From comms at afrinic.net Mon Jan 19 07:47:25 2026 From: comms at afrinic.net (comms at afrinic.net) Date: Mon, 19 Jan 2026 07:47:25 +0000 Subject: [rpd] Partner with AFRINIC: Host or Sponsor 2026 IPv6 & RPKI Events in Your Country Message-ID: [Apologies for cross-posting] [Version en fran?ais au bas] Dear colleagues, Greetings from AFRINIC! It's that time of year, and we are calling on organisations across Africa to partner with us to unleash the power of the Internet through impactful in-person events in 2026. Join the 40+ organisations who have partnered with us over the past 20 years to build skills, deploy technologies, and drive continental progress. You can partner with us in one of two ways: 1. Host an RPKI & IPv6 Deployathon. 2. Host an IPv6 Training & Certification event. Government organisations will benefit the most from hosting our special Government IPv6 Kickstart event, in which we: * Train & certify government IPv6 Engineers * Train & certify IPv6 government Program Managers * Create & refine an IPv6 Action Plan for the government. This event prepares the government organisation to host future deployathons, transforming those IPv6 deployment plans into actual IPv6 deployment milestones. Ready to make an impact? Learn more and apply to host an event in your country in 2026 - https://afrinic.academy/call-for-local-hosts/ Deadline: 31 January 2026 at 23:59 GMT. We look forward to partnering with you to elevate Africa's digital future. Kind Regards, AFRINIC Team P.S. Interested in sponsoring but don?t want to host? Sponsor an event or certification fees for engineers - https://afrinic.academy/call-for-local-hosts/ ???????????????????????.. Devenez partenaire d'AFRINIC : organisez ou sponsorisez les ?v?nements IPv6 & RPKI 2026 dans votre pays Chers coll?gues, Salutations d?AFRINIC!! C'est le moment de l'ann?e o? nous appelons les organisations ? travers l'Afrique ? collaborer avec nous pour exploiter tout le potentiel d'Internet gr?ce ? des ?v?nements en pr?sentiel marquants en 2026. Rejoignez plus de 40 organisations qui se sont associ?es ? nous au cours des 20 derni?res ann?es pour d?velopper des comp?tences, d?ployer des technologies et stimuler le progr?s continental. Vous pouvez vous associer ? nous de deux mani?res : 1. Organisez un RPKI & IPv6 Deployathon 2. Organisez un ?v?nement de formation et de certification IPv6 Les organisations gouvernementales tireront le meilleur parti de l'organisation de notre ?v?nement sp?cial Government IPv6 Kickstart, dans le cadre duquel nous: * Formons et certifions les ing?nieurs IPv6 du gouvernement * Formons et certifions les responsables de programmes IPv6 du gouvernement * Cr?ons et affinons un plan d'action IPv6 pour le gouvernement. Cet ?v?nement pr?pare l'organisme gouvernemental ? organiser de futurs d?ploiements, transformant ces plans de d?ploiement IPv6 en ?tapes concr?tes de d?ploiement IPv6. Pr?t ? faire bouger les choses ? En savoir plus et postuler pour accueillir un ?v?nement dans votre pays en 2026 - https://afrinic.academy/fr/call-for-local-hosts/ Date limite : 31 Janvier 2026 ? 23 h 59 GMT. Nous sommes impatients de collaborer avec vous pour am?liorer l'avenir num?rique de l'Afrique. Cordialement, AFRINIC Team P.S. Vous souhaitez devenir un sponsor, mais vous ne voulez pas accueillir l??v?nement Parrainez un ?v?nement ou les frais de certification des ing?nieurs - https://afrinic.academy/fr/call-for-local-hosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From policy-liaison at afrinic.net Mon Feb 9 06:34:44 2026 From: policy-liaison at afrinic.net (Policy Liaison Team) Date: Mon, 9 Feb 2026 10:34:44 +0400 Subject: [rpd] Ratified Policy Proposal - Abuse Contact Policy Update AFPUB-2018-GEN-001-DRAFT07 Message-ID: <0e4358c9-afb6-4974-a211-deefac16d4ef@afrinic.net> ** *Dear PDWG Members* * We refer to the PDWG Chairs report on the draft policy proposal Abuse Contact Policy Update? AFPUB-2018-GEN-001-DRAFT07 dated 14 January 2022 and sent to the AFRINIC Board of Directors for ratification. The Board has also taken note of the report of the Policy Liaison dated? 16 October 2025. We wish to inform you that the AFRINIC Board, at its meeting held on 4 February 2026, considered the PDWG Chairs' recommendation and resolved,with the consent of the Receiver,? that the above policy proposal be ratified. The? AFRINIC Secretariat will revert back on the implementation. References :- Policy Proposal - https://afrinic.net/policy/proposals/2018-gen-001-d7 PDWG Chairs Report - https://lists.afrinic.net/pipermail/rpd/2022/014141.html Kind Regards, Madhvi Gokool & Brice Abba * -- AFRINIC Policy Liaison. t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia -------------- next part -------------- An HTML attachment was scrubbed... URL: From madhvi at afrinic.net Mon Feb 9 06:45:38 2026 From: madhvi at afrinic.net (Madhvi Gokool) Date: Mon, 9 Feb 2026 10:45:38 +0400 Subject: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer Message-ID: ** * Dear PDWG Members, We refer to the PDWG Chairs report on the draft policy proposal AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer dated 14 January 2022 and sent to the AFRINIC Board of Directors for ratification. The Board has also taken note of the report of the Policy Liaison dated? 24 October 2025. We wish to inform you that the AFRINIC Board, at its meeting held on 4 February 2026, considered the PDWG Chairs' recommendation and resolved,with the consent of the Receiver,? that the above policy proposal be ratified. The? AFRINIC Secretariat will revert back on the implementation. Kind Regards, Madhvi Gokool & Brice Abba Policy Liaisons * * References :- Policy Proposal - https://afrinic.net/policy/proposals/2020-gen-006-d3 PDWG Chairs Report - https://lists.afrinic.net/pipermail/rpd/2022/014142.html Kind Regards, Madhvi Gokool & Brice Abba * -- AFRINIC Policy Liaison. t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd From professorpeteranderson at gmail.com Mon Feb 9 07:07:00 2026 From: professorpeteranderson at gmail.com (Peter Anderson) Date: Mon, 9 Feb 2026 11:07:00 +0400 Subject: [rpd] Launch of The Internet Ecosystem Book Message-ID: *(Apologies for cross-posting)* As a researcher, I have never come across a highly intensive and inclusive book like "The Internet Ecosystem". The book englobes the whole Internet Ecosystem with the correct information compared to misleading information from blogs/wikipedia on the Internet. This book was reviewed by Vint Cerf. I have just completed the reading, I will highly recommend it and it is nice to have a copy to keep for reference. Professor Peter Anderson Head of Research ------------------------------ *From:* Nikesh B. Simmandree *Sent:* Monday, August 18, 2025 1:35 PM *To:* alac-announce at icann.org ; alac at icann.org < alac at icann.org>; at-large at icann.org ; afri-discuss at icann.org *Subject:* Launch of The Internet Ecosystem Book Dear Community, I am thrilled to announce the launch of my book, *The Internet Ecosystem* ? a comprehensive exploration of the history, architecture, governance, and future of the Internet. This book distills decades of technological evolution ? from ARPANET and packet switching, to AI, Web3, quantum networks, and beyond ? into a clear, engaging narrative accessible to both technical and non-technical readers *What the Book Covers* - *The Past:* How Cold War research, ARPANET, and packet switching gave birth to the Internet we know today. - *The Present:* The intricate roles of ISPs, backbone providers, cloud infrastructure, AI, cybersecurity, and global governance shaping our daily online experiences. - *The Future:* Insights into 5G/6G, blockchain, immersive technologies, quantum security, and the Internet in 2050. With *49 detailed chapters*, the book provides a definitive yet approachable reference for students, professionals, policymakers, and curious readers alike. My mission with *The Internet Ecosystem* is to make the Internet?s complexity understandable ? showing not only *how* the Internet works, but also *why* it matters and has become one of the most transformative human inventions ? while sparking dialogue on how we build a secure, inclusive, and sustainable digital future. In the 21st century, understanding the Internet is not optional ? it?s essential. Whether you?re a business leader, policymaker, educator, student, or everyday Internet user, this book provides the context and clarity you need to navigate the opportunities and challenges of our connected world. *Get Your Copy* *The Internet Ecosystem* is now available: https://payhip.com/b/hfvYg Thank you, Best Regards, Nikesh B. Simmandree +230-5-907-3413 nikeshbs at outlook.com This message and its attachments are intended only for the person or entity to which it is addressed and are strictly confidential. If you have received this in error, please delete it from any devices after having informed the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah at neo.co.tz Mon Feb 9 07:49:29 2026 From: noah at neo.co.tz (Noah) Date: Mon, 9 Feb 2026 10:49:29 +0300 Subject: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer In-Reply-To: References: Message-ID: To the Afrinic Board, Allow me to wish you a Happy 2026. This is a greatest progress. You might now understand the feeling but this is a great way forward. We shall hence forth retreat and now move on to building the African Internet Infrastructure. Cheers, *.**/noah* On Mon, 9 Feb 2026, 9:55?am Madhvi Gokool via RPD, wrote: > > > * Dear PDWG Members, We refer to the PDWG Chairs report on the draft > policy proposal AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy > Transfer dated 14 January 2022 and sent to the AFRINIC Board of Directors > for ratification. The Board has also taken note of the report of the Policy > Liaison dated 24 October 2025. We wish to inform you that the AFRINIC > Board, at its meeting held on 4 February 2026, considered the PDWG Chairs' > recommendation and resolved,with the consent of the Receiver, that the > above policy proposal be ratified. The AFRINIC Secretariat will revert > back on the implementation. Kind Regards, Madhvi Gokool & Brice Abba > Policy Liaisons * > > > * References :- Policy Proposal - > https://afrinic.net/policy/proposals/2020-gen-006-d3 > PDWG Chairs Report - > https://lists.afrinic.net/pipermail/rpd/2022/014142.html > Kind Regards, > Madhvi Gokool & Brice Abba * > > -- > AFRINIC Policy Liaison. > t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.netfacebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From comms at afrinic.net Wed Feb 11 11:25:04 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Wed, 11 Feb 2026 15:25:04 +0400 Subject: [rpd] Call for Volunteers on the Nomination Committee 2026 Message-ID: [Version en fran?ais au bas] Dear AFRINIC Members and Community, The AFRINIC Board of Directors hereby makes a public call for volunteers from the African Internet community to fill four (4) vacant positions on a Nomination Committee. The Nomination Committee [NomCom 2026] is being constituted for the purpose of conducting the following elections: Three (3) Members of the Governance Committee elected by AFRINIC Resource Members in good standing. Two (2) Members of the NRO NC / ASO AC elected by the AFRINIC community. PDP Co-Chairs selected through a consensus-based process by the AFRINIC Policy Development Working Group Additional information on the role and responsibilities of the NomCom 2026, as well as other related information is available in the Election Guidelines published at: https://elections.afrinic.net/election-guideline-2026 Interested individuals wishing to serve on the NomCom 2026 are invited to submit an expression of interest, together with a short biography, by email to guylaine at afrinic.net by 20 February 2026 at 23:59 UTC. The Board expects members of the NomCom to: Be neutral and impartial; Have no direct or indirect interest in the outcome of the elections; Be trustworthy individuals of the AFRINIC community; Demonstrate a good understanding of the AFRINIC business environment; and Carry out their responsibilities diligently and in good faith. Please note that NomCom members serve on a voluntary basis and do not receive any remuneration. AFRINIC staff will provide logistical support to NomCom throughout its mandate. Travel support will also be provided for the Chairperson of the NomCom 2026 to attend the meeting at which such elections will be held, or other meetings where the attendance of a representative of the NomCom is warranted. Further information on the meetings will be provided in due course. We sincerely thank the AFRINIC Members and the community for its usual cooperation and continued support. Yours sincerely, Prof. Adewale Adedokun Chairman, AFRINIC Board of Directors ??????? Chers membres et chers membres de la communaut? d'AFRINIC, Le conseil d'administration d'AFRINIC lance un appel public ? des volontaires au sein de la communaut? Internet africaine afin de pourvoir quatre (4) postes au sein du comit? de nomination (NomCom) pour l'ann?e 2026. Le NomCom 2026 sera mis en place pour organiser les ?lections suivantes : Trois (3) membres du Comit? de gouvernance ?lus par les Membres ressources AFRINIC en r?gle ; Deux (2) membres du NRO NC/ASO AC ?lus par la communaut? AFRINIC ; Les copr?sidents du PDP s?lectionn?s par consensus au sein du Groupe de travail sur le d?veloppement des politiques d'AFRINIC. Des informations compl?mentaires sur le r?le et les responsabilit?s du NomCom sont disponibles dans les Lignes directrices des ?lections, publi?es ? l'adresse suivante : https://elections.afrinic.net/election-guideline-2026 Les personnes int?ress?es ? si?ger au NomCom 2026 sont invit?es ? soumettre une manifestation d'int?r?t accompagn?e d'une courte biographie par courriel ? l'adresse guylaine at afrinic.net , au plus tard le 20 f?vrier 2026 ? 23 h 59 UTC. Le conseil d'administration attend des membres du NomCom qu'ils : fassent preuve de neutralit? et d'impartialit? ; n'aient aucun int?r?t direct ou indirect dans l'issue des ?lections ; jouissent d'une r?putation de confiance au sein de la communaut? AFRINIC ; d?montrent une bonne compr?hension de l'environnement d'AFRINIC ; exercent leurs responsabilit?s avec diligence et en toute bonne foi Veuillez noter que les membres du NomCom exercent leurs fonctions ? titre b?n?vole et ne per?oivent aucune r?mun?ration. Le personnel d'AFRINIC fournira un appui logistique au NomCom tout au long de son mandat. Un soutien aux d?placements sera accord? au pr?sident du NomCom 2026 afin de lui permettre d'assister ? la s?ance ?lectorale ou ? d'autres r?unions pour lesquelles la pr?sence d'un repr?sentant du NomCom est requise. Des informations compl?mentaires sur ces r?unions seront communiqu?es ult?rieurement. Nous remercions sinc?rement les membres d'AFRINIC et la communaut? pour leur collaboration et leur soutien continus. Cordialement, Prof. Adewale Adedokun Pr?sident, Conseil d?administration d?AFRINIC -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah at neo.co.tz Wed Feb 18 07:33:53 2026 From: noah at neo.co.tz (Noah) Date: Wed, 18 Feb 2026 10:33:53 +0300 Subject: [rpd] Fwd: [arin-ppml] ARIN 2025-8 Reserve 4.10 Space for In-Region Use In-Reply-To: References: Message-ID: FYI Cheers, *.**/noah* ---------- Forwarded message --------- From: Kaitlyn Pellak Date: Tue, 17 Feb 2026, 11:57?pm Subject: [arin-ppml] ARIN 2025-8 Reserve 4.10 Space for In-Region Use To: Cc: Hello PPML, We?ve received some feedback regarding this policy I wanted to resurface to gauge community interest. One community member mentioned a desire to restrict 4.10 space to only support ARIN IPv6 allocations, and ensure that 4.10 space is only used out of region insofar as it adheres to the restrictions set aside in section 9 of the NRPM. In case it was unclear, current ARIN practice is to allow a requestor to receive 4.10 space with an IPv6 allocation from another RIR as justification if that IPv6 allocation is being used within the ARIN service region (for example being routed within the ARIN service region). With this in mind, does the community support a more restrictive view of 4.10 justification that would only allow for ARIN allocated IPv6 ranges to be used for qualifying for 4.10 space? I believe in addition to the original proposal for this language I saw at least one additional community member in favor of this change. Thanks folks, Kaitlyn Pellak ARIN Advisory Council _______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent at ngundi.me.ke Tue Feb 24 18:09:25 2026 From: vincent at ngundi.me.ke (PDWG Chair) Date: Tue, 24 Feb 2026 21:09:25 +0300 Subject: [rpd] Preparation for the Upcoming Public Policy Meeting in 2026 Message-ID: <9380fad9-e5dc-4453-a57a-39c87326be2a@afrinic.net> Dear AFRINIC PDWG, We would like to welcome you to the new year. According to the Policy Development Process, policy changes are proposed by the Community. ?In anticipation of the upcoming Public Policy Meeting (PPM) in 2026, we kindly request that you commence? the work on developing and submitting new Draft Policy Proposals (DPPs). No new policy proposals have been received since May 2022 and those proposals that were under discussion expired a calendar year after their submission. While the dates of the PPM are not yet known, to avoid a rush of last-minute submissions and to ensure that the problem statements are well defined, we encourage the authors: (a)who withdrew their proposals ?PDP Working Group Guidelines and Procedures AFPUB-2020-GEN-002-DRAFT06? and ?Update of PDP AFPUB-2021-GEN-002-DRAFT03? to work together and propose a joint version that will address the implementation concerns. (b)whose policies expired to submit a new version of their proposals if they wish their DPPs to run for consensus determination. (c)to consider the past Policy Implementation Experience Reports and use the published issues as problem statements. All submitted proposals can be discussed on the RPD mailing list(rpd at afrinic.net) as of now. Once the AFRINIC Secretariat announces the date on which the PPM will be held, we will communicate further on the timelines to be adhered to in accordance with Section 3 of the Consolidated Policy Manual? for the proposals to go through the Policy Development Process for consensus determination. Your efforts are vital to the policy development process. Past webinars on the Policy Development Process are available for consultation here - https://www.afrinic.net/events/webinar-series . The PDWG may reach out to us in case they wish to discuss any new topic or a refresher. We look forward to your contributions in the coming months. Kind Regards, Dr. Vincent Ngundi and Darwin Da Costa *AFRINIC PDWG Co-Chairs*** -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah at neo.co.tz Thu Mar 12 10:58:11 2026 From: noah at neo.co.tz (Noah) Date: Thu, 12 Mar 2026 13:58:11 +0300 Subject: [rpd] The new case and plaint challenging the Board's ratification of the resource transfer policy. Message-ID: Dear Members, FYI, a new case has been initiated by the following member: Skyconnect v AFRINIC & Anor SC/COM/PWS/000132/2026 I assume this relates to the policy ratified by the Board below [1]. Cheers, *Noah* AFRINIC Number Resources Transfer Policy (Draft-3) [1] https://afrinic.net/policy/proposals/2020-gen-006-d3#proposal -------------- next part -------------- An HTML attachment was scrubbed... URL: From comms at afrinic.net Tue Mar 17 08:56:53 2026 From: comms at afrinic.net (comms at afrinic.net) Date: Tue, 17 Mar 2026 08:56:53 +0000 Subject: [rpd] AFRINIC Newsletter: Community Pulse Message-ID: View in browser ? https://connect.afrinic.net/email/view/69b8e72a0984c626133979 AFRINIC ? Monthly Publication Community Pulse February 2026 [AFRINIC Community Pulse] Welcome to the first 2026 edition of AFRINIC Community Pulse. This month, we explore the steady expansion of our community, the strengthening of our governance structures, and the work underway to ensure the African Internet remains resilient, inclusive, and secure for all. Membership Expanding the Internet Community In February 2026, AFRINIC continued strengthening Africa's Internet ecosystem by welcoming 10 new resource members ? 9 Internet Service Providers and 1 financial institution from South Africa, Tanzania, Zimbabwe, Senegal, Kenya, and Nigeria. Continue Reading ? Infrastructure Strengthening Internet Routing Security across Africa AFRINIC continues to support the development of a more secure and resilient Internet infrastructure across Africa by enabling its members to adopt modern routing security practices and maintain accurate Internet registry data. Continue Reading ? Governance AFRINIC Appoints 2026 Bylaws Review Committee [Bylaws Review] As part of its continued efforts to strengthen organisational governance, AFRINIC has appointed the 2026 Bylaws Review Committee following an open call for volunteers, ensuring its governing framework reflects the evolving needs of the community. Continue Reading ? Policy New Policies Ratified [Policies Ratified] The Board has officially ratified two policies, reinforcing the management framework for Internet resources in our region: * Number Resource Transfer Policy (AFPUB-2020-GEN-006-DRAFT03) * Abuse Contact Policy Update (AFPUB-2018-GEN-001-DRAFT07) Continue Reading ? Success Spotlight Douala IX [Douala IX] As Internet usage continues to grow across Central Africa, the development of resilient, locally managed infrastructure has become increasingly critical. Strengthening local connectivity improves network performance, reduces latency, and keeps Internet traffic within the region. Continue Reading ? Engagements Global and Regional Engagements [Global Engagements] Brice Abba, AFRINIC's Stakeholder Engagement Manager, speaking at the Central Africa IGF 2026 in Burundi AFRINIC's recent engagements underscore a commitment to strengthening Africa's internet resilience through technical training and strategic advocacy. In Benin, a five-day hands-on workshop equipped engineers with critical skills in IXP interconnection and routing security. In Tunis, AFRINIC engaged IT decision-makers on cybersecurity and cloud infrastructure challenges across the Maghreb region. Continue Reading ? Community Join the AFRINIC Growing Internet Community Organisations across Africa and the Indian Ocean region continue to join the AFRINIC Internet community to access the resources, services, and expertise needed to build and operate modern Internet infrastructure. Continue Reading ? Stay informed about the African Internet ecosystem ? delivered to your inbox every month. Subscribe to our Newsletter Regional Internet Registry for Africa 11th Floor, Standard Chartered Tower, Cybercity, Ebene, Mauritius service-support at afrinic.net ? 2026 AFRINIC Community Pulse. All rights reserved. Unsubscribe to no longer receive emails from us. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Mon Mar 23 05:34:25 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Mon, 23 Mar 2026 13:34:25 +0800 Subject: [rpd] Ratified Policy Proposal - Abuse Contact Policy Update AFPUB-2018-GEN-001-DRAFT07 In-Reply-To: <0e4358c9-afb6-4974-a211-deefac16d4ef@afrinic.net> References: <0e4358c9-afb6-4974-a211-deefac16d4ef@afrinic.net> Message-ID: Hi Madhvi, Brice, I just realized that while the board ratified AFPUB-2020-GEN-006-DRAFT03 and AFPUB-2018-GEN-001-DRAFT07, the policy compliance dashboard (AFPUB-2021-GEN-003-DRAFT02), has not been yet ratified. Do we have any news on that one, or when it is expected to be ratified? Also, it will be good to have an idea about what are the implementation plans/status for all the pending policies at: https://afrinic.net/policy/proposals? Tks! Regards, Jordi @jordipalet > El 9 feb 2026, a las 14:34, Policy Liaison Team via RPD escribi?: > > Dear PDWG Members > > We refer to the PDWG Chairs report on the draft policy proposal Abuse Contact Policy Update AFPUB-2018-GEN-001-DRAFT07 dated 14 January 2022 and sent to the AFRINIC Board of Directors for ratification. The Board has also taken note of the report of the Policy Liaison dated 16 October 2025. > We wish to inform you that the AFRINIC Board, at its meeting held on 4 February 2026, considered the PDWG Chairs' recommendation and resolved,with the consent of the Receiver, that the above policy proposal be ratified. > > The AFRINIC Secretariat will revert back on the implementation. > > References :- > Policy Proposal - https://afrinic.net/policy/proposals/2018-gen-001-d7 > PDWG Chairs Report - https://lists.afrinic.net/pipermail/rpd/2022/014141.html > > Kind Regards, > Madhvi Gokool & Brice Abba > > -- > AFRINIC Policy Liaison. > t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net > facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: afrinic-logo-a-favicon.png Type: image/png Size: 1187 bytes Desc: not available URL: From baya.sylvain at cmnog.cm Mon Mar 23 06:28:43 2026 From: baya.sylvain at cmnog.cm (Sylvain BAYA) Date: Mon, 23 Mar 2026 07:28:43 +0100 Subject: [rpd] Ratified Policy Proposal - Abuse Contact Policy Update AFPUB-2018-GEN-001-DRAFT07 In-Reply-To: References: <0e4358c9-afb6-4974-a211-deefac16d4ef@afrinic.net> Message-ID: Le 23/03/2026 ? 06:34, jordi.palet--- via RPD a ?crit?: > Hi Madhvi, Brice, > > I just realized that while the board > ratified?AFPUB-2020-GEN-006-DRAFT03 and?AFPUB-2018-GEN-001-DRAFT07, > the policy compliance dashboard (AFPUB-2021-GEN-003-DRAFT02), has not > been yet ratified. > Hi Jordi, Hope you are doing well, brother! You probably meant: not listed as ratified; because i recollect that it was ratified and only not implemented, due to reasons we are all able to understand... Thanks to the Policy Liaison Team (PLT) to clarify this fact. Shalom, --sb. > > Do we have any news on that one, or when it is expected to be ratified? > > Also, it will be good to have an idea about what are the > implementation plans/status for all the pending policies at: > > List of Current Policy Proposals > afrinic.net > afrinic-logo-a-favicon.png > > > > Tks! > > Regards, > Jordi > > @jordipalet > > >> El 9 feb 2026, a las 14:34, Policy Liaison Team via RPD >> escribi?: >> >> ** >> >> *Dear PDWG Members* >> * >> >> We refer to the PDWG Chairs report on the draft policy proposal Abuse >> Contact Policy Update? AFPUB-2018-GEN-001-DRAFT07 dated 14 January >> 2022 and sent to the AFRINIC Board of Directors for ratification. The >> Board has also taken note of the report of the Policy Liaison dated? >> 16 October 2025. >> We wish to inform you that the AFRINIC Board, at its meeting held on >> 4 February 2026, considered the PDWG Chairs' recommendation and >> resolved,with the consent of the Receiver,? that the above policy >> proposal be ratified. >> >> The? AFRINIC Secretariat will revert back on the implementation. >> >> References :- >> Policy Proposal - https://afrinic.net/policy/proposals/2018-gen-001-d7 >> PDWG Chairs Report - >> https://lists.afrinic.net/pipermail/rpd/2022/014141.html >> >> Kind Regards, >> Madhvi Gokool & Brice Abba >> * >> >> -- >> AFRINIC Policy Liaison. >> t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic |w:www.afrinic.net >> facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents of > this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If you > are not the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited, will be > considered a criminal offense, so you must reply to the original > sender to inform about this communication and delete it. > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -- Best Regards ! baya.sylvain [AT cmNOG DOT cm] | cmNOG's Structure | CAMIX's Website | Douala-IX's Looking Glass | cmNOG's Surveys | Subscribe to cmNOG's Mailing List | __ #LASAINTEBIBLE|#Eph?siens5:18,15-21?[...] 18 Et *_ne vous enivrez_* pas *_de vin_*, en quoi *_il y a de la dissolution_*; mais *_soyez remplis de l'Esprit_*, [...]? ?#LASAINTEBIBLE|#H?breux13:9,5-15?[...] 9 _*Ne soyez pas seduits par*_ des _*doctrines diverses*_ et _*etrangeres*_, car il est bon _*que le coeur soit affermi par la grace*_, non par les viandes, lesquels n'ont pas profite ? ceux qui y ont marche. [...]? #AMEN,#Maranatha,#MerciJ?SUS! #?MaPri?re? est que tu naisses de nouveau.#Chr?tiennement -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: afrinic-logo-a-favicon.png Type: image/png Size: 1187 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x0387408365AC8594.asc Type: application/pgp-keys Size: 19437 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From policy-liaison at afrinic.net Mon Mar 23 18:29:53 2026 From: policy-liaison at afrinic.net (AFRINIC Policy Liaison) Date: Mon, 23 Mar 2026 18:29:53 +0000 Subject: [rpd] Policy Compliance Dashboard - Not ratified by AFRINIC Board Message-ID: <21d0b0de-3268-40af-8bab-f8a8e84c4af0@afrinic.net> ** *Dear Policy Authors,* * We wish to inform you that the AFRINIC Board has not ratified your policy proposal, Policy Compliance Dashboard ID AFPUB-2021-GEN-003-DRAFT02. This decision was made due to the proposal's potential impact on AFRINIC?s contract management of the Registration Service Agreement (RSA), as highlighted in the legal impact assessment of the proposal. As a result, the proposal will be sent back to the RPD mailing list, where it is foreseen to expire in accordance with the Consolidated Policy Manual. Should you wish to continue with this proposal, we recommend that you: * Consider the impact assessment provided:Impact Assessment . * Amend the proposal as required, with a focus on Sections 4, 5, and 6. * Submit the new proposal for discussion. While the AFRINIC Board has not yet called for a Public Policy Meeting, you have ample time to make refinements and request us, the Policy Liaisons, for support in drafting the proposal. Thank you for your continuous contribution to the AFRINIC PDP. Sincerely * -- AFRINIC Policy Liaison. t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjmututicloud at gmail.com Tue Mar 24 19:00:16 2026 From: jjmututicloud at gmail.com (Junior) Date: Tue, 24 Mar 2026 21:00:16 +0200 Subject: [rpd] =?utf-8?q?=5BQUIP=5D_A_new_federated_identity_and_interacti?= =?utf-8?q?on_layer_over_QUIC_=E2=80=93_seeking_engagement_with_the?= =?utf-8?q?_AFRINIC_community?= Message-ID: Dear AFRINIC RPD list members, My name is Junior Joseph Mututi, and I?ve been working on a new protocol called QUIP (QUIC Identity Protocol). QUIP is designed as an open, federated identity and interaction layer built entirely on QUIC (RFC 9000). It combines the domain-based addressing of XMPP, the vocabulary of ActivityStreams, and a novel trust model where ISPs act as neutral trust anchors ? verifying user identities without owning them. The protocol?s whitepaper (attached) details its architecture: a generic state machine over QUIC, ISP?based attestation, a distributed CA foundation, end?to?end encryption extensions, and built?in federation mechanics. It is meant to run in parallel with the existing web and to give ISPs a direct role in enabling secure, privacy?respecting communication for their subscribers. I?m reaching out to the AFRINIC community because Africa is a key region for QUIP?s vision. The whitepaper notes (Section 13.3.1) that Africa?s ISP landscape ? with its growing number of operators, mobile?first connectivity, and strong data sovereignty concerns ? is a natural early adopter. I?d like to present QUIP at an upcoming AFRINIC meeting (e.g., AFRINIC?OPEN) to get feedback from network engineers, policy makers, and the ISP community. Specifically, I?d be grateful for: ? Guidance on how to propose a presentation or technical talk at an AFRINIC meeting. ? Feedback on the ISP trust model and its alignment with regional regulatory frameworks. ? Interest from ISPs willing to participate in a pilot deployment (the whitepaper outlines a potential Zimbabwe pilot with ZISPA and POTRAZ). I welcome any questions or comments ? I?m happy to clarify technical details or discuss how QUIP could fit into AFRINIC?s capacity?building and infrastructure development goals. Thank you for your time, and I look forward to engaging with the community. Best regards, Junior Joseph Mututi WhatsApp/Calls: +27658095749/+27812629742 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: QUIP_InstitutionalWhitePaper_v1.1.pdf Type: application/pdf Size: 341788 bytes Desc: not available URL: From ben.roberts at afrinic.net Tue Mar 24 19:31:50 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Tue, 24 Mar 2026 22:31:50 +0300 Subject: [rpd] =?utf-8?q?=5BQUIP=5D_A_new_federated_identity_and_interacti?= =?utf-8?q?on_layer_over_QUIC_=E2=80=93_seeking_engagement_with_the_AFRINI?= =?utf-8?q?C_community?= In-Reply-To: References: Message-ID: <7A322302-3C0A-4324-9685-1F2D52A0FCED@afrinic.net> Junior, Thanks for this contribution. I confess I am at a complete loss to understand the white paper at all. I am relatively tech savvy and able to interpret standards etc, but I?m lost in so many words. I would suggest some diagrams might help to communicate the complex ideas that the paper is conveying. Kind regards Ben Sent from my iPhone > On 24 Mar 2026, at 22:02, Junior wrote: > > ? > Dear AFRINIC RPD list members, > > My name is Junior Joseph Mututi, and I?ve been working on a new protocol called QUIP (QUIC Identity Protocol). QUIP is designed as an open, federated identity and interaction layer built entirely on QUIC (RFC 9000). It combines the domain-based addressing of XMPP, the vocabulary of ActivityStreams, and a novel trust model where ISPs act as neutral trust anchors ? verifying user identities without owning them. > > The protocol?s whitepaper (attached) details its architecture: a generic state machine over QUIC, ISP?based attestation, a distributed CA foundation, end?to?end encryption extensions, and built?in federation mechanics. It is meant to run in parallel with the existing web and to give ISPs a direct role in enabling secure, privacy?respecting communication for their subscribers. > > I?m reaching out to the AFRINIC community because Africa is a key region for QUIP?s vision. The whitepaper notes (Section 13.3.1) that Africa?s ISP landscape ? with its growing number of operators, mobile?first connectivity, and strong data sovereignty concerns ? is a natural early adopter. I?d like to present QUIP at an upcoming AFRINIC meeting (e.g., AFRINIC?OPEN) to get feedback from network engineers, policy makers, and the ISP community. > > Specifically, I?d be grateful for: > > ? Guidance on how to propose a presentation or technical talk at an AFRINIC meeting. > ? Feedback on the ISP trust model and its alignment with regional regulatory frameworks. > ? Interest from ISPs willing to participate in a pilot deployment (the whitepaper outlines a potential Zimbabwe pilot with ZISPA and POTRAZ). > > I welcome any questions or comments ? I?m happy to clarify technical details or discuss how QUIP could fit into AFRINIC?s capacity?building and infrastructure development goals. > > Thank you for your time, and I look forward to engaging with the community. > > Best regards, > Junior Joseph Mututi > WhatsApp/Calls: +27658095749/+27812629742 > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From dello.a.a at gmail.com Tue Mar 24 20:09:32 2026 From: dello.a.a at gmail.com (DELLO. A. A) Date: Tue, 24 Mar 2026 23:09:32 +0300 Subject: [rpd] =?utf-8?q?=5BDello_Response=5D_A_new_federated_identity_and?= =?utf-8?q?_interaction_layer_over_QUIC_=E2=80=93_seeking_engagemen?= =?utf-8?q?t_with_the_AFRINIC_community?= In-Reply-To: References: Message-ID: Dear Junior, Thank you for sharing this. The concept is interesting, but before meaningful technical feedback can be given, the paper needs to explain a few fundamentals more clearly, ideally with architecture and trust-flow diagrams. In particular, could you clarify: 1. the exact problem QUIP solves that existing protocols do not 2. where QUIC ends and the actual identity/application layer begins, 3. how the ISP trust-anchor model works in practice, including identity proofing, portability, revocation, and privacy safeguards, 4. how the proposed distributed CA model operates, and 5. whether there is any working prototype, message flow, or interoperability demonstration. At present, the paper feels too abstract for technical review, especially without diagrams showing the architecture, trust relationships, and end-to-end flows Regards, Amani Dello On Tue, 24 Mar 2026 at 22:04, Junior wrote: > Dear AFRINIC RPD list members, > > My name is Junior Joseph Mututi, and I?ve been working on a new protocol > called QUIP (QUIC Identity Protocol). QUIP is designed as an open, > federated identity and interaction layer built entirely on QUIC (RFC 9000). > It combines the domain-based addressing of XMPP, the vocabulary of > ActivityStreams, and a novel trust model where ISPs act as neutral trust > anchors ? verifying user identities without owning them. > > The protocol?s whitepaper (attached) details its architecture: a generic > state machine over QUIC, ISP?based attestation, a distributed CA > foundation, end?to?end encryption extensions, and built?in federation > mechanics. It is meant to run in parallel with the existing web and to give > ISPs a direct role in enabling secure, privacy?respecting communication for > their subscribers. > > I?m reaching out to the AFRINIC community because Africa is a key region > for QUIP?s vision. The whitepaper notes (Section 13.3.1) that Africa?s ISP > landscape ? with its growing number of operators, mobile?first > connectivity, and strong data sovereignty concerns ? is a natural early > adopter. I?d like to present QUIP at an upcoming AFRINIC meeting (e.g., > AFRINIC?OPEN) to get feedback from network engineers, policy makers, and > the ISP community. > > Specifically, I?d be grateful for: > > ? Guidance on how to propose a presentation or technical talk at an > AFRINIC meeting. > ? Feedback on the ISP trust model and its alignment with regional > regulatory frameworks. > ? Interest from ISPs willing to participate in a pilot deployment (the > whitepaper outlines a potential Zimbabwe pilot with ZISPA and POTRAZ). > > I welcome any questions or comments ? I?m happy to clarify technical > details or discuss how QUIP could fit into AFRINIC?s capacity?building and > infrastructure development goals. > > Thank you for your time, and I look forward to engaging with the community. > > Best regards, > Junior Joseph Mututi > WhatsApp/Calls: +27658095749/+27812629742 > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Wed Mar 25 08:47:35 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Wed, 25 Mar 2026 09:47:35 +0100 Subject: [rpd] =?utf-8?q?=5BQUIP=5D_A_new_federated_identity_and_interacti?= =?utf-8?q?on_layer_over_QUIC_=E2=80=93_seeking_engagement_with_the_AFRINI?= =?utf-8?q?C_community?= In-Reply-To: <7A322302-3C0A-4324-9685-1F2D52A0FCED@afrinic.net> References: <7A322302-3C0A-4324-9685-1F2D52A0FCED@afrinic.net> Message-ID: <246D73A0-E323-4F24-A08D-37FD86AD7572@consulintel.es> Fail to see the relation of this with PDP, and this list is only for PDP, nothing else. Regards, Jordi @jordipalet > El 24 mar 2026, a las 20:31, Ben Roberts - AfriNIC via RPD escribi?: > > Junior, > Thanks for this contribution. I confess I am at a complete loss to understand the white paper at all. I am relatively tech savvy and able to interpret standards etc, but I?m lost in so many words. I would suggest some diagrams might help to communicate the complex ideas that the paper is conveying. > > Kind regards > Ben > > > Sent from my iPhone > >> On 24 Mar 2026, at 22:02, Junior wrote: >> >> ? >> Dear AFRINIC RPD list members, >> >> My name is Junior Joseph Mututi, and I?ve been working on a new protocol called QUIP (QUIC Identity Protocol). QUIP is designed as an open, federated identity and interaction layer built entirely on QUIC (RFC 9000). It combines the domain-based addressing of XMPP, the vocabulary of ActivityStreams, and a novel trust model where ISPs act as neutral trust anchors ? verifying user identities without owning them. >> >> The protocol?s whitepaper (attached) details its architecture: a generic state machine over QUIC, ISP?based attestation, a distributed CA foundation, end?to?end encryption extensions, and built?in federation mechanics. It is meant to run in parallel with the existing web and to give ISPs a direct role in enabling secure, privacy?respecting communication for their subscribers. >> >> I?m reaching out to the AFRINIC community because Africa is a key region for QUIP?s vision. The whitepaper notes (Section 13.3.1) that Africa?s ISP landscape ? with its growing number of operators, mobile?first connectivity, and strong data sovereignty concerns ? is a natural early adopter. I?d like to present QUIP at an upcoming AFRINIC meeting (e.g., AFRINIC?OPEN) to get feedback from network engineers, policy makers, and the ISP community. >> >> Specifically, I?d be grateful for: >> >> ? Guidance on how to propose a presentation or technical talk at an AFRINIC meeting. >> ? Feedback on the ISP trust model and its alignment with regional regulatory frameworks. >> ? Interest from ISPs willing to participate in a pilot deployment (the whitepaper outlines a potential Zimbabwe pilot with ZISPA and POTRAZ). >> >> I welcome any questions or comments ? I?m happy to clarify technical details or discuss how QUIP could fit into AFRINIC?s capacity?building and infrastructure development goals. >> >> Thank you for your time, and I look forward to engaging with the community. >> >> Best regards, >> Junior Joseph Mututi >> WhatsApp/Calls: +27658095749/+27812629742 >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From aa at alstonnetworks.net Wed Mar 25 08:51:54 2026 From: aa at alstonnetworks.net (Andrew Alston) Date: Wed, 25 Mar 2026 11:51:54 +0300 Subject: [rpd] =?utf-8?q?=5BQUIP=5D_A_new_federated_identity_and_interacti?= =?utf-8?q?on_layer_over_QUIC_=E2=80=93_seeking_engagement_with_the?= =?utf-8?q?_AFRINIC_community?= In-Reply-To: References: Message-ID: Hi Junior, As a matter of interest, have you raised this in the IETF. It would be far easier to get backing for a new protocol if the IETF agrees that constructing one is worthwhile and you achieve consensus there first. I suggest writing an initial RFC draft and then submitting it to gen-dispatch, where they can decide if the IETF can support this and which working group it belongs in. I'd be happy to work with you on the process (and potentially even a protocol draft) if that would assist. Thanks Andrew On Tue, Mar 24, 2026 at 10:01?PM Junior wrote: > Dear AFRINIC RPD list members, > > My name is Junior Joseph Mututi, and I?ve been working on a new protocol > called QUIP (QUIC Identity Protocol). QUIP is designed as an open, > federated identity and interaction layer built entirely on QUIC (RFC 9000). > It combines the domain-based addressing of XMPP, the vocabulary of > ActivityStreams, and a novel trust model where ISPs act as neutral trust > anchors ? verifying user identities without owning them. > > The protocol?s whitepaper (attached) details its architecture: a generic > state machine over QUIC, ISP?based attestation, a distributed CA > foundation, end?to?end encryption extensions, and built?in federation > mechanics. It is meant to run in parallel with the existing web and to give > ISPs a direct role in enabling secure, privacy?respecting communication for > their subscribers. > > I?m reaching out to the AFRINIC community because Africa is a key region > for QUIP?s vision. The whitepaper notes (Section 13.3.1) that Africa?s ISP > landscape ? with its growing number of operators, mobile?first > connectivity, and strong data sovereignty concerns ? is a natural early > adopter. I?d like to present QUIP at an upcoming AFRINIC meeting (e.g., > AFRINIC?OPEN) to get feedback from network engineers, policy makers, and > the ISP community. > > Specifically, I?d be grateful for: > > ? Guidance on how to propose a presentation or technical talk at an > AFRINIC meeting. > ? Feedback on the ISP trust model and its alignment with regional > regulatory frameworks. > ? Interest from ISPs willing to participate in a pilot deployment (the > whitepaper outlines a potential Zimbabwe pilot with ZISPA and POTRAZ). > > I welcome any questions or comments ? I?m happy to clarify technical > details or discuss how QUIP could fit into AFRINIC?s capacity?building and > infrastructure development goals. > > Thank you for your time, and I look forward to engaging with the community. > > Best regards, > Junior Joseph Mututi > WhatsApp/Calls: +27658095749/+27812629742 > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baya.sylvain at cmnog.cm Wed Mar 25 09:38:22 2026 From: baya.sylvain at cmnog.cm (Sylvain BAYA) Date: Wed, 25 Mar 2026 10:38:22 +0100 Subject: [rpd] =?utf-8?q?_=5BQUIP=5D_A_new_federated_identity_and_interact?= =?utf-8?q?ion_layer_over_QUIC_=E2=80=93_seeking_engagement_with_the_AFRIN?= =?utf-8?q?IC_community?= In-Reply-To: <246D73A0-E323-4F24-A08D-37FD86AD7572@consulintel.es> References: <7A322302-3C0A-4324-9685-1F2D52A0FCED@afrinic.net> <246D73A0-E323-4F24-A08D-37FD86AD7572@consulintel.es> Message-ID: <53E99F8B-4CBC-48D8-B98E-46258B4E64CF@cmnog.cm> Le 25 mars 2026 09:47:35 GMT+01:00, "jordi.palet--- via RPD" a ?crit?: >Fail to see the relation of this with PDP, and this list is only for PDP, nothing else. > Dear Junior, Do kindly consider to subscribe to the following more appropriate mailinglist; so that you can post your email out there. OIS-WG Info Page | Open Internet Standards Working Group (OIS-WG) - AFRINIC - Regional Internet Registry for Africa | Hope this helps! Shalom, --sb. > >Regards, >Jordi > >@jordipalet > > >> El 24 mar 2026, a las 20:31, Ben Roberts - AfriNIC via RPD escribi?: >> >> Junior, >> Thanks for this contribution. I confess I am at a complete loss to understand the white paper at all. I am relatively tech savvy and able to interpret standards etc, but I?m lost in so many words. I would suggest some diagrams might help to communicate the complex ideas that the paper is conveying. >> >> Kind regards >> Ben >> >> >> Sent from my iPhone >> >>> On 24 Mar 2026, at 22:02, Junior wrote: >>> >>> ? >>> Dear AFRINIC RPD list members, >>> >>> My name is Junior Joseph Mututi, and I?ve been working on a new protocol called QUIP (QUIC Identity Protocol). QUIP is designed as an open, federated identity and interaction layer built entirely on QUIC (RFC 9000). > [...] > -- Best Regards !? baya.sylvain [AT cmNOG DOT cm] |? cmNOG's Structure?|?Douala-IX's Looking Glass?|?CAMIX's Website?|? cmNOG's Surveys | Subscribe to?cmNOG's Mailing List?|? __ #LASAINTEBIBLE|#Eph?siens5:18,15-21?[...] 18 Et?ne vous enivrez?pas?de vin, en quoi?il y a de la dissolution; mais?soyez remplis de l'Esprit,?[...]? ? #LASAINTEBIBLE|#H?breux13:9,5-15?[...] 9?Ne soyez pas seduits par?des?doctrines diverses?et?etrangeres, car il est bon?que le coeur soit affermi par la grace, non par les viandes, lesquels n'ont pas profite ? ceux qui y ont marche. [...]? #AMEN,#Maranatha,#MerciJ?SUS! #?MaPri?re? est que tu naisses de nouveau.#Chr?tiennement From ben.roberts at afrinic.net Wed Mar 25 10:48:08 2026 From: ben.roberts at afrinic.net (Ben Roberts) Date: Wed, 25 Mar 2026 13:48:08 +0300 Subject: [rpd] =?utf-8?q?=5BQUIP=5D_A_new_federated_identity_and_interacti?= =?utf-8?q?on_layer_over_QUIC_=E2=80=93_seeking_engagement_with_the_AFRINI?= =?utf-8?q?C_community?= In-Reply-To: <246D73A0-E323-4F24-A08D-37FD86AD7572@consulintel.es> References: <7A322302-3C0A-4324-9685-1F2D52A0FCED@afrinic.net> <246D73A0-E323-4F24-A08D-37FD86AD7572@consulintel.es> Message-ID: <1C8227DD-58A3-447D-9C76-47D7BBF5215D@afrinic.net> Jordi, Let us use this space to encourage new participators and help them to nurture their ideas, rather than shutting them down. Regards Ben > On 25 Mar 2026, at 11:47, jordi.palet--- via RPD wrote: > > Fail to see the relation of this with PDP, and this list is only for PDP, nothing else. > > Regards, > Jordi > > @jordipalet > > >> El 24 mar 2026, a las 20:31, Ben Roberts - AfriNIC via RPD escribi?: >> >> Junior, >> Thanks for this contribution. I confess I am at a complete loss to understand the white paper at all. I am relatively tech savvy and able to interpret standards etc, but I?m lost in so many words. I would suggest some diagrams might help to communicate the complex ideas that the paper is conveying. >> >> Kind regards >> Ben >> >> >> Sent from my iPhone >> >>> On 24 Mar 2026, at 22:02, Junior wrote: >>> >>> ? >>> Dear AFRINIC RPD list members, >>> >>> My name is Junior Joseph Mututi, and I?ve been working on a new protocol called QUIP (QUIC Identity Protocol). QUIP is designed as an open, federated identity and interaction layer built entirely on QUIC (RFC 9000). It combines the domain-based addressing of XMPP, the vocabulary of ActivityStreams, and a novel trust model where ISPs act as neutral trust anchors ? verifying user identities without owning them. >>> >>> The protocol?s whitepaper (attached) details its architecture: a generic state machine over QUIC, ISP?based attestation, a distributed CA foundation, end?to?end encryption extensions, and built?in federation mechanics. It is meant to run in parallel with the existing web and to give ISPs a direct role in enabling secure, privacy?respecting communication for their subscribers. >>> >>> I?m reaching out to the AFRINIC community because Africa is a key region for QUIP?s vision. The whitepaper notes (Section 13.3.1) that Africa?s ISP landscape ? with its growing number of operators, mobile?first connectivity, and strong data sovereignty concerns ? is a natural early adopter. I?d like to present QUIP at an upcoming AFRINIC meeting (e.g., AFRINIC?OPEN) to get feedback from network engineers, policy makers, and the ISP community. >>> >>> Specifically, I?d be grateful for: >>> >>> ? Guidance on how to propose a presentation or technical talk at an AFRINIC meeting. >>> ? Feedback on the ISP trust model and its alignment with regional regulatory frameworks. >>> ? Interest from ISPs willing to participate in a pilot deployment (the whitepaper outlines a potential Zimbabwe pilot with ZISPA and POTRAZ). >>> >>> I welcome any questions or comments ? I?m happy to clarify technical details or discuss how QUIP could fit into AFRINIC?s capacity?building and infrastructure development goals. >>> >>> Thank you for your time, and I look forward to engaging with the community. >>> >>> Best regards, >>> Junior Joseph Mututi >>> WhatsApp/Calls: +27658095749/+27812629742 >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From jordi.palet at consulintel.es Wed Mar 25 11:19:15 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Wed, 25 Mar 2026 12:19:15 +0100 Subject: [rpd] =?utf-8?q?=5BQUIP=5D_A_new_federated_identity_and_interacti?= =?utf-8?q?on_layer_over_QUIC_=E2=80=93_seeking_engagement_with_the_AFRINI?= =?utf-8?q?C_community?= In-Reply-To: <1C8227DD-58A3-447D-9C76-47D7BBF5215D@afrinic.net> References: <7A322302-3C0A-4324-9685-1F2D52A0FCED@afrinic.net> <246D73A0-E323-4F24-A08D-37FD86AD7572@consulintel.es> <1C8227DD-58A3-447D-9C76-47D7BBF5215D@afrinic.net> Message-ID: Hi Ben, Sorry, can?t agree with you this time. Is not about turning down anyone. Is about respecting AUP on each mailing list. Each mailing list has a very specific scope, and this one, exactly the same as in other RIRs, is exclusively for policy discussions. Otherwise, we will have only a single mailing list for everything in each region. Allowing a single off-topic, will not allow later on to dismiss other off-topics as it will be discriminatory. Regards, Jordi @jordipalet > El 25 mar 2026, a las 11:48, Ben Roberts escribi?: > > Jordi, > Let us use this space to encourage new participators and help them to nurture their ideas, rather than shutting them down. > > Regards > > Ben > >> On 25 Mar 2026, at 11:47, jordi.palet--- via RPD wrote: >> >> Fail to see the relation of this with PDP, and this list is only for PDP, nothing else. >> >> Regards, >> Jordi >> >> @jordipalet >> >> >>> El 24 mar 2026, a las 20:31, Ben Roberts - AfriNIC via RPD escribi?: >>> >>> Junior, >>> Thanks for this contribution. I confess I am at a complete loss to understand the white paper at all. I am relatively tech savvy and able to interpret standards etc, but I?m lost in so many words. I would suggest some diagrams might help to communicate the complex ideas that the paper is conveying. >>> >>> Kind regards >>> Ben >>> >>> >>> Sent from my iPhone >>> >>>> On 24 Mar 2026, at 22:02, Junior wrote: >>>> >>>> ? >>>> Dear AFRINIC RPD list members, >>>> >>>> My name is Junior Joseph Mututi, and I?ve been working on a new protocol called QUIP (QUIC Identity Protocol). QUIP is designed as an open, federated identity and interaction layer built entirely on QUIC (RFC 9000). It combines the domain-based addressing of XMPP, the vocabulary of ActivityStreams, and a novel trust model where ISPs act as neutral trust anchors ? verifying user identities without owning them. >>>> >>>> The protocol?s whitepaper (attached) details its architecture: a generic state machine over QUIC, ISP?based attestation, a distributed CA foundation, end?to?end encryption extensions, and built?in federation mechanics. It is meant to run in parallel with the existing web and to give ISPs a direct role in enabling secure, privacy?respecting communication for their subscribers. >>>> >>>> I?m reaching out to the AFRINIC community because Africa is a key region for QUIP?s vision. The whitepaper notes (Section 13.3.1) that Africa?s ISP landscape ? with its growing number of operators, mobile?first connectivity, and strong data sovereignty concerns ? is a natural early adopter. I?d like to present QUIP at an upcoming AFRINIC meeting (e.g., AFRINIC?OPEN) to get feedback from network engineers, policy makers, and the ISP community. >>>> >>>> Specifically, I?d be grateful for: >>>> >>>> ? Guidance on how to propose a presentation or technical talk at an AFRINIC meeting. >>>> ? Feedback on the ISP trust model and its alignment with regional regulatory frameworks. >>>> ? Interest from ISPs willing to participate in a pilot deployment (the whitepaper outlines a potential Zimbabwe pilot with ZISPA and POTRAZ). >>>> >>>> I welcome any questions or comments ? I?m happy to clarify technical details or discuss how QUIP could fit into AFRINIC?s capacity?building and infrastructure development goals. >>>> >>>> Thank you for your time, and I look forward to engaging with the community. >>>> >>>> Best regards, >>>> Junior Joseph Mututi >>>> WhatsApp/Calls: +27658095749/+27812629742 >>>> >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jordi.palet at consulintel.es Wed Mar 25 11:58:51 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Wed, 25 Mar 2026 12:58:51 +0100 Subject: [rpd] Policy Compliance Dashboard - Not ratified by AFRINIC Board In-Reply-To: <21d0b0de-3268-40af-8bab-f8a8e84c4af0@afrinic.net> References: <21d0b0de-3268-40af-8bab-f8a8e84c4af0@afrinic.net> Message-ID: <7B86D275-6CA7-4978-8F71-E9B3AF7CC1EE@consulintel.es> Hi, I have major disagreements here. Speaking from myself, not for my co-authors. 1) In other regions, having a similar RSA, the board has ratified similar policies (for example, LACNIC). 2) It is common sense, that the rules must be applied the same to all the members, so setting in a policy those rules and timelines, has the effect not of encroaching anyone, but clearly defining rules in an open and transparent way. 3) The community has always the right to decide the way rules are to be implemented, what timelines, etc., even for failure to complain with policies, because is only up to the community the right to setup policies. Anyway, even with those disagreements in mind, we need to understand if the impact assessment will be positive if we remove this text: ?AFRINIC shall consider that a member is persisting in non-compliance in case more than 3 confirmed violations happen in a 12 months timeframe. This trigger will be reset once there are no policy violations after 12 months? Is acceptable to allow the member to resolve the issue as indicated in section 5 of the proposal, with a specific timeline and clearly defined steps, or is that also a problem? Or there is anything else that will still be a problem with the current text of the proposal? We need to understand that, to avoid wasting time the authors and the community, in new versions that still may not be resolving the issues of the Regards, Jordi @jordipalet > El 23 mar 2026, a las 19:29, AFRINIC Policy Liaison via RPD escribi?: > > Dear Policy Authors, > > We wish to inform you that the AFRINIC Board has not ratified your policy proposal, Policy Compliance Dashboard ID AFPUB-2021-GEN-003-DRAFT02. > > This decision was made due to the proposal's potential impact on AFRINIC?s contract management of the Registration Service Agreement (RSA), as highlighted in the legal impact assessment of the proposal. > As a result, the proposal will be sent back to the RPD mailing list, where it is foreseen to expire in accordance with the Consolidated Policy Manual. > > Should you wish to continue with this proposal, we recommend that you: > Consider the impact assessment provided: Impact Assessment . > Amend the proposal as required, with a focus on Sections 4, 5, and 6. > Submit the new proposal for discussion. > > While the AFRINIC Board has not yet called for a Public Policy Meeting, you have ample time to make refinements and request us, the Policy Liaisons, for support in drafting the proposal. > > Thank you for your continuous contribution to the AFRINIC PDP. > > Sincerely > > -- > AFRINIC Policy Liaison. > t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net > facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd Saludos, Jordi @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jjmututicloud at gmail.com Thu Mar 26 01:24:30 2026 From: jjmututicloud at gmail.com (Junior) Date: Thu, 26 Mar 2026 03:24:30 +0200 Subject: [rpd] =?utf-8?q?RPD_Digest=2C_Vol_218=2C_Issue_7_=3D=3E_QUIP_?= =?utf-8?b?4oCTIGZvbGxvd+KAkXVwIGFuZCBtb3ZpbmcgdG8gT0lT4oCRV0c=?= In-Reply-To: References: Message-ID: Dear colleagues, Thank you for the feedback on my QUIP white paper. I apologise for posting to the RPD list ? I now understand that it is reserved for PDP matters. I have subscribed to the OIS?WG list, which is the appropriate forum for standards discussions, and will continue there. Several of you asked for more concrete technical detail and diagrams. The white paper is a strategic overview; the companion technical specification (separate document) contains the full wire format, state machine definitions, and Protocol Buffers schemas. I also have a reference implementation in progress. To keep the RPD list on?topic, I won?t post diagrams or lengthy technical details here. Instead, I invite anyone interested in the protocol to: ? Continue the discussion on the OIS?WG list (I will start a new thread there), ? Or contact me directly at jjmututicloud at gmail.com ? I am happy to share the technical specification, architecture diagrams, and discuss implementation details. I also want to thank Andrew for the offer to help prepare an IETF Internet?Draft. That is the next logical step, and I?ll follow up with him on that. I look forward to engaging with the community on OIS?WG and, hopefully, presenting QUIP at a future AFRINIC meeting. Best regards, Junior Joseph Mututi On Wed, 25 Mar 2026, 13:59 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. [QUIP] A new federated identity and interaction layer over > QUIC ? seeking engagement with the AFRINIC community (Sylvain BAYA) > 2. Re: [QUIP] A new federated identity and interaction layer > over QUIC ? seeking engagement with the AFRINIC community > (Ben Roberts) > 3. Re: [QUIP] A new federated identity and interaction layer > over QUIC ? seeking engagement with the AFRINIC community > (jordi.palet at consulintel.es) > 4. Re: Policy Compliance Dashboard - Not ratified by AFRINIC > Board (jordi.palet at consulintel.es) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 25 Mar 2026 10:38:22 +0100 > From: Sylvain BAYA > To: Junior , AfriNIC Resource Policy > Developement ML > Cc: rpd at afrinic.net > Subject: [rpd] [QUIP] A new federated identity and interaction layer > over QUIC ? seeking engagement with the AFRINIC community > Message-ID: <53E99F8B-4CBC-48D8-B98E-46258B4E64CF at cmnog.cm> > Content-Type: text/plain; charset=utf-8 > > Le 25 mars 2026 09:47:35 GMT+01:00, "jordi.palet--- via RPD" < > rpd at afrinic.net> a ?crit?: > >Fail to see the relation of this with PDP, and this list is only for PDP, > nothing else. > > > > Dear Junior, > > Do kindly consider to subscribe to the > following more appropriate mailinglist; > so that you can post your email out there. > > OIS-WG Info Page | > > Open Internet Standards Working Group (OIS-WG) - AFRINIC - Regional > Internet Registry for Africa | < > https://afrinic.net/open-internet-standards-working-group> > > Hope this helps! > > Shalom, > --sb. > > > > > >Regards, > >Jordi > > > >@jordipalet > > > > > >> El 24 mar 2026, a las 20:31, Ben Roberts - AfriNIC via RPD < > rpd at afrinic.net> escribi?: > >> > >> Junior, > >> Thanks for this contribution. I confess I am at a complete loss to > understand the white paper at all. I am relatively tech savvy and able to > interpret standards etc, but I?m lost in so many words. I would suggest > some diagrams might help to communicate the complex ideas that the paper is > conveying. > >> > >> Kind regards > >> Ben > >> > >> > >> Sent from my iPhone > >> > >>> On 24 Mar 2026, at 22:02, Junior wrote: > >>> > >>> ? > >>> Dear AFRINIC RPD list members, > >>> > >>> My name is Junior Joseph Mututi, and I?ve been working on a new > protocol called QUIP (QUIC Identity Protocol). QUIP is designed as an open, > federated identity and interaction layer built entirely on QUIC (RFC 9000). > > [...] > > > > -- > > Best Regards !? > > baya.sylvain [AT cmNOG DOT cm] |? > cmNOG's Structure?|?Douala-IX's Looking Glass?|?CAMIX's Website?|? > cmNOG's Surveys | Subscribe to?cmNOG's Mailing List?|? > __ > #LASAINTEBIBLE|#Eph?siens5:18,15-21?[...] 18 Et?ne vous enivrez?pas?de > vin, en quoi?il y a de la dissolution; mais?soyez remplis de > l'Esprit,?[...]? ? > #LASAINTEBIBLE|#H?breux13:9,5-15?[...] 9?Ne soyez pas seduits > par?des?doctrines diverses?et?etrangeres, car il est bon?que le coeur soit > affermi par la grace, non par les viandes, lesquels n'ont pas profite ? > ceux qui y ont marche. [...]? > #AMEN,#Maranatha,#MerciJ?SUS! #?MaPri?re? est que tu naisses de > nouveau.#Chr?tiennement > > > > > ------------------------------ > > Message: 2 > Date: Wed, 25 Mar 2026 13:48:08 +0300 > From: Ben Roberts > To: "jordi.palet at consulintel.es" > Cc: rpd at afrinic.net > Subject: Re: [rpd] [QUIP] A new federated identity and interaction > layer over QUIC ? seeking engagement with the AFRINIC community > Message-ID: <1C8227DD-58A3-447D-9C76-47D7BBF5215D at afrinic.net> > Content-Type: text/plain; charset=utf-8 > > Jordi, > Let us use this space to encourage new participators and help them to > nurture their ideas, rather than shutting them down. > > Regards > > Ben > > > On 25 Mar 2026, at 11:47, jordi.palet--- via RPD > wrote: > > > > Fail to see the relation of this with PDP, and this list is only for > PDP, nothing else. > > > > Regards, > > Jordi > > > > @jordipalet > > > > > >> El 24 mar 2026, a las 20:31, Ben Roberts - AfriNIC via RPD < > rpd at afrinic.net> escribi?: > >> > >> Junior, > >> Thanks for this contribution. I confess I am at a complete loss to > understand the white paper at all. I am relatively tech savvy and able to > interpret standards etc, but I?m lost in so many words. I would suggest > some diagrams might help to communicate the complex ideas that the paper is > conveying. > >> > >> Kind regards > >> Ben > >> > >> > >> Sent from my iPhone > >> > >>> On 24 Mar 2026, at 22:02, Junior wrote: > >>> > >>> ? > >>> Dear AFRINIC RPD list members, > >>> > >>> My name is Junior Joseph Mututi, and I?ve been working on a new > protocol called QUIP (QUIC Identity Protocol). QUIP is designed as an open, > federated identity and interaction layer built entirely on QUIC (RFC 9000). > It combines the domain-based addressing of XMPP, the vocabulary of > ActivityStreams, and a novel trust model where ISPs act as neutral trust > anchors ? verifying user identities without owning them. > >>> > >>> The protocol?s whitepaper (attached) details its architecture: a > generic state machine over QUIC, ISP?based attestation, a distributed CA > foundation, end?to?end encryption extensions, and built?in federation > mechanics. It is meant to run in parallel with the existing web and to give > ISPs a direct role in enabling secure, privacy?respecting communication for > their subscribers. > >>> > >>> I?m reaching out to the AFRINIC community because Africa is a key > region for QUIP?s vision. The whitepaper notes (Section 13.3.1) that > Africa?s ISP landscape ? with its growing number of operators, mobile?first > connectivity, and strong data sovereignty concerns ? is a natural early > adopter. I?d like to present QUIP at an upcoming AFRINIC meeting (e.g., > AFRINIC?OPEN) to get feedback from network engineers, policy makers, and > the ISP community. > >>> > >>> Specifically, I?d be grateful for: > >>> > >>> ? Guidance on how to propose a presentation or technical talk at an > AFRINIC meeting. > >>> ? Feedback on the ISP trust model and its alignment with regional > regulatory frameworks. > >>> ? Interest from ISPs willing to participate in a pilot deployment (the > whitepaper outlines a potential Zimbabwe pilot with ZISPA and POTRAZ). > >>> > >>> I welcome any questions or comments ? I?m happy to clarify technical > details or discuss how QUIP could fit into AFRINIC?s capacity?building and > infrastructure development goals. > >>> > >>> Thank you for your time, and I look forward to engaging with the > community. > >>> > >>> Best regards, > >>> Junior Joseph Mututi > >>> WhatsApp/Calls: +27658095749/+27812629742 > >>> > >>> > >>> _______________________________________________ > >>> RPD mailing list > >>> RPD at afrinic.net > >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.theipv6company.com > > The IPv6 Company > > > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > > > > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > ------------------------------ > > Message: 3 > Date: Wed, 25 Mar 2026 12:19:15 +0100 > From: "jordi.palet at consulintel.es" > To: rpd at afrinic.net > Subject: Re: [rpd] [QUIP] A new federated identity and interaction > layer over QUIC ? seeking engagement with the AFRINIC community > Message-ID: > Content-Type: text/plain; charset=utf-8 > > Hi Ben, > > Sorry, can?t agree with you this time. Is not about turning down anyone. > Is about respecting AUP on each mailing list. Each mailing list has a very > specific scope, and this one, exactly the same as in other RIRs, is > exclusively for policy discussions. Otherwise, we will have only a single > mailing list for everything in each region. > > Allowing a single off-topic, will not allow later on to dismiss other > off-topics as it will be discriminatory. > > Regards, > Jordi > > @jordipalet > > > > El 25 mar 2026, a las 11:48, Ben Roberts > escribi?: > > > > Jordi, > > Let us use this space to encourage new participators and help them to > nurture their ideas, rather than shutting them down. > > > > Regards > > > > Ben > > > >> On 25 Mar 2026, at 11:47, jordi.palet--- via RPD > wrote: > >> > >> Fail to see the relation of this with PDP, and this list is only for > PDP, nothing else. > >> > >> Regards, > >> Jordi > >> > >> @jordipalet > >> > >> > >>> El 24 mar 2026, a las 20:31, Ben Roberts - AfriNIC via RPD < > rpd at afrinic.net> escribi?: > >>> > >>> Junior, > >>> Thanks for this contribution. I confess I am at a complete loss to > understand the white paper at all. I am relatively tech savvy and able to > interpret standards etc, but I?m lost in so many words. I would suggest > some diagrams might help to communicate the complex ideas that the paper is > conveying. > >>> > >>> Kind regards > >>> Ben > >>> > >>> > >>> Sent from my iPhone > >>> > >>>> On 24 Mar 2026, at 22:02, Junior wrote: > >>>> > >>>> ? > >>>> Dear AFRINIC RPD list members, > >>>> > >>>> My name is Junior Joseph Mututi, and I?ve been working on a new > protocol called QUIP (QUIC Identity Protocol). QUIP is designed as an open, > federated identity and interaction layer built entirely on QUIC (RFC 9000). > It combines the domain-based addressing of XMPP, the vocabulary of > ActivityStreams, and a novel trust model where ISPs act as neutral trust > anchors ? verifying user identities without owning them. > >>>> > >>>> The protocol?s whitepaper (attached) details its architecture: a > generic state machine over QUIC, ISP?based attestation, a distributed CA > foundation, end?to?end encryption extensions, and built?in federation > mechanics. It is meant to run in parallel with the existing web and to give > ISPs a direct role in enabling secure, privacy?respecting communication for > their subscribers. > >>>> > >>>> I?m reaching out to the AFRINIC community because Africa is a key > region for QUIP?s vision. The whitepaper notes (Section 13.3.1) that > Africa?s ISP landscape ? with its growing number of operators, mobile?first > connectivity, and strong data sovereignty concerns ? is a natural early > adopter. I?d like to present QUIP at an upcoming AFRINIC meeting (e.g., > AFRINIC?OPEN) to get feedback from network engineers, policy makers, and > the ISP community. > >>>> > >>>> Specifically, I?d be grateful for: > >>>> > >>>> ? Guidance on how to propose a presentation or technical talk at an > AFRINIC meeting. > >>>> ? Feedback on the ISP trust model and its alignment with regional > regulatory frameworks. > >>>> ? Interest from ISPs willing to participate in a pilot deployment > (the whitepaper outlines a potential Zimbabwe pilot with ZISPA and POTRAZ). > >>>> > >>>> I welcome any questions or comments ? I?m happy to clarify technical > details or discuss how QUIP could fit into AFRINIC?s capacity?building and > infrastructure development goals. > >>>> > >>>> Thank you for your time, and I look forward to engaging with the > community. > >>>> > >>>> Best regards, > >>>> Junior Joseph Mututi > >>>> WhatsApp/Calls: +27658095749/+27812629742 > >>>> > >>>> > >>>> _______________________________________________ > >>>> RPD mailing list > >>>> RPD at afrinic.net > >>>> https://lists.afrinic.net/mailman/listinfo/rpd > >>> > >>> _______________________________________________ > >>> RPD mailing list > >>> RPD at afrinic.net > >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> > >> > >> ********************************************** > >> IPv4 is over > >> Are you ready for the new Internet ? > >> http://www.theipv6company.com > >> The IPv6 Company > >> > >> This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > >> > >> > >> > >> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > > > > ------------------------------ > > Message: 4 > Date: Wed, 25 Mar 2026 12:58:51 +0100 > From: "jordi.palet at consulintel.es" > To: "rpd >> AfriNIC Resource Policy" > Subject: Re: [rpd] Policy Compliance Dashboard - Not ratified by > AFRINIC Board > Message-ID: <7B86D275-6CA7-4978-8F71-E9B3AF7CC1EE at consulintel.es> > Content-Type: text/plain; charset="utf-8" > > Hi, > > I have major disagreements here. Speaking from myself, not for my > co-authors. > > 1) In other regions, having a similar RSA, the board has ratified similar > policies (for example, LACNIC). > > 2) It is common sense, that the rules must be applied the same to all the > members, so setting in a policy those rules and timelines, has the effect > not of encroaching anyone, but clearly defining rules in an open and > transparent way. > > 3) The community has always the right to decide the way rules are to be > implemented, what timelines, etc., even for failure to complain with > policies, because is only up to the community the right to setup policies. > > Anyway, even with those disagreements in mind, we need to understand if > the impact assessment will be positive if we remove this text: > ?AFRINIC shall consider that a member is persisting in non-compliance in > case more than 3 confirmed violations happen in a 12 months timeframe. This > trigger will be reset once there are no policy violations after 12 months? > > Is acceptable to allow the member to resolve the issue as indicated in > section 5 of the proposal, with a specific timeline and clearly defined > steps, or is that also a problem? > > Or there is anything else that will still be a problem with the current > text of the proposal? > > We need to understand that, to avoid wasting time the authors and the > community, in new versions that still may not be resolving the issues of > the > > Regards, > Jordi > > @jordipalet > > > > El 23 mar 2026, a las 19:29, AFRINIC Policy Liaison via RPD < > rpd at afrinic.net> escribi?: > > > > Dear Policy Authors, > > > > We wish to inform you that the AFRINIC Board has not ratified your > policy proposal, Policy Compliance Dashboard ID AFPUB-2021-GEN-003-DRAFT02. > > > > This decision was made due to the proposal's potential impact on > AFRINIC?s contract management of the Registration Service Agreement (RSA), > as highlighted in the legal impact assessment of the proposal. > > As a result, the proposal will be sent back to the RPD mailing list, > where it is foreseen to expire in accordance with the Consolidated Policy > Manual. > > > > Should you wish to continue with this proposal, we recommend that you: > > Consider the impact assessment provided: Impact Assessment < > https://afrinic.net/policy/proposals/2021-gen-003-d2#impact>. > > Amend the proposal as required, with a focus on Sections 4, 5, and 6. > > Submit the new proposal for discussion. > > > > While the AFRINIC Board has not yet called for a Public Policy Meeting, > you have ample time to make refinements and request us, the Policy > Liaisons, for support in drafting the proposal. > > > > Thank you for your continuous contribution to the AFRINIC PDP. > > > > Sincerely > > > > -- > > AFRINIC Policy Liaison. > > t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net > > facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > Saludos, > Jordi > > @jordipalet > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260325/ed180989/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 218, Issue 7 > *********************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From baya.sylvain at cmnog.cm Thu Mar 26 11:46:51 2026 From: baya.sylvain at cmnog.cm (Sylvain BAYA) Date: Thu, 26 Mar 2026 12:46:51 +0100 Subject: [rpd] =?utf-8?b?W29mZi10b3BpY10gUVVJUCDigJMgZm9sbG934oCRdXAgYW5k?= =?utf-8?q?_moving_to_OIS=E2=80=91WG=2E?= In-Reply-To: References: Message-ID: <6DE20A26-A93D-4FE2-ADF0-0C03824417B0@cmnog.cm> {??off-topic! please, don't read!} Le 26 mars 2026 02:24:30 GMT+01:00, Junior a ?crit?: >Dear colleagues, > >Thank you for the feedback on my QUIP white paper. I apologise for posting >to the RPD list ? I now understand that it is reserved for PDP matters. I >have subscribed to the OIS?WG list, which is the appropriate forum for >standards discussions, and will continue there. > Hi Junior, Many thanks for this email, brother! ;-) ...i can reveal to you that having read this email encouraged me to want to read you paper. But, no quick promise, though :-) Hope you would also participate to the on-topic discussions within this Policy Development Working Group (PDWG) ;-) > > [...] > >I also want to thank Andrew for the offer to help prepare an IETF >Internet?Draft. That is the next logical step, and I?ll follow up with him >on that. > Andrew, here is *the opportunity*, imho; brother ;-) If it starts here [1,2], some of us would maybe learn the process by doing; with African IETF actual participants support, mentorship and assistance...then, who know: start to actively participate to IETF and other OpenStand [3] activities. __ [1]: please join the OIS-WG if interested [2]: [3]: Shalom, --sb. > >I look forward to engaging with the community on OIS?WG and, hopefully, >presenting QUIP at a future AFRINIC meeting. > >Best regards, >Junior Joseph Mututi > >On Wed, 25 Mar 2026, 13:59 , wrote: > >> >>> >>>>[...] >>> >> > -- Best Regards !? baya.sylvain [AT cmNOG DOT cm] |? cmNOG's Structure?|?Douala-IX's Looking Glass?|?CAMIX's Website?|? cmNOG's Surveys | Subscribe to?cmNOG's Mailing List?|? __ #LASAINTEBIBLE|#Eph?siens5:18,15-21?[...] 18 Et?ne vous enivrez?pas?de vin, en quoi?il y a de la dissolution; mais?soyez remplis de l'Esprit,?[...]? ? #LASAINTEBIBLE|#H?breux13:9,5-15?[...] 9?Ne soyez pas seduits par?des?doctrines diverses?et?etrangeres, car il est bon?que le coeur soit affermi par la grace, non par les viandes, lesquels n'ont pas profite ? ceux qui y ont marche. [...]? #AMEN,#Maranatha,#MerciJ?SUS! #?MaPri?re? est que tu naisses de nouveau.#Chr?tiennement -------------- next part -------------- An HTML attachment was scrubbed... URL: From comms at afrinic.net Wed Apr 1 09:41:07 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Wed, 1 Apr 2026 13:41:07 +0400 Subject: [rpd] Appointment of the Nomination Committee Message-ID: <8DF09DA1-9CF0-48CE-BAE3-7BADE02C5671@afrinic.net> ??Dear AFRINIC community, The AFRINIC Board is pleased to announce the appointment of the Nomination Committee (NomCom) for the upcoming 2026 elections: Three (3) Members of the Governance Committee elected by AFRINIC Resource Members in good standing. Two (2) Members of the NRO NC / ASO AC elected by the AFRINIC community. Two (2) PDP Co-Chairs selected through a consensus-based process by the AFRINIC Policy Development Working Group Please read the Election Guidelines 2026 for guidance and clarification on the election process. (https://elections.afrinic.net/election-guideline-2026) The Nomination Committee has been constituted in accordance with the provisions of Article 9 of the AFRINIC Constitution. The members of the Nomination Committee are as follows: Ms Prichard Chakadenga Mr Solomon Dindi Mr Ganesh Ramalingum Mr Ikibah Ebi. Benjamin The Board has full confidence in the Nomination Committee to discharge its responsibilities with impartiality, diligence, and the highest standards of integrity, and extends its sincere appreciation to the committee members for their willingness to serve the AFRINIC community. Prof. Adewale Adedokun Chairman, AFRINIC Board of Directors ???????. [fran?ais] Ch?re communaut? AFRINIC, Le Conseil d?administration d?AFRINIC a le plaisir d?annoncer la nomination du Comit? de nomination (NomCom) pour les ?lections de 2026 suivantes: ? Trois (3) membres du Comit? de gouvernance ?lus par les membres ressources d?AFRINIC en r?gle. ? Deux (2) membres du NRO NC / ASO AC ?lus par la communaut? AFRINIC. ? Deux (2) copr?sidents du PDP s?lectionn?s par un processus fond? sur le consensus par le Groupe de travail sur le d?veloppement des politiques d?AFRINIC. Nous vous invitons ? lire le Guide des ?lections 2026 pour plus d'informations sur le processus ?lectoral. (https://elections.afrinic.net/election-guideline-2026) Le Comit? de nomination a ?t? constitu? conform?ment aux dispositions de l?Article 9 de la Constitution d?AFRINIC. Les membres du Comit? de nomination sont les suivants : Mme Prichard Chakadenga M. Solomon Dindi M. Ganesh Ramalingum M. Ikibah Ebi Benjamin Le Conseil d?administration accorde toute sa confiance au Comit? de nomination pour s?acquitter de ses responsabilit?s avec impartialit?, diligence et selon les plus hautes exigences d?int?grit?. Il adresse ?galement ses sinc?res remerciements aux membres du comit? pour leur volont? de servir la communaut? AFRINIC. Prof. Adewale Adedokun Pr?sident du Conseil d?administration d?AFRINIC -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu Apr 9 12:36:10 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Thu, 9 Apr 2026 14:36:10 +0200 Subject: [rpd] Preparation for the Upcoming Public Policy Meeting in 2026 In-Reply-To: <9380fad9-e5dc-4453-a57a-39c87326be2a@afrinic.net> References: <9380fad9-e5dc-4453-a57a-39c87326be2a@afrinic.net> Message-ID: Hi all, Last December there was a Policy Implementation Experience Report (PIER) presentation (https://www.afrinic.net/media/attachments/2025/12/12/policy-implementation-experience---af36.pdf). I think we should move on and try to resolve the issues. In addition to that, looking at previous PIER presentations, it seems to me that other aspects also need a solution. I believe it will be good if the staff can make a short summary, possibly ordered in terms of what they believe is more urgent on top, of the different policy issues so the community can work on policy proposals to resolve them. I?m happy to work myself, hopefully together with other folks willing to co-author, in one or several proposals. In my opinion one of the key topics clearly is the update of the PDP itself, already working on that and happy to get other folks onboard. Regards, Jordi @jordipalet > El 24 feb 2026, a las 19:09, PDWG Chair escribi?: > > > Dear AFRINIC PDWG, > > We would like to welcome you to the new year. > > According to the Policy Development Process, policy changes are proposed by the Community. In anticipation of the upcoming Public Policy Meeting (PPM) in 2026, we kindly request that you commence the work on developing and submitting new Draft Policy Proposals (DPPs). > > No new policy proposals have been received since May 2022 and those proposals that were under discussion expired a calendar year after their submission. > > While the dates of the PPM are not yet known, to avoid a rush of last-minute submissions and to ensure that the problem statements are well defined, we encourage the authors: > (a) who withdrew their proposals ?PDP Working Group Guidelines and Procedures AFPUB-2020-GEN-002-DRAFT06? and ?Update of PDP AFPUB-2021-GEN-002-DRAFT03? to work together and propose a joint version that will address the implementation concerns. > (b) whose policies expired to submit a new version of their proposals if they wish their DPPs to run for consensus determination. > (c) to consider the past Policy Implementation Experience Reports and use the published issues as problem statements. > > All submitted proposals can be discussed on the RPD mailing list(rpd at afrinic.net ) as of now. Once the AFRINIC Secretariat announces the date on which the PPM will be held, we will communicate further on the timelines to be adhered to in accordance with Section 3 of the Consolidated Policy Manual for the proposals to go through the Policy Development Process for consensus determination. > > Your efforts are vital to the policy development process. > > Past webinars on the Policy Development Process are available for consultation here - https://www.afrinic.net/events/webinar-series. The PDWG may reach out to us in case they wish to discuss any new topic or a refresher. > > We look forward to your contributions in the coming months. > > Kind Regards, > > Dr. Vincent Ngundi and Darwin Da Costa > AFRINIC PDWG Co-Chairs > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From policy-liaison at afrinic.net Tue Apr 14 17:51:07 2026 From: policy-liaison at afrinic.net (Policy Liaison Team) Date: Tue, 14 Apr 2026 21:51:07 +0400 Subject: [rpd] Preparation for the Upcoming Public Policy Meeting in 2026 In-Reply-To: References: <9380fad9-e5dc-4453-a57a-39c87326be2a@afrinic.net> Message-ID: <141d644d-5ed8-4592-ba07-76de2364c8ec@afrinic.net> Dear Jordi/ AFRINIC PDWG Thank you for the request. We are currently preparing the summary & priority status of the issues, which will be posted on the AFRINIC website and this list. Kind Regards Madhvi & Brice Policy Liaison Team On 09/04/2026 16:36, jordi.palet--- via RPD wrote: > Hi all, > > Last December there was a Policy Implementation Experience Report > (PIER) presentation > (https://www.afrinic.net/media/attachments/2025/12/12/policy-implementation-experience---af36.pdf). > I think we should move on and try to resolve the issues. > > In addition to that, looking at previous PIER presentations, it seems > to me that other aspects also need a solution. > > I believe it will be good if the staff can make a short summary, > possibly ordered in terms of what they believe is more urgent on top, > of the different policy issues so the community can work on policy > proposals to resolve them. > > I?m happy to work myself, ?hopefully together with other folks willing > to co-author, in one or several proposals. > > In my opinion one of the key topics clearly is the update of the PDP > itself, already working on that and happy to get other folks onboard. > > Regards, > Jordi > > @jordipalet > > >> El 24 feb 2026, a las 19:09, PDWG Chair escribi?: >> >> >> Dear AFRINIC PDWG, >> >> We would like to welcome you to the new year. >> >> According to the Policy Development Process, policy changes are >> proposed by the Community.?In anticipation of the upcoming Public >> Policy Meeting (PPM) in 2026, we kindly request that you commence the >> work on developing and submitting new Draft Policy Proposals (DPPs). >> >> No new policy proposals have been received since May 2022 and those >> proposals that were under discussion expired a calendar year after >> their submission. >> >> While the dates of the PPM are not yet known, to avoid a rush of >> last-minute submissions and to ensure that the problem statements are >> well defined, we encourage the authors: >> (a)who withdrew their proposals ?PDP Working Group Guidelines and >> Procedures AFPUB-2020-GEN-002-DRAFT06? and ?Update of PDP >> AFPUB-2021-GEN-002-DRAFT03? to work together and propose a joint >> version that will address the implementation concerns. >> (b)whose policies expired tosubmit a new version of their proposals >> if they wish their DPPs to run for consensus determination. >> (c)to consider the past Policy Implementation Experience Reports >> ? anduse the >> published issues as problem statements. >> >> All submitted proposals can be discussed on the RPD mailing >> list(rpd at afrinic.net) as of now. Once the AFRINIC Secretariat >> announces the date on which the PPM will be held, we will communicate >> further on the timelines to be adhered to in accordance with Section >> 3 of the Consolidated Policy Manual? for the proposals to go through >> the Policy Development Process for consensus determination. >> >> Your efforts are vital to the policy development process. >> >> Past webinars on the Policy Development Process are available for >> consultation here -https://www.afrinic.net/events/webinar-series >> . The PDWG may reach >> out to us in case they wish to discuss any new topic or a refresher. >> >> We look forward to your contributions in the coming months. >> >> Kind Regards, >> >> Dr. Vincent Ngundi and Darwin Da Costa >> *AFRINIC PDWG Co-Chairs*** >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents of > this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If you > are not the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited, will be > considered a criminal offense, so you must reply to the original > sender to inform about this communication and delete it. > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -- AFRINIC Policy Liaison. t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia -------------- next part -------------- An HTML attachment was scrubbed... URL: From comms at afrinic.net Tue Apr 28 10:20:17 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Tue, 28 Apr 2026 14:20:17 +0400 Subject: [rpd] REMINDER: Invitation to Contribute to the AFRINIC Bylaws Review by 10th May 2026 Message-ID: Dear Colleagues, Following our announcement on 19th April 2026, the AFRINIC Bylaws Review Committee wishes to remind you that the community consultation on the review of the AFRINIC Bylaws remains open. As the Regional Internet Registry for Africa and the Indian Ocean region, AFRINIC?s governance framework underpins the stability and development of Africa's Internet infrastructure. It is therefore essential that our bylaws continue to be strong, transparent, and aligned with the evolving needs of our diverse community. Why Your Contribution Matters This review process is central to our commitment to accountability. By sharing your views, you contribute directly to strengthening governance and transparency, while helping ensure that the bylaws remain responsive to evolving operational realities and aligned with applicable legal and governance standards. How to Participate Submissions should be clear and concise. You may submit your feedback via the dedicated online form here . https://forms.afrinic.net/brc-comment Upcoming Milestones Following the closure of this initial window, the process will proceed according to the following indicative timeline: 11 May ? 25 May 2026: Committee Analysis & Clarifications. 26 May ? 15 June 2026: Drafting Phase One. 19 June 2026: Publication of Draft Bylaws Amendments. 22 June ? 26 June 2026: Presentation & Feedback during AIS?26. Submission Deadline The current Community Consultation Period is scheduled to conclude on 10 May 2026. We strongly encourage you to submit your comments, proposed amendments, and supporting rationales before this date to ensure they are included in the Committee?s forthcoming analysis. We thank you for your continued engagement and for contributing to the future of Internet governance in Africa. Kind Regards, AFRINIC Communications. ??????????????????????. Objet : RAPPEL ? Invitation ? contribuer ? la r?vision des Statuts d?AFRINIC avant le 10 mai 2026 Chers membres de la communaut?, Suite ? notre annonce du 19 avril 2026, le Comit? de r?vision des Statuts d?AFRINIC souhaite vous rappeler que la consultation communautaire sur la r?vision des Statuts d?AFRINIC est toujours ouverte. En tant que Registre Internet r?gional pour l?Afrique et la r?gion de l?oc?an Indien, le cadre de gouvernance d?AFRINIC constitue un pilier essentiel de la stabilit? et du d?veloppement de l?infrastructure Internet en Afrique. Il est donc primordial que nos statuts demeurent solides, transparents et align?s sur les besoins ?volutifs de notre communaut? diverse. Pourquoi votre contribution est importante Ce processus de r?vision est au c?ur de notre engagement en faveur de la redevabilit?. En partageant vos points de vue, vous contribuez directement au renforcement de la gouvernance et de la transparence, tout en veillant ? ce que les statuts restent adapt?s aux r?alit?s op?rationnelles en constante ?volution et conformes aux normes juridiques et de gouvernance applicables. Comment participer Les contributions doivent ?tre claires et concises. Vous pouvez soumettre vos commentaires via le formulaire en ligne d?di? ici https://forms.afrinic.net/brc-comment Prochaines ?tapes ? la cl?ture de cette premi?re phase, le processus se poursuivra selon le calendrier indicatif suivant : 11 mai ? 25 mai 2026 : Analyse par le Comit? et clarifications. 26 mai ? 15 juin 2026 : Phase de r?daction (phase 1). 19 juin 2026 : Publication du projet d?amendements des Statuts. 22 juin ? 26 juin 2026 : Pr?sentation et collecte de retours lors de l?AIS?26. Date limite de soumission La p?riode de consultation communautaire en cours prendra fin le 10 mai 2026. Nous vous encourageons vivement ? soumettre vos commentaires, propositions d?amendements et justifications avant cette date afin qu?ils soient pris en compte dans l?analyse ? venir du Comit?. Nous vous remercions de votre engagement sans faille et de votre contribution ? l'avenir de la gouvernance de l'Internet en Afrique. Cordialement AFRINIC Communications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From comms at afrinic.net Wed Apr 29 11:02:09 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Wed, 29 Apr 2026 15:02:09 +0400 Subject: [rpd] =?utf-8?q?Register_for_the__=E2=80=9CAFRINIC_Bylaws_Review_?= =?utf-8?q?-_Community_Engagement=E2=80=9D_Webinar=2C_4th_May_2026=2C_15?= =?utf-8?q?=3A00_UTC=2E?= Message-ID: [Version en fran?ais au bas] Dear Colleagues, As AFRINIC continues to strengthen transparency, accountability, and community-driven governance, the ongoing Bylaws Review process presents a critical opportunity for stakeholders to directly influence AFRINIC's future in the Community Consultation that closes on 10th May 2026. The AFRINIC Bylaws Review Committee is hosting a webinar to provide clarity, drive awareness, and encourage meaningful contributions to the process. Webinar Details Date: 4th May 2026 Time: 15:00 -16.00 UTC Register Here: https://us02web.zoom.us/webinar/register/6517773830151/WN_EIm8OC-2Q72X_w9bINz-hw The AFRINIC Bylaws are the foundation of how the AFRINIC is governed (from decision-making structures to member representation and accountability mechanisms) and any revisions in the bylaws will have lasting implications for the management of Internet number resources across Africa and the Indian Ocean region. Participants will have the opportunity to gain insights into the consultation process and seek clarifications directly from members of the Committee. The webinar is open to all stakeholders, including AFRINIC members and the wider Internet community. What you will gain from this session A clear understanding of the Bylaws Review process and why it matters. Practical guidance on how to submit informed and effective feedback. An opportunity to ask questions and engage directly with the process. The knowledge needed to confidently participate before the consultation deadline. We look forward to welcoming you. Kind Regards, AFRINIC Communications. ???????????????????????? Inscrivez-vous au webinaire ? AFRINIC Bylaws Review - Community Engagement?, le 4 mai 2026 ? 15 h 00 UTC. Chers coll?gues, Alors qu?AFRINIC continue de renforcer la transparence, la responsabilit? et une gouvernance port?e par la communaut?, le processus en cours de r?vision des statuts constitue une occasion cruciale pour les parties prenantes d?influencer directement l?avenir d?AFRINIC dans le cadre de la consultation communautaire qui se cl?turera le 10 mai 2026. Le comit? de r?vision des statuts d?AFRINIC organise un webinaire afin d?apporter des ?claircissements, de sensibiliser et d?encourager des contributions significatives ? ce processus. D?tails du webinaire Date : 4 mai 2026 Heure : 15.00-16.00 GMT Inscrivez-vous ici: https://us02web.zoom.us/webinar/register/6517773830151/WN_EIm8OC-2Q72X_w9bINz-hw Les statuts d?AFRINIC constituent la base de la gouvernance d?AFRINIC (des structures de prise de d?cision ? la repr?sentation des membres et aux m?canismes de responsabilit?), et toute r?vision de ces statuts aura des r?percussions durables sur la gestion des num?ros Internet ? travers l?Afrique et la r?gion de l?oc?an Indien. Les participants auront l?occasion d?obtenir des informations sur le processus de consultation et de poser directement leurs questions aux membres du comit?. Le webinaire est ouvert ? toutes les parties prenantes, y compris les membres d?AFRINIC et l?ensemble de la communaut? Internet. Ce que vous retirerez de cette session: Une compr?hension claire du processus de r?vision des statuts et de son importance. Des conseils pratiques sur la mani?re de soumettre des contributions ?clair?es et efficaces. Une occasion de poser des questions et d?interagir directement avec le processus. Les connaissances n?cessaires pour participer en toute confiance avant la date limite de la consultation. Nous nous r?jouissons de vous accueillir. Cordialement, AFRINIC Communications -------------- next part -------------- An HTML attachment was scrubbed... URL: From comms at afrinic.net Thu Apr 30 11:16:27 2026 From: comms at afrinic.net (comms at afrinic.net) Date: Thu, 30 Apr 2026 11:16:27 +0000 Subject: [rpd] AIS'23 Update Message-ID: [Apologies for cross-posting] [Version en fran?ais au bas] Dear Colleagues, The preparations for the Africa Internet Summit 2026 (AIS?26) are well underway. AIS?26 will be hosted in a hybrid format, welcoming participants onsite in Nairobi and virtually via Zoom. Full event details and updates are available on the AIS?26 website. Here are your AIS?26 Updates: Registration is Open Registration for both onsite and online participation is ongoing. We strongly encourage you to register early to confirm your attendance, whether in Nairobi or virtually, noting that we will not have any on-site registration. Register here. ________________________________ Call for Presentations We are still welcoming presentation abstracts for AIS?26, and this is your chance to be part of shaping the conversation. AIS?26 provides a platform for experts and innovators to share their knowledge, spark dialogue, and showcase practical solutions to some of Africa?s most pressing Internet challenges. By presenting at AIS?26, you will contribute to driving collaboration and inspiring the future of the Internet across the continent. Please take note of the important deadlines: * Deadline for submitting presentation abstracts: 24th May 2026 * Deadline for submission of draft presentations: 6th June 2026 * Submission of final presentations: 16th June 2026 We encourage you to seize this opportunity to take the stage at AIS?26 and share your expertise with a diverse and influential audience. Be part of AIS?26 as a speaker. ________________________________ Call for Sponsorship AIS?26 offers a powerful platform for brands, organizations, and innovators seeking to make an impact in Africa?s digital landscape. As a sponsor or partner, you will have the opportunity to: * Gain high-level visibility across Africa?s ICT and policy space. * Showcase your brand through dedicated sessions, exhibition booths, or side events. * Engage directly with government officials, academia, industry leaders, and civil society stakeholders. A range of sponsorship packages alongside the Sponsorship Brochure are available and we welcome discussions on tailored opportunities aligned to your organisation?s objectives. ________________________________ Travel Please note that some countries require visas to travel to Kenya. All Visa information is available Here. Book your accommodation at the event venue in the Accommodation section here.Those who wish to book their accommodation at the event venue are required to do so by 25th May 2026. Delegates are advised to book their airport transfers directly with their respective hotel. ________________________________ Updates and News You can keep informed with updates and the latest news about AIS?26 on the website. You can also follow us on twitter with the handle @AIS_Africa We are using the hashtag #AIS2026 For questions or assistance with logistics, feel free to reach us at: secretariat at internetsummit.africa Whether you?re a first-time attendee or a returning participant, we look forward to welcoming you to AIS?26 in Nairobi or connecting with you virtually. Karibu AIS?26! AIS?26 Secretariat. secretariat at internetsummit.africa ???????.. FR Cher(e)s D?l?gu?(e)s, Les pr?paratifs de la tenue de l'African Internet Summit 2026 (AIS?26) sont en cours. L?AIS?26 se tiendra en format hybride, avec des participants en pr?sentiel ? Nairobi et d?autres en ligne via Zoom. Les d?tails complets de l??v?nement ainsi que les mises ? jour de l?agenda sont disponibles sur le site web de l?AIS?26. Voici les derni?res informations concernant l?AIS?26: Les inscriptions sont toujours ouvertes Les inscriptions pour participer en pr?sentiel et en ligne sont en cours. Nous vous encourageons vivement ? vous inscrire massivement maintenant. Veuillez noter que les inscriptions ne seront pas possibles sur place lors de l?AIS?26. Appel ? pr?sentations Nous recevons encore les r?sum?s de pr?sentations pour l?AIS?26. Cette opportunit? vous permet de contribuer activement aux ?changes qui fa?onneront l?avenir de l?Internet en Afrique. L?AIS?26 r?unira des experts, innovateurs et acteurs cl?s du secteur afin de partager des connaissances, encourager le dialogue et pr?senter des solutions concr?tes aux principaux d?fis li?s au d?veloppement de l?Internet sur le continent. En prenant la parole lors de cet ?v?nement, vous contribuerez ? renforcer la collaboration et ? promouvoir des initiatives porteuses pour l??cosyst?me num?rique africain. Veuillez prendre note des ?ch?ances importantes suivantes : * Date limite de soumission des r?sum?s de pr?sentations : 24 mai 2026 * Date limite de soumission des projets de pr?sentations : 6 juin 2026 * Soumission des pr?sentations finales : 16 juin 2026 Veuillez vous inscrire ici comme orateur. Appel au sponsoring L?AIS?26 offre une plateforme strat?gique aux marques, organisations et innovateurs qui souhaitent avoir un impact dans l??cosyst?me num?rique africain. En tant que sponsor ou partenaire, vous aurez l?occasion de : * b?n?ficier d?une visibilit? de haut niveau dans l?espace africain des TIC et des politiques publiques ; * mettre en valeur votre marque ? travers des sessions d?di?es, des stands d?exposition ou des ?v?nements parall?les ; * ?changer directement avec des repr?sentants gouvernementaux, des universitaires, des leaders de l?industrie et des acteurs de la soci?t? civile. Plusieurs formules de sponsoring, ainsi que la brochure de sponsoring, sont disponibles. Nous restons ouverts ? des discussions sur des opportunit?s personnalis?es, align?es sur les objectifs de votre organisation. Voyage Toutes les informations relatives aux visas d'entr?e au Kenya sont disponibles ici. Pour la r?servation de votre h?bergement, veuillez vous rendre ici. Les personnes d?sireuses de s?journer sur le site de l??v?nement d?AIS?26 doivent le faire au plus tard le 25 mai 2026. Les d?l?gu?s sont invit?s ? organiser leurs transferts depuis l?a?roport directement aupr?s de leur h?tel respectif. Autres actualit?s Pour rester inform? des derni?res actualit?s et mises ? jour concernant l?AIS?26, veuillez consulter r?guli?rement le site web de l??v?nement. Vous pouvez ?galement suivre nos communications sur Twitter via le compte @AIS_Africa et utiliser le hashtag #AIS2026. Pour toute question ou demande d?assistance logistique, veuillez contacter le Secr?tariat de l?AIS?26 ? l?adresse suivante : secretariat at internetsummit.africa. Que vous soyez un nouveau participant ou un habitu? de l??v?nement, nous serons heureux de vous accueillir ? Nairobi ou de vous compter parmi les participants en ligne. Karibu AIS?26! Secr?tariat de l?AIS?26 secretariat at internetsummit.africa -------------- next part -------------- An HTML attachment was scrubbed... URL: From comms at afrinic.net Thu Apr 30 11:28:49 2026 From: comms at afrinic.net (comms at afrinic.net) Date: Thu, 30 Apr 2026 11:28:49 +0000 Subject: [rpd] AIS'26 Update In-Reply-To: References: Message-ID: **Erratum: AIS?26 Update. From: comms at afrinic.net Date: Thursday, 30 April 2026 at 14:16 To: Policy Liaison Team via RPD Subject: AIS'23 Update [Apologies for cross-posting] [Version en fran?ais au bas] Dear Colleagues, The preparations for the Africa Internet Summit 2026 (AIS?26) are well underway. AIS?26 will be hosted in a hybrid format, welcoming participants onsite in Nairobi and virtually via Zoom. Full event details and updates are available on the AIS?26 website. Here are your AIS?26 Updates: Registration is Open Registration for both onsite and online participation is ongoing. We strongly encourage you to register early to confirm your attendance, whether in Nairobi or virtually, noting that we will not have any on-site registration. Register here. ________________________________ Call for Presentations We are still welcoming presentation abstracts for AIS?26, and this is your chance to be part of shaping the conversation. AIS?26 provides a platform for experts and innovators to share their knowledge, spark dialogue, and showcase practical solutions to some of Africa?s most pressing Internet challenges. By presenting at AIS?26, you will contribute to driving collaboration and inspiring the future of the Internet across the continent. Please take note of the important deadlines: * Deadline for submitting presentation abstracts: 24th May 2026 * Deadline for submission of draft presentations: 6th June 2026 * Submission of final presentations: 16th June 2026 We encourage you to seize this opportunity to take the stage at AIS?26 and share your expertise with a diverse and influential audience. Be part of AIS?26 as a speaker. ________________________________ Call for Sponsorship AIS?26 offers a powerful platform for brands, organizations, and innovators seeking to make an impact in Africa?s digital landscape. As a sponsor or partner, you will have the opportunity to: * Gain high-level visibility across Africa?s ICT and policy space. * Showcase your brand through dedicated sessions, exhibition booths, or side events. * Engage directly with government officials, academia, industry leaders, and civil society stakeholders. A range of sponsorship packages alongside the Sponsorship Brochure are available and we welcome discussions on tailored opportunities aligned to your organisation?s objectives. ________________________________ Travel Please note that some countries require visas to travel to Kenya. All Visa information is available Here. Book your accommodation at the event venue in the Accommodation section here.Those who wish to book their accommodation at the event venue are required to do so by 25th May 2026. Delegates are advised to book their airport transfers directly with their respective hotel. ________________________________ Updates and News You can keep informed with updates and the latest news about AIS?26 on the website. You can also follow us on twitter with the handle @AIS_Africa We are using the hashtag #AIS2026 For questions or assistance with logistics, feel free to reach us at: secretariat at internetsummit.africa Whether you?re a first-time attendee or a returning participant, we look forward to welcoming you to AIS?26 in Nairobi or connecting with you virtually. Karibu AIS?26! AIS?26 Secretariat. secretariat at internetsummit.africa ???????.. FR Cher(e)s D?l?gu?(e)s, Les pr?paratifs de la tenue de l'African Internet Summit 2026 (AIS?26) sont en cours. L?AIS?26 se tiendra en format hybride, avec des participants en pr?sentiel ? Nairobi et d?autres en ligne via Zoom. Les d?tails complets de l??v?nement ainsi que les mises ? jour de l?agenda sont disponibles sur le site web de l?AIS?26. Voici les derni?res informations concernant l?AIS?26: Les inscriptions sont toujours ouvertes Les inscriptions pour participer en pr?sentiel et en ligne sont en cours. Nous vous encourageons vivement ? vous inscrire massivement maintenant. Veuillez noter que les inscriptions ne seront pas possibles sur place lors de l?AIS?26. Appel ? pr?sentations Nous recevons encore les r?sum?s de pr?sentations pour l?AIS?26. Cette opportunit? vous permet de contribuer activement aux ?changes qui fa?onneront l?avenir de l?Internet en Afrique. L?AIS?26 r?unira des experts, innovateurs et acteurs cl?s du secteur afin de partager des connaissances, encourager le dialogue et pr?senter des solutions concr?tes aux principaux d?fis li?s au d?veloppement de l?Internet sur le continent. En prenant la parole lors de cet ?v?nement, vous contribuerez ? renforcer la collaboration et ? promouvoir des initiatives porteuses pour l??cosyst?me num?rique africain. Veuillez prendre note des ?ch?ances importantes suivantes : * Date limite de soumission des r?sum?s de pr?sentations : 24 mai 2026 * Date limite de soumission des projets de pr?sentations : 6 juin 2026 * Soumission des pr?sentations finales : 16 juin 2026 Veuillez vous inscrire ici comme orateur. Appel au sponsoring L?AIS?26 offre une plateforme strat?gique aux marques, organisations et innovateurs qui souhaitent avoir un impact dans l??cosyst?me num?rique africain. En tant que sponsor ou partenaire, vous aurez l?occasion de : * b?n?ficier d?une visibilit? de haut niveau dans l?espace africain des TIC et des politiques publiques ; * mettre en valeur votre marque ? travers des sessions d?di?es, des stands d?exposition ou des ?v?nements parall?les ; * ?changer directement avec des repr?sentants gouvernementaux, des universitaires, des leaders de l?industrie et des acteurs de la soci?t? civile. Plusieurs formules de sponsoring, ainsi que la brochure de sponsoring, sont disponibles. Nous restons ouverts ? des discussions sur des opportunit?s personnalis?es, align?es sur les objectifs de votre organisation. Voyage Toutes les informations relatives aux visas d'entr?e au Kenya sont disponibles ici. Pour la r?servation de votre h?bergement, veuillez vous rendre ici. Les personnes d?sireuses de s?journer sur le site de l??v?nement d?AIS?26 doivent le faire au plus tard le 25 mai 2026. Les d?l?gu?s sont invit?s ? organiser leurs transferts depuis l?a?roport directement aupr?s de leur h?tel respectif. Autres actualit?s Pour rester inform? des derni?res actualit?s et mises ? jour concernant l?AIS?26, veuillez consulter r?guli?rement le site web de l??v?nement. Vous pouvez ?galement suivre nos communications sur Twitter via le compte @AIS_Africa et utiliser le hashtag #AIS2026. Pour toute question ou demande d?assistance logistique, veuillez contacter le Secr?tariat de l?AIS?26 ? l?adresse suivante : secretariat at internetsummit.africa. Que vous soyez un nouveau participant ou un habitu? de l??v?nement, nous serons heureux de vous accueillir ? Nairobi ou de vous compter parmi les participants en ligne. Karibu AIS?26! Secr?tariat de l?AIS?26 secretariat at internetsummit.africa -------------- next part -------------- An HTML attachment was scrubbed... URL: From dacostadarwin at gmail.com Tue May 5 11:21:48 2026 From: dacostadarwin at gmail.com (Darwin Da Costa) Date: Tue, 5 May 2026 08:21:48 -0300 Subject: [rpd] AFRINIC-37 Public Policy Meeting Timelines and Draft Agenda. Message-ID: <8C15EAC8-6E03-4FA1-AF79-6F8B44407CFD@gmail.com> Dear PDWG, The AFRINIC-37 Public Policy Meeting (PPM) will be held in hybrid format on 24 June 2026, with ~6 hrs allocated to the agenda. Registration for the meeting is already open at https://2026.internetsummit.africa/ . In case you are planning to participate during the PPM, please ensure that you register for the event before the registration closes. In preparation for this PPM, we have noted that as of 30 April 2026, there are no active policy proposals https://afrinic.net/policy/proposals/ . We therefore request the authors of forthcoming new policy proposals to ensure that their proposals have clear problem statements and the proposal text is aligned with the problem statements and to be proactive with their updates based on the discussions and contributions of the PDWG. Some timelines in compliance with the Section 3 of the Consolidated Policy Manual are as follows: New proposals can be submitted by 23h59 UTC, 26 May 2026. Updates to proposals can be submitted by 23h59 UTC, 17 June 2026 Final agenda to be communicated by 23h59 UTC, 18 June 2026 The draft agenda of the PPM is as follows ? 24 June 2026 (Time in Local time) 09:00 - 09:10 Overview of the logistics of the AFRINIC-37 PPM 09:10 - 09:15 Welcome, Introduction & Agenda Overview 09:15 - 09:40 The AFRINIC PDP & Building Consensus 09:40 - 09:50 Questions & Answers 10:00 - 10:15 TEA BREAK 10:15 - 13:15 Policy discussions 13:15 - 14:30 LUNCH BREAK 14:30 - 14:50 Policy Update from other regions 14:50 - 15:05 Policy Implementation Experience Report 15:05 - 15:20 Questions & Answers 15:20 - 15:35 PDWG Chair selection 15:35 - 15:55 Open Microphone 15:55 - 16:00 Close PPM 16:00 - 16:15 TEA BREAK 16:15 - 16:35 TBC 16:35 - 16:45 ASO-AC representatives election? 16:45 -17:00 Closing Remarks of the Day We look forward to having a healthy participation and contribution by the community in the AFRINIC Policy Development Process. Kind Regards, Vincent Ngundi & Darwin Da Costa AFRINIC PDWG Co-Chairs -------------- next part -------------- An HTML attachment was scrubbed... URL: From dacostadarwin at gmail.com Tue May 5 11:21:48 2026 From: dacostadarwin at gmail.com (Darwin Da Costa) Date: Tue, 5 May 2026 08:21:48 -0300 Subject: [rpd] AFRINIC-37 Public Policy Meeting Timelines and Draft Agenda. Message-ID: <8C15EAC8-6E03-4FA1-AF79-6F8B44407CFD@gmail.com> Dear PDWG, The AFRINIC-37 Public Policy Meeting (PPM) will be held in hybrid format on 24 June 2026, with ~6 hrs allocated to the agenda. Registration for the meeting is already open at https://2026.internetsummit.africa/ . In case you are planning to participate during the PPM, please ensure that you register for the event before the registration closes. In preparation for this PPM, we have noted that as of 30 April 2026, there are no active policy proposals https://afrinic.net/policy/proposals/ . We therefore request the authors of forthcoming new policy proposals to ensure that their proposals have clear problem statements and the proposal text is aligned with the problem statements and to be proactive with their updates based on the discussions and contributions of the PDWG. Some timelines in compliance with the Section 3 of the Consolidated Policy Manual are as follows: New proposals can be submitted by 23h59 UTC, 26 May 2026. Updates to proposals can be submitted by 23h59 UTC, 17 June 2026 Final agenda to be communicated by 23h59 UTC, 18 June 2026 The draft agenda of the PPM is as follows ? 24 June 2026 (Time in Local time) 09:00 - 09:10 Overview of the logistics of the AFRINIC-37 PPM 09:10 - 09:15 Welcome, Introduction & Agenda Overview 09:15 - 09:40 The AFRINIC PDP & Building Consensus 09:40 - 09:50 Questions & Answers 10:00 - 10:15 TEA BREAK 10:15 - 13:15 Policy discussions 13:15 - 14:30 LUNCH BREAK 14:30 - 14:50 Policy Update from other regions 14:50 - 15:05 Policy Implementation Experience Report 15:05 - 15:20 Questions & Answers 15:20 - 15:35 PDWG Chair selection 15:35 - 15:55 Open Microphone 15:55 - 16:00 Close PPM 16:00 - 16:15 TEA BREAK 16:15 - 16:35 TBC 16:35 - 16:45 ASO-AC representatives election? 16:45 -17:00 Closing Remarks of the Day We look forward to having a healthy participation and contribution by the community in the AFRINIC Policy Development Process. Kind Regards, Vincent Ngundi & Darwin Da Costa AFRINIC PDWG Co-Chairs -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Tue May 5 11:49:28 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Tue, 5 May 2026 13:49:28 +0200 Subject: [rpd] AFRINIC-37 Public Policy Meeting Timelines and Draft Agenda. In-Reply-To: <8C15EAC8-6E03-4FA1-AF79-6F8B44407CFD@gmail.com> References: <8C15EAC8-6E03-4FA1-AF79-6F8B44407CFD@gmail.com> Message-ID: Hi Darwin, A new version of "Policy Compliance Dashboard" - AFPUB-2021-GEN-003-DRAFT03 was submitted last week. Also, I was hoping that there is an update version of the implementation report from the staff, so we can see what are the most urgent topics that need some proposals (if any). I think it will be good to organize a webinar if this can be done quickly (even by end of this week already?), so there is sufficient time for a proposal, otherwise, just an email from the staff showing what issues they found, or an updated presentation from the last one, etc. Regards, Jordi @jordipalet > El 5 may 2026, a las 13:21, Darwin Da Costa escribi?: > > Dear PDWG, > > The AFRINIC-37 Public Policy Meeting (PPM) will be held in hybrid format on 24 June 2026, with ~6 hrs allocated to the agenda. Registration for the meeting is already open at https://2026.internetsummit.africa/ . In case you are planning to participate during the PPM, please ensure that you register for the event before the registration closes. > > In preparation for this PPM, we have noted that as of 30 April 2026, there are no active policy proposals https://afrinic.net/policy/proposals/ . > We therefore request the authors of forthcoming new policy proposals to ensure that their proposals have clear problem statements and the proposal text is aligned with the problem statements and to be proactive with their updates based on the discussions and contributions of the PDWG. > > Some timelines in compliance with the Section 3 of the Consolidated Policy Manual are as follows: > > New proposals can be submitted by 23h59 UTC, 26 May 2026. > Updates to proposals can be submitted by 23h59 UTC, 17 June 2026 > Final agenda to be communicated by 23h59 UTC, 18 June 2026 > > The draft agenda of the PPM is as follows ? > 24 June 2026 (Time in Local time) > 09:00 - 09:10 Overview of the logistics of the AFRINIC-37 PPM > 09:10 - 09:15 Welcome, Introduction & Agenda Overview > 09:15 - 09:40 The AFRINIC PDP & Building Consensus > 09:40 - 09:50 Questions & Answers > 10:00 - 10:15 TEA BREAK > 10:15 - 13:15 Policy discussions > 13:15 - 14:30 LUNCH BREAK > 14:30 - 14:50 Policy Update from other regions > 14:50 - 15:05 Policy Implementation Experience Report > 15:05 - 15:20 Questions & Answers > 15:20 - 15:35 PDWG Chair selection > 15:35 - 15:55 Open Microphone > 15:55 - 16:00 Close PPM > 16:00 - 16:15 TEA BREAK > 16:15 - 16:35 TBC > 16:35 - 16:45 ASO-AC representatives election? > 16:45 -17:00 Closing Remarks of the Day > > We look forward to having a healthy participation and contribution by the community in the AFRINIC Policy Development Process. > > Kind Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From policy-liaison at afrinic.net Tue May 5 11:58:49 2026 From: policy-liaison at afrinic.net (Policy Liaison Team) Date: Tue, 5 May 2026 15:58:49 +0400 Subject: [rpd] PIER Summary Message-ID: <606b6bec-cfc1-4445-8c9c-d46e6f4334e0@afrinic.net> Dear PDWG A summary of problem areas presented in past Policy Implementation Experience Reports has been published here - https://www.afrinic.net/policy/implementation-reports/pier-summary ?. Kind Regards Madhvi? & Brice Policy Liaison Team -- AFRINIC Policy Liaison. t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Tue May 5 12:26:36 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Tue, 5 May 2026 14:26:36 +0200 Subject: [rpd] PIER Summary In-Reply-To: <606b6bec-cfc1-4445-8c9c-d46e6f4334e0@afrinic.net> References: <606b6bec-cfc1-4445-8c9c-d46e6f4334e0@afrinic.net> Message-ID: <9003A4F6-E85A-428B-8860-54D2E81BD181@consulintel.es> Hi Madhvi, Brice, This is a perfect summary, tks a lot! Regards, Jordi @jordipalet > El 5 may 2026, a las 13:58, Policy Liaison Team via RPD escribi?: > > Dear PDWG > > A summary of problem areas presented in past Policy Implementation Experience Reports has been published here - https://www.afrinic.net/policy/implementation-reports/pier-summary? . > > Kind Regards > > Madhvi & Brice > > Policy Liaison Team > > -- > AFRINIC Policy Liaison. > t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net > facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbemiadepojuesho at gmail.com Tue May 5 12:45:20 2026 From: gbemiadepojuesho at gmail.com (Gbemisola Esho) Date: Tue, 5 May 2026 13:45:20 +0100 Subject: [rpd] PIER Summary In-Reply-To: <9003A4F6-E85A-428B-8860-54D2E81BD181@consulintel.es> References: <606b6bec-cfc1-4445-8c9c-d46e6f4334e0@afrinic.net> <9003A4F6-E85A-428B-8860-54D2E81BD181@consulintel.es> Message-ID: Thank you for this. Regards, Gbemisola Esho On Tue, 5 May 2026, 13:29 jordi.palet--- via RPD, wrote: > Hi Madhvi, Brice, > > This is a perfect summary, tks a lot! > > Regards, > Jordi > > @jordipalet > > > El 5 may 2026, a las 13:58, Policy Liaison Team via RPD > escribi?: > > Dear PDWG > > A summary of problem areas presented in past Policy Implementation > Experience Reports has been published here - > https://www.afrinic.net/policy/implementation-reports/pier-summary > . > > Kind Regards > > Madhvi & Brice > > Policy Liaison Team > > -- > AFRINIC Policy Liaison. > t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.netfacebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajumobinoah070 at gmail.com Wed May 6 13:29:35 2026 From: ajumobinoah070 at gmail.com (noah ajumobi) Date: Wed, 6 May 2026 14:29:35 +0100 Subject: [rpd] RPD Digest, Vol 220, Issue 3 In-Reply-To: References: Message-ID: Awesome ready to use IPV6 On Wed, May 6, 2026 at 1:00?PM wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: PIER Summary (jordi.palet at consulintel.es) > 2. Re: PIER Summary (Gbemisola Esho) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 5 May 2026 14:26:36 +0200 > From: "jordi.palet at consulintel.es" > To: policy-liaison at afrinic.net > Cc: rpd at afrinic.net > Subject: Re: [rpd] PIER Summary > Message-ID: <9003A4F6-E85A-428B-8860-54D2E81BD181 at consulintel.es> > Content-Type: text/plain; charset="utf-8" > > Hi Madhvi, Brice, > > This is a perfect summary, tks a lot! > > Regards, > Jordi > > @jordipalet > > > > El 5 may 2026, a las 13:58, Policy Liaison Team via RPD > escribi?: > > > > Dear PDWG > > > > A summary of problem areas presented in past Policy Implementation > Experience Reports has been published here - > https://www.afrinic.net/policy/implementation-reports/pier-summary? < > https://www.afrinic.net/policy/implementation-reports/pier-summary> . > > > > Kind Regards > > > > Madhvi & Brice > > > > Policy Liaison Team > > > > -- > > AFRINIC Policy Liaison. > > t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net > > facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260505/12998cdd/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Tue, 5 May 2026 13:45:20 +0100 > From: Gbemisola Esho > To: jordi.palet at consulintel.es > Cc: rpd at afrinic.net > Subject: Re: [rpd] PIER Summary > Message-ID: > Y6g at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Thank you for this. > > Regards, > Gbemisola Esho > > On Tue, 5 May 2026, 13:29 jordi.palet--- via RPD, wrote: > > > Hi Madhvi, Brice, > > > > This is a perfect summary, tks a lot! > > > > Regards, > > Jordi > > > > @jordipalet > > > > > > El 5 may 2026, a las 13:58, Policy Liaison Team via RPD > > > escribi?: > > > > Dear PDWG > > > > A summary of problem areas presented in past Policy Implementation > > Experience Reports has been published here - > > https://www.afrinic.net/policy/implementation-reports/pier-summary > > . > > > > Kind Regards > > > > Madhvi & Brice > > > > Policy Liaison Team > > > > -- > > AFRINIC Policy Liaison. > > t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w: > www.afrinic.netfacebook.com/afrinic | flickr.com/afrinic | > youtube.com/afrinicmedia > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.theipv6company.com > > The IPv6 Company > > > > This electronic message contains information which may be privileged or > > confidential. The information is intended to be for the exclusive use of > > the individual(s) named above and further non-explicilty authorized > > disclosure, copying, distribution or use of the contents of this > > information, even if partially, including attached files, is strictly > > prohibited and will be considered a criminal offense. If you are not the > > intended recipient be aware that any disclosure, copying, distribution or > > use of the contents of this information, even if partially, including > > attached files, is strictly prohibited, will be considered a criminal > > offense, so you must reply to the original sender to inform about this > > communication and delete it. > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260505/84c4b8bb/attachment-0001.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 220, Issue 3 > *********************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From comms at afrinic.net Fri May 8 12:16:29 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Fri, 8 May 2026 16:16:29 +0400 Subject: [rpd] AFRINIC 2026 Elections: Call for Nominations Message-ID: [Version en fran?ais ci-dessous] Dear coll?gues, The Nomination Committee 2026, under the Chairmanship of Mr Ganesh Ramalingum, is hereby calling for nominations from the AFRINIC Membership and its Community for the following open positions. 1.? ?Three (3) Seats for the Governance Committee The AFRINIC Governance Committee is a standing committee whose purpose is to advise the AFRINIC Board, AFRINIC Membership, and the community, on matters of governance. The GC Charter is available at https://afrinic.net/govcom#tor As an exceptional transitional arrangement applicable to this election only, the 3 elected members shall be assigned staggered terms expiring in three (3) consecutive years as follows: the candidate receiving the highest number of votes shall assume office upon election and serve until 31 December 2029 the candidate receiving the second-highest number of votes shall assume office upon election and serve until 31 December 2028; and the candidate receiving the third-highest number of votes shall assume office upon election and serve until 31 December 2027. Thereafter, future replacements would typically serve normal three-year terms. For the avoidance of doubt, the aforesaid 3 elected representatives are voted by the AFRINIC Resource Members in good standing, as reflected in the MyAFRINIC system at the time of voting. 2.? ?Two (2) Seats for the NRO NC / ASO AC community representatives The Number Resource Organisation Number Council (NRO NC), also serving as the ASO Address Council (ASO AC), operate as a single entity (NRO NC / ASO AC), and consist of 15 members, three from each of the five Regional Internet Registries (RIR) communities. The ASO AC is part of the ICANN Address Support Organisation (ASO). The NRO NC is part of the Number Resource Organisation (NRO) created by the five RIRs. More information is available at https://afrinic.net/committees As an exceptional transitional arrangement applicable to this election only, the 2 elected representatives shall be assigned staggered terms expiring in two (2) consecutive years as follows: ?the candidate receiving the highest number of votes shall assume office upon election and serve until 31 December 2029; and ?the candidate receiving the second-highest number of votes shall assume office upon election and serve until 31 December 2028. Thereafter, future replacements would typically serve normal three-year terms. For the purposes of this election, eligible voters shall include individuals, whether acting as representatives of Resource Members or otherwise, who form part of the African Internet community and who have completed the required registration process for inclusion on the community voter register. Do note that individuals not being a designated voter of an eligible Resource Member must have been on AFRINIC?s mailing list, including Resource Policy Discussion, Community-Discuss, or Members-Discuss, for at least three (3) years immediately prior to his/her online registration for the meeting and been vetted. Clause 8.2.1 of the Election Guidelines refers. 3.? ?Two (2) PDP Co-Chairs [consensus-based] The two (2) selected PDP Co-Chairs shall be assigned staggered terms expiring in two (2) consecutive years: one selected candidate shall, exceptionally, serve a one-year term ending at the first Public Policy Meeting (PPM) following the expiry of that one-year term, the other selected candidate shall serve a standard two-year term ending at the first PPM following the expiry of his or her two-year term based on the wish of the PDWG during the said PPM. Thereafter, future replacements would typically serve normal two-year terms. Consistent with Article 11.2 of the AFRINIC bylaws, and in order to give full effect to AFRINIC?s bottom-up governance model, the section process to be conducted during the PPM will involve individuals, whether acting as representatives of Resource Members or otherwise, who form part of the African Internet community and who have completed the required registration process for attending the said meeting. The Nomination Committee 2026 wishes to receive Nominations from all of the AFRINIC sub-regions and explicitly seeks to promote both gender and linguistic diversity, although a working understanding of the English language is required. The nomination requirements and Election Guidelines are available at http://election.afrinic.net/election-guideline-2026 To nominate yourself or a candidate of your choice, please complete the applicable nomination form at: For Governance Committee elections: https://forms.afrinic.net/governance-committee-election-2026 For NRO NC / ASO AC elections : https://forms.afrinic.net/nro-nc-aso-ac-election-2026 For PDP Co-Chairs selection: https://forms.afrinic.net/pdp-co-chairs-selection-2026 Kindly note that each candidature must be supported by two (2) AFRINIC Resource Members in good standing. The nomination period shall end on 29th May 2026 at 23:59 UTC. Please note that any person convicted of an offence involving dishonesty, fraud, or breach of trust shall not be eligible for consideration for the aforementioned positions. The Nomination Committee reserves the right to disqualify nominees from the final candidates slate who engage in any form of election malpractice. 2026 ELECTIONS TIMELINE The following timeline shall apply, insofar as reasonably practicable. 1. Open Call for Nominations 8th May 2026 2. Close Call for Nominations 29th May 2026 3. Candidate Vetting and Verification 30 May 2026 to 10th June 2026 4. Final Candidate Slate Publication 11th June 5. Voting Period & Platform Access for Governance Committee & NRO NC / ASO AC elections = at least 5 days before the day of AGMM and PPM = 19 June 2026 6. Announcement of Results of NRO NC / ASO AC election and PDWG Co-Chairs selection = During PPM = 24 June 2026 7. Announcement of Results of Governance Committee election = AGMM Day = 25 June 2026 We look forward to hearing from you the soonest possible and remain at your disposal for any further information that you may require. Yours sincerely, Ganesh Ramalingum Chairman AFRINIC Nomination Committee 2026 ??????????????????.. Chers coll?gues, Le Comit? de nomination 2026, sous la pr?sidence de Monsieur Ganesh Ramalingum, lance par la pr?sente un appel ? candidatures aupr?s des membres et de la communaut? d'AFRINIC pour les postes vacants suivants : 1. Trois (3) si?ges au sein du Comit? de gouvernance Le Comit? de gouvernance (GC) d'AFRINIC est un comit? permanent dont la mission est de conseiller le Conseil d'administration, les membres et la communaut? d'AFRINIC sur les questions de gouvernance. La charte du GC est disponible ? l'adresse suivante : https://afrinic.net/govcom#tor ? titre de disposition transitoire exceptionnelle applicable uniquement ? cette ?lection, les trois membres ?lus se verront attribuer des mandats ?chelonn?s expirant sur trois (3) ann?es cons?cutives comme suit : Le candidat ayant obtenu le plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2029 ; Le candidat ayant obtenu le deuxi?me plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2028 ; Le candidat ayant obtenu le troisi?me plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2027. Par la suite, les futurs rempla?ants rempliront normalement des mandats de trois ans. Pour ?viter toute ambigu?t?, les trois repr?sentants ?lus susmentionn?s sont vot?s par les Membres de ressources d'AFRINIC en r?gle, tels que r?pertori?s dans le syst?me MyAFRINIC au moment du vote. 2. Deux (2) si?ges pour les repr?sentants de la communaut? NRO NC / ASO AC Le Conseil des num?ros de l'Organisation des ressources num?riques (NRO NC), si?geant ?galement en tant que Conseil d'adressage de l'ASO (ASO AC), fonctionne comme une entit? unique (NRO NC / ASO AC) et se compose de 15 membres, soit trois membres issus de chacune des communaut?s des cinq Registres Internet R?gionaux (RIR). L'ASO AC fait partie de l'organisation de soutien ? l'adressage de l'ICANN (ASO). Le NRO NC fait partie de l'Organisation des ressources num?riques (NRO) cr??e par les cinq RIR. De plus amples informations sont disponibles sur : https://afrinic.net/committees ? titre de disposition transitoire exceptionnelle applicable uniquement ? cette ?lection, les deux repr?sentants ?lus se verront attribuer des mandats ?chelonn?s expirant sur deux (2) ann?es cons?cutives comme suit : Le candidat ayant obtenu le plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2029 ; Le candidat ayant obtenu le deuxi?me plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2028. Par la suite, les futurs rempla?ants rempliront normalement des mandats de trois ans. Aux fins de cette ?lection, les ?lecteurs ?ligibles comprennent les individus, qu'ils agissent en tant que repr?sentants de Membres de ressources ou autrement, faisant partie de la communaut? Internet africaine et ayant compl?t? le processus d'enregistrement requis pour figurer sur le registre ?lectoral de la communaut?. Veuillez noter que les individus n'?tant pas un ?lecteur d?sign? d'un Membre de ressources ?ligible doivent avoir figur? sur les listes de diffusion d'AFRINIC (y compris Resource Policy Discussion, Community-Discuss ou Members-Discuss) pendant au moins trois (3) ans imm?diatement avant leur enregistrement en ligne pour la r?union et avoir ?t? valid?s. Se r?f?rer ? la clause 8.2.1 des directives ?lectorales. 3. Deux (2) co-pr?sidents du PDP [bas? sur le consensus] Les deux (2) co-pr?sidents du PDP s?lectionn?s se verront attribuer des mandats ?chelonn?s expirant sur deux (2) ann?es cons?cutives : L'un des candidats s?lectionn?s effectuera, exceptionnellement, un mandat d'un an se terminant lors de la premi?re r?union de politique publique (PPM) suivant l'expiration de ce mandat d'un an ; L'autre candidat s?lectionn? effectuera un mandat standard de deux ans se terminant lors de la premi?re PPM suivant l'expiration de son mandat de deux ans, selon le souhait du PDWG lors de ladite PPM. Par la suite, les futurs rempla?ants rempliront normalement des mandats de deux ans. Conform?ment ? l'article 11.2 des statuts d'AFRINIC, et afin de donner plein effet au mod?le de gouvernance ascendante (bottom-up) d'AFRINIC, le processus de s?lection qui se tiendra lors de la PPM impliquera des individus, qu'ils agissent en tant que repr?sentants de Membres de ressources ou autrement, faisant partie de la communaut? Internet africaine et ayant compl?t? le processus d'enregistrement requis pour assister ? ladite r?union. Informations G?n?rales et Candidatures Le Comit? de nomination 2026 souhaite recevoir des candidatures de toutes les sous-r?gions d'AFRINIC et cherche explicitement ? promouvoir la diversit? tant linguistique que de genre, bien qu'une compr?hension op?rationnelle de la langue anglaise soit requise. Les crit?res de nomination et les directives ?lectorales sont disponibles sur : http://election.afrinic.net/election-guideline-2026 Pour vous pr?senter ou nommer un candidat de votre choix, veuillez remplir le formulaire de nomination correspondant : ?lections du Comit? de gouvernance : https://forms.afrinic.net/governance-committee-election-2026 ?lections NRO NC / ASO AC : https://forms.afrinic.net/nro-nc-aso-ac-election-2026 S?lection des co-pr?sidents du PDP : https://forms.afrinic.net/pdp-co-chairs-selection-2026 Veuillez noter que chaque candidature doit ?tre soutenue par deux (2) Membres de ressources d'AFRINIC en r?gle. La p?riode de nomination se terminera le 29 mai 2026 ? 23h59 UTC. Toute personne condamn?e pour une infraction impliquant la malhonn?tet?, la fraude ou l'abus de confiance ne sera pas ?ligible aux postes susmentionn?s. Le Comit? de nomination se r?serve le droit de disqualifier de la liste finale tout candidat se livrant ? toute forme de faute ?lectorale. Calendrier des elections 2026 Le calendrier suivant s'appliquera, dans la mesure du possible : Ouverture de l'appel ? candidatures : 8 mai 2026 Cl?ture de l'appel ? candidatures : 29 mai 2026 Examen et v?rification des candidatures : Du 30 mai au 10 juin 2026 Publication de la liste finale des candidats : 11 juin 2026 P?riode de vote et acc?s ? la plateforme (Comit? de gouvernance & NRO NC / ASO AC) : Au moins 5 jours avant l'AGMM et la PPM (soit le 19 juin 2026). Annonce des r?sultats (NRO NC / ASO AC et co-pr?sidents du PDWG) : Pendant la PPM (le 24 juin 2026). Annonce des r?sultats (Comit? de gouvernance) : Jour de l'AGMM (le 25 juin 2026). Dans l'attente de vos candidatures, nous restons ? votre enti?re disposition pour tout compl?ment d'information. Cordialement Ganesh Ramalingum Pr?sident Comit? de nomination d'AFRINIC 2026 -------------- next part -------------- An HTML attachment was scrubbed... URL: From comms at afrinic.net Fri May 8 13:12:27 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Fri, 8 May 2026 17:12:27 +0400 Subject: [rpd] AFRINIC 2026 Elections: Call for Nominations In-Reply-To: References: Message-ID: Dear colleagues, Please ignore this message due to a typo in the Election Timeline. Another message will follow. Regards, AFRINIC Communication > On 8 May 2026, at 16:16, rpd-request at afrinic.net wrote: > > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. AFRINIC 2026 Elections: Call for Nominations > (AFRINIC Communication) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 8 May 2026 16:16:29 +0400 > From: AFRINIC Communication > To: rpd > Subject: [rpd] AFRINIC 2026 Elections: Call for Nominations > Message-ID: > Content-Type: text/plain; charset="utf-8" > > [Version en fran?ais ci-dessous] > > Dear coll?gues, > > The Nomination Committee 2026, under the Chairmanship of Mr Ganesh Ramalingum, is hereby calling for nominations from the AFRINIC Membership and its Community for the following open positions. > > 1.? ?Three (3) Seats for the Governance Committee > > The AFRINIC Governance Committee is a standing committee whose purpose is to advise the AFRINIC Board, AFRINIC Membership, and the community, on matters of governance. > > The GC Charter is available at https://afrinic.net/govcom#tor > > As an exceptional transitional arrangement applicable to this election only, the 3 elected members shall be assigned staggered terms expiring in three (3) consecutive years as follows: > > the candidate receiving the highest number of votes shall assume office upon election and serve until 31 December 2029 > the candidate receiving the second-highest number of votes shall assume office upon election and serve until 31 December 2028; and > the candidate receiving the third-highest number of votes shall assume office upon election and serve until 31 December 2027. > > Thereafter, future replacements would typically serve normal three-year terms. > > For the avoidance of doubt, the aforesaid 3 elected representatives are voted by the AFRINIC Resource Members in good standing, as reflected in the MyAFRINIC system at the time of voting. > > > 2.? ?Two (2) Seats for the NRO NC / ASO AC community representatives > > The Number Resource Organisation Number Council (NRO NC), also serving as the ASO Address Council (ASO AC), operate as a single entity (NRO NC / ASO AC), and consist of 15 members, three from each of the five Regional Internet Registries (RIR) communities. > > The ASO AC is part of the ICANN Address Support Organisation (ASO). The NRO NC is part of the Number Resource Organisation (NRO) created by the five RIRs. > > More information is available at https://afrinic.net/committees > > As an exceptional transitional arrangement applicable to this election only, the 2 elected representatives shall be assigned staggered terms expiring in two (2) consecutive years as follows: > > ?the candidate receiving the highest number of votes shall assume office upon election and serve until 31 December 2029; and > ?the candidate receiving the second-highest number of votes shall assume office upon election and serve until 31 December 2028. > > Thereafter, future replacements would typically serve normal three-year terms. > > For the purposes of this election, eligible voters shall include individuals, whether acting as representatives of Resource Members or otherwise, who form part of the African Internet community and who have completed the required registration process for inclusion on the community voter register. > > Do note that individuals not being a designated voter of an eligible Resource Member must have been on AFRINIC?s mailing list, including Resource Policy Discussion, Community-Discuss, or Members-Discuss, for at least three (3) years immediately prior to his/her online registration for the meeting and been vetted. Clause 8.2.1 of the Election Guidelines refers. > > > 3.? ?Two (2) PDP Co-Chairs [consensus-based] > > The two (2) selected PDP Co-Chairs shall be assigned staggered terms expiring in two (2) consecutive years: > > one selected candidate shall, exceptionally, serve a one-year term ending at the first Public Policy Meeting (PPM) following the expiry of that one-year term, > the other selected candidate shall serve a standard two-year term ending at the first PPM following the expiry of his or her two-year term based on the wish of the PDWG during the said PPM. > > Thereafter, future replacements would typically serve normal two-year terms. > > Consistent with Article 11.2 of the AFRINIC bylaws, and in order to give full effect to AFRINIC?s bottom-up governance model, the section process to be conducted during the PPM will involve individuals, whether acting as representatives of Resource Members or otherwise, who form part of the African Internet community and who have completed the required registration process for attending the said meeting. > > The Nomination Committee 2026 wishes to receive Nominations from all of the AFRINIC sub-regions and explicitly seeks to promote both gender and linguistic diversity, although a working understanding of the English language is required. > > The nomination requirements and Election Guidelines are available at http://election.afrinic.net/election-guideline-2026 > > To nominate yourself or a candidate of your choice, please complete the applicable nomination form at: > > For Governance Committee elections: https://forms.afrinic.net/governance-committee-election-2026 > For NRO NC / ASO AC elections : https://forms.afrinic.net/nro-nc-aso-ac-election-2026 > For PDP Co-Chairs selection: https://forms.afrinic.net/pdp-co-chairs-selection-2026 > > > Kindly note that each candidature must be supported by two (2) AFRINIC Resource Members in good standing. > > The nomination period shall end on 29th May 2026 at 23:59 UTC. > > Please note that any person convicted of an offence involving dishonesty, fraud, or breach of trust shall not be eligible for consideration for the aforementioned positions. > > The Nomination Committee reserves the right to disqualify nominees from the final candidates slate who engage in any form of election malpractice. > > 2026 ELECTIONS TIMELINE > > The following timeline shall apply, insofar as reasonably practicable. > > 1. Open Call for Nominations 8th May 2026 > > 2. Close Call for Nominations 29th May 2026 > > 3. Candidate Vetting and Verification 30 May 2026 to 10th June 2026 > > 4. Final Candidate Slate Publication 11th June > > 5. Voting Period & Platform Access for Governance Committee & NRO NC / ASO AC elections = at least 5 days before the day of AGMM and PPM = 19 June 2026 > > 6. Announcement of Results of NRO NC / ASO AC election and PDWG Co-Chairs selection = During PPM = 24 June 2026 > > 7. Announcement of Results of Governance Committee election = AGMM Day = 25 June 2026 > > > We look forward to hearing from you the soonest possible and remain at your disposal for any further information that you may require. > > Yours sincerely, > > Ganesh Ramalingum > Chairman > AFRINIC Nomination Committee 2026 > > ??????????????????.. > > Chers coll?gues, > > Le Comit? de nomination 2026, sous la pr?sidence de Monsieur Ganesh Ramalingum, lance par la pr?sente un appel ? candidatures aupr?s des membres et de la communaut? d'AFRINIC pour les postes vacants suivants : > > > 1. Trois (3) si?ges au sein du Comit? de gouvernance > Le Comit? de gouvernance (GC) d'AFRINIC est un comit? permanent dont la mission est de conseiller le Conseil d'administration, les membres et la communaut? d'AFRINIC sur les questions de gouvernance. > > La charte du GC est disponible ? l'adresse suivante : https://afrinic.net/govcom#tor > ? titre de disposition transitoire exceptionnelle applicable uniquement ? cette ?lection, les trois membres ?lus se verront attribuer des mandats ?chelonn?s expirant sur trois (3) ann?es cons?cutives comme suit : > > Le candidat ayant obtenu le plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2029 ; > Le candidat ayant obtenu le deuxi?me plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2028 ; > Le candidat ayant obtenu le troisi?me plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2027. > > Par la suite, les futurs rempla?ants rempliront normalement des mandats de trois ans. > > Pour ?viter toute ambigu?t?, les trois repr?sentants ?lus susmentionn?s sont vot?s par les Membres de ressources d'AFRINIC en r?gle, tels que r?pertori?s dans le syst?me MyAFRINIC au moment du vote. > > > 2. Deux (2) si?ges pour les repr?sentants de la communaut? NRO NC / ASO AC > Le Conseil des num?ros de l'Organisation des ressources num?riques (NRO NC), si?geant ?galement en tant que Conseil d'adressage de l'ASO (ASO AC), fonctionne comme une entit? unique (NRO NC / ASO AC) et se compose de 15 membres, soit trois membres issus de chacune des communaut?s des cinq Registres Internet R?gionaux (RIR). > > L'ASO AC fait partie de l'organisation de soutien ? l'adressage de l'ICANN (ASO). Le NRO NC fait partie de l'Organisation des ressources num?riques (NRO) cr??e par les cinq RIR. > > De plus amples informations sont disponibles sur : https://afrinic.net/committees > ? titre de disposition transitoire exceptionnelle applicable uniquement ? cette ?lection, les deux repr?sentants ?lus se verront attribuer des mandats ?chelonn?s expirant sur deux (2) ann?es cons?cutives comme suit : > > Le candidat ayant obtenu le plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2029 ; > Le candidat ayant obtenu le deuxi?me plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2028. > > Par la suite, les futurs rempla?ants rempliront normalement des mandats de trois ans. > > Aux fins de cette ?lection, les ?lecteurs ?ligibles comprennent les individus, qu'ils agissent en tant que repr?sentants de Membres de ressources ou autrement, faisant partie de la communaut? Internet africaine et ayant compl?t? le processus d'enregistrement requis pour figurer sur le registre ?lectoral de la communaut?. > > Veuillez noter que les individus n'?tant pas un ?lecteur d?sign? d'un Membre de ressources ?ligible doivent avoir figur? sur les listes de diffusion d'AFRINIC (y compris Resource Policy Discussion, Community-Discuss ou Members-Discuss) pendant au moins trois (3) ans imm?diatement avant leur enregistrement en ligne pour la r?union et avoir ?t? valid?s. Se r?f?rer ? la clause 8.2.1 des directives ?lectorales. > > > 3. Deux (2) co-pr?sidents du PDP [bas? sur le consensus] > Les deux (2) co-pr?sidents du PDP s?lectionn?s se verront attribuer des mandats ?chelonn?s expirant sur deux (2) ann?es cons?cutives : > > L'un des candidats s?lectionn?s effectuera, exceptionnellement, un mandat d'un an se terminant lors de la premi?re r?union de politique publique (PPM) suivant l'expiration de ce mandat d'un an ; > L'autre candidat s?lectionn? effectuera un mandat standard de deux ans se terminant lors de la premi?re PPM suivant l'expiration de son mandat de deux ans, selon le souhait du PDWG lors de ladite PPM. > > Par la suite, les futurs rempla?ants rempliront normalement des mandats de deux ans. > > Conform?ment ? l'article 11.2 des statuts d'AFRINIC, et afin de donner plein effet au mod?le de gouvernance ascendante (bottom-up) d'AFRINIC, le processus de s?lection qui se tiendra lors de la PPM impliquera des individus, qu'ils agissent en tant que repr?sentants de Membres de ressources ou autrement, faisant partie de la communaut? Internet africaine et ayant compl?t? le processus d'enregistrement requis pour assister ? ladite r?union. > > > Informations G?n?rales et Candidatures > Le Comit? de nomination 2026 souhaite recevoir des candidatures de toutes les sous-r?gions d'AFRINIC et cherche explicitement ? promouvoir la diversit? tant linguistique que de genre, bien qu'une compr?hension op?rationnelle de la langue anglaise soit requise. > > Les crit?res de nomination et les directives ?lectorales sont disponibles sur : http://election.afrinic.net/election-guideline-2026 > Pour vous pr?senter ou nommer un candidat de votre choix, veuillez remplir le formulaire de nomination correspondant : > > ?lections du Comit? de gouvernance : https://forms.afrinic.net/governance-committee-election-2026 > ?lections NRO NC / ASO AC : https://forms.afrinic.net/nro-nc-aso-ac-election-2026 > S?lection des co-pr?sidents du PDP : https://forms.afrinic.net/pdp-co-chairs-selection-2026 > Veuillez noter que chaque candidature doit ?tre soutenue par deux (2) Membres de ressources d'AFRINIC en r?gle. > > La p?riode de nomination se terminera le 29 mai 2026 ? 23h59 UTC. > > Toute personne condamn?e pour une infraction impliquant la malhonn?tet?, la fraude ou l'abus de confiance ne sera pas ?ligible aux postes susmentionn?s. Le Comit? de nomination se r?serve le droit de disqualifier de la liste finale tout candidat se livrant ? toute forme de faute ?lectorale. > > > Calendrier des elections 2026 > Le calendrier suivant s'appliquera, dans la mesure du possible : > > Ouverture de l'appel ? candidatures : 8 mai 2026 > Cl?ture de l'appel ? candidatures : 29 mai 2026 > Examen et v?rification des candidatures : Du 30 mai au 10 juin 2026 > Publication de la liste finale des candidats : 11 juin 2026 > P?riode de vote et acc?s ? la plateforme (Comit? de gouvernance & NRO NC / ASO AC) : Au moins 5 jours avant l'AGMM et la PPM (soit le 19 juin 2026). > Annonce des r?sultats (NRO NC / ASO AC et co-pr?sidents du PDWG) : Pendant la PPM (le 24 juin 2026). > Annonce des r?sultats (Comit? de gouvernance) : Jour de l'AGMM (le 25 juin 2026). > > Dans l'attente de vos candidatures, nous restons ? votre enti?re disposition pour tout compl?ment d'information. > > Cordialement > > Ganesh Ramalingum > > Pr?sident > > Comit? de nomination d'AFRINIC 2026 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 220, Issue 5 > *********************************** From comms at afrinic.net Fri May 8 13:16:31 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Fri, 8 May 2026 17:16:31 +0400 Subject: [rpd] AFRINIC 2026 Elections: Call for Nominations In-Reply-To: References: Message-ID: <91E0A4FF-AE32-4035-AAAA-3CAF37B2A990@afrinic.net> Dear colleagues, Please ignore this message due to a typo in the Election Timeline. Another message will follow. Regards, AFRINIC Communication > On 8 May 2026, at 16:16, AFRINIC Communication wrote: > > [Version en fran?ais ci-dessous] > > Dear coll?gues, > > The Nomination Committee 2026, under the Chairmanship of Mr Ganesh Ramalingum, is hereby calling for nominations from the AFRINIC Membership and its Community for the following open positions. > > 1.? ?Three (3) Seats for the Governance Committee > > The AFRINIC Governance Committee is a standing committee whose purpose is to advise the AFRINIC Board, AFRINIC Membership, and the community, on matters of governance. > > The GC Charter is available at https://afrinic.net/govcom#tor > > As an exceptional transitional arrangement applicable to this election only, the 3 elected members shall be assigned staggered terms expiring in three (3) consecutive years as follows: > > the candidate receiving the highest number of votes shall assume office upon election and serve until 31 December 2029 > the candidate receiving the second-highest number of votes shall assume office upon election and serve until 31 December 2028; and > the candidate receiving the third-highest number of votes shall assume office upon election and serve until 31 December 2027. > > Thereafter, future replacements would typically serve normal three-year terms. > > For the avoidance of doubt, the aforesaid 3 elected representatives are voted by the AFRINIC Resource Members in good standing, as reflected in the MyAFRINIC system at the time of voting. > > > 2.? ?Two (2) Seats for the NRO NC / ASO AC community representatives > > The Number Resource Organisation Number Council (NRO NC), also serving as the ASO Address Council (ASO AC), operate as a single entity (NRO NC / ASO AC), and consist of 15 members, three from each of the five Regional Internet Registries (RIR) communities. > > The ASO AC is part of the ICANN Address Support Organisation (ASO). The NRO NC is part of the Number Resource Organisation (NRO) created by the five RIRs. > > More information is available at https://afrinic.net/committees > > As an exceptional transitional arrangement applicable to this election only, the 2 elected representatives shall be assigned staggered terms expiring in two (2) consecutive years as follows: > > ?the candidate receiving the highest number of votes shall assume office upon election and serve until 31 December 2029; and > ?the candidate receiving the second-highest number of votes shall assume office upon election and serve until 31 December 2028. > > Thereafter, future replacements would typically serve normal three-year terms. > > For the purposes of this election, eligible voters shall include individuals, whether acting as representatives of Resource Members or otherwise, who form part of the African Internet community and who have completed the required registration process for inclusion on the community voter register. > > Do note that individuals not being a designated voter of an eligible Resource Member must have been on AFRINIC?s mailing list, including Resource Policy Discussion, Community-Discuss, or Members-Discuss, for at least three (3) years immediately prior to his/her online registration for the meeting and been vetted. Clause 8.2.1 of the Election Guidelines refers. > > > 3.? ?Two (2) PDP Co-Chairs [consensus-based] > > The two (2) selected PDP Co-Chairs shall be assigned staggered terms expiring in two (2) consecutive years: > > one selected candidate shall, exceptionally, serve a one-year term ending at the first Public Policy Meeting (PPM) following the expiry of that one-year term, > the other selected candidate shall serve a standard two-year term ending at the first PPM following the expiry of his or her two-year term based on the wish of the PDWG during the said PPM. > > Thereafter, future replacements would typically serve normal two-year terms. > > Consistent with Article 11.2 of the AFRINIC bylaws, and in order to give full effect to AFRINIC?s bottom-up governance model, the section process to be conducted during the PPM will involve individuals, whether acting as representatives of Resource Members or otherwise, who form part of the African Internet community and who have completed the required registration process for attending the said meeting. > > The Nomination Committee 2026 wishes to receive Nominations from all of the AFRINIC sub-regions and explicitly seeks to promote both gender and linguistic diversity, although a working understanding of the English language is required. > > The nomination requirements and Election Guidelines are available at http://election.afrinic.net/election-guideline-2026 > > To nominate yourself or a candidate of your choice, please complete the applicable nomination form at: > > For Governance Committee elections: https://forms.afrinic.net/governance-committee-election-2026 > For NRO NC / ASO AC elections : https://forms.afrinic.net/nro-nc-aso-ac-election-2026 > For PDP Co-Chairs selection: https://forms.afrinic.net/pdp-co-chairs-selection-2026 > > > Kindly note that each candidature must be supported by two (2) AFRINIC Resource Members in good standing. > > The nomination period shall end on 29th May 2026 at 23:59 UTC. > > Please note that any person convicted of an offence involving dishonesty, fraud, or breach of trust shall not be eligible for consideration for the aforementioned positions. > > The Nomination Committee reserves the right to disqualify nominees from the final candidates slate who engage in any form of election malpractice. > > 2026 ELECTIONS TIMELINE > > The following timeline shall apply, insofar as reasonably practicable. > > 1. Open Call for Nominations 8th May 2026 > > 2. Close Call for Nominations 29th May 2026 > > 3. Candidate Vetting and Verification 30 May 2026 to 10th June 2026 > > 4. Final Candidate Slate Publication 11th June > > 5. Voting Period & Platform Access for Governance Committee & NRO NC / ASO AC elections = at least 5 days before the day of AGMM and PPM = 19 June 2026 > > 6. Announcement of Results of NRO NC / ASO AC election and PDWG Co-Chairs selection = During PPM = 24 June 2026 > > 7. Announcement of Results of Governance Committee election = AGMM Day = 25 June 2026 > > > We look forward to hearing from you the soonest possible and remain at your disposal for any further information that you may require. > > Yours sincerely, > > Ganesh Ramalingum > Chairman > AFRINIC Nomination Committee 2026 > > ??????????????????.. > > Chers coll?gues, > > Le Comit? de nomination 2026, sous la pr?sidence de Monsieur Ganesh Ramalingum, lance par la pr?sente un appel ? candidatures aupr?s des membres et de la communaut? d'AFRINIC pour les postes vacants suivants : > > > 1. Trois (3) si?ges au sein du Comit? de gouvernance > Le Comit? de gouvernance (GC) d'AFRINIC est un comit? permanent dont la mission est de conseiller le Conseil d'administration, les membres et la communaut? d'AFRINIC sur les questions de gouvernance. > > La charte du GC est disponible ? l'adresse suivante : https://afrinic.net/govcom#tor > ? titre de disposition transitoire exceptionnelle applicable uniquement ? cette ?lection, les trois membres ?lus se verront attribuer des mandats ?chelonn?s expirant sur trois (3) ann?es cons?cutives comme suit : > > Le candidat ayant obtenu le plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2029 ; > Le candidat ayant obtenu le deuxi?me plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2028 ; > Le candidat ayant obtenu le troisi?me plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2027. > > Par la suite, les futurs rempla?ants rempliront normalement des mandats de trois ans. > > Pour ?viter toute ambigu?t?, les trois repr?sentants ?lus susmentionn?s sont vot?s par les Membres de ressources d'AFRINIC en r?gle, tels que r?pertori?s dans le syst?me MyAFRINIC au moment du vote. > > > 2. Deux (2) si?ges pour les repr?sentants de la communaut? NRO NC / ASO AC > Le Conseil des num?ros de l'Organisation des ressources num?riques (NRO NC), si?geant ?galement en tant que Conseil d'adressage de l'ASO (ASO AC), fonctionne comme une entit? unique (NRO NC / ASO AC) et se compose de 15 membres, soit trois membres issus de chacune des communaut?s des cinq Registres Internet R?gionaux (RIR). > > L'ASO AC fait partie de l'organisation de soutien ? l'adressage de l'ICANN (ASO). Le NRO NC fait partie de l'Organisation des ressources num?riques (NRO) cr??e par les cinq RIR. > > De plus amples informations sont disponibles sur : https://afrinic.net/committees > ? titre de disposition transitoire exceptionnelle applicable uniquement ? cette ?lection, les deux repr?sentants ?lus se verront attribuer des mandats ?chelonn?s expirant sur deux (2) ann?es cons?cutives comme suit : > > Le candidat ayant obtenu le plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2029 ; > Le candidat ayant obtenu le deuxi?me plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2028. > > Par la suite, les futurs rempla?ants rempliront normalement des mandats de trois ans. > > Aux fins de cette ?lection, les ?lecteurs ?ligibles comprennent les individus, qu'ils agissent en tant que repr?sentants de Membres de ressources ou autrement, faisant partie de la communaut? Internet africaine et ayant compl?t? le processus d'enregistrement requis pour figurer sur le registre ?lectoral de la communaut?. > > Veuillez noter que les individus n'?tant pas un ?lecteur d?sign? d'un Membre de ressources ?ligible doivent avoir figur? sur les listes de diffusion d'AFRINIC (y compris Resource Policy Discussion, Community-Discuss ou Members-Discuss) pendant au moins trois (3) ans imm?diatement avant leur enregistrement en ligne pour la r?union et avoir ?t? valid?s. Se r?f?rer ? la clause 8.2.1 des directives ?lectorales. > > > 3. Deux (2) co-pr?sidents du PDP [bas? sur le consensus] > Les deux (2) co-pr?sidents du PDP s?lectionn?s se verront attribuer des mandats ?chelonn?s expirant sur deux (2) ann?es cons?cutives : > > L'un des candidats s?lectionn?s effectuera, exceptionnellement, un mandat d'un an se terminant lors de la premi?re r?union de politique publique (PPM) suivant l'expiration de ce mandat d'un an ; > L'autre candidat s?lectionn? effectuera un mandat standard de deux ans se terminant lors de la premi?re PPM suivant l'expiration de son mandat de deux ans, selon le souhait du PDWG lors de ladite PPM. > > Par la suite, les futurs rempla?ants rempliront normalement des mandats de deux ans. > > Conform?ment ? l'article 11.2 des statuts d'AFRINIC, et afin de donner plein effet au mod?le de gouvernance ascendante (bottom-up) d'AFRINIC, le processus de s?lection qui se tiendra lors de la PPM impliquera des individus, qu'ils agissent en tant que repr?sentants de Membres de ressources ou autrement, faisant partie de la communaut? Internet africaine et ayant compl?t? le processus d'enregistrement requis pour assister ? ladite r?union. > > > Informations G?n?rales et Candidatures > Le Comit? de nomination 2026 souhaite recevoir des candidatures de toutes les sous-r?gions d'AFRINIC et cherche explicitement ? promouvoir la diversit? tant linguistique que de genre, bien qu'une compr?hension op?rationnelle de la langue anglaise soit requise. > > Les crit?res de nomination et les directives ?lectorales sont disponibles sur : http://election.afrinic.net/election-guideline-2026 > Pour vous pr?senter ou nommer un candidat de votre choix, veuillez remplir le formulaire de nomination correspondant : > > ?lections du Comit? de gouvernance : https://forms.afrinic.net/governance-committee-election-2026 > ?lections NRO NC / ASO AC : https://forms.afrinic.net/nro-nc-aso-ac-election-2026 > S?lection des co-pr?sidents du PDP : https://forms.afrinic.net/pdp-co-chairs-selection-2026 > Veuillez noter que chaque candidature doit ?tre soutenue par deux (2) Membres de ressources d'AFRINIC en r?gle. > > La p?riode de nomination se terminera le 29 mai 2026 ? 23h59 UTC. > > Toute personne condamn?e pour une infraction impliquant la malhonn?tet?, la fraude ou l'abus de confiance ne sera pas ?ligible aux postes susmentionn?s. Le Comit? de nomination se r?serve le droit de disqualifier de la liste finale tout candidat se livrant ? toute forme de faute ?lectorale. > > > Calendrier des elections 2026 > Le calendrier suivant s'appliquera, dans la mesure du possible : > > Ouverture de l'appel ? candidatures : 8 mai 2026 > Cl?ture de l'appel ? candidatures : 29 mai 2026 > Examen et v?rification des candidatures : Du 30 mai au 10 juin 2026 > Publication de la liste finale des candidats : 11 juin 2026 > P?riode de vote et acc?s ? la plateforme (Comit? de gouvernance & NRO NC / ASO AC) : Au moins 5 jours avant l'AGMM et la PPM (soit le 19 juin 2026). > Annonce des r?sultats (NRO NC / ASO AC et co-pr?sidents du PDWG) : Pendant la PPM (le 24 juin 2026). > Annonce des r?sultats (Comit? de gouvernance) : Jour de l'AGMM (le 25 juin 2026). > > Dans l'attente de vos candidatures, nous restons ? votre enti?re disposition pour tout compl?ment d'information. > > Cordialement > > Ganesh Ramalingum > > Pr?sident > > Comit? de nomination d'AFRINIC 2026 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From comms at afrinic.net Fri May 8 13:28:43 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Fri, 8 May 2026 17:28:43 +0400 Subject: [rpd] AFRINIC 2026 Elections: Call for Nominations In-Reply-To: <91E0A4FF-AE32-4035-AAAA-3CAF37B2A990@afrinic.net> References: <91E0A4FF-AE32-4035-AAAA-3CAF37B2A990@afrinic.net> Message-ID: <94E9FF80-4517-4724-95A8-CEF1BE353732@afrinic.net> Dear colleagues, The Nomination Committee 2026, under the Chairmanship of Mr Ganesh Ramalingum, is hereby calling for nominations from the AFRINIC Membership and its Community for the following open positions; 1.? ?Three (3) Seats for the Governance Committee The AFRINIC Governance Committee is a standing committee whose purpose is to advise the AFRINIC Board, AFRINIC Membership, and the community, on matters of governance. The GC Charter is available at https://afrinic.net/govcom#tor As an exceptional transitional arrangement applicable to this election only, the 3 elected members shall be assigned staggered terms expiring in three (3) consecutive years as follows: the candidate receiving the highest number of votes shall assume office upon election and serve until 31 December 2029 the candidate receiving the second-highest number of votes shall assume office upon election and serve until 31 December 2028; and the candidate receiving the third-highest number of votes shall assume office upon election and serve until 31 December 2027. Thereafter, future replacements would typically serve normal three-year terms. For the avoidance of doubt, the aforesaid 3 elected representatives are voted by the AFRINIC Resource Members in good standing, as reflected in the MyAFRINIC system at the time of voting. 2.? ?Two (2) Seats for the NRO NC / ASO AC community representatives The Number Resource Organisation Number Council (NRO NC), also serving as the ASO Address Council (ASO AC), operate as a single entity (NRO NC / ASO AC), and consist of 15 members, three from each of the five Regional Internet Registries (RIR) communities. The ASO AC is part of the ICANN Address Support Organisation (ASO). The NRO NC is part of the Number Resource Organisation (NRO) created by the five RIRs. More information is available at https://afrinic.net/committees As an exceptional transitional arrangement applicable to this election only, the 2 elected representatives shall be assigned staggered terms expiring in two (2) consecutive years as follows: ?the candidate receiving the highest number of votes shall assume office upon election and serve until 31 December 2029; and ?the candidate receiving the second-highest number of votes shall assume office upon election and serve until 31 December 2028. Thereafter, future replacements would typically serve normal three-year terms. For the purposes of this election, eligible voters shall include individuals, whether acting as representatives of Resource Members or otherwise, who form part of the African Internet community and who have completed the required registration process for inclusion on the community voter register. Do note that individuals not being a designated voter of an eligible Resource Member must have been on AFRINIC?s mailing list, including Resource Policy Discussion, Community-Discuss, or Members-Discuss, for at least three (3) years immediately prior to his/her online registration for the meeting and been vetted. Clause 8.2.1 of the Election Guidelines refers. 3.? ?Two (2) PDP Co-Chairs [consensus-based] The two (2) selected PDP Co-Chairs shall be assigned staggered terms expiring in two (2) consecutive years: one selected candidate shall, exceptionally, serve a one-year term ending at the first Public Policy Meeting (PPM) following the expiry of that one-year term, the other selected candidate shall serve a standard two-year term ending at the first PPM following the expiry of his or her two-year term based on the wish of the PDWG during the said PPM. Thereafter, future replacements would typically serve normal two-year terms. Consistent with Article 11.2 of the AFRINIC bylaws, and in order to give full effect to AFRINIC?s bottom-up governance model, the selection process to be conducted during the PPM will involve individuals, whether acting as representatives of Resource Members or otherwise, who form part of the African Internet community and who have completed the required registration process for attending the said meeting. The Nomination Committee 2026 wishes to receive Nominations from all of the AFRINIC sub-regions and explicitly seeks to promote both gender and linguistic diversity, although a working understanding of the English language is required. The nomination requirements and Election Guidelines are available at http://election.afrinic.net/election-guideline-2026 To nominate yourself or a candidate of your choice, please complete the applicable nomination form at: For Governance Committee elections: https://forms.afrinic.net/governance-committee-election-2026 For NRO NC / ASO AC elections: https://forms.afrinic.net/nro-nc-aso-ac-election-2026 For PDP Co-Chairs selection: https://forms.afrinic.net/pdp-co-chairs-selection-2026 Kindly note that each candidature must be supported by two (2) AFRINIC Resource Members in good standing. The nomination period shall end on 29th May 2026 at 23:59 UTC. Please note that any person convicted of an offence involving dishonesty, fraud, or breach of trust shall not be eligible for consideration for the aforementioned positions. The Nomination Committee reserves the right to disqualify nominees from the final candidates slate who engage in any form of election malpractice. 2026 ELECTIONS TIMELINE The following timeline shall apply, insofar as reasonably practicable. Open Call for Nominations 8th May 2026 Close Call for Nominations 29th May 2026 Candidate Vetting and Verification 30 May 2026 to 10th June 2026 Provisional Candidate State Publication 11th June 2026 Final Candidate Slate Publication 15th June 2026 Voting Period & Platform Access for Governance Committee & NRO NC / ASO AC elections = at least 5 days before the day of AGMM and PPM = 19 June 2026 Announcement of Results of NRO NC / ASO AC election and PDWG Co-Chairs selection = During PPM = 24 June 2026 Announcement of Results of Governance Committee election = AGMM Day = 25 June 2026 We look forward to hearing from you the soonest possible and remain at your disposal for any further information that you may require. Yours sincerely, Ganesh Ramalingum Chairman AFRINIC Nomination Committee 2026 ??????????????????.. Chers coll?gues, Le Comit? de nomination 2026, sous la pr?sidence de Monsieur Ganesh Ramalingum, lance par la pr?sente un appel ? candidatures aupr?s des membres et de la communaut? d'AFRINIC pour les postes vacants suivants : 1. Trois (3) si?ges au sein du Comit? de gouvernance Le Comit? de gouvernance (GC) d'AFRINIC est un comit? permanent dont la mission est de conseiller le Conseil d'administration, les membres et la communaut? d'AFRINIC sur les questions de gouvernance. La charte du GC est disponible ? l'adresse suivante : https://afrinic.net/govcom#tor ? titre de disposition transitoire exceptionnelle applicable uniquement ? cette ?lection, les trois membres ?lus se verront attribuer des mandats ?chelonn?s expirant sur trois (3) ann?es cons?cutives comme suit : Le candidat ayant obtenu le plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2029 ; Le candidat ayant obtenu le deuxi?me plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2028 ; Le candidat ayant obtenu le troisi?me plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2027. Par la suite, les futurs rempla?ants rempliront normalement des mandats de trois ans. Pour ?viter toute ambigu?t?, les trois repr?sentants ?lus susmentionn?s sont vot?s par les Membres de ressources d'AFRINIC en r?gle, tels que r?pertori?s dans le syst?me MyAFRINIC au moment du vote. 2. Deux (2) si?ges pour les repr?sentants de la communaut? NRO NC / ASO AC Le Conseil des num?ros de l'Organisation des ressources num?riques (NRO NC), si?geant ?galement en tant que Conseil d'adressage de l'ASO (ASO AC), fonctionne comme une entit? unique (NRO NC / ASO AC) et se compose de 15 membres, soit trois membres issus de chacune des communaut?s des cinq Registres Internet R?gionaux (RIR). L'ASO AC fait partie de l'organisation de soutien ? l'adressage de l'ICANN (ASO). Le NRO NC fait partie de l'Organisation des ressources num?riques (NRO) cr??e par les cinq RIR. De plus amples informations sont disponibles sur : https://afrinic.net/committees ? titre de disposition transitoire exceptionnelle applicable uniquement ? cette ?lection, les deux repr?sentants ?lus se verront attribuer des mandats ?chelonn?s expirant sur deux (2) ann?es cons?cutives comme suit : Le candidat ayant obtenu le plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2029 ; Le candidat ayant obtenu le deuxi?me plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2028. Par la suite, les futurs rempla?ants rempliront normalement des mandats de trois ans. Aux fins de cette ?lection, les ?lecteurs ?ligibles comprennent les individus, qu'ils agissent en tant que repr?sentants de Membres de ressources ou autrement, faisant partie de la communaut? Internet africaine et ayant compl?t? le processus d'enregistrement requis pour figurer sur le registre ?lectoral de la communaut?. Veuillez noter que les individus n'?tant pas un ?lecteur d?sign? d'un Membre de ressources ?ligible doivent avoir figur? sur les listes de diffusion d'AFRINIC (y compris Resource Policy Discussion, Community-Discuss ou Members-Discuss) pendant au moins trois (3) ans imm?diatement avant leur enregistrement en ligne pour la r?union et avoir ?t? valid?s. Se r?f?rer ? la clause 8.2.1 des directives ?lectorales. 3. Deux (2) co-pr?sidents du PDP [bas? sur le consensus] Les deux (2) co-pr?sidents du PDP s?lectionn?s se verront attribuer des mandats ?chelonn?s expirant sur deux (2) ann?es cons?cutives : L'un des candidats s?lectionn?s effectuera, exceptionnellement, un mandat d'un an se terminant lors de la premi?re r?union de politique publique (PPM) suivant l'expiration de ce mandat d'un an ; L'autre candidat s?lectionn? effectuera un mandat standard de deux ans se terminant lors de la premi?re PPM suivant l'expiration de son mandat de deux ans, selon le souhait du PDWG lors de ladite PPM. Par la suite, les futurs rempla?ants rempliront normalement des mandats de deux ans. Conform?ment ? l'article 11.2 des statuts d'AFRINIC, et afin de donner plein effet au mod?le de gouvernance ascendante (bottom-up) d'AFRINIC, le processus de s?lection qui se tiendra lors de la PPM impliquera des individus, qu'ils agissent en tant que repr?sentants de Membres de ressources ou autrement, faisant partie de la communaut? Internet africaine et ayant compl?t? le processus d'enregistrement requis pour assister ? ladite r?union. Informations G?n?rales et Candidatures Le Comit? de nomination 2026 souhaite recevoir des candidatures de toutes les sous-r?gions d'AFRINIC et cherche explicitement ? promouvoir la diversit? tant linguistique que de genre, bien qu'une compr?hension op?rationnelle de la langue anglaise soit requise. Les crit?res de nomination et les directives ?lectorales sont disponibles sur : http://election.afrinic.net/election-guideline-2026 Pour vous pr?senter ou nommer un candidat de votre choix, veuillez remplir le formulaire de nomination correspondant : ?lections du Comit? de gouvernance : https://forms.afrinic.net/governance-committee-election-2026 ?lections NRO NC / ASO AC : https://forms.afrinic.net/nro-nc-aso-ac-election-2026 S?lection des co-pr?sidents du PDP : https://forms.afrinic.net/pdp-co-chairs-selection-2026 Veuillez noter que chaque candidature doit ?tre soutenue par deux (2) Membres de ressources d'AFRINIC en r?gle. La p?riode de nomination se terminera le 29 mai 2026 ? 23h59 UTC. Toute personne condamn?e pour une infraction impliquant la malhonn?tet?, la fraude ou l'abus de confiance ne sera pas ?ligible aux postes susmentionn?s. Le Comit? de nomination se r?serve le droit de disqualifier de la liste finale tout candidat se livrant ? toute forme de faute ?lectorale. CALENDRIER DES ?LECTIONS 2026 Le calendrier suivant s'appliquera, dans la mesure du possible : Ouverture de l'appel ? candidatures : 8 mai 2026 Cl?ture de l'appel ? candidatures : 29 mai 2026 Examen et v?rification des candidatures : Du 30 mai au 10 juin 2026 Publication de la liste provisoire des candidats : 11 juin 2026 Publication de la liste finale des candidats: 15 juin 2026 P?riode de vote et acc?s ? la plateforme (Comit? de gouvernance & NRO NC / ASO AC) : Au moins 5 jours avant l'AGMM et la PPM (soit le 19 juin 2026). Annonce des r?sultats (NRO NC / ASO AC et co-pr?sidents du PDWG) : Pendant la PPM (le 24 juin 2026). Annonce des r?sultats (Comit? de gouvernance) : Jour de l'AGMM (le 25 juin 2026). Dans l'attente de vos candidatures, nous restons ? votre enti?re disposition pour tout compl?ment d'information. Cordialement Ganesh Ramalingum Pr?sident Comit? de nomination d'AFRINIC 2026 > On 8 May 2026, at 17:16, AFRINIC Communication wrote: > > Dear colleagues, > > Please ignore this message due to a typo in the Election Timeline. Another message will follow. > > Regards, > > AFRINIC Communication > >> On 8 May 2026, at 16:16, AFRINIC Communication wrote: >> >> [Version en fran?ais ci-dessous] >> >> Dear coll?gues, >> >> The Nomination Committee 2026, under the Chairmanship of Mr Ganesh Ramalingum, is hereby calling for nominations from the AFRINIC Membership and its Community for the following open positions. >> >> 1.? ?Three (3) Seats for the Governance Committee >> >> The AFRINIC Governance Committee is a standing committee whose purpose is to advise the AFRINIC Board, AFRINIC Membership, and the community, on matters of governance. >> >> The GC Charter is available at https://afrinic.net/govcom#tor >> >> As an exceptional transitional arrangement applicable to this election only, the 3 elected members shall be assigned staggered terms expiring in three (3) consecutive years as follows: >> >> the candidate receiving the highest number of votes shall assume office upon election and serve until 31 December 2029 >> the candidate receiving the second-highest number of votes shall assume office upon election and serve until 31 December 2028; and >> the candidate receiving the third-highest number of votes shall assume office upon election and serve until 31 December 2027. >> >> Thereafter, future replacements would typically serve normal three-year terms. >> >> For the avoidance of doubt, the aforesaid 3 elected representatives are voted by the AFRINIC Resource Members in good standing, as reflected in the MyAFRINIC system at the time of voting. >> >> >> 2.? ?Two (2) Seats for the NRO NC / ASO AC community representatives >> >> The Number Resource Organisation Number Council (NRO NC), also serving as the ASO Address Council (ASO AC), operate as a single entity (NRO NC / ASO AC), and consist of 15 members, three from each of the five Regional Internet Registries (RIR) communities. >> >> The ASO AC is part of the ICANN Address Support Organisation (ASO). The NRO NC is part of the Number Resource Organisation (NRO) created by the five RIRs. >> >> More information is available at https://afrinic.net/committees >> >> As an exceptional transitional arrangement applicable to this election only, the 2 elected representatives shall be assigned staggered terms expiring in two (2) consecutive years as follows: >> >> ?the candidate receiving the highest number of votes shall assume office upon election and serve until 31 December 2029; and >> ?the candidate receiving the second-highest number of votes shall assume office upon election and serve until 31 December 2028. >> >> Thereafter, future replacements would typically serve normal three-year terms. >> >> For the purposes of this election, eligible voters shall include individuals, whether acting as representatives of Resource Members or otherwise, who form part of the African Internet community and who have completed the required registration process for inclusion on the community voter register. >> >> Do note that individuals not being a designated voter of an eligible Resource Member must have been on AFRINIC?s mailing list, including Resource Policy Discussion, Community-Discuss, or Members-Discuss, for at least three (3) years immediately prior to his/her online registration for the meeting and been vetted. Clause 8.2.1 of the Election Guidelines refers. >> >> >> 3.? ?Two (2) PDP Co-Chairs [consensus-based] >> >> The two (2) selected PDP Co-Chairs shall be assigned staggered terms expiring in two (2) consecutive years: >> >> one selected candidate shall, exceptionally, serve a one-year term ending at the first Public Policy Meeting (PPM) following the expiry of that one-year term, >> the other selected candidate shall serve a standard two-year term ending at the first PPM following the expiry of his or her two-year term based on the wish of the PDWG during the said PPM. >> >> Thereafter, future replacements would typically serve normal two-year terms. >> >> Consistent with Article 11.2 of the AFRINIC bylaws, and in order to give full effect to AFRINIC?s bottom-up governance model, the section process to be conducted during the PPM will involve individuals, whether acting as representatives of Resource Members or otherwise, who form part of the African Internet community and who have completed the required registration process for attending the said meeting. >> >> The Nomination Committee 2026 wishes to receive Nominations from all of the AFRINIC sub-regions and explicitly seeks to promote both gender and linguistic diversity, although a working understanding of the English language is required. >> >> The nomination requirements and Election Guidelines are available at http://election.afrinic.net/election-guideline-2026 >> >> To nominate yourself or a candidate of your choice, please complete the applicable nomination form at: >> >> For Governance Committee elections: https://forms.afrinic.net/governance-committee-election-2026 >> For NRO NC / ASO AC elections : https://forms.afrinic.net/nro-nc-aso-ac-election-2026 >> For PDP Co-Chairs selection: https://forms.afrinic.net/pdp-co-chairs-selection-2026 >> >> >> Kindly note that each candidature must be supported by two (2) AFRINIC Resource Members in good standing. >> >> The nomination period shall end on 29th May 2026 at 23:59 UTC. >> >> Please note that any person convicted of an offence involving dishonesty, fraud, or breach of trust shall not be eligible for consideration for the aforementioned positions. >> >> The Nomination Committee reserves the right to disqualify nominees from the final candidates slate who engage in any form of election malpractice. >> >> 2026 ELECTIONS TIMELINE >> >> The following timeline shall apply, insofar as reasonably practicable. >> >> 1. Open Call for Nominations 8th May 2026 >> >> 2. Close Call for Nominations 29th May 2026 >> >> 3. Candidate Vetting and Verification 30 May 2026 to 10th June 2026 >> >> 4. Final Candidate Slate Publication 11th June >> >> 5. Voting Period & Platform Access for Governance Committee & NRO NC / ASO AC elections = at least 5 days before the day of AGMM and PPM = 19 June 2026 >> >> 6. Announcement of Results of NRO NC / ASO AC election and PDWG Co-Chairs selection = During PPM = 24 June 2026 >> >> 7. Announcement of Results of Governance Committee election = AGMM Day = 25 June 2026 >> >> >> We look forward to hearing from you the soonest possible and remain at your disposal for any further information that you may require. >> >> Yours sincerely, >> >> Ganesh Ramalingum >> Chairman >> AFRINIC Nomination Committee 2026 >> >> ??????????????????.. >> >> Chers coll?gues, >> >> Le Comit? de nomination 2026, sous la pr?sidence de Monsieur Ganesh Ramalingum, lance par la pr?sente un appel ? candidatures aupr?s des membres et de la communaut? d'AFRINIC pour les postes vacants suivants : >> >> >> 1. Trois (3) si?ges au sein du Comit? de gouvernance >> Le Comit? de gouvernance (GC) d'AFRINIC est un comit? permanent dont la mission est de conseiller le Conseil d'administration, les membres et la communaut? d'AFRINIC sur les questions de gouvernance. >> >> La charte du GC est disponible ? l'adresse suivante : https://afrinic.net/govcom#tor >> ? titre de disposition transitoire exceptionnelle applicable uniquement ? cette ?lection, les trois membres ?lus se verront attribuer des mandats ?chelonn?s expirant sur trois (3) ann?es cons?cutives comme suit : >> >> Le candidat ayant obtenu le plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2029 ; >> Le candidat ayant obtenu le deuxi?me plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2028 ; >> Le candidat ayant obtenu le troisi?me plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2027. >> >> Par la suite, les futurs rempla?ants rempliront normalement des mandats de trois ans. >> >> Pour ?viter toute ambigu?t?, les trois repr?sentants ?lus susmentionn?s sont vot?s par les Membres de ressources d'AFRINIC en r?gle, tels que r?pertori?s dans le syst?me MyAFRINIC au moment du vote. >> >> >> 2. Deux (2) si?ges pour les repr?sentants de la communaut? NRO NC / ASO AC >> Le Conseil des num?ros de l'Organisation des ressources num?riques (NRO NC), si?geant ?galement en tant que Conseil d'adressage de l'ASO (ASO AC), fonctionne comme une entit? unique (NRO NC / ASO AC) et se compose de 15 membres, soit trois membres issus de chacune des communaut?s des cinq Registres Internet R?gionaux (RIR). >> >> L'ASO AC fait partie de l'organisation de soutien ? l'adressage de l'ICANN (ASO). Le NRO NC fait partie de l'Organisation des ressources num?riques (NRO) cr??e par les cinq RIR. >> >> De plus amples informations sont disponibles sur : https://afrinic.net/committees >> ? titre de disposition transitoire exceptionnelle applicable uniquement ? cette ?lection, les deux repr?sentants ?lus se verront attribuer des mandats ?chelonn?s expirant sur deux (2) ann?es cons?cutives comme suit : >> >> Le candidat ayant obtenu le plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2029 ; >> Le candidat ayant obtenu le deuxi?me plus grand nombre de voix entrera en fonction d?s son ?lection et servira jusqu'au 31 d?cembre 2028. >> >> Par la suite, les futurs rempla?ants rempliront normalement des mandats de trois ans. >> >> Aux fins de cette ?lection, les ?lecteurs ?ligibles comprennent les individus, qu'ils agissent en tant que repr?sentants de Membres de ressources ou autrement, faisant partie de la communaut? Internet africaine et ayant compl?t? le processus d'enregistrement requis pour figurer sur le registre ?lectoral de la communaut?. >> >> Veuillez noter que les individus n'?tant pas un ?lecteur d?sign? d'un Membre de ressources ?ligible doivent avoir figur? sur les listes de diffusion d'AFRINIC (y compris Resource Policy Discussion, Community-Discuss ou Members-Discuss) pendant au moins trois (3) ans imm?diatement avant leur enregistrement en ligne pour la r?union et avoir ?t? valid?s. Se r?f?rer ? la clause 8.2.1 des directives ?lectorales. >> >> >> 3. Deux (2) co-pr?sidents du PDP [bas? sur le consensus] >> Les deux (2) co-pr?sidents du PDP s?lectionn?s se verront attribuer des mandats ?chelonn?s expirant sur deux (2) ann?es cons?cutives : >> >> L'un des candidats s?lectionn?s effectuera, exceptionnellement, un mandat d'un an se terminant lors de la premi?re r?union de politique publique (PPM) suivant l'expiration de ce mandat d'un an ; >> L'autre candidat s?lectionn? effectuera un mandat standard de deux ans se terminant lors de la premi?re PPM suivant l'expiration de son mandat de deux ans, selon le souhait du PDWG lors de ladite PPM. >> >> Par la suite, les futurs rempla?ants rempliront normalement des mandats de deux ans. >> >> Conform?ment ? l'article 11.2 des statuts d'AFRINIC, et afin de donner plein effet au mod?le de gouvernance ascendante (bottom-up) d'AFRINIC, le processus de s?lection qui se tiendra lors de la PPM impliquera des individus, qu'ils agissent en tant que repr?sentants de Membres de ressources ou autrement, faisant partie de la communaut? Internet africaine et ayant compl?t? le processus d'enregistrement requis pour assister ? ladite r?union. >> >> >> Informations G?n?rales et Candidatures >> Le Comit? de nomination 2026 souhaite recevoir des candidatures de toutes les sous-r?gions d'AFRINIC et cherche explicitement ? promouvoir la diversit? tant linguistique que de genre, bien qu'une compr?hension op?rationnelle de la langue anglaise soit requise. >> >> Les crit?res de nomination et les directives ?lectorales sont disponibles sur : http://election.afrinic.net/election-guideline-2026 >> Pour vous pr?senter ou nommer un candidat de votre choix, veuillez remplir le formulaire de nomination correspondant : >> >> ?lections du Comit? de gouvernance : https://forms.afrinic.net/governance-committee-election-2026 >> ?lections NRO NC / ASO AC : https://forms.afrinic.net/nro-nc-aso-ac-election-2026 >> S?lection des co-pr?sidents du PDP : https://forms.afrinic.net/pdp-co-chairs-selection-2026 >> Veuillez noter que chaque candidature doit ?tre soutenue par deux (2) Membres de ressources d'AFRINIC en r?gle. >> >> La p?riode de nomination se terminera le 29 mai 2026 ? 23h59 UTC. >> >> Toute personne condamn?e pour une infraction impliquant la malhonn?tet?, la fraude ou l'abus de confiance ne sera pas ?ligible aux postes susmentionn?s. Le Comit? de nomination se r?serve le droit de disqualifier de la liste finale tout candidat se livrant ? toute forme de faute ?lectorale. >> >> >> Calendrier des elections 2026 >> Le calendrier suivant s'appliquera, dans la mesure du possible : >> >> Ouverture de l'appel ? candidatures : 8 mai 2026 >> Cl?ture de l'appel ? candidatures : 29 mai 2026 >> Examen et v?rification des candidatures : Du 30 mai au 10 juin 2026 >> Publication de la liste finale des candidats : 11 juin 2026 >> P?riode de vote et acc?s ? la plateforme (Comit? de gouvernance & NRO NC / ASO AC) : Au moins 5 jours avant l'AGMM et la PPM (soit le 19 juin 2026). >> Annonce des r?sultats (NRO NC / ASO AC et co-pr?sidents du PDWG) : Pendant la PPM (le 24 juin 2026). >> Annonce des r?sultats (Comit? de gouvernance) : Jour de l'AGMM (le 25 juin 2026). >> >> Dans l'attente de vos candidatures, nous restons ? votre enti?re disposition pour tout compl?ment d'information. >> >> Cordialement >> >> Ganesh Ramalingum >> >> Pr?sident >> >> Comit? de nomination d'AFRINIC 2026 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From comms at afrinic.net Sat May 9 07:38:48 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Sat, 9 May 2026 11:38:48 +0400 Subject: [rpd] AFRINIC Communique - 09 May 2026 Message-ID: Dear Colleagues, AFRINIC has become aware of public statements and publications made by entities associated with ?Larus?. These statements refer to what they describe as a ?Court-Ordered Shareholder-Position Continuity Structure?, allegedly linked to proceedings before the Supreme Court of Mauritius in case reference SC/COM/MOT/000399/2025. AFRINIC wishes to make it clear that the Court Order dated 11 June 2025 did not establish, approve, recognise, or create any such ?Court-Ordered Shareholder-Position Continuity Structure? in relation to AFRINIC. AFRINIC has also noted that some public statements appear to suggest that the Court Order concerns AFRINIC?s statutory register of members, which is maintained under section 91 of the Companies Act 2001. AFRINIC has been advised that the undertaking provided before the Court in the context of the aforesaid proceedings was made, for all intents and purposes, on the premise that the relevant register concerned AFRINIC?s register relating to its resource, and not to AFRINIC?s statutory register of registered members under the Companies Act. To avoid any misunderstanding, AFRINIC is considering the appropriate legal steps before the Supreme Court of Mauritius, as it may be advised. This may include seeking clarification on the exact nature of the register referred to in the Court Order. AFRINIC remains committed to transparency, institutional integrity, and full compliance with all applicable legal and regulatory obligations. AFRINIC also reserves all of its rights in relation to any public statement or publication that inaccurately describes, misrepresents, or implies an incorrect legal effect of any court proceedings involving AFRINIC. Issued by AFRINIC Date 09 May 2026 From comms at afrinic.net Sat May 9 13:46:32 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Sat, 9 May 2026 17:46:32 +0400 Subject: [rpd] Extension of Community Consultation Period on AFRINIC Bylaws Review Message-ID: <2C792C29-A787-4182-969E-6DD79B65297E@afrinic.net> [Version en fran?ais au bas] Dear colleagues, AFRINIC wishes to thank all members and stakeholders for their valuable contributions to the ongoing review of our bylaws. To ensure everyone has sufficient time to provide comprehensive feedback, the deadline for submitting comments and proposed amendments has been extended to 17 May 2026. As the Regional Internet Registry for Africa and the Indian Ocean, we remain dedicated to transparency and inclusive governance. This consultation is vital to ensuring our institutional framework remains robust and fit for purpose. We invite you to share your recommendations via the designated online form (https://forms.afrinic.net/brc-comment). All submissions received by the new deadline will be carefully reviewed by the Committee. Thank you for your continued engagement and support. AFRINIC Bylaws Review Committee ?????????????????? Chers coll?gues, AFRINIC tient ? remercier l?ensemble des membres et des parties prenantes pour leurs pr?cieuses contributions ? la r?vision en cours de nos statuts. Afin de permettre ? chacun de disposer du temps n?cessaire pour formuler des observations compl?tes, la date limite de soumission des commentaires et des propositions d?amendement a ?t? report?e au 17 mai 2026. En tant que Registre Internet R?gional pour l?Afrique et l?oc?an Indien, nous demeurons attach?s ? la transparence et ? une gouvernance inclusive. Cette consultation est essentielle pour garantir que notre cadre institutionnel reste robuste et adapt? ? ses objectifs. Nous vous invitons ? nous faire part de vos recommandations via le formulaire en ligne (https://forms.afrinic.net/brc-comment) pr?vu ? cet effet. Toutes les contributions re?ues d'ici la nouvelle ?ch?ance seront examin?es avec la plus grande attention par le Comit?. Nous vous remercions de votre engagement et de votre soutien continus. Le Comit? de r?vision des statuts de l?AFRINIC -------------- next part -------------- An HTML attachment was scrubbed... URL: From benson_muite at emailplus.org Wed May 13 18:46:01 2026 From: benson_muite at emailplus.org (Benson Muite) Date: Wed, 13 May 2026 21:46:01 +0300 Subject: [rpd] Extension of Community Consultation Period on AFRINIC Bylaws Review In-Reply-To: <2C792C29-A787-4182-969E-6DD79B65297E@afrinic.net> References: <2C792C29-A787-4182-969E-6DD79B65297E@afrinic.net> Message-ID: <8733zvkv12.fsf@emailplus.org> AFRINIC Communication via RPD writes: Will all submissions be made public? A platform such as Decidim (https://decidim.org/) would allow full community participation in the process. There are a number of troubling concerns. It is good to see that there is a possibility for Afrinic to dissolve itself and allow for a reconstitution as a new body - ideally an efficient international NGO rather than as a for profit business. It is unclear if any African country can enact sufficiently strong legislation to support this. > [Version en fran?ais au bas] > > Dear colleagues, > > AFRINIC wishes to thank all members and stakeholders for their valuable contributions to the ongoing review of our bylaws. > > To ensure everyone has sufficient time to provide comprehensive feedback, the deadline for submitting comments and proposed amendments has been extended to 17 May 2026. > > As the Regional Internet Registry for Africa and the Indian Ocean, we remain dedicated to transparency and inclusive governance. This consultation is vital to ensuring our institutional framework remains robust and fit for purpose. > > We invite you to share your recommendations via the designated online form (https://forms.afrinic.net/brc-comment). All submissions received by the new deadline will be carefully reviewed by the Committee. > > Thank you for your continued engagement and support. > > AFRINIC Bylaws Review Committee > > ?????????????????? > > Chers coll?gues, > > AFRINIC tient ? remercier l?ensemble des membres et des parties prenantes pour leurs pr?cieuses contributions ? la r?vision en cours de nos statuts. > > Afin de permettre ? chacun de disposer du temps n?cessaire pour formuler des observations compl?tes, la date limite de soumission des commentaires et des propositions d?amendement a ?t? report?e au 17 mai 2026. > > En tant que Registre Internet R?gional pour l?Afrique et l?oc?an Indien, nous demeurons attach?s ? la transparence et ? une gouvernance inclusive. Cette consultation est essentielle pour garantir que notre cadre institutionnel reste robuste et adapt? ? ses objectifs. > > Nous vous invitons ? nous faire part de vos recommandations via le formulaire en ligne (https://forms.afrinic.net/brc-comment) pr?vu ? cet effet. Toutes les contributions re?ues d'ici la nouvelle ?ch?ance seront examin?es avec la plus grande attention par le Comit?. > > Nous vous remercions de votre engagement et de votre soutien continus. > > Le Comit? de r?vision des statuts de l?AFRINIC > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From comms at afrinic.net Thu May 14 15:20:11 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Thu, 14 May 2026 19:20:11 +0400 Subject: [rpd] =?utf-8?q?Register_for_the__=E2=80=9CUnderstanding_the_AFRI?= =?utf-8?q?NIC_Policy_Development_Process_=28PDP=29=E2=80=9D_Webinar=2C_21?= =?utf-8?q?st_May_2026=2C_10=3A00_UTC=2E?= Message-ID: [Version en fran?ais au bas] Dear colleagues, Register for this insightful webinar on the AFRINIC Policy Development Process (PDP), a community-driven framework through which policies governing the allocation and management of Internet number resources across the AFRINIC service region are developed and refined. Founded on the principles of openness, inclusivity, and consensus, the PDP empowers stakeholders to actively contribute to decisions that shape the Internet ecosystem in Africa and the Indian Ocean region. A sound understanding of this process is essential for organisations and individuals involved in Internet governance, operations, and resource management. Webinar Details. Date: 21st May 2026 Time: 10:00 UTC (1 hour) Register now https://us02web.zoom.us/webinar/register/2617785824932/WN_K8780adkSIWWHMUHrbpkVw#/registration Key Objectives Build a clear understanding of how the PDP functions. Outline the process for developing and presenting policy proposals. Illustrate how rough consensus is achieved. Encourage active and informed participation in policy discussions. Panelists: Mr. Vincent Ngundi, PDP Co-Chair Mr. Darwin Da Costa, PDP Co-Chair Mrs. Madhvi Gokool, Policy Liaison, AFRINIC Mr. Brice Abba, Policy Liaison, AFRINIC We look forward to welcoming you. Kind Regards, AFRINIC Communication ?????????????????????????????????????????????????????????... Inscrivez-vous au webinaire ? Understanding the AFRINIC Policy Development Process (PDP) ?, le 21 mai 2026 ? 10h00 UTC. Chers coll?gues, Inscrivez-vous ? ce webinaire instructif sur le processus d??laboration des politiques (PDP) d?AFRINIC, un cadre collaboratif ? travers lequel la communaut? ?labore, examine et affine les politiques r?gissant l?allocation et la gestion des ressources de num?rotation Internet dans la r?gion de service d?AFRINIC. Fond? sur les principes d'ouverture, d'inclusivit? et de consensus, le PDP permet aux parties prenantes de contribuer activement aux d?cisions qui fa?onnent l'?cosyst?me Internet en Afrique et dans la r?gion de l'oc?an Indien. Une bonne compr?hension de ce processus est essentielle pour les organisations et les personnes impliqu?es dans la gouvernance, les op?rations et la gestion des ressources Internet. D?tails du webinaire Date : 21 mai 2026 Heure : 10h00 UTC (dur?e : 1 heure) Inscrivez-vous d?s maintenant https://us02web.zoom.us/webinar/register/2617785824932/WN_K8780adkSIWWHMUHrbpkVw#/registration Objectifs cl?s D?velopper une compr?hension claire du fonctionnement du PDP. Pr?senter le processus d'?laboration et de pr?sentation des propositions de politiques. Illustrer la mani?re dont un consensus g?n?ral (rough consensus) est atteint. Encourager une participation active et ?clair?e aux discussions sur les politiques. Intervenants : M. Vincent Ngundi, Co-pr?sident du PDP M. Darwin Da Costa, Co-pr?sident du PDP Mme Madhvi Gokool, Liaison politique, AFRINIC M. Brice Abba, Liaison politique, AFRINIC Dans l'attente de vous accueillir. Cordialement, Communication d?AFRINIC -------------- next part -------------- An HTML attachment was scrubbed... URL: From comms at afrinic.net Fri May 15 13:08:26 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Fri, 15 May 2026 17:08:26 +0400 Subject: [rpd] =?utf-8?q?AFRINIC_Communiqu=C3=A9=3A_15_May_2026?= Message-ID: Dear Colleagues, The African Network Information Centre (AfriNIC) Ltd, also known as AFRINIC, wishes to inform its members, resource holders, stakeholders, and the broader Internet community that the Supreme Court of Mauritius has, on 14 May 2026, issued an Interim Order (https://afrinic.net/ast/pdf/Rule_Afrinic-150526_Redacted.pdf) against Cloud Innovation Ltd following the publication of false and misleading statements disseminated through its subsidiary, Larus Ltd. In particular, the publication had incorrectly represented that the Supreme Court of Mauritius had sanctioned or otherwise authorised the leasing of AFRINIC-allocated Internet number resources, including IP address resources. AFRINIC wishes to reiterate, further to its communiqu? dated 09 May 2026 (https://afrinic.net/afrinic-communique-09052026) and in the clearest possible terms, that the said publication does not accurately reflect the position of the Supreme Court of Mauritius and is misleading in nature. The aforementioned Interim Order (https://afrinic.net/ast/pdf/case_73_555-2025-140526_Redacted.pdf) issued by the Supreme Court of Mauritius expressly addresses the matter and confirms the legal position in relation thereto. AFRINIC further reiterates that Internet number resources allocated by AFRINIC are governed by the applicable registration policies, contractual framework, and the established principles underpinning the Regional Internet Registry (RIR) system. Any representation suggesting judicial sanctioning of arrangements outside such framework is categorically denied unless expressly determined by a competent court. Additionally, AFRINIC considers it both opportune and appropriate to inform its members and the broader Internet community that, in relation to the winding-up petition initiated by Cloud Innovation Ltd against AFRINIC in July 2025 under matter reference SC/COM/PET/000508/2025, the Supreme Court of Mauritius has, on 14 May 2026,also granted an Order formally allowing ICANN to intervene as a party in the proceedings. Details providing an overview of the series of proceedings initiated by Cloud Innovation Ltd against AFRINIC since 2021, which AFRINIC considers to be frivolous and vexatious, are available at: https://afrinic.net/court-cases. AFRINIC remains committed to ensuring transparency, accuracy of information, and the protection of the integrity of the Internet number resource administration system for the African and Indian Ocean region. Issued by: AFRINIC 15 May 2026 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbemiadepojuesho at gmail.com Fri May 15 13:18:04 2026 From: gbemiadepojuesho at gmail.com (Gbemisola Esho) Date: Fri, 15 May 2026 14:18:04 +0100 Subject: [rpd] =?utf-8?q?AFRINIC_Communiqu=C3=A9=3A_15_May_2026?= In-Reply-To: References: Message-ID: Dear AFIRINIC, Thank you for your email and for the clarifications. We look forward to more good neqs as AFRINIC retains its position and sovereignity as the conitent RIR . Regards Gbemisola Esho On Fri, 15 May 2026, 14:11 AFRINIC Communication via RPD, wrote: > Dear Colleagues, > > The African Network Information Centre (AfriNIC) Ltd, also known as > AFRINIC, wishes to inform its members, resource holders, stakeholders, and > the broader Internet community that the Supreme Court of Mauritius has, on > 14 May 2026, issued an Interim Order > ( > https://afrinic.net/ast/pdf/Rule_Afrinic-150526_Redacted.pdf) > against Cloud Innovation Ltd following the publication of false and > misleading statements disseminated through its subsidiary, Larus Ltd. > > In particular, the publication had incorrectly represented that the > Supreme Court of Mauritius had sanctioned or otherwise authorised the > leasing of AFRINIC-allocated Internet number resources, including IP > address resources. > > AFRINIC wishes to reiterate, further to its communiqu? dated 09 May 2026 > ( > https://afrinic.net/afrinic-communique-09052026) and in the clearest > possible terms, that the said publication does not accurately reflect the > position of the Supreme Court of Mauritius and is misleading in nature. > > The aforementioned Interim Order > ( > https://afrinic.net/ast/pdf/case_73_555-2025-140526_Redacted.pdf) issued > by the Supreme Court of Mauritius expressly addresses the matter and > confirms the legal position in relation thereto. > > AFRINIC further reiterates that Internet number resources allocated by > AFRINIC are governed by the applicable registration policies, contractual > framework, and the established principles underpinning the Regional > Internet Registry (RIR) system. Any representation suggesting judicial > sanctioning of arrangements outside such framework is categorically denied > unless expressly determined by a competent court. > > Additionally, AFRINIC considers it both opportune and appropriate to > inform its members and the broader Internet community that, in relation to > the winding-up petition initiated by Cloud Innovation Ltd against AFRINIC > in July 2025 under matter reference SC/COM/PET/000508/2025, the Supreme > Court of Mauritius has, on 14 May 2026,also granted an Order formally > allowing ICANN to intervene as a party in the proceedings. Details > providing an overview of the series of proceedings initiated by Cloud > Innovation Ltd against AFRINIC since 2021, which AFRINIC considers to be > frivolous and vexatious, are available at: https://afrinic.net/court-cases > . > > AFRINIC remains committed to ensuring transparency, accuracy of > information, and the protection of the integrity of the Internet number > resource administration system for the African and Indian Ocean region. > > Issued by: > AFRINIC > 15 May 2026 > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From comms at afrinic.net Fri May 15 14:20:52 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Fri, 15 May 2026 18:20:52 +0400 Subject: [rpd] =?utf-8?q?AFRINIC_Communiqu=C3=A9=3A_15_May_2026?= In-Reply-To: References: Message-ID: Dear Colleagues, Please disregard the previous email. The following communication refers. ???????. The African Network Information Centre (AfriNIC) Ltd, also known as AFRINIC, wishes to inform its members, resource holders, stakeholders, and the broader Internet community that the Supreme Court of Mauritius has, on 14 May 2026, issued an Interim Order (https://afrinic.net/ast/pdf/Rule_Afrinic-150526_Redacted.pdf) against Cloud Innovation Ltd following the publication of false and misleading statements disseminated through its subsidiary, Larus Ltd. In particular, the publication had incorrectly represented that the Supreme Court of Mauritius had sanctioned or otherwise authorised the leasing of AFRINIC-allocated Internet number resources, including IP address resources. AFRINIC wishes to reiterate, further to its communiqu? dated 09 May 2026 (https://afrinic.net/afrinic-communique-09052026) and in the clearest possible terms, that the said publication does not accurately reflect the position of the Supreme Court of Mauritius and is misleading in nature. The aforementioned Interim Order issued by the Supreme Court of Mauritius expressly addresses the matter and confirms the legal position in relation thereto. AFRINIC further reiterates that Internet number resources allocated by AFRINIC are governed by the applicable registration policies, contractual framework, and the established principles underpinning the Regional Internet Registry (RIR) system. Any representation suggesting judicial sanctioning of arrangements outside such framework is categorically denied unless expressly determined by a competent court. Additionally, AFRINIC considers it both opportune and appropriate to inform its members and the broader Internet community that, in relation to the winding-up petition initiated by Cloud Innovation Ltdagainst AFRINIC in July 2025 under matter reference SC/COM/PET/000508/2025, the Supreme Court of Mauritius has, on 14 May 2026, also granted an Order (https://afrinic.net/ast/pdf/case_73_555-2025-140526_Redacted.pdf) formally allowing ICANN to intervene as a party in the proceedings. Details providing an overview of the series of proceedings initiated by Cloud Innovation Ltd against AFRINIC since 2021, which AFRINIC considers to be frivolous and vexatious, are available at: https://afrinic.net/court-cases AFRINIC remains committed to ensuring transparency, accuracy of information, and the protection of the integrity of the Internet number resource administration system for the African and Indian Ocean region. Issued by: AFRINIC 15 May 2026 > On 15 May 2026, at 17:08, AFRINIC Communication wrote: > > Dear Colleagues, > > The African Network Information Centre (AfriNIC) Ltd, also known as AFRINIC, wishes to inform its members, resource holders, stakeholders, and the broader Internet community that the Supreme Court of Mauritius has, on 14 May 2026, issued an Interim Order (https://afrinic.net/ast/pdf/Rule_Afrinic-150526_Redacted.pdf) against Cloud Innovation Ltd following the publication of false and misleading statements disseminated through its subsidiary, Larus Ltd. > > In particular, the publication had incorrectly represented that the Supreme Court of Mauritius had sanctioned or otherwise authorised the leasing of AFRINIC-allocated Internet number resources, including IP address resources. > > AFRINIC wishes to reiterate, further to its communiqu? dated 09 May 2026 (https://afrinic.net/afrinic-communique-09052026) and in the clearest possible terms, that the said publication does not accurately reflect the position of the Supreme Court of Mauritius and is misleading in nature. > > The aforementioned Interim Order (https://afrinic.net/ast/pdf/case_73_555-2025-140526_Redacted.pdf) issued by the Supreme Court of Mauritius expressly addresses the matter and confirms the legal position in relation thereto. > > AFRINIC further reiterates that Internet number resources allocated by AFRINIC are governed by the applicable registration policies, contractual framework, and the established principles underpinning the Regional Internet Registry (RIR) system. Any representation suggesting judicial sanctioning of arrangements outside such framework is categorically denied unless expressly determined by a competent court. > > Additionally, AFRINIC considers it both opportune and appropriate to inform its members and the broader Internet community that, in relation to the winding-up petition initiated by Cloud Innovation Ltd against AFRINIC in July 2025 under matter reference SC/COM/PET/000508/2025, the Supreme Court of Mauritius has, on 14 May 2026,also granted an Order formally allowing ICANN to intervene as a party in the proceedings. Details providing an overview of the series of proceedings initiated by Cloud Innovation Ltd against AFRINIC since 2021, which AFRINIC considers to be frivolous and vexatious, are available at: https://afrinic.net/court-cases. > > AFRINIC remains committed to ensuring transparency, accuracy of information, and the protection of the integrity of the Internet number resource administration system for the African and Indian Ocean region. > > Issued by: > AFRINIC > 15 May 2026 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fhfrediani at gmail.com Fri May 15 14:41:59 2026 From: fhfrediani at gmail.com (Fernando Frediani) Date: Fri, 15 May 2026 11:41:59 -0300 Subject: [rpd] =?utf-8?q?AFRINIC_Communiqu=C3=A9=3A_15_May_2026?= In-Reply-To: References: Message-ID: This sounds good news to African region and whole internet ecosystem. It is always important to highlight that the continue tentative to treat IP addresses as private property and keep believing that IP leasing is something normal and acceptable, with the excuse that the IPv4 exhaustion justifies it will not prevail. Members of all RIRs must understand there are policies in place and they must be obeyed regardless if they agree or not, if they find it fair or not. A contract has been signed agreeing to that. There are proper processes in place to change policies and nobody should consider that bypassing the current rules is something that will go unnoticed without sanctions. Regards On 5/15/2026 10:08 AM, AFRINIC Communication via RPD wrote: > Dear Colleagues, > > The African Network Information Centre (AfriNIC) Ltd, also known as > AFRINIC, wishes to inform its members, resource holders, stakeholders, > and the broader Internet community that the Supreme Court of Mauritius > has, on 14 May 2026, issued an Interim Order > ?(https://afrinic.net/ast/pdf/Rule_Afrinic-150526_Redacted.pdf) > against?Cloud Innovation Ltd?following the publication of false and > misleading statements disseminated through its subsidiary,?Larus Ltd. > > In particular, the publication had incorrectly represented that the > Supreme Court of Mauritius had sanctioned or otherwise authorised the > leasing of AFRINIC-allocated Internet number resources, including IP > address resources. > > AFRINIC wishes to reiterate, further to its communiqu? dated 09 May > 2026 > ?(https://afrinic.net/afrinic-communique-09052026) > and in the clearest possible terms, that the said publication does not > accurately reflect the position of the Supreme Court of Mauritius and > is misleading in nature. > > The aforementioned Interim Order > ?(https://afrinic.net/ast/pdf/case_73_555-2025-140526_Redacted.pdf) > issued by the Supreme Court of Mauritius expressly addresses the > matter and confirms the legal position in relation thereto. > > AFRINIC further reiterates that Internet number resources allocated by > AFRINIC are governed by the applicable registration policies, > contractual framework, and the established principles underpinning the > Regional Internet Registry (RIR) system. Any representation suggesting > judicial sanctioning of arrangements outside such framework is > categorically denied unless expressly determined by a competent court. > > Additionally, AFRINIC considers it both opportune and appropriate to > inform its members and the broader Internet community that, in > relation to the winding-up petition initiated by?Cloud Innovation > Ltd?against AFRINIC in July 2025 under matter reference > SC/COM/PET/000508/2025, the Supreme Court of Mauritius has, on 14 May > 2026,also granted an?Order?formally allowing ICANN to intervene as a > party in the proceedings.??Details providing an overview of the series > of proceedings initiated by Cloud Innovation Ltd against AFRINIC since > 2021, which AFRINIC considers to be frivolous and vexatious, are > available at: https://afrinic.net/court-cases. > > AFRINIC remains committed to ensuring transparency, accuracy of > information, and the protection of the integrity of the Internet > number resource administration system for the African and Indian Ocean > region. > > Issued by: > AFRINIC > 15 May 2026 > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From dacostadarwin at gmail.com Fri May 15 15:46:40 2026 From: dacostadarwin at gmail.com (dacostadarwin at gmail.com) Date: Fri, 15 May 2026 17:46:40 +0200 Subject: [rpd] Soft Landing, Recovered Space and Priority AFPUB-2026-IPv4-001-DRAFT01. Message-ID: <0EDA090C-E6CB-4A9E-BB96-CBFD336FFD53@gmail.com> Dear PDWG, We have received a new draft policy proposal - Soft Landing, Recovered Space and Priority, ID AFPUB-2026-IPv4-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: https://afrinic.net/policy/proposals/afpub-2026-ipv4-001-draft01 We encourage you to take some time to go through the proposal contents and provide feedback as follows: a) Do you support or oppose the proposal? b) If you oppose the proposal, state your reasons? c) Is there anything in the proposal that is not clear? d) What changes could be made to this proposal to make it more effective? Regards, Vincent Ngundi & Darwin Da Costa AFRINIC PDWG Co-Chairs. From dacostadarwin at gmail.com Fri May 15 15:51:17 2026 From: dacostadarwin at gmail.com (dacostadarwin at gmail.com) Date: Fri, 15 May 2026 17:51:17 +0200 Subject: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01. Message-ID: Dear PDWG, We have received a new draft policy proposal - Amendment of Utilisation in Soft Landing, ID AFPUB-2026-IPv4-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: https://afrinic.net/policy/proposals/afpub-2026-ipv4-002-draft01 We encourage you to take some time to go through the proposal contents and provide feedback as follows : a) Do you support or oppose the proposal? b) If you oppose the proposal, state your reasons? c) Is there anything in the proposal that is not clear? d) What changes could be made to this proposal to make it more effective? Regards, Vincent Ngundi & Darwin Da Costa AFRINIC PDWG Co-Chairs From comms at afrinic.net Tue May 19 12:04:21 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Tue, 19 May 2026 16:04:21 +0400 Subject: [rpd] =?utf-8?q?Reminder=3A_Register_for_the__=E2=80=9CUnderstand?= =?utf-8?q?ing_the_AFRINIC_Policy_Development_Process_=28PDP=29=E2=80=9D_W?= =?utf-8?q?ebinar=2C_21st_May_2026=2C_10=3A00_UTC=2E?= Message-ID: <390B78CF-F8D0-4D7A-9C2B-2DEE8398EA88@afrinic.net> [Version en fran?ais au bas] Dear colleagues, Registration is ongoing for this insightful webinar on the AFRINIC Policy Development Process (PDP), a community-driven framework through which policies governing the allocation and management of Internet number resources across the AFRINIC service region are developed and refined. Founded on the principles of openness, inclusivity, and consensus, the PDP empowers stakeholders to actively contribute to decisions that shape the Internet ecosystem in Africa and the Indian Ocean region. A sound understanding of this process is essential for organisations and individuals involved in Internet governance, operations, and resource management. Webinar Details. Date: 21st May 2026 Time: 10:00 UTC (1 hour) Register now: https://us02web.zoom.us/webinar/register/2617785824932/WN_K8780adkSIWWHMUHrbpkVw#/registration Key Objectives ? Build a clear understanding of how the PDP functions. ? Outline the process for developing and presenting policy proposals. ? Illustrate how rough consensus is achieved. ? Encourage active and informed participation in policy discussions. Panelists: ? Mr. Vincent Ngundi, PDP Co-Chair ? Mr. Darwin Da Costa, PDP Co-Chair ? Mrs. Madhvi Gokool, Policy Liaison, AFRINIC ? Mr. Brice Abba, Policy Liaison, AFRINIC We look forward to welcoming you. Kind Regards, AFRINIC Communication ????????????????. Rappel : Inscrivez-vous au webinaire ? Understanding the AFRINIC Policy Development Process (PDP) ?, le 21 mai 2026 ? 10h00 UTC. Chers Membres de la communaut?, Les inscriptions se poursuivent pour le webinaire informatif sur le processus d??laboration des politiques (PDP) d?AFRINIC, un cadre collaboratif ? travers lequel la communaut? ?labore, examine et affine les politiques r?gissant l?allocation et la gestion des ressources de num?rotation Internet (adresses IP) dans la r?gion de service d?AFRINIC. Fond? sur les principes d'ouverture, d'inclusivit? et de consensus, le PDP permet aux parties prenantes de contribuer activement aux d?cisions qui fa?onnent l'?cosyst?me Internet en Afrique et dans la r?gion de l'oc?an Indien. Une bonne compr?hension de ce processus est essentielle pour les organisations et les personnes impliqu?es dans la gouvernance, les op?rations et la gestion des ressources Internet. D?tails du webinaire ? Date : 21 mai 2026 Heure : 10h00 UTC (1 heure) ? Lien d?inscriptiont: https://us02web.zoom.us/webinar/register/2617785824932/WN_K8780adkSIWWHMUHrbpkVw#/registration Objectifs cl?s ? Comprendre le fonctionnement du processus d??laboration des politiques ? Expliquer comment une proposition de politique est pr?par?e et pr?sent?e. ? Montrer comment la communaut? arrive ? un consensus g?n?ral. ? Encourager chacun ? participer activement et de mani?re inform?e aux discussions sur les politiques. Intervenants : ? M. Vincent Ngundi, Co-pr?sident du PDP ? M. Darwin Da Costa, Co-pr?sident du PDP ? Mme Madhvi Gokool, Liaison politique, AFRINIC ? M. Brice Abba, Liaison politique, AFRINIC Dans l'attente de votre participation effective, Cordialement, Communication d?AFRINIC -------------- next part -------------- An HTML attachment was scrubbed... URL: From comms at afrinic.net Tue May 19 13:11:09 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Tue, 19 May 2026 17:11:09 +0400 Subject: [rpd] Statement from the Bylaws Review Committee on its Independence and Integrity Message-ID: <441CECC6-2583-4824-B6AD-C777859FCAD2@afrinic.net> [Version en fran?ais au bas] Dear Colleagues, The Bylaws Review Committee has been made aware of a purported email circulated on or about 07 May 2026 by the Number Resource Society, titled ?ISPA?s bylaw plan turns your AFRINIC rights into a gym membership?, which allegedly suggests that the current AFRINIC bylaws review exercise is being driven by a single controlling organisation. The Committee wishes to reassure AFRINIC?s resource members, as well as the wider Internet community, that it is composed of representatives from each of AFRINIC?s geographical regions, and that its members are fully cognisant of their obligations to act independently, impartially, and in the best interests of the community. Accordingly, the Committee strongly condemns any statement or insinuation that seeks to call into question its independence, integrity, or impartiality. Kind regards, Kishna Dhondee *For and on behalf of the Bylaws Review Committee* ????????????????????????.. Chers membres de la communaut?, Le Comit? de r?vision des statuts d?AFRINIC a ?t? inform? de la circulation, le 07 mai 2026, d'un pr?tendu courrier ?lectronique ?manant de la Number Resource Society et intitul? ? ISPA?s bylaw plan turns your AFRINIC rights into a gym membership?. Ce message laisserait entendre que l'exercice actuel de r?vision des statuts d'AFRINIC serait men? par une seule organisation de contr?le. Le Comit? tient ? rassurer les membres ressources d'AFRINIC, ainsi que l'ensemble de la communaut? Internet, sur le fait qu'il est constitu? de repr?sentants de chacune des r?gions g?ographiques d'AFRINIC, et que ses membres sont pleinement conscients de leur obligation d'agir de mani?re ind?pendante, impartiale et dans le meilleur int?r?t de la communaut?. Par cons?quent, le Comit? de r?vision des statuts d?AFRINIC condamne fermement toute d?claration ou insinuation visant ? remettre en cause son ind?pendance, son int?grit? ou son impartialit?. Veuillez agr?er, chers membres de la Communaut?, l'expression de nos salutations distingu?es. Kishna Dhondee Pour et au nom du Comit? de r?vision des statuts d?AFRINIC From comms at afrinic.net Wed May 20 15:53:44 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Wed, 20 May 2026 19:53:44 +0400 Subject: [rpd] Reminder: Call for Candidates for AFRINIC 2026 Elections Message-ID: <507F2966-FEF1-4D7F-8AF8-B8A0BCCE1609@afrinic.net> [Version en fran?ais au bas] Dear Colleagues, AFRINIC is at an important turning point. As we continue rebuilding our African Internet Registry, we need committed, credible, and service-minded people who are ready to contribute to the future of this esteemed institution and to the development of the Internet across our continent. The Nomination Committee 2026 is calling for nominations for the following positions: ? Three (3) seats on the Governance Committee ? Two (2) seats for the NRO NC / ASO AC community representatives ? Two (2) PDP Co-Chair positions These roles are not symbolic. They are designed for people who believe in accountability, transparency, bottom-up governance, responsible management of Internet number resources, and the long-term stability of Africa?s Internet ecosystem. If you have the experience, commitment, integrity, and willingness to serve the African Internet community, this is the right moment to step forward. We also strongly encourage nominations from all African sub-regions, including women, young professionals, experienced technical experts, policy contributors, and members of our English, French, Arabic, and Portuguese-speaking communities. You may nominate yourself or nominate a qualified candidate. Nomination forms: ? Governance Committee: https://forms.afrinic.net/governance-committee-election-2026 ? NRO NC / ASO AC: https://forms.afrinic.net/nro-nc-aso-ac-election-2026 ? PDP Co-Chairs: https://forms.afrinic.net/pdp-co-chairs-selection-2026 Each candidature must be supported by two AFRINIC Resource Members in good standing. The deadline for nominations is 29 May 2026 at 23:59 UTC. Let us build the future of AFRINIC together, with competence, responsibility, and commitment to Africa. Yours sincerely, Ganesh Ramalingum NomCom Chair ______________________________________________________________________ Chers membres de la communaut?, AFRINIC est ? un tournant important de son histoire. Alors que nous poursuivons la reconstruction de notre registre Internet africain, nous avons besoin de personnes engag?es, cr?dibles et anim?es par le sens du service, pr?tes ? contribuer ? l'avenir de cette prestigieuse institution et au d?veloppement d'Internet sur l'ensemble de notre continent. Le Comit? de nomination 2026 lance un appel ? candidatures pour les postes suivants: ? Trois (3) si?ges au sein du Comit? de gouvernance ? Deux (2) si?ges de repr?sentants de la communaut? pour le NRO NC / ASO AC ? Deux (2) postes de copr?sidents du PDP (Processus de d?veloppement des politiques) Ces r?les ne sont pas symboliques. Ils sont con?us pour des personnes qui croient en la responsabilit?, la transparence, la gouvernance ascendante, la gestion responsable des ressources de num?rotation Internet et la stabilit? ? long terme de l'?cosyst?me Internet africain. Si vous poss?dez l'exp?rience, l'engagement, l'int?grit? et la volont? de servir la communaut? Internet africaine, c'est le moment id?al pour vous pr?senter. Nous encourageons les candidatures issues de toutes les sous-r?gions africaines, y compris les femmes, les jeunes professionnels, les experts techniques chevronn?s, les contributeurs aux politiques, ainsi que les membres de nos communaut?s anglophones, francophones, arabophones et lusophones. Vous pouvez proposer votre propre candidature ou parrainer un candidat qualifi? ? travers les Formulaires de candidature : ? Comit? de gouvernance : https://forms.afrinic.net/governance-committee-election-2026 ? NRO NC / ASO AC : https://forms.afrinic.net/nro-nc-aso-ac-election-2026 ? Copr?sidents du PDP : https://forms.afrinic.net/pdp-co-chairs-selection-2026 Chaque candidature doit ?tre endoss?e par deux membres-ressources d?AFRINIC en r?gle. La date limite de d?p?t des candidatures est fix?e au 29 mai 2026 ? 23h59 UTC. Construisons ensemble l'avenir d'AFRINIC, avec le sens de comp?tence, de responsabilit? et d'engagement envers l?Afrique. Cordialement, Ganesh Ramalingum NomCom Chair -------------- next part -------------- An HTML attachment was scrubbed... URL: From dacostadarwin at gmail.com Wed May 20 17:37:44 2026 From: dacostadarwin at gmail.com (dacostadarwin at gmail.com) Date: Wed, 20 May 2026 19:37:44 +0200 Subject: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. Message-ID: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> Dear PDWG, We have received a new draft policy proposal - Require newly created AS-SETs to have hierarchical names, ID AFPUB-2026-ASN-001-DRAFT01 from author James Bensley. The proposal contents are published at: https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft01 We encourage you to take some time to go through the proposal contents and provide feedback as follows: a) Do you support or oppose the proposal? b) If you oppose the proposal, state your reasons? c) Is there anything in the proposal that is not clear? d) What changes could be made to this proposal to make it more effective? Regards, Vincent Ngundi & Darwin Da Costa AFRINIC PDWG Co-Chairs From jordi.palet at consulintel.es Thu May 21 08:45:19 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Thu, 21 May 2026 10:45:19 +0200 Subject: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. In-Reply-To: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> References: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> Message-ID: Hi, I believe this is a good proposal and we should do it. Tks! Regards, Jordi @jordipalet > El 20 may 2026, a las 19:37, dacostadarwin at gmail.com escribi?: > > Dear PDWG, > > We have received a new draft policy proposal - Require newly created AS-SETs to have hierarchical names, ID AFPUB-2026-ASN-001-DRAFT01 from author James Bensley. > > The proposal contents are published at: > https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft01 > > We encourage you to take some time to go through the proposal contents and provide feedback as follows: > > a) Do you support or oppose the proposal? > > b) If you oppose the proposal, state your reasons? > > c) Is there anything in the proposal that is not clear? > > d) What changes could be made to this proposal to make it more effective? > > Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From mark at posix.co.za Thu May 21 11:14:17 2026 From: mark at posix.co.za (Mark Elkins) Date: Thu, 21 May 2026 13:14:17 +0200 Subject: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer In-Reply-To: References: Message-ID: Still waiting to hear how this becomes implemented - and to show that I do read and reply to the RPD! On 2026/02/09 08:45, Madhvi Gokool via RPD wrote: > > ** > > * > > Dear PDWG Members, > > We refer to the PDWG Chairs report on the draft policy proposal > AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer > dated 14 January 2022 and sent to the AFRINIC Board of Directors for > ratification. The Board has also taken note of the report of the > Policy Liaison dated? 24 October 2025. > > We wish to inform you that the AFRINIC Board, at its meeting held on 4 > February 2026, considered the PDWG Chairs' recommendation and > resolved,with the consent of the Receiver,? that the above policy > proposal be ratified. > > > The? AFRINIC Secretariat will revert back on the implementation. > > > Kind Regards, > > Madhvi Gokool & Brice Abba > > Policy Liaisons > > * > * > > References :- > > Policy Proposal - https://afrinic.net/policy/proposals/2020-gen-006-d3 > > PDWG Chairs Report - > https://lists.afrinic.net/pipermail/rpd/2022/014142.html > > > Kind Regards, > > Madhvi Gokool & Brice Abba > > * > -- > AFRINIC Policy Liaison. > t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net > facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -- Mark James ELKINS? -? Posix Systems - (South) Africa mje at posix.co.za?????? Tel: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za Posix SystemsVCARD for MJ Elkins -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: abessive_logo.jpg Type: image/jpeg Size: 6410 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: QR-MJElkins.png Type: image/png Size: 2163 bytes Desc: not available URL: From owen at delong.com Thu May 21 11:30:41 2026 From: owen at delong.com (Owen DeLong) Date: Thu, 21 May 2026 04:30:41 -0700 Subject: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer In-Reply-To: References: Message-ID: <5BC824B3-E8E4-4509-B889-F3EC22391861@delong.com> Ratification of this policy only serves to prove that the board remains capable of absurdity. As written, the policy requires an out-of-region recipient allowed by the policy to comply with AFRINC policies, sign an AfriNIX RSA, etc. (section 3.6). Ridiculous. Owen > On Feb 8, 2026, at 22:45, Madhvi Gokool via RPD wrote: > > Dear PDWG Members, > > We refer to the PDWG Chairs report on the draft policy proposal AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer dated 14 January 2022 and sent to the AFRINIC Board of Directors for ratification. The Board has also taken note of the report of the Policy Liaison dated 24 October 2025. > We wish to inform you that the AFRINIC Board, at its meeting held on 4 February 2026, considered the PDWG Chairs' recommendation and resolved,with the consent of the Receiver, that the above policy proposal be ratified. > > The AFRINIC Secretariat will revert back on the implementation. > > Kind Regards, > Madhvi Gokool & Brice Abba > Policy Liaisons > > > References :- > Policy Proposal - https://afrinic.net/policy/proposals/2020-gen-006-d3 > PDWG Chairs Report - https://lists.afrinic.net/pipermail/rpd/2022/014142.html > > Kind Regards, > Madhvi Gokool & Brice Abba > -- > AFRINIC Policy Liaison. > t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net > facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu May 21 11:30:41 2026 From: owen at delong.com (Owen DeLong) Date: Thu, 21 May 2026 04:30:41 -0700 Subject: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer In-Reply-To: References: Message-ID: <5BC824B3-E8E4-4509-B889-F3EC22391861@delong.com> Ratification of this policy only serves to prove that the board remains capable of absurdity. As written, the policy requires an out-of-region recipient allowed by the policy to comply with AFRINC policies, sign an AfriNIX RSA, etc. (section 3.6). Ridiculous. Owen > On Feb 8, 2026, at 22:45, Madhvi Gokool via RPD wrote: > > Dear PDWG Members, > > We refer to the PDWG Chairs report on the draft policy proposal AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer dated 14 January 2022 and sent to the AFRINIC Board of Directors for ratification. The Board has also taken note of the report of the Policy Liaison dated 24 October 2025. > We wish to inform you that the AFRINIC Board, at its meeting held on 4 February 2026, considered the PDWG Chairs' recommendation and resolved,with the consent of the Receiver, that the above policy proposal be ratified. > > The AFRINIC Secretariat will revert back on the implementation. > > Kind Regards, > Madhvi Gokool & Brice Abba > Policy Liaisons > > > References :- > Policy Proposal - https://afrinic.net/policy/proposals/2020-gen-006-d3 > PDWG Chairs Report - https://lists.afrinic.net/pipermail/rpd/2022/014142.html > > Kind Regards, > Madhvi Gokool & Brice Abba > -- > AFRINIC Policy Liaison. > t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net > facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu May 21 12:45:53 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Thu, 21 May 2026 14:45:53 +0200 Subject: [rpd] Soft Landing, Recovered Space and Priority AFPUB-2026-IPv4-001-DRAFT01. In-Reply-To: <0EDA090C-E6CB-4A9E-BB96-CBFD336FFD53@gmail.com> References: <0EDA090C-E6CB-4A9E-BB96-CBFD336FFD53@gmail.com> Message-ID: Hi all, I just want to make a short intro to this proposal, aiming to create, hopefully, some discussion. This proposal aims to resolve in a single step, most of the conflicts that have been raised by the staff and summarized here: https://www.afrinic.net/policy/implementation-reports/pier-summary Those conflicts are because the soft landing policy takes over some of the articles in other parts of the CPM. This proposal address that by basically stating that in case of conflict, soft-landing articles will have higher priority and actually removing 3 articles and rewording one more, to avoid confusion for anyone reading the CPM. This is the actual way the staff is doing for any request for IPv4 addresses, so basically, the proposal doesn?t imply changes in the actual evaluation process, just ensuring that there are no misinterpretations or confusions. Please, let me know if you feel that something is broken or can be improved or whatever. Note that this proposal doesn?t prevent the community to improve the soft-landing policy, for example regarding what do to with the IPv4 addresses being recovered, but reaching consensus in changes to soft landing, probably can take longer discussion cycles. Tks! Regards, Jordi @jordipalet > El 15 may 2026, a las 17:46, dacostadarwin at gmail.com escribi?: > > Dear PDWG, > > We have received a new draft policy proposal - Soft Landing, Recovered Space and Priority, ID AFPUB-2026-IPv4-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: > > https://afrinic.net/policy/proposals/afpub-2026-ipv4-001-draft01 > > We encourage you to take some time to go through the proposal contents and provide feedback as follows: > > a) Do you support or oppose the proposal? > b) If you oppose the proposal, state your reasons? > c) Is there anything in the proposal that is not clear? > d) What changes could be made to this proposal to make it more effective? > > > Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs. > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Thu May 21 13:06:55 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Thu, 21 May 2026 15:06:55 +0200 Subject: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. In-Reply-To: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> References: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> Message-ID: Hi, Definitely in support. The only thing that I found weird is that the second element has to be a name, why would "ASnum:ASnum2:AS-name" not be acceptable? The purpose/function of "3. Other set types such as route sets are excluded." is unclear - everything else speaks specifically to AS-SET so why is this mention required? Kind regards, Jaco On 2026/05/20 19:37, dacostadarwin at gmail.com wrote: > Dear PDWG, > > We have received a new draft policy proposal - Require newly created AS-SETs to have hierarchical names, ID AFPUB-2026-ASN-001-DRAFT01 from author James Bensley. > > The proposal contents are published at: > https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft01 > > We encourage you to take some time to go through the proposal contents and provide feedback as follows: > > a) Do you support or oppose the proposal? > > b) If you oppose the proposal, state your reasons? > > c) Is there anything in the proposal that is not clear? > > d) What changes could be made to this proposal to make it more effective? > > Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From jaco at uls.co.za Thu May 21 13:26:33 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Thu, 21 May 2026 15:26:33 +0200 Subject: [rpd] Soft Landing, Recovered Space and Priority AFPUB-2026-IPv4-001-DRAFT01. In-Reply-To: References: <0EDA090C-E6CB-4A9E-BB96-CBFD336FFD53@gmail.com> Message-ID: Hi Jordi, Thanks for raising this. To be clear:? I'm mostly neutral on this.? To a degree I'm of the opinion that the remaining space should just go away so that IPv4 can now go the way of the dodo and those that have not yet deployed IPv6 can remain behind in an eventually disconnected world of their own.? That said ...? "no IPv4 space" makes you the "currently disconnected from reality" service provider - whilst in most cases is possible to overcome by providing services on IPv6-only and using a service like Cloudflare to bridge from IPv4 to IPv6 - but that's not always possible for all services.? From the latter perspective I'm in support of what you're saying, but I do thing we're just pro-longing our pain. I do thing we also need to urgently address if possible is a policy around how to handle space that's recovered that were leased to AFRINIC members (or entities that could legitimately become AFRINIC members) by the entity from where the space is recovered. I see two options: 1.? Lose it.? For some of those entities this could be a death stroke. 2.? If the space could be justified as per existing AFRINIC policies, the space (or the portion that can be justified) gets assigned to the AFRINIC member. This is aimed towards not penalising downstream customers (presumably innocent) of entities that engaged in policy violating behaviour (not speaking towards guilt/not - that's for others to determine, but it doesn't hurt to prepare for space recovery in the case that that happens). Kind regards, Jaco ?On 2026/05/21 14:45, jordi.palet--- via RPD wrote: > Hi all, > > I just want to make a short intro to this proposal, aiming to create, > hopefully, some discussion. > > This proposal aims to resolve in a single step, most of the conflicts > that have been raised by the staff and summarized here: > https://www.afrinic.net/policy/implementation-reports/pier-summary > > Those conflicts are because the soft landing policy takes over some of > the articles in other parts of the CPM. > > This proposal address that by basically stating that in case of > conflict, soft-landing articles will have higher priority and actually > removing 3 articles and rewording one more, to avoid confusion for > anyone reading the CPM. > > This is the actual way the staff is doing for any request for IPv4 > addresses, so basically, the proposal doesn?t imply changes in the > actual evaluation process, just ensuring that there are no > misinterpretations or confusions. > > Please, let me know if you feel that something is broken or can be > improved or whatever. > > Note that this proposal doesn?t prevent the community to improve the > soft-landing policy, for example regarding what do to with the IPv4 > addresses being recovered, but reaching consensus in changes to soft > landing, probably can take longer discussion cycles. > > Tks! > > Regards, > Jordi > > @jordipalet > > >> El 15 may 2026, a las 17:46, dacostadarwin at gmail.com escribi?: >> >> Dear PDWG, >> >> We have received a new draft policy proposal - Soft Landing, >> Recovered Space and Priority, ID AFPUB-2026-IPv4-001-DRAFT01 ?from >> author Jordi Palet Martinez. The proposal contents are published at: >> >> https://afrinic.net/policy/proposals/afpub-2026-ipv4-001-draft01 >> >> We encourage you to take some time to go through the proposal >> contents and provide feedback as follows: >> >> a) Do you support or oppose the proposal? >> b) If you oppose the proposal, state your reasons? >> c) Is there anything in the proposal that is not clear? >> d) What changes could be made to this proposal to make it more effective? >> >> >> Regards, >> Vincent Ngundi & Darwin Da Costa >> AFRINIC PDWG Co-Chairs. >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents of > this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If you > are not the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited, will be > considered a criminal offense, so you must reply to the original > sender to inform about this communication and delete it. > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu May 21 13:28:26 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Thu, 21 May 2026 15:28:26 +0200 Subject: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01. In-Reply-To: References: Message-ID: <29E79A7F-BF80-44DE-8B67-45521A95F2FB@consulintel.es> Hi all, This proposal, continuing with the idea of resolving the issues that have been discovered by the staff, is attempting to fix the problem of operators that need additional resources for redundancy, new sites (for example data centers), or even transition technologies. The actual soft landing proposal doesn?t cover those cases and only allows obtaining additional resources when 90% of utilizations is reached. Of course, I think is clear for all, that you don?t setup a data-center or other kinds of redundancy when your 1st data center is almost full, you actually want to have them being built even at the same time. Similarly when you, for example, want to deploy 464XLAT, and you have 4 PoPs where you will locate the NAT64 boxes, you will need some free IPv4 pools (for example 1x/24 and each POP), and you want to do that in all the PoPs, not one, wait for 90% utilization, then the next one, etc., because you want to make sure to provide high-availability. This is a very clear case for me, in my day-job deploying IPv6-only with IPv4-as-a-Service worldwide. This is easily achieved by waiving those requests from the 90% utilization and considering them as a ?first request? (in fact, it is a first request for a new site). The advantage for Afrinic, compared with other RIRs, is that we have recovered 3 millions of IPv4 addresses, so multiple sites allocations for every member, doesn?t mean draining earlier than expected the available pool when we entered in soft landing phases. Comments welcome! Tks! Regards, Jordi @jordipalet > El 15 may 2026, a las 17:51, dacostadarwin at gmail.com escribi?: > > Dear PDWG, > > We have received a new draft policy proposal - Amendment of Utilisation in Soft Landing, ID AFPUB-2026-IPv4-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: > > https://afrinic.net/policy/proposals/afpub-2026-ipv4-002-draft01 > > We encourage you to take some time to go through the proposal contents and provide feedback as follows : > > a) Do you support or oppose the proposal? > b) If you oppose the proposal, state your reasons? > c) Is there anything in the proposal that is not clear? > d) What changes could be made to this proposal to make it more effective? > > Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jaco at uls.co.za Thu May 21 14:03:12 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Thu, 21 May 2026 16:03:12 +0200 Subject: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01. In-Reply-To: <29E79A7F-BF80-44DE-8B67-45521A95F2FB@consulintel.es> References: <29E79A7F-BF80-44DE-8B67-45521A95F2FB@consulintel.es> Message-ID: Hi Jordi, In principle in support, this could potentially have helped me a few years back to avoid nasty renumbering. Having said that, I think this becomes a bit too lenient.? Must be "where it can be shown that the new requirement cannot practically be served by existing resources", so in your case where you have four POPs each needing to originate it's own /24, you will require extra resources to set up a fifth POP.? The counter argument would be "but you can use /25s internally and just advertise >=/24s to the outside world" - but this would result in sub-optimal routing which is where I stand with you. I just think the wording as is could potentially be abused and I'd like to see it a bit more strict in the sense that it must be shown that even with renumbering it cannot be accommodated from existing resources. I like that you mention examples, and some of them definitely tickled my curiosity as to why you'd need IPv4 to achieve that, but I don't think that matters, except that these could potentially be used to obtain additional resources prematurely and I'd like a requirement that it must be shown that the current allocations/assignments cannot be utilised to fulfil the technical requirements. Kind regards, Jac On 2026/05/21 15:28, jordi.palet--- via RPD wrote: > Hi all, > > This proposal, continuing with the idea of resolving the issues that have been discovered by the staff, is attempting to fix the problem of operators that need additional resources for redundancy, new sites (for example data centers), or even transition technologies. > > The actual soft landing proposal doesn?t cover those cases and only allows obtaining additional resources when 90% of utilizations is reached. > > Of course, I think is clear for all, that you don?t setup a data-center or other kinds of redundancy when your 1st data center is almost full, you actually want to have them being built even at the same time. > > Similarly when you, for example, want to deploy 464XLAT, and you have 4 PoPs where you will locate the NAT64 boxes, you will need some free IPv4 pools (for example 1x/24 and each POP), and you want to do that in all the PoPs, not one, wait for 90% utilization, then the next one, etc., because you want to make sure to provide high-availability. This is a very clear case for me, in my day-job deploying IPv6-only with IPv4-as-a-Service worldwide. > > This is easily achieved by waiving those requests from the 90% utilization and considering them as a ?first request? (in fact, it is a first request for a new site). > > The advantage for Afrinic, compared with other RIRs, is that we have recovered 3 millions of IPv4 addresses, so multiple sites allocations for every member, doesn?t mean draining earlier than expected the available pool when we entered in soft landing phases. > > Comments welcome! > > Tks! > > Regards, > Jordi > > @jordipalet > > >> El 15 may 2026, a las 17:51, dacostadarwin at gmail.com escribi?: >> >> Dear PDWG, >> >> We have received a new draft policy proposal - Amendment of Utilisation in Soft Landing, ID AFPUB-2026-IPv4-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >> >> https://afrinic.net/policy/proposals/afpub-2026-ipv4-002-draft01 >> >> We encourage you to take some time to go through the proposal contents and provide feedback as follows : >> >> a) Do you support or oppose the proposal? >> b) If you oppose the proposal, state your reasons? >> c) Is there anything in the proposal that is not clear? >> d) What changes could be made to this proposal to make it more effective? >> >> Regards, >> Vincent Ngundi & Darwin Da Costa >> AFRINIC PDWG Co-Chairs >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From jordi.palet at consulintel.es Thu May 21 14:19:51 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Thu, 21 May 2026 16:19:51 +0200 Subject: [rpd] Soft Landing, Recovered Space and Priority AFPUB-2026-IPv4-001-DRAFT01. In-Reply-To: References: <0EDA090C-E6CB-4A9E-BB96-CBFD336FFD53@gmail.com> Message-ID: <71E930BC-374C-4747-A490-21393E032A85@consulintel.es> Hi Jaco, Tks for the inputs. I understand your point, and ideally I will be also for ?stop completely? providing IPv4 addresses, but this is impossible while you can do transfers, even if they may happen under the table, so not a realistic position. In other regions, only newcomers can get new IPv4 addresses, but the difference is that in other regions, they don?t have anymore any space, so the situation with Afrinic is quite different. I think we should work in a better use of the recovered space, or learning from what happened in other regions with policies similar to ?soft landing?, have a much better policy, but as said, I don?t think this will reach consensus in a short time, so meanwhile, let?s clear contradictions in the CPM. Also note that in Africa, the penetration of Internet is still low, unless it changed a lot in the last few years, compared to other regions, so having the recovered space in the ?soft landing? space, seems more appropriate. Note also that the other proposal also allows to use some of this ?extra? IPv4 recovered space. I think overall, this way to approach what do to with the recovered space helps Africa to improve Internet penetration tied to IPv6 deployment. Regards, Jordi @jordipalet > El 21 may 2026, a las 15:26, Jaco Kroon escribi?: > > Hi Jordi, > > Thanks for raising this. > > To be clear: I'm mostly neutral on this. To a degree I'm of the opinion that the remaining space should just go away so that IPv4 can now go the way of the dodo and those that have not yet deployed IPv6 can remain behind in an eventually disconnected world of their own. That said ... "no IPv4 space" makes you the "currently disconnected from reality" service provider - whilst in most cases is possible to overcome by providing services on IPv6-only and using a service like Cloudflare to bridge from IPv4 to IPv6 - but that's not always possible for all services. From the latter perspective I'm in support of what you're saying, but I do thing we're just pro-longing our pain. > > I do thing we also need to urgently address if possible is a policy around how to handle space that's recovered that were leased to AFRINIC members (or entities that could legitimately become AFRINIC members) by the entity from where the space is recovered. > > I see two options: > > 1. Lose it. For some of those entities this could be a death stroke. > 2. If the space could be justified as per existing AFRINIC policies, the space (or the portion that can be justified) gets assigned to the AFRINIC member. > > This is aimed towards not penalising downstream customers (presumably innocent) of entities that engaged in policy violating behaviour (not speaking towards guilt/not - that's for others to determine, but it doesn't hurt to prepare for space recovery in the case that that happens). > > Kind regards, > Jaco > > On 2026/05/21 14:45, jordi.palet--- via RPD wrote: > >> Hi all, >> >> I just want to make a short intro to this proposal, aiming to create, hopefully, some discussion. >> >> This proposal aims to resolve in a single step, most of the conflicts that have been raised by the staff and summarized here: >> https://www.afrinic.net/policy/implementation-reports/pier-summary >> >> Those conflicts are because the soft landing policy takes over some of the articles in other parts of the CPM. >> >> This proposal address that by basically stating that in case of conflict, soft-landing articles will have higher priority and actually removing 3 articles and rewording one more, to avoid confusion for anyone reading the CPM. >> >> This is the actual way the staff is doing for any request for IPv4 addresses, so basically, the proposal doesn?t imply changes in the actual evaluation process, just ensuring that there are no misinterpretations or confusions. >> >> Please, let me know if you feel that something is broken or can be improved or whatever. >> >> Note that this proposal doesn?t prevent the community to improve the soft-landing policy, for example regarding what do to with the IPv4 addresses being recovered, but reaching consensus in changes to soft landing, probably can take longer discussion cycles. >> >> Tks! >> >> Regards, >> Jordi >> >> @jordipalet >> >> >>> El 15 may 2026, a las 17:46, dacostadarwin at gmail.com escribi?: >>> >>> Dear PDWG, >>> >>> We have received a new draft policy proposal - Soft Landing, Recovered Space and Priority, ID AFPUB-2026-IPv4-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>> >>> https://afrinic.net/policy/proposals/afpub-2026-ipv4-001-draft01 >>> >>> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>> >>> a) Do you support or oppose the proposal? >>> b) If you oppose the proposal, state your reasons? >>> c) Is there anything in the proposal that is not clear? >>> d) What changes could be made to this proposal to make it more effective? >>> >>> >>> Regards, >>> Vincent Ngundi & Darwin Da Costa >>> AFRINIC PDWG Co-Chairs. >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Thu May 21 14:32:54 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Thu, 21 May 2026 16:32:54 +0200 Subject: [rpd] Soft Landing, Recovered Space and Priority AFPUB-2026-IPv4-001-DRAFT01. In-Reply-To: <71E930BC-374C-4747-A490-21393E032A85@consulintel.es> References: <0EDA090C-E6CB-4A9E-BB96-CBFD336FFD53@gmail.com> <71E930BC-374C-4747-A490-21393E032A85@consulintel.es> Message-ID: <6e629c43-0c6e-42d2-bc56-e4e0c24523d8@uls.co.za> Hi Jordi, Fully agree with everything you say, related proposal. Your proposal as is, is good IMHO. I suspect it then goes to option (1) below, so if the community wants option (2) below someone will have to write the policy proposal for that.? Doesn't affect me and I'd love to have IPv4 for a bit longer for all the practical reasons you stated.? That said I do encourage as much IPv6 adoption as I can. Kind regards, Jaco On 2026/05/21 16:19, jordi.palet--- via RPD wrote: > Hi Jaco, > > Tks for the inputs. > > I understand your point, and ideally I will be also for ?stop > completely? providing IPv4 addresses, but this is impossible while you > can do transfers, even if they may happen under the table, so not a > realistic position. > > In other regions, only newcomers can get new IPv4 addresses, but the > difference is that in other regions, they don?t have anymore any > space, so the situation with Afrinic is quite different. > > I think we should work in a better use of the recovered space, or > learning from what happened in other regions with policies similar to > ?soft landing?, have a much better policy, but as said, I don?t think > this will reach consensus in a short time, so meanwhile, let?s clear > contradictions in the CPM. > > Also note that in Africa, the penetration of Internet is still low, > unless it changed a lot in the last few years, compared to other > regions, so having the recovered space in the ?soft landing? space, > seems more appropriate. Note also that the other proposal also allows > to use some of this ?extra? IPv4 recovered space. > > I think overall, this way to approach what do to with the recovered > space helps Africa to improve Internet penetration tied to IPv6 > deployment. > > Regards, > Jordi > > @jordipalet > > >> El 21 may 2026, a las 15:26, Jaco Kroon escribi?: >> >> Hi Jordi, >> >> Thanks for raising this. >> >> To be clear:? I'm mostly neutral on this.? To a degree I'm of the >> opinion that the remaining space should just go away so that IPv4 can >> now go the way of the dodo and those that have not yet deployed IPv6 >> can remain behind in an eventually disconnected world of their own.? >> That said ...? "no IPv4 space" makes you the "currently disconnected >> from reality" service provider - whilst in most cases is possible to >> overcome by providing services on IPv6-only and using a service like >> Cloudflare to bridge from IPv4 to IPv6 - but that's not always >> possible for all services. From the latter perspective I'm in support >> of what you're saying, but I do thing we're just pro-longing our pain. >> >> I do thing we also need to urgently address if possible is a policy >> around how to handle space that's recovered that were leased to >> AFRINIC members (or entities that could legitimately become AFRINIC >> members) by the entity from where the space is recovered. >> >> I see two options: >> >> 1.? Lose it.? For some of those entities this could be a death stroke. >> 2.? If the space could be justified as per existing AFRINIC policies, >> the space (or the portion that can be justified) gets assigned to the >> AFRINIC member. >> >> This is aimed towards not penalising downstream customers (presumably >> innocent) of entities that engaged in policy violating behaviour (not >> speaking towards guilt/not - that's for others to determine, but it >> doesn't hurt to prepare for space recovery in the case that that >> happens). >> >> Kind regards, >> Jaco >> >> ?On 2026/05/21 14:45, jordi.palet--- via RPD wrote: >> >>> Hi all, >>> >>> I just want to make a short intro to this proposal, aiming to >>> create, hopefully, some discussion. >>> >>> This proposal aims to resolve in a single step, most of the >>> conflicts that have been raised by the staff and summarized here: >>> https://www.afrinic.net/policy/implementation-reports/pier-summary >>> >>> Those conflicts are because the soft landing policy takes over some >>> of the articles in other parts of the CPM. >>> >>> This proposal address that by basically stating that in case of >>> conflict, soft-landing articles will have higher priority and >>> actually removing 3 articles and rewording one more, to avoid >>> confusion for anyone reading the CPM. >>> >>> This is the actual way the staff is doing for any request for IPv4 >>> addresses, so basically, the proposal doesn?t imply changes in the >>> actual evaluation process, just ensuring that there are no >>> misinterpretations or confusions. >>> >>> Please, let me know if you feel that something is broken or can be >>> improved or whatever. >>> >>> Note that this proposal doesn?t prevent the community to improve the >>> soft-landing policy, for example regarding what do to with the IPv4 >>> addresses being recovered, but reaching consensus in changes to soft >>> landing, probably can take longer discussion cycles. >>> >>> Tks! >>> >>> Regards, >>> Jordi >>> >>> @jordipalet >>> >>> >>>> El 15 may 2026, a las 17:46, dacostadarwin at gmail.com escribi?: >>>> >>>> Dear PDWG, >>>> >>>> We have received a new draft policy proposal - Soft Landing, >>>> Recovered Space and Priority, ID AFPUB-2026-IPv4-001-DRAFT01 ?from >>>> author Jordi Palet Martinez. The proposal contents are published at: >>>> >>>> https://afrinic.net/policy/proposals/afpub-2026-ipv4-001-draft01 >>>> >>>> We encourage you to take some time to go through the proposal >>>> contents and provide feedback as follows: >>>> >>>> a) Do you support or oppose the proposal? >>>> b) If you oppose the proposal, state your reasons? >>>> c) Is there anything in the proposal that is not clear? >>>> d) What changes could be made to this proposal to make it more >>>> effective? >>>> >>>> >>>> Regards, >>>> Vincent Ngundi & Darwin Da Costa >>>> AFRINIC PDWG Co-Chairs. >>>> >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> >>> ********************************************** >>> IPv4 is over >>> Are you ready for the new Internet ? >>> http://www.theipv6company.com >>> The IPv6 Company >>> >>> This electronic message contains information which may be privileged >>> or confidential. The information is intended to be for the exclusive >>> use of the individual(s) named above and further non-explicilty >>> authorized disclosure, copying, distribution or use of the contents >>> of this information, even if partially, including attached files, is >>> strictly prohibited and will be considered a criminal offense. If >>> you are not the intended recipient be aware that any disclosure, >>> copying, distribution or use of the contents of this information, >>> even if partially, including attached files, is strictly prohibited, >>> will be considered a criminal offense, so you must reply to the >>> original sender to inform about this communication and delete it. >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents of > this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If you > are not the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited, will be > considered a criminal offense, so you must reply to the original > sender to inform about this communication and delete it. > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu May 21 14:36:41 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Thu, 21 May 2026 16:36:41 +0200 Subject: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01. In-Reply-To: References: <29E79A7F-BF80-44DE-8B67-45521A95F2FB@consulintel.es> Message-ID: <44FDA4A2-B9AF-47C8-81AE-73CFB1982E5B@consulintel.es> Hi and tks again, I see your point that seems to easy, but we shall remember that you need to demonstrate the need to Afrinic *every time* you do a request. So if you say, I will build not 1 but 3 DCs, you will need to show contracts, right? Is the same as when you request a bigger address block than what policies dictate, you need to justify the need, have network diagrams, etc.. If you need to deploy 4 NAT64 PoPs, you need to show the contracts, even the invoices for the NAT64 boxes, etc. All that are operational details, with don?t go into policy text. We want to avoid micromanagement of the RIR as much as possible, only got into the details if they are going to (clearly) do it wrong (or done wrong already previously). If a request for 4 /24 for 4 NAT64 PoPs is fraudulent, the service agreement already enable Afrinic to review that and reclaim the space. I don?t think in general, people want to break rules on purpose. Also I think asking for demonstrating that it can?t be done with renumbering is too expensive (just the exercise to analyze is it often a big hurdle), renumbering is extremely hard, and imposing this may go against some IPv6 deployments ?the deployment cost me x and also I need to check if I can do it with renumbering first, then I just do with the renumbering, at least for some time?. ****** Now, if the staff believes that they need some explicit text to demonstrate the need, please say so before the policy proposal submission deadline, because in that case, we still have time to incorporate that text into a v2. May be something such as: ?The above requirement is waived for network operators requesting new IP addresses for demonstrated key technical needs ? such as redundancy and high-availability sites, IPv6 transition technologies, or expansion to new sites which pose a technical constraint on their current resource pool ? and in these cases, the request is treated as a first allocation or request." Repeating myself: I think overall, this way to approach what do to with the recovered space helps Africa to improve Internet penetration tied to IPv6 deployment, specially because dual-stack is not longer possible, so this helps IPv6 + IPv4aaS, so it is clearly in support of IPv6 deployment. Regards, Jordi @jordipalet > El 21 may 2026, a las 16:03, Jaco Kroon escribi?: > > Hi Jordi, > > In principle in support, this could potentially have helped me a few years back to avoid nasty renumbering. > > Having said that, I think this becomes a bit too lenient. Must be "where it can be shown that the new requirement cannot practically be served by existing resources", so in your case where you have four POPs each needing to originate it's own /24, you will require extra resources to set up a fifth POP. The counter argument would be "but you can use /25s internally and just advertise >=/24s to the outside world" - but this would result in sub-optimal routing which is where I stand with you. > > I just think the wording as is could potentially be abused and I'd like to see it a bit more strict in the sense that it must be shown that even with renumbering it cannot be accommodated from existing resources. > > I like that you mention examples, and some of them definitely tickled my curiosity as to why you'd need IPv4 to achieve that, but I don't think that matters, except that these could potentially be used to obtain additional resources prematurely and I'd like a requirement that it must be shown that the current allocations/assignments cannot be utilised to fulfil the technical requirements. > > Kind regards, > Jac > > > On 2026/05/21 15:28, jordi.palet--- via RPD wrote: >> Hi all, >> >> This proposal, continuing with the idea of resolving the issues that have been discovered by the staff, is attempting to fix the problem of operators that need additional resources for redundancy, new sites (for example data centers), or even transition technologies. >> >> The actual soft landing proposal doesn?t cover those cases and only allows obtaining additional resources when 90% of utilizations is reached. >> >> Of course, I think is clear for all, that you don?t setup a data-center or other kinds of redundancy when your 1st data center is almost full, you actually want to have them being built even at the same time. >> >> Similarly when you, for example, want to deploy 464XLAT, and you have 4 PoPs where you will locate the NAT64 boxes, you will need some free IPv4 pools (for example 1x/24 and each POP), and you want to do that in all the PoPs, not one, wait for 90% utilization, then the next one, etc., because you want to make sure to provide high-availability. This is a very clear case for me, in my day-job deploying IPv6-only with IPv4-as-a-Service worldwide. >> >> This is easily achieved by waiving those requests from the 90% utilization and considering them as a ?first request? (in fact, it is a first request for a new site). >> >> The advantage for Afrinic, compared with other RIRs, is that we have recovered 3 millions of IPv4 addresses, so multiple sites allocations for every member, doesn?t mean draining earlier than expected the available pool when we entered in soft landing phases. >> >> Comments welcome! >> >> Tks! >> >> Regards, >> Jordi >> >> @jordipalet >> >> >>> El 15 may 2026, a las 17:51, dacostadarwin at gmail.com escribi?: >>> >>> Dear PDWG, >>> >>> We have received a new draft policy proposal - Amendment of Utilisation in Soft Landing, ID AFPUB-2026-IPv4-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>> >>> https://afrinic.net/policy/proposals/afpub-2026-ipv4-002-draft01 >>> >>> We encourage you to take some time to go through the proposal contents and provide feedback as follows : >>> >>> a) Do you support or oppose the proposal? >>> b) If you oppose the proposal, state your reasons? >>> c) Is there anything in the proposal that is not clear? >>> d) What changes could be made to this proposal to make it more effective? >>> >>> Regards, >>> Vincent Ngundi & Darwin Da Costa >>> AFRINIC PDWG Co-Chairs >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Thu May 21 14:56:32 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Thu, 21 May 2026 16:56:32 +0200 Subject: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01. In-Reply-To: <44FDA4A2-B9AF-47C8-81AE-73CFB1982E5B@consulintel.es> References: <29E79A7F-BF80-44DE-8B67-45521A95F2FB@consulintel.es> <44FDA4A2-B9AF-47C8-81AE-73CFB1982E5B@consulintel.es> Message-ID: <611d8d2e-fcde-4ba2-ad02-a89169649622@uls.co.za> Hi, On 2026/05/21 16:36, jordi.palet--- via RPD wrote: > Hi and tks again, > > I see your point that seems to easy, but we shall remember that you > need to demonstrate the need to Afrinic *every time* you do a request. > So if you say, I will build not 1 but 3 DCs, you will need to show > contracts, right? > > Is the same as when you request a bigger address block than what > policies dictate, you need to justify the need, have network diagrams, > etc.. If you need to deploy 4 NAT64 PoPs, you need to show the > contracts, even the invoices for the NAT64 boxes, etc. Well, right now I don't think you can get more than /22 no matter how well you can illustrate that.? I would not mind being able to consolidate the resources that I have into a single block, however, there's one black that would be exceptionally hard to renumber (And I believe this is part of your point about renumbering). > > All that are operational details, with don?t go into policy text. We > want to avoid micromanagement of the RIR as much as possible, only got > into the details if they are going to (clearly) do it wrong (or done > wrong already previously). I agree.? But we also want policy to be clear so as to avoid misinterpretation - accidentally or otherwise. > > If a request for 4 /24 for 4 NAT64 PoPs is fraudulent, the service > agreement already enable Afrinic to review that and reclaim the space. > I don?t think in general, people want to break rules on purpose. Agree, I expect most people to be rule-abiding and well-intentioned individuals. > > Also I think asking for demonstrating that it can?t be done with > renumbering is too expensive (just the exercise to analyze is it often > a big hurdle), renumbering is extremely hard, and imposing this may go > against some IPv6 deployments ?the deployment cost me x and also I > need to check if I can do it with renumbering first, then I just do > with the renumbering, at least for some time?. Ok. > > ****** Now, if the staff believes that they need some explicit text to > demonstrate the need, please say so before the policy proposal > submission deadline, because in that case, we still have time to > incorporate that text into a v2. > > May be something such as: > > ?The above requirement is waived for network operators requesting new > IP addresses for demonstrated?key technical needs ? such as redundancy > and high-availability sites,?IPv6?transition technologies, or > expansion to new sites which pose a technical constraint on their > current resource pool ? and in these cases, the request is treated as > a first allocation or request." How about: ?The above requirement is waived for network operators requesting new IPv4addresses for demonstrated?key technical requirements, which can be illustrated to not be practically serviceable from existing assigned/allocated IPv4 resources?? such as redundancy and high-availability sites,?IPv6?transition technologies, or expansion to new sites which pose a technical constraint on their current resource pool ? and in these cases, the request is treated as a first allocation or request." As you say, there could be practical limitations that could potentially be alleviated by renumbering but where it isn't practical to do so, so I believe this hits more the middle ground, I hope. > > Repeating myself: > I think overall, this way to approach what do to with the recovered > space helps Africa to improve Internet penetration tied to IPv6 > deployment, specially because dual-stack is not longer possible, so > this helps IPv6 + IPv4aaS, so it is clearly in support of IPv6 deployment. I agree.? I just feel extremely sorry for those entities that were forced to approach leasing entities in order to obtain some IPv4 space that may now have that space revoked again ... refer to the other discussion. Appreciate the discussion, use it don't use it, I think this is fine as is, my preference has been made known. Kind regards, Jaco -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu May 21 15:01:50 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Thu, 21 May 2026 17:01:50 +0200 Subject: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01. In-Reply-To: <611d8d2e-fcde-4ba2-ad02-a89169649622@uls.co.za> References: <29E79A7F-BF80-44DE-8B67-45521A95F2FB@consulintel.es> <44FDA4A2-B9AF-47C8-81AE-73CFB1982E5B@consulintel.es> <611d8d2e-fcde-4ba2-ad02-a89169649622@uls.co.za> Message-ID: I will be happy myself with the text changes that you proposed. Let?s make sure other folks agree/disagree and specially it will be awesome to get a confirmation from the staff that this doesn?t create excessive burden to them for the evaluation of the request, and we don?t miss the deadline for a v2. Tks! Regards, Jordi @jordipalet > El 21 may 2026, a las 16:56, Jaco Kroon escribi?: > > Hi, > > On 2026/05/21 16:36, jordi.palet--- via RPD wrote: >> Hi and tks again, >> >> I see your point that seems to easy, but we shall remember that you need to demonstrate the need to Afrinic *every time* you do a request. So if you say, I will build not 1 but 3 DCs, you will need to show contracts, right? >> >> Is the same as when you request a bigger address block than what policies dictate, you need to justify the need, have network diagrams, etc.. If you need to deploy 4 NAT64 PoPs, you need to show the contracts, even the invoices for the NAT64 boxes, etc. > Well, right now I don't think you can get more than /22 no matter how well you can illustrate that. I would not mind being able to consolidate the resources that I have into a single block, however, there's one black that would be exceptionally hard to renumber (And I believe this is part of your point about renumbering). >> >> >> All that are operational details, with don?t go into policy text. We want to avoid micromanagement of the RIR as much as possible, only got into the details if they are going to (clearly) do it wrong (or done wrong already previously). > I agree. But we also want policy to be clear so as to avoid misinterpretation - accidentally or otherwise. >> >> >> If a request for 4 /24 for 4 NAT64 PoPs is fraudulent, the service agreement already enable Afrinic to review that and reclaim the space. I don?t think in general, people want to break rules on purpose. > Agree, I expect most people to be rule-abiding and well-intentioned individuals. >> >> >> Also I think asking for demonstrating that it can?t be done with renumbering is too expensive (just the exercise to analyze is it often a big hurdle), renumbering is extremely hard, and imposing this may go against some IPv6 deployments ?the deployment cost me x and also I need to check if I can do it with renumbering first, then I just do with the renumbering, at least for some time?. > Ok. >> >> >> ****** Now, if the staff believes that they need some explicit text to demonstrate the need, please say so before the policy proposal submission deadline, because in that case, we still have time to incorporate that text into a v2. >> >> May be something such as: >> >> ?The above requirement is waived for network operators requesting new IP addresses for demonstrated key technical needs ? such as redundancy and high-availability sites, IPv6 transition technologies, or expansion to new sites which pose a technical constraint on their current resource pool ? and in these cases, the request is treated as a first allocation or request." > How about: > > ?The above requirement is waived for network operators requesting new IPv4 addresses for demonstrated key technical requirements, which can be illustrated to not be practically serviceable from existing assigned/allocated IPv4 resources ? such as redundancy and high-availability sites, IPv6 transition technologies, or expansion to new sites which pose a technical constraint on their current resource pool ? and in these cases, the request is treated as a first allocation or request." > > As you say, there could be practical limitations that could potentially be alleviated by renumbering but where it isn't practical to do so, so I believe this hits more the middle ground, I hope. > >> >> Repeating myself: >> I think overall, this way to approach what do to with the recovered space helps Africa to improve Internet penetration tied to IPv6 deployment, specially because dual-stack is not longer possible, so this helps IPv6 + IPv4aaS, so it is clearly in support of IPv6 deployment. > I agree. I just feel extremely sorry for those entities that were forced to approach leasing entities in order to obtain some IPv4 space that may now have that space revoked again ... refer to the other discussion. > > Appreciate the discussion, use it don't use it, I think this is fine as is, my preference has been made known. > > Kind regards, > Jaco > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From honlue at gmail.com Thu May 21 16:30:27 2026 From: honlue at gmail.com (Musa Stephen Honlue) Date: Thu, 21 May 2026 16:30:27 +0000 Subject: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. In-Reply-To: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> References: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> Message-ID: Dear author and rpd members, I support this proposal as it addresses a real operational and security concern caused by ambiguous AS-SET naming across IRR databases. Moving toward hierarchical naming strengthens uniqueness, authorisation, and overall trust in routing data. At the same time, it may be useful to consider transition and interoperability aspects, particularly for operators currently relying on widely recognised non-hierarchical AS-SET names and in the context of alignment with other RIRs. Overall, I believe this is a positive step toward improving the integrity and resilience of the routing ecosystem. Kind regards, Sent from my iPhone > On 20 May 2026, at 17:38, dacostadarwin at gmail.com wrote: > > ?Dear PDWG, > > We have received a new draft policy proposal - Require newly created AS-SETs to have hierarchical names, ID AFPUB-2026-ASN-001-DRAFT01 from author James Bensley. > > The proposal contents are published at: > https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft01 > > We encourage you to take some time to go through the proposal contents and provide feedback as follows: > > a) Do you support or oppose the proposal? > > b) If you oppose the proposal, state your reasons? > > c) Is there anything in the proposal that is not clear? > > d) What changes could be made to this proposal to make it more effective? > > Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From sami.salih at outlook.com Thu May 21 16:51:34 2026 From: sami.salih at outlook.com (Sami Salih) Date: Thu, 21 May 2026 16:51:34 +0000 Subject: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01. In-Reply-To: References: <29E79A7F-BF80-44DE-8B67-45521A95F2FB@consulintel.es> <44FDA4A2-B9AF-47C8-81AE-73CFB1982E5B@consulintel.es> <611d8d2e-fcde-4ba2-ad02-a89169649622@uls.co.za> Message-ID: Dear Jordi, Co-Chairs, and fellow PDWG members, Thank you for this proposal ? the technical rationale is sound and I support the intent. That said, I have one focused concern: the waiver mechanism as drafted is broad enough to be systematically abused, as the qualifying categories are self-declared with no verification requirement in the policy text. To address this, I suggest four improvements: 1. Require documented justification ? applicants should submit supporting technical documentation to AFRINIC staff before the waiver is activated 2. Cap waiver-based allocations ? limit to one per member per 12-month period to prevent repeated invocations across rolling "new sites" 3. Post-allocation follow-up ? require utilisation reporting within 12 months, with reclamation if the stated deployment has not materialised 4. Condition on IPv6 co-deployment ? require the requesting member to hold an active IPv6 allocation, ensuring the waiver supports transition rather than extending IPv4-only operations I support this proposal with the above amendments and am happy to assist in drafting the updated text if required. With Regards. Sami Salih. ________________________________ From: jordi.palet--- via RPD Sent: Thursday, May 21, 2026 6:01 PM To: rpd at afrinic.net Subject: Re: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01. I will be happy myself with the text changes that you proposed. Let?s make sure other folks agree/disagree and specially it will be awesome to get a confirmation from the staff that this doesn?t create excessive burden to them for the evaluation of the request, and we don?t miss the deadline for a v2. Tks! Regards, Jordi @jordipalet El 21 may 2026, a las 16:56, Jaco Kroon escribi?: Hi, On 2026/05/21 16:36, jordi.palet--- via RPD wrote: Hi and tks again, I see your point that seems to easy, but we shall remember that you need to demonstrate the need to Afrinic *every time* you do a request. So if you say, I will build not 1 but 3 DCs, you will need to show contracts, right? Is the same as when you request a bigger address block than what policies dictate, you need to justify the need, have network diagrams, etc.. If you need to deploy 4 NAT64 PoPs, you need to show the contracts, even the invoices for the NAT64 boxes, etc. Well, right now I don't think you can get more than /22 no matter how well you can illustrate that. I would not mind being able to consolidate the resources that I have into a single block, however, there's one black that would be exceptionally hard to renumber (And I believe this is part of your point about renumbering). All that are operational details, with don?t go into policy text. We want to avoid micromanagement of the RIR as much as possible, only got into the details if they are going to (clearly) do it wrong (or done wrong already previously). I agree. But we also want policy to be clear so as to avoid misinterpretation - accidentally or otherwise. If a request for 4 /24 for 4 NAT64 PoPs is fraudulent, the service agreement already enable Afrinic to review that and reclaim the space. I don?t think in general, people want to break rules on purpose. Agree, I expect most people to be rule-abiding and well-intentioned individuals. Also I think asking for demonstrating that it can?t be done with renumbering is too expensive (just the exercise to analyze is it often a big hurdle), renumbering is extremely hard, and imposing this may go against some IPv6 deployments ?the deployment cost me x and also I need to check if I can do it with renumbering first, then I just do with the renumbering, at least for some time?. Ok. ****** Now, if the staff believes that they need some explicit text to demonstrate the need, please say so before the policy proposal submission deadline, because in that case, we still have time to incorporate that text into a v2. May be something such as: ?The above requirement is waived for network operators requesting new IP addresses for demonstrated key technical needs ? such as redundancy and high-availability sites, IPv6 transition technologies, or expansion to new sites which pose a technical constraint on their current resource pool ? and in these cases, the request is treated as a first allocation or request." How about: ?The above requirement is waived for network operators requesting new IPv4 addresses for demonstrated key technical requirements, which can be illustrated to not be practically serviceable from existing assigned/allocated IPv4 resources ? such as redundancy and high-availability sites, IPv6 transition technologies, or expansion to new sites which pose a technical constraint on their current resource pool ? and in these cases, the request is treated as a first allocation or request." As you say, there could be practical limitations that could potentially be alleviated by renumbering but where it isn't practical to do so, so I believe this hits more the middle ground, I hope. Repeating myself: I think overall, this way to approach what do to with the recovered space helps Africa to improve Internet penetration tied to IPv6 deployment, specially because dual-stack is not longer possible, so this helps IPv6 + IPv4aaS, so it is clearly in support of IPv6 deployment. I agree. I just feel extremely sorry for those entities that were forced to approach leasing entities in order to obtain some IPv4 space that may now have that space revoked again ... refer to the other discussion. Appreciate the discussion, use it don't use it, I think this is fine as is, my preference has been made known. Kind regards, Jaco ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu May 21 17:03:53 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Thu, 21 May 2026 19:03:53 +0200 Subject: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01. In-Reply-To: References: <29E79A7F-BF80-44DE-8B67-45521A95F2FB@consulintel.es> <44FDA4A2-B9AF-47C8-81AE-73CFB1982E5B@consulintel.es> <611d8d2e-fcde-4ba2-ad02-a89169649622@uls.co.za> Message-ID: Hi Sami, I?m not sure if you are understanding that I?m for the improvements suggested by Jaco, so it will be: ?The above requirement is waived for network operators requesting new IPv4 addresses for demonstrated key technical requirements, which can be illustrated to not be practically serviceable from existing assigned/allocated IPv4 resources ? such as redundancy and high-availability sites, IPv6 transition technologies, or expansion to new sites which pose a technical constraint on their current resource pool ? and in these cases, the request is treated as a first allocation or request." With that we are already addressing your point 1. The reporting of usage of any resource, can be requested by Afrinic at any time, so that covers 3. 2 will ruin the goal of the proposal. You?re limiting then the number of sites, DCs, or PoPs with transition that an operator needs to deploy. 4, in other RIR discussion I always tried to incorporate this kind of requirements. However, most of the time, the proposal didn?t advanced with that requirement because the community didn?t supported it. If there are sufficient voices in favor and none agains, I will be happy to add that as well, of course. But we need to hear opinions! many ! Now one additional question on 4, what is the meaning to hold and IPv6 allocation/assignment. Should state also that is actually used? How this is verified? As you can see is not that easy. Note also that some folks may need some time to actually do the IPv6 deployment. I?m able to do that for any client in 3-6 months, because I?ve the expertise, but this is not the case for everyone, so not allowing it for IPv4-only usages, basically means those folks will be much slower to deploy IPv6 and have less interest. We need to make it as easy as possible. We need to remember: lack of policy compliance means resources can be recovered, so using the text amended by Jaco, I think covers it very well. Regards, Jordi @jordipalet > El 21 may 2026, a las 18:51, Sami Salih escribi?: > > Dear Jordi, Co-Chairs, and fellow PDWG members, > Thank you for this proposal ? the technical rationale is sound and I support the intent. > That said, I have one focused concern: the waiver mechanism as drafted is broad enough to be systematically abused, as the qualifying categories are self-declared with no verification requirement in the policy text. > To address this, I suggest four improvements: > Require documented justification ? applicants should submit supporting technical documentation to AFRINIC staff before the waiver is activated > Cap waiver-based allocations ? limit to one per member per 12-month period to prevent repeated invocations across rolling "new sites" > Post-allocation follow-up ? require utilisation reporting within 12 months, with reclamation if the stated deployment has not materialised > Condition on IPv6 co-deployment ? require the requesting member to hold an active IPv6 allocation, ensuring the waiver supports transition rather than extending IPv4-only operations > I support this proposal with the above amendments and am happy to assist in drafting the updated text if required. > > With Regards. > Sami Salih. > From: jordi.palet--- via RPD > > Sent: Thursday, May 21, 2026 6:01 PM > To: rpd at afrinic.net > > Subject: Re: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01. > > I will be happy myself with the text changes that you proposed. > > Let?s make sure other folks agree/disagree and specially it will be awesome to get a confirmation from the staff that this doesn?t create excessive burden to them for the evaluation of the request, and we don?t miss the deadline for a v2. > > Tks! > > Regards, > Jordi > > @jordipalet > > > El 21 may 2026, a las 16:56, Jaco Kroon > escribi?: > > Hi, > > On 2026/05/21 16:36, jordi.palet--- via RPD wrote: > Hi and tks again, > > I see your point that seems to easy, but we shall remember that you need to demonstrate the need to Afrinic *every time* you do a request. So if you say, I will build not 1 but 3 DCs, you will need to show contracts, right? > > Is the same as when you request a bigger address block than what policies dictate, you need to justify the need, have network diagrams, etc.. If you need to deploy 4 NAT64 PoPs, you need to show the contracts, even the invoices for the NAT64 boxes, etc. > Well, right now I don't think you can get more than /22 no matter how well you can illustrate that. I would not mind being able to consolidate the resources that I have into a single block, however, there's one black that would be exceptionally hard to renumber (And I believe this is part of your point about renumbering). > > All that are operational details, with don?t go into policy text. We want to avoid micromanagement of the RIR as much as possible, only got into the details if they are going to (clearly) do it wrong (or done wrong already previously). > I agree. But we also want policy to be clear so as to avoid misinterpretation - accidentally or otherwise. > > If a request for 4 /24 for 4 NAT64 PoPs is fraudulent, the service agreement already enable Afrinic to review that and reclaim the space. I don?t think in general, people want to break rules on purpose. > Agree, I expect most people to be rule-abiding and well-intentioned individuals. > > Also I think asking for demonstrating that it can?t be done with renumbering is too expensive (just the exercise to analyze is it often a big hurdle), renumbering is extremely hard, and imposing this may go against some IPv6 deployments ?the deployment cost me x and also I need to check if I can do it with renumbering first, then I just do with the renumbering, at least for some time?. > Ok. > > ****** Now, if the staff believes that they need some explicit text to demonstrate the need, please say so before the policy proposal submission deadline, because in that case, we still have time to incorporate that text into a v2. > > May be something such as: > > ?The above requirement is waived for network operators requesting new IP addresses for demonstrated key technical needs ? such as redundancy and high-availability sites, IPv6 transition technologies, or expansion to new sites which pose a technical constraint on their current resource pool ? and in these cases, the request is treated as a first allocation or request." > How about: > > ?The above requirement is waived for network operators requesting new IPv4 addresses for demonstrated key technical requirements, which can be illustrated to not be practically serviceable from existing assigned/allocated IPv4 resources ? such as redundancy and high-availability sites, IPv6 transition technologies, or expansion to new sites which pose a technical constraint on their current resource pool ? and in these cases, the request is treated as a first allocation or request." > > As you say, there could be practical limitations that could potentially be alleviated by renumbering but where it isn't practical to do so, so I believe this hits more the middle ground, I hope. > > > Repeating myself: > I think overall, this way to approach what do to with the recovered space helps Africa to improve Internet penetration tied to IPv6 deployment, specially because dual-stack is not longer possible, so this helps IPv6 + IPv4aaS, so it is clearly in support of IPv6 deployment. > I agree. I just feel extremely sorry for those entities that were forced to approach leasing entities in order to obtain some IPv4 space that may now have that space revoked again ... refer to the other discussion. > > Appreciate the discussion, use it don't use it, I think this is fine as is, my preference has been made known. > > Kind regards, > Jaco > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From honlue at gmail.com Thu May 21 18:00:55 2026 From: honlue at gmail.com (Musa Stephen Honlue) Date: Thu, 21 May 2026 18:00:55 +0000 Subject: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01. In-Reply-To: <29E79A7F-BF80-44DE-8B67-45521A95F2FB@consulintel.es> References: <29E79A7F-BF80-44DE-8B67-45521A95F2FB@consulintel.es> Message-ID: <6AAF451A-0A96-4933-A09C-4136A0396DA8@gmail.com> Dear Jordi, On a lighter note, I sometimes feel that IPv4 has reached a stage where every remaining allocation feels like a very carefully managed shared resource ? which only reinforces the importance of clear and consistent exhaustion-phase policy. Thank you for the proposal to revise Section 5.4.6.1. The intent is positive, particularly in introducing flexibility for legitimate operational needs such as redundancy, high availability, IPv6 transition mechanisms, and expansion to new sites. However, I would like to highlight a few concerns and suggest refinements to improve clarity, consistency, and implementation robustness. 1. 90% utilisation requirement Firstly, while the 90% utilisation requirement provides a clear conservation baseline, it remains too rigid if not complemented by a more explicit consideration of architectural efficiency and operational context. A more balanced approach could retain the threshold while allowing justified exceptions based on clearly defined criteria. For example: ?In order to receive IPv4 allocations or assignments during the Exhaustion Phase, the LIR or End User must have used at least 90% of all previous allocations or assignments (including those made during both the Current Phase and the Exhaustion Phase). The above requirement may be waived where the request is justified by clearly demonstrated operational requirements that cannot be reasonably met within existing address space.? 2. Scope of waiver clause Secondly, the waiver clause for ?key technical needs? is currently broad and open to interpretation. Terms such as ?technical constraints? and ?new sites? would benefit from clearer definitions or bounded conditions to ensure consistent application and to avoid unintended ambiguity while postmasters evaluate resources requests, or misuse. It may be preferable to require documented justification demonstrating that the need cannot be satisfied within existing allocations. 3. ?First allocation? equivalence Thirdly, the provision stating that such cases are ?treated as a first allocation? may be too strong, as it risks bypassing the exhaustion-phase intent of the policy. A more appropriate framing would be that such requests are evaluated under criteria equivalent to a first allocation, while still preserving exhaustion-phase conservation principles. 4. Broader PIER-related consistency items Finally, I note that the proposal addresses an important part of the PIER findings, but there remain additional structural inconsistencies raised by staff that may require separate attention, including: planning horizon inconsistencies (8-month vs 12-month references), minimum allocation inconsistency (/22 vs /24), treatment and policy framework for recovered IPv4 address space (approximately 3 million addresses). Addressing these alongside the current proposal may further improve overall policy coherence. Overall, I support the direction of the proposal and encourage strengthening the language around definitions, evaluation criteria, and safeguards to ensure consistency, predictability, and policy integrity. -- Best Regards -- Musa Stephen HONLUE Agile Coach | Project Manager | Digital Transformation Champion. Systems/Network Engineer. = t: +230 57444041 / +237 6 9310 6174 | tt: @mhonlue | linkedIn: https://www.linkedin.com/in/honluemusa/ w: www.skillsblocks.com| facebook.com/mhonlue ___________________________ > On 21 May 2026, at 13:28, jordi.palet--- via RPD wrote: > > Hi all, > > This proposal, continuing with the idea of resolving the issues that have been discovered by the staff, is attempting to fix the problem of operators that need additional resources for redundancy, new sites (for example data centers), or even transition technologies. > > The actual soft landing proposal doesn?t cover those cases and only allows obtaining additional resources when 90% of utilizations is reached. > > Of course, I think is clear for all, that you don?t setup a data-center or other kinds of redundancy when your 1st data center is almost full, you actually want to have them being built even at the same time. > > Similarly when you, for example, want to deploy 464XLAT, and you have 4 PoPs where you will locate the NAT64 boxes, you will need some free IPv4 pools (for example 1x/24 and each POP), and you want to do that in all the PoPs, not one, wait for 90% utilization, then the next one, etc., because you want to make sure to provide high-availability. This is a very clear case for me, in my day-job deploying IPv6-only with IPv4-as-a-Service worldwide. > > This is easily achieved by waiving those requests from the 90% utilization and considering them as a ?first request? (in fact, it is a first request for a new site). > > The advantage for Afrinic, compared with other RIRs, is that we have recovered 3 millions of IPv4 addresses, so multiple sites allocations for every member, doesn?t mean draining earlier than expected the available pool when we entered in soft landing phases. > > Comments welcome! > > Tks! > > Regards, > Jordi > > @jordipalet > > >> El 15 may 2026, a las 17:51, dacostadarwin at gmail.com escribi?: >> >> Dear PDWG, >> >> We have received a new draft policy proposal - Amendment of Utilisation in Soft Landing, ID AFPUB-2026-IPv4-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >> >> https://afrinic.net/policy/proposals/afpub-2026-ipv4-002-draft01 >> >> We encourage you to take some time to go through the proposal contents and provide feedback as follows : >> >> a) Do you support or oppose the proposal? >> b) If you oppose the proposal, state your reasons? >> c) Is there anything in the proposal that is not clear? >> d) What changes could be made to this proposal to make it more effective? >> >> Regards, >> Vincent Ngundi & Darwin Da Costa >> AFRINIC PDWG Co-Chairs >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From sami.salih at outlook.com Thu May 21 18:19:07 2026 From: sami.salih at outlook.com (Sami Salih) Date: Thu, 21 May 2026 18:19:07 +0000 Subject: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01. In-Reply-To: <6AAF451A-0A96-4933-A09C-4136A0396DA8@gmail.com> References: <29E79A7F-BF80-44DE-8B67-45521A95F2FB@consulintel.es> <6AAF451A-0A96-4933-A09C-4136A0396DA8@gmail.com> Message-ID: As I said, Jordi, I support the proposal. However, to address concerns about potential abuse, we need to define some safeguards. The points I shared are not intended to be fully adopted as they are; they are simply the initial measures that came to my mind. Others may further refine, amend, or add additional safeguards as needed. I recommend including as many of these measures as possible in the proposal itself. Then, during staff review and further community discussion, they can be consolidated into a final set of safeguards to prevent abuse. I hope this clarifies how I see the way forward. With Regards. Sami Salih. Sami Salih ________________________________ From: Musa Stephen Honlue Sent: Thursday, May 21, 2026 9:00:55 PM To: jordi.palet at consulintel.es ; rpd at afrinic.net Subject: Re: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01. Dear Jordi, On a lighter note, I sometimes feel that IPv4 has reached a stage where every remaining allocation feels like a very carefully managed shared resource ? which only reinforces the importance of clear and consistent exhaustion-phase policy. Thank you for the proposal to revise Section 5.4.6.1. The intent is positive, particularly in introducing flexibility for legitimate operational needs such as redundancy, high availability, IPv6 transition mechanisms, and expansion to new sites. However, I would like to highlight a few concerns and suggest refinements to improve clarity, consistency, and implementation robustness. 1. 90% utilisation requirement Firstly, while the 90% utilisation requirement provides a clear conservation baseline, it remains too rigid if not complemented by a more explicit consideration of architectural efficiency and operational context. A more balanced approach could retain the threshold while allowing justified exceptions based on clearly defined criteria. For example: ?In order to receive IPv4 allocations or assignments during the Exhaustion Phase, the LIR or End User must have used at least 90% of all previous allocations or assignments (including those made during both the Current Phase and the Exhaustion Phase). The above requirement may be waived where the request is justified by clearly demonstrated operational requirements that cannot be reasonably met within existing address space.? 2. Scope of waiver clause Secondly, the waiver clause for ?key technical needs? is currently broad and open to interpretation. Terms such as ?technical constraints? and ?new sites? would benefit from clearer definitions or bounded conditions to ensure consistent application and to avoid unintended ambiguity while postmasters evaluate resources requests, or misuse. It may be preferable to require documented justification demonstrating that the need cannot be satisfied within existing allocations. 3. ?First allocation? equivalence Thirdly, the provision stating that such cases are ?treated as a first allocation? may be too strong, as it risks bypassing the exhaustion-phase intent of the policy. A more appropriate framing would be that such requests are evaluated under criteria equivalent to a first allocation, while still preserving exhaustion-phase conservation principles. 4. Broader PIER-related consistency items Finally, I note that the proposal addresses an important part of the PIER findings, but there remain additional structural inconsistencies raised by staff that may require separate attention, including: * planning horizon inconsistencies (8-month vs 12-month references), * minimum allocation inconsistency (/22 vs /24), * treatment and policy framework for recovered IPv4 address space (approximately 3 million addresses). Addressing these alongside the current proposal may further improve overall policy coherence. Overall, I support the direction of the proposal and encourage strengthening the language around definitions, evaluation criteria, and safeguards to ensure consistency, predictability, and policy integrity. -- Best Regards -- Musa Stephen HONLUE Agile Coach | Project Manager | Digital Transformation Champion. Systems/Network Engineer. = t: +230 57444041 / +237 6 9310 6174 | tt: @mhonlue | linkedIn: https://www.linkedin.com/in/honluemusa/ w: www.skillsblocks.com| facebook.com/mhonlue ___________________________ On 21 May 2026, at 13:28, jordi.palet--- via RPD wrote: Hi all, This proposal, continuing with the idea of resolving the issues that have been discovered by the staff, is attempting to fix the problem of operators that need additional resources for redundancy, new sites (for example data centers), or even transition technologies. The actual soft landing proposal doesn?t cover those cases and only allows obtaining additional resources when 90% of utilizations is reached. Of course, I think is clear for all, that you don?t setup a data-center or other kinds of redundancy when your 1st data center is almost full, you actually want to have them being built even at the same time. Similarly when you, for example, want to deploy 464XLAT, and you have 4 PoPs where you will locate the NAT64 boxes, you will need some free IPv4 pools (for example 1x/24 and each POP), and you want to do that in all the PoPs, not one, wait for 90% utilization, then the next one, etc., because you want to make sure to provide high-availability. This is a very clear case for me, in my day-job deploying IPv6-only with IPv4-as-a-Service worldwide. This is easily achieved by waiving those requests from the 90% utilization and considering them as a ?first request? (in fact, it is a first request for a new site). The advantage for Afrinic, compared with other RIRs, is that we have recovered 3 millions of IPv4 addresses, so multiple sites allocations for every member, doesn?t mean draining earlier than expected the available pool when we entered in soft landing phases. Comments welcome! Tks! Regards, Jordi @jordipalet El 15 may 2026, a las 17:51, dacostadarwin at gmail.com escribi?: Dear PDWG, We have received a new draft policy proposal - Amendment of Utilisation in Soft Landing, ID AFPUB-2026-IPv4-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: https://afrinic.net/policy/proposals/afpub-2026-ipv4-002-draft01 We encourage you to take some time to go through the proposal contents and provide feedback as follows : a) Do you support or oppose the proposal? b) If you oppose the proposal, state your reasons? c) Is there anything in the proposal that is not clear? d) What changes could be made to this proposal to make it more effective? Regards, Vincent Ngundi & Darwin Da Costa AFRINIC PDWG Co-Chairs _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregoire.ehoumi at yahoo.fr Thu May 21 23:22:34 2026 From: gregoire.ehoumi at yahoo.fr (Gregoire EHOUMI) Date: Thu, 21 May 2026 19:22:34 -0400 Subject: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer In-Reply-To: <5BC824B3-E8E4-4509-B889-F3EC22391861@delong.com> References: <5BC824B3-E8E4-4509-B889-F3EC22391861@delong.com> Message-ID: Hi Owen The last point of section 3.6 defines conditions for recipient in another region: "If the recipient is in another region, the conditions on the recipient are defined in the counterpart's RIR transfer policy? Is this so difficult to find? Insulting AFRINIC board, community and such arrogance shall not be tolerated anymore in revived PDP. Regards, Gregoire > On May 21, 2026, at 7:30?AM, Owen DeLong via RPD wrote: > > Ratification of this policy only serves to prove that the board remains capable of absurdity. > > As written, the policy requires an out-of-region recipient allowed by the policy to comply with AFRINC policies, sign an AfriNIX RSA, etc. (section 3.6). > > Ridiculous. > > Owen > > >> On Feb 8, 2026, at 22:45, Madhvi Gokool via RPD wrote: >> >> Dear PDWG Members, >> >> We refer to the PDWG Chairs report on the draft policy proposal AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer dated 14 January 2022 and sent to the AFRINIC Board of Directors for ratification. The Board has also taken note of the report of the Policy Liaison dated 24 October 2025. >> We wish to inform you that the AFRINIC Board, at its meeting held on 4 February 2026, considered the PDWG Chairs' recommendation and resolved,with the consent of the Receiver, that the above policy proposal be ratified. >> >> The AFRINIC Secretariat will revert back on the implementation. >> >> Kind Regards, >> Madhvi Gokool & Brice Abba >> Policy Liaisons >> >> >> References :- >> Policy Proposal - https://afrinic.net/policy/proposals/2020-gen-006-d3 >> PDWG Chairs Report - https://lists.afrinic.net/pipermail/rpd/2022/014142.html >> >> Kind Regards, >> Madhvi Gokool & Brice Abba >> -- >> AFRINIC Policy Liaison. >> t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net >> facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From sami.salih at outlook.com Fri May 22 01:46:35 2026 From: sami.salih at outlook.com (Sami Salih) Date: Fri, 22 May 2026 01:46:35 +0000 Subject: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer In-Reply-To: References: <5BC824B3-E8E4-4509-B889-F3EC22391861@delong.com> Message-ID: Dear Co-Chairs, Point of order. I believe the tone and conduct reflected in the recent message require immediate intervention to maintain a civil and professional discussion environment on the mailing list. Technical disagreements are expected and welcome; however, discussions should remain respectful and constructive. With Regards, Sami Salih. ________________________________ From: Gregoire EHOUMI via RPD Sent: Friday, May 22, 2026 2:22:34 AM To: Owen DeLong Cc: rpd Subject: Re: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer Hi Owen The last point of section 3.6 defines conditions for recipient in another region: "If the recipient is in another region, the conditions on the recipient are defined in the counterpart's RIR transfer policy? Is this so difficult to find? Insulting AFRINIC board, community and such arrogance shall not be tolerated anymore in revived PDP. Regards, Gregoire On May 21, 2026, at 7:30?AM, Owen DeLong via RPD wrote: Ratification of this policy only serves to prove that the board remains capable of absurdity. As written, the policy requires an out-of-region recipient allowed by the policy to comply with AFRINC policies, sign an AfriNIX RSA, etc. (section 3.6). Ridiculous. Owen On Feb 8, 2026, at 22:45, Madhvi Gokool via RPD wrote: Dear PDWG Members, We refer to the PDWG Chairs report on the draft policy proposal AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer dated 14 January 2022 and sent to the AFRINIC Board of Directors for ratification. The Board has also taken note of the report of the Policy Liaison dated 24 October 2025. We wish to inform you that the AFRINIC Board, at its meeting held on 4 February 2026, considered the PDWG Chairs' recommendation and resolved,with the consent of the Receiver, that the above policy proposal be ratified. The AFRINIC Secretariat will revert back on the implementation. Kind Regards, Madhvi Gokool & Brice Abba Policy Liaisons References :- Policy Proposal - https://afrinic.net/policy/proposals/2020-gen-006-d3 PDWG Chairs Report - https://lists.afrinic.net/pipermail/rpd/2022/014142.html Kind Regards, Madhvi Gokool & Brice Abba -- AFRINIC Policy Liaison. t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From geier at geier.ne.tz Fri May 22 06:20:28 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Fri, 22 May 2026 09:20:28 +0300 Subject: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. In-Reply-To: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> References: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> Message-ID: <797e1318-3dd3-4b71-8ec3-9e0ffbe6239d@geier.ne.tz> Dear PDWG, a) I support this proposal. A colleague pointed out to me that this change is not all that needs to be done in this area - to improve IRR reliability. But we agree that this proposal is one very necessary step that absolutely goes in the right direction to avoid future creation of non-unique data. d) 1. Question: I understand "authoritative IRR databases" to mean the ones operated by RIRs. I hope everyone does the same. If not, should this phrase be defined in the proposal. I wish the proposal to succeed and wish to avoid this question to cause discussion or confusion later in the process. So I try to clarify it now. 2. about Language "an authoritative IRR server can't be sure that the proposed set name doesn't exist in all other IRR databases" I think if a name exists in 2 out of 4 of the other (RIR) IRR databases, then it can be said "it doesn't exist in all". Should that instead be "that the proposed set name doesn't exist in any other IRR databases" ? Or should that be "that the proposed set name is non-existent in all other IRR databases" ? I think this is an editorial change... 3. under 'Proposal' "The first element of the name must be an ASN" I hope we all understand that 'element' will be the things separated by colons (":"). I would humbly like to suggest to add "preceded by AS-" at the end, so this becomes "The first element of the name must be an ASN preceded by 'AS-'" I think this would just be an editorial change... 4. The necessity of "3. Other set types such as route sets are excluded." was questioned. It's not absolutely necessary. But I believe it can help. Maybe it can start with "For the avoidance of doubt: " ?? not a big issue. 5. Under the proposal Tab (https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft01#proposal) there is "4. References In other regions, all IPv4 addresses have been exhausted and it seems that the equivalent to the soft-landing is not any more an issue, because most of the existing members only can access IPv4 addresses via transfers." this seems to be irrelevant for this proposal. Also the next section is also called "5. References". is it there by mistake? I would like to emphasize that I did only suggest editorial changes and want for the proposal to succeed and get implemented in any case. Thanks, Frank Habicht On 5/20/2026 8:37 PM, dacostadarwin at gmail.com wrote: > Dear PDWG, > > We have received a new draft policy proposal - Require newly created AS-SETs to have hierarchical names, ID AFPUB-2026-ASN-001-DRAFT01 from author James Bensley. > > The proposal contents are published at: > https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft01 > > We encourage you to take some time to go through the proposal contents and provide feedback as follows: > > a) Do you support or oppose the proposal? > > b) If you oppose the proposal, state your reasons? > > c) Is there anything in the proposal that is not clear? > > d) What changes could be made to this proposal to make it more effective? > > Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From jordi.palet at consulintel.es Fri May 22 07:05:01 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Fri, 22 May 2026 09:05:01 +0200 Subject: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01. In-Reply-To: <6AAF451A-0A96-4933-A09C-4136A0396DA8@gmail.com> References: <29E79A7F-BF80-44DE-8B67-45521A95F2FB@consulintel.es> <6AAF451A-0A96-4933-A09C-4136A0396DA8@gmail.com> Message-ID: <42EF61FD-17A9-4480-AA72-2DEF4E0F8DC2@consulintel.es> Hi Musa, Tks for the inputs and clearly I will reconsidere some additional text changes. Regarding the other inconsistencies observed by the PIER, I?m not sure if you have seen the other proposal ? If so, please, use the other thread so we don?t mix inputs and make difficult to all to follow each proposal discussion. Tks! Regards, Jordi @jordipalet > El 21 may 2026, a las 20:00, Musa Stephen Honlue escribi?: > > Dear Jordi, > > On a lighter note, I sometimes feel that IPv4 has reached a stage where every remaining allocation feels like a very carefully managed shared resource ? which only reinforces the importance of clear and consistent exhaustion-phase policy. > > Thank you for the proposal to revise Section 5.4.6.1. The intent is positive, particularly in introducing flexibility for legitimate operational needs such as redundancy, high availability, IPv6 transition mechanisms, and expansion to new sites. > > However, I would like to highlight a few concerns and suggest refinements to improve clarity, consistency, and implementation robustness. > > 1. 90% utilisation requirement > > Firstly, while the 90% utilisation requirement provides a clear conservation baseline, it remains too rigid if not complemented by a more explicit consideration of architectural efficiency and operational context. > > A more balanced approach could retain the threshold while allowing justified exceptions based on clearly defined criteria. For example: > > ?In order to receive IPv4 allocations or assignments during the Exhaustion Phase, the LIR or End User must have used at least 90% of all previous allocations or assignments (including those made during both the Current Phase and the Exhaustion Phase). The above requirement may be waived where the request is justified by clearly demonstrated operational requirements that cannot be reasonably met within existing address space.? > > 2. Scope of waiver clause > > Secondly, the waiver clause for ?key technical needs? is currently broad and open to interpretation. Terms such as ?technical constraints? and ?new sites? would benefit from clearer definitions or bounded conditions to ensure consistent application and to avoid unintended ambiguity while postmasters evaluate resources requests, or misuse. > > It may be preferable to require documented justification demonstrating that the need cannot be satisfied within existing allocations. > > 3. ?First allocation? equivalence > > Thirdly, the provision stating that such cases are ?treated as a first allocation? may be too strong, as it risks bypassing the exhaustion-phase intent of the policy. A more appropriate framing would be that such requests are evaluated under criteria equivalent to a first allocation, while still preserving exhaustion-phase conservation principles. > > 4. Broader PIER-related consistency items > > Finally, I note that the proposal addresses an important part of the PIER findings, but there remain additional structural inconsistencies raised by staff that may require separate attention, including: > > planning horizon inconsistencies (8-month vs 12-month references), > minimum allocation inconsistency (/22 vs /24), > treatment and policy framework for recovered IPv4 address space (approximately 3 million addresses). > Addressing these alongside the current proposal may further improve overall policy coherence. > > Overall, I support the direction of the proposal and encourage strengthening the language around definitions, evaluation criteria, and safeguards to ensure consistency, predictability, and policy integrity. > > -- > Best Regards > -- > Musa Stephen HONLUE > Agile Coach | Project Manager | Digital Transformation Champion. > Systems/Network Engineer. > = > t: +230 57444041 / +237 6 9310 6174 > | tt: @mhonlue | linkedIn: https://www.linkedin.com/in/honluemusa/ > w: > www.skillsblocks.com| facebook.com/mhonlue > ___________________________ > >> On 21 May 2026, at 13:28, jordi.palet--- via RPD wrote: >> >> Hi all, >> >> This proposal, continuing with the idea of resolving the issues that have been discovered by the staff, is attempting to fix the problem of operators that need additional resources for redundancy, new sites (for example data centers), or even transition technologies. >> >> The actual soft landing proposal doesn?t cover those cases and only allows obtaining additional resources when 90% of utilizations is reached. >> >> Of course, I think is clear for all, that you don?t setup a data-center or other kinds of redundancy when your 1st data center is almost full, you actually want to have them being built even at the same time. >> >> Similarly when you, for example, want to deploy 464XLAT, and you have 4 PoPs where you will locate the NAT64 boxes, you will need some free IPv4 pools (for example 1x/24 and each POP), and you want to do that in all the PoPs, not one, wait for 90% utilization, then the next one, etc., because you want to make sure to provide high-availability. This is a very clear case for me, in my day-job deploying IPv6-only with IPv4-as-a-Service worldwide. >> >> This is easily achieved by waiving those requests from the 90% utilization and considering them as a ?first request? (in fact, it is a first request for a new site). >> >> The advantage for Afrinic, compared with other RIRs, is that we have recovered 3 millions of IPv4 addresses, so multiple sites allocations for every member, doesn?t mean draining earlier than expected the available pool when we entered in soft landing phases. >> >> Comments welcome! >> >> Tks! >> >> Regards, >> Jordi >> >> @jordipalet >> >> >>> El 15 may 2026, a las 17:51, dacostadarwin at gmail.com escribi?: >>> >>> Dear PDWG, >>> >>> We have received a new draft policy proposal - Amendment of Utilisation in Soft Landing, ID AFPUB-2026-IPv4-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>> >>> https://afrinic.net/policy/proposals/afpub-2026-ipv4-002-draft01 >>> >>> We encourage you to take some time to go through the proposal contents and provide feedback as follows : >>> >>> a) Do you support or oppose the proposal? >>> b) If you oppose the proposal, state your reasons? >>> c) Is there anything in the proposal that is not clear? >>> d) What changes could be made to this proposal to make it more effective? >>> >>> Regards, >>> Vincent Ngundi & Darwin Da Costa >>> AFRINIC PDWG Co-Chairs >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From geier at geier.ne.tz Fri May 22 07:05:46 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Fri, 22 May 2026 10:05:46 +0300 Subject: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. In-Reply-To: <797e1318-3dd3-4b71-8ec3-9e0ffbe6239d@geier.ne.tz> References: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> <797e1318-3dd3-4b71-8ec3-9e0ffbe6239d@geier.ne.tz> Message-ID: <31ea4ca7-5fe4-4f01-928e-52ae15c2b5db@geier.ne.tz> so I'm a bit confused - sorry. On 5/22/2026 9:20 AM, Frank Habicht wrote: > 3. under 'Proposal' > "The first element of the name must be an ASN" > I hope we all understand that 'element' will be the things separated by > colons (":"). > I would humbly like to suggest to add "preceded by AS-" at the end, so > this becomes > "The first element of the name must be an ASN preceded by 'AS-'" > I think this would just be an editorial change... RFC2622 section 5 https://www.rfc-editor.org/info/rfc2622/#section-5 gives valid examples such as "AS1:AS-CUSTOMERS, AS1:RS-EXPORT:AS2" but section 5.1 states that AS-SETs have to start with "as-". So maybe the word "ASN" in the text refers to a string such as "AS37181" and not just the number by itself. And even if not, likely what would need to be added in front would be "AS" and not "AS-" ... Not sure about item 3. of my comments - quoted above. Sorry for confusion. Frank From jordi.palet at consulintel.es Fri May 22 07:08:33 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Fri, 22 May 2026 09:08:33 +0200 Subject: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01. In-Reply-To: References: <29E79A7F-BF80-44DE-8B67-45521A95F2FB@consulintel.es> <6AAF451A-0A96-4933-A09C-4136A0396DA8@gmail.com> Message-ID: <4A8255DB-304E-4D9F-9C38-BD555AA24382@consulintel.es> Yep, understood and tks again. I was initially reading your email as ?all the 4 points are mandatory for me to support the proposal?. Of course, the staff impact analysis is always key to finally be able to fix the text, hopefully we can have it before the dead line for a new version of the proposal in time for the meeting! Regards, Jordi @jordipalet > El 21 may 2026, a las 20:19, Sami Salih escribi?: > > As I said, Jordi, I support the proposal. However, to address concerns about potential abuse, we need to define some safeguards. > The points I shared are not intended to be fully adopted as they are; they are simply the initial measures that came to my mind. Others may further refine, amend, or add additional safeguards as needed. > > I recommend including as many of these measures as possible in the proposal itself. Then, during staff review and further community discussion, they can be consolidated into a final set of safeguards to prevent abuse. > > I hope this clarifies how I see the way forward. > > > With Regards. > > Sami Salih. > > Sami Salih > From: Musa Stephen Honlue > Sent: Thursday, May 21, 2026 9:00:55 PM > To: jordi.palet at consulintel.es ; rpd at afrinic.net > Subject: Re: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01. > > Dear Jordi, > > On a lighter note, I sometimes feel that IPv4 has reached a stage where every remaining allocation feels like a very carefully managed shared resource ? which only reinforces the importance of clear and consistent exhaustion-phase policy. > > Thank you for the proposal to revise Section 5.4.6.1. The intent is positive, particularly in introducing flexibility for legitimate operational needs such as redundancy, high availability, IPv6 transition mechanisms, and expansion to new sites. > > However, I would like to highlight a few concerns and suggest refinements to improve clarity, consistency, and implementation robustness. > > 1. 90% utilisation requirement > > Firstly, while the 90% utilisation requirement provides a clear conservation baseline, it remains too rigid if not complemented by a more explicit consideration of architectural efficiency and operational context. > > A more balanced approach could retain the threshold while allowing justified exceptions based on clearly defined criteria. For example: > > ?In order to receive IPv4 allocations or assignments during the Exhaustion Phase, the LIR or End User must have used at least 90% of all previous allocations or assignments (including those made during both the Current Phase and the Exhaustion Phase). The above requirement may be waived where the request is justified by clearly demonstrated operational requirements that cannot be reasonably met within existing address space.? > > 2. Scope of waiver clause > > Secondly, the waiver clause for ?key technical needs? is currently broad and open to interpretation. Terms such as ?technical constraints? and ?new sites? would benefit from clearer definitions or bounded conditions to ensure consistent application and to avoid unintended ambiguity while postmasters evaluate resources requests, or misuse. > > It may be preferable to require documented justification demonstrating that the need cannot be satisfied within existing allocations. > > 3. ?First allocation? equivalence > > Thirdly, the provision stating that such cases are ?treated as a first allocation? may be too strong, as it risks bypassing the exhaustion-phase intent of the policy. A more appropriate framing would be that such requests are evaluated under criteria equivalent to a first allocation, while still preserving exhaustion-phase conservation principles. > > 4. Broader PIER-related consistency items > > Finally, I note that the proposal addresses an important part of the PIER findings, but there remain additional structural inconsistencies raised by staff that may require separate attention, including: > > planning horizon inconsistencies (8-month vs 12-month references), > minimum allocation inconsistency (/22 vs /24), > treatment and policy framework for recovered IPv4 address space (approximately 3 million addresses). > Addressing these alongside the current proposal may further improve overall policy coherence. > > Overall, I support the direction of the proposal and encourage strengthening the language around definitions, evaluation criteria, and safeguards to ensure consistency, predictability, and policy integrity. > > -- > Best Regards > -- > Musa Stephen HONLUE > Agile Coach | Project Manager | Digital Transformation Champion. > Systems/Network Engineer. > = > t: +230 57444041 / +237 6 9310 6174 > | tt: @mhonlue | linkedIn: https://www.linkedin.com/in/honluemusa/ > w: > www.skillsblocks.com| facebook.com/mhonlue > ___________________________ > >> On 21 May 2026, at 13:28, jordi.palet--- via RPD wrote: >> >> Hi all, >> >> This proposal, continuing with the idea of resolving the issues that have been discovered by the staff, is attempting to fix the problem of operators that need additional resources for redundancy, new sites (for example data centers), or even transition technologies. >> >> The actual soft landing proposal doesn?t cover those cases and only allows obtaining additional resources when 90% of utilizations is reached. >> >> Of course, I think is clear for all, that you don?t setup a data-center or other kinds of redundancy when your 1st data center is almost full, you actually want to have them being built even at the same time. >> >> Similarly when you, for example, want to deploy 464XLAT, and you have 4 PoPs where you will locate the NAT64 boxes, you will need some free IPv4 pools (for example 1x/24 and each POP), and you want to do that in all the PoPs, not one, wait for 90% utilization, then the next one, etc., because you want to make sure to provide high-availability. This is a very clear case for me, in my day-job deploying IPv6-only with IPv4-as-a-Service worldwide. >> >> This is easily achieved by waiving those requests from the 90% utilization and considering them as a ?first request? (in fact, it is a first request for a new site). >> >> The advantage for Afrinic, compared with other RIRs, is that we have recovered 3 millions of IPv4 addresses, so multiple sites allocations for every member, doesn?t mean draining earlier than expected the available pool when we entered in soft landing phases. >> >> Comments welcome! >> >> Tks! >> >> Regards, >> Jordi >> >> @jordipalet >> >> >>> El 15 may 2026, a las 17:51, dacostadarwin at gmail.com escribi?: >>> >>> Dear PDWG, >>> >>> We have received a new draft policy proposal - Amendment of Utilisation in Soft Landing, ID AFPUB-2026-IPv4-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>> >>> https://afrinic.net/policy/proposals/afpub-2026-ipv4-002-draft01 >>> >>> We encourage you to take some time to go through the proposal contents and provide feedback as follows : >>> >>> a) Do you support or oppose the proposal? >>> b) If you oppose the proposal, state your reasons? >>> c) Is there anything in the proposal that is not clear? >>> d) What changes could be made to this proposal to make it more effective? >>> >>> Regards, >>> Vincent Ngundi & Darwin Da Costa >>> AFRINIC PDWG Co-Chairs >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dewole.ajao at afrinic.net Fri May 22 07:54:54 2026 From: dewole.ajao at afrinic.net (Dewole Ajao [AFRINIC]) Date: Fri, 22 May 2026 08:54:54 +0100 Subject: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer In-Reply-To: References: <5BC824B3-E8E4-4509-B889-F3EC22391861@delong.com> Message-ID: Thank you, Sami for putting it nicely. I read the emails and was about to request the following: 1. That Mr DeLong be self-respecting and respectful of others (regardless of his feelings or motivations). Not being a stranger to the policy development process, it would appear that his comments were designed to be what my kids refer to as ?rage-baiting?. 2. That Mr Ehoumi and any others recognize that there is a PDWG leadership and as such refrain from giving any airtime to comments that are lacking in guidance or value. It is very okay to ignore posts. Where comments are derogatory or defamatory, the attention of the working group Chairs be called to such respectfully. We should let them do their work. 3. That the Working Group chairs and any AFRINIC staff supporting them issue the necessary cautions and keep a watch on the actors involved. If they can not behave themselves, they do not deserve to be on the list. It is a free and open forum but we should not allow unnecessary distractions. It had been a nice couple of days seeing policy proposals and discussions. Thank you all for helping the working group keep this a respectful space. With warm regards, Dewole Ajao. > On 22 May 2026, at 02:46, Sami Salih wrote: > > > Dear Co-Chairs, > > Point of order. > > I believe the tone and conduct reflected in the recent message require immediate intervention to maintain a civil and professional discussion environment on the mailing list. > > Technical disagreements are expected and welcome; however, discussions should remain respectful and constructive. > > With Regards, > Sami Salih. > From: Gregoire EHOUMI via RPD > Sent: Friday, May 22, 2026 2:22:34 AM > To: Owen DeLong > Cc: rpd > Subject: Re: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer > > Hi Owen > > The last point of section 3.6 defines conditions for recipient in another region: > "If the recipient is in another region, the conditions on the recipient are defined in the counterpart's RIR transfer policy? > > Is this so difficult to find? > > Insulting AFRINIC board, community and such arrogance shall not be tolerated anymore in revived PDP. > > Regards, > > Gregoire > > >> On May 21, 2026, at 7:30?AM, Owen DeLong via RPD wrote: >> >> Ratification of this policy only serves to prove that the board remains capable of absurdity. >> >> As written, the policy requires an out-of-region recipient allowed by the policy to comply with AFRINC policies, sign an AfriNIX RSA, etc. (section 3.6). >> >> Ridiculous. >> >> Owen >> >> >>> On Feb 8, 2026, at 22:45, Madhvi Gokool via RPD wrote: >>> >>> Dear >>> PDWG Members, >>> We >>> refer to the PDWG Chairs report on the draft policy proposal AFPUB-2020-GEN-006-DRAFT03 >>> AFRINIC >>> Number Resource Policy Transfer dated >>> 14 January 2022 and sent to the AFRINIC Board of Directors for ratification. The Board has also taken note of the report of the Policy Liaison dated 24 October 2025. >>> We >>> wish to inform you that the AFRINIC Board, at its meeting held on 4 February 2026, considered the PDWG Chairs' recommendation and resolved,with the consent of the Receiver, that the above policy proposal be ratified. >>> >>> The >>> AFRINIC Secretariat will revert back on the implementation. >>> >>> Kind >>> Regards, >>> Madhvi >>> Gokool & Brice Abba >>> Policy >>> Liaisons >>> >>> References >>> :- >>> Policy >>> Proposal - >>> https://afrinic.net/policy/proposals/2020-gen-006-d3 >>> PDWG >>> Chairs Report - >>> https://lists.afrinic.net/pipermail/rpd/2022/014142.html >>> >>> Kind >>> Regards, >>> Madhvi >>> Gokool & Brice Abba >>> -- >>> AFRINIC Policy Liaison. >>> t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net >>> facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent at ngundi.me.ke Fri May 22 09:33:21 2026 From: vincent at ngundi.me.ke (PDWG Chair) Date: Fri, 22 May 2026 12:33:21 +0300 Subject: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer In-Reply-To: <5BC824B3-E8E4-4509-B889-F3EC22391861@delong.com> References: <5BC824B3-E8E4-4509-B889-F3EC22391861@delong.com> Message-ID: <6030efb2-be92-48e9-a9e9-f186bd001a15@afrinic.net> Dear Owen We have taken note of your communication to RPD Mailing List^1 . Section 3.6 of the proposal published at _https://www.afrinic.net/policy/proposals/2020-gen-006-d3#proposal_ mentions conditions on the recipient if in the AFRINIC region and also mentions that in case the recipient is in another RIR, then the latter's transfer policy conditions will apply to the recipient. */3.6 Conditions on the recipient/* * /Will be subject to current AFRINIC policies./ * /Must sign RSA./ * /The recipient that does not have prior resources must:/ o /demonstrate a detailed plan for the use of the transferred resources (in the case of ASN, the recipient must meet the criteria for the assignment of ASN)./ * /The recipient with prior resources must:/ o /demonstrate a detailed plan for the use of the transferred resources (in the case of ASN, the recipient must meet the criteria for the assignment of ASN)./ o /show past usage rate./ o /provide evidence of compliance with AFRINIC policies with respect to past allocations/ assignments./ * /If the recipient is in another region, the conditions on the recipient are defined in the counterpart's RIR transfer policy/. It appears that only certain portions of the section were referenced in your post, whereas the full text provides necessary context and clarity. Furthermore, we noted that the RPD Mailing List was used to express grievances regarding the AFRINIC Board. Please be advised that any concerns regarding Board decisions should be addressed through the formal channels established for such matters, as they fall outside the scope of the AFRINIC Policy Development Process (PDP). The PDP is designed to facilitate constructive community feedback during discussion phases and the Last Call. The community is always encouraged to seek clarification or highlight potential omissions through these established participation windows. There were numerous opportunities to share your suggestions with the authors, the community, and the PDWG Co-Chairs during the earlier stages of this process. Moving forward, we would like to remind all PDWG members that the RPD Mailing List is dedicated to discussions concerning resource policies and the PDP. Maintaining a professional and respectful environment is essential to achieving productive outcomes for the community. We kindly request that you review and adhere to the AFRINIC Code of Conduct (https://www.afrinic.net/code ) in all future interactions on the mailing list. Best Regards, Dr. Vincent Ngundi & Darwin Da Costa *AFRINIC PDWG Co-Chairs* ** ^1 _https://lists.afrinic.net/pipermail/rpd/2026/014750.html_ On 21/05/2026 14:30, Owen DeLong via RPD wrote: > Ratification of this policy only serves to prove that the board > remains capable of absurdity. > > As written, the policy requires an out-of-region recipient allowed by > the policy to comply with AFRINC policies, sign an AfriNIX RSA, etc. > (section 3.6). > > Ridiculous. > > Owen > > >> On Feb 8, 2026, at 22:45, Madhvi Gokool via RPD wrote: >> >> ** >> >> * >> Dear PDWG Members, >> >> We refer to the PDWG Chairs report on the draft policy proposal >> AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer >> dated 14 January 2022 and sent to the AFRINIC Board of Directors for >> ratification. The Board has also taken note of the report of the >> Policy Liaison dated? 24 October 2025. >> We wish to inform you that the AFRINIC Board, at its meeting held on >> 4 February 2026, considered the PDWG Chairs' recommendation and >> resolved,with the consent of the Receiver,? that the above policy >> proposal be ratified. >> >> The? AFRINIC Secretariat will revert back on the implementation. >> >> Kind Regards, >> Madhvi Gokool & Brice Abba >> Policy Liaisons >> * >> * >> >> References :- >> Policy Proposal - https://afrinic.net/policy/proposals/2020-gen-006-d3 >> PDWG Chairs Report - >> https://lists.afrinic.net/pipermail/rpd/2022/014142.html >> >> Kind Regards, >> Madhvi Gokool & Brice Abba >> * >> -- >> AFRINIC Policy Liaison. >> t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net >> facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia >> > Part.txt>_______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent at ngundi.me.ke Fri May 22 09:42:16 2026 From: vincent at ngundi.me.ke (PDWG Chair) Date: Fri, 22 May 2026 12:42:16 +0300 Subject: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer In-Reply-To: References: <5BC824B3-E8E4-4509-B889-F3EC22391861@delong.com> Message-ID: <3a9533dd-1946-4bd8-b1d9-be91e232784f@afrinic.net> Dear Gregoire, We have taken note of your communication on the RPD Mailing List^1 . While we appreciate the provision of clarity, personal attacks are strictly unacceptable. As a member of the Policy Development Working Group (PDWG) and a policy author, we must reiterate that the RPD Mailing List is designated exclusively for discussions concerning resource policies and the AFRINIC Policy Development Process (PDP). Maintaining a professional and respectful environment is required to ensure productive outcomes regarding resource policies. We require that you review and fully adhere to the Code of Conduct, https://www.afrinic.net/code , in all future correspondence. Best Regards, Dr. Vincent Ngundi & Darwin Da Costa *AFRINIC PDWG Co-Chairs* ** ^1 https://lists.afrinic.net/pipermail/rpd/2026/014766.html On 22/05/2026 02:22, Gregoire EHOUMI via RPD wrote: > Hi Owen > > The last point of section 3.6 defines conditions for recipient in > another region: > "If the recipient is in another region, the conditions on the > recipient are defined in the counterpart's RIR transfer policy? > > ?Is this so difficult to find? > Insulting AFRINIC board, community and such arrogance shall not be > tolerated anymore in revived PDP. > > Regards, > > Gregoire > > >> On May 21, 2026, at 7:30?AM, Owen DeLong via RPD wrote: >> >> Ratification of this policy only serves to prove that the board >> remains capable of absurdity. >> >> As written, the policy requires an out-of-region recipient allowed by >> the policy to comply with AFRINC policies, sign an AfriNIX RSA, etc. >> (section 3.6). >> >> Ridiculous. >> >> Owen >> >> >>> On Feb 8, 2026, at 22:45, Madhvi Gokool via RPD wrote: >>> >>> ** >>> >>> * >>> Dear PDWG Members, >>> >>> We refer to the PDWG Chairs report on the draft policy proposal >>> AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer >>> dated 14 January 2022 and sent to the AFRINIC Board of Directors for >>> ratification. The Board has also taken note of the report of the >>> Policy Liaison dated? 24 October 2025. >>> We wish to inform you that the AFRINIC Board, at its meeting held on >>> 4 February 2026, considered the PDWG Chairs' recommendation and >>> resolved,with the consent of the Receiver,? that the above policy >>> proposal be ratified. >>> >>> The? AFRINIC Secretariat will revert back on the implementation. >>> >>> Kind Regards, >>> Madhvi Gokool & Brice Abba >>> Policy Liaisons >>> * >>> * >>> >>> References :- >>> Policy Proposal - https://afrinic.net/policy/proposals/2020-gen-006-d3 >>> PDWG Chairs Report - >>> https://lists.afrinic.net/pipermail/rpd/2022/014142.html >>> >>> Kind Regards, >>> Madhvi Gokool & Brice Abba >>> * >>> -- >>> AFRINIC Policy Liaison. >>> t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net >>> facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia >>> >> Part.txt>_______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent at ngundi.me.ke Fri May 22 09:48:17 2026 From: vincent at ngundi.me.ke (PDWG Chair) Date: Fri, 22 May 2026 12:48:17 +0300 Subject: [rpd] Adherence to AFRINIC Code of Conduct Message-ID: Dear PDWG, The AFRINIC Policy Development Process is currently resuming after a four-year period of inactivity. We invite all stakeholders, including Resource Members, to participate in the Policy Development Working Group and contribute to the constructive evolution of resource policies. We encourage all community members to adhere to the AFRINIC Code of Conduct (https://www.afrinic.net/code ) to ensure the RPD mailing list remains a respectful and professional environment. Your collaborative efforts and civil discourse are essential to achieving productive outcomes for the community. Best Regards, Dr. Vincent Ngundi & Darwin Da Costa *AFRINIC PDWG Co-Chairs* -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbemiadepojuesho at gmail.com Fri May 22 09:54:17 2026 From: gbemiadepojuesho at gmail.com (Gbemisola Esho) Date: Fri, 22 May 2026 10:54:17 +0100 Subject: [rpd] Adherence to AFRINIC Code of Conduct In-Reply-To: References: Message-ID: Dear Vincent and Dacosta, Well noted with thanks On Fri, 22 May 2026, 10:51 PDWG Chair, wrote: > Dear PDWG, > > > > The AFRINIC Policy Development Process is currently resuming after a > four-year period of inactivity. We invite all stakeholders, including > Resource Members, to participate in the Policy Development Working Group > and contribute to the constructive evolution of resource policies. > > > > We encourage all community members to adhere to the AFRINIC Code of > Conduct (https://www.afrinic.net/code) to ensure the RPD mailing list > remains a respectful and professional environment. Your collaborative > efforts and civil discourse are essential to achieving productive outcomes > for the community. > > > Best Regards, > > Dr. Vincent Ngundi & Darwin Da Costa > > *AFRINIC PDWG Co-Chairs* > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Fri May 22 10:01:53 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Fri, 22 May 2026 12:01:53 +0200 Subject: [rpd] general question for the staff Message-ID: <494B50BC-E35B-49DF-B2C2-93F38F61F801@consulintel.es> Hi all, This point comes back frequently in discussions in different policy proposals, and I think we need to make it clear for once. For example, yesterday Sami requested to add some kind of text for post-allocation follow-up. I don?t think we have specific policy (other RIRs have it) for reclaim and recover, however, my understanding is that the existing RSA already enforces the policy compliance and AFRINIC may reclaim resources to any member that, for example, requested IPv4 or IPv6 addressing space with some specific plans, and after 1 or 2 years, the plans have been sensibly altered or even not complied at all, showing bad-faith on the original request. Is my interpretation correct and coincident with AFRINIC or we should add very specific text for any policy proposal (or a generic proposal for lack of compliance like in some other RIRs), for AFRINIC to ?verify? after a given period the compliance? I will understand that plans for an organization may change, but I think in those cases, the organization must for its own interest, have an alternative plan for the business continuity/business strategy changes and that should be re-addressed with AFRINIC, in case the allocation of resources need to be modified. I think a very clear (and urgent) response is needed in case we need to add some text into a new version of the current proposals under discussion before the dead line for a possible v2. Tks! Regards, Jordi @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From amelnaud at gmail.com Sat May 23 15:56:56 2026 From: amelnaud at gmail.com (Arnaud AMELINA) Date: Sat, 23 May 2026 15:56:56 +0000 Subject: [rpd] =?utf-8?q?Impl=C3=A9mentation_of_CoC=2E?= In-Reply-To: References: <5BC824B3-E8E4-4509-B889-F3EC22391861@delong.com> Message-ID: Dear Cochairs.. Thanks for acting on this? For the sake of clarity, could you help me understand the ?personal attack? in Gregoire?s mail? He did point out to the missing line of a referenced section and raise your attention on a serious violation of the CoC as per section D. Thanks Regards -- Arnaud Le ven. 22 mai 2026 ? 07:55, Dewole Ajao [AFRINIC] via RPD a ?crit : > Thank you, Sami for putting it nicely. I read the emails and was about to > request the following: > > 1. That Mr DeLong be self-respecting and respectful of others (regardless > of his feelings or motivations). Not being a stranger to the policy > development process, it would appear that his comments were designed to be > what my kids refer to as ?rage-baiting?. > > 2. That Mr Ehoumi and any others recognize that there is a PDWG leadership > and as such refrain from giving any airtime to comments that are lacking in > guidance or value. It is very okay to ignore posts. Where comments are > derogatory or defamatory, the attention of the working group Chairs be > called to such respectfully. We should let them do their work. > > 3. That the Working Group chairs and any AFRINIC staff supporting them > issue the necessary cautions and keep a watch on the actors involved. If > they can not behave themselves, they do not deserve to be on the list. It > is a free and open forum but we should not allow unnecessary distractions. > It had been a nice couple of days seeing policy proposals and discussions. > > Thank you all for helping the working group keep this a respectful space. > > With warm regards, > Dewole Ajao. > > On 22 May 2026, at 02:46, Sami Salih wrote: > > > Dear Co-Chairs, > > Point of order. > > I believe the tone and conduct reflected in the recent message require > immediate intervention to maintain a civil and professional discussion > environment on the mailing list. > > Technical disagreements are expected and welcome; however, discussions > should remain respectful and constructive. > > With Regards, > Sami Salih. > ------------------------------ > *From:* Gregoire EHOUMI via RPD > *Sent:* Friday, May 22, 2026 2:22:34 AM > *To:* Owen DeLong > *Cc:* rpd > *Subject:* Re: [rpd] Ratified Policy Proposal - > AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer > > Hi Owen > > The last point of section 3.6 defines conditions for recipient in another > region: > "If the recipient is in another region, the conditions on the recipient > are defined in the counterpart's RIR transfer policy? > > Is this so difficult to find? > > Insulting AFRINIC board, community and such arrogance shall not be > tolerated anymore in revived PDP. > > Regards, > > Gregoire > > > On May 21, 2026, at 7:30?AM, Owen DeLong via RPD wrote: > > Ratification of this policy only serves to prove that the board remains > capable of absurdity. > > As written, the policy requires an out-of-region recipient allowed by the > policy to comply with AFRINC policies, sign an AfriNIX RSA, etc. (section > 3.6). > > Ridiculous. > > Owen > > > On Feb 8, 2026, at 22:45, Madhvi Gokool via RPD wrote: > > > > * Dear PDWG Members, We refer to the PDWG Chairs report on the draft > policy proposal AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy > Transfer dated 14 January 2022 and sent to the AFRINIC Board of Directors > for ratification. The Board has also taken note of the report of the Policy > Liaison dated 24 October 2025. We wish to inform you that the AFRINIC > Board, at its meeting held on 4 February 2026, considered the PDWG Chairs' > recommendation and resolved,with the consent of the Receiver, that the > above policy proposal be ratified. The AFRINIC Secretariat will revert > back on the implementation. Kind Regards, Madhvi Gokool & Brice Abba > Policy Liaisons * > > > * References :- Policy Proposal - > https://afrinic.net/policy/proposals/2020-gen-006-d3 > PDWG Chairs Report - > https://lists.afrinic.net/pipermail/rpd/2022/014142.html > Kind Regards, > Madhvi Gokool & Brice Abba * > > -- > AFRINIC Policy Liaison. > t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.netfacebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From seun.ojedeji at gmail.com Sat May 23 17:00:54 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Sat, 23 May 2026 12:00:54 -0500 Subject: [rpd] =?utf-8?q?Impl=C3=A9mentation_of_CoC=2E?= In-Reply-To: References: <5BC824B3-E8E4-4509-B889-F3EC22391861@delong.com> Message-ID: That's was not from the Co-Chairs Arnaud. Yeah Dewole was indeed a Co-chair in the past so it's understandable Bro :-) That said, the gist from the Board member was to remind us all that co-chairs are the custodian of the rpd and while we can bring a matter of CoC to their attention there is no need to engage the alleged infringer. Co-Chair Watch the list as well so I expect they will act accordingly when necessary. Regards ---- Sent from my mobile kindly excuse typos On Sat, 23 May 2026, 10:58?am Arnaud AMELINA, wrote: > Dear Cochairs.. Thanks for acting on this? For the sake of clarity, could > you help me understand the ?personal attack? in Gregoire?s mail? He did > point out to the missing line of a referenced section and raise your > attention on a serious violation of the CoC as per section D. Thanks > Regards > -- > Arnaud > > Le ven. 22 mai 2026 ? 07:55, Dewole Ajao [AFRINIC] via RPD < > rpd at afrinic.net> a ?crit : > >> Thank you, Sami for putting it nicely. I read the emails and was about to >> request the following: >> >> 1. That Mr DeLong be self-respecting and respectful of others (regardless >> of his feelings or motivations). Not being a stranger to the policy >> development process, it would appear that his comments were designed to be >> what my kids refer to as ?rage-baiting?. >> >> 2. That Mr Ehoumi and any others recognize that there is a PDWG >> leadership and as such refrain from giving any airtime to comments that are >> lacking in guidance or value. It is very okay to ignore posts. Where >> comments are derogatory or defamatory, the attention of the working group >> Chairs be called to such respectfully. We should let them do their work. >> >> 3. That the Working Group chairs and any AFRINIC staff supporting them >> issue the necessary cautions and keep a watch on the actors involved. If >> they can not behave themselves, they do not deserve to be on the list. It >> is a free and open forum but we should not allow unnecessary distractions. >> It had been a nice couple of days seeing policy proposals and discussions. >> >> Thank you all for helping the working group keep this a respectful space. >> >> With warm regards, >> Dewole Ajao. >> >> On 22 May 2026, at 02:46, Sami Salih wrote: >> >> >> Dear Co-Chairs, >> >> Point of order. >> >> I believe the tone and conduct reflected in the recent message require >> immediate intervention to maintain a civil and professional discussion >> environment on the mailing list. >> >> Technical disagreements are expected and welcome; however, discussions >> should remain respectful and constructive. >> >> With Regards, >> Sami Salih. >> ------------------------------ >> *From:* Gregoire EHOUMI via RPD >> *Sent:* Friday, May 22, 2026 2:22:34 AM >> *To:* Owen DeLong >> *Cc:* rpd >> *Subject:* Re: [rpd] Ratified Policy Proposal - >> AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer >> >> Hi Owen >> >> The last point of section 3.6 defines conditions for recipient in another >> region: >> "If the recipient is in another region, the conditions on the recipient >> are defined in the counterpart's RIR transfer policy? >> >> Is this so difficult to find? >> >> Insulting AFRINIC board, community and such arrogance shall not be >> tolerated anymore in revived PDP. >> >> Regards, >> >> Gregoire >> >> >> On May 21, 2026, at 7:30?AM, Owen DeLong via RPD wrote: >> >> Ratification of this policy only serves to prove that the board remains >> capable of absurdity. >> >> As written, the policy requires an out-of-region recipient allowed by the >> policy to comply with AFRINC policies, sign an AfriNIX RSA, etc. (section >> 3.6). >> >> Ridiculous. >> >> Owen >> >> >> On Feb 8, 2026, at 22:45, Madhvi Gokool via RPD wrote: >> >> >> >> * Dear PDWG Members, We refer to the PDWG Chairs report on the draft >> policy proposal AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy >> Transfer dated 14 January 2022 and sent to the AFRINIC Board of Directors >> for ratification. The Board has also taken note of the report of the Policy >> Liaison dated 24 October 2025. We wish to inform you that the AFRINIC >> Board, at its meeting held on 4 February 2026, considered the PDWG Chairs' >> recommendation and resolved,with the consent of the Receiver, that the >> above policy proposal be ratified. The AFRINIC Secretariat will revert >> back on the implementation. Kind Regards, Madhvi Gokool & Brice Abba >> Policy Liaisons * >> >> >> * References :- Policy Proposal - >> https://afrinic.net/policy/proposals/2020-gen-006-d3 >> PDWG Chairs Report - >> https://lists.afrinic.net/pipermail/rpd/2022/014142.html >> Kind Regards, >> Madhvi Gokool & Brice Abba * >> >> -- >> AFRINIC Policy Liaison. >> t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.netfacebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Sat May 23 18:16:17 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Sat, 23 May 2026 20:16:17 +0200 Subject: [rpd] general question for the staff In-Reply-To: <494B50BC-E35B-49DF-B2C2-93F38F61F801@consulintel.es> References: <494B50BC-E35B-49DF-B2C2-93F38F61F801@consulintel.es> Message-ID: <9b4ccb8d-d1fb-4e96-8aa7-302a43c85d68@uls.co.za> Short answer or long answer? This hits straight at the disputes between Cloud Innovation and Afrinic as I understand, and this is currently being tested back and forth in court. NRS is also sending a bunch of (in my humble opinion) FUD-generating emails around what and what does not constitute IP leasing.? For me the difference is quite clear, am I leasing IPs for the sake of leasing IPs, or do I utilise IPs as part of selling an IP-based service? I personally think things are clear-cut, as per inference below, but if that was the case it would not have ended up in court. I'm not a lawyer and I don't know what the right way forward here is. Kind regards, Jaco On 2026/05/22 12:01, jordi.palet--- via RPD wrote: > Hi all, > > This point comes back frequently in discussions in different policy proposals, and I think we need to make it clear for once. > > For example, yesterday Sami requested to add some kind of text for post-allocation follow-up. > > I don?t think we have specific policy (other RIRs have it) for reclaim and recover, however, my understanding is that the existing RSA already enforces the policy compliance and AFRINIC may reclaim resources to any member that, for example, requested IPv4 or IPv6 addressing space with some specific plans, and after 1 or 2 years, the plans have been sensibly altered or even not complied at all, showing bad-faith on the original request. > > Is my interpretation correct and coincident with AFRINIC or we should add very specific text for any policy proposal (or a generic proposal for lack of compliance like in some other RIRs), for AFRINIC to ?verify? after a given period the compliance? > > I will understand that plans for an organization may change, but I think in those cases, the organization must for its own interest, have an alternative plan for the business continuity/business strategy changes and that should be re-addressed with AFRINIC, in case the allocation of resources need to be modified. > > I think a very clear (and urgent) response is needed in case we need to add some text into a new version of the current proposals under discussion before the dead line for a possible v2. > > Tks! > > Regards, > Jordi > > @jordipalet > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From baya.sylvain at cmnog.cm Sat May 23 19:26:59 2026 From: baya.sylvain at cmnog.cm (Sylvain BAYA) Date: Sat, 23 May 2026 20:26:59 +0100 Subject: [rpd] general question for the staff In-Reply-To: <494B50BC-E35B-49DF-B2C2-93F38F61F801@consulintel.es> References: <494B50BC-E35B-49DF-B2C2-93F38F61F801@consulintel.es> Message-ID: <3d7865e6-3af9-4ce6-8d56-3580923df8e9@cmnog.cm> Le 22/05/2026 ? 11:01, jordi.palet--- via RPD a ?crit?: > Hi all, > > This point comes back frequently in discussions in different policy proposals, and I think we need to make it clear for once. > > For example, yesterday Sami requested to add some kind of text for post-allocation follow-up. > > I don?t think we have specific policy (other RIRs have it) for reclaim and recover, however, my understanding is that the existing RSA already enforces the policy compliance and AFRINIC may reclaim resources to any member that, for example, requested IPv4 or IPv6 addressing space with some specific plans, and after 1 or 2 years, the plans have been sensibly altered or even not complied at all, showing bad-faith on the original request. > > Is my interpretation correct and coincident with AFRINIC or we should add very specific text for any policy proposal (or a generic proposal for lack of compliance like in some other RIRs), for AFRINIC to ?verify? after a given period the compliance? > > I will understand that plans for an organization may change, but I think in those cases, the organization must for its own interest, have an alternative plan for the business continuity/business strategy changes and that should be re-addressed with AFRINIC, in case the allocation of resources need to be modified. > > I think a very clear (and urgent) response is needed in case we need to add some text into a new version of the current proposals under discussion before the dead line for a possible v2. > Hi Jordi, Thanks for the description; brother! Please, note that, a DPP proposal in its most mature version must be written in a manner such that a minimun bunch of safeguards is defined...in my opinion ;-) Therefore, what has be suggested by Sami (thanks brother) is the wisest approach; imho! We can't procrastinate here. Why? simply because if we don't follow that advice, then we could end up with a broken DPP adopted and its companion DPP leaved aside...as the Murphy's Law [1] may apply. __ [1]: https://en.wikipedia.org/wiki/Murphy%27s_law ...my choice is to start with what we can do right now. ...i'm not sure that, Policy Liaison Team have to decide in last resort in this question. Their impact analysis is always welcome; indeed :-) Thanks. Shalom, --sb. > Tks! > > Regards, > Jordi > > @jordipalet > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -- Best Regards ! baya.sylvain [AT cmNOG DOT cm] | cmNOG's Structure | CAMIX's Website | Douala-IX's Looking Glass | cmNOG's Surveys | Subscribe to cmNOG's Mailing List | __ #LASAINTEBIBLE|#Eph?siens5:18,15-21?[...] 18 Et *_ne vous enivrez_* pas *_de vin_*, en quoi *_il y a de la dissolution_*; mais *_soyez remplis de l'Esprit_*, [...]? ?#LASAINTEBIBLE|#H?breux13:9,5-15?[...] 9 _*Ne soyez pas seduits par*_ des _*doctrines diverses*_ et _*etrangeres*_, car il est bon _*que le coeur soit affermi par la grace*_, non par les viandes, lesquels n'ont pas profite ? ceux qui y ont marche. [...]? #AMEN,#Maranatha,#MerciJ?SUS! #?MaPri?re? est que tu naisses de nouveau.#Chr?tiennement -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x0387408365AC8594.asc Type: application/pgp-keys Size: 19437 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From honlue at gmail.com Sat May 23 20:00:55 2026 From: honlue at gmail.com (Musa Stephen Honlue) Date: Sat, 23 May 2026 22:00:55 +0200 Subject: [rpd] =?utf-8?q?Impl=C3=A9mentation_of_CoC=2E?= In-Reply-To: References: Message-ID: <43BE4FFE-C160-45B0-925B-6686EF63DED7@gmail.com> An HTML attachment was scrubbed... URL: From noah at neo.co.tz Sat May 23 21:07:23 2026 From: noah at neo.co.tz (Noah) Date: Sun, 24 May 2026 00:07:23 +0300 Subject: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer In-Reply-To: <5BC824B3-E8E4-4509-B889-F3EC22391861@delong.com> References: <5BC824B3-E8E4-4509-B889-F3EC22391861@delong.com> Message-ID: On Thu, 21 May 2026, 2:40?pm Owen DeLong via RPD, wrote: > Ratification of this policy only serves to prove that the board remains > capable of absurdity. > The internet community spent some time to discuss the proposal through version 1, version 2, and the final version 3 which obtained rough consensus and eventually consensus after all issues had been addressed by the PDWG. The last call period elapsed and the co-chairs sent version 3 of proposal to the board for consideration and ratification post PDWG process. The above bottom-up PDP process is not alien to you Delong. While you are a widely known controversial participant acrosss multiple policy development working groups that span multiple RIR.... Allow me to state the below... > As written, the policy requires an out-of-region recipient allowed by the > policy to comply with AFRINC policies, sign an AfriNIX RSA, etc. (section > 3.6). > The PDP provides the mechanism for anybody to submit a new proposal that addresses an issue with a clear problem statements as they are arise. Follow the PDP and to close my train of thought..... > Ridiculous. > > Owen > Contain your arrogance Mr. Noah -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjul.paul at gmail.com Sun May 24 01:55:07 2026 From: hjul.paul at gmail.com (Paul Hjul) Date: Sun, 24 May 2026 03:55:07 +0200 Subject: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer Message-ID: I shared Mark Elkins curiosity. Although I was perhaps a little less optimistic. Then I saw Owen's post and really hoped he was wrong. Being less optimistic has meant going over the record and putting together this email. It being a lazy Saturday has meant that this email comes after a couple of additions to the discussion. Owen has pointed out that the *AS WRITTEN* policy imposes on the recipient compliance with AFRINIC policies and to sign an RSA regardless of whether the recipient is an AFRINIC member or not. I really really really hoped he was wrong but unfortunately he is not. There is a difference in the presentation of Draft 3 (which is what has been ratified) and Draft 2. Draft 2 ( https://afrinic.net/policy/proposals/2020-gen-006-d2#proposal) appears as follows: [image: image.png] The bullets suggest (but an ambiguity arises) that you have 1,2 then 3 under one set of circumstances followed by 4 if 3 was not applicable. Followed by a general statement that lends itself to being an alternative to the whole section. Draft 3 (https://afrinic.net/policy/proposals/2020-gen-006-d3#proposal) presents the conditions as: [image: image.png] Draft 3 contains no indication that the section 3.6 was amended: [image: image.png] The PDWG co-chairs in an email provide a different formatting of the text: [image: image.png] Even with this formatting (which formatting was not circulated in any last call. The conditions on the recipient flow as: 1] Will be subject to AFRINIC policies, then 2] Must sign RSA, 3] IF not holding resources; 4] ELSE, 5] IF 1 and 2 are not indicated as conditional and nothing in 5 gives any indication of suppressing the application of 1 - 4. Therefore while "the full text provides necessary context" it doesn't provide clarity. To get clarity you have to dig further and when we dig further the clarity that comes up is not good for the PDP. I understand that Gregoire is attempting to convey that Owen is wrong and that the intent of the final point is to act as an alternative to the earlier points but this is not the most logical understanding of the text. The fact that the as written text produces an absurd policy that creates a massive problem for the organization doesn't mean that the text can be magically changed. At best it means the policy will be ignored or that a judicial authority will step in (and there are good reasons to assume that they won't). The phrase "the counterpart's RIR transfer policy" does not make sense to me. The term arises undoubtedly from the idea that other RIRs are counterparts to AFRINIC but there is nothing contractual (or at least there shouldn't be ...) involving AFRINIC the recipient, the source and another RIR in the transfer process. But putting that to one side its clear that both AFRINIC and another RIR transfer policy will give rise to conditions. This creates a mess. The real problem is the presumption that the recipient as a resource holder is under an RIR and that resource holders are in one region in the divided up world.. RIR service regions aren't a domicile or jurisdiction. I think the M word will start getting thrown around several gaskets blown when talk of carving up the market into regions with an enterprise controlling the market in their agreed upon region. It is difficult to say that a policy has "rough consensus" if there isn't agreement as to what a policy means or if the meaning is vague or ambiguous. As written draft 3 imposes on the recipient (whoever they may be) the It is worth noting that "Must sign RSA" doesn't specify which RSA, A major opportunity for problems arises if a host of conflicting contractual instruments are produced and I am quite sure that the A in RSA is for agreement. Does the policy act to mandate entering into an agreement by which supply of services are collusively controlled? Lets hope not, and lets really hope that it can't be argued persuasively that that is what is happening. It is also worth noting that *as written* the policy causes the resources to be "marked". Presumably once marked the resources will be the subject of further unstated policy prescriptions as may be promulgated. Nothing in the policy assures continued grandfathering in respect of "legacy". I don't understand why anybody who has "legacy" would "transfer" those resources into AFRINIC under this policy. The policy causes the resource ... I suspect that the authors of the policy (and probably AFRINIC staff) are harbouring the assumption that an AFRINIC member cannot also hold legacy resources or be a resource holder with resources within the administrative ambit of different RIRs. The staff assessment correctly identifies this problem: "It is important to highlight that, as a matter of law, legacy resource holders existing within the AFRINIC?s service region are not contractually bound by AFRINIC?s adopted policies such that these policies have no direct effect on legacy resource holders, and it is up to those legacy-holders to adhere to AFRINIC?s policies. Thus, the authors should bear in mind that obligations impacting legacy resource holders may not necessarily achieve the intended results if the legacy resource holders refuse to opt for voluntary registration of the transfer with AFRINIC." Looking at it from the perspective of a legacy resource holder the idea of this sort of divide up and marking would raise eyebrows. I suspect that an attempt to mute objections to the policy from legacy resource holders while avoiding a proper grandfathering in is what is attempted but the overall "solution" is probably not the outcome anybody was banking on. Now the best case scenario is to assume that the staff assessment's proposition of law is correct and that legacy resource holders aren't given an RSA to sign but the policy does not address the issue and you have legacy resource holders who do enter into an RSA for other resources. This policy demands the signing of an RSA. It is a little more than a bit absurd. I don't know if the ratification by the Board proves anything about the Board at all (so at least Owen is in my view wrong about one thing, unfortunately its a minor one and not what I was hoping he was wrong about when I took a dive into this). Ratification is on the advise of the PDWG and staff and if the Board refuses to ratify when given advise that the policy is order and after it has been vetted for implementation by staff it would be quite a tall order for the Board to refuse and with the documentation which would have been placed in front of the Board I don't think they or the Receiver had any basis not to ratify. This is particularly because of the language of the CPM (as at version 1.3) at 3.4.4 "The recommendation shall include a report of the discussions of the draft policy and feedback from the Last Call. The draft policy shall be ratified by the AFRINIC Board of Directors". I do not see real scope for reconsideration by the Board on their own volition. For the Board to act beyond being a rubber stamp requires reliance on the bylaws 11.4 as amended in 2020 [and that is assuming that 11.4 survives scrutiny] although in light of what will follow it might be necessary for the Board to consider an emergency measure. Now for the reasons I have set out the Board probably should revoke the ratification (although to be honest I am not entirely sure that such a power exists) or at least should not oppose the legal challenge which appears (https://afrinic.net/court-cases) to have been brought by Skyconnect in SC/COM/PWS/132/2026 [plaint challenging the Board's ratification of the transfer policy] to the ratification. It will be most problematic if AFRINIC expends resources on a policy that is dead on arrival or worse introduces problems for the organization *as written. *If the authors want the document defended then they can instruct solicitors in Mauritius. The process manual is clear that "No change can be made to a draft policy within one week of the meeting. This is so that a stable version of the draft policy can be considered at the meeting" . At PPM 34 ( https://afrinic.net/policy/development-working-group/ppm-afrinic-34) draft 2 was under discussion. The discussion was dominated by defensive posture of the authors and editorial changes desired by staff. Rough consensus was declared on a commitment to editorial changes. I don't see how you can have a version change of the document submitted after the PPM presumed to find rough consensus is held. This point was raised in the discussion by Jordi and I cautioned as to handling the situation in light of discussions of other conflicting policies that were ongoing. Be that as it may substance rather than form should be looked at. You could have a situation where a substantive and informed discussion on a 3rd draft produces actual consensus that is more coherent than the rough consensus in the 2nd draft. However what clearly happened is that version 3 was not circulated and discussed upon during last call and only an email ( https://lists.afrinic.net/pipermail/rpd/2021/014054.html) containing a link to version 3 was sent as "Summary of Proposal". I am not sure that such a summary can really be considered as an announcement but for present purposes it doesn't matter CPM 3.4.2 requires a distinct announcement of last call because even if it is accepted that the PDWG was in last call between 8th December 2021 and 5th January 2022 the document presented to PDWG gave no indication of the change to 3.6. More importantly the entirety of the discussion in 2022 ( https://lists.afrinic.net/pipermail/rpd/2022/date.html) (and the discussion from the date of the PPM) was in respect of version 2. There is not a single email outside of the co-chairs touching on version 3. There is also concurrent discussion on the withdrawn competing policy proposal and that discussion has not be absorbed into the consensus assessment of this policy proposal. If the AFRINIC staff responsible for enforcement of the code of conduct were committed to fair application that code they would take steps to address the clear and egregious misconduct of the authors of this policy proposal who have acted in bad faith and contrary to the effort to find solutions to problems. Owen's statement that "board remains capable of absurdity" is not one I agree with but its well within the bounds of civic discourse. The policy as ratified is absurd. The false accusation by one of the authors of the policy should result in the organisation doing the homework of walking through the adoption process. As I have confidence in the integrity of Dr Vincent Ngundi and Darwin Da Costa (the co-chairs) I expect that on being presented with clear evidence that the presumed rough consensus that they will take appropriate and prudent steps to guard the PDP from being brought into further disrepute. I hope I am not wrong on this point. In my view this particular policy proposal was a good faith effort by the PDWG co-chairs to get manifestly incompatible efforts to dictate policy into a single policy document but that unfortunately in the exercise of doing so a gremlin slipped through the cracks. What Owen has pointed out - and Mark sitting in anticipation as to "how this becomes implemented" - requires the PDWG co-chairs to do something. I am acutely aware of there existence of pressure to get an inter-RIR transfer policy and the ideological hunting grounds which this policy has landed in. The worry though is some years down the line and the need for a defensible and sound policy has only grown.This policy proposal was moved forward with amendments as other conflicting policy proposals timed out. The absence of an inter-RIR transfer policy was raising issues surrounding whether AFRINIC or the RIRs more broadly are operating such that the M word should be thrown about. And the as ratified proposal probably should see the M word being thrown about but it really should be getting some thought about related questions of collusive agreements and the like. Mike Silber strenuously disagreed with the contention that RIRs without an intra-RIR transfer policy would be a *de facto* monopoly and asserted that people were arguing beyond their scope of knowledge. When it comes to the field of competition law and policy everybody invariably steps a little bit out of their lane because of the interplay with economics, People involved in the Internet and telco space seem to really get quite religious about the M word. Of course competition considerations are broader than whether something is a monopoly. Now I've publicly taken the stand that in terms of design the RIRs, particularly AFRINIC does not fall within the general remit of Mauritius competition law or of any other competent jurisdiction's competition law (and by competence here I am referring of course to whether the jurisdictions law can legitimately find application rather than a comment on the jurisdiction or its judicial officers, lest somebody mischievously steps in on the word "competence", although there are conceivable circumstances where a possible cause outside Mauritius could arise) but both that there are circumstances in which a competition issue could arise and that the broad concept of promoting a competitive ecosystem should be a factor in decision making. Moreover, Mauritius is not in the European Union (or notwithstanding Brexit the United Kingdom - now through Statutory Instruments and using its own CMA) and so the Pavlov doctrine is not applicable and so arguing that AFRINICis an "undertaking" or more importantly an "enterprise" is a hard ask. I do think that if AFRINIC was in a country subject to the Treaty on the Functioning of the European Union a whole host of complexity would arise but ultimately that one of the 101(3) based block exemptions would apply [I don't feel like diving into my course and study notes on block exemptions beyond the TTBER as the nightmares for preparing for the exam Competition law and technology transfer haven't yet abated]. I actually followed up with the Mauritian authorities (and published to the Community Mailing List) on the matter and the response affirmed what I had said and contradicted the attempted spin from AFRINIC staff. I am of the view that the definition of "enterprise" (in Mauritius) which requires "engaged in commercial activities for gain or reward" is dispositive so long as AFRINIC is able to demonstrate that it is properly operating as a non-commercial entity that is not-for-profit. However a given RSA could be held to be within the scope of Section 41 or Section 44 (and thereby Section 41) of the Mauritius Competition Act of 2007 (as amended) does not depend on an enterprise being identified. if it can be shown that the RSA is an "agreement" which "significantly prevents, restricts or distorts competition" that agreement can be nullified by statute. Therefore an intentional policy that obliges a commercial entity to enter into an agreement which has the object or effect of restricting the acquisition of services by any person and significantly distorts competition puts you in a dangerous space. It is honestly a significant failing that within the staff assessment the legal assessment contains no indication of consideration of the Competition Act. You are welcome to argue (wrongly) that there are no concerns touching of the Competition Act but in light of what was discussed in the mailing lists the staff assessment is incomplete with this wrong position not being stated. In my view that this point alone necessitates a review of the action of the applicable staff who advised the Board to ratify. Also Mike was quite ready to point out that "ICP-2 no longer has any status" ( https://lists.afrinic.net/pipermail/rpd/2022/014296.html) and well that has definitely changed - exactly what the status of ICP-2 with the revision is is a lot more complicated. Moreover ICANN are now a party in winding up proceedings (Crystal Web's stance on the winding up of AFRINIC is on record) and I think they are very much taking on the role of supervising compliance to assure the Supreme Court that it is not in the interests of justice to wind up AFRINIC. So even without invoking the mighty M word there are clearly reasons to consider the competition dynamics and aspects of the registry system and the role the RIRs are playing. As written the policy holds that a "recipient" is subject both to AFRINIC policies (including any policy which is restrictive or materially hinders competition) and that they "must sign" a resource services agreement (which agreement would be void if it is held to be a collusive horizontal agreement) coupled with a sharing of commercial plans. Moreover the recipient is agreeing to adhere to further conditions imposed by a "counterpart" that being another RIR. It frankly does not matter whether somebody wants the policy to mean that the conditions of the recipient are different (rather than cumulative) if the recipient "is in another region". Moreover the "in another region" language presents its own major problem. A multinational resource holder would be in Africa and Europe, if such entity transfers resources to their European operation is the presence of the entity in Africa of relevance. Equally if an Australian company is the recipient of resources which it uses in African operations the phrase used ties those resources to two sets of policies... What of an African company (incorporated in an African state) that has significant ultimate beneficial shareholders in the "other regions"? If we consider what Ernest Byaruhanga and his henchmen were (and quite likely are) trying to do it may be the case of cockup before conspiracy but isn't that half of the idea and this point? Noah's email I think speaks to the fact that at least one of the authors intends the policy to make the impositions which Owen has raised as an absurdity. If it is indeed the case that the co-chairs presumed the agreed to amendments meant one thing and one of the authors was quite intentionally seeking to slip through something else well then you've got a problem. And here is another procedural problem, policy version 3's change from policy version 2 on the point at hand was not communicated publicly by the chairs and according to https://www.afrinic.net/policy/appeal-committee#members there was no appeal committee in effect at the time the chair's called consensus. [image: image.png] Moreover there isn't an PDAC at present. So clearly you have a situation in which any disregarding of valid technical objections by the co-chairs would fall through the cracks. Add to this the fact that the policy proposal was amended to address input from the staff and that there was a body of discussion on the version 2. I don't know why the Board in 2022 (while still quorate) did not ratify the policy but what is clear is that once a Board took office this policy was put before the Board as if the policy had simply been waiting ratification. I don't know what the co-chairs of the PDWG should do here. What I do know is that there is a problem with what was ratified and the authors of the policy document clearly want to drag the PDP into further disrepute. What I also know is that they owe Owen an apology. If the PDWG is to be a "professional and respectful environment is essential to achieving productive outcomes for the community" then that starts with the co-chairs. As I've shown it is incorrect to attribute to the Board but it is equally wrong to claim that an absurdity being ratified is outside the scope of the PDP when the absurdity is from the PDP. Considering that same co-chairs had previously muzzled Owen ( https://lists.afrinic.net/pipermail/rpd/2021/013969.html) the situation is a little worse. The stated grounds for the muzzling was improper and are a misuse of moderating power. Moreover it is clear that the complaint against Owen (which was spurious and an abuse of office) by the then CEO of AFRINIC and it is reasonable to assume that the PDWG was instructed to take steps against Owen due to the fact that he drew attention to the known corruption. As he correctly pointed out it is quite difficult to assert that a statement that there are crooks within an organization is defamatory especially if the speaker can point to a factual basis. If Owen was a vindictive character ... Fortunately for the individuals who are the co-chairs I don't think that he is. For present purposes though what is clear is that during the critical period when a discussion on the particulars of the 3rd draft was needed Owen was excluded from participation this not only means . It further gives a reasonable apprehension that the co-chairs exhibited bias in their handling of objections to the draft. I hope that if indeed the imposition of moderation was communicated by but not decided by the co-chairs that same will inform the PDWG of the same but failing that being communicated I am afraid they are responsible for the misconduct at hand. Even if a person wishes to gloss over the issue the consequence that the declared consensus is unsustainable cannot be ignored. What I hope is that the co-chairs reflect on their misconduct, apologise to both Owen and the PDWG and build on the experience. Then again I might be wrong and the co-chairs could decide to double down and back the authors of the impugned policy in which case the problems in the process do unfortunately become a concern for the Board. Either way I am afraid that trying to build consensus for the next PPM is going to be a bigger challenge than it really should be. On another note from PPM-34 then Proposal 5 "Policy Compliance Dashboard - Policy Proposal" reached consensus but does not appear to have moved on. I was supportive of this policy with an amendment and I really don't know why it hasn't moved further into planned implementation. If anything that policy with amendments was more ready for ratification than the transfer policy. Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 61442 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 86854 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 88847 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 80473 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 69360 bytes Desc: not available URL: From jordi.palet at consulintel.es Sun May 24 07:56:13 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Sun, 24 May 2026 09:56:13 +0200 Subject: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer In-Reply-To: References: Message-ID: <40FC3A6E-68D2-4B7E-8D71-2D30F7C4861D@consulintel.es> Hi Paul, I don?t recall now all the details of the discussion, which it seems you reviewed in detail and I agree with your summary. What I?m sure is that I always discussed the lack of complete reprocity with other RIRs, which impacts on the volume of transfers that can come in to AFRINIC, and also discussed that changes in a policy proposal can?t be done after consensus has been reached. In the last call we can do an editorial change, but what is the border line about what is an editorial change and what not? Some times can be subjective. For me is clear: anything that corrects grammar or orthography or improves the reading of the text, only if is clear that it doesn?t change the meaning of what was written when the consensus was achieved. To solve this problem, in LACNIC I submitted a proposal to modify the PDP in several aspects including this one, it reached consensus and was ratified in mid-2023, and was implemented in June 2024 with this text: "To publish a four-week last call for comments period for any proposal that reaches consensus. In the case of editorial changes, a new version of the proposal must be published and the last call for comments period must be restarted." This way, the chairs have the chance to re-evaluate that the editorial changes aren?t altering the view of the PDWG. Regarding the policy compliance dashboard, it was not ratified by the board: https://lists.afrinic.net/pipermail/rpd/2026/014703.html As a consequence, the authors had a call with the staff and then submitted several weeks ago a new version. We are waiting for possible inputs from the staff before publication. The major problem we are having is what I asked the staff to confirm very urgently in this email: https://lists.afrinic.net/pipermail/rpd/2026/014777.html Without a clear statement on that, any proposals that we submit, either, we need to reinforce the ?supervision? by AFRINIC and possible recovery of resources in case of lack of compliance, or AFRINIC has a general mandata to verify compliance of all the CPM and taking actions. Note that in all the RIRs this is very clear, and we even have in some cases, defined a very clear procedure by means of a policy (https://www.lacnic.net/687/2/lacnic/) so it is crystal clear and fair to all the resource holders. This is despite the RSAs being similar and not contradictory in this aspect. So either we have a problem with Mauritius legislation or the legal advisor of AFRINIC and the Board should reconsider if the CPM and possible new policies are in fact ?Encroaching? AFRINIC instead of trying to set fair procedures (please read the staff assessment https://afrinic.net/policy/proposals/2021-gen-003-d2#impact). Regards, Jordi @jordipalet > El 24 may 2026, a las 3:55, Paul Hjul escribi?: > > I shared Mark Elkins curiosity. Although I was perhaps a little less optimistic. Then I saw Owen's post and really hoped he was wrong. Being less optimistic has meant going over the record and putting together this email. It being a lazy Saturday has meant that this email comes after a couple of additions to the discussion. > > Owen has pointed out that the AS WRITTEN policy imposes on the recipient compliance with AFRINIC policies and to sign an RSA regardless of whether the recipient is an AFRINIC member or not. I really really really hoped he was wrong but unfortunately he is not. > > There is a difference in the presentation of Draft 3 (which is what has been ratified) and Draft 2. Draft 2 (https://afrinic.net/policy/proposals/2020-gen-006-d2#proposal) appears as follows: > > > > The bullets suggest (but an ambiguity arises) that you have 1,2 then 3 under one set of circumstances followed by 4 if 3 was not applicable. Followed by a general statement that lends itself to being an alternative to the whole section. > > Draft 3 (https://afrinic.net/policy/proposals/2020-gen-006-d3#proposal) presents the conditions as: > > > > Draft 3 contains no indication that the section 3.6 was amended: > > > > > The PDWG co-chairs in an email provide a different formatting of the text: > > > > > Even with this formatting (which formatting was not circulated in any last call. The conditions on the recipient flow as: 1] Will be subject to AFRINIC policies, then 2] Must sign RSA, 3] IF not holding resources; 4] ELSE, 5] IF > 1 and 2 are not indicated as conditional and nothing in 5 gives any indication of suppressing the application of 1 - 4. > > Therefore while "the full text provides necessary context" it doesn't provide clarity. To get clarity you have to dig further and when we dig further the clarity that comes up is not good for the PDP. > > I understand that Gregoire is attempting to convey that Owen is wrong and that the intent of the final point is to act as an alternative to the earlier points but this is not the most logical understanding of the text. The fact that the as written text produces an absurd policy that creates a massive problem for the organization doesn't mean that the text can be magically changed. At best it means the policy will be ignored or that a judicial authority will step in (and there are good reasons to assume that they won't). > > The phrase "the counterpart's RIR transfer policy" does not make sense to me. The term arises undoubtedly from the idea that other RIRs are counterparts to AFRINIC but there is nothing contractual (or at least there shouldn't be ...) involving AFRINIC the recipient, the source and another RIR in the transfer process. But putting that to one side its clear that both AFRINIC and another RIR transfer policy will give rise to conditions. This creates a mess. > > The real problem is the presumption that the recipient as a resource holder is under an RIR and that resource holders are in one region in the divided up world.. RIR service regions aren't a domicile or jurisdiction. I think the M word will start getting thrown around several gaskets blown when talk of carving up the market into regions with an enterprise controlling the market in their agreed upon region. > > It is difficult to say that a policy has "rough consensus" if there isn't agreement as to what a policy means or if the meaning is vague or ambiguous. As written draft 3 imposes on the recipient (whoever they may be) the > > It is worth noting that "Must sign RSA" doesn't specify which RSA, A major opportunity for problems arises if a host of conflicting contractual instruments are produced and I am quite sure that the A in RSA is for agreement. Does the policy act to mandate entering into an agreement by which supply of services are collusively controlled? Lets hope not, and lets really hope that it can't be argued persuasively that that is what is happening. > > It is also worth noting that as written the policy causes the resources to be "marked". Presumably once marked the resources will be the subject of further unstated policy prescriptions as may be promulgated. Nothing in the policy assures continued grandfathering in respect of "legacy". > I don't understand why anybody who has "legacy" would "transfer" those resources into AFRINIC under this policy. The policy causes the resource ... I suspect that the authors of the policy (and probably AFRINIC staff) are harbouring the assumption that an AFRINIC member cannot also hold legacy resources or be a resource holder with resources within the administrative ambit of different RIRs. The staff assessment correctly identifies this problem: > "It is important to highlight that, as a matter of law, legacy resource holders existing within the AFRINIC?s service region are not contractually bound by AFRINIC?s adopted policies such that these policies have no direct effect on legacy resource holders, and it is up to those legacy-holders to adhere to AFRINIC?s policies. Thus, the authors should bear in mind that obligations impacting legacy resource holders may not necessarily achieve the intended results if the legacy resource holders refuse to opt for voluntary registration of the transfer with AFRINIC." > > Looking at it from the perspective of a legacy resource holder the idea of this sort of divide up and marking would raise eyebrows. I suspect that an attempt to mute objections to the policy from legacy resource holders while avoiding a proper grandfathering in is what is attempted but the overall "solution" is probably not the outcome anybody was banking on. > > Now the best case scenario is to assume that the staff assessment's proposition of law is correct and that legacy resource holders aren't given an RSA to sign but the policy does not address the issue and you have legacy resource holders who do enter into an RSA for other resources. This policy demands the signing of an RSA. It is a little more than a bit absurd. > > I don't know if the ratification by the Board proves anything about the Board at all (so at least Owen is in my view wrong about one thing, unfortunately its a minor one and not what I was hoping he was wrong about when I took a dive into this). Ratification is on the advise of the PDWG and staff and if the Board refuses to ratify when given advise that the policy is order and after it has been vetted for implementation by staff it would be quite a tall order for the Board to refuse and with the documentation which would have been placed in front of the Board I don't think they or the Receiver had any basis not to ratify. This is particularly because of the language of the CPM (as at version 1.3) at 3.4.4 "The recommendation shall include a report of the discussions of the draft policy and feedback from the Last Call. The draft policy shall be ratified by the AFRINIC Board of Directors". I do not see real scope for reconsideration by the Board on their own volition. For the Board to act beyond being a rubber stamp requires reliance on the bylaws 11.4 as amended in 2020 [and that is assuming that 11.4 survives scrutiny] although in light of what will follow it might be necessary for the Board to consider an emergency measure. > > Now for the reasons I have set out the Board probably should revoke the ratification (although to be honest I am not entirely sure that such a power exists) or at least should not oppose the legal challenge which appears (https://afrinic.net/court-cases) to have been brought by Skyconnect in SC/COM/PWS/132/2026 [plaint challenging the Board's ratification of the transfer policy] to the ratification. It will be most problematic if AFRINIC expends resources on a policy that is dead on arrival or worse introduces problems for the organization as written. If the authors want the document defended then they can instruct solicitors in Mauritius. > > The process manual is clear that "No change can be made to a draft policy within one week of the meeting. This is so that a stable version of the draft policy can be considered at the meeting" . At PPM 34 (https://afrinic.net/policy/development-working-group/ppm-afrinic-34) draft 2 was under discussion. The discussion was dominated by defensive posture of the authors and editorial changes desired by staff. Rough consensus was declared on a commitment to editorial changes. > > I don't see how you can have a version change of the document submitted after the PPM presumed to find rough consensus is held. This point was raised in the discussion by Jordi and I cautioned as to handling the situation in light of discussions of other conflicting policies that were ongoing. Be that as it may substance rather than form should be looked at. You could have a situation where a substantive and informed discussion on a 3rd draft produces actual consensus that is more coherent than the rough consensus in the 2nd draft. > > However what clearly happened is that version 3 was not circulated and discussed upon during last call and only an email (https://lists.afrinic.net/pipermail/rpd/2021/014054.html) containing a link to version 3 was sent as "Summary of Proposal". I am not sure that such a summary can really be considered as an announcement but for present purposes it doesn't matter CPM 3.4.2 requires a distinct announcement of last call because even if it is accepted that the PDWG was in last call between 8th December 2021 and 5th January 2022 the document presented to PDWG gave no indication of the change to 3.6. More importantly the entirety of the discussion in 2022 (https://lists.afrinic.net/pipermail/rpd/2022/date.html) (and the discussion from the date of the PPM) was in respect of version 2. There is not a single email outside of the co-chairs touching on version 3. There is also concurrent discussion on the withdrawn competing policy proposal and that discussion has not be absorbed into the consensus assessment of this policy proposal. > > > If the AFRINIC staff responsible for enforcement of the code of conduct were committed to fair application that code they would take steps to address the clear and egregious misconduct of the authors of this policy proposal who have acted in bad faith and contrary to the effort to find solutions to problems. Owen's statement that "board remains capable of absurdity" is not one I agree with but its well within the bounds of civic discourse. The policy as ratified is absurd. The false accusation by one of the authors of the policy should result in the organisation doing the homework of walking through the adoption process. > > As I have confidence in the integrity of Dr Vincent Ngundi and Darwin Da Costa (the co-chairs) I expect that on being presented with clear evidence that the presumed rough consensus that they will take appropriate and prudent steps to guard the PDP from being brought into further disrepute. I hope I am not wrong on this point. > > In my view this particular policy proposal was a good faith effort by the PDWG co-chairs to get manifestly incompatible efforts to dictate policy into a single policy document but that unfortunately in the exercise of doing so a gremlin slipped through the cracks. What Owen has pointed out - and Mark sitting in anticipation as to "how this becomes implemented" - requires the PDWG co-chairs to do something. I am acutely aware of there existence of pressure to get an inter-RIR transfer policy and the ideological hunting grounds which this policy has landed in. The worry though is some years down the line and the need for a defensible and sound policy has only grown.This policy proposal was moved forward with amendments as other conflicting policy proposals timed out. The absence of an inter-RIR transfer policy was raising issues surrounding whether AFRINIC or the RIRs more broadly are operating such that the M word should be thrown about. And the as ratified proposal probably should see the M word being thrown about but it really should be getting some thought about related questions of collusive agreements and the like. > > Mike Silber strenuously disagreed with the contention that RIRs without an intra-RIR transfer policy would be a de facto monopoly and asserted that people were arguing beyond their scope of knowledge. When it comes to the field of competition law and policy everybody invariably steps a little bit out of their lane because of the interplay with economics, People involved in the Internet and telco space seem to really get quite religious about the M word. Of course competition considerations are broader than whether something is a monopoly. Now I've publicly taken the stand that in terms of design the RIRs, particularly AFRINIC does not fall within the general remit of Mauritius competition law or of any other competent jurisdiction's competition law (and by competence here I am referring of course to whether the jurisdictions law can legitimately find application rather than a comment on the jurisdiction or its judicial officers, lest somebody mischievously steps in on the word "competence", although there are conceivable circumstances where a possible cause outside Mauritius could arise) but both that there are circumstances in which a competition issue could arise and that the broad concept of promoting a competitive ecosystem should be a factor in decision making. Moreover, Mauritius is not in the European Union (or notwithstanding Brexit the United Kingdom - now through Statutory Instruments and using its own CMA) and so the Pavlov doctrine is not applicable and so arguing that AFRINICis an "undertaking" or more importantly an "enterprise" is a hard ask. I do think that if AFRINIC was in a country subject to the Treaty on the Functioning of the European Union a whole host of complexity would arise but ultimately that one of the 101(3) based block exemptions would apply [I don't feel like diving into my course and study notes on block exemptions beyond the TTBER as the nightmares for preparing for the exam Competition law and technology transfer haven't yet abated]. I actually followed up with the Mauritian authorities (and published to the Community Mailing List) on the matter and the response affirmed what I had said and contradicted the attempted spin from AFRINIC staff. I am of the view that the definition of "enterprise" (in Mauritius) which requires "engaged in commercial activities for gain or reward" is dispositive so long as AFRINIC is able to demonstrate that it is properly operating as a non-commercial entity that is not-for-profit. However a given RSA could be held to be within the scope of Section 41 or Section 44 (and thereby Section 41) of the Mauritius Competition Act of 2007 (as amended) does not depend on an enterprise being identified. if it can be shown that the RSA is an "agreement" which "significantly prevents, restricts or distorts competition" that agreement can be nullified by statute. Therefore an intentional policy that obliges a commercial entity to enter into an agreement which has the object or effect of restricting the acquisition of services by any person and significantly distorts competition puts you in a dangerous space. It is honestly a significant failing that within the staff assessment the legal assessment contains no indication of consideration of the Competition Act. You are welcome to argue (wrongly) that there are no concerns touching of the Competition Act but in light of what was discussed in the mailing lists the staff assessment is incomplete with this wrong position not being stated. In my view that this point alone necessitates a review of the action of the applicable staff who advised the Board to ratify. Also Mike was quite ready to point out that "ICP-2 no longer has any status" (https://lists.afrinic.net/pipermail/rpd/2022/014296.html) and well that has definitely changed - exactly what the status of ICP-2 with the revision is is a lot more complicated. Moreover ICANN are now a party in winding up proceedings (Crystal Web's stance on the winding up of AFRINIC is on record) and I think they are very much taking on the role of supervising compliance to assure the Supreme Court that it is not in the interests of justice to wind up AFRINIC. So even without invoking the mighty M word there are clearly reasons to consider the competition dynamics and aspects of the registry system and the role the RIRs are playing. > > As written the policy holds that a "recipient" is subject both to AFRINIC policies (including any policy which is restrictive or materially hinders competition) and that they "must sign" a resource services agreement (which agreement would be void if it is held to be a collusive horizontal agreement) coupled with a sharing of commercial plans. Moreover the recipient is agreeing to adhere to further conditions imposed by a "counterpart" that being another RIR. It frankly does not matter whether somebody wants the policy to mean that the conditions of the recipient are different (rather than cumulative) if the recipient "is in another region". > Moreover the "in another region" language presents its own major problem. A multinational resource holder would be in Africa and Europe, if such entity transfers resources to their European operation is the presence of the entity in Africa of relevance. Equally if an Australian company is the recipient of resources which it uses in African operations the phrase used ties those resources to two sets of policies... What of an African company (incorporated in an African state) that has significant ultimate beneficial shareholders in the "other regions"? > > > If we consider what Ernest Byaruhanga and his henchmen were (and quite likely are) trying to do it may be the case of cockup before conspiracy but isn't that half of the idea and this point? Noah's email I think speaks to the fact that at least one of the authors intends the policy to make the impositions which Owen has raised as an absurdity. If it is indeed the case that the co-chairs presumed the agreed to amendments meant one thing and one of the authors was quite intentionally seeking to slip through something else well then you've got a problem. > > And here is another procedural problem, policy version 3's change from policy version 2 on the point at hand was not communicated publicly by the chairs and according to https://www.afrinic.net/policy/appeal-committee#members there was no appeal committee in effect at the time the chair's called consensus. > > > > Moreover there isn't an PDAC at present. So clearly you have a situation in which any disregarding of valid technical objections by the co-chairs would fall through the cracks. Add to this the fact that the policy proposal was amended to address input from the staff and that there was a body of discussion on the version 2. > > I don't know why the Board in 2022 (while still quorate) did not ratify the policy but what is clear is that once a Board took office this policy was put before the Board as if the policy had simply been waiting ratification. > > > I don't know what the co-chairs of the PDWG should do here. What I do know is that there is a problem with what was ratified and the authors of the policy document clearly want to drag the PDP into further disrepute. What I also know is that they owe Owen an apology. If the PDWG is to be a "professional and respectful environment is essential to achieving productive outcomes for the community" then that starts with the co-chairs. As I've shown it is incorrect to attribute to the Board but it is equally wrong to claim that an absurdity being ratified is outside the scope of the PDP when the absurdity is from the PDP. > > Considering that same co-chairs had previously muzzled Owen (https://lists.afrinic.net/pipermail/rpd/2021/013969.html) the situation is a little worse. The stated grounds for the muzzling was improper and are a misuse of moderating power. Moreover it is clear that the complaint against Owen (which was spurious and an abuse of office) by the then CEO of AFRINIC and it is reasonable to assume that the PDWG was instructed to take steps against Owen due to the fact that he drew attention to the known corruption. As he correctly pointed out it is quite difficult to assert that a statement that there are crooks within an organization is defamatory especially if the speaker can point to a factual basis. > If Owen was a vindictive character ... Fortunately for the individuals who are the co-chairs I don't think that he is. > For present purposes though what is clear is that during the critical period when a discussion on the particulars of the 3rd draft was needed Owen was excluded from participation this not only means . It further gives a reasonable apprehension that the co-chairs exhibited bias in their handling of objections to the draft. > > I hope that if indeed the imposition of moderation was communicated by but not decided by the co-chairs that same will inform the PDWG of the same but failing that being communicated I am afraid they are responsible for the misconduct at hand. Even if a person wishes to gloss over the issue the consequence that the declared consensus is unsustainable cannot be ignored. What I hope is that the co-chairs reflect on their misconduct, apologise to both Owen and the PDWG and build on the experience. Then again I might be wrong and the co-chairs could decide to double down and back the authors of the impugned policy in which case the problems in the process do unfortunately become a concern for the Board. Either way I am afraid that trying to build consensus for the next PPM is going to be a bigger challenge than it really should be. > > On another note from PPM-34 then Proposal 5 "Policy Compliance Dashboard - Policy Proposal" reached consensus but does not appear to have moved on. I was supportive of this policy with an amendment and I really don't know why it hasn't moved further into planned implementation. If anything that policy with amendments was more ready for ratification than the transfer policy. > > Paul > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Sun May 24 08:05:14 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Sun, 24 May 2026 10:05:14 +0200 Subject: [rpd] general question for the staff In-Reply-To: <9b4ccb8d-d1fb-4e96-8aa7-302a43c85d68@uls.co.za> References: <494B50BC-E35B-49DF-B2C2-93F38F61F801@consulintel.es> <9b4ccb8d-d1fb-4e96-8aa7-302a43c85d68@uls.co.za> Message-ID: <534DF3FF-3D37-47B1-B8A2-86D8EEAF4CEF@consulintel.es> Hi Jaco, As I just said in a previous email, the problem is that in other RIRs is crystal clear also in the RSA and bylaws, but it is also allowed to further clarify it via policies, like: https://www.lacnic.net/687/2/lacnic/ In the case of AFRINIC, they perceive it as encroaching the staff, and then the board doesn?t ratify it. May be because Mauritius law and that means that we must change AFRINIC to another jurisdiction? What is clear is that the community is the responsible of how the resources are handled by means of policies (not the staff, not the Board, not AFRINIC as an organisation), and this ALSO means that if they are misused against the policies, the community also is the responsible and has the RIGHT to decide how and even when the resources must be recovered. AFRINIC just execute the orders of the community in regard to policies. This is the same in all the RIRs. Saludos, Jordi @jordipalet > El 23 may 2026, a las 20:16, Jaco Kroon escribi?: > > Short answer or long answer? > > This hits straight at the disputes between Cloud Innovation and Afrinic as I understand, and this is currently being tested back and forth in court. > > NRS is also sending a bunch of (in my humble opinion) FUD-generating emails around what and what does not constitute IP leasing. For me the difference is quite clear, am I leasing IPs for the sake of leasing IPs, or do I utilise IPs as part of selling an IP-based service? > > I personally think things are clear-cut, as per inference below, but if that was the case it would not have ended up in court. > > I'm not a lawyer and I don't know what the right way forward here is. > > Kind regards, > Jaco > > > On 2026/05/22 12:01, jordi.palet--- via RPD wrote: > >> Hi all, >> >> This point comes back frequently in discussions in different policy proposals, and I think we need to make it clear for once. >> >> For example, yesterday Sami requested to add some kind of text for post-allocation follow-up. >> >> I don?t think we have specific policy (other RIRs have it) for reclaim and recover, however, my understanding is that the existing RSA already enforces the policy compliance and AFRINIC may reclaim resources to any member that, for example, requested IPv4 or IPv6 addressing space with some specific plans, and after 1 or 2 years, the plans have been sensibly altered or even not complied at all, showing bad-faith on the original request. >> >> Is my interpretation correct and coincident with AFRINIC or we should add very specific text for any policy proposal (or a generic proposal for lack of compliance like in some other RIRs), for AFRINIC to ?verify? after a given period the compliance? >> >> I will understand that plans for an organization may change, but I think in those cases, the organization must for its own interest, have an alternative plan for the business continuity/business strategy changes and that should be re-addressed with AFRINIC, in case the allocation of resources need to be modified. >> >> I think a very clear (and urgent) response is needed in case we need to add some text into a new version of the current proposals under discussion before the dead line for a possible v2. >> >> Tks! >> >> Regards, >> Jordi >> >> @jordipalet >> >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From amelnaud at gmail.com Sun May 24 12:47:12 2026 From: amelnaud at gmail.com (Arnaud AMELINA) Date: Sun, 24 May 2026 12:47:12 +0000 Subject: [rpd] =?utf-8?q?Impl=C3=A9mentation_of_CoC=2E?= In-Reply-To: References: <5BC824B3-E8E4-4509-B889-F3EC22391861@delong.com> Message-ID: You are right, this is a new thread and the message is indeed to the current co-chairs. We really need to dig into implementation and enforcement of the CoC. Regards, ? Arnaud Le sam. 23 mai 2026 ? 17:01, Seun Ojedeji a ?crit : > That's was not from the Co-Chairs Arnaud. Yeah Dewole was indeed a > Co-chair in the past so it's understandable Bro :-) > That said, the gist from the Board member was to remind us all that > co-chairs are the custodian of the rpd and while we can bring a matter of > CoC to their attention there is no need to engage the alleged infringer. > Co-Chair Watch the list as well so I expect they will act accordingly when > necessary. > > Regards > > ---- > Sent from my mobile > kindly excuse typos > > On Sat, 23 May 2026, 10:58?am Arnaud AMELINA, wrote: > >> Dear Cochairs.. Thanks for acting on this? For the sake of clarity, could >> you help me understand the ?personal attack? in Gregoire?s mail? He did >> point out to the missing line of a referenced section and raise your >> attention on a serious violation of the CoC as per section D. Thanks >> Regards >> -- >> Arnaud >> >> Le ven. 22 mai 2026 ? 07:55, Dewole Ajao [AFRINIC] via RPD < >> rpd at afrinic.net> a ?crit : >> >>> Thank you, Sami for putting it nicely. I read the emails and was about >>> to request the following: >>> >>> 1. That Mr DeLong be self-respecting and respectful of others >>> (regardless of his feelings or motivations). Not being a stranger to the >>> policy development process, it would appear that his comments were designed >>> to be what my kids refer to as ?rage-baiting?. >>> >>> 2. That Mr Ehoumi and any others recognize that there is a PDWG >>> leadership and as such refrain from giving any airtime to comments that are >>> lacking in guidance or value. It is very okay to ignore posts. Where >>> comments are derogatory or defamatory, the attention of the working group >>> Chairs be called to such respectfully. We should let them do their work. >>> >>> 3. That the Working Group chairs and any AFRINIC staff supporting them >>> issue the necessary cautions and keep a watch on the actors involved. If >>> they can not behave themselves, they do not deserve to be on the list. It >>> is a free and open forum but we should not allow unnecessary distractions. >>> It had been a nice couple of days seeing policy proposals and discussions. >>> >>> Thank you all for helping the working group keep this a respectful >>> space. >>> >>> With warm regards, >>> Dewole Ajao. >>> >>> On 22 May 2026, at 02:46, Sami Salih wrote: >>> >>> >>> Dear Co-Chairs, >>> >>> Point of order. >>> >>> I believe the tone and conduct reflected in the recent message require >>> immediate intervention to maintain a civil and professional discussion >>> environment on the mailing list. >>> >>> Technical disagreements are expected and welcome; however, discussions >>> should remain respectful and constructive. >>> >>> With Regards, >>> Sami Salih. >>> ------------------------------ >>> *From:* Gregoire EHOUMI via RPD >>> *Sent:* Friday, May 22, 2026 2:22:34 AM >>> *To:* Owen DeLong >>> *Cc:* rpd >>> *Subject:* Re: [rpd] Ratified Policy Proposal - >>> AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer >>> >>> Hi Owen >>> >>> The last point of section 3.6 defines conditions for recipient in >>> another region: >>> "If the recipient is in another region, the conditions on the recipient >>> are defined in the counterpart's RIR transfer policy? >>> >>> Is this so difficult to find? >>> >>> Insulting AFRINIC board, community and such arrogance shall not be >>> tolerated anymore in revived PDP. >>> >>> Regards, >>> >>> Gregoire >>> >>> >>> On May 21, 2026, at 7:30?AM, Owen DeLong via RPD >>> wrote: >>> >>> Ratification of this policy only serves to prove that the board remains >>> capable of absurdity. >>> >>> As written, the policy requires an out-of-region recipient allowed by >>> the policy to comply with AFRINC policies, sign an AfriNIX RSA, etc. >>> (section 3.6). >>> >>> Ridiculous. >>> >>> Owen >>> >>> >>> On Feb 8, 2026, at 22:45, Madhvi Gokool via RPD wrote: >>> >>> >>> >>> * Dear PDWG Members, We refer to the PDWG Chairs report on the draft >>> policy proposal AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy >>> Transfer dated 14 January 2022 and sent to the AFRINIC Board of Directors >>> for ratification. The Board has also taken note of the report of the Policy >>> Liaison dated 24 October 2025. We wish to inform you that the AFRINIC >>> Board, at its meeting held on 4 February 2026, considered the PDWG Chairs' >>> recommendation and resolved,with the consent of the Receiver, that the >>> above policy proposal be ratified. The AFRINIC Secretariat will revert >>> back on the implementation. Kind Regards, Madhvi Gokool & Brice Abba >>> Policy Liaisons * >>> >>> >>> * References :- Policy Proposal - >>> https://afrinic.net/policy/proposals/2020-gen-006-d3 >>> PDWG Chairs Report - >>> https://lists.afrinic.net/pipermail/rpd/2022/014142.html >>> Kind Regards, >>> Madhvi Gokool & Brice Abba * >>> >>> -- >>> AFRINIC Policy Liaison. >>> t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.netfacebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From seun.ojedeji at gmail.com Sun May 24 15:27:19 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Sun, 24 May 2026 10:27:19 -0500 Subject: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03 AFRINIC Number Resource Policy Transfer In-Reply-To: References: <5BC824B3-E8E4-4509-B889-F3EC22391861@delong.com> Message-ID: Hi Noah, I agree that issues with a policy can be fixed by proposing new policy. However I do not believe that should be applicable to a policy that has just been approved if there is indeed an implementation issue then there is nothing wrong with the board coming back to highlight the challenges and rescending on their prior approval if necessary to give opportunity for the pdwg to address the issue. That said, I do not see an issue with the currently approved policy. As Gregoire rightly noted, last bullet point of section 3.6 addresses Owen's concern. That understanding was also reinforced by point 7 of legal's staff assessment of draft V2 of the policy in that the requirement for RSA, adherence to AFRINIC policy et all only refers to inbound transfers. Regards ---- Sent from my mobile kindly excuse typos On Sat, 23 May 2026, 4:08?pm Noah, wrote: > > On Thu, 21 May 2026, 2:40?pm Owen DeLong via RPD, wrote: > >> Ratification of this policy only serves to prove that the board remains >> capable of absurdity. >> > > The internet community spent some time to discuss the proposal through > version 1, version 2, and the final version 3 which obtained rough > consensus and eventually consensus after all issues had been addressed by > the PDWG. > > The last call period elapsed and the co-chairs sent version 3 of proposal > to the board for consideration and ratification post PDWG process. > > The above bottom-up PDP process is not alien to you Delong. While you are > a widely known controversial participant acrosss multiple policy > development working groups that span multiple RIR.... Allow me to state the > below... > > >> As written, the policy requires an out-of-region recipient allowed by the >> policy to comply with AFRINC policies, sign an AfriNIX RSA, etc. (section >> 3.6). >> > > The PDP provides the mechanism for anybody to submit a new proposal that > addresses an issue with a clear problem statements as they are arise. > Follow the PDP and to close my train of thought..... > > >> Ridiculous. >> >> Owen >> > > Contain your arrogance Mr. > > Noah > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dacostadarwin at gmail.com Mon May 25 15:19:09 2026 From: dacostadarwin at gmail.com (dacostadarwin at gmail.com) Date: Mon, 25 May 2026 17:19:09 +0200 Subject: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. Message-ID: <1EC212BF-EA11-4FB4-B5C4-B7429FFE6209@gmail.com> Dear PDWG, We have received a new draft policy proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01 from authors Gr?goire EHOUMI, Noah Maina and Adeola A. P. AINA. The proposal contents are published at: https://afrinic.net/policy/proposals/afpub-2026-gen-001-draft01 We encourage you to take some time to go through the proposal contents and provide feedback as follows : a) Do you support or oppose the proposal? b) If you oppose the proposal, state your reasons. c) Is there anything in the proposal that is not clear? d) What changes could be made to this proposal to make it more effective? Regards, Vincent Ngundi & Darwin Da Costa AFRINIC PDWG Co-Chairs From ben.roberts at afrinic.net Mon May 25 16:14:03 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Mon, 25 May 2026 19:14:03 +0300 Subject: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. In-Reply-To: <1EC212BF-EA11-4FB4-B5C4-B7429FFE6209@gmail.com> References: <1EC212BF-EA11-4FB4-B5C4-B7429FFE6209@gmail.com> Message-ID: <10461E18-A0FF-4DC9-B232-B23D572F591B@afrinic.net> I don?t think the RPD list was frozen during Afrinic?s period of stagnation? Only the community discuss list was frozen. Sent from my iPhone > On 25 May 2026, at 18:21, dacostadarwin at gmail.com wrote: > > ?Dear PDWG, > > We have received a new draft policy proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01 from authors Gr?goire EHOUMI, Noah Maina and Adeola A. P. AINA. > > The proposal contents are published at: https://afrinic.net/policy/proposals/afpub-2026-gen-001-draft01 > > We encourage you to take some time to go through the proposal contents and provide feedback as follows : > > a) Do you support or oppose the proposal? > > b) If you oppose the proposal, state your reasons. > > c) Is there anything in the proposal that is not clear? > > d) What changes could be made to this proposal to make it more effective? > > Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From seun.ojedeji at gmail.com Mon May 25 17:43:56 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Mon, 25 May 2026 12:43:56 -0500 Subject: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. In-Reply-To: <1EC212BF-EA11-4FB4-B5C4-B7429FFE6209@gmail.com> References: <1EC212BF-EA11-4FB4-B5C4-B7429FFE6209@gmail.com> Message-ID: Hello, Thanks for sharing this proposal. My initial comments after a brief review are the following: - A typical community member could also be an AFRINIC member. There is no reason to mandate that nomination supporters for the NRO NC must be both community members and AFRINIC members. Requiring one or 2 supporters from the service region should be sufficient. - The rpd is open to anyone that wishes to participate irrespective of origin, region or residence. It sure makes sense to restrict election participation to those with a historical record of involvement, either online or in-person to avoid historical experience of DDOS on election day. However, there is no reason to restrict the selectorate/electorate to those in the region alone. - I do not see the necessity of a Number Committee; it seems to create yet another layer. The Appeal committee which also serves as the recall committee can perform any intended role of the RNC. Its composition could be the 3 NRO NC members from the region, a past co-chair, and a past appeal committee chair in a non-voting capacity. In situations where both Co-Chairs are no more, the Chair of the Appeal committee can temporarily take over until rpd appoints a new co-chair - As a former co-chair of PDWG, i find the proposed responsibilities of the Co-chairs as described in section 3.3.2 to be overly granular and quite policing-like for lack of a better word. - I believe the proposed 3.3.7 should refer to AFRINIC CoC and that should be sufficient. The proposed penalties for violations look good, though they are a bit too wordy to me and the process leading to that is quite descriptive. We really need to give the co-chairs the privilege of managing events as they deem applicable - The idea that a co-chair eligibility should be tied to attending in-person meetings during a specific period isn't realistic given our region's unique challenges. I understand it may be an effort to put a face to the name but restricting eligibility to the last 2 years (which is basically last 4 PPM) isn't realistic. - 3.3.3.3.3 suggests co-chairs will be appointed by consensus, that is an interesting point that i would definitely not support. This can lead to unnecessary subjectivity. - I like the expectation of participation from Co-Chair hence 3.3.4 appeals to me as written. - Use of shall in 3.3.11 suggests that ratification is the only option for the Board. There should be an option for the Board to provide reasons for not ratifying and that should not be triggered by a petition. I may have more comments in future, but that is all from me for now. Regards On Mon, 25 May 2026 at 10:20, dacostadarwin at gmail.com < dacostadarwin at gmail.com> wrote: > Dear PDWG, > > We have received a new draft policy proposal - Amendment of the PDP > Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01 > from authors Gr?goire EHOUMI, Noah Maina and Adeola A. P. AINA. > > The proposal contents are published at: > https://afrinic.net/policy/proposals/afpub-2026-gen-001-draft01 > > We encourage you to take some time to go through the proposal contents > and provide feedback as follows : > > a) Do you support or oppose the proposal? > > b) If you oppose the proposal, state your reasons. > > c) Is there anything in the proposal that is not clear? > > d) What changes could be made to this proposal to make it more effective? > > Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -- ------------------------------------------------------------------------ *Seun Ojedeji,* Bringing another down does not take you up - think about your action! -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at alstonnetworks.net Wed May 27 05:53:09 2026 From: aa at alstonnetworks.net (Andrew Alston) Date: Wed, 27 May 2026 08:53:09 +0300 Subject: [rpd] Gauging Interest in a possible policy change Message-ID: Hi Guys, I've been giving this a lot of thought and want to gauge interest in adding a policy relating to the code of conduct. Effectively, what I foresee is language added to the policy which acts similar to the IETF Notewell, and specifies appropriate/inappropriate conduct both on the PDP List and during PDP meetings. Ideally speaking this will also include enforcement actions for the code of conduct, appeal procedures etc. Within the IETF framework for example, disruptive behavior can result in the temporary or permanent loss of posting rights to the list, and such enforcement actions are subject to a robust appeal mechanism. Before I start drafting however, I'd like to hear the PDP's thoughts on whether this is worth doing. Thanks Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From saul at enetworks.co.za Wed May 27 06:19:56 2026 From: saul at enetworks.co.za (Saul Stein) Date: Wed, 27 May 2026 06:19:56 +0000 Subject: [rpd] Gauging Interest in a possible policy change In-Reply-To: References: Message-ID: Hi Andrew, It?s sad that it?s come to this. I think a better idea would be rule that says after x warnings from the co-chairs, you have a 6month period of either moderation or suspension from posting. That should be in the code of conduct, not a specific policy. Regards Saul From: Andrew Alston Sent: Wednesday, 27 May 2026 07:53 To: RPD Subject: [rpd] Gauging Interest in a possible policy change Hi Guys, I've been giving this a lot of thought and want to gauge interest in adding a policy relating to the code of conduct. Effectively, what I foresee is language added to the policy which acts similar to the IETF Notewell, and specifies appropriate/inappropriate conduct both on the PDP List and during PDP meetings. Ideally speaking this will also include enforcement actions for the code of conduct, appeal procedures etc. Within the IETF framework for example, disruptive behavior can result in the temporary or permanent loss of posting rights to the list, and such enforcement actions are subject to a robust appeal mechanism. Before I start drafting however, I'd like to hear the PDP's thoughts on whether this is worth doing. Thanks Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at alstonnetworks.net Wed May 27 06:22:20 2026 From: aa at alstonnetworks.net (Andrew Alston) Date: Wed, 27 May 2026 09:22:20 +0300 Subject: [rpd] Gauging Interest in a possible policy change In-Reply-To: References: Message-ID: Hi Saul, I think my point here is that the PDP should in a way be self governing, and as such should specify its code of conduct (similar to rfc 7154 and related documents) Thanks Andrew On Wed, 27 May 2026 at 09:20, Saul Stein wrote: > Hi Andrew, > > > > It?s sad that it?s come to this. > > > > I think a better idea would be rule that says after x warnings from the > co-chairs, you have a 6month period of either moderation or suspension from > posting. > > > > That should be in the code of conduct, not a specific policy. > > > > Regards > > Saul > > > > > > *From:* Andrew Alston > *Sent:* Wednesday, 27 May 2026 07:53 > *To:* RPD > *Subject:* [rpd] Gauging Interest in a possible policy change > > > > Hi Guys, > > > > I've been giving this a lot of thought and want to gauge interest in > adding a policy relating to the code of conduct. > > > > Effectively, what I foresee is language added to the policy which acts > similar to the IETF Notewell, and specifies appropriate/inappropriate > conduct both on the PDP List and during PDP meetings. > > > > Ideally speaking this will also include enforcement actions for the code > of conduct, appeal procedures etc. > > > > Within the IETF framework for example, disruptive behavior can result in > the temporary or permanent loss of posting rights to the list, and such > enforcement actions are subject to a robust appeal mechanism. > > > > Before I start drafting however, I'd like to hear the PDP's thoughts on > whether this is worth doing. > > > > Thanks > > > > Andrew > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Wed May 27 06:49:24 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Wed, 27 May 2026 08:49:24 +0200 Subject: [rpd] Gauging Interest in a possible policy change In-Reply-To: References: Message-ID: <69DABC60-221A-4223-90BB-C114E3C46BE2@consulintel.es> Hi Andrew, A few years ago, in LACNIC we had similar issues with behaviours against the spirit of the equivalent list to this one. As I was IETF sergeant at arms for the IETF mailing list, and also participate in many other exploders that have AUPs (Acceptable Usage Policy), I used my experience to design a proposal for LACNIC, you can see the last version here: https://politicas.lacnic.net/politicas/detail/id/LAC-2018-13/language/en It took a long time to discuss the proposal, and when it was almost reaching consensus (in my opinion), LACNIC decided to make a CoC which somehow superseddes the AUP. Nevertheless, I still have encountered feelings if an AUP may be also needed in parallel to the CoC, as the CoC is quite generic while the AUP can provide a ore clear path to co-chairs. So if you reach the conclusion that this is good to have, I?m happy to work with you/others in that, or feel free to use that proposal as a starting point that was discussed during 3 years in a very similar context. Regards, Jordi @jordipalet > El 27 may 2026, a las 7:53, Andrew Alston escribi?: > > Hi Guys, > > I've been giving this a lot of thought and want to gauge interest in adding a policy relating to the code of conduct. > > Effectively, what I foresee is language added to the policy which acts similar to the IETF Notewell, and specifies appropriate/inappropriate conduct both on the PDP List and during PDP meetings. > > Ideally speaking this will also include enforcement actions for the code of conduct, appeal procedures etc. > > Within the IETF framework for example, disruptive behavior can result in the temporary or permanent loss of posting rights to the list, and such enforcement actions are subject to a robust appeal mechanism. > > Before I start drafting however, I'd like to hear the PDP's thoughts on whether this is worth doing. > > Thanks > > Andrew > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dewole.ajao at afrinic.net Wed May 27 07:00:58 2026 From: dewole.ajao at afrinic.net (Dewole Ajao [AFRINIC]) Date: Wed, 27 May 2026 08:00:58 +0100 Subject: [rpd] Gauging Interest in a possible policy change In-Reply-To: References: Message-ID: Thanks, Andrew. While I am not currently making any comments on the subject matter at this point, I would like to commend the approach of coming to the list to check for interest in working together to solve what you believe may be a problem that needs to be solved. By getting to a wider understanding of whether or not there is a problem to be solved (and possibly the root causes), before policy text is proposed, the working group will be more efficient in its deliberations and even the first draft (if it ever gets to draft stages) will be more robust because it would ideally carry inputs from the discussions within the working group (even if members choose not to join as authors). This has been suggested to policy proposal authors over the years and I hope we can do more of this type of engagement in our policy development. With warm regards, Dewole. > On 27 May 2026, at 06:53, Andrew Alston wrote: > > Hi Guys, > > I've been giving this a lot of thought and want to gauge interest in adding a policy relating to the code of conduct. > > Effectively, what I foresee is language added to the policy which acts similar to the IETF Notewell, and specifies appropriate/inappropriate conduct both on the PDP List and during PDP meetings. > > Ideally speaking this will also include enforcement actions for the code of conduct, appeal procedures etc. > > Within the IETF framework for example, disruptive behavior can result in the temporary or permanent loss of posting rights to the list, and such enforcement actions are subject to a robust appeal mechanism. > > Before I start drafting however, I'd like to hear the PDP's thoughts on whether this is worth doing. > > Thanks > > Andrew > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From benson_muite at emailplus.org Wed May 27 07:35:17 2026 From: benson_muite at emailplus.org (Benson Muite) Date: Wed, 27 May 2026 10:35:17 +0300 Subject: [rpd] Gauging Interest in a possible policy change In-Reply-To: References: Message-ID: <87jysp2tl6.fsf@emailplus.org> Andrew Alston writes: Hi, (Will avoid gendered pronouns in case anyone feels left out)! > Hi Guys, > > I've been giving this a lot of thought and want to gauge interest in adding > a policy relating to the code of conduct. > > Effectively, what I foresee is language added to the policy which acts > similar to the IETF Notewell, and specifies appropriate/inappropriate > conduct both on the PDP List and during PDP meetings. This would probably be helpful. The IETF has much more transparency than AFRINIC. It is not structured as a private company so legal requirements for transparency in decision making, and in use of funds are stricter. Every other RIR is structured as an non-profit public benefit non governmental organization. Within the IETF, there are structures to get input from outside the IETF for some decisions, for example from ISOC a broader community of internet stakeholders. A code of conduct could help streamline useful input but should not not prevent dissenting voices from being heard - this can be difficult in large communities with diverse backgrounds. When there is disruptive behavior in the IETF, one can ask for further details and decide on whether a warranted point is being made - some of the post quantum standards are at least worthy of further individual investigation. IETF processes have originated from a specific culture, they are generally good, but could still be improved in terms of getting dissenting voices heard. Not all elements may work well for AFRINIC, but the experience is something that AFRINIC could learn from and use to improve. > > Ideally speaking this will also include enforcement actions for the code of > conduct, appeal procedures etc. > Codes of conduct are often not drafted by people with any legal background so are often guidelines for desired behavior and can be difficult to enforce in some jurisdictions as they maybe in conflict with local laws. Codes of conduct are easier to change than by-laws and as changes would probably be needed, having this would be better than putting it in the by-laws until they stabilise. > Within the IETF framework for example, disruptive behavior can result in > the temporary or permanent loss of posting rights to the list, and such > enforcement actions are subject to a robust appeal mechanism. > > Before I start drafting however, I'd like to hear the PDP's thoughts on > whether this is worth doing. > In my personal opinion this would be helpful, though my opinion is that AFRINIC also needs broader restructuring and if such a restructuring were to occur, how much would be carried over? Benson > Thanks > > Andrew From seun.ojedeji at gmail.com Wed May 27 10:48:51 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Wed, 27 May 2026 05:48:51 -0500 Subject: [rpd] Gauging Interest in a possible policy change In-Reply-To: References: Message-ID: Hi Andrew, AFRINIC does have an existing code of conduct[1] whether it is sufficient in present realities is a different thing. I do not believe the rpd need to have a different CoC but I think it may be appropriate for rpd to document the process to follow when AFRINIC CoC is violated. Regards [1] https://afrinic.net/code ---- Sent from my mobile kindly excuse typos On Wed, 27 May 2026, 12:55?am Andrew Alston, wrote: > Hi Guys, > > I've been giving this a lot of thought and want to gauge interest in > adding a policy relating to the code of conduct. > > Effectively, what I foresee is language added to the policy which acts > similar to the IETF Notewell, and specifies appropriate/inappropriate > conduct both on the PDP List and during PDP meetings. > > Ideally speaking this will also include enforcement actions for the code > of conduct, appeal procedures etc. > > Within the IETF framework for example, disruptive behavior can result in > the temporary or permanent loss of posting rights to the list, and such > enforcement actions are subject to a robust appeal mechanism. > > Before I start drafting however, I'd like to hear the PDP's thoughts on > whether this is worth doing. > > Thanks > > Andrew > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sami.salih at outlook.com Wed May 27 13:25:34 2026 From: sami.salih at outlook.com (Sami Salih) Date: Wed, 27 May 2026 13:25:34 +0000 Subject: [rpd] Gauging Interest in a possible policy change In-Reply-To: References: Message-ID: Salam Andrew, I would support having a specific CoC policy within the PDWG context. However, after reviewing the current AFRINIC Code of Conduct, I find that it is generic enough to cover broader community interactions, while it's relatively comprehensive to serve the PDWG and other lists. In particular, the existing sections related to: D) Enforcement of the Code of Conduct; and E) Understanding AFRINIC Warning Process on AFRINIC Mailing Lists. already provide a reasonable foundation to address uncivilized or disruptive behaviour. That said, I believe the current warning and enforcement mechanisms may still require strengthening to better address severe or harmful conduct from the outset, especially in cases of repeated or highly disruptive behaviour. Overall, if AFRINIC maintains a sufficiently high-level and enforceable organizational CoC, there may be limited need for a fully separate PDWG-specific CoC. In my view, the current framework generally serves the purpose, with some targeted amendments and clearer enforcement provisions. With regards, Sami Salih. Sami Salih ________________________________ From: Seun Ojedeji Sent: Wednesday, May 27, 2026 1:48:51 PM To: Andrew Alston Cc: RPD Subject: Re: [rpd] Gauging Interest in a possible policy change Hi Andrew, AFRINIC does have an existing code of conduct[1] whether it is sufficient in present realities is a different thing. I do not believe the rpd need to have a different CoC but I think it may be appropriate for rpd to document the process to follow when AFRINIC CoC is violated. Regards [1] https://afrinic.net/code ---- Sent from my mobile kindly excuse typos On Wed, 27 May 2026, 12:55?am Andrew Alston, > wrote: Hi Guys, I've been giving this a lot of thought and want to gauge interest in adding a policy relating to the code of conduct. Effectively, what I foresee is language added to the policy which acts similar to the IETF Notewell, and specifies appropriate/inappropriate conduct both on the PDP List and during PDP meetings. Ideally speaking this will also include enforcement actions for the code of conduct, appeal procedures etc. Within the IETF framework for example, disruptive behavior can result in the temporary or permanent loss of posting rights to the list, and such enforcement actions are subject to a robust appeal mechanism. Before I start drafting however, I'd like to hear the PDP's thoughts on whether this is worth doing. Thanks Andrew _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From theresadukumor at gmail.com Wed May 27 13:53:26 2026 From: theresadukumor at gmail.com (Theresa Dukumor) Date: Wed, 27 May 2026 14:53:26 +0100 Subject: [rpd] RPD Digest, Vol 220, Issue 41 In-Reply-To: References: Message-ID: Hi Andrew, I see the value, but I'm cautious. Conduct rules have been twisted to protect insiders and exclude criticism. Adding a conduct code could make things worse. We should limit it to clear harm like harassment and spam, not vague tone complaints. The IETF model only works because of its open culture. Let's not copy the form without the substance. Will need to see the draft and the oversight plan before I can support it. Regards, Theresa On Wed, May 27, 2026 at 11:49?AM wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: Gauging Interest in a possible policy change > (jordi.palet at consulintel.es) > 2. Re: Gauging Interest in a possible policy change > (Dewole Ajao [AFRINIC]) > 3. Re: Gauging Interest in a possible policy change (Benson Muite) > 4. Re: Gauging Interest in a possible policy change (Seun Ojedeji) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 27 May 2026 08:49:24 +0200 > From: "jordi.palet at consulintel.es" > To: RPD > Subject: Re: [rpd] Gauging Interest in a possible policy change > Message-ID: <69DABC60-221A-4223-90BB-C114E3C46BE2 at consulintel.es> > Content-Type: text/plain; charset="utf-8" > > Hi Andrew, > > A few years ago, in LACNIC we had similar issues with behaviours against > the spirit of the equivalent list to this one. > > As I was IETF sergeant at arms for the IETF mailing list, and also > participate in many other exploders that have AUPs (Acceptable Usage > Policy), I used my experience to design a proposal for LACNIC, you can see > the last version here: > > https://politicas.lacnic.net/politicas/detail/id/LAC-2018-13/language/en > > It took a long time to discuss the proposal, and when it was almost > reaching consensus (in my opinion), LACNIC decided to make a CoC which > somehow superseddes the AUP. > > Nevertheless, I still have encountered feelings if an AUP may be also > needed in parallel to the CoC, as the CoC is quite generic while the AUP > can provide a ore clear path to co-chairs. > > So if you reach the conclusion that this is good to have, I?m happy to > work with you/others in that, or feel free to use that proposal as a > starting point that was discussed during 3 years in a very similar context. > > Regards, > Jordi > > @jordipalet > > > > El 27 may 2026, a las 7:53, Andrew Alston > escribi?: > > > > Hi Guys, > > > > I've been giving this a lot of thought and want to gauge interest in > adding a policy relating to the code of conduct. > > > > Effectively, what I foresee is language added to the policy which acts > similar to the IETF Notewell, and specifies appropriate/inappropriate > conduct both on the PDP List and during PDP meetings. > > > > Ideally speaking this will also include enforcement actions for the code > of conduct, appeal procedures etc. > > > > Within the IETF framework for example, disruptive behavior can result in > the temporary or permanent loss of posting rights to the list, and such > enforcement actions are subject to a robust appeal mechanism. > > > > Before I start drafting however, I'd like to hear the PDP's thoughts on > whether this is worth doing. > > > > Thanks > > > > Andrew > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260527/9c03f681/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Wed, 27 May 2026 08:00:58 +0100 > From: "Dewole Ajao [AFRINIC]" > To: Andrew Alston > Cc: RPD > Subject: Re: [rpd] Gauging Interest in a possible policy change > Message-ID: > Content-Type: text/plain; charset=us-ascii > > Thanks, Andrew. > > While I am not currently making any comments on the subject matter at this > point, > > I would like to commend the approach of coming to the list to check for > interest in working together to solve what you believe may be a problem > that needs to be solved. > > By getting to a wider understanding of whether or not there is a problem > to be solved (and possibly the root causes), before policy text is > proposed, the working group will be more efficient in its deliberations and > even the first draft (if it ever gets to draft stages) will be more robust > because it would ideally carry inputs from the discussions within the > working group (even if members choose not to join as authors). > > This has been suggested to policy proposal authors over the years and I > hope we can do more of this type of engagement in our policy development. > > With warm regards, > Dewole. > > > On 27 May 2026, at 06:53, Andrew Alston wrote: > > > > Hi Guys, > > > > I've been giving this a lot of thought and want to gauge interest in > adding a policy relating to the code of conduct. > > > > Effectively, what I foresee is language added to the policy which acts > similar to the IETF Notewell, and specifies appropriate/inappropriate > conduct both on the PDP List and during PDP meetings. > > > > Ideally speaking this will also include enforcement actions for the code > of conduct, appeal procedures etc. > > > > Within the IETF framework for example, disruptive behavior can result in > the temporary or permanent loss of posting rights to the list, and such > enforcement actions are subject to a robust appeal mechanism. > > > > Before I start drafting however, I'd like to hear the PDP's thoughts on > whether this is worth doing. > > > > Thanks > > > > Andrew > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > ------------------------------ > > Message: 3 > Date: Wed, 27 May 2026 10:35:17 +0300 > From: Benson Muite > To: Andrew Alston , RPD > Subject: Re: [rpd] Gauging Interest in a possible policy change > Message-ID: <87jysp2tl6.fsf at emailplus.org> > Content-Type: text/plain > > Andrew Alston writes: > Hi, > > (Will avoid gendered pronouns in case anyone feels left out)! > > > Hi Guys, > > > > I've been giving this a lot of thought and want to gauge interest in > adding > > a policy relating to the code of conduct. > > > > Effectively, what I foresee is language added to the policy which acts > > similar to the IETF Notewell, and specifies appropriate/inappropriate > > conduct both on the PDP List and during PDP meetings. > > This would probably be helpful. The IETF has much more transparency > than AFRINIC. It is not structured as a private company so legal > requirements for transparency in decision making, and in use of funds > are stricter. Every other RIR is structured as an non-profit public > benefit non governmental organization. > > Within the IETF, there are structures to get input from outside the IETF > for some decisions, for example from ISOC a broader community of > internet stakeholders. > > A code of conduct could help streamline useful input but should not not > prevent dissenting voices from being heard - this can be difficult in > large communities with diverse backgrounds. > > When there is disruptive behavior in the IETF, one can ask for further > details and decide on whether a warranted point is being made - some of > the post quantum standards are at least worthy of further individual > investigation. IETF processes have originated from a specific culture, > they are generally good, but could still be improved in terms of getting > dissenting voices heard. Not all elements may work well for AFRINIC, > but the experience is something that AFRINIC could learn from and use to > improve. > > > > > Ideally speaking this will also include enforcement actions for the code > of > > conduct, appeal procedures etc. > > > > Codes of conduct are often not drafted by people with any legal > background so are often guidelines for desired behavior and can be > difficult to enforce in some jurisdictions as they maybe in conflict > with local laws. Codes of conduct are easier to change than by-laws and > as changes would probably be needed, having this would be better than > putting it in the by-laws until they stabilise. > > > Within the IETF framework for example, disruptive behavior can result in > > the temporary or permanent loss of posting rights to the list, and such > > enforcement actions are subject to a robust appeal mechanism. > > > > Before I start drafting however, I'd like to hear the PDP's thoughts on > > whether this is worth doing. > > > > In my personal opinion this would be helpful, though my opinion is that > AFRINIC also needs broader restructuring and if such a restructuring > were to occur, how much would be carried over? > > Benson > > > Thanks > > > > Andrew > > > > ------------------------------ > > Message: 4 > Date: Wed, 27 May 2026 05:48:51 -0500 > From: Seun Ojedeji > To: Andrew Alston > Cc: RPD > Subject: Re: [rpd] Gauging Interest in a possible policy change > Message-ID: > < > CAD_dc6g9tBzMH6O3NJC3wnirT+jHjZrTJCw_3-QfPhmLTWJD2Q at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Andrew, > > AFRINIC does have an existing code of conduct[1] whether it is sufficient > in present realities is a different thing. > > I do not believe the rpd need to have a different CoC but I think it may be > appropriate for rpd to document the process to follow when AFRINIC CoC is > violated. > > Regards > [1] https://afrinic.net/code > ---- > Sent from my mobile > kindly excuse typos > > On Wed, 27 May 2026, 12:55?am Andrew Alston, > wrote: > > > Hi Guys, > > > > I've been giving this a lot of thought and want to gauge interest in > > adding a policy relating to the code of conduct. > > > > Effectively, what I foresee is language added to the policy which acts > > similar to the IETF Notewell, and specifies appropriate/inappropriate > > conduct both on the PDP List and during PDP meetings. > > > > Ideally speaking this will also include enforcement actions for the code > > of conduct, appeal procedures etc. > > > > Within the IETF framework for example, disruptive behavior can result in > > the temporary or permanent loss of posting rights to the list, and such > > enforcement actions are subject to a robust appeal mechanism. > > > > Before I start drafting however, I'd like to hear the PDP's thoughts on > > whether this is worth doing. > > > > Thanks > > > > Andrew > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260527/2c2c8a43/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 220, Issue 41 > ************************************ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sami.salih at outlook.com Wed May 27 18:45:15 2026 From: sami.salih at outlook.com (Sami Salih) Date: Wed, 27 May 2026 18:45:15 +0000 Subject: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. In-Reply-To: References: <1EC212BF-EA11-4FB4-B5C4-B7429FFE6209@gmail.com> Message-ID: Dear Colleagues, As a former PDWG Co-chair, I generally support the intent behind strengthening the autonomy and operational continuity of the PDWG. The policy development process ultimately belongs to the African Internet community and should remain resilient regardless of operational or governance challenges affecting AFRINIC as an organisation. At the same time, I believe it is important to recognize that this proposal introduces substantial structural, operational, procedural, and governance changes to the PDP framework. In many respects, this is a major and transformative proposal rather than a routine procedural update. >From my experience with the PDP, the community process tends to work best when addressing clearly scoped issues through focused and easy-to-understand proposals. In contrast, this proposal attempts to address many different governance, electoral, operational, disciplinary, and procedural matters simultaneously, which makes it difficult for the community to fully analyse, discuss, and build meaningful consensus around all aspects at once. IMHO, many of the ideas and intended improvements presented in this proposal are constructive and deserve serious consideration. I also fully acknowledge and respect the extensive experience, effort, and strategic thinking of the authors in developing such a comprehensive framework proposal. However, considering the breadth of the changes and the number of distinct governance and operational matters being introduced simultaneously, my respectful recommendation would be to consider withdrawing the current proposal and restructuring this work into multiple smaller and more focused proposals. I believe this would make it significantly easier for the community to understand, analyse, discuss, and build meaningful consensus around each individual topic independently, while improving overall community engagement and participation in the process. With Regards, Sami Sali. Sami Salih ________________________________ From: Seun Ojedeji Sent: Monday, May 25, 2026 8:43:56 PM To: dacostadarwin at gmail.com Cc: rpd at afrinic.net Subject: Re: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. Hello, Thanks for sharing this proposal. My initial comments after a brief review are the following: - A typical community member could also be an AFRINIC member. There is no reason to mandate that nomination supporters for the NRO NC must be both community members and AFRINIC members. Requiring one or 2 supporters from the service region should be sufficient. - The rpd is open to anyone that wishes to participate irrespective of origin, region or residence. It sure makes sense to restrict election participation to those with a historical record of involvement, either online or in-person to avoid historical experience of DDOS on election day. However, there is no reason to restrict the selectorate/electorate to those in the region alone. - I do not see the necessity of a Number Committee; it seems to create yet another layer. The Appeal committee which also serves as the recall committee can perform any intended role of the RNC. Its composition could be the 3 NRO NC members from the region, a past co-chair, and a past appeal committee chair in a non-voting capacity. In situations where both Co-Chairs are no more, the Chair of the Appeal committee can temporarily take over until rpd appoints a new co-chair - As a former co-chair of PDWG, i find the proposed responsibilities of the Co-chairs as described in section 3.3.2 to be overly granular and quite policing-like for lack of a better word. - I believe the proposed 3.3.7 should refer to AFRINIC CoC and that should be sufficient. The proposed penalties for violations look good, though they are a bit too wordy to me and the process leading to that is quite descriptive. We really need to give the co-chairs the privilege of managing events as they deem applicable - The idea that a co-chair eligibility should be tied to attending in-person meetings during a specific period isn't realistic given our region's unique challenges. I understand it may be an effort to put a face to the name but restricting eligibility to the last 2 years (which is basically last 4 PPM) isn't realistic. - 3.3.3.3.3 suggests co-chairs will be appointed by consensus, that is an interesting point that i would definitely not support. This can lead to unnecessary subjectivity. - I like the expectation of participation from Co-Chair hence 3.3.4 appeals to me as written. - Use of shall in 3.3.11 suggests that ratification is the only option for the Board. There should be an option for the Board to provide reasons for not ratifying and that should not be triggered by a petition. I may have more comments in future, but that is all from me for now. Regards On Mon, 25 May 2026 at 10:20, dacostadarwin at gmail.com > wrote: Dear PDWG, We have received a new draft policy proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01 from authors Gr?goire EHOUMI, Noah Maina and Adeola A. P. AINA. The proposal contents are published at: https://afrinic.net/policy/proposals/afpub-2026-gen-001-draft01 We encourage you to take some time to go through the proposal contents and provide feedback as follows : a) Do you support or oppose the proposal? b) If you oppose the proposal, state your reasons. c) Is there anything in the proposal that is not clear? d) What changes could be made to this proposal to make it more effective? Regards, Vincent Ngundi & Darwin Da Costa AFRINIC PDWG Co-Chairs _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd -- ------------------------------------------------------------------------ Seun Ojedeji, Bringing another down does not take you up - think about your action! -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at inter.link Thu May 28 07:54:37 2026 From: james at inter.link (James Bensley) Date: Thu, 28 May 2026 07:54:37 +0000 Subject: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. In-Reply-To: References: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> Message-ID: Hi Jaco, Thank you for the support and your feedback. I wrote the original proposal. Regarding this comment: "The only thing that I found weird is that the second element has to be a name, why would "ASnum:ASnum2:AS-name" not be acceptable?" If you have a use case for that, then that could be added to the proposal. Do you have a use case/requirement for this? I think this usage is very rare, but if you have this use case, please speak up :) Regarding this comment: "The purpose/function of "3. Other set types such as route sets are excluded." is unclear - everything else speaks specifically to AS-SET so why is this mention required?" Because route-sets can also support hierarchical names and in the past people have had the thought "well if we're making this change for AS-SETs let's also making it for Route-Sets whilst we're here" - but route-sets are extremely rarely used today and this just adds scope which I think isn't needed. So it was just about trying to stop that scope creep. With kind regards, James Bensley (he/him) ________________________________________ From: Jaco Kroon Sent: 21 May 2026 14:06 To: dacostadarwin at gmail.com ; rpd at afrinic.net Subject: Re: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. Hi, Definitely in support. The only thing that I found weird is that the second element has to be a name, why would "ASnum:ASnum2:AS-name" not be acceptable? The purpose/function of "3. Other set types such as route sets are excluded." is unclear - everything else speaks specifically to AS-SET so why is this mention required? Kind regards, Jaco On 2026/05/20 19:37, dacostadarwin at gmail.com wrote: > Dear PDWG, > > We have received a new draft policy proposal - Require newly created AS-SETs to have hierarchical names, ID AFPUB-2026-ASN-001-DRAFT01 from author James Bensley. > > The proposal contents are published at: > https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft01 > > We encourage you to take some time to go through the proposal contents and provide feedback as follows: > > a) Do you support or oppose the proposal? > > b) If you oppose the proposal, state your reasons? > > c) Is there anything in the proposal that is not clear? > > d) What changes could be made to this proposal to make it more effective? > > Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd [CompanySignature] Inter..link GmbH | Boxhagener Stra?e 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello at inter.link | Web: inter.link From dacostadarwin at gmail.com Thu May 28 08:05:07 2026 From: dacostadarwin at gmail.com (Darwin Da Costa) Date: Thu, 28 May 2026 10:05:07 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. Message-ID: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> Dear PDWG, We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: https://afrinic.net/afpub-2026-v6-001-draft01 We encourage you to take some time to go through the proposal contents and provide feedback as follows: a)Do you support or oppose the proposal? b) If you oppose the proposal, state your reasons? c) Is there anything in the proposal that is not clear? d) What changes could be made to this proposal to make it more effective? Regards, Vincent Ngundi & Darwin Da Costa AFRINIC PDWG Co-Chairs -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Thu May 28 08:07:01 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Thu, 28 May 2026 10:07:01 +0200 Subject: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. In-Reply-To: References: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> Message-ID: Hi James, On 2026/05/28 09:54, James Bensley wrote: > Hi Jaco, > > Thank you for the support and your feedback. > > I wrote the original proposal. Regarding this comment: > > "The only thing that I found weird is that the second element has to be a name, why would "ASnum:ASnum2:AS-name" not be acceptable?" > > If you have a use case for that, then that could be added to the proposal. Do you have a use case/requirement for this? I think this usage is very rare, but if you have this use case, please speak up :) It's a hierarchy right, so what if I want to refer my customers by their AS numbers? Eg, ASyyyy:ASxxxx:AS-set It's an arbitrary and in my opinion unneeded restriction which can be removed.? The only restriction is that the first component has to be ASnum where you have control over AS num.? The rest can be left to the discretion of the ASnum admin surely? So just drop bullet three entirely. > > > Regarding this comment: > > "The purpose/function of "3. Other set types such as route sets are excluded." is unclear - everything else speaks specifically to AS-SET so why is this mention required?" > > Because route-sets can also support hierarchical names and in the past people have had the thought "well if we're making this change for AS-SETs let's also making it for Route-Sets whilst we're here" - but route-sets are extremely rarely used today and this just adds scope which I think isn't needed. So it was just about trying to stop that scope creep. I hear you. 7.8 as as whole specifically states "AS-SET" - not "Set Types", and point 1 also makes it clears this refers specifically to AS-SET, which means point 3 can be dropped without changing the intent/meaning of 7.8 as a whole. Point 4 also really adds no value, that's an operational issue, not a policy issue.? Definitely a valid point and something to be aware but still operational, not policy. Exceptions to the policy may need to be permitted on a case by case basis *if and only if* a non-hierarchical AS-SET has been accidentally deleted to allow recreation.? IMHO these should require motivation to have them restored from where they can then be edited again as per point 6. Kind regards, Jaco > > With kind regards, > James Bensley (he/him) > > ________________________________________ > From: Jaco Kroon > Sent: 21 May 2026 14:06 > To: dacostadarwin at gmail.com ; rpd at afrinic.net > Subject: Re: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. > > Hi, > > Definitely in support. > > The only thing that I found weird is that the second element has to be a > name, why would "ASnum:ASnum2:AS-name" not be acceptable? > > The purpose/function of "3. Other set types such as route sets are > excluded." is unclear - everything else speaks specifically to AS-SET so > why is this mention required? > > Kind regards, > Jaco > > On 2026/05/20 19:37, dacostadarwin at gmail.com wrote: > >> Dear PDWG, >> >> We have received a new draft policy proposal - Require newly created AS-SETs to have hierarchical names, ID AFPUB-2026-ASN-001-DRAFT01 from author James Bensley. >> >> The proposal contents are published at: >> https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft01 >> >> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >> >> a) Do you support or oppose the proposal? >> >> b) If you oppose the proposal, state your reasons? >> >> c) Is there anything in the proposal that is not clear? >> >> d) What changes could be made to this proposal to make it more effective? >> >> Regards, >> Vincent Ngundi & Darwin Da Costa >> AFRINIC PDWG Co-Chairs >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > [CompanySignature] > Inter..link GmbH | Boxhagener Stra?e 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello at inter.link | Web: inter.link From dacostadarwin at gmail.com Thu May 28 08:07:31 2026 From: dacostadarwin at gmail.com (Darwin Da Costa) Date: Thu, 28 May 2026 10:07:31 +0200 Subject: [rpd] AFRINIC Policy Compliance Dashboard ID AFPUB-2026-GEN-002-DRAFT01. Message-ID: Dear PDWG, We have received a new draft policy proposal - AFRINIC Policy Compliance Dashboard ID AFPUB-2026-GEN-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: https://afrinic.net/afpub-2026-gen-002-draft01 We encourage you to take some time to go through the proposal contents and provide feedback as follows: a) Do you support or oppose the proposal? b) If you oppose the proposal, state your reasons? c) Is there anything in the proposal that is not clear? d) What changes could be made to this proposal to make it more effective? Regards, Vincent Ngundi & Darwin Da Costa AFRINIC PDWG Co-Chairs From gbemiadepojuesho at gmail.com Thu May 28 08:22:45 2026 From: gbemiadepojuesho at gmail.com (Gbemisola Esho) Date: Thu, 28 May 2026 09:22:45 +0100 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> References: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> Message-ID: Acknowledged with thanks Regards, Gbemisola Esho On Thu, 28 May 2026, 09:08 Darwin Da Costa, wrote: > Dear PDWG, > > > We have received a new draft policy proposal - IPv6 as a criteria in IPv4 > Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. > The proposal contents are published at: > > > https://afrinic.net/afpub-2026-v6-001-draft01 > > > > We encourage you to take some time to go through the proposal contents and > provide feedback as follows: > > > a)Do you support or oppose the proposal? > > > b) If you oppose the proposal, state your reasons? > > > c) Is there anything in the proposal that is not clear? > > > d) What changes could be made to this proposal to make it more effective? > > > > Regards, > > Vincent Ngundi & Darwin Da Costa > > AFRINIC PDWG Co-Chairs > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu May 28 08:28:26 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Thu, 28 May 2026 10:28:26 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> References: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> Message-ID: <75E8A336-B72B-4AE6-8EB0-CC25C75AE878@consulintel.es> Hi all, Somehow this is a response to Sami input on a previous proposal. This way we can split the problem space in 2 proposals, which may reach consensus without depending one on the other. So we have a very basic question: If we believe that the members that receive IPv4 out of the Soft Landing policy, must implement IPv6, or not? Regards, Jordi @jordipalet > El 28 may 2026, a las 10:05, Darwin Da Costa escribi?: > > Dear PDWG, > > We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: > > https://afrinic.net/afpub-2026-v6-001-draft01 > > > We encourage you to take some time to go through the proposal contents and provide feedback as follows: > > a)Do you support or oppose the proposal? > > b) If you oppose the proposal, state your reasons? > > c) Is there anything in the proposal that is not clear? > > d) What changes could be made to this proposal to make it more effective? > > > Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jordi.palet at consulintel.es Thu May 28 08:35:02 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Thu, 28 May 2026 10:35:02 +0200 Subject: [rpd] AFRINIC Policy Compliance Dashboard ID AFPUB-2026-GEN-002-DRAFT01. In-Reply-To: References: Message-ID: Hi all, Quick comments: 1) Note that this proposal was submitted many years ago and reached consensus, finally was not ratified because the Board was understanding that according to the impact analysis, it was enchroaching some of their functions. 2) The authors (not just me), don?t believe this is the case. Also the community didn?t understood that was the case, as it reached consensus despite the impact analysis. 3) In any case, the authors decided to do a ?cut-down? version, removing all the aspects that AFRINIC consider as ?encroaching?. 4) Another comment I?ve is that in my opinion, this proposal should have kept the original ID. According to 3.4.1 of the CPM: ?A draft policy expires after one calendar year unless it is approved by the AFRINIC Board of Directors as a policy. The timeout period is restarted when the draft policy is replaced by a more recent version of the proposal. ? So even if it expired due to the no-ratifications, which is debatable because we ?paused? all the timing for all the proposals during the time of ?no-board?, as we are sending a new version, the timing is restarted, but the ID should be the same. I think this is important to ensure that all the participants in the list and meeting can have a ?unified? view of the proposal and all the versions, compare them, etc., etc. I think point 4 needs some clarification, because we may have discrepancy on how different folks interpret this specific point of the PDP, which is not good. Regards, Jordi @jordipalet > El 28 may 2026, a las 10:07, Darwin Da Costa escribi?: > > Dear PDWG, > > We have received a new draft policy proposal - AFRINIC Policy Compliance Dashboard ID AFPUB-2026-GEN-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: > > https://afrinic.net/afpub-2026-gen-002-draft01 > > > We encourage you to take some time to go through the proposal contents and provide feedback as follows: > > a) Do you support or oppose the proposal? > > b) If you oppose the proposal, state your reasons? > > c) Is there anything in the proposal that is not clear? > > d) What changes could be made to this proposal to make it more effective? > > > Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Thu May 28 09:32:33 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Thu, 28 May 2026 09:32:33 +0000 Subject: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. In-Reply-To: References: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> , Message-ID: <1671C898-3DF8-42B7-A10E-99484C7CDBC5@hevis.co.za> Organisation with network/ISP and separate hosting division Not that uncommon Sent from my mobile device > On 28 May 2026, at 10:14, Jaco Kroon wrote: > > ?Hi James, > >> On 2026/05/28 09:54, James Bensley wrote: >> >> Hi Jaco, >> >> Thank you for the support and your feedback. >> >> I wrote the original proposal. Regarding this comment: >> >> "The only thing that I found weird is that the second element has to be a name, why would "ASnum:ASnum2:AS-name" not be acceptable?" >> >> If you have a use case for that, then that could be added to the proposal. Do you have a use case/requirement for this? I think this usage is very rare, but if you have this use case, please speak up :) > > It's a hierarchy right, so what if I want to refer my customers by their AS numbers? > > Eg, ASyyyy:ASxxxx:AS-set > > It's an arbitrary and in my opinion unneeded restriction which can be removed. The only restriction is that the first component has to be ASnum where you have control over AS num. The rest can be left to the discretion of the ASnum admin surely? > > So just drop bullet three entirely. > >> >> >> Regarding this comment: >> >> "The purpose/function of "3. Other set types such as route sets are excluded." is unclear - everything else speaks specifically to AS-SET so why is this mention required?" >> >> Because route-sets can also support hierarchical names and in the past people have had the thought "well if we're making this change for AS-SETs let's also making it for Route-Sets whilst we're here" - but route-sets are extremely rarely used today and this just adds scope which I think isn't needed. So it was just about trying to stop that scope creep. > > I hear you. > > 7.8 as as whole specifically states "AS-SET" - not "Set Types", and point 1 also makes it clears this refers specifically to AS-SET, which means point 3 can be dropped without changing the intent/meaning of 7.8 as a whole. > > Point 4 also really adds no value, that's an operational issue, not a policy issue. Definitely a valid point and something to be aware but still operational, not policy. > > Exceptions to the policy may need to be permitted on a case by case basis *if and only if* a non-hierarchical AS-SET has been accidentally deleted to allow recreation. IMHO these should require motivation to have them restored from where they can then be edited again as per point 6. > > Kind regards, > Jaco > >> >> With kind regards, >> James Bensley (he/him) >> >> ________________________________________ >> From: Jaco Kroon >> Sent: 21 May 2026 14:06 >> To: dacostadarwin at gmail.com ; rpd at afrinic.net >> Subject: Re: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. >> >> Hi, >> >> Definitely in support. >> >> The only thing that I found weird is that the second element has to be a >> name, why would "ASnum:ASnum2:AS-name" not be acceptable? >> >> The purpose/function of "3. Other set types such as route sets are >> excluded." is unclear - everything else speaks specifically to AS-SET so >> why is this mention required? >> >> Kind regards, >> Jaco >> >>> On 2026/05/20 19:37, dacostadarwin at gmail.com wrote: >>> >>> Dear PDWG, >>> >>> We have received a new draft policy proposal - Require newly created AS-SETs to have hierarchical names, ID AFPUB-2026-ASN-001-DRAFT01 from author James Bensley. >>> >>> The proposal contents are published at: >>> https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft01 >>> >>> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>> >>> a) Do you support or oppose the proposal? >>> >>> b) If you oppose the proposal, state your reasons? >>> >>> c) Is there anything in the proposal that is not clear? >>> >>> d) What changes could be made to this proposal to make it more effective? >>> >>> Regards, >>> Vincent Ngundi & Darwin Da Costa >>> AFRINIC PDWG Co-Chairs >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> [CompanySignature] >> Inter..link GmbH | Boxhagener Stra?e 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello at inter.link | Web: inter.link > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd --- Hendrik Visage hvisage at hevis.co.za HeViS.Co Systems Pty Ltd https://www.envisage.co.za From jaco at uls.co.za Thu May 28 09:43:14 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Thu, 28 May 2026 11:43:14 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: <75E8A336-B72B-4AE6-8EB0-CC25C75AE878@consulintel.es> References: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> <75E8A336-B72B-4AE6-8EB0-CC25C75AE878@consulintel.es> Message-ID: Hi Jordi, I support the principle very much.? Practicality may be a different story, yes, must implement v6, however: How do you determine/measure that?? I think your "In addition" section addresses this to a degree. Merely advertising IPv6 space?? Sure, that's easy, but it doesn't mean I have to actually make that available to customers. Re proposed text, the word "However, " doesn't add value, merely "Any IPv4 request must be done with a simultaneous IPv6 request if the requesting party does not already have IPv6 space." This does also be the question, it seems 6.5.1.1.3 states that you must give /48s to end sites - we do distinguish between business and home users, for business we happily do /48 if so required (at least we reserve a /48 per site minimum), but for home users we generally do dynamically allocated /56 (but will again do /48 on request) - would this imply failure to comply with your proposed policy?? If so, should the proposed policy be adjusted, or 6.5.1.1.3? For PI space (6.8.2.2.d) - what does deployed mean? Kind regards, Jaco Kroon On 2026/05/28 10:28, jordi.palet--- via RPD wrote: > Hi all, > > Somehow this is a response to Sami input on a previous proposal. > > This way we can split the problem space in 2 proposals, which may reach consensus without depending one on the other. > > So we have a very basic question: If we believe that the members that receive IPv4 out of the Soft Landing policy, must implement IPv6, or not? > > Regards, > Jordi > > @jordipalet > > >> El 28 may 2026, a las 10:05, Darwin Da Costa escribi?: >> >> Dear PDWG, >> >> We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >> >> https://afrinic.net/afpub-2026-v6-001-draft01 >> >> >> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >> >> a)Do you support or oppose the proposal? >> >> b) If you oppose the proposal, state your reasons? >> >> c) Is there anything in the proposal that is not clear? >> >> d) What changes could be made to this proposal to make it more effective? >> >> >> Regards, >> Vincent Ngundi & Darwin Da Costa >> AFRINIC PDWG Co-Chairs >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu May 28 10:21:52 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Thu, 28 May 2026 12:21:52 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> <75E8A336-B72B-4AE6-8EB0-CC25C75AE878@consulintel.es> Message-ID: Hi Jaco, Tks, next version will use: ?Any IPv4 request must be done with a simultaneous IPv6 request if the requesting party does not already have IPv6 space.? This may depend on the impact analysis inputs, of course. About the determination/measurement that this is being done, let me explain how I see this. The existing 6.5.1.1 (for LIRs) and 6.8.2, already set the conditions to be met. AFRINIC already has, in both cases, a 12 months period to confirm the deployment. May be is not sufficiently clear there if AFRINIC should do something if that?s not actually done. We aren?t talking there only about announcing the prefix, but also in the case of LIRs, about making assignments to end-sites, and the text is clear, /48s, nothing different. There is no reason for using different sizes for different type of customers on that text. There is no technical reason at all for not doing it correctly, however, this is a discussion for amending that part of the policy, not for this proposal. What this proposal wants to make sure is that you *actually*, *following existing policy*, if you get IPv4, you really deploy IPv6 in 12 months. To reinforce it I explicitly mention ?In addition ??, as you said. Note that ?in addition? section enforces a more detailed work from the member requesting IPv4, to justify a credible IPv6 addressing and deployment plan, this will be accepted or not by AFRINIC, as with any request evaluation. For example, in many RIRs, not just AFRINIC, I?ve observed that many members get by default a /32, even if they have 800.000 end-sites. Clearly wrong, they didn?t have done any real addressing plan and they will end up providing a single /64 to each end-site. If they do it correctly, they will soon discover why they should use /48s, so with a /32 they can only cover around 50.000 customers, which means that typically for 800.000 of customers (depending on the topological distribution of the network) will mean that they need a /27-/28. I don?t think nobody can say ?deploy? is not clear. If this is the case, we can improve it, something like ?and IPv6 is actually being used?. We can even set a minimum level of traffic, such as 50% for example? Those that have deployed IPv6 know that, at least in the case of residential and cellular customers, because most of the traffic (typically 75-90%) is from big CDNs, caches, and contend providers (all google, all Meta, Akamai and all the other CDNs), already provide IPv6, when you turn on IPv6 in an end-site, the IPv6 traffic of that end-site becomes 75%-90% IPv6, in turn the total ISP traffic reaches similar levels. So asking for 50% seems to me conservative, but I?m happy for lower levels, if we agree that we can ask for more later on. We can even consider something like 25% after 12 months, 50% after 24 months, 75% after 48 months. Just an example. Finally, as we have many policies that AFRINIC not necessarily is measuring the compliance, that?s what the other proposal (compliance dashboard) was already trying to resolve, now in a ?light? version. This proposal also added a trigger (failure to comply) to ensure that abuse (requesting IPv4, but then not deploying IPv6) can enact the RSA terms, because clearly shows that there is a policy breach. By the way, dynamic prefixes in IPv6 is broken, terrible idea, specially if there are power outages. I suggest to read what, hopefully in a few months, will become in RFC/BCP a successor of RIPE690: https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/ Regards, Jordi @jordipalet > El 28 may 2026, a las 11:43, Jaco Kroon escribi?: > > Hi Jordi, > > I support the principle very much. Practicality may be a different story, yes, must implement v6, however: > > How do you determine/measure that? I think your "In addition" section addresses this to a degree. > > Merely advertising IPv6 space? Sure, that's easy, but it doesn't mean I have to actually make that available to customers. > > Re proposed text, the word "However, " doesn't add value, merely "Any IPv4 request must be done with a simultaneous IPv6 request if the requesting party does not already have IPv6 space." > > This does also be the question, it seems 6.5.1.1.3 states that you must give /48s to end sites - we do distinguish between business and home users, for business we happily do /48 if so required (at least we reserve a /48 per site minimum), but for home users we generally do dynamically allocated /56 (but will again do /48 on request) - would this imply failure to comply with your proposed policy? If so, should the proposed policy be adjusted, or 6.5.1.1.3? > > For PI space (6.8.2.2.d) - what does deployed mean? > > Kind regards, > Jaco Kroon > > On 2026/05/28 10:28, jordi.palet--- via RPD wrote: > >> Hi all, >> >> Somehow this is a response to Sami input on a previous proposal. >> >> This way we can split the problem space in 2 proposals, which may reach consensus without depending one on the other. >> >> So we have a very basic question: If we believe that the members that receive IPv4 out of the Soft Landing policy, must implement IPv6, or not? >> >> Regards, >> Jordi >> >> @jordipalet >> >> >>> El 28 may 2026, a las 10:05, Darwin Da Costa escribi?: >>> >>> Dear PDWG, >>> >>> We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>> >>> https://afrinic.net/afpub-2026-v6-001-draft01 >>> >>> >>> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>> >>> a)Do you support or oppose the proposal? >>> >>> b) If you oppose the proposal, state your reasons? >>> >>> c) Is there anything in the proposal that is not clear? >>> >>> d) What changes could be made to this proposal to make it more effective? >>> >>> >>> Regards, >>> Vincent Ngundi & Darwin Da Costa >>> AFRINIC PDWG Co-Chairs >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sami.salih at outlook.com Thu May 28 10:27:04 2026 From: sami.salih at outlook.com (Sami Salih) Date: Thu, 28 May 2026 10:27:04 +0000 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> <75E8A336-B72B-4AE6-8EB0-CC25C75AE878@consulintel.es> Message-ID: Hi Jordi, colleagues, Thank you, Jordi, for considering my previous comments and for restructuring this into a more focused proposal. In principle, I support linking IPv4 allocations under the Soft Landing policy with commitment toward IPv6 deployment. Given the IPv4 exhaustion reality, this is a reasonable policy direction. I also appreciate the additional clarifications regarding the existing policy references and deployment expectations. Nevertheless, I believe the implementation and enforcement aspects may still require further refinement to ensure the criteria remain objective, measurable, and operationally practical across the AFRINIC service region. I believe the staff analysis may further help clarify the operational feasibility, compliance verification approach, and enforcement practicality of the proposed requirements. Overall, I support the intent of the proposal and appreciate the more granular approach to the discussion. With Regards, Sami Salih. Sami Salih ________________________________ From: jordi.palet--- via RPD Sent: Thursday, May 28, 2026 1:21:52 PM To: rpd at afrinic.net Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. Hi Jaco, Tks, next version will use: ?Any IPv4 request must be done with a simultaneous IPv6 request if the requesting party does not already have IPv6 space.? This may depend on the impact analysis inputs, of course. About the determination/measurement that this is being done, let me explain how I see this. The existing 6.5.1.1 (for LIRs) and 6.8.2, already set the conditions to be met. AFRINIC already has, in both cases, a 12 months period to confirm the deployment. May be is not sufficiently clear there if AFRINIC should do something if that?s not actually done. We aren?t talking there only about announcing the prefix, but also in the case of LIRs, about making assignments to end-sites, and the text is clear, /48s, nothing different. There is no reason for using different sizes for different type of customers on that text. There is no technical reason at all for not doing it correctly, however, this is a discussion for amending that part of the policy, not for this proposal. What this proposal wants to make sure is that you *actually*, *following existing policy*, if you get IPv4, you really deploy IPv6 in 12 months. To reinforce it I explicitly mention ?In addition ??, as you said. Note that ?in addition? section enforces a more detailed work from the member requesting IPv4, to justify a credible IPv6 addressing and deployment plan, this will be accepted or not by AFRINIC, as with any request evaluation. For example, in many RIRs, not just AFRINIC, I?ve observed that many members get by default a /32, even if they have 800.000 end-sites. Clearly wrong, they didn?t have done any real addressing plan and they will end up providing a single /64 to each end-site. If they do it correctly, they will soon discover why they should use /48s, so with a /32 they can only cover around 50.000 customers, which means that typically for 800.000 of customers (depending on the topological distribution of the network) will mean that they need a /27-/28. I don?t think nobody can say ?deploy? is not clear. If this is the case, we can improve it, something like ?and IPv6 is actually being used?. We can even set a minimum level of traffic, such as 50% for example? Those that have deployed IPv6 know that, at least in the case of residential and cellular customers, because most of the traffic (typically 75-90%) is from big CDNs, caches, and contend providers (all google, all Meta, Akamai and all the other CDNs), already provide IPv6, when you turn on IPv6 in an end-site, the IPv6 traffic of that end-site becomes 75%-90% IPv6, in turn the total ISP traffic reaches similar levels. So asking for 50% seems to me conservative, but I?m happy for lower levels, if we agree that we can ask for more later on. We can even consider something like 25% after 12 months, 50% after 24 months, 75% after 48 months. Just an example. Finally, as we have many policies that AFRINIC not necessarily is measuring the compliance, that?s what the other proposal (compliance dashboard) was already trying to resolve, now in a ?light? version. This proposal also added a trigger (failure to comply) to ensure that abuse (requesting IPv4, but then not deploying IPv6) can enact the RSA terms, because clearly shows that there is a policy breach. By the way, dynamic prefixes in IPv6 is broken, terrible idea, specially if there are power outages. I suggest to read what, hopefully in a few months, will become in RFC/BCP a successor of RIPE690: https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/ Regards, Jordi @jordipalet El 28 may 2026, a las 11:43, Jaco Kroon escribi?: Hi Jordi, I support the principle very much. Practicality may be a different story, yes, must implement v6, however: How do you determine/measure that? I think your "In addition" section addresses this to a degree. Merely advertising IPv6 space? Sure, that's easy, but it doesn't mean I have to actually make that available to customers. Re proposed text, the word "However, " doesn't add value, merely "Any IPv4 request must be done with a simultaneous IPv6 request if the requesting party does not already have IPv6 space." This does also be the question, it seems 6.5.1.1.3 states that you must give /48s to end sites - we do distinguish between business and home users, for business we happily do /48 if so required (at least we reserve a /48 per site minimum), but for home users we generally do dynamically allocated /56 (but will again do /48 on request) - would this imply failure to comply with your proposed policy? If so, should the proposed policy be adjusted, or 6.5.1.1.3? For PI space (6.8.2.2.d) - what does deployed mean? Kind regards, Jaco Kroon On 2026/05/28 10:28, jordi.palet--- via RPD wrote: Hi all, Somehow this is a response to Sami input on a previous proposal. This way we can split the problem space in 2 proposals, which may reach consensus without depending one on the other. So we have a very basic question: If we believe that the members that receive IPv4 out of the Soft Landing policy, must implement IPv6, or not? Regards, Jordi @jordipalet El 28 may 2026, a las 10:05, Darwin Da Costa escribi?: Dear PDWG, We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: https://afrinic.net/afpub-2026-v6-001-draft01 We encourage you to take some time to go through the proposal contents and provide feedback as follows: a)Do you support or oppose the proposal? b) If you oppose the proposal, state your reasons? c) Is there anything in the proposal that is not clear? d) What changes could be made to this proposal to make it more effective? Regards, Vincent Ngundi & Darwin Da Costa AFRINIC PDWG Co-Chairs _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu May 28 10:41:17 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Thu, 28 May 2026 12:41:17 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> <75E8A336-B72B-4AE6-8EB0-CC25C75AE878@consulintel.es> Message-ID: <4D16AF5A-61D9-4263-8A36-A62E4A7E937C@consulintel.es> Tks Sami, Of course, the impact analysis is key, staff may see issues that we are unable to see, such as (specialy) implementation timing, etc. Do you think % of traffic is not a sufficiently good and objetive measure? Note that the % of traffic, we need to find how to word it out, can be accommodated to the actual deployment plans. So if you can only deploy, for example, 50% of your customers in the 1st year, instead of reaching the 25% of IPv6 traffic, you will be fine reaching 12,5%. The point here is to show the progress on your deployment. I only can see one case where this can?t be met. Let?s suppose an ISP (or end-site) that don?t have residential users, but only some kind of business that are only reaching (mainly) IPv4-only web sites, and this is beyond their control. This can be part of the justification of the IPv6 deployment plan, showing that your traffic patterns (easy to provide stats of your today top destinations) can?t reach the IPv6 required levels. In that case the AFRINIC evaluation will be able to verify that (of course, those destinations typically will grow up in terms of IPv6 traffic, so you may be able to do it even better than in the deployment plan). Regards, Jordi @jordipalet > El 28 may 2026, a las 12:27, Sami Salih escribi?: > > Hi Jordi, colleagues, > > Thank you, Jordi, for considering my previous comments and for restructuring this into a more focused proposal. > > In principle, I support linking IPv4 allocations under the Soft Landing policy with commitment toward IPv6 deployment. Given the IPv4 exhaustion reality, this is a reasonable policy direction. > > I also appreciate the additional clarifications regarding the existing policy references and deployment expectations. Nevertheless, I believe the implementation and enforcement aspects may still require further refinement to ensure the criteria remain objective, measurable, and operationally practical across the AFRINIC service region. I believe the staff analysis may further help clarify the operational feasibility, compliance verification approach, and enforcement practicality of the proposed requirements. > > Overall, I support the intent of the proposal and appreciate the more granular approach to the discussion. > > With Regards, > Sami Salih. > > > Sami Salih > From: jordi.palet--- via RPD > Sent: Thursday, May 28, 2026 1:21:52 PM > To: rpd at afrinic.net > Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. > > Hi Jaco, > > Tks, next version will use: ?Any IPv4 request must be done with a simultaneous IPv6 request if the requesting party does not already have IPv6 space.? This may depend on the impact analysis inputs, of course. > > About the determination/measurement that this is being done, let me explain how I see this. > > The existing 6.5.1.1 (for LIRs) and 6.8.2, already set the conditions to be met. AFRINIC already has, in both cases, a 12 months period to confirm the deployment. May be is not sufficiently clear there if AFRINIC should do something if that?s not actually done. We aren?t talking there only about announcing the prefix, but also in the case of LIRs, about making assignments to end-sites, and the text is clear, /48s, nothing different. There is no reason for using different sizes for different type of customers on that text. There is no technical reason at all for not doing it correctly, however, this is a discussion for amending that part of the policy, not for this proposal. > > What this proposal wants to make sure is that you *actually*, *following existing policy*, if you get IPv4, you really deploy IPv6 in 12 months. To reinforce it I explicitly mention ?In addition ??, as you said. Note that ?in addition? section enforces a more detailed work from the member requesting IPv4, to justify a credible IPv6 addressing and deployment plan, this will be accepted or not by AFRINIC, as with any request evaluation. > > For example, in many RIRs, not just AFRINIC, I?ve observed that many members get by default a /32, even if they have 800.000 end-sites. Clearly wrong, they didn?t have done any real addressing plan and they will end up providing a single /64 to each end-site. If they do it correctly, they will soon discover why they should use /48s, so with a /32 they can only cover around 50.000 customers, which means that typically for 800.000 of customers (depending on the topological distribution of the network) will mean that they need a /27-/28. > > I don?t think nobody can say ?deploy? is not clear. If this is the case, we can improve it, something like ?and IPv6 is actually being used?. We can even set a minimum level of traffic, such as 50% for example? Those that have deployed IPv6 know that, at least in the case of residential and cellular customers, because most of the traffic (typically 75-90%) is from big CDNs, caches, and contend providers (all google, all Meta, Akamai and all the other CDNs), already provide IPv6, when you turn on IPv6 in an end-site, the IPv6 traffic of that end-site becomes 75%-90% IPv6, in turn the total ISP traffic reaches similar levels. > > So asking for 50% seems to me conservative, but I?m happy for lower levels, if we agree that we can ask for more later on. We can even consider something like 25% after 12 months, 50% after 24 months, 75% after 48 months. Just an example. > > Finally, as we have many policies that AFRINIC not necessarily is measuring the compliance, that?s what the other proposal (compliance dashboard) was already trying to resolve, now in a ?light? version. > > This proposal also added a trigger (failure to comply) to ensure that abuse (requesting IPv4, but then not deploying IPv6) can enact the RSA terms, because clearly shows that there is a policy breach. > > By the way, dynamic prefixes in IPv6 is broken, terrible idea, specially if there are power outages. > > I suggest to read what, hopefully in a few months, will become in RFC/BCP a successor of RIPE690: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/ > > Regards, > Jordi > > @jordipalet > > >> El 28 may 2026, a las 11:43, Jaco Kroon escribi?: >> >> Hi Jordi, >> >> I support the principle very much. Practicality may be a different story, yes, must implement v6, however: >> >> How do you determine/measure that? I think your "In addition" section addresses this to a degree. >> >> Merely advertising IPv6 space? Sure, that's easy, but it doesn't mean I have to actually make that available to customers. >> >> Re proposed text, the word "However, " doesn't add value, merely "Any IPv4 request must be done with a simultaneous IPv6 request if the requesting party does not already have IPv6 space." >> >> This does also be the question, it seems 6.5.1.1.3 states that you must give /48s to end sites - we do distinguish between business and home users, for business we happily do /48 if so required (at least we reserve a /48 per site minimum), but for home users we generally do dynamically allocated /56 (but will again do /48 on request) - would this imply failure to comply with your proposed policy? If so, should the proposed policy be adjusted, or 6.5.1.1.3? >> >> For PI space (6.8.2.2.d) - what does deployed mean? >> >> Kind regards, >> Jaco Kroon >> >> On 2026/05/28 10:28, jordi.palet--- via RPD wrote: >> >>> Hi all, >>> >>> Somehow this is a response to Sami input on a previous proposal. >>> >>> This way we can split the problem space in 2 proposals, which may reach consensus without depending one on the other. >>> >>> So we have a very basic question: If we believe that the members that receive IPv4 out of the Soft Landing policy, must implement IPv6, or not? >>> >>> Regards, >>> Jordi >>> >>> @jordipalet >>> >>> >>>> El 28 may 2026, a las 10:05, Darwin Da Costa escribi?: >>>> >>>> Dear PDWG, >>>> >>>> We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>>> >>>> https://afrinic.net/afpub-2026-v6-001-draft01 >>>> >>>> >>>> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>>> >>>> a)Do you support or oppose the proposal? >>>> >>>> b) If you oppose the proposal, state your reasons? >>>> >>>> c) Is there anything in the proposal that is not clear? >>>> >>>> d) What changes could be made to this proposal to make it more effective? >>>> >>>> >>>> Regards, >>>> Vincent Ngundi & Darwin Da Costa >>>> AFRINIC PDWG Co-Chairs >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>> ********************************************** >>> IPv4 is over >>> Are you ready for the new Internet ? >>> http://www.theipv6company.com >>> The IPv6 Company >>> >>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >>> >>> >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From saul at enetworks.co.za Thu May 28 10:56:28 2026 From: saul at enetworks.co.za (Saul Stein) Date: Thu, 28 May 2026 10:56:28 +0000 Subject: [rpd] RPD Digest, Vol 220, Issue 41 In-Reply-To: References: Message-ID: Theresa, >Conduct rules have been twisted to protect insiders and exclude criticism. You are quite right they are to protect members of this list against abuse and since we are not here to criticise anyone, that is exactly what we are trying to prevent. People need to treat others with respect and dignity. The only protection is just that ? people. You are welcome to factually disagree and propose something better, but not criticize people, their words or their ideas. From: Theresa Dukumor Sent: Wednesday, 27 May 2026 15:53 To: rpd at afrinic.net Subject: Re: [rpd] RPD Digest, Vol 220, Issue 41 Hi Andrew, I see the value, but I'm cautious. Conduct rules have been twisted to protect insiders and exclude criticism. Adding a conduct code could make things worse. We should limit it to clear harm like harassment and spam, not vague tone complaints. The IETF model only works because of its open culture. Let's not copy the form without the substance. Will need to see the draft and the oversight plan before I can support it. Regards, Theresa On Wed, May 27, 2026 at 11:49?AM > wrote: Send RPD mailing list submissions to rpd at afrinic.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.afrinic.net/mailman/listinfo/rpd or, via email, send a message with subject or body 'help' to rpd-request at afrinic.net You can reach the person managing the list at rpd-owner at afrinic.net When replying, please edit your Subject line so it is more specific than "Re: Contents of RPD digest..." Today's Topics: 1. Re: Gauging Interest in a possible policy change (jordi.palet at consulintel.es) 2. Re: Gauging Interest in a possible policy change (Dewole Ajao [AFRINIC]) 3. Re: Gauging Interest in a possible policy change (Benson Muite) 4. Re: Gauging Interest in a possible policy change (Seun Ojedeji) ---------------------------------------------------------------------- Message: 1 Date: Wed, 27 May 2026 08:49:24 +0200 From: "jordi.palet at consulintel.es" > To: RPD > Subject: Re: [rpd] Gauging Interest in a possible policy change Message-ID: <69DABC60-221A-4223-90BB-C114E3C46BE2 at consulintel.es> Content-Type: text/plain; charset="utf-8" Hi Andrew, A few years ago, in LACNIC we had similar issues with behaviours against the spirit of the equivalent list to this one. As I was IETF sergeant at arms for the IETF mailing list, and also participate in many other exploders that have AUPs (Acceptable Usage Policy), I used my experience to design a proposal for LACNIC, you can see the last version here: https://politicas.lacnic.net/politicas/detail/id/LAC-2018-13/language/en It took a long time to discuss the proposal, and when it was almost reaching consensus (in my opinion), LACNIC decided to make a CoC which somehow superseddes the AUP. Nevertheless, I still have encountered feelings if an AUP may be also needed in parallel to the CoC, as the CoC is quite generic while the AUP can provide a ore clear path to co-chairs. So if you reach the conclusion that this is good to have, I?m happy to work with you/others in that, or feel free to use that proposal as a starting point that was discussed during 3 years in a very similar context. Regards, Jordi @jordipalet > El 27 may 2026, a las 7:53, Andrew Alston > escribi?: > > Hi Guys, > > I've been giving this a lot of thought and want to gauge interest in adding a policy relating to the code of conduct. > > Effectively, what I foresee is language added to the policy which acts similar to the IETF Notewell, and specifies appropriate/inappropriate conduct both on the PDP List and during PDP meetings. > > Ideally speaking this will also include enforcement actions for the code of conduct, appeal procedures etc. > > Within the IETF framework for example, disruptive behavior can result in the temporary or permanent loss of posting rights to the list, and such enforcement actions are subject to a robust appeal mechanism. > > Before I start drafting however, I'd like to hear the PDP's thoughts on whether this is worth doing. > > Thanks > > Andrew > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: > ------------------------------ Message: 2 Date: Wed, 27 May 2026 08:00:58 +0100 From: "Dewole Ajao [AFRINIC]" > To: Andrew Alston > Cc: RPD > Subject: Re: [rpd] Gauging Interest in a possible policy change Message-ID: > Content-Type: text/plain; charset=us-ascii Thanks, Andrew. While I am not currently making any comments on the subject matter at this point, I would like to commend the approach of coming to the list to check for interest in working together to solve what you believe may be a problem that needs to be solved. By getting to a wider understanding of whether or not there is a problem to be solved (and possibly the root causes), before policy text is proposed, the working group will be more efficient in its deliberations and even the first draft (if it ever gets to draft stages) will be more robust because it would ideally carry inputs from the discussions within the working group (even if members choose not to join as authors). This has been suggested to policy proposal authors over the years and I hope we can do more of this type of engagement in our policy development. With warm regards, Dewole. > On 27 May 2026, at 06:53, Andrew Alston > wrote: > > Hi Guys, > > I've been giving this a lot of thought and want to gauge interest in adding a policy relating to the code of conduct. > > Effectively, what I foresee is language added to the policy which acts similar to the IETF Notewell, and specifies appropriate/inappropriate conduct both on the PDP List and during PDP meetings. > > Ideally speaking this will also include enforcement actions for the code of conduct, appeal procedures etc. > > Within the IETF framework for example, disruptive behavior can result in the temporary or permanent loss of posting rights to the list, and such enforcement actions are subject to a robust appeal mechanism. > > Before I start drafting however, I'd like to hear the PDP's thoughts on whether this is worth doing. > > Thanks > > Andrew > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ Message: 3 Date: Wed, 27 May 2026 10:35:17 +0300 From: Benson Muite > To: Andrew Alston >, RPD > Subject: Re: [rpd] Gauging Interest in a possible policy change Message-ID: <87jysp2tl6.fsf at emailplus.org> Content-Type: text/plain Andrew Alston > writes: Hi, (Will avoid gendered pronouns in case anyone feels left out)! > Hi Guys, > > I've been giving this a lot of thought and want to gauge interest in adding > a policy relating to the code of conduct. > > Effectively, what I foresee is language added to the policy which acts > similar to the IETF Notewell, and specifies appropriate/inappropriate > conduct both on the PDP List and during PDP meetings. This would probably be helpful. The IETF has much more transparency than AFRINIC. It is not structured as a private company so legal requirements for transparency in decision making, and in use of funds are stricter. Every other RIR is structured as an non-profit public benefit non governmental organization. Within the IETF, there are structures to get input from outside the IETF for some decisions, for example from ISOC a broader community of internet stakeholders. A code of conduct could help streamline useful input but should not not prevent dissenting voices from being heard - this can be difficult in large communities with diverse backgrounds. When there is disruptive behavior in the IETF, one can ask for further details and decide on whether a warranted point is being made - some of the post quantum standards are at least worthy of further individual investigation. IETF processes have originated from a specific culture, they are generally good, but could still be improved in terms of getting dissenting voices heard. Not all elements may work well for AFRINIC, but the experience is something that AFRINIC could learn from and use to improve. > > Ideally speaking this will also include enforcement actions for the code of > conduct, appeal procedures etc. > Codes of conduct are often not drafted by people with any legal background so are often guidelines for desired behavior and can be difficult to enforce in some jurisdictions as they maybe in conflict with local laws. Codes of conduct are easier to change than by-laws and as changes would probably be needed, having this would be better than putting it in the by-laws until they stabilise. > Within the IETF framework for example, disruptive behavior can result in > the temporary or permanent loss of posting rights to the list, and such > enforcement actions are subject to a robust appeal mechanism. > > Before I start drafting however, I'd like to hear the PDP's thoughts on > whether this is worth doing. > In my personal opinion this would be helpful, though my opinion is that AFRINIC also needs broader restructuring and if such a restructuring were to occur, how much would be carried over? Benson > Thanks > > Andrew ------------------------------ Message: 4 Date: Wed, 27 May 2026 05:48:51 -0500 From: Seun Ojedeji > To: Andrew Alston > Cc: RPD > Subject: Re: [rpd] Gauging Interest in a possible policy change Message-ID: > Content-Type: text/plain; charset="utf-8" Hi Andrew, AFRINIC does have an existing code of conduct[1] whether it is sufficient in present realities is a different thing. I do not believe the rpd need to have a different CoC but I think it may be appropriate for rpd to document the process to follow when AFRINIC CoC is violated. Regards [1] https://afrinic.net/code ---- Sent from my mobile kindly excuse typos On Wed, 27 May 2026, 12:55?am Andrew Alston, > wrote: > Hi Guys, > > I've been giving this a lot of thought and want to gauge interest in > adding a policy relating to the code of conduct. > > Effectively, what I foresee is language added to the policy which acts > similar to the IETF Notewell, and specifies appropriate/inappropriate > conduct both on the PDP List and during PDP meetings. > > Ideally speaking this will also include enforcement actions for the code > of conduct, appeal procedures etc. > > Within the IETF framework for example, disruptive behavior can result in > the temporary or permanent loss of posting rights to the list, and such > enforcement actions are subject to a robust appeal mechanism. > > Before I start drafting however, I'd like to hear the PDP's thoughts on > whether this is worth doing. > > Thanks > > Andrew > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: > ------------------------------ Subject: Digest Footer _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ End of RPD Digest, Vol 220, Issue 41 ************************************ -------------- next part -------------- An HTML attachment was scrubbed... URL: From seun.ojedeji at gmail.com Thu May 28 11:40:20 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Thu, 28 May 2026 06:40:20 -0500 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> References: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> Message-ID: This proposal looks good to me in principle but I'd like to mention that if this is a first v4 request then perhaps V6 deployment plan requirement should not be mandatory. While we need people to deploy V6, we also don't want V4 to run stale in AFRINIC's vault, a balanced depletion rate may be good. I fear this proposal may reduce depletion rate of v4 which I know may not be the intent. I also look forward to reading staff analysis of this proposal especially as it concerns V6 justification implementation Regards ---- Sent from my mobile kindly excuse typos On Thu, 28 May 2026, 3:05?am Darwin Da Costa, wrote: > Dear PDWG, > > > We have received a new draft policy proposal - IPv6 as a criteria in IPv4 > Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. > The proposal contents are published at: > > > https://afrinic.net/afpub-2026-v6-001-draft01 > > > > We encourage you to take some time to go through the proposal contents and > provide feedback as follows: > > > a)Do you support or oppose the proposal? > > > b) If you oppose the proposal, state your reasons? > > > c) Is there anything in the proposal that is not clear? > > > d) What changes could be made to this proposal to make it more effective? > > > > Regards, > > Vincent Ngundi & Darwin Da Costa > > AFRINIC PDWG Co-Chairs > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Thu May 28 11:44:52 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Thu, 28 May 2026 13:44:52 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> Message-ID: <26787741-b549-41e9-a27e-abf062fe6dac@uls.co.za> Hi Seun, I don't think anybody at this point in time should become an Afrinic member if they don't deal with reality:? You need to deploy IPv6. I do agree it shouldn't run stale - but I'd rather see that happening than people don't actively deploy IPv6. Kind regards, Jaco On 2026/05/28 13:40, Seun Ojedeji wrote: > This proposal looks good to me in principle but I'd like to mention > that if this is a first v4 request then perhaps V6 deployment plan > requirement should not be mandatory. > > While we need people to deploy V6, we also don't want V4 to run stale > in AFRINIC's vault, a balanced depletion rate may be good. I fear this > proposal may reduce depletion rate of v4 which I know may not be the > intent. > > I also look forward to reading staff analysis of this proposal > especially as it concerns V6 justification implementation > > Regards > > ---- > Sent from my mobile > kindly excuse typos > > > > On Thu, 28 May 2026, 3:05?am Darwin Da Costa, > wrote: > > Dear PDWG, > > > We have received a new draft policy proposal - IPv6 as a criteria > in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author > Jordi Palet Martinez. The proposal contents are published at: > > > https://afrinic.net/afpub-2026-v6-001-draft01 > > > > We encourage you to take some time to go through the proposal > contents and ?provide feedback as follows: > > > a)Do you support or oppose the proposal? > > > b) If you oppose the proposal, state your reasons? > > > c) Is there anything in the proposal that is not clear? > > > d) What changes could be made to this proposal to make it more > effective? > > > > Regards, > > Vincent Ngundi & Darwin Da Costa > > AFRINIC PDWG Co-Chairs > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at alstonnetworks.net Thu May 28 12:42:14 2026 From: aa at alstonnetworks.net (Andrew Alston) Date: Thu, 28 May 2026 15:42:14 +0300 Subject: [rpd] In Memoriam: Alan Barrett Message-ID: Dear friends and colleagues, As some of you will already be aware, it is with immense sadness that we confirm, on behalf of his wife Kerry and the family, the passing of Alan Barrett. Alan died on May 28th in Cape Town, South Africa, following a diagnosis of late-stage cancer about a month ago. We are sharing this notice so that the community has accurate information at a moment when Kerry and the family need space to grieve. Alan was a friend, a willing listener, and someone who always stepped up to help when called upon. His contributions to the African Internet ecosystem were second to none, and with his passing we lose not only a friend but a giant of the industry. In 1990, Alan helped establish the very first Internet connection to South African universities, and in 1993 he co-founded the country's first commercial Internet Service Provider. In 1997 he co-authored the proposal to create AfriNIC and subsequently served on the steering committee tasked with bringing it into being. Alan served on the AfriNIC board from 2004 to 2009 and was a member of the NRO NC from 2004 to 2014. In 2015 he was appointed CEO of AfriNIC, a role he held until 2019. Beyond Africa, he was a central participant in the IANA Stewardship Transition Coordination Group, and until his death served on the ICANN board on behalf of the Address Supporting Organisation. Alan will be sorely missed by the community, his relatives and his wife, Kerry. Kerry and the family ask for privacy at this time. We will be organising an online memorial in due course and will share details once they are available. Andrew Alston Remco van Mook -------------- next part -------------- An HTML attachment was scrubbed... URL: From seun.ojedeji at gmail.com Thu May 28 13:15:24 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Thu, 28 May 2026 08:15:24 -0500 Subject: [rpd] In Memoriam: Alan Barrett In-Reply-To: References: Message-ID: Very sad news: Africa has lost one of the founding fathers of AFRINIC, a great technocrat and a dear friend of the community. He will be dearly missed, may his soul rest in peace! Regards On Thu, 28 May 2026 at 07:42, Andrew Alston wrote: > Dear friends and colleagues, > > As some of you will already be aware, it is with immense sadness that we > confirm, on behalf of his wife Kerry and the family, the passing of Alan > Barrett. Alan died on May 28th in Cape Town, South Africa, following a > diagnosis of late-stage cancer about a month ago. We are sharing this > notice so that the community has accurate information at a moment when > Kerry and the family need space to grieve. > > Alan was a friend, a willing listener, and someone who always stepped up > to help when called upon. His contributions to the African Internet > ecosystem were second to none, and with his passing we lose not only a > friend but a giant of the industry. > > In 1990, Alan helped establish the very first Internet connection to South > African universities, and in 1993 he co-founded the country's first > commercial Internet Service Provider. In 1997 he co-authored the proposal > to create AfriNIC and subsequently served on the steering committee tasked > with bringing it into being. Alan served on the AfriNIC board from 2004 to > 2009 and was a member of the NRO NC from 2004 to 2014. In 2015 he was > appointed CEO of AfriNIC, a role he held until 2019. > > Beyond Africa, he was a central participant in the IANA Stewardship > Transition Coordination Group, and until his death served on the ICANN > board on behalf of the Address Supporting Organisation. > > Alan will be sorely missed by the community, his relatives and his wife, > Kerry. > > Kerry and the family ask for privacy at this time. We will be organising > an online memorial in due course and will share details once they are > available. > > Andrew Alston > Remco van Mook > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -- ------------------------------------------------------------------------ *Seun Ojedeji,* Bringing another down does not take you up - think about your action! -------------- next part -------------- An HTML attachment was scrubbed... URL: From theresadukumor at gmail.com Thu May 28 13:24:00 2026 From: theresadukumor at gmail.com (Theresa Dukumor) Date: Thu, 28 May 2026 14:24:00 +0100 Subject: [rpd] Promoting IPv6 adoption In-Reply-To: References: Message-ID: Dear PDWG, While I appreciate the goal of promoting IPv6 adoption, I have concerns about making it a condition for IPv4 allocations under Soft Landing. IPv4 is still the operating foundation for many in this region. Adding a mandate compounds cost and complexity without proven benefit, turning a resource policy into a migration mandate. The cost and pressure would fall on ordinary operators, while the main winners are likely registry governance bodies and large equipment vendors. I ask the PDWG to examine these consequences carefully. Regards, Theresa On Thu, May 28, 2026 at 9:23?AM wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01. (Darwin Da Costa) > 2. Re: Require newly created AS-SETs to have hierarchical names > AFPUB-2026-ASN-001-DRAFT01. (Jaco Kroon) > 3. AFRINIC Policy Compliance Dashboard ID > AFPUB-2026-GEN-002-DRAFT01. (Darwin Da Costa) > 4. Re: IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01. (Gbemisola Esho) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 28 May 2026 10:05:07 +0200 > From: Darwin Da Costa > To: rpd at afrinic.net > Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01. > Message-ID: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18 at gmail.com> > Content-Type: text/plain; charset="us-ascii" > > Dear PDWG, > > We have received a new draft policy proposal - IPv6 as a criteria in IPv4 > Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. > The proposal contents are published at: > > https://afrinic.net/afpub-2026-v6-001-draft01 > > > We encourage you to take some time to go through the proposal contents > and provide feedback as follows: > > a)Do you support or oppose the proposal? > > b) If you oppose the proposal, state your reasons? > > c) Is there anything in the proposal that is not clear? > > d) What changes could be made to this proposal to make it more effective? > > > Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260528/acf245c0/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Thu, 28 May 2026 10:07:01 +0200 > From: Jaco Kroon > To: James Bensley , "dacostadarwin at gmail.com" > , "rpd at afrinic.net" > Subject: Re: [rpd] Require newly created AS-SETs to have hierarchical > names AFPUB-2026-ASN-001-DRAFT01. > Message-ID: > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi James, > > On 2026/05/28 09:54, James Bensley wrote: > > > Hi Jaco, > > > > Thank you for the support and your feedback. > > > > I wrote the original proposal. Regarding this comment: > > > > "The only thing that I found weird is that the second element has to be > a name, why would "ASnum:ASnum2:AS-name" not be acceptable?" > > > > If you have a use case for that, then that could be added to the > proposal. Do you have a use case/requirement for this? I think this usage > is very rare, but if you have this use case, please speak up :) > > It's a hierarchy right, so what if I want to refer my customers by their > AS numbers? > > Eg, ASyyyy:ASxxxx:AS-set > > It's an arbitrary and in my opinion unneeded restriction which can be > removed.? The only restriction is that the first component has to be > ASnum where you have control over AS num.? The rest can be left to the > discretion of the ASnum admin surely? > > So just drop bullet three entirely. > > > > > > > Regarding this comment: > > > > "The purpose/function of "3. Other set types such as route sets are > excluded." is unclear - everything else speaks specifically to AS-SET so > why is this mention required?" > > > > Because route-sets can also support hierarchical names and in the past > people have had the thought "well if we're making this change for AS-SETs > let's also making it for Route-Sets whilst we're here" - but route-sets are > extremely rarely used today and this just adds scope which I think isn't > needed. So it was just about trying to stop that scope creep. > > I hear you. > > 7.8 as as whole specifically states "AS-SET" - not "Set Types", and > point 1 also makes it clears this refers specifically to AS-SET, which > means point 3 can be dropped without changing the intent/meaning of 7.8 > as a whole. > > Point 4 also really adds no value, that's an operational issue, not a > policy issue.? Definitely a valid point and something to be aware but > still operational, not policy. > > Exceptions to the policy may need to be permitted on a case by case > basis *if and only if* a non-hierarchical AS-SET has been accidentally > deleted to allow recreation.? IMHO these should require motivation to > have them restored from where they can then be edited again as per point 6. > > Kind regards, > Jaco > > > > > With kind regards, > > James Bensley (he/him) > > > > ________________________________________ > > From: Jaco Kroon > > Sent: 21 May 2026 14:06 > > To: dacostadarwin at gmail.com ; rpd at afrinic.net < > rpd at afrinic.net> > > Subject: Re: [rpd] Require newly created AS-SETs to have hierarchical > names AFPUB-2026-ASN-001-DRAFT01. > > > > Hi, > > > > Definitely in support. > > > > The only thing that I found weird is that the second element has to be a > > name, why would "ASnum:ASnum2:AS-name" not be acceptable? > > > > The purpose/function of "3. Other set types such as route sets are > > excluded." is unclear - everything else speaks specifically to AS-SET so > > why is this mention required? > > > > Kind regards, > > Jaco > > > > On 2026/05/20 19:37, dacostadarwin at gmail.com wrote: > > > >> Dear PDWG, > >> > >> We have received a new draft policy proposal - Require newly created > AS-SETs to have hierarchical names, ID AFPUB-2026-ASN-001-DRAFT01 from > author James Bensley. > >> > >> The proposal contents are published at: > >> https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft01 > >> > >> We encourage you to take some time to go through the proposal contents > and provide feedback as follows: > >> > >> a) Do you support or oppose the proposal? > >> > >> b) If you oppose the proposal, state your reasons? > >> > >> c) Is there anything in the proposal that is not clear? > >> > >> d) What changes could be made to this proposal to make it more > effective? > >> > >> Regards, > >> Vincent Ngundi & Darwin Da Costa > >> AFRINIC PDWG Co-Chairs > >> > >> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > [CompanySignature] > > Inter..link GmbH | Boxhagener Stra?e 80, 10245 Berlin, Germany | > Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: > Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: > hello at inter.link | Web: inter.link< > https://inter.link> > > > > ------------------------------ > > Message: 3 > Date: Thu, 28 May 2026 10:07:31 +0200 > From: Darwin Da Costa > To: rpd at afrinic.net > Subject: [rpd] AFRINIC Policy Compliance Dashboard ID > AFPUB-2026-GEN-002-DRAFT01. > Message-ID: > Content-Type: text/plain; charset=us-ascii > > Dear PDWG, > > We have received a new draft policy proposal - AFRINIC Policy Compliance > Dashboard ID AFPUB-2026-GEN-002-DRAFT01 from author Jordi Palet Martinez. > The proposal contents are published at: > > https://afrinic.net/afpub-2026-gen-002-draft01 > > > We encourage you to take some time to go through the proposal contents > and provide feedback as follows: > > a) Do you support or oppose the proposal? > > b) If you oppose the proposal, state your reasons? > > c) Is there anything in the proposal that is not clear? > > d) What changes could be made to this proposal to make it more effective? > > > Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs > > > > > ------------------------------ > > Message: 4 > Date: Thu, 28 May 2026 09:22:45 +0100 > From: Gbemisola Esho > To: Darwin Da Costa > Cc: rpd > Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01. > Message-ID: > fisTUzHiU-QXgHL+OxPAA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Acknowledged with thanks > > > Regards, > Gbemisola Esho > > On Thu, 28 May 2026, 09:08 Darwin Da Costa, > wrote: > > > Dear PDWG, > > > > > > We have received a new draft policy proposal - IPv6 as a criteria in IPv4 > > Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet > Martinez. > > The proposal contents are published at: > > > > > > https://afrinic.net/afpub-2026-v6-001-draft01 > > > > > > > > We encourage you to take some time to go through the proposal contents > and > > provide feedback as follows: > > > > > > a)Do you support or oppose the proposal? > > > > > > b) If you oppose the proposal, state your reasons? > > > > > > c) Is there anything in the proposal that is not clear? > > > > > > d) What changes could be made to this proposal to make it more effective? > > > > > > > > Regards, > > > > Vincent Ngundi & Darwin Da Costa > > > > AFRINIC PDWG Co-Chairs > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260528/b0ca3f5a/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 220, Issue 44 > ************************************ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sami.salih at outlook.com Thu May 28 13:46:50 2026 From: sami.salih at outlook.com (Sami Salih) Date: Thu, 28 May 2026 13:46:50 +0000 Subject: [rpd] In Memoriam: Alan Barrett In-Reply-To: References: Message-ID: Dear Friends, I am deeply saddened by Alan?s passing. He was a true pioneer of the African Internet community and a mentor to many of us. I will always remember his guidance and support during my first nomination as AFRINIC PDWG Co-Chair. Please convey my sincere condolences to his family and loved ones. May he rest in peace. Sami Salih. Sami Salih ________________________________ From: Seun Ojedeji Sent: Thursday, May 28, 2026 4:15:24 PM To: Andrew Alston Cc: RPD Subject: Re: [rpd] In Memoriam: Alan Barrett Very sad news: Africa has lost one of the founding fathers of AFRINIC, a great technocrat and a dear friend of the community. He will be dearly missed, may his soul rest in peace! Regards On Thu, 28 May 2026 at 07:42, Andrew Alston > wrote: Dear friends and colleagues, As some of you will already be aware, it is with immense sadness that we confirm, on behalf of his wife Kerry and the family, the passing of Alan Barrett. Alan died on May 28th in Cape Town, South Africa, following a diagnosis of late-stage cancer about a month ago. We are sharing this notice so that the community has accurate information at a moment when Kerry and the family need space to grieve. Alan was a friend, a willing listener, and someone who always stepped up to help when called upon. His contributions to the African Internet ecosystem were second to none, and with his passing we lose not only a friend but a giant of the industry. In 1990, Alan helped establish the very first Internet connection to South African universities, and in 1993 he co-founded the country's first commercial Internet Service Provider. In 1997 he co-authored the proposal to create AfriNIC and subsequently served on the steering committee tasked with bringing it into being. Alan served on the AfriNIC board from 2004 to 2009 and was a member of the NRO NC from 2004 to 2014. In 2015 he was appointed CEO of AfriNIC, a role he held until 2019. Beyond Africa, he was a central participant in the IANA Stewardship Transition Coordination Group, and until his death served on the ICANN board on behalf of the Address Supporting Organisation. Alan will be sorely missed by the community, his relatives and his wife, Kerry. Kerry and the family ask for privacy at this time. We will be organising an online memorial in due course and will share details once they are available. Andrew Alston Remco van Mook _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd -- ------------------------------------------------------------------------ Seun Ojedeji, Bringing another down does not take you up - think about your action! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu May 28 13:52:50 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Thu, 28 May 2026 15:52:50 +0200 Subject: [rpd] Promoting IPv6 adoption In-Reply-To: References: Message-ID: Hi Theresa, I think it needs to be understood that IPv4 is legacy and its main usage must be supporting transition. This has been said already many times, but I think we need to repeat it. It doesn?t make any sense to extend any existing network, or to deploy a new one, with IPv4-only. We are not saying it must be done with IPv6-only. In fact, the way is IPv6-Only with IPv4-as-a-Service, which basically means this is not a migration (we aren?t talking about removing IPv4 completely), it is transition and coexistence (there is no such concept as migration defined by IETF). The Soft Landing policy was designed having this in mind, it is clear reading 5.4 in the CPM, however we didn?t took measures at that time to make it happen. Now is the time. At that time the IPv6 deployment levels were very low globally, but at this time, Africa is overall, the bigger lagging region and no great signs that this is changing quickly. There is not today, any technical or even economical rationale to support IPv4 only. In fact across many deployments where I?ve participated in more than 150 countries, the result is that deploying IPv6 is much cheaper than IPv4 (IPv6 supporting equipment is not more expensive than IPv4, is the same price, and some cost are much lower, such as no need for CGN boxes). The problem is basically a lack of decision by executives, not technical people. We need to accommodate to the pace of each one, but a credible pace, not a pace like ?I get more IPv4, promise IPv6, but I?m lazy and don?t have now the time to do it". I think is fine that we accommodate the text in the new version so each one can say ?I realistically will grow 15% my network in the next year (that?s why I?m asking for IPv4 addresses), and I will do that with IPv6, so I commit to % IPv6 traffic for the 1st year, % next one and so on?. I?m happy to try as much as possible, with all your contributions, to accommodate the text in the next version, in such way that is not like you say having the cost and pressure unbalanced. Regards, Jordi @jordipalet > El 28 may 2026, a las 15:24, Theresa Dukumor escribi?: > > Dear PDWG, > > While I appreciate the goal of promoting IPv6 adoption, I have concerns about making it a condition for IPv4 allocations under Soft Landing. IPv4 is still the operating foundation for many in this region. Adding a mandate compounds cost and complexity without proven benefit, turning a resource policy into a migration mandate. The cost and pressure would fall on ordinary operators, while the main winners are likely registry governance bodies and large equipment vendors. I ask the PDWG to examine these consequences carefully. > > Regards, > Theresa > > > On Thu, May 28, 2026 at 9:23?AM > wrote: >> Send RPD mailing list submissions to >> rpd at afrinic.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.afrinic.net/mailman/listinfo/rpd >> or, via email, send a message with subject or body 'help' to >> rpd-request at afrinic.net >> >> You can reach the person managing the list at >> rpd-owner at afrinic.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of RPD digest..." >> >> >> Today's Topics: >> >> 1. IPv6 as a criteria in IPv4 Soft Landing >> AFPUB-2026-v6-001-DRAFT01. (Darwin Da Costa) >> 2. Re: Require newly created AS-SETs to have hierarchical names >> AFPUB-2026-ASN-001-DRAFT01. (Jaco Kroon) >> 3. AFRINIC Policy Compliance Dashboard ID >> AFPUB-2026-GEN-002-DRAFT01. (Darwin Da Costa) >> 4. Re: IPv6 as a criteria in IPv4 Soft Landing >> AFPUB-2026-v6-001-DRAFT01. (Gbemisola Esho) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Thu, 28 May 2026 10:05:07 +0200 >> From: Darwin Da Costa > >> To: rpd at afrinic.net >> Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing >> AFPUB-2026-v6-001-DRAFT01. >> Message-ID: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18 at gmail.com > >> Content-Type: text/plain; charset="us-ascii" >> >> Dear PDWG, >> >> We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >> >> https://afrinic.net/afpub-2026-v6-001-draft01 >> >> >> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >> >> a)Do you support or oppose the proposal? >> >> b) If you oppose the proposal, state your reasons? >> >> c) Is there anything in the proposal that is not clear? >> >> d) What changes could be made to this proposal to make it more effective? >> >> >> Regards, >> Vincent Ngundi & Darwin Da Costa >> AFRINIC PDWG Co-Chairs >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> ------------------------------ >> >> Message: 2 >> Date: Thu, 28 May 2026 10:07:01 +0200 >> From: Jaco Kroon > >> To: James Bensley , "dacostadarwin at gmail.com " >> >, "rpd at afrinic.net " > >> Subject: Re: [rpd] Require newly created AS-SETs to have hierarchical >> names AFPUB-2026-ASN-001-DRAFT01. >> Message-ID: > >> Content-Type: text/plain; charset=UTF-8; format=flowed >> >> Hi James, >> >> On 2026/05/28 09:54, James Bensley wrote: >> >> > Hi Jaco, >> > >> > Thank you for the support and your feedback. >> > >> > I wrote the original proposal. Regarding this comment: >> > >> > "The only thing that I found weird is that the second element has to be a name, why would "ASnum:ASnum2:AS-name" not be acceptable?" >> > >> > If you have a use case for that, then that could be added to the proposal. Do you have a use case/requirement for this? I think this usage is very rare, but if you have this use case, please speak up :) >> >> It's a hierarchy right, so what if I want to refer my customers by their >> AS numbers? >> >> Eg, ASyyyy:ASxxxx:AS-set >> >> It's an arbitrary and in my opinion unneeded restriction which can be >> removed.? The only restriction is that the first component has to be >> ASnum where you have control over AS num.? The rest can be left to the >> discretion of the ASnum admin surely? >> >> So just drop bullet three entirely. >> >> > >> > >> > Regarding this comment: >> > >> > "The purpose/function of "3. Other set types such as route sets are excluded." is unclear - everything else speaks specifically to AS-SET so why is this mention required?" >> > >> > Because route-sets can also support hierarchical names and in the past people have had the thought "well if we're making this change for AS-SETs let's also making it for Route-Sets whilst we're here" - but route-sets are extremely rarely used today and this just adds scope which I think isn't needed. So it was just about trying to stop that scope creep. >> >> I hear you. >> >> 7.8 as as whole specifically states "AS-SET" - not "Set Types", and >> point 1 also makes it clears this refers specifically to AS-SET, which >> means point 3 can be dropped without changing the intent/meaning of 7.8 >> as a whole. >> >> Point 4 also really adds no value, that's an operational issue, not a >> policy issue.? Definitely a valid point and something to be aware but >> still operational, not policy. >> >> Exceptions to the policy may need to be permitted on a case by case >> basis *if and only if* a non-hierarchical AS-SET has been accidentally >> deleted to allow recreation.? IMHO these should require motivation to >> have them restored from where they can then be edited again as per point 6. >> >> Kind regards, >> Jaco >> >> > >> > With kind regards, >> > James Bensley (he/him) >> > >> > ________________________________________ >> > From: Jaco Kroon > >> > Sent: 21 May 2026 14:06 >> > To: dacostadarwin at gmail.com >; rpd at afrinic.net > >> > Subject: Re: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. >> > >> > Hi, >> > >> > Definitely in support. >> > >> > The only thing that I found weird is that the second element has to be a >> > name, why would "ASnum:ASnum2:AS-name" not be acceptable? >> > >> > The purpose/function of "3. Other set types such as route sets are >> > excluded." is unclear - everything else speaks specifically to AS-SET so >> > why is this mention required? >> > >> > Kind regards, >> > Jaco >> > >> > On 2026/05/20 19:37, dacostadarwin at gmail.com wrote: >> > >> >> Dear PDWG, >> >> >> >> We have received a new draft policy proposal - Require newly created AS-SETs to have hierarchical names, ID AFPUB-2026-ASN-001-DRAFT01 from author James Bensley. >> >> >> >> The proposal contents are published at: >> >> https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft01 >> >> >> >> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >> >> >> >> a) Do you support or oppose the proposal? >> >> >> >> b) If you oppose the proposal, state your reasons? >> >> >> >> c) Is there anything in the proposal that is not clear? >> >> >> >> d) What changes could be made to this proposal to make it more effective? >> >> >> >> Regards, >> >> Vincent Ngundi & Darwin Da Costa >> >> AFRINIC PDWG Co-Chairs >> >> >> >> >> >> _______________________________________________ >> >> RPD mailing list >> >> RPD at afrinic.net >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> > _______________________________________________ >> > RPD mailing list >> > RPD at afrinic.net >> > https://lists.afrinic.net/mailman/listinfo/rpd >> > [CompanySignature] >> > Inter..link GmbH | Boxhagener Stra?e 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello at inter.link> | Web: inter.link> >> >> >> >> ------------------------------ >> >> Message: 3 >> Date: Thu, 28 May 2026 10:07:31 +0200 >> From: Darwin Da Costa > >> To: rpd at afrinic.net >> Subject: [rpd] AFRINIC Policy Compliance Dashboard ID >> AFPUB-2026-GEN-002-DRAFT01. >> Message-ID: > >> Content-Type: text/plain; charset=us-ascii >> >> Dear PDWG, >> >> We have received a new draft policy proposal - AFRINIC Policy Compliance Dashboard ID AFPUB-2026-GEN-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >> >> https://afrinic.net/afpub-2026-gen-002-draft01 >> >> >> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >> >> a) Do you support or oppose the proposal? >> >> b) If you oppose the proposal, state your reasons? >> >> c) Is there anything in the proposal that is not clear? >> >> d) What changes could be made to this proposal to make it more effective? >> >> >> Regards, >> Vincent Ngundi & Darwin Da Costa >> AFRINIC PDWG Co-Chairs >> >> >> >> >> ------------------------------ >> >> Message: 4 >> Date: Thu, 28 May 2026 09:22:45 +0100 >> From: Gbemisola Esho > >> To: Darwin Da Costa > >> Cc: rpd > >> Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing >> AFPUB-2026-v6-001-DRAFT01. >> Message-ID: >> > >> Content-Type: text/plain; charset="utf-8" >> >> Acknowledged with thanks >> >> >> Regards, >> Gbemisola Esho >> >> On Thu, 28 May 2026, 09:08 Darwin Da Costa, > wrote: >> >> > Dear PDWG, >> > >> > >> > We have received a new draft policy proposal - IPv6 as a criteria in IPv4 >> > Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. >> > The proposal contents are published at: >> > >> > >> > https://afrinic.net/afpub-2026-v6-001-draft01 >> > >> > >> > >> > We encourage you to take some time to go through the proposal contents and >> > provide feedback as follows: >> > >> > >> > a)Do you support or oppose the proposal? >> > >> > >> > b) If you oppose the proposal, state your reasons? >> > >> > >> > c) Is there anything in the proposal that is not clear? >> > >> > >> > d) What changes could be made to this proposal to make it more effective? >> > >> > >> > >> > Regards, >> > >> > Vincent Ngundi & Darwin Da Costa >> > >> > AFRINIC PDWG Co-Chairs >> > >> > _______________________________________________ >> > RPD mailing list >> > RPD at afrinic.net >> > https://lists.afrinic.net/mailman/listinfo/rpd >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ------------------------------ >> >> End of RPD Digest, Vol 220, Issue 44 >> ************************************ > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gbemiadepojuesho at gmail.com Thu May 28 13:54:14 2026 From: gbemiadepojuesho at gmail.com (Gbemisola Esho) Date: Thu, 28 May 2026 14:54:14 +0100 Subject: [rpd] In Memoriam: Alan Barrett In-Reply-To: References: Message-ID: May his soul rest in peace, though I hardly knew him but I knew of him that is work. Condolences to his friends and family. Gbemisola Esho. On Thu, 28 May 2026, 14:18 Seun Ojedeji, wrote: > Very sad news: Africa has lost one of the founding fathers of AFRINIC, a > great technocrat and a dear friend of the community. He will be dearly > missed, may his soul rest in peace! > > Regards > > On Thu, 28 May 2026 at 07:42, Andrew Alston wrote: > >> Dear friends and colleagues, >> >> As some of you will already be aware, it is with immense sadness that we >> confirm, on behalf of his wife Kerry and the family, the passing of Alan >> Barrett. Alan died on May 28th in Cape Town, South Africa, following a >> diagnosis of late-stage cancer about a month ago. We are sharing this >> notice so that the community has accurate information at a moment when >> Kerry and the family need space to grieve. >> >> Alan was a friend, a willing listener, and someone who always stepped up >> to help when called upon. His contributions to the African Internet >> ecosystem were second to none, and with his passing we lose not only a >> friend but a giant of the industry. >> >> In 1990, Alan helped establish the very first Internet connection to >> South African universities, and in 1993 he co-founded the country's first >> commercial Internet Service Provider. In 1997 he co-authored the proposal >> to create AfriNIC and subsequently served on the steering committee tasked >> with bringing it into being. Alan served on the AfriNIC board from 2004 to >> 2009 and was a member of the NRO NC from 2004 to 2014. In 2015 he was >> appointed CEO of AfriNIC, a role he held until 2019. >> >> Beyond Africa, he was a central participant in the IANA Stewardship >> Transition Coordination Group, and until his death served on the ICANN >> board on behalf of the Address Supporting Organisation. >> >> Alan will be sorely missed by the community, his relatives and his wife, >> Kerry. >> >> Kerry and the family ask for privacy at this time. We will be organising >> an online memorial in due course and will share details once they are >> available. >> >> Andrew Alston >> Remco van Mook >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > > > -- > ------------------------------------------------------------------------ > > > *Seun Ojedeji,* > > Bringing another down does not take you up - think about your action! > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu May 28 13:55:28 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Thu, 28 May 2026 15:55:28 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: <26787741-b549-41e9-a27e-abf062fe6dac@uls.co.za> References: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> <26787741-b549-41e9-a27e-abf062fe6dac@uls.co.za> Message-ID: <2B015435-ED04-45E5-95BA-807D1D62092D@consulintel.es> Fully agree. I think my recent response to Theresa provides a bigger context/response. Regards, Jordi @jordipalet > El 28 may 2026, a las 13:44, Jaco Kroon escribi?: > > Hi Seun, > > I don't think anybody at this point in time should become an Afrinic member if they don't deal with reality: You need to deploy IPv6. > > I do agree it shouldn't run stale - but I'd rather see that happening than people don't actively deploy IPv6. > > Kind regards, > Jaco > > On 2026/05/28 13:40, Seun Ojedeji wrote: > >> This proposal looks good to me in principle but I'd like to mention that if this is a first v4 request then perhaps V6 deployment plan requirement should not be mandatory. >> >> While we need people to deploy V6, we also don't want V4 to run stale in AFRINIC's vault, a balanced depletion rate may be good. I fear this proposal may reduce depletion rate of v4 which I know may not be the intent. >> >> I also look forward to reading staff analysis of this proposal especially as it concerns V6 justification implementation >> >> Regards >> >> ---- >> Sent from my mobile >> kindly excuse typos >> >> >> >> On Thu, 28 May 2026, 3:05?am Darwin Da Costa, > wrote: >>> Dear PDWG, >>> >>> We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>> >>> https://afrinic.net/afpub-2026-v6-001-draft01 >>> >>> >>> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>> >>> a)Do you support or oppose the proposal? >>> >>> b) If you oppose the proposal, state your reasons? >>> >>> c) Is there anything in the proposal that is not clear? >>> >>> d) What changes could be made to this proposal to make it more effective? >>> >>> >>> Regards, >>> Vincent Ngundi & Darwin Da Costa >>> AFRINIC PDWG Co-Chairs >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From evelyngeek at gmail.com Thu May 28 14:36:47 2026 From: evelyngeek at gmail.com (Evelyn Namara) Date: Thu, 28 May 2026 17:36:47 +0300 Subject: [rpd] In Memoriam: Alan Barrett In-Reply-To: References: Message-ID: This is truly shocking! So sad to hear of the passing of my dear friend Alan! He was a gentle giant, a kind soul, and a resource for this ecosystem. I will forever cherish the moments our work interfaced and his consistent cheering me on! Rest easy friend! On Thu, May 28, 2026 at 4:57?PM Gbemisola Esho wrote: > May his soul rest in peace, though I hardly knew him but I knew of him > that is work. > Condolences to his friends and family. > > Gbemisola Esho. > > On Thu, 28 May 2026, 14:18 Seun Ojedeji, wrote: > >> Very sad news: Africa has lost one of the founding fathers of AFRINIC, a >> great technocrat and a dear friend of the community. He will be dearly >> missed, may his soul rest in peace! >> >> Regards >> >> On Thu, 28 May 2026 at 07:42, Andrew Alston >> wrote: >> >>> Dear friends and colleagues, >>> >>> As some of you will already be aware, it is with immense sadness that we >>> confirm, on behalf of his wife Kerry and the family, the passing of Alan >>> Barrett. Alan died on May 28th in Cape Town, South Africa, following a >>> diagnosis of late-stage cancer about a month ago. We are sharing this >>> notice so that the community has accurate information at a moment when >>> Kerry and the family need space to grieve. >>> >>> Alan was a friend, a willing listener, and someone who always stepped up >>> to help when called upon. His contributions to the African Internet >>> ecosystem were second to none, and with his passing we lose not only a >>> friend but a giant of the industry. >>> >>> In 1990, Alan helped establish the very first Internet connection to >>> South African universities, and in 1993 he co-founded the country's first >>> commercial Internet Service Provider. In 1997 he co-authored the proposal >>> to create AfriNIC and subsequently served on the steering committee tasked >>> with bringing it into being. Alan served on the AfriNIC board from 2004 to >>> 2009 and was a member of the NRO NC from 2004 to 2014. In 2015 he was >>> appointed CEO of AfriNIC, a role he held until 2019. >>> >>> Beyond Africa, he was a central participant in the IANA Stewardship >>> Transition Coordination Group, and until his death served on the ICANN >>> board on behalf of the Address Supporting Organisation. >>> >>> Alan will be sorely missed by the community, his relatives and his wife, >>> Kerry. >>> >>> Kerry and the family ask for privacy at this time. We will be organising >>> an online memorial in due course and will share details once they are >>> available. >>> >>> Andrew Alston >>> Remco van Mook >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >> >> >> -- >> ------------------------------------------------------------------------ >> >> >> *Seun Ojedeji,* >> >> Bringing another down does not take you up - think about your action! >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From badru.ntege at nftconsult.com Thu May 28 14:39:12 2026 From: badru.ntege at nftconsult.com (Badru Ntege) Date: Thu, 28 May 2026 14:39:12 +0000 Subject: [rpd] In Memoriam: Alan Barrett In-Reply-To: References: Message-ID: Dear Andrew, and all, Thank you for sharing this heartbreaking news with such care and dignity. Alan was indeed a friend of the community. I first met him in Kampala at AfNOG 2003, and even then, his passion was unmistakable. He wasn't just attending meetings ? he was deeply invested in building something that would serve the African Internet for decades to come. That commitment never wavered. Alan was a passionate instructor at every AfNOG and AfriNIC meeting. From the early days right up to the last major face-to-face, in-person event in Kampala just before COVID, I don't think he missed a single annual gathering. His dedication to teaching and mentoring the next generation of network engineers across Africa was extraordinary. He showed up year after year, not for recognition, but because he believed in the work and in the people. His kindness, willingness to listen, and quiet strength made him someone you could always turn to. My deepest condolences to Kerry and all of Alan's family. May they find strength and peace in this difficult time. Rest in peace, Alan. You will be sorely missed. Badru Ntege From: Andrew Alston Date: Thursday, 28 May 2026 at 3:43?PM To: RPD Subject: [rpd] In Memoriam: Alan Barrett Dear friends and colleagues, As some of you will already be aware, it is with immense sadness that we confirm, on behalf of his wife Kerry and the family, the passing of Alan Barrett. Alan died on May 28th in Cape Town, South Africa, following a diagnosis of late-stage cancer about a month ago. We are sharing this notice so that the community has accurate information at a moment when Kerry and the family need space to grieve. Alan was a friend, a willing listener, and someone who always stepped up to help when called upon. His contributions to the African Internet ecosystem were second to none, and with his passing we lose not only a friend but a giant of the industry. In 1990, Alan helped establish the very first Internet connection to South African universities, and in 1993 he co-founded the country's first commercial Internet Service Provider. In 1997 he co-authored the proposal to create AfriNIC and subsequently served on the steering committee tasked with bringing it into being. Alan served on the AfriNIC board from 2004 to 2009 and was a member of the NRO NC from 2004 to 2014. In 2015 he was appointed CEO of AfriNIC, a role he held until 2019. Beyond Africa, he was a central participant in the IANA Stewardship Transition Coordination Group, and until his death served on the ICANN board on behalf of the Address Supporting Organisation. Alan will be sorely missed by the community, his relatives and his wife, Kerry. Kerry and the family ask for privacy at this time. We will be organising an online memorial in due course and will share details once they are available. Andrew Alston Remco van Mook -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkwambs02 at gmail.com Thu May 28 14:40:26 2026 From: dkwambs02 at gmail.com (Dorothy Kwamboka) Date: Thu, 28 May 2026 17:40:26 +0300 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: <2B015435-ED04-45E5-95BA-807D1D62092D@consulintel.es> References: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> <26787741-b549-41e9-a27e-abf062fe6dac@uls.co.za> <2B015435-ED04-45E5-95BA-807D1D62092D@consulintel.es> Message-ID: Dear PDWG, I understand the concern about low IPv6 adoption, but I have real reservations about making it a condition for IPv4 allocations. The RIR?s role is to coordinate number resources, not to drive network migration. Tying IPv4 access to IPv6 deployment turns a resource policy into a migration mandate, adding cost and complexity for operators, particularly in emerging markets where IPv4 is still essential. The Soft Landing policy already limits supply. Adding a mandatory IPv6 requirement would shift the burden to ordinary operators, while the benefits flow mainly to registry structures and large vendors. I ask the PDWG to consider these consequences carefully. Regards, Dorothy. On Thu, May 28, 2026 at 4:58?PM jordi.palet--- via RPD wrote: > > Fully agree. I think my recent response to Theresa provides a bigger context/response. > > Regards, > Jordi > > @jordipalet > > > El 28 may 2026, a las 13:44, Jaco Kroon escribi?: > > Hi Seun, > > I don't think anybody at this point in time should become an Afrinic member if they don't deal with reality: You need to deploy IPv6. > > I do agree it shouldn't run stale - but I'd rather see that happening than people don't actively deploy IPv6. > > Kind regards, > Jaco > > On 2026/05/28 13:40, Seun Ojedeji wrote: > > This proposal looks good to me in principle but I'd like to mention that if this is a first v4 request then perhaps V6 deployment plan requirement should not be mandatory. > > While we need people to deploy V6, we also don't want V4 to run stale in AFRINIC's vault, a balanced depletion rate may be good. I fear this proposal may reduce depletion rate of v4 which I know may not be the intent. > > I also look forward to reading staff analysis of this proposal especially as it concerns V6 justification implementation > > Regards > > ---- > Sent from my mobile > kindly excuse typos > > > > On Thu, 28 May 2026, 3:05?am Darwin Da Costa, wrote: >> >> Dear PDWG, >> >> We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >> >> https://afrinic.net/afpub-2026-v6-001-draft01 >> >> >> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >> >> a)Do you support or oppose the proposal? >> >> b) If you oppose the proposal, state your reasons? >> >> c) Is there anything in the proposal that is not clear? >> >> d) What changes could be made to this proposal to make it more effective? >> >> >> Regards, >> Vincent Ngundi & Darwin Da Costa >> AFRINIC PDWG Co-Chairs >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From ben.roberts at afrinic.net Thu May 28 14:55:45 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Thu, 28 May 2026 17:55:45 +0300 Subject: [rpd] Promoting IPv6 adoption In-Reply-To: References: Message-ID: <7B0B99DF-A2DE-4F7C-9D11-83221919F526@afrinic.net> An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu May 28 15:12:12 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Thu, 28 May 2026 17:12:12 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> <26787741-b549-41e9-a27e-abf062fe6dac@uls.co.za> <2B015435-ED04-45E5-95BA-807D1D62092D@consulintel.es> Message-ID: Hi Dorothy, I need to make this clear again. There is no such thing as migration, we don?t turn-off IPv4 completely. Anyone can keep using it. What we are doing is to ensure with IPv6-only with IPv4-as-a-Service, that both protocols coexist, so we do an ordered transition, at the pace of everyone. As faster you move to IPv6, as cheaper is your CapEx and OpEx, it is up to each operator. The RIR job is not setting up policies, is up to the community, the global Internet community. What we are saying is that the Soft Landing policy already was designed to ensure that newcomers and existing players needing more resources, do it together with IPv6 deployment, but we didn?t set rules to verify that and the level of encouragement was basically cero. Now we, as a community (not the RIR), can decide if we want to give a stronger push and what level of push we want to have. Fighting against IPv6 deployment is non-sense, it is a very high cost not only for all the players in Africa, but also in the rest of Internet. We need to see it in the other way around. Deploying IPv6, or extending existing networks with IPv6 is cheaper than buying more and more CGN boxes. So clearly I must disagree that this will create a burden, on the other way around. Saying it in a different way: It will be non-sense that an existing operator extend its network to accommodate more customers (that?s the reason they need more IPv4 addresses in the end), and they do it without implementing IPv6, the cost will be bigger with only-IPv4. Same non-sense that a new operator or end-site decides to start just with IPv4, the cost will be bigger. We need to find the way to word it so there is a proper balance. We are not saying necessarily, because you have ?n? new customers and need IPv4 addresses for them, you need to deploy IPv6 in all your network (even less remove IPv4 completely). Let?s find the way to ensure that we request a % of traffic according to the grow that creates you the need for more IPv4 addresses and then ramp-up the following years. Regards, Jordi @jordipalet > El 28 may 2026, a las 16:40, Dorothy Kwamboka escribi?: > > Dear PDWG, > > I understand the concern about low IPv6 adoption, but I have real > reservations about making it a condition for IPv4 allocations. The > RIR?s role is to coordinate number resources, not to drive network > migration. Tying IPv4 access to IPv6 deployment turns a resource > policy into a migration mandate, adding cost and complexity for > operators, particularly in emerging markets where IPv4 is still > essential. > > The Soft Landing policy already limits supply. Adding a mandatory IPv6 > requirement would shift the burden to ordinary operators, while the > benefits flow mainly to registry structures and large vendors. I ask > the PDWG to consider these consequences carefully. > > Regards, > Dorothy. > > On Thu, May 28, 2026 at 4:58?PM jordi.palet--- via RPD wrote: >> >> Fully agree. I think my recent response to Theresa provides a bigger context/response. >> >> Regards, >> Jordi >> >> @jordipalet >> >> >> El 28 may 2026, a las 13:44, Jaco Kroon escribi?: >> >> Hi Seun, >> >> I don't think anybody at this point in time should become an Afrinic member if they don't deal with reality: You need to deploy IPv6. >> >> I do agree it shouldn't run stale - but I'd rather see that happening than people don't actively deploy IPv6. >> >> Kind regards, >> Jaco >> >> On 2026/05/28 13:40, Seun Ojedeji wrote: >> >> This proposal looks good to me in principle but I'd like to mention that if this is a first v4 request then perhaps V6 deployment plan requirement should not be mandatory. >> >> While we need people to deploy V6, we also don't want V4 to run stale in AFRINIC's vault, a balanced depletion rate may be good. I fear this proposal may reduce depletion rate of v4 which I know may not be the intent. >> >> I also look forward to reading staff analysis of this proposal especially as it concerns V6 justification implementation >> >> Regards >> >> ---- >> Sent from my mobile >> kindly excuse typos >> >> >> >> On Thu, 28 May 2026, 3:05?am Darwin Da Costa, wrote: >>> >>> Dear PDWG, >>> >>> We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>> >>> https://afrinic.net/afpub-2026-v6-001-draft01 >>> >>> >>> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>> >>> a)Do you support or oppose the proposal? >>> >>> b) If you oppose the proposal, state your reasons? >>> >>> c) Is there anything in the proposal that is not clear? >>> >>> d) What changes could be made to this proposal to make it more effective? >>> >>> >>> Regards, >>> Vincent Ngundi & Darwin Da Costa >>> AFRINIC PDWG Co-Chairs >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jordi.palet at consulintel.es Thu May 28 15:27:22 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Thu, 28 May 2026 17:27:22 +0200 Subject: [rpd] Promoting IPv6 adoption In-Reply-To: <7B0B99DF-A2DE-4F7C-9D11-83221919F526@afrinic.net> References: <7B0B99DF-A2DE-4F7C-9D11-83221919F526@afrinic.net> Message-ID: <1B962FF9-82EF-4F8D-BF0A-838EABF2C5C1@consulintel.es> Hi Ben, I don?t think I?ve suggested (it wasn?t my intent) that we need to exhaust IPv4 as fast as possible, on the other way around. Note that Afrinic recovered 3.000.000 of address, and I suggested in another proposal, to keep them under the same Soft Landing ?pool", not reverting back to allocation policies previous to Soft Landing. We entered in the last Soft Landing phase, let?s remain there to have a more controlled distribution of IPv4 resources, but together with IPv6. This is to ensure that both, newcomers, and people willing to do the transition to IPv6, still keep having IPv4 pools to be able to do that and avoid them a heavy work of renumbering existing customers to recover IPv4 addresses from other parts of the network. After reading your blog, I think we agree that deploying new networks with IPv6 is the way: ?The silver lining is that Africa's relative latecomer status to internet infrastructure could become an advantage: rather than managing the complex transition from IPv4 to IPv6, many African nations can build IPv6-native networks from the ground up. This leapfrogging potential, combined with mobile-first innovation and growing regional interconnection, suggests that today's IPv4 poverty need not determine tomorrow's digital destiny." This is true also for extending existing networks (so those requesting new IPv4 allocations or assignments). Unless you advocate for ?if you need to extend your network, better keep doing it with IPv4?? I just disagree that you mention a complex transition from IPv4 to IPv6. This is not longer true. Right now in both, mobile and wired networks, deploying 464XLAT is much much much much cheaper than IPv4 or even dual-stack (and in this case easier as well). Even in the case of enterprise networks, using IPv6-Mostly is also cheaper and easier. This is not an opinion, is technical and economical facts, based on deployment experience in hundreds of networks. I?m not saying turning your existing network to IPv6 overnight. A progressive deployment, which match each specific case needs to be planned. Regards, Jordi @jordipalet > El 28 may 2026, a las 16:55, Ben Roberts - AfriNIC escribi?: > > Jordi, > I really have to disagree with this narrative that IPv4 needs to be exhausted as fast as possible because some regard it as legacy. > > I draw attention to my earlier blog on this matter where I advocate that the inequality gap is there. https://www.digitaleconomy.ke/post/ipv4-address-allocation-in-africa-are-you-above-or-below-the-ip-address-poverty-line > > For now those African countries that are catching up are going to need that base load allocations that they get under soft landing. > > Kind regards > > Ben > > Sent from my iPhone > >> On 28 May 2026, at 16:53, jordi.palet--- via RPD wrote: >> >> ?Hi Theresa, >> >> I think it needs to be understood that IPv4 is legacy and its main usage must be supporting transition. >> >> This has been said already many times, but I think we need to repeat it. >> >> It doesn?t make any sense to extend any existing network, or to deploy a new one, with IPv4-only. >> >> We are not saying it must be done with IPv6-only. In fact, the way is IPv6-Only with IPv4-as-a-Service, which basically means this is not a migration (we aren?t talking about removing IPv4 completely), it is transition and coexistence (there is no such concept as migration defined by IETF). >> >> The Soft Landing policy was designed having this in mind, it is clear reading 5.4 in the CPM, however we didn?t took measures at that time to make it happen. Now is the time. >> >> At that time the IPv6 deployment levels were very low globally, but at this time, Africa is overall, the bigger lagging region and no great signs that this is changing quickly. >> >> There is not today, any technical or even economical rationale to support IPv4 only. In fact across many deployments where I?ve participated in more than 150 countries, the result is that deploying IPv6 is much cheaper than IPv4 (IPv6 supporting equipment is not more expensive than IPv4, is the same price, and some cost are much lower, such as no need for CGN boxes). The problem is basically a lack of decision by executives, not technical people. >> >> We need to accommodate to the pace of each one, but a credible pace, not a pace like ?I get more IPv4, promise IPv6, but I?m lazy and don?t have now the time to do it". I think is fine that we accommodate the text in the new version so each one can say ?I realistically will grow 15% my network in the next year (that?s why I?m asking for IPv4 addresses), and I will do that with IPv6, so I commit to % IPv6 traffic for the 1st year, % next one and so on?. I?m happy to try as much as possible, with all your contributions, to accommodate the text in the next version, in such way that is not like you say having the cost and pressure unbalanced. >> >> Regards, >> Jordi >> >> @jordipalet >> >> >>> El 28 may 2026, a las 15:24, Theresa Dukumor escribi?: >>> >>> Dear PDWG, >>> >>> While I appreciate the goal of promoting IPv6 adoption, I have concerns about making it a condition for IPv4 allocations under Soft Landing. IPv4 is still the operating foundation for many in this region. Adding a mandate compounds cost and complexity without proven benefit, turning a resource policy into a migration mandate. The cost and pressure would fall on ordinary operators, while the main winners are likely registry governance bodies and large equipment vendors. I ask the PDWG to examine these consequences carefully. >>> >>> Regards, >>> Theresa >>> >>> >>> On Thu, May 28, 2026 at 9:23?AM > wrote: >>>> Send RPD mailing list submissions to >>>> rpd at afrinic.net >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> or, via email, send a message with subject or body 'help' to >>>> rpd-request at afrinic.net >>>> >>>> You can reach the person managing the list at >>>> rpd-owner at afrinic.net >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of RPD digest..." >>>> >>>> >>>> Today's Topics: >>>> >>>> 1. IPv6 as a criteria in IPv4 Soft Landing >>>> AFPUB-2026-v6-001-DRAFT01. (Darwin Da Costa) >>>> 2. Re: Require newly created AS-SETs to have hierarchical names >>>> AFPUB-2026-ASN-001-DRAFT01. (Jaco Kroon) >>>> 3. AFRINIC Policy Compliance Dashboard ID >>>> AFPUB-2026-GEN-002-DRAFT01. (Darwin Da Costa) >>>> 4. Re: IPv6 as a criteria in IPv4 Soft Landing >>>> AFPUB-2026-v6-001-DRAFT01. (Gbemisola Esho) >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> Message: 1 >>>> Date: Thu, 28 May 2026 10:05:07 +0200 >>>> From: Darwin Da Costa > >>>> To: rpd at afrinic.net >>>> Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing >>>> AFPUB-2026-v6-001-DRAFT01. >>>> Message-ID: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18 at gmail.com > >>>> Content-Type: text/plain; charset="us-ascii" >>>> >>>> Dear PDWG, >>>> >>>> We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>>> >>>> https://afrinic.net/afpub-2026-v6-001-draft01 >>>> >>>> >>>> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>>> >>>> a)Do you support or oppose the proposal? >>>> >>>> b) If you oppose the proposal, state your reasons? >>>> >>>> c) Is there anything in the proposal that is not clear? >>>> >>>> d) What changes could be made to this proposal to make it more effective? >>>> >>>> >>>> Regards, >>>> Vincent Ngundi & Darwin Da Costa >>>> AFRINIC PDWG Co-Chairs >>>> >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: >>>> >>>> ------------------------------ >>>> >>>> Message: 2 >>>> Date: Thu, 28 May 2026 10:07:01 +0200 >>>> From: Jaco Kroon > >>>> To: James Bensley , "dacostadarwin at gmail.com " >>>> >, "rpd at afrinic.net " > >>>> Subject: Re: [rpd] Require newly created AS-SETs to have hierarchical >>>> names AFPUB-2026-ASN-001-DRAFT01. >>>> Message-ID: > >>>> Content-Type: text/plain; charset=UTF-8; format=flowed >>>> >>>> Hi James, >>>> >>>> On 2026/05/28 09:54, James Bensley wrote: >>>> >>>> > Hi Jaco, >>>> > >>>> > Thank you for the support and your feedback. >>>> > >>>> > I wrote the original proposal. Regarding this comment: >>>> > >>>> > "The only thing that I found weird is that the second element has to be a name, why would "ASnum:ASnum2:AS-name" not be acceptable?" >>>> > >>>> > If you have a use case for that, then that could be added to the proposal. Do you have a use case/requirement for this? I think this usage is very rare, but if you have this use case, please speak up :) >>>> >>>> It's a hierarchy right, so what if I want to refer my customers by their >>>> AS numbers? >>>> >>>> Eg, ASyyyy:ASxxxx:AS-set >>>> >>>> It's an arbitrary and in my opinion unneeded restriction which can be >>>> removed.? The only restriction is that the first component has to be >>>> ASnum where you have control over AS num.? The rest can be left to the >>>> discretion of the ASnum admin surely? >>>> >>>> So just drop bullet three entirely. >>>> >>>> > >>>> > >>>> > Regarding this comment: >>>> > >>>> > "The purpose/function of "3. Other set types such as route sets are excluded." is unclear - everything else speaks specifically to AS-SET so why is this mention required?" >>>> > >>>> > Because route-sets can also support hierarchical names and in the past people have had the thought "well if we're making this change for AS-SETs let's also making it for Route-Sets whilst we're here" - but route-sets are extremely rarely used today and this just adds scope which I think isn't needed. So it was just about trying to stop that scope creep. >>>> >>>> I hear you. >>>> >>>> 7.8 as as whole specifically states "AS-SET" - not "Set Types", and >>>> point 1 also makes it clears this refers specifically to AS-SET, which >>>> means point 3 can be dropped without changing the intent/meaning of 7.8 >>>> as a whole. >>>> >>>> Point 4 also really adds no value, that's an operational issue, not a >>>> policy issue.? Definitely a valid point and something to be aware but >>>> still operational, not policy. >>>> >>>> Exceptions to the policy may need to be permitted on a case by case >>>> basis *if and only if* a non-hierarchical AS-SET has been accidentally >>>> deleted to allow recreation.? IMHO these should require motivation to >>>> have them restored from where they can then be edited again as per point 6. >>>> >>>> Kind regards, >>>> Jaco >>>> >>>> > >>>> > With kind regards, >>>> > James Bensley (he/him) >>>> > >>>> > ________________________________________ >>>> > From: Jaco Kroon > >>>> > Sent: 21 May 2026 14:06 >>>> > To: dacostadarwin at gmail.com >; rpd at afrinic.net > >>>> > Subject: Re: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. >>>> > >>>> > Hi, >>>> > >>>> > Definitely in support. >>>> > >>>> > The only thing that I found weird is that the second element has to be a >>>> > name, why would "ASnum:ASnum2:AS-name" not be acceptable? >>>> > >>>> > The purpose/function of "3. Other set types such as route sets are >>>> > excluded." is unclear - everything else speaks specifically to AS-SET so >>>> > why is this mention required? >>>> > >>>> > Kind regards, >>>> > Jaco >>>> > >>>> > On 2026/05/20 19:37, dacostadarwin at gmail.com wrote: >>>> > >>>> >> Dear PDWG, >>>> >> >>>> >> We have received a new draft policy proposal - Require newly created AS-SETs to have hierarchical names, ID AFPUB-2026-ASN-001-DRAFT01 from author James Bensley. >>>> >> >>>> >> The proposal contents are published at: >>>> >> https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft01 >>>> >> >>>> >> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>>> >> >>>> >> a) Do you support or oppose the proposal? >>>> >> >>>> >> b) If you oppose the proposal, state your reasons? >>>> >> >>>> >> c) Is there anything in the proposal that is not clear? >>>> >> >>>> >> d) What changes could be made to this proposal to make it more effective? >>>> >> >>>> >> Regards, >>>> >> Vincent Ngundi & Darwin Da Costa >>>> >> AFRINIC PDWG Co-Chairs >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> RPD mailing list >>>> >> RPD at afrinic.net >>>> >> https://lists.afrinic.net/mailman/listinfo/rpd >>>> > _______________________________________________ >>>> > RPD mailing list >>>> > RPD at afrinic.net >>>> > https://lists.afrinic.net/mailman/listinfo/rpd >>>> > [CompanySignature] >>>> > Inter..link GmbH | Boxhagener Stra?e 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello at inter.link> | Web: inter.link> >>>> >>>> >>>> >>>> ------------------------------ >>>> >>>> Message: 3 >>>> Date: Thu, 28 May 2026 10:07:31 +0200 >>>> From: Darwin Da Costa > >>>> To: rpd at afrinic.net >>>> Subject: [rpd] AFRINIC Policy Compliance Dashboard ID >>>> AFPUB-2026-GEN-002-DRAFT01. >>>> Message-ID: > >>>> Content-Type: text/plain; charset=us-ascii >>>> >>>> Dear PDWG, >>>> >>>> We have received a new draft policy proposal - AFRINIC Policy Compliance Dashboard ID AFPUB-2026-GEN-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>>> >>>> https://afrinic.net/afpub-2026-gen-002-draft01 >>>> >>>> >>>> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>>> >>>> a) Do you support or oppose the proposal? >>>> >>>> b) If you oppose the proposal, state your reasons? >>>> >>>> c) Is there anything in the proposal that is not clear? >>>> >>>> d) What changes could be made to this proposal to make it more effective? >>>> >>>> >>>> Regards, >>>> Vincent Ngundi & Darwin Da Costa >>>> AFRINIC PDWG Co-Chairs >>>> >>>> >>>> >>>> >>>> ------------------------------ >>>> >>>> Message: 4 >>>> Date: Thu, 28 May 2026 09:22:45 +0100 >>>> From: Gbemisola Esho > >>>> To: Darwin Da Costa > >>>> Cc: rpd > >>>> Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing >>>> AFPUB-2026-v6-001-DRAFT01. >>>> Message-ID: >>>> > >>>> Content-Type: text/plain; charset="utf-8" >>>> >>>> Acknowledged with thanks >>>> >>>> >>>> Regards, >>>> Gbemisola Esho >>>> >>>> On Thu, 28 May 2026, 09:08 Darwin Da Costa, > wrote: >>>> >>>> > Dear PDWG, >>>> > >>>> > >>>> > We have received a new draft policy proposal - IPv6 as a criteria in IPv4 >>>> > Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. >>>> > The proposal contents are published at: >>>> > >>>> > >>>> > https://afrinic.net/afpub-2026-v6-001-draft01 >>>> > >>>> > >>>> > >>>> > We encourage you to take some time to go through the proposal contents and >>>> > provide feedback as follows: >>>> > >>>> > >>>> > a)Do you support or oppose the proposal? >>>> > >>>> > >>>> > b) If you oppose the proposal, state your reasons? >>>> > >>>> > >>>> > c) Is there anything in the proposal that is not clear? >>>> > >>>> > >>>> > d) What changes could be made to this proposal to make it more effective? >>>> > >>>> > >>>> > >>>> > Regards, >>>> > >>>> > Vincent Ngundi & Darwin Da Costa >>>> > >>>> > AFRINIC PDWG Co-Chairs >>>> > >>>> > _______________________________________________ >>>> > RPD mailing list >>>> > RPD at afrinic.net >>>> > https://lists.afrinic.net/mailman/listinfo/rpd >>>> > >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: >>>> >>>> ------------------------------ >>>> >>>> Subject: Digest Footer >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>>> >>>> ------------------------------ >>>> >>>> End of RPD Digest, Vol 220, Issue 44 >>>> ************************************ >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Thu May 28 15:37:33 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Thu, 28 May 2026 18:37:33 +0300 Subject: [rpd] Promoting IPv6 adoption In-Reply-To: <1B962FF9-82EF-4F8D-BF0A-838EABF2C5C1@consulintel.es> References: <1B962FF9-82EF-4F8D-BF0A-838EABF2C5C1@consulintel.es> Message-ID: <54A4F147-0E45-441D-8D94-8B8346B129A2@afrinic.net> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image1.jpeg Type: image/jpeg Size: 328934 bytes Desc: not available URL: From jordi.palet at consulintel.es Thu May 28 16:14:25 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Thu, 28 May 2026 18:14:25 +0200 Subject: [rpd] Promoting IPv6 adoption In-Reply-To: <54A4F147-0E45-441D-8D94-8B8346B129A2@afrinic.net> References: <1B962FF9-82EF-4F8D-BF0A-838EABF2C5C1@consulintel.es> <54A4F147-0E45-441D-8D94-8B8346B129A2@afrinic.net> Message-ID: <4C6B314A-2A97-4A63-BFBB-348820BDFBA9@consulintel.es> Hi Ben, Today there are sufficient OEM vendors for all kind of network devices that there is no need to buy ?pre owned? equipment. In Alibaba, you can find almost anything. I was in Shenzhen in March for the IETF meeting and visited a coupe of vendors, really impressive. Actually brought with me some 100G L3 switches, among other things, and just as a quick comparison, one of them will have costed me 4-5.000 euros in Spain, and I paid only 432 USD. Even more features than using a well known branded device. For ONU, CPE, etc., I?m not necessarily suggesting replacing all those already in customers in a single shot, clearly it could be phases across a number of months or years, and be part of marketing actions, such as ?we will provide a better wifi, you need to pay part of the cost?. As an example, you can find in Alibaba, without the need for buying thousands of units (of course cheaper if you do so, but basically because the shipping and customs clearance expenses go down per unit), ONU/CPE with Wifi, 4 Gig ports, for less than 12-15USD (you?ve thousands of options to choose). You can customize OpenWrt based on your own needs if a default OpenWrt doesn?t work for you. IPv6 (actually 464XLAT) deployment in 4/5G networks is the most easy one, so they don?t really have any excuse. May be they don?t have the expertise, but experienced consultants in the field, like ourselves (sorry not intended publicity, just showing reality), will be much cheaper an reliable that trusting any vendor or paying for their extra services. Regards, Jordi @jordipalet > El 28 may 2026, a las 17:37, Ben Roberts - AfriNIC escribi?: > > Jordi, > Ok. I think we are mostly aligned. > Other challenges we have of older ?pre owned? equipment in the provider WAN and very much in the enterprise LAN, as well as consumer devices and CPEs are also part of the challenge. That may be a blog for another day?. > > My list of shame though really is the lazy MNOs and their vendors that have deployed state of the art 5G core and not rolled out V6. This unfortunately means that most African Internet users don?t get served an IPv6. > > > > > > Sent from my iPhone > >> On 28 May 2026, at 18:28, jordi.palet--- via RPD wrote: >> >> ?Hi Ben, >> >> I don?t think I?ve suggested (it wasn?t my intent) that we need to exhaust IPv4 as fast as possible, on the other way around. >> >> Note that Afrinic recovered 3.000.000 of address, and I suggested in another proposal, to keep them under the same Soft Landing ?pool", not reverting back to allocation policies previous to Soft Landing. We entered in the last Soft Landing phase, let?s remain there to have a more controlled distribution of IPv4 resources, but together with IPv6. This is to ensure that both, newcomers, and people willing to do the transition to IPv6, still keep having IPv4 pools to be able to do that and avoid them a heavy work of renumbering existing customers to recover IPv4 addresses from other parts of the network. >> >> After reading your blog, I think we agree that deploying new networks with IPv6 is the way: >> >> ?The silver lining is that Africa's relative latecomer status to internet infrastructure could become an advantage: rather than managing the complex transition from IPv4 to IPv6, many African nations can build IPv6-native networks from the ground up. This leapfrogging potential, combined with mobile-first innovation and growing regional interconnection, suggests that today's IPv4 poverty need not determine tomorrow's digital destiny." >> >> This is true also for extending existing networks (so those requesting new IPv4 allocations or assignments). Unless you advocate for ?if you need to extend your network, better keep doing it with IPv4?? >> >> I just disagree that you mention a complex transition from IPv4 to IPv6. This is not longer true. Right now in both, mobile and wired networks, deploying 464XLAT is much much much much cheaper than IPv4 or even dual-stack (and in this case easier as well). Even in the case of enterprise networks, using IPv6-Mostly is also cheaper and easier. This is not an opinion, is technical and economical facts, based on deployment experience in hundreds of networks. >> >> I?m not saying turning your existing network to IPv6 overnight. A progressive deployment, which match each specific case needs to be planned. >> >> Regards, >> Jordi >> >> @jordipalet >> >> >>> El 28 may 2026, a las 16:55, Ben Roberts - AfriNIC escribi?: >>> >>> Jordi, >>> I really have to disagree with this narrative that IPv4 needs to be exhausted as fast as possible because some regard it as legacy. >>> >>> I draw attention to my earlier blog on this matter where I advocate that the inequality gap is there. https://www.digitaleconomy.ke/post/ipv4-address-allocation-in-africa-are-you-above-or-below-the-ip-address-poverty-line >>> >>> For now those African countries that are catching up are going to need that base load allocations that they get under soft landing. >>> >>> Kind regards >>> >>> Ben >>> >>> Sent from my iPhone >>> >>>> On 28 May 2026, at 16:53, jordi.palet--- via RPD wrote: >>>> >>>> ?Hi Theresa, >>>> >>>> I think it needs to be understood that IPv4 is legacy and its main usage must be supporting transition. >>>> >>>> This has been said already many times, but I think we need to repeat it. >>>> >>>> It doesn?t make any sense to extend any existing network, or to deploy a new one, with IPv4-only. >>>> >>>> We are not saying it must be done with IPv6-only. In fact, the way is IPv6-Only with IPv4-as-a-Service, which basically means this is not a migration (we aren?t talking about removing IPv4 completely), it is transition and coexistence (there is no such concept as migration defined by IETF). >>>> >>>> The Soft Landing policy was designed having this in mind, it is clear reading 5.4 in the CPM, however we didn?t took measures at that time to make it happen. Now is the time. >>>> >>>> At that time the IPv6 deployment levels were very low globally, but at this time, Africa is overall, the bigger lagging region and no great signs that this is changing quickly. >>>> >>>> There is not today, any technical or even economical rationale to support IPv4 only. In fact across many deployments where I?ve participated in more than 150 countries, the result is that deploying IPv6 is much cheaper than IPv4 (IPv6 supporting equipment is not more expensive than IPv4, is the same price, and some cost are much lower, such as no need for CGN boxes). The problem is basically a lack of decision by executives, not technical people. >>>> >>>> We need to accommodate to the pace of each one, but a credible pace, not a pace like ?I get more IPv4, promise IPv6, but I?m lazy and don?t have now the time to do it". I think is fine that we accommodate the text in the new version so each one can say ?I realistically will grow 15% my network in the next year (that?s why I?m asking for IPv4 addresses), and I will do that with IPv6, so I commit to % IPv6 traffic for the 1st year, % next one and so on?. I?m happy to try as much as possible, with all your contributions, to accommodate the text in the next version, in such way that is not like you say having the cost and pressure unbalanced. >>>> >>>> Regards, >>>> Jordi >>>> >>>> @jordipalet >>>> >>>> >>>>> El 28 may 2026, a las 15:24, Theresa Dukumor escribi?: >>>>> >>>>> Dear PDWG, >>>>> >>>>> While I appreciate the goal of promoting IPv6 adoption, I have concerns about making it a condition for IPv4 allocations under Soft Landing. IPv4 is still the operating foundation for many in this region. Adding a mandate compounds cost and complexity without proven benefit, turning a resource policy into a migration mandate. The cost and pressure would fall on ordinary operators, while the main winners are likely registry governance bodies and large equipment vendors. I ask the PDWG to examine these consequences carefully. >>>>> >>>>> Regards, >>>>> Theresa >>>>> >>>>> >>>>> On Thu, May 28, 2026 at 9:23?AM > wrote: >>>>>> Send RPD mailing list submissions to >>>>>> rpd at afrinic.net >>>>>> >>>>>> To subscribe or unsubscribe via the World Wide Web, visit >>>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>>> or, via email, send a message with subject or body 'help' to >>>>>> rpd-request at afrinic.net >>>>>> >>>>>> You can reach the person managing the list at >>>>>> rpd-owner at afrinic.net >>>>>> >>>>>> When replying, please edit your Subject line so it is more specific >>>>>> than "Re: Contents of RPD digest..." >>>>>> >>>>>> >>>>>> Today's Topics: >>>>>> >>>>>> 1. IPv6 as a criteria in IPv4 Soft Landing >>>>>> AFPUB-2026-v6-001-DRAFT01. (Darwin Da Costa) >>>>>> 2. Re: Require newly created AS-SETs to have hierarchical names >>>>>> AFPUB-2026-ASN-001-DRAFT01. (Jaco Kroon) >>>>>> 3. AFRINIC Policy Compliance Dashboard ID >>>>>> AFPUB-2026-GEN-002-DRAFT01. (Darwin Da Costa) >>>>>> 4. Re: IPv6 as a criteria in IPv4 Soft Landing >>>>>> AFPUB-2026-v6-001-DRAFT01. (Gbemisola Esho) >>>>>> >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> Message: 1 >>>>>> Date: Thu, 28 May 2026 10:05:07 +0200 >>>>>> From: Darwin Da Costa > >>>>>> To: rpd at afrinic.net >>>>>> Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing >>>>>> AFPUB-2026-v6-001-DRAFT01. >>>>>> Message-ID: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18 at gmail.com > >>>>>> Content-Type: text/plain; charset="us-ascii" >>>>>> >>>>>> Dear PDWG, >>>>>> >>>>>> We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>>>>> >>>>>> https://afrinic.net/afpub-2026-v6-001-draft01 >>>>>> >>>>>> >>>>>> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>>>>> >>>>>> a)Do you support or oppose the proposal? >>>>>> >>>>>> b) If you oppose the proposal, state your reasons? >>>>>> >>>>>> c) Is there anything in the proposal that is not clear? >>>>>> >>>>>> d) What changes could be made to this proposal to make it more effective? >>>>>> >>>>>> >>>>>> Regards, >>>>>> Vincent Ngundi & Darwin Da Costa >>>>>> AFRINIC PDWG Co-Chairs >>>>>> >>>>>> -------------- next part -------------- >>>>>> An HTML attachment was scrubbed... >>>>>> URL: >>>>>> >>>>>> ------------------------------ >>>>>> >>>>>> Message: 2 >>>>>> Date: Thu, 28 May 2026 10:07:01 +0200 >>>>>> From: Jaco Kroon > >>>>>> To: James Bensley , "dacostadarwin at gmail.com " >>>>>> >, "rpd at afrinic.net " > >>>>>> Subject: Re: [rpd] Require newly created AS-SETs to have hierarchical >>>>>> names AFPUB-2026-ASN-001-DRAFT01. >>>>>> Message-ID: > >>>>>> Content-Type: text/plain; charset=UTF-8; format=flowed >>>>>> >>>>>> Hi James, >>>>>> >>>>>> On 2026/05/28 09:54, James Bensley wrote: >>>>>> >>>>>> > Hi Jaco, >>>>>> > >>>>>> > Thank you for the support and your feedback. >>>>>> > >>>>>> > I wrote the original proposal. Regarding this comment: >>>>>> > >>>>>> > "The only thing that I found weird is that the second element has to be a name, why would "ASnum:ASnum2:AS-name" not be acceptable?" >>>>>> > >>>>>> > If you have a use case for that, then that could be added to the proposal. Do you have a use case/requirement for this? I think this usage is very rare, but if you have this use case, please speak up :) >>>>>> >>>>>> It's a hierarchy right, so what if I want to refer my customers by their >>>>>> AS numbers? >>>>>> >>>>>> Eg, ASyyyy:ASxxxx:AS-set >>>>>> >>>>>> It's an arbitrary and in my opinion unneeded restriction which can be >>>>>> removed.? The only restriction is that the first component has to be >>>>>> ASnum where you have control over AS num.? The rest can be left to the >>>>>> discretion of the ASnum admin surely? >>>>>> >>>>>> So just drop bullet three entirely. >>>>>> >>>>>> > >>>>>> > >>>>>> > Regarding this comment: >>>>>> > >>>>>> > "The purpose/function of "3. Other set types such as route sets are excluded." is unclear - everything else speaks specifically to AS-SET so why is this mention required?" >>>>>> > >>>>>> > Because route-sets can also support hierarchical names and in the past people have had the thought "well if we're making this change for AS-SETs let's also making it for Route-Sets whilst we're here" - but route-sets are extremely rarely used today and this just adds scope which I think isn't needed. So it was just about trying to stop that scope creep. >>>>>> >>>>>> I hear you. >>>>>> >>>>>> 7.8 as as whole specifically states "AS-SET" - not "Set Types", and >>>>>> point 1 also makes it clears this refers specifically to AS-SET, which >>>>>> means point 3 can be dropped without changing the intent/meaning of 7.8 >>>>>> as a whole. >>>>>> >>>>>> Point 4 also really adds no value, that's an operational issue, not a >>>>>> policy issue.? Definitely a valid point and something to be aware but >>>>>> still operational, not policy. >>>>>> >>>>>> Exceptions to the policy may need to be permitted on a case by case >>>>>> basis *if and only if* a non-hierarchical AS-SET has been accidentally >>>>>> deleted to allow recreation.? IMHO these should require motivation to >>>>>> have them restored from where they can then be edited again as per point 6. >>>>>> >>>>>> Kind regards, >>>>>> Jaco >>>>>> >>>>>> > >>>>>> > With kind regards, >>>>>> > James Bensley (he/him) >>>>>> > >>>>>> > ________________________________________ >>>>>> > From: Jaco Kroon > >>>>>> > Sent: 21 May 2026 14:06 >>>>>> > To: dacostadarwin at gmail.com >; rpd at afrinic.net > >>>>>> > Subject: Re: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. >>>>>> > >>>>>> > Hi, >>>>>> > >>>>>> > Definitely in support. >>>>>> > >>>>>> > The only thing that I found weird is that the second element has to be a >>>>>> > name, why would "ASnum:ASnum2:AS-name" not be acceptable? >>>>>> > >>>>>> > The purpose/function of "3. Other set types such as route sets are >>>>>> > excluded." is unclear - everything else speaks specifically to AS-SET so >>>>>> > why is this mention required? >>>>>> > >>>>>> > Kind regards, >>>>>> > Jaco >>>>>> > >>>>>> > On 2026/05/20 19:37, dacostadarwin at gmail.com wrote: >>>>>> > >>>>>> >> Dear PDWG, >>>>>> >> >>>>>> >> We have received a new draft policy proposal - Require newly created AS-SETs to have hierarchical names, ID AFPUB-2026-ASN-001-DRAFT01 from author James Bensley. >>>>>> >> >>>>>> >> The proposal contents are published at: >>>>>> >> https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft01 >>>>>> >> >>>>>> >> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>>>>> >> >>>>>> >> a) Do you support or oppose the proposal? >>>>>> >> >>>>>> >> b) If you oppose the proposal, state your reasons? >>>>>> >> >>>>>> >> c) Is there anything in the proposal that is not clear? >>>>>> >> >>>>>> >> d) What changes could be made to this proposal to make it more effective? >>>>>> >> >>>>>> >> Regards, >>>>>> >> Vincent Ngundi & Darwin Da Costa >>>>>> >> AFRINIC PDWG Co-Chairs >>>>>> >> >>>>>> >> >>>>>> >> _______________________________________________ >>>>>> >> RPD mailing list >>>>>> >> RPD at afrinic.net >>>>>> >> https://lists.afrinic.net/mailman/listinfo/rpd >>>>>> > _______________________________________________ >>>>>> > RPD mailing list >>>>>> > RPD at afrinic.net >>>>>> > https://lists.afrinic.net/mailman/listinfo/rpd >>>>>> > [CompanySignature] >>>>>> > Inter..link GmbH | Boxhagener Stra?e 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello at inter.link> | Web: inter.link> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------ >>>>>> >>>>>> Message: 3 >>>>>> Date: Thu, 28 May 2026 10:07:31 +0200 >>>>>> From: Darwin Da Costa > >>>>>> To: rpd at afrinic.net >>>>>> Subject: [rpd] AFRINIC Policy Compliance Dashboard ID >>>>>> AFPUB-2026-GEN-002-DRAFT01. >>>>>> Message-ID: > >>>>>> Content-Type: text/plain; charset=us-ascii >>>>>> >>>>>> Dear PDWG, >>>>>> >>>>>> We have received a new draft policy proposal - AFRINIC Policy Compliance Dashboard ID AFPUB-2026-GEN-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>>>>> >>>>>> https://afrinic.net/afpub-2026-gen-002-draft01 >>>>>> >>>>>> >>>>>> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>>>>> >>>>>> a) Do you support or oppose the proposal? >>>>>> >>>>>> b) If you oppose the proposal, state your reasons? >>>>>> >>>>>> c) Is there anything in the proposal that is not clear? >>>>>> >>>>>> d) What changes could be made to this proposal to make it more effective? >>>>>> >>>>>> >>>>>> Regards, >>>>>> Vincent Ngundi & Darwin Da Costa >>>>>> AFRINIC PDWG Co-Chairs >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------ >>>>>> >>>>>> Message: 4 >>>>>> Date: Thu, 28 May 2026 09:22:45 +0100 >>>>>> From: Gbemisola Esho > >>>>>> To: Darwin Da Costa > >>>>>> Cc: rpd > >>>>>> Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing >>>>>> AFPUB-2026-v6-001-DRAFT01. >>>>>> Message-ID: >>>>>> > >>>>>> Content-Type: text/plain; charset="utf-8" >>>>>> >>>>>> Acknowledged with thanks >>>>>> >>>>>> >>>>>> Regards, >>>>>> Gbemisola Esho >>>>>> >>>>>> On Thu, 28 May 2026, 09:08 Darwin Da Costa, > wrote: >>>>>> >>>>>> > Dear PDWG, >>>>>> > >>>>>> > >>>>>> > We have received a new draft policy proposal - IPv6 as a criteria in IPv4 >>>>>> > Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. >>>>>> > The proposal contents are published at: >>>>>> > >>>>>> > >>>>>> > https://afrinic.net/afpub-2026-v6-001-draft01 >>>>>> > >>>>>> > >>>>>> > >>>>>> > We encourage you to take some time to go through the proposal contents and >>>>>> > provide feedback as follows: >>>>>> > >>>>>> > >>>>>> > a)Do you support or oppose the proposal? >>>>>> > >>>>>> > >>>>>> > b) If you oppose the proposal, state your reasons? >>>>>> > >>>>>> > >>>>>> > c) Is there anything in the proposal that is not clear? >>>>>> > >>>>>> > >>>>>> > d) What changes could be made to this proposal to make it more effective? >>>>>> > >>>>>> > >>>>>> > >>>>>> > Regards, >>>>>> > >>>>>> > Vincent Ngundi & Darwin Da Costa >>>>>> > >>>>>> > AFRINIC PDWG Co-Chairs >>>>>> > >>>>>> > _______________________________________________ >>>>>> > RPD mailing list >>>>>> > RPD at afrinic.net >>>>>> > https://lists.afrinic.net/mailman/listinfo/rpd >>>>>> > >>>>>> -------------- next part -------------- >>>>>> An HTML attachment was scrubbed... >>>>>> URL: >>>>>> >>>>>> ------------------------------ >>>>>> >>>>>> Subject: Digest Footer >>>>>> >>>>>> _______________________________________________ >>>>>> RPD mailing list >>>>>> RPD at afrinic.net >>>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>>> >>>>>> >>>>>> ------------------------------ >>>>>> >>>>>> End of RPD Digest, Vol 220, Issue 44 >>>>>> ************************************ >>>>> _______________________________________________ >>>>> RPD mailing list >>>>> RPD at afrinic.net >>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>>> >>>> ********************************************** >>>> IPv4 is over >>>> Are you ready for the new Internet ? >>>> http://www.theipv6company.com >>>> The IPv6 Company >>>> >>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From omo.oaiya at wacren.net Thu May 28 16:48:52 2026 From: omo.oaiya at wacren.net (Omo Oaiya) Date: Thu, 28 May 2026 17:48:52 +0100 Subject: [rpd] In Memoriam: Alan Barrett In-Reply-To: References: Message-ID: <889785CC-55BE-4ECC-A0E8-6493410A61DF@wacren.net> Very sorry to hear this. May Alan?s soul rest in peace. The few interactions I had with him left me with the impression of someone who genuinely tried to be fair, balanced, and constructive, even in difficult circumstances. My condolences to his family and all who worked closely with him. Omo > On 28 May 2026, at 13:42, Andrew Alston wrote: > > Dear friends and colleagues, > > As some of you will already be aware, it is with immense sadness that we confirm, on behalf of his wife Kerry and the family, the passing of Alan Barrett. Alan died on May 28th in Cape Town, South Africa, following a diagnosis of late-stage cancer about a month ago. We are sharing this notice so that the community has accurate information at a moment when Kerry and the family need space to grieve. > > Alan was a friend, a willing listener, and someone who always stepped up to help when called upon. His contributions to the African Internet ecosystem were second to none, and with his passing we lose not only a friend but a giant of the industry. > > In 1990, Alan helped establish the very first Internet connection to South African universities, and in 1993 he co-founded the country's first commercial Internet Service Provider. In 1997 he co-authored the proposal to create AfriNIC and subsequently served on the steering committee tasked with bringing it into being. Alan served on the AfriNIC board from 2004 to 2009 and was a member of the NRO NC from 2004 to 2014. In 2015 he was appointed CEO of AfriNIC, a role he held until 2019. > > Beyond Africa, he was a central participant in the IANA Stewardship Transition Coordination Group, and until his death served on the ICANN board on behalf of the Address Supporting Organisation. > > Alan will be sorely missed by the community, his relatives and his wife, Kerry. > > Kerry and the family ask for privacy at this time. We will be organising an online memorial in due course and will share details once they are available. > > Andrew Alston > Remco van Mook > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd Omo OAIYA Chief Strategy Officer/Directeur de la Strat?gie | WACREN m: +234 808 888 1571 , +233 536 269 987 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Thu May 28 17:06:03 2026 From: ben.roberts at afrinic.net (Ben Roberts) Date: Thu, 28 May 2026 20:06:03 +0300 Subject: [rpd] Promoting IPv6 adoption In-Reply-To: <4C6B314A-2A97-4A63-BFBB-348820BDFBA9@consulintel.es> References: <1B962FF9-82EF-4F8D-BF0A-838EABF2C5C1@consulintel.es> <54A4F147-0E45-441D-8D94-8B8346B129A2@afrinic.net> <4C6B314A-2A97-4A63-BFBB-348820BDFBA9@consulintel.es> Message-ID: <9CF7DDA4-9EBC-4052-A2E1-B5DBDC24EB60@afrinic.net> Jordi, You are ignoring the fact that people already have owned installed base of equipment that they bought pre owned and is now 10 to 15 year sold in their networks. When you come to the RPD meetings ar the AIS in Kanye I can take you to see the ancient equipments that are in use in the school compute labs of even the top schools in the country. Then you might appreciate the situation "kwa ground? as we say in Kenya. > On 28 May 2026, at 19:14, jordi.palet--- via RPD wrote: > > Hi Ben, > > Today there are sufficient OEM vendors for all kind of network devices that there is no need to buy ?pre owned? equipment. In Alibaba, you can find almost anything. I was in Shenzhen in March for the IETF meeting and visited a coupe of vendors, really impressive. Actually brought with me some 100G L3 switches, among other things, and just as a quick comparison, one of them will have costed me 4-5.000 euros in Spain, and I paid only 432 USD. Even more features than using a well known branded device. > > For ONU, CPE, etc., I?m not necessarily suggesting replacing all those already in customers in a single shot, clearly it could be phases across a number of months or years, and be part of marketing actions, such as ?we will provide a better wifi, you need to pay part of the cost?. > > As an example, you can find in Alibaba, without the need for buying thousands of units (of course cheaper if you do so, but basically because the shipping and customs clearance expenses go down per unit), ONU/CPE with Wifi, 4 Gig ports, for less than 12-15USD (you?ve thousands of options to choose). You can customize OpenWrt based on your own needs if a default OpenWrt doesn?t work for you. > > IPv6 (actually 464XLAT) deployment in 4/5G networks is the most easy one, so they don?t really have any excuse. May be they don?t have the expertise, but experienced consultants in the field, like ourselves (sorry not intended publicity, just showing reality), will be much cheaper an reliable that trusting any vendor or paying for their extra services. > > Regards, > Jordi > > @jordipalet > > >> El 28 may 2026, a las 17:37, Ben Roberts - AfriNIC escribi?: >> >> Jordi, >> Ok. I think we are mostly aligned. >> Other challenges we have of older ?pre owned? equipment in the provider WAN and very much in the enterprise LAN, as well as consumer devices and CPEs are also part of the challenge. That may be a blog for another day?. >> >> My list of shame though really is the lazy MNOs and their vendors that have deployed state of the art 5G core and not rolled out V6. This unfortunately means that most African Internet users don?t get served an IPv6. >> >> >> >> >> >> Sent from my iPhone >> >>> On 28 May 2026, at 18:28, jordi.palet--- via RPD wrote: >>> >>> ?Hi Ben, >>> >>> I don?t think I?ve suggested (it wasn?t my intent) that we need to exhaust IPv4 as fast as possible, on the other way around. >>> >>> Note that Afrinic recovered 3.000.000 of address, and I suggested in another proposal, to keep them under the same Soft Landing ?pool", not reverting back to allocation policies previous to Soft Landing. We entered in the last Soft Landing phase, let?s remain there to have a more controlled distribution of IPv4 resources, but together with IPv6. This is to ensure that both, newcomers, and people willing to do the transition to IPv6, still keep having IPv4 pools to be able to do that and avoid them a heavy work of renumbering existing customers to recover IPv4 addresses from other parts of the network. >>> >>> After reading your blog, I think we agree that deploying new networks with IPv6 is the way: >>> >>> ?The silver lining is that Africa's relative latecomer status to internet infrastructure could become an advantage: rather than managing the complex transition from IPv4 to IPv6, many African nations can build IPv6-native networks from the ground up. This leapfrogging potential, combined with mobile-first innovation and growing regional interconnection, suggests that today's IPv4 poverty need not determine tomorrow's digital destiny." >>> >>> This is true also for extending existing networks (so those requesting new IPv4 allocations or assignments). Unless you advocate for ?if you need to extend your network, better keep doing it with IPv4?? >>> >>> I just disagree that you mention a complex transition from IPv4 to IPv6. This is not longer true. Right now in both, mobile and wired networks, deploying 464XLAT is much much much much cheaper than IPv4 or even dual-stack (and in this case easier as well). Even in the case of enterprise networks, using IPv6-Mostly is also cheaper and easier. This is not an opinion, is technical and economical facts, based on deployment experience in hundreds of networks. >>> >>> I?m not saying turning your existing network to IPv6 overnight. A progressive deployment, which match each specific case needs to be planned. >>> >>> Regards, >>> Jordi >>> >>> @jordipalet >>> >>> >>>> El 28 may 2026, a las 16:55, Ben Roberts - AfriNIC escribi?: >>>> >>>> Jordi, >>>> I really have to disagree with this narrative that IPv4 needs to be exhausted as fast as possible because some regard it as legacy. >>>> >>>> I draw attention to my earlier blog on this matter where I advocate that the inequality gap is there. https://www.digitaleconomy.ke/post/ipv4-address-allocation-in-africa-are-you-above-or-below-the-ip-address-poverty-line >>>> >>>> For now those African countries that are catching up are going to need that base load allocations that they get under soft landing. >>>> >>>> Kind regards >>>> >>>> Ben >>>> >>>> Sent from my iPhone >>>> >>>>> On 28 May 2026, at 16:53, jordi.palet--- via RPD wrote: >>>>> >>>>> ?Hi Theresa, >>>>> >>>>> I think it needs to be understood that IPv4 is legacy and its main usage must be supporting transition. >>>>> >>>>> This has been said already many times, but I think we need to repeat it. >>>>> >>>>> It doesn?t make any sense to extend any existing network, or to deploy a new one, with IPv4-only. >>>>> >>>>> We are not saying it must be done with IPv6-only. In fact, the way is IPv6-Only with IPv4-as-a-Service, which basically means this is not a migration (we aren?t talking about removing IPv4 completely), it is transition and coexistence (there is no such concept as migration defined by IETF). >>>>> >>>>> The Soft Landing policy was designed having this in mind, it is clear reading 5.4 in the CPM, however we didn?t took measures at that time to make it happen. Now is the time. >>>>> >>>>> At that time the IPv6 deployment levels were very low globally, but at this time, Africa is overall, the bigger lagging region and no great signs that this is changing quickly. >>>>> >>>>> There is not today, any technical or even economical rationale to support IPv4 only. In fact across many deployments where I?ve participated in more than 150 countries, the result is that deploying IPv6 is much cheaper than IPv4 (IPv6 supporting equipment is not more expensive than IPv4, is the same price, and some cost are much lower, such as no need for CGN boxes). The problem is basically a lack of decision by executives, not technical people. >>>>> >>>>> We need to accommodate to the pace of each one, but a credible pace, not a pace like ?I get more IPv4, promise IPv6, but I?m lazy and don?t have now the time to do it". I think is fine that we accommodate the text in the new version so each one can say ?I realistically will grow 15% my network in the next year (that?s why I?m asking for IPv4 addresses), and I will do that with IPv6, so I commit to % IPv6 traffic for the 1st year, % next one and so on?. I?m happy to try as much as possible, with all your contributions, to accommodate the text in the next version, in such way that is not like you say having the cost and pressure unbalanced. >>>>> >>>>> Regards, >>>>> Jordi >>>>> >>>>> @jordipalet >>>>> >>>>> >>>>>> El 28 may 2026, a las 15:24, Theresa Dukumor escribi?: >>>>>> >>>>>> Dear PDWG, >>>>>> >>>>>> While I appreciate the goal of promoting IPv6 adoption, I have concerns about making it a condition for IPv4 allocations under Soft Landing. IPv4 is still the operating foundation for many in this region. Adding a mandate compounds cost and complexity without proven benefit, turning a resource policy into a migration mandate. The cost and pressure would fall on ordinary operators, while the main winners are likely registry governance bodies and large equipment vendors. I ask the PDWG to examine these consequences carefully. >>>>>> >>>>>> Regards, >>>>>> Theresa >>>>>> >>>>>> >>>>>> On Thu, May 28, 2026 at 9:23?AM > wrote: >>>>>>> Send RPD mailing list submissions to >>>>>>> rpd at afrinic.net >>>>>>> >>>>>>> To subscribe or unsubscribe via the World Wide Web, visit >>>>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>>>> or, via email, send a message with subject or body 'help' to >>>>>>> rpd-request at afrinic.net >>>>>>> >>>>>>> You can reach the person managing the list at >>>>>>> rpd-owner at afrinic.net >>>>>>> >>>>>>> When replying, please edit your Subject line so it is more specific >>>>>>> than "Re: Contents of RPD digest..." >>>>>>> >>>>>>> >>>>>>> Today's Topics: >>>>>>> >>>>>>> 1. IPv6 as a criteria in IPv4 Soft Landing >>>>>>> AFPUB-2026-v6-001-DRAFT01. (Darwin Da Costa) >>>>>>> 2. Re: Require newly created AS-SETs to have hierarchical names >>>>>>> AFPUB-2026-ASN-001-DRAFT01. (Jaco Kroon) >>>>>>> 3. AFRINIC Policy Compliance Dashboard ID >>>>>>> AFPUB-2026-GEN-002-DRAFT01. (Darwin Da Costa) >>>>>>> 4. Re: IPv6 as a criteria in IPv4 Soft Landing >>>>>>> AFPUB-2026-v6-001-DRAFT01. (Gbemisola Esho) >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> >>>>>>> Message: 1 >>>>>>> Date: Thu, 28 May 2026 10:05:07 +0200 >>>>>>> From: Darwin Da Costa > >>>>>>> To: rpd at afrinic.net >>>>>>> Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing >>>>>>> AFPUB-2026-v6-001-DRAFT01. >>>>>>> Message-ID: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18 at gmail.com > >>>>>>> Content-Type: text/plain; charset="us-ascii" >>>>>>> >>>>>>> Dear PDWG, >>>>>>> >>>>>>> We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>>>>>> >>>>>>> https://afrinic.net/afpub-2026-v6-001-draft01 >>>>>>> >>>>>>> >>>>>>> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>>>>>> >>>>>>> a)Do you support or oppose the proposal? >>>>>>> >>>>>>> b) If you oppose the proposal, state your reasons? >>>>>>> >>>>>>> c) Is there anything in the proposal that is not clear? >>>>>>> >>>>>>> d) What changes could be made to this proposal to make it more effective? >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Vincent Ngundi & Darwin Da Costa >>>>>>> AFRINIC PDWG Co-Chairs >>>>>>> >>>>>>> -------------- next part -------------- >>>>>>> An HTML attachment was scrubbed... >>>>>>> URL: >>>>>>> >>>>>>> ------------------------------ >>>>>>> >>>>>>> Message: 2 >>>>>>> Date: Thu, 28 May 2026 10:07:01 +0200 >>>>>>> From: Jaco Kroon > >>>>>>> To: James Bensley , "dacostadarwin at gmail.com " >>>>>>> >, "rpd at afrinic.net " > >>>>>>> Subject: Re: [rpd] Require newly created AS-SETs to have hierarchical >>>>>>> names AFPUB-2026-ASN-001-DRAFT01. >>>>>>> Message-ID: > >>>>>>> Content-Type: text/plain; charset=UTF-8; format=flowed >>>>>>> >>>>>>> Hi James, >>>>>>> >>>>>>> On 2026/05/28 09:54, James Bensley wrote: >>>>>>> >>>>>>> > Hi Jaco, >>>>>>> > >>>>>>> > Thank you for the support and your feedback. >>>>>>> > >>>>>>> > I wrote the original proposal. Regarding this comment: >>>>>>> > >>>>>>> > "The only thing that I found weird is that the second element has to be a name, why would "ASnum:ASnum2:AS-name" not be acceptable?" >>>>>>> > >>>>>>> > If you have a use case for that, then that could be added to the proposal. Do you have a use case/requirement for this? I think this usage is very rare, but if you have this use case, please speak up :) >>>>>>> >>>>>>> It's a hierarchy right, so what if I want to refer my customers by their >>>>>>> AS numbers? >>>>>>> >>>>>>> Eg, ASyyyy:ASxxxx:AS-set >>>>>>> >>>>>>> It's an arbitrary and in my opinion unneeded restriction which can be >>>>>>> removed.? The only restriction is that the first component has to be >>>>>>> ASnum where you have control over AS num.? The rest can be left to the >>>>>>> discretion of the ASnum admin surely? >>>>>>> >>>>>>> So just drop bullet three entirely. >>>>>>> >>>>>>> > >>>>>>> > >>>>>>> > Regarding this comment: >>>>>>> > >>>>>>> > "The purpose/function of "3. Other set types such as route sets are excluded." is unclear - everything else speaks specifically to AS-SET so why is this mention required?" >>>>>>> > >>>>>>> > Because route-sets can also support hierarchical names and in the past people have had the thought "well if we're making this change for AS-SETs let's also making it for Route-Sets whilst we're here" - but route-sets are extremely rarely used today and this just adds scope which I think isn't needed. So it was just about trying to stop that scope creep. >>>>>>> >>>>>>> I hear you. >>>>>>> >>>>>>> 7.8 as as whole specifically states "AS-SET" - not "Set Types", and >>>>>>> point 1 also makes it clears this refers specifically to AS-SET, which >>>>>>> means point 3 can be dropped without changing the intent/meaning of 7.8 >>>>>>> as a whole. >>>>>>> >>>>>>> Point 4 also really adds no value, that's an operational issue, not a >>>>>>> policy issue.? Definitely a valid point and something to be aware but >>>>>>> still operational, not policy. >>>>>>> >>>>>>> Exceptions to the policy may need to be permitted on a case by case >>>>>>> basis *if and only if* a non-hierarchical AS-SET has been accidentally >>>>>>> deleted to allow recreation.? IMHO these should require motivation to >>>>>>> have them restored from where they can then be edited again as per point 6. >>>>>>> >>>>>>> Kind regards, >>>>>>> Jaco >>>>>>> >>>>>>> > >>>>>>> > With kind regards, >>>>>>> > James Bensley (he/him) >>>>>>> > >>>>>>> > ________________________________________ >>>>>>> > From: Jaco Kroon > >>>>>>> > Sent: 21 May 2026 14:06 >>>>>>> > To: dacostadarwin at gmail.com >; rpd at afrinic.net > >>>>>>> > Subject: Re: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. >>>>>>> > >>>>>>> > Hi, >>>>>>> > >>>>>>> > Definitely in support. >>>>>>> > >>>>>>> > The only thing that I found weird is that the second element has to be a >>>>>>> > name, why would "ASnum:ASnum2:AS-name" not be acceptable? >>>>>>> > >>>>>>> > The purpose/function of "3. Other set types such as route sets are >>>>>>> > excluded." is unclear - everything else speaks specifically to AS-SET so >>>>>>> > why is this mention required? >>>>>>> > >>>>>>> > Kind regards, >>>>>>> > Jaco >>>>>>> > >>>>>>> > On 2026/05/20 19:37, dacostadarwin at gmail.com wrote: >>>>>>> > >>>>>>> >> Dear PDWG, >>>>>>> >> >>>>>>> >> We have received a new draft policy proposal - Require newly created AS-SETs to have hierarchical names, ID AFPUB-2026-ASN-001-DRAFT01 from author James Bensley. >>>>>>> >> >>>>>>> >> The proposal contents are published at: >>>>>>> >> https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft01 >>>>>>> >> >>>>>>> >> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>>>>>> >> >>>>>>> >> a) Do you support or oppose the proposal? >>>>>>> >> >>>>>>> >> b) If you oppose the proposal, state your reasons? >>>>>>> >> >>>>>>> >> c) Is there anything in the proposal that is not clear? >>>>>>> >> >>>>>>> >> d) What changes could be made to this proposal to make it more effective? >>>>>>> >> >>>>>>> >> Regards, >>>>>>> >> Vincent Ngundi & Darwin Da Costa >>>>>>> >> AFRINIC PDWG Co-Chairs >>>>>>> >> >>>>>>> >> >>>>>>> >> _______________________________________________ >>>>>>> >> RPD mailing list >>>>>>> >> RPD at afrinic.net >>>>>>> >> https://lists.afrinic.net/mailman/listinfo/rpd >>>>>>> > _______________________________________________ >>>>>>> > RPD mailing list >>>>>>> > RPD at afrinic.net >>>>>>> > https://lists.afrinic.net/mailman/listinfo/rpd >>>>>>> > [CompanySignature] >>>>>>> > Inter..link GmbH | Boxhagener Stra?e 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello at inter.link> | Web: inter.link> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------ >>>>>>> >>>>>>> Message: 3 >>>>>>> Date: Thu, 28 May 2026 10:07:31 +0200 >>>>>>> From: Darwin Da Costa > >>>>>>> To: rpd at afrinic.net >>>>>>> Subject: [rpd] AFRINIC Policy Compliance Dashboard ID >>>>>>> AFPUB-2026-GEN-002-DRAFT01. >>>>>>> Message-ID: > >>>>>>> Content-Type: text/plain; charset=us-ascii >>>>>>> >>>>>>> Dear PDWG, >>>>>>> >>>>>>> We have received a new draft policy proposal - AFRINIC Policy Compliance Dashboard ID AFPUB-2026-GEN-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>>>>>> >>>>>>> https://afrinic.net/afpub-2026-gen-002-draft01 >>>>>>> >>>>>>> >>>>>>> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>>>>>> >>>>>>> a) Do you support or oppose the proposal? >>>>>>> >>>>>>> b) If you oppose the proposal, state your reasons? >>>>>>> >>>>>>> c) Is there anything in the proposal that is not clear? >>>>>>> >>>>>>> d) What changes could be made to this proposal to make it more effective? >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Vincent Ngundi & Darwin Da Costa >>>>>>> AFRINIC PDWG Co-Chairs >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------ >>>>>>> >>>>>>> Message: 4 >>>>>>> Date: Thu, 28 May 2026 09:22:45 +0100 >>>>>>> From: Gbemisola Esho > >>>>>>> To: Darwin Da Costa > >>>>>>> Cc: rpd > >>>>>>> Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing >>>>>>> AFPUB-2026-v6-001-DRAFT01. >>>>>>> Message-ID: >>>>>>> > >>>>>>> Content-Type: text/plain; charset="utf-8" >>>>>>> >>>>>>> Acknowledged with thanks >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Gbemisola Esho >>>>>>> >>>>>>> On Thu, 28 May 2026, 09:08 Darwin Da Costa, > wrote: >>>>>>> >>>>>>> > Dear PDWG, >>>>>>> > >>>>>>> > >>>>>>> > We have received a new draft policy proposal - IPv6 as a criteria in IPv4 >>>>>>> > Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. >>>>>>> > The proposal contents are published at: >>>>>>> > >>>>>>> > >>>>>>> > https://afrinic.net/afpub-2026-v6-001-draft01 >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > We encourage you to take some time to go through the proposal contents and >>>>>>> > provide feedback as follows: >>>>>>> > >>>>>>> > >>>>>>> > a)Do you support or oppose the proposal? >>>>>>> > >>>>>>> > >>>>>>> > b) If you oppose the proposal, state your reasons? >>>>>>> > >>>>>>> > >>>>>>> > c) Is there anything in the proposal that is not clear? >>>>>>> > >>>>>>> > >>>>>>> > d) What changes could be made to this proposal to make it more effective? >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > Regards, >>>>>>> > >>>>>>> > Vincent Ngundi & Darwin Da Costa >>>>>>> > >>>>>>> > AFRINIC PDWG Co-Chairs >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > RPD mailing list >>>>>>> > RPD at afrinic.net >>>>>>> > https://lists.afrinic.net/mailman/listinfo/rpd >>>>>>> > >>>>>>> -------------- next part -------------- >>>>>>> An HTML attachment was scrubbed... >>>>>>> URL: >>>>>>> >>>>>>> ------------------------------ >>>>>>> >>>>>>> Subject: Digest Footer >>>>>>> >>>>>>> _______________________________________________ >>>>>>> RPD mailing list >>>>>>> RPD at afrinic.net >>>>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>>>> >>>>>>> >>>>>>> ------------------------------ >>>>>>> >>>>>>> End of RPD Digest, Vol 220, Issue 44 >>>>>>> ************************************ >>>>>> _______________________________________________ >>>>>> RPD mailing list >>>>>> RPD at afrinic.net >>>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>> >>>>> >>>>> ********************************************** >>>>> IPv4 is over >>>>> Are you ready for the new Internet ? >>>>> http://www.theipv6company.com >>>>> The IPv6 Company >>>>> >>>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >>>>> >>>>> _______________________________________________ >>>>> RPD mailing list >>>>> RPD at afrinic.net >>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> >>> ********************************************** >>> IPv4 is over >>> Are you ready for the new Internet ? >>> http://www.theipv6company.com >>> The IPv6 Company >>> >>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu May 28 17:33:03 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Thu, 28 May 2026 19:33:03 +0200 Subject: [rpd] Promoting IPv6 adoption In-Reply-To: <9CF7DDA4-9EBC-4052-A2E1-B5DBDC24EB60@afrinic.net> References: <1B962FF9-82EF-4F8D-BF0A-838EABF2C5C1@consulintel.es> <54A4F147-0E45-441D-8D94-8B8346B129A2@afrinic.net> <4C6B314A-2A97-4A63-BFBB-348820BDFBA9@consulintel.es> <9CF7DDA4-9EBC-4052-A2E1-B5DBDC24EB60@afrinic.net> Message-ID: <15A3F999-4785-4ECB-A4E3-7A48777F37AF@consulintel.es> Hi Ben, Fully ack and not ignoring it at all ? in many countries in APNIC and LACNIC, for example, I can find the same. However, the point is: If you ask for more IPv4 addresses, it means that somehow your network is growing up. I don?t think it will be savvy to keep purchasing those old boxes for that part of the network. Life is not perfect and my example is not perfect, for sure, but what I?m sure is that we can find a middle point. Remember that we are talking about keeping IPv4-as-a-Service. The ISP access link is IPv6-only, but the school, enterprise, or home network will still be dual-stack or even IPv4 only if the windows are 3.11 (I don't think will be the case, but just exaggerating so the point is clear). Saludos, Jordi @jordipalet > El 28 may 2026, a las 19:06, Ben Roberts escribi?: > > Jordi, > You are ignoring the fact that people already have owned installed base of equipment that they bought pre owned and is now 10 to 15 year sold in their networks. When you come to the RPD meetings ar the AIS in Kanye I can take you to see the ancient equipments that are in use in the school compute labs of even the top schools in the country. Then you might appreciate the situation "kwa ground? as we say in Kenya. > >> On 28 May 2026, at 19:14, jordi.palet--- via RPD wrote: >> >> Hi Ben, >> >> Today there are sufficient OEM vendors for all kind of network devices that there is no need to buy ?pre owned? equipment. In Alibaba, you can find almost anything. I was in Shenzhen in March for the IETF meeting and visited a coupe of vendors, really impressive. Actually brought with me some 100G L3 switches, among other things, and just as a quick comparison, one of them will have costed me 4-5.000 euros in Spain, and I paid only 432 USD. Even more features than using a well known branded device. >> >> For ONU, CPE, etc., I?m not necessarily suggesting replacing all those already in customers in a single shot, clearly it could be phases across a number of months or years, and be part of marketing actions, such as ?we will provide a better wifi, you need to pay part of the cost?. >> >> As an example, you can find in Alibaba, without the need for buying thousands of units (of course cheaper if you do so, but basically because the shipping and customs clearance expenses go down per unit), ONU/CPE with Wifi, 4 Gig ports, for less than 12-15USD (you?ve thousands of options to choose). You can customize OpenWrt based on your own needs if a default OpenWrt doesn?t work for you. >> >> IPv6 (actually 464XLAT) deployment in 4/5G networks is the most easy one, so they don?t really have any excuse. May be they don?t have the expertise, but experienced consultants in the field, like ourselves (sorry not intended publicity, just showing reality), will be much cheaper an reliable that trusting any vendor or paying for their extra services. >> >> Regards, >> Jordi >> >> @jordipalet >> >> >>> El 28 may 2026, a las 17:37, Ben Roberts - AfriNIC escribi?: >>> >>> Jordi, >>> Ok. I think we are mostly aligned. >>> Other challenges we have of older ?pre owned? equipment in the provider WAN and very much in the enterprise LAN, as well as consumer devices and CPEs are also part of the challenge. That may be a blog for another day?. >>> >>> My list of shame though really is the lazy MNOs and their vendors that have deployed state of the art 5G core and not rolled out V6. This unfortunately means that most African Internet users don?t get served an IPv6. >>> >>> >>> >>> >>> >>> Sent from my iPhone >>> >>>> On 28 May 2026, at 18:28, jordi.palet--- via RPD wrote: >>>> >>>> ?Hi Ben, >>>> >>>> I don?t think I?ve suggested (it wasn?t my intent) that we need to exhaust IPv4 as fast as possible, on the other way around. >>>> >>>> Note that Afrinic recovered 3.000.000 of address, and I suggested in another proposal, to keep them under the same Soft Landing ?pool", not reverting back to allocation policies previous to Soft Landing. We entered in the last Soft Landing phase, let?s remain there to have a more controlled distribution of IPv4 resources, but together with IPv6. This is to ensure that both, newcomers, and people willing to do the transition to IPv6, still keep having IPv4 pools to be able to do that and avoid them a heavy work of renumbering existing customers to recover IPv4 addresses from other parts of the network. >>>> >>>> After reading your blog, I think we agree that deploying new networks with IPv6 is the way: >>>> >>>> ?The silver lining is that Africa's relative latecomer status to internet infrastructure could become an advantage: rather than managing the complex transition from IPv4 to IPv6, many African nations can build IPv6-native networks from the ground up. This leapfrogging potential, combined with mobile-first innovation and growing regional interconnection, suggests that today's IPv4 poverty need not determine tomorrow's digital destiny." >>>> >>>> This is true also for extending existing networks (so those requesting new IPv4 allocations or assignments). Unless you advocate for ?if you need to extend your network, better keep doing it with IPv4?? >>>> >>>> I just disagree that you mention a complex transition from IPv4 to IPv6. This is not longer true. Right now in both, mobile and wired networks, deploying 464XLAT is much much much much cheaper than IPv4 or even dual-stack (and in this case easier as well). Even in the case of enterprise networks, using IPv6-Mostly is also cheaper and easier. This is not an opinion, is technical and economical facts, based on deployment experience in hundreds of networks. >>>> >>>> I?m not saying turning your existing network to IPv6 overnight. A progressive deployment, which match each specific case needs to be planned. >>>> >>>> Regards, >>>> Jordi >>>> >>>> @jordipalet >>>> >>>> >>>>> El 28 may 2026, a las 16:55, Ben Roberts - AfriNIC escribi?: >>>>> >>>>> Jordi, >>>>> I really have to disagree with this narrative that IPv4 needs to be exhausted as fast as possible because some regard it as legacy. >>>>> >>>>> I draw attention to my earlier blog on this matter where I advocate that the inequality gap is there. https://www.digitaleconomy.ke/post/ipv4-address-allocation-in-africa-are-you-above-or-below-the-ip-address-poverty-line >>>>> >>>>> For now those African countries that are catching up are going to need that base load allocations that they get under soft landing. >>>>> >>>>> Kind regards >>>>> >>>>> Ben >>>>> >>>>> Sent from my iPhone >>>>> >>>>>> On 28 May 2026, at 16:53, jordi.palet--- via RPD wrote: >>>>>> >>>>>> ?Hi Theresa, >>>>>> >>>>>> I think it needs to be understood that IPv4 is legacy and its main usage must be supporting transition. >>>>>> >>>>>> This has been said already many times, but I think we need to repeat it. >>>>>> >>>>>> It doesn?t make any sense to extend any existing network, or to deploy a new one, with IPv4-only. >>>>>> >>>>>> We are not saying it must be done with IPv6-only. In fact, the way is IPv6-Only with IPv4-as-a-Service, which basically means this is not a migration (we aren?t talking about removing IPv4 completely), it is transition and coexistence (there is no such concept as migration defined by IETF). >>>>>> >>>>>> The Soft Landing policy was designed having this in mind, it is clear reading 5.4 in the CPM, however we didn?t took measures at that time to make it happen. Now is the time. >>>>>> >>>>>> At that time the IPv6 deployment levels were very low globally, but at this time, Africa is overall, the bigger lagging region and no great signs that this is changing quickly. >>>>>> >>>>>> There is not today, any technical or even economical rationale to support IPv4 only. In fact across many deployments where I?ve participated in more than 150 countries, the result is that deploying IPv6 is much cheaper than IPv4 (IPv6 supporting equipment is not more expensive than IPv4, is the same price, and some cost are much lower, such as no need for CGN boxes). The problem is basically a lack of decision by executives, not technical people. >>>>>> >>>>>> We need to accommodate to the pace of each one, but a credible pace, not a pace like ?I get more IPv4, promise IPv6, but I?m lazy and don?t have now the time to do it". I think is fine that we accommodate the text in the new version so each one can say ?I realistically will grow 15% my network in the next year (that?s why I?m asking for IPv4 addresses), and I will do that with IPv6, so I commit to % IPv6 traffic for the 1st year, % next one and so on?. I?m happy to try as much as possible, with all your contributions, to accommodate the text in the next version, in such way that is not like you say having the cost and pressure unbalanced. >>>>>> >>>>>> Regards, >>>>>> Jordi >>>>>> >>>>>> @jordipalet >>>>>> >>>>>> >>>>>>> El 28 may 2026, a las 15:24, Theresa Dukumor escribi?: >>>>>>> >>>>>>> Dear PDWG, >>>>>>> >>>>>>> While I appreciate the goal of promoting IPv6 adoption, I have concerns about making it a condition for IPv4 allocations under Soft Landing. IPv4 is still the operating foundation for many in this region. Adding a mandate compounds cost and complexity without proven benefit, turning a resource policy into a migration mandate. The cost and pressure would fall on ordinary operators, while the main winners are likely registry governance bodies and large equipment vendors. I ask the PDWG to examine these consequences carefully. >>>>>>> >>>>>>> Regards, >>>>>>> Theresa >>>>>>> >>>>>>> >>>>>>> On Thu, May 28, 2026 at 9:23?AM > wrote: >>>>>>>> Send RPD mailing list submissions to >>>>>>>> rpd at afrinic.net >>>>>>>> >>>>>>>> To subscribe or unsubscribe via the World Wide Web, visit >>>>>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>>>>> or, via email, send a message with subject or body 'help' to >>>>>>>> rpd-request at afrinic.net >>>>>>>> >>>>>>>> You can reach the person managing the list at >>>>>>>> rpd-owner at afrinic.net >>>>>>>> >>>>>>>> When replying, please edit your Subject line so it is more specific >>>>>>>> than "Re: Contents of RPD digest..." >>>>>>>> >>>>>>>> >>>>>>>> Today's Topics: >>>>>>>> >>>>>>>> 1. IPv6 as a criteria in IPv4 Soft Landing >>>>>>>> AFPUB-2026-v6-001-DRAFT01. (Darwin Da Costa) >>>>>>>> 2. Re: Require newly created AS-SETs to have hierarchical names >>>>>>>> AFPUB-2026-ASN-001-DRAFT01. (Jaco Kroon) >>>>>>>> 3. AFRINIC Policy Compliance Dashboard ID >>>>>>>> AFPUB-2026-GEN-002-DRAFT01. (Darwin Da Costa) >>>>>>>> 4. Re: IPv6 as a criteria in IPv4 Soft Landing >>>>>>>> AFPUB-2026-v6-001-DRAFT01. (Gbemisola Esho) >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------------------------------------- >>>>>>>> >>>>>>>> Message: 1 >>>>>>>> Date: Thu, 28 May 2026 10:05:07 +0200 >>>>>>>> From: Darwin Da Costa > >>>>>>>> To: rpd at afrinic.net >>>>>>>> Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing >>>>>>>> AFPUB-2026-v6-001-DRAFT01. >>>>>>>> Message-ID: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18 at gmail.com > >>>>>>>> Content-Type: text/plain; charset="us-ascii" >>>>>>>> >>>>>>>> Dear PDWG, >>>>>>>> >>>>>>>> We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>>>>>>> >>>>>>>> https://afrinic.net/afpub-2026-v6-001-draft01 >>>>>>>> >>>>>>>> >>>>>>>> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>>>>>>> >>>>>>>> a)Do you support or oppose the proposal? >>>>>>>> >>>>>>>> b) If you oppose the proposal, state your reasons? >>>>>>>> >>>>>>>> c) Is there anything in the proposal that is not clear? >>>>>>>> >>>>>>>> d) What changes could be made to this proposal to make it more effective? >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Vincent Ngundi & Darwin Da Costa >>>>>>>> AFRINIC PDWG Co-Chairs >>>>>>>> >>>>>>>> -------------- next part -------------- >>>>>>>> An HTML attachment was scrubbed... >>>>>>>> URL: >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> >>>>>>>> Message: 2 >>>>>>>> Date: Thu, 28 May 2026 10:07:01 +0200 >>>>>>>> From: Jaco Kroon > >>>>>>>> To: James Bensley , "dacostadarwin at gmail.com " >>>>>>>> >, "rpd at afrinic.net " > >>>>>>>> Subject: Re: [rpd] Require newly created AS-SETs to have hierarchical >>>>>>>> names AFPUB-2026-ASN-001-DRAFT01. >>>>>>>> Message-ID: > >>>>>>>> Content-Type: text/plain; charset=UTF-8; format=flowed >>>>>>>> >>>>>>>> Hi James, >>>>>>>> >>>>>>>> On 2026/05/28 09:54, James Bensley wrote: >>>>>>>> >>>>>>>> > Hi Jaco, >>>>>>>> > >>>>>>>> > Thank you for the support and your feedback. >>>>>>>> > >>>>>>>> > I wrote the original proposal. Regarding this comment: >>>>>>>> > >>>>>>>> > "The only thing that I found weird is that the second element has to be a name, why would "ASnum:ASnum2:AS-name" not be acceptable?" >>>>>>>> > >>>>>>>> > If you have a use case for that, then that could be added to the proposal. Do you have a use case/requirement for this? I think this usage is very rare, but if you have this use case, please speak up :) >>>>>>>> >>>>>>>> It's a hierarchy right, so what if I want to refer my customers by their >>>>>>>> AS numbers? >>>>>>>> >>>>>>>> Eg, ASyyyy:ASxxxx:AS-set >>>>>>>> >>>>>>>> It's an arbitrary and in my opinion unneeded restriction which can be >>>>>>>> removed.? The only restriction is that the first component has to be >>>>>>>> ASnum where you have control over AS num.? The rest can be left to the >>>>>>>> discretion of the ASnum admin surely? >>>>>>>> >>>>>>>> So just drop bullet three entirely. >>>>>>>> >>>>>>>> > >>>>>>>> > >>>>>>>> > Regarding this comment: >>>>>>>> > >>>>>>>> > "The purpose/function of "3. Other set types such as route sets are excluded." is unclear - everything else speaks specifically to AS-SET so why is this mention required?" >>>>>>>> > >>>>>>>> > Because route-sets can also support hierarchical names and in the past people have had the thought "well if we're making this change for AS-SETs let's also making it for Route-Sets whilst we're here" - but route-sets are extremely rarely used today and this just adds scope which I think isn't needed. So it was just about trying to stop that scope creep. >>>>>>>> >>>>>>>> I hear you. >>>>>>>> >>>>>>>> 7.8 as as whole specifically states "AS-SET" - not "Set Types", and >>>>>>>> point 1 also makes it clears this refers specifically to AS-SET, which >>>>>>>> means point 3 can be dropped without changing the intent/meaning of 7.8 >>>>>>>> as a whole. >>>>>>>> >>>>>>>> Point 4 also really adds no value, that's an operational issue, not a >>>>>>>> policy issue.? Definitely a valid point and something to be aware but >>>>>>>> still operational, not policy. >>>>>>>> >>>>>>>> Exceptions to the policy may need to be permitted on a case by case >>>>>>>> basis *if and only if* a non-hierarchical AS-SET has been accidentally >>>>>>>> deleted to allow recreation.? IMHO these should require motivation to >>>>>>>> have them restored from where they can then be edited again as per point 6. >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> Jaco >>>>>>>> >>>>>>>> > >>>>>>>> > With kind regards, >>>>>>>> > James Bensley (he/him) >>>>>>>> > >>>>>>>> > ________________________________________ >>>>>>>> > From: Jaco Kroon > >>>>>>>> > Sent: 21 May 2026 14:06 >>>>>>>> > To: dacostadarwin at gmail.com >; rpd at afrinic.net > >>>>>>>> > Subject: Re: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. >>>>>>>> > >>>>>>>> > Hi, >>>>>>>> > >>>>>>>> > Definitely in support. >>>>>>>> > >>>>>>>> > The only thing that I found weird is that the second element has to be a >>>>>>>> > name, why would "ASnum:ASnum2:AS-name" not be acceptable? >>>>>>>> > >>>>>>>> > The purpose/function of "3. Other set types such as route sets are >>>>>>>> > excluded." is unclear - everything else speaks specifically to AS-SET so >>>>>>>> > why is this mention required? >>>>>>>> > >>>>>>>> > Kind regards, >>>>>>>> > Jaco >>>>>>>> > >>>>>>>> > On 2026/05/20 19:37, dacostadarwin at gmail.com wrote: >>>>>>>> > >>>>>>>> >> Dear PDWG, >>>>>>>> >> >>>>>>>> >> We have received a new draft policy proposal - Require newly created AS-SETs to have hierarchical names, ID AFPUB-2026-ASN-001-DRAFT01 from author James Bensley. >>>>>>>> >> >>>>>>>> >> The proposal contents are published at: >>>>>>>> >> https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft01 >>>>>>>> >> >>>>>>>> >> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>>>>>>> >> >>>>>>>> >> a) Do you support or oppose the proposal? >>>>>>>> >> >>>>>>>> >> b) If you oppose the proposal, state your reasons? >>>>>>>> >> >>>>>>>> >> c) Is there anything in the proposal that is not clear? >>>>>>>> >> >>>>>>>> >> d) What changes could be made to this proposal to make it more effective? >>>>>>>> >> >>>>>>>> >> Regards, >>>>>>>> >> Vincent Ngundi & Darwin Da Costa >>>>>>>> >> AFRINIC PDWG Co-Chairs >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> _______________________________________________ >>>>>>>> >> RPD mailing list >>>>>>>> >> RPD at afrinic.net >>>>>>>> >> https://lists.afrinic.net/mailman/listinfo/rpd >>>>>>>> > _______________________________________________ >>>>>>>> > RPD mailing list >>>>>>>> > RPD at afrinic.net >>>>>>>> > https://lists.afrinic.net/mailman/listinfo/rpd >>>>>>>> > [CompanySignature] >>>>>>>> > Inter..link GmbH | Boxhagener Stra?e 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello at inter.link> | Web: inter.link> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> >>>>>>>> Message: 3 >>>>>>>> Date: Thu, 28 May 2026 10:07:31 +0200 >>>>>>>> From: Darwin Da Costa > >>>>>>>> To: rpd at afrinic.net >>>>>>>> Subject: [rpd] AFRINIC Policy Compliance Dashboard ID >>>>>>>> AFPUB-2026-GEN-002-DRAFT01. >>>>>>>> Message-ID: > >>>>>>>> Content-Type: text/plain; charset=us-ascii >>>>>>>> >>>>>>>> Dear PDWG, >>>>>>>> >>>>>>>> We have received a new draft policy proposal - AFRINIC Policy Compliance Dashboard ID AFPUB-2026-GEN-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>>>>>>> >>>>>>>> https://afrinic.net/afpub-2026-gen-002-draft01 >>>>>>>> >>>>>>>> >>>>>>>> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>>>>>>> >>>>>>>> a) Do you support or oppose the proposal? >>>>>>>> >>>>>>>> b) If you oppose the proposal, state your reasons? >>>>>>>> >>>>>>>> c) Is there anything in the proposal that is not clear? >>>>>>>> >>>>>>>> d) What changes could be made to this proposal to make it more effective? >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Vincent Ngundi & Darwin Da Costa >>>>>>>> AFRINIC PDWG Co-Chairs >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> >>>>>>>> Message: 4 >>>>>>>> Date: Thu, 28 May 2026 09:22:45 +0100 >>>>>>>> From: Gbemisola Esho > >>>>>>>> To: Darwin Da Costa > >>>>>>>> Cc: rpd > >>>>>>>> Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing >>>>>>>> AFPUB-2026-v6-001-DRAFT01. >>>>>>>> Message-ID: >>>>>>>> > >>>>>>>> Content-Type: text/plain; charset="utf-8" >>>>>>>> >>>>>>>> Acknowledged with thanks >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Gbemisola Esho >>>>>>>> >>>>>>>> On Thu, 28 May 2026, 09:08 Darwin Da Costa, > wrote: >>>>>>>> >>>>>>>> > Dear PDWG, >>>>>>>> > >>>>>>>> > >>>>>>>> > We have received a new draft policy proposal - IPv6 as a criteria in IPv4 >>>>>>>> > Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. >>>>>>>> > The proposal contents are published at: >>>>>>>> > >>>>>>>> > >>>>>>>> > https://afrinic.net/afpub-2026-v6-001-draft01 >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > We encourage you to take some time to go through the proposal contents and >>>>>>>> > provide feedback as follows: >>>>>>>> > >>>>>>>> > >>>>>>>> > a)Do you support or oppose the proposal? >>>>>>>> > >>>>>>>> > >>>>>>>> > b) If you oppose the proposal, state your reasons? >>>>>>>> > >>>>>>>> > >>>>>>>> > c) Is there anything in the proposal that is not clear? >>>>>>>> > >>>>>>>> > >>>>>>>> > d) What changes could be made to this proposal to make it more effective? >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > Regards, >>>>>>>> > >>>>>>>> > Vincent Ngundi & Darwin Da Costa >>>>>>>> > >>>>>>>> > AFRINIC PDWG Co-Chairs >>>>>>>> > >>>>>>>> > _______________________________________________ >>>>>>>> > RPD mailing list >>>>>>>> > RPD at afrinic.net >>>>>>>> > https://lists.afrinic.net/mailman/listinfo/rpd >>>>>>>> > >>>>>>>> -------------- next part -------------- >>>>>>>> An HTML attachment was scrubbed... >>>>>>>> URL: >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> >>>>>>>> Subject: Digest Footer >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> RPD mailing list >>>>>>>> RPD at afrinic.net >>>>>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> >>>>>>>> End of RPD Digest, Vol 220, Issue 44 >>>>>>>> ************************************ >>>>>>> _______________________________________________ >>>>>>> RPD mailing list >>>>>>> RPD at afrinic.net >>>>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>>> >>>>>> >>>>>> ********************************************** >>>>>> IPv4 is over >>>>>> Are you ready for the new Internet ? >>>>>> http://www.theipv6company.com >>>>>> The IPv6 Company >>>>>> >>>>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >>>>>> >>>>>> _______________________________________________ >>>>>> RPD mailing list >>>>>> RPD at afrinic.net >>>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>>> >>>> ********************************************** >>>> IPv4 is over >>>> Are you ready for the new Internet ? >>>> http://www.theipv6company.com >>>> The IPv6 Company >>>> >>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lawrence at microboss.org Fri May 29 00:33:37 2026 From: lawrence at microboss.org (Lawrence O. Olawale-Roberts) Date: Fri, 29 May 2026 00:33:37 +0000 Subject: [rpd] In Memoriam: Alan Barrett In-Reply-To: <889785CC-55BE-4ECC-A0E8-6493410A61DF@wacren.net> References: <889785CC-55BE-4ECC-A0E8-6493410A61DF@wacren.net> Message-ID: Such Sad news this is. May his gentle soul rest in Peace. Africa lost a great mind, one who was careful with all he had to say on a given subject or topic of discussion. His deep roots in the development of Africa's digital infrastructure would be missed and so will his calm demenor and spirt. My prayers are with his family and hope the find the courage to blaze on even in the face of this loss. Adieu Alan B. Lawrence ----- [Image] [Image] Lawrence Olawale-Roberts Global President & Managing Director Mobile: +234 8070892705, (0)8056 3333 97 Lawrence at microboss.org [Image] [Image] ?collaboration to enhance communication. [Image] https://www.microboss.org | [Image] [Image] [Image] [Image] [Image] This e-mail and any attachments are confidential and may be protected by legal, professional or other privilege. If you are not the intended recipient, you should not store it, copy it, re-transmit it, use it or disclose its contents, but should return it to the sender immediately and delete your copy from your system. The views expressed are those of the sender and his company MicroBoss. Kindly note that whilst we scan all e-mails for viruses, we cannot guarantee that any e-mail is virus-free. | Do consider the environment before printing this email. ________________________________ From: Omo Oaiya via RPD Sent: Thursday, May 28, 2026 5:48:52 PM To: Andrew Alston Cc: RPD Subject: Re: [rpd] In Memoriam: Alan Barrett Very sorry to hear this. May Alan?s soul rest in peace. The few interactions I had with him left me with the impression of someone who genuinely tried to be fair, balanced, and constructive, even in difficult circumstances. My condolences to his family and all who worked closely with him. Omo On 28 May 2026, at 13:42, Andrew Alston wrote: Dear friends and colleagues, As some of you will already be aware, it is with immense sadness that we confirm, on behalf of his wife Kerry and the family, the passing of Alan Barrett. Alan died on May 28th in Cape Town, South Africa, following a diagnosis of late-stage cancer about a month ago. We are sharing this notice so that the community has accurate information at a moment when Kerry and the family need space to grieve. Alan was a friend, a willing listener, and someone who always stepped up to help when called upon. His contributions to the African Internet ecosystem were second to none, and with his passing we lose not only a friend but a giant of the industry. In 1990, Alan helped establish the very first Internet connection to South African universities, and in 1993 he co-founded the country's first commercial Internet Service Provider. In 1997 he co-authored the proposal to create AfriNIC and subsequently served on the steering committee tasked with bringing it into being. Alan served on the AfriNIC board from 2004 to 2009 and was a member of the NRO NC from 2004 to 2014. In 2015 he was appointed CEO of AfriNIC, a role he held until 2019. Beyond Africa, he was a central participant in the IANA Stewardship Transition Coordination Group, and until his death served on the ICANN board on behalf of the Address Supporting Organisation. Alan will be sorely missed by the community, his relatives and his wife, Kerry. Kerry and the family ask for privacy at this time. We will be organising an online memorial in due course and will share details once they are available. Andrew Alston Remco van Mook _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd Omo OAIYA Chief Strategy Officer/Directeur de la Strat?gie | WACREN m: +234 808 888 1571 , +233 536 269 987 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikeshbs at outlook.com Fri May 29 05:04:23 2026 From: nikeshbs at outlook.com (Nikesh B. Simmandree) Date: Fri, 29 May 2026 05:04:23 +0000 Subject: [rpd] In Memoriam: Alan Barrett In-Reply-To: References: Message-ID: Very sad news indeed, got the opportunity to work with him at AFRINIC. Rest In Peace Alan. My deepest condolences. Life is really short ! Best Regards, Nikesh B. Simmandree +230-5-907-3413 nikeshbs at outlook.com This message and its attachments are intended only for the person or entity to which it is addressed and are strictly confidential. If you have received this in error, please delete it from any devices after having informed the sender. ________________________________ From: Seun Ojedeji Sent: Thursday, May 28, 2026 5:15 PM To: Andrew Alston Cc: RPD Subject: Re: [rpd] In Memoriam: Alan Barrett Very sad news: Africa has lost one of the founding fathers of AFRINIC, a great technocrat and a dear friend of the community. He will be dearly missed, may his soul rest in peace! Regards On Thu, 28 May 2026 at 07:42, Andrew Alston > wrote: Dear friends and colleagues, As some of you will already be aware, it is with immense sadness that we confirm, on behalf of his wife Kerry and the family, the passing of Alan Barrett. Alan died on May 28th in Cape Town, South Africa, following a diagnosis of late-stage cancer about a month ago. We are sharing this notice so that the community has accurate information at a moment when Kerry and the family need space to grieve. Alan was a friend, a willing listener, and someone who always stepped up to help when called upon. His contributions to the African Internet ecosystem were second to none, and with his passing we lose not only a friend but a giant of the industry. In 1990, Alan helped establish the very first Internet connection to South African universities, and in 1993 he co-founded the country's first commercial Internet Service Provider. In 1997 he co-authored the proposal to create AfriNIC and subsequently served on the steering committee tasked with bringing it into being. Alan served on the AfriNIC board from 2004 to 2009 and was a member of the NRO NC from 2004 to 2014. In 2015 he was appointed CEO of AfriNIC, a role he held until 2019. Beyond Africa, he was a central participant in the IANA Stewardship Transition Coordination Group, and until his death served on the ICANN board on behalf of the Address Supporting Organisation. Alan will be sorely missed by the community, his relatives and his wife, Kerry. Kerry and the family ask for privacy at this time. We will be organising an online memorial in due course and will share details once they are available. Andrew Alston Remco van Mook _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd -- ------------------------------------------------------------------------ Seun Ojedeji, Bringing another down does not take you up - think about your action! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dacostadarwin at gmail.com Fri May 29 05:57:29 2026 From: dacostadarwin at gmail.com (dacostadarwin at gmail.com) Date: Fri, 29 May 2026 07:57:29 +0200 Subject: [rpd] In Memoriam: Alan Barrett In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From oloyede.aa at unilorin.edu.ng Fri May 29 08:00:51 2026 From: oloyede.aa at unilorin.edu.ng (Abdulkarim Oloyede) Date: Fri, 29 May 2026 09:00:51 +0100 Subject: [rpd] In Memoriam: Alan Barrett In-Reply-To: References: Message-ID: This is shocking. My deepest condolences to his Family. May his soul rest in peace. Prof. Abdulkarim A. Oloyede *Professor of Wireless Telecommunications * *Director, Centre for Research Development and In-House Training (CREDIT)* *University of Ilorin, Ilorin* *Nigeria* On Fri, May 29, 2026 at 8:01?AM dacostadarwin at gmail.com < dacostadarwin at gmail.com> wrote: > My deepest condolences to the entire family! Rest in peace Alan ????. > > > On 29 May 2026, at 07:07, Nikesh B. Simmandree > wrote: > > ? > Very sad news indeed, got the opportunity to work with him at AFRINIC. > Rest In Peace Alan. My deepest condolences. Life is really short ! > > Best Regards, > Nikesh B. Simmandree > +230-5-907-3413 > nikeshbs at outlook.com > > This message and its attachments are intended only for the person or > entity to which it is addressed and are strictly confidential. If you have > received this in error, please delete it from any devices after having > informed the sender. > ------------------------------ > *From:* Seun Ojedeji > *Sent:* Thursday, May 28, 2026 5:15 PM > *To:* Andrew Alston > *Cc:* RPD > *Subject:* Re: [rpd] In Memoriam: Alan Barrett > > Very sad news: Africa has lost one of the founding fathers of AFRINIC, a > great technocrat and a dear friend of the community. He will be dearly > missed, may his soul rest in peace! > > Regards > > On Thu, 28 May 2026 at 07:42, Andrew Alston wrote: > > Dear friends and colleagues, > > As some of you will already be aware, it is with immense sadness that we > confirm, on behalf of his wife Kerry and the family, the passing of Alan > Barrett. Alan died on May 28th in Cape Town, South Africa, following a > diagnosis of late-stage cancer about a month ago. We are sharing this > notice so that the community has accurate information at a moment when > Kerry and the family need space to grieve. > > Alan was a friend, a willing listener, and someone who always stepped up > to help when called upon. His contributions to the African Internet > ecosystem were second to none, and with his passing we lose not only a > friend but a giant of the industry. > > In 1990, Alan helped establish the very first Internet connection to South > African universities, and in 1993 he co-founded the country's first > commercial Internet Service Provider. In 1997 he co-authored the proposal > to create AfriNIC and subsequently served on the steering committee tasked > with bringing it into being. Alan served on the AfriNIC board from 2004 to > 2009 and was a member of the NRO NC from 2004 to 2014. In 2015 he was > appointed CEO of AfriNIC, a role he held until 2019. > > Beyond Africa, he was a central participant in the IANA Stewardship > Transition Coordination Group, and until his death served on the ICANN > board on behalf of the Address Supporting Organisation. > > Alan will be sorely missed by the community, his relatives and his wife, > Kerry. > > Kerry and the family ask for privacy at this time. We will be organising > an online memorial in due course and will share details once they are > available. > > Andrew Alston > Remco van Mook > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > > -- > ------------------------------------------------------------------------ > > > *Seun Ojedeji, * > > Bringing another down does not take you up - think about your action! > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -- Website ,?Weekly Bulletin ?UGPortal PGPortal ?HelpDesk -------------- next part -------------- An HTML attachment was scrubbed... URL: From akin.akinfenwa at uniosun.edu.ng Fri May 29 08:31:49 2026 From: akin.akinfenwa at uniosun.edu.ng (Timothy Ola Akinfenwa) Date: Fri, 29 May 2026 09:31:49 +0100 Subject: [rpd] In Memoriam: Alan Barrett In-Reply-To: References: Message-ID: Ha! This is so shocking to read. I met Alan during my earliest AfNOG days in 2013, he was such a kind, gentle and very humble personality. You would hardly believe he carried so much aura and wisdom with his unique and simple lifestyle. A mighty *iroko *tree has indeed fallen in the forest of Africa's internet ecosystem. May God Almighty console the family and friends, and give them the fortitude to bear this great loss. Rest in power, Alan! <.a/> "Be happy with what you have and are, be generous with both, and you won't have to hunt for happiness." ~ William E. Gladstone *CONFIDENTIALITY NOTICE: * *The contents of this email message and any attachments are intended solely for the addressee(s) and may contain confidential and/or privileged information and may be legally protected from disclosure. If you are not the intended recipient of this message or their agent, or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited.* On Thu, May 28, 2026 at 1:46?PM Andrew Alston wrote: > Dear friends and colleagues, > > As some of you will already be aware, it is with immense sadness that we > confirm, on behalf of his wife Kerry and the family, the passing of Alan > Barrett. Alan died on May 28th in Cape Town, South Africa, following a > diagnosis of late-stage cancer about a month ago. We are sharing this > notice so that the community has accurate information at a moment when > Kerry and the family need space to grieve. > > Alan was a friend, a willing listener, and someone who always stepped up > to help when called upon. His contributions to the African Internet > ecosystem were second to none, and with his passing we lose not only a > friend but a giant of the industry. > > In 1990, Alan helped establish the very first Internet connection to South > African universities, and in 1993 he co-founded the country's first > commercial Internet Service Provider. In 1997 he co-authored the proposal > to create AfriNIC and subsequently served on the steering committee tasked > with bringing it into being. Alan served on the AfriNIC board from 2004 to > 2009 and was a member of the NRO NC from 2004 to 2014. In 2015 he was > appointed CEO of AfriNIC, a role he held until 2019. > > Beyond Africa, he was a central participant in the IANA Stewardship > Transition Coordination Group, and until his death served on the ICANN > board on behalf of the Address Supporting Organisation. > > Alan will be sorely missed by the community, his relatives and his wife, > Kerry. > > Kerry and the family ask for privacy at this time. We will be organising > an online memorial in due course and will share details once they are > available. > > Andrew Alston > Remco van Mook > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From isatou.jah at qcell.gm Fri May 29 09:55:46 2026 From: isatou.jah at qcell.gm (Isatou Jah) Date: Fri, 29 May 2026 09:55:46 +0000 Subject: [rpd] In Memoriam: Alan Barrett In-Reply-To: References: , Message-ID: An HTML attachment was scrubbed... URL: From comms at afrinic.net Fri May 29 14:53:50 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Fri, 29 May 2026 18:53:50 +0400 Subject: [rpd] AFRINIC Elections 2026: Call for Candidates Extended to 8 June 2026. Message-ID: <44DDEA08-7A66-418F-821A-8021B46F381D@afrinic.net> [Version en fran?ais au bas] Dear Colleagues, The Nomination Committee 2026 hereby informs the AFRINIC Membership and broader Internet Community that the deadline for submission of nominations for the AFRINIC Elections 2026 has been extended to 08 June 2026. The extension applies to the following positions: Three (3) seats for the Governance Committee Two (2) seats for the NRO NC / ASO AC community representatives Two (2) PDP Co-Chairs The Nomination Committee encourages qualified candidates from all AFRINIC sub-regions to submit their nominations and welcomes diversity in representation, including gender and linguistic diversity. Nomination forms and election information are available: Governance Committee:https://forms.afrinic.net/governance-committee-election-2026 NRO NC / ASO AC: https://forms.afrinic.net/nro-nc-aso-ac-election-2026 PDP Co-Chairs: https://forms.afrinic.net/pdp-co-chairs-selection-2026 Additional information and the Election Guidelines 2026 at: https://election.afrinic.net/election-guideline-2026, Kind Regards, AFRINIC Communication ?????????????????????? ?lections AFRINIC 2026 : Prolongation de l'appel ? candidatures Chers coll?gues, Le comit? de nomination 2026 informe les membres d'AFRINIC et la communaut? Internet que la date limite de soumission des candidatures pour les ?lections AFRINIC 2026 a ?t? prolong?e au 08 juin 2026. Cette prolongation s'applique aux postes suivants : Trois (3) si?ges au sein du comit? de gouvernance Deux (2) si?ges pour les repr?sentants de la communaut? NRO NC / ASO AC Deux (2) copr?sidents du PDP Les formulaires de candidature et les informations relatives aux ?lections restent disponibles aux adresses suivantes: Comit? de gouvernance : https://forms.afrinic.net/governance-committee-election-2026 NRO NC / ASO AC : https://forms.afrinic.net/nro-nc-aso-ac-election-2026 Copr?sidents du PDP : https://forms.afrinic.net/pdp-co-chairs-selection-2026 Pour toute information compl?mentaire ainsi que pour consulter les directives ?lectorales 2026, veuillez visiter : https://election.afrinic.net/election-guideline-2026 -------------- next part -------------- An HTML attachment was scrubbed... URL: From benson_muite at emailplus.org Sat May 30 03:51:28 2026 From: benson_muite at emailplus.org (Benson Muite) Date: Sat, 30 May 2026 06:51:28 +0300 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> <26787741-b549-41e9-a27e-abf062fe6dac@uls.co.za> <2B015435-ED04-45E5-95BA-807D1D62092D@consulintel.es> Message-ID: <87y0h1v9kv.fsf@emailplus.org> "jordi.palet--- via RPD" writes: Hi Jordi, Encouraging more IPv6 adoption is helpful. MNOs sharing IPv4 addresses leads to problematic internet access, at least some IPs I have received temporarily have been listed at: https://www.dronebl.org/ That being said, sharing an IPv4 address behind a NAT gives some level of privacy which may require more configuration effort if IPv6 is used. > Hi Dorothy, > > I need to make this clear again. There is no such thing as migration, we don?t turn-off IPv4 completely. Anyone can keep using it. What we are doing is to ensure with IPv6-only with IPv4-as-a-Service, that both protocols coexist, so we do an ordered transition, at the pace of everyone. > > As faster you move to IPv6, as cheaper is your CapEx and OpEx, it is up to each operator. > There is an initial setup and training cost. For hardware, while one can buy routers from other places outside Africa, some of the countries mentioned as leading in the post: https://www.digitaleconomy.ke/post/ipv4-address-allocation-in-africa-are-you-above-or-below-the-ip-address-poverty-line also have growing electronics industries, unfortunately none are fabricating chips, but PCB assembly is possible. While many people will likely start with refurbrished equipment, locally manufactured equipment maybe easier to repair and update giving a lower total cost of ownership. AfriNIC courses on IPv6 are good, but there does not seem to be a strong link to the African electronics sector and to the education sector. Are there any statistics on the numbers of people that have taken AfriNICs IPv6 courses? Of particular interest would be Nigeria which has significant internet users and DRC which produces raw material used in chips, but does little value addition to the raw materials. My understanding is that a number of tertiary educational institutions have obtained blocks of IPs from AfriNIC. How actively promoted is IPv6 at these institutions? Do any of those people responsible for those allocations monitor this list or does one need to reach out to them individually? > The RIR job is not setting up policies, is up to the community, the global Internet community. > > What we are saying is that the Soft Landing policy already was designed to ensure that newcomers and existing players needing more resources, do it together with IPv6 deployment, but we didn?t set rules to verify that and the level of encouragement was basically cero. Now we, as a community (not the RIR), can decide if we want to give a stronger push and what level of push we want to have. > > Fighting against IPv6 deployment is non-sense, it is a very high cost not only for all the players in Africa, but also in the rest of Internet. Encouraging IPv6 adoption is good, but success will depend on more than just forcing an allocation when applying for a block of IPv4 addresses. If most people in Africa will be consumers on a mobile network behind a NAT, then IPv6 uptake will be slow. If more people are looking to put up their own online services, they maybe more interest in IPv6 as the cost of leasing the address will be lower. Of course, for Africa, if Google and Meta were to turn off IPv4, it would be painful, but transition to IPv6 would happen real quick! The other main reason people use the internet is to access government services. This sector tends to be price sensitive and difficult to move in new directions. Simply forcing it to obtain IPv6 addresses will not likely encourage IPv6 adoption unless there are tangible benefits to end users. > > We need to see it in the other way around. Deploying IPv6, or extending existing networks with IPv6 is cheaper than buying more and more CGN boxes. > > So clearly I must disagree that this will create a burden, on the other way around. > > Saying it in a different way: It will be non-sense that an existing operator extend its network to accommodate more customers (that?s the reason they need more IPv4 addresses in the end), and they do it without implementing IPv6, the cost will be bigger with only-IPv4. Same non-sense that a new operator or end-site decides to start just with IPv4, the cost will be bigger. > > We need to find the way to word it so there is a proper balance. We are not saying necessarily, because you have ?n? new customers and need IPv4 addresses for them, you need to deploy IPv6 in all your network (even less remove IPv4 completely). Let?s find the way to ensure that we request a % of traffic according to the grow that creates you the need for more IPv4 addresses and then ramp-up the following years. The policy proposal has good intentions, but the feedback here indicates you are mostly preaching to the choir. It needs integration with the wider eco system. Regards, Benson From gbemiadepojuesho at gmail.com Sat May 30 04:12:47 2026 From: gbemiadepojuesho at gmail.com (Gbemisola Esho) Date: Fri, 29 May 2026 23:12:47 -0500 Subject: [rpd] In Memoriam: Alan Barrett In-Reply-To: References: Message-ID: Dear all, In tribute to the departed internet giant, I took a little walk down memory lane regarding his legacy in the space. Condolences again to his friends and family; may he rest in peace. On Fri, May 29, 2026 at 4:56?AM Isatou Jah wrote: > This is a devastating loss to the community. Alan was a friend and a > mentor and I am deeply saddened by this news. He was my instructor in the > very first Afnog workshop held in Cape Town in 2000 and had impacted great > knowledge upon the myself and the community at large. He was kind, patient > yet a strong leader. May his soul rest in perfect peace and my sincere > condolences to his family. > > Isatou > > *From: *Badru Ntege > *Date: *Thursday, 28 May 2026 at 2:45?PM > *To: *Andrew Alston ; RPD > *Subject: *Re: [rpd] In Memoriam: Alan Barrett > > Dear Andrew, and all, > > > > Thank you for sharing this heartbreaking news with such care and dignity. > > > > Alan was indeed a friend of the community. I first met him in Kampala at > AfNOG 2003, and even then, his passion was unmistakable. He wasn't just > attending meetings ? he was deeply invested in building something that > would serve the African Internet for decades to come. That commitment never > wavered. > > > > Alan was a passionate instructor at every AfNOG and AfriNIC meeting. From > the early days right up to the last major face-to-face, in-person event in > Kampala just before COVID, I don't think he missed a single annual > gathering. His dedication to teaching and mentoring the next generation of > network engineers across Africa was extraordinary. He showed up year after > year, not for recognition, but because he believed in the work and in the > people. > > > > His kindness, willingness to listen, and quiet strength made him someone > you could always turn to. > > > > My deepest condolences to Kerry and all of Alan's family. May they find > strength and peace in this difficult time. > > > > Rest in peace, Alan. You will be sorely missed. > > > > Badru Ntege > > > > *From: *Andrew Alston > *Date: *Thursday, 28 May 2026 at 3:43?PM > *To: *RPD > *Subject: *[rpd] In Memoriam: Alan Barrett > > > > Dear friends and colleagues, > > As some of you will already be aware, it is with immense sadness that we > confirm, on behalf of his wife Kerry and the family, the passing of Alan > Barrett. Alan died on May 28th in Cape Town, South Africa, following a > diagnosis of late-stage cancer about a month ago. We are sharing this > notice so that the community has accurate information at a moment when > Kerry and the family need space to grieve. > > Alan was a friend, a willing listener, and someone who always stepped up > to help when called upon. His contributions to the African Internet > ecosystem were second to none, and with his passing we lose not only a > friend but a giant of the industry. > > In 1990, Alan helped establish the very first Internet connection to South > African universities, and in 1993 he co-founded the country's first > commercial Internet Service Provider. In 1997 he co-authored the proposal > to create AfriNIC and subsequently served on the steering committee tasked > with bringing it into being. Alan served on the AfriNIC board from 2004 to > 2009 and was a member of the NRO NC from 2004 to 2014. In 2015 he was > appointed CEO of AfriNIC, a role he held until 2019. > > Beyond Africa, he was a central participant in the IANA Stewardship > Transition Coordination Group, and until his death served on the ICANN > board on behalf of the Address Supporting Organisation. > > Alan will be sorely missed by the community, his relatives and his wife, > Kerry. > > Kerry and the family ask for privacy at this time. We will be organising > an online memorial in due course and will share details once they are > available. > > Andrew Alston > Remco van Mook > > > ----- > This e-mail is intended only for the person(s) to whom it is addressed. If > an addressing or transmission error has misdirected this e-mail, please > notify the sender by replying to this e-mail. Further, if you are not an > intended recipient, please delete this e-mail and do not use, disclose, > copy, print or rely on the e-mail in any manner. QGroup does not accept or > assume responsibility for any use of or reliance on this e-mail by anyone, > other than the intended addressee to the extent agreed in the relevant > contract for the matter to which this email relates (if any). > > If you are not the intended addressee, please inform the sender > immediately that you have received this e-mail in error, and delete it. > Thanks for your cooperation. > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Alan b.jpeg Type: image/jpeg Size: 247610 bytes Desc: not available URL: From dawda.jatta at utg.edu.gm Sat May 30 13:38:43 2026 From: dawda.jatta at utg.edu.gm (Dawda Jatta) Date: Sat, 30 May 2026 13:38:43 +0000 Subject: [rpd] In Memoriam: Alan Barrett In-Reply-To: References: Message-ID: What a loss to the Internet community in Africa and globe at large. May the departed soul RIP ?. Best Regards, Dawda Jatta On Sat, May 30, 2026, 04:18 Gbemisola Esho wrote: > Dear all, > In tribute to the departed internet giant, I took a little walk down > memory lane regarding his legacy in the space. > Condolences again to his friends and family; may he rest in peace. > > On Fri, May 29, 2026 at 4:56?AM Isatou Jah wrote: > >> This is a devastating loss to the community. Alan was a friend and a >> mentor and I am deeply saddened by this news. He was my instructor in the >> very first Afnog workshop held in Cape Town in 2000 and had impacted great >> knowledge upon the myself and the community at large. He was kind, patient >> yet a strong leader. May his soul rest in perfect peace and my sincere >> condolences to his family. >> >> Isatou >> >> *From: *Badru Ntege >> *Date: *Thursday, 28 May 2026 at 2:45?PM >> *To: *Andrew Alston ; RPD >> *Subject: *Re: [rpd] In Memoriam: Alan Barrett >> >> Dear Andrew, and all, >> >> >> >> Thank you for sharing this heartbreaking news with such care and dignity. >> >> >> >> Alan was indeed a friend of the community. I first met him in Kampala at >> AfNOG 2003, and even then, his passion was unmistakable. He wasn't just >> attending meetings ? he was deeply invested in building something that >> would serve the African Internet for decades to come. That commitment never >> wavered. >> >> >> >> Alan was a passionate instructor at every AfNOG and AfriNIC meeting. From >> the early days right up to the last major face-to-face, in-person event in >> Kampala just before COVID, I don't think he missed a single annual >> gathering. His dedication to teaching and mentoring the next generation of >> network engineers across Africa was extraordinary. He showed up year after >> year, not for recognition, but because he believed in the work and in the >> people. >> >> >> >> His kindness, willingness to listen, and quiet strength made him someone >> you could always turn to. >> >> >> >> My deepest condolences to Kerry and all of Alan's family. May they find >> strength and peace in this difficult time. >> >> >> >> Rest in peace, Alan. You will be sorely missed. >> >> >> >> Badru Ntege >> >> >> >> *From: *Andrew Alston >> *Date: *Thursday, 28 May 2026 at 3:43?PM >> *To: *RPD >> *Subject: *[rpd] In Memoriam: Alan Barrett >> >> >> >> Dear friends and colleagues, >> >> As some of you will already be aware, it is with immense sadness that we >> confirm, on behalf of his wife Kerry and the family, the passing of Alan >> Barrett. Alan died on May 28th in Cape Town, South Africa, following a >> diagnosis of late-stage cancer about a month ago. We are sharing this >> notice so that the community has accurate information at a moment when >> Kerry and the family need space to grieve. >> >> Alan was a friend, a willing listener, and someone who always stepped up >> to help when called upon. His contributions to the African Internet >> ecosystem were second to none, and with his passing we lose not only a >> friend but a giant of the industry. >> >> In 1990, Alan helped establish the very first Internet connection to >> South African universities, and in 1993 he co-founded the country's first >> commercial Internet Service Provider. In 1997 he co-authored the proposal >> to create AfriNIC and subsequently served on the steering committee tasked >> with bringing it into being. Alan served on the AfriNIC board from 2004 to >> 2009 and was a member of the NRO NC from 2004 to 2014. In 2015 he was >> appointed CEO of AfriNIC, a role he held until 2019. >> >> Beyond Africa, he was a central participant in the IANA Stewardship >> Transition Coordination Group, and until his death served on the ICANN >> board on behalf of the Address Supporting Organisation. >> >> Alan will be sorely missed by the community, his relatives and his wife, >> Kerry. >> >> Kerry and the family ask for privacy at this time. We will be organising >> an online memorial in due course and will share details once they are >> available. >> >> Andrew Alston >> Remco van Mook >> >> >> ----- >> This e-mail is intended only for the person(s) to whom it is addressed. >> If an addressing or transmission error has misdirected this e-mail, please >> notify the sender by replying to this e-mail. Further, if you are not an >> intended recipient, please delete this e-mail and do not use, disclose, >> copy, print or rely on the e-mail in any manner. QGroup does not accept or >> assume responsibility for any use of or reliance on this e-mail by anyone, >> other than the intended addressee to the extent agreed in the relevant >> contract for the matter to which this email relates (if any). >> >> If you are not the intended addressee, please inform the sender >> immediately that you have received this e-mail in error, and delete it. >> Thanks for your cooperation. >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at inter.link Mon Jun 1 09:23:08 2026 From: james at inter.link (James Bensley) Date: Mon, 1 Jun 2026 09:23:08 +0000 Subject: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. In-Reply-To: <31ea4ca7-5fe4-4f01-928e-52ae15c2b5db@geier.ne.tz> References: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> <797e1318-3dd3-4b71-8ec3-9e0ffbe6239d@geier.ne.tz> <31ea4ca7-5fe4-4f01-928e-52ae15c2b5db@geier.ne.tz> Message-ID: Hi Frank, Thank you for taking the time to read the draft and suggest edits. Regarding this point from you: "4. References. In other regions, all IPv4 addresses have been exhausted and it seems that the equivalent to the soft-landing is not any more an issue, because most of the existing members only can access IPv4 addresses via transfers." this seems to be irrelevant for this proposal. Also the next section is also called "5. References". is it there by mistake? This wasn't me; I guess a copy and paste error from the AFRINIC team; this is text from another draft proposal. I will ask them to correct it. I believe I have incorporated the feedback from all over points from you except this one; 4. The necessity of "3. Other set types such as route sets are excluded." was questioned. It's not absolutely necessary. But I believe it can help. Maybe it can start with "For the avoidance of doubt: " ?? I'm not sure what benefit the text "For the avoidance of doubt" is adding here. Can you explain what is unclear about the existing text which this helps with (that would help me to understand what's wrong with the existing wording)? "The proposal is not currently extended to any other set types such as route sets, to keep the scope of this change to a more manageable level." I've put the latest version on GitHub (this avoids the AFRINIC staff potentially having to process many version changes with potentially very minor changes), feel free to comment there or respond here via email and I'll update the gist: https://gist.github.com/jwbensley/d76bfd3e87a5cb85fb28585381623bc4 Thank you for your input and support. With kind regards, James Bensley (he/him) ________________________________ From: Frank Habicht Sent: 22 May 2026 09:05 To: rpd at afrinic.net Subject: Re: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. ?? Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. so I'm a bit confused - sorry. On 5/22/2026 9:20 AM, Frank Habicht wrote: > 3. under 'Proposal' > "The first element of the name must be an ASN" > I hope we all understand that 'element' will be the things separated by > colons (":"). > I would humbly like to suggest to add "preceded by AS-" at the end, so > this becomes > "The first element of the name must be an ASN preceded by 'AS-'" > I think this would just be an editorial change... RFC2622 section 5 https://www.rfc-editor.org/info/rfc2622/#section-5 gives valid examples such as "AS1:AS-CUSTOMERS, AS1:RS-EXPORT:AS2" but section 5.1 states that AS-SETs have to start with "as-". So maybe the word "ASN" in the text refers to a string such as "AS37181" and not just the number by itself. And even if not, likely what would need to be added in front would be "AS" and not "AS-" ... Not sure about item 3. of my comments - quoted above. Sorry for confusion. Frank _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd [CompanySignature] Inter..link GmbH | Boxhagener Stra?e 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello at inter.link | Web: inter.link -------------- next part -------------- An HTML attachment was scrubbed... URL: From emmanuelvitus at gmail.com Mon Jun 1 09:31:33 2026 From: emmanuelvitus at gmail.com (Emmanuel Vitus) Date: Mon, 1 Jun 2026 10:31:33 +0100 Subject: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. In-Reply-To: References: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> <797e1318-3dd3-4b71-8ec3-9e0ffbe6239d@geier.ne.tz> <31ea4ca7-5fe4-4f01-928e-52ae15c2b5db@geier.ne.tz> Message-ID: I support this proposal. The problem of AS-SET name collisions across IRR databases is real and well documented. Requiring hierarchical names for newly created AS-SETs is a pragmatic approach that improves uniqueness, strengthens authorization and aligns AFRINIC with practices already adopted by other RIRs. One point of clarification would be helpful. Has AFRINIC experienced documented cases where such collisions have affected operators within the region? Overall, I believe this is a sensible and necessary improvement. Best, Emmanuel Vitus Le lun. 1 juin 2026 ? 10:24, James Bensley a ?crit : > Hi Frank, > > Thank you for taking the time to read the draft and suggest edits. > > Regarding this point from you: > > "4. References. In other regions, all IPv4 addresses have been exhausted > and it seems that the equivalent to the soft-landing is not any more an > issue, because most of the existing members only can access IPv4 addresses > via transfers." > this seems to be irrelevant for this proposal. Also the next section is > also called "5. References". is it there by mistake? > > This wasn't me; I guess a copy and paste error from the AFRINIC team; this > is text from another draft proposal. I will ask them to correct it. > > I believe I have incorporated the feedback from all over points from you > except this one; > > 4. The necessity of "3. Other set types such as route sets are excluded." > was questioned. It's not absolutely necessary. But I believe it can > help. Maybe it can start with "For the avoidance of doubt: " ?? > > I'm not sure what benefit the text "For the avoidance of doubt" is adding > here. Can you explain what is unclear about the existing text which this > helps with (that would help me to understand what's wrong with the existing > wording)? > "The proposal is not currently extended to any other set types such as > route sets, to keep the scope of this change to a more manageable level." > > I've put the latest version on GitHub (this avoids the AFRINIC staff > potentially having to process many version changes with potentially very > minor changes), feel free to comment there or respond here via email and > I'll update the gist: > https://gist.github.com/jwbensley/d76bfd3e87a5cb85fb28585381623bc4 > > Thank you for your input and support. > > With kind regards, > James Bensley (he/him) > ------------------------------ > *From:* Frank Habicht > *Sent:* 22 May 2026 09:05 > *To:* rpd at afrinic.net > *Subject:* Re: [rpd] Require newly created AS-SETs to have hierarchical > names AFPUB-2026-ASN-001-DRAFT01. > > ?? Caution: This email originated from outside of your organization. Do > not click on links or open attachments unless you recognize the sender and > know the content is safe. > > > so I'm a bit confused - sorry. > > On 5/22/2026 9:20 AM, Frank Habicht wrote: > > 3. under 'Proposal' > > "The first element of the name must be an ASN" > > I hope we all understand that 'element' will be the things separated by > > colons (":"). > > I would humbly like to suggest to add "preceded by AS-" at the end, so > > this becomes > > "The first element of the name must be an ASN preceded by 'AS-'" > > I think this would just be an editorial change... > > > RFC2622 section 5 > https://www.rfc-editor.org/info/rfc2622/#section-5 > gives valid examples such as "AS1:AS-CUSTOMERS, AS1:RS-EXPORT:AS2" > > but section 5.1 states that AS-SETs have to start with "as-". > > So maybe the word "ASN" in the text refers to a string such as "AS37181" > and not just the number by itself. > > And even if not, likely what would need to be added in front would be > "AS" and not "AS-" ... > > Not sure about item 3. of my comments - quoted above. > > Sorry for confusion. > > Frank > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > [CompanySignature] > Inter..link GmbH *|* Boxhagener Stra?e 80, 10245 Berlin, Germany > > *|* Managing Directors: Marc Korthaus, Theo Voss *|* Commercial Register: > Amtsgericht Charlottenburg, HRB 138876 *|* VAT ID: DE281288887 *|* Email: > hello at inter.link *|* Web: inter.link > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at inter.link Mon Jun 1 09:41:11 2026 From: james at inter.link (James Bensley) Date: Mon, 1 Jun 2026 09:41:11 +0000 Subject: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. In-Reply-To: References: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> Message-ID: Hi Jaco, Thanks for the additional feedback. I have hopefully responded to all your queries below (if not, please let me know). * It's an arbitrary and in my opinion unneeded restriction which can be removed. The only restriction is that the first component has to be ASnum where you have control over AS num. The rest can be left to the discretion of the ASnum admin surely? * So just drop bullet three entirely. I missed originally what you were getting at. Yes I agree with you, I have re-arranged the text in the latest draft (https://gist.github.com/jwbensley/d76bfd3e87a5cb85fb28585381623bc4), has this covered what you had hoped it would? * 7.8 as as whole specifically states "AS-SET" - not "Set Types", and point 1 also makes it clears this refers specifically to AS-SET, which means point 3 can be dropped without changing the intent/meaning of 7.8 as a whole. Point 3 has been removed. * Point 4 also really adds no value, that's an operational issue, not a policy issue. Definitely a valid point and something to be aware but still operational, not policy. I agree it's operational not policy, but it's the kind of question people ask "what about my existing AS-SET"? So we can avoid the question by having this in. I'd reverse your question; is there any downside to leaving this in (to try and avoid the question) ? * Exceptions to the policy may need to be permitted on a case by case basis *if and only if* a non-hierarchical AS-SET has been accidentally deleted to allow recreation. IMHO these should require motivation to have them restored from where they can then be edited again as per point 6. That's a good point - you never know what the future holds. I've added this as point 6. Please see the latest version - are all your points resolved? With kind regards, James Bensley (he/him) ________________________________ From: Jaco Kroon Sent: 28 May 2026 10:07 To: James Bensley ; dacostadarwin at gmail.com ; rpd at afrinic.net Subject: Re: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. ?? Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. Hi James, On 2026/05/28 09:54, James Bensley wrote: > Hi Jaco, > > Thank you for the support and your feedback. > > I wrote the original proposal. Regarding this comment: > > "The only thing that I found weird is that the second element has to be a name, why would "ASnum:ASnum2:AS-name" not be acceptable?" > > If you have a use case for that, then that could be added to the proposal. Do you have a use case/requirement for this? I think this usage is very rare, but if you have this use case, please speak up :) It's a hierarchy right, so what if I want to refer my customers by their AS numbers? Eg, ASyyyy:ASxxxx:AS-set It's an arbitrary and in my opinion unneeded restriction which can be removed. The only restriction is that the first component has to be ASnum where you have control over AS num. The rest can be left to the discretion of the ASnum admin surely? So just drop bullet three entirely. > > > Regarding this comment: > > "The purpose/function of "3. Other set types such as route sets are excluded." is unclear - everything else speaks specifically to AS-SET so why is this mention required?" > > Because route-sets can also support hierarchical names and in the past people have had the thought "well if we're making this change for AS-SETs let's also making it for Route-Sets whilst we're here" - but route-sets are extremely rarely used today and this just adds scope which I think isn't needed. So it was just about trying to stop that scope creep. I hear you. 7.8 as as whole specifically states "AS-SET" - not "Set Types", and point 1 also makes it clears this refers specifically to AS-SET, which means point 3 can be dropped without changing the intent/meaning of 7.8 as a whole. Point 4 also really adds no value, that's an operational issue, not a policy issue. Definitely a valid point and something to be aware but still operational, not policy. Exceptions to the policy may need to be permitted on a case by case basis *if and only if* a non-hierarchical AS-SET has been accidentally deleted to allow recreation. IMHO these should require motivation to have them restored from where they can then be edited again as per point 6. Kind regards, Jaco > > With kind regards, > James Bensley (he/him) > > ________________________________________ > From: Jaco Kroon > Sent: 21 May 2026 14:06 > To: dacostadarwin at gmail.com ; rpd at afrinic.net > Subject: Re: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. > > Hi, > > Definitely in support. > > The only thing that I found weird is that the second element has to be a > name, why would "ASnum:ASnum2:AS-name" not be acceptable? > > The purpose/function of "3. Other set types such as route sets are > excluded." is unclear - everything else speaks specifically to AS-SET so > why is this mention required? > > Kind regards, > Jaco > > On 2026/05/20 19:37, dacostadarwin at gmail.com wrote: > >> Dear PDWG, >> >> We have received a new draft policy proposal - Require newly created AS-SETs to have hierarchical names, ID AFPUB-2026-ASN-001-DRAFT01 from author James Bensley. >> >> The proposal contents are published at: >> https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft01 >> >> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >> >> a) Do you support or oppose the proposal? >> >> b) If you oppose the proposal, state your reasons? >> >> c) Is there anything in the proposal that is not clear? >> >> d) What changes could be made to this proposal to make it more effective? >> >> Regards, >> Vincent Ngundi & Darwin Da Costa >> AFRINIC PDWG Co-Chairs >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > [CompanySignature] > Inter..link GmbH | Boxhagener Stra?e 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello at inter.link | Web: inter.link -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at inter.link Mon Jun 1 09:51:28 2026 From: james at inter.link (James Bensley) Date: Mon, 1 Jun 2026 09:51:28 +0000 Subject: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. In-Reply-To: <1671C898-3DF8-42B7-A10E-99484C7CDBC5@hevis.co.za> References: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> , <1671C898-3DF8-42B7-A10E-99484C7CDBC5@hevis.co.za> Message-ID: Hi Hendrik, I assume your comment was referring to the hierarchical AS-SET names with say three elements? > Eg, ASyyyy:ASxxxx:AS-set It's valid syntax as per the RFC so I think that should be the reason it is supported (originally I misread what Jaco meant, I see now he's just referring to some valid syntax). It's usage is very rare (circa 2,92% of AS-SETs, see below), but because it's valid syntax I think it must be supported, not because of "gut feelings" about widely this feature is used.. ----- Downloaded AS-SET data from the 5 RIRs plus RADB: $ ls afrinic.db apnic.db.as-set arin.db lacnic.db radb.db ripe.db.as-set 53.6k unique AS-SETs: $ grep -E "^as-set: " * | awk '{print $NF}' | sort | uniq | wc -l 53674 Just 1571 with three colons in them: $ grep -E "^as-set: " * | awk '{print $NF}' | sort | uniq | grep -E ".*:.*:.*" | uniq | wc -l 1571 And those belong to a total of 72 (!!) networks of all networks in the 5 RIRs + RADB: $ grep -E "^as-set: " * | awk '{print $NF}' | sort | uniq | grep -E ".*:.*:.*" | awk -F ":" '{print $1}' | uniq | wc -l 72 With kind regards, James Bensley (he/him) ________________________________ From: Hendrik Visage Sent: 28 May 2026 11:32 To: Jaco Kroon Cc: James Bensley ; dacostadarwin at gmail.com ; rpd at afrinic.net Subject: Re: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. ?? Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. Organisation with network/ISP and separate hosting division Not that uncommon Sent from my mobile device > On 28 May 2026, at 10:14, Jaco Kroon wrote: > > ?Hi James, > >> On 2026/05/28 09:54, James Bensley wrote: >> >> Hi Jaco, >> >> Thank you for the support and your feedback. >> >> I wrote the original proposal. Regarding this comment: >> >> "The only thing that I found weird is that the second element has to be a name, why would "ASnum:ASnum2:AS-name" not be acceptable?" >> >> If you have a use case for that, then that could be added to the proposal. Do you have a use case/requirement for this? I think this usage is very rare, but if you have this use case, please speak up :) > > It's a hierarchy right, so what if I want to refer my customers by their AS numbers? > > Eg, ASyyyy:ASxxxx:AS-set > > It's an arbitrary and in my opinion unneeded restriction which can be removed. The only restriction is that the first component has to be ASnum where you have control over AS num. The rest can be left to the discretion of the ASnum admin surely? > > So just drop bullet three entirely. > >> >> >> Regarding this comment: >> >> "The purpose/function of "3. Other set types such as route sets are excluded." is unclear - everything else speaks specifically to AS-SET so why is this mention required?" >> >> Because route-sets can also support hierarchical names and in the past people have had the thought "well if we're making this change for AS-SETs let's also making it for Route-Sets whilst we're here" - but route-sets are extremely rarely used today and this just adds scope which I think isn't needed. So it was just about trying to stop that scope creep. > > I hear you. > > 7.8 as as whole specifically states "AS-SET" - not "Set Types", and point 1 also makes it clears this refers specifically to AS-SET, which means point 3 can be dropped without changing the intent/meaning of 7.8 as a whole. > > Point 4 also really adds no value, that's an operational issue, not a policy issue. Definitely a valid point and something to be aware but still operational, not policy. > > Exceptions to the policy may need to be permitted on a case by case basis *if and only if* a non-hierarchical AS-SET has been accidentally deleted to allow recreation. IMHO these should require motivation to have them restored from where they can then be edited again as per point 6. > > Kind regards, > Jaco > >> >> With kind regards, >> James Bensley (he/him) >> >> ________________________________________ >> From: Jaco Kroon >> Sent: 21 May 2026 14:06 >> To: dacostadarwin at gmail.com ; rpd at afrinic.net >> Subject: Re: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. >> >> Hi, >> >> Definitely in support. >> >> The only thing that I found weird is that the second element has to be a >> name, why would "ASnum:ASnum2:AS-name" not be acceptable? >> >> The purpose/function of "3. Other set types such as route sets are >> excluded." is unclear - everything else speaks specifically to AS-SET so >> why is this mention required? >> >> Kind regards, >> Jaco >> >>> On 2026/05/20 19:37, dacostadarwin at gmail.com wrote: >>> >>> Dear PDWG, >>> >>> We have received a new draft policy proposal - Require newly created AS-SETs to have hierarchical names, ID AFPUB-2026-ASN-001-DRAFT01 from author James Bensley. >>> >>> The proposal contents are published at: >>> https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft01 >>> >>> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>> >>> a) Do you support or oppose the proposal? >>> >>> b) If you oppose the proposal, state your reasons? >>> >>> c) Is there anything in the proposal that is not clear? >>> >>> d) What changes could be made to this proposal to make it more effective? >>> >>> Regards, >>> Vincent Ngundi & Darwin Da Costa >>> AFRINIC PDWG Co-Chairs >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> [CompanySignature] >> Inter..link GmbH | Boxhagener Stra?e 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello at inter.link | Web: inter.link > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd --- Hendrik Visage hvisage at hevis.co.za HeViS.Co Systems Pty Ltd https://www.envisage.co.za -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Mon Jun 1 09:57:47 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Mon, 1 Jun 2026 11:57:47 +0200 Subject: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. In-Reply-To: References: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> <797e1318-3dd3-4b71-8ec3-9e0ffbe6239d@geier.ne.tz> <31ea4ca7-5fe4-4f01-928e-52ae15c2b5db@geier.ne.tz> Message-ID: <6cc9855a-1bb4-4826-bfe7-1cbc7d7ca0fa@uls.co.za> Hi, On 2026/06/01 11:31, Emmanuel Vitus wrote: > > I support this proposal. > > The problem of AS-SET name collisions across IRR databases is real and > well documented. Requiring hierarchical names for newly created > AS-SETs is a pragmatic approach that improves uniqueness, strengthens > authorization and aligns AFRINIC with practices already adopted by > other RIRs. > > One point of clarification would be helpful. Has AFRINIC experienced > documented cases where such collisions have affected operators within > the region? > I'm aware of two cases, not going to disclose those details though. Kind regards, Jaco -------------- next part -------------- An HTML attachment was scrubbed... URL: From geier at geier.ne.tz Mon Jun 1 09:58:27 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Mon, 1 Jun 2026 12:58:27 +0300 Subject: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. In-Reply-To: References: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> <797e1318-3dd3-4b71-8ec3-9e0ffbe6239d@geier.ne.tz> <31ea4ca7-5fe4-4f01-928e-52ae15c2b5db@geier.ne.tz> Message-ID: <503184f8-bc23-44ab-894e-857759141afb@geier.ne.tz> On 6/1/2026 12:31 PM, Emmanuel Vitus wrote: > One point of clarification would be helpful. Has AFRINIC experienced > documented cases where such collisions have affected operators within > the region? I know of a case where an LIR in Tanzania used AS-BELL in the AfriNIC DB, and i notified them that this will clash globally, and the changed to a different name for the AS-SET and removed the AS-BELL. So it was resolved before it affected operators... Regards, Frank From emmanuelvitus at gmail.com Mon Jun 1 10:16:27 2026 From: emmanuelvitus at gmail.com (Emmanuel Vitus) Date: Mon, 1 Jun 2026 10:16:27 +0000 Subject: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. In-Reply-To: <503184f8-bc23-44ab-894e-857759141afb@geier.ne.tz> References: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> <797e1318-3dd3-4b71-8ec3-9e0ffbe6239d@geier.ne.tz> <31ea4ca7-5fe4-4f01-928e-52ae15c2b5db@geier.ne.tz> <503184f8-bc23-44ab-894e-857759141afb@geier.ne.tz> Message-ID: Thank you Frank. That is actually a useful example. It demonstrates that AS-SET name collisions are not merely a theoretical concern and can arise within the AFRINIC service region. It also reinforces one of the proposal's core arguments, namely that preventing future collisions is preferable to relying on manual detection and community intervention after the fact. My remaining question would be whether AFRINIC staff have visibility on how many similar cases may exist today within the AFRINIC IRR database and whether any broader assessment has been conducted. Le lun. 1 juin 2026 ? 10:58, Frank Habicht a ?crit : > On 6/1/2026 12:31 PM, Emmanuel Vitus wrote: > > One point of clarification would be helpful. Has AFRINIC experienced > > documented cases where such collisions have affected operators within > > the region? > > I know of a case where an LIR in Tanzania used AS-BELL in the AfriNIC > DB, and i notified them that this will clash globally, and the changed > to a different name for the AS-SET and removed the AS-BELL. > > So it was resolved before it affected operators... > > Regards, > Frank > -------------- next part -------------- An HTML attachment was scrubbed... URL: From madhvi at afrinic.net Mon Jun 1 10:33:14 2026 From: madhvi at afrinic.net (Madhvi Gokool) Date: Mon, 1 Jun 2026 14:33:14 +0400 Subject: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. In-Reply-To: References: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> <797e1318-3dd3-4b71-8ec3-9e0ffbe6239d@geier.ne.tz> <31ea4ca7-5fe4-4f01-928e-52ae15c2b5db@geier.ne.tz> Message-ID: <9a96268e-e0f6-4ff0-9226-552062de12f6@afrinic.net> Dear James/Frank Indeed there was a glitch while putting up the references section. This has been corrected. Kind Regards Madhvi On 01/06/2026 13:23, James Bensley wrote: > > Regarding this point from you: > > "4. References. In other regions, all IPv4 addresses have been > exhausted and it seems that the equivalent to the soft-landing is not > any more an issue, because most of the existing members only can > access IPv4 addresses via transfers." > this seems to be irrelevant for this proposal. Also the next section is > also called "5. References". is it there by mistake? > > This wasn't me; I guess a copy and paste error from the AFRINIC team; > this is text from another draft proposal. I will ask them to correct it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at inter.link Mon Jun 1 10:42:25 2026 From: james at inter.link (James Bensley) Date: Mon, 1 Jun 2026 10:42:25 +0000 Subject: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. In-Reply-To: References: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> <797e1318-3dd3-4b71-8ec3-9e0ffbe6239d@geier.ne.tz> <31ea4ca7-5fe4-4f01-928e-52ae15c2b5db@geier.ne.tz> <503184f8-bc23-44ab-894e-857759141afb@geier.ne.tz> Message-ID: Hi Emmanuel, This is something we can quickly check ourselves.... $ ./collissions.sh Total collisions: 211 ^ 211 AS-SETs in the AFRINIC DB today exist in other DBs. With kind regards, James Bensley (he/him) ------ #!/bin/bash AFRINIC_SETS=$(grep -E "^as-set: " afrinic.db | awk '{print $NF}' | sort | uniq) OTHER_SETS=$(grep -E "^as-set: " apnic.db.as-set arin.db lacnic.db radb.db ripe.db.as-set | awk '{print $NF}' | sort | uniq) COLLISIONS=0 for SET in $AFRINIC_SETS; do if grep -q -E "^$SET\$" <<< "$OTHER_SETS" then COLLISIONS=$((COLLISIONS + 1)) fi done echo "Total collisions: $COLLISIONS" ________________________________ From: Emmanuel Vitus Sent: 01 June 2026 12:16 To: Frank Habicht Cc: James Bensley ; rpd at afrinic.net Subject: Re: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. ?? Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. Thank you Frank. That is actually a useful example. It demonstrates that AS-SET name collisions are not merely a theoretical concern and can arise within the AFRINIC service region. It also reinforces one of the proposal's core arguments, namely that preventing future collisions is preferable to relying on manual detection and community intervention after the fact. My remaining question would be whether AFRINIC staff have visibility on how many similar cases may exist today within the AFRINIC IRR database and whether any broader assessment has been conducted. Le lun. 1 juin 2026 ? 10:58, Frank Habicht > a ?crit : On 6/1/2026 12:31 PM, Emmanuel Vitus wrote: > One point of clarification would be helpful. Has AFRINIC experienced > documented cases where such collisions have affected operators within > the region? I know of a case where an LIR in Tanzania used AS-BELL in the AfriNIC DB, and i notified them that this will clash globally, and the changed to a different name for the AS-SET and removed the AS-BELL. So it was resolved before it affected operators... Regards, Frank [CompanySignature] Inter..link GmbH | Boxhagener Stra?e 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello at inter.link | Web: inter.link -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjul.paul at gmail.com Mon Jun 1 13:30:06 2026 From: hjul.paul at gmail.com (Paul Hjul) Date: Mon, 1 Jun 2026 15:30:06 +0200 Subject: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03, AFRINIC Number Resource Policy Transfer Message-ID: Hi Jordi I don?t recall now all the details of the discussion, which it seems you > reviewed in detail and I agree with your summary. > What I?m sure is that I always discussed the lack of complete reprocity > with other RIRs, which impacts on the volume of transfers that can come in > to AFRINIC, and also discussed that changes in a policy proposal can?t be > done after consensus has been reached. Thanks, yes the reciprocity consideration is the main backdrop and until looking at this again I had assumed that this policy as ratified, while dead on arrival because of a lack of complete reciprocity as raised in your concerns, would still be net improvement. [I have a cynical streak ;) ]. Giving it a little bit of thought though, there are actually two aspects to the need for a sensible inter-RIR policy that resolves reciprocity and my thinking has only been on the one (I cop it to "occupational hazard") and I haven't grappled fully. A couple of more interesting problems can creep up from the woodwork. To solve this problem, in LACNIC I submitted a proposal to modify the PDP > in several aspects including this one, it reached consensus and was > ratified in mid-2023, and was implemented in June 2024 with this text: "To > publish a four-week last call for comments period for any proposal that > reaches consensus. In the case of editorial changes, a new version of the > proposal must be published and the last call for comments period must be > restarted." This way, the chairs have the chance to re-evaluate that the > editorial changes aren?t altering the view of the PDWG. > That seems like a very sensible thing to come into play. Digging in the archives also revealed a rather dense PDP policy discussion and things get wild. A new RDP proposal was put forward recently (from the same authors of this particular proposal and which I suspect is little more than an attempt to drag AFRINIC down another disastrous path) and I think the suggestion from Andrew needs to be taken forward. I anticipate that there will be some robust discussions in Nairobi followed by some kicking and screaming and name calling. Regarding the policy compliance dashboard, it was not ratified by the > board: https://lists.afrinic.net/pipermail/rpd/2026/014703.html As a > consequence, the authors had a call with the staff and then submitted > several weeks ago a new version. We are waiting for possible inputs from > the staff before publication. The major problem we are having is what I > asked the staff to confirm very urgently in this email: > https://lists.afrinic.net/pipermail/rpd/2026/014777.html This bothers me quite a bit - again though I don't think we can fault the Board. While I think we may disagree as to the scope of authority that a policy from the community can have once it touches on contractual relationships, there is likely common ground amongst everybody who actually is engaging in good faith that the role of Afrinic as an organization is to implement policy and mechanisms that have consensus from the community. The role of staff is not to create an Afrinic fiefdom or to gatekeep the global community. What is quite clear is that certain members of Afrinic staff oppose this policy on the basis that they see it as restaining their ability to act arbitrarily and capriciously. In doing so they wish to advance the contention that the RSA permits them to act in an arbitrary and capricious manner. I see you (together with other authors) have proposed a revised version of the policy. I am a little concerned that in trying to mute the staff objection the new policy proposal might miss the mark but I'll look more closely and comment specifically on that policy. [So I am quoting a different email from you] > In the case of AFRINIC, they perceive it as encroaching the staff, and > then the board doesn?t ratify it. May be because Mauritius law and that > means that we must change AFRINIC to another jurisdiction? What is clear is > that the community is the responsible of how the resources are handled by > means of policies (not the staff, not the Board, not AFRINIC as an > organisation), and this ALSO means that if they are misused against the > policies, the community also is the responsible and has the RIGHT to decide > how and even when the resources must be recovered. AFRINIC just execute the > orders of the community in regard to policies. This is the same in all the > RIRs. > There is a serious problem with the culture amongst some of the staff but I actually do think the vast majority of employees actually do try to do the right thing and that some careful leadership from the top will solve things reasonably quickly. AFRINIC as an organization has a long standing problem of certain insiders wishing to use the organization to advance some bizarre ideological bent and to use the cantankerous fights which flow as a smokescreen to engage in general larceny. When anybody gets caught with their trousers down poor Mauritius as a jurisdiction gets blamed. The problem isn't Mauritius as a jurisdiction. With the way AFRINIC has misdirected itself the litigation space would be infinitely more hazardous in South Africa (for example). We would probably have had a 15 year running saga over whether and how PAJA applies and while there is a certain intellectual curiosity for many reasons the questions at hand are best left as academic. If AFRINIC fell in one of the United Kingdom jurisdictions I can assure you that the barristers who've been engaged to take injunctions out on AFRINIC would have the same level of success (if not greater) as they've had in Mauritius (there would be significantly fewer matters but the overall situation would be similar). My knowledge of Kenya is quite limited but I have little doubt that the Keynan judiciary would largely align with the Mauritius and English courts - although the judges and even counsel will be more likely to wear wigs. Namibia, Lesotho and Botswana are distinct jurisdictions to South Africa and you might be able to avoid some of the delay that would arise in South Africa but you'd get much the same endpoint as in South Africa. If AFRINIC were seated in eSwatini we'd be able to argue for a more Roman-Dutch contract law than anywhere else but I am not sure anybody will actually be happy with the outcome. Rwanda is showing promise on some fronts but I don't think we can really escape the extent to which stability of rule of law is still to be entrenched. Now there are one or two aspects and peculiarities of Mauritius and there is a certain parochial feel to that annoys me [although we should probably blame the French], but the problem is not - and has never been - about the choice of jurisdiction. More importantly there is a massive difference between allocation policies and policies aiming to control the utilization of allocated resources. Grandfathering is a longstanding way of avoiding problems but emphatically avoiding retrospective rule making doesn't serve the interests of staff. This actually presents itself quite strongly the moment "legacy" space comes up. If RIPE NCC were to behave as badly as AFRINIC has I can assure that the authorities in the Netherlands would have operated in a vary similar manner to Mauritius. I really don't know if LACNIC has ever tried to pick the wrong fight on spurious grounds but I don't think the courts of Uruguay will afford it some unique tolerance. The less that is said about the United States the better. [If you take a gander down the ARIN mailing lists you'll discover some spine chilling stupidity as to the organizations understanding of resource holding.] So while I agree with the principle that the community must develop the policies and in developing the policies provide for the mechanisms of implementation and enforcement I'd stop very short of suggesting that the "community" (however you try to define it) has any right to assert some sort of authority to override applicable law. I'd be particularly concerned when there is some sort of suggestion that RIRs should enjoy some special dispensation because of some magical power asserted by the "community". A lot of mess would evaporate if there wasn't so many naked attempts to use the PDP as a means of control. Therefore as a general rule it is better to ensure that the assignment of resources is done in a manner that promotes the objectives for which consensus has been reached. Some years ago the intelligent voices in the community warned that the policy mechanisms were defective and they were shouted down. The community got the policy I've taken a look at the proposal of req So I'll poke in on your proposed amendment to require ... My question is - and has been for more than 10 years is why AFRINIC does not require IPv6 deployment undertakings -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjul.paul at gmail.com Mon Jun 1 13:35:24 2026 From: hjul.paul at gmail.com (Paul Hjul) Date: Mon, 1 Jun 2026 15:35:24 +0200 Subject: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03, AFRINIC Number Resource Policy Transfer In-Reply-To: References: Message-ID: Sorry hit send early. Complete message below. On Mon, 1 Jun 2026 at 15:30, Paul Hjul wrote: > Hi Jordi > > I don?t recall now all the details of the discussion, which it seems you >> reviewed in detail and I agree with your summary. >> What I?m sure is that I always discussed the lack of complete reprocity >> with other RIRs, which impacts on the volume of transfers that can come in >> to AFRINIC, and also discussed that changes in a policy proposal can?t be >> done after consensus has been reached. > > > Thanks, yes the reciprocity consideration is the main backdrop and until > looking at this again I had assumed that this policy as ratified, while > dead on arrival because of a lack of complete reciprocity as raised in your > concerns, would still be net improvement. [I have a cynical streak ;) ]. > Giving it a little bit of thought though, there are actually two aspects to > the need for a sensible inter-RIR policy that resolves reciprocity and my > thinking has only been on the one (I cop it to "occupational hazard") and I > haven't grappled fully. A couple of more interesting problems can creep up > from the woodwork. > > To solve this problem, in LACNIC I submitted a proposal to modify the PDP >> in several aspects including this one, it reached consensus and was >> ratified in mid-2023, and was implemented in June 2024 with this text: "To >> publish a four-week last call for comments period for any proposal that >> reaches consensus. In the case of editorial changes, a new version of the >> proposal must be published and the last call for comments period must be >> restarted." This way, the chairs have the chance to re-evaluate that the >> editorial changes aren?t altering the view of the PDWG. >> > > That seems like a very sensible thing to come into play. Digging in the > archives also revealed a rather dense PDP policy discussion and things get > wild. A new RDP proposal was put forward recently (from the same authors of > this particular proposal and which I suspect is little more than an attempt > to drag AFRINIC down another disastrous path) and I think the suggestion > from Andrew needs to be taken forward. I anticipate that there will be some > robust discussions in Nairobi followed by some kicking and screaming and > name calling. > > > > Regarding the policy compliance dashboard, it was not ratified by the >> board: https://lists.afrinic.net/pipermail/rpd/2026/014703.html As a >> consequence, the authors had a call with the staff and then submitted >> several weeks ago a new version. We are waiting for possible inputs from >> the staff before publication. The major problem we are having is what I >> asked the staff to confirm very urgently in this email: >> https://lists.afrinic.net/pipermail/rpd/2026/014777.html > > > This bothers me quite a bit - again though I don't think we can fault > the Board. While I think we may disagree as to the scope of authority that > a policy from the community can have once it touches on contractual > relationships, there is likely common ground amongst everybody who actually > is engaging in good faith that the role of Afrinic as an organization is to > implement policy and mechanisms that have consensus from the community. The > role of staff is not to create an Afrinic fiefdom or to gatekeep the global > community. > > What is quite clear is that certain members of Afrinic staff oppose this > policy on the basis that they see it as restaining their ability to act > arbitrarily and capriciously. In doing so they wish to advance the > contention that the RSA permits them to act in an arbitrary and capricious > manner. > > I see you (together with other authors) have proposed a revised version of > the policy. I am a little concerned that in trying to mute the staff > objection the new policy proposal might miss the mark but I'll look more > closely and comment specifically on that policy. > > [So I am quoting a different email from you] > >> In the case of AFRINIC, they perceive it as encroaching the staff, and >> then the board doesn?t ratify it. May be because Mauritius law and that >> means that we must change AFRINIC to another jurisdiction? What is clear is >> that the community is the responsible of how the resources are handled by >> means of policies (not the staff, not the Board, not AFRINIC as an >> organisation), and this ALSO means that if they are misused against the >> policies, the community also is the responsible and has the RIGHT to decide >> how and even when the resources must be recovered. AFRINIC just execute the >> orders of the community in regard to policies. This is the same in all the >> RIRs. >> > > There is a serious problem with the culture amongst some of the staff but > I actually do think the vast majority of employees actually do try to do > the right thing and that some careful leadership from the top will solve > things reasonably quickly. > AFRINIC as an organization has a long standing problem of certain insiders > wishing to use the organization to advance some bizarre ideological bent > and to use the cantankerous fights which flow as a smokescreen to engage in > general larceny. > > When anybody gets caught with their trousers down poor Mauritius as a > jurisdiction gets blamed. > > The problem isn't Mauritius as a jurisdiction. With the way AFRINIC has > misdirected itself the litigation space would be infinitely more hazardous > in South Africa (for example). We would probably have had a 15 year running > saga over whether and how PAJA applies and while there is a certain > intellectual curiosity for many reasons the questions at hand are best left > as academic. If AFRINIC fell in one of the United Kingdom jurisdictions I > can assure you that the barristers who've been engaged to take injunctions > out on AFRINIC would have the same level of success (if not greater) as > they've had in Mauritius (there would be significantly fewer matters but > the overall situation would be similar). My knowledge of Kenya is quite > limited but I have little doubt that the Keynan judiciary would largely > align with the Mauritius and English courts - although the judges and even > counsel will be more likely to wear wigs. Namibia, Lesotho and Botswana are > distinct jurisdictions to South Africa and you might be able to avoid some > of the delay that would arise in South Africa but you'd get much the same > endpoint as in South Africa. If AFRINIC were seated in eSwatini we'd be > able to argue for a more Roman-Dutch contract law than anywhere else but I > am not sure anybody will actually be happy with the outcome. Rwanda is > showing promise on some fronts but I don't think we can really escape the > extent to which stability of rule of law is still to be entrenched. > > Now there are one or two aspects and peculiarities of Mauritius and there > is a certain parochial feel to that annoys me [although we should probably > blame the French], but the problem is not - and has never been - about the > choice of jurisdiction. > More importantly there is a massive difference between allocation policies > and policies aiming to control the utilization of allocated resources. > Grandfathering is a longstanding way of avoiding problems but emphatically > avoiding retrospective rule making doesn't serve the interests of staff. > This actually presents itself quite strongly the moment "legacy" space > comes up. > > If RIPE NCC were to behave as badly as AFRINIC has I can assure that the > authorities in the Netherlands would have operated in a vary similar manner > to Mauritius. I really don't know if LACNIC has ever tried to pick the > wrong fight on spurious grounds but I don't think the courts of > Uruguay will afford it some unique tolerance. > The less that is said about the United States the better. [If you take a > gander down the ARIN mailing lists you'll discover some spine chilling > stupidity as to the organizations understanding of resource holding.] > > So while I agree with the principle that the community must develop the > policies and in developing the policies provide for the mechanisms of > implementation and enforcement I'd stop very short of suggesting that the > "community" (however you try to define it) has any right to assert some > sort of authority to override applicable law. I'd be particularly concerned > when there is some sort of suggestion that RIRs should enjoy some special > dispensation because of some magical power asserted by the "community". > A lot of mess would evaporate if there wasn't so many naked attempts to > use the PDP as a means of control. The proper way to ensure that resources > are allocated in line with some sort of expected case is to have > undertakings made by the recipient at the time of allocation. > > Therefore as a general rule it is better to ensure that the assignment of > resources is done in a manner that promotes the objectives for which > consensus has been reached. > Some years ago the intelligent voices in the community warned that the > policy mechanisms were defective and they were shouted down. The community > got the policy > > I've taken a look at the proposal of requirements around pairing IPv6 to > new IPv4 allocations that you've advanced. I think it provides a good > starting point and will comment on it properly during the week. > So I'll poke in on your policy proposal. My question is - and has been for > more than 10 years is why AFRINIC does not require IPv6 deployment > undertakings when allocations for IPv4 address space are made. The answer > which nobody wants to admit to is that that would not have served a lot of > peoples interests. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From policy-liaison at afrinic.net Mon Jun 1 18:12:22 2026 From: policy-liaison at afrinic.net (Policy Liaison Team) Date: Mon, 1 Jun 2026 22:12:22 +0400 Subject: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03, AFRINIC Number Resource Policy Transfer In-Reply-To: References: Message-ID: <171de628-8112-413a-a571-3f0a68ba84f7@afrinic.net> Dear All We have noted the discussion regarding reciprocity. Please note that reciprocity with the other RIRs were re-verified @April 2026 and published here - https://afrinic.net/policy/proposals/2020-gen-006-d3#implementation Kind Regards Madhvi for Policy Liaison Team On 01/06/2026 17:35, Paul Hjul wrote: > Sorry hit send early. Complete message below. > > On Mon, 1 Jun 2026 at 15:30, Paul Hjul wrote: > > Hi Jordi > > I don?t recall now all the details of the discussion, which it > seems you reviewed in detail and I agree with your summary. > What I?m sure is that I always discussed the lack of complete > reprocity with other RIRs, which impacts on the volume of > transfers that can come in to AFRINIC, and also discussed that > changes in a policy proposal can?t be done after consensus has > been reached. > > > Thanks, yes the reciprocity consideration is the main backdrop and > until looking at this again I had assumed that this policy as > ratified, while dead on arrival because of a lack of complete > reciprocity as raised in your concerns, would still be net > improvement. [I have a cynical streak ;) ]. Giving it a little bit > of thought though, there are actually two aspects to the need for > a sensible inter-RIR policy that resolves reciprocity and my > thinking has only been on the one (I cop it to "occupational > hazard") and I haven't grappled fully. A couple of more > interesting problems can creep up from the woodwork. > > To solve this problem, in LACNIC I submitted a proposal to > modify the PDP in several aspects including this one, it > reached consensus and was ratified in mid-2023, and was > implemented in June 2024 with this text: "To publish a > four-week last call for comments period for any proposal that > reaches consensus. In the case of editorial changes, a new > version of the proposal must be published and the last call > for comments period must be restarted." This way, the chairs > have the chance to re-evaluate that the editorial changes > aren?t altering the view of the PDWG. > > > That seems like a very sensible thing to come into play. Digging > in the archives also revealed a rather dense PDP policy discussion > and things get wild. A new RDP proposal was put forward recently > (from the same authors of this particular proposal and which I > suspect is little more than an attempt to drag AFRINIC down > another disastrous?path) and I think the suggestion from Andrew > needs to be taken forward. I anticipate that there will be some > robust discussions in Nairobi followed by some kicking and > screaming and name calling. > > > Regarding the policy compliance dashboard, it was not ratified > by the board: > https://lists.afrinic.net/pipermail/rpd/2026/014703.html As a > consequence, the authors had a call with the staff and then > submitted several weeks ago a new version. We are waiting for > possible inputs from the staff before publication. The major > problem we are having is what I asked the staff to confirm > very urgently in this email: > https://lists.afrinic.net/pipermail/rpd/2026/014777.html > > > This bothers me quite a bit - again though I don't think we can > fault the?Board. While I think we may disagree as to the scope of > authority that a policy from the community can have once it > touches on contractual relationships, there is likely common > ground amongst everybody who actually is engaging in good faith > that the role of Afrinic as an organization is to implement policy > and mechanisms that have consensus from the community. The role of > staff is not to create an Afrinic fiefdom or to gatekeep the > global community. > > What is quite clear is that certain members of Afrinic staff > oppose this policy on the basis that they see it as restaining > their ability to act arbitrarily and capriciously. In doing so > they wish to advance the contention that the RSA permits them to > act in an arbitrary and capricious manner. > > I see you (together with other authors) have proposed a revised > version of the policy. I am a little concerned that in trying to > mute the staff objection the new policy proposal might miss the > mark but I'll look more closely and comment specifically on that > policy. > > [So I am quoting a different email from you] > > In the case of AFRINIC, they perceive it as encroaching the > staff, and then the board doesn?t ratify it. May be because > Mauritius law and that means that we must change AFRINIC to > another jurisdiction? What is clear is that the community is > the responsible of how the resources are handled by means of > policies (not the staff, not the Board, not AFRINIC as an > organisation), and this ALSO means that if they are misused > against the policies, the community also is the responsible > and has the RIGHT to decide how and even when the resources > must be recovered. AFRINIC just execute the orders of the > community in regard to policies. This is the same in all the > RIRs. > > > There is a serious problem with the culture amongst some of the > staff but I actually do think the vast majority of employees > actually do try to do the right thing and that some careful > leadership from the top will solve things reasonably quickly. > AFRINIC as an organization has a long standing problem of certain > insiders wishing to use the organization to advance some bizarre > ideological bent and to use the cantankerous?fights which flow as > a smokescreen to engage in general larceny. > > When anybody gets caught with their trousers down poor Mauritius > as a jurisdiction gets blamed. > > The problem isn't Mauritius as a jurisdiction. With the way > AFRINIC has misdirected itself the litigation space would be > infinitely more hazardous in South Africa (for example). We would > probably have had a 15 year running saga over whether and how PAJA > applies and while there is a certain intellectual curiosity for > many reasons the questions at hand are best left as academic. If > AFRINIC fell in one of the United Kingdom jurisdictions I can > assure you that the barristers who've been engaged to take > injunctions out on AFRINIC would have the same level of success > (if not greater) as they've had in Mauritius (there would be > significantly fewer matters but the overall situation would be > similar). My knowledge of Kenya is quite limited but I have little > doubt that the Keynan judiciary would largely align with the > Mauritius and English courts - although the judges and even > counsel will be more likely to wear wigs.?Namibia, Lesotho and > Botswana are distinct jurisdictions to South Africa and you might > be able to avoid some of the delay that would arise in South > Africa but you'd get much the same endpoint as in South Africa. If > AFRINIC were seated in eSwatini we'd be able to argue for a more > Roman-Dutch contract law than anywhere else but I am not sure > anybody will actually be happy with the outcome. Rwanda is showing > promise on some fronts but I don't think we can really escape the > extent to which stability of rule of law is still to be entrenched. > > Now there are one or two aspects and peculiarities of Mauritius > and there is a certain parochial feel to that annoys me [although > we should probably blame the French], but the problem is not - and > has never been - about the choice of jurisdiction. > More importantly there is a massive difference between allocation > policies and policies aiming to control the utilization of > allocated resources. Grandfathering is a longstanding way of > avoiding problems but emphatically avoiding retrospective rule > making doesn't serve the interests of staff. This actually > presents itself quite strongly the moment "legacy" space comes up. > > If RIPE NCC were to behave as badly as AFRINIC has I can assure > that the authorities in the Netherlands would have operated in a > vary similar manner to Mauritius.?I really don't know if LACNIC > has ever tried to pick the wrong fight on spurious grounds but I > don't think the courts of Uruguay?will afford it some unique > tolerance. > The less that is said about the United States the better. [If you > take a gander down the ARIN mailing lists you'll discover some > spine chilling stupidity as to the organizations understanding of > resource holding.] > > So while I agree with the principle that the community must > develop the policies and in developing the policies provide for > the mechanisms of implementation and enforcement I'd stop very > short of suggesting that the "community" (however you try to > define it) has any right to assert some sort of authority to > override applicable law. I'd be particularly concerned when there > is some sort of suggestion that RIRs should enjoy some special > dispensation because of some magical power asserted by the > "community". > A lot of mess would evaporate if there wasn't so many naked > attempts to use the PDP as a means of control. The proper way to > ensure that resources are allocated in line with some sort of > expected case is to have undertakings made by the recipient at the > time of allocation. > > Therefore as a general rule it is better to ensure that the > assignment of resources is done in a manner that promotes the > objectives for which consensus has been reached. > Some years ago the intelligent voices in the community warned that > the policy mechanisms were defective and they were shouted down. > The community got the policy > > I've taken a look at the proposal of requirements around pairing > IPv6 to new IPv4 allocations that you've advanced. I think it > provides a good starting point and will comment on it properly > during the week. > So I'll poke in on your policy proposal. My question is - and has > been for more than 10 years is why AFRINIC does not require IPv6 > deployment undertakings when allocations for IPv4 address space > are made. The answer which nobody wants to admit to is that that > would not have served a lot of peoples interests. > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -- AFRINIC Policy Liaison. t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia -------------- next part -------------- An HTML attachment was scrubbed... URL: From benson_muite at emailplus.org Tue Jun 2 05:48:49 2026 From: benson_muite at emailplus.org (Benson Muite) Date: Tue, 02 Jun 2026 08:48:49 +0300 Subject: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03, AFRINIC Number Resource Policy Transfer In-Reply-To: References: Message-ID: <87pl29eblq.fsf@emailplus.org> Paul Hjul writes: > > > [So I am quoting a different email from you] > >> In the case of AFRINIC, they perceive it as encroaching the staff, and >> then the board doesn?t ratify it. May be because Mauritius law and that >> means that we must change AFRINIC to another jurisdiction? What is clear is >> that the community is the responsible of how the resources are handled by >> means of policies (not the staff, not the Board, not AFRINIC as an >> organisation), and this ALSO means that if they are misused against the >> policies, the community also is the responsible and has the RIGHT to decide >> how and even when the resources must be recovered. AFRINIC just execute the >> orders of the community in regard to policies. This is the same in all the >> RIRs. >> > > There is a serious problem with the culture amongst some of the staff but I > actually do think the vast majority of employees actually do try to do the > right thing and that some careful leadership from the top will solve things > reasonably quickly. AFRINIC has mostly operated succesfully, but there has also been financial mismanagement. > AFRINIC as an organization has a long standing problem of certain insiders > wishing to use the organization to advance some bizarre ideological bent > and to use the cantankerous fights which flow as a smokescreen to engage in > general larceny. > > When anybody gets caught with their trousers down poor Mauritius as a > jurisdiction gets blamed. > > The problem isn't Mauritius as a jurisdiction. With the way AFRINIC has > misdirected itself the litigation space would be infinitely more hazardous > in South Africa (for example). We would probably have had a 15 year running > saga over whether and how PAJA applies and while there is a certain > intellectual curiosity for many reasons the questions at hand are best left > as academic. If AFRINIC fell in one of the United Kingdom jurisdictions I > can assure you that the barristers who've been engaged to take injunctions > out on AFRINIC would have the same level of success (if not greater) as > they've had in Mauritius (there would be significantly fewer matters but > the overall situation would be similar). My knowledge of Kenya is quite > limited but I have little doubt that the Keynan judiciary would largely > align with the Mauritius and English courts - although the judges and even > counsel will be more likely to wear wigs. Namibia, Lesotho and Botswana are > distinct jurisdictions to South Africa and you might be able to avoid some > of the delay that would arise in South Africa but you'd get much the same > endpoint as in South Africa. If AFRINIC were seated in eSwatini we'd be > able to argue for a more Roman-Dutch contract law than anywhere else but I > am not sure anybody will actually be happy with the outcome. Rwanda is > showing promise on some fronts but I don't think we can really escape the > extent to which stability of rule of law is still to be entrenched. > > Now there are one or two aspects and peculiarities of Mauritius and there > is a certain parochial feel to that annoys me [although we should probably > blame the French], but the problem is not - and has never been - about the > choice of jurisdiction. > More importantly there is a massive difference between allocation policies > and policies aiming to control the utilization of allocated resources. > Grandfathering is a longstanding way of avoiding problems but emphatically > avoiding retrospective rule making doesn't serve the interests of staff. > This actually presents itself quite strongly the moment "legacy" space > comes up. > > If RIPE NCC were to behave as badly as AFRINIC has I can assure that the > authorities in the Netherlands would have operated in a vary similar manner > to Mauritius. I really don't know if LACNIC has ever tried to pick the > wrong fight on spurious grounds but I don't think the courts of > Uruguay will afford it some unique tolerance. > The less that is said about the United States the better. [If you take a > gander down the ARIN mailing lists you'll discover some spine chilling > stupidity as to the organizations understanding of resource holding.] > AFRINIC is a company limited by guarantee. From the companies act in Mauritius: https://www.mcci.org/media/35749/the-companies-act-2001.pdf my understanding is that annual reporting requirements are primarily the total indebtedness, members and directors. This is insufficient for an organization that can impact over 1 billion people. ARIN serves two countries, so may not have the same challenges as other RIRs. Have not looked at the legal registration status of LACNIC, it does serve many countries and appears to have done so well. APNIC is registered in Brisbane, Australia though was initially located in Japan and was moved for cost reasons: https://en.wikipedia.org/wiki/APNIC#History APNIC has both a non-profit corporation and a public company limited by guarantee: https://www.apnic.net/about-apnic/transparency/ RIPE NCC is an association under dutch law: https://business.gov.nl/running-your-business/legal-forms-and-governance/association/ This has good status for tax obligations, and requires that directors operate it in compliance with the stated objectives: https://business.gov.nl/running-your-business/legal-forms-and-governance/liability-of-a-director-or-committee-member/ One of the challenges RIPE NCC may face is compliance with sanctions: https://trust.ripe.net/legal-compliance/ If one considers IP addresses useful in government operations, this may have implications for national sovreignity. As an example the ITU has been involved in regulating the use of space internet services: https://en.wikipedia.org/wiki/International_Telecommunication_Union#Iranian_complaint_about_Starlink The ITU is not the most efficient organization (the multi stakeholder internet model is better), but the ITU is not subject solely to the laws of the country it is registered in. From hjul.paul at gmail.com Tue Jun 2 07:37:08 2026 From: hjul.paul at gmail.com (Paul Hjul) Date: Tue, 2 Jun 2026 09:37:08 +0200 Subject: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03, AFRINIC Number Resource Policy Transfer In-Reply-To: <87pl29eblq.fsf@emailplus.org> References: <87pl29eblq.fsf@emailplus.org> Message-ID: Commenting from my tablet so... (italics what is being replied to) *AFRINIC is a company limited by guarantee. From the companies act inMauritius:https://www.mcci.org/media/35749/the-companies-act-2001.pdf my understanding is that annual reporting requirements are primarily thetotal indebtedness, members and directors. This is insufficient for anorganization that can impact over 1 billion people.* Quite familiar with the Mauritius Companies Act ? including some very significant amendments of recent years. The selection of being a private as opposed to public company leads me very strongly to agree with the sentiment of "insufficient for an organization that can impact..." it though is a discussion that is isn't an RPD thing. I am pretty sure that I've publicly on more than one occasion argued that Afrinic ought to have been established as a public company limited by guarantee and that misapplying the Virginia non-stock corporation statute was a devastating if somewhat amusing misstep. Even with the limited annual reporting requirements taking a gander at the company registry database from time to time should get a person more than mildly concerned. I dont think the ITU really enters the mix as it is an intergovernmental organization. The concurrence and consensus was (and should be) that RIRs and the like aren't. RIPE certainly is sitting with a uniquely vexing challenge flowing from the unlawful conduct of Putin and weaponization of the Internet but that doesn't make the case to support a departure from one of the foundational bulwarks for a multistakeholder distributed system which is that you have different organizations performing their functional scope subject to the law. There are all sorts of things which have implications of countries capacity to exercise sovereignty which have been agreed to be operated on a commercial and global community basis. We don't have a global intergovernmental body that manages the delivery of cement yet critical infrastructure of great importance to sovereignty is constructed on contractual terms all the time. The transmission of payments has significant concerns yet Visa and Mastercard are not suggested to be suited to special intergovernmental treatment. SWIFT like the RIRs is governed as an entity under the laws of its seat (Belgium). APNIC is certainly on a better footing after 2024. A good transfer policy would reflect this... On Tue, 02 Jun 2026, 7:48 am Benson Muite wrote: > Paul Hjul writes: > > > > > > > [So I am quoting a different email from you] > > > >> In the case of AFRINIC, they perceive it as encroaching the staff, and > >> then the board doesn?t ratify it. May be because Mauritius law and that > >> means that we must change AFRINIC to another jurisdiction? What is > clear is > >> that the community is the responsible of how the resources are handled > by > >> means of policies (not the staff, not the Board, not AFRINIC as an > >> organisation), and this ALSO means that if they are misused against the > >> policies, the community also is the responsible and has the RIGHT to > decide > >> how and even when the resources must be recovered. AFRINIC just execute > the > >> orders of the community in regard to policies. This is the same in all > the > >> RIRs. > >> > > > > There is a serious problem with the culture amongst some of the staff > but I > > actually do think the vast majority of employees actually do try to do > the > > right thing and that some careful leadership from the top will solve > things > > reasonably quickly. > > AFRINIC has mostly operated succesfully, but there has also been financial > mismanagement. > > > AFRINIC as an organization has a long standing problem of certain > insiders > > wishing to use the organization to advance some bizarre ideological bent > > and to use the cantankerous fights which flow as a smokescreen to engage > in > > general larceny. > > > > When anybody gets caught with their trousers down poor Mauritius as a > > jurisdiction gets blamed. > > > > The problem isn't Mauritius as a jurisdiction. With the way AFRINIC has > > misdirected itself the litigation space would be infinitely more > hazardous > > in South Africa (for example). We would probably have had a 15 year > running > > saga over whether and how PAJA applies and while there is a certain > > intellectual curiosity for many reasons the questions at hand are best > left > > as academic. If AFRINIC fell in one of the United Kingdom jurisdictions I > > can assure you that the barristers who've been engaged to take > injunctions > > out on AFRINIC would have the same level of success (if not greater) as > > they've had in Mauritius (there would be significantly fewer matters but > > the overall situation would be similar). My knowledge of Kenya is quite > > limited but I have little doubt that the Keynan judiciary would largely > > align with the Mauritius and English courts - although the judges and > even > > counsel will be more likely to wear wigs. Namibia, Lesotho and Botswana > are > > distinct jurisdictions to South Africa and you might be able to avoid > some > > of the delay that would arise in South Africa but you'd get much the same > > endpoint as in South Africa. If AFRINIC were seated in eSwatini we'd be > > able to argue for a more Roman-Dutch contract law than anywhere else but > I > > am not sure anybody will actually be happy with the outcome. Rwanda is > > showing promise on some fronts but I don't think we can really escape the > > extent to which stability of rule of law is still to be entrenched. > > > > Now there are one or two aspects and peculiarities of Mauritius and there > > is a certain parochial feel to that annoys me [although we should > probably > > blame the French], but the problem is not - and has never been - about > the > > choice of jurisdiction. > > More importantly there is a massive difference between allocation > policies > > and policies aiming to control the utilization of allocated resources. > > Grandfathering is a longstanding way of avoiding problems but > emphatically > > avoiding retrospective rule making doesn't serve the interests of staff. > > This actually presents itself quite strongly the moment "legacy" space > > comes up. > > > > If RIPE NCC were to behave as badly as AFRINIC has I can assure that the > > authorities in the Netherlands would have operated in a vary similar > manner > > to Mauritius. I really don't know if LACNIC has ever tried to pick the > > wrong fight on spurious grounds but I don't think the courts of > > Uruguay will afford it some unique tolerance. > > The less that is said about the United States the better. [If you take a > > gander down the ARIN mailing lists you'll discover some spine chilling > > stupidity as to the organizations understanding of resource holding.] > > > > AFRINIC is a company limited by guarantee. From the companies act in > Mauritius: > https://www.mcci.org/media/35749/the-companies-act-2001.pdf > my understanding is that annual reporting requirements are primarily the > total indebtedness, members and directors. This is insufficient for an > organization that can impact over 1 billion people. > > ARIN serves two countries, so may not have the same challenges as other > RIRs. Have not looked at the legal registration status of LACNIC, it > does serve many countries and appears to have done so well. APNIC is > registered in Brisbane, Australia though was initially located in Japan > and was moved for cost reasons: > https://en.wikipedia.org/wiki/APNIC#History > APNIC has both a non-profit corporation and a public company limited by > guarantee: > https://www.apnic.net/about-apnic/transparency/ > > RIPE NCC is an association under dutch law: > > https://business.gov.nl/running-your-business/legal-forms-and-governance/association/ > > This has good status for tax obligations, and requires that directors > operate it in compliance with the stated objectives: > > https://business.gov.nl/running-your-business/legal-forms-and-governance/liability-of-a-director-or-committee-member/ > > One of the challenges RIPE NCC may face is compliance with sanctions: > https://trust.ripe.net/legal-compliance/ > > If one considers IP addresses useful in government operations, this may > have implications for national sovreignity. As an example the ITU has > been involved in regulating the use of space internet services: > > https://en.wikipedia.org/wiki/International_Telecommunication_Union#Iranian_complaint_about_Starlink > The ITU is not the most efficient organization (the multi stakeholder > internet model is better), but the ITU is not subject solely to the laws > of the country it is registered in. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Tue Jun 2 08:15:09 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Tue, 2 Jun 2026 10:15:09 +0200 Subject: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03, AFRINIC Number Resource Policy Transfer In-Reply-To: <171de628-8112-413a-a571-3f0a68ba84f7@afrinic.net> References: <171de628-8112-413a-a571-3f0a68ba84f7@afrinic.net> Message-ID: <5526A8DB-F535-443F-886B-0E675488A259@consulintel.es> Hi, Let me clarify my view on this. AFRINIC resource transfer policy has this limitation: "Only Legacy resources and resources transferred in from other regions will be transferable out of the AFRINIC service region." Consequently, I don?t think this is matching section 8.4 of the ARIN NRPM, which states: "Inter-regional transfers of IPv4 addresses or ASNs may take place only via RIRs who agree to the transfer and share reciprocal, compatible needs-based policies." If we take a ?subset? of only legacy resources from AFRINIC, then it can be considered reciprocal, but I will not call it ?fully reciprocal?, because clearly it disallows non-legacy AFRINIC resources to be transferred to ARIN or any other regions. What I?m not sure, I don?t know if ARIN confirmed that, is if the ARIN interpretation of their own policy will then allow non-legacy resources from ARIN be transferred to AFRINIC. Has this been confirmed by ARIN? I think there are no issues, at the time being with other RIRs, but when this proposal reached consensus, the major global ?donor? was ARIN, and unless I got it wrong, this is still the case in the last NRO stats from April 2026. Regards, Jordi @jordipalet > El 1 jun 2026, a las 20:12, Policy Liaison Team via RPD escribi?: > > Dear All > > We have noted the discussion regarding reciprocity. > > Please note that reciprocity with the other RIRs were re-verified @April 2026 and published here - https://afrinic.net/policy/proposals/2020-gen-006-d3#implementation > > > > Kind Regards > > Madhvi > > for Policy Liaison Team > > On 01/06/2026 17:35, Paul Hjul wrote: >> Sorry hit send early. Complete message below. >> >> On Mon, 1 Jun 2026 at 15:30, Paul Hjul > wrote: >>> Hi Jordi >>> >>>> I don?t recall now all the details of the discussion, which it seems you reviewed in detail and I agree with your summary. >>>> What I?m sure is that I always discussed the lack of complete reprocity with other RIRs, which impacts on the volume of transfers that can come in to AFRINIC, and also discussed that changes in a policy proposal can?t be done after consensus has been reached. >>> >>> Thanks, yes the reciprocity consideration is the main backdrop and until looking at this again I had assumed that this policy as ratified, while dead on arrival because of a lack of complete reciprocity as raised in your concerns, would still be net improvement. [I have a cynical streak ;) ]. Giving it a little bit of thought though, there are actually two aspects to the need for a sensible inter-RIR policy that resolves reciprocity and my thinking has only been on the one (I cop it to "occupational hazard") and I haven't grappled fully. A couple of more interesting problems can creep up from the woodwork. >>> >>>> To solve this problem, in LACNIC I submitted a proposal to modify the PDP in several aspects including this one, it reached consensus and was ratified in mid-2023, and was implemented in June 2024 with this text: "To publish a four-week last call for comments period for any proposal that reaches consensus. In the case of editorial changes, a new version of the proposal must be published and the last call for comments period must be restarted." This way, the chairs have the chance to re-evaluate that the editorial changes aren?t altering the view of the PDWG. >>> >>> That seems like a very sensible thing to come into play. Digging in the archives also revealed a rather dense PDP policy discussion and things get wild. A new RDP proposal was put forward recently (from the same authors of this particular proposal and which I suspect is little more than an attempt to drag AFRINIC down another disastrous path) and I think the suggestion from Andrew needs to be taken forward. I anticipate that there will be some robust discussions in Nairobi followed by some kicking and screaming and name calling. >>> >>>> Regarding the policy compliance dashboard, it was not ratified by the board: https://lists.afrinic.net/pipermail/rpd/2026/014703.html As a consequence, the authors had a call with the staff and then submitted several weeks ago a new version. We are waiting for possible inputs from the staff before publication. The major problem we are having is what I asked the staff to confirm very urgently in this email: https://lists.afrinic.net/pipermail/rpd/2026/014777.html >>> >>> This bothers me quite a bit - again though I don't think we can fault the Board. While I think we may disagree as to the scope of authority that a policy from the community can have once it touches on contractual relationships, there is likely common ground amongst everybody who actually is engaging in good faith that the role of Afrinic as an organization is to implement policy and mechanisms that have consensus from the community. The role of staff is not to create an Afrinic fiefdom or to gatekeep the global community. >>> >>> What is quite clear is that certain members of Afrinic staff oppose this policy on the basis that they see it as restaining their ability to act arbitrarily and capriciously. In doing so they wish to advance the contention that the RSA permits them to act in an arbitrary and capricious manner. >>> >>> I see you (together with other authors) have proposed a revised version of the policy. I am a little concerned that in trying to mute the staff objection the new policy proposal might miss the mark but I'll look more closely and comment specifically on that policy. >>> >>> [So I am quoting a different email from you] >>>> In the case of AFRINIC, they perceive it as encroaching the staff, and then the board doesn?t ratify it. May be because Mauritius law and that means that we must change AFRINIC to another jurisdiction? What is clear is that the community is the responsible of how the resources are handled by means of policies (not the staff, not the Board, not AFRINIC as an organisation), and this ALSO means that if they are misused against the policies, the community also is the responsible and has the RIGHT to decide how and even when the resources must be recovered. AFRINIC just execute the orders of the community in regard to policies. This is the same in all the RIRs. >>> >>> There is a serious problem with the culture amongst some of the staff but I actually do think the vast majority of employees actually do try to do the right thing and that some careful leadership from the top will solve things reasonably quickly. >>> AFRINIC as an organization has a long standing problem of certain insiders wishing to use the organization to advance some bizarre ideological bent and to use the cantankerous fights which flow as a smokescreen to engage in general larceny. >>> >>> When anybody gets caught with their trousers down poor Mauritius as a jurisdiction gets blamed. >>> >>> The problem isn't Mauritius as a jurisdiction. With the way AFRINIC has misdirected itself the litigation space would be infinitely more hazardous in South Africa (for example). We would probably have had a 15 year running saga over whether and how PAJA applies and while there is a certain intellectual curiosity for many reasons the questions at hand are best left as academic. If AFRINIC fell in one of the United Kingdom jurisdictions I can assure you that the barristers who've been engaged to take injunctions out on AFRINIC would have the same level of success (if not greater) as they've had in Mauritius (there would be significantly fewer matters but the overall situation would be similar). My knowledge of Kenya is quite limited but I have little doubt that the Keynan judiciary would largely align with the Mauritius and English courts - although the judges and even counsel will be more likely to wear wigs. Namibia, Lesotho and Botswana are distinct jurisdictions to South Africa and you might be able to avoid some of the delay that would arise in South Africa but you'd get much the same endpoint as in South Africa. If AFRINIC were seated in eSwatini we'd be able to argue for a more Roman-Dutch contract law than anywhere else but I am not sure anybody will actually be happy with the outcome. Rwanda is showing promise on some fronts but I don't think we can really escape the extent to which stability of rule of law is still to be entrenched. >>> >>> Now there are one or two aspects and peculiarities of Mauritius and there is a certain parochial feel to that annoys me [although we should probably blame the French], but the problem is not - and has never been - about the choice of jurisdiction. >>> More importantly there is a massive difference between allocation policies and policies aiming to control the utilization of allocated resources. Grandfathering is a longstanding way of avoiding problems but emphatically avoiding retrospective rule making doesn't serve the interests of staff. This actually presents itself quite strongly the moment "legacy" space comes up. >>> >>> If RIPE NCC were to behave as badly as AFRINIC has I can assure that the authorities in the Netherlands would have operated in a vary similar manner to Mauritius. I really don't know if LACNIC has ever tried to pick the wrong fight on spurious grounds but I don't think the courts of Uruguay will afford it some unique tolerance. >>> The less that is said about the United States the better. [If you take a gander down the ARIN mailing lists you'll discover some spine chilling stupidity as to the organizations understanding of resource holding.] >>> >>> So while I agree with the principle that the community must develop the policies and in developing the policies provide for the mechanisms of implementation and enforcement I'd stop very short of suggesting that the "community" (however you try to define it) has any right to assert some sort of authority to override applicable law. I'd be particularly concerned when there is some sort of suggestion that RIRs should enjoy some special dispensation because of some magical power asserted by the "community". >>> A lot of mess would evaporate if there wasn't so many naked attempts to use the PDP as a means of control. The proper way to ensure that resources are allocated in line with some sort of expected case is to have undertakings made by the recipient at the time of allocation. >>> >>> Therefore as a general rule it is better to ensure that the assignment of resources is done in a manner that promotes the objectives for which consensus has been reached. >>> Some years ago the intelligent voices in the community warned that the policy mechanisms were defective and they were shouted down. The community got the policy >>> >>> I've taken a look at the proposal of requirements around pairing IPv6 to new IPv4 allocations that you've advanced. I think it provides a good starting point and will comment on it properly during the week. >>> So I'll poke in on your policy proposal. My question is - and has been for more than 10 years is why AFRINIC does not require IPv6 deployment undertakings when allocations for IPv4 address space are made. The answer which nobody wants to admit to is that that would not have served a lot of peoples interests. >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > -- > AFRINIC Policy Liaison. > t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net > facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Tue Jun 2 09:32:06 2026 From: sander at steffann.nl (Sander Steffann) Date: Tue, 02 Jun 2026 09:32:06 +0000 Subject: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. In-Reply-To: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> References: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> Message-ID: Hi, > We have received a new draft policy proposal - Require newly created AS-SETs to have hierarchical names, ID AFPUB-2026-ASN-001-DRAFT01 from author James Bensley. > > The proposal contents are published at: > https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft01 > > We encourage you to take some time to go through the proposal contents and provide feedback as follows: > > a) Do you support or oppose the proposal? I think this proposal benefits the entire RIR and IRR system, so a +1 from me. Cheers, Sander From seun.ojedeji at gmail.com Tue Jun 2 11:29:12 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Tue, 2 Jun 2026 06:29:12 -0500 Subject: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03, AFRINIC Number Resource Policy Transfer In-Reply-To: <5526A8DB-F535-443F-886B-0E675488A259@consulintel.es> References: <171de628-8112-413a-a571-3f0a68ba84f7@afrinic.net> <5526A8DB-F535-443F-886B-0E675488A259@consulintel.es> Message-ID: Hello Jordi, Did you see policy liaisons reference or comment earlier and the link below: https://afrinic.net/policy/proposals/2020-gen-006-d3#implementation Whether it is fully or partially reciprocal the main question is whether it is compatible with other RIR and since other RIR confirmed. I think this matter can then be put to rest. Others can decide to improve upon the policy in future. Regards ---- Sent from my mobile kindly excuse typos On Tue, 2 Jun 2026, 3:15?am jordi.palet--- via RPD, wrote: > Hi, > > Let me clarify my view on this. > > AFRINIC resource transfer policy has this limitation: > "Only Legacy resources and resources transferred in from other regions > will be transferable out of the AFRINIC service region." > > Consequently, I don?t think this is matching section 8.4 of the ARIN NRPM, > which states: > "Inter-regional transfers of IPv4 addresses or ASNs may take place only > via RIRs who agree to the transfer and share reciprocal, compatible > needs-based policies." > > If we take a ?subset? of only legacy resources from AFRINIC, then it can > be considered reciprocal, but I will not call it ?fully reciprocal?, > because clearly it disallows non-legacy AFRINIC resources to be transferred > to ARIN or any other regions. > > What I?m not sure, I don?t know if ARIN confirmed that, is if the ARIN > interpretation of their own policy will then allow non-legacy resources > from ARIN be transferred to AFRINIC. Has this been confirmed by ARIN? > > I think there are no issues, at the time being with other RIRs, but when > this proposal reached consensus, the major global ?donor? was ARIN, and > unless I got it wrong, this is still the case in the last NRO stats from > April 2026. > > Regards, > Jordi > > @jordipalet > > > El 1 jun 2026, a las 20:12, Policy Liaison Team via RPD > escribi?: > > Dear All > > We have noted the discussion regarding reciprocity. > > Please note that reciprocity with the other RIRs were re-verified @April > 2026 and published here - > https://afrinic.net/policy/proposals/2020-gen-006-d3#implementation > > > Kind Regards > > Madhvi > > for Policy Liaison Team > On 01/06/2026 17:35, Paul Hjul wrote: > > Sorry hit send early. Complete message below. > > On Mon, 1 Jun 2026 at 15:30, Paul Hjul wrote: > >> Hi Jordi >> >> I don?t recall now all the details of the discussion, which it seems you >>> reviewed in detail and I agree with your summary. >>> What I?m sure is that I always discussed the lack of complete reprocity >>> with other RIRs, which impacts on the volume of transfers that can come in >>> to AFRINIC, and also discussed that changes in a policy proposal can?t be >>> done after consensus has been reached. >> >> >> Thanks, yes the reciprocity consideration is the main backdrop and until >> looking at this again I had assumed that this policy as ratified, while >> dead on arrival because of a lack of complete reciprocity as raised in your >> concerns, would still be net improvement. [I have a cynical streak ;) ]. >> Giving it a little bit of thought though, there are actually two aspects to >> the need for a sensible inter-RIR policy that resolves reciprocity and my >> thinking has only been on the one (I cop it to "occupational hazard") and I >> haven't grappled fully. A couple of more interesting problems can creep up >> from the woodwork. >> >> To solve this problem, in LACNIC I submitted a proposal to modify the PDP >>> in several aspects including this one, it reached consensus and was >>> ratified in mid-2023, and was implemented in June 2024 with this text: "To >>> publish a four-week last call for comments period for any proposal that >>> reaches consensus. In the case of editorial changes, a new version of the >>> proposal must be published and the last call for comments period must be >>> restarted." This way, the chairs have the chance to re-evaluate that the >>> editorial changes aren?t altering the view of the PDWG. >>> >> >> That seems like a very sensible thing to come into play. Digging in the >> archives also revealed a rather dense PDP policy discussion and things get >> wild. A new RDP proposal was put forward recently (from the same authors of >> this particular proposal and which I suspect is little more than an attempt >> to drag AFRINIC down another disastrous path) and I think the suggestion >> from Andrew needs to be taken forward. I anticipate that there will be some >> robust discussions in Nairobi followed by some kicking and screaming and >> name calling. >> >> Regarding the policy compliance dashboard, it was not ratified by the >>> board: https://lists.afrinic.net/pipermail/rpd/2026/014703.html As a >>> consequence, the authors had a call with the staff and then submitted >>> several weeks ago a new version. We are waiting for possible inputs from >>> the staff before publication. The major problem we are having is what I >>> asked the staff to confirm very urgently in this email: >>> https://lists.afrinic.net/pipermail/rpd/2026/014777.html >> >> >> This bothers me quite a bit - again though I don't think we can fault >> the Board. While I think we may disagree as to the scope of authority that >> a policy from the community can have once it touches on contractual >> relationships, there is likely common ground amongst everybody who actually >> is engaging in good faith that the role of Afrinic as an organization is to >> implement policy and mechanisms that have consensus from the community. The >> role of staff is not to create an Afrinic fiefdom or to gatekeep the global >> community. >> >> What is quite clear is that certain members of Afrinic staff oppose this >> policy on the basis that they see it as restaining their ability to act >> arbitrarily and capriciously. In doing so they wish to advance the >> contention that the RSA permits them to act in an arbitrary and capricious >> manner. >> >> I see you (together with other authors) have proposed a revised version >> of the policy. I am a little concerned that in trying to mute the staff >> objection the new policy proposal might miss the mark but I'll look more >> closely and comment specifically on that policy. >> >> [So I am quoting a different email from you] >> >>> In the case of AFRINIC, they perceive it as encroaching the staff, and >>> then the board doesn?t ratify it. May be because Mauritius law and that >>> means that we must change AFRINIC to another jurisdiction? What is clear is >>> that the community is the responsible of how the resources are handled by >>> means of policies (not the staff, not the Board, not AFRINIC as an >>> organisation), and this ALSO means that if they are misused against the >>> policies, the community also is the responsible and has the RIGHT to decide >>> how and even when the resources must be recovered. AFRINIC just execute the >>> orders of the community in regard to policies. This is the same in all the >>> RIRs. >>> >> >> There is a serious problem with the culture amongst some of the staff but >> I actually do think the vast majority of employees actually do try to do >> the right thing and that some careful leadership from the top will solve >> things reasonably quickly. >> AFRINIC as an organization has a long standing problem of certain >> insiders wishing to use the organization to advance some bizarre >> ideological bent and to use the cantankerous fights which flow as a >> smokescreen to engage in general larceny. >> >> When anybody gets caught with their trousers down poor Mauritius as a >> jurisdiction gets blamed. >> >> The problem isn't Mauritius as a jurisdiction. With the way AFRINIC has >> misdirected itself the litigation space would be infinitely more hazardous >> in South Africa (for example). We would probably have had a 15 year running >> saga over whether and how PAJA applies and while there is a certain >> intellectual curiosity for many reasons the questions at hand are best left >> as academic. If AFRINIC fell in one of the United Kingdom jurisdictions I >> can assure you that the barristers who've been engaged to take injunctions >> out on AFRINIC would have the same level of success (if not greater) as >> they've had in Mauritius (there would be significantly fewer matters but >> the overall situation would be similar). My knowledge of Kenya is quite >> limited but I have little doubt that the Keynan judiciary would largely >> align with the Mauritius and English courts - although the judges and even >> counsel will be more likely to wear wigs. Namibia, Lesotho and Botswana are >> distinct jurisdictions to South Africa and you might be able to avoid some >> of the delay that would arise in South Africa but you'd get much the same >> endpoint as in South Africa. If AFRINIC were seated in eSwatini we'd be >> able to argue for a more Roman-Dutch contract law than anywhere else but I >> am not sure anybody will actually be happy with the outcome. Rwanda is >> showing promise on some fronts but I don't think we can really escape the >> extent to which stability of rule of law is still to be entrenched. >> >> Now there are one or two aspects and peculiarities of Mauritius and there >> is a certain parochial feel to that annoys me [although we should probably >> blame the French], but the problem is not - and has never been - about the >> choice of jurisdiction. >> More importantly there is a massive difference between allocation >> policies and policies aiming to control the utilization of allocated >> resources. Grandfathering is a longstanding way of avoiding problems but >> emphatically avoiding retrospective rule making doesn't serve the interests >> of staff. This actually presents itself quite strongly the moment "legacy" >> space comes up. >> >> If RIPE NCC were to behave as badly as AFRINIC has I can assure that the >> authorities in the Netherlands would have operated in a vary similar manner >> to Mauritius. I really don't know if LACNIC has ever tried to pick the >> wrong fight on spurious grounds but I don't think the courts of >> Uruguay will afford it some unique tolerance. >> The less that is said about the United States the better. [If you take a >> gander down the ARIN mailing lists you'll discover some spine chilling >> stupidity as to the organizations understanding of resource holding.] >> >> So while I agree with the principle that the community must develop the >> policies and in developing the policies provide for the mechanisms of >> implementation and enforcement I'd stop very short of suggesting that the >> "community" (however you try to define it) has any right to assert some >> sort of authority to override applicable law. I'd be particularly concerned >> when there is some sort of suggestion that RIRs should enjoy some special >> dispensation because of some magical power asserted by the "community". >> A lot of mess would evaporate if there wasn't so many naked attempts to >> use the PDP as a means of control. The proper way to ensure that resources >> are allocated in line with some sort of expected case is to have >> undertakings made by the recipient at the time of allocation. >> >> Therefore as a general rule it is better to ensure that the assignment of >> resources is done in a manner that promotes the objectives for which >> consensus has been reached. >> Some years ago the intelligent voices in the community warned that the >> policy mechanisms were defective and they were shouted down. The community >> got the policy >> >> I've taken a look at the proposal of requirements around pairing IPv6 to >> new IPv4 allocations that you've advanced. I think it provides a good >> starting point and will comment on it properly during the week. >> So I'll poke in on your policy proposal. My question is - and has been >> for more than 10 years is why AFRINIC does not require IPv6 deployment >> undertakings when allocations for IPv4 address space are made. The answer >> which nobody wants to admit to is that that would not have served a lot of >> peoples interests. >> > > _______________________________________________ > RPD mailing listRPD at afrinic.nethttps://lists.afrinic.net/mailman/listinfo/rpd > > -- > AFRINIC Policy Liaison. > t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.netfacebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From seun.ojedeji at gmail.com Tue Jun 2 11:29:12 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Tue, 2 Jun 2026 06:29:12 -0500 Subject: [rpd] Ratified Policy Proposal - AFPUB-2020-GEN-006-DRAFT03, AFRINIC Number Resource Policy Transfer In-Reply-To: <5526A8DB-F535-443F-886B-0E675488A259@consulintel.es> References: <171de628-8112-413a-a571-3f0a68ba84f7@afrinic.net> <5526A8DB-F535-443F-886B-0E675488A259@consulintel.es> Message-ID: Hello Jordi, Did you see policy liaisons reference or comment earlier and the link below: https://afrinic.net/policy/proposals/2020-gen-006-d3#implementation Whether it is fully or partially reciprocal the main question is whether it is compatible with other RIR and since other RIR confirmed. I think this matter can then be put to rest. Others can decide to improve upon the policy in future. Regards ---- Sent from my mobile kindly excuse typos On Tue, 2 Jun 2026, 3:15?am jordi.palet--- via RPD, wrote: > Hi, > > Let me clarify my view on this. > > AFRINIC resource transfer policy has this limitation: > "Only Legacy resources and resources transferred in from other regions > will be transferable out of the AFRINIC service region." > > Consequently, I don?t think this is matching section 8.4 of the ARIN NRPM, > which states: > "Inter-regional transfers of IPv4 addresses or ASNs may take place only > via RIRs who agree to the transfer and share reciprocal, compatible > needs-based policies." > > If we take a ?subset? of only legacy resources from AFRINIC, then it can > be considered reciprocal, but I will not call it ?fully reciprocal?, > because clearly it disallows non-legacy AFRINIC resources to be transferred > to ARIN or any other regions. > > What I?m not sure, I don?t know if ARIN confirmed that, is if the ARIN > interpretation of their own policy will then allow non-legacy resources > from ARIN be transferred to AFRINIC. Has this been confirmed by ARIN? > > I think there are no issues, at the time being with other RIRs, but when > this proposal reached consensus, the major global ?donor? was ARIN, and > unless I got it wrong, this is still the case in the last NRO stats from > April 2026. > > Regards, > Jordi > > @jordipalet > > > El 1 jun 2026, a las 20:12, Policy Liaison Team via RPD > escribi?: > > Dear All > > We have noted the discussion regarding reciprocity. > > Please note that reciprocity with the other RIRs were re-verified @April > 2026 and published here - > https://afrinic.net/policy/proposals/2020-gen-006-d3#implementation > > > Kind Regards > > Madhvi > > for Policy Liaison Team > On 01/06/2026 17:35, Paul Hjul wrote: > > Sorry hit send early. Complete message below. > > On Mon, 1 Jun 2026 at 15:30, Paul Hjul wrote: > >> Hi Jordi >> >> I don?t recall now all the details of the discussion, which it seems you >>> reviewed in detail and I agree with your summary. >>> What I?m sure is that I always discussed the lack of complete reprocity >>> with other RIRs, which impacts on the volume of transfers that can come in >>> to AFRINIC, and also discussed that changes in a policy proposal can?t be >>> done after consensus has been reached. >> >> >> Thanks, yes the reciprocity consideration is the main backdrop and until >> looking at this again I had assumed that this policy as ratified, while >> dead on arrival because of a lack of complete reciprocity as raised in your >> concerns, would still be net improvement. [I have a cynical streak ;) ]. >> Giving it a little bit of thought though, there are actually two aspects to >> the need for a sensible inter-RIR policy that resolves reciprocity and my >> thinking has only been on the one (I cop it to "occupational hazard") and I >> haven't grappled fully. A couple of more interesting problems can creep up >> from the woodwork. >> >> To solve this problem, in LACNIC I submitted a proposal to modify the PDP >>> in several aspects including this one, it reached consensus and was >>> ratified in mid-2023, and was implemented in June 2024 with this text: "To >>> publish a four-week last call for comments period for any proposal that >>> reaches consensus. In the case of editorial changes, a new version of the >>> proposal must be published and the last call for comments period must be >>> restarted." This way, the chairs have the chance to re-evaluate that the >>> editorial changes aren?t altering the view of the PDWG. >>> >> >> That seems like a very sensible thing to come into play. Digging in the >> archives also revealed a rather dense PDP policy discussion and things get >> wild. A new RDP proposal was put forward recently (from the same authors of >> this particular proposal and which I suspect is little more than an attempt >> to drag AFRINIC down another disastrous path) and I think the suggestion >> from Andrew needs to be taken forward. I anticipate that there will be some >> robust discussions in Nairobi followed by some kicking and screaming and >> name calling. >> >> Regarding the policy compliance dashboard, it was not ratified by the >>> board: https://lists.afrinic.net/pipermail/rpd/2026/014703.html As a >>> consequence, the authors had a call with the staff and then submitted >>> several weeks ago a new version. We are waiting for possible inputs from >>> the staff before publication. The major problem we are having is what I >>> asked the staff to confirm very urgently in this email: >>> https://lists.afrinic.net/pipermail/rpd/2026/014777.html >> >> >> This bothers me quite a bit - again though I don't think we can fault >> the Board. While I think we may disagree as to the scope of authority that >> a policy from the community can have once it touches on contractual >> relationships, there is likely common ground amongst everybody who actually >> is engaging in good faith that the role of Afrinic as an organization is to >> implement policy and mechanisms that have consensus from the community. The >> role of staff is not to create an Afrinic fiefdom or to gatekeep the global >> community. >> >> What is quite clear is that certain members of Afrinic staff oppose this >> policy on the basis that they see it as restaining their ability to act >> arbitrarily and capriciously. In doing so they wish to advance the >> contention that the RSA permits them to act in an arbitrary and capricious >> manner. >> >> I see you (together with other authors) have proposed a revised version >> of the policy. I am a little concerned that in trying to mute the staff >> objection the new policy proposal might miss the mark but I'll look more >> closely and comment specifically on that policy. >> >> [So I am quoting a different email from you] >> >>> In the case of AFRINIC, they perceive it as encroaching the staff, and >>> then the board doesn?t ratify it. May be because Mauritius law and that >>> means that we must change AFRINIC to another jurisdiction? What is clear is >>> that the community is the responsible of how the resources are handled by >>> means of policies (not the staff, not the Board, not AFRINIC as an >>> organisation), and this ALSO means that if they are misused against the >>> policies, the community also is the responsible and has the RIGHT to decide >>> how and even when the resources must be recovered. AFRINIC just execute the >>> orders of the community in regard to policies. This is the same in all the >>> RIRs. >>> >> >> There is a serious problem with the culture amongst some of the staff but >> I actually do think the vast majority of employees actually do try to do >> the right thing and that some careful leadership from the top will solve >> things reasonably quickly. >> AFRINIC as an organization has a long standing problem of certain >> insiders wishing to use the organization to advance some bizarre >> ideological bent and to use the cantankerous fights which flow as a >> smokescreen to engage in general larceny. >> >> When anybody gets caught with their trousers down poor Mauritius as a >> jurisdiction gets blamed. >> >> The problem isn't Mauritius as a jurisdiction. With the way AFRINIC has >> misdirected itself the litigation space would be infinitely more hazardous >> in South Africa (for example). We would probably have had a 15 year running >> saga over whether and how PAJA applies and while there is a certain >> intellectual curiosity for many reasons the questions at hand are best left >> as academic. If AFRINIC fell in one of the United Kingdom jurisdictions I >> can assure you that the barristers who've been engaged to take injunctions >> out on AFRINIC would have the same level of success (if not greater) as >> they've had in Mauritius (there would be significantly fewer matters but >> the overall situation would be similar). My knowledge of Kenya is quite >> limited but I have little doubt that the Keynan judiciary would largely >> align with the Mauritius and English courts - although the judges and even >> counsel will be more likely to wear wigs. Namibia, Lesotho and Botswana are >> distinct jurisdictions to South Africa and you might be able to avoid some >> of the delay that would arise in South Africa but you'd get much the same >> endpoint as in South Africa. If AFRINIC were seated in eSwatini we'd be >> able to argue for a more Roman-Dutch contract law than anywhere else but I >> am not sure anybody will actually be happy with the outcome. Rwanda is >> showing promise on some fronts but I don't think we can really escape the >> extent to which stability of rule of law is still to be entrenched. >> >> Now there are one or two aspects and peculiarities of Mauritius and there >> is a certain parochial feel to that annoys me [although we should probably >> blame the French], but the problem is not - and has never been - about the >> choice of jurisdiction. >> More importantly there is a massive difference between allocation >> policies and policies aiming to control the utilization of allocated >> resources. Grandfathering is a longstanding way of avoiding problems but >> emphatically avoiding retrospective rule making doesn't serve the interests >> of staff. This actually presents itself quite strongly the moment "legacy" >> space comes up. >> >> If RIPE NCC were to behave as badly as AFRINIC has I can assure that the >> authorities in the Netherlands would have operated in a vary similar manner >> to Mauritius. I really don't know if LACNIC has ever tried to pick the >> wrong fight on spurious grounds but I don't think the courts of >> Uruguay will afford it some unique tolerance. >> The less that is said about the United States the better. [If you take a >> gander down the ARIN mailing lists you'll discover some spine chilling >> stupidity as to the organizations understanding of resource holding.] >> >> So while I agree with the principle that the community must develop the >> policies and in developing the policies provide for the mechanisms of >> implementation and enforcement I'd stop very short of suggesting that the >> "community" (however you try to define it) has any right to assert some >> sort of authority to override applicable law. I'd be particularly concerned >> when there is some sort of suggestion that RIRs should enjoy some special >> dispensation because of some magical power asserted by the "community". >> A lot of mess would evaporate if there wasn't so many naked attempts to >> use the PDP as a means of control. The proper way to ensure that resources >> are allocated in line with some sort of expected case is to have >> undertakings made by the recipient at the time of allocation. >> >> Therefore as a general rule it is better to ensure that the assignment of >> resources is done in a manner that promotes the objectives for which >> consensus has been reached. >> Some years ago the intelligent voices in the community warned that the >> policy mechanisms were defective and they were shouted down. The community >> got the policy >> >> I've taken a look at the proposal of requirements around pairing IPv6 to >> new IPv4 allocations that you've advanced. I think it provides a good >> starting point and will comment on it properly during the week. >> So I'll poke in on your policy proposal. My question is - and has been >> for more than 10 years is why AFRINIC does not require IPv6 deployment >> undertakings when allocations for IPv4 address space are made. The answer >> which nobody wants to admit to is that that would not have served a lot of >> peoples interests. >> > > _______________________________________________ > RPD mailing listRPD at afrinic.nethttps://lists.afrinic.net/mailman/listinfo/rpd > > -- > AFRINIC Policy Liaison. > t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.netfacebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From policy-liaison at afrinic.net Wed Jun 3 12:08:40 2026 From: policy-liaison at afrinic.net (Policy Liaison Team) Date: Wed, 3 Jun 2026 16:08:40 +0400 Subject: [rpd] general question for the staff In-Reply-To: <494B50BC-E35B-49DF-B2C2-93F38F61F801@consulintel.es> References: <494B50BC-E35B-49DF-B2C2-93F38F61F801@consulintel.es> Message-ID: <21052128-6a2a-49b4-8e12-e8be656c9d13@afrinic.net> Dear Jordi/PDWG We appreciate the inquiry regarding post-delegation follow-up and the subsequent comments shared by the working group members. Please find AFRINIC?s response below. The Registration Service Agreement (RSA) and Bylaws serve as the primary legal instruments governing the relationship between AFRINIC and its Resource Members. For this matter in particular, Clauses 4 and 6 of the RSA and 8.2 of the Bylaws outline the expected behaviours of members, including the mandatory requirement to comply with established policies. These clauses also provide the necessary legal basis for AFRINIC to take action when a member?s conduct or resource utilisation deviates from the policies. While it is important to ensure compliance, embedding specific post-delegation follow-up actions within applicable individual policies may present significant scalability and agility constraints as below: * Managing unique per-policy mechanisms for every individual policy could lead to a complex administrative burden. * Detailed operational steps within the Consolidated Policy Manual (CPM) can make it rigid to meet evolving administrative or technical needs without undergoing the full Policy Development Process (PDP). However, if the Working Group deems it necessary, then a recommendation would be that: * A consolidated guide or framework could be introduced to the Policy Manual with general reference to the RSA and Bylaws. Setting the high-level mandate for compliance reviews without prescribing specific, operational steps is beneficial. * Specific details, such as timelines, notification stages, and reclamation steps, can be published by AFRINIC in separate publicly accessible operational document(s) and implementation notes for specific policies. This ensures that the community understands the "how" while allowing the staff the flexibility to manage the process effectively and inline with any prevailing operational constraints. As reference , please see Section 5 of https://afrinic.net/reverse-dns and https://afrinic.net/20210428-lame-dns-delegation-policy * The resource policies be drafted in clear and unambiguous text so that compliance or lack of compliance requires no additional interpretation Kind Regards Madhvi On 22/05/2026 14:01, jordi.palet--- via RPD wrote: > Hi all, > > This point comes back frequently in discussions in different policy proposals, and I think we need to make it clear for once. > > For example, yesterday Sami requested to add some kind of text for post-allocation follow-up. > > I don?t think we have specific policy (other RIRs have it) for reclaim and recover, however, my understanding is that the existing RSA already enforces the policy compliance and AFRINIC may reclaim resources to any member that, for example, requested IPv4 or IPv6 addressing space with some specific plans, and after 1 or 2 years, the plans have been sensibly altered or even not complied at all, showing bad-faith on the original request. > > Is my interpretation correct and coincident with AFRINIC or we should add very specific text for any policy proposal (or a generic proposal for lack of compliance like in some other RIRs), for AFRINIC to ?verify? after a given period the compliance? > > I will understand that plans for an organization may change, but I think in those cases, the organization must for its own interest, have an alternative plan for the business continuity/business strategy changes and that should be re-addressed with AFRINIC, in case the allocation of resources need to be modified. > > I think a very clear (and urgent) response is needed in case we need to add some text into a new version of the current proposals under discussion before the dead line for a possible v2. > > Tks! > > Regards, > Jordi > > @jordipalet > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -- AFRINIC Policy Liaison. t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia -------------- next part -------------- An HTML attachment was scrubbed... URL: From theresadukumor at gmail.com Wed Jun 3 15:42:03 2026 From: theresadukumor at gmail.com (Theresa Dukumor) Date: Wed, 3 Jun 2026 16:42:03 +0100 Subject: [rpd] RPD Digest, Vol 220, Issue 41 In-Reply-To: References: Message-ID: Saul, I think there's a misunderstanding. Policy development is fundamentally about critiquing, challenging, and scrutinizing *ideas* and *words*. We have to be able to do that rigorously if we want good policy. We must protect people from abuse, absolutely, but shutting down criticism of a proposal itself is protectionism, not procedure. Regards, Theresa On Thu, May 28, 2026 at 11:56?AM Saul Stein wrote: > Theresa, > > > > >Conduct rules have been twisted to protect insiders and exclude criticism. > > > > You are quite right they are to protect members of this list against abuse > and since we are not here to criticise anyone, that is exactly what we are > trying to prevent. > > People need to treat others with respect and dignity. > > > The only protection is just that ? people. > > > > You are welcome to factually disagree and propose something better, but > not criticize people, their words or their ideas. > > > > *From:* Theresa Dukumor > *Sent:* Wednesday, 27 May 2026 15:53 > *To:* rpd at afrinic.net > *Subject:* Re: [rpd] RPD Digest, Vol 220, Issue 41 > > > > Hi Andrew, > > I see the value, but I'm cautious. > > Conduct rules have been twisted to protect insiders and exclude criticism. Adding a conduct code could make things worse. We should limit it to clear harm like harassment and spam, not vague tone complaints. The IETF model only works because of its open culture. Let's not copy the form without the substance. Will need to see the draft and the oversight plan before I can support it. > > Regards, > Theresa > > > > On Wed, May 27, 2026 at 11:49?AM wrote: > > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: Gauging Interest in a possible policy change > (jordi.palet at consulintel.es) > 2. Re: Gauging Interest in a possible policy change > (Dewole Ajao [AFRINIC]) > 3. Re: Gauging Interest in a possible policy change (Benson Muite) > 4. Re: Gauging Interest in a possible policy change (Seun Ojedeji) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 27 May 2026 08:49:24 +0200 > From: "jordi.palet at consulintel.es" > To: RPD > Subject: Re: [rpd] Gauging Interest in a possible policy change > Message-ID: <69DABC60-221A-4223-90BB-C114E3C46BE2 at consulintel.es> > Content-Type: text/plain; charset="utf-8" > > Hi Andrew, > > A few years ago, in LACNIC we had similar issues with behaviours against > the spirit of the equivalent list to this one. > > As I was IETF sergeant at arms for the IETF mailing list, and also > participate in many other exploders that have AUPs (Acceptable Usage > Policy), I used my experience to design a proposal for LACNIC, you can see > the last version here: > > https://politicas.lacnic.net/politicas/detail/id/LAC-2018-13/language/en > > It took a long time to discuss the proposal, and when it was almost > reaching consensus (in my opinion), LACNIC decided to make a CoC which > somehow superseddes the AUP. > > Nevertheless, I still have encountered feelings if an AUP may be also > needed in parallel to the CoC, as the CoC is quite generic while the AUP > can provide a ore clear path to co-chairs. > > So if you reach the conclusion that this is good to have, I?m happy to > work with you/others in that, or feel free to use that proposal as a > starting point that was discussed during 3 years in a very similar context. > > Regards, > Jordi > > @jordipalet > > > > El 27 may 2026, a las 7:53, Andrew Alston > escribi?: > > > > Hi Guys, > > > > I've been giving this a lot of thought and want to gauge interest in > adding a policy relating to the code of conduct. > > > > Effectively, what I foresee is language added to the policy which acts > similar to the IETF Notewell, and specifies appropriate/inappropriate > conduct both on the PDP List and during PDP meetings. > > > > Ideally speaking this will also include enforcement actions for the code > of conduct, appeal procedures etc. > > > > Within the IETF framework for example, disruptive behavior can result in > the temporary or permanent loss of posting rights to the list, and such > enforcement actions are subject to a robust appeal mechanism. > > > > Before I start drafting however, I'd like to hear the PDP's thoughts on > whether this is worth doing. > > > > Thanks > > > > Andrew > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260527/9c03f681/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Wed, 27 May 2026 08:00:58 +0100 > From: "Dewole Ajao [AFRINIC]" > To: Andrew Alston > Cc: RPD > Subject: Re: [rpd] Gauging Interest in a possible policy change > Message-ID: > Content-Type: text/plain; charset=us-ascii > > Thanks, Andrew. > > While I am not currently making any comments on the subject matter at this > point, > > I would like to commend the approach of coming to the list to check for > interest in working together to solve what you believe may be a problem > that needs to be solved. > > By getting to a wider understanding of whether or not there is a problem > to be solved (and possibly the root causes), before policy text is > proposed, the working group will be more efficient in its deliberations and > even the first draft (if it ever gets to draft stages) will be more robust > because it would ideally carry inputs from the discussions within the > working group (even if members choose not to join as authors). > > This has been suggested to policy proposal authors over the years and I > hope we can do more of this type of engagement in our policy development. > > With warm regards, > Dewole. > > > On 27 May 2026, at 06:53, Andrew Alston wrote: > > > > Hi Guys, > > > > I've been giving this a lot of thought and want to gauge interest in > adding a policy relating to the code of conduct. > > > > Effectively, what I foresee is language added to the policy which acts > similar to the IETF Notewell, and specifies appropriate/inappropriate > conduct both on the PDP List and during PDP meetings. > > > > Ideally speaking this will also include enforcement actions for the code > of conduct, appeal procedures etc. > > > > Within the IETF framework for example, disruptive behavior can result in > the temporary or permanent loss of posting rights to the list, and such > enforcement actions are subject to a robust appeal mechanism. > > > > Before I start drafting however, I'd like to hear the PDP's thoughts on > whether this is worth doing. > > > > Thanks > > > > Andrew > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > ------------------------------ > > Message: 3 > Date: Wed, 27 May 2026 10:35:17 +0300 > From: Benson Muite > To: Andrew Alston , RPD > Subject: Re: [rpd] Gauging Interest in a possible policy change > Message-ID: <87jysp2tl6.fsf at emailplus.org> > Content-Type: text/plain > > Andrew Alston writes: > Hi, > > (Will avoid gendered pronouns in case anyone feels left out)! > > > Hi Guys, > > > > I've been giving this a lot of thought and want to gauge interest in > adding > > a policy relating to the code of conduct. > > > > Effectively, what I foresee is language added to the policy which acts > > similar to the IETF Notewell, and specifies appropriate/inappropriate > > conduct both on the PDP List and during PDP meetings. > > This would probably be helpful. The IETF has much more transparency > than AFRINIC. It is not structured as a private company so legal > requirements for transparency in decision making, and in use of funds > are stricter. Every other RIR is structured as an non-profit public > benefit non governmental organization. > > Within the IETF, there are structures to get input from outside the IETF > for some decisions, for example from ISOC a broader community of > internet stakeholders. > > A code of conduct could help streamline useful input but should not not > prevent dissenting voices from being heard - this can be difficult in > large communities with diverse backgrounds. > > When there is disruptive behavior in the IETF, one can ask for further > details and decide on whether a warranted point is being made - some of > the post quantum standards are at least worthy of further individual > investigation. IETF processes have originated from a specific culture, > they are generally good, but could still be improved in terms of getting > dissenting voices heard. Not all elements may work well for AFRINIC, > but the experience is something that AFRINIC could learn from and use to > improve. > > > > > Ideally speaking this will also include enforcement actions for the code > of > > conduct, appeal procedures etc. > > > > Codes of conduct are often not drafted by people with any legal > background so are often guidelines for desired behavior and can be > difficult to enforce in some jurisdictions as they maybe in conflict > with local laws. Codes of conduct are easier to change than by-laws and > as changes would probably be needed, having this would be better than > putting it in the by-laws until they stabilise. > > > Within the IETF framework for example, disruptive behavior can result in > > the temporary or permanent loss of posting rights to the list, and such > > enforcement actions are subject to a robust appeal mechanism. > > > > Before I start drafting however, I'd like to hear the PDP's thoughts on > > whether this is worth doing. > > > > In my personal opinion this would be helpful, though my opinion is that > AFRINIC also needs broader restructuring and if such a restructuring > were to occur, how much would be carried over? > > Benson > > > Thanks > > > > Andrew > > > > ------------------------------ > > Message: 4 > Date: Wed, 27 May 2026 05:48:51 -0500 > From: Seun Ojedeji > To: Andrew Alston > Cc: RPD > Subject: Re: [rpd] Gauging Interest in a possible policy change > Message-ID: > < > CAD_dc6g9tBzMH6O3NJC3wnirT+jHjZrTJCw_3-QfPhmLTWJD2Q at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Andrew, > > AFRINIC does have an existing code of conduct[1] whether it is sufficient > in present realities is a different thing. > > I do not believe the rpd need to have a different CoC but I think it may be > appropriate for rpd to document the process to follow when AFRINIC CoC is > violated. > > Regards > [1] https://afrinic.net/code > ---- > Sent from my mobile > kindly excuse typos > > On Wed, 27 May 2026, 12:55?am Andrew Alston, > wrote: > > > Hi Guys, > > > > I've been giving this a lot of thought and want to gauge interest in > > adding a policy relating to the code of conduct. > > > > Effectively, what I foresee is language added to the policy which acts > > similar to the IETF Notewell, and specifies appropriate/inappropriate > > conduct both on the PDP List and during PDP meetings. > > > > Ideally speaking this will also include enforcement actions for the code > > of conduct, appeal procedures etc. > > > > Within the IETF framework for example, disruptive behavior can result in > > the temporary or permanent loss of posting rights to the list, and such > > enforcement actions are subject to a robust appeal mechanism. > > > > Before I start drafting however, I'd like to hear the PDP's thoughts on > > whether this is worth doing. > > > > Thanks > > > > Andrew > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260527/2c2c8a43/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 220, Issue 41 > ************************************ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From comms at afrinic.net Fri Jun 5 11:57:32 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Fri, 5 Jun 2026 15:57:32 +0400 Subject: [rpd] Reminder: AFRINIC Elections 2026: Call for Candidates Extended to 8 June 2026. Message-ID: [Version en fran?ais au bas] Dear Colleagues, The Nomination Committee 2026 hereby informs the AFRINIC Membership and broader Internet Community that the deadline for submission of nominations for the AFRINIC Elections 2026 has been extended to 08 June 2026. The extension applies to the following positions: Three (3) seats for the Governance Committee Two (2) seats for the NRO NC / ASO AC community representatives Two (2) PDP Co-Chairs The Nomination Committee encourages qualified candidates from all AFRINIC sub-regions to submit their nominations and welcomes diversity in representation, including gender and linguistic diversity. Nomination forms and election information are available: Governance Committee:https://forms.afrinic.net/governance-committee-election-2026 NRO NC / ASO AC: https://forms.afrinic.net/nro-nc-aso-ac-election-2026 PDP Co-Chairs: https://forms.afrinic.net/pdp-co-chairs-selection-2026 Additional information and the Election Guidelines 2026 at: https://election.afrinic.net/election-guideline-2026, Kind Regards, AFRINIC Communication ?????????????????????? ?lections AFRINIC 2026 : Prolongation de l'appel ? candidatures Chers coll?gues, Le comit? de nomination 2026 informe les membres d'AFRINIC et la communaut? Internet que la date limite de soumission des candidatures pour les ?lections AFRINIC 2026 a ?t? prolong?e au 08 juin 2026. Cette prolongation s'applique aux postes suivants : Trois (3) si?ges au sein du comit? de gouvernance Deux (2) si?ges pour les repr?sentants de la communaut? NRO NC / ASO AC Deux (2) copr?sidents du PDP Les formulaires de candidature et les informations relatives aux ?lections restent disponibles aux adresses suivantes: Comit? de gouvernance : https://forms.afrinic.net/governance-committee-election-2026 NRO NC / ASO AC : https://forms.afrinic.net/nro-nc-aso-ac-election-2026 Copr?sidents du PDP : https://forms.afrinic.net/pdp-co-chairs-selection-2026 Pour toute information compl?mentaire ainsi que pour consulter les directives ?lectorales 2026, veuillez visiter : https://election.afrinic.net/election-guideline-2026 AFRINIC Communication -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregoire.ehoumi at yahoo.fr Tue Jun 9 19:26:41 2026 From: gregoire.ehoumi at yahoo.fr (Gregoire EHOUMI) Date: Tue, 9 Jun 2026 15:26:41 -0400 Subject: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. In-Reply-To: References: <1EC212BF-EA11-4FB4-B5C4-B7429FFE6209@gmail.com> Message-ID: <4D12F3EC-E524-468A-BA8A-782BA4483DA6@yahoo.fr> Dear PDWG, This digest summarises the key points raised by community members (Ben, Seun, and Sami) regarding this policy proposal, along with the authors? clarifications and responses. It is organised into four themes for easier reading. 1. Corrections & Clarifications Mailing list freeze clarification: Comment (Ben): The RPD list was not frozen; only community?discuss was moderated. Response: Acknowledged. The text will be corrected in Draft?2. It was meant to say ? Inactive Resource Policy Discussion mailing list? 2. Participation, Representation & Elections Nomination support requirements: Comment (Seun): No need for supporters to be both AFRINIC members and community members. Response: The intent is to ensure support from at least one contact of the membership. Participants in the PDP and the WG activities are generally classified in 2 categories: ?Registered contact of AFRINIC member? and ? Non-registered contact of AFRINIC member? Who can vote in NRO NC elections: Comment (Seun): No reason to restrict voting to people in the region. Response: This follows existing AFRINIC rules. For NRO NC, only participants from the region(excluding staff) vote. 3. Co?Chair Roles, Eligibility & Processes Level of detail in co?chair responsibilities: Comment (Seun): Responsibilities in section 3.3.2 feel too granular and policing. Response: The detail is intentional, based on RFC?2418 and other RIRs practices, to avoid ambiguity. The WG should be predictable. Eligibility criteria ? meeting attendance: Comment (Seun): Requiring attendance at 4 of the last 6 PPMs (including one in?person) may be unrealistic. Response: at the old rhythm of 2 PPMs a year, this requirement means attending 4 of the 6 meetings held the last 3 years with at least one in-person. With Attendance A=4 and Meetings M= 6, what would you suggest for A and M? Appointment by consensus: Comment (Seun): Consensus?based appointment could introduce subjectivity. Response: This WG makes decisions by consensus with appeal mechanisms in place. Appointing co-chairs via the same mechanisms should not be a problem. With the requirements stated at section 3.3.3, it should not be difficult to reach consensus on co-chairs candidates. While this may not be perfect, it is used worldwide by various WGs. ?Community? votes rather bring more subjectivity. Code of Conduct reference: Comment (Seun): Simply refer to AFRINIC?s CoC. Response: By referring to ?applicable CoC? the proposal avoids attaching to a particular CoC. Today we are using the ?AFRINIC Community CoC? elaborated by the board ( https://afrinic.net/code ), this may change in the future. We saw some recent CoC discussions on the list. 4. Governance Structure & Proposal Scope Necessity of the Number Council: Comment (Seun): The Appeal Committee could perform the same role; RNC may be unnecessary. Response: The RNC?s roles encompass calling PPM and appointing interim co-chairs. So making the AC perform RNC?s role may not be appropriate. Splitting the proposal into smaller documents: Comment (Sami): Consider withdrawing and splitting into multiple focused proposals. Response: The components are interdependent; splitting them would create incoherent intermediate states and procedural gaps. Board ratification language: Comment (Seun): ?Shall? implies the Board must ratify; the Board should be able to decline with reasons. Response: The text as written ?If a policy proposal approved by the PDWG fails to be ratified by the board (inability or refusal by the board without reasons for 60 days), a petition for ratification can be initiated by a member of the PDWG.? it is meant to cover the two scenarios below: 1. The Board is unable to act for 60 days (No quorum, No functioning Board, Legal or operational paralysis, etc.) 2. The Board refuses to ratify without giving reasons for 60 days (the Board says ?no? but gives no justification, or The Board simply does nothing and provides no explanation.) Any suggestions to improve the text if it is not clear enough ? The authors thank the community for constructive feedback. Regards, Gr?goire > On May 27, 2026, at 2:45?PM, Sami Salih wrote: > > Dear Colleagues, > > As a former PDWG Co-chair, I generally support the intent behind strengthening the autonomy and operational continuity of the PDWG. The policy development process ultimately belongs to the African Internet community and should remain resilient regardless of operational or governance challenges affecting AFRINIC as an organisation. > > At the same time, I believe it is important to recognize that this proposal introduces substantial structural, operational, procedural, and governance changes to the PDP framework. In many respects, this is a major and transformative proposal rather than a routine procedural update. > > From my experience with the PDP, the community process tends to work best when addressing clearly scoped issues through focused and easy-to-understand proposals. In contrast, this proposal attempts to address many different governance, electoral, operational, disciplinary, and procedural matters simultaneously, which makes it difficult for the community to fully analyse, discuss, and build meaningful consensus around all aspects at once. > > IMHO, many of the ideas and intended improvements presented in this proposal are constructive and deserve serious consideration. I also fully acknowledge and respect the extensive experience, effort, and strategic thinking of the authors in developing such a comprehensive framework proposal. > > However, considering the breadth of the changes and the number of distinct governance and operational matters being introduced simultaneously, my respectful recommendation would be to consider withdrawing the current proposal and restructuring this work into multiple smaller and more focused proposals. I believe this would make it significantly easier for the community to understand, analyse, discuss, and build meaningful consensus around each individual topic independently, while improving overall community engagement and participation in the process. > > With Regards, > Sami Sali. > > > > Sami Salih > From: Seun Ojedeji > Sent: Monday, May 25, 2026 8:43:56 PM > To: dacostadarwin at gmail.com > Cc: rpd at afrinic.net > Subject: Re: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. > > Hello, > > Thanks for sharing this proposal. My initial comments after a brief review are the following: > > - A typical community member could also be an AFRINIC member. There is no reason to mandate that nomination supporters for the NRO NC must be both community members and AFRINIC members. Requiring one or 2 supporters from the service region should be sufficient. > > - The rpd is open to anyone that wishes to participate irrespective of origin, region or residence. It sure makes sense to restrict election participation to those with a historical record of involvement, either online or in-person to avoid historical experience of DDOS on election day. However, there is no reason to restrict the selectorate/electorate to those in the region alone. > > - I do not see the necessity of a Number Committee; it seems to create yet another layer. The Appeal committee which also serves as the recall committee can perform any intended role of the RNC. Its composition could be the 3 NRO NC members from the region, a past co-chair, and a past appeal committee chair in a non-voting capacity. In situations where both Co-Chairs are no more, the Chair of the Appeal committee can temporarily take over until rpd appoints a new co-chair > > - As a former co-chair of PDWG, i find the proposed responsibilities of the Co-chairs as described in section 3.3.2 to be overly granular and quite policing-like for lack of a better word. > > - I believe the proposed 3.3.7 should refer to AFRINIC CoC and that should be sufficient. The proposed penalties for violations look good, though they are a bit too wordy to me and the process leading to that is quite descriptive. We really need to give the co-chairs the privilege of managing events as they deem applicable > > - The idea that a co-chair eligibility should be tied to attending in-person meetings during a specific period isn't realistic given our region's unique challenges. I understand it may be an effort to put a face to the name but restricting eligibility to the last 2 years (which is basically last 4 PPM) isn't realistic. > > - 3.3.3.3.3 suggests co-chairs will be appointed by consensus, that is an interesting point that i would definitely not support. This can lead to unnecessary subjectivity. > > - I like the expectation of participation from Co-Chair hence 3.3.4 appeals to me as written. > > - Use of shall in 3.3.11 suggests that ratification is the only option for the Board. There should be an option for the Board to provide reasons for not ratifying and that should not be triggered by a petition. > > I may have more comments in future, but that is all from me for now. > > Regards > > On Mon, 25 May 2026 at 10:20, dacostadarwin at gmail.com > wrote: > Dear PDWG, > > We have received a new draft policy proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01 from authors Gr?goire EHOUMI, Noah Maina and Adeola A. P. AINA. > > The proposal contents are published at: https://afrinic.net/policy/proposals/afpub-2026-gen-001-draft01 > > We encourage you to take some time to go through the proposal contents and provide feedback as follows : > > a) Do you support or oppose the proposal? > > b) If you oppose the proposal, state your reasons. > > c) Is there anything in the proposal that is not clear? > > d) What changes could be made to this proposal to make it more effective? > > Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > -- > ------------------------------------------------------------------------ > Seun Ojedeji, > Bringing another down does not take you up - think about your action! > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From oloyede.aa at unilorin.edu.ng Tue Jun 9 21:24:12 2026 From: oloyede.aa at unilorin.edu.ng (Abdulkarim Oloyede) Date: Tue, 9 Jun 2026 23:24:12 +0200 Subject: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. In-Reply-To: <4D12F3EC-E524-468A-BA8A-782BA4483DA6@yahoo.fr> References: <1EC212BF-EA11-4FB4-B5C4-B7429FFE6209@gmail.com> <4D12F3EC-E524-468A-BA8A-782BA4483DA6@yahoo.fr> Message-ID: +1 to Seun except that I agree that only people from the region should vote. I do not think Seun's concerns have been addressed, especially on: below and I have a few additional concerns 1. Responsibilities in section 3.3.2 feel too granular and policing. 2. Requiring attendance at 4 of the last 6 PPMs (including one in?person) may be unrealistic. (I totally agree to this except if the requirement is personal funding for the one meeting.) Physical attendance does not show commitment; it?s about opportunities most times. 3. Consensus?based appointment could introduce subjectivity. I totally agree with this; it brings not just subjectivity but anarchy and lawlessness. 4. Registered PPM attendee voting... Does this include online attendees? Then I think we need to make up our mind on who should vote. My suggestion is members only should vote. 5. I totally disagree with having a recall committee and having recall committee decisions being final. This is subject to manipulation and abuse, and the chair is entirely at the mercy of few individuals called the recall committee. This is because the recall committee doesn?t appoint chairs, neither do 10 members appoint chairs. To remove chairs must be subjected to the same process as electing a chair. There must be a general vote with majority agreeing to recall the chair. *AK.* *Prof Abdulkarim Oloyede* *Professor of Wireless Telecommunications * *University of Ilorin. * On Tue, Jun 9, 2026, 9:34?PM Gregoire EHOUMI via RPD wrote: > Dear PDWG, > > This digest summarises the key points raised by community members (Ben, > Seun, and Sami) regarding this policy proposal, along with the authors? > clarifications and responses. > It is organised into four themes for easier reading. > > *1. Corrections & Clarifications* > *Mailing list freeze clarification:* > > - Comment (Ben): The RPD list was not frozen; only community?discuss > was moderated. > - *Response: *Acknowledged. The text will be corrected in Draft?2. It > was meant to say ? Inactive Resource Policy Discussion mailing list? > > > *2. Participation, Representation & Elections* > *Nomination support requirements:* > > - Comment (Seun): No need for supporters to be both AFRINIC members > and community members. > - *Response:* The intent is to ensure support from at least one > contact of the membership. Participants in the PDP and the WG activities > are generally classified in 2 categories: ?Registered contact of AFRINIC > member? and ? Non-registered contact of AFRINIC member? > > > *Who can vote in NRO NC elections:* > > - Comment (Seun): No reason to restrict voting to people in the region. > - *Response:* This follows existing AFRINIC rules. For NRO NC, only > participants from the region(excluding staff) vote. > > > *3. Co?Chair Roles, Eligibility & Processes* > *Level of detail in co?chair responsibilities:* > > - Comment (Seun): Responsibilities in section 3.3.2 feel too granular > and policing. > - *Response: *The detail is intentional, based on RFC?2418 and other > RIRs practices, to avoid ambiguity. The WG should be predictable. > > > *Eligibility criteria ? meeting attendance:* > > - Comment (Seun): Requiring attendance at 4 of the last 6 PPMs > (including one in?person) may be unrealistic. > - *Response:* at the old rhythm of 2 PPMs a year, this requirement > means attending 4 of the 6 meetings held the last 3 years with at least > one in-person. With Attendance A=4 and Meetings M= 6, what would you > suggest for A and M? > > > *Appointment by consensus:* > > - Comment (Seun): Consensus?based appointment could introduce > subjectivity. > - *Response:* This WG makes decisions by consensus with appeal > mechanisms in place. Appointing co-chairs via the same mechanisms should > not be a problem. With the requirements stated at section 3.3.3, it should > not be difficult to reach consensus on co-chairs candidates. While this may > not be perfect, it is used worldwide by various WGs. ?Community? votes > rather bring more subjectivity. > > > *Code of Conduct reference:* > > - Comment (Seun): Simply refer to AFRINIC?s CoC. > - *Response:* By referring to ?applicable CoC? the proposal avoids > attaching to a particular CoC. Today we are using the ?AFRINIC Community > CoC? elaborated by the board ( https://afrinic.net/code ), this may > change in the future. We saw some recent CoC discussions on the list. > > > *4. Governance Structure & Proposal Scope* > *Necessity of the Number Council:* > > - Comment (Seun): The Appeal Committee could perform the same role; > RNC may be unnecessary. > - *Response: *The RNC?s roles encompass calling PPM and appointing > interim co-chairs. So making the AC perform RNC?s role may not be > appropriate. > > > *Splitting the proposal into smaller documents:* > > - Comment (Sami): Consider withdrawing and splitting into multiple > focused proposals. > - *Response:* The components are interdependent; splitting them would > create incoherent intermediate states and procedural gaps. > > > *Board ratification language:* > > - Comment (Seun): ?Shall? implies the Board must ratify; the Board > should be able to decline with reasons. > - *Response:* The text as written ?If a policy proposal approved by > the PDWG fails to be ratified by the board (inability or refusal by the > board without reasons for 60 days), a petition for ratification can be > initiated by a member of the PDWG.? it is meant to cover the two scenarios > below: > > 1. The Board is unable to act for 60 days (No quorum, No functioning > Board, Legal or operational paralysis, etc.) > 2. The Board refuses to ratify without giving reasons for 60 days (the > Board says ?no? but gives no justification, or The Board simply does > nothing and provides no explanation.) > Any suggestions to improve the text if it is not clear enough ? > > > The authors thank the community for constructive feedback. > > Regards, > > Gr?goire > > > > On May 27, 2026, at 2:45?PM, Sami Salih wrote: > > Dear Colleagues, > > As a former PDWG Co-chair, I generally support the intent behind > strengthening the autonomy and operational continuity of the PDWG. The > policy development process ultimately belongs to the African Internet > community and should remain resilient regardless of operational or > governance challenges affecting AFRINIC as an organisation. > > At the same time, I believe it is important to recognize that this > proposal introduces substantial structural, operational, procedural, and > governance changes to the PDP framework. In many respects, this is a major > and transformative proposal rather than a routine procedural update. > > From my experience with the PDP, the community process tends to work best > when addressing clearly scoped issues through focused and > easy-to-understand proposals. In contrast, this proposal attempts to > address many different governance, electoral, operational, disciplinary, > and procedural matters simultaneously, which makes it difficult for the > community to fully analyse, discuss, and build meaningful consensus around > all aspects at once. > > IMHO, many of the ideas and intended improvements presented in this > proposal are constructive and deserve serious consideration. I also fully > acknowledge and respect the extensive experience, effort, and strategic > thinking of the authors in developing such a comprehensive framework > proposal. > > However, considering the breadth of the changes and the number of distinct > governance and operational matters being introduced simultaneously, my > respectful recommendation would be to consider withdrawing the current > proposal and restructuring this work into multiple smaller and more focused > proposals. I believe this would make it significantly easier for the > community to understand, analyse, discuss, and build meaningful consensus > around each individual topic independently, while improving overall > community engagement and participation in the process. > > With Regards, > Sami Sali. > > > Sami Salih > ------------------------------ > *From:* Seun Ojedeji > *Sent:* Monday, May 25, 2026 8:43:56 PM > *To:* dacostadarwin at gmail.com > *Cc:* rpd at afrinic.net > *Subject:* Re: [rpd] New Draft Policy Proposal - Amendment of the PDP > Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. > > Hello, > > Thanks for sharing this proposal. My initial comments after a brief review > are the following: > > - A typical community member could also be an AFRINIC member. There is no > reason to mandate that nomination supporters for the NRO NC must be both > community members and AFRINIC members. Requiring one or 2 supporters from > the service region should be sufficient. > > - The rpd is open to anyone that wishes to participate irrespective of > origin, region or residence. It sure makes sense to restrict election > participation to those with a historical record of involvement, either > online or in-person to avoid historical experience of DDOS on election > day. However, there is no reason to restrict the selectorate/electorate to > those in the region alone. > > - I do not see the necessity of a Number Committee; it seems to create yet > another layer. The Appeal committee which also serves as the recall > committee can perform any intended role of the RNC. Its composition could > be the 3 NRO NC members from the region, a past co-chair, and a past appeal > committee chair in a non-voting capacity. In situations where both > Co-Chairs are no more, the Chair of the Appeal committee can temporarily > take over until rpd appoints a new co-chair > > - As a former co-chair of PDWG, i find the proposed responsibilities of > the Co-chairs as described in section 3.3.2 to be overly granular and > quite policing-like for lack of a better word. > > - I believe the proposed 3.3.7 should refer to AFRINIC CoC and that should > be sufficient. The proposed penalties for violations look good, though they > are a bit too wordy to me and the process leading to that is quite > descriptive. We really need to give the co-chairs the privilege of managing > events as they deem applicable > > - The idea that a co-chair eligibility should be tied to attending > in-person meetings during a specific period isn't realistic given our > region's unique challenges. I understand it may be an effort to put a face > to the name but restricting eligibility to the last 2 years (which is > basically last 4 PPM) isn't realistic. > > - 3.3.3.3.3 suggests co-chairs will be appointed by consensus, that is an > interesting point that i would definitely not support. This can lead to > unnecessary subjectivity. > > - I like the expectation of participation from Co-Chair hence 3.3.4 > appeals to me as written. > > - Use of shall in 3.3.11 suggests that ratification is the only option for > the Board. There should be an option for the Board to provide reasons for > not ratifying and that should not be triggered by a petition. > > I may have more comments in future, but that is all from me for now. > > Regards > > On Mon, 25 May 2026 at 10:20, dacostadarwin at gmail.com < > dacostadarwin at gmail.com> wrote: > > Dear PDWG, > > We have received a new draft policy proposal - Amendment of the PDP > Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01 > from authors Gr?goire EHOUMI, Noah Maina and Adeola A. P. AINA. > > The proposal contents are published at: > https://afrinic.net/policy/proposals/afpub-2026-gen-001-draft01 > > We encourage you to take some time to go through the proposal contents > and provide feedback as follows : > > a) Do you support or oppose the proposal? > > b) If you oppose the proposal, state your reasons. > > c) Is there anything in the proposal that is not clear? > > d) What changes could be made to this proposal to make it more effective? > > Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > > -- > ------------------------------------------------------------------------ > > > *Seun Ojedeji, * > > Bringing another down does not take you up - think about your action! > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -- Website ,?Weekly Bulletin ?UGPortal PGPortal ?HelpDesk -------------- next part -------------- An HTML attachment was scrubbed... URL: From seun.ojedeji at gmail.com Wed Jun 10 01:09:59 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Tue, 9 Jun 2026 20:09:59 -0500 Subject: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. In-Reply-To: <4D12F3EC-E524-468A-BA8A-782BA4483DA6@yahoo.fr> References: <1EC212BF-EA11-4FB4-B5C4-B7429FFE6209@gmail.com> <4D12F3EC-E524-468A-BA8A-782BA4483DA6@yahoo.fr> Message-ID: Hello Gregoire, Please find the details inline: On Tue, 9 Jun 2026 at 14:27, Gregoire EHOUMI wrote: > Dear PDWG, > > This digest summarises the key points raised by community members (Ben, > Seun, and Sami) regarding this policy proposal, along with the authors? > clarifications and responses. > It is organised into four themes for easier reading. > > *1. Corrections & Clarifications* > *Mailing list freeze clarification:* > > - Comment (Ben): The RPD list was not frozen; only community?discuss > was moderated. > - *Response: *Acknowledged. The text will be corrected in Draft?2. It > was meant to say ? Inactive Resource Policy Discussion mailing list? > > > *2. Participation, Representation & Elections* > *Nomination support requirements:* > > - Comment (Seun): No need for supporters to be both AFRINIC members > and community members. > - *Response:* The intent is to ensure support from at least one > contact of the membership. Participants in the PDP and the WG activities > are generally classified in 2 categories: ?Registered contact of AFRINIC > member? and ? Non-registered contact of AFRINIC member? > > SO: Current participants of RPD do not need to be a ?Registered contact of AFRINIC member? OR ? Non-registered contact of AFRINIC member?, the PDWG is and should be open to any person interested in number policy development including non AFRINIC members. Note that there is a subtle difference between non-registered contact of AFRINIC member and a non-AFRINIC member. It should be okay to require support from either an AFRINIC member OR a community member, but the current text mandates both.To illustrate a nomination supported by 2 community members should pass just as a nomination supported by 2 afrinic member, likewise 1 afrinic member and 1 community member. > > *Who can vote in NRO NC elections:* > > - Comment (Seun): No reason to restrict voting to people in the region. > - *Response:* This follows existing AFRINIC rules. For NRO NC, only > participants from the region(excluding staff) vote. > > SO: My rationale is based on the premise that the rpd is open to all; hence, PDWG co-chair voters should not be restricted to in-region. By extension, NRO NC voters should be similar. Nevertheless considering past experiences, I agree there is merit in restricting voting to in-region but that discriminates on participation as voting is a form of participation as well. > > *3. Co?Chair Roles, Eligibility & Processes* > *Level of detail in co?chair responsibilities:* > > - Comment (Seun): Responsibilities in section 3.3.2 feel too granular > and policing. > - *Response: *The detail is intentional, based on RFC?2418 and other > RIRs practices, to avoid ambiguity. The WG should be predictable. > > SO: I do not know of an RIR process that is as granular in the responsibility of co-chairs as stated in 3.3.2. Section 6.1 of RFC 2418 that describes the role of a working group chair isn't as granular either. > > *Eligibility criteria ? meeting attendance:* > > - Comment (Seun): Requiring attendance at 4 of the last 6 PPMs > (including one in?person) may be unrealistic. > - *Response:* at the old rhythm of 2 PPMs a year, this requirement > means attending 4 of the 6 meetings held the last 3 years with at least > one in-person. With Attendance A=4 and Meetings M= 6, what would you > suggest for A and M? > > SO: Requiring in-person attendance is my main concern, it should not be mandatory. You may find at times that it is cheaper to travel out of Africa than within Africa, so not everyone can afford an in-person meeting. Let individual voters decide on candidates based on their historical participation. > > *Appointment by consensus:* > > - Comment (Seun): Consensus?based appointment could introduce > subjectivity. > - *Response:* This WG makes decisions by consensus with appeal > mechanisms in place. Appointing co-chairs via the same mechanisms should > not be a problem. With the requirements stated at section 3.3.3, it should > not be difficult to reach consensus on co-chairs candidates. While this may > not be perfect, it is used worldwide by various WGs. ?Community? votes > rather bring more subjectivity. > > > *Code of Conduct reference:* > > - Comment (Seun): Simply refer to AFRINIC?s CoC. > - *Response:* By referring to ?applicable CoC? the proposal avoids > attaching to a particular CoC. Today we are using the ?AFRINIC Community > CoC? elaborated by the board ( https://afrinic.net/code ), this may > change in the future. We saw some recent CoC discussions on the list. > > SO: Who determines which Code of Conduct (CoC) is "applicable" and which is not? > > *4. Governance Structure & Proposal Scope* > *Necessity of the Number Council:* > > - Comment (Seun): The Appeal Committee could perform the same role; > RNC may be unnecessary. > - *Response: *The RNC?s roles encompass calling PPM and appointing > interim co-chairs. So making the AC perform RNC?s role may not be > appropriate. > > What I am trying to communicate is that the RNC and its proposed roles are not required. There is value in having nomcom whose membership is more likely to change every year perform the role of getting nominations for PDWG Co-Chair. If both Co-Chairs resign, the Board should select one of the 3 NRO NC members to chair temporarily until a co-Chair is elected. > > *Splitting the proposal into smaller documents:* > > - Comment (Sami): Consider withdrawing and splitting into multiple > focused proposals. > - *Response:* The components are interdependent; splitting them would > create incoherent intermediate states and procedural gaps. > > SO: I looked at the problem enumerated below: - Adopted policy proposals not ratified or not implemented - No Public Policy Meeting - Non-renewal of co-chairs - Non-renewal of appeal and recall committees - Non-renewal of ASO AC/NRO NC representatives - Frozen Resource Policy Discussion mailing list The problems stated in the policy as listed above (apart from the last which has been corrected) all stemmed from the Board not having a quorum. The idea that the volunteer PDWG should or can effectively operate when there is no Board in the future is wishful thinking that should not be encouraged. In fact, the PDP operation is mandated by the bylaws, and the Board has the fiduciary responsibility to oversee the entire organisation. It therefore seems to me that this policy attempts to address a governance issue through policy rather than through the bylaws. Bylaws is the way to ensure that the events that happened with the Board in the past does not repeat itself. > > *Board ratification language:* > > - Comment (Seun): ?Shall? implies the Board must ratify; the Board > should be able to decline with reasons. > - *Response:* The text as written ?If a policy proposal approved by > the PDWG fails to be ratified by the board (inability or refusal by the > board without reasons for 60 days), a petition for ratification can be > initiated by a member of the PDWG.? it is meant to cover the two scenarios > below: > > 1. The Board is unable to act for 60 days (No quorum, No functioning > Board, Legal or operational paralysis, etc.) > 2. The Board refuses to ratify without giving reasons for 60 days (the > Board says ?no? but gives no justification, or The Board simply does > nothing and provides no explanation.) > Any suggestions to improve the text if it is not clear enough ? > SO: I think there may be a need to review the problem statement first so the rest of the document is better guided Regards > > > The authors thank the community for constructive feedback. > > Regards, > > Gr?goire > > > > On May 27, 2026, at 2:45?PM, Sami Salih wrote: > > Dear Colleagues, > > As a former PDWG Co-chair, I generally support the intent behind > strengthening the autonomy and operational continuity of the PDWG. The > policy development process ultimately belongs to the African Internet > community and should remain resilient regardless of operational or > governance challenges affecting AFRINIC as an organisation. > > At the same time, I believe it is important to recognize that this > proposal introduces substantial structural, operational, procedural, and > governance changes to the PDP framework. In many respects, this is a major > and transformative proposal rather than a routine procedural update. > > From my experience with the PDP, the community process tends to work best > when addressing clearly scoped issues through focused and > easy-to-understand proposals. In contrast, this proposal attempts to > address many different governance, electoral, operational, disciplinary, > and procedural matters simultaneously, which makes it difficult for the > community to fully analyse, discuss, and build meaningful consensus around > all aspects at once. > > IMHO, many of the ideas and intended improvements presented in this > proposal are constructive and deserve serious consideration. I also fully > acknowledge and respect the extensive experience, effort, and strategic > thinking of the authors in developing such a comprehensive framework > proposal. > > However, considering the breadth of the changes and the number of distinct > governance and operational matters being introduced simultaneously, my > respectful recommendation would be to consider withdrawing the current > proposal and restructuring this work into multiple smaller and more focused > proposals. I believe this would make it significantly easier for the > community to understand, analyse, discuss, and build meaningful consensus > around each individual topic independently, while improving overall > community engagement and participation in the process. > > With Regards, > Sami Sali. > > > Sami Salih > ------------------------------ > *From:* Seun Ojedeji > *Sent:* Monday, May 25, 2026 8:43:56 PM > *To:* dacostadarwin at gmail.com > *Cc:* rpd at afrinic.net > *Subject:* Re: [rpd] New Draft Policy Proposal - Amendment of the PDP > Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. > > Hello, > > Thanks for sharing this proposal. My initial comments after a brief review > are the following: > > - A typical community member could also be an AFRINIC member. There is no > reason to mandate that nomination supporters for the NRO NC must be both > community members and AFRINIC members. Requiring one or 2 supporters from > the service region should be sufficient. > > - The rpd is open to anyone that wishes to participate irrespective of > origin, region or residence. It sure makes sense to restrict election > participation to those with a historical record of involvement, either > online or in-person to avoid historical experience of DDOS on election > day. However, there is no reason to restrict the selectorate/electorate to > those in the region alone. > > - I do not see the necessity of a Number Committee; it seems to create yet > another layer. The Appeal committee which also serves as the recall > committee can perform any intended role of the RNC. Its composition could > be the 3 NRO NC members from the region, a past co-chair, and a past appeal > committee chair in a non-voting capacity. In situations where both > Co-Chairs are no more, the Chair of the Appeal committee can temporarily > take over until rpd appoints a new co-chair > > - As a former co-chair of PDWG, i find the proposed responsibilities of > the Co-chairs as described in section 3.3.2 to be overly granular and > quite policing-like for lack of a better word. > > - I believe the proposed 3.3.7 should refer to AFRINIC CoC and that should > be sufficient. The proposed penalties for violations look good, though they > are a bit too wordy to me and the process leading to that is quite > descriptive. We really need to give the co-chairs the privilege of managing > events as they deem applicable > > - The idea that a co-chair eligibility should be tied to attending > in-person meetings during a specific period isn't realistic given our > region's unique challenges. I understand it may be an effort to put a face > to the name but restricting eligibility to the last 2 years (which is > basically last 4 PPM) isn't realistic. > > - 3.3.3.3.3 suggests co-chairs will be appointed by consensus, that is an > interesting point that i would definitely not support. This can lead to > unnecessary subjectivity. > > - I like the expectation of participation from Co-Chair hence 3.3.4 > appeals to me as written. > > - Use of shall in 3.3.11 suggests that ratification is the only option for > the Board. There should be an option for the Board to provide reasons for > not ratifying and that should not be triggered by a petition. > > I may have more comments in future, but that is all from me for now. > > Regards > > On Mon, 25 May 2026 at 10:20, dacostadarwin at gmail.com < > dacostadarwin at gmail.com> wrote: > > Dear PDWG, > > We have received a new draft policy proposal - Amendment of the PDP > Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01 > from authors Gr?goire EHOUMI, Noah Maina and Adeola A. P. AINA. > > The proposal contents are published at: > https://afrinic.net/policy/proposals/afpub-2026-gen-001-draft01 > > We encourage you to take some time to go through the proposal contents > and provide feedback as follows : > > a) Do you support or oppose the proposal? > > b) If you oppose the proposal, state your reasons. > > c) Is there anything in the proposal that is not clear? > > d) What changes could be made to this proposal to make it more effective? > > Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > > -- > ------------------------------------------------------------------------ > > > *Seun Ojedeji, * > > Bringing another down does not take you up - think about your action! > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > -- ------------------------------------------------------------------------ *Seun Ojedeji,* Bringing another down does not take you up - think about your action! -------------- next part -------------- An HTML attachment was scrubbed... URL: From comms at afrinic.net Thu Jun 11 17:10:31 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Thu, 11 Jun 2026 19:10:31 +0200 Subject: [rpd] =?utf-8?q?AFRINIC_Elections_2026_=E2=80=93_Important_Regist?= =?utf-8?q?ration_Deadlines?= Message-ID: [Version en fran?ais au bas] Dear Colleagues, AFRINIC reminds all members and stakeholders participating in the AFRINIC Elections 2026 that the registration deadlines for election-related processes are approaching. AFRINIC-37 Public Policy Meeting Registration on the AIS?26 Registration Portal will close on Friday, 12 June 2026, at 12.00 PM UTC. Designated Representative Registration will also close on Friday, 12 June 2026, at 12.00 PM UTC. Members are encouraged to complete the necessary registration procedures before the deadline to ensure their eligibility to participate in the electoral process and exercise their voting rights. There will be no on-site registration. No new registrations or modifications will be accepted after the registration period closes. For further information and access to the relevant registration forms and election documentation, please consult the AFRINIC Elections 2026 information page (https://elections.afrinic.net/). Deadline: Friday, 12 June 2026. Members and stakeholders are advised not to wait until the last minute to submit their registrations. AFRINIC Communication [on behalf of the Election Committee] ______________________________________________________________ Fran?ais ?lections AFRINIC 2026 ? Dates limites ? retenir pour les inscriptions Chers membres de la communaut?, AFRINIC rappelle ? l'ensemble des membres et des parties prenantes participant aux ?lections AFRINIC 2026 que les dates limites d'inscription pour les processus li?s aux ?lections s?approchent ? grands pas. L'inscription ? la r?union de politique publique AFRINIC-37 sur le portail de l'AIS?26 sera cl?tur?e ce vendredi 12 juin 2026 ? 12 h 00 GMT. L'inscription des repr?sentants d?sign?s se cl?turera ?galement ce vendredi 12 juin 2026 ? 12 h 00 GMT Les membres sont encourag?s ? accomplir les proc?dures d'inscription n?cessaires avant la date limite afin de garantir leur ?ligibilit? pour participer au processus ?lectoral et exercer leur droit de vote. Il n'y aura aucune inscription sur place. Aucune nouvelle inscription ni modification ne sera accept?e apr?s la cl?ture de la p?riode d'inscription. Pour de plus amples informations et pour acc?der aux formulaires d'inscription correspondants ainsi qu'? la documentation ?lectorale, veuillez consulter la page d'information des ?lections AFRINIC 2026 (https://elections.afrinic.net/). Date limite : vendredi 12 juin 2026. Il est conseill? aux membres et les parties prenantes de ne pas attendre la derni?re minute pour soumettre leurs inscriptions. Communication d'AFRINIC [au nom du Comit? ?lectoral] -------------- next part -------------- An HTML attachment was scrubbed... URL: From comms at afrinic.net Fri Jun 12 13:01:47 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Fri, 12 Jun 2026 15:01:47 +0200 Subject: [rpd] =?utf-8?q?AIS=E2=80=9926_Meeting_Update=3A_The_Countdown_is?= =?utf-8?q?_On!?= Message-ID: <71DC2F7F-8862-4AFA-8A16-556550CCEE65@afrinic.net> Dear Colleagues, The countdown to Nairobi has begun! We counting days to the Africa Internet Summit (AIS?26) taking place from 22?26 June 2026 in Nairobi, Kenya. The AIS?26 promises a week of engaging discussions, policy development sessions, networking opportunities, and collaborative dialogue on the most pressing Internet issues facing Africa today. Registration Registration for onsite participation will close on Friday 12th June 2026 at 23:59EAT however, online registration will remain open. We strongly encourage you to register early to confirm your attendance.?Register here. Health, Safety and Travel Advisory The safety and well-being of all AIS?26 participants remain our highest priority. The AIS?26 Secretariat is working closely with public health authorities to ensure that appropriate health and safety measures are in place before and throughout the meeting. We will keep delegates informed should any additional travel or health advisories become necessary. More information available in the Security Assessment Report here . Agenda Highlights AIS?26 will feature five days of engaging technical, policy, governance, and Internet development discussions, bringing together experts, decision-makers, and practitioners from across Africa and beyond. Highlights include the Opening Ceremony, AF-Star Day, Government Roundtable, AfNOG Day, the AFRINIC-37 Public Policy Meeting, AFRINIC AGMM, ICANN Day, ISOC Day and Closing Ceremony. Visit the AIS?26 Agenda? for the full programme. Travel and Accommodation Information Delegates are encouraged to review Kenya?s entry requirements well in advance of their travel, as visa requirements may vary depending on nationality. If you require an invitation letter to support your visa application, you may request one here. Participants can also enjoy special accommodation rates negotiated exclusively for AIS?26 delegates through the official event accommodation options . To ensure a smooth arrival experience, delegates are advised to arrange airport transfers directly with their chosen hotel. To help you plan your journey and make the most of your stay in Nairobi, we have prepared a Practical Event Information Guide containing useful details on travel, accommodation, transportation, health and safety, local services, and other important information for AIS?26 attendees. Thank You to Our AIS?26 Sponsors AIS?26 would not be possible without the generous support of our sponsors and partners, whose continued investment helps advance the growth and development of Africa?s Internet ecosystem. We extend our sincere appreciation to the Africa Network Information Centre (AFRINIC), Technology Service Providers of Kenya (TESPOK), Internet Corporation for Assigned Names and Numbers (ICANN), Internet Society (ISOC), Africa Data Centres, Liquid Intelligent Technologies, Registry Africa, Vega Vision Software, London Internet Exchange (LINX), and Team Cymru for their invaluable support of this year's Summit. Updates and News You can keep informed with updates and the latest news about AIS?26 on the website . You can also follow us on twitter with the handle @AIS_Africa We are using the hashtag #AIS2026 For questions or assistance with logistics, feel free to reach us at: secretariat at internetsummit.africa Whether you?re a first-time attendee or a returning participant, we look forward to welcoming you to AIS?26 in Nairobi or connecting with you virtually. Karibu AIS?26! AIS?26 Secretariat. secretariat at internetsummit.africa ________________________________ Fran?ais Mise ? jour sur la r?union de l'AIS?26 : le compte ? rebours est lanc? ! Chers membres de la communaut?, Le compte ? rebours pour Nairobi a commenc? ! Nous comptons les jours qui nous s?parent du Sommet Africain de l'Internet (AIS?26) , qui se d?roulera du 22 au 26 juin 2026 ? Nairobi, au Kenya. L'AIS?26 promet une semaine de discussions passionnantes, de sessions d'?laboration de politiques, d'opportunit?s de r?seautage et de dialogues collaboratifs sur les enjeux internet les plus pressants auxquels l'Afrique fait face aujourd'hui. Inscription Les inscriptions pour une participation en pr?sentiel cl?tureront le lundi 12 juin 2026 ? 23h59 EAT. Toutefois, les inscriptions en ligne resteront ouvertes. Nous vous encourageons vivement ? vous inscrire rapidement afin de confirmer votre pr?sence. Inscrivez-vous ici . Avis sanitaire, de s?curit? et de voyage La s?curit? et le bien-?tre de tous les participants ? AIS?26 demeurent notre priorit? absolue. Le Secr?tariat d?AIS?26 travaille en ?troite collaboration avec les autorit?s de sant? publique afin de s?assurer que les mesures sanitaires et de s?curit? appropri?es soient en place avant et pendant toute la dur?e de la r?union. Nous tiendrons les d?l?gu?s inform?s si des recommandations suppl?mentaires en mati?re de voyage ou de sant? s?av?raient n?cessaires. De plus amples informations sont disponibles dans le rapport d'?valuation de la s?curit? ici . Points forts du programme L'AIS?26 proposera cinq jours de discussions captivantes sur les th?matiques techniques, politiques, de gouvernance et de d?veloppement de l'Internet, r?unissant des experts, des d?cideurs et des professionnels de toute l'Afrique et d'ailleurs. Les moments forts comprendront la c?r?monie d'ouverture, la journ?e AF-Star, la table ronde gouvernementale, la journ?e AfNOG, la r?union de politique publique d'AFRINIC-37, l'assembl?e g?n?rale annuelle d'AFRINIC, la journ?e de l'ICANN, la journ?e de l'ISOC et la c?r?monie de cl?ture. Consultez l'agenda de l'AIS?26 pour d?couvrir l'int?gralit? du programme. Informations sur le voyage et l'h?bergement Les d?l?gu?s sont invit?s ? v?rifier les conditions d'entr?e au Kenya bien avant leur voyage, les exigences en mati?re de visa pouvant varier selon la nationalit?. Si vous avez besoin d'une lettre d'invitation pour appuyer votre demande de visa, vous pouvez en faire la demande ici . Les participants peuvent ?galement b?n?ficier de tarifs pr?f?rentiels d'h?bergement, n?goci?s exclusivement pour les d?l?gu?s de l'AIS?26 aupr?s des ?tablissements partenaires officiels de l'?v?nement . Afin de garantir une arriv?e en toute s?r?nit?, il est conseill? aux d?l?gu?s d'organiser leurs transferts depuis l'a?roport directement avec l'h?tel de leur choix. Pour vous aider ? planifier votre voyage et ? profiter au mieux de votre s?jour ? Nairobi, nous avons pr?par? un guide d'informations pratiques sur l'?v?nement. Celui-ci contient des d?tails utiles sur le voyage, l'h?bergement, les transports, la sant? et la s?curit?, les services locaux, ainsi que d'autres renseignements importants pour les participants ? l'AIS?26. Merci ? nos sponsors de l'AIS?26 L'AIS?26 ne pourrait avoir lieu sans le g?n?reux soutien de nos sponsors et partenaires , dont l'investissement continu contribue ? faire progresser la croissance et le d?veloppement de l'?cosyst?me Internet en Afrique. Nous exprimons notre sinc?re gratitude au Centre d'information sur les r?seaux africains (AFRINIC), aux fournisseurs de services technologiques du Kenya (TESPOK), ? la Soci?t? pour l'attribution des noms de domaine et des num?ros sur Internet (ICANN), ? l'Internet Society (ISOC), ? Africa Data Centres, ? Liquid Intelligent Technologies, ? Registry Africa, ? Vega Vision Software, au London Internet Exchange (LINX) et ? Team Cymru pour leur pr?cieux soutien au Sommet de cette ann?e. Actualit?s et mises ? jour Vous pouvez vous tenir inform? des derni?res actualit?s et mises ? jour concernant l'AIS?26 sur le site web . Vous pouvez ?galement nous suivre sur Twitter via le compte @AIS_Africa Nous utilisons le hashtag #AIS2026 Pour toute question ou assistance logistique, n'h?sitez pas ? nous contacter ? l'adresse suivante : secretariat at internetsummit.africa Que vous participiez pour la premi?re fois ou que vous soyez un habitu? de l'?v?nement, nous nous r?jouissons de vous accueillir ? l'AIS?26 ? Nairobi ou de nous connecter avec vous virtuellement. Karibu AIS?26 ! Le secr?tariat de l'AIS?26. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at inter.link Fri Jun 12 13:09:55 2026 From: james at inter.link (James Bensley) Date: Fri, 12 Jun 2026 13:09:55 +0000 Subject: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. In-Reply-To: References: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> Message-ID: Hi All, An updated version of the proposal with all the community feedback is now available online: https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft02 Thank you all for supporting the proposal and providing feedback to improve it! With kind regards, James Bensley (he/him) > Dear PDWG, > > We have received a new draft policy proposal - Require newly created AS-SETs to have hierarchical names, ID AFPUB-2026-ASN-001-DRAFT01 from author James Bensley. > > The proposal contents are published at: > https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft01 > > We encourage you to take some time to go through the proposal contents and provide feedback as follows: > > a) Do you support or oppose the proposal? > > b) If you oppose the proposal, state your reasons? > > c) Is there anything in the proposal that is not clear? > > d) What changes could be made to this proposal to make it more effective? > > Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd [CompanySignature] Inter..link GmbH | Boxhagener Stra?e 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello at inter.link | Web: inter.link -------------- next part -------------- An HTML attachment was scrubbed... URL: From geier at geier.ne.tz Fri Jun 12 20:41:49 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Fri, 12 Jun 2026 23:41:49 +0300 Subject: [rpd] Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT01. In-Reply-To: References: <8D7B2583-4C94-4EA0-A02A-D885E2654403@gmail.com> Message-ID: <287d7c0d-6431-4e14-a9c0-b07e02a4b3be@geier.ne.tz> Hi all, I support this proposal in its new revision. I consider it very sad that the AFRINIC Staff Assessment is not available yet. (at https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft02#impact) Thanks, Frank Habicht On 6/12/2026 4:09 PM, James Bensley wrote: > Hi All, > > An updated version of the proposal with all the community feedback is > now available online: https://afrinic.net/policy/proposals/afpub-2026- > asn-001-draft02 asn-001-draft02> > > Thank you all for supporting the proposal and providing feedback to > improve it! > > With kind regards, > James Bensley (he/him) > > >> Dear PDWG, >> >> We have received a new draft policy proposal - Require newly created AS-SETs to have hierarchical names, ID AFPUB-2026-ASN-001-DRAFT01 from author James Bensley. >> >> The proposal contents are published at: >> https://afrinic.net/policy/proposals/afpub-2026-asn-001-draft01 > >> >> We encourage you to take some time to go through the proposal contents and? provide feedback as follows: >> >> a) Do you support or oppose the proposal? >> >> b) If you oppose the proposal, state your reasons? >> >> c) Is there anything in the proposal that is not clear? >> >> d) What changes could be made to this proposal to make it more effective? >> >> Regards, >> Vincent Ngundi & Darwin Da Costa >> AFRINIC PDWG Co-Chairs >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd lists.afrinic.net/mailman/listinfo/rpd> > > [CompanySignature] > Inter..link GmbH *|* Boxhagener Stra?e 80, 10245 Berlin, Germany *|* > Managing Directors: Marc Korthaus, Theo Voss *|* Commercial Register: > Amtsgericht Charlottenburg, HRB 138876 *|* VAT ID: DE281288887 *|* > Email: hello at inter.link *|* Web: inter.link > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From jordi.palet at consulintel.es Sun Jun 14 11:11:30 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Sun, 14 Jun 2026 13:11:30 +0200 Subject: [rpd] general question for the staff In-Reply-To: <21052128-6a2a-49b4-8e12-e8be656c9d13@afrinic.net> References: <494B50BC-E35B-49DF-B2C2-93F38F61F801@consulintel.es> <21052128-6a2a-49b4-8e12-e8be656c9d13@afrinic.net> Message-ID: Hi Madhvi, all, Tks, this is clear now I think. And exactly this: > However, if the Working Group deems it necessary, then a recommendation would be that: > > A consolidated guide or framework could be introduced to the Policy Manual with general reference to the RSA and Bylaws. Setting the high-level mandate for compliance reviews without prescribing specific, operational steps is beneficial. > > Specific details, such as timelines, notification stages, and reclamation steps, can be published by AFRINIC in separate publicly accessible operational document(s) and implementation notes for specific policies. ?. > is what the AFPUB-2026-GEN-002-DRAFT01 (AfriNIC Policy Compliance Dashboard), was doing in a very clear manner in the original version that was rejected considering that it was encroaching. Hopefully now that?s clear in the version that was submitted this time. If we can have the impact analysis before the 16th, we could still be have time to fix any issues. Regards, Jordi @jordipalet > El 3 jun 2026, a las 14:08, Policy Liaison Team via RPD escribi?: > > > Dear Jordi/PDWG > > We appreciate the inquiry regarding post-delegation follow-up and the subsequent comments shared by the working group members. Please find AFRINIC?s response below. > > The Registration Service Agreement (RSA) and Bylaws serve as the primary legal instruments governing the relationship between AFRINIC and its Resource Members. For this matter in particular, Clauses 4 and 6 of the RSA and 8.2 of the Bylaws outline the expected behaviours of members, including the mandatory requirement to comply with established policies. These clauses also provide the necessary legal basis for AFRINIC to take action when a member?s conduct or resource utilisation deviates from the policies. > > While it is important to ensure compliance, embedding specific post-delegation follow-up actions within applicable individual policies may present significant scalability and agility constraints as below: > > Managing unique per-policy mechanisms for every individual policy could lead to a complex administrative burden. > > Detailed operational steps within the Consolidated Policy Manual (CPM) can make it rigid to meet evolving administrative or technical needs without undergoing the full Policy Development Process (PDP). > > However, if the Working Group deems it necessary, then a recommendation would be that: > > A consolidated guide or framework could be introduced to the Policy Manual with general reference to the RSA and Bylaws. Setting the high-level mandate for compliance reviews without prescribing specific, operational steps is beneficial. > > Specific details, such as timelines, notification stages, and reclamation steps, can be published by AFRINIC in separate publicly accessible operational document(s) and implementation notes for specific policies. This ensures that the community understands the "how" while allowing the staff the flexibility to manage the process effectively and inline with any prevailing operational constraints. As reference , please see Section 5 of https://afrinic.net/reverse-dns and https://afrinic.net/20210428-lame-dns-delegation-policy > > The resource policies be drafted in clear and unambiguous text so that compliance or lack of compliance requires no additional interpretation > > Kind Regards > > Madhvi > > On 22/05/2026 14:01, jordi.palet--- via RPD wrote: >> Hi all, >> >> This point comes back frequently in discussions in different policy proposals, and I think we need to make it clear for once. >> >> For example, yesterday Sami requested to add some kind of text for post-allocation follow-up. >> >> I don?t think we have specific policy (other RIRs have it) for reclaim and recover, however, my understanding is that the existing RSA already enforces the policy compliance and AFRINIC may reclaim resources to any member that, for example, requested IPv4 or IPv6 addressing space with some specific plans, and after 1 or 2 years, the plans have been sensibly altered or even not complied at all, showing bad-faith on the original request. >> >> Is my interpretation correct and coincident with AFRINIC or we should add very specific text for any policy proposal (or a generic proposal for lack of compliance like in some other RIRs), for AFRINIC to ?verify? after a given period the compliance? >> >> I will understand that plans for an organization may change, but I think in those cases, the organization must for its own interest, have an alternative plan for the business continuity/business strategy changes and that should be re-addressed with AFRINIC, in case the allocation of resources need to be modified. >> >> I think a very clear (and urgent) response is needed in case we need to add some text into a new version of the current proposals under discussion before the dead line for a possible v2. >> >> Tks! >> >> Regards, >> Jordi >> >> @jordipalet >> >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > -- > AFRINIC Policy Liaison. > t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net > facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Sun Jun 14 11:23:30 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Sun, 14 Jun 2026 13:23:30 +0200 Subject: [rpd] possible update to AFPUB-2026-IPv4-002-DRAFT01 "Amendment of Utilisation in Soft Landing" Message-ID: Hi all, Pending from the impact analysis, if it comes in time before the 16th, i?ve worked in a possible v2 of this policy proposal, considering the previous discussion in the list. I?m sending this before official submission in order to seek further inputs, if they come in time before the deadline. The text I?m proposing is: The above requirement is waived for network operators requesting new IPv4 addresses for demonstrated key technical requirements, which can be illustrated to not be practically serviceable from existing assigned/allocated IPv4 resources ? such as redundancy and high-availability sites, IPv6 transition technologies, or expansion to new sites which pose a technical constraint on their current resource pool ? and in these cases, the request is treated as a first allocation or request. The request justification should be sufficiently documented, in such way that AFRINIC can verify the compliance with the provided justification. I believe the last sentence provides a valid way to avoid abusing the policy. I?m attaching (not sure if it will pass thru the list) a PDF of how it looks like in a comprehensive view. Regards, Jordi @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- A non-text attachment was scrubbed... Name: AfriNIC-Amendment of Utilisation in Soft Landing-v2.pdf Type: application/pdf Size: 176662 bytes Desc: not available URL: From jordi.palet at consulintel.es Sun Jun 14 11:41:40 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Sun, 14 Jun 2026 13:41:40 +0200 Subject: [rpd] possible update to AFPUB-2026-v6-001-DRAFT01 "IPv6 as a criteria in IPv4 Soft Landing" Message-ID: <501FD190-164C-4672-9A2D-39465BAA7A77@consulintel.es> Hi all, As in my previous email, pending from the impact analysis, if it comes in time before the 16th, i?ve worked in a possible v2 of this policy proposal, considering the previous discussion in the list. I?m sending this before official submission in order to seek further inputs, if they come in time before the deadline. The text I?m proposing is: "Any IPv4 request must be done with a simultaneous IPv6 request if the requesting party does not already have IPv6 space. Regardless of if the IPv6 requests was already done previously or simultaneously with the IPv4 request, the relevant allocation/assignment criteria conditions must be met. In addition, a coherent IPv6 deployment and addressing plan, must be presented clearly showing how will be met: a) 6.5.1.1.3 and 6.5.1.1.4, in the case of LIRs. b) 6.8.2.2.d, in the case of end-users. The IPv6 deployment plan must show the actual IPv4 top-25 traffic destinations of that network. For each of those external destinations that are IPv6-enabled, the following minimum IPv6 % will be considered as compliant: ? 25% in a maximum of 12 months. ? 50% in a maximum of 24 months. ? 75% in a maximum of 48 months. In case of networks hosting any kind of services, applications or contents, will be considered as compliant when matching the following % of AAAA RRs available and IPv6 reachable from Internet: ? 25% in a maximum of 12 months. ? 75% in a maximum of 24 months. ? 95% in a maximum of 48 months. Failure to comply with the IPv6 deployment plan according to the relevant criteria, imply an IPv4 Soft Landing Policy breach." Existing IPv6 worldwide deployment experience shows that those % are easily achievable. Actually 75-85% in terms of destinations can be achieved in just a few months once the deployment is done, and same for the AAAA RRs, should not be a problem to set 100% of the services with *working and reachable* IPv6 AAAAs also in a matter of few months. So the figures are really conservative, for the 1st and 2nd year and only going to the 4th year for a ?complete? deployment. I?m attaching (not sure if it will pass thru the list) a PDF of how it looks like in a comprehensive view. Regards, Jordi @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- A non-text attachment was scrubbed... Name: AfriNIC-IPv6 as a criteria in IPv4 Soft Landing-v2.pdf Type: application/pdf Size: 211949 bytes Desc: not available URL: From amelnaud at gmail.com Sun Jun 14 15:37:41 2026 From: amelnaud at gmail.com (Arnaud AMELINA) Date: Sun, 14 Jun 2026 15:37:41 +0000 Subject: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. In-Reply-To: <1EC212BF-EA11-4FB4-B5C4-B7429FFE6209@gmail.com> References: <1EC212BF-EA11-4FB4-B5C4-B7429FFE6209@gmail.com> Message-ID: Hi PDW members, Hi AK, Are you suggesting that decisions made by consensus by the WG are lawless? Regards > >+1 to Seun except that I agree that only people from the region should vote. > > > >I do not think Seun's concerns have been addressed, especially on: below > >and I have a few additional concerns > >1. Responsibilities in section 3.3.2 feel too granular and policing. > > > >2. Requiring attendance at 4 of the last 6 PPMs (including one in?person) > >may be unrealistic. (I totally agree to this except if the requirement is > >personal funding for the one meeting.) Physical attendance does not show > >commitment; it?s about opportunities most times. > > > >3. Consensus?based appointment could introduce subjectivity. I totally > >agree with this; it brings not just subjectivity but anarchy and > >lawlessness. > > > > 4. Registered PPM attendee voting... Does this include online attendees? > >Then I think we need to make up our mind on who should vote. My suggestion > >is members only should vote. > > > > 5. I totally disagree with having a recall committee and having recall > >committee decisions being final. This is subject to manipulation and abuse, > >and the chair is entirely at the mercy of few individuals called the recall > >committee. This is because the recall committee doesn?t appoint chairs, > >neither do 10 members appoint chairs. To remove chairs must be subjected to > >the same process as electing a chair. There must be a general vote with > >majority agreeing to recall the chair. > > > > > > > >*AK.* > > > > > > *Prof Abdulkarim Oloyede* > *Professor of Wireless Telecommunications * > *University of Ilorin. * > > On Tue, Jun 9, 2026, 9:34?PM Gregoire EHOUMI via RPD > > wrote: > > >* Dear PDWG, > *>>* This digest summarises the key points raised by community members (Ben, > *>* Seun, and Sami) regarding this policy proposal, along with the authors? > *>* clarifications and responses. > *>* It is organised into four themes for easier reading. > *>>* *1. Corrections & Clarifications* > *>* *Mailing list freeze clarification:* > *>>* - Comment (Ben): The RPD list was not frozen; only community?discuss > *>* was moderated. > *>* - *Response: *Acknowledged. The text will be corrected in Draft?2. It > *>* was meant to say ? Inactive Resource Policy Discussion mailing list? > *>>>* *2. Participation, Representation & Elections* > *>* *Nomination support requirements:* > *>>* - Comment (Seun): No need for supporters to be both AFRINIC members > *>* and community members. > *>* - *Response:* The intent is to ensure support from at least one > *>* contact of the membership. Participants in the PDP and the WG activities > *>* are generally classified in 2 categories: ?Registered contact of AFRINIC > *>* member? and ? Non-registered contact of AFRINIC member? > *>>>* *Who can vote in NRO NC elections:* > *>>* - Comment (Seun): No reason to restrict voting to people in the region. > *>* - *Response:* This follows existing AFRINIC rules. For NRO NC, only > *>* participants from the region(excluding staff) vote. > *>>>* *3. Co?Chair Roles, Eligibility & Processes* > *>* *Level of detail in co?chair responsibilities:* > *>>* - Comment (Seun): Responsibilities in section 3.3.2 feel too granular > *>* and policing. > *>* - *Response: *The detail is intentional, based on RFC?2418 and other > *>* RIRs practices, to avoid ambiguity. The WG should be predictable. > *>>>* *Eligibility criteria ? meeting attendance:* > *>>* - Comment (Seun): Requiring attendance at 4 of the last 6 PPMs > *>* (including one in?person) may be unrealistic. > *>* - *Response:* at the old rhythm of 2 PPMs a year, this requirement > *>* means attending 4 of the 6 meetings held the last 3 years with at least > *>* one in-person. With Attendance A=4 and Meetings M= 6, what would you > *>* suggest for A and M? > *>>>* *Appointment by consensus:* > *>>* - Comment (Seun): Consensus?based appointment could introduce > *>* subjectivity. > *>* - *Response:* This WG makes decisions by consensus with appeal > *>* mechanisms in place. Appointing co-chairs via the same mechanisms should > *>* not be a problem. With the requirements stated at section 3.3.3, it should > *>* not be difficult to reach consensus on co-chairs candidates. While this may > *>* not be perfect, it is used worldwide by various WGs. ?Community? votes > *>* rather bring more subjectivity. > *>>>* *Code of Conduct reference:* > *>>* - Comment (Seun): Simply refer to AFRINIC?s CoC. > *>* - *Response:* By referring to ?applicable CoC? the proposal avoids > *>* attaching to a particular CoC. Today we are using the ?AFRINIC Community > *>* CoC? elaborated by the board ( https://afrinic.net/code ), this may > *>* change in the future. We saw some recent CoC discussions on the list. > *>>>* *4. Governance Structure & Proposal Scope* > *>* *Necessity of the Number Council:* > *>>* - Comment (Seun): The Appeal Committee could perform the same role; > *>* RNC may be unnecessary. > *>* - *Response: *The RNC?s roles encompass calling PPM and appointing > *>* interim co-chairs. So making the AC perform RNC?s role may not be > *>* appropriate. > *>>>* *Splitting the proposal into smaller documents:* > *>>* - Comment (Sami): Consider withdrawing and splitting into multiple > *>* focused proposals. > *>* - *Response:* The components are interdependent; splitting them would > *>* create incoherent intermediate states and procedural gaps. > *>>>* *Board ratification language:* > *>>* - Comment (Seun): ?Shall? implies the Board must ratify; the Board > *>* should be able to decline with reasons. > *>* - *Response:* The text as written ?If a policy proposal approved by > *>* the PDWG fails to be ratified by the board (inability or refusal by the > *>* board without reasons for 60 days), a petition for ratification can be > *>* initiated by a member of the PDWG.? it is meant to cover the two scenarios > *>* below: > *>>* 1. The Board is unable to act for 60 days (No quorum, No functioning > *>* Board, Legal or operational paralysis, etc.) > *>* 2. The Board refuses to ratify without giving reasons for 60 days (the > *>* Board says ?no? but gives no justification, or The Board simply does > *>* nothing and provides no explanation.) > *>* Any suggestions to improve the text if it is not clear enough ? > *>>>* The authors thank the community for constructive feedback. > *>>* Regards, > *>>* Gr?goire > *>>>>* On May 27, 2026, at 2:45?PM, Sami Salih > wrote: > *>>* Dear Colleagues, > *>>* As a former PDWG Co-chair, I generally support the intent behind > *>* strengthening the autonomy and operational continuity of the PDWG. The > *>* policy development process ultimately belongs to the African Internet > *>* community and should remain resilient regardless of operational or > *>* governance challenges affecting AFRINIC as an organisation. > *>>* At the same time, I believe it is important to recognize that this > *>* proposal introduces substantial structural, operational, procedural, and > *>* governance changes to the PDP framework. In many respects, this is a major > *>* and transformative proposal rather than a routine procedural update. > *>>* From my experience with the PDP, the community process tends to work best > *>* when addressing clearly scoped issues through focused and > *>* easy-to-understand proposals. In contrast, this proposal attempts to > *>* address many different governance, electoral, operational, disciplinary, > *>* and procedural matters simultaneously, which makes it difficult for the > *>* community to fully analyse, discuss, and build meaningful consensus around > *>* all aspects at once. > *>>* IMHO, many of the ideas and intended improvements presented in this > *>* proposal are constructive and deserve serious consideration. I also fully > *>* acknowledge and respect the extensive experience, effort, and strategic > *>* thinking of the authors in developing such a comprehensive framework > *>* proposal. > *>>* However, considering the breadth of the changes and the number of distinct > *>* governance and operational matters being introduced simultaneously, my > *>* respectful recommendation would be to consider withdrawing the current > *>* proposal and restructuring this work into multiple smaller and more focused > *>* proposals. I believe this would make it significantly easier for the > *>* community to understand, analyse, discuss, and build meaningful consensus > *>* around each individual topic independently, while improving overall > *>* community engagement and participation in the process. > *>>* With Regards, > *>* Sami Sali. > *>>>* Sami Salih > *>* ------------------------------ > *>* *From:* Seun Ojedeji > > *>* *Sent:* Monday, May 25, 2026 8:43:56 PM > *>* *To:* dacostadarwin at gmail.com > > *>* *Cc:* rpd at afrinic.net > > *>* *Subject:* Re: [rpd] New Draft Policy Proposal - Amendment of the PDP > *>* Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. > *>>* Hello, > *>>* Thanks for sharing this proposal. My initial comments after a brief review > *>* are the following: > *>>* - A typical community member could also be an AFRINIC member. There is no > *>* reason to mandate that nomination supporters for the NRO NC must be both > *>* community members and AFRINIC members. Requiring one or 2 supporters from > *>* the service region should be sufficient. > *>>* - The rpd is open to anyone that wishes to participate irrespective of > *>* origin, region or residence. It sure makes sense to restrict election > *>* participation to those with a historical record of involvement, either > *>* online or in-person to avoid historical experience of DDOS on election > *>* day. However, there is no reason to restrict the selectorate/electorate to > *>* those in the region alone. > *>>* - I do not see the necessity of a Number Committee; it seems to create yet > *>* another layer. The Appeal committee which also serves as the recall > *>* committee can perform any intended role of the RNC. Its composition could > *>* be the 3 NRO NC members from the region, a past co-chair, and a past appeal > *>* committee chair in a non-voting capacity. In situations where both > *>* Co-Chairs are no more, the Chair of the Appeal committee can temporarily > *>* take over until rpd appoints a new co-chair > *>>* - As a former co-chair of PDWG, i find the proposed responsibilities of > *>* the Co-chairs as described in section 3.3.2 to be overly granular and > *>* quite policing-like for lack of a better word. > *>>* - I believe the proposed 3.3.7 should refer to AFRINIC CoC and that should > *>* be sufficient. The proposed penalties for violations look good, though they > *>* are a bit too wordy to me and the process leading to that is quite > *>* descriptive. We really need to give the co-chairs the privilege of managing > *>* events as they deem applicable > *>>* - The idea that a co-chair eligibility should be tied to attending > *>* in-person meetings during a specific period isn't realistic given our > *>* region's unique challenges. I understand it may be an effort to put a face > *>* to the name but restricting eligibility to the last 2 years (which is > *>* basically last 4 PPM) isn't realistic. > *>>* - 3.3.3.3.3 suggests co-chairs will be appointed by consensus, that is an > *>* interesting point that i would definitely not support. This can lead to > *>* unnecessary subjectivity. > *>>* - I like the expectation of participation from Co-Chair hence 3.3.4 > *>* appeals to me as written. > *>>* - Use of shall in 3.3.11 suggests that ratification is the only option for > *>* the Board. There should be an option for the Board to provide reasons for > *>* not ratifying and that should not be triggered by a petition. > *>>* I may have more comments in future, but that is all from me for now. > *>>* Regards > *>>* On Mon, 25 May 2026 at 10:20, dacostadarwin at gmail.com < > *>* dacostadarwin at gmail.com > wrote: > *>>* Dear PDWG, > *>>* We have received a new draft policy proposal - Amendment of the PDP > *>* Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01 > *>* from authors Gr?goire EHOUMI, Noah Maina and Adeola A. P. AINA. > *>>* The proposal contents are published at: > *>* https://afrinic.net/policy/proposals/afpub-2026-gen-001-draft01 > *>>* We encourage you to take some time to go through the proposal contents > *>* and provide feedback as follows : > *>>* a) Do you support or oppose the proposal? > *>>* b) If you oppose the proposal, state your reasons. > *>>* c) Is there anything in the proposal that is not clear? > *>>* d) What changes could be made to this proposal to make it more effective? > *>>* Regards, > *>* Vincent Ngundi & Darwin Da Costa > *>* AFRINIC PDWG Co-Chairs > *>* _______________________________________________ > *>* RPD mailing list > *>* RPD at afrinic.net > *>* https://lists.afrinic.net/mailman/listinfo/rpd > *>>>>* -- > *>* ------------------------------------------------------------------------ > *>>>* *Seun Ojedeji, * > *>>* Bringing another down does not take you up - think about your action! > *>>>* _______________________________________________ > *>* RPD mailing list > *>* RPD at afrinic.net > *>* https://lists.afrinic.net/mailman/listinfo/rpd > *>>>* _______________________________________________ > *>* RPD mailing list > *>* RPD at afrinic.net > *>* https://lists.afrinic.net/mailman/listinfo/rpd > *> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sami.salih at outlook.com Sun Jun 14 19:55:06 2026 From: sami.salih at outlook.com (Sami Salih) Date: Sun, 14 Jun 2026 19:55:06 +0000 Subject: [rpd] possible update to AFPUB-2026-IPv4-002-DRAFT01 "Amendment of Utilisation in Soft Landing" In-Reply-To: References: Message-ID: Hi Jordi, Based on my previous comments and the new simplified update you provided, I would support this proposal if the following amendment is incorporated: "The evaluation of requests submitted under this exception shall be conducted by AFRINIC staff based on the information and supporting documentation provided by the applicant. AFRINIC reserves the sole discretion to determine whether the demonstrated technical requirements satisfy the conditions of this provision. The decision of AFRINIC regarding such requests shall be final for the purposes of resource evaluation under this policy. AFRINIC may, at its discretion, provide feedback regarding the basis for a denial, but shall not be obligated to provide detailed technical assessments or recommendations." I believe this amendment is important for several reasons. First, the proposed exception introduces a degree of subjective technical assessment that cannot be fully codified within the policy text. As a result, AFRINIC staff must retain the necessary discretion to evaluate whether a request genuinely satisfies the stated technical requirements. Second, the amendment provides clarity regarding roles and responsibilities by making it explicit that the evaluation is an operational function carried out by AFRINIC staff, rather than a matter for policy interpretation or community debate on a case-by-case basis. Third, requiring AFRINIC to provide detailed technical justifications or recommendations for every rejected request could create unnecessary administrative burden, encourage repeated challenges to operational decisions, and potentially divert resources from the efficient processing of resource requests. Finally, the amendment helps ensure consistency, predictability, and operational efficiency in the implementation of the policy while preserving AFRINIC's ability to provide feedback where it considers it useful and appropriate. With this amendment included, I believe the proposal would achieve its intended objective while reducing ambiguity in its implementation and strengthening the overall governance of the evaluation process. With regards, Sami Salih. ________________________________ From: jordi.palet--- via RPD Sent: Sunday, June 14, 2026 2:23 PM To: RPD Subject: [rpd] possible update to AFPUB-2026-IPv4-002-DRAFT01 "Amendment of Utilisation in Soft Landing" Hi all, Pending from the impact analysis, if it comes in time before the 16th, i?ve worked in a possible v2 of this policy proposal, considering the previous discussion in the list. I?m sending this before official submission in order to seek further inputs, if they come in time before the deadline. The text I?m proposing is: The above requirement is waived for network operators requesting new IPv4 addresses for demonstrated key technical requirements, which can be illustrated to not be practically serviceable from existing assigned/allocated IPv4 resources ? such as redundancy and high-availability sites, IPv6 transition technologies, or expansion to new sites which pose a technical constraint on their current resource pool ? and in these cases, the request is treated as a first allocation or request. The request justification should be sufficiently documented, in such way that AFRINIC can verify the compliance with the provided justification. I believe the last sentence provides a valid way to avoid abusing the policy. I?m attaching (not sure if it will pass thru the list) a PDF of how it looks like in a comprehensive view. Regards, Jordi @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From honlue at gmail.com Mon Jun 15 02:28:42 2026 From: honlue at gmail.com (Musa Stephen Honlue) Date: Mon, 15 Jun 2026 04:28:42 +0200 Subject: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. In-Reply-To: <10461E18-A0FF-4DC9-B232-B23D572F591B@afrinic.net> References: <10461E18-A0FF-4DC9-B232-B23D572F591B@afrinic.net> Message-ID: <1CF0DF8A-2DA5-4E52-ADAC-3D31DA02E693@gmail.com> Neither the RPD nor the community list was frozen. The community list was put under moderation and still is, I think. What that means is that any mail sent to that list needs to be approved by someone at AFRINIC before it is forwarded to the rest of the list. And I think the board should wave that moderation because it has significantly paralised community interactions. Sent from my iPhone > On 25 May 2026, at 18:14, Ben Roberts - AfriNIC via RPD wrote: > > ?I don?t think the RPD list was frozen during Afrinic?s period of stagnation? Only the community discuss list was frozen. > > > Sent from my iPhone > >> On 25 May 2026, at 18:21, dacostadarwin at gmail.com wrote: >> >> ?Dear PDWG, >> >> We have received a new draft policy proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01 from authors Gr?goire EHOUMI, Noah Maina and Adeola A. P. AINA. >> >> The proposal contents are published at: https://afrinic.net/policy/proposals/afpub-2026-gen-001-draft01 >> >> We encourage you to take some time to go through the proposal contents and provide feedback as follows : >> >> a) Do you support or oppose the proposal? >> >> b) If you oppose the proposal, state your reasons. >> >> c) Is there anything in the proposal that is not clear? >> >> d) What changes could be made to this proposal to make it more effective? >> >> Regards, >> Vincent Ngundi & Darwin Da Costa >> AFRINIC PDWG Co-Chairs >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From seun.ojedeji at gmail.com Mon Jun 15 02:29:23 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Sun, 14 Jun 2026 21:29:23 -0500 Subject: [rpd] possible update to AFPUB-2026-IPv4-002-DRAFT01 "Amendment of Utilisation in Soft Landing" In-Reply-To: References: Message-ID: Hello Jordi, I want to be sure i understand your intent of the section below: "....and in these cases, the request is treated as a first allocation or request..." Does it mean that the exception will only be granted once to member? if that is the case i agree, if that is not the case, then i disagree. I think there should be a limit to the round trip per qualified member. I will also suggest a minor edit as per below: "The above requirement of 90% is waived for network operators...." Regards On Sun, 14 Jun 2026 at 06:24, jordi.palet--- via RPD wrote: > Hi all, > > Pending from the impact analysis, if it comes in time before the 16th, > i?ve worked in a possible v2 of this policy proposal, considering the > previous discussion in the list. > > I?m sending this before official submission in order to seek further > inputs, if they come in time before the deadline. > > The text I?m proposing is: > > The above requirement is waived for network operators requesting new IPv4 > addresses for demonstrated key technical requirements, which can be > illustrated to not be practically serviceable from existing > assigned/allocated IPv4 resources ? such as redundancy and > high-availability sites, IPv6 transition technologies, or expansion to new > sites which pose a technical constraint on their current resource pool ? > and in these cases, the request is treated as a first allocation or > request. The request justification should be sufficiently documented, in > such way that AFRINIC can verify the compliance with the provided > justification. > > I believe the last sentence provides a valid way to avoid abusing the > policy. > > I?m attaching (not sure if it will pass thru the list) a PDF of how it > looks like in a comprehensive view. > > Regards, > Jordi > > @jordipalet > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > ---- Sent from my mobile kindly excuse typos -------------- next part -------------- An HTML attachment was scrubbed... URL: From ayoolaolatunji at dasamonie.com Mon Jun 15 06:14:27 2026 From: ayoolaolatunji at dasamonie.com (Ayoolaolatunji@dasamonie.com) Date: Mon, 15 Jun 2026 06:14:27 +0000 (UTC) Subject: [rpd] RPD Digest, Vol 221, Issue 20 In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: From baya.sylvain at cmnog.cm Mon Jun 15 06:36:56 2026 From: baya.sylvain at cmnog.cm (Sylvain BAYA) Date: Mon, 15 Jun 2026 07:36:56 +0100 Subject: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01. In-Reply-To: <29E79A7F-BF80-44DE-8B67-45521A95F2FB@consulintel.es> References: <29E79A7F-BF80-44DE-8B67-45521A95F2FB@consulintel.es> Message-ID: {sent with a registered email address now!} {i hope i'm not too late to add my comment!} Le 21/05/2026 ? 14:28, jordi.palet--- via RPD a ?crit?: > Hi all, > [...] > Comments welcome! > Hi Jordi, Thanks for your email, brother. It's my pleasure to be able to review the DPP (Draft Policy Proposal)! > Tks! > > Regards, > Jordi > > @jordipalet > > >> El 15 may 2026, a las 17:51,dacostadarwin at gmail.com escribi?: >> >> Dear PDWG, >> >> We have received a new draft policy proposal - Amendment of Utilisation in Soft Landing, ID AFPUB-2026-IPv4-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >> >> https://afrinic.net/policy/proposals/afpub-2026-ipv4-002-draft01 >> >> We encourage you to take some time to go through the proposal contents and provide feedback as follows : >> Dear PDWG, Do kindly consider my review of the AFPUB-2026-IPv4-002-DRAFT01 DPP (Draft Policy Proposal) below. 1. Summary of the problem being addressed by this proposal The Soft-Landing utilisation criteria is preventing organisations that may have multiple sites, redundancy or high availability needs to achieve that, because section 5.4.6.1 states that 90% of the previous allocations or assignments must have been used. For example, an end-user member may have received a /24 for a Data Centre and now is setting up new Data Centres. Current policy will not allow that until 90% of the first Data Centre prefix is utilised. Another example may be an ISP, with multiple BGP PoPs, setting up 464XLAT in the network, with NAT64 devices in each PoP for high-availability purposes. Normally it will announce a /22-/24 in each PoP, even if all the addresses are not being used simultaneously all the time, so 90% utilisation is not allowing that deployment offering high-availability to the subscribers. ...maybe the Policy Liaison Team could tell us more about the number of such requests; the hostmaster is actually unable to satisfy. This problem seems to be reasonable; but i have a small doubt on the urgency; of these situation. Can we found at least three Orgs per case? prior to validate the problem which is formulated here. 2. Summary of how this proposal addresses the problem This proposal suggests that the utilisation criteria should allow cases such as those in the previous examples and similar ones. Because the 3 million IPv4 recovered addresses, this change will not create an immediate drain of the AFRINIC pool, and instead, can help to increase the number of DC and high-availability, IPv6 deployment and better connectivity for the region. 3 million IPv4 recovered ~ /11 + /12 2?? + 2?? =?3145728?? ...while the problem, as formulated, might be validated (by real facts); i think if we want to keep "one shop", then it's necessary to keep the same definition of "first allocation"; for instance. Proposed ~~5.4.6.1 In order to receive?IPv4?allocations or assignments during the Exhaustion Phase, the LIR or End User must have used at least 90% of all previous allocations or assignments (including those made during both the Current Phase and the Exhaustion Phase) In the case of new LIRs or End Users with no previous allocations or assignments, this requirement does not apply to their first allocation or assignment request.~~ "The above requirement is waived for network operators requesting new IP addresses for key technical needs ? such as redundancy and high-availability sites,?IPv6?transition technologies, or expansion to new sites which pose a technical constraint on their current resource pool ? and in these cases, the request is treated as a first allocation or request." ...i disagree with the above approach; as it looks like a less optimal approach. It goes without saying that when a first allocation or assignment exists, any resource holder should be treated same as all the others in same conditions. What could be done, imho, if the edge cases you have described are proved true; should be to consider a different approach in order to address their specificity. ...if applicable; then i would suggest the text below as a replacement to the part of text between double quotes above: "If a resource member (being a LIR or an End-user) can prove that its actual need for IPv4 resources can not be satisfied by its available allocation/assignment, even in case of a percentage of utilization lower than 90 %; then notwithstanding the above requirements, the requesting resource member shall be *specially considered* eligible to receive a new allocation or assignment. This *special consideration* shall also be applicable to a new LIR or End-user, with similar structural needs in IPv4 resources. In that case, the given LIR or End-user shall be *specially considered* eligible to receive a two allocations or assignments; to begin with." *4. References* In other regions, all?IPv4?addresses have been exhausted and it seems that the equivalent to the soft-landing is not any more an issue, because most of the existing members only can access?IPv4?addresses via transfers. ? ...i have found a counter-example to the above statement; see, brother: ARIN NRPM Section 4.1.8 *. ARIN Waitlist*. Do kindly include this precision, to your "References" section (4.), as you go. Thanks. Shalom, --sb. >> a) Do you support or oppose the proposal? >> b) If you oppose the proposal, state your reasons? >> c) Is there anything in the proposal that is not clear? >> d) What changes could be made to this proposal to make it more effective? >> >> Regards, >> Vincent Ngundi & Darwin Da Costa >> AFRINIC PDWG Co-Chairs >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > [...] > -- Best Regards ! baya.sylvain [AT cmNOG DOT cm] | cmNOG's Structure | CAMIX's Website | Douala-IX's Looking Glass | cmNOG's Surveys | Subscribe to cmNOG's Mailing List | __ #LASAINTEBIBLE|#Eph?siens5:18,15-21?[...] 18 Et *_ne vous enivrez_* pas *_de vin_*, en quoi *_il y a de la dissolution_*; mais *_soyez remplis de l'Esprit_*, [...]? ?#LASAINTEBIBLE|#H?breux13:9,5-15?[...] 9 _*Ne soyez pas seduits par*_ des _*doctrines diverses*_ et _*etrangeres*_, car il est bon _*que le coeur soit affermi par la grace*_, non par les viandes, lesquels n'ont pas profite ? ceux qui y ont marche. [...]? #AMEN,#Maranatha,#MerciJ?SUS! #?MaPri?re? est que tu naisses de nouveau.#Chr?tiennement -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x0387408365AC8594.asc Type: application/pgp-keys Size: 19438 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From jordi.palet at consulintel.es Mon Jun 15 06:57:03 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Mon, 15 Jun 2026 08:57:03 +0200 Subject: [rpd] possible update to AFPUB-2026-IPv4-002-DRAFT01 "Amendment of Utilisation in Soft Landing" In-Reply-To: References: Message-ID: <8CB91D38-B8C9-4AC9-85C7-96C9B88E3F89@consulintel.es> Hi Sami, See below in line. Also it will be good if the staff can confirm if my responses below are correct or I?m missing something. Regards, Jordi @jordipalet > El 14 jun 2026, a las 21:55, Sami Salih escribi?: > > Hi Jordi, > Based on my previous comments and the new simplified update you provided, I would support this proposal if the following amendment is incorporated: > "The evaluation of requests submitted under this exception shall be conducted by AFRINIC staff based on the information and supporting documentation provided by the applicant. AFRINIC reserves the sole discretion to determine whether the demonstrated technical requirements satisfy the conditions of this provision. This is already true for *any* justification provided for any request of number resources. In fact it is defined in section 3 of the RSA. If you provide information that is not sufficient to justify the request, AFRINIC will tell you ?we need more info, we need to clarify this, etc.?. Same for the 2nd sentence. In AFRINIC there is no escalation procedure in the CPM for a denial of any resources request. > The decision of AFRINIC regarding such requests shall be final for the purposes of resource evaluation under this policy. AFRINIC may, at its discretion, provide feedback regarding the basis for a denial, but shall not be obligated to provide detailed technical assessments or recommendations." This will contradict the RSA, with defines in section 13 the ?right of appeal?. The CPM can?t contradict that, because it will mean the board can?t ratify the proposal (if it reaches consensus). > I believe this amendment is important for several reasons. > First, the proposed exception introduces a degree of subjective technical assessment that cannot be fully codified within the policy text. As a result, AFRINIC staff must retain the necessary discretion to evaluate whether a request genuinely satisfies the stated technical requirements. In general, there is always some degree of subjectivity in many requests to a RIR. It depends a lot on the documentation that you provide, so is the requester the one responsible to make a clear documentation. > Second, the amendment provides clarity regarding roles and responsibilities by making it explicit that the evaluation is an operational function carried out by AFRINIC staff, rather than a matter for policy interpretation or community debate on a case-by-case basis. This is always the case, we need to trust the RIR staff, otherwise, we will enter into a never-ending micromanagement cycle. If the staff discover that something is not going well, they can 1) warn the community when reviewing the proposal thru the impact analysis, 2) if the proposal was already implemented, explain the issues via the PIER as they already do. Also the community can discover issues in any implemented policy, and they have the right to query the staff and submit proposals to resolve the issues. > Third, requiring AFRINIC to provide detailed technical justifications or recommendations for every rejected request could create unnecessary administrative burden, encourage repeated challenges to operational decisions, and potentially divert resources from the efficient processing of resource requests. Again, this is true for any existing policies. With any new implemented policy, this may happen, and the staff is able to create a procedures, templates, or whatever, to guide the members in how to correctly send the request. > Finally, the amendment helps ensure consistency, predictability, and operational efficiency in the implementation of the policy while preserving AFRINIC's ability to provide feedback where it considers it useful and appropriate. > With this amendment included, I believe the proposal would achieve its intended objective while reducing ambiguity in its implementation and strengthening the overall governance of the evaluation process. > With regards, > Sami Salih. > From: jordi.palet--- via RPD > > Sent: Sunday, June 14, 2026 2:23 PM > To: RPD > > Subject: [rpd] possible update to AFPUB-2026-IPv4-002-DRAFT01 "Amendment of Utilisation in Soft Landing" > > Hi all, > > Pending from the impact analysis, if it comes in time before the 16th, i?ve worked in a possible v2 of this policy proposal, considering the previous discussion in the list. > > I?m sending this before official submission in order to seek further inputs, if they come in time before the deadline. > > The text I?m proposing is: > > The above requirement is waived for network operators requesting new IPv4 addresses for demonstrated key technical requirements, which can be illustrated to not be practically serviceable from existing assigned/allocated IPv4 resources ? such as redundancy and high-availability sites, IPv6 transition technologies, or expansion to new sites which pose a technical constraint on their current resource pool ? and in these cases, the request is treated as a first allocation or request. The request justification should be sufficiently documented, in such way that AFRINIC can verify the compliance with the provided justification. > > I believe the last sentence provides a valid way to avoid abusing the policy. > > I?m attaching (not sure if it will pass thru the list) a PDF of how it looks like in a comprehensive view. > > Regards, > Jordi > > @jordipalet > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Mon Jun 15 07:15:39 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Mon, 15 Jun 2026 09:15:39 +0200 Subject: [rpd] possible update to AFPUB-2026-IPv4-002-DRAFT01 "Amendment of Utilisation in Soft Landing" In-Reply-To: References: Message-ID: Hi Seun, No, there is no such limite of once per member. Is already possible for a member to request multiple times, with the actual soft landing policy (and happening according to the PIER, https://www.afrinic.net/policy/implementation-reports/pier-summary). I?m not changing that, I?m facilitating cases that today aren?t considering in the policy and are acting against AFRICA competitivity. As I said in a previous email, we need to trust the RIR staff. They should be able to request sufficient documentation to justify each case and to avoid abuses, they always can review the implemented reality with the documentation and ask for corrections or recover address when no longer needed or no longer justified. We shall remember what has been presented in the PIER. It looks to me that at the current delegation rate, it will take over 10-12 years to deplete the pool (3+ million addresses), not including possible new recoveries. Also it clearly explains that several members have received more than 8x/22 submitting multiple requests. So with the actual policy, if you have a DC, for example, and need to build more, you need to wait until you have DC1 is built and using 90% of the addresses, to request resources for DC2. This is contrary to high-availability, and it only means that AFRICAN DCs are less competitive. Event worst for new businesses that need HA. If we take an example of 464XLAT deployment, and you have multiple BGP PoPs (which is very common for redundancy, HA, etc.), you can?t actually do that. You?re limited to a single PoP, etc. There are many situation where you actually want to build "simultaneously". Regards, Jordi @jordipalet > El 15 jun 2026, a las 4:29, Seun Ojedeji escribi?: > > Hello Jordi, > > I want to be sure i understand your intent of the section below: > "....and in these cases, the request is treated as a first allocation or request..." > > Does it mean that the exception will only be granted once to member? if that is the case i agree, if that is not the case, then i disagree. I think there should be a limit to the round trip per qualified member. > > I will also suggest a minor edit as per below: > > "The above requirement of 90% is waived for network operators...." > > Regards > On Sun, 14 Jun 2026 at 06:24, jordi.palet--- via RPD > wrote: >> Hi all, >> >> Pending from the impact analysis, if it comes in time before the 16th, i?ve worked in a possible v2 of this policy proposal, considering the previous discussion in the list. >> >> I?m sending this before official submission in order to seek further inputs, if they come in time before the deadline. >> >> The text I?m proposing is: >> >> The above requirement is waived for network operators requesting new IPv4 addresses for demonstrated key technical requirements, which can be illustrated to not be practically serviceable from existing assigned/allocated IPv4 resources ? such as redundancy and high-availability sites, IPv6 transition technologies, or expansion to new sites which pose a technical constraint on their current resource pool ? and in these cases, the request is treated as a first allocation or request. The request justification should be sufficiently documented, in such way that AFRINIC can verify the compliance with the provided justification. >> >> I believe the last sentence provides a valid way to avoid abusing the policy. >> >> I?m attaching (not sure if it will pass thru the list) a PDF of how it looks like in a comprehensive view. >> >> Regards, >> Jordi >> >> @jordipalet >> >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > ---- > Sent from my mobile > kindly excuse typos ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From baya.sylvain at cmnog.cm Mon Jun 15 07:15:57 2026 From: baya.sylvain at cmnog.cm (Sylvain BAYA) Date: Mon, 15 Jun 2026 08:15:57 +0100 Subject: [rpd] [Off-topic] Please Free AfriNIC Community Mailing List. In-Reply-To: <1CF0DF8A-2DA5-4E52-ADAC-3D31DA02E693@gmail.com> References: <10461E18-A0FF-4DC9-B232-B23D572F591B@afrinic.net> <1CF0DF8A-2DA5-4E52-ADAC-3D31DA02E693@gmail.com> Message-ID: <3447f29b-7afd-48ed-a4c9-61aab51fbe9a@cmnog.cm> {Attention! crossposted to Community-Discuss} Le 15/06/2026 ? 03:28, Musa Stephen Honlue a ?crit?: > Neither the RPD nor the community list was frozen. > Hi Musa, An other term was used to describe the situation: [Community-Discuss] Censorship of Community-discuss > The community list was put under moderation and still is, > Exactly! our brother Noah reminded the facts: [Community-Discuss] [members-discuss] Censorship of Community-discuss "what I recall was an implementation of a necessary moderation inlight of the fake news accusations related to terrorism by one of the community list participants." > I think. What that means is that any mail sent to that list needs to be approved by someone at AFRINIC before it is forwarded to the rest of the list. > Sure! but no one want to touch it; as it's not an easy responsibility to carry for our Staff. > And I think the board should wave that moderation because it has significantly paralised community interactions. > ...i fully support! This is *my* request to our BoD members, here in particular i call Ben R., our brother, to please carry it to the AfriNIC BoD (Board of Directors). Please free the Community-Discuss mailinglist! Shalom, --sb. > Sent from my iPhone > >> On 25 May 2026, at 18:14, Ben Roberts - AfriNIC via RPD wrote: >> >> ?I don?t think the RPD list was frozen during Afrinic?s period of stagnation? Only the community discuss list was frozen. >> >> >> Sent from my iPhone >> >>> On 25 May 2026, at 18:21,dacostadarwin at gmail.com wrote: >>> >>> ?Dear PDWG, >>> >>> We have received a new draft policy proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01 from authors Gr?goire EHOUMI, Noah Maina and Adeola A. P. AINA. >>> >>> The proposal contents are published at:https://afrinic.net/policy/proposals/afpub-2026-gen-001-draft01 >>> >>> We encourage you to take some time to go through the proposal contents and provide feedback as follows : >>> >>> a) Do you support or oppose the proposal? >>> >>> b) If you oppose the proposal, state your reasons. >>> >>> c) Is there anything in the proposal that is not clear? >>> >>> d) What changes could be made to this proposal to make it more effective? >>> >>> Regards, >>> Vincent Ngundi & Darwin Da Costa >>> AFRINIC PDWG Co-Chairs >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -- Best Regards ! baya.sylvain [AT cmNOG DOT cm] | cmNOG's Structure | CAMIX's Website | Douala-IX's Looking Glass | cmNOG's Surveys | Subscribe to cmNOG's Mailing List | __ #LASAINTEBIBLE|#Eph?siens5:18,15-21?[...] 18 Et *_ne vous enivrez_* pas *_de vin_*, en quoi *_il y a de la dissolution_*; mais *_soyez remplis de l'Esprit_*, [...]? ?#LASAINTEBIBLE|#H?breux13:9,5-15?[...] 9 _*Ne soyez pas seduits par*_ des _*doctrines diverses*_ et _*etrangeres*_, car il est bon _*que le coeur soit affermi par la grace*_, non par les viandes, lesquels n'ont pas profite ? ceux qui y ont marche. [...]? #AMEN,#Maranatha,#MerciJ?SUS! #?MaPri?re? est que tu naisses de nouveau.#Chr?tiennement -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x0387408365AC8594.asc Type: application/pgp-keys Size: 19437 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From ben.roberts at afrinic.net Mon Jun 15 07:36:07 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Mon, 15 Jun 2026 10:36:07 +0300 Subject: [rpd] [Off-topic] Please Free AfriNIC Community Mailing List. In-Reply-To: <3447f29b-7afd-48ed-a4c9-61aab51fbe9a@cmnog.cm> References: <3447f29b-7afd-48ed-a4c9-61aab51fbe9a@cmnog.cm> Message-ID: An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Mon Jun 15 07:42:23 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Mon, 15 Jun 2026 09:42:23 +0200 Subject: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01. In-Reply-To: References: <29E79A7F-BF80-44DE-8B67-45521A95F2FB@consulintel.es> Message-ID: <38E750A7-2E63-4984-AED4-365CE13D7609@consulintel.es> Hi Sylvain, Some comments below, in-line. Regards, Jordi @jordipalet > El 15 jun 2026, a las 8:36, Sylvain BAYA escribi?: > > {sent with a registered email address now!} > {i hope i'm not too late to add my comment!} > Le 21/05/2026 ? 14:28, jordi.palet--- via RPD a ?crit : >> Hi all, >> [...] >> Comments welcome! >> > > Hi Jordi, > Thanks for your email, brother. > It's my pleasure to be able to review the DPP > (Draft Policy Proposal)! > >> Tks! >> >> Regards, >> Jordi >> >> @jordipalet >> >> >>> El 15 may 2026, a las 17:51, dacostadarwin at gmail.com escribi?: >>> >>> Dear PDWG, >>> >>> We have received a new draft policy proposal - Amendment of Utilisation in Soft Landing, ID AFPUB-2026-IPv4-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>> >>> https://afrinic.net/policy/proposals/afpub-2026-ipv4-002-draft01 >>> >>> We encourage you to take some time to go through the proposal contents and provide feedback as follows : >>> > > Dear PDWG, > > Do kindly consider my review of the > AFPUB-2026-IPv4-002-DRAFT01 DPP > (Draft Policy Proposal) below. > > > > 1. Summary of the problem being addressed by this proposal > > The Soft-Landing utilisation criteria is preventing organisations that may have multiple sites, redundancy or high availability needs to achieve that, because section 5.4.6.1 states that 90% of the previous allocations or assignments must have been used. > > For example, an end-user member may have received a /24 for a Data Centre and now is setting up new Data Centres. Current policy will not allow that until 90% of the first Data Centre prefix is utilised. > > Another example may be an ISP, with multiple BGP PoPs, setting up 464XLAT in the network, with NAT64 devices in each PoP for high-availability purposes. Normally it will announce a /22-/24 in each PoP, even if all the addresses are not being used simultaneously all the time, so 90% utilisation is not allowing that deployment offering high-availability to the subscribers. > > > > ...maybe the Policy Liaison Team could tell us > more about the number of such requests; the > hostmaster is actually unable to satisfy. > > This problem seems to be reasonable; but i > have a small doubt on the urgency; of these > situation. Can we found at least three Orgs > per case? prior to validate the problem which > is formulated here. > > > According to my experience, with customers in all the 5 RIRs, those request not always come to the RIR. If I need some resources, I see that the existing policy doesn?t allow me to request them, *most of the time* I will not waste my time going to the hostmasters to request something that the policy is clear I can?t request. So even if the hostmasters can provide some data, it may not be sufficiently representative. The problem is there, can?t be denied, despite there have been 1 or 10 cases coming to the hostmasters. > 2. Summary of how this proposal addresses the problem > > This proposal suggests that the utilisation criteria should allow cases such as those in the previous examples and similar ones. > > Because the 3 million IPv4 recovered addresses, this change will not create an immediate drain of the AFRINIC pool, and instead, can help to increase the number of DC and high-availability, IPv6 deployment and better connectivity for the region. > > > > 3 million IPv4 recovered > ~ /11 + /12 > 2?? + 2?? = 3145728 ? > > ...while the problem, as formulated, might be > validated (by real facts); i think if we want to > keep "one shop", then it's necessary to keep > the same definition of "first allocation"; for > instance. > > > Please check the PIER, it talks about 3 years per each million, according to current delegation rates. It is clear, with IPv6 deployment, and the waiver provider by this proposal, that it may speed up a little bit, but even if it just give us 3 years for the 3 millions, once IPv6 is being deployed, less and less IPv4 addresses are needed. This is the reason why regions with more IPv6 deployment become the source for more IPv4 transfers. > Proposed > > ~~5.4.6.1 In order to receive IPv4 allocations or assignments during the Exhaustion Phase, the LIR or End User must have used at least 90% of all previous allocations or assignments (including those made during both the Current Phase and the Exhaustion Phase) > > In the case of new LIRs or End Users with no previous allocations or assignments, this requirement does not apply to their first allocation or assignment request.~~ > > "The above requirement is waived for network operators requesting new IP addresses for key technical needs ? such as redundancy and high-availability sites, IPv6 transition technologies, or expansion to new sites which pose a technical constraint on their current resource pool ? and in these cases, the request is treated as a first allocation or request." > > > ...i disagree with the above approach; as it > looks like a less optimal approach. It goes > without saying that when a first allocation > or assignment exists, any resource holder > should be treated same as all the others in > same conditions. > > What could be done, imho, if the edge cases > you have described are proved true; should > be to consider a different approach in order > to address their specificity. > > ...if applicable; then i would suggest the text > below as a replacement to the part of text > between double quotes above: > > "If a resource member (being a LIR or an > End-user) can prove that its actual need for > IPv4 resources can not be satisfied by its > available allocation/assignment, even in > case of a percentage of utilization lower > than 90 %; then notwithstanding the above > requirements, the requesting resource > member shall be *specially considered* > eligible to receive a new allocation or > assignment. > > This *special consideration* shall also > be applicable to a new LIR or End-user, > with similar structural needs in IPv4 > resources. In that case, the given LIR or > End-user shall be *specially considered* > eligible to receive a two allocations or > assignments; to begin with." > > I?m confused here. I think you?re reading v1, not the text that I?m proposing for v2. Nevertheless, your point seems to be a wording issue, not against the goal. My point to make the wording this way was to avoid changes in the existing text, and adding a new paragraph. > > 4. References > In other regions, all IPv4 addresses have been exhausted and it seems that the equivalent to the soft-landing is not any more an issue, because most of the existing members only can access IPv4 addresses via transfers. > > > ...i have found a counter-example to the above > statement; see, brother: > ARIN NRPM Section 4.1.8 . ARIN Waitlist. > > Do kindly include this precision, to your > "References" section (4.), as you go. > We have a waiting list in ARIN, LACNIC and RIPE NCC, but this is not the same as the soft landing. > Thanks. > > Shalom, > --sb. > > > >>> a) Do you support or oppose the proposal? >>> b) If you oppose the proposal, state your reasons? >>> c) Is there anything in the proposal that is not clear? >>> d) What changes could be made to this proposal to make it more effective? >>> >>> Regards, >>> Vincent Ngundi & Darwin Da Costa >>> AFRINIC PDWG Co-Chairs >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> [...] >> > > > > -- > > Best Regards ! > > baya.sylvain [AT cmNOG DOT cm] | > cmNOG's Structure | CAMIX's Website | Douala-IX's Looking Glass | > cmNOG's Surveys | Subscribe to cmNOG's Mailing List | > __ > #LASAINTEBIBLE|#Eph?siens5:18,15-21? [...] 18 Et ne vous enivrez pas de vin, en quoi il y a de la dissolution; mais soyez remplis de l'Esprit, [...]? > ?#LASAINTEBIBLE|#H?breux13:9,5-15? [...] 9 Ne soyez pas seduits par des doctrines diverses et etrangeres, car il est bon que le coeur soit affermi par la grace, non par les viandes, lesquels n'ont pas profite ? ceux qui y ont marche. [...]? > #AMEN,#Maranatha,#MerciJ?SUS! #?MaPri?re? est que tu naisses de nouveau.#Chr?tiennement > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From seun.ojedeji at gmail.com Mon Jun 15 10:03:49 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Mon, 15 Jun 2026 05:03:49 -0500 Subject: [rpd] Staff impact analysis Message-ID: Dear Co-Chairs, I checked all the draft policy proposals at https://afrinic.net/policy/proposals and could not find stay impact analysis on them. Could you kindly have the policy liaisons look into this as ppm is right on our door step. Regards ---- Sent from my mobile kindly excuse typos -------------- next part -------------- An HTML attachment was scrubbed... URL: From aalain at trstech.net Mon Jun 15 10:16:32 2026 From: aalain at trstech.net (ALAIN AINA) Date: Mon, 15 Jun 2026 10:16:32 +0000 Subject: [rpd] Staff impact analysis In-Reply-To: References: Message-ID: Dear PDWG, Would it not be more appropriate for the Working Group to first allow discussions to mature to a certain level of stability before the co?chairs request an AFRINIC staff analysis? Section 3.4.1 of the CPM states that: ?the Working Group Chair(s) may request AFRINIC to provide an analysis (technical, financial, legal or other) of the impact of the draft policy proposal.? ?Alain > On 15 Jun 2026, at 10:03, Seun Ojedeji wrote: > > Dear Co-Chairs, > > I checked all the draft policy proposals at https://afrinic.net/policy/proposals and could not find stay impact analysis on them. > > Could you kindly have the policy liaisons look into this as ppm is right on our door step. > > Regards > > ---- > Sent from my mobile > kindly excuse typos > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From aalain at trstech.net Mon Jun 15 10:16:32 2026 From: aalain at trstech.net (ALAIN AINA) Date: Mon, 15 Jun 2026 10:16:32 +0000 Subject: [rpd] Staff impact analysis In-Reply-To: References: Message-ID: Dear PDWG, Would it not be more appropriate for the Working Group to first allow discussions to mature to a certain level of stability before the co?chairs request an AFRINIC staff analysis? Section 3.4.1 of the CPM states that: ?the Working Group Chair(s) may request AFRINIC to provide an analysis (technical, financial, legal or other) of the impact of the draft policy proposal.? ?Alain > On 15 Jun 2026, at 10:03, Seun Ojedeji wrote: > > Dear Co-Chairs, > > I checked all the draft policy proposals at https://afrinic.net/policy/proposals and could not find stay impact analysis on them. > > Could you kindly have the policy liaisons look into this as ppm is right on our door step. > > Regards > > ---- > Sent from my mobile > kindly excuse typos > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From jordi.palet at consulintel.es Mon Jun 15 11:15:17 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Mon, 15 Jun 2026 13:15:17 +0200 Subject: [rpd] Staff impact analysis In-Reply-To: References: Message-ID: <8E5691B2-E1A8-44E9-AE28-9909B0D596B8@consulintel.es> Hi Alain, I see it in a different way. It has been a good practice in AFRINIC (and also same experience in other RIRs) to provide the impact analysis ASAP. The impact analysis is key to understand possible implementation issues that the community discussion may or may not be able to discover. If we get the impact analysis before the 1 week deadline for a new version, then ?fixes? for those issues could be incorporated in a new version. Otherwise, those fixes, which may even prevent the board to ratify a proposal even if it reaches consensus in the community, will need to wait for a complete new cycle (6 months or even 1 year). So both, community discussion and impact analysis should be concurrent, because they may present different ?views" of a proposal. I fully understand that the number of proposals makes difficult for the staff to get all them in a perfect ?final state" right now, but even just sharing a draft version in a PDF (no need to publish the draft in the web site), clearly stating that it is a draft and subjected to corrections, will be very helpful for both the discussion and the authors to be able to fix issues before the deadline. Regards, Jordi @jordipalet > El 15 jun 2026, a las 12:16, ALAIN AINA via RPD escribi?: > > Dear PDWG, > > Would it not be more appropriate for the Working Group to first allow discussions to mature to a certain level of stability before the co?chairs request an AFRINIC staff analysis? > > Section 3.4.1 of the CPM states that: > ?the Working Group Chair(s) may request AFRINIC to provide an analysis (technical, financial, legal or other) of the impact of the draft policy proposal.? > > ?Alain > >> On 15 Jun 2026, at 10:03, Seun Ojedeji wrote: >> >> Dear Co-Chairs, >> >> I checked all the draft policy proposals at https://afrinic.net/policy/proposals and could not find stay impact analysis on them. >> >> Could you kindly have the policy liaisons look into this as ppm is right on our door step. >> >> Regards >> >> ---- >> Sent from my mobile >> kindly excuse typos >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From geier at geier.ne.tz Mon Jun 15 12:35:09 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Mon, 15 Jun 2026 15:35:09 +0300 Subject: [rpd] Staff impact analysis In-Reply-To: <8E5691B2-E1A8-44E9-AE28-9909B0D596B8@consulintel.es> References: <8E5691B2-E1A8-44E9-AE28-9909B0D596B8@consulintel.es> Message-ID: <0aacf48c-289c-4a5d-bce8-b291a4f4b6b9@geier.ne.tz> Hi all, I agree with what Jordi is saying here. Any unnecessary delay will just delay the conclusion of this process. Regards, Frank On 6/15/2026 2:15 PM, jordi.palet--- via RPD wrote: > Hi Alain, > > I see it in a different way. It has been a good practice in AFRINIC (and also same experience in other RIRs) to provide the impact analysis ASAP. > > The impact analysis is key to understand possible implementation issues that the community discussion may or may not be able to discover. > > If we get the impact analysis before the 1 week deadline for a new version, then ?fixes? for those issues could be incorporated in a new version. > > Otherwise, those fixes, which may even prevent the board to ratify a proposal even if it reaches consensus in the community, will need to wait for a complete new cycle (6 months or even 1 year). > > So both, community discussion and impact analysis should be concurrent, because they may present different ?views" of a proposal. > > I fully understand that the number of proposals makes difficult for the staff to get all them in a perfect ?final state" right now, but even just sharing a draft version in a PDF (no need to publish the draft in the web site), clearly stating that it is a draft and subjected to corrections, will be very helpful for both the discussion and the authors to be able to fix issues before the deadline. > > Regards, > Jordi > > @jordipalet > >> El 15 jun 2026, a las 12:16, ALAIN AINA via RPD escribi?: >> >> Dear PDWG, >> >> Would it not be more appropriate for the Working Group to first allow discussions to mature to a certain level of stability before the co?chairs request an AFRINIC staff analysis? >> >> Section 3.4.1 of the CPM states that: >> ?the Working Group Chair(s) may request AFRINIC to provide an analysis (technical, financial, legal or other) of the impact of the draft policy proposal.? >> >> ?Alain >> >>> On 15 Jun 2026, at 10:03, Seun Ojedeji wrote: >>> >>> Dear Co-Chairs, >>> >>> I checked all the draft policy proposals at https://afrinic.net/policy/proposals and could not find stay impact analysis on them. >>> >>> Could you kindly have the policy liaisons look into this as ppm is right on our door step. >>> >>> Regards >>> >>> ---- >>> Sent from my mobile >>> kindly excuse typos >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From geier at geier.ne.tz Mon Jun 15 12:38:59 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Mon, 15 Jun 2026 15:38:59 +0300 Subject: [rpd] Staff impact analysis In-Reply-To: References: Message-ID: <63d38996-7be9-4cb8-82c9-73293cea330a@geier.ne.tz> Hi all, On 6/15/2026 1:16 PM, ALAIN AINA via RPD wrote: > Dear PDWG, > > Would it not be more appropriate for the Working Group to first allow discussions to mature to a certain level of stability before the co?chairs request an AFRINIC staff analysis? I think this can be a valid argument for some proposals. But not necessarily for all. When for instance looking at the proposal for hierarchical AS-SETs, I see no reason to delay the impact analysis. There might of course be internal reasons with AfriNIC (staff), but from outside AfriNIC staff we don't need (and shouldn't) impose delays. My opinion. Regards, Frank > Section 3.4.1 of the CPM states that: > ?the Working Group Chair(s) may request AFRINIC to provide an analysis (technical, financial, legal or other) of the impact of the draft policy proposal.? > > ?Alain > >> On 15 Jun 2026, at 10:03, Seun Ojedeji wrote: >> >> Dear Co-Chairs, >> >> I checked all the draft policy proposals at https://afrinic.net/policy/proposals and could not find stay impact analysis on them. >> >> Could you kindly have the policy liaisons look into this as ppm is right on our door step. >> >> Regards >> >> ---- >> Sent from my mobile >> kindly excuse typos >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From aalain at trstech.net Mon Jun 15 23:34:10 2026 From: aalain at trstech.net (ALAIN AINA) Date: Mon, 15 Jun 2026 23:34:10 +0000 Subject: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01. In-Reply-To: References: Message-ID: Dear PDWG The problem we are trying to solve here seems to be an issue with organisation running Multiple Discrete Networks (MDNs) and willing to manage the associated number resources in one account (Org-Id). This goes beyond the IPv4 soft landing and the 90% usage requirements. It is also valid for other resources (IPv6 and ASN) How to address this? We need clear definitions and eligibility criteria, appropriate requests evaluation and allocation/assignment rules. Below is a proposed policy text (*) ========================= Definitions and eligibility --------------------------- Definition: A Multiple Discrete Network is a network architecture in which a single organisation operates two or more autonomous and non?interconnected networks that cannot practically share number resources. Eligibility: ------------ Organisations with Multiple Discrete Networks desiring to request a new or additional IP address space allocation under a single Organisation ID must meet the following criteria: - It is a single legal entity, not a consortium of smaller independent entities. - It operates two or more networks that cannot share address space due to one or more of the following: + regulatory or legal restrictions; + significant geographic separation and diversity between networks; + autonomous routing policies (e.g., independent multi?homing); + operational or security constraints requiring strict separation. 1- IPv4 requirements for MDNs The organisation must keep detailed records on how it has allocated IP addresses to each location, including the date of each sub-allocations or assignments. When applying for additional IP address allocations from AFRINIC, - the organisation must demonstrate utilisation greater than 50% of both the last IP addresses allocated or assigned and the aggregate sum of all IP addresses from AFRINIC to that organisation. - If an organisation is unable to satisfy this 50% minimum utilisation criteria, the organisation may alternatively qualify for additional IP address by having all unused IP address blocks smaller than AFRINIC's current minimum allocation or assignment size. - The organisation must not sub-allocate or assign additional IP address space to a location until each of that location?s IP address allocations are 90% utilised. The organisation must notify AFRINIC at the time of the request of their desire to apply this policy to their account. 2- IPv6 requirements for MDNs - The organisation must keep detailed records on how it has allocated IPv6 addresses to each location, including the date of each IPv6 address allocation. - When an organisation is requesting additional IPv6 address allocations under this policy, the organisation must specify on the application which discrete network(s) the IPv6 address request applies to. - A request for additional space will be judged against the existing utilisation criteria specified in 6.5.1 and 6.5.2 of the CPM as if it were a separate organisation, rather than collectively as would be done for requests outside of this policy. - The organisation must notify AFRINIC at the time of the request their desire to apply this policy to their account. 3- ASN requirements for MDNs Organizations that have space issued under Multiple Discrete Networks policy may be issued one ASN per discrete network upon request. Additional ASN requests should include proof of the requestor?s need for a unique routing policy, or other technical justification for the need for more than one ASN. (*) adapted from ARIN Policy Manual HTH ?Alain(sorry for coming a bit late..) > On 15 May 2026, at 15:51, dacostadarwin at gmail.com wrote: > > Dear PDWG, > > We have received a new draft policy proposal - Amendment of Utilisation in Soft Landing, ID AFPUB-2026-IPv4-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: > > https://afrinic.net/policy/proposals/afpub-2026-ipv4-002-draft01 > > We encourage you to take some time to go through the proposal contents and provide feedback as follows : > > a) Do you support or oppose the proposal? > b) If you oppose the proposal, state your reasons? > c) Is there anything in the proposal that is not clear? > d) What changes could be made to this proposal to make it more effective? > > Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From aalain at trstech.net Mon Jun 15 23:34:10 2026 From: aalain at trstech.net (ALAIN AINA) Date: Mon, 15 Jun 2026 23:34:10 +0000 Subject: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01. In-Reply-To: References: Message-ID: Dear PDWG The problem we are trying to solve here seems to be an issue with organisation running Multiple Discrete Networks (MDNs) and willing to manage the associated number resources in one account (Org-Id). This goes beyond the IPv4 soft landing and the 90% usage requirements. It is also valid for other resources (IPv6 and ASN) How to address this? We need clear definitions and eligibility criteria, appropriate requests evaluation and allocation/assignment rules. Below is a proposed policy text (*) ========================= Definitions and eligibility --------------------------- Definition: A Multiple Discrete Network is a network architecture in which a single organisation operates two or more autonomous and non?interconnected networks that cannot practically share number resources. Eligibility: ------------ Organisations with Multiple Discrete Networks desiring to request a new or additional IP address space allocation under a single Organisation ID must meet the following criteria: - It is a single legal entity, not a consortium of smaller independent entities. - It operates two or more networks that cannot share address space due to one or more of the following: + regulatory or legal restrictions; + significant geographic separation and diversity between networks; + autonomous routing policies (e.g., independent multi?homing); + operational or security constraints requiring strict separation. 1- IPv4 requirements for MDNs The organisation must keep detailed records on how it has allocated IP addresses to each location, including the date of each sub-allocations or assignments. When applying for additional IP address allocations from AFRINIC, - the organisation must demonstrate utilisation greater than 50% of both the last IP addresses allocated or assigned and the aggregate sum of all IP addresses from AFRINIC to that organisation. - If an organisation is unable to satisfy this 50% minimum utilisation criteria, the organisation may alternatively qualify for additional IP address by having all unused IP address blocks smaller than AFRINIC's current minimum allocation or assignment size. - The organisation must not sub-allocate or assign additional IP address space to a location until each of that location?s IP address allocations are 90% utilised. The organisation must notify AFRINIC at the time of the request of their desire to apply this policy to their account. 2- IPv6 requirements for MDNs - The organisation must keep detailed records on how it has allocated IPv6 addresses to each location, including the date of each IPv6 address allocation. - When an organisation is requesting additional IPv6 address allocations under this policy, the organisation must specify on the application which discrete network(s) the IPv6 address request applies to. - A request for additional space will be judged against the existing utilisation criteria specified in 6.5.1 and 6.5.2 of the CPM as if it were a separate organisation, rather than collectively as would be done for requests outside of this policy. - The organisation must notify AFRINIC at the time of the request their desire to apply this policy to their account. 3- ASN requirements for MDNs Organizations that have space issued under Multiple Discrete Networks policy may be issued one ASN per discrete network upon request. Additional ASN requests should include proof of the requestor?s need for a unique routing policy, or other technical justification for the need for more than one ASN. (*) adapted from ARIN Policy Manual HTH ?Alain(sorry for coming a bit late..) > On 15 May 2026, at 15:51, dacostadarwin at gmail.com wrote: > > Dear PDWG, > > We have received a new draft policy proposal - Amendment of Utilisation in Soft Landing, ID AFPUB-2026-IPv4-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: > > https://afrinic.net/policy/proposals/afpub-2026-ipv4-002-draft01 > > We encourage you to take some time to go through the proposal contents and provide feedback as follows : > > a) Do you support or oppose the proposal? > b) If you oppose the proposal, state your reasons? > c) Is there anything in the proposal that is not clear? > d) What changes could be made to this proposal to make it more effective? > > Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From jordi.palet at consulintel.es Tue Jun 16 07:53:56 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Tue, 16 Jun 2026 09:53:56 +0200 Subject: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01. In-Reply-To: References: Message-ID: Hi Alain, While I agree that the problem of MDNs may also happen in the region, this is not the one being tried to fix in this proposal. The examples provided in the proposal don?t need different ASNs. In fact, you want a single ASN and provide HA. For example, I?ve run into the problem, in one country in Africa, when doing a 464XLAT network design. The customer has 4 BGP PoPs, the need to be redundant in case of failure, but normally, each one covers nearby customers in that region. This imply having 4 new IPv4 blocks for the NAT64 boxes (2 of them in each PoP to increase the HA). And of course, they are under a single ASN. Regards, Jordi @jordipalet > El 16 jun 2026, a las 1:34, ALAIN AINA via RPD escribi?: > > Dear PDWG > > The problem we are trying to solve here seems to be an issue with organisation running Multiple Discrete Networks (MDNs) and willing to manage the associated number resources in one account (Org-Id). > > This goes beyond the IPv4 soft landing and the 90% usage requirements. It is also valid for other resources (IPv6 and ASN) > > How to address this? > > We need clear definitions and eligibility criteria, appropriate requests evaluation and allocation/assignment rules. > > Below is a proposed policy text (*) > > ========================= > Definitions and eligibility > --------------------------- > > Definition: > > A Multiple Discrete Network is a network architecture in which a single organisation operates two or more autonomous and non?interconnected networks that cannot practically share number resources. > > Eligibility: > ------------ > > Organisations with Multiple Discrete Networks desiring to request a new or additional IP address space allocation under a single Organisation ID must meet the following criteria: > > - It is a single legal entity, not a consortium of smaller independent entities. > > - It operates two or more networks that cannot share address space due to one or more of the following: > > + regulatory or legal restrictions; > + significant geographic separation and diversity between networks; > + autonomous routing policies (e.g., independent multi?homing); > + operational or security constraints requiring strict separation. > > 1- IPv4 requirements for MDNs > > The organisation must keep detailed records on how it has allocated IP addresses to each location, including the date of each sub-allocations or assignments. > > When applying for additional IP address allocations from AFRINIC, > > - the organisation must demonstrate utilisation greater than 50% of both the last IP addresses allocated or assigned and the aggregate sum of all IP addresses from AFRINIC to that organisation. > > - If an organisation is unable to satisfy this 50% minimum utilisation criteria, the organisation may alternatively qualify for additional IP address by having all unused IP address blocks smaller than AFRINIC's current minimum allocation or assignment size. > > - The organisation must not sub-allocate or assign additional IP address space to a location until each of that location?s IP address allocations are 90% utilised. > > The organisation must notify AFRINIC at the time of the request of their desire to apply this policy to their account. > > 2- IPv6 requirements for MDNs > > - The organisation must keep detailed records on how it has allocated IPv6 addresses to each location, including the date of each IPv6 address allocation. > > - When an organisation is requesting additional IPv6 address allocations under this policy, the organisation must specify on the application which discrete network(s) the IPv6 address request applies to. > > - A request for additional space will be judged against the existing utilisation criteria specified in 6.5.1 and 6.5.2 of the CPM as if it were a separate organisation, rather than collectively as would be done for requests outside of this policy. > > - The organisation must notify AFRINIC at the time of the request their desire to apply this policy to their account. > > 3- ASN requirements for MDNs > > Organizations that have space issued under Multiple Discrete Networks policy may be issued one ASN per discrete network upon request. > > Additional ASN requests should include proof of the requestor?s need for a unique routing policy, or other technical justification for the need for more than one ASN. > > (*) adapted from ARIN Policy Manual > > HTH > > ?Alain(sorry for coming a bit late..) > >> On 15 May 2026, at 15:51, dacostadarwin at gmail.com wrote: >> >> Dear PDWG, >> >> We have received a new draft policy proposal - Amendment of Utilisation in Soft Landing, ID AFPUB-2026-IPv4-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >> >> https://afrinic.net/policy/proposals/afpub-2026-ipv4-002-draft01 >> >> We encourage you to take some time to go through the proposal contents and provide feedback as follows : >> >> a) Do you support or oppose the proposal? >> b) If you oppose the proposal, state your reasons? >> c) Is there anything in the proposal that is not clear? >> d) What changes could be made to this proposal to make it more effective? >> >> Regards, >> Vincent Ngundi & Darwin Da Costa >> AFRINIC PDWG Co-Chairs >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From aalain at trstech.net Tue Jun 16 23:47:06 2026 From: aalain at trstech.net (ALAIN AINA) Date: Tue, 16 Jun 2026 23:47:06 +0000 Subject: [rpd] Fwd: New policy Proposal: Dynamic IPv4 Pools Exhaustion Management Framework References: Message-ID: Hi PDWG, This proposal was submitted a week ago. Thanks ?Alain > Begin forwarded message: > > From: aalain at digitalintelligence.africa > Subject: New policy Proposal: Dynamic IPv4 Pools Exhaustion Management Framework > Date: 8 June 2026 at 10:11:47 GMT > To: pdwg-chairs at afrinic.net > Cc: policy-liaison at afrinic.net > > Dear Co-chairs, > > Please find below a new policy proposal. If all in order, please assign the ID and publish it as soon as possible. > > https://docs.google.com/document/d/1vy6RRhw1YTSmJ5W9bZlllw6rzH86nzdLl03zeL2DZ5U/edit?usp=sharing > > ===== > > Dynamic IPv4 Pools Exhaustion Management Framework > > AFPUB?2026?GEN?XXX > Version 1.0 > ID: Assigned by AFRINIC Staff > > Date Submitted: 08 June 2026 > > Author(s): > Adeola A. P. AINA (aalain at digitalintelligence.africa), > Co?authors: Contact me if you want to be co-author > > Obsoletes: Amends: The soft landing policy section 5.4 of the CPM > > > 1. Definitions > ? Delegation ? IPv4 Allocation to LIRs or Assignment to End?Users. > ? Recovered Space ? Any IPv4 resources returned, revoked, reclaimed, or otherwise recovered by AFRINIC. > ? Legacy Space ? Delegations prior to the RIR system and tagged as Legacy by AFRINIC. > ? Soft?Landing Pool ? The IPv4 pool administered under CPM Section 5.4 (Soft?Landing Phase 2). > ? Policy?Reserved Pool ? Dedicated IPv4 blocks reserved for specific sub?policies (e.g., IXPs, Critical Infrastructure). > ? Pre?Softlanding Pool ? A reserve pool replenished exclusively by recovered space originating from pre-Soft-Landing delegations, allocations from IANA?recovered space and unclaimed or un-registered Legacy space. > ? Recovered Pool ? The initial administrative holding area for all recovered IPv4 space prior to classification. > ? Post?Exhaustion Waiting List ? A structured queue used once both primary pools are fully depleted. > ? Immediate Infrastructural Need ? A documented requirement for IPv4 resources essential to maintain or activate operational network services. > > 2. Problem Statement > > 2.1 Summary of the Problem > > AFRINIC entered Soft?Landing Phase 2 in 2020 when the remaining non?reserved IPv4 space fell below one /11. Current delegation rates indicate: > ? Approximately 2 years remain before depletion of the active Soft?Landing Pool. > ? Approximately 3 additional years remain before depletion of the /12 block reserved for future use. > ? More than 3 million IPv4 addresses have been recovered and currently fall under Soft-landing Phase 2 rules by default. > Operational data shows that several members have obtained more than 8 ? /22 (/19) within a calendar year by submitting multiple sequential requests, revealing gaps in the current framework. > > The existing CPM lacks: > ? A structured mechanism to classify and return recovered space to its appropriate pool. > ? A predictable replenishment pipeline for IPv4 resources. > ? A post?exhaustion delegation framework. > ? Automated operational triggers that adjust delegation behaviour based on pool health. > ? Protections against gaming through repeated small requests. > > > 2.2 Summary of How This Proposal Addresses the Problem > > This proposal introduces: > ? A multi?pool IPv4 management architecture with clear replenishment rules. > ? A tiered delegation framework that prioritises pre Soft-landing recovered space. > ? A post?exhaustion waiting list with strict rationing and fairness rules. > ? A trace?back mechanism ensuring recovered space returns to its rightful pool. > ? Operational transparency and anti?gaming protections. > > 3. Proposed Solution > 3.1 IPv4 Pools > > This policy establishes four distinct IPv4 management pools: > ? Soft?Landing Pool ? Administered under CPM 5.4 Phase 2 rules. > ? Policy?Reserved Pools ? Dedicated pools for sub?policies such as IXPs and Critical Infrastructure. > ? Pre?Softlanding Pool ? Replenished exclusively by: > ? Unclaimed or Un-registered Legacy space > ? Delegations predating the soft?landing era > ? Allocations from the IANA Recovered IPv4 Pool > ? Recovered Pool ? Temporary holding area for all recovered space prior to classification. > > Operational Requirements: > ? All pools must be tracked independently in AFRINIC?s inventory system. > ? Movements between pools must be auditable and publicly reportable. > > > 3.2 Operational Rules > > Rule 1 ? Classification of Recovered Space > > ? All recovered space shall first enter the Recovered Pool. > ? AFRINIC staff shall trace each block to its original source pool category. > ? Space shall be returned to that source pool. > ? If the source cannot be determined with reasonable certainty, the space shall default to the Pre?Softlanding Pool. > ? Partial blocks shall be classified proportionally based on their traceable origin. > ? Classification actions shall be documented and publicly announced > ? AFRINIC shall minimise fragmentation when reassigning recovered space. > > Rule 2 ? Delegation Rules for the Pre?Softlanding Pool > > The Pre?Softlanding Pool serves as the primary evaluation layer. > ? Maximum delegation size: /18 per request. > ? Minimum delegation size: /24 > ? Justification period: 12 months > ? Pre-use requirement: Applicants must provide evidence of efficient utilisation of all prior delegations to 80% > ? Extended maximum: Up to /16 if the member provides: > ? Documented growth metrics > ? A verifiable deployment plan > > Members may not submit multiple concurrent or sequential requests intended to aggregate beyond the maximum delegation size. > > Rule 3 ? Automatic Deferral to the Soft?Landing Pool > > If a request cannot be satisfied by available blocks in the Pre?Softlanding Pool: > ? The request shall be automatically deferred to the Soft?Landing Pool. > ? AFRINIC staff must document the deferral and notify the applicant. > ? Soft?Landing Phase 2 conditions, as defined in CPM Section?5.4, shall apply to all delegations made under this deferral mechanism. > > Rule 4 ? Post?Exhaustion Waiting List Framework > > When both the Soft?Landing Pool and Pre?Softlanding Pool reach zero available space, all IPv4 delegations shall be managed exclusively through a Post?Exhaustion Waiting List. > > 4.1 Feeding Mechanism > ? The Recovered Pool becomes the sole source of IPv4 space for the waiting list. > > 4.2 Queue Rules > ? Requests must demonstrate immediate infrastructural need. > ? Queue operates strictly first?come, first?served. > ? Only one active position per organisation or related entity. > ? Requests expire after 30 days if the member does not respond. > ? Mergers or acquisitions involving entities on the list shall result in consolidation to a single queue position. > > 4.3 Delegation Sizes > ? Maximum: /23 > ? Minimum: /24, unless global routing standards or internet community consensus officially shift the minimum universally routable prefix size below a /24, in which case AFRINIC shall align its minimum allocation floor to match the new global standard. > ? If a /23 is justified but only a /24 is available, the member may accept the /24 without losing queue position. > > 4.4 Deployment Requirement > ? Delegated space must be fully deployed within 6 months. > ? After deployment, the member may re?apply at the bottom of the queue. > > 4.5 Transparency Requirements > AFRINIC shall publish monthly: > ? Queue length > ? Total addresses available > ? Average wait time > ? Total recovered space processed > > Rule 5? Transfer of IPv4 addresses > Address space delegated from the pre-softlanding pool and later on from the waiting list will not be eligible for transfer, with the exception of Mergers, Acquisition and Takeovers for a period of 24 months. Transfer restrictions on delegations from the soft landing pool shall apply. > > 5. Acknowledgements > The authors acknowledge community feedback and operational insights from AFRINIC staff that informed this revised framework. > > 6. References > ? AFRINIC Policy Implementation Experience Report > ? AFRINIC Statistics Portal > ? IANA Recovered IPv4 Pool Procedures > ? Global RIR IPv4 Exhaustion Models > > 7. Situation in other regions > > 7.1 APNIC > APNIC managed its final /8 by limiting allocations to a strict maximum size per member. Initially set to a /22, it was later reduced to a /23. On 2 July 2019, APNIC implemented Prop-129, which completely abolished the waiting list for unmet IPv4 requests due to the lack of a predictable stream of recovered space. Instead, APNIC continues to delegate up to a strict total lifetime maximum of a /23 per member exclusively from its remaining 103/8 pool and a separate pool of recovered non-103 space. Allocations from these scarce resource pools are held from voluntary transfer for a period of 24 months. > > 7.2 LACNIC > LACNIC officially reached total exhaustion of its remaining non-recovered pools on August 19, 2020, triggering a permanent waiting list system funded strictly by returned, revoked, and recovered space after a mandatory 6-month quarantine. Under the LACNIC Waitlist Policy, approved organisations that have assigned IPv6 are placed in a first-come, first-served queue with a maximum allocation cap of a > /22. Space allocated from the LACNIC waiting list is restricted from voluntary transfer for a period of 36 months. > > 7.3 RIPE NCC > Following complete depletion of its available free pools, RIPE NCC implemented a strict post-exhaustion waiting list. Under the current RIPE IPv4 Waiting List Policy, allocations are restricted to exactly one /24 per Local Internet Registry (LIR), provided the LIR has never received an IPv4 allocation from RIPE NCC before. Allocations from this waiting list are held from voluntary transfer for a period of 24 months. > > 7.4 ARIN > ARIN initially deployed an unrestricted waiting list. Because it lacked strong caps, the queue faced systemic gaming, forcing the ARIN Board to temporarily suspend the waiting list in 2019. ARIN subsequently reinstated the list with strict anti-gaming parameters: organisations holding more than a /20 equivalent in aggregate are entirely ineligible to apply, and the maximum allocation size is capped at a /22. Space distributed from the ARIN IPv4 Waiting List cannot be transferred to another organisation for 60 months, except in cases of corporate mergers, acquisitions, or takeovers. > ===== > > > Thanks > > ?Alain > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: Message signed with OpenPGP URL: From comms at afrinic.net Wed Jun 17 13:39:14 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Wed, 17 Jun 2026 17:39:14 +0400 Subject: [rpd] Invitation to Share a Tribute and Join us in the Memorial Celebration of Alan Barrett Message-ID: <3F195BA5-7D69-480F-A248-B2E04ED5E60D@afrinic.net> Dear Colleagues, The African Internet community continues to mourn the loss of Alan Barrett, one of Africa?s Internet pioneers, a respected leader, mentor, and friend. Through his decades of service to the Internet community, Alan helped shape Internet infrastructure, policy development, and governance across Africa and globally. His legacy lives on through the institutions he helped build, the policies he shaped, and the many people he inspired. To honour Alan?s life and contributions, we invite you to share a personal tribute, memory, message, or photograph that reflects his impact on your life or work. Selected tributes and photos will be featured during a memorial session and included in a commemorative tribute for Alan?s family. Please submit your tribute and photographs here . (https://2026.internetsummit.africa/alan-p-barrett-memorial) We also invite you to join us for the Alan Barrett Memorial Tribute: Date: 23 June 2026 Time: 18:00 EAT ( 15.00 UTC) Venue: Africa Internet Summit 2026, Nairobi, Kenya Format: Hybrid (In-Person and Online) Let us celebrate the life, leadership, and lasting legacy of a man whose contributions helped shape Africa?s Internet. Kind Regards, AFRINIC Communications. Chers membres de la Communaut?, La communaut? Internet africaine continue de pleurer la perte d?Alan Barrett, l?un des pionniers de l?Internet en Afrique, un leader respect?, un mentor et un ami. ? travers plusieurs d?cennies de service au sein de la communaut? Internet, Alan a contribu? ? fa?onner l?infrastructure Internet, le d?veloppement des politiques et la gouvernance de l?Internet en Afrique et dans le monde. Son h?ritage demeure vivant ? travers les institutions qu?il a aid? ? b?tir, les politiques qu?il a contribu? ? fa?onner et les nombreuses personnes qu?il a inspir?es. Afin d?honorer la vie et les contributions d?Alan, nous vous invitons ? partager un hommage personnel, un souvenir, un message ou une photographie refl?tant l?impact qu?il a eu sur votre vie ou votre travail. Les hommages et photographies s?lectionn?s seront pr?sent?s lors d?une session comm?morative et inclus dans un hommage souvenir destin? ? la famille d?Alan. Veuillez soumettre votre hommage et vos photographies ici (https://2026.internetsummit.africa/alan-p-barrett-memorial) Nous vous invitons ?galement ? vous joindre ? nous pour l?hommage comm?moratif en m?moire d?Alan Barrett : Date : 23 juin 2026 Heure : 18 h 00 EAT (15.00 GMT) Lieu: Africa Internet Summit 2026, Nairobi, Kenya Format : Hybride (en pr?sentiel et en ligne) C?l?brons ensemble la vie, le leadership et l?h?ritage durable d?un homme dont les contributions ont aid? ? fa?onner l?Internet en Afrique. Cordialement, AFRINIC Communications. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dacostadarwin at gmail.com Thu Jun 18 11:41:13 2026 From: dacostadarwin at gmail.com (Darwin Da Costa) Date: Thu, 18 Jun 2026 13:41:13 +0200 Subject: [rpd] New policy Proposal: Dynamic IPv4 Pools Exhaustion Management Framework In-Reply-To: References: Message-ID: <604E2DC6-C04C-4EAF-A963-F42327C75EC1@gmail.com> Dear Policy Authors, We acknowledge receipt of the proposal titled Dynamic IPv4 Pools Exhaustion Management Framework, which seeks to amend Section 5.4 of the Consolidated Policy Manual on 8 June 2026. Please note that: 1. An existing proposal Soft Landing Recovered Space and Priority https://afrinic.net/policy/proposals/afpub-2026-ipv4-001-draft01#proposal is currently under discussion regarding the recovered IPv4 space after Softlanding Phase has been triggered at AFRINIC. 2. Furthermore, the timelines for submitting new proposals for the upcoming AFRINIC meeting was 23h59 UTC, 26 May 2026. As a result, this proposal cannot be accepted as a new proposal for discussion at the upcoming PPM. We recommend and encourage that you share your proposal text around the recovered space and its merits with the author of the above mentioned proposal and PDWG on the RPD Mailing List as an improvement/alternative to the solution that is currently being discussed. We trust that the spirit of the consensus-driven bottom-up principle of the PDP will prevail and that the community would be forthcoming in improving the current policy proposal that is being discussed. Kind Regards Darwin da Costa Vincent Ngundi PDWG Chairs > On 17 Jun 2026, at 01:47, ALAIN AINA via RPD wrote: > > Hi PDWG, > > This proposal was submitted a week ago. > > Thanks > > ?Alain > >> Begin forwarded message: >> >> From: aalain at digitalintelligence.africa >> Subject: New policy Proposal: Dynamic IPv4 Pools Exhaustion Management Framework >> Date: 8 June 2026 at 10:11:47 GMT >> To: pdwg-chairs at afrinic.net >> Cc: policy-liaison at afrinic.net >> >> Dear Co-chairs, >> >> Please find below a new policy proposal. If all in order, please assign the ID and publish it as soon as possible. >> >> https://docs.google.com/document/d/1vy6RRhw1YTSmJ5W9bZlllw6rzH86nzdLl03zeL2DZ5U/edit?usp=sharing >> >> ===== >> >> Dynamic IPv4 Pools Exhaustion Management Framework >> >> AFPUB?2026?GEN?XXX >> Version 1.0 >> ID: Assigned by AFRINIC Staff >> >> Date Submitted: 08 June 2026 >> >> Author(s): >> Adeola A. P. AINA (aalain at digitalintelligence.africa), >> Co?authors: Contact me if you want to be co-author >> >> Obsoletes: Amends: The soft landing policy section 5.4 of the CPM >> >> >> 1. Definitions >> ? Delegation ? IPv4 Allocation to LIRs or Assignment to End?Users. >> ? Recovered Space ? Any IPv4 resources returned, revoked, reclaimed, or otherwise recovered by AFRINIC. >> ? Legacy Space ? Delegations prior to the RIR system and tagged as Legacy by AFRINIC. >> ? Soft?Landing Pool ? The IPv4 pool administered under CPM Section 5.4 (Soft?Landing Phase 2). >> ? Policy?Reserved Pool ? Dedicated IPv4 blocks reserved for specific sub?policies (e.g., IXPs, Critical Infrastructure). >> ? Pre?Softlanding Pool ? A reserve pool replenished exclusively by recovered space originating from pre-Soft-Landing delegations, allocations from IANA?recovered space and unclaimed or un-registered Legacy space. >> ? Recovered Pool ? The initial administrative holding area for all recovered IPv4 space prior to classification. >> ? Post?Exhaustion Waiting List ? A structured queue used once both primary pools are fully depleted. >> ? Immediate Infrastructural Need ? A documented requirement for IPv4 resources essential to maintain or activate operational network services. >> >> 2. Problem Statement >> >> 2.1 Summary of the Problem >> >> AFRINIC entered Soft?Landing Phase 2 in 2020 when the remaining non?reserved IPv4 space fell below one /11. Current delegation rates indicate: >> ? Approximately 2 years remain before depletion of the active Soft?Landing Pool. >> ? Approximately 3 additional years remain before depletion of the /12 block reserved for future use. >> ? More than 3 million IPv4 addresses have been recovered and currently fall under Soft-landing Phase 2 rules by default. >> Operational data shows that several members have obtained more than 8 ? /22 (/19) within a calendar year by submitting multiple sequential requests, revealing gaps in the current framework. >> >> The existing CPM lacks: >> ? A structured mechanism to classify and return recovered space to its appropriate pool. >> ? A predictable replenishment pipeline for IPv4 resources. >> ? A post?exhaustion delegation framework. >> ? Automated operational triggers that adjust delegation behaviour based on pool health. >> ? Protections against gaming through repeated small requests. >> >> >> 2.2 Summary of How This Proposal Addresses the Problem >> >> This proposal introduces: >> ? A multi?pool IPv4 management architecture with clear replenishment rules. >> ? A tiered delegation framework that prioritises pre Soft-landing recovered space. >> ? A post?exhaustion waiting list with strict rationing and fairness rules. >> ? A trace?back mechanism ensuring recovered space returns to its rightful pool. >> ? Operational transparency and anti?gaming protections. >> >> 3. Proposed Solution >> 3.1 IPv4 Pools >> >> This policy establishes four distinct IPv4 management pools: >> ? Soft?Landing Pool ? Administered under CPM 5.4 Phase 2 rules. >> ? Policy?Reserved Pools ? Dedicated pools for sub?policies such as IXPs and Critical Infrastructure. >> ? Pre?Softlanding Pool ? Replenished exclusively by: >> ? Unclaimed or Un-registered Legacy space >> ? Delegations predating the soft?landing era >> ? Allocations from the IANA Recovered IPv4 Pool >> ? Recovered Pool ? Temporary holding area for all recovered space prior to classification. >> >> Operational Requirements: >> ? All pools must be tracked independently in AFRINIC?s inventory system. >> ? Movements between pools must be auditable and publicly reportable. >> >> >> 3.2 Operational Rules >> >> Rule 1 ? Classification of Recovered Space >> >> ? All recovered space shall first enter the Recovered Pool. >> ? AFRINIC staff shall trace each block to its original source pool category. >> ? Space shall be returned to that source pool. >> ? If the source cannot be determined with reasonable certainty, the space shall default to the Pre?Softlanding Pool. >> ? Partial blocks shall be classified proportionally based on their traceable origin. >> ? Classification actions shall be documented and publicly announced >> ? AFRINIC shall minimise fragmentation when reassigning recovered space. >> >> Rule 2 ? Delegation Rules for the Pre?Softlanding Pool >> >> The Pre?Softlanding Pool serves as the primary evaluation layer. >> ? Maximum delegation size: /18 per request. >> ? Minimum delegation size: /24 >> ? Justification period: 12 months >> ? Pre-use requirement: Applicants must provide evidence of efficient utilisation of all prior delegations to 80% >> ? Extended maximum: Up to /16 if the member provides: >> ? Documented growth metrics >> ? A verifiable deployment plan >> >> Members may not submit multiple concurrent or sequential requests intended to aggregate beyond the maximum delegation size. >> >> Rule 3 ? Automatic Deferral to the Soft?Landing Pool >> >> If a request cannot be satisfied by available blocks in the Pre?Softlanding Pool: >> ? The request shall be automatically deferred to the Soft?Landing Pool. >> ? AFRINIC staff must document the deferral and notify the applicant. >> ? Soft?Landing Phase 2 conditions, as defined in CPM Section?5.4, shall apply to all delegations made under this deferral mechanism. >> >> Rule 4 ? Post?Exhaustion Waiting List Framework >> >> When both the Soft?Landing Pool and Pre?Softlanding Pool reach zero available space, all IPv4 delegations shall be managed exclusively through a Post?Exhaustion Waiting List. >> >> 4.1 Feeding Mechanism >> ? The Recovered Pool becomes the sole source of IPv4 space for the waiting list. >> >> 4.2 Queue Rules >> ? Requests must demonstrate immediate infrastructural need. >> ? Queue operates strictly first?come, first?served. >> ? Only one active position per organisation or related entity. >> ? Requests expire after 30 days if the member does not respond. >> ? Mergers or acquisitions involving entities on the list shall result in consolidation to a single queue position. >> >> 4.3 Delegation Sizes >> ? Maximum: /23 >> ? Minimum: /24, unless global routing standards or internet community consensus officially shift the minimum universally routable prefix size below a /24, in which case AFRINIC shall align its minimum allocation floor to match the new global standard. >> ? If a /23 is justified but only a /24 is available, the member may accept the /24 without losing queue position. >> >> 4.4 Deployment Requirement >> ? Delegated space must be fully deployed within 6 months. >> ? After deployment, the member may re?apply at the bottom of the queue. >> >> 4.5 Transparency Requirements >> AFRINIC shall publish monthly: >> ? Queue length >> ? Total addresses available >> ? Average wait time >> ? Total recovered space processed >> >> Rule 5? Transfer of IPv4 addresses >> Address space delegated from the pre-softlanding pool and later on from the waiting list will not be eligible for transfer, with the exception of Mergers, Acquisition and Takeovers for a period of 24 months. Transfer restrictions on delegations from the soft landing pool shall apply. >> >> 5. Acknowledgements >> The authors acknowledge community feedback and operational insights from AFRINIC staff that informed this revised framework. >> >> 6. References >> ? AFRINIC Policy Implementation Experience Report >> ? AFRINIC Statistics Portal >> ? IANA Recovered IPv4 Pool Procedures >> ? Global RIR IPv4 Exhaustion Models >> >> 7. Situation in other regions >> >> 7.1 APNIC >> APNIC managed its final /8 by limiting allocations to a strict maximum size per member. Initially set to a /22, it was later reduced to a /23. On 2 July 2019, APNIC implemented Prop-129, which completely abolished the waiting list for unmet IPv4 requests due to the lack of a predictable stream of recovered space. Instead, APNIC continues to delegate up to a strict total lifetime maximum of a /23 per member exclusively from its remaining 103/8 pool and a separate pool of recovered non-103 space. Allocations from these scarce resource pools are held from voluntary transfer for a period of 24 months. >> >> 7.2 LACNIC >> LACNIC officially reached total exhaustion of its remaining non-recovered pools on August 19, 2020, triggering a permanent waiting list system funded strictly by returned, revoked, and recovered space after a mandatory 6-month quarantine. Under the LACNIC Waitlist Policy, approved organisations that have assigned IPv6 are placed in a first-come, first-served queue with a maximum allocation cap of a >> /22. Space allocated from the LACNIC waiting list is restricted from voluntary transfer for a period of 36 months. >> >> 7.3 RIPE NCC >> Following complete depletion of its available free pools, RIPE NCC implemented a strict post-exhaustion waiting list. Under the current RIPE IPv4 Waiting List Policy, allocations are restricted to exactly one /24 per Local Internet Registry (LIR), provided the LIR has never received an IPv4 allocation from RIPE NCC before. Allocations from this waiting list are held from voluntary transfer for a period of 24 months. >> >> 7.4 ARIN >> ARIN initially deployed an unrestricted waiting list. Because it lacked strong caps, the queue faced systemic gaming, forcing the ARIN Board to temporarily suspend the waiting list in 2019. ARIN subsequently reinstated the list with strict anti-gaming parameters: organisations holding more than a /20 equivalent in aggregate are entirely ineligible to apply, and the maximum allocation size is capped at a /22. Space distributed from the ARIN IPv4 Waiting List cannot be transferred to another organisation for 60 months, except in cases of corporate mergers, acquisitions, or takeovers. >> ===== >> >> >> Thanks >> >> ?Alain >> >> >> > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From aalain at trstech.net Thu Jun 18 14:11:09 2026 From: aalain at trstech.net (ALAIN AINA) Date: Thu, 18 Jun 2026 14:11:09 +0000 Subject: [rpd] New policy Proposal: Dynamic IPv4 Pools Exhaustion Management Framework In-Reply-To: <604E2DC6-C04C-4EAF-A963-F42327C75EC1@gmail.com> References: <604E2DC6-C04C-4EAF-A963-F42327C75EC1@gmail.com> Message-ID: Dear Co?chairs, The author wishes to reaffirm awareness of the provisions of Section 3.4.1 of the CPM, including the timelines governing the submission of policy proposals for consideration at an upcoming PPM. For the avoidance of doubt, this proposal is not being submitted for discussion at the next PPM. Its purpose at this stage is solely to place the text on the mailing list for community visibility and initial review. Furthermore, as is evident from its scope, the proposal extends well beyond the Soft?Landing recovery space. I trust this provides the necessary clarification. Thank you. ?Alain > On 18 Jun 2026, at 11:41, Darwin Da Costa wrote: > > Dear Policy Authors, > > We acknowledge receipt of the proposal titled Dynamic IPv4 Pools Exhaustion Management Framework, which seeks to amend Section 5.4 of the Consolidated Policy Manual on 8 June 2026. Please note that: > > 1. An existing proposal Soft Landing Recovered Space and Priority https://afrinic.net/policy/proposals/afpub-2026-ipv4-001-draft01#proposal is currently under discussion regarding the recovered IPv4 space after Softlanding Phase has been triggered at AFRINIC. > > 2. Furthermore, the timelines for submitting new proposals for the upcoming AFRINIC meeting was 23h59 UTC, 26 May 2026. > As a result, this proposal cannot be accepted as a new proposal for discussion at the upcoming PPM. > > We recommend and encourage that you share your proposal text around the recovered space and its merits with the author of the above mentioned proposal and PDWG on the RPD Mailing List as an improvement/alternative to the solution that is currently being discussed. > > We trust that the spirit of the consensus-driven bottom-up principle of the PDP will prevail and that the community would be forthcoming in improving the current policy proposal that is being discussed. > > Kind Regards > Darwin da Costa > Vincent Ngundi > PDWG Chairs > > >> On 17 Jun 2026, at 01:47, ALAIN AINA via RPD wrote: >> >> Hi PDWG, >> >> This proposal was submitted a week ago. >> >> Thanks >> >> ?Alain >> >>> Begin forwarded message: >>> >>> From: aalain at digitalintelligence.africa >>> Subject: New policy Proposal: Dynamic IPv4 Pools Exhaustion Management Framework >>> Date: 8 June 2026 at 10:11:47 GMT >>> To: pdwg-chairs at afrinic.net >>> Cc: policy-liaison at afrinic.net >>> >>> Dear Co-chairs, >>> >>> Please find below a new policy proposal. If all in order, please assign the ID and publish it as soon as possible. >>> >>> https://docs.google.com/document/d/1vy6RRhw1YTSmJ5W9bZlllw6rzH86nzdLl03zeL2DZ5U/edit?usp=sharing >>> >>> ===== >>> >>> Dynamic IPv4 Pools Exhaustion Management Framework >>> >>> AFPUB?2026?GEN?XXX >>> Version 1.0 >>> ID: Assigned by AFRINIC Staff >>> >>> Date Submitted: 08 June 2026 >>> >>> Author(s): >>> Adeola A. P. AINA (aalain at digitalintelligence.africa), >>> Co?authors: Contact me if you want to be co-author >>> >>> Obsoletes: Amends: The soft landing policy section 5.4 of the CPM >>> >>> >>> 1. Definitions >>> ? Delegation ? IPv4 Allocation to LIRs or Assignment to End?Users. >>> ? Recovered Space ? Any IPv4 resources returned, revoked, reclaimed, or otherwise recovered by AFRINIC. >>> ? Legacy Space ? Delegations prior to the RIR system and tagged as Legacy by AFRINIC. >>> ? Soft?Landing Pool ? The IPv4 pool administered under CPM Section 5.4 (Soft?Landing Phase 2). >>> ? Policy?Reserved Pool ? Dedicated IPv4 blocks reserved for specific sub?policies (e.g., IXPs, Critical Infrastructure). >>> ? Pre?Softlanding Pool ? A reserve pool replenished exclusively by recovered space originating from pre-Soft-Landing delegations, allocations from IANA?recovered space and unclaimed or un-registered Legacy space. >>> ? Recovered Pool ? The initial administrative holding area for all recovered IPv4 space prior to classification. >>> ? Post?Exhaustion Waiting List ? A structured queue used once both primary pools are fully depleted. >>> ? Immediate Infrastructural Need ? A documented requirement for IPv4 resources essential to maintain or activate operational network services. >>> >>> 2. Problem Statement >>> >>> 2.1 Summary of the Problem >>> >>> AFRINIC entered Soft?Landing Phase 2 in 2020 when the remaining non?reserved IPv4 space fell below one /11. Current delegation rates indicate: >>> ? Approximately 2 years remain before depletion of the active Soft?Landing Pool. >>> ? Approximately 3 additional years remain before depletion of the /12 block reserved for future use. >>> ? More than 3 million IPv4 addresses have been recovered and currently fall under Soft-landing Phase 2 rules by default. >>> Operational data shows that several members have obtained more than 8 ? /22 (/19) within a calendar year by submitting multiple sequential requests, revealing gaps in the current framework. >>> >>> The existing CPM lacks: >>> ? A structured mechanism to classify and return recovered space to its appropriate pool. >>> ? A predictable replenishment pipeline for IPv4 resources. >>> ? A post?exhaustion delegation framework. >>> ? Automated operational triggers that adjust delegation behaviour based on pool health. >>> ? Protections against gaming through repeated small requests. >>> >>> >>> 2.2 Summary of How This Proposal Addresses the Problem >>> >>> This proposal introduces: >>> ? A multi?pool IPv4 management architecture with clear replenishment rules. >>> ? A tiered delegation framework that prioritises pre Soft-landing recovered space. >>> ? A post?exhaustion waiting list with strict rationing and fairness rules. >>> ? A trace?back mechanism ensuring recovered space returns to its rightful pool. >>> ? Operational transparency and anti?gaming protections. >>> >>> 3. Proposed Solution >>> 3.1 IPv4 Pools >>> >>> This policy establishes four distinct IPv4 management pools: >>> ? Soft?Landing Pool ? Administered under CPM 5.4 Phase 2 rules. >>> ? Policy?Reserved Pools ? Dedicated pools for sub?policies such as IXPs and Critical Infrastructure. >>> ? Pre?Softlanding Pool ? Replenished exclusively by: >>> ? Unclaimed or Un-registered Legacy space >>> ? Delegations predating the soft?landing era >>> ? Allocations from the IANA Recovered IPv4 Pool >>> ? Recovered Pool ? Temporary holding area for all recovered space prior to classification. >>> >>> Operational Requirements: >>> ? All pools must be tracked independently in AFRINIC?s inventory system. >>> ? Movements between pools must be auditable and publicly reportable. >>> >>> >>> 3.2 Operational Rules >>> >>> Rule 1 ? Classification of Recovered Space >>> >>> ? All recovered space shall first enter the Recovered Pool. >>> ? AFRINIC staff shall trace each block to its original source pool category. >>> ? Space shall be returned to that source pool. >>> ? If the source cannot be determined with reasonable certainty, the space shall default to the Pre?Softlanding Pool. >>> ? Partial blocks shall be classified proportionally based on their traceable origin. >>> ? Classification actions shall be documented and publicly announced >>> ? AFRINIC shall minimise fragmentation when reassigning recovered space. >>> >>> Rule 2 ? Delegation Rules for the Pre?Softlanding Pool >>> >>> The Pre?Softlanding Pool serves as the primary evaluation layer. >>> ? Maximum delegation size: /18 per request. >>> ? Minimum delegation size: /24 >>> ? Justification period: 12 months >>> ? Pre-use requirement: Applicants must provide evidence of efficient utilisation of all prior delegations to 80% >>> ? Extended maximum: Up to /16 if the member provides: >>> ? Documented growth metrics >>> ? A verifiable deployment plan >>> >>> Members may not submit multiple concurrent or sequential requests intended to aggregate beyond the maximum delegation size. >>> >>> Rule 3 ? Automatic Deferral to the Soft?Landing Pool >>> >>> If a request cannot be satisfied by available blocks in the Pre?Softlanding Pool: >>> ? The request shall be automatically deferred to the Soft?Landing Pool. >>> ? AFRINIC staff must document the deferral and notify the applicant. >>> ? Soft?Landing Phase 2 conditions, as defined in CPM Section?5.4, shall apply to all delegations made under this deferral mechanism. >>> >>> Rule 4 ? Post?Exhaustion Waiting List Framework >>> >>> When both the Soft?Landing Pool and Pre?Softlanding Pool reach zero available space, all IPv4 delegations shall be managed exclusively through a Post?Exhaustion Waiting List. >>> >>> 4.1 Feeding Mechanism >>> ? The Recovered Pool becomes the sole source of IPv4 space for the waiting list. >>> >>> 4.2 Queue Rules >>> ? Requests must demonstrate immediate infrastructural need. >>> ? Queue operates strictly first?come, first?served. >>> ? Only one active position per organisation or related entity. >>> ? Requests expire after 30 days if the member does not respond. >>> ? Mergers or acquisitions involving entities on the list shall result in consolidation to a single queue position. >>> >>> 4.3 Delegation Sizes >>> ? Maximum: /23 >>> ? Minimum: /24, unless global routing standards or internet community consensus officially shift the minimum universally routable prefix size below a /24, in which case AFRINIC shall align its minimum allocation floor to match the new global standard. >>> ? If a /23 is justified but only a /24 is available, the member may accept the /24 without losing queue position. >>> >>> 4.4 Deployment Requirement >>> ? Delegated space must be fully deployed within 6 months. >>> ? After deployment, the member may re?apply at the bottom of the queue. >>> >>> 4.5 Transparency Requirements >>> AFRINIC shall publish monthly: >>> ? Queue length >>> ? Total addresses available >>> ? Average wait time >>> ? Total recovered space processed >>> >>> Rule 5? Transfer of IPv4 addresses >>> Address space delegated from the pre-softlanding pool and later on from the waiting list will not be eligible for transfer, with the exception of Mergers, Acquisition and Takeovers for a period of 24 months. Transfer restrictions on delegations from the soft landing pool shall apply. >>> >>> 5. Acknowledgements >>> The authors acknowledge community feedback and operational insights from AFRINIC staff that informed this revised framework. >>> >>> 6. References >>> ? AFRINIC Policy Implementation Experience Report >>> ? AFRINIC Statistics Portal >>> ? IANA Recovered IPv4 Pool Procedures >>> ? Global RIR IPv4 Exhaustion Models >>> >>> 7. Situation in other regions >>> >>> 7.1 APNIC >>> APNIC managed its final /8 by limiting allocations to a strict maximum size per member. Initially set to a /22, it was later reduced to a /23. On 2 July 2019, APNIC implemented Prop-129, which completely abolished the waiting list for unmet IPv4 requests due to the lack of a predictable stream of recovered space. Instead, APNIC continues to delegate up to a strict total lifetime maximum of a /23 per member exclusively from its remaining 103/8 pool and a separate pool of recovered non-103 space. Allocations from these scarce resource pools are held from voluntary transfer for a period of 24 months. >>> >>> 7.2 LACNIC >>> LACNIC officially reached total exhaustion of its remaining non-recovered pools on August 19, 2020, triggering a permanent waiting list system funded strictly by returned, revoked, and recovered space after a mandatory 6-month quarantine. Under the LACNIC Waitlist Policy, approved organisations that have assigned IPv6 are placed in a first-come, first-served queue with a maximum allocation cap of a >>> /22. Space allocated from the LACNIC waiting list is restricted from voluntary transfer for a period of 36 months. >>> >>> 7.3 RIPE NCC >>> Following complete depletion of its available free pools, RIPE NCC implemented a strict post-exhaustion waiting list. Under the current RIPE IPv4 Waiting List Policy, allocations are restricted to exactly one /24 per Local Internet Registry (LIR), provided the LIR has never received an IPv4 allocation from RIPE NCC before. Allocations from this waiting list are held from voluntary transfer for a period of 24 months. >>> >>> 7.4 ARIN >>> ARIN initially deployed an unrestricted waiting list. Because it lacked strong caps, the queue faced systemic gaming, forcing the ARIN Board to temporarily suspend the waiting list in 2019. ARIN subsequently reinstated the list with strict anti-gaming parameters: organisations holding more than a /20 equivalent in aggregate are entirely ineligible to apply, and the maximum allocation size is capped at a /22. Space distributed from the ARIN IPv4 Waiting List cannot be transferred to another organisation for 60 months, except in cases of corporate mergers, acquisitions, or takeovers. >>> ===== >>> >>> >>> Thanks >>> >>> ?Alain >>> >>> >>> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > From gregoire.ehoumi at yahoo.fr Fri Jun 19 22:22:16 2026 From: gregoire.ehoumi at yahoo.fr (Gregoire EHOUMI) Date: Fri, 19 Jun 2026 18:22:16 -0400 Subject: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. In-Reply-To: References: <1EC212BF-EA11-4FB4-B5C4-B7429FFE6209@gmail.com> <4D12F3EC-E524-468A-BA8A-782BA4483DA6@yahoo.fr> Message-ID: Hello Seun, Please see the references below. Most importantly, what do you think should not be listed under the co-chairs' roles and responsibilities in the proposal? https://www.apnic.net/community/participate/sigs/sig-guidelines/ Chair and co-chairs roles - section 2.3 https://www.lacnic.net/679/2/lacnic/policy-development-process PDP chairs section 3.2 https://www.ripe.net/publications/docs/ripe-861/ RIPE Working Group Chair Job Description and Procedures ? RIPE Network Coordination Centre Best regards, Gregoire > On Jun 9, 2026, at 9:09?PM, Seun Ojedeji wrote: > > Hello Gregoire, > > Please find the details inline: > > On Tue, 9 Jun 2026 at 14:27, Gregoire EHOUMI > wrote: >> Dear PDWG, >> >> This digest summarises the key points raised by community members (Ben, Seun, and Sami) regarding this policy proposal, along with the authors? clarifications and responses. >> It is organised into four themes for easier reading. >> >> 1. Corrections & Clarifications >> Mailing list freeze clarification: >> Comment (Ben): The RPD list was not frozen; only community?discuss was moderated. >> Response: Acknowledged. The text will be corrected in Draft?2. It was meant to say ? Inactive Resource Policy Discussion mailing list? >> >> 2. Participation, Representation & Elections >> Nomination support requirements: >> Comment (Seun): No need for supporters to be both AFRINIC members and community members. >> Response: The intent is to ensure support from at least one contact of the membership. Participants in the PDP and the WG activities are generally classified in 2 categories: ?Registered contact of AFRINIC member? and ? Non-registered contact of AFRINIC member? > SO: Current participants of RPD do not need to be a ?Registered contact of AFRINIC member? OR ? Non-registered contact of AFRINIC member?, the PDWG is and should be open to any person interested in number policy development including non AFRINIC members. Note that there is a subtle difference between non-registered contact of AFRINIC member and a non-AFRINIC member. It should be okay to require support from either an AFRINIC member OR a community member, but the current text mandates both.To illustrate a nomination supported by 2 community members should pass just as a nomination supported by 2 afrinic member, likewise 1 afrinic member and 1 community member. > >> >> Who can vote in NRO NC elections: >> Comment (Seun): No reason to restrict voting to people in the region. >> Response: This follows existing AFRINIC rules. For NRO NC, only participants from the region(excluding staff) vote. > > SO: My rationale is based on the premise that the rpd is open to all; hence, PDWG co-chair voters should not be restricted to in-region. By extension, NRO NC voters should be similar. Nevertheless considering past experiences, I agree there is merit in restricting voting to in-region but that discriminates on participation as voting is a form of participation as well. >> >> 3. Co?Chair Roles, Eligibility & Processes >> Level of detail in co?chair responsibilities: >> Comment (Seun): Responsibilities in section 3.3.2 feel too granular and policing. >> Response: The detail is intentional, based on RFC?2418 and other RIRs practices, to avoid ambiguity. The WG should be predictable. > > SO: I do not know of an RIR process that is as granular in the responsibility of co-chairs as stated in 3.3.2. Section 6.1 of RFC 2418 that describes the role of a working group chair isn't as granular either. >> >> Eligibility criteria ? meeting attendance: >> Comment (Seun): Requiring attendance at 4 of the last 6 PPMs (including one in?person) may be unrealistic. >> Response: at the old rhythm of 2 PPMs a year, this requirement means attending 4 of the 6 meetings held the last 3 years with at least one in-person. With Attendance A=4 and Meetings M= 6, what would you suggest for A and M? > SO: Requiring in-person attendance is my main concern, it should not be mandatory. You may find at times that it is cheaper to travel out of Africa than within Africa, so not everyone can afford an in-person meeting. Let individual voters decide on candidates based on their historical participation. >> >> Appointment by consensus: >> Comment (Seun): Consensus?based appointment could introduce subjectivity. >> Response: This WG makes decisions by consensus with appeal mechanisms in place. Appointing co-chairs via the same mechanisms should not be a problem. With the requirements stated at section 3.3.3, it should not be difficult to reach consensus on co-chairs candidates. While this may not be perfect, it is used worldwide by various WGs. ?Community? votes rather bring more subjectivity. >> >> Code of Conduct reference: >> Comment (Seun): Simply refer to AFRINIC?s CoC. >> Response: By referring to ?applicable CoC? the proposal avoids attaching to a particular CoC. Today we are using the ?AFRINIC Community CoC? elaborated by the board ( https://afrinic.net/code ), this may change in the future. We saw some recent CoC discussions on the list. > SO: Who determines which Code of Conduct (CoC) is "applicable" and which is not? >> >> 4. Governance Structure & Proposal Scope >> Necessity of the Number Council: >> Comment (Seun): The Appeal Committee could perform the same role; RNC may be unnecessary. >> Response: The RNC?s roles encompass calling PPM and appointing interim co-chairs. So making the AC perform RNC?s role may not be appropriate. > > What I am trying to communicate is that the RNC and its proposed roles are not required. There is value in having nomcom whose membership is more likely to change every year perform the role of getting nominations for PDWG Co-Chair. If both Co-Chairs resign, the Board should select one of the 3 NRO NC members to chair temporarily until a co-Chair is elected. >> >> Splitting the proposal into smaller documents: >> Comment (Sami): Consider withdrawing and splitting into multiple focused proposals. >> Response: The components are interdependent; splitting them would create incoherent intermediate states and procedural gaps. > SO: I looked at the problem enumerated below: > > Adopted policy proposals not ratified or not implemented > No Public Policy Meeting - Non-renewal of co-chairs > Non-renewal of appeal and recall committees > Non-renewal of ASO AC/NRO NC representatives > Frozen Resource Policy Discussion mailing list > The problems stated in the policy as listed above (apart from the last which has been corrected) all stemmed from the Board not having a quorum. The idea that the volunteer PDWG should or can effectively operate when there is no Board in the future is wishful thinking that should not be encouraged. In fact, the PDP operation is mandated by the bylaws, and the Board has the fiduciary responsibility to oversee the entire organisation. It therefore seems to me that this policy attempts to address a governance issue through policy rather than through the bylaws. Bylaws is the way to ensure that the events that happened with the Board in the past does not repeat itself. >> >> Board ratification language: >> Comment (Seun): ?Shall? implies the Board must ratify; the Board should be able to decline with reasons. >> Response: The text as written ?If a policy proposal approved by the PDWG fails to be ratified by the board (inability or refusal by the board without reasons for 60 days), a petition for ratification can be initiated by a member of the PDWG.? it is meant to cover the two scenarios below: >> 1. The Board is unable to act for 60 days (No quorum, No functioning Board, Legal or operational paralysis, etc.) >> 2. The Board refuses to ratify without giving reasons for 60 days (the Board says ?no? but gives no justification, or The Board simply does nothing and provides no explanation.) >> Any suggestions to improve the text if it is not clear enough ? > > SO: I think there may be a need to review the problem statement first so the rest of the document is better guided > > Regards >> >> >> The authors thank the community for constructive feedback. >> >> Regards, >> >> Gr?goire >> >> >> >>> On May 27, 2026, at 2:45?PM, Sami Salih > wrote: >>> >>> Dear Colleagues, >>> >>> As a former PDWG Co-chair, I generally support the intent behind strengthening the autonomy and operational continuity of the PDWG. The policy development process ultimately belongs to the African Internet community and should remain resilient regardless of operational or governance challenges affecting AFRINIC as an organisation. >>> >>> At the same time, I believe it is important to recognize that this proposal introduces substantial structural, operational, procedural, and governance changes to the PDP framework. In many respects, this is a major and transformative proposal rather than a routine procedural update. >>> >>> From my experience with the PDP, the community process tends to work best when addressing clearly scoped issues through focused and easy-to-understand proposals. In contrast, this proposal attempts to address many different governance, electoral, operational, disciplinary, and procedural matters simultaneously, which makes it difficult for the community to fully analyse, discuss, and build meaningful consensus around all aspects at once. >>> >>> IMHO, many of the ideas and intended improvements presented in this proposal are constructive and deserve serious consideration. I also fully acknowledge and respect the extensive experience, effort, and strategic thinking of the authors in developing such a comprehensive framework proposal. >>> >>> However, considering the breadth of the changes and the number of distinct governance and operational matters being introduced simultaneously, my respectful recommendation would be to consider withdrawing the current proposal and restructuring this work into multiple smaller and more focused proposals. I believe this would make it significantly easier for the community to understand, analyse, discuss, and build meaningful consensus around each individual topic independently, while improving overall community engagement and participation in the process. >>> >>> With Regards, >>> Sami Sali. >>> >>> >>> >>> Sami Salih >>> From: Seun Ojedeji > >>> Sent: Monday, May 25, 2026 8:43:56 PM >>> To: dacostadarwin at gmail.com > >>> Cc: rpd at afrinic.net > >>> Subject: Re: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. >>> >>> Hello, >>> >>> Thanks for sharing this proposal. My initial comments after a brief review are the following: >>> >>> - A typical community member could also be an AFRINIC member. There is no reason to mandate that nomination supporters for the NRO NC must be both community members and AFRINIC members. Requiring one or 2 supporters from the service region should be sufficient. >>> >>> - The rpd is open to anyone that wishes to participate irrespective of origin, region or residence. It sure makes sense to restrict election participation to those with a historical record of involvement, either online or in-person to avoid historical experience of DDOS on election day. However, there is no reason to restrict the selectorate/electorate to those in the region alone. >>> >>> - I do not see the necessity of a Number Committee; it seems to create yet another layer. The Appeal committee which also serves as the recall committee can perform any intended role of the RNC. Its composition could be the 3 NRO NC members from the region, a past co-chair, and a past appeal committee chair in a non-voting capacity. In situations where both Co-Chairs are no more, the Chair of the Appeal committee can temporarily take over until rpd appoints a new co-chair >>> >>> - As a former co-chair of PDWG, i find the proposed responsibilities of the Co-chairs as described in section 3.3.2 to be overly granular and quite policing-like for lack of a better word. >>> >>> - I believe the proposed 3.3.7 should refer to AFRINIC CoC and that should be sufficient. The proposed penalties for violations look good, though they are a bit too wordy to me and the process leading to that is quite descriptive. We really need to give the co-chairs the privilege of managing events as they deem applicable >>> >>> - The idea that a co-chair eligibility should be tied to attending in-person meetings during a specific period isn't realistic given our region's unique challenges. I understand it may be an effort to put a face to the name but restricting eligibility to the last 2 years (which is basically last 4 PPM) isn't realistic. >>> >>> - 3.3.3.3.3 suggests co-chairs will be appointed by consensus, that is an interesting point that i would definitely not support. This can lead to unnecessary subjectivity. >>> >>> - I like the expectation of participation from Co-Chair hence 3.3.4 appeals to me as written. >>> >>> - Use of shall in 3.3.11 suggests that ratification is the only option for the Board. There should be an option for the Board to provide reasons for not ratifying and that should not be triggered by a petition. >>> >>> I may have more comments in future, but that is all from me for now. >>> >>> Regards >>> >>> On Mon, 25 May 2026 at 10:20, dacostadarwin at gmail.com > wrote: >>> Dear PDWG, >>> >>> We have received a new draft policy proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01 from authors Gr?goire EHOUMI, Noah Maina and Adeola A. P. AINA. >>> >>> The proposal contents are published at: https://afrinic.net/policy/proposals/afpub-2026-gen-001-draft01 >>> >>> We encourage you to take some time to go through the proposal contents and provide feedback as follows : >>> >>> a) Do you support or oppose the proposal? >>> >>> b) If you oppose the proposal, state your reasons. >>> >>> c) Is there anything in the proposal that is not clear? >>> >>> d) What changes could be made to this proposal to make it more effective? >>> >>> Regards, >>> Vincent Ngundi & Darwin Da Costa >>> AFRINIC PDWG Co-Chairs >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> >>> -- >>> ------------------------------------------------------------------------ >>> Seun Ojedeji, >>> Bringing another down does not take you up - think about your action! >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> > > > > -- > ------------------------------------------------------------------------ > Seun Ojedeji, > Bringing another down does not take you up - think about your action! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oloyede.aa at unilorin.edu.ng Fri Jun 19 22:56:32 2026 From: oloyede.aa at unilorin.edu.ng (Abdulkarim Oloyede) Date: Fri, 19 Jun 2026 23:56:32 +0100 Subject: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. In-Reply-To: References: <1EC212BF-EA11-4FB4-B5C4-B7429FFE6209@gmail.com> Message-ID: Hi Arnaud, These are two diffrent things. Its comparing Apples with oranges. When we know they are both fruits. Cheers Abdulkarim. On Sun, Jun 14, 2026, 4:37?PM Arnaud AMELINA wrote: > Hi PDW members, Hi AK, > > Are you suggesting that decisions made by consensus by the WG are lawless? > > Regards > >> >+1 to Seun except that I agree that only people from the region should vote. >> > >> >I do not think Seun's concerns have been addressed, especially on: below >> >and I have a few additional concerns >> >1. Responsibilities in section 3.3.2 feel too granular and policing. >> > >> >2. Requiring attendance at 4 of the last 6 PPMs (including one in?person) >> >may be unrealistic. (I totally agree to this except if the requirement is >> >personal funding for the one meeting.) Physical attendance does not show >> >commitment; it?s about opportunities most times. >> > >> >3. Consensus?based appointment could introduce subjectivity. I totally >> >agree with this; it brings not just subjectivity but anarchy and >> >lawlessness. >> > >> > 4. Registered PPM attendee voting... Does this include online attendees? >> >Then I think we need to make up our mind on who should vote. My suggestion >> >is members only should vote. >> > >> > 5. I totally disagree with having a recall committee and having recall >> >committee decisions being final. This is subject to manipulation and abuse, >> >and the chair is entirely at the mercy of few individuals called the recall >> >committee. This is because the recall committee doesn?t appoint chairs, >> >neither do 10 members appoint chairs. To remove chairs must be subjected to >> >the same process as electing a chair. There must be a general vote with >> >majority agreeing to recall the chair. >> > >> > >> > >> >*AK.* >> > >> > >> >> *Prof Abdulkarim Oloyede* >> *Professor of Wireless Telecommunications * >> *University of Ilorin. * >> >> On Tue, Jun 9, 2026, 9:34?PM Gregoire EHOUMI via RPD > >> wrote: >> >> >* Dear PDWG, >> *>>* This digest summarises the key points raised by community members (Ben, >> *>* Seun, and Sami) regarding this policy proposal, along with the authors? >> *>* clarifications and responses. >> *>* It is organised into four themes for easier reading. >> *>>* *1. Corrections & Clarifications* >> *>* *Mailing list freeze clarification:* >> *>>* - Comment (Ben): The RPD list was not frozen; only community?discuss >> *>* was moderated. >> *>* - *Response: *Acknowledged. The text will be corrected in Draft?2. It >> *>* was meant to say ? Inactive Resource Policy Discussion mailing list? >> *>>>* *2. Participation, Representation & Elections* >> *>* *Nomination support requirements:* >> *>>* - Comment (Seun): No need for supporters to be both AFRINIC members >> *>* and community members. >> *>* - *Response:* The intent is to ensure support from at least one >> *>* contact of the membership. Participants in the PDP and the WG activities >> *>* are generally classified in 2 categories: ?Registered contact of AFRINIC >> *>* member? and ? Non-registered contact of AFRINIC member? >> *>>>* *Who can vote in NRO NC elections:* >> *>>* - Comment (Seun): No reason to restrict voting to people in the region. >> *>* - *Response:* This follows existing AFRINIC rules. For NRO NC, only >> *>* participants from the region(excluding staff) vote. >> *>>>* *3. Co?Chair Roles, Eligibility & Processes* >> *>* *Level of detail in co?chair responsibilities:* >> *>>* - Comment (Seun): Responsibilities in section 3.3.2 feel too granular >> *>* and policing. >> *>* - *Response: *The detail is intentional, based on RFC?2418 and other >> *>* RIRs practices, to avoid ambiguity. The WG should be predictable. >> *>>>* *Eligibility criteria ? meeting attendance:* >> *>>* - Comment (Seun): Requiring attendance at 4 of the last 6 PPMs >> *>* (including one in?person) may be unrealistic. >> *>* - *Response:* at the old rhythm of 2 PPMs a year, this requirement >> *>* means attending 4 of the 6 meetings held the last 3 years with at least >> *>* one in-person. With Attendance A=4 and Meetings M= 6, what would you >> *>* suggest for A and M? >> *>>>* *Appointment by consensus:* >> *>>* - Comment (Seun): Consensus?based appointment could introduce >> *>* subjectivity. >> *>* - *Response:* This WG makes decisions by consensus with appeal >> *>* mechanisms in place. Appointing co-chairs via the same mechanisms should >> *>* not be a problem. With the requirements stated at section 3.3.3, it should >> *>* not be difficult to reach consensus on co-chairs candidates. While this may >> *>* not be perfect, it is used worldwide by various WGs. ?Community? votes >> *>* rather bring more subjectivity. >> *>>>* *Code of Conduct reference:* >> *>>* - Comment (Seun): Simply refer to AFRINIC?s CoC. >> *>* - *Response:* By referring to ?applicable CoC? the proposal avoids >> *>* attaching to a particular CoC. Today we are using the ?AFRINIC Community >> *>* CoC? elaborated by the board ( https://afrinic.net/code ), this may >> *>* change in the future. We saw some recent CoC discussions on the list. >> *>>>* *4. Governance Structure & Proposal Scope* >> *>* *Necessity of the Number Council:* >> *>>* - Comment (Seun): The Appeal Committee could perform the same role; >> *>* RNC may be unnecessary. >> *>* - *Response: *The RNC?s roles encompass calling PPM and appointing >> *>* interim co-chairs. So making the AC perform RNC?s role may not be >> *>* appropriate. >> *>>>* *Splitting the proposal into smaller documents:* >> *>>* - Comment (Sami): Consider withdrawing and splitting into multiple >> *>* focused proposals. >> *>* - *Response:* The components are interdependent; splitting them would >> *>* create incoherent intermediate states and procedural gaps. >> *>>>* *Board ratification language:* >> *>>* - Comment (Seun): ?Shall? implies the Board must ratify; the Board >> *>* should be able to decline with reasons. >> *>* - *Response:* The text as written ?If a policy proposal approved by >> *>* the PDWG fails to be ratified by the board (inability or refusal by the >> *>* board without reasons for 60 days), a petition for ratification can be >> *>* initiated by a member of the PDWG.? it is meant to cover the two scenarios >> *>* below: >> *>>* 1. The Board is unable to act for 60 days (No quorum, No functioning >> *>* Board, Legal or operational paralysis, etc.) >> *>* 2. The Board refuses to ratify without giving reasons for 60 days (the >> *>* Board says ?no? but gives no justification, or The Board simply does >> *>* nothing and provides no explanation.) >> *>* Any suggestions to improve the text if it is not clear enough ? >> *>>>* The authors thank the community for constructive feedback. >> *>>* Regards, >> *>>* Gr?goire >> *>>>>* On May 27, 2026, at 2:45?PM, Sami Salih > wrote: >> *>>* Dear Colleagues, >> *>>* As a former PDWG Co-chair, I generally support the intent behind >> *>* strengthening the autonomy and operational continuity of the PDWG. The >> *>* policy development process ultimately belongs to the African Internet >> *>* community and should remain resilient regardless of operational or >> *>* governance challenges affecting AFRINIC as an organisation. >> *>>* At the same time, I believe it is important to recognize that this >> *>* proposal introduces substantial structural, operational, procedural, and >> *>* governance changes to the PDP framework. In many respects, this is a major >> *>* and transformative proposal rather than a routine procedural update. >> *>>* From my experience with the PDP, the community process tends to work best >> *>* when addressing clearly scoped issues through focused and >> *>* easy-to-understand proposals. In contrast, this proposal attempts to >> *>* address many different governance, electoral, operational, disciplinary, >> *>* and procedural matters simultaneously, which makes it difficult for the >> *>* community to fully analyse, discuss, and build meaningful consensus around >> *>* all aspects at once. >> *>>* IMHO, many of the ideas and intended improvements presented in this >> *>* proposal are constructive and deserve serious consideration. I also fully >> *>* acknowledge and respect the extensive experience, effort, and strategic >> *>* thinking of the authors in developing such a comprehensive framework >> *>* proposal. >> *>>* However, considering the breadth of the changes and the number of distinct >> *>* governance and operational matters being introduced simultaneously, my >> *>* respectful recommendation would be to consider withdrawing the current >> *>* proposal and restructuring this work into multiple smaller and more focused >> *>* proposals. I believe this would make it significantly easier for the >> *>* community to understand, analyse, discuss, and build meaningful consensus >> *>* around each individual topic independently, while improving overall >> *>* community engagement and participation in the process. >> *>>* With Regards, >> *>* Sami Sali. >> *>>>* Sami Salih >> *>* ------------------------------ >> *>* *From:* Seun Ojedeji > >> *>* *Sent:* Monday, May 25, 2026 8:43:56 PM >> *>* *To:* dacostadarwin at gmail.com > >> *>* *Cc:* rpd at afrinic.net > >> *>* *Subject:* Re: [rpd] New Draft Policy Proposal - Amendment of the PDP >> *>* Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. >> *>>* Hello, >> *>>* Thanks for sharing this proposal. My initial comments after a brief review >> *>* are the following: >> *>>* - A typical community member could also be an AFRINIC member. There is no >> *>* reason to mandate that nomination supporters for the NRO NC must be both >> *>* community members and AFRINIC members. Requiring one or 2 supporters from >> *>* the service region should be sufficient. >> *>>* - The rpd is open to anyone that wishes to participate irrespective of >> *>* origin, region or residence. It sure makes sense to restrict election >> *>* participation to those with a historical record of involvement, either >> *>* online or in-person to avoid historical experience of DDOS on election >> *>* day. However, there is no reason to restrict the selectorate/electorate to >> *>* those in the region alone. >> *>>* - I do not see the necessity of a Number Committee; it seems to create yet >> *>* another layer. The Appeal committee which also serves as the recall >> *>* committee can perform any intended role of the RNC. Its composition could >> *>* be the 3 NRO NC members from the region, a past co-chair, and a past appeal >> *>* committee chair in a non-voting capacity. In situations where both >> *>* Co-Chairs are no more, the Chair of the Appeal committee can temporarily >> *>* take over until rpd appoints a new co-chair >> *>>* - As a former co-chair of PDWG, i find the proposed responsibilities of >> *>* the Co-chairs as described in section 3.3.2 to be overly granular and >> *>* quite policing-like for lack of a better word. >> *>>* - I believe the proposed 3.3.7 should refer to AFRINIC CoC and that should >> *>* be sufficient. The proposed penalties for violations look good, though they >> *>* are a bit too wordy to me and the process leading to that is quite >> *>* descriptive. We really need to give the co-chairs the privilege of managing >> *>* events as they deem applicable >> *>>* - The idea that a co-chair eligibility should be tied to attending >> *>* in-person meetings during a specific period isn't realistic given our >> *>* region's unique challenges. I understand it may be an effort to put a face >> *>* to the name but restricting eligibility to the last 2 years (which is >> *>* basically last 4 PPM) isn't realistic. >> *>>* - 3.3.3.3.3 suggests co-chairs will be appointed by consensus, that is an >> *>* interesting point that i would definitely not support. This can lead to >> *>* unnecessary subjectivity. >> *>>* - I like the expectation of participation from Co-Chair hence 3.3.4 >> *>* appeals to me as written. >> *>>* - Use of shall in 3.3.11 suggests that ratification is the only option for >> *>* the Board. There should be an option for the Board to provide reasons for >> *>* not ratifying and that should not be triggered by a petition. >> *>>* I may have more comments in future, but that is all from me for now. >> *>>* Regards >> *>>* On Mon, 25 May 2026 at 10:20, dacostadarwin at gmail.com < >> *>* dacostadarwin at gmail.com > wrote: >> *>>* Dear PDWG, >> *>>* We have received a new draft policy proposal - Amendment of the PDP >> *>* Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01 >> *>* from authors Gr?goire EHOUMI, Noah Maina and Adeola A. P. AINA. >> *>>* The proposal contents are published at: >> *>* https://afrinic.net/policy/proposals/afpub-2026-gen-001-draft01 >> *>>* We encourage you to take some time to go through the proposal contents >> *>* and provide feedback as follows : >> *>>* a) Do you support or oppose the proposal? >> *>>* b) If you oppose the proposal, state your reasons. >> *>>* c) Is there anything in the proposal that is not clear? >> *>>* d) What changes could be made to this proposal to make it more effective? >> *>>* Regards, >> *>* Vincent Ngundi & Darwin Da Costa >> *>* AFRINIC PDWG Co-Chairs >> *>* _______________________________________________ >> *>* RPD mailing list >> *>* RPD at afrinic.net >> *>* https://lists.afrinic.net/mailman/listinfo/rpd >> *>>>>* -- >> *>* ------------------------------------------------------------------------ >> *>>>* *Seun Ojedeji, * >> *>>* Bringing another down does not take you up - think about your action! >> *>>>* _______________________________________________ >> *>* RPD mailing list >> *>* RPD at afrinic.net >> *>* https://lists.afrinic.net/mailman/listinfo/rpd >> *>>>* _______________________________________________ >> *>* RPD mailing list >> *>* RPD at afrinic.net >> *>* https://lists.afrinic.net/mailman/listinfo/rpd >> *> >> >> -- Website ,?Weekly Bulletin ?UGPortal PGPortal ?HelpDesk -------------- next part -------------- An HTML attachment was scrubbed... URL: From seun.ojedeji at gmail.com Sat Jun 20 20:25:38 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Sat, 20 Jun 2026 15:25:38 -0500 Subject: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. In-Reply-To: References: <1EC212BF-EA11-4FB4-B5C4-B7429FFE6209@gmail.com> <4D12F3EC-E524-468A-BA8A-782BA4483DA6@yahoo.fr> Message-ID: Hello Gregoire, Thanks for putting those references, you will find that referenced roles and responsibility from other RIRs and our current PDP puts some trust in the chair(s) to do the needful based on expected outcome. IMO 3.3.2.1 e,f,g,I are currently worded in much granular manner. Take f for instance, why won't the Co-Chairs read presentation, so what happens if the Co-Chair missed reading the presentation or if they did but someone within the PDWG claim they didn't. The text Preceding 3.3.2.1 addresses a lot of the granularity of 3.3.2.1: "Organise, prepare and chair the face-to-face and on-line formal working group meetings as well as community consultation meetings." That said, please do not loose sight of the main concerns that I have raised already. One of them is that we need to be clear on what problem we are trying to address. The problems stated in the current proposal are not problems unique to PDWG, they are organisational problems and PDWG was rightly affected by them just like the other part of the org was affected. However, PDWG is not the place to address those problems. This proposal is attempting to use the event that occurred to the board to turn PDWG to a self governing independent authority through policy and I do not believe that is the way to go about it. Nevertheless, there is merit in clarifying roles of Co-Chairs and some of the 3.3.2 texts addresses that, hence that then can become the problem statement and sections that does not relate to roles and responsibilities can be commented out. Regards ---- Sent from my mobile kindly excuse typos On Fri, 19 Jun 2026, 6:22?pm Gregoire EHOUMI, wrote: > Hello Seun, > > Please see the references below. Most importantly, what do you think > should not be listed under the co-chairs' roles and responsibilities in the > proposal? > > https://www.apnic.net/community/participate/sigs/sig-guidelines/ > Chair and co-chairs roles - section 2.3 > > https://www.lacnic.net/679/2/lacnic/policy-development-process > PDP chairs section 3.2 > > https://www.ripe.net/publications/docs/ripe-861/ > > RIPE Working Group Chair Job Description and Procedures ? RIPE Network > Coordination Centre > > Best regards, > > Gregoire > > > On Jun 9, 2026, at 9:09?PM, Seun Ojedeji wrote: > > Hello Gregoire, > > Please find the details inline: > > On Tue, 9 Jun 2026 at 14:27, Gregoire EHOUMI > wrote: > >> Dear PDWG, >> >> This digest summarises the key points raised by community members (Ben, >> Seun, and Sami) regarding this policy proposal, along with the authors? >> clarifications and responses. >> It is organised into four themes for easier reading. >> >> *1. Corrections & Clarifications* >> *Mailing list freeze clarification:* >> >> - Comment (Ben): The RPD list was not frozen; only community?discuss >> was moderated. >> - *Response: *Acknowledged. The text will be corrected in Draft?2. It >> was meant to say ? Inactive Resource Policy Discussion mailing list? >> >> >> *2. Participation, Representation & Elections* >> *Nomination support requirements:* >> >> - Comment (Seun): No need for supporters to be both AFRINIC members >> and community members. >> - *Response:* The intent is to ensure support from at least one >> contact of the membership. Participants in the PDP and the WG activities >> are generally classified in 2 categories: ?Registered contact of AFRINIC >> member? and ? Non-registered contact of AFRINIC member? >> >> SO: Current participants of RPD do not need to be a ?Registered contact > of AFRINIC member? OR ? Non-registered contact of AFRINIC member?, the > PDWG is and should be open to any person interested in number policy > development including non AFRINIC members. Note that there is a subtle > difference between non-registered contact of AFRINIC member and a > non-AFRINIC member. It should be okay to require support from either an > AFRINIC member OR a community member, but the current text mandates both.To > illustrate a nomination supported by 2 community members should pass just > as a nomination supported by 2 afrinic member, likewise 1 afrinic member > and 1 community member. > > >> >> *Who can vote in NRO NC elections:* >> >> - Comment (Seun): No reason to restrict voting to people in the >> region. >> - *Response:* This follows existing AFRINIC rules. For NRO NC, only >> participants from the region(excluding staff) vote. >> >> > SO: My rationale is based on the premise that the rpd is open to all; > hence, PDWG co-chair voters should not be restricted to in-region. By > extension, NRO NC voters should be similar. Nevertheless considering past > experiences, I agree there is merit in restricting voting to in-region but > that discriminates on participation as voting is a form of participation as > well. > >> >> *3. Co?Chair Roles, Eligibility & Processes* >> *Level of detail in co?chair responsibilities:* >> >> - Comment (Seun): Responsibilities in section 3.3.2 feel too granular >> and policing. >> - *Response: *The detail is intentional, based on RFC?2418 and other >> RIRs practices, to avoid ambiguity. The WG should be predictable. >> >> > SO: I do not know of an RIR process that is as granular in the > responsibility of co-chairs as stated in 3.3.2. Section 6.1 of RFC 2418 > that describes the role of a working group chair isn't as granular either. > >> >> *Eligibility criteria ? meeting attendance:* >> >> - Comment (Seun): Requiring attendance at 4 of the last 6 PPMs >> (including one in?person) may be unrealistic. >> - *Response:* at the old rhythm of 2 PPMs a year, this requirement >> means attending 4 of the 6 meetings held the last 3 years with at least >> one in-person. With Attendance A=4 and Meetings M= 6, what would you >> suggest for A and M? >> >> SO: Requiring in-person attendance is my main concern, it should not be > mandatory. You may find at times that it is cheaper to travel out of Africa > than within Africa, so not everyone can afford an in-person meeting. Let > individual voters decide on candidates based on their historical > participation. > >> >> *Appointment by consensus:* >> >> - Comment (Seun): Consensus?based appointment could introduce >> subjectivity. >> - *Response:* This WG makes decisions by consensus with appeal >> mechanisms in place. Appointing co-chairs via the same mechanisms should >> not be a problem. With the requirements stated at section 3.3.3, it should >> not be difficult to reach consensus on co-chairs candidates. While this may >> not be perfect, it is used worldwide by various WGs. ?Community? votes >> rather bring more subjectivity. >> >> >> *Code of Conduct reference:* >> >> - Comment (Seun): Simply refer to AFRINIC?s CoC. >> - *Response:* By referring to ?applicable CoC? the proposal avoids >> attaching to a particular CoC. Today we are using the ?AFRINIC Community >> CoC? elaborated by the board ( https://afrinic.net/code ), this may >> change in the future. We saw some recent CoC discussions on the list. >> >> SO: Who determines which Code of Conduct (CoC) is "applicable" and which > is not? > >> >> *4. Governance Structure & Proposal Scope* >> *Necessity of the Number Council:* >> >> - Comment (Seun): The Appeal Committee could perform the same role; >> RNC may be unnecessary. >> - *Response: *The RNC?s roles encompass calling PPM and appointing >> interim co-chairs. So making the AC perform RNC?s role may not be >> appropriate. >> >> > What I am trying to communicate is that the RNC and its proposed roles are > not required. There is value in having nomcom whose membership is more > likely to change every year perform the role of getting nominations for > PDWG Co-Chair. If both Co-Chairs resign, the Board should select one of the > 3 NRO NC members to chair temporarily until a co-Chair is elected. > >> >> *Splitting the proposal into smaller documents:* >> >> - Comment (Sami): Consider withdrawing and splitting into multiple >> focused proposals. >> - *Response:* The components are interdependent; splitting them would >> create incoherent intermediate states and procedural gaps. >> >> SO: I looked at the problem enumerated below: > > > - Adopted policy proposals not ratified or not implemented > - No Public Policy Meeting - Non-renewal of co-chairs > - Non-renewal of appeal and recall committees > - Non-renewal of ASO AC/NRO NC representatives > - Frozen Resource Policy Discussion mailing list > > The problems stated in the policy as listed above (apart from the last > which has been corrected) all stemmed from the Board not having a quorum. > The idea that the volunteer PDWG should or can effectively operate when > there is no Board in the future is wishful thinking that should not be > encouraged. In fact, the PDP operation is mandated by the bylaws, and the > Board has the fiduciary responsibility to oversee the entire organisation. > It therefore seems to me that this policy attempts to address a governance > issue through policy rather than through the bylaws. Bylaws is the way to > ensure that the events that happened with the Board in the past does not > repeat itself. > >> >> *Board ratification language:* >> >> - Comment (Seun): ?Shall? implies the Board must ratify; the Board >> should be able to decline with reasons. >> - *Response:* The text as written ?If a policy proposal approved by >> the PDWG fails to be ratified by the board (inability or refusal by the >> board without reasons for 60 days), a petition for ratification can be >> initiated by a member of the PDWG.? it is meant to cover the two scenarios >> below: >> >> 1. The Board is unable to act for 60 days (No quorum, No functioning >> Board, Legal or operational paralysis, etc.) >> 2. The Board refuses to ratify without giving reasons for 60 days (the >> Board says ?no? but gives no justification, or The Board simply does >> nothing and provides no explanation.) >> Any suggestions to improve the text if it is not clear enough ? >> > > SO: I think there may be a need to review the problem statement first so > the rest of the document is better guided > > Regards > >> >> >> The authors thank the community for constructive feedback. >> >> Regards, >> >> Gr?goire >> >> >> >> On May 27, 2026, at 2:45?PM, Sami Salih wrote: >> >> Dear Colleagues, >> >> As a former PDWG Co-chair, I generally support the intent behind >> strengthening the autonomy and operational continuity of the PDWG. The >> policy development process ultimately belongs to the African Internet >> community and should remain resilient regardless of operational or >> governance challenges affecting AFRINIC as an organisation. >> >> At the same time, I believe it is important to recognize that this >> proposal introduces substantial structural, operational, procedural, and >> governance changes to the PDP framework. In many respects, this is a major >> and transformative proposal rather than a routine procedural update. >> >> From my experience with the PDP, the community process tends to work best >> when addressing clearly scoped issues through focused and >> easy-to-understand proposals. In contrast, this proposal attempts to >> address many different governance, electoral, operational, disciplinary, >> and procedural matters simultaneously, which makes it difficult for the >> community to fully analyse, discuss, and build meaningful consensus around >> all aspects at once. >> >> IMHO, many of the ideas and intended improvements presented in this >> proposal are constructive and deserve serious consideration. I also fully >> acknowledge and respect the extensive experience, effort, and strategic >> thinking of the authors in developing such a comprehensive framework >> proposal. >> >> However, considering the breadth of the changes and the number of >> distinct governance and operational matters being introduced >> simultaneously, my respectful recommendation would be to consider >> withdrawing the current proposal and restructuring this work into multiple >> smaller and more focused proposals. I believe this would make it >> significantly easier for the community to understand, analyse, discuss, and >> build meaningful consensus around each individual topic independently, >> while improving overall community engagement and participation in the >> process. >> >> With Regards, >> Sami Sali. >> >> >> Sami Salih >> ------------------------------ >> *From:* Seun Ojedeji >> *Sent:* Monday, May 25, 2026 8:43:56 PM >> *To:* dacostadarwin at gmail.com >> *Cc:* rpd at afrinic.net >> *Subject:* Re: [rpd] New Draft Policy Proposal - Amendment of the PDP >> Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. >> >> Hello, >> >> Thanks for sharing this proposal. My initial comments after a brief >> review are the following: >> >> - A typical community member could also be an AFRINIC member. There is no >> reason to mandate that nomination supporters for the NRO NC must be both >> community members and AFRINIC members. Requiring one or 2 supporters from >> the service region should be sufficient. >> >> - The rpd is open to anyone that wishes to participate irrespective of >> origin, region or residence. It sure makes sense to restrict election >> participation to those with a historical record of involvement, either >> online or in-person to avoid historical experience of DDOS on election >> day. However, there is no reason to restrict the selectorate/electorate to >> those in the region alone. >> >> - I do not see the necessity of a Number Committee; it seems to create >> yet another layer. The Appeal committee which also serves as the recall >> committee can perform any intended role of the RNC. Its composition could >> be the 3 NRO NC members from the region, a past co-chair, and a past appeal >> committee chair in a non-voting capacity. In situations where both >> Co-Chairs are no more, the Chair of the Appeal committee can temporarily >> take over until rpd appoints a new co-chair >> >> - As a former co-chair of PDWG, i find the proposed responsibilities of >> the Co-chairs as described in section 3.3.2 to be overly granular and >> quite policing-like for lack of a better word. >> >> - I believe the proposed 3.3.7 should refer to AFRINIC CoC and that >> should be sufficient. The proposed penalties for violations look good, >> though they are a bit too wordy to me and the process leading to that is >> quite descriptive. We really need to give the co-chairs the privilege of >> managing events as they deem applicable >> >> - The idea that a co-chair eligibility should be tied to attending >> in-person meetings during a specific period isn't realistic given our >> region's unique challenges. I understand it may be an effort to put a face >> to the name but restricting eligibility to the last 2 years (which is >> basically last 4 PPM) isn't realistic. >> >> - 3.3.3.3.3 suggests co-chairs will be appointed by consensus, that is an >> interesting point that i would definitely not support. This can lead to >> unnecessary subjectivity. >> >> - I like the expectation of participation from Co-Chair hence 3.3.4 >> appeals to me as written. >> >> - Use of shall in 3.3.11 suggests that ratification is the only option >> for the Board. There should be an option for the Board to provide reasons >> for not ratifying and that should not be triggered by a petition. >> >> I may have more comments in future, but that is all from me for now. >> >> Regards >> >> On Mon, 25 May 2026 at 10:20, dacostadarwin at gmail.com < >> dacostadarwin at gmail.com> wrote: >> >> Dear PDWG, >> >> We have received a new draft policy proposal - Amendment of the PDP >> Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01 >> from authors Gr?goire EHOUMI, Noah Maina and Adeola A. P. AINA. >> >> The proposal contents are published at: >> https://afrinic.net/policy/proposals/afpub-2026-gen-001-draft01 >> >> We encourage you to take some time to go through the proposal contents >> and provide feedback as follows : >> >> a) Do you support or oppose the proposal? >> >> b) If you oppose the proposal, state your reasons. >> >> c) Is there anything in the proposal that is not clear? >> >> d) What changes could be made to this proposal to make it more effective? >> >> Regards, >> Vincent Ngundi & Darwin Da Costa >> AFRINIC PDWG Co-Chairs >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> -- >> ------------------------------------------------------------------------ >> >> >> *Seun Ojedeji, * >> >> Bringing another down does not take you up - think about your action! >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> > > -- > ------------------------------------------------------------------------ > > > *Seun Ojedeji,* > > Bringing another down does not take you up - think about your action! > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gregoire.ehoumi at yahoo.fr Mon Jun 22 05:16:14 2026 From: gregoire.ehoumi at yahoo.fr (Gregoire EHOUMI) Date: Mon, 22 Jun 2026 01:16:14 -0400 Subject: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. In-Reply-To: References: <1EC212BF-EA11-4FB4-B5C4-B7429FFE6209@gmail.com> Message-ID: <040EA822-E811-4C0D-92A1-0A3D45684F8E@yahoo.fr> Hi Seun, It looks like the selection of co-chair by consensus is an established norm at AFRINIC https://afrinic.net/afrinic-elections-2026-call-for-candidates 3. Two (2) PDP Co-Chairs [consensus-based] https://election.afrinic.net/election-guideline-2026 6.3. PDP Co-Chairs Selection 6.3.2. It is also established practice that this selection is conducted through a consensus-based process, and participants are therefore expected to adhere to this established norm. Regards, Gregoire > - 3.3.3.3.3 suggests co-chairs will be appointed by consensus, that is an interesting point that i would definitely not support. This can lead to unnecessary subjectivity. > > - I like the expectation of participation from Co-Chair hence 3.3.4 appeals to me as written. > > - Use of shall in 3.3.11 suggests that ratification is the only option for the Board. There should be an option for the Board to provide reasons for not ratifying and that should not be triggered by a petition. > > I may have more comments in future, but that is all from me for now. > > Regards > > On Mon, 25 May 2026 at 10:20, dacostadarwin at gmail.com > wrote: >> Dear PDWG, >> >> We have received a new draft policy proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01 from authors Gr?goire EHOUMI, Noah Maina and Adeola A. P. AINA. >> >> The proposal contents are published at: https://afrinic.net/policy/proposals/afpub-2026-gen-001-draft01 >> >> We encourage you to take some time to go through the proposal contents and provide feedback as follows : >> >> a) Do you support or oppose the proposal? >> >> b) If you oppose the proposal, state your reasons. >> >> c) Is there anything in the proposal that is not clear? >> >> d) What changes could be made to this proposal to make it more effective? >> >> Regards, >> Vincent Ngundi & Darwin Da Costa >> AFRINIC PDWG Co-Chairs >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > > > -- > ------------------------------------------------------------------------ > Seun Ojedeji, > Bringing another down does not take you up - think about your action! > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From seun.ojedeji at gmail.com Mon Jun 22 05:46:20 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Mon, 22 Jun 2026 08:46:20 +0300 Subject: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. In-Reply-To: <040EA822-E811-4C0D-92A1-0A3D45684F8E@yahoo.fr> References: <1EC212BF-EA11-4FB4-B5C4-B7429FFE6209@gmail.com> <040EA822-E811-4C0D-92A1-0A3D45684F8E@yahoo.fr> Message-ID: Hello Gregoire, Selection is done by show of hands which is some form of voting. I am not sure why present ecom or the board chose to call the selection process consensus without further explaining the details. Here is reference to where the process was well described: https://afrinic.net/changelog?view=article&id=2764:pdwg-election-process-2021&catid=17 7. Voting Voting shall be by a simple show of hands. Regards ---- Sent from my mobile kindly excuse typos On Mon, 22 Jun 2026, 8:16?am Gregoire EHOUMI, wrote: > Hi Seun, > > It looks like the selection of co-chair by consensus is an established > norm at AFRINIC > > > https://afrinic.net/afrinic-elections-2026-call-for-candidates > > *3. Two (2) PDP Co-Chairs [consensus-based]* > > https://election.afrinic.net/election-guideline-2026 > > *6.3. PDP Co-Chairs Selection* > > *6.3.2. It is also established practice that this selection is conducted > through a consensus-based process, and participants are therefore expected > to adhere to this established norm.* > > > Regards, > > Gregoire > > > - 3.3.3.3.3 suggests co-chairs will be appointed by consensus, that is an > interesting point that i would definitely not support. This can lead to > unnecessary subjectivity. > > - I like the expectation of participation from Co-Chair hence 3.3.4 > appeals to me as written. > > - Use of shall in 3.3.11 suggests that ratification is the only option for > the Board. There should be an option for the Board to provide reasons for > not ratifying and that should not be triggered by a petition. > > I may have more comments in future, but that is all from me for now. > > Regards > > On Mon, 25 May 2026 at 10:20, dacostadarwin at gmail.com < > dacostadarwin at gmail.com> wrote: > >> Dear PDWG, >> >> We have received a new draft policy proposal - Amendment of the PDP >> Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01 >> from authors Gr?goire EHOUMI, Noah Maina and Adeola A. P. AINA. >> >> The proposal contents are published at: >> https://afrinic.net/policy/proposals/afpub-2026-gen-001-draft01 >> >> We encourage you to take some time to go through the proposal contents >> and provide feedback as follows : >> >> a) Do you support or oppose the proposal? >> >> b) If you oppose the proposal, state your reasons. >> >> c) Is there anything in the proposal that is not clear? >> >> d) What changes could be made to this proposal to make it more effective? >> >> Regards, >> Vincent Ngundi & Darwin Da Costa >> AFRINIC PDWG Co-Chairs >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > > > -- > ------------------------------------------------------------------------ > > > *Seun Ojedeji,* > > Bringing another down does not take you up - think about your action! > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dacostadarwin at gmail.com Mon Jun 22 05:58:22 2026 From: dacostadarwin at gmail.com (dacostadarwin at gmail.com) Date: Mon, 22 Jun 2026 07:58:22 +0200 Subject: [rpd] Final Agenda AFRINIC-37 Public Policy Meeting. Message-ID: <59B4859D-B883-498E-A6BC-034B419EF2EB@gmail.com> Dear PDWG The final agenda for the AFRINIC=37 Public Policy Meeting happening in hybrid mode in Nairobi, Kenya on 24 June 2026 is as follows: 09:00 ? 09:05: Overview of logistics 09:05 ? 09:10: Welcome & Agenda Overview 09:10 ? 10:00: Soft Landing, Recovered Space and Priority AFPUB-2026-IPv4-001-DRAFT02 10:00 ? 10:15: TEA BREAK 10:15 ? 11:05: PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01 11:05 ? 11:55: Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT02 11:55 ? 12:45: Require newly created AS-SETs to have hierarchical names AFPUB-2026-ASN-001-DRAFT02 12:45 ? 13:00: Update on ratified policies 13:00 ? 14:25: LUNCH BREAK 14:25 ? 15:15: IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 15:15 ? 16:05: AfriNIC Policy Compliance Dashboard AFPUB-2026-GEN-002-DRAFT01 16:05 ? 16:20: TEA BREAK 16:20 ? 16:35: Policy Implementation Experience Report 16:35 ? 16:55: Policy Update from other regions 16:55 ? 17:20: PDWG Chair selection 17:20 ? 17:35: Q&A and Open Microphone 17:35 ? 17:40: Closing of PPM 17:40 ? 17:50: ASO-AC election ? Results 17:50 ? 17:55: Closing Remarks of the Day Kind Regards Vincent Ngundi & Darwin Da Costa *AFRINIC PDWG Co-Chairs From dacostadarwin at gmail.com Mon Jun 22 08:15:28 2026 From: dacostadarwin at gmail.com (Darwin Da Costa) Date: Mon, 22 Jun 2026 10:15:28 +0200 Subject: [rpd] Pv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 . Message-ID: Dear PDWG, We have received an update to the draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT02 from author Jordi Palet Martinez on 14 June 2026. The proposal contents are published at: https://afrinic.net/participate/policy/proposals/afpub-2026-v6-001-draft02 We encourage you to take some time to go through the proposal contents and provide feedback as follows: a) Do you support or oppose the proposal? b) If you oppose the proposal, state your reasons? c) Is there anything in the proposal that is not clear? d) What changes could be made to this proposal to make it more effective? Regards, Vincent Ngundi & Darwin Da Costa AFRINIC PDWG Co-Chairs From dacostadarwin at gmail.com Mon Jun 22 08:26:59 2026 From: dacostadarwin at gmail.com (Darwin Da Costa) Date: Mon, 22 Jun 2026 10:26:59 +0200 Subject: [rpd] Soft Landing, Recovered Space and Priority AFPUB-2026-IPv4-001-DRAFT02. Message-ID: <0C0DDB39-96A1-49AE-8F91-24280BB9FC61@gmail.com> Dear PDWG, We have received an update to the draft policy proposal - Soft Landing, Recovered Space and Priority, ID AFPUB-2026-IPv4-001-DRAFT01 from author Jordi Palet Martinez on 16 June 2026. The proposal contents are published at: https://afrinic.net/participate/policy/proposals/afpub-2026-ipv4-001-draft02 We encourage you to take some time to go through the proposal contents and provide feedback as follows: a) Do you support or oppose the proposal? b) If you oppose the proposal, state your reasons? c) Is there anything in the proposal that is not clear? d) What changes could be made to this proposal to make it more effective? Regards, Vincent Ngundi & Darwin Da Costa AFRINIC PDWG Co-Chairs From dacostadarwin at gmail.com Mon Jun 22 08:27:03 2026 From: dacostadarwin at gmail.com (Darwin Da Costa) Date: Mon, 22 Jun 2026 10:27:03 +0200 Subject: [rpd] Amendment of Utilisation in Soft Landing. Message-ID: Dear PDWG, We have received an update to the draft policy proposal - Amendment of Utilisation in Soft Landing, ID AFPUB-2026-IPv4-002-DRAFT02 from author Jordi Palet Martinez, on 16 June 2026. The proposal contents are published at: https://afrinic.net/policy/proposals/afpub-2026-ipv4-002-draft02 We encourage you to take some time to go through the proposal contents and provide feedback as follows: a) Do you support or oppose the proposal? b) If you oppose the proposal, state your reasons? c) Is there anything in the proposal that is not clear? d) What changes could be made to this proposal to make it more effective? Regards, Vincent Ngundi & Darwin Da Costa AFRINIC PDWG Co-Chairs From aalain at trstech.net Mon Jun 22 17:16:33 2026 From: aalain at trstech.net (ALAIN AINA) Date: Mon, 22 Jun 2026 20:16:33 +0300 Subject: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. In-Reply-To: References: <1EC212BF-EA11-4FB4-B5C4-B7429FFE6209@gmail.com> <4D12F3EC-E524-468A-BA8A-782BA4483DA6@yahoo.fr> Message-ID: Hello PDWG, > On 20 Jun 2026, at 23:25, Seun Ojedeji wrote: > > Hello Gregoire, > > Thanks for putting those references, you will find that referenced roles and responsibility from other RIRs and our current PDP puts some trust in the chair(s) to do the needful based on expected outcome. > > IMO 3.3.2.1 e,f,g,I are currently worded in much granular manner. Take f for instance, why won't the Co-Chairs read presentation, so what happens if the Co-Chair missed reading the presentation or if they did but someone within the PDWG claim they didn't. > > The text Preceding 3.3.2.1 addresses a lot of the granularity of 3.3.2.1: > > "Organise, prepare and chair the face-to-face and on-line formal working group meetings as well as community consultation meetings." If there is consensus that the co?chairs? roles and responsibilities must be explicitly defined, the next step is to agree on the precise wording. We invite others in the community to share their perspectives and suggestions > > That said, please do not loose sight of the main concerns that I have raised already. One of them is that we need to be clear on what problem we are trying to address. The problems stated in the current proposal are not problems unique to PDWG, they are organisational problems and PDWG was rightly affected by them just like the other part of the org was affected. > > However, PDWG is not the place to address those problems. Could you elaborate on which forum, structure, or mechanism you consider appropriate for addressing these issues, given that they directly affect the continuity, functionality, and compliance of the PDP? > This proposal is attempting to use the event that occurred to the board to turn PDWG to a self governing independent authority through policy and I do not believe that is the way to go about it. This proposal is not attempting to ?turn the PDWG into a self?governing independent authority.? The PDWG already is a self?governing, community?driven authority by design. What the proposal does is address the structural weaknesses that recent events exposed; weaknesses that placed AFRINIC in breach of ICP?2 and threatened the continuity of the entire regional registry. As required by ICP?2, all RIRs must maintain a bottom?up, self?governance structure for developing local policies. This structure must be community?driven, transparent, and resilient. Each RIR therefore defines a PDP that reflects its operational realities. AFRINIC is no exception. Under AFRINIC?s governance model, the PDWG is already a self?governing body whose authority is delegated downward to AFRINIC Ltd?s Board through the Bylaws ? not the other way around. The Bylaws themselves make this clear: ? Definition of the PDP (Section 23): The PDP is approved by the Internet Community. This establishes the primacy of the community in policy development. ? Section 15.3: The Board determines allocation guidelines in line with the member?driven PDP. The PDP constrains the Board. ? Section 11.2: The Board calls a PPM as per requirements defined in the PDP. The PDP defines the conditions This model has been in place since AFRINIC?s inception. What has changed is that its risk profile was never assessed, and the events affecting the Board demonstrated how fragile the system becomes when governance failures occur. The PDP stalled, the community could not advance policy, and AFRINIC fell out of compliance with ICP?2. The new NRO Governance Document for the Recognition, Operation, and Derecognition of RIRs, currently under discussion, introduces stricter continuity obligations. These obligations will require AFRINIC to demonstrate that its PDP and the structures supporting it can continue to function even when AFRINIC Ltd faces governance paralysis. For this reason, the community must review the PDP, identify the necessary amendments, and agree on the evolution required to ensure continuity. Where appropriate, these changes will trigger corresponding updates to the AFRINIC Ltd Bylaws and internal operational procedures. This proposal is one such attempt. A community?driven effort to strengthen the PDP, ensure compliance with ICP?2, and prevent a repeat of the governance failures that affected AFRINIC and the region. Hope this helps ?Alain > > Nevertheless, there is merit in clarifying roles of Co-Chairs and some of the 3.3.2 texts addresses that, hence that then can become the problem statement and sections that does not relate to roles and responsibilities can be commented out. > > Regards > > ---- > Sent from my mobile > kindly excuse typos > > > > On Fri, 19 Jun 2026, 6:22?pm Gregoire EHOUMI, wrote: > Hello Seun, > > Please see the references below. Most importantly, what do you think should not be listed under the co-chairs' roles and responsibilities in the proposal? > https://www.apnic.net/community/participate/sigs/sig-guidelines/ > Chair and co-chairs roles - section 2.3 > https://www.lacnic.net/679/2/lacnic/policy-development-process > PDP chairs section 3.2 > https://www.ripe.net/publications/docs/ripe-861/ > > RIPE Working Group Chair Job Description and Procedures ? RIPE Network Coordination Centre > > Best regards, > > Gregoire > > >> On Jun 9, 2026, at 9:09?PM, Seun Ojedeji wrote: >> >> Hello Gregoire, >> >> Please find the details inline: >> >> On Tue, 9 Jun 2026 at 14:27, Gregoire EHOUMI wrote: >> Dear PDWG, >> >> This digest summarises the key points raised by community members (Ben, Seun, and Sami) regarding this policy proposal, along with the authors? clarifications and responses. >> It is organised into four themes for easier reading. >> >> 1. Corrections & Clarifications >> Mailing list freeze clarification: >> ? >> Comment (Ben): The RPD list was not frozen; only community?discuss was moderated. >> ? Response: Acknowledged. The text will be corrected in Draft?2. It was meant to say ? Inactive Resource Policy Discussion mailing list? >> >> >> 2. Participation, Representation & Elections >> Nomination support requirements: >> ? >> Comment (Seun): No need for supporters to be both AFRINIC members and community members. >> ? Response: The intent is to ensure support from at least one contact of the membership. Participants in the PDP and the WG activities are generally classified in 2 categories: ?Registered contact of AFRINIC member? and ? Non-registered contact of AFRINIC member? >> >> SO: Current participants of RPD do not need to be a ?Registered contact of AFRINIC member? OR ? Non-registered contact of AFRINIC member?, the PDWG is and should be open to any person interested in number policy development including non AFRINIC members. Note that there is a subtle difference between non-registered contact of AFRINIC member and a non-AFRINIC member. It should be okay to require support from either an AFRINIC member OR a community member, but the current text mandates both.To illustrate a nomination supported by 2 community members should pass just as a nomination supported by 2 afrinic member, likewise 1 afrinic member and 1 community member. >> >> Who can vote in NRO NC elections: >> ? >> Comment (Seun): No reason to restrict voting to people in the region. >> ? Response: This follows existing AFRINIC rules. For NRO NC, only participants from the region(excluding staff) vote. >> >> >> SO: My rationale is based on the premise that the rpd is open to all; hence, PDWG co-chair voters should not be restricted to in-region. By extension, NRO NC voters should be similar. Nevertheless considering past experiences, I agree there is merit in restricting voting to in-region but that discriminates on participation as voting is a form of participation as well. >> >> 3. Co?Chair Roles, Eligibility & Processes >> Level of detail in co?chair responsibilities: >> ? >> Comment (Seun): Responsibilities in section 3.3.2 feel too granular and policing. >> ? Response: The detail is intentional, based on RFC?2418 and other RIRs practices, to avoid ambiguity. The WG should be predictable. >> >> >> SO: I do not know of an RIR process that is as granular in the responsibility of co-chairs as stated in 3.3.2. Section 6.1 of RFC 2418 that describes the role of a working group chair isn't as granular either. >> >> Eligibility criteria ? meeting attendance: >> ? >> Comment (Seun): Requiring attendance at 4 of the last 6 PPMs (including one in?person) may be unrealistic. >> ? Response: at the old rhythm of 2 PPMs a year, this requirement means attending 4 of the 6 meetings held the last 3 years with at least one in-person. With Attendance A=4 and Meetings M= 6, what would you suggest for A and M? >> >> SO: Requiring in-person attendance is my main concern, it should not be mandatory. You may find at times that it is cheaper to travel out of Africa than within Africa, so not everyone can afford an in-person meeting. Let individual voters decide on candidates based on their historical participation. >> >> Appointment by consensus: >> ? >> Comment (Seun): Consensus?based appointment could introduce subjectivity. >> ? Response: This WG makes decisions by consensus with appeal mechanisms in place. Appointing co-chairs via the same mechanisms should not be a problem. With the requirements stated at section 3.3.3, it should not be difficult to reach consensus on co-chairs candidates. While this may not be perfect, it is used worldwide by various WGs. ?Community? votes rather bring more subjectivity. >> >> >> Code of Conduct reference: >> ? >> Comment (Seun): Simply refer to AFRINIC?s CoC. >> ? Response: By referring to ?applicable CoC? the proposal avoids attaching to a particular CoC. Today we are using the ?AFRINIC Community CoC? elaborated by the board ( https://afrinic.net/code ), this may change in the future. We saw some recent CoC discussions on the list. >> >> SO: Who determines which Code of Conduct (CoC) is "applicable" and which is not? >> >> 4. Governance Structure & Proposal Scope >> Necessity of the Number Council: >> ? >> Comment (Seun): The Appeal Committee could perform the same role; RNC may be unnecessary. >> ? Response: The RNC?s roles encompass calling PPM and appointing interim co-chairs. So making the AC perform RNC?s role may not be appropriate. >> >> >> What I am trying to communicate is that the RNC and its proposed roles are not required. There is value in having nomcom whose membership is more likely to change every year perform the role of getting nominations for PDWG Co-Chair. If both Co-Chairs resign, the Board should select one of the 3 NRO NC members to chair temporarily until a co-Chair is elected. >> >> Splitting the proposal into smaller documents: >> ? >> Comment (Sami): Consider withdrawing and splitting into multiple focused proposals. >> ? Response: The components are interdependent; splitting them would create incoherent intermediate states and procedural gaps. >> >> SO: I looked at the problem enumerated below: >> >> ? Adopted policy proposals not ratified or not implemented >> ? No Public Policy Meeting - Non-renewal of co-chairs >> ? Non-renewal of appeal and recall committees >> ? Non-renewal of ASO AC/NRO NC representatives >> ? Frozen Resource Policy Discussion mailing list >> The problems stated in the policy as listed above (apart from the last which has been corrected) all stemmed from the Board not having a quorum. The idea that the volunteer PDWG should or can effectively operate when there is no Board in the future is wishful thinking that should not be encouraged. In fact, the PDP operation is mandated by the bylaws, and the Board has the fiduciary responsibility to oversee the entire organisation. It therefore seems to me that this policy attempts to address a governance issue through policy rather than through the bylaws. Bylaws is the way to ensure that the events that happened with the Board in the past does not repeat itself. >> >> Board ratification language: >> ? >> Comment (Seun): ?Shall? implies the Board must ratify; the Board should be able to decline with reasons. >> ? Response: The text as written ?If a policy proposal approved by the PDWG fails to be ratified by the board (inability or refusal by the board without reasons for 60 days), a petition for ratification can be initiated by a member of the PDWG.? it is meant to cover the two scenarios below: >> >> 1. The Board is unable to act for 60 days (No quorum, No functioning Board, Legal or operational paralysis, etc.) >> 2. The Board refuses to ratify without giving reasons for 60 days (the Board says ?no? but gives no justification, or The Board simply does nothing and provides no explanation.) >> Any suggestions to improve the text if it is not clear enough ? >> >> SO: I think there may be a need to review the problem statement first so the rest of the document is better guided >> >> Regards >> >> >> The authors thank the community for constructive feedback. >> >> Regards, >> >> Gr?goire >> >> >> >>> On May 27, 2026, at 2:45?PM, Sami Salih wrote: >>> >>> Dear Colleagues, >>> As a former PDWG Co-chair, I generally support the intent behind strengthening the autonomy and operational continuity of the PDWG. The policy development process ultimately belongs to the African Internet community and should remain resilient regardless of operational or governance challenges affecting AFRINIC as an organisation. >>> At the same time, I believe it is important to recognize that this proposal introduces substantial structural, operational, procedural, and governance changes to the PDP framework. In many respects, this is a major and transformative proposal rather than a routine procedural update. >>> From my experience with the PDP, the community process tends to work best when addressing clearly scoped issues through focused and easy-to-understand proposals. In contrast, this proposal attempts to address many different governance, electoral, operational, disciplinary, and procedural matters simultaneously, which makes it difficult for the community to fully analyse, discuss, and build meaningful consensus around all aspects at once. >>> IMHO, many of the ideas and intended improvements presented in this proposal are constructive and deserve serious consideration. I also fully acknowledge and respect the extensive experience, effort, and strategic thinking of the authors in developing such a comprehensive framework proposal. >>> However, considering the breadth of the changes and the number of distinct governance and operational matters being introduced simultaneously, my respectful recommendation would be to consider withdrawing the current proposal and restructuring this work into multiple smaller and more focused proposals. I believe this would make it significantly easier for the community to understand, analyse, discuss, and build meaningful consensus around each individual topic independently, while improving overall community engagement and participation in the process. >>> With Regards, >>> Sami Sali. >>> >>> >>> Sami Salih >>> From: Seun Ojedeji >>> Sent: Monday, May 25, 2026 8:43:56 PM >>> To: dacostadarwin at gmail.com >>> Cc: rpd at afrinic.net >>> Subject: Re: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. Hello, >>> >>> Thanks for sharing this proposal. My initial comments after a brief review are the following: >>> >>> - A typical community member could also be an AFRINIC member. There is no reason to mandate that nomination supporters for the NRO NC must be both community members and AFRINIC members. Requiring one or 2 supporters from the service region should be sufficient. >>> >>> - The rpd is open to anyone that wishes to participate irrespective of origin, region or residence. It sure makes sense to restrict election participation to those with a historical record of involvement, either online or in-person to avoid historical experience of DDOS on election day. However, there is no reason to restrict the selectorate/electorate to those in the region alone. >>> >>> - I do not see the necessity of a Number Committee; it seems to create yet another layer. The Appeal committee which also serves as the recall committee can perform any intended role of the RNC. Its composition could be the 3 NRO NC members from the region, a past co-chair, and a past appeal committee chair in a non-voting capacity. In situations where both Co-Chairs are no more, the Chair of the Appeal committee can temporarily take over until rpd appoints a new co-chair >>> >>> - As a former co-chair of PDWG, i find the proposed responsibilities of the Co-chairs as described in section 3.3.2 to be overly granular and quite policing-like for lack of a better word. >>> >>> - I believe the proposed 3.3.7 should refer to AFRINIC CoC and that should be sufficient. The proposed penalties for violations look good, though they are a bit too wordy to me and the process leading to that is quite descriptive. We really need to give the co-chairs the privilege of managing events as they deem applicable >>> >>> - The idea that a co-chair eligibility should be tied to attending in-person meetings during a specific period isn't realistic given our region's unique challenges. I understand it may be an effort to put a face to the name but restricting eligibility to the last 2 years (which is basically last 4 PPM) isn't realistic. >>> >>> - 3.3.3.3.3 suggests co-chairs will be appointed by consensus, that is an interesting point that i would definitely not support. This can lead to unnecessary subjectivity. >>> >>> - I like the expectation of participation from Co-Chair hence 3.3.4 appeals to me as written. >>> >>> - Use of shall in 3.3.11 suggests that ratification is the only option for the Board. There should be an option for the Board to provide reasons for not ratifying and that should not be triggered by a petition. >>> >>> I may have more comments in future, but that is all from me for now. >>> >>> Regards >>> >>> On Mon, 25 May 2026 at 10:20, dacostadarwin at gmail.com wrote: >>> Dear PDWG, >>> >>> We have received a new draft policy proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01 from authors Gr?goire EHOUMI, Noah Maina and Adeola A. P. AINA. >>> >>> The proposal contents are published at: https://afrinic.net/policy/proposals/afpub-2026-gen-001-draft01 >>> >>> We encourage you to take some time to go through the proposal contents and provide feedback as follows : >>> >>> a) Do you support or oppose the proposal? >>> >>> b) If you oppose the proposal, state your reasons. >>> >>> c) Is there anything in the proposal that is not clear? >>> >>> d) What changes could be made to this proposal to make it more effective? >>> >>> Regards, >>> Vincent Ngundi & Darwin Da Costa >>> AFRINIC PDWG Co-Chairs >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> >>> -- >>> ------------------------------------------------------------------------ >>> Seun Ojedeji, >>> Bringing another down does not take you up - think about your action! >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> -- >> ------------------------------------------------------------------------ >> Seun Ojedeji, >> Bringing another down does not take you up - think about your action! >> > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From seun.ojedeji at gmail.com Mon Jun 22 19:48:35 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Mon, 22 Jun 2026 22:48:35 +0300 Subject: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. In-Reply-To: References: <1EC212BF-EA11-4FB4-B5C4-B7429FFE6209@gmail.com> <4D12F3EC-E524-468A-BA8A-782BA4483DA6@yahoo.fr> Message-ID: Hello PDWG, ---- Sent from my mobile kindly excuse typos On Mon, 22 Jun 2026, 8:21?pm ALAIN AINA via RPD, wrote: > Hello PDWG, > > > On 20 Jun 2026, at 23:25, Seun Ojedeji wrote: > > > > Hello Gregoire, > > > > Thanks for putting those references, you will find that referenced roles > and responsibility from other RIRs and our current PDP puts some trust in > the chair(s) to do the needful based on expected outcome. > > > > IMO 3.3.2.1 e,f,g,I are currently worded in much granular manner. Take f > for instance, why won't the Co-Chairs read presentation, so what happens if > the Co-Chair missed reading the presentation or if they did but someone > within the PDWG claim they didn't. > > > > The text Preceding 3.3.2.1 addresses a lot of the granularity of 3.3.2.1 > : > > > > "Organise, prepare and chair the face-to-face and on-line formal working > group meetings as well as community consultation meetings." > > If there is consensus that the co?chairs? roles and responsibilities must > be explicitly defined, the next step is to agree on the precise wording. We > invite others in the community to share their perspectives and suggestions > > > > That said, please do not loose sight of the main concerns that I have > raised already. One of them is that we need to be clear on what problem we > are trying to address. The problems stated in the current proposal are not > problems unique to PDWG, they are organisational problems and PDWG was > rightly affected by them just like the other part of the org was affected. > > > > However, PDWG is not the place to address those problems. > > Could you elaborate on which forum, structure, or mechanism you consider > appropriate for addressing these issues, given that they directly affect > the continuity, functionality, and compliance of the PDP? > SO: The issue is governance matter, it affected PDWG directly just as it affected Govcom, Nomcom, AFRINIC Org, etc it even affected the CEO. I have stated before that I believe the bylaws is the place to address the issue at high level and there is an existing bylaws review ongoing to address those bylaws related changes that ensures that when the board losses quorum then there is a mechanism that ensures not just PDWG but every other aspect of the organisation continue to operate. > > This proposal is attempting to use the event that occurred to the board > to turn PDWG to a self governing independent authority through policy and I > do not believe that is the way to go about it. > > This proposal is not attempting to ?turn the PDWG into a self?governing > independent authority.? The PDWG already is a self?governing, > community?driven authority by design. What the proposal does is address the > structural weaknesses that recent events exposed; weaknesses that placed > AFRINIC in breach of ICP?2 and threatened the continuity of the entire > regional registry. > SO: Once again I believe that Bylaw is the place to address those weakness as the event that occur didn't just affect PDWG alone. Roles and responsibilities of the Co-Chairs is a different thing which is within scope of PDWG. > As required by ICP?2, all RIRs must maintain a bottom?up, self?governance > structure for developing local policies. This structure must be > community?driven, transparent, and resilient. Each RIR therefore defines a > PDP that reflects its operational realities. AFRINIC is no exception. > > Under AFRINIC?s governance model, the PDWG is already a self?governing > body whose authority is delegated downward to AFRINIC Ltd?s Board through > the Bylaws ? not the other way around. The Bylaws themselves make this > clear: > ? Definition of the PDP (Section 23): The PDP is approved by the > Internet Community. This establishes the primacy of the community in policy > development. > ? Section 15.3: The Board determines allocation guidelines in line > with the member?driven PDP. The PDP constrains the Board. > ? Section 11.2: The Board calls a PPM as per requirements defined in > the PDP. The PDP defines the conditions > > This model has been in place since AFRINIC?s inception. What has changed > is that its risk profile was never assessed, and the events affecting the > Board demonstrated how fragile the system becomes when governance failures > occur. The PDP stalled, the community could not advance policy, and AFRINIC > fell out of compliance with ICP?2. > SO: Well the PDP didn't do that, the bylaw did. Respectfully, I do not agree that PDP is what should restrict the board in this context, it is rather members who restrict the board as defined in the bylaws. I also do not agree that having a PDWG that is self sustaining while the Board is not quorate will fulfill ICP-2 either because that directly signals governance failure according to ICP 2 > The new NRO Governance Document for the Recognition, Operation, and > Derecognition of RIRs, currently under discussion, introduces stricter > continuity obligations. These obligations will require AFRINIC to > demonstrate that its PDP and the structures supporting it can continue to > function even when AFRINIC Ltd faces governance paralysis. > And where is the best place to ensure that if not in the bylaws? I do not agree that "fixing" PDP alone would fulfill requirements of the new NRO Governance document if other structures including the Board is broken. article 4.1 of the Governance document clearly states the expectation of each structure and places significant expectations on the governing body. 4.1g clearly states the expectations for PDP and continuation without the board is not one of them. Section 4.1h further states policy compliance expectations and who will ensure that if not the governing body as represented by the Board. > For this reason, the community must review the PDP, identify the necessary > amendments, and agree on the evolution required to ensure continuity. Where > appropriate, these changes will trigger corresponding updates to the > AFRINIC Ltd Bylaws and internal operational procedures. > > This proposal is one such attempt. A community?driven effort to strengthen > the PDP, ensure compliance with ICP?2, and prevent a repeat of the > governance failures that affected AFRINIC and the region. > SO: I appreciate the intent but I do not agree that PDP is the mechanism to effect this. I have no problem with the review of roles and responsibilities of Co-Chairs. The PDWG is a consensus gathering mechanism it should not become a legal ratification vehicle at the same time. That role should remain with the board and we have to agree that if the board have problem then the entire organisation has problem. Infact the board will not be fulfilling 4.1f of the governing document. In summary If the PDWG could somehow bypass the Board entirely to implement policy(as suggested by the proposal), or if the lack of a functioning Board stalls the process indefinitely, it triggers multiple compliance failures under ICP-2. So why not avoid lack of a functioning board so that PDWG and other structures within AFRINIC can continue to function. Then we test 4.1g against our current PDP and addresses any lapses found which to me are not much > Hope this helps > Thanks ? > > ?Alain > > > > > > Nevertheless, there is merit in clarifying roles of Co-Chairs and some > of the 3.3.2 texts addresses that, hence that then can become the problem > statement and sections that does not relate to roles and responsibilities > can be commented out. > > > > > Regards > > > > ---- > > Sent from my mobile > > kindly excuse typos > > > > > > > > On Fri, 19 Jun 2026, 6:22?pm Gregoire EHOUMI, > wrote: > > Hello Seun, > > > > Please see the references below. Most importantly, what do you think > should not be listed under the co-chairs' roles and responsibilities in the > proposal? > > https://www.apnic.net/community/participate/sigs/sig-guidelines/ > > Chair and co-chairs roles - section 2.3 > > https://www.lacnic.net/679/2/lacnic/policy-development-process > > PDP chairs section 3.2 > > https://www.ripe.net/publications/docs/ripe-861/ > > > > RIPE Working Group Chair Job Description and Procedures ? RIPE Network > Coordination Centre > > > > Best regards, > > > > Gregoire > > > > > >> On Jun 9, 2026, at 9:09?PM, Seun Ojedeji > wrote: > >> > >> Hello Gregoire, > >> > >> Please find the details inline: > >> > >> On Tue, 9 Jun 2026 at 14:27, Gregoire EHOUMI > wrote: > >> Dear PDWG, > >> > >> This digest summarises the key points raised by community members (Ben, > Seun, and Sami) regarding this policy proposal, along with the authors? > clarifications and responses. > >> It is organised into four themes for easier reading. > >> > >> 1. Corrections & Clarifications > >> Mailing list freeze clarification: > >> ? > >> Comment (Ben): The RPD list was not frozen; only community?discuss was > moderated. > >> ? Response: Acknowledged. The text will be corrected in Draft?2. It > was meant to say ? Inactive Resource Policy Discussion mailing list? > >> > >> > >> 2. Participation, Representation & Elections > >> Nomination support requirements: > >> ? > >> Comment (Seun): No need for supporters to be both AFRINIC members and > community members. > >> ? Response: The intent is to ensure support from at least one > contact of the membership. Participants in the PDP and the WG activities > are generally classified in 2 categories: ?Registered contact of AFRINIC > member? and ? Non-registered contact of AFRINIC member? > >> > >> SO: Current participants of RPD do not need to be a ?Registered contact > of AFRINIC member? OR ? Non-registered contact of AFRINIC member?, the > PDWG is and should be open to any person interested in number policy > development including non AFRINIC members. Note that there is a subtle > difference between non-registered contact of AFRINIC member and a > non-AFRINIC member. It should be okay to require support from either an > AFRINIC member OR a community member, but the current text mandates both.To > illustrate a nomination supported by 2 community members should pass just > as a nomination supported by 2 afrinic member, likewise 1 afrinic member > and 1 community member. > >> > >> Who can vote in NRO NC elections: > >> ? > >> Comment (Seun): No reason to restrict voting to people in the region. > >> ? Response: This follows existing AFRINIC rules. For NRO NC, only > participants from the region(excluding staff) vote. > >> > >> > >> SO: My rationale is based on the premise that the rpd is open to all; > hence, PDWG co-chair voters should not be restricted to in-region. By > extension, NRO NC voters should be similar. Nevertheless considering past > experiences, I agree there is merit in restricting voting to in-region but > that discriminates on participation as voting is a form of participation as > well. > >> > >> 3. Co?Chair Roles, Eligibility & Processes > >> Level of detail in co?chair responsibilities: > >> ? > >> Comment (Seun): Responsibilities in section 3.3.2 feel too granular and > policing. > >> ? Response: The detail is intentional, based on RFC?2418 and other > RIRs practices, to avoid ambiguity. The WG should be predictable. > >> > >> > >> SO: I do not know of an RIR process that is as granular in the > responsibility of co-chairs as stated in 3.3.2. Section 6.1 of RFC 2418 > that describes the role of a working group chair isn't as granular either. > >> > >> Eligibility criteria ? meeting attendance: > >> ? > >> Comment (Seun): Requiring attendance at 4 of the last 6 PPMs (including > one in?person) may be unrealistic. > >> ? Response: at the old rhythm of 2 PPMs a year, this requirement > means attending 4 of the 6 meetings held the last 3 years with at least > one in-person. With Attendance A=4 and Meetings M= 6, what would you > suggest for A and M? > >> > >> SO: Requiring in-person attendance is my main concern, it should not be > mandatory. You may find at times that it is cheaper to travel out of Africa > than within Africa, so not everyone can afford an in-person meeting. Let > individual voters decide on candidates based on their historical > participation. > >> > >> Appointment by consensus: > >> ? > >> Comment (Seun): Consensus?based appointment could introduce > subjectivity. > >> ? Response: This WG makes decisions by consensus with appeal > mechanisms in place. Appointing co-chairs via the same mechanisms should > not be a problem. With the requirements stated at section 3.3.3, it should > not be difficult to reach consensus on co-chairs candidates. While this may > not be perfect, it is used worldwide by various WGs. ?Community? votes > rather bring more subjectivity. > >> > >> > >> Code of Conduct reference: > >> ? > >> Comment (Seun): Simply refer to AFRINIC?s CoC. > >> ? Response: By referring to ?applicable CoC? the proposal avoids > attaching to a particular CoC. Today we are using the ?AFRINIC Community > CoC? elaborated by the board ( https://afrinic.net/code ), this may > change in the future. We saw some recent CoC discussions on the list. > >> > >> SO: Who determines which Code of Conduct (CoC) is "applicable" and > which is not? > >> > >> 4. Governance Structure & Proposal Scope > >> Necessity of the Number Council: > >> ? > >> Comment (Seun): The Appeal Committee could perform the same role; RNC > may be unnecessary. > >> ? Response: The RNC?s roles encompass calling PPM and appointing > interim co-chairs. So making the AC perform RNC?s role may not be > appropriate. > >> > >> > >> What I am trying to communicate is that the RNC and its proposed roles > are not required. There is value in having nomcom whose membership is more > likely to change every year perform the role of getting nominations for > PDWG Co-Chair. If both Co-Chairs resign, the Board should select one of the > 3 NRO NC members to chair temporarily until a co-Chair is elected. > >> > >> Splitting the proposal into smaller documents: > >> ? > >> Comment (Sami): Consider withdrawing and splitting into multiple > focused proposals. > >> ? Response: The components are interdependent; splitting them would > create incoherent intermediate states and procedural gaps. > >> > >> SO: I looked at the problem enumerated below: > >> > >> ? Adopted policy proposals not ratified or not implemented > >> ? No Public Policy Meeting - Non-renewal of co-chairs > >> ? Non-renewal of appeal and recall committees > >> ? Non-renewal of ASO AC/NRO NC representatives > >> ? Frozen Resource Policy Discussion mailing list > >> The problems stated in the policy as listed above (apart from the last > which has been corrected) all stemmed from the Board not having a quorum. > The idea that the volunteer PDWG should or can effectively operate when > there is no Board in the future is wishful thinking that should not be > encouraged. In fact, the PDP operation is mandated by the bylaws, and the > Board has the fiduciary responsibility to oversee the entire organisation. > It therefore seems to me that this policy attempts to address a governance > issue through policy rather than through the bylaws. Bylaws is the way to > ensure that the events that happened with the Board in the past does not > repeat itself. > >> > >> Board ratification language: > >> ? > >> Comment (Seun): ?Shall? implies the Board must ratify; the Board should > be able to decline with reasons. > >> ? Response: The text as written ?If a policy proposal approved by > the PDWG fails to be ratified by the board (inability or refusal by the > board without reasons for 60 days), a petition for ratification can be > initiated by a member of the PDWG.? it is meant to cover the two scenarios > below: > >> > >> 1. The Board is unable to act for 60 days (No quorum, No functioning > Board, Legal or operational paralysis, etc.) > >> 2. The Board refuses to ratify without giving reasons for 60 days (the > Board says ?no? but gives no justification, or The Board simply does > nothing and provides no explanation.) > >> Any suggestions to improve the text if it is not clear enough ? > >> > >> SO: I think there may be a need to review the problem statement first > so the rest of the document is better guided > >> > >> Regards > >> > >> > >> The authors thank the community for constructive feedback. > >> > >> Regards, > >> > >> Gr?goire > >> > >> > >> > >>> On May 27, 2026, at 2:45?PM, Sami Salih > wrote: > >>> > >>> Dear Colleagues, > >>> As a former PDWG Co-chair, I generally support the intent behind > strengthening the autonomy and operational continuity of the PDWG. The > policy development process ultimately belongs to the African Internet > community and should remain resilient regardless of operational or > governance challenges affecting AFRINIC as an organisation. > >>> At the same time, I believe it is important to recognize that this > proposal introduces substantial structural, operational, procedural, and > governance changes to the PDP framework. In many respects, this is a major > and transformative proposal rather than a routine procedural update. > >>> From my experience with the PDP, the community process tends to work > best when addressing clearly scoped issues through focused and > easy-to-understand proposals. In contrast, this proposal attempts to > address many different governance, electoral, operational, disciplinary, > and procedural matters simultaneously, which makes it difficult for the > community to fully analyse, discuss, and build meaningful consensus around > all aspects at once. > >>> IMHO, many of the ideas and intended improvements presented in this > proposal are constructive and deserve serious consideration. I also fully > acknowledge and respect the extensive experience, effort, and strategic > thinking of the authors in developing such a comprehensive framework > proposal. > >>> However, considering the breadth of the changes and the number of > distinct governance and operational matters being introduced > simultaneously, my respectful recommendation would be to consider > withdrawing the current proposal and restructuring this work into multiple > smaller and more focused proposals. I believe this would make it > significantly easier for the community to understand, analyse, discuss, and > build meaningful consensus around each individual topic independently, > while improving overall community engagement and participation in the > process. > >>> With Regards, > >>> Sami Sali. > >>> > >>> > >>> Sami Salih > >>> From: Seun Ojedeji > >>> Sent: Monday, May 25, 2026 8:43:56 PM > >>> To: dacostadarwin at gmail.com > >>> Cc: rpd at afrinic.net > >>> Subject: Re: [rpd] New Draft Policy Proposal - Amendment of the PDP > Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. > Hello, > >>> > >>> Thanks for sharing this proposal. My initial comments after a brief > review are the following: > >>> > >>> - A typical community member could also be an AFRINIC member. There is > no reason to mandate that nomination supporters for the NRO NC must be both > community members and AFRINIC members. Requiring one or 2 supporters from > the service region should be sufficient. > >>> > >>> - The rpd is open to anyone that wishes to participate irrespective of > origin, region or residence. It sure makes sense to restrict election > participation to those with a historical record of involvement, either > online or in-person to avoid historical experience of DDOS on election > day. However, there is no reason to restrict the selectorate/electorate to > those in the region alone. > >>> > >>> - I do not see the necessity of a Number Committee; it seems to create > yet another layer. The Appeal committee which also serves as the recall > committee can perform any intended role of the RNC. Its composition could > be the 3 NRO NC members from the region, a past co-chair, and a past appeal > committee chair in a non-voting capacity. In situations where both > Co-Chairs are no more, the Chair of the Appeal committee can temporarily > take over until rpd appoints a new co-chair > >>> > >>> - As a former co-chair of PDWG, i find the proposed responsibilities > of the Co-chairs as described in section 3.3.2 to be overly granular and > quite policing-like for lack of a better word. > >>> > >>> - I believe the proposed 3.3.7 should refer to AFRINIC CoC and that > should be sufficient. The proposed penalties for violations look good, > though they are a bit too wordy to me and the process leading to that is > quite descriptive. We really need to give the co-chairs the privilege of > managing events as they deem applicable > >>> > >>> - The idea that a co-chair eligibility should be tied to attending > in-person meetings during a specific period isn't realistic given our > region's unique challenges. I understand it may be an effort to put a face > to the name but restricting eligibility to the last 2 years (which is > basically last 4 PPM) isn't realistic. > >>> > >>> - 3.3.3.3.3 suggests co-chairs will be appointed by consensus, that is > an interesting point that i would definitely not support. This can lead to > unnecessary subjectivity. > >>> > >>> - I like the expectation of participation from Co-Chair hence 3.3.4 > appeals to me as written. > >>> > >>> - Use of shall in 3.3.11 suggests that ratification is the only option > for the Board. There should be an option for the Board to provide reasons > for not ratifying and that should not be triggered by a petition. > >>> > >>> I may have more comments in future, but that is all from me for now. > >>> > >>> Regards > >>> > >>> On Mon, 25 May 2026 at 10:20, dacostadarwin at gmail.com < > dacostadarwin at gmail.com> wrote: > >>> Dear PDWG, > >>> > >>> We have received a new draft policy proposal - Amendment of the PDP > Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01 > from authors Gr?goire EHOUMI, Noah Maina and Adeola A. P. AINA. > >>> > >>> The proposal contents are published at: > https://afrinic.net/policy/proposals/afpub-2026-gen-001-draft01 > >>> > >>> We encourage you to take some time to go through the proposal contents > and provide feedback as follows : > >>> > >>> a) Do you support or oppose the proposal? > >>> > >>> b) If you oppose the proposal, state your reasons. > >>> > >>> c) Is there anything in the proposal that is not clear? > >>> > >>> d) What changes could be made to this proposal to make it more > effective? > >>> > >>> Regards, > >>> Vincent Ngundi & Darwin Da Costa > >>> AFRINIC PDWG Co-Chairs > >>> _______________________________________________ > >>> RPD mailing list > >>> RPD at afrinic.net > >>> https://lists.afrinic.net/mailman/listinfo/rpd > >>> > >>> > >>> -- > >>> > ------------------------------------------------------------------------ > >>> Seun Ojedeji, > >>> Bringing another down does not take you up - think about your action! > >>> > >>> _______________________________________________ > >>> RPD mailing list > >>> RPD at afrinic.net > >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> > >> > >> > >> -- > >> ------------------------------------------------------------------------ > >> Seun Ojedeji, > >> Bringing another down does not take you up - think about your action! > >> > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From honlue at gmail.com Mon Jun 22 21:50:19 2026 From: honlue at gmail.com (Musa Stephen Honlue) Date: Mon, 22 Jun 2026 23:50:19 +0200 Subject: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. In-Reply-To: References: <1EC212BF-EA11-4FB4-B5C4-B7429FFE6209@gmail.com> <4D12F3EC-E524-468A-BA8A-782BA4483DA6@yahoo.fr> Message-ID: > On 22 Jun 2026, at 21:48, Seun Ojedeji wrote: > > Hello PDWG, > > ---- > Sent from my mobile > kindly excuse typos > > On Mon, 22 Jun 2026, 8:21?pm ALAIN AINA via RPD, > wrote: >> Hello PDWG, >> >> > On 20 Jun 2026, at 23:25, Seun Ojedeji > wrote: >> > >> > Hello Gregoire, >> > >> > Thanks for putting those references, you will find that referenced roles and responsibility from other RIRs and our current PDP puts some trust in the chair(s) to do the needful based on expected outcome. >> > >> > IMO 3.3.2.1 e,f,g,I are currently worded in much granular manner. Take f for instance, why won't the Co-Chairs read presentation, so what happens if the Co-Chair missed reading the presentation or if they did but someone within the PDWG claim they didn't. >> > >> > The text Preceding 3.3.2.1 addresses a lot of the granularity of 3.3.2.1 : >> > >> > "Organise, prepare and chair the face-to-face and on-line formal working group meetings as well as community consultation meetings." >> >> If there is consensus that the co?chairs? roles and responsibilities must be explicitly defined, the next step is to agree on the precise wording. We invite others in the community to share their perspectives and suggestions >> > >> > That said, please do not loose sight of the main concerns that I have raised already. One of them is that we need to be clear on what problem we are trying to address. The problems stated in the current proposal are not problems unique to PDWG, they are organisational problems and PDWG was rightly affected by them just like the other part of the org was affected. >> > >> > However, PDWG is not the place to address those problems. >> >> Could you elaborate on which forum, structure, or mechanism you consider appropriate for addressing these issues, given that they directly affect the continuity, functionality, and compliance of the PDP? > > > SO: The issue is governance matter, it affected PDWG directly just as it affected Govcom, Nomcom, AFRINIC Org, etc it even affected the CEO. > > I have stated before that I believe the bylaws is the place to address the issue at high level and there is an existing bylaws review ongoing to address those bylaws related changes that ensures that when the board losses quorum then there is a mechanism that ensures not just PDWG but every other aspect of the organisation continue to operate. As it stands, the bylaw has not resolved this issue and we are not sure we will have a resolution soon. Therefore it?s very prudent to think of a solution to protect this working group from such undesirable consequences. I support the idea of finding the solution within the PDP which in principle is suppose to function independently of other bodies of AFRINIC. This doesn?t stop the organisation to find a global solution with the bylaws. > >> >> > This proposal is attempting to use the event that occurred to the board to turn PDWG to a self governing independent authority through policy and I do not believe that is the way to go about it. >> >> This proposal is not attempting to ?turn the PDWG into a self?governing independent authority.? The PDWG already is a self?governing, community?driven authority by design. What the proposal does is address the structural weaknesses that recent events exposed; weaknesses that placed AFRINIC in breach of ICP?2 and threatened the continuity of the entire regional registry. > > > SO: Once again I believe that Bylaw is the place to address those weakness as the event that occur didn't just affect PDWG alone. Roles and responsibilities of the Co-Chairs is a different thing which is within scope of PDWG. > >> >> As required by ICP?2, all RIRs must maintain a bottom?up, self?governance structure for developing local policies. This structure must be community?driven, transparent, and resilient. Each RIR therefore defines a PDP that reflects its operational realities. AFRINIC is no exception. >> >> Under AFRINIC?s governance model, the PDWG is already a self?governing body whose authority is delegated downward to AFRINIC Ltd?s Board through the Bylaws ? not the other way around. The Bylaws themselves make this clear: >> ? Definition of the PDP (Section 23): The PDP is approved by the Internet Community. This establishes the primacy of the community in policy development. >> ? Section 15.3: The Board determines allocation guidelines in line with the member?driven PDP. The PDP constrains the Board. >> ? Section 11.2: The Board calls a PPM as per requirements defined in the PDP. The PDP defines the conditions >> >> This model has been in place since AFRINIC?s inception. What has changed is that its risk profile was never assessed, and the events affecting the Board demonstrated how fragile the system becomes when governance failures occur. The PDP stalled, the community could not advance policy, and AFRINIC fell out of compliance with ICP?2. > > > SO: Well the PDP didn't do that, the bylaw did. Respectfully, I do not agree that PDP is what should restrict the board in this context, it is rather members who restrict the board as defined in the bylaws. I also do not agree that having a PDWG that is self sustaining while the Board is not quorate will fulfill ICP-2 either because that directly signals governance failure according to ICP 2 Can you please explain why having a self-sustaining PDWG while the Board is dysfunctional is itself a signal of failure? My understanding is that the governance failure is evidenced by a Board that cannot reach quorum; continuing policy development through the PDWG seems like a mitigation measure to maintain continuity, not an additional problem. > >> >> The new NRO Governance Document for the Recognition, Operation, and Derecognition of RIRs, currently under discussion, introduces stricter continuity obligations. These obligations will require AFRINIC to demonstrate that its PDP and the structures supporting it can continue to function even when AFRINIC Ltd faces governance paralysis. > > > And where is the best place to ensure that if not in the bylaws? Do we have this covered by the bylaws as of date? > I do not agree that "fixing" PDP alone would fulfill requirements of the new NRO Governance document if other structures including the Board is broken. article 4.1 of the Governance document clearly states the expectation of each structure and places significant expectations on the governing body. 4.1g clearly states the expectations for PDP and continuation without the board is not one of them. Section 4.1h further states policy compliance expectations and who will ensure that if not the governing body as represented by the Board. > >> >> For this reason, the community must review the PDP, identify the necessary amendments, and agree on the evolution required to ensure continuity. Where appropriate, these changes will trigger corresponding updates to the AFRINIC Ltd Bylaws and internal operational procedures. >> >> This proposal is one such attempt. A community?driven effort to strengthen the PDP, ensure compliance with ICP?2, and prevent a repeat of the governance failures that affected AFRINIC and the region. > > > SO: I appreciate the intent but I do not agree that PDP is the mechanism to effect this. I have no problem with the review of roles and responsibilities of Co-Chairs. The PDWG is a consensus gathering mechanism it should not become a legal ratification vehicle at the same time. That role should remain with the board and we have to agree that if the board have problem then the entire organisation has problem. Infact the board will not be fulfilling 4.1f of the governing document. > > In summary If the PDWG could somehow bypass the Board entirely to implement policy(as suggested by the proposal), or if the lack of a functioning Board stalls the process indefinitely, it triggers multiple compliance failures under ICP-2. So why not avoid lack of a functioning board so that PDWG and other structures within AFRINIC can continue to function. Then we test 4.1g against our current PDP and addresses any lapses found which to me are not much > >> >> Hope this helps > > > Thanks ? >> >> ?Alain >> >> >> > >> > Nevertheless, there is merit in clarifying roles of Co-Chairs and some of the 3.3.2 texts addresses that, hence that then can become the problem statement and sections that does not relate to roles and responsibilities can be commented out. >> >> > >> > Regards >> > >> > ---- >> > Sent from my mobile >> > kindly excuse typos >> > >> > >> > >> > On Fri, 19 Jun 2026, 6:22?pm Gregoire EHOUMI, > wrote: >> > Hello Seun, >> > >> > Please see the references below. Most importantly, what do you think should not be listed under the co-chairs' roles and responsibilities in the proposal? >> > https://www.apnic.net/community/participate/sigs/sig-guidelines/ >> > Chair and co-chairs roles - section 2.3 >> > https://www.lacnic.net/679/2/lacnic/policy-development-process >> > PDP chairs section 3.2 >> > https://www.ripe.net/publications/docs/ripe-861/ >> > >> > RIPE Working Group Chair Job Description and Procedures ? RIPE Network Coordination Centre >> > >> > Best regards, >> > >> > Gregoire >> > >> > >> >> On Jun 9, 2026, at 9:09?PM, Seun Ojedeji > wrote: >> >> >> >> Hello Gregoire, >> >> >> >> Please find the details inline: >> >> >> >> On Tue, 9 Jun 2026 at 14:27, Gregoire EHOUMI > wrote: >> >> Dear PDWG, >> >> >> >> This digest summarises the key points raised by community members (Ben, Seun, and Sami) regarding this policy proposal, along with the authors? clarifications and responses. >> >> It is organised into four themes for easier reading. >> >> >> >> 1. Corrections & Clarifications >> >> Mailing list freeze clarification: >> >> ? >> >> Comment (Ben): The RPD list was not frozen; only community?discuss was moderated. >> >> ? Response: Acknowledged. The text will be corrected in Draft?2. It was meant to say ? Inactive Resource Policy Discussion mailing list? >> >> >> >> >> >> 2. Participation, Representation & Elections >> >> Nomination support requirements: >> >> ? >> >> Comment (Seun): No need for supporters to be both AFRINIC members and community members. >> >> ? Response: The intent is to ensure support from at least one contact of the membership. Participants in the PDP and the WG activities are generally classified in 2 categories: ?Registered contact of AFRINIC member? and ? Non-registered contact of AFRINIC member? >> >> >> >> SO: Current participants of RPD do not need to be a ?Registered contact of AFRINIC member? OR ? Non-registered contact of AFRINIC member?, the PDWG is and should be open to any person interested in number policy development including non AFRINIC members. Note that there is a subtle difference between non-registered contact of AFRINIC member and a non-AFRINIC member. It should be okay to require support from either an AFRINIC member OR a community member, but the current text mandates both.To illustrate a nomination supported by 2 community members should pass just as a nomination supported by 2 afrinic member, likewise 1 afrinic member and 1 community member. >> >> >> >> Who can vote in NRO NC elections: >> >> ? >> >> Comment (Seun): No reason to restrict voting to people in the region. >> >> ? Response: This follows existing AFRINIC rules. For NRO NC, only participants from the region(excluding staff) vote. >> >> >> >> >> >> SO: My rationale is based on the premise that the rpd is open to all; hence, PDWG co-chair voters should not be restricted to in-region. By extension, NRO NC voters should be similar. Nevertheless considering past experiences, I agree there is merit in restricting voting to in-region but that discriminates on participation as voting is a form of participation as well. >> >> >> >> 3. Co?Chair Roles, Eligibility & Processes >> >> Level of detail in co?chair responsibilities: >> >> ? >> >> Comment (Seun): Responsibilities in section 3.3.2 feel too granular and policing. >> >> ? Response: The detail is intentional, based on RFC?2418 and other RIRs practices, to avoid ambiguity. The WG should be predictable. >> >> >> >> >> >> SO: I do not know of an RIR process that is as granular in the responsibility of co-chairs as stated in 3.3.2. Section 6.1 of RFC 2418 that describes the role of a working group chair isn't as granular either. >> >> >> >> Eligibility criteria ? meeting attendance: >> >> ? >> >> Comment (Seun): Requiring attendance at 4 of the last 6 PPMs (including one in?person) may be unrealistic. >> >> ? Response: at the old rhythm of 2 PPMs a year, this requirement means attending 4 of the 6 meetings held the last 3 years with at least one in-person. With Attendance A=4 and Meetings M= 6, what would you suggest for A and M? >> >> >> >> SO: Requiring in-person attendance is my main concern, it should not be mandatory. You may find at times that it is cheaper to travel out of Africa than within Africa, so not everyone can afford an in-person meeting. Let individual voters decide on candidates based on their historical participation. >> >> >> >> Appointment by consensus: >> >> ? >> >> Comment (Seun): Consensus?based appointment could introduce subjectivity. >> >> ? Response: This WG makes decisions by consensus with appeal mechanisms in place. Appointing co-chairs via the same mechanisms should not be a problem. With the requirements stated at section 3.3.3, it should not be difficult to reach consensus on co-chairs candidates. While this may not be perfect, it is used worldwide by various WGs. ?Community? votes rather bring more subjectivity. >> >> >> >> >> >> Code of Conduct reference: >> >> ? >> >> Comment (Seun): Simply refer to AFRINIC?s CoC. >> >> ? Response: By referring to ?applicable CoC? the proposal avoids attaching to a particular CoC. Today we are using the ?AFRINIC Community CoC? elaborated by the board ( https://afrinic.net/code ), this may change in the future. We saw some recent CoC discussions on the list. >> >> >> >> SO: Who determines which Code of Conduct (CoC) is "applicable" and which is not? >> >> >> >> 4. Governance Structure & Proposal Scope >> >> Necessity of the Number Council: >> >> ? >> >> Comment (Seun): The Appeal Committee could perform the same role; RNC may be unnecessary. >> >> ? Response: The RNC?s roles encompass calling PPM and appointing interim co-chairs. So making the AC perform RNC?s role may not be appropriate. >> >> >> >> >> >> What I am trying to communicate is that the RNC and its proposed roles are not required. There is value in having nomcom whose membership is more likely to change every year perform the role of getting nominations for PDWG Co-Chair. If both Co-Chairs resign, the Board should select one of the 3 NRO NC members to chair temporarily until a co-Chair is elected. >> >> >> >> Splitting the proposal into smaller documents: >> >> ? >> >> Comment (Sami): Consider withdrawing and splitting into multiple focused proposals. >> >> ? Response: The components are interdependent; splitting them would create incoherent intermediate states and procedural gaps. >> >> >> >> SO: I looked at the problem enumerated below: >> >> >> >> ? Adopted policy proposals not ratified or not implemented >> >> ? No Public Policy Meeting - Non-renewal of co-chairs >> >> ? Non-renewal of appeal and recall committees >> >> ? Non-renewal of ASO AC/NRO NC representatives >> >> ? Frozen Resource Policy Discussion mailing list >> >> The problems stated in the policy as listed above (apart from the last which has been corrected) all stemmed from the Board not having a quorum. The idea that the volunteer PDWG should or can effectively operate when there is no Board in the future is wishful thinking that should not be encouraged. In fact, the PDP operation is mandated by the bylaws, and the Board has the fiduciary responsibility to oversee the entire organisation. It therefore seems to me that this policy attempts to address a governance issue through policy rather than through the bylaws. Bylaws is the way to ensure that the events that happened with the Board in the past does not repeat itself. >> >> >> >> Board ratification language: >> >> ? >> >> Comment (Seun): ?Shall? implies the Board must ratify; the Board should be able to decline with reasons. >> >> ? Response: The text as written ?If a policy proposal approved by the PDWG fails to be ratified by the board (inability or refusal by the board without reasons for 60 days), a petition for ratification can be initiated by a member of the PDWG.? it is meant to cover the two scenarios below: >> >> >> >> 1. The Board is unable to act for 60 days (No quorum, No functioning Board, Legal or operational paralysis, etc.) >> >> 2. The Board refuses to ratify without giving reasons for 60 days (the Board says ?no? but gives no justification, or The Board simply does nothing and provides no explanation.) >> >> Any suggestions to improve the text if it is not clear enough ? >> >> >> >> SO: I think there may be a need to review the problem statement first so the rest of the document is better guided >> >> >> >> Regards >> >> >> >> >> >> The authors thank the community for constructive feedback. >> >> >> >> Regards, >> >> >> >> Gr?goire >> >> >> >> >> >> >> >>> On May 27, 2026, at 2:45?PM, Sami Salih > wrote: >> >>> >> >>> Dear Colleagues, >> >>> As a former PDWG Co-chair, I generally support the intent behind strengthening the autonomy and operational continuity of the PDWG. The policy development process ultimately belongs to the African Internet community and should remain resilient regardless of operational or governance challenges affecting AFRINIC as an organisation. >> >>> At the same time, I believe it is important to recognize that this proposal introduces substantial structural, operational, procedural, and governance changes to the PDP framework. In many respects, this is a major and transformative proposal rather than a routine procedural update. >> >>> From my experience with the PDP, the community process tends to work best when addressing clearly scoped issues through focused and easy-to-understand proposals. In contrast, this proposal attempts to address many different governance, electoral, operational, disciplinary, and procedural matters simultaneously, which makes it difficult for the community to fully analyse, discuss, and build meaningful consensus around all aspects at once. >> >>> IMHO, many of the ideas and intended improvements presented in this proposal are constructive and deserve serious consideration. I also fully acknowledge and respect the extensive experience, effort, and strategic thinking of the authors in developing such a comprehensive framework proposal. >> >>> However, considering the breadth of the changes and the number of distinct governance and operational matters being introduced simultaneously, my respectful recommendation would be to consider withdrawing the current proposal and restructuring this work into multiple smaller and more focused proposals. I believe this would make it significantly easier for the community to understand, analyse, discuss, and build meaningful consensus around each individual topic independently, while improving overall community engagement and participation in the process. >> >>> With Regards, >> >>> Sami Sali. >> >>> >> >>> >> >>> Sami Salih >> >>> From: Seun Ojedeji > >> >>> Sent: Monday, May 25, 2026 8:43:56 PM >> >>> To: dacostadarwin at gmail.com > >> >>> Cc: rpd at afrinic.net > >> >>> Subject: Re: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. Hello, >> >>> >> >>> Thanks for sharing this proposal. My initial comments after a brief review are the following: >> >>> >> >>> - A typical community member could also be an AFRINIC member. There is no reason to mandate that nomination supporters for the NRO NC must be both community members and AFRINIC members. Requiring one or 2 supporters from the service region should be sufficient. >> >>> >> >>> - The rpd is open to anyone that wishes to participate irrespective of origin, region or residence. It sure makes sense to restrict election participation to those with a historical record of involvement, either online or in-person to avoid historical experience of DDOS on election day. However, there is no reason to restrict the selectorate/electorate to those in the region alone. >> >>> >> >>> - I do not see the necessity of a Number Committee; it seems to create yet another layer. The Appeal committee which also serves as the recall committee can perform any intended role of the RNC. Its composition could be the 3 NRO NC members from the region, a past co-chair, and a past appeal committee chair in a non-voting capacity. In situations where both Co-Chairs are no more, the Chair of the Appeal committee can temporarily take over until rpd appoints a new co-chair >> >>> >> >>> - As a former co-chair of PDWG, i find the proposed responsibilities of the Co-chairs as described in section 3.3.2 to be overly granular and quite policing-like for lack of a better word. >> >>> >> >>> - I believe the proposed 3.3.7 should refer to AFRINIC CoC and that should be sufficient. The proposed penalties for violations look good, though they are a bit too wordy to me and the process leading to that is quite descriptive. We really need to give the co-chairs the privilege of managing events as they deem applicable >> >>> >> >>> - The idea that a co-chair eligibility should be tied to attending in-person meetings during a specific period isn't realistic given our region's unique challenges. I understand it may be an effort to put a face to the name but restricting eligibility to the last 2 years (which is basically last 4 PPM) isn't realistic. >> >>> >> >>> - 3.3.3.3.3 suggests co-chairs will be appointed by consensus, that is an interesting point that i would definitely not support. This can lead to unnecessary subjectivity. >> >>> >> >>> - I like the expectation of participation from Co-Chair hence 3.3.4 appeals to me as written. >> >>> >> >>> - Use of shall in 3.3.11 suggests that ratification is the only option for the Board. There should be an option for the Board to provide reasons for not ratifying and that should not be triggered by a petition. >> >>> >> >>> I may have more comments in future, but that is all from me for now. >> >>> >> >>> Regards >> >>> >> >>> On Mon, 25 May 2026 at 10:20, dacostadarwin at gmail.com > wrote: >> >>> Dear PDWG, >> >>> >> >>> We have received a new draft policy proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01 from authors Gr?goire EHOUMI, Noah Maina and Adeola A. P. AINA. >> >>> >> >>> The proposal contents are published at: https://afrinic.net/policy/proposals/afpub-2026-gen-001-draft01 >> >>> >> >>> We encourage you to take some time to go through the proposal contents and provide feedback as follows : >> >>> >> >>> a) Do you support or oppose the proposal? >> >>> >> >>> b) If you oppose the proposal, state your reasons. >> >>> >> >>> c) Is there anything in the proposal that is not clear? >> >>> >> >>> d) What changes could be made to this proposal to make it more effective? >> >>> >> >>> Regards, >> >>> Vincent Ngundi & Darwin Da Costa >> >>> AFRINIC PDWG Co-Chairs >> >>> _______________________________________________ >> >>> RPD mailing list >> >>> RPD at afrinic.net >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >>> >> >>> >> >>> -- >> >>> ------------------------------------------------------------------------ >> >>> Seun Ojedeji, >> >>> Bringing another down does not take you up - think about your action! >> >>> >> >>> _______________________________________________ >> >>> RPD mailing list >> >>> RPD at afrinic.net >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> >> >> >> >> -- >> >> ------------------------------------------------------------------------ >> >> Seun Ojedeji, >> >> Bringing another down does not take you up - think about your action! >> >> >> > >> > _______________________________________________ >> > RPD mailing list >> > RPD at afrinic.net >> > https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From seun.ojedeji at gmail.com Tue Jun 23 01:47:16 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Tue, 23 Jun 2026 04:47:16 +0300 Subject: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. In-Reply-To: References: <1EC212BF-EA11-4FB4-B5C4-B7429FFE6209@gmail.com> <4D12F3EC-E524-468A-BA8A-782BA4483DA6@yahoo.fr> Message-ID: Hello Musa, I think I have tried to be as clear on my concerns as possible but see further response inline which I hope further put clarity to my concern. ---- Sent from my mobile kindly excuse typos On Tue, 23 Jun 2026, 12:50?am Musa Stephen Honlue, wrote: > > > On 22 Jun 2026, at 21:48, Seun Ojedeji wrote: > > Hello PDWG, > > ---- > Sent from my mobile > kindly excuse typos > > On Mon, 22 Jun 2026, 8:21?pm ALAIN AINA via RPD, wrote: > >> Hello PDWG, >> >> > On 20 Jun 2026, at 23:25, Seun Ojedeji wrote: >> > >> > Hello Gregoire, >> > >> > Thanks for putting those references, you will find that referenced >> roles and responsibility from other RIRs and our current PDP puts some >> trust in the chair(s) to do the needful based on expected outcome. >> > >> > IMO 3.3.2.1 e,f,g,I are currently worded in much granular manner. Take >> f for instance, why won't the Co-Chairs read presentation, so what happens >> if the Co-Chair missed reading the presentation or if they did but someone >> within the PDWG claim they didn't. >> > >> > The text Preceding 3.3.2.1 addresses a lot of the granularity of >> 3.3.2.1: >> > >> > "Organise, prepare and chair the face-to-face and on-line formal >> working group meetings as well as community consultation meetings." >> >> If there is consensus that the co?chairs? roles and responsibilities must >> be explicitly defined, the next step is to agree on the precise wording. We >> invite others in the community to share their perspectives and suggestions >> > >> > That said, please do not loose sight of the main concerns that I have >> raised already. One of them is that we need to be clear on what problem we >> are trying to address. The problems stated in the current proposal are not >> problems unique to PDWG, they are organisational problems and PDWG was >> rightly affected by them just like the other part of the org was affected. >> > >> > However, PDWG is not the place to address those problems. >> >> Could you elaborate on which forum, structure, or mechanism you consider >> appropriate for addressing these issues, given that they directly affect >> the continuity, functionality, and compliance of the PDP? >> > > SO: The issue is governance matter, it affected PDWG directly just as it > affected Govcom, Nomcom, AFRINIC Org, etc it even affected the CEO. > > I have stated before that I believe the bylaws is the place to address the > issue at high level and there is an existing bylaws review ongoing to > address those bylaws related changes that ensures that when the board > losses quorum then there is a mechanism that ensures not just PDWG but > every other aspect of the organisation continue to operate. > > > As it stands, the bylaw has not resolved this issue and we are not sure we > will have a resolution soon. Therefore it?s very prudent to think of a > solution to protect this working group from such undesirable consequences. > > I support the idea of finding the solution within the PDP which in > principle is suppose to function independently of other bodies of AFRINIC. > This doesn?t stop the organisation to find a global solution with the > bylaws. > > > >> > This proposal is attempting to use the event that occurred to the board >> to turn PDWG to a self governing independent authority through policy and I >> do not believe that is the way to go about it. >> >> This proposal is not attempting to ?turn the PDWG into a self?governing >> independent authority.? The PDWG already is a self?governing, >> community?driven authority by design. What the proposal does is address the >> structural weaknesses that recent events exposed; weaknesses that placed >> AFRINIC in breach of ICP?2 and threatened the continuity of the entire >> regional registry. >> > > SO: Once again I believe that Bylaw is the place to address those weakness > as the event that occur didn't just affect PDWG alone. Roles and > responsibilities of the Co-Chairs is a different thing which is within > scope of PDWG. > > >> As required by ICP?2, all RIRs must maintain a bottom?up, self?governance >> structure for developing local policies. This structure must be >> community?driven, transparent, and resilient. Each RIR therefore defines a >> PDP that reflects its operational realities. AFRINIC is no exception. >> >> Under AFRINIC?s governance model, the PDWG is already a self?governing >> body whose authority is delegated downward to AFRINIC Ltd?s Board through >> the Bylaws ? not the other way around. The Bylaws themselves make this >> clear: >> ? Definition of the PDP (Section 23): The PDP is approved by the >> Internet Community. This establishes the primacy of the community in policy >> development. >> ? Section 15.3: The Board determines allocation guidelines in line >> with the member?driven PDP. The PDP constrains the Board. >> ? Section 11.2: The Board calls a PPM as per requirements defined in >> the PDP. The PDP defines the conditions >> >> This model has been in place since AFRINIC?s inception. What has changed >> is that its risk profile was never assessed, and the events affecting the >> Board demonstrated how fragile the system becomes when governance failures >> occur. The PDP stalled, the community could not advance policy, and AFRINIC >> fell out of compliance with ICP?2. >> > > SO: Well the PDP didn't do that, the bylaw did. Respectfully, I do not > agree that PDP is what should restrict the board in this context, it is > rather members who restrict the board as defined in the bylaws. I also do > not agree that having a PDWG that is self sustaining while the Board is not > quorate will fulfill ICP-2 either because that directly signals governance > failure according to ICP 2 > > > Can you please explain why having a self-sustaining PDWG while the Board > is dysfunctional is itself a signal of failure? > My understanding is that the governance failure is evidenced by a Board > that cannot reach quorum; continuing policy development through the PDWG > seems like a mitigation measure to maintain continuity, not an additional > problem. > It signals a failure becasue section 4.1 d and f of the NRO governance document will be grossly unfulfilled. The point here is that the role of the Board and that of PDWG is interdependent. The PDP makes the policy, the board gives it legal ratification. If the PDWG is to be repurposed to perform a dual role either temporarily or permanently then it needs to become a "governing body" as defined in section 1.1 of the NRO governing document. Is that really what we want? > > >> The new NRO Governance Document for the Recognition, Operation, and >> Derecognition of RIRs, currently under discussion, introduces stricter >> continuity obligations. These obligations will require AFRINIC to >> demonstrate that its PDP and the structures supporting it can continue to >> function even when AFRINIC Ltd faces governance paralysis. >> > > And where is the best place to ensure that if not in the bylaws? > > > Do we have this covered by the bylaws as of date? > I will note that I do not see where the NRO governance document expects that PDP performs the function of the board when the Board is dysfunctional. However the document expect that the Board(the RIR) in performing it's governing role put in place mechanism that ensures it's various structures are functional with redundant procedures in place. ref Section 4.1L The bylaw is the document to bake in those redundant procedures. As they are not in the bylaw right now, then we should put them not just to serve PDWG but to serve the various structures of the organisation which PDWG is one of them For example I expect that a dysfunctional board would trigger a section of the bylaw that initiates a process where members put in place temporary measures that will continue to give operational continuity to various structures of AFRINIC including PDWG. I do not believe that the PDWG should be that temporary measure. > > I do not agree that "fixing" PDP alone would fulfill requirements of the > new NRO Governance document if other structures including the Board is > broken. article 4.1 of the Governance document clearly states the > expectation of each structure and places significant expectations on the > governing body. 4.1g clearly states the expectations for PDP and > continuation without the board is not one of them. Section 4.1h further > states policy compliance expectations and who will ensure that if not the > governing body as represented by the Board. > > >> For this reason, the community must review the PDP, identify the >> necessary amendments, and agree on the evolution required to ensure >> continuity. Where appropriate, these changes will trigger corresponding >> updates to the AFRINIC Ltd Bylaws and internal operational procedures. >> >> This proposal is one such attempt. A community?driven effort to >> strengthen the PDP, ensure compliance with ICP?2, and prevent a repeat of >> the governance failures that affected AFRINIC and the region. >> > > SO: I appreciate the intent but I do not agree that PDP is the mechanism > to effect this. I have no problem with the review of roles and > responsibilities of Co-Chairs. The PDWG is a consensus gathering mechanism > it should not become a legal ratification vehicle at the same time. That > role should remain with the board and we have to agree that if the board > have problem then the entire organisation has problem. Infact the board > will not be fulfilling 4.1f of the governing document. > > In summary If the PDWG could somehow bypass the Board entirely to > implement policy(as suggested by the proposal), or if the lack of a > functioning Board stalls the process indefinitely, it triggers multiple > compliance failures under ICP-2. So why not avoid lack of a functioning > board so that PDWG and other structures within AFRINIC can continue to > function. Then we test 4.1g against our current PDP and addresses any > lapses found which to me are not much > > >> Hope this helps >> > > Thanks ? > >> >> ?Alain >> >> >> > >> > Nevertheless, there is merit in clarifying roles of Co-Chairs and some >> of the 3.3.2 texts addresses that, hence that then can become the problem >> statement and sections that does not relate to roles and responsibilities >> can be commented out. >> >> > >> > Regards >> > >> > ---- >> > Sent from my mobile >> > kindly excuse typos >> > >> > >> > >> > On Fri, 19 Jun 2026, 6:22?pm Gregoire EHOUMI, >> wrote: >> > Hello Seun, >> > >> > Please see the references below. Most importantly, what do you think >> should not be listed under the co-chairs' roles and responsibilities in the >> proposal? >> > https://www.apnic.net/community/participate/sigs/sig-guidelines/ >> > Chair and co-chairs roles - section 2.3 >> > https://www.lacnic.net/679/2/lacnic/policy-development-process >> > PDP chairs section 3.2 >> > https://www.ripe.net/publications/docs/ripe-861/ >> > >> > RIPE Working Group Chair Job Description and Procedures ? RIPE Network >> Coordination Centre >> > >> > Best regards, >> > >> > Gregoire >> > >> > >> >> On Jun 9, 2026, at 9:09?PM, Seun Ojedeji >> wrote: >> >> >> >> Hello Gregoire, >> >> >> >> Please find the details inline: >> >> >> >> On Tue, 9 Jun 2026 at 14:27, Gregoire EHOUMI >> wrote: >> >> Dear PDWG, >> >> >> >> This digest summarises the key points raised by community members >> (Ben, Seun, and Sami) regarding this policy proposal, along with the >> authors? clarifications and responses. >> >> It is organised into four themes for easier reading. >> >> >> >> 1. Corrections & Clarifications >> >> Mailing list freeze clarification: >> >> ? >> >> Comment (Ben): The RPD list was not frozen; only community?discuss was >> moderated. >> >> ? Response: Acknowledged. The text will be corrected in Draft?2. >> It was meant to say ? Inactive Resource Policy Discussion mailing list? >> >> >> >> >> >> 2. Participation, Representation & Elections >> >> Nomination support requirements: >> >> ? >> >> Comment (Seun): No need for supporters to be both AFRINIC members and >> community members. >> >> ? Response: The intent is to ensure support from at least one >> contact of the membership. Participants in the PDP and the WG activities >> are generally classified in 2 categories: ?Registered contact of AFRINIC >> member? and ? Non-registered contact of AFRINIC member? >> >> >> >> SO: Current participants of RPD do not need to be a ?Registered >> contact of AFRINIC member? OR ? Non-registered contact of AFRINIC member?, >> the PDWG is and should be open to any person interested in number policy >> development including non AFRINIC members. Note that there is a subtle >> difference between non-registered contact of AFRINIC member and a >> non-AFRINIC member. It should be okay to require support from either an >> AFRINIC member OR a community member, but the current text mandates both.To >> illustrate a nomination supported by 2 community members should pass just >> as a nomination supported by 2 afrinic member, likewise 1 afrinic member >> and 1 community member. >> >> >> >> Who can vote in NRO NC elections: >> >> ? >> >> Comment (Seun): No reason to restrict voting to people in the region. >> >> ? Response: This follows existing AFRINIC rules. For NRO NC, only >> participants from the region(excluding staff) vote. >> >> >> >> >> >> SO: My rationale is based on the premise that the rpd is open to all; >> hence, PDWG co-chair voters should not be restricted to in-region. By >> extension, NRO NC voters should be similar. Nevertheless considering past >> experiences, I agree there is merit in restricting voting to in-region but >> that discriminates on participation as voting is a form of participation as >> well. >> >> >> >> 3. Co?Chair Roles, Eligibility & Processes >> >> Level of detail in co?chair responsibilities: >> >> ? >> >> Comment (Seun): Responsibilities in section 3.3.2 feel too granular >> and policing. >> >> ? Response: The detail is intentional, based on RFC?2418 and other >> RIRs practices, to avoid ambiguity. The WG should be predictable. >> >> >> >> >> >> SO: I do not know of an RIR process that is as granular in the >> responsibility of co-chairs as stated in 3.3.2. Section 6.1 of RFC 2418 >> that describes the role of a working group chair isn't as granular either. >> >> >> >> Eligibility criteria ? meeting attendance: >> >> ? >> >> Comment (Seun): Requiring attendance at 4 of the last 6 PPMs >> (including one in?person) may be unrealistic. >> >> ? Response: at the old rhythm of 2 PPMs a year, this requirement >> means attending 4 of the 6 meetings held the last 3 years with at least >> one in-person. With Attendance A=4 and Meetings M= 6, what would you >> suggest for A and M? >> >> >> >> SO: Requiring in-person attendance is my main concern, it should not >> be mandatory. You may find at times that it is cheaper to travel out of >> Africa than within Africa, so not everyone can afford an in-person meeting. >> Let individual voters decide on candidates based on their historical >> participation. >> >> >> >> Appointment by consensus: >> >> ? >> >> Comment (Seun): Consensus?based appointment could introduce >> subjectivity. >> >> ? Response: This WG makes decisions by consensus with appeal >> mechanisms in place. Appointing co-chairs via the same mechanisms should >> not be a problem. With the requirements stated at section 3.3.3, it should >> not be difficult to reach consensus on co-chairs candidates. While this may >> not be perfect, it is used worldwide by various WGs. ?Community? votes >> rather bring more subjectivity. >> >> >> >> >> >> Code of Conduct reference: >> >> ? >> >> Comment (Seun): Simply refer to AFRINIC?s CoC. >> >> ? Response: By referring to ?applicable CoC? the proposal avoids >> attaching to a particular CoC. Today we are using the ?AFRINIC Community >> CoC? elaborated by the board ( https://afrinic.net/code ), this may >> change in the future. We saw some recent CoC discussions on the list. >> >> >> >> SO: Who determines which Code of Conduct (CoC) is "applicable" and >> which is not? >> >> >> >> 4. Governance Structure & Proposal Scope >> >> Necessity of the Number Council: >> >> ? >> >> Comment (Seun): The Appeal Committee could perform the same role; RNC >> may be unnecessary. >> >> ? Response: The RNC?s roles encompass calling PPM and appointing >> interim co-chairs. So making the AC perform RNC?s role may not be >> appropriate. >> >> >> >> >> >> What I am trying to communicate is that the RNC and its proposed roles >> are not required. There is value in having nomcom whose membership is more >> likely to change every year perform the role of getting nominations for >> PDWG Co-Chair. If both Co-Chairs resign, the Board should select one of the >> 3 NRO NC members to chair temporarily until a co-Chair is elected. >> >> >> >> Splitting the proposal into smaller documents: >> >> ? >> >> Comment (Sami): Consider withdrawing and splitting into multiple >> focused proposals. >> >> ? Response: The components are interdependent; splitting them >> would create incoherent intermediate states and procedural gaps. >> >> >> >> SO: I looked at the problem enumerated below: >> >> >> >> ? Adopted policy proposals not ratified or not implemented >> >> ? No Public Policy Meeting - Non-renewal of co-chairs >> >> ? Non-renewal of appeal and recall committees >> >> ? Non-renewal of ASO AC/NRO NC representatives >> >> ? Frozen Resource Policy Discussion mailing list >> >> The problems stated in the policy as listed above (apart from the last >> which has been corrected) all stemmed from the Board not having a quorum. >> The idea that the volunteer PDWG should or can effectively operate when >> there is no Board in the future is wishful thinking that should not be >> encouraged. In fact, the PDP operation is mandated by the bylaws, and the >> Board has the fiduciary responsibility to oversee the entire organisation. >> It therefore seems to me that this policy attempts to address a governance >> issue through policy rather than through the bylaws. Bylaws is the way to >> ensure that the events that happened with the Board in the past does not >> repeat itself. >> >> >> >> Board ratification language: >> >> ? >> >> Comment (Seun): ?Shall? implies the Board must ratify; the Board >> should be able to decline with reasons. >> >> ? Response: The text as written ?If a policy proposal approved by >> the PDWG fails to be ratified by the board (inability or refusal by the >> board without reasons for 60 days), a petition for ratification can be >> initiated by a member of the PDWG.? it is meant to cover the two scenarios >> below: >> >> >> >> 1. The Board is unable to act for 60 days (No quorum, No functioning >> Board, Legal or operational paralysis, etc.) >> >> 2. The Board refuses to ratify without giving reasons for 60 days (the >> Board says ?no? but gives no justification, or The Board simply does >> nothing and provides no explanation.) >> >> Any suggestions to improve the text if it is not clear enough ? >> >> >> >> SO: I think there may be a need to review the problem statement first >> so the rest of the document is better guided >> >> >> >> Regards >> >> >> >> >> >> The authors thank the community for constructive feedback. >> >> >> >> Regards, >> >> >> >> Gr?goire >> >> >> >> >> >> >> >>> On May 27, 2026, at 2:45?PM, Sami Salih >> wrote: >> >>> >> >>> Dear Colleagues, >> >>> As a former PDWG Co-chair, I generally support the intent behind >> strengthening the autonomy and operational continuity of the PDWG. The >> policy development process ultimately belongs to the African Internet >> community and should remain resilient regardless of operational or >> governance challenges affecting AFRINIC as an organisation. >> >>> At the same time, I believe it is important to recognize that this >> proposal introduces substantial structural, operational, procedural, and >> governance changes to the PDP framework. In many respects, this is a major >> and transformative proposal rather than a routine procedural update. >> >>> From my experience with the PDP, the community process tends to work >> best when addressing clearly scoped issues through focused and >> easy-to-understand proposals. In contrast, this proposal attempts to >> address many different governance, electoral, operational, disciplinary, >> and procedural matters simultaneously, which makes it difficult for the >> community to fully analyse, discuss, and build meaningful consensus around >> all aspects at once. >> >>> IMHO, many of the ideas and intended improvements presented in this >> proposal are constructive and deserve serious consideration. I also fully >> acknowledge and respect the extensive experience, effort, and strategic >> thinking of the authors in developing such a comprehensive framework >> proposal. >> >>> However, considering the breadth of the changes and the number of >> distinct governance and operational matters being introduced >> simultaneously, my respectful recommendation would be to consider >> withdrawing the current proposal and restructuring this work into multiple >> smaller and more focused proposals. I believe this would make it >> significantly easier for the community to understand, analyse, discuss, and >> build meaningful consensus around each individual topic independently, >> while improving overall community engagement and participation in the >> process. >> >>> With Regards, >> >>> Sami Sali. >> >>> >> >>> >> >>> Sami Salih >> >>> From: Seun Ojedeji >> >>> Sent: Monday, May 25, 2026 8:43:56 PM >> >>> To: dacostadarwin at gmail.com >> >>> Cc: rpd at afrinic.net >> >>> Subject: Re: [rpd] New Draft Policy Proposal - Amendment of the PDP >> Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. >> Hello, >> >>> >> >>> Thanks for sharing this proposal. My initial comments after a brief >> review are the following: >> >>> >> >>> - A typical community member could also be an AFRINIC member. There >> is no reason to mandate that nomination supporters for the NRO NC must be >> both community members and AFRINIC members. Requiring one or 2 supporters >> from the service region should be sufficient. >> >>> >> >>> - The rpd is open to anyone that wishes to participate irrespective >> of origin, region or residence. It sure makes sense to restrict election >> participation to those with a historical record of involvement, either >> online or in-person to avoid historical experience of DDOS on election >> day. However, there is no reason to restrict the selectorate/electorate to >> those in the region alone. >> >>> >> >>> - I do not see the necessity of a Number Committee; it seems to >> create yet another layer. The Appeal committee which also serves as the >> recall committee can perform any intended role of the RNC. Its composition >> could be the 3 NRO NC members from the region, a past co-chair, and a past >> appeal committee chair in a non-voting capacity. In situations where both >> Co-Chairs are no more, the Chair of the Appeal committee can temporarily >> take over until rpd appoints a new co-chair >> >>> >> >>> - As a former co-chair of PDWG, i find the proposed responsibilities >> of the Co-chairs as described in section 3.3.2 to be overly granular and >> quite policing-like for lack of a better word. >> >>> >> >>> - I believe the proposed 3.3.7 should refer to AFRINIC CoC and that >> should be sufficient. The proposed penalties for violations look good, >> though they are a bit too wordy to me and the process leading to that is >> quite descriptive. We really need to give the co-chairs the privilege of >> managing events as they deem applicable >> >>> >> >>> - The idea that a co-chair eligibility should be tied to attending >> in-person meetings during a specific period isn't realistic given our >> region's unique challenges. I understand it may be an effort to put a face >> to the name but restricting eligibility to the last 2 years (which is >> basically last 4 PPM) isn't realistic. >> >>> >> >>> - 3.3.3.3.3 suggests co-chairs will be appointed by consensus, that >> is an interesting point that i would definitely not support. This can lead >> to unnecessary subjectivity. >> >>> >> >>> - I like the expectation of participation from Co-Chair hence 3.3.4 >> appeals to me as written. >> >>> >> >>> - Use of shall in 3.3.11 suggests that ratification is the only >> option for the Board. There should be an option for the Board to provide >> reasons for not ratifying and that should not be triggered by a petition. >> >> >>> >> >>> I may have more comments in future, but that is all from me for now. >> >>> >> >>> Regards >> >>> >> >>> On Mon, 25 May 2026 at 10:20, dacostadarwin at gmail.com < >> dacostadarwin at gmail.com> wrote: >> >>> Dear PDWG, >> >>> >> >>> We have received a new draft policy proposal - Amendment of the PDP >> Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01 >> from authors Gr?goire EHOUMI, Noah Maina and Adeola A. P. AINA. >> >>> >> >>> The proposal contents are published at: >> https://afrinic.net/policy/proposals/afpub-2026-gen-001-draft01 >> >>> >> >>> We encourage you to take some time to go through the proposal >> contents and provide feedback as follows : >> >>> >> >>> a) Do you support or oppose the proposal? >> >>> >> >>> b) If you oppose the proposal, state your reasons. >> >>> >> >>> c) Is there anything in the proposal that is not clear? >> >>> >> >>> d) What changes could be made to this proposal to make it more >> effective? >> >>> >> >>> Regards, >> >>> Vincent Ngundi & Darwin Da Costa >> >>> AFRINIC PDWG Co-Chairs >> >>> _______________________________________________ >> >>> RPD mailing list >> >>> RPD at afrinic.net >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >>> >> >>> >> >>> -- >> >>> >> ------------------------------------------------------------------------ >> >>> Seun Ojedeji, >> >>> Bringing another down does not take you up - think about your action! >> >>> >> >>> _______________________________________________ >> >>> RPD mailing list >> >>> RPD at afrinic.net >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> >> >> >> >> -- >> >> >> ------------------------------------------------------------------------ >> >> Seun Ojedeji, >> >> Bringing another down does not take you up - think about your action! >> >> >> > >> > _______________________________________________ >> > RPD mailing list >> > RPD at afrinic.net >> > https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at alstonnetworks.net Tue Jun 23 12:43:41 2026 From: aa at alstonnetworks.net (Andrew Alston) Date: Tue, 23 Jun 2026 15:43:41 +0300 Subject: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. In-Reply-To: References: <1EC212BF-EA11-4FB4-B5C4-B7429FFE6209@gmail.com> <4D12F3EC-E524-468A-BA8A-782BA4483DA6@yahoo.fr> Message-ID: To add a bit to what Seun said, though I largely agree with everything he mentioned. I write this in my personal capacity. The PDP sets the operational rules; the bylaws set the governance rules. The bylaws may make reference to the PDP to strengthen it, but should not. contain things of an operational nature.Similarly, the PDP cannot function as a board; it lacks fiduciary responsibility - that lies with the directors. In my view, the role of the PDP chairs is to judge consensus, and in some cases to encourage people to come together to find consensus. It is not the job of the PDP chairs to force consensus, It needs to also be understood that a failure to reach consensus in the PDP is not a failure of the system, it merely means that the community does not agree on a particular way forward, and that is fine. If I look at the IETF processes and procedures, which I believe are some of the strongest and most well tested set, the working group chairs make judgement calls on if there is rough consensus, first at the adoption stage of a document, and then at last call for the document. After that, it moves to the Area Directors, first to put it through IETF wide last call, then, once it passes IETF wide last call, to the IESG to ballot on. IESG balloting on any proposal has 3 options. a.) A 'discuss' position is a blocking ballot, meaning an Area Director wants to discuss and resolve certain issues. It is not designed so that the Area Directors or the IESG can override community consensus. b.) A 'no objection' position. This means the Area Director has read the document and has no objections to its contents c.) A 'YES' position. This indicates strong support from a particular Area Director and is the default position for an Area Director when they move a document out of working group to the IESG for balloting. d.) An 'Abstain' position. An abstention ballot reduces the quorum required to pass a document. To put this into a PDP context, the PDP chairs act in a similar role as working group chairs do in the IETF. The board currently acts in an equivelant role to the IESG. That being said, there is a key difference: the board currently has the right to refuse to ratify policy without reason. It may be worth while considering a similar structure when it comes to ratification of PDP policies, where the board ballots along similar lines. Of course this would be a pretty unique way for an RIR to function, but it has worked well at an IETF level for more than 30 years. The advantage of this is that any refusal to ratify policy places an obligation on the individual who is blocking the ballot to have a discussion to attempt to resolve and find a way forward to meet community consensus. Just my thoughts Andrew On Tue, Jun 23, 2026 at 4:50?AM Seun Ojedeji wrote: > Hello Musa, > > I think I have tried to be as clear on my concerns as possible but see > further response inline which I hope further put clarity to my concern. > > ---- > Sent from my mobile > kindly excuse typos > > On Tue, 23 Jun 2026, 12:50?am Musa Stephen Honlue, > wrote: > >> >> >> On 22 Jun 2026, at 21:48, Seun Ojedeji wrote: >> >> Hello PDWG, >> >> ---- >> Sent from my mobile >> kindly excuse typos >> >> On Mon, 22 Jun 2026, 8:21?pm ALAIN AINA via RPD, wrote: >> >>> Hello PDWG, >>> >>> > On 20 Jun 2026, at 23:25, Seun Ojedeji wrote: >>> > >>> > Hello Gregoire, >>> > >>> > Thanks for putting those references, you will find that referenced >>> roles and responsibility from other RIRs and our current PDP puts some >>> trust in the chair(s) to do the needful based on expected outcome. >>> > >>> > IMO 3.3.2.1 e,f,g,I are currently worded in much granular manner. Take >>> f for instance, why won't the Co-Chairs read presentation, so what happens >>> if the Co-Chair missed reading the presentation or if they did but someone >>> within the PDWG claim they didn't. >>> > >>> > The text Preceding 3.3.2.1 addresses a lot of the granularity of >>> 3.3.2.1: >>> > >>> > "Organise, prepare and chair the face-to-face and on-line formal >>> working group meetings as well as community consultation meetings." >>> >>> If there is consensus that the co?chairs? roles and responsibilities >>> must be explicitly defined, the next step is to agree on the precise >>> wording. We invite others in the community to share their perspectives and >>> suggestions >>> > >>> > That said, please do not loose sight of the main concerns that I have >>> raised already. One of them is that we need to be clear on what problem we >>> are trying to address. The problems stated in the current proposal are not >>> problems unique to PDWG, they are organisational problems and PDWG was >>> rightly affected by them just like the other part of the org was affected. >>> > >>> > However, PDWG is not the place to address those problems. >>> >>> Could you elaborate on which forum, structure, or mechanism you consider >>> appropriate for addressing these issues, given that they directly affect >>> the continuity, functionality, and compliance of the PDP? >>> >> >> SO: The issue is governance matter, it affected PDWG directly just as it >> affected Govcom, Nomcom, AFRINIC Org, etc it even affected the CEO. >> >> I have stated before that I believe the bylaws is the place to address >> the issue at high level and there is an existing bylaws review ongoing to >> address those bylaws related changes that ensures that when the board >> losses quorum then there is a mechanism that ensures not just PDWG but >> every other aspect of the organisation continue to operate. >> >> >> As it stands, the bylaw has not resolved this issue and we are not sure >> we will have a resolution soon. Therefore it?s very prudent to think of a >> solution to protect this working group from such undesirable consequences. >> >> I support the idea of finding the solution within the PDP which in >> principle is suppose to function independently of other bodies of AFRINIC. >> This doesn?t stop the organisation to find a global solution with the >> bylaws. >> >> >> >>> > This proposal is attempting to use the event that occurred to the >>> board to turn PDWG to a self governing independent authority through policy >>> and I do not believe that is the way to go about it. >>> >>> This proposal is not attempting to ?turn the PDWG into a self?governing >>> independent authority.? The PDWG already is a self?governing, >>> community?driven authority by design. What the proposal does is address the >>> structural weaknesses that recent events exposed; weaknesses that placed >>> AFRINIC in breach of ICP?2 and threatened the continuity of the entire >>> regional registry. >>> >> >> SO: Once again I believe that Bylaw is the place to address those >> weakness as the event that occur didn't just affect PDWG alone. Roles and >> responsibilities of the Co-Chairs is a different thing which is within >> scope of PDWG. >> >> >>> As required by ICP?2, all RIRs must maintain a bottom?up, >>> self?governance structure for developing local policies. This structure >>> must be community?driven, transparent, and resilient. Each RIR therefore >>> defines a PDP that reflects its operational realities. AFRINIC is no >>> exception. >>> >>> Under AFRINIC?s governance model, the PDWG is already a self?governing >>> body whose authority is delegated downward to AFRINIC Ltd?s Board through >>> the Bylaws ? not the other way around. The Bylaws themselves make this >>> clear: >>> ? Definition of the PDP (Section 23): The PDP is approved by the >>> Internet Community. This establishes the primacy of the community in policy >>> development. >>> ? Section 15.3: The Board determines allocation guidelines in line >>> with the member?driven PDP. The PDP constrains the Board. >>> ? Section 11.2: The Board calls a PPM as per requirements defined >>> in the PDP. The PDP defines the conditions >>> >>> This model has been in place since AFRINIC?s inception. What has changed >>> is that its risk profile was never assessed, and the events affecting the >>> Board demonstrated how fragile the system becomes when governance failures >>> occur. The PDP stalled, the community could not advance policy, and AFRINIC >>> fell out of compliance with ICP?2. >>> >> >> SO: Well the PDP didn't do that, the bylaw did. Respectfully, I do not >> agree that PDP is what should restrict the board in this context, it is >> rather members who restrict the board as defined in the bylaws. I also do >> not agree that having a PDWG that is self sustaining while the Board is not >> quorate will fulfill ICP-2 either because that directly signals governance >> failure according to ICP 2 >> >> >> Can you please explain why having a self-sustaining PDWG while the Board >> is dysfunctional is itself a signal of failure? >> My understanding is that the governance failure is evidenced by a Board >> that cannot reach quorum; continuing policy development through the PDWG >> seems like a mitigation measure to maintain continuity, not an additional >> problem. >> > > It signals a failure becasue section 4.1 d and f of the NRO governance > document will be grossly unfulfilled. The point here is that the role of > the Board and that of PDWG is interdependent. The PDP makes the policy, the > board gives it legal ratification. If the PDWG is to be repurposed to > perform a dual role either temporarily or permanently then it needs to > become a "governing body" as defined in section 1.1 of the NRO governing > document. Is that really what we want? > > >> >> >>> The new NRO Governance Document for the Recognition, Operation, and >>> Derecognition of RIRs, currently under discussion, introduces stricter >>> continuity obligations. These obligations will require AFRINIC to >>> demonstrate that its PDP and the structures supporting it can continue to >>> function even when AFRINIC Ltd faces governance paralysis. >>> >> >> And where is the best place to ensure that if not in the bylaws? >> >> >> Do we have this covered by the bylaws as of date? >> > > I will note that I do not see where the NRO governance document expects > that PDP performs the function of the board when the Board is > dysfunctional. However the document expect that the Board(the RIR) in > performing it's governing role put in place mechanism that ensures it's > various structures are functional with redundant procedures in place. ref > Section 4.1L > > The bylaw is the document to bake in those redundant procedures. As they > are not in the bylaw right now, then we should put them not just to serve > PDWG but to serve the various structures of the organisation which PDWG is > one of them > > For example I expect that a dysfunctional board would trigger a section of > the bylaw that initiates a process where members put in place temporary > measures that will continue to give operational continuity to various > structures of AFRINIC including PDWG. I do not believe that the PDWG should > be that temporary measure. > >> >> I do not agree that "fixing" PDP alone would fulfill requirements of the >> new NRO Governance document if other structures including the Board is >> broken. article 4.1 of the Governance document clearly states the >> expectation of each structure and places significant expectations on the >> governing body. 4.1g clearly states the expectations for PDP and >> continuation without the board is not one of them. Section 4.1h further >> states policy compliance expectations and who will ensure that if not the >> governing body as represented by the Board. >> >> >>> For this reason, the community must review the PDP, identify the >>> necessary amendments, and agree on the evolution required to ensure >>> continuity. Where appropriate, these changes will trigger corresponding >>> updates to the AFRINIC Ltd Bylaws and internal operational procedures. >>> >>> This proposal is one such attempt. A community?driven effort to >>> strengthen the PDP, ensure compliance with ICP?2, and prevent a repeat of >>> the governance failures that affected AFRINIC and the region. >>> >> >> SO: I appreciate the intent but I do not agree that PDP is the mechanism >> to effect this. I have no problem with the review of roles and >> responsibilities of Co-Chairs. The PDWG is a consensus gathering mechanism >> it should not become a legal ratification vehicle at the same time. That >> role should remain with the board and we have to agree that if the board >> have problem then the entire organisation has problem. Infact the board >> will not be fulfilling 4.1f of the governing document. >> >> In summary If the PDWG could somehow bypass the Board entirely to >> implement policy(as suggested by the proposal), or if the lack of a >> functioning Board stalls the process indefinitely, it triggers multiple >> compliance failures under ICP-2. So why not avoid lack of a functioning >> board so that PDWG and other structures within AFRINIC can continue to >> function. Then we test 4.1g against our current PDP and addresses any >> lapses found which to me are not much >> >> >>> Hope this helps >>> >> >> Thanks ? >> >>> >>> ?Alain >>> >>> >>> > >>> > Nevertheless, there is merit in clarifying roles of Co-Chairs and some >>> of the 3.3.2 texts addresses that, hence that then can become the problem >>> statement and sections that does not relate to roles and responsibilities >>> can be commented out. >>> >>> > >>> > Regards >>> > >>> > ---- >>> > Sent from my mobile >>> > kindly excuse typos >>> > >>> > >>> > >>> > On Fri, 19 Jun 2026, 6:22?pm Gregoire EHOUMI, < >>> gregoire.ehoumi at yahoo.fr> wrote: >>> > Hello Seun, >>> > >>> > Please see the references below. Most importantly, what do you think >>> should not be listed under the co-chairs' roles and responsibilities in the >>> proposal? >>> > https://www.apnic.net/community/participate/sigs/sig-guidelines/ >>> > Chair and co-chairs roles - section 2.3 >>> > https://www.lacnic.net/679/2/lacnic/policy-development-process >>> > PDP chairs section 3.2 >>> > https://www.ripe.net/publications/docs/ripe-861/ >>> > >>> > RIPE Working Group Chair Job Description and Procedures ? RIPE Network >>> Coordination Centre >>> > >>> > Best regards, >>> > >>> > Gregoire >>> > >>> > >>> >> On Jun 9, 2026, at 9:09?PM, Seun Ojedeji >>> wrote: >>> >> >>> >> Hello Gregoire, >>> >> >>> >> Please find the details inline: >>> >> >>> >> On Tue, 9 Jun 2026 at 14:27, Gregoire EHOUMI < >>> gregoire.ehoumi at yahoo.fr> wrote: >>> >> Dear PDWG, >>> >> >>> >> This digest summarises the key points raised by community members >>> (Ben, Seun, and Sami) regarding this policy proposal, along with the >>> authors? clarifications and responses. >>> >> It is organised into four themes for easier reading. >>> >> >>> >> 1. Corrections & Clarifications >>> >> Mailing list freeze clarification: >>> >> ? >>> >> Comment (Ben): The RPD list was not frozen; only community?discuss >>> was moderated. >>> >> ? Response: Acknowledged. The text will be corrected in Draft?2. >>> It was meant to say ? Inactive Resource Policy Discussion mailing list? >>> >> >>> >> >>> >> 2. Participation, Representation & Elections >>> >> Nomination support requirements: >>> >> ? >>> >> Comment (Seun): No need for supporters to be both AFRINIC members and >>> community members. >>> >> ? Response: The intent is to ensure support from at least one >>> contact of the membership. Participants in the PDP and the WG activities >>> are generally classified in 2 categories: ?Registered contact of AFRINIC >>> member? and ? Non-registered contact of AFRINIC member? >>> >> >>> >> SO: Current participants of RPD do not need to be a ?Registered >>> contact of AFRINIC member? OR ? Non-registered contact of AFRINIC member?, >>> the PDWG is and should be open to any person interested in number policy >>> development including non AFRINIC members. Note that there is a subtle >>> difference between non-registered contact of AFRINIC member and a >>> non-AFRINIC member. It should be okay to require support from either an >>> AFRINIC member OR a community member, but the current text mandates both.To >>> illustrate a nomination supported by 2 community members should pass just >>> as a nomination supported by 2 afrinic member, likewise 1 afrinic member >>> and 1 community member. >>> >> >>> >> Who can vote in NRO NC elections: >>> >> ? >>> >> Comment (Seun): No reason to restrict voting to people in the region. >>> >> ? Response: This follows existing AFRINIC rules. For NRO NC, only >>> participants from the region(excluding staff) vote. >>> >> >>> >> >>> >> SO: My rationale is based on the premise that the rpd is open to all; >>> hence, PDWG co-chair voters should not be restricted to in-region. By >>> extension, NRO NC voters should be similar. Nevertheless considering past >>> experiences, I agree there is merit in restricting voting to in-region but >>> that discriminates on participation as voting is a form of participation as >>> well. >>> >> >>> >> 3. Co?Chair Roles, Eligibility & Processes >>> >> Level of detail in co?chair responsibilities: >>> >> ? >>> >> Comment (Seun): Responsibilities in section 3.3.2 feel too granular >>> and policing. >>> >> ? Response: The detail is intentional, based on RFC?2418 and >>> other RIRs practices, to avoid ambiguity. The WG should be predictable. >>> >>> >> >>> >> >>> >> SO: I do not know of an RIR process that is as granular in the >>> responsibility of co-chairs as stated in 3.3.2. Section 6.1 of RFC 2418 >>> that describes the role of a working group chair isn't as granular either. >>> >> >>> >> Eligibility criteria ? meeting attendance: >>> >> ? >>> >> Comment (Seun): Requiring attendance at 4 of the last 6 PPMs >>> (including one in?person) may be unrealistic. >>> >> ? Response: at the old rhythm of 2 PPMs a year, this requirement >>> means attending 4 of the 6 meetings held the last 3 years with at least >>> one in-person. With Attendance A=4 and Meetings M= 6, what would you >>> suggest for A and M? >>> >> >>> >> SO: Requiring in-person attendance is my main concern, it should not >>> be mandatory. You may find at times that it is cheaper to travel out of >>> Africa than within Africa, so not everyone can afford an in-person meeting. >>> Let individual voters decide on candidates based on their historical >>> participation. >>> >> >>> >> Appointment by consensus: >>> >> ? >>> >> Comment (Seun): Consensus?based appointment could introduce >>> subjectivity. >>> >> ? Response: This WG makes decisions by consensus with appeal >>> mechanisms in place. Appointing co-chairs via the same mechanisms should >>> not be a problem. With the requirements stated at section 3.3.3, it should >>> not be difficult to reach consensus on co-chairs candidates. While this may >>> not be perfect, it is used worldwide by various WGs. ?Community? votes >>> rather bring more subjectivity. >>> >> >>> >> >>> >> Code of Conduct reference: >>> >> ? >>> >> Comment (Seun): Simply refer to AFRINIC?s CoC. >>> >> ? Response: By referring to ?applicable CoC? the proposal avoids >>> attaching to a particular CoC. Today we are using the ?AFRINIC Community >>> CoC? elaborated by the board ( https://afrinic.net/code ), this may >>> change in the future. We saw some recent CoC discussions on the list. >>> >> >>> >> SO: Who determines which Code of Conduct (CoC) is "applicable" and >>> which is not? >>> >> >>> >> 4. Governance Structure & Proposal Scope >>> >> Necessity of the Number Council: >>> >> ? >>> >> Comment (Seun): The Appeal Committee could perform the same role; RNC >>> may be unnecessary. >>> >> ? Response: The RNC?s roles encompass calling PPM and appointing >>> interim co-chairs. So making the AC perform RNC?s role may not be >>> appropriate. >>> >> >>> >> >>> >> What I am trying to communicate is that the RNC and its proposed >>> roles are not required. There is value in having nomcom whose membership >>> is more likely to change every year perform the role of getting nominations >>> for PDWG Co-Chair. If both Co-Chairs resign, the Board should select one of >>> the 3 NRO NC members to chair temporarily until a co-Chair is elected. >>> >> >>> >> Splitting the proposal into smaller documents: >>> >> ? >>> >> Comment (Sami): Consider withdrawing and splitting into multiple >>> focused proposals. >>> >> ? Response: The components are interdependent; splitting them >>> would create incoherent intermediate states and procedural gaps. >>> >> >>> >> SO: I looked at the problem enumerated below: >>> >> >>> >> ? Adopted policy proposals not ratified or not implemented >>> >> ? No Public Policy Meeting - Non-renewal of co-chairs >>> >> ? Non-renewal of appeal and recall committees >>> >> ? Non-renewal of ASO AC/NRO NC representatives >>> >> ? Frozen Resource Policy Discussion mailing list >>> >> The problems stated in the policy as listed above (apart from the >>> last which has been corrected) all stemmed from the Board not having a >>> quorum. The idea that the volunteer PDWG should or can effectively operate >>> when there is no Board in the future is wishful thinking that should not be >>> encouraged. In fact, the PDP operation is mandated by the bylaws, and the >>> Board has the fiduciary responsibility to oversee the entire organisation. >>> It therefore seems to me that this policy attempts to address a governance >>> issue through policy rather than through the bylaws. Bylaws is the way to >>> ensure that the events that happened with the Board in the past does not >>> repeat itself. >>> >> >>> >> Board ratification language: >>> >> ? >>> >> Comment (Seun): ?Shall? implies the Board must ratify; the Board >>> should be able to decline with reasons. >>> >> ? Response: The text as written ?If a policy proposal approved by >>> the PDWG fails to be ratified by the board (inability or refusal by the >>> board without reasons for 60 days), a petition for ratification can be >>> initiated by a member of the PDWG.? it is meant to cover the two scenarios >>> below: >>> >> >>> >> 1. The Board is unable to act for 60 days (No quorum, No functioning >>> Board, Legal or operational paralysis, etc.) >>> >> 2. The Board refuses to ratify without giving reasons for 60 days >>> (the Board says ?no? but gives no justification, or The Board simply does >>> nothing and provides no explanation.) >>> >> Any suggestions to improve the text if it is not clear enough ? >>> >> >>> >> SO: I think there may be a need to review the problem statement first >>> so the rest of the document is better guided >>> >> >>> >> Regards >>> >> >>> >> >>> >> The authors thank the community for constructive feedback. >>> >> >>> >> Regards, >>> >> >>> >> Gr?goire >>> >> >>> >> >>> >> >>> >>> On May 27, 2026, at 2:45?PM, Sami Salih >>> wrote: >>> >>> >>> >>> Dear Colleagues, >>> >>> As a former PDWG Co-chair, I generally support the intent behind >>> strengthening the autonomy and operational continuity of the PDWG. The >>> policy development process ultimately belongs to the African Internet >>> community and should remain resilient regardless of operational or >>> governance challenges affecting AFRINIC as an organisation. >>> >>> At the same time, I believe it is important to recognize that this >>> proposal introduces substantial structural, operational, procedural, and >>> governance changes to the PDP framework. In many respects, this is a major >>> and transformative proposal rather than a routine procedural update. >>> >>> From my experience with the PDP, the community process tends to work >>> best when addressing clearly scoped issues through focused and >>> easy-to-understand proposals. In contrast, this proposal attempts to >>> address many different governance, electoral, operational, disciplinary, >>> and procedural matters simultaneously, which makes it difficult for the >>> community to fully analyse, discuss, and build meaningful consensus around >>> all aspects at once. >>> >>> IMHO, many of the ideas and intended improvements presented in this >>> proposal are constructive and deserve serious consideration. I also fully >>> acknowledge and respect the extensive experience, effort, and strategic >>> thinking of the authors in developing such a comprehensive framework >>> proposal. >>> >>> However, considering the breadth of the changes and the number of >>> distinct governance and operational matters being introduced >>> simultaneously, my respectful recommendation would be to consider >>> withdrawing the current proposal and restructuring this work into multiple >>> smaller and more focused proposals. I believe this would make it >>> significantly easier for the community to understand, analyse, discuss, and >>> build meaningful consensus around each individual topic independently, >>> while improving overall community engagement and participation in the >>> process. >>> >>> With Regards, >>> >>> Sami Sali. >>> >>> >>> >>> >>> >>> Sami Salih >>> >>> From: Seun Ojedeji >>> >>> Sent: Monday, May 25, 2026 8:43:56 PM >>> >>> To: dacostadarwin at gmail.com >>> >>> Cc: rpd at afrinic.net >>> >>> Subject: Re: [rpd] New Draft Policy Proposal - Amendment of the PDP >>> Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. >>> Hello, >>> >>> >>> >>> Thanks for sharing this proposal. My initial comments after a brief >>> review are the following: >>> >>> >>> >>> - A typical community member could also be an AFRINIC member. There >>> is no reason to mandate that nomination supporters for the NRO NC must be >>> both community members and AFRINIC members. Requiring one or 2 supporters >>> from the service region should be sufficient. >>> >>> >>> >>> - The rpd is open to anyone that wishes to participate irrespective >>> of origin, region or residence. It sure makes sense to restrict election >>> participation to those with a historical record of involvement, either >>> online or in-person to avoid historical experience of DDOS on election >>> day. However, there is no reason to restrict the selectorate/electorate to >>> those in the region alone. >>> >>> >>> >>> - I do not see the necessity of a Number Committee; it seems to >>> create yet another layer. The Appeal committee which also serves as the >>> recall committee can perform any intended role of the RNC. Its composition >>> could be the 3 NRO NC members from the region, a past co-chair, and a past >>> appeal committee chair in a non-voting capacity. In situations where both >>> Co-Chairs are no more, the Chair of the Appeal committee can temporarily >>> take over until rpd appoints a new co-chair >>> >>> >>> >>> - As a former co-chair of PDWG, i find the proposed responsibilities >>> of the Co-chairs as described in section 3.3.2 to be overly granular and >>> quite policing-like for lack of a better word. >>> >>> >>> >>> - I believe the proposed 3.3.7 should refer to AFRINIC CoC and that >>> should be sufficient. The proposed penalties for violations look good, >>> though they are a bit too wordy to me and the process leading to that is >>> quite descriptive. We really need to give the co-chairs the privilege of >>> managing events as they deem applicable >>> >>> >>> >>> - The idea that a co-chair eligibility should be tied to attending >>> in-person meetings during a specific period isn't realistic given our >>> region's unique challenges. I understand it may be an effort to put a face >>> to the name but restricting eligibility to the last 2 years (which is >>> basically last 4 PPM) isn't realistic. >>> >>> >>> >>> - 3.3.3.3.3 suggests co-chairs will be appointed by consensus, that >>> is an interesting point that i would definitely not support. This can lead >>> to unnecessary subjectivity. >>> >>> >>> >>> - I like the expectation of participation from Co-Chair hence 3.3.4 >>> appeals to me as written. >>> >>> >>> >>> - Use of shall in 3.3.11 suggests that ratification is the only >>> option for the Board. There should be an option for the Board to provide >>> reasons for not ratifying and that should not be triggered by a petition. >>> >>> >>> >>> >>> I may have more comments in future, but that is all from me for now. >>> >>> >>> >>> Regards >>> >>> >>> >>> On Mon, 25 May 2026 at 10:20, dacostadarwin at gmail.com < >>> dacostadarwin at gmail.com> wrote: >>> >>> Dear PDWG, >>> >>> >>> >>> We have received a new draft policy proposal - Amendment of the PDP >>> Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01 >>> from authors Gr?goire EHOUMI, Noah Maina and Adeola A. P. AINA. >>> >>> >>> >>> The proposal contents are published at: >>> https://afrinic.net/policy/proposals/afpub-2026-gen-001-draft01 >>> >>> >>> >>> We encourage you to take some time to go through the proposal >>> contents and provide feedback as follows : >>> >>> >>> >>> a) Do you support or oppose the proposal? >>> >>> >>> >>> b) If you oppose the proposal, state your reasons. >>> >>> >>> >>> c) Is there anything in the proposal that is not clear? >>> >>> >>> >>> d) What changes could be made to this proposal to make it more >>> effective? >>> >>> >>> >>> Regards, >>> >>> Vincent Ngundi & Darwin Da Costa >>> >>> AFRINIC PDWG Co-Chairs >>> >>> _______________________________________________ >>> >>> RPD mailing list >>> >>> RPD at afrinic.net >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> >>> >>> >>> >>> -- >>> >>> >>> ------------------------------------------------------------------------ >>> >>> Seun Ojedeji, >>> >>> Bringing another down does not take you up - think about your action! >>> >>> >>> >>> _______________________________________________ >>> >>> RPD mailing list >>> >>> RPD at afrinic.net >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >> >>> >> >>> >> >>> >> -- >>> >> >>> ------------------------------------------------------------------------ >>> >> Seun Ojedeji, >>> >> Bringing another down does not take you up - think about your action! >>> >> >>> > >>> > _______________________________________________ >>> > RPD mailing list >>> > RPD at afrinic.net >>> > https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From honlue at gmail.com Tue Jun 23 14:53:30 2026 From: honlue at gmail.com (Musa Stephen Honlue) Date: Tue, 23 Jun 2026 16:53:30 +0200 Subject: [rpd] Soft Landing, Recovered Space and Priority AFPUB-2026-IPv4-001-DRAFT02. In-Reply-To: <0C0DDB39-96A1-49AE-8F91-24280BB9FC61@gmail.com> References: <0C0DDB39-96A1-49AE-8F91-24280BB9FC61@gmail.com> Message-ID: Dear Jordi, Your proposal says: Unless exceptional circumstances are demonstrated, utilisation shall reach at least fifty per cent (50%) within eight (8) months from the date of assignment. Q: Why 8 months and not 12 as in the previous 5.5.1.9? How does this address the problem stated? Sent from my iPhone > On 22 Jun 2026, at 10:28, Darwin Da Costa wrote: > > ?Dear PDWG, > > We have received an update to the draft policy proposal - Soft Landing, Recovered Space and Priority, ID AFPUB-2026-IPv4-001-DRAFT01 from author Jordi Palet Martinez on 16 June 2026. > > The proposal contents are published at: > https://afrinic.net/participate/policy/proposals/afpub-2026-ipv4-001-draft02 > > We encourage you to take some time to go through the proposal contents and provide feedback as follows: > > a) Do you support or oppose the proposal? > > b) If you oppose the proposal, state your reasons? > > c) Is there anything in the proposal that is not clear? > > d) What changes could be made to this proposal to make it more effective? > > > Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Tue Jun 23 16:11:24 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Tue, 23 Jun 2026 18:11:24 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: <87y0h1v9kv.fsf@emailplus.org> References: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> <26787741-b549-41e9-a27e-abf062fe6dac@uls.co.za> <2B015435-ED04-45E5-95BA-807D1D62092D@consulintel.es> <87y0h1v9kv.fsf@emailplus.org> Message-ID: <8E64306A-814E-416C-9C72-119093CFFC9B@consulintel.es> Hi Benson, Trying to make it short. In most of the aspects that you mention here, manufacturing of routers, switches, and similar networking equipment, is not different in Africa than Europe or Latin America and Caribbean, and despite that, there is more IPv6 deployment and traffic in those regions. As I?ve mention today in the AFNOG session, having deployed IPv6 in many networks, in many countries, including small and big deployments, the cost of artificially keeping IPv4 with CGN is much higher than deploying IPv6. This is like any new technology. Either you do it already with your own pace, but a good one (months, not years), or will become in the end more difficult and expensive. Regards, Jordi @jordipalet > El 30 may 2026, a las 5:51, Benson Muite escribi?: > > "jordi.palet--- via RPD" writes: > > Hi Jordi, > > Encouraging more IPv6 adoption is helpful. MNOs sharing IPv4 addresses > leads to problematic internet access, at least some IPs I have received > temporarily have been listed at: > https://www.dronebl.org/ > > That being said, sharing an IPv4 address behind a NAT gives some level > of privacy which may require more configuration effort if IPv6 is used. > >> Hi Dorothy, >> >> I need to make this clear again. There is no such thing as migration, we don?t turn-off IPv4 completely. Anyone can keep using it. What we are doing is to ensure with IPv6-only with IPv4-as-a-Service, that both protocols coexist, so we do an ordered transition, at the pace of everyone. >> >> As faster you move to IPv6, as cheaper is your CapEx and OpEx, it is up to each operator. >> > > There is an initial setup and training cost. For hardware, while one > can buy routers from other places outside Africa, some of the countries > mentioned as leading in the post: > https://www.digitaleconomy.ke/post/ipv4-address-allocation-in-africa-are-you-above-or-below-the-ip-address-poverty-line > also have growing electronics industries, unfortunately none are > fabricating chips, but PCB assembly is possible. While many people will > likely start with refurbrished equipment, locally manufactured equipment > maybe easier to repair and update giving a lower total cost of > ownership. > > AfriNIC courses on IPv6 are good, but there does not seem to be a strong > link to the African electronics sector and to the education sector. Are > there any statistics on the numbers of people that have taken AfriNICs > IPv6 courses? Of particular interest would be Nigeria which has > significant internet users and DRC which produces raw material used in > chips, but does little value addition to the raw materials. > > My understanding is that a number of tertiary educational institutions have > obtained blocks of IPs from AfriNIC. How actively promoted is IPv6 at > these institutions? Do any of those people responsible for those > allocations monitor this list or does one need to reach out to them > individually? > > >> The RIR job is not setting up policies, is up to the community, the global Internet community. >> >> What we are saying is that the Soft Landing policy already was designed to ensure that newcomers and existing players needing more resources, do it together with IPv6 deployment, but we didn?t set rules to verify that and the level of encouragement was basically cero. Now we, as a community (not the RIR), can decide if we want to give a stronger push and what level of push we want to have. >> >> Fighting against IPv6 deployment is non-sense, it is a very high cost not only for all the players in Africa, but also in the rest of Internet. > > Encouraging IPv6 adoption is good, but success will depend on more than > just forcing an allocation when applying for a block of IPv4 addresses. > If most people in Africa will be consumers on a mobile network behind a > NAT, then IPv6 uptake will be slow. If more people are looking to put > up their own online services, they maybe more interest in IPv6 as the > cost of leasing the address will be lower. > > Of course, for Africa, if Google and Meta were to turn off IPv4, it > would be painful, but transition to IPv6 would happen real quick! > > The other main reason people use the internet is to access government > services. This sector tends to be price sensitive and difficult to move > in new directions. Simply forcing it to obtain IPv6 addresses will not > likely encourage IPv6 adoption unless there are tangible benefits to end > users. > >> >> We need to see it in the other way around. Deploying IPv6, or extending existing networks with IPv6 is cheaper than buying more and more CGN boxes. >> >> So clearly I must disagree that this will create a burden, on the other way around. >> >> Saying it in a different way: It will be non-sense that an existing operator extend its network to accommodate more customers (that?s the reason they need more IPv4 addresses in the end), and they do it without implementing IPv6, the cost will be bigger with only-IPv4. Same non-sense that a new operator or end-site decides to start just with IPv4, the cost will be bigger. >> >> We need to find the way to word it so there is a proper balance. We are not saying necessarily, because you have ?n? new customers and need IPv4 addresses for them, you need to deploy IPv6 in all your network (even less remove IPv4 completely). Let?s find the way to ensure that we request a % of traffic according to the grow that creates you the need for more IPv4 addresses and then ramp-up the following years. > > The policy proposal has good intentions, but the feedback here indicates > you are mostly preaching to the choir. It needs integration with the > wider eco system. > > Regards, > Benson ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From jordi.palet at consulintel.es Tue Jun 23 16:19:21 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Tue, 23 Jun 2026 18:19:21 +0200 Subject: [rpd] Soft Landing, Recovered Space and Priority AFPUB-2026-IPv4-001-DRAFT02. In-Reply-To: References: <0C0DDB39-96A1-49AE-8F91-24280BB9FC61@gmail.com> Message-ID: <515166FF-17BD-4C52-9242-DE816AE2D039@consulintel.es> Hi Musa, This is done to accommodate the same periods as defined in the existing soft-landing policy, which is the one acting in current situation. The full point was to avoid discrepancies in different parts of the CPM. If we want to adopt 12 months, then we should also modify the soft-landing to be 12 months, but mixing different periods doesn?t really make sense, as the staff need to take a decision about which one apply. Regards, Jordi @jordipalet > El 23 jun 2026, a las 16:53, Musa Stephen Honlue escribi?: > > Dear Jordi, > > > Your proposal says: > > Unless exceptional circumstances are demonstrated, utilisation shall reach at least fifty per cent (50%) within eight (8) months from the date of assignment. > > Q: Why 8 months and not 12 as in the previous 5.5.1.9? > > How does this address the problem stated? > > Sent from my iPhone > >> On 22 Jun 2026, at 10:28, Darwin Da Costa wrote: >> >> ?Dear PDWG, >> >> We have received an update to the draft policy proposal - Soft Landing, Recovered Space and Priority, ID AFPUB-2026-IPv4-001-DRAFT01 from author Jordi Palet Martinez on 16 June 2026. >> >> The proposal contents are published at: >> https://afrinic.net/participate/policy/proposals/afpub-2026-ipv4-001-draft02 >> >> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >> >> a) Do you support or oppose the proposal? >> >> b) If you oppose the proposal, state your reasons? >> >> c) Is there anything in the proposal that is not clear? >> >> d) What changes could be made to this proposal to make it more effective? >> >> >> Regards, >> Vincent Ngundi & Darwin Da Costa >> AFRINIC PDWG Co-Chairs >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From honlue at gmail.com Tue Jun 23 20:20:10 2026 From: honlue at gmail.com (Musa Stephen Honlue) Date: Tue, 23 Jun 2026 22:20:10 +0200 Subject: [rpd] Soft Landing, Recovered Space and Priority AFPUB-2026-IPv4-001-DRAFT02. In-Reply-To: <515166FF-17BD-4C52-9242-DE816AE2D039@consulintel.es> References: <515166FF-17BD-4C52-9242-DE816AE2D039@consulintel.es> Message-ID: <43843058-62B9-4722-BC3A-6621E38C9E3C@gmail.com> Thank you Jordi. I am fully in support of this policy. > > On 23 Jun 2026, at 18:20, jordi.palet--- via RPD wrote: > > ?Hi Musa, > > This is done to accommodate the same periods as defined in the existing soft-landing policy, which is the one acting in current situation. > > The full point was to avoid discrepancies in different parts of the CPM. > > If we want to adopt 12 months, then we should also modify the soft-landing to be 12 months, but mixing different periods doesn?t really make sense, as the staff need to take a decision about which one apply. > > Regards, > Jordi > > @jordipalet > >> El 23 jun 2026, a las 16:53, Musa Stephen Honlue escribi?: >> >> Dear Jordi, >> >> >> Your proposal says: >> >> Unless exceptional circumstances are demonstrated, utilisation shall reach at least fifty per cent (50%) within eight (8) months from the date of assignment. >> >> Q: Why 8 months and not 12 as in the previous 5.5.1.9? >> >> How does this address the problem stated? >> >> Sent from my iPhone >> >>> On 22 Jun 2026, at 10:28, Darwin Da Costa wrote: >>> >>> ?Dear PDWG, >>> >>> We have received an update to the draft policy proposal - Soft Landing, Recovered Space and Priority, ID AFPUB-2026-IPv4-001-DRAFT01 from author Jordi Palet Martinez on 16 June 2026. >>> >>> The proposal contents are published at: >>> https://afrinic.net/participate/policy/proposals/afpub-2026-ipv4-001-draft02 >>> >>> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>> >>> a) Do you support or oppose the proposal? >>> >>> b) If you oppose the proposal, state your reasons? >>> >>> c) Is there anything in the proposal that is not clear? >>> >>> d) What changes could be made to this proposal to make it more effective? >>> >>> >>> Regards, >>> Vincent Ngundi & Darwin Da Costa >>> AFRINIC PDWG Co-Chairs >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From honlue at gmail.com Tue Jun 23 20:25:30 2026 From: honlue at gmail.com (Musa Stephen Honlue) Date: Tue, 23 Jun 2026 22:25:30 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image0.png Type: image/png Size: 75252 bytes Desc: not available URL: From madhvi at afrinic.net Tue Jun 23 21:25:30 2026 From: madhvi at afrinic.net (Madhvi Gokool) Date: Wed, 24 Jun 2026 00:25:30 +0300 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: Message-ID: Hello Stephen There seems to be an issue with the first version of the proposal on the website. We'll ensure it's fixed the soonest. Please note that the author submitted a revised version of the proposal - https://afrinic.net/participate/policy/proposals/afpub-2026-v6-001-draft02 and that the latter will be discussed during the AFRINIC-37 PPM. Kind Regards Madhvi Policy Liaison AFRINIC On 24/06/2026 00:25, Musa Stephen Honlue wrote: > image0.png > > > This is what the link is showing, please confirm that you have access. > >> On 28 May 2026, at 12:27, Sami Salih wrote: >> >> ? >> Hi Jordi, colleagues, >> >> Thank you, Jordi, for considering my previous comments and for >> restructuring this into a more focused proposal. >> >> In principle, I support linking IPv4 allocations under the Soft >> Landing policy with commitment toward IPv6 deployment. Given the IPv4 >> exhaustion reality, this is a reasonable policy direction. >> >> I also appreciate the additional clarifications regarding the >> existing policy references and deployment expectations. Nevertheless, >> I believe the implementation and enforcement aspects may still >> require further refinement to ensure the criteria remain objective, >> measurable, and operationally practical across the AFRINIC service >> region. I believe the staff analysis may further help clarify the >> operational feasibility, compliance verification approach, and >> enforcement practicality of the proposed requirements. >> >> Overall, I support the intent of the proposal and appreciate the more >> granular approach to the discussion. >> >> With Regards, >> Sami Salih. >> >> >> Sami Salih >> ------------------------------------------------------------------------ >> *From:* jordi.palet--- via RPD >> *Sent:* Thursday, May 28, 2026 1:21:52 PM >> *To:* rpd at afrinic.net >> *Subject:* Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing >> AFPUB-2026-v6-001-DRAFT01. >> Hi Jaco, >> >> Tks, next version will use: ?Any IPv4 request must be done with a >> simultaneous IPv6 request if the requesting party does not already >> have IPv6 space.? This may depend on the impact analysis inputs, of >> course. >> >> About the determination/measurement that this is being done, let me >> explain how I see this. >> >> The existing 6.5.1.1 (for LIRs) and 6.8.2, already set the conditions >> to be met. AFRINIC already has, in both cases, a 12 months period to >> confirm the deployment. May be is not sufficiently clear there if >> AFRINIC should do something if that?s not actually done. We aren?t >> talking there only about announcing the prefix, but also in the case >> of LIRs, about making assignments to end-sites, and the text is >> clear, /48s, nothing different. There is no reason for using >> different sizes for different type of customers on that text. There >> is no technical reason at all for not doing it correctly, however, >> this is a discussion for amending that part of the policy, not for >> this proposal. >> >> What this proposal wants to make sure is that you *actually*, >> *following existing policy*, if you get IPv4, you really deploy IPv6 >> in 12 months. To reinforce it I explicitly mention ?In addition ??, >> as you said. Note that ?in addition? section enforces a more detailed >> work from the member requesting IPv4, to justify a credible IPv6 >> addressing and deployment plan, this will be accepted or not by >> AFRINIC, as with any request evaluation. >> >> For example, in many RIRs, not just AFRINIC, I?ve observed that many >> members get by default a /32, even if they have 800.000 end-sites. >> Clearly wrong, they didn?t have done any real addressing plan and >> they will end up providing a single /64 to each end-site. If they do >> it correctly, they will soon discover why they should use /48s, so >> with a /32 they can only cover around 50.000 customers, which means >> that typically for 800.000 of customers (depending on the topological >> distribution of the network) will mean that they need a /27-/28. >> >> I don?t think nobody can say ?deploy? is not clear. If this is the >> case, we can improve it, something like ?and IPv6 is actually being >> used?. We can even set a minimum level of traffic, such as 50% for >> example? Those that have deployed IPv6 know that, at least in the >> case of residential and cellular customers, because most of the >> traffic (typically 75-90%) is from big CDNs, caches, and contend >> providers (all google, all Meta, Akamai and all the other CDNs), >> already provide IPv6, when you turn on IPv6 in an end-site, the IPv6 >> traffic of that end-site becomes 75%-90% IPv6, in turn the total ISP >> traffic reaches similar levels. >> >> So asking for 50% seems to me conservative, but I?m happy for lower >> levels, if we agree that we can ask for more later on. We can even >> consider something like 25% after 12 months, 50% after 24 months, 75% >> after 48 months. Just an example. >> >> Finally, as we have many policies that AFRINIC not necessarily is >> measuring the compliance, that?s what the other proposal (compliance >> dashboard) was already trying to resolve, now in a ?light? version. >> >> This proposal also added a trigger (failure to comply) to ensure that >> abuse (requesting IPv4, but then not deploying IPv6) can enact the >> RSA terms, because clearly shows that there is a policy breach. >> >> By the way, dynamic prefixes in IPv6 is broken, terrible idea, >> specially if there are power outages. >> >> I suggest to read what, hopefully in a few months, will become in >> RFC/BCP a successor of RIPE690: >> >> https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/ >> >> Regards, >> Jordi >> >> @jordipalet >> >> >>> El 28 may 2026, a las 11:43, Jaco Kroon escribi?: >>> >>> Hi Jordi, >>> >>> I support the principle very much. Practicality may be a different >>> story, yes, must implement v6, however: >>> >>> How do you determine/measure that?? I think your "In addition" >>> section addresses this to a degree. >>> >>> Merely advertising IPv6 space?? Sure, that's easy, but it doesn't >>> mean I have to actually make that available to customers. >>> >>> Re proposed text, the word "However, " doesn't add value, merely >>> "Any IPv4 request must be done with a simultaneous IPv6 request if >>> the requesting party does not already have IPv6 space." >>> >>> This does also be the question, it seems 6.5.1.1.3 states that you >>> must give /48s to end sites - we do distinguish between business and >>> home users, for business we happily do /48 if so required (at least >>> we reserve a /48 per site minimum), but for home users we generally >>> do dynamically allocated /56 (but will again do /48 on request) - >>> would this imply failure to comply with your proposed policy?? If >>> so, should the proposed policy be adjusted, or 6.5.1.1.3? >>> >>> For PI space (6.8.2.2.d) - what does deployed mean? >>> >>> Kind regards, >>> Jaco Kroon >>> >>> On 2026/05/28 10:28, jordi.palet--- via RPD wrote: >>> >>>> Hi all, >>>> >>>> Somehow this is a response to Sami input on a previous proposal. >>>> >>>> This way we can split the problem space in 2 proposals, which may reach consensus without depending one on the other. >>>> >>>> So we have a very basic question: If we believe that the members that receive IPv4 out of the Soft Landing policy, must implement IPv6, or not? >>>> >>>> Regards, >>>> Jordi >>>> >>>> @jordipalet >>>> >>>> >>>>> El 28 may 2026, a las 10:05, Darwin Da Costa escribi?: >>>>> >>>>> Dear PDWG, >>>>> >>>>> We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>>>> >>>>> https://afrinic.net/afpub-2026-v6-001-draft01 >>>>> >>>>> >>>>> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>>>> >>>>> a)Do you support or oppose the proposal? >>>>> >>>>> b) If you oppose the proposal, state your reasons? >>>>> >>>>> c) Is there anything in the proposal that is not clear? >>>>> >>>>> d) What changes could be made to this proposal to make it more effective? >>>>> >>>>> >>>>> Regards, >>>>> Vincent Ngundi & Darwin Da Costa >>>>> AFRINIC PDWG Co-Chairs >>>>> >>>>> _______________________________________________ >>>>> RPD mailing list >>>>> RPD at afrinic.net >>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> ********************************************** >>>> IPv4 is over >>>> Are you ready for the new Internet ? >>>> http://www.theipv6company.com >>>> The IPv6 Company >>>> >>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged >> or confidential. The information is intended to be for the exclusive >> use of the individual(s) named above and further non-explicilty >> authorized disclosure, copying, distribution or use of the contents >> of this information, even if partially, including attached files, is >> strictly prohibited and will be considered a criminal offense. If you >> are not the intended recipient be aware that any disclosure, copying, >> distribution or use of the contents of this information, even if >> partially, including attached files, is strictly prohibited, will be >> considered a criminal offense, so you must reply to the original >> sender to inform about this communication and delete it. >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image0.png Type: image/png Size: 75252 bytes Desc: not available URL: From honlue at gmail.com Tue Jun 23 21:45:36 2026 From: honlue at gmail.com (Musa Stephen Honlue) Date: Tue, 23 Jun 2026 23:45:36 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: Message-ID: <2C5FDE82-7BCC-4763-BAA5-3D0AC8EA1CFF@gmail.com> An HTML attachment was scrubbed... URL: From honlue at gmail.com Tue Jun 23 22:20:56 2026 From: honlue at gmail.com (Musa Stephen Honlue) Date: Wed, 24 Jun 2026 00:20:56 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: <2C5FDE82-7BCC-4763-BAA5-3D0AC8EA1CFF@gmail.com> References: <2C5FDE82-7BCC-4763-BAA5-3D0AC8EA1CFF@gmail.com> Message-ID: <99A91520-5FF1-4924-A200-C593A3EA520C@gmail.com> An HTML attachment was scrubbed... URL: From seun.ojedeji at gmail.com Tue Jun 23 22:21:16 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Tue, 23 Jun 2026 17:21:16 -0500 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: Message-ID: Hi Jordi, I understand it might be late to put in an updated draft, but it would be good to know how you plan to address the comments raised in the impact assessment Regards On Tue, 23 Jun 2026 at 16:25, Madhvi Gokool via RPD wrote: > Hello Stephen > > There seems to be an issue with the first version of the proposal on the > website. We'll ensure it's fixed the soonest. > > Please note that the author submitted a revised version of the proposal - > https://afrinic.net/participate/policy/proposals/afpub-2026-v6-001-draft02 > and that the latter will be discussed during the AFRINIC-37 PPM. > > Kind Regards > > Madhvi > > Policy Liaison AFRINIC > On 24/06/2026 00:25, Musa Stephen Honlue wrote: > > [image: image0.png] > > > This is what the link is showing, please confirm that you have access. > > On 28 May 2026, at 12:27, Sami Salih > wrote: > > ? > Hi Jordi, colleagues, > > Thank you, Jordi, for considering my previous comments and for > restructuring this into a more focused proposal. > > In principle, I support linking IPv4 allocations under the Soft Landing > policy with commitment toward IPv6 deployment. Given the IPv4 exhaustion > reality, this is a reasonable policy direction. > > I also appreciate the additional clarifications regarding the existing > policy references and deployment expectations. Nevertheless, I believe the > implementation and enforcement aspects may still require further refinement > to ensure the criteria remain objective, measurable, and operationally > practical across the AFRINIC service region. I believe the staff analysis > may further help clarify the operational feasibility, compliance > verification approach, and enforcement practicality of the proposed > requirements. > > Overall, I support the intent of the proposal and appreciate the more > granular approach to the discussion. > > With Regards, > Sami Salih. > > > Sami Salih > ------------------------------ > *From:* jordi.palet--- via RPD > *Sent:* Thursday, May 28, 2026 1:21:52 PM > *To:* rpd at afrinic.net > *Subject:* Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01. > > Hi Jaco, > > Tks, next version will use: ?Any IPv4 request must be done with a > simultaneous IPv6 request if the requesting party does not already have > IPv6 space.? This may depend on the impact analysis inputs, of course. > > About the determination/measurement that this is being done, let me > explain how I see this. > > The existing 6.5.1.1 (for LIRs) and 6.8.2, already set the conditions to > be met. AFRINIC already has, in both cases, a 12 months period to confirm > the deployment. May be is not sufficiently clear there if AFRINIC should do > something if that?s not actually done. We aren?t talking there only about > announcing the prefix, but also in the case of LIRs, about making > assignments to end-sites, and the text is clear, /48s, nothing different. > There is no reason for using different sizes for different type of > customers on that text. There is no technical reason at all for not doing > it correctly, however, this is a discussion for amending that part of the > policy, not for this proposal. > > What this proposal wants to make sure is that you *actually*, *following > existing policy*, if you get IPv4, you really deploy IPv6 in 12 months. To > reinforce it I explicitly mention ?In addition ??, as you said. Note that > ?in addition? section enforces a more detailed work from the member > requesting IPv4, to justify a credible IPv6 addressing and deployment plan, > this will be accepted or not by AFRINIC, as with any request evaluation. > > For example, in many RIRs, not just AFRINIC, I?ve observed that many > members get by default a /32, even if they have 800.000 end-sites. Clearly > wrong, they didn?t have done any real addressing plan and they will end up > providing a single /64 to each end-site. If they do it correctly, they will > soon discover why they should use /48s, so with a /32 they can only cover > around 50.000 customers, which means that typically for 800.000 of > customers (depending on the topological distribution of the network) will > mean that they need a /27-/28. > > I don?t think nobody can say ?deploy? is not clear. If this is the case, > we can improve it, something like ?and IPv6 is actually being used?. We can > even set a minimum level of traffic, such as 50% for example? Those that > have deployed IPv6 know that, at least in the case of residential and > cellular customers, because most of the traffic (typically 75-90%) is from > big CDNs, caches, and contend providers (all google, all Meta, Akamai and > all the other CDNs), already provide IPv6, when you turn on IPv6 in an > end-site, the IPv6 traffic of that end-site becomes 75%-90% IPv6, in turn > the total ISP traffic reaches similar levels. > > So asking for 50% seems to me conservative, but I?m happy for lower > levels, if we agree that we can ask for more later on. We can even consider > something like 25% after 12 months, 50% after 24 months, 75% after 48 > months. Just an example. > > Finally, as we have many policies that AFRINIC not necessarily is > measuring the compliance, that?s what the other proposal (compliance > dashboard) was already trying to resolve, now in a ?light? version. > > This proposal also added a trigger (failure to comply) to ensure that > abuse (requesting IPv4, but then not deploying IPv6) can enact the RSA > terms, because clearly shows that there is a policy breach. > > By the way, dynamic prefixes in IPv6 is broken, terrible idea, specially > if there are power outages. > > I suggest to read what, hopefully in a few months, will become in RFC/BCP > a successor of RIPE690: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/ > > Regards, > Jordi > > @jordipalet > > > El 28 may 2026, a las 11:43, Jaco Kroon > escribi?: > > Hi Jordi, > > I support the principle very much. Practicality may be a different story, > yes, must implement v6, however: > > How do you determine/measure that? I think your "In addition" section > addresses this to a degree. > > Merely advertising IPv6 space? Sure, that's easy, but it doesn't mean I > have to actually make that available to customers. > > Re proposed text, the word "However, " doesn't add value, merely "Any IPv4 > request must be done with a simultaneous IPv6 request if the requesting > party does not already have IPv6 space." > > This does also be the question, it seems 6.5.1.1.3 states that you must > give /48s to end sites - we do distinguish between business and home users, > for business we happily do /48 if so required (at least we reserve a /48 > per site minimum), but for home users we generally do dynamically allocated > /56 (but will again do /48 on request) - would this imply failure to comply > with your proposed policy? If so, should the proposed policy be adjusted, > or 6.5.1.1.3? > > For PI space (6.8.2.2.d) - what does deployed mean? > > Kind regards, > Jaco Kroon > > On 2026/05/28 10:28, jordi.palet--- via RPD wrote: > > Hi all, > > Somehow this is a response to Sami input on a previous proposal. > > This way we can split the problem space in 2 proposals, which may reach consensus without depending one on the other. > > So we have a very basic question: If we believe that the members that receive IPv4 out of the Soft Landing policy, must implement IPv6, or not? > > Regards, > Jordi > > @jordipalet > > > > El 28 may 2026, a las 10:05, Darwin Da Costa escribi?: > > Dear PDWG, > > We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: > https://afrinic.net/afpub-2026-v6-001-draft01 > > > We encourage you to take some time to go through the proposal contents and provide feedback as follows: > > a)Do you support or oppose the proposal? > > b) If you oppose the proposal, state your reasons? > > c) Is there anything in the proposal that is not clear? > > d) What changes could be made to this proposal to make it more effective? > > > Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs > > _______________________________________________ > RPD mailing listRPD at afrinic.nethttps://lists.afrinic.net/mailman/listinfo/rpd > > ********************************************** > IPv4 is over > Are you ready for the new Internet ?http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > _______________________________________________ > RPD mailing listRPD at afrinic.nethttps://lists.afrinic.net/mailman/listinfo/rpd > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > _______________________________________________ > RPD mailing listRPD at afrinic.nethttps://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -- ------------------------------------------------------------------------ *Seun Ojedeji,* Bringing another down does not take you up - think about your action! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image0.png Type: image/png Size: 75252 bytes Desc: not available URL: From seun.ojedeji at gmail.com Tue Jun 23 22:46:54 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Tue, 23 Jun 2026 17:46:54 -0500 Subject: [rpd] New Draft Policy Proposal - Amendment of the PDP Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. In-Reply-To: References: <1EC212BF-EA11-4FB4-B5C4-B7429FFE6209@gmail.com> <4D12F3EC-E524-468A-BA8A-782BA4483DA6@yahoo.fr> Message-ID: Hello Andrew, While I expect a responsible Board would provide detailed reasons for refusing to ratify a policy proposal, I understand that the current Bylaw and CPM do not mandate an explanation. Hence, I agree it is worth incorporating that requirement into the bylaw. On a related note, the recently published staff assessment of this proposal (especially the legal section) aligns closely with my concerns; therefore, I do not support the proposal in its current form Regards On Tue, 23 Jun 2026 at 07:43, Andrew Alston wrote: > To add a bit to what Seun said, though I largely agree with everything he > mentioned. I write this in my personal capacity. > > The PDP sets the operational rules; the bylaws set the governance rules. > The bylaws may make reference to the PDP to strengthen it, but should not. > contain things of an operational nature.Similarly, the PDP cannot function > as a board; it lacks fiduciary responsibility - that lies with the > directors. > > In my view, the role of the PDP chairs is to judge consensus, and in some > cases to encourage people to come together to find consensus. It is not > the job of the PDP chairs to force consensus, It needs to also be > understood that a failure to reach consensus in the PDP is not a failure of > the system, it merely means that the community does not agree on a > particular way forward, and that is fine. > > If I look at the IETF processes and procedures, which I believe are some > of the strongest and most well tested set, the working group chairs make > judgement calls on if there is rough consensus, first at the adoption stage > of a document, and then at last call for the document. After that, it > moves to the Area Directors, first to put it through IETF wide last call, > then, once it passes IETF wide last call, to the IESG to ballot on. IESG > balloting on any proposal has 3 options. > > a.) A 'discuss' position is a blocking ballot, meaning an Area Director > wants to discuss and resolve certain issues. It is not designed so that > the Area Directors or the IESG can override community consensus. > b.) A 'no objection' position. This means the Area Director has read the > document and has no objections to its contents > c.) A 'YES' position. This indicates strong support from a particular > Area Director and is the default position for an Area Director when they > move a document out of working group to the IESG for balloting. > d.) An 'Abstain' position. An abstention ballot reduces the quorum > required to pass a document. > > To put this into a PDP context, the PDP chairs act in a similar role as > working group chairs do in the IETF. The board currently acts in an > equivelant role to the IESG. That being said, there is a key difference: > the board currently has the right to refuse to ratify policy without > reason. It may be worth while considering a similar structure when it > comes to ratification of PDP policies, where the board ballots along > similar lines. Of course this would be a pretty unique way for an RIR to > function, but it has worked well at an IETF level for more than 30 years. > The advantage of this is that any refusal to ratify policy places an > obligation on the individual who is blocking the ballot to have a > discussion to attempt to resolve and find a way forward to meet community > consensus. > > Just my thoughts > > Andrew > > > > On Tue, Jun 23, 2026 at 4:50?AM Seun Ojedeji > wrote: > >> Hello Musa, >> >> I think I have tried to be as clear on my concerns as possible but see >> further response inline which I hope further put clarity to my concern. >> >> ---- >> Sent from my mobile >> kindly excuse typos >> >> On Tue, 23 Jun 2026, 12:50?am Musa Stephen Honlue, >> wrote: >> >>> >>> >>> On 22 Jun 2026, at 21:48, Seun Ojedeji wrote: >>> >>> Hello PDWG, >>> >>> ---- >>> Sent from my mobile >>> kindly excuse typos >>> >>> On Mon, 22 Jun 2026, 8:21?pm ALAIN AINA via RPD, >>> wrote: >>> >>>> Hello PDWG, >>>> >>>> > On 20 Jun 2026, at 23:25, Seun Ojedeji >>>> wrote: >>>> > >>>> > Hello Gregoire, >>>> > >>>> > Thanks for putting those references, you will find that referenced >>>> roles and responsibility from other RIRs and our current PDP puts some >>>> trust in the chair(s) to do the needful based on expected outcome. >>>> > >>>> > IMO 3.3.2.1 e,f,g,I are currently worded in much granular manner. >>>> Take f for instance, why won't the Co-Chairs read presentation, so what >>>> happens if the Co-Chair missed reading the presentation or if they did but >>>> someone within the PDWG claim they didn't. >>>> > >>>> > The text Preceding 3.3.2.1 addresses a lot of the granularity of >>>> 3.3.2.1: >>>> > >>>> > "Organise, prepare and chair the face-to-face and on-line formal >>>> working group meetings as well as community consultation meetings." >>>> >>>> If there is consensus that the co?chairs? roles and responsibilities >>>> must be explicitly defined, the next step is to agree on the precise >>>> wording. We invite others in the community to share their perspectives and >>>> suggestions >>>> > >>>> > That said, please do not loose sight of the main concerns that I have >>>> raised already. One of them is that we need to be clear on what problem we >>>> are trying to address. The problems stated in the current proposal are not >>>> problems unique to PDWG, they are organisational problems and PDWG was >>>> rightly affected by them just like the other part of the org was affected. >>>> > >>>> > However, PDWG is not the place to address those problems. >>>> >>>> Could you elaborate on which forum, structure, or mechanism you >>>> consider appropriate for addressing these issues, given that they directly >>>> affect the continuity, functionality, and compliance of the PDP? >>>> >>> >>> SO: The issue is governance matter, it affected PDWG directly just as it >>> affected Govcom, Nomcom, AFRINIC Org, etc it even affected the CEO. >>> >>> I have stated before that I believe the bylaws is the place to address >>> the issue at high level and there is an existing bylaws review ongoing to >>> address those bylaws related changes that ensures that when the board >>> losses quorum then there is a mechanism that ensures not just PDWG but >>> every other aspect of the organisation continue to operate. >>> >>> >>> As it stands, the bylaw has not resolved this issue and we are not sure >>> we will have a resolution soon. Therefore it?s very prudent to think of a >>> solution to protect this working group from such undesirable consequences. >>> >>> I support the idea of finding the solution within the PDP which in >>> principle is suppose to function independently of other bodies of AFRINIC. >>> This doesn?t stop the organisation to find a global solution with the >>> bylaws. >>> >>> >>> >>>> > This proposal is attempting to use the event that occurred to the >>>> board to turn PDWG to a self governing independent authority through policy >>>> and I do not believe that is the way to go about it. >>>> >>>> This proposal is not attempting to ?turn the PDWG into a self?governing >>>> independent authority.? The PDWG already is a self?governing, >>>> community?driven authority by design. What the proposal does is address the >>>> structural weaknesses that recent events exposed; weaknesses that placed >>>> AFRINIC in breach of ICP?2 and threatened the continuity of the entire >>>> regional registry. >>>> >>> >>> SO: Once again I believe that Bylaw is the place to address those >>> weakness as the event that occur didn't just affect PDWG alone. Roles and >>> responsibilities of the Co-Chairs is a different thing which is within >>> scope of PDWG. >>> >>> >>>> As required by ICP?2, all RIRs must maintain a bottom?up, >>>> self?governance structure for developing local policies. This structure >>>> must be community?driven, transparent, and resilient. Each RIR therefore >>>> defines a PDP that reflects its operational realities. AFRINIC is no >>>> exception. >>>> >>>> Under AFRINIC?s governance model, the PDWG is already a self?governing >>>> body whose authority is delegated downward to AFRINIC Ltd?s Board through >>>> the Bylaws ? not the other way around. The Bylaws themselves make this >>>> clear: >>>> ? Definition of the PDP (Section 23): The PDP is approved by the >>>> Internet Community. This establishes the primacy of the community in policy >>>> development. >>>> ? Section 15.3: The Board determines allocation guidelines in line >>>> with the member?driven PDP. The PDP constrains the Board. >>>> ? Section 11.2: The Board calls a PPM as per requirements defined >>>> in the PDP. The PDP defines the conditions >>>> >>>> This model has been in place since AFRINIC?s inception. What has >>>> changed is that its risk profile was never assessed, and the events >>>> affecting the Board demonstrated how fragile the system becomes when >>>> governance failures occur. The PDP stalled, the community could not advance >>>> policy, and AFRINIC fell out of compliance with ICP?2. >>>> >>> >>> SO: Well the PDP didn't do that, the bylaw did. Respectfully, I do not >>> agree that PDP is what should restrict the board in this context, it is >>> rather members who restrict the board as defined in the bylaws. I also do >>> not agree that having a PDWG that is self sustaining while the Board is not >>> quorate will fulfill ICP-2 either because that directly signals governance >>> failure according to ICP 2 >>> >>> >>> Can you please explain why having a self-sustaining PDWG while the Board >>> is dysfunctional is itself a signal of failure? >>> My understanding is that the governance failure is evidenced by a Board >>> that cannot reach quorum; continuing policy development through the PDWG >>> seems like a mitigation measure to maintain continuity, not an additional >>> problem. >>> >> >> It signals a failure becasue section 4.1 d and f of the NRO governance >> document will be grossly unfulfilled. The point here is that the role of >> the Board and that of PDWG is interdependent. The PDP makes the policy, the >> board gives it legal ratification. If the PDWG is to be repurposed to >> perform a dual role either temporarily or permanently then it needs to >> become a "governing body" as defined in section 1.1 of the NRO governing >> document. Is that really what we want? >> >> >>> >>> >>>> The new NRO Governance Document for the Recognition, Operation, and >>>> Derecognition of RIRs, currently under discussion, introduces stricter >>>> continuity obligations. These obligations will require AFRINIC to >>>> demonstrate that its PDP and the structures supporting it can continue to >>>> function even when AFRINIC Ltd faces governance paralysis. >>>> >>> >>> And where is the best place to ensure that if not in the bylaws? >>> >>> >>> Do we have this covered by the bylaws as of date? >>> >> >> I will note that I do not see where the NRO governance document expects >> that PDP performs the function of the board when the Board is >> dysfunctional. However the document expect that the Board(the RIR) in >> performing it's governing role put in place mechanism that ensures it's >> various structures are functional with redundant procedures in place. ref >> Section 4.1L >> >> The bylaw is the document to bake in those redundant procedures. As they >> are not in the bylaw right now, then we should put them not just to serve >> PDWG but to serve the various structures of the organisation which PDWG is >> one of them >> >> For example I expect that a dysfunctional board would trigger a section >> of the bylaw that initiates a process where members put in place temporary >> measures that will continue to give operational continuity to various >> structures of AFRINIC including PDWG. I do not believe that the PDWG should >> be that temporary measure. >> >>> >>> I do not agree that "fixing" PDP alone would fulfill requirements of the >>> new NRO Governance document if other structures including the Board is >>> broken. article 4.1 of the Governance document clearly states the >>> expectation of each structure and places significant expectations on the >>> governing body. 4.1g clearly states the expectations for PDP and >>> continuation without the board is not one of them. Section 4.1h further >>> states policy compliance expectations and who will ensure that if not the >>> governing body as represented by the Board. >>> >>> >>>> For this reason, the community must review the PDP, identify the >>>> necessary amendments, and agree on the evolution required to ensure >>>> continuity. Where appropriate, these changes will trigger corresponding >>>> updates to the AFRINIC Ltd Bylaws and internal operational procedures. >>>> >>>> This proposal is one such attempt. A community?driven effort to >>>> strengthen the PDP, ensure compliance with ICP?2, and prevent a repeat of >>>> the governance failures that affected AFRINIC and the region. >>>> >>> >>> SO: I appreciate the intent but I do not agree that PDP is the mechanism >>> to effect this. I have no problem with the review of roles and >>> responsibilities of Co-Chairs. The PDWG is a consensus gathering mechanism >>> it should not become a legal ratification vehicle at the same time. That >>> role should remain with the board and we have to agree that if the board >>> have problem then the entire organisation has problem. Infact the board >>> will not be fulfilling 4.1f of the governing document. >>> >>> In summary If the PDWG could somehow bypass the Board entirely to >>> implement policy(as suggested by the proposal), or if the lack of a >>> functioning Board stalls the process indefinitely, it triggers multiple >>> compliance failures under ICP-2. So why not avoid lack of a functioning >>> board so that PDWG and other structures within AFRINIC can continue to >>> function. Then we test 4.1g against our current PDP and addresses any >>> lapses found which to me are not much >>> >>> >>>> Hope this helps >>>> >>> >>> Thanks ? >>> >>>> >>>> ?Alain >>>> >>>> >>>> > >>>> > Nevertheless, there is merit in clarifying roles of Co-Chairs and >>>> some of the 3.3.2 texts addresses that, hence that then can become the >>>> problem statement and sections that does not relate to roles and >>>> responsibilities can be commented out. >>>> >>>> > >>>> > Regards >>>> > >>>> > ---- >>>> > Sent from my mobile >>>> > kindly excuse typos >>>> > >>>> > >>>> > >>>> > On Fri, 19 Jun 2026, 6:22?pm Gregoire EHOUMI, < >>>> gregoire.ehoumi at yahoo.fr> wrote: >>>> > Hello Seun, >>>> > >>>> > Please see the references below. Most importantly, what do you think >>>> should not be listed under the co-chairs' roles and responsibilities in the >>>> proposal? >>>> > https://www.apnic.net/community/participate/sigs/sig-guidelines/ >>>> > Chair and co-chairs roles - section 2.3 >>>> > https://www.lacnic.net/679/2/lacnic/policy-development-process >>>> > PDP chairs section 3.2 >>>> > https://www.ripe.net/publications/docs/ripe-861/ >>>> > >>>> > RIPE Working Group Chair Job Description and Procedures ? RIPE >>>> Network Coordination Centre >>>> > >>>> > Best regards, >>>> > >>>> > Gregoire >>>> > >>>> > >>>> >> On Jun 9, 2026, at 9:09?PM, Seun Ojedeji >>>> wrote: >>>> >> >>>> >> Hello Gregoire, >>>> >> >>>> >> Please find the details inline: >>>> >> >>>> >> On Tue, 9 Jun 2026 at 14:27, Gregoire EHOUMI < >>>> gregoire.ehoumi at yahoo.fr> wrote: >>>> >> Dear PDWG, >>>> >> >>>> >> This digest summarises the key points raised by community members >>>> (Ben, Seun, and Sami) regarding this policy proposal, along with the >>>> authors? clarifications and responses. >>>> >> It is organised into four themes for easier reading. >>>> >> >>>> >> 1. Corrections & Clarifications >>>> >> Mailing list freeze clarification: >>>> >> ? >>>> >> Comment (Ben): The RPD list was not frozen; only community?discuss >>>> was moderated. >>>> >> ? Response: Acknowledged. The text will be corrected in Draft?2. >>>> It was meant to say ? Inactive Resource Policy Discussion mailing list? >>>> >> >>>> >> >>>> >> 2. Participation, Representation & Elections >>>> >> Nomination support requirements: >>>> >> ? >>>> >> Comment (Seun): No need for supporters to be both AFRINIC members >>>> and community members. >>>> >> ? Response: The intent is to ensure support from at least one >>>> contact of the membership. Participants in the PDP and the WG activities >>>> are generally classified in 2 categories: ?Registered contact of AFRINIC >>>> member? and ? Non-registered contact of AFRINIC member? >>>> >> >>>> >> SO: Current participants of RPD do not need to be a ?Registered >>>> contact of AFRINIC member? OR ? Non-registered contact of AFRINIC member?, >>>> the PDWG is and should be open to any person interested in number policy >>>> development including non AFRINIC members. Note that there is a subtle >>>> difference between non-registered contact of AFRINIC member and a >>>> non-AFRINIC member. It should be okay to require support from either an >>>> AFRINIC member OR a community member, but the current text mandates both.To >>>> illustrate a nomination supported by 2 community members should pass just >>>> as a nomination supported by 2 afrinic member, likewise 1 afrinic member >>>> and 1 community member. >>>> >> >>>> >> Who can vote in NRO NC elections: >>>> >> ? >>>> >> Comment (Seun): No reason to restrict voting to people in the region. >>>> >> ? Response: This follows existing AFRINIC rules. For NRO NC, >>>> only participants from the region(excluding staff) vote. >>>> >> >>>> >> >>>> >> SO: My rationale is based on the premise that the rpd is open to >>>> all; hence, PDWG co-chair voters should not be restricted to in-region. By >>>> extension, NRO NC voters should be similar. Nevertheless considering past >>>> experiences, I agree there is merit in restricting voting to in-region but >>>> that discriminates on participation as voting is a form of participation as >>>> well. >>>> >> >>>> >> 3. Co?Chair Roles, Eligibility & Processes >>>> >> Level of detail in co?chair responsibilities: >>>> >> ? >>>> >> Comment (Seun): Responsibilities in section 3.3.2 feel too granular >>>> and policing. >>>> >> ? Response: The detail is intentional, based on RFC?2418 and >>>> other RIRs practices, to avoid ambiguity. The WG should be predictable. >>>> >>>> >> >>>> >> >>>> >> SO: I do not know of an RIR process that is as granular in the >>>> responsibility of co-chairs as stated in 3.3.2. Section 6.1 of RFC 2418 >>>> that describes the role of a working group chair isn't as granular either. >>>> >> >>>> >> Eligibility criteria ? meeting attendance: >>>> >> ? >>>> >> Comment (Seun): Requiring attendance at 4 of the last 6 PPMs >>>> (including one in?person) may be unrealistic. >>>> >> ? Response: at the old rhythm of 2 PPMs a year, this requirement >>>> means attending 4 of the 6 meetings held the last 3 years with at least >>>> one in-person. With Attendance A=4 and Meetings M= 6, what would you >>>> suggest for A and M? >>>> >> >>>> >> SO: Requiring in-person attendance is my main concern, it should not >>>> be mandatory. You may find at times that it is cheaper to travel out of >>>> Africa than within Africa, so not everyone can afford an in-person meeting. >>>> Let individual voters decide on candidates based on their historical >>>> participation. >>>> >> >>>> >> Appointment by consensus: >>>> >> ? >>>> >> Comment (Seun): Consensus?based appointment could introduce >>>> subjectivity. >>>> >> ? Response: This WG makes decisions by consensus with appeal >>>> mechanisms in place. Appointing co-chairs via the same mechanisms should >>>> not be a problem. With the requirements stated at section 3.3.3, it should >>>> not be difficult to reach consensus on co-chairs candidates. While this may >>>> not be perfect, it is used worldwide by various WGs. ?Community? votes >>>> rather bring more subjectivity. >>>> >> >>>> >> >>>> >> Code of Conduct reference: >>>> >> ? >>>> >> Comment (Seun): Simply refer to AFRINIC?s CoC. >>>> >> ? Response: By referring to ?applicable CoC? the proposal avoids >>>> attaching to a particular CoC. Today we are using the ?AFRINIC Community >>>> CoC? elaborated by the board ( https://afrinic.net/code ), this may >>>> change in the future. We saw some recent CoC discussions on the list. >>>> >> >>>> >> SO: Who determines which Code of Conduct (CoC) is "applicable" and >>>> which is not? >>>> >> >>>> >> 4. Governance Structure & Proposal Scope >>>> >> Necessity of the Number Council: >>>> >> ? >>>> >> Comment (Seun): The Appeal Committee could perform the same role; >>>> RNC may be unnecessary. >>>> >> ? Response: The RNC?s roles encompass calling PPM and appointing >>>> interim co-chairs. So making the AC perform RNC?s role may not be >>>> appropriate. >>>> >> >>>> >> >>>> >> What I am trying to communicate is that the RNC and its proposed >>>> roles are not required. There is value in having nomcom whose membership >>>> is more likely to change every year perform the role of getting nominations >>>> for PDWG Co-Chair. If both Co-Chairs resign, the Board should select one of >>>> the 3 NRO NC members to chair temporarily until a co-Chair is elected. >>>> >> >>>> >> Splitting the proposal into smaller documents: >>>> >> ? >>>> >> Comment (Sami): Consider withdrawing and splitting into multiple >>>> focused proposals. >>>> >> ? Response: The components are interdependent; splitting them >>>> would create incoherent intermediate states and procedural gaps. >>>> >> >>>> >> SO: I looked at the problem enumerated below: >>>> >> >>>> >> ? Adopted policy proposals not ratified or not implemented >>>> >> ? No Public Policy Meeting - Non-renewal of co-chairs >>>> >> ? Non-renewal of appeal and recall committees >>>> >> ? Non-renewal of ASO AC/NRO NC representatives >>>> >> ? Frozen Resource Policy Discussion mailing list >>>> >> The problems stated in the policy as listed above (apart from the >>>> last which has been corrected) all stemmed from the Board not having a >>>> quorum. The idea that the volunteer PDWG should or can effectively operate >>>> when there is no Board in the future is wishful thinking that should not be >>>> encouraged. In fact, the PDP operation is mandated by the bylaws, and the >>>> Board has the fiduciary responsibility to oversee the entire organisation. >>>> It therefore seems to me that this policy attempts to address a governance >>>> issue through policy rather than through the bylaws. Bylaws is the way to >>>> ensure that the events that happened with the Board in the past does not >>>> repeat itself. >>>> >> >>>> >> Board ratification language: >>>> >> ? >>>> >> Comment (Seun): ?Shall? implies the Board must ratify; the Board >>>> should be able to decline with reasons. >>>> >> ? Response: The text as written ?If a policy proposal approved >>>> by the PDWG fails to be ratified by the board (inability or refusal by the >>>> board without reasons for 60 days), a petition for ratification can be >>>> initiated by a member of the PDWG.? it is meant to cover the two scenarios >>>> below: >>>> >> >>>> >> 1. The Board is unable to act for 60 days (No quorum, No functioning >>>> Board, Legal or operational paralysis, etc.) >>>> >> 2. The Board refuses to ratify without giving reasons for 60 days >>>> (the Board says ?no? but gives no justification, or The Board simply does >>>> nothing and provides no explanation.) >>>> >> Any suggestions to improve the text if it is not clear enough ? >>>> >> >>>> >> SO: I think there may be a need to review the problem statement >>>> first so the rest of the document is better guided >>>> >> >>>> >> Regards >>>> >> >>>> >> >>>> >> The authors thank the community for constructive feedback. >>>> >> >>>> >> Regards, >>>> >> >>>> >> Gr?goire >>>> >> >>>> >> >>>> >> >>>> >>> On May 27, 2026, at 2:45?PM, Sami Salih >>>> wrote: >>>> >>> >>>> >>> Dear Colleagues, >>>> >>> As a former PDWG Co-chair, I generally support the intent behind >>>> strengthening the autonomy and operational continuity of the PDWG. The >>>> policy development process ultimately belongs to the African Internet >>>> community and should remain resilient regardless of operational or >>>> governance challenges affecting AFRINIC as an organisation. >>>> >>> At the same time, I believe it is important to recognize that this >>>> proposal introduces substantial structural, operational, procedural, and >>>> governance changes to the PDP framework. In many respects, this is a major >>>> and transformative proposal rather than a routine procedural update. >>>> >>> From my experience with the PDP, the community process tends to >>>> work best when addressing clearly scoped issues through focused and >>>> easy-to-understand proposals. In contrast, this proposal attempts to >>>> address many different governance, electoral, operational, disciplinary, >>>> and procedural matters simultaneously, which makes it difficult for the >>>> community to fully analyse, discuss, and build meaningful consensus around >>>> all aspects at once. >>>> >>> IMHO, many of the ideas and intended improvements presented in this >>>> proposal are constructive and deserve serious consideration. I also fully >>>> acknowledge and respect the extensive experience, effort, and strategic >>>> thinking of the authors in developing such a comprehensive framework >>>> proposal. >>>> >>> However, considering the breadth of the changes and the number of >>>> distinct governance and operational matters being introduced >>>> simultaneously, my respectful recommendation would be to consider >>>> withdrawing the current proposal and restructuring this work into multiple >>>> smaller and more focused proposals. I believe this would make it >>>> significantly easier for the community to understand, analyse, discuss, and >>>> build meaningful consensus around each individual topic independently, >>>> while improving overall community engagement and participation in the >>>> process. >>>> >>> With Regards, >>>> >>> Sami Sali. >>>> >>> >>>> >>> >>>> >>> Sami Salih >>>> >>> From: Seun Ojedeji >>>> >>> Sent: Monday, May 25, 2026 8:43:56 PM >>>> >>> To: dacostadarwin at gmail.com >>>> >>> Cc: rpd at afrinic.net >>>> >>> Subject: Re: [rpd] New Draft Policy Proposal - Amendment of the PDP >>>> Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01. >>>> Hello, >>>> >>> >>>> >>> Thanks for sharing this proposal. My initial comments after a brief >>>> review are the following: >>>> >>> >>>> >>> - A typical community member could also be an AFRINIC member. There >>>> is no reason to mandate that nomination supporters for the NRO NC must be >>>> both community members and AFRINIC members. Requiring one or 2 supporters >>>> from the service region should be sufficient. >>>> >>> >>>> >>> - The rpd is open to anyone that wishes to participate irrespective >>>> of origin, region or residence. It sure makes sense to restrict election >>>> participation to those with a historical record of involvement, either >>>> online or in-person to avoid historical experience of DDOS on election >>>> day. However, there is no reason to restrict the selectorate/electorate to >>>> those in the region alone. >>>> >>> >>>> >>> - I do not see the necessity of a Number Committee; it seems to >>>> create yet another layer. The Appeal committee which also serves as the >>>> recall committee can perform any intended role of the RNC. Its composition >>>> could be the 3 NRO NC members from the region, a past co-chair, and a past >>>> appeal committee chair in a non-voting capacity. In situations where both >>>> Co-Chairs are no more, the Chair of the Appeal committee can temporarily >>>> take over until rpd appoints a new co-chair >>>> >>> >>>> >>> - As a former co-chair of PDWG, i find the proposed >>>> responsibilities of the Co-chairs as described in section 3.3.2 to be >>>> overly granular and quite policing-like for lack of a better word. >>>> >>> >>>> >>> - I believe the proposed 3.3.7 should refer to AFRINIC CoC and that >>>> should be sufficient. The proposed penalties for violations look good, >>>> though they are a bit too wordy to me and the process leading to that is >>>> quite descriptive. We really need to give the co-chairs the privilege of >>>> managing events as they deem applicable >>>> >>> >>>> >>> - The idea that a co-chair eligibility should be tied to attending >>>> in-person meetings during a specific period isn't realistic given our >>>> region's unique challenges. I understand it may be an effort to put a face >>>> to the name but restricting eligibility to the last 2 years (which is >>>> basically last 4 PPM) isn't realistic. >>>> >>> >>>> >>> - 3.3.3.3.3 suggests co-chairs will be appointed by consensus, that >>>> is an interesting point that i would definitely not support. This can lead >>>> to unnecessary subjectivity. >>>> >>> >>>> >>> - I like the expectation of participation from Co-Chair hence 3.3.4 >>>> appeals to me as written. >>>> >>> >>>> >>> - Use of shall in 3.3.11 suggests that ratification is the only >>>> option for the Board. There should be an option for the Board to provide >>>> reasons for not ratifying and that should not be triggered by a petition. >>>> >>>> >>> >>>> >>> I may have more comments in future, but that is all from me for now. >>>> >>> >>>> >>> Regards >>>> >>> >>>> >>> On Mon, 25 May 2026 at 10:20, dacostadarwin at gmail.com < >>>> dacostadarwin at gmail.com> wrote: >>>> >>> Dear PDWG, >>>> >>> >>>> >>> We have received a new draft policy proposal - Amendment of the PDP >>>> Working Group (WG) Guidelines and Procedures AFPUB-2026-GEN-001-DRAFT01 >>>> from authors Gr?goire EHOUMI, Noah Maina and Adeola A. P. AINA. >>>> >>> >>>> >>> The proposal contents are published at: >>>> https://afrinic.net/policy/proposals/afpub-2026-gen-001-draft01 >>>> >>> >>>> >>> We encourage you to take some time to go through the proposal >>>> contents and provide feedback as follows : >>>> >>> >>>> >>> a) Do you support or oppose the proposal? >>>> >>> >>>> >>> b) If you oppose the proposal, state your reasons. >>>> >>> >>>> >>> c) Is there anything in the proposal that is not clear? >>>> >>> >>>> >>> d) What changes could be made to this proposal to make it more >>>> effective? >>>> >>> >>>> >>> Regards, >>>> >>> Vincent Ngundi & Darwin Da Costa >>>> >>> AFRINIC PDWG Co-Chairs >>>> >>> _______________________________________________ >>>> >>> RPD mailing list >>>> >>> RPD at afrinic.net >>>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>> >>>> >>> >>>> >>> -- >>>> >>> >>>> ------------------------------------------------------------------------ >>>> >>> Seun Ojedeji, >>>> >>> Bringing another down does not take you up - think about your >>>> action! >>>> >>> >>>> >>> _______________________________________________ >>>> >>> RPD mailing list >>>> >>> RPD at afrinic.net >>>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> >>>> ------------------------------------------------------------------------ >>>> >> Seun Ojedeji, >>>> >> Bringing another down does not take you up - think about your action! >>>> >> >>>> > >>>> > _______________________________________________ >>>> > RPD mailing list >>>> > RPD at afrinic.net >>>> > https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> >>> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > -- ------------------------------------------------------------------------ *Seun Ojedeji,* Bringing another down does not take you up - think about your action! -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjul.paul at gmail.com Wed Jun 24 06:59:57 2026 From: hjul.paul at gmail.com (Paul Hjul) Date: Wed, 24 Jun 2026 09:59:57 +0300 Subject: [rpd] Soft landing putting in writing amendment and objection Message-ID: Good morning, as presented at the PPM in person I am supportive of the proposal with amendment and object failing amendment. I believe for now 12 months would be acceptable and avoids debate at present with a view to reducing it to 3 months once the appropriate policy amendment kicks in. I understand that this will move the place of contention but doing so allows a focus on the right issues. Amendment proposed in bold and italic. Sent from venue on tablet (?) This section shall govern the manner in which AFRINIC assigns, allocates, and administers IPv4 resources during the ?Exhaustion Phase?, which phase shall commence upon AFRINIC first assigning or allocating IPv4 address space from the final /8 block of IPv4 resources available to it. Upon the commencement of any Soft-Landing exhaustion phase, such phase shall be deemed final and irreversible. Any IPv4 resources *finally *returned or recovered thereafter *in accordance with adopted community policy*, irrespective of their size or original pool, shall be returned to the ?available space? pool only following a quarantine period of twelve (12) months. AFRINIC may reduce the quarantine period, for example when ?available space? is below a /13 or other operational reasons. For clarity, ?available space? pool is the total addresses available, regardless of being from the last /8, or other blocks. In the event of any inconsistency or conflict between the provisions of the Soft-Landing framework and any other provision of the CPM relating to allocation criteria, the provisions of the Soft-Landing framework shall prevail to the extent of such inconsistency. *I am not proposing an amendment to the utilization section but rather pointing out that the policy presupposes this is properly handled in other policies* -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Wed Jun 24 07:18:26 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Wed, 24 Jun 2026 09:18:26 +0200 Subject: [rpd] Soft landing putting in writing amendment and objection In-Reply-To: References: Message-ID: Hi Paul, Tks for the inputs. I think we need to see a written description of the current staff procedure before further decisions. I don?t fully agree with the last input from Andrew. Somehow, staff procedures if they are well described, don?t need to become policies, otherwise, we move into an extreme-micro-management. I only see the need for that when the procedure is failing or the community don?t agree. Of course, it means the procedures should be clearly described somewhere. Now, regarding your proposed changes, I think the ?finally? seems ok to me. What I?m not sure if is this can be incorporated as part of editorial last call changes. To me yes, as it only provides clarity, not changes the intent. However, don?t agree in the need of the other change, because in the end, all the CPM is ?in accordance to adopted community policy?, not need to state that in every possible place of the manual. Regards, Jordi @jordipalet > El 24 jun 2026, a las 8:59, Paul Hjul escribi?: > > Good morning, as presented at the PPM in person I am supportive of the proposal with amendment and object failing amendment. > > I believe for now 12 months would be acceptable and avoids debate at present with a view to reducing it to 3 months once the appropriate policy amendment kicks in. > > I understand that this will move the place of contention but doing so allows a focus on the right issues. > > Amendment proposed in bold and italic. Sent from venue on tablet (?) > > > > > This section shall govern the manner in which AFRINIC assigns, allocates, and administers IPv4 resources during the ?Exhaustion Phase?, which phase shall commence upon AFRINIC first assigning or allocating IPv4 address space from the final /8 block of IPv4 resources available to it. > > Upon the commencement of any Soft-Landing exhaustion phase, such phase shall be deemed final and irreversible. Any IPv4 resources finally returned or recovered thereafter in accordance with adopted community policy, irrespective of their size or original pool, shall be returned to the ?available space? pool only following a quarantine period of twelve (12) months. AFRINIC may reduce the quarantine period, for example when ?available space? is below a /13 or other operational reasons. > > For clarity, ?available space? pool is the total addresses available, regardless of being from the last /8, or other blocks. > > In the event of any inconsistency or conflict between the provisions of the Soft-Landing framework and any other provision of the CPM relating to allocation criteria, the provisions of the Soft-Landing framework shall prevail to the extent of such inconsistency. > > > I am not proposing an amendment to the utilization section but rather pointing out that the policy presupposes this is properly handled in other policies > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Wed Jun 24 07:23:01 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Wed, 24 Jun 2026 09:23:01 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: Message-ID: <41504101-2AE2-4694-80E9-11F713E5B3AA@consulintel.es> Hi Seun, Musa, Responding once for both of you. In my slides I?ve 3 slides to respond to the points of the impact assestment. We can clarify all during the presentation. Regards, Jordi @jordipalet > El 24 jun 2026, a las 0:21, Seun Ojedeji escribi?: > > Hi Jordi, > > I understand it might be late to put in an updated draft, but it would be good to know how you plan to address the comments raised in the impact assessment > > Regards > > On Tue, 23 Jun 2026 at 16:25, Madhvi Gokool via RPD > wrote: >> Hello Stephen >> >> There seems to be an issue with the first version of the proposal on the website. We'll ensure it's fixed the soonest. >> >> Please note that the author submitted a revised version of the proposal - https://afrinic.net/participate/policy/proposals/afpub-2026-v6-001-draft02 and that the latter will be discussed during the AFRINIC-37 PPM. >> >> Kind Regards >> >> Madhvi >> >> Policy Liaison AFRINIC >> >> On 24/06/2026 00:25, Musa Stephen Honlue wrote: >>> >>> >>> >>> This is what the link is showing, please confirm that you have access. >>> >>>> On 28 May 2026, at 12:27, Sami Salih wrote: >>>> >>>> ? >>>> Hi Jordi, colleagues, >>>> >>>> Thank you, Jordi, for considering my previous comments and for restructuring this into a more focused proposal. >>>> >>>> In principle, I support linking IPv4 allocations under the Soft Landing policy with commitment toward IPv6 deployment. Given the IPv4 exhaustion reality, this is a reasonable policy direction. >>>> >>>> I also appreciate the additional clarifications regarding the existing policy references and deployment expectations. Nevertheless, I believe the implementation and enforcement aspects may still require further refinement to ensure the criteria remain objective, measurable, and operationally practical across the AFRINIC service region. I believe the staff analysis may further help clarify the operational feasibility, compliance verification approach, and enforcement practicality of the proposed requirements. >>>> >>>> Overall, I support the intent of the proposal and appreciate the more granular approach to the discussion. >>>> >>>> With Regards, >>>> Sami Salih. >>>> >>>> >>>> Sami Salih >>>> From: jordi.palet--- via RPD >>>> Sent: Thursday, May 28, 2026 1:21:52 PM >>>> To: rpd at afrinic.net >>>> Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. >>>> >>>> Hi Jaco, >>>> >>>> Tks, next version will use: ?Any IPv4 request must be done with a simultaneous IPv6 request if the requesting party does not already have IPv6 space.? This may depend on the impact analysis inputs, of course. >>>> >>>> About the determination/measurement that this is being done, let me explain how I see this. >>>> >>>> The existing 6.5.1.1 (for LIRs) and 6.8.2, already set the conditions to be met. AFRINIC already has, in both cases, a 12 months period to confirm the deployment. May be is not sufficiently clear there if AFRINIC should do something if that?s not actually done. We aren?t talking there only about announcing the prefix, but also in the case of LIRs, about making assignments to end-sites, and the text is clear, /48s, nothing different. There is no reason for using different sizes for different type of customers on that text. There is no technical reason at all for not doing it correctly, however, this is a discussion for amending that part of the policy, not for this proposal. >>>> >>>> What this proposal wants to make sure is that you *actually*, *following existing policy*, if you get IPv4, you really deploy IPv6 in 12 months. To reinforce it I explicitly mention ?In addition ??, as you said. Note that ?in addition? section enforces a more detailed work from the member requesting IPv4, to justify a credible IPv6 addressing and deployment plan, this will be accepted or not by AFRINIC, as with any request evaluation. >>>> >>>> For example, in many RIRs, not just AFRINIC, I?ve observed that many members get by default a /32, even if they have 800.000 end-sites. Clearly wrong, they didn?t have done any real addressing plan and they will end up providing a single /64 to each end-site. If they do it correctly, they will soon discover why they should use /48s, so with a /32 they can only cover around 50.000 customers, which means that typically for 800.000 of customers (depending on the topological distribution of the network) will mean that they need a /27-/28. >>>> >>>> I don?t think nobody can say ?deploy? is not clear. If this is the case, we can improve it, something like ?and IPv6 is actually being used?. We can even set a minimum level of traffic, such as 50% for example? Those that have deployed IPv6 know that, at least in the case of residential and cellular customers, because most of the traffic (typically 75-90%) is from big CDNs, caches, and contend providers (all google, all Meta, Akamai and all the other CDNs), already provide IPv6, when you turn on IPv6 in an end-site, the IPv6 traffic of that end-site becomes 75%-90% IPv6, in turn the total ISP traffic reaches similar levels. >>>> >>>> So asking for 50% seems to me conservative, but I?m happy for lower levels, if we agree that we can ask for more later on. We can even consider something like 25% after 12 months, 50% after 24 months, 75% after 48 months. Just an example. >>>> >>>> Finally, as we have many policies that AFRINIC not necessarily is measuring the compliance, that?s what the other proposal (compliance dashboard) was already trying to resolve, now in a ?light? version. >>>> >>>> This proposal also added a trigger (failure to comply) to ensure that abuse (requesting IPv4, but then not deploying IPv6) can enact the RSA terms, because clearly shows that there is a policy breach. >>>> >>>> By the way, dynamic prefixes in IPv6 is broken, terrible idea, specially if there are power outages. >>>> >>>> I suggest to read what, hopefully in a few months, will become in RFC/BCP a successor of RIPE690: >>>> >>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/ >>>> >>>> Regards, >>>> Jordi >>>> >>>> @jordipalet >>>> >>>> >>>>> El 28 may 2026, a las 11:43, Jaco Kroon escribi?: >>>>> >>>>> Hi Jordi, >>>>> >>>>> I support the principle very much. Practicality may be a different story, yes, must implement v6, however: >>>>> >>>>> How do you determine/measure that? I think your "In addition" section addresses this to a degree. >>>>> >>>>> Merely advertising IPv6 space? Sure, that's easy, but it doesn't mean I have to actually make that available to customers. >>>>> >>>>> Re proposed text, the word "However, " doesn't add value, merely "Any IPv4 request must be done with a simultaneous IPv6 request if the requesting party does not already have IPv6 space." >>>>> >>>>> This does also be the question, it seems 6.5.1.1.3 states that you must give /48s to end sites - we do distinguish between business and home users, for business we happily do /48 if so required (at least we reserve a /48 per site minimum), but for home users we generally do dynamically allocated /56 (but will again do /48 on request) - would this imply failure to comply with your proposed policy? If so, should the proposed policy be adjusted, or 6.5.1.1.3? >>>>> >>>>> For PI space (6.8.2.2.d) - what does deployed mean? >>>>> >>>>> Kind regards, >>>>> Jaco Kroon >>>>> >>>>> On 2026/05/28 10:28, jordi.palet--- via RPD wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Somehow this is a response to Sami input on a previous proposal. >>>>>> >>>>>> This way we can split the problem space in 2 proposals, which may reach consensus without depending one on the other. >>>>>> >>>>>> So we have a very basic question: If we believe that the members that receive IPv4 out of the Soft Landing policy, must implement IPv6, or not? >>>>>> >>>>>> Regards, >>>>>> Jordi >>>>>> >>>>>> @jordipalet >>>>>> >>>>>> >>>>>>> El 28 may 2026, a las 10:05, Darwin Da Costa escribi?: >>>>>>> >>>>>>> Dear PDWG, >>>>>>> >>>>>>> We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>>>>>> >>>>>>> https://afrinic.net/afpub-2026-v6-001-draft01 >>>>>>> >>>>>>> >>>>>>> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>>>>>> >>>>>>> a)Do you support or oppose the proposal? >>>>>>> >>>>>>> b) If you oppose the proposal, state your reasons? >>>>>>> >>>>>>> c) Is there anything in the proposal that is not clear? >>>>>>> >>>>>>> d) What changes could be made to this proposal to make it more effective? >>>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Vincent Ngundi & Darwin Da Costa >>>>>>> AFRINIC PDWG Co-Chairs >>>>>>> >>>>>>> _______________________________________________ >>>>>>> RPD mailing list >>>>>>> RPD at afrinic.net >>>>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>>> ********************************************** >>>>>> IPv4 is over >>>>>> Are you ready for the new Internet ? >>>>>> http://www.theipv6company.com >>>>>> The IPv6 Company >>>>>> >>>>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> RPD mailing list >>>>>> RPD at afrinic.net >>>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>>> >>>> ********************************************** >>>> IPv4 is over >>>> Are you ready for the new Internet ? >>>> http://www.theipv6company.com >>>> The IPv6 Company >>>> >>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > > > -- > ------------------------------------------------------------------------ > Seun Ojedeji, > Bringing another down does not take you up - think about your action! > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hytham at tra.gov.eg Wed Jun 24 07:27:15 2026 From: hytham at tra.gov.eg (Hytham El-Nakhal) Date: Wed, 24 Jun 2026 07:27:15 +0000 Subject: [rpd] [External] Soft landing putting in writing amendment and objection In-Reply-To: References: Message-ID: <1782286035184.66738@tra.gov.eg> Hi Pual, The utilization is well defined @ https://afrinic.net/ipv4-allocation-policy-afpub-2005-v4-001 Article 9.3 : 9.3 Utilisation Immediate utilisation of assignments should be at least 25% of the assigned space. After one year, unless special circumstances are defined, it should be at least 50%. Thanks, Haitham el Nakhal? ________________________________ From: Paul Hjul Sent: Wednesday, June 24, 2026 9:59 AM To: rpd-request at afrinic.net; rpd at afrinic.net; Darwin Costa Subject: [External] [rpd] Soft landing putting in writing amendment and objection Good morning, as presented at the PPM in person I am supportive of the proposal with amendment and object failing amendment. I believe for now 12 months would be acceptable and avoids debate at present with a view to reducing it to 3 months once the appropriate policy amendment kicks in. I understand that this will move the place of contention but doing so allows a focus on the right issues. Amendment proposed in bold and italic. Sent from venue on tablet (??) This section shall govern the manner in which AFRINIC assigns, allocates, and administers IPv4 resources during the "Exhaustion Phase", which phase shall commence upon AFRINIC first assigning or allocating IPv4 address space from the final /8 block of IPv4 resources available to it. Upon the commencement of any Soft-Landing exhaustion phase, such phase shall be deemed final and irreversible. Any IPv4 resources finally returned or recovered thereafter in accordance with adopted community policy, irrespective of their size or original pool, shall be returned to the "available space" pool only following a quarantine period of twelve (12) months. AFRINIC may reduce the quarantine period, for example when "available space" is below a /13 or other operational reasons. For clarity, "available space" pool is the total addresses available, regardless of being from the last /8, or other blocks. In the event of any inconsistency or conflict between the provisions of the Soft-Landing framework and any other provision of the CPM relating to allocation criteria, the provisions of the Soft-Landing framework shall prevail to the extent of such inconsistency. I am not proposing an amendment to the utilization section but rather pointing out that the policy presupposes this is properly handled in other policies From mark at posix.co.za Wed Jun 24 08:29:03 2026 From: mark at posix.co.za (Mark Elkins) Date: Wed, 24 Jun 2026 10:29:03 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: <99A91520-5FF1-4924-A200-C593A3EA520C@gmail.com> References: <2C5FDE82-7BCC-4763-BAA5-3D0AC8EA1CFF@gmail.com> <99A91520-5FF1-4924-A200-C593A3EA520C@gmail.com> Message-ID: Dear Musa?Stephen Honlue, I disagree with your viewpoint and can see that in the future some resource members muttering that "nobody told us we had to have IPv6 - why didn't AFRINIC enforce it?" Personally, I want AFRINIC to make sure all resource members have IPv6 the change that to all IPv6 resource holders need to make their space visible then one day insist that all communications with AFRINIC is over IPv6 and AFRINIC somewhat terminates access via IPv4. Harsh, I know, but IPv6 is cheaper and more efficient to run than IPv4... Step by step - and this is a good step. On 2026/06/24 00:20, Musa Stephen Honlue wrote: > > Dear Jordi > > I would like to express my opposition to this proposal in its current > form. > > While I fully support the objective of increasing IPv6 deployment > across the AFRINIC service region, I do not believe that the problem > statement and the proposed solution adequately justify the measures > being introduced. > > First, I believe the problem statement is inappropriately framed. The > proposal relies heavily on comparisons between Africa and other > regions of the world, suggesting that Africa?s lower IPv6 deployment > rate is, by itself, evidence that stronger policy intervention is > required. I do not think this is a useful basis for policy development. > > The AFRINIC community should not be comparing itself to other regions > from a technological adoption perspective. There are numerous > economic, infrastructural, educational, and operational factors that > influence IPv6 deployment across different regions. The fact that > Africa has lower IPv6 deployment than other regions does not > automatically indicate a policy failure. > > Furthermore, after more than 25 years of IPv6 availability, even the > regions often considered technologically advanced are still reporting > deployment levels that are far from complete. If the reported global > capability is approximately 44%, this demonstrates that IPv6 adoption > remains a challenge worldwide and not exclusively within Africa. > > If the objective is to highlight low IPv6 deployment within the > AFRINIC service region, the problem statement should focus on that > issue directly and objectively, without relying on comparisons with > other regions. Any benchmarking should be done carefully and within > relevant peer groups rather than presenting Africa as lagging behind > the rest of the world. > > Second, I am concerned that the proposal moves AFRINIC beyond its > traditional role as a registry and into the role of an operational > regulator. > > The primary function of an RIR is the fair and efficient management > and registration of Internet number resources. This proposal goes > significantly further by attempting to regulate how networks deploy > IPv6, how quickly they deploy it, what percentage of traffic should > use it, and what percentage of services should be reachable over it. > > Such requirements extend beyond resource registration and enter the > realm of network operations and business decisions. I do not believe > this falls within the intended scope of RIR policy. > > Third, the proposed compliance criteria appear difficult to evaluate > objectively. > > For example, the proposal requires networks to demonstrate specific > percentages of IPv6 traffic to their top-25 external destinations. It > is unclear: > > * How these destinations will be identified and measured; > * Over what period measurements will be taken; > * How AFRINIC staff will independently verify the information provided; > * How compliance will be assessed when traffic patterns change over > time. > > In addition, network operators do not control whether external > destinations support IPv6, nor do they fully control the applications > and services used by their customers. As a result, the proposed > traffic thresholds may not accurately reflect the deployment efforts > undertaken by the resource holder. > > Similarly, evaluating IPv6 reachability through percentages of AAAA > records and service availability introduces a high degree of > subjectivity. Different networks host different types of services, > operate different architectures, and face different technical > constraints. A single set of percentages may not be appropriate across > all deployment scenarios. > > Finally, I am particularly concerned by the statement that failure to > comply with the IPv6 deployment plan constitutes a policy violation. > > An organization may make genuine efforts to deploy IPv6 and still fail > to meet prescribed percentages due to factors outside its control. > Turning such outcomes into policy violations creates uncertainty and > potentially disproportionate consequences for resource holders. > > I would support measures that encourage IPv6 adoption, such as > requiring organizations requesting IPv4 resources to also obtain IPv6 > resources if they do not already have them, or requiring applicants to > submit an IPv6 deployment plan. However, I do not support introducing > operational deployment targets, traffic thresholds, service > reachability metrics, and compliance enforcement mechanisms that move > beyond AFRINIC?s core registration function. > > For these reasons, I oppose the proposal in its current form. > >> >> On 23 Jun 2026, at 23:45, Musa Stephen Honlue wrote: >> >> ? Thank you Madhvi. >> >>> >>> On 23 Jun 2026, at 23:25, Madhvi Gokool wrote: >>> >>> ? >>> >>> Hello Stephen >>> >>> There seems to be an issue with the first version of the proposal on >>> the website. We'll ensure it's fixed the soonest. >>> >>> Please note that the author submitted a revised version of the >>> proposal - >>> https://afrinic.net/participate/policy/proposals/afpub-2026-v6-001-draft02 >>> and that the latter will be discussed during the AFRINIC-37 PPM. >>> >>> Kind Regards >>> >>> Madhvi >>> >>> Policy Liaison AFRINIC >>> >>> On 24/06/2026 00:25, Musa Stephen Honlue wrote: >>>> >>>> >>>> >>>> >>>> This is what the link is showing, please confirm that you have access. >>>> >>>>> On 28 May 2026, at 12:27, Sami Salih wrote: >>>>> >>>>> ? >>>>> Hi Jordi, colleagues, >>>>> >>>>> Thank you, Jordi, for considering my previous comments and for >>>>> restructuring this into a more focused proposal. >>>>> >>>>> In principle, I support linking IPv4 allocations under the Soft >>>>> Landing policy with commitment toward IPv6 deployment. Given the >>>>> IPv4 exhaustion reality, this is a reasonable policy direction. >>>>> >>>>> I also appreciate the additional clarifications regarding the >>>>> existing policy references and deployment expectations. >>>>> Nevertheless, I believe the implementation and enforcement aspects >>>>> may still require further refinement to ensure the criteria remain >>>>> objective, measurable, and operationally practical across the >>>>> AFRINIC service region. I believe the staff analysis may further >>>>> help clarify the operational feasibility, compliance verification >>>>> approach, and enforcement practicality of the proposed requirements. >>>>> >>>>> Overall, I support the intent of the proposal and appreciate the >>>>> more granular approach to the discussion. >>>>> >>>>> With Regards, >>>>> Sami Salih. >>>>> >>>>> >>>>> Sami Salih >>>>> ------------------------------------------------------------------------ >>>>> *From:* jordi.palet--- via RPD >>>>> *Sent:* Thursday, May 28, 2026 1:21:52 PM >>>>> *To:* rpd at afrinic.net >>>>> *Subject:* Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing >>>>> AFPUB-2026-v6-001-DRAFT01. >>>>> Hi Jaco, >>>>> >>>>> Tks, next version will use: ?Any IPv4 request must be done with a >>>>> simultaneous IPv6 request if the requesting party does not already >>>>> have IPv6 space.? This may depend on the impact analysis inputs, >>>>> of course. >>>>> >>>>> About the determination/measurement that this is being done, let >>>>> me explain how I see this. >>>>> >>>>> The existing 6.5.1.1 (for LIRs) and 6.8.2, already set the >>>>> conditions to be met. AFRINIC already has, in both cases, a 12 >>>>> months period to confirm the deployment. May be is not >>>>> sufficiently clear there if AFRINIC should do something if that?s >>>>> not actually done. We aren?t talking there only about announcing >>>>> the prefix, but also in the case of LIRs, about making assignments >>>>> to end-sites, and the text is clear, /48s, nothing different. >>>>> There is no reason for using different sizes for different type of >>>>> customers on that text. There is no technical reason at all for >>>>> not doing it correctly, however, this is a discussion for amending >>>>> that part of the policy, not for this proposal. >>>>> >>>>> What this proposal wants to make sure is that you *actually*, >>>>> *following existing policy*, if you get IPv4, you really deploy >>>>> IPv6 in 12 months. To reinforce it I explicitly mention ?In >>>>> addition ??, as you said. Note that ?in addition? section enforces >>>>> a more detailed work from the member requesting IPv4, to justify a >>>>> credible IPv6 addressing and deployment plan, this will be >>>>> accepted or not by AFRINIC, as with any request evaluation. >>>>> >>>>> For example, in many RIRs, not just AFRINIC, I?ve observed that >>>>> many members get by default a /32, even if they have 800.000 >>>>> end-sites. Clearly wrong, they didn?t have done any real >>>>> addressing plan and they will end up providing a single /64 to >>>>> each end-site. If they do it correctly, they will soon discover >>>>> why they should use /48s, so with a /32 they can only cover around >>>>> 50.000 customers, which means that typically for 800.000 of >>>>> customers (depending on the topological distribution of the >>>>> network) will mean that they need a /27-/28. >>>>> >>>>> I don?t think nobody can say ?deploy? is not clear. If this is the >>>>> case, we can improve it, something like ?and IPv6 is actually >>>>> being used?. We can even set a minimum level of traffic, such as >>>>> 50% for example? Those that have deployed IPv6 know that, at least >>>>> in the case of residential and cellular customers, because most of >>>>> the traffic (typically 75-90%) is from big CDNs, caches, and >>>>> contend providers (all google, all Meta, Akamai and all the other >>>>> CDNs), already provide IPv6, when you turn on IPv6 in an end-site, >>>>> the IPv6 traffic of that end-site becomes 75%-90% IPv6, in turn >>>>> the total ISP traffic reaches similar levels. >>>>> >>>>> So asking for 50% seems to me conservative, but I?m happy for >>>>> lower levels, if we agree that we can ask for more later on. We >>>>> can even consider something like 25% after 12 months, 50% after 24 >>>>> months, 75% after 48 months. Just an example. >>>>> >>>>> Finally, as we have many policies that AFRINIC not necessarily is >>>>> measuring the compliance, that?s what the other proposal >>>>> (compliance dashboard) was already trying to resolve, now in a >>>>> ?light? version. >>>>> >>>>> This proposal also added a trigger (failure to comply) to ensure >>>>> that abuse (requesting IPv4, but then not deploying IPv6) can >>>>> enact the RSA terms, because clearly shows that there is a policy >>>>> breach. >>>>> >>>>> By the way, dynamic prefixes in IPv6 is broken, terrible idea, >>>>> specially if there are power outages. >>>>> >>>>> I suggest to read what, hopefully in a few months, will become in >>>>> RFC/BCP a successor of RIPE690: >>>>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/ >>>>> >>>>> Regards, >>>>> Jordi >>>>> >>>>> @jordipalet >>>>> >>>>> >>>>>> El 28 may 2026, a las 11:43, Jaco Kroon escribi?: >>>>>> >>>>>> Hi Jordi, >>>>>> >>>>>> I support the principle very much. Practicality may be a >>>>>> different story, yes, must implement v6, however: >>>>>> >>>>>> How do you determine/measure that? I think your "In addition" >>>>>> section addresses this to a degree. >>>>>> >>>>>> Merely advertising IPv6 space? Sure, that's easy, but it doesn't >>>>>> mean I have to actually make that available to customers. >>>>>> >>>>>> Re proposed text, the word "However, " doesn't add value, merely >>>>>> "Any IPv4 request must be done with a simultaneous IPv6 request >>>>>> if the requesting party does not already have IPv6 space." >>>>>> >>>>>> This does also be the question, it seems 6.5.1.1.3 states that >>>>>> you must give /48s to end sites - we do distinguish between >>>>>> business and home users, for business we happily do /48 if so >>>>>> required (at least we reserve a /48 per site minimum), but for >>>>>> home users we generally do dynamically allocated /56 (but will >>>>>> again do /48 on request) - would this imply failure to comply >>>>>> with your proposed policy?? If so, should the proposed policy be >>>>>> adjusted, or 6.5.1.1.3? >>>>>> >>>>>> For PI space (6.8.2.2.d) - what does deployed mean? >>>>>> >>>>>> Kind regards, >>>>>> Jaco Kroon >>>>>> >>>>>> On 2026/05/28 10:28, jordi.palet--- via RPD wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> Somehow this is a response to Sami input on a previous proposal. >>>>>>> >>>>>>> This way we can split the problem space in 2 proposals, which may reach consensus without depending one on the other. >>>>>>> >>>>>>> So we have a very basic question: If we believe that the members that receive IPv4 out of the Soft Landing policy, must implement IPv6, or not? >>>>>>> >>>>>>> Regards, >>>>>>> Jordi >>>>>>> >>>>>>> @jordipalet >>>>>>> >>>>>>> >>>>>>>> El 28 may 2026, a las 10:05, Darwin Da Costa escribi?: >>>>>>>> >>>>>>>> Dear PDWG, >>>>>>>> >>>>>>>> We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>>>>>>> >>>>>>>> https://afrinic.net/afpub-2026-v6-001-draft01 >>>>>>>> >>>>>>>> >>>>>>>> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>>>>>>> >>>>>>>> a)Do you support or oppose the proposal? >>>>>>>> >>>>>>>> b) If you oppose the proposal, state your reasons? >>>>>>>> >>>>>>>> c) Is there anything in the proposal that is not clear? >>>>>>>> >>>>>>>> d) What changes could be made to this proposal to make it more effective? >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Vincent Ngundi & Darwin Da Costa >>>>>>>> AFRINIC PDWG Co-Chairs >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> RPD mailing list >>>>>>>> RPD at afrinic.net >>>>>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>>>> ********************************************** >>>>>>> IPv4 is over >>>>>>> Are you ready for the new Internet ? >>>>>>> http://www.theipv6company.com >>>>>>> The IPv6 Company >>>>>>> >>>>>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> RPD mailing list >>>>>>> RPD at afrinic.net >>>>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>> >>>>> >>>>> ********************************************** >>>>> IPv4 is over >>>>> Are you ready for the new Internet ? >>>>> http://www.theipv6company.com >>>>> The IPv6 Company >>>>> >>>>> This electronic message contains information which may be >>>>> privileged or confidential. The information is intended to be for >>>>> the exclusive use of the individual(s) named above and further >>>>> non-explicilty authorized disclosure, copying, distribution or use >>>>> of the contents of this information, even if partially, including >>>>> attached files, is strictly prohibited and will be considered a >>>>> criminal offense. If you are not the intended recipient be aware >>>>> that any disclosure, copying, distribution or use of the contents >>>>> of this information, even if partially, including attached files, >>>>> is strictly prohibited, will be considered a criminal offense, so >>>>> you must reply to the original sender to inform about this >>>>> communication and delete it. >>>>> >>>>> _______________________________________________ >>>>> RPD mailing list >>>>> RPD at afrinic.net >>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -- Mark James ELKINS? -? Posix Systems - (South) Africa mje at posix.co.za?????? Tel: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za Posix SystemsVCARD for MJ Elkins -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: abessive_logo.jpg Type: image/jpeg Size: 6410 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: QR-MJElkins.png Type: image/png Size: 2163 bytes Desc: not available URL: From honlue at gmail.com Wed Jun 24 13:43:29 2026 From: honlue at gmail.com (Musa Stephen Honlue) Date: Wed, 24 Jun 2026 15:43:29 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: Message-ID: <62C7A878-5533-46BE-8B44-BD8651F574E1@gmail.com> An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Wed Jun 24 15:13:31 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Wed, 24 Jun 2026 17:13:31 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: <62C7A878-5533-46BE-8B44-BD8651F574E1@gmail.com> References: <62C7A878-5533-46BE-8B44-BD8651F574E1@gmail.com> Message-ID: Hi Musa, I don?t agree in your understanding of the AFRINIC function. In the policies we already do a kind of ?regulation?. If you get IPv4, ASN or IPv6 resources, and you don?t follow the rules, the resources can be reclaimed. If you don?t set RDNS, the resources can be reclaimed. If you don?t correctly manage the whois, register the relevant contacts, including abuse-c, etc. the resources can be reclaimed. This is on top of policies, because the RSA already obligate members to follow the policies. So there is no difference in now setting a policy that clearly say, you get more IPv4, but you must also deploy IPv6. We could also do something slightly different, I?m not sure if this is what Seun tried to say in the mic earlier this afternoon. We don?t give any more IPv4 resources if you already got them previously. This has been done by most of the other RIRs. Will you agree with that? Only newcomers can get IPv4. Now, as a 2nd part of the proposal, resources left (even recovered), can be provided to anyone who also deploy IPv6, regardless of being a newcomer or an existing member. What do you think? Regards, Jordi @jordipalet > El 24 jun 2026, a las 15:43, Musa Stephen Honlue escribi?: > > > Thank you Mark for your response. > > I would like to clarify that my opposition is not to IPv6 deployment itself. I fully support wider IPv6 adoption across the AFRINIC service region and agree that organizations should be encouraged to deploy and actively use the IPv6 resources they receive. I have been training and supporting engineers on the deployment of IPv6 and other technologies. > > Where I differ is on the role that AFRINIC policy should play in achieving that objective. > > Your suggestion that AFRINIC should eventually require IPv6-only interactions with AFRINIC services is an operational decision that AFRINIC may choose to make for its own infrastructure and services. However, the proposal under discussion goes much further by prescribing how resource holders should deploy IPv6 within their own networks and by attaching compliance obligations to operational outcomes. > > My concern is that this moves AFRINIC from managing and registering number resources into regulating network operations. Whether IPv6 is cheaper, more efficient, or technically preferable does not automatically mean that deployment targets, traffic ratios, service reachability percentages, and compliance enforcement belong in resource management policy. > > I also do not believe that making IPv6 deployment a policy compliance matter is the right solution to the concern that some members may later claim they were not encouraged to adopt IPv6. AFRINIC already allocates IPv6 resources, provides training, conducts outreach, and can require applicants to demonstrate IPv6 planning as part of resource requests. These are measures that encourage adoption without attempting to regulate operational implementation. > > In my view, there is a significant difference between encouraging IPv6 deployment and enforcing specific deployment outcomes. I support the former, but I remain unconvinced that the latter falls within the appropriate scope of AFRINIC policy. > > > >> On 24 Jun 2026, at 10:30, Mark Elkins via RPD wrote: >> >> ? >> Dear Musa Stephen Honlue, >> >> I disagree with your viewpoint and can see that in the future some resource members muttering that "nobody told us we had to have IPv6 - why didn't AFRINIC enforce it?" >> Personally, I want AFRINIC to make sure all resource members have IPv6 the change that to all IPv6 resource holders need to make their space visible then one day insist that all communications with AFRINIC is over IPv6 and AFRINIC somewhat terminates access via IPv4. Harsh, I know, but IPv6 is cheaper and more efficient to run than IPv4... Step by step - and this is a good step. >> >> On 2026/06/24 00:20, Musa Stephen Honlue wrote: >>> Dear Jordi >>> >>> I would like to express my opposition to this proposal in its current form. >>> >>> While I fully support the objective of increasing IPv6 deployment across the AFRINIC service region, I do not believe that the problem statement and the proposed solution adequately justify the measures being introduced. >>> >>> First, I believe the problem statement is inappropriately framed. The proposal relies heavily on comparisons between Africa and other regions of the world, suggesting that Africa?s lower IPv6 deployment rate is, by itself, evidence that stronger policy intervention is required. I do not think this is a useful basis for policy development. >>> >>> The AFRINIC community should not be comparing itself to other regions from a technological adoption perspective. There are numerous economic, infrastructural, educational, and operational factors that influence IPv6 deployment across different regions. The fact that Africa has lower IPv6 deployment than other regions does not automatically indicate a policy failure. >>> >>> Furthermore, after more than 25 years of IPv6 availability, even the regions often considered technologically advanced are still reporting deployment levels that are far from complete. If the reported global capability is approximately 44%, this demonstrates that IPv6 adoption remains a challenge worldwide and not exclusively within Africa. >>> >>> If the objective is to highlight low IPv6 deployment within the AFRINIC service region, the problem statement should focus on that issue directly and objectively, without relying on comparisons with other regions. Any benchmarking should be done carefully and within relevant peer groups rather than presenting Africa as lagging behind the rest of the world. >>> >>> Second, I am concerned that the proposal moves AFRINIC beyond its traditional role as a registry and into the role of an operational regulator. >>> >>> The primary function of an RIR is the fair and efficient management and registration of Internet number resources. This proposal goes significantly further by attempting to regulate how networks deploy IPv6, how quickly they deploy it, what percentage of traffic should use it, and what percentage of services should be reachable over it. >>> >>> Such requirements extend beyond resource registration and enter the realm of network operations and business decisions. I do not believe this falls within the intended scope of RIR policy. >>> >>> Third, the proposed compliance criteria appear difficult to evaluate objectively. >>> >>> For example, the proposal requires networks to demonstrate specific percentages of IPv6 traffic to their top-25 external destinations. It is unclear: >>> >>> How these destinations will be identified and measured; >>> Over what period measurements will be taken; >>> How AFRINIC staff will independently verify the information provided; >>> How compliance will be assessed when traffic patterns change over time. >>> In addition, network operators do not control whether external destinations support IPv6, nor do they fully control the applications and services used by their customers. As a result, the proposed traffic thresholds may not accurately reflect the deployment efforts undertaken by the resource holder. >>> >>> Similarly, evaluating IPv6 reachability through percentages of AAAA records and service availability introduces a high degree of subjectivity. Different networks host different types of services, operate different architectures, and face different technical constraints. A single set of percentages may not be appropriate across all deployment scenarios. >>> >>> Finally, I am particularly concerned by the statement that failure to comply with the IPv6 deployment plan constitutes a policy violation. >>> >>> An organization may make genuine efforts to deploy IPv6 and still fail to meet prescribed percentages due to factors outside its control. Turning such outcomes into policy violations creates uncertainty and potentially disproportionate consequences for resource holders. >>> >>> I would support measures that encourage IPv6 adoption, such as requiring organizations requesting IPv4 resources to also obtain IPv6 resources if they do not already have them, or requiring applicants to submit an IPv6 deployment plan. However, I do not support introducing operational deployment targets, traffic thresholds, service reachability metrics, and compliance enforcement mechanisms that move beyond AFRINIC?s core registration function. >>> >>> For these reasons, I oppose the proposal in its current form. >>> >>>> >>>> On 23 Jun 2026, at 23:45, Musa Stephen Honlue wrote: >>>> >>>> ? Thank you Madhvi. >>>> >>>>> >>>>> On 23 Jun 2026, at 23:25, Madhvi Gokool wrote: >>>>> >>>>> ? >>>>> Hello Stephen >>>>> >>>>> There seems to be an issue with the first version of the proposal on the website. We'll ensure it's fixed the soonest. >>>>> >>>>> Please note that the author submitted a revised version of the proposal - https://afrinic.net/participate/policy/proposals/afpub-2026-v6-001-draft02 and that the latter will be discussed during the AFRINIC-37 PPM. >>>>> >>>>> Kind Regards >>>>> >>>>> Madhvi >>>>> >>>>> Policy Liaison AFRINIC >>>>> >>>>> On 24/06/2026 00:25, Musa Stephen Honlue wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> This is what the link is showing, please confirm that you have access. >>>>>> >>>>>>> On 28 May 2026, at 12:27, Sami Salih wrote: >>>>>>> >>>>>>> ? >>>>>>> Hi Jordi, colleagues, >>>>>>> >>>>>>> Thank you, Jordi, for considering my previous comments and for restructuring this into a more focused proposal. >>>>>>> >>>>>>> In principle, I support linking IPv4 allocations under the Soft Landing policy with commitment toward IPv6 deployment. Given the IPv4 exhaustion reality, this is a reasonable policy direction. >>>>>>> >>>>>>> I also appreciate the additional clarifications regarding the existing policy references and deployment expectations. Nevertheless, I believe the implementation and enforcement aspects may still require further refinement to ensure the criteria remain objective, measurable, and operationally practical across the AFRINIC service region. I believe the staff analysis may further help clarify the operational feasibility, compliance verification approach, and enforcement practicality of the proposed requirements. >>>>>>> >>>>>>> Overall, I support the intent of the proposal and appreciate the more granular approach to the discussion. >>>>>>> >>>>>>> With Regards, >>>>>>> Sami Salih. >>>>>>> >>>>>>> >>>>>>> Sami Salih >>>>>>> From: jordi.palet--- via RPD >>>>>>> Sent: Thursday, May 28, 2026 1:21:52 PM >>>>>>> To: rpd at afrinic.net >>>>>>> Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. >>>>>>> >>>>>>> Hi Jaco, >>>>>>> >>>>>>> Tks, next version will use: ?Any IPv4 request must be done with a simultaneous IPv6 request if the requesting party does not already have IPv6 space.? This may depend on the impact analysis inputs, of course. >>>>>>> >>>>>>> About the determination/measurement that this is being done, let me explain how I see this. >>>>>>> >>>>>>> The existing 6.5.1.1 (for LIRs) and 6.8.2, already set the conditions to be met. AFRINIC already has, in both cases, a 12 months period to confirm the deployment. May be is not sufficiently clear there if AFRINIC should do something if that?s not actually done. We aren?t talking there only about announcing the prefix, but also in the case of LIRs, about making assignments to end-sites, and the text is clear, /48s, nothing different. There is no reason for using different sizes for different type of customers on that text. There is no technical reason at all for not doing it correctly, however, this is a discussion for amending that part of the policy, not for this proposal. >>>>>>> >>>>>>> What this proposal wants to make sure is that you *actually*, *following existing policy*, if you get IPv4, you really deploy IPv6 in 12 months. To reinforce it I explicitly mention ?In addition ??, as you said. Note that ?in addition? section enforces a more detailed work from the member requesting IPv4, to justify a credible IPv6 addressing and deployment plan, this will be accepted or not by AFRINIC, as with any request evaluation. >>>>>>> >>>>>>> For example, in many RIRs, not just AFRINIC, I?ve observed that many members get by default a /32, even if they have 800.000 end-sites. Clearly wrong, they didn?t have done any real addressing plan and they will end up providing a single /64 to each end-site. If they do it correctly, they will soon discover why they should use /48s, so with a /32 they can only cover around 50.000 customers, which means that typically for 800.000 of customers (depending on the topological distribution of the network) will mean that they need a /27-/28. >>>>>>> >>>>>>> I don?t think nobody can say ?deploy? is not clear. If this is the case, we can improve it, something like ?and IPv6 is actually being used?. We can even set a minimum level of traffic, such as 50% for example? Those that have deployed IPv6 know that, at least in the case of residential and cellular customers, because most of the traffic (typically 75-90%) is from big CDNs, caches, and contend providers (all google, all Meta, Akamai and all the other CDNs), already provide IPv6, when you turn on IPv6 in an end-site, the IPv6 traffic of that end-site becomes 75%-90% IPv6, in turn the total ISP traffic reaches similar levels. >>>>>>> >>>>>>> So asking for 50% seems to me conservative, but I?m happy for lower levels, if we agree that we can ask for more later on. We can even consider something like 25% after 12 months, 50% after 24 months, 75% after 48 months. Just an example. >>>>>>> >>>>>>> Finally, as we have many policies that AFRINIC not necessarily is measuring the compliance, that?s what the other proposal (compliance dashboard) was already trying to resolve, now in a ?light? version. >>>>>>> >>>>>>> This proposal also added a trigger (failure to comply) to ensure that abuse (requesting IPv4, but then not deploying IPv6) can enact the RSA terms, because clearly shows that there is a policy breach. >>>>>>> >>>>>>> By the way, dynamic prefixes in IPv6 is broken, terrible idea, specially if there are power outages. >>>>>>> >>>>>>> I suggest to read what, hopefully in a few months, will become in RFC/BCP a successor of RIPE690: >>>>>>> >>>>>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/ >>>>>>> >>>>>>> Regards, >>>>>>> Jordi >>>>>>> >>>>>>> @jordipalet >>>>>>> >>>>>>> >>>>>>>> El 28 may 2026, a las 11:43, Jaco Kroon escribi?: >>>>>>>> >>>>>>>> Hi Jordi, >>>>>>>> >>>>>>>> I support the principle very much. Practicality may be a different story, yes, must implement v6, however: >>>>>>>> >>>>>>>> How do you determine/measure that? I think your "In addition" section addresses this to a degree. >>>>>>>> >>>>>>>> Merely advertising IPv6 space? Sure, that's easy, but it doesn't mean I have to actually make that available to customers. >>>>>>>> >>>>>>>> Re proposed text, the word "However, " doesn't add value, merely "Any IPv4 request must be done with a simultaneous IPv6 request if the requesting party does not already have IPv6 space." >>>>>>>> >>>>>>>> This does also be the question, it seems 6.5.1.1.3 states that you must give /48s to end sites - we do distinguish between business and home users, for business we happily do /48 if so required (at least we reserve a /48 per site minimum), but for home users we generally do dynamically allocated /56 (but will again do /48 on request) - would this imply failure to comply with your proposed policy? If so, should the proposed policy be adjusted, or 6.5.1.1.3? >>>>>>>> >>>>>>>> For PI space (6.8.2.2.d) - what does deployed mean? >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> Jaco Kroon >>>>>>>> >>>>>>>> On 2026/05/28 10:28, jordi.palet--- via RPD wrote: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> Somehow this is a response to Sami input on a previous proposal. >>>>>>>>> >>>>>>>>> This way we can split the problem space in 2 proposals, which may reach consensus without depending one on the other. >>>>>>>>> >>>>>>>>> So we have a very basic question: If we believe that the members that receive IPv4 out of the Soft Landing policy, must implement IPv6, or not? >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Jordi >>>>>>>>> >>>>>>>>> @jordipalet >>>>>>>>> >>>>>>>>> >>>>>>>>>> El 28 may 2026, a las 10:05, Darwin Da Costa escribi?: >>>>>>>>>> >>>>>>>>>> Dear PDWG, >>>>>>>>>> >>>>>>>>>> We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>>>>>>>>> >>>>>>>>>> https://afrinic.net/afpub-2026-v6-001-draft01 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>>>>>>>>> >>>>>>>>>> a)Do you support or oppose the proposal? >>>>>>>>>> >>>>>>>>>> b) If you oppose the proposal, state your reasons? >>>>>>>>>> >>>>>>>>>> c) Is there anything in the proposal that is not clear? >>>>>>>>>> >>>>>>>>>> d) What changes could be made to this proposal to make it more effective? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Vincent Ngundi & Darwin Da Costa >>>>>>>>>> AFRINIC PDWG Co-Chairs >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> RPD mailing list >>>>>>>>>> RPD at afrinic.net >>>>>>>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>>>>>> ********************************************** >>>>>>>>> IPv4 is over >>>>>>>>> Are you ready for the new Internet ? >>>>>>>>> http://www.theipv6company.com >>>>>>>>> The IPv6 Company >>>>>>>>> >>>>>>>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> RPD mailing list >>>>>>>>> RPD at afrinic.net >>>>>>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>>>> >>>>>>> >>>>>>> ********************************************** >>>>>>> IPv4 is over >>>>>>> Are you ready for the new Internet ? >>>>>>> http://www.theipv6company.com >>>>>>> The IPv6 Company >>>>>>> >>>>>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> RPD mailing list >>>>>>> RPD at afrinic.net >>>>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> RPD mailing list >>>>>> RPD at afrinic.net >>>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> -- >> Mark James ELKINS - Posix Systems - (South) Africa >> mje at posix.co.za Tel: +27.826010496 >> For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za >> >> >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From seun.ojedeji at gmail.com Thu Jun 25 00:37:48 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Thu, 25 Jun 2026 03:37:48 +0300 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: <62C7A878-5533-46BE-8B44-BD8651F574E1@gmail.com> Message-ID: Hi Jordi, ---- Sent from my mobile kindly excuse typos On Wed, 24 Jun 2026, 6:14?pm jordi.palet--- via RPD, wrote: > . > > So there is no difference in now setting a policy that clearly say, you > get more IPv4, but you must also deploy IPv6. > > We could also do something slightly different, I?m not sure if this is > what Seun tried to say in the mic earlier this afternoon. > > We don?t give any more IPv4 resources if you already got them previously. > This has been done by most of the other RIRs. Will you agree with that? > Only newcomers can get IPv4. > SO: More like you don't get IPv4 resources if you already got it for X number of times in the current phase unless you meet the IPv6 deployment plan requirements. My intention is for X not !=Once Regards > > Now, as a 2nd part of the proposal, resources left (even recovered), can > be provided to anyone who also deploy IPv6, regardless of being a newcomer > or an existing member. > > What do you think? > > Regards, > Jordi > > @jordipalet > > El 24 jun 2026, a las 15:43, Musa Stephen Honlue > escribi?: > > > Thank you Mark for your response. > > I would like to clarify that my opposition is not to IPv6 deployment > itself. I fully support wider IPv6 adoption across the AFRINIC service > region and agree that organizations should be encouraged to deploy and > actively use the IPv6 resources they receive. I have been training and > supporting engineers on the deployment of IPv6 and other technologies. > > *Where I differ is on the role that AFRINIC policy should play in > achieving that objective.* > > Your suggestion that AFRINIC should eventually require IPv6-only > interactions with AFRINIC services is an operational decision that AFRINIC > may choose to make for its own infrastructure and services. However, the > proposal under discussion goes much further by prescribing how resource > holders should deploy IPv6 within their own networks and by attaching > compliance obligations to operational outcomes. > > My concern is that this moves AFRINIC from managing and registering number > resources into regulating network operations. Whether IPv6 is cheaper, more > efficient, or technically preferable does not automatically mean that > deployment targets, traffic ratios, service reachability percentages, and > compliance enforcement belong in resource management policy. > > I also do not believe that making IPv6 deployment a policy compliance > matter is the right solution to the concern that some members may later > claim they were not encouraged to adopt IPv6. AFRINIC already allocates > IPv6 resources, provides training, conducts outreach, and can require > applicants to demonstrate IPv6 planning as part of resource requests. These > are measures that encourage adoption without attempting to regulate > operational implementation. > > In my view, there is a significant difference between encouraging IPv6 > deployment and enforcing specific deployment outcomes. I support the > former, but I remain unconvinced that the latter falls within the > appropriate scope of AFRINIC policy. > > > On 24 Jun 2026, at 10:30, Mark Elkins via RPD wrote: > > ? > > Dear Musa Stephen Honlue, > > I disagree with your viewpoint and can see that in the future some > resource members muttering that "nobody told us we had to have IPv6 - why > didn't AFRINIC enforce it?" > Personally, I want AFRINIC to make sure all resource members have IPv6 the > change that to all IPv6 resource holders need to make their space visible > then one day insist that all communications with AFRINIC is over IPv6 and > AFRINIC somewhat terminates access via IPv4. Harsh, I know, but IPv6 is > cheaper and more efficient to run than IPv4... Step by step - and this is a > good step. > On 2026/06/24 00:20, Musa Stephen Honlue wrote: > > Dear Jordi > > I would like to express my opposition to this proposal in its current form. > > While I fully support the objective of increasing IPv6 deployment across > the AFRINIC service region, I do not believe that the problem statement and > the proposed solution adequately justify the measures being introduced. > > First, I believe the problem statement is inappropriately framed. The > proposal relies heavily on comparisons between Africa and other regions of > the world, suggesting that Africa?s lower IPv6 deployment rate is, by > itself, evidence that stronger policy intervention is required. I do not > think this is a useful basis for policy development. > > The AFRINIC community should not be comparing itself to other regions from > a technological adoption perspective. There are numerous economic, > infrastructural, educational, and operational factors that influence IPv6 > deployment across different regions. The fact that Africa has lower IPv6 > deployment than other regions does not automatically indicate a policy > failure. > > Furthermore, after more than 25 years of IPv6 availability, even the > regions often considered technologically advanced are still reporting > deployment levels that are far from complete. If the reported global > capability is approximately 44%, this demonstrates that IPv6 adoption > remains a challenge worldwide and not exclusively within Africa. > > If the objective is to highlight low IPv6 deployment within the AFRINIC > service region, the problem statement should focus on that issue directly > and objectively, without relying on comparisons with other regions. Any > benchmarking should be done carefully and within relevant peer groups > rather than presenting Africa as lagging behind the rest of the world. > > Second, I am concerned that the proposal moves AFRINIC beyond its > traditional role as a registry and into the role of an operational > regulator. > > The primary function of an RIR is the fair and efficient management and > registration of Internet number resources. This proposal goes significantly > further by attempting to regulate how networks deploy IPv6, how quickly > they deploy it, what percentage of traffic should use it, and what > percentage of services should be reachable over it. > > Such requirements extend beyond resource registration and enter the realm > of network operations and business decisions. I do not believe this falls > within the intended scope of RIR policy. > > Third, the proposed compliance criteria appear difficult to evaluate > objectively. > > For example, the proposal requires networks to demonstrate specific > percentages of IPv6 traffic to their top-25 external destinations. It is > unclear: > > - How these destinations will be identified and measured; > - Over what period measurements will be taken; > - How AFRINIC staff will independently verify the information provided; > - How compliance will be assessed when traffic patterns change over > time. > > In addition, network operators do not control whether external > destinations support IPv6, nor do they fully control the applications and > services used by their customers. As a result, the proposed traffic > thresholds may not accurately reflect the deployment efforts undertaken by > the resource holder. > > Similarly, evaluating IPv6 reachability through percentages of AAAA > records and service availability introduces a high degree of subjectivity. > Different networks host different types of services, operate different > architectures, and face different technical constraints. A single set of > percentages may not be appropriate across all deployment scenarios. > > Finally, I am particularly concerned by the statement that failure to > comply with the IPv6 deployment plan constitutes a policy violation. > > An organization may make genuine efforts to deploy IPv6 and still fail to > meet prescribed percentages due to factors outside its control. Turning > such outcomes into policy violations creates uncertainty and potentially > disproportionate consequences for resource holders. > > I would support measures that encourage IPv6 adoption, such as requiring > organizations requesting IPv4 resources to also obtain IPv6 resources if > they do not already have them, or requiring applicants to submit an IPv6 > deployment plan. However, I do not support introducing operational > deployment targets, traffic thresholds, service reachability metrics, and > compliance enforcement mechanisms that move beyond AFRINIC?s core > registration function. > > For these reasons, I oppose the proposal in its current form. > > > On 23 Jun 2026, at 23:45, Musa Stephen Honlue > wrote: > > ? Thank you Madhvi. > > > On 23 Jun 2026, at 23:25, Madhvi Gokool > wrote: > > ? > > Hello Stephen > > There seems to be an issue with the first version of the proposal on the > website. We'll ensure it's fixed the soonest. > > Please note that the author submitted a revised version of the proposal - > https://afrinic.net/participate/policy/proposals/afpub-2026-v6-001-draft02 > and that the latter will be discussed during the AFRINIC-37 PPM. > > Kind Regards > > Madhvi > > Policy Liaison AFRINIC > On 24/06/2026 00:25, Musa Stephen Honlue wrote: > > > > > > This is what the link is showing, please confirm that you have access. > > On 28 May 2026, at 12:27, Sami Salih > wrote: > > ? > Hi Jordi, colleagues, > > Thank you, Jordi, for considering my previous comments and for > restructuring this into a more focused proposal. > > In principle, I support linking IPv4 allocations under the Soft Landing > policy with commitment toward IPv6 deployment. Given the IPv4 exhaustion > reality, this is a reasonable policy direction. > > I also appreciate the additional clarifications regarding the existing > policy references and deployment expectations. Nevertheless, I believe the > implementation and enforcement aspects may still require further refinement > to ensure the criteria remain objective, measurable, and operationally > practical across the AFRINIC service region. I believe the staff analysis > may further help clarify the operational feasibility, compliance > verification approach, and enforcement practicality of the proposed > requirements. > > Overall, I support the intent of the proposal and appreciate the more > granular approach to the discussion. > > With Regards, > Sami Salih. > > > Sami Salih > ------------------------------ > *From:* jordi.palet--- via RPD > *Sent:* Thursday, May 28, 2026 1:21:52 PM > *To:* rpd at afrinic.net > *Subject:* Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01. > > Hi Jaco, > > Tks, next version will use: ?Any IPv4 request must be done with a > simultaneous IPv6 request if the requesting party does not already have > IPv6 space.? This may depend on the impact analysis inputs, of course. > > About the determination/measurement that this is being done, let me > explain how I see this. > > The existing 6.5.1.1 (for LIRs) and 6.8.2, already set the conditions to > be met. AFRINIC already has, in both cases, a 12 months period to confirm > the deployment. May be is not sufficiently clear there if AFRINIC should do > something if that?s not actually done. We aren?t talking there only about > announcing the prefix, but also in the case of LIRs, about making > assignments to end-sites, and the text is clear, /48s, nothing different. > There is no reason for using different sizes for different type of > customers on that text. There is no technical reason at all for not doing > it correctly, however, this is a discussion for amending that part of the > policy, not for this proposal. > > What this proposal wants to make sure is that you *actually*, *following > existing policy*, if you get IPv4, you really deploy IPv6 in 12 months. To > reinforce it I explicitly mention ?In addition ??, as you said. Note that > ?in addition? section enforces a more detailed work from the member > requesting IPv4, to justify a credible IPv6 addressing and deployment plan, > this will be accepted or not by AFRINIC, as with any request evaluation. > > For example, in many RIRs, not just AFRINIC, I?ve observed that many > members get by default a /32, even if they have 800.000 end-sites. Clearly > wrong, they didn?t have done any real addressing plan and they will end up > providing a single /64 to each end-site. If they do it correctly, they will > soon discover why they should use /48s, so with a /32 they can only cover > around 50.000 customers, which means that typically for 800.000 of > customers (depending on the topological distribution of the network) will > mean that they need a /27-/28. > > I don?t think nobody can say ?deploy? is not clear. If this is the case, > we can improve it, something like ?and IPv6 is actually being used?. We can > even set a minimum level of traffic, such as 50% for example? Those that > have deployed IPv6 know that, at least in the case of residential and > cellular customers, because most of the traffic (typically 75-90%) is from > big CDNs, caches, and contend providers (all google, all Meta, Akamai and > all the other CDNs), already provide IPv6, when you turn on IPv6 in an > end-site, the IPv6 traffic of that end-site becomes 75%-90% IPv6, in turn > the total ISP traffic reaches similar levels. > > So asking for 50% seems to me conservative, but I?m happy for lower > levels, if we agree that we can ask for more later on. We can even consider > something like 25% after 12 months, 50% after 24 months, 75% after 48 > months. Just an example. > > Finally, as we have many policies that AFRINIC not necessarily is > measuring the compliance, that?s what the other proposal (compliance > dashboard) was already trying to resolve, now in a ?light? version. > > This proposal also added a trigger (failure to comply) to ensure that > abuse (requesting IPv4, but then not deploying IPv6) can enact the RSA > terms, because clearly shows that there is a policy breach. > > By the way, dynamic prefixes in IPv6 is broken, terrible idea, specially > if there are power outages. > > I suggest to read what, hopefully in a few months, will become in RFC/BCP > a successor of RIPE690: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/ > > Regards, > Jordi > > @jordipalet > > > El 28 may 2026, a las 11:43, Jaco Kroon > escribi?: > > Hi Jordi, > > I support the principle very much. Practicality may be a different story, > yes, must implement v6, however: > > How do you determine/measure that? I think your "In addition" section > addresses this to a degree. > > Merely advertising IPv6 space? Sure, that's easy, but it doesn't mean I > have to actually make that available to customers. > > Re proposed text, the word "However, " doesn't add value, merely "Any IPv4 > request must be done with a simultaneous IPv6 request if the requesting > party does not already have IPv6 space." > > This does also be the question, it seems 6.5.1.1.3 states that you must > give /48s to end sites - we do distinguish between business and home users, > for business we happily do /48 if so required (at least we reserve a /48 > per site minimum), but for home users we generally do dynamically allocated > /56 (but will again do /48 on request) - would this imply failure to comply > with your proposed policy? If so, should the proposed policy be adjusted, > or 6.5.1.1.3? > > For PI space (6.8.2.2.d) - what does deployed mean? > > Kind regards, > Jaco Kroon > > On 2026/05/28 10:28, jordi.palet--- via RPD wrote: > > Hi all, > > Somehow this is a response to Sami input on a previous proposal. > > This way we can split the problem space in 2 proposals, which may reach consensus without depending one on the other. > > So we have a very basic question: If we believe that the members that receive IPv4 out of the Soft Landing policy, must implement IPv6, or not? > > Regards, > Jordi > > @jordipalet > > > > El 28 may 2026, a las 10:05, Darwin Da Costa escribi?: > > Dear PDWG, > > We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: > https://afrinic.net/afpub-2026-v6-001-draft01 > > > We encourage you to take some time to go through the proposal contents and provide feedback as follows: > > a)Do you support or oppose the proposal? > > b) If you oppose the proposal, state your reasons? > > c) Is there anything in the proposal that is not clear? > > d) What changes could be made to this proposal to make it more effective? > > > Regards, > Vincent Ngundi & Darwin Da Costa > AFRINIC PDWG Co-Chairs > > _______________________________________________ > RPD mailing listRPD at afrinic.nethttps://lists.afrinic.net/mailman/listinfo/rpd > > ********************************************** > IPv4 is over > Are you ready for the new Internet ?http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > > > > _______________________________________________ > RPD mailing listRPD at afrinic.nethttps://lists.afrinic.net/mailman/listinfo/rpd > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > _______________________________________________ > RPD mailing listRPD at afrinic.nethttps://lists.afrinic.net/mailman/listinfo/rpd > > > _______________________________________________ > RPD mailing listRPD at afrinic.nethttps://lists.afrinic.net/mailman/listinfo/rpd > > -- > > Mark James ELKINS - Posix Systems - (South) Africa > mje at posix.co.za Tel: +27.826010496 <+27826010496> > For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za > > > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu Jun 25 06:15:40 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Thu, 25 Jun 2026 08:15:40 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: <62C7A878-5533-46BE-8B44-BD8651F574E1@gmail.com> Message-ID: Hi Seun, I will actually say personally, the only acceptable X=1, but happy to concede with 2. Hopefully we don?t have a discussion and every participant chose a different number, as this is the typical issue when asking for a decision of ?number of whatever? in trying to reach consensus. I will also say that X is only for ?single? allocations/assigments, in the sense that if you are doing something for HA (one of the policies that reached consensus yesterday), you must do it with IPv6. There is no sense that you deploy, today, an HA infrastructure without IPv6. What do you think ? Regards, Jordi @jordipalet > El 25 jun 2026, a las 2:37, Seun Ojedeji escribi?: > > Hi Jordi, > > ---- > Sent from my mobile > kindly excuse typos > > On Wed, 24 Jun 2026, 6:14?pm jordi.palet--- via RPD, > wrote: >> . >> >> So there is no difference in now setting a policy that clearly say, you get more IPv4, but you must also deploy IPv6. >> >> We could also do something slightly different, I?m not sure if this is what Seun tried to say in the mic earlier this afternoon. >> >> We don?t give any more IPv4 resources if you already got them previously. This has been done by most of the other RIRs. Will you agree with that? Only newcomers can get IPv4. > > > SO: More like you don't get IPv4 resources if you already got it for X number of times in the current phase unless you meet the IPv6 deployment plan requirements. My intention is for X not !=Once > > Regards >> >> Now, as a 2nd part of the proposal, resources left (even recovered), can be provided to anyone who also deploy IPv6, regardless of being a newcomer or an existing member. >> >> What do you think? >> >> Regards, >> Jordi >> >> @jordipalet >> >>> El 24 jun 2026, a las 15:43, Musa Stephen Honlue > escribi?: >>> >>> >>> Thank you Mark for your response. >>> >>> I would like to clarify that my opposition is not to IPv6 deployment itself. I fully support wider IPv6 adoption across the AFRINIC service region and agree that organizations should be encouraged to deploy and actively use the IPv6 resources they receive. I have been training and supporting engineers on the deployment of IPv6 and other technologies. >>> >>> Where I differ is on the role that AFRINIC policy should play in achieving that objective. >>> >>> Your suggestion that AFRINIC should eventually require IPv6-only interactions with AFRINIC services is an operational decision that AFRINIC may choose to make for its own infrastructure and services. However, the proposal under discussion goes much further by prescribing how resource holders should deploy IPv6 within their own networks and by attaching compliance obligations to operational outcomes. >>> >>> My concern is that this moves AFRINIC from managing and registering number resources into regulating network operations. Whether IPv6 is cheaper, more efficient, or technically preferable does not automatically mean that deployment targets, traffic ratios, service reachability percentages, and compliance enforcement belong in resource management policy. >>> >>> I also do not believe that making IPv6 deployment a policy compliance matter is the right solution to the concern that some members may later claim they were not encouraged to adopt IPv6. AFRINIC already allocates IPv6 resources, provides training, conducts outreach, and can require applicants to demonstrate IPv6 planning as part of resource requests. These are measures that encourage adoption without attempting to regulate operational implementation. >>> >>> In my view, there is a significant difference between encouraging IPv6 deployment and enforcing specific deployment outcomes. I support the former, but I remain unconvinced that the latter falls within the appropriate scope of AFRINIC policy. >>> >>> >>> >>>> On 24 Jun 2026, at 10:30, Mark Elkins via RPD > wrote: >>>> >>>> ? >>>> Dear Musa Stephen Honlue, >>>> >>>> I disagree with your viewpoint and can see that in the future some resource members muttering that "nobody told us we had to have IPv6 - why didn't AFRINIC enforce it?" >>>> Personally, I want AFRINIC to make sure all resource members have IPv6 the change that to all IPv6 resource holders need to make their space visible then one day insist that all communications with AFRINIC is over IPv6 and AFRINIC somewhat terminates access via IPv4. Harsh, I know, but IPv6 is cheaper and more efficient to run than IPv4... Step by step - and this is a good step. >>>> >>>> On 2026/06/24 00:20, Musa Stephen Honlue wrote: >>>>> Dear Jordi >>>>> >>>>> I would like to express my opposition to this proposal in its current form. >>>>> >>>>> While I fully support the objective of increasing IPv6 deployment across the AFRINIC service region, I do not believe that the problem statement and the proposed solution adequately justify the measures being introduced. >>>>> >>>>> First, I believe the problem statement is inappropriately framed. The proposal relies heavily on comparisons between Africa and other regions of the world, suggesting that Africa?s lower IPv6 deployment rate is, by itself, evidence that stronger policy intervention is required. I do not think this is a useful basis for policy development. >>>>> >>>>> The AFRINIC community should not be comparing itself to other regions from a technological adoption perspective. There are numerous economic, infrastructural, educational, and operational factors that influence IPv6 deployment across different regions. The fact that Africa has lower IPv6 deployment than other regions does not automatically indicate a policy failure. >>>>> >>>>> Furthermore, after more than 25 years of IPv6 availability, even the regions often considered technologically advanced are still reporting deployment levels that are far from complete. If the reported global capability is approximately 44%, this demonstrates that IPv6 adoption remains a challenge worldwide and not exclusively within Africa. >>>>> >>>>> If the objective is to highlight low IPv6 deployment within the AFRINIC service region, the problem statement should focus on that issue directly and objectively, without relying on comparisons with other regions. Any benchmarking should be done carefully and within relevant peer groups rather than presenting Africa as lagging behind the rest of the world. >>>>> >>>>> Second, I am concerned that the proposal moves AFRINIC beyond its traditional role as a registry and into the role of an operational regulator. >>>>> >>>>> The primary function of an RIR is the fair and efficient management and registration of Internet number resources. This proposal goes significantly further by attempting to regulate how networks deploy IPv6, how quickly they deploy it, what percentage of traffic should use it, and what percentage of services should be reachable over it. >>>>> >>>>> Such requirements extend beyond resource registration and enter the realm of network operations and business decisions. I do not believe this falls within the intended scope of RIR policy. >>>>> >>>>> Third, the proposed compliance criteria appear difficult to evaluate objectively. >>>>> >>>>> For example, the proposal requires networks to demonstrate specific percentages of IPv6 traffic to their top-25 external destinations. It is unclear: >>>>> >>>>> How these destinations will be identified and measured; >>>>> Over what period measurements will be taken; >>>>> How AFRINIC staff will independently verify the information provided; >>>>> How compliance will be assessed when traffic patterns change over time. >>>>> In addition, network operators do not control whether external destinations support IPv6, nor do they fully control the applications and services used by their customers. As a result, the proposed traffic thresholds may not accurately reflect the deployment efforts undertaken by the resource holder. >>>>> >>>>> Similarly, evaluating IPv6 reachability through percentages of AAAA records and service availability introduces a high degree of subjectivity. Different networks host different types of services, operate different architectures, and face different technical constraints. A single set of percentages may not be appropriate across all deployment scenarios. >>>>> >>>>> Finally, I am particularly concerned by the statement that failure to comply with the IPv6 deployment plan constitutes a policy violation. >>>>> >>>>> An organization may make genuine efforts to deploy IPv6 and still fail to meet prescribed percentages due to factors outside its control. Turning such outcomes into policy violations creates uncertainty and potentially disproportionate consequences for resource holders. >>>>> >>>>> I would support measures that encourage IPv6 adoption, such as requiring organizations requesting IPv4 resources to also obtain IPv6 resources if they do not already have them, or requiring applicants to submit an IPv6 deployment plan. However, I do not support introducing operational deployment targets, traffic thresholds, service reachability metrics, and compliance enforcement mechanisms that move beyond AFRINIC?s core registration function. >>>>> >>>>> For these reasons, I oppose the proposal in its current form. >>>>> >>>>>> >>>>>> On 23 Jun 2026, at 23:45, Musa Stephen Honlue wrote: >>>>>> >>>>>> ? Thank you Madhvi. >>>>>> >>>>>>> >>>>>>> On 23 Jun 2026, at 23:25, Madhvi Gokool wrote: >>>>>>> >>>>>>> ? >>>>>>> Hello Stephen >>>>>>> >>>>>>> There seems to be an issue with the first version of the proposal on the website. We'll ensure it's fixed the soonest. >>>>>>> >>>>>>> Please note that the author submitted a revised version of the proposal - https://afrinic.net/participate/policy/proposals/afpub-2026-v6-001-draft02 and that the latter will be discussed during the AFRINIC-37 PPM. >>>>>>> >>>>>>> Kind Regards >>>>>>> >>>>>>> Madhvi >>>>>>> >>>>>>> Policy Liaison AFRINIC >>>>>>> >>>>>>> On 24/06/2026 00:25, Musa Stephen Honlue wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This is what the link is showing, please confirm that you have access. >>>>>>>> >>>>>>>>> On 28 May 2026, at 12:27, Sami Salih wrote: >>>>>>>>> >>>>>>>>> ? >>>>>>>>> Hi Jordi, colleagues, >>>>>>>>> >>>>>>>>> Thank you, Jordi, for considering my previous comments and for restructuring this into a more focused proposal. >>>>>>>>> >>>>>>>>> In principle, I support linking IPv4 allocations under the Soft Landing policy with commitment toward IPv6 deployment. Given the IPv4 exhaustion reality, this is a reasonable policy direction. >>>>>>>>> >>>>>>>>> I also appreciate the additional clarifications regarding the existing policy references and deployment expectations. Nevertheless, I believe the implementation and enforcement aspects may still require further refinement to ensure the criteria remain objective, measurable, and operationally practical across the AFRINIC service region. I believe the staff analysis may further help clarify the operational feasibility, compliance verification approach, and enforcement practicality of the proposed requirements. >>>>>>>>> >>>>>>>>> Overall, I support the intent of the proposal and appreciate the more granular approach to the discussion. >>>>>>>>> >>>>>>>>> With Regards, >>>>>>>>> Sami Salih. >>>>>>>>> >>>>>>>>> >>>>>>>>> Sami Salih >>>>>>>>> From: jordi.palet--- via RPD >>>>>>>>> Sent: Thursday, May 28, 2026 1:21:52 PM >>>>>>>>> To: rpd at afrinic.net >>>>>>>>> Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. >>>>>>>>> >>>>>>>>> Hi Jaco, >>>>>>>>> >>>>>>>>> Tks, next version will use: ?Any IPv4 request must be done with a simultaneous IPv6 request if the requesting party does not already have IPv6 space.? This may depend on the impact analysis inputs, of course. >>>>>>>>> >>>>>>>>> About the determination/measurement that this is being done, let me explain how I see this. >>>>>>>>> >>>>>>>>> The existing 6.5.1.1 (for LIRs) and 6.8.2, already set the conditions to be met. AFRINIC already has, in both cases, a 12 months period to confirm the deployment. May be is not sufficiently clear there if AFRINIC should do something if that?s not actually done. We aren?t talking there only about announcing the prefix, but also in the case of LIRs, about making assignments to end-sites, and the text is clear, /48s, nothing different. There is no reason for using different sizes for different type of customers on that text. There is no technical reason at all for not doing it correctly, however, this is a discussion for amending that part of the policy, not for this proposal. >>>>>>>>> >>>>>>>>> What this proposal wants to make sure is that you *actually*, *following existing policy*, if you get IPv4, you really deploy IPv6 in 12 months. To reinforce it I explicitly mention ?In addition ??, as you said. Note that ?in addition? section enforces a more detailed work from the member requesting IPv4, to justify a credible IPv6 addressing and deployment plan, this will be accepted or not by AFRINIC, as with any request evaluation. >>>>>>>>> >>>>>>>>> For example, in many RIRs, not just AFRINIC, I?ve observed that many members get by default a /32, even if they have 800.000 end-sites. Clearly wrong, they didn?t have done any real addressing plan and they will end up providing a single /64 to each end-site. If they do it correctly, they will soon discover why they should use /48s, so with a /32 they can only cover around 50.000 customers, which means that typically for 800.000 of customers (depending on the topological distribution of the network) will mean that they need a /27-/28. >>>>>>>>> >>>>>>>>> I don?t think nobody can say ?deploy? is not clear. If this is the case, we can improve it, something like ?and IPv6 is actually being used?. We can even set a minimum level of traffic, such as 50% for example? Those that have deployed IPv6 know that, at least in the case of residential and cellular customers, because most of the traffic (typically 75-90%) is from big CDNs, caches, and contend providers (all google, all Meta, Akamai and all the other CDNs), already provide IPv6, when you turn on IPv6 in an end-site, the IPv6 traffic of that end-site becomes 75%-90% IPv6, in turn the total ISP traffic reaches similar levels. >>>>>>>>> >>>>>>>>> So asking for 50% seems to me conservative, but I?m happy for lower levels, if we agree that we can ask for more later on. We can even consider something like 25% after 12 months, 50% after 24 months, 75% after 48 months. Just an example. >>>>>>>>> >>>>>>>>> Finally, as we have many policies that AFRINIC not necessarily is measuring the compliance, that?s what the other proposal (compliance dashboard) was already trying to resolve, now in a ?light? version. >>>>>>>>> >>>>>>>>> This proposal also added a trigger (failure to comply) to ensure that abuse (requesting IPv4, but then not deploying IPv6) can enact the RSA terms, because clearly shows that there is a policy breach. >>>>>>>>> >>>>>>>>> By the way, dynamic prefixes in IPv6 is broken, terrible idea, specially if there are power outages. >>>>>>>>> >>>>>>>>> I suggest to read what, hopefully in a few months, will become in RFC/BCP a successor of RIPE690: >>>>>>>>> >>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/ >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Jordi >>>>>>>>> >>>>>>>>> @jordipalet >>>>>>>>> >>>>>>>>> >>>>>>>>>> El 28 may 2026, a las 11:43, Jaco Kroon escribi?: >>>>>>>>>> >>>>>>>>>> Hi Jordi, >>>>>>>>>> >>>>>>>>>> I support the principle very much. Practicality may be a different story, yes, must implement v6, however: >>>>>>>>>> >>>>>>>>>> How do you determine/measure that? I think your "In addition" section addresses this to a degree. >>>>>>>>>> >>>>>>>>>> Merely advertising IPv6 space? Sure, that's easy, but it doesn't mean I have to actually make that available to customers. >>>>>>>>>> >>>>>>>>>> Re proposed text, the word "However, " doesn't add value, merely "Any IPv4 request must be done with a simultaneous IPv6 request if the requesting party does not already have IPv6 space." >>>>>>>>>> >>>>>>>>>> This does also be the question, it seems 6.5.1.1.3 states that you must give /48s to end sites - we do distinguish between business and home users, for business we happily do /48 if so required (at least we reserve a /48 per site minimum), but for home users we generally do dynamically allocated /56 (but will again do /48 on request) - would this imply failure to comply with your proposed policy? If so, should the proposed policy be adjusted, or 6.5.1.1.3? >>>>>>>>>> >>>>>>>>>> For PI space (6.8.2.2.d) - what does deployed mean? >>>>>>>>>> >>>>>>>>>> Kind regards, >>>>>>>>>> Jaco Kroon >>>>>>>>>> >>>>>>>>>> On 2026/05/28 10:28, jordi.palet--- via RPD wrote: >>>>>>>>>> >>>>>>>>>>> Hi all, >>>>>>>>>>> >>>>>>>>>>> Somehow this is a response to Sami input on a previous proposal. >>>>>>>>>>> >>>>>>>>>>> This way we can split the problem space in 2 proposals, which may reach consensus without depending one on the other. >>>>>>>>>>> >>>>>>>>>>> So we have a very basic question: If we believe that the members that receive IPv4 out of the Soft Landing policy, must implement IPv6, or not? >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Jordi >>>>>>>>>>> >>>>>>>>>>> @jordipalet >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> El 28 may 2026, a las 10:05, Darwin Da Costa escribi?: >>>>>>>>>>>> >>>>>>>>>>>> Dear PDWG, >>>>>>>>>>>> >>>>>>>>>>>> We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>>>>>>>>>>> >>>>>>>>>>>> https://afrinic.net/afpub-2026-v6-001-draft01 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>>>>>>>>>>> >>>>>>>>>>>> a)Do you support or oppose the proposal? >>>>>>>>>>>> >>>>>>>>>>>> b) If you oppose the proposal, state your reasons? >>>>>>>>>>>> >>>>>>>>>>>> c) Is there anything in the proposal that is not clear? >>>>>>>>>>>> >>>>>>>>>>>> d) What changes could be made to this proposal to make it more effective? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Vincent Ngundi & Darwin Da Costa >>>>>>>>>>>> AFRINIC PDWG Co-Chairs >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> RPD mailing list >>>>>>>>>>>> RPD at afrinic.net >>>>>>>>>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>>>>>>>> ********************************************** >>>>>>>>>>> IPv4 is over >>>>>>>>>>> Are you ready for the new Internet ? >>>>>>>>>>> http://www.theipv6company.com >>>>>>>>>>> The IPv6 Company >>>>>>>>>>> >>>>>>>>>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> RPD mailing list >>>>>>>>>>> RPD at afrinic.net >>>>>>>>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>>>>>> >>>>>>>>> >>>>>>>>> ********************************************** >>>>>>>>> IPv4 is over >>>>>>>>> Are you ready for the new Internet ? >>>>>>>>> http://www.theipv6company.com >>>>>>>>> The IPv6 Company >>>>>>>>> >>>>>>>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> RPD mailing list >>>>>>>>> RPD at afrinic.net >>>>>>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> RPD mailing list >>>>>>>> RPD at afrinic.net >>>>>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>> >>>>> >>>>> _______________________________________________ >>>>> RPD mailing list >>>>> RPD at afrinic.net >>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> -- >>>> Mark James ELKINS - Posix Systems - (South) Africa >>>> mje at posix.co.za Tel: +27.826010496 >>>> For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Thu Jun 25 08:15:49 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Thu, 25 Jun 2026 10:15:49 +0200 Subject: [rpd] suggestion for improving PDP discussion Message-ID: Hi all, I will like to suggest several points to improve the discussion in the RPD list and avoid ?last minute rush? the weeks before the next meeting. 1) For the proposals that didn?t reached consensus (or ere not looking for that). Wait for the chairs report and try to continue the discussion immediately, so we can work in an updated version in a matter of weeks. 2) Could the staff publish an updated PIER, like https://www.afrinic.net/policy/implementation-reports/pier-summary? This way we can see if some folks, for example ccTLDs, IXs, etc., that may be able to join to co-author proposals, again in a matter of weeks. 3) Hopefully others can contribute with some other ideas on the same direction ... I know now everyone is too busy with the meeting and post-meeting, I?m not talking about an immediate reaction, but may be doing so by next month or so. I feel that even if this is what we should expect, after ever meeting we forget about that, so somehow ?formalizing? it immediately, we will not forget this time! Regards, Jordi @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From mike at iptrading.com Thu Jun 25 12:59:50 2026 From: mike at iptrading.com (Mike Burns) Date: Thu, 25 Jun 2026 08:59:50 -0400 Subject: [rpd] IPv6 as a criteria in IPv4 Soft LandingAFPUB-2026-v6-001-DRAFT01. In-Reply-To: <62C7A878-5533-46BE-8B44-BD8651F574E1@gmail.com> References: <62C7A878-5533-46BE-8B44-BD8651F574E1@gmail.com> Message-ID: <011c01dd04a2$822a5b90$867f12b0$@iptrading.com> Hello list, +1 to Musa?s viewpoint. We are just stewards of numbers, seeking uniqueness of registration. We are not routing police, we do not prescribe or proscribe network configurations. Almost every organization suffers from mission creep as there is always another windmill to tilt at. We see the bloat at other RIRs, with actions aimed at other ?causes? like grants, foundations, meeting etiquette, demographic representation, etc. Let us just stick to our remit and make sure those in need of number resources can acquire them and get them registered. IPv6 numbers or IPv4 numbers or AS numbers. What?s next? No resources unless prior ones are covered under a ROA? These are good, even noble causes, but they are not part of number stewardship, which some now seek to turn into a weapon for protocol change. As Musa said, encourage IPv6, that is okay, but coercively mandating one protocol over the other is a mistake. Regards, Mike From: Musa Stephen Honlue Sent: Wednesday, June 24, 2026 9:43 AM To: mje at posix.co.za; Mark Elkins Cc: rpd at afrinic.net Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft LandingAFPUB-2026-v6-001-DRAFT01. Thank you Mark for your response. I would like to clarify that my opposition is not to IPv6 deployment itself. I fully support wider IPv6 adoption across the AFRINIC service region and agree that organizations should be encouraged to deploy and actively use the IPv6 resources they receive. I have been training and supporting engineers on the deployment of IPv6 and other technologies. Where I differ is on the role that AFRINIC policy should play in achieving that objective. Your suggestion that AFRINIC should eventually require IPv6-only interactions with AFRINIC services is an operational decision that AFRINIC may choose to make for its own infrastructure and services. However, the proposal under discussion goes much further by prescribing how resource holders should deploy IPv6 within their own networks and by attaching compliance obligations to operational outcomes. My concern is that this moves AFRINIC from managing and registering number resources into regulating network operations. Whether IPv6 is cheaper, more efficient, or technically preferable does not automatically mean that deployment targets, traffic ratios, service reachability percentages, and compliance enforcement belong in resource management policy. I also do not believe that making IPv6 deployment a policy compliance matter is the right solution to the concern that some members may later claim they were not encouraged to adopt IPv6. AFRINIC already allocates IPv6 resources, provides training, conducts outreach, and can require applicants to demonstrate IPv6 planning as part of resource requests. These are measures that encourage adoption without attempting to regulate operational implementation. In my view, there is a significant difference between encouraging IPv6 deployment and enforcing specific deployment outcomes. I support the former, but I remain unconvinced that the latter falls within the appropriate scope of AFRINIC policy. On 24 Jun 2026, at 10:30, Mark Elkins via RPD > wrote: ? Dear Musa Stephen Honlue, I disagree with your viewpoint and can see that in the future some resource members muttering that "nobody told us we had to have IPv6 - why didn't AFRINIC enforce it?" Personally, I want AFRINIC to make sure all resource members have IPv6 the change that to all IPv6 resource holders need to make their space visible then one day insist that all communications with AFRINIC is over IPv6 and AFRINIC somewhat terminates access via IPv4. Harsh, I know, but IPv6 is cheaper and more efficient to run than IPv4... Step by step - and this is a good step. On 2026/06/24 00:20, Musa Stephen Honlue wrote: Dear Jordi I would like to express my opposition to this proposal in its current form. While I fully support the objective of increasing IPv6 deployment across the AFRINIC service region, I do not believe that the problem statement and the proposed solution adequately justify the measures being introduced. First, I believe the problem statement is inappropriately framed. The proposal relies heavily on comparisons between Africa and other regions of the world, suggesting that Africa?s lower IPv6 deployment rate is, by itself, evidence that stronger policy intervention is required. I do not think this is a useful basis for policy development. The AFRINIC community should not be comparing itself to other regions from a technological adoption perspective. There are numerous economic, infrastructural, educational, and operational factors that influence IPv6 deployment across different regions. The fact that Africa has lower IPv6 deployment than other regions does not automatically indicate a policy failure. Furthermore, after more than 25 years of IPv6 availability, even the regions often considered technologically advanced are still reporting deployment levels that are far from complete. If the reported global capability is approximately 44%, this demonstrates that IPv6 adoption remains a challenge worldwide and not exclusively within Africa. If the objective is to highlight low IPv6 deployment within the AFRINIC service region, the problem statement should focus on that issue directly and objectively, without relying on comparisons with other regions. Any benchmarking should be done carefully and within relevant peer groups rather than presenting Africa as lagging behind the rest of the world. Second, I am concerned that the proposal moves AFRINIC beyond its traditional role as a registry and into the role of an operational regulator. The primary function of an RIR is the fair and efficient management and registration of Internet number resources. This proposal goes significantly further by attempting to regulate how networks deploy IPv6, how quickly they deploy it, what percentage of traffic should use it, and what percentage of services should be reachable over it. Such requirements extend beyond resource registration and enter the realm of network operations and business decisions. I do not believe this falls within the intended scope of RIR policy. Third, the proposed compliance criteria appear difficult to evaluate objectively. For example, the proposal requires networks to demonstrate specific percentages of IPv6 traffic to their top-25 external destinations. It is unclear: * How these destinations will be identified and measured; * Over what period measurements will be taken; * How AFRINIC staff will independently verify the information provided; * How compliance will be assessed when traffic patterns change over time. In addition, network operators do not control whether external destinations support IPv6, nor do they fully control the applications and services used by their customers. As a result, the proposed traffic thresholds may not accurately reflect the deployment efforts undertaken by the resource holder. Similarly, evaluating IPv6 reachability through percentages of AAAA records and service availability introduces a high degree of subjectivity. Different networks host different types of services, operate different architectures, and face different technical constraints. A single set of percentages may not be appropriate across all deployment scenarios. Finally, I am particularly concerned by the statement that failure to comply with the IPv6 deployment plan constitutes a policy violation. An organization may make genuine efforts to deploy IPv6 and still fail to meet prescribed percentages due to factors outside its control. Turning such outcomes into policy violations creates uncertainty and potentially disproportionate consequences for resource holders. I would support measures that encourage IPv6 adoption, such as requiring organizations requesting IPv4 resources to also obtain IPv6 resources if they do not already have them, or requiring applicants to submit an IPv6 deployment plan. However, I do not support introducing operational deployment targets, traffic thresholds, service reachability metrics, and compliance enforcement mechanisms that move beyond AFRINIC?s core registration function. For these reasons, I oppose the proposal in its current form. On 23 Jun 2026, at 23:45, Musa Stephen Honlue wrote: ? Thank you Madhvi. On 23 Jun 2026, at 23:25, Madhvi Gokool wrote: ? Hello Stephen There seems to be an issue with the first version of the proposal on the website. We'll ensure it's fixed the soonest. Please note that the author submitted a revised version of the proposal - https://afrinic.net/participate/policy/proposals/afpub-2026-v6-001-draft02 and that the latter will be discussed during the AFRINIC-37 PPM. Kind Regards Madhvi Policy Liaison AFRINIC On 24/06/2026 00:25, Musa Stephen Honlue wrote: This is what the link is showing, please confirm that you have access. On 28 May 2026, at 12:27, Sami Salih wrote: ? Hi Jordi, colleagues, Thank you, Jordi, for considering my previous comments and for restructuring this into a more focused proposal. In principle, I support linking IPv4 allocations under the Soft Landing policy with commitment toward IPv6 deployment. Given the IPv4 exhaustion reality, this is a reasonable policy direction. I also appreciate the additional clarifications regarding the existing policy references and deployment expectations. Nevertheless, I believe the implementation and enforcement aspects may still require further refinement to ensure the criteria remain objective, measurable, and operationally practical across the AFRINIC service region. I believe the staff analysis may further help clarify the operational feasibility, compliance verification approach, and enforcement practicality of the proposed requirements. Overall, I support the intent of the proposal and appreciate the more granular approach to the discussion. With Regards, Sami Salih. Sami Salih _____ From: jordi.palet--- via RPD Sent: Thursday, May 28, 2026 1:21:52 PM To: rpd at afrinic.net Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. Hi Jaco, Tks, next version will use: ?Any IPv4 request must be done with a simultaneous IPv6 request if the requesting party does not already have IPv6 space.? This may depend on the impact analysis inputs, of course. About the determination/measurement that this is being done, let me explain how I see this. The existing 6.5.1.1 (for LIRs) and 6.8.2, already set the conditions to be met. AFRINIC already has, in both cases, a 12 months period to confirm the deployment. May be is not sufficiently clear there if AFRINIC should do something if that?s not actually done. We aren?t talking there only about announcing the prefix, but also in the case of LIRs, about making assignments to end-sites, and the text is clear, /48s, nothing different. There is no reason for using different sizes for different type of customers on that text. There is no technical reason at all for not doing it correctly, however, this is a discussion for amending that part of the policy, not for this proposal. What this proposal wants to make sure is that you *actually*, *following existing policy*, if you get IPv4, you really deploy IPv6 in 12 months. To reinforce it I explicitly mention ?In addition ??, as you said. Note that ?in addition? section enforces a more detailed work from the member requesting IPv4, to justify a credible IPv6 addressing and deployment plan, this will be accepted or not by AFRINIC, as with any request evaluation. For example, in many RIRs, not just AFRINIC, I?ve observed that many members get by default a /32, even if they have 800.000 end-sites. Clearly wrong, they didn?t have done any real addressing plan and they will end up providing a single /64 to each end-site. If they do it correctly, they will soon discover why they should use /48s, so with a /32 they can only cover around 50.000 customers, which means that typically for 800.000 of customers (depending on the topological distribution of the network) will mean that they need a /27-/28. I don?t think nobody can say ?deploy? is not clear. If this is the case, we can improve it, something like ?and IPv6 is actually being used?. We can even set a minimum level of traffic, such as 50% for example? Those that have deployed IPv6 know that, at least in the case of residential and cellular customers, because most of the traffic (typically 75-90%) is from big CDNs, caches, and contend providers (all google, all Meta, Akamai and all the other CDNs), already provide IPv6, when you turn on IPv6 in an end-site, the IPv6 traffic of that end-site becomes 75%-90% IPv6, in turn the total ISP traffic reaches similar levels. So asking for 50% seems to me conservative, but I?m happy for lower levels, if we agree that we can ask for more later on. We can even consider something like 25% after 12 months, 50% after 24 months, 75% after 48 months. Just an example. Finally, as we have many policies that AFRINIC not necessarily is measuring the compliance, that?s what the other proposal (compliance dashboard) was already trying to resolve, now in a ?light? version. This proposal also added a trigger (failure to comply) to ensure that abuse (requesting IPv4, but then not deploying IPv6) can enact the RSA terms, because clearly shows that there is a policy breach. By the way, dynamic prefixes in IPv6 is broken, terrible idea, specially if there are power outages. I suggest to read what, hopefully in a few months, will become in RFC/BCP a successor of RIPE690: https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/ Regards, Jordi @jordipalet El 28 may 2026, a las 11:43, Jaco Kroon escribi?: Hi Jordi, I support the principle very much. Practicality may be a different story, yes, must implement v6, however: How do you determine/measure that? I think your "In addition" section addresses this to a degree. Merely advertising IPv6 space? Sure, that's easy, but it doesn't mean I have to actually make that available to customers. Re proposed text, the word "However, " doesn't add value, merely "Any IPv4 request must be done with a simultaneous IPv6 request if the requesting party does not already have IPv6 space." This does also be the question, it seems 6.5.1.1.3 states that you must give /48s to end sites - we do distinguish between business and home users, for business we happily do /48 if so required (at least we reserve a /48 per site minimum), but for home users we generally do dynamically allocated /56 (but will again do /48 on request) - would this imply failure to comply with your proposed policy? If so, should the proposed policy be adjusted, or 6.5.1.1.3? For PI space (6.8.2.2.d) - what does deployed mean? Kind regards, Jaco Kroon On 2026/05/28 10:28, jordi.palet--- via RPD wrote: Hi all, Somehow this is a response to Sami input on a previous proposal. This way we can split the problem space in 2 proposals, which may reach consensus without depending one on the other. So we have a very basic question: If we believe that the members that receive IPv4 out of the Soft Landing policy, must implement IPv6, or not? Regards, Jordi @jordipalet El 28 may 2026, a las 10:05, Darwin Da Costa escribi?: Dear PDWG, We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: https://afrinic.net/afpub-2026-v6-001-draft01 We encourage you to take some time to go through the proposal contents and provide feedback as follows: a)Do you support or oppose the proposal? b) If you oppose the proposal, state your reasons? c) Is there anything in the proposal that is not clear? d) What changes could be made to this proposal to make it more effective? Regards, Vincent Ngundi & Darwin Da Costa AFRINIC PDWG Co-Chairs _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd -- Mark James ELKINS - Posix Systems - (South) Africa mje at posix.co.za Tel: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From benson_muite at emailplus.org Fri Jun 26 04:16:00 2026 From: benson_muite at emailplus.org (Benson Muite) Date: Fri, 26 Jun 2026 07:16:00 +0300 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: <62C7A878-5533-46BE-8B44-BD8651F574E1@gmail.com> Message-ID: <878q827x8f.fsf@emailplus.org> "jordi.palet--- via RPD" writes: > Hi Seun, > > I will actually say personally, the only acceptable X=1, but happy to concede with 2. Hopefully we don?t have a discussion and every participant chose a different number, as this is the typical issue when asking for a decision of ?number of whatever? in trying to reach consensus. The low adoption rate is worrying. Clear criteria to justify IPv4 maybe helpful. If one gets IPv4, IPv6 is free. It is good that Afrinic is doing outreach to universities. From Africa Gabon seems to have the highest percentage capability: https://stats.labs.apnic.net/ipv6 India also has good adoption and a diverse set of people in the internet industry. Understanding what has lead to adoption in these places may help guide whether what new policies sohuld be adopted if any and how to complement these with outreach and education activities. > > I will also say that X is only for ?single? allocations/assigments, in the sense that if you are doing something for HA (one of the policies that reached consensus yesterday), you must do it with IPv6. There is no sense that you deploy, today, an HA infrastructure without IPv6. What do you think ? > > Regards, > Jordi > > @jordipalet > >> El 25 jun 2026, a las 2:37, Seun Ojedeji escribi?: >> >> Hi Jordi, >> >> ---- >> Sent from my mobile >> kindly excuse typos >> >> On Wed, 24 Jun 2026, 6:14?pm jordi.palet--- via RPD, > wrote: >>> . >>> >>> So there is no difference in now setting a policy that clearly say, you get more IPv4, but you must also deploy IPv6. >>> >>> We could also do something slightly different, I?m not sure if this is what Seun tried to say in the mic earlier this afternoon. >>> >>> We don?t give any more IPv4 resources if you already got them previously. This has been done by most of the other RIRs. Will you agree with that? Only newcomers can get IPv4. >> >> >> SO: More like you don't get IPv4 resources if you already got it for X number of times in the current phase unless you meet the IPv6 deployment plan requirements. My intention is for X not !=Once >> >> Regards >>> >>> Now, as a 2nd part of the proposal, resources left (even recovered), can be provided to anyone who also deploy IPv6, regardless of being a newcomer or an existing member. >>> >>> What do you think? >>> >>> Regards, >>> Jordi >>> >>> @jordipalet From jordi.palet at consulintel.es Fri Jun 26 08:32:27 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Fri, 26 Jun 2026 10:32:27 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: <878q827x8f.fsf@emailplus.org> References: <62C7A878-5533-46BE-8B44-BD8651F574E1@gmail.com> <878q827x8f.fsf@emailplus.org> Message-ID: Hi Benson, Gabon is a good example of a good deployment in one of the ISPs (GVA), at least in terms of having a coherent % of traffic (I don?t know the rest of the details, for example prefix size to customers, if it is persistent, etc.), but if you look at the other ISPs, is not good ? Note that looking into a country is good as a generic rule, but the view of each big ISP is key. India is a unique case, and there is a special history behind. Very short: All started because the ?fight? among two brothers and the 2nd one of them starting telecom very late, when getting IPv4 was already impossible, so he decided to create an extensive IPv6-only network across the country an provide to customers a price with even free 3 trial months, that couldn?t be beaten by competitors. As a result, all the other competitors were somehow ?forced? to do IPv6 as well, together with some regulator actions. This kind of cases are difficult to repeat in other countries. But in general, despite country GDP, status of Internet penetration, etc., etc. (there is a good presentation about this from Geoff Huston), in the end, what it matters is when an ISP in a country deploy IPv6, others need to do the same, but not always happens immediately, because you don?t have the expertise in deployment. Trainings is often not enough, because this doesn?t give you deployment experience, and also most of the trainings provided worldwide, don?t have a real deployment expertise using the latest transition mechanisms. You can see the GVA case in Gabon, that shows what I?ve said during this week many times. Because most of the time 80-90% of your traffic is to big content providers, caches, CDNs, etc., and they already have enabled IPv6, when you turn on IPv6 in an ISP, you quickly get 80-90% of your traffic becoming IPv6. Of course, it depends on the pace of your deployment in terms of number of "deployed customers". Regards, Jordi @jordipalet > El 26 jun 2026, a las 6:16, Benson Muite escribi?: > > "jordi.palet--- via RPD" writes: > >> Hi Seun, >> >> I will actually say personally, the only acceptable X=1, but happy to concede with 2. Hopefully we don?t have a discussion and every participant chose a different number, as this is the typical issue when asking for a decision of ?number of whatever? in trying to reach consensus. > > The low adoption rate is worrying. Clear criteria to justify IPv4 > maybe helpful. If one gets IPv4, IPv6 is free. It is good that Afrinic > is doing outreach to universities. From Africa Gabon seems to have the > highest percentage capability: > https://stats.labs.apnic.net/ipv6 > India also has good adoption and a diverse set of people in the internet > industry. Understanding what has lead to adoption in these places may > help guide whether what new policies sohuld be adopted if any and how to > complement these with outreach and education activities. > > >> >> I will also say that X is only for ?single? allocations/assigments, in the sense that if you are doing something for HA (one of the policies that reached consensus yesterday), you must do it with IPv6. There is no sense that you deploy, today, an HA infrastructure without IPv6. What do you think ? >> >> Regards, >> Jordi >> >> @jordipalet >> >>> El 25 jun 2026, a las 2:37, Seun Ojedeji escribi?: >>> >>> Hi Jordi, >>> >>> ---- >>> Sent from my mobile >>> kindly excuse typos >>> >>> On Wed, 24 Jun 2026, 6:14?pm jordi.palet--- via RPD, > wrote: >>>> . >>>> >>>> So there is no difference in now setting a policy that clearly say, you get more IPv4, but you must also deploy IPv6. >>>> >>>> We could also do something slightly different, I?m not sure if this is what Seun tried to say in the mic earlier this afternoon. >>>> >>>> We don?t give any more IPv4 resources if you already got them previously. This has been done by most of the other RIRs. Will you agree with that? Only newcomers can get IPv4. >>> >>> >>> SO: More like you don't get IPv4 resources if you already got it for X number of times in the current phase unless you meet the IPv6 deployment plan requirements. My intention is for X not !=Once >>> >>> Regards >>>> >>>> Now, as a 2nd part of the proposal, resources left (even recovered), can be provided to anyone who also deploy IPv6, regardless of being a newcomer or an existing member. >>>> >>>> What do you think? >>>> >>>> Regards, >>>> Jordi >>>> >>>> @jordipalet ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From aalain at trstech.net Sat Jun 27 17:50:14 2026 From: aalain at trstech.net (ALAIN AINA) Date: Sat, 27 Jun 2026 20:50:14 +0300 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: <878q827x8f.fsf@emailplus.org> References: <62C7A878-5533-46BE-8B44-BD8651F574E1@gmail.com> <878q827x8f.fsf@emailplus.org> Message-ID: > On 26 Jun 2026, at 07:16, Benson Muite wrote: > > "jordi.palet--- via RPD" writes: > >> Hi Seun, >> >> I will actually say personally, the only acceptable X=1, but happy to concede with 2. Hopefully we don?t have a discussion and every participant chose a different number, as this is the typical issue when asking for a decision of ?number of whatever? in trying to reach consensus. > > The low adoption rate is worrying. Clear criteria to justify IPv4 > maybe helpful. If one gets IPv4, IPv6 is free. It is good that Afrinic > is doing outreach to universities. From Africa Gabon seems to have the > highest percentage capability: > https://stats.labs.apnic.net/ipv6 > India also has good adoption and a diverse set of people in the internet > industry. Understanding what has lead to adoption in these places may > help guide whether what new policies sohuld be adopted if any and how to > complement these with outreach and education activities. A few years ago, I published an analysis of IPv6 uptake in Africa, examining adoption from multiple angles, including infrastructure readiness, operator behaviour, and user?access patterns. One of the key findings was the positive impact of new market entrants, particularly those who deployed IPv6?capable networks from day one. That dynamic remains relevant today. Unfortunately, the overall situation has not changed significantly. The user?access layer continues to be the weakest point in the regional IPv6 ecosystem. Given that Africa?s Internet is overwhelmingly mobile?centric, meaningful progress depends on Mobile Internet Service Providers taking deliberate steps to enable IPv6 at scale. Without their participation, adoption will remain slow regardless of improvements elsewhere in the ecosystem. There are, however, some recent initiatives underway: - The ICANN grant to the African Telecommunications Union (ATU) to support IPv6 deployment in 30 African countries is a major development. - ATU has already published an interim implementation report, outlining early progress and challenges. These efforts complement AFRINIC?s ongoing outreach, including engagement with universities and technical communities. ----- https://www.digitalintelligence.africa/publications/alain/AFRICA-and-IPv6-uptake.html https://www.icann.org/en/grant-program/first-cycle-funded-projects#deployment-ipv6-african-countries https://atuuat.africa/wp-content/uploads/2026/02/ATU_IPv6_First_Interim_Status_Report_Sep-Dec_2025.pdf https://atuuat.africa/wp-content/uploads/2022/11/Africa-IPv6-Development-White-Paper_double-page-version.pdf ?Alain > > >> >> I will also say that X is only for ?single? allocations/assigments, in the sense that if you are doing something for HA (one of the policies that reached consensus yesterday), you must do it with IPv6. There is no sense that you deploy, today, an HA infrastructure without IPv6. What do you think ? >> >> Regards, >> Jordi >> >> @jordipalet >> >>> El 25 jun 2026, a las 2:37, Seun Ojedeji escribi?: >>> >>> Hi Jordi, >>> >>> ---- >>> Sent from my mobile >>> kindly excuse typos >>> >>> On Wed, 24 Jun 2026, 6:14?pm jordi.palet--- via RPD, > wrote: >>>> . >>>> >>>> So there is no difference in now setting a policy that clearly say, you get more IPv4, but you must also deploy IPv6. >>>> >>>> We could also do something slightly different, I?m not sure if this is what Seun tried to say in the mic earlier this afternoon. >>>> >>>> We don?t give any more IPv4 resources if you already got them previously. This has been done by most of the other RIRs. Will you agree with that? Only newcomers can get IPv4. >>> >>> >>> SO: More like you don't get IPv4 resources if you already got it for X number of times in the current phase unless you meet the IPv6 deployment plan requirements. My intention is for X not !=Once >>> >>> Regards >>>> >>>> Now, as a 2nd part of the proposal, resources left (even recovered), can be provided to anyone who also deploy IPv6, regardless of being a newcomer or an existing member. >>>> >>>> What do you think? >>>> >>>> Regards, >>>> Jordi >>>> >>>> @jordipalet > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From ben.roberts at afrinic.net Sat Jun 27 18:32:48 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Sat, 27 Jun 2026 21:32:48 +0300 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: Message-ID: <497AC0C6-09CF-4FE3-A6F9-B32690413A71@afrinic.net> Alain, I am with you on this. I was talking about this yesterday with someone. It seems we have been doing the same things with IPv6 capacity building for best part of 15 years and still it?s not really pushing (mass) adoption. Yet we keep doing the same things. ?.. Most Africans connect to the phone via mobile. Manu of them through the ?big 5? of African MNO groups. We need to focus our IPv6 efforts around 5 groups of MNOs plus 4 vendors (2 from China, 2 from Scandinavia). These 9 companies know who they are?. Some of them are represented here?. Then if they start deploying IPv6 then 700M Africans will be using IPv6 The rest will fall into place?. Cheers Ben Sent from my iPhone > On 27 Jun 2026, at 20:52, ALAIN AINA via RPD wrote: > > ? > >> On 26 Jun 2026, at 07:16, Benson Muite wrote: >> >> "jordi.palet--- via RPD" writes: >> >>> Hi Seun, >>> >>> I will actually say personally, the only acceptable X=1, but happy to concede with 2. Hopefully we don?t have a discussion and every participant chose a different number, as this is the typical issue when asking for a decision of ?number of whatever? in trying to reach consensus. >> >> The low adoption rate is worrying. Clear criteria to justify IPv4 >> maybe helpful. If one gets IPv4, IPv6 is free. It is good that Afrinic >> is doing outreach to universities. From Africa Gabon seems to have the >> highest percentage capability: >> https://stats.labs.apnic.net/ipv6 >> India also has good adoption and a diverse set of people in the internet >> industry. Understanding what has lead to adoption in these places may >> help guide whether what new policies sohuld be adopted if any and how to >> complement these with outreach and education activities. > > > A few years ago, I published an analysis of IPv6 uptake in Africa, examining adoption from multiple angles, including infrastructure readiness, operator behaviour, and user?access patterns. One of the key findings was the positive impact of new market entrants, particularly those who deployed IPv6?capable networks from day one. That dynamic remains relevant today. > > Unfortunately, the overall situation has not changed significantly. The user?access layer continues to be the weakest point in the regional IPv6 ecosystem. Given that Africa?s Internet is overwhelmingly mobile?centric, meaningful progress depends on Mobile Internet Service Providers taking deliberate steps to enable IPv6 at scale. Without their participation, adoption will remain slow regardless of improvements elsewhere in the ecosystem. > > There are, however, some recent initiatives underway: > - The ICANN grant to the African Telecommunications Union (ATU) to support IPv6 deployment in 30 African countries is a major development. > - ATU has already published an interim implementation report, outlining early progress and challenges. > > These efforts complement AFRINIC?s ongoing outreach, including engagement with universities and technical communities. > ----- > > https://www.digitalintelligence.africa/publications/alain/AFRICA-and-IPv6-uptake.html > https://www.icann.org/en/grant-program/first-cycle-funded-projects#deployment-ipv6-african-countries > https://atuuat.africa/wp-content/uploads/2026/02/ATU_IPv6_First_Interim_Status_Report_Sep-Dec_2025.pdf > https://atuuat.africa/wp-content/uploads/2022/11/Africa-IPv6-Development-White-Paper_double-page-version.pdf > > > ?Alain > > > > >> >> >>> >>> I will also say that X is only for ?single? allocations/assigments, in the sense that if you are doing something for HA (one of the policies that reached consensus yesterday), you must do it with IPv6. There is no sense that you deploy, today, an HA infrastructure without IPv6. What do you think ? >>> >>> Regards, >>> Jordi >>> >>> @jordipalet >>> >>>> El 25 jun 2026, a las 2:37, Seun Ojedeji escribi?: >>>> >>>> Hi Jordi, >>>> >>>> ---- >>>> Sent from my mobile >>>> kindly excuse typos >>>> >>>> On Wed, 24 Jun 2026, 6:14?pm jordi.palet--- via RPD, > wrote: >>>>> . >>>>> >>>>> So there is no difference in now setting a policy that clearly say, you get more IPv4, but you must also deploy IPv6. >>>>> >>>>> We could also do something slightly different, I?m not sure if this is what Seun tried to say in the mic earlier this afternoon. >>>>> >>>>> We don?t give any more IPv4 resources if you already got them previously. This has been done by most of the other RIRs. Will you agree with that? Only newcomers can get IPv4. >>>> >>>> >>>> SO: More like you don't get IPv4 resources if you already got it for X number of times in the current phase unless you meet the IPv6 deployment plan requirements. My intention is for X not !=Once >>>> >>>> Regards >>>>> >>>>> Now, as a 2nd part of the proposal, resources left (even recovered), can be provided to anyone who also deploy IPv6, regardless of being a newcomer or an existing member. >>>>> >>>>> What do you think? >>>>> >>>>> Regards, >>>>> Jordi >>>>> >>>>> @jordipalet >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From jordi.palet at consulintel.es Sun Jun 28 09:14:47 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Sun, 28 Jun 2026 11:14:47 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: <497AC0C6-09CF-4FE3-A6F9-B32690413A71@afrinic.net> References: <497AC0C6-09CF-4FE3-A6F9-B32690413A71@afrinic.net> Message-ID: Fortunately, deploying 464XLAT in mobile networks (the only way to go) is much easier and cheaper than in wireline. Vendors of both UEs and packet switch mobile networks support it very well since many years ago. The point, as usual, is to have the expertise and not trust what vendors try to sell you. Is not just a matter of teaching IPv6. In a training you don?t get the experience. There is a good reason why consultancy companies have a business: it is much cheaper to trust an experienced consultant (vendor independent) than a vendor and you avoid all the mistakes of lack of experience. Regards, Jordi @jordipalet > El 27 jun 2026, a las 20:32, Ben Roberts - AfriNIC via RPD escribi?: > > Alain, > I am with you on this. > I was talking about this yesterday with someone. It seems we have been doing the same things with IPv6 capacity building for best part of 15 years and still it?s not really pushing (mass) adoption. Yet we keep doing the same things. ?.. > > Most Africans connect to the phone via mobile. Manu of them through the ?big 5? of African MNO groups. > > We need to focus our IPv6 efforts around 5 groups of MNOs plus 4 vendors (2 from China, 2 from Scandinavia). > > These 9 companies know who they are?. Some of them are represented here?. > > Then if they start deploying IPv6 then 700M Africans will be using IPv6 > > The rest will fall into place?. > > Cheers > > Ben > > > Sent from my iPhone > >> On 27 Jun 2026, at 20:52, ALAIN AINA via RPD wrote: >> >> ? >> >>> On 26 Jun 2026, at 07:16, Benson Muite wrote: >>> >>> "jordi.palet--- via RPD" writes: >>> >>>> Hi Seun, >>>> >>>> I will actually say personally, the only acceptable X=1, but happy to concede with 2. Hopefully we don?t have a discussion and every participant chose a different number, as this is the typical issue when asking for a decision of ?number of whatever? in trying to reach consensus. >>> >>> The low adoption rate is worrying. Clear criteria to justify IPv4 >>> maybe helpful. If one gets IPv4, IPv6 is free. It is good that Afrinic >>> is doing outreach to universities. From Africa Gabon seems to have the >>> highest percentage capability: >>> https://stats.labs.apnic.net/ipv6 >>> India also has good adoption and a diverse set of people in the internet >>> industry. Understanding what has lead to adoption in these places may >>> help guide whether what new policies sohuld be adopted if any and how to >>> complement these with outreach and education activities. >> >> >> A few years ago, I published an analysis of IPv6 uptake in Africa, examining adoption from multiple angles, including infrastructure readiness, operator behaviour, and user?access patterns. One of the key findings was the positive impact of new market entrants, particularly those who deployed IPv6?capable networks from day one. That dynamic remains relevant today. >> >> Unfortunately, the overall situation has not changed significantly. The user?access layer continues to be the weakest point in the regional IPv6 ecosystem. Given that Africa?s Internet is overwhelmingly mobile?centric, meaningful progress depends on Mobile Internet Service Providers taking deliberate steps to enable IPv6 at scale. Without their participation, adoption will remain slow regardless of improvements elsewhere in the ecosystem. >> >> There are, however, some recent initiatives underway: >> - The ICANN grant to the African Telecommunications Union (ATU) to support IPv6 deployment in 30 African countries is a major development. >> - ATU has already published an interim implementation report, outlining early progress and challenges. >> >> These efforts complement AFRINIC?s ongoing outreach, including engagement with universities and technical communities. >> ----- >> >> https://www.digitalintelligence.africa/publications/alain/AFRICA-and-IPv6-uptake.html >> https://www.icann.org/en/grant-program/first-cycle-funded-projects#deployment-ipv6-african-countries >> https://atuuat.africa/wp-content/uploads/2026/02/ATU_IPv6_First_Interim_Status_Report_Sep-Dec_2025.pdf >> https://atuuat.africa/wp-content/uploads/2022/11/Africa-IPv6-Development-White-Paper_double-page-version.pdf >> >> >> ?Alain >> >> >> >> >>> >>> >>>> >>>> I will also say that X is only for ?single? allocations/assigments, in the sense that if you are doing something for HA (one of the policies that reached consensus yesterday), you must do it with IPv6. There is no sense that you deploy, today, an HA infrastructure without IPv6. What do you think ? >>>> >>>> Regards, >>>> Jordi >>>> >>>> @jordipalet >>>> >>>>> El 25 jun 2026, a las 2:37, Seun Ojedeji escribi?: >>>>> >>>>> Hi Jordi, >>>>> >>>>> ---- >>>>> Sent from my mobile >>>>> kindly excuse typos >>>>> >>>>> On Wed, 24 Jun 2026, 6:14?pm jordi.palet--- via RPD, > wrote: >>>>>> . >>>>>> >>>>>> So there is no difference in now setting a policy that clearly say, you get more IPv4, but you must also deploy IPv6. >>>>>> >>>>>> We could also do something slightly different, I?m not sure if this is what Seun tried to say in the mic earlier this afternoon. >>>>>> >>>>>> We don?t give any more IPv4 resources if you already got them previously. This has been done by most of the other RIRs. Will you agree with that? Only newcomers can get IPv4. >>>>> >>>>> >>>>> SO: More like you don't get IPv4 resources if you already got it for X number of times in the current phase unless you meet the IPv6 deployment plan requirements. My intention is for X not !=Once >>>>> >>>>> Regards >>>>>> >>>>>> Now, as a 2nd part of the proposal, resources left (even recovered), can be provided to anyone who also deploy IPv6, regardless of being a newcomer or an existing member. >>>>>> >>>>>> What do you think? >>>>>> >>>>>> Regards, >>>>>> Jordi >>>>>> >>>>>> @jordipalet >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From comms at afrinic.net Mon Jun 29 05:58:55 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Mon, 29 Jun 2026 09:58:55 +0400 Subject: [rpd] Thank You to Darwin Da Costa and Dr Vincent Ngundi for Your Service to the AFRINIC Community Message-ID: Dear Colleagues, AFRINIC would like to express our sincere appreciation to Darwin Da Costa and Dr Vincent Ngundi for their dedicated service and valuable contributions to the AFRINIC community over the past five years. Throughout their tenure, both Darwin Da Costa and Dr Vincent Ngundi have played important roles in supporting and strengthening AFRINIC's Resource Policy Development Process (PDP). Through their active leadership, thoughtful contributions, and commitment to constructive dialogue, they have helped advance discussions on Internet number resource policies and contributed to preserving the open, transparent, and community-driven nature of the policy development process. The success of AFRINIC's multistakeholder model depends on the willingness of community members to contribute their time, expertise, and experience for the benefit of the broader African Internet ecosystem. Darwin Da Costa and Dr. Vincent Ngundi have consistently demonstrated this commitment, helping to foster informed discussions, encourage community participation, and support consensus-building within the AFRINIC community. We would also like to express our sincere gratitude to both Darwin Da Costa and Dr. Vincent Ngundi for their willingness to continue supporting the Policy Development Process by working alongside Hytham El Nakhal, the incoming Co-Chair, until the next Public Policy Meeting (PPM). Their commitment to ensuring continuity, sharing their experience, and supporting a smooth handover reflects the spirit of service and collaboration that has long characterised the AFRINIC community. We wish Darwin Da Costa and Dr. Vincent Ngundi every success in their future endeavours and look forward to their continued engagement within the African Internet ecosystem. Please join us in thanking them for their service, their contributions, and their continued support to the AFRINIC Policy Development Process. Kind regards, AFRINIC -------------- next part -------------- An HTML attachment was scrubbed... URL: From sami.salih at outlook.com Mon Jun 29 06:39:48 2026 From: sami.salih at outlook.com (Sami Salih) Date: Mon, 29 Jun 2026 06:39:48 +0000 Subject: [rpd] Thank You to Darwin Da Costa and Dr Vincent Ngundi for Your Service to the AFRINIC Community In-Reply-To: References: Message-ID: Thank you, Darwin and Vincent, for your exceptional leadership, dedication, and service as Co-Chairs of the Policy Development Working Group. Your commitment to an open, transparent, and collaborative Policy Development Process has made a lasting contribution to the AFRINIC community and the African Internet ecosystem. Thank you also for your continued support in ensuring a smooth transition. Wishing you both every success in your future endeavours. A warm welcome back to Hytham El Nakhal as the returning PDWG Co-Chair. Wishing you every success in your renewed role, and every success in leading the Policy Development Working Group as it continues to serve the AFRINIC community. Sami Salih ________________________________ From: AFRINIC Communication via RPD Sent: Monday, 29 June 2026 08:58:55 To: rpd Subject: [rpd] Thank You to Darwin Da Costa and Dr Vincent Ngundi for Your Service to the AFRINIC Community Dear Colleagues, AFRINIC would like to express our sincere appreciation to Darwin Da Costa and Dr Vincent Ngundi for their dedicated service and valuable contributions to the AFRINIC community over the past five years. Throughout their tenure, both Darwin Da Costa and Dr Vincent Ngundi have played important roles in supporting and strengthening AFRINIC's Resource Policy Development Process (PDP). Through their active leadership, thoughtful contributions, and commitment to constructive dialogue, they have helped advance discussions on Internet number resource policies and contributed to preserving the open, transparent, and community-driven nature of the policy development process. The success of AFRINIC's multistakeholder model depends on the willingness of community members to contribute their time, expertise, and experience for the benefit of the broader African Internet ecosystem. Darwin Da Costa and Dr. Vincent Ngundi have consistently demonstrated this commitment, helping to foster informed discussions, encourage community participation, and support consensus-building within the AFRINIC community. We would also like to express our sincere gratitude to both Darwin Da Costa and Dr. Vincent Ngundi for their willingness to continue supporting the Policy Development Process by working alongside Hytham El Nakhal, the incoming Co-Chair, until the next Public Policy Meeting (PPM). Their commitment to ensuring continuity, sharing their experience, and supporting a smooth handover reflects the spirit of service and collaboration that has long characterised the AFRINIC community. We wish Darwin Da Costa and Dr. Vincent Ngundi every success in their future endeavours and look forward to their continued engagement within the African Internet ecosystem. Please join us in thanking them for their service, their contributions, and their continued support to the AFRINIC Policy Development Process. Kind regards, AFRINIC -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Mon Jun 29 18:56:50 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Mon, 29 Jun 2026 20:56:50 +0200 Subject: [rpd] Welcome to the "RPD" mailing list (Digest mode) In-Reply-To: References: Message-ID: Good day, I would like to post to the RPD mailing list. Kindly allow me this wonderful opportunity of being part of the RPD AFRINIC Policy Discussions. BR, Nonhlanhla On Mon, 29 Jun 2026, 8:52 pm wrote: > Welcome to the RPD at afrinic.net mailing list! > > To post to this list, send your message to: > > rpd at afrinic.net > > General information about the mailing list is at: > > https://lists.afrinic.net/mailman/listinfo/rpd > > If you ever want to unsubscribe or change your options (eg, switch to > or from digest mode, change your password, etc.), visit your > subscription page at: > > > https://lists.afrinic.net/mailman/options/rpd/nonhlanhlapetronella85%40gmail.com > > > You can also make such adjustments via email by sending a message to: > > RPD-request at afrinic.net > > with the word `help' in the subject or body (don't include the > quotes), and you will get back a message with instructions. > > You must know your password to change your options (including changing > the password, itself) or to unsubscribe without confirmation. It is: > > Physic at l45 > > Normally, Mailman will remind you of your afrinic.net mailing list > passwords once every month, although you can disable this if you > prefer. This reminder will also include instructions on how to > unsubscribe or change your account options. There is also a button on > your options page that will email your current password to you. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From christianbope at gmail.com Tue Jun 30 07:12:50 2026 From: christianbope at gmail.com (Bope Domilongo Christian) Date: Tue, 30 Jun 2026 09:12:50 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: <497AC0C6-09CF-4FE3-A6F9-B32690413A71@afrinic.net> Message-ID: Hi Jordi, If the solution is to convince the MNOs (Mobile Network Operators) to hire and trust *"vendor- neutral"* consultants for their IPv6 deployment, why are we trying to use IPv6 as a condition to IPv4 at AFRINIC? I am also interested in knowing how the *"vendor-neutral consultants"* get their experience in deploying IPv6 in Mobile Network from? @christianbope On Sun, 28 Jun 2026 at 11:16, jordi.palet--- via RPD wrote: > Fortunately, deploying 464XLAT in mobile networks (the only way to go) is > much easier and cheaper than in wireline. Vendors of both UEs and packet > switch mobile networks support it very well since many years ago. The > point, as usual, is to have the expertise and not trust what vendors try to > sell you. > > Is not just a matter of teaching IPv6. In a training you don?t get the > experience. There is a good reason why consultancy companies have a > business: it is much cheaper to trust an experienced consultant (vendor > independent) than a vendor and you avoid all the mistakes of lack of > experience. > > Regards, > Jordi > > @jordipalet > > > El 27 jun 2026, a las 20:32, Ben Roberts - AfriNIC via RPD < > rpd at afrinic.net> escribi?: > > > > Alain, > > I am with you on this. > > I was talking about this yesterday with someone. It seems we have been > doing the same things with IPv6 capacity building for best part of 15 years > and still it?s not really pushing (mass) adoption. Yet we keep doing the > same things. ?.. > > > > Most Africans connect to the phone via mobile. Manu of them through the > ?big 5? of African MNO groups. > > > > We need to focus our IPv6 efforts around 5 groups of MNOs plus 4 vendors > (2 from China, 2 from Scandinavia). > > > > These 9 companies know who they are?. Some of them are represented > here?. > > > > Then if they start deploying IPv6 then 700M Africans will be using IPv6 > > > > The rest will fall into place?. > > > > Cheers > > > > Ben > > > > > > Sent from my iPhone > > > >> On 27 Jun 2026, at 20:52, ALAIN AINA via RPD wrote: > >> > >> ? > >> > >>> On 26 Jun 2026, at 07:16, Benson Muite > wrote: > >>> > >>> "jordi.palet--- via RPD" writes: > >>> > >>>> Hi Seun, > >>>> > >>>> I will actually say personally, the only acceptable X=1, but happy to > concede with 2. Hopefully we don?t have a discussion and every participant > chose a different number, as this is the typical issue when asking for a > decision of ?number of whatever? in trying to reach consensus. > >>> > >>> The low adoption rate is worrying. Clear criteria to justify IPv4 > >>> maybe helpful. If one gets IPv4, IPv6 is free. It is good that > Afrinic > >>> is doing outreach to universities. From Africa Gabon seems to have the > >>> highest percentage capability: > >>> https://stats.labs.apnic.net/ipv6 > >>> India also has good adoption and a diverse set of people in the > internet > >>> industry. Understanding what has lead to adoption in these places may > >>> help guide whether what new policies sohuld be adopted if any and how > to > >>> complement these with outreach and education activities. > >> > >> > >> A few years ago, I published an analysis of IPv6 uptake in Africa, > examining adoption from multiple angles, including infrastructure > readiness, operator behaviour, and user?access patterns. One of the key > findings was the positive impact of new market entrants, particularly those > who deployed IPv6?capable networks from day one. That dynamic remains > relevant today. > >> > >> Unfortunately, the overall situation has not changed significantly. The > user?access layer continues to be the weakest point in the regional IPv6 > ecosystem. Given that Africa?s Internet is overwhelmingly mobile?centric, > meaningful progress depends on Mobile Internet Service Providers taking > deliberate steps to enable IPv6 at scale. Without their participation, > adoption will remain slow regardless of improvements elsewhere in the > ecosystem. > >> > >> There are, however, some recent initiatives underway: > >> - The ICANN grant to the African Telecommunications Union (ATU) to > support IPv6 deployment in 30 African countries is a major development. > >> - ATU has already published an interim implementation report, > outlining early progress and challenges. > >> > >> These efforts complement AFRINIC?s ongoing outreach, including > engagement with universities and technical communities. > >> ----- > >> > >> > https://www.digitalintelligence.africa/publications/alain/AFRICA-and-IPv6-uptake.html > >> > https://www.icann.org/en/grant-program/first-cycle-funded-projects#deployment-ipv6-african-countries > >> > https://atuuat.africa/wp-content/uploads/2026/02/ATU_IPv6_First_Interim_Status_Report_Sep-Dec_2025.pdf > >> > https://atuuat.africa/wp-content/uploads/2022/11/Africa-IPv6-Development-White-Paper_double-page-version.pdf > >> > >> > >> ?Alain > >> > >> > >> > >> > >>> > >>> > >>>> > >>>> I will also say that X is only for ?single? allocations/assigments, > in the sense that if you are doing something for HA (one of the policies > that reached consensus yesterday), you must do it with IPv6. There is no > sense that you deploy, today, an HA infrastructure without IPv6. What do > you think ? > >>>> > >>>> Regards, > >>>> Jordi > >>>> > >>>> @jordipalet > >>>> > >>>>> El 25 jun 2026, a las 2:37, Seun Ojedeji > escribi?: > >>>>> > >>>>> Hi Jordi, > >>>>> > >>>>> ---- > >>>>> Sent from my mobile > >>>>> kindly excuse typos > >>>>> > >>>>> On Wed, 24 Jun 2026, 6:14?pm jordi.palet--- via RPD, < > rpd at afrinic.net > wrote: > >>>>>> . > >>>>>> > >>>>>> So there is no difference in now setting a policy that clearly say, > you get more IPv4, but you must also deploy IPv6. > >>>>>> > >>>>>> We could also do something slightly different, I?m not sure if this > is what Seun tried to say in the mic earlier this afternoon. > >>>>>> > >>>>>> We don?t give any more IPv4 resources if you already got them > previously. This has been done by most of the other RIRs. Will you agree > with that? Only newcomers can get IPv4. > >>>>> > >>>>> > >>>>> SO: More like you don't get IPv4 resources if you already got it for > X number of times in the current phase unless you meet the IPv6 deployment > plan requirements. My intention is for X not !=Once > >>>>> > >>>>> Regards > >>>>>> > >>>>>> Now, as a 2nd part of the proposal, resources left (even > recovered), can be provided to anyone who also deploy IPv6, regardless of > being a newcomer or an existing member. > >>>>>> > >>>>>> What do you think? > >>>>>> > >>>>>> Regards, > >>>>>> Jordi > >>>>>> > >>>>>> @jordipalet > >>> > >>> _______________________________________________ > >>> RPD mailing list > >>> RPD at afrinic.net > >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> > >> > >> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Tue Jun 30 08:18:09 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Tue, 30 Jun 2026 10:18:09 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: <497AC0C6-09CF-4FE3-A6F9-B32690413A71@afrinic.net> Message-ID: <1403CD0F-9F3F-4815-92BE-D28B94C87E82@consulintel.es> Hi Christian, Those are two different things and there is not a single solution. I think a strong position is needed to clearly pass the message: You can?t just live with IPv4 anymore, you must do IPv6; you may need a few extra IPv4 addresses, but you get the if you also do IPv6. My experience, in general for many years in the industry, not just with IPv6, is that vendors try to sell you their own solution, which not necessarily is the best one in each case, that?s why I advocate for not getting the consultancy tasks done by vendors, but someone which is vendor-neutral. As in any other job, you get the experience having done that many times probably starting with labs, finding your errors, fixing them and ensuring that in a production environment all works as expected and with a profound knowledge in standards to do it right. Regards, Jordi @jordipalet > El 30 jun 2026, a las 9:12, Bope Domilongo Christian escribi?: > > Hi Jordi, > > If the solution is to convince the MNOs (Mobile Network Operators) to hire and trust "vendor- neutral" consultants for their IPv6 deployment, why are we trying to use IPv6 as a condition to IPv4 at AFRINIC? I am also interested in knowing how the "vendor-neutral consultants" get their experience in deploying IPv6 in Mobile Network from? > > @christianbope <> > On Sun, 28 Jun 2026 at 11:16, jordi.palet--- via RPD > wrote: >> Fortunately, deploying 464XLAT in mobile networks (the only way to go) is much easier and cheaper than in wireline. Vendors of both UEs and packet switch mobile networks support it very well since many years ago. The point, as usual, is to have the expertise and not trust what vendors try to sell you. >> >> Is not just a matter of teaching IPv6. In a training you don?t get the experience. There is a good reason why consultancy companies have a business: it is much cheaper to trust an experienced consultant (vendor independent) than a vendor and you avoid all the mistakes of lack of experience. >> >> Regards, >> Jordi >> >> @jordipalet >> >> > El 27 jun 2026, a las 20:32, Ben Roberts - AfriNIC via RPD > escribi?: >> > >> > Alain, >> > I am with you on this. >> > I was talking about this yesterday with someone. It seems we have been doing the same things with IPv6 capacity building for best part of 15 years and still it?s not really pushing (mass) adoption. Yet we keep doing the same things. ?.. >> > >> > Most Africans connect to the phone via mobile. Manu of them through the ?big 5? of African MNO groups. >> > >> > We need to focus our IPv6 efforts around 5 groups of MNOs plus 4 vendors (2 from China, 2 from Scandinavia). >> > >> > These 9 companies know who they are?. Some of them are represented here?. >> > >> > Then if they start deploying IPv6 then 700M Africans will be using IPv6 >> > >> > The rest will fall into place?. >> > >> > Cheers >> > >> > Ben >> > >> > >> > Sent from my iPhone >> > >> >> On 27 Jun 2026, at 20:52, ALAIN AINA via RPD > wrote: >> >> >> >> ? >> >> >> >>> On 26 Jun 2026, at 07:16, Benson Muite > wrote: >> >>> >> >>> "jordi.palet--- via RPD" > writes: >> >>> >> >>>> Hi Seun, >> >>>> >> >>>> I will actually say personally, the only acceptable X=1, but happy to concede with 2. Hopefully we don?t have a discussion and every participant chose a different number, as this is the typical issue when asking for a decision of ?number of whatever? in trying to reach consensus. >> >>> >> >>> The low adoption rate is worrying. Clear criteria to justify IPv4 >> >>> maybe helpful. If one gets IPv4, IPv6 is free. It is good that Afrinic >> >>> is doing outreach to universities. From Africa Gabon seems to have the >> >>> highest percentage capability: >> >>> https://stats.labs.apnic.net/ipv6 >> >>> India also has good adoption and a diverse set of people in the internet >> >>> industry. Understanding what has lead to adoption in these places may >> >>> help guide whether what new policies sohuld be adopted if any and how to >> >>> complement these with outreach and education activities. >> >> >> >> >> >> A few years ago, I published an analysis of IPv6 uptake in Africa, examining adoption from multiple angles, including infrastructure readiness, operator behaviour, and user?access patterns. One of the key findings was the positive impact of new market entrants, particularly those who deployed IPv6?capable networks from day one. That dynamic remains relevant today. >> >> >> >> Unfortunately, the overall situation has not changed significantly. The user?access layer continues to be the weakest point in the regional IPv6 ecosystem. Given that Africa?s Internet is overwhelmingly mobile?centric, meaningful progress depends on Mobile Internet Service Providers taking deliberate steps to enable IPv6 at scale. Without their participation, adoption will remain slow regardless of improvements elsewhere in the ecosystem. >> >> >> >> There are, however, some recent initiatives underway: >> >> - The ICANN grant to the African Telecommunications Union (ATU) to support IPv6 deployment in 30 African countries is a major development. >> >> - ATU has already published an interim implementation report, outlining early progress and challenges. >> >> >> >> These efforts complement AFRINIC?s ongoing outreach, including engagement with universities and technical communities. >> >> ----- >> >> >> >> https://www.digitalintelligence.africa/publications/alain/AFRICA-and-IPv6-uptake.html >> >> https://www.icann.org/en/grant-program/first-cycle-funded-projects#deployment-ipv6-african-countries >> >> https://atuuat.africa/wp-content/uploads/2026/02/ATU_IPv6_First_Interim_Status_Report_Sep-Dec_2025.pdf >> >> https://atuuat.africa/wp-content/uploads/2022/11/Africa-IPv6-Development-White-Paper_double-page-version.pdf >> >> >> >> >> >> ?Alain >> >> >> >> >> >> >> >> >> >>> >> >>> >> >>>> >> >>>> I will also say that X is only for ?single? allocations/assigments, in the sense that if you are doing something for HA (one of the policies that reached consensus yesterday), you must do it with IPv6. There is no sense that you deploy, today, an HA infrastructure without IPv6. What do you think ? >> >>>> >> >>>> Regards, >> >>>> Jordi >> >>>> >> >>>> @jordipalet >> >>>> >> >>>>> El 25 jun 2026, a las 2:37, Seun Ojedeji > escribi?: >> >>>>> >> >>>>> Hi Jordi, >> >>>>> >> >>>>> ---- >> >>>>> Sent from my mobile >> >>>>> kindly excuse typos >> >>>>> >> >>>>> On Wed, 24 Jun 2026, 6:14?pm jordi.palet--- via RPD, >> wrote: >> >>>>>> . >> >>>>>> >> >>>>>> So there is no difference in now setting a policy that clearly say, you get more IPv4, but you must also deploy IPv6. >> >>>>>> >> >>>>>> We could also do something slightly different, I?m not sure if this is what Seun tried to say in the mic earlier this afternoon. >> >>>>>> >> >>>>>> We don?t give any more IPv4 resources if you already got them previously. This has been done by most of the other RIRs. Will you agree with that? Only newcomers can get IPv4. >> >>>>> >> >>>>> >> >>>>> SO: More like you don't get IPv4 resources if you already got it for X number of times in the current phase unless you meet the IPv6 deployment plan requirements. My intention is for X not !=Once >> >>>>> >> >>>>> Regards >> >>>>>> >> >>>>>> Now, as a 2nd part of the proposal, resources left (even recovered), can be provided to anyone who also deploy IPv6, regardless of being a newcomer or an existing member. >> >>>>>> >> >>>>>> What do you think? >> >>>>>> >> >>>>>> Regards, >> >>>>>> Jordi >> >>>>>> >> >>>>>> @jordipalet >> >>> >> >>> _______________________________________________ >> >>> RPD mailing list >> >>> RPD at afrinic.net >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> >> >> >> >> _______________________________________________ >> >> RPD mailing list >> >> RPD at afrinic.net >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> > >> > _______________________________________________ >> > RPD mailing list >> > RPD at afrinic.net >> > https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Tue Jun 30 08:42:31 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Tue, 30 Jun 2026 10:42:31 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> <75E8A336-B72B-4AE6-8EB0-CC25C75AE878@consulintel.es> Message-ID: Hi Jordi, As per my previous emails on the matter I agree with the message, but based on the below, not with the implementation.? Mostly referencing your original email I think the way you're proposing adds a significant cost to smaller network operators in particular which is money that could be better spent actually rolling out IPv6 or in other ways improving networks. I'm not sure the alternative options.? As an example, 100% of our clients, primarily consumer clients, has IPv6 available for use from ourselves.? We offer IPv6 on the entirety of our active ethernet networks by way of active RA + DHCPv6, as well as all dial-in options.? In spite of pressuring customers, we find they actively switch off IPv6 where they see it, and they will actively inform you when you request they switch it on to back off or they'll move to a different ISP that won't put this pressure on them. Various different reasons are provided, ranging from the absurd to the more absurd.? The middle-arguments are in the "IPv6 puts public addresses on my devices and I don't want that". Do you want to now punish the smaller players because they're struggling to get to 50% IPv6 uptake?? Even with the above in place, we're struggling to keep it active at >20% clients that at least take a PD from us.? Whether or not that's then actually deployed internally in their network is yet another matter. My problem with the proposal isn't that it needs to be deployed, we have it deployed.? There is one single /29 network where we have in play that doesn't have IPv6 also deployed, mostly because of the function thereof IPv6 cannot functionally be deployed there (the moment it makes sense you can be guaranteed we'll have it done in a week).? Therefore I consider our network to be as close to 100% deployed as can be, however, our downstream networks is a different matter, with as stated, around 20%. You're now forcing me towards LNS because I won't be able to obtain additional resources because my customers are being stubborn.? This just incurs further costs, both in terms of capex to procure (likely build) the equipment as well as opex in terms of running costs (primarily rack space and electricity, but also support staff training and additional complexity). Further in threads there were mention about top 25 sites etc ... all of that is highly impractical to measure for most networks. Kind regards, Jaco On 2026/05/28 12:21, jordi.palet--- via RPD wrote: > Hi Jaco, > > Tks, next version will use: ?Any IPv4 request must be done with a > simultaneous IPv6 request if the requesting party does not already > have IPv6 space.? This may depend on the impact analysis inputs, of > course. > > About the determination/measurement that this is being done, let me > explain how I see this. > > The existing 6.5.1.1 (for LIRs) and 6.8.2, already set the conditions > to be met. AFRINIC already has, in both cases, a 12 months period to > confirm the deployment. May be is not sufficiently clear there if > AFRINIC should do something if that?s not actually done. We aren?t > talking there only about announcing the prefix, but also in the case > of LIRs, about making assignments to end-sites, and the text is clear, > /48s, nothing different. There is no reason for using different sizes > for different type of customers on that text. There is no technical > reason at all for not doing it correctly, however, this is a > discussion for amending that part of the policy, not for this proposal. > > What this proposal wants to make sure is that you *actually*, > *following existing policy*, if you get IPv4, you really deploy IPv6 > in 12 months. To reinforce it I explicitly mention ?In addition ??, as > you said. Note that ?in addition? section enforces a more detailed > work from the member requesting IPv4, to justify a credible IPv6 > addressing and deployment plan, this will be accepted or not by > AFRINIC, as with any request evaluation. > > For example, in many RIRs, not just AFRINIC, I?ve observed that many > members get by default a /32, even if they have 800.000 end-sites. > Clearly wrong, they didn?t have done any real addressing plan and they > will end up providing a single /64 to each end-site. If they do it > correctly, they will soon discover why they should use /48s, so with a > /32 they can only cover around 50.000 customers, which means that > typically for 800.000 of customers (depending on the topological > distribution of the network) will mean that they need a /27-/28. > > I don?t think nobody can say ?deploy? is not clear. If this is the > case, we can improve it, something like ?and IPv6 is actually being > used?. We can even set a minimum level of traffic, such as 50% for > example? Those that have deployed IPv6 know that, at least in the case > of residential and cellular customers, because most of the traffic > (typically 75-90%) is from big CDNs, caches, and contend providers > (all google, all Meta, Akamai and all the other CDNs), already provide > IPv6, when you turn on IPv6 in an end-site, the IPv6 traffic of that > end-site becomes 75%-90% IPv6, in turn the total ISP traffic reaches > similar levels. > > So asking for 50% seems to me conservative, but I?m happy for lower > levels, if we agree that we can ask for more later on. We can even > consider something like 25% after 12 months, 50% after 24 months, 75% > after 48 months. Just an example. > > Finally, as we have many policies that AFRINIC not necessarily is > measuring the compliance, that?s what the other proposal (compliance > dashboard) was already trying to resolve, now in a ?light? version. > > This proposal also added a trigger (failure to comply) to ensure that > abuse (requesting IPv4, but then not deploying IPv6) can enact the RSA > terms, because clearly shows that there is a policy breach. > > By the way, dynamic prefixes in IPv6 is broken, terrible idea, > specially if there are power outages. > > I suggest to read what, hopefully in a few months, will become in > RFC/BCP a successor of RIPE690: > > https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/ > > Regards, > Jordi > > @jordipalet > > >> El 28 may 2026, a las 11:43, Jaco Kroon escribi?: >> >> Hi Jordi, >> >> I support the principle very much.? Practicality may be a different >> story, yes, must implement v6, however: >> >> How do you determine/measure that?? I think your "In addition" >> section addresses this to a degree. >> >> Merely advertising IPv6 space?? Sure, that's easy, but it doesn't >> mean I have to actually make that available to customers. >> >> Re proposed text, the word "However, " doesn't add value, merely "Any >> IPv4 request must be done with a simultaneous IPv6 request if the >> requesting party does not already have IPv6 space." >> >> This does also be the question, it seems 6.5.1.1.3 states that you >> must give /48s to end sites - we do distinguish between business and >> home users, for business we happily do /48 if so required (at least >> we reserve a /48 per site minimum), but for home users we generally >> do dynamically allocated /56 (but will again do /48 on request) - >> would this imply failure to comply with your proposed policy?? If so, >> should the proposed policy be adjusted, or 6.5.1.1.3? >> >> For PI space (6.8.2.2.d) - what does deployed mean? >> >> Kind regards, >> Jaco Kroon >> >> On 2026/05/28 10:28, jordi.palet--- via RPD wrote: >> >>> Hi all, >>> >>> Somehow this is a response to Sami input on a previous proposal. >>> >>> This way we can split the problem space in 2 proposals, which may reach consensus without depending one on the other. >>> >>> So we have a very basic question: If we believe that the members that receive IPv4 out of the Soft Landing policy, must implement IPv6, or not? >>> >>> Regards, >>> Jordi >>> >>> @jordipalet >>> >>> >>>> El 28 may 2026, a las 10:05, Darwin Da Costa escribi?: >>>> >>>> Dear PDWG, >>>> >>>> We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >>>> >>>> https://afrinic.net/afpub-2026-v6-001-draft01 >>>> >>>> >>>> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >>>> >>>> a)Do you support or oppose the proposal? >>>> >>>> b) If you oppose the proposal, state your reasons? >>>> >>>> c) Is there anything in the proposal that is not clear? >>>> >>>> d) What changes could be made to this proposal to make it more effective? >>>> >>>> >>>> Regards, >>>> Vincent Ngundi & Darwin Da Costa >>>> AFRINIC PDWG Co-Chairs >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>> ********************************************** >>> IPv4 is over >>> Are you ready for the new Internet ? >>> http://www.theipv6company.com >>> The IPv6 Company >>> >>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >>> >>> >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive > use of the individual(s) named above and further non-explicilty > authorized disclosure, copying, distribution or use of the contents of > this information, even if partially, including attached files, is > strictly prohibited and will be considered a criminal offense. If you > are not the intended recipient be aware that any disclosure, copying, > distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited, will be > considered a criminal offense, so you must reply to the original > sender to inform about this communication and delete it. > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From saul at enetworks.co.za Tue Jun 30 10:09:03 2026 From: saul at enetworks.co.za (Saul Stein) Date: Tue, 30 Jun 2026 10:09:03 +0000 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> <75E8A336-B72B-4AE6-8EB0-CC25C75AE878@consulintel.es> Message-ID: Hi Jordi, Further to below and the discussion in Kenya: I am not wanting to get into the rights and wrongs of IPv6 deployment (we all know it is the right thing to do) and there are many things that we can debate as to what should one be doing verses reality 1. The proposal relies on to much manual intervention: * this is a manual process between AFRINIC and the member. * Not sure the practicality of this level of monitoring for many smaller ISPs. You say it is cheap, but there are always costs associated. Smaller ISPs are more focussed on building a business then netflow etc. (and don?t say that they need to be monitoring anyway ? maybe they are or maybe they aren?t) 2. Customer profile: * Broadband/home users aren?t a problem, there will be some traffic that will work over v6. But again, that depends on the ability of the FNO to be able to support IPV6. Sadly in South Africa, this is still not the case. * Where customer profile is B2B, the ISP as the provider is not in a position to be able to dictate their security and IP policies. * IPv6 adoption at the customer is a different discussion and becomes commercial. While ISPs have v4 space, If the ISP dictates v6 usage, then the customer will go so someone who doesn?t. that is the free world. Jordi, you keep beating on at how simple this is, yes, in your experience, your country, your customer base. That doesn?t translate into other regions. I do agree that we need better uptake. I have no issue with requiring v6 usage, but it needs to be practical, positive, sustainable and most important commercially viable ? we can?t force our customers to do something they don?t want to. My 2c Saul From: Jaco Kroon via RPD Sent: Tuesday, 30 June 2026 10:43 To: jordi.palet at consulintel.es; rpd at afrinic.net Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. Hi Jordi, As per my previous emails on the matter I agree with the message, but based on the below, not with the implementation. Mostly referencing your original email I think the way you're proposing adds a significant cost to smaller network operators in particular which is money that could be better spent actually rolling out IPv6 or in other ways improving networks. I'm not sure the alternative options. As an example, 100% of our clients, primarily consumer clients, has IPv6 available for use from ourselves. We offer IPv6 on the entirety of our active ethernet networks by way of active RA + DHCPv6, as well as all dial-in options. In spite of pressuring customers, we find they actively switch off IPv6 where they see it, and they will actively inform you when you request they switch it on to back off or they'll move to a different ISP that won't put this pressure on them. Various different reasons are provided, ranging from the absurd to the more absurd. The middle-arguments are in the "IPv6 puts public addresses on my devices and I don't want that". Do you want to now punish the smaller players because they're struggling to get to 50% IPv6 uptake? Even with the above in place, we're struggling to keep it active at >20% clients that at least take a PD from us. Whether or not that's then actually deployed internally in their network is yet another matter. My problem with the proposal isn't that it needs to be deployed, we have it deployed. There is one single /29 network where we have in play that doesn't have IPv6 also deployed, mostly because of the function thereof IPv6 cannot functionally be deployed there (the moment it makes sense you can be guaranteed we'll have it done in a week). Therefore I consider our network to be as close to 100% deployed as can be, however, our downstream networks is a different matter, with as stated, around 20%. You're now forcing me towards LNS because I won't be able to obtain additional resources because my customers are being stubborn. This just incurs further costs, both in terms of capex to procure (likely build) the equipment as well as opex in terms of running costs (primarily rack space and electricity, but also support staff training and additional complexity). Further in threads there were mention about top 25 sites etc ... all of that is highly impractical to measure for most networks. Kind regards, Jaco On 2026/05/28 12:21, jordi.palet--- via RPD wrote: Hi Jaco, Tks, next version will use: ?Any IPv4 request must be done with a simultaneous IPv6 request if the requesting party does not already have IPv6 space.? This may depend on the impact analysis inputs, of course. About the determination/measurement that this is being done, let me explain how I see this. The existing 6.5.1.1 (for LIRs) and 6.8.2, already set the conditions to be met. AFRINIC already has, in both cases, a 12 months period to confirm the deployment. May be is not sufficiently clear there if AFRINIC should do something if that?s not actually done. We aren?t talking there only about announcing the prefix, but also in the case of LIRs, about making assignments to end-sites, and the text is clear, /48s, nothing different. There is no reason for using different sizes for different type of customers on that text. There is no technical reason at all for not doing it correctly, however, this is a discussion for amending that part of the policy, not for this proposal. What this proposal wants to make sure is that you *actually*, *following existing policy*, if you get IPv4, you really deploy IPv6 in 12 months. To reinforce it I explicitly mention ?In addition ??, as you said. Note that ?in addition? section enforces a more detailed work from the member requesting IPv4, to justify a credible IPv6 addressing and deployment plan, this will be accepted or not by AFRINIC, as with any request evaluation. For example, in many RIRs, not just AFRINIC, I?ve observed that many members get by default a /32, even if they have 800.000 end-sites. Clearly wrong, they didn?t have done any real addressing plan and they will end up providing a single /64 to each end-site. If they do it correctly, they will soon discover why they should use /48s, so with a /32 they can only cover around 50.000 customers, which means that typically for 800.000 of customers (depending on the topological distribution of the network) will mean that they need a /27-/28. I don?t think nobody can say ?deploy? is not clear. If this is the case, we can improve it, something like ?and IPv6 is actually being used?. We can even set a minimum level of traffic, such as 50% for example? Those that have deployed IPv6 know that, at least in the case of residential and cellular customers, because most of the traffic (typically 75-90%) is from big CDNs, caches, and contend providers (all google, all Meta, Akamai and all the other CDNs), already provide IPv6, when you turn on IPv6 in an end-site, the IPv6 traffic of that end-site becomes 75%-90% IPv6, in turn the total ISP traffic reaches similar levels. So asking for 50% seems to me conservative, but I?m happy for lower levels, if we agree that we can ask for more later on. We can even consider something like 25% after 12 months, 50% after 24 months, 75% after 48 months. Just an example. Finally, as we have many policies that AFRINIC not necessarily is measuring the compliance, that?s what the other proposal (compliance dashboard) was already trying to resolve, now in a ?light? version. This proposal also added a trigger (failure to comply) to ensure that abuse (requesting IPv4, but then not deploying IPv6) can enact the RSA terms, because clearly shows that there is a policy breach. By the way, dynamic prefixes in IPv6 is broken, terrible idea, specially if there are power outages. I suggest to read what, hopefully in a few months, will become in RFC/BCP a successor of RIPE690: https://datatracker.ietf.org/doc/draft-ietf-v6ops-prefix-to-end-sites/ Regards, Jordi @jordipalet El 28 may 2026, a las 11:43, Jaco Kroon escribi?: Hi Jordi, I support the principle very much. Practicality may be a different story, yes, must implement v6, however: How do you determine/measure that? I think your "In addition" section addresses this to a degree. Merely advertising IPv6 space? Sure, that's easy, but it doesn't mean I have to actually make that available to customers. Re proposed text, the word "However, " doesn't add value, merely "Any IPv4 request must be done with a simultaneous IPv6 request if the requesting party does not already have IPv6 space." This does also be the question, it seems 6.5.1.1.3 states that you must give /48s to end sites - we do distinguish between business and home users, for business we happily do /48 if so required (at least we reserve a /48 per site minimum), but for home users we generally do dynamically allocated /56 (but will again do /48 on request) - would this imply failure to comply with your proposed policy? If so, should the proposed policy be adjusted, or 6.5.1.1.3? For PI space (6.8.2.2.d) - what does deployed mean? Kind regards, Jaco Kroon On 2026/05/28 10:28, jordi.palet--- via RPD wrote: Hi all, Somehow this is a response to Sami input on a previous proposal. This way we can split the problem space in 2 proposals, which may reach consensus without depending one on the other. So we have a very basic question: If we believe that the members that receive IPv4 out of the Soft Landing policy, must implement IPv6, or not? Regards, Jordi @jordipalet El 28 may 2026, a las 10:05, Darwin Da Costa escribi?: Dear PDWG, We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: https://afrinic.net/afpub-2026-v6-001-draft01 We encourage you to take some time to go through the proposal contents and provide feedback as follows: a)Do you support or oppose the proposal? b) If you oppose the proposal, state your reasons? c) Is there anything in the proposal that is not clear? d) What changes could be made to this proposal to make it more effective? Regards, Vincent Ngundi & Darwin Da Costa AFRINIC PDWG Co-Chairs _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From comms at afrinic.net Sun Jul 5 10:17:27 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Sun, 5 Jul 2026 14:17:27 +0400 Subject: [rpd] Temporary unavailability of the AFRINIC website Message-ID: [Version fran?aise plus bas] Dear Colleagues, We regret to inform you that the AFRINIC website is currently unavailable due to a suspected malicious attack. Our technical team is investigating the matter and working to restore the website as soon as possible. We apologise for any inconvenience this may cause and thank you for your patience and understanding. We will inform you once the website is back online. Kind regards, AFRINIC Team ------- Indisponibilit? temporaire du site web d?AFRINIC Chers membres, Nous regrettons de vous informer que le site web d?AFRINIC est actuellement indisponible ? la suite d?une attaque malveillante. Notre ?quipe technique travaille ? r?tablir le site dans les meilleurs d?lais. Nous nous excusons pour tout d?sagr?ment que cette situation pourrait causer et vous remercions pour votre patience et votre compr?hension. Nous vous informerons d?s que le site sera de nouveau disponible. Cordialement, AFRINIC Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From christianbope at gmail.com Sun Jul 5 10:26:33 2026 From: christianbope at gmail.com (Bope Domilongo Christian) Date: Sun, 5 Jul 2026 12:26:33 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: <497AC0C6-09CF-4FE3-A6F9-B32690413A71@afrinic.net> Message-ID: On Sun, 28 Jun 2026 at 11:16, jordi.palet--- via RPD wrote: > Fortunately, deploying 464XLAT in mobile networks (the only way to go) is > much easier and cheaper than in wireline. Vendors of both UEs and packet > switch mobile networks support it very well since many years ago. The > point, as usual, is to have the expertise and not trust what vendors try to > sell you. > > Is not just a matter of teaching IPv6. In a training you don?t get the > experience. There is a good reason why consultancy companies have a > business: it is much cheaper to trust an experienced consultant (vendor > independent) than a vendor and you avoid all the mistakes of lack of > experience. > Hi Jordi, 464XLAT is indeed well supported in mobile networks, but saying the main barrier is ?lack of experience? doesn?t match the data. If experience were the decisive factor, operators in high?GDP countries like Spain and Italy ? with large engineering teams and easy access to consultants ? wouldn?t be lagging in APNIC Labs measurements ( https://stats.labs.apnic.net/ipv6/XE). Yet they are. This shows the real issue isn?t consultant scarcity, but operator?level prioritization. IPv6 only moves when the dominant networks decide it matters. @christianbope > > Regards, > Jordi > > @jordipalet > > > El 27 jun 2026, a las 20:32, Ben Roberts - AfriNIC via RPD < > rpd at afrinic.net> escribi?: > > > > Alain, > > I am with you on this. > > I was talking about this yesterday with someone. It seems we have been > doing the same things with IPv6 capacity building for best part of 15 years > and still it?s not really pushing (mass) adoption. Yet we keep doing the > same things. ?.. > > > > Most Africans connect to the phone via mobile. Manu of them through the > ?big 5? of African MNO groups. > > > > We need to focus our IPv6 efforts around 5 groups of MNOs plus 4 vendors > (2 from China, 2 from Scandinavia). > > > > These 9 companies know who they are?. Some of them are represented > here?. > > > > Then if they start deploying IPv6 then 700M Africans will be using IPv6 > > > > The rest will fall into place?. > > > > Cheers > > > > Ben > > > > > > Sent from my iPhone > > > >> On 27 Jun 2026, at 20:52, ALAIN AINA via RPD wrote: > >> > >> ? > >> > >>> On 26 Jun 2026, at 07:16, Benson Muite > wrote: > >>> > >>> "jordi.palet--- via RPD" writes: > >>> > >>>> Hi Seun, > >>>> > >>>> I will actually say personally, the only acceptable X=1, but happy to > concede with 2. Hopefully we don?t have a discussion and every participant > chose a different number, as this is the typical issue when asking for a > decision of ?number of whatever? in trying to reach consensus. > >>> > >>> The low adoption rate is worrying. Clear criteria to justify IPv4 > >>> maybe helpful. If one gets IPv4, IPv6 is free. It is good that > Afrinic > >>> is doing outreach to universities. From Africa Gabon seems to have the > >>> highest percentage capability: > >>> https://stats.labs.apnic.net/ipv6 > >>> India also has good adoption and a diverse set of people in the > internet > >>> industry. Understanding what has lead to adoption in these places may > >>> help guide whether what new policies sohuld be adopted if any and how > to > >>> complement these with outreach and education activities. > >> > >> > >> A few years ago, I published an analysis of IPv6 uptake in Africa, > examining adoption from multiple angles, including infrastructure > readiness, operator behaviour, and user?access patterns. One of the key > findings was the positive impact of new market entrants, particularly those > who deployed IPv6?capable networks from day one. That dynamic remains > relevant today. > >> > >> Unfortunately, the overall situation has not changed significantly. The > user?access layer continues to be the weakest point in the regional IPv6 > ecosystem. Given that Africa?s Internet is overwhelmingly mobile?centric, > meaningful progress depends on Mobile Internet Service Providers taking > deliberate steps to enable IPv6 at scale. Without their participation, > adoption will remain slow regardless of improvements elsewhere in the > ecosystem. > >> > >> There are, however, some recent initiatives underway: > >> - The ICANN grant to the African Telecommunications Union (ATU) to > support IPv6 deployment in 30 African countries is a major development. > >> - ATU has already published an interim implementation report, > outlining early progress and challenges. > >> > >> These efforts complement AFRINIC?s ongoing outreach, including > engagement with universities and technical communities. > >> ----- > >> > >> > https://www.digitalintelligence.africa/publications/alain/AFRICA-and-IPv6-uptake.html > >> > https://www.icann.org/en/grant-program/first-cycle-funded-projects#deployment-ipv6-african-countries > >> > https://atuuat.africa/wp-content/uploads/2026/02/ATU_IPv6_First_Interim_Status_Report_Sep-Dec_2025.pdf > >> > https://atuuat.africa/wp-content/uploads/2022/11/Africa-IPv6-Development-White-Paper_double-page-version.pdf > >> > >> > >> ?Alain > >> > >> > >> > >> > >>> > >>> > >>>> > >>>> I will also say that X is only for ?single? allocations/assigments, > in the sense that if you are doing something for HA (one of the policies > that reached consensus yesterday), you must do it with IPv6. There is no > sense that you deploy, today, an HA infrastructure without IPv6. What do > you think ? > >>>> > >>>> Regards, > >>>> Jordi > >>>> > >>>> @jordipalet > >>>> > >>>>> El 25 jun 2026, a las 2:37, Seun Ojedeji > escribi?: > >>>>> > >>>>> Hi Jordi, > >>>>> > >>>>> ---- > >>>>> Sent from my mobile > >>>>> kindly excuse typos > >>>>> > >>>>> On Wed, 24 Jun 2026, 6:14?pm jordi.palet--- via RPD, < > rpd at afrinic.net > wrote: > >>>>>> . > >>>>>> > >>>>>> So there is no difference in now setting a policy that clearly say, > you get more IPv4, but you must also deploy IPv6. > >>>>>> > >>>>>> We could also do something slightly different, I?m not sure if this > is what Seun tried to say in the mic earlier this afternoon. > >>>>>> > >>>>>> We don?t give any more IPv4 resources if you already got them > previously. This has been done by most of the other RIRs. Will you agree > with that? Only newcomers can get IPv4. > >>>>> > >>>>> > >>>>> SO: More like you don't get IPv4 resources if you already got it for > X number of times in the current phase unless you meet the IPv6 deployment > plan requirements. My intention is for X not !=Once > >>>>> > >>>>> Regards > >>>>>> > >>>>>> Now, as a 2nd part of the proposal, resources left (even > recovered), can be provided to anyone who also deploy IPv6, regardless of > being a newcomer or an existing member. > >>>>>> > >>>>>> What do you think? > >>>>>> > >>>>>> Regards, > >>>>>> Jordi > >>>>>> > >>>>>> @jordipalet > >>> > >>> _______________________________________________ > >>> RPD mailing list > >>> RPD at afrinic.net > >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> > >> > >> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dc at darwincosta.com Sun Jul 5 12:03:38 2026 From: dc at darwincosta.com (dc at darwincosta.com) Date: Sun, 5 Jul 2026 14:03:38 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: Message-ID: <0A117F46-5C95-4D76-AAE9-F695C191800B@darwincosta.com> An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Mon Jul 6 08:41:56 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Mon, 6 Jul 2026 10:41:56 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: <497AC0C6-09CF-4FE3-A6F9-B32690413A71@afrinic.net> Message-ID: <84082285-459A-4843-9C4A-3D201E083840@consulintel.es> Hi Christian, Yes, that?s true as well, but the difference is that those operators (for example the case of Spain, which I know very well), aren?t in a hurry for IPv6 deployment, because: 1) They already invested long time ago in getting more IPv4 addressed that they need, indirectly via M&A. Several of them have extra IPv4 addresses. 2) Some times they also invested in CGN boxes (specially in mobile networks). In the specific case of Spain, I did consultancy for all the major operators already in 2011-2013 time frame. I?ve even worked with some of them in 2002. So I know very well the situation and specific rationales. Note also that 464XLAT was not available at that time. For me is a shame that IPv6 deployment in my own country is not progressing as well as it should be. We say here (free translation, I?m sure you have an equivalent sentence): ?you can?t be a prophet in your own land?. The main difference here is that many operators in Africa haven?t sufficient IPv4 addresses, so what we are proposing is, instead of investing in CGN with is a bad solution in the long term, you can invest in IPv6 deployment. It is easy to demonstrate that it is actually much cheaper. 464XLAT needs much less IPv4 addresses (for the PLAT IPv4 pool) than CGN (NAT444). In addition to that, IPv4 pools in CGN (NAT444) when detected by some service provider, such as Sony Network Play Station, get blocked in a black-list which is never cleaned, so you get an IPv4 block (or you already have it), and becomes useless if you have gammers (is an example, it happens with other services) in your network. RFC Regards, Jordi @jordipalet > El 5 jul 2026, a las 12:26, Bope Domilongo Christian escribi?: > > > > On Sun, 28 Jun 2026 at 11:16, jordi.palet--- via RPD > wrote: >> Fortunately, deploying 464XLAT in mobile networks (the only way to go) is much easier and cheaper than in wireline. Vendors of both UEs and packet switch mobile networks support it very well since many years ago. The point, as usual, is to have the expertise and not trust what vendors try to sell you. >> >> Is not just a matter of teaching IPv6. In a training you don?t get the experience. There is a good reason why consultancy companies have a business: it is much cheaper to trust an experienced consultant (vendor independent) than a vendor and you avoid all the mistakes of lack of experience. > > Hi Jordi, > > 464XLAT is indeed well supported in mobile networks, but saying the main barrier is ?lack of experience? doesn?t match the data. If experience were the decisive factor, operators in high?GDP countries like Spain and Italy ? with large engineering teams and easy access to consultants ? wouldn?t be lagging in APNIC Labs measurements ( https://stats.labs.apnic.net/ipv6/XE). > > Yet they are. > This shows the real issue isn?t consultant scarcity, but operator?level prioritization. IPv6 only moves when the dominant networks decide it matters. > > @christianbope <> >> Regards, >> Jordi >> >> @jordipalet >> >> > El 27 jun 2026, a las 20:32, Ben Roberts - AfriNIC via RPD > escribi?: >> > >> > Alain, >> > I am with you on this. >> > I was talking about this yesterday with someone. It seems we have been doing the same things with IPv6 capacity building for best part of 15 years and still it?s not really pushing (mass) adoption. Yet we keep doing the same things. ?.. >> > >> > Most Africans connect to the phone via mobile. Manu of them through the ?big 5? of African MNO groups. >> > >> > We need to focus our IPv6 efforts around 5 groups of MNOs plus 4 vendors (2 from China, 2 from Scandinavia). >> > >> > These 9 companies know who they are?. Some of them are represented here?. >> > >> > Then if they start deploying IPv6 then 700M Africans will be using IPv6 >> > >> > The rest will fall into place?. >> > >> > Cheers >> > >> > Ben >> > >> > >> > Sent from my iPhone >> > >> >> On 27 Jun 2026, at 20:52, ALAIN AINA via RPD > wrote: >> >> >> >> ? >> >> >> >>> On 26 Jun 2026, at 07:16, Benson Muite > wrote: >> >>> >> >>> "jordi.palet--- via RPD" > writes: >> >>> >> >>>> Hi Seun, >> >>>> >> >>>> I will actually say personally, the only acceptable X=1, but happy to concede with 2. Hopefully we don?t have a discussion and every participant chose a different number, as this is the typical issue when asking for a decision of ?number of whatever? in trying to reach consensus. >> >>> >> >>> The low adoption rate is worrying. Clear criteria to justify IPv4 >> >>> maybe helpful. If one gets IPv4, IPv6 is free. It is good that Afrinic >> >>> is doing outreach to universities. From Africa Gabon seems to have the >> >>> highest percentage capability: >> >>> https://stats.labs.apnic.net/ipv6 >> >>> India also has good adoption and a diverse set of people in the internet >> >>> industry. Understanding what has lead to adoption in these places may >> >>> help guide whether what new policies sohuld be adopted if any and how to >> >>> complement these with outreach and education activities. >> >> >> >> >> >> A few years ago, I published an analysis of IPv6 uptake in Africa, examining adoption from multiple angles, including infrastructure readiness, operator behaviour, and user?access patterns. One of the key findings was the positive impact of new market entrants, particularly those who deployed IPv6?capable networks from day one. That dynamic remains relevant today. >> >> >> >> Unfortunately, the overall situation has not changed significantly. The user?access layer continues to be the weakest point in the regional IPv6 ecosystem. Given that Africa?s Internet is overwhelmingly mobile?centric, meaningful progress depends on Mobile Internet Service Providers taking deliberate steps to enable IPv6 at scale. Without their participation, adoption will remain slow regardless of improvements elsewhere in the ecosystem. >> >> >> >> There are, however, some recent initiatives underway: >> >> - The ICANN grant to the African Telecommunications Union (ATU) to support IPv6 deployment in 30 African countries is a major development. >> >> - ATU has already published an interim implementation report, outlining early progress and challenges. >> >> >> >> These efforts complement AFRINIC?s ongoing outreach, including engagement with universities and technical communities. >> >> ----- >> >> >> >> https://www.digitalintelligence.africa/publications/alain/AFRICA-and-IPv6-uptake.html >> >> https://www.icann.org/en/grant-program/first-cycle-funded-projects#deployment-ipv6-african-countries >> >> https://atuuat.africa/wp-content/uploads/2026/02/ATU_IPv6_First_Interim_Status_Report_Sep-Dec_2025.pdf >> >> https://atuuat.africa/wp-content/uploads/2022/11/Africa-IPv6-Development-White-Paper_double-page-version.pdf >> >> >> >> >> >> ?Alain >> >> >> >> >> >> >> >> >> >>> >> >>> >> >>>> >> >>>> I will also say that X is only for ?single? allocations/assigments, in the sense that if you are doing something for HA (one of the policies that reached consensus yesterday), you must do it with IPv6. There is no sense that you deploy, today, an HA infrastructure without IPv6. What do you think ? >> >>>> >> >>>> Regards, >> >>>> Jordi >> >>>> >> >>>> @jordipalet >> >>>> >> >>>>> El 25 jun 2026, a las 2:37, Seun Ojedeji > escribi?: >> >>>>> >> >>>>> Hi Jordi, >> >>>>> >> >>>>> ---- >> >>>>> Sent from my mobile >> >>>>> kindly excuse typos >> >>>>> >> >>>>> On Wed, 24 Jun 2026, 6:14?pm jordi.palet--- via RPD, >> wrote: >> >>>>>> . >> >>>>>> >> >>>>>> So there is no difference in now setting a policy that clearly say, you get more IPv4, but you must also deploy IPv6. >> >>>>>> >> >>>>>> We could also do something slightly different, I?m not sure if this is what Seun tried to say in the mic earlier this afternoon. >> >>>>>> >> >>>>>> We don?t give any more IPv4 resources if you already got them previously. This has been done by most of the other RIRs. Will you agree with that? Only newcomers can get IPv4. >> >>>>> >> >>>>> >> >>>>> SO: More like you don't get IPv4 resources if you already got it for X number of times in the current phase unless you meet the IPv6 deployment plan requirements. My intention is for X not !=Once >> >>>>> >> >>>>> Regards >> >>>>>> >> >>>>>> Now, as a 2nd part of the proposal, resources left (even recovered), can be provided to anyone who also deploy IPv6, regardless of being a newcomer or an existing member. >> >>>>>> >> >>>>>> What do you think? >> >>>>>> >> >>>>>> Regards, >> >>>>>> Jordi >> >>>>>> >> >>>>>> @jordipalet >> >>> >> >>> _______________________________________________ >> >>> RPD mailing list >> >>> RPD at afrinic.net >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> >> >> >> >> _______________________________________________ >> >> RPD mailing list >> >> RPD at afrinic.net >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> > >> > _______________________________________________ >> > RPD mailing list >> > RPD at afrinic.net >> > https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Mon Jul 6 08:45:43 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Mon, 6 Jul 2026 10:45:43 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: <84082285-459A-4843-9C4A-3D201E083840@consulintel.es> References: <497AC0C6-09CF-4FE3-A6F9-B32690413A71@afrinic.net> <84082285-459A-4843-9C4A-3D201E083840@consulintel.es> Message-ID: <554E0756-48A5-4C71-A7BB-5A595692889B@consulintel.es> Sorry missed the RFC9313 https://datatracker.ietf.org/doc/rfc9313/ Regards, Jordi @jordipalet > El 6 jul 2026, a las 10:41, jordi.palet at consulintel.es escribi?: > > Hi Christian, > > Yes, that?s true as well, but the difference is that those operators (for example the case of Spain, which I know very well), aren?t in a hurry for IPv6 deployment, because: > 1) They already invested long time ago in getting more IPv4 addressed that they need, indirectly via M&A. Several of them have extra IPv4 addresses. > 2) Some times they also invested in CGN boxes (specially in mobile networks). > > In the specific case of Spain, I did consultancy for all the major operators already in 2011-2013 time frame. I?ve even worked with some of them in 2002. So I know very well the situation and specific rationales. Note also that 464XLAT was not available at that time. For me is a shame that IPv6 deployment in my own country is not progressing as well as it should be. We say here (free translation, I?m sure you have an equivalent sentence): ?you can?t be a prophet in your own land?. > > The main difference here is that many operators in Africa haven?t sufficient IPv4 addresses, so what we are proposing is, instead of investing in CGN with is a bad solution in the long term, you can invest in IPv6 deployment. It is easy to demonstrate that it is actually much cheaper. 464XLAT needs much less IPv4 addresses (for the PLAT IPv4 pool) than CGN (NAT444). In addition to that, IPv4 pools in CGN (NAT444) when detected by some service provider, such as Sony Network Play Station, get blocked in a black-list which is never cleaned, so you get an IPv4 block (or you already have it), and becomes useless if you have gammers (is an example, it happens with other services) in your network. > > RFC > > Regards, > Jordi > > @jordipalet > >> El 5 jul 2026, a las 12:26, Bope Domilongo Christian escribi?: >> >> >> >> On Sun, 28 Jun 2026 at 11:16, jordi.palet--- via RPD > wrote: >>> Fortunately, deploying 464XLAT in mobile networks (the only way to go) is much easier and cheaper than in wireline. Vendors of both UEs and packet switch mobile networks support it very well since many years ago. The point, as usual, is to have the expertise and not trust what vendors try to sell you. >>> >>> Is not just a matter of teaching IPv6. In a training you don?t get the experience. There is a good reason why consultancy companies have a business: it is much cheaper to trust an experienced consultant (vendor independent) than a vendor and you avoid all the mistakes of lack of experience. >> >> Hi Jordi, >> >> 464XLAT is indeed well supported in mobile networks, but saying the main barrier is ?lack of experience? doesn?t match the data. If experience were the decisive factor, operators in high?GDP countries like Spain and Italy ? with large engineering teams and easy access to consultants ? wouldn?t be lagging in APNIC Labs measurements ( https://stats.labs.apnic.net/ipv6/XE). >> >> Yet they are. >> This shows the real issue isn?t consultant scarcity, but operator?level prioritization. IPv6 only moves when the dominant networks decide it matters. >> >> @christianbope <> >>> Regards, >>> Jordi >>> >>> @jordipalet >>> >>> > El 27 jun 2026, a las 20:32, Ben Roberts - AfriNIC via RPD > escribi?: >>> > >>> > Alain, >>> > I am with you on this. >>> > I was talking about this yesterday with someone. It seems we have been doing the same things with IPv6 capacity building for best part of 15 years and still it?s not really pushing (mass) adoption. Yet we keep doing the same things. ?.. >>> > >>> > Most Africans connect to the phone via mobile. Manu of them through the ?big 5? of African MNO groups. >>> > >>> > We need to focus our IPv6 efforts around 5 groups of MNOs plus 4 vendors (2 from China, 2 from Scandinavia). >>> > >>> > These 9 companies know who they are?. Some of them are represented here?. >>> > >>> > Then if they start deploying IPv6 then 700M Africans will be using IPv6 >>> > >>> > The rest will fall into place?. >>> > >>> > Cheers >>> > >>> > Ben >>> > >>> > >>> > Sent from my iPhone >>> > >>> >> On 27 Jun 2026, at 20:52, ALAIN AINA via RPD > wrote: >>> >> >>> >> ? >>> >> >>> >>> On 26 Jun 2026, at 07:16, Benson Muite > wrote: >>> >>> >>> >>> "jordi.palet--- via RPD" > writes: >>> >>> >>> >>>> Hi Seun, >>> >>>> >>> >>>> I will actually say personally, the only acceptable X=1, but happy to concede with 2. Hopefully we don?t have a discussion and every participant chose a different number, as this is the typical issue when asking for a decision of ?number of whatever? in trying to reach consensus. >>> >>> >>> >>> The low adoption rate is worrying. Clear criteria to justify IPv4 >>> >>> maybe helpful. If one gets IPv4, IPv6 is free. It is good that Afrinic >>> >>> is doing outreach to universities. From Africa Gabon seems to have the >>> >>> highest percentage capability: >>> >>> https://stats.labs.apnic.net/ipv6 >>> >>> India also has good adoption and a diverse set of people in the internet >>> >>> industry. Understanding what has lead to adoption in these places may >>> >>> help guide whether what new policies sohuld be adopted if any and how to >>> >>> complement these with outreach and education activities. >>> >> >>> >> >>> >> A few years ago, I published an analysis of IPv6 uptake in Africa, examining adoption from multiple angles, including infrastructure readiness, operator behaviour, and user?access patterns. One of the key findings was the positive impact of new market entrants, particularly those who deployed IPv6?capable networks from day one. That dynamic remains relevant today. >>> >> >>> >> Unfortunately, the overall situation has not changed significantly. The user?access layer continues to be the weakest point in the regional IPv6 ecosystem. Given that Africa?s Internet is overwhelmingly mobile?centric, meaningful progress depends on Mobile Internet Service Providers taking deliberate steps to enable IPv6 at scale. Without their participation, adoption will remain slow regardless of improvements elsewhere in the ecosystem. >>> >> >>> >> There are, however, some recent initiatives underway: >>> >> - The ICANN grant to the African Telecommunications Union (ATU) to support IPv6 deployment in 30 African countries is a major development. >>> >> - ATU has already published an interim implementation report, outlining early progress and challenges. >>> >> >>> >> These efforts complement AFRINIC?s ongoing outreach, including engagement with universities and technical communities. >>> >> ----- >>> >> >>> >> https://www.digitalintelligence.africa/publications/alain/AFRICA-and-IPv6-uptake.html >>> >> https://www.icann.org/en/grant-program/first-cycle-funded-projects#deployment-ipv6-african-countries >>> >> https://atuuat.africa/wp-content/uploads/2026/02/ATU_IPv6_First_Interim_Status_Report_Sep-Dec_2025.pdf >>> >> https://atuuat.africa/wp-content/uploads/2022/11/Africa-IPv6-Development-White-Paper_double-page-version.pdf >>> >> >>> >> >>> >> ?Alain >>> >> >>> >> >>> >> >>> >> >>> >>> >>> >>> >>> >>>> >>> >>>> I will also say that X is only for ?single? allocations/assigments, in the sense that if you are doing something for HA (one of the policies that reached consensus yesterday), you must do it with IPv6. There is no sense that you deploy, today, an HA infrastructure without IPv6. What do you think ? >>> >>>> >>> >>>> Regards, >>> >>>> Jordi >>> >>>> >>> >>>> @jordipalet >>> >>>> >>> >>>>> El 25 jun 2026, a las 2:37, Seun Ojedeji > escribi?: >>> >>>>> >>> >>>>> Hi Jordi, >>> >>>>> >>> >>>>> ---- >>> >>>>> Sent from my mobile >>> >>>>> kindly excuse typos >>> >>>>> >>> >>>>> On Wed, 24 Jun 2026, 6:14?pm jordi.palet--- via RPD, >> wrote: >>> >>>>>> . >>> >>>>>> >>> >>>>>> So there is no difference in now setting a policy that clearly say, you get more IPv4, but you must also deploy IPv6. >>> >>>>>> >>> >>>>>> We could also do something slightly different, I?m not sure if this is what Seun tried to say in the mic earlier this afternoon. >>> >>>>>> >>> >>>>>> We don?t give any more IPv4 resources if you already got them previously. This has been done by most of the other RIRs. Will you agree with that? Only newcomers can get IPv4. >>> >>>>> >>> >>>>> >>> >>>>> SO: More like you don't get IPv4 resources if you already got it for X number of times in the current phase unless you meet the IPv6 deployment plan requirements. My intention is for X not !=Once >>> >>>>> >>> >>>>> Regards >>> >>>>>> >>> >>>>>> Now, as a 2nd part of the proposal, resources left (even recovered), can be provided to anyone who also deploy IPv6, regardless of being a newcomer or an existing member. >>> >>>>>> >>> >>>>>> What do you think? >>> >>>>>> >>> >>>>>> Regards, >>> >>>>>> Jordi >>> >>>>>> >>> >>>>>> @jordipalet >>> >>> >>> >>> _______________________________________________ >>> >>> RPD mailing list >>> >>> RPD at afrinic.net >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> RPD mailing list >>> >> RPD at afrinic.net >>> >> https://lists.afrinic.net/mailman/listinfo/rpd >>> > >>> > _______________________________________________ >>> > RPD mailing list >>> > RPD at afrinic.net >>> > https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> >>> ********************************************** >>> IPv4 is over >>> Are you ready for the new Internet ? >>> http://www.theipv6company.com >>> The IPv6 Company >>> >>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >>> >>> >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Mon Jul 6 09:06:39 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Mon, 6 Jul 2026 11:06:39 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: <0A117F46-5C95-4D76-AAE9-F695C191800B@darwincosta.com> References: <0A117F46-5C95-4D76-AAE9-F695C191800B@darwincosta.com> Message-ID: Hi Darwin, In Angola, according to APNIC, UNITEL, Paragus and Neonet, have 25-33% IPv6. Not good, something may be broken there. Of course, without knowing the exact details of those networks and how IPv6 has been deployed, I can only speculate, but based in my experience, I can point to some aspects: 1) If it is a mobile network, are they using dual-stack (even with IPv4 private addresses behind CGN) or 464XLAT? 2) Are they monitoring IPv4 and IPv6 at the upstreams and the rest of the network. Bad quality IPv6 transits or peering may bring HE to fallback to IPv4. 3) Are they using a single APN (right way to go)? Have they done test with iOS/Apple and signed the contract to provide the updated operator-profile for dual-stack or IPv6-only and to enable CLAT for the tethering? 4) Have they measured the top-n (I will suggest top-25) traffic destinations? 5) Are they taking advantage of Caches/CDNs, with need to be updated to support also IPv6? 6) How are they doing the Pref64 discovery or it is manually configured? How they provision and what lenght, the IPv6 prefix? 7) If they customer base is mainly residential, what transition technology and how is it configured at the CEs. Do they allow customers to replace the CEs and they support ?any? or only certified ones? 8) Marketing actions: In some cases, during many years, specially some game companies suggested to disable IPv6 in Windows. They had bugs and the easy way was ?IPv6 is the guilty?. When you deploy IPv6 you need to ask customers to revert that. Same for un-updated Android and iOS phones, you need to tell customer to keep them updated, in some Android cases, if you don?t do that, you need to offer some free bonus to customers to tell them ?you get ?n? extra free gigs? if you enable IPv6 in your config. Unfortunately this doesn?t work for iOS, the only way is to engage with your Apple liaison. This is just an example of many things that you don?t learn in trainings, just over deployment experience. Some of them are very simple, some others really need to be updated to each specific network case. Some of them are related only to mobile or wireline, some apply to both. If you have direct contact with those operators and they are interested in having an email exchange or a call to see how we can increase the IPv6 traffic looking at how the deployment has been done, let me know in pvt. I will be happy to support them at a minimum with some free tips. We could take that as a deployment case and ask them to present in the next AIS, to demonstrate how things can change. Regards, Jordi @jordipalet > El 5 jul 2026, a las 14:03, dc at darwincosta.com escribi?: > > > >> On 5 Jul 2026, at 12:29, Bope Domilongo Christian wrote: >> >> ? >> >> >> On Sun, 28 Jun 2026 at 11:16, jordi.palet--- via RPD > wrote: >>> Fortunately, deploying 464XLAT in mobile networks (the only way to go) is much easier and cheaper than in wireline. Vendors of both UEs and packet switch mobile networks support it very well since many years ago. The point, as usual, is to have the expertise and not trust what vendors try to sell you. >>> >>> Is not just a matter of teaching IPv6. In a training you don?t get the experience. There is a good reason why consultancy companies have a business: it is much cheaper to trust an experienced consultant (vendor independent) than a vendor and you avoid all the mistakes of lack of experience. >> >> Hi Jordi, >> >> 464XLAT is indeed well supported in mobile networks, but saying the main barrier is ?lack of experience? doesn?t match the data. If experience were the decisive factor, operators in high?GDP countries like Spain and Italy ? with large engineering teams and easy access to consultants ? wouldn?t be lagging in APNIC Labs measurements ( https://stats.labs.apnic.net/ipv6/XE). >> >> Yet they are. >> This shows the real issue isn?t consultant scarcity, but operator?level prioritization. IPv6 only moves when the dominant networks decide it matters. >> >> @christianbope <> > Fully agree with your statement, @Christianbope. > > We?ve seen this firsthand in Angola. Since launching the Angolan Peering Forum in 2019, we?ve focused on capacity building, knowledge sharing, and consistently engaging operators year after year. As a result, we?ve gone from 0% to approximately 15% nationwide IPv6 adoption today. > > One of the top three contributors to this progress is Angola?s largest mobile operator, UNITEL (AS37119), which has reached 26% adoption. It took time to address the necessary operational and organizational adjustments, but today they?re more engaged than ever and continue to play an important role in advancing IPv6 adoption in the country. > > Cheers. > > Darwin/. > >>> >>> Regards, >>> Jordi >>> >>> @jordipalet >>> >>> > El 27 jun 2026, a las 20:32, Ben Roberts - AfriNIC via RPD > escribi?: >>> > >>> > Alain, >>> > I am with you on this. >>> > I was talking about this yesterday with someone. It seems we have been doing the same things with IPv6 capacity building for best part of 15 years and still it?s not really pushing (mass) adoption. Yet we keep doing the same things. ?.. >>> > >>> > Most Africans connect to the phone via mobile. Manu of them through the ?big 5? of African MNO groups. >>> > >>> > We need to focus our IPv6 efforts around 5 groups of MNOs plus 4 vendors (2 from China, 2 from Scandinavia). >>> > >>> > These 9 companies know who they are?. Some of them are represented here?. >>> > >>> > Then if they start deploying IPv6 then 700M Africans will be using IPv6 >>> > >>> > The rest will fall into place?. >>> > >>> > Cheers >>> > >>> > Ben >>> > >>> > >>> > Sent from my iPhone >>> > >>> >> On 27 Jun 2026, at 20:52, ALAIN AINA via RPD > wrote: >>> >> >>> >> ? >>> >> >>> >>> On 26 Jun 2026, at 07:16, Benson Muite > wrote: >>> >>> >>> >>> "jordi.palet--- via RPD" > writes: >>> >>> >>> >>>> Hi Seun, >>> >>>> >>> >>>> I will actually say personally, the only acceptable X=1, but happy to concede with 2. Hopefully we don?t have a discussion and every participant chose a different number, as this is the typical issue when asking for a decision of ?number of whatever? in trying to reach consensus. >>> >>> >>> >>> The low adoption rate is worrying. Clear criteria to justify IPv4 >>> >>> maybe helpful. If one gets IPv4, IPv6 is free. It is good that Afrinic >>> >>> is doing outreach to universities. From Africa Gabon seems to have the >>> >>> highest percentage capability: >>> >>> https://stats.labs.apnic.net/ipv6 >>> >>> India also has good adoption and a diverse set of people in the internet >>> >>> industry. Understanding what has lead to adoption in these places may >>> >>> help guide whether what new policies sohuld be adopted if any and how to >>> >>> complement these with outreach and education activities. >>> >> >>> >> >>> >> A few years ago, I published an analysis of IPv6 uptake in Africa, examining adoption from multiple angles, including infrastructure readiness, operator behaviour, and user?access patterns. One of the key findings was the positive impact of new market entrants, particularly those who deployed IPv6?capable networks from day one. That dynamic remains relevant today. >>> >> >>> >> Unfortunately, the overall situation has not changed significantly. The user?access layer continues to be the weakest point in the regional IPv6 ecosystem. Given that Africa?s Internet is overwhelmingly mobile?centric, meaningful progress depends on Mobile Internet Service Providers taking deliberate steps to enable IPv6 at scale. Without their participation, adoption will remain slow regardless of improvements elsewhere in the ecosystem. >>> >> >>> >> There are, however, some recent initiatives underway: >>> >> - The ICANN grant to the African Telecommunications Union (ATU) to support IPv6 deployment in 30 African countries is a major development. >>> >> - ATU has already published an interim implementation report, outlining early progress and challenges. >>> >> >>> >> These efforts complement AFRINIC?s ongoing outreach, including engagement with universities and technical communities. >>> >> ----- >>> >> >>> >> https://www.digitalintelligence.africa/publications/alain/AFRICA-and-IPv6-uptake.html >>> >> https://www.icann.org/en/grant-program/first-cycle-funded-projects#deployment-ipv6-african-countries >>> >> https://atuuat.africa/wp-content/uploads/2026/02/ATU_IPv6_First_Interim_Status_Report_Sep-Dec_2025.pdf >>> >> https://atuuat.africa/wp-content/uploads/2022/11/Africa-IPv6-Development-White-Paper_double-page-version.pdf >>> >> >>> >> >>> >> ?Alain >>> >> >>> >> >>> >> >>> >> >>> >>> >>> >>> >>> >>>> >>> >>>> I will also say that X is only for ?single? allocations/assigments, in the sense that if you are doing something for HA (one of the policies that reached consensus yesterday), you must do it with IPv6. There is no sense that you deploy, today, an HA infrastructure without IPv6. What do you think ? >>> >>>> >>> >>>> Regards, >>> >>>> Jordi >>> >>>> >>> >>>> @jordipalet >>> >>>> >>> >>>>> El 25 jun 2026, a las 2:37, Seun Ojedeji > escribi?: >>> >>>>> >>> >>>>> Hi Jordi, >>> >>>>> >>> >>>>> ---- >>> >>>>> Sent from my mobile >>> >>>>> kindly excuse typos >>> >>>>> >>> >>>>> On Wed, 24 Jun 2026, 6:14?pm jordi.palet--- via RPD, >> wrote: >>> >>>>>> . >>> >>>>>> >>> >>>>>> So there is no difference in now setting a policy that clearly say, you get more IPv4, but you must also deploy IPv6. >>> >>>>>> >>> >>>>>> We could also do something slightly different, I?m not sure if this is what Seun tried to say in the mic earlier this afternoon. >>> >>>>>> >>> >>>>>> We don?t give any more IPv4 resources if you already got them previously. This has been done by most of the other RIRs. Will you agree with that? Only newcomers can get IPv4. >>> >>>>> >>> >>>>> >>> >>>>> SO: More like you don't get IPv4 resources if you already got it for X number of times in the current phase unless you meet the IPv6 deployment plan requirements. My intention is for X not !=Once >>> >>>>> >>> >>>>> Regards >>> >>>>>> >>> >>>>>> Now, as a 2nd part of the proposal, resources left (even recovered), can be provided to anyone who also deploy IPv6, regardless of being a newcomer or an existing member. >>> >>>>>> >>> >>>>>> What do you think? >>> >>>>>> >>> >>>>>> Regards, >>> >>>>>> Jordi >>> >>>>>> >>> >>>>>> @jordipalet >>> >>> >>> >>> _______________________________________________ >>> >>> RPD mailing list >>> >>> RPD at afrinic.net >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> RPD mailing list >>> >> RPD at afrinic.net >>> >> https://lists.afrinic.net/mailman/listinfo/rpd >>> > >>> > _______________________________________________ >>> > RPD mailing list >>> > RPD at afrinic.net >>> > https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> >>> ********************************************** >>> IPv4 is over >>> Are you ready for the new Internet ? >>> http://www.theipv6company.com >>> The IPv6 Company >>> >>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >>> >>> >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dc at darwincosta.com Mon Jul 6 09:49:47 2026 From: dc at darwincosta.com (Darwin Da Costa) Date: Mon, 6 Jul 2026 11:49:47 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: <0A117F46-5C95-4D76-AAE9-F695C191800B@darwincosta.com> Message-ID: <3817D4DB-F675-40B8-A844-847FD4189D01@darwincosta.com> > On 6. Jul 2026, at 11:06, jordi.palet--- via RPD wrote: > > Hi Darwin, Hi Jordi, > > In Angola, according to APNIC, UNITEL, Paragus and Neonet, have 25-33% IPv6. Not good, something may be broken there. It depends on how you look into it. Again, 2019 was 0% while in 2026 a movement is happening. Obviously the speed will always depend on their (networks) priorities. Our job is to push them and guide them. > > Of course, without knowing the exact details of those networks and how IPv6 has been deployed, I can only speculate, but based in my experience, I can point to some aspects: > > 1) If it is a mobile network, are they using dual-stack (even with IPv4 private addresses behind CGN) or 464XLAT? > 2) Are they monitoring IPv4 and IPv6 at the upstreams and the rest of the network. Bad quality IPv6 transits or peering may bring HE to fallback to IPv4. > 3) Are they using a single APN (right way to go)? Have they done test with iOS/Apple and signed the contract to provide the updated operator-profile for dual-stack or IPv6-only and to enable CLAT for the tethering? > 4) Have they measured the top-n (I will suggest top-25) traffic destinations? > 5) Are they taking advantage of Caches/CDNs, with need to be updated to support also IPv6? > 6) How are they doing the Pref64 discovery or it is manually configured? How they provision and what lenght, the IPv6 prefix? > 7) If they customer base is mainly residential, what transition technology and how is it configured at the CEs. Do they allow customers to replace the CEs and they support ?any? or only certified ones? > 8) Marketing actions: In some cases, during many years, specially some game companies suggested to disable IPv6 in Windows. They had bugs and the easy way was ?IPv6 is the guilty?. When you deploy IPv6 you need to ask customers to revert that. Same for un-updated Android and iOS phones, you need to tell customer to keep them updated, in some Android cases, if you don?t do that, you need to offer some free bonus to customers to tell them ?you get ?n? extra free gigs? if you enable IPv6 in your config. Unfortunately this doesn?t work for iOS, the only way is to engage with your Apple liaison. > > This is just an example of many things that you don?t learn in trainings, just over deployment experience. Some of them are very simple, some others really need to be updated to each specific network case. Some of them are related only to mobile or wireline, some apply to both. > > If you have direct contact with those operators and they are interested in having an email exchange or a call to see how we can increase the IPv6 traffic looking at how the deployment has been done, let me know in pvt. I will be happy to support them at a minimum with some free tips. We could take that as a deployment case and ask them to present in the next AIS, to demonstrate how things can change. Sure and agree with the operational points you have shared. Will do some intros and hopefully bringing them over to one of the AIS in the future. > > Regards, > Jordi > > @jordipalet Cheers! Darwin/. > >> El 5 jul 2026, a las 14:03, dc at darwincosta.com escribi?: >> >> >> >>> On 5 Jul 2026, at 12:29, Bope Domilongo Christian wrote: >>> >>> ? >>> >>> >>> On Sun, 28 Jun 2026 at 11:16, jordi.palet--- via RPD > wrote: >>>> Fortunately, deploying 464XLAT in mobile networks (the only way to go) is much easier and cheaper than in wireline. Vendors of both UEs and packet switch mobile networks support it very well since many years ago. The point, as usual, is to have the expertise and not trust what vendors try to sell you. >>>> >>>> Is not just a matter of teaching IPv6. In a training you don?t get the experience. There is a good reason why consultancy companies have a business: it is much cheaper to trust an experienced consultant (vendor independent) than a vendor and you avoid all the mistakes of lack of experience. >>> >>> Hi Jordi, >>> >>> 464XLAT is indeed well supported in mobile networks, but saying the main barrier is ?lack of experience? doesn?t match the data. If experience were the decisive factor, operators in high?GDP countries like Spain and Italy ? with large engineering teams and easy access to consultants ? wouldn?t be lagging in APNIC Labs measurements ( https://stats.labs.apnic.net/ipv6/XE). >>> >>> Yet they are. >>> This shows the real issue isn?t consultant scarcity, but operator?level prioritization. IPv6 only moves when the dominant networks decide it matters. >>> >>> @christianbope <> >> Fully agree with your statement, @Christianbope. >> >> We?ve seen this firsthand in Angola. Since launching the Angolan Peering Forum in 2019, we?ve focused on capacity building, knowledge sharing, and consistently engaging operators year after year. As a result, we?ve gone from 0% to approximately 15% nationwide IPv6 adoption today. >> >> One of the top three contributors to this progress is Angola?s largest mobile operator, UNITEL (AS37119), which has reached 26% adoption. It took time to address the necessary operational and organizational adjustments, but today they?re more engaged than ever and continue to play an important role in advancing IPv6 adoption in the country. >> >> Cheers. >> >> Darwin/. >> >>>> >>>> Regards, >>>> Jordi >>>> >>>> @jordipalet >>>> >>>> > El 27 jun 2026, a las 20:32, Ben Roberts - AfriNIC via RPD > escribi?: >>>> > >>>> > Alain, >>>> > I am with you on this. >>>> > I was talking about this yesterday with someone. It seems we have been doing the same things with IPv6 capacity building for best part of 15 years and still it?s not really pushing (mass) adoption. Yet we keep doing the same things. ?.. >>>> > >>>> > Most Africans connect to the phone via mobile. Manu of them through the ?big 5? of African MNO groups. >>>> > >>>> > We need to focus our IPv6 efforts around 5 groups of MNOs plus 4 vendors (2 from China, 2 from Scandinavia). >>>> > >>>> > These 9 companies know who they are?. Some of them are represented here?. >>>> > >>>> > Then if they start deploying IPv6 then 700M Africans will be using IPv6 >>>> > >>>> > The rest will fall into place?. >>>> > >>>> > Cheers >>>> > >>>> > Ben >>>> > >>>> > >>>> > Sent from my iPhone >>>> > >>>> >> On 27 Jun 2026, at 20:52, ALAIN AINA via RPD > wrote: >>>> >> >>>> >> ? >>>> >> >>>> >>> On 26 Jun 2026, at 07:16, Benson Muite > wrote: >>>> >>> >>>> >>> "jordi.palet--- via RPD" > writes: >>>> >>> >>>> >>>> Hi Seun, >>>> >>>> >>>> >>>> I will actually say personally, the only acceptable X=1, but happy to concede with 2. Hopefully we don?t have a discussion and every participant chose a different number, as this is the typical issue when asking for a decision of ?number of whatever? in trying to reach consensus. >>>> >>> >>>> >>> The low adoption rate is worrying. Clear criteria to justify IPv4 >>>> >>> maybe helpful. If one gets IPv4, IPv6 is free. It is good that Afrinic >>>> >>> is doing outreach to universities. From Africa Gabon seems to have the >>>> >>> highest percentage capability: >>>> >>> https://stats.labs.apnic.net/ipv6 >>>> >>> India also has good adoption and a diverse set of people in the internet >>>> >>> industry. Understanding what has lead to adoption in these places may >>>> >>> help guide whether what new policies sohuld be adopted if any and how to >>>> >>> complement these with outreach and education activities. >>>> >> >>>> >> >>>> >> A few years ago, I published an analysis of IPv6 uptake in Africa, examining adoption from multiple angles, including infrastructure readiness, operator behaviour, and user?access patterns. One of the key findings was the positive impact of new market entrants, particularly those who deployed IPv6?capable networks from day one. That dynamic remains relevant today. >>>> >> >>>> >> Unfortunately, the overall situation has not changed significantly. The user?access layer continues to be the weakest point in the regional IPv6 ecosystem. Given that Africa?s Internet is overwhelmingly mobile?centric, meaningful progress depends on Mobile Internet Service Providers taking deliberate steps to enable IPv6 at scale. Without their participation, adoption will remain slow regardless of improvements elsewhere in the ecosystem. >>>> >> >>>> >> There are, however, some recent initiatives underway: >>>> >> - The ICANN grant to the African Telecommunications Union (ATU) to support IPv6 deployment in 30 African countries is a major development. >>>> >> - ATU has already published an interim implementation report, outlining early progress and challenges. >>>> >> >>>> >> These efforts complement AFRINIC?s ongoing outreach, including engagement with universities and technical communities. >>>> >> ----- >>>> >> >>>> >> https://www.digitalintelligence.africa/publications/alain/AFRICA-and-IPv6-uptake.html >>>> >> https://www.icann.org/en/grant-program/first-cycle-funded-projects#deployment-ipv6-african-countries >>>> >> https://atuuat.africa/wp-content/uploads/2026/02/ATU_IPv6_First_Interim_Status_Report_Sep-Dec_2025.pdf >>>> >> https://atuuat.africa/wp-content/uploads/2022/11/Africa-IPv6-Development-White-Paper_double-page-version.pdf >>>> >> >>>> >> >>>> >> ?Alain >>>> >> >>>> >> >>>> >> >>>> >> >>>> >>> >>>> >>> >>>> >>>> >>>> >>>> I will also say that X is only for ?single? allocations/assigments, in the sense that if you are doing something for HA (one of the policies that reached consensus yesterday), you must do it with IPv6. There is no sense that you deploy, today, an HA infrastructure without IPv6. What do you think ? >>>> >>>> >>>> >>>> Regards, >>>> >>>> Jordi >>>> >>>> >>>> >>>> @jordipalet >>>> >>>> >>>> >>>>> El 25 jun 2026, a las 2:37, Seun Ojedeji > escribi?: >>>> >>>>> >>>> >>>>> Hi Jordi, >>>> >>>>> >>>> >>>>> ---- >>>> >>>>> Sent from my mobile >>>> >>>>> kindly excuse typos >>>> >>>>> >>>> >>>>> On Wed, 24 Jun 2026, 6:14?pm jordi.palet--- via RPD, >> wrote: >>>> >>>>>> . >>>> >>>>>> >>>> >>>>>> So there is no difference in now setting a policy that clearly say, you get more IPv4, but you must also deploy IPv6. >>>> >>>>>> >>>> >>>>>> We could also do something slightly different, I?m not sure if this is what Seun tried to say in the mic earlier this afternoon. >>>> >>>>>> >>>> >>>>>> We don?t give any more IPv4 resources if you already got them previously. This has been done by most of the other RIRs. Will you agree with that? Only newcomers can get IPv4. >>>> >>>>> >>>> >>>>> >>>> >>>>> SO: More like you don't get IPv4 resources if you already got it for X number of times in the current phase unless you meet the IPv6 deployment plan requirements. My intention is for X not !=Once >>>> >>>>> >>>> >>>>> Regards >>>> >>>>>> >>>> >>>>>> Now, as a 2nd part of the proposal, resources left (even recovered), can be provided to anyone who also deploy IPv6, regardless of being a newcomer or an existing member. >>>> >>>>>> >>>> >>>>>> What do you think? >>>> >>>>>> >>>> >>>>>> Regards, >>>> >>>>>> Jordi >>>> >>>>>> >>>> >>>>>> @jordipalet >>>> >>> >>>> >>> _______________________________________________ >>>> >>> RPD mailing list >>>> >>> RPD at afrinic.net >>>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >> >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> RPD mailing list >>>> >> RPD at afrinic.net >>>> >> https://lists.afrinic.net/mailman/listinfo/rpd >>>> > >>>> > _______________________________________________ >>>> > RPD mailing list >>>> > RPD at afrinic.net >>>> > https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>>> >>>> ********************************************** >>>> IPv4 is over >>>> Are you ready for the new Internet ? >>>> http://www.theipv6company.com >>>> The IPv6 Company >>>> >>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Mon Jul 6 10:12:30 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Mon, 6 Jul 2026 12:12:30 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: <3817D4DB-F675-40B8-A844-847FD4189D01@darwincosta.com> References: <0A117F46-5C95-4D76-AAE9-F695C191800B@darwincosta.com> <3817D4DB-F675-40B8-A844-847FD4189D01@darwincosta.com> Message-ID: <35D96C88-DFFF-449D-A747-76691CEA46B1@consulintel.es> Normally, if you deploy IPv6 in a mobile network, the % of traffic can move ?almost? overnight from 0 to 60-70 or even up to 85%, unless you are turning on very slowly by regions or customer groups and so on. In a deployment you typically do some ?labs?, then move it to production with some experience users, then you start a massive deployment in a specific region/user group, and if everything is right, you jump to the rest of the network. Once you started, this should not take more than 6 months. Some people may prefer to go at a slower pace, but generally it doesn?t make sense once you have done the 1st big region/users group. It may happen that you have 50/50% traffic in between mobile and residential, etc. and you only start with mobile. As said, you need to know some details from inside the network. A good example is precisely the 1st massive IPv6 deployment in the world (T-Mobile) with started with NAT64 in production in 2015, then with 464XLAT. They jump from 2-3% IPv6 in 2015 to 80% in 6 months, corrected something in the network, then has been over 92% since 2018 till now. https://stats.labs.apnic.net/ipv6/AS21928?c=US&p=1&v=1&w=30&x=1 This can be observed in other deployments in many countries, but sometimes, if it is is a mix cellular, residential, business network, is difficult to appreciate what traffic belongs to each part, unless you know some data from people working in that network. Of course, if your customers have cell phones older than 12-13 years ago, that will not happen, but I don?t think generally people have so old phones. That?s when IPv6 was available in cell phones. > El 6 jul 2026, a las 11:49, Darwin Da Costa escribi?: > > > >> On 6. Jul 2026, at 11:06, jordi.palet--- via RPD wrote: >> >> Hi Darwin, > Hi Jordi, >> >> In Angola, according to APNIC, UNITEL, Paragus and Neonet, have 25-33% IPv6. Not good, something may be broken there. > It depends on how you look into it. Again, 2019 was 0% while in 2026 a movement is happening. Obviously the speed will always depend on their (networks) priorities. Our job is to push them and guide them. >> >> Of course, without knowing the exact details of those networks and how IPv6 has been deployed, I can only speculate, but based in my experience, I can point to some aspects: >> >> 1) If it is a mobile network, are they using dual-stack (even with IPv4 private addresses behind CGN) or 464XLAT? >> 2) Are they monitoring IPv4 and IPv6 at the upstreams and the rest of the network. Bad quality IPv6 transits or peering may bring HE to fallback to IPv4. >> 3) Are they using a single APN (right way to go)? Have they done test with iOS/Apple and signed the contract to provide the updated operator-profile for dual-stack or IPv6-only and to enable CLAT for the tethering? >> 4) Have they measured the top-n (I will suggest top-25) traffic destinations? >> 5) Are they taking advantage of Caches/CDNs, with need to be updated to support also IPv6? >> 6) How are they doing the Pref64 discovery or it is manually configured? How they provision and what lenght, the IPv6 prefix? >> 7) If they customer base is mainly residential, what transition technology and how is it configured at the CEs. Do they allow customers to replace the CEs and they support ?any? or only certified ones? >> 8) Marketing actions: In some cases, during many years, specially some game companies suggested to disable IPv6 in Windows. They had bugs and the easy way was ?IPv6 is the guilty?. When you deploy IPv6 you need to ask customers to revert that. Same for un-updated Android and iOS phones, you need to tell customer to keep them updated, in some Android cases, if you don?t do that, you need to offer some free bonus to customers to tell them ?you get ?n? extra free gigs? if you enable IPv6 in your config. Unfortunately this doesn?t work for iOS, the only way is to engage with your Apple liaison. >> >> This is just an example of many things that you don?t learn in trainings, just over deployment experience. Some of them are very simple, some others really need to be updated to each specific network case. Some of them are related only to mobile or wireline, some apply to both. >> >> If you have direct contact with those operators and they are interested in having an email exchange or a call to see how we can increase the IPv6 traffic looking at how the deployment has been done, let me know in pvt. I will be happy to support them at a minimum with some free tips. We could take that as a deployment case and ask them to present in the next AIS, to demonstrate how things can change. > Sure and agree with the operational points you have shared. Will do some intros and hopefully bringing them over to one of the AIS in the future. > > >> >> Regards, >> Jordi >> >> @jordipalet > > Cheers! > Darwin/. > > >> >>> El 5 jul 2026, a las 14:03, dc at darwincosta.com escribi?: >>> >>> >>> >>>> On 5 Jul 2026, at 12:29, Bope Domilongo Christian wrote: >>>> >>>> ? >>>> >>>> >>>> On Sun, 28 Jun 2026 at 11:16, jordi.palet--- via RPD > wrote: >>>>> Fortunately, deploying 464XLAT in mobile networks (the only way to go) is much easier and cheaper than in wireline. Vendors of both UEs and packet switch mobile networks support it very well since many years ago. The point, as usual, is to have the expertise and not trust what vendors try to sell you. >>>>> >>>>> Is not just a matter of teaching IPv6. In a training you don?t get the experience. There is a good reason why consultancy companies have a business: it is much cheaper to trust an experienced consultant (vendor independent) than a vendor and you avoid all the mistakes of lack of experience. >>>> >>>> Hi Jordi, >>>> >>>> 464XLAT is indeed well supported in mobile networks, but saying the main barrier is ?lack of experience? doesn?t match the data. If experience were the decisive factor, operators in high?GDP countries like Spain and Italy ? with large engineering teams and easy access to consultants ? wouldn?t be lagging in APNIC Labs measurements ( https://stats.labs.apnic.net/ipv6/XE). >>>> >>>> Yet they are. >>>> This shows the real issue isn?t consultant scarcity, but operator?level prioritization. IPv6 only moves when the dominant networks decide it matters. >>>> >>>> @christianbope <> >>> Fully agree with your statement, @Christianbope. >>> >>> We?ve seen this firsthand in Angola. Since launching the Angolan Peering Forum in 2019, we?ve focused on capacity building, knowledge sharing, and consistently engaging operators year after year. As a result, we?ve gone from 0% to approximately 15% nationwide IPv6 adoption today. >>> >>> One of the top three contributors to this progress is Angola?s largest mobile operator, UNITEL (AS37119), which has reached 26% adoption. It took time to address the necessary operational and organizational adjustments, but today they?re more engaged than ever and continue to play an important role in advancing IPv6 adoption in the country. >>> >>> Cheers. >>> >>> Darwin/. >>> >>>>> >>>>> Regards, >>>>> Jordi >>>>> >>>>> @jordipalet >>>>> >>>>> > El 27 jun 2026, a las 20:32, Ben Roberts - AfriNIC via RPD > escribi?: >>>>> > >>>>> > Alain, >>>>> > I am with you on this. >>>>> > I was talking about this yesterday with someone. It seems we have been doing the same things with IPv6 capacity building for best part of 15 years and still it?s not really pushing (mass) adoption. Yet we keep doing the same things. ?.. >>>>> > >>>>> > Most Africans connect to the phone via mobile. Manu of them through the ?big 5? of African MNO groups. >>>>> > >>>>> > We need to focus our IPv6 efforts around 5 groups of MNOs plus 4 vendors (2 from China, 2 from Scandinavia). >>>>> > >>>>> > These 9 companies know who they are?. Some of them are represented here?. >>>>> > >>>>> > Then if they start deploying IPv6 then 700M Africans will be using IPv6 >>>>> > >>>>> > The rest will fall into place?. >>>>> > >>>>> > Cheers >>>>> > >>>>> > Ben >>>>> > >>>>> > >>>>> > Sent from my iPhone >>>>> > >>>>> >> On 27 Jun 2026, at 20:52, ALAIN AINA via RPD > wrote: >>>>> >> >>>>> >> ? >>>>> >> >>>>> >>> On 26 Jun 2026, at 07:16, Benson Muite > wrote: >>>>> >>> >>>>> >>> "jordi.palet--- via RPD" > writes: >>>>> >>> >>>>> >>>> Hi Seun, >>>>> >>>> >>>>> >>>> I will actually say personally, the only acceptable X=1, but happy to concede with 2. Hopefully we don?t have a discussion and every participant chose a different number, as this is the typical issue when asking for a decision of ?number of whatever? in trying to reach consensus. >>>>> >>> >>>>> >>> The low adoption rate is worrying. Clear criteria to justify IPv4 >>>>> >>> maybe helpful. If one gets IPv4, IPv6 is free. It is good that Afrinic >>>>> >>> is doing outreach to universities. From Africa Gabon seems to have the >>>>> >>> highest percentage capability: >>>>> >>> https://stats.labs.apnic.net/ipv6 >>>>> >>> India also has good adoption and a diverse set of people in the internet >>>>> >>> industry. Understanding what has lead to adoption in these places may >>>>> >>> help guide whether what new policies sohuld be adopted if any and how to >>>>> >>> complement these with outreach and education activities. >>>>> >> >>>>> >> >>>>> >> A few years ago, I published an analysis of IPv6 uptake in Africa, examining adoption from multiple angles, including infrastructure readiness, operator behaviour, and user?access patterns. One of the key findings was the positive impact of new market entrants, particularly those who deployed IPv6?capable networks from day one. That dynamic remains relevant today. >>>>> >> >>>>> >> Unfortunately, the overall situation has not changed significantly. The user?access layer continues to be the weakest point in the regional IPv6 ecosystem. Given that Africa?s Internet is overwhelmingly mobile?centric, meaningful progress depends on Mobile Internet Service Providers taking deliberate steps to enable IPv6 at scale. Without their participation, adoption will remain slow regardless of improvements elsewhere in the ecosystem. >>>>> >> >>>>> >> There are, however, some recent initiatives underway: >>>>> >> - The ICANN grant to the African Telecommunications Union (ATU) to support IPv6 deployment in 30 African countries is a major development. >>>>> >> - ATU has already published an interim implementation report, outlining early progress and challenges. >>>>> >> >>>>> >> These efforts complement AFRINIC?s ongoing outreach, including engagement with universities and technical communities. >>>>> >> ----- >>>>> >> >>>>> >> https://www.digitalintelligence.africa/publications/alain/AFRICA-and-IPv6-uptake.html >>>>> >> https://www.icann.org/en/grant-program/first-cycle-funded-projects#deployment-ipv6-african-countries >>>>> >> https://atuuat.africa/wp-content/uploads/2026/02/ATU_IPv6_First_Interim_Status_Report_Sep-Dec_2025.pdf >>>>> >> https://atuuat.africa/wp-content/uploads/2022/11/Africa-IPv6-Development-White-Paper_double-page-version.pdf >>>>> >> >>>>> >> >>>>> >> ?Alain >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >>> >>>>> >>> >>>>> >>>> >>>>> >>>> I will also say that X is only for ?single? allocations/assigments, in the sense that if you are doing something for HA (one of the policies that reached consensus yesterday), you must do it with IPv6. There is no sense that you deploy, today, an HA infrastructure without IPv6. What do you think ? >>>>> >>>> >>>>> >>>> Regards, >>>>> >>>> Jordi >>>>> >>>> >>>>> >>>> @jordipalet >>>>> >>>> >>>>> >>>>> El 25 jun 2026, a las 2:37, Seun Ojedeji > escribi?: >>>>> >>>>> >>>>> >>>>> Hi Jordi, >>>>> >>>>> >>>>> >>>>> ---- >>>>> >>>>> Sent from my mobile >>>>> >>>>> kindly excuse typos >>>>> >>>>> >>>>> >>>>> On Wed, 24 Jun 2026, 6:14?pm jordi.palet--- via RPD, >> wrote: >>>>> >>>>>> . >>>>> >>>>>> >>>>> >>>>>> So there is no difference in now setting a policy that clearly say, you get more IPv4, but you must also deploy IPv6. >>>>> >>>>>> >>>>> >>>>>> We could also do something slightly different, I?m not sure if this is what Seun tried to say in the mic earlier this afternoon. >>>>> >>>>>> >>>>> >>>>>> We don?t give any more IPv4 resources if you already got them previously. This has been done by most of the other RIRs. Will you agree with that? Only newcomers can get IPv4. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> SO: More like you don't get IPv4 resources if you already got it for X number of times in the current phase unless you meet the IPv6 deployment plan requirements. My intention is for X not !=Once >>>>> >>>>> >>>>> >>>>> Regards >>>>> >>>>>> >>>>> >>>>>> Now, as a 2nd part of the proposal, resources left (even recovered), can be provided to anyone who also deploy IPv6, regardless of being a newcomer or an existing member. >>>>> >>>>>> >>>>> >>>>>> What do you think? >>>>> >>>>>> >>>>> >>>>>> Regards, >>>>> >>>>>> Jordi >>>>> >>>>>> >>>>> >>>>>> @jordipalet >>>>> >>> >>>>> >>> _______________________________________________ >>>>> >>> RPD mailing list >>>>> >>> RPD at afrinic.net >>>>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>> >> >>>>> >> >>>>> >> >>>>> >> _______________________________________________ >>>>> >> RPD mailing list >>>>> >> RPD at afrinic.net >>>>> >> https://lists.afrinic.net/mailman/listinfo/rpd >>>>> > >>>>> > _______________________________________________ >>>>> > RPD mailing list >>>>> > RPD at afrinic.net >>>>> > https://lists.afrinic.net/mailman/listinfo/rpd >>>>> >>>>> >>>>> ********************************************** >>>>> IPv4 is over >>>>> Are you ready for the new Internet ? >>>>> http://www.theipv6company.com >>>>> The IPv6 Company >>>>> >>>>> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> RPD mailing list >>>>> RPD at afrinic.net >>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mokoenakeabetswe003 at gmail.com Mon Jul 6 11:04:01 2026 From: mokoenakeabetswe003 at gmail.com (Keabetswe Mokoena) Date: Mon, 6 Jul 2026 13:04:01 +0200 Subject: [rpd] (no subject) Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1000114534.jpg Type: image/jpeg Size: 103528 bytes Desc: not available URL: From zimkhithamguqulwa32 at gmail.com Mon Jul 6 16:15:53 2026 From: zimkhithamguqulwa32 at gmail.com (Zimkhitha Mguqulwa) Date: Mon, 6 Jul 2026 18:15:53 +0200 Subject: [rpd] (no subject) Message-ID: Dear PDWG, I hope everyone is doing well. I am new to the mailing list and am sending this message to confirm that my subscription and posting permissions are working correctly. I look forward to following and contributing to future discussions. Kind regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Tue Jul 7 07:22:14 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Tue, 7 Jul 2026 09:22:14 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01 Message-ID: Dear colleagues, I would like to share another perspective on the proposal. >From my understanding, the primary role of the Regional Internet Registries has always been to coordinate Internet number resources through transparent, community-developed policies. Making IPv6 deployment a requirement for IPv4 Soft Landing appears to extend that role into evaluating how network operators design and manage their networks. This raises an important governance question: how would it be determined whether an operator has deployed "enough" IPv6? Would this be based on traffic percentages, addressing plans, or some other measure? Different operators also have different deployment models, which could make such assessments difficult and open to interpretation. In my view, Soft Landing policies should remain focused on the fair management of IPv4 resources rather than using IPv4 allocation to influence network architecture decisions. I fully support continued IPv6 adoption through technical assistance, training, operational collaboration, and knowledge sharing. However, making IPv6 deployment a compliance requirement for IPv4 policy may unintentionally expand the role of the registry beyond neutral resource coordination. As the Internet continues to evolve, I believe it is important to maintain a clear distinction between coordinating Internet number resources and influencing operational decisions. Kind regards, Fundiswa Nadia Maseko "Governance should follow operational reality." -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Tue Jul 7 07:24:00 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Tue, 7 Jul 2026 09:24:00 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01 Message-ID: Dear Jordi and colleagues, Thank you for your detailed contribution. Your examples clearly demonstrate that, with the right planning, expertise and organisational commitment, IPv6 deployment can progress rapidly. Those operational experiences are undoubtedly valuable and should continue to be shared across the community. However, I find myself asking a broader policy question. What is the primary objective of an IPv4 Soft Landing policy? Is it to manage the fair and efficient allocation of remaining IPv4 resources, or is it to encourage the deployment of IPv6? While both are important, I believe they are distinct policy objectives and may require different policy instruments. If IPv6 deployment becomes a prerequisite for IPv4 eligibility, could that unintentionally shift the role of Soft Landing from resource management to influencing network strategy? One of the enduring strengths of the Internet has been that operators retain the flexibility to choose technologies based on their own operational realities, customer needs and commercial priorities. That flexibility has enabled innovation across networks with very different business models and levels of maturity. >From that perspective, I wonder whether this discussion presents an opportunity to consider broader governance reforms instead of additional deployment criteria. For example: - Should policies place greater emphasis on portability so that operators retain confidence in the continuity of their Internet number resources? - Should exit rights be recognised as an important governance safeguard, allowing operators meaningful alternatives if institutional confidence is weakened? - Should registry policy focus on reducing unnecessary administrative discretion while strengthening predictability and legal certainty? - As Internet number resources continue to grow in economic importance, should governance evolve to reinforce operator autonomy rather than introduce additional conditions tied to technology choices? Jordi, I would genuinely value your opinion on this. Do you see portability and exit rights as governance principles that deserve greater attention within the RIR policy framework, particularly as the Internet ecosystem becomes more decentralised and commercially diverse? It seems to me that governance reforms which strengthen neutrality, continuity and operator choice would benefit both IPv4 and IPv6 communities alike, regardless of where each operator is on its deployment journey. Kind regards, Nonhlanhla "Strong governance is built on portability, neutrality and choice." -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Tue Jul 7 07:47:44 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Tue, 7 Jul 2026 09:47:44 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01 In-Reply-To: References: Message-ID: <7C848C2A-E257-4F56-BC64-7EC6961311EB@consulintel.es> Hi Nia, The CPM is clear about the reason for the Soft Landing policy: "In order to ensure a smooth transition to IPv6, AFRINIC's pool should be managed to provide members with address space after the IPv4 pool is depleted. This will help in maintaining IPv4 networks while deploying IPv6 networks - a practice that characterizes the transition period." If we don?t ?attach" the soft landing IPv4 remaining resources to the IPv6 deployment, then there is no need for a soft landing policy. It will be much better to just follow pre-soft-landing policies and let the natural IPv4 exhaustion to progress. To correctly answer yous questions, I will like to understand what do you mean with ?portability?. Note that all the governments, sooner or later, will need to enforce the IPv6 deployment. There is no question about that. Regulation is not good if we can, as a technical community, self-regulate in advance with our own pace, specially considering that law makers, courts, etc., etc., have not the knowledge neither expertise, and in fact they have a very hard time trying to understand how Internet works, and consequently they can make severe mistakes with such regulations. There are many examples of that in many countries, such as when the Spanish, Italian and other courts decided that, to fight against football piracy is right to enforce filtering based on IPs, VPNs, etc., and this create millions of losses to absolutely legal and honest web sites, e-commerce, NGOs, etc. Regards, Jordi @jordipalet > El 7 jul 2026, a las 9:24, Nia Petronella escribi?: > > Dear Jordi and colleagues, > > Thank you for your detailed contribution. Your examples clearly demonstrate that, with the right planning, expertise and organisational commitment, IPv6 deployment can progress rapidly. Those operational experiences are undoubtedly valuable and should continue to be shared across the community. > > However, I find myself asking a broader policy question. > > What is the primary objective of an IPv4 Soft Landing policy? > > Is it to manage the fair and efficient allocation of remaining IPv4 resources, or is it to encourage the deployment of IPv6? > > While both are important, I believe they are distinct policy objectives and may require different policy instruments. > > If IPv6 deployment becomes a prerequisite for IPv4 eligibility, could that unintentionally shift the role of Soft Landing from resource management to influencing network strategy? > > One of the enduring strengths of the Internet has been that operators retain the flexibility to choose technologies based on their own operational realities, customer needs and commercial priorities. That flexibility has enabled innovation across networks with very different business models and levels of maturity. > > From that perspective, I wonder whether this discussion presents an opportunity to consider broader governance reforms instead of additional deployment criteria. > > For example: > > - Should policies place greater emphasis on portability so that operators retain confidence in the continuity of their Internet number resources? > - Should exit rights be recognised as an important governance safeguard, allowing operators meaningful alternatives if institutional confidence is weakened? > - Should registry policy focus on reducing unnecessary administrative discretion while strengthening predictability and legal certainty? > - As Internet number resources continue to grow in economic importance, should governance evolve to reinforce operator autonomy rather than introduce additional conditions tied to technology choices? > > Jordi, I would genuinely value your opinion on this. > > Do you see portability and exit rights as governance principles that deserve greater attention within the RIR policy framework, particularly as the Internet ecosystem becomes more decentralised and commercially diverse? > > It seems to me that governance reforms which strengthen neutrality, continuity and operator choice would benefit both IPv4 and IPv6 communities alike, regardless of where each operator is on its deployment journey. > > > Kind regards, > > Nonhlanhla > > "Strong governance is built on portability, neutrality and choice." > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Tue Jul 7 07:53:24 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Tue, 7 Jul 2026 09:53:24 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01 In-Reply-To: References: Message-ID: <53A283EE-4C58-4916-993D-4CB3311BB5D9@consulintel.es> Hi Fundiswa, All the policies that we have, somehow are already doing that. The RIRs evaluate the justification based on how you use the resources, so that clearly has an impact on how you design and manage your network. There is nothing different here. In the end, it is a community decision based on what is good for the overall community, not what is good for the ISPs or the RIRs, because the Internet resources are from the community. So yes, we are and we must keep doing that, influence how the Internet resources are managed, because are community resources! If you pay attention to the proposal text, and the previous discussion, I think there is no doubt, that there is a clear rationale about how to measure the deployment. Please, let me know what specific points aren?t clear, so we can progress on that. Regards, Jordi @jordipalet > El 7 jul 2026, a las 9:22, Fundiswa Nadia Maseko escribi?: > > Dear colleagues, > > I would like to share another perspective on the proposal. > > From my understanding, the primary role of the Regional Internet Registries has always been to coordinate Internet number resources through transparent, community-developed policies. > > Making IPv6 deployment a requirement for IPv4 Soft Landing appears to extend that role into evaluating how network operators design and manage their networks. > > This raises an important governance question: how would it be determined whether an operator has deployed "enough" IPv6? Would this be based on traffic percentages, addressing plans, or some other measure? Different operators also have different deployment models, which could make such assessments difficult and open to interpretation. > > In my view, Soft Landing policies should remain focused on the fair management of IPv4 resources rather than using IPv4 allocation to influence network architecture decisions. > > I fully support continued IPv6 adoption through technical assistance, training, operational collaboration, and knowledge sharing. However, making IPv6 deployment a compliance requirement for IPv4 policy may unintentionally expand the role of the registry beyond neutral resource coordination. > > As the Internet continues to evolve, I believe it is important to maintain a clear distinction between coordinating Internet number resources and influencing operational decisions. > > Kind regards, > > Fundiswa Nadia Maseko > > "Governance should follow operational reality." > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From mguqulwazenalo at gmail.com Tue Jul 7 07:58:56 2026 From: mguqulwazenalo at gmail.com (Zenalo Mguqulwa) Date: Tue, 7 Jul 2026 09:58:56 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 8 In-Reply-To: References: Message-ID: Dear colleagues, Thank you for the thoughtful discussion. One question I have is whether this proposal changes how the Soft Landing Policy is implemented. The CPM already states that the purpose of Soft Landing is to support the transition to IPv6 while managing the remaining IPv4 pool. My question is whether requiring measurable IPv6 deployment as a condition for receiving IPv4 moves the policy beyond encouraging transition and into evaluating how operators implement their networks. If so, should this type of oversight form part of resource policy, or would it be more appropriate to encourage IPv6 adoption through technical assistance, best practices and community collaboration? I think clarifying this distinction may help the community evaluate the proposal. Kind regards, Zim On Tue, 7 Jul 2026 at 09:48, wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. (no subject) (Zimkhitha Mguqulwa) > 2. Re: IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01 (Fundiswa Nadia Maseko) > 3. Re: IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01 (Nia Petronella) > 4. Re: IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01 (jordi.palet at consulintel.es) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 6 Jul 2026 18:15:53 +0200 > From: Zimkhitha Mguqulwa > To: rpd at afrinic.net > Subject: [rpd] (no subject) > Message-ID: > < > CAJ7uu8nEuc_j5kkKV8EhX_VhkgZTNk1uPTRUFOot35bcvudJJQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear PDWG, > > I hope everyone is doing well. > > I am new to the mailing list and am sending this message to confirm that my > subscription and posting permissions are working correctly. I look forward > to following and contributing to future discussions. > > Kind regards, > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260706/2ee1356b/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Tue, 7 Jul 2026 09:22:14 +0200 > From: Fundiswa Nadia Maseko > To: rpd at afrinic.net > Cc: rpd-owner at afrinic.net > Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01 > Message-ID: > LcfHORdx6R94zjqpnOq-8eYA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear colleagues, > > I would like to share another perspective on the proposal. > > >From my understanding, the primary role of the Regional Internet > Registries > has always been to coordinate Internet number resources through > transparent, community-developed policies. > > Making IPv6 deployment a requirement for IPv4 Soft Landing appears to > extend that role into evaluating how network operators design and manage > their networks. > > This raises an important governance question: how would it be determined > whether an operator has deployed "enough" IPv6? Would this be based on > traffic percentages, addressing plans, or some other measure? Different > operators also have different deployment models, which could make such > assessments difficult and open to interpretation. > > In my view, Soft Landing policies should remain focused on the fair > management of IPv4 resources rather than using IPv4 allocation to influence > network architecture decisions. > > I fully support continued IPv6 adoption through technical assistance, > training, operational collaboration, and knowledge sharing. However, making > IPv6 deployment a compliance requirement for IPv4 policy may > unintentionally expand the role of the registry beyond neutral resource > coordination. > > As the Internet continues to evolve, I believe it is important to maintain > a clear distinction between coordinating Internet number resources and > influencing operational decisions. > > Kind regards, > > Fundiswa Nadia Maseko > > "Governance should follow operational reality." > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260707/40ad19d8/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Tue, 7 Jul 2026 09:24:00 +0200 > From: Nia Petronella > To: rpd at afrinic.net, rpd-owner at afrinic.net > Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01 > Message-ID: > < > CA+mDOg3EfQ998gJq2KSHnsWeNRa3H72ZbX9eKQXvRRujU9Xebw at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Jordi and colleagues, > > Thank you for your detailed contribution. Your examples clearly demonstrate > that, with the right planning, expertise and organisational commitment, > IPv6 deployment can progress rapidly. Those operational experiences are > undoubtedly valuable and should continue to be shared across the community. > > However, I find myself asking a broader policy question. > > What is the primary objective of an IPv4 Soft Landing policy? > > Is it to manage the fair and efficient allocation of remaining IPv4 > resources, or is it to encourage the deployment of IPv6? > > While both are important, I believe they are distinct policy objectives and > may require different policy instruments. > > If IPv6 deployment becomes a prerequisite for IPv4 eligibility, could that > unintentionally shift the role of Soft Landing from resource management to > influencing network strategy? > > One of the enduring strengths of the Internet has been that operators > retain the flexibility to choose technologies based on their own > operational realities, customer needs and commercial priorities. That > flexibility has enabled innovation across networks with very different > business models and levels of maturity. > > >From that perspective, I wonder whether this discussion presents an > opportunity to consider broader governance reforms instead of additional > deployment criteria. > > For example: > > - Should policies place greater emphasis on portability so that operators > retain confidence in the continuity of their Internet number resources? > - Should exit rights be recognised as an important governance safeguard, > allowing operators meaningful alternatives if institutional confidence is > weakened? > - Should registry policy focus on reducing unnecessary administrative > discretion while strengthening predictability and legal certainty? > - As Internet number resources continue to grow in economic importance, > should governance evolve to reinforce operator autonomy rather than > introduce additional conditions tied to technology choices? > > Jordi, I would genuinely value your opinion on this. > > Do you see portability and exit rights as governance principles that > deserve greater attention within the RIR policy framework, particularly as > the Internet ecosystem becomes more decentralised and commercially diverse? > > It seems to me that governance reforms which strengthen neutrality, > continuity and operator choice would benefit both IPv4 and IPv6 communities > alike, regardless of where each operator is on its deployment journey. > > > Kind regards, > > Nonhlanhla > > "Strong governance is built on portability, neutrality and choice." > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260707/d72ae894/attachment-0001.html > > > > ------------------------------ > > Message: 4 > Date: Tue, 7 Jul 2026 09:47:44 +0200 > From: "jordi.palet at consulintel.es" > To: rpd at afrinic.net > Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01 > Message-ID: <7C848C2A-E257-4F56-BC64-7EC6961311EB at consulintel.es> > Content-Type: text/plain; charset="utf-8" > > Hi Nia, > > The CPM is clear about the reason for the Soft Landing policy: > > "In order to ensure a smooth transition to IPv6, AFRINIC's pool should be > managed to provide members with address space after the IPv4 pool is > depleted. This will help in maintaining IPv4 networks while deploying IPv6 > networks - a practice that characterizes the transition period." > > If we don?t ?attach" the soft landing IPv4 remaining resources to the IPv6 > deployment, then there is no need for a soft landing policy. It will be > much better to just follow pre-soft-landing policies and let the natural > IPv4 exhaustion to progress. > > To correctly answer yous questions, I will like to understand what do you > mean with ?portability?. > > Note that all the governments, sooner or later, will need to enforce the > IPv6 deployment. There is no question about that. Regulation is not good if > we can, as a technical community, self-regulate in advance with our own > pace, specially considering that law makers, courts, etc., etc., have not > the knowledge neither expertise, and in fact they have a very hard time > trying to understand how Internet works, and consequently they can make > severe mistakes with such regulations. There are many examples of that in > many countries, such as when the Spanish, Italian and other courts decided > that, to fight against football piracy is right to enforce filtering based > on IPs, VPNs, etc., and this create millions of losses to absolutely legal > and honest web sites, e-commerce, NGOs, etc. > > Regards, > Jordi > > @jordipalet > > > El 7 jul 2026, a las 9:24, Nia Petronella < > nonhlanhlapetronella85 at gmail.com> escribi?: > > > > Dear Jordi and colleagues, > > > > Thank you for your detailed contribution. Your examples clearly > demonstrate that, with the right planning, expertise and organisational > commitment, IPv6 deployment can progress rapidly. Those operational > experiences are undoubtedly valuable and should continue to be shared > across the community. > > > > However, I find myself asking a broader policy question. > > > > What is the primary objective of an IPv4 Soft Landing policy? > > > > Is it to manage the fair and efficient allocation of remaining IPv4 > resources, or is it to encourage the deployment of IPv6? > > > > While both are important, I believe they are distinct policy objectives > and may require different policy instruments. > > > > If IPv6 deployment becomes a prerequisite for IPv4 eligibility, could > that unintentionally shift the role of Soft Landing from resource > management to influencing network strategy? > > > > One of the enduring strengths of the Internet has been that operators > retain the flexibility to choose technologies based on their own > operational realities, customer needs and commercial priorities. That > flexibility has enabled innovation across networks with very different > business models and levels of maturity. > > > > From that perspective, I wonder whether this discussion presents an > opportunity to consider broader governance reforms instead of additional > deployment criteria. > > > > For example: > > > > - Should policies place greater emphasis on portability so that > operators retain confidence in the continuity of their Internet number > resources? > > - Should exit rights be recognised as an important governance safeguard, > allowing operators meaningful alternatives if institutional confidence is > weakened? > > - Should registry policy focus on reducing unnecessary administrative > discretion while strengthening predictability and legal certainty? > > - As Internet number resources continue to grow in economic importance, > should governance evolve to reinforce operator autonomy rather than > introduce additional conditions tied to technology choices? > > > > Jordi, I would genuinely value your opinion on this. > > > > Do you see portability and exit rights as governance principles that > deserve greater attention within the RIR policy framework, particularly as > the Internet ecosystem becomes more decentralised and commercially diverse? > > > > It seems to me that governance reforms which strengthen neutrality, > continuity and operator choice would benefit both IPv4 and IPv6 communities > alike, regardless of where each operator is on its deployment journey. > > > > > > Kind regards, > > > > Nonhlanhla > > > > "Strong governance is built on portability, neutrality and choice." > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260707/7805f63f/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 8 > *********************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Tue Jul 7 08:25:03 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Tue, 7 Jul 2026 10:25:03 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01 Message-ID: Dear Jordi, Thank you for your response. I think we may have reached the point where the discussion is no longer about IPv6, but about the philosophy of Internet governance itself. You mention that Internet number resources are "community resources" and that policies should reflect what is good for "the community." That sounds reasonable in principle, but I believe it deserves much closer examination in practice. Who exactly is "the community"? Is it the relatively small group of individuals who consistently participate in policy discussions, attend meetings and understand the procedural mechanics of the PDP? Or is it the thousands of operators, ISPs, cloud providers and enterprises that actually finance, deploy and operate the infrastructure on which the Internet depends? Those are not necessarily the same constituency. One of the structural weaknesses of multistakeholder governance is the assumption that participation automatically equals representation. In reality, most operators are focused on running networks, serving customers and investing in infrastructure. They do not have the time or resources to engage continuously in governance processes. As participation narrows, influence naturally concentrates among those who are able to remain permanently engaged. That does not make the process illegitimate, but it should make us cautious about equating "community consensus" with the interests of the wider operational community. This is why I am concerned about using IPv6 deployment as a criterion for IPv4 Soft Landing. Once the registry begins determining which architectural choices are sufficiently aligned with community objectives, we move beyond neutral coordination and into behavioural governance. Historically, registries existed to coordinate uniqueness and maintain authoritative records. Today, we are discussing whether they should also influence technology adoption strategies. That is a significant evolution of mandate. Rather than expanding policy into operational design, I believe this is an opportunity to discuss reforms that strengthen the governance framework itself. For example: ? How do we ensure operators have meaningful portability if confidence in an institution declines? ? Should members have clearer exit rights so governance remains genuinely voluntary rather than structurally captive? ? How do we ensure neutrality when registries are simultaneously coordinating resources and promoting preferred deployment outcomes? ? Should governance evolve to give greater weight to those with long-term operational and economic exposure, alongside those who participate regularly in policy forums? These questions become increasingly important as Internet number resources mature from purely technical identifiers into economically significant infrastructure. My concern is therefore not whether IPv6 is valuable. It clearly is. My concern is whether IPv4 policy should become the mechanism through which registries influence protocol adoption, or whether our focus should instead be on ensuring governance remains neutral, accountable and resilient enough to accommodate different operational realities. Perhaps that is the broader discussion we should be having. Kind regards, Fundiswa Nadia Maseko "Neutral coordination earns trust. Trust should never depend on institutional preference." -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Tue Jul 7 08:25:40 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Tue, 7 Jul 2026 10:25:40 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 8 In-Reply-To: References: Message-ID: Hi Zenalo, I think it is clear that both is needed: technical assistance which is already being provided since many years (up to a certain point, because a RIR is not a business for training and consultancy and doing that my interfere even with competition laws, and of course, the RIR staff aren?t doing actual production deployments in such way they have all the required expertise) and community policies that protect and ensure a fair usage of the community resources. As I said before, all the policies already have influence in how the networks are operated, is difficult to draw a border line, but the community policies are to protect the community resources, not the ISP business. Otherwise, the policies will be made by the ISPs, instead of the community and the is not how we decided to do this in a global RIR ecosystem-scale. Regards, Jordi @jordipalet > El 7 jul 2026, a las 9:58, Zenalo Mguqulwa escribi?: > > Dear colleagues, > > Thank you for the thoughtful discussion. > > One question I have is whether this proposal changes how the Soft Landing Policy is implemented. > > The CPM already states that the purpose of Soft Landing is to support the transition to IPv6 while managing the remaining IPv4 pool. My question is whether requiring measurable IPv6 deployment as a condition for receiving IPv4 moves the policy beyond encouraging transition and into evaluating how operators implement their networks. > > If so, should this type of oversight form part of resource policy, or would it be more appropriate to encourage IPv6 adoption through technical assistance, best practices and community collaboration? > > I think clarifying this distinction may help the community evaluate the proposal. > > Kind regards, > Zim > > > On Tue, 7 Jul 2026 at 09:48, > wrote: >> Send RPD mailing list submissions to >> rpd at afrinic.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.afrinic.net/mailman/listinfo/rpd >> or, via email, send a message with subject or body 'help' to >> rpd-request at afrinic.net >> >> You can reach the person managing the list at >> rpd-owner at afrinic.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of RPD digest..." >> >> >> Today's Topics: >> >> 1. (no subject) (Zimkhitha Mguqulwa) >> 2. Re: IPv6 as a criteria in IPv4 Soft Landing >> AFPUB-2026-v6-001-DRAFT01 (Fundiswa Nadia Maseko) >> 3. Re: IPv6 as a criteria in IPv4 Soft Landing >> AFPUB-2026-v6-001-DRAFT01 (Nia Petronella) >> 4. Re: IPv6 as a criteria in IPv4 Soft Landing >> AFPUB-2026-v6-001-DRAFT01 (jordi.palet at consulintel.es ) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Mon, 6 Jul 2026 18:15:53 +0200 >> From: Zimkhitha Mguqulwa > >> To: rpd at afrinic.net >> Subject: [rpd] (no subject) >> Message-ID: >> > >> Content-Type: text/plain; charset="utf-8" >> >> Dear PDWG, >> >> I hope everyone is doing well. >> >> I am new to the mailing list and am sending this message to confirm that my >> subscription and posting permissions are working correctly. I look forward >> to following and contributing to future discussions. >> >> Kind regards, >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> ------------------------------ >> >> Message: 2 >> Date: Tue, 7 Jul 2026 09:22:14 +0200 >> From: Fundiswa Nadia Maseko > >> To: rpd at afrinic.net >> Cc: rpd-owner at afrinic.net >> Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing >> AFPUB-2026-v6-001-DRAFT01 >> Message-ID: >> > >> Content-Type: text/plain; charset="utf-8" >> >> Dear colleagues, >> >> I would like to share another perspective on the proposal. >> >> >From my understanding, the primary role of the Regional Internet Registries >> has always been to coordinate Internet number resources through >> transparent, community-developed policies. >> >> Making IPv6 deployment a requirement for IPv4 Soft Landing appears to >> extend that role into evaluating how network operators design and manage >> their networks. >> >> This raises an important governance question: how would it be determined >> whether an operator has deployed "enough" IPv6? Would this be based on >> traffic percentages, addressing plans, or some other measure? Different >> operators also have different deployment models, which could make such >> assessments difficult and open to interpretation. >> >> In my view, Soft Landing policies should remain focused on the fair >> management of IPv4 resources rather than using IPv4 allocation to influence >> network architecture decisions. >> >> I fully support continued IPv6 adoption through technical assistance, >> training, operational collaboration, and knowledge sharing. However, making >> IPv6 deployment a compliance requirement for IPv4 policy may >> unintentionally expand the role of the registry beyond neutral resource >> coordination. >> >> As the Internet continues to evolve, I believe it is important to maintain >> a clear distinction between coordinating Internet number resources and >> influencing operational decisions. >> >> Kind regards, >> >> Fundiswa Nadia Maseko >> >> "Governance should follow operational reality." >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> ------------------------------ >> >> Message: 3 >> Date: Tue, 7 Jul 2026 09:24:00 +0200 >> From: Nia Petronella > >> To: rpd at afrinic.net , rpd-owner at afrinic.net >> Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing >> AFPUB-2026-v6-001-DRAFT01 >> Message-ID: >> > >> Content-Type: text/plain; charset="utf-8" >> >> Dear Jordi and colleagues, >> >> Thank you for your detailed contribution. Your examples clearly demonstrate >> that, with the right planning, expertise and organisational commitment, >> IPv6 deployment can progress rapidly. Those operational experiences are >> undoubtedly valuable and should continue to be shared across the community. >> >> However, I find myself asking a broader policy question. >> >> What is the primary objective of an IPv4 Soft Landing policy? >> >> Is it to manage the fair and efficient allocation of remaining IPv4 >> resources, or is it to encourage the deployment of IPv6? >> >> While both are important, I believe they are distinct policy objectives and >> may require different policy instruments. >> >> If IPv6 deployment becomes a prerequisite for IPv4 eligibility, could that >> unintentionally shift the role of Soft Landing from resource management to >> influencing network strategy? >> >> One of the enduring strengths of the Internet has been that operators >> retain the flexibility to choose technologies based on their own >> operational realities, customer needs and commercial priorities. That >> flexibility has enabled innovation across networks with very different >> business models and levels of maturity. >> >> >From that perspective, I wonder whether this discussion presents an >> opportunity to consider broader governance reforms instead of additional >> deployment criteria. >> >> For example: >> >> - Should policies place greater emphasis on portability so that operators >> retain confidence in the continuity of their Internet number resources? >> - Should exit rights be recognised as an important governance safeguard, >> allowing operators meaningful alternatives if institutional confidence is >> weakened? >> - Should registry policy focus on reducing unnecessary administrative >> discretion while strengthening predictability and legal certainty? >> - As Internet number resources continue to grow in economic importance, >> should governance evolve to reinforce operator autonomy rather than >> introduce additional conditions tied to technology choices? >> >> Jordi, I would genuinely value your opinion on this. >> >> Do you see portability and exit rights as governance principles that >> deserve greater attention within the RIR policy framework, particularly as >> the Internet ecosystem becomes more decentralised and commercially diverse? >> >> It seems to me that governance reforms which strengthen neutrality, >> continuity and operator choice would benefit both IPv4 and IPv6 communities >> alike, regardless of where each operator is on its deployment journey. >> >> >> Kind regards, >> >> Nonhlanhla >> >> "Strong governance is built on portability, neutrality and choice." >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> ------------------------------ >> >> Message: 4 >> Date: Tue, 7 Jul 2026 09:47:44 +0200 >> From: "jordi.palet at consulintel.es " > >> To: rpd at afrinic.net >> Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing >> AFPUB-2026-v6-001-DRAFT01 >> Message-ID: <7C848C2A-E257-4F56-BC64-7EC6961311EB at consulintel.es > >> Content-Type: text/plain; charset="utf-8" >> >> Hi Nia, >> >> The CPM is clear about the reason for the Soft Landing policy: >> >> "In order to ensure a smooth transition to IPv6, AFRINIC's pool should be managed to provide members with address space after the IPv4 pool is depleted. This will help in maintaining IPv4 networks while deploying IPv6 networks - a practice that characterizes the transition period." >> >> If we don?t ?attach" the soft landing IPv4 remaining resources to the IPv6 deployment, then there is no need for a soft landing policy. It will be much better to just follow pre-soft-landing policies and let the natural IPv4 exhaustion to progress. >> >> To correctly answer yous questions, I will like to understand what do you mean with ?portability?. >> >> Note that all the governments, sooner or later, will need to enforce the IPv6 deployment. There is no question about that. Regulation is not good if we can, as a technical community, self-regulate in advance with our own pace, specially considering that law makers, courts, etc., etc., have not the knowledge neither expertise, and in fact they have a very hard time trying to understand how Internet works, and consequently they can make severe mistakes with such regulations. There are many examples of that in many countries, such as when the Spanish, Italian and other courts decided that, to fight against football piracy is right to enforce filtering based on IPs, VPNs, etc., and this create millions of losses to absolutely legal and honest web sites, e-commerce, NGOs, etc. >> >> Regards, >> Jordi >> >> @jordipalet >> >> > El 7 jul 2026, a las 9:24, Nia Petronella > escribi?: >> > >> > Dear Jordi and colleagues, >> > >> > Thank you for your detailed contribution. Your examples clearly demonstrate that, with the right planning, expertise and organisational commitment, IPv6 deployment can progress rapidly. Those operational experiences are undoubtedly valuable and should continue to be shared across the community. >> > >> > However, I find myself asking a broader policy question. >> > >> > What is the primary objective of an IPv4 Soft Landing policy? >> > >> > Is it to manage the fair and efficient allocation of remaining IPv4 resources, or is it to encourage the deployment of IPv6? >> > >> > While both are important, I believe they are distinct policy objectives and may require different policy instruments. >> > >> > If IPv6 deployment becomes a prerequisite for IPv4 eligibility, could that unintentionally shift the role of Soft Landing from resource management to influencing network strategy? >> > >> > One of the enduring strengths of the Internet has been that operators retain the flexibility to choose technologies based on their own operational realities, customer needs and commercial priorities. That flexibility has enabled innovation across networks with very different business models and levels of maturity. >> > >> > From that perspective, I wonder whether this discussion presents an opportunity to consider broader governance reforms instead of additional deployment criteria. >> > >> > For example: >> > >> > - Should policies place greater emphasis on portability so that operators retain confidence in the continuity of their Internet number resources? >> > - Should exit rights be recognised as an important governance safeguard, allowing operators meaningful alternatives if institutional confidence is weakened? >> > - Should registry policy focus on reducing unnecessary administrative discretion while strengthening predictability and legal certainty? >> > - As Internet number resources continue to grow in economic importance, should governance evolve to reinforce operator autonomy rather than introduce additional conditions tied to technology choices? >> > >> > Jordi, I would genuinely value your opinion on this. >> > >> > Do you see portability and exit rights as governance principles that deserve greater attention within the RIR policy framework, particularly as the Internet ecosystem becomes more decentralised and commercially diverse? >> > >> > It seems to me that governance reforms which strengthen neutrality, continuity and operator choice would benefit both IPv4 and IPv6 communities alike, regardless of where each operator is on its deployment journey. >> > >> > >> > Kind regards, >> > >> > Nonhlanhla >> > >> > "Strong governance is built on portability, neutrality and choice." >> > _______________________________________________ >> > RPD mailing list >> > RPD at afrinic.net >> > https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ------------------------------ >> >> End of RPD Digest, Vol 222, Issue 8 >> *********************************** > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Tue Jul 7 08:51:26 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Tue, 7 Jul 2026 10:51:26 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01 In-Reply-To: References: Message-ID: Community is the global humanity, anyone interested in the Internet resources, which have been standardized by IETF and has delegated to IANA and the RIRs its management based on the standards. It has been clearly defined, I don?t think there is any doubt on that. Anyone interested can participate. Note that due to the global nature of Internet, any mismanagement of the resources affects all the rest of the Internet. Everyone is able to participate on the PDP, not just in AFRINIC, but in all the other regions as well. It is an open and transparent process and that participation is designed in such a way that the global good is the top priority, not any specific individual or business. This is the same concept as when we do standards in IETF. We do that as individuals, not as companies and is not a voting, just to make sure that all the positions are well balanced, having the top priority of global good. ?don?t have the time? is always a good excuse. You manage your time. If a person or a business is not happy with something, it should get involved. Just barking is not the way. You keep talking about portability, but you don?t explain that, so I?m unable to respond to that properly to your questions about that. Saludos, Jordi @jordipalet > El 7 jul 2026, a las 10:25, Fundiswa Nadia Maseko escribi?: > > Dear Jordi, > > Thank you for your response. > > I think we may have reached the point where the discussion is no longer about IPv6, but about the philosophy of Internet governance itself. > > You mention that Internet number resources are "community resources" and that policies should reflect what is good for "the community." That sounds reasonable in principle, but I believe it deserves much closer examination in practice. > > Who exactly is "the community"? > > Is it the relatively small group of individuals who consistently participate in policy discussions, attend meetings and understand the procedural mechanics of the PDP? Or is it the thousands of operators, ISPs, cloud providers and enterprises that actually finance, deploy and operate the infrastructure on which the Internet depends? > > Those are not necessarily the same constituency. > > One of the structural weaknesses of multistakeholder governance is the assumption that participation automatically equals representation. In reality, most operators are focused on running networks, serving customers and investing in infrastructure. They do not have the time or resources to engage continuously in governance processes. As participation narrows, influence naturally concentrates among those who are able to remain permanently engaged. > > That does not make the process illegitimate, but it should make us cautious about equating "community consensus" with the interests of the wider operational community. > > This is why I am concerned about using IPv6 deployment as a criterion for IPv4 Soft Landing. > > Once the registry begins determining which architectural choices are sufficiently aligned with community objectives, we move beyond neutral coordination and into behavioural governance. > > Historically, registries existed to coordinate uniqueness and maintain authoritative records. Today, we are discussing whether they should also influence technology adoption strategies. > > That is a significant evolution of mandate. > > Rather than expanding policy into operational design, I believe this is an opportunity to discuss reforms that strengthen the governance framework itself. > > For example: > > ? How do we ensure operators have meaningful portability if confidence in an institution declines? > ? Should members have clearer exit rights so governance remains genuinely voluntary rather than structurally captive? > ? How do we ensure neutrality when registries are simultaneously coordinating resources and promoting preferred deployment outcomes? > ? Should governance evolve to give greater weight to those with long-term operational and economic exposure, alongside those who participate regularly in policy forums? > > These questions become increasingly important as Internet number resources mature from purely technical identifiers into economically significant infrastructure. > > My concern is therefore not whether IPv6 is valuable. It clearly is. > > My concern is whether IPv4 policy should become the mechanism through which registries influence protocol adoption, or whether our focus should instead be on ensuring governance remains neutral, accountable and resilient enough to accommodate different operational realities. > > Perhaps that is the broader discussion we should be having. > > Kind regards, > > Fundiswa Nadia Maseko > > "Neutral coordination earns trust. Trust should never depend on institutional preference." ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From entlemokheseng at gmail.com Tue Jul 7 09:01:45 2026 From: entlemokheseng at gmail.com (entle mokheseng) Date: Tue, 7 Jul 2026 09:01:45 +0000 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01 Message-ID: Dear Jordi, Thank you for your detailed contribution and for sharing practical deployment experiences from different networks. Reading through the discussion, I found myself asking a different question. IPv6 adoption has been encouraged globally for more than two decades, yet many operators still make different deployment decisions depending on their business priorities. Given that reality, does introducing IPv6 as a criterion within IPv4 policy address the underlying issue? Or does it simply add another administrative requirement? The market has consistently shown that operators deploy technologies when they provide sufficient operational or commercial value for their particular environment. Would it therefore be more productive for policy to focus on creating governance conditions that improve confidence, rather than attempting to shape deployment decisions through policy ? For instance: - How can policies improve portability of Internet number resources? - Should operators have stronger exit rights if governance structures no longer meet their operational needs? - Should registry policies place greater emphasis on predictability, continuity and neutrality? - Could strengthening these governance principles encourage innovation more effectively than introducing additional policy conditions? These seem like questions that affect every operator, regardless of their current IPv6 deployment level. I'd be very interested to hear your view. Do you see portability and exit rights as governance principles worth incorporating into future policy discussions, or do you believe the current governance model already provides sufficient flexibility for operators? Thank you once again for contributing to this discussion. Best regards, Mphoentle Policy should strengthen rights before introducing new obligations. -------------- next part -------------- An HTML attachment was scrubbed... URL: From entlemokheseng at gmail.com Tue Jul 7 09:04:30 2026 From: entlemokheseng at gmail.com (entle mokheseng) Date: Tue, 7 Jul 2026 09:04:30 +0000 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01 Message-ID: Dear Jordi, Thank you for your detailed contribution and for sharing practical deployment experiences from different networks. Reading through the discussion, I found myself asking a different question. IPv6 adoption has been encouraged globally for more than two decades, yet many operators still make different deployment decisions depending on their business priorities. Given that reality, does introducing IPv6 as a criterion within IPv4 policy address the underlying issue? Or does it simply add another administrative requirement? The market has consistently shown that operators deploy technologies when they provide sufficient operational or commercial value for their particular environment. Would it therefore be more productive for policy to focus on creating governance conditions that improve confidence, rather than attempting to shape deployment decisions through it ? For instance: - How can policies improve portability of Internet number resources? - Should operators have stronger exit rights if governance structures no longer meet their operational needs? - Should registry policies place greater emphasis on predictability, continuity and neutrality? - Could strengthening these governance principles encourage innovation more effectively than introducing additional policy conditions? These seem like questions that affect every operator, regardless of their current IPv6 deployment level. I'd be very interested to hear your view. Do you see portability and exit rights as governance principles worth incorporating into future policy discussions, or do you believe the current governance model already provides sufficient flexibility for operators? Thank you once again for contributing to this discussion. Best regards, Mphoentle Policy should strengthen rights before introducing new obligations. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Tue Jul 7 12:18:22 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Tue, 7 Jul 2026 14:18:22 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01 Message-ID: Dear Jordi, Thank you for taking the time to elaborate on your position. I respectfully beg to differ, not on the value of openness, but on the assumption that openness alone is sufficient to guarantee legitimacy. You describe the community as "global humanity" and note that anyone can participate. In theory, I completely agree that the process is open. My concern is whether openness necessarily translates into representation. Political theory has long distinguished between formal participation and effective participation. A process may be open to everyone, yet still be shaped primarily by those with the time, institutional knowledge, and procedural familiarity to engage continuously. In practice, these are rarely the network operators spending their days deploying infrastructure, expanding connectivity, and managing commercial risk. This is not a criticism of the PDP itself. Rather, it is a recognition that governance systems naturally develop an asymmetry between those who operate institutions and those who operate networks. That distinction matters. The argument that "if you are unhappy, you should simply participate" assumes that legitimacy is created by the availability of participation. I would argue that legitimacy is strengthened when governance remains proportionate to its mandate and when those who bear the greatest operational and economic consequences are not required to become full-time governance participants simply to protect their interests. This brings me to portability. When I refer to portability, I am not referring to the portability of IP addresses themselves, but to the portability of governance relationships. A resilient governance system should never assume permanent institutional dependence. Just as the Internet itself was designed to eliminate single points of failure, governance should also avoid creating situations where operators are effectively locked into one institutional relationship with no meaningful alternatives. Portability therefore means that operators should be able to maintain continuity of their number resources while retaining meaningful freedom of institutional choice. The existence of credible alternatives creates healthy accountability. Institutions perform best when they continue to earn the confidence of those they serve, rather than assuming that confidence will always exist. Similarly, exit rights are not about abandoning coordination; they are about ensuring that coordination remains voluntary rather than becoming structurally unavoidable. In most governance systems, the ability to leave is an important discipline on the exercise of authority. Where meaningful exit becomes impossible, institutions inevitably accumulate greater discretionary power over time because there are fewer practical constraints on that power. This is why I remain cautious about proposals that make IPv6 deployment a criterion for IPv4 Soft Landing. Viewed in isolation, it may appear to be a technical policy adjustment. Viewed within the broader trajectory of Internet governance, however, it represents another step in expanding institutional influence beyond resource coordination and into operational decision-making. Perhaps the more fundamental question is not whether IPv6 deployment is beneficial?it clearly is in many contexts?but whether policy should encourage technological outcomes through administrative conditions, or whether its primary role should remain the neutral coordination of Internet number resources. The strength of the Internet has always been that it is decentralised, interoperable, and resilient. I believe our governance principles should aspire to those same characteristics. Kind regards, Fundiswa Nadia Maseko "Decentralisation is sustained not only by open participation, but by meaningful choice." -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Tue Jul 7 13:27:20 2026 From: mike at iptrading.com (Mike Burns) Date: Tue, 7 Jul 2026 09:27:20 -0400 Subject: [rpd] RPD Digest, Vol 222, Issue 8 In-Reply-To: References: Message-ID: <00dc01dd0e14$566a6150$033f23f0$@iptrading.com> Hi Jordi, ?As I said before, all the policies already have influence in how the networks are operated? Tell me how the RIPE transfer policy influences how the networks are operated. There is no justification, so how does it work? Historically, RIRs have avoided influencing network decisions. In ARIN, for example, you can justify the use of a public routed address on every single computer in an organization, no NAT expected or required. Even though nobody would do this today, the ARIN community did not think it advisable to favor one sort of network implementation over another, in recognition of the limits of the RIR role. Your proposal elevates one network configuration over another with clarity, and changes the RIR role forever with the same clarity. Now the RIRs are not just stewards of numbers and ensurers of uniqueness, not just protocol cheerleaders, but instead protocol police. If ?global humanity? wants IPv6, it has to happen organically. Top down forcing by a tiny elite is not the answer. I think the question about portability goes to the ability to move registration to a different RIR without undue limitation. I know there are members of this community who witnessed the last several years and wonder about their escape hatch. Regards, Mike From: jordi.palet--- via RPD Sent: Tuesday, July 07, 2026 4:26 AM To: rpd at afrinic.net Subject: Re: [rpd] RPD Digest, Vol 222, Issue 8 Hi Zenalo, I think it is clear that both is needed: technical assistance which is already being provided since many years (up to a certain point, because a RIR is not a business for training and consultancy and doing that my interfere even with competition laws, and of course, the RIR staff aren?t doing actual production deployments in such way they have all the required expertise) and community policies that protect and ensure a fair usage of the community resources. As I said before, all the policies already have influence in how the networks are operated, is difficult to draw a border line, but the community policies are to protect the community resources, not the ISP business. Otherwise, the policies will be made by the ISPs, instead of the community and the is not how we decided to do this in a global RIR ecosystem-scale. Regards, Jordi @jordipalet El 7 jul 2026, a las 9:58, Zenalo Mguqulwa > escribi?: Dear colleagues, Thank you for the thoughtful discussion. One question I have is whether this proposal changes how the Soft Landing Policy is implemented. The CPM already states that the purpose of Soft Landing is to support the transition to IPv6 while managing the remaining IPv4 pool. My question is whether requiring measurable IPv6 deployment as a condition for receiving IPv4 moves the policy beyond encouraging transition and into evaluating how operators implement their networks. If so, should this type of oversight form part of resource policy, or would it be more appropriate to encourage IPv6 adoption through technical assistance, best practices and community collaboration? I think clarifying this distinction may help the community evaluate the proposal. Kind regards, Zim On Tue, 7 Jul 2026 at 09:48, > wrote: Send RPD mailing list submissions to rpd at afrinic.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.afrinic.net/mailman/listinfo/rpd or, via email, send a message with subject or body 'help' to rpd-request at afrinic.net You can reach the person managing the list at rpd-owner at afrinic.net When replying, please edit your Subject line so it is more specific than "Re: Contents of RPD digest..." Today's Topics: 1. (no subject) (Zimkhitha Mguqulwa) 2. Re: IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01 (Fundiswa Nadia Maseko) 3. Re: IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01 (Nia Petronella) 4. Re: IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01 (jordi.palet at consulintel.es ) ---------------------------------------------------------------------- Message: 1 Date: Mon, 6 Jul 2026 18:15:53 +0200 From: Zimkhitha Mguqulwa > To: rpd at afrinic.net Subject: [rpd] (no subject) Message-ID: > Content-Type: text/plain; charset="utf-8" Dear PDWG, I hope everyone is doing well. I am new to the mailing list and am sending this message to confirm that my subscription and posting permissions are working correctly. I look forward to following and contributing to future discussions. Kind regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Tue, 7 Jul 2026 09:22:14 +0200 From: Fundiswa Nadia Maseko > To: rpd at afrinic.net Cc: rpd-owner at afrinic.net Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01 Message-ID: > Content-Type: text/plain; charset="utf-8" Dear colleagues, I would like to share another perspective on the proposal. >From my understanding, the primary role of the Regional Internet Registries has always been to coordinate Internet number resources through transparent, community-developed policies. Making IPv6 deployment a requirement for IPv4 Soft Landing appears to extend that role into evaluating how network operators design and manage their networks. This raises an important governance question: how would it be determined whether an operator has deployed "enough" IPv6? Would this be based on traffic percentages, addressing plans, or some other measure? Different operators also have different deployment models, which could make such assessments difficult and open to interpretation. In my view, Soft Landing policies should remain focused on the fair management of IPv4 resources rather than using IPv4 allocation to influence network architecture decisions. I fully support continued IPv6 adoption through technical assistance, training, operational collaboration, and knowledge sharing. However, making IPv6 deployment a compliance requirement for IPv4 policy may unintentionally expand the role of the registry beyond neutral resource coordination. As the Internet continues to evolve, I believe it is important to maintain a clear distinction between coordinating Internet number resources and influencing operational decisions. Kind regards, Fundiswa Nadia Maseko "Governance should follow operational reality." -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Tue, 7 Jul 2026 09:24:00 +0200 From: Nia Petronella > To: rpd at afrinic.net , rpd-owner at afrinic.net Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01 Message-ID: > Content-Type: text/plain; charset="utf-8" Dear Jordi and colleagues, Thank you for your detailed contribution. Your examples clearly demonstrate that, with the right planning, expertise and organisational commitment, IPv6 deployment can progress rapidly. Those operational experiences are undoubtedly valuable and should continue to be shared across the community. However, I find myself asking a broader policy question. What is the primary objective of an IPv4 Soft Landing policy? Is it to manage the fair and efficient allocation of remaining IPv4 resources, or is it to encourage the deployment of IPv6? While both are important, I believe they are distinct policy objectives and may require different policy instruments. If IPv6 deployment becomes a prerequisite for IPv4 eligibility, could that unintentionally shift the role of Soft Landing from resource management to influencing network strategy? One of the enduring strengths of the Internet has been that operators retain the flexibility to choose technologies based on their own operational realities, customer needs and commercial priorities. That flexibility has enabled innovation across networks with very different business models and levels of maturity. >From that perspective, I wonder whether this discussion presents an opportunity to consider broader governance reforms instead of additional deployment criteria. For example: - Should policies place greater emphasis on portability so that operators retain confidence in the continuity of their Internet number resources? - Should exit rights be recognised as an important governance safeguard, allowing operators meaningful alternatives if institutional confidence is weakened? - Should registry policy focus on reducing unnecessary administrative discretion while strengthening predictability and legal certainty? - As Internet number resources continue to grow in economic importance, should governance evolve to reinforce operator autonomy rather than introduce additional conditions tied to technology choices? Jordi, I would genuinely value your opinion on this. Do you see portability and exit rights as governance principles that deserve greater attention within the RIR policy framework, particularly as the Internet ecosystem becomes more decentralised and commercially diverse? It seems to me that governance reforms which strengthen neutrality, continuity and operator choice would benefit both IPv4 and IPv6 communities alike, regardless of where each operator is on its deployment journey. Kind regards, Nonhlanhla "Strong governance is built on portability, neutrality and choice." -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Tue, 7 Jul 2026 09:47:44 +0200 From: "jordi.palet at consulintel.es " > To: rpd at afrinic.net Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01 Message-ID: <7C848C2A-E257-4F56-BC64-7EC6961311EB at consulintel.es > Content-Type: text/plain; charset="utf-8" Hi Nia, The CPM is clear about the reason for the Soft Landing policy: "In order to ensure a smooth transition to IPv6, AFRINIC's pool should be managed to provide members with address space after the IPv4 pool is depleted. This will help in maintaining IPv4 networks while deploying IPv6 networks - a practice that characterizes the transition period." If we don?t ?attach" the soft landing IPv4 remaining resources to the IPv6 deployment, then there is no need for a soft landing policy. It will be much better to just follow pre-soft-landing policies and let the natural IPv4 exhaustion to progress. To correctly answer yous questions, I will like to understand what do you mean with ?portability?. Note that all the governments, sooner or later, will need to enforce the IPv6 deployment. There is no question about that. Regulation is not good if we can, as a technical community, self-regulate in advance with our own pace, specially considering that law makers, courts, etc., etc., have not the knowledge neither expertise, and in fact they have a very hard time trying to understand how Internet works, and consequently they can make severe mistakes with such regulations. There are many examples of that in many countries, such as when the Spanish, Italian and other courts decided that, to fight against football piracy is right to enforce filtering based on IPs, VPNs, etc., and this create millions of losses to absolutely legal and honest web sites, e-commerce, NGOs, etc. Regards, Jordi @jordipalet > El 7 jul 2026, a las 9:24, Nia Petronella > escribi?: > > Dear Jordi and colleagues, > > Thank you for your detailed contribution. Your examples clearly demonstrate that, with the right planning, expertise and organisational commitment, IPv6 deployment can progress rapidly. Those operational experiences are undoubtedly valuable and should continue to be shared across the community. > > However, I find myself asking a broader policy question. > > What is the primary objective of an IPv4 Soft Landing policy? > > Is it to manage the fair and efficient allocation of remaining IPv4 resources, or is it to encourage the deployment of IPv6? > > While both are important, I believe they are distinct policy objectives and may require different policy instruments. > > If IPv6 deployment becomes a prerequisite for IPv4 eligibility, could that unintentionally shift the role of Soft Landing from resource management to influencing network strategy? > > One of the enduring strengths of the Internet has been that operators retain the flexibility to choose technologies based on their own operational realities, customer needs and commercial priorities. That flexibility has enabled innovation across networks with very different business models and levels of maturity. > > From that perspective, I wonder whether this discussion presents an opportunity to consider broader governance reforms instead of additional deployment criteria. > > For example: > > - Should policies place greater emphasis on portability so that operators retain confidence in the continuity of their Internet number resources? > - Should exit rights be recognised as an important governance safeguard, allowing operators meaningful alternatives if institutional confidence is weakened? > - Should registry policy focus on reducing unnecessary administrative discretion while strengthening predictability and legal certainty? > - As Internet number resources continue to grow in economic importance, should governance evolve to reinforce operator autonomy rather than introduce additional conditions tied to technology choices? > > Jordi, I would genuinely value your opinion on this. > > Do you see portability and exit rights as governance principles that deserve greater attention within the RIR policy framework, particularly as the Internet ecosystem becomes more decentralised and commercially diverse? > > It seems to me that governance reforms which strengthen neutrality, continuity and operator choice would benefit both IPv4 and IPv6 communities alike, regardless of where each operator is on its deployment journey. > > > Kind regards, > > Nonhlanhla > > "Strong governance is built on portability, neutrality and choice." > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ End of RPD Digest, Vol 222, Issue 8 *********************************** _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From NGBSIM008 at myuct.ac.za Tue Jul 7 13:33:38 2026 From: NGBSIM008 at myuct.ac.za (Simphiwe Ngubane) Date: Tue, 7 Jul 2026 13:33:38 +0000 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01 Message-ID: Dear Jordi and colleagues, Thank you for continuing to share practical deployment experience. One observation I would like to make is that much of this discussion measures success through IPv6 adoption percentages. While those metrics are certainly useful operationally, I wonder whether they are the right indicators for policy. Should the success of Internet number resource governance instead be measured by questions such as: * Can operators retain confidence in registry neutrality? * Can resources remain portable when circumstances change? * Do operators have meaningful exit options? * Are transfer processes predictable and transparent? * Does policy minimise unnecessary administrative discretion? If these governance foundations are strong, operators remain free to adopt IPv6 wherever it provides value. If those foundations are weak, adding IPv6 criteria may simply increase institutional dependence rather than improving Internet resilience. Jordi, would you support a broader discussion on governance reforms that strengthen portability, operator autonomy and exit rights alongside any discussion of IPv6? To me, those principles appear complementary to a healthy and competitive Internet. Thank you for considering another perspective. Best regards, Simphiwe Ngubane "IPv4 is an important service enabler." [cid:9a927a36-99f1-4767-8d8a-61a5ac7949f8] Simphiwe Ngubane MSc (Eng) specialising in Geomatics candidate: Faculty of Engineering & the Built Environment Menzies Building, Level 5 Upper Campus University of Cape Town | Rondebosch|7701 Phone: 0810479025 Email: ngbsim008 at myuct.ac.za ? Disclaimer - University of Cape Town This email is subject to UCT policies and email disclaimer published on our website at https://www.uct.ac.za/main/email-disclaimer or obtainable from +27 21 650 9111. If this email is not related to the business of UCT, it is sent by the sender in an individual capacity. Please report security incidents or abuse via https://csirt.uct.ac.za/report-incident -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/gif Size: 6098 bytes Desc: image.png URL: From nonhlanhlapetronella85 at gmail.com Tue Jul 7 17:18:02 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Tue, 7 Jul 2026 19:18:02 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01 Message-ID: Dear Jordi, I think the discussion is beginning to reveal a more fundamental question than the mechanics of IPv6 deployment. You note that if IPv6 deployment is not attached to the remaining IPv4 pool, then the rationale for Soft Landing becomes weaker. I understand the historical intent of the policy. However, I wonder whether the policy should continue to be evaluated against the assumptions that existed when it was first developed, or against the realities of today's Internet. The Internet has changed considerably. IPv4 is no longer simply a technical resource awaiting replacement; it has become an economically significant infrastructure asset that continues to underpin large parts of the global Internet. At the same time, IPv6 has grown substantially, yet the Internet remains overwhelmingly dual-stack rather than transitional. Against that backdrop, I question whether it is appropriate for IPv4 policy to become a vehicle for encouraging IPv6 deployment, or whether its primary objective should instead be the neutral and predictable management of scarce IPv4 resources. You also asked what I mean by portability. By portability, I mean the ability of operators to retain continuity and certainty over their Internet number resources without being indefinitely tied to a particular governance arrangement or institutional interpretation. Good governance should create confidence because institutions continue to earn the trust of their members, not because members have no practical alternative. >From a political and institutional perspective, resilient systems are rarely those that depend on a single centre of authority. Rather, they are those in which authority is constrained by accountability, transparency and meaningful choice. The Internet itself was built on principles of decentralisation and resilience. It seems reasonable to ask whether those same principles should increasingly inform how Internet number resources are governed. I also found your point about government regulation interesting. I agree that poorly designed regulation can produce unintended consequences, and there are many examples where policymakers have struggled to appreciate the technical realities of Internet operations. However, I am not convinced that the alternative is for technical institutions to continually expand their own policy remit. Avoiding state overreach should not inadvertently justify institutional overreach elsewhere. Good governance is not simply about who exercises authority; it is also about ensuring that authority remains proportionate to its mandate. This is why I continue to distinguish between coordinating Internet number resources and influencing technology adoption. Encouraging IPv6 through technical collaboration, operational support and shared experience is entirely consistent with the role of the technical community. Making IPv6 deployment a condition within IPv4 policy, however, raises broader governance questions about institutional neutrality and the appropriate boundaries of policy. Perhaps the question before us is not whether IPv6 is important?it clearly is?but whether Internet number resource policy should primarily shape technological outcomes or preserve a governance framework that allows operators to make those decisions according to their own operational and commercial realities. I believe that distinction is worth careful consideration. Kind regards, Nonhlanhla "Strong governance is measured not only by technical outcomes, but by the restraint, neutrality and accountability of the institutions that exercise authority." -------------- next part -------------- An HTML attachment was scrubbed... URL: From comms at afrinic.net Tue Jul 7 17:58:26 2026 From: comms at afrinic.net (AFRINIC Communication) Date: Tue, 7 Jul 2026 21:58:26 +0400 Subject: [rpd] Update on the Restoration of the AFRINIC Website Message-ID: <1448F7F8-364B-48DD-963A-035ACDAC324C@afrinic.net> [Version en fran?ais au bas] Dear colleagues, We would like to thank you for your patience and continued support following our communication of 5th July 2026 regarding the temporary unavailability of the AFRINIC website (www.afrinic.net). Our technical team has been working around the clock to ensure that the website is restored in a secure, stable, and resilient manner. We would like to reassure you that AFRINIC's core Internet number resource management services remain fully operational. The Resource Management, Member Support, Registry operations, and other essential services continue to be delivered without interruption, and our team remains available to assist members through our established support channels. As part of the restoration process, we expect to make the AFRINIC website publicly accessible again by COB 8th July 2026 through a secure static version of the site. This initial version will provide information most frequently accessed by members, stakeholders, and the wider Internet community. At the same time, work continues to restore the full website. This measured approach helps ensure that when the complete website is restored, it will provide a stronger and more resilient platform for the AFRINIC community. We will continue to keep all stakeholders informed as restoration activities progress and will share further updates through our official communication channels. We sincerely appreciate your understanding, patience, and the many messages of support we have received from across our community. Your confidence and cooperation are invaluable as we work to complete this process. Should you have any questions or require assistance, please do not hesitate to contact us at: contact at afrinic.net. Kind Regards, AFRINIC Communications ???????????????????????? Information concernant la restauration du site web d?AFRINIC Nous vous remercions sinc?rement pour votre patience et votre soutien continu ? la suite de notre communication du 5 juillet 2026 concernant l?indisponibilit? temporaire du site web d?AFRINIC ((www.afrinic.net). Notre ?quipe technique poursuit ses efforts afin de r?tablir le site web dans des conditions garantissant un niveau ?lev? de s?curit?, de stabilit? et de r?silience. Nous tenons ? vous rassurer que les services essentiels d?AFRINIC, notamment la gestion des ressources num?riques Internet ainsi que l?ensemble de nos op?rations de registre, continuent de fonctionner normalement. Nos ?quipes restent ?galement ? votre disposition via nos canaux d?assistance habituels. Dans le cadre du processus de restauration, nous pr?voyons de rendre le site web d?AFRINIC de nouveau accessible au public d?ici le 8 juillet 2026, gr?ce ? une premi?re version statique et s?curis?e. Cette version permettra aux membres et ? la communaut? d?acc?der aux informations les plus fr?quemment consult?es. En parall?le, les travaux se poursuivent afin de restaurer l?ensemble des fonctionnalit?s du site web. Cette approche progressive nous permettra de garantir qu?une fois pleinement r?tabli, le site offrira ? la communaut? AFRINIC une plateforme plus robuste, plus s?curis?e et plus r?siliente. Nous continuerons ? informer r?guli?rement l?ensemble des parties prenantes de l?avancement des travaux de restauration et partagerons toute nouvelle information par le biais de nos canaux de communication officiels. Nous vous remercions une nouvelle fois pour votre compr?hension, votre patience et les nombreux messages de soutien que nous avons re?us de la part de notre communaut?. Votre confiance et votre coop?ration nous sont pr?cieuses alors que nous poursuivons ce processus de restauration. Pour toute question ou demande d?assistance, n?h?sitez pas ? nous contacter ? l?adresse suivante : contact at afrinic.net. Cordialement, AFRINIC Communications From hytham at tra.gov.eg Tue Jul 7 21:23:40 2026 From: hytham at tra.gov.eg (Hytham El-Nakhal) Date: Tue, 7 Jul 2026 21:23:40 +0000 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 Message-ID: <1783459420709.11832@tra.gov.eg> Dear PDWG, I have noticed some mails from community members regarding the policy proposal "IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01". The author has updated the proposal (DRAFT02), and it was discussed during the AFRINIC-37 PPM on 24th June 2026. The updated proposal is attached to this email to bring you up to speed with its contents [pending the re-establishment of the AFRINIC website by COB 8th July as communicated by AFRINIC]. The updated proposal did not reach consensus at the AFRINIC-37 PPM and was sent back to the RPD mailing-list for further discussions. Those who missed the discussions still have access the AF-37 PPM proceedings here: https://www.youtube.com/watch?v=uwjG1_XwKV8 . Therefore, it is highly recommended that participants thoroughly review the attached proposal, familiarize themselves with prior discussions on the mailing list and during the Public Policy Meeting, and subsequently focus their valuable contribution by undertaking any of the following actions: * - Seek clarifications regarding the policy text and offer recommendations for its improvement; * - Express formal support for the proposal; or, * - Provide a detailed justification in case of opposition to the policy as drafted. Best Regards, Haitham el Nakhal PDWG Co-Chair -------------- next part -------------- A non-text attachment was scrubbed... Name: IPv6 as a criteria in IPv4 Soft Landing - AFPUB-2026-v6-001-DRAFT02-070726-175333.pdf Type: application/pdf Size: 207547 bytes Desc: IPv6 as a criteria in IPv4 Soft Landing - AFPUB-2026-v6-001-DRAFT02-070726-175333.pdf URL: From nonhlanhlapetronella85 at gmail.com Tue Jul 7 21:39:15 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Tue, 7 Jul 2026 23:39:15 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 Message-ID: Dear Haitham, Thank you for the clarification and for circulating the updated draft proposal. I agree that the primary focus of this discussion should remain the policy proposal itself and whether DRAFT02 adequately addresses the objectives of the IPv4 Soft Landing policy. At the same time, I believe this does not preclude broader policy considerations that are directly relevant to evaluating the proposal. The proposal explicitly links IPv6 deployment with continued access to IPv4 resources. As a result, perspectives on the economic, operational, and strategic role of IPv4?including whether IPv4 should be regarded as a long-term capital asset rather than merely a legacy resource?are not peripheral to the discussion. They are central to assessing whether the proposed criteria are proportionate, justified, and aligned with sound resource governance. Where community members continue to raise these issues, they are contributing to the broader policy context that informs the proposal's merits. Such contributions do not depart from the mandate of the discussion; rather, they help ensure that policy decisions are evaluated against both current operational realities and their longer-term governance implications. A robust policy development process benefits from examining not only the wording of a proposal but also the assumptions on which it is based. Keeping the discussion open to relevant policy perspectives ultimately strengthens the quality and legitimacy of the consensus-building process. Kind regards, Nonhlanhla -------------- next part -------------- An HTML attachment was scrubbed... URL: From tshepomasuku16 at gmail.com Wed Jul 8 00:15:38 2026 From: tshepomasuku16 at gmail.com (Tshepo Masuku) Date: Wed, 8 Jul 2026 02:15:38 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01 Message-ID: Dear all, Jordi's deployment examples clearly show that IPv6 can achieve impressive levels of traffic once implementation reaches scale. However, those same examples also illustrate another reality. Even networks with very high IPv6 utilisation continue operating dual-stack environments because IPv4 remains an essential part of today's Internet. That raises an important question for this policy discussion. If dual-stack remains the practical operational model for the foreseeable future, should IPv6 deployment become a prerequisite for receiving IPv4 resources? In my view, IPv4 Soft Landing should primarily address how scarce IPv4 resources are managed fairly and transparently. IPv6 adoption is certainly beneficial where it improves operational efficiency, but making it a policy criterion assumes there is a universal deployment pathway that every operator can reasonably follow. Operational realities differ significantly across networks, markets and regions. Successful Internet governance has traditionally allowed those differences while maintaining neutral coordination of shared resources. Perhaps we should continue encouraging IPv6 through collaboration, technical support and community knowledge sharing, while ensuring IPv4 policy remains focused on managing IPv4 itself. Keeping those objectives separate may ultimately produce stronger outcomes for both protocols. Kind regards, Tshepo "IPv6 is not designed for scarcity." -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Wed Jul 8 00:38:29 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Wed, 8 Jul 2026 03:38:29 +0300 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 In-Reply-To: <1783459420709.11832@tra.gov.eg> References: <1783459420709.11832@tra.gov.eg> Message-ID: <0A1B8E6A-A26D-45D0-91A7-FE9E34A802CF@afrinic.net> It seems to me that the proposal serves mostly to complicate what is an already complex process. ? The IPv6 deployment plan must show the actual IPv4 top-25 traffic destinations of that network. For each of those external destinations that are IPv6-enabled, the following minimum IPv6 % will be considered? Like a new startup ISP in rural Africa even has traffic analysis tools to measure their IPV4 top 25 destinations? The policy is looking like another barrier to Building Africas Digital Future. Therefore I can?t support it. Sent from my iPhone > On 8 Jul 2026, at 00:25, Hytham El-Nakhal wrote: > > ?Dear PDWG, > > > I have noticed some mails from community members regarding the policy proposal "IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01". > > > The author has updated the proposal (DRAFT02), and it was discussed during the AFRINIC-37 PPM on 24th June 2026. > > > The updated proposal is attached to this email to bring you up to speed with its contents [pending the re-establishment of the AFRINIC website by COB 8th July as communicated by AFRINIC]. > > The updated proposal did not reach consensus at the AFRINIC-37 PPM and was sent back to the RPD mailing-list for further discussions. > > > Those who missed the discussions still have access the AF-37 PPM proceedings here: https://www.youtube.com/watch?v=uwjG1_XwKV8 . > > > Therefore, it is highly recommended that participants thoroughly review the attached proposal, familiarize themselves with prior discussions on the mailing list and during the Public Policy Meeting, and subsequently focus their valuable contribution by undertaking any of the following actions: > > * - Seek clarifications regarding the policy text and offer recommendations for its improvement; > * - Express formal support for the proposal; or, > * - Provide a detailed justification in case of opposition to the policy as drafted. > > > Best Regards, > Haitham el Nakhal > PDWG Co-Chair > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Wed Jul 8 07:01:51 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Wed, 8 Jul 2026 09:01:51 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> References: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> Message-ID: Hi All, I'm looping back to this original email, not because I want to answer here directly, but rather because I think it's appropriate to consider the "bigger picture" of responses. First and foremost, I've seen quite strong opinions from newly registered @gmail.com addresses.? I'd like to understand the affiliation of these participants. In my opinion there are a number of conflicting and not quite obvious agendas in this, for this, and against this, policy proposal - all of them with various commercial impacts for various entities.? Almost none of them to the benefit of the "end consumer". I personally believe the best thing is to retain the current status quo *as it stands*, as this leaves operational decisions to the various network operators rather than enforcing operational issues by way of policy. That said, I *personally* do not believe IPv4 should have a future of any kind.? Here I'm in agreement with Jordi that networks should be deploying as IPv6-first. The *reality* however is that the world is predominantly IPv4 - "everyone" is connected using IPv4, and I don't (at least not in Africa) see that this is going to change any time soon.? We've been debating the reasons for this in the office the last week or two, and I'm not going to bore you with the details, but our opinion is that this is not because networks and techies don't want to switch but because customers (yes, you read that right) demands that we don't.? When you deploy DNS for a customer - just dare try and ask for AAAA details when only provided with A details and see the response you get.? Usually from people that should *know better*. When people run speedtest (which I understand measures only L7 throughput) and they get a lower value on IPv6 than on IPv4 ... what's the next thing that happens?? User logs into router, find the "disable IPv6" button (or equivalent) *click*. Okay, so follow the (apparent) European standard of users may not have access to their routers where they're forced to have IPv6 on and can do nothing about it ... had a discussion the other day with someone in Europe about this, "I get better throughput by putting my own router behind that of my ISP and running IPv4 only on my own network" - where there's v6 only ... well, I've yet to hear/see about that end-network.? Some core networks sure I've heard of that. As much as I hate to say this:? IPv4 is going to be with us for a while.? And we should encourage deployment of IPv6, but I don't think we can enforce that by way of policy as this is interfering with network operational decisions/designs.? I also strongly disagree with apparent stances I've observed hinting that we should make the soft landing more lax as that just drives up costs for everyone much sooner and faster, and in a world where everyone I communicate with are already complaining about the cost of stuff I don't think that's fair either. Kind regards, Jaco On 2026/05/28 10:05, Darwin Da Costa wrote: > > Dear PDWG, > > > We have received a new draft policy proposal - IPv6 as a criteria in > IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet > Martinez. The proposal contents are published at: > > > https://afrinic.net/afpub-2026-v6-001-draft01 > > > > We encourage you to take some time to go through the proposal contents > and ?provide feedback as follows: > > > a)Do you support or oppose the proposal? > > > b) If you oppose the proposal, state your reasons? > > > c) Is there anything in the proposal that is not clear? > > > d) What changes could be made to this proposal to make it more effective? > > > > Regards, > > Vincent Ngundi & Darwin Da Costa > > AFRINIC PDWG Co-Chairs > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From mguqulwazenalo at gmail.com Wed Jul 8 07:42:35 2026 From: mguqulwazenalo at gmail.com (Zenalo Mguqulwa) Date: Wed, 8 Jul 2026 09:42:35 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 13 In-Reply-To: References: Message-ID: Good day all, I agree with Mike. The discussion is no longer about IPv6 itself but about the scope of the RIR's mandate. Resource allocation and protocol choice should remain separate. The registry should coordinate Internet number resources, while operators retain responsibility for network architecture and deployment decisions. Regards On Tue, 7 Jul 2026 at 15:29, wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01 (Fundiswa Nadia Maseko) > 2. Re: RPD Digest, Vol 222, Issue 8 (Mike Burns) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 7 Jul 2026 14:18:22 +0200 > From: Fundiswa Nadia Maseko > To: rpd at afrinic.net > Cc: rpd-owner at afrinic.net > Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01 > Message-ID: > < > CABV0QcS0qzkeyTBQDSY2ZCyHoRoWA-OjekuZ+Bx0Jr8R_RAXGg at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Jordi, > > Thank you for taking the time to elaborate on your position. > > I respectfully beg to differ, not on the value of openness, but on the > assumption that openness alone is sufficient to guarantee legitimacy. > > You describe the community as "global humanity" and note that anyone can > participate. In theory, I completely agree that the process is open. My > concern is whether openness necessarily translates into representation. > > Political theory has long distinguished between formal participation and > effective participation. A process may be open to everyone, yet still be > shaped primarily by those with the time, institutional knowledge, and > procedural familiarity to engage continuously. In practice, these are > rarely the network operators spending their days deploying infrastructure, > expanding connectivity, and managing commercial risk. > > This is not a criticism of the PDP itself. Rather, it is a recognition that > governance systems naturally develop an asymmetry between those who operate > institutions and those who operate networks. > > That distinction matters. > > The argument that "if you are unhappy, you should simply participate" > assumes that legitimacy is created by the availability of participation. I > would argue that legitimacy is strengthened when governance remains > proportionate to its mandate and when those who bear the greatest > operational and economic consequences are not required to become full-time > governance participants simply to protect their interests. > > This brings me to portability. > > When I refer to portability, I am not referring to the portability of IP > addresses themselves, but to the portability of governance relationships. > > A resilient governance system should never assume permanent institutional > dependence. Just as the Internet itself was designed to eliminate single > points of failure, governance should also avoid creating situations where > operators are effectively locked into one institutional relationship with > no meaningful alternatives. > > Portability therefore means that operators should be able to maintain > continuity of their number resources while retaining meaningful freedom of > institutional choice. The existence of credible alternatives creates > healthy accountability. Institutions perform best when they continue to > earn the confidence of those they serve, rather than assuming that > confidence will always exist. > > Similarly, exit rights are not about abandoning coordination; they are > about ensuring that coordination remains voluntary rather than becoming > structurally unavoidable. In most governance systems, the ability to leave > is an important discipline on the exercise of authority. Where meaningful > exit becomes impossible, institutions inevitably accumulate greater > discretionary power over time because there are fewer practical constraints > on that power. > > This is why I remain cautious about proposals that make IPv6 deployment a > criterion for IPv4 Soft Landing. > > Viewed in isolation, it may appear to be a technical policy adjustment. > Viewed within the broader trajectory of Internet governance, however, it > represents another step in expanding institutional influence beyond > resource coordination and into operational decision-making. > > Perhaps the more fundamental question is not whether IPv6 deployment is > beneficial?it clearly is in many contexts?but whether policy should > encourage technological outcomes through administrative conditions, or > whether its primary role should remain the neutral coordination of Internet > number resources. > > The strength of the Internet has always been that it is decentralised, > interoperable, and resilient. I believe our governance principles should > aspire to those same characteristics. > > Kind regards, > > Fundiswa Nadia Maseko > > "Decentralisation is sustained not only by open participation, but by > meaningful choice." > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260707/d72bdb66/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Tue, 7 Jul 2026 09:27:20 -0400 > From: "Mike Burns" > To: , > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 8 > Message-ID: <00dc01dd0e14$566a6150$033f23f0$@iptrading.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi Jordi, > > > > ?As I said before, all the policies already have influence in how the > networks are operated? > > > > Tell me how the RIPE transfer policy influences how the networks are > operated. > > There is no justification, so how does it work? > > > > Historically, RIRs have avoided influencing network decisions. In ARIN, for > example, you can justify the use of a public routed address on every single > computer in an organization, no NAT expected or required. Even though > nobody > would do this today, the ARIN community did not think it advisable to favor > one sort of network implementation over another, in recognition of the > limits of the RIR role. > > > > Your proposal elevates one network configuration over another with clarity, > and changes the RIR role forever with the same clarity. > > Now the RIRs are not just stewards of numbers and ensurers of uniqueness, > not just protocol cheerleaders, but instead protocol police. > > > > If ?global humanity? wants IPv6, it has to happen organically. Top down > forcing by a tiny elite is not the answer. > > > > I think the question about portability goes to the ability to move > registration to a different RIR without undue limitation. I know there are > members of this community who witnessed the last several years and wonder > about their escape hatch. > > > > Regards, > Mike > > > > > > From: jordi.palet--- via RPD > Sent: Tuesday, July 07, 2026 4:26 AM > To: rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 8 > > > > Hi Zenalo, > > > > I think it is clear that both is needed: technical assistance which is > already being provided since many years (up to a certain point, because a > RIR is not a business for training and consultancy and doing that my > interfere even with competition laws, and of course, the RIR staff aren?t > doing actual production deployments in such way they have all the required > expertise) and community policies that protect and ensure a fair usage of > the community resources. > > > > As I said before, all the policies already have influence in how the > networks are operated, is difficult to draw a border line, but the > community > policies are to protect the community resources, not the ISP business. > Otherwise, the policies will be made by the ISPs, instead of the community > and the is not how we decided to do this in a global RIR ecosystem-scale. > > > > Regards, > Jordi > > @jordipalet > > > > > > El 7 jul 2026, a las 9:58, Zenalo Mguqulwa > escribi?: > > > > Dear colleagues, > > Thank you for the thoughtful discussion. > > One question I have is whether this proposal changes how the Soft Landing > Policy is implemented. > > The CPM already states that the purpose of Soft Landing is to support the > transition to IPv6 while managing the remaining IPv4 pool. My question is > whether requiring measurable IPv6 deployment as a condition for receiving > IPv4 moves the policy beyond encouraging transition and into evaluating how > operators implement their networks. > > If so, should this type of oversight form part of resource policy, or would > it be more appropriate to encourage IPv6 adoption through technical > assistance, best practices and community collaboration? > > I think clarifying this distinction may help the community evaluate the > proposal. > > Kind regards, > Zim > > > > On Tue, 7 Jul 2026 at 09:48, > wrote: > > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. (no subject) (Zimkhitha Mguqulwa) > 2. Re: IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01 (Fundiswa Nadia Maseko) > 3. Re: IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01 (Nia Petronella) > 4. Re: IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01 (jordi.palet at consulintel.es > ) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 6 Jul 2026 18:15:53 +0200 > From: Zimkhitha Mguqulwa > > To: rpd at afrinic.net > Subject: [rpd] (no subject) > Message-ID: > < > CAJ7uu8nEuc_j5kkKV8EhX_VhkgZTNk1uPTRUFOot35bcvudJJQ at mail.gmail.com > > > > > Content-Type: text/plain; charset="utf-8" > > Dear PDWG, > > I hope everyone is doing well. > > I am new to the mailing list and am sending this message to confirm that my > subscription and posting permissions are working correctly. I look forward > to following and contributing to future discussions. > > Kind regards, > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > < > https://lists.afrinic.net/pipermail/rpd/attachments/20260706/2ee1356b/attac > hment-0001.html > > > > > ------------------------------ > > Message: 2 > Date: Tue, 7 Jul 2026 09:22:14 +0200 > From: Fundiswa Nadia Maseko > > To: rpd at afrinic.net > Cc: rpd-owner at afrinic.net > Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01 > Message-ID: > LcfHORdx6R94zjqpnOq-8eYA at mail.gmail.com > > > Content-Type: text/plain; charset="utf-8" > > Dear colleagues, > > I would like to share another perspective on the proposal. > > >From my understanding, the primary role of the Regional Internet > Registries > has always been to coordinate Internet number resources through > transparent, community-developed policies. > > Making IPv6 deployment a requirement for IPv4 Soft Landing appears to > extend that role into evaluating how network operators design and manage > their networks. > > This raises an important governance question: how would it be determined > whether an operator has deployed "enough" IPv6? Would this be based on > traffic percentages, addressing plans, or some other measure? Different > operators also have different deployment models, which could make such > assessments difficult and open to interpretation. > > In my view, Soft Landing policies should remain focused on the fair > management of IPv4 resources rather than using IPv4 allocation to influence > network architecture decisions. > > I fully support continued IPv6 adoption through technical assistance, > training, operational collaboration, and knowledge sharing. However, making > IPv6 deployment a compliance requirement for IPv4 policy may > unintentionally expand the role of the registry beyond neutral resource > coordination. > > As the Internet continues to evolve, I believe it is important to maintain > a clear distinction between coordinating Internet number resources and > influencing operational decisions. > > Kind regards, > > Fundiswa Nadia Maseko > > "Governance should follow operational reality." > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > < > https://lists.afrinic.net/pipermail/rpd/attachments/20260707/40ad19d8/attac > hment-0001.html > > > > > ------------------------------ > > Message: 3 > Date: Tue, 7 Jul 2026 09:24:00 +0200 > From: Nia Petronella > > To: rpd at afrinic.net , rpd-owner at afrinic.net > > Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01 > Message-ID: > < > CA+mDOg3EfQ998gJq2KSHnsWeNRa3H72ZbX9eKQXvRRujU9Xebw at mail.gmail.com > CA%2BmDOg3EfQ998gJq2KSHnsWeNRa3H72ZbX9eKQXvRRujU9Xebw at mail.gmail.com > > > > Content-Type: text/plain; charset="utf-8" > > Dear Jordi and colleagues, > > Thank you for your detailed contribution. Your examples clearly demonstrate > that, with the right planning, expertise and organisational commitment, > IPv6 deployment can progress rapidly. Those operational experiences are > undoubtedly valuable and should continue to be shared across the community. > > However, I find myself asking a broader policy question. > > What is the primary objective of an IPv4 Soft Landing policy? > > Is it to manage the fair and efficient allocation of remaining IPv4 > resources, or is it to encourage the deployment of IPv6? > > While both are important, I believe they are distinct policy objectives and > may require different policy instruments. > > If IPv6 deployment becomes a prerequisite for IPv4 eligibility, could that > unintentionally shift the role of Soft Landing from resource management to > influencing network strategy? > > One of the enduring strengths of the Internet has been that operators > retain the flexibility to choose technologies based on their own > operational realities, customer needs and commercial priorities. That > flexibility has enabled innovation across networks with very different > business models and levels of maturity. > > >From that perspective, I wonder whether this discussion presents an > opportunity to consider broader governance reforms instead of additional > deployment criteria. > > For example: > > - Should policies place greater emphasis on portability so that operators > retain confidence in the continuity of their Internet number resources? > - Should exit rights be recognised as an important governance safeguard, > allowing operators meaningful alternatives if institutional confidence is > weakened? > - Should registry policy focus on reducing unnecessary administrative > discretion while strengthening predictability and legal certainty? > - As Internet number resources continue to grow in economic importance, > should governance evolve to reinforce operator autonomy rather than > introduce additional conditions tied to technology choices? > > Jordi, I would genuinely value your opinion on this. > > Do you see portability and exit rights as governance principles that > deserve greater attention within the RIR policy framework, particularly as > the Internet ecosystem becomes more decentralised and commercially diverse? > > It seems to me that governance reforms which strengthen neutrality, > continuity and operator choice would benefit both IPv4 and IPv6 communities > alike, regardless of where each operator is on its deployment journey. > > > Kind regards, > > Nonhlanhla > > "Strong governance is built on portability, neutrality and choice." > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > < > https://lists.afrinic.net/pipermail/rpd/attachments/20260707/d72ae894/attac > hment-0001.html > > > > > ------------------------------ > > Message: 4 > Date: Tue, 7 Jul 2026 09:47:44 +0200 > From: "jordi.palet at consulintel.es " > > > To: rpd at afrinic.net > Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01 > Message-ID: <7C848C2A-E257-4F56-BC64-7EC6961311EB at consulintel.es > > > Content-Type: text/plain; charset="utf-8" > > Hi Nia, > > The CPM is clear about the reason for the Soft Landing policy: > > "In order to ensure a smooth transition to IPv6, AFRINIC's pool should be > managed to provide members with address space after the IPv4 pool is > depleted. This will help in maintaining IPv4 networks while deploying IPv6 > networks - a practice that characterizes the transition period." > > If we don?t ?attach" the soft landing IPv4 remaining resources to the IPv6 > deployment, then there is no need for a soft landing policy. It will be > much > better to just follow pre-soft-landing policies and let the natural IPv4 > exhaustion to progress. > > To correctly answer yous questions, I will like to understand what do you > mean with ?portability?. > > Note that all the governments, sooner or later, will need to enforce the > IPv6 deployment. There is no question about that. Regulation is not good if > we can, as a technical community, self-regulate in advance with our own > pace, specially considering that law makers, courts, etc., etc., have not > the knowledge neither expertise, and in fact they have a very hard time > trying to understand how Internet works, and consequently they can make > severe mistakes with such regulations. There are many examples of that in > many countries, such as when the Spanish, Italian and other courts decided > that, to fight against football piracy is right to enforce filtering based > on IPs, VPNs, etc., and this create millions of losses to absolutely legal > and honest web sites, e-commerce, NGOs, etc. > > Regards, > Jordi > > @jordipalet > > > El 7 jul 2026, a las 9:24, Nia Petronella > > > > escribi?: > > > > Dear Jordi and colleagues, > > > > Thank you for your detailed contribution. Your examples clearly > demonstrate that, with the right planning, expertise and organisational > commitment, IPv6 deployment can progress rapidly. Those operational > experiences are undoubtedly valuable and should continue to be shared > across > the community. > > > > However, I find myself asking a broader policy question. > > > > What is the primary objective of an IPv4 Soft Landing policy? > > > > Is it to manage the fair and efficient allocation of remaining IPv4 > resources, or is it to encourage the deployment of IPv6? > > > > While both are important, I believe they are distinct policy objectives > and may require different policy instruments. > > > > If IPv6 deployment becomes a prerequisite for IPv4 eligibility, could > that > unintentionally shift the role of Soft Landing from resource management to > influencing network strategy? > > > > One of the enduring strengths of the Internet has been that operators > retain the flexibility to choose technologies based on their own > operational > realities, customer needs and commercial priorities. That flexibility has > enabled innovation across networks with very different business models and > levels of maturity. > > > > From that perspective, I wonder whether this discussion presents an > opportunity to consider broader governance reforms instead of additional > deployment criteria. > > > > For example: > > > > - Should policies place greater emphasis on portability so that operators > retain confidence in the continuity of their Internet number resources? > > - Should exit rights be recognised as an important governance safeguard, > allowing operators meaningful alternatives if institutional confidence is > weakened? > > - Should registry policy focus on reducing unnecessary administrative > discretion while strengthening predictability and legal certainty? > > - As Internet number resources continue to grow in economic importance, > should governance evolve to reinforce operator autonomy rather than > introduce additional conditions tied to technology choices? > > > > Jordi, I would genuinely value your opinion on this. > > > > Do you see portability and exit rights as governance principles that > deserve greater attention within the RIR policy framework, particularly as > the Internet ecosystem becomes more decentralised and commercially diverse? > > > > It seems to me that governance reforms which strengthen neutrality, > continuity and operator choice would benefit both IPv4 and IPv6 communities > alike, regardless of where each operator is on its deployment journey. > > > > > > Kind regards, > > > > Nonhlanhla > > > > "Strong governance is built on portability, neutrality and choice." > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the > individual(s) named above and further non-explicilty authorized disclosure, > copying, distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited and will be > considered a criminal offense. If you are not the intended recipient be > aware that any disclosure, copying, distribution or use of the contents of > this information, even if partially, including attached files, is strictly > prohibited, will be considered a criminal offense, so you must reply to the > original sender to inform about this communication and delete it. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > < > https://lists.afrinic.net/pipermail/rpd/attachments/20260707/7805f63f/attac > hment.html > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 8 > *********************************** > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the > individual(s) named above and further non-explicilty authorized disclosure, > copying, distribution or use of the contents of this information, even if > partially, including attached files, is strictly prohibited and will be > considered a criminal offense. If you are not the intended recipient be > aware that any disclosure, copying, distribution or use of the contents of > this information, even if partially, including attached files, is strictly > prohibited, will be considered a criminal offense, so you must reply to the > original sender to inform about this communication and delete it. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260707/93960920/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 13 > ************************************ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at posix.co.za Wed Jul 8 08:29:09 2026 From: mark at posix.co.za (Mark Elkins) Date: Wed, 8 Jul 2026 10:29:09 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> Message-ID: <3303462e-bb8c-42c3-a545-dcaa8f5f87ac@posix.co.za> So IPv6 is slower??? From my home in Pretoria, where I have a 100Mbps FTTH connection via Telkom/Axxess - I can easily test ping times to a server I have at Teraco in Johannesburg. Running ping side-by-side, I see:- ? ? ? ? ? ?Min? ? ?Avg? ?Max? ?Mdev IPv6:? 4.565/5.028/6.021/0.318 ms IPv4:? 5.013/5.902/6.452/0.395 ms Speedtest systems give me 105Mbps down and 95Mbps upload speeds.... (to Durban???) - but do I really care? I'm more interested in "how quick does that Website load" or "how fast are responses to typing" - not "do I save a second in downloading a 1.2GB movie" Anyway - my Interactive interaction to my servers at Teraco is faster on IPv6 than on IPv4 - not that I really notice a 1ms difference! Oh - I strongly suggest if you are in the Internet industry then you should generally use your ccTLD based email address - not Gmail/Yahoo - etc. On 2026/07/08 09:01, Jaco Kroon via RPD wrote: > Hi All, > > I'm looping back to this original email, not because I want to answer > here directly, but rather because I think it's appropriate to consider > the "bigger picture" of responses. > > First and foremost, I've seen quite strong opinions from newly > registered @gmail.com addresses.? I'd like to understand the > affiliation of these participants. > > In my opinion there are a number of conflicting and not quite obvious > agendas in this, for this, and against this, policy proposal - all of > them with various commercial impacts for various entities.? Almost > none of them to the benefit of the "end consumer". > > I personally believe the best thing is to retain the current status > quo *as it stands*, as this leaves operational decisions to the > various network operators rather than enforcing operational issues by > way of policy. > > That said, I *personally* do not believe IPv4 should have a future of > any kind.? Here I'm in agreement with Jordi that networks should be > deploying as IPv6-first. > > The *reality* however is that the world is predominantly IPv4 - > "everyone" is connected using IPv4, and I don't (at least not in > Africa) see that this is going to change any time soon.? We've been > debating the reasons for this in the office the last week or two, and > I'm not going to bore you with the details, but our opinion is that > this is not because networks and techies don't want to switch but > because customers (yes, you read that right) demands that we don't.? > When you deploy DNS for a customer - just dare try and ask for AAAA > details when only provided with A details and see the response you > get.? Usually from people that should *know better*. > > When people run speedtest (which I understand measures only L7 > throughput) and they get a lower value on IPv6 than on IPv4 ... what's > the next thing that happens?? User logs into router, find the "disable > IPv6" button (or equivalent) *click*. > > Okay, so follow the (apparent) European standard of users may not have > access to their routers where they're forced to have IPv6 on and can > do nothing about it ... had a discussion the other day with someone in > Europe about this, "I get better throughput by putting my own router > behind that of my ISP and running IPv4 only on my own network" - where > there's v6 only ... well, I've yet to hear/see about that > end-network.? Some core networks sure I've heard of that. > > As much as I hate to say this:? IPv4 is going to be with us for a > while.? And we should encourage deployment of IPv6, but I don't think > we can enforce that by way of policy as this is interfering with > network operational decisions/designs.? I also strongly disagree with > apparent stances I've observed hinting that we should make the soft > landing more lax as that just drives up costs for everyone much sooner > and faster, and in a world where everyone I communicate with are > already complaining about the cost of stuff I don't think that's fair > either. > > Kind regards, > Jaco > > On 2026/05/28 10:05, Darwin Da Costa wrote: >> >> Dear PDWG, >> >> >> We have received a new draft policy proposal - IPv6 as a criteria in >> IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi >> Palet Martinez. The proposal contents are published at: >> >> >> https://afrinic.net/afpub-2026-v6-001-draft01 >> >> >> >> We encourage you to take some time to go through the proposal >> contents and ?provide feedback as follows: >> >> >> a)Do you support or oppose the proposal? >> >> >> b) If you oppose the proposal, state your reasons? >> >> >> c) Is there anything in the proposal that is not clear? >> >> >> d) What changes could be made to this proposal to make it more effective? >> >> >> >> Regards, >> >> Vincent Ngundi & Darwin Da Costa >> >> AFRINIC PDWG Co-Chairs >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -- Mark James ELKINS? -? Posix Systems - (South) Africa mje at posix.co.za?????? Tel: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za Posix SystemsVCARD for MJ Elkins -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: abessive_logo.jpg Type: image/jpeg Size: 6410 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: QR-MJElkins.png Type: image/png Size: 2163 bytes Desc: not available URL: From jaco at uls.co.za Wed Jul 8 09:28:34 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Wed, 8 Jul 2026 11:28:34 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: <3303462e-bb8c-42c3-a545-dcaa8f5f87ac@posix.co.za> References: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> <3303462e-bb8c-42c3-a545-dcaa8f5f87ac@posix.co.za> Message-ID: <93b132da-93fc-40ad-95cf-9b8d534bdf58@uls.co.za> Hi Mark, Yes.? The raw Mbits/second value ends up being marginally lower in almost all cases.? And that's all that matters. I agree latency is the more important measure.? Most (non-tech) people don't reason like that. Kind regards, Jaco On 2026/07/08 10:29, Mark Elkins via RPD wrote: > So IPv6 is slower??? > > From my home in Pretoria, where I have a 100Mbps FTTH connection via > Telkom/Axxess - I can easily test ping times to a server I have at > Teraco in Johannesburg. Running ping side-by-side, I see:- > > ? ? ? ? ? ?Min? ? ?Avg? ?Max? ?Mdev > IPv6:? 4.565/5.028/6.021/0.318 ms > IPv4:? 5.013/5.902/6.452/0.395 ms > > Speedtest systems give me 105Mbps down and 95Mbps upload speeds.... > (to Durban???) - but do I really care? I'm more interested in "how > quick does that Website load" or "how fast are responses to typing" - > not "do I save a second in downloading a 1.2GB movie" > > Anyway - my Interactive interaction to my servers at Teraco is faster > on IPv6 than on IPv4 - not that I really notice a 1ms difference! > > Oh - I strongly suggest if you are in the Internet industry then you > should generally use your ccTLD based email address - not Gmail/Yahoo > - etc. > > > On 2026/07/08 09:01, Jaco Kroon via RPD wrote: > >> Hi All, >> >> I'm looping back to this original email, not because I want to answer >> here directly, but rather because I think it's appropriate to >> consider the "bigger picture" of responses. >> >> First and foremost, I've seen quite strong opinions from newly >> registered @gmail.com addresses.? I'd like to understand the >> affiliation of these participants. >> >> In my opinion there are a number of conflicting and not quite obvious >> agendas in this, for this, and against this, policy proposal - all of >> them with various commercial impacts for various entities.? Almost >> none of them to the benefit of the "end consumer". >> >> I personally believe the best thing is to retain the current status >> quo *as it stands*, as this leaves operational decisions to the >> various network operators rather than enforcing operational issues by >> way of policy. >> >> That said, I *personally* do not believe IPv4 should have a future of >> any kind.? Here I'm in agreement with Jordi that networks should be >> deploying as IPv6-first. >> >> The *reality* however is that the world is predominantly IPv4 - >> "everyone" is connected using IPv4, and I don't (at least not in >> Africa) see that this is going to change any time soon.? We've been >> debating the reasons for this in the office the last week or two, and >> I'm not going to bore you with the details, but our opinion is that >> this is not because networks and techies don't want to switch but >> because customers (yes, you read that right) demands that we don't.? >> When you deploy DNS for a customer - just dare try and ask for AAAA >> details when only provided with A details and see the response you >> get.? Usually from people that should *know better*. >> >> When people run speedtest (which I understand measures only L7 >> throughput) and they get a lower value on IPv6 than on IPv4 ... >> what's the next thing that happens?? User logs into router, find the >> "disable IPv6" button (or equivalent) *click*. >> >> Okay, so follow the (apparent) European standard of users may not >> have access to their routers where they're forced to have IPv6 on and >> can do nothing about it ... had a discussion the other day with >> someone in Europe about this, "I get better throughput by putting my >> own router behind that of my ISP and running IPv4 only on my own >> network" - where there's v6 only ... well, I've yet to hear/see about >> that end-network.? Some core networks sure I've heard of that. >> >> As much as I hate to say this:? IPv4 is going to be with us for a >> while.? And we should encourage deployment of IPv6, but I don't think >> we can enforce that by way of policy as this is interfering with >> network operational decisions/designs.? I also strongly disagree with >> apparent stances I've observed hinting that we should make the soft >> landing more lax as that just drives up costs for everyone much >> sooner and faster, and in a world where everyone I communicate with >> are already complaining about the cost of stuff I don't think that's >> fair either. >> >> Kind regards, >> Jaco >> >> On 2026/05/28 10:05, Darwin Da Costa wrote: >>> >>> Dear PDWG, >>> >>> >>> We have received a new draft policy proposal - IPv6 as a criteria in >>> IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi >>> Palet Martinez. The proposal contents are published at: >>> >>> >>> https://afrinic.net/afpub-2026-v6-001-draft01 >>> >>> >>> >>> We encourage you to take some time to go through the proposal >>> contents and ?provide feedback as follows: >>> >>> >>> a)Do you support or oppose the proposal? >>> >>> >>> b) If you oppose the proposal, state your reasons? >>> >>> >>> c) Is there anything in the proposal that is not clear? >>> >>> >>> d) What changes could be made to this proposal to make it more >>> effective? >>> >>> >>> >>> Regards, >>> >>> Vincent Ngundi & Darwin Da Costa >>> >>> AFRINIC PDWG Co-Chairs >>> >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > -- > > Mark James ELKINS? -? Posix Systems - (South) Africa > mje at posix.co.za Tel: +27.826010496 > For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za > > Posix SystemsVCARD for MJ Elkins > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: abessive_logo.jpg Type: image/jpeg Size: 6410 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: QR-MJElkins.png Type: image/png Size: 2163 bytes Desc: not available URL: From jordi.palet at consulintel.es Wed Jul 8 11:08:15 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Wed, 8 Jul 2026 13:08:15 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> Message-ID: Hi Jaco, Some responses below, in-line. Regards, Jordi @jordipalet > El 8 jul 2026, a las 9:01, Jaco Kroon via RPD escribi?: > > Hi All, > > I'm looping back to this original email, not because I want to answer here directly, but rather because I think it's appropriate to consider the "bigger picture" of responses. > > First and foremost, I've seen quite strong opinions from newly registered @gmail.com addresses. I'd like to understand the affiliation of these participants. > > In my opinion there are a number of conflicting and not quite obvious agendas in this, for this, and against this, policy proposal - all of them with various commercial impacts for various entities. Almost none of them to the benefit of the "end consumer". > > I personally believe the best thing is to retain the current status quo *as it stands*, as this leaves operational decisions to the various network operators rather than enforcing operational issues by way of policy. > > That said, I *personally* do not believe IPv4 should have a future of any kind. Here I'm in agreement with Jordi that networks should be deploying as IPv6-first. > > The *reality* however is that the world is predominantly IPv4 - "everyone" is connected using IPv4, and I don't (at least not in Africa) see that this is going to change any time soon. We've been debating the reasons for this in the office the last week or two, and I'm not going to bore you with the details, but our opinion is that this is not because networks and techies don't want to switch but because customers (yes, you read that right) demands that we don't. When you deploy DNS for a customer - just dare try and ask for AAAA details when only provided with A details and see the response you get. Usually from people that should *know better*. > I disagree, not true anymore. Measurements from Google, Meta, APNIC, Akamai, etc., show 50% and none of them is able to measure the traffic in China (where they have strict mandates for IPv6-only), so worldwide, we are closer to 65-70%. In addition to that, there is something that we never count on measurements, in terms of actual terabits. All the traffic from CDNs is measured only ?once? (when it is cached), but if users have IPv6, they will get as many copies with IPv6 as users accessing that content. This is the reason why IX can?t measure CDN traffic and often they are showing much lower real data. > When people run speedtest (which I understand measures only L7 throughput) and they get a lower value on IPv6 than on IPv4 ... what's the next thing that happens? User logs into router, find the "disable IPv6" button (or equivalent) *click*. > > If you get lower measurements with IPv6 there is some deployment issue, either in the access, distribution, BNGs, or even upstreams. This is not only creating this ?slower effect?, but also Happy Eyeballs entering into action and falling back to IPv4. One of the reasons that I mention in a previous email a few days ago which means that instead of having 70-90% IPv6 traffic you may be getting only 30%. Geoff Huston do lots of measurements that show that IPv6 typically is faster (not because the protocol itself, but just because the lack of NAT and CGN, as well as because often it is deployed much better than keeping the older IPv4 configs). Here is the thing. When you deploy IPv4, you really check everything, ensure a good monitoring, etc., right? Well, we like it or not, I see many IPv6 deployments really broken. Again lack of expertise in real deployment and good knowledge of standards. > Okay, so follow the (apparent) European standard of users may not have access to their routers where they're forced to have IPv6 on and can do nothing about it ... had a discussion the other day with someone in Europe about this, "I get better throughput by putting my own router behind that of my ISP and running IPv4 only on my own network" - where there's v6 only ... well, I've yet to hear/see about that end-network. Some core networks sure I've heard of that. > This is probably from someone misinformed. In fact, since many years ago EU regulations enforce the provider to give complete access to the CPE, and even be able to replace it with your own, etc. > As much as I hate to say this: IPv4 is going to be with us for a while. And we should encourage deployment of IPv6, but I don't think we can enforce that by way of policy as this is interfering with network operational decisions/designs. I also strongly disagree with apparent stances I've observed hinting that we should make the soft landing more lax as that just drives up costs for everyone much sooner and faster, and in a world where everyone I communicate with are already complaining about the cost of stuff I don't think that's fair either. > So we prefer instead of our own policies at our own pace, government regulations? > > Kind regards, > Jaco > > On 2026/05/28 10:05, Darwin Da Costa wrote: >> Dear PDWG, >> >> We have received a new draft policy proposal - IPv6 as a criteria in IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at: >> >> https://afrinic.net/afpub-2026-v6-001-draft01 >> >> >> We encourage you to take some time to go through the proposal contents and provide feedback as follows: >> >> a)Do you support or oppose the proposal? >> >> b) If you oppose the proposal, state your reasons? >> >> c) Is there anything in the proposal that is not clear? >> >> d) What changes could be made to this proposal to make it more effective? >> >> >> Regards, >> Vincent Ngundi & Darwin Da Costa >> AFRINIC PDWG Co-Chairs >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Wed Jul 8 11:55:32 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Wed, 8 Jul 2026 13:55:32 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 In-Reply-To: <0A1B8E6A-A26D-45D0-91A7-FE9E34A802CF@afrinic.net> References: <1783459420709.11832@tra.gov.eg> <0A1B8E6A-A26D-45D0-91A7-FE9E34A802CF@afrinic.net> Message-ID: Hi Ben, Why today will anyone build a new network without IPv6? In fact building anything new or extending any existing network, not just in Africa, worldwide, without proper IPv6 support it will be clearly going against who is buliding that network and the customers. There is no excuse. Also note that Seun proposed that ?n? first IPv4 allocations are exempt from the IPv6 deployment plan, so new networks are well covered. Regards, Jordi @jordipalet > El 8 jul 2026, a las 2:38, Ben Roberts - AfriNIC via RPD escribi?: > > It seems to me that the proposal serves mostly to complicate what is an already complex process. > > ? The IPv6 deployment plan must > show the actual IPv4 top-25 traffic > destinations of that network. For > each of those external destinations > that are IPv6-enabled, the following > minimum IPv6 % will be considered? > > Like a new startup ISP in rural Africa even has traffic analysis tools to measure their IPV4 top 25 destinations? > > The policy is looking like another barrier to Building Africas Digital Future. Therefore I can?t support it. > > > Sent from my iPhone > >> On 8 Jul 2026, at 00:25, Hytham El-Nakhal wrote: >> >> ?Dear PDWG, >> >> >> I have noticed some mails from community members regarding the policy proposal "IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01". >> >> >> The author has updated the proposal (DRAFT02), and it was discussed during the AFRINIC-37 PPM on 24th June 2026. >> >> >> The updated proposal is attached to this email to bring you up to speed with its contents [pending the re-establishment of the AFRINIC website by COB 8th July as communicated by AFRINIC]. >> >> The updated proposal did not reach consensus at the AFRINIC-37 PPM and was sent back to the RPD mailing-list for further discussions. >> >> >> Those who missed the discussions still have access the AF-37 PPM proceedings here: https://www.youtube.com/watch?v=uwjG1_XwKV8 . >> >> >> Therefore, it is highly recommended that participants thoroughly review the attached proposal, familiarize themselves with prior discussions on the mailing list and during the Public Policy Meeting, and subsequently focus their valuable contribution by undertaking any of the following actions: >> >> * - Seek clarifications regarding the policy text and offer recommendations for its improvement; >> * - Express formal support for the proposal; or, >> * - Provide a detailed justification in case of opposition to the policy as drafted. >> >> >> Best Regards, >> Haitham el Nakhal >> PDWG Co-Chair >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Wed Jul 8 12:28:16 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Wed, 8 Jul 2026 14:28:16 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> Message-ID: Hi Jordi, On 2026/07/08 13:08, jordi.palet--- via RPD wrote: > Hi Jaco, > > Some responses below, in-line. > > Regards, > Jordi > > @jordipalet > >> El 8 jul 2026, a las 9:01, Jaco Kroon via RPD escribi?: >> >> Hi All, >> >> I'm looping back to this original email, not because I want to answer >> here directly, but rather because I think it's appropriate to >> consider the "bigger picture" of responses. >> >> First and foremost, I've seen quite strong opinions from newly >> registered @gmail.com addresses.? I'd like to understand the >> affiliation of these participants. >> >> In my opinion there are a number of conflicting and not quite obvious >> agendas in this, for this, and against this, policy proposal - all of >> them with various commercial impacts for various entities. Almost >> none of them to the benefit of the "end consumer". >> >> I personally believe the best thing is to retain the current status >> quo *as it stands*, as this leaves operational decisions to the >> various network operators rather than enforcing operational issues by >> way of policy. >> >> That said, I *personally* do not believe IPv4 should have a future of >> any kind.? Here I'm in agreement with Jordi that networks should be >> deploying as IPv6-first. >> >> The *reality* however is that the world is predominantly IPv4 - >> "everyone" is connected using IPv4, and I don't (at least not in >> Africa) see that this is going to change any time soon.? We've been >> debating the reasons for this in the office the last week or two, and >> I'm not going to bore you with the details, but our opinion is that >> this is not because networks and techies don't want to switch but >> because customers (yes, you read that right) demands that we don't.? >> When you deploy DNS for a customer - just dare try and ask for AAAA >> details when only provided with A details and see the response you >> get.? Usually from people that should *know better*. >> > I disagree, not true anymore. Measurements from Google, Meta, APNIC, > Akamai, etc., show 50% and none of them is able to measure the traffic > in China (where they have strict mandates for IPv6-only), so > worldwide, we are closer to 65-70%. > > In addition to that, there is something that we never count on > measurements, in terms of actual terabits. All the traffic from CDNs > is measured only ?once? (when it is cached), but if users have IPv6, > they will get as many copies with IPv6 as users accessing that > content. This is the reason why IX can?t measure CDN traffic and often > they are showing much lower real data. None of which gives the registry the rights to dictate to net-ops. Nor were I referring to any of the names you're mentioning, and I specifically refrained from - and will continue to refrain from - naming names. Your entire argument is valid, but doesn't address my statement that real-world customers (at least in Africa) absolutely resist IPv6. Now you're dictating to netops that they must dictate to their customers.? Y ou cannot do that.? That's not the purpose of a registry.? Nor should it be. >> >> When people run speedtest (which I understand measures only L7 >> throughput) and they get a lower value on IPv6 than on IPv4 ... >> what's the next thing that happens?? User logs into router, find the >> "disable IPv6" button (or equivalent) *click*. >> > If you get lower measurements with IPv6 there is some deployment > issue, either in the access, distribution, BNGs, or even upstreams. > This is not only creating this ?slower effect?, but also Happy > Eyeballs entering into action and falling back to IPv4. One of the > reasons that I mention in a previous email a few days ago which means > that instead of having 70-90% IPv6 traffic you may be getting only 30%. Right.? Let's take a 1Gbps ethernet link.? Max sizes packets, no VLANs. ipg = 96-bit times aka 12 bytes preamble = 8 eth header = 14 payload = 1500 (ipv4=20, ipv6=40, tcp=20, so payload for v4 = 1460 for v6 1440, excluding crypto overhead which may apply). trailer = 4 bytes. That means at max packets we can use: packets per second = 1E9 / ((12 + 8 + 14 + 1500 + 4) * 8) ? = 1E9 / (1538 * 8) ? = 81274.38231 Which means: IPv4 rate = 81274.38231 * 1460 = 118660598.17260B/s = 949284785.38080bps = 949.28Mbps (which is what we're typically seeing on 1Gbps services through speedtest). IPv6 rate = 81274.38231 * 1440 = 117035110.52640B/s = 936280884.21120bpx = 936.28Mbps (which a customer is saying Oh I'm getting lower performance on IPv6 compared to IPv4 .. *off*). > > Geoff Huston do lots of measurements that show that IPv6 typically is > faster (not because the protocol itself, but just because the lack of > NAT and CGN, as well as because often it is deployed much better than > keeping the older IPv4 configs). This techs all over the world (myself included) will agree with you, but the only measure that matters to customers (and many an "IT Professional") is Ookla Speedtest. Absolutely irrelevant.? You're still dictating network design and architecture to entities that's not you, something you have no right to do. > > Here is the thing. When you deploy IPv4, you really check everything, > ensure a good monitoring, etc., right? Well, we like it or not, I see > many IPv6 deployments really broken. Again lack of expertise in real > deployment and good knowledge of standards. Well ... here I get where you're coming from, and I have to concede that - but this isn't the case on all networks.? Again, irrelevant to the discussion. >> Okay, so follow the (apparent) European standard of users may not >> have access to their routers where they're forced to have IPv6 on and >> can do nothing about it ... had a discussion the other day with >> someone in Europe about this, "I get better throughput by putting my >> own router behind that of my ISP and running IPv4 only on my own >> network" - where there's v6 only ... well, I've yet to hear/see about >> that end-network.? Some core networks sure I've heard of that. >> > This is probably from someone misinformed. In fact, since many years > ago EU regulations enforce the provider to give complete access to the > CPE, and even be able to replace it with your own, etc. Uhrm.? Again, can't disclose, but no.? Two cases.? The one I know from face to face direct, and can confirm that no access to the router was available.? Ports aren't even opened towards LAN side. The other case was from a reputable developer who works on one of the Linux distributions. >> >> As much as I hate to say this:? IPv4 is going to be with us for a >> while.? And we should encourage deployment of IPv6, but I don't think >> we can enforce that by way of policy as this is interfering with >> network operational decisions/designs.? I also strongly disagree with >> apparent stances I've observed hinting that we should make the soft >> landing more lax as that just drives up costs for everyone much >> sooner and faster, and in a world where everyone I communicate with >> are already complaining about the cost of stuff I don't think that's >> fair either. >> > So we prefer instead of our own policies at our own pace, government > regulations? I'm just saying your way isn't in my opinion the way to get this done.? You're adding significant additional operational issues to measure metrics that networks honestly shouldn't have to need to care about, burdening network operators that's already suffering from an over-abundance of stupid. I'm also saying that going the other way and completely loosening the soft-landing is even more absurd as it would have the side effect of blocking new entrants into the market (bad for consumer) much sooner, and make entering into the market much more expensive for new players. At best you can state that the network operator has to be able to show which proportion of their network is IPv6 capable, and what portion of customers has access to IPv6 if they so choose. You cannot dictate that networks has to force IPv6 onto their customers who don't want it, and you most certainly (at least in Africa) cannot measure uptake based on traffic percentage.? I've included the reasoning on this into a presentation earlier in the year, and have managed to consolidate the different measures to within roughly 1% to explain the discrepancies between a couple various measuring methodologies. This would put my own network at 99.885 % measurement.? But if I use your measurements we're below 10% - not because we've not done our part, but because: a)? Consumer networks accessing services hosted on our network is IPv4 only; b)? Customers are actively switching OFF IPv6 on the services they procure from us; and c)? Customers that host services on our network aren't deploying AAAA records, even when we push them to do so.? In many cases we don't even know what all the names are that's being set to the relevant IP space. You are now aiming to punish our (and other networks in a similar situation to ours) because of other's behaviour. If I need to choose between that and government regulation ... I think I might go fishing instead. Kind regards, Jaco -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Wed Jul 8 12:34:47 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Wed, 8 Jul 2026 15:34:47 +0300 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 In-Reply-To: References: Message-ID: Jordi, My invitation to come and visit rural schools and the ISPs that connect them remains open so you can see the ?situation kwa ground? of connectivity entrepreneurship. The kind start up ISPs who make up a good proportion of Afrinic?s new members. They face enough challenges and enforced rules on IPv6 deployment is just another hurdle? Best regards Ben Sent from my iPhone > On 8 Jul 2026, at 14:56, jordi.palet--- via RPD wrote: > > ?Hi Ben, > > Why today will anyone build a new network without IPv6? In fact building anything new or extending any existing network, not just in Africa, worldwide, without proper IPv6 support it will be clearly going against who is buliding that network and the customers. There is no excuse. > > Also note that Seun proposed that ?n? first IPv4 allocations are exempt from the IPv6 deployment plan, so new networks are well covered. > > Regards, > Jordi > > @jordipalet > >> El 8 jul 2026, a las 2:38, Ben Roberts - AfriNIC via RPD escribi?: >> >> It seems to me that the proposal serves mostly to complicate what is an already complex process. >> >> ? The IPv6 deployment plan must >> show the actual IPv4 top-25 traffic >> destinations of that network. For >> each of those external destinations >> that are IPv6-enabled, the following >> minimum IPv6 % will be considered? >> >> Like a new startup ISP in rural Africa even has traffic analysis tools to measure their IPV4 top 25 destinations? >> >> The policy is looking like another barrier to Building Africas Digital Future. Therefore I can?t support it. >> >> >> Sent from my iPhone >> >>> On 8 Jul 2026, at 00:25, Hytham El-Nakhal wrote: >>> >>> ?Dear PDWG, >>> >>> >>> I have noticed some mails from community members regarding the policy proposal "IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01". >>> >>> >>> The author has updated the proposal (DRAFT02), and it was discussed during the AFRINIC-37 PPM on 24th June 2026. >>> >>> >>> The updated proposal is attached to this email to bring you up to speed with its contents [pending the re-establishment of the AFRINIC website by COB 8th July as communicated by AFRINIC]. >>> >>> The updated proposal did not reach consensus at the AFRINIC-37 PPM and was sent back to the RPD mailing-list for further discussions. >>> >>> >>> Those who missed the discussions still have access the AF-37 PPM proceedings here: https://www.youtube.com/watch?v=uwjG1_XwKV8 . >>> >>> >>> Therefore, it is highly recommended that participants thoroughly review the attached proposal, familiarize themselves with prior discussions on the mailing list and during the Public Policy Meeting, and subsequently focus their valuable contribution by undertaking any of the following actions: >>> >>> * - Seek clarifications regarding the policy text and offer recommendations for its improvement; >>> * - Express formal support for the proposal; or, >>> * - Provide a detailed justification in case of opposition to the policy as drafted. >>> >>> >>> Best Regards, >>> Haitham el Nakhal >>> PDWG Co-Chair >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Wed Jul 8 14:18:05 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Wed, 08 Jul 2026 16:18:05 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01 In-Reply-To: References: Message-ID: <998516E3-EAE0-427E-BF00-E35268D69117@hevis.co.za> On 7 Jul 2026, at 15:33, Simphiwe Ngubane via RPD wrote: > Dear Jordi and colleagues, > > Thank you for continuing to share practical deployment experience. > > One observation I would like to make is that much of this discussion measures success through IPv6 adoption percentages. yeah, that will be a sticky point from several perspectives. > While those metrics are certainly useful operationally, I wonder whether they are the right indicators for policy. I?d rather have a policy with indicators that is mostly right, than perfect. > Should the success of Internet number resource governance instead be measured by questions such as: > > * Can operators retain confidence in registry neutrality? What is the counter point you are seeing here? ie. what would make it biased instead of neutral? > * Can resources remain portable when circumstances change? Portable as in? If you refer to out of Africa for resources designed to Africa, then I?d say the answer should be an unequivocal NO > * Do operators have meaningful exit options? Exit from what? as in they quite the IP industry and now want to sell their ?resources?? Nope, that should not and never was the intention of IP resources. > * Are transfer processes predictable and transparent? give a use case to underline you point other than being greedy and gathering cheap resources to be ?sold? at a higher price? > * Does policy minimise unnecessary administrative discretion? At present there aren?t, other than proving you are a African based operator. What other administrative discretion are you afraid of? > If these governance foundations are strong, operators remain free to adopt IPv6 wherever it provides value. yeah, but the initial idea of the softlanding (from my interpretation) was to PREVENT resource gathering and reselling.. something that is counter to the ideas of the original Internet, but that got abused by the IP leasing companies, counter to the needs and provisioning of those of lesser means > If those foundations are weak, adding IPv6 criteria may simply increase institutional dependence rather than improving Internet resilience. I?d counter the issue that once you have a proper IPv6 rollout, then the IPv4 softlandings/etc. is mood points, as nobody would care about it. > Jordi, would you support a broader discussion on governance reforms that strengthen portability, operator autonomy and exit rights alongside any discussion of IPv6? Again may I ask you to show examples and case studies you have in mind that these IPv6 policies would impact? > To me, those principles appear complementary to a healthy and competitive Internet. Internet was originally never about ?competitiveness?, but about sharing and caring and distribution of knowledge. Just go ask Archie! The internet is turning nasty and competitive (in my personal view, competitive is nasty, not good as it is counter to Ubuntu and working together) because of the idea and notion of IPv4 leasing companies that doesn?t add value, but just use it for their own pockets as speculation, where as we?d like to provide services in sharing knowledge? but that is the difference between those that see IPv4 addresses as ?property?, instead of resources that had been placed in your guardianship (LIR) which is the more correct viewpoint for IP resources IMHO. > Thank you for considering another perspective. > > Best regards, > Simphiwe Ngubane > "IPv4 is an important service enabler." Nope, IPv6 is. IPv4 is currently a tool used to make war, not peace. And yes, I?ll debate you on it as my eyes opened up to the gains from using IPv6 in my network vs IPv4 that is holding me back!! > > > > [cid:9a927a36-99f1-4767-8d8a-61a5ac7949f8] > > Simphiwe Ngubane > > > > MSc (Eng) specialising in Geomatics candidate: > > > > Faculty of Engineering & the Built Environment > > > > Menzies Building, Level 5 > > > > Upper Campus > > > > University of Cape Town | Rondebosch|7701 > > > > Phone: 0810479025 > > > > Email: ngbsim008 at myuct.ac.za > > > > ? > > > > > > Disclaimer - University of Cape Town This email is subject to UCT policies and email disclaimer published on our website at https://www.uct.ac.za/main/email-disclaimer or obtainable from +27 21 650 9111. If this email is not related to the business of UCT, it is sent by the sender in an individual capacity. Please report security incidents or abuse via https://csirt.uct.ac.za/report-incident > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From hvisage at hevis.co.za Wed Jul 8 18:27:58 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Wed, 08 Jul 2026 20:27:58 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: <3303462e-bb8c-42c3-a545-dcaa8f5f87ac@posix.co.za> References: <7DED1C3E-6BCB-4414-8F8D-9252540BAE18@gmail.com> <3303462e-bb8c-42c3-a545-dcaa8f5f87ac@posix.co.za> Message-ID: On 8 Jul 2026, at 10:29, Mark Elkins via RPD wrote: > So IPv6 is slower??? Yes? well? the *perception* several times, and the ? wel? guilty party is the one that tries to make things beterer for IPv6? HE.net ;( I had the case where they are grabbing traffic for some reason, and then it goes long paths around the world? instead of the shortest IPv4 route, so yes, there is one example. I?ve heard from another provider that had a user that had similar IPV6 slowness complaints whenever they have IPv6 enabled on the router? I had the case 2-3 weeks ago, where the IPv6 to a major bank?s public facing website (the only IPv6 portion) didn?t want to load, switched off IPv4 and it works like a charm?. IPv6 MSS/MTU on a PPPoE link and once I forced a lower TCP MSS on the link things worked again, so I see those clients (like Jaco?s) would?ve also seen similar and dropped IPv6 in favor of IPv4 only on their network firewall ?cause of issues like the above. > Oh - I strongly suggest if you are in the Internet industry then you > should generally use your ccTLD based email address - not Gmail/Yahoo > - etc. It this group not also suppose to be ?verified? users in/from the AfriNIC WhoIS DB? > > > On 2026/07/08 09:01, Jaco Kroon via RPD wrote: > >> Hi All, >> >> I'm looping back to this original email, not because I want to answer >> here directly, but rather because I think it's appropriate to >> consider the "bigger picture" of responses. >> >> First and foremost, I've seen quite strong opinions from newly >> registered @gmail.com addresses.? I'd like to understand the >> affiliation of these participants. >> >> In my opinion there are a number of conflicting and not quite obvious >> agendas in this, for this, and against this, policy proposal - all of >> them with various commercial impacts for various entities.? Almost >> none of them to the benefit of the "end consumer". >> >> I personally believe the best thing is to retain the current status >> quo *as it stands*, as this leaves operational decisions to the >> various network operators rather than enforcing operational issues by >> way of policy. >> >> That said, I *personally* do not believe IPv4 should have a future of >> any kind.? Here I'm in agreement with Jordi that networks should be >> deploying as IPv6-first. >> >> The *reality* however is that the world is predominantly IPv4 - >> "everyone" is connected using IPv4, and I don't (at least not in >> Africa) see that this is going to change any time soon.? We've been >> debating the reasons for this in the office the last week or two, and >> I'm not going to bore you with the details, but our opinion is that >> this is not because networks and techies don't want to switch but >> because customers (yes, you read that right) demands that we don't.? >> When you deploy DNS for a customer - just dare try and ask for AAAA >> details when only provided with A details and see the response you >> get.? Usually from people that should *know better*. >> >> When people run speedtest (which I understand measures only L7 >> throughput) and they get a lower value on IPv6 than on IPv4 ... >> what's the next thing that happens?? User logs into router, find the >> "disable IPv6" button (or equivalent) *click*. >> >> Okay, so follow the (apparent) European standard of users may not >> have access to their routers where they're forced to have IPv6 on and >> can do nothing about it ... had a discussion the other day with >> someone in Europe about this, "I get better throughput by putting my >> own router behind that of my ISP and running IPv4 only on my own >> network" - where there's v6 only ... well, I've yet to hear/see about >> that end-network.? Some core networks sure I've heard of that. >> >> As much as I hate to say this:? IPv4 is going to be with us for a >> while.? And we should encourage deployment of IPv6, but I don't >> think we can enforce that by way of policy as this is interfering >> with network operational decisions/designs.? I also strongly >> disagree with apparent stances I've observed hinting that we should >> make the soft landing more lax as that just drives up costs for >> everyone much sooner and faster, and in a world where everyone I >> communicate with are already complaining about the cost of stuff I >> don't think that's fair either. >> >> Kind regards, >> Jaco >> >> On 2026/05/28 10:05, Darwin Da Costa wrote: >>> >>> Dear PDWG, >>> >>> >>> We have received a new draft policy proposal - IPv6 as a criteria in >>> IPv4 Soft Landing ID AFPUB-2026-v6-001-DRAFT01 from author Jordi >>> Palet Martinez. The proposal contents are published at: >>> >>> >>> https://afrinic.net/afpub-2026-v6-001-draft01 >>> >>> >>> >>> We encourage you to take some time to go through the proposal >>> contents and ?provide feedback as follows: >>> >>> >>> a)Do you support or oppose the proposal? >>> >>> >>> b) If you oppose the proposal, state your reasons? >>> >>> >>> c) Is there anything in the proposal that is not clear? >>> >>> >>> d) What changes could be made to this proposal to make it more >>> effective? >>> >>> >>> >>> Regards, >>> >>> Vincent Ngundi & Darwin Da Costa >>> >>> AFRINIC PDWG Co-Chairs >>> >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > -- > > Mark James ELKINS? -? Posix Systems - (South) Africa > mje at posix.co.za?????? Tel: +27.826010496 > For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za > > Posix SystemsVCARD for MJ Elkins > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From comms-announce at afrinic.net Wed Jul 8 19:08:24 2026 From: comms-announce at afrinic.net (AFRINIC Announce) Date: Wed, 8 Jul 2026 19:08:24 +0000 Subject: [rpd] Secure Static Version Now Available Message-ID: [Version en fran?ais au bas] Dear Colleagues, Further to our communication regarding the temporary unavailability of the AFRINIC website, we are pleased to inform you that a secure static version of the AFRINIC website is now publicly accessible (www.afrinic.net). The static website provides access to essential information and resources that our members, stakeholders, and the broader Internet community most frequently use. Our technical team continues to work diligently on the next stages of the website restoration process, including developing a fully rebuilt website environment. We remain committed to ensuring that the final platform delivers an enhanced, secure, and reliable experience for the AFRINIC community. We would also like to reiterate that AFRINIC's core Internet number resource management services have remained fully operational throughout this period. Resource management, member support, registry operations, and other essential services continue to be delivered without interruption. We encourage members and stakeholders to visit the website and access the information currently available. Additional content and functionality will be progressively restored as work continues. AFRINIC would like to thank you for your patience, understanding, and continued support.. Further updates will be shared through our official communication channels as restoration activities progress. Should you have any questions or require assistance, please contact us at contact at afrinic.net. Kind Regards, AFRINIC Communications ?????????. Version statique s?curis?e du site Web est d?sormais disponible Chers members de la communaut?, ? la suite de notre communication concernant l?indisponibilit? temporaire du site web d?AFRINIC, nous avons le plaisir de vous informer qu?une version statique s?curis?e du site web d?AFRINIC est d?sormais accessible au public ? l?adresse www.afrinic.net. Le site web statique donne acc?s aux informations et ressources essentielles les plus fr?quemment utilis?es par nos membres, nos parties prenantes et la communaut? Internet au sens large. Notre ?quipe technique poursuit activement les prochaines ?tapes du processus de restauration du site web, y compris le d?veloppement d?un nouvel environnement enti?rement reconstruit. Nous restons d?termin?s ? faire en sorte que la plateforme finale offre ? la communaut? AFRINIC une exp?rience am?lior?e, s?curis?e et fiable. Nous souhaitons ?galement rappeler que les services essentiels d?AFRINIC li?s ? la gestion des adresses IP restent pleinement op?rationnels. La gestion des ressources IP, l?assistance aux membres, les op?rations de registre ainsi que les autres services essentiels continuent d??tre assur?s sans interruption. Nous encourageons les membres et les parties prenantes ? visiter le site web et ? acc?der aux informations actuellement disponibles. Des contenus et fonctionnalit?s suppl?mentaires seront progressivement restaur?s ? mesure que les travaux se poursuivent. AFRINIC tient ? vous remercier pour votre patience, votre compr?hension et votre soutien continu. De nouvelles mises ? jour seront partag?es ? travers nos canaux de communication officiels au fur et ? mesure de l?avancement des activit?s de restauration. Pour toute question ou demande d?assistance, veuillez nous contacter ? l?adresse contact at afrinic.net. Cordialement, AFRINIC Communications -------------- next part -------------- An HTML attachment was scrubbed... URL: From aalain at trstech.net Sat Jul 11 16:51:14 2026 From: aalain at trstech.net (ALAIN AINA) Date: Sat, 11 Jul 2026 16:51:14 +0000 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: <84082285-459A-4843-9C4A-3D201E083840@consulintel.es> References: <497AC0C6-09CF-4FE3-A6F9-B32690413A71@afrinic.net> <84082285-459A-4843-9C4A-3D201E083840@consulintel.es> Message-ID: <424D5D46-AA0D-411D-A26D-743C59BE2F25@trstech.net> Hi PDWG Much has already been said about why this proposal and its variants are not suitable for our region. It is tempting to shift the discussion from ?IPv6 as a criterion in IPv4 Soft Landing AFPUB?2026?v6?001?DRAFT02? to broader IPv6 deployment topics, but that belongs in operational fora such as AFNOG, not in the PDWG. We should clearly distinguish IPv6 readiness from IPv6 deployment. Many operators may have improved readiness but are not yet in a position to roll out IPv6 to end?users. PDWG cannot dictate operational practices. 5G is indeed a strong enabler for IPv6 rollout among MNOs. As 5G expands in the region, IPv6 adoption will naturally increase. This aligns with global trends in 5G IPv6 behavior compared to 4G IPv6 behavior. But again, this is an operational evolution; not a policy lever. Regarding IPv6 performance over IPv4, APNIC Labs data (RTT comparison v6/v4, IPv6 TCP failure rate, IPv6 fragmentation drop rates) shows improvement, but also shows persistent and significant gaps. We should avoid excessive euphoria. The data does not support the idea that IPv6 performance is uniformly strong enough to justify using it as a gating criterion for IPv4 access. On CGN vs IPv6?only + 464XLAT: in this region, operators are not ?investing? in CGN today. CGN was built into their architecture from the beginning, and many secured IPv4 space before Soft Landing or during Soft Landing phase 1. The cost?comparison argument simply does not apply uniformly here, and cannot be used as justification for policy changes. IPv6 adoption should be encouraged through experience sharing, showcases, and lessons learned, not through policy mechanisms that attempt to enforce operational practices. We have also been here before. During the 2016?2018 discussions to amend Soft Landing, similar attempts were made to impose IPv6 deployment and later IPv6 resource requirements as pre?conditions for IPv4 requests, or to create a dedicated reserve of IPv4 to ?facilitate? IPv6 deployment(1). At that time, global IPv6 deployment was around 25%, and only one country in Africa exceeded 5%. The archives(2) are explicit. Let?s keep IPv6 adoption discussions active, but separate them entirely from IPv4 Soft Landing policy, which must remain operationally neutral, technically realistic, and region?appropriate. (1) https://web.archive.org/web/20260411113239/https://afrinic.net/policy/2016-v4-001-d7?lang=en#proposal (2) https://lists.afrinic.net/pipermail/rpd/2018/thread.html#8214 HTH ?Alain > On 6 Jul 2026, at 08:41, jordi.palet--- via RPD wrote: > > Hi Christian, > > Yes, that?s true as well, but the difference is that those operators (for example the case of Spain, which I know very well), aren?t in a hurry for IPv6 deployment, because: > 1) They already invested long time ago in getting more IPv4 addressed that they need, indirectly via M&A. Several of them have extra IPv4 addresses. > 2) Some times they also invested in CGN boxes (specially in mobile networks). > > In the specific case of Spain, I did consultancy for all the major operators already in 2011-2013 time frame. I?ve even worked with some of them in 2002. So I know very well the situation and specific rationales. Note also that 464XLAT was not available at that time. For me is a shame that IPv6 deployment in my own country is not progressing as well as it should be. We say here (free translation, I?m sure you have an equivalent sentence): ?you can?t be a prophet in your own land?. > > The main difference here is that many operators in Africa haven?t sufficient IPv4 addresses, so what we are proposing is, instead of investing in CGN with is a bad solution in the long term, you can invest in IPv6 deployment. It is easy to demonstrate that it is actually much cheaper. 464XLAT needs much less IPv4 addresses (for the PLAT IPv4 pool) than CGN (NAT444). In addition to that, IPv4 pools in CGN (NAT444) when detected by some service provider, such as Sony Network Play Station, get blocked in a black-list which is never cleaned, so you get an IPv4 block (or you already have it), and becomes useless if you have gammers (is an example, it happens with other services) in your network. > > RFC > > Regards, > Jordi > > @jordipalet > >> El 5 jul 2026, a las 12:26, Bope Domilongo Christian escribi?: >> >> >> >> On Sun, 28 Jun 2026 at 11:16, jordi.palet--- via RPD wrote: >> Fortunately, deploying 464XLAT in mobile networks (the only way to go) is much easier and cheaper than in wireline. Vendors of both UEs and packet switch mobile networks support it very well since many years ago. The point, as usual, is to have the expertise and not trust what vendors try to sell you. >> >> Is not just a matter of teaching IPv6. In a training you don?t get the experience. There is a good reason why consultancy companies have a business: it is much cheaper to trust an experienced consultant (vendor independent) than a vendor and you avoid all the mistakes of lack of experience. >> >> Hi Jordi, >> >> 464XLAT is indeed well supported in mobile networks, but saying the main barrier is ?lack of experience? doesn?t match the data. If experience were the decisive factor, operators in high?GDP countries like Spain and Italy ? with large engineering teams and easy access to consultants ? wouldn?t be lagging in APNIC Labs measurements ( https://stats.labs.apnic.net/ipv6/XE). >> >> Yet they are. >> This shows the real issue isn?t consultant scarcity, but operator?level prioritization. IPv6 only moves when the dominant networks decide it matters. >> >> @christianbope >> >> Regards, >> Jordi >> >> @jordipalet >> >> > El 27 jun 2026, a las 20:32, Ben Roberts - AfriNIC via RPD escribi?: >> > >> > Alain, >> > I am with you on this. >> > I was talking about this yesterday with someone. It seems we have been doing the same things with IPv6 capacity building for best part of 15 years and still it?s not really pushing (mass) adoption. Yet we keep doing the same things. ?.. >> > >> > Most Africans connect to the phone via mobile. Manu of them through the ?big 5? of African MNO groups. >> > >> > We need to focus our IPv6 efforts around 5 groups of MNOs plus 4 vendors (2 from China, 2 from Scandinavia). >> > >> > These 9 companies know who they are?. Some of them are represented here?. >> > >> > Then if they start deploying IPv6 then 700M Africans will be using IPv6 >> > >> > The rest will fall into place?. >> > >> > Cheers >> > >> > Ben >> > >> > >> > Sent from my iPhone >> > >> >> On 27 Jun 2026, at 20:52, ALAIN AINA via RPD wrote: >> >> >> >> ? >> >> >> >>> On 26 Jun 2026, at 07:16, Benson Muite wrote: >> >>> >> >>> "jordi.palet--- via RPD" writes: >> >>> >> >>>> Hi Seun, >> >>>> >> >>>> I will actually say personally, the only acceptable X=1, but happy to concede with 2. Hopefully we don?t have a discussion and every participant chose a different number, as this is the typical issue when asking for a decision of ?number of whatever? in trying to reach consensus. >> >>> >> >>> The low adoption rate is worrying. Clear criteria to justify IPv4 >> >>> maybe helpful. If one gets IPv4, IPv6 is free. It is good that Afrinic >> >>> is doing outreach to universities. From Africa Gabon seems to have the >> >>> highest percentage capability: >> >>> https://stats.labs.apnic.net/ipv6 >> >>> India also has good adoption and a diverse set of people in the internet >> >>> industry. Understanding what has lead to adoption in these places may >> >>> help guide whether what new policies sohuld be adopted if any and how to >> >>> complement these with outreach and education activities. >> >> >> >> >> >> A few years ago, I published an analysis of IPv6 uptake in Africa, examining adoption from multiple angles, including infrastructure readiness, operator behaviour, and user?access patterns. One of the key findings was the positive impact of new market entrants, particularly those who deployed IPv6?capable networks from day one. That dynamic remains relevant today. >> >> >> >> Unfortunately, the overall situation has not changed significantly. The user?access layer continues to be the weakest point in the regional IPv6 ecosystem. Given that Africa?s Internet is overwhelmingly mobile?centric, meaningful progress depends on Mobile Internet Service Providers taking deliberate steps to enable IPv6 at scale. Without their participation, adoption will remain slow regardless of improvements elsewhere in the ecosystem. >> >> >> >> There are, however, some recent initiatives underway: >> >> - The ICANN grant to the African Telecommunications Union (ATU) to support IPv6 deployment in 30 African countries is a major development. >> >> - ATU has already published an interim implementation report, outlining early progress and challenges. >> >> >> >> These efforts complement AFRINIC?s ongoing outreach, including engagement with universities and technical communities. >> >> ----- >> >> >> >> https://www.digitalintelligence.africa/publications/alain/AFRICA-and-IPv6-uptake.html >> >> https://www.icann.org/en/grant-program/first-cycle-funded-projects#deployment-ipv6-african-countries >> >> https://atuuat.africa/wp-content/uploads/2026/02/ATU_IPv6_First_Interim_Status_Report_Sep-Dec_2025.pdf >> >> https://atuuat.africa/wp-content/uploads/2022/11/Africa-IPv6-Development-White-Paper_double-page-version.pdf >> >> >> >> >> >> ?Alain >> >> >> >> >> >> >> >> >> >>> >> >>> >> >>>> >> >>>> I will also say that X is only for ?single? allocations/assigments, in the sense that if you are doing something for HA (one of the policies that reached consensus yesterday), you must do it with IPv6. There is no sense that you deploy, today, an HA infrastructure without IPv6. What do you think ? >> >>>> >> >>>> Regards, >> >>>> Jordi >> >>>> >> >>>> @jordipalet >> >>>> >> >>>>> El 25 jun 2026, a las 2:37, Seun Ojedeji escribi?: >> >>>>> >> >>>>> Hi Jordi, >> >>>>> >> >>>>> ---- >> >>>>> Sent from my mobile >> >>>>> kindly excuse typos >> >>>>> >> >>>>> On Wed, 24 Jun 2026, 6:14?pm jordi.palet--- via RPD, > wrote: >> >>>>>> . >> >>>>>> >> >>>>>> So there is no difference in now setting a policy that clearly say, you get more IPv4, but you must also deploy IPv6. >> >>>>>> >> >>>>>> We could also do something slightly different, I?m not sure if this is what Seun tried to say in the mic earlier this afternoon. >> >>>>>> >> >>>>>> We don?t give any more IPv4 resources if you already got them previously. This has been done by most of the other RIRs. Will you agree with that? Only newcomers can get IPv4. >> >>>>> >> >>>>> >> >>>>> SO: More like you don't get IPv4 resources if you already got it for X number of times in the current phase unless you meet the IPv6 deployment plan requirements. My intention is for X not !=Once >> >>>>> >> >>>>> Regards >> >>>>>> >> >>>>>> Now, as a 2nd part of the proposal, resources left (even recovered), can be provided to anyone who also deploy IPv6, regardless of being a newcomer or an existing member. >> >>>>>> >> >>>>>> What do you think? >> >>>>>> >> >>>>>> Regards, >> >>>>>> Jordi >> >>>>>> >> >>>>>> @jordipalet >> >>> >> >>> _______________________________________________ >> >>> RPD mailing list >> >>> RPD at afrinic.net >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> >> >> >> >> _______________________________________________ >> >> RPD mailing list >> >> RPD at afrinic.net >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> > >> > _______________________________________________ >> > RPD mailing list >> > RPD at afrinic.net >> > https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From fundiswanadia2 at gmail.com Mon Jul 13 08:26:50 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Mon, 13 Jul 2026 10:26:50 +0200 Subject: [rpd] IPv6 as a Criterion in IPv4 Soft Landing (AFPUB-2026-v6-001-DRAFT02) Message-ID: Dear colleagues, After following the discussions on the updated proposal and reading the different perspectives shared by the community, I would like to offer my thoughts. Firstly, I fully support the continued growth of IPv6. It is an important part of the Internet's future, and encouraging its adoption is in everyone's interest. My concern, however, is whether the IPv4 Soft Landing policy is the appropriate place to achieve that objective. One issue that stands out to me is the distinction between IPv6 readiness and IPv6 deployment. An operator may be preparing for IPv6, investing in staff training, upgrading infrastructure, or planning deployment in phases. That does not necessarily mean they are ready to meet deployment targets immediately. Different operators face different technical, financial, and operational realities. For this reason, I am concerned that making IPv6 deployment a condition for receiving IPv4 resources may unintentionally create barriers instead of encouraging progress. I also believe policy should remain proportionate to its original purpose. The IPv4 Soft Landing policy exists to manage the remaining IPv4 address space fairly and transparently. If it begins determining how operators should design or prioritise their networks, the role of the registry may gradually expand from neutral coordination into influencing operational decisions. Another point worth considering is implementation. Any policy that introduces deployment requirements should be clear, objective, and easy to assess. If different operators can interpret the requirements differently, or if compliance depends on subjective judgement, uncertainty may increase for members requesting IPv4 resources. The discussion has also highlighted that Africa's Internet ecosystem has unique operational realities. Some networks are well positioned to deploy IPv6 quickly, while others continue to face infrastructure, funding, or market challenges. A regional policy should be flexible enough to recognise those differences rather than assuming every operator is starting from the same position. In my view, IPv6 adoption should continue to be promoted through technical assistance, knowledge sharing, capacity building, and collaboration. Those approaches encourage long-term adoption while allowing operators to implement IPv6 according to their operational circumstances. My recommendation would therefore be to keep the IPv4 Soft Landing policy focused on its original objective of fair IPv4 resource management, while supporting IPv6 growth through education, operational cooperation, and community-led initiatives rather than making deployment an eligibility requirement. Thank you for considering my perspective. Kind regards, Fundiswa Maseko -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Mon Jul 13 11:13:32 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Mon, 13 Jul 2026 13:13:32 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01 Message-ID: Dear colleagues, After following the discussions on the updated proposal and reading the different perspectives shared by the community, I would like to offer my thoughts. Firstly, I fully support the continued growth of IPv6. It is an important part of the Internet's future, and encouraging its adoption is in everyone's interest. My concern, however, is whether the IPv4 Soft Landing policy is the appropriate place to achieve that objective. One issue that stands out to me is the distinction between IPv6 readiness and IPv6 deployment. An operator may be preparing for IPv6, investing in staff training, upgrading infrastructure, or planning deployment in phases. That does not necessarily mean they are ready to meet deployment targets immediately. Different operators face different technical, financial, and operational realities. For this reason, I am concerned that making IPv6 deployment a condition for receiving IPv4 resources may unintentionally create barriers instead of encouraging progress. I also believe policy should remain proportionate to its original purpose. The IPv4 Soft Landing policy exists to manage the remaining IPv4 address space fairly and transparently. If it begins determining how operators should design or prioritise their networks, the role of the registry may gradually expand from neutral coordination into influencing operational decisions. Another point worth considering is implementation. Any policy that introduces deployment requirements should be clear, objective, and easy to assess. If different operators can interpret the requirements differently, or if compliance depends on subjective judgement, uncertainty may increase for members requesting IPv4 resources. The discussion has also highlighted that Africa's Internet ecosystem has unique operational realities. Some networks are well positioned to deploy IPv6 quickly, while others continue to face infrastructure, funding, or market challenges. A regional policy should be flexible enough to recognise those differences rather than assuming every operator is starting from the same position. In my view, IPv6 adoption should continue to be promoted through technical assistance, knowledge sharing, capacity building, and collaboration. Those approaches encourage long-term adoption while allowing operators to implement IPv6 according to their operational circumstances. My recommendation would therefore be to keep the IPv4 Soft Landing policy focused on its original objective of fair IPv4 resource management, while supporting IPv6 growth through education, operational cooperation, and community-led initiatives rather than making deployment an eligibility requirement. Thank you for considering my perspective. Kind regards, Fundiswa Maseko -------------- next part -------------- An HTML attachment was scrubbed... URL: From nndemo at staff.zegu.ac.zw Mon Jul 13 12:54:46 2026 From: nndemo at staff.zegu.ac.zw (Nyasha Ndemo) Date: Mon, 13 Jul 2026 14:54:46 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. Message-ID: Dear PDWG, I agree with Alain's response because it preserves the distinction between Internet number resource coordination and network operations. The objective of the IPv4 Soft Landing policy should be to maintain a fair and predictable framework for managing IPv4 resources, not to influence how operators choose to deploy IPv6 within their networks. I also agree that IPv6 readiness should not be confused with IPv6 deployment. Operators must make deployment decisions based on operational requirements, customer demand, commercial realities, and the maturity of their infrastructure. These are matters of running networks, where practical experience should take precedence over policy mandates. Encouraging IPv6 adoption remains important, but it is more likely to succeed through voluntary adoption, technical collaboration, capacity building, and the sharing of implementation experience than through eligibility requirements for IPv4 allocations. Policies are most effective when they remain focused on their core coordination function and avoid expanding into areas that are better addressed through operational and technical forums. For these reasons, I support Alain's view that the IPv4 Soft Landing policy should remain technically neutral, focused on resource coordination, and respectful of the diverse operational realities across the AFRINIC service region. Best Regards, Dr. Nyasha Ndemo-Masimbarasi (DPhil, MSc., BSc. Hon. Development Science and Policy) Chairperson - Department of Development Programming and Management Zimbabwe Ezekiel Guti University 1901 Barrassie Rd, Off Shamva Rd, Bindura Zimbabwe Landline: +263867 700 6136 Cell: +263 773226552 Email: nyashandemo at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mxolisi at igd.org.za Mon Jul 13 14:10:02 2026 From: Mxolisi at igd.org.za (Mxolisi Nomdletshe) Date: Mon, 13 Jul 2026 16:10:02 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01 Message-ID: <5c1fb639346488497c9925d279bfe821@igd.org.za> Dear PDWG, I agree with Alain because the discussion should remain focused on the core purpose of the IPv4 Soft Landing policy: Internet number resource coordination, not operational decision-making. A registry policy should remain a thin coordination layer, ensuring fair and predictable resource management, rather than expanding into areas that are better determined by network operators. Of course, it is tempting to transition to IPv6, considering the perks it offers. If we are to be rational, everyone would definitely appreciate the fact that IPv6 presents them with streamlined packet headers that allow routers to process traffic faster and prioritize tasks that are data heavy. Reality however is that businesses find IPv4 sufficient for their everyday operations. This then means it remains unnecessary for them to undergo the expensive transition to IPv6. We also need to agree to draw distinction between IPv6 deployment and IPv6 readiness. Operators understand the realities of their running networks, including infrastructure constraints, customer demand, investment cycles, and business priorities. These operational decisions are best driven by technical implementation and practical experience, not by policy conditions attached to IPv4 eligibility. IPv6 adoption is undoubtedly important, but lasting progress is more likely to come through voluntary adoption, technical collaboration, capacity building, and operational knowledge sharing than through registry-imposed requirements. Policies should protect operational continuity, remain technically neutral, and avoid introducing conditions that extend beyond the registry's coordination function. For these reasons, I support Alain's view that IPv4 Soft Landing should remain focused on resource coordination while allowing operators the flexibility to determine the most appropriate path for IPv6 deployment within their own networks. Regards -- Mxolisi Nomdletshe Research Assistant Institute For Global Dialogue Cell no: 0684264698 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nndemo at staff.zegu.ac.zw Mon Jul 13 15:11:23 2026 From: nndemo at staff.zegu.ac.zw (Nyasha Ndemo) Date: Mon, 13 Jul 2026 17:11:23 +0200 Subject: [rpd] Fwd: IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: Message-ID: Dr. Nyasha Ndemo-Masimbarasi (DPhil, MSc., BSc. Hon. Development Science and Policy) Chairperson - Department of Development Programming and Management Zimbabwe Ezekiel Guti University 1901 Barrassie Rd, Off Shamva Rd, Bindura Zimbabwe Landline: +263867 700 6136 Cell: +263 773226552 Email: nyashandemo at gmail.com ---------- Forwarded message --------- From: Nyasha Ndemo Date: Mon, Jul 13, 2026, 2:54?PM Subject: IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. To: Cc: , Dear PDWG, I agree with Alain's response because it preserves the distinction between Internet number resource coordination and network operations. The objective of the IPv4 Soft Landing policy should be to maintain a fair and predictable framework for managing IPv4 resources, not to influence how operators choose to deploy IPv6 within their networks. I also agree that IPv6 readiness should not be confused with IPv6 deployment. Operators must make deployment decisions based on operational requirements, customer demand, commercial realities, and the maturity of their infrastructure. These are matters of running networks, where practical experience should take precedence over policy mandates. Encouraging IPv6 adoption remains important, but it is more likely to succeed through voluntary adoption, technical collaboration, capacity building, and the sharing of implementation experience than through eligibility requirements for IPv4 allocations. Policies are most effective when they remain focused on their core coordination function and avoid expanding into areas that are better addressed through operational and technical forums. For these reasons, I support Alain's view that the IPv4 Soft Landing policy should remain technically neutral, focused on resource coordination, and respectful of the diverse operational realities across the AFRINIC service region. Best Regards, Dr. Nyasha Ndemo-Masimbarasi (DPhil, MSc., BSc. Hon. Development Science and Policy) Chairperson - Department of Development Programming and Management Zimbabwe Ezekiel Guti University 1901 Barrassie Rd, Off Shamva Rd, Bindura Zimbabwe Landline: +263867 700 6136 Cell: +263 773226552 Email: nyashandemo at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From NGBSIM008 at myuct.ac.za Mon Jul 13 15:42:14 2026 From: NGBSIM008 at myuct.ac.za (Simphiwe Ngubane) Date: Mon, 13 Jul 2026 15:42:14 +0000 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. Message-ID: Dear PDWG, I agree with Alain?s response because it maintains a necessary distinction between the role of registry policy and the realities of network operations. The purpose of the IPv4 Soft Landing policy should remain centered on the coordination and management of scarce Internet number resources, rather than introducing operational conditions tied to IPv6 deployment. I also agree that IPv6 adoption across the region cannot be measured only through deployment statistics. Many operators may already be investing in infrastructure upgrades, staff training, network planning, and transition readiness, even where large-scale IPv6 traffic is not yet visible. Deployment decisions are influenced by operational readiness, commercial priorities, customer demand, equipment lifecycles, and local market conditions, all of which vary significantly across the AFRINIC service region. Importantly, the IPv4 Soft Landing policy was developed to address IPv4 scarcity and allocation management. While IPv6 adoption remains an important objective for the long-term sustainability of the Internet, using IPv4 allocation policy as a mechanism to drive deployment risks combining two distinct policy goals. Resource coordination and technology adoption are related, but they are not the same function. In my view, policies work best when they remain focused on their narrow coordination purpose while allowing operators the flexibility to determine the most practical technical path for their networks. Linking IPv4 eligibility to IPv6 deployment could unintentionally disadvantage smaller or resource-constrained operators that are actively preparing for transition but are not yet in a position to deploy at scale. Encouraging IPv6 through technical cooperation, implementation experience, training, knowledge sharing, and operational forums is likely to produce more sustainable progress than introducing deployment requirements into resource management policies. Long-term IPv6 success depends on the readiness of the broader ecosystem, including network operators, vendors, content providers, transit providers, and end-user environments. For these reasons, I support keeping the IPv4 Soft Landing policy technically neutral, operationally realistic, and aligned with the diverse needs of networks across the AFRINIC region. RIRs are most effective when they remain neutral coordinators of Internet number resources while enabling, rather than prescribing, the evolution of network technologies. Yours Sincerely, Simphiwe Ngubane MSc in Engineering UCT (My views are my own in given in my personal capacity and do not form part of any affiliation or representation to the University of Cape Town) Disclaimer - University of Cape Town This email is subject to UCT policies and email disclaimer published on our website at https://www.uct.ac.za/main/email-disclaimer or obtainable from +27 21 650 9111. If this email is not related to the business of UCT, it is sent by the sender in an individual capacity. Please report security incidents or abuse via https://csirt.uct.ac.za/report-incident -------------- next part -------------- An HTML attachment was scrubbed... URL: From asamkele.menzeleli18 at maharishinstitute.org Mon Jul 13 16:07:46 2026 From: asamkele.menzeleli18 at maharishinstitute.org (Asamkele Menzeleli) Date: Mon, 13 Jul 2026 18:07:46 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01 Message-ID: Dear Jordi and colleagues, Thank you for taking the time to explain the operational realities of large-scale IPv6 deployments. There is no question that practical deployment experience is extremely valuable, particularly for operators beginning their IPv6 journey. However, I wonder whether this discussion risks equating IPv6 deployment with responsible stewardship of Internet number resources. Should an operator's eligibility under IPv4 Soft Landing really be judged by the extent of its IPv6 deployment? Or should it instead be measured by how responsibly it manages and justifies its IPv4 resources? These seem to be fundamentally different objectives. One concerns network architecture. The other concerns resource governance. If the purpose of Soft Landing is to ensure the responsible management of scarce IPv4 resources, perhaps the policy should remain focused on that objective alone. Introducing IPv6 deployment as an assessment criterion inevitably raises further questions. Who decides what level of IPv6 deployment is sufficient? Would different deployment models receive different treatment? Would operators serving challenging environments be placed at a disadvantage despite managing their IPv4 resources responsibly? I also believe this presents an opportunity for a broader governance discussion. Rather than introducing additional behavioural criteria, should we instead be strengthening operator rights through clearer portability provisions, stronger continuity protections and meaningful exit rights? Those reforms would benefit every operator, regardless of whether their network is predominantly IPv4, dual-stack or IPv6. Jordi, I would be interested in your thoughts on whether governance reforms of this nature might produce more durable outcomes than linking IPv4 policy to protocol adoption. Thank you for the discussion. Kind regards, Asamkele Menzeleli "IPv4 deserves neutral governance" -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah at neo.co.tz Mon Jul 13 16:21:06 2026 From: noah at neo.co.tz (Noah) Date: Mon, 13 Jul 2026 19:21:06 +0300 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 In-Reply-To: <1783459420709.11832@tra.gov.eg> References: <1783459420709.11832@tra.gov.eg> Message-ID: To the PDWG, How do we invension the current IPv4 inventory will look like by 2030 in terms of IPv4 address space managed directly by AFRINIC? Suppose the current existing inventory is completely depleted and whatever is recoved be allocated beyond 2030. Do we envision a future where IPv4 brokers/traders step in to trade IPv4 addresses which have been hoarded in inticipation that there will be existance of future scarcity which will create an IPv4 market considering a potential demand for IPv4 post softlanding? Do we envision a future where IPv6 transitioning is potentially further delayed due to a prolonged artificial market place for IPv4 addresses? Is a policy with a clear problem statement that could encourage IPv6 transition within the limits and realities of scarce IPv4 addresses make sense for the PDWG? Does the authors assumptions nonetheless make some sense? Cheers, *.**/noah* On Wed, 8 Jul 2026, 12:34?am Hytham El-Nakhal, wrote: > Dear PDWG, > > > I have noticed some mails from community members regarding the policy > proposal "IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01". > > > The author has updated the proposal (DRAFT02), and it was discussed during > the AFRINIC-37 PPM on 24th June 2026. > > > The updated proposal is attached to this email to bring you up to speed > with its contents [pending the re-establishment of the AFRINIC website by > COB 8th July as communicated by AFRINIC]. > > The updated proposal did not reach consensus at the AFRINIC-37 PPM and was > sent back to the RPD mailing-list for further discussions. > > > Those who missed the discussions still have access the AF-37 PPM > proceedings here: https://www.youtube.com/watch?v=uwjG1_XwKV8 . > > > Therefore, it is highly recommended that participants thoroughly review > the attached proposal, familiarize themselves with prior discussions on the > mailing list and during the Public Policy Meeting, and subsequently focus > their valuable contribution by undertaking any of the following actions: > > * - Seek clarifications regarding the policy text and offer > recommendations for its improvement; > * - Express formal support for the proposal; or, > * - Provide a detailed justification in case of opposition to the > policy as drafted. > > > Best Regards, > Haitham el Nakhal > PDWG Co-Chair > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah at neo.co.tz Mon Jul 13 18:21:18 2026 From: noah at neo.co.tz (Noah) Date: Mon, 13 Jul 2026 21:21:18 +0300 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: <424D5D46-AA0D-411D-A26D-743C59BE2F25@trstech.net> References: <497AC0C6-09CF-4FE3-A6F9-B32690413A71@afrinic.net> <84082285-459A-4843-9C4A-3D201E083840@consulintel.es> <424D5D46-AA0D-411D-A26D-743C59BE2F25@trstech.net> Message-ID: To the PDWG I have raised some questions in another thread. I also wanted to add another grounding question. Who will measure compliance and how will it be done since the rest of the mechanism depends on that. Answers can help guide the WG to define a clear problem statement because I think the author has something going but we need to define it further. Cheers, *.**/noah* On Sat, 11 Jul 2026, 8:04?pm ALAIN AINA via RPD, wrote: > Hi PDWG > > Much has already been said about why this proposal and its variants are > not suitable for our region. It is tempting to shift the discussion from > ?IPv6 as a criterion in IPv4 Soft Landing AFPUB?2026?v6?001?DRAFT02? to > broader IPv6 deployment topics, but that belongs in operational fora such > as AFNOG, not in the PDWG. > > We should clearly distinguish IPv6 readiness from IPv6 deployment. Many > operators may have improved readiness but are not yet in a position to roll > out IPv6 to end?users. PDWG cannot dictate operational practices. > > 5G is indeed a strong enabler for IPv6 rollout among MNOs. As 5G expands > in the region, IPv6 adoption will naturally increase. This aligns with > global trends in 5G IPv6 behavior compared to 4G IPv6 behavior. But again, > this is an operational evolution; not a policy lever. > > Regarding IPv6 performance over IPv4, APNIC Labs data (RTT comparison > v6/v4, IPv6 TCP failure rate, IPv6 fragmentation drop rates) shows > improvement, but also shows persistent and significant gaps. We should > avoid excessive euphoria. The data does not support the idea that IPv6 > performance is uniformly strong enough to justify using it as a gating > criterion for IPv4 access. > > On CGN vs IPv6?only + 464XLAT: in this region, operators are not > ?investing? in CGN today. CGN was built into their architecture from the > beginning, and many secured IPv4 space before Soft Landing or during Soft > Landing phase 1. The cost?comparison argument simply does not apply > uniformly here, and cannot be used as justification for policy changes. > > IPv6 adoption should be encouraged through experience sharing, showcases, > and lessons learned, not through policy mechanisms that attempt to enforce > operational practices. > > We have also been here before. During the 2016?2018 discussions to amend > Soft Landing, similar attempts were made to impose IPv6 deployment and > later IPv6 resource requirements as pre?conditions for IPv4 requests, or to > create a dedicated reserve of IPv4 to ?facilitate? IPv6 deployment(1). At > that time, global IPv6 deployment was around 25%, and only one country in > Africa exceeded 5%. The archives(2) are explicit. > > Let?s keep IPv6 adoption discussions active, but separate them entirely > from IPv4 Soft Landing policy, which must remain operationally neutral, > technically realistic, and region?appropriate. > > (1) > https://web.archive.org/web/20260411113239/https://afrinic.net/policy/2016-v4-001-d7?lang=en#proposal > (2) https://lists.afrinic.net/pipermail/rpd/2018/thread.html#8214 > > HTH > > ?Alain > > > On 6 Jul 2026, at 08:41, jordi.palet--- via RPD wrote: > > > > Hi Christian, > > > > Yes, that?s true as well, but the difference is that those operators > (for example the case of Spain, which I know very well), aren?t in a hurry > for IPv6 deployment, because: > > 1) They already invested long time ago in getting more IPv4 addressed > that they need, indirectly via M&A. Several of them have extra IPv4 > addresses. > > 2) Some times they also invested in CGN boxes (specially in mobile > networks). > > > > In the specific case of Spain, I did consultancy for all the major > operators already in 2011-2013 time frame. I?ve even worked with some of > them in 2002. So I know very well the situation and specific rationales. > Note also that 464XLAT was not available at that time. For me is a shame > that IPv6 deployment in my own country is not progressing as well as it > should be. We say here (free translation, I?m sure you have an equivalent > sentence): ?you can?t be a prophet in your own land?. > > > > The main difference here is that many operators in Africa haven?t > sufficient IPv4 addresses, so what we are proposing is, instead of > investing in CGN with is a bad solution in the long term, you can invest in > IPv6 deployment. It is easy to demonstrate that it is actually much > cheaper. 464XLAT needs much less IPv4 addresses (for the PLAT IPv4 pool) > than CGN (NAT444). In addition to that, IPv4 pools in CGN (NAT444) when > detected by some service provider, such as Sony Network Play Station, get > blocked in a black-list which is never cleaned, so you get an IPv4 block > (or you already have it), and becomes useless if you have gammers (is an > example, it happens with other services) in your network. > > > > RFC > > > > Regards, > > Jordi > > > > @jordipalet > > > >> El 5 jul 2026, a las 12:26, Bope Domilongo Christian < > christianbope at gmail.com> escribi?: > >> > >> > >> > >> On Sun, 28 Jun 2026 at 11:16, jordi.palet--- via RPD > wrote: > >> Fortunately, deploying 464XLAT in mobile networks (the only way to go) > is much easier and cheaper than in wireline. Vendors of both UEs and packet > switch mobile networks support it very well since many years ago. The > point, as usual, is to have the expertise and not trust what vendors try to > sell you. > >> > >> Is not just a matter of teaching IPv6. In a training you don?t get the > experience. There is a good reason why consultancy companies have a > business: it is much cheaper to trust an experienced consultant (vendor > independent) than a vendor and you avoid all the mistakes of lack of > experience. > >> > >> Hi Jordi, > >> > >> 464XLAT is indeed well supported in mobile networks, but saying the > main barrier is ?lack of experience? doesn?t match the data. If experience > were the decisive factor, operators in high?GDP countries like Spain and > Italy ? with large engineering teams and easy access to consultants ? > wouldn?t be lagging in APNIC Labs measurements ( > https://stats.labs.apnic.net/ipv6/XE). > >> > >> Yet they are. > >> This shows the real issue isn?t consultant scarcity, but operator?level > prioritization. IPv6 only moves when the dominant networks decide it > matters. > >> > >> @christianbope > >> > >> Regards, > >> Jordi > >> > >> @jordipalet > >> > >> > El 27 jun 2026, a las 20:32, Ben Roberts - AfriNIC via RPD < > rpd at afrinic.net> escribi?: > >> > > >> > Alain, > >> > I am with you on this. > >> > I was talking about this yesterday with someone. It seems we have > been doing the same things with IPv6 capacity building for best part of 15 > years and still it?s not really pushing (mass) adoption. Yet we keep doing > the same things. ?.. > >> > > >> > Most Africans connect to the phone via mobile. Manu of them through > the ?big 5? of African MNO groups. > >> > > >> > We need to focus our IPv6 efforts around 5 groups of MNOs plus 4 > vendors (2 from China, 2 from Scandinavia). > >> > > >> > These 9 companies know who they are?. Some of them are represented > here?. > >> > > >> > Then if they start deploying IPv6 then 700M Africans will be using > IPv6 > >> > > >> > The rest will fall into place?. > >> > > >> > Cheers > >> > > >> > Ben > >> > > >> > > >> > Sent from my iPhone > >> > > >> >> On 27 Jun 2026, at 20:52, ALAIN AINA via RPD > wrote: > >> >> > >> >> ? > >> >> > >> >>> On 26 Jun 2026, at 07:16, Benson Muite > wrote: > >> >>> > >> >>> "jordi.palet--- via RPD" writes: > >> >>> > >> >>>> Hi Seun, > >> >>>> > >> >>>> I will actually say personally, the only acceptable X=1, but happy > to concede with 2. Hopefully we don?t have a discussion and every > participant chose a different number, as this is the typical issue when > asking for a decision of ?number of whatever? in trying to reach consensus. > >> >>> > >> >>> The low adoption rate is worrying. Clear criteria to justify IPv4 > >> >>> maybe helpful. If one gets IPv4, IPv6 is free. It is good that > Afrinic > >> >>> is doing outreach to universities. From Africa Gabon seems to have > the > >> >>> highest percentage capability: > >> >>> https://stats.labs.apnic.net/ipv6 > >> >>> India also has good adoption and a diverse set of people in the > internet > >> >>> industry. Understanding what has lead to adoption in these places > may > >> >>> help guide whether what new policies sohuld be adopted if any and > how to > >> >>> complement these with outreach and education activities. > >> >> > >> >> > >> >> A few years ago, I published an analysis of IPv6 uptake in Africa, > examining adoption from multiple angles, including infrastructure > readiness, operator behaviour, and user?access patterns. One of the key > findings was the positive impact of new market entrants, particularly those > who deployed IPv6?capable networks from day one. That dynamic remains > relevant today. > >> >> > >> >> Unfortunately, the overall situation has not changed significantly. > The user?access layer continues to be the weakest point in the regional > IPv6 ecosystem. Given that Africa?s Internet is overwhelmingly > mobile?centric, meaningful progress depends on Mobile Internet Service > Providers taking deliberate steps to enable IPv6 at scale. Without their > participation, adoption will remain slow regardless of improvements > elsewhere in the ecosystem. > >> >> > >> >> There are, however, some recent initiatives underway: > >> >> - The ICANN grant to the African Telecommunications Union (ATU) to > support IPv6 deployment in 30 African countries is a major development. > >> >> - ATU has already published an interim implementation report, > outlining early progress and challenges. > >> >> > >> >> These efforts complement AFRINIC?s ongoing outreach, including > engagement with universities and technical communities. > >> >> ----- > >> >> > >> >> > https://www.digitalintelligence.africa/publications/alain/AFRICA-and-IPv6-uptake.html > >> >> > https://www.icann.org/en/grant-program/first-cycle-funded-projects#deployment-ipv6-african-countries > >> >> > https://atuuat.africa/wp-content/uploads/2026/02/ATU_IPv6_First_Interim_Status_Report_Sep-Dec_2025.pdf > >> >> > https://atuuat.africa/wp-content/uploads/2022/11/Africa-IPv6-Development-White-Paper_double-page-version.pdf > >> >> > >> >> > >> >> ?Alain > >> >> > >> >> > >> >> > >> >> > >> >>> > >> >>> > >> >>>> > >> >>>> I will also say that X is only for ?single? > allocations/assigments, in the sense that if you are doing something for HA > (one of the policies that reached consensus yesterday), you must do it with > IPv6. There is no sense that you deploy, today, an HA infrastructure > without IPv6. What do you think ? > >> >>>> > >> >>>> Regards, > >> >>>> Jordi > >> >>>> > >> >>>> @jordipalet > >> >>>> > >> >>>>> El 25 jun 2026, a las 2:37, Seun Ojedeji > escribi?: > >> >>>>> > >> >>>>> Hi Jordi, > >> >>>>> > >> >>>>> ---- > >> >>>>> Sent from my mobile > >> >>>>> kindly excuse typos > >> >>>>> > >> >>>>> On Wed, 24 Jun 2026, 6:14?pm jordi.palet--- via RPD, < > rpd at afrinic.net > wrote: > >> >>>>>> . > >> >>>>>> > >> >>>>>> So there is no difference in now setting a policy that clearly > say, you get more IPv4, but you must also deploy IPv6. > >> >>>>>> > >> >>>>>> We could also do something slightly different, I?m not sure if > this is what Seun tried to say in the mic earlier this afternoon. > >> >>>>>> > >> >>>>>> We don?t give any more IPv4 resources if you already got them > previously. This has been done by most of the other RIRs. Will you agree > with that? Only newcomers can get IPv4. > >> >>>>> > >> >>>>> > >> >>>>> SO: More like you don't get IPv4 resources if you already got it > for X number of times in the current phase unless you meet the IPv6 > deployment plan requirements. My intention is for X not !=Once > >> >>>>> > >> >>>>> Regards > >> >>>>>> > >> >>>>>> Now, as a 2nd part of the proposal, resources left (even > recovered), can be provided to anyone who also deploy IPv6, regardless of > being a newcomer or an existing member. > >> >>>>>> > >> >>>>>> What do you think? > >> >>>>>> > >> >>>>>> Regards, > >> >>>>>> Jordi > >> >>>>>> > >> >>>>>> @jordipalet > >> >>> > >> >>> _______________________________________________ > >> >>> RPD mailing list > >> >>> RPD at afrinic.net > >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> > >> >> > >> >> > >> >> _______________________________________________ > >> >> RPD mailing list > >> >> RPD at afrinic.net > >> >> https://lists.afrinic.net/mailman/listinfo/rpd > >> > > >> > _______________________________________________ > >> > RPD mailing list > >> > RPD at afrinic.net > >> > https://lists.afrinic.net/mailman/listinfo/rpd > >> > >> > >> ********************************************** > >> IPv4 is over > >> Are you ready for the new Internet ? > >> http://www.theipv6company.com > >> The IPv6 Company > >> > >> This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > >> > >> > >> > >> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.theipv6company.com > > The IPv6 Company > > > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Tue Jul 14 08:09:21 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Tue, 14 Jul 2026 10:09:21 +0200 Subject: [rpd] Confirmation of the 3mil recovered space? Re: Promoting IPv6 adoption In-Reply-To: <1B962FF9-82EF-4F8D-BF0A-838EABF2C5C1@consulintel.es> References: <7B0B99DF-A2DE-4F7C-9D11-83221919F526@afrinic.net> <1B962FF9-82EF-4F8D-BF0A-838EABF2C5C1@consulintel.es> Message-ID: <6AC6401E-04B8-42D5-BFF5-A59CFCA0086A@hevis.co.za> On 28 May 2026, at 17:27, jordi.palet--- via RPD wrote: > Note that Afrinic recovered 3.000.000 of address, Has this been ?published? and are public knowledge? When are those expected to become ?active? and distributable? Seems that places like https://ipv6.he.net/statistics/ still only shows 1mil (~4000 x /24s, or 1000x /22s), ~75 /22 per African Country left. In the ?bigger? IPv4 vs IPv6 allocation scheme, these are the numbers to consider and debate/work on: How are we going to ?evenly and equitably? distribute those IP blocks across the Africa countries? Perhaps the questions might need to be asked: Instead of adding IPv6 targets, what about allocate the remainder to the ~50 African Countries, based on some inverse of historical allocation based scheme? ie. if country X has eg. 10x /24 IPv4 blocks per million inhabitants, and , Country Y only has 2x /24 per million users, how would we reserve /24 blocks for those two countries? 1x for Country X and 5x for Country Y ? or just say 75x /24s per country? The next question that I believe is the elephant in the room: Are we trying to assist/reserve resources to get internet rolled out to under served areas and countries, or still playing the Voldemort game of chess on a checkers board by seeing ?Intellectual Property?/?Commodity Value? of IPv4s? If we are playing the latter, then I?d say: Put ALL the IPv4s (as /24s :)=) ) on AUCTION - caveat: The price you bid is the price you?ll pay per year for the lifetime you have that resource allocated to you, even if newer price ?drops? gets implemented on other resources? If we are looking at reserving for future country roll outs, then we should rather enter a hard land phase and say: This is the resource allocation per country - period, and if a country?s allocation runs out, that was it, sorry, no more for you country (and than Voldemort can be contacted) - I am staying a a country that the above allocation (or even the 75x /22s) will run out the fastest, and will complain the loudest. See IPv6 roll out will *have* to be a financial decision, as many others (Like Jaco Kroon - that feels the same like me about the needs and benefits os IPv6 roll out, but are experiencing the client/customer push backs) have stated that AfriNIC as such can?t ?legislate? IPv6 (we can only lobby Countries to consider that) and even though I agree with the idea of forcing IPv6 usage before giving out IPv4s, I have to admit: AfriNIC can?t really police that as a policy. --- 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: From ben.roberts at afrinic.net Tue Jul 14 09:44:44 2026 From: ben.roberts at afrinic.net (ben.roberts@frinic.net) Date: Tue, 14 Jul 2026 12:44:44 +0300 Subject: [rpd] Confirmation of the 3mil recovered space? Re: Promoting IPv6 adoption In-Reply-To: <6AC6401E-04B8-42D5-BFF5-A59CFCA0086A@hevis.co.za> References: <7B0B99DF-A2DE-4F7C-9D11-83221919F526@afrinic.net> <1B962FF9-82EF-4F8D-BF0A-838EABF2C5C1@consulintel.es>, <6AC6401E-04B8-42D5-BFF5-A59CFCA0086A@hevis.co.za> Message-ID: <464D1BB3-F702-3543-BB6C-026EE83170CC@hxcore.ol> An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Tue Jul 14 10:02:41 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Tue, 14 Jul 2026 12:02:41 +0200 Subject: [rpd] Confirmation of the 3mil recovered space? Re: Promoting IPv6 adoption In-Reply-To: <464D1BB3-F702-3543-BB6C-026EE83170CC@hxcore.ol> References: <7B0B99DF-A2DE-4F7C-9D11-83221919F526@afrinic.net> <1B962FF9-82EF-4F8D-BF0A-838EABF2C5C1@consulintel.es> <6AC6401E-04B8-42D5-BFF5-A59CFCA0086A@hevis.co.za> <464D1BB3-F702-3543-BB6C-026EE83170CC@hxcore.ol> Message-ID: Thank you Ben! On 14 Jul 2026, at 11:44, ben.roberts at frinic.net wrote: > Hendrik, > > In case you havent seen it, I share again my publication on this matter of countries usage per capita. https://www.digitaleconomy.ke/post/ipv4-address-allocation-in-africa-are-you-above-or-below-the-ip-address-poverty-line this, in short, makes a great case for a rather HARD LANDING for AfriNIC is IPv4 resource allocations to only the ?IPv4 poor? countries given their per capita current allocation. Doesn?t it? Yes, Voldemorts might like a hard landing, but I am of the opinion that, should the consensus/direction/etc. be to further Internet reach (and by extension IPv4 allocations) in those IPv4 poor regions, the logical (Spock speaking) conclusion would be to initiate hard landing(s) for the IPv4 ?rich? (per capita) countries. From fundiswanadia2 at gmail.com Tue Jul 14 14:57:33 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Tue, 14 Jul 2026 16:57:33 +0200 Subject: [rpd] Confirmation of the 3mil Recovered Space? Re: Promoting IPv6 Adoption Message-ID: Dear Colleagues, This discussion raises an important governance question beyond IPv6 deployment: what principles should guide the allocation of AFRINIC's remaining IPv4 resources? If the objective of the Soft Landing policy is to manage scarcity fairly, then transparency and equitable distribution should remain central considerations. The community should clearly establish whether the remaining IPv4 pool is intended to maximise Internet growth in underserved regions, maintain fairness among all members, or balance both objectives. The suggestion to examine historical allocation disparities is valuable because it shifts the discussion from technology requirements to resource governance. However, any approach based on geography or per-capita distribution would also need to remain consistent with the principles of fairness, neutrality, and the established Policy Development Process. In my view, the discussion demonstrates that AFRINIC's role is not to determine operational choices, but to ensure that scarce Internet number resources are managed through transparent, objective, and community-developed policies that benefit the region as a whole. Best Regards, Fundiswa Nadia Maseko -------------- next part -------------- An HTML attachment was scrubbed... URL: From mselekuthandeka80 at gmail.com Wed Jul 15 13:09:54 2026 From: mselekuthandeka80 at gmail.com (Thandeka Mseleku) Date: Wed, 15 Jul 2026 15:09:54 +0200 Subject: [rpd] Confirmation of the 3mil Recovered Space? Re: Promoting IPv6 Adoption Message-ID: Dear Colleagues, Thank you, Fundiswa, for raising these important governance considerations. I agree that transparency, neutrality, and fairness should remain at the core of decisions concerning AFRINIC's remaining IPv4 resources. As IPv4 continues to support many operational networks across the region, it is important that allocation policies remain objective and proportionate to members' legitimate needs. While promoting IPv6 adoption is an important long-term objective, I believe this should not diminish the need for sound governance of IPv4 resources. A balanced approach that protects equitable access to IPv4 while encouraging IPv6 deployment will contribute to a stronger and more credible policy development process. I look forward to the continued discussion. BR, Thandeka Mseleku -------------- next part -------------- An HTML attachment was scrubbed... URL: From hytham at tra.gov.eg Thu Jul 16 22:08:10 2026 From: hytham at tra.gov.eg (Hytham El-Nakhal) Date: Thu, 16 Jul 2026 22:08:10 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal- Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT02 Message-ID: <1784239690230.54504@tra.gov.eg> Dear PDWG, Last Call: Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) The Policy Development Working Group (PDWG )Chairs have initiated a Last Call for this proposal, following rough consensus at the AFRINIC-37 Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. * Proposal Name: Amendment of Utilisation in Soft Landing * Proposal ID: AFPUB-2026-IPv4-002-DRAFT02 * Proposal URL: https://www.afrinic.net/afpub-2026-ipv4-002-draft02.html . Last Call closes on : July 31, 2026, at 23:59 UTC. The Secretariat will provide an operational definition of "utilisation" during this period to assist with final community review. As always, we kindly request that all participants adhere to the AFRINIC Code of Conduct to maintain a respectful and professional environment on the mailing list. Kind regards, Haitham el Nakhal AFRINIC PDWG Co-Chair From hytham at tra.gov.eg Thu Jul 16 22:08:49 2026 From: hytham at tra.gov.eg (Hytham El-Nakhal) Date: Thu, 16 Jul 2026 22:08:49 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Soft Landing, Recovered Space and Priority (AFPUB-2026-IPv4-001-DRAFT02) Message-ID: <1784239728924.52164@tra.gov.eg> Dear PDWG, The Policy Development Working Group (PDWG )Chairs have initiated a Last Call for this proposal, following rough consensus at the AFRINIC-37 Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. Proposal Details: * Proposal Name: Soft Landing, Recovered Space and Priority * Proposal ID: AFPUB-2026-IPv4-001-DRAFT02 * Proposal URL: https://www.afrinic.net/afpub-2026-ipv4-001-draft02.html Last Call will close on : July 31, 2026, at 23:59 UTC. The Secretariat will provide information on the resource recovery process during this period to assist with final community review. As always, we kindly request that all participants adhere to the AFRINIC Code of Conduct to maintain a respectful and professional environment on the mailing list. Kind Regards, Haitham el Nakhal AFRINIC PDWG Co-Chair From hytham at tra.gov.eg Thu Jul 16 22:09:48 2026 From: hytham at tra.gov.eg (Hytham El-Nakhal) Date: Thu, 16 Jul 2026 22:09:48 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: <1784239787450.20999@tra.gov.eg> Dear PDWG, The Policy Development Working Group (PDWG) Chairs have initiated a Last Call for this proposal, following rough consensus at the AFRINIC-37 Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. * Proposal Name: Hierarchical Names for New AS-SETs * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 * Proposal URL: https://www.afrinic.net/afpub-2026-asn-001-draft02.html Last Call closes on: July 31, 2026, at 23:59 UTC. 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. As always, we kindly request that all participants adhere to the AFRINIC Code of Conduct to maintain a respectful and professional environment on the mailing list. Kind regards, Haitham el Nakhal AFRINIC PDWG Co-Chair From james at inter.link Fri Jul 17 07:13:05 2026 From: james at inter.link (James Bensley) Date: Fri, 17 Jul 2026 07:13:05 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <1784239787450.20999@tra.gov.eg> References: <1784239787450.20999@tra.gov.eg> Message-ID: Dear PDWG, I support the adoption of this proposal. Full disclosure: I am the original author. With kind regards, James Bensley (he/him) ________________________________ From: Hytham El-Nakhal Sent: 17 July 2026 00:09 To: rpd at afrinic.net Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) ?? Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. Dear PDWG, The Policy Development Working Group (PDWG) Chairs have initiated a Last Call for this proposal, following rough consensus at the AFRINIC-37 Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. * Proposal Name: Hierarchical Names for New AS-SETs * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 * Proposal URL: https://www.afrinic.net/afpub-2026-asn-001-draft02.html Last Call closes on: July 31, 2026, at 23:59 UTC. 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. As always, we kindly request that all participants adhere to the AFRINIC Code of Conduct to maintain a respectful and professional environment on the mailing list. Kind regards, Haitham el Nakhal AFRINIC PDWG Co-Chair _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd [CompanySignature] Inter..link GmbH | Boxhagener Stra?e 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello at inter.link | Web: inter.link -------------- next part -------------- An HTML attachment was scrubbed... URL: From geier at geier.ne.tz Fri Jul 17 07:19:32 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Fri, 17 Jul 2026 10:19:32 +0300 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <1784239787450.20999@tra.gov.eg> References: <1784239787450.20999@tra.gov.eg> Message-ID: <61376605-1e0a-472e-b5e8-0dad0272b388@geier.ne.tz> Dear all, I support adoption and implementation of this proposal. Regards, Frank Habicht AS37084 On 7/17/2026 1:09 AM, Hytham El-Nakhal wrote: > Dear PDWG, > > > The Policy Development Working Group (PDWG) Chairs have initiated a Last Call for this proposal, following rough consensus at the AFRINIC-37 Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. > > * Proposal Name: Hierarchical Names for New AS-SETs > > * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > > * Proposal URL: https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > Last Call closes on: July 31, 2026, at 23:59 UTC. > > > 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. > > > As always, we kindly request that all participants adhere to the AFRINIC Code of Conduct to maintain a respectful and professional environment on the mailing list. > > > Kind regards, > > > Haitham el Nakhal > > AFRINIC PDWG Co-Chair > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From mselekuthandeka80 at gmail.com Fri Jul 17 08:25:09 2026 From: mselekuthandeka80 at gmail.com (Thandeka Mseleku) Date: Fri, 17 Jul 2026 10:25:09 +0200 Subject: [rpd] IPv6 as a Criteria in IPv4 Soft Landing Message-ID: Dear Colleagues, I support the view that the remaining IPv4 resources should continue to be managed through policies that are transparent, objective, and fair to all members of the AFRINIC community. While IPv6 adoption remains an important long-term objective, IPv4 continues to play a critical operational role for many networks across the region. For this reason, any policy governing IPv4 allocation should ensure that access to these resources remains balanced, practical, and does not unintentionally disadvantage networks that still depend on IPv4. A well-designed policy should encourage responsible stewardship of IPv4 while supporting a gradual and sustainable transition toward IPv6. I believe that maintaining neutrality, fairness, and sound resource governance will strengthen confidence in the Policy Development Process and serve the best interests of the community. BR, Thandeka Mseleku -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Fri Jul 17 11:45:55 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Fri, 17 Jul 2026 13:45:55 +0200 Subject: [rpd] =?utf-8?q?=5BLast_Call=5D_Draft_Policy_Proposal_=E2=80=93_A?= =?utf-8?q?mendment_of_Utilisation_in_Soft_Landing_=28AFPUB-2026-IP?= =?utf-8?q?v4-002-DRAFT02=29?= In-Reply-To: References: Message-ID: Dear PDWG, I would like to respectfully object to the adoption of this proposal based on the governance concerns I raised in my previous contributions to this mailing list. While I support the continued adoption of IPv6 across Africa, I believe Internet number resource policy should remain focused on fair, transparent, and predictable resource management rather than influencing operational deployment decisions. Africa's operators face diverse technical, economic, and infrastructure realities. For this reason, utilisation requirements should not indirectly become a mechanism for influencing technology choices. AFRINIC's role is to remain a neutral steward of Internet number resources while operational decisions continue to rest with network operators. I believe IPv6 adoption can be more effectively encouraged through technical capacity building, operational experience sharing, collaboration, and community engagement rather than through policy requirements. For these reasons, I respectfully object to the proposal in its current form and encourage the community to preserve the principles of neutrality, proportionality, transparency, and fairness within the Policy Development Process. Thank you for your consideration. Best Regards, Fundiswa Nadia Maseko On Fri, 17 Jul 2026, 09:13 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. [Last Call] Draft Policy Proposal- Amendment of Utilisation > in Soft Landing AFPUB-2026-IPv4-002-DRAFT02 (Hytham El-Nakhal) > 2. [Last Call] Draft Policy Proposal - Soft Landing, Recovered > Space and Priority (AFPUB-2026-IPv4-001-DRAFT02) (Hytham El-Nakhal) > 3. [Last Call] Draft Policy Proposal - Hierarchical Names for > New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hytham El-Nakhal) > 4. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (James Bensley) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 16 Jul 2026 22:08:10 +0000 > From: Hytham El-Nakhal > To: "rpd at afrinic.net" > Subject: [rpd] [Last Call] Draft Policy Proposal- Amendment of > Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT02 > Message-ID: <1784239690230.54504 at tra.gov.eg> > Content-Type: text/plain; charset="iso-8859-1" > > Dear PDWG, > > > Last Call: Amendment of Utilisation in Soft Landing > (AFPUB-2026-IPv4-002-DRAFT02) > > > The Policy Development Working Group (PDWG )Chairs have initiated a Last > Call for this proposal, following rough consensus at the AFRINIC-37 Public > Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. > > > * Proposal Name: Amendment of Utilisation in Soft Landing > > * Proposal ID: AFPUB-2026-IPv4-002-DRAFT02 > > * Proposal URL: > https://www.afrinic.net/afpub-2026-ipv4-002-draft02.html > > . > > Last Call closes on : July 31, 2026, at 23:59 UTC. > > > The Secretariat will provide an operational definition of "utilisation" > during this period to assist with final community review. > > > As always, we kindly request that all participants adhere to the AFRINIC > Code of Conduct to maintain a respectful > and professional environment on the mailing list. > > > Kind regards, > > > Haitham el Nakhal > > AFRINIC PDWG Co-Chair > > > > > > ------------------------------ > > Message: 2 > Date: Thu, 16 Jul 2026 22:08:49 +0000 > From: Hytham El-Nakhal > To: "rpd at afrinic.net" > Subject: [rpd] [Last Call] Draft Policy Proposal - Soft Landing, > Recovered Space and Priority (AFPUB-2026-IPv4-001-DRAFT02) > Message-ID: <1784239728924.52164 at tra.gov.eg> > Content-Type: text/plain; charset="iso-8859-1" > > Dear PDWG, > > > The Policy Development Working Group (PDWG )Chairs have initiated a Last > Call for this proposal, following rough consensus at the AFRINIC-37 Public > Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. > > Proposal Details: > > * Proposal Name: Soft Landing, Recovered Space and Priority > > * Proposal ID: AFPUB-2026-IPv4-001-DRAFT02 > > * Proposal URL: > https://www.afrinic.net/afpub-2026-ipv4-001-draft02.html > > Last Call will close on : July 31, 2026, at 23:59 UTC. > > > The Secretariat will provide information on the resource recovery process > during this period to assist with final community review. > > > As always, we kindly request that all participants adhere to the AFRINIC > Code of Conduct to maintain a respectful > and professional environment on the mailing list. > > > Kind Regards, > > > Haitham el Nakhal > > AFRINIC PDWG Co-Chair > > > > > > ------------------------------ > > Message: 3 > Date: Thu, 16 Jul 2026 22:09:48 +0000 > From: Hytham El-Nakhal > To: "rpd at afrinic.net" > Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: <1784239787450.20999 at tra.gov.eg> > Content-Type: text/plain; charset="iso-8859-1" > > Dear PDWG, > > > The Policy Development Working Group (PDWG) Chairs have initiated a Last > Call for this proposal, following rough consensus at the AFRINIC-37 Public > Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. > > * Proposal Name: Hierarchical Names for New AS-SETs > > * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > > * Proposal URL: > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > Last Call closes on: July 31, 2026, at 23:59 UTC. > > > 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. > > > As always, we kindly request that all participants adhere to the AFRINIC > Code of Conduct to maintain a respectful > and professional environment on the mailing list. > > > Kind regards, > > > Haitham el Nakhal > > AFRINIC PDWG Co-Chair > > > > > > ------------------------------ > > Message: 4 > Date: Fri, 17 Jul 2026 07:13:05 +0000 > From: James Bensley > To: Hytham El-Nakhal , "rpd at afrinic.net" > > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > < > BEZP281MB2455B27A57B2ED3DADBA3818C0C62 at BEZP281MB2455.DEUP281.PROD.OUTLOOK.COM > > > > Content-Type: text/plain; charset="utf-8" > > Dear PDWG, > > I support the adoption of this proposal. > > Full disclosure: I am the original author. > > With kind regards, > James Bensley (he/him) > ________________________________ > From: Hytham El-Nakhal > Sent: 17 July 2026 00:09 > To: rpd at afrinic.net > Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for > New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > ?? Caution: This email originated from outside of your organization. Do > not click on links or open attachments unless you recognize the sender and > know the content is safe. > > Dear PDWG, > > > The Policy Development Working Group (PDWG) Chairs have initiated a Last > Call for this proposal, following rough consensus at the AFRINIC-37 Public > Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. > > * Proposal Name: Hierarchical Names for New AS-SETs > > * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > > * Proposal URL: > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > Last Call closes on: July 31, 2026, at 23:59 UTC. > > > 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. > > > As always, we kindly request that all participants adhere to the AFRINIC > Code of Conduct to maintain a respectful > and professional environment on the mailing list. > > > Kind regards, > > > Haitham el Nakhal > > AFRINIC PDWG Co-Chair > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > [CompanySignature] > Inter..link GmbH | Boxhagener Stra?e 80, 10245 Berlin, Germany > > | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: > Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: > hello at inter.link | Web: inter.link< > https://inter.link> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260717/297790c0/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 32 > ************************************ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From seun.ojedeji at gmail.com Fri Jul 17 12:10:27 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Fri, 17 Jul 2026 07:10:27 -0500 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: Message-ID: This response seem similar to the response from nndemo at staff.zegu.ac.zw Regards ---- Sent from my mobile kindly excuse typos On Mon, 13 Jul 2026, 10:42?am Simphiwe Ngubane via RPD, wrote: > Dear PDWG, > > I agree with Alain?s response because it maintains a necessary distinction > between the role of registry policy and the realities of network > operations. The purpose of the IPv4 Soft Landing policy should remain > centered on the coordination and management of scarce Internet number > resources, rather than introducing operational conditions tied to IPv6 > deployment. > > I also agree that IPv6 adoption across the region cannot be measured only > through deployment statistics. Many operators may already be investing in > infrastructure upgrades, staff training, network planning, and transition > readiness, even where large-scale IPv6 traffic is not yet visible. > Deployment decisions are influenced by operational readiness, commercial > priorities, customer demand, equipment lifecycles, and local market > conditions, all of which vary significantly across the AFRINIC service > region. > > Importantly, the IPv4 Soft Landing policy was developed to address IPv4 > scarcity and allocation management. While IPv6 adoption remains an > important objective for the long-term sustainability of the Internet, using > IPv4 allocation policy as a mechanism to drive deployment risks combining > two distinct policy goals. Resource coordination and technology adoption > are related, but they are not the same function. > > In my view, policies work best when they remain focused on their narrow > coordination purpose while allowing operators the flexibility to determine > the most practical technical path for their networks. Linking IPv4 > eligibility to IPv6 deployment could unintentionally disadvantage smaller > or resource-constrained operators that are actively preparing for > transition but are not yet in a position to deploy at scale. > > Encouraging IPv6 through technical cooperation, implementation experience, > training, knowledge sharing, and operational forums is likely to produce > more sustainable progress than introducing deployment requirements into > resource management policies. Long-term IPv6 success depends on the > readiness of the broader ecosystem, including network operators, vendors, > content providers, transit providers, and end-user environments. > > For these reasons, I support keeping the IPv4 Soft Landing policy > technically neutral, operationally realistic, and aligned with the diverse > needs of networks across the AFRINIC region. RIRs are most effective when > they remain neutral coordinators of Internet number resources while > enabling, rather than prescribing, the evolution of network technologies. > > Yours Sincerely, > Simphiwe Ngubane > MSc in Engineering UCT > (My views are my own in given in my personal capacity and do not form part > of any affiliation or representation to the University of Cape Town) > Disclaimer - University of Cape Town This email is subject to UCT policies > and email disclaimer published on our website at > https://www.uct.ac.za/main/email-disclaimer or obtainable from +27 21 650 > 9111. If this email is not related to the business of UCT, it is sent by > the sender in an individual capacity. Please report security incidents or > abuse via https://csirt.uct.ac.za/report-incident > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Fri Jul 17 13:14:55 2026 From: ben.roberts at afrinic.net (ben.roberts@frinic.net) Date: Fri, 17 Jul 2026 16:14:55 +0300 Subject: [rpd] Word of the day - Astroturfing Message-ID: An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Fri Jul 17 15:39:45 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Fri, 17 Jul 2026 17:39:45 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) Message-ID: Dear Colleagues, I do *not* support adoption of this proposal. 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. This proposal also illustrates what Lu Heng describes as the *Policy Mirror*. The issue is not hierarchical AS-SET names themselves, but the continuing assumption that every operational practice should be standardized through registry policy rather than left to voluntary operator adoption. Running networks?not policy manuals?should determine what survives. If hierarchical naming provides sufficient operational value, operators will naturally deploy it without requiring another layer of institutional governance. Furthermore, AFRINIC should be reducing policy complexity rather than increasing it. *Running-Code Primacy* requires that policy remain the minimum necessary to preserve interoperability and operational continuity. Every additional policy object increases long-term maintenance, interpretation, and enforcement costs while offering limited benefit to the stability of the Internet itself. The common layer should remain thin. Finally, rough consensus should not be mistaken for proof that additional governance is desirable. A mailing list is not a legislature, and community discussion should not automatically become permanent policy. Before adopting any proposal, we should first ask whether failure to adopt would actually threaten uniqueness, interoperability, or operational continuity. If the answer is no, then the proposal belongs in operational best practice, not in mandatory registry policy. For these reasons, I oppose adoption. BR, Nonhlanhla -------------- next part -------------- An HTML attachment was scrubbed... URL: From honlue at gmail.com Fri Jul 17 15:43:36 2026 From: honlue at gmail.com (Musa Stephen Honlue) Date: Fri, 17 Jul 2026 17:43:36 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <61376605-1e0a-472e-b5e8-0dad0272b388@geier.ne.tz> References: <61376605-1e0a-472e-b5e8-0dad0272b388@geier.ne.tz> Message-ID: <41BA114C-5267-454D-A4E9-7DA43D881E7E@gmail.com> Hello all, I support adoption and implementation of this policy. Sent from my iPhone > On 17 Jul 2026, at 09:19, Frank Habicht wrote: > > ?Dear all, > > I support adoption and implementation of this proposal. > > Regards, > Frank Habicht > AS37084 > >> On 7/17/2026 1:09 AM, Hytham El-Nakhal wrote: >> Dear PDWG, >> The Policy Development Working Group (PDWG) Chairs have initiated a Last Call for this proposal, following rough consensus at the AFRINIC-37 Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. >> * Proposal Name: Hierarchical Names for New AS-SETs >> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >> * Proposal URL: https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> Last Call closes on: July 31, 2026, at 23:59 UTC. >> 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. >> As always, we kindly request that all participants adhere to the AFRINIC Code of Conduct to maintain a respectful and professional environment on the mailing list. >> Kind regards, >> Haitham el Nakhal >> AFRINIC PDWG Co-Chair >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From nngodiseniannastacia at gmail.com Fri Jul 17 15:46:02 2026 From: nngodiseniannastacia at gmail.com (Dakalo Nngodiseni) Date: Fri, 17 Jul 2026 17:46:02 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <41BA114C-5267-454D-A4E9-7DA43D881E7E@gmail.com> References: <61376605-1e0a-472e-b5e8-0dad0272b388@geier.ne.tz> <41BA114C-5267-454D-A4E9-7DA43D881E7E@gmail.com> Message-ID: Hello all , I support the adoption and implementation of this policy . On Fri, 17 Jul 2026 at 17:44, Musa Stephen Honlue wrote: > Hello all, > > I support adoption and implementation of this policy. > > Sent from my iPhone > > > On 17 Jul 2026, at 09:19, Frank Habicht wrote: > > > > ?Dear all, > > > > I support adoption and implementation of this proposal. > > > > Regards, > > Frank Habicht > > AS37084 > > > >> On 7/17/2026 1:09 AM, Hytham El-Nakhal wrote: > >> Dear PDWG, > >> The Policy Development Working Group (PDWG) Chairs have initiated a > Last Call for this proposal, following rough consensus at the AFRINIC-37 > Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June > 2026. > >> * Proposal Name: Hierarchical Names for New AS-SETs > >> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > >> * Proposal URL: > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >> Last Call closes on: July 31, 2026, at 23:59 UTC. > >> 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. > >> As always, we kindly request that all participants adhere to the > AFRINIC Code of Conduct to maintain a > respectful and professional environment on the mailing list. > >> Kind regards, > >> Haitham el Nakhal > >> AFRINIC PDWG Co-Chair > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gugudhlamini343 at gmail.com Fri Jul 17 15:46:18 2026 From: gugudhlamini343 at gmail.com (Gugu Dhlamini) Date: Fri, 17 Jul 2026 17:46:18 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear All, I would like to register my objection to the proposal to make IPv6 deployment a criterion for IPv4 soft landing. I share the concerns raised by Fundiswa, Thandeka, and Nonhlanhla during the discussion. The purpose of a soft-landing policy should be to ensure the fair, predictable, and operationally sound management of the remaining IPv4 address pool. Introducing IPv6 deployment as an eligibility criterion shifts the policy away from resource stewardship and towards influencing operational decisions that are better left to network operators. IPv6 deployment is an important objective, but it should progress because it delivers technical and business value?not because it becomes a regulatory condition for accessing IPv4 resources. Organisations adopt IPv6 at different rates depending on their infrastructure, customer demand, commercial environment, and technical readiness. A policy that conditions IPv4 access on IPv6 deployment risks creating artificial barriers while doing little to address the underlying operational realities of Internet networks. More fundamentally, resource management policies should avoid expanding the role of the registry beyond maintaining an accurate and reliable allocation ledger. The role of the registry is to administer Internet number resources in a neutral, transparent, and predictable manner, not to use allocation policy as a mechanism to direct network architecture or operational behaviour. Conflating these roles risks unnecessary policy complexity and expands institutional authority beyond what is required for effective registry operations. A resilient Internet depends on maintaining the continuity and integrity of the registry while allowing operators the flexibility to determine how best to manage their own network transitions. Encouraging IPv6 adoption through technical support, education, incentives, and capacity building is likely to be more effective than making it a prerequisite for IPv4 eligibility. For these reasons, I do not support including IPv6 deployment as a criterion for IPv4 soft landing and encourage the Working Group to pursue approaches that promote IPv6 adoption without compromising the neutrality and operational focus of the registry. BR, Gugu -------------- next part -------------- An HTML attachment was scrubbed... URL: From gugudhlamini343 at gmail.com Fri Jul 17 15:48:51 2026 From: gugudhlamini343 at gmail.com (Gugu Dhlamini) Date: Fri, 17 Jul 2026 17:48:51 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <41BA114C-5267-454D-A4E9-7DA43D881E7E@gmail.com> References: <61376605-1e0a-472e-b5e8-0dad0272b388@geier.ne.tz> <41BA114C-5267-454D-A4E9-7DA43D881E7E@gmail.com> Message-ID: Dear All, I OBJECT THIS POLICY. I would like to express my concerns regarding the proposal to introduce hierarchical naming for new AS-SETs (AFPUB-2026-ASN-001-DRAFT02). I agree with the concerns raised by Fundiswa, Thandeka, and Nonhlanhla during the discussion. At first glance, this proposal appears to be a minor technical enhancement. However, policy changes should be evaluated not only on their immediate operational benefits, but also on whether they expand institutional complexity or shift the role of the registry beyond its core function. The primary role of the registry is to maintain an accurate, neutral, and reliable resource registry and associated data infrastructure. Policy should focus on preserving the integrity of the ledger and enabling operational continuity, rather than continuously introducing new structures that may increase dependence on registry-defined conventions. One concern is that proposals of this nature, while well-intentioned, can contribute to what has been described as ?mandate laundering?: the gradual expansion of institutional influence through incremental policy changes that appear administrative or technical in isolation, but collectively increase the scope of centralized governance over network operations and coordination practices. The Internet?s resilience comes from minimizing unnecessary dependencies and preserving operator autonomy. If hierarchical AS-SET naming is genuinely required for operational efficiency, the proposal should clearly demonstrate that existing mechanisms are insufficient and that the benefits outweigh the costs of additional policy complexity. Convenience alone is not a sufficient basis for expanding registry-managed structures. This also relates to the broader ?stability fallacy?: the assumption that more structure, more policy, or more institutional mechanisms necessarily create more stability. In many cases, long-term stability is better served by simplicity, interoperability, and clear separation between registry administration and operator decision-making. The burden of proof should therefore rest with proponents to demonstrate that this proposal addresses a concrete operational problem that cannot be solved through existing practices, voluntary coordination, or tooling improvements outside the policy framework. For these reasons, I do not support the proposal in its current form and encourage the Working Group to prioritise minimalism, operational continuity, and the protection of the registry?s core mandate. Kind regards, Gugu On Fri, 17 Jul 2026, 5:44 pm Musa Stephen Honlue wrote: > Hello all, > > I support adoption and implementation of this policy. > > Sent from my iPhone > > > On 17 Jul 2026, at 09:19, Frank Habicht wrote: > > > > ?Dear all, > > > > I support adoption and implementation of this proposal. > > > > Regards, > > Frank Habicht > > AS37084 > > > >> On 7/17/2026 1:09 AM, Hytham El-Nakhal wrote: > >> Dear PDWG, > >> The Policy Development Working Group (PDWG) Chairs have initiated a > Last Call for this proposal, following rough consensus at the AFRINIC-37 > Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June > 2026. > >> * Proposal Name: Hierarchical Names for New AS-SETs > >> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > >> * Proposal URL: > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >> Last Call closes on: July 31, 2026, at 23:59 UTC. > >> 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. > >> As always, we kindly request that all participants adhere to the > AFRINIC Code of Conduct to maintain a > respectful and professional environment on the mailing list. > >> Kind regards, > >> Haitham el Nakhal > >> AFRINIC PDWG Co-Chair > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gugudhlamini343 at gmail.com Fri Jul 17 15:53:21 2026 From: gugudhlamini343 at gmail.com (Gugu Dhlamini) Date: Fri, 17 Jul 2026 17:53:21 +0200 Subject: [rpd] Fwd: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <61376605-1e0a-472e-b5e8-0dad0272b388@geier.ne.tz> <41BA114C-5267-454D-A4E9-7DA43D881E7E@gmail.com> Message-ID: ---------- Forwarded message --------- From: Gugu Dhlamini Date: Fri, 17 Jul 2026, 5:48 pm Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) To: Musa Stephen Honlue Cc: Frank Habicht , Dear All, I OBJECT THIS POLICY. I would like to express my concerns regarding the proposal to introduce hierarchical naming for new AS-SETs (AFPUB-2026-ASN-001-DRAFT02). I agree with the concerns raised by Fundiswa, Thandeka, and Nonhlanhla during the discussion. At first glance, this proposal appears to be a minor technical enhancement. However, policy changes should be evaluated not only on their immediate operational benefits, but also on whether they expand institutional complexity or shift the role of the registry beyond its core function. The primary role of the registry is to maintain an accurate, neutral, and reliable resource registry and associated data infrastructure. Policy should focus on preserving the integrity of the ledger and enabling operational continuity, rather than continuously introducing new structures that may increase dependence on registry-defined conventions. One concern is that proposals of this nature, while well-intentioned, can contribute to what has been described as ?mandate laundering?: the gradual expansion of institutional influence through incremental policy changes that appear administrative or technical in isolation, but collectively increase the scope of centralized governance over network operations and coordination practices. The Internet?s resilience comes from minimizing unnecessary dependencies and preserving operator autonomy. If hierarchical AS-SET naming is genuinely required for operational efficiency, the proposal should clearly demonstrate that existing mechanisms are insufficient and that the benefits outweigh the costs of additional policy complexity. Convenience alone is not a sufficient basis for expanding registry-managed structures. This also relates to the broader ?stability fallacy?: the assumption that more structure, more policy, or more institutional mechanisms necessarily create more stability. In many cases, long-term stability is better served by simplicity, interoperability, and clear separation between registry administration and operator decision-making. The burden of proof should therefore rest with proponents to demonstrate that this proposal addresses a concrete operational problem that cannot be solved through existing practices, voluntary coordination, or tooling improvements outside the policy framework. For these reasons, I do not support the proposal in its current form and encourage the Working Group to prioritise minimalism, operational continuity, and the protection of the registry?s core mandate. Kind regards, Gugu On Fri, 17 Jul 2026, 5:44 pm Musa Stephen Honlue wrote: > Hello all, > > I support adoption and implementation of this policy. > > Sent from my iPhone > > > On 17 Jul 2026, at 09:19, Frank Habicht wrote: > > > > ?Dear all, > > > > I support adoption and implementation of this proposal. > > > > Regards, > > Frank Habicht > > AS37084 > > > >> On 7/17/2026 1:09 AM, Hytham El-Nakhal wrote: > >> Dear PDWG, > >> The Policy Development Working Group (PDWG) Chairs have initiated a > Last Call for this proposal, following rough consensus at the AFRINIC-37 > Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June > 2026. > >> * Proposal Name: Hierarchical Names for New AS-SETs > >> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > >> * Proposal URL: > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >> Last Call closes on: July 31, 2026, at 23:59 UTC. > >> 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. > >> As always, we kindly request that all participants adhere to the > AFRINIC Code of Conduct to maintain a > respectful and professional environment on the mailing list. > >> Kind regards, > >> Haitham el Nakhal > >> AFRINIC PDWG Co-Chair > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew at teraco.co.za Fri Jul 17 15:59:04 2026 From: andrew at teraco.co.za (Andrew Owens) Date: Fri, 17 Jul 2026 15:59:04 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <61376605-1e0a-472e-b5e8-0dad0272b388@geier.ne.tz> References: <1784239787450.20999@tra.gov.eg> <61376605-1e0a-472e-b5e8-0dad0272b388@geier.ne.tz> Message-ID: Supported. Get Outlook for Android ________________________________ From: Frank Habicht Sent: Friday, 17 July 2026 09:19:32 To: rpd at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Dear all, I support adoption and implementation of this proposal. Regards, Frank Habicht AS37084 On 7/17/2026 1:09 AM, Hytham El-Nakhal wrote: > Dear PDWG, > > > The Policy Development Working Group (PDWG) Chairs have initiated a Last Call for this proposal, following rough consensus at the AFRINIC-37 Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. > > * Proposal Name: Hierarchical Names for New AS-SETs > > * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > > * Proposal URL: https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > Last Call closes on: July 31, 2026, at 23:59 UTC. > > > 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. > > > As always, we kindly request that all participants adhere to the AFRINIC Code of Conduct> to maintain a respectful and professional environment on the mailing list. > > > Kind regards, > > > Haitham el Nakhal > > AFRINIC PDWG Co-Chair > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From edd at edd.za.net Fri Jul 17 16:08:09 2026 From: edd at edd.za.net (Edrich de Lange) Date: Fri, 17 Jul 2026 18:08:09 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <61376605-1e0a-472e-b5e8-0dad0272b388@geier.ne.tz> References: <1784239787450.20999@tra.gov.eg> <61376605-1e0a-472e-b5e8-0dad0272b388@geier.ne.tz> Message-ID: Hi All, I support this policy adoption and implementation. Kind regards Edd On 17 Jul 2026, at 9:19, Frank Habicht wrote: > Dear all, > > I support adoption and implementation of this proposal. > > Regards, > Frank Habicht > AS37084 > > On 7/17/2026 1:09 AM, Hytham El-Nakhal wrote: >> Dear PDWG, >> >> >> The Policy Development Working Group (PDWG) Chairs have initiated a >> Last Call for this proposal, following rough consensus at the >> AFRINIC-37 Public Policy Meeting held in hybrid format in Nairobi, >> Kenya on 24 June 2026. >> >> * Proposal Name: Hierarchical Names for New AS-SETs >> >> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >> >> * Proposal URL: >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >> Last Call closes on: July 31, 2026, at 23:59 UTC. >> >> >> 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. >> >> >> As always, we kindly request that all participants adhere to the >> AFRINIC Code of Conduct to maintain a >> respectful and professional environment > on the mailing list. >> >> >> Kind regards, >> >> >> Haitham el Nakhal >> >> AFRINIC PDWG Co-Chair >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From seun.ojedeji at gmail.com Fri Jul 17 16:15:30 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Fri, 17 Jul 2026 11:15:30 -0500 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <1784239787450.20999@tra.gov.eg> References: <1784239787450.20999@tra.gov.eg> Message-ID: I do support this proposal Regards On Thu, 16 Jul 2026 at 17:10, Hytham El-Nakhal wrote: > Dear PDWG, > > > The Policy Development Working Group (PDWG) Chairs have initiated a Last > Call for this proposal, following rough consensus at the AFRINIC-37 Public > Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. > > * Proposal Name: Hierarchical Names for New AS-SETs > > * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > > * Proposal URL: > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > Last Call closes on: July 31, 2026, at 23:59 UTC. > > > 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. > > > As always, we kindly request that all participants adhere to the AFRINIC > Code of Conduct to maintain a respectful > and professional environment on the mailing list. > > > Kind regards, > > > Haitham el Nakhal > > AFRINIC PDWG Co-Chair > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -- ------------------------------------------------------------------------ *Seun Ojedeji,* Bringing another down does not take you up - think about your action! -------------- next part -------------- An HTML attachment was scrubbed... URL: From seun.ojedeji at gmail.com Fri Jul 17 16:23:45 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Fri, 17 Jul 2026 11:23:45 -0500 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) In-Reply-To: References: Message-ID: Hello Nia, The registry administers number resources through policies that govern it. To your question* "...does it expand the registry's governance surface?" *no it doesn't, the proposal once ratified will serve as one of the policies that helps the RIR fulfil its role. Regards On Fri, 17 Jul 2026 at 10:40, Nia Petronella < nonhlanhlapetronella85 at gmail.com> wrote: > Dear Colleagues, > > I do *not* support adoption of this proposal. > > 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. > > This proposal also illustrates what Lu Heng describes as the *Policy > Mirror*. The issue is not hierarchical AS-SET names themselves, but the > continuing assumption that every operational practice should be > standardized through registry policy rather than left to voluntary operator > adoption. Running networks?not policy manuals?should determine what > survives. If hierarchical naming provides sufficient operational value, > operators will naturally deploy it without requiring another layer of > institutional governance. > > Furthermore, AFRINIC should be reducing policy complexity rather than > increasing it. *Running-Code Primacy* requires that policy remain the > minimum necessary to preserve interoperability and operational continuity. > Every additional policy object increases long-term maintenance, > interpretation, and enforcement costs while offering limited benefit to the > stability of the Internet itself. The common layer should remain thin. > > Finally, rough consensus should not be mistaken for proof that additional > governance is desirable. A mailing list is not a legislature, and community > discussion should not automatically become permanent policy. Before > adopting any proposal, we should first ask whether failure to adopt would > actually threaten uniqueness, interoperability, or operational continuity. > If the answer is no, then the proposal belongs in operational best > practice, not in mandatory registry policy. > > For these reasons, I oppose adoption. > > > BR, > > Nonhlanhla > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -- ------------------------------------------------------------------------ *Seun Ojedeji,* Bringing another down does not take you up - think about your action! -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonjabulosphilile at gmail.com Fri Jul 17 16:27:41 2026 From: nonjabulosphilile at gmail.com (Nonjabulo Sphilile) Date: Fri, 17 Jul 2026 18:27:41 +0200 Subject: [rpd] Subject is [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear PDWG Chairs, I object to AFPUB-2026-ASN-001-DRAFT02: Hierarchical Names for New AS-SETs. This proposal reflects a recurring failure within the policy process: the assumption that every perceived inconvenience should be answered with another layer of policy rather than evidence of an actual operational problem. The burden of proof belongs to those proposing new rules, not to everyone else to justify keeping the Internet simpler. Where is the demonstrated operational failure that requires this change? Where is the evidence that existing AS-SET naming conventions have become inadequate at Internet scale? None has been presented. Instead, we are asked to accept additional complexity because it appears administratively tidy. Administrative tidiness is not the same as operational necessity. Internet coordination should remain as thin as possible. Every additional rule, naming convention, or procedural expectation expands the policy surface without necessarily improving interoperability or routing security. Complexity accumulates far more easily than it disappears. The policy process should resist the temptation to legislate for hypothetical problems. If there is no demonstrated operational deficiency, then introducing additional hierarchy is simply governance expanding into spaces where it has not yet justified its existence. For these reasons, I object to the proposal in its current form. Kind regards, Nonjabulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Fri Jul 17 16:51:53 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Fri, 17 Jul 2026 18:51:53 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) In-Reply-To: References: Message-ID: Hello Seun, That response illustrates precisely the concern. Saying that a proposal ?helps the RIR fulfil its role? does not answer whether the proposal expands that role. It merely assumes the scope of the role in advance and then uses policy adoption to validate the assumption. That is circular. The registry?s original technical function is narrow: preserve uniqueness, maintain accurate records, support contactability, record changes of control, and protect operational continuity. Those functions justify a registry. They do not create a general mandate to regulate every practice that can be attached to a registry object. A policy does not become legitimate merely because the registry can administer it. Nor does ratification transform an administrative preference into a technical necessity. Otherwise, there is no limiting principle. Any proposal can be said to ?help the RIR fulfil its role,? provided the role is continuously redefined by the policies the RIR later enforces. That is mandate laundering. A narrow coordination function is passed through the language of policy, consensus, and community until it re-emerges as institutional authority. The process then points to its own output as proof that the authority existed all along. But policy procedure cannot manufacture mandate. A meeting is not a legislature. Participation is not authorization. Rough consensus does not give a registry an unlimited governance surface over operators, routing practice, commercial arrangements, naming conventions, or future implementation choices. The proper question is not whether the proposal can be administered by the RIR. Almost anything can be administered once enough procedure is created around it. The proper question is: what technical invariant requires this rule to be mandatory? Does it protect uniqueness? Does it prevent duplicate registration? Does it preserve registry accuracy? Does it protect security integrity? Does it preserve operational continuity? If it does not, then it is not a necessary registry function. It is institutional preference being converted into enforceable policy. There is also an important distinction between recording a practice and governing it. A registry may accurately record AS-SET information. It may provide technical formats and interoperable publication mechanisms. It should not assume that maintaining the database gives it authority to prescribe every naming structure used by operators. The registry should describe operational reality, not manufacture it through policy and then enforce obedience through control of the registry layer. So yes, this proposal does expand the governance surface. It does so by converting a naming convention into a policy obligation and then placing the registry in the position of interpreting, administering, and enforcing that obligation. Calling that ?fulfilling the RIR?s role? does not resolve the objection. It proves it. Regards, Nonhlanhla On Fri, 17 Jul 2026, 6:24 pm Seun Ojedeji wrote: > Hello Nia, > > The registry administers number resources through policies that govern it. > To your question* "...does it expand the registry's governance surface?" *no > it doesn't, the proposal once ratified will serve as one of the policies > that helps the RIR fulfil its role. > > Regards > > On Fri, 17 Jul 2026 at 10:40, Nia Petronella < > nonhlanhlapetronella85 at gmail.com> wrote: > >> Dear Colleagues, >> >> I do *not* support adoption of this proposal. >> >> 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. >> >> This proposal also illustrates what Lu Heng describes as the *Policy >> Mirror*. The issue is not hierarchical AS-SET names themselves, but the >> continuing assumption that every operational practice should be >> standardized through registry policy rather than left to voluntary operator >> adoption. Running networks?not policy manuals?should determine what >> survives. If hierarchical naming provides sufficient operational value, >> operators will naturally deploy it without requiring another layer of >> institutional governance. >> >> Furthermore, AFRINIC should be reducing policy complexity rather than >> increasing it. *Running-Code Primacy* requires that policy remain the >> minimum necessary to preserve interoperability and operational continuity. >> Every additional policy object increases long-term maintenance, >> interpretation, and enforcement costs while offering limited benefit to the >> stability of the Internet itself. The common layer should remain thin. >> >> Finally, rough consensus should not be mistaken for proof that additional >> governance is desirable. A mailing list is not a legislature, and community >> discussion should not automatically become permanent policy. Before >> adopting any proposal, we should first ask whether failure to adopt would >> actually threaten uniqueness, interoperability, or operational continuity. >> If the answer is no, then the proposal belongs in operational best >> practice, not in mandatory registry policy. >> >> For these reasons, I oppose adoption. >> >> >> BR, >> >> Nonhlanhla >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > > > -- > ------------------------------------------------------------------------ > > > *Seun Ojedeji,* > > Bringing another down does not take you up - think about your action! > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gugudhlamini343 at gmail.com Fri Jul 17 16:58:08 2026 From: gugudhlamini343 at gmail.com (Gugu Dhlamini) Date: Fri, 17 Jul 2026 18:58:08 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <1784239787450.20999@tra.gov.eg> Message-ID: Hi All, Further to my OBJECTION of this POLICY PROPOSAL: I agree with Nonhlanhla's point regarding mandate laundering and the gradual expansion of institutional authority. My concern is that this discussion is not really about hierarchical names. It is about a much broader pattern. We increasingly justify new policy by saying it helps the registry fulfil its role, while the role itself is continuously expanded through the accumulation of policies. That creates a circular process in which policy becomes the justification for more policy. The registry's original technical purpose is relatively narrow: maintain uniqueness, preserve accurate records, support interoperability, and provide a reliable registry service. Those are functions that the Internet genuinely requires. The difficulty begins when every new proposal is treated as another legitimate extension of the registry's mandate simply because it has passed through the PDP. At that point, the process itself begins manufacturing authority. Participation becomes confused with authorization, and procedural consensus gradually becomes institutional power. That is why I believe Nonhlanhla's observation about mandate laundering is important. A policy process should not become a mechanism through which an administrative body continually enlarges its own scope. Otherwise there is no meaningful limiting principle. Every proposal can simply be described as helping the registry perform its role, while the definition of that role quietly expands over time. The better question is much simpler. What technical invariant requires this policy? Does it preserve uniqueness? Does it improve registry accuracy? Does it protect interoperability? Does it strengthen operational continuity? If the answer is no, then we should be cautious about converting operational preferences into registry policy. This is also why I believe decentralisation is the longer-term direction we should be discussing. A resilient Internet should minimise dependence on institutional discretion. Coordination should remain thin, while operational decisions remain with operators. The registry should record reality, not increasingly define it. The more authority accumulates within a single administrative layer, the greater the temptation to use policy as a governance mechanism rather than as a narrow technical tool. The Internet became successful because it minimised the amount of central authority required for independent networks to interoperate. We should be careful not to move in the opposite direction by steadily expanding registry governance into areas where technical necessity has not been demonstrated. Regards, Gugu On Fri, 17 Jul 2026, 6:18 pm Seun Ojedeji wrote: > I do support this proposal > > Regards > > On Thu, 16 Jul 2026 at 17:10, Hytham El-Nakhal wrote: > >> Dear PDWG, >> >> >> The Policy Development Working Group (PDWG) Chairs have initiated a Last >> Call for this proposal, following rough consensus at the AFRINIC-37 Public >> Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. >> >> * Proposal Name: Hierarchical Names for New AS-SETs >> >> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >> >> * Proposal URL: >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >> Last Call closes on: July 31, 2026, at 23:59 UTC. >> >> >> 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. >> >> >> As always, we kindly request that all participants adhere to the AFRINIC >> Code of Conduct to maintain a respectful >> and professional environment on the mailing list. >> >> >> Kind regards, >> >> >> Haitham el Nakhal >> >> AFRINIC PDWG Co-Chair >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > > > -- > ------------------------------------------------------------------------ > > > *Seun Ojedeji,* > > Bringing another down does not take you up - think about your action! > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asamkele.menzeleli18 at maharishinstitute.org Fri Jul 17 17:26:25 2026 From: asamkele.menzeleli18 at maharishinstitute.org (Asamkele Menzeleli) Date: Fri, 17 Jul 2026 19:26:25 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Hello everyone, I object to this proposal. I also agree with Nonhlanhla's point regarding mandate laundering. We should be careful not to confuse policy development with expanding institutional authority. Policies should reflect demonstrated operational realities and technical necessity. They should not become governance mechanisms that gradually enlarge the registry's role beyond maintaining uniqueness, accurate records, and operational coordination. A registry should record reality, not create new layers of governance through policy. Regards, Asamkele Menzeleli -------------- next part -------------- An HTML attachment was scrubbed... URL: From nndemo at staff.zegu.ac.zw Fri Jul 17 17:27:28 2026 From: nndemo at staff.zegu.ac.zw (Nyasha Ndemo) Date: Fri, 17 Jul 2026 19:27:28 +0200 Subject: [rpd] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear PDWG Chairs, I object to AFPUB-2026-ASN-001-DRAFT02. This proposal reflects a recurring institutional habit: when no clear operational failure exists, create additional structure and then describe that structure as progress. The Internet did not become resilient because every identifier was surrounded by increasingly elaborate policy. It became resilient because coordination remained narrow, predictable, and justified by operational necessity. The burden should always rest with those proposing additional rules to demonstrate why existing practice has become inadequate. That burden has not been met. I have seen no evidence that current AS-SET naming conventions are creating a material operational problem that justifies expanding the policy surface. Administrative preference is not operational necessity. Consistency is desirable, but consistency alone is not sufficient justification for imposing additional structure on everyone. Every new rule carries a cost. It increases complexity, creates new expectations, and expands the scope of future interpretation. Those costs accumulate even when each individual proposal appears modest. Over time, coordination quietly transforms into governance, and governance gradually begins solving problems that never required central solutions in the first place. The default principle should be restraint. If the Internet continues to function without a proposed rule, then the proposal must demonstrate not merely that it is cleaner or more elegant, but that it solves a concrete operational deficiency that cannot reasonably be addressed through existing practice. This proposal does not reach that threshold. For these reasons, I object to AFPUB-2026-ASN-001-DRAFT02. Kind regards, Dr. Nyasha Ndemo-Masimbarasi (DPhil, MSc., BSc. Hon. Development Science and Policy) Chairperson - Department of Development Programming and Management Zimbabwe Ezekiel Guti University 1901 Barrassie Rd, Off Shamva Rd, Bindura Zimbabwe Landline: +263867 700 6136 Cell: +263 773226552 Email: nyashandemo at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mavhungutshepo at gmail.com Fri Jul 17 18:03:25 2026 From: mavhungutshepo at gmail.com (tshepo mavhungu) Date: Fri, 17 Jul 2026 20:03:25 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear Policy Development Working Group, I would like to express my concerns regarding the proposal to introduce hierarchical naming for new AS-SETs (AFPUB-2026-ASN-001-DRAFT02). I agree with the concerns raised by Fundiswa, Thandeka, and Nonhlanhla during the discussion. At first glance, this proposal appears to be a minor technical enhancement. However, policy changes should be evaluated not only on their immediate operational benefits, but also on whether they expand institutional complexity or shift the role of the registry beyond its core function. The primary role of the registry is to maintain an accurate, neutral, and reliable resource registry and associated data infrastructure. Policy should focus on preserving the integrity of the ledger and enabling operational continuity, rather than continuously introducing new structures that may increase dependence on registry-defined conventions. One concern is that proposals of this nature, while well-intentioned, can contribute to what has been described as ?mandate laundering?: the gradual expansion of institutional influence through incremental policy changes that appear administrative or technical in isolation, but collectively increase the scope of centralized governance over network operations and coordination practices. The Internet?s resilience comes from minimizing unnecessary dependencies and preserving operator autonomy. If hierarchical AS-SET naming is genuinely required for operational efficiency, the proposal should clearly demonstrate that existing mechanisms are insufficient and that the benefits outweigh the costs of additional policy complexity. Convenience alone is not a sufficient basis for expanding registry-managed structures. This also relates to the broader ?stability fallacy?: the assumption that more structure, more policy, or more institutional mechanisms necessarily create more stability. In many cases, long-term stability is better served by simplicity, interoperability, and clear separation between registry administration and operator decision-making. The burden of proof should therefore rest with proponents to demonstrate that this proposal addresses a concrete operational problem that cannot be solved through existing practices, voluntary coordination, or tooling improvements outside the policy framework. For these reasons, I do not support the proposal in its current form and encourage the Working Group to prioritise minimalism, operational continuity, and the protection of the registry?s core mandate. Kind regards, Tshepo Mavhungu -------------- next part -------------- An HTML attachment was scrubbed... URL: From ST10120874 at vcconnect.edu.za Fri Jul 17 19:36:04 2026 From: ST10120874 at vcconnect.edu.za (Mphoentle Mokheseng) Date: Fri, 17 Jul 2026 19:36:04 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear PDWG Chairs, I object to AFPUB-2026-ASN-001-DRAFT02. The Internet has always succeeded by minimizing the amount of centralized authority required for independent networks to interoperate. Coordination is necessary. Governance beyond what coordination requires is not. This proposal may appear modest, but it reflects a broader trend that deserves scrutiny. We increasingly treat every operational preference as something that must be standardized through policy simply because the registry is capable of administering it. That reverses the proper relationship between operations and policy. Policy should emerge from established operational reality. It should not be used to manufacture it. The burden is on the proposer to demonstrate that an existing technical deficiency cannot be addressed without creating a new policy obligation. I do not believe that burden has been met. No compelling evidence has been presented that current AS-SET naming practices threaten uniqueness, registry integrity, interoperability, or the stable operation of the Internet. The fact that a naming convention may be desirable does not make it an appropriate subject for mandatory registry policy. Every additional policy expands the registry's sphere of interpretation and administration. Individually these expansions appear harmless. Collectively they normalize the idea that the registry should increasingly prescribe operational behaviour rather than simply coordinate shared technical resources. That is a direction we should resist. The registry's legitimacy comes from performing a narrowly defined technical function exceptionally well, not from continuously enlarging its policy surface. We should preserve that distinction. Institutions are strongest when they exercise only the authority that is demonstrably necessary, and no more. For these reasons, I object to AFPUB-2026-ASN-001-DRAFT02. Kind regards, Mphoentle Disclaimer This email and the information contained herein are Advtech Ltd confidential and are protected by law. Please navigate to our website for more information https://www.groupadvtech.com. Use of this information or this email by any person for any purposes other than that for which it is intended is prohibited and may result in civil and/or criminal liability. This email is not to be shared with any 3rd parties not included within this email, without the written consent of its Author. If you have received this message in error, please notify Advtech immediately, telephone number +27 11 676 8000. Advtech leads the private sector in the fields of education and resourcing, contributing meaningfully towards the sustainable development of human capacity in South Africa. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tshepomasuku16 at gmail.com Fri Jul 17 20:00:58 2026 From: tshepomasuku16 at gmail.com (Tshepo Masuku) Date: Fri, 17 Jul 2026 22:00:58 +0200 Subject: [rpd] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) Message-ID: Dear PDWG, I object to this proposal. Policy should mirror operational realities, not attempt to shape or prescribe them. Where operational demand already justifies a practice, the community will adopt it without requiring additional policy intervention. If there is insufficient operational demand, then creating policy around it risks introducing unnecessary complexity and administrative overhead. More importantly, this proposal reflects what I see as policy enforcement creep. The role of policy is to provide a neutral framework for Internet number resource management?not to incrementally expand the registry's influence over how operators structure or manage their routing objects. Every additional policy requirement should be justified by a clear operational necessity, not simply because it is technically possible or administratively convenient. The registry should remain focused on maintaining the integrity of the registry and supporting operational continuity, rather than extending its mandate through increasingly prescriptive policies. Kind regards, Tshepo -------------- next part -------------- An HTML attachment was scrubbed... URL: From hytham at tra.gov.eg Fri Jul 17 21:07:14 2026 From: hytham at tra.gov.eg (Hytham El-Nakhal) Date: Fri, 17 Jul 2026 21:07:14 +0000 Subject: [rpd] [External] Re: IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: , Message-ID: <1784322436120.29860@tra.gov.eg> Dear Seun, Well noted.. The new word shared by Ben, "astroturfing" is the best term to define such emails. Unfortunately, the Code of Conduct doesn't include a clear action against astroturfing but it's taken into consideration. Best Regards, Haitham el Nakhal PDWG Co-Chair ________________________________ From: Seun Ojedeji Sent: Friday, July 17, 2026 3:10 PM To: Simphiwe Ngubane Cc: rpd Subject: [External] Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. This response seem similar to the response from nndemo at staff.zegu.ac.zw Regards ---- Sent from my mobile kindly excuse typos On Mon, 13 Jul 2026, 10:42?am Simphiwe Ngubane via RPD, > wrote: Dear PDWG, I agree with Alain's response because it maintains a necessary distinction between the role of registry policy and the realities of network operations. The purpose of the IPv4 Soft Landing policy should remain centered on the coordination and management of scarce Internet number resources, rather than introducing operational conditions tied to IPv6 deployment. I also agree that IPv6 adoption across the region cannot be measured only through deployment statistics. Many operators may already be investing in infrastructure upgrades, staff training, network planning, and transition readiness, even where large-scale IPv6 traffic is not yet visible. Deployment decisions are influenced by operational readiness, commercial priorities, customer demand, equipment lifecycles, and local market conditions, all of which vary significantly across the AFRINIC service region. Importantly, the IPv4 Soft Landing policy was developed to address IPv4 scarcity and allocation management. While IPv6 adoption remains an important objective for the long-term sustainability of the Internet, using IPv4 allocation policy as a mechanism to drive deployment risks combining two distinct policy goals. Resource coordination and technology adoption are related, but they are not the same function. In my view, policies work best when they remain focused on their narrow coordination purpose while allowing operators the flexibility to determine the most practical technical path for their networks. Linking IPv4 eligibility to IPv6 deployment could unintentionally disadvantage smaller or resource-constrained operators that are actively preparing for transition but are not yet in a position to deploy at scale. Encouraging IPv6 through technical cooperation, implementation experience, training, knowledge sharing, and operational forums is likely to produce more sustainable progress than introducing deployment requirements into resource management policies. Long-term IPv6 success depends on the readiness of the broader ecosystem, including network operators, vendors, content providers, transit providers, and end-user environments. For these reasons, I support keeping the IPv4 Soft Landing policy technically neutral, operationally realistic, and aligned with the diverse needs of networks across the AFRINIC region. RIRs are most effective when they remain neutral coordinators of Internet number resources while enabling, rather than prescribing, the evolution of network technologies. Yours Sincerely, Simphiwe Ngubane MSc in Engineering UCT (My views are my own in given in my personal capacity and do not form part of any affiliation or representation to the University of Cape Town) Disclaimer - University of Cape Town This email is subject to UCT policies and email disclaimer published on our website at https://www.uct.ac.za/main/email-disclaimer or obtainable from +27 21 650 9111. If this email is not related to the business of UCT, it is sent by the sender in an individual capacity. Please report security incidents or abuse via https://csirt.uct.ac.za/report-incident _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd From 4141105 at myuwc.ac.za Sat Jul 18 08:19:26 2026 From: 4141105 at myuwc.ac.za (PAULO MSABA) Date: Sat, 18 Jul 2026 10:19:26 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) Message-ID: Dear PDWG, I object to this proposal. In line with what Tshepo, Nonhlanhla, Fundiswa and Thandeka had mentioned, Policy should follow operational reality, not manufacture obligations where running networks have not demonstrated a clear need. A registry should protect uniqueness, accuracy, and continuity. It should not expand its mandate through increasingly prescriptive control over how operators manage routing objects. This proposal therefore represents unnecessary policy and enforcement creep. In the absence of a clear technical necessity, such matters should remain with operators and voluntary adoption. Kind regards Paulo Msaba -- Disclaimer - This e-mail is subject to UWC policies and e-mail disclaimer published on our website at:?https://www.uwc.ac.za/disclaimer -------------- next part -------------- An HTML attachment was scrubbed... URL: From tshehlanthabiseng93 at gmail.com Sat Jul 18 08:21:48 2026 From: tshehlanthabiseng93 at gmail.com (Nthabiseng Tshehla) Date: Sat, 18 Jul 2026 10:21:48 +0200 Subject: [rpd] Subject: Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Good day everyone I object to this proposal and agree with Nonhlanhla's concerns regarding mandate laundering. The existence of a Policy Development Process does not, by itself, justify expanding the registry's role. Policy should be a means of documenting genuine operational requirements, not a vehicle for extending institutional authority into areas where no technical necessity has been demonstrated. The RIR's responsibility is to facilitate coordination, maintain accurate registry data, and support the stable operation of the Internet. It should not become the arbiter of operational conventions simply because it has the procedural ability to do so. For that reason, I do not believe this proposal should advance. Regards Nthabiseng -------------- next part -------------- An HTML attachment was scrubbed... URL: From mselekuthandeka80 at gmail.com Sat Jul 18 08:59:07 2026 From: mselekuthandeka80 at gmail.com (Thandeka Mseleku) Date: Sat, 18 Jul 2026 10:59:07 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) Message-ID: Dear PDWG, I remain opposed to this proposal. The fact that multiple community members express similar concerns should not diminish the substance of those concerns. What matters is whether the arguments are technically and operationally sound. I continue to believe that policy should reflect demonstrated operational needs rather than introduce obligations that have not been shown to be necessary. Registry policies should preserve stability, accuracy, and neutrality without expanding prescriptive requirements where voluntary operational practices are already sufficient. For that reason, I do not believe this proposal has demonstrated a compelling justification for the additional requirements it introduces. Maintaining operator flexibility while ensuring sound resource governance remains the more proportionate approach. BR, *Thandeka Mseleku* -------------- next part -------------- An HTML attachment was scrubbed... URL: From NGBSIM008 at myuct.ac.za Sat Jul 18 09:55:24 2026 From: NGBSIM008 at myuct.ac.za (Simphiwe Ngubane) Date: Sat, 18 Jul 2026 09:55:24 +0000 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. In-Reply-To: References: Message-ID: Good morning Seun, To the best of my knowledge I've only posted once or twice on this platform. I'm comparatively knew to the forum. In terms of the similarity you allude to, I should think it well spotted as we both, from my understanding, object/ed to the new policy proposal. Fundamentally, as an objection to IPv6 enforcement creep through IPv4 policy. Kind Regards Simphiwe Ngubane ________________________________ From: Seun Ojedeji Sent: Friday, July 17, 2026 2:10:59 pm To: Simphiwe Ngubane Cc: rpd Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01. CAUTION: This email originated outside the UCT network. Do not click any links or open attachments unless you know and trust the source. This response seem similar to the response from nndemo at staff.zegu.ac.zw Regards ---- Sent from my mobile kindly excuse typos On Mon, 13 Jul 2026, 10:42?am Simphiwe Ngubane via RPD, > wrote: Dear PDWG, I agree with Alain?s response because it maintains a necessary distinction between the role of registry policy and the realities of network operations. The purpose of the IPv4 Soft Landing policy should remain centered on the coordination and management of scarce Internet number resources, rather than introducing operational conditions tied to IPv6 deployment. I also agree that IPv6 adoption across the region cannot be measured only through deployment statistics. Many operators may already be investing in infrastructure upgrades, staff training, network planning, and transition readiness, even where large-scale IPv6 traffic is not yet visible. Deployment decisions are influenced by operational readiness, commercial priorities, customer demand, equipment lifecycles, and local market conditions, all of which vary significantly across the AFRINIC service region. Importantly, the IPv4 Soft Landing policy was developed to address IPv4 scarcity and allocation management. While IPv6 adoption remains an important objective for the long-term sustainability of the Internet, using IPv4 allocation policy as a mechanism to drive deployment risks combining two distinct policy goals. Resource coordination and technology adoption are related, but they are not the same function. In my view, policies work best when they remain focused on their narrow coordination purpose while allowing operators the flexibility to determine the most practical technical path for their networks. Linking IPv4 eligibility to IPv6 deployment could unintentionally disadvantage smaller or resource-constrained operators that are actively preparing for transition but are not yet in a position to deploy at scale. Encouraging IPv6 through technical cooperation, implementation experience, training, knowledge sharing, and operational forums is likely to produce more sustainable progress than introducing deployment requirements into resource management policies. Long-term IPv6 success depends on the readiness of the broader ecosystem, including network operators, vendors, content providers, transit providers, and end-user environments. For these reasons, I support keeping the IPv4 Soft Landing policy technically neutral, operationally realistic, and aligned with the diverse needs of networks across the AFRINIC region. RIRs are most effective when they remain neutral coordinators of Internet number resources while enabling, rather than prescribing, the evolution of network technologies. Yours Sincerely, Simphiwe Ngubane MSc in Engineering UCT (My views are my own in given in my personal capacity and do not form part of any affiliation or representation to the University of Cape Town) Disclaimer - University of Cape Town This email is subject to UCT policies and email disclaimer published on our website at https://www.uct.ac.za/main/email-disclaimer or obtainable from +27 21 650 9111. If this email is not related to the business of UCT, it is sent by the sender in an individual capacity. Please report security incidents or abuse via https://csirt.uct.ac.za/report-incident _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd Disclaimer - University of Cape Town This email is subject to UCT policies and email disclaimer published on our website at https://www.uct.ac.za/main/email-disclaimer or obtainable from +27 21 650 9111. If this email is not related to the business of UCT, it is sent by the sender in an individual capacity. Please report security incidents or abuse via https://csirt.uct.ac.za/report-incident -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Sat Jul 18 10:44:17 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Sat, 18 Jul 2026 12:44:17 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 42 In-Reply-To: References: Message-ID: Dear PDWG, I agree with Thandeka and remain opposed to this proposal. The attempt to dismiss similar objections as ?astroturfing? does not answer the substance of those objections. Different participants may independently reach the same conclusion when a proposal introduces requirements that are not supported by demonstrated operational necessity. Similarity of position is not evidence of improper coordination. The relevant question is not who used comparable language, but whether the proposal protects a genuine technical invariant such as registry accuracy, uniqueness, security, or operational continuity. If it does not, the matter should remain with operators and voluntary operational practice. Participation should be assessed by the quality of the argument, not invalidated because several people object on the same principled grounds. A mailing list should discuss policy, not police conformity of expression. For these reasons, I support Thandeka?s objection and maintain my opposition to the proposal. Kind regards, Nonhlanhla On Sat, 18 Jul 2026, 11:56 am wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of > Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) > (Thandeka Mseleku) > 2. Re: IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01. (Simphiwe Ngubane) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 18 Jul 2026 10:59:07 +0200 > From: Thandeka Mseleku > To: rpd at afrinic.net > Cc: rpd-owner at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of > Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) > Message-ID: > kXZ5yCoEMq4yKazG_+1GMUouiEpkYA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear PDWG, > > I remain opposed to this proposal. > > The fact that multiple community members express similar concerns should > not diminish the substance of those concerns. What matters is whether the > arguments are technically and operationally sound. > > I continue to believe that policy should reflect demonstrated operational > needs rather than introduce obligations that have not been shown to be > necessary. Registry policies should preserve stability, accuracy, and > neutrality without expanding prescriptive requirements where voluntary > operational practices are already sufficient. > > For that reason, I do not believe this proposal has demonstrated a > compelling justification for the additional requirements it introduces. > Maintaining operator flexibility while ensuring sound resource governance > remains the more proportionate approach. > > BR, > *Thandeka Mseleku* > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260718/90004a03/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Sat, 18 Jul 2026 09:55:24 +0000 > From: Simphiwe Ngubane > To: Seun Ojedeji > Cc: rpd > Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01. > Message-ID: > < > JN1P275MB06001BC72DBF6290E7A7336AB1C52 at JN1P275MB0600.ZAFP275.PROD.OUTLOOK.COM > > > > Content-Type: text/plain; charset="utf-8" > > Good morning Seun, > > To the best of my knowledge I've only posted once or twice on this > platform. I'm comparatively knew to the forum. > > In terms of the similarity you allude to, I should think it well spotted > as we both, from my understanding, object/ed to the new policy proposal. > Fundamentally, as an objection to IPv6 enforcement creep through IPv4 > policy. > > Kind Regards > Simphiwe Ngubane > > ________________________________ > From: Seun Ojedeji > Sent: Friday, July 17, 2026 2:10:59 pm > To: Simphiwe Ngubane > Cc: rpd > Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01. > > CAUTION: This email originated outside the UCT network. Do not click any > links or open attachments unless you know and trust the source. > > This response seem similar to the response from nndemo at staff.zegu.ac.zw > > > Regards > ---- > Sent from my mobile > kindly excuse typos > > On Mon, 13 Jul 2026, 10:42?am Simphiwe Ngubane via RPD, > wrote: > Dear PDWG, > > I agree with Alain?s response because it maintains a necessary distinction > between the role of registry policy and the realities of network > operations. The purpose of the IPv4 Soft Landing policy should remain > centered on the coordination and management of scarce Internet number > resources, rather than introducing operational conditions tied to IPv6 > deployment. > > I also agree that IPv6 adoption across the region cannot be measured only > through deployment statistics. Many operators may already be investing in > infrastructure upgrades, staff training, network planning, and transition > readiness, even where large-scale IPv6 traffic is not yet visible. > Deployment decisions are influenced by operational readiness, commercial > priorities, customer demand, equipment lifecycles, and local market > conditions, all of which vary significantly across the AFRINIC service > region. > > Importantly, the IPv4 Soft Landing policy was developed to address IPv4 > scarcity and allocation management. While IPv6 adoption remains an > important objective for the long-term sustainability of the Internet, using > IPv4 allocation policy as a mechanism to drive deployment risks combining > two distinct policy goals. Resource coordination and technology adoption > are related, but they are not the same function. > > In my view, policies work best when they remain focused on their narrow > coordination purpose while allowing operators the flexibility to determine > the most practical technical path for their networks. Linking IPv4 > eligibility to IPv6 deployment could unintentionally disadvantage smaller > or resource-constrained operators that are actively preparing for > transition but are not yet in a position to deploy at scale. > > Encouraging IPv6 through technical cooperation, implementation experience, > training, knowledge sharing, and operational forums is likely to produce > more sustainable progress than introducing deployment requirements into > resource management policies. Long-term IPv6 success depends on the > readiness of the broader ecosystem, including network operators, vendors, > content providers, transit providers, and end-user environments. > > For these reasons, I support keeping the IPv4 Soft Landing policy > technically neutral, operationally realistic, and aligned with the diverse > needs of networks across the AFRINIC region. RIRs are most effective when > they remain neutral coordinators of Internet number resources while > enabling, rather than prescribing, the evolution of network technologies. > > Yours Sincerely, > Simphiwe Ngubane > MSc in Engineering UCT > (My views are my own in given in my personal capacity and do not form part > of any affiliation or representation to the University of Cape Town) > Disclaimer - University of Cape Town This email is subject to UCT policies > and email disclaimer published on our website at > https://www.uct.ac.za/main/email-disclaimer< > https://www.uct.ac.za/main/email-disclaimer> or obtainable from +27 21 > 650 9111. If this email is not related to the business of UCT, it is sent > by the sender in an individual capacity. Please report security incidents > or abuse via https://csirt.uct.ac.za/report-incident< > https://csirt.uct.ac.za/report-incident> > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd< > https://lists.afrinic.net/mailman/listinfo/rpd> > > Disclaimer - University of Cape Town This email is subject to UCT policies > and email disclaimer published on our website at > https://www.uct.ac.za/main/email-disclaimer or obtainable from +27 21 650 > 9111. If this email is not related to the business of UCT, it is sent by > the sender in an individual capacity. Please report security incidents or > abuse via https://csirt.uct.ac.za/report-incident > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260718/4684f837/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 42 > ************************************ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Sat Jul 18 14:32:38 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Sat, 18 Jul 2026 16:32:38 +0200 Subject: [rpd] =?utf-8?q?=5BLast_Call=5D_Draft_Policy_Proposal_-_Hierarchi?= =?utf-8?q?cal_Names=2C_=C2=A0_=C2=A0_=C2=A0_for_New_AS-SETs_=28AFPUB-2026?= =?utf-8?q?-ASN-001-DRAFT02=29=2C__Re=3A__RPD_Digest=2C_Vol_222=2C_Issue_4?= =?utf-8?q?2?= In-Reply-To: References: Message-ID: So Nia, The first question that comes in my mind: Which AFRICAN network and organizations do you represent? AfriNIC ORG handles? The use of anonymous Emails puts a real question mark and does enhance the astrturfing claims. The 2nd question: When Other RIRs are enforcing it, MANRS are advocating it, and it is a good for the Internet/etc. and for running proper networks to be a good netizen, why the objections other than vague similar objections?by NOT enforcing it, we, AfriNIC are playing in the hands of those that does and can use AS-sets in less?good-for-the-internet? ways. By Enforcing it for new AS-SETS, it just keeps things properly clean from my, being an operator?s point of view. --- 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 On 18 Jul 2026, at 12:44, Nia Petronella wrote: > Dear PDWG, > > I agree with Thandeka and remain opposed to this proposal. > > The attempt to dismiss similar objections as ?astroturfing? does > not answer > the substance of those objections. Different participants may > independently > reach the same conclusion when a proposal introduces requirements that > are > not supported by demonstrated operational necessity. Similarity of > position > is not evidence of improper coordination. > > The relevant question is not who used comparable language, but whether > the > proposal protects a genuine technical invariant such as registry > accuracy, > uniqueness, security, or operational continuity. If it does not, the > matter > should remain with operators and voluntary operational practice. > > Participation should be assessed by the quality of the argument, not > invalidated because several people object on the same principled > grounds. A > mailing list should discuss policy, not police conformity of > expression. > > For these reasons, I support Thandeka?s objection and maintain my > opposition to the proposal. > > Kind regards, > Nonhlanhla -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Sat Jul 18 14:40:31 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Sat, 18 Jul 2026 16:40:31 +0200 Subject: [rpd] =?utf-8?q?=5BLast_Call=5D_Draft_Policy_Proposal_-_Hierarchi?= =?utf-8?b?Y2FsIE5hbWVzLCDCoCDCoCDCoCBmb3IgTmV3IEFTLVNFVHMgKEFGUFVC?= =?utf-8?q?-2026-ASN-001-DRAFT02=29=2C_Re=3A__RPD_Digest=2C_Vol_222?= =?utf-8?q?=2C_Issue_42?= In-Reply-To: References: Message-ID: Dear Hendrick, Your questions appear to confuse participation with representation. I participate in the PDWG as an individual stakeholder expressing a policy position. An open policy process cannot invite individual participation and then demand that every objection be backed by an institutional constituency before it is considered legitimate. A participant may provide evidence, technical judgment, operational experience, warning, or objection. None of these requires the participant to claim authority over a continent or community. Indeed, claiming to represent ?African networks? without direct authorization would be a far more serious legitimacy problem than speaking in an individual capacity. The use of a private or unfamiliar email address does not prove astroturfing. Similar conclusions are also not evidence of coordinated misconduct. When several participants identify the same defect in a proposal, similarity may simply reflect that the defect is obvious. An allegation of astroturfing requires evidence, not suspicion based on identity, wording, or repeated opposition. On the proposal itself, the fact that other RIRs enforce a practice and that MANRS advocates it does not establish a mandate for AFRINIC to enforce it. Advocacy is not authority. Adoption elsewhere is not proof of necessity. A desirable operational practice does not automatically belong in the mandatory registry layer. The correct test is whether the proposal protects a technical invariant that running networks require, such as uniqueness, registry accuracy, security integrity, or operational continuity. It must also show that compulsory enforcement is necessary, that voluntary adoption is insufficient, and that the administrative and operational costs are proportionate. Keeping records clean is valuable. Giving the registry wider enforcement power is a separate question. The registry may support good routing practice, publish guidance, and provide useful tools. It should not convert every recommended practice into an enforceable obligation merely because another institution considers it beneficial. The burden remains on the proposal?s supporters to demonstrate why operator judgment and voluntary implementation are inadequate. Questioning the identity or affiliations of objectors does not satisfy that burden and does not answer their arguments. I therefore remain opposed to the proposal. Kind regards, Nonhlanhla On Sat, 18 Jul 2026, 4:33 pm Hendrik Visage wrote: > So Nia, > > The first question that comes in my mind: Which AFRICAN network and > organizations do you represent? > AfriNIC ORG handles? The use of anonymous Emails puts a real question mark > and does enhance the astrturfing claims. > > The 2nd question: When Other RIRs are enforcing it, MANRS are advocating > it, and it is a good for the Internet/etc. and for running proper networks > to be a good netizen, why the objections other than vague similar > objections?by NOT enforcing it, we, AfriNIC are playing in the hands of > those that does and can use AS-sets in less?good-for-the-internet? ways. By > Enforcing it for new AS-SETS, it just keeps things properly clean from my, > being an operator?s point of view. > ------------------------------ > > 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 > > On 18 Jul 2026, at 12:44, Nia Petronella wrote: > > Dear PDWG, > > I agree with Thandeka and remain opposed to this proposal. > > The attempt to dismiss similar objections as ?astroturfing? does not > answer > the substance of those objections. Different participants may > independently > reach the same conclusion when a proposal introduces requirements that are > not supported by demonstrated operational necessity. Similarity of > position > is not evidence of improper coordination. > > The relevant question is not who used comparable language, but whether the > proposal protects a genuine technical invariant such as registry accuracy, > uniqueness, security, or operational continuity. If it does not, the > matter > should remain with operators and voluntary operational practice. > > Participation should be assessed by the quality of the argument, not > invalidated because several people object on the same principled grounds. > A > mailing list should discuss policy, not police conformity of expression. > > For these reasons, I support Thandeka?s objection and maintain my > opposition to the proposal. > > Kind regards, > Nonhlanhla > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Sat Jul 18 18:27:16 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Sat, 18 Jul 2026 20:27:16 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: Dear Tshepo, I disagree with the objection. This proposal isn't policy trying to shape behaviour ahead of demand ? it's closing a known gap before it grows larger. Non-hierarchical AS-SET names allow two operators to register the same name, and once that happens there's no reliable way to tell which ASN a set actually belongs to. That ambiguity directly undermines IRR-based route filtering, which is a real operational and routing-security concern, not a theoretical one. Every flat-named AS-SET created under the current convention adds to the collision problem and makes future cleanup harder, so waiting for "sufficient demand" simply lets the mess compound. Far from being enforcement creep, the proposal is narrowly scoped: it applies only to newly created AS-SETs, doesn't touch route-sets or other object types, and never forces an existing object to be renamed. And this isn't AFRINIC inventing a mandate ? APNIC, RIPE, ARIN, and LACNIC have all already adopted hierarchical AS-SET naming, which would leave AFRINIC as the only RIR without it. That consensus across the other four registries is exactly the "clear operational necessity" you're asking for. Kind regards --- 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 On 17 Jul 2026, at 20:03, tshepo mavhungu wrote: > Dear Policy Development Working Group, > > I would like to express my concerns regarding the proposal to > introduce > hierarchical naming for new AS-SETs (AFPUB-2026-ASN-001-DRAFT02). > > I agree with the concerns raised by Fundiswa, Thandeka, and Nonhlanhla > during the discussion. > > At first glance, this proposal appears to be a minor technical > enhancement. > However, policy changes should be evaluated not only on their > immediate > operational benefits, but also on whether they expand institutional > complexity or shift the role of the registry beyond its core function. > > The primary role of the registry is to maintain an accurate, neutral, > and > reliable resource registry and associated data infrastructure. Policy > should focus on preserving the integrity of the ledger and enabling > operational continuity, rather than continuously introducing new > structures > that may increase dependence on registry-defined conventions. > > One concern is that proposals of this nature, while well-intentioned, > can > contribute to what has been described as ?mandate laundering?: the > gradual > expansion of institutional influence through incremental policy > changes > that appear administrative or technical in isolation, but collectively > increase the scope of centralized governance over network operations > and > coordination practices. > > The Internet?s resilience comes from minimizing unnecessary > dependencies > and preserving operator autonomy. If hierarchical AS-SET naming is > genuinely required for operational efficiency, the proposal should > clearly > demonstrate that existing mechanisms are insufficient and that the > benefits > outweigh the costs of additional policy complexity. Convenience alone > is > not a sufficient basis for expanding registry-managed structures. > > This also relates to the broader ?stability fallacy?: the > assumption that > more structure, more policy, or more institutional mechanisms > necessarily > create more stability. In many cases, long-term stability is better > served > by simplicity, interoperability, and clear separation between registry > administration and operator decision-making. > > The burden of proof should therefore rest with proponents to > demonstrate > that this proposal addresses a concrete operational problem that > cannot be > solved through existing practices, voluntary coordination, or tooling > improvements outside the policy framework. > > For these reasons, I do not support the proposal in its current form > and > encourage the Working Group to prioritise minimalism, operational > continuity, and the protection of the registry?s core mandate. > > Kind regards, > > Tshepo Mavhungu > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Sat Jul 18 18:28:16 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Sat, 18 Jul 2026 20:28:16 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: <6F54C5B9-4C90-42F4-ACFD-6E4C57F5BD66@hevis.co.za> Hello Asamkele, Respectfully, this proposal does exactly what you're asking for ? it maintains uniqueness. Flat AS-SET names can be registered by anyone, so two operators can create the same name and there is no way to tell afterwards which ASN it belongs to. That is a uniqueness failure in the registry's own data, and fixing it is squarely within the mandate you describe, not an expansion of it. The proposal adds no governance layer: it applies only to newly created AS-SETs, leaves existing objects untouched, and doesn't extend to route-sets or anything else. And the operational necessity is already demonstrated ? APNIC, RIPE, ARIN, and LACNIC have all implemented hierarchical AS-SET naming, which would leave AFRINIC as the only registry whose IRR data still permits name collisions. Regards --- 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 On 17 Jul 2026, at 19:26, Asamkele Menzeleli wrote: > Hello everyone, > > I object to this proposal. > > I also agree with Nonhlanhla's point regarding mandate laundering. We > should be careful not to confuse policy development with expanding > institutional authority. > > Policies should reflect demonstrated operational realities and > technical > necessity. They should not become governance mechanisms that gradually > enlarge the registry's role beyond maintaining uniqueness, accurate > records, and operational coordination. > > A registry should record reality, not create new layers of governance > through policy. > > Regards, > Asamkele Menzeleli -------------- next part -------------- An HTML attachment was scrubbed... URL: From asamkele.menzeleli18 at maharishinstitute.org Sat Jul 18 19:05:38 2026 From: asamkele.menzeleli18 at maharishinstitute.org (Asamkele Menzeleli) Date: Sat, 18 Jul 2026 21:05:38 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear Hendrik, I disagree with your characterization. A collision between two AS-SET names is not the same as a failure of Internet number-resource uniqueness. The uniqueness function of the registry concerns ASNs, prefixes, proof of control and accurate registration of those resources. An AS-SET is an operational routing-policy object. Confusing the naming convention of that object with the uniqueness of the underlying number resource expands the meaning of ?uniqueness? far beyond its proper technical scope. The fact that two operators may choose the same flat label may justify better tooling, clearer warnings, stronger validation or voluntary hierarchical naming. It does not automatically justify a mandatory policy rule. That distinction is precisely the concern I raised. Institutional authority often expands by redefining a useful administrative preference as a technical necessity. Once every data-quality issue is described as a uniqueness failure, there is effectively no limit to what may be brought into mandatory registry policy. The proposal?s limited scope does not answer that concern. A new enforcement power does not cease to be enforcement merely because it applies prospectively or begins with one object type. The correct test is whether the rule is indispensable to preserving the operation of running networks, and whether a less restrictive mechanism cannot achieve the same outcome. You also repeat that the other four RIRs have implemented hierarchical naming. That demonstrates institutional adoption elsewhere. It does not demonstrate that AFRINIC operators have authorized the same rule, that actual routing failures in this region require it, or that voluntary and technical alternatives are inadequate. Four registries making the same choice is not a substitute for evidence. A registry should record operational reality accurately and provide operators with tools to manage routing information safely. It should not turn every preferred convention into mandatory governance merely because uniformity looks tidy from the registry side. My objection therefore remains. The proposal has not shown that compulsory hierarchical naming is necessary to protect number-resource uniqueness, nor that the registry should extend its mandatory policy authority into this area. Regards, Asamkele Menzeleli -------------- next part -------------- An HTML attachment was scrubbed... URL: From gugudhlamini343 at gmail.com Sat Jul 18 19:45:03 2026 From: gugudhlamini343 at gmail.com (Gugu Dhlamini) Date: Sat, 18 Jul 2026 21:45:03 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: Dear PDWG, I agree with Asamkele and disagree with Hendrik?s perspective. This is substantially the same argument Hendrik made in response to Tshepo: that because a naming collision can occur, the issue must therefore be treated as a failure of registry uniqueness and made subject to mandatory policy. That conclusion does not follow. A collision between AS-SET labels is not the same as duplicate allocation of an ASN or IP prefix. The underlying number resources remain unique. What is being discussed is the naming and interpretation of an operational routing object. That may justify better tools, warnings, validation, documentation, or voluntary hierarchical naming, but it does not automatically justify expanding mandatory registry authority. There is also an important ethical question here. Policy power should not be enlarged merely because the proposed requirement appears useful, tidy, or widely adopted elsewhere. The burden lies with those seeking compulsion to show actual harm, necessity, proportionality, and the failure of less restrictive alternatives. Operators should not be forced to surrender discretion simply because an institution prefers uniformity. The fact that four other RIRs adopted a similar convention is not proof that AFRINIC must do the same. Institutional repetition is not technical necessity, and participation in the PDWG should not become a ritual for ratifying choices already made elsewhere. The registry should preserve number-resource uniqueness, registry accuracy, and operational continuity. It should not stretch those concepts until every preferred operational convention becomes mandatory policy. For these reasons, I support Asamkele?s objection and remain opposed to the proposal. Regards, Nonhlanhla On Sat, 18 Jul 2026, 9:08 pm Asamkele Menzeleli < asamkele.menzeleli18 at maharishinstitute.org> wrote: > Dear Hendrik, > > I disagree with your characterization. > > A collision between two AS-SET names is not the same as a failure of > Internet number-resource uniqueness. The uniqueness function of the > registry concerns ASNs, prefixes, proof of control and accurate > registration of those resources. An AS-SET is an operational routing-policy > object. Confusing the naming convention of that object with the uniqueness > of the underlying number resource expands the meaning of ?uniqueness? far > beyond its proper technical scope. > > The fact that two operators may choose the same flat label may justify > better tooling, clearer warnings, stronger validation or voluntary > hierarchical naming. It does not automatically justify a mandatory policy > rule. > > That distinction is precisely the concern I raised. Institutional > authority often expands by redefining a useful administrative preference as > a technical necessity. Once every data-quality issue is described as a > uniqueness failure, there is effectively no limit to what may be brought > into mandatory registry policy. > > The proposal?s limited scope does not answer that concern. A new > enforcement power does not cease to be enforcement merely because it > applies prospectively or begins with one object type. The correct test is > whether the rule is indispensable to preserving the operation of running > networks, and whether a less restrictive mechanism cannot achieve the same > outcome. > > You also repeat that the other four RIRs have implemented hierarchical > naming. That demonstrates institutional adoption elsewhere. It does not > demonstrate that AFRINIC operators have authorized the same rule, that > actual routing failures in this region require it, or that voluntary and > technical alternatives are inadequate. Four registries making the same > choice is not a substitute for evidence. > > A registry should record operational reality accurately and provide > operators with tools to manage routing information safely. It should not > turn every preferred convention into mandatory governance merely because > uniformity looks tidy from the registry side. > > My objection therefore remains. The proposal has not shown that compulsory > hierarchical naming is necessary to protect number-resource uniqueness, nor > that the registry should extend its mandatory policy authority into this > area. > > Regards, > Asamkele Menzeleli > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Sat Jul 18 19:49:48 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Sat, 18 Jul 2026 21:49:48 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 45 In-Reply-To: References: Message-ID: Dear PDWG, I agree with Asamkele, Gugu, and Tshepo, and I remain opposed to this proposal. Responding to objectors one by one does not resolve the common concern they have raised. A collision between AS-SET labels is not a failure of ASN or prefix uniqueness, and repeating that characterization does not make it technically correct. The proposal still has not demonstrated measurable operational harm, why voluntary hierarchical naming is insufficient, or why mandatory registry intervention is the least restrictive solution. Adoption by other RIRs is relevant, but institutional uniformity is not proof of technical necessity. A policy process should examine objections on their merits, not treat repeated disagreement as something to be individually overcome. The registry should support accurate routing information without converting every preferred convention into compulsory policy. I therefore support the objections already raised and maintain my opposition. Regards, Nonhlanhla On Sat, 18 Jul 2026, 9:46 pm wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage) > 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Asamkele Menzeleli) > 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Gugu Dhlamini) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 18 Jul 2026 20:28:16 +0200 > From: Hendrik Visage > To: Asamkele Menzeleli > Cc: rpd-owner at afrinic.net, rpd at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: <6F54C5B9-4C90-42F4-ACFD-6E4C57F5BD66 at hevis.co.za> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hello Asamkele, > Respectfully, this proposal does exactly what you're asking for ? it > maintains uniqueness. Flat AS-SET names can be registered by anyone, so > two operators can create the same name and there is no way to tell > afterwards which ASN it belongs to. That is a uniqueness failure in the > registry's own data, and fixing it is squarely within the mandate you > describe, not an expansion of it. The proposal adds no governance layer: > it applies only to newly created AS-SETs, leaves existing objects > untouched, and doesn't extend to route-sets or anything else. And the > operational necessity is already demonstrated ? APNIC, RIPE, ARIN, and > LACNIC have all implemented hierarchical AS-SET naming, which would > leave AFRINIC as the only registry whose IRR data still permits name > collisions. > Regards > > --- > 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 > > On 17 Jul 2026, at 19:26, Asamkele Menzeleli wrote: > > > Hello everyone, > > > > I object to this proposal. > > > > I also agree with Nonhlanhla's point regarding mandate laundering. We > > should be careful not to confuse policy development with expanding > > institutional authority. > > > > Policies should reflect demonstrated operational realities and > > technical > > necessity. They should not become governance mechanisms that gradually > > enlarge the registry's role beyond maintaining uniqueness, accurate > > records, and operational coordination. > > > > A registry should record reality, not create new layers of governance > > through policy. > > > > Regards, > > Asamkele Menzeleli > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260718/cd333640/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Sat, 18 Jul 2026 21:05:38 +0200 > From: Asamkele Menzeleli > To: rpd at afrinic.net > Cc: rpd-owner at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > Yxp+MhGJFpQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Hendrik, > > I disagree with your characterization. > > A collision between two AS-SET names is not the same as a failure of > Internet number-resource uniqueness. The uniqueness function of the > registry concerns ASNs, prefixes, proof of control and accurate > registration of those resources. An AS-SET is an operational routing-policy > object. Confusing the naming convention of that object with the uniqueness > of the underlying number resource expands the meaning of ?uniqueness? far > beyond its proper technical scope. > > The fact that two operators may choose the same flat label may justify > better tooling, clearer warnings, stronger validation or voluntary > hierarchical naming. It does not automatically justify a mandatory policy > rule. > > That distinction is precisely the concern I raised. Institutional authority > often expands by redefining a useful administrative preference as a > technical necessity. Once every data-quality issue is described as a > uniqueness failure, there is effectively no limit to what may be brought > into mandatory registry policy. > > The proposal?s limited scope does not answer that concern. A new > enforcement power does not cease to be enforcement merely because it > applies prospectively or begins with one object type. The correct test is > whether the rule is indispensable to preserving the operation of running > networks, and whether a less restrictive mechanism cannot achieve the same > outcome. > > You also repeat that the other four RIRs have implemented hierarchical > naming. That demonstrates institutional adoption elsewhere. It does not > demonstrate that AFRINIC operators have authorized the same rule, that > actual routing failures in this region require it, or that voluntary and > technical alternatives are inadequate. Four registries making the same > choice is not a substitute for evidence. > > A registry should record operational reality accurately and provide > operators with tools to manage routing information safely. It should not > turn every preferred convention into mandatory governance merely because > uniformity looks tidy from the registry side. > > My objection therefore remains. The proposal has not shown that compulsory > hierarchical naming is necessary to protect number-resource uniqueness, nor > that the registry should extend its mandatory policy authority into this > area. > > Regards, > Asamkele Menzeleli > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260718/e46cf6c9/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Sat, 18 Jul 2026 21:45:03 +0200 > From: Gugu Dhlamini > To: "asamkele.menzeleli18 at maharishinstitute.org" > , " > hvisage at hevis.co.za" > , rpd at afrinic.net, rpd-owner at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > < > CADMrvbPw1Dyu7JU9unFWz4zTZSd4QGQdMup_ibDd9nKcWwuP-w at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear PDWG, > > I agree with Asamkele and disagree with Hendrik?s perspective. > > This is substantially the same argument Hendrik made in response to Tshepo: > that because a naming collision can occur, the issue must therefore be > treated as a failure of registry uniqueness and made subject to mandatory > policy. That conclusion does not follow. > > A collision between AS-SET labels is not the same as duplicate allocation > of an ASN or IP prefix. The underlying number resources remain unique. What > is being discussed is the naming and interpretation of an operational > routing object. That may justify better tools, warnings, validation, > documentation, or voluntary hierarchical naming, but it does not > automatically justify expanding mandatory registry authority. > > There is also an important ethical question here. Policy power should not > be enlarged merely because the proposed requirement appears useful, tidy, > or widely adopted elsewhere. The burden lies with those seeking compulsion > to show actual harm, necessity, proportionality, and the failure of less > restrictive alternatives. Operators should not be forced to surrender > discretion simply because an institution prefers uniformity. > > The fact that four other RIRs adopted a similar convention is not proof > that AFRINIC must do the same. Institutional repetition is not technical > necessity, and participation in the PDWG should not become a ritual for > ratifying choices already made elsewhere. > > The registry should preserve number-resource uniqueness, registry accuracy, > and operational continuity. It should not stretch those concepts until > every preferred operational convention becomes mandatory policy. > > For these reasons, I support Asamkele?s objection and remain opposed to the > proposal. > > Regards, > Nonhlanhla > On Sat, 18 Jul 2026, 9:08 pm Asamkele Menzeleli < > asamkele.menzeleli18 at maharishinstitute.org> wrote: > > > Dear Hendrik, > > > > I disagree with your characterization. > > > > A collision between two AS-SET names is not the same as a failure of > > Internet number-resource uniqueness. The uniqueness function of the > > registry concerns ASNs, prefixes, proof of control and accurate > > registration of those resources. An AS-SET is an operational > routing-policy > > object. Confusing the naming convention of that object with the > uniqueness > > of the underlying number resource expands the meaning of ?uniqueness? far > > beyond its proper technical scope. > > > > The fact that two operators may choose the same flat label may justify > > better tooling, clearer warnings, stronger validation or voluntary > > hierarchical naming. It does not automatically justify a mandatory policy > > rule. > > > > That distinction is precisely the concern I raised. Institutional > > authority often expands by redefining a useful administrative preference > as > > a technical necessity. Once every data-quality issue is described as a > > uniqueness failure, there is effectively no limit to what may be brought > > into mandatory registry policy. > > > > The proposal?s limited scope does not answer that concern. A new > > enforcement power does not cease to be enforcement merely because it > > applies prospectively or begins with one object type. The correct test is > > whether the rule is indispensable to preserving the operation of running > > networks, and whether a less restrictive mechanism cannot achieve the > same > > outcome. > > > > You also repeat that the other four RIRs have implemented hierarchical > > naming. That demonstrates institutional adoption elsewhere. It does not > > demonstrate that AFRINIC operators have authorized the same rule, that > > actual routing failures in this region require it, or that voluntary and > > technical alternatives are inadequate. Four registries making the same > > choice is not a substitute for evidence. > > > > A registry should record operational reality accurately and provide > > operators with tools to manage routing information safely. It should not > > turn every preferred convention into mandatory governance merely because > > uniformity looks tidy from the registry side. > > > > My objection therefore remains. The proposal has not shown that > compulsory > > hierarchical naming is necessary to protect number-resource uniqueness, > nor > > that the registry should extend its mandatory policy authority into this > > area. > > > > Regards, > > Asamkele Menzeleli > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260718/7d3628bc/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 45 > ************************************ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nishal at controlfreak.co.za Sat Jul 18 19:59:08 2026 From: nishal at controlfreak.co.za (Nishal Goburdhan) Date: Sat, 18 Jul 2026 21:59:08 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: <8F6E7DF6-5C1E-4181-B07F-F96E2C1FA2ED@controlfreak.co.za> On 18 Jul 2026, at 21:05, Asamkele Menzeleli wrote: > My objection therefore remains. The proposal has not shown that compulsory > hierarchical naming is necessary to protect number-resource uniqueness, nor > that the registry should extend its mandatory policy authority into this > area. what you meant to say is that it hasn?t shown this ?to you?. and that?s ok; policy proposals are never about appeasing everyone. they are about making incremental benefit. what you are not seeing, is that this solution, has already been demonstrated elsewhere in the world, has actually solved Real-World-Operational problems. you?re forgiven if you don?t see these problems - again - not everyone lives and speaks bgp. but maybe i?m wrong - and maybe you *have* found a better sauce to solving these problems; problems which, real world network operators, have already shown can be exploited, to significant detriment. in which case, please share that, because we?d love to benefit from your operational prowess. but, f you haven?t - either found that sauce, or, are unwilling to share, then appreciate that those of us that operate real networks, want the better protections that this proposal brings. even if you don?t. here?s the thing; the threat that ?flat? names creates has already done this - ie. they *have* been exploited, for no good, in the wild. this is already well documented, and discussed in operator forums. and the objections as i read them - and however strongly you may feel about them - haven?t failed to address any kind of solution, or provided a technical alternate, or, actually done anything except say: ?well, i don?t agree? also, as a tip, the last call part of the proposal is where you address concerns that the _particular policy_ might have. you haven?t really done any of that. so please, try to focus your the discussion on _technical merit solely_. here?s what would help: - show an alternate solution by a vendor / from a technical list - show real world problems that this creates, as documented on a technical forum (eg. afnog, sidr, secops, ..) no-one here has all the answers; and, if we discover in 10years, that ?flat? names were better, no penguins would have been harmed. but, we would have enabled protections for african operators. ?n. From seun.ojedeji at gmail.com Sat Jul 18 20:10:20 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Sat, 18 Jul 2026 15:10:20 -0500 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <8F6E7DF6-5C1E-4181-B07F-F96E2C1FA2ED@controlfreak.co.za> References: <8F6E7DF6-5C1E-4181-B07F-F96E2C1FA2ED@controlfreak.co.za> Message-ID: Well said Nishal and since it seem Nia, Asamkele, Gugu, and Tshepo, agree on the same philosophy and infact they share similar content, perhaps they can form co authors to propose what they feel is a better policy. However for now I support AFPUB-2026-ASN-001-DRAFT02 to move pass the last call. Regards ---- Sent from my mobile kindly excuse typos On Sat, 18 Jul 2026, 2:59?pm Nishal Goburdhan, wrote: > > > On 18 Jul 2026, at 21:05, Asamkele Menzeleli wrote: > > > My objection therefore remains. The proposal has not shown that > compulsory > > hierarchical naming is necessary to protect number-resource uniqueness, > nor > > that the registry should extend its mandatory policy authority into this > > area. > > > what you meant to say is that it hasn?t shown this ?to you?. > and that?s ok; policy proposals are never about appeasing everyone. they > are about making incremental benefit. > what you are not seeing, is that this solution, has already been > demonstrated elsewhere in the world, has actually solved > Real-World-Operational problems. > you?re forgiven if you don?t see these problems - again - not everyone > lives and speaks bgp. > > but maybe i?m wrong - and maybe you *have* found a better sauce to solving > these problems; problems which, real world network operators, have already > shown can be exploited, to significant detriment. in which case, please > share that, because we?d love to benefit from your operational prowess. > but, f you haven?t - either found that sauce, or, are unwilling to share, > then appreciate that those of us that operate real networks, want the > better protections that this proposal brings. even if you don?t. here?s > the thing; the threat that ?flat? names creates has already done this - > ie. they *have* been exploited, for no good, in the wild. this is already > well documented, and discussed in operator forums. and the objections as i > read them - and however strongly you may feel about them - haven?t failed > to address any kind of solution, or provided a technical alternate, or, > actually done anything except say: ?well, i don?t agree? > > also, as a tip, the last call part of the proposal is where you address > concerns that the _particular policy_ might have. you haven?t really done > any of that. so please, try to focus your the discussion on _technical > merit solely_. here?s what would help: > - show an alternate solution by a vendor / from a technical list > - show real world problems that this creates, as documented on a technical > forum (eg. afnog, sidr, secops, ..) > > no-one here has all the answers; and, if we discover in 10years, that > ?flat? names were better, no penguins would have been harmed. but, we > would have enabled protections for african operators. > > ?n. > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Sat Jul 18 20:32:14 2026 From: ben.roberts at afrinic.net (ben.roberts@frinic.net) Date: Sat, 18 Jul 2026 23:32:14 +0300 Subject: [rpd] My latest blog... Message-ID: <56AA1768-E6C1-224D-9633-009718198534@hxcore.ol> An HTML attachment was scrubbed... URL: From christianbope at gmail.com Sat Jul 18 20:46:06 2026 From: christianbope at gmail.com (Bope Domilongo Christian) Date: Sat, 18 Jul 2026 15:46:06 -0500 Subject: [rpd] Appeal Committee Message-ID: Dear PDWG, We appear to be operating without an Appeal Committee, which is a key component of the PDP?s conflict?resolution mechanism. Section 3.5 of the CPM seems to require a standing Appeal Committee to handle disagreements that cannot be resolved between the Chairs and the participant. Could the co?chairs clarify whether an Appeal Committee is currently constituted, and if not, how conflict resolution is expected to function under Section 3.5? Thank you. @christianbope -------------- next part -------------- An HTML attachment was scrubbed... URL: From amelnaud at gmail.com Sat Jul 18 21:39:35 2026 From: amelnaud at gmail.com (Arnaud AMELINA) Date: Sat, 18 Jul 2026 21:39:35 +0000 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 In-Reply-To: <1783459420709.11832@tra.gov.eg> References: <1783459420709.11832@tra.gov.eg> Message-ID: Dear Co?chairs, Section 3.4 of the CPM sets a three?week deadline for publishing PPM minutes. This deadline has now passed, yet the minutes are still unavailable. It is therefore difficult to understand how Last Call was initiated without these minutes, and without a summary of how the RPD and PPM discussions led to the determination of rough consensus. These elements are essential for the Working Group to participate meaningfully in Last Call. Thank you. Regards -- Arnaud Le mar. 7 juil. 2026 ? 21:25, Hytham El-Nakhal a ?crit : > Dear PDWG, > > > I have noticed some mails from community members regarding the policy > proposal "IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01". > > > The author has updated the proposal (DRAFT02), and it was discussed during > the AFRINIC-37 PPM on 24th June 2026. > > > The updated proposal is attached to this email to bring you up to speed > with its contents [pending the re-establishment of the AFRINIC website by > COB 8th July as communicated by AFRINIC]. > > The updated proposal did not reach consensus at the AFRINIC-37 PPM and was > sent back to the RPD mailing-list for further discussions. > > > Those who missed the discussions still have access the AF-37 PPM > proceedings here: https://www.youtube.com/watch?v=uwjG1_XwKV8 . > > > Therefore, it is highly recommended that participants thoroughly review > the attached proposal, familiarize themselves with prior discussions on the > mailing list and during the Public Policy Meeting, and subsequently focus > their valuable contribution by undertaking any of the following actions: > > * - Seek clarifications regarding the policy text and offer > recommendations for its improvement; > * - Express formal support for the proposal; or, > * - Provide a detailed justification in case of opposition to the > policy as drafted. > > > Best Regards, > Haitham el Nakhal > PDWG Co-Chair > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hytham at tra.gov.eg Sat Jul 18 23:08:08 2026 From: hytham at tra.gov.eg (Hytham El-Nakhal) Date: Sat, 18 Jul 2026 23:08:08 +0000 Subject: [rpd] [External] Re: IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 In-Reply-To: References: <1783459420709.11832@tra.gov.eg>, Message-ID: <1784416088278.30395@tra.gov.eg> Dear Arnaud, The PPM minutes are ready to be published within the normal time frame as per CPM and in same day with the Last Call, but there was a technical problem on the new static website for AFRINIC with the links for the policy proposals' ppt and other hyperlinks. The IT staff and the Policy Liaison Team are doing their best to fix the issue as soon as possible. Meanwhile you can find the discussions happened during the PPM day, authors ppt. and the staff analysis here: https://www.youtube.com/watch?v=uwjG1_XwKV8 Appreciate your patience. Regards, Haitham el Nakhal PDWG Co-Chair ________________________________________ From: Arnaud AMELINA [amelnaud at gmail.com] Sent: Sunday, July 19, 2026 12:39 AM To: Hytham El-Nakhal Cc: rpd at afrinic.net Subject: [External] Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 Dear Co?chairs, Section 3.4 of the CPM sets a three?week deadline for publishing PPM minutes. This deadline has now passed, yet the minutes are still unavailable. It is therefore difficult to understand how Last Call was initiated without these minutes, and without a summary of how the RPD and PPM discussions led to the determination of rough consensus. These elements are essential for the Working Group to participate meaningfully in Last Call. Thank you. Regards -- Arnaud Le mar. 7 juil. 2026 ? 21:25, Hytham El-Nakhal > a ?crit : Dear PDWG, I have noticed some mails from community members regarding the policy proposal "IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01". The author has updated the proposal (DRAFT02), and it was discussed during the AFRINIC-37 PPM on 24th June 2026. The updated proposal is attached to this email to bring you up to speed with its contents [pending the re-establishment of the AFRINIC website by COB 8th July as communicated by AFRINIC]. The updated proposal did not reach consensus at the AFRINIC-37 PPM and was sent back to the RPD mailing-list for further discussions. Those who missed the discussions still have access the AF-37 PPM proceedings here: https://www.youtube.com/watch?v=uwjG1_XwKV8 . Therefore, it is highly recommended that participants thoroughly review the attached proposal, familiarize themselves with prior discussions on the mailing list and during the Public Policy Meeting, and subsequently focus their valuable contribution by undertaking any of the following actions: * - Seek clarifications regarding the policy text and offer recommendations for its improvement; * - Express formal support for the proposal; or, * - Provide a detailed justification in case of opposition to the policy as drafted. Best Regards, Haitham el Nakhal PDWG Co-Chair _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd From bakenon.kone at sancfis.net Sat Jul 18 23:33:59 2026 From: bakenon.kone at sancfis.net (Bakenon KONE) Date: Sat, 18 Jul 2026 23:33:59 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <1784239787450.20999@tra.gov.eg> References: <1784239787450.20999@tra.gov.eg> Message-ID: Dear PDWG, I have been following the discussions on the hierarchical AS?SET naming scheme and would like clarification on a few points: 1. Could this matter be addressed operationally, as is done in ARIN, LACNIC, and RIPE NCC, without requiring policy changes? 2. If yes, why are we taking the policy route? Is it because AFRINIC currently lacks a defined process for handling operational issues that affect IRR services? 3. Given that the hierarchical naming scheme is already supported and currently exists within the IRR, this proposal represents an enforcement change rather than the introduction of a new technical standard. Why is a formal policy required to change an operational enforcement setting, rather than a community-vetted technical implementation plan?" Thank you. --- Kone Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal a ?crit : > Dear PDWG, > > > The Policy Development Working Group (PDWG) Chairs have initiated a Last > Call for this proposal, following rough consensus at the AFRINIC-37 Public > Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. > > * Proposal Name: Hierarchical Names for New AS-SETs > > * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > > * Proposal URL: > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > Last Call closes on: July 31, 2026, at 23:59 UTC. > > > 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. > > > As always, we kindly request that all participants adhere to the AFRINIC > Code of Conduct to maintain a respectful > and professional environment on the mailing list. > > > Kind regards, > > > Haitham el Nakhal > > AFRINIC PDWG Co-Chair > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From seun.ojedeji at gmail.com Sun Jul 19 00:21:04 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Sat, 18 Jul 2026 19:21:04 -0500 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <1784239787450.20999@tra.gov.eg> Message-ID: Hello Bakenon, Do refer to the proposal as it references URL to other RIR's policies for thiis: https://www.afrinic.net/afpub-2026-asn-001-draft02.html Regards ---- Sent from my mobile kindly excuse typos On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, wrote: > Dear PDWG, > > I have been following the discussions on the hierarchical AS?SET naming > scheme and would like clarification on a few points: > > 1. Could this matter be addressed operationally, as is done in ARIN, > LACNIC, and RIPE NCC, without requiring policy changes? > > 2. If yes, why are we taking the policy route? Is it because AFRINIC > currently lacks a defined process for handling operational issues that > affect IRR services? > > 3. Given that the hierarchical naming scheme is already supported and > currently exists within the IRR, this proposal represents an enforcement > change rather than the introduction of a new technical standard. Why is a > formal policy required to change an operational enforcement setting, rather > than a community-vetted technical implementation plan?" > > Thank you. > --- > Kone > > > > Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal a > ?crit : > >> Dear PDWG, >> >> >> The Policy Development Working Group (PDWG) Chairs have initiated a Last >> Call for this proposal, following rough consensus at the AFRINIC-37 Public >> Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. >> >> * Proposal Name: Hierarchical Names for New AS-SETs >> >> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >> >> * Proposal URL: >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >> Last Call closes on: July 31, 2026, at 23:59 UTC. >> >> >> 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. >> >> >> As always, we kindly request that all participants adhere to the AFRINIC >> Code of Conduct to maintain a respectful >> and professional environment on the mailing list. >> >> >> Kind regards, >> >> >> Haitham el Nakhal >> >> AFRINIC PDWG Co-Chair >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Sun Jul 19 04:14:10 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Sun, 19 Jul 2026 06:14:10 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 45 In-Reply-To: References: Message-ID: Dear colleagues, The point about voluntary naming is where the argument breaks down. Hierarchical naming only protects you if the namespace is closed ? if flat names remain creatable, any third party can still register a name that collides with or shadows yours, and your voluntary good behaviour does nothing to stop it. That is why every other RIR made it mandatory rather than advisory: the protection is only real when it's universal. On measurable harm: tools like bgpq4 expand AS-SET names, not ASNs, so when a name is ambiguous the generated prefix-filter can silently include the wrong prefixes or drop the right ones. That is a routing outcome, not a labelling aesthetic ? and it is precisely the "accurate routing information" you say the registry should support. On least-restrictive: this proposal already is the minimum ? new objects only, no renaming, no other set types, no ongoing registry discretion. It is hard to describe a narrower intervention that still closes the namespace. And the point about other RIRs isn't an appeal to conformity; IRR data is consumed globally as a single namespace by operators who query multiple sources, so AFRINIC remaining the one registry that permits flat names doesn't preserve our independence ? it just makes our data the weak link in everyone else's filters. Finally, responding to objections individually is engaging with them on their merits; that is what the process asks for. Regards On 18 Jul 2026, at 21:49, Nia Petronella wrote: > Dear PDWG, > > I agree with Asamkele, Gugu, and Tshepo, and I remain opposed to this > proposal. > > Responding to objectors one by one does not resolve the common concern they > have raised. A collision between AS-SET labels is not a failure of ASN or > prefix uniqueness, and repeating that characterization does not make it > technically correct. > > The proposal still has not demonstrated measurable operational harm, why > voluntary hierarchical naming is insufficient, or why mandatory registry > intervention is the least restrictive solution. Adoption by other RIRs is > relevant, but institutional uniformity is not proof of technical necessity. > > A policy process should examine objections on their merits, not treat > repeated disagreement as something to be individually overcome. The > registry should support accurate routing information without converting > every preferred convention into compulsory policy. > > I therefore support the objections already raised and maintain my > opposition. > > Regards, > Nonhlanhla > > On Sat, 18 Jul 2026, 9:46 pm wrote: > >> Send RPD mailing list submissions to >> rpd at afrinic.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.afrinic.net/mailman/listinfo/rpd >> or, via email, send a message with subject or body 'help' to >> rpd-request at afrinic.net >> >> You can reach the person managing the list at >> rpd-owner at afrinic.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of RPD digest..." >> >> >> Today's Topics: >> >> 1. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage) >> 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Asamkele Menzeleli) >> 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Gugu Dhlamini) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Sat, 18 Jul 2026 20:28:16 +0200 >> From: Hendrik Visage >> To: Asamkele Menzeleli >> Cc: rpd-owner at afrinic.net, rpd at afrinic.net >> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> Message-ID: <6F54C5B9-4C90-42F4-ACFD-6E4C57F5BD66 at hevis.co.za> >> Content-Type: text/plain; charset="utf-8"; Format="flowed" >> >> Hello Asamkele, >> Respectfully, this proposal does exactly what you're asking for ? it >> maintains uniqueness. Flat AS-SET names can be registered by anyone, so >> two operators can create the same name and there is no way to tell >> afterwards which ASN it belongs to. That is a uniqueness failure in the >> registry's own data, and fixing it is squarely within the mandate you >> describe, not an expansion of it. The proposal adds no governance layer: >> it applies only to newly created AS-SETs, leaves existing objects >> untouched, and doesn't extend to route-sets or anything else. And the >> operational necessity is already demonstrated ? APNIC, RIPE, ARIN, and >> LACNIC have all implemented hierarchical AS-SET naming, which would >> leave AFRINIC as the only registry whose IRR data still permits name >> collisions. >> Regards >> >> --- >> 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 >> >> On 17 Jul 2026, at 19:26, Asamkele Menzeleli wrote: >> >>> Hello everyone, >>> >>> I object to this proposal. >>> >>> I also agree with Nonhlanhla's point regarding mandate laundering. We >>> should be careful not to confuse policy development with expanding >>> institutional authority. >>> >>> Policies should reflect demonstrated operational realities and >>> technical >>> necessity. They should not become governance mechanisms that gradually >>> enlarge the registry's role beyond maintaining uniqueness, accurate >>> records, and operational coordination. >>> >>> A registry should record reality, not create new layers of governance >>> through policy. >>> >>> Regards, >>> Asamkele Menzeleli >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> https://lists.afrinic.net/pipermail/rpd/attachments/20260718/cd333640/attachment-0001.html >>> >> >> ------------------------------ >> >> Message: 2 >> Date: Sat, 18 Jul 2026 21:05:38 +0200 >> From: Asamkele Menzeleli >> To: rpd at afrinic.net >> Cc: rpd-owner at afrinic.net >> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> Message-ID: >> > Yxp+MhGJFpQ at mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Dear Hendrik, >> >> I disagree with your characterization. >> >> A collision between two AS-SET names is not the same as a failure of >> Internet number-resource uniqueness. The uniqueness function of the >> registry concerns ASNs, prefixes, proof of control and accurate >> registration of those resources. An AS-SET is an operational routing-policy >> object. Confusing the naming convention of that object with the uniqueness >> of the underlying number resource expands the meaning of ?uniqueness? far >> beyond its proper technical scope. >> >> The fact that two operators may choose the same flat label may justify >> better tooling, clearer warnings, stronger validation or voluntary >> hierarchical naming. It does not automatically justify a mandatory policy >> rule. >> >> That distinction is precisely the concern I raised. Institutional authority >> often expands by redefining a useful administrative preference as a >> technical necessity. Once every data-quality issue is described as a >> uniqueness failure, there is effectively no limit to what may be brought >> into mandatory registry policy. >> >> The proposal?s limited scope does not answer that concern. A new >> enforcement power does not cease to be enforcement merely because it >> applies prospectively or begins with one object type. The correct test is >> whether the rule is indispensable to preserving the operation of running >> networks, and whether a less restrictive mechanism cannot achieve the same >> outcome. >> >> You also repeat that the other four RIRs have implemented hierarchical >> naming. That demonstrates institutional adoption elsewhere. It does not >> demonstrate that AFRINIC operators have authorized the same rule, that >> actual routing failures in this region require it, or that voluntary and >> technical alternatives are inadequate. Four registries making the same >> choice is not a substitute for evidence. >> >> A registry should record operational reality accurately and provide >> operators with tools to manage routing information safely. It should not >> turn every preferred convention into mandatory governance merely because >> uniformity looks tidy from the registry side. >> >> My objection therefore remains. The proposal has not shown that compulsory >> hierarchical naming is necessary to protect number-resource uniqueness, nor >> that the registry should extend its mandatory policy authority into this >> area. >> >> Regards, >> Asamkele Menzeleli >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> https://lists.afrinic.net/pipermail/rpd/attachments/20260718/e46cf6c9/attachment-0001.html >>> >> >> ------------------------------ >> >> Message: 3 >> Date: Sat, 18 Jul 2026 21:45:03 +0200 >> From: Gugu Dhlamini >> To: "asamkele.menzeleli18 at maharishinstitute.org" >> , " >> hvisage at hevis.co.za" >> , rpd at afrinic.net, rpd-owner at afrinic.net >> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> Message-ID: >> < >> CADMrvbPw1Dyu7JU9unFWz4zTZSd4QGQdMup_ibDd9nKcWwuP-w at mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Dear PDWG, >> >> I agree with Asamkele and disagree with Hendrik?s perspective. >> >> This is substantially the same argument Hendrik made in response to Tshepo: >> that because a naming collision can occur, the issue must therefore be >> treated as a failure of registry uniqueness and made subject to mandatory >> policy. That conclusion does not follow. >> >> A collision between AS-SET labels is not the same as duplicate allocation >> of an ASN or IP prefix. The underlying number resources remain unique. What >> is being discussed is the naming and interpretation of an operational >> routing object. That may justify better tools, warnings, validation, >> documentation, or voluntary hierarchical naming, but it does not >> automatically justify expanding mandatory registry authority. >> >> There is also an important ethical question here. Policy power should not >> be enlarged merely because the proposed requirement appears useful, tidy, >> or widely adopted elsewhere. The burden lies with those seeking compulsion >> to show actual harm, necessity, proportionality, and the failure of less >> restrictive alternatives. Operators should not be forced to surrender >> discretion simply because an institution prefers uniformity. >> >> The fact that four other RIRs adopted a similar convention is not proof >> that AFRINIC must do the same. Institutional repetition is not technical >> necessity, and participation in the PDWG should not become a ritual for >> ratifying choices already made elsewhere. >> >> The registry should preserve number-resource uniqueness, registry accuracy, >> and operational continuity. It should not stretch those concepts until >> every preferred operational convention becomes mandatory policy. >> >> For these reasons, I support Asamkele?s objection and remain opposed to the >> proposal. >> >> Regards, >> Nonhlanhla >> On Sat, 18 Jul 2026, 9:08 pm Asamkele Menzeleli < >> asamkele.menzeleli18 at maharishinstitute.org> wrote: >> >>> Dear Hendrik, >>> >>> I disagree with your characterization. >>> >>> A collision between two AS-SET names is not the same as a failure of >>> Internet number-resource uniqueness. The uniqueness function of the >>> registry concerns ASNs, prefixes, proof of control and accurate >>> registration of those resources. An AS-SET is an operational >> routing-policy >>> object. Confusing the naming convention of that object with the >> uniqueness >>> of the underlying number resource expands the meaning of ?uniqueness? far >>> beyond its proper technical scope. >>> >>> The fact that two operators may choose the same flat label may justify >>> better tooling, clearer warnings, stronger validation or voluntary >>> hierarchical naming. It does not automatically justify a mandatory policy >>> rule. >>> >>> That distinction is precisely the concern I raised. Institutional >>> authority often expands by redefining a useful administrative preference >> as >>> a technical necessity. Once every data-quality issue is described as a >>> uniqueness failure, there is effectively no limit to what may be brought >>> into mandatory registry policy. >>> >>> The proposal?s limited scope does not answer that concern. A new >>> enforcement power does not cease to be enforcement merely because it >>> applies prospectively or begins with one object type. The correct test is >>> whether the rule is indispensable to preserving the operation of running >>> networks, and whether a less restrictive mechanism cannot achieve the >> same >>> outcome. >>> >>> You also repeat that the other four RIRs have implemented hierarchical >>> naming. That demonstrates institutional adoption elsewhere. It does not >>> demonstrate that AFRINIC operators have authorized the same rule, that >>> actual routing failures in this region require it, or that voluntary and >>> technical alternatives are inadequate. Four registries making the same >>> choice is not a substitute for evidence. >>> >>> A registry should record operational reality accurately and provide >>> operators with tools to manage routing information safely. It should not >>> turn every preferred convention into mandatory governance merely because >>> uniformity looks tidy from the registry side. >>> >>> My objection therefore remains. The proposal has not shown that >> compulsory >>> hierarchical naming is necessary to protect number-resource uniqueness, >> nor >>> that the registry should extend its mandatory policy authority into this >>> area. >>> >>> Regards, >>> Asamkele Menzeleli >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> https://lists.afrinic.net/pipermail/rpd/attachments/20260718/7d3628bc/attachment.html >>> >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ------------------------------ >> >> End of RPD Digest, Vol 222, Issue 45 >> ************************************ >> > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From hvisage at hevis.co.za Sun Jul 19 04:15:36 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Sun, 19 Jul 2026 06:15:36 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: <06FBDEC1-29B0-41E6-B87E-A8EC62C42F22@hevis.co.za> Dear Asamkele, The distinction you draw doesn't survive contact with how the objects actually work: an AS-SET name is not merely a label, it is the authorization anchor for the object. Under RFC 2622 hierarchical naming, the leading AS number binds the set to a resource the registry has already uniquely assigned, so only the maintainer of that ASN can create or modify it ? proof of control, which you agree is core registry function, is derived directly from the name. A flat name has no such binding, which means the registry is accepting objects it cannot attribute to any resource holder; that is not a data-quality preference, it is an authorization gap in the registry's own database. This is also why voluntary naming cannot solve it: hierarchy protects you only if the flat namespace is closed, because as long as anyone can create AS-EXAMPLE, your careful use of AS65000:AS-EXAMPLE does nothing to stop a third party from registering a colliding or shadowing set that expands into your customer cone. The harm is concrete and regional in effect regardless of where the query originates ? bgpq4, IRRToolSet and similar expand AS-SET names, so an ambiguous name yields a prefix-list that either admits prefixes the operator never authorized or omits ones it did, and the resulting leak or blackhole lands on AFRINIC networks. Better tooling and warnings cannot close this, because the ambiguity exists in the data the tooling consumes, not in the tooling itself. As for scope: rejecting the creation of unauthorizable objects is the same function the registry already performs when it refuses an unauthenticated route object ? it is the existing mandate applied consistently, not a new one, and applying it prospectively to a single object type is the least restrictive form in which it can achieve the outcome at all. Regards --- 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 On 18 Jul 2026, at 21:05, Asamkele Menzeleli wrote: > Dear Hendrik, > > I disagree with your characterization. > > A collision between two AS-SET names is not the same as a failure of > Internet number-resource uniqueness. The uniqueness function of the > registry concerns ASNs, prefixes, proof of control and accurate > registration of those resources. An AS-SET is an operational > routing-policy > object. Confusing the naming convention of that object with the > uniqueness > of the underlying number resource expands the meaning of > ?uniqueness? far > beyond its proper technical scope. > > The fact that two operators may choose the same flat label may justify > better tooling, clearer warnings, stronger validation or voluntary > hierarchical naming. It does not automatically justify a mandatory > policy > rule. > > That distinction is precisely the concern I raised. Institutional > authority > often expands by redefining a useful administrative preference as a > technical necessity. Once every data-quality issue is described as a > uniqueness failure, there is effectively no limit to what may be > brought > into mandatory registry policy. > > The proposal?s limited scope does not answer that concern. A new > enforcement power does not cease to be enforcement merely because it > applies prospectively or begins with one object type. The correct test > is > whether the rule is indispensable to preserving the operation of > running > networks, and whether a less restrictive mechanism cannot achieve the > same > outcome. > > You also repeat that the other four RIRs have implemented hierarchical > naming. That demonstrates institutional adoption elsewhere. It does > not > demonstrate that AFRINIC operators have authorized the same rule, that > actual routing failures in this region require it, or that voluntary > and > technical alternatives are inadequate. Four registries making the same > choice is not a substitute for evidence. > > A registry should record operational reality accurately and provide > operators with tools to manage routing information safely. It should > not > turn every preferred convention into mandatory governance merely > because > uniformity looks tidy from the registry side. > > My objection therefore remains. The proposal has not shown that > compulsory > hierarchical naming is necessary to protect number-resource > uniqueness, nor > that the registry should extend its mandatory policy authority into > this > area. > > Regards, > Asamkele Menzeleli -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Sun Jul 19 04:23:41 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Sun, 19 Jul 2026 06:23:41 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <8F6E7DF6-5C1E-4181-B07F-F96E2C1FA2ED@controlfreak.co.za> Message-ID: <80F134B2-CDD2-49E9-B64D-3BF67FDCE535@hevis.co.za> Well said both Seun & Nishal. Being a very young operator, actually running a multi-homed network, I quickly realized that hierarchical AS-SETS should be mandatory, not just ?optional?, Not only from technical and operational reasons, but also for AfriNIC to be a good Netizen in the global Internet --- 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 On 18 Jul 2026, at 22:10, Seun Ojedeji wrote: > Well said Nishal and since it seem Nia, Asamkele, Gugu, and Tshepo, > agree > on the same philosophy and infact they share similar content, perhaps > they > can form co authors to propose what they feel is a better policy. > > However for now I support AFPUB-2026-ASN-001-DRAFT02 to move pass the > last > call. > > Regards > > ---- > Sent from my mobile > kindly excuse typos > > > > On Sat, 18 Jul 2026, 2:59?pm Nishal Goburdhan, > > wrote: > >> >> >> On 18 Jul 2026, at 21:05, Asamkele Menzeleli wrote: >> >>> My objection therefore remains. The proposal has not shown that >> compulsory >>> hierarchical naming is necessary to protect number-resource >>> uniqueness, >> nor >>> that the registry should extend its mandatory policy authority into >>> this >>> area. >> >> >> what you meant to say is that it hasn?t shown this ?to you?. >> and that?s ok; policy proposals are never about appeasing >> everyone. they >> are about making incremental benefit. >> what you are not seeing, is that this solution, has already been >> demonstrated elsewhere in the world, has actually solved >> Real-World-Operational problems. >> you?re forgiven if you don?t see these problems - again - not >> everyone >> lives and speaks bgp. >> >> but maybe i?m wrong - and maybe you *have* found a better sauce to >> solving >> these problems; problems which, real world network operators, have >> already >> shown can be exploited, to significant detriment. in which case, >> please >> share that, because we?d love to benefit from your operational >> prowess. >> but, f you haven?t - either found that sauce, or, are unwilling to >> share, >> then appreciate that those of us that operate real networks, want the >> better protections that this proposal brings. even if you don?t. >> here?s >> the thing; the threat that ?flat? names creates has already done >> this - >> ie. they *have* been exploited, for no good, in the wild. this is >> already >> well documented, and discussed in operator forums. and the >> objections as i >> read them - and however strongly you may feel about them - haven?t >> failed >> to address any kind of solution, or provided a technical alternate, >> or, >> actually done anything except say: ?well, i don?t agree? >> >> also, as a tip, the last call part of the proposal is where you >> address >> concerns that the _particular policy_ might have. you haven?t >> really done >> any of that. so please, try to focus your the discussion on >> _technical >> merit solely_. here?s what would help: >> - show an alternate solution by a vendor / from a technical list >> - show real world problems that this creates, as documented on a >> technical >> forum (eg. afnog, sidr, secops, ..) >> >> no-one here has all the answers; and, if we discover in 10years, >> that >> ?flat? names were better, no penguins would have been harmed. >> but, we >> would have enabled protections for african operators. >> >> ?n. >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah at neo.co.tz Sun Jul 19 05:00:04 2026 From: noah at neo.co.tz (Noah) Date: Sun, 19 Jul 2026 08:00:04 +0300 Subject: [rpd] [External] Re: IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 In-Reply-To: <1784416088278.30395@tra.gov.eg> References: <1783459420709.11832@tra.gov.eg> <1784416088278.30395@tra.gov.eg> Message-ID: Hello Co-chair Since the website is still broken and the rpd mailing is not broken. The PPM minutes can be published in document format perhaps as a pdf and sent to the broader working group via email to this rpd list. Cheers, *.**/noah* On Sun, 19 Jul 2026, 2:16?am Hytham El-Nakhal, wrote: > Dear Arnaud, > > The PPM minutes are ready to be published within the normal time frame as > per CPM and in same day with the Last Call, but there was a technical > problem on the new static website for AFRINIC with the links for the policy > proposals' ppt and other hyperlinks. The IT staff and the Policy Liaison > Team are doing their best to fix the issue as soon as possible. Meanwhile > you can find the discussions happened during the PPM day, authors ppt. and > the staff analysis here: https://www.youtube.com/watch?v=uwjG1_XwKV8 > > Appreciate your patience. > > Regards, > Haitham el Nakhal > PDWG Co-Chair > ________________________________________ > From: Arnaud AMELINA [amelnaud at gmail.com] > Sent: Sunday, July 19, 2026 12:39 AM > To: Hytham El-Nakhal > Cc: rpd at afrinic.net > Subject: [External] Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT02 > > Dear Co?chairs, Section 3.4 of the CPM sets a three?week deadline for > publishing PPM minutes. This deadline has now passed, yet the minutes are > still unavailable. It is therefore difficult to understand how Last Call > was initiated without these minutes, and without a summary of how the RPD > and PPM discussions led to the determination of rough consensus. These > elements are essential for the Working Group to participate meaningfully in > Last Call. Thank you. > > Regards > -- > Arnaud > > > Le mar. 7 juil. 2026 ? 21:25, Hytham El-Nakhal hytham at tra.gov.eg>> a ?crit : > Dear PDWG, > > > I have noticed some mails from community members regarding the policy > proposal "IPv6 as a criteria in IPv4 Soft Landing > AFPUB-2026-v6-001-DRAFT01". > > > The author has updated the proposal (DRAFT02), and it was discussed during > the AFRINIC-37 PPM on 24th June 2026. > > > The updated proposal is attached to this email to bring you up to speed > with its contents [pending the re-establishment of the AFRINIC website by > COB 8th July as communicated by AFRINIC]. > > The updated proposal did not reach consensus at the AFRINIC-37 PPM and was > sent back to the RPD mailing-list for further discussions. > > > Those who missed the discussions still have access the AF-37 PPM > proceedings here: https://www.youtube.com/watch?v=uwjG1_XwKV8 . > > > Therefore, it is highly recommended that participants thoroughly review > the attached proposal, familiarize themselves with prior discussions on the > mailing list and during the Public Policy Meeting, and subsequently focus > their valuable contribution by undertaking any of the following actions: > > * - Seek clarifications regarding the policy text and offer > recommendations for its improvement; > * - Express formal support for the proposal; or, > * - Provide a detailed justification in case of opposition to the > policy as drafted. > > > Best Regards, > Haitham el Nakhal > PDWG Co-Chair > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah at neo.co.tz Sun Jul 19 05:44:13 2026 From: noah at neo.co.tz (Noah) Date: Sun, 19 Jul 2026 08:44:13 +0300 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: On Sat, 18 Jul 2026, 10:12?pm Asamkele Menzeleli, < asamkele.menzeleli18 at maharishinstitute.org> wrote: > Dear Hendrik, > Hi Asamkele, > > > I disagree with your characterization. > > A collision between two AS-SET names is not the same as a failure of > Internet number-resource uniqueness. > So, while you are somewhat correct on that very narrow point, its still irrelevant imho. The issue is namespace integrity and authorization for policy objects in a globally mirrored system. RFC 2622 hierarchical naming was invented exactly to solve this. Collisions break automated tools that networks rely on for prefix filtering and I mean really technically breaks ....FYI An AS-SET is an operational routing-policy object. Confusing the naming > convention of that object with the uniqueness of the underlying number > resource expands the meaning of ?uniqueness? far beyond its proper > technical scope. > > The fact that two operators may choose the same flat label may justify > better tooling, clearer warnings, stronger validation or voluntary > hierarchical naming. It does not automatically justify a mandatory policy > rule. > > That distinction is precisely the concern I raised. Institutional > authority often expands by redefining a useful administrative preference as > a technical necessity. Once every data-quality issue is described as a > uniqueness failure, there is effectively no limit to what may be brought > into mandatory registry policy. > > The proposal?s limited scope does not answer that concern. A new > enforcement power does not cease to be enforcement merely because it > applies prospectively or begins with one object type. The correct test is > whether the rule is indispensable to preserving the operation of running > networks, and whether a less restrictive mechanism cannot achieve the same > outcome > See my response above .... > You also repeat that the other four RIRs have implemented hierarchical > naming. That demonstrates institutional adoption elsewhere. It does not > demonstrate that AFRINIC operators have authorized the same rule, that > actual routing failures in this region require it, or that voluntary and > technical alternatives are inadequate. Four registries making the same > choice is not a substitute for evidence. > Firstly, the AFRINIC service region is not an isolated island. Other RIRs so the need to implement this after experiencing the same cross-IRR collision and perhaps incidents of unauthorized creation problems. There was a problem and they so it fit to fix it. Hence APNIC prop-151, a full PDP process as an example. Therefore imho, It is a broader convergence on a technical solution to a shared defect in the IRR ecosystem, not arbitrary uniformity. AFRINIC operators already benefit from that very same protection the other RIR have put in place and we not doing it is accepting an existing bug is the system to continue existing hence the PDWG support you are seeing from technical community. > A registry should record operational reality accurately and provide > operators with tools to manage routing information safely. It should not > turn every preferred convention into mandatory governance merely because > uniformity looks tidy from the registry side. > Well there is only so much a registry can do. We the community have been empowered to develop policies that support the operations aspects of the RIR. When voluntary adoption + guidance has continued to demonstrably failed for years (non-hierarchical sets are still being created), and when the failure mode enables unauthorized objects that can disrupt routing, enforcement at creation time becomes the proportionate response. This is exactly what RIPE, APNIC, and others concluded. > My objection therefore remains. The proposal has not shown that compulsory > hierarchical naming is necessary to protect number-resource uniqueness, nor > that the registry should extend its mandatory policy authority into this > area. > Actually the risk here is global and probabilistic. And I say so, because by not resolving IRRs merge in all five registry databases, a colliding or squatted AS-SET created in AFRINIC db can affect networks widely (and vice versa). Waiting for an AFRINIC-specific outage before acting is reactive rather than responsible stewardship of the registry and the community is already empowered to always look out for solutions to better RIR operations some of which are policy driven. Cheers, *.**/noah* -------------- next part -------------- An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Sun Jul 19 06:39:18 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Sun, 19 Jul 2026 06:39:18 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear Nishal and Seun, I disagree with both responses. First, this is not about whether the proposal has persuaded one particular participant. The objection is that those seeking mandatory registry enforcement have not demonstrated that compulsion is necessary, proportionate, and technically sufficient. ?Incremental benefit? is not the correct threshold for mandatory policy. Many operational practices may offer some benefit. That does not mean every useful convention should be elevated into a compulsory registry rule. The common policy layer should contain only what running networks genuinely require for uniqueness, interoperability, security integrity, proof of control, and continuity. Second, citing deployment in other regions does not settle the matter. Adoption elsewhere is evidence, not authority. AFRINIC should not govern by institutional imitation. The fact that other RIRs have implemented hierarchical naming does not prove that this proposal is the minimum necessary solution for AFRINIC operators, nor that the same operational outcomes could not be achieved through thinner mechanisms. Third, hierarchical naming does not solve the whole problem being used to justify it. It may identify the ASN holder responsible for creating an AS-SET. It does not prove that every ASN, route, or customer relationship listed inside that set is accurate or authorised. It authenticates the maintainer of the container, not the truth of its contents. That distinction is not academic. Prefix-generation tools consume the membership of the AS-SET. An authorised maintainer can still publish stale, incomplete, excessive, or incorrect membership. The proposal therefore improves attribution, but it does not transform AS-SET expansion into verified routing authorisation. Fourth, the suggestion that only those who ?live and speak BGP? may raise valid objections is misplaced. Operational experience is valuable evidence. It is not a mandate to dismiss questions about proportionality, institutional scope, implementation risk, or policy design. Technical competence should discipline power. It should not become a credential used to silence scrutiny. A policy room is not an operators? guild. Participation is not conditional on passing an informal test imposed by those supporting the proposal. Fifth, objectors are not required to produce a replacement policy before opposing this one. That reverses the burden. The party proposing a new mandatory rule must prove that: - the harm is clearly defined and evidenced; - the proposed rule materially prevents that harm; - less restrictive mechanisms are inadequate; - residual risks are understood; - and the additional registry authority is proportionate. Possible alternatives have already been identified: source-qualified references, collision detection, stronger validation, clearer tooling, warnings, explicit object provenance, and voluntary hierarchical adoption. Supporters may disagree with those alternatives, but they cannot pretend no alternatives have been raised. Seun?s suggestion that participants with similar concerns should become co-authors of another policy misses the point. Similar objections do not become invalid because several people independently reach the same conclusion. Participation is evidence, warning, and technical judgment. It is not weakened by agreement. Nor should the last-call stage be reduced to a demand that objectors prove harm caused by the proposed rule while supporters are excused from proving necessity for compulsion. Last call is precisely where unresolved questions of scope, proportionality, technical sufficiency, and mandate must be tested. The Internet was not built by making every preferred practice mandatory. It was built through thin common rules, operator judgment, implementation, and adoption. Policy should describe operational reality where a true invariant requires coordination. It should not declare a preferred future and then use the registry to compel it. The proposal may offer a useful convention. That is not the same as proving a legitimate mandatory rule. For those reasons, I remain opposed to AFPUB-2026-ASN-001-DRAFT02. Regards, Tshepo -------------- next part -------------- An HTML attachment was scrubbed... URL: From gugudhlamini343 at gmail.com Sun Jul 19 06:54:14 2026 From: gugudhlamini343 at gmail.com (Gugu Dhlamini) Date: Sun, 19 Jul 2026 08:54:14 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 45 In-Reply-To: References: Message-ID: Dear Hendrik, I remain firmly opposed to your viewpoint, and I agree with Nonhlanhla. Your argument establishes that a closed hierarchical namespace can prevent future creation of flat-name collisions. It does not establish that this proposal solves the broader routing-authorisation problem being used to justify mandatory policy. The distinction remains important. Hierarchical naming can bind the creator of an AS-SET to the maintainer of an ASN. It does not verify that the contents of the set are accurate, current, complete, or authorised by every network represented within it. A hierarchically named object can still contain stale, excessive, or incorrect members. Tools such as bgpq4 will still expand those contents. The proposal therefore reduces one source of ambiguity. It does not make generated prefix filters inherently trustworthy. That matters because the policy is being defended not merely as a naming improvement, but as a necessary routing-security protection. The claimed benefit should be described honestly and proportionately. Attribution is improved. Semantic correctness is not guaranteed. The remaining failure modes do not disappear because the namespace has been closed. You also describe the proposal as the minimum intervention because it applies only to new AS-SETs. Narrow scope is relevant, but it does not by itself prove necessity. A rule may be small and still place an optional operational convention into the mandatory registry layer without first demonstrating that other technical controls are inadequate. The alternatives are not limited to voluntary good behaviour. They include explicit IRR source qualification, provenance display, collision detection, deterministic validation, tooling that refuses ambiguous references, stronger object-level authorization signals, and local rejection of untrusted data. The relevant question is whether those mechanisms can prevent silent ambiguity without making the registry the universal enforcement point. If a tool silently consumes an ambiguous name across multiple IRRs, that is also a tooling and validation failure. A coordination system should not answer every unsafe consumer assumption by expanding central compulsion at the producer layer. You further say that the namespace must be universal because IRR data is consumed globally. Global consumption does not automatically create global authority for one preferred implementation. It creates a need for clear source semantics, local validation, and explicit compatibility rules. The Internet has always depended on operators deciding which data sources they trust and how they validate them. That responsibility should not be quietly transferred upward each time a tool can be misconfigured or over-trusting. The fact that other RIRs closed their namespaces remains relevant experience. It is still not proof that AFRINIC must do the same through mandatory policy, nor that their adoption eliminated the underlying problem rather than only one visible symptom. A registry should maintain a truthful ledger and support safe coordination. It should not claim more than the proposed mechanism can actually deliver. This proposal prevents future flat-name creation. It does not validate AS-SET membership, guarantee accurate prefix filters, or establish that registry compulsion is the only technically sound response. For those reasons, my objection remains. Regards, Gugu On Sun, 19 Jul 2026, 6:17 am Hendrik Visage via RPD wrote: > Dear colleagues, > The point about voluntary naming is where the argument breaks down. > Hierarchical naming only protects you if the namespace is closed ? if flat > names remain creatable, any third party can still register a name that > collides with or shadows yours, and your voluntary good behaviour does > nothing to stop it. That is why every other RIR made it mandatory rather > than advisory: the protection is only real when it's universal. On > measurable harm: tools like bgpq4 expand AS-SET names, not ASNs, so when a > name is ambiguous the generated prefix-filter can silently include the > wrong prefixes or drop the right ones. That is a routing outcome, not a > labelling aesthetic ? and it is precisely the "accurate routing > information" you say the registry should support. On least-restrictive: > this proposal already is the minimum ? new objects only, no renaming, no > other set types, no ongoing registry discretion. It is hard to describe a > narrower intervention that still closes the namespace. And the point about > other RIRs isn't an appeal to conformity; IRR data is consumed globally as > a single namespace by operators who query multiple sources, so AFRINIC > remaining the one registry that permits flat names doesn't preserve our > independence ? it just makes our data the weak link in everyone else's > filters. Finally, responding to objections individually is engaging with > them on their merits; that is what the process asks for. > Regards > > On 18 Jul 2026, at 21:49, Nia Petronella wrote: > > > Dear PDWG, > > > > I agree with Asamkele, Gugu, and Tshepo, and I remain opposed to this > > proposal. > > > > Responding to objectors one by one does not resolve the common concern > they > > have raised. A collision between AS-SET labels is not a failure of ASN or > > prefix uniqueness, and repeating that characterization does not make it > > technically correct. > > > > The proposal still has not demonstrated measurable operational harm, why > > voluntary hierarchical naming is insufficient, or why mandatory registry > > intervention is the least restrictive solution. Adoption by other RIRs is > > relevant, but institutional uniformity is not proof of technical > necessity. > > > > A policy process should examine objections on their merits, not treat > > repeated disagreement as something to be individually overcome. The > > registry should support accurate routing information without converting > > every preferred convention into compulsory policy. > > > > I therefore support the objections already raised and maintain my > > opposition. > > > > Regards, > > Nonhlanhla > > > > On Sat, 18 Jul 2026, 9:46 pm wrote: > > > >> Send RPD mailing list submissions to > >> rpd at afrinic.net > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> or, via email, send a message with subject or body 'help' to > >> rpd-request at afrinic.net > >> > >> You can reach the person managing the list at > >> rpd-owner at afrinic.net > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of RPD digest..." > >> > >> > >> Today's Topics: > >> > >> 1. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage) > >> 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Asamkele Menzeleli) > >> 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Gugu Dhlamini) > >> > >> > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Sat, 18 Jul 2026 20:28:16 +0200 > >> From: Hendrik Visage > >> To: Asamkele Menzeleli > >> Cc: rpd-owner at afrinic.net, rpd at afrinic.net > >> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >> Message-ID: <6F54C5B9-4C90-42F4-ACFD-6E4C57F5BD66 at hevis.co.za> > >> Content-Type: text/plain; charset="utf-8"; Format="flowed" > >> > >> Hello Asamkele, > >> Respectfully, this proposal does exactly what you're asking for ? it > >> maintains uniqueness. Flat AS-SET names can be registered by anyone, so > >> two operators can create the same name and there is no way to tell > >> afterwards which ASN it belongs to. That is a uniqueness failure in the > >> registry's own data, and fixing it is squarely within the mandate you > >> describe, not an expansion of it. The proposal adds no governance layer: > >> it applies only to newly created AS-SETs, leaves existing objects > >> untouched, and doesn't extend to route-sets or anything else. And the > >> operational necessity is already demonstrated ? APNIC, RIPE, ARIN, and > >> LACNIC have all implemented hierarchical AS-SET naming, which would > >> leave AFRINIC as the only registry whose IRR data still permits name > >> collisions. > >> Regards > >> > >> --- > >> 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 > >> > >> On 17 Jul 2026, at 19:26, Asamkele Menzeleli wrote: > >> > >>> Hello everyone, > >>> > >>> I object to this proposal. > >>> > >>> I also agree with Nonhlanhla's point regarding mandate laundering. We > >>> should be careful not to confuse policy development with expanding > >>> institutional authority. > >>> > >>> Policies should reflect demonstrated operational realities and > >>> technical > >>> necessity. They should not become governance mechanisms that gradually > >>> enlarge the registry's role beyond maintaining uniqueness, accurate > >>> records, and operational coordination. > >>> > >>> A registry should record reality, not create new layers of governance > >>> through policy. > >>> > >>> Regards, > >>> Asamkele Menzeleli > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: < > >> > https://lists.afrinic.net/pipermail/rpd/attachments/20260718/cd333640/attachment-0001.html > >>> > >> > >> ------------------------------ > >> > >> Message: 2 > >> Date: Sat, 18 Jul 2026 21:05:38 +0200 > >> From: Asamkele Menzeleli > >> To: rpd at afrinic.net > >> Cc: rpd-owner at afrinic.net > >> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >> Message-ID: > >> >> Yxp+MhGJFpQ at mail.gmail.com> > >> Content-Type: text/plain; charset="utf-8" > >> > >> Dear Hendrik, > >> > >> I disagree with your characterization. > >> > >> A collision between two AS-SET names is not the same as a failure of > >> Internet number-resource uniqueness. The uniqueness function of the > >> registry concerns ASNs, prefixes, proof of control and accurate > >> registration of those resources. An AS-SET is an operational > routing-policy > >> object. Confusing the naming convention of that object with the > uniqueness > >> of the underlying number resource expands the meaning of ?uniqueness? > far > >> beyond its proper technical scope. > >> > >> The fact that two operators may choose the same flat label may justify > >> better tooling, clearer warnings, stronger validation or voluntary > >> hierarchical naming. It does not automatically justify a mandatory > policy > >> rule. > >> > >> That distinction is precisely the concern I raised. Institutional > authority > >> often expands by redefining a useful administrative preference as a > >> technical necessity. Once every data-quality issue is described as a > >> uniqueness failure, there is effectively no limit to what may be brought > >> into mandatory registry policy. > >> > >> The proposal?s limited scope does not answer that concern. A new > >> enforcement power does not cease to be enforcement merely because it > >> applies prospectively or begins with one object type. The correct test > is > >> whether the rule is indispensable to preserving the operation of running > >> networks, and whether a less restrictive mechanism cannot achieve the > same > >> outcome. > >> > >> You also repeat that the other four RIRs have implemented hierarchical > >> naming. That demonstrates institutional adoption elsewhere. It does not > >> demonstrate that AFRINIC operators have authorized the same rule, that > >> actual routing failures in this region require it, or that voluntary and > >> technical alternatives are inadequate. Four registries making the same > >> choice is not a substitute for evidence. > >> > >> A registry should record operational reality accurately and provide > >> operators with tools to manage routing information safely. It should not > >> turn every preferred convention into mandatory governance merely because > >> uniformity looks tidy from the registry side. > >> > >> My objection therefore remains. The proposal has not shown that > compulsory > >> hierarchical naming is necessary to protect number-resource uniqueness, > nor > >> that the registry should extend its mandatory policy authority into this > >> area. > >> > >> Regards, > >> Asamkele Menzeleli > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: < > >> > https://lists.afrinic.net/pipermail/rpd/attachments/20260718/e46cf6c9/attachment-0001.html > >>> > >> > >> ------------------------------ > >> > >> Message: 3 > >> Date: Sat, 18 Jul 2026 21:45:03 +0200 > >> From: Gugu Dhlamini > >> To: "asamkele.menzeleli18 at maharishinstitute.org" > >> , " > >> hvisage at hevis.co.za" > >> , rpd at afrinic.net, rpd-owner at afrinic.net > >> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >> Message-ID: > >> < > >> CADMrvbPw1Dyu7JU9unFWz4zTZSd4QGQdMup_ibDd9nKcWwuP-w at mail.gmail.com> > >> Content-Type: text/plain; charset="utf-8" > >> > >> Dear PDWG, > >> > >> I agree with Asamkele and disagree with Hendrik?s perspective. > >> > >> This is substantially the same argument Hendrik made in response to > Tshepo: > >> that because a naming collision can occur, the issue must therefore be > >> treated as a failure of registry uniqueness and made subject to > mandatory > >> policy. That conclusion does not follow. > >> > >> A collision between AS-SET labels is not the same as duplicate > allocation > >> of an ASN or IP prefix. The underlying number resources remain unique. > What > >> is being discussed is the naming and interpretation of an operational > >> routing object. That may justify better tools, warnings, validation, > >> documentation, or voluntary hierarchical naming, but it does not > >> automatically justify expanding mandatory registry authority. > >> > >> There is also an important ethical question here. Policy power should > not > >> be enlarged merely because the proposed requirement appears useful, > tidy, > >> or widely adopted elsewhere. The burden lies with those seeking > compulsion > >> to show actual harm, necessity, proportionality, and the failure of less > >> restrictive alternatives. Operators should not be forced to surrender > >> discretion simply because an institution prefers uniformity. > >> > >> The fact that four other RIRs adopted a similar convention is not proof > >> that AFRINIC must do the same. Institutional repetition is not technical > >> necessity, and participation in the PDWG should not become a ritual for > >> ratifying choices already made elsewhere. > >> > >> The registry should preserve number-resource uniqueness, registry > accuracy, > >> and operational continuity. It should not stretch those concepts until > >> every preferred operational convention becomes mandatory policy. > >> > >> For these reasons, I support Asamkele?s objection and remain opposed to > the > >> proposal. > >> > >> Regards, > >> Nonhlanhla > >> On Sat, 18 Jul 2026, 9:08 pm Asamkele Menzeleli < > >> asamkele.menzeleli18 at maharishinstitute.org> wrote: > >> > >>> Dear Hendrik, > >>> > >>> I disagree with your characterization. > >>> > >>> A collision between two AS-SET names is not the same as a failure of > >>> Internet number-resource uniqueness. The uniqueness function of the > >>> registry concerns ASNs, prefixes, proof of control and accurate > >>> registration of those resources. An AS-SET is an operational > >> routing-policy > >>> object. Confusing the naming convention of that object with the > >> uniqueness > >>> of the underlying number resource expands the meaning of ?uniqueness? > far > >>> beyond its proper technical scope. > >>> > >>> The fact that two operators may choose the same flat label may justify > >>> better tooling, clearer warnings, stronger validation or voluntary > >>> hierarchical naming. It does not automatically justify a mandatory > policy > >>> rule. > >>> > >>> That distinction is precisely the concern I raised. Institutional > >>> authority often expands by redefining a useful administrative > preference > >> as > >>> a technical necessity. Once every data-quality issue is described as a > >>> uniqueness failure, there is effectively no limit to what may be > brought > >>> into mandatory registry policy. > >>> > >>> The proposal?s limited scope does not answer that concern. A new > >>> enforcement power does not cease to be enforcement merely because it > >>> applies prospectively or begins with one object type. The correct test > is > >>> whether the rule is indispensable to preserving the operation of > running > >>> networks, and whether a less restrictive mechanism cannot achieve the > >> same > >>> outcome. > >>> > >>> You also repeat that the other four RIRs have implemented hierarchical > >>> naming. That demonstrates institutional adoption elsewhere. It does not > >>> demonstrate that AFRINIC operators have authorized the same rule, that > >>> actual routing failures in this region require it, or that voluntary > and > >>> technical alternatives are inadequate. Four registries making the same > >>> choice is not a substitute for evidence. > >>> > >>> A registry should record operational reality accurately and provide > >>> operators with tools to manage routing information safely. It should > not > >>> turn every preferred convention into mandatory governance merely > because > >>> uniformity looks tidy from the registry side. > >>> > >>> My objection therefore remains. The proposal has not shown that > >> compulsory > >>> hierarchical naming is necessary to protect number-resource uniqueness, > >> nor > >>> that the registry should extend its mandatory policy authority into > this > >>> area. > >>> > >>> Regards, > >>> Asamkele Menzeleli > >>> _______________________________________________ > >>> RPD mailing list > >>> RPD at afrinic.net > >>> https://lists.afrinic.net/mailman/listinfo/rpd > >>> > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: < > >> > https://lists.afrinic.net/pipermail/rpd/attachments/20260718/7d3628bc/attachment.html > >>> > >> > >> ------------------------------ > >> > >> Subject: Digest Footer > >> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> > >> > >> ------------------------------ > >> > >> End of RPD Digest, Vol 222, Issue 45 > >> ************************************ > >> > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Sun Jul 19 06:56:56 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Sun, 19 Jul 2026 08:56:56 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 45 In-Reply-To: References: Message-ID: Dear Hendrik, I agree with Gugu, Tshepo, and Asamkele, and I remain firmly opposed to this proposal. Your argument proves that mandatory hierarchical naming can close one path to future flat-name collisions. It does not prove that the proposal secures the routing information consumed by operators. That difference is fundamental. A hierarchical name authenticates the maintainer permitted to create the object under an ASN. It does not authenticate every member placed inside that object. It does not prove that the represented customer cone is complete, current, or authorised. It does not prevent an authorised maintainer from publishing stale, excessive, mistaken, or misleading membership. The tools you cite expand the contents of an AS-SET. They do not merely validate the parent ASN in its name. Closing the namespace may improve provenance, but it does not make the expanded data true. The proposal is therefore being credited with a security outcome it cannot deliver. It reduces one ambiguity while leaving the central semantic risk intact. A partial control should be described as a partial control, not elevated into a universal protection merely because it is easy to enforce at object creation. You also argue that AFRINIC would become the weak link because other RIRs have adopted the rule. That is still institutional convergence being used as a substitute for proving necessity. A globally consumed system requires explicit source identity, deterministic validation, trustworthy provenance, and local rejection of unsafe data. It does not follow that every source must impose the same mandatory naming convention through registry policy. A consumer that merges multiple IRR sources and silently treats an ambiguous name as authoritative has made a validation decision. That design choice cannot simply be transferred upward and converted into a new power for the registry. Unsafe consumption is not cured only by restricting production. Nor is ?new objects only? proof that this is the least restrictive solution. It describes the proposal?s temporal scope. It does not demonstrate that source-qualified queries, collision detection, provenance-aware tooling, ambiguity rejection, or stronger object-content validation are technically inadequate. The minimum intervention is not automatically the smallest rule the registry can enforce. It is the least coercive mechanism that protects the actual invariant. That analysis has not been completed. The broader concern is precisely this pattern: a technical inconvenience is identified, one centralised remedy is proposed, and then the existence of the inconvenience is treated as authority for compulsion. The registry?s role expands one apparently narrow rule at a time. No one announces enforcement creep. It arrives dressed as data hygiene. A registry may maintain accurate records, expose provenance, warn about collisions, and support safer tooling. It should not pretend that controlling the name of a container guarantees the accuracy of what the container says. Responding to objections individually is not itself the problem. The problem is that the same institutional answer is being repeated without resolving the same substantive objection: the proposal authenticates object creation but does not validate object content, and its supporters have not shown why registry compulsion is the minimum necessary response. The common layer must remain thin. It should protect what running networks objectively require, not every convention that an institution can enforce. For these reasons, I support Gugu, Tshepo, and Asamkele, and I maintain my strong opposition to AFPUB-2026-ASN-001-DRAFT02. Regards, Nonhlanhla On Sun, 19 Jul 2026, 6:14 am Hendrik Visage wrote: > Dear colleagues, > The point about voluntary naming is where the argument breaks down. > Hierarchical naming only protects you if the namespace is closed ? if flat > names remain creatable, any third party can still register a name that > collides with or shadows yours, and your voluntary good behaviour does > nothing to stop it. That is why every other RIR made it mandatory rather > than advisory: the protection is only real when it's universal. On > measurable harm: tools like bgpq4 expand AS-SET names, not ASNs, so when a > name is ambiguous the generated prefix-filter can silently include the > wrong prefixes or drop the right ones. That is a routing outcome, not a > labelling aesthetic ? and it is precisely the "accurate routing > information" you say the registry should support. On least-restrictive: > this proposal already is the minimum ? new objects only, no renaming, no > other set types, no ongoing registry discretion. It is hard to describe a > narrower intervention that still closes the namespace. And the point about > other RIRs isn't an appeal to conformity; IRR data is consumed globally as > a single namespace by operators who query multiple sources, so AFRINIC > remaining the one registry that permits flat names doesn't preserve our > independence ? it just makes our data the weak link in everyone else's > filters. Finally, responding to objections individually is engaging with > them on their merits; that is what the process asks for. > Regards > > On 18 Jul 2026, at 21:49, Nia Petronella wrote: > > > Dear PDWG, > > > > I agree with Asamkele, Gugu, and Tshepo, and I remain opposed to this > > proposal. > > > > Responding to objectors one by one does not resolve the common concern > they > > have raised. A collision between AS-SET labels is not a failure of ASN or > > prefix uniqueness, and repeating that characterization does not make it > > technically correct. > > > > The proposal still has not demonstrated measurable operational harm, why > > voluntary hierarchical naming is insufficient, or why mandatory registry > > intervention is the least restrictive solution. Adoption by other RIRs is > > relevant, but institutional uniformity is not proof of technical > necessity. > > > > A policy process should examine objections on their merits, not treat > > repeated disagreement as something to be individually overcome. The > > registry should support accurate routing information without converting > > every preferred convention into compulsory policy. > > > > I therefore support the objections already raised and maintain my > > opposition. > > > > Regards, > > Nonhlanhla > > > > On Sat, 18 Jul 2026, 9:46 pm wrote: > > > >> Send RPD mailing list submissions to > >> rpd at afrinic.net > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> or, via email, send a message with subject or body 'help' to > >> rpd-request at afrinic.net > >> > >> You can reach the person managing the list at > >> rpd-owner at afrinic.net > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of RPD digest..." > >> > >> > >> Today's Topics: > >> > >> 1. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage) > >> 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Asamkele Menzeleli) > >> 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Gugu Dhlamini) > >> > >> > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Sat, 18 Jul 2026 20:28:16 +0200 > >> From: Hendrik Visage > >> To: Asamkele Menzeleli > >> Cc: rpd-owner at afrinic.net, rpd at afrinic.net > >> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >> Message-ID: <6F54C5B9-4C90-42F4-ACFD-6E4C57F5BD66 at hevis.co.za> > >> Content-Type: text/plain; charset="utf-8"; Format="flowed" > >> > >> Hello Asamkele, > >> Respectfully, this proposal does exactly what you're asking for ? it > >> maintains uniqueness. Flat AS-SET names can be registered by anyone, so > >> two operators can create the same name and there is no way to tell > >> afterwards which ASN it belongs to. That is a uniqueness failure in the > >> registry's own data, and fixing it is squarely within the mandate you > >> describe, not an expansion of it. The proposal adds no governance layer: > >> it applies only to newly created AS-SETs, leaves existing objects > >> untouched, and doesn't extend to route-sets or anything else. And the > >> operational necessity is already demonstrated ? APNIC, RIPE, ARIN, and > >> LACNIC have all implemented hierarchical AS-SET naming, which would > >> leave AFRINIC as the only registry whose IRR data still permits name > >> collisions. > >> Regards > >> > >> --- > >> 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 > >> > >> On 17 Jul 2026, at 19:26, Asamkele Menzeleli wrote: > >> > >>> Hello everyone, > >>> > >>> I object to this proposal. > >>> > >>> I also agree with Nonhlanhla's point regarding mandate laundering. We > >>> should be careful not to confuse policy development with expanding > >>> institutional authority. > >>> > >>> Policies should reflect demonstrated operational realities and > >>> technical > >>> necessity. They should not become governance mechanisms that gradually > >>> enlarge the registry's role beyond maintaining uniqueness, accurate > >>> records, and operational coordination. > >>> > >>> A registry should record reality, not create new layers of governance > >>> through policy. > >>> > >>> Regards, > >>> Asamkele Menzeleli > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: < > >> > https://lists.afrinic.net/pipermail/rpd/attachments/20260718/cd333640/attachment-0001.html > >>> > >> > >> ------------------------------ > >> > >> Message: 2 > >> Date: Sat, 18 Jul 2026 21:05:38 +0200 > >> From: Asamkele Menzeleli > >> To: rpd at afrinic.net > >> Cc: rpd-owner at afrinic.net > >> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >> Message-ID: > >> >> Yxp+MhGJFpQ at mail.gmail.com> > >> Content-Type: text/plain; charset="utf-8" > >> > >> Dear Hendrik, > >> > >> I disagree with your characterization. > >> > >> A collision between two AS-SET names is not the same as a failure of > >> Internet number-resource uniqueness. The uniqueness function of the > >> registry concerns ASNs, prefixes, proof of control and accurate > >> registration of those resources. An AS-SET is an operational > routing-policy > >> object. Confusing the naming convention of that object with the > uniqueness > >> of the underlying number resource expands the meaning of ?uniqueness? > far > >> beyond its proper technical scope. > >> > >> The fact that two operators may choose the same flat label may justify > >> better tooling, clearer warnings, stronger validation or voluntary > >> hierarchical naming. It does not automatically justify a mandatory > policy > >> rule. > >> > >> That distinction is precisely the concern I raised. Institutional > authority > >> often expands by redefining a useful administrative preference as a > >> technical necessity. Once every data-quality issue is described as a > >> uniqueness failure, there is effectively no limit to what may be brought > >> into mandatory registry policy. > >> > >> The proposal?s limited scope does not answer that concern. A new > >> enforcement power does not cease to be enforcement merely because it > >> applies prospectively or begins with one object type. The correct test > is > >> whether the rule is indispensable to preserving the operation of running > >> networks, and whether a less restrictive mechanism cannot achieve the > same > >> outcome. > >> > >> You also repeat that the other four RIRs have implemented hierarchical > >> naming. That demonstrates institutional adoption elsewhere. It does not > >> demonstrate that AFRINIC operators have authorized the same rule, that > >> actual routing failures in this region require it, or that voluntary and > >> technical alternatives are inadequate. Four registries making the same > >> choice is not a substitute for evidence. > >> > >> A registry should record operational reality accurately and provide > >> operators with tools to manage routing information safely. It should not > >> turn every preferred convention into mandatory governance merely because > >> uniformity looks tidy from the registry side. > >> > >> My objection therefore remains. The proposal has not shown that > compulsory > >> hierarchical naming is necessary to protect number-resource uniqueness, > nor > >> that the registry should extend its mandatory policy authority into this > >> area. > >> > >> Regards, > >> Asamkele Menzeleli > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: < > >> > https://lists.afrinic.net/pipermail/rpd/attachments/20260718/e46cf6c9/attachment-0001.html > >>> > >> > >> ------------------------------ > >> > >> Message: 3 > >> Date: Sat, 18 Jul 2026 21:45:03 +0200 > >> From: Gugu Dhlamini > >> To: "asamkele.menzeleli18 at maharishinstitute.org" > >> , " > >> hvisage at hevis.co.za" > >> , rpd at afrinic.net, rpd-owner at afrinic.net > >> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >> Message-ID: > >> < > >> CADMrvbPw1Dyu7JU9unFWz4zTZSd4QGQdMup_ibDd9nKcWwuP-w at mail.gmail.com> > >> Content-Type: text/plain; charset="utf-8" > >> > >> Dear PDWG, > >> > >> I agree with Asamkele and disagree with Hendrik?s perspective. > >> > >> This is substantially the same argument Hendrik made in response to > Tshepo: > >> that because a naming collision can occur, the issue must therefore be > >> treated as a failure of registry uniqueness and made subject to > mandatory > >> policy. That conclusion does not follow. > >> > >> A collision between AS-SET labels is not the same as duplicate > allocation > >> of an ASN or IP prefix. The underlying number resources remain unique. > What > >> is being discussed is the naming and interpretation of an operational > >> routing object. That may justify better tools, warnings, validation, > >> documentation, or voluntary hierarchical naming, but it does not > >> automatically justify expanding mandatory registry authority. > >> > >> There is also an important ethical question here. Policy power should > not > >> be enlarged merely because the proposed requirement appears useful, > tidy, > >> or widely adopted elsewhere. The burden lies with those seeking > compulsion > >> to show actual harm, necessity, proportionality, and the failure of less > >> restrictive alternatives. Operators should not be forced to surrender > >> discretion simply because an institution prefers uniformity. > >> > >> The fact that four other RIRs adopted a similar convention is not proof > >> that AFRINIC must do the same. Institutional repetition is not technical > >> necessity, and participation in the PDWG should not become a ritual for > >> ratifying choices already made elsewhere. > >> > >> The registry should preserve number-resource uniqueness, registry > accuracy, > >> and operational continuity. It should not stretch those concepts until > >> every preferred operational convention becomes mandatory policy. > >> > >> For these reasons, I support Asamkele?s objection and remain opposed to > the > >> proposal. > >> > >> Regards, > >> Nonhlanhla > >> On Sat, 18 Jul 2026, 9:08 pm Asamkele Menzeleli < > >> asamkele.menzeleli18 at maharishinstitute.org> wrote: > >> > >>> Dear Hendrik, > >>> > >>> I disagree with your characterization. > >>> > >>> A collision between two AS-SET names is not the same as a failure of > >>> Internet number-resource uniqueness. The uniqueness function of the > >>> registry concerns ASNs, prefixes, proof of control and accurate > >>> registration of those resources. An AS-SET is an operational > >> routing-policy > >>> object. Confusing the naming convention of that object with the > >> uniqueness > >>> of the underlying number resource expands the meaning of ?uniqueness? > far > >>> beyond its proper technical scope. > >>> > >>> The fact that two operators may choose the same flat label may justify > >>> better tooling, clearer warnings, stronger validation or voluntary > >>> hierarchical naming. It does not automatically justify a mandatory > policy > >>> rule. > >>> > >>> That distinction is precisely the concern I raised. Institutional > >>> authority often expands by redefining a useful administrative > preference > >> as > >>> a technical necessity. Once every data-quality issue is described as a > >>> uniqueness failure, there is effectively no limit to what may be > brought > >>> into mandatory registry policy. > >>> > >>> The proposal?s limited scope does not answer that concern. A new > >>> enforcement power does not cease to be enforcement merely because it > >>> applies prospectively or begins with one object type. The correct test > is > >>> whether the rule is indispensable to preserving the operation of > running > >>> networks, and whether a less restrictive mechanism cannot achieve the > >> same > >>> outcome. > >>> > >>> You also repeat that the other four RIRs have implemented hierarchical > >>> naming. That demonstrates institutional adoption elsewhere. It does not > >>> demonstrate that AFRINIC operators have authorized the same rule, that > >>> actual routing failures in this region require it, or that voluntary > and > >>> technical alternatives are inadequate. Four registries making the same > >>> choice is not a substitute for evidence. > >>> > >>> A registry should record operational reality accurately and provide > >>> operators with tools to manage routing information safely. It should > not > >>> turn every preferred convention into mandatory governance merely > because > >>> uniformity looks tidy from the registry side. > >>> > >>> My objection therefore remains. The proposal has not shown that > >> compulsory > >>> hierarchical naming is necessary to protect number-resource uniqueness, > >> nor > >>> that the registry should extend its mandatory policy authority into > this > >>> area. > >>> > >>> Regards, > >>> Asamkele Menzeleli > >>> _______________________________________________ > >>> RPD mailing list > >>> RPD at afrinic.net > >>> https://lists.afrinic.net/mailman/listinfo/rpd > >>> > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: < > >> > https://lists.afrinic.net/pipermail/rpd/attachments/20260718/7d3628bc/attachment.html > >>> > >> > >> ------------------------------ > >> > >> Subject: Digest Footer > >> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> > >> > >> ------------------------------ > >> > >> End of RPD Digest, Vol 222, Issue 45 > >> ************************************ > >> > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 219280444 at mycput.ac.za Sun Jul 19 08:10:14 2026 From: 219280444 at mycput.ac.za (Thulisile Mazomba) Date: Sun, 19 Jul 2026 08:10:14 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear Nishal and Seun, I agree with Asamkele, Gugu, Tshepo, and Nonhlanhla, and I remain opposed to AFPUB-2026-ASN-001-DRAFT02. Nishal describes the proposal as an incremental improvement. But mandatory policy should not be justified merely by the possibility of improvement. It should define what success means, how that success will be measured, and what happens if the promised benefit does not materialise. The proposal appears to contain no meaningful operational baseline. How many harmful collisions currently originate from the AFRINIC database? How many incorrect filters have resulted? What measurable reduction should hierarchical naming produce? How will the community distinguish an actual security improvement from simple compliance with a new naming format? Without those answers, the policy risks creating a false assurance. Operators may see a hierarchical name and assume the object is trustworthy even though the accuracy of its members remains unverified. A rule that improves appearance while leaving substantive data risk intact can make unsafe reliance more likely, not less. There is also no serious treatment of reversibility. Nishal says that if the policy proves mistaken in ten years, no harm will have occurred. That is an assumption, not an analysis. Mandatory formats create implementation dependencies, documentation burdens, tooling expectations, and institutional precedent. Once the registry becomes the enforcement point, reversal is rarely costless. This is why the common coordination layer must remain minimal. A rule should enter that layer only when the protected invariant is clearly identified, the remedy is technically sufficient, and the consequences of centralising enforcement are understood. Policy should not be used as an experiment whose costs are carried by operators while its supporters declare success by adoption alone. Seun?s suggestion that participants with similar objections should write another proposal also misunderstands the role of objection. The absence of a competing policy does not validate the current one. A proposal must stand on its own evidence, scope, and implementation design. Nor does agreement among several participants weaken the objection. A shared concern may indicate that the proposal?s assumptions have not been answered. It should not be treated as a reason to advance the proposal despite those concerns. The policy process should record and test operational reality. It should not manufacture obligation first and wait for running networks to prove the institution wrong later. Until the proposal defines measurable harm, measurable benefit, residual risk, review criteria, and a credible rollback path, it should not proceed beyond last call. I therefore maintain my objection. Regards, Thulisile Mazomba -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at posix.co.za Sun Jul 19 08:49:58 2026 From: mark at posix.co.za (Mark Elkins) Date: Sun, 19 Jul 2026 10:49:58 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: <526b0a0f-ef77-4481-a93f-5cb8653b020a@posix.co.za> Dear RPD, I'm quite confused by some of the conversation. Firstly, I support the policy proposal - Hierarchical Names for New AS-SETs. What I see is that people who have been in the Industry for many years and who's names are well known to me (Hendrik, Noah, Seun, Nishal)? all support the proposal - as have the other four RIR's. They are all in the business of BGP - etc. They approve of the proposal and wouldn't do that if it was going to greatly complicate their lives. I don't recognise (as in seeing them before) the names of the people against the proposal. On 2026/07/19 07:44, Noah wrote: > > > > On Sat, 18 Jul 2026, 10:12?pm Asamkele Menzeleli, > wrote: > > Dear Hendrik, > > > Hi Asamkele, > > > > I disagree with your characterization. > > A collision between two AS-SET names is not the same as a failure > of Internet number-resource uniqueness. > > > So, while you are somewhat correct on that very narrow point, its > still irrelevant imho. The issue is namespace integrity and > authorization for policy objects in a globally mirrored system. RFC > 2622 hierarchical naming was invented exactly to solve this. > Collisions break automated tools that networks rely on for prefix > filtering and I mean really technically breaks ....FYI > > > An AS-SET is an operational routing-policy object. Confusing the > naming convention of that object with the uniqueness of the > underlying number resource expands the meaning of ?uniqueness? far > beyond its proper technical scope. > > The fact that two operators may choose the same flat label may > justify better tooling, clearer warnings, stronger validation or > voluntary hierarchical naming. It does not automatically justify a > mandatory policy rule. > > That distinction is precisely the concern I raised. Institutional > authority often expands by redefining a useful administrative > preference as a technical necessity. Once every data-quality issue > is described as a uniqueness failure, there is effectively no > limit to what may be brought into mandatory registry policy. > > The proposal?s limited scope does not answer that concern. A new > enforcement power does not cease to be enforcement merely because > it applies prospectively or begins with one object type. The > correct test is whether the rule is indispensable to preserving > the operation of running networks, and whether a less restrictive > mechanism cannot achieve the same outcome > > > See my response above .... > > > > You also repeat that the other four RIRs have implemented > hierarchical naming. That demonstrates institutional adoption > elsewhere. It does not demonstrate that AFRINIC operators have > authorized the same rule, that actual routing failures in this > region require it, or that voluntary and technical alternatives > are inadequate. Four registries making the same choice is not a > substitute for evidence. > > > > Firstly, the AFRINIC service region is not an isolated island.?Other > RIRs so the need to implement this after experiencing the same > cross-IRR collision and perhaps incidents of unauthorized creation > problems. > > There was a problem and they so it fit to fix it. Hence APNIC > prop-151, a full PDP process as an example. > > Therefore imho, It is a broader convergence on a technical solution to > a shared defect in the IRR ecosystem, not arbitrary uniformity. > AFRINIC operators already benefit from that very same protection the > other RIR have put in place and we not doing it is accepting an > existing bug is the system to continue existing hence the PDWG support > you are seeing from technical community. > > > A registry should record operational reality accurately and > provide operators with tools to manage routing information safely. > It should not turn every preferred convention into mandatory > governance merely because uniformity looks tidy from the registry > side. > > > Well there is only so much a registry can do. We the community have > been empowered to develop policies that support the operations aspects > of the RIR. > > When voluntary adoption + guidance has continued to demonstrably > failed for years (non-hierarchical sets are still being created), and > when the failure mode enables unauthorized objects that can disrupt > routing, enforcement at creation time becomes the proportionate > response. This is exactly what RIPE, APNIC, and others concluded. > > > > My objection therefore remains. The proposal has not shown that > compulsory hierarchical naming is necessary to protect > number-resource uniqueness, nor that the registry should extend > its mandatory policy authority into this area. > > > Actually the risk here is global and probabilistic. And I say so, > because by not resolving IRRs merge in all five registry databases, a > colliding or squatted AS-SET created in AFRINIC db can affect networks > widely (and vice versa). Waiting for an AFRINIC-specific outage before > acting is reactive rather than responsible stewardship of the registry > and the community is already empowered to always look out for > solutions to better RIR operations some of which are policy driven. > > Cheers, > *.**/noah* > * > * > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -- Mark James ELKINS? -? Posix Systems - (South) Africa mje at posix.co.za?????? Tel: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za Posix SystemsVCARD for MJ Elkins -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: abessive_logo.jpg Type: image/jpeg Size: 6410 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: QR-MJElkins.png Type: image/png Size: 2163 bytes Desc: not available URL: From mselekuthandeka80 at gmail.com Sun Jul 19 08:55:41 2026 From: mselekuthandeka80 at gmail.com (Thandeka Mseleku) Date: Sun, 19 Jul 2026 10:55:41 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear Hendrik, Thank you for your response. While I appreciate your explanation, I remain unconvinced that the proposal establishes a sufficient basis for mandatory hierarchical naming. The discussion continues to distinguish between authenticating who may create an object and validating the correctness, completeness, and operational reliability of the information contained within that object. Hierarchical naming may assist with identifying the maintainer of an AS-SET, but it does not itself ensure that the routing information is accurate, current, or safe for operational use. For that reason, I do not believe the proposal has demonstrated that registry-enforced naming is the least restrictive mechanism available. Improving provenance should not automatically justify expanding registry authority where existing operational practices and voluntary conventions already provide flexibility for network operators. As previously raised by several community members, the registry's role should remain focused on maintaining accurate records and supporting interoperability, rather than extending policy into areas where clear technical necessity has not been demonstrated. For these reasons, I continue to support the concerns raised by Asamkele, Gugu, Tshepo and Nonhlanhla, and I remain opposed to AFPUB-2026-ASN-001-DRAFT02. BR, Thandeka Mseleku -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Sun Jul 19 09:18:44 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Sun, 19 Jul 2026 11:18:44 +0200 Subject: [rpd] My latest blog... In-Reply-To: <56AA1768-E6C1-224D-9633-009718198534@hxcore.ol> References: <56AA1768-E6C1-224D-9633-009718198534@hxcore.ol> Message-ID: <8F545878-130B-455C-90EF-7B9105A8622C@consulintel.es> Very appropriate blog post, I just added a comment. I think some repeated emails, which interestingly are being sent to the wrong email (list owner) and even wrong subjects (mixing proposals), which means don?t even know how to use a mail exploder, and copy even the ?procedure? not just the text, should understand better how the PDP works, and specially, how the chairs evaluate the consensus according to RFC7282. In summary, objections (specially in the last call) are only valid if they can demonstrate that there is something really broken in the policy proposal that was not previously discovered during the discussion phase, not discussing if this proposal is appropriate for a RIR or not. A RIR must do whatever the community decides. There is not a ?global out of scope? definition in the PDP. If the community decides to do something that creates harm for the AFRINIC (as an organization), then it is up to the board to not ratify it. Also, in the last call there is no need to say ?I support the proposal?. No more yes o no voices count for the consensus (neither for maintaining it). The last call is only about valid technical objections that were not raised before on the proposal text and can?t be refuted by the author(s) or community. In the last call is also valid to correct grammar or typos, when it is clear that they don?t change the proposal, as that will invalidate the reached consensus. All this comes from IETF, with many years of experience discussing even more complex proposals that whatever we usually have in any RIR. Regards, Jordi @jordipalet > El 18 jul 2026, a las 22:32, ben.roberts--- via RPD escribi?: > > I felt it important to write this to explain how I learned the word ?Astroturfing? ?. I am all for newcomers into the policy development process, but please lets have real arguments, instead of machine generated co-ordinated "manufactured concencus" > > > https://benrobertskenya.medium.com/the-word-of-the-day-was-astroturfing-3d6e52135665 > > Cheers, > Ben > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at posix.co.za Sun Jul 19 09:26:25 2026 From: mark at posix.co.za (Mark Elkins) Date: Sun, 19 Jul 2026 11:26:25 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 In-Reply-To: <1783459420709.11832@tra.gov.eg> References: <1783459420709.11832@tra.gov.eg> Message-ID: <95592897-0d54-4f5f-b5f8-cd918dd51c24@posix.co.za> Dear PDWG, I have two major concerns regarding the Internet in Africa. 1 - Lack of DNSSEC - for DNS security 2 - Lack of IPv6 - for growth I run something called the Observatory - https://observatory.dnsstudy.africa - which has in the past collected information such as how many domains there are, are they DNSSEC Signed and are they IPv6 accessible. So I want Domain content to be IPv6 Accessible... ISP's need to have IPv6 resources, they need to make sure that all content has IPv6 - so that as end users access that content, they have IPv6 access all the way through. IPv6 doesn't use RFC1918 addresses - all IPv6 addresses are unique. We are running out of IPv4. Yes - some resources will still need IPv4 addresses - so let's stretch what we have out. The IPv4 Soft Landing proposal helps this stretching process - by forcing IPv6 onto LIR's/ ISP's. So I support the Proposal. It may not be perfect but it will help shape the African Internet Industry further into the right direction. -- Mark James ELKINS? -? Posix Systems - (South) Africa mje at posix.co.za?????? Tel: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za -------------- next part -------------- An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Sun Jul 19 09:35:07 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Sun, 19 Jul 2026 09:35:07 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear Mark, I disagree with the basis of your support. The fact that Hendrik, Noah, Seun, and Nishal are familiar names with long experience may make their views worth considering. It does not make those views authoritative, and it does not reduce the validity of objections raised by participants whose names you do not recognise. Participation is not representation. Familiarity is not mandate. Longevity in a policy process is not ownership of that process. A mailing list exists so arguments can be examined on their substance. It should not become a reputational hierarchy in which recognised insiders are presumed technically correct and newer or less visible participants are treated as suspect. That would convert an open process into a closed procedural class while preserving the language of community participation. The same problem appears in the appeal to the other four RIRs. Their adoption is relevant experience, but it does not create authority over AFRINIC. Institutional repetition does not become technical proof merely because the institutions are established and the participants are well known. You also state that experienced operators would not support a proposal if it greatly complicated their lives. That is not the relevant test. A policy may be convenient for established operators while still expanding registry control, imposing costs on others, or turning a preferred operational convention into a mandatory rule. Those who are most familiar with a system are not always those who bear every consequence of its expansion. Community stewardship should not mean that a small group of recognised participants may convert its operational preference into compulsory policy for everyone else. The community may discuss, advise, and contribute expertise. It does not become a legislature merely because familiar people agree with one another. The proper question remains whether the proposal protects a clearly defined technical invariant, whether its benefits are demonstrated, whether its residual risks are understood, and whether mandatory registry enforcement is the minimum proportionate response. Those questions are not answered by asking who has been in the room longest. I therefore remain opposed to AFPUB-2026-ASN-001-DRAFT02. Regards, Tshepo -------------- next part -------------- An HTML attachment was scrubbed... URL: From hytham at tra.gov.eg Sun Jul 19 09:42:40 2026 From: hytham at tra.gov.eg (Hytham El-Nakhal) Date: Sun, 19 Jul 2026 09:42:40 +0000 Subject: [rpd] [External] Re: IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 In-Reply-To: References: <1783459420709.11832@tra.gov.eg> <1784416088278.30395@tra.gov.eg>, Message-ID: <1784454160989.35755@tra.gov.eg> Hello Noah, Well, I asked the Policy Liaison Team (PLT) to prepare a google docs link for the minutes and will share it on the list on a temporarily action till the website issue fixed. Thanks, Haitham el Nakhal PDWG Co-Chair ________________________________ From: Noah Sent: Sunday, July 19, 2026 8:00 AM To: Hytham El-Nakhal Cc: Arnaud AMELINA; rpd List Subject: Re: [rpd] [External] Re: IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 Hello Co-chair Since the website is still broken and the rpd mailing is not broken. The PPM minutes can be published in document format perhaps as a pdf and sent to the broader working group via email to this rpd list. Cheers, ./noah On Sun, 19 Jul 2026, 2:16?am Hytham El-Nakhal, > wrote: Dear Arnaud, The PPM minutes are ready to be published within the normal time frame as per CPM and in same day with the Last Call, but there was a technical problem on the new static website for AFRINIC with the links for the policy proposals' ppt and other hyperlinks. The IT staff and the Policy Liaison Team are doing their best to fix the issue as soon as possible. Meanwhile you can find the discussions happened during the PPM day, authors ppt. and the staff analysis here: https://www.youtube.com/watch?v=uwjG1_XwKV8 Appreciate your patience. Regards, Haitham el Nakhal PDWG Co-Chair ________________________________________ From: Arnaud AMELINA [amelnaud at gmail.com] Sent: Sunday, July 19, 2026 12:39 AM To: Hytham El-Nakhal Cc: rpd at afrinic.net Subject: [External] Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 Dear Co-chairs, Section 3.4 of the CPM sets a three-week deadline for publishing PPM minutes. This deadline has now passed, yet the minutes are still unavailable. It is therefore difficult to understand how Last Call was initiated without these minutes, and without a summary of how the RPD and PPM discussions led to the determination of rough consensus. These elements are essential for the Working Group to participate meaningfully in Last Call. Thank you. Regards -- Arnaud Le mar. 7 juil. 2026 ? 21:25, Hytham El-Nakhal >> a ?crit : Dear PDWG, I have noticed some mails from community members regarding the policy proposal "IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01". The author has updated the proposal (DRAFT02), and it was discussed during the AFRINIC-37 PPM on 24th June 2026. The updated proposal is attached to this email to bring you up to speed with its contents [pending the re-establishment of the AFRINIC website by COB 8th July as communicated by AFRINIC]. The updated proposal did not reach consensus at the AFRINIC-37 PPM and was sent back to the RPD mailing-list for further discussions. Those who missed the discussions still have access the AF-37 PPM proceedings here: https://www.youtube.com/watch?v=uwjG1_XwKV8 . Therefore, it is highly recommended that participants thoroughly review the attached proposal, familiarize themselves with prior discussions on the mailing list and during the Public Policy Meeting, and subsequently focus their valuable contribution by undertaking any of the following actions: * - Seek clarifications regarding the policy text and offer recommendations for its improvement; * - Express formal support for the proposal; or, * - Provide a detailed justification in case of opposition to the policy as drafted. Best Regards, Haitham el Nakhal PDWG Co-Chair _______________________________________________ RPD mailing list RPD at afrinic.net> https://lists.afrinic.net/mailman/listinfo/rpd _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd From hytham at tra.gov.eg Sun Jul 19 10:08:51 2026 From: hytham at tra.gov.eg (Hytham El-Nakhal) Date: Sun, 19 Jul 2026 10:08:51 +0000 Subject: [rpd] [External] Appeal Committee In-Reply-To: References: Message-ID: <1784455732390.26197@tra.gov.eg> Dear Christian, I'm sure that the Board is well aware of the committees necessary for the proper functioning of all aspects of AFRINIC, albeit that, your advice has been forwarded to the Board to convey the community's interest in having a functional Appeal Committee as soon as possible. Regards, Haitham el Nakhal PDWG Co-Chair ________________________________ From: Bope Domilongo Christian Sent: Saturday, July 18, 2026 11:46 PM To: rpd Subject: [External] [rpd] Appeal Committee Dear PDWG, We appear to be operating without an Appeal Committee, which is a key component of the PDP's conflict-resolution mechanism. Section 3.5 of the CPM seems to require a standing Appeal Committee to handle disagreements that cannot be resolved between the Chairs and the participant. Could the co-chairs clarify whether an Appeal Committee is currently constituted, and if not, how conflict resolution is expected to function under Section 3.5? Thank you. @christianbope From hytham at tra.gov.eg Sun Jul 19 10:12:24 2026 From: hytham at tra.gov.eg (Hytham El-Nakhal) Date: Sun, 19 Jul 2026 10:12:24 +0000 Subject: [rpd] Fw: [External] Re: IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 In-Reply-To: <1784454160989.35755@tra.gov.eg> References: <1783459420709.11832@tra.gov.eg> <1784416088278.30395@tra.gov.eg>, , <1784454160989.35755@tra.gov.eg> Message-ID: <1784455945349.43915@tra.gov.eg> Hello Noah, I'm not sure if my following reply is not well received ? Thanks, Haitham ________________________________ From: Hytham El-Nakhal Sent: Sunday, July 19, 2026 12:42 PM To: Noah Cc: rpd List Subject: Re: [rpd] [External] Re: IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 Hello Noah, Well, I asked the Policy Liaison Team (PLT) to prepare a google docs link for the minutes and will share it on the list on a temporarily action till the website issue fixed. Thanks, Haitham el Nakhal PDWG Co-Chair ________________________________ From: Noah Sent: Sunday, July 19, 2026 8:00 AM To: Hytham El-Nakhal Cc: Arnaud AMELINA; rpd List Subject: Re: [rpd] [External] Re: IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 Hello Co-chair Since the website is still broken and the rpd mailing is not broken. The PPM minutes can be published in document format perhaps as a pdf and sent to the broader working group via email to this rpd list. Cheers, ./noah On Sun, 19 Jul 2026, 2:16?am Hytham El-Nakhal, > wrote: Dear Arnaud, The PPM minutes are ready to be published within the normal time frame as per CPM and in same day with the Last Call, but there was a technical problem on the new static website for AFRINIC with the links for the policy proposals' ppt and other hyperlinks. The IT staff and the Policy Liaison Team are doing their best to fix the issue as soon as possible. Meanwhile you can find the discussions happened during the PPM day, authors ppt. and the staff analysis here: https://www.youtube.com/watch?v=uwjG1_XwKV8 Appreciate your patience. Regards, Haitham el Nakhal PDWG Co-Chair ________________________________________ From: Arnaud AMELINA [amelnaud at gmail.com] Sent: Sunday, July 19, 2026 12:39 AM To: Hytham El-Nakhal Cc: rpd at afrinic.net Subject: [External] Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 Dear Co-chairs, Section 3.4 of the CPM sets a three-week deadline for publishing PPM minutes. This deadline has now passed, yet the minutes are still unavailable. It is therefore difficult to understand how Last Call was initiated without these minutes, and without a summary of how the RPD and PPM discussions led to the determination of rough consensus. These elements are essential for the Working Group to participate meaningfully in Last Call. Thank you. Regards -- Arnaud Le mar. 7 juil. 2026 ? 21:25, Hytham El-Nakhal >> a ?crit : Dear PDWG, I have noticed some mails from community members regarding the policy proposal "IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01". The author has updated the proposal (DRAFT02), and it was discussed during the AFRINIC-37 PPM on 24th June 2026. The updated proposal is attached to this email to bring you up to speed with its contents [pending the re-establishment of the AFRINIC website by COB 8th July as communicated by AFRINIC]. The updated proposal did not reach consensus at the AFRINIC-37 PPM and was sent back to the RPD mailing-list for further discussions. Those who missed the discussions still have access the AF-37 PPM proceedings here: https://www.youtube.com/watch?v=uwjG1_XwKV8 . Therefore, it is highly recommended that participants thoroughly review the attached proposal, familiarize themselves with prior discussions on the mailing list and during the Public Policy Meeting, and subsequently focus their valuable contribution by undertaking any of the following actions: * - Seek clarifications regarding the policy text and offer recommendations for its improvement; * - Express formal support for the proposal; or, * - Provide a detailed justification in case of opposition to the policy as drafted. Best Regards, Haitham el Nakhal PDWG Co-Chair _______________________________________________ RPD mailing list RPD at afrinic.net> https://lists.afrinic.net/mailman/listinfo/rpd _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd From hytham at tra.gov.eg Sun Jul 19 10:13:54 2026 From: hytham at tra.gov.eg (Hytham El-Nakhal) Date: Sun, 19 Jul 2026 10:13:54 +0000 Subject: [rpd] [External] Re: IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 In-Reply-To: <1784454160989.35755@tra.gov.eg> References: <1783459420709.11832@tra.gov.eg> <1784416088278.30395@tra.gov.eg>, , <1784454160989.35755@tra.gov.eg> Message-ID: <1784456035559.39573@tra.gov.eg> Hello Noah, I'm not sure if my following reply is not well received ? Thanks, Haitham? ________________________________ From: Hytham El-Nakhal Sent: Sunday, July 19, 2026 12:42 PM To: Noah Cc: rpd List Subject: Re: [rpd] [External] Re: IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 Hello Noah, Well, I asked the Policy Liaison Team (PLT) to prepare a google docs link for the minutes and will share it on the list on a temporarily action till the website issue fixed. Thanks, Haitham el Nakhal PDWG Co-Chair ________________________________ From: Noah Sent: Sunday, July 19, 2026 8:00 AM To: Hytham El-Nakhal Cc: Arnaud AMELINA; rpd List Subject: Re: [rpd] [External] Re: IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 Hello Co-chair Since the website is still broken and the rpd mailing is not broken. The PPM minutes can be published in document format perhaps as a pdf and sent to the broader working group via email to this rpd list. Cheers, ./noah On Sun, 19 Jul 2026, 2:16?am Hytham El-Nakhal, > wrote: Dear Arnaud, The PPM minutes are ready to be published within the normal time frame as per CPM and in same day with the Last Call, but there was a technical problem on the new static website for AFRINIC with the links for the policy proposals' ppt and other hyperlinks. The IT staff and the Policy Liaison Team are doing their best to fix the issue as soon as possible. Meanwhile you can find the discussions happened during the PPM day, authors ppt. and the staff analysis here: https://www.youtube.com/watch?v=uwjG1_XwKV8 Appreciate your patience. Regards, Haitham el Nakhal PDWG Co-Chair ________________________________________ From: Arnaud AMELINA [amelnaud at gmail.com] Sent: Sunday, July 19, 2026 12:39 AM To: Hytham El-Nakhal Cc: rpd at afrinic.net Subject: [External] Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 Dear Co?chairs, Section 3.4 of the CPM sets a three?week deadline for publishing PPM minutes. This deadline has now passed, yet the minutes are still unavailable. It is therefore difficult to understand how Last Call was initiated without these minutes, and without a summary of how the RPD and PPM discussions led to the determination of rough consensus. These elements are essential for the Working Group to participate meaningfully in Last Call. Thank you. Regards -- Arnaud Le mar. 7 juil. 2026 ? 21:25, Hytham El-Nakhal >> a ?crit : Dear PDWG, I have noticed some mails from community members regarding the policy proposal "IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT01". The author has updated the proposal (DRAFT02), and it was discussed during the AFRINIC-37 PPM on 24th June 2026. The updated proposal is attached to this email to bring you up to speed with its contents [pending the re-establishment of the AFRINIC website by COB 8th July as communicated by AFRINIC]. The updated proposal did not reach consensus at the AFRINIC-37 PPM and was sent back to the RPD mailing-list for further discussions. Those who missed the discussions still have access the AF-37 PPM proceedings here: https://www.youtube.com/watch?v=uwjG1_XwKV8 . Therefore, it is highly recommended that participants thoroughly review the attached proposal, familiarize themselves with prior discussions on the mailing list and during the Public Policy Meeting, and subsequently focus their valuable contribution by undertaking any of the following actions: * - Seek clarifications regarding the policy text and offer recommendations for its improvement; * - Express formal support for the proposal; or, * - Provide a detailed justification in case of opposition to the policy as drafted. Best Regards, Haitham el Nakhal PDWG Co-Chair _______________________________________________ RPD mailing list RPD at afrinic.net> https://lists.afrinic.net/mailman/listinfo/rpd _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd From mark at posix.co.za Sun Jul 19 10:15:22 2026 From: mark at posix.co.za (Mark Elkins) Date: Sun, 19 Jul 2026 12:15:22 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: Dear Tshepo, Your intelligence to my email is quite astounding, all be it, clearly artificially answered. I do note that your groups email addresses were all born around the same time as well. I believe that you and your token fed kin have wasted this community enough time. I fully support the Policy Proposal - Hier-arch-ical Names for New AS-SET's - Draft number two. I fully support the removal of Artificial Intelligence agents in the RPD Mailing list - as it's designed for non-artificial but somewhat intelligent or at least experienced (as in the workplace) humans only. Please delete yourself. On 2026/07/19 11:35, Tshepo Masuku wrote: > Dear Mark, > > I disagree with the basis of your support. > > The fact that Hendrik, Noah, Seun, and Nishal are familiar names with > long experience may make their views worth considering. It does not > make those views authoritative, and it does not reduce the validity of > objections raised by participants whose names you do not recognise. > > Participation is not representation. Familiarity is not mandate. > Longevity in a policy process is not ownership of that process. > > A mailing list exists so arguments can be examined on their substance. > It should not become a reputational hierarchy in which recognised > insiders are presumed technically correct and newer or less visible > participants are treated as suspect. That would convert an open > process into a closed procedural class while preserving the language > of community participation. > > The same problem appears in the appeal to the other four RIRs. Their > adoption is relevant experience, but it does not create authority over > AFRINIC. Institutional repetition does not become technical proof > merely because the institutions are established and the participants > are well known. > > You also state that experienced operators would not support a proposal > if it greatly complicated their lives. That is not the relevant test. > A policy may be convenient for established operators while still > expanding registry control, imposing costs on others, or turning a > preferred operational convention into a mandatory rule. Those who are > most familiar with a system are not always those who bear every > consequence of its expansion. > > Community stewardship should not mean that a small group of recognised > participants may convert its operational preference into compulsory > policy for everyone else. The community may discuss, advise, and > contribute expertise. It does not become a legislature merely because > familiar people agree with one another. > > The proper question remains whether the proposal protects a clearly > defined technical invariant, whether its benefits are demonstrated, > whether its residual risks are understood, and whether mandatory > registry enforcement is the minimum proportionate response. > > Those questions are not answered by asking who has been in the room > longest. > > I therefore remain opposed to AFPUB-2026-ASN-001-DRAFT02. > > Regards, > Tshepo -- Mark James ELKINS? -? Posix Systems - (South) Africa mje at posix.co.za?????? Tel: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za -------------- next part -------------- An HTML attachment was scrubbed... URL: From hytham at tra.gov.eg Sun Jul 19 10:16:38 2026 From: hytham at tra.gov.eg (Hytham El-Nakhal) Date: Sun, 19 Jul 2026 10:16:38 +0000 Subject: [rpd] [External] Re: IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 In-Reply-To: References: <1783459420709.11832@tra.gov.eg> <1784416088278.30395@tra.gov.eg>, Message-ID: <1784456199650.84308@tra.gov.eg> Hello Noah, Well, I asked the Policy Liaison Team (PLT) to prepare a google docs link for the minutes and will share it on the list on a temporarily action till the website issue fixed. Thanks, Haitham el Nakhal PDWG Co-Chair ________________________________ From: Noah Sent: Sunday, July 19, 2026 8:00 AM To: Hytham El-Nakhal Cc: Arnaud AMELINA; rpd List Subject: Re: [rpd] [External] Re: IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 Hello Co-chair Since the website is still broken and the rpd mailing is not broken. The PPM minutes can be published in document format perhaps as a pdf and sent to the broader working group via email to this rpd list. Cheers, ./noah ? From paulos at sdnp.org.mw Sun Jul 19 10:36:18 2026 From: paulos at sdnp.org.mw (Dr Paulos Nyirenda) Date: Sun, 19 Jul 2026 12:36:18 +0200 Subject: [rpd] TOR - Re: Appeal Committee In-Reply-To: <1784455732390.26197@tra.gov.eg> References: <1784455732390.26197@tra.gov.eg> Message-ID: <20260719103615.M76126@sdnp.org.mw> An HTML attachment was scrubbed... URL: From noah at neo.co.tz Sun Jul 19 11:31:49 2026 From: noah at neo.co.tz (Noah) Date: Sun, 19 Jul 2026 14:31:49 +0300 Subject: [rpd] AI usage in RPD - Was Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: On Sun, 19 Jul 2026, 1:22?pm Mark Elkins via RPD, wrote: > I fully support the removal of Artificial Intelligence agents in the RPD > Mailing list - as it's designed for non-artificial but somewhat intelligent > or at least experienced (as in the workplace) humans only. Please delete > yourself. > Hi Mark I had not actually paid attention to the responses from opposition side but after your comment above, I have reviewed the repeative long comments and I think you are right.. We could be responding to automated bots and this might really waste lots of PDWG time. To the PDWG Co-chair, It appears we have reached a fundamental disagreement. Supporters of the proposal based on sound reason believe that preventing the creation of unattributable AS-SET names at source is a proportionate and necessary step, based on the experience of other RIRs. The problem statement is clear and backed by a real problem the technical community seeks to address as defined in the relevant RFC. The objectors whose comments appears to be AI generated believe the problem has not been sufficiently justified and risks expanding RIR registry authority while we all know that APNIC and other RIR have addressed the issue. Unless new evidence or arguments emerge, further repetition is unlikely to change positions esp if its AI generated repeation. I suggest that as co-chairs you assess whether there is rough consensus within the PDWG. Cheers, *.**/noah* -------------- next part -------------- An HTML attachment was scrubbed... URL: From Juneparris5 at outlook.com Sun Jul 19 11:49:42 2026 From: Juneparris5 at outlook.com (June Parris) Date: Sun, 19 Jul 2026 11:49:42 +0000 Subject: [rpd] [External] Re: IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 In-Reply-To: <1784456199650.84308@tra.gov.eg> References: <1783459420709.11832@tra.gov.eg> <1784416088278.30395@tra.gov.eg>, <1784456199650.84308@tra.gov.eg> Message-ID: Dear All, Please unsubscribe my email address from this list. The constant bombardment of emails is annoying. I have no interest in these emails I tried unsubscribing, it it did does not work. Regards June Parris June Parris ________________________________ From: Hytham El-Nakhal Sent: Sunday, 19 July 2026 06:16:38 To: Noah Cc: rpd List Subject: Re: [rpd] [External] Re: IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 Hello Noah, Well, I asked the Policy Liaison Team (PLT) to prepare a google docs link for the minutes and will share it on the list on a temporarily action till the website issue fixed. Thanks, Haitham el Nakhal PDWG Co-Chair ________________________________ From: Noah Sent: Sunday, July 19, 2026 8:00 AM To: Hytham El-Nakhal Cc: Arnaud AMELINA; rpd List Subject: Re: [rpd] [External] Re: IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 Hello Co-chair Since the website is still broken and the rpd mailing is not broken. The PPM minutes can be published in document format perhaps as a pdf and sent to the broader working group via email to this rpd list. Cheers, ./noah ? _______________________________________________ RPD mailing list RPD at afrinic.net https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.afrinic.net%2Fmailman%2Flistinfo%2Frpd&data=05%7C02%7C%7C43bbefd4a7124d46901d08dee57edfd3%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C639200530258426407%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=irQXVg6jFE4nIfoJxeW69vr4F5uNQVC3wbEhYVDNcdI%3D&reserved=0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From geier at geier.ne.tz Sun Jul 19 12:22:33 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Sun, 19 Jul 2026 15:22:33 +0300 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) In-Reply-To: References: Message-ID: <6f4ce43f-ffc7-4a04-a7ba-6275f5980318@geier.ne.tz> Hi, inline... On 7/17/2026 6:39 PM, Nia Petronella wrote: > Dear Colleagues, > > I do *not* support adoption of this proposal. > > 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. AfriNIC does (for many years) operate an Internet Routing Registry (IRR). Along the one for IP addresses and aut-num's. RIRs are in a unique position to operate IRRs as they have a direct knowledge of which entities hold IP address resources. And only those holding IP resources can then create associated route[6] objects. This makes the RIR-operated IRRs authoritative, while the others (RADB, Level3, ...) are *not*. I just helped this past week to clean up incorrect information in the "Level3" IRR - my national communications regulator can confirm. You said above "It may protect uniqueness." I agree with you that the Internet Routing *REGISTRY* should protect uniqueness. Globally. It was a mistake to not do this from the beginning, this is now being corrected. We have this way to avoid future creation of these collisions of AS-SET names that we have shown to exist. Anyone opposing this solution can show a better one, as has been mentioned by others. [before last call would also be nice] Otherwise, opposing means effectively that you want me to have the ability to create AS-AKAMAI AS-FACEBOOK AS-SEACOM That would mean you want to enable the IRR system to become more unpredictable. As someone who has created policies/filter rules from IRR data, I would like to say that this is not good. We unfortunately have not seen what the level of experience is that the opponents of this policy have with using Internet Routing Registries. I gave an example on June 1st in https://lists.afrinic.net/pipermail/rpd/2026/014850.html how a collision was avoided. It is in-scope for any operator of an IRR to make the rules for their IRR. It is good for AfriNIC to not allow names like the examples give above. > This proposal also illustrates what Lu Heng describes as the *Policy > Mirror*. The issue is not hierarchical AS-SET names themselves, but the > continuing assumption that every operational practice should be > standardized through registry policy rather than left to voluntary > operator adoption. Running networks?not policy manuals?should determine > what survives. How many networks do the opponents of this policy run? How many networks does Lu Heng run? Do we agree that there are 8533 route objects with maintainer LARUS-SERVICE-MNT in the AfriNIC DB? [1] Referencing 557 origin networks? [2] Are these origin networks listed in AS-SET's in different IRRs? Can I create one with the same name in AfriNIC? Can I omit some members from that AS-SET? Will someone generating filters from that suddenly not allow certain IP resources? > If hierarchical naming provides sufficient operational > value, operators will naturally deploy it without requiring another > layer of institutional governance. I sincerely hope that my above questions pointed (anyone not artificially thinking) to the operational value. If not, I will conclude: It is difficult to get a man to understand something, when his salary depends on his not understanding it. [Upton Sinclair] > Furthermore, AFRINIC should be reducing policy complexity rather than > increasing it. *Running-Code Primacy* requires that policy remain the > minimum necessary to preserve interoperability and operational > continuity. I wonder what's the source for this statement? > Every additional policy object increases long-term > maintenance, interpretation, and enforcement costs while offering > limited benefit to the stability of the Internet itself. The common > layer should remain thin. Many have concluded that in this case the benefit outweighs the cost. Thank you. > Finally, rough consensus should not be mistaken for proof that > additional governance is desirable. I believe this is universally agreed. Nothing new. Otherwise the rough consensus that a certain AfriNIC member in Seychelles doesn't really need 6 million Pv4 addresses would have let to some action already - right? > A mailing list is not a legislature, > and community discussion should not automatically become permanent > policy. Before adopting any proposal, we should first ask whether > failure to adopt would actually threaten uniqueness, interoperability, > or operational continuity. Yes, it would. Hence the proposal exists, has a good problem statement, with actual example cases, and was adopted. > If the answer is no, then the proposal > belongs in operational best practice, not in mandatory registry policy. Answer is not no. Regards, Frank Habicht has created AS-SETs, eBGP policies, prefix filters, advised colleagues against colliding AS-SET names [1] $ whois -h whois.afrinic.net "LARUS-SERVICE-MNT -i mnt-by -T route" | grep -E '^route:' | wc -l 8533 $ [2] $ whois -h whois.afrinic.net "LARUS-SERVICE-MNT -i mnt-by -T route" | grep -E '^origin:' | awk '{print $2}' | sort | uniq | wc -l 557 $ > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From nishal at controlfreak.co.za Sun Jul 19 12:43:32 2026 From: nishal at controlfreak.co.za (Nishal Goburdhan) Date: Sun, 19 Jul 2026 14:43:32 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: <98BF382D-3976-446B-9A72-BA811C6DED99@controlfreak.co.za> On 19 Jul 2026, at 8:39, Tshepo Masuku wrote: [snip] tshepo, i'm not going to work through every point in your mail, because you have not addressed the simple request i made. if you are objecting, then demonstrate: - this complexity (or harm) you keep talking about; and/or - a viable alternative; and my reason is simple - there is a bug that is being exploited. we have real-world evidence of this. we would like to see that patched, asap. what your responses do not reflect, is that operators across the world *want* this patch! we know this to be true, because, there is a policy for this, in every other RIR. and yes, whilst other regions do not force afrinic policy, we are hearing from real network operators in africa, that they want this. i know, i am an operator, and it would make my life better. and there are other, verifiable, operators, in this region, that have said the same, in support of this policy already. i'm going to re-state something i wrote earlier: no single policy instrument, solves every problem simultaneously. the fact that hierarchical naming does not also validate every prefix inside an AS-SET, does not mean it offers no value. attribution alone, is a meaningful improvement, even in the absence of full content verification. by your logic, RPKI should also have been opposed ? because ROAs don't validate BGP path attributes! that argument, if taken seriously, would paralyse every incremental improvement to internet infrastructure. forever! the internet was built, incrementally. it gets better, incrementally. that is not a bug. ?n. ps. as a matter of list etiquette, you should not include rpd-owner@ in your reply; it is sufficient to simply address your mail to the mailing list. From nishal at controlfreak.co.za Sun Jul 19 12:48:51 2026 From: nishal at controlfreak.co.za (Nishal Goburdhan) Date: Sun, 19 Jul 2026 14:48:51 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <1784239787450.20999@tra.gov.eg> References: <1784239787450.20999@tra.gov.eg> Message-ID: <0138A740-92F4-4FE9-AD99-E9AA9ED1CBA2@controlfreak.co.za> On 17 Jul 2026, at 0:09, Hytham El-Nakhal wrote: > Dear PDWG, > The Policy Development Working Group (PDWG) Chairs have initiated a Last Call for this proposal, following rough consensus at the AFRINIC-37 Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. > > * Proposal Name: Hierarchical Names for New AS-SETs > * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > * Proposal URL: https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > Last Call closes on: July 31, 2026, at 23:59 UTC. hi pdwg. i (like other lurkers here) have taught bgp, bgp policy, and interaction with afrinic?s whois database, and the irrdb, to many participants on this list. i think that this policy will add one more security knob for operators (a good thing). i do not see this policy adding any measure of onerous administrative burden, to either operators, or afrinic staff. so, i support the adoption of this policy. ?n. From geier at geier.ne.tz Sun Jul 19 12:58:00 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Sun, 19 Jul 2026 15:58:00 +0300 Subject: [rpd] RPD Digest, Vol 222, Issue 45 In-Reply-To: References: Message-ID: <6487b0cf-568f-44ad-94b0-f3dff9eb21bd@geier.ne.tz> Hi, inline... On 7/18/2026 10:49 PM, Nia Petronella wrote: > Dear PDWG, > > I agree with Asamkele, Gugu, and Tshepo, and I remain opposed to this > proposal. > > Responding to objectors one by one does not resolve the common concern > they have raised. A collision between AS-SET labels is not a failure of > ASN or prefix uniqueness, It is a failure of AS-SET uniqueness. Which are not among the famous 3 INR that AfriNIC primarily deals with. But they are important objects in the IRR. Which AfriNIC operates. And thus AfriNIC should set the policies under which it operates the IRR. > and repeating that characterization does not > make it technically correct. Maybe my above statement is not a repetition, and could be technically correct? > The proposal still has not demonstrated measurable operational harm, Would it be better if someone would have added this to the proposal: "" MANRS documented the incident with AS-AMAZON back in 2022, https://manrs.org/2022/12/why-network-operators-should-use-hierarchical-as-sets/. At the time of writing Google's official source for their AS-SET is RADB as documented in their PeeringDB entry https://www.peeringdb.com/net/433, but AS-GOOGLE currently exists as an empty AS-SET in the RIPE DB https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=AS-GOOGLE&type=as-set. "" Would you then agree that the proposal demonstrated harm? Just because you didn't see it doesn't mean there was no harm. > why > voluntary hierarchical naming is insufficient, the author posted on this mailing list the number of collisions that exist. > or why mandatory registry > intervention is the least restrictive solution. This is where you can propose a less restrictive solution. > Adoption by other RIRs > is relevant, but institutional uniformity is not proof of technical > necessity. Harm that was documented is the proof of technical necessity. > A policy process should examine objections on their merits, not treat > repeated disagreement as something to be individually overcome. Thanks. Was the AI asked to produce a certain quantity of text, so that this blah had to be included? > The > registry should support accurate routing information without converting > every preferred convention into compulsory policy. Now, I have a question. If "the registry" (AfriNIC) gets this information: as-set: AS-GOOGLE tech-c: AS156-AFRINIC admin-c: AS156-AFRINIC mnt-by: google_kenya source: AFRINIC # Filtered descr: AS-GOOGLE and another registry (RADB) has this information: as-set: AS-GOOGLE descr: Google members: AS11344 members: AS13949 members: AS15169 members: AS15276 members: AS19425 members: AS22577 members: AS26910 members: AS36040 members: AS36384 members: AS36492 members: AS36561 members: AS394725 members: AS40873 members: AS41264 members: AS43515 members: AS55023 members: AS6432 members: AS19527 members: AS26684 members: AS395973 members: AS36039 members: AS24424 members: AS396982 members: AS139070 members: AS139190 members: AS394699 members: AS-GOOGLE-IT members: AS-MEEBO members: AS-METAWEB-2 members: AS32381 members: AS36383 members: AS36411 members: AS36520 members: AS394089 mnt-by: MAINT-AS15169 changed: arturolev at google.com 20231030 #16:36:58Z source: RADB last-modified: 2023-11-13T16:19:21Z then what should the person or the software generating a prefix-filter do? Awaiting this answer. It's important. Because this is what this discussion is about. Any indication that the opponents have understood this will be welcome. Frank Habicht From fundiswanadia2 at gmail.com Sun Jul 19 13:12:23 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Sun, 19 Jul 2026 15:12:23 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear Colleagues, I would like to support the concerns raised regarding this proposal. While hierarchical naming may improve attribution by linking an AS-SET to the maintainer of an ASN, I do not believe this alone resolves the broader routing-policy authorisation concerns. Verifying who created an object is different from verifying that the routing policy represented within that object is accurate, current, or authorised by every network it includes. For this reason, I believe the proposal addresses only one aspect of the problem. It improves identification of the publisher but does not necessarily guarantee the correctness or legitimacy of the routing information contained in the object. I also believe that continued use of existing naming conventions should not automatically be viewed as evidence that mandatory policy intervention is required. Before introducing additional policy requirements, the community should be satisfied that there is a clearly demonstrated operational problem which cannot be addressed through improved tooling, validation mechanisms, operational guidance, or voluntary adoption. AFRINIC's Policy Development Process has always sought to balance technical necessity with proportionality. In my view, mandatory policy should remain limited to what is essential for the secure and reliable coordination of Internet number resources. For these reasons, I respectfully maintain my objection to the proposal. Best Regards, Fundiswa Nadia Maseko -------------- next part -------------- An HTML attachment was scrubbed... URL: From geier at geier.ne.tz Sun Jul 19 13:16:10 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Sun, 19 Jul 2026 16:16:10 +0300 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <61376605-1e0a-472e-b5e8-0dad0272b388@geier.ne.tz> <41BA114C-5267-454D-A4E9-7DA43D881E7E@gmail.com> Message-ID: Hi, inline... On 7/17/2026 6:48 PM, Gugu Dhlamini wrote: [snip] > The Internet?s resilience comes from minimizing unnecessary dependencies > and preserving operator autonomy. If hierarchical AS-SET naming is > genuinely required for operational efficiency, it is. > the proposal should > clearly demonstrate that existing mechanisms are insufficient the proposal has done that. And you suggesting that it has not is not accepted. > and that > the benefits outweigh the costs of additional policy complexity. The benefit: the internet continuing to work (mostly) as intended. Any costs...??? > Convenience alone is not a sufficient basis for expanding registry- > managed structures. Since there was a clear problem statement in the proposal, you can not allege "convenience alone". You should retract this statement. Unless you get paid well enough, then you can keep it for the money's sake. > This also relates to the broader ?stability fallacy?: the assumption > that more structure, more policy, or more institutional mechanisms > necessarily create more stability. For those that understand what is proposed, we also understand that this creates more stability and it is not an assumption. Please don't assume that we are assuming. I'm not talking about "more structure, more policy, or more institutional mechanisms". we are discussing a specific proposal here. Dear co-chair, I believe contributions that are alleging an "assumption" when there is none should be disregarded. > In many cases, long-term stability is > better served by simplicity, interoperability, and clear separation > between registry administration and operator decision-making. Yes, "many cases". Not this one. I believe the "many cases" are not including the proposal discussed here. > The burden of proof should therefore rest with proponents to demonstrate > that this proposal addresses a concrete operational problem Oh, the problem statement was included in the proposal. You are almost suggesting that it wasn't there, which is a bit insulting. > that cannot > be solved through existing practices, voluntary coordination, or tooling > improvements outside the policy framework. How do you suggest to solve it? Regards, Frank Habicht From geier at geier.ne.tz Sun Jul 19 13:24:57 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Sun, 19 Jul 2026 16:24:57 +0300 Subject: [rpd] Subject is [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: Hi, inline.... On 7/17/2026 7:27 PM, Nonjabulo Sphilile wrote: [snip] > The burden of proof belongs to those proposing new rules, this sounds like you didn't read the problem statement. > not to > everyone else to justify keeping the Internet simpler. Where is the > demonstrated operational failure that requires this change? In the problem statement. > Where is the > evidence that existing AS-SET naming conventions have become inadequate > at Internet scale? None has been presented. In the problem statement. > Instead, we are asked to accept additional complexity because it appears > administratively tidy. Nope. You missed the other reason. Operational stability. > Administrative tidiness is not the same as > operational necessity. And the latter was addressed int the ...... problem statement. > Internet coordination should remain as thin as possible. Every > additional rule, naming convention, or procedural expectation expands > the policy surface without necessarily improving interoperability or > routing security. Complexity accumulates far more easily than it disappears. Nice text. And true. Assuming you read the problem statement by now, how would you address it? > The policy process should resist the temptation to legislate for > hypothetical problems. What is your justification for "hypothetical" ? Please don't respond without answering this question. > If there is no demonstrated operational > deficiency, ... what if there are ....? > then introducing additional hierarchy is simply governance > expanding into spaces where it has not yet justified its existence. > > For these reasons, I object to the proposal in its current form. Sorry, with myself having seen and understood the problem statement, I couldn't see any of your "reasons"... Frank Habicht From hvisage at hevis.co.za Sun Jul 19 13:34:35 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Sun, 19 Jul 2026 15:34:35 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 45 In-Reply-To: References: Message-ID: <364E8EAC-A7B5-4E86-95A0-FF4585045812@hevis.co.za> Hi Gugu & Nia Just to be clear, I?m the operator of AS329532 & AS213481, Which ASNs are you representing that have issues with this AS-SET proposal? --- 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 On 19 Jul 2026, at 8:54, Gugu Dhlamini wrote: > Dear Hendrik, > > I remain firmly opposed to your viewpoint, and I agree with Nonhlanhla. > > Your argument establishes that a closed hierarchical namespace can prevent > future creation of flat-name collisions. It does not establish that this > proposal solves the broader routing-authorisation problem being used to > justify mandatory policy. > > The distinction remains important. Hierarchical naming can bind the creator > of an AS-SET to the maintainer of an ASN. It does not verify that the > contents of the set are accurate, current, complete, or authorised by every > network represented within it. A hierarchically named object can still > contain stale, excessive, or incorrect members. Tools such as bgpq4 will > still expand those contents. > > The proposal therefore reduces one source of ambiguity. It does not make > generated prefix filters inherently trustworthy. > > That matters because the policy is being defended not merely as a naming > improvement, but as a necessary routing-security protection. The claimed > benefit should be described honestly and proportionately. Attribution is > improved. Semantic correctness is not guaranteed. The remaining failure > modes do not disappear because the namespace has been closed. > > You also describe the proposal as the minimum intervention because it > applies only to new AS-SETs. Narrow scope is relevant, but it does not by > itself prove necessity. A rule may be small and still place an optional > operational convention into the mandatory registry layer without first > demonstrating that other technical controls are inadequate. > > The alternatives are not limited to voluntary good behaviour. They include > explicit IRR source qualification, provenance display, collision detection, > deterministic validation, tooling that refuses ambiguous references, > stronger object-level authorization signals, and local rejection of > untrusted data. The relevant question is whether those mechanisms can > prevent silent ambiguity without making the registry the universal > enforcement point. > > If a tool silently consumes an ambiguous name across multiple IRRs, that is > also a tooling and validation failure. A coordination system should not > answer every unsafe consumer assumption by expanding central compulsion at > the producer layer. > > You further say that the namespace must be universal because IRR data is > consumed globally. Global consumption does not automatically create global > authority for one preferred implementation. It creates a need for clear > source semantics, local validation, and explicit compatibility rules. The > Internet has always depended on operators deciding which data sources they > trust and how they validate them. That responsibility should not be quietly > transferred upward each time a tool can be misconfigured or over-trusting. > > The fact that other RIRs closed their namespaces remains relevant > experience. It is still not proof that AFRINIC must do the same through > mandatory policy, nor that their adoption eliminated the underlying problem > rather than only one visible symptom. > > A registry should maintain a truthful ledger and support safe coordination. > It should not claim more than the proposed mechanism can actually deliver. > > This proposal prevents future flat-name creation. It does not validate > AS-SET membership, guarantee accurate prefix filters, or establish that > registry compulsion is the only technically sound response. > > For those reasons, my objection remains. > > Regards, > Gugu > > On Sun, 19 Jul 2026, 6:17 am Hendrik Visage via RPD wrote: > >> Dear colleagues, >> The point about voluntary naming is where the argument breaks down. >> Hierarchical naming only protects you if the namespace is closed ? if flat >> names remain creatable, any third party can still register a name that >> collides with or shadows yours, and your voluntary good behaviour does >> nothing to stop it. That is why every other RIR made it mandatory rather >> than advisory: the protection is only real when it's universal. On >> measurable harm: tools like bgpq4 expand AS-SET names, not ASNs, so when a >> name is ambiguous the generated prefix-filter can silently include the >> wrong prefixes or drop the right ones. That is a routing outcome, not a >> labelling aesthetic ? and it is precisely the "accurate routing >> information" you say the registry should support. On least-restrictive: >> this proposal already is the minimum ? new objects only, no renaming, no >> other set types, no ongoing registry discretion. It is hard to describe a >> narrower intervention that still closes the namespace. And the point about >> other RIRs isn't an appeal to conformity; IRR data is consumed globally as >> a single namespace by operators who query multiple sources, so AFRINIC >> remaining the one registry that permits flat names doesn't preserve our >> independence ? it just makes our data the weak link in everyone else's >> filters. Finally, responding to objections individually is engaging with >> them on their merits; that is what the process asks for. >> Regards >> >> On 18 Jul 2026, at 21:49, Nia Petronella wrote: >> >>> Dear PDWG, >>> >>> I agree with Asamkele, Gugu, and Tshepo, and I remain opposed to this >>> proposal. >>> >>> Responding to objectors one by one does not resolve the common concern >> they >>> have raised. A collision between AS-SET labels is not a failure of ASN or >>> prefix uniqueness, and repeating that characterization does not make it >>> technically correct. >>> >>> The proposal still has not demonstrated measurable operational harm, why >>> voluntary hierarchical naming is insufficient, or why mandatory registry >>> intervention is the least restrictive solution. Adoption by other RIRs is >>> relevant, but institutional uniformity is not proof of technical >> necessity. >>> >>> A policy process should examine objections on their merits, not treat >>> repeated disagreement as something to be individually overcome. The >>> registry should support accurate routing information without converting >>> every preferred convention into compulsory policy. >>> >>> I therefore support the objections already raised and maintain my >>> opposition. >>> >>> Regards, >>> Nonhlanhla >>> >>> On Sat, 18 Jul 2026, 9:46 pm wrote: >>> >>>> Send RPD mailing list submissions to >>>> rpd at afrinic.net >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> or, via email, send a message with subject or body 'help' to >>>> rpd-request at afrinic.net >>>> >>>> You can reach the person managing the list at >>>> rpd-owner at afrinic.net >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of RPD digest..." >>>> >>>> >>>> Today's Topics: >>>> >>>> 1. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >>>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage) >>>> 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >>>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Asamkele Menzeleli) >>>> 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >>>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Gugu Dhlamini) >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> Message: 1 >>>> Date: Sat, 18 Jul 2026 20:28:16 +0200 >>>> From: Hendrik Visage >>>> To: Asamkele Menzeleli >>>> Cc: rpd-owner at afrinic.net, rpd at afrinic.net >>>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >>>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>>> Message-ID: <6F54C5B9-4C90-42F4-ACFD-6E4C57F5BD66 at hevis.co.za> >>>> Content-Type: text/plain; charset="utf-8"; Format="flowed" >>>> >>>> Hello Asamkele, >>>> Respectfully, this proposal does exactly what you're asking for ? it >>>> maintains uniqueness. Flat AS-SET names can be registered by anyone, so >>>> two operators can create the same name and there is no way to tell >>>> afterwards which ASN it belongs to. That is a uniqueness failure in the >>>> registry's own data, and fixing it is squarely within the mandate you >>>> describe, not an expansion of it. The proposal adds no governance layer: >>>> it applies only to newly created AS-SETs, leaves existing objects >>>> untouched, and doesn't extend to route-sets or anything else. And the >>>> operational necessity is already demonstrated ? APNIC, RIPE, ARIN, and >>>> LACNIC have all implemented hierarchical AS-SET naming, which would >>>> leave AFRINIC as the only registry whose IRR data still permits name >>>> collisions. >>>> Regards >>>> >>>> --- >>>> 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 >>>> >>>> On 17 Jul 2026, at 19:26, Asamkele Menzeleli wrote: >>>> >>>>> Hello everyone, >>>>> >>>>> I object to this proposal. >>>>> >>>>> I also agree with Nonhlanhla's point regarding mandate laundering. We >>>>> should be careful not to confuse policy development with expanding >>>>> institutional authority. >>>>> >>>>> Policies should reflect demonstrated operational realities and >>>>> technical >>>>> necessity. They should not become governance mechanisms that gradually >>>>> enlarge the registry's role beyond maintaining uniqueness, accurate >>>>> records, and operational coordination. >>>>> >>>>> A registry should record reality, not create new layers of governance >>>>> through policy. >>>>> >>>>> Regards, >>>>> Asamkele Menzeleli >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: < >>>> >> https://lists.afrinic.net/pipermail/rpd/attachments/20260718/cd333640/attachment-0001.html >>>>> >>>> >>>> ------------------------------ >>>> >>>> Message: 2 >>>> Date: Sat, 18 Jul 2026 21:05:38 +0200 >>>> From: Asamkele Menzeleli >>>> To: rpd at afrinic.net >>>> Cc: rpd-owner at afrinic.net >>>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >>>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>>> Message-ID: >>>> >>> Yxp+MhGJFpQ at mail.gmail.com> >>>> Content-Type: text/plain; charset="utf-8" >>>> >>>> Dear Hendrik, >>>> >>>> I disagree with your characterization. >>>> >>>> A collision between two AS-SET names is not the same as a failure of >>>> Internet number-resource uniqueness. The uniqueness function of the >>>> registry concerns ASNs, prefixes, proof of control and accurate >>>> registration of those resources. An AS-SET is an operational >> routing-policy >>>> object. Confusing the naming convention of that object with the >> uniqueness >>>> of the underlying number resource expands the meaning of ?uniqueness? >> far >>>> beyond its proper technical scope. >>>> >>>> The fact that two operators may choose the same flat label may justify >>>> better tooling, clearer warnings, stronger validation or voluntary >>>> hierarchical naming. It does not automatically justify a mandatory >> policy >>>> rule. >>>> >>>> That distinction is precisely the concern I raised. Institutional >> authority >>>> often expands by redefining a useful administrative preference as a >>>> technical necessity. Once every data-quality issue is described as a >>>> uniqueness failure, there is effectively no limit to what may be brought >>>> into mandatory registry policy. >>>> >>>> The proposal?s limited scope does not answer that concern. A new >>>> enforcement power does not cease to be enforcement merely because it >>>> applies prospectively or begins with one object type. The correct test >> is >>>> whether the rule is indispensable to preserving the operation of running >>>> networks, and whether a less restrictive mechanism cannot achieve the >> same >>>> outcome. >>>> >>>> You also repeat that the other four RIRs have implemented hierarchical >>>> naming. That demonstrates institutional adoption elsewhere. It does not >>>> demonstrate that AFRINIC operators have authorized the same rule, that >>>> actual routing failures in this region require it, or that voluntary and >>>> technical alternatives are inadequate. Four registries making the same >>>> choice is not a substitute for evidence. >>>> >>>> A registry should record operational reality accurately and provide >>>> operators with tools to manage routing information safely. It should not >>>> turn every preferred convention into mandatory governance merely because >>>> uniformity looks tidy from the registry side. >>>> >>>> My objection therefore remains. The proposal has not shown that >> compulsory >>>> hierarchical naming is necessary to protect number-resource uniqueness, >> nor >>>> that the registry should extend its mandatory policy authority into this >>>> area. >>>> >>>> Regards, >>>> Asamkele Menzeleli >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: < >>>> >> https://lists.afrinic.net/pipermail/rpd/attachments/20260718/e46cf6c9/attachment-0001.html >>>>> >>>> >>>> ------------------------------ >>>> >>>> Message: 3 >>>> Date: Sat, 18 Jul 2026 21:45:03 +0200 >>>> From: Gugu Dhlamini >>>> To: "asamkele.menzeleli18 at maharishinstitute.org" >>>> , " >>>> hvisage at hevis.co.za" >>>> , rpd at afrinic.net, rpd-owner at afrinic.net >>>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >>>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>>> Message-ID: >>>> < >>>> CADMrvbPw1Dyu7JU9unFWz4zTZSd4QGQdMup_ibDd9nKcWwuP-w at mail.gmail.com> >>>> Content-Type: text/plain; charset="utf-8" >>>> >>>> Dear PDWG, >>>> >>>> I agree with Asamkele and disagree with Hendrik?s perspective. >>>> >>>> This is substantially the same argument Hendrik made in response to >> Tshepo: >>>> that because a naming collision can occur, the issue must therefore be >>>> treated as a failure of registry uniqueness and made subject to >> mandatory >>>> policy. That conclusion does not follow. >>>> >>>> A collision between AS-SET labels is not the same as duplicate >> allocation >>>> of an ASN or IP prefix. The underlying number resources remain unique. >> What >>>> is being discussed is the naming and interpretation of an operational >>>> routing object. That may justify better tools, warnings, validation, >>>> documentation, or voluntary hierarchical naming, but it does not >>>> automatically justify expanding mandatory registry authority. >>>> >>>> There is also an important ethical question here. Policy power should >> not >>>> be enlarged merely because the proposed requirement appears useful, >> tidy, >>>> or widely adopted elsewhere. The burden lies with those seeking >> compulsion >>>> to show actual harm, necessity, proportionality, and the failure of less >>>> restrictive alternatives. Operators should not be forced to surrender >>>> discretion simply because an institution prefers uniformity. >>>> >>>> The fact that four other RIRs adopted a similar convention is not proof >>>> that AFRINIC must do the same. Institutional repetition is not technical >>>> necessity, and participation in the PDWG should not become a ritual for >>>> ratifying choices already made elsewhere. >>>> >>>> The registry should preserve number-resource uniqueness, registry >> accuracy, >>>> and operational continuity. It should not stretch those concepts until >>>> every preferred operational convention becomes mandatory policy. >>>> >>>> For these reasons, I support Asamkele?s objection and remain opposed to >> the >>>> proposal. >>>> >>>> Regards, >>>> Nonhlanhla >>>> On Sat, 18 Jul 2026, 9:08 pm Asamkele Menzeleli < >>>> asamkele.menzeleli18 at maharishinstitute.org> wrote: >>>> >>>>> Dear Hendrik, >>>>> >>>>> I disagree with your characterization. >>>>> >>>>> A collision between two AS-SET names is not the same as a failure of >>>>> Internet number-resource uniqueness. The uniqueness function of the >>>>> registry concerns ASNs, prefixes, proof of control and accurate >>>>> registration of those resources. An AS-SET is an operational >>>> routing-policy >>>>> object. Confusing the naming convention of that object with the >>>> uniqueness >>>>> of the underlying number resource expands the meaning of ?uniqueness? >> far >>>>> beyond its proper technical scope. >>>>> >>>>> The fact that two operators may choose the same flat label may justify >>>>> better tooling, clearer warnings, stronger validation or voluntary >>>>> hierarchical naming. It does not automatically justify a mandatory >> policy >>>>> rule. >>>>> >>>>> That distinction is precisely the concern I raised. Institutional >>>>> authority often expands by redefining a useful administrative >> preference >>>> as >>>>> a technical necessity. Once every data-quality issue is described as a >>>>> uniqueness failure, there is effectively no limit to what may be >> brought >>>>> into mandatory registry policy. >>>>> >>>>> The proposal?s limited scope does not answer that concern. A new >>>>> enforcement power does not cease to be enforcement merely because it >>>>> applies prospectively or begins with one object type. The correct test >> is >>>>> whether the rule is indispensable to preserving the operation of >> running >>>>> networks, and whether a less restrictive mechanism cannot achieve the >>>> same >>>>> outcome. >>>>> >>>>> You also repeat that the other four RIRs have implemented hierarchical >>>>> naming. That demonstrates institutional adoption elsewhere. It does not >>>>> demonstrate that AFRINIC operators have authorized the same rule, that >>>>> actual routing failures in this region require it, or that voluntary >> and >>>>> technical alternatives are inadequate. Four registries making the same >>>>> choice is not a substitute for evidence. >>>>> >>>>> A registry should record operational reality accurately and provide >>>>> operators with tools to manage routing information safely. It should >> not >>>>> turn every preferred convention into mandatory governance merely >> because >>>>> uniformity looks tidy from the registry side. >>>>> >>>>> My objection therefore remains. The proposal has not shown that >>>> compulsory >>>>> hierarchical naming is necessary to protect number-resource uniqueness, >>>> nor >>>>> that the registry should extend its mandatory policy authority into >> this >>>>> area. >>>>> >>>>> Regards, >>>>> Asamkele Menzeleli >>>>> _______________________________________________ >>>>> RPD mailing list >>>>> RPD at afrinic.net >>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>> >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: < >>>> >> https://lists.afrinic.net/pipermail/rpd/attachments/20260718/7d3628bc/attachment.html >>>>> >>>> >>>> ------------------------------ >>>> >>>> Subject: Digest Footer >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>>> >>>> ------------------------------ >>>> >>>> End of RPD Digest, Vol 222, Issue 45 >>>> ************************************ >>>> >> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Sun Jul 19 13:44:22 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Sun, 19 Jul 2026 15:44:22 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 45 In-Reply-To: References: Message-ID: Nia, The below is my next marker/reason for calling you out as part of Astroturfing, as after feeding your response to Claude: TL;DR: **Verdict:** `I'd put this at high confidence (roughly 85?95%) that it was generated by an LLM given the thread as context` Claude?s response: This one is a strong candidate for LLM-drafted or heavily LLM-assisted text. Here's the breakdown: Structural markers (strong signals) Parallel negation cascades: "It does not authenticate every member... It does not prove that... It does not prevent..." ? then again later: "It does not demonstrate that... It is not automatically..." This anaphoric triple/quadruple negation pattern is a hallmark of LLM argumentative prose. Humans use it occasionally for rhetorical effect; LLMs produce it in nearly every paragraph. The two-sentence "concede-then-pivot" unit repeated throughout: "Your argument proves X. It does not prove Y." / "The tools you cite expand X. They do not merely validate Y." / "Closing the namespace may improve provenance, but it does not make the expanded data true." Same rhetorical machine, run four or five times. Short punchy sentence as paragraph capstone: "That difference is fundamental." / "That analysis has not been completed." / "It arrives dressed as data hygiene." This dramatic one-liner cadence is very characteristic of Claude/GPT persuasive-essay mode. Lexical markers Abstraction stacking: "explicit source identity, deterministic validation, trustworthy provenance, and local rejection of unsafe data" ? a perfectly balanced four-item noun-phrase list, each item adjective+noun. Classic model output. "least coercive mechanism that protects the actual invariant" ? "invariant" used in a policy-rhetoric sense rather than an engineering sense; models love borrowing formal CS vocabulary into governance arguments. "institutional convergence being used as a substitute for proving necessity" ? dense nominalization strings ("enforcement creep," "registry compulsion," "provenance-aware tooling") throughout. "It arrives dressed as data hygiene" ? the one flourish of metaphor, placed exactly where an LLM asked to "make it forceful" would place it. Rhetorical fingerprints The message argues almost entirely at the meta level (what counts as proof, what the minimum intervention "really" is, patterns of institutional expansion) with very few concrete operational specifics ? no actual example of a collision, an AS-SET, a query workflow, or a tooling name. Human network operators in PDWG threads usually anchor in at least one concrete war story or config detail. Zero grammatical slips, perfectly consistent register, no contractions anywhere ? unusual for mailing-list prose, even formal opposition statements. The "pattern accusation" paragraph ("a technical inconvenience is identified, one centralised remedy is proposed, and then the existence of the inconvenience is treated as authority for compulsion") is a generalized abstraction of the debate itself ? models produce this "zoom out and name the pattern" move very reliably when asked to write rebuttals. Counter-signals (weak) It does engage with your specific arguments (namespace closure, "new objects only," other-RIR precedent), so it's not generic boilerplate ? someone fed it the thread context. British/SA spelling ("authorised," "centralised") is consistent, which a model does when prompted or when the prior thread uses it. Verdict I'd put this at high confidence (roughly 85?95%) that it was generated by an LLM given the thread as context, possibly with light human editing. The tells are the industrialized concede-pivot-negate structure, the capstone one-liners, the balanced abstract noun lists, and the complete absence of concrete operational detail from someone ostensibly arguing about IRR data quality. If the same "Nonhlanhla" has earlier posts in the thread, comparing sentence rhythm and contraction usage would settle it ? LLM-assisted posts in a series tend to converge on this exact register while genuine posts vary. Worth noting: even if machine-drafted, the arguments themselves still need answering on the merits ? the authenticate-creation-vs-validate-content distinction is a real objection regardless of who or what phrased it. But the repetition you're seeing across "different" opposers (if Gugu/Tshepo/Asamkele posts share these markers) would suggest one drafting pipeline behind multiple names, which is itself relevant to how the co-chairs weigh consensus. --- 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 On 19 Jul 2026, at 8:56, Nia Petronella wrote: > Dear Hendrik, > > I agree with Gugu, Tshepo, and Asamkele, and I remain firmly opposed to > this proposal. > > Your argument proves that mandatory hierarchical naming can close one path > to future flat-name collisions. It does not prove that the proposal secures > the routing information consumed by operators. > > That difference is fundamental. > > A hierarchical name authenticates the maintainer permitted to create the > object under an ASN. It does not authenticate every member placed inside > that object. It does not prove that the represented customer cone is > complete, current, or authorised. It does not prevent an authorised > maintainer from publishing stale, excessive, mistaken, or misleading > membership. > > The tools you cite expand the contents of an AS-SET. They do not merely > validate the parent ASN in its name. Closing the namespace may improve > provenance, but it does not make the expanded data true. > > The proposal is therefore being credited with a security outcome it cannot > deliver. It reduces one ambiguity while leaving the central semantic risk > intact. A partial control should be described as a partial control, not > elevated into a universal protection merely because it is easy to enforce > at object creation. > > You also argue that AFRINIC would become the weak link because other RIRs > have adopted the rule. That is still institutional convergence being used > as a substitute for proving necessity. A globally consumed system requires > explicit source identity, deterministic validation, trustworthy provenance, > and local rejection of unsafe data. It does not follow that every source > must impose the same mandatory naming convention through registry policy. > > A consumer that merges multiple IRR sources and silently treats an > ambiguous name as authoritative has made a validation decision. That design > choice cannot simply be transferred upward and converted into a new power > for the registry. Unsafe consumption is not cured only by restricting > production. > > Nor is ?new objects only? proof that this is the least restrictive > solution. It describes the proposal?s temporal scope. It does not > demonstrate that source-qualified queries, collision detection, > provenance-aware tooling, ambiguity rejection, or stronger object-content > validation are technically inadequate. > > The minimum intervention is not automatically the smallest rule the > registry can enforce. It is the least coercive mechanism that protects the > actual invariant. That analysis has not been completed. > > The broader concern is precisely this pattern: a technical inconvenience is > identified, one centralised remedy is proposed, and then the existence of > the inconvenience is treated as authority for compulsion. The registry?s > role expands one apparently narrow rule at a time. No one announces > enforcement creep. It arrives dressed as data hygiene. > > A registry may maintain accurate records, expose provenance, warn about > collisions, and support safer tooling. It should not pretend that > controlling the name of a container guarantees the accuracy of what the > container says. > > Responding to objections individually is not itself the problem. The > problem is that the same institutional answer is being repeated without > resolving the same substantive objection: the proposal authenticates object > creation but does not validate object content, and its supporters have not > shown why registry compulsion is the minimum necessary response. > > The common layer must remain thin. It should protect what running networks > objectively require, not every convention that an institution can enforce. > > For these reasons, I support Gugu, Tshepo, and Asamkele, and I maintain my > strong opposition to AFPUB-2026-ASN-001-DRAFT02. > > Regards, > Nonhlanhla > > On Sun, 19 Jul 2026, 6:14 am Hendrik Visage wrote: > >> Dear colleagues, >> The point about voluntary naming is where the argument breaks down. >> Hierarchical naming only protects you if the namespace is closed ? if flat >> names remain creatable, any third party can still register a name that >> collides with or shadows yours, and your voluntary good behaviour does >> nothing to stop it. That is why every other RIR made it mandatory rather >> than advisory: the protection is only real when it's universal. On >> measurable harm: tools like bgpq4 expand AS-SET names, not ASNs, so when a >> name is ambiguous the generated prefix-filter can silently include the >> wrong prefixes or drop the right ones. That is a routing outcome, not a >> labelling aesthetic ? and it is precisely the "accurate routing >> information" you say the registry should support. On least-restrictive: >> this proposal already is the minimum ? new objects only, no renaming, no >> other set types, no ongoing registry discretion. It is hard to describe a >> narrower intervention that still closes the namespace. And the point about >> other RIRs isn't an appeal to conformity; IRR data is consumed globally as >> a single namespace by operators who query multiple sources, so AFRINIC >> remaining the one registry that permits flat names doesn't preserve our >> independence ? it just makes our data the weak link in everyone else's >> filters. Finally, responding to objections individually is engaging with >> them on their merits; that is what the process asks for. >> Regards >> >> On 18 Jul 2026, at 21:49, Nia Petronella wrote: >> >>> Dear PDWG, >>> >>> I agree with Asamkele, Gugu, and Tshepo, and I remain opposed to this >>> proposal. >>> >>> Responding to objectors one by one does not resolve the common concern >> they >>> have raised. A collision between AS-SET labels is not a failure of ASN or >>> prefix uniqueness, and repeating that characterization does not make it >>> technically correct. >>> >>> The proposal still has not demonstrated measurable operational harm, why >>> voluntary hierarchical naming is insufficient, or why mandatory registry >>> intervention is the least restrictive solution. Adoption by other RIRs is >>> relevant, but institutional uniformity is not proof of technical >> necessity. >>> >>> A policy process should examine objections on their merits, not treat >>> repeated disagreement as something to be individually overcome. The >>> registry should support accurate routing information without converting >>> every preferred convention into compulsory policy. >>> >>> I therefore support the objections already raised and maintain my >>> opposition. >>> >>> Regards, >>> Nonhlanhla >>> >>> On Sat, 18 Jul 2026, 9:46 pm wrote: >>> >>>> Send RPD mailing list submissions to >>>> rpd at afrinic.net >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> or, via email, send a message with subject or body 'help' to >>>> rpd-request at afrinic.net >>>> >>>> You can reach the person managing the list at >>>> rpd-owner at afrinic.net >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of RPD digest..." >>>> >>>> >>>> Today's Topics: >>>> >>>> 1. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >>>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage) >>>> 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >>>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Asamkele Menzeleli) >>>> 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >>>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Gugu Dhlamini) >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> Message: 1 >>>> Date: Sat, 18 Jul 2026 20:28:16 +0200 >>>> From: Hendrik Visage >>>> To: Asamkele Menzeleli >>>> Cc: rpd-owner at afrinic.net, rpd at afrinic.net >>>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >>>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>>> Message-ID: <6F54C5B9-4C90-42F4-ACFD-6E4C57F5BD66 at hevis.co.za> >>>> Content-Type: text/plain; charset="utf-8"; Format="flowed" >>>> >>>> Hello Asamkele, >>>> Respectfully, this proposal does exactly what you're asking for ? it >>>> maintains uniqueness. Flat AS-SET names can be registered by anyone, so >>>> two operators can create the same name and there is no way to tell >>>> afterwards which ASN it belongs to. That is a uniqueness failure in the >>>> registry's own data, and fixing it is squarely within the mandate you >>>> describe, not an expansion of it. The proposal adds no governance layer: >>>> it applies only to newly created AS-SETs, leaves existing objects >>>> untouched, and doesn't extend to route-sets or anything else. And the >>>> operational necessity is already demonstrated ? APNIC, RIPE, ARIN, and >>>> LACNIC have all implemented hierarchical AS-SET naming, which would >>>> leave AFRINIC as the only registry whose IRR data still permits name >>>> collisions. >>>> Regards >>>> >>>> --- >>>> 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 >>>> >>>> On 17 Jul 2026, at 19:26, Asamkele Menzeleli wrote: >>>> >>>>> Hello everyone, >>>>> >>>>> I object to this proposal. >>>>> >>>>> I also agree with Nonhlanhla's point regarding mandate laundering. We >>>>> should be careful not to confuse policy development with expanding >>>>> institutional authority. >>>>> >>>>> Policies should reflect demonstrated operational realities and >>>>> technical >>>>> necessity. They should not become governance mechanisms that gradually >>>>> enlarge the registry's role beyond maintaining uniqueness, accurate >>>>> records, and operational coordination. >>>>> >>>>> A registry should record reality, not create new layers of governance >>>>> through policy. >>>>> >>>>> Regards, >>>>> Asamkele Menzeleli >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: < >>>> >> https://lists.afrinic.net/pipermail/rpd/attachments/20260718/cd333640/attachment-0001.html >>>>> >>>> >>>> ------------------------------ >>>> >>>> Message: 2 >>>> Date: Sat, 18 Jul 2026 21:05:38 +0200 >>>> From: Asamkele Menzeleli >>>> To: rpd at afrinic.net >>>> Cc: rpd-owner at afrinic.net >>>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >>>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>>> Message-ID: >>>> >>> Yxp+MhGJFpQ at mail.gmail.com> >>>> Content-Type: text/plain; charset="utf-8" >>>> >>>> Dear Hendrik, >>>> >>>> I disagree with your characterization. >>>> >>>> A collision between two AS-SET names is not the same as a failure of >>>> Internet number-resource uniqueness. The uniqueness function of the >>>> registry concerns ASNs, prefixes, proof of control and accurate >>>> registration of those resources. An AS-SET is an operational >> routing-policy >>>> object. Confusing the naming convention of that object with the >> uniqueness >>>> of the underlying number resource expands the meaning of ?uniqueness? >> far >>>> beyond its proper technical scope. >>>> >>>> The fact that two operators may choose the same flat label may justify >>>> better tooling, clearer warnings, stronger validation or voluntary >>>> hierarchical naming. It does not automatically justify a mandatory >> policy >>>> rule. >>>> >>>> That distinction is precisely the concern I raised. Institutional >> authority >>>> often expands by redefining a useful administrative preference as a >>>> technical necessity. Once every data-quality issue is described as a >>>> uniqueness failure, there is effectively no limit to what may be brought >>>> into mandatory registry policy. >>>> >>>> The proposal?s limited scope does not answer that concern. A new >>>> enforcement power does not cease to be enforcement merely because it >>>> applies prospectively or begins with one object type. The correct test >> is >>>> whether the rule is indispensable to preserving the operation of running >>>> networks, and whether a less restrictive mechanism cannot achieve the >> same >>>> outcome. >>>> >>>> You also repeat that the other four RIRs have implemented hierarchical >>>> naming. That demonstrates institutional adoption elsewhere. It does not >>>> demonstrate that AFRINIC operators have authorized the same rule, that >>>> actual routing failures in this region require it, or that voluntary and >>>> technical alternatives are inadequate. Four registries making the same >>>> choice is not a substitute for evidence. >>>> >>>> A registry should record operational reality accurately and provide >>>> operators with tools to manage routing information safely. It should not >>>> turn every preferred convention into mandatory governance merely because >>>> uniformity looks tidy from the registry side. >>>> >>>> My objection therefore remains. The proposal has not shown that >> compulsory >>>> hierarchical naming is necessary to protect number-resource uniqueness, >> nor >>>> that the registry should extend its mandatory policy authority into this >>>> area. >>>> >>>> Regards, >>>> Asamkele Menzeleli >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: < >>>> >> https://lists.afrinic.net/pipermail/rpd/attachments/20260718/e46cf6c9/attachment-0001.html >>>>> >>>> >>>> ------------------------------ >>>> >>>> Message: 3 >>>> Date: Sat, 18 Jul 2026 21:45:03 +0200 >>>> From: Gugu Dhlamini >>>> To: "asamkele.menzeleli18 at maharishinstitute.org" >>>> , " >>>> hvisage at hevis.co.za" >>>> , rpd at afrinic.net, rpd-owner at afrinic.net >>>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >>>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>>> Message-ID: >>>> < >>>> CADMrvbPw1Dyu7JU9unFWz4zTZSd4QGQdMup_ibDd9nKcWwuP-w at mail.gmail.com> >>>> Content-Type: text/plain; charset="utf-8" >>>> >>>> Dear PDWG, >>>> >>>> I agree with Asamkele and disagree with Hendrik?s perspective. >>>> >>>> This is substantially the same argument Hendrik made in response to >> Tshepo: >>>> that because a naming collision can occur, the issue must therefore be >>>> treated as a failure of registry uniqueness and made subject to >> mandatory >>>> policy. That conclusion does not follow. >>>> >>>> A collision between AS-SET labels is not the same as duplicate >> allocation >>>> of an ASN or IP prefix. The underlying number resources remain unique. >> What >>>> is being discussed is the naming and interpretation of an operational >>>> routing object. That may justify better tools, warnings, validation, >>>> documentation, or voluntary hierarchical naming, but it does not >>>> automatically justify expanding mandatory registry authority. >>>> >>>> There is also an important ethical question here. Policy power should >> not >>>> be enlarged merely because the proposed requirement appears useful, >> tidy, >>>> or widely adopted elsewhere. The burden lies with those seeking >> compulsion >>>> to show actual harm, necessity, proportionality, and the failure of less >>>> restrictive alternatives. Operators should not be forced to surrender >>>> discretion simply because an institution prefers uniformity. >>>> >>>> The fact that four other RIRs adopted a similar convention is not proof >>>> that AFRINIC must do the same. Institutional repetition is not technical >>>> necessity, and participation in the PDWG should not become a ritual for >>>> ratifying choices already made elsewhere. >>>> >>>> The registry should preserve number-resource uniqueness, registry >> accuracy, >>>> and operational continuity. It should not stretch those concepts until >>>> every preferred operational convention becomes mandatory policy. >>>> >>>> For these reasons, I support Asamkele?s objection and remain opposed to >> the >>>> proposal. >>>> >>>> Regards, >>>> Nonhlanhla >>>> On Sat, 18 Jul 2026, 9:08 pm Asamkele Menzeleli < >>>> asamkele.menzeleli18 at maharishinstitute.org> wrote: >>>> >>>>> Dear Hendrik, >>>>> >>>>> I disagree with your characterization. >>>>> >>>>> A collision between two AS-SET names is not the same as a failure of >>>>> Internet number-resource uniqueness. The uniqueness function of the >>>>> registry concerns ASNs, prefixes, proof of control and accurate >>>>> registration of those resources. An AS-SET is an operational >>>> routing-policy >>>>> object. Confusing the naming convention of that object with the >>>> uniqueness >>>>> of the underlying number resource expands the meaning of ?uniqueness? >> far >>>>> beyond its proper technical scope. >>>>> >>>>> The fact that two operators may choose the same flat label may justify >>>>> better tooling, clearer warnings, stronger validation or voluntary >>>>> hierarchical naming. It does not automatically justify a mandatory >> policy >>>>> rule. >>>>> >>>>> That distinction is precisely the concern I raised. Institutional >>>>> authority often expands by redefining a useful administrative >> preference >>>> as >>>>> a technical necessity. Once every data-quality issue is described as a >>>>> uniqueness failure, there is effectively no limit to what may be >> brought >>>>> into mandatory registry policy. >>>>> >>>>> The proposal?s limited scope does not answer that concern. A new >>>>> enforcement power does not cease to be enforcement merely because it >>>>> applies prospectively or begins with one object type. The correct test >> is >>>>> whether the rule is indispensable to preserving the operation of >> running >>>>> networks, and whether a less restrictive mechanism cannot achieve the >>>> same >>>>> outcome. >>>>> >>>>> You also repeat that the other four RIRs have implemented hierarchical >>>>> naming. That demonstrates institutional adoption elsewhere. It does not >>>>> demonstrate that AFRINIC operators have authorized the same rule, that >>>>> actual routing failures in this region require it, or that voluntary >> and >>>>> technical alternatives are inadequate. Four registries making the same >>>>> choice is not a substitute for evidence. >>>>> >>>>> A registry should record operational reality accurately and provide >>>>> operators with tools to manage routing information safely. It should >> not >>>>> turn every preferred convention into mandatory governance merely >> because >>>>> uniformity looks tidy from the registry side. >>>>> >>>>> My objection therefore remains. The proposal has not shown that >>>> compulsory >>>>> hierarchical naming is necessary to protect number-resource uniqueness, >>>> nor >>>>> that the registry should extend its mandatory policy authority into >> this >>>>> area. >>>>> >>>>> Regards, >>>>> Asamkele Menzeleli >>>>> _______________________________________________ >>>>> RPD mailing list >>>>> RPD at afrinic.net >>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>> >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: < >>>> >> https://lists.afrinic.net/pipermail/rpd/attachments/20260718/7d3628bc/attachment.html >>>>> >>>> >>>> ------------------------------ >>>> >>>> Subject: Digest Footer >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>>> >>>> ------------------------------ >>>> >>>> End of RPD Digest, Vol 222, Issue 45 >>>> ************************************ >>>> >> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Sun Jul 19 14:01:39 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Sun, 19 Jul 2026 16:01:39 +0200 Subject: [rpd] Gugu use of AI Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <1784239787450.20999@tra.gov.eg> Message-ID: Hi Gugu, or should I rather call you ChatGPT? So why I believe you are ALSO PART OF THE ASTROTURFING event, the exec summary: `High confidence again ? I'd say 85?95% LLM-drafted, and moderately high confidence (the "mandate laundering" attribution question is the thing to check) that Nonhlanhla's and Gugu's messages share a drafting pipeline, whether that's one person operating multiple voices or several people using the same tool and prompt style.` PPS: which ASNs are you, Nia and Nonhlanhla operating again where you?ve got the RFC1925 experience? what other real world BGP, ASN operations do you have? so, for those like to see/read the gorifically expanded (non-cave-men-skill) detailed Claudes response: Same pipeline, same fingerprints ? arguably even stronger here. Analysis: **Structural markers** - **The rhetorical-question battery**: "What technical invariant requires this policy? / Does it preserve uniqueness? / Does it improve registry accuracy? / Does it protect interoperability? / Does it strengthen operational continuity?" ? a four-item parallel interrogative list, each item verb+object, perfectly balanced. This is the interrogative version of Nonhlanhla's four-item noun list ("explicit source identity, deterministic validation, trustworthy provenance, and local rejection of unsafe data"). Same machine, different surface form. - **Capstone one-liners again**: "The better question is much simpler." / "That creates a circular process in which policy becomes the justification for more policy." / "The registry should record reality, not increasingly define it." That last one is the exact same antithesis flourish as Nonhlanhla's "It arrives dressed as data hygiene" ? one polished chiasmus-adjacent zinger per message, placed at the emotional peak. - **The "zoom out and name the pattern" move**, again: "this discussion is not really about hierarchical names. It is about a much broader pattern." Nonhlanhla did precisely this ("The broader concern is precisely this pattern..."). Both messages escalate from the object-level dispute to a meta-level institutional critique using nearly identical framing. **Lexical markers** - **"Invariant"** ? there it is again, used in the same non-engineering governance sense. Two different humans on one mailing list independently reaching for "technical invariant" as their load-bearing policy concept is unlikely; one drafting source doing it twice is very likely. - Nominalization strings: "mandate laundering," "institutional discretion," "procedural consensus," "operational continuity," "registry governance." Same register as "enforcement creep" and "registry compulsion" in the previous message. - "Participation becomes confused with authorization, and procedural consensus gradually becomes institutional power" ? the balanced A-becomes-B, C-becomes-D construction, a signature LLM cadence. - Zero contractions, zero grammatical noise, flawless parallelism ? again unusual for mailing-list prose, and the shouty human touch ("my OBJECTION of this POLICY PROPOSAL") sits oddly against the seminar-grade prose below it. That opening line, with its slightly off preposition ("objection *of*" rather than "objection *to*"), reads like the one genuinely human-authored sentence in the message ? likely the sender's own framing stapled onto generated body text. **The cross-message tell** The strongest evidence isn't within this message; it's between the two: - "Mandate laundering" is presented as *Nonhlanhla's* term ("I agree with Nonhlanhla's point regarding mandate laundering") ? but Nonhlanhla's message you showed me never uses that phrase. Either it appeared in a different Nonhlanhla post, or the drafting prompt summarized her argument with that label and the model attributed it back. If the phrase doesn't exist elsewhere in the thread, that's close to a smoking gun for a shared drafting context. - Both messages argue for the identical thesis (thin coordination layer, registry records-not-defines, minimum-necessary compulsion) using the same conceptual vocabulary but non-overlapping surface examples ? exactly what you get from one prompt template run twice with "make it sound like a different person" or two people using the same tool on the same thread. - Neither message contains a single concrete operational detail: no AS-SET name, no IRR source, no filter-generation anecdote, no AFRINIC-specific history. For a debate about IRR data quality among African network operators, two consecutive opposers with zero operational grounding is conspicuous. **Verdict** High confidence again ? I'd say 85?95% LLM-drafted, and moderately high confidence (the "mandate laundering" attribution question is the thing to check) that Nonhlanhla's and Gugu's messages share a drafting pipeline, whether that's one person operating multiple voices or several people using the same tool and prompt style. For the PDWG context: this matters for consensus assessment. AFRINIC's PDP weighs the substance of objections, not headcount, so the co-chairs can legitimately treat five stylistically-identical restatements of one meta-level objection as *one* objection. If you respond on-list, the strongest move is probably not "these are AI-generated" (hard to prove, easy to derail into accusations) but rather: "Objections X, Y, Z restate the same single argument ? that name authentication doesn't validate content ? which has been answered as follows..." That collapses the apparent pile-on into what it substantively is, without needing to litigate authorship. Though if you want, checking whether "mandate laundering" actually appears anywhere earlier in the thread archive would be a quietly decisive data point to have in your back pocket. ====== Oh, then I?ve asked Claude to guess the AI model used: Now we're firmly in speculation territory ? model attribution from style alone is much shakier than human-vs-machine detection, because the frontier models have converged a lot and a strong prompt ("write a forceful formal objection, no contractions, British spelling") can push any of them into this register. But since you asked for a guess, here's my honest stylometric read: **Most likely: the GPT family (GPT-4o / GPT-5 / o-series), fairly recent vintage** - The **staccato capstone sentences** ? "That difference is fundamental." / "The better question is much simpler." / "That analysis has not been completed." ? are the strongest tell. This drum-beat of four-to-six-word declarative paragraph-closers is the signature ChatGPT "forceful essay" cadence, much more than Claude's or Gemini's default. - The **"It is not X. It is Y."** antithesis engine ("This discussion is not really about hierarchical names. It is about a much broader pattern.") is the formal-register cousin of ChatGPT's infamous "It's not just X ? it's Y" tic, with the em-dash stripped out by the formal tone. - "It arrives dressed as data hygiene" ? that single permitted metaphor, deployed as a mic-drop, is very GPT when prompted for "sharp" or "incisive." Claude's flourishes tend to run longer and more hedged; GPT's run short and aphoristic like this. - Interestingly, there are **almost no em-dashes** ? normally the classic GPT tell. But recent GPT versions in formal-letter mode suppress them, and a prompt like "formal mailing list objection" does too, so I don't read much into the absence. **Why probably not Claude (i.e., not me/my siblings)** - Claude's default argumentative prose hedges more ("while it's true that...", "it's worth noting"), qualifies its confidence, and tends toward longer, more subordinate-clause-heavy sentences. These messages are relentlessly assertive with essentially zero hedging ? every sentence is a verdict. That's not impossible to prompt out of Claude, but it's against the grain. - Claude also tends to concede more genuinely before pivoting; the concessions here ("Your argument proves that...") are purely tactical setup for the negation, which is more GPT-rebuttal-mode. **Why probably not Gemini** - Gemini's long-form default leans on structural scaffolding ? headers, bolded topic sentences, bullet lists ? and slightly more effusive transitions. These messages are pure flowing prose with rhetorical-question lists instead, which fits GPT or a heavily prompted model better. **Why probably not an open-weights model (Llama, Qwen, DeepSeek, Mistral)** - Possible, but the prose is *too* clean ? perfectly consistent register over 400+ words, no slightly-off collocations, no repetition slips. DeepSeek in particular has a recognizable fondness for grand historical sweep and occasionally odd idiom; the closest thing here to a slip is the human-typed "OBJECTION of this POLICY PROPOSAL" line, not the body. **One more scenario worth weighting: same model, same operator, one saved prompt** The two messages are so architecturally identical ? one meta-escalation move, one four-item parallel list, one metaphor/chiasmus zinger, one "invariant" ? that I'd guess not just the same model family but literally the same chat template or custom-instruction set, run twice with "respond as a different supporter agreeing with the previous objection." The recycled vocabulary ("invariant," the thin-layer thesis) crossing between "authors" points at a shared conversation or system prompt more than at any particular model's defaults. So, forced to bet: **~55?60% GPT-4o/GPT-5-class, ~15% Claude with an aggressive prompt, ~10% Gemini, ~15% something else or heavily human-edited hybrid** ? and high confidence, whatever the model, that both letters came out of one operator's workflow rather than two independent tool users. Treat all of this as educated guessing, though; unlike the human-vs-AI call, model fingerprinting from a single register-controlled sample is genuinely unreliable, and I'd never state it on-list as anything firmer than an impression. --- 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 On 17 Jul 2026, at 18:58, Gugu Dhlamini wrote: > Hi All, > > Further to my OBJECTION of this POLICY PROPOSAL: > > I agree with Nonhlanhla's point regarding mandate laundering and the > gradual expansion of institutional authority. > > My concern is that this discussion is not really about hierarchical > names. > It is about a much broader pattern. We increasingly justify new policy > by > saying it helps the registry fulfil its role, while the role itself is > continuously expanded through the accumulation of policies. That > creates a > circular process in which policy becomes the justification for more > policy. > > The registry's original technical purpose is relatively narrow: > maintain > uniqueness, preserve accurate records, support interoperability, and > provide a reliable registry service. Those are functions that the > Internet > genuinely requires. > > The difficulty begins when every new proposal is treated as another > legitimate extension of the registry's mandate simply because it has > passed > through the PDP. At that point, the process itself begins > manufacturing > authority. Participation becomes confused with authorization, and > procedural consensus gradually becomes institutional power. > > That is why I believe Nonhlanhla's observation about mandate > laundering is > important. > > A policy process should not become a mechanism through which an > administrative body continually enlarges its own scope. Otherwise > there is > no meaningful limiting principle. Every proposal can simply be > described as > helping the registry perform its role, while the definition of that > role > quietly expands over time. > > The better question is much simpler. > > What technical invariant requires this policy? > > Does it preserve uniqueness? > > Does it improve registry accuracy? > > Does it protect interoperability? > > Does it strengthen operational continuity? > > If the answer is no, then we should be cautious about converting > operational preferences into registry policy. > > This is also why I believe decentralisation is the longer-term > direction we > should be discussing. > > A resilient Internet should minimise dependence on institutional > discretion. Coordination should remain thin, while operational > decisions > remain with operators. The registry should record reality, not > increasingly > define it. The more authority accumulates within a single > administrative > layer, the greater the temptation to use policy as a governance > mechanism > rather than as a narrow technical tool. > > The Internet became successful because it minimised the amount of > central > authority required for independent networks to interoperate. We should > be > careful not to move in the opposite direction by steadily expanding > registry governance into areas where technical necessity has not been > demonstrated. > > Regards, > Gugu -------------- next part -------------- An HTML attachment was scrubbed... URL: From geier at geier.ne.tz Sun Jul 19 14:08:03 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Sun, 19 Jul 2026 17:08:03 +0300 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) In-Reply-To: References: Message-ID: <9ee3de86-a292-4bb4-bf41-aa85d8144b3d@geier.ne.tz> Hi, inline .... On 7/17/2026 7:51 PM, Nia Petronella wrote: > Hello Seun, > > That response illustrates precisely the concern. > > Saying that a proposal ?helps the RIR fulfil its role? does not answer > whether the proposal expands that role. It merely assumes the scope of > the role in advance and then uses policy adoption to validate the > assumption. > > That is circular. > > The registry?s original technical function is narrow: preserve > uniqueness, maintain accurate records, support contactability, record > changes of control, and protect operational continuity. Those functions > justify a registry. They do not create a general mandate to regulate > every practice that can be attached to a registry object. So, until 2013 (Lusaka) there was a discussion and (by 2013) conclusion, that AfriNIC should operate an Internet Routing REGISTRY (IRR). You might have missed this. Since then, AfriNIC is not only dealing out IPv4, IPv6, ASNs, but also allowing members with those resources to create route[6] objects, and also (anyone) to create as-set objects. The rules / policies for the latter is what we're discussing. And unfortunately it took quite a long while till most people understood that just like IPs and ASNs, it would be a good thing if AS-SETs were also unique, assuredly. That's what we're trying to fix. Unfortunately some people haven't understood that yet. But we'll get there. Maybe it's just their incentives that make them not understand. > A policy does not become legitimate merely because the registry can > administer it. Nor does ratification transform an administrative > preference into a technical necessity. Please note: we are having a case where we started with the 'technical necessity'. > That is mandate laundering. As mentioned: 2013 [1] was the mandate to operate an IRR. Now we are trying to improve it from an IRR that allows dangerous garbage [say: toxic waste] to an IRR that doesn't allow dangerous garbage. Hope that explanation helps. > A narrow coordination function is passed through the language of policy, > consensus, and community until it re-emerges as institutional authority. > The process then points to its own output as proof that the authority > existed all along. the authority is and was with this WG. With the above you are trying to make it more complicated, right? [snip] > Rough consensus does not give a registry an unlimited governance surface > over operators, routing practice, commercial arrangements, naming > conventions, or future implementation choices. You know what gives AfriNIC 'an unlimited governance surface over operators, routing practice, commercial arrangements, naming conventions, or future implementation choices' ??? Nothing. We (the humans and AIs) in this WG are talking about what can be in that IRR Database. Maybe the ones using that DB should have a say about what should be in there. Have you ever used it? > The proper question is: what technical invariant requires this rule to > be mandatory? The operational problems in the problem statement. Which were well put. > Does it protect uniqueness? of AS-SETs, for future creations of same. Yes. > Does it prevent duplicate registration? of AS-SETs. Yes. > Does it preserve registry accuracy? Not if the Iv4,IPv6,ASN registry, which i guess you're referring to... > Does it protect security integrity? Indirectly. It improves a tool that network operators can use (if they so wish) to prevent incorrect routing announcements. In the operators responsibility. > Does it preserve operational continuity? Not by itself. But it can support a tool (software) that does this. > If it does not, then it is not a necessary registry function. It is > institutional preference being converted into enforceable policy. You must have noticed the prference of network operators by now. This is not (AfriNIC) 'institutional preference' ! The proposal originated from a network operator. > There is also an important distinction between recording a practice and > governing it. A registry may accurately record AS-SET information. are you aware that AfriNIC members and also everyone else is generating this IRR content? > It > may provide technical formats and interoperable publication mechanisms. > It should not assume that maintaining the database gives it authority to > prescribe every naming structure used by operators. not *every*. But some. As decided by this here WG. > The registry should describe operational reality, not manufacture it > through policy and then enforce obedience through control of the > registry layer. And this WG should mandate the IRR operator (AfriNIC) to restrict naming, since it is of operational benefit. > So yes, this proposal does expand the governance surface. It does so by > converting a naming convention into a policy obligation and then placing > the registry in the position of interpreting, administering, and > enforcing that obligation. so when governments made rulings such as "you should always drive on the left-hand side of the road" or "you should always drive on the right-hand side of the road" that was also "converting a naming convention into a policy obligation" - right? > Calling that ?fulfilling the RIR?s role? does not resolve the objection. Hey, it's improving the IRR's functionality, as per users of the IRR. Are you a user of any IRR? Regards, Frank [1] Madhvi is allowed to correct me. From geier at geier.ne.tz Sun Jul 19 14:46:33 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Sun, 19 Jul 2026 17:46:33 +0300 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <1784239787450.20999@tra.gov.eg> Message-ID: <0640ebec-94a1-44a6-84e3-8b01aa9b475a@geier.ne.tz> Didn't I just respond to the same text from Nia Petronella ????????????????? On 7/17/2026 7:58 PM, Gugu Dhlamini wrote: > Hi All, > > Further to my OBJECTION of this POLICY PROPOSAL: > > I agree with Nonhlanhla's point regarding mandate laundering and the > gradual expansion of institutional authority. > > My concern is that this discussion is not really about hierarchical > names. It is about a much broader pattern. We increasingly justify new > policy by saying it helps the registry fulfil its role, while the role > itself is continuously expanded through the accumulation of policies. > That creates a circular process in which policy becomes the > justification for more policy. > > The registry's original technical purpose is relatively narrow: maintain > uniqueness, preserve accurate records, support interoperability, and > provide a reliable registry service. Those are functions that the > Internet genuinely requires. > > The difficulty begins when every new proposal is treated as another > legitimate extension of the registry's mandate simply because it has > passed through the PDP. At that point, the process itself begins > manufacturing authority. Participation becomes confused with > authorization, and procedural consensus gradually becomes institutional > power. > > That is why I believe Nonhlanhla's observation about mandate laundering > is important. > > A policy process should not become a mechanism through which an > administrative body continually enlarges its own scope. Otherwise there > is no meaningful limiting principle. Every proposal can simply be > described as helping the registry perform its role, while the definition > of that role quietly expands over time. > > The better question is much simpler. > > What technical invariant requires this policy? > > Does it preserve uniqueness? > > Does it improve registry accuracy? > > Does it protect interoperability? > > Does it strengthen operational continuity? > > If the answer is no, then we should be cautious about converting > operational preferences into registry policy. > > This is also why I believe decentralisation is the longer-term direction > we should be discussing. > > A resilient Internet should minimise dependence on institutional > discretion. Coordination should remain thin, while operational decisions > remain with operators. The registry should record reality, not > increasingly define it. The more authority accumulates within a single > administrative layer, the greater the temptation to use policy as a > governance mechanism rather than as a narrow technical tool. > > The Internet became successful because it minimised the amount of > central authority required for independent networks to interoperate. We > should be careful not to move in the opposite direction by steadily > expanding registry governance into areas where technical necessity has > not been demonstrated. > > Regards, > Gugu > > On Fri, 17 Jul 2026, 6:18 pm Seun Ojedeji > wrote: > > I do support this proposal > > Regards > > On Thu, 16 Jul 2026 at 17:10, Hytham El-Nakhal > wrote: > > Dear PDWG, > > > The Policy Development Working Group (PDWG) Chairs have > initiated a Last Call for this proposal, following rough > consensus at the AFRINIC-37 Public Policy Meeting held in hybrid > format in Nairobi, Kenya on 24 June 2026. > > ? *? ?Proposal Name: Hierarchical Names for New AS-SETs > > ? *? ?Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > > ? *? ?Proposal URL: https://www.afrinic.net/afpub-2026-asn-001- > draft02.html draft02.html> > > Last Call closes on: July 31, 2026, at 23:59 UTC. > > > 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. > > > As always, we kindly request that all participants adhere to the > AFRINIC Code of Conduct www.afrinic.net/code>> to maintain a respectful and professional > environment on the mailing list. > > > Kind regards, > > > Haitham el Nakhal > > AFRINIC PDWG Co-Chair > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd lists.afrinic.net/mailman/listinfo/rpd> > > > > -- > ------------------------------------------------------------------------ > > /Seun Ojedeji, > / > > Bringing another down does not take you up - think about > your action! > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd lists.afrinic.net/mailman/listinfo/rpd> > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From geier at geier.ne.tz Sun Jul 19 14:49:24 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Sun, 19 Jul 2026 17:49:24 +0300 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: Hi, inline... On 7/17/2026 8:26 PM, Asamkele Menzeleli wrote: [snip] > A registry should record reality, not create new layers of governance > through policy. How would you describe the reality where the AS-SET "AS-GOOGLE" has two different contents in AfriNIC and in RADB? Desirable? Not desirable? I think this clarification will help us understand whether the problem is worth solving. Thanks, Frank From geier at geier.ne.tz Sun Jul 19 14:52:09 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Sun, 19 Jul 2026 17:52:09 +0300 Subject: [rpd] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: <6b7e583c-6a66-4623-ae8c-4feb57f64568@geier.ne.tz> Hi, inline... On 7/17/2026 8:27 PM, Nyasha Ndemo wrote: > Dear PDWG Chairs, > > I object to AFPUB-2026-ASN-001-DRAFT02. > > This proposal reflects a recurring institutional habit: when no clear > operational failure exists, You didn't read the problem statement. And honestly I wonder whether because of that your whole email should be disregarded. Well, I'll personally do that in order t now allow you to waste my time. Regards, Frank > create additional structure and then > describe that structure as progress. > > The Internet did not become resilient because every identifier was > surrounded by increasingly elaborate policy. It became resilient because > coordination remained narrow, predictable, and justified by operational > necessity. The burden should always rest with those proposing additional > rules to demonstrate why existing practice has become inadequate. > > That burden has not been met. > > I have seen no evidence that current AS-SET naming conventions are > creating a material operational problem that justifies expanding the > policy surface. Administrative preference is not operational necessity. > Consistency is desirable, but consistency alone is not sufficient > justification for imposing additional structure on everyone. > > Every new rule carries a cost. It increases complexity, creates new > expectations, and expands the scope of future interpretation. Those > costs accumulate even when each individual proposal appears modest. Over > time, coordination quietly transforms into governance, and governance > gradually begins solving problems that never required central solutions > in the first place. > > The default principle should be restraint. If the Internet continues to > function without a proposed rule, then the proposal must demonstrate not > merely that it is cleaner or more elegant, but that it solves a concrete > operational deficiency that cannot reasonably be addressed through > existing practice. > > This proposal does not reach that threshold. > > For these reasons, I object to AFPUB-2026-ASN-001-DRAFT02. > > Kind regards, > > Dr. Nyasha Ndemo-Masimbarasi > (DPhil, MSc., BSc. Hon. Development Science and Policy) > Chairperson - Department of Development Programming and Management > Zimbabwe Ezekiel Guti University > 1901 Barrassie Rd, Off Shamva Rd, Bindura > Zimbabwe > Landline: +263867 700 6136 > Cell: +263 773226552 > Email: nyashandemo at gmail.com > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From geier at geier.ne.tz Sun Jul 19 14:58:22 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Sun, 19 Jul 2026 17:58:22 +0300 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: <2a3223b4-7933-4601-bf36-1f46717a8113@geier.ne.tz> Dear whole PDWG, should there be a requirement to have read the problem statement at least? Phrases like "The burden of proof should therefore rest with proponents" seem to suggest there was not problem statement in the proposal, which is not correct. I hope this kind of "contribution" can be disregarded. Regards, Frank Habicht On 7/17/2026 9:03 PM, tshepo mavhungu wrote: > Dear Policy Development Working Group, > > I would like to express my concerns regarding the proposal to introduce > hierarchical naming for new AS-SETs (AFPUB-2026-ASN-001-DRAFT02). > > I agree with the concerns raised by Fundiswa, Thandeka, and Nonhlanhla > during the discussion. > > At first glance, this proposal appears to be a minor technical > enhancement. However, policy changes should be evaluated not only on > their immediate operational benefits, but also on whether they expand > institutional complexity or shift the role of the registry beyond its > core function. > > The primary role of the registry is to maintain an accurate, neutral, > and reliable resource registry and associated data infrastructure. > Policy should focus on preserving the integrity of the ledger and > enabling operational continuity, rather than continuously introducing > new structures that may increase dependence on registry-defined conventions. > > One concern is that proposals of this nature, while well-intentioned, > can contribute to what has been described as ?mandate laundering?: the > gradual expansion of institutional influence through incremental policy > changes that appear administrative or technical in isolation, but > collectively increase the scope of centralized governance over network > operations and coordination practices. > > The Internet?s resilience comes from minimizing unnecessary dependencies > and preserving operator autonomy. If hierarchical AS-SET naming is > genuinely required for operational efficiency, the proposal should > clearly demonstrate that existing mechanisms are insufficient and that > the benefits outweigh the costs of additional policy complexity. > Convenience alone is not a sufficient basis for expanding registry- > managed structures. > > This also relates to the broader ?stability fallacy?: the assumption > that more structure, more policy, or more institutional mechanisms > necessarily create more stability. In many cases, long-term stability is > better served by simplicity, interoperability, and clear separation > between registry administration and operator decision-making. > > The burden of proof should therefore rest with proponents to demonstrate > that this proposal addresses a concrete operational problem that cannot > be solved through existing practices, voluntary coordination, or tooling > improvements outside the policy framework. > > For these reasons, I do not support the proposal in its current form and > encourage the Working Group to prioritise minimalism, operational > continuity, and the protection of the registry?s core mandate. > > Kind regards, > > Tshepo Mavhungu > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From hvisage at hevis.co.za Sun Jul 19 15:07:34 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Sun, 19 Jul 2026 17:07:34 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <0640ebec-94a1-44a6-84e3-8b01aa9b475a@geier.ne.tz> References: <1784239787450.20999@tra.gov.eg> <0640ebec-94a1-44a6-84e3-8b01aa9b475a@geier.ne.tz> Message-ID: <4DEF1ABE-9275-40A9-BA8B-3538FB05B1B8@hevis.co.za> On 19 Jul 2026, at 16:46, Frank Habicht wrote: > Didn't I just respond to the same text from > Nia Petronella > ????????????????? > I?ll quote my friendly LLM: ``` - One more scenario worth weighting: same model, same operator, one saved prompt The two messages are so architecturally identical ? one meta-escalation move, one four-item parallel list, one metaphor/chiasmus zinger, one "invariant" ? that I'd guess not just the same model family but literally the same chat template or custom-instruction set, run twice with "respond as a different supporter agreeing with the previous objection." The recycled vocabulary ("invariant," the thin-layer thesis) crossing between "authors" points at a shared conversation or system prompt more than at any particular model's defaults. ``` > On 7/17/2026 7:58 PM, Gugu Dhlamini wrote: >> Hi All, >> >> Further to my OBJECTION of this POLICY PROPOSAL: >> >> I agree with Nonhlanhla's point regarding mandate laundering and the >> gradual expansion of institutional authority. >> >> My concern is that this discussion is not really about hierarchical >> names. It is about a much broader pattern. We increasingly justify >> new policy by saying it helps the registry fulfil its role, while the >> role itself is continuously expanded through the accumulation of >> policies. That creates a circular process in which policy becomes the >> justification for more policy. >> >> The registry's original technical purpose is relatively narrow: >> maintain uniqueness, preserve accurate records, support >> interoperability, and provide a reliable registry service. Those are >> functions that the Internet genuinely requires. >> >> The difficulty begins when every new proposal is treated as another >> legitimate extension of the registry's mandate simply because it has >> passed through the PDP. At that point, the process itself begins >> manufacturing authority. Participation becomes confused with >> authorization, and procedural consensus gradually becomes >> institutional power. >> >> That is why I believe Nonhlanhla's observation about mandate >> laundering is important. >> >> A policy process should not become a mechanism through which an >> administrative body continually enlarges its own scope. Otherwise >> there is no meaningful limiting principle. Every proposal can simply >> be described as helping the registry perform its role, while the >> definition of that role quietly expands over time. >> >> The better question is much simpler. >> >> What technical invariant requires this policy? >> >> Does it preserve uniqueness? >> >> Does it improve registry accuracy? >> >> Does it protect interoperability? >> >> Does it strengthen operational continuity? >> >> If the answer is no, then we should be cautious about converting >> operational preferences into registry policy. >> >> This is also why I believe decentralisation is the longer-term >> direction we should be discussing. >> >> A resilient Internet should minimise dependence on institutional >> discretion. Coordination should remain thin, while operational >> decisions remain with operators. The registry should record reality, >> not increasingly define it. The more authority accumulates within a >> single administrative layer, the greater the temptation to use policy >> as a governance mechanism rather than as a narrow technical tool. >> >> The Internet became successful because it minimised the amount of >> central authority required for independent networks to interoperate. >> We should be careful not to move in the opposite direction by >> steadily expanding registry governance into areas where technical >> necessity has not been demonstrated. >> >> Regards, >> Gugu >> >> On Fri, 17 Jul 2026, 6:18 pm Seun Ojedeji > > wrote: >> >> I do support this proposal >> >> Regards >> >> On Thu, 16 Jul 2026 at 17:10, Hytham El-Nakhal > > wrote: >> >> Dear PDWG, >> >> >> The Policy Development Working Group (PDWG) Chairs have >> initiated a Last Call for this proposal, following rough >> consensus at the AFRINIC-37 Public Policy Meeting held in >> hybrid >> format in Nairobi, Kenya on 24 June 2026. >> >> ? *? ?Proposal Name: Hierarchical Names for New AS-SETs >> >> ? *? ?Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >> >> ? *? ?Proposal URL: >> https://www.afrinic.net/afpub-2026-asn-001- >> draft02.html > draft02.html> >> >> Last Call closes on: July 31, 2026, at 23:59 UTC. >> >> >> 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. >> >> >> As always, we kindly request that all participants adhere to >> the >> AFRINIC Code of Conduct> > www.afrinic.net/code>> to maintain a respectful and >> professional >> environment on the mailing list. >> >> >> Kind regards, >> >> >> Haitham el Nakhal >> >> AFRINIC PDWG Co-Chair >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > lists.afrinic.net/mailman/listinfo/rpd> >> >> >> >> -- >> ------------------------------------------------------------------------ >> >> /Seun Ojedeji, >> / >> >> Bringing another down does not take you up - think about >> your action! >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > lists.afrinic.net/mailman/listinfo/rpd> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From baya.sylvain at cmnog.cm Sun Jul 19 15:16:43 2026 From: baya.sylvain at cmnog.cm (Sylvain BAYA) Date: Sun, 19 Jul 2026 16:16:43 +0100 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <1784239787450.20999@tra.gov.eg> References: <1784239787450.20999@tra.gov.eg> Message-ID: <2cfcb254-0d85-46bf-8aff-30f830b35a42@cmnog.cm> Le 16/07/2026 ? 23:09, Hytham El-Nakhal a ?crit?: > Dear PDWG, > > > The Policy Development Working Group (PDWG) Chairs have initiated a Last Call for this proposal, following rough consensus at the AFRINIC-37 Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. > > * Proposal Name: Hierarchical Names for New AS-SETs > > * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > > * Proposal URL:https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > Last Call closes on: July 31, 2026, at 23:59 UTC. > Dear PDWG Co-chairs, Many thanks for your much appreciated work! This long email contains four things: ? * the reason why i support this DPP; ? * A presentation from Tashi Phuntsho, during iWeek2026 regarding: Securing Internet Routing - The Puzzle Pieces | iWeek Why Internet Routing Is Broken ? And How We're Fixing It | BGP Security Explained - YouTube ? * Actual AS-SET syntax; ? * Actual AS-SET detailed syntax ? {as that is where the proposed (by this DPP) ??change of behavior would firstly appear...} ...i would like to thanks the author of this DPP; as he wisely ended the References section with the following words: "AFRINIC is the only major RIR which has not currently implemented this feature, or is not currently working towards implementing it. If/when AFRINIC implements it, AS-SET squatting in the 5 major RIRs will no longer be possible and AS-SETs will be have become more secure globally." ...which is the exact reason why i want this DPP to be (i) adopted; (ii) ratified; and (iii) implemented the soonest. > 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. > ...this is ok to me! i have also noted the following from the Staff IAr (Impact Assessment report) of this DPP (AFPUB-2026-ASN-001-DRAFT02): "*6. Staff Observations* We note the exception highlighted in 7.8.6 that could allow restoration of deleted objects. However, we feel that such recalls may introduce operational loopholes, and it may also reduce the effective objective for the policy in general. In the instance that an unintended deletion happens, the affected members may take the opportunity to create aligned AS-SETs." > As always, we kindly request that all participants adhere to the AFRINIC Code of Conduct to maintain a respectful and professional environment on the mailing list. > Thanks for recalling it; as the risk is always there! By the way, having noted that there seems to be some recurring misbeliefs regarding what an AS-SET class of IRR/Whois objects is; please allow me to share three things, which could be helpful to see where the proposed change is intended to start to be seen: (i) A presentation from Tashi Phuntsho, during iWeek2026 regarding: Securing Internet Routing - The Puzzle Pieces | iWeek Why Internet Routing Is Broken ? And How We're Fixing It | BGP Security Explained - YouTube (ii) Actual AS-SET syntax; /cacty at shalom:~$ TZ='UTC' date --rfc-3339='seconds' && whois -h whois.afrinic.net -t AS-SET # from AS15964 at Bhome 2026-07-19 14:43:17+00:00 % This is the AfriNIC Whois server. % The AFRINIC whois database is subject to? the following terms of Use. See https://afrinic.net/whois/terms as-set:? ? ? ? ?[mandatory]? [single]? ? ?[primary/lookup key] descr:? ? ? ? ? [mandatory]? [multiple]? ?[ ] members:? ? ? ? [optional]? ?[multiple]? ?[ ] mbrs-by-ref:? ? [optional]? ?[multiple]? ?[inverse key] remarks:? ? ? ? [optional]? ?[multiple]? ?[ ] org:? ? ? ? ? ? [optional]? ?[multiple]? ?[inverse key] tech-c:? ? ? ? ?[mandatory]? [multiple]? ?[inverse key] admin-c:? ? ? ? [mandatory]? [multiple]? ?[inverse key] notify:? ? ? ? ?[optional]? ?[multiple]? ?[inverse key] mnt-by:? ? ? ? ?[mandatory]? [multiple]? ?[inverse key] mnt-lower:? ? ? [optional]? ?[multiple]? ?[inverse key] changed:? ? ? ? [mandatory]? [multiple]? ?[ ] source:? ? ? ? ?[mandatory]? [single]? ? ?[ ] cacty at shalom:~$ / (iii) Actual AS-SET detailed syntax; /cacty at shalom:~$ TZ='UTC' date --rfc-3339='seconds' && whois -h whois.afrinic.net -v AS-SET # from AS15964 at Bhome 2026-07-19 14:53:36+00:00 % This is the AfriNIC Whois server. % The AFRINIC whois database is subject to? the following terms of Use. See https://afrinic.net/whois/terms The as-set class: ? ? ? An as-set object defines a set of aut-num objects. The ? ? ? attributes of the as-set class are shown in Figure 1.2.2. The ? ? ? "as-set:" attribute defines the name of the set. It is an RPSL ? ? ? name that starts with "as-". The "members:" attribute lists the ? ? ? members of the set.? The "members:" attribute is a list of AS ? ? ? numbers, or other as-set names. as-set:? ? ? ? ?[mandatory]? [single]? ? ?[primary/lookup key] descr:? ? ? ? ? [mandatory]? [multiple]? ?[ ] members:? ? ? ? [optional]? ?[multiple]? ?[ ] mbrs-by-ref:? ? [optional]? ?[multiple]? ?[inverse key] remarks:? ? ? ? [optional]? ?[multiple]? ?[ ] org:? ? ? ? ? ? [optional]? ?[multiple]? ?[inverse key] tech-c:? ? ? ? ?[mandatory]? [multiple]? ?[inverse key] admin-c:? ? ? ? [mandatory]? [multiple]? ?[inverse key] notify:? ? ? ? ?[optional]? ?[multiple]? ?[inverse key] mnt-by:? ? ? ? ?[mandatory]? [multiple]? ?[inverse key] mnt-lower:? ? ? [optional]? ?[multiple]? ?[inverse key] changed:? ? ? ? [mandatory]? [multiple]? ?[ ] source:? ? ? ? ?[mandatory]? [single]? ? ?[ ] The content of the attributes of the as-set class are defined below: as-set ? ?Defines the name of the set. ? ? ?An as-set name is made up of letters, digits, the ? ? ?character underscore "_", and the character hyphen "-"; it ? ? ?must start with "as-", and the last character of a name must ? ? ?be a letter or a digit. ? ? ?An as-set name can also be hierarchical.? A hierarchical set ? ? ?name is a sequence of set names and AS numbers separated by ? ? ?colons ":".? At least one component of such a name must be ? ? ?an actual set name (i.e. start with "as-").? All the set ? ? ?name components of a hierarchical as-name have to be as-set ? ? ?names. descr ? ?A short decription related to the object. ? ? ?A sequence of ASCII characters. members ? ?Lists the members of the set. ? ? ? or ? ? ? mbrs-by-ref ? ?This attribute can be used in all "set" objects; it allows indirect ? ?population of a set. If this attribute is used, the set also includes ? ?objects of the corresponding type (aut-num objects for as-set, for ? ?example) that are protected by one of these maintainers and whose ? ?"member-of:" attributes refer to the name of the set. If the value of ? ?a "mbrs-by-ref:" attribute is ANY, any object of the corresponding ? ?type referring to the set is a member of the set. If the ? ?"mbrs-by-ref:" attribute is missing, the set is defined explicitly by ? ?the "members:" attribute. ? ? ? | ANY remarks ? ?Contains remarks. ? ? ?A sequence of ASCII characters. org ? ?Points to an existing organisation object representing the entity that ? ?holds the resource. ? ? ?The 'ORG-' string followed by 2 to 4 characters, followed by up to 5 digits ? ? ?followed by a source specification.? The first digit must not be "0". ? ? ?Source specification starts with "-" followed by source name up to ? ? ?9-character length. tech-c ? ?References a technical contact. ? ? ?From 2 to 4 characters optionally followed by up to 5 digits ? ? ?optionally followed by a source specification.? The first digit ? ? ?must not be "0".? Source specification starts with "-" followed ? ? ?by source name up to 9-character length. admin-c ? ?References an on-site administrative contact. ? ? ?From 2 to 4 characters optionally followed by up to 5 digits ? ? ?optionally followed by a source specification.? The first digit ? ? ?must not be "0".? Source specification starts with "-" followed ? ? ?by source name up to 9-character length. notify ? ?Specifies the e-mail address to which notifications of changes to an ? ?object should be sent. ? ?This attribute is filtered from the default whois output. ? ? ?An e-mail address as defined in RFC 2822. mnt-by ? ?Specifies the identifier of a registered mntner object used for ? ?authorisation of operations performed with the object that contains ? ?this attribute. ? ? ?Made up of letters, digits, the character underscore "_", ? ? ?and the character hyphen "-"; the first character of a name ? ? ?must be a letter, and the last character of a name must be a ? ? ?letter or a digit.? The following words are reserved by ? ? ?RPSL, and they can not be used as names: ? ? ? any as-any rs-any peeras and or not atomic from to at ? ? ? action accept announce except refine networks into inbound ? ? ? outbound ? ? ?Names starting with certain prefixes are reserved for ? ? ?certain object types.? Names starting with "as-" are ? ? ?reserved for as set names.? Names starting with "rs-" are ? ? ?reserved for route set names.? Names starting with "rtrs-" ? ? ?are reserved for router set names. Names starting with ? ? ?"fltr-" are reserved for filter set names. Names starting ? ? ?with "prng-" are reserved for peering set names. Names ? ? ?starting with "irt-" are reserved for irt names. mnt-lower ? ?Specifies the identifier of a registered mntner object used for ? ?hierarchical authorisation. Protects creation of objects directly (one ? ?level) below in the hierarchy of an object type. The authentication ? ?method of this maintainer object will then be used upon creation of ? ?any object directly below the object that contains the "mnt-lower:" ? ?attribute. ? ? ?Made up of letters, digits, the character underscore "_", ? ? ?and the character hyphen "-"; the first character of a name ? ? ?must be a letter, and the last character of a name must be a ? ? ?letter or a digit.? The following words are reserved by ? ? ?RPSL, and they can not be used as names: ? ? ? any as-any rs-any peeras and or not atomic from to at ? ? ? action accept announce except refine networks into inbound ? ? ? outbound ? ? ?Names starting with certain prefixes are reserved for ? ? ?certain object types.? Names starting with "as-" are ? ? ?reserved for as set names.? Names starting with "rs-" are ? ? ?reserved for route set names.? Names starting with "rtrs-" ? ? ?are reserved for router set names. Names starting with ? ? ?"fltr-" are reserved for filter set names. Names starting ? ? ?with "prng-" are reserved for peering set names. Names ? ? ?starting with "irt-" are reserved for irt names. changed ? ?Specifies who submitted the update, and when the object was updated. ? ?This attribute is filtered from the default whois output. ? ? ?An e-mail address as defined in RFC 2822, followed by a date ? ? ?in the format YYYYMMDD. source ? ?Specifies the registry where the object is registered. Should be ? ?"AFRINIC" for the AFRINIC Database. ? ? ?Made up of letters, digits, the character underscore "_", ? ? ?and the character hyphen "-"; the first character of a ? ? ?registry name must be a letter, and the last character of a ? ? ?registry name must be a letter or a digit. cacty at shalom:~$ / Have a blessed sunday; y'all! Shalom, --sb. > Kind regards, > > > Haitham el Nakhal > > AFRINIC PDWG Co-Chair > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -- Best Regards ! baya.sylvain [AT cmNOG DOT cm] | cmNOG's Structure | CAMIX's Website | Douala-IX's Looking Glass | cmNOG's Surveys | Subscribe to cmNOG's Mailing List | __ #LASAINTEBIBLE|#Eph?siens5:18,15-21?[...] 18 Et *_ne vous enivrez_* pas *_de vin_*, en quoi *_il y a de la dissolution_*; mais *_soyez remplis de l'Esprit_*, [...]? ?#LASAINTEBIBLE|#H?breux13:9,5-15?[...] 9 _*Ne soyez pas seduits par*_ des _*doctrines diverses*_ et _*etrangeres*_, car il est bon _*que le coeur soit affermi par la grace*_, non par les viandes, lesquels n'ont pas profite ? ceux qui y ont marche. [...]? #AMEN,#Maranatha,#MerciJ?SUS! #?MaPri?re? est que tu naisses de nouveau.#Chr?tiennement -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FZqxPTyZXI0rz0ip.png Type: image/png Size: 218713 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x0387408365AC8594.asc Type: application/pgp-keys Size: 19437 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From hvisage at hevis.co.za Sun Jul 19 15:37:24 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Sun, 19 Jul 2026 17:37:24 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <1784239787450.20999@tra.gov.eg> References: <1784239787450.20999@tra.gov.eg> Message-ID: Good day Hytham I hereby also want to thank the PDWG for their work on this proposal, and express my support for it. I might be a ?new? entrant/operator, but very early in the process of setting up my BGP peering sessions, realized the importance of hierarcical AS-SETS. --- 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 On 17 Jul 2026, at 0:09, Hytham El-Nakhal wrote: > Dear PDWG, > > > The Policy Development Working Group (PDWG) Chairs have initiated a > Last Call for this proposal, following rough consensus at the > AFRINIC-37 Public Policy Meeting held in hybrid format in Nairobi, > Kenya on 24 June 2026. > > * Proposal Name: Hierarchical Names for New AS-SETs > > * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > > * Proposal URL: > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > Last Call closes on: July 31, 2026, at 23:59 UTC. > > > 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. > > > As always, we kindly request that all participants adhere to the > AFRINIC Code of Conduct to maintain a > respectful and professional environment on the mailing list. > > > Kind regards, > > > Haitham el Nakhal > > AFRINIC PDWG Co-Chair > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Sun Jul 19 16:02:17 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Sun, 19 Jul 2026 17:02:17 +0100 Subject: [rpd] TOR - Re: Appeal Committee In-Reply-To: <20260719103615.M76126@sdnp.org.mw> References: <20260719103615.M76126@sdnp.org.mw> Message-ID: <494B5C33-3546-4626-AA0C-866691665CC7@afrinic.net> An HTML attachment was scrubbed... URL: From policy-liaison at afrinic.net Sun Jul 19 16:42:47 2026 From: policy-liaison at afrinic.net (Policy Liaison Team) Date: Sun, 19 Jul 2026 20:42:47 +0400 Subject: [rpd] AFRINIC-37 PPM Minutes(draft) Message-ID: <45f082df-a923-44a5-abe9-581078a83bda@afrinic.net> * Dear PDWG, As requested by the PDWG Chair, the PPM minutes are available here -https://docs.google.com/document/d/1RS9bYBb9-8uQxLb4u8LpvEUw1jZSfei5mLj01l2LS1s/edit?usp=sharing . We will share the link once they are published on the website. . You may share your comments and feedback on the RPD mailing list https://lists.afrinic.net/mailman/listinfo/rpd or pdwg at afrinic.net . Deadline :? 23h59 UTC 23rd July? 2026 The final minutes shall thereafter be published. Regards AFRINIC Policy Liaison Team * -- AFRINIC Policy Liaison. t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Sun Jul 19 16:55:44 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Sun, 19 Jul 2026 18:55:44 +0200 Subject: [rpd] =?utf-8?q?=5BLast_Call=5D_Draft_Policy_Proposal_=E2=80=93_H?= =?utf-8?q?ierarchical_Names_for_New_AS-SETs_=28AFPUB-2026-ASN-001-?= =?utf-8?q?DRAFT02=29?= Message-ID: *Dear PDWG,* I have been following this discussion with interest, and I would like to express my concern about the direction it has taken. The Policy Development Process should evaluate technical arguments on their merits. Whether a participant drafted a message unaided, received editorial assistance, or used modern writing tools does not determine whether the reasoning is sound. Speculating about authorship instead of addressing the substance risks distracting the Working Group from the policy questions before it. I am also concerned by suggestions that contributions should be disregarded simply because of assumptions about how they were written. If there are factual or technical errors, they should be identified and discussed. That is how consensus is strengthened. The questions raised by several participants remain legitimate subjects for technical debate: whether the proposal has demonstrated operational necessity, whether the proposed intervention is proportionate, and whether less restrictive alternatives have been adequately considered. I therefore encourage all participants to continue engaging with the substance of the proposal while maintaining the respectful and professional standards expected within the PDWG. Kind regards, Fundiswa Nadia Maseko -------------- next part -------------- An HTML attachment was scrubbed... URL: From Juneparris5 at outlook.com Sun Jul 19 17:12:47 2026 From: Juneparris5 at outlook.com (June Parris) Date: Sun, 19 Jul 2026 17:12:47 +0000 Subject: [rpd] Take me off this list or I will report harassment. Message-ID: June Parris -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Sun Jul 19 17:13:26 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Sun, 19 Jul 2026 18:13:26 +0100 Subject: [rpd] =?utf-8?q?=5BLast_Call=5D_Draft_Policy_Proposal_=E2=80=93_H?= =?utf-8?q?ierarchical_Names_for_New_AS-SETs_=28AFPUB-2026-ASN-001-DRAFT02?= =?utf-8?q?=29?= In-Reply-To: References: Message-ID: Fundiswa, But the AI bots opposing the AS-SET policy aren?t making technical arguments. They are just regurgitating and re-using the same script. None of them seem to know or care what an AS-SET is, or what network owners use them for. Cheers, Ben Sent from my iPhone > On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko wrote: > > ? > Dear PDWG, > > I have been following this discussion with interest, and I would like to express my concern about the direction it has taken. > > The Policy Development Process should evaluate technical arguments on their merits. Whether a participant drafted a message unaided, received editorial assistance, or used modern writing tools does not determine whether the reasoning is sound. Speculating about authorship instead of addressing the substance risks distracting the Working Group from the policy questions before it. > > I am also concerned by suggestions that contributions should be disregarded simply because of assumptions about how they were written. If there are factual or technical errors, they should be identified and discussed. That is how consensus is strengthened. > > The questions raised by several participants remain legitimate subjects for technical debate: whether the proposal has demonstrated operational necessity, whether the proposed intervention is proportionate, and whether less restrictive alternatives have been adequately considered. > > I therefore encourage all participants to continue engaging with the substance of the proposal while maintaining the respectful and professional standards expected within the PDWG. > > Kind regards, > > Fundiswa Nadia Maseko > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From dc at darwincosta.com Sun Jul 19 17:20:05 2026 From: dc at darwincosta.com (dc at darwincosta.com) Date: Sun, 19 Jul 2026 14:20:05 -0300 Subject: [rpd] Take me off this list or I will report harassment. In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From asamkele.menzeleli18 at maharishinstitute.org Sun Jul 19 17:25:17 2026 From: asamkele.menzeleli18 at maharishinstitute.org (Asamkele Menzeleli) Date: Sun, 19 Jul 2026 19:25:17 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear Hendrik, I remain opposed. Your argument proves less than you suggest. Hierarchical naming may identify which ASN maintainer created an AS-SET, but it does not prove that every member placed inside that set was authorised by the affected networks. It establishes attribution of the object. It does not establish the correctness of its contents. That distinction matters because the routing harm you describe arises when operators rely on inaccurate or misleading AS-SET expansion. Prefix-list tools consume the membership data, not merely the name. Binding a name to an ASN therefore does not, by itself, prevent an authorised maintainer from publishing an incorrect customer cone, omitting legitimate members, or including routes it should not include. The proposal is consequently being presented as though it closes an authorisation problem that it only partly addresses. It authenticates who created the container. It does not authenticate every relationship represented inside the container. Nor does the existence of a flat namespace automatically require AFRINIC to prohibit it. Source-qualified lookups, explicit object references, collision warnings, validation rules, local rejection, and voluntary hierarchical objects are all less coercive mechanisms that should be evaluated first. The fact that tooling consumes ambiguous data is an argument for deterministic validation and safer tooling, not automatically for expanding the registry?s permission layer. This is the precise point of running-code discipline: identify the invariant, define the failure, and use the minimum rule necessary to protect it. Do not take one operational risk, rename it ?proof of control,? and then treat that vocabulary as sufficient authority for compulsory policy. A registry may record who maintains an object. It may expose conflicts and provide stronger validation. It should not confuse control of an ASN with ownership of every routing relationship that someone chooses to place beneath that ASN?s name. The proposal therefore still fails the proportionality test. It has not shown that mandatory hierarchical naming eliminates the claimed routing harm, only that it makes the creator of a new object easier to identify. Administrative attribution is useful. It is not the same thing as routing authorisation. My objection remains. Regards, Asamkele Menzeleli -------------- next part -------------- An HTML attachment was scrubbed... URL: From 219280444 at mycput.ac.za Sun Jul 19 17:39:35 2026 From: 219280444 at mycput.ac.za (Thulisile Mazomba) Date: Sun, 19 Jul 2026 17:39:35 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) In-Reply-To: References: Message-ID: Dear colleagues, This discussion has moved away from the proposal and toward questioning who is allowed to object. Whether someone operates an ASN, uses drafting assistance, is new to the list, or is unfamiliar to long-standing participants does not determine whether their argument is valid. The PDP should examine the substance of an objection, not attempt to infer authorship from writing style or rank participants according to reputation. Submitting text to another language model does not establish who wrote it, who contributed to it, or whether the person posting it agrees with it. A probability produced by Claude is not evidence of astroturfing. It is an automated opinion about prose. Hendrik?s own quoted analysis concedes the important point: the distinction between authenticating the creator of an AS-SET and validating its contents is a real objection that still requires an answer. That issue does not disappear because the wording appears polished. The request to identify which ASNs objectors ?represent? also misunderstands participation. I am not claiming to represent every African operator, nor should any individual participant make that claim without authority. I am participating in my own capacity. An ASN is not a voting credential, and operating one does not give its holder a larger mandate over the policy process. Frank?s road-rule analogy is also misplaced. Governments impose traffic laws through public authority and accept legal accountability for doing so. AFRINIC is a private registry operating a technical database. The existence of a working group does not turn that registry into a legislature or every preferred operational practice into the equivalent of public law. The question before us remains simple: does this proposal solve the specific harm claimed, and is mandatory registry enforcement the minimum necessary mechanism? Hierarchical naming may reduce future name collisions. That is a useful property. It does not validate the accuracy of AS-SET membership, prevent incorrect customer-cone data, or make generated filters trustworthy by itself. Those limitations should be assessed honestly rather than buried beneath accusations about who wrote which paragraph. If the co-chairs believe several objections raise the same substantive issue, they may group them as one issue. That is reasonable. But they should then determine whether the issue has been answered on its merits. They should not discount it because the participants are unfamiliar, share a view, use similar language, or may have used writing tools. Participation provides evidence, criticism, and warning. Familiarity does not create mandate. Reputation does not replace proof. A mailing list should not become a private club in which established names decide which speakers count. I remain opposed to the proposal and ask that the discussion return to the proposal?s technical scope, demonstrated benefit, limitations, and proportionality. Regards, Thulisile ________________________________ From: rpd-request at afrinic.net Sent: Sunday, July 19, 2026 18:56 To: rpd at afrinic.net Subject: RPD Digest, Vol 222, Issue 65 Send RPD mailing list submissions to rpd at afrinic.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.afrinic.net/mailman/listinfo/rpd or, via email, send a message with subject or body 'help' to rpd-request at afrinic.net You can reach the person managing the list at rpd-owner at afrinic.net When replying, please edit your Subject line so it is more specific than "Re: Contents of RPD digest..." Today's Topics: 1. Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage) 2. Re: TOR - Re: Appeal Committee (Ben Roberts - AfriNIC) 3. AFRINIC-37 PPM Minutes(draft) (Policy Liaison Team) 4. [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Fundiswa Nadia Maseko) ---------------------------------------------------------------------- Message: 1 Date: Sun, 19 Jul 2026 17:37:24 +0200 From: Hendrik Visage To: Hytham El-Nakhal Cc: rpd at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Content-Type: text/plain; charset="utf-8"; Format="flowed" Good day Hytham I hereby also want to thank the PDWG for their work on this proposal, and express my support for it. I might be a ?new? entrant/operator, but very early in the process of setting up my BGP peering sessions, realized the importance of hierarcical AS-SETS. --- 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 On 17 Jul 2026, at 0:09, Hytham El-Nakhal wrote: > Dear PDWG, > > > The Policy Development Working Group (PDWG) Chairs have initiated a > Last Call for this proposal, following rough consensus at the > AFRINIC-37 Public Policy Meeting held in hybrid format in Nairobi, > Kenya on 24 June 2026. > > * Proposal Name: Hierarchical Names for New AS-SETs > > * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > > * Proposal URL: > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > Last Call closes on: July 31, 2026, at 23:59 UTC. > > > 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. > > > As always, we kindly request that all participants adhere to the > AFRINIC Code of Conduct to maintain a > respectful and professional environment on the mailing list. > > > Kind regards, > > > Haitham el Nakhal > > AFRINIC PDWG Co-Chair > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Sun, 19 Jul 2026 17:02:17 +0100 From: Ben Roberts - AfriNIC To: Dr Nyirenda Paulos Cc: rpd Subject: Re: [rpd] TOR - Re: Appeal Committee Message-ID: <494B5C33-3546-4626-AA0C-866691665CC7 at afrinic.net> Content-Type: text/plain; charset="us-ascii" An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Sun, 19 Jul 2026 20:42:47 +0400 From: Policy Liaison Team To: "rpd at afrinic.net" Subject: [rpd] AFRINIC-37 PPM Minutes(draft) Message-ID: <45f082df-a923-44a5-abe9-581078a83bda at afrinic.net> Content-Type: text/plain; charset="utf-8"; Format="flowed" * Dear PDWG, As requested by the PDWG Chair, the PPM minutes are available here -https://docs.google.com/document/d/1RS9bYBb9-8uQxLb4u8LpvEUw1jZSfei5mLj01l2LS1s/edit?usp=sharing . We will share the link once they are published on the website. . You may share your comments and feedback on the RPD mailing list https://lists.afrinic.net/mailman/listinfo/rpd or pdwg at afrinic.net . Deadline :? 23h59 UTC 23rd July? 2026 The final minutes shall thereafter be published. Regards AFRINIC Policy Liaison Team * -- AFRINIC Policy Liaison. t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Sun, 19 Jul 2026 18:55:44 +0200 From: Fundiswa Nadia Maseko To: rpd at afrinic.net Cc: rpd-owner at afrinic.net Subject: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Content-Type: text/plain; charset="utf-8" *Dear PDWG,* I have been following this discussion with interest, and I would like to express my concern about the direction it has taken. The Policy Development Process should evaluate technical arguments on their merits. Whether a participant drafted a message unaided, received editorial assistance, or used modern writing tools does not determine whether the reasoning is sound. Speculating about authorship instead of addressing the substance risks distracting the Working Group from the policy questions before it. I am also concerned by suggestions that contributions should be disregarded simply because of assumptions about how they were written. If there are factual or technical errors, they should be identified and discussed. That is how consensus is strengthened. The questions raised by several participants remain legitimate subjects for technical debate: whether the proposal has demonstrated operational necessity, whether the proposed intervention is proportionate, and whether less restrictive alternatives have been adequately considered. I therefore encourage all participants to continue engaging with the substance of the proposal while maintaining the respectful and professional standards expected within the PDWG. Kind regards, Fundiswa Nadia Maseko -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ End of RPD Digest, Vol 222, Issue 65 ************************************ -------------- next part -------------- An HTML attachment was scrubbed... URL: From 4141105 at myuwc.ac.za Sun Jul 19 17:35:19 2026 From: 4141105 at myuwc.ac.za (PAULO MSABA) Date: Sun, 19 Jul 2026 19:35:19 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear Frank and Hendrik, I think the discussion is becoming unnecessarily personal. Frank, nobody has denied that the proposal contains a problem statement. The issue is whether the proposed restriction is the right response to that problem. A problem statement explains why a proposal exists. It does not make every conclusion that follows from it correct. Hendrik, saying that some operators prefer the proposal is also not enough. Operators are entitled to support it, but their support does not settle the question for everyone else. The working group exists to examine the rule, including its limits and consequences, not simply to ratify the preference of the most established participants. The traffic-law comparison is particularly unhelpful. AFRINIC is not a government, and this working group is not a parliament. Public law and technical coordination are not interchangeable simply because both can produce rules. What concerns me most is the suggestion that contributions should be disregarded because the wording is familiar, polished, or similar to another objection. That is not how an open process should work. The chairs can group repeated points, but the underlying concern still has to be answered. The point remains that closing flat-name creation may reduce collisions, but it does not make AS-SET data accurate, complete, or safe to trust automatically. The proposal addresses one part of the problem. It should not be treated as though it settles the whole problem. Please deal with the argument rather than the identity, reputation, writing style, or tooling of the person raising it. I remain opposed to the proposal. Regards, [PAULO MSABA] -- Disclaimer - This e-mail is subject to UWC policies and e-mail disclaimer published on our website at:?https://www.uwc.ac.za/disclaimer -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Sun Jul 19 17:54:42 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Sun, 19 Jul 2026 19:54:42 +0200 Subject: [rpd] =?utf-8?q?=5BLast_Call=5D_Draft_Policy_Proposal_=E2=80=93_H?= =?utf-8?q?ierarchical_Names_for_New_AS-SETs_=28AFPUB-2026-ASN-001-?= =?utf-8?q?DRAFT02=29?= In-Reply-To: References: Message-ID: Dear Ben, Thank you for your response. Respectfully, I believe it is more productive to address the arguments themselves than to make assumptions about the people presenting them or the tools they may have used. If you believe the objections are technically incorrect, I would appreciate it if you could identify which specific points you disagree with. For example, do you disagree that hierarchical naming authenticates object creation rather than the accuracy of object membership? Or do you believe the proposal has demonstrated that mandatory naming is the least restrictive solution available? Those are technical questions that can be examined and debated. Dismissing opposing views as "AI bots" does not, on its own, explain why the arguments are wrong. I believe the PDWG benefits most when participants engage with the substance of each other's reasoning, regardless of how a contribution was drafted. Kind regards, Fundiswa Nadia Maseko On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, wrote: > Fundiswa, > But the AI bots opposing the AS-SET policy aren?t making technical > arguments. They are just regurgitating and re-using the same script. None > of them seem to know or care what an AS-SET is, or what network owners use > them for. > > Cheers, > Ben > Sent from my iPhone > > On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko > wrote: > > ? > > *Dear PDWG,* > > I have been following this discussion with interest, and I would like to > express my concern about the direction it has taken. > > The Policy Development Process should evaluate technical arguments on > their merits. Whether a participant drafted a message unaided, received > editorial assistance, or used modern writing tools does not determine > whether the reasoning is sound. Speculating about authorship instead of > addressing the substance risks distracting the Working Group from the > policy questions before it. > > I am also concerned by suggestions that contributions should be > disregarded simply because of assumptions about how they were written. If > there are factual or technical errors, they should be identified and > discussed. That is how consensus is strengthened. > > The questions raised by several participants remain legitimate subjects > for technical debate: whether the proposal has demonstrated operational > necessity, whether the proposed intervention is proportionate, and whether > less restrictive alternatives have been adequately considered. > > I therefore encourage all participants to continue engaging with the > substance of the proposal while maintaining the respectful and professional > standards expected within the PDWG. > > Kind regards, > > Fundiswa Nadia Maseko > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Sun Jul 19 17:56:05 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Sun, 19 Jul 2026 17:56:05 +0000 Subject: [rpd] Fw: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: ________________________________ From: Tshepo Masuku Sent: Sunday, 19 July 2026 19:40:54 To: rpd-request at afrinic.net ; noah at neo.co.tz Subject: Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Dear PDWG, Speculating that participants are ?AI agents? is not a valid basis for excluding them or assessing consensus. If several objections raise the same point, the co-chairs may group them. But the substance must still be addressed. Similar wording does not make an objection invalid, and familiarity or workplace status does not create a greater mandate to participate. The unresolved issue remains whether this proposal is necessary, proportionate, and sufficient to address the stated problem. That question should be assessed on evidence, not assumptions about who drafted a message. Participation is not authority, and a mailing list should not become a gatekeeping exercise. I remain opposed. Regards, Tshepo -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Sun Jul 19 18:04:03 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Sun, 19 Jul 2026 20:04:03 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) In-Reply-To: References: Message-ID: <0B9F65CE-7417-4996-84C6-7E395FB27544@hevis.co.za> Dear Thulisile, Why did you also use an AI to respond? Claude: `Yes ? and it's the same drafting pipeline again, now writing a defense of itself. That's the most interesting thing about this one: the thread has become recursive, and the message quotes my own analysis back while exhibiting the exact markers that analysis described.a --- 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 On 19 Jul 2026, at 19:39, Thulisile Mazomba wrote: > Dear colleagues, > > This discussion has moved away from the proposal and toward > questioning who is allowed to object. > > Whether someone operates an ASN, uses drafting assistance, is new to > the list, or is unfamiliar to long-standing participants does not > determine whether their argument is valid. The PDP should examine the > substance of an objection, not attempt to infer authorship from > writing style or rank participants according to reputation. > > Submitting text to another language model does not establish who wrote > it, who contributed to it, or whether the person posting it agrees > with it. A probability produced by Claude is not evidence of > astroturfing. It is an automated opinion about prose. > > Hendrik?s own quoted analysis concedes the important point: the > distinction between authenticating the creator of an AS-SET and > validating its contents is a real objection that still requires an > answer. That issue does not disappear because the wording appears > polished. > > The request to identify which ASNs objectors ?represent? also > misunderstands participation. I am not claiming to represent every > African operator, nor should any individual participant make that > claim without authority. I am participating in my own capacity. An ASN > is not a voting credential, and operating one does not give its holder > a larger mandate over the policy process. > > Frank?s road-rule analogy is also misplaced. Governments impose > traffic laws through public authority and accept legal accountability > for doing so. AFRINIC is a private registry operating a technical > database. The existence of a working group does not turn that registry > into a legislature or every preferred operational practice into the > equivalent of public law. > > The question before us remains simple: does this proposal solve the > specific harm claimed, and is mandatory registry enforcement the > minimum necessary mechanism? > > Hierarchical naming may reduce future name collisions. That is a > useful property. It does not validate the accuracy of AS-SET > membership, prevent incorrect customer-cone data, or make generated > filters trustworthy by itself. Those limitations should be assessed > honestly rather than buried beneath accusations about who wrote which > paragraph. > > If the co-chairs believe several objections raise the same substantive > issue, they may group them as one issue. That is reasonable. But they > should then determine whether the issue has been answered on its > merits. They should not discount it because the participants are > unfamiliar, share a view, use similar language, or may have used > writing tools. > > Participation provides evidence, criticism, and warning. Familiarity > does not create mandate. Reputation does not replace proof. A mailing > list should not become a private club in which established names > decide which speakers count. > > I remain opposed to the proposal and ask that the discussion return to > the proposal?s technical scope, demonstrated benefit, limitations, > and proportionality. > > Regards, > Thulisile -------------- next part -------------- An HTML attachment was scrubbed... URL: From gugudhlamini343 at gmail.com Sun Jul 19 18:09:25 2026 From: gugudhlamini343 at gmail.com (Gugu Dhlamini) Date: Sun, 19 Jul 2026 20:09:25 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 45 In-Reply-To: <6487b0cf-568f-44ad-94b0-f3dff9eb21bd@geier.ne.tz> References: <6487b0cf-568f-44ad-94b0-f3dff9eb21bd@geier.ne.tz> Message-ID: Dear Frank, A problem statement establishes that a concern exists. It does not establish that this proposal is necessary, proportionate, or the only valid remedy. Questioning and asking that contributions be disregarded because their wording appears similar is not consensus assessment. It is #Gatekeeping. Participation may provide evidence and objection; familiarity and style do not create or remove mandate. Please answer the unresolved policy concern rather than analyse the people raising it. I remain opposed. Regards, Gugu On Sun, 19 Jul 2026, 3:00 pm Frank Habicht wrote: > Hi, > > inline... > > On 7/18/2026 10:49 PM, Nia Petronella wrote: > > Dear PDWG, > > > > I agree with Asamkele, Gugu, and Tshepo, and I remain opposed to this > > proposal. > > > > Responding to objectors one by one does not resolve the common concern > > they have raised. A collision between AS-SET labels is not a failure of > > ASN or prefix uniqueness, > > It is a failure of AS-SET uniqueness. > Which are not among the famous 3 INR that AfriNIC primarily deals with. > But they are important objects in the IRR. Which AfriNIC operates. And > thus AfriNIC should set the policies under which it operates the IRR. > > > and repeating that characterization does not > > make it technically correct. > > Maybe my above statement is not a repetition, and could be technically > correct? > > > The proposal still has not demonstrated measurable operational harm, > > Would it be better if someone would have added this to the proposal: > "" MANRS documented the incident with AS-AMAZON back in 2022, > > https://manrs.org/2022/12/why-network-operators-should-use-hierarchical-as-sets/. > > At the time of writing Google's official source for their AS-SET is RADB > as documented in their PeeringDB entry > https://www.peeringdb.com/net/433, but AS-GOOGLE currently exists as an > empty AS-SET in the RIPE DB > > https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=AS-GOOGLE&type=as-set. > > "" > > Would you then agree that the proposal demonstrated harm? > > Just because you didn't see it doesn't mean there was no harm. > > > > why > > voluntary hierarchical naming is insufficient, > > the author posted on this mailing list the number of collisions that exist. > > > or why mandatory registry > > intervention is the least restrictive solution. > > This is where you can propose a less restrictive solution. > > > Adoption by other RIRs > > is relevant, but institutional uniformity is not proof of technical > > necessity. > > Harm that was documented is the proof of technical necessity. > > > A policy process should examine objections on their merits, not treat > > repeated disagreement as something to be individually overcome. > > Thanks. Was the AI asked to produce a certain quantity of text, so that > this blah had to be included? > > > The > > registry should support accurate routing information without converting > > every preferred convention into compulsory policy. > > Now, I have a question. > > If "the registry" (AfriNIC) gets this information: > > as-set: AS-GOOGLE > tech-c: AS156-AFRINIC > admin-c: AS156-AFRINIC > mnt-by: google_kenya > source: AFRINIC # Filtered > descr: AS-GOOGLE > > > and another registry (RADB) has this information: > > as-set: AS-GOOGLE > descr: Google > members: AS11344 > members: AS13949 > members: AS15169 > members: AS15276 > members: AS19425 > members: AS22577 > members: AS26910 > members: AS36040 > members: AS36384 > members: AS36492 > members: AS36561 > members: AS394725 > members: AS40873 > members: AS41264 > members: AS43515 > members: AS55023 > members: AS6432 > members: AS19527 > members: AS26684 > members: AS395973 > members: AS36039 > members: AS24424 > members: AS396982 > members: AS139070 > members: AS139190 > members: AS394699 > members: AS-GOOGLE-IT > members: AS-MEEBO > members: AS-METAWEB-2 > members: AS32381 > members: AS36383 > members: AS36411 > members: AS36520 > members: AS394089 > mnt-by: MAINT-AS15169 > changed: arturolev at google.com 20231030 #16:36:58Z > source: RADB > last-modified: 2023-11-13T16:19:21Z > > then what should the person or the software generating a prefix-filter do? > > Awaiting this answer. > > It's important. Because this is what this discussion is about. Any > indication that the opponents have understood this will be welcome. > > Frank Habicht > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Sun Jul 19 18:09:35 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Sun, 19 Jul 2026 20:09:35 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: <5677688B-5E12-4BB1-BE12-1F9EB5739B40@hevis.co.za> Dear Asamkele Claude: `Same pipeline, fourth voice ? and this one is useful to you, because it's the first letter that visibly repeats rather than extends.` Claude: `Still zero contractions, zero concrete operational detail, zero personal grounding. "Running-code discipline" is the one gesture at IETF culture, deployed as a slogan rather than an anecdote ? a model reaching for community credibility markers.` Claude?s analysis: ``` **Why the repetition helps you** Across four letters the pipeline has now produced: 1. Nonhlanhla ? authentication-vs-content + minimum-intervention 2. Gugu ? meta version (mandate laundering, thin layer) 3. Thulisile ? procedural defense of the objectors 4. Asamkele ? authentication-vs-content + minimum-intervention *again*, with a reshuffled alternatives list Letters 1 and 4 are substantively one letter. That's your consolidation case made for you: you can now write, without any authorship claims, "Asamkele's objection restates Nonhlanhla's ? the attribution/content distinction and the less-coercive-alternatives list ? which I've answered at [reference]. No new substance has been introduced." Under rough-consensus practice, an objection that's been answered doesn't become unanswered by being repeated in fresh phrasing, and co-chairs can and should treat it as closed unless the repetition adds something. ``` --- 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 On 19 Jul 2026, at 19:25, Asamkele Menzeleli wrote: > Dear Hendrik, > > I remain opposed. > > Your argument proves less than you suggest. Hierarchical naming may > identify which ASN maintainer created an AS-SET, but it does not prove > that > every member placed inside that set was authorised by the affected > networks. It establishes attribution of the object. It does not > establish > the correctness of its contents. > > That distinction matters because the routing harm you describe arises > when > operators rely on inaccurate or misleading AS-SET expansion. > Prefix-list > tools consume the membership data, not merely the name. Binding a name > to > an ASN therefore does not, by itself, prevent an authorised maintainer > from > publishing an incorrect customer cone, omitting legitimate members, or > including routes it should not include. > > The proposal is consequently being presented as though it closes an > authorisation problem that it only partly addresses. It authenticates > who > created the container. It does not authenticate every relationship > represented inside the container. > > Nor does the existence of a flat namespace automatically require > AFRINIC to > prohibit it. Source-qualified lookups, explicit object references, > collision warnings, validation rules, local rejection, and voluntary > hierarchical objects are all less coercive mechanisms that should be > evaluated first. The fact that tooling consumes ambiguous data is an > argument for deterministic validation and safer tooling, not > automatically > for expanding the registry?s permission layer. > > This is the precise point of running-code discipline: identify the > invariant, define the failure, and use the minimum rule necessary to > protect it. Do not take one operational risk, rename it ?proof of > control,? > and then treat that vocabulary as sufficient authority for compulsory > policy. > > A registry may record who maintains an object. It may expose conflicts > and > provide stronger validation. It should not confuse control of an ASN > with > ownership of every routing relationship that someone chooses to place > beneath that ASN?s name. > > The proposal therefore still fails the proportionality test. It has > not > shown that mandatory hierarchical naming eliminates the claimed > routing > harm, only that it makes the creator of a new object easier to > identify. > Administrative attribution is useful. It is not the same thing as > routing > authorisation. > > My objection remains. > > Regards, > Asamkele Menzeleli -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Sun Jul 19 18:24:26 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Sun, 19 Jul 2026 20:24:26 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 69 In-Reply-To: References: Message-ID: Dear Mr Hendrik, It is hard to reconcile your position with the digital future that AFRINIC itself is promoting. This community encourages the use of technology such as IPv6 transition, automation and modern network tools. Yet when participants use online resources to organize their contributions, that same technological progress is suddenly seen as a cause for suspicion or exclusion. The question is not whether assistance was used. It is whether or not the message is from a real person and whether or not the argument is sound. Digital inclusion can?t be about embracing technology only when the incumbents like the user. Concentrate on the policy objections, rather than attempting to discredit the people making them. Kind regards, Nonhlanhla On Sun, 19 Jul 2026, 8:10 pm wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of > Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) > (Hendrik Visage) > 2. Re: RPD Digest, Vol 222, Issue 45 (Gugu Dhlamini) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 19 Jul 2026 20:04:03 +0200 > From: Hendrik Visage > To: Thulisile Mazomba <219280444 at mycput.ac.za> > Cc: rpd-owner at afrinic.net, rpd at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of > Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) > Message-ID: <0B9F65CE-7417-4996-84C6-7E395FB27544 at hevis.co.za> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Dear Thulisile, > > Why did you also use an AI to respond? > > Claude: `Yes ? and it's the same drafting pipeline again, now writing > a defense of itself. That's the most interesting thing about this one: > the thread has become recursive, and the message quotes my own analysis > back while exhibiting the exact markers that analysis described.a > > --- > 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 > > On 19 Jul 2026, at 19:39, Thulisile Mazomba wrote: > > > Dear colleagues, > > > > This discussion has moved away from the proposal and toward > > questioning who is allowed to object. > > > > Whether someone operates an ASN, uses drafting assistance, is new to > > the list, or is unfamiliar to long-standing participants does not > > determine whether their argument is valid. The PDP should examine the > > substance of an objection, not attempt to infer authorship from > > writing style or rank participants according to reputation. > > > > Submitting text to another language model does not establish who wrote > > it, who contributed to it, or whether the person posting it agrees > > with it. A probability produced by Claude is not evidence of > > astroturfing. It is an automated opinion about prose. > > > > Hendrik?s own quoted analysis concedes the important point: the > > distinction between authenticating the creator of an AS-SET and > > validating its contents is a real objection that still requires an > > answer. That issue does not disappear because the wording appears > > polished. > > > > The request to identify which ASNs objectors ?represent? also > > misunderstands participation. I am not claiming to represent every > > African operator, nor should any individual participant make that > > claim without authority. I am participating in my own capacity. An ASN > > is not a voting credential, and operating one does not give its holder > > a larger mandate over the policy process. > > > > Frank?s road-rule analogy is also misplaced. Governments impose > > traffic laws through public authority and accept legal accountability > > for doing so. AFRINIC is a private registry operating a technical > > database. The existence of a working group does not turn that registry > > into a legislature or every preferred operational practice into the > > equivalent of public law. > > > > The question before us remains simple: does this proposal solve the > > specific harm claimed, and is mandatory registry enforcement the > > minimum necessary mechanism? > > > > Hierarchical naming may reduce future name collisions. That is a > > useful property. It does not validate the accuracy of AS-SET > > membership, prevent incorrect customer-cone data, or make generated > > filters trustworthy by itself. Those limitations should be assessed > > honestly rather than buried beneath accusations about who wrote which > > paragraph. > > > > If the co-chairs believe several objections raise the same substantive > > issue, they may group them as one issue. That is reasonable. But they > > should then determine whether the issue has been answered on its > > merits. They should not discount it because the participants are > > unfamiliar, share a view, use similar language, or may have used > > writing tools. > > > > Participation provides evidence, criticism, and warning. Familiarity > > does not create mandate. Reputation does not replace proof. A mailing > > list should not become a private club in which established names > > decide which speakers count. > > > > I remain opposed to the proposal and ask that the discussion return to > > the proposal?s technical scope, demonstrated benefit, limitations, > > and proportionality. > > > > Regards, > > Thulisile > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260719/421ab07f/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Sun, 19 Jul 2026 20:09:25 +0200 > From: Gugu Dhlamini > To: Frank Habicht , rpd-owner at afrinic.net > Cc: rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 45 > Message-ID: > < > CADMrvbNHq+u4HTi1r9qNoX4A9LH69czSnPoAAeVPSYq8oai01A at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Frank, > > A problem statement establishes that a concern exists. It does not > establish that this proposal is necessary, proportionate, or the only valid > remedy. > > Questioning and asking that contributions be disregarded because their > wording appears similar is not consensus assessment. It is #Gatekeeping. > Participation may provide evidence and objection; familiarity and style do > not create or remove mandate. > > Please answer the unresolved policy concern rather than analyse the people > raising it. > > I remain opposed. > > Regards, > Gugu > > On Sun, 19 Jul 2026, 3:00 pm Frank Habicht wrote: > > > Hi, > > > > inline... > > > > On 7/18/2026 10:49 PM, Nia Petronella wrote: > > > Dear PDWG, > > > > > > I agree with Asamkele, Gugu, and Tshepo, and I remain opposed to this > > > proposal. > > > > > > Responding to objectors one by one does not resolve the common concern > > > they have raised. A collision between AS-SET labels is not a failure of > > > ASN or prefix uniqueness, > > > > It is a failure of AS-SET uniqueness. > > Which are not among the famous 3 INR that AfriNIC primarily deals with. > > But they are important objects in the IRR. Which AfriNIC operates. And > > thus AfriNIC should set the policies under which it operates the IRR. > > > > > and repeating that characterization does not > > > make it technically correct. > > > > Maybe my above statement is not a repetition, and could be technically > > correct? > > > > > The proposal still has not demonstrated measurable operational harm, > > > > Would it be better if someone would have added this to the proposal: > > "" MANRS documented the incident with AS-AMAZON back in 2022, > > > > > https://manrs.org/2022/12/why-network-operators-should-use-hierarchical-as-sets/ > . > > > > At the time of writing Google's official source for their AS-SET is RADB > > as documented in their PeeringDB entry > > https://www.peeringdb.com/net/433, but AS-GOOGLE currently exists as an > > empty AS-SET in the RIPE DB > > > > > https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=AS-GOOGLE&type=as-set > . > > > > "" > > > > Would you then agree that the proposal demonstrated harm? > > > > Just because you didn't see it doesn't mean there was no harm. > > > > > > > why > > > voluntary hierarchical naming is insufficient, > > > > the author posted on this mailing list the number of collisions that > exist. > > > > > or why mandatory registry > > > intervention is the least restrictive solution. > > > > This is where you can propose a less restrictive solution. > > > > > Adoption by other RIRs > > > is relevant, but institutional uniformity is not proof of technical > > > necessity. > > > > Harm that was documented is the proof of technical necessity. > > > > > A policy process should examine objections on their merits, not treat > > > repeated disagreement as something to be individually overcome. > > > > Thanks. Was the AI asked to produce a certain quantity of text, so that > > this blah had to be included? > > > > > The > > > registry should support accurate routing information without converting > > > every preferred convention into compulsory policy. > > > > Now, I have a question. > > > > If "the registry" (AfriNIC) gets this information: > > > > as-set: AS-GOOGLE > > tech-c: AS156-AFRINIC > > admin-c: AS156-AFRINIC > > mnt-by: google_kenya > > source: AFRINIC # Filtered > > descr: AS-GOOGLE > > > > > > and another registry (RADB) has this information: > > > > as-set: AS-GOOGLE > > descr: Google > > members: AS11344 > > members: AS13949 > > members: AS15169 > > members: AS15276 > > members: AS19425 > > members: AS22577 > > members: AS26910 > > members: AS36040 > > members: AS36384 > > members: AS36492 > > members: AS36561 > > members: AS394725 > > members: AS40873 > > members: AS41264 > > members: AS43515 > > members: AS55023 > > members: AS6432 > > members: AS19527 > > members: AS26684 > > members: AS395973 > > members: AS36039 > > members: AS24424 > > members: AS396982 > > members: AS139070 > > members: AS139190 > > members: AS394699 > > members: AS-GOOGLE-IT > > members: AS-MEEBO > > members: AS-METAWEB-2 > > members: AS32381 > > members: AS36383 > > members: AS36411 > > members: AS36520 > > members: AS394089 > > mnt-by: MAINT-AS15169 > > changed: arturolev at google.com 20231030 #16:36:58Z > > source: RADB > > last-modified: 2023-11-13T16:19:21Z > > > > then what should the person or the software generating a prefix-filter > do? > > > > Awaiting this answer. > > > > It's important. Because this is what this discussion is about. Any > > indication that the opponents have understood this will be welcome. > > > > Frank Habicht > > > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260719/a7141280/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 69 > ************************************ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Sun Jul 19 18:25:00 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Sun, 19 Jul 2026 20:25:00 +0200 Subject: [rpd] =?utf-8?q?=5BLast_Call=5D_Draft_Policy_Proposal_=E2=80=93__?= =?utf-8?q?Hierarchical_Names_for_New_AS-SETs_=28AFPUB-2026-ASN-001-DRAFT0?= =?utf-8?q?2=29?= In-Reply-To: References: Message-ID: <24327C8E-E411-4D2F-BE55-F250691CD720@hevis.co.za> Dear Fundiswa, ?Has the proposal demonstrated mandatory naming is the least restrictive solution?" ? Yes, "Do you disagree that hierarchical naming authenticates object creation rather than membership accuracy?" ? No. These are the specific answers requested. If you still oppose this proposal, we ask that you engage these answers first ? in particular the deployment-coordination asymmetry raised ? instead of repeating the original objections without technical substances --- 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 On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: > Dear Ben, > > Thank you for your response. > > Respectfully, I believe it is more productive to address the arguments > themselves than to make assumptions about the people presenting them > or the > tools they may have used. > > If you believe the objections are technically incorrect, I would > appreciate > it if you could identify which specific points you disagree with. For > example, do you disagree that hierarchical naming authenticates object > creation rather than the accuracy of object membership? Or do you > believe > the proposal has demonstrated that mandatory naming is the least > restrictive solution available? > > Those are technical questions that can be examined and debated. > Dismissing > opposing views as "AI bots" does not, on its own, explain why the > arguments > are wrong. > I believe the PDWG benefits most when participants engage with the > substance of each other's reasoning, regardless of how a contribution > was > drafted. > > > Kind regards, > Fundiswa Nadia Maseko > > On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, > > wrote: > >> Fundiswa, >> But the AI bots opposing the AS-SET policy aren?t making technical >> arguments. They are just regurgitating and re-using the same script. >> None >> of them seem to know or care what an AS-SET is, or what network >> owners use >> them for. >> >> Cheers, >> Ben >> Sent from my iPhone >> >> On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko >> >> wrote: >> >> ? >> >> *Dear PDWG,* >> >> I have been following this discussion with interest, and I would like >> to >> express my concern about the direction it has taken. >> >> The Policy Development Process should evaluate technical arguments on >> their merits. Whether a participant drafted a message unaided, >> received >> editorial assistance, or used modern writing tools does not determine >> whether the reasoning is sound. Speculating about authorship instead >> of >> addressing the substance risks distracting the Working Group from the >> policy questions before it. >> >> I am also concerned by suggestions that contributions should be >> disregarded simply because of assumptions about how they were >> written. If >> there are factual or technical errors, they should be identified and >> discussed. That is how consensus is strengthened. >> >> The questions raised by several participants remain legitimate >> subjects >> for technical debate: whether the proposal has demonstrated >> operational >> necessity, whether the proposed intervention is proportionate, and >> whether >> less restrictive alternatives have been adequately considered. >> >> I therefore encourage all participants to continue engaging with the >> substance of the proposal while maintaining the respectful and >> professional >> standards expected within the PDWG. >> >> Kind regards, >> >> Fundiswa Nadia Maseko >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From saul at enetworks.co.za Sun Jul 19 18:34:04 2026 From: saul at enetworks.co.za (Saul Stein) Date: Sun, 19 Jul 2026 18:34:04 +0000 Subject: [rpd] =?utf-8?q?=5BLast_Call=5D_Draft_Policy_Proposal_=E2=80=93__?= =?utf-8?q?Hierarchical_Names_for_New_AS-SETs_=28AFPUB-2026-ASN-001-DRAFT0?= =?utf-8?q?2=29?= In-Reply-To: <24327C8E-E411-4D2F-BE55-F250691CD720@hevis.co.za> References: <24327C8E-E411-4D2F-BE55-F250691CD720@hevis.co.za> Message-ID: Dear all, Well, I have just finished my popcorn? sadly there wasn?t enough to read the bombardment of emails, so I didn?t. What I did see though, was a number of non-original / cvopy and paste objections. Not only that, but more importantly, they do not raise any valid concerns about the proposal that has reached final call. So with that in mind, I fully support this proposal. I?d have to be part of a community group where you have to have a valid NIC to post? Regards Saul From: Hendrik Visage via RPD Sent: Sunday, 19 July 2026 20:25 To: Fundiswa Nadia Maseko Cc: rpd at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Dear Fundiswa, ?Has the proposal demonstrated mandatory naming is the least restrictive solution?" ? Yes, "Do you disagree that hierarchical naming authenticates object creation rather than membership accuracy?" ? No. These are the specific answers requested. If you still oppose this proposal, we ask that you engage these answers first ? in particular the deployment-coordination asymmetry raised ? instead of repeating the original objections without technical substances ________________________________ 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 On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: Dear Ben, Thank you for your response. Respectfully, I believe it is more productive to address the arguments themselves than to make assumptions about the people presenting them or the tools they may have used. If you believe the objections are technically incorrect, I would appreciate it if you could identify which specific points you disagree with. For example, do you disagree that hierarchical naming authenticates object creation rather than the accuracy of object membership? Or do you believe the proposal has demonstrated that mandatory naming is the least restrictive solution available? Those are technical questions that can be examined and debated. Dismissing opposing views as "AI bots" does not, on its own, explain why the arguments are wrong. I believe the PDWG benefits most when participants engage with the substance of each other's reasoning, regardless of how a contribution was drafted. Kind regards, Fundiswa Nadia Maseko On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, > wrote: Fundiswa, But the AI bots opposing the AS-SET policy aren?t making technical arguments. They are just regurgitating and re-using the same script. None of them seem to know or care what an AS-SET is, or what network owners use them for. Cheers, Ben Sent from my iPhone On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko > wrote: ? Dear PDWG, I have been following this discussion with interest, and I would like to express my concern about the direction it has taken. The Policy Development Process should evaluate technical arguments on their merits. Whether a participant drafted a message unaided, received editorial assistance, or used modern writing tools does not determine whether the reasoning is sound. Speculating about authorship instead of addressing the substance risks distracting the Working Group from the policy questions before it. I am also concerned by suggestions that contributions should be disregarded simply because of assumptions about how they were written. If there are factual or technical errors, they should be identified and discussed. That is how consensus is strengthened. The questions raised by several participants remain legitimate subjects for technical debate: whether the proposal has demonstrated operational necessity, whether the proposed intervention is proportionate, and whether less restrictive alternatives have been adequately considered. I therefore encourage all participants to continue engaging with the substance of the proposal while maintaining the respectful and professional standards expected within the PDWG. Kind regards, Fundiswa Nadia Maseko _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Sun Jul 19 18:38:00 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Sun, 19 Jul 2026 20:38:00 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <24327C8E-E411-4D2F-BE55-F250691CD720@hevis.co.za> Message-ID: Dear Hendrik, Thank you for taking the time to answer my questions. I think we actually agree on one important point: hierarchical naming authenticates who creates the object, but it does not guarantee that the contents of the object are accurate. That was the distinction I was trying to make. Where we still differ is on whether that justifies making the naming convention mandatory. I understand your position that this is the narrowest solution available, but I'm not yet convinced that less restrictive alternatives have been ruled out. I still think that point deserves more discussion. I also don't believe that the fact that other RIRs have adopted the same approach automatically means AFRINIC must do so. It's useful context, but I don't think it replaces the need to show why this is necessary for our own policy process. I'm not trying to oppose operational improvements. I'm simply asking whether a mandatory policy is the only way to achieve the intended outcome. I think that's a reasonable question for the Working Group to discuss. Kind regards, Fundiswa Nadia Maseko On Sun, 19 Jul 2026, 20:34 Saul Stein, wrote: > Dear all, > > Well, I have just finished my popcorn? sadly there wasn?t enough to read > the bombardment of emails, so I didn?t. > > > > What I did see though, was a number of non-original / cvopy and paste > objections. Not only that, but more importantly, they do not raise any > valid concerns about the proposal that has reached final call. > > > > So with that in mind, I fully support this proposal. > > > > I?d have to be part of a community group where you have to have a valid > NIC to post? > > > > Regards > > Saul > > > > > > *From:* Hendrik Visage via RPD > *Sent:* Sunday, 19 July 2026 20:25 > *To:* Fundiswa Nadia Maseko > *Cc:* rpd at afrinic.net > *Subject:* Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > > > Dear Fundiswa, > > ?Has the proposal demonstrated mandatory naming is the least restrictive > solution?" ? Yes, > > "Do you disagree that hierarchical naming authenticates object creation > rather than membership accuracy?" ? No. > > These are the specific answers requested. > If you still oppose this proposal, we ask that you engage these answers > first ? in particular the deployment-coordination asymmetry raised ? > instead of repeating the original objections without technical substances > ------------------------------ > > 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 > > On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: > > Dear Ben, > > > > Thank you for your response. > > > > Respectfully, I believe it is more productive to address the arguments > themselves than to make assumptions about the people presenting them or the > tools they may have used. > > > > If you believe the objections are technically incorrect, I would > appreciate it if you could identify which specific points you disagree > with. For example, do you disagree that hierarchical naming authenticates > object creation rather than the accuracy of object membership? Or do you > believe the proposal has demonstrated that mandatory naming is the least > restrictive solution available? > > > > Those are technical questions that can be examined and debated. Dismissing > opposing views as "AI bots" does not, on its own, explain why the arguments > are wrong. > > I believe the PDWG benefits most when participants engage with the > substance of each other's reasoning, regardless of how a contribution was > drafted. > > > > > > Kind regards, > > Fundiswa Nadia Maseko > > > > On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, > wrote: > > Fundiswa, > > But the AI bots opposing the AS-SET policy aren?t making technical > arguments. They are just regurgitating and re-using the same script. None > of them seem to know or care what an AS-SET is, or what network owners use > them for. > > > > Cheers, > > Ben > > Sent from my iPhone > > > > On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko > wrote: > > ? > > *Dear PDWG,* > > I have been following this discussion with interest, and I would like to > express my concern about the direction it has taken. > > The Policy Development Process should evaluate technical arguments on > their merits. Whether a participant drafted a message unaided, received > editorial assistance, or used modern writing tools does not determine > whether the reasoning is sound. Speculating about authorship instead of > addressing the substance risks distracting the Working Group from the > policy questions before it. > > I am also concerned by suggestions that contributions should be > disregarded simply because of assumptions about how they were written. If > there are factual or technical errors, they should be identified and > discussed. That is how consensus is strengthened. > > The questions raised by several participants remain legitimate subjects > for technical debate: whether the proposal has demonstrated operational > necessity, whether the proposed intervention is proportionate, and whether > less restrictive alternatives have been adequately considered. > > I therefore encourage all participants to continue engaging with the > substance of the proposal while maintaining the respectful and professional > standards expected within the PDWG. > > Kind regards, > > Fundiswa Nadia Maseko > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Sun Jul 19 18:40:22 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Sun, 19 Jul 2026 20:40:22 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <24327C8E-E411-4D2F-BE55-F250691CD720@hevis.co.za> Message-ID: Dear PDWG, I would like to add one observation regarding the recent discussion about AI-assisted writing. Many people today use AI as a writing aid to improve grammar, structure, or clarity. That does not necessarily mean the ideas, reasoning, or conclusions are generated by the tool. The author still decides what arguments to make, what evidence to rely on, and whether those arguments accurately reflect their own views. For that reason, I do not believe the validity of a technical contribution should be judged by assumptions about how it was drafted. If an argument is technically incorrect, then it should be challenged on technical grounds. If it is incomplete, then it should be explained why. That approach strengthens the Policy Development Process far more than speculating about authorship or writing tools. The purpose of this Working Group is to evaluate technical arguments on their merits. I hope we can continue doing exactly that. Kind regards, Fundiswa Nadia Maseko On Sun, 19 Jul 2026, 20:34 Saul Stein, wrote: > Dear all, > > Well, I have just finished my popcorn? sadly there wasn?t enough to read > the bombardment of emails, so I didn?t. > > > > What I did see though, was a number of non-original / cvopy and paste > objections. Not only that, but more importantly, they do not raise any > valid concerns about the proposal that has reached final call. > > > > So with that in mind, I fully support this proposal. > > > > I?d have to be part of a community group where you have to have a valid > NIC to post? > > > > Regards > > Saul > > > > > > *From:* Hendrik Visage via RPD > *Sent:* Sunday, 19 July 2026 20:25 > *To:* Fundiswa Nadia Maseko > *Cc:* rpd at afrinic.net > *Subject:* Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > > > Dear Fundiswa, > > ?Has the proposal demonstrated mandatory naming is the least restrictive > solution?" ? Yes, > > "Do you disagree that hierarchical naming authenticates object creation > rather than membership accuracy?" ? No. > > These are the specific answers requested. > If you still oppose this proposal, we ask that you engage these answers > first ? in particular the deployment-coordination asymmetry raised ? > instead of repeating the original objections without technical substances > ------------------------------ > > 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 > > On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: > > Dear Ben, > > > > Thank you for your response. > > > > Respectfully, I believe it is more productive to address the arguments > themselves than to make assumptions about the people presenting them or the > tools they may have used. > > > > If you believe the objections are technically incorrect, I would > appreciate it if you could identify which specific points you disagree > with. For example, do you disagree that hierarchical naming authenticates > object creation rather than the accuracy of object membership? Or do you > believe the proposal has demonstrated that mandatory naming is the least > restrictive solution available? > > > > Those are technical questions that can be examined and debated. Dismissing > opposing views as "AI bots" does not, on its own, explain why the arguments > are wrong. > > I believe the PDWG benefits most when participants engage with the > substance of each other's reasoning, regardless of how a contribution was > drafted. > > > > > > Kind regards, > > Fundiswa Nadia Maseko > > > > On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, > wrote: > > Fundiswa, > > But the AI bots opposing the AS-SET policy aren?t making technical > arguments. They are just regurgitating and re-using the same script. None > of them seem to know or care what an AS-SET is, or what network owners use > them for. > > > > Cheers, > > Ben > > Sent from my iPhone > > > > On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko > wrote: > > ? > > *Dear PDWG,* > > I have been following this discussion with interest, and I would like to > express my concern about the direction it has taken. > > The Policy Development Process should evaluate technical arguments on > their merits. Whether a participant drafted a message unaided, received > editorial assistance, or used modern writing tools does not determine > whether the reasoning is sound. Speculating about authorship instead of > addressing the substance risks distracting the Working Group from the > policy questions before it. > > I am also concerned by suggestions that contributions should be > disregarded simply because of assumptions about how they were written. If > there are factual or technical errors, they should be identified and > discussed. That is how consensus is strengthened. > > The questions raised by several participants remain legitimate subjects > for technical debate: whether the proposal has demonstrated operational > necessity, whether the proposed intervention is proportionate, and whether > less restrictive alternatives have been adequately considered. > > I therefore encourage all participants to continue engaging with the > substance of the proposal while maintaining the respectful and professional > standards expected within the PDWG. > > Kind regards, > > Fundiswa Nadia Maseko > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gugudhlamini343 at gmail.com Sun Jul 19 18:41:31 2026 From: gugudhlamini343 at gmail.com (Gugu Dhlamini) Date: Sun, 19 Jul 2026 20:41:31 +0200 Subject: [rpd] =?utf-8?q?=5BLast_Call=5D_Draft_Policy_Proposal_=E2=80=93_H?= =?utf-8?q?ierarchical_Names_for_New_AS-SETs_=28AFPUB-2026-ASN-001-?= =?utf-8?q?DRAFT02=29?= In-Reply-To: References: <24327C8E-E411-4D2F-BE55-F250691CD720@hevis.co.za> Message-ID: Hi Saul, That is precisely the problem. When something gets to last call that doesn?t mean objections don?t matter. The last call is meant to test unresolved concerns, not to dismiss them because the proposal has gone far enough through the process. Saying objections are ?copy and paste? doesn?t answer them. If the same issue is brought up by a few people, then deal with the issue. Just because you repeat a concern doesn?t make it any less valid. That's exactly how mandate laundering works: procedure is conflated with authority, and once a proposal has passed through enough stages, disagreement is framed as illegitimate, not substantive. The process shouldn?t generate consent just because some participants are tired of reading objections. I am still against it. Best, Gugu On Sun, 19 Jul 2026, 8:34 pm Saul Stein via RPD wrote: > Dear all, > > Well, I have just finished my popcorn? sadly there wasn?t enough to read > the bombardment of emails, so I didn?t. > > > > What I did see though, was a number of non-original / cvopy and paste > objections. Not only that, but more importantly, they do not raise any > valid concerns about the proposal that has reached final call. > > > > So with that in mind, I fully support this proposal. > > > > I?d have to be part of a community group where you have to have a valid > NIC to post? > > > > Regards > > Saul > > > > > > *From:* Hendrik Visage via RPD > *Sent:* Sunday, 19 July 2026 20:25 > *To:* Fundiswa Nadia Maseko > *Cc:* rpd at afrinic.net > *Subject:* Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > > > Dear Fundiswa, > > ?Has the proposal demonstrated mandatory naming is the least restrictive > solution?" ? Yes, > > "Do you disagree that hierarchical naming authenticates object creation > rather than membership accuracy?" ? No. > > These are the specific answers requested. > If you still oppose this proposal, we ask that you engage these answers > first ? in particular the deployment-coordination asymmetry raised ? > instead of repeating the original objections without technical substances > ------------------------------ > > 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 > > On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: > > Dear Ben, > > > > Thank you for your response. > > > > Respectfully, I believe it is more productive to address the arguments > themselves than to make assumptions about the people presenting them or the > tools they may have used. > > > > If you believe the objections are technically incorrect, I would > appreciate it if you could identify which specific points you disagree > with. For example, do you disagree that hierarchical naming authenticates > object creation rather than the accuracy of object membership? Or do you > believe the proposal has demonstrated that mandatory naming is the least > restrictive solution available? > > > > Those are technical questions that can be examined and debated. Dismissing > opposing views as "AI bots" does not, on its own, explain why the arguments > are wrong. > > I believe the PDWG benefits most when participants engage with the > substance of each other's reasoning, regardless of how a contribution was > drafted. > > > > > > Kind regards, > > Fundiswa Nadia Maseko > > > > On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, > wrote: > > Fundiswa, > > But the AI bots opposing the AS-SET policy aren?t making technical > arguments. They are just regurgitating and re-using the same script. None > of them seem to know or care what an AS-SET is, or what network owners use > them for. > > > > Cheers, > > Ben > > Sent from my iPhone > > > > On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko > wrote: > > ? > > *Dear PDWG,* > > I have been following this discussion with interest, and I would like to > express my concern about the direction it has taken. > > The Policy Development Process should evaluate technical arguments on > their merits. Whether a participant drafted a message unaided, received > editorial assistance, or used modern writing tools does not determine > whether the reasoning is sound. Speculating about authorship instead of > addressing the substance risks distracting the Working Group from the > policy questions before it. > > I am also concerned by suggestions that contributions should be > disregarded simply because of assumptions about how they were written. If > there are factual or technical errors, they should be identified and > discussed. That is how consensus is strengthened. > > The questions raised by several participants remain legitimate subjects > for technical debate: whether the proposal has demonstrated operational > necessity, whether the proposed intervention is proportionate, and whether > less restrictive alternatives have been adequately considered. > > I therefore encourage all participants to continue engaging with the > substance of the proposal while maintaining the respectful and professional > standards expected within the PDWG. > > Kind regards, > > Fundiswa Nadia Maseko > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Sun Jul 19 18:45:56 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Sun, 19 Jul 2026 20:45:56 +0200 Subject: [rpd] =?utf-8?q?=5BLast_Call=5D_Draft_Policy_Proposal_=E2=80=93_H?= =?utf-8?q?ierarchical_Names_for_New_AS-SETs_=28AFPUB-2026-ASN-001-?= =?utf-8?q?DRAFT02=29?= In-Reply-To: References: Message-ID: Dear Hendrik, Saul, and colleagues, Thank you for your responses. I would also like to address the recurring comments about AI-generated contributions. Whether someone uses AI to improve grammar, structure, or clarity does not, in itself, determine whether their arguments are valid. AI only works with the information and instructions provided by the person using it. Many people use it as a writing assistant to communicate their ideas more clearly, just as others may ask a colleague to proofread or edit a draft before sending it. For that reason, I do not believe the discussion should focus on how a message was written, but rather on whether the technical reasoning is correct or incorrect. With regard to the proposal itself, I appreciate Hendrik's direct answers. However, simply answering "yes" or "no" does not, by itself, explain the technical reasoning behind those conclusions. It would be helpful to understand why the proposal is considered the least restrictive solution and how the identified operational benefits outweigh the additional policy requirements. That explanation would assist everyone in evaluating the proposal on its technical merits. I believe the PDWG is strongest when differing views are examined through technical discussion supported by evidence, rather than assumptions about who wrote a message or what tools they may have used. Kind regards, Fundiswa Nadia Maseko On Sun, 19 Jul 2026, 20:34 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage) > 2. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Saul Stein) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 19 Jul 2026 20:25:00 +0200 > From: Hendrik Visage > To: Fundiswa Nadia Maseko > Cc: rpd at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: <24327C8E-E411-4D2F-BE55-F250691CD720 at hevis.co.za> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Dear Fundiswa, > > ?Has the proposal demonstrated mandatory naming is the least > restrictive solution?" ? Yes, > > "Do you disagree that hierarchical naming authenticates object creation > rather than membership accuracy?" ? No. > > These are the specific answers requested. > If you still oppose this proposal, we ask that you engage these answers > first ? in particular the deployment-coordination asymmetry raised ? > instead of repeating the original objections without technical > substances > > --- > 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 > > On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: > > > Dear Ben, > > > > Thank you for your response. > > > > Respectfully, I believe it is more productive to address the arguments > > themselves than to make assumptions about the people presenting them > > or the > > tools they may have used. > > > > If you believe the objections are technically incorrect, I would > > appreciate > > it if you could identify which specific points you disagree with. For > > example, do you disagree that hierarchical naming authenticates object > > creation rather than the accuracy of object membership? Or do you > > believe > > the proposal has demonstrated that mandatory naming is the least > > restrictive solution available? > > > > Those are technical questions that can be examined and debated. > > Dismissing > > opposing views as "AI bots" does not, on its own, explain why the > > arguments > > are wrong. > > I believe the PDWG benefits most when participants engage with the > > substance of each other's reasoning, regardless of how a contribution > > was > > drafted. > > > > > > Kind regards, > > Fundiswa Nadia Maseko > > > > On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, > > > > wrote: > > > >> Fundiswa, > >> But the AI bots opposing the AS-SET policy aren?t making technical > >> arguments. They are just regurgitating and re-using the same script. > >> None > >> of them seem to know or care what an AS-SET is, or what network > >> owners use > >> them for. > >> > >> Cheers, > >> Ben > >> Sent from my iPhone > >> > >> On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko > >> > >> wrote: > >> > >> ? > >> > >> *Dear PDWG,* > >> > >> I have been following this discussion with interest, and I would like > >> to > >> express my concern about the direction it has taken. > >> > >> The Policy Development Process should evaluate technical arguments on > >> their merits. Whether a participant drafted a message unaided, > >> received > >> editorial assistance, or used modern writing tools does not determine > >> whether the reasoning is sound. Speculating about authorship instead > >> of > >> addressing the substance risks distracting the Working Group from the > >> policy questions before it. > >> > >> I am also concerned by suggestions that contributions should be > >> disregarded simply because of assumptions about how they were > >> written. If > >> there are factual or technical errors, they should be identified and > >> discussed. That is how consensus is strengthened. > >> > >> The questions raised by several participants remain legitimate > >> subjects > >> for technical debate: whether the proposal has demonstrated > >> operational > >> necessity, whether the proposed intervention is proportionate, and > >> whether > >> less restrictive alternatives have been adequately considered. > >> > >> I therefore encourage all participants to continue engaging with the > >> substance of the proposal while maintaining the respectful and > >> professional > >> standards expected within the PDWG. > >> > >> Kind regards, > >> > >> Fundiswa Nadia Maseko > >> > >> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> > >> > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260719/3805216e/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Sun, 19 Jul 2026 18:34:04 +0000 > From: Saul Stein > To: Hendrik Visage , Fundiswa Nadia Maseko > > Cc: "rpd at afrinic.net" > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > < > JNAP275MB125812327DC4FFF2404C216E8EC42 at JNAP275MB1258.ZAFP275.PROD.OUTLOOK.COM > > > > Content-Type: text/plain; charset="utf-8" > > Dear all, > Well, I have just finished my popcorn? sadly there wasn?t enough to read > the bombardment of emails, so I didn?t. > > What I did see though, was a number of non-original / cvopy and paste > objections. Not only that, but more importantly, they do not raise any > valid concerns about the proposal that has reached final call. > > So with that in mind, I fully support this proposal. > > I?d have to be part of a community group where you have to have a valid > NIC to post? > > Regards > Saul > > > From: Hendrik Visage via RPD > Sent: Sunday, 19 July 2026 20:25 > To: Fundiswa Nadia Maseko > Cc: rpd at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > > Dear Fundiswa, > > ?Has the proposal demonstrated mandatory naming is the least restrictive > solution?" ? Yes, > > "Do you disagree that hierarchical naming authenticates object creation > rather than membership accuracy?" ? No. > > These are the specific answers requested. > If you still oppose this proposal, we ask that you engage these answers > first ? in particular the deployment-coordination asymmetry raised ? > instead of repeating the original objections without technical substances > > ________________________________ > > 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 > > On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: > Dear Ben, > > Thank you for your response. > > Respectfully, I believe it is more productive to address the arguments > themselves than to make assumptions about the people presenting them or the > tools they may have used. > > If you believe the objections are technically incorrect, I would > appreciate it if you could identify which specific points you disagree > with. For example, do you disagree that hierarchical naming authenticates > object creation rather than the accuracy of object membership? Or do you > believe the proposal has demonstrated that mandatory naming is the least > restrictive solution available? > > Those are technical questions that can be examined and debated. Dismissing > opposing views as "AI bots" does not, on its own, explain why the arguments > are wrong. > I believe the PDWG benefits most when participants engage with the > substance of each other's reasoning, regardless of how a contribution was > drafted. > > > Kind regards, > Fundiswa Nadia Maseko > > On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, > wrote: > Fundiswa, > But the AI bots opposing the AS-SET policy aren?t making technical > arguments. They are just regurgitating and re-using the same script. None > of them seem to know or care what an AS-SET is, or what network owners use > them for. > > Cheers, > Ben > Sent from my iPhone > > > On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko > wrote: > ? > > Dear PDWG, > > I have been following this discussion with interest, and I would like to > express my concern about the direction it has taken. > > The Policy Development Process should evaluate technical arguments on > their merits. Whether a participant drafted a message unaided, received > editorial assistance, or used modern writing tools does not determine > whether the reasoning is sound. Speculating about authorship instead of > addressing the substance risks distracting the Working Group from the > policy questions before it. > > I am also concerned by suggestions that contributions should be > disregarded simply because of assumptions about how they were written. If > there are factual or technical errors, they should be identified and > discussed. That is how consensus is strengthened. > > The questions raised by several participants remain legitimate subjects > for technical debate: whether the proposal has demonstrated operational > necessity, whether the proposed intervention is proportionate, and whether > less restrictive alternatives have been adequately considered. > > I therefore encourage all participants to continue engaging with the > substance of the proposal while maintaining the respectful and professional > standards expected within the PDWG. > > Kind regards, > > Fundiswa Nadia Maseko > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd< > https://lists.afrinic.net/mailman/listinfo/rpd> > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd< > https://lists.afrinic.net/mailman/listinfo/rpd> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260719/f1cb5a98/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 71 > ************************************ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 219280444 at mycput.ac.za Sun Jul 19 19:00:10 2026 From: 219280444 at mycput.ac.za (Thulisile Mazomba) Date: Sun, 19 Jul 2026 19:00:10 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) In-Reply-To: <0B9F65CE-7417-4996-84C6-7E395FB27544@hevis.co.za> References: <0B9F65CE-7417-4996-84C6-7E395FB27544@hevis.co.za> Message-ID: Dear Hendrik, We are talking about Internet policy in the digital era. The use of modern tools to help organise or improve a response does not make the participant artificial, nor does it invalidate the argument. AFRINIC itself is supporting technological evolution, including IPv6 adoption. Promoting digital transformation of infrastructure while at the same time using the adoption of new technology in participation as an excuse for exclusion would be incongruous. The right test is simple: Is the argument technically correct, relevant and coming from someone who stands behind it? Address the policy concerns rather than disqualifying participants for using tools. Best regards, Thulisile, Get Outlook for Android ________________________________ From: Hendrik Visage Sent: Sunday, 19 July 2026 20:04:03 To: Thulisile Mazomba <219280444 at mycput.ac.za> Cc: rpd at afrinic.net ; rpd-owner at afrinic.net ; nishal at controlfreak.co.za ; seun.ojedeji at gmail.com Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) Dear Thulisile, Why did you also use an AI to respond? Claude: `Yes ? and it's the same drafting pipeline again, now writing a defense of itself. That's the most interesting thing about this one: the thread has become recursive, and the message quotes my own analysis back while exhibiting the exact markers that analysis described.a ________________________________ 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 On 19 Jul 2026, at 19:39, Thulisile Mazomba wrote: Dear colleagues, This discussion has moved away from the proposal and toward questioning who is allowed to object. Whether someone operates an ASN, uses drafting assistance, is new to the list, or is unfamiliar to long-standing participants does not determine whether their argument is valid. The PDP should examine the substance of an objection, not attempt to infer authorship from writing style or rank participants according to reputation. Submitting text to another language model does not establish who wrote it, who contributed to it, or whether the person posting it agrees with it. A probability produced by Claude is not evidence of astroturfing. It is an automated opinion about prose. Hendrik?s own quoted analysis concedes the important point: the distinction between authenticating the creator of an AS-SET and validating its contents is a real objection that still requires an answer. That issue does not disappear because the wording appears polished. The request to identify which ASNs objectors ?represent? also misunderstands participation. I am not claiming to represent every African operator, nor should any individual participant make that claim without authority. I am participating in my own capacity. An ASN is not a voting credential, and operating one does not give its holder a larger mandate over the policy process. Frank?s road-rule analogy is also misplaced. Governments impose traffic laws through public authority and accept legal accountability for doing so. AFRINIC is a private registry operating a technical database. The existence of a working group does not turn that registry into a legislature or every preferred operational practice into the equivalent of public law. The question before us remains simple: does this proposal solve the specific harm claimed, and is mandatory registry enforcement the minimum necessary mechanism? Hierarchical naming may reduce future name collisions. That is a useful property. It does not validate the accuracy of AS-SET membership, prevent incorrect customer-cone data, or make generated filters trustworthy by itself. Those limitations should be assessed honestly rather than buried beneath accusations about who wrote which paragraph. If the co-chairs believe several objections raise the same substantive issue, they may group them as one issue. That is reasonable. But they should then determine whether the issue has been answered on its merits. They should not discount it because the participants are unfamiliar, share a view, use similar language, or may have used writing tools. Participation provides evidence, criticism, and warning. Familiarity does not create mandate. Reputation does not replace proof. A mailing list should not become a private club in which established names decide which speakers count. I remain opposed to the proposal and ask that the discussion return to the proposal?s technical scope, demonstrated benefit, limitations, and proportionality. Regards, Thulisile -------------- next part -------------- An HTML attachment was scrubbed... URL: From saul at enetworks.co.za Sun Jul 19 19:20:17 2026 From: saul at enetworks.co.za (Saul Stein) Date: Sun, 19 Jul 2026 19:20:17 +0000 Subject: [rpd] =?windows-1252?q?=5BLast_Call=5D_Draft_Policy_Proposal_=96_?= =?windows-1252?q?Hierarchical_Names_for_New_AS-SETs_=28AFPUB-2026-ASN-001?= =?windows-1252?q?-DRAFT02=29?= In-Reply-To: References: Message-ID: Hi you have now posted the email twice 7 minutes apart? From: Fundiswa Nadia Maseko Sent: Sunday, 19 July 2026 20:46 To: rpd at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Dear Hendrik, Saul, and colleagues, Thank you for your responses. I would also like to address the recurring comments about AI-generated contributions. Whether someone uses AI to improve grammar, structure, or clarity does not, in itself, determine whether their arguments are valid. AI only works with the information and instructions provided by the person using it. Many people use it as a writing assistant to communicate their ideas more clearly, just as others may ask a colleague to proofread or edit a draft before sending it. For that reason, I do not believe the discussion should focus on how a message was written, but rather on whether the technical reasoning is correct or incorrect. With regard to the proposal itself, I appreciate Hendrik's direct answers. However, simply answering "yes" or "no" does not, by itself, explain the technical reasoning behind those conclusions. It would be helpful to understand why the proposal is considered the least restrictive solution and how the identified operational benefits outweigh the additional policy requirements. That explanation would assist everyone in evaluating the proposal on its technical merits. I believe the PDWG is strongest when differing views are examined through technical discussion supported by evidence, rather than assumptions about who wrote a message or what tools they may have used. Kind regards, Fundiswa Nadia Maseko On Sun, 19 Jul 2026, 20:34 , > wrote: Send RPD mailing list submissions to rpd at afrinic.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.afrinic.net/mailman/listinfo/rpd or, via email, send a message with subject or body 'help' to rpd-request at afrinic.net You can reach the person managing the list at rpd-owner at afrinic.net When replying, please edit your Subject line so it is more specific than "Re: Contents of RPD digest..." Today's Topics: 1. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage) 2. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Saul Stein) ---------------------------------------------------------------------- Message: 1 Date: Sun, 19 Jul 2026 20:25:00 +0200 From: Hendrik Visage > To: Fundiswa Nadia Maseko > Cc: rpd at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: <24327C8E-E411-4D2F-BE55-F250691CD720 at hevis.co.za> Content-Type: text/plain; charset="utf-8"; Format="flowed" Dear Fundiswa, ?Has the proposal demonstrated mandatory naming is the least restrictive solution?" ? Yes, "Do you disagree that hierarchical naming authenticates object creation rather than membership accuracy?" ? No. These are the specific answers requested. If you still oppose this proposal, we ask that you engage these answers first ? in particular the deployment-coordination asymmetry raised ? instead of repeating the original objections without technical substances --- 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 On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: > Dear Ben, > > Thank you for your response. > > Respectfully, I believe it is more productive to address the arguments > themselves than to make assumptions about the people presenting them > or the > tools they may have used. > > If you believe the objections are technically incorrect, I would > appreciate > it if you could identify which specific points you disagree with. For > example, do you disagree that hierarchical naming authenticates object > creation rather than the accuracy of object membership? Or do you > believe > the proposal has demonstrated that mandatory naming is the least > restrictive solution available? > > Those are technical questions that can be examined and debated. > Dismissing > opposing views as "AI bots" does not, on its own, explain why the > arguments > are wrong. > I believe the PDWG benefits most when participants engage with the > substance of each other's reasoning, regardless of how a contribution > was > drafted. > > > Kind regards, > Fundiswa Nadia Maseko > > On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, > > > wrote: > >> Fundiswa, >> But the AI bots opposing the AS-SET policy aren?t making technical >> arguments. They are just regurgitating and re-using the same script. >> None >> of them seem to know or care what an AS-SET is, or what network >> owners use >> them for. >> >> Cheers, >> Ben >> Sent from my iPhone >> >> On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko >> > >> wrote: >> >> ? >> >> *Dear PDWG,* >> >> I have been following this discussion with interest, and I would like >> to >> express my concern about the direction it has taken. >> >> The Policy Development Process should evaluate technical arguments on >> their merits. Whether a participant drafted a message unaided, >> received >> editorial assistance, or used modern writing tools does not determine >> whether the reasoning is sound. Speculating about authorship instead >> of >> addressing the substance risks distracting the Working Group from the >> policy questions before it. >> >> I am also concerned by suggestions that contributions should be >> disregarded simply because of assumptions about how they were >> written. If >> there are factual or technical errors, they should be identified and >> discussed. That is how consensus is strengthened. >> >> The questions raised by several participants remain legitimate >> subjects >> for technical debate: whether the proposal has demonstrated >> operational >> necessity, whether the proposed intervention is proportionate, and >> whether >> less restrictive alternatives have been adequately considered. >> >> I therefore encourage all participants to continue engaging with the >> substance of the proposal while maintaining the respectful and >> professional >> standards expected within the PDWG. >> >> Kind regards, >> >> Fundiswa Nadia Maseko >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: > ------------------------------ Message: 2 Date: Sun, 19 Jul 2026 18:34:04 +0000 From: Saul Stein > To: Hendrik Visage >, Fundiswa Nadia Maseko > Cc: "rpd at afrinic.net" > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: > Content-Type: text/plain; charset="utf-8" Dear all, Well, I have just finished my popcorn? sadly there wasn?t enough to read the bombardment of emails, so I didn?t. What I did see though, was a number of non-original / cvopy and paste objections. Not only that, but more importantly, they do not raise any valid concerns about the proposal that has reached final call. So with that in mind, I fully support this proposal. I?d have to be part of a community group where you have to have a valid NIC to post? Regards Saul From: Hendrik Visage via RPD > Sent: Sunday, 19 July 2026 20:25 To: Fundiswa Nadia Maseko > Cc: rpd at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Dear Fundiswa, ?Has the proposal demonstrated mandatory naming is the least restrictive solution?" ? Yes, "Do you disagree that hierarchical naming authenticates object creation rather than membership accuracy?" ? No. These are the specific answers requested. If you still oppose this proposal, we ask that you engage these answers first ? in particular the deployment-coordination asymmetry raised ? instead of repeating the original objections without technical substances ________________________________ 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> On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: Dear Ben, Thank you for your response. Respectfully, I believe it is more productive to address the arguments themselves than to make assumptions about the people presenting them or the tools they may have used. If you believe the objections are technically incorrect, I would appreciate it if you could identify which specific points you disagree with. For example, do you disagree that hierarchical naming authenticates object creation rather than the accuracy of object membership? Or do you believe the proposal has demonstrated that mandatory naming is the least restrictive solution available? Those are technical questions that can be examined and debated. Dismissing opposing views as "AI bots" does not, on its own, explain why the arguments are wrong. I believe the PDWG benefits most when participants engage with the substance of each other's reasoning, regardless of how a contribution was drafted. Kind regards, Fundiswa Nadia Maseko On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, >> wrote: Fundiswa, But the AI bots opposing the AS-SET policy aren?t making technical arguments. They are just regurgitating and re-using the same script. None of them seem to know or care what an AS-SET is, or what network owners use them for. Cheers, Ben Sent from my iPhone On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko >> wrote: ? Dear PDWG, I have been following this discussion with interest, and I would like to express my concern about the direction it has taken. The Policy Development Process should evaluate technical arguments on their merits. Whether a participant drafted a message unaided, received editorial assistance, or used modern writing tools does not determine whether the reasoning is sound. Speculating about authorship instead of addressing the substance risks distracting the Working Group from the policy questions before it. I am also concerned by suggestions that contributions should be disregarded simply because of assumptions about how they were written. If there are factual or technical errors, they should be identified and discussed. That is how consensus is strengthened. The questions raised by several participants remain legitimate subjects for technical debate: whether the proposal has demonstrated operational necessity, whether the proposed intervention is proportionate, and whether less restrictive alternatives have been adequately considered. I therefore encourage all participants to continue engaging with the substance of the proposal while maintaining the respectful and professional standards expected within the PDWG. Kind regards, Fundiswa Nadia Maseko _______________________________________________ RPD mailing list RPD at afrinic.net> https://lists.afrinic.net/mailman/listinfo/rpd> _______________________________________________ RPD mailing list RPD at afrinic.net> https://lists.afrinic.net/mailman/listinfo/rpd> -------------- next part -------------- An HTML attachment was scrubbed... URL: > ------------------------------ Subject: Digest Footer _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ End of RPD Digest, Vol 222, Issue 71 ************************************ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Sun Jul 19 19:28:38 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Sun, 19 Jul 2026 21:28:38 +0200 Subject: [rpd] =?utf-8?q?=5BLast_Call=5D_Draft_Policy_Proposal_=E2=80=93_H?= =?utf-8?q?ierarchical_Names_for_New_AS-SETs_=28AFPUB-2026-ASN-001-?= =?utf-8?q?DRAFT02=29?= In-Reply-To: References: Message-ID: Thank you for pointing that out. The two emails were intended for different purposes. The first was a direct response to Hendrik's points, while the second was addressed to the broader discussion, including your comments and the wider issue that had developed on the mailing list. I understand they were sent close together, which may have made them appear to be duplicates, but they were intended as separate responses. Kind regards, Fundiswa Nadia Maseko On Sun, 19 Jul 2026, 21:20 Saul Stein, wrote: > Hi > > you have now posted the email twice 7 minutes apart? > > > > > > *From:* Fundiswa Nadia Maseko > *Sent:* Sunday, 19 July 2026 20:46 > *To:* rpd at afrinic.net > *Subject:* Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > > > Dear Hendrik, Saul, and colleagues, > > > > Thank you for your responses. > > > > I would also like to address the recurring comments about AI-generated > contributions. > > > > Whether someone uses AI to improve grammar, structure, or clarity does > not, in itself, determine whether their arguments are valid. AI only works > with the information and instructions provided by the person using it. Many > people use it as a writing assistant to communicate their ideas more > clearly, just as others may ask a colleague to proofread or edit a draft > before sending it. > > > > For that reason, I do not believe the discussion should focus on how a > message was written, but rather on whether the technical reasoning is > correct or incorrect. > > > > With regard to the proposal itself, I appreciate Hendrik's direct answers. > However, simply answering "yes" or "no" does not, by itself, explain the > technical reasoning behind those conclusions. It would be helpful to > understand why the proposal is considered the least restrictive solution > and how the identified operational benefits outweigh the additional policy > requirements. That explanation would assist everyone in evaluating the > proposal on its technical merits. > > > > I believe the PDWG is strongest when differing views are examined through > technical discussion supported by evidence, rather than assumptions about > who wrote a message or what tools they may have used. > > > > Kind regards, > > > > Fundiswa Nadia Maseko > > > > > > On Sun, 19 Jul 2026, 20:34 , wrote: > > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage) > 2. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Saul Stein) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 19 Jul 2026 20:25:00 +0200 > From: Hendrik Visage > To: Fundiswa Nadia Maseko > Cc: rpd at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: <24327C8E-E411-4D2F-BE55-F250691CD720 at hevis.co.za> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Dear Fundiswa, > > ?Has the proposal demonstrated mandatory naming is the least > restrictive solution?" ? Yes, > > "Do you disagree that hierarchical naming authenticates object creation > rather than membership accuracy?" ? No. > > These are the specific answers requested. > If you still oppose this proposal, we ask that you engage these answers > first ? in particular the deployment-coordination asymmetry raised ? > instead of repeating the original objections without technical > substances > > --- > 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 > > On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: > > > Dear Ben, > > > > Thank you for your response. > > > > Respectfully, I believe it is more productive to address the arguments > > themselves than to make assumptions about the people presenting them > > or the > > tools they may have used. > > > > If you believe the objections are technically incorrect, I would > > appreciate > > it if you could identify which specific points you disagree with. For > > example, do you disagree that hierarchical naming authenticates object > > creation rather than the accuracy of object membership? Or do you > > believe > > the proposal has demonstrated that mandatory naming is the least > > restrictive solution available? > > > > Those are technical questions that can be examined and debated. > > Dismissing > > opposing views as "AI bots" does not, on its own, explain why the > > arguments > > are wrong. > > I believe the PDWG benefits most when participants engage with the > > substance of each other's reasoning, regardless of how a contribution > > was > > drafted. > > > > > > Kind regards, > > Fundiswa Nadia Maseko > > > > On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, > > > > wrote: > > > >> Fundiswa, > >> But the AI bots opposing the AS-SET policy aren?t making technical > >> arguments. They are just regurgitating and re-using the same script. > >> None > >> of them seem to know or care what an AS-SET is, or what network > >> owners use > >> them for. > >> > >> Cheers, > >> Ben > >> Sent from my iPhone > >> > >> On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko > >> > >> wrote: > >> > >> ? > >> > >> *Dear PDWG,* > >> > >> I have been following this discussion with interest, and I would like > >> to > >> express my concern about the direction it has taken. > >> > >> The Policy Development Process should evaluate technical arguments on > >> their merits. Whether a participant drafted a message unaided, > >> received > >> editorial assistance, or used modern writing tools does not determine > >> whether the reasoning is sound. Speculating about authorship instead > >> of > >> addressing the substance risks distracting the Working Group from the > >> policy questions before it. > >> > >> I am also concerned by suggestions that contributions should be > >> disregarded simply because of assumptions about how they were > >> written. If > >> there are factual or technical errors, they should be identified and > >> discussed. That is how consensus is strengthened. > >> > >> The questions raised by several participants remain legitimate > >> subjects > >> for technical debate: whether the proposal has demonstrated > >> operational > >> necessity, whether the proposed intervention is proportionate, and > >> whether > >> less restrictive alternatives have been adequately considered. > >> > >> I therefore encourage all participants to continue engaging with the > >> substance of the proposal while maintaining the respectful and > >> professional > >> standards expected within the PDWG. > >> > >> Kind regards, > >> > >> Fundiswa Nadia Maseko > >> > >> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> > >> > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260719/3805216e/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Sun, 19 Jul 2026 18:34:04 +0000 > From: Saul Stein > To: Hendrik Visage , Fundiswa Nadia Maseko > > Cc: "rpd at afrinic.net" > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > < > JNAP275MB125812327DC4FFF2404C216E8EC42 at JNAP275MB1258.ZAFP275.PROD.OUTLOOK.COM > > > > Content-Type: text/plain; charset="utf-8" > > Dear all, > Well, I have just finished my popcorn? sadly there wasn?t enough to read > the bombardment of emails, so I didn?t. > > What I did see though, was a number of non-original / cvopy and paste > objections. Not only that, but more importantly, they do not raise any > valid concerns about the proposal that has reached final call. > > So with that in mind, I fully support this proposal. > > I?d have to be part of a community group where you have to have a valid > NIC to post? > > Regards > Saul > > > From: Hendrik Visage via RPD > Sent: Sunday, 19 July 2026 20:25 > To: Fundiswa Nadia Maseko > Cc: rpd at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > > Dear Fundiswa, > > ?Has the proposal demonstrated mandatory naming is the least restrictive > solution?" ? Yes, > > "Do you disagree that hierarchical naming authenticates object creation > rather than membership accuracy?" ? No. > > These are the specific answers requested. > If you still oppose this proposal, we ask that you engage these answers > first ? in particular the deployment-coordination asymmetry raised ? > instead of repeating the original objections without technical substances > > ________________________________ > > 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 > > On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: > Dear Ben, > > Thank you for your response. > > Respectfully, I believe it is more productive to address the arguments > themselves than to make assumptions about the people presenting them or the > tools they may have used. > > If you believe the objections are technically incorrect, I would > appreciate it if you could identify which specific points you disagree > with. For example, do you disagree that hierarchical naming authenticates > object creation rather than the accuracy of object membership? Or do you > believe the proposal has demonstrated that mandatory naming is the least > restrictive solution available? > > Those are technical questions that can be examined and debated. Dismissing > opposing views as "AI bots" does not, on its own, explain why the arguments > are wrong. > I believe the PDWG benefits most when participants engage with the > substance of each other's reasoning, regardless of how a contribution was > drafted. > > > Kind regards, > Fundiswa Nadia Maseko > > On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, > wrote: > Fundiswa, > But the AI bots opposing the AS-SET policy aren?t making technical > arguments. They are just regurgitating and re-using the same script. None > of them seem to know or care what an AS-SET is, or what network owners use > them for. > > Cheers, > Ben > Sent from my iPhone > > > On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko > wrote: > ? > > Dear PDWG, > > I have been following this discussion with interest, and I would like to > express my concern about the direction it has taken. > > The Policy Development Process should evaluate technical arguments on > their merits. Whether a participant drafted a message unaided, received > editorial assistance, or used modern writing tools does not determine > whether the reasoning is sound. Speculating about authorship instead of > addressing the substance risks distracting the Working Group from the > policy questions before it. > > I am also concerned by suggestions that contributions should be > disregarded simply because of assumptions about how they were written. If > there are factual or technical errors, they should be identified and > discussed. That is how consensus is strengthened. > > The questions raised by several participants remain legitimate subjects > for technical debate: whether the proposal has demonstrated operational > necessity, whether the proposed intervention is proportionate, and whether > less restrictive alternatives have been adequately considered. > > I therefore encourage all participants to continue engaging with the > substance of the proposal while maintaining the respectful and professional > standards expected within the PDWG. > > Kind regards, > > Fundiswa Nadia Maseko > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd< > https://lists.afrinic.net/mailman/listinfo/rpd> > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd< > https://lists.afrinic.net/mailman/listinfo/rpd> > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260719/f1cb5a98/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 71 > ************************************ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From geier at geier.ne.tz Sun Jul 19 19:30:01 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Sun, 19 Jul 2026 22:30:01 +0300 Subject: [rpd] =?utf-8?q?=5BLast_Call=5D_Draft_Policy_Proposal_=E2=80=93_H?= =?utf-8?q?ierarchical_Names_for_New_AS-SETs_=28AFPUB-2026-ASN-001-DRAFT02?= =?utf-8?q?=29?= In-Reply-To: References: Message-ID: Hi, inline ... On 7/19/2026 7:55 PM, Fundiswa Nadia Maseko wrote: > *Dear PDWG,* > > I have been following this discussion with interest, and I would like to > express my concern about the direction it has taken. Sorry. I'm just trying to ppoint out that I don't consider some argument to be good arguments. > The Policy Development Process should evaluate technical arguments on > their merits. Honestly, I've seen a lot of claimed so-called "technical arguments". I haven't seen anything I would call technical arguments from the opponents of the policy. Can you give one using technical facts? [snip] > I am also concerned by suggestions that contributions should be > disregarded simply because of assumptions about how they were written. I'm assuming you refer to this: >> This also relates to the broader ?stability fallacy?: the assumption >> that more structure, more policy, or more institutional mechanisms >> necessarily create more stability. > > For those that understand what is proposed, we also understand that > this > creates more stability and it is not an assumption. > > Please don't assume that we are assuming. You see how this was not about "how they were written". It was about Gugu Dhlamini calling the argument for the policy an assumption, which is incorrect. It is very uncool to call a technical argument an assumption. It is also required then to call-out this incorrectness. And you mixing these up and misrepresenting is also not good. > If there are factual or technical errors, they should be identified and > discussed. That is how consensus is strengthened. you would have mentioned any factual or technical errors if you would have found one. You haven't. I just have to conclude you don't want to understand. But the policy process here should know that you didn't have any arguments. Regards, Frank again, all typed myself ;-) From gugudhlamini343 at gmail.com Sun Jul 19 19:37:18 2026 From: gugudhlamini343 at gmail.com (Gugu Dhlamini) Date: Sun, 19 Jul 2026 21:37:18 +0200 Subject: [rpd] =?utf-8?q?=5BLast_Call=5D_Draft_Policy_Proposal_=E2=80=93_H?= =?utf-8?q?ierarchical_Names_for_New_AS-SETs_=28AFPUB-2026-ASN-001-?= =?utf-8?q?DRAFT02=29?= In-Reply-To: References: Message-ID: Hi Saul, Yes, the message was sent twice. That is a posting mistake, not a policy argument. Focusing on duplicate delivery while ignoring the substance is exactly how process starts replacing discussion. Please address the objection itself rather than using a technical error as a reason to dismiss participation. Regards, Gugu On Sun, 19 Jul 2026, 9:29 pm Fundiswa Nadia Maseko wrote: > Thank you for pointing that out. > > The two emails were intended for different purposes. The first was a > direct response to Hendrik's points, while the second was addressed to the > broader discussion, including your comments and the wider issue that had > developed on the mailing list. > > I understand they were sent close together, which may have made them > appear to be duplicates, but they were intended as separate responses. > > Kind regards, > > Fundiswa Nadia Maseko > > > > On Sun, 19 Jul 2026, 21:20 Saul Stein, wrote: > >> Hi >> >> you have now posted the email twice 7 minutes apart? >> >> >> >> >> >> *From:* Fundiswa Nadia Maseko >> *Sent:* Sunday, 19 July 2026 20:46 >> *To:* rpd at afrinic.net >> *Subject:* Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> >> >> >> Dear Hendrik, Saul, and colleagues, >> >> >> >> Thank you for your responses. >> >> >> >> I would also like to address the recurring comments about AI-generated >> contributions. >> >> >> >> Whether someone uses AI to improve grammar, structure, or clarity does >> not, in itself, determine whether their arguments are valid. AI only works >> with the information and instructions provided by the person using it. Many >> people use it as a writing assistant to communicate their ideas more >> clearly, just as others may ask a colleague to proofread or edit a draft >> before sending it. >> >> >> >> For that reason, I do not believe the discussion should focus on how a >> message was written, but rather on whether the technical reasoning is >> correct or incorrect. >> >> >> >> With regard to the proposal itself, I appreciate Hendrik's direct >> answers. However, simply answering "yes" or "no" does not, by itself, >> explain the technical reasoning behind those conclusions. It would be >> helpful to understand why the proposal is considered the least restrictive >> solution and how the identified operational benefits outweigh the >> additional policy requirements. That explanation would assist everyone in >> evaluating the proposal on its technical merits. >> >> >> >> I believe the PDWG is strongest when differing views are examined through >> technical discussion supported by evidence, rather than assumptions about >> who wrote a message or what tools they may have used. >> >> >> >> Kind regards, >> >> >> >> Fundiswa Nadia Maseko >> >> >> >> >> >> On Sun, 19 Jul 2026, 20:34 , wrote: >> >> Send RPD mailing list submissions to >> rpd at afrinic.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.afrinic.net/mailman/listinfo/rpd >> or, via email, send a message with subject or body 'help' to >> rpd-request at afrinic.net >> >> You can reach the person managing the list at >> rpd-owner at afrinic.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of RPD digest..." >> >> >> Today's Topics: >> >> 1. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage) >> 2. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Saul Stein) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Sun, 19 Jul 2026 20:25:00 +0200 >> From: Hendrik Visage >> To: Fundiswa Nadia Maseko >> Cc: rpd at afrinic.net >> Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> Message-ID: <24327C8E-E411-4D2F-BE55-F250691CD720 at hevis.co.za> >> Content-Type: text/plain; charset="utf-8"; Format="flowed" >> >> Dear Fundiswa, >> >> ?Has the proposal demonstrated mandatory naming is the least >> restrictive solution?" ? Yes, >> >> "Do you disagree that hierarchical naming authenticates object creation >> rather than membership accuracy?" ? No. >> >> These are the specific answers requested. >> If you still oppose this proposal, we ask that you engage these answers >> first ? in particular the deployment-coordination asymmetry raised ? >> instead of repeating the original objections without technical >> substances >> >> --- >> 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 >> >> On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: >> >> > Dear Ben, >> > >> > Thank you for your response. >> > >> > Respectfully, I believe it is more productive to address the arguments >> > themselves than to make assumptions about the people presenting them >> > or the >> > tools they may have used. >> > >> > If you believe the objections are technically incorrect, I would >> > appreciate >> > it if you could identify which specific points you disagree with. For >> > example, do you disagree that hierarchical naming authenticates object >> > creation rather than the accuracy of object membership? Or do you >> > believe >> > the proposal has demonstrated that mandatory naming is the least >> > restrictive solution available? >> > >> > Those are technical questions that can be examined and debated. >> > Dismissing >> > opposing views as "AI bots" does not, on its own, explain why the >> > arguments >> > are wrong. >> > I believe the PDWG benefits most when participants engage with the >> > substance of each other's reasoning, regardless of how a contribution >> > was >> > drafted. >> > >> > >> > Kind regards, >> > Fundiswa Nadia Maseko >> > >> > On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, >> > >> > wrote: >> > >> >> Fundiswa, >> >> But the AI bots opposing the AS-SET policy aren?t making technical >> >> arguments. They are just regurgitating and re-using the same script. >> >> None >> >> of them seem to know or care what an AS-SET is, or what network >> >> owners use >> >> them for. >> >> >> >> Cheers, >> >> Ben >> >> Sent from my iPhone >> >> >> >> On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko >> >> >> >> wrote: >> >> >> >> ? >> >> >> >> *Dear PDWG,* >> >> >> >> I have been following this discussion with interest, and I would like >> >> to >> >> express my concern about the direction it has taken. >> >> >> >> The Policy Development Process should evaluate technical arguments on >> >> their merits. Whether a participant drafted a message unaided, >> >> received >> >> editorial assistance, or used modern writing tools does not determine >> >> whether the reasoning is sound. Speculating about authorship instead >> >> of >> >> addressing the substance risks distracting the Working Group from the >> >> policy questions before it. >> >> >> >> I am also concerned by suggestions that contributions should be >> >> disregarded simply because of assumptions about how they were >> >> written. If >> >> there are factual or technical errors, they should be identified and >> >> discussed. That is how consensus is strengthened. >> >> >> >> The questions raised by several participants remain legitimate >> >> subjects >> >> for technical debate: whether the proposal has demonstrated >> >> operational >> >> necessity, whether the proposed intervention is proportionate, and >> >> whether >> >> less restrictive alternatives have been adequately considered. >> >> >> >> I therefore encourage all participants to continue engaging with the >> >> substance of the proposal while maintaining the respectful and >> >> professional >> >> standards expected within the PDWG. >> >> >> >> Kind regards, >> >> >> >> Fundiswa Nadia Maseko >> >> >> >> >> >> _______________________________________________ >> >> RPD mailing list >> >> RPD at afrinic.net >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> >> >> > _______________________________________________ >> > RPD mailing list >> > RPD at afrinic.net >> > https://lists.afrinic.net/mailman/listinfo/rpd >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> https://lists.afrinic.net/pipermail/rpd/attachments/20260719/3805216e/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 2 >> Date: Sun, 19 Jul 2026 18:34:04 +0000 >> From: Saul Stein >> To: Hendrik Visage , Fundiswa Nadia Maseko >> >> Cc: "rpd at afrinic.net" >> Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> Message-ID: >> < >> JNAP275MB125812327DC4FFF2404C216E8EC42 at JNAP275MB1258.ZAFP275.PROD.OUTLOOK.COM >> > >> >> Content-Type: text/plain; charset="utf-8" >> >> Dear all, >> Well, I have just finished my popcorn? sadly there wasn?t enough to read >> the bombardment of emails, so I didn?t. >> >> What I did see though, was a number of non-original / cvopy and paste >> objections. Not only that, but more importantly, they do not raise any >> valid concerns about the proposal that has reached final call. >> >> So with that in mind, I fully support this proposal. >> >> I?d have to be part of a community group where you have to have a valid >> NIC to post? >> >> Regards >> Saul >> >> >> From: Hendrik Visage via RPD >> Sent: Sunday, 19 July 2026 20:25 >> To: Fundiswa Nadia Maseko >> Cc: rpd at afrinic.net >> Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> >> >> Dear Fundiswa, >> >> ?Has the proposal demonstrated mandatory naming is the least restrictive >> solution?" ? Yes, >> >> "Do you disagree that hierarchical naming authenticates object creation >> rather than membership accuracy?" ? No. >> >> These are the specific answers requested. >> If you still oppose this proposal, we ask that you engage these answers >> first ? in particular the deployment-coordination asymmetry raised ? >> instead of repeating the original objections without technical substances >> >> ________________________________ >> >> 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 >> >> On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: >> Dear Ben, >> >> Thank you for your response. >> >> Respectfully, I believe it is more productive to address the arguments >> themselves than to make assumptions about the people presenting them or the >> tools they may have used. >> >> If you believe the objections are technically incorrect, I would >> appreciate it if you could identify which specific points you disagree >> with. For example, do you disagree that hierarchical naming authenticates >> object creation rather than the accuracy of object membership? Or do you >> believe the proposal has demonstrated that mandatory naming is the least >> restrictive solution available? >> >> Those are technical questions that can be examined and debated. >> Dismissing opposing views as "AI bots" does not, on its own, explain why >> the arguments are wrong. >> I believe the PDWG benefits most when participants engage with the >> substance of each other's reasoning, regardless of how a contribution was >> drafted. >> >> >> Kind regards, >> Fundiswa Nadia Maseko >> >> On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, < >> ben.roberts at afrinic.net> wrote: >> Fundiswa, >> But the AI bots opposing the AS-SET policy aren?t making technical >> arguments. They are just regurgitating and re-using the same script. None >> of them seem to know or care what an AS-SET is, or what network owners use >> them for. >> >> Cheers, >> Ben >> Sent from my iPhone >> >> >> On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko > > wrote: >> ? >> >> Dear PDWG, >> >> I have been following this discussion with interest, and I would like to >> express my concern about the direction it has taken. >> >> The Policy Development Process should evaluate technical arguments on >> their merits. Whether a participant drafted a message unaided, received >> editorial assistance, or used modern writing tools does not determine >> whether the reasoning is sound. Speculating about authorship instead of >> addressing the substance risks distracting the Working Group from the >> policy questions before it. >> >> I am also concerned by suggestions that contributions should be >> disregarded simply because of assumptions about how they were written. If >> there are factual or technical errors, they should be identified and >> discussed. That is how consensus is strengthened. >> >> The questions raised by several participants remain legitimate subjects >> for technical debate: whether the proposal has demonstrated operational >> necessity, whether the proposed intervention is proportionate, and whether >> less restrictive alternatives have been adequately considered. >> >> I therefore encourage all participants to continue engaging with the >> substance of the proposal while maintaining the respectful and professional >> standards expected within the PDWG. >> >> Kind regards, >> >> Fundiswa Nadia Maseko >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd< >> https://lists.afrinic.net/mailman/listinfo/rpd> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd< >> https://lists.afrinic.net/mailman/listinfo/rpd> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> https://lists.afrinic.net/pipermail/rpd/attachments/20260719/f1cb5a98/attachment.html >> > >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ------------------------------ >> >> End of RPD Digest, Vol 222, Issue 71 >> ************************************ >> >> _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 219280444 at mycput.ac.za Sun Jul 19 20:07:17 2026 From: 219280444 at mycput.ac.za (Thulisile Mazomba) Date: Sun, 19 Jul 2026 20:07:17 +0000 Subject: [rpd] RPD Digest, Vol 222, Issue 69 In-Reply-To: References: Message-ID: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Hi Frank, You appear to be treating your disagreement with an objection as proof that no technical objection exists. The proposal prevents one naming collision. It does not establish the correctness of the routing data attached to that name, nor prove that mandatory registry control is the only proportionate remedy. Those are technical and policy questions. Declaring them invalid does not resolve them. I remain opposed. Regards, Thulisile ________________________________ From: rpd-request at afrinic.net Sent: Sunday, 19 July 2026 20:09 To: rpd at afrinic.net Subject: RPD Digest, Vol 222, Issue 69 Send RPD mailing list submissions to rpd at afrinic.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.afrinic.net/mailman/listinfo/rpd or, via email, send a message with subject or body 'help' to rpd-request at afrinic.net You can reach the person managing the list at rpd-owner at afrinic.net When replying, please edit your Subject line so it is more specific than "Re: Contents of RPD digest..." Today's Topics: 1. Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) (Hendrik Visage) 2. Re: RPD Digest, Vol 222, Issue 45 (Gugu Dhlamini) ---------------------------------------------------------------------- Message: 1 Date: Sun, 19 Jul 2026 20:04:03 +0200 From: Hendrik Visage To: Thulisile Mazomba <219280444 at mycput.ac.za> Cc: rpd-owner at afrinic.net, rpd at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) Message-ID: <0B9F65CE-7417-4996-84C6-7E395FB27544 at hevis.co.za> Content-Type: text/plain; charset="utf-8"; Format="flowed" Dear Thulisile, Why did you also use an AI to respond? Claude: `Yes ? and it's the same drafting pipeline again, now writing a defense of itself. That's the most interesting thing about this one: the thread has become recursive, and the message quotes my own analysis back while exhibiting the exact markers that analysis described.a --- 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 On 19 Jul 2026, at 19:39, Thulisile Mazomba wrote: > Dear colleagues, > > This discussion has moved away from the proposal and toward > questioning who is allowed to object. > > Whether someone operates an ASN, uses drafting assistance, is new to > the list, or is unfamiliar to long-standing participants does not > determine whether their argument is valid. The PDP should examine the > substance of an objection, not attempt to infer authorship from > writing style or rank participants according to reputation. > > Submitting text to another language model does not establish who wrote > it, who contributed to it, or whether the person posting it agrees > with it. A probability produced by Claude is not evidence of > astroturfing. It is an automated opinion about prose. > > Hendrik?s own quoted analysis concedes the important point: the > distinction between authenticating the creator of an AS-SET and > validating its contents is a real objection that still requires an > answer. That issue does not disappear because the wording appears > polished. > > The request to identify which ASNs objectors ?represent? also > misunderstands participation. I am not claiming to represent every > African operator, nor should any individual participant make that > claim without authority. I am participating in my own capacity. An ASN > is not a voting credential, and operating one does not give its holder > a larger mandate over the policy process. > > Frank?s road-rule analogy is also misplaced. Governments impose > traffic laws through public authority and accept legal accountability > for doing so. AFRINIC is a private registry operating a technical > database. The existence of a working group does not turn that registry > into a legislature or every preferred operational practice into the > equivalent of public law. > > The question before us remains simple: does this proposal solve the > specific harm claimed, and is mandatory registry enforcement the > minimum necessary mechanism? > > Hierarchical naming may reduce future name collisions. That is a > useful property. It does not validate the accuracy of AS-SET > membership, prevent incorrect customer-cone data, or make generated > filters trustworthy by itself. Those limitations should be assessed > honestly rather than buried beneath accusations about who wrote which > paragraph. > > If the co-chairs believe several objections raise the same substantive > issue, they may group them as one issue. That is reasonable. But they > should then determine whether the issue has been answered on its > merits. They should not discount it because the participants are > unfamiliar, share a view, use similar language, or may have used > writing tools. > > Participation provides evidence, criticism, and warning. Familiarity > does not create mandate. Reputation does not replace proof. A mailing > list should not become a private club in which established names > decide which speakers count. > > I remain opposed to the proposal and ask that the discussion return to > the proposal?s technical scope, demonstrated benefit, limitations, > and proportionality. > > Regards, > Thulisile -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Sun, 19 Jul 2026 20:09:25 +0200 From: Gugu Dhlamini To: Frank Habicht , rpd-owner at afrinic.net Cc: rpd at afrinic.net Subject: Re: [rpd] RPD Digest, Vol 222, Issue 45 Message-ID: Content-Type: text/plain; charset="utf-8" Dear Frank, A problem statement establishes that a concern exists. It does not establish that this proposal is necessary, proportionate, or the only valid remedy. Questioning and asking that contributions be disregarded because their wording appears similar is not consensus assessment. It is #Gatekeeping. Participation may provide evidence and objection; familiarity and style do not create or remove mandate. Please answer the unresolved policy concern rather than analyse the people raising it. I remain opposed. Regards, Gugu On Sun, 19 Jul 2026, 3:00 pm Frank Habicht wrote: > Hi, > > inline... > > On 7/18/2026 10:49 PM, Nia Petronella wrote: > > Dear PDWG, > > > > I agree with Asamkele, Gugu, and Tshepo, and I remain opposed to this > > proposal. > > > > Responding to objectors one by one does not resolve the common concern > > they have raised. A collision between AS-SET labels is not a failure of > > ASN or prefix uniqueness, > > It is a failure of AS-SET uniqueness. > Which are not among the famous 3 INR that AfriNIC primarily deals with. > But they are important objects in the IRR. Which AfriNIC operates. And > thus AfriNIC should set the policies under which it operates the IRR. > > > and repeating that characterization does not > > make it technically correct. > > Maybe my above statement is not a repetition, and could be technically > correct? > > > The proposal still has not demonstrated measurable operational harm, > > Would it be better if someone would have added this to the proposal: > "" MANRS documented the incident with AS-AMAZON back in 2022, > > https://manrs.org/2022/12/why-network-operators-should-use-hierarchical-as-sets/. > > At the time of writing Google's official source for their AS-SET is RADB > as documented in their PeeringDB entry > https://www.peeringdb.com/net/433, but AS-GOOGLE currently exists as an > empty AS-SET in the RIPE DB > > https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=AS-GOOGLE&type=as-set. > > "" > > Would you then agree that the proposal demonstrated harm? > > Just because you didn't see it doesn't mean there was no harm. > > > > why > > voluntary hierarchical naming is insufficient, > > the author posted on this mailing list the number of collisions that exist. > > > or why mandatory registry > > intervention is the least restrictive solution. > > This is where you can propose a less restrictive solution. > > > Adoption by other RIRs > > is relevant, but institutional uniformity is not proof of technical > > necessity. > > Harm that was documented is the proof of technical necessity. > > > A policy process should examine objections on their merits, not treat > > repeated disagreement as something to be individually overcome. > > Thanks. Was the AI asked to produce a certain quantity of text, so that > this blah had to be included? > > > The > > registry should support accurate routing information without converting > > every preferred convention into compulsory policy. > > Now, I have a question. > > If "the registry" (AfriNIC) gets this information: > > as-set: AS-GOOGLE > tech-c: AS156-AFRINIC > admin-c: AS156-AFRINIC > mnt-by: google_kenya > source: AFRINIC # Filtered > descr: AS-GOOGLE > > > and another registry (RADB) has this information: > > as-set: AS-GOOGLE > descr: Google > members: AS11344 > members: AS13949 > members: AS15169 > members: AS15276 > members: AS19425 > members: AS22577 > members: AS26910 > members: AS36040 > members: AS36384 > members: AS36492 > members: AS36561 > members: AS394725 > members: AS40873 > members: AS41264 > members: AS43515 > members: AS55023 > members: AS6432 > members: AS19527 > members: AS26684 > members: AS395973 > members: AS36039 > members: AS24424 > members: AS396982 > members: AS139070 > members: AS139190 > members: AS394699 > members: AS-GOOGLE-IT > members: AS-MEEBO > members: AS-METAWEB-2 > members: AS32381 > members: AS36383 > members: AS36411 > members: AS36520 > members: AS394089 > mnt-by: MAINT-AS15169 > changed: arturolev at google.com 20231030 #16:36:58Z > source: RADB > last-modified: 2023-11-13T16:19:21Z > > then what should the person or the software generating a prefix-filter do? > > Awaiting this answer. > > It's important. Because this is what this discussion is about. Any > indication that the opponents have understood this will be welcome. > > Frank Habicht > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ End of RPD Digest, Vol 222, Issue 69 ************************************ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Zimkhitha.Mguqulwa at dlrrd.gov.za Sun Jul 19 20:28:40 2026 From: Zimkhitha.Mguqulwa at dlrrd.gov.za (Zimkhitha Mguqulwa) Date: Sun, 19 Jul 2026 20:28:40 +0000 Subject: [rpd] RPD Digest, Vol 222, Issue 77 In-Reply-To: References: Message-ID: Good day to everyone, As I'm going through the discussions from today I have a few questions that come to mind, and I would appreciate some clarification. 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? 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? 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. Regards Z -----Original Message----- From: rpd-request at afrinic.net Sent: 19 July 2026 22:08 To: rpd at afrinic.net Subject: RPD Digest, Vol 222, Issue 77 [You don't often get email from rpd-request at afrinic.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Send RPD mailing list submissions to rpd at afrinic.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.afrinic.net/mailman/listinfo/rpd or, via email, send a message with subject or body 'help' to rpd-request at afrinic.net You can reach the person managing the list at rpd-owner at afrinic.net When replying, please edit your Subject line so it is more specific than "Re: Contents of RPD digest..." Today's Topics: 1. Re: RPD Digest, Vol 222, Issue 69 (Thulisile Mazomba) ---------------------------------------------------------------------- Message: 1 Date: Sun, 19 Jul 2026 20:07:17 +0000 From: Thulisile Mazomba <219280444 at mycput.ac.za> To: "rpd at afrinic.net" Cc: "rpd-owner at afrinic.ne" Subject: Re: [rpd] RPD Digest, Vol 222, Issue 69 Message-ID: Content-Type: text/plain; charset="us-ascii" Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Hi Frank, You appear to be treating your disagreement with an objection as proof that no technical objection exists. The proposal prevents one naming collision. It does not establish the correctness of the routing data attached to that name, nor prove that mandatory registry control is the only proportionate remedy. Those are technical and policy questions. Declaring them invalid does not resolve them. I remain opposed. Regards, Thulisile ________________________________ From: rpd-request at afrinic.net Sent: Sunday, 19 July 2026 20:09 To: rpd at afrinic.net Subject: RPD Digest, Vol 222, Issue 69 Send RPD mailing list submissions to rpd at afrinic.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.afrinic.net/mailman/listinfo/rpd or, via email, send a message with subject or body 'help' to rpd-request at afrinic.net You can reach the person managing the list at rpd-owner at afrinic.net When replying, please edit your Subject line so it is more specific than "Re: Contents of RPD digest..." Today's Topics: 1. Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) (Hendrik Visage) 2. Re: RPD Digest, Vol 222, Issue 45 (Gugu Dhlamini) ---------------------------------------------------------------------- Message: 1 Date: Sun, 19 Jul 2026 20:04:03 +0200 From: Hendrik Visage To: Thulisile Mazomba <219280444 at mycput.ac.za> Cc: rpd-owner at afrinic.net, rpd at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) Message-ID: <0B9F65CE-7417-4996-84C6-7E395FB27544 at hevis.co.za> Content-Type: text/plain; charset="utf-8"; Format="flowed" Dear Thulisile, Why did you also use an AI to respond? Claude: `Yes ? and it's the same drafting pipeline again, now writing a defense of itself. That's the most interesting thing about this one: the thread has become recursive, and the message quotes my own analysis back while exhibiting the exact markers that analysis described.a --- 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 On 19 Jul 2026, at 19:39, Thulisile Mazomba wrote: > Dear colleagues, > > This discussion has moved away from the proposal and toward > questioning who is allowed to object. > > Whether someone operates an ASN, uses drafting assistance, is new to > the list, or is unfamiliar to long-standing participants does not > determine whether their argument is valid. The PDP should examine the > substance of an objection, not attempt to infer authorship from > writing style or rank participants according to reputation. > > Submitting text to another language model does not establish who wrote > it, who contributed to it, or whether the person posting it agrees > with it. A probability produced by Claude is not evidence of > astroturfing. It is an automated opinion about prose. > > Hendrik?s own quoted analysis concedes the important point: the > distinction between authenticating the creator of an AS-SET and > validating its contents is a real objection that still requires an > answer. That issue does not disappear because the wording appears > polished. > > The request to identify which ASNs objectors ?represent? also > misunderstands participation. I am not claiming to represent every > African operator, nor should any individual participant make that > claim without authority. I am participating in my own capacity. An ASN > is not a voting credential, and operating one does not give its holder > a larger mandate over the policy process. > > Frank?s road-rule analogy is also misplaced. Governments impose > traffic laws through public authority and accept legal accountability > for doing so. AFRINIC is a private registry operating a technical > database. The existence of a working group does not turn that registry > into a legislature or every preferred operational practice into the > equivalent of public law. > > The question before us remains simple: does this proposal solve the > specific harm claimed, and is mandatory registry enforcement the > minimum necessary mechanism? > > Hierarchical naming may reduce future name collisions. That is a > useful property. It does not validate the accuracy of AS-SET > membership, prevent incorrect customer-cone data, or make generated > filters trustworthy by itself. Those limitations should be assessed > honestly rather than buried beneath accusations about who wrote which > paragraph. > > If the co-chairs believe several objections raise the same substantive > issue, they may group them as one issue. That is reasonable. But they > should then determine whether the issue has been answered on its > merits. They should not discount it because the participants are > unfamiliar, share a view, use similar language, or may have used > writing tools. > > Participation provides evidence, criticism, and warning. Familiarity > does not create mandate. Reputation does not replace proof. A mailing > list should not become a private club in which established names > decide which speakers count. > > I remain opposed to the proposal and ask that the discussion return to > the proposal?s technical scope, demonstrated benefit, limitations, and > proportionality. > > Regards, > Thulisile -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Sun, 19 Jul 2026 20:09:25 +0200 From: Gugu Dhlamini To: Frank Habicht , rpd-owner at afrinic.net Cc: rpd at afrinic.net Subject: Re: [rpd] RPD Digest, Vol 222, Issue 45 Message-ID: Content-Type: text/plain; charset="utf-8" Dear Frank, A problem statement establishes that a concern exists. It does not establish that this proposal is necessary, proportionate, or the only valid remedy. Questioning and asking that contributions be disregarded because their wording appears similar is not consensus assessment. It is #Gatekeeping. Participation may provide evidence and objection; familiarity and style do not create or remove mandate. Please answer the unresolved policy concern rather than analyse the people raising it. I remain opposed. Regards, Gugu On Sun, 19 Jul 2026, 3:00 pm Frank Habicht wrote: > Hi, > > inline... > > On 7/18/2026 10:49 PM, Nia Petronella wrote: > > Dear PDWG, > > > > I agree with Asamkele, Gugu, and Tshepo, and I remain opposed to > > this proposal. > > > > Responding to objectors one by one does not resolve the common > > concern they have raised. A collision between AS-SET labels is not a > > failure of ASN or prefix uniqueness, > > It is a failure of AS-SET uniqueness. > Which are not among the famous 3 INR that AfriNIC primarily deals with. > But they are important objects in the IRR. Which AfriNIC operates. And > thus AfriNIC should set the policies under which it operates the IRR. > > > and repeating that characterization does not make it technically > > correct. > > Maybe my above statement is not a repetition, and could be technically > correct? > > > The proposal still has not demonstrated measurable operational harm, > > Would it be better if someone would have added this to the proposal: > "" MANRS documented the incident with AS-AMAZON back in 2022, > > https://manrs.org/2022/12/why-network-operators-should-use-hierarchical-as-sets/. > > At the time of writing Google's official source for their AS-SET is > RADB as documented in their PeeringDB entry > https://www/. > peeringdb.com%2Fnet%2F433&data=05%7C02%7Czimkhitha.mguqulwa%40dlrrd.go > v.za%7C076691813692477b975208dee5d176e0%7C1f792a3502a74e3e9e7aff40ae39 > 0cb6%7C0%7C0%7C639200885007490766%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1h > cGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIj > oyfQ%3D%3D%7C0%7C%7C%7C&sdata=n2R%2FsqlX%2FLV2jLmvrGOdYT5RrM8lAltO76e3 > FGJYEj4%3D&reserved=0, but AS-GOOGLE currently exists as an empty > AS-SET in the RIPE DB > > https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=AS-GOOGLE&type=as-set. > > "" > > Would you then agree that the proposal demonstrated harm? > > Just because you didn't see it doesn't mean there was no harm. > > > > why > > voluntary hierarchical naming is insufficient, > > the author posted on this mailing list the number of collisions that exist. > > > or why mandatory registry > > intervention is the least restrictive solution. > > This is where you can propose a less restrictive solution. > > > Adoption by other RIRs > > is relevant, but institutional uniformity is not proof of technical > > necessity. > > Harm that was documented is the proof of technical necessity. > > > A policy process should examine objections on their merits, not > > treat repeated disagreement as something to be individually overcome. > > Thanks. Was the AI asked to produce a certain quantity of text, so > that this blah had to be included? > > > The > > registry should support accurate routing information without > > converting every preferred convention into compulsory policy. > > Now, I have a question. > > If "the registry" (AfriNIC) gets this information: > > as-set: AS-GOOGLE > tech-c: AS156-AFRINIC > admin-c: AS156-AFRINIC > mnt-by: google_kenya > source: AFRINIC # Filtered > descr: AS-GOOGLE > > > and another registry (RADB) has this information: > > as-set: AS-GOOGLE > descr: Google > members: AS11344 > members: AS13949 > members: AS15169 > members: AS15276 > members: AS19425 > members: AS22577 > members: AS26910 > members: AS36040 > members: AS36384 > members: AS36492 > members: AS36561 > members: AS394725 > members: AS40873 > members: AS41264 > members: AS43515 > members: AS55023 > members: AS6432 > members: AS19527 > members: AS26684 > members: AS395973 > members: AS36039 > members: AS24424 > members: AS396982 > members: AS139070 > members: AS139190 > members: AS394699 > members: AS-GOOGLE-IT > members: AS-MEEBO > members: AS-METAWEB-2 > members: AS32381 > members: AS36383 > members: AS36411 > members: AS36520 > members: AS394089 > mnt-by: MAINT-AS15169 > changed: arturolev at google.com 20231030 #16:36:58Z > source: RADB > last-modified: 2023-11-13T16:19:21Z > > then what should the person or the software generating a prefix-filter do? > > Awaiting this answer. > > It's important. Because this is what this discussion is about. Any > indication that the opponents have understood this will be welcome. > > Frank Habicht > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://list/ > s.afrinic.net%2Fmailman%2Flistinfo%2Frpd&data=05%7C02%7Czimkhitha.mguq > ulwa%40dlrrd.gov.za%7C076691813692477b975208dee5d176e0%7C1f792a3502a74 > e3e9e7aff40ae390cb6%7C0%7C0%7C639200885007526282%7CUnknown%7CTWFpbGZsb > 3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjo > iTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=RmDDiZxKdY%2FAfCV3iBjO5DJ > benoVisv5lSTkc76SUG0%3D&reserved=0 > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ End of RPD Digest, Vol 222, Issue 69 ************************************ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ End of RPD Digest, Vol 222, Issue 77 ************************************ From 219280444 at mycput.ac.za Sun Jul 19 20:29:04 2026 From: 219280444 at mycput.ac.za (Thulisile Mazomba) Date: Sun, 19 Jul 2026 20:29:04 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: <2d4cf65e26634c56b9033ccd8a735e53GVXPR04MB1229100159AC12816C0BB263FD1C42@GVXPR04MB12291.eurprd04.prod.outlook.com> Hi Frank, You appear to be treating your disagreement with an objection as proof that no technical objection exists. The proposal prevents one naming collision. It does not establish the correctness of the routing data attached to that name, nor prove that mandatory registry control is the only proportionate remedy. Those are technical and policy questions. Declaring them invalid does not resolve them. I remain opposed. Regards, Thulisile ________________________________ From: rpd-request at afrinic.net Sent: Sunday, 19 July 2026 20:09 To: rpd at afrinic.net Subject: RPD Digest, Vol 222, Issue 69 Send RPD mailing list submissions to rpd at afrinic.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.afrinic.net/mailman/listinfo/rpd or, via email, send a message with subject or body 'help' to rpd-request at afrinic.net You can reach the person managing the list at rpd-owner at afrinic.net When replying, please edit your Subject line so it is more specific than "Re: Contents of RPD digest..." Today's Topics: 1. Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) (Hendrik Visage) 2. Re: RPD Digest, Vol 222, Issue 45 (Gugu Dhlamini) ---------------------------------------------------------------------- Message: 1 Date: Sun, 19 Jul 2026 20:04:03 +0200 From: Hendrik Visage To: Thulisile Mazomba <219280444 at mycput.ac.za> Cc: rpd-owner at afrinic.net, rpd at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) Message-ID: <0B9F65CE-7417-4996-84C6-7E395FB27544 at hevis.co.za> Content-Type: text/plain; charset="utf-8"; Format="flowed" Dear Thulisile, Why did you also use an AI to respond? Claude: `Yes ? and it's the same drafting pipeline again, now writing a defense of itself. That's the most interesting thing about this one: the thread has become recursive, and the message quotes my own analysis back while exhibiting the exact markers that analysis described.a --- 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 On 19 Jul 2026, at 19:39, Thulisile Mazomba wrote: > Dear colleagues, > > This discussion has moved away from the proposal and toward > questioning who is allowed to object. > > Whether someone operates an ASN, uses drafting assistance, is new to > the list, or is unfamiliar to long-standing participants does not > determine whether their argument is valid. The PDP should examine the > substance of an objection, not attempt to infer authorship from > writing style or rank participants according to reputation. > > Submitting text to another language model does not establish who wrote > it, who contributed to it, or whether the person posting it agrees > with it. A probability produced by Claude is not evidence of > astroturfing. It is an automated opinion about prose. > > Hendrik?s own quoted analysis concedes the important point: the > distinction between authenticating the creator of an AS-SET and > validating its contents is a real objection that still requires an > answer. That issue does not disappear because the wording appears > polished. > > The request to identify which ASNs objectors ?represent? also > misunderstands participation. I am not claiming to represent every > African operator, nor should any individual participant make that > claim without authority. I am participating in my own capacity. An ASN > is not a voting credential, and operating one does not give its holder > a larger mandate over the policy process. > > Frank?s road-rule analogy is also misplaced. Governments impose > traffic laws through public authority and accept legal accountability > for doing so. AFRINIC is a private registry operating a technical > database. The existence of a working group does not turn that registry > into a legislature or every preferred operational practice into the > equivalent of public law. > > The question before us remains simple: does this proposal solve the > specific harm claimed, and is mandatory registry enforcement the > minimum necessary mechanism? > > Hierarchical naming may reduce future name collisions. That is a > useful property. It does not validate the accuracy of AS-SET > membership, prevent incorrect customer-cone data, or make generated > filters trustworthy by itself. Those limitations should be assessed > honestly rather than buried beneath accusations about who wrote which > paragraph. > > If the co-chairs believe several objections raise the same substantive > issue, they may group them as one issue. That is reasonable. But they > should then determine whether the issue has been answered on its > merits. They should not discount it because the participants are > unfamiliar, share a view, use similar language, or may have used > writing tools. > > Participation provides evidence, criticism, and warning. Familiarity > does not create mandate. Reputation does not replace proof. A mailing > list should not become a private club in which established names > decide which speakers count. > > I remain opposed to the proposal and ask that the discussion return to > the proposal?s technical scope, demonstrated benefit, limitations, > and proportionality. > > Regards, > Thulisile -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Sun, 19 Jul 2026 20:09:25 +0200 From: Gugu Dhlamini To: Frank Habicht , rpd-owner at afrinic.net Cc: rpd at afrinic.net Subject: Re: [rpd] RPD Digest, Vol 222, Issue 45 Message-ID: Content-Type: text/plain; charset="utf-8" Dear Frank, A problem statement establishes that a concern exists. It does not establish that this proposal is necessary, proportionate, or the only valid remedy. Questioning and asking that contributions be disregarded because their wording appears similar is not consensus assessment. It is #Gatekeeping. Participation may provide evidence and objection; familiarity and style do not create or remove mandate. Please answer the unresolved policy concern rather than analyse the people raising it. I remain opposed. Regards, Gugu On Sun, 19 Jul 2026, 3:00 pm Frank Habicht wrote: > Hi, > > inline... > > On 7/18/2026 10:49 PM, Nia Petronella wrote: > > Dear PDWG, > > > > I agree with Asamkele, Gugu, and Tshepo, and I remain opposed to this > > proposal. > > > > Responding to objectors one by one does not resolve the common concern > > they have raised. A collision between AS-SET labels is not a failure of > > ASN or prefix uniqueness, > > It is a failure of AS-SET uniqueness. > Which are not among the famous 3 INR that AfriNIC primarily deals with. > But they are important objects in the IRR. Which AfriNIC operates. And > thus AfriNIC should set the policies under which it operates the IRR. > > > and repeating that characterization does not > > make it technically correct. > > Maybe my above statement is not a repetition, and could be technically > correct? > > > The proposal still has not demonstrated measurable operational harm, > > Would it be better if someone would have added this to the proposal: > "" MANRS documented the incident with AS-AMAZON back in 2022, > > https://manrs.org/2022/12/why-network-operators-should-use-hierarchical-as-sets/. > > At the time of writing Google's official source for their AS-SET is RADB > as documented in their PeeringDB entry > https://www.peeringdb.com/net/433, but AS-GOOGLE currently exists as an > empty AS-SET in the RIPE DB > > https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=AS-GOOGLE&type=as-set. > > "" > > Would you then agree that the proposal demonstrated harm? > > Just because you didn't see it doesn't mean there was no harm. > > > > why > > voluntary hierarchical naming is insufficient, > > the author posted on this mailing list the number of collisions that exist. > > > or why mandatory registry > > intervention is the least restrictive solution. > > This is where you can propose a less restrictive solution. > > > Adoption by other RIRs > > is relevant, but institutional uniformity is not proof of technical > > necessity. > > Harm that was documented is the proof of technical necessity. > > > A policy process should examine objections on their merits, not treat > > repeated disagreement as something to be individually overcome. > > Thanks. Was the AI asked to produce a certain quantity of text, so that > this blah had to be included? > > > The > > registry should support accurate routing information without converting > > every preferred convention into compulsory policy. > > Now, I have a question. > > If "the registry" (AfriNIC) gets this information: > > as-set: AS-GOOGLE > tech-c: AS156-AFRINIC > admin-c: AS156-AFRINIC > mnt-by: google_kenya > source: AFRINIC # Filtered > descr: AS-GOOGLE > > > and another registry (RADB) has this information: > > as-set: AS-GOOGLE > descr: Google > members: AS11344 > members: AS13949 > members: AS15169 > members: AS15276 > members: AS19425 > members: AS22577 > members: AS26910 > members: AS36040 > members: AS36384 > members: AS36492 > members: AS36561 > members: AS394725 > members: AS40873 > members: AS41264 > members: AS43515 > members: AS55023 > members: AS6432 > members: AS19527 > members: AS26684 > members: AS395973 > members: AS36039 > members: AS24424 > members: AS396982 > members: AS139070 > members: AS139190 > members: AS394699 > members: AS-GOOGLE-IT > members: AS-MEEBO > members: AS-METAWEB-2 > members: AS32381 > members: AS36383 > members: AS36411 > members: AS36520 > members: AS394089 > mnt-by: MAINT-AS15169 > changed: arturolev at google.com 20231030 #16:36:58Z > source: RADB > last-modified: 2023-11-13T16:19:21Z > > then what should the person or the software generating a prefix-filter do? > > Awaiting this answer. > > It's important. Because this is what this discussion is about. Any > indication that the opponents have understood this will be welcome. > > Frank Habicht > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ End of RPD Digest, Vol 222, Issue 69 ************************************ -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Sun Jul 19 21:17:17 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Sun, 19 Jul 2026 23:17:17 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 77 In-Reply-To: References: Message-ID: <823BB692-1C8B-4D02-8D09-87B2E247586A@hevis.co.za> 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: From fundiswanadia2 at gmail.com Sun Jul 19 22:17:18 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Mon, 20 Jul 2026 00:17:18 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 76 In-Reply-To: References: Message-ID: Dear Frank, Thank you for your response. I disagree with your conclusion that opponents have presented no technical arguments. Whether an argument is ultimately persuasive is different from whether it is technical. My point remains that hierarchical naming may reduce namespace collisions, but it does not verify that the contents of an AS-SET are accurate, current, or authorised. The correctness of generated filters still depends on the quality of the underlying registry data. That is a technical limitation of what the proposal can achieve. Likewise, the assertion that the proposal improves stability is a claim that should be supported by technical reasoning and operational evidence. Explaining what failures are prevented, what risks remain, and why this is the least restrictive solution would strengthen that case. My intention is not to dismiss the proposal, but to test whether it has been sufficiently justified. That is an important part of the policy development process. Reasonable people may disagree on the answers, but I do not believe that makes the questions themselves any less technical. Kind regards, Fundiswa Nadia Maseko On Sun, 19 Jul 2026, 21:38 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Frank Habicht) > 2. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Gugu Dhlamini) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 19 Jul 2026 22:30:01 +0300 > From: Frank Habicht > To: rpd at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi, > > inline ... > > On 7/19/2026 7:55 PM, Fundiswa Nadia Maseko wrote: > > *Dear PDWG,* > > > > I have been following this discussion with interest, and I would like to > > express my concern about the direction it has taken. > > Sorry. I'm just trying to ppoint out that I don't consider some argument > to be good arguments. > > > The Policy Development Process should evaluate technical arguments on > > their merits. > > Honestly, I've seen a lot of claimed so-called "technical arguments". I > haven't seen anything I would call technical arguments from the > opponents of the policy. Can you give one using technical facts? > > [snip] > > I am also concerned by suggestions that contributions should be > > disregarded simply because of assumptions about how they were written. > > I'm assuming you refer to this: > >> This also relates to the broader ?stability fallacy?: the assumption > >> that more structure, more policy, or more institutional mechanisms > >> necessarily create more stability. > > > > For those that understand what is proposed, we also understand that > > this > > creates more stability and it is not an assumption. > > > > Please don't assume that we are assuming. > > You see how this was not about "how they were written". It was about > Gugu Dhlamini calling the argument for the policy an assumption, which > is incorrect. > > It is very uncool to call a technical argument an assumption. > It is also required then to call-out this incorrectness. > And you mixing these up and misrepresenting is also not good. > > > > > If there are factual or technical errors, they should be identified and > > discussed. That is how consensus is strengthened. > > you would have mentioned any factual or technical errors if you would > have found one. You haven't. > > I just have to conclude you don't want to understand. > > But the policy process here should know that you didn't have any arguments. > > Regards, > Frank > again, all typed myself ;-) > > > > > ------------------------------ > > Message: 2 > Date: Sun, 19 Jul 2026 21:37:18 +0200 > From: Gugu Dhlamini > To: Fundiswa Nadia Maseko > Cc: rpd at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > w at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Saul, > > Yes, the message was sent twice. That is a posting mistake, not a policy > argument. > > Focusing on duplicate delivery while ignoring the substance is exactly how > process starts replacing discussion. Please address the objection itself > rather than using a technical error as a reason to dismiss participation. > > Regards, > Gugu > > On Sun, 19 Jul 2026, 9:29 pm Fundiswa Nadia Maseko < > fundiswanadia2 at gmail.com> > wrote: > > > Thank you for pointing that out. > > > > The two emails were intended for different purposes. The first was a > > direct response to Hendrik's points, while the second was addressed to > the > > broader discussion, including your comments and the wider issue that had > > developed on the mailing list. > > > > I understand they were sent close together, which may have made them > > appear to be duplicates, but they were intended as separate responses. > > > > Kind regards, > > > > Fundiswa Nadia Maseko > > > > > > > > On Sun, 19 Jul 2026, 21:20 Saul Stein, wrote: > > > >> Hi > >> > >> you have now posted the email twice 7 minutes apart? > >> > >> > >> > >> > >> > >> *From:* Fundiswa Nadia Maseko > >> *Sent:* Sunday, 19 July 2026 20:46 > >> *To:* rpd at afrinic.net > >> *Subject:* Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >> > >> > >> > >> Dear Hendrik, Saul, and colleagues, > >> > >> > >> > >> Thank you for your responses. > >> > >> > >> > >> I would also like to address the recurring comments about AI-generated > >> contributions. > >> > >> > >> > >> Whether someone uses AI to improve grammar, structure, or clarity does > >> not, in itself, determine whether their arguments are valid. AI only > works > >> with the information and instructions provided by the person using it. > Many > >> people use it as a writing assistant to communicate their ideas more > >> clearly, just as others may ask a colleague to proofread or edit a draft > >> before sending it. > >> > >> > >> > >> For that reason, I do not believe the discussion should focus on how a > >> message was written, but rather on whether the technical reasoning is > >> correct or incorrect. > >> > >> > >> > >> With regard to the proposal itself, I appreciate Hendrik's direct > >> answers. However, simply answering "yes" or "no" does not, by itself, > >> explain the technical reasoning behind those conclusions. It would be > >> helpful to understand why the proposal is considered the least > restrictive > >> solution and how the identified operational benefits outweigh the > >> additional policy requirements. That explanation would assist everyone > in > >> evaluating the proposal on its technical merits. > >> > >> > >> > >> I believe the PDWG is strongest when differing views are examined > through > >> technical discussion supported by evidence, rather than assumptions > about > >> who wrote a message or what tools they may have used. > >> > >> > >> > >> Kind regards, > >> > >> > >> > >> Fundiswa Nadia Maseko > >> > >> > >> > >> > >> > >> On Sun, 19 Jul 2026, 20:34 , wrote: > >> > >> Send RPD mailing list submissions to > >> rpd at afrinic.net > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> or, via email, send a message with subject or body 'help' to > >> rpd-request at afrinic.net > >> > >> You can reach the person managing the list at > >> rpd-owner at afrinic.net > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of RPD digest..." > >> > >> > >> Today's Topics: > >> > >> 1. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names > >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage) > >> 2. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names > >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Saul Stein) > >> > >> > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Sun, 19 Jul 2026 20:25:00 +0200 > >> From: Hendrik Visage > >> To: Fundiswa Nadia Maseko > >> Cc: rpd at afrinic.net > >> Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >> Message-ID: <24327C8E-E411-4D2F-BE55-F250691CD720 at hevis.co.za> > >> Content-Type: text/plain; charset="utf-8"; Format="flowed" > >> > >> Dear Fundiswa, > >> > >> ?Has the proposal demonstrated mandatory naming is the least > >> restrictive solution?" ? Yes, > >> > >> "Do you disagree that hierarchical naming authenticates object creation > >> rather than membership accuracy?" ? No. > >> > >> These are the specific answers requested. > >> If you still oppose this proposal, we ask that you engage these answers > >> first ? in particular the deployment-coordination asymmetry raised ? > >> instead of repeating the original objections without technical > >> substances > >> > >> --- > >> 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 > >> > >> On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: > >> > >> > Dear Ben, > >> > > >> > Thank you for your response. > >> > > >> > Respectfully, I believe it is more productive to address the arguments > >> > themselves than to make assumptions about the people presenting them > >> > or the > >> > tools they may have used. > >> > > >> > If you believe the objections are technically incorrect, I would > >> > appreciate > >> > it if you could identify which specific points you disagree with. For > >> > example, do you disagree that hierarchical naming authenticates object > >> > creation rather than the accuracy of object membership? Or do you > >> > believe > >> > the proposal has demonstrated that mandatory naming is the least > >> > restrictive solution available? > >> > > >> > Those are technical questions that can be examined and debated. > >> > Dismissing > >> > opposing views as "AI bots" does not, on its own, explain why the > >> > arguments > >> > are wrong. > >> > I believe the PDWG benefits most when participants engage with the > >> > substance of each other's reasoning, regardless of how a contribution > >> > was > >> > drafted. > >> > > >> > > >> > Kind regards, > >> > Fundiswa Nadia Maseko > >> > > >> > On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, > >> > > >> > wrote: > >> > > >> >> Fundiswa, > >> >> But the AI bots opposing the AS-SET policy aren?t making technical > >> >> arguments. They are just regurgitating and re-using the same script. > >> >> None > >> >> of them seem to know or care what an AS-SET is, or what network > >> >> owners use > >> >> them for. > >> >> > >> >> Cheers, > >> >> Ben > >> >> Sent from my iPhone > >> >> > >> >> On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko > >> >> > >> >> wrote: > >> >> > >> >> ? > >> >> > >> >> *Dear PDWG,* > >> >> > >> >> I have been following this discussion with interest, and I would like > >> >> to > >> >> express my concern about the direction it has taken. > >> >> > >> >> The Policy Development Process should evaluate technical arguments on > >> >> their merits. Whether a participant drafted a message unaided, > >> >> received > >> >> editorial assistance, or used modern writing tools does not determine > >> >> whether the reasoning is sound. Speculating about authorship instead > >> >> of > >> >> addressing the substance risks distracting the Working Group from the > >> >> policy questions before it. > >> >> > >> >> I am also concerned by suggestions that contributions should be > >> >> disregarded simply because of assumptions about how they were > >> >> written. If > >> >> there are factual or technical errors, they should be identified and > >> >> discussed. That is how consensus is strengthened. > >> >> > >> >> The questions raised by several participants remain legitimate > >> >> subjects > >> >> for technical debate: whether the proposal has demonstrated > >> >> operational > >> >> necessity, whether the proposed intervention is proportionate, and > >> >> whether > >> >> less restrictive alternatives have been adequately considered. > >> >> > >> >> I therefore encourage all participants to continue engaging with the > >> >> substance of the proposal while maintaining the respectful and > >> >> professional > >> >> standards expected within the PDWG. > >> >> > >> >> Kind regards, > >> >> > >> >> Fundiswa Nadia Maseko > >> >> > >> >> > >> >> _______________________________________________ > >> >> RPD mailing list > >> >> RPD at afrinic.net > >> >> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> > >> >> > >> > >> > _______________________________________________ > >> > RPD mailing list > >> > RPD at afrinic.net > >> > https://lists.afrinic.net/mailman/listinfo/rpd > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: < > >> > https://lists.afrinic.net/pipermail/rpd/attachments/20260719/3805216e/attachment-0001.html > >> > > >> > >> ------------------------------ > >> > >> Message: 2 > >> Date: Sun, 19 Jul 2026 18:34:04 +0000 > >> From: Saul Stein > >> To: Hendrik Visage , Fundiswa Nadia Maseko > >> > >> Cc: "rpd at afrinic.net" > >> Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >> Message-ID: > >> < > >> > JNAP275MB125812327DC4FFF2404C216E8EC42 at JNAP275MB1258.ZAFP275.PROD.OUTLOOK.COM > >> > > >> > >> Content-Type: text/plain; charset="utf-8" > >> > >> Dear all, > >> Well, I have just finished my popcorn? sadly there wasn?t enough to read > >> the bombardment of emails, so I didn?t. > >> > >> What I did see though, was a number of non-original / cvopy and paste > >> objections. Not only that, but more importantly, they do not raise any > >> valid concerns about the proposal that has reached final call. > >> > >> So with that in mind, I fully support this proposal. > >> > >> I?d have to be part of a community group where you have to have a valid > >> NIC to post? > >> > >> Regards > >> Saul > >> > >> > >> From: Hendrik Visage via RPD > >> Sent: Sunday, 19 July 2026 20:25 > >> To: Fundiswa Nadia Maseko > >> Cc: rpd at afrinic.net > >> Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > Names > >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >> > >> > >> Dear Fundiswa, > >> > >> ?Has the proposal demonstrated mandatory naming is the least restrictive > >> solution?" ? Yes, > >> > >> "Do you disagree that hierarchical naming authenticates object creation > >> rather than membership accuracy?" ? No. > >> > >> These are the specific answers requested. > >> If you still oppose this proposal, we ask that you engage these answers > >> first ? in particular the deployment-coordination asymmetry raised ? > >> instead of repeating the original objections without technical > substances > >> > >> ________________________________ > >> > >> 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 > >> > >> On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: > >> Dear Ben, > >> > >> Thank you for your response. > >> > >> Respectfully, I believe it is more productive to address the arguments > >> themselves than to make assumptions about the people presenting them or > the > >> tools they may have used. > >> > >> If you believe the objections are technically incorrect, I would > >> appreciate it if you could identify which specific points you disagree > >> with. For example, do you disagree that hierarchical naming > authenticates > >> object creation rather than the accuracy of object membership? Or do you > >> believe the proposal has demonstrated that mandatory naming is the least > >> restrictive solution available? > >> > >> Those are technical questions that can be examined and debated. > >> Dismissing opposing views as "AI bots" does not, on its own, explain why > >> the arguments are wrong. > >> I believe the PDWG benefits most when participants engage with the > >> substance of each other's reasoning, regardless of how a contribution > was > >> drafted. > >> > >> > >> Kind regards, > >> Fundiswa Nadia Maseko > >> > >> On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, < > >> ben.roberts at afrinic.net> wrote: > >> Fundiswa, > >> But the AI bots opposing the AS-SET policy aren?t making technical > >> arguments. They are just regurgitating and re-using the same script. > None > >> of them seem to know or care what an AS-SET is, or what network owners > use > >> them for. > >> > >> Cheers, > >> Ben > >> Sent from my iPhone > >> > >> > >> On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko < > fundiswanadia2 at gmail.com > >> > wrote: > >> ? > >> > >> Dear PDWG, > >> > >> I have been following this discussion with interest, and I would like to > >> express my concern about the direction it has taken. > >> > >> The Policy Development Process should evaluate technical arguments on > >> their merits. Whether a participant drafted a message unaided, received > >> editorial assistance, or used modern writing tools does not determine > >> whether the reasoning is sound. Speculating about authorship instead of > >> addressing the substance risks distracting the Working Group from the > >> policy questions before it. > >> > >> I am also concerned by suggestions that contributions should be > >> disregarded simply because of assumptions about how they were written. > If > >> there are factual or technical errors, they should be identified and > >> discussed. That is how consensus is strengthened. > >> > >> The questions raised by several participants remain legitimate subjects > >> for technical debate: whether the proposal has demonstrated operational > >> necessity, whether the proposed intervention is proportionate, and > whether > >> less restrictive alternatives have been adequately considered. > >> > >> I therefore encourage all participants to continue engaging with the > >> substance of the proposal while maintaining the respectful and > professional > >> standards expected within the PDWG. > >> > >> Kind regards, > >> > >> Fundiswa Nadia Maseko > >> > >> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd< > >> https://lists.afrinic.net/mailman/listinfo/rpd> > >> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd< > >> https://lists.afrinic.net/mailman/listinfo/rpd> > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: < > >> > https://lists.afrinic.net/pipermail/rpd/attachments/20260719/f1cb5a98/attachment.html > >> > > >> > >> ------------------------------ > >> > >> Subject: Digest Footer > >> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> > >> > >> ------------------------------ > >> > >> End of RPD Digest, Vol 222, Issue 71 > >> ************************************ > >> > >> _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260719/f73a0e8b/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 76 > ************************************ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From geier at geier.ne.tz Mon Jul 20 04:25:52 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Mon, 20 Jul 2026 07:25:52 +0300 Subject: [rpd] RPD Digest, Vol 222, Issue 76 In-Reply-To: References: Message-ID: Hi On 7/20/2026 1:17 AM, Fundiswa Nadia Maseko wrote: > I disagree with your conclusion that opponents have presented no > technical arguments. Please name one. Frank From geier at geier.ne.tz Mon Jul 20 04:36:00 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Mon, 20 Jul 2026 07:36:00 +0300 Subject: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <2d4cf65e26634c56b9033ccd8a735e53GVXPR04MB1229100159AC12816C0BB263FD1C42@GVXPR04MB12291.eurprd04.prod.outlook.com> References: <2d4cf65e26634c56b9033ccd8a735e53GVXPR04MB1229100159AC12816C0BB263FD1C42@GVXPR04MB12291.eurprd04.prod.outlook.com> Message-ID: <8b2ddf81-edd0-4c6a-97c3-46be5634ea04@geier.ne.tz> Hi, On 7/19/2026 11:29 PM, Thulisile Mazomba wrote: > > Hi Frank, > > You appear to be treating your disagreement with an objection as proof > that no technical objection exists. > > The proposal prevents one naming collision. It does not establish the > correctness of the routing data attached to that name, The proposal does not fix *all* problems. and it doesn't claim to do so. It creates an improvement. I don't agree that it is ok to object just because this proposal does not fix *all* problems. Do you agree it provides improvements? > nor prove that > mandatory registry control is the only proportionate remedy. it's not intended to prove that. > > Those are technical and policy questions. Declaring them invalid does > not resolve them. They are not good reasons against the proposal. But some people maybe want to be against the proposal first and then are looking for "questions". Frank From geier at geier.ne.tz Mon Jul 20 04:58:22 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Mon, 20 Jul 2026 07:58:22 +0300 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <24327C8E-E411-4D2F-BE55-F250691CD720@hevis.co.za> Message-ID: <3e091d61-af57-4543-bebf-402a7fbc937f@geier.ne.tz> Hi, inline... On 7/19/2026 9:38 PM, Fundiswa Nadia Maseko wrote: > Dear Hendrik, > > Thank you for taking the time to answer my questions. > > I think we actually agree on one important point: hierarchical naming > authenticates who creates the object, can we also agree that this is a good thing? > but it does not guarantee that the > contents of the object are accurate. I agree with that. Also, please note: noone claimed it does that. This proposal is not the perfect solution which guarantees accuracy. There are also many other problems this proposal does not solve..... > That was the distinction I was > trying to make. So the proposal is an improvement, right? So should we adopt it? Since AfriNIC does operate an IRR, do we want AfriNIC to do that in the best possible way? > Where we still differ is on whether that justifies making the naming > convention mandatory. I tried to explain with the AS-GOOGLE example - if we don't make it mandatory, collisions may be created. Actually by anyone in the world. > I understand your position that this is the > narrowest solution available, but I'm not yet convinced that less > restrictive alternatives have been ruled out. I don't think it's possible to prove to you that there are no less restrictive alternatives. But if there are, I think it's possible for you to show us. > I still think that point > deserves more discussion. And we should start to clarify where the "burden of proof" is ;-) > I also don't believe that the fact that other RIRs have adopted the same > approach automatically means AFRINIC must do so. It's useful context, > but I don't think it replaces the need to show why this is necessary for > our own policy process. About the necessity: Can we agree that collisions happen, that hey are bad, that they have let to operational problems? > I'm not trying to oppose operational improvements. I'm simply asking > whether a mandatory policy is the only way to achieve the intended > outcome. If we can find a better way, we can use it. If we can't find a better way, I think we should use this proposal. Isn't this how this choice should work? Regards, Frank From mselekuthandeka80 at gmail.com Mon Jul 20 06:06:34 2026 From: mselekuthandeka80 at gmail.com (Thandeka Mseleku) Date: Mon, 20 Jul 2026 08:06:34 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear colleagues, The discussion is now being diverted from the proposal into speculation about writing style, drafting tools, and who may have assisted whom. That is not a sound basis for policy assessment. An LLM?s opinion about whether a message resembles another message is not evidence of authorship, coordination, or astroturfing. It is merely another generated interpretation. Feeding text into Claude and quoting a probability back to the list does not establish who wrote the text, who agrees with it, or whether the argument is valid. Frank suggests that contributions should be disregarded because they refer to the burden of proof even though the proposal contains a problem statement. That is a misunderstanding. A problem statement identifies a concern. It does not automatically prove that the proposed remedy is necessary, sufficient, proportionate, or the least restrictive available response. Those are different questions. The proposal may accurately describe risks associated with flat AS-SET names. Objectors are still entitled to ask whether mandatory hierarchical naming addresses the full problem, whether the benefit has been measured, whether residual risks remain, and whether central enforcement is justified. The repeated focus on familiar wording also proves very little. Participants reading the same thread may naturally respond to the same claims. People may agree with one another. They may adopt terminology already introduced in the discussion. Similarity of argument is not proof of common authorship, just as familiarity of names is not proof of correctness. The proper response to repeated objections is simple: identify the common substantive issue and answer it once, clearly and completely. If the objection is that hierarchical naming authenticates the creator of an object but does not validate its contents, then address that distinction. If the objection concerns the scope of mandatory registry authority, explain why compulsion is indispensable. If the objection concerns proportionality, provide the evidence. Trying to disqualify the speakers does not answer the argument. Participation in the PDWG should not depend on being a recognised operator, representing an ASN, writing in an informal style, or avoiding editorial assistance. Participants contribute evidence, criticism, experience, and warning. They do not need permission from an established procedural class before their concerns may be considered. Nor should the PDP confuse process with mandate. A proposal does not become technically necessary merely because it has supporters, a problem statement, or precedent elsewhere. The process must still test the rule against operational reality. The registry should remain a narrow coordination layer. It may protect uniqueness, maintain accurate records, and support routing-related services. It should not acquire broader authority simply because objections are inconvenient or because regular participants prefer a particular convention. I therefore ask that the discussion return to the policy itself. The questions remain: What exact failure does the proposal prevent? What evidence shows the scale of that failure? What risks remain after hierarchical naming is imposed? Why are less restrictive technical mechanisms insufficient? How will success be measured? Until those questions are answered, dismissing objections because of writing style is not consensus-building. It is avoidance. Regards, Thandeka -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.schroder at gmail.com Mon Jul 20 06:49:53 2026 From: daniel.schroder at gmail.com (Daniel Schroder) Date: Mon, 20 Jul 2026 08:49:53 +0200 Subject: [rpd] =?utf-8?q?=5BLast_Call=5D_Draft_Policy_Proposal_=E2=80=93_H?= =?utf-8?q?ierarchical_Names_for_New_AS-SETs_=28AFPUB-2026-ASN-001-?= =?utf-8?q?DRAFT02=29?= In-Reply-To: References: Message-ID: Simple: The dog wanted a bone as usual. AI: As is customary, the canine harbored an insatiable desire for an osseous structure. Simple: Tom ordered pizza. AI: Thomas commissioned the preparation of an Italian flatbread adorned with melted cheese and savory toppings. Simple: We need one more document to complete your file. AI: Additional documentation is an absolute prerequisite to finalize your comprehensive dossier. If everyones is looking at their watches during a meeting, you missing the point which is getting to the point. Having language models influence input into policy changes from participants who rely on those LLMs for the simple objective of being heard or taken seriously is going to dissuade actual progress because there are other matters to attend to with policy being shifted to the backbench and your efforts effectively ignored, or your pearls lost in the mud. -daniel On Sun, Jul 19, 2026 at 9:38?PM Gugu Dhlamini wrote: > Hi Saul, > > Yes, the message was sent twice. That is a posting mistake, not a policy > argument. > > Focusing on duplicate delivery while ignoring the substance is exactly how > process starts replacing discussion. Please address the objection itself > rather than using a technical error as a reason to dismiss participation. > > Regards, > Gugu > > On Sun, 19 Jul 2026, 9:29 pm Fundiswa Nadia Maseko < > fundiswanadia2 at gmail.com> wrote: > >> Thank you for pointing that out. >> >> The two emails were intended for different purposes. The first was a >> direct response to Hendrik's points, while the second was addressed to the >> broader discussion, including your comments and the wider issue that had >> developed on the mailing list. >> >> I understand they were sent close together, which may have made them >> appear to be duplicates, but they were intended as separate responses. >> >> Kind regards, >> >> Fundiswa Nadia Maseko >> >> >> >> On Sun, 19 Jul 2026, 21:20 Saul Stein, wrote: >> >>> Hi >>> >>> you have now posted the email twice 7 minutes apart? >>> >>> >>> >>> >>> >>> *From:* Fundiswa Nadia Maseko >>> *Sent:* Sunday, 19 July 2026 20:46 >>> *To:* rpd at afrinic.net >>> *Subject:* Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>> >>> >>> >>> Dear Hendrik, Saul, and colleagues, >>> >>> >>> >>> Thank you for your responses. >>> >>> >>> >>> I would also like to address the recurring comments about AI-generated >>> contributions. >>> >>> >>> >>> Whether someone uses AI to improve grammar, structure, or clarity does >>> not, in itself, determine whether their arguments are valid. AI only works >>> with the information and instructions provided by the person using it. Many >>> people use it as a writing assistant to communicate their ideas more >>> clearly, just as others may ask a colleague to proofread or edit a draft >>> before sending it. >>> >>> >>> >>> For that reason, I do not believe the discussion should focus on how a >>> message was written, but rather on whether the technical reasoning is >>> correct or incorrect. >>> >>> >>> >>> With regard to the proposal itself, I appreciate Hendrik's direct >>> answers. However, simply answering "yes" or "no" does not, by itself, >>> explain the technical reasoning behind those conclusions. It would be >>> helpful to understand why the proposal is considered the least restrictive >>> solution and how the identified operational benefits outweigh the >>> additional policy requirements. That explanation would assist everyone in >>> evaluating the proposal on its technical merits. >>> >>> >>> >>> I believe the PDWG is strongest when differing views are examined >>> through technical discussion supported by evidence, rather than assumptions >>> about who wrote a message or what tools they may have used. >>> >>> >>> >>> Kind regards, >>> >>> >>> >>> Fundiswa Nadia Maseko >>> >>> >>> >>> >>> >>> On Sun, 19 Jul 2026, 20:34 , wrote: >>> >>> Send RPD mailing list submissions to >>> rpd at afrinic.net >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> or, via email, send a message with subject or body 'help' to >>> rpd-request at afrinic.net >>> >>> You can reach the person managing the list at >>> rpd-owner at afrinic.net >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of RPD digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage) >>> 2. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Saul Stein) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Sun, 19 Jul 2026 20:25:00 +0200 >>> From: Hendrik Visage >>> To: Fundiswa Nadia Maseko >>> Cc: rpd at afrinic.net >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>> Message-ID: <24327C8E-E411-4D2F-BE55-F250691CD720 at hevis.co.za> >>> Content-Type: text/plain; charset="utf-8"; Format="flowed" >>> >>> Dear Fundiswa, >>> >>> ?Has the proposal demonstrated mandatory naming is the least >>> restrictive solution?" ? Yes, >>> >>> "Do you disagree that hierarchical naming authenticates object creation >>> rather than membership accuracy?" ? No. >>> >>> These are the specific answers requested. >>> If you still oppose this proposal, we ask that you engage these answers >>> first ? in particular the deployment-coordination asymmetry raised ? >>> instead of repeating the original objections without technical >>> substances >>> >>> --- >>> 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 >>> >>> On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: >>> >>> > Dear Ben, >>> > >>> > Thank you for your response. >>> > >>> > Respectfully, I believe it is more productive to address the arguments >>> > themselves than to make assumptions about the people presenting them >>> > or the >>> > tools they may have used. >>> > >>> > If you believe the objections are technically incorrect, I would >>> > appreciate >>> > it if you could identify which specific points you disagree with. For >>> > example, do you disagree that hierarchical naming authenticates object >>> > creation rather than the accuracy of object membership? Or do you >>> > believe >>> > the proposal has demonstrated that mandatory naming is the least >>> > restrictive solution available? >>> > >>> > Those are technical questions that can be examined and debated. >>> > Dismissing >>> > opposing views as "AI bots" does not, on its own, explain why the >>> > arguments >>> > are wrong. >>> > I believe the PDWG benefits most when participants engage with the >>> > substance of each other's reasoning, regardless of how a contribution >>> > was >>> > drafted. >>> > >>> > >>> > Kind regards, >>> > Fundiswa Nadia Maseko >>> > >>> > On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, >>> > >>> > wrote: >>> > >>> >> Fundiswa, >>> >> But the AI bots opposing the AS-SET policy aren?t making technical >>> >> arguments. They are just regurgitating and re-using the same script. >>> >> None >>> >> of them seem to know or care what an AS-SET is, or what network >>> >> owners use >>> >> them for. >>> >> >>> >> Cheers, >>> >> Ben >>> >> Sent from my iPhone >>> >> >>> >> On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko >>> >> >>> >> wrote: >>> >> >>> >> ? >>> >> >>> >> *Dear PDWG,* >>> >> >>> >> I have been following this discussion with interest, and I would like >>> >> to >>> >> express my concern about the direction it has taken. >>> >> >>> >> The Policy Development Process should evaluate technical arguments on >>> >> their merits. Whether a participant drafted a message unaided, >>> >> received >>> >> editorial assistance, or used modern writing tools does not determine >>> >> whether the reasoning is sound. Speculating about authorship instead >>> >> of >>> >> addressing the substance risks distracting the Working Group from the >>> >> policy questions before it. >>> >> >>> >> I am also concerned by suggestions that contributions should be >>> >> disregarded simply because of assumptions about how they were >>> >> written. If >>> >> there are factual or technical errors, they should be identified and >>> >> discussed. That is how consensus is strengthened. >>> >> >>> >> The questions raised by several participants remain legitimate >>> >> subjects >>> >> for technical debate: whether the proposal has demonstrated >>> >> operational >>> >> necessity, whether the proposed intervention is proportionate, and >>> >> whether >>> >> less restrictive alternatives have been adequately considered. >>> >> >>> >> I therefore encourage all participants to continue engaging with the >>> >> substance of the proposal while maintaining the respectful and >>> >> professional >>> >> standards expected within the PDWG. >>> >> >>> >> Kind regards, >>> >> >>> >> Fundiswa Nadia Maseko >>> >> >>> >> >>> >> _______________________________________________ >>> >> RPD mailing list >>> >> RPD at afrinic.net >>> >> https://lists.afrinic.net/mailman/listinfo/rpd >>> >> >>> >> >>> >>> > _______________________________________________ >>> > RPD mailing list >>> > RPD at afrinic.net >>> > https://lists.afrinic.net/mailman/listinfo/rpd >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: < >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260719/3805216e/attachment-0001.html >>> > >>> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Sun, 19 Jul 2026 18:34:04 +0000 >>> From: Saul Stein >>> To: Hendrik Visage , Fundiswa Nadia Maseko >>> >>> Cc: "rpd at afrinic.net" >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>> Message-ID: >>> < >>> JNAP275MB125812327DC4FFF2404C216E8EC42 at JNAP275MB1258.ZAFP275.PROD.OUTLOOK.COM >>> > >>> >>> Content-Type: text/plain; charset="utf-8" >>> >>> Dear all, >>> Well, I have just finished my popcorn? sadly there wasn?t enough to read >>> the bombardment of emails, so I didn?t. >>> >>> What I did see though, was a number of non-original / cvopy and paste >>> objections. Not only that, but more importantly, they do not raise any >>> valid concerns about the proposal that has reached final call. >>> >>> So with that in mind, I fully support this proposal. >>> >>> I?d have to be part of a community group where you have to have a valid >>> NIC to post? >>> >>> Regards >>> Saul >>> >>> >>> From: Hendrik Visage via RPD >>> Sent: Sunday, 19 July 2026 20:25 >>> To: Fundiswa Nadia Maseko >>> Cc: rpd at afrinic.net >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>> >>> >>> Dear Fundiswa, >>> >>> ?Has the proposal demonstrated mandatory naming is the least restrictive >>> solution?" ? Yes, >>> >>> "Do you disagree that hierarchical naming authenticates object creation >>> rather than membership accuracy?" ? No. >>> >>> These are the specific answers requested. >>> If you still oppose this proposal, we ask that you engage these answers >>> first ? in particular the deployment-coordination asymmetry raised ? >>> instead of repeating the original objections without technical substances >>> >>> ________________________________ >>> >>> 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 >>> >>> On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: >>> Dear Ben, >>> >>> Thank you for your response. >>> >>> Respectfully, I believe it is more productive to address the arguments >>> themselves than to make assumptions about the people presenting them or the >>> tools they may have used. >>> >>> If you believe the objections are technically incorrect, I would >>> appreciate it if you could identify which specific points you disagree >>> with. For example, do you disagree that hierarchical naming authenticates >>> object creation rather than the accuracy of object membership? Or do you >>> believe the proposal has demonstrated that mandatory naming is the least >>> restrictive solution available? >>> >>> Those are technical questions that can be examined and debated. >>> Dismissing opposing views as "AI bots" does not, on its own, explain why >>> the arguments are wrong. >>> I believe the PDWG benefits most when participants engage with the >>> substance of each other's reasoning, regardless of how a contribution was >>> drafted. >>> >>> >>> Kind regards, >>> Fundiswa Nadia Maseko >>> >>> On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, < >>> ben.roberts at afrinic.net> wrote: >>> Fundiswa, >>> But the AI bots opposing the AS-SET policy aren?t making technical >>> arguments. They are just regurgitating and re-using the same script. None >>> of them seem to know or care what an AS-SET is, or what network owners use >>> them for. >>> >>> Cheers, >>> Ben >>> Sent from my iPhone >>> >>> >>> On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko < >>> fundiswanadia2 at gmail.com> wrote: >>> ? >>> >>> Dear PDWG, >>> >>> I have been following this discussion with interest, and I would like to >>> express my concern about the direction it has taken. >>> >>> The Policy Development Process should evaluate technical arguments on >>> their merits. Whether a participant drafted a message unaided, received >>> editorial assistance, or used modern writing tools does not determine >>> whether the reasoning is sound. Speculating about authorship instead of >>> addressing the substance risks distracting the Working Group from the >>> policy questions before it. >>> >>> I am also concerned by suggestions that contributions should be >>> disregarded simply because of assumptions about how they were written. If >>> there are factual or technical errors, they should be identified and >>> discussed. That is how consensus is strengthened. >>> >>> The questions raised by several participants remain legitimate subjects >>> for technical debate: whether the proposal has demonstrated operational >>> necessity, whether the proposed intervention is proportionate, and whether >>> less restrictive alternatives have been adequately considered. >>> >>> I therefore encourage all participants to continue engaging with the >>> substance of the proposal while maintaining the respectful and professional >>> standards expected within the PDWG. >>> >>> Kind regards, >>> >>> Fundiswa Nadia Maseko >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd< >>> https://lists.afrinic.net/mailman/listinfo/rpd> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd< >>> https://lists.afrinic.net/mailman/listinfo/rpd> >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: < >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260719/f1cb5a98/attachment.html >>> > >>> >>> ------------------------------ >>> >>> Subject: Digest Footer >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> >>> ------------------------------ >>> >>> End of RPD Digest, Vol 222, Issue 71 >>> ************************************ >>> >>> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 219280444 at mycput.ac.za Mon Jul 20 07:24:43 2026 From: 219280444 at mycput.ac.za (Thulisile Mazomba) Date: Mon, 20 Jul 2026 07:24:43 +0000 Subject: [rpd] Subject: Re: [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <8b2ddf81-edd0-4c6a-97c3-46be5634ea04@geier.ne.tz> References: <2d4cf65e26634c56b9033ccd8a735e53GVXPR04MB1229100159AC12816C0BB263FD1C42@GVXPR04MB12291.eurprd04.prod.outlook.com> <8b2ddf81-edd0-4c6a-97c3-46be5634ea04@geier.ne.tz> Message-ID: Hi Frank, An improvement is not automatically a justification for mandatory policy. The question is whether the benefit is significant enough, proven enough, and proportionate enough to place in the registry?s compulsory layer. Saying ?it helps? does not answer that. And no, raising those questions does not mean the objection came first. It means policy power should be tested before it is expanded. I remain opposed. Regards, Thulisile ________________________________ From: Frank Habicht Sent: Monday, 20 July 2026 06:36:00 To: Thulisile Mazomba <219280444 at mycput.ac.za>; rpd at afrinic.net Cc: rpd-owner at afrinic.ne Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Hi, On 7/19/2026 11:29 PM, Thulisile Mazomba wrote: > > Hi Frank, > > You appear to be treating your disagreement with an objection as proof > that no technical objection exists. > > The proposal prevents one naming collision. It does not establish the > correctness of the routing data attached to that name, The proposal does not fix *all* problems. and it doesn't claim to do so. It creates an improvement. I don't agree that it is ok to object just because this proposal does not fix *all* problems. Do you agree it provides improvements? > nor prove that > mandatory registry control is the only proportionate remedy. it's not intended to prove that. > > Those are technical and policy questions. Declaring them invalid does > not resolve them. They are not good reasons against the proposal. But some people maybe want to be against the proposal first and then are looking for "questions". Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Mon Jul 20 07:34:21 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Mon, 20 Jul 2026 07:34:21 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Hi Frank, You keep positioning yourself as the referee of which objections count. That is not your role. Participants are allowed to question whether a useful change belongs in mandatory policy. Dismissing those concerns instead of answering them turns discussion into gatekeeping. A policy room may debate. It does not grant any participant authority to police dissent. I remain opposed. Regards, Tshepo -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Mon Jul 20 07:37:42 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Mon, 20 Jul 2026 09:37:42 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 81 In-Reply-To: References: Message-ID: Dear PDWG, A pattern is becoming clear: familiar names are treated as authoritative, while newer participants are questioned, graded, or dismissed. That is gatekeeping, not consensus. An open process should test arguments, not reputations. Participation is evidence and objection; being well known does not create a mandate to decide whose voice counts. Regards, Nonhlanhla On Mon, 20 Jul 2026, 9:35 am wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Subject: Re: [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Thulisile > Mazomba) > 2. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Tshepo Masuku) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 20 Jul 2026 07:24:43 +0000 > From: Thulisile Mazomba <219280444 at mycput.ac.za> > To: Frank Habicht , "rpd at afrinic.net" > > Cc: "rpd-owner at afrinic.ne" > Subject: [rpd] Subject: Re: [Last Call] Draft Policy Proposal ? > Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > < > GVXPR04MB12291FB9551CD3D0ADB433FE6D1C32 at GVXPR04MB12291.eurprd04.prod.outlook.com > > > > Content-Type: text/plain; charset="windows-1252" > > Hi Frank, > > An improvement is not automatically a justification for mandatory policy. > > The question is whether the benefit is significant enough, proven enough, > and proportionate enough to place in the registry?s compulsory layer. > Saying ?it helps? does not answer that. > > And no, raising those questions does not mean the objection came first. It > means policy power should be tested before it is expanded. > > I remain opposed. > > Regards, > Thulisile > ________________________________ > From: Frank Habicht > Sent: Monday, 20 July 2026 06:36:00 > To: Thulisile Mazomba <219280444 at mycput.ac.za>; rpd at afrinic.net < > rpd at afrinic.net> > Cc: rpd-owner at afrinic.ne > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > Hi, > > On 7/19/2026 11:29 PM, Thulisile Mazomba wrote: > > > > Hi Frank, > > > > You appear to be treating your disagreement with an objection as proof > > that no technical objection exists. > > > > The proposal prevents one naming collision. It does not establish the > > correctness of the routing data attached to that name, > > The proposal does not fix *all* problems. and it doesn't claim to do so. > It creates an improvement. > I don't agree that it is ok to object just because this proposal does > not fix *all* problems. > > Do you agree it provides improvements? > > > nor prove that > > mandatory registry control is the only proportionate remedy. > > it's not intended to prove that. > > > > > Those are technical and policy questions. Declaring them invalid does > > not resolve them. > They are not good reasons against the proposal. > > But some people maybe want to be against the proposal first and then are > looking for "questions". > > Frank > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/a7286772/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Mon, 20 Jul 2026 07:34:21 +0000 > From: Tshepo Masuku > To: "rpd at afrinic.net" , "geier at geier.ne.tz" > > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > < > VI2PR04MB10545520811A7499ACFFB1239CAC32 at VI2PR04MB10545.eurprd04.prod.outlook.com > > > > Content-Type: text/plain; charset="us-ascii" > > Hi Frank, > > You keep positioning yourself as the referee of which objections count. > > That is not your role. Participants are allowed to question whether a > useful change belongs in mandatory policy. Dismissing those concerns > instead of answering them turns discussion into gatekeeping. > > A policy room may debate. It does not grant any participant authority to > police dissent. > > I remain opposed. > > Regards, > Tshepo > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/0cd4be0c/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 81 > ************************************ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 219280444 at mycput.ac.za Mon Jul 20 07:38:15 2026 From: 219280444 at mycput.ac.za (Thulisile Mazomba) Date: Mon, 20 Jul 2026 07:38:15 +0000 Subject: [rpd] Subject: Re: [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: Hi Frank, An improvement is not automatically a justification for mandatory policy. The question is whether the benefit is significant enough, proven enough, and proportionate enough to place in the registry's compulsory layer. Saying "it helps" does not answer that. And no, raising those questions does not mean the objection came first. It means policy power should be tested before it is expanded. I remain opposed. Regards, Thulisile Get Outlook for Android ________________________________ From: rpd-request at afrinic.net Sent: Monday, 20 July 2026 08:50:55 To: rpd at afrinic.net Subject: RPD Digest, Vol 222, Issue 80 Send RPD mailing list submissions to rpd at afrinic.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.afrinic.net/mailman/listinfo/rpd or, via email, send a message with subject or body 'help' to rpd-request at afrinic.net You can reach the person managing the list at rpd-owner at afrinic.net When replying, please edit your Subject line so it is more specific than "Re: Contents of RPD digest..." Today's Topics: 1. Re: RPD Digest, Vol 222, Issue 76 (Frank Habicht) 2. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Frank Habicht) 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Frank Habicht) 4. Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Thandeka Mseleku) 5. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Daniel Schroder) ---------------------------------------------------------------------- Message: 1 Date: Mon, 20 Jul 2026 07:25:52 +0300 From: Frank Habicht To: rpd at afrinic.net Subject: Re: [rpd] RPD Digest, Vol 222, Issue 76 Message-ID: Content-Type: text/plain; charset=UTF-8; format=flowed Hi On 7/20/2026 1:17 AM, Fundiswa Nadia Maseko wrote: > I disagree with your conclusion that opponents have presented no > technical arguments. Please name one. Frank ------------------------------ Message: 2 Date: Mon, 20 Jul 2026 07:36:00 +0300 From: Frank Habicht To: Thulisile Mazomba <219280444 at mycput.ac.za>, "rpd at afrinic.net" Cc: "rpd-owner at afrinic.ne" Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: <8b2ddf81-edd0-4c6a-97c3-46be5634ea04 at geier.ne.tz> Content-Type: text/plain; charset=UTF-8; format=flowed Hi, On 7/19/2026 11:29 PM, Thulisile Mazomba wrote: > > Hi Frank, > > You appear to be treating your disagreement with an objection as proof > that no technical objection exists. > > The proposal prevents one naming collision. It does not establish the > correctness of the routing data attached to that name, The proposal does not fix *all* problems. and it doesn't claim to do so. It creates an improvement. I don't agree that it is ok to object just because this proposal does not fix *all* problems. Do you agree it provides improvements? > nor prove that > mandatory registry control is the only proportionate remedy. it's not intended to prove that. > > Those are technical and policy questions. Declaring them invalid does > not resolve them. They are not good reasons against the proposal. But some people maybe want to be against the proposal first and then are looking for "questions". Frank ------------------------------ Message: 3 Date: Mon, 20 Jul 2026 07:58:22 +0300 From: Frank Habicht To: rpd at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: <3e091d61-af57-4543-bebf-402a7fbc937f at geier.ne.tz> Content-Type: text/plain; charset=UTF-8; format=flowed Hi, inline... On 7/19/2026 9:38 PM, Fundiswa Nadia Maseko wrote: > Dear Hendrik, > > Thank you for taking the time to answer my questions. > > I think we actually agree on one important point: hierarchical naming > authenticates who creates the object, can we also agree that this is a good thing? > but it does not guarantee that the > contents of the object are accurate. I agree with that. Also, please note: noone claimed it does that. This proposal is not the perfect solution which guarantees accuracy. There are also many other problems this proposal does not solve..... > That was the distinction I was > trying to make. So the proposal is an improvement, right? So should we adopt it? Since AfriNIC does operate an IRR, do we want AfriNIC to do that in the best possible way? > Where we still differ is on whether that justifies making the naming > convention mandatory. I tried to explain with the AS-GOOGLE example - if we don't make it mandatory, collisions may be created. Actually by anyone in the world. > I understand your position that this is the > narrowest solution available, but I'm not yet convinced that less > restrictive alternatives have been ruled out. I don't think it's possible to prove to you that there are no less restrictive alternatives. But if there are, I think it's possible for you to show us. > I still think that point > deserves more discussion. And we should start to clarify where the "burden of proof" is ;-) > I also don't believe that the fact that other RIRs have adopted the same > approach automatically means AFRINIC must do so. It's useful context, > but I don't think it replaces the need to show why this is necessary for > our own policy process. About the necessity: Can we agree that collisions happen, that hey are bad, that they have let to operational problems? > I'm not trying to oppose operational improvements. I'm simply asking > whether a mandatory policy is the only way to achieve the intended > outcome. If we can find a better way, we can use it. If we can't find a better way, I think we should use this proposal. Isn't this how this choice should work? Regards, Frank ------------------------------ Message: 4 Date: Mon, 20 Jul 2026 08:06:34 +0200 From: Thandeka Mseleku To: rpd at afrinic.net Cc: rpd-owner at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Content-Type: text/plain; charset="utf-8" Dear colleagues, The discussion is now being diverted from the proposal into speculation about writing style, drafting tools, and who may have assisted whom. That is not a sound basis for policy assessment. An LLM?s opinion about whether a message resembles another message is not evidence of authorship, coordination, or astroturfing. It is merely another generated interpretation. Feeding text into Claude and quoting a probability back to the list does not establish who wrote the text, who agrees with it, or whether the argument is valid. Frank suggests that contributions should be disregarded because they refer to the burden of proof even though the proposal contains a problem statement. That is a misunderstanding. A problem statement identifies a concern. It does not automatically prove that the proposed remedy is necessary, sufficient, proportionate, or the least restrictive available response. Those are different questions. The proposal may accurately describe risks associated with flat AS-SET names. Objectors are still entitled to ask whether mandatory hierarchical naming addresses the full problem, whether the benefit has been measured, whether residual risks remain, and whether central enforcement is justified. The repeated focus on familiar wording also proves very little. Participants reading the same thread may naturally respond to the same claims. People may agree with one another. They may adopt terminology already introduced in the discussion. Similarity of argument is not proof of common authorship, just as familiarity of names is not proof of correctness. The proper response to repeated objections is simple: identify the common substantive issue and answer it once, clearly and completely. If the objection is that hierarchical naming authenticates the creator of an object but does not validate its contents, then address that distinction. If the objection concerns the scope of mandatory registry authority, explain why compulsion is indispensable. If the objection concerns proportionality, provide the evidence. Trying to disqualify the speakers does not answer the argument. Participation in the PDWG should not depend on being a recognised operator, representing an ASN, writing in an informal style, or avoiding editorial assistance. Participants contribute evidence, criticism, experience, and warning. They do not need permission from an established procedural class before their concerns may be considered. Nor should the PDP confuse process with mandate. A proposal does not become technically necessary merely because it has supporters, a problem statement, or precedent elsewhere. The process must still test the rule against operational reality. The registry should remain a narrow coordination layer. It may protect uniqueness, maintain accurate records, and support routing-related services. It should not acquire broader authority simply because objections are inconvenient or because regular participants prefer a particular convention. I therefore ask that the discussion return to the policy itself. The questions remain: What exact failure does the proposal prevent? What evidence shows the scale of that failure? What risks remain after hierarchical naming is imposed? Why are less restrictive technical mechanisms insufficient? How will success be measured? Until those questions are answered, dismissing objections because of writing style is not consensus-building. It is avoidance. Regards, Thandeka -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 5 Date: Mon, 20 Jul 2026 08:49:53 +0200 From: Daniel Schroder Cc: rpd at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Content-Type: text/plain; charset="utf-8" Simple: The dog wanted a bone as usual. AI: As is customary, the canine harbored an insatiable desire for an osseous structure. Simple: Tom ordered pizza. AI: Thomas commissioned the preparation of an Italian flatbread adorned with melted cheese and savory toppings. Simple: We need one more document to complete your file. AI: Additional documentation is an absolute prerequisite to finalize your comprehensive dossier. If everyones is looking at their watches during a meeting, you missing the point which is getting to the point. Having language models influence input into policy changes from participants who rely on those LLMs for the simple objective of being heard or taken seriously is going to dissuade actual progress because there are other matters to attend to with policy being shifted to the backbench and your efforts effectively ignored, or your pearls lost in the mud. -daniel On Sun, Jul 19, 2026 at 9:38?PM Gugu Dhlamini wrote: > Hi Saul, > > Yes, the message was sent twice. That is a posting mistake, not a policy > argument. > > Focusing on duplicate delivery while ignoring the substance is exactly how > process starts replacing discussion. Please address the objection itself > rather than using a technical error as a reason to dismiss participation. > > Regards, > Gugu > > On Sun, 19 Jul 2026, 9:29 pm Fundiswa Nadia Maseko < > fundiswanadia2 at gmail.com> wrote: > >> Thank you for pointing that out. >> >> The two emails were intended for different purposes. The first was a >> direct response to Hendrik's points, while the second was addressed to the >> broader discussion, including your comments and the wider issue that had >> developed on the mailing list. >> >> I understand they were sent close together, which may have made them >> appear to be duplicates, but they were intended as separate responses. >> >> Kind regards, >> >> Fundiswa Nadia Maseko >> >> >> >> On Sun, 19 Jul 2026, 21:20 Saul Stein, wrote: >> >>> Hi >>> >>> you have now posted the email twice 7 minutes apart? >>> >>> >>> >>> >>> >>> *From:* Fundiswa Nadia Maseko >>> *Sent:* Sunday, 19 July 2026 20:46 >>> *To:* rpd at afrinic.net >>> *Subject:* Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>> >>> >>> >>> Dear Hendrik, Saul, and colleagues, >>> >>> >>> >>> Thank you for your responses. >>> >>> >>> >>> I would also like to address the recurring comments about AI-generated >>> contributions. >>> >>> >>> >>> Whether someone uses AI to improve grammar, structure, or clarity does >>> not, in itself, determine whether their arguments are valid. AI only works >>> with the information and instructions provided by the person using it. Many >>> people use it as a writing assistant to communicate their ideas more >>> clearly, just as others may ask a colleague to proofread or edit a draft >>> before sending it. >>> >>> >>> >>> For that reason, I do not believe the discussion should focus on how a >>> message was written, but rather on whether the technical reasoning is >>> correct or incorrect. >>> >>> >>> >>> With regard to the proposal itself, I appreciate Hendrik's direct >>> answers. However, simply answering "yes" or "no" does not, by itself, >>> explain the technical reasoning behind those conclusions. It would be >>> helpful to understand why the proposal is considered the least restrictive >>> solution and how the identified operational benefits outweigh the >>> additional policy requirements. That explanation would assist everyone in >>> evaluating the proposal on its technical merits. >>> >>> >>> >>> I believe the PDWG is strongest when differing views are examined >>> through technical discussion supported by evidence, rather than assumptions >>> about who wrote a message or what tools they may have used. >>> >>> >>> >>> Kind regards, >>> >>> >>> >>> Fundiswa Nadia Maseko >>> >>> >>> >>> >>> >>> On Sun, 19 Jul 2026, 20:34 , wrote: >>> >>> Send RPD mailing list submissions to >>> rpd at afrinic.net >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> or, via email, send a message with subject or body 'help' to >>> rpd-request at afrinic.net >>> >>> You can reach the person managing the list at >>> rpd-owner at afrinic.net >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of RPD digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage) >>> 2. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Saul Stein) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Sun, 19 Jul 2026 20:25:00 +0200 >>> From: Hendrik Visage >>> To: Fundiswa Nadia Maseko >>> Cc: rpd at afrinic.net >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>> Message-ID: <24327C8E-E411-4D2F-BE55-F250691CD720 at hevis.co.za> >>> Content-Type: text/plain; charset="utf-8"; Format="flowed" >>> >>> Dear Fundiswa, >>> >>> ?Has the proposal demonstrated mandatory naming is the least >>> restrictive solution?" ? Yes, >>> >>> "Do you disagree that hierarchical naming authenticates object creation >>> rather than membership accuracy?" ? No. >>> >>> These are the specific answers requested. >>> If you still oppose this proposal, we ask that you engage these answers >>> first ? in particular the deployment-coordination asymmetry raised ? >>> instead of repeating the original objections without technical >>> substances >>> >>> --- >>> 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 >>> >>> On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: >>> >>> > Dear Ben, >>> > >>> > Thank you for your response. >>> > >>> > Respectfully, I believe it is more productive to address the arguments >>> > themselves than to make assumptions about the people presenting them >>> > or the >>> > tools they may have used. >>> > >>> > If you believe the objections are technically incorrect, I would >>> > appreciate >>> > it if you could identify which specific points you disagree with. For >>> > example, do you disagree that hierarchical naming authenticates object >>> > creation rather than the accuracy of object membership? Or do you >>> > believe >>> > the proposal has demonstrated that mandatory naming is the least >>> > restrictive solution available? >>> > >>> > Those are technical questions that can be examined and debated. >>> > Dismissing >>> > opposing views as "AI bots" does not, on its own, explain why the >>> > arguments >>> > are wrong. >>> > I believe the PDWG benefits most when participants engage with the >>> > substance of each other's reasoning, regardless of how a contribution >>> > was >>> > drafted. >>> > >>> > >>> > Kind regards, >>> > Fundiswa Nadia Maseko >>> > >>> > On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, >>> > >>> > wrote: >>> > >>> >> Fundiswa, >>> >> But the AI bots opposing the AS-SET policy aren?t making technical >>> >> arguments. They are just regurgitating and re-using the same script. >>> >> None >>> >> of them seem to know or care what an AS-SET is, or what network >>> >> owners use >>> >> them for. >>> >> >>> >> Cheers, >>> >> Ben >>> >> Sent from my iPhone >>> >> >>> >> On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko >>> >> >>> >> wrote: >>> >> >>> >> ? >>> >> >>> >> *Dear PDWG,* >>> >> >>> >> I have been following this discussion with interest, and I would like >>> >> to >>> >> express my concern about the direction it has taken. >>> >> >>> >> The Policy Development Process should evaluate technical arguments on >>> >> their merits. Whether a participant drafted a message unaided, >>> >> received >>> >> editorial assistance, or used modern writing tools does not determine >>> >> whether the reasoning is sound. Speculating about authorship instead >>> >> of >>> >> addressing the substance risks distracting the Working Group from the >>> >> policy questions before it. >>> >> >>> >> I am also concerned by suggestions that contributions should be >>> >> disregarded simply because of assumptions about how they were >>> >> written. If >>> >> there are factual or technical errors, they should be identified and >>> >> discussed. That is how consensus is strengthened. >>> >> >>> >> The questions raised by several participants remain legitimate >>> >> subjects >>> >> for technical debate: whether the proposal has demonstrated >>> >> operational >>> >> necessity, whether the proposed intervention is proportionate, and >>> >> whether >>> >> less restrictive alternatives have been adequately considered. >>> >> >>> >> I therefore encourage all participants to continue engaging with the >>> >> substance of the proposal while maintaining the respectful and >>> >> professional >>> >> standards expected within the PDWG. >>> >> >>> >> Kind regards, >>> >> >>> >> Fundiswa Nadia Maseko >>> >> >>> >> >>> >> _______________________________________________ >>> >> RPD mailing list >>> >> RPD at afrinic.net >>> >> https://lists.afrinic.net/mailman/listinfo/rpd >>> >> >>> >> >>> >>> > _______________________________________________ >>> > RPD mailing list >>> > RPD at afrinic.net >>> > https://lists.afrinic.net/mailman/listinfo/rpd >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: < >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260719/3805216e/attachment-0001.html >>> > >>> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Sun, 19 Jul 2026 18:34:04 +0000 >>> From: Saul Stein >>> To: Hendrik Visage , Fundiswa Nadia Maseko >>> >>> Cc: "rpd at afrinic.net" >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>> Message-ID: >>> < >>> JNAP275MB125812327DC4FFF2404C216E8EC42 at JNAP275MB1258.ZAFP275.PROD.OUTLOOK.COM >>> > >>> >>> Content-Type: text/plain; charset="utf-8" >>> >>> Dear all, >>> Well, I have just finished my popcorn? sadly there wasn?t enough to read >>> the bombardment of emails, so I didn?t. >>> >>> What I did see though, was a number of non-original / cvopy and paste >>> objections. Not only that, but more importantly, they do not raise any >>> valid concerns about the proposal that has reached final call. >>> >>> So with that in mind, I fully support this proposal. >>> >>> I?d have to be part of a community group where you have to have a valid >>> NIC to post? >>> >>> Regards >>> Saul >>> >>> >>> From: Hendrik Visage via RPD >>> Sent: Sunday, 19 July 2026 20:25 >>> To: Fundiswa Nadia Maseko >>> Cc: rpd at afrinic.net >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>> >>> >>> Dear Fundiswa, >>> >>> ?Has the proposal demonstrated mandatory naming is the least restrictive >>> solution?" ? Yes, >>> >>> "Do you disagree that hierarchical naming authenticates object creation >>> rather than membership accuracy?" ? No. >>> >>> These are the specific answers requested. >>> If you still oppose this proposal, we ask that you engage these answers >>> first ? in particular the deployment-coordination asymmetry raised ? >>> instead of repeating the original objections without technical substances >>> >>> ________________________________ >>> >>> 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 >>> >>> On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: >>> Dear Ben, >>> >>> Thank you for your response. >>> >>> Respectfully, I believe it is more productive to address the arguments >>> themselves than to make assumptions about the people presenting them or the >>> tools they may have used. >>> >>> If you believe the objections are technically incorrect, I would >>> appreciate it if you could identify which specific points you disagree >>> with. For example, do you disagree that hierarchical naming authenticates >>> object creation rather than the accuracy of object membership? Or do you >>> believe the proposal has demonstrated that mandatory naming is the least >>> restrictive solution available? >>> >>> Those are technical questions that can be examined and debated. >>> Dismissing opposing views as "AI bots" does not, on its own, explain why >>> the arguments are wrong. >>> I believe the PDWG benefits most when participants engage with the >>> substance of each other's reasoning, regardless of how a contribution was >>> drafted. >>> >>> >>> Kind regards, >>> Fundiswa Nadia Maseko >>> >>> On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, < >>> ben.roberts at afrinic.net> wrote: >>> Fundiswa, >>> But the AI bots opposing the AS-SET policy aren?t making technical >>> arguments. They are just regurgitating and re-using the same script. None >>> of them seem to know or care what an AS-SET is, or what network owners use >>> them for. >>> >>> Cheers, >>> Ben >>> Sent from my iPhone >>> >>> >>> On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko < >>> fundiswanadia2 at gmail.com> wrote: >>> ? >>> >>> Dear PDWG, >>> >>> I have been following this discussion with interest, and I would like to >>> express my concern about the direction it has taken. >>> >>> The Policy Development Process should evaluate technical arguments on >>> their merits. Whether a participant drafted a message unaided, received >>> editorial assistance, or used modern writing tools does not determine >>> whether the reasoning is sound. Speculating about authorship instead of >>> addressing the substance risks distracting the Working Group from the >>> policy questions before it. >>> >>> I am also concerned by suggestions that contributions should be >>> disregarded simply because of assumptions about how they were written. If >>> there are factual or technical errors, they should be identified and >>> discussed. That is how consensus is strengthened. >>> >>> The questions raised by several participants remain legitimate subjects >>> for technical debate: whether the proposal has demonstrated operational >>> necessity, whether the proposed intervention is proportionate, and whether >>> less restrictive alternatives have been adequately considered. >>> >>> I therefore encourage all participants to continue engaging with the >>> substance of the proposal while maintaining the respectful and professional >>> standards expected within the PDWG. >>> >>> Kind regards, >>> >>> Fundiswa Nadia Maseko >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd< >>> https://lists.afrinic.net/mailman/listinfo/rpd> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd< >>> https://lists.afrinic.net/mailman/listinfo/rpd> >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: < >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260719/f1cb5a98/attachment.html >>> > >>> >>> ------------------------------ >>> >>> Subject: Digest Footer >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> >>> ------------------------------ >>> >>> End of RPD Digest, Vol 222, Issue 71 >>> ************************************ >>> >>> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ End of RPD Digest, Vol 222, Issue 80 ************************************ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Mon Jul 20 07:41:18 2026 From: ben.roberts at afrinic.net (ben.roberts@frinic.net) Date: Mon, 20 Jul 2026 09:41:18 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 81 In-Reply-To: References: , Message-ID: An HTML attachment was scrubbed... URL: From nndemo at staff.zegu.ac.zw Mon Jul 20 07:41:43 2026 From: nndemo at staff.zegu.ac.zw (Nyasha Ndemo) Date: Mon, 20 Jul 2026 09:41:43 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear PDWG, The discussion is being diverted from the substance of the objections toward speculation about AI use, writing style, and how consensus should be counted. That does not answer the policy concerns raised. A problem statement does not prove that the proposed remedy is necessary, proportionate, or technically sufficient. Nor does the use of drafting assistance invalidate an argument. The relevant question is whether the objection is sound. The objections remain clear: the proposal improves naming attribution, but it does not validate AS-SET contents, eliminate incorrect customer-cone data, or demonstrate that mandatory registry enforcement is the minimum necessary response. If several participants raise the same concern, the proper response is to answer that concern on its merits. Similarity does not make it disappear, and unfamiliar participants do not count for less. Participation is evidence, not mandate. Consensus is not manufactured by dismissing dissenters or analysing their prose. I therefore remain opposed and ask that the discussion return to the unresolved technical and proportionality questions. Regards, [Name] Dr. Nyasha Ndemo-Masimbarasi (DPhil, MSc., BSc. Hon. Development Science and Policy) Chairperson - Department of Development Programming and Management Zimbabwe Ezekiel Guti University 1901 Barrassie Rd, Off Shamva Rd, Bindura Zimbabwe Landline: +263867 700 6136 Cell: +263 773226552 Email: nyashandemo at gmail.com On Mon, Jul 20, 2026, 9:35?AM wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Subject: Re: [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Thulisile > Mazomba) > 2. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Tshepo Masuku) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 20 Jul 2026 07:24:43 +0000 > From: Thulisile Mazomba <219280444 at mycput.ac.za> > To: Frank Habicht , "rpd at afrinic.net" > > Cc: "rpd-owner at afrinic.ne" > Subject: [rpd] Subject: Re: [Last Call] Draft Policy Proposal ? > Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > < > GVXPR04MB12291FB9551CD3D0ADB433FE6D1C32 at GVXPR04MB12291.eurprd04.prod.outlook.com > > > > Content-Type: text/plain; charset="windows-1252" > > Hi Frank, > > An improvement is not automatically a justification for mandatory policy. > > The question is whether the benefit is significant enough, proven enough, > and proportionate enough to place in the registry?s compulsory layer. > Saying ?it helps? does not answer that. > > And no, raising those questions does not mean the objection came first. It > means policy power should be tested before it is expanded. > > I remain opposed. > > Regards, > Thulisile > ________________________________ > From: Frank Habicht > Sent: Monday, 20 July 2026 06:36:00 > To: Thulisile Mazomba <219280444 at mycput.ac.za>; rpd at afrinic.net < > rpd at afrinic.net> > Cc: rpd-owner at afrinic.ne > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > Hi, > > On 7/19/2026 11:29 PM, Thulisile Mazomba wrote: > > > > Hi Frank, > > > > You appear to be treating your disagreement with an objection as proof > > that no technical objection exists. > > > > The proposal prevents one naming collision. It does not establish the > > correctness of the routing data attached to that name, > > The proposal does not fix *all* problems. and it doesn't claim to do so. > It creates an improvement. > I don't agree that it is ok to object just because this proposal does > not fix *all* problems. > > Do you agree it provides improvements? > > > nor prove that > > mandatory registry control is the only proportionate remedy. > > it's not intended to prove that. > > > > > Those are technical and policy questions. Declaring them invalid does > > not resolve them. > They are not good reasons against the proposal. > > But some people maybe want to be against the proposal first and then are > looking for "questions". > > Frank > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/a7286772/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Mon, 20 Jul 2026 07:34:21 +0000 > From: Tshepo Masuku > To: "rpd at afrinic.net" , "geier at geier.ne.tz" > > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > < > VI2PR04MB10545520811A7499ACFFB1239CAC32 at VI2PR04MB10545.eurprd04.prod.outlook.com > > > > Content-Type: text/plain; charset="us-ascii" > > Hi Frank, > > You keep positioning yourself as the referee of which objections count. > > That is not your role. Participants are allowed to question whether a > useful change belongs in mandatory policy. Dismissing those concerns > instead of answering them turns discussion into gatekeeping. > > A policy room may debate. It does not grant any participant authority to > police dissent. > > I remain opposed. > > Regards, > Tshepo > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/0cd4be0c/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 81 > ************************************ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonjabulosphilile at gmail.com Mon Jul 20 07:43:11 2026 From: nonjabulosphilile at gmail.com (Nonjabulo Sphilile) Date: Mon, 20 Jul 2026 09:43:11 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Hi Frank, You seem more interested in grading participants than answering the policy concern. That is not consensus-building. It is gatekeeping. Participation is not a privilege granted by familiar voices, and disagreement is not misconduct. Please address the substance instead of threatening to disregard contributors. I remain opposed. Regards, Nonjabulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Mon Jul 20 07:45:53 2026 From: ben.roberts at afrinic.net (ben.roberts@frinic.net) Date: Mon, 20 Jul 2026 09:45:53 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: <03F8CE74-281D-134A-BC11-DA1F695B0B01@hxcore.ol> An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Mon Jul 20 07:46:05 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Mon, 20 Jul 2026 09:46:05 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 81 In-Reply-To: References: Message-ID: Hi Ben, Participants may introduce themselves if they choose, but an introduction should not become a condition for having an argument considered. This is an open policy forum, not a membership interview. Contributions should be assessed on their substance, not on how familiar the speaker is or how long they have been present. Regards, Nonhlanhla On Mon, 20 Jul 2026, 9:41 am ben.roberts at frinic.net wrote: > Nonhlanhla, > > Perhaps the new participants would like to introduce themselves, with some > context of their new interest in IP address policy making? > > Kind Regards, > Ben > > *From: *Nia Petronella > *Date: *Monday, 20 July 2026 at 09:38 > *To: *rpd at afrinic.net > *Subject: *Re: [rpd] RPD Digest, Vol 222, Issue 81 > > Get Outlook for Mac > Dear PDWG, > > A pattern is becoming clear: familiar names are treated as authoritative, > while newer participants are questioned, graded, or dismissed. > > That is gatekeeping, not consensus. > > An open process should test arguments, not reputations. Participation is > evidence and objection; being well known does not create a mandate to > decide whose voice counts. > > Regards, > Nonhlanhla > > On Mon, 20 Jul 2026, 9:35 am wrote: > > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Subject: Re: [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Thulisile > Mazomba) > 2. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Tshepo Masuku) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 20 Jul 2026 07:24:43 +0000 > From: Thulisile Mazomba <219280444 at mycput.ac.za> > To: Frank Habicht , "rpd at afrinic.net" > > Cc: "rpd-owner at afrinic.ne" > Subject: [rpd] Subject: Re: [Last Call] Draft Policy Proposal ? > Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > < > GVXPR04MB12291FB9551CD3D0ADB433FE6D1C32 at GVXPR04MB12291.eurprd04.prod.outlook.com > > > > Content-Type: text/plain; charset="windows-1252" > > Hi Frank, > > An improvement is not automatically a justification for mandatory policy. > > The question is whether the benefit is significant enough, proven enough, > and proportionate enough to place in the registry?s compulsory layer. > Saying ?it helps? does not answer that. > > And no, raising those questions does not mean the objection came first. It > means policy power should be tested before it is expanded. > > I remain opposed. > > Regards, > Thulisile > ________________________________ > From: Frank Habicht > Sent: Monday, 20 July 2026 06:36:00 > To: Thulisile Mazomba <219280444 at mycput.ac.za>; rpd at afrinic.net < > rpd at afrinic.net> > Cc: rpd-owner at afrinic.ne > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > Hi, > > On 7/19/2026 11:29 PM, Thulisile Mazomba wrote: > > > > Hi Frank, > > > > You appear to be treating your disagreement with an objection as proof > > that no technical objection exists. > > > > The proposal prevents one naming collision. It does not establish the > > correctness of the routing data attached to that name, > > The proposal does not fix *all* problems. and it doesn't claim to do so. > It creates an improvement. > I don't agree that it is ok to object just because this proposal does > not fix *all* problems. > > Do you agree it provides improvements? > > > nor prove that > > mandatory registry control is the only proportionate remedy. > > it's not intended to prove that. > > > > > Those are technical and policy questions. Declaring them invalid does > > not resolve them. > They are not good reasons against the proposal. > > But some people maybe want to be against the proposal first and then are > looking for "questions". > > Frank > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/a7286772/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Mon, 20 Jul 2026 07:34:21 +0000 > From: Tshepo Masuku > To: "rpd at afrinic.net" , "geier at geier.ne.tz" > > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > < > VI2PR04MB10545520811A7499ACFFB1239CAC32 at VI2PR04MB10545.eurprd04.prod.outlook.com > > > > Content-Type: text/plain; charset="us-ascii" > > Hi Frank, > > You keep positioning yourself as the referee of which objections count. > > That is not your role. Participants are allowed to question whether a > useful change belongs in mandatory policy. Dismissing those concerns > instead of answering them turns discussion into gatekeeping. > > A policy room may debate. It does not grant any participant authority to > police dissent. > > I remain opposed. > > Regards, > Tshepo > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/0cd4be0c/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 81 > ************************************ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From saul at enetworks.co.za Mon Jul 20 08:05:43 2026 From: saul at enetworks.co.za (Saul Stein) Date: Mon, 20 Jul 2026 08:05:43 +0000 Subject: [rpd] RPD Digest, Vol 222, Issue 81 In-Reply-To: References: Message-ID: Actually, one?s knowledge and experience is very relevant. Running and safeguarding the internet landscape is a very practical thing. Something that those who do, do so on a daily basis. People who are commenting on the practicality of running the internet and routing protocols and who have no experience in it or are even involved in it, might well have some insights to provide. HOWEVER, they then need to provide fact to base comments where the technical community who are practically involved in the process are saying otherwise. Simply repeating the same narrative which goes against global trends and those that use it raise questions about their intentions. From: Nia Petronella Sent: Monday, 20 July 2026 09:46 To: ben.roberts at afrinic.net; rpd at afrinic.net Subject: Re: [rpd] RPD Digest, Vol 222, Issue 81 Hi Ben, Participants may introduce themselves if they choose, but an introduction should not become a condition for having an argument considered. This is an open policy forum, not a membership interview. Contributions should be assessed on their substance, not on how familiar the speaker is or how long they have been present. Regards, Nonhlanhla On Mon, 20 Jul 2026, 9:41 am ben.roberts at frinic.net > wrote: Nonhlanhla, Perhaps the new participants would like to introduce themselves, with some context of their new interest in IP address policy making? Kind Regards, Ben From: Nia Petronella > Date: Monday, 20 July 2026 at 09:38 To: rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 81 Get Outlook for Mac Dear PDWG, A pattern is becoming clear: familiar names are treated as authoritative, while newer participants are questioned, graded, or dismissed. That is gatekeeping, not consensus. An open process should test arguments, not reputations. Participation is evidence and objection; being well known does not create a mandate to decide whose voice counts. Regards, Nonhlanhla On Mon, 20 Jul 2026, 9:35 am > wrote: Send RPD mailing list submissions to rpd at afrinic.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.afrinic.net/mailman/listinfo/rpd or, via email, send a message with subject or body 'help' to rpd-request at afrinic.net You can reach the person managing the list at rpd-owner at afrinic.net When replying, please edit your Subject line so it is more specific than "Re: Contents of RPD digest..." Today's Topics: 1. Subject: Re: [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Thulisile Mazomba) 2. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Tshepo Masuku) ---------------------------------------------------------------------- Message: 1 Date: Mon, 20 Jul 2026 07:24:43 +0000 From: Thulisile Mazomba <219280444 at mycput.ac.za> To: Frank Habicht >, "rpd at afrinic.net" > Cc: "rpd-owner at afrinic.ne" > Subject: [rpd] Subject: Re: [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: > Content-Type: text/plain; charset="windows-1252" Hi Frank, An improvement is not automatically a justification for mandatory policy. The question is whether the benefit is significant enough, proven enough, and proportionate enough to place in the registry?s compulsory layer. Saying ?it helps? does not answer that. And no, raising those questions does not mean the objection came first. It means policy power should be tested before it is expanded. I remain opposed. Regards, Thulisile ________________________________ From: Frank Habicht > Sent: Monday, 20 July 2026 06:36:00 To: Thulisile Mazomba <219280444 at mycput.ac.za>; rpd at afrinic.net > Cc: rpd-owner at afrinic.ne > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Hi, On 7/19/2026 11:29 PM, Thulisile Mazomba wrote: > > Hi Frank, > > You appear to be treating your disagreement with an objection as proof > that no technical objection exists. > > The proposal prevents one naming collision. It does not establish the > correctness of the routing data attached to that name, The proposal does not fix *all* problems. and it doesn't claim to do so. It creates an improvement. I don't agree that it is ok to object just because this proposal does not fix *all* problems. Do you agree it provides improvements? > nor prove that > mandatory registry control is the only proportionate remedy. it's not intended to prove that. > > Those are technical and policy questions. Declaring them invalid does > not resolve them. They are not good reasons against the proposal. But some people maybe want to be against the proposal first and then are looking for "questions". Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: > ------------------------------ Message: 2 Date: Mon, 20 Jul 2026 07:34:21 +0000 From: Tshepo Masuku > To: "rpd at afrinic.net" >, "geier at geier.ne.tz" > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: > Content-Type: text/plain; charset="us-ascii" Hi Frank, You keep positioning yourself as the referee of which objections count. That is not your role. Participants are allowed to question whether a useful change belongs in mandatory policy. Dismissing those concerns instead of answering them turns discussion into gatekeeping. A policy room may debate. It does not grant any participant authority to police dissent. I remain opposed. Regards, Tshepo -------------- next part -------------- An HTML attachment was scrubbed... URL: > ------------------------------ Subject: Digest Footer _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ End of RPD Digest, Vol 222, Issue 81 ************************************ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ST10120874 at vcconnect.edu.za Mon Jul 20 08:10:38 2026 From: ST10120874 at vcconnect.edu.za (Mphoentle Mokheseng) Date: Mon, 20 Jul 2026 08:10:38 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear PDWG, The discussion is drifting away from policy analysis and toward deciding which participants deserve to be heard. That is not a legitimate consensus test. Frank, a proposal containing a problem statement does not remove the proponents? burden to show that the proposed remedy is necessary, effective, proportionate, and preferable to less restrictive alternatives. Describing a problem and proving a mandatory solution are different tasks. Hendrik, the fact that operators support a proposal does not convert their preference into authority. Operators provide important evidence, but they do not become the principals of every affected network merely because they participate in the working group. A proposal originating from an operator can still expand institutional control. The comparison with traffic laws is also incorrect. Governments exercise authority through public law, established legal mandates, representation, judicial review, and public accountability. AFRINIC is a private registry, and the PDWG exists to develop technical policy through open consensus. The existence of a discussion forum does not, in itself, confer legislative authority or justify expanding registry intervention beyond what has been demonstrated to be operationally necessary. Questions about whether contributors use an IRR, operate an ASN, are familiar names, or may have used drafting tools do not answer their objections. Writing style is not a technical metric. An AI-generated opinion about another message is not evidence of astroturfing, and repeated objections do not become invalid because their reasoning overlaps. The co-chairs may reasonably group similar objections as one substantive concern. They may not disregard that concern without determining whether it has actually been answered. The unresolved point remains straightforward: the proposal may prevent future flat-name collisions, but its supporters must still show the exact operational harm addressed, the scope of the benefit, the limitations of the remedy, and why mandatory registry enforcement is the minimum necessary approach. Consensus is not the absence of unfamiliar voices. It is not the agreement of recognised insiders. It is not achieved by asking that inconvenient contributions be disregarded. Please return the discussion to the proposal. I remain opposed. Regards, Mphoentle Disclaimer This email and the information contained herein are Advtech Ltd confidential and are protected by law. Please navigate to our website for more information https://www.groupadvtech.com. Use of this information or this email by any person for any purposes other than that for which it is intended is prohibited and may result in civil and/or criminal liability. This email is not to be shared with any 3rd parties not included within this email, without the written consent of its Author. If you have received this message in error, please notify Advtech immediately, telephone number +27 11 676 8000. Advtech leads the private sector in the fields of education and resourcing, contributing meaningfully towards the sustainable development of human capacity in South Africa. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Mon Jul 20 08:22:21 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Mon, 20 Jul 2026 10:22:21 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: <47c7fa89-2925-459b-a454-e92cd87e07ea@uls.co.za> Hi, Please allow me to be blatantly blunt: The only possible reason I can imagine to resist this proposal is because you don't want people to use Hierarchical Names, leaving them vulnerable to IRR collision attacks, in order to enable yourself or a related party to execute such a collision attack against them.? Either that or you're resisting change for the sake of resisting change. The problem is, it's usually not the vulnerable party that suffers the damages, it's their peers, service providers and customers. I beg you Mphoentle, as well as Tshepo, Paulo, Nthabiesng, Thandeka, Thulisile, Nia,?Asamkele,?Nonhlanhla?and probably others I've missed now please stop this.? Others call this astroturfing. Just because a bunch of you repeat the same rhetoric, not grounded in actual technical fact or sound reasoning, does not make it true, reasonable or sensible.? If you want to object, please clarify to us from a technical and operational perspective how this policy causes harm (ie, as Nishal said - creates operational problems - so that we can address that). It has been shown, and is well know, that Hierarchical Names helps avoid inter-RIR naming collissions, this preventing a set of known attacks (at least one of our upstreams was collided previously, causing measurable harm to us - this policy, if implemented from day one, would have prevented that).? This does not in any way add additional centralised control - you can choose to use these objects to help protect you, your customers, as well as your providers, or not.? But I highly recommend you do.? This policy, does in fact, not actually change anything other than force those that choose to use the mechanism to not make themselves vulnerable to known naming collision attacks.? In other words - this policy solves actual real-world problem for real network operators.? If that can be done in a better way - please speak up and show us how, rather than just merely objecting. Better tooling as some have implied does not stop the problem. One can (for bgpq* at least) say to specifically look at say AFRINIC::ULS - but fixing the root cause of the problem should be preferred over requiring all tooling to work around the problem. Which is what this policy does. The same goes for every other objection to this proposal.? It feels like the whole AS0 situation all over again.? Those of us who operated actual networks has existing operational problems which this, and policies such as others being resisted currently, as well as the previously mentioned AS0 policy, helps address. This isn't about centralising control.? This is about protecting resources and making the Internet a better and safer place for all. These policies helps to make the internet a safer place for all. Kind regards, Jaco Kroon On 2026/07/17 21:36, Mphoentle Mokheseng via RPD wrote: > Dear PDWG Chairs, > > I object to AFPUB-2026-ASN-001-DRAFT02. > > The Internet has always succeeded by minimizing the amount of > centralized authority required for independent networks to > interoperate. Coordination is necessary. Governance beyond what > coordination requires is not. > > This proposal may appear modest, but it reflects a broader trend that > deserves scrutiny. We increasingly treat every operational preference > as something that must be standardized through policy simply because > the registry is capable of administering it. That reverses the proper > relationship between operations and policy. > > Policy should emerge from established operational reality. It should > not be used to manufacture it. > > The burden is on the proposer to demonstrate that an existing > technical deficiency cannot be addressed without creating a new policy > obligation. I do not believe that burden has been met. No compelling > evidence has been presented that current AS-SET naming practices > threaten uniqueness, registry integrity, interoperability, or the > stable operation of the Internet. > > The fact that a naming convention may be desirable does not make it an > appropriate subject for mandatory registry policy. > > Every additional policy expands the registry's sphere of > interpretation and administration. Individually these expansions > appear harmless. Collectively they normalize the idea that the > registry should increasingly prescribe operational behaviour rather > than simply coordinate shared technical resources. > > That is a direction we should resist. > > The registry's legitimacy comes from performing a narrowly defined > technical function exceptionally well, not from continuously enlarging > its policy surface. We should preserve that distinction. Institutions > are strongest when they exercise only the authority that is > demonstrably necessary, and no more. > > For these reasons, I object to AFPUB-2026-ASN-001-DRAFT02. > > Kind regards, > Mphoentle > Disclaimer This email and the information contained herein are Advtech > Ltd confidential and are protected by law. Please navigate to our > website for more information https://www.groupadvtech.com. Use of this > information or this email by any person for any purposes other than > that for which it is intended is prohibited and may result in civil > and/or criminal liability. This email is not to be shared with any 3rd > parties not included within this email, without the written consent of > its Author. If you have received this message in error, please notify > Advtech immediately, telephone number +27 11 676 8000. Advtech leads > the private sector in the fields of education and resourcing, > contributing meaningfully towards the sustainable development of human > capacity in South Africa. > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Mon Jul 20 08:22:31 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Mon, 20 Jul 2026 08:22:31 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Hi Saul, Experience matters, but it does not give anyone exclusive authority over the discussion. Operators may provide evidence from practice. Others may still question the scope, necessity, and consequences of the policy. If an objection is weak, answer it on the merits. Participation is not mandate, and disagreement is not evidence of bad intent. Regards, Tshepo -------------- next part -------------- An HTML attachment was scrubbed... URL: From phetulodhlamini at gmail.com Mon Jul 20 08:37:46 2026 From: phetulodhlamini at gmail.com (Phetulo Dhlamini) Date: Mon, 20 Jul 2026 10:37:46 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Hi Saul, Experience is relevant. It is not authority. Operators should bring evidence from running networks, but they do not become the exclusive judges of who may participate or which concerns count. The line matters: participation can provide expertise, warning, and objection; it does not create a mandate over everyone else. Global trends are also not self-proving. Adoption elsewhere is evidence to examine, not a command to copy. If an objection is wrong, show why. Questioning the intentions of unfamiliar participants because they disagree with established operators is not technical scrutiny. It is gatekeeping. Regards, Phetulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonjabulosphilile at gmail.com Mon Jul 20 08:39:02 2026 From: nonjabulosphilile at gmail.com (Nonjabulo Sphilile) Date: Mon, 20 Jul 2026 10:39:02 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Hi Jaco, Accusing objectors of wanting to enable attacks is not a technical rebuttal. It assigns motive where evidence is required. Your operational example deserves consideration, but operator experience remains evidence, not mandate. Consensus cannot be built by treating disagreement as bad faith. Please address the objection without criminalising participation. Regards, Nonjabulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From onica at globaldigitalinclusion.org Mon Jul 20 08:42:00 2026 From: onica at globaldigitalinclusion.org (Onica Makwakwa) Date: Mon, 20 Jul 2026 10:42:00 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 80 In-Reply-To: References: Message-ID: Greetings, Please switch me to a daily digest. Thanks, Onica On Mon, Jul 20, 2026 at 8:51?AM wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: RPD Digest, Vol 222, Issue 76 (Frank Habicht) > 2. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Frank Habicht) > 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Frank Habicht) > 4. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Thandeka Mseleku) > 5. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Daniel Schroder) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 20 Jul 2026 07:25:52 +0300 > From: Frank Habicht > To: rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 76 > Message-ID: > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi > > On 7/20/2026 1:17 AM, Fundiswa Nadia Maseko wrote: > > I disagree with your conclusion that opponents have presented no > > technical arguments. > Please name one. > > Frank > > > > ------------------------------ > > Message: 2 > Date: Mon, 20 Jul 2026 07:36:00 +0300 > From: Frank Habicht > To: Thulisile Mazomba <219280444 at mycput.ac.za>, "rpd at afrinic.net" > > Cc: "rpd-owner at afrinic.ne" > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: <8b2ddf81-edd0-4c6a-97c3-46be5634ea04 at geier.ne.tz> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi, > > On 7/19/2026 11:29 PM, Thulisile Mazomba wrote: > > > > Hi Frank, > > > > You appear to be treating your disagreement with an objection as proof > > that no technical objection exists. > > > > The proposal prevents one naming collision. It does not establish the > > correctness of the routing data attached to that name, > > The proposal does not fix *all* problems. and it doesn't claim to do so. > It creates an improvement. > I don't agree that it is ok to object just because this proposal does > not fix *all* problems. > > Do you agree it provides improvements? > > > nor prove that > > mandatory registry control is the only proportionate remedy. > > it's not intended to prove that. > > > > > Those are technical and policy questions. Declaring them invalid does > > not resolve them. > They are not good reasons against the proposal. > > But some people maybe want to be against the proposal first and then are > looking for "questions". > > Frank > > > > > ------------------------------ > > Message: 3 > Date: Mon, 20 Jul 2026 07:58:22 +0300 > From: Frank Habicht > To: rpd at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: <3e091d61-af57-4543-bebf-402a7fbc937f at geier.ne.tz> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi, > > inline... > > On 7/19/2026 9:38 PM, Fundiswa Nadia Maseko wrote: > > Dear Hendrik, > > > > Thank you for taking the time to answer my questions. > > > > I think we actually agree on one important point: hierarchical naming > > authenticates who creates the object, > > can we also agree that this is a good thing? > > > but it does not guarantee that the > > contents of the object are accurate. > > I agree with that. > Also, please note: noone claimed it does that. > This proposal is not the perfect solution which guarantees accuracy. > There are also many other problems this proposal does not solve..... > > > That was the distinction I was > > trying to make. > > So the proposal is an improvement, right? > So should we adopt it? > > Since AfriNIC does operate an IRR, do we want AfriNIC to do that in the > best possible way? > > > > Where we still differ is on whether that justifies making the naming > > convention mandatory. > > I tried to explain with the AS-GOOGLE example - if we don't make it > mandatory, collisions may be created. Actually by anyone in the world. > > > I understand your position that this is the > > narrowest solution available, but I'm not yet convinced that less > > restrictive alternatives have been ruled out. > > I don't think it's possible to prove to you that there are no less > restrictive alternatives. But if there are, I think it's possible for > you to show us. > > > I still think that point > > deserves more discussion. > > And we should start to clarify where the "burden of proof" is ;-) > > > I also don't believe that the fact that other RIRs have adopted the same > > approach automatically means AFRINIC must do so. It's useful context, > > but I don't think it replaces the need to show why this is necessary for > > our own policy process. > > About the necessity: > Can we agree that collisions happen, that hey are bad, that they have > let to operational problems? > > > I'm not trying to oppose operational improvements. I'm simply asking > > whether a mandatory policy is the only way to achieve the intended > > outcome. > > If we can find a better way, we can use it. > If we can't find a better way, I think we should use this proposal. > Isn't this how this choice should work? > > Regards, > Frank > > > > > ------------------------------ > > Message: 4 > Date: Mon, 20 Jul 2026 08:06:34 +0200 > From: Thandeka Mseleku > To: rpd at afrinic.net > Cc: rpd-owner at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > S0D4RO7rbS-CVSP0_3wntWb0H5AXTf4tqHkV-s974fA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear colleagues, > > The discussion is now being diverted from the proposal into speculation > about writing style, drafting tools, and who may have assisted whom. > > That is not a sound basis for policy assessment. > > An LLM?s opinion about whether a message resembles another message is not > evidence of authorship, coordination, or astroturfing. It is merely another > generated interpretation. Feeding text into Claude and quoting a > probability back to the list does not establish who wrote the text, who > agrees with it, or whether the argument is valid. > > Frank suggests that contributions should be disregarded because they refer > to the burden of proof even though the proposal contains a problem > statement. That is a misunderstanding. A problem statement identifies a > concern. It does not automatically prove that the proposed remedy is > necessary, sufficient, proportionate, or the least restrictive available > response. > > Those are different questions. > > The proposal may accurately describe risks associated with flat AS-SET > names. Objectors are still entitled to ask whether mandatory hierarchical > naming addresses the full problem, whether the benefit has been measured, > whether residual risks remain, and whether central enforcement is > justified. > > The repeated focus on familiar wording also proves very little. > Participants reading the same thread may naturally respond to the same > claims. People may agree with one another. They may adopt terminology > already introduced in the discussion. Similarity of argument is not proof > of common authorship, just as familiarity of names is not proof of > correctness. > > The proper response to repeated objections is simple: identify the common > substantive issue and answer it once, clearly and completely. If the > objection is that hierarchical naming authenticates the creator of an > object but does not validate its contents, then address that distinction. > If the objection concerns the scope of mandatory registry authority, > explain why compulsion is indispensable. If the objection concerns > proportionality, provide the evidence. > > Trying to disqualify the speakers does not answer the argument. > > Participation in the PDWG should not depend on being a recognised operator, > representing an ASN, writing in an informal style, or avoiding editorial > assistance. Participants contribute evidence, criticism, experience, and > warning. They do not need permission from an established procedural class > before their concerns may be considered. > > Nor should the PDP confuse process with mandate. A proposal does not become > technically necessary merely because it has supporters, a problem > statement, or precedent elsewhere. The process must still test the rule > against operational reality. > > The registry should remain a narrow coordination layer. It may protect > uniqueness, maintain accurate records, and support routing-related > services. It should not acquire broader authority simply because objections > are inconvenient or because regular participants prefer a particular > convention. > > I therefore ask that the discussion return to the policy itself. > > The questions remain: > > What exact failure does the proposal prevent? > > What evidence shows the scale of that failure? > > What risks remain after hierarchical naming is imposed? > > Why are less restrictive technical mechanisms insufficient? > > How will success be measured? > > Until those questions are answered, dismissing objections because of > writing style is not consensus-building. It is avoidance. > > Regards, > Thandeka > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/8854dcc4/attachment-0001.html > > > > ------------------------------ > > Message: 5 > Date: Mon, 20 Jul 2026 08:49:53 +0200 > From: Daniel Schroder > Cc: rpd at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > 4qZNniduoG473soQVWdKBw at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Simple: The dog wanted a bone as usual. > AI: As is customary, the canine harbored an insatiable desire for an > osseous structure. > > Simple: Tom ordered pizza. > AI: Thomas commissioned the preparation of an Italian flatbread adorned > with melted cheese and savory toppings. > > Simple: We need one more document to complete your file. > AI: Additional documentation is an absolute prerequisite to finalize your > comprehensive dossier. > > If everyones is looking at their watches during a meeting, you missing the > point which is getting to the point. > > Having language models influence input into policy changes from > participants who rely on those LLMs for the simple objective of being heard > or taken seriously is going to dissuade actual progress because there are > other matters to attend to with policy being shifted to the backbench and > your efforts effectively ignored, or your pearls lost in the mud. -daniel > > > On Sun, Jul 19, 2026 at 9:38?PM Gugu Dhlamini > wrote: > > > Hi Saul, > > > > Yes, the message was sent twice. That is a posting mistake, not a policy > > argument. > > > > Focusing on duplicate delivery while ignoring the substance is exactly > how > > process starts replacing discussion. Please address the objection itself > > rather than using a technical error as a reason to dismiss participation. > > > > Regards, > > Gugu > > > > On Sun, 19 Jul 2026, 9:29 pm Fundiswa Nadia Maseko < > > fundiswanadia2 at gmail.com> wrote: > > > >> Thank you for pointing that out. > >> > >> The two emails were intended for different purposes. The first was a > >> direct response to Hendrik's points, while the second was addressed to > the > >> broader discussion, including your comments and the wider issue that had > >> developed on the mailing list. > >> > >> I understand they were sent close together, which may have made them > >> appear to be duplicates, but they were intended as separate responses. > >> > >> Kind regards, > >> > >> Fundiswa Nadia Maseko > >> > >> > >> > >> On Sun, 19 Jul 2026, 21:20 Saul Stein, wrote: > >> > >>> Hi > >>> > >>> you have now posted the email twice 7 minutes apart? > >>> > >>> > >>> > >>> > >>> > >>> *From:* Fundiswa Nadia Maseko > >>> *Sent:* Sunday, 19 July 2026 20:46 > >>> *To:* rpd at afrinic.net > >>> *Subject:* Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >>> > >>> > >>> > >>> Dear Hendrik, Saul, and colleagues, > >>> > >>> > >>> > >>> Thank you for your responses. > >>> > >>> > >>> > >>> I would also like to address the recurring comments about AI-generated > >>> contributions. > >>> > >>> > >>> > >>> Whether someone uses AI to improve grammar, structure, or clarity does > >>> not, in itself, determine whether their arguments are valid. AI only > works > >>> with the information and instructions provided by the person using it. > Many > >>> people use it as a writing assistant to communicate their ideas more > >>> clearly, just as others may ask a colleague to proofread or edit a > draft > >>> before sending it. > >>> > >>> > >>> > >>> For that reason, I do not believe the discussion should focus on how a > >>> message was written, but rather on whether the technical reasoning is > >>> correct or incorrect. > >>> > >>> > >>> > >>> With regard to the proposal itself, I appreciate Hendrik's direct > >>> answers. However, simply answering "yes" or "no" does not, by itself, > >>> explain the technical reasoning behind those conclusions. It would be > >>> helpful to understand why the proposal is considered the least > restrictive > >>> solution and how the identified operational benefits outweigh the > >>> additional policy requirements. That explanation would assist everyone > in > >>> evaluating the proposal on its technical merits. > >>> > >>> > >>> > >>> I believe the PDWG is strongest when differing views are examined > >>> through technical discussion supported by evidence, rather than > assumptions > >>> about who wrote a message or what tools they may have used. > >>> > >>> > >>> > >>> Kind regards, > >>> > >>> > >>> > >>> Fundiswa Nadia Maseko > >>> > >>> > >>> > >>> > >>> > >>> On Sun, 19 Jul 2026, 20:34 , wrote: > >>> > >>> Send RPD mailing list submissions to > >>> rpd at afrinic.net > >>> > >>> To subscribe or unsubscribe via the World Wide Web, visit > >>> https://lists.afrinic.net/mailman/listinfo/rpd > >>> or, via email, send a message with subject or body 'help' to > >>> rpd-request at afrinic.net > >>> > >>> You can reach the person managing the list at > >>> rpd-owner at afrinic.net > >>> > >>> When replying, please edit your Subject line so it is more specific > >>> than "Re: Contents of RPD digest..." > >>> > >>> > >>> Today's Topics: > >>> > >>> 1. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names > >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage) > >>> 2. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names > >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Saul Stein) > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> > >>> Message: 1 > >>> Date: Sun, 19 Jul 2026 20:25:00 +0200 > >>> From: Hendrik Visage > >>> To: Fundiswa Nadia Maseko > >>> Cc: rpd at afrinic.net > >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >>> Message-ID: <24327C8E-E411-4D2F-BE55-F250691CD720 at hevis.co.za> > >>> Content-Type: text/plain; charset="utf-8"; Format="flowed" > >>> > >>> Dear Fundiswa, > >>> > >>> ?Has the proposal demonstrated mandatory naming is the least > >>> restrictive solution?" ? Yes, > >>> > >>> "Do you disagree that hierarchical naming authenticates object creation > >>> rather than membership accuracy?" ? No. > >>> > >>> These are the specific answers requested. > >>> If you still oppose this proposal, we ask that you engage these answers > >>> first ? in particular the deployment-coordination asymmetry raised ? > >>> instead of repeating the original objections without technical > >>> substances > >>> > >>> --- > >>> 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 > >>> > >>> On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: > >>> > >>> > Dear Ben, > >>> > > >>> > Thank you for your response. > >>> > > >>> > Respectfully, I believe it is more productive to address the > arguments > >>> > themselves than to make assumptions about the people presenting them > >>> > or the > >>> > tools they may have used. > >>> > > >>> > If you believe the objections are technically incorrect, I would > >>> > appreciate > >>> > it if you could identify which specific points you disagree with. For > >>> > example, do you disagree that hierarchical naming authenticates > object > >>> > creation rather than the accuracy of object membership? Or do you > >>> > believe > >>> > the proposal has demonstrated that mandatory naming is the least > >>> > restrictive solution available? > >>> > > >>> > Those are technical questions that can be examined and debated. > >>> > Dismissing > >>> > opposing views as "AI bots" does not, on its own, explain why the > >>> > arguments > >>> > are wrong. > >>> > I believe the PDWG benefits most when participants engage with the > >>> > substance of each other's reasoning, regardless of how a contribution > >>> > was > >>> > drafted. > >>> > > >>> > > >>> > Kind regards, > >>> > Fundiswa Nadia Maseko > >>> > > >>> > On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, > >>> > > >>> > wrote: > >>> > > >>> >> Fundiswa, > >>> >> But the AI bots opposing the AS-SET policy aren?t making technical > >>> >> arguments. They are just regurgitating and re-using the same script. > >>> >> None > >>> >> of them seem to know or care what an AS-SET is, or what network > >>> >> owners use > >>> >> them for. > >>> >> > >>> >> Cheers, > >>> >> Ben > >>> >> Sent from my iPhone > >>> >> > >>> >> On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko > >>> >> > >>> >> wrote: > >>> >> > >>> >> ? > >>> >> > >>> >> *Dear PDWG,* > >>> >> > >>> >> I have been following this discussion with interest, and I would > like > >>> >> to > >>> >> express my concern about the direction it has taken. > >>> >> > >>> >> The Policy Development Process should evaluate technical arguments > on > >>> >> their merits. Whether a participant drafted a message unaided, > >>> >> received > >>> >> editorial assistance, or used modern writing tools does not > determine > >>> >> whether the reasoning is sound. Speculating about authorship instead > >>> >> of > >>> >> addressing the substance risks distracting the Working Group from > the > >>> >> policy questions before it. > >>> >> > >>> >> I am also concerned by suggestions that contributions should be > >>> >> disregarded simply because of assumptions about how they were > >>> >> written. If > >>> >> there are factual or technical errors, they should be identified and > >>> >> discussed. That is how consensus is strengthened. > >>> >> > >>> >> The questions raised by several participants remain legitimate > >>> >> subjects > >>> >> for technical debate: whether the proposal has demonstrated > >>> >> operational > >>> >> necessity, whether the proposed intervention is proportionate, and > >>> >> whether > >>> >> less restrictive alternatives have been adequately considered. > >>> >> > >>> >> I therefore encourage all participants to continue engaging with the > >>> >> substance of the proposal while maintaining the respectful and > >>> >> professional > >>> >> standards expected within the PDWG. > >>> >> > >>> >> Kind regards, > >>> >> > >>> >> Fundiswa Nadia Maseko > >>> >> > >>> >> > >>> >> _______________________________________________ > >>> >> RPD mailing list > >>> >> RPD at afrinic.net > >>> >> https://lists.afrinic.net/mailman/listinfo/rpd > >>> >> > >>> >> > >>> > >>> > _______________________________________________ > >>> > RPD mailing list > >>> > RPD at afrinic.net > >>> > https://lists.afrinic.net/mailman/listinfo/rpd > >>> -------------- next part -------------- > >>> An HTML attachment was scrubbed... > >>> URL: < > >>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260719/3805216e/attachment-0001.html > >>> > > >>> > >>> ------------------------------ > >>> > >>> Message: 2 > >>> Date: Sun, 19 Jul 2026 18:34:04 +0000 > >>> From: Saul Stein > >>> To: Hendrik Visage , Fundiswa Nadia Maseko > >>> > >>> Cc: "rpd at afrinic.net" > >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >>> Message-ID: > >>> < > >>> > JNAP275MB125812327DC4FFF2404C216E8EC42 at JNAP275MB1258.ZAFP275.PROD.OUTLOOK.COM > >>> > > >>> > >>> Content-Type: text/plain; charset="utf-8" > >>> > >>> Dear all, > >>> Well, I have just finished my popcorn? sadly there wasn?t enough to > read > >>> the bombardment of emails, so I didn?t. > >>> > >>> What I did see though, was a number of non-original / cvopy and paste > >>> objections. Not only that, but more importantly, they do not raise any > >>> valid concerns about the proposal that has reached final call. > >>> > >>> So with that in mind, I fully support this proposal. > >>> > >>> I?d have to be part of a community group where you have to have a valid > >>> NIC to post? > >>> > >>> Regards > >>> Saul > >>> > >>> > >>> From: Hendrik Visage via RPD > >>> Sent: Sunday, 19 July 2026 20:25 > >>> To: Fundiswa Nadia Maseko > >>> Cc: rpd at afrinic.net > >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >>> > >>> > >>> Dear Fundiswa, > >>> > >>> ?Has the proposal demonstrated mandatory naming is the least > restrictive > >>> solution?" ? Yes, > >>> > >>> "Do you disagree that hierarchical naming authenticates object creation > >>> rather than membership accuracy?" ? No. > >>> > >>> These are the specific answers requested. > >>> If you still oppose this proposal, we ask that you engage these answers > >>> first ? in particular the deployment-coordination asymmetry raised ? > >>> instead of repeating the original objections without technical > substances > >>> > >>> ________________________________ > >>> > >>> 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 > >>> > >>> On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: > >>> Dear Ben, > >>> > >>> Thank you for your response. > >>> > >>> Respectfully, I believe it is more productive to address the arguments > >>> themselves than to make assumptions about the people presenting them > or the > >>> tools they may have used. > >>> > >>> If you believe the objections are technically incorrect, I would > >>> appreciate it if you could identify which specific points you disagree > >>> with. For example, do you disagree that hierarchical naming > authenticates > >>> object creation rather than the accuracy of object membership? Or do > you > >>> believe the proposal has demonstrated that mandatory naming is the > least > >>> restrictive solution available? > >>> > >>> Those are technical questions that can be examined and debated. > >>> Dismissing opposing views as "AI bots" does not, on its own, explain > why > >>> the arguments are wrong. > >>> I believe the PDWG benefits most when participants engage with the > >>> substance of each other's reasoning, regardless of how a contribution > was > >>> drafted. > >>> > >>> > >>> Kind regards, > >>> Fundiswa Nadia Maseko > >>> > >>> On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, < > >>> ben.roberts at afrinic.net> wrote: > >>> Fundiswa, > >>> But the AI bots opposing the AS-SET policy aren?t making technical > >>> arguments. They are just regurgitating and re-using the same script. > None > >>> of them seem to know or care what an AS-SET is, or what network owners > use > >>> them for. > >>> > >>> Cheers, > >>> Ben > >>> Sent from my iPhone > >>> > >>> > >>> On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko < > >>> fundiswanadia2 at gmail.com> wrote: > >>> ? > >>> > >>> Dear PDWG, > >>> > >>> I have been following this discussion with interest, and I would like > to > >>> express my concern about the direction it has taken. > >>> > >>> The Policy Development Process should evaluate technical arguments on > >>> their merits. Whether a participant drafted a message unaided, received > >>> editorial assistance, or used modern writing tools does not determine > >>> whether the reasoning is sound. Speculating about authorship instead of > >>> addressing the substance risks distracting the Working Group from the > >>> policy questions before it. > >>> > >>> I am also concerned by suggestions that contributions should be > >>> disregarded simply because of assumptions about how they were written. > If > >>> there are factual or technical errors, they should be identified and > >>> discussed. That is how consensus is strengthened. > >>> > >>> The questions raised by several participants remain legitimate subjects > >>> for technical debate: whether the proposal has demonstrated operational > >>> necessity, whether the proposed intervention is proportionate, and > whether > >>> less restrictive alternatives have been adequately considered. > >>> > >>> I therefore encourage all participants to continue engaging with the > >>> substance of the proposal while maintaining the respectful and > professional > >>> standards expected within the PDWG. > >>> > >>> Kind regards, > >>> > >>> Fundiswa Nadia Maseko > >>> > >>> > >>> _______________________________________________ > >>> RPD mailing list > >>> RPD at afrinic.net > >>> https://lists.afrinic.net/mailman/listinfo/rpd< > >>> https://lists.afrinic.net/mailman/listinfo/rpd> > >>> > >>> _______________________________________________ > >>> RPD mailing list > >>> RPD at afrinic.net > >>> https://lists.afrinic.net/mailman/listinfo/rpd< > >>> https://lists.afrinic.net/mailman/listinfo/rpd> > >>> -------------- next part -------------- > >>> An HTML attachment was scrubbed... > >>> URL: < > >>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260719/f1cb5a98/attachment.html > >>> > > >>> > >>> ------------------------------ > >>> > >>> Subject: Digest Footer > >>> > >>> _______________________________________________ > >>> RPD mailing list > >>> RPD at afrinic.net > >>> https://lists.afrinic.net/mailman/listinfo/rpd > >>> > >>> > >>> ------------------------------ > >>> > >>> End of RPD Digest, Vol 222, Issue 71 > >>> ************************************ > >>> > >>> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/ef93f424/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 80 > ************************************ > -- Onica N. Makwakwa Executive Director p +27 63 237 3050 (WhatsApp/Signal) @ AfroDiva w globaldigitalinclusion.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From ST10120874 at vcconnect.edu.za Mon Jul 20 08:44:58 2026 From: ST10120874 at vcconnect.edu.za (Mphoentle Mokheseng) Date: Mon, 20 Jul 2026 08:44:58 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Hi Jaco, Your argument creates a false choice: either support the proposal or be suspected of enabling attacks. That is not fair, and it is not how consensus should be assessed. Your operational example is useful evidence. It does not give anyone authority to assign motives to objectors or to treat operator experience as a mandate over the whole process. The question is not whether hierarchical naming can help. It can. The question is whether that benefit justifies mandatory registry policy, and whether the scope and consequences have been properly tested. Please address the objection without turning disagreement into suspicion. I remain opposed. Regards, Mphoentle Disclaimer This email and the information contained herein are Advtech Ltd confidential and are protected by law. Please navigate to our website for more information https://www.groupadvtech.com. Use of this information or this email by any person for any purposes other than that for which it is intended is prohibited and may result in civil and/or criminal liability. This email is not to be shared with any 3rd parties not included within this email, without the written consent of its Author. If you have received this message in error, please notify Advtech immediately, telephone number +27 11 676 8000. Advtech leads the private sector in the fields of education and resourcing, contributing meaningfully towards the sustainable development of human capacity in South Africa. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Mon Jul 20 08:45:07 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Mon, 20 Jul 2026 10:45:07 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 76 In-Reply-To: References: Message-ID: Hi Frank, Certainly. One technical argument is that hierarchical naming improves the uniqueness of AS-SET names, but it does not verify the correctness, authorization, or currency of the routing information contained within those AS-SET objects. As a result, while the proposal may reduce namespace collisions, it does not address the accuracy of the routing policy data that operators ultimately rely on when generating filters. That is a technical observation about the scope and limitations of the mechanism being proposed. From there, the policy question is whether that improvement, on its own, justifies making hierarchical naming mandatory. Regards, Fundiswa Nadia Maseko On Mon, 20 Jul 2026, 00:17 Fundiswa Nadia Maseko, wrote: > Dear Frank, > > Thank you for your response. > > I disagree with your conclusion that opponents have presented no technical > arguments. Whether an argument is ultimately persuasive is different from > whether it is technical. > > My point remains that hierarchical naming may reduce namespace collisions, > but it does not verify that the contents of an AS-SET are accurate, > current, or authorised. The correctness of generated filters still depends > on the quality of the underlying registry data. That is a technical > limitation of what the proposal can achieve. > > Likewise, the assertion that the proposal improves stability is a claim > that should be supported by technical reasoning and operational evidence. > Explaining what failures are prevented, what risks remain, and why this is > the least restrictive solution would strengthen that case. > > My intention is not to dismiss the proposal, but to test whether it has > been sufficiently justified. That is an important part of the policy > development process. Reasonable people may disagree on the answers, but I > do not believe that makes the questions themselves any less technical. > > > Kind regards, > > Fundiswa Nadia Maseko > > > > On Sun, 19 Jul 2026, 21:38 , wrote: > >> Send RPD mailing list submissions to >> rpd at afrinic.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.afrinic.net/mailman/listinfo/rpd >> or, via email, send a message with subject or body 'help' to >> rpd-request at afrinic.net >> >> You can reach the person managing the list at >> rpd-owner at afrinic.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of RPD digest..." >> >> >> Today's Topics: >> >> 1. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Frank Habicht) >> 2. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Gugu Dhlamini) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Sun, 19 Jul 2026 22:30:01 +0300 >> From: Frank Habicht >> To: rpd at afrinic.net >> Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> Message-ID: >> Content-Type: text/plain; charset=UTF-8; format=flowed >> >> Hi, >> >> inline ... >> >> On 7/19/2026 7:55 PM, Fundiswa Nadia Maseko wrote: >> > *Dear PDWG,* >> > >> > I have been following this discussion with interest, and I would like >> to >> > express my concern about the direction it has taken. >> >> Sorry. I'm just trying to ppoint out that I don't consider some argument >> to be good arguments. >> >> > The Policy Development Process should evaluate technical arguments on >> > their merits. >> >> Honestly, I've seen a lot of claimed so-called "technical arguments". I >> haven't seen anything I would call technical arguments from the >> opponents of the policy. Can you give one using technical facts? >> >> [snip] >> > I am also concerned by suggestions that contributions should be >> > disregarded simply because of assumptions about how they were written. >> >> I'm assuming you refer to this: >> >> This also relates to the broader ?stability fallacy?: the assumption >> >> that more structure, more policy, or more institutional mechanisms >> >> necessarily create more stability. >> > >> > For those that understand what is proposed, we also understand that >> > this >> > creates more stability and it is not an assumption. >> > >> > Please don't assume that we are assuming. >> >> You see how this was not about "how they were written". It was about >> Gugu Dhlamini calling the argument for the policy an assumption, which >> is incorrect. >> >> It is very uncool to call a technical argument an assumption. >> It is also required then to call-out this incorrectness. >> And you mixing these up and misrepresenting is also not good. >> >> >> >> > If there are factual or technical errors, they should be identified and >> > discussed. That is how consensus is strengthened. >> >> you would have mentioned any factual or technical errors if you would >> have found one. You haven't. >> >> I just have to conclude you don't want to understand. >> >> But the policy process here should know that you didn't have any >> arguments. >> >> Regards, >> Frank >> again, all typed myself ;-) >> >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Sun, 19 Jul 2026 21:37:18 +0200 >> From: Gugu Dhlamini >> To: Fundiswa Nadia Maseko >> Cc: rpd at afrinic.net >> Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> Message-ID: >> > w at mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Hi Saul, >> >> Yes, the message was sent twice. That is a posting mistake, not a policy >> argument. >> >> Focusing on duplicate delivery while ignoring the substance is exactly how >> process starts replacing discussion. Please address the objection itself >> rather than using a technical error as a reason to dismiss participation. >> >> Regards, >> Gugu >> >> On Sun, 19 Jul 2026, 9:29 pm Fundiswa Nadia Maseko < >> fundiswanadia2 at gmail.com> >> wrote: >> >> > Thank you for pointing that out. >> > >> > The two emails were intended for different purposes. The first was a >> > direct response to Hendrik's points, while the second was addressed to >> the >> > broader discussion, including your comments and the wider issue that had >> > developed on the mailing list. >> > >> > I understand they were sent close together, which may have made them >> > appear to be duplicates, but they were intended as separate responses. >> > >> > Kind regards, >> > >> > Fundiswa Nadia Maseko >> > >> > >> > >> > On Sun, 19 Jul 2026, 21:20 Saul Stein, wrote: >> > >> >> Hi >> >> >> >> you have now posted the email twice 7 minutes apart? >> >> >> >> >> >> >> >> >> >> >> >> *From:* Fundiswa Nadia Maseko >> >> *Sent:* Sunday, 19 July 2026 20:46 >> >> *To:* rpd at afrinic.net >> >> *Subject:* Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical >> >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> >> >> >> >> >> >> >> Dear Hendrik, Saul, and colleagues, >> >> >> >> >> >> >> >> Thank you for your responses. >> >> >> >> >> >> >> >> I would also like to address the recurring comments about AI-generated >> >> contributions. >> >> >> >> >> >> >> >> Whether someone uses AI to improve grammar, structure, or clarity does >> >> not, in itself, determine whether their arguments are valid. AI only >> works >> >> with the information and instructions provided by the person using it. >> Many >> >> people use it as a writing assistant to communicate their ideas more >> >> clearly, just as others may ask a colleague to proofread or edit a >> draft >> >> before sending it. >> >> >> >> >> >> >> >> For that reason, I do not believe the discussion should focus on how a >> >> message was written, but rather on whether the technical reasoning is >> >> correct or incorrect. >> >> >> >> >> >> >> >> With regard to the proposal itself, I appreciate Hendrik's direct >> >> answers. However, simply answering "yes" or "no" does not, by itself, >> >> explain the technical reasoning behind those conclusions. It would be >> >> helpful to understand why the proposal is considered the least >> restrictive >> >> solution and how the identified operational benefits outweigh the >> >> additional policy requirements. That explanation would assist everyone >> in >> >> evaluating the proposal on its technical merits. >> >> >> >> >> >> >> >> I believe the PDWG is strongest when differing views are examined >> through >> >> technical discussion supported by evidence, rather than assumptions >> about >> >> who wrote a message or what tools they may have used. >> >> >> >> >> >> >> >> Kind regards, >> >> >> >> >> >> >> >> Fundiswa Nadia Maseko >> >> >> >> >> >> >> >> >> >> >> >> On Sun, 19 Jul 2026, 20:34 , wrote: >> >> >> >> Send RPD mailing list submissions to >> >> rpd at afrinic.net >> >> >> >> To subscribe or unsubscribe via the World Wide Web, visit >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> or, via email, send a message with subject or body 'help' to >> >> rpd-request at afrinic.net >> >> >> >> You can reach the person managing the list at >> >> rpd-owner at afrinic.net >> >> >> >> When replying, please edit your Subject line so it is more specific >> >> than "Re: Contents of RPD digest..." >> >> >> >> >> >> Today's Topics: >> >> >> >> 1. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names >> >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage) >> >> 2. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names >> >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Saul Stein) >> >> >> >> >> >> ---------------------------------------------------------------------- >> >> >> >> Message: 1 >> >> Date: Sun, 19 Jul 2026 20:25:00 +0200 >> >> From: Hendrik Visage >> >> To: Fundiswa Nadia Maseko >> >> Cc: rpd at afrinic.net >> >> Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical >> >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> >> Message-ID: <24327C8E-E411-4D2F-BE55-F250691CD720 at hevis.co.za> >> >> Content-Type: text/plain; charset="utf-8"; Format="flowed" >> >> >> >> Dear Fundiswa, >> >> >> >> ?Has the proposal demonstrated mandatory naming is the least >> >> restrictive solution?" ? Yes, >> >> >> >> "Do you disagree that hierarchical naming authenticates object creation >> >> rather than membership accuracy?" ? No. >> >> >> >> These are the specific answers requested. >> >> If you still oppose this proposal, we ask that you engage these answers >> >> first ? in particular the deployment-coordination asymmetry raised ? >> >> instead of repeating the original objections without technical >> >> substances >> >> >> >> --- >> >> 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 >> >> >> >> On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: >> >> >> >> > Dear Ben, >> >> > >> >> > Thank you for your response. >> >> > >> >> > Respectfully, I believe it is more productive to address the >> arguments >> >> > themselves than to make assumptions about the people presenting them >> >> > or the >> >> > tools they may have used. >> >> > >> >> > If you believe the objections are technically incorrect, I would >> >> > appreciate >> >> > it if you could identify which specific points you disagree with. For >> >> > example, do you disagree that hierarchical naming authenticates >> object >> >> > creation rather than the accuracy of object membership? Or do you >> >> > believe >> >> > the proposal has demonstrated that mandatory naming is the least >> >> > restrictive solution available? >> >> > >> >> > Those are technical questions that can be examined and debated. >> >> > Dismissing >> >> > opposing views as "AI bots" does not, on its own, explain why the >> >> > arguments >> >> > are wrong. >> >> > I believe the PDWG benefits most when participants engage with the >> >> > substance of each other's reasoning, regardless of how a contribution >> >> > was >> >> > drafted. >> >> > >> >> > >> >> > Kind regards, >> >> > Fundiswa Nadia Maseko >> >> > >> >> > On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, >> >> > >> >> > wrote: >> >> > >> >> >> Fundiswa, >> >> >> But the AI bots opposing the AS-SET policy aren?t making technical >> >> >> arguments. They are just regurgitating and re-using the same script. >> >> >> None >> >> >> of them seem to know or care what an AS-SET is, or what network >> >> >> owners use >> >> >> them for. >> >> >> >> >> >> Cheers, >> >> >> Ben >> >> >> Sent from my iPhone >> >> >> >> >> >> On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko >> >> >> >> >> >> wrote: >> >> >> >> >> >> ? >> >> >> >> >> >> *Dear PDWG,* >> >> >> >> >> >> I have been following this discussion with interest, and I would >> like >> >> >> to >> >> >> express my concern about the direction it has taken. >> >> >> >> >> >> The Policy Development Process should evaluate technical arguments >> on >> >> >> their merits. Whether a participant drafted a message unaided, >> >> >> received >> >> >> editorial assistance, or used modern writing tools does not >> determine >> >> >> whether the reasoning is sound. Speculating about authorship instead >> >> >> of >> >> >> addressing the substance risks distracting the Working Group from >> the >> >> >> policy questions before it. >> >> >> >> >> >> I am also concerned by suggestions that contributions should be >> >> >> disregarded simply because of assumptions about how they were >> >> >> written. If >> >> >> there are factual or technical errors, they should be identified and >> >> >> discussed. That is how consensus is strengthened. >> >> >> >> >> >> The questions raised by several participants remain legitimate >> >> >> subjects >> >> >> for technical debate: whether the proposal has demonstrated >> >> >> operational >> >> >> necessity, whether the proposed intervention is proportionate, and >> >> >> whether >> >> >> less restrictive alternatives have been adequately considered. >> >> >> >> >> >> I therefore encourage all participants to continue engaging with the >> >> >> substance of the proposal while maintaining the respectful and >> >> >> professional >> >> >> standards expected within the PDWG. >> >> >> >> >> >> Kind regards, >> >> >> >> >> >> Fundiswa Nadia Maseko >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> >> RPD mailing list >> >> >> RPD at afrinic.net >> >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> >> >> >> >> >> >> > _______________________________________________ >> >> > RPD mailing list >> >> > RPD at afrinic.net >> >> > https://lists.afrinic.net/mailman/listinfo/rpd >> >> -------------- next part -------------- >> >> An HTML attachment was scrubbed... >> >> URL: < >> >> >> https://lists.afrinic.net/pipermail/rpd/attachments/20260719/3805216e/attachment-0001.html >> >> > >> >> >> >> ------------------------------ >> >> >> >> Message: 2 >> >> Date: Sun, 19 Jul 2026 18:34:04 +0000 >> >> From: Saul Stein >> >> To: Hendrik Visage , Fundiswa Nadia Maseko >> >> >> >> Cc: "rpd at afrinic.net" >> >> Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical >> >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> >> Message-ID: >> >> < >> >> >> JNAP275MB125812327DC4FFF2404C216E8EC42 at JNAP275MB1258.ZAFP275.PROD.OUTLOOK.COM >> >> > >> >> >> >> Content-Type: text/plain; charset="utf-8" >> >> >> >> Dear all, >> >> Well, I have just finished my popcorn? sadly there wasn?t enough to >> read >> >> the bombardment of emails, so I didn?t. >> >> >> >> What I did see though, was a number of non-original / cvopy and paste >> >> objections. Not only that, but more importantly, they do not raise any >> >> valid concerns about the proposal that has reached final call. >> >> >> >> So with that in mind, I fully support this proposal. >> >> >> >> I?d have to be part of a community group where you have to have a valid >> >> NIC to post? >> >> >> >> Regards >> >> Saul >> >> >> >> >> >> From: Hendrik Visage via RPD >> >> Sent: Sunday, 19 July 2026 20:25 >> >> To: Fundiswa Nadia Maseko >> >> Cc: rpd at afrinic.net >> >> Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical >> Names >> >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> >> >> >> >> >> Dear Fundiswa, >> >> >> >> ?Has the proposal demonstrated mandatory naming is the least >> restrictive >> >> solution?" ? Yes, >> >> >> >> "Do you disagree that hierarchical naming authenticates object creation >> >> rather than membership accuracy?" ? No. >> >> >> >> These are the specific answers requested. >> >> If you still oppose this proposal, we ask that you engage these answers >> >> first ? in particular the deployment-coordination asymmetry raised ? >> >> instead of repeating the original objections without technical >> substances >> >> >> >> ________________________________ >> >> >> >> 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 >> >> >> >> On 19 Jul 2026, at 19:54, Fundiswa Nadia Maseko wrote: >> >> Dear Ben, >> >> >> >> Thank you for your response. >> >> >> >> Respectfully, I believe it is more productive to address the arguments >> >> themselves than to make assumptions about the people presenting them >> or the >> >> tools they may have used. >> >> >> >> If you believe the objections are technically incorrect, I would >> >> appreciate it if you could identify which specific points you disagree >> >> with. For example, do you disagree that hierarchical naming >> authenticates >> >> object creation rather than the accuracy of object membership? Or do >> you >> >> believe the proposal has demonstrated that mandatory naming is the >> least >> >> restrictive solution available? >> >> >> >> Those are technical questions that can be examined and debated. >> >> Dismissing opposing views as "AI bots" does not, on its own, explain >> why >> >> the arguments are wrong. >> >> I believe the PDWG benefits most when participants engage with the >> >> substance of each other's reasoning, regardless of how a contribution >> was >> >> drafted. >> >> >> >> >> >> Kind regards, >> >> Fundiswa Nadia Maseko >> >> >> >> On Sun, 19 Jul 2026, 19:13 Ben Roberts - AfriNIC, < >> >> ben.roberts at afrinic.net> wrote: >> >> Fundiswa, >> >> But the AI bots opposing the AS-SET policy aren?t making technical >> >> arguments. They are just regurgitating and re-using the same script. >> None >> >> of them seem to know or care what an AS-SET is, or what network owners >> use >> >> them for. >> >> >> >> Cheers, >> >> Ben >> >> Sent from my iPhone >> >> >> >> >> >> On 19 Jul 2026, at 17:56, Fundiswa Nadia Maseko < >> fundiswanadia2 at gmail.com >> >> > wrote: >> >> ? >> >> >> >> Dear PDWG, >> >> >> >> I have been following this discussion with interest, and I would like >> to >> >> express my concern about the direction it has taken. >> >> >> >> The Policy Development Process should evaluate technical arguments on >> >> their merits. Whether a participant drafted a message unaided, received >> >> editorial assistance, or used modern writing tools does not determine >> >> whether the reasoning is sound. Speculating about authorship instead of >> >> addressing the substance risks distracting the Working Group from the >> >> policy questions before it. >> >> >> >> I am also concerned by suggestions that contributions should be >> >> disregarded simply because of assumptions about how they were written. >> If >> >> there are factual or technical errors, they should be identified and >> >> discussed. That is how consensus is strengthened. >> >> >> >> The questions raised by several participants remain legitimate subjects >> >> for technical debate: whether the proposal has demonstrated operational >> >> necessity, whether the proposed intervention is proportionate, and >> whether >> >> less restrictive alternatives have been adequately considered. >> >> >> >> I therefore encourage all participants to continue engaging with the >> >> substance of the proposal while maintaining the respectful and >> professional >> >> standards expected within the PDWG. >> >> >> >> Kind regards, >> >> >> >> Fundiswa Nadia Maseko >> >> >> >> >> >> _______________________________________________ >> >> RPD mailing list >> >> RPD at afrinic.net >> >> https://lists.afrinic.net/mailman/listinfo/rpd< >> >> https://lists.afrinic.net/mailman/listinfo/rpd> >> >> >> >> _______________________________________________ >> >> RPD mailing list >> >> RPD at afrinic.net >> >> https://lists.afrinic.net/mailman/listinfo/rpd< >> >> https://lists.afrinic.net/mailman/listinfo/rpd> >> >> -------------- next part -------------- >> >> An HTML attachment was scrubbed... >> >> URL: < >> >> >> https://lists.afrinic.net/pipermail/rpd/attachments/20260719/f1cb5a98/attachment.html >> >> > >> >> >> >> ------------------------------ >> >> >> >> Subject: Digest Footer >> >> >> >> _______________________________________________ >> >> RPD mailing list >> >> RPD at afrinic.net >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> >> >> ------------------------------ >> >> >> >> End of RPD Digest, Vol 222, Issue 71 >> >> ************************************ >> >> >> >> _______________________________________________ >> > RPD mailing list >> > RPD at afrinic.net >> > https://lists.afrinic.net/mailman/listinfo/rpd >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> https://lists.afrinic.net/pipermail/rpd/attachments/20260719/f73a0e8b/attachment.html >> > >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ------------------------------ >> >> End of RPD Digest, Vol 222, Issue 76 >> ************************************ >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mselekuthandeka80 at gmail.com Mon Jul 20 08:50:28 2026 From: mselekuthandeka80 at gmail.com (Thandeka Mseleku) Date: Mon, 20 Jul 2026 10:50:28 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Hi Frank, The issue is not whether the proposal offers any benefit. The issue is whether that benefit belongs in mandatory registry policy. A useful convention can remain useful without becoming compulsory. Policy should be reserved for what running networks genuinely require, not every improvement a working group prefers. Questioning that boundary is not looking for excuses. It is exactly what last call is for. I remain opposed. Regards, Thandeka -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.medoye at gmail.com Mon Jul 20 09:08:56 2026 From: daniel.medoye at gmail.com (Taye Medoye) Date: Mon, 20 Jul 2026 11:08:56 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Whereas the Organization?s guideline on Policy Scope & Exclusions permits any desired alteration or amendment to an existing policy framework, it is required that such an exercise would require critical deliberations and discussion to ensure a convincing and realistic position for the proposed policy change or amendment to stand the test of time. This view also aligns with the policy statement which guarantees *that Number Resource management policies are developed through an open Policy Development Process (PDP).* In regard to the draft Policy proposal on bordering on the above captioned subject-matter, projected for discussions on the Forum, l have taken note of the justifiable rationale which forbids the unauthorized creation of names that could lead to either a flat or arbitrary name, and its consequences of potential squatting or accidental overlaps; and the fact that the requirement currently applies strictly to AS-SET objects to the exclusion of other IRR objects. I have equally taken note that the AFPUB-2026-ASN-001-DRAFT02 requires newly created AS-SETs to use hierarchical naming to avoid name collisions and improve route filtering, the fact remains that any alteration or amendment or new creation to existing policy framework would need to be subjected to extensive discussions as is the guideline on this forum. Therefore, l hereby object to a creation of names as is being proposed subject to alternative and more acceptable rationale that necessitates acceptance of the proposal. *Daniel Taye Medoye* -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah at neo.co.tz Mon Jul 20 09:16:34 2026 From: noah at neo.co.tz (Noah) Date: Mon, 20 Jul 2026 12:16:34 +0300 Subject: [rpd] Request to Pause the AI generated posting In-Reply-To: <47c7fa89-2925-459b-a454-e92cd87e07ea@uls.co.za> References: <47c7fa89-2925-459b-a454-e92cd87e07ea@uls.co.za> Message-ID: On Mon, 20 Jul 2026, 11:28?am Jaco Kroon via RPD, wrote: > Mphoentle, Tshepo, Paulo, Nthabiesng, Thandeka, Thulisile, > Nia, Asamkele, Nonhlanhla > > Folks The PDWG has had enough of your posts. Can I kindly request that you pause your AI generated posts for now so as to reduce traffic on rpd list. Cheers, Noah > -------------- next part -------------- An HTML attachment was scrubbed... URL: From geier at geier.ne.tz Mon Jul 20 09:23:58 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Mon, 20 Jul 2026 12:23:58 +0300 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: <7b2ad64d-fd0a-4d29-b616-5234b94de87f@geier.ne.tz> Hi, On 7/20/2026 12:08 PM, Taye Medoye wrote: [snip] > Therefore, l hereby object to a creation of names as is being proposed > subject to alternative and more acceptable rationale that necessitates > acceptance of the proposal. It is OK to object to the creation of names. Nobody forces you to do that. But it is also true that others are already allowed to create these names. I think 34 exist. Frank From phetulodhlamini at gmail.com Mon Jul 20 09:31:28 2026 From: phetulodhlamini at gmail.com (Phetulo Dhlamini) Date: Mon, 20 Jul 2026 11:31:28 +0200 Subject: [rpd] Request to Pause the AI generated posting Message-ID: Hi Noah, You don?t speak for the whole PDWG . People disagreeing is not a reason to silence people . The chairs might run the process, but no individual participant gets to decide whose contributions the community is ?tired of.? Stick to the matter, not the person talking. Obedience is not engagement. Kind regards, Phetulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From phetulodhlamini at gmail.com Mon Jul 20 09:33:32 2026 From: phetulodhlamini at gmail.com (Phetulo Dhlamini) Date: Mon, 20 Jul 2026 11:33:32 +0200 Subject: [rpd] Request to Pause the AI generated posting In-Reply-To: References: <47c7fa89-2925-459b-a454-e92cd87e07ea@uls.co.za> Message-ID: Hi Noah, You don?t speak for the whole PDWG . People disagreeing is not a reason to silence people . The chairs might run the process, but no individual participant gets to decide whose contributions the community is ?tired of.? Stick to the matter, not the person talking. Obedience is not engagement. Kind regards, Phetulo On Mon, 20 Jul 2026, 11:17 Noah, wrote: > > On Mon, 20 Jul 2026, 11:28?am Jaco Kroon via RPD, wrote: > >> Mphoentle, Tshepo, Paulo, Nthabiesng, Thandeka, Thulisile, >> Nia, Asamkele, Nonhlanhla >> >> Folks > > The PDWG has had enough of your posts. > > Can I kindly request that you pause your AI generated posts for now so as > to reduce traffic on rpd list. > > Cheers, > Noah > >> _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Mon Jul 20 08:30:54 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Mon, 20 Jul 2026 10:30:54 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 In-Reply-To: <95592897-0d54-4f5f-b5f8-cd918dd51c24@posix.co.za> References: <1783459420709.11832@tra.gov.eg> <95592897-0d54-4f5f-b5f8-cd918dd51c24@posix.co.za> Message-ID: <51f0a40c-f6f3-4d84-9c5b-ea883fb2b28f@uls.co.za> Hi, I'm going to state this again - I support the principle but not the implementation. Specifically the way in which this links IPv4 requests to IPv6 *traffic levels* as a percentage, rather than percentage of network to which IPv6 has been deployed. I'm unable to sensibly force my customers to consume IPv6, no matter what.? Further - we host a bunch of content which due to lack of external IPv6 deployment (specifically on MNO networks) brings down our overall level of network IPv6 thresholds.? This in spite of but one single /29 subnet (which communicates exclusively with MNO networks, this might change in the next month, thus deploying IPv6 here until now made no sense, and this little subnet single-handedly carries around 5% of our ingress and ~30% of our egress bandwidth). As written this policy punishes network operators for bad behaviour of others, be it other access networks, or customers. It also adds significant additional costs towards otherwise needless network monitoring that would otherwise not be required. Again, to be clear:? I'm in full support of the principle of linking IPv4 allocations/assignments to IPv6 deployment, I simply disagree with how it should be measured. Traffic levels are not a good measure.? If 50% of my network is capable of IPv6, and 50% of content being accessed, or 50% of of eyeballs accessing my network are IPv6 capable, that puts my general IPv6 network levels around 25%, depending on exact patterns, possibly a bit higher, but no higher than 50%.? Now our ability to access IPv4 resources is being limited by *others's* IPv6 deployment rather than merely our own. This should be measured as: What percentage of existing deployed IPv4 resources on the network also has IPv6 deployed in the case of content provisioning, and has access to IPv6 for downstream networks. For us the former percentage, having somewhere between a /22 and /23 provisioned for *services*, so let's work on a /23 or about 512 IPs with only a /29 not being IPv6 enabled as of right now is 98.5%, however, traffic patterns on access shows less than 5% of actual traffic is IPv6. For the latter, 100% of downstream customers/networks has *access* to IPv6.? On customers using ppp less than 5% are consuming IPv6. At least a portion of these configures IPv6 LL (just over 30%). Once that happens we do actively send RAs to provoke configuration. For AE customers (Or "DHCP Customers") things looked better, as of right now we've got? 43% active IPv6 customers (which shows that consumer routers are more inclined to grab IPv6 on "DHCP uplinks compared to PPP", however, this percentage used to be closer to 96%, as customers are *actively against recommendation insisting on switching OFF IPv6*. Whilst we are pushing we cannot prescribe to customers to keep IPv6 enabled - they'll simply move their business elsewhere if we push, thus this policy - as written - creates a significant operational issue. Kind regards, Jaco On 2026/07/19 11:26, Mark Elkins via RPD wrote: > Dear PDWG, > > I have two major concerns regarding the Internet in Africa. > > 1 - Lack of DNSSEC - for DNS security > > 2 - Lack of IPv6 - for growth > > I run something called the Observatory - > https://observatory.dnsstudy.africa - which has in the past collected > information such as how many domains there are, are they DNSSEC Signed > and are they IPv6 accessible. > > So I want Domain content to be IPv6 Accessible... > > ISP's need to have IPv6 resources, they need to make sure that all > content has IPv6 - so that as end users access that content, they have > IPv6 access all the way through. IPv6 doesn't use RFC1918 addresses - > all IPv6 addresses are unique. > > We are running out of IPv4. Yes - some resources will still need IPv4 > addresses - so let's stretch what we have out. The IPv4 Soft Landing > proposal helps this stretching process - by forcing IPv6 onto LIR's/ > ISP's. > > So I support the Proposal. It may not be perfect but it will help > shape the African Internet Industry further into the right direction. > > -- > > Mark James ELKINS? -? Posix Systems - (South) Africa > mje at posix.co.za Tel: +27.826010496 > For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Mon Jul 20 09:50:45 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Mon, 20 Jul 2026 11:50:45 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: Dear Daniel, Thank you for the considered note, and for recognising the rationale on squatting and name overlaps as justifiable. One clarification on process: this proposal is DRAFT02 at Last Call, meaning the PDP discussion phases your message calls for have already run their course ? Last Call is their conclusion. The earlier rounds are in the list archive https://lists.afrinic.net/pipermail/rpd/ should they be useful - Reference the first draft call on https://lists.afrinic.net/pipermail/rpd/2026/014746.html You write that you object "subject to alternative and more acceptable rationale." Could you say what specific rationale would move you to acceptance? Happy to address it directly. Regards, Hendrik --- 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 On 20 Jul 2026, at 11:08, Taye Medoye wrote: > Whereas the Organization?s guideline on Policy Scope & Exclusions > permits > any desired alteration or amendment to an existing policy framework, > it is > required that such an exercise would require critical deliberations > and > discussion to ensure a convincing and realistic position for the > proposed > policy change or amendment to stand the test of time. This view also > aligns > with the policy statement which guarantees *that Number Resource > management > policies are developed through an open Policy Development Process > (PDP).* > > In regard to the draft Policy proposal on bordering on the above > captioned > subject-matter, projected for discussions on the Forum, l have taken > note > of the justifiable rationale which forbids the unauthorized creation > of > names that could lead to either a flat or arbitrary name, and its > consequences of potential squatting or accidental overlaps; and the > fact > that the requirement currently applies strictly to AS-SET objects to > the > exclusion of other IRR objects. > > I have equally taken note that the AFPUB-2026-ASN-001-DRAFT02 requires > newly created AS-SETs to use hierarchical naming to avoid name > collisions > and improve route filtering, the fact remains that any alteration or > amendment or new creation to existing policy framework would need to > be > subjected to extensive discussions as is the guideline on this forum. > > Therefore, l hereby object to a creation of names as is being proposed > subject to alternative and more acceptable rationale that necessitates > acceptance of the proposal. > *Daniel Taye Medoye* > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah at neo.co.tz Mon Jul 20 09:55:25 2026 From: noah at neo.co.tz (Noah) Date: Mon, 20 Jul 2026 12:55:25 +0300 Subject: [rpd] Request to Pause the AI generated posting In-Reply-To: References: <47c7fa89-2925-459b-a454-e92cd87e07ea@uls.co.za> Message-ID: On Mon, 20 Jul 2026, 12:33?pm Phetulo Dhlamini, wrote: > Hi Noah, > > You don?t speak for the whole PDWG . People disagreeing is not a reason to > silence people . > You are absolutely right. I dont speak for the PDWG... I made assumption based on offline discussions I have had with an ecosystem that participate in this WG which is really surprised by the coordinated AI posting from your peers who I mentioned earlier. >> Can I kindly request that you pause your AI generated posts for now so as >> to reduce traffic on rpd list. >> > Can i kindly request that you and your peers pause the endless posting for now as we wait for feedback from the co-chairs. Noah > -------------- next part -------------- An HTML attachment was scrubbed... URL: From buba at sowe.me Mon Jul 20 10:01:42 2026 From: buba at sowe.me (Bubacarr Sowe) Date: Mon, 20 Jul 2026 11:01:42 +0100 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <1784239787450.20999@tra.gov.eg> References: <1784239787450.20999@tra.gov.eg> Message-ID: <80a2afb9-07c4-4878-81ff-70f4603080e5@sowe.me> Dear PDWG, I support the adoption of this draft. Hierarchical AS-SETs? solve a problem. We need this and such a draft should be adopted without difficulty. I don't see any benefit in not adapting it. Lets not resist for the sake of resisting but understand why hierarchical AS-SETs are important. MANRS site has more on this here: https://manrs.org/2022/12/why-network-operators-should-use-hierarchical-as-sets/. Please don't load this list with AI puke, its annoying, stupid and the repetitiveness is an eye sore. You may enjoy your AI output? but that may not be the case for most of us, that is for your Facebook post. Mailing lists like this solves real problems and people make decision base on the discussions but if we fill this list with some garbage from ChatGTP or whatever, we will kill the spirit of the discussion, the human engagement and the results that define our community and the internet. Thanks, BS On 16/07/2026 23:09, Hytham El-Nakhal wrote: > Dear PDWG, > > > The Policy Development Working Group (PDWG) Chairs have initiated a Last Call for this proposal, following rough consensus at the AFRINIC-37 Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. > > * Proposal Name: Hierarchical Names for New AS-SETs > > * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > > * Proposal URL:https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > Last Call closes on: July 31, 2026, at 23:59 UTC. > > > 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. > > > As always, we kindly request that all participants adhere to the AFRINIC Code of Conduct to maintain a respectful and professional environment on the mailing list. > > > Kind regards, > > > Haitham el Nakhal > > AFRINIC PDWG Co-Chair > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From mselekuthandeka80 at gmail.com Mon Jul 20 10:23:34 2026 From: mselekuthandeka80 at gmail.com (Thandeka Mseleku) Date: Mon, 20 Jul 2026 12:23:34 +0200 Subject: [rpd] Request to Pause the AI Generated Posting Message-ID: Dear Noah, I respectfully disagree with your request. The Policy Development Process is built on open participation. Contributions should be assessed on their technical and policy merits, not on assumptions about how they were prepared. Not every well-written or similar email is AI-generated. If there are concerns about a contribution, they should be addressed by responding to the arguments themselves rather than discouraging participation. BR, Thandeka Mseleku -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Mon Jul 20 11:54:06 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Mon, 20 Jul 2026 13:54:06 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 91 In-Reply-To: References: Message-ID: Hi Noah, You may disagree with the use of writing tools, but you cannot dictate which tools participants may or may not use. What matters is whether contributors stand behind their submissions and whether the arguments are relevant. As for traffic, an active policy discussion will naturally generate messages. The answer is sensible moderation, threading, and consolidation where appropriate, not asking selected participants to stop speaking. The co-chairs can manage the process. Individual participants do not have a mandate to silence others. Regards, Nonhlanhla On Mon, 20 Jul 2026, 12:02 pm wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage) > 2. Re: Request to Pause the AI generated posting (Noah) > 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Bubacarr Sowe) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 20 Jul 2026 11:50:45 +0200 > From: Hendrik Visage > To: Taye Medoye > Cc: rpd at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Dear Daniel, > > Thank you for the considered note, and for recognising the rationale on > squatting and name overlaps as justifiable. > > One clarification on process: this proposal is DRAFT02 at Last Call, > meaning the PDP discussion phases your message calls for have already > run their course ? Last Call is their conclusion. The earlier rounds > are in the list archive https://lists.afrinic.net/pipermail/rpd/ should > they be useful - Reference the first draft call on > https://lists.afrinic.net/pipermail/rpd/2026/014746.html > > You write that you object "subject to alternative and more acceptable > rationale." Could you say what specific rationale would move you to > acceptance? Happy to address it directly. > Regards, > Hendrik > > --- > 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 > > On 20 Jul 2026, at 11:08, Taye Medoye wrote: > > > Whereas the Organization?s guideline on Policy Scope & Exclusions > > permits > > any desired alteration or amendment to an existing policy framework, > > it is > > required that such an exercise would require critical deliberations > > and > > discussion to ensure a convincing and realistic position for the > > proposed > > policy change or amendment to stand the test of time. This view also > > aligns > > with the policy statement which guarantees *that Number Resource > > management > > policies are developed through an open Policy Development Process > > (PDP).* > > > > In regard to the draft Policy proposal on bordering on the above > > captioned > > subject-matter, projected for discussions on the Forum, l have taken > > note > > of the justifiable rationale which forbids the unauthorized creation > > of > > names that could lead to either a flat or arbitrary name, and its > > consequences of potential squatting or accidental overlaps; and the > > fact > > that the requirement currently applies strictly to AS-SET objects to > > the > > exclusion of other IRR objects. > > > > I have equally taken note that the AFPUB-2026-ASN-001-DRAFT02 requires > > newly created AS-SETs to use hierarchical naming to avoid name > > collisions > > and improve route filtering, the fact remains that any alteration or > > amendment or new creation to existing policy framework would need to > > be > > subjected to extensive discussions as is the guideline on this forum. > > > > Therefore, l hereby object to a creation of names as is being proposed > > subject to alternative and more acceptable rationale that necessitates > > acceptance of the proposal. > > *Daniel Taye Medoye* > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/6a473a32/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Mon, 20 Jul 2026 12:55:25 +0300 > From: Noah > To: Phetulo Dhlamini > Cc: rpd List > Subject: Re: [rpd] Request to Pause the AI generated posting > Message-ID: > mhiUzqY3NcMJ9Q at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Mon, 20 Jul 2026, 12:33?pm Phetulo Dhlamini, > > wrote: > > > Hi Noah, > > > > You don?t speak for the whole PDWG . People disagreeing is not a reason > to > > silence people . > > > > You are absolutely right. I dont speak for the PDWG... > > I made assumption based on offline discussions I have had with an ecosystem > that participate in this WG which is really surprised by the coordinated AI > posting from your peers who I mentioned earlier. > > > > >> Can I kindly request that you pause your AI generated posts for now so > as > >> to reduce traffic on rpd list. > >> > > > Can i kindly request that you and your peers pause the endless posting for > now as we wait for feedback from the co-chairs. > > Noah > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/bcad9913/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Mon, 20 Jul 2026 11:01:42 +0100 > From: Bubacarr Sowe > To: rpd at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: <80a2afb9-07c4-4878-81ff-70f4603080e5 at sowe.me> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Dear PDWG, > > I support the adoption of this draft. > > Hierarchical AS-SETs? solve a problem. We need this and such a draft > should be adopted without difficulty. I don't see any benefit in not > adapting it. > > Lets not resist for the sake of resisting but understand why > hierarchical AS-SETs are important. MANRS site has more on this here: > > https://manrs.org/2022/12/why-network-operators-should-use-hierarchical-as-sets/. > > > > Please don't load this list with AI puke, its annoying, stupid and the > repetitiveness is an eye sore. You may enjoy your AI output? but that > may not be the case for most of us, that is for your Facebook post. > > Mailing lists like this solves real problems and people make decision > base on the discussions but if we fill this list with some garbage from > ChatGTP or whatever, we will kill the spirit of the discussion, the > human engagement and the results that define our community and the > internet. > > Thanks, > > BS > > > On 16/07/2026 23:09, Hytham El-Nakhal wrote: > > Dear PDWG, > > > > > > The Policy Development Working Group (PDWG) Chairs have initiated a Last > Call for this proposal, following rough consensus at the AFRINIC-37 Public > Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. > > > > * Proposal Name: Hierarchical Names for New AS-SETs > > > > * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > > > > * Proposal URL: > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > > > Last Call closes on: July 31, 2026, at 23:59 UTC. > > > > > > 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. > > > > > > As always, we kindly request that all participants adhere to the AFRINIC > Code of Conduct to maintain a respectful > and professional environment on the mailing list. > > > > > > Kind regards, > > > > > > Haitham el Nakhal > > > > AFRINIC PDWG Co-Chair > > > > > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/6bc09152/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 91 > ************************************ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.medoye at gmail.com Mon Jul 20 12:00:47 2026 From: daniel.medoye at gmail.com (Taye Medoye) Date: Mon, 20 Jul 2026 14:00:47 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: Dear Hendrik, Thank you for your feedback. Your updates that the PDP discussion phases, wherein my message provided a response had already run their course, are noted. As l indicated in my message with the caveat ? subject to alternative and more acceptable rationale, for which you require to know what, will undo or weaken my objection, l will respond as follows: I understand that any proposed policy creation is expected to pay attention to concerns of Security and Alignment, etc. With specific reference to security, it is understood that unauthorized creation or a change, resulting in flat or arbitrary AS-SET names can lead to potential squatting or accidental overlaps. I guess such an error should be avoided. Secondly, l am inclined to bother that any proposed policy creation, in terms of name-change, must reflect global alignment. In other words, if the creation or name change aligns AFRINIC with best practices already established in other RIR streamlining global IRR data consumption, then my object-position could be swayed without further reservations. *Daniel Taye Medoye* NB This mail had earlier been sent to Hendrik Visage, as forwarded below. On Mon, 20 Jul 2026 at 11:50, Hendrik Visage wrote: > Dear Daniel, > > Thank you for the considered note, and for recognising the rationale on > squatting and name overlaps as justifiable. > > One clarification on process: this proposal is DRAFT02 at Last Call, > meaning the PDP discussion phases your message calls for have already run > their course ? Last Call is their conclusion. The earlier rounds are in the > list archive https://lists.afrinic.net/pipermail/rpd/ should they be > useful - Reference the first draft call on > https://lists.afrinic.net/pipermail/rpd/2026/014746.html > > You write that you object "subject to alternative and more acceptable > rationale." Could you say what specific rationale would move you to > acceptance? Happy to address it directly. > Regards, > Hendrik > ------------------------------ > > 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 > > On 20 Jul 2026, at 11:08, Taye Medoye wrote: > > Whereas the Organization?s guideline on Policy Scope & Exclusions permits > any desired alteration or amendment to an existing policy framework, it is > required that such an exercise would require critical deliberations and > discussion to ensure a convincing and realistic position for the proposed > policy change or amendment to stand the test of time. This view also > aligns with the policy statement which guarantees *that Number Resource > management policies are developed through an open Policy Development > Process (PDP).* > > In regard to the draft Policy proposal on bordering on the above captioned > subject-matter, projected for discussions on the Forum, l have taken note > of the justifiable rationale which forbids the unauthorized creation of > names that could lead to either a flat or arbitrary name, and its > consequences of potential squatting or accidental overlaps; and the fact > that the requirement currently applies strictly to AS-SET objects to the > exclusion of other IRR objects. > > I have equally taken note that the AFPUB-2026-ASN-001-DRAFT02 requires > newly created AS-SETs to use hierarchical naming to avoid name collisions > and improve route filtering, the fact remains that any alteration or > amendment or new creation to existing policy framework would need to be > subjected to extensive discussions as is the guideline on this forum. > > Therefore, l hereby object to a creation of names as is being proposed > subject to alternative and more acceptable rationale that necessitates > acceptance of the proposal. > *Daniel Taye Medoye* > > > > > > > > > > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Mon Jul 20 12:01:19 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Mon, 20 Jul 2026 12:01:19 +0000 Subject: [rpd] Request to Pause the AI generated posting Message-ID: Hi Noah, I am the participant, and I take full responsibility for what I submit. A writing tool may assist me, but it does not replace my judgment, my views, or my right to participate. You do not have the authority to dictate which lawful tools I may use to express those views. That choice is mine. Concerns about list traffic should be handled through normal moderation and consolidation, not by selectively asking certain participants to stop contributing. Regards, Tshepo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mselekuthandeka80 at gmail.com Mon Jul 20 12:02:54 2026 From: mselekuthandeka80 at gmail.com (Thandeka Mseleku) Date: Mon, 20 Jul 2026 14:02:54 +0200 Subject: [rpd] Request to Pause the AI Generated Posting Message-ID: Dear Noah, Thank you for the clarification. I appreciate that you have shared your personal view. However, I believe all participants should remain free to contribute to the discussion, and our contributions should be evaluated on their merits rather than assumptions about how they were prepared or whether similar viewpoints are coordinated. Respectful disagreement is an important part of the Policy Development Process, and I hope the discussion can continue to focus on the proposals themselves. BR, Thandeka Mseleku -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Mon Jul 20 12:11:56 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Mon, 20 Jul 2026 14:11:56 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 92 In-Reply-To: References: Message-ID: Hi Noah, Thanks for clarifying that you were speaking for yourself. I still don't think it's appropriate to ask certain participants to stop posting while everyone else continues. The discussion is still open, and unless the co-chairs decide otherwise, everyone has the same right to participate. Whether someone uses a writing tool or not doesn't change the responsibility for what they write. What matters is whether the person stands behind their submission and whether the arguments can be answered. If there are concerns about the volume of emails, that should apply equally to everyone. It shouldn't become a reason to ask one group of participants to step back. Healthy policy discussions involve different views, and sometimes that naturally means more emails. The best response is to engage with the arguments rather than the people making them. Regards, Fundiswa Nadia Maseko On Mon, 20 Jul 2026, 13:54 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: Request to Pause the AI Generated Posting (Thandeka Mseleku) > 2. Re: RPD Digest, Vol 222, Issue 91 (Nia Petronella) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 20 Jul 2026 12:23:34 +0200 > From: Thandeka Mseleku > To: rpd at afrinic.net > Cc: rpd-owner at afrinic.net > Subject: Re: [rpd] Request to Pause the AI Generated Posting > Message-ID: > < > CA+mVb0mhYYqqMKMW9pvjmicdw3i3NGS87vwHfVVP+pvX9QAe6w at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Noah, > > I respectfully disagree with your request. > > The Policy Development Process is built on open participation. > Contributions should be assessed on their technical and policy merits, not > on assumptions about how they were prepared. Not every well-written or > similar email is AI-generated. > > If there are concerns about a contribution, they should be addressed by > responding to the arguments themselves rather than discouraging > participation. > > BR, > Thandeka Mseleku > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/1f7b90a5/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Mon, 20 Jul 2026 13:54:06 +0200 > From: Nia Petronella > To: rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 91 > Message-ID: > 3ig at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Noah, > > You may disagree with the use of writing tools, but you cannot dictate > which tools participants may or may not use. What matters is whether > contributors stand behind their submissions and whether the arguments are > relevant. > > As for traffic, an active policy discussion will naturally generate > messages. The answer is sensible moderation, threading, and consolidation > where appropriate, not asking selected participants to stop speaking. > > The co-chairs can manage the process. Individual participants do not have a > mandate to silence others. > > Regards, > > Nonhlanhla > > > On Mon, 20 Jul 2026, 12:02 pm wrote: > > > Send RPD mailing list submissions to > > rpd at afrinic.net > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.afrinic.net/mailman/listinfo/rpd > > or, via email, send a message with subject or body 'help' to > > rpd-request at afrinic.net > > > > You can reach the person managing the list at > > rpd-owner at afrinic.net > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of RPD digest..." > > > > > > Today's Topics: > > > > 1. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage) > > 2. Re: Request to Pause the AI generated posting (Noah) > > 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Bubacarr Sowe) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Mon, 20 Jul 2026 11:50:45 +0200 > > From: Hendrik Visage > > To: Taye Medoye > > Cc: rpd at afrinic.net > > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > Message-ID: > > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > > Dear Daniel, > > > > Thank you for the considered note, and for recognising the rationale on > > squatting and name overlaps as justifiable. > > > > One clarification on process: this proposal is DRAFT02 at Last Call, > > meaning the PDP discussion phases your message calls for have already > > run their course ? Last Call is their conclusion. The earlier rounds > > are in the list archive https://lists.afrinic.net/pipermail/rpd/ should > > they be useful - Reference the first draft call on > > https://lists.afrinic.net/pipermail/rpd/2026/014746.html > > > > You write that you object "subject to alternative and more acceptable > > rationale." Could you say what specific rationale would move you to > > acceptance? Happy to address it directly. > > Regards, > > Hendrik > > > > --- > > 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 > > > > On 20 Jul 2026, at 11:08, Taye Medoye wrote: > > > > > Whereas the Organization?s guideline on Policy Scope & Exclusions > > > permits > > > any desired alteration or amendment to an existing policy framework, > > > it is > > > required that such an exercise would require critical deliberations > > > and > > > discussion to ensure a convincing and realistic position for the > > > proposed > > > policy change or amendment to stand the test of time. This view also > > > aligns > > > with the policy statement which guarantees *that Number Resource > > > management > > > policies are developed through an open Policy Development Process > > > (PDP).* > > > > > > In regard to the draft Policy proposal on bordering on the above > > > captioned > > > subject-matter, projected for discussions on the Forum, l have taken > > > note > > > of the justifiable rationale which forbids the unauthorized creation > > > of > > > names that could lead to either a flat or arbitrary name, and its > > > consequences of potential squatting or accidental overlaps; and the > > > fact > > > that the requirement currently applies strictly to AS-SET objects to > > > the > > > exclusion of other IRR objects. > > > > > > I have equally taken note that the AFPUB-2026-ASN-001-DRAFT02 requires > > > newly created AS-SETs to use hierarchical naming to avoid name > > > collisions > > > and improve route filtering, the fact remains that any alteration or > > > amendment or new creation to existing policy framework would need to > > > be > > > subjected to extensive discussions as is the guideline on this forum. > > > > > > Therefore, l hereby object to a creation of names as is being proposed > > > subject to alternative and more acceptable rationale that necessitates > > > acceptance of the proposal. > > > *Daniel Taye Medoye* > > > > > _______________________________________________ > > > RPD mailing list > > > RPD at afrinic.net > > > https://lists.afrinic.net/mailman/listinfo/rpd > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/6a473a32/attachment-0001.html > > > > > > > ------------------------------ > > > > Message: 2 > > Date: Mon, 20 Jul 2026 12:55:25 +0300 > > From: Noah > > To: Phetulo Dhlamini > > Cc: rpd List > > Subject: Re: [rpd] Request to Pause the AI generated posting > > Message-ID: > > > mhiUzqY3NcMJ9Q at mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > On Mon, 20 Jul 2026, 12:33?pm Phetulo Dhlamini, < > phetulodhlamini at gmail.com > > > > > wrote: > > > > > Hi Noah, > > > > > > You don?t speak for the whole PDWG . People disagreeing is not a reason > > to > > > silence people . > > > > > > > You are absolutely right. I dont speak for the PDWG... > > > > I made assumption based on offline discussions I have had with an > ecosystem > > that participate in this WG which is really surprised by the coordinated > AI > > posting from your peers who I mentioned earlier. > > > > > > > > >> Can I kindly request that you pause your AI generated posts for now so > > as > > >> to reduce traffic on rpd list. > > >> > > > > > Can i kindly request that you and your peers pause the endless posting > for > > now as we wait for feedback from the co-chairs. > > > > Noah > > > > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/bcad9913/attachment-0001.html > > > > > > > ------------------------------ > > > > Message: 3 > > Date: Mon, 20 Jul 2026 11:01:42 +0100 > > From: Bubacarr Sowe > > To: rpd at afrinic.net > > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > Message-ID: <80a2afb9-07c4-4878-81ff-70f4603080e5 at sowe.me> > > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > > Dear PDWG, > > > > I support the adoption of this draft. > > > > Hierarchical AS-SETs? solve a problem. We need this and such a draft > > should be adopted without difficulty. I don't see any benefit in not > > adapting it. > > > > Lets not resist for the sake of resisting but understand why > > hierarchical AS-SETs are important. MANRS site has more on this here: > > > > > https://manrs.org/2022/12/why-network-operators-should-use-hierarchical-as-sets/ > . > > > > > > > > Please don't load this list with AI puke, its annoying, stupid and the > > repetitiveness is an eye sore. You may enjoy your AI output? but that > > may not be the case for most of us, that is for your Facebook post. > > > > Mailing lists like this solves real problems and people make decision > > base on the discussions but if we fill this list with some garbage from > > ChatGTP or whatever, we will kill the spirit of the discussion, the > > human engagement and the results that define our community and the > > internet. > > > > Thanks, > > > > BS > > > > > > On 16/07/2026 23:09, Hytham El-Nakhal wrote: > > > Dear PDWG, > > > > > > > > > The Policy Development Working Group (PDWG) Chairs have initiated a > Last > > Call for this proposal, following rough consensus at the AFRINIC-37 > Public > > Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. > > > > > > * Proposal Name: Hierarchical Names for New AS-SETs > > > > > > * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > > > > > > * Proposal URL: > > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > > > > > Last Call closes on: July 31, 2026, at 23:59 UTC. > > > > > > > > > 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. > > > > > > > > > As always, we kindly request that all participants adhere to the > AFRINIC > > Code of Conduct to maintain a respectful > > and professional environment on the mailing list. > > > > > > > > > Kind regards, > > > > > > > > > Haitham el Nakhal > > > > > > AFRINIC PDWG Co-Chair > > > > > > > > > > > > _______________________________________________ > > > RPD mailing list > > > RPD at afrinic.net > > > https://lists.afrinic.net/mailman/listinfo/rpd > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/6bc09152/attachment.html > > > > > > > ------------------------------ > > > > Subject: Digest Footer > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > ------------------------------ > > > > End of RPD Digest, Vol 222, Issue 91 > > ************************************ > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/59c11051/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 92 > ************************************ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.medoye at gmail.com Mon Jul 20 12:37:40 2026 From: daniel.medoye at gmail.com (Taye Medoye) Date: Mon, 20 Jul 2026 14:37:40 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the AI Generated Posting Message-ID: In regard to the ensuing antagonistic reponses relating to the call for the pause of AI generated mails, l align with the position expressed by Noah for obvious reasons: Firstly, the well referenced Policy Development Process (PDP) on open and unecumbered participation and expressions remains sancrosant, and a guiding principle. I think this priciple should be observed always; Secondly, l am not aware that the Forum gives the freedom to engage in any form of criticism on the contributions made by participants. Above all, l subscribe to the view that, while AI may be good in assisting with information as may be sought concerning any subject matter, l do not think it has the capacity to meet the prinicple of originality expected in any written literary work, whether in research or for informative diseemination purposes. The bottom line remains that, in line with the framework for particiapting in any discussion on this Forum, mutual respect for views should be upheld. Daniel Taye Medoye -------------- next part -------------- An HTML attachment was scrubbed... URL: From NGBSIM008 at myuct.ac.za Mon Jul 20 13:52:56 2026 From: NGBSIM008 at myuct.ac.za (Simphiwe Ngubane) Date: Mon, 20 Jul 2026 13:52:56 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear PDWG, Good day colleagues, I would like to take the opportunity to vouchsafe the remarks made by Asamkele?s objection in accordance with remaining firmly opposed to AFPUB-2026-ASN-001-DRAFT02. Noah, Nishal, and Seun, from the discursive propositions they have made and that I have seen, seem (and I say this with some hesitation but with profound respect for each of them) to treat the existence of an operational concern as if it automatically proves the necessity of this particular mandatory policy: in my humble opinion it does not. Hierarchical naming may improve attribution by binding the creator of an AS-SET to an ASN maintainer. It does not verify that the membership of the set is accurate, current, complete, or authorised by every network represented within it. Automated filtering tools consume the contents of the object. They do not become safe merely because the object has a hierarchical name. The proposal, from my perspective, addresses attribution, not the expansive full routing-authorisation problem being used in justifying the said proposal. That difference cannot be dismissed as philosophical or non-technical, to whit; it goes directly to whether the proposed rule actually prevents the claimed harm. Nishal (whose discursive writing on this platform I have been consuming with rapacious intent) made a suggestion that objectors do not ?live and speak BGP?, this has a hue of questionability. Operational experience is valuable, but it is evidence, not exclusive authority. Technical expertise should explain the threat model, quantify the harm, and test whether the remedy works. It can be argued that it should not be used as a credential to exclude participants who question policy scope, proportionality, or institutional power. Noah has also made claim that the community is ?empowered? to impose such rules also requires limits. A policy process may coordinate around genuine technical invariants. It does not receive unlimited authority to make every preferred operational convention compulsory. Participation does not manufacture mandate. A mailing list is not a legislature, and support from regular participants is not a substitute for proof that compulsion is indispensable. Seun, whom I have respectfully addressed directly before regarding a comment directed at myself, made the suggestion that those sharing similar objections should write another policy reverses the burden of proof. Objectors do not have to design a replacement enforcement regime before opposing this one. The authors and supporters of a mandatory proposal must demonstrate: * that the harm is clearly evidenced; * that the proposed rule materially prevents it; * that less restrictive mechanisms have failed; * and that registry enforcement is the minimum proportionate response. The continued creation of flat AS-SETs does not prove that voluntary adoption has failed. It proves only that operators continue to use a format currently permitted by the system. Non-adoption of a preferred convention is not itself a technical failure. Alternatives such as explicit provenance, source-qualified references, collision warnings, deterministic validation, tooling improvements, local rejection, and voluntary hierarchical naming have not been shown to be incapable of addressing the risk. They have largely been brushed aside because compulsion is administratively simpler. Administrative simplicity is not a technical necessity. Nor does adoption by other RIRs settle the issue. Institutional convergence may be relevant experience, but it is not authority over AFRINIC. Other registries choosing the same rule does not remove AFRINIC?s obligation to test necessity, proportionality, residual risk, and operator impact for itself. Ultimately, it should be given that the proper common layer should remain thin. It should protect uniqueness, proof of control, registry accuracy, security integrity, and operational continuity. It should not grow each time a useful practice can be converted into a mandatory database rule. For these reasons, and unequivocally, I lend my support to Asamkele and maintain my strong opposition to this proposal. Regards, Simphiwe Ngubane Disclaimer - University of Cape Town This email is subject to UCT policies and email disclaimer published on our website at https://www.uct.ac.za/main/email-disclaimer or obtainable from +27 21 650 9111. If this email is not related to the business of UCT, it is sent by the sender in an individual capacity. Please report security incidents or abuse via https://csirt.uct.ac.za/report-incident -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Mon Jul 20 13:55:38 2026 From: mike at iptrading.com (Mike Burns) Date: Mon, 20 Jul 2026 09:55:38 -0400 Subject: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the AI Generated Posting In-Reply-To: References: Message-ID: <062601dd184f$72379070$56a6b150$@iptrading.com> I am very happy that this list has some traffic, and separate from the AS-SET issue, the issue of AI generated posts is enormously interesting not only to this RIR policy list, but to all of them. My position is that there are two issues contained. One is the swamping of the list with AI generated posts. The other is the concept of treating AI posts like any other post. While I am against the use of AI to swamp the list with long messages in a Denial of Service sort of attack, I believe the principle of avoiding ad hominem arguments means that we have to treat the AI generated arguments the same as if they came directly from the pen of the poster. That is to say, ignore everything but the arguments being made, not the use of AI. It is the arguments that matter, not the speaker. I expect this to bubble up in other RIR policy lists as time goes on, it would be good to have some kind of principled response. Many use translators to write posts in foreign languages, so certainly some tool use is expected. There are ways to block participants who transgress in other ways and those who post repeated AI slop to swamp the list should be so treated. But unless there is an attempt by an individual to swamp the list, the posts should be treated as if written by the poster, that is like every other post. I am interested to hear other perspectives on this. Regards, Mike From: Taye Medoye Sent: Monday, July 20, 2026 8:38 AM To: rpd at afrinic.net Subject: Re: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the AI Generated Posting In regard to the ensuing antagonistic reponses relating to the call for the pause of AI generated mails, l align with the position expressed by Noah for obvious reasons: Firstly, the well referenced Policy Development Process (PDP) on open and unecumbered participation and expressions remains sancrosant, and a guiding principle. I think this priciple should be observed always; Secondly, l am not aware that the Forum gives the freedom to engage in any form of criticism on the contributions made by participants. Above all, l subscribe to the view that, while AI may be good in assisting with information as may be sought concerning any subject matter, l do not think it has the capacity to meet the prinicple of originality expected in any written literary work, whether in research or for informative diseemination purposes. The bottom line remains that, in line with the framework for particiapting in any discussion on this Forum, mutual respect for views should be upheld. Daniel Taye Medoye -------------- next part -------------- An HTML attachment was scrubbed... URL: From NGBSIM008 at myuct.ac.za Mon Jul 20 13:57:30 2026 From: NGBSIM008 at myuct.ac.za (Simphiwe Ngubane) Date: Mon, 20 Jul 2026 13:57:30 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Good afternoon Jaco, I'd like to take the chance to proffer my opinion on something stated; I believe and I may be incorrect in this that demonstrating that a proposal may reduce one risk does not automatically prove that mandatory policy is the right remedy. The community, as it stands, is tasked to interrogate necessity, scope, and alternatives, not merely perhaps to treat operational concern as automatic authority or axiomatic in that way. A problem statement is evidence, not a blank cheque.\ I hope this comment is well received. Regards, Simphiwe Ngubane Disclaimer - University of Cape Town This email is subject to UCT policies and email disclaimer published on our website at https://www.uct.ac.za/main/email-disclaimer or obtainable from +27 21 650 9111. If this email is not related to the business of UCT, it is sent by the sender in an individual capacity. Please report security incidents or abuse via https://csirt.uct.ac.za/report-incident -------------- next part -------------- An HTML attachment was scrubbed... URL: From internetplumber at gmail.com Mon Jul 20 14:40:43 2026 From: internetplumber at gmail.com (Rob Evans) Date: Mon, 20 Jul 2026 15:40:43 +0100 Subject: [rpd] Writing tools In-Reply-To: <062601dd184f$72379070$56a6b150$@iptrading.com> References: <062601dd184f$72379070$56a6b150$@iptrading.com> Message-ID: Mike, all > But unless there is an attempt by an individual to swamp the list, the posts should be treated as if written by the poster, that is like every other post. As someone with no hats to wear, but an occasional interest in global address policy. One of the challenges I've found reading the list traffic over the last few days has been that some of the emails generated using 'writing tools' can appear vague and flowery[1]. It can be difficult to debate a point when it's almost impossible to fathom what point is being made. I fully appreciate that having a discussion take place in English when that is, at best, the second language of many of the participants means that using tools to translate the discussion can be invaluable for having an inclusive discussion, but I wonder if it is also possible to ask the tools to be more concise as part of whatever prompt is being used? >From what I can see, the major objections relating to the hierarchical AS-SET naming are: - The solution isn't perfect and doesn't state its limitations. - This is an overreach of the RIR into something that doesn't need policy. Cheers, Rob [1] Google AI helpfully describes flowery language as "Flowery language?often called purple prose?is writing or speech that is overly ornate, intricate, and packed with decorative adjectives." From aa at alstonnetworks.net Mon Jul 20 14:46:22 2026 From: aa at alstonnetworks.net (Andrew Alston) Date: Mon, 20 Jul 2026 17:46:22 +0300 Subject: [rpd] RPD Digest, Vol 222, Issue 81 In-Reply-To: References: Message-ID: Hi All, I agree with what Saul has said here. I also want to make some notes on rough consensus because reading through recent messages, some participants seem unaware of how rough consensus is achieved. Firstly - Rough Consensus as used in the RIR system largely stems from rough consensus as defined in RFC7282 ( https://datatracker.ietf.org/doc/html/rfc7282) The essence of this is that there are two basic principles: First, objections are given more weight than support; second, objections must be grounded in fact and evidence. If 100 people support something, but there is one strong, evidence-backed technical argument against it, that issue must be addressed. Note: The issue does not have to be "fixed"; however, it must be considered and the working group must agree that the issue is not substantive enough to block consensus. Regarding the ongoing last call for the as-set naming policy, I support it because I believe it is a sensible safeguard. Second, after reading the objections related to AfriNIC's institutional mandate and scope creep, reviewing the current AfriNIC bylaws shows this objection doesn't stand up to scrutiny. Section 3.4 of the bylaws as currently written, makes it clear that policy promoting common-sense good practice for the benefit of the African internet community as a whole, is very much within AfriNIC's scope. I do not believe that this policy infringes on any institution's right to operate its network as it sees fit. It merely provides a safeguard. One of the objections I saw stated that the onus is on the authors to prove that their proposal cannot be addressed via other means. This again, is inaccurate. There are many ways to accomplish the same thing, in the standards world in particular there are often multiple standards that accomplish the same goal. I would argue that it is the opponents who have a duty to prove that the proposal may cause undue harm to the community, or is outside of the scope of the PDP (or AfriNIC's mandate as defined in the bylaws). Since there has been no such objection grounded in facts or evidence, I cannot see how such objections would withstand the rough consensus test. Thanks Andrew On Mon, Jul 20, 2026 at 11:06?AM Saul Stein via RPD wrote: > Actually, one?s knowledge and experience is very relevant. > > > > Running and safeguarding the internet landscape is a very practical thing. > Something that those who do, do so on a daily basis. > > > > People who are commenting on the practicality of running the internet and > routing protocols and who have no experience in it or are even involved in > it, might well have some insights to provide. > > HOWEVER, they then need to provide fact to base comments where the > technical community who are practically involved in the process are saying > otherwise. > > > > Simply repeating the same narrative which goes against global trends and > those that use it raise questions about their intentions. > > > > > > > > *From:* Nia Petronella > *Sent:* Monday, 20 July 2026 09:46 > *To:* ben.roberts at afrinic.net; rpd at afrinic.net > *Subject:* Re: [rpd] RPD Digest, Vol 222, Issue 81 > > > > Hi Ben, > > > > Participants may introduce themselves if they choose, but an introduction > should not become a condition for having an argument considered. > > > > This is an open policy forum, not a membership interview. Contributions > should be assessed on their substance, not on how familiar the speaker is > or how long they have been present. > > > > Regards, > > Nonhlanhla > > > > On Mon, 20 Jul 2026, 9:41 am ben.roberts at frinic.net < > ben.roberts at afrinic.net> wrote: > > Nonhlanhla, > > > > Perhaps the new participants would like to introduce themselves, with some > context of their new interest in IP address policy making? > > > > Kind Regards, > > Ben > > > > *From: *Nia Petronella > *Date: *Monday, 20 July 2026 at 09:38 > *To: *rpd at afrinic.net > *Subject: *Re: [rpd] RPD Digest, Vol 222, Issue 81 > > Get Outlook for Mac > > Dear PDWG, > > > > A pattern is becoming clear: familiar names are treated as authoritative, > while newer participants are questioned, graded, or dismissed. > > > > That is gatekeeping, not consensus. > > > > An open process should test arguments, not reputations. Participation is > evidence and objection; being well known does not create a mandate to > decide whose voice counts. > > > > Regards, > > Nonhlanhla > > > > On Mon, 20 Jul 2026, 9:35 am wrote: > > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Subject: Re: [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Thulisile > Mazomba) > 2. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Tshepo Masuku) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 20 Jul 2026 07:24:43 +0000 > From: Thulisile Mazomba <219280444 at mycput.ac.za> > To: Frank Habicht , "rpd at afrinic.net" > > Cc: "rpd-owner at afrinic.ne" > Subject: [rpd] Subject: Re: [Last Call] Draft Policy Proposal ? > Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > < > GVXPR04MB12291FB9551CD3D0ADB433FE6D1C32 at GVXPR04MB12291.eurprd04.prod.outlook.com > > > > Content-Type: text/plain; charset="windows-1252" > > Hi Frank, > > An improvement is not automatically a justification for mandatory policy. > > The question is whether the benefit is significant enough, proven enough, > and proportionate enough to place in the registry?s compulsory layer. > Saying ?it helps? does not answer that. > > And no, raising those questions does not mean the objection came first. It > means policy power should be tested before it is expanded. > > I remain opposed. > > Regards, > Thulisile > ________________________________ > From: Frank Habicht > Sent: Monday, 20 July 2026 06:36:00 > To: Thulisile Mazomba <219280444 at mycput.ac.za>; rpd at afrinic.net < > rpd at afrinic.net> > Cc: rpd-owner at afrinic.ne > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > Hi, > > On 7/19/2026 11:29 PM, Thulisile Mazomba wrote: > > > > Hi Frank, > > > > You appear to be treating your disagreement with an objection as proof > > that no technical objection exists. > > > > The proposal prevents one naming collision. It does not establish the > > correctness of the routing data attached to that name, > > The proposal does not fix *all* problems. and it doesn't claim to do so. > It creates an improvement. > I don't agree that it is ok to object just because this proposal does > not fix *all* problems. > > Do you agree it provides improvements? > > > nor prove that > > mandatory registry control is the only proportionate remedy. > > it's not intended to prove that. > > > > > Those are technical and policy questions. Declaring them invalid does > > not resolve them. > They are not good reasons against the proposal. > > But some people maybe want to be against the proposal first and then are > looking for "questions". > > Frank > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/a7286772/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Mon, 20 Jul 2026 07:34:21 +0000 > From: Tshepo Masuku > To: "rpd at afrinic.net" , "geier at geier.ne.tz" > > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > < > VI2PR04MB10545520811A7499ACFFB1239CAC32 at VI2PR04MB10545.eurprd04.prod.outlook.com > > > > Content-Type: text/plain; charset="us-ascii" > > Hi Frank, > > You keep positioning yourself as the referee of which objections count. > > That is not your role. Participants are allowed to question whether a > useful change belongs in mandatory policy. Dismissing those concerns > instead of answering them turns discussion into gatekeeping. > > A policy room may debate. It does not grant any participant authority to > police dissent. > > I remain opposed. > > Regards, > Tshepo > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/0cd4be0c/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 81 > ************************************ > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Mon Jul 20 15:02:43 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Mon, 20 Jul 2026 17:02:43 +0200 Subject: [rpd] Writing tools In-Reply-To: References: <062601dd184f$72379070$56a6b150$@iptrading.com> Message-ID: <97ab9d85-1047-46d8-aa87-1fd8b9dfe9b9@uls.co.za> Hi Rob, On 2026/07/20 16:40, Rob Evans wrote: > Mike, all > >> But unless there is an attempt by an individual to swamp the list, the posts should be treated as if written by the poster, that is like every other post. > As someone with no hats to wear, but an occasional interest in global > address policy. > > One of the challenges I've found reading the list traffic over the > last few days has been that some of the emails generated using > 'writing tools' can appear vague and flowery[1]. It can be difficult > to debate a point when it's almost impossible to fathom what point is > being made. You and me both. > I fully appreciate that having a discussion take place in English when > that is, at best, the second language of many of the participants > means that using tools to translate the discussion can be invaluable > for having an inclusive discussion, but I wonder if it is also > possible to ask the tools to be more concise as part of whatever > prompt is being used? In support of short concise language.? And actually making the point. > > From what I can see, the major objections relating to the hierarchical > AS-SET naming are: > - The solution isn't perfect and doesn't state its limitations. No one claimed it's perfect.? But it does two things: * It protects against naming collisions between multiple RIR (having been on the victim side ...).? The long and the short is that it causes major routing filter problems when these collisions happen.? The effects of which we all know too well I expect. * It assigns ownership, as in, we can know which AS published it. It still does not state how authentic the data is, in other words, let's say AS65500 decides to include AS65511 into it's set, who's to say that AS65511 wants to be included?? There are attributes in the autnum objects which relates to this problem, but they are only meaningful if we can protect against collisions. In other words - it improves upon the current situation.? There's a saying that done is better than perfect.? Or as Nishal points out - incremental improvements, which is obviously better than no improvement. No software, and pretty much no system gets held back until it's perfect - if that was the case we'd still be waiting for ... well, even the most basic of operating system to be released.? There's good enough, and risk is low enough.? Since the current level of risk exceeds that of the proposed change it overall lowers risk, and as such is a move in the right direction.? Is it complete?? By no means.? But we can't wait for the bricks on top of the wall to be manufactured before we start laying down useful foundations. > - This is an overreach of the RIR into something that doesn't need policy. I'm getting the same.? But this isn't being driven by the RIR, it's a community desired policy related to IRR data being kept by the RIR in accordance with the wishes of it's members - and those people against the policy has (to the best of my knowledge) not disclosed their affiliations, or what operational problems (as implied) this policy can cause that worries them. As such my only logical conclusion is that they are opposed against accountability and overall routing security.? This has been disclaimed, but I've yet to see a reasonable motivation as to why this policy is a bad thing for internet governance. Andrew Alston also points out rough consensus, and frankly, until we see a proper objection to this policy based on operational issues that it will cause, I personally think discussions are done.? Nothing more to be said IMHO. Kind regards, Jaco > > Cheers, > Rob > > [1] Google AI helpfully describes flowery language as "Flowery > language?often called purple prose?is writing or speech that is overly > ornate, intricate, and packed with decorative adjectives." > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From omo.oaiya at wacren.net Mon Jul 20 15:05:32 2026 From: omo.oaiya at wacren.net (Omo Oaiya) Date: Mon, 20 Jul 2026 18:05:32 +0300 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <03F8CE74-281D-134A-BC11-DA1F695B0B01@hxcore.ol> References: <03F8CE74-281D-134A-BC11-DA1F695B0B01@hxcore.ol> Message-ID: <72A839EA-2F7A-4122-9EF7-CD0D2B2DD208@wacren.net> Hi Ben, Some of the recent exchanges do suggest that some contributions may have been coordinated or based on common templates - and thanks adding ?astroturfing" to my vocabulary :-) Another problem along similar lines is organised bloc participation, but these issues are not new, in the AFRINIC community or elsewhere. We should be careful not to let the discussion become about the participants rather than the policy. New voices should always be welcome, and the co-chairs can determine rough consensus by identifying and evaluating the distinct technical and policy issues raised, rather than the number of emails expressing them. Technically sound objections should be addressed on their merits regardless of who raises them - experienced operator or not -, and repeated assertions without additional evidence should not carry additional weight. In fact, co-chairs could ask participants to be more evidence-oriented, raising the quality bar without worrying too much about who the author is. I think this could preserve the openness of the PDP while making coordinated messaging largely ineffective. Cheers, Omo > On 20 Jul 2026, at 10:45, ben.roberts--- via RPD wrote: > > Dr Nyasha, > > It appears you are in fact using a template? And forgot to delete the [name] placeholder ? > Did you write the email yourself? > > Kind Regards, > > Ben > > Nyasha Ndemo wrote. >>> > > Regards, > [Name] > > Dr. Nyasha Ndemo-Masimbarasi > (DPhil, MSc., BSc. Hon. Development Science and Policy) > Chairperson - Department of Development Programming and Management > > > From: Nyasha Ndemo > Date: Monday, 20 July 2026 at 09:42 > To: rpd at afrinic.net > Cc: rpd-owner at afrinic.net > Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > Get Outlook for Mac > Dear PDWG, > > The discussion is being diverted from the substance of the objections toward speculation about AI use, writing style, and how consensus should be counted. > > That does not answer the policy concerns raised. > > A problem statement does not prove that the proposed remedy is necessary, proportionate, or technically sufficient. Nor does the use of drafting assistance invalidate an argument. The relevant question is whether the objection is sound. > > The objections remain clear: the proposal improves naming attribution, but it does not validate AS-SET contents, eliminate incorrect customer-cone data, or demonstrate that mandatory registry enforcement is the minimum necessary response. > > If several participants raise the same concern, the proper response is to answer that concern on its merits. Similarity does not make it disappear, and unfamiliar participants do not count for less. > > Participation is evidence, not mandate. Consensus is not manufactured by dismissing dissenters or analysing their prose. > > I therefore remain opposed and ask that the discussion return to the unresolved technical and proportionality questions. > > Regards, > [Name] > > Dr. Nyasha Ndemo-Masimbarasi > (DPhil, MSc., BSc. Hon. Development Science and Policy) > Chairperson - Department of Development Programming and Management > Zimbabwe Ezekiel Guti University > 1901 Barrassie Rd, Off Shamva Rd, Bindura > Zimbabwe > Landline: +263867 700 6136 > Cell: +263 773226552 > Email: nyashandemo at gmail.com > > On Mon, Jul 20, 2026, 9:35?AM > wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Subject: Re: [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Thulisile Mazomba) > 2. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Tshepo Masuku) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 20 Jul 2026 07:24:43 +0000 > From: Thulisile Mazomba <219280444 at mycput.ac.za > > To: Frank Habicht >, "rpd at afrinic.net " > > > Cc: "rpd-owner at afrinic.ne " > > Subject: [rpd] Subject: Re: [Last Call] Draft Policy Proposal ? > Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > > > > Content-Type: text/plain; charset="windows-1252" > > Hi Frank, > > An improvement is not automatically a justification for mandatory policy. > > The question is whether the benefit is significant enough, proven enough, and proportionate enough to place in the registry?s compulsory layer. Saying ?it helps? does not answer that. > > And no, raising those questions does not mean the objection came first. It means policy power should be tested before it is expanded. > > I remain opposed. > > Regards, > Thulisile > ________________________________ > From: Frank Habicht > > Sent: Monday, 20 July 2026 06:36:00 > To: Thulisile Mazomba <219280444 at mycput.ac.za >; rpd at afrinic.net > > Cc: rpd-owner at afrinic.ne > > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > Hi, > > On 7/19/2026 11:29 PM, Thulisile Mazomba wrote: > > > > Hi Frank, > > > > You appear to be treating your disagreement with an objection as proof > > that no technical objection exists. > > > > The proposal prevents one naming collision. It does not establish the > > correctness of the routing data attached to that name, > > The proposal does not fix *all* problems. and it doesn't claim to do so. > It creates an improvement. > I don't agree that it is ok to object just because this proposal does > not fix *all* problems. > > Do you agree it provides improvements? > > > nor prove that > > mandatory registry control is the only proportionate remedy. > > it's not intended to prove that. > > > > > Those are technical and policy questions. Declaring them invalid does > > not resolve them. > They are not good reasons against the proposal. > > But some people maybe want to be against the proposal first and then are > looking for "questions". > > Frank > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Message: 2 > Date: Mon, 20 Jul 2026 07:34:21 +0000 > From: Tshepo Masuku > > To: "rpd at afrinic.net " >, "geier at geier.ne.tz " > > > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > > > > Content-Type: text/plain; charset="us-ascii" > > Hi Frank, > > You keep positioning yourself as the referee of which objections count. > > That is not your role. Participants are allowed to question whether a useful change belongs in mandatory policy. Dismissing those concerns instead of answering them turns discussion into gatekeeping. > > A policy room may debate. It does not grant any participant authority to police dissent. > > I remain opposed. > > Regards, > Tshepo > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 81 > ************************************ > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd Omo OAIYA Chief Strategy Officer/Directeur de la Strat?gie | WACREN m: +234 808 888 1571 , +233 536 269 987 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Mon Jul 20 15:17:29 2026 From: mike at iptrading.com (Mike Burns) Date: Mon, 20 Jul 2026 11:17:29 -0400 Subject: [rpd] Writing tools In-Reply-To: References: <062601dd184f$72379070$56a6b150$@iptrading.com> Message-ID: <066b01dd185a$e13e9080$a3bbb180$@iptrading.com> Hi Rob, Yes, the language is a clear tell of AI usage, but flowery language alone is not swamping the list. I don't want to hijack the AS-SET discussion, so thank you for the new subject line. Now, sometimes and unfortunately, I can use vague and flowery language myself, so I would advise you to treat the AI stuff like the human stuff. Ignore it if it's too vague or flowery to serve as a good argument, and you have clearly laid out the two arguments in your last two lines. Hopefully the list will show judgement and treat clear and concise arguments better than vague ones. And then the AI posts, if they want to be successful, will avoid the purple prose. Regards, Mike -----Original Message----- From: Rob Evans Sent: Monday, July 20, 2026 10:41 AM To: Mike Burns Cc: Taye Medoye ; rpd >> AfriNIC Resource Policy Subject: Writing tools Mike, all > But unless there is an attempt by an individual to swamp the list, the posts should be treated as if written by the poster, that is like every other post. As someone with no hats to wear, but an occasional interest in global address policy. One of the challenges I've found reading the list traffic over the last few days has been that some of the emails generated using 'writing tools' can appear vague and flowery[1]. It can be difficult to debate a point when it's almost impossible to fathom what point is being made. I fully appreciate that having a discussion take place in English when that is, at best, the second language of many of the participants means that using tools to translate the discussion can be invaluable for having an inclusive discussion, but I wonder if it is also possible to ask the tools to be more concise as part of whatever prompt is being used? >From what I can see, the major objections relating to the hierarchical AS-SET naming are: - The solution isn't perfect and doesn't state its limitations. - This is an overreach of the RIR into something that doesn't need policy. Cheers, Rob [1] Google AI helpfully describes flowery language as "Flowery language?often called purple prose?is writing or speech that is overly ornate, intricate, and packed with decorative adjectives." From TshepoMasuku26 at hotmail.com Mon Jul 20 15:17:40 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Mon, 20 Jul 2026 15:17:40 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear all, There are two separate questions here, and they should not be collapsed into one. First, writing assistance does not determine whether a contribution is valid. The participant remains responsible for the argument submitted. Concision and evidence are reasonable expectations for everyone, but the tools used to prepare a message are a matter of individual choice, not a basis for excluding it. Second, showing that hierarchical naming offers an improvement does not automatically prove that it should become mandatory policy. ?Better than today? is not the end of the analysis. The community must still test necessity, proportionality, scope, alternatives, and the authority being granted to the registry. Operational experience is valuable evidence, but it is not a mandate to define consensus or dismiss non-operators. Likewise, repeated objections should not gain weight merely through volume, but neither should repeated support from familiar participants. The co-chairs should identify the distinct arguments and assess them on their merits. Rough consensus is not a headcount, a reputation contest, or permission for the established group to declare the discussion finished. Participation may provide expertise, support, warning, or objection. It does not create authority over everyone else. Regards, Tshepo -------------- next part -------------- An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Mon Jul 20 15:19:20 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Mon, 20 Jul 2026 15:19:20 +0000 Subject: [rpd] Fw: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: ________________________________ From: Tshepo Masuku Sent: Monday, 20 July 2026 17:17:40 To: rpd at afrinic.net ; ben.roberts at frinic.net ; omo.oaiya at wacren.net ; jaco at uls.co.za ; mike at iptrading.com ; internetplumber at gmail.com Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Dear all, There are two separate questions here, and they should not be collapsed into one. First, writing assistance does not determine whether a contribution is valid. The participant remains responsible for the argument submitted. Concision and evidence are reasonable expectations for everyone, but the tools used to prepare a message are a matter of individual choice, not a basis for excluding it. Second, showing that hierarchical naming offers an improvement does not automatically prove that it should become mandatory policy. ?Better than today? is not the end of the analysis. The community must still test necessity, proportionality, scope, alternatives, and the authority being granted to the registry. Operational experience is valuable evidence, but it is not a mandate to define consensus or dismiss non-operators. Likewise, repeated objections should not gain weight merely through volume, but neither should repeated support from familiar participants. The co-chairs should identify the distinct arguments and assess them on their merits. Rough consensus is not a headcount, a reputation contest, or permission for the established group to declare the discussion finished. Participation may provide expertise, support, warning, or objection. It does not create authority over everyone else. Regards, Tshepo -------------- next part -------------- An HTML attachment was scrubbed... URL: From nndemo at staff.zegu.ac.zw Mon Jul 20 15:20:12 2026 From: nndemo at staff.zegu.ac.zw (Nyasha Ndemo) Date: Mon, 20 Jul 2026 17:20:12 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <72A839EA-2F7A-4122-9EF7-CD0D2B2DD208@wacren.net> References: <03F8CE74-281D-134A-BC11-DA1F695B0B01@hxcore.ol> <72A839EA-2F7A-4122-9EF7-CD0D2B2DD208@wacren.net> Message-ID: Thank you for the heads-up...I might have been coopted in a group or faction unaware... Please note this will be rectified so that I participate more objectively. I am not on the discussion platform hence I do not see how the discussion go... I am not on the mailing list or discussion platform. Kindly allow me on the platform for me to participate objectively.... Regards, Dr. Nyasha Ndemo-Masimbarasi (DPhil, MSc., BSc. Hon. Development Science and Policy) Chairperson - Department of Development Programming and Management Zimbabwe Ezekiel Guti University 1901 Barrassie Rd, Off Shamva Rd, Bindura Zimbabwe Landline: +263867 700 6136 Cell: +263 773226552 Email: nyashandemo at gmail.com On Mon, Jul 20, 2026, 5:06?PM Omo Oaiya wrote: > Hi Ben, > > Some of the recent exchanges do suggest that some contributions may have > been coordinated or based on common templates - and thanks adding > ?astroturfing" to my vocabulary :-) Another problem along similar lines is > organised bloc participation, but these issues are not new, in the AFRINIC > community or elsewhere. > > We should be careful not to let the discussion become about the > participants rather than the policy. New voices should always be welcome, > and the co-chairs can determine rough consensus by identifying and > evaluating the distinct technical and policy issues raised, rather than the > number of emails expressing them. > > Technically sound objections should be addressed on their merits > regardless of who raises them - experienced operator or not -, and repeated > assertions without additional evidence should not carry additional weight. > In fact, co-chairs could ask participants to be more evidence-oriented, > raising the quality bar without worrying too much about who the author is. > > I think this could preserve the openness of the PDP while making > coordinated messaging largely ineffective. > > Cheers, > > Omo > > On 20 Jul 2026, at 10:45, ben.roberts--- via RPD wrote: > > Dr Nyasha, > > It appears you are in fact using a template? And forgot to delete the > [name] placeholder ? > Did you write the email yourself? > > Kind Regards, > > Ben > > Nyasha Ndemo wrote. >>> > > Regards, > [Name] > > Dr. Nyasha Ndemo-Masimbarasi > (DPhil, MSc., BSc. Hon. Development Science and Policy) > Chairperson - Department of Development Programming and Management > > > *From: *Nyasha Ndemo > *Date: *Monday, 20 July 2026 at 09:42 > *To: *rpd at afrinic.net > *Cc: *rpd-owner at afrinic.net > *Subject: *[rpd] [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > Get Outlook for Mac > Dear PDWG, > > The discussion is being diverted from the substance of the objections > toward speculation about AI use, writing style, and how consensus should be > counted. > > That does not answer the policy concerns raised. > > A problem statement does not prove that the proposed remedy is necessary, > proportionate, or technically sufficient. Nor does the use of drafting > assistance invalidate an argument. The relevant question is whether the > objection is sound. > > The objections remain clear: the proposal improves naming attribution, but > it does not validate AS-SET contents, eliminate incorrect customer-cone > data, or demonstrate that mandatory registry enforcement is the minimum > necessary response. > > If several participants raise the same concern, the proper response is to > answer that concern on its merits. Similarity does not make it disappear, > and unfamiliar participants do not count for less. > > Participation is evidence, not mandate. Consensus is not manufactured by > dismissing dissenters or analysing their prose. > > I therefore remain opposed and ask that the discussion return to the > unresolved technical and proportionality questions. > > Regards, > [Name] > > Dr. Nyasha Ndemo-Masimbarasi > (DPhil, MSc., BSc. Hon. Development Science and Policy) > Chairperson - Department of Development Programming and Management > Zimbabwe Ezekiel Guti University > 1901 Barrassie Rd, Off Shamva Rd, Bindura > Zimbabwe > Landline: +263867 700 6136 > Cell: +263 773226552 > Email: nyashandemo at gmail.com > > On Mon, Jul 20, 2026, 9:35?AM wrote: > > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Subject: Re: [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Thulisile > Mazomba) > 2. Re: [Last Call] Draft Policy Proposal ? Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Tshepo Masuku) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 20 Jul 2026 07:24:43 +0000 > From: Thulisile Mazomba <219280444 at mycput.ac.za> > To: Frank Habicht , "rpd at afrinic.net" > > Cc: "rpd-owner at afrinic.ne" > Subject: [rpd] Subject: Re: [Last Call] Draft Policy Proposal ? > Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > < > GVXPR04MB12291FB9551CD3D0ADB433FE6D1C32 at GVXPR04MB12291.eurprd04.prod.outlook.com > > > > Content-Type: text/plain; charset="windows-1252" > > Hi Frank, > > An improvement is not automatically a justification for mandatory policy. > > The question is whether the benefit is significant enough, proven enough, > and proportionate enough to place in the registry?s compulsory layer. > Saying ?it helps? does not answer that. > > And no, raising those questions does not mean the objection came first. It > means policy power should be tested before it is expanded. > > I remain opposed. > > Regards, > Thulisile > ________________________________ > From: Frank Habicht > Sent: Monday, 20 July 2026 06:36:00 > To: Thulisile Mazomba <219280444 at mycput.ac.za>; rpd at afrinic.net < > rpd at afrinic.net> > Cc: rpd-owner at afrinic.ne > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > Hi, > > On 7/19/2026 11:29 PM, Thulisile Mazomba wrote: > > > > Hi Frank, > > > > You appear to be treating your disagreement with an objection as proof > > that no technical objection exists. > > > > The proposal prevents one naming collision. It does not establish the > > correctness of the routing data attached to that name, > > The proposal does not fix *all* problems. and it doesn't claim to do so. > It creates an improvement. > I don't agree that it is ok to object just because this proposal does > not fix *all* problems. > > Do you agree it provides improvements? > > > nor prove that > > mandatory registry control is the only proportionate remedy. > > it's not intended to prove that. > > > > > Those are technical and policy questions. Declaring them invalid does > > not resolve them. > They are not good reasons against the proposal. > > But some people maybe want to be against the proposal first and then are > looking for "questions". > > Frank > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/a7286772/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Mon, 20 Jul 2026 07:34:21 +0000 > From: Tshepo Masuku > To: "rpd at afrinic.net" , "geier at geier.ne.tz" > > Subject: Re: [rpd] [Last Call] Draft Policy Proposal ? Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > < > VI2PR04MB10545520811A7499ACFFB1239CAC32 at VI2PR04MB10545.eurprd04.prod.outlook.com > > > > Content-Type: text/plain; charset="us-ascii" > > Hi Frank, > > You keep positioning yourself as the referee of which objections count. > > That is not your role. Participants are allowed to question whether a > useful change belongs in mandatory policy. Dismissing those concerns > instead of answering them turns discussion into gatekeeping. > > A policy room may debate. It does not grant any participant authority to > police dissent. > > I remain opposed. > > Regards, > Tshepo > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/0cd4be0c/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 81 > ************************************ > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > > Omo OAIYA > Chief Strategy Officer/Directeur de la Strat?gie | WACREN > > m: +234 808 888 1571 , +233 536 269 987 > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mselekuthandeka80 at gmail.com Mon Jul 20 15:22:43 2026 From: mselekuthandeka80 at gmail.com (Thandeka Mseleku) Date: Mon, 20 Jul 2026 17:22:43 +0200 Subject: [rpd] Request to Pause the AI Generated Posting Message-ID: Dear Noah, While I appreciate that this is your personal opinion, I do not believe assumptions about coordinated or AI-generated posts should be used as a basis for asking community members to pause their participation. The strength of the Policy Development Process lies in evaluating contributions on their technical and policy merits, regardless of whether participants reach similar conclusions. Agreement among contributors should not, by itself, be interpreted as evidence of coordination. I therefore believe the discussion should remain focused on the policy proposals themselves rather than on assumptions about the participants. BR, Thandeka Mseleku -------------- next part -------------- An HTML attachment was scrubbed... URL: From omo.oaiya at wacren.net Mon Jul 20 15:24:16 2026 From: omo.oaiya at wacren.net (Omo Oaiya) Date: Mon, 20 Jul 2026 18:24:16 +0300 Subject: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the AI Generated Posting In-Reply-To: <062601dd184f$72379070$56a6b150$@iptrading.com> References: <062601dd184f$72379070$56a6b150$@iptrading.com> Message-ID: Hi Mike, Fully agree, especially the distinction between swamping the list and treating AI-assisted arguments on their merits. On holiday and squandering quality time catching up with AFRINIC emails, and just said much the same to Ben on the AS-SET thread. Let's get on with the substance. Omo > On 20 Jul 2026, at 16:55, Mike Burns via RPD wrote: > > I am very happy that this list has some traffic, and separate from the AS-SET issue, the issue of AI generated posts is enormously interesting not only to this RIR policy list, but to all of them. > > My position is that there are two issues contained. One is the swamping of the list with AI generated posts. The other is the concept of treating AI posts like any other post. > > While I am against the use of AI to swamp the list with long messages in a Denial of Service sort of attack, I believe the principle of avoiding ad hominem arguments means that we have to treat the AI generated arguments the same as if they came directly from the pen of the poster. That is to say, ignore everything but the arguments being made, not the use of AI. It is the arguments that matter, not the speaker. > > I expect this to bubble up in other RIR policy lists as time goes on, it would be good to have some kind of principled response. > Many use translators to write posts in foreign languages, so certainly some tool use is expected. > > There are ways to block participants who transgress in other ways and those who post repeated AI slop to swamp the list should be so treated. > But unless there is an attempt by an individual to swamp the list, the posts should be treated as if written by the poster, that is like every other post. > > I am interested to hear other perspectives on this. > > Regards, > Mike > > > From: Taye Medoye > Sent: Monday, July 20, 2026 8:38 AM > To: rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the AI Generated Posting > > In regard to the ensuing antagonistic reponses relating to the call for the pause of AI generated mails, l align with the position expressed by Noah for obvious reasons: > > Firstly, the well referenced Policy Development Process (PDP) on open and unecumbered participation and expressions remains sancrosant, and a guiding principle. I think this priciple should be observed always; > > Secondly, l am not aware that the Forum gives the freedom to engage in any form of criticism on the contributions made by participants. > > Above all, l subscribe to the view that, while AI may be good in assisting with information as may be sought concerning any subject matter, l do not think it has the capacity to meet the prinicple of originality expected in any written literary work, whether in research or for informative diseemination purposes. > > The bottom line remains that, in line with the framework for particiapting in any discussion on this Forum, mutual respect for views should be upheld. > > Daniel Taye Medoye > > > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From mselekuthandeka80 at gmail.com Mon Jul 20 15:25:17 2026 From: mselekuthandeka80 at gmail.com (Thandeka Mseleku) Date: Mon, 20 Jul 2026 17:25:17 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear colleagues, I agree with the view expressed by Asamkele and others that this proposal has not demonstrated why registry enforcement is the appropriate solution. The discussion continues to assume that introducing mandatory hierarchical naming is the only effective way to address operational concerns, yet it has not shown why less restrictive approaches would be insufficient. I also believe the discussion should remain focused on the technical and policy merits of the proposal rather than assumptions about how participants prepare or present their contributions. Whether a contribution is concise, detailed, or drafted with writing tools does not change the validity of the arguments it contains. Each submission should be evaluated on its substance. For these reasons, I remain opposed to AFPUB-2026-ASN-001-DRAFT02. BR, Thandeka Mseleku -------------- next part -------------- An HTML attachment was scrubbed... URL: From phetulodhlamini at gmail.com Mon Jul 20 15:22:47 2026 From: phetulodhlamini at gmail.com (Phetulo Dhlamini) Date: Mon, 20 Jul 2026 17:22:47 +0200 Subject: [rpd] Request to Pause the AI generated posting Message-ID: Hi Noah, You are not entitled to prescribe which writing tools participants may use. That choice belongs to each contributor, provided they stand behind what they submit. We are in a digital age, and using emerging technology does not invalidate an argument. Asking people to stop participating because of the tools they may use risks turning process management into gatekeeping. The co-chairs may assess consensus. Individual participants do not have a mandate to suspend other voices while they wait. Regards, Phetulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandlamatshika at gmail.com Mon Jul 20 15:35:28 2026 From: mandlamatshika at gmail.com (Mandla Matshika) Date: Mon, 20 Jul 2026 17:35:28 +0200 Subject: [rpd] Intro Message-ID: Good day, Mandla,Policy insights contributor at NRS. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Mon Jul 20 15:40:20 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Mon, 20 Jul 2026 15:40:20 +0000 Subject: [rpd] Subject: Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Hi Omo, I agree that contributions should be judged on their substance. Whether I use a drafting or editing tool is my choice. I remain the author, I decide the position, and I take responsibility for what I submit. The tool is not the participant. The same standard should apply consistently across the process, including policy drafting, business planning, research, and correspondence. Unless a tool creates a factual or procedural problem, its use is not the community?s business. Participation does not require surrendering personal autonomy over how we prepare our words. Regards, Tshepo -------------- next part -------------- An HTML attachment was scrubbed... URL: From silber.mike at gmail.com Mon Jul 20 15:40:55 2026 From: silber.mike at gmail.com (Mike Silber) Date: Mon, 20 Jul 2026 17:40:55 +0200 Subject: [rpd] Writing tools In-Reply-To: <066b01dd185a$e13e9080$a3bbb180$@iptrading.com> References: <062601dd184f$72379070$56a6b150$@iptrading.com> <066b01dd185a$e13e9080$a3bbb180$@iptrading.com> Message-ID: A useful discussion - thank you On Mon, Jul 20, 2026 at 5:17?PM Mike Burns via RPD wrote: > Hi Rob, > > Yes, the language is a clear tell of AI usage, but flowery language alone > is not swamping the list. I don't want to hijack the AS-SET discussion, so thank you for the new > subject line. > Agreed > > Now, sometimes and unfortunately, I can use vague and flowery language > myself, so I would advise you to treat the AI stuff like the human stuff. > Ignore it if it's too vague or flowery to serve as a good argument, and > you have clearly laid out the two arguments in your last two lines. > Hopefully the list will show judgement and treat clear and concise > arguments better than vague ones. > And then the AI posts, if they want to be successful, will avoid the > purple prose. > I think it goes beyond flowery language. I am concerned that this is a precedent for AI generated DDoS attacks on the PDP and I do think we should have some light touch guidelines. I suspect that one of the reasons for the AI-slop flood is not just to try convince anyone of the value or legitimacy of their views but rather to overwhelm and frustrate other participants and cause them to withdraw from participation. Accordingly, I suggest we don't simply leave this to the co-chairs to determine on a case by case basis, but rather set some guidelines under which measures can be taken to avoid AI DDoS. Anyway - just my ZAR0,02 which is not worth much Regards Mike S -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Mon Jul 20 15:45:25 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Mon, 20 Jul 2026 17:45:25 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 101 In-Reply-To: References: Message-ID: Dear Omo and Ben, This discussion is becoming an authorship tribunal instead of a policy process. A mailing list may assess whether a contribution is relevant, evidenced, repetitive, or abusive. It has no mandate to police a participant?s private drafting tools or demand that unfamiliar contributors prove how every sentence was produced. A real person who submits a position, stands behind it, and accepts responsibility for it remains the participant. Templates, translation tools, editors, and AI assistance do not transfer authorship or judgment to the tool. The tool does not vote, object, or bear responsibility. The person does. If several messages raise the same objection, the co-chairs can group them as one issue and evaluate it once. That is sensible process management. What they should not do is erase the objection, interrogate the writers, or treat familiar names as more legitimate than unfamiliar ones. This is precisely where participation can be laundered into mandate: established participants begin by asking who wrote the message, then who the person represents, then whether the person is sufficiently experienced, and finally whether the contribution should count at all. An open process quietly becomes a permission system controlled by the people already closest to the microphone. A community may discuss. It may evaluate evidence. It may reject a weak argument. It may not turn familiarity into authority or curiosity about drafting into control over participation. The policy question remains the policy question. If the objection is wrong, answer it. If it is repeated, answer it once. But stop using speculation about tools and templates as a substitute for dealing with the substance. Regards, Nonhlanhla On Mon, 20 Jul 2026, 5:26 pm wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: Request to Pause the AI Generated Posting (Thandeka Mseleku) > 2. Re: RPD Digest, Vol 222, Issue 92: Request to Pause the AI > Generated Posting (Omo Oaiya) > 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Thandeka Mseleku) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 20 Jul 2026 17:22:43 +0200 > From: Thandeka Mseleku > To: rpd at afrinic.net > Cc: rpd-owner at afrinic.net > Subject: Re: [rpd] Request to Pause the AI Generated Posting > Message-ID: > jrQyMg at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Noah, > > While I appreciate that this is your personal opinion, I do not believe > assumptions about coordinated or AI-generated posts should be used as a > basis for asking community members to pause their participation. > > The strength of the Policy Development Process lies in evaluating > contributions on their technical and policy merits, regardless of whether > participants reach similar conclusions. Agreement among contributors should > not, by itself, be interpreted as evidence of coordination. > > I therefore believe the discussion should remain focused on the policy > proposals themselves rather than on assumptions about the participants. > > BR, > Thandeka Mseleku > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/495273c9/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Mon, 20 Jul 2026 18:24:16 +0300 > From: Omo Oaiya > To: Mike Burns > Cc: rpd at afrinic.net, Taye Medoye > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause > the AI Generated Posting > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > Hi Mike, > > Fully agree, especially the distinction between swamping the list and > treating AI-assisted arguments on their merits. On holiday and squandering > quality time catching up with AFRINIC emails, and just said much the same > to Ben on the AS-SET thread. > > Let's get on with the substance. > > Omo > > > On 20 Jul 2026, at 16:55, Mike Burns via RPD wrote: > > > > I am very happy that this list has some traffic, and separate from the > AS-SET issue, the issue of AI generated posts is enormously interesting not > only to this RIR policy list, but to all of them. > > > > My position is that there are two issues contained. One is the swamping > of the list with AI generated posts. The other is the concept of treating > AI posts like any other post. > > > > While I am against the use of AI to swamp the list with long messages in > a Denial of Service sort of attack, I believe the principle of avoiding ad > hominem arguments means that we have to treat the AI generated arguments > the same as if they came directly from the pen of the poster. That is to > say, ignore everything but the arguments being made, not the use of AI. It > is the arguments that matter, not the speaker. > > > > I expect this to bubble up in other RIR policy lists as time goes on, it > would be good to have some kind of principled response. > > Many use translators to write posts in foreign languages, so certainly > some tool use is expected. > > > > There are ways to block participants who transgress in other ways and > those who post repeated AI slop to swamp the list should be so treated. > > But unless there is an attempt by an individual to swamp the list, the > posts should be treated as if written by the poster, that is like every > other post. > > > > I am interested to hear other perspectives on this. > > > > Regards, > > Mike > > > > > > From: Taye Medoye > > Sent: Monday, July 20, 2026 8:38 AM > > To: rpd at afrinic.net > > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the > AI Generated Posting > > > > In regard to the ensuing antagonistic reponses relating to the call for > the pause of AI generated mails, l align with the position expressed by > Noah for obvious reasons: > > > > Firstly, the well referenced Policy Development Process (PDP) on open > and unecumbered participation and expressions remains sancrosant, and a > guiding principle. I think this priciple should be observed always; > > > > Secondly, l am not aware that the Forum gives the freedom to engage in > any form of criticism on the contributions made by participants. > > > > Above all, l subscribe to the view that, while AI may be good in > assisting with information as may be sought concerning any subject matter, > l do not think it has the capacity to meet the prinicple of originality > expected in any written literary work, whether in research or for > informative diseemination purposes. > > > > The bottom line remains that, in line with the framework for > particiapting in any discussion on this Forum, mutual respect for views > should be upheld. > > > > Daniel Taye Medoye > > > > > > > > > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/1ed5fc47/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Mon, 20 Jul 2026 17:25:17 +0200 > From: Thandeka Mseleku > To: rpd at afrinic.net > Cc: rpd-owner at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > < > CA+mVb0nk0PyaW+uE7ZNtxmA-cyVh5_V4h5+M7QdWgSR90uLqVg at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear colleagues, > > I agree with the view expressed by Asamkele and others that this proposal > has not demonstrated why registry enforcement is the appropriate solution. > The discussion continues to assume that introducing mandatory hierarchical > naming is the only effective way to address operational concerns, yet it > has not shown why less restrictive approaches would be insufficient. > > I also believe the discussion should remain focused on the technical and > policy merits of the proposal rather than assumptions about how > participants prepare or present their contributions. Whether a contribution > is concise, detailed, or drafted with writing tools does not change the > validity of the arguments it contains. Each submission should be evaluated > on its substance. > > For these reasons, I remain opposed to AFPUB-2026-ASN-001-DRAFT02. > > BR, > Thandeka Mseleku > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/a209f273/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 101 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.medoye at gmail.com Mon Jul 20 15:48:51 2026 From: daniel.medoye at gmail.com (Taye Medoye) Date: Mon, 20 Jul 2026 17:48:51 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the AI Generated Posting In-Reply-To: <062601dd184f$72379070$56a6b150$@iptrading.com> References: <062601dd184f$72379070$56a6b150$@iptrading.com> Message-ID: Dear Mike, I do hope that the usefulness of AI in assisting to generate relevant information is not being undermined here, as contributions on writing tools tend to suggest. In this regard, l want to align with the position of Mike, to the extent of his disapproval of the use of AI to swamp the list with long messages in a denial of service sort of attack....... However, the discussion is drifting from the proposal into judgments about who is speaking and how they prepared their words. That is a wrong test. A participant may use translation, editing, or drafting assistance and still remain fully responsible for the position expressed. The policy question is whether mandatory hierarchical naming is necessary, proportionate, and limited to a genuine technical invariant. Operational benefits are relevant, but they do not automatically create policy authority. Nor does support from established participants become ?community consensus? merely because those voices are familiar. The co-chairs should separate distinct arguments, test the evidence, and avoid turning participation into mandate. The community may advise, support, warn, and object. It does not acquire ownership over dissent. I think the use of AI generated information should be viewed in the context of how it is projected to address the issue of concern, and its veriability. Regards, Taye Medoye On Mon, 20 Jul 2026 at 15:55, Mike Burns wrote: > I am very happy that this list has some traffic, and separate from the > AS-SET issue, the issue of AI generated posts is enormously interesting not > only to this RIR policy list, but to all of them. > > > > My position is that there are two issues contained. One is the swamping of > the list with AI generated posts. The other is the concept of treating AI > posts like any other post. > > > > While I am against the use of AI to swamp the list with long messages in a > Denial of Service sort of attack, I believe the principle of avoiding ad > hominem arguments means that we have to treat the AI generated arguments > the same as if they came directly from the pen of the poster. That is to > say, ignore everything but the arguments being made, not the use of AI. It > is the arguments that matter, not the speaker. > > > > I expect this to bubble up in other RIR policy lists as time goes on, it > would be good to have some kind of principled response. > > Many use translators to write posts in foreign languages, so certainly > some tool use is expected. > > > > There are ways to block participants who transgress in other ways and > those who post repeated AI slop to swamp the list should be so treated. > > But unless there is an attempt by an individual to swamp the list, the > posts should be treated as if written by the poster, that is like every > other post. > > > > I am interested to hear other perspectives on this. > > > > Regards, > Mike > > > > > > *From:* Taye Medoye > *Sent:* Monday, July 20, 2026 8:38 AM > *To:* rpd at afrinic.net > *Subject:* Re: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the > AI Generated Posting > > > > In regard to the ensuing antagonistic reponses relating to the call for > the pause of AI generated mails, l align with the position expressed by > Noah for obvious reasons: > > > > Firstly, the well referenced Policy Development Process (PDP) on open and > unecumbered participation and expressions remains sancrosant, and a guiding > principle. I think this priciple should be observed always; > > > > Secondly, l am not aware that the Forum gives the freedom to engage in any > form of criticism on the contributions made by participants. > > > > Above all, l subscribe to the view that, while AI may be good in assisting > with information as may be sought concerning any subject matter, l do not > think it has the capacity to meet the prinicple of originality expected in > any written literary work, whether in research or for informative > diseemination purposes. > > > > The bottom line remains that, in line with the framework for particiapting > in any discussion on this Forum, mutual respect for views should be upheld. > > > > Daniel Taye Medoye > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonjabulosphilile at gmail.com Mon Jul 20 16:01:51 2026 From: nonjabulosphilile at gmail.com (Nonjabulo Sphilile) Date: Mon, 20 Jul 2026 18:01:51 +0200 Subject: [rpd] Writing tools Message-ID: Dear Mike, The ?AI DDoS? analogy is the wrong category. Participants are not packets, and disagreement is not an attack on the process. The list may regulate actual conduct such as automated flooding, impersonation, excessive duplication, or deliberate disruption. It should not infer abuse from writing style or from the use of a drafting tool. A person who reviews, submits, and stands behind a message remains responsible for it. Any guideline must therefore be tool-neutral and based on measurable behaviour. Otherwise process management becomes a mechanism for filtering unfamiliar or inconvenient voices while established participants continue to define what counts as legitimate participation. Rough consensus is not protected by narrowing the room. It is protected by identifying distinct issues, answering them on their merits, and refusing to turn procedural control into institutional mandate. I oppose any rule that treats AI assistance itself as presumptive misconduct. Regards, Nonjabulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From gugudhlamini343 at gmail.com Mon Jul 20 16:02:14 2026 From: gugudhlamini343 at gmail.com (Gugu Dhlamini) Date: Mon, 20 Jul 2026 18:02:14 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the AI Generated Posting In-Reply-To: References: <062601dd184f$72379070$56a6b150$@iptrading.com> Message-ID: Dear Mike, I support the use of AI-assisted drafting. I pay for the tool, I choose when to use it, and I remain responsible for every message I submit. The software is not participating in the PDWG. I am. The list may address actual misconduct such as spam, impersonation, automated flooding, or excessive duplication. It should not police lawful writing tools simply because some participants dislike them. Participation should be judged by substance and conduct, not by whether someone used modern technology to express a view. Otherwise, familiar participants turn personal preference into an unwritten permission system. My tools are my choice. My words remain my responsibility. Regards, Gugu On Mon, 20 Jul 2026, 5:49 pm Taye Medoye wrote: > Dear Mike, > > I do hope that the usefulness of AI in assisting to generate relevant > information is not being undermined here, as contributions on writing tools > tend to suggest. In this regard, l want to align with the position of > Mike, to the extent of his disapproval of the use of AI to swamp the list > with long messages in a denial of service sort of attack....... > > However, the discussion is drifting from the proposal into judgments > about who is speaking and how they prepared their words. > > That is a wrong test. > > A participant may use translation, editing, or drafting assistance and > still remain fully responsible for the position expressed. The policy > question is whether mandatory hierarchical naming is necessary, > proportionate, and limited to a genuine technical invariant. > > Operational benefits are relevant, but they do not automatically create > policy authority. Nor does support from established participants become > ?community consensus? merely because those voices are familiar. > > The co-chairs should separate distinct arguments, test the evidence, and > avoid turning participation into mandate. The community may advise, > support, warn, and object. It does not acquire ownership over dissent. > > I think the use of AI generated information should be viewed in the > context of how it is projected to address the issue of concern, and its > veriability. > > Regards, > > Taye Medoye > > > > > > > > On Mon, 20 Jul 2026 at 15:55, Mike Burns wrote: > >> I am very happy that this list has some traffic, and separate from the >> AS-SET issue, the issue of AI generated posts is enormously interesting not >> only to this RIR policy list, but to all of them. >> >> >> >> My position is that there are two issues contained. One is the swamping >> of the list with AI generated posts. The other is the concept of treating >> AI posts like any other post. >> >> >> >> While I am against the use of AI to swamp the list with long messages in >> a Denial of Service sort of attack, I believe the principle of avoiding ad >> hominem arguments means that we have to treat the AI generated arguments >> the same as if they came directly from the pen of the poster. That is to >> say, ignore everything but the arguments being made, not the use of AI. It >> is the arguments that matter, not the speaker. >> >> >> >> I expect this to bubble up in other RIR policy lists as time goes on, it >> would be good to have some kind of principled response. >> >> Many use translators to write posts in foreign languages, so certainly >> some tool use is expected. >> >> >> >> There are ways to block participants who transgress in other ways and >> those who post repeated AI slop to swamp the list should be so treated. >> >> But unless there is an attempt by an individual to swamp the list, the >> posts should be treated as if written by the poster, that is like every >> other post. >> >> >> >> I am interested to hear other perspectives on this. >> >> >> >> Regards, >> Mike >> >> >> >> >> >> *From:* Taye Medoye >> *Sent:* Monday, July 20, 2026 8:38 AM >> *To:* rpd at afrinic.net >> *Subject:* Re: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the >> AI Generated Posting >> >> >> >> In regard to the ensuing antagonistic reponses relating to the call for >> the pause of AI generated mails, l align with the position expressed by >> Noah for obvious reasons: >> >> >> >> Firstly, the well referenced Policy Development Process (PDP) on open and >> unecumbered participation and expressions remains sancrosant, and a guiding >> principle. I think this priciple should be observed always; >> >> >> >> Secondly, l am not aware that the Forum gives the freedom to engage in >> any form of criticism on the contributions made by participants. >> >> >> >> Above all, l subscribe to the view that, while AI may be good in >> assisting with information as may be sought concerning any subject matter, >> l do not think it has the capacity to meet the prinicple of originality >> expected in any written literary work, whether in research or for >> informative diseemination purposes. >> >> >> >> The bottom line remains that, in line with the framework for >> particiapting in any discussion on this Forum, mutual respect for views >> should be upheld. >> >> >> >> Daniel Taye Medoye >> >> >> >> >> >> >> >> >> >> >> > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Mon Jul 20 16:14:42 2026 From: mike at iptrading.com (Mike Burns) Date: Mon, 20 Jul 2026 12:14:42 -0400 Subject: [rpd] Writing tools In-Reply-To: References: Message-ID: <06e701dd1862$df4b2b50$9de181f0$@iptrading.com> Hi Nonjablulo, I want to be clear that AI DDos is the same as automated flooding. AI can generate non-duplicative prompts more quickly and easily than anything else, which provide a tool for list-swamping. What that can do is render the list unusable. Note that I do not see that happening in any current conversations. And as I pointed out, existing procedures can take care of list flooding, whether AI generated or not. I thought I was clear that absent the flooding I called a DDoS, all arguments should be considered on their merits. I personally don?t care where the argument comes from. Regards, Mike From: Nonjabulo Sphilile Sent: Monday, July 20, 2026 12:02 PM To: rpd at afrinic.net Subject: Re: [rpd] Writing tools Dear Mike, The ?AI DDoS? analogy is the wrong category. Participants are not packets, and disagreement is not an attack on the process. The list may regulate actual conduct such as automated flooding, impersonation, excessive duplication, or deliberate disruption. It should not infer abuse from writing style or from the use of a drafting tool. A person who reviews, submits, and stands behind a message remains responsible for it. Any guideline must therefore be tool-neutral and based on measurable behaviour. Otherwise process management becomes a mechanism for filtering unfamiliar or inconvenient voices while established participants continue to define what counts as legitimate participation. Rough consensus is not protected by narrowing the room. It is protected by identifying distinct issues, answering them on their merits, and refusing to turn procedural control into institutional mandate. I oppose any rule that treats AI assistance itself as presumptive misconduct. Regards, Nonjabulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Mon Jul 20 16:15:52 2026 From: mike at iptrading.com (Mike Burns) Date: Mon, 20 Jul 2026 12:15:52 -0400 Subject: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the AI Generated Posting In-Reply-To: References: <062601dd184f$72379070$56a6b150$@iptrading.com> Message-ID: <06ec01dd1863$092791c0$1b76b540$@iptrading.com> Hi Gugu, I wonder if you actually read my post, as I completely agree with your rewording of it. Regards, Mike From: Gugu Dhlamini Sent: Monday, July 20, 2026 12:02 PM To: rpd at afrinic.net Subject: Re: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the AI Generated Posting Dear Mike, I support the use of AI-assisted drafting. I pay for the tool, I choose when to use it, and I remain responsible for every message I submit. The software is not participating in the PDWG. I am. The list may address actual misconduct such as spam, impersonation, automated flooding, or excessive duplication. It should not police lawful writing tools simply because some participants dislike them. Participation should be judged by substance and conduct, not by whether someone used modern technology to express a view. Otherwise, familiar participants turn personal preference into an unwritten permission system. My tools are my choice. My words remain my responsibility. Regards, Gugu On Mon, 20 Jul 2026, 5:49 pm Taye Medoye > wrote: Dear Mike, I do hope that the usefulness of AI in assisting to generate relevant information is not being undermined here, as contributions on writing tools tend to suggest. In this regard, l want to align with the position of Mike, to the extent of his disapproval of the use of AI to swamp the list with long messages in a denial of service sort of attack....... However, the discussion is drifting from the proposal into judgments about who is speaking and how they prepared their words. That is a wrong test. A participant may use translation, editing, or drafting assistance and still remain fully responsible for the position expressed. The policy question is whether mandatory hierarchical naming is necessary, proportionate, and limited to a genuine technical invariant. Operational benefits are relevant, but they do not automatically create policy authority. Nor does support from established participants become ?community consensus? merely because those voices are familiar. The co-chairs should separate distinct arguments, test the evidence, and avoid turning participation into mandate. The community may advise, support, warn, and object. It does not acquire ownership over dissent. I think the use of AI generated information should be viewed in the context of how it is projected to address the issue of concern, and its veriability. Regards, Taye Medoye On Mon, 20 Jul 2026 at 15:55, Mike Burns > wrote: I am very happy that this list has some traffic, and separate from the AS-SET issue, the issue of AI generated posts is enormously interesting not only to this RIR policy list, but to all of them. My position is that there are two issues contained. One is the swamping of the list with AI generated posts. The other is the concept of treating AI posts like any other post. While I am against the use of AI to swamp the list with long messages in a Denial of Service sort of attack, I believe the principle of avoiding ad hominem arguments means that we have to treat the AI generated arguments the same as if they came directly from the pen of the poster. That is to say, ignore everything but the arguments being made, not the use of AI. It is the arguments that matter, not the speaker. I expect this to bubble up in other RIR policy lists as time goes on, it would be good to have some kind of principled response. Many use translators to write posts in foreign languages, so certainly some tool use is expected. There are ways to block participants who transgress in other ways and those who post repeated AI slop to swamp the list should be so treated. But unless there is an attempt by an individual to swamp the list, the posts should be treated as if written by the poster, that is like every other post. I am interested to hear other perspectives on this. Regards, Mike From: Taye Medoye > Sent: Monday, July 20, 2026 8:38 AM To: rpd at afrinic.net Subject: Re: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the AI Generated Posting In regard to the ensuing antagonistic reponses relating to the call for the pause of AI generated mails, l align with the position expressed by Noah for obvious reasons: Firstly, the well referenced Policy Development Process (PDP) on open and unecumbered participation and expressions remains sancrosant, and a guiding principle. I think this priciple should be observed always; Secondly, l am not aware that the Forum gives the freedom to engage in any form of criticism on the contributions made by participants. Above all, l subscribe to the view that, while AI may be good in assisting with information as may be sought concerning any subject matter, l do not think it has the capacity to meet the prinicple of originality expected in any written literary work, whether in research or for informative diseemination purposes. The bottom line remains that, in line with the framework for particiapting in any discussion on this Forum, mutual respect for views should be upheld. Daniel Taye Medoye _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From gugudhlamini343 at gmail.com Mon Jul 20 16:29:35 2026 From: gugudhlamini343 at gmail.com (Gugu Dhlamini) Date: Mon, 20 Jul 2026 18:29:35 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the AI Generated Posting In-Reply-To: <06ec01dd1863$092791c0$1b76b540$@iptrading.com> References: <062601dd184f$72379070$56a6b150$@iptrading.com> <06ec01dd1863$092791c0$1b76b540$@iptrading.com> Message-ID: Hi Mike, Then we agree on the important principle: moderate actual disruptive conduct, not the tool, and assess every contribution on its substance. The participant remains responsible for the message. That keeps the process open without turning moderation into gatekeeping. Regards, Gugu On Mon, 20 Jul 2026, 6:15 pm Mike Burns wrote: > Hi Gugu, > > > > I wonder if you actually read my post, as I completely agree with your > rewording of it. > > > > Regards, > Mike > > > > > > *From:* Gugu Dhlamini > *Sent:* Monday, July 20, 2026 12:02 PM > *To:* rpd at afrinic.net > *Subject:* Re: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the > AI Generated Posting > > > > Dear Mike, > > I support the use of AI-assisted drafting. I pay for the tool, I choose > when to use it, and I remain responsible for every message I submit. The > software is not participating in the PDWG. I am. > > The list may address actual misconduct such as spam, impersonation, > automated flooding, or excessive duplication. It should not police lawful > writing tools simply because some participants dislike them. > > Participation should be judged by substance and conduct, not by whether > someone used modern technology to express a view. Otherwise, familiar > participants turn personal preference into an unwritten permission system. > > My tools are my choice. My words remain my responsibility. > > Regards, > Gugu > > > > On Mon, 20 Jul 2026, 5:49 pm Taye Medoye wrote: > > Dear Mike, > > > > I do hope that the usefulness of AI in assisting to generate relevant > information is not being undermined here, as contributions on writing tools > tend to suggest. In this regard, l want to align with the position of Mike, > to the extent of his disapproval of the use of AI to swamp the list with > long messages in a denial of service sort of attack....... > > > > However, the discussion is drifting from the proposal into judgments about > who is speaking and how they prepared their words. > > > That is a wrong test. > > A participant may use translation, editing, or drafting assistance and > still remain fully responsible for the position expressed. The policy > question is whether mandatory hierarchical naming is necessary, > proportionate, and limited to a genuine technical invariant. > > Operational benefits are relevant, but they do not automatically create > policy authority. Nor does support from established participants become > ?community consensus? merely because those voices are familiar. > > The co-chairs should separate distinct arguments, test the evidence, and > avoid turning participation into mandate. The community may advise, > support, warn, and object. It does not acquire ownership over dissent. > > > > I think the use of AI generated information should be viewed in the > context of how it is projected to address the issue of concern, and its > veriability. > > Regards, > > > Taye Medoye > > > > > > > > > > > > > > > On Mon, 20 Jul 2026 at 15:55, Mike Burns wrote: > > I am very happy that this list has some traffic, and separate from the > AS-SET issue, the issue of AI generated posts is enormously interesting not > only to this RIR policy list, but to all of them. > > > > My position is that there are two issues contained. One is the swamping of > the list with AI generated posts. The other is the concept of treating AI > posts like any other post. > > > > While I am against the use of AI to swamp the list with long messages in a > Denial of Service sort of attack, I believe the principle of avoiding ad > hominem arguments means that we have to treat the AI generated arguments > the same as if they came directly from the pen of the poster. That is to > say, ignore everything but the arguments being made, not the use of AI. It > is the arguments that matter, not the speaker. > > > > I expect this to bubble up in other RIR policy lists as time goes on, it > would be good to have some kind of principled response. > > Many use translators to write posts in foreign languages, so certainly > some tool use is expected. > > > > There are ways to block participants who transgress in other ways and > those who post repeated AI slop to swamp the list should be so treated. > > But unless there is an attempt by an individual to swamp the list, the > posts should be treated as if written by the poster, that is like every > other post. > > > > I am interested to hear other perspectives on this. > > > > Regards, > Mike > > > > > > *From:* Taye Medoye > *Sent:* Monday, July 20, 2026 8:38 AM > *To:* rpd at afrinic.net > *Subject:* Re: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the > AI Generated Posting > > > > In regard to the ensuing antagonistic reponses relating to the call for > the pause of AI generated mails, l align with the position expressed by > Noah for obvious reasons: > > > > Firstly, the well referenced Policy Development Process (PDP) on open and > unecumbered participation and expressions remains sancrosant, and a guiding > principle. I think this priciple should be observed always; > > > > Secondly, l am not aware that the Forum gives the freedom to engage in any > form of criticism on the contributions made by participants. > > > > Above all, l subscribe to the view that, while AI may be good in assisting > with information as may be sought concerning any subject matter, l do not > think it has the capacity to meet the prinicple of originality expected in > any written literary work, whether in research or for informative > diseemination purposes. > > > > The bottom line remains that, in line with the framework for particiapting > in any discussion on this Forum, mutual respect for views should be upheld. > > > > Daniel Taye Medoye > > > > > > > > > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Mon Jul 20 16:34:33 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Mon, 20 Jul 2026 18:34:33 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 105 In-Reply-To: References: Message-ID: Hi all, I think this discussion is drifting away from the policy itself. Whether someone drafts a message with or without a writing tool does not determine whether the points raised are valid. Every participant remains responsible for what they submit, and those submissions should be assessed on their technical and policy merits. At the same time, I agree that discussions are more productive when contributions are clear, concise, and responsive to the points being debated. That expectation applies equally to everyone, regardless of how they prepare their emails. If a particular argument is unclear or unsupported, it should be challenged on its substance. Focusing on the tool used to write it risks overlooking the actual issues under discussion. The Policy Development Process is strongest when it welcomes participation while maintaining a high standard of evidence and technical reasoning. Regards, Fundiswa Nadia Maseko On Mon, 20 Jul 2026, 18:16 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: Writing tools (Mike Burns) > 2. Re: RPD Digest, Vol 222, Issue 92: Request to Pause the AI > Generated Posting (Mike Burns) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 20 Jul 2026 12:14:42 -0400 > From: "Mike Burns" > To: "'Nonjabulo Sphilile'" , > > Subject: Re: [rpd] Writing tools > Message-ID: <06e701dd1862$df4b2b50$9de181f0$@iptrading.com> > Content-Type: text/plain; charset="utf-8" > > Hi Nonjablulo, > > > > I want to be clear that AI DDos is the same as automated flooding. AI can > generate non-duplicative prompts more quickly and easily than anything > else, which provide a tool for list-swamping. > > What that can do is render the list unusable. > > Note that I do not see that happening in any current conversations. > > And as I pointed out, existing procedures can take care of list flooding, > whether AI generated or not. > > > > I thought I was clear that absent the flooding I called a DDoS, all > arguments should be considered on their merits. > > I personally don?t care where the argument comes from. > > > > Regards, > Mike > > > > > > From: Nonjabulo Sphilile > Sent: Monday, July 20, 2026 12:02 PM > To: rpd at afrinic.net > Subject: Re: [rpd] Writing tools > > > > Dear Mike, > > > > The ?AI DDoS? analogy is the wrong category. Participants are not packets, > and disagreement is not an attack on the process. > > > > The list may regulate actual conduct such as automated flooding, > impersonation, excessive duplication, or deliberate disruption. It should > not infer abuse from writing style or from the use of a drafting tool. A > person who reviews, submits, and stands behind a message remains > responsible for it. > > > > Any guideline must therefore be tool-neutral and based on measurable > behaviour. Otherwise process management becomes a mechanism for filtering > unfamiliar or inconvenient voices while established participants continue > to define what counts as legitimate participation. > > > > Rough consensus is not protected by narrowing the room. It is protected by > identifying distinct issues, answering them on their merits, and refusing > to turn procedural control into institutional mandate. > > > > I oppose any rule that treats AI assistance itself as presumptive > misconduct. > > > > Regards, > > Nonjabulo > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/faab8042/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Mon, 20 Jul 2026 12:15:52 -0400 > From: "Mike Burns" > To: "'Gugu Dhlamini'" , > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the > AI Generated Posting > Message-ID: <06ec01dd1863$092791c0$1b76b540$@iptrading.com> > Content-Type: text/plain; charset="utf-8" > > Hi Gugu, > > > > I wonder if you actually read my post, as I completely agree with your > rewording of it. > > > > Regards, > Mike > > > > > > From: Gugu Dhlamini > Sent: Monday, July 20, 2026 12:02 PM > To: rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the AI > Generated Posting > > > > Dear Mike, > > I support the use of AI-assisted drafting. I pay for the tool, I choose > when to use it, and I remain responsible for every message I submit. The > software is not participating in the PDWG. I am. > > The list may address actual misconduct such as spam, impersonation, > automated flooding, or excessive duplication. It should not police lawful > writing tools simply because some participants dislike them. > > Participation should be judged by substance and conduct, not by whether > someone used modern technology to express a view. Otherwise, familiar > participants turn personal preference into an unwritten permission system. > > My tools are my choice. My words remain my responsibility. > > Regards, > Gugu > > > > On Mon, 20 Jul 2026, 5:49 pm Taye Medoye daniel.medoye at gmail.com> > wrote: > > Dear Mike, > > > > I do hope that the usefulness of AI in assisting to generate relevant > information is not being undermined here, as contributions on writing tools > tend to suggest. In this regard, l want to align with the position of Mike, > to the extent of his disapproval of the use of AI to swamp the list with > long messages in a denial of service sort of attack....... > > > > However, the discussion is drifting from the proposal into judgments about > who is speaking and how they prepared their words. > > > That is a wrong test. > > A participant may use translation, editing, or drafting assistance and > still remain fully responsible for the position expressed. The policy > question is whether mandatory hierarchical naming is necessary, > proportionate, and limited to a genuine technical invariant. > > Operational benefits are relevant, but they do not automatically create > policy authority. Nor does support from established participants become > ?community consensus? merely because those voices are familiar. > > The co-chairs should separate distinct arguments, test the evidence, and > avoid turning participation into mandate. The community may advise, > support, warn, and object. It does not acquire ownership over dissent. > > > > I think the use of AI generated information should be viewed in the > context of how it is projected to address the issue of concern, and its > veriability. > > Regards, > > > Taye Medoye > > > > > > > > > > > > > > On Mon, 20 Jul 2026 at 15:55, Mike Burns mike at iptrading.com> > wrote: > > I am very happy that this list has some traffic, and separate from the > AS-SET issue, the issue of AI generated posts is enormously interesting not > only to this RIR policy list, but to all of them. > > > > My position is that there are two issues contained. One is the swamping of > the list with AI generated posts. The other is the concept of treating AI > posts like any other post. > > > > While I am against the use of AI to swamp the list with long messages in a > Denial of Service sort of attack, I believe the principle of avoiding ad > hominem arguments means that we have to treat the AI generated arguments > the same as if they came directly from the pen of the poster. That is to > say, ignore everything but the arguments being made, not the use of AI. It > is the arguments that matter, not the speaker. > > > > I expect this to bubble up in other RIR policy lists as time goes on, it > would be good to have some kind of principled response. > > Many use translators to write posts in foreign languages, so certainly > some tool use is expected. > > > > There are ways to block participants who transgress in other ways and > those who post repeated AI slop to swamp the list should be so treated. > > But unless there is an attempt by an individual to swamp the list, the > posts should be treated as if written by the poster, that is like every > other post. > > > > I am interested to hear other perspectives on this. > > > > Regards, > Mike > > > > > > From: Taye Medoye > > > Sent: Monday, July 20, 2026 8:38 AM > To: rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the AI > Generated Posting > > > > In regard to the ensuing antagonistic reponses relating to the call for > the pause of AI generated mails, l align with the position expressed by > Noah for obvious reasons: > > > > Firstly, the well referenced Policy Development Process (PDP) on open and > unecumbered participation and expressions remains sancrosant, and a guiding > principle. I think this priciple should be observed always; > > > > Secondly, l am not aware that the Forum gives the freedom to engage in any > form of criticism on the contributions made by participants. > > > > Above all, l subscribe to the view that, while AI may be good in assisting > with information as may be sought concerning any subject matter, l do not > think it has the capacity to meet the prinicple of originality expected in > any written literary work, whether in research or for informative > diseemination purposes. > > > > The bottom line remains that, in line with the framework for particiapting > in any discussion on this Forum, mutual respect for views should be upheld. > > > > Daniel Taye Medoye > > > > > > > > > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/5ac94fac/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 105 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phetulodhlamini at gmail.com Mon Jul 20 16:35:41 2026 From: phetulodhlamini at gmail.com (Phetulo Dhlamini) Date: Mon, 20 Jul 2026 18:35:41 +0200 Subject: [rpd] Writing tools Message-ID: Hi Mike, On that point, we?re closer than it first appeared. Actual flooding, whether automated or not, should be handled under the existing list rules. My concern is with the phrase ?AI DDoS,? because it can stigmatise ordinary AI-assisted participation before any disruptive conduct has occurred. The fair test is behaviour, not the tool: excessive volume, duplication, impersonation, or deliberate disruption can be moderated. A real participant who submits a message and stands behind it should still have the argument considered on its merits. That keeps the process open without turning moderation into gatekeeping over which tools people may use. Regards, Phetulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From gugudhlamini343 at gmail.com Mon Jul 20 16:58:46 2026 From: gugudhlamini343 at gmail.com (Gugu Dhlamini) Date: Mon, 20 Jul 2026 18:58:46 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the AI Generated Posting In-Reply-To: <070a01dd1866$eaa5ad00$bff10700$@iptrading.com> References: <062601dd184f$72379070$56a6b150$@iptrading.com> <06ec01dd1863$092791c0$1b76b540$@iptrading.com> <070a01dd1866$eaa5ad00$bff10700$@iptrading.com> Message-ID: Hi Mike, Thank you for clarifying. I?ll leave the matter there, with the expectation that the same standard is applied consistently to all participants. Regards, Gugu On Mon, 20 Jul 2026, 6:43 pm Mike Burns wrote: > Hi Gugu, > > > > Off-list. Yes, of course. > > I was clear to distinguish between list-flooding as a sort of Denial of > Service from simply using AI. > > Who cares who wrote the message? The list is open to everybody. > > That in itself is to ensure that the message is what matters, not some > gatekeeping of participants. > > I didn?t want to clutter the list with more discussion of this matter, but > there is a new thread now with the Subject line Writing tools. > > > > Regards, > Mike > > > > > > > > > > > > > > > > > > > > *From:* Gugu Dhlamini > *Sent:* Monday, July 20, 2026 12:30 PM > *To:* Mike Burns ; rpd at afrinic.net > *Subject:* Re: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the > AI Generated Posting > > > > Hi Mike, > > Then we agree on the important principle: moderate actual disruptive > conduct, not the tool, and assess every contribution on its substance. > > The participant remains responsible for the message. That keeps the > process open without turning moderation into gatekeeping. > > Regards, > Gugu > > > > On Mon, 20 Jul 2026, 6:15 pm Mike Burns wrote: > > Hi Gugu, > > > > I wonder if you actually read my post, as I completely agree with your > rewording of it. > > > > Regards, > Mike > > > > > > *From:* Gugu Dhlamini > *Sent:* Monday, July 20, 2026 12:02 PM > *To:* rpd at afrinic.net > *Subject:* Re: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the > AI Generated Posting > > > > Dear Mike, > > I support the use of AI-assisted drafting. I pay for the tool, I choose > when to use it, and I remain responsible for every message I submit. The > software is not participating in the PDWG. I am. > > The list may address actual misconduct such as spam, impersonation, > automated flooding, or excessive duplication. It should not police lawful > writing tools simply because some participants dislike them. > > Participation should be judged by substance and conduct, not by whether > someone used modern technology to express a view. Otherwise, familiar > participants turn personal preference into an unwritten permission system. > > My tools are my choice. My words remain my responsibility. > > Regards, > Gugu > > > > On Mon, 20 Jul 2026, 5:49 pm Taye Medoye wrote: > > Dear Mike, > > > > I do hope that the usefulness of AI in assisting to generate relevant > information is not being undermined here, as contributions on writing tools > tend to suggest. In this regard, l want to align with the position of Mike, > to the extent of his disapproval of the use of AI to swamp the list with > long messages in a denial of service sort of attack....... > > > > However, the discussion is drifting from the proposal into judgments about > who is speaking and how they prepared their words. > > > That is a wrong test. > > A participant may use translation, editing, or drafting assistance and > still remain fully responsible for the position expressed. The policy > question is whether mandatory hierarchical naming is necessary, > proportionate, and limited to a genuine technical invariant. > > Operational benefits are relevant, but they do not automatically create > policy authority. Nor does support from established participants become > ?community consensus? merely because those voices are familiar. > > The co-chairs should separate distinct arguments, test the evidence, and > avoid turning participation into mandate. The community may advise, > support, warn, and object. It does not acquire ownership over dissent. > > > > I think the use of AI generated information should be viewed in the > context of how it is projected to address the issue of concern, and its > veriability. > > Regards, > > > Taye Medoye > > > > > > > > > > > > > > > On Mon, 20 Jul 2026 at 15:55, Mike Burns wrote: > > I am very happy that this list has some traffic, and separate from the > AS-SET issue, the issue of AI generated posts is enormously interesting not > only to this RIR policy list, but to all of them. > > > > My position is that there are two issues contained. One is the swamping of > the list with AI generated posts. The other is the concept of treating AI > posts like any other post. > > > > While I am against the use of AI to swamp the list with long messages in a > Denial of Service sort of attack, I believe the principle of avoiding ad > hominem arguments means that we have to treat the AI generated arguments > the same as if they came directly from the pen of the poster. That is to > say, ignore everything but the arguments being made, not the use of AI. It > is the arguments that matter, not the speaker. > > > > I expect this to bubble up in other RIR policy lists as time goes on, it > would be good to have some kind of principled response. > > Many use translators to write posts in foreign languages, so certainly > some tool use is expected. > > > > There are ways to block participants who transgress in other ways and > those who post repeated AI slop to swamp the list should be so treated. > > But unless there is an attempt by an individual to swamp the list, the > posts should be treated as if written by the poster, that is like every > other post. > > > > I am interested to hear other perspectives on this. > > > > Regards, > Mike > > > > > > *From:* Taye Medoye > *Sent:* Monday, July 20, 2026 8:38 AM > *To:* rpd at afrinic.net > *Subject:* Re: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the > AI Generated Posting > > > > In regard to the ensuing antagonistic reponses relating to the call for > the pause of AI generated mails, l align with the position expressed by > Noah for obvious reasons: > > > > Firstly, the well referenced Policy Development Process (PDP) on open and > unecumbered participation and expressions remains sancrosant, and a guiding > principle. I think this priciple should be observed always; > > > > Secondly, l am not aware that the Forum gives the freedom to engage in any > form of criticism on the contributions made by participants. > > > > Above all, l subscribe to the view that, while AI may be good in assisting > with information as may be sought concerning any subject matter, l do not > think it has the capacity to meet the prinicple of originality expected in > any written literary work, whether in research or for informative > diseemination purposes. > > > > The bottom line remains that, in line with the framework for particiapting > in any discussion on this Forum, mutual respect for views should be upheld. > > > > Daniel Taye Medoye > > > > > > > > > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kwandokuhlebhembe at gmail.com Mon Jul 20 17:32:52 2026 From: kwandokuhlebhembe at gmail.com (Kwandokuhle Bhembe) Date: Mon, 20 Jul 2026 19:32:52 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 107 In-Reply-To: References: Message-ID: Hi, I guess I'm support of this Ultimately, proponents of Artificial Intelligence conclude that the technology is not a replacement for humanity, but rather the next logical step in our technological evolution. History proves that every major industrial shift creates initial fear, yet ultimately delivers higher productivity, new job sectors, and an elevated global standard of living. By acting as the ultimate intellectual co-pilot, AI liberates workers from grueling administrative tasks, allowing society to refocus on empathy, deep strategy, and genuine creative innovation. Furthermore, the immense global challenges of the twenty-first century?from predicting climate disruptions to curing complex diseases?require computational power far beyond human capability. Rather than a threat to our autonomy, AI stands as the single most powerful tool we possess to solve humanity's greatest crises and democratize world-class expertise for everyone. Best regards Kwandokuhle Bhembe On Mon, 20 Jul 2026, 18:59 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: Writing tools (Phetulo Dhlamini) > 2. Re: RPD Digest, Vol 222, Issue 92: Request to Pause the AI > Generated Posting (Gugu Dhlamini) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 20 Jul 2026 18:35:41 +0200 > From: Phetulo Dhlamini > To: rpd at afrinic.net > Subject: Re: [rpd] Writing tools > Message-ID: > < > CAABFmSn9mMmtkQAubfP44Fo+bMGm3eAavUQRDm0iO4eMuEDzwg at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Mike, > > On that point, we?re closer than it first appeared. > > Actual flooding, whether automated or not, should be handled under the > existing list rules. My concern is with the phrase ?AI DDoS,? because it > can stigmatise ordinary AI-assisted participation before any disruptive > conduct has occurred. > > The fair test is behaviour, not the tool: excessive volume, duplication, > impersonation, or deliberate disruption can be moderated. A real > participant who submits a message and stands behind it should still have > the argument considered on its merits. > > That keeps the process open without turning moderation into gatekeeping > over which tools people may use. > > Regards, > Phetulo > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/e51cbe8e/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Mon, 20 Jul 2026 18:58:46 +0200 > From: Gugu Dhlamini > To: Mike Burns , rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the > AI Generated Posting > Message-ID: > QA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Mike, > > Thank you for clarifying. I?ll leave the matter there, with the expectation > that the same standard is applied consistently to all participants. > > Regards, > Gugu > > On Mon, 20 Jul 2026, 6:43 pm Mike Burns wrote: > > > Hi Gugu, > > > > > > > > Off-list. Yes, of course. > > > > I was clear to distinguish between list-flooding as a sort of Denial of > > Service from simply using AI. > > > > Who cares who wrote the message? The list is open to everybody. > > > > That in itself is to ensure that the message is what matters, not some > > gatekeeping of participants. > > > > I didn?t want to clutter the list with more discussion of this matter, > but > > there is a new thread now with the Subject line Writing tools. > > > > > > > > Regards, > > Mike > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > *From:* Gugu Dhlamini > > *Sent:* Monday, July 20, 2026 12:30 PM > > *To:* Mike Burns ; rpd at afrinic.net > > *Subject:* Re: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the > > AI Generated Posting > > > > > > > > Hi Mike, > > > > Then we agree on the important principle: moderate actual disruptive > > conduct, not the tool, and assess every contribution on its substance. > > > > The participant remains responsible for the message. That keeps the > > process open without turning moderation into gatekeeping. > > > > Regards, > > Gugu > > > > > > > > On Mon, 20 Jul 2026, 6:15 pm Mike Burns wrote: > > > > Hi Gugu, > > > > > > > > I wonder if you actually read my post, as I completely agree with your > > rewording of it. > > > > > > > > Regards, > > Mike > > > > > > > > > > > > *From:* Gugu Dhlamini > > *Sent:* Monday, July 20, 2026 12:02 PM > > *To:* rpd at afrinic.net > > *Subject:* Re: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the > > AI Generated Posting > > > > > > > > Dear Mike, > > > > I support the use of AI-assisted drafting. I pay for the tool, I choose > > when to use it, and I remain responsible for every message I submit. The > > software is not participating in the PDWG. I am. > > > > The list may address actual misconduct such as spam, impersonation, > > automated flooding, or excessive duplication. It should not police lawful > > writing tools simply because some participants dislike them. > > > > Participation should be judged by substance and conduct, not by whether > > someone used modern technology to express a view. Otherwise, familiar > > participants turn personal preference into an unwritten permission > system. > > > > My tools are my choice. My words remain my responsibility. > > > > Regards, > > Gugu > > > > > > > > On Mon, 20 Jul 2026, 5:49 pm Taye Medoye > wrote: > > > > Dear Mike, > > > > > > > > I do hope that the usefulness of AI in assisting to generate relevant > > information is not being undermined here, as contributions on writing > tools > > tend to suggest. In this regard, l want to align with the position of > Mike, > > to the extent of his disapproval of the use of AI to swamp the list with > > long messages in a denial of service sort of attack....... > > > > > > > > However, the discussion is drifting from the proposal into judgments > about > > who is speaking and how they prepared their words. > > > > > > That is a wrong test. > > > > A participant may use translation, editing, or drafting assistance and > > still remain fully responsible for the position expressed. The policy > > question is whether mandatory hierarchical naming is necessary, > > proportionate, and limited to a genuine technical invariant. > > > > Operational benefits are relevant, but they do not automatically create > > policy authority. Nor does support from established participants become > > ?community consensus? merely because those voices are familiar. > > > > The co-chairs should separate distinct arguments, test the evidence, and > > avoid turning participation into mandate. The community may advise, > > support, warn, and object. It does not acquire ownership over dissent. > > > > > > > > I think the use of AI generated information should be viewed in the > > context of how it is projected to address the issue of concern, and its > > veriability. > > > > Regards, > > > > > > Taye Medoye > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 20 Jul 2026 at 15:55, Mike Burns wrote: > > > > I am very happy that this list has some traffic, and separate from the > > AS-SET issue, the issue of AI generated posts is enormously interesting > not > > only to this RIR policy list, but to all of them. > > > > > > > > My position is that there are two issues contained. One is the swamping > of > > the list with AI generated posts. The other is the concept of treating AI > > posts like any other post. > > > > > > > > While I am against the use of AI to swamp the list with long messages in > a > > Denial of Service sort of attack, I believe the principle of avoiding ad > > hominem arguments means that we have to treat the AI generated arguments > > the same as if they came directly from the pen of the poster. That is to > > say, ignore everything but the arguments being made, not the use of AI. > It > > is the arguments that matter, not the speaker. > > > > > > > > I expect this to bubble up in other RIR policy lists as time goes on, it > > would be good to have some kind of principled response. > > > > Many use translators to write posts in foreign languages, so certainly > > some tool use is expected. > > > > > > > > There are ways to block participants who transgress in other ways and > > those who post repeated AI slop to swamp the list should be so treated. > > > > But unless there is an attempt by an individual to swamp the list, the > > posts should be treated as if written by the poster, that is like every > > other post. > > > > > > > > I am interested to hear other perspectives on this. > > > > > > > > Regards, > > Mike > > > > > > > > > > > > *From:* Taye Medoye > > *Sent:* Monday, July 20, 2026 8:38 AM > > *To:* rpd at afrinic.net > > *Subject:* Re: [rpd] RPD Digest, Vol 222, Issue 92: Request to Pause the > > AI Generated Posting > > > > > > > > In regard to the ensuing antagonistic reponses relating to the call for > > the pause of AI generated mails, l align with the position expressed by > > Noah for obvious reasons: > > > > > > > > Firstly, the well referenced Policy Development Process (PDP) on open and > > unecumbered participation and expressions remains sancrosant, and a > guiding > > principle. I think this priciple should be observed always; > > > > > > > > Secondly, l am not aware that the Forum gives the freedom to engage in > any > > form of criticism on the contributions made by participants. > > > > > > > > Above all, l subscribe to the view that, while AI may be good in > assisting > > with information as may be sought concerning any subject matter, l do not > > think it has the capacity to meet the prinicple of originality expected > in > > any written literary work, whether in research or for informative > > diseemination purposes. > > > > > > > > The bottom line remains that, in line with the framework for > particiapting > > in any discussion on this Forum, mutual respect for views should be > upheld. > > > > > > > > Daniel Taye Medoye > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/66c2e8c1/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 107 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonjabulosphilile at gmail.com Mon Jul 20 17:35:39 2026 From: nonjabulosphilile at gmail.com (Nonjabulo Sphilile) Date: Mon, 20 Jul 2026 19:35:39 +0200 Subject: [rpd] Writing tools In-Reply-To: <06e701dd1862$df4b2b50$9de181f0$@iptrading.com> References: <06e701dd1862$df4b2b50$9de181f0$@iptrading.com> Message-ID: Hi Mike, Your clarification does not remove my concern. Calling AI-assisted participation a potential ?DDoS? still frames the tool as suspicious before any disruptive conduct has occurred. Existing rules already address flooding. Moderation should respond to proven behaviour, not hypothetical assumptions about technology. Otherwise, process management becomes gatekeeping. Regards, Nonjabulo On Mon, 20 Jul 2026, 18:14 Mike Burns, wrote: > Hi Nonjablulo, > > > > I want to be clear that AI DDos is the same as automated flooding. AI can > generate non-duplicative prompts more quickly and easily than anything > else, which provide a tool for list-swamping. > > What that can do is render the list unusable. > > Note that I do not see that happening in any current conversations. > > And as I pointed out, existing procedures can take care of list flooding, > whether AI generated or not. > > > > I thought I was clear that absent the flooding I called a DDoS, all > arguments should be considered on their merits. > > I personally don?t care where the argument comes from. > > > > Regards, > Mike > > > > > > *From:* Nonjabulo Sphilile > *Sent:* Monday, July 20, 2026 12:02 PM > *To:* rpd at afrinic.net > *Subject:* Re: [rpd] Writing tools > > > > Dear Mike, > > > > The ?AI DDoS? analogy is the wrong category. Participants are not packets, > and disagreement is not an attack on the process. > > > > The list may regulate actual conduct such as automated flooding, > impersonation, excessive duplication, or deliberate disruption. It should > not infer abuse from writing style or from the use of a drafting tool. A > person who reviews, submits, and stands behind a message remains > responsible for it. > > > > Any guideline must therefore be tool-neutral and based on measurable > behaviour. Otherwise process management becomes a mechanism for filtering > unfamiliar or inconvenient voices while established participants continue > to define what counts as legitimate participation. > > > > Rough consensus is not protected by narrowing the room. It is protected by > identifying distinct issues, answering them on their merits, and refusing > to turn procedural control into institutional mandate. > > > > I oppose any rule that treats AI assistance itself as presumptive > misconduct. > > > > Regards, > > Nonjabulo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Mon Jul 20 18:07:56 2026 From: mike at iptrading.com (Mike Burns) Date: Mon, 20 Jul 2026 14:07:56 -0400 Subject: [rpd] Writing tools In-Reply-To: References: <06e701dd1862$df4b2b50$9de181f0$@iptrading.com> Message-ID: <073401dd1872$b0f77a50$12e66ef0$@iptrading.com> Hi Nonjabulo, You seem to continue to miss the context of my comment about "Denial of Service sort of attack" which was explicitly framed in the context of swamping the list. I also mentioned "But unless there is an attempt by an individual to swamp the list, the posts should be treated as if written by the poster, that is like every other post." And I think there has been support for this separation of the "AI" issue into more digestible pieces. I don't want AI to be used as a tool to generate so many copies of the same argument in slightly different words WITH AN INTENT TO SWAMP THE LIST, and we know it is quite capable of that. Why not a simple +1 comment if you want your argument noted and it has already been stated by another? However, as I have also said, I have not seen any deployment of AI in this manner in the current discussions, and my comment was broader in target. Sorry for any confusion and I hope I have answered your concern. I don't want AI generated messages to overwhelm any policy list, but I don't care if list members employ AI as a writing tool. In some ways it could be an improvement. Regards, Mike From: Nonjabulo Sphilile Sent: Monday, July 20, 2026 1:36 PM To: Mike Burns Cc: rpd at afrinic.net Subject: Re: [rpd] Writing tools Hi Mike, Your clarification does not remove my concern. Calling AI-assisted participation a potential "DDoS" still frames the tool as suspicious before any disruptive conduct has occurred. Existing rules already address flooding. Moderation should respond to proven behaviour, not hypothetical assumptions about technology. Otherwise, process management becomes gatekeeping. Regards, Nonjabulo On Mon, 20 Jul 2026, 18:14 Mike Burns, > wrote: Hi Nonjablulo, I want to be clear that AI DDos is the same as automated flooding. AI can generate non-duplicative prompts more quickly and easily than anything else, which provide a tool for list-swamping. What that can do is render the list unusable. Note that I do not see that happening in any current conversations. And as I pointed out, existing procedures can take care of list flooding, whether AI generated or not. I thought I was clear that absent the flooding I called a DDoS, all arguments should be considered on their merits. I personally don't care where the argument comes from. Regards, Mike From: Nonjabulo Sphilile < nonjabulosphilile at gmail.com> Sent: Monday, July 20, 2026 12:02 PM To: rpd at afrinic.net Subject: Re: [rpd] Writing tools Dear Mike, The "AI DDoS" analogy is the wrong category. Participants are not packets, and disagreement is not an attack on the process. The list may regulate actual conduct such as automated flooding, impersonation, excessive duplication, or deliberate disruption. It should not infer abuse from writing style or from the use of a drafting tool. A person who reviews, submits, and stands behind a message remains responsible for it. Any guideline must therefore be tool-neutral and based on measurable behaviour. Otherwise process management becomes a mechanism for filtering unfamiliar or inconvenient voices while established participants continue to define what counts as legitimate participation. Rough consensus is not protected by narrowing the room. It is protected by identifying distinct issues, answering them on their merits, and refusing to turn procedural control into institutional mandate. I oppose any rule that treats AI assistance itself as presumptive misconduct. Regards, Nonjabulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Mon Jul 20 19:26:40 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Mon, 20 Jul 2026 21:26:40 +0200 Subject: [rpd] Writing tools In-Reply-To: References: Message-ID: <09EB63D0-2FBC-48F9-B752-43E842D85096@afrinic.net> An HTML attachment was scrubbed... URL: From bakenon.kone at sancfis.net Mon Jul 20 20:34:20 2026 From: bakenon.kone at sancfis.net (Kone) Date: Mon, 20 Jul 2026 20:34:20 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <1784239787450.20999@tra.gov.eg> Message-ID: Hello Seun, You may have misread my earlier mail. I clearly stated that LACNIC, RIPE NCC, and ARIN do not require policy to enforce hierarchical AS?SET naming. To help close the ongoing discussions, I believe addressing the questions I raised would bring clarity: * LACNIC enforces hierarchical AS?SET naming operationally, as part of their IRR design from inception. * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) process, not through policy. * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR operational matters, again without policy. These examples show that other RIRs (except APNIC) treat AS?SET naming as an operational IRR matter, not a policy obligation. This is why I asked whether AFRINIC could address this operationally rather than through policy, and why Last Call discussions would benefit from clear answers to these points. Thanks. --- Kone Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji a ?crit : > Hello Bakenon, > > Do refer to the proposal as it references URL to other RIR's policies for > thiis: > > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > Regards > > ---- > Sent from my mobile > kindly excuse typos > > On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, > wrote: > >> Dear PDWG, >> >> I have been following the discussions on the hierarchical AS?SET naming >> scheme and would like clarification on a few points: >> >> 1. Could this matter be addressed operationally, as is done in ARIN, >> LACNIC, and RIPE NCC, without requiring policy changes? >> >> 2. If yes, why are we taking the policy route? Is it because AFRINIC >> currently lacks a defined process for handling operational issues that >> affect IRR services? >> >> 3. Given that the hierarchical naming scheme is already supported and >> currently exists within the IRR, this proposal represents an enforcement >> change rather than the introduction of a new technical standard. Why is a >> formal policy required to change an operational enforcement setting, rather >> than a community-vetted technical implementation plan?" >> >> Thank you. >> --- >> Kone >> >> >> >> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal a >> ?crit : >> >>> Dear PDWG, >>> >>> >>> The Policy Development Working Group (PDWG) Chairs have initiated a Last >>> Call for this proposal, following rough consensus at the AFRINIC-37 Public >>> Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. >>> >>> * Proposal Name: Hierarchical Names for New AS-SETs >>> >>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >>> >>> * Proposal URL: >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >>> >>> Last Call closes on: July 31, 2026, at 23:59 UTC. >>> >>> >>> 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. >>> >>> >>> As always, we kindly request that all participants adhere to the AFRINIC >>> Code of Conduct to maintain a respectful >>> and professional environment on the mailing list. >>> >>> >>> Kind regards, >>> >>> >>> Haitham el Nakhal >>> >>> AFRINIC PDWG Co-Chair >>> >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Mon Jul 20 21:10:04 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Mon, 20 Jul 2026 23:10:04 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <1784239787450.20999@tra.gov.eg> Message-ID: Hi Kone, And what is the relevance of that? If you have a good understanding about all the RIRs, you will know that each RIR has their own ways to do things. In many senses they act very similarly and in general we end up with very similarly policies, but not always. Some RIRs have decided that some aspects are operational and don?t need a policy proposal. However, despite that, the community is on top of the RIR, and the community sometimes, may decide that they prefer a policy if the RIR hasn?t been proactive in advance in any specific topic, or even if the RIR was proactive, the community may prefer to speed up things, or to show the way the community prefers. For example, if AFRINIC has any specific operational aspect already in place, and the community prefer to manage that in a different way, the community may opt either for suggesting the RIR to modify that operational aspect or to do actually enforce it by means of a policy proposal. I think is important to know, by personal experience, how the other 4 RIRs work before stating something that is not correct, because if you don?t work in all the RIRs for many years, it will be difficult for you to know the past and I?m sure IA will not be able to be precise as well. Regards, Jordi @jordipalet > El 20 jul 2026, a las 22:34, Kone escribi?: > > Hello Seun, > You may have misread my earlier mail. I clearly stated that LACNIC, RIPE NCC, and ARIN do not require policy to enforce hierarchical AS?SET naming. > > To help close the ongoing discussions, I believe addressing the questions I raised would bring clarity: > * LACNIC enforces hierarchical AS?SET naming operationally, as part of their IRR design from inception. > * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) process, not through policy. > * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR operational matters, again without policy. > > > These examples show that other RIRs (except APNIC) treat AS?SET naming as an operational IRR matter, not a policy obligation. > > This is why I asked whether AFRINIC could address this operationally rather than through policy, and why Last Call discussions would benefit from clear answers to these points. > > Thanks. > --- > Kone > > > > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji > a ?crit : >> Hello Bakenon, >> >> Do refer to the proposal as it references URL to other RIR's policies for thiis: >> >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >> Regards >> >> ---- >> Sent from my mobile >> kindly excuse typos >> >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, > wrote: >>> Dear PDWG, >>> >>> I have been following the discussions on the hierarchical AS?SET naming scheme and would like clarification on a few points: >>> >>> 1. Could this matter be addressed operationally, as is done in ARIN, LACNIC, and RIPE NCC, without requiring policy changes? >>> >>> 2. If yes, why are we taking the policy route? Is it because AFRINIC currently lacks a defined process for handling operational issues that affect IRR services? >>> >>> 3. Given that the hierarchical naming scheme is already supported and currently exists within the IRR, this proposal represents an enforcement change rather than the introduction of a new technical standard. Why is a formal policy required to change an operational enforcement setting, rather than a community-vetted technical implementation plan?" >>> >>> Thank you. >>> --- >>> Kone >>> >>> >>> >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal > a ?crit : >>>> Dear PDWG, >>>> >>>> >>>> The Policy Development Working Group (PDWG) Chairs have initiated a Last Call for this proposal, following rough consensus at the AFRINIC-37 Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. >>>> >>>> * Proposal Name: Hierarchical Names for New AS-SETs >>>> >>>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >>>> >>>> * Proposal URL: https://www.afrinic.net/afpub-2026-asn-001-draft02.html >>>> >>>> Last Call closes on: July 31, 2026, at 23:59 UTC. >>>> >>>> >>>> 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. >>>> >>>> >>>> As always, we kindly request that all participants adhere to the AFRINIC Code of Conduct to maintain a respectful and professional environment on the mailing list. >>>> >>>> >>>> Kind regards, >>>> >>>> >>>> Haitham el Nakhal >>>> >>>> AFRINIC PDWG Co-Chair >>>> >>>> >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Tue Jul 21 06:19:05 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Tue, 21 Jul 2026 06:19:05 +0000 Subject: [rpd] RPD Digest, Vol 222, Issue 110 In-Reply-To: References: Message-ID: Dear All, Kone?s point is directly relevant. If LACNIC, RIPE NCC, and ARIN can implement hierarchical AS-SET naming through operational mechanisms, then proponents must explain why AFRINIC needs a binding policy to achieve the same technical result. Saying that each RIR works differently does not answer that question. Nor does saying that ?the community is on top of the RIR.? A community may advise, object, and coordinate. It does not acquire unlimited authority to convert every operational preference into policy. A mailing list is not a legislature. If AFRINIC can solve this through an operational change, policy adds governance where technical administration would be sufficient. Speed and preference do not create mandate. Kone provided specific examples. Those should be answered with evidence, not by questioning whether he has worked in every RIR for many years. Experience is relevant, but it is not authority and it is not a substitute for argument. The unanswered question remains: what technical necessity requires policy rather than operational implementation? Until that is answered, Kone?s objection stands, and I support it. Regards, Tshepo ________________________________ From: rpd-request at afrinic.net Sent: Monday, July 20, 2026 11:10:57 pm To: rpd at afrinic.net Subject: RPD Digest, Vol 222, Issue 110 Send RPD mailing list submissions to rpd at afrinic.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.afrinic.net/mailman/listinfo/rpd or, via email, send a message with subject or body 'help' to rpd-request at afrinic.net You can reach the person managing the list at rpd-owner at afrinic.net When replying, please edit your Subject line so it is more specific than "Re: Contents of RPD digest..." Today's Topics: 1. Re: Writing tools (Ben Roberts - AfriNIC) 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Kone) 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (jordi.palet at consulintel.es) ---------------------------------------------------------------------- Message: 1 Date: Mon, 20 Jul 2026 21:26:40 +0200 From: Ben Roberts - AfriNIC To: Nonjabulo Sphilile Cc: rpd at afrinic.net Subject: Re: [rpd] Writing tools Message-ID: <09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net> Content-Type: text/plain; charset="us-ascii" An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Mon, 20 Jul 2026 20:34:20 +0000 From: Kone To: Seun Ojedeji Cc: rpd Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Content-Type: text/plain; charset="utf-8" Hello Seun, You may have misread my earlier mail. I clearly stated that LACNIC, RIPE NCC, and ARIN do not require policy to enforce hierarchical AS?SET naming. To help close the ongoing discussions, I believe addressing the questions I raised would bring clarity: * LACNIC enforces hierarchical AS?SET naming operationally, as part of their IRR design from inception. * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) process, not through policy. * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR operational matters, again without policy. These examples show that other RIRs (except APNIC) treat AS?SET naming as an operational IRR matter, not a policy obligation. This is why I asked whether AFRINIC could address this operationally rather than through policy, and why Last Call discussions would benefit from clear answers to these points. Thanks. --- Kone Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji a ?crit : > Hello Bakenon, > > Do refer to the proposal as it references URL to other RIR's policies for > thiis: > > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > Regards > > ---- > Sent from my mobile > kindly excuse typos > > On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, > wrote: > >> Dear PDWG, >> >> I have been following the discussions on the hierarchical AS?SET naming >> scheme and would like clarification on a few points: >> >> 1. Could this matter be addressed operationally, as is done in ARIN, >> LACNIC, and RIPE NCC, without requiring policy changes? >> >> 2. If yes, why are we taking the policy route? Is it because AFRINIC >> currently lacks a defined process for handling operational issues that >> affect IRR services? >> >> 3. Given that the hierarchical naming scheme is already supported and >> currently exists within the IRR, this proposal represents an enforcement >> change rather than the introduction of a new technical standard. Why is a >> formal policy required to change an operational enforcement setting, rather >> than a community-vetted technical implementation plan?" >> >> Thank you. >> --- >> Kone >> >> >> >> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal a >> ?crit : >> >>> Dear PDWG, >>> >>> >>> The Policy Development Working Group (PDWG) Chairs have initiated a Last >>> Call for this proposal, following rough consensus at the AFRINIC-37 Public >>> Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. >>> >>> * Proposal Name: Hierarchical Names for New AS-SETs >>> >>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >>> >>> * Proposal URL: >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >>> >>> Last Call closes on: July 31, 2026, at 23:59 UTC. >>> >>> >>> 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. >>> >>> >>> As always, we kindly request that all participants adhere to the AFRINIC >>> Code of Conduct to maintain a respectful >>> and professional environment on the mailing list. >>> >>> >>> Kind regards, >>> >>> >>> Haitham el Nakhal >>> >>> AFRINIC PDWG Co-Chair >>> >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Mon, 20 Jul 2026 23:10:04 +0200 From: "jordi.palet at consulintel.es" To: rpd Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Content-Type: text/plain; charset="utf-8" Hi Kone, And what is the relevance of that? If you have a good understanding about all the RIRs, you will know that each RIR has their own ways to do things. In many senses they act very similarly and in general we end up with very similarly policies, but not always. Some RIRs have decided that some aspects are operational and don?t need a policy proposal. However, despite that, the community is on top of the RIR, and the community sometimes, may decide that they prefer a policy if the RIR hasn?t been proactive in advance in any specific topic, or even if the RIR was proactive, the community may prefer to speed up things, or to show the way the community prefers. For example, if AFRINIC has any specific operational aspect already in place, and the community prefer to manage that in a different way, the community may opt either for suggesting the RIR to modify that operational aspect or to do actually enforce it by means of a policy proposal. I think is important to know, by personal experience, how the other 4 RIRs work before stating something that is not correct, because if you don?t work in all the RIRs for many years, it will be difficult for you to know the past and I?m sure IA will not be able to be precise as well. Regards, Jordi @jordipalet > El 20 jul 2026, a las 22:34, Kone escribi?: > > Hello Seun, > You may have misread my earlier mail. I clearly stated that LACNIC, RIPE NCC, and ARIN do not require policy to enforce hierarchical AS?SET naming. > > To help close the ongoing discussions, I believe addressing the questions I raised would bring clarity: > * LACNIC enforces hierarchical AS?SET naming operationally, as part of their IRR design from inception. > * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) process, not through policy. > * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR operational matters, again without policy. > > > These examples show that other RIRs (except APNIC) treat AS?SET naming as an operational IRR matter, not a policy obligation. > > This is why I asked whether AFRINIC could address this operationally rather than through policy, and why Last Call discussions would benefit from clear answers to these points. > > Thanks. > --- > Kone > > > > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji > a ?crit : >> Hello Bakenon, >> >> Do refer to the proposal as it references URL to other RIR's policies for thiis: >> >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >> Regards >> >> ---- >> Sent from my mobile >> kindly excuse typos >> >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, > wrote: >>> Dear PDWG, >>> >>> I have been following the discussions on the hierarchical AS?SET naming scheme and would like clarification on a few points: >>> >>> 1. Could this matter be addressed operationally, as is done in ARIN, LACNIC, and RIPE NCC, without requiring policy changes? >>> >>> 2. If yes, why are we taking the policy route? Is it because AFRINIC currently lacks a defined process for handling operational issues that affect IRR services? >>> >>> 3. Given that the hierarchical naming scheme is already supported and currently exists within the IRR, this proposal represents an enforcement change rather than the introduction of a new technical standard. Why is a formal policy required to change an operational enforcement setting, rather than a community-vetted technical implementation plan?" >>> >>> Thank you. >>> --- >>> Kone >>> >>> >>> >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal > a ?crit : >>>> Dear PDWG, >>>> >>>> >>>> The Policy Development Working Group (PDWG) Chairs have initiated a Last Call for this proposal, following rough consensus at the AFRINIC-37 Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. >>>> >>>> * Proposal Name: Hierarchical Names for New AS-SETs >>>> >>>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >>>> >>>> * Proposal URL: https://www.afrinic.net/afpub-2026-asn-001-draft02.html >>>> >>>> Last Call closes on: July 31, 2026, at 23:59 UTC. >>>> >>>> >>>> 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. >>>> >>>> >>>> As always, we kindly request that all participants adhere to the AFRINIC Code of Conduct to maintain a respectful and professional environment on the mailing list. >>>> >>>> >>>> Kind regards, >>>> >>>> >>>> Haitham el Nakhal >>>> >>>> AFRINIC PDWG Co-Chair >>>> >>>> >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ End of RPD Digest, Vol 222, Issue 110 ************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Tue Jul 21 06:30:41 2026 From: hvisage at hevis.co.za (hvisage at hevis.co.za) Date: Tue, 21 Jul 2026 08:30:41 +0200 Subject: [rpd] Hierarchical AS-SETs objector analysis -> astroturfing Message-ID: <908A2232-203B-4C9D-9A09-DB95C379C397@hevis.co.za> I gave Claude Cavemen the mailing list archive, and requested it to analyze the objectors? question and answers and why this could be classified as Astroturfing? the humans with brains in here can stop reading as they had already seen all the signs, but for the AI writing tools, the summarised version? the name references at the astroturfing section was Fable 5 that made/found/linked it, not me? just? revealing --- ## 1. Questions the objectors POSED ? and the answers they received Every substantive question they asked **was answered on the record**: | Their question | Answer given | Where | |---|---|---| | "Does hierarchical naming validate AS-SET *contents*?" (the attribution vs content distinction) | **Conceded**: no, and the proposal never claims it ? scope is name uniqueness + creation attribution only. Content = RPKI/ASPA/bilateral territory. | Hendrik 015120, Frank 015123 ("it doesn't claim to? It creates an improvement") | | "Show the exact operational harm" | MANRS AS-AMAZON incident (2022); live empty AS-GOOGLE in AFRINIC DB vs populated RADB one, pasted side-by-side; Jaco Kroon's first-person upstream-collision testimony | Frank's two-object post; 015120; Jaco 20 Jul | | "Why is this the least restrictive solution?" | Deployment asymmetry (one naming rule at one registry vs universal consumer reform); squatting has no consumer-side remedy; ~34 voluntary hierarchical sets already existed and collisions persisted anyway | 015120 | | "Where is the proportionality/impact analysis?" | Published staff Impact Assessment: minimal member impact, no legal/finance issues; scope limits written into 7.8.3?7.8.6 | 015120 + proposal text | | "Why must AFRINIC follow other RIRs?" | It needn't ? reframed: with the other four closed, AFRINIC's namespace is the **last open one**; residual global squatting surface concentrates here | 015120 | | "Why the policy route instead of operational?" (Kone ? genuine dissent) | Community may prefer/enforce via policy; that's its prerogative over the RIR | Jordi Palet 015195 | **None of the answers received a counter-engagement.** The objections were then restated as if unanswered. ## 2. Questions ASKED OF the objectors ? and how they responded | Question | Response across 23 accounts / 161 messages | |---|---| | What should filter software do with the empty AFRINIC AS-GOOGLE vs populated RADB one? (Frank) | **Zero answers.** ?4 direct replies to Frank skip it. Only cohort message containing "AS-GOOGLE" quotes Frank's own words via digest. | | What remedy does a squatting victim have under your alternatives? (Hendrik 015120) | **Zero answers.** Alternatives lists kept being reposted without touching it. | | "Do you agree it provides improvements?" (Frank) | **Conceded by presupposition** ? "An improvement is not automatically a justification for mandatory policy" (Thulisile 015130). Never a plain yes, never a no. | | What evidence threshold would satisfy "proven enough / proportionate enough"? | **Never named.** The bar stays undefined ? unfalsifiable by construction. | | Which specific Impact Assessment finding do you contest? | **IA never once mentioned** by any objector, while "the analysis has not been completed" kept being asserted. | | Would new participants introduce themselves? (Ben ? invoking the objectors' *own* "real person who stands behind it" test) | **Refused** ("not a membership interview"); three new accounts appeared within 22 minutes instead. Sole compliance: Mandla Matshika ? "Policy insights contributor at NRS". | Their only direct "answers" = concessions: mechanism works, it's an improvement, harm evidence is "useful evidence," and their stated technical case = the already-conceded scope point. ## 3. Why this classifies as astroturfing Astroturfing = manufacturing the *appearance* of independent grassroots opinion. The behavioral evidence (no stylometry needed): 1. **Manufactured breadth**: 23 accounts first-seen in the weeks before/during Last Call, mostly `name+digits at gmail` + student mailboxes, producing 161 messages ? vs 2 established participants opposing anything all year. 72 of 74 oppose stances in the Last Call window came from these accounts. 2. **One voice, many names**: five distinct arguments total; everything else restatement. Same vocabulary kit ("mandate laundering", "invariant", "gatekeeping", "Participation is not mandate") crossing accounts; the same new talking point delivered by two personas within one exchange; cross-account signature slip (gugudhlamini343 message signed "Nonhlanhla"); verbatim-copied objection between two senders (0.985 similarity, per our dossier). 3. **Coordination artifacts**: literal `[Name]` template placeholder sent as a signature (015134); contradictory explanations of the same double-post 8 minutes apart; two display names each operating two mailboxes; batch digest-reply workflow; three fresh accounts materializing in 22 minutes when introductions were requested. 4. **Asymmetric responsiveness**: supporter missteps drew replies in ~20 minutes; the five concrete questions stood unanswered >1 day across the whole roster ? the signature of a template pipeline that can restate but not adapt. 5. **Attention exhaustion as the mechanism**: volume aimed at swamping Last Call and manufacturing "unresolved objections," not persuading ? what Mike Silber called an "AI generated DDoS on the PDP" (015179). 6. **Link to a known astroturf actor, self-declared**: Mandla Matshika introduces as "Policy insights contributor at **NRS**" (015177); Nia/Nonhlanhla cites **Lu Heng's** "Policy Mirror" as framework (015011) ? NRS/Larus/Lu Heng being the named actors in AFRINIC's own 2021?2023 misinformation warnings. 7. **Independent recognition**: not one observer's read ? Omo Oaiya ("coordinated or based on common templates"), Silber, Sowe, Noah, Ben, and sitting co-chair El-Nakhal himself: *"astroturfing is the best term to define such emails"* (015029). The rough-consensus consequence (RFC 7282, per Alston 015166): objections count when grounded in evidence and *sustained through engagement* ? this corpus reduces to two issues, both answered, one mutually agreed out of scope, echoed by many mouths. That's the definition of astroturf: headcount pretending to be argument. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Tue Jul 21 06:33:31 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Tue, 21 Jul 2026 08:33:31 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 111 In-Reply-To: References: Message-ID: Dear PDWG, Kone is asking the right question. The issue is no longer whether hierarchical AS-SET naming is technically possible or useful. It already exists. The issue is why AFRINIC needs a binding policy to enforce what other RIRs largely treat as an operational IRR matter. That distinction matters. An operational change adjusts how a service is implemented. A policy creates an enforceable obligation and enlarges the registry?s authority. If the same technical result can be achieved through a community-reviewed implementation plan, then policy is not the minimum necessary instrument. Saying that ?the community prefers policy? is not enough. Participation may guide technical work, but it does not turn every preference into a mandate. A mailing list is not a legislature, and the availability of the PDP should not make policy the default answer to every operational setting. This is how gatekeeping expands: the registry begins with a useful technical function, then policy converts that function into permission and enforcement. The recordkeeper gradually becomes the rule-maker. The proponents should therefore answer Kone directly: what technical outcome can mandatory policy achieve here that an operational implementation cannot? Until that is clearly demonstrated, I support Kone?s questions and remain opposed to the policy route. Regards, Nonhlanhla On Tue, 21 Jul 2026, 8:20 am wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: RPD Digest, Vol 222, Issue 110 (Tshepo Masuku) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2026 06:19:05 +0000 > From: Tshepo Masuku > To: "rpd at afrinic.net" > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 110 > Message-ID: > < > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > > > > Content-Type: text/plain; charset="windows-1252" > > Dear All, > > Kone?s point is directly relevant. If LACNIC, RIPE NCC, and ARIN can > implement hierarchical AS-SET naming through operational mechanisms, then > proponents must explain why AFRINIC needs a binding policy to achieve the > same technical result. > > Saying that each RIR works differently does not answer that question. Nor > does saying that ?the community is on top of the RIR.? A community may > advise, object, and coordinate. It does not acquire unlimited authority to > convert every operational preference into policy. A mailing list is not a > legislature. > > If AFRINIC can solve this through an operational change, policy adds > governance where technical administration would be sufficient. Speed and > preference do not create mandate. > > Kone provided specific examples. Those should be answered with evidence, > not by questioning whether he has worked in every RIR for many years. > Experience is relevant, but it is not authority and it is not a substitute > for argument. > > The unanswered question remains: what technical necessity requires policy > rather than operational implementation? > > Until that is answered, Kone?s objection stands, and I support it. > > Regards, > Tshepo > > > ________________________________ > From: rpd-request at afrinic.net > Sent: Monday, July 20, 2026 11:10:57 pm > To: rpd at afrinic.net > Subject: RPD Digest, Vol 222, Issue 110 > > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: Writing tools (Ben Roberts - AfriNIC) > 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Kone) > 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > (jordi.palet at consulintel.es) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 20 Jul 2026 21:26:40 +0200 > From: Ben Roberts - AfriNIC > To: Nonjabulo Sphilile > Cc: rpd at afrinic.net > Subject: Re: [rpd] Writing tools > Message-ID: <09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net> > Content-Type: text/plain; charset="us-ascii" > > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/33c3ac9e/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Mon, 20 Jul 2026 20:34:20 +0000 > From: Kone > To: Seun Ojedeji > Cc: rpd > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello Seun, > You may have misread my earlier mail. I clearly stated that LACNIC, RIPE > NCC, and ARIN do not require policy to enforce hierarchical AS?SET naming. > > To help close the ongoing discussions, I believe addressing the questions I > raised would bring clarity: > * LACNIC enforces hierarchical AS?SET naming operationally, as part of > their IRR design from inception. > * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) > process, not through policy. > * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR > operational matters, again without policy. > > > These examples show that other RIRs (except APNIC) treat AS?SET naming as > an operational IRR matter, not a policy obligation. > > This is why I asked whether AFRINIC could address this operationally rather > than through policy, and why Last Call discussions would benefit from clear > answers to these points. > > Thanks. > --- > Kone > > > > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji a > ?crit : > > > Hello Bakenon, > > > > Do refer to the proposal as it references URL to other RIR's policies for > > thiis: > > > > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > > > Regards > > > > ---- > > Sent from my mobile > > kindly excuse typos > > > > On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, > > wrote: > > > >> Dear PDWG, > >> > >> I have been following the discussions on the hierarchical AS?SET naming > >> scheme and would like clarification on a few points: > >> > >> 1. Could this matter be addressed operationally, as is done in ARIN, > >> LACNIC, and RIPE NCC, without requiring policy changes? > >> > >> 2. If yes, why are we taking the policy route? Is it because AFRINIC > >> currently lacks a defined process for handling operational issues that > >> affect IRR services? > >> > >> 3. Given that the hierarchical naming scheme is already supported and > >> currently exists within the IRR, this proposal represents an enforcement > >> change rather than the introduction of a new technical standard. Why is > a > >> formal policy required to change an operational enforcement setting, > rather > >> than a community-vetted technical implementation plan?" > >> > >> Thank you. > >> --- > >> Kone > >> > >> > >> > >> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal a > >> ?crit : > >> > >>> Dear PDWG, > >>> > >>> > >>> The Policy Development Working Group (PDWG) Chairs have initiated a > Last > >>> Call for this proposal, following rough consensus at the AFRINIC-37 > Public > >>> Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. > >>> > >>> * Proposal Name: Hierarchical Names for New AS-SETs > >>> > >>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > >>> > >>> * Proposal URL: > >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >>> > >>> Last Call closes on: July 31, 2026, at 23:59 UTC. > >>> > >>> > >>> 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. > >>> > >>> > >>> As always, we kindly request that all participants adhere to the > AFRINIC > >>> Code of Conduct to maintain a respectful > >>> and professional environment on the mailing list. > >>> > >>> > >>> Kind regards, > >>> > >>> > >>> Haitham el Nakhal > >>> > >>> AFRINIC PDWG Co-Chair > >>> > >>> > >>> > >>> _______________________________________________ > >>> RPD mailing list > >>> RPD at afrinic.net > >>> https://lists.afrinic.net/mailman/listinfo/rpd > >>> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/4563e1d5/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Mon, 20 Jul 2026 23:10:04 +0200 > From: "jordi.palet at consulintel.es" > To: rpd > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Hi Kone, > > And what is the relevance of that? > > If you have a good understanding about all the RIRs, you will know that > each RIR has their own ways to do things. In many senses they act very > similarly and in general we end up with very similarly policies, but not > always. Some RIRs have decided that some aspects are operational and don?t > need a policy proposal. > > However, despite that, the community is on top of the RIR, and the > community sometimes, may decide that they prefer a policy if the RIR hasn?t > been proactive in advance in any specific topic, or even if the RIR was > proactive, the community may prefer to speed up things, or to show the way > the community prefers. > > For example, if AFRINIC has any specific operational aspect already in > place, and the community prefer to manage that in a different way, the > community may opt either for suggesting the RIR to modify that operational > aspect or to do actually enforce it by means of a policy proposal. > > I think is important to know, by personal experience, how the other 4 RIRs > work before stating something that is not correct, because if you don?t > work in all the RIRs for many years, it will be difficult for you to know > the past and I?m sure IA will not be able to be precise as well. > > Regards, > Jordi > > @jordipalet > > > El 20 jul 2026, a las 22:34, Kone escribi?: > > > > Hello Seun, > > You may have misread my earlier mail. I clearly stated that LACNIC, RIPE > NCC, and ARIN do not require policy to enforce hierarchical AS?SET naming. > > > > To help close the ongoing discussions, I believe addressing the > questions I raised would bring clarity: > > * LACNIC enforces hierarchical AS?SET naming operationally, as part of > their IRR design from inception. > > * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) > process, not through policy. > > * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR > operational matters, again without policy. > > > > > > These examples show that other RIRs (except APNIC) treat AS?SET naming > as an operational IRR matter, not a policy obligation. > > > > This is why I asked whether AFRINIC could address this operationally > rather than through policy, and why Last Call discussions would benefit > from clear answers to these points. > > > > Thanks. > > --- > > Kone > > > > > > > > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji > a ?crit : > >> Hello Bakenon, > >> > >> Do refer to the proposal as it references URL to other RIR's policies > for thiis: > >> > >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >> > >> Regards > >> > >> ---- > >> Sent from my mobile > >> kindly excuse typos > >> > >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, > wrote: > >>> Dear PDWG, > >>> > >>> I have been following the discussions on the hierarchical AS?SET > naming scheme and would like clarification on a few points: > >>> > >>> 1. Could this matter be addressed operationally, as is done in ARIN, > LACNIC, and RIPE NCC, without requiring policy changes? > >>> > >>> 2. If yes, why are we taking the policy route? Is it because AFRINIC > currently lacks a defined process for handling operational issues that > affect IRR services? > >>> > >>> 3. Given that the hierarchical naming scheme is already supported and > currently exists within the IRR, this proposal represents an enforcement > change rather than the introduction of a new technical standard. Why is a > formal policy required to change an operational enforcement setting, rather > than a community-vetted technical implementation plan?" > >>> > >>> Thank you. > >>> --- > >>> Kone > >>> > >>> > >>> > >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal > a ?crit : > >>>> Dear PDWG, > >>>> > >>>> > >>>> The Policy Development Working Group (PDWG) Chairs have initiated a > Last Call for this proposal, following rough consensus at the AFRINIC-37 > Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June > 2026. > >>>> > >>>> * Proposal Name: Hierarchical Names for New AS-SETs > >>>> > >>>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > >>>> > >>>> * Proposal URL: > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >>>> > >>>> Last Call closes on: July 31, 2026, at 23:59 UTC. > >>>> > >>>> > >>>> 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. > >>>> > >>>> > >>>> As always, we kindly request that all participants adhere to the > AFRINIC Code of Conduct to maintain a > respectful and professional environment on the mailing list. > >>>> > >>>> > >>>> Kind regards, > >>>> > >>>> > >>>> Haitham el Nakhal > >>>> > >>>> AFRINIC PDWG Co-Chair > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> RPD mailing list > >>>> RPD at afrinic.net > >>>> https://lists.afrinic.net/mailman/listinfo/rpd > >>> _______________________________________________ > >>> RPD mailing list > >>> RPD at afrinic.net > >>> https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/b6777fa7/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 110 > ************************************* > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e492c668/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 111 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Tue Jul 21 06:34:21 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Tue, 21 Jul 2026 08:34:21 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 111 Message-ID: Dear Jordi, Kone's point is not that every RIR must follow the same procedure. Rather, his point is that the same technical outcome has been achieved elsewhere without making it binding policy. That makes the choice of mechanism relevant. A policy process should not be used simply because it is available. The appropriate approach is to use the least powerful mechanism capable of solving the operational problem. If AFRINIC can implement hierarchical naming as an IRR operational change, then proponents should explain what additional technical benefit policy provides. Policy introduces enforcement, precedent, and rigidity. Those costs require justification. Saying that "the community prefers it" or "the community wants to move faster" does not explain why an operational matter should become a policy obligation. Kone also raised specific factual examples. Those examples deserve direct responses. Suggesting that only those with extensive experience across all RIRs may question the proposal risks turning expertise into gatekeeping rather than evidence-based discussion. The central question therefore remains: what can mandatory policy achieve here that an operational implementation cannot? Until that question is clearly answered, I support Kone's position and remain opposed. Regards, Fundiswa -------------- next part -------------- An HTML attachment was scrubbed... URL: From mselekuthandeka80 at gmail.com Tue Jul 21 06:36:39 2026 From: mselekuthandeka80 at gmail.com (Thandeka Mseleku) Date: Tue, 21 Jul 2026 08:36:39 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear colleagues, I support Kone's observations. The examples from other RIRs show that hierarchical AS-SET naming can be implemented through operational practices without necessarily becoming a policy requirement. Before introducing additional policy obligations, it is important to demonstrate why existing operational approaches would not adequately address the concerns raised. Where practical alternatives exist, they deserve careful consideration. Policy should remain focused on addressing clearly demonstrated needs rather than replacing operational decisions that can be managed through established registry practices. For these reasons, I remain opposed to AFPUB-2026-ASN-001-DRAFT02. BR, Thandeka Mseleku -------------- next part -------------- An HTML attachment was scrubbed... URL: From saul at enetworks.co.za Tue Jul 21 06:43:41 2026 From: saul at enetworks.co.za (Saul Stein) Date: Tue, 21 Jul 2026 06:43:41 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: So let?s look at this differently: Policy: community driven Operational: AFRINIC driven (no community input ? its operational) The statements that have been made is that the policy is giving to many rights to the ?organisation? Now, you are suggesting that this idea and it is managed be taken away from the community. Understand, if this is operational, AFRIINC decide what and how. Thus having this as a policy is more empowering. From: Thandeka Mseleku Sent: Tuesday, 21 July 2026 08:37 To: rpd at afrinic.net Cc: rpd-owner at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Dear colleagues, I support Kone's observations. The examples from other RIRs show that hierarchical AS-SET naming can be implemented through operational practices without necessarily becoming a policy requirement. Before introducing additional policy obligations, it is important to demonstrate why existing operational approaches would not adequately address the concerns raised. Where practical alternatives exist, they deserve careful consideration. Policy should remain focused on addressing clearly demonstrated needs rather than replacing operational decisions that can be managed through established registry practices. For these reasons, I remain opposed to AFPUB-2026-ASN-001-DRAFT02. BR, Thandeka Mseleku -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Tue Jul 21 07:06:45 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Tue, 21 Jul 2026 09:06:45 +0200 Subject: [rpd] Hierarchical AS-SETs objector analysis -> astroturfing Message-ID: Dear Mike, Ben and Hendrik, We are spending more time auditing prose than discussing policy. Mike, you have already distinguished actual flooding from ordinary AI-assisted writing. That should settle the tool question. Ben and Hendrik, feeding messages into Claude does not establish authorship, coordination, or bad faith. Claude is not a forensic authority, and a probability about writing style is not evidence. I choose the tools I use, I review what I submit, and I take responsibility for it. If there is genuine flooding, impersonation, or abuse, the co-chairs can address that conduct. If several messages repeat one concern, they can consolidate the concern. Neither situation gives individual participants authority to interrogate contributors or treat unfamiliar voices as less legitimate. Turning speculation about tools into a test of who may participate is not moderation. It is gatekeeping dressed as process. Please return to the policy itself. Regards, Nonhlanhla -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonjabulosphilile at gmail.com Tue Jul 21 07:32:35 2026 From: nonjabulosphilile at gmail.com (Nonjabulo Sphilile) Date: Tue, 21 Jul 2026 09:32:35 +0200 Subject: [rpd] Writing tools Message-ID: Dear colleagues, Hendrik, asking an AI system to label participants as astroturfers is not evidence. It is an automated opinion about writing style. The phrase ?humans with brains? also adds nothing to the policy discussion. It simply turns disagreement into personal contempt. Mike, your distinction between ordinary AI-assisted writing and intentional list flooding is reasonable. Actual flooding should be handled under existing rules, regardless of the tool used. But a ?+1? should not become compulsory. Participants may agree on the same issue while reaching it from different experiences or concerns. The co-chairs can consolidate repeated arguments without erasing the people raising them. Ben, the football comparison may be amusing, but the PDP is not a match in which familiar players, referees, or crowd preference determine legitimacy. Participation provides evidence and objection. It does not create authority over other participants. The correct approach is straightforward: moderate proven disruptive conduct, group genuinely repetitive points, and assess each distinct policy concern on its merits. Do not turn speculation about tools, identity, or familiarity into a gatekeeping mechanism. Regards, Nonjabulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Tue Jul 21 07:35:16 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Tue, 21 Jul 2026 09:35:16 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 111 In-Reply-To: References: Message-ID: Dear Saul, I understand your point about community involvement, and I agree that the community should have a voice in how AFRINIC operates. That said, I think the question is slightly different. Nobody is suggesting that the community should be excluded. The question is whether hierarchical naming needs to be a policy at all if the same result can be achieved operationally. If the objective is exactly the same, then why is a policy necessary? What does making it mandatory through policy achieve that an operational implementation cannot? You mention that an operational approach would leave AFRINIC to decide the details. That's true, but operational changes can still be transparent and informed by community feedback. Not every operational decision has to become a policy requirement. For me, the important issue is using the right mechanism for the problem. If an operational solution is sufficient, then I'd like to understand what specific benefit is gained by making it a policy obligation instead. I think answering that question would help move the discussion forward. Kind regards, Fundiswa On Tue, 21 Jul 2026, 08:44 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: RPD Digest, Vol 222, Issue 111 (Fundiswa Nadia Maseko) > 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Thandeka Mseleku) > 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Saul Stein) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2026 08:34:21 +0200 > From: Fundiswa Nadia Maseko > To: rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 111 > Message-ID: > < > CABV0QcQFcLoOaoZ97xyHmOBc7fU1gDJa74usFNv8mMC6ehPj5A at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Jordi, > > Kone's point is not that every RIR must follow the same procedure. Rather, > his point is that the same technical outcome has been achieved elsewhere > without making it binding policy. > > That makes the choice of mechanism relevant. > > A policy process should not be used simply because it is available. The > appropriate approach is to use the least powerful mechanism capable of > solving the operational problem. If AFRINIC can implement hierarchical > naming as an IRR operational change, then proponents should explain what > additional technical benefit policy provides. > > Policy introduces enforcement, precedent, and rigidity. Those costs require > justification. Saying that "the community prefers it" or "the community > wants to move faster" does not explain why an operational matter should > become a policy obligation. > > Kone also raised specific factual examples. Those examples deserve direct > responses. Suggesting that only those with extensive experience across all > RIRs may question the proposal risks turning expertise into gatekeeping > rather than evidence-based discussion. > > The central question therefore remains: what can mandatory policy achieve > here that an operational implementation cannot? > > Until that question is clearly answered, I support Kone's position and > remain opposed. > > Regards, > > Fundiswa > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/23554e60/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Tue, 21 Jul 2026 08:36:39 +0200 > From: Thandeka Mseleku > To: rpd at afrinic.net > Cc: rpd-owner at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > 12opts37KFc4juGwkd0ZCP_d4F99cm2FirBCSSYqyHw at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear colleagues, > > I support Kone's observations. The examples from other RIRs show that > hierarchical AS-SET naming can be implemented through operational practices > without necessarily becoming a policy requirement. > > Before introducing additional policy obligations, it is important to > demonstrate why existing operational approaches would not adequately > address the concerns raised. Where practical alternatives exist, they > deserve careful consideration. > > Policy should remain focused on addressing clearly demonstrated needs > rather than replacing operational decisions that can be managed through > established registry practices. > > For these reasons, I remain opposed to AFPUB-2026-ASN-001-DRAFT02. > > BR, > Thandeka Mseleku > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/f7a2a1e7/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Tue, 21 Jul 2026 06:43:41 +0000 > From: Saul Stein > To: Thandeka Mseleku , "rpd at afrinic.net" > > Cc: "rpd-owner at afrinic.net" > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > < > JNAP275MB1258655644EA68740D2EE98A8EC22 at JNAP275MB1258.ZAFP275.PROD.OUTLOOK.COM > > > > Content-Type: text/plain; charset="utf-8" > > So let?s look at this differently: > > Policy: community driven > Operational: AFRINIC driven (no community input ? its operational) > > The statements that have been made is that the policy is giving to many > rights to the ?organisation? > > Now, you are suggesting that this idea and it is managed be taken away > from the community. > > Understand, if this is operational, AFRIINC decide what and how. > > Thus having this as a policy is more empowering. > > > > From: Thandeka Mseleku > Sent: Tuesday, 21 July 2026 08:37 > To: rpd at afrinic.net > Cc: rpd-owner at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > Dear colleagues, > > I support Kone's observations. The examples from other RIRs show that > hierarchical AS-SET naming can be implemented through operational practices > without necessarily becoming a policy requirement. > > Before introducing additional policy obligations, it is important to > demonstrate why existing operational approaches would not adequately > address the concerns raised. Where practical alternatives exist, they > deserve careful consideration. > > Policy should remain focused on addressing clearly demonstrated needs > rather than replacing operational decisions that can be managed through > established registry practices. > > For these reasons, I remain opposed to AFPUB-2026-ASN-001-DRAFT02. > > BR, > Thandeka Mseleku > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/5b95665e/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 113 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Tue Jul 21 08:07:07 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Tue, 21 Jul 2026 10:07:07 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 111 In-Reply-To: References: Message-ID: <3B529937-17D8-40B5-9CE8-A1ED06188E71@consulintel.es> If we?ve a single RIR then it will be easy to do all in the same way ;-) This is something I've advocated for several times, but the problem is that there are different cultural backgrounds, different economies, different time zones, different languages, etc. It could be somehow resolved by having regional offices, etc., but it is a complex problem anyway. However, we don?t have a single RIR, and while what and how something is being done in different RIRs is important information, doesn?t necessarily need to be considered as relevant as to do it the exactly same way. So, even if something didn?t required a policy proposal in other regions, this doesn?t mean that other regions community discussion prefer to have a policy proposal, like the one that reached consensus here. In fact, it may happen tomorrow, that in other regions, for whatever reason, it is also decided to make a policy proposal, despite the relevant RIR having already adopted it without a policy. Will then your discourse follow? clearly now! Let me repeat again: The community is on top of the RIR. The community can take decisions, otherwise will not have a PDP. Note that even if it is done by means of an exclusive RIR operational decision, still it becomes mandatory, no difference vs a policy decision. The members are bound to both the operational RIR decisions and the policies. The ?central question? that you make is a generic question for all the policies, not only for this policy proposal. If you want to discuss about that, you need to consider if the PDP should have a more clear distinction about what is in scope and what not, and believe me, we had this discussion in all the other RIRs, and never succeded. Limiting the scope of the PDP is near to impossible beyond the obvious (example: we can?t make policies to control how many pets every member can have, but we can have policies about anything related to resource management). Regards, Jordi @jordipalet > El 21 jul 2026, a las 8:34, Fundiswa Nadia Maseko escribi?: > > Dear Jordi, > > Kone's point is not that every RIR must follow the same procedure. Rather, his point is that the same technical outcome has been achieved elsewhere without making it binding policy. > > That makes the choice of mechanism relevant. > > A policy process should not be used simply because it is available. The appropriate approach is to use the least powerful mechanism capable of solving the operational problem. If AFRINIC can implement hierarchical naming as an IRR operational change, then proponents should explain what additional technical benefit policy provides. > > Policy introduces enforcement, precedent, and rigidity. Those costs require justification. Saying that "the community prefers it" or "the community wants to move faster" does not explain why an operational matter should become a policy obligation. > > Kone also raised specific factual examples. Those examples deserve direct responses. Suggesting that only those with extensive experience across all RIRs may question the proposal risks turning expertise into gatekeeping rather than evidence-based discussion. > > The central question therefore remains: what can mandatory policy achieve here that an operational implementation cannot? > > Until that question is clearly answered, I support Kone's position and remain opposed. > > Regards, > > Fundiswa ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From gugudhlamini343 at gmail.com Tue Jul 21 08:16:08 2026 From: gugudhlamini343 at gmail.com (Gugu Dhlamini) Date: Tue, 21 Jul 2026 10:16:08 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: Dear Saul, That framing creates a false choice. An operational change does not have to mean ?no community input.? It can be publicly documented, consulted on, tested, reviewed, and reversed where necessary. The question is not whether the community may advise AFRINIC. It may. The question is whether that advice must become a binding policy obligation. Policy is not automatically empowering. Once adopted, the community does not enforce it. AFRINIC interprets, administers, and enforces it. The community discusses; the registry holds the lever. Confusing participation with continuing authority is precisely how mandate laundering occurs. If the same technical outcome can be achieved through a transparent, community-reviewed operational process, then policy adds an enforcement layer without adding technical value. Kone?s question therefore remains unanswered: what technical necessity requires binding policy rather than an operational implementation? I support Kone?s observations and remain opposed to AFPUB-2026-ASN-001-DRAFT02. Regards, Gugu On Tue, 21 Jul 2026, 8:46 am Saul Stein via RPD wrote: > So let?s look at this differently: > > > > Policy: community driven > > Operational: AFRINIC driven (no community input ? its operational) > > > > The statements that have been made is that the policy is giving to many > rights to the ?organisation? > > > > Now, you are suggesting that this idea and it is managed be taken away > from the community. > > > > Understand, if this is operational, AFRIINC decide what and how. > > > > Thus having this as a policy is more empowering. > > > > > > > > *From:* Thandeka Mseleku > *Sent:* Tuesday, 21 July 2026 08:37 > *To:* rpd at afrinic.net > *Cc:* rpd-owner at afrinic.net > *Subject:* Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > > > Dear colleagues, > > > > I support Kone's observations. The examples from other RIRs show that > hierarchical AS-SET naming can be implemented through operational practices > without necessarily becoming a policy requirement. > > > > Before introducing additional policy obligations, it is important to > demonstrate why existing operational approaches would not adequately > address the concerns raised. Where practical alternatives exist, they > deserve careful consideration. > > > > Policy should remain focused on addressing clearly demonstrated needs > rather than replacing operational decisions that can be managed through > established registry practices. > > > > For these reasons, I remain opposed to AFPUB-2026-ASN-001-DRAFT02. > > > > BR, > > Thandeka Mseleku > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mselekuthandeka80 at gmail.com Tue Jul 21 08:16:52 2026 From: mselekuthandeka80 at gmail.com (Thandeka Mseleku) Date: Tue, 21 Jul 2026 10:16:52 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: Dear Saul, Thank you for your perspective. I respectfully disagree that moving this matter to an operational process automatically removes community influence. Operational practices can still be transparent, accountable, and informed by community input without making every operational issue a policy obligation. The key question remains whether a policy requirement has been shown to be necessary. If the same objective can be achieved through operational mechanisms, then expanding policy may not be the most proportionate approach. For that reason, I continue to believe that this proposal has not sufficiently justified why policy is the appropriate solution. BR, Thandeka Mseleku On Tue, 21 Jul 2026, 08:43 Saul Stein, wrote: > So let?s look at this differently: > > > > Policy: community driven > > Operational: AFRINIC driven (no community input ? its operational) > > > > The statements that have been made is that the policy is giving to many > rights to the ?organisation? > > > > Now, you are suggesting that this idea and it is managed be taken away > from the community. > > > > Understand, if this is operational, AFRIINC decide what and how. > > > > Thus having this as a policy is more empowering. > > > > > > > > *From:* Thandeka Mseleku > *Sent:* Tuesday, 21 July 2026 08:37 > *To:* rpd at afrinic.net > *Cc:* rpd-owner at afrinic.net > *Subject:* Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > > > Dear colleagues, > > > > I support Kone's observations. The examples from other RIRs show that > hierarchical AS-SET naming can be implemented through operational practices > without necessarily becoming a policy requirement. > > > > Before introducing additional policy obligations, it is important to > demonstrate why existing operational approaches would not adequately > address the concerns raised. Where practical alternatives exist, they > deserve careful consideration. > > > > Policy should remain focused on addressing clearly demonstrated needs > rather than replacing operational decisions that can be managed through > established registry practices. > > > > For these reasons, I remain opposed to AFPUB-2026-ASN-001-DRAFT02. > > > > BR, > > Thandeka Mseleku > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mselekuthandeka80 at gmail.com Tue Jul 21 08:17:41 2026 From: mselekuthandeka80 at gmail.com (Thandeka Mseleku) Date: Tue, 21 Jul 2026 10:17:41 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: ? Thandeka reacted via Gmail On Tue, 21 Jul 2026, 10:16 Gugu Dhlamini, wrote: > Dear Saul, > > That framing creates a false choice. > > An operational change does not have to mean ?no community input.? It can > be publicly documented, consulted on, tested, reviewed, and reversed where > necessary. The question is not whether the community may advise AFRINIC. It > may. The question is whether that advice must become a binding policy > obligation. > > Policy is not automatically empowering. Once adopted, the community does > not enforce it. AFRINIC interprets, administers, and enforces it. The > community discusses; the registry holds the lever. Confusing participation > with continuing authority is precisely how mandate laundering occurs. > > If the same technical outcome can be achieved through a transparent, > community-reviewed operational process, then policy adds an enforcement > layer without adding technical value. > > Kone?s question therefore remains unanswered: what technical necessity > requires binding policy rather than an operational implementation? > > I support Kone?s observations and remain opposed to > AFPUB-2026-ASN-001-DRAFT02. > > Regards, > Gugu > > > > On Tue, 21 Jul 2026, 8:46 am Saul Stein via RPD wrote: > >> So let?s look at this differently: >> >> >> >> Policy: community driven >> >> Operational: AFRINIC driven (no community input ? its operational) >> >> >> >> The statements that have been made is that the policy is giving to many >> rights to the ?organisation? >> >> >> >> Now, you are suggesting that this idea and it is managed be taken away >> from the community. >> >> >> >> Understand, if this is operational, AFRIINC decide what and how. >> >> >> >> Thus having this as a policy is more empowering. >> >> >> >> >> >> >> >> *From:* Thandeka Mseleku >> *Sent:* Tuesday, 21 July 2026 08:37 >> *To:* rpd at afrinic.net >> *Cc:* rpd-owner at afrinic.net >> *Subject:* Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> >> >> >> Dear colleagues, >> >> >> >> I support Kone's observations. The examples from other RIRs show that >> hierarchical AS-SET naming can be implemented through operational practices >> without necessarily becoming a policy requirement. >> >> >> >> Before introducing additional policy obligations, it is important to >> demonstrate why existing operational approaches would not adequately >> address the concerns raised. Where practical alternatives exist, they >> deserve careful consideration. >> >> >> >> Policy should remain focused on addressing clearly demonstrated needs >> rather than replacing operational decisions that can be managed through >> established registry practices. >> >> >> >> For these reasons, I remain opposed to AFPUB-2026-ASN-001-DRAFT02. >> >> >> >> BR, >> >> Thandeka Mseleku >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/vnd.google.email-reaction+json Size: 37 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at alstonnetworks.net Tue Jul 21 08:26:11 2026 From: aa at alstonnetworks.net (Andrew Alston) Date: Tue, 21 Jul 2026 11:26:11 +0300 Subject: [rpd] RPD Digest, Vol 222, Issue 111 In-Reply-To: References: Message-ID: The answer to this is simple. AfriNiC is a community driven organisation - and anything done with regard to address allocation and management is done as per policy provided by the community. It is through policy that the community tells AfriNIC how to do things in regards to the allocation and handling of resources. Without policy, the discretion and rules are entirely in the hands of the registry, and the community voice is removed. This has been the way the RIR system has operated for decades and it works. The community exercises its voice and its right as to how things are done in relation to resource management through policy. Arguing that just because something can be done another way, is not in my view a valid argument against policy. Objections to policy need to be technically grounded and demonstrate that the policy would either cause harm or alternatively be impractical to implement. Anything else is simply arguing that policy should not exist because someone doesn?t like AfriNIC being told how the community wants things done - and that isn?t an argument that I believe rises to the level of a block on consensus. Please note - consensus does not require that the issue you raise have been fixed, it requires that they have been addressed, and should the community feel that despite the objections, the policy is something that should proceed based on the fact that the questions have been addressed if not necessarily accommodated, rough consensus still exists. Again, I support the policy and I see no technical or evidence/fact-based arguments against said policy. Andrew On Tue, Jul 21, 2026 at 09:34, Nia Petronella < nonhlanhlapetronella85 at gmail.com> wrote: > Dear PDWG, > > Kone is asking the right question. > > The issue is no longer whether hierarchical AS-SET naming is technically > possible or useful. It already exists. The issue is why AFRINIC needs a > binding policy to enforce what other RIRs largely treat as an operational > IRR matter. > > That distinction matters. An operational change adjusts how a service is > implemented. A policy creates an enforceable obligation and enlarges the > registry?s authority. If the same technical result can be achieved through > a community-reviewed implementation plan, then policy is not the minimum > necessary instrument. > > Saying that ?the community prefers policy? is not enough. Participation > may guide technical work, but it does not turn every preference into a > mandate. A mailing list is not a legislature, and the availability of the > PDP should not make policy the default answer to every operational setting. > > This is how gatekeeping expands: the registry begins with a useful > technical function, then policy converts that function into permission and > enforcement. The recordkeeper gradually becomes the rule-maker. > > The proponents should therefore answer Kone directly: what technical > outcome can mandatory policy achieve here that an operational > implementation cannot? > > Until that is clearly demonstrated, I support Kone?s questions and remain > opposed to the policy route. > > Regards, > Nonhlanhla > > > > On Tue, 21 Jul 2026, 8:20 am wrote: > >> Send RPD mailing list submissions to >> rpd at afrinic.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.afrinic.net/mailman/listinfo/rpd >> or, via email, send a message with subject or body 'help' to >> rpd-request at afrinic.net >> >> You can reach the person managing the list at >> rpd-owner at afrinic.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of RPD digest..." >> >> >> Today's Topics: >> >> 1. Re: RPD Digest, Vol 222, Issue 110 (Tshepo Masuku) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 21 Jul 2026 06:19:05 +0000 >> From: Tshepo Masuku >> To: "rpd at afrinic.net" >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 110 >> Message-ID: >> < >> VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com >> > >> >> Content-Type: text/plain; charset="windows-1252" >> >> Dear All, >> >> Kone?s point is directly relevant. If LACNIC, RIPE NCC, and ARIN can >> implement hierarchical AS-SET naming through operational mechanisms, then >> proponents must explain why AFRINIC needs a binding policy to achieve the >> same technical result. >> >> Saying that each RIR works differently does not answer that question. Nor >> does saying that ?the community is on top of the RIR.? A community may >> advise, object, and coordinate. It does not acquire unlimited authority to >> convert every operational preference into policy. A mailing list is not a >> legislature. >> >> If AFRINIC can solve this through an operational change, policy adds >> governance where technical administration would be sufficient. Speed and >> preference do not create mandate. >> >> Kone provided specific examples. Those should be answered with evidence, >> not by questioning whether he has worked in every RIR for many years. >> Experience is relevant, but it is not authority and it is not a substitute >> for argument. >> >> The unanswered question remains: what technical necessity requires policy >> rather than operational implementation? >> >> Until that is answered, Kone?s objection stands, and I support it. >> >> Regards, >> Tshepo >> >> >> ________________________________ >> From: rpd-request at afrinic.net >> Sent: Monday, July 20, 2026 11:10:57 pm >> To: rpd at afrinic.net >> Subject: RPD Digest, Vol 222, Issue 110 >> >> Send RPD mailing list submissions to >> rpd at afrinic.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.afrinic.net/mailman/listinfo/rpd >> or, via email, send a message with subject or body 'help' to >> rpd-request at afrinic.net >> >> You can reach the person managing the list at >> rpd-owner at afrinic.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of RPD digest..." >> >> >> Today's Topics: >> >> 1. Re: Writing tools (Ben Roberts - AfriNIC) >> 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Kone) >> 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> (jordi.palet at consulintel.es) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Mon, 20 Jul 2026 21:26:40 +0200 >> From: Ben Roberts - AfriNIC >> To: Nonjabulo Sphilile >> Cc: rpd at afrinic.net >> Subject: Re: [rpd] Writing tools >> Message-ID: <09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net> >> Content-Type: text/plain; charset="us-ascii" >> >> An HTML attachment was scrubbed... >> URL: < >> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/33c3ac9e/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 2 >> Date: Mon, 20 Jul 2026 20:34:20 +0000 >> From: Kone >> To: Seun Ojedeji >> Cc: rpd >> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> Message-ID: >> > 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Hello Seun, >> You may have misread my earlier mail. I clearly stated that LACNIC, RIPE >> NCC, and ARIN do not require policy to enforce hierarchical AS?SET naming. >> >> To help close the ongoing discussions, I believe addressing the questions >> I >> raised would bring clarity: >> * LACNIC enforces hierarchical AS?SET naming operationally, as part of >> their IRR design from inception. >> * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) >> process, not through policy. >> * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR >> operational matters, again without policy. >> >> >> These examples show that other RIRs (except APNIC) treat AS?SET naming as >> an operational IRR matter, not a policy obligation. >> >> This is why I asked whether AFRINIC could address this operationally >> rather >> than through policy, and why Last Call discussions would benefit from >> clear >> answers to these points. >> >> Thanks. >> --- >> Kone >> >> >> >> Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji a >> ?crit : >> >> > Hello Bakenon, >> > >> > Do refer to the proposal as it references URL to other RIR's policies >> for >> > thiis: >> > >> > https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> > >> > Regards >> > >> > ---- >> > Sent from my mobile >> > kindly excuse typos >> > >> > On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, >> > wrote: >> > >> >> Dear PDWG, >> >> >> >> I have been following the discussions on the hierarchical AS?SET naming >> >> scheme and would like clarification on a few points: >> >> >> >> 1. Could this matter be addressed operationally, as is done in ARIN, >> >> LACNIC, and RIPE NCC, without requiring policy changes? >> >> >> >> 2. If yes, why are we taking the policy route? Is it because AFRINIC >> >> currently lacks a defined process for handling operational issues that >> >> affect IRR services? >> >> >> >> 3. Given that the hierarchical naming scheme is already supported and >> >> currently exists within the IRR, this proposal represents an >> enforcement >> >> change rather than the introduction of a new technical standard. Why >> is a >> >> formal policy required to change an operational enforcement setting, >> rather >> >> than a community-vetted technical implementation plan?" >> >> >> >> Thank you. >> >> --- >> >> Kone >> >> >> >> >> >> >> >> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal a >> >> ?crit : >> >> >> >>> Dear PDWG, >> >>> >> >>> >> >>> The Policy Development Working Group (PDWG) Chairs have initiated a >> Last >> >>> Call for this proposal, following rough consensus at the AFRINIC-37 >> Public >> >>> Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June >> 2026. >> >>> >> >>> * Proposal Name: Hierarchical Names for New AS-SETs >> >>> >> >>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >> >>> >> >>> * Proposal URL: >> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >>> >> >>> Last Call closes on: July 31, 2026, at 23:59 UTC. >> >>> >> >>> >> >>> 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. >> >>> >> >>> >> >>> As always, we kindly request that all participants adhere to the >> AFRINIC >> >>> Code of Conduct to maintain a >> respectful >> >>> and professional environment on the mailing list. >> >>> >> >>> >> >>> Kind regards, >> >>> >> >>> >> >>> Haitham el Nakhal >> >>> >> >>> AFRINIC PDWG Co-Chair >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> RPD mailing list >> >>> RPD at afrinic.net >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >>> >> >> _______________________________________________ >> >> RPD mailing list >> >> RPD at afrinic.net >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/4563e1d5/attachment-0001.html >> > >> >> ------------------------------ >> >> Message: 3 >> Date: Mon, 20 Jul 2026 23:10:04 +0200 >> From: "jordi.palet at consulintel.es" >> To: rpd >> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> Message-ID: >> Content-Type: text/plain; charset="utf-8" >> >> Hi Kone, >> >> And what is the relevance of that? >> >> If you have a good understanding about all the RIRs, you will know that >> each RIR has their own ways to do things. In many senses they act very >> similarly and in general we end up with very similarly policies, but not >> always. Some RIRs have decided that some aspects are operational and don?t >> need a policy proposal. >> >> However, despite that, the community is on top of the RIR, and the >> community sometimes, may decide that they prefer a policy if the RIR hasn?t >> been proactive in advance in any specific topic, or even if the RIR was >> proactive, the community may prefer to speed up things, or to show the way >> the community prefers. >> >> For example, if AFRINIC has any specific operational aspect already in >> place, and the community prefer to manage that in a different way, the >> community may opt either for suggesting the RIR to modify that operational >> aspect or to do actually enforce it by means of a policy proposal. >> >> I think is important to know, by personal experience, how the other 4 >> RIRs work before stating something that is not correct, because if you >> don?t work in all the RIRs for many years, it will be difficult for you to >> know the past and I?m sure IA will not be able to be precise as well. >> >> Regards, >> Jordi >> >> @jordipalet >> >> > El 20 jul 2026, a las 22:34, Kone escribi?: >> > >> > Hello Seun, >> > You may have misread my earlier mail. I clearly stated that LACNIC, >> RIPE NCC, and ARIN do not require policy to enforce hierarchical AS?SET >> naming. >> > >> > To help close the ongoing discussions, I believe addressing the >> questions I raised would bring clarity: >> > * LACNIC enforces hierarchical AS?SET naming operationally, as part of >> their IRR design from inception. >> > * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) >> process, not through policy. >> > * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR >> operational matters, again without policy. >> > >> > >> > These examples show that other RIRs (except APNIC) treat AS?SET naming >> as an operational IRR matter, not a policy obligation. >> > >> > This is why I asked whether AFRINIC could address this operationally >> rather than through policy, and why Last Call discussions would benefit >> from clear answers to these points. >> > >> > Thanks. >> > --- >> > Kone >> > >> > >> > >> > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji > > a ?crit : >> >> Hello Bakenon, >> >> >> >> Do refer to the proposal as it references URL to other RIR's policies >> for thiis: >> >> >> >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >> >> >> Regards >> >> >> >> ---- >> >> Sent from my mobile >> >> kindly excuse typos >> >> >> >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, > > wrote: >> >>> Dear PDWG, >> >>> >> >>> I have been following the discussions on the hierarchical AS?SET >> naming scheme and would like clarification on a few points: >> >>> >> >>> 1. Could this matter be addressed operationally, as is done in ARIN, >> LACNIC, and RIPE NCC, without requiring policy changes? >> >>> >> >>> 2. If yes, why are we taking the policy route? Is it because AFRINIC >> currently lacks a defined process for handling operational issues that >> affect IRR services? >> >>> >> >>> 3. Given that the hierarchical naming scheme is already supported and >> currently exists within the IRR, this proposal represents an enforcement >> change rather than the introduction of a new technical standard. Why is a >> formal policy required to change an operational enforcement setting, rather >> than a community-vetted technical implementation plan?" >> >>> >> >>> Thank you. >> >>> --- >> >>> Kone >> >>> >> >>> >> >>> >> >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal > > a ?crit : >> >>>> Dear PDWG, >> >>>> >> >>>> >> >>>> The Policy Development Working Group (PDWG) Chairs have initiated a >> Last Call for this proposal, following rough consensus at the AFRINIC-37 >> Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June >> 2026. >> >>>> >> >>>> * Proposal Name: Hierarchical Names for New AS-SETs >> >>>> >> >>>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >> >>>> >> >>>> * Proposal URL: >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >>>> >> >>>> Last Call closes on: July 31, 2026, at 23:59 UTC. >> >>>> >> >>>> >> >>>> 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. >> >>>> >> >>>> >> >>>> As always, we kindly request that all participants adhere to the >> AFRINIC Code of Conduct to maintain a >> respectful and professional environment on the mailing list. >> >>>> >> >>>> >> >>>> Kind regards, >> >>>> >> >>>> >> >>>> Haitham el Nakhal >> >>>> >> >>>> AFRINIC PDWG Co-Chair >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> RPD mailing list >> >>>> RPD at afrinic.net >> >>>> https://lists.afrinic.net/mailman/listinfo/rpd >> >>> _______________________________________________ >> >>> RPD mailing list >> >>> RPD at afrinic.net >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> > _______________________________________________ >> > RPD mailing list >> > RPD at afrinic.net >> > https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the exclusive use of >> the individual(s) named above and further non-explicilty authorized >> disclosure, copying, distribution or use of the contents of this >> information, even if partially, including attached files, is strictly >> prohibited and will be considered a criminal offense. If you are not the >> intended recipient be aware that any disclosure, copying, distribution or >> use of the contents of this information, even if partially, including >> attached files, is strictly prohibited, will be considered a criminal >> offense, so you must reply to the original sender to inform about this >> communication and delete it. >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/b6777fa7/attachment.html >> > >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ------------------------------ >> >> End of RPD Digest, Vol 222, Issue 110 >> ************************************* >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e492c668/attachment.html >> > >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ------------------------------ >> >> End of RPD Digest, Vol 222, Issue 111 >> ************************************* >> > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sami at marwan.ma Tue Jul 21 08:45:47 2026 From: sami at marwan.ma (Sami Ait Ali Oulahcen) Date: Tue, 21 Jul 2026 09:45:47 +0100 (WEST) Subject: [rpd] Writing tools In-Reply-To: References: <062601dd184f$72379070$56a6b150$@iptrading.com> <066b01dd185a$e13e9080$a3bbb180$@iptrading.com> Message-ID: <1809710664.2684.1784623547091.JavaMail.zimbra@marwan.ma> Hi all, It's been really difficult to follow the list this past 2/3 days. And I imagine I'm not alone. I fully agree on moderating the AI madness. Otherwise, it'll dissuade many folks from following/participating. Regards, Sami ----- Original Message ----- From: "Mike Silber" To: "rpd >> AfriNIC Resource Policy" Sent: Monday, July 20, 2026 4:40:55 PM Subject: Re: [rpd] Writing tools A useful discussion - thank you On Mon, Jul 20, 2026 at 5:17?PM Mike Burns via RPD wrote: > Hi Rob, > > Yes, the language is a clear tell of AI usage, but flowery language alone > is not swamping the list. I don't want to hijack the AS-SET discussion, so thank you for the new > subject line. > Agreed > > Now, sometimes and unfortunately, I can use vague and flowery language > myself, so I would advise you to treat the AI stuff like the human stuff. > Ignore it if it's too vague or flowery to serve as a good argument, and > you have clearly laid out the two arguments in your last two lines. > Hopefully the list will show judgement and treat clear and concise > arguments better than vague ones. > And then the AI posts, if they want to be successful, will avoid the > purple prose. > I think it goes beyond flowery language. I am concerned that this is a precedent for AI generated DDoS attacks on the PDP and I do think we should have some light touch guidelines. I suspect that one of the reasons for the AI-slop flood is not just to try convince anyone of the value or legitimacy of their views but rather to overwhelm and frustrate other participants and cause them to withdraw from participation. Accordingly, I suggest we don't simply leave this to the co-chairs to determine on a case by case basis, but rather set some guidelines under which measures can be taken to avoid AI DDoS. Anyway - just my ZAR0,02 which is not worth much Regards Mike S _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd From noah at neo.co.tz Tue Jul 21 08:54:49 2026 From: noah at neo.co.tz (Noah) Date: Tue, 21 Jul 2026 11:54:49 +0300 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <1784239787450.20999@tra.gov.eg> Message-ID: Jordi, Also to add that the technical community's support for the proposal is based on our recognition, that, hierarchical naming improves attribution of the objects. The issue of validating the members inside the as-set is a separate one and I for one dont dispute that changamoto. Its also a fact that the specific, documented problem of unattributable as-set names in multi-source irr environments remains real. It needs a fix. Technical communities across the five Registy's are chosing to close that gap at creation time are doing so based on experienced operational incidents, some through policy (apnic) and others through techops implementation. The policy route will suffice at afrinic... Ahsante sana Noah On Tue, 21 Jul 2026, 12:17?am jordi.palet--- via RPD, wrote: > Hi Kone, > > And what is the relevance of that? > > If you have a good understanding about all the RIRs, you will know that > each RIR has their own ways to do things. In many senses they act very > similarly and in general we end up with very similarly policies, but not > always. Some RIRs have decided that some aspects are operational and don?t > need a policy proposal. > > However, despite that, the community is on top of the RIR, and the > community sometimes, may decide that they prefer a policy if the RIR hasn?t > been proactive in advance in any specific topic, or even if the RIR was > proactive, the community may prefer to speed up things, or to show the way > the community prefers. > > For example, if AFRINIC has any specific operational aspect already in > place, and the community prefer to manage that in a different way, the > community may opt either for suggesting the RIR to modify that operational > aspect or to do actually enforce it by means of a policy proposal. > > I think is important to know, by personal experience, how the other 4 RIRs > work before stating something that is not correct, because if you don?t > work in all the RIRs for many years, it will be difficult for you to know > the past and I?m sure IA will not be able to be precise as well. > > Regards, > Jordi > > @jordipalet > > El 20 jul 2026, a las 22:34, Kone escribi?: > > Hello Seun, > You may have misread my earlier mail. I clearly stated that LACNIC, RIPE > NCC, and ARIN do not require policy to enforce hierarchical AS?SET naming. > > To help close the ongoing discussions, I believe addressing the questions > I raised would bring clarity: > * LACNIC enforces hierarchical AS?SET naming operationally, as part of > their IRR design from inception. > * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) > process, not through policy. > * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR > operational matters, again without policy. > > > These examples show that other RIRs (except APNIC) treat AS?SET naming as > an operational IRR matter, not a policy obligation. > > This is why I asked whether AFRINIC could address this operationally > rather than through policy, and why Last Call discussions would benefit > from clear answers to these points. > > Thanks. > --- > Kone > > > > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji a > ?crit : > >> Hello Bakenon, >> >> Do refer to the proposal as it references URL to other RIR's policies for >> thiis: >> >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >> Regards >> >> ---- >> Sent from my mobile >> kindly excuse typos >> >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, >> wrote: >> >>> Dear PDWG, >>> >>> I have been following the discussions on the hierarchical AS?SET naming >>> scheme and would like clarification on a few points: >>> >>> 1. Could this matter be addressed operationally, as is done in ARIN, >>> LACNIC, and RIPE NCC, without requiring policy changes? >>> >>> 2. If yes, why are we taking the policy route? Is it because AFRINIC >>> currently lacks a defined process for handling operational issues that >>> affect IRR services? >>> >>> 3. Given that the hierarchical naming scheme is already supported and >>> currently exists within the IRR, this proposal represents an enforcement >>> change rather than the introduction of a new technical standard. Why is a >>> formal policy required to change an operational enforcement setting, rather >>> than a community-vetted technical implementation plan?" >>> >>> Thank you. >>> --- >>> Kone >>> >>> >>> >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal a >>> ?crit : >>> >>>> Dear PDWG, >>>> >>>> >>>> The Policy Development Working Group (PDWG) Chairs have initiated a >>>> Last Call for this proposal, following rough consensus at the AFRINIC-37 >>>> Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June >>>> 2026. >>>> >>>> * Proposal Name: Hierarchical Names for New AS-SETs >>>> >>>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >>>> >>>> * Proposal URL: >>>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >>>> >>>> Last Call closes on: July 31, 2026, at 23:59 UTC. >>>> >>>> >>>> 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. >>>> >>>> >>>> As always, we kindly request that all participants adhere to the >>>> AFRINIC Code of Conduct to maintain a >>>> respectful and professional environment on the mailing list. >>>> >>>> >>>> Kind regards, >>>> >>>> >>>> Haitham el Nakhal >>>> >>>> AFRINIC PDWG Co-Chair >>>> >>>> >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >> _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mendie5205 at gmail.com Tue Jul 21 09:22:46 2026 From: mendie5205 at gmail.com (Mendie Sweetness Mguqulwa) Date: Tue, 21 Jul 2026 11:22:46 +0200 Subject: [rpd] RPD hierarchical names for new AS - SETs In-Reply-To: References: Message-ID: Dear PDWG, 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. 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. 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. 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. 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. 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. 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. 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. The central question therefore remains: What technical requirement cannot be met through an open, community-reviewed operational implementation, but can only be achieved through binding policy? 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. Kind regards, On Tue, 21 Jul 2026, 10:55 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: Writing tools (Sami Ait Ali Oulahcen) > 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Noah) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2026 09:45:47 +0100 (WEST) > From: Sami Ait Ali Oulahcen > To: "rpd >> AfriNIC Resource Policy" > Subject: Re: [rpd] Writing tools > Message-ID: <1809710664.2684.1784623547091.JavaMail.zimbra at marwan.ma> > Content-Type: text/plain; charset=utf-8 > > Hi all, > > It's been really difficult to follow the list this past 2/3 days. And I > imagine I'm not alone. > I fully agree on moderating the AI madness. Otherwise, it'll dissuade many > folks from following/participating. > > Regards, > Sami > > ----- Original Message ----- > From: "Mike Silber" > To: "rpd >> AfriNIC Resource Policy" > Sent: Monday, July 20, 2026 4:40:55 PM > Subject: Re: [rpd] Writing tools > > A useful discussion - thank you > > On Mon, Jul 20, 2026 at 5:17?PM Mike Burns via RPD > wrote: > > > Hi Rob, > > > > Yes, the language is a clear tell of AI usage, but flowery language > alone > > is not swamping the list. > > I don't want to hijack the AS-SET discussion, so thank you for the new > > subject line. > > > > Agreed > > > > > Now, sometimes and unfortunately, I can use vague and flowery language > > myself, so I would advise you to treat the AI stuff like the human stuff. > > Ignore it if it's too vague or flowery to serve as a good argument, and > > you have clearly laid out the two arguments in your last two lines. > > Hopefully the list will show judgement and treat clear and concise > > arguments better than vague ones. > > And then the AI posts, if they want to be successful, will avoid the > > purple prose. > > > > I think it goes beyond flowery language. > > I am concerned that this is a precedent for AI generated DDoS attacks on > the PDP and I do think we should have some light touch guidelines. I > suspect that one of the reasons for the AI-slop flood is not just to try > convince anyone of the value or legitimacy of their views but rather to > overwhelm and frustrate other participants and cause them to withdraw from > participation. > > Accordingly, I suggest we don't simply leave this to the co-chairs to > determine on a case by case basis, but rather set some guidelines under > which measures can be taken to avoid AI DDoS. > > Anyway - just my ZAR0,02 which is not worth much > > Regards > > Mike S > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > > ------------------------------ > > Message: 2 > Date: Tue, 21 Jul 2026 11:54:49 +0300 > From: Noah > To: Jordi Palet Martinez > Cc: rpd > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > Q at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Jordi, > > Also to add that the technical community's support for the proposal is > based on our recognition, that, hierarchical naming improves attribution of > the objects. > > The issue of validating the members inside the as-set is a separate one and > I for one dont dispute that changamoto. Its also a fact that the specific, > documented problem of unattributable as-set names in multi-source irr > environments remains real. It needs a fix. > > Technical communities across the five Registy's are chosing to close that > gap at creation time are doing so based on experienced operational > incidents, some through policy (apnic) and others through techops > implementation. > > The policy route will suffice at afrinic... > > Ahsante sana > Noah > > On Tue, 21 Jul 2026, 12:17?am jordi.palet--- via RPD, > wrote: > > > Hi Kone, > > > > And what is the relevance of that? > > > > If you have a good understanding about all the RIRs, you will know that > > each RIR has their own ways to do things. In many senses they act very > > similarly and in general we end up with very similarly policies, but not > > always. Some RIRs have decided that some aspects are operational and > don?t > > need a policy proposal. > > > > However, despite that, the community is on top of the RIR, and the > > community sometimes, may decide that they prefer a policy if the RIR > hasn?t > > been proactive in advance in any specific topic, or even if the RIR was > > proactive, the community may prefer to speed up things, or to show the > way > > the community prefers. > > > > For example, if AFRINIC has any specific operational aspect already in > > place, and the community prefer to manage that in a different way, the > > community may opt either for suggesting the RIR to modify that > operational > > aspect or to do actually enforce it by means of a policy proposal. > > > > I think is important to know, by personal experience, how the other 4 > RIRs > > work before stating something that is not correct, because if you don?t > > work in all the RIRs for many years, it will be difficult for you to know > > the past and I?m sure IA will not be able to be precise as well. > > > > Regards, > > Jordi > > > > @jordipalet > > > > El 20 jul 2026, a las 22:34, Kone escribi?: > > > > Hello Seun, > > You may have misread my earlier mail. I clearly stated that LACNIC, RIPE > > NCC, and ARIN do not require policy to enforce hierarchical AS?SET > naming. > > > > To help close the ongoing discussions, I believe addressing the questions > > I raised would bring clarity: > > * LACNIC enforces hierarchical AS?SET naming operationally, as part of > > their IRR design from inception. > > * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) > > process, not through policy. > > * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR > > operational matters, again without policy. > > > > > > These examples show that other RIRs (except APNIC) treat AS?SET naming as > > an operational IRR matter, not a policy obligation. > > > > This is why I asked whether AFRINIC could address this operationally > > rather than through policy, and why Last Call discussions would benefit > > from clear answers to these points. > > > > Thanks. > > --- > > Kone > > > > > > > > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji a > > ?crit : > > > >> Hello Bakenon, > >> > >> Do refer to the proposal as it references URL to other RIR's policies > for > >> thiis: > >> > >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >> > >> Regards > >> > >> ---- > >> Sent from my mobile > >> kindly excuse typos > >> > >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, > >> wrote: > >> > >>> Dear PDWG, > >>> > >>> I have been following the discussions on the hierarchical AS?SET naming > >>> scheme and would like clarification on a few points: > >>> > >>> 1. Could this matter be addressed operationally, as is done in ARIN, > >>> LACNIC, and RIPE NCC, without requiring policy changes? > >>> > >>> 2. If yes, why are we taking the policy route? Is it because AFRINIC > >>> currently lacks a defined process for handling operational issues that > >>> affect IRR services? > >>> > >>> 3. Given that the hierarchical naming scheme is already supported and > >>> currently exists within the IRR, this proposal represents an > enforcement > >>> change rather than the introduction of a new technical standard. Why > is a > >>> formal policy required to change an operational enforcement setting, > rather > >>> than a community-vetted technical implementation plan?" > >>> > >>> Thank you. > >>> --- > >>> Kone > >>> > >>> > >>> > >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal a > >>> ?crit : > >>> > >>>> Dear PDWG, > >>>> > >>>> > >>>> The Policy Development Working Group (PDWG) Chairs have initiated a > >>>> Last Call for this proposal, following rough consensus at the > AFRINIC-37 > >>>> Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 > June > >>>> 2026. > >>>> > >>>> * Proposal Name: Hierarchical Names for New AS-SETs > >>>> > >>>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > >>>> > >>>> * Proposal URL: > >>>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >>>> > >>>> Last Call closes on: July 31, 2026, at 23:59 UTC. > >>>> > >>>> > >>>> 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. > >>>> > >>>> > >>>> As always, we kindly request that all participants adhere to the > >>>> AFRINIC Code of Conduct to maintain a > >>>> respectful and professional environment on the mailing list. > >>>> > >>>> > >>>> Kind regards, > >>>> > >>>> > >>>> Haitham el Nakhal > >>>> > >>>> AFRINIC PDWG Co-Chair > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> RPD mailing list > >>>> RPD at afrinic.net > >>>> https://lists.afrinic.net/mailman/listinfo/rpd > >>>> > >>> _______________________________________________ > >>> RPD mailing list > >>> RPD at afrinic.net > >>> https://lists.afrinic.net/mailman/listinfo/rpd > >>> > >> _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.theipv6company.com > > The IPv6 Company > > > > This electronic message contains information which may be privileged or > > confidential. The information is intended to be for the exclusive use of > > the individual(s) named above and further non-explicilty authorized > > disclosure, copying, distribution or use of the contents of this > > information, even if partially, including attached files, is strictly > > prohibited and will be considered a criminal offense. If you are not the > > intended recipient be aware that any disclosure, copying, distribution or > > use of the contents of this information, even if partially, including > > attached files, is strictly prohibited, will be considered a criminal > > offense, so you must reply to the original sender to inform about this > > communication and delete it. > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/68d4d480/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 117 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Tue Jul 21 09:56:49 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Tue, 21 Jul 2026 11:56:49 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 111 In-Reply-To: References: Message-ID: Dear Andrew, I do not accept the binary you have presented. No one is suggesting that AFRINIC should make operational changes in secret or without community input. An operational change can be published, consulted on, tested, documented, and reviewed. The real question is whether that input must be converted into binding policy enforced by the registry. Calling AFRINIC ?community-driven? does not answer who the community is or what it is authorised to bind. A self-selecting group of mailing-list participants can provide expertise, support, and objection. It does not automatically represent every member, resource holder, network, customer, or other affected party. The institutional reality also remains unchanged: participants discuss the policy, but AFRINIC interprets and enforces it. Community participation therefore does not eliminate registry power. It can become the language used to legitimise that power. This is why Kone?s examples matter. If LACNIC, RIPE NCC, and ARIN can achieve the same technical outcome through operational mechanisms, then policy is not technically inevitable. Proponents should explain what additional technical result binding policy provides, beyond converting an IRR setting into an enforceable obligation. I also disagree that an objection is valid only if it proves immediate operational harm or implementation failure. The choice of instrument, proportionality, reversibility, and expansion of enforcement authority are legitimate policy concerns. Last Call is not limited to asking whether software will break. It must also ask whether the proposed power is greater than the problem requires. Rough consensus does not require every objection to be accommodated. But an objection is not ?addressed? merely because supporters repeat that the community prefers policy. That is the very assumption being challenged. Procedure cannot be used to prove its own mandate. The fact that the RIR system has operated this way for decades demonstrates continuity of practice. It does not establish unlimited legitimacy of scope. I support Kone?s questions and remain opposed to AFPUB-2026-ASN-001-DRAFT02. Regards, Nonhlanhla On Tue, 21 Jul 2026, 10:26 am Andrew Alston wrote: > The answer to this is simple. AfriNiC is a community driven organisation > - and anything done with regard to address allocation and management is > done as per policy provided by the community. It is through policy that > the community tells AfriNIC how to do things in regards to the allocation > and handling of resources. > > Without policy, the discretion and rules are entirely in the hands of the > registry, and the community voice is removed. > > This has been the way the RIR system has operated for decades and it > works. The community exercises its voice and its right as to how things > are done in relation to resource management through policy. > > Arguing that just because something can be done another way, is not in my > view a valid argument against policy. Objections to policy need to be > technically grounded and demonstrate that the policy would either cause > harm or alternatively be impractical to implement. Anything else is simply > arguing that policy should not exist because someone doesn?t like AfriNIC > being told how the community wants things done - and that isn?t an argument > that I believe rises to the level of a block on consensus. > > Please note - consensus does not require that the issue you raise have > been fixed, it requires that they have been addressed, and should the > community feel that despite the objections, the policy is something that > should proceed based on the fact that the questions have been addressed if > not necessarily accommodated, rough consensus still exists. > > Again, I support the policy and I see no technical or evidence/fact-based > arguments against said policy. > > Andrew > > On Tue, Jul 21, 2026 at 09:34, Nia Petronella < > nonhlanhlapetronella85 at gmail.com> wrote: > >> Dear PDWG, >> >> Kone is asking the right question. >> >> The issue is no longer whether hierarchical AS-SET naming is technically >> possible or useful. It already exists. The issue is why AFRINIC needs a >> binding policy to enforce what other RIRs largely treat as an operational >> IRR matter. >> >> That distinction matters. An operational change adjusts how a service is >> implemented. A policy creates an enforceable obligation and enlarges the >> registry?s authority. If the same technical result can be achieved through >> a community-reviewed implementation plan, then policy is not the minimum >> necessary instrument. >> >> Saying that ?the community prefers policy? is not enough. Participation >> may guide technical work, but it does not turn every preference into a >> mandate. A mailing list is not a legislature, and the availability of the >> PDP should not make policy the default answer to every operational setting. >> >> This is how gatekeeping expands: the registry begins with a useful >> technical function, then policy converts that function into permission and >> enforcement. The recordkeeper gradually becomes the rule-maker. >> >> The proponents should therefore answer Kone directly: what technical >> outcome can mandatory policy achieve here that an operational >> implementation cannot? >> >> Until that is clearly demonstrated, I support Kone?s questions and remain >> opposed to the policy route. >> >> Regards, >> Nonhlanhla >> >> >> >> On Tue, 21 Jul 2026, 8:20 am wrote: >> >>> Send RPD mailing list submissions to >>> rpd at afrinic.net >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> or, via email, send a message with subject or body 'help' to >>> rpd-request at afrinic.net >>> >>> You can reach the person managing the list at >>> rpd-owner at afrinic.net >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of RPD digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Re: RPD Digest, Vol 222, Issue 110 (Tshepo Masuku) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Tue, 21 Jul 2026 06:19:05 +0000 >>> From: Tshepo Masuku >>> To: "rpd at afrinic.net" >>> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 110 >>> Message-ID: >>> < >>> VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com >>> > >>> >>> Content-Type: text/plain; charset="windows-1252" >>> >>> Dear All, >>> >>> Kone?s point is directly relevant. If LACNIC, RIPE NCC, and ARIN can >>> implement hierarchical AS-SET naming through operational mechanisms, then >>> proponents must explain why AFRINIC needs a binding policy to achieve the >>> same technical result. >>> >>> Saying that each RIR works differently does not answer that question. >>> Nor does saying that ?the community is on top of the RIR.? A community may >>> advise, object, and coordinate. It does not acquire unlimited authority to >>> convert every operational preference into policy. A mailing list is not a >>> legislature. >>> >>> If AFRINIC can solve this through an operational change, policy adds >>> governance where technical administration would be sufficient. Speed and >>> preference do not create mandate. >>> >>> Kone provided specific examples. Those should be answered with evidence, >>> not by questioning whether he has worked in every RIR for many years. >>> Experience is relevant, but it is not authority and it is not a substitute >>> for argument. >>> >>> The unanswered question remains: what technical necessity requires >>> policy rather than operational implementation? >>> >>> Until that is answered, Kone?s objection stands, and I support it. >>> >>> Regards, >>> Tshepo >>> >>> >>> ________________________________ >>> From: rpd-request at afrinic.net >>> Sent: Monday, July 20, 2026 11:10:57 pm >>> To: rpd at afrinic.net >>> Subject: RPD Digest, Vol 222, Issue 110 >>> >>> Send RPD mailing list submissions to >>> rpd at afrinic.net >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> or, via email, send a message with subject or body 'help' to >>> rpd-request at afrinic.net >>> >>> You can reach the person managing the list at >>> rpd-owner at afrinic.net >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of RPD digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Re: Writing tools (Ben Roberts - AfriNIC) >>> 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Kone) >>> 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>> (jordi.palet at consulintel.es) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Mon, 20 Jul 2026 21:26:40 +0200 >>> From: Ben Roberts - AfriNIC >>> To: Nonjabulo Sphilile >>> Cc: rpd at afrinic.net >>> Subject: Re: [rpd] Writing tools >>> Message-ID: <09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net> >>> Content-Type: text/plain; charset="us-ascii" >>> >>> An HTML attachment was scrubbed... >>> URL: < >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/33c3ac9e/attachment-0001.html >>> > >>> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Mon, 20 Jul 2026 20:34:20 +0000 >>> From: Kone >>> To: Seun Ojedeji >>> Cc: rpd >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>> Message-ID: >>> >> 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com> >>> Content-Type: text/plain; charset="utf-8" >>> >>> Hello Seun, >>> You may have misread my earlier mail. I clearly stated that LACNIC, RIPE >>> NCC, and ARIN do not require policy to enforce hierarchical AS?SET >>> naming. >>> >>> To help close the ongoing discussions, I believe addressing the >>> questions I >>> raised would bring clarity: >>> * LACNIC enforces hierarchical AS?SET naming operationally, as part of >>> their IRR design from inception. >>> * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) >>> process, not through policy. >>> * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR >>> operational matters, again without policy. >>> >>> >>> These examples show that other RIRs (except APNIC) treat AS?SET naming as >>> an operational IRR matter, not a policy obligation. >>> >>> This is why I asked whether AFRINIC could address this operationally >>> rather >>> than through policy, and why Last Call discussions would benefit from >>> clear >>> answers to these points. >>> >>> Thanks. >>> --- >>> Kone >>> >>> >>> >>> Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji a >>> ?crit : >>> >>> > Hello Bakenon, >>> > >>> > Do refer to the proposal as it references URL to other RIR's policies >>> for >>> > thiis: >>> > >>> > https://www.afrinic.net/afpub-2026-asn-001-draft02.html >>> > >>> > Regards >>> > >>> > ---- >>> > Sent from my mobile >>> > kindly excuse typos >>> > >>> > On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, >>> > wrote: >>> > >>> >> Dear PDWG, >>> >> >>> >> I have been following the discussions on the hierarchical AS?SET >>> naming >>> >> scheme and would like clarification on a few points: >>> >> >>> >> 1. Could this matter be addressed operationally, as is done in ARIN, >>> >> LACNIC, and RIPE NCC, without requiring policy changes? >>> >> >>> >> 2. If yes, why are we taking the policy route? Is it because AFRINIC >>> >> currently lacks a defined process for handling operational issues that >>> >> affect IRR services? >>> >> >>> >> 3. Given that the hierarchical naming scheme is already supported and >>> >> currently exists within the IRR, this proposal represents an >>> enforcement >>> >> change rather than the introduction of a new technical standard. Why >>> is a >>> >> formal policy required to change an operational enforcement setting, >>> rather >>> >> than a community-vetted technical implementation plan?" >>> >> >>> >> Thank you. >>> >> --- >>> >> Kone >>> >> >>> >> >>> >> >>> >> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal a >>> >> ?crit : >>> >> >>> >>> Dear PDWG, >>> >>> >>> >>> >>> >>> The Policy Development Working Group (PDWG) Chairs have initiated a >>> Last >>> >>> Call for this proposal, following rough consensus at the AFRINIC-37 >>> Public >>> >>> Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June >>> 2026. >>> >>> >>> >>> * Proposal Name: Hierarchical Names for New AS-SETs >>> >>> >>> >>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >>> >>> >>> >>> * Proposal URL: >>> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >>> >>> >>> >>> Last Call closes on: July 31, 2026, at 23:59 UTC. >>> >>> >>> >>> >>> >>> 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. >>> >>> >>> >>> >>> >>> As always, we kindly request that all participants adhere to the >>> AFRINIC >>> >>> Code of Conduct to maintain a >>> respectful >>> >>> and professional environment on the mailing list. >>> >>> >>> >>> >>> >>> Kind regards, >>> >>> >>> >>> >>> >>> Haitham el Nakhal >>> >>> >>> >>> AFRINIC PDWG Co-Chair >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> RPD mailing list >>> >>> RPD at afrinic.net >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> >>> >> _______________________________________________ >>> >> RPD mailing list >>> >> RPD at afrinic.net >>> >> https://lists.afrinic.net/mailman/listinfo/rpd >>> >> >>> > >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: < >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/4563e1d5/attachment-0001.html >>> > >>> >>> ------------------------------ >>> >>> Message: 3 >>> Date: Mon, 20 Jul 2026 23:10:04 +0200 >>> From: "jordi.palet at consulintel.es" >>> To: rpd >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>> Message-ID: >>> Content-Type: text/plain; charset="utf-8" >>> >>> Hi Kone, >>> >>> And what is the relevance of that? >>> >>> If you have a good understanding about all the RIRs, you will know that >>> each RIR has their own ways to do things. In many senses they act very >>> similarly and in general we end up with very similarly policies, but not >>> always. Some RIRs have decided that some aspects are operational and don?t >>> need a policy proposal. >>> >>> However, despite that, the community is on top of the RIR, and the >>> community sometimes, may decide that they prefer a policy if the RIR hasn?t >>> been proactive in advance in any specific topic, or even if the RIR was >>> proactive, the community may prefer to speed up things, or to show the way >>> the community prefers. >>> >>> For example, if AFRINIC has any specific operational aspect already in >>> place, and the community prefer to manage that in a different way, the >>> community may opt either for suggesting the RIR to modify that operational >>> aspect or to do actually enforce it by means of a policy proposal. >>> >>> I think is important to know, by personal experience, how the other 4 >>> RIRs work before stating something that is not correct, because if you >>> don?t work in all the RIRs for many years, it will be difficult for you to >>> know the past and I?m sure IA will not be able to be precise as well. >>> >>> Regards, >>> Jordi >>> >>> @jordipalet >>> >>> > El 20 jul 2026, a las 22:34, Kone escribi?: >>> > >>> > Hello Seun, >>> > You may have misread my earlier mail. I clearly stated that LACNIC, >>> RIPE NCC, and ARIN do not require policy to enforce hierarchical AS?SET >>> naming. >>> > >>> > To help close the ongoing discussions, I believe addressing the >>> questions I raised would bring clarity: >>> > * LACNIC enforces hierarchical AS?SET naming operationally, as part of >>> their IRR design from inception. >>> > * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) >>> process, not through policy. >>> > * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR >>> operational matters, again without policy. >>> > >>> > >>> > These examples show that other RIRs (except APNIC) treat AS?SET naming >>> as an operational IRR matter, not a policy obligation. >>> > >>> > This is why I asked whether AFRINIC could address this operationally >>> rather than through policy, and why Last Call discussions would benefit >>> from clear answers to these points. >>> > >>> > Thanks. >>> > --- >>> > Kone >>> > >>> > >>> > >>> > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji >> > a ?crit : >>> >> Hello Bakenon, >>> >> >>> >> Do refer to the proposal as it references URL to other RIR's policies >>> for thiis: >>> >> >>> >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >>> >> >>> >> Regards >>> >> >>> >> ---- >>> >> Sent from my mobile >>> >> kindly excuse typos >>> >> >>> >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, >> > wrote: >>> >>> Dear PDWG, >>> >>> >>> >>> I have been following the discussions on the hierarchical AS?SET >>> naming scheme and would like clarification on a few points: >>> >>> >>> >>> 1. Could this matter be addressed operationally, as is done in ARIN, >>> LACNIC, and RIPE NCC, without requiring policy changes? >>> >>> >>> >>> 2. If yes, why are we taking the policy route? Is it because AFRINIC >>> currently lacks a defined process for handling operational issues that >>> affect IRR services? >>> >>> >>> >>> 3. Given that the hierarchical naming scheme is already supported >>> and currently exists within the IRR, this proposal represents an >>> enforcement change rather than the introduction of a new technical >>> standard. Why is a formal policy required to change an operational >>> enforcement setting, rather than a community-vetted technical >>> implementation plan?" >>> >>> >>> >>> Thank you. >>> >>> --- >>> >>> Kone >>> >>> >>> >>> >>> >>> >>> >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal >> > a ?crit : >>> >>>> Dear PDWG, >>> >>>> >>> >>>> >>> >>>> The Policy Development Working Group (PDWG) Chairs have initiated a >>> Last Call for this proposal, following rough consensus at the AFRINIC-37 >>> Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June >>> 2026. >>> >>>> >>> >>>> * Proposal Name: Hierarchical Names for New AS-SETs >>> >>>> >>> >>>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >>> >>>> >>> >>>> * Proposal URL: >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >>> >>>> >>> >>>> Last Call closes on: July 31, 2026, at 23:59 UTC. >>> >>>> >>> >>>> >>> >>>> 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. >>> >>>> >>> >>>> >>> >>>> As always, we kindly request that all participants adhere to the >>> AFRINIC Code of Conduct to maintain a >>> respectful and professional environment on the mailing list. >>> >>>> >>> >>>> >>> >>>> Kind regards, >>> >>>> >>> >>>> >>> >>>> Haitham el Nakhal >>> >>>> >>> >>>> AFRINIC PDWG Co-Chair >>> >>>> >>> >>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> RPD mailing list >>> >>>> RPD at afrinic.net >>> >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> _______________________________________________ >>> >>> RPD mailing list >>> >>> RPD at afrinic.net >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> > _______________________________________________ >>> > RPD mailing list >>> > RPD at afrinic.net >>> > https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> >>> >>> ********************************************** >>> IPv4 is over >>> Are you ready for the new Internet ? >>> http://www.theipv6company.com >>> The IPv6 Company >>> >>> This electronic message contains information which may be privileged or >>> confidential. The information is intended to be for the exclusive use of >>> the individual(s) named above and further non-explicilty authorized >>> disclosure, copying, distribution or use of the contents of this >>> information, even if partially, including attached files, is strictly >>> prohibited and will be considered a criminal offense. If you are not the >>> intended recipient be aware that any disclosure, copying, distribution or >>> use of the contents of this information, even if partially, including >>> attached files, is strictly prohibited, will be considered a criminal >>> offense, so you must reply to the original sender to inform about this >>> communication and delete it. >>> >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: < >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/b6777fa7/attachment.html >>> > >>> >>> ------------------------------ >>> >>> Subject: Digest Footer >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> >>> ------------------------------ >>> >>> End of RPD Digest, Vol 222, Issue 110 >>> ************************************* >>> >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: < >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e492c668/attachment.html >>> > >>> >>> ------------------------------ >>> >>> Subject: Digest Footer >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> >>> ------------------------------ >>> >>> End of RPD Digest, Vol 222, Issue 111 >>> ************************************* >>> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Tue Jul 21 10:03:14 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Tue, 21 Jul 2026 12:03:14 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 119 In-Reply-To: References: Message-ID: Dear Jordi, Thank you for your response. I agree that AFRINIC is not required to follow the same approach as other RIRs. Every region should make decisions that suit its own community. My point, however, is slightly different. I wasn't suggesting that AFRINIC should copy another RIR simply because they did it that way. Rather, I'm asking what specific problem is solved by making this a policy instead of implementing it operationally. If both approaches achieve the same technical outcome, then what additional value does the policy itself provide? I think that's an important distinction. The fact that the community can choose policy doesn't necessarily mean policy is the most appropriate mechanism in every case. I'd be interested to hear what practical or technical benefit you believe is only possible through policy and not through an operational implementation. Kind regards, Fundiswa On Tue, 21 Jul 2026, 11:57 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: RPD Digest, Vol 222, Issue 111 (Nia Petronella) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2026 11:56:49 +0200 > From: Nia Petronella > To: Andrew Alston > Cc: rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 111 > Message-ID: > itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Andrew, > > I do not accept the binary you have presented. > > No one is suggesting that AFRINIC should make operational changes in secret > or without community input. An operational change can be published, > consulted on, tested, documented, and reviewed. The real question is > whether that input must be converted into binding policy enforced by the > registry. > > Calling AFRINIC ?community-driven? does not answer who the community is or > what it is authorised to bind. A self-selecting group of mailing-list > participants can provide expertise, support, and objection. It does not > automatically represent every member, resource holder, network, customer, > or other affected party. > > The institutional reality also remains unchanged: participants discuss the > policy, but AFRINIC interprets and enforces it. Community participation > therefore does not eliminate registry power. It can become the language > used to legitimise that power. > > This is why Kone?s examples matter. If LACNIC, RIPE NCC, and ARIN can > achieve the same technical outcome through operational mechanisms, then > policy is not technically inevitable. Proponents should explain what > additional technical result binding policy provides, beyond converting an > IRR setting into an enforceable obligation. > > I also disagree that an objection is valid only if it proves immediate > operational harm or implementation failure. The choice of instrument, > proportionality, reversibility, and expansion of enforcement authority are > legitimate policy concerns. Last Call is not limited to asking whether > software will break. It must also ask whether the proposed power is greater > than the problem requires. > > Rough consensus does not require every objection to be accommodated. But an > objection is not ?addressed? merely because supporters repeat that the > community prefers policy. That is the very assumption being challenged. > Procedure cannot be used to prove its own mandate. > > The fact that the RIR system has operated this way for decades demonstrates > continuity of practice. It does not establish unlimited legitimacy of > scope. > > I support Kone?s questions and remain opposed to > AFPUB-2026-ASN-001-DRAFT02. > > Regards, > Nonhlanhla > > > > On Tue, 21 Jul 2026, 10:26 am Andrew Alston wrote: > > > The answer to this is simple. AfriNiC is a community driven organisation > > - and anything done with regard to address allocation and management is > > done as per policy provided by the community. It is through policy that > > the community tells AfriNIC how to do things in regards to the allocation > > and handling of resources. > > > > Without policy, the discretion and rules are entirely in the hands of the > > registry, and the community voice is removed. > > > > This has been the way the RIR system has operated for decades and it > > works. The community exercises its voice and its right as to how things > > are done in relation to resource management through policy. > > > > Arguing that just because something can be done another way, is not in my > > view a valid argument against policy. Objections to policy need to be > > technically grounded and demonstrate that the policy would either cause > > harm or alternatively be impractical to implement. Anything else is > simply > > arguing that policy should not exist because someone doesn?t like AfriNIC > > being told how the community wants things done - and that isn?t an > argument > > that I believe rises to the level of a block on consensus. > > > > Please note - consensus does not require that the issue you raise have > > been fixed, it requires that they have been addressed, and should the > > community feel that despite the objections, the policy is something that > > should proceed based on the fact that the questions have been addressed > if > > not necessarily accommodated, rough consensus still exists. > > > > Again, I support the policy and I see no technical or evidence/fact-based > > arguments against said policy. > > > > Andrew > > > > On Tue, Jul 21, 2026 at 09:34, Nia Petronella < > > nonhlanhlapetronella85 at gmail.com> wrote: > > > >> Dear PDWG, > >> > >> Kone is asking the right question. > >> > >> The issue is no longer whether hierarchical AS-SET naming is technically > >> possible or useful. It already exists. The issue is why AFRINIC needs a > >> binding policy to enforce what other RIRs largely treat as an > operational > >> IRR matter. > >> > >> That distinction matters. An operational change adjusts how a service is > >> implemented. A policy creates an enforceable obligation and enlarges the > >> registry?s authority. If the same technical result can be achieved > through > >> a community-reviewed implementation plan, then policy is not the minimum > >> necessary instrument. > >> > >> Saying that ?the community prefers policy? is not enough. Participation > >> may guide technical work, but it does not turn every preference into a > >> mandate. A mailing list is not a legislature, and the availability of > the > >> PDP should not make policy the default answer to every operational > setting. > >> > >> This is how gatekeeping expands: the registry begins with a useful > >> technical function, then policy converts that function into permission > and > >> enforcement. The recordkeeper gradually becomes the rule-maker. > >> > >> The proponents should therefore answer Kone directly: what technical > >> outcome can mandatory policy achieve here that an operational > >> implementation cannot? > >> > >> Until that is clearly demonstrated, I support Kone?s questions and > remain > >> opposed to the policy route. > >> > >> Regards, > >> Nonhlanhla > >> > >> > >> > >> On Tue, 21 Jul 2026, 8:20 am wrote: > >> > >>> Send RPD mailing list submissions to > >>> rpd at afrinic.net > >>> > >>> To subscribe or unsubscribe via the World Wide Web, visit > >>> https://lists.afrinic.net/mailman/listinfo/rpd > >>> or, via email, send a message with subject or body 'help' to > >>> rpd-request at afrinic.net > >>> > >>> You can reach the person managing the list at > >>> rpd-owner at afrinic.net > >>> > >>> When replying, please edit your Subject line so it is more specific > >>> than "Re: Contents of RPD digest..." > >>> > >>> > >>> Today's Topics: > >>> > >>> 1. Re: RPD Digest, Vol 222, Issue 110 (Tshepo Masuku) > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> > >>> Message: 1 > >>> Date: Tue, 21 Jul 2026 06:19:05 +0000 > >>> From: Tshepo Masuku > >>> To: "rpd at afrinic.net" > >>> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 110 > >>> Message-ID: > >>> < > >>> > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > >>> > > >>> > >>> Content-Type: text/plain; charset="windows-1252" > >>> > >>> Dear All, > >>> > >>> Kone?s point is directly relevant. If LACNIC, RIPE NCC, and ARIN can > >>> implement hierarchical AS-SET naming through operational mechanisms, > then > >>> proponents must explain why AFRINIC needs a binding policy to achieve > the > >>> same technical result. > >>> > >>> Saying that each RIR works differently does not answer that question. > >>> Nor does saying that ?the community is on top of the RIR.? A community > may > >>> advise, object, and coordinate. It does not acquire unlimited > authority to > >>> convert every operational preference into policy. A mailing list is > not a > >>> legislature. > >>> > >>> If AFRINIC can solve this through an operational change, policy adds > >>> governance where technical administration would be sufficient. Speed > and > >>> preference do not create mandate. > >>> > >>> Kone provided specific examples. Those should be answered with > evidence, > >>> not by questioning whether he has worked in every RIR for many years. > >>> Experience is relevant, but it is not authority and it is not a > substitute > >>> for argument. > >>> > >>> The unanswered question remains: what technical necessity requires > >>> policy rather than operational implementation? > >>> > >>> Until that is answered, Kone?s objection stands, and I support it. > >>> > >>> Regards, > >>> Tshepo > >>> > >>> > >>> ________________________________ > >>> From: rpd-request at afrinic.net > >>> Sent: Monday, July 20, 2026 11:10:57 pm > >>> To: rpd at afrinic.net > >>> Subject: RPD Digest, Vol 222, Issue 110 > >>> > >>> Send RPD mailing list submissions to > >>> rpd at afrinic.net > >>> > >>> To subscribe or unsubscribe via the World Wide Web, visit > >>> https://lists.afrinic.net/mailman/listinfo/rpd > >>> or, via email, send a message with subject or body 'help' to > >>> rpd-request at afrinic.net > >>> > >>> You can reach the person managing the list at > >>> rpd-owner at afrinic.net > >>> > >>> When replying, please edit your Subject line so it is more specific > >>> than "Re: Contents of RPD digest..." > >>> > >>> > >>> Today's Topics: > >>> > >>> 1. Re: Writing tools (Ben Roberts - AfriNIC) > >>> 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Kone) > >>> 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >>> (jordi.palet at consulintel.es) > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> > >>> Message: 1 > >>> Date: Mon, 20 Jul 2026 21:26:40 +0200 > >>> From: Ben Roberts - AfriNIC > >>> To: Nonjabulo Sphilile > >>> Cc: rpd at afrinic.net > >>> Subject: Re: [rpd] Writing tools > >>> Message-ID: <09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net> > >>> Content-Type: text/plain; charset="us-ascii" > >>> > >>> An HTML attachment was scrubbed... > >>> URL: < > >>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/33c3ac9e/attachment-0001.html > >>> > > >>> > >>> ------------------------------ > >>> > >>> Message: 2 > >>> Date: Mon, 20 Jul 2026 20:34:20 +0000 > >>> From: Kone > >>> To: Seun Ojedeji > >>> Cc: rpd > >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >>> Message-ID: > >>> >>> 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com> > >>> Content-Type: text/plain; charset="utf-8" > >>> > >>> Hello Seun, > >>> You may have misread my earlier mail. I clearly stated that LACNIC, > RIPE > >>> NCC, and ARIN do not require policy to enforce hierarchical AS?SET > >>> naming. > >>> > >>> To help close the ongoing discussions, I believe addressing the > >>> questions I > >>> raised would bring clarity: > >>> * LACNIC enforces hierarchical AS?SET naming operationally, as part of > >>> their IRR design from inception. > >>> * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) > >>> process, not through policy. > >>> * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR > >>> operational matters, again without policy. > >>> > >>> > >>> These examples show that other RIRs (except APNIC) treat AS?SET naming > as > >>> an operational IRR matter, not a policy obligation. > >>> > >>> This is why I asked whether AFRINIC could address this operationally > >>> rather > >>> than through policy, and why Last Call discussions would benefit from > >>> clear > >>> answers to these points. > >>> > >>> Thanks. > >>> --- > >>> Kone > >>> > >>> > >>> > >>> Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji a > >>> ?crit : > >>> > >>> > Hello Bakenon, > >>> > > >>> > Do refer to the proposal as it references URL to other RIR's policies > >>> for > >>> > thiis: > >>> > > >>> > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >>> > > >>> > Regards > >>> > > >>> > ---- > >>> > Sent from my mobile > >>> > kindly excuse typos > >>> > > >>> > On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, > > >>> > wrote: > >>> > > >>> >> Dear PDWG, > >>> >> > >>> >> I have been following the discussions on the hierarchical AS?SET > >>> naming > >>> >> scheme and would like clarification on a few points: > >>> >> > >>> >> 1. Could this matter be addressed operationally, as is done in ARIN, > >>> >> LACNIC, and RIPE NCC, without requiring policy changes? > >>> >> > >>> >> 2. If yes, why are we taking the policy route? Is it because AFRINIC > >>> >> currently lacks a defined process for handling operational issues > that > >>> >> affect IRR services? > >>> >> > >>> >> 3. Given that the hierarchical naming scheme is already supported > and > >>> >> currently exists within the IRR, this proposal represents an > >>> enforcement > >>> >> change rather than the introduction of a new technical standard. Why > >>> is a > >>> >> formal policy required to change an operational enforcement setting, > >>> rather > >>> >> than a community-vetted technical implementation plan?" > >>> >> > >>> >> Thank you. > >>> >> --- > >>> >> Kone > >>> >> > >>> >> > >>> >> > >>> >> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal > a > >>> >> ?crit : > >>> >> > >>> >>> Dear PDWG, > >>> >>> > >>> >>> > >>> >>> The Policy Development Working Group (PDWG) Chairs have initiated a > >>> Last > >>> >>> Call for this proposal, following rough consensus at the AFRINIC-37 > >>> Public > >>> >>> Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June > >>> 2026. > >>> >>> > >>> >>> * Proposal Name: Hierarchical Names for New AS-SETs > >>> >>> > >>> >>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > >>> >>> > >>> >>> * Proposal URL: > >>> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >>> >>> > >>> >>> Last Call closes on: July 31, 2026, at 23:59 UTC. > >>> >>> > >>> >>> > >>> >>> 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. > >>> >>> > >>> >>> > >>> >>> As always, we kindly request that all participants adhere to the > >>> AFRINIC > >>> >>> Code of Conduct to maintain a > >>> respectful > >>> >>> and professional environment on the mailing list. > >>> >>> > >>> >>> > >>> >>> Kind regards, > >>> >>> > >>> >>> > >>> >>> Haitham el Nakhal > >>> >>> > >>> >>> AFRINIC PDWG Co-Chair > >>> >>> > >>> >>> > >>> >>> > >>> >>> _______________________________________________ > >>> >>> RPD mailing list > >>> >>> RPD at afrinic.net > >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >>> >>> > >>> >> _______________________________________________ > >>> >> RPD mailing list > >>> >> RPD at afrinic.net > >>> >> https://lists.afrinic.net/mailman/listinfo/rpd > >>> >> > >>> > > >>> -------------- next part -------------- > >>> An HTML attachment was scrubbed... > >>> URL: < > >>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/4563e1d5/attachment-0001.html > >>> > > >>> > >>> ------------------------------ > >>> > >>> Message: 3 > >>> Date: Mon, 20 Jul 2026 23:10:04 +0200 > >>> From: "jordi.palet at consulintel.es" > >>> To: rpd > >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >>> Message-ID: > >>> Content-Type: text/plain; charset="utf-8" > >>> > >>> Hi Kone, > >>> > >>> And what is the relevance of that? > >>> > >>> If you have a good understanding about all the RIRs, you will know that > >>> each RIR has their own ways to do things. In many senses they act very > >>> similarly and in general we end up with very similarly policies, but > not > >>> always. Some RIRs have decided that some aspects are operational and > don?t > >>> need a policy proposal. > >>> > >>> However, despite that, the community is on top of the RIR, and the > >>> community sometimes, may decide that they prefer a policy if the RIR > hasn?t > >>> been proactive in advance in any specific topic, or even if the RIR was > >>> proactive, the community may prefer to speed up things, or to show the > way > >>> the community prefers. > >>> > >>> For example, if AFRINIC has any specific operational aspect already in > >>> place, and the community prefer to manage that in a different way, the > >>> community may opt either for suggesting the RIR to modify that > operational > >>> aspect or to do actually enforce it by means of a policy proposal. > >>> > >>> I think is important to know, by personal experience, how the other 4 > >>> RIRs work before stating something that is not correct, because if you > >>> don?t work in all the RIRs for many years, it will be difficult for > you to > >>> know the past and I?m sure IA will not be able to be precise as well. > >>> > >>> Regards, > >>> Jordi > >>> > >>> @jordipalet > >>> > >>> > El 20 jul 2026, a las 22:34, Kone > escribi?: > >>> > > >>> > Hello Seun, > >>> > You may have misread my earlier mail. I clearly stated that LACNIC, > >>> RIPE NCC, and ARIN do not require policy to enforce hierarchical AS?SET > >>> naming. > >>> > > >>> > To help close the ongoing discussions, I believe addressing the > >>> questions I raised would bring clarity: > >>> > * LACNIC enforces hierarchical AS?SET naming operationally, as part > of > >>> their IRR design from inception. > >>> > * RIPE NCC handles IRR changes through their Numbered Work Items > (NWI) > >>> process, not through policy. > >>> > * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR > >>> operational matters, again without policy. > >>> > > >>> > > >>> > These examples show that other RIRs (except APNIC) treat AS?SET > naming > >>> as an operational IRR matter, not a policy obligation. > >>> > > >>> > This is why I asked whether AFRINIC could address this operationally > >>> rather than through policy, and why Last Call discussions would benefit > >>> from clear answers to these points. > >>> > > >>> > Thanks. > >>> > --- > >>> > Kone > >>> > > >>> > > >>> > > >>> > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji >>> > a ?crit : > >>> >> Hello Bakenon, > >>> >> > >>> >> Do refer to the proposal as it references URL to other RIR's > policies > >>> for thiis: > >>> >> > >>> >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >>> >> > >>> >> Regards > >>> >> > >>> >> ---- > >>> >> Sent from my mobile > >>> >> kindly excuse typos > >>> >> > >>> >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, < > bakenon.kone at sancfis.net > >>> > wrote: > >>> >>> Dear PDWG, > >>> >>> > >>> >>> I have been following the discussions on the hierarchical AS?SET > >>> naming scheme and would like clarification on a few points: > >>> >>> > >>> >>> 1. Could this matter be addressed operationally, as is done in > ARIN, > >>> LACNIC, and RIPE NCC, without requiring policy changes? > >>> >>> > >>> >>> 2. If yes, why are we taking the policy route? Is it because > AFRINIC > >>> currently lacks a defined process for handling operational issues that > >>> affect IRR services? > >>> >>> > >>> >>> 3. Given that the hierarchical naming scheme is already supported > >>> and currently exists within the IRR, this proposal represents an > >>> enforcement change rather than the introduction of a new technical > >>> standard. Why is a formal policy required to change an operational > >>> enforcement setting, rather than a community-vetted technical > >>> implementation plan?" > >>> >>> > >>> >>> Thank you. > >>> >>> --- > >>> >>> Kone > >>> >>> > >>> >>> > >>> >>> > >>> >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal >>> > a ?crit : > >>> >>>> Dear PDWG, > >>> >>>> > >>> >>>> > >>> >>>> The Policy Development Working Group (PDWG) Chairs have initiated > a > >>> Last Call for this proposal, following rough consensus at the > AFRINIC-37 > >>> Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 > June > >>> 2026. > >>> >>>> > >>> >>>> * Proposal Name: Hierarchical Names for New AS-SETs > >>> >>>> > >>> >>>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > >>> >>>> > >>> >>>> * Proposal URL: > >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >>> >>>> > >>> >>>> Last Call closes on: July 31, 2026, at 23:59 UTC. > >>> >>>> > >>> >>>> > >>> >>>> 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. > >>> >>>> > >>> >>>> > >>> >>>> As always, we kindly request that all participants adhere to the > >>> AFRINIC Code of Conduct to maintain a > >>> respectful and professional environment on the mailing list. > >>> >>>> > >>> >>>> > >>> >>>> Kind regards, > >>> >>>> > >>> >>>> > >>> >>>> Haitham el Nakhal > >>> >>>> > >>> >>>> AFRINIC PDWG Co-Chair > >>> >>>> > >>> >>>> > >>> >>>> > >>> >>>> _______________________________________________ > >>> >>>> RPD mailing list > >>> >>>> RPD at afrinic.net > >>> >>>> https://lists.afrinic.net/mailman/listinfo/rpd > >>> >>> _______________________________________________ > >>> >>> RPD mailing list > >>> >>> RPD at afrinic.net > >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >>> > _______________________________________________ > >>> > RPD mailing list > >>> > RPD at afrinic.net > >>> > https://lists.afrinic.net/mailman/listinfo/rpd > >>> > >>> > >>> > >>> ********************************************** > >>> IPv4 is over > >>> Are you ready for the new Internet ? > >>> http://www.theipv6company.com > >>> The IPv6 Company > >>> > >>> This electronic message contains information which may be privileged or > >>> confidential. The information is intended to be for the exclusive use > of > >>> the individual(s) named above and further non-explicilty authorized > >>> disclosure, copying, distribution or use of the contents of this > >>> information, even if partially, including attached files, is strictly > >>> prohibited and will be considered a criminal offense. If you are not > the > >>> intended recipient be aware that any disclosure, copying, distribution > or > >>> use of the contents of this information, even if partially, including > >>> attached files, is strictly prohibited, will be considered a criminal > >>> offense, so you must reply to the original sender to inform about this > >>> communication and delete it. > >>> > >>> -------------- next part -------------- > >>> An HTML attachment was scrubbed... > >>> URL: < > >>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/b6777fa7/attachment.html > >>> > > >>> > >>> ------------------------------ > >>> > >>> Subject: Digest Footer > >>> > >>> _______________________________________________ > >>> RPD mailing list > >>> RPD at afrinic.net > >>> https://lists.afrinic.net/mailman/listinfo/rpd > >>> > >>> > >>> ------------------------------ > >>> > >>> End of RPD Digest, Vol 222, Issue 110 > >>> ************************************* > >>> > >>> -------------- next part -------------- > >>> An HTML attachment was scrubbed... > >>> URL: < > >>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e492c668/attachment.html > >>> > > >>> > >>> ------------------------------ > >>> > >>> Subject: Digest Footer > >>> > >>> _______________________________________________ > >>> RPD mailing list > >>> RPD at afrinic.net > >>> https://lists.afrinic.net/mailman/listinfo/rpd > >>> > >>> > >>> ------------------------------ > >>> > >>> End of RPD Digest, Vol 222, Issue 111 > >>> ************************************* > >>> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/9c41424a/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 119 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Tue Jul 21 10:04:46 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Tue, 21 Jul 2026 12:04:46 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 113 In-Reply-To: References: Message-ID: Hi Saul, That split is too neat. Community input does not require every operational change to become binding policy. AFRINIC can consult publicly, document the implementation, and remain accountable without creating another enforcement rule. Once policy is adopted, the community does not enforce it. AFRINIC does. The question remains: what technical result requires policy that a transparent operational process cannot deliver? Regards, Nonhlanhla On Tue, 21 Jul 2026, 8:44 am wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: RPD Digest, Vol 222, Issue 111 (Fundiswa Nadia Maseko) > 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Thandeka Mseleku) > 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Saul Stein) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2026 08:34:21 +0200 > From: Fundiswa Nadia Maseko > To: rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 111 > Message-ID: > < > CABV0QcQFcLoOaoZ97xyHmOBc7fU1gDJa74usFNv8mMC6ehPj5A at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Jordi, > > Kone's point is not that every RIR must follow the same procedure. Rather, > his point is that the same technical outcome has been achieved elsewhere > without making it binding policy. > > That makes the choice of mechanism relevant. > > A policy process should not be used simply because it is available. The > appropriate approach is to use the least powerful mechanism capable of > solving the operational problem. If AFRINIC can implement hierarchical > naming as an IRR operational change, then proponents should explain what > additional technical benefit policy provides. > > Policy introduces enforcement, precedent, and rigidity. Those costs require > justification. Saying that "the community prefers it" or "the community > wants to move faster" does not explain why an operational matter should > become a policy obligation. > > Kone also raised specific factual examples. Those examples deserve direct > responses. Suggesting that only those with extensive experience across all > RIRs may question the proposal risks turning expertise into gatekeeping > rather than evidence-based discussion. > > The central question therefore remains: what can mandatory policy achieve > here that an operational implementation cannot? > > Until that question is clearly answered, I support Kone's position and > remain opposed. > > Regards, > > Fundiswa > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/23554e60/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Tue, 21 Jul 2026 08:36:39 +0200 > From: Thandeka Mseleku > To: rpd at afrinic.net > Cc: rpd-owner at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > 12opts37KFc4juGwkd0ZCP_d4F99cm2FirBCSSYqyHw at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear colleagues, > > I support Kone's observations. The examples from other RIRs show that > hierarchical AS-SET naming can be implemented through operational practices > without necessarily becoming a policy requirement. > > Before introducing additional policy obligations, it is important to > demonstrate why existing operational approaches would not adequately > address the concerns raised. Where practical alternatives exist, they > deserve careful consideration. > > Policy should remain focused on addressing clearly demonstrated needs > rather than replacing operational decisions that can be managed through > established registry practices. > > For these reasons, I remain opposed to AFPUB-2026-ASN-001-DRAFT02. > > BR, > Thandeka Mseleku > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/f7a2a1e7/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Tue, 21 Jul 2026 06:43:41 +0000 > From: Saul Stein > To: Thandeka Mseleku , "rpd at afrinic.net" > > Cc: "rpd-owner at afrinic.net" > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > < > JNAP275MB1258655644EA68740D2EE98A8EC22 at JNAP275MB1258.ZAFP275.PROD.OUTLOOK.COM > > > > Content-Type: text/plain; charset="utf-8" > > So let?s look at this differently: > > Policy: community driven > Operational: AFRINIC driven (no community input ? its operational) > > The statements that have been made is that the policy is giving to many > rights to the ?organisation? > > Now, you are suggesting that this idea and it is managed be taken away > from the community. > > Understand, if this is operational, AFRIINC decide what and how. > > Thus having this as a policy is more empowering. > > > > From: Thandeka Mseleku > Sent: Tuesday, 21 July 2026 08:37 > To: rpd at afrinic.net > Cc: rpd-owner at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > Dear colleagues, > > I support Kone's observations. The examples from other RIRs show that > hierarchical AS-SET naming can be implemented through operational practices > without necessarily becoming a policy requirement. > > Before introducing additional policy obligations, it is important to > demonstrate why existing operational approaches would not adequately > address the concerns raised. Where practical alternatives exist, they > deserve careful consideration. > > Policy should remain focused on addressing clearly demonstrated needs > rather than replacing operational decisions that can be managed through > established registry practices. > > For these reasons, I remain opposed to AFPUB-2026-ASN-001-DRAFT02. > > BR, > Thandeka Mseleku > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/5b95665e/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 113 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at alstonnetworks.net Tue Jul 21 10:19:51 2026 From: aa at alstonnetworks.net (Andrew Alston) Date: Tue, 21 Jul 2026 13:19:51 +0300 Subject: [rpd] RPD Digest, Vol 222, Issue 111 In-Reply-To: References: Message-ID: Hi Nia, Ok, let me try and further expand on what I have said. Firstly - in a rough consensus approach - an objection carries weight when it is factually backed up and proves a real problem. From what I can see, your objection fails to meet this threshold. It is the objector's obligation to substantiate objections to the point where they can be answered and addressed. Now, looking at your objection, it seems to be that the policy expands AfriNIC's mandate and grants them more power. I point out that AfriNIC's mandate is clearly spelled out in article 3.4 of the bylaws as currently written, which was amended by a supermajority vote of the members. In my opinion, you have yet to articulate the harm this policy creates or explain how it falls outside the scope of the PDP or the AfriNIC mandate as defined in its bylaws. While you may prefer AfriNIC to be simply a database without policy restrictions, that is not what this community has consistently agreed upon, nor is it what the bylaws voted on by the members endorse. As such, I believe your position has been addressed by the mandate given to AfriNIC under section 3.4 of the bylaws. During my tenure as an Area Director within the IETF, I often saw disagreements on particular standards. It was always the objector's responsibility to articulate the real problem, and then the working group decided if that disagreement was sufficient to justify blocking the proposal. >From what I have seen - your objection seems to be "I don't like this because it gives AfriNIC power of enforcement where such is unnecessary". I disagree with this stance and believe that the policy committee has the right to set policy as it sees fit, and you have not demonstrated any real HARM from the policy. Thanks Andrew On Tue, Jul 21, 2026 at 12:57?PM Nia Petronella < nonhlanhlapetronella85 at gmail.com> wrote: > Dear Andrew, > > I do not accept the binary you have presented. > > No one is suggesting that AFRINIC should make operational changes in > secret or without community input. An operational change can be published, > consulted on, tested, documented, and reviewed. The real question is > whether that input must be converted into binding policy enforced by the > registry. > > Calling AFRINIC ?community-driven? does not answer who the community is or > what it is authorised to bind. A self-selecting group of mailing-list > participants can provide expertise, support, and objection. It does not > automatically represent every member, resource holder, network, customer, > or other affected party. > > The institutional reality also remains unchanged: participants discuss the > policy, but AFRINIC interprets and enforces it. Community participation > therefore does not eliminate registry power. It can become the language > used to legitimise that power. > > This is why Kone?s examples matter. If LACNIC, RIPE NCC, and ARIN can > achieve the same technical outcome through operational mechanisms, then > policy is not technically inevitable. Proponents should explain what > additional technical result binding policy provides, beyond converting an > IRR setting into an enforceable obligation. > > I also disagree that an objection is valid only if it proves immediate > operational harm or implementation failure. The choice of instrument, > proportionality, reversibility, and expansion of enforcement authority are > legitimate policy concerns. Last Call is not limited to asking whether > software will break. It must also ask whether the proposed power is greater > than the problem requires. > > Rough consensus does not require every objection to be accommodated. But > an objection is not ?addressed? merely because supporters repeat that the > community prefers policy. That is the very assumption being challenged. > Procedure cannot be used to prove its own mandate. > > The fact that the RIR system has operated this way for decades > demonstrates continuity of practice. It does not establish unlimited > legitimacy of scope. > > I support Kone?s questions and remain opposed to > AFPUB-2026-ASN-001-DRAFT02. > > Regards, > Nonhlanhla > > > > On Tue, 21 Jul 2026, 10:26 am Andrew Alston wrote: > >> The answer to this is simple. AfriNiC is a community driven organisation >> - and anything done with regard to address allocation and management is >> done as per policy provided by the community. It is through policy that >> the community tells AfriNIC how to do things in regards to the allocation >> and handling of resources. >> >> Without policy, the discretion and rules are entirely in the hands of the >> registry, and the community voice is removed. >> >> This has been the way the RIR system has operated for decades and it >> works. The community exercises its voice and its right as to how things >> are done in relation to resource management through policy. >> >> Arguing that just because something can be done another way, is not in my >> view a valid argument against policy. Objections to policy need to be >> technically grounded and demonstrate that the policy would either cause >> harm or alternatively be impractical to implement. Anything else is simply >> arguing that policy should not exist because someone doesn?t like AfriNIC >> being told how the community wants things done - and that isn?t an argument >> that I believe rises to the level of a block on consensus. >> >> Please note - consensus does not require that the issue you raise have >> been fixed, it requires that they have been addressed, and should the >> community feel that despite the objections, the policy is something that >> should proceed based on the fact that the questions have been addressed if >> not necessarily accommodated, rough consensus still exists. >> >> Again, I support the policy and I see no technical or evidence/fact-based >> arguments against said policy. >> >> Andrew >> >> On Tue, Jul 21, 2026 at 09:34, Nia Petronella < >> nonhlanhlapetronella85 at gmail.com> wrote: >> >>> Dear PDWG, >>> >>> Kone is asking the right question. >>> >>> The issue is no longer whether hierarchical AS-SET naming is technically >>> possible or useful. It already exists. The issue is why AFRINIC needs a >>> binding policy to enforce what other RIRs largely treat as an operational >>> IRR matter. >>> >>> That distinction matters. An operational change adjusts how a service is >>> implemented. A policy creates an enforceable obligation and enlarges the >>> registry?s authority. If the same technical result can be achieved through >>> a community-reviewed implementation plan, then policy is not the minimum >>> necessary instrument. >>> >>> Saying that ?the community prefers policy? is not enough. Participation >>> may guide technical work, but it does not turn every preference into a >>> mandate. A mailing list is not a legislature, and the availability of the >>> PDP should not make policy the default answer to every operational setting. >>> >>> This is how gatekeeping expands: the registry begins with a useful >>> technical function, then policy converts that function into permission and >>> enforcement. The recordkeeper gradually becomes the rule-maker. >>> >>> The proponents should therefore answer Kone directly: what technical >>> outcome can mandatory policy achieve here that an operational >>> implementation cannot? >>> >>> Until that is clearly demonstrated, I support Kone?s questions and >>> remain opposed to the policy route. >>> >>> Regards, >>> Nonhlanhla >>> >>> >>> >>> On Tue, 21 Jul 2026, 8:20 am wrote: >>> >>>> Send RPD mailing list submissions to >>>> rpd at afrinic.net >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> or, via email, send a message with subject or body 'help' to >>>> rpd-request at afrinic.net >>>> >>>> You can reach the person managing the list at >>>> rpd-owner at afrinic.net >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of RPD digest..." >>>> >>>> >>>> Today's Topics: >>>> >>>> 1. Re: RPD Digest, Vol 222, Issue 110 (Tshepo Masuku) >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> Message: 1 >>>> Date: Tue, 21 Jul 2026 06:19:05 +0000 >>>> From: Tshepo Masuku >>>> To: "rpd at afrinic.net" >>>> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 110 >>>> Message-ID: >>>> < >>>> VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com >>>> > >>>> >>>> Content-Type: text/plain; charset="windows-1252" >>>> >>>> Dear All, >>>> >>>> Kone?s point is directly relevant. If LACNIC, RIPE NCC, and ARIN can >>>> implement hierarchical AS-SET naming through operational mechanisms, then >>>> proponents must explain why AFRINIC needs a binding policy to achieve the >>>> same technical result. >>>> >>>> Saying that each RIR works differently does not answer that question. >>>> Nor does saying that ?the community is on top of the RIR.? A community may >>>> advise, object, and coordinate. It does not acquire unlimited authority to >>>> convert every operational preference into policy. A mailing list is not a >>>> legislature. >>>> >>>> If AFRINIC can solve this through an operational change, policy adds >>>> governance where technical administration would be sufficient. Speed and >>>> preference do not create mandate. >>>> >>>> Kone provided specific examples. Those should be answered with >>>> evidence, not by questioning whether he has worked in every RIR for many >>>> years. Experience is relevant, but it is not authority and it is not a >>>> substitute for argument. >>>> >>>> The unanswered question remains: what technical necessity requires >>>> policy rather than operational implementation? >>>> >>>> Until that is answered, Kone?s objection stands, and I support it. >>>> >>>> Regards, >>>> Tshepo >>>> >>>> >>>> ________________________________ >>>> From: rpd-request at afrinic.net >>>> Sent: Monday, July 20, 2026 11:10:57 pm >>>> To: rpd at afrinic.net >>>> Subject: RPD Digest, Vol 222, Issue 110 >>>> >>>> Send RPD mailing list submissions to >>>> rpd at afrinic.net >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> or, via email, send a message with subject or body 'help' to >>>> rpd-request at afrinic.net >>>> >>>> You can reach the person managing the list at >>>> rpd-owner at afrinic.net >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of RPD digest..." >>>> >>>> >>>> Today's Topics: >>>> >>>> 1. Re: Writing tools (Ben Roberts - AfriNIC) >>>> 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >>>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Kone) >>>> 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >>>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>>> (jordi.palet at consulintel.es) >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> Message: 1 >>>> Date: Mon, 20 Jul 2026 21:26:40 +0200 >>>> From: Ben Roberts - AfriNIC >>>> To: Nonjabulo Sphilile >>>> Cc: rpd at afrinic.net >>>> Subject: Re: [rpd] Writing tools >>>> Message-ID: <09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net> >>>> Content-Type: text/plain; charset="us-ascii" >>>> >>>> An HTML attachment was scrubbed... >>>> URL: < >>>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/33c3ac9e/attachment-0001.html >>>> > >>>> >>>> ------------------------------ >>>> >>>> Message: 2 >>>> Date: Mon, 20 Jul 2026 20:34:20 +0000 >>>> From: Kone >>>> To: Seun Ojedeji >>>> Cc: rpd >>>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >>>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>>> Message-ID: >>>> >>> 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com> >>>> Content-Type: text/plain; charset="utf-8" >>>> >>>> Hello Seun, >>>> You may have misread my earlier mail. I clearly stated that LACNIC, RIPE >>>> NCC, and ARIN do not require policy to enforce hierarchical AS?SET >>>> naming. >>>> >>>> To help close the ongoing discussions, I believe addressing the >>>> questions I >>>> raised would bring clarity: >>>> * LACNIC enforces hierarchical AS?SET naming operationally, as part of >>>> their IRR design from inception. >>>> * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) >>>> process, not through policy. >>>> * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR >>>> operational matters, again without policy. >>>> >>>> >>>> These examples show that other RIRs (except APNIC) treat AS?SET naming >>>> as >>>> an operational IRR matter, not a policy obligation. >>>> >>>> This is why I asked whether AFRINIC could address this operationally >>>> rather >>>> than through policy, and why Last Call discussions would benefit from >>>> clear >>>> answers to these points. >>>> >>>> Thanks. >>>> --- >>>> Kone >>>> >>>> >>>> >>>> Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji a >>>> ?crit : >>>> >>>> > Hello Bakenon, >>>> > >>>> > Do refer to the proposal as it references URL to other RIR's policies >>>> for >>>> > thiis: >>>> > >>>> > https://www.afrinic.net/afpub-2026-asn-001-draft02.html >>>> > >>>> > Regards >>>> > >>>> > ---- >>>> > Sent from my mobile >>>> > kindly excuse typos >>>> > >>>> > On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, >>>> > wrote: >>>> > >>>> >> Dear PDWG, >>>> >> >>>> >> I have been following the discussions on the hierarchical AS?SET >>>> naming >>>> >> scheme and would like clarification on a few points: >>>> >> >>>> >> 1. Could this matter be addressed operationally, as is done in ARIN, >>>> >> LACNIC, and RIPE NCC, without requiring policy changes? >>>> >> >>>> >> 2. If yes, why are we taking the policy route? Is it because AFRINIC >>>> >> currently lacks a defined process for handling operational issues >>>> that >>>> >> affect IRR services? >>>> >> >>>> >> 3. Given that the hierarchical naming scheme is already supported and >>>> >> currently exists within the IRR, this proposal represents an >>>> enforcement >>>> >> change rather than the introduction of a new technical standard. Why >>>> is a >>>> >> formal policy required to change an operational enforcement setting, >>>> rather >>>> >> than a community-vetted technical implementation plan?" >>>> >> >>>> >> Thank you. >>>> >> --- >>>> >> Kone >>>> >> >>>> >> >>>> >> >>>> >> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal >>>> a >>>> >> ?crit : >>>> >> >>>> >>> Dear PDWG, >>>> >>> >>>> >>> >>>> >>> The Policy Development Working Group (PDWG) Chairs have initiated a >>>> Last >>>> >>> Call for this proposal, following rough consensus at the AFRINIC-37 >>>> Public >>>> >>> Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June >>>> 2026. >>>> >>> >>>> >>> * Proposal Name: Hierarchical Names for New AS-SETs >>>> >>> >>>> >>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >>>> >>> >>>> >>> * Proposal URL: >>>> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >>>> >>> >>>> >>> Last Call closes on: July 31, 2026, at 23:59 UTC. >>>> >>> >>>> >>> >>>> >>> 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. >>>> >>> >>>> >>> >>>> >>> As always, we kindly request that all participants adhere to the >>>> AFRINIC >>>> >>> Code of Conduct to maintain a >>>> respectful >>>> >>> and professional environment on the mailing list. >>>> >>> >>>> >>> >>>> >>> Kind regards, >>>> >>> >>>> >>> >>>> >>> Haitham el Nakhal >>>> >>> >>>> >>> AFRINIC PDWG Co-Chair >>>> >>> >>>> >>> >>>> >>> >>>> >>> _______________________________________________ >>>> >>> RPD mailing list >>>> >>> RPD at afrinic.net >>>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>> >>>> >> _______________________________________________ >>>> >> RPD mailing list >>>> >> RPD at afrinic.net >>>> >> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >> >>>> > >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: < >>>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/4563e1d5/attachment-0001.html >>>> > >>>> >>>> ------------------------------ >>>> >>>> Message: 3 >>>> Date: Mon, 20 Jul 2026 23:10:04 +0200 >>>> From: "jordi.palet at consulintel.es" >>>> To: rpd >>>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >>>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>>> Message-ID: >>>> Content-Type: text/plain; charset="utf-8" >>>> >>>> Hi Kone, >>>> >>>> And what is the relevance of that? >>>> >>>> If you have a good understanding about all the RIRs, you will know that >>>> each RIR has their own ways to do things. In many senses they act very >>>> similarly and in general we end up with very similarly policies, but not >>>> always. Some RIRs have decided that some aspects are operational and don?t >>>> need a policy proposal. >>>> >>>> However, despite that, the community is on top of the RIR, and the >>>> community sometimes, may decide that they prefer a policy if the RIR hasn?t >>>> been proactive in advance in any specific topic, or even if the RIR was >>>> proactive, the community may prefer to speed up things, or to show the way >>>> the community prefers. >>>> >>>> For example, if AFRINIC has any specific operational aspect already in >>>> place, and the community prefer to manage that in a different way, the >>>> community may opt either for suggesting the RIR to modify that operational >>>> aspect or to do actually enforce it by means of a policy proposal. >>>> >>>> I think is important to know, by personal experience, how the other 4 >>>> RIRs work before stating something that is not correct, because if you >>>> don?t work in all the RIRs for many years, it will be difficult for you to >>>> know the past and I?m sure IA will not be able to be precise as well. >>>> >>>> Regards, >>>> Jordi >>>> >>>> @jordipalet >>>> >>>> > El 20 jul 2026, a las 22:34, Kone >>>> escribi?: >>>> > >>>> > Hello Seun, >>>> > You may have misread my earlier mail. I clearly stated that LACNIC, >>>> RIPE NCC, and ARIN do not require policy to enforce hierarchical AS?SET >>>> naming. >>>> > >>>> > To help close the ongoing discussions, I believe addressing the >>>> questions I raised would bring clarity: >>>> > * LACNIC enforces hierarchical AS?SET naming operationally, as part >>>> of their IRR design from inception. >>>> > * RIPE NCC handles IRR changes through their Numbered Work Items >>>> (NWI) process, not through policy. >>>> > * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR >>>> operational matters, again without policy. >>>> > >>>> > >>>> > These examples show that other RIRs (except APNIC) treat AS?SET >>>> naming as an operational IRR matter, not a policy obligation. >>>> > >>>> > This is why I asked whether AFRINIC could address this operationally >>>> rather than through policy, and why Last Call discussions would benefit >>>> from clear answers to these points. >>>> > >>>> > Thanks. >>>> > --- >>>> > Kone >>>> > >>>> > >>>> > >>>> > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji >>> > a ?crit : >>>> >> Hello Bakenon, >>>> >> >>>> >> Do refer to the proposal as it references URL to other RIR's >>>> policies for thiis: >>>> >> >>>> >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >>>> >> >>>> >> Regards >>>> >> >>>> >> ---- >>>> >> Sent from my mobile >>>> >> kindly excuse typos >>>> >> >>>> >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, >>> > wrote: >>>> >>> Dear PDWG, >>>> >>> >>>> >>> I have been following the discussions on the hierarchical AS?SET >>>> naming scheme and would like clarification on a few points: >>>> >>> >>>> >>> 1. Could this matter be addressed operationally, as is done in >>>> ARIN, LACNIC, and RIPE NCC, without requiring policy changes? >>>> >>> >>>> >>> 2. If yes, why are we taking the policy route? Is it because >>>> AFRINIC currently lacks a defined process for handling operational issues >>>> that affect IRR services? >>>> >>> >>>> >>> 3. Given that the hierarchical naming scheme is already supported >>>> and currently exists within the IRR, this proposal represents an >>>> enforcement change rather than the introduction of a new technical >>>> standard. Why is a formal policy required to change an operational >>>> enforcement setting, rather than a community-vetted technical >>>> implementation plan?" >>>> >>> >>>> >>> Thank you. >>>> >>> --- >>>> >>> Kone >>>> >>> >>>> >>> >>>> >>> >>>> >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal >>> > a ?crit : >>>> >>>> Dear PDWG, >>>> >>>> >>>> >>>> >>>> >>>> The Policy Development Working Group (PDWG) Chairs have initiated >>>> a Last Call for this proposal, following rough consensus at the AFRINIC-37 >>>> Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June >>>> 2026. >>>> >>>> >>>> >>>> * Proposal Name: Hierarchical Names for New AS-SETs >>>> >>>> >>>> >>>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >>>> >>>> >>>> >>>> * Proposal URL: >>>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >>>> >>>> >>>> >>>> Last Call closes on: July 31, 2026, at 23:59 UTC. >>>> >>>> >>>> >>>> >>>> >>>> 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. >>>> >>>> >>>> >>>> >>>> >>>> As always, we kindly request that all participants adhere to the >>>> AFRINIC Code of Conduct to maintain a >>>> respectful and professional environment on the mailing list. >>>> >>>> >>>> >>>> >>>> >>>> Kind regards, >>>> >>>> >>>> >>>> >>>> >>>> Haitham el Nakhal >>>> >>>> >>>> >>>> AFRINIC PDWG Co-Chair >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> RPD mailing list >>>> >>>> RPD at afrinic.net >>>> >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>> _______________________________________________ >>>> >>> RPD mailing list >>>> >>> RPD at afrinic.net >>>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> > _______________________________________________ >>>> > RPD mailing list >>>> > RPD at afrinic.net >>>> > https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>>> >>>> >>>> ********************************************** >>>> IPv4 is over >>>> Are you ready for the new Internet ? >>>> http://www.theipv6company.com >>>> The IPv6 Company >>>> >>>> This electronic message contains information which may be privileged or >>>> confidential. The information is intended to be for the exclusive use of >>>> the individual(s) named above and further non-explicilty authorized >>>> disclosure, copying, distribution or use of the contents of this >>>> information, even if partially, including attached files, is strictly >>>> prohibited and will be considered a criminal offense. If you are not the >>>> intended recipient be aware that any disclosure, copying, distribution or >>>> use of the contents of this information, even if partially, including >>>> attached files, is strictly prohibited, will be considered a criminal >>>> offense, so you must reply to the original sender to inform about this >>>> communication and delete it. >>>> >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: < >>>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/b6777fa7/attachment.html >>>> > >>>> >>>> ------------------------------ >>>> >>>> Subject: Digest Footer >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>>> >>>> ------------------------------ >>>> >>>> End of RPD Digest, Vol 222, Issue 110 >>>> ************************************* >>>> >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: < >>>> https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e492c668/attachment.html >>>> > >>>> >>>> ------------------------------ >>>> >>>> Subject: Digest Footer >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>>> >>>> ------------------------------ >>>> >>>> End of RPD Digest, Vol 222, Issue 111 >>>> ************************************* >>>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Tue Jul 21 10:29:07 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Tue, 21 Jul 2026 12:29:07 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 119 In-Reply-To: References: Message-ID: Hi Fundiswa, Is not a matter of what is practical and what not. It is a matter that, during the discussion of the policy proposal (which is not the same as the Last Call), the community reached consensus on making it this way. RIRs follow the same procedures for reaching consensus as IETF, this has been said several times. The Last Call is a last opportunity to discover any weak point in a proposal that already reached consensus, and was OVERLOOKED before. Is not about discussing if the proposal should be a proposal or an operational decision. This is no longer the moment to discuss that (it should have done when the proposal was being discussed before reaching consensus), and many folks in this discussing are ignoring that, probably because they are not used to IETF procedures. Otherwise, you can remain silent during the proposal discussion, during the presentation in the PPM and object to it after reached consensus, which is an incorrect procedure. One more example: we could have asked AFRINIC many years ago to write the Soft Landing as an operational thing, instead we as a community, decided to make it a policy proposal. Same here. However, the community decided to do it as a proposal and it was accepted that way at the right time, not in the Last Call. By the way, I love cooking so from time to time follow some documentaries about that. Are you the same person as the famous chef? I think I saw you in a TV program some months ago or I?m confused. Regards, Jordi @jordipalet > El 21 jul 2026, a las 12:03, Fundiswa Nadia Maseko escribi?: > > Dear Jordi, > > Thank you for your response. > > I agree that AFRINIC is not required to follow the same approach as other RIRs. Every region should make decisions that suit its own community. > > My point, however, is slightly different. I wasn't suggesting that AFRINIC should copy another RIR simply because they did it that way. > > Rather, I'm asking what specific problem is solved by making this a policy instead of implementing it operationally. If both approaches achieve the same technical outcome, then what additional value does the policy itself provide? > > I think that's an important distinction. The fact that the community can choose policy doesn't necessarily mean policy is the most appropriate mechanism in every case. > > I'd be interested to hear what practical or technical benefit you believe is only possible through policy and not through an operational implementation. > > Kind regards, > > Fundiswa > > > > On Tue, 21 Jul 2026, 11:57 , > wrote: >> Send RPD mailing list submissions to >> rpd at afrinic.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.afrinic.net/mailman/listinfo/rpd >> or, via email, send a message with subject or body 'help' to >> rpd-request at afrinic.net >> >> You can reach the person managing the list at >> rpd-owner at afrinic.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of RPD digest..." >> >> >> Today's Topics: >> >> 1. Re: RPD Digest, Vol 222, Issue 111 (Nia Petronella) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 21 Jul 2026 11:56:49 +0200 >> From: Nia Petronella > >> To: Andrew Alston > >> Cc: rpd at afrinic.net >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 111 >> Message-ID: >> > >> Content-Type: text/plain; charset="utf-8" >> >> Dear Andrew, >> >> I do not accept the binary you have presented. >> >> No one is suggesting that AFRINIC should make operational changes in secret >> or without community input. An operational change can be published, >> consulted on, tested, documented, and reviewed. The real question is >> whether that input must be converted into binding policy enforced by the >> registry. >> >> Calling AFRINIC ?community-driven? does not answer who the community is or >> what it is authorised to bind. A self-selecting group of mailing-list >> participants can provide expertise, support, and objection. It does not >> automatically represent every member, resource holder, network, customer, >> or other affected party. >> >> The institutional reality also remains unchanged: participants discuss the >> policy, but AFRINIC interprets and enforces it. Community participation >> therefore does not eliminate registry power. It can become the language >> used to legitimise that power. >> >> This is why Kone?s examples matter. If LACNIC, RIPE NCC, and ARIN can >> achieve the same technical outcome through operational mechanisms, then >> policy is not technically inevitable. Proponents should explain what >> additional technical result binding policy provides, beyond converting an >> IRR setting into an enforceable obligation. >> >> I also disagree that an objection is valid only if it proves immediate >> operational harm or implementation failure. The choice of instrument, >> proportionality, reversibility, and expansion of enforcement authority are >> legitimate policy concerns. Last Call is not limited to asking whether >> software will break. It must also ask whether the proposed power is greater >> than the problem requires. >> >> Rough consensus does not require every objection to be accommodated. But an >> objection is not ?addressed? merely because supporters repeat that the >> community prefers policy. That is the very assumption being challenged. >> Procedure cannot be used to prove its own mandate. >> >> The fact that the RIR system has operated this way for decades demonstrates >> continuity of practice. It does not establish unlimited legitimacy of scope. >> >> I support Kone?s questions and remain opposed to AFPUB-2026-ASN-001-DRAFT02. >> >> Regards, >> Nonhlanhla >> >> >> >> On Tue, 21 Jul 2026, 10:26 am Andrew Alston > wrote: >> >> > The answer to this is simple. AfriNiC is a community driven organisation >> > - and anything done with regard to address allocation and management is >> > done as per policy provided by the community. It is through policy that >> > the community tells AfriNIC how to do things in regards to the allocation >> > and handling of resources. >> > >> > Without policy, the discretion and rules are entirely in the hands of the >> > registry, and the community voice is removed. >> > >> > This has been the way the RIR system has operated for decades and it >> > works. The community exercises its voice and its right as to how things >> > are done in relation to resource management through policy. >> > >> > Arguing that just because something can be done another way, is not in my >> > view a valid argument against policy. Objections to policy need to be >> > technically grounded and demonstrate that the policy would either cause >> > harm or alternatively be impractical to implement. Anything else is simply >> > arguing that policy should not exist because someone doesn?t like AfriNIC >> > being told how the community wants things done - and that isn?t an argument >> > that I believe rises to the level of a block on consensus. >> > >> > Please note - consensus does not require that the issue you raise have >> > been fixed, it requires that they have been addressed, and should the >> > community feel that despite the objections, the policy is something that >> > should proceed based on the fact that the questions have been addressed if >> > not necessarily accommodated, rough consensus still exists. >> > >> > Again, I support the policy and I see no technical or evidence/fact-based >> > arguments against said policy. >> > >> > Andrew >> > >> > On Tue, Jul 21, 2026 at 09:34, Nia Petronella < >> > nonhlanhlapetronella85 at gmail.com > wrote: >> > >> >> Dear PDWG, >> >> >> >> Kone is asking the right question. >> >> >> >> The issue is no longer whether hierarchical AS-SET naming is technically >> >> possible or useful. It already exists. The issue is why AFRINIC needs a >> >> binding policy to enforce what other RIRs largely treat as an operational >> >> IRR matter. >> >> >> >> That distinction matters. An operational change adjusts how a service is >> >> implemented. A policy creates an enforceable obligation and enlarges the >> >> registry?s authority. If the same technical result can be achieved through >> >> a community-reviewed implementation plan, then policy is not the minimum >> >> necessary instrument. >> >> >> >> Saying that ?the community prefers policy? is not enough. Participation >> >> may guide technical work, but it does not turn every preference into a >> >> mandate. A mailing list is not a legislature, and the availability of the >> >> PDP should not make policy the default answer to every operational setting. >> >> >> >> This is how gatekeeping expands: the registry begins with a useful >> >> technical function, then policy converts that function into permission and >> >> enforcement. The recordkeeper gradually becomes the rule-maker. >> >> >> >> The proponents should therefore answer Kone directly: what technical >> >> outcome can mandatory policy achieve here that an operational >> >> implementation cannot? >> >> >> >> Until that is clearly demonstrated, I support Kone?s questions and remain >> >> opposed to the policy route. >> >> >> >> Regards, >> >> Nonhlanhla >> >> >> >> >> >> >> >> On Tue, 21 Jul 2026, 8:20 am > wrote: >> >> >> >>> Send RPD mailing list submissions to >> >>> rpd at afrinic.net >> >>> >> >>> To subscribe or unsubscribe via the World Wide Web, visit >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >>> or, via email, send a message with subject or body 'help' to >> >>> rpd-request at afrinic.net >> >>> >> >>> You can reach the person managing the list at >> >>> rpd-owner at afrinic.net >> >>> >> >>> When replying, please edit your Subject line so it is more specific >> >>> than "Re: Contents of RPD digest..." >> >>> >> >>> >> >>> Today's Topics: >> >>> >> >>> 1. Re: RPD Digest, Vol 222, Issue 110 (Tshepo Masuku) >> >>> >> >>> >> >>> ---------------------------------------------------------------------- >> >>> >> >>> Message: 1 >> >>> Date: Tue, 21 Jul 2026 06:19:05 +0000 >> >>> From: Tshepo Masuku > >> >>> To: "rpd at afrinic.net " > >> >>> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 110 >> >>> Message-ID: >> >>> < >> >>> VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com >> >>> > >> >>> >> >>> Content-Type: text/plain; charset="windows-1252" >> >>> >> >>> Dear All, >> >>> >> >>> Kone?s point is directly relevant. If LACNIC, RIPE NCC, and ARIN can >> >>> implement hierarchical AS-SET naming through operational mechanisms, then >> >>> proponents must explain why AFRINIC needs a binding policy to achieve the >> >>> same technical result. >> >>> >> >>> Saying that each RIR works differently does not answer that question. >> >>> Nor does saying that ?the community is on top of the RIR.? A community may >> >>> advise, object, and coordinate. It does not acquire unlimited authority to >> >>> convert every operational preference into policy. A mailing list is not a >> >>> legislature. >> >>> >> >>> If AFRINIC can solve this through an operational change, policy adds >> >>> governance where technical administration would be sufficient. Speed and >> >>> preference do not create mandate. >> >>> >> >>> Kone provided specific examples. Those should be answered with evidence, >> >>> not by questioning whether he has worked in every RIR for many years. >> >>> Experience is relevant, but it is not authority and it is not a substitute >> >>> for argument. >> >>> >> >>> The unanswered question remains: what technical necessity requires >> >>> policy rather than operational implementation? >> >>> >> >>> Until that is answered, Kone?s objection stands, and I support it. >> >>> >> >>> Regards, >> >>> Tshepo >> >>> >> >>> >> >>> ________________________________ >> >>> From: rpd-request at afrinic.net > >> >>> Sent: Monday, July 20, 2026 11:10:57 pm >> >>> To: rpd at afrinic.net > >> >>> Subject: RPD Digest, Vol 222, Issue 110 >> >>> >> >>> Send RPD mailing list submissions to >> >>> rpd at afrinic.net >> >>> >> >>> To subscribe or unsubscribe via the World Wide Web, visit >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >>> or, via email, send a message with subject or body 'help' to >> >>> rpd-request at afrinic.net >> >>> >> >>> You can reach the person managing the list at >> >>> rpd-owner at afrinic.net >> >>> >> >>> When replying, please edit your Subject line so it is more specific >> >>> than "Re: Contents of RPD digest..." >> >>> >> >>> >> >>> Today's Topics: >> >>> >> >>> 1. Re: Writing tools (Ben Roberts - AfriNIC) >> >>> 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >> >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Kone) >> >>> 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >> >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> >>> (jordi.palet at consulintel.es ) >> >>> >> >>> >> >>> ---------------------------------------------------------------------- >> >>> >> >>> Message: 1 >> >>> Date: Mon, 20 Jul 2026 21:26:40 +0200 >> >>> From: Ben Roberts - AfriNIC > >> >>> To: Nonjabulo Sphilile > >> >>> Cc: rpd at afrinic.net >> >>> Subject: Re: [rpd] Writing tools >> >>> Message-ID: <09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net > >> >>> Content-Type: text/plain; charset="us-ascii" >> >>> >> >>> An HTML attachment was scrubbed... >> >>> URL: < >> >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/33c3ac9e/attachment-0001.html >> >>> > >> >>> >> >>> ------------------------------ >> >>> >> >>> Message: 2 >> >>> Date: Mon, 20 Jul 2026 20:34:20 +0000 >> >>> From: Kone > >> >>> To: Seun Ojedeji > >> >>> Cc: rpd > >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >> >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> >>> Message-ID: >> >>> > >>> 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com > >> >>> Content-Type: text/plain; charset="utf-8" >> >>> >> >>> Hello Seun, >> >>> You may have misread my earlier mail. I clearly stated that LACNIC, RIPE >> >>> NCC, and ARIN do not require policy to enforce hierarchical AS?SET >> >>> naming. >> >>> >> >>> To help close the ongoing discussions, I believe addressing the >> >>> questions I >> >>> raised would bring clarity: >> >>> * LACNIC enforces hierarchical AS?SET naming operationally, as part of >> >>> their IRR design from inception. >> >>> * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) >> >>> process, not through policy. >> >>> * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR >> >>> operational matters, again without policy. >> >>> >> >>> >> >>> These examples show that other RIRs (except APNIC) treat AS?SET naming as >> >>> an operational IRR matter, not a policy obligation. >> >>> >> >>> This is why I asked whether AFRINIC could address this operationally >> >>> rather >> >>> than through policy, and why Last Call discussions would benefit from >> >>> clear >> >>> answers to these points. >> >>> >> >>> Thanks. >> >>> --- >> >>> Kone >> >>> >> >>> >> >>> >> >>> Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji > a >> >>> ?crit : >> >>> >> >>> > Hello Bakenon, >> >>> > >> >>> > Do refer to the proposal as it references URL to other RIR's policies >> >>> for >> >>> > thiis: >> >>> > >> >>> > https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >>> > >> >>> > Regards >> >>> > >> >>> > ---- >> >>> > Sent from my mobile >> >>> > kindly excuse typos >> >>> > >> >>> > On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, > >> >>> > wrote: >> >>> > >> >>> >> Dear PDWG, >> >>> >> >> >>> >> I have been following the discussions on the hierarchical AS?SET >> >>> naming >> >>> >> scheme and would like clarification on a few points: >> >>> >> >> >>> >> 1. Could this matter be addressed operationally, as is done in ARIN, >> >>> >> LACNIC, and RIPE NCC, without requiring policy changes? >> >>> >> >> >>> >> 2. If yes, why are we taking the policy route? Is it because AFRINIC >> >>> >> currently lacks a defined process for handling operational issues that >> >>> >> affect IRR services? >> >>> >> >> >>> >> 3. Given that the hierarchical naming scheme is already supported and >> >>> >> currently exists within the IRR, this proposal represents an >> >>> enforcement >> >>> >> change rather than the introduction of a new technical standard. Why >> >>> is a >> >>> >> formal policy required to change an operational enforcement setting, >> >>> rather >> >>> >> than a community-vetted technical implementation plan?" >> >>> >> >> >>> >> Thank you. >> >>> >> --- >> >>> >> Kone >> >>> >> >> >>> >> >> >>> >> >> >>> >> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal > a >> >>> >> ?crit : >> >>> >> >> >>> >>> Dear PDWG, >> >>> >>> >> >>> >>> >> >>> >>> The Policy Development Working Group (PDWG) Chairs have initiated a >> >>> Last >> >>> >>> Call for this proposal, following rough consensus at the AFRINIC-37 >> >>> Public >> >>> >>> Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June >> >>> 2026. >> >>> >>> >> >>> >>> * Proposal Name: Hierarchical Names for New AS-SETs >> >>> >>> >> >>> >>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >> >>> >>> >> >>> >>> * Proposal URL: >> >>> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >>> >>> >> >>> >>> Last Call closes on: July 31, 2026, at 23:59 UTC. >> >>> >>> >> >>> >>> >> >>> >>> 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. >> >>> >>> >> >>> >>> >> >>> >>> As always, we kindly request that all participants adhere to the >> >>> AFRINIC >> >>> >>> Code of Conduct to maintain a >> >>> respectful >> >>> >>> and professional environment on the mailing list. >> >>> >>> >> >>> >>> >> >>> >>> Kind regards, >> >>> >>> >> >>> >>> >> >>> >>> Haitham el Nakhal >> >>> >>> >> >>> >>> AFRINIC PDWG Co-Chair >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> _______________________________________________ >> >>> >>> RPD mailing list >> >>> >>> RPD at afrinic.net >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >>> >>> >> >>> >> _______________________________________________ >> >>> >> RPD mailing list >> >>> >> RPD at afrinic.net >> >>> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >>> >> >> >>> > >> >>> -------------- next part -------------- >> >>> An HTML attachment was scrubbed... >> >>> URL: < >> >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/4563e1d5/attachment-0001.html >> >>> > >> >>> >> >>> ------------------------------ >> >>> >> >>> Message: 3 >> >>> Date: Mon, 20 Jul 2026 23:10:04 +0200 >> >>> From: "jordi.palet at consulintel.es " > >> >>> To: rpd > >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >> >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> >>> Message-ID: > >> >>> Content-Type: text/plain; charset="utf-8" >> >>> >> >>> Hi Kone, >> >>> >> >>> And what is the relevance of that? >> >>> >> >>> If you have a good understanding about all the RIRs, you will know that >> >>> each RIR has their own ways to do things. In many senses they act very >> >>> similarly and in general we end up with very similarly policies, but not >> >>> always. Some RIRs have decided that some aspects are operational and don?t >> >>> need a policy proposal. >> >>> >> >>> However, despite that, the community is on top of the RIR, and the >> >>> community sometimes, may decide that they prefer a policy if the RIR hasn?t >> >>> been proactive in advance in any specific topic, or even if the RIR was >> >>> proactive, the community may prefer to speed up things, or to show the way >> >>> the community prefers. >> >>> >> >>> For example, if AFRINIC has any specific operational aspect already in >> >>> place, and the community prefer to manage that in a different way, the >> >>> community may opt either for suggesting the RIR to modify that operational >> >>> aspect or to do actually enforce it by means of a policy proposal. >> >>> >> >>> I think is important to know, by personal experience, how the other 4 >> >>> RIRs work before stating something that is not correct, because if you >> >>> don?t work in all the RIRs for many years, it will be difficult for you to >> >>> know the past and I?m sure IA will not be able to be precise as well. >> >>> >> >>> Regards, >> >>> Jordi >> >>> >> >>> @jordipalet >> >>> >> >>> > El 20 jul 2026, a las 22:34, Kone > escribi?: >> >>> > >> >>> > Hello Seun, >> >>> > You may have misread my earlier mail. I clearly stated that LACNIC, >> >>> RIPE NCC, and ARIN do not require policy to enforce hierarchical AS?SET >> >>> naming. >> >>> > >> >>> > To help close the ongoing discussions, I believe addressing the >> >>> questions I raised would bring clarity: >> >>> > * LACNIC enforces hierarchical AS?SET naming operationally, as part of >> >>> their IRR design from inception. >> >>> > * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) >> >>> process, not through policy. >> >>> > * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR >> >>> operational matters, again without policy. >> >>> > >> >>> > >> >>> > These examples show that other RIRs (except APNIC) treat AS?SET naming >> >>> as an operational IRR matter, not a policy obligation. >> >>> > >> >>> > This is why I asked whether AFRINIC could address this operationally >> >>> rather than through policy, and why Last Call discussions would benefit >> >>> from clear answers to these points. >> >>> > >> >>> > Thanks. >> >>> > --- >> >>> > Kone >> >>> > >> >>> > >> >>> > >> >>> > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji >> >>> >> a ?crit : >> >>> >> Hello Bakenon, >> >>> >> >> >>> >> Do refer to the proposal as it references URL to other RIR's policies >> >>> for thiis: >> >>> >> >> >>> >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >>> >> >> >>> >> Regards >> >>> >> >> >>> >> ---- >> >>> >> Sent from my mobile >> >>> >> kindly excuse typos >> >>> >> >> >>> >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, >> >>> >> wrote: >> >>> >>> Dear PDWG, >> >>> >>> >> >>> >>> I have been following the discussions on the hierarchical AS?SET >> >>> naming scheme and would like clarification on a few points: >> >>> >>> >> >>> >>> 1. Could this matter be addressed operationally, as is done in ARIN, >> >>> LACNIC, and RIPE NCC, without requiring policy changes? >> >>> >>> >> >>> >>> 2. If yes, why are we taking the policy route? Is it because AFRINIC >> >>> currently lacks a defined process for handling operational issues that >> >>> affect IRR services? >> >>> >>> >> >>> >>> 3. Given that the hierarchical naming scheme is already supported >> >>> and currently exists within the IRR, this proposal represents an >> >>> enforcement change rather than the introduction of a new technical >> >>> standard. Why is a formal policy required to change an operational >> >>> enforcement setting, rather than a community-vetted technical >> >>> implementation plan?" >> >>> >>> >> >>> >>> Thank you. >> >>> >>> --- >> >>> >>> Kone >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal >> >>> >> a ?crit : >> >>> >>>> Dear PDWG, >> >>> >>>> >> >>> >>>> >> >>> >>>> The Policy Development Working Group (PDWG) Chairs have initiated a >> >>> Last Call for this proposal, following rough consensus at the AFRINIC-37 >> >>> Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June >> >>> 2026. >> >>> >>>> >> >>> >>>> * Proposal Name: Hierarchical Names for New AS-SETs >> >>> >>>> >> >>> >>>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >> >>> >>>> >> >>> >>>> * Proposal URL: >> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >>> >>>> >> >>> >>>> Last Call closes on: July 31, 2026, at 23:59 UTC. >> >>> >>>> >> >>> >>>> >> >>> >>>> 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. >> >>> >>>> >> >>> >>>> >> >>> >>>> As always, we kindly request that all participants adhere to the >> >>> AFRINIC Code of Conduct to maintain a >> >>> respectful and professional environment on the mailing list. >> >>> >>>> >> >>> >>>> >> >>> >>>> Kind regards, >> >>> >>>> >> >>> >>>> >> >>> >>>> Haitham el Nakhal >> >>> >>>> >> >>> >>>> AFRINIC PDWG Co-Chair >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> _______________________________________________ >> >>> >>>> RPD mailing list >> >>> >>>> RPD at afrinic.net > >> >>> >>>> https://lists.afrinic.net/mailman/listinfo/rpd >> >>> >>> _______________________________________________ >> >>> >>> RPD mailing list >> >>> >>> RPD at afrinic.net > >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >>> > _______________________________________________ >> >>> > RPD mailing list >> >>> > RPD at afrinic.net >> >>> > https://lists.afrinic.net/mailman/listinfo/rpd >> >>> >> >>> >> >>> >> >>> ********************************************** >> >>> IPv4 is over >> >>> Are you ready for the new Internet ? >> >>> http://www.theipv6company.com >> >>> The IPv6 Company >> >>> >> >>> This electronic message contains information which may be privileged or >> >>> confidential. The information is intended to be for the exclusive use of >> >>> the individual(s) named above and further non-explicilty authorized >> >>> disclosure, copying, distribution or use of the contents of this >> >>> information, even if partially, including attached files, is strictly >> >>> prohibited and will be considered a criminal offense. If you are not the >> >>> intended recipient be aware that any disclosure, copying, distribution or >> >>> use of the contents of this information, even if partially, including >> >>> attached files, is strictly prohibited, will be considered a criminal >> >>> offense, so you must reply to the original sender to inform about this >> >>> communication and delete it. >> >>> >> >>> -------------- next part -------------- >> >>> An HTML attachment was scrubbed... >> >>> URL: < >> >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/b6777fa7/attachment.html >> >>> > >> >>> >> >>> ------------------------------ >> >>> >> >>> Subject: Digest Footer >> >>> >> >>> _______________________________________________ >> >>> RPD mailing list >> >>> RPD at afrinic.net >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >>> >> >>> >> >>> ------------------------------ >> >>> >> >>> End of RPD Digest, Vol 222, Issue 110 >> >>> ************************************* >> >>> >> >>> -------------- next part -------------- >> >>> An HTML attachment was scrubbed... >> >>> URL: < >> >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e492c668/attachment.html >> >>> > >> >>> >> >>> ------------------------------ >> >>> >> >>> Subject: Digest Footer >> >>> >> >>> _______________________________________________ >> >>> RPD mailing list >> >>> RPD at afrinic.net >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >>> >> >>> >> >>> ------------------------------ >> >>> >> >>> End of RPD Digest, Vol 222, Issue 111 >> >>> ************************************* >> >>> >> >> _______________________________________________ >> >> RPD mailing list >> >> RPD at afrinic.net >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ------------------------------ >> >> End of RPD Digest, Vol 222, Issue 119 >> ************************************* > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Tue Jul 21 10:46:12 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Tue, 21 Jul 2026 12:46:12 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 122 In-Reply-To: References: Message-ID: Dear Jordi, Thank you for your clarification. I understand your point that the proposal has already reached consensus and that Last Call is intended to identify any weaknesses that may have been overlooked. My concern is precisely that if the choice of mechanism was not sufficiently examined during the earlier discussions, then it remains a valid point to raise during Last Call. If a proposal introduces policy where an operational approach could achieve the same objective, that affects whether policy is the appropriate solution in the first place. I appreciate that consensus was declared, but consensus does not prevent the community from identifying a concern that may not have received enough attention. Last Call exists to give the community one final opportunity to do exactly that. Kind regards, Fundiswa On Tue, 21 Jul 2026, 12:30 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: RPD Digest, Vol 222, Issue 119 (jordi.palet at consulintel.es) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2026 12:29:07 +0200 > From: "jordi.palet at consulintel.es" > To: rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 119 > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Hi Fundiswa, > > Is not a matter of what is practical and what not. > > It is a matter that, during the discussion of the policy proposal (which > is not the same as the Last Call), the community reached consensus on > making it this way. RIRs follow the same procedures for reaching consensus > as IETF, this has been said several times. The Last Call is a last > opportunity to discover any weak point in a proposal that already reached > consensus, and was OVERLOOKED before. Is not about discussing if the > proposal should be a proposal or an operational decision. This is no longer > the moment to discuss that (it should have done when the proposal was being > discussed before reaching consensus), and many folks in this discussing are > ignoring that, probably because they are not used to IETF procedures. > > Otherwise, you can remain silent during the proposal discussion, during > the presentation in the PPM and object to it after reached consensus, which > is an incorrect procedure. > > One more example: we could have asked AFRINIC many years ago to write the > Soft Landing as an operational thing, instead we as a community, decided to > make it a policy proposal. Same here. However, the community decided to do > it as a proposal and it was accepted that way at the right time, not in the > Last Call. > > By the way, I love cooking so from time to time follow some documentaries > about that. Are you the same person as the famous chef? I think I saw you > in a TV program some months ago or I?m confused. > > Regards, > Jordi > > @jordipalet > > > El 21 jul 2026, a las 12:03, Fundiswa Nadia Maseko < > fundiswanadia2 at gmail.com> escribi?: > > > > Dear Jordi, > > > > Thank you for your response. > > > > I agree that AFRINIC is not required to follow the same approach as > other RIRs. Every region should make decisions that suit its own community. > > > > My point, however, is slightly different. I wasn't suggesting that > AFRINIC should copy another RIR simply because they did it that way. > > > > Rather, I'm asking what specific problem is solved by making this a > policy instead of implementing it operationally. If both approaches achieve > the same technical outcome, then what additional value does the policy > itself provide? > > > > I think that's an important distinction. The fact that the community can > choose policy doesn't necessarily mean policy is the most appropriate > mechanism in every case. > > > > I'd be interested to hear what practical or technical benefit you > believe is only possible through policy and not through an operational > implementation. > > > > Kind regards, > > > > Fundiswa > > > > > > > > On Tue, 21 Jul 2026, 11:57 , rpd-request at afrinic.net>> wrote: > >> Send RPD mailing list submissions to > >> rpd at afrinic.net > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> or, via email, send a message with subject or body 'help' to > >> rpd-request at afrinic.net > >> > >> You can reach the person managing the list at > >> rpd-owner at afrinic.net > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of RPD digest..." > >> > >> > >> Today's Topics: > >> > >> 1. Re: RPD Digest, Vol 222, Issue 111 (Nia Petronella) > >> > >> > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Tue, 21 Jul 2026 11:56:49 +0200 > >> From: Nia Petronella nonhlanhlapetronella85 at gmail.com>> > >> To: Andrew Alston >> > >> Cc: rpd at afrinic.net > >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 111 > >> Message-ID: > >> itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com>> > >> Content-Type: text/plain; charset="utf-8" > >> > >> Dear Andrew, > >> > >> I do not accept the binary you have presented. > >> > >> No one is suggesting that AFRINIC should make operational changes in > secret > >> or without community input. An operational change can be published, > >> consulted on, tested, documented, and reviewed. The real question is > >> whether that input must be converted into binding policy enforced by the > >> registry. > >> > >> Calling AFRINIC ?community-driven? does not answer who the community is > or > >> what it is authorised to bind. A self-selecting group of mailing-list > >> participants can provide expertise, support, and objection. It does not > >> automatically represent every member, resource holder, network, > customer, > >> or other affected party. > >> > >> The institutional reality also remains unchanged: participants discuss > the > >> policy, but AFRINIC interprets and enforces it. Community participation > >> therefore does not eliminate registry power. It can become the language > >> used to legitimise that power. > >> > >> This is why Kone?s examples matter. If LACNIC, RIPE NCC, and ARIN can > >> achieve the same technical outcome through operational mechanisms, then > >> policy is not technically inevitable. Proponents should explain what > >> additional technical result binding policy provides, beyond converting > an > >> IRR setting into an enforceable obligation. > >> > >> I also disagree that an objection is valid only if it proves immediate > >> operational harm or implementation failure. The choice of instrument, > >> proportionality, reversibility, and expansion of enforcement authority > are > >> legitimate policy concerns. Last Call is not limited to asking whether > >> software will break. It must also ask whether the proposed power is > greater > >> than the problem requires. > >> > >> Rough consensus does not require every objection to be accommodated. > But an > >> objection is not ?addressed? merely because supporters repeat that the > >> community prefers policy. That is the very assumption being challenged. > >> Procedure cannot be used to prove its own mandate. > >> > >> The fact that the RIR system has operated this way for decades > demonstrates > >> continuity of practice. It does not establish unlimited legitimacy of > scope. > >> > >> I support Kone?s questions and remain opposed to > AFPUB-2026-ASN-001-DRAFT02. > >> > >> Regards, > >> Nonhlanhla > >> > >> > >> > >> On Tue, 21 Jul 2026, 10:26 am Andrew Alston > wrote: > >> > >> > The answer to this is simple. AfriNiC is a community driven > organisation > >> > - and anything done with regard to address allocation and management > is > >> > done as per policy provided by the community. It is through policy > that > >> > the community tells AfriNIC how to do things in regards to the > allocation > >> > and handling of resources. > >> > > >> > Without policy, the discretion and rules are entirely in the hands of > the > >> > registry, and the community voice is removed. > >> > > >> > This has been the way the RIR system has operated for decades and it > >> > works. The community exercises its voice and its right as to how > things > >> > are done in relation to resource management through policy. > >> > > >> > Arguing that just because something can be done another way, is not > in my > >> > view a valid argument against policy. Objections to policy need to be > >> > technically grounded and demonstrate that the policy would either > cause > >> > harm or alternatively be impractical to implement. Anything else is > simply > >> > arguing that policy should not exist because someone doesn?t like > AfriNIC > >> > being told how the community wants things done - and that isn?t an > argument > >> > that I believe rises to the level of a block on consensus. > >> > > >> > Please note - consensus does not require that the issue you raise have > >> > been fixed, it requires that they have been addressed, and should the > >> > community feel that despite the objections, the policy is something > that > >> > should proceed based on the fact that the questions have been > addressed if > >> > not necessarily accommodated, rough consensus still exists. > >> > > >> > Again, I support the policy and I see no technical or > evidence/fact-based > >> > arguments against said policy. > >> > > >> > Andrew > >> > > >> > On Tue, Jul 21, 2026 at 09:34, Nia Petronella < > >> > nonhlanhlapetronella85 at gmail.com nonhlanhlapetronella85 at gmail.com>> wrote: > >> > > >> >> Dear PDWG, > >> >> > >> >> Kone is asking the right question. > >> >> > >> >> The issue is no longer whether hierarchical AS-SET naming is > technically > >> >> possible or useful. It already exists. The issue is why AFRINIC > needs a > >> >> binding policy to enforce what other RIRs largely treat as an > operational > >> >> IRR matter. > >> >> > >> >> That distinction matters. An operational change adjusts how a > service is > >> >> implemented. A policy creates an enforceable obligation and enlarges > the > >> >> registry?s authority. If the same technical result can be achieved > through > >> >> a community-reviewed implementation plan, then policy is not the > minimum > >> >> necessary instrument. > >> >> > >> >> Saying that ?the community prefers policy? is not enough. > Participation > >> >> may guide technical work, but it does not turn every preference into > a > >> >> mandate. A mailing list is not a legislature, and the availability > of the > >> >> PDP should not make policy the default answer to every operational > setting. > >> >> > >> >> This is how gatekeeping expands: the registry begins with a useful > >> >> technical function, then policy converts that function into > permission and > >> >> enforcement. The recordkeeper gradually becomes the rule-maker. > >> >> > >> >> The proponents should therefore answer Kone directly: what technical > >> >> outcome can mandatory policy achieve here that an operational > >> >> implementation cannot? > >> >> > >> >> Until that is clearly demonstrated, I support Kone?s questions and > remain > >> >> opposed to the policy route. > >> >> > >> >> Regards, > >> >> Nonhlanhla > >> >> > >> >> > >> >> > >> >> On Tue, 21 Jul 2026, 8:20 am rpd-request at afrinic.net>> wrote: > >> >> > >> >>> Send RPD mailing list submissions to > >> >>> rpd at afrinic.net > >> >>> > >> >>> To subscribe or unsubscribe via the World Wide Web, visit > >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >>> or, via email, send a message with subject or body 'help' to > >> >>> rpd-request at afrinic.net > >> >>> > >> >>> You can reach the person managing the list at > >> >>> rpd-owner at afrinic.net > >> >>> > >> >>> When replying, please edit your Subject line so it is more specific > >> >>> than "Re: Contents of RPD digest..." > >> >>> > >> >>> > >> >>> Today's Topics: > >> >>> > >> >>> 1. Re: RPD Digest, Vol 222, Issue 110 (Tshepo Masuku) > >> >>> > >> >>> > >> >>> > ---------------------------------------------------------------------- > >> >>> > >> >>> Message: 1 > >> >>> Date: Tue, 21 Jul 2026 06:19:05 +0000 > >> >>> From: Tshepo Masuku TshepoMasuku26 at hotmail.com>> > >> >>> To: "rpd at afrinic.net " > > >> >>> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 110 > >> >>> Message-ID: > >> >>> < > >> >>> > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > > > >> >>> > > >> >>> > >> >>> Content-Type: text/plain; charset="windows-1252" > >> >>> > >> >>> Dear All, > >> >>> > >> >>> Kone?s point is directly relevant. If LACNIC, RIPE NCC, and ARIN can > >> >>> implement hierarchical AS-SET naming through operational > mechanisms, then > >> >>> proponents must explain why AFRINIC needs a binding policy to > achieve the > >> >>> same technical result. > >> >>> > >> >>> Saying that each RIR works differently does not answer that > question. > >> >>> Nor does saying that ?the community is on top of the RIR.? A > community may > >> >>> advise, object, and coordinate. It does not acquire unlimited > authority to > >> >>> convert every operational preference into policy. A mailing list is > not a > >> >>> legislature. > >> >>> > >> >>> If AFRINIC can solve this through an operational change, policy adds > >> >>> governance where technical administration would be sufficient. > Speed and > >> >>> preference do not create mandate. > >> >>> > >> >>> Kone provided specific examples. Those should be answered with > evidence, > >> >>> not by questioning whether he has worked in every RIR for many > years. > >> >>> Experience is relevant, but it is not authority and it is not a > substitute > >> >>> for argument. > >> >>> > >> >>> The unanswered question remains: what technical necessity requires > >> >>> policy rather than operational implementation? > >> >>> > >> >>> Until that is answered, Kone?s objection stands, and I support it. > >> >>> > >> >>> Regards, > >> >>> Tshepo > >> >>> > >> >>> > >> >>> ________________________________ > >> >>> From: rpd-request at afrinic.net < > rpd-request at afrinic.net > > >> >>> Sent: Monday, July 20, 2026 11:10:57 pm > >> >>> To: rpd at afrinic.net > > >> >>> Subject: RPD Digest, Vol 222, Issue 110 > >> >>> > >> >>> Send RPD mailing list submissions to > >> >>> rpd at afrinic.net > >> >>> > >> >>> To subscribe or unsubscribe via the World Wide Web, visit > >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >>> or, via email, send a message with subject or body 'help' to > >> >>> rpd-request at afrinic.net > >> >>> > >> >>> You can reach the person managing the list at > >> >>> rpd-owner at afrinic.net > >> >>> > >> >>> When replying, please edit your Subject line so it is more specific > >> >>> than "Re: Contents of RPD digest..." > >> >>> > >> >>> > >> >>> Today's Topics: > >> >>> > >> >>> 1. Re: Writing tools (Ben Roberts - AfriNIC) > >> >>> 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > >> >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Kone) > >> >>> 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > >> >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >> >>> (jordi.palet at consulintel.es jordi.palet at consulintel.es>) > >> >>> > >> >>> > >> >>> > ---------------------------------------------------------------------- > >> >>> > >> >>> Message: 1 > >> >>> Date: Mon, 20 Jul 2026 21:26:40 +0200 > >> >>> From: Ben Roberts - AfriNIC ben.roberts at afrinic.net>> > >> >>> To: Nonjabulo Sphilile nonjabulosphilile at gmail.com>> > >> >>> Cc: rpd at afrinic.net > >> >>> Subject: Re: [rpd] Writing tools > >> >>> Message-ID: <09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net > > > >> >>> Content-Type: text/plain; charset="us-ascii" > >> >>> > >> >>> An HTML attachment was scrubbed... > >> >>> URL: < > >> >>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/33c3ac9e/attachment-0001.html > >> >>> > > >> >>> > >> >>> ------------------------------ > >> >>> > >> >>> Message: 2 > >> >>> Date: Mon, 20 Jul 2026 20:34:20 +0000 > >> >>> From: Kone bakenon.kone at sancfis.net>> > >> >>> To: Seun Ojedeji seun.ojedeji at gmail.com>> > >> >>> Cc: rpd > > >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > >> >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >> >>> Message-ID: > >> >>> >> >>> 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com>> > >> >>> Content-Type: text/plain; charset="utf-8" > >> >>> > >> >>> Hello Seun, > >> >>> You may have misread my earlier mail. I clearly stated that LACNIC, > RIPE > >> >>> NCC, and ARIN do not require policy to enforce hierarchical AS?SET > >> >>> naming. > >> >>> > >> >>> To help close the ongoing discussions, I believe addressing the > >> >>> questions I > >> >>> raised would bring clarity: > >> >>> * LACNIC enforces hierarchical AS?SET naming operationally, as part > of > >> >>> their IRR design from inception. > >> >>> * RIPE NCC handles IRR changes through their Numbered Work Items > (NWI) > >> >>> process, not through policy. > >> >>> * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR > >> >>> operational matters, again without policy. > >> >>> > >> >>> > >> >>> These examples show that other RIRs (except APNIC) treat AS?SET > naming as > >> >>> an operational IRR matter, not a policy obligation. > >> >>> > >> >>> This is why I asked whether AFRINIC could address this operationally > >> >>> rather > >> >>> than through policy, and why Last Call discussions would benefit > from > >> >>> clear > >> >>> answers to these points. > >> >>> > >> >>> Thanks. > >> >>> --- > >> >>> Kone > >> >>> > >> >>> > >> >>> > >> >>> Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji > a > >> >>> ?crit : > >> >>> > >> >>> > Hello Bakenon, > >> >>> > > >> >>> > Do refer to the proposal as it references URL to other RIR's > policies > >> >>> for > >> >>> > thiis: > >> >>> > > >> >>> > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >> >>> > > >> >>> > Regards > >> >>> > > >> >>> > ---- > >> >>> > Sent from my mobile > >> >>> > kindly excuse typos > >> >>> > > >> >>> > On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, < > bakenon.kone at sancfis.net > > >> >>> > wrote: > >> >>> > > >> >>> >> Dear PDWG, > >> >>> >> > >> >>> >> I have been following the discussions on the hierarchical AS?SET > >> >>> naming > >> >>> >> scheme and would like clarification on a few points: > >> >>> >> > >> >>> >> 1. Could this matter be addressed operationally, as is done in > ARIN, > >> >>> >> LACNIC, and RIPE NCC, without requiring policy changes? > >> >>> >> > >> >>> >> 2. If yes, why are we taking the policy route? Is it because > AFRINIC > >> >>> >> currently lacks a defined process for handling operational > issues that > >> >>> >> affect IRR services? > >> >>> >> > >> >>> >> 3. Given that the hierarchical naming scheme is already > supported and > >> >>> >> currently exists within the IRR, this proposal represents an > >> >>> enforcement > >> >>> >> change rather than the introduction of a new technical standard. > Why > >> >>> is a > >> >>> >> formal policy required to change an operational enforcement > setting, > >> >>> rather > >> >>> >> than a community-vetted technical implementation plan?" > >> >>> >> > >> >>> >> Thank you. > >> >>> >> --- > >> >>> >> Kone > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal < > hytham at tra.gov.eg > a > >> >>> >> ?crit : > >> >>> >> > >> >>> >>> Dear PDWG, > >> >>> >>> > >> >>> >>> > >> >>> >>> The Policy Development Working Group (PDWG) Chairs have > initiated a > >> >>> Last > >> >>> >>> Call for this proposal, following rough consensus at the > AFRINIC-37 > >> >>> Public > >> >>> >>> Policy Meeting held in hybrid format in Nairobi, Kenya on 24 > June > >> >>> 2026. > >> >>> >>> > >> >>> >>> * Proposal Name: Hierarchical Names for New AS-SETs > >> >>> >>> > >> >>> >>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > >> >>> >>> > >> >>> >>> * Proposal URL: > >> >>> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >> >>> >>> > >> >>> >>> Last Call closes on: July 31, 2026, at 23:59 UTC. > >> >>> >>> > >> >>> >>> > >> >>> >>> 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. > >> >>> >>> > >> >>> >>> > >> >>> >>> As always, we kindly request that all participants adhere to the > >> >>> AFRINIC > >> >>> >>> Code of Conduct to maintain a > >> >>> respectful > >> >>> >>> and professional environment on the mailing list. > >> >>> >>> > >> >>> >>> > >> >>> >>> Kind regards, > >> >>> >>> > >> >>> >>> > >> >>> >>> Haitham el Nakhal > >> >>> >>> > >> >>> >>> AFRINIC PDWG Co-Chair > >> >>> >>> > >> >>> >>> > >> >>> >>> > >> >>> >>> _______________________________________________ > >> >>> >>> RPD mailing list > >> >>> >>> RPD at afrinic.net > >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >>> >>> > >> >>> >> _______________________________________________ > >> >>> >> RPD mailing list > >> >>> >> RPD at afrinic.net > >> >>> >> https://lists.afrinic.net/mailman/listinfo/rpd > >> >>> >> > >> >>> > > >> >>> -------------- next part -------------- > >> >>> An HTML attachment was scrubbed... > >> >>> URL: < > >> >>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/4563e1d5/attachment-0001.html > >> >>> > > >> >>> > >> >>> ------------------------------ > >> >>> > >> >>> Message: 3 > >> >>> Date: Mon, 20 Jul 2026 23:10:04 +0200 > >> >>> From: "jordi.palet at consulintel.es jordi.palet at consulintel.es>" jordi.palet at consulintel.es>> > >> >>> To: rpd > > >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > >> >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >> >>> Message-ID: > > >> >>> Content-Type: text/plain; charset="utf-8" > >> >>> > >> >>> Hi Kone, > >> >>> > >> >>> And what is the relevance of that? > >> >>> > >> >>> If you have a good understanding about all the RIRs, you will know > that > >> >>> each RIR has their own ways to do things. In many senses they act > very > >> >>> similarly and in general we end up with very similarly policies, > but not > >> >>> always. Some RIRs have decided that some aspects are operational > and don?t > >> >>> need a policy proposal. > >> >>> > >> >>> However, despite that, the community is on top of the RIR, and the > >> >>> community sometimes, may decide that they prefer a policy if the > RIR hasn?t > >> >>> been proactive in advance in any specific topic, or even if the RIR > was > >> >>> proactive, the community may prefer to speed up things, or to show > the way > >> >>> the community prefers. > >> >>> > >> >>> For example, if AFRINIC has any specific operational aspect already > in > >> >>> place, and the community prefer to manage that in a different way, > the > >> >>> community may opt either for suggesting the RIR to modify that > operational > >> >>> aspect or to do actually enforce it by means of a policy proposal. > >> >>> > >> >>> I think is important to know, by personal experience, how the other > 4 > >> >>> RIRs work before stating something that is not correct, because if > you > >> >>> don?t work in all the RIRs for many years, it will be difficult for > you to > >> >>> know the past and I?m sure IA will not be able to be precise as > well. > >> >>> > >> >>> Regards, > >> >>> Jordi > >> >>> > >> >>> @jordipalet > >> >>> > >> >>> > El 20 jul 2026, a las 22:34, Kone > escribi?: > >> >>> > > >> >>> > Hello Seun, > >> >>> > You may have misread my earlier mail. I clearly stated that > LACNIC, > >> >>> RIPE NCC, and ARIN do not require policy to enforce hierarchical > AS?SET > >> >>> naming. > >> >>> > > >> >>> > To help close the ongoing discussions, I believe addressing the > >> >>> questions I raised would bring clarity: > >> >>> > * LACNIC enforces hierarchical AS?SET naming operationally, as > part of > >> >>> their IRR design from inception. > >> >>> > * RIPE NCC handles IRR changes through their Numbered Work Items > (NWI) > >> >>> process, not through policy. > >> >>> > * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR > >> >>> operational matters, again without policy. > >> >>> > > >> >>> > > >> >>> > These examples show that other RIRs (except APNIC) treat AS?SET > naming > >> >>> as an operational IRR matter, not a policy obligation. > >> >>> > > >> >>> > This is why I asked whether AFRINIC could address this > operationally > >> >>> rather than through policy, and why Last Call discussions would > benefit > >> >>> from clear answers to these points. > >> >>> > > >> >>> > Thanks. > >> >>> > --- > >> >>> > Kone > >> >>> > > >> >>> > > >> >>> > > >> >>> > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji < > seun.ojedeji at gmail.com > >> >>> >> a > ?crit : > >> >>> >> Hello Bakenon, > >> >>> >> > >> >>> >> Do refer to the proposal as it references URL to other RIR's > policies > >> >>> for thiis: > >> >>> >> > >> >>> >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >> >>> >> > >> >>> >> Regards > >> >>> >> > >> >>> >> ---- > >> >>> >> Sent from my mobile > >> >>> >> kindly excuse typos > >> >>> >> > >> >>> >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, < > bakenon.kone at sancfis.net > >> >>> >> > wrote: > >> >>> >>> Dear PDWG, > >> >>> >>> > >> >>> >>> I have been following the discussions on the hierarchical AS?SET > >> >>> naming scheme and would like clarification on a few points: > >> >>> >>> > >> >>> >>> 1. Could this matter be addressed operationally, as is done in > ARIN, > >> >>> LACNIC, and RIPE NCC, without requiring policy changes? > >> >>> >>> > >> >>> >>> 2. If yes, why are we taking the policy route? Is it because > AFRINIC > >> >>> currently lacks a defined process for handling operational issues > that > >> >>> affect IRR services? > >> >>> >>> > >> >>> >>> 3. Given that the hierarchical naming scheme is already > supported > >> >>> and currently exists within the IRR, this proposal represents an > >> >>> enforcement change rather than the introduction of a new technical > >> >>> standard. Why is a formal policy required to change an operational > >> >>> enforcement setting, rather than a community-vetted technical > >> >>> implementation plan?" > >> >>> >>> > >> >>> >>> Thank you. > >> >>> >>> --- > >> >>> >>> Kone > >> >>> >>> > >> >>> >>> > >> >>> >>> > >> >>> >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal < > hytham at tra.gov.eg > >> >>> >> a ?crit : > >> >>> >>>> Dear PDWG, > >> >>> >>>> > >> >>> >>>> > >> >>> >>>> The Policy Development Working Group (PDWG) Chairs have > initiated a > >> >>> Last Call for this proposal, following rough consensus at the > AFRINIC-37 > >> >>> Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 > June > >> >>> 2026. > >> >>> >>>> > >> >>> >>>> * Proposal Name: Hierarchical Names for New AS-SETs > >> >>> >>>> > >> >>> >>>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > >> >>> >>>> > >> >>> >>>> * Proposal URL: > >> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >> >>> >>>> > >> >>> >>>> Last Call closes on: July 31, 2026, at 23:59 UTC. > >> >>> >>>> > >> >>> >>>> > >> >>> >>>> 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. > >> >>> >>>> > >> >>> >>>> > >> >>> >>>> As always, we kindly request that all participants adhere to > the > >> >>> AFRINIC Code of Conduct to maintain a > >> >>> respectful and professional environment on the mailing list. > >> >>> >>>> > >> >>> >>>> > >> >>> >>>> Kind regards, > >> >>> >>>> > >> >>> >>>> > >> >>> >>>> Haitham el Nakhal > >> >>> >>>> > >> >>> >>>> AFRINIC PDWG Co-Chair > >> >>> >>>> > >> >>> >>>> > >> >>> >>>> > >> >>> >>>> _______________________________________________ > >> >>> >>>> RPD mailing list > >> >>> >>>> RPD at afrinic.net RPD at afrinic.net > > >> >>> >>>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >>> >>> _______________________________________________ > >> >>> >>> RPD mailing list > >> >>> >>> RPD at afrinic.net RPD at afrinic.net > > >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >>> > _______________________________________________ > >> >>> > RPD mailing list > >> >>> > RPD at afrinic.net > >> >>> > https://lists.afrinic.net/mailman/listinfo/rpd > >> >>> > >> >>> > >> >>> > >> >>> ********************************************** > >> >>> IPv4 is over > >> >>> Are you ready for the new Internet ? > >> >>> http://www.theipv6company.com > >> >>> The IPv6 Company > >> >>> > >> >>> This electronic message contains information which may be > privileged or > >> >>> confidential. The information is intended to be for the exclusive > use of > >> >>> the individual(s) named above and further non-explicilty authorized > >> >>> disclosure, copying, distribution or use of the contents of this > >> >>> information, even if partially, including attached files, is > strictly > >> >>> prohibited and will be considered a criminal offense. If you are > not the > >> >>> intended recipient be aware that any disclosure, copying, > distribution or > >> >>> use of the contents of this information, even if partially, > including > >> >>> attached files, is strictly prohibited, will be considered a > criminal > >> >>> offense, so you must reply to the original sender to inform about > this > >> >>> communication and delete it. > >> >>> > >> >>> -------------- next part -------------- > >> >>> An HTML attachment was scrubbed... > >> >>> URL: < > >> >>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/b6777fa7/attachment.html > >> >>> > > >> >>> > >> >>> ------------------------------ > >> >>> > >> >>> Subject: Digest Footer > >> >>> > >> >>> _______________________________________________ > >> >>> RPD mailing list > >> >>> RPD at afrinic.net > >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >>> > >> >>> > >> >>> ------------------------------ > >> >>> > >> >>> End of RPD Digest, Vol 222, Issue 110 > >> >>> ************************************* > >> >>> > >> >>> -------------- next part -------------- > >> >>> An HTML attachment was scrubbed... > >> >>> URL: < > >> >>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e492c668/attachment.html > >> >>> > > >> >>> > >> >>> ------------------------------ > >> >>> > >> >>> Subject: Digest Footer > >> >>> > >> >>> _______________________________________________ > >> >>> RPD mailing list > >> >>> RPD at afrinic.net > >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >>> > >> >>> > >> >>> ------------------------------ > >> >>> > >> >>> End of RPD Digest, Vol 222, Issue 111 > >> >>> ************************************* > >> >>> > >> >> _______________________________________________ > >> >> RPD mailing list > >> >> RPD at afrinic.net > >> >> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> > >> > > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/9c41424a/attachment.html > > > >> > >> ------------------------------ > >> > >> Subject: Digest Footer > >> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> > >> > >> ------------------------------ > >> > >> End of RPD Digest, Vol 222, Issue 119 > >> ************************************* > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/0ba797a1/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 122 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Tue Jul 21 11:03:53 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Tue, 21 Jul 2026 13:03:53 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 122 In-Reply-To: References: Message-ID: <3071913E-7C72-49BC-BEDD-B7F26DE20A96@consulintel.es> Well ? that?s incorrect. Nobody in the community, neither the staff impact assessment, said that a policy is not needed and many folks already contested several times, that doing it by means of a policy is valid according to the bylaws and PDP and it has not been demonstrated by objections that following this path, with is the most regular one in AFRINIC, creates any harm or problem. So repeating the argument, by many folks, many times, doesn?t demonstrate ?per se" that it is a valid objection to revert the already reached consensus. Of course, this is a decision that need to be taken by PDP chairs, but this is my view point from an exclusive ?procedural? basis. Regards, Jordi @jordipalet > El 21 jul 2026, a las 12:46, Fundiswa Nadia Maseko escribi?: > > Dear Jordi, > > Thank you for your clarification. > > I understand your point that the proposal has already reached consensus and that Last Call is intended to identify any weaknesses that may have been overlooked. > > My concern is precisely that if the choice of mechanism was not sufficiently examined during the earlier discussions, then it remains a valid point to raise during Last Call. If a proposal introduces policy where an operational approach could achieve the same objective, that affects whether policy is the appropriate solution in the first place. > > I appreciate that consensus was declared, but consensus does not prevent the community from identifying a concern that may not have received enough attention. Last Call exists to give the community one final opportunity to do exactly that. > > > Kind regards, > > Fundiswa > > On Tue, 21 Jul 2026, 12:30 , > wrote: >> Send RPD mailing list submissions to >> rpd at afrinic.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.afrinic.net/mailman/listinfo/rpd >> or, via email, send a message with subject or body 'help' to >> rpd-request at afrinic.net >> >> You can reach the person managing the list at >> rpd-owner at afrinic.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of RPD digest..." >> >> >> Today's Topics: >> >> 1. Re: RPD Digest, Vol 222, Issue 119 (jordi.palet at consulintel.es ) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 21 Jul 2026 12:29:07 +0200 >> From: "jordi.palet at consulintel.es " > >> To: rpd at afrinic.net >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 119 >> Message-ID: > >> Content-Type: text/plain; charset="utf-8" >> >> Hi Fundiswa, >> >> Is not a matter of what is practical and what not. >> >> It is a matter that, during the discussion of the policy proposal (which is not the same as the Last Call), the community reached consensus on making it this way. RIRs follow the same procedures for reaching consensus as IETF, this has been said several times. The Last Call is a last opportunity to discover any weak point in a proposal that already reached consensus, and was OVERLOOKED before. Is not about discussing if the proposal should be a proposal or an operational decision. This is no longer the moment to discuss that (it should have done when the proposal was being discussed before reaching consensus), and many folks in this discussing are ignoring that, probably because they are not used to IETF procedures. >> >> Otherwise, you can remain silent during the proposal discussion, during the presentation in the PPM and object to it after reached consensus, which is an incorrect procedure. >> >> One more example: we could have asked AFRINIC many years ago to write the Soft Landing as an operational thing, instead we as a community, decided to make it a policy proposal. Same here. However, the community decided to do it as a proposal and it was accepted that way at the right time, not in the Last Call. >> >> By the way, I love cooking so from time to time follow some documentaries about that. Are you the same person as the famous chef? I think I saw you in a TV program some months ago or I?m confused. >> >> Regards, >> Jordi >> >> @jordipalet >> >> > El 21 jul 2026, a las 12:03, Fundiswa Nadia Maseko > escribi?: >> > >> > Dear Jordi, >> > >> > Thank you for your response. >> > >> > I agree that AFRINIC is not required to follow the same approach as other RIRs. Every region should make decisions that suit its own community. >> > >> > My point, however, is slightly different. I wasn't suggesting that AFRINIC should copy another RIR simply because they did it that way. >> > >> > Rather, I'm asking what specific problem is solved by making this a policy instead of implementing it operationally. If both approaches achieve the same technical outcome, then what additional value does the policy itself provide? >> > >> > I think that's an important distinction. The fact that the community can choose policy doesn't necessarily mean policy is the most appropriate mechanism in every case. >> > >> > I'd be interested to hear what practical or technical benefit you believe is only possible through policy and not through an operational implementation. >> > >> > Kind regards, >> > >> > Fundiswa >> > >> > >> > >> > On Tue, 21 Jul 2026, 11:57 , >> wrote: >> >> Send RPD mailing list submissions to >> >> rpd at afrinic.net > >> >> >> >> To subscribe or unsubscribe via the World Wide Web, visit >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> or, via email, send a message with subject or body 'help' to >> >> rpd-request at afrinic.net > >> >> >> >> You can reach the person managing the list at >> >> rpd-owner at afrinic.net > >> >> >> >> When replying, please edit your Subject line so it is more specific >> >> than "Re: Contents of RPD digest..." >> >> >> >> >> >> Today's Topics: >> >> >> >> 1. Re: RPD Digest, Vol 222, Issue 111 (Nia Petronella) >> >> >> >> >> >> ---------------------------------------------------------------------- >> >> >> >> Message: 1 >> >> Date: Tue, 21 Jul 2026 11:56:49 +0200 >> >> From: Nia Petronella >> >> >> To: Andrew Alston >> >> >> Cc: rpd at afrinic.net > >> >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 111 >> >> Message-ID: >> >> >> >> >> Content-Type: text/plain; charset="utf-8" >> >> >> >> Dear Andrew, >> >> >> >> I do not accept the binary you have presented. >> >> >> >> No one is suggesting that AFRINIC should make operational changes in secret >> >> or without community input. An operational change can be published, >> >> consulted on, tested, documented, and reviewed. The real question is >> >> whether that input must be converted into binding policy enforced by the >> >> registry. >> >> >> >> Calling AFRINIC ?community-driven? does not answer who the community is or >> >> what it is authorised to bind. A self-selecting group of mailing-list >> >> participants can provide expertise, support, and objection. It does not >> >> automatically represent every member, resource holder, network, customer, >> >> or other affected party. >> >> >> >> The institutional reality also remains unchanged: participants discuss the >> >> policy, but AFRINIC interprets and enforces it. Community participation >> >> therefore does not eliminate registry power. It can become the language >> >> used to legitimise that power. >> >> >> >> This is why Kone?s examples matter. If LACNIC, RIPE NCC, and ARIN can >> >> achieve the same technical outcome through operational mechanisms, then >> >> policy is not technically inevitable. Proponents should explain what >> >> additional technical result binding policy provides, beyond converting an >> >> IRR setting into an enforceable obligation. >> >> >> >> I also disagree that an objection is valid only if it proves immediate >> >> operational harm or implementation failure. The choice of instrument, >> >> proportionality, reversibility, and expansion of enforcement authority are >> >> legitimate policy concerns. Last Call is not limited to asking whether >> >> software will break. It must also ask whether the proposed power is greater >> >> than the problem requires. >> >> >> >> Rough consensus does not require every objection to be accommodated. But an >> >> objection is not ?addressed? merely because supporters repeat that the >> >> community prefers policy. That is the very assumption being challenged. >> >> Procedure cannot be used to prove its own mandate. >> >> >> >> The fact that the RIR system has operated this way for decades demonstrates >> >> continuity of practice. It does not establish unlimited legitimacy of scope. >> >> >> >> I support Kone?s questions and remain opposed to AFPUB-2026-ASN-001-DRAFT02. >> >> >> >> Regards, >> >> Nonhlanhla >> >> >> >> >> >> >> >> On Tue, 21 Jul 2026, 10:26 am Andrew Alston >> wrote: >> >> >> >> > The answer to this is simple. AfriNiC is a community driven organisation >> >> > - and anything done with regard to address allocation and management is >> >> > done as per policy provided by the community. It is through policy that >> >> > the community tells AfriNIC how to do things in regards to the allocation >> >> > and handling of resources. >> >> > >> >> > Without policy, the discretion and rules are entirely in the hands of the >> >> > registry, and the community voice is removed. >> >> > >> >> > This has been the way the RIR system has operated for decades and it >> >> > works. The community exercises its voice and its right as to how things >> >> > are done in relation to resource management through policy. >> >> > >> >> > Arguing that just because something can be done another way, is not in my >> >> > view a valid argument against policy. Objections to policy need to be >> >> > technically grounded and demonstrate that the policy would either cause >> >> > harm or alternatively be impractical to implement. Anything else is simply >> >> > arguing that policy should not exist because someone doesn?t like AfriNIC >> >> > being told how the community wants things done - and that isn?t an argument >> >> > that I believe rises to the level of a block on consensus. >> >> > >> >> > Please note - consensus does not require that the issue you raise have >> >> > been fixed, it requires that they have been addressed, and should the >> >> > community feel that despite the objections, the policy is something that >> >> > should proceed based on the fact that the questions have been addressed if >> >> > not necessarily accommodated, rough consensus still exists. >> >> > >> >> > Again, I support the policy and I see no technical or evidence/fact-based >> >> > arguments against said policy. >> >> > >> >> > Andrew >> >> > >> >> > On Tue, Jul 21, 2026 at 09:34, Nia Petronella < >> >> > nonhlanhlapetronella85 at gmail.com >> wrote: >> >> > >> >> >> Dear PDWG, >> >> >> >> >> >> Kone is asking the right question. >> >> >> >> >> >> The issue is no longer whether hierarchical AS-SET naming is technically >> >> >> possible or useful. It already exists. The issue is why AFRINIC needs a >> >> >> binding policy to enforce what other RIRs largely treat as an operational >> >> >> IRR matter. >> >> >> >> >> >> That distinction matters. An operational change adjusts how a service is >> >> >> implemented. A policy creates an enforceable obligation and enlarges the >> >> >> registry?s authority. If the same technical result can be achieved through >> >> >> a community-reviewed implementation plan, then policy is not the minimum >> >> >> necessary instrument. >> >> >> >> >> >> Saying that ?the community prefers policy? is not enough. Participation >> >> >> may guide technical work, but it does not turn every preference into a >> >> >> mandate. A mailing list is not a legislature, and the availability of the >> >> >> PDP should not make policy the default answer to every operational setting. >> >> >> >> >> >> This is how gatekeeping expands: the registry begins with a useful >> >> >> technical function, then policy converts that function into permission and >> >> >> enforcement. The recordkeeper gradually becomes the rule-maker. >> >> >> >> >> >> The proponents should therefore answer Kone directly: what technical >> >> >> outcome can mandatory policy achieve here that an operational >> >> >> implementation cannot? >> >> >> >> >> >> Until that is clearly demonstrated, I support Kone?s questions and remain >> >> >> opposed to the policy route. >> >> >> >> >> >> Regards, >> >> >> Nonhlanhla >> >> >> >> >> >> >> >> >> >> >> >> On Tue, 21 Jul 2026, 8:20 am >> wrote: >> >> >> >> >> >>> Send RPD mailing list submissions to >> >> >>> rpd at afrinic.net > >> >> >>> >> >> >>> To subscribe or unsubscribe via the World Wide Web, visit >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >>> or, via email, send a message with subject or body 'help' to >> >> >>> rpd-request at afrinic.net > >> >> >>> >> >> >>> You can reach the person managing the list at >> >> >>> rpd-owner at afrinic.net > >> >> >>> >> >> >>> When replying, please edit your Subject line so it is more specific >> >> >>> than "Re: Contents of RPD digest..." >> >> >>> >> >> >>> >> >> >>> Today's Topics: >> >> >>> >> >> >>> 1. Re: RPD Digest, Vol 222, Issue 110 (Tshepo Masuku) >> >> >>> >> >> >>> >> >> >>> ---------------------------------------------------------------------- >> >> >>> >> >> >>> Message: 1 >> >> >>> Date: Tue, 21 Jul 2026 06:19:05 +0000 >> >> >>> From: Tshepo Masuku >> >> >> >>> To: "rpd at afrinic.net >" >> >> >> >>> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 110 >> >> >>> Message-ID: >> >> >>> < >> >> >>> VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > >> >> >>> > >> >> >>> >> >> >>> Content-Type: text/plain; charset="windows-1252" >> >> >>> >> >> >>> Dear All, >> >> >>> >> >> >>> Kone?s point is directly relevant. If LACNIC, RIPE NCC, and ARIN can >> >> >>> implement hierarchical AS-SET naming through operational mechanisms, then >> >> >>> proponents must explain why AFRINIC needs a binding policy to achieve the >> >> >>> same technical result. >> >> >>> >> >> >>> Saying that each RIR works differently does not answer that question. >> >> >>> Nor does saying that ?the community is on top of the RIR.? A community may >> >> >>> advise, object, and coordinate. It does not acquire unlimited authority to >> >> >>> convert every operational preference into policy. A mailing list is not a >> >> >>> legislature. >> >> >>> >> >> >>> If AFRINIC can solve this through an operational change, policy adds >> >> >>> governance where technical administration would be sufficient. Speed and >> >> >>> preference do not create mandate. >> >> >>> >> >> >>> Kone provided specific examples. Those should be answered with evidence, >> >> >>> not by questioning whether he has worked in every RIR for many years. >> >> >>> Experience is relevant, but it is not authority and it is not a substitute >> >> >>> for argument. >> >> >>> >> >> >>> The unanswered question remains: what technical necessity requires >> >> >>> policy rather than operational implementation? >> >> >>> >> >> >>> Until that is answered, Kone?s objection stands, and I support it. >> >> >>> >> >> >>> Regards, >> >> >>> Tshepo >> >> >>> >> >> >>> >> >> >>> ________________________________ >> >> >>> From: rpd-request at afrinic.net > >> >> >> >>> Sent: Monday, July 20, 2026 11:10:57 pm >> >> >>> To: rpd at afrinic.net > >> >> >> >>> Subject: RPD Digest, Vol 222, Issue 110 >> >> >>> >> >> >>> Send RPD mailing list submissions to >> >> >>> rpd at afrinic.net > >> >> >>> >> >> >>> To subscribe or unsubscribe via the World Wide Web, visit >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >>> or, via email, send a message with subject or body 'help' to >> >> >>> rpd-request at afrinic.net > >> >> >>> >> >> >>> You can reach the person managing the list at >> >> >>> rpd-owner at afrinic.net > >> >> >>> >> >> >>> When replying, please edit your Subject line so it is more specific >> >> >>> than "Re: Contents of RPD digest..." >> >> >>> >> >> >>> >> >> >>> Today's Topics: >> >> >>> >> >> >>> 1. Re: Writing tools (Ben Roberts - AfriNIC) >> >> >>> 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >> >> >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Kone) >> >> >>> 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >> >> >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> >> >>> (jordi.palet at consulintel.es >) >> >> >>> >> >> >>> >> >> >>> ---------------------------------------------------------------------- >> >> >>> >> >> >>> Message: 1 >> >> >>> Date: Mon, 20 Jul 2026 21:26:40 +0200 >> >> >>> From: Ben Roberts - AfriNIC >> >> >> >>> To: Nonjabulo Sphilile >> >> >> >>> Cc: rpd at afrinic.net > >> >> >>> Subject: Re: [rpd] Writing tools >> >> >>> Message-ID: <09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net >> >> >> >>> Content-Type: text/plain; charset="us-ascii" >> >> >>> >> >> >>> An HTML attachment was scrubbed... >> >> >>> URL: < >> >> >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/33c3ac9e/attachment-0001.html >> >> >>> > >> >> >>> >> >> >>> ------------------------------ >> >> >>> >> >> >>> Message: 2 >> >> >>> Date: Mon, 20 Jul 2026 20:34:20 +0000 >> >> >>> From: Kone >> >> >> >>> To: Seun Ojedeji >> >> >> >>> Cc: rpd >> >> >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >> >> >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> >> >>> Message-ID: >> >> >>> > >> >>> 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com >> >> >> >>> Content-Type: text/plain; charset="utf-8" >> >> >>> >> >> >>> Hello Seun, >> >> >>> You may have misread my earlier mail. I clearly stated that LACNIC, RIPE >> >> >>> NCC, and ARIN do not require policy to enforce hierarchical AS?SET >> >> >>> naming. >> >> >>> >> >> >>> To help close the ongoing discussions, I believe addressing the >> >> >>> questions I >> >> >>> raised would bring clarity: >> >> >>> * LACNIC enforces hierarchical AS?SET naming operationally, as part of >> >> >>> their IRR design from inception. >> >> >>> * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) >> >> >>> process, not through policy. >> >> >>> * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR >> >> >>> operational matters, again without policy. >> >> >>> >> >> >>> >> >> >>> These examples show that other RIRs (except APNIC) treat AS?SET naming as >> >> >>> an operational IRR matter, not a policy obligation. >> >> >>> >> >> >>> This is why I asked whether AFRINIC could address this operationally >> >> >>> rather >> >> >>> than through policy, and why Last Call discussions would benefit from >> >> >>> clear >> >> >>> answers to these points. >> >> >>> >> >> >>> Thanks. >> >> >>> --- >> >> >>> Kone >> >> >>> >> >> >>> >> >> >>> >> >> >>> Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji >> a >> >> >>> ?crit : >> >> >>> >> >> >>> > Hello Bakenon, >> >> >>> > >> >> >>> > Do refer to the proposal as it references URL to other RIR's policies >> >> >>> for >> >> >>> > thiis: >> >> >>> > >> >> >>> > https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >> >>> > >> >> >>> > Regards >> >> >>> > >> >> >>> > ---- >> >> >>> > Sent from my mobile >> >> >>> > kindly excuse typos >> >> >>> > >> >> >>> > On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, >> >> >> >>> > wrote: >> >> >>> > >> >> >>> >> Dear PDWG, >> >> >>> >> >> >> >>> >> I have been following the discussions on the hierarchical AS?SET >> >> >>> naming >> >> >>> >> scheme and would like clarification on a few points: >> >> >>> >> >> >> >>> >> 1. Could this matter be addressed operationally, as is done in ARIN, >> >> >>> >> LACNIC, and RIPE NCC, without requiring policy changes? >> >> >>> >> >> >> >>> >> 2. If yes, why are we taking the policy route? Is it because AFRINIC >> >> >>> >> currently lacks a defined process for handling operational issues that >> >> >>> >> affect IRR services? >> >> >>> >> >> >> >>> >> 3. Given that the hierarchical naming scheme is already supported and >> >> >>> >> currently exists within the IRR, this proposal represents an >> >> >>> enforcement >> >> >>> >> change rather than the introduction of a new technical standard. Why >> >> >>> is a >> >> >>> >> formal policy required to change an operational enforcement setting, >> >> >>> rather >> >> >>> >> than a community-vetted technical implementation plan?" >> >> >>> >> >> >> >>> >> Thank you. >> >> >>> >> --- >> >> >>> >> Kone >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> >> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal >> a >> >> >>> >> ?crit : >> >> >>> >> >> >> >>> >>> Dear PDWG, >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> The Policy Development Working Group (PDWG) Chairs have initiated a >> >> >>> Last >> >> >>> >>> Call for this proposal, following rough consensus at the AFRINIC-37 >> >> >>> Public >> >> >>> >>> Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June >> >> >>> 2026. >> >> >>> >>> >> >> >>> >>> * Proposal Name: Hierarchical Names for New AS-SETs >> >> >>> >>> >> >> >>> >>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >> >> >>> >>> >> >> >>> >>> * Proposal URL: >> >> >>> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >> >>> >>> >> >> >>> >>> Last Call closes on: July 31, 2026, at 23:59 UTC. >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> 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. >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> As always, we kindly request that all participants adhere to the >> >> >>> AFRINIC >> >> >>> >>> Code of Conduct to maintain a >> >> >>> respectful >> >> >>> >>> and professional environment on the mailing list. >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> Kind regards, >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> Haitham el Nakhal >> >> >>> >>> >> >> >>> >>> AFRINIC PDWG Co-Chair >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> _______________________________________________ >> >> >>> >>> RPD mailing list >> >> >>> >>> RPD at afrinic.net > >> >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >>> >>> >> >> >>> >> _______________________________________________ >> >> >>> >> RPD mailing list >> >> >>> >> RPD at afrinic.net > >> >> >>> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >>> >> >> >> >>> > >> >> >>> -------------- next part -------------- >> >> >>> An HTML attachment was scrubbed... >> >> >>> URL: < >> >> >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/4563e1d5/attachment-0001.html >> >> >>> > >> >> >>> >> >> >>> ------------------------------ >> >> >>> >> >> >>> Message: 3 >> >> >>> Date: Mon, 20 Jul 2026 23:10:04 +0200 >> >> >>> From: "jordi.palet at consulintel.es >" >> >> >> >>> To: rpd >> >> >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >> >> >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> >> >>> Message-ID: >> >> >> >>> Content-Type: text/plain; charset="utf-8" >> >> >>> >> >> >>> Hi Kone, >> >> >>> >> >> >>> And what is the relevance of that? >> >> >>> >> >> >>> If you have a good understanding about all the RIRs, you will know that >> >> >>> each RIR has their own ways to do things. In many senses they act very >> >> >>> similarly and in general we end up with very similarly policies, but not >> >> >>> always. Some RIRs have decided that some aspects are operational and don?t >> >> >>> need a policy proposal. >> >> >>> >> >> >>> However, despite that, the community is on top of the RIR, and the >> >> >>> community sometimes, may decide that they prefer a policy if the RIR hasn?t >> >> >>> been proactive in advance in any specific topic, or even if the RIR was >> >> >>> proactive, the community may prefer to speed up things, or to show the way >> >> >>> the community prefers. >> >> >>> >> >> >>> For example, if AFRINIC has any specific operational aspect already in >> >> >>> place, and the community prefer to manage that in a different way, the >> >> >>> community may opt either for suggesting the RIR to modify that operational >> >> >>> aspect or to do actually enforce it by means of a policy proposal. >> >> >>> >> >> >>> I think is important to know, by personal experience, how the other 4 >> >> >>> RIRs work before stating something that is not correct, because if you >> >> >>> don?t work in all the RIRs for many years, it will be difficult for you to >> >> >>> know the past and I?m sure IA will not be able to be precise as well. >> >> >>> >> >> >>> Regards, >> >> >>> Jordi >> >> >>> >> >> >>> @jordipalet >> >> >>> >> >> >>> > El 20 jul 2026, a las 22:34, Kone >> escribi?: >> >> >>> > >> >> >>> > Hello Seun, >> >> >>> > You may have misread my earlier mail. I clearly stated that LACNIC, >> >> >>> RIPE NCC, and ARIN do not require policy to enforce hierarchical AS?SET >> >> >>> naming. >> >> >>> > >> >> >>> > To help close the ongoing discussions, I believe addressing the >> >> >>> questions I raised would bring clarity: >> >> >>> > * LACNIC enforces hierarchical AS?SET naming operationally, as part of >> >> >>> their IRR design from inception. >> >> >>> > * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) >> >> >>> process, not through policy. >> >> >>> > * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR >> >> >>> operational matters, again without policy. >> >> >>> > >> >> >>> > >> >> >>> > These examples show that other RIRs (except APNIC) treat AS?SET naming >> >> >>> as an operational IRR matter, not a policy obligation. >> >> >>> > >> >> >>> > This is why I asked whether AFRINIC could address this operationally >> >> >>> rather than through policy, and why Last Call discussions would benefit >> >> >>> from clear answers to these points. >> >> >>> > >> >> >>> > Thanks. >> >> >>> > --- >> >> >>> > Kone >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji > >> >> >>> >>> a ?crit : >> >> >>> >> Hello Bakenon, >> >> >>> >> >> >> >>> >> Do refer to the proposal as it references URL to other RIR's policies >> >> >>> for thiis: >> >> >>> >> >> >> >>> >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >> >>> >> >> >> >>> >> Regards >> >> >>> >> >> >> >>> >> ---- >> >> >>> >> Sent from my mobile >> >> >>> >> kindly excuse typos >> >> >>> >> >> >> >>> >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, > >> >> >>> >>> wrote: >> >> >>> >>> Dear PDWG, >> >> >>> >>> >> >> >>> >>> I have been following the discussions on the hierarchical AS?SET >> >> >>> naming scheme and would like clarification on a few points: >> >> >>> >>> >> >> >>> >>> 1. Could this matter be addressed operationally, as is done in ARIN, >> >> >>> LACNIC, and RIPE NCC, without requiring policy changes? >> >> >>> >>> >> >> >>> >>> 2. If yes, why are we taking the policy route? Is it because AFRINIC >> >> >>> currently lacks a defined process for handling operational issues that >> >> >>> affect IRR services? >> >> >>> >>> >> >> >>> >>> 3. Given that the hierarchical naming scheme is already supported >> >> >>> and currently exists within the IRR, this proposal represents an >> >> >>> enforcement change rather than the introduction of a new technical >> >> >>> standard. Why is a formal policy required to change an operational >> >> >>> enforcement setting, rather than a community-vetted technical >> >> >>> implementation plan?" >> >> >>> >>> >> >> >>> >>> Thank you. >> >> >>> >>> --- >> >> >>> >>> Kone >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal > >> >> >>> >>> a ?crit : >> >> >>> >>>> Dear PDWG, >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> The Policy Development Working Group (PDWG) Chairs have initiated a >> >> >>> Last Call for this proposal, following rough consensus at the AFRINIC-37 >> >> >>> Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June >> >> >>> 2026. >> >> >>> >>>> >> >> >>> >>>> * Proposal Name: Hierarchical Names for New AS-SETs >> >> >>> >>>> >> >> >>> >>>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >> >> >>> >>>> >> >> >>> >>>> * Proposal URL: >> >> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >> >>> >>>> >> >> >>> >>>> Last Call closes on: July 31, 2026, at 23:59 UTC. >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> 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. >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> As always, we kindly request that all participants adhere to the >> >> >>> AFRINIC Code of Conduct to maintain a >> >> >>> respectful and professional environment on the mailing list. >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> Kind regards, >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> Haitham el Nakhal >> >> >>> >>>> >> >> >>> >>>> AFRINIC PDWG Co-Chair >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> >> >> >>> >>>> _______________________________________________ >> >> >>> >>>> RPD mailing list >> >> >>> >>>> RPD at afrinic.net > >> >> >> >>> >>>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >>> >>> _______________________________________________ >> >> >>> >>> RPD mailing list >> >> >>> >>> RPD at afrinic.net > >> >> >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >>> > _______________________________________________ >> >> >>> > RPD mailing list >> >> >>> > RPD at afrinic.net > >> >> >>> > https://lists.afrinic.net/mailman/listinfo/rpd >> >> >>> >> >> >>> >> >> >>> >> >> >>> ********************************************** >> >> >>> IPv4 is over >> >> >>> Are you ready for the new Internet ? >> >> >>> http://www.theipv6company.com >> >> >>> The IPv6 Company >> >> >>> >> >> >>> This electronic message contains information which may be privileged or >> >> >>> confidential. The information is intended to be for the exclusive use of >> >> >>> the individual(s) named above and further non-explicilty authorized >> >> >>> disclosure, copying, distribution or use of the contents of this >> >> >>> information, even if partially, including attached files, is strictly >> >> >>> prohibited and will be considered a criminal offense. If you are not the >> >> >>> intended recipient be aware that any disclosure, copying, distribution or >> >> >>> use of the contents of this information, even if partially, including >> >> >>> attached files, is strictly prohibited, will be considered a criminal >> >> >>> offense, so you must reply to the original sender to inform about this >> >> >>> communication and delete it. >> >> >>> >> >> >>> -------------- next part -------------- >> >> >>> An HTML attachment was scrubbed... >> >> >>> URL: < >> >> >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/b6777fa7/attachment.html >> >> >>> > >> >> >>> >> >> >>> ------------------------------ >> >> >>> >> >> >>> Subject: Digest Footer >> >> >>> >> >> >>> _______________________________________________ >> >> >>> RPD mailing list >> >> >>> RPD at afrinic.net > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >>> >> >> >>> >> >> >>> ------------------------------ >> >> >>> >> >> >>> End of RPD Digest, Vol 222, Issue 110 >> >> >>> ************************************* >> >> >>> >> >> >>> -------------- next part -------------- >> >> >>> An HTML attachment was scrubbed... >> >> >>> URL: < >> >> >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e492c668/attachment.html >> >> >>> > >> >> >>> >> >> >>> ------------------------------ >> >> >>> >> >> >>> Subject: Digest Footer >> >> >>> >> >> >>> _______________________________________________ >> >> >>> RPD mailing list >> >> >>> RPD at afrinic.net > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >>> >> >> >>> >> >> >>> ------------------------------ >> >> >>> >> >> >>> End of RPD Digest, Vol 222, Issue 111 >> >> >>> ************************************* >> >> >>> >> >> >> _______________________________________________ >> >> >> RPD mailing list >> >> >> RPD at afrinic.net > >> >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> >> > >> >> -------------- next part -------------- >> >> An HTML attachment was scrubbed... >> >> URL: >> >> >> >> ------------------------------ >> >> >> >> Subject: Digest Footer >> >> >> >> _______________________________________________ >> >> RPD mailing list >> >> RPD at afrinic.net > >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> >> >> ------------------------------ >> >> >> >> End of RPD Digest, Vol 222, Issue 119 >> >> ************************************* >> > _______________________________________________ >> > RPD mailing list >> > RPD at afrinic.net >> > https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ------------------------------ >> >> End of RPD Digest, Vol 222, Issue 122 >> ************************************* > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gugudhlamini343 at gmail.com Tue Jul 21 11:08:12 2026 From: gugudhlamini343 at gmail.com (Gugu Dhlamini) Date: Tue, 21 Jul 2026 13:08:12 +0200 Subject: [rpd] Writing tools In-Reply-To: <1809710664.2684.1784623547091.JavaMail.zimbra@marwan.ma> References: <062601dd184f$72379070$56a6b150$@iptrading.com> <066b01dd185a$e13e9080$a3bbb180$@iptrading.com> <1809710664.2684.1784623547091.JavaMail.zimbra@marwan.ma> Message-ID: Hi Sami, The concern is not reasonable moderation. It is that AI use is being raised mainly against participants who oppose these policies, as though the tool makes their objections illegitimate. If anyone floods the list, moderate the flooding. Apply that rule equally, regardless of viewpoint or drafting method. A real participant using AI to translate, edit, or organise their own position is not grounds for exclusion. An open PDP cannot embrace technology for registry operations while condemning it when unfamiliar participants use it to speak. That would be gatekeeping, not consensus. Regards, Gugu On Tue, 21 Jul 2026, 10:48 am Sami Ait Ali Oulahcen via RPD wrote: > Hi all, > > It's been really difficult to follow the list this past 2/3 days. And I > imagine I'm not alone. > I fully agree on moderating the AI madness. Otherwise, it'll dissuade many > folks from following/participating. > > Regards, > Sami > > ----- Original Message ----- > From: "Mike Silber" > To: "rpd >> AfriNIC Resource Policy" > Sent: Monday, July 20, 2026 4:40:55 PM > Subject: Re: [rpd] Writing tools > > A useful discussion - thank you > > On Mon, Jul 20, 2026 at 5:17?PM Mike Burns via RPD > wrote: > > > Hi Rob, > > > > Yes, the language is a clear tell of AI usage, but flowery language > alone > > is not swamping the list. > > I don't want to hijack the AS-SET discussion, so thank you for the new > > subject line. > > > > Agreed > > > > > Now, sometimes and unfortunately, I can use vague and flowery language > > myself, so I would advise you to treat the AI stuff like the human stuff. > > Ignore it if it's too vague or flowery to serve as a good argument, and > > you have clearly laid out the two arguments in your last two lines. > > Hopefully the list will show judgement and treat clear and concise > > arguments better than vague ones. > > And then the AI posts, if they want to be successful, will avoid the > > purple prose. > > > > I think it goes beyond flowery language. > > I am concerned that this is a precedent for AI generated DDoS attacks on > the PDP and I do think we should have some light touch guidelines. I > suspect that one of the reasons for the AI-slop flood is not just to try > convince anyone of the value or legitimacy of their views but rather to > overwhelm and frustrate other participants and cause them to withdraw from > participation. > > Accordingly, I suggest we don't simply leave this to the co-chairs to > determine on a case by case basis, but rather set some guidelines under > which measures can be taken to avoid AI DDoS. > > Anyway - just my ZAR0,02 which is not worth much > > Regards > > Mike S > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Tue Jul 21 11:13:49 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Tue, 21 Jul 2026 13:13:49 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 111 In-Reply-To: References: Message-ID: Dear Andrew, Your reply clarifies where we disagree. I am not arguing that AFRINIC has no authority to adopt policy. I am arguing that the existence of authority does not prove that policy is the correct instrument in every case. Authority to act is not a requirement to act, and a bylaw cannot substitute for a necessity test. Even accepting your reading of Article 3.4, it defines AFRINIC?s corporate scope. It does not automatically turn every operational IRR setting into a policy matter. Nor does a vote by members prove that a self-selecting policy forum represents every network or party affected by the resulting enforcement. The concern is concrete: policy converts a technical setting that could be implemented, tested, reviewed, and revised operationally into a binding rule administered by AFRINIC. That adds rigidity, enforcement, and precedent. If other RIRs can achieve the same result through operational processes, proponents should explain what additional technical outcome AFRINIC gains by using policy. I also disagree that an objection is valid only if it proves immediate operational harm or implementation failure. Policy design must consider scope, proportionality, reversibility, and whether the least coercive mechanism is being used. A proposal may be technically implementable and still be unnecessary as binding policy. Your IETF comparison points toward restraint, not automatic deference to process. Rough consensus is disciplined by running code and operational reality. It does not mean that a proposal proceeds unless objectors prove catastrophe. Nor is an objection ?addressed? merely because supporters repeat that the bylaws permit policy. That does not answer why policy is necessary here. Finally, saying that ?the community has consistently agreed? cannot resolve a challenge about the limits of community mandate. Participation provides expertise, support, warning, and objection. It does not make mailing-list participants the legal principals of every affected operator. My objection is therefore not that I simply dislike AFRINIC having power. It is that the policy route has not been shown to be necessary for the technical result sought. Kone?s question about the choice of instrument remains unanswered. I remain opposed to AFPUB-2026-ASN-001-DRAFT02. Regards, Nonhlanhla On Tue, 21 Jul 2026, 12:20 pm Andrew Alston wrote: > Hi Nia, > > Ok, let me try and further expand on what I have said. > > Firstly - in a rough consensus approach - an objection carries weight when > it is factually backed up and proves a real problem. From what I can see, > your objection fails to meet this threshold. It is the objector's > obligation to substantiate objections to the point where they can be > answered and addressed. > > Now, looking at your objection, it seems to be that the policy expands > AfriNIC's mandate and grants them more power. I point out that AfriNIC's > mandate is clearly spelled out in article 3.4 of the bylaws as currently > written, which was amended by a supermajority vote of the members. > > In my opinion, you have yet to articulate the harm this policy creates or > explain how it falls outside the scope of the PDP or the AfriNIC mandate as > defined in its bylaws. While you may prefer AfriNIC to be simply a > database without policy restrictions, that is not what this community has > consistently agreed upon, nor is it what the bylaws voted on by the members > endorse. As such, I believe your position has been addressed by the mandate > given to AfriNIC under section 3.4 of the bylaws. > > During my tenure as an Area Director within the IETF, I often saw > disagreements on particular standards. It was always the objector's > responsibility to articulate the real problem, and then the working group > decided if that disagreement was sufficient to justify blocking the > proposal. > > From what I have seen - your objection seems to be "I don't like this > because it gives AfriNIC power of enforcement where such is unnecessary". > I disagree with this stance and believe that the policy committee has the > right to set policy as it sees fit, and you have not demonstrated any real > HARM from the policy. > > Thanks > > Andrew > > > > > On Tue, Jul 21, 2026 at 12:57?PM Nia Petronella < > nonhlanhlapetronella85 at gmail.com> wrote: > >> Dear Andrew, >> >> I do not accept the binary you have presented. >> >> No one is suggesting that AFRINIC should make operational changes in >> secret or without community input. An operational change can be published, >> consulted on, tested, documented, and reviewed. The real question is >> whether that input must be converted into binding policy enforced by the >> registry. >> >> Calling AFRINIC ?community-driven? does not answer who the community is >> or what it is authorised to bind. A self-selecting group of mailing-list >> participants can provide expertise, support, and objection. It does not >> automatically represent every member, resource holder, network, customer, >> or other affected party. >> >> The institutional reality also remains unchanged: participants discuss >> the policy, but AFRINIC interprets and enforces it. Community participation >> therefore does not eliminate registry power. It can become the language >> used to legitimise that power. >> >> This is why Kone?s examples matter. If LACNIC, RIPE NCC, and ARIN can >> achieve the same technical outcome through operational mechanisms, then >> policy is not technically inevitable. Proponents should explain what >> additional technical result binding policy provides, beyond converting an >> IRR setting into an enforceable obligation. >> >> I also disagree that an objection is valid only if it proves immediate >> operational harm or implementation failure. The choice of instrument, >> proportionality, reversibility, and expansion of enforcement authority are >> legitimate policy concerns. Last Call is not limited to asking whether >> software will break. It must also ask whether the proposed power is greater >> than the problem requires. >> >> Rough consensus does not require every objection to be accommodated. But >> an objection is not ?addressed? merely because supporters repeat that the >> community prefers policy. That is the very assumption being challenged. >> Procedure cannot be used to prove its own mandate. >> >> The fact that the RIR system has operated this way for decades >> demonstrates continuity of practice. It does not establish unlimited >> legitimacy of scope. >> >> I support Kone?s questions and remain opposed to >> AFPUB-2026-ASN-001-DRAFT02. >> >> Regards, >> Nonhlanhla >> >> >> >> On Tue, 21 Jul 2026, 10:26 am Andrew Alston >> wrote: >> >>> The answer to this is simple. AfriNiC is a community driven >>> organisation - and anything done with regard to address allocation and >>> management is done as per policy provided by the community. It is through >>> policy that the community tells AfriNIC how to do things in regards to the >>> allocation and handling of resources. >>> >>> Without policy, the discretion and rules are entirely in the hands of >>> the registry, and the community voice is removed. >>> >>> This has been the way the RIR system has operated for decades and it >>> works. The community exercises its voice and its right as to how things >>> are done in relation to resource management through policy. >>> >>> Arguing that just because something can be done another way, is not in >>> my view a valid argument against policy. Objections to policy need to be >>> technically grounded and demonstrate that the policy would either cause >>> harm or alternatively be impractical to implement. Anything else is simply >>> arguing that policy should not exist because someone doesn?t like AfriNIC >>> being told how the community wants things done - and that isn?t an argument >>> that I believe rises to the level of a block on consensus. >>> >>> Please note - consensus does not require that the issue you raise have >>> been fixed, it requires that they have been addressed, and should the >>> community feel that despite the objections, the policy is something that >>> should proceed based on the fact that the questions have been addressed if >>> not necessarily accommodated, rough consensus still exists. >>> >>> Again, I support the policy and I see no technical or >>> evidence/fact-based arguments against said policy. >>> >>> Andrew >>> >>> On Tue, Jul 21, 2026 at 09:34, Nia Petronella < >>> nonhlanhlapetronella85 at gmail.com> wrote: >>> >>>> Dear PDWG, >>>> >>>> Kone is asking the right question. >>>> >>>> The issue is no longer whether hierarchical AS-SET naming is >>>> technically possible or useful. It already exists. The issue is why AFRINIC >>>> needs a binding policy to enforce what other RIRs largely treat as an >>>> operational IRR matter. >>>> >>>> That distinction matters. An operational change adjusts how a service >>>> is implemented. A policy creates an enforceable obligation and enlarges the >>>> registry?s authority. If the same technical result can be achieved through >>>> a community-reviewed implementation plan, then policy is not the minimum >>>> necessary instrument. >>>> >>>> Saying that ?the community prefers policy? is not enough. Participation >>>> may guide technical work, but it does not turn every preference into a >>>> mandate. A mailing list is not a legislature, and the availability of the >>>> PDP should not make policy the default answer to every operational setting. >>>> >>>> This is how gatekeeping expands: the registry begins with a useful >>>> technical function, then policy converts that function into permission and >>>> enforcement. The recordkeeper gradually becomes the rule-maker. >>>> >>>> The proponents should therefore answer Kone directly: what technical >>>> outcome can mandatory policy achieve here that an operational >>>> implementation cannot? >>>> >>>> Until that is clearly demonstrated, I support Kone?s questions and >>>> remain opposed to the policy route. >>>> >>>> Regards, >>>> Nonhlanhla >>>> >>>> >>>> >>>> On Tue, 21 Jul 2026, 8:20 am wrote: >>>> >>>>> Send RPD mailing list submissions to >>>>> rpd at afrinic.net >>>>> >>>>> To subscribe or unsubscribe via the World Wide Web, visit >>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>> or, via email, send a message with subject or body 'help' to >>>>> rpd-request at afrinic.net >>>>> >>>>> You can reach the person managing the list at >>>>> rpd-owner at afrinic.net >>>>> >>>>> When replying, please edit your Subject line so it is more specific >>>>> than "Re: Contents of RPD digest..." >>>>> >>>>> >>>>> Today's Topics: >>>>> >>>>> 1. Re: RPD Digest, Vol 222, Issue 110 (Tshepo Masuku) >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> >>>>> Message: 1 >>>>> Date: Tue, 21 Jul 2026 06:19:05 +0000 >>>>> From: Tshepo Masuku >>>>> To: "rpd at afrinic.net" >>>>> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 110 >>>>> Message-ID: >>>>> < >>>>> VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com >>>>> > >>>>> >>>>> Content-Type: text/plain; charset="windows-1252" >>>>> >>>>> Dear All, >>>>> >>>>> Kone?s point is directly relevant. If LACNIC, RIPE NCC, and ARIN can >>>>> implement hierarchical AS-SET naming through operational mechanisms, then >>>>> proponents must explain why AFRINIC needs a binding policy to achieve the >>>>> same technical result. >>>>> >>>>> Saying that each RIR works differently does not answer that question. >>>>> Nor does saying that ?the community is on top of the RIR.? A community may >>>>> advise, object, and coordinate. It does not acquire unlimited authority to >>>>> convert every operational preference into policy. A mailing list is not a >>>>> legislature. >>>>> >>>>> If AFRINIC can solve this through an operational change, policy adds >>>>> governance where technical administration would be sufficient. Speed and >>>>> preference do not create mandate. >>>>> >>>>> Kone provided specific examples. Those should be answered with >>>>> evidence, not by questioning whether he has worked in every RIR for many >>>>> years. Experience is relevant, but it is not authority and it is not a >>>>> substitute for argument. >>>>> >>>>> The unanswered question remains: what technical necessity requires >>>>> policy rather than operational implementation? >>>>> >>>>> Until that is answered, Kone?s objection stands, and I support it. >>>>> >>>>> Regards, >>>>> Tshepo >>>>> >>>>> >>>>> ________________________________ >>>>> From: rpd-request at afrinic.net >>>>> Sent: Monday, July 20, 2026 11:10:57 pm >>>>> To: rpd at afrinic.net >>>>> Subject: RPD Digest, Vol 222, Issue 110 >>>>> >>>>> Send RPD mailing list submissions to >>>>> rpd at afrinic.net >>>>> >>>>> To subscribe or unsubscribe via the World Wide Web, visit >>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>> or, via email, send a message with subject or body 'help' to >>>>> rpd-request at afrinic.net >>>>> >>>>> You can reach the person managing the list at >>>>> rpd-owner at afrinic.net >>>>> >>>>> When replying, please edit your Subject line so it is more specific >>>>> than "Re: Contents of RPD digest..." >>>>> >>>>> >>>>> Today's Topics: >>>>> >>>>> 1. Re: Writing tools (Ben Roberts - AfriNIC) >>>>> 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >>>>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Kone) >>>>> 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >>>>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>>>> (jordi.palet at consulintel.es) >>>>> >>>>> >>>>> ---------------------------------------------------------------------- >>>>> >>>>> Message: 1 >>>>> Date: Mon, 20 Jul 2026 21:26:40 +0200 >>>>> From: Ben Roberts - AfriNIC >>>>> To: Nonjabulo Sphilile >>>>> Cc: rpd at afrinic.net >>>>> Subject: Re: [rpd] Writing tools >>>>> Message-ID: <09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net> >>>>> Content-Type: text/plain; charset="us-ascii" >>>>> >>>>> An HTML attachment was scrubbed... >>>>> URL: < >>>>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/33c3ac9e/attachment-0001.html >>>>> > >>>>> >>>>> ------------------------------ >>>>> >>>>> Message: 2 >>>>> Date: Mon, 20 Jul 2026 20:34:20 +0000 >>>>> From: Kone >>>>> To: Seun Ojedeji >>>>> Cc: rpd >>>>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >>>>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>>>> Message-ID: >>>>> >>>> 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com> >>>>> Content-Type: text/plain; charset="utf-8" >>>>> >>>>> Hello Seun, >>>>> You may have misread my earlier mail. I clearly stated that LACNIC, >>>>> RIPE >>>>> NCC, and ARIN do not require policy to enforce hierarchical AS?SET >>>>> naming. >>>>> >>>>> To help close the ongoing discussions, I believe addressing the >>>>> questions I >>>>> raised would bring clarity: >>>>> * LACNIC enforces hierarchical AS?SET naming operationally, as part of >>>>> their IRR design from inception. >>>>> * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) >>>>> process, not through policy. >>>>> * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR >>>>> operational matters, again without policy. >>>>> >>>>> >>>>> These examples show that other RIRs (except APNIC) treat AS?SET naming >>>>> as >>>>> an operational IRR matter, not a policy obligation. >>>>> >>>>> This is why I asked whether AFRINIC could address this operationally >>>>> rather >>>>> than through policy, and why Last Call discussions would benefit from >>>>> clear >>>>> answers to these points. >>>>> >>>>> Thanks. >>>>> --- >>>>> Kone >>>>> >>>>> >>>>> >>>>> Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji a >>>>> ?crit : >>>>> >>>>> > Hello Bakenon, >>>>> > >>>>> > Do refer to the proposal as it references URL to other RIR's >>>>> policies for >>>>> > thiis: >>>>> > >>>>> > https://www.afrinic.net/afpub-2026-asn-001-draft02.html >>>>> > >>>>> > Regards >>>>> > >>>>> > ---- >>>>> > Sent from my mobile >>>>> > kindly excuse typos >>>>> > >>>>> > On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, >>>> > >>>>> > wrote: >>>>> > >>>>> >> Dear PDWG, >>>>> >> >>>>> >> I have been following the discussions on the hierarchical AS?SET >>>>> naming >>>>> >> scheme and would like clarification on a few points: >>>>> >> >>>>> >> 1. Could this matter be addressed operationally, as is done in ARIN, >>>>> >> LACNIC, and RIPE NCC, without requiring policy changes? >>>>> >> >>>>> >> 2. If yes, why are we taking the policy route? Is it because AFRINIC >>>>> >> currently lacks a defined process for handling operational issues >>>>> that >>>>> >> affect IRR services? >>>>> >> >>>>> >> 3. Given that the hierarchical naming scheme is already supported >>>>> and >>>>> >> currently exists within the IRR, this proposal represents an >>>>> enforcement >>>>> >> change rather than the introduction of a new technical standard. >>>>> Why is a >>>>> >> formal policy required to change an operational enforcement >>>>> setting, rather >>>>> >> than a community-vetted technical implementation plan?" >>>>> >> >>>>> >> Thank you. >>>>> >> --- >>>>> >> Kone >>>>> >> >>>>> >> >>>>> >> >>>>> >> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal >>>>> a >>>>> >> ?crit : >>>>> >> >>>>> >>> Dear PDWG, >>>>> >>> >>>>> >>> >>>>> >>> The Policy Development Working Group (PDWG) Chairs have initiated >>>>> a Last >>>>> >>> Call for this proposal, following rough consensus at the >>>>> AFRINIC-37 Public >>>>> >>> Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June >>>>> 2026. >>>>> >>> >>>>> >>> * Proposal Name: Hierarchical Names for New AS-SETs >>>>> >>> >>>>> >>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >>>>> >>> >>>>> >>> * Proposal URL: >>>>> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >>>>> >>> >>>>> >>> Last Call closes on: July 31, 2026, at 23:59 UTC. >>>>> >>> >>>>> >>> >>>>> >>> 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. >>>>> >>> >>>>> >>> >>>>> >>> As always, we kindly request that all participants adhere to the >>>>> AFRINIC >>>>> >>> Code of Conduct to maintain a >>>>> respectful >>>>> >>> and professional environment on the mailing list. >>>>> >>> >>>>> >>> >>>>> >>> Kind regards, >>>>> >>> >>>>> >>> >>>>> >>> Haitham el Nakhal >>>>> >>> >>>>> >>> AFRINIC PDWG Co-Chair >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> _______________________________________________ >>>>> >>> RPD mailing list >>>>> >>> RPD at afrinic.net >>>>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>> >>> >>>>> >> _______________________________________________ >>>>> >> RPD mailing list >>>>> >> RPD at afrinic.net >>>>> >> https://lists.afrinic.net/mailman/listinfo/rpd >>>>> >> >>>>> > >>>>> -------------- next part -------------- >>>>> An HTML attachment was scrubbed... >>>>> URL: < >>>>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/4563e1d5/attachment-0001.html >>>>> > >>>>> >>>>> ------------------------------ >>>>> >>>>> Message: 3 >>>>> Date: Mon, 20 Jul 2026 23:10:04 +0200 >>>>> From: "jordi.palet at consulintel.es" >>>>> To: rpd >>>>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >>>>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >>>>> Message-ID: >>>>> Content-Type: text/plain; charset="utf-8" >>>>> >>>>> Hi Kone, >>>>> >>>>> And what is the relevance of that? >>>>> >>>>> If you have a good understanding about all the RIRs, you will know >>>>> that each RIR has their own ways to do things. In many senses they act very >>>>> similarly and in general we end up with very similarly policies, but not >>>>> always. Some RIRs have decided that some aspects are operational and don?t >>>>> need a policy proposal. >>>>> >>>>> However, despite that, the community is on top of the RIR, and the >>>>> community sometimes, may decide that they prefer a policy if the RIR hasn?t >>>>> been proactive in advance in any specific topic, or even if the RIR was >>>>> proactive, the community may prefer to speed up things, or to show the way >>>>> the community prefers. >>>>> >>>>> For example, if AFRINIC has any specific operational aspect already in >>>>> place, and the community prefer to manage that in a different way, the >>>>> community may opt either for suggesting the RIR to modify that operational >>>>> aspect or to do actually enforce it by means of a policy proposal. >>>>> >>>>> I think is important to know, by personal experience, how the other 4 >>>>> RIRs work before stating something that is not correct, because if you >>>>> don?t work in all the RIRs for many years, it will be difficult for you to >>>>> know the past and I?m sure IA will not be able to be precise as well. >>>>> >>>>> Regards, >>>>> Jordi >>>>> >>>>> @jordipalet >>>>> >>>>> > El 20 jul 2026, a las 22:34, Kone >>>>> escribi?: >>>>> > >>>>> > Hello Seun, >>>>> > You may have misread my earlier mail. I clearly stated that LACNIC, >>>>> RIPE NCC, and ARIN do not require policy to enforce hierarchical AS?SET >>>>> naming. >>>>> > >>>>> > To help close the ongoing discussions, I believe addressing the >>>>> questions I raised would bring clarity: >>>>> > * LACNIC enforces hierarchical AS?SET naming operationally, as part >>>>> of their IRR design from inception. >>>>> > * RIPE NCC handles IRR changes through their Numbered Work Items >>>>> (NWI) process, not through policy. >>>>> > * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR >>>>> operational matters, again without policy. >>>>> > >>>>> > >>>>> > These examples show that other RIRs (except APNIC) treat AS?SET >>>>> naming as an operational IRR matter, not a policy obligation. >>>>> > >>>>> > This is why I asked whether AFRINIC could address this operationally >>>>> rather than through policy, and why Last Call discussions would benefit >>>>> from clear answers to these points. >>>>> > >>>>> > Thanks. >>>>> > --- >>>>> > Kone >>>>> > >>>>> > >>>>> > >>>>> > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji >>>> > a ?crit : >>>>> >> Hello Bakenon, >>>>> >> >>>>> >> Do refer to the proposal as it references URL to other RIR's >>>>> policies for thiis: >>>>> >> >>>>> >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >>>>> >> >>>>> >> Regards >>>>> >> >>>>> >> ---- >>>>> >> Sent from my mobile >>>>> >> kindly excuse typos >>>>> >> >>>>> >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, < >>>>> bakenon.kone at sancfis.net > wrote: >>>>> >>> Dear PDWG, >>>>> >>> >>>>> >>> I have been following the discussions on the hierarchical AS?SET >>>>> naming scheme and would like clarification on a few points: >>>>> >>> >>>>> >>> 1. Could this matter be addressed operationally, as is done in >>>>> ARIN, LACNIC, and RIPE NCC, without requiring policy changes? >>>>> >>> >>>>> >>> 2. If yes, why are we taking the policy route? Is it because >>>>> AFRINIC currently lacks a defined process for handling operational issues >>>>> that affect IRR services? >>>>> >>> >>>>> >>> 3. Given that the hierarchical naming scheme is already supported >>>>> and currently exists within the IRR, this proposal represents an >>>>> enforcement change rather than the introduction of a new technical >>>>> standard. Why is a formal policy required to change an operational >>>>> enforcement setting, rather than a community-vetted technical >>>>> implementation plan?" >>>>> >>> >>>>> >>> Thank you. >>>>> >>> --- >>>>> >>> Kone >>>>> >>> >>>>> >>> >>>>> >>> >>>>> >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal >>>> > a ?crit : >>>>> >>>> Dear PDWG, >>>>> >>>> >>>>> >>>> >>>>> >>>> The Policy Development Working Group (PDWG) Chairs have initiated >>>>> a Last Call for this proposal, following rough consensus at the AFRINIC-37 >>>>> Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June >>>>> 2026. >>>>> >>>> >>>>> >>>> * Proposal Name: Hierarchical Names for New AS-SETs >>>>> >>>> >>>>> >>>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >>>>> >>>> >>>>> >>>> * Proposal URL: >>>>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >>>>> >>>> >>>>> >>>> Last Call closes on: July 31, 2026, at 23:59 UTC. >>>>> >>>> >>>>> >>>> >>>>> >>>> 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. >>>>> >>>> >>>>> >>>> >>>>> >>>> As always, we kindly request that all participants adhere to the >>>>> AFRINIC Code of Conduct to maintain a >>>>> respectful and professional environment on the mailing list. >>>>> >>>> >>>>> >>>> >>>>> >>>> Kind regards, >>>>> >>>> >>>>> >>>> >>>>> >>>> Haitham el Nakhal >>>>> >>>> >>>>> >>>> AFRINIC PDWG Co-Chair >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> _______________________________________________ >>>>> >>>> RPD mailing list >>>>> >>>> RPD at afrinic.net >>>>> >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>> >>> _______________________________________________ >>>>> >>> RPD mailing list >>>>> >>> RPD at afrinic.net >>>>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>> > _______________________________________________ >>>>> > RPD mailing list >>>>> > RPD at afrinic.net >>>>> > https://lists.afrinic.net/mailman/listinfo/rpd >>>>> >>>>> >>>>> >>>>> ********************************************** >>>>> IPv4 is over >>>>> Are you ready for the new Internet ? >>>>> http://www.theipv6company.com >>>>> The IPv6 Company >>>>> >>>>> This electronic message contains information which may be privileged >>>>> or confidential. The information is intended to be for the exclusive use of >>>>> the individual(s) named above and further non-explicilty authorized >>>>> disclosure, copying, distribution or use of the contents of this >>>>> information, even if partially, including attached files, is strictly >>>>> prohibited and will be considered a criminal offense. If you are not the >>>>> intended recipient be aware that any disclosure, copying, distribution or >>>>> use of the contents of this information, even if partially, including >>>>> attached files, is strictly prohibited, will be considered a criminal >>>>> offense, so you must reply to the original sender to inform about this >>>>> communication and delete it. >>>>> >>>>> -------------- next part -------------- >>>>> An HTML attachment was scrubbed... >>>>> URL: < >>>>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/b6777fa7/attachment.html >>>>> > >>>>> >>>>> ------------------------------ >>>>> >>>>> Subject: Digest Footer >>>>> >>>>> _______________________________________________ >>>>> RPD mailing list >>>>> RPD at afrinic.net >>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> End of RPD Digest, Vol 222, Issue 110 >>>>> ************************************* >>>>> >>>>> -------------- next part -------------- >>>>> An HTML attachment was scrubbed... >>>>> URL: < >>>>> https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e492c668/attachment.html >>>>> > >>>>> >>>>> ------------------------------ >>>>> >>>>> Subject: Digest Footer >>>>> >>>>> _______________________________________________ >>>>> RPD mailing list >>>>> RPD at afrinic.net >>>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> End of RPD Digest, Vol 222, Issue 111 >>>>> ************************************* >>>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.medoye at gmail.com Tue Jul 21 11:16:30 2026 From: daniel.medoye at gmail.com (Taye Medoye) Date: Tue, 21 Jul 2026 13:16:30 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 122 Message-ID: Dear All, I think the clarification made by Fundiswa regarding the seemingly fluid interconnection between the stage of consensus and Last Call in reaching a policy statement suffices. It is understood that if, at the point of Last Call on a policy proposal process, there arises an intervening factor, the need for a further review can be allowed. Besides, l have taken note of the relevance of the possible effect of diversities in the different Registries on the development of policy action on any subject-matter for consideration. And l think this should be accorded the recognition it deserves. Therefore, l align with the perspective as suggested by Fundiswa, and hope for an understanding of the Community participants on the same. Taye Medoye. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Tue Jul 21 11:18:25 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Tue, 21 Jul 2026 13:18:25 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 124 In-Reply-To: References: Message-ID: Dear Jordi, You are answering whether policy is procedurally permitted. That is not the question being raised. The fact that the bylaws and PDP allow a policy does not prove that policy is necessary, proportionate, or the best instrument. Likewise, the absence of a staff statement saying ?policy is not needed? is not evidence that it is needed. Silence cannot manufacture necessity. Kone?s examples remain relevant because they show that the same technical outcome can be achieved operationally. The unanswered question is what binding policy adds beyond rigidity and registry enforcement. A procedural route does not justify itself merely because it is familiar. That is how process becomes mandate: the PDP permits policy, therefore policy is treated as necessary, and the resulting enforcement is then called community authority. Last Call exists precisely to test unresolved concerns, including the choice of instrument. Consensus is not protected by declaring that it was already reached before those concerns were answered. I therefore support Kone?s questions and remain opposed to the policy route. Regards, Nonhlanhla On Tue, 21 Jul 2026, 1:05 pm wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: RPD Digest, Vol 222, Issue 122 (jordi.palet at consulintel.es) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2026 13:03:53 +0200 > From: "jordi.palet at consulintel.es" > To: rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 122 > Message-ID: <3071913E-7C72-49BC-BEDD-B7F26DE20A96 at consulintel.es> > Content-Type: text/plain; charset="utf-8" > > Well ? that?s incorrect. Nobody in the community, neither the staff impact > assessment, said that a policy is not needed and many folks already > contested several times, that doing it by means of a policy is valid > according to the bylaws and PDP and it has not been demonstrated by > objections that following this path, with is the most regular one in > AFRINIC, creates any harm or problem. > > So repeating the argument, by many folks, many times, doesn?t demonstrate > ?per se" that it is a valid objection to revert the already reached > consensus. Of course, this is a decision that need to be taken by PDP > chairs, but this is my view point from an exclusive ?procedural? basis. > > Regards, > Jordi > > @jordipalet > > > El 21 jul 2026, a las 12:46, Fundiswa Nadia Maseko < > fundiswanadia2 at gmail.com> escribi?: > > > > Dear Jordi, > > > > Thank you for your clarification. > > > > I understand your point that the proposal has already reached consensus > and that Last Call is intended to identify any weaknesses that may have > been overlooked. > > > > My concern is precisely that if the choice of mechanism was not > sufficiently examined during the earlier discussions, then it remains a > valid point to raise during Last Call. If a proposal introduces policy > where an operational approach could achieve the same objective, that > affects whether policy is the appropriate solution in the first place. > > > > I appreciate that consensus was declared, but consensus does not prevent > the community from identifying a concern that may not have received enough > attention. Last Call exists to give the community one final opportunity to > do exactly that. > > > > > > Kind regards, > > > > Fundiswa > > > > On Tue, 21 Jul 2026, 12:30 , rpd-request at afrinic.net>> wrote: > >> Send RPD mailing list submissions to > >> rpd at afrinic.net > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> or, via email, send a message with subject or body 'help' to > >> rpd-request at afrinic.net > >> > >> You can reach the person managing the list at > >> rpd-owner at afrinic.net > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of RPD digest..." > >> > >> > >> Today's Topics: > >> > >> 1. Re: RPD Digest, Vol 222, Issue 119 (jordi.palet at consulintel.es > ) > >> > >> > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Tue, 21 Jul 2026 12:29:07 +0200 > >> From: "jordi.palet at consulintel.es " > > > >> To: rpd at afrinic.net > >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 119 > >> Message-ID: > > >> Content-Type: text/plain; charset="utf-8" > >> > >> Hi Fundiswa, > >> > >> Is not a matter of what is practical and what not. > >> > >> It is a matter that, during the discussion of the policy proposal > (which is not the same as the Last Call), the community reached consensus > on making it this way. RIRs follow the same procedures for reaching > consensus as IETF, this has been said several times. The Last Call is a > last opportunity to discover any weak point in a proposal that already > reached consensus, and was OVERLOOKED before. Is not about discussing if > the proposal should be a proposal or an operational decision. This is no > longer the moment to discuss that (it should have done when the proposal > was being discussed before reaching consensus), and many folks in this > discussing are ignoring that, probably because they are not used to IETF > procedures. > >> > >> Otherwise, you can remain silent during the proposal discussion, during > the presentation in the PPM and object to it after reached consensus, which > is an incorrect procedure. > >> > >> One more example: we could have asked AFRINIC many years ago to write > the Soft Landing as an operational thing, instead we as a community, > decided to make it a policy proposal. Same here. However, the community > decided to do it as a proposal and it was accepted that way at the right > time, not in the Last Call. > >> > >> By the way, I love cooking so from time to time follow some > documentaries about that. Are you the same person as the famous chef? I > think I saw you in a TV program some months ago or I?m confused. > >> > >> Regards, > >> Jordi > >> > >> @jordipalet > >> > >> > El 21 jul 2026, a las 12:03, Fundiswa Nadia Maseko < > fundiswanadia2 at gmail.com > escribi?: > >> > > >> > Dear Jordi, > >> > > >> > Thank you for your response. > >> > > >> > I agree that AFRINIC is not required to follow the same approach as > other RIRs. Every region should make decisions that suit its own community. > >> > > >> > My point, however, is slightly different. I wasn't suggesting that > AFRINIC should copy another RIR simply because they did it that way. > >> > > >> > Rather, I'm asking what specific problem is solved by making this a > policy instead of implementing it operationally. If both approaches achieve > the same technical outcome, then what additional value does the policy > itself provide? > >> > > >> > I think that's an important distinction. The fact that the community > can choose policy doesn't necessarily mean policy is the most appropriate > mechanism in every case. > >> > > >> > I'd be interested to hear what practical or technical benefit you > believe is only possible through policy and not through an operational > implementation. > >> > > >> > Kind regards, > >> > > >> > Fundiswa > >> > > >> > > >> > > >> > On Tue, 21 Jul 2026, 11:57 , rpd-request at afrinic.net> rpd-request at afrinic.net>>> wrote: > >> >> Send RPD mailing list submissions to > >> >> rpd at afrinic.net rpd at afrinic.net > > >> >> > >> >> To subscribe or unsubscribe via the World Wide Web, visit > >> >> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> or, via email, send a message with subject or body 'help' to > >> >> rpd-request at afrinic.net > > > >> >> > >> >> You can reach the person managing the list at > >> >> rpd-owner at afrinic.net > > > >> >> > >> >> When replying, please edit your Subject line so it is more specific > >> >> than "Re: Contents of RPD digest..." > >> >> > >> >> > >> >> Today's Topics: > >> >> > >> >> 1. Re: RPD Digest, Vol 222, Issue 111 (Nia Petronella) > >> >> > >> >> > >> >> > ---------------------------------------------------------------------- > >> >> > >> >> Message: 1 > >> >> Date: Tue, 21 Jul 2026 11:56:49 +0200 > >> >> From: Nia Petronella nonhlanhlapetronella85 at gmail.com> >> > >> >> To: Andrew Alston aa at alstonnetworks.net> aa at alstonnetworks.net>>> > >> >> Cc: rpd at afrinic.net > > >> >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 111 > >> >> Message-ID: > >> >> itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com> itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com>>> > >> >> Content-Type: text/plain; charset="utf-8" > >> >> > >> >> Dear Andrew, > >> >> > >> >> I do not accept the binary you have presented. > >> >> > >> >> No one is suggesting that AFRINIC should make operational changes in > secret > >> >> or without community input. An operational change can be published, > >> >> consulted on, tested, documented, and reviewed. The real question is > >> >> whether that input must be converted into binding policy enforced by > the > >> >> registry. > >> >> > >> >> Calling AFRINIC ?community-driven? does not answer who the community > is or > >> >> what it is authorised to bind. A self-selecting group of mailing-list > >> >> participants can provide expertise, support, and objection. It does > not > >> >> automatically represent every member, resource holder, network, > customer, > >> >> or other affected party. > >> >> > >> >> The institutional reality also remains unchanged: participants > discuss the > >> >> policy, but AFRINIC interprets and enforces it. Community > participation > >> >> therefore does not eliminate registry power. It can become the > language > >> >> used to legitimise that power. > >> >> > >> >> This is why Kone?s examples matter. If LACNIC, RIPE NCC, and ARIN can > >> >> achieve the same technical outcome through operational mechanisms, > then > >> >> policy is not technically inevitable. Proponents should explain what > >> >> additional technical result binding policy provides, beyond > converting an > >> >> IRR setting into an enforceable obligation. > >> >> > >> >> I also disagree that an objection is valid only if it proves > immediate > >> >> operational harm or implementation failure. The choice of instrument, > >> >> proportionality, reversibility, and expansion of enforcement > authority are > >> >> legitimate policy concerns. Last Call is not limited to asking > whether > >> >> software will break. It must also ask whether the proposed power is > greater > >> >> than the problem requires. > >> >> > >> >> Rough consensus does not require every objection to be accommodated. > But an > >> >> objection is not ?addressed? merely because supporters repeat that > the > >> >> community prefers policy. That is the very assumption being > challenged. > >> >> Procedure cannot be used to prove its own mandate. > >> >> > >> >> The fact that the RIR system has operated this way for decades > demonstrates > >> >> continuity of practice. It does not establish unlimited legitimacy > of scope. > >> >> > >> >> I support Kone?s questions and remain opposed to > AFPUB-2026-ASN-001-DRAFT02. > >> >> > >> >> Regards, > >> >> Nonhlanhla > >> >> > >> >> > >> >> > >> >> On Tue, 21 Jul 2026, 10:26 am Andrew Alston aa at alstonnetworks.net>>> wrote: > >> >> > >> >> > The answer to this is simple. AfriNiC is a community driven > organisation > >> >> > - and anything done with regard to address allocation and > management is > >> >> > done as per policy provided by the community. It is through > policy that > >> >> > the community tells AfriNIC how to do things in regards to the > allocation > >> >> > and handling of resources. > >> >> > > >> >> > Without policy, the discretion and rules are entirely in the hands > of the > >> >> > registry, and the community voice is removed. > >> >> > > >> >> > This has been the way the RIR system has operated for decades and > it > >> >> > works. The community exercises its voice and its right as to how > things > >> >> > are done in relation to resource management through policy. > >> >> > > >> >> > Arguing that just because something can be done another way, is > not in my > >> >> > view a valid argument against policy. Objections to policy need > to be > >> >> > technically grounded and demonstrate that the policy would either > cause > >> >> > harm or alternatively be impractical to implement. Anything else > is simply > >> >> > arguing that policy should not exist because someone doesn?t like > AfriNIC > >> >> > being told how the community wants things done - and that isn?t an > argument > >> >> > that I believe rises to the level of a block on consensus. > >> >> > > >> >> > Please note - consensus does not require that the issue you raise > have > >> >> > been fixed, it requires that they have been addressed, and should > the > >> >> > community feel that despite the objections, the policy is > something that > >> >> > should proceed based on the fact that the questions have been > addressed if > >> >> > not necessarily accommodated, rough consensus still exists. > >> >> > > >> >> > Again, I support the policy and I see no technical or > evidence/fact-based > >> >> > arguments against said policy. > >> >> > > >> >> > Andrew > >> >> > > >> >> > On Tue, Jul 21, 2026 at 09:34, Nia Petronella < > >> >> > nonhlanhlapetronella85 at gmail.com nonhlanhlapetronella85 at gmail.com> >> wrote: > >> >> > > >> >> >> Dear PDWG, > >> >> >> > >> >> >> Kone is asking the right question. > >> >> >> > >> >> >> The issue is no longer whether hierarchical AS-SET naming is > technically > >> >> >> possible or useful. It already exists. The issue is why AFRINIC > needs a > >> >> >> binding policy to enforce what other RIRs largely treat as an > operational > >> >> >> IRR matter. > >> >> >> > >> >> >> That distinction matters. An operational change adjusts how a > service is > >> >> >> implemented. A policy creates an enforceable obligation and > enlarges the > >> >> >> registry?s authority. If the same technical result can be > achieved through > >> >> >> a community-reviewed implementation plan, then policy is not the > minimum > >> >> >> necessary instrument. > >> >> >> > >> >> >> Saying that ?the community prefers policy? is not enough. > Participation > >> >> >> may guide technical work, but it does not turn every preference > into a > >> >> >> mandate. A mailing list is not a legislature, and the > availability of the > >> >> >> PDP should not make policy the default answer to every > operational setting. > >> >> >> > >> >> >> This is how gatekeeping expands: the registry begins with a useful > >> >> >> technical function, then policy converts that function into > permission and > >> >> >> enforcement. The recordkeeper gradually becomes the rule-maker. > >> >> >> > >> >> >> The proponents should therefore answer Kone directly: what > technical > >> >> >> outcome can mandatory policy achieve here that an operational > >> >> >> implementation cannot? > >> >> >> > >> >> >> Until that is clearly demonstrated, I support Kone?s questions > and remain > >> >> >> opposed to the policy route. > >> >> >> > >> >> >> Regards, > >> >> >> Nonhlanhla > >> >> >> > >> >> >> > >> >> >> > >> >> >> On Tue, 21 Jul 2026, 8:20 am rpd-request at afrinic.net> rpd-request at afrinic.net>>> wrote: > >> >> >> > >> >> >>> Send RPD mailing list submissions to > >> >> >>> rpd at afrinic.net rpd at afrinic.net > > >> >> >>> > >> >> >>> To subscribe or unsubscribe via the World Wide Web, visit > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >>> or, via email, send a message with subject or body 'help' to > >> >> >>> rpd-request at afrinic.net > > > >> >> >>> > >> >> >>> You can reach the person managing the list at > >> >> >>> rpd-owner at afrinic.net > > > >> >> >>> > >> >> >>> When replying, please edit your Subject line so it is more > specific > >> >> >>> than "Re: Contents of RPD digest..." > >> >> >>> > >> >> >>> > >> >> >>> Today's Topics: > >> >> >>> > >> >> >>> 1. Re: RPD Digest, Vol 222, Issue 110 (Tshepo Masuku) > >> >> >>> > >> >> >>> > >> >> >>> > ---------------------------------------------------------------------- > >> >> >>> > >> >> >>> Message: 1 > >> >> >>> Date: Tue, 21 Jul 2026 06:19:05 +0000 > >> >> >>> From: Tshepo Masuku TshepoMasuku26 at hotmail.com> TshepoMasuku26 at hotmail.com>>> > >> >> >>> To: "rpd at afrinic.net rpd at afrinic.net >" rpd at afrinic.net> >> > >> >> >>> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 110 > >> >> >>> Message-ID: > >> >> >>> < > >> >> >>> > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com> > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > >> > >> >> >>> > > >> >> >>> > >> >> >>> Content-Type: text/plain; charset="windows-1252" > >> >> >>> > >> >> >>> Dear All, > >> >> >>> > >> >> >>> Kone?s point is directly relevant. If LACNIC, RIPE NCC, and ARIN > can > >> >> >>> implement hierarchical AS-SET naming through operational > mechanisms, then > >> >> >>> proponents must explain why AFRINIC needs a binding policy to > achieve the > >> >> >>> same technical result. > >> >> >>> > >> >> >>> Saying that each RIR works differently does not answer that > question. > >> >> >>> Nor does saying that ?the community is on top of the RIR.? A > community may > >> >> >>> advise, object, and coordinate. It does not acquire unlimited > authority to > >> >> >>> convert every operational preference into policy. A mailing list > is not a > >> >> >>> legislature. > >> >> >>> > >> >> >>> If AFRINIC can solve this through an operational change, policy > adds > >> >> >>> governance where technical administration would be sufficient. > Speed and > >> >> >>> preference do not create mandate. > >> >> >>> > >> >> >>> Kone provided specific examples. Those should be answered with > evidence, > >> >> >>> not by questioning whether he has worked in every RIR for many > years. > >> >> >>> Experience is relevant, but it is not authority and it is not a > substitute > >> >> >>> for argument. > >> >> >>> > >> >> >>> The unanswered question remains: what technical necessity > requires > >> >> >>> policy rather than operational implementation? > >> >> >>> > >> >> >>> Until that is answered, Kone?s objection stands, and I support > it. > >> >> >>> > >> >> >>> Regards, > >> >> >>> Tshepo > >> >> >>> > >> >> >>> > >> >> >>> ________________________________ > >> >> >>> From: rpd-request at afrinic.net > > < > rpd-request at afrinic.net rpd-request at afrinic.net >> > >> >> >>> Sent: Monday, July 20, 2026 11:10:57 pm > >> >> >>> To: rpd at afrinic.net rpd at afrinic.net > rpd at afrinic.net> >> > >> >> >>> Subject: RPD Digest, Vol 222, Issue 110 > >> >> >>> > >> >> >>> Send RPD mailing list submissions to > >> >> >>> rpd at afrinic.net rpd at afrinic.net > > >> >> >>> > >> >> >>> To subscribe or unsubscribe via the World Wide Web, visit > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >>> or, via email, send a message with subject or body 'help' to > >> >> >>> rpd-request at afrinic.net > > > >> >> >>> > >> >> >>> You can reach the person managing the list at > >> >> >>> rpd-owner at afrinic.net > > > >> >> >>> > >> >> >>> When replying, please edit your Subject line so it is more > specific > >> >> >>> than "Re: Contents of RPD digest..." > >> >> >>> > >> >> >>> > >> >> >>> Today's Topics: > >> >> >>> > >> >> >>> 1. Re: Writing tools (Ben Roberts - AfriNIC) > >> >> >>> 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > >> >> >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Kone) > >> >> >>> 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > >> >> >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >> >> >>> (jordi.palet at consulintel.es jordi.palet at consulintel.es> jordi.palet at consulintel.es>>) > >> >> >>> > >> >> >>> > >> >> >>> > ---------------------------------------------------------------------- > >> >> >>> > >> >> >>> Message: 1 > >> >> >>> Date: Mon, 20 Jul 2026 21:26:40 +0200 > >> >> >>> From: Ben Roberts - AfriNIC ben.roberts at afrinic.net> ben.roberts at afrinic.net>>> > >> >> >>> To: Nonjabulo Sphilile nonjabulosphilile at gmail.com> nonjabulosphilile at gmail.com>>> > >> >> >>> Cc: rpd at afrinic.net rpd at afrinic.net > > >> >> >>> Subject: Re: [rpd] Writing tools > >> >> >>> Message-ID: <09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net > 09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net 09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net>>> > >> >> >>> Content-Type: text/plain; charset="us-ascii" > >> >> >>> > >> >> >>> An HTML attachment was scrubbed... > >> >> >>> URL: < > >> >> >>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/33c3ac9e/attachment-0001.html > >> >> >>> > > >> >> >>> > >> >> >>> ------------------------------ > >> >> >>> > >> >> >>> Message: 2 > >> >> >>> Date: Mon, 20 Jul 2026 20:34:20 +0000 > >> >> >>> From: Kone bakenon.kone at sancfis.net> bakenon.kone at sancfis.net>>> > >> >> >>> To: Seun Ojedeji seun.ojedeji at gmail.com> seun.ojedeji at gmail.com>>> > >> >> >>> Cc: rpd rpd at afrinic.net >> > >> >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - > Hierarchical > >> >> >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >> >> >>> Message-ID: > >> >> >>> >> >> >>> 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com> 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com>>> > >> >> >>> Content-Type: text/plain; charset="utf-8" > >> >> >>> > >> >> >>> Hello Seun, > >> >> >>> You may have misread my earlier mail. I clearly stated that > LACNIC, RIPE > >> >> >>> NCC, and ARIN do not require policy to enforce hierarchical > AS?SET > >> >> >>> naming. > >> >> >>> > >> >> >>> To help close the ongoing discussions, I believe addressing the > >> >> >>> questions I > >> >> >>> raised would bring clarity: > >> >> >>> * LACNIC enforces hierarchical AS?SET naming operationally, as > part of > >> >> >>> their IRR design from inception. > >> >> >>> * RIPE NCC handles IRR changes through their Numbered Work Items > (NWI) > >> >> >>> process, not through policy. > >> >> >>> * ARIN uses the ACSP (Consultation and Suggestion Process) for > IRR > >> >> >>> operational matters, again without policy. > >> >> >>> > >> >> >>> > >> >> >>> These examples show that other RIRs (except APNIC) treat AS?SET > naming as > >> >> >>> an operational IRR matter, not a policy obligation. > >> >> >>> > >> >> >>> This is why I asked whether AFRINIC could address this > operationally > >> >> >>> rather > >> >> >>> than through policy, and why Last Call discussions would benefit > from > >> >> >>> clear > >> >> >>> answers to these points. > >> >> >>> > >> >> >>> Thanks. > >> >> >>> --- > >> >> >>> Kone > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji < > seun.ojedeji at gmail.com seun.ojedeji at gmail.com >> a > >> >> >>> ?crit : > >> >> >>> > >> >> >>> > Hello Bakenon, > >> >> >>> > > >> >> >>> > Do refer to the proposal as it references URL to other RIR's > policies > >> >> >>> for > >> >> >>> > thiis: > >> >> >>> > > >> >> >>> > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >> >> >>> > > >> >> >>> > Regards > >> >> >>> > > >> >> >>> > ---- > >> >> >>> > Sent from my mobile > >> >> >>> > kindly excuse typos > >> >> >>> > > >> >> >>> > On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, < > bakenon.kone at sancfis.net bakenon.kone at sancfis.net >> > >> >> >>> > wrote: > >> >> >>> > > >> >> >>> >> Dear PDWG, > >> >> >>> >> > >> >> >>> >> I have been following the discussions on the hierarchical > AS?SET > >> >> >>> naming > >> >> >>> >> scheme and would like clarification on a few points: > >> >> >>> >> > >> >> >>> >> 1. Could this matter be addressed operationally, as is done > in ARIN, > >> >> >>> >> LACNIC, and RIPE NCC, without requiring policy changes? > >> >> >>> >> > >> >> >>> >> 2. If yes, why are we taking the policy route? Is it because > AFRINIC > >> >> >>> >> currently lacks a defined process for handling operational > issues that > >> >> >>> >> affect IRR services? > >> >> >>> >> > >> >> >>> >> 3. Given that the hierarchical naming scheme is already > supported and > >> >> >>> >> currently exists within the IRR, this proposal represents an > >> >> >>> enforcement > >> >> >>> >> change rather than the introduction of a new technical > standard. Why > >> >> >>> is a > >> >> >>> >> formal policy required to change an operational enforcement > setting, > >> >> >>> rather > >> >> >>> >> than a community-vetted technical implementation plan?" > >> >> >>> >> > >> >> >>> >> Thank you. > >> >> >>> >> --- > >> >> >>> >> Kone > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal < > hytham at tra.gov.eg >> a > >> >> >>> >> ?crit : > >> >> >>> >> > >> >> >>> >>> Dear PDWG, > >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> The Policy Development Working Group (PDWG) Chairs have > initiated a > >> >> >>> Last > >> >> >>> >>> Call for this proposal, following rough consensus at the > AFRINIC-37 > >> >> >>> Public > >> >> >>> >>> Policy Meeting held in hybrid format in Nairobi, Kenya on 24 > June > >> >> >>> 2026. > >> >> >>> >>> > >> >> >>> >>> * Proposal Name: Hierarchical Names for New AS-SETs > >> >> >>> >>> > >> >> >>> >>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > >> >> >>> >>> > >> >> >>> >>> * Proposal URL: > >> >> >>> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >> >> >>> >>> > >> >> >>> >>> Last Call closes on: July 31, 2026, at 23:59 UTC. > >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> 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. > >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> As always, we kindly request that all participants adhere to > the > >> >> >>> AFRINIC > >> >> >>> >>> Code of Conduct to maintain a > >> >> >>> respectful > >> >> >>> >>> and professional environment on the mailing list. > >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> Kind regards, > >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> Haitham el Nakhal > >> >> >>> >>> > >> >> >>> >>> AFRINIC PDWG Co-Chair > >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> _______________________________________________ > >> >> >>> >>> RPD mailing list > >> >> >>> >>> RPD at afrinic.net RPD at afrinic.net > > >> >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >>> >>> > >> >> >>> >> _______________________________________________ > >> >> >>> >> RPD mailing list > >> >> >>> >> RPD at afrinic.net RPD at afrinic.net > > >> >> >>> >> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >>> >> > >> >> >>> > > >> >> >>> -------------- next part -------------- > >> >> >>> An HTML attachment was scrubbed... > >> >> >>> URL: < > >> >> >>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/4563e1d5/attachment-0001.html > >> >> >>> > > >> >> >>> > >> >> >>> ------------------------------ > >> >> >>> > >> >> >>> Message: 3 > >> >> >>> Date: Mon, 20 Jul 2026 23:10:04 +0200 > >> >> >>> From: "jordi.palet at consulintel.es jordi.palet at consulintel.es> jordi.palet at consulintel.es>>" jordi.palet at consulintel.es> jordi.palet at consulintel.es>>> > >> >> >>> To: rpd rpd at afrinic.net >> > >> >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - > Hierarchical > >> >> >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >> >> >>> Message-ID: F22A09CF-A827-4D7F-B077-E0B9C774AF00 at consulintel.es F22A09CF-A827-4D7F-B077-E0B9C774AF00 at consulintel.es>>> > >> >> >>> Content-Type: text/plain; charset="utf-8" > >> >> >>> > >> >> >>> Hi Kone, > >> >> >>> > >> >> >>> And what is the relevance of that? > >> >> >>> > >> >> >>> If you have a good understanding about all the RIRs, you will > know that > >> >> >>> each RIR has their own ways to do things. In many senses they > act very > >> >> >>> similarly and in general we end up with very similarly policies, > but not > >> >> >>> always. Some RIRs have decided that some aspects are operational > and don?t > >> >> >>> need a policy proposal. > >> >> >>> > >> >> >>> However, despite that, the community is on top of the RIR, and > the > >> >> >>> community sometimes, may decide that they prefer a policy if the > RIR hasn?t > >> >> >>> been proactive in advance in any specific topic, or even if the > RIR was > >> >> >>> proactive, the community may prefer to speed up things, or to > show the way > >> >> >>> the community prefers. > >> >> >>> > >> >> >>> For example, if AFRINIC has any specific operational aspect > already in > >> >> >>> place, and the community prefer to manage that in a different > way, the > >> >> >>> community may opt either for suggesting the RIR to modify that > operational > >> >> >>> aspect or to do actually enforce it by means of a policy > proposal. > >> >> >>> > >> >> >>> I think is important to know, by personal experience, how the > other 4 > >> >> >>> RIRs work before stating something that is not correct, because > if you > >> >> >>> don?t work in all the RIRs for many years, it will be difficult > for you to > >> >> >>> know the past and I?m sure IA will not be able to be precise as > well. > >> >> >>> > >> >> >>> Regards, > >> >> >>> Jordi > >> >> >>> > >> >> >>> @jordipalet > >> >> >>> > >> >> >>> > El 20 jul 2026, a las 22:34, Kone >> escribi?: > >> >> >>> > > >> >> >>> > Hello Seun, > >> >> >>> > You may have misread my earlier mail. I clearly stated that > LACNIC, > >> >> >>> RIPE NCC, and ARIN do not require policy to enforce hierarchical > AS?SET > >> >> >>> naming. > >> >> >>> > > >> >> >>> > To help close the ongoing discussions, I believe addressing the > >> >> >>> questions I raised would bring clarity: > >> >> >>> > * LACNIC enforces hierarchical AS?SET naming operationally, as > part of > >> >> >>> their IRR design from inception. > >> >> >>> > * RIPE NCC handles IRR changes through their Numbered Work > Items (NWI) > >> >> >>> process, not through policy. > >> >> >>> > * ARIN uses the ACSP (Consultation and Suggestion Process) for > IRR > >> >> >>> operational matters, again without policy. > >> >> >>> > > >> >> >>> > > >> >> >>> > These examples show that other RIRs (except APNIC) treat > AS?SET naming > >> >> >>> as an operational IRR matter, not a policy obligation. > >> >> >>> > > >> >> >>> > This is why I asked whether AFRINIC could address this > operationally > >> >> >>> rather than through policy, and why Last Call discussions would > benefit > >> >> >>> from clear answers to these points. > >> >> >>> > > >> >> >>> > Thanks. > >> >> >>> > --- > >> >> >>> > Kone > >> >> >>> > > >> >> >>> > > >> >> >>> > > >> >> >>> > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji < > seun.ojedeji at gmail.com seun.ojedeji at gmail.com > > >> >> >>> > >>> a ?crit > : > >> >> >>> >> Hello Bakenon, > >> >> >>> >> > >> >> >>> >> Do refer to the proposal as it references URL to other RIR's > policies > >> >> >>> for thiis: > >> >> >>> >> > >> >> >>> >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >> >> >>> >> > >> >> >>> >> Regards > >> >> >>> >> > >> >> >>> >> ---- > >> >> >>> >> Sent from my mobile > >> >> >>> >> kindly excuse typos > >> >> >>> >> > >> >> >>> >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, < > bakenon.kone at sancfis.net bakenon.kone at sancfis.net > > >> >> >>> bakenon.kone at sancfis.net> bakenon.kone at sancfis.net>>>> wrote: > >> >> >>> >>> Dear PDWG, > >> >> >>> >>> > >> >> >>> >>> I have been following the discussions on the hierarchical > AS?SET > >> >> >>> naming scheme and would like clarification on a few points: > >> >> >>> >>> > >> >> >>> >>> 1. Could this matter be addressed operationally, as is done > in ARIN, > >> >> >>> LACNIC, and RIPE NCC, without requiring policy changes? > >> >> >>> >>> > >> >> >>> >>> 2. If yes, why are we taking the policy route? Is it because > AFRINIC > >> >> >>> currently lacks a defined process for handling operational > issues that > >> >> >>> affect IRR services? > >> >> >>> >>> > >> >> >>> >>> 3. Given that the hierarchical naming scheme is already > supported > >> >> >>> and currently exists within the IRR, this proposal represents an > >> >> >>> enforcement change rather than the introduction of a new > technical > >> >> >>> standard. Why is a formal policy required to change an > operational > >> >> >>> enforcement setting, rather than a community-vetted technical > >> >> >>> implementation plan?" > >> >> >>> >>> > >> >> >>> >>> Thank you. > >> >> >>> >>> --- > >> >> >>> >>> Kone > >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal < > hytham at tra.gov.eg > > >> >> >>> hytham at tra.gov.eg >>> a ?crit : > >> >> >>> >>>> Dear PDWG, > >> >> >>> >>>> > >> >> >>> >>>> > >> >> >>> >>>> The Policy Development Working Group (PDWG) Chairs have > initiated a > >> >> >>> Last Call for this proposal, following rough consensus at the > AFRINIC-37 > >> >> >>> Public Policy Meeting held in hybrid format in Nairobi, Kenya on > 24 June > >> >> >>> 2026. > >> >> >>> >>>> > >> >> >>> >>>> * Proposal Name: Hierarchical Names for New AS-SETs > >> >> >>> >>>> > >> >> >>> >>>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > >> >> >>> >>>> > >> >> >>> >>>> * Proposal URL: > >> >> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >> >> >>> >>>> > >> >> >>> >>>> Last Call closes on: July 31, 2026, at 23:59 UTC. > >> >> >>> >>>> > >> >> >>> >>>> > >> >> >>> >>>> 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. > >> >> >>> >>>> > >> >> >>> >>>> > >> >> >>> >>>> As always, we kindly request that all participants adhere > to the > >> >> >>> AFRINIC Code of Conduct to > maintain a > >> >> >>> respectful and professional environment on the mailing list. > >> >> >>> >>>> > >> >> >>> >>>> > >> >> >>> >>>> Kind regards, > >> >> >>> >>>> > >> >> >>> >>>> > >> >> >>> >>>> Haitham el Nakhal > >> >> >>> >>>> > >> >> >>> >>>> AFRINIC PDWG Co-Chair > >> >> >>> >>>> > >> >> >>> >>>> > >> >> >>> >>>> > >> >> >>> >>>> _______________________________________________ > >> >> >>> >>>> RPD mailing list > >> >> >>> >>>> RPD at afrinic.net RPD at afrinic.net > RPD at afrinic.net> >> > >> >> >>> >>>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >>> >>> _______________________________________________ > >> >> >>> >>> RPD mailing list > >> >> >>> >>> RPD at afrinic.net RPD at afrinic.net > RPD at afrinic.net> >> > >> >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >>> > _______________________________________________ > >> >> >>> > RPD mailing list > >> >> >>> > RPD at afrinic.net RPD at afrinic.net > > >> >> >>> > https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> ********************************************** > >> >> >>> IPv4 is over > >> >> >>> Are you ready for the new Internet ? > >> >> >>> http://www.theipv6company.com < > http://www.theipv6company.com/> > >> >> >>> The IPv6 Company > >> >> >>> > >> >> >>> This electronic message contains information which may be > privileged or > >> >> >>> confidential. The information is intended to be for the > exclusive use of > >> >> >>> the individual(s) named above and further non-explicilty > authorized > >> >> >>> disclosure, copying, distribution or use of the contents of this > >> >> >>> information, even if partially, including attached files, is > strictly > >> >> >>> prohibited and will be considered a criminal offense. If you are > not the > >> >> >>> intended recipient be aware that any disclosure, copying, > distribution or > >> >> >>> use of the contents of this information, even if partially, > including > >> >> >>> attached files, is strictly prohibited, will be considered a > criminal > >> >> >>> offense, so you must reply to the original sender to inform > about this > >> >> >>> communication and delete it. > >> >> >>> > >> >> >>> -------------- next part -------------- > >> >> >>> An HTML attachment was scrubbed... > >> >> >>> URL: < > >> >> >>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/b6777fa7/attachment.html > >> >> >>> > > >> >> >>> > >> >> >>> ------------------------------ > >> >> >>> > >> >> >>> Subject: Digest Footer > >> >> >>> > >> >> >>> _______________________________________________ > >> >> >>> RPD mailing list > >> >> >>> RPD at afrinic.net > > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >>> > >> >> >>> > >> >> >>> ------------------------------ > >> >> >>> > >> >> >>> End of RPD Digest, Vol 222, Issue 110 > >> >> >>> ************************************* > >> >> >>> > >> >> >>> -------------- next part -------------- > >> >> >>> An HTML attachment was scrubbed... > >> >> >>> URL: < > >> >> >>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e492c668/attachment.html > >> >> >>> > > >> >> >>> > >> >> >>> ------------------------------ > >> >> >>> > >> >> >>> Subject: Digest Footer > >> >> >>> > >> >> >>> _______________________________________________ > >> >> >>> RPD mailing list > >> >> >>> RPD at afrinic.net > > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >>> > >> >> >>> > >> >> >>> ------------------------------ > >> >> >>> > >> >> >>> End of RPD Digest, Vol 222, Issue 111 > >> >> >>> ************************************* > >> >> >>> > >> >> >> _______________________________________________ > >> >> >> RPD mailing list > >> >> >> RPD at afrinic.net > > >> >> >> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >> > >> >> > > >> >> -------------- next part -------------- > >> >> An HTML attachment was scrubbed... > >> >> URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/9c41424a/attachment.html > > > >> >> > >> >> ------------------------------ > >> >> > >> >> Subject: Digest Footer > >> >> > >> >> _______________________________________________ > >> >> RPD mailing list > >> >> RPD at afrinic.net > > >> >> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> > >> >> > >> >> ------------------------------ > >> >> > >> >> End of RPD Digest, Vol 222, Issue 119 > >> >> ************************************* > >> > _______________________________________________ > >> > RPD mailing list > >> > RPD at afrinic.net > >> > https://lists.afrinic.net/mailman/listinfo/rpd > >> > >> > >> > >> ********************************************** > >> IPv4 is over > >> Are you ready for the new Internet ? > >> http://www.theipv6company.com > >> The IPv6 Company > >> > >> This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > >> > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/0ba797a1/attachment.html > > > >> > >> ------------------------------ > >> > >> Subject: Digest Footer > >> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> > >> > >> ------------------------------ > >> > >> End of RPD Digest, Vol 222, Issue 122 > >> ************************************* > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/d5daa838/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 124 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Tue Jul 21 11:20:51 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Tue, 21 Jul 2026 13:20:51 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 126 In-Reply-To: References: Message-ID: Dear Jordi, Thank you for your response. I agree that simply repeating an argument does not, by itself, justify revisiting consensus. However, I believe the concern being raised is not repetition for its own sake. It is whether the proposal has demonstrated the necessity of using a policy mechanism rather than an operational one. I also agree that a policy does not have to create harm to be questioned. At the same time, policy should generally exist because it provides a clear benefit that cannot reasonably be achieved through a less prescriptive mechanism. My understanding is that Last Call is an opportunity for the community to determine whether any aspect of a proposal has not been sufficiently justified before it is recommended for ratification. In my view, the choice of mechanism remains one such aspect. I appreciate your explanation of the procedural perspective, even though we may differ on whether this concern has been fully addressed. Kind regards, Fundiswa On Tue, 21 Jul 2026, 13:19 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: RPD Digest, Vol 222, Issue 122 (Taye Medoye) > 2. Re: RPD Digest, Vol 222, Issue 124 (Nia Petronella) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2026 13:16:30 +0200 > From: Taye Medoye > To: rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 122 > Message-ID: > kSBazfyhWoAq5AgKzR9RWFk0wkNMV+g at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear All, > > I think the clarification made by Fundiswa regarding the seemingly fluid > interconnection between the stage of consensus and Last Call in reaching a > policy statement suffices. It is understood that if, at the point of Last > Call on a policy proposal process, there arises an intervening factor, the > need for a further review can be allowed. > > Besides, l have taken note of the relevance of the possible effect of > diversities in the different Registries on the development of policy action > on any subject-matter for consideration. And l think this should be > accorded the recognition it deserves. > > Therefore, l align with the perspective as suggested by Fundiswa, and hope > for an understanding of the Community participants on the same. > > Taye Medoye. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/359c5247/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Tue, 21 Jul 2026 13:18:25 +0200 > From: Nia Petronella > To: rpd at afrinic.net, jordi.palet at consulintel.es > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 124 > Message-ID: > < > CA+mDOg07VG92t_JQUKjAbmSCYWcKXfnOa4KTFU5q6DwkSOaaxg at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Jordi, > > You are answering whether policy is procedurally permitted. That is not the > question being raised. > > The fact that the bylaws and PDP allow a policy does not prove that policy > is necessary, proportionate, or the best instrument. Likewise, the absence > of a staff statement saying ?policy is not needed? is not evidence that it > is needed. Silence cannot manufacture necessity. > > Kone?s examples remain relevant because they show that the same technical > outcome can be achieved operationally. The unanswered question is what > binding policy adds beyond rigidity and registry enforcement. > > A procedural route does not justify itself merely because it is familiar. > That is how process becomes mandate: the PDP permits policy, therefore > policy is treated as necessary, and the resulting enforcement is then > called community authority. > > Last Call exists precisely to test unresolved concerns, including the > choice of instrument. Consensus is not protected by declaring that it was > already reached before those concerns were answered. > > I therefore support Kone?s questions and remain opposed to the policy > route. > > Regards, > Nonhlanhla > > > > On Tue, 21 Jul 2026, 1:05 pm wrote: > > > Send RPD mailing list submissions to > > rpd at afrinic.net > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.afrinic.net/mailman/listinfo/rpd > > or, via email, send a message with subject or body 'help' to > > rpd-request at afrinic.net > > > > You can reach the person managing the list at > > rpd-owner at afrinic.net > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of RPD digest..." > > > > > > Today's Topics: > > > > 1. Re: RPD Digest, Vol 222, Issue 122 (jordi.palet at consulintel.es) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 21 Jul 2026 13:03:53 +0200 > > From: "jordi.palet at consulintel.es" > > To: rpd at afrinic.net > > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 122 > > Message-ID: <3071913E-7C72-49BC-BEDD-B7F26DE20A96 at consulintel.es> > > Content-Type: text/plain; charset="utf-8" > > > > Well ? that?s incorrect. Nobody in the community, neither the staff > impact > > assessment, said that a policy is not needed and many folks already > > contested several times, that doing it by means of a policy is valid > > according to the bylaws and PDP and it has not been demonstrated by > > objections that following this path, with is the most regular one in > > AFRINIC, creates any harm or problem. > > > > So repeating the argument, by many folks, many times, doesn?t demonstrate > > ?per se" that it is a valid objection to revert the already reached > > consensus. Of course, this is a decision that need to be taken by PDP > > chairs, but this is my view point from an exclusive ?procedural? basis. > > > > Regards, > > Jordi > > > > @jordipalet > > > > > El 21 jul 2026, a las 12:46, Fundiswa Nadia Maseko < > > fundiswanadia2 at gmail.com> escribi?: > > > > > > Dear Jordi, > > > > > > Thank you for your clarification. > > > > > > I understand your point that the proposal has already reached consensus > > and that Last Call is intended to identify any weaknesses that may have > > been overlooked. > > > > > > My concern is precisely that if the choice of mechanism was not > > sufficiently examined during the earlier discussions, then it remains a > > valid point to raise during Last Call. If a proposal introduces policy > > where an operational approach could achieve the same objective, that > > affects whether policy is the appropriate solution in the first place. > > > > > > I appreciate that consensus was declared, but consensus does not > prevent > > the community from identifying a concern that may not have received > enough > > attention. Last Call exists to give the community one final opportunity > to > > do exactly that. > > > > > > > > > Kind regards, > > > > > > Fundiswa > > > > > > On Tue, 21 Jul 2026, 12:30 , > rpd-request at afrinic.net>> wrote: > > >> Send RPD mailing list submissions to > > >> rpd at afrinic.net > > >> > > >> To subscribe or unsubscribe via the World Wide Web, visit > > >> https://lists.afrinic.net/mailman/listinfo/rpd > > >> or, via email, send a message with subject or body 'help' to > > >> rpd-request at afrinic.net > > >> > > >> You can reach the person managing the list at > > >> rpd-owner at afrinic.net > > >> > > >> When replying, please edit your Subject line so it is more specific > > >> than "Re: Contents of RPD digest..." > > >> > > >> > > >> Today's Topics: > > >> > > >> 1. Re: RPD Digest, Vol 222, Issue 119 (jordi.palet at consulintel.es > > ) > > >> > > >> > > >> ---------------------------------------------------------------------- > > >> > > >> Message: 1 > > >> Date: Tue, 21 Jul 2026 12:29:07 +0200 > > >> From: "jordi.palet at consulintel.es >" > > > > > >> To: rpd at afrinic.net > > >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 119 > > >> Message-ID: > > > > >> Content-Type: text/plain; charset="utf-8" > > >> > > >> Hi Fundiswa, > > >> > > >> Is not a matter of what is practical and what not. > > >> > > >> It is a matter that, during the discussion of the policy proposal > > (which is not the same as the Last Call), the community reached consensus > > on making it this way. RIRs follow the same procedures for reaching > > consensus as IETF, this has been said several times. The Last Call is a > > last opportunity to discover any weak point in a proposal that already > > reached consensus, and was OVERLOOKED before. Is not about discussing if > > the proposal should be a proposal or an operational decision. This is no > > longer the moment to discuss that (it should have done when the proposal > > was being discussed before reaching consensus), and many folks in this > > discussing are ignoring that, probably because they are not used to IETF > > procedures. > > >> > > >> Otherwise, you can remain silent during the proposal discussion, > during > > the presentation in the PPM and object to it after reached consensus, > which > > is an incorrect procedure. > > >> > > >> One more example: we could have asked AFRINIC many years ago to write > > the Soft Landing as an operational thing, instead we as a community, > > decided to make it a policy proposal. Same here. However, the community > > decided to do it as a proposal and it was accepted that way at the right > > time, not in the Last Call. > > >> > > >> By the way, I love cooking so from time to time follow some > > documentaries about that. Are you the same person as the famous chef? I > > think I saw you in a TV program some months ago or I?m confused. > > >> > > >> Regards, > > >> Jordi > > >> > > >> @jordipalet > > >> > > >> > El 21 jul 2026, a las 12:03, Fundiswa Nadia Maseko < > > fundiswanadia2 at gmail.com > escribi?: > > >> > > > >> > Dear Jordi, > > >> > > > >> > Thank you for your response. > > >> > > > >> > I agree that AFRINIC is not required to follow the same approach as > > other RIRs. Every region should make decisions that suit its own > community. > > >> > > > >> > My point, however, is slightly different. I wasn't suggesting that > > AFRINIC should copy another RIR simply because they did it that way. > > >> > > > >> > Rather, I'm asking what specific problem is solved by making this a > > policy instead of implementing it operationally. If both approaches > achieve > > the same technical outcome, then what additional value does the policy > > itself provide? > > >> > > > >> > I think that's an important distinction. The fact that the community > > can choose policy doesn't necessarily mean policy is the most appropriate > > mechanism in every case. > > >> > > > >> > I'd be interested to hear what practical or technical benefit you > > believe is only possible through policy and not through an operational > > implementation. > > >> > > > >> > Kind regards, > > >> > > > >> > Fundiswa > > >> > > > >> > > > >> > > > >> > On Tue, 21 Jul 2026, 11:57 , > rpd-request at afrinic.net> > rpd-request at afrinic.net>>> wrote: > > >> >> Send RPD mailing list submissions to > > >> >> rpd at afrinic.net > rpd at afrinic.net > > > >> >> > > >> >> To subscribe or unsubscribe via the World Wide Web, visit > > >> >> https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> or, via email, send a message with subject or body 'help' to > > >> >> rpd-request at afrinic.net > > > > > >> >> > > >> >> You can reach the person managing the list at > > >> >> rpd-owner at afrinic.net > > > > > >> >> > > >> >> When replying, please edit your Subject line so it is more specific > > >> >> than "Re: Contents of RPD digest..." > > >> >> > > >> >> > > >> >> Today's Topics: > > >> >> > > >> >> 1. Re: RPD Digest, Vol 222, Issue 111 (Nia Petronella) > > >> >> > > >> >> > > >> >> > > ---------------------------------------------------------------------- > > >> >> > > >> >> Message: 1 > > >> >> Date: Tue, 21 Jul 2026 11:56:49 +0200 > > >> >> From: Nia Petronella > nonhlanhlapetronella85 at gmail.com> nonhlanhlapetronella85 at gmail.com > > >> > > >> >> To: Andrew Alston > aa at alstonnetworks.net> > aa at alstonnetworks.net>>> > > >> >> Cc: rpd at afrinic.net rpd at afrinic.net > > > > > >> >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 111 > > >> >> Message-ID: > > >> >> > itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com > itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com> > itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com > itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com>>> > > >> >> Content-Type: text/plain; charset="utf-8" > > >> >> > > >> >> Dear Andrew, > > >> >> > > >> >> I do not accept the binary you have presented. > > >> >> > > >> >> No one is suggesting that AFRINIC should make operational changes > in > > secret > > >> >> or without community input. An operational change can be published, > > >> >> consulted on, tested, documented, and reviewed. The real question > is > > >> >> whether that input must be converted into binding policy enforced > by > > the > > >> >> registry. > > >> >> > > >> >> Calling AFRINIC ?community-driven? does not answer who the > community > > is or > > >> >> what it is authorised to bind. A self-selecting group of > mailing-list > > >> >> participants can provide expertise, support, and objection. It does > > not > > >> >> automatically represent every member, resource holder, network, > > customer, > > >> >> or other affected party. > > >> >> > > >> >> The institutional reality also remains unchanged: participants > > discuss the > > >> >> policy, but AFRINIC interprets and enforces it. Community > > participation > > >> >> therefore does not eliminate registry power. It can become the > > language > > >> >> used to legitimise that power. > > >> >> > > >> >> This is why Kone?s examples matter. If LACNIC, RIPE NCC, and ARIN > can > > >> >> achieve the same technical outcome through operational mechanisms, > > then > > >> >> policy is not technically inevitable. Proponents should explain > what > > >> >> additional technical result binding policy provides, beyond > > converting an > > >> >> IRR setting into an enforceable obligation. > > >> >> > > >> >> I also disagree that an objection is valid only if it proves > > immediate > > >> >> operational harm or implementation failure. The choice of > instrument, > > >> >> proportionality, reversibility, and expansion of enforcement > > authority are > > >> >> legitimate policy concerns. Last Call is not limited to asking > > whether > > >> >> software will break. It must also ask whether the proposed power is > > greater > > >> >> than the problem requires. > > >> >> > > >> >> Rough consensus does not require every objection to be > accommodated. > > But an > > >> >> objection is not ?addressed? merely because supporters repeat that > > the > > >> >> community prefers policy. That is the very assumption being > > challenged. > > >> >> Procedure cannot be used to prove its own mandate. > > >> >> > > >> >> The fact that the RIR system has operated this way for decades > > demonstrates > > >> >> continuity of practice. It does not establish unlimited legitimacy > > of scope. > > >> >> > > >> >> I support Kone?s questions and remain opposed to > > AFPUB-2026-ASN-001-DRAFT02. > > >> >> > > >> >> Regards, > > >> >> Nonhlanhla > > >> >> > > >> >> > > >> >> > > >> >> On Tue, 21 Jul 2026, 10:26 am Andrew Alston > > aa at alstonnetworks.net>>> wrote: > > >> >> > > >> >> > The answer to this is simple. AfriNiC is a community driven > > organisation > > >> >> > - and anything done with regard to address allocation and > > management is > > >> >> > done as per policy provided by the community. It is through > > policy that > > >> >> > the community tells AfriNIC how to do things in regards to the > > allocation > > >> >> > and handling of resources. > > >> >> > > > >> >> > Without policy, the discretion and rules are entirely in the > hands > > of the > > >> >> > registry, and the community voice is removed. > > >> >> > > > >> >> > This has been the way the RIR system has operated for decades > and > > it > > >> >> > works. The community exercises its voice and its right as to how > > things > > >> >> > are done in relation to resource management through policy. > > >> >> > > > >> >> > Arguing that just because something can be done another way, is > > not in my > > >> >> > view a valid argument against policy. Objections to policy need > > to be > > >> >> > technically grounded and demonstrate that the policy would either > > cause > > >> >> > harm or alternatively be impractical to implement. Anything else > > is simply > > >> >> > arguing that policy should not exist because someone doesn?t like > > AfriNIC > > >> >> > being told how the community wants things done - and that isn?t > an > > argument > > >> >> > that I believe rises to the level of a block on consensus. > > >> >> > > > >> >> > Please note - consensus does not require that the issue you raise > > have > > >> >> > been fixed, it requires that they have been addressed, and should > > the > > >> >> > community feel that despite the objections, the policy is > > something that > > >> >> > should proceed based on the fact that the questions have been > > addressed if > > >> >> > not necessarily accommodated, rough consensus still exists. > > >> >> > > > >> >> > Again, I support the policy and I see no technical or > > evidence/fact-based > > >> >> > arguments against said policy. > > >> >> > > > >> >> > Andrew > > >> >> > > > >> >> > On Tue, Jul 21, 2026 at 09:34, Nia Petronella < > > >> >> > nonhlanhlapetronella85 at gmail.com > nonhlanhlapetronella85 at gmail.com> nonhlanhlapetronella85 at gmail.com > > >> wrote: > > >> >> > > > >> >> >> Dear PDWG, > > >> >> >> > > >> >> >> Kone is asking the right question. > > >> >> >> > > >> >> >> The issue is no longer whether hierarchical AS-SET naming is > > technically > > >> >> >> possible or useful. It already exists. The issue is why AFRINIC > > needs a > > >> >> >> binding policy to enforce what other RIRs largely treat as an > > operational > > >> >> >> IRR matter. > > >> >> >> > > >> >> >> That distinction matters. An operational change adjusts how a > > service is > > >> >> >> implemented. A policy creates an enforceable obligation and > > enlarges the > > >> >> >> registry?s authority. If the same technical result can be > > achieved through > > >> >> >> a community-reviewed implementation plan, then policy is not the > > minimum > > >> >> >> necessary instrument. > > >> >> >> > > >> >> >> Saying that ?the community prefers policy? is not enough. > > Participation > > >> >> >> may guide technical work, but it does not turn every preference > > into a > > >> >> >> mandate. A mailing list is not a legislature, and the > > availability of the > > >> >> >> PDP should not make policy the default answer to every > > operational setting. > > >> >> >> > > >> >> >> This is how gatekeeping expands: the registry begins with a > useful > > >> >> >> technical function, then policy converts that function into > > permission and > > >> >> >> enforcement. The recordkeeper gradually becomes the rule-maker. > > >> >> >> > > >> >> >> The proponents should therefore answer Kone directly: what > > technical > > >> >> >> outcome can mandatory policy achieve here that an operational > > >> >> >> implementation cannot? > > >> >> >> > > >> >> >> Until that is clearly demonstrated, I support Kone?s questions > > and remain > > >> >> >> opposed to the policy route. > > >> >> >> > > >> >> >> Regards, > > >> >> >> Nonhlanhla > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> On Tue, 21 Jul 2026, 8:20 am > rpd-request at afrinic.net> > rpd-request at afrinic.net>>> wrote: > > >> >> >> > > >> >> >>> Send RPD mailing list submissions to > > >> >> >>> rpd at afrinic.net > rpd at afrinic.net > > > >> >> >>> > > >> >> >>> To subscribe or unsubscribe via the World Wide Web, visit > > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> >>> or, via email, send a message with subject or body 'help' to > > >> >> >>> rpd-request at afrinic.net rpd-request at afrinic.net> > > > > > >> >> >>> > > >> >> >>> You can reach the person managing the list at > > >> >> >>> rpd-owner at afrinic.net > > > > > >> >> >>> > > >> >> >>> When replying, please edit your Subject line so it is more > > specific > > >> >> >>> than "Re: Contents of RPD digest..." > > >> >> >>> > > >> >> >>> > > >> >> >>> Today's Topics: > > >> >> >>> > > >> >> >>> 1. Re: RPD Digest, Vol 222, Issue 110 (Tshepo Masuku) > > >> >> >>> > > >> >> >>> > > >> >> >>> > > ---------------------------------------------------------------------- > > >> >> >>> > > >> >> >>> Message: 1 > > >> >> >>> Date: Tue, 21 Jul 2026 06:19:05 +0000 > > >> >> >>> From: Tshepo Masuku > TshepoMasuku26 at hotmail.com> > TshepoMasuku26 at hotmail.com>>> > > >> >> >>> To: "rpd at afrinic.net > rpd at afrinic.net >" > rpd at afrinic.net> >> > > >> >> >>> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 110 > > >> >> >>> Message-ID: > > >> >> >>> < > > >> >> >>> > > > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > > > > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > > > > > > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > > > > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > > >> > > >> >> >>> > > > >> >> >>> > > >> >> >>> Content-Type: text/plain; charset="windows-1252" > > >> >> >>> > > >> >> >>> Dear All, > > >> >> >>> > > >> >> >>> Kone?s point is directly relevant. If LACNIC, RIPE NCC, and > ARIN > > can > > >> >> >>> implement hierarchical AS-SET naming through operational > > mechanisms, then > > >> >> >>> proponents must explain why AFRINIC needs a binding policy to > > achieve the > > >> >> >>> same technical result. > > >> >> >>> > > >> >> >>> Saying that each RIR works differently does not answer that > > question. > > >> >> >>> Nor does saying that ?the community is on top of the RIR.? A > > community may > > >> >> >>> advise, object, and coordinate. It does not acquire unlimited > > authority to > > >> >> >>> convert every operational preference into policy. A mailing > list > > is not a > > >> >> >>> legislature. > > >> >> >>> > > >> >> >>> If AFRINIC can solve this through an operational change, policy > > adds > > >> >> >>> governance where technical administration would be sufficient. > > Speed and > > >> >> >>> preference do not create mandate. > > >> >> >>> > > >> >> >>> Kone provided specific examples. Those should be answered with > > evidence, > > >> >> >>> not by questioning whether he has worked in every RIR for many > > years. > > >> >> >>> Experience is relevant, but it is not authority and it is not a > > substitute > > >> >> >>> for argument. > > >> >> >>> > > >> >> >>> The unanswered question remains: what technical necessity > > requires > > >> >> >>> policy rather than operational implementation? > > >> >> >>> > > >> >> >>> Until that is answered, Kone?s objection stands, and I support > > it. > > >> >> >>> > > >> >> >>> Regards, > > >> >> >>> Tshepo > > >> >> >>> > > >> >> >>> > > >> >> >>> ________________________________ > > >> >> >>> From: rpd-request at afrinic.net > > > < > > rpd-request at afrinic.net > rpd-request at afrinic.net >> > > >> >> >>> Sent: Monday, July 20, 2026 11:10:57 pm > > >> >> >>> To: rpd at afrinic.net > rpd at afrinic.net > > rpd at afrinic.net> >> > > >> >> >>> Subject: RPD Digest, Vol 222, Issue 110 > > >> >> >>> > > >> >> >>> Send RPD mailing list submissions to > > >> >> >>> rpd at afrinic.net > rpd at afrinic.net > > > >> >> >>> > > >> >> >>> To subscribe or unsubscribe via the World Wide Web, visit > > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> >>> or, via email, send a message with subject or body 'help' to > > >> >> >>> rpd-request at afrinic.net rpd-request at afrinic.net> > > > > > >> >> >>> > > >> >> >>> You can reach the person managing the list at > > >> >> >>> rpd-owner at afrinic.net > > > > > >> >> >>> > > >> >> >>> When replying, please edit your Subject line so it is more > > specific > > >> >> >>> than "Re: Contents of RPD digest..." > > >> >> >>> > > >> >> >>> > > >> >> >>> Today's Topics: > > >> >> >>> > > >> >> >>> 1. Re: Writing tools (Ben Roberts - AfriNIC) > > >> >> >>> 2. Re: [Last Call] Draft Policy Proposal - Hierarchical > Names > > >> >> >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Kone) > > >> >> >>> 3. Re: [Last Call] Draft Policy Proposal - Hierarchical > Names > > >> >> >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > >> >> >>> (jordi.palet at consulintel.es > jordi.palet at consulintel.es> > jordi.palet at consulintel.es>>) > > >> >> >>> > > >> >> >>> > > >> >> >>> > > ---------------------------------------------------------------------- > > >> >> >>> > > >> >> >>> Message: 1 > > >> >> >>> Date: Mon, 20 Jul 2026 21:26:40 +0200 > > >> >> >>> From: Ben Roberts - AfriNIC > ben.roberts at afrinic.net> > ben.roberts at afrinic.net>>> > > >> >> >>> To: Nonjabulo Sphilile > nonjabulosphilile at gmail.com> > nonjabulosphilile at gmail.com>>> > > >> >> >>> Cc: rpd at afrinic.net > rpd at afrinic.net > > > >> >> >>> Subject: Re: [rpd] Writing tools > > >> >> >>> Message-ID: <09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net > > > 09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net > 09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net>>> > > >> >> >>> Content-Type: text/plain; charset="us-ascii" > > >> >> >>> > > >> >> >>> An HTML attachment was scrubbed... > > >> >> >>> URL: < > > >> >> >>> > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/33c3ac9e/attachment-0001.html > > >> >> >>> > > > >> >> >>> > > >> >> >>> ------------------------------ > > >> >> >>> > > >> >> >>> Message: 2 > > >> >> >>> Date: Mon, 20 Jul 2026 20:34:20 +0000 > > >> >> >>> From: Kone > bakenon.kone at sancfis.net> > bakenon.kone at sancfis.net>>> > > >> >> >>> To: Seun Ojedeji > seun.ojedeji at gmail.com> > seun.ojedeji at gmail.com>>> > > >> >> >>> Cc: rpd > rpd at afrinic.net >> > > >> >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - > > Hierarchical > > >> >> >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > >> >> >>> Message-ID: > > >> >> >>> > >> >> >>> 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com > 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com> > 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com > 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com>>> > > >> >> >>> Content-Type: text/plain; charset="utf-8" > > >> >> >>> > > >> >> >>> Hello Seun, > > >> >> >>> You may have misread my earlier mail. I clearly stated that > > LACNIC, RIPE > > >> >> >>> NCC, and ARIN do not require policy to enforce hierarchical > > AS?SET > > >> >> >>> naming. > > >> >> >>> > > >> >> >>> To help close the ongoing discussions, I believe addressing the > > >> >> >>> questions I > > >> >> >>> raised would bring clarity: > > >> >> >>> * LACNIC enforces hierarchical AS?SET naming operationally, as > > part of > > >> >> >>> their IRR design from inception. > > >> >> >>> * RIPE NCC handles IRR changes through their Numbered Work > Items > > (NWI) > > >> >> >>> process, not through policy. > > >> >> >>> * ARIN uses the ACSP (Consultation and Suggestion Process) for > > IRR > > >> >> >>> operational matters, again without policy. > > >> >> >>> > > >> >> >>> > > >> >> >>> These examples show that other RIRs (except APNIC) treat AS?SET > > naming as > > >> >> >>> an operational IRR matter, not a policy obligation. > > >> >> >>> > > >> >> >>> This is why I asked whether AFRINIC could address this > > operationally > > >> >> >>> rather > > >> >> >>> than through policy, and why Last Call discussions would > benefit > > from > > >> >> >>> clear > > >> >> >>> answers to these points. > > >> >> >>> > > >> >> >>> Thanks. > > >> >> >>> --- > > >> >> >>> Kone > > >> >> >>> > > >> >> >>> > > >> >> >>> > > >> >> >>> Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji < > > seun.ojedeji at gmail.com > seun.ojedeji at gmail.com >> a > > >> >> >>> ?crit : > > >> >> >>> > > >> >> >>> > Hello Bakenon, > > >> >> >>> > > > >> >> >>> > Do refer to the proposal as it references URL to other RIR's > > policies > > >> >> >>> for > > >> >> >>> > thiis: > > >> >> >>> > > > >> >> >>> > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > >> >> >>> > > > >> >> >>> > Regards > > >> >> >>> > > > >> >> >>> > ---- > > >> >> >>> > Sent from my mobile > > >> >> >>> > kindly excuse typos > > >> >> >>> > > > >> >> >>> > On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, < > > bakenon.kone at sancfis.net > bakenon.kone at sancfis.net >> > > >> >> >>> > wrote: > > >> >> >>> > > > >> >> >>> >> Dear PDWG, > > >> >> >>> >> > > >> >> >>> >> I have been following the discussions on the hierarchical > > AS?SET > > >> >> >>> naming > > >> >> >>> >> scheme and would like clarification on a few points: > > >> >> >>> >> > > >> >> >>> >> 1. Could this matter be addressed operationally, as is done > > in ARIN, > > >> >> >>> >> LACNIC, and RIPE NCC, without requiring policy changes? > > >> >> >>> >> > > >> >> >>> >> 2. If yes, why are we taking the policy route? Is it because > > AFRINIC > > >> >> >>> >> currently lacks a defined process for handling operational > > issues that > > >> >> >>> >> affect IRR services? > > >> >> >>> >> > > >> >> >>> >> 3. Given that the hierarchical naming scheme is already > > supported and > > >> >> >>> >> currently exists within the IRR, this proposal represents an > > >> >> >>> enforcement > > >> >> >>> >> change rather than the introduction of a new technical > > standard. Why > > >> >> >>> is a > > >> >> >>> >> formal policy required to change an operational enforcement > > setting, > > >> >> >>> rather > > >> >> >>> >> than a community-vetted technical implementation plan?" > > >> >> >>> >> > > >> >> >>> >> Thank you. > > >> >> >>> >> --- > > >> >> >>> >> Kone > > >> >> >>> >> > > >> >> >>> >> > > >> >> >>> >> > > >> >> >>> >> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal < > > hytham at tra.gov.eg > >> a > > >> >> >>> >> ?crit : > > >> >> >>> >> > > >> >> >>> >>> Dear PDWG, > > >> >> >>> >>> > > >> >> >>> >>> > > >> >> >>> >>> The Policy Development Working Group (PDWG) Chairs have > > initiated a > > >> >> >>> Last > > >> >> >>> >>> Call for this proposal, following rough consensus at the > > AFRINIC-37 > > >> >> >>> Public > > >> >> >>> >>> Policy Meeting held in hybrid format in Nairobi, Kenya on > 24 > > June > > >> >> >>> 2026. > > >> >> >>> >>> > > >> >> >>> >>> * Proposal Name: Hierarchical Names for New AS-SETs > > >> >> >>> >>> > > >> >> >>> >>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > > >> >> >>> >>> > > >> >> >>> >>> * Proposal URL: > > >> >> >>> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > >> >> >>> >>> > > >> >> >>> >>> Last Call closes on: July 31, 2026, at 23:59 UTC. > > >> >> >>> >>> > > >> >> >>> >>> > > >> >> >>> >>> 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. > > >> >> >>> >>> > > >> >> >>> >>> > > >> >> >>> >>> As always, we kindly request that all participants adhere > to > > the > > >> >> >>> AFRINIC > > >> >> >>> >>> Code of Conduct to maintain > a > > >> >> >>> respectful > > >> >> >>> >>> and professional environment on the mailing list. > > >> >> >>> >>> > > >> >> >>> >>> > > >> >> >>> >>> Kind regards, > > >> >> >>> >>> > > >> >> >>> >>> > > >> >> >>> >>> Haitham el Nakhal > > >> >> >>> >>> > > >> >> >>> >>> AFRINIC PDWG Co-Chair > > >> >> >>> >>> > > >> >> >>> >>> > > >> >> >>> >>> > > >> >> >>> >>> _______________________________________________ > > >> >> >>> >>> RPD mailing list > > >> >> >>> >>> RPD at afrinic.net > RPD at afrinic.net > > > >> >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> >>> >>> > > >> >> >>> >> _______________________________________________ > > >> >> >>> >> RPD mailing list > > >> >> >>> >> RPD at afrinic.net > RPD at afrinic.net > > > >> >> >>> >> https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> >>> >> > > >> >> >>> > > > >> >> >>> -------------- next part -------------- > > >> >> >>> An HTML attachment was scrubbed... > > >> >> >>> URL: < > > >> >> >>> > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/4563e1d5/attachment-0001.html > > >> >> >>> > > > >> >> >>> > > >> >> >>> ------------------------------ > > >> >> >>> > > >> >> >>> Message: 3 > > >> >> >>> Date: Mon, 20 Jul 2026 23:10:04 +0200 > > >> >> >>> From: "jordi.palet at consulintel.es > jordi.palet at consulintel.es> > jordi.palet at consulintel.es>>" > jordi.palet at consulintel.es> > jordi.palet at consulintel.es>>> > > >> >> >>> To: rpd > rpd at afrinic.net >> > > >> >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - > > Hierarchical > > >> >> >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > >> >> >>> Message-ID: < > F22A09CF-A827-4D7F-B077-E0B9C774AF00 at consulintel.es > > > F22A09CF-A827-4D7F-B077-E0B9C774AF00 at consulintel.es > F22A09CF-A827-4D7F-B077-E0B9C774AF00 at consulintel.es>>> > > >> >> >>> Content-Type: text/plain; charset="utf-8" > > >> >> >>> > > >> >> >>> Hi Kone, > > >> >> >>> > > >> >> >>> And what is the relevance of that? > > >> >> >>> > > >> >> >>> If you have a good understanding about all the RIRs, you will > > know that > > >> >> >>> each RIR has their own ways to do things. In many senses they > > act very > > >> >> >>> similarly and in general we end up with very similarly > policies, > > but not > > >> >> >>> always. Some RIRs have decided that some aspects are > operational > > and don?t > > >> >> >>> need a policy proposal. > > >> >> >>> > > >> >> >>> However, despite that, the community is on top of the RIR, and > > the > > >> >> >>> community sometimes, may decide that they prefer a policy if > the > > RIR hasn?t > > >> >> >>> been proactive in advance in any specific topic, or even if the > > RIR was > > >> >> >>> proactive, the community may prefer to speed up things, or to > > show the way > > >> >> >>> the community prefers. > > >> >> >>> > > >> >> >>> For example, if AFRINIC has any specific operational aspect > > already in > > >> >> >>> place, and the community prefer to manage that in a different > > way, the > > >> >> >>> community may opt either for suggesting the RIR to modify that > > operational > > >> >> >>> aspect or to do actually enforce it by means of a policy > > proposal. > > >> >> >>> > > >> >> >>> I think is important to know, by personal experience, how the > > other 4 > > >> >> >>> RIRs work before stating something that is not correct, because > > if you > > >> >> >>> don?t work in all the RIRs for many years, it will be difficult > > for you to > > >> >> >>> know the past and I?m sure IA will not be able to be precise as > > well. > > >> >> >>> > > >> >> >>> Regards, > > >> >> >>> Jordi > > >> >> >>> > > >> >> >>> @jordipalet > > >> >> >>> > > >> >> >>> > El 20 jul 2026, a las 22:34, Kone > > >> escribi?: > > >> >> >>> > > > >> >> >>> > Hello Seun, > > >> >> >>> > You may have misread my earlier mail. I clearly stated that > > LACNIC, > > >> >> >>> RIPE NCC, and ARIN do not require policy to enforce > hierarchical > > AS?SET > > >> >> >>> naming. > > >> >> >>> > > > >> >> >>> > To help close the ongoing discussions, I believe addressing > the > > >> >> >>> questions I raised would bring clarity: > > >> >> >>> > * LACNIC enforces hierarchical AS?SET naming operationally, > as > > part of > > >> >> >>> their IRR design from inception. > > >> >> >>> > * RIPE NCC handles IRR changes through their Numbered Work > > Items (NWI) > > >> >> >>> process, not through policy. > > >> >> >>> > * ARIN uses the ACSP (Consultation and Suggestion Process) > for > > IRR > > >> >> >>> operational matters, again without policy. > > >> >> >>> > > > >> >> >>> > > > >> >> >>> > These examples show that other RIRs (except APNIC) treat > > AS?SET naming > > >> >> >>> as an operational IRR matter, not a policy obligation. > > >> >> >>> > > > >> >> >>> > This is why I asked whether AFRINIC could address this > > operationally > > >> >> >>> rather than through policy, and why Last Call discussions would > > benefit > > >> >> >>> from clear answers to these points. > > >> >> >>> > > > >> >> >>> > Thanks. > > >> >> >>> > --- > > >> >> >>> > Kone > > >> >> >>> > > > >> >> >>> > > > >> >> >>> > > > >> >> >>> > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji < > > seun.ojedeji at gmail.com > seun.ojedeji at gmail.com > > > >> >> >>> > > >>> a > ?crit > > : > > >> >> >>> >> Hello Bakenon, > > >> >> >>> >> > > >> >> >>> >> Do refer to the proposal as it references URL to other RIR's > > policies > > >> >> >>> for thiis: > > >> >> >>> >> > > >> >> >>> >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > >> >> >>> >> > > >> >> >>> >> Regards > > >> >> >>> >> > > >> >> >>> >> ---- > > >> >> >>> >> Sent from my mobile > > >> >> >>> >> kindly excuse typos > > >> >> >>> >> > > >> >> >>> >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, < > > bakenon.kone at sancfis.net > bakenon.kone at sancfis.net > > > >> >> >>> > bakenon.kone at sancfis.net> > bakenon.kone at sancfis.net>>>> wrote: > > >> >> >>> >>> Dear PDWG, > > >> >> >>> >>> > > >> >> >>> >>> I have been following the discussions on the hierarchical > > AS?SET > > >> >> >>> naming scheme and would like clarification on a few points: > > >> >> >>> >>> > > >> >> >>> >>> 1. Could this matter be addressed operationally, as is done > > in ARIN, > > >> >> >>> LACNIC, and RIPE NCC, without requiring policy changes? > > >> >> >>> >>> > > >> >> >>> >>> 2. If yes, why are we taking the policy route? Is it > because > > AFRINIC > > >> >> >>> currently lacks a defined process for handling operational > > issues that > > >> >> >>> affect IRR services? > > >> >> >>> >>> > > >> >> >>> >>> 3. Given that the hierarchical naming scheme is already > > supported > > >> >> >>> and currently exists within the IRR, this proposal represents > an > > >> >> >>> enforcement change rather than the introduction of a new > > technical > > >> >> >>> standard. Why is a formal policy required to change an > > operational > > >> >> >>> enforcement setting, rather than a community-vetted technical > > >> >> >>> implementation plan?" > > >> >> >>> >>> > > >> >> >>> >>> Thank you. > > >> >> >>> >>> --- > > >> >> >>> >>> Kone > > >> >> >>> >>> > > >> >> >>> >>> > > >> >> >>> >>> > > >> >> >>> >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal < > > hytham at tra.gov.eg > > > > >> >> >>> > hytham at tra.gov.eg >>> a ?crit : > > >> >> >>> >>>> Dear PDWG, > > >> >> >>> >>>> > > >> >> >>> >>>> > > >> >> >>> >>>> The Policy Development Working Group (PDWG) Chairs have > > initiated a > > >> >> >>> Last Call for this proposal, following rough consensus at the > > AFRINIC-37 > > >> >> >>> Public Policy Meeting held in hybrid format in Nairobi, Kenya > on > > 24 June > > >> >> >>> 2026. > > >> >> >>> >>>> > > >> >> >>> >>>> * Proposal Name: Hierarchical Names for New AS-SETs > > >> >> >>> >>>> > > >> >> >>> >>>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > > >> >> >>> >>>> > > >> >> >>> >>>> * Proposal URL: > > >> >> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > >> >> >>> >>>> > > >> >> >>> >>>> Last Call closes on: July 31, 2026, at 23:59 UTC. > > >> >> >>> >>>> > > >> >> >>> >>>> > > >> >> >>> >>>> 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. > > >> >> >>> >>>> > > >> >> >>> >>>> > > >> >> >>> >>>> As always, we kindly request that all participants adhere > > to the > > >> >> >>> AFRINIC Code of Conduct to > > maintain a > > >> >> >>> respectful and professional environment on the mailing list. > > >> >> >>> >>>> > > >> >> >>> >>>> > > >> >> >>> >>>> Kind regards, > > >> >> >>> >>>> > > >> >> >>> >>>> > > >> >> >>> >>>> Haitham el Nakhal > > >> >> >>> >>>> > > >> >> >>> >>>> AFRINIC PDWG Co-Chair > > >> >> >>> >>>> > > >> >> >>> >>>> > > >> >> >>> >>>> > > >> >> >>> >>>> _______________________________________________ > > >> >> >>> >>>> RPD mailing list > > >> >> >>> >>>> RPD at afrinic.net > RPD at afrinic.net > > RPD at afrinic.net> >> > > >> >> >>> >>>> https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> >>> >>> _______________________________________________ > > >> >> >>> >>> RPD mailing list > > >> >> >>> >>> RPD at afrinic.net > RPD at afrinic.net > > RPD at afrinic.net> >> > > >> >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> >>> > _______________________________________________ > > >> >> >>> > RPD mailing list > > >> >> >>> > RPD at afrinic.net > RPD at afrinic.net > > > >> >> >>> > https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> >>> > > >> >> >>> > > >> >> >>> > > >> >> >>> ********************************************** > > >> >> >>> IPv4 is over > > >> >> >>> Are you ready for the new Internet ? > > >> >> >>> http://www.theipv6company.com > < > > http://www.theipv6company.com/> > > >> >> >>> The IPv6 Company > > >> >> >>> > > >> >> >>> This electronic message contains information which may be > > privileged or > > >> >> >>> confidential. The information is intended to be for the > > exclusive use of > > >> >> >>> the individual(s) named above and further non-explicilty > > authorized > > >> >> >>> disclosure, copying, distribution or use of the contents of > this > > >> >> >>> information, even if partially, including attached files, is > > strictly > > >> >> >>> prohibited and will be considered a criminal offense. If you > are > > not the > > >> >> >>> intended recipient be aware that any disclosure, copying, > > distribution or > > >> >> >>> use of the contents of this information, even if partially, > > including > > >> >> >>> attached files, is strictly prohibited, will be considered a > > criminal > > >> >> >>> offense, so you must reply to the original sender to inform > > about this > > >> >> >>> communication and delete it. > > >> >> >>> > > >> >> >>> -------------- next part -------------- > > >> >> >>> An HTML attachment was scrubbed... > > >> >> >>> URL: < > > >> >> >>> > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/b6777fa7/attachment.html > > >> >> >>> > > > >> >> >>> > > >> >> >>> ------------------------------ > > >> >> >>> > > >> >> >>> Subject: Digest Footer > > >> >> >>> > > >> >> >>> _______________________________________________ > > >> >> >>> RPD mailing list > > >> >> >>> RPD at afrinic.net RPD at afrinic.net > > > > > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> >>> > > >> >> >>> > > >> >> >>> ------------------------------ > > >> >> >>> > > >> >> >>> End of RPD Digest, Vol 222, Issue 110 > > >> >> >>> ************************************* > > >> >> >>> > > >> >> >>> -------------- next part -------------- > > >> >> >>> An HTML attachment was scrubbed... > > >> >> >>> URL: < > > >> >> >>> > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e492c668/attachment.html > > >> >> >>> > > > >> >> >>> > > >> >> >>> ------------------------------ > > >> >> >>> > > >> >> >>> Subject: Digest Footer > > >> >> >>> > > >> >> >>> _______________________________________________ > > >> >> >>> RPD mailing list > > >> >> >>> RPD at afrinic.net RPD at afrinic.net > > > > > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> >>> > > >> >> >>> > > >> >> >>> ------------------------------ > > >> >> >>> > > >> >> >>> End of RPD Digest, Vol 222, Issue 111 > > >> >> >>> ************************************* > > >> >> >>> > > >> >> >> _______________________________________________ > > >> >> >> RPD mailing list > > >> >> >> RPD at afrinic.net RPD at afrinic.net > > > > > >> >> >> https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> >> > > >> >> > > > >> >> -------------- next part -------------- > > >> >> An HTML attachment was scrubbed... > > >> >> URL: < > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/9c41424a/attachment.html > > > > > >> >> > > >> >> ------------------------------ > > >> >> > > >> >> Subject: Digest Footer > > >> >> > > >> >> _______________________________________________ > > >> >> RPD mailing list > > >> >> RPD at afrinic.net > > > > >> >> https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> > > >> >> > > >> >> ------------------------------ > > >> >> > > >> >> End of RPD Digest, Vol 222, Issue 119 > > >> >> ************************************* > > >> > _______________________________________________ > > >> > RPD mailing list > > >> > RPD at afrinic.net > > >> > https://lists.afrinic.net/mailman/listinfo/rpd > > >> > > >> > > >> > > >> ********************************************** > > >> IPv4 is over > > >> Are you ready for the new Internet ? > > >> http://www.theipv6company.com > > >> The IPv6 Company > > >> > > >> This electronic message contains information which may be privileged > or > > confidential. The information is intended to be for the exclusive use of > > the individual(s) named above and further non-explicilty authorized > > disclosure, copying, distribution or use of the contents of this > > information, even if partially, including attached files, is strictly > > prohibited and will be considered a criminal offense. If you are not the > > intended recipient be aware that any disclosure, copying, distribution or > > use of the contents of this information, even if partially, including > > attached files, is strictly prohibited, will be considered a criminal > > offense, so you must reply to the original sender to inform about this > > communication and delete it. > > >> > > >> -------------- next part -------------- > > >> An HTML attachment was scrubbed... > > >> URL: < > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/0ba797a1/attachment.html > > > > > >> > > >> ------------------------------ > > >> > > >> Subject: Digest Footer > > >> > > >> _______________________________________________ > > >> RPD mailing list > > >> RPD at afrinic.net > > >> https://lists.afrinic.net/mailman/listinfo/rpd > > >> > > >> > > >> ------------------------------ > > >> > > >> End of RPD Digest, Vol 222, Issue 122 > > >> ************************************* > > > _______________________________________________ > > > RPD mailing list > > > RPD at afrinic.net > > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.theipv6company.com > > The IPv6 Company > > > > This electronic message contains information which may be privileged or > > confidential. The information is intended to be for the exclusive use of > > the individual(s) named above and further non-explicilty authorized > > disclosure, copying, distribution or use of the contents of this > > information, even if partially, including attached files, is strictly > > prohibited and will be considered a criminal offense. If you are not the > > intended recipient be aware that any disclosure, copying, distribution or > > use of the contents of this information, even if partially, including > > attached files, is strictly prohibited, will be considered a criminal > > offense, so you must reply to the original sender to inform about this > > communication and delete it. > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/d5daa838/attachment.html > > > > > > > ------------------------------ > > > > Subject: Digest Footer > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > ------------------------------ > > > > End of RPD Digest, Vol 222, Issue 124 > > ************************************* > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/fe3cdcf4/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 126 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mendie5205 at gmail.com Tue Jul 21 11:26:55 2026 From: mendie5205 at gmail.com (Mendie) Date: Tue, 21 Jul 2026 13:26:55 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 127 In-Reply-To: References: Message-ID: Good day, I agree with Fundiswa's point. I do not understand her argument to be that using the PDP is prohibited by the bylaws or that repeating an objection automatically overturns rough consensus. Rather, the point is narrower: the fact that policy is procedurally available does not, by itself, establish that it is the appropriate instrument. Likewise, the fact that neither the staff assessment nor earlier participants argued that policy was unnecessary does not demonstrate that it is necessary. That question still requires a substantive justification. I also believe this concern is appropriate for Last Call. If the distinction between an operational implementation and a binding policy was not sufficiently examined before consensus was declared, then identifying that potential weakness is precisely what Last Call is intended to do. The central question therefore remains: What technical requirement can only be met through binding policy rather than a transparent, community-reviewed operational implementation? The examples from LACNIC, RIPE NCC, and ARIN are not offered to suggest AFRINIC should copy other RIRs. They simply demonstrate that an operational alternative exists. If the same technical outcome can be achieved through an open operational process, then the additional technical value of a binding policy should be clearly explained. Kind regards, On Tue, 21 Jul 2026, 13:21 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: RPD Digest, Vol 222, Issue 126 (Fundiswa Nadia Maseko) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2026 13:20:51 +0200 > From: Fundiswa Nadia Maseko > To: rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 126 > Message-ID: > < > CABV0QcSyVH-Om4eB8ZiR_RHq5Hf6uOpckQ870WPpWkAV1ej7CA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Jordi, > > Thank you for your response. > > I agree that simply repeating an argument does not, by itself, justify > revisiting consensus. > > However, I believe the concern being raised is not repetition for its own > sake. It is whether the proposal has demonstrated the necessity of using a > policy mechanism rather than an operational one. > > I also agree that a policy does not have to create harm to be questioned. > At the same time, policy should generally exist because it provides a clear > benefit that cannot reasonably be achieved through a less prescriptive > mechanism. > > My understanding is that Last Call is an opportunity for the community to > determine whether any aspect of a proposal has not been sufficiently > justified before it is recommended for ratification. In my view, the choice > of mechanism remains one such aspect. > > I appreciate your explanation of the procedural perspective, even though we > may differ on whether this concern has been fully addressed. > > Kind regards, > Fundiswa > > On Tue, 21 Jul 2026, 13:19 , wrote: > > > Send RPD mailing list submissions to > > rpd at afrinic.net > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.afrinic.net/mailman/listinfo/rpd > > or, via email, send a message with subject or body 'help' to > > rpd-request at afrinic.net > > > > You can reach the person managing the list at > > rpd-owner at afrinic.net > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of RPD digest..." > > > > > > Today's Topics: > > > > 1. Re: RPD Digest, Vol 222, Issue 122 (Taye Medoye) > > 2. Re: RPD Digest, Vol 222, Issue 124 (Nia Petronella) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 21 Jul 2026 13:16:30 +0200 > > From: Taye Medoye > > To: rpd at afrinic.net > > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 122 > > Message-ID: > > > kSBazfyhWoAq5AgKzR9RWFk0wkNMV+g at mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > Dear All, > > > > I think the clarification made by Fundiswa regarding the seemingly fluid > > interconnection between the stage of consensus and Last Call in reaching > a > > policy statement suffices. It is understood that if, at the point of Last > > Call on a policy proposal process, there arises an intervening factor, > the > > need for a further review can be allowed. > > > > Besides, l have taken note of the relevance of the possible effect of > > diversities in the different Registries on the development of policy > action > > on any subject-matter for consideration. And l think this should be > > accorded the recognition it deserves. > > > > Therefore, l align with the perspective as suggested by Fundiswa, and > hope > > for an understanding of the Community participants on the same. > > > > Taye Medoye. > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/359c5247/attachment-0001.html > > > > > > > ------------------------------ > > > > Message: 2 > > Date: Tue, 21 Jul 2026 13:18:25 +0200 > > From: Nia Petronella > > To: rpd at afrinic.net, jordi.palet at consulintel.es > > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 124 > > Message-ID: > > < > > CA+mDOg07VG92t_JQUKjAbmSCYWcKXfnOa4KTFU5q6DwkSOaaxg at mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > Dear Jordi, > > > > You are answering whether policy is procedurally permitted. That is not > the > > question being raised. > > > > The fact that the bylaws and PDP allow a policy does not prove that > policy > > is necessary, proportionate, or the best instrument. Likewise, the > absence > > of a staff statement saying ?policy is not needed? is not evidence that > it > > is needed. Silence cannot manufacture necessity. > > > > Kone?s examples remain relevant because they show that the same technical > > outcome can be achieved operationally. The unanswered question is what > > binding policy adds beyond rigidity and registry enforcement. > > > > A procedural route does not justify itself merely because it is familiar. > > That is how process becomes mandate: the PDP permits policy, therefore > > policy is treated as necessary, and the resulting enforcement is then > > called community authority. > > > > Last Call exists precisely to test unresolved concerns, including the > > choice of instrument. Consensus is not protected by declaring that it was > > already reached before those concerns were answered. > > > > I therefore support Kone?s questions and remain opposed to the policy > > route. > > > > Regards, > > Nonhlanhla > > > > > > > > On Tue, 21 Jul 2026, 1:05 pm wrote: > > > > > Send RPD mailing list submissions to > > > rpd at afrinic.net > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > https://lists.afrinic.net/mailman/listinfo/rpd > > > or, via email, send a message with subject or body 'help' to > > > rpd-request at afrinic.net > > > > > > You can reach the person managing the list at > > > rpd-owner at afrinic.net > > > > > > When replying, please edit your Subject line so it is more specific > > > than "Re: Contents of RPD digest..." > > > > > > > > > Today's Topics: > > > > > > 1. Re: RPD Digest, Vol 222, Issue 122 (jordi.palet at consulintel.es) > > > > > > > > > ---------------------------------------------------------------------- > > > > > > Message: 1 > > > Date: Tue, 21 Jul 2026 13:03:53 +0200 > > > From: "jordi.palet at consulintel.es" > > > To: rpd at afrinic.net > > > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 122 > > > Message-ID: <3071913E-7C72-49BC-BEDD-B7F26DE20A96 at consulintel.es> > > > Content-Type: text/plain; charset="utf-8" > > > > > > Well ? that?s incorrect. Nobody in the community, neither the staff > > impact > > > assessment, said that a policy is not needed and many folks already > > > contested several times, that doing it by means of a policy is valid > > > according to the bylaws and PDP and it has not been demonstrated by > > > objections that following this path, with is the most regular one in > > > AFRINIC, creates any harm or problem. > > > > > > So repeating the argument, by many folks, many times, doesn?t > demonstrate > > > ?per se" that it is a valid objection to revert the already reached > > > consensus. Of course, this is a decision that need to be taken by PDP > > > chairs, but this is my view point from an exclusive ?procedural? basis. > > > > > > Regards, > > > Jordi > > > > > > @jordipalet > > > > > > > El 21 jul 2026, a las 12:46, Fundiswa Nadia Maseko < > > > fundiswanadia2 at gmail.com> escribi?: > > > > > > > > Dear Jordi, > > > > > > > > Thank you for your clarification. > > > > > > > > I understand your point that the proposal has already reached > consensus > > > and that Last Call is intended to identify any weaknesses that may have > > > been overlooked. > > > > > > > > My concern is precisely that if the choice of mechanism was not > > > sufficiently examined during the earlier discussions, then it remains a > > > valid point to raise during Last Call. If a proposal introduces policy > > > where an operational approach could achieve the same objective, that > > > affects whether policy is the appropriate solution in the first place. > > > > > > > > I appreciate that consensus was declared, but consensus does not > > prevent > > > the community from identifying a concern that may not have received > > enough > > > attention. Last Call exists to give the community one final opportunity > > to > > > do exactly that. > > > > > > > > > > > > Kind regards, > > > > > > > > Fundiswa > > > > > > > > On Tue, 21 Jul 2026, 12:30 , > > rpd-request at afrinic.net>> wrote: > > > >> Send RPD mailing list submissions to > > > >> rpd at afrinic.net > > > >> > > > >> To subscribe or unsubscribe via the World Wide Web, visit > > > >> https://lists.afrinic.net/mailman/listinfo/rpd > > > >> or, via email, send a message with subject or body 'help' to > > > >> rpd-request at afrinic.net > > > >> > > > >> You can reach the person managing the list at > > > >> rpd-owner at afrinic.net > > > >> > > > >> When replying, please edit your Subject line so it is more specific > > > >> than "Re: Contents of RPD digest..." > > > >> > > > >> > > > >> Today's Topics: > > > >> > > > >> 1. Re: RPD Digest, Vol 222, Issue 119 ( > jordi.palet at consulintel.es > > > ) > > > >> > > > >> > > > >> > ---------------------------------------------------------------------- > > > >> > > > >> Message: 1 > > > >> Date: Tue, 21 Jul 2026 12:29:07 +0200 > > > >> From: "jordi.palet at consulintel.es jordi.palet at consulintel.es > > >" > > > > > > > >> To: rpd at afrinic.net > > > >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 119 > > > >> Message-ID: > > > > > > >> Content-Type: text/plain; charset="utf-8" > > > >> > > > >> Hi Fundiswa, > > > >> > > > >> Is not a matter of what is practical and what not. > > > >> > > > >> It is a matter that, during the discussion of the policy proposal > > > (which is not the same as the Last Call), the community reached > consensus > > > on making it this way. RIRs follow the same procedures for reaching > > > consensus as IETF, this has been said several times. The Last Call is a > > > last opportunity to discover any weak point in a proposal that already > > > reached consensus, and was OVERLOOKED before. Is not about discussing > if > > > the proposal should be a proposal or an operational decision. This is > no > > > longer the moment to discuss that (it should have done when the > proposal > > > was being discussed before reaching consensus), and many folks in this > > > discussing are ignoring that, probably because they are not used to > IETF > > > procedures. > > > >> > > > >> Otherwise, you can remain silent during the proposal discussion, > > during > > > the presentation in the PPM and object to it after reached consensus, > > which > > > is an incorrect procedure. > > > >> > > > >> One more example: we could have asked AFRINIC many years ago to > write > > > the Soft Landing as an operational thing, instead we as a community, > > > decided to make it a policy proposal. Same here. However, the community > > > decided to do it as a proposal and it was accepted that way at the > right > > > time, not in the Last Call. > > > >> > > > >> By the way, I love cooking so from time to time follow some > > > documentaries about that. Are you the same person as the famous chef? I > > > think I saw you in a TV program some months ago or I?m confused. > > > >> > > > >> Regards, > > > >> Jordi > > > >> > > > >> @jordipalet > > > >> > > > >> > El 21 jul 2026, a las 12:03, Fundiswa Nadia Maseko < > > > fundiswanadia2 at gmail.com > escribi?: > > > >> > > > > >> > Dear Jordi, > > > >> > > > > >> > Thank you for your response. > > > >> > > > > >> > I agree that AFRINIC is not required to follow the same approach > as > > > other RIRs. Every region should make decisions that suit its own > > community. > > > >> > > > > >> > My point, however, is slightly different. I wasn't suggesting that > > > AFRINIC should copy another RIR simply because they did it that way. > > > >> > > > > >> > Rather, I'm asking what specific problem is solved by making this > a > > > policy instead of implementing it operationally. If both approaches > > achieve > > > the same technical outcome, then what additional value does the policy > > > itself provide? > > > >> > > > > >> > I think that's an important distinction. The fact that the > community > > > can choose policy doesn't necessarily mean policy is the most > appropriate > > > mechanism in every case. > > > >> > > > > >> > I'd be interested to hear what practical or technical benefit you > > > believe is only possible through policy and not through an operational > > > implementation. > > > >> > > > > >> > Kind regards, > > > >> > > > > >> > Fundiswa > > > >> > > > > >> > > > > >> > > > > >> > On Tue, 21 Jul 2026, 11:57 , > > rpd-request at afrinic.net> > > rpd-request at afrinic.net>>> wrote: > > > >> >> Send RPD mailing list submissions to > > > >> >> rpd at afrinic.net > > rpd at afrinic.net > > > > >> >> > > > >> >> To subscribe or unsubscribe via the World Wide Web, visit > > > >> >> https://lists.afrinic.net/mailman/listinfo/rpd > > > >> >> or, via email, send a message with subject or body 'help' to > > > >> >> rpd-request at afrinic.net > > > > > > > >> >> > > > >> >> You can reach the person managing the list at > > > >> >> rpd-owner at afrinic.net > > > > > > > >> >> > > > >> >> When replying, please edit your Subject line so it is more > specific > > > >> >> than "Re: Contents of RPD digest..." > > > >> >> > > > >> >> > > > >> >> Today's Topics: > > > >> >> > > > >> >> 1. Re: RPD Digest, Vol 222, Issue 111 (Nia Petronella) > > > >> >> > > > >> >> > > > >> >> > > > ---------------------------------------------------------------------- > > > >> >> > > > >> >> Message: 1 > > > >> >> Date: Tue, 21 Jul 2026 11:56:49 +0200 > > > >> >> From: Nia Petronella > > nonhlanhlapetronella85 at gmail.com> > nonhlanhlapetronella85 at gmail.com > > > >> > > > >> >> To: Andrew Alston > > aa at alstonnetworks.net> > > aa at alstonnetworks.net>>> > > > >> >> Cc: rpd at afrinic.net > rpd at afrinic.net > > > > > > > >> >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 111 > > > >> >> Message-ID: > > > >> >> > > itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com > > itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com> > > itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com > > itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com>>> > > > >> >> Content-Type: text/plain; charset="utf-8" > > > >> >> > > > >> >> Dear Andrew, > > > >> >> > > > >> >> I do not accept the binary you have presented. > > > >> >> > > > >> >> No one is suggesting that AFRINIC should make operational changes > > in > > > secret > > > >> >> or without community input. An operational change can be > published, > > > >> >> consulted on, tested, documented, and reviewed. The real question > > is > > > >> >> whether that input must be converted into binding policy enforced > > by > > > the > > > >> >> registry. > > > >> >> > > > >> >> Calling AFRINIC ?community-driven? does not answer who the > > community > > > is or > > > >> >> what it is authorised to bind. A self-selecting group of > > mailing-list > > > >> >> participants can provide expertise, support, and objection. It > does > > > not > > > >> >> automatically represent every member, resource holder, network, > > > customer, > > > >> >> or other affected party. > > > >> >> > > > >> >> The institutional reality also remains unchanged: participants > > > discuss the > > > >> >> policy, but AFRINIC interprets and enforces it. Community > > > participation > > > >> >> therefore does not eliminate registry power. It can become the > > > language > > > >> >> used to legitimise that power. > > > >> >> > > > >> >> This is why Kone?s examples matter. If LACNIC, RIPE NCC, and ARIN > > can > > > >> >> achieve the same technical outcome through operational > mechanisms, > > > then > > > >> >> policy is not technically inevitable. Proponents should explain > > what > > > >> >> additional technical result binding policy provides, beyond > > > converting an > > > >> >> IRR setting into an enforceable obligation. > > > >> >> > > > >> >> I also disagree that an objection is valid only if it proves > > > immediate > > > >> >> operational harm or implementation failure. The choice of > > instrument, > > > >> >> proportionality, reversibility, and expansion of enforcement > > > authority are > > > >> >> legitimate policy concerns. Last Call is not limited to asking > > > whether > > > >> >> software will break. It must also ask whether the proposed power > is > > > greater > > > >> >> than the problem requires. > > > >> >> > > > >> >> Rough consensus does not require every objection to be > > accommodated. > > > But an > > > >> >> objection is not ?addressed? merely because supporters repeat > that > > > the > > > >> >> community prefers policy. That is the very assumption being > > > challenged. > > > >> >> Procedure cannot be used to prove its own mandate. > > > >> >> > > > >> >> The fact that the RIR system has operated this way for decades > > > demonstrates > > > >> >> continuity of practice. It does not establish unlimited > legitimacy > > > of scope. > > > >> >> > > > >> >> I support Kone?s questions and remain opposed to > > > AFPUB-2026-ASN-001-DRAFT02. > > > >> >> > > > >> >> Regards, > > > >> >> Nonhlanhla > > > >> >> > > > >> >> > > > >> >> > > > >> >> On Tue, 21 Jul 2026, 10:26 am Andrew Alston < > aa at alstonnetworks.net > > > > > aa at alstonnetworks.net>>> wrote: > > > >> >> > > > >> >> > The answer to this is simple. AfriNiC is a community driven > > > organisation > > > >> >> > - and anything done with regard to address allocation and > > > management is > > > >> >> > done as per policy provided by the community. It is through > > > policy that > > > >> >> > the community tells AfriNIC how to do things in regards to the > > > allocation > > > >> >> > and handling of resources. > > > >> >> > > > > >> >> > Without policy, the discretion and rules are entirely in the > > hands > > > of the > > > >> >> > registry, and the community voice is removed. > > > >> >> > > > > >> >> > This has been the way the RIR system has operated for decades > > and > > > it > > > >> >> > works. The community exercises its voice and its right as to > how > > > things > > > >> >> > are done in relation to resource management through policy. > > > >> >> > > > > >> >> > Arguing that just because something can be done another way, is > > > not in my > > > >> >> > view a valid argument against policy. Objections to policy > need > > > to be > > > >> >> > technically grounded and demonstrate that the policy would > either > > > cause > > > >> >> > harm or alternatively be impractical to implement. Anything > else > > > is simply > > > >> >> > arguing that policy should not exist because someone doesn?t > like > > > AfriNIC > > > >> >> > being told how the community wants things done - and that isn?t > > an > > > argument > > > >> >> > that I believe rises to the level of a block on consensus. > > > >> >> > > > > >> >> > Please note - consensus does not require that the issue you > raise > > > have > > > >> >> > been fixed, it requires that they have been addressed, and > should > > > the > > > >> >> > community feel that despite the objections, the policy is > > > something that > > > >> >> > should proceed based on the fact that the questions have been > > > addressed if > > > >> >> > not necessarily accommodated, rough consensus still exists. > > > >> >> > > > > >> >> > Again, I support the policy and I see no technical or > > > evidence/fact-based > > > >> >> > arguments against said policy. > > > >> >> > > > > >> >> > Andrew > > > >> >> > > > > >> >> > On Tue, Jul 21, 2026 at 09:34, Nia Petronella < > > > >> >> > nonhlanhlapetronella85 at gmail.com > > nonhlanhlapetronella85 at gmail.com> > nonhlanhlapetronella85 at gmail.com > > > >> wrote: > > > >> >> > > > > >> >> >> Dear PDWG, > > > >> >> >> > > > >> >> >> Kone is asking the right question. > > > >> >> >> > > > >> >> >> The issue is no longer whether hierarchical AS-SET naming is > > > technically > > > >> >> >> possible or useful. It already exists. The issue is why > AFRINIC > > > needs a > > > >> >> >> binding policy to enforce what other RIRs largely treat as an > > > operational > > > >> >> >> IRR matter. > > > >> >> >> > > > >> >> >> That distinction matters. An operational change adjusts how a > > > service is > > > >> >> >> implemented. A policy creates an enforceable obligation and > > > enlarges the > > > >> >> >> registry?s authority. If the same technical result can be > > > achieved through > > > >> >> >> a community-reviewed implementation plan, then policy is not > the > > > minimum > > > >> >> >> necessary instrument. > > > >> >> >> > > > >> >> >> Saying that ?the community prefers policy? is not enough. > > > Participation > > > >> >> >> may guide technical work, but it does not turn every > preference > > > into a > > > >> >> >> mandate. A mailing list is not a legislature, and the > > > availability of the > > > >> >> >> PDP should not make policy the default answer to every > > > operational setting. > > > >> >> >> > > > >> >> >> This is how gatekeeping expands: the registry begins with a > > useful > > > >> >> >> technical function, then policy converts that function into > > > permission and > > > >> >> >> enforcement. The recordkeeper gradually becomes the > rule-maker. > > > >> >> >> > > > >> >> >> The proponents should therefore answer Kone directly: what > > > technical > > > >> >> >> outcome can mandatory policy achieve here that an operational > > > >> >> >> implementation cannot? > > > >> >> >> > > > >> >> >> Until that is clearly demonstrated, I support Kone?s questions > > > and remain > > > >> >> >> opposed to the policy route. > > > >> >> >> > > > >> >> >> Regards, > > > >> >> >> Nonhlanhla > > > >> >> >> > > > >> >> >> > > > >> >> >> > > > >> >> >> On Tue, 21 Jul 2026, 8:20 am > > rpd-request at afrinic.net> > > rpd-request at afrinic.net>>> wrote: > > > >> >> >> > > > >> >> >>> Send RPD mailing list submissions to > > > >> >> >>> rpd at afrinic.net > > rpd at afrinic.net > > > > >> >> >>> > > > >> >> >>> To subscribe or unsubscribe via the World Wide Web, visit > > > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > > > >> >> >>> or, via email, send a message with subject or body 'help' to > > > >> >> >>> rpd-request at afrinic.net > rpd-request at afrinic.net> > > > > > > > >> >> >>> > > > >> >> >>> You can reach the person managing the list at > > > >> >> >>> rpd-owner at afrinic.net > > > > > > > >> >> >>> > > > >> >> >>> When replying, please edit your Subject line so it is more > > > specific > > > >> >> >>> than "Re: Contents of RPD digest..." > > > >> >> >>> > > > >> >> >>> > > > >> >> >>> Today's Topics: > > > >> >> >>> > > > >> >> >>> 1. Re: RPD Digest, Vol 222, Issue 110 (Tshepo Masuku) > > > >> >> >>> > > > >> >> >>> > > > >> >> >>> > > > ---------------------------------------------------------------------- > > > >> >> >>> > > > >> >> >>> Message: 1 > > > >> >> >>> Date: Tue, 21 Jul 2026 06:19:05 +0000 > > > >> >> >>> From: Tshepo Masuku > > TshepoMasuku26 at hotmail.com> > > TshepoMasuku26 at hotmail.com>>> > > > >> >> >>> To: "rpd at afrinic.net > > rpd at afrinic.net >" > > rpd at afrinic.net> >> > > > >> >> >>> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 110 > > > >> >> >>> Message-ID: > > > >> >> >>> < > > > >> >> >>> > > > > > > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > > > > > > > > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > > > > > > > > > > > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > > > > > > > > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > > > >> > > > >> >> >>> > > > > >> >> >>> > > > >> >> >>> Content-Type: text/plain; charset="windows-1252" > > > >> >> >>> > > > >> >> >>> Dear All, > > > >> >> >>> > > > >> >> >>> Kone?s point is directly relevant. If LACNIC, RIPE NCC, and > > ARIN > > > can > > > >> >> >>> implement hierarchical AS-SET naming through operational > > > mechanisms, then > > > >> >> >>> proponents must explain why AFRINIC needs a binding policy to > > > achieve the > > > >> >> >>> same technical result. > > > >> >> >>> > > > >> >> >>> Saying that each RIR works differently does not answer that > > > question. > > > >> >> >>> Nor does saying that ?the community is on top of the RIR.? A > > > community may > > > >> >> >>> advise, object, and coordinate. It does not acquire unlimited > > > authority to > > > >> >> >>> convert every operational preference into policy. A mailing > > list > > > is not a > > > >> >> >>> legislature. > > > >> >> >>> > > > >> >> >>> If AFRINIC can solve this through an operational change, > policy > > > adds > > > >> >> >>> governance where technical administration would be > sufficient. > > > Speed and > > > >> >> >>> preference do not create mandate. > > > >> >> >>> > > > >> >> >>> Kone provided specific examples. Those should be answered > with > > > evidence, > > > >> >> >>> not by questioning whether he has worked in every RIR for > many > > > years. > > > >> >> >>> Experience is relevant, but it is not authority and it is > not a > > > substitute > > > >> >> >>> for argument. > > > >> >> >>> > > > >> >> >>> The unanswered question remains: what technical necessity > > > requires > > > >> >> >>> policy rather than operational implementation? > > > >> >> >>> > > > >> >> >>> Until that is answered, Kone?s objection stands, and I > support > > > it. > > > >> >> >>> > > > >> >> >>> Regards, > > > >> >> >>> Tshepo > > > >> >> >>> > > > >> >> >>> > > > >> >> >>> ________________________________ > > > >> >> >>> From: rpd-request at afrinic.net rpd-request at afrinic.net> > > > > < > > > rpd-request at afrinic.net > > rpd-request at afrinic.net >> > > > >> >> >>> Sent: Monday, July 20, 2026 11:10:57 pm > > > >> >> >>> To: rpd at afrinic.net > > rpd at afrinic.net > > > rpd at afrinic.net> >> > > > >> >> >>> Subject: RPD Digest, Vol 222, Issue 110 > > > >> >> >>> > > > >> >> >>> Send RPD mailing list submissions to > > > >> >> >>> rpd at afrinic.net > > rpd at afrinic.net > > > > >> >> >>> > > > >> >> >>> To subscribe or unsubscribe via the World Wide Web, visit > > > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > > > >> >> >>> or, via email, send a message with subject or body 'help' to > > > >> >> >>> rpd-request at afrinic.net > rpd-request at afrinic.net> > > > > > > > >> >> >>> > > > >> >> >>> You can reach the person managing the list at > > > >> >> >>> rpd-owner at afrinic.net > > > > > > > >> >> >>> > > > >> >> >>> When replying, please edit your Subject line so it is more > > > specific > > > >> >> >>> than "Re: Contents of RPD digest..." > > > >> >> >>> > > > >> >> >>> > > > >> >> >>> Today's Topics: > > > >> >> >>> > > > >> >> >>> 1. Re: Writing tools (Ben Roberts - AfriNIC) > > > >> >> >>> 2. Re: [Last Call] Draft Policy Proposal - Hierarchical > > Names > > > >> >> >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Kone) > > > >> >> >>> 3. Re: [Last Call] Draft Policy Proposal - Hierarchical > > Names > > > >> >> >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > > >> >> >>> (jordi.palet at consulintel.es > > jordi.palet at consulintel.es> > > jordi.palet at consulintel.es>>) > > > >> >> >>> > > > >> >> >>> > > > >> >> >>> > > > ---------------------------------------------------------------------- > > > >> >> >>> > > > >> >> >>> Message: 1 > > > >> >> >>> Date: Mon, 20 Jul 2026 21:26:40 +0200 > > > >> >> >>> From: Ben Roberts - AfriNIC > > ben.roberts at afrinic.net> > > ben.roberts at afrinic.net>>> > > > >> >> >>> To: Nonjabulo Sphilile > > nonjabulosphilile at gmail.com> > > > nonjabulosphilile at gmail.com>>> > > > >> >> >>> Cc: rpd at afrinic.net > > rpd at afrinic.net > > > > >> >> >>> Subject: Re: [rpd] Writing tools > > > >> >> >>> Message-ID: < > 09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net > > > > > 09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net > > 09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net>>> > > > >> >> >>> Content-Type: text/plain; charset="us-ascii" > > > >> >> >>> > > > >> >> >>> An HTML attachment was scrubbed... > > > >> >> >>> URL: < > > > >> >> >>> > > > > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/33c3ac9e/attachment-0001.html > > > >> >> >>> > > > > >> >> >>> > > > >> >> >>> ------------------------------ > > > >> >> >>> > > > >> >> >>> Message: 2 > > > >> >> >>> Date: Mon, 20 Jul 2026 20:34:20 +0000 > > > >> >> >>> From: Kone > > bakenon.kone at sancfis.net> > > bakenon.kone at sancfis.net>>> > > > >> >> >>> To: Seun Ojedeji > > seun.ojedeji at gmail.com> > > seun.ojedeji at gmail.com>>> > > > >> >> >>> Cc: rpd > > rpd at afrinic.net >> > > > >> >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - > > > Hierarchical > > > >> >> >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > > >> >> >>> Message-ID: > > > >> >> >>> > > >> >> >>> 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com > > 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com> > > 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com > > 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com>>> > > > >> >> >>> Content-Type: text/plain; charset="utf-8" > > > >> >> >>> > > > >> >> >>> Hello Seun, > > > >> >> >>> You may have misread my earlier mail. I clearly stated that > > > LACNIC, RIPE > > > >> >> >>> NCC, and ARIN do not require policy to enforce hierarchical > > > AS?SET > > > >> >> >>> naming. > > > >> >> >>> > > > >> >> >>> To help close the ongoing discussions, I believe addressing > the > > > >> >> >>> questions I > > > >> >> >>> raised would bring clarity: > > > >> >> >>> * LACNIC enforces hierarchical AS?SET naming operationally, > as > > > part of > > > >> >> >>> their IRR design from inception. > > > >> >> >>> * RIPE NCC handles IRR changes through their Numbered Work > > Items > > > (NWI) > > > >> >> >>> process, not through policy. > > > >> >> >>> * ARIN uses the ACSP (Consultation and Suggestion Process) > for > > > IRR > > > >> >> >>> operational matters, again without policy. > > > >> >> >>> > > > >> >> >>> > > > >> >> >>> These examples show that other RIRs (except APNIC) treat > AS?SET > > > naming as > > > >> >> >>> an operational IRR matter, not a policy obligation. > > > >> >> >>> > > > >> >> >>> This is why I asked whether AFRINIC could address this > > > operationally > > > >> >> >>> rather > > > >> >> >>> than through policy, and why Last Call discussions would > > benefit > > > from > > > >> >> >>> clear > > > >> >> >>> answers to these points. > > > >> >> >>> > > > >> >> >>> Thanks. > > > >> >> >>> --- > > > >> >> >>> Kone > > > >> >> >>> > > > >> >> >>> > > > >> >> >>> > > > >> >> >>> Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji < > > > seun.ojedeji at gmail.com > > seun.ojedeji at gmail.com >> a > > > >> >> >>> ?crit : > > > >> >> >>> > > > >> >> >>> > Hello Bakenon, > > > >> >> >>> > > > > >> >> >>> > Do refer to the proposal as it references URL to other > RIR's > > > policies > > > >> >> >>> for > > > >> >> >>> > thiis: > > > >> >> >>> > > > > >> >> >>> > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > > >> >> >>> > > > > >> >> >>> > Regards > > > >> >> >>> > > > > >> >> >>> > ---- > > > >> >> >>> > Sent from my mobile > > > >> >> >>> > kindly excuse typos > > > >> >> >>> > > > > >> >> >>> > On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, < > > > bakenon.kone at sancfis.net > > bakenon.kone at sancfis.net >> > > > >> >> >>> > wrote: > > > >> >> >>> > > > > >> >> >>> >> Dear PDWG, > > > >> >> >>> >> > > > >> >> >>> >> I have been following the discussions on the hierarchical > > > AS?SET > > > >> >> >>> naming > > > >> >> >>> >> scheme and would like clarification on a few points: > > > >> >> >>> >> > > > >> >> >>> >> 1. Could this matter be addressed operationally, as is > done > > > in ARIN, > > > >> >> >>> >> LACNIC, and RIPE NCC, without requiring policy changes? > > > >> >> >>> >> > > > >> >> >>> >> 2. If yes, why are we taking the policy route? Is it > because > > > AFRINIC > > > >> >> >>> >> currently lacks a defined process for handling operational > > > issues that > > > >> >> >>> >> affect IRR services? > > > >> >> >>> >> > > > >> >> >>> >> 3. Given that the hierarchical naming scheme is already > > > supported and > > > >> >> >>> >> currently exists within the IRR, this proposal represents > an > > > >> >> >>> enforcement > > > >> >> >>> >> change rather than the introduction of a new technical > > > standard. Why > > > >> >> >>> is a > > > >> >> >>> >> formal policy required to change an operational > enforcement > > > setting, > > > >> >> >>> rather > > > >> >> >>> >> than a community-vetted technical implementation plan?" > > > >> >> >>> >> > > > >> >> >>> >> Thank you. > > > >> >> >>> >> --- > > > >> >> >>> >> Kone > > > >> >> >>> >> > > > >> >> >>> >> > > > >> >> >>> >> > > > >> >> >>> >> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal < > > > hytham at tra.gov.eg > > >> a > > > >> >> >>> >> ?crit : > > > >> >> >>> >> > > > >> >> >>> >>> Dear PDWG, > > > >> >> >>> >>> > > > >> >> >>> >>> > > > >> >> >>> >>> The Policy Development Working Group (PDWG) Chairs have > > > initiated a > > > >> >> >>> Last > > > >> >> >>> >>> Call for this proposal, following rough consensus at the > > > AFRINIC-37 > > > >> >> >>> Public > > > >> >> >>> >>> Policy Meeting held in hybrid format in Nairobi, Kenya on > > 24 > > > June > > > >> >> >>> 2026. > > > >> >> >>> >>> > > > >> >> >>> >>> * Proposal Name: Hierarchical Names for New AS-SETs > > > >> >> >>> >>> > > > >> >> >>> >>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > > > >> >> >>> >>> > > > >> >> >>> >>> * Proposal URL: > > > >> >> >>> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > > >> >> >>> >>> > > > >> >> >>> >>> Last Call closes on: July 31, 2026, at 23:59 UTC. > > > >> >> >>> >>> > > > >> >> >>> >>> > > > >> >> >>> >>> 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. > > > >> >> >>> >>> > > > >> >> >>> >>> > > > >> >> >>> >>> As always, we kindly request that all participants adhere > > to > > > the > > > >> >> >>> AFRINIC > > > >> >> >>> >>> Code of Conduct to > maintain > > a > > > >> >> >>> respectful > > > >> >> >>> >>> and professional environment on the mailing list. > > > >> >> >>> >>> > > > >> >> >>> >>> > > > >> >> >>> >>> Kind regards, > > > >> >> >>> >>> > > > >> >> >>> >>> > > > >> >> >>> >>> Haitham el Nakhal > > > >> >> >>> >>> > > > >> >> >>> >>> AFRINIC PDWG Co-Chair > > > >> >> >>> >>> > > > >> >> >>> >>> > > > >> >> >>> >>> > > > >> >> >>> >>> _______________________________________________ > > > >> >> >>> >>> RPD mailing list > > > >> >> >>> >>> RPD at afrinic.net > > RPD at afrinic.net > > > > >> >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd > > > >> >> >>> >>> > > > >> >> >>> >> _______________________________________________ > > > >> >> >>> >> RPD mailing list > > > >> >> >>> >> RPD at afrinic.net > > RPD at afrinic.net > > > > >> >> >>> >> https://lists.afrinic.net/mailman/listinfo/rpd > > > >> >> >>> >> > > > >> >> >>> > > > > >> >> >>> -------------- next part -------------- > > > >> >> >>> An HTML attachment was scrubbed... > > > >> >> >>> URL: < > > > >> >> >>> > > > > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/4563e1d5/attachment-0001.html > > > >> >> >>> > > > > >> >> >>> > > > >> >> >>> ------------------------------ > > > >> >> >>> > > > >> >> >>> Message: 3 > > > >> >> >>> Date: Mon, 20 Jul 2026 23:10:04 +0200 > > > >> >> >>> From: "jordi.palet at consulintel.es > > jordi.palet at consulintel.es> > > jordi.palet at consulintel.es>>" > > jordi.palet at consulintel.es> > > jordi.palet at consulintel.es>>> > > > >> >> >>> To: rpd > > rpd at afrinic.net >> > > > >> >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - > > > Hierarchical > > > >> >> >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > > >> >> >>> Message-ID: < > > F22A09CF-A827-4D7F-B077-E0B9C774AF00 at consulintel.es > > > > > F22A09CF-A827-4D7F-B077-E0B9C774AF00 at consulintel.es > > F22A09CF-A827-4D7F-B077-E0B9C774AF00 at consulintel.es>>> > > > >> >> >>> Content-Type: text/plain; charset="utf-8" > > > >> >> >>> > > > >> >> >>> Hi Kone, > > > >> >> >>> > > > >> >> >>> And what is the relevance of that? > > > >> >> >>> > > > >> >> >>> If you have a good understanding about all the RIRs, you will > > > know that > > > >> >> >>> each RIR has their own ways to do things. In many senses they > > > act very > > > >> >> >>> similarly and in general we end up with very similarly > > policies, > > > but not > > > >> >> >>> always. Some RIRs have decided that some aspects are > > operational > > > and don?t > > > >> >> >>> need a policy proposal. > > > >> >> >>> > > > >> >> >>> However, despite that, the community is on top of the RIR, > and > > > the > > > >> >> >>> community sometimes, may decide that they prefer a policy if > > the > > > RIR hasn?t > > > >> >> >>> been proactive in advance in any specific topic, or even if > the > > > RIR was > > > >> >> >>> proactive, the community may prefer to speed up things, or to > > > show the way > > > >> >> >>> the community prefers. > > > >> >> >>> > > > >> >> >>> For example, if AFRINIC has any specific operational aspect > > > already in > > > >> >> >>> place, and the community prefer to manage that in a different > > > way, the > > > >> >> >>> community may opt either for suggesting the RIR to modify > that > > > operational > > > >> >> >>> aspect or to do actually enforce it by means of a policy > > > proposal. > > > >> >> >>> > > > >> >> >>> I think is important to know, by personal experience, how the > > > other 4 > > > >> >> >>> RIRs work before stating something that is not correct, > because > > > if you > > > >> >> >>> don?t work in all the RIRs for many years, it will be > difficult > > > for you to > > > >> >> >>> know the past and I?m sure IA will not be able to be precise > as > > > well. > > > >> >> >>> > > > >> >> >>> Regards, > > > >> >> >>> Jordi > > > >> >> >>> > > > >> >> >>> @jordipalet > > > >> >> >>> > > > >> >> >>> > El 20 jul 2026, a las 22:34, Kone < > bakenon.kone at sancfis.net > > > > > >> escribi?: > > > >> >> >>> > > > > >> >> >>> > Hello Seun, > > > >> >> >>> > You may have misread my earlier mail. I clearly stated that > > > LACNIC, > > > >> >> >>> RIPE NCC, and ARIN do not require policy to enforce > > hierarchical > > > AS?SET > > > >> >> >>> naming. > > > >> >> >>> > > > > >> >> >>> > To help close the ongoing discussions, I believe addressing > > the > > > >> >> >>> questions I raised would bring clarity: > > > >> >> >>> > * LACNIC enforces hierarchical AS?SET naming operationally, > > as > > > part of > > > >> >> >>> their IRR design from inception. > > > >> >> >>> > * RIPE NCC handles IRR changes through their Numbered Work > > > Items (NWI) > > > >> >> >>> process, not through policy. > > > >> >> >>> > * ARIN uses the ACSP (Consultation and Suggestion Process) > > for > > > IRR > > > >> >> >>> operational matters, again without policy. > > > >> >> >>> > > > > >> >> >>> > > > > >> >> >>> > These examples show that other RIRs (except APNIC) treat > > > AS?SET naming > > > >> >> >>> as an operational IRR matter, not a policy obligation. > > > >> >> >>> > > > > >> >> >>> > This is why I asked whether AFRINIC could address this > > > operationally > > > >> >> >>> rather than through policy, and why Last Call discussions > would > > > benefit > > > >> >> >>> from clear answers to these points. > > > >> >> >>> > > > > >> >> >>> > Thanks. > > > >> >> >>> > --- > > > >> >> >>> > Kone > > > >> >> >>> > > > > >> >> >>> > > > > >> >> >>> > > > > >> >> >>> > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji < > > > seun.ojedeji at gmail.com > > seun.ojedeji at gmail.com > > > > >> >> >>> seun.ojedeji at gmail.com> > > > >>> a > > ?crit > > > : > > > >> >> >>> >> Hello Bakenon, > > > >> >> >>> >> > > > >> >> >>> >> Do refer to the proposal as it references URL to other > RIR's > > > policies > > > >> >> >>> for thiis: > > > >> >> >>> >> > > > >> >> >>> >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > > >> >> >>> >> > > > >> >> >>> >> Regards > > > >> >> >>> >> > > > >> >> >>> >> ---- > > > >> >> >>> >> Sent from my mobile > > > >> >> >>> >> kindly excuse typos > > > >> >> >>> >> > > > >> >> >>> >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, < > > > bakenon.kone at sancfis.net > > bakenon.kone at sancfis.net > > > > >> >> >>> > > bakenon.kone at sancfis.net> > > bakenon.kone at sancfis.net>>>> wrote: > > > >> >> >>> >>> Dear PDWG, > > > >> >> >>> >>> > > > >> >> >>> >>> I have been following the discussions on the hierarchical > > > AS?SET > > > >> >> >>> naming scheme and would like clarification on a few points: > > > >> >> >>> >>> > > > >> >> >>> >>> 1. Could this matter be addressed operationally, as is > done > > > in ARIN, > > > >> >> >>> LACNIC, and RIPE NCC, without requiring policy changes? > > > >> >> >>> >>> > > > >> >> >>> >>> 2. If yes, why are we taking the policy route? Is it > > because > > > AFRINIC > > > >> >> >>> currently lacks a defined process for handling operational > > > issues that > > > >> >> >>> affect IRR services? > > > >> >> >>> >>> > > > >> >> >>> >>> 3. Given that the hierarchical naming scheme is already > > > supported > > > >> >> >>> and currently exists within the IRR, this proposal represents > > an > > > >> >> >>> enforcement change rather than the introduction of a new > > > technical > > > >> >> >>> standard. Why is a formal policy required to change an > > > operational > > > >> >> >>> enforcement setting, rather than a community-vetted technical > > > >> >> >>> implementation plan?" > > > >> >> >>> >>> > > > >> >> >>> >>> Thank you. > > > >> >> >>> >>> --- > > > >> >> >>> >>> Kone > > > >> >> >>> >>> > > > >> >> >>> >>> > > > >> >> >>> >>> > > > >> >> >>> >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal < > > > hytham at tra.gov.eg > > > > > > >> >> >>> > > > hytham at tra.gov.eg >>> a ?crit : > > > >> >> >>> >>>> Dear PDWG, > > > >> >> >>> >>>> > > > >> >> >>> >>>> > > > >> >> >>> >>>> The Policy Development Working Group (PDWG) Chairs have > > > initiated a > > > >> >> >>> Last Call for this proposal, following rough consensus at the > > > AFRINIC-37 > > > >> >> >>> Public Policy Meeting held in hybrid format in Nairobi, Kenya > > on > > > 24 June > > > >> >> >>> 2026. > > > >> >> >>> >>>> > > > >> >> >>> >>>> * Proposal Name: Hierarchical Names for New AS-SETs > > > >> >> >>> >>>> > > > >> >> >>> >>>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > > > >> >> >>> >>>> > > > >> >> >>> >>>> * Proposal URL: > > > >> >> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > > >> >> >>> >>>> > > > >> >> >>> >>>> Last Call closes on: July 31, 2026, at 23:59 UTC. > > > >> >> >>> >>>> > > > >> >> >>> >>>> > > > >> >> >>> >>>> 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. > > > >> >> >>> >>>> > > > >> >> >>> >>>> > > > >> >> >>> >>>> As always, we kindly request that all participants > adhere > > > to the > > > >> >> >>> AFRINIC Code of Conduct to > > > maintain a > > > >> >> >>> respectful and professional environment on the mailing list. > > > >> >> >>> >>>> > > > >> >> >>> >>>> > > > >> >> >>> >>>> Kind regards, > > > >> >> >>> >>>> > > > >> >> >>> >>>> > > > >> >> >>> >>>> Haitham el Nakhal > > > >> >> >>> >>>> > > > >> >> >>> >>>> AFRINIC PDWG Co-Chair > > > >> >> >>> >>>> > > > >> >> >>> >>>> > > > >> >> >>> >>>> > > > >> >> >>> >>>> _______________________________________________ > > > >> >> >>> >>>> RPD mailing list > > > >> >> >>> >>>> RPD at afrinic.net > > RPD at afrinic.net > > > > RPD at afrinic.net> >> > > > >> >> >>> >>>> https://lists.afrinic.net/mailman/listinfo/rpd > > > >> >> >>> >>> _______________________________________________ > > > >> >> >>> >>> RPD mailing list > > > >> >> >>> >>> RPD at afrinic.net > > RPD at afrinic.net > > > > RPD at afrinic.net> >> > > > >> >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd > > > >> >> >>> > _______________________________________________ > > > >> >> >>> > RPD mailing list > > > >> >> >>> > RPD at afrinic.net > > RPD at afrinic.net > > > > >> >> >>> > https://lists.afrinic.net/mailman/listinfo/rpd > > > >> >> >>> > > > >> >> >>> > > > >> >> >>> > > > >> >> >>> ********************************************** > > > >> >> >>> IPv4 is over > > > >> >> >>> Are you ready for the new Internet ? > > > >> >> >>> http://www.theipv6company.com < > http://www.theipv6company.com/> > > < > > > http://www.theipv6company.com/> > > > >> >> >>> The IPv6 Company > > > >> >> >>> > > > >> >> >>> This electronic message contains information which may be > > > privileged or > > > >> >> >>> confidential. The information is intended to be for the > > > exclusive use of > > > >> >> >>> the individual(s) named above and further non-explicilty > > > authorized > > > >> >> >>> disclosure, copying, distribution or use of the contents of > > this > > > >> >> >>> information, even if partially, including attached files, is > > > strictly > > > >> >> >>> prohibited and will be considered a criminal offense. If you > > are > > > not the > > > >> >> >>> intended recipient be aware that any disclosure, copying, > > > distribution or > > > >> >> >>> use of the contents of this information, even if partially, > > > including > > > >> >> >>> attached files, is strictly prohibited, will be considered a > > > criminal > > > >> >> >>> offense, so you must reply to the original sender to inform > > > about this > > > >> >> >>> communication and delete it. > > > >> >> >>> > > > >> >> >>> -------------- next part -------------- > > > >> >> >>> An HTML attachment was scrubbed... > > > >> >> >>> URL: < > > > >> >> >>> > > > > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/b6777fa7/attachment.html > > > >> >> >>> > > > > >> >> >>> > > > >> >> >>> ------------------------------ > > > >> >> >>> > > > >> >> >>> Subject: Digest Footer > > > >> >> >>> > > > >> >> >>> _______________________________________________ > > > >> >> >>> RPD mailing list > > > >> >> >>> RPD at afrinic.net > RPD at afrinic.net > > > > > > > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > > > >> >> >>> > > > >> >> >>> > > > >> >> >>> ------------------------------ > > > >> >> >>> > > > >> >> >>> End of RPD Digest, Vol 222, Issue 110 > > > >> >> >>> ************************************* > > > >> >> >>> > > > >> >> >>> -------------- next part -------------- > > > >> >> >>> An HTML attachment was scrubbed... > > > >> >> >>> URL: < > > > >> >> >>> > > > > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e492c668/attachment.html > > > >> >> >>> > > > > >> >> >>> > > > >> >> >>> ------------------------------ > > > >> >> >>> > > > >> >> >>> Subject: Digest Footer > > > >> >> >>> > > > >> >> >>> _______________________________________________ > > > >> >> >>> RPD mailing list > > > >> >> >>> RPD at afrinic.net > RPD at afrinic.net > > > > > > > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > > > >> >> >>> > > > >> >> >>> > > > >> >> >>> ------------------------------ > > > >> >> >>> > > > >> >> >>> End of RPD Digest, Vol 222, Issue 111 > > > >> >> >>> ************************************* > > > >> >> >>> > > > >> >> >> _______________________________________________ > > > >> >> >> RPD mailing list > > > >> >> >> RPD at afrinic.net > RPD at afrinic.net > > > > > > > >> >> >> https://lists.afrinic.net/mailman/listinfo/rpd > > > >> >> >> > > > >> >> > > > > >> >> -------------- next part -------------- > > > >> >> An HTML attachment was scrubbed... > > > >> >> URL: < > > > > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/9c41424a/attachment.html > > > > > > > >> >> > > > >> >> ------------------------------ > > > >> >> > > > >> >> Subject: Digest Footer > > > >> >> > > > >> >> _______________________________________________ > > > >> >> RPD mailing list > > > >> >> RPD at afrinic.net > > > > > > >> >> https://lists.afrinic.net/mailman/listinfo/rpd > > > >> >> > > > >> >> > > > >> >> ------------------------------ > > > >> >> > > > >> >> End of RPD Digest, Vol 222, Issue 119 > > > >> >> ************************************* > > > >> > _______________________________________________ > > > >> > RPD mailing list > > > >> > RPD at afrinic.net > > > >> > https://lists.afrinic.net/mailman/listinfo/rpd > > > >> > > > >> > > > >> > > > >> ********************************************** > > > >> IPv4 is over > > > >> Are you ready for the new Internet ? > > > >> http://www.theipv6company.com > > > >> The IPv6 Company > > > >> > > > >> This electronic message contains information which may be privileged > > or > > > confidential. The information is intended to be for the exclusive use > of > > > the individual(s) named above and further non-explicilty authorized > > > disclosure, copying, distribution or use of the contents of this > > > information, even if partially, including attached files, is strictly > > > prohibited and will be considered a criminal offense. If you are not > the > > > intended recipient be aware that any disclosure, copying, distribution > or > > > use of the contents of this information, even if partially, including > > > attached files, is strictly prohibited, will be considered a criminal > > > offense, so you must reply to the original sender to inform about this > > > communication and delete it. > > > >> > > > >> -------------- next part -------------- > > > >> An HTML attachment was scrubbed... > > > >> URL: < > > > > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/0ba797a1/attachment.html > > > > > > > >> > > > >> ------------------------------ > > > >> > > > >> Subject: Digest Footer > > > >> > > > >> _______________________________________________ > > > >> RPD mailing list > > > >> RPD at afrinic.net > > > >> https://lists.afrinic.net/mailman/listinfo/rpd > > > >> > > > >> > > > >> ------------------------------ > > > >> > > > >> End of RPD Digest, Vol 222, Issue 122 > > > >> ************************************* > > > > _______________________________________________ > > > > RPD mailing list > > > > RPD at afrinic.net > > > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > > > > > > > ********************************************** > > > IPv4 is over > > > Are you ready for the new Internet ? > > > http://www.theipv6company.com > > > The IPv6 Company > > > > > > This electronic message contains information which may be privileged or > > > confidential. The information is intended to be for the exclusive use > of > > > the individual(s) named above and further non-explicilty authorized > > > disclosure, copying, distribution or use of the contents of this > > > information, even if partially, including attached files, is strictly > > > prohibited and will be considered a criminal offense. If you are not > the > > > intended recipient be aware that any disclosure, copying, distribution > or > > > use of the contents of this information, even if partially, including > > > attached files, is strictly prohibited, will be considered a criminal > > > offense, so you must reply to the original sender to inform about this > > > communication and delete it. > > > > > > -------------- next part -------------- > > > An HTML attachment was scrubbed... > > > URL: < > > > > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/d5daa838/attachment.html > > > > > > > > > > ------------------------------ > > > > > > Subject: Digest Footer > > > > > > _______________________________________________ > > > RPD mailing list > > > RPD at afrinic.net > > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > > > > ------------------------------ > > > > > > End of RPD Digest, Vol 222, Issue 124 > > > ************************************* > > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/fe3cdcf4/attachment.html > > > > > > > ------------------------------ > > > > Subject: Digest Footer > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > ------------------------------ > > > > End of RPD Digest, Vol 222, Issue 126 > > ************************************* > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/124f7b1b/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 127 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Tue Jul 21 11:58:02 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Tue, 21 Jul 2026 13:58:02 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 124 In-Reply-To: References: Message-ID: Hi Nia, In other occasions, staff has said ?policy not needed, it is a very operational matter?. So that sets a precedent, even if not a mandatory one, because even in that case, the community can decide to take the policy approach. That completely nullify the objection to follow the policy approach. Let?s suppose the Last Call fails based on that. The staff implements it just operationally, and then the community still prefers to have it as a policy. Will then your argument become valid and a policy should not reach consensus? Clearly not. As I said many times, the community is "on top? (bottom up process) of the staff and the community can decide that even if a policy is doing exactly the same as the staff operational decision, the community still have the right to reach consensus on setting any operational aspect by means of a policy, unless the policy creates a damage for the AFRINIC organization (in which case, will be NOT ratified by the board). You keep understanding that policy is binding and operational staff procedures not. This is fundamentally broken, so it doesn?t make a difference. Saludos, Jordi @jordipalet > El 21 jul 2026, a las 13:18, Nia Petronella escribi?: > > Dear Jordi, > > You are answering whether policy is procedurally permitted. That is not the question being raised. > > The fact that the bylaws and PDP allow a policy does not prove that policy is necessary, proportionate, or the best instrument. Likewise, the absence of a staff statement saying ?policy is not needed? is not evidence that it is needed. Silence cannot manufacture necessity. > > Kone?s examples remain relevant because they show that the same technical outcome can be achieved operationally. The unanswered question is what binding policy adds beyond rigidity and registry enforcement. > > A procedural route does not justify itself merely because it is familiar. That is how process becomes mandate: the PDP permits policy, therefore policy is treated as necessary, and the resulting enforcement is then called community authority. > > Last Call exists precisely to test unresolved concerns, including the choice of instrument. Consensus is not protected by declaring that it was already reached before those concerns were answered. > > I therefore support Kone?s questions and remain opposed to the policy route. > > Regards, > Nonhlanhla > > > > > On Tue, 21 Jul 2026, 1:05 pm > wrote: >> Send RPD mailing list submissions to >> rpd at afrinic.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.afrinic.net/mailman/listinfo/rpd >> or, via email, send a message with subject or body 'help' to >> rpd-request at afrinic.net >> >> You can reach the person managing the list at >> rpd-owner at afrinic.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of RPD digest..." >> >> >> Today's Topics: >> >> 1. Re: RPD Digest, Vol 222, Issue 122 (jordi.palet at consulintel.es ) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 21 Jul 2026 13:03:53 +0200 >> From: "jordi.palet at consulintel.es " > >> To: rpd at afrinic.net >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 122 >> Message-ID: <3071913E-7C72-49BC-BEDD-B7F26DE20A96 at consulintel.es > >> Content-Type: text/plain; charset="utf-8" >> >> Well ? that?s incorrect. Nobody in the community, neither the staff impact assessment, said that a policy is not needed and many folks already contested several times, that doing it by means of a policy is valid according to the bylaws and PDP and it has not been demonstrated by objections that following this path, with is the most regular one in AFRINIC, creates any harm or problem. >> >> So repeating the argument, by many folks, many times, doesn?t demonstrate ?per se" that it is a valid objection to revert the already reached consensus. Of course, this is a decision that need to be taken by PDP chairs, but this is my view point from an exclusive ?procedural? basis. >> >> Regards, >> Jordi >> >> @jordipalet >> >> > El 21 jul 2026, a las 12:46, Fundiswa Nadia Maseko > escribi?: >> > >> > Dear Jordi, >> > >> > Thank you for your clarification. >> > >> > I understand your point that the proposal has already reached consensus and that Last Call is intended to identify any weaknesses that may have been overlooked. >> > >> > My concern is precisely that if the choice of mechanism was not sufficiently examined during the earlier discussions, then it remains a valid point to raise during Last Call. If a proposal introduces policy where an operational approach could achieve the same objective, that affects whether policy is the appropriate solution in the first place. >> > >> > I appreciate that consensus was declared, but consensus does not prevent the community from identifying a concern that may not have received enough attention. Last Call exists to give the community one final opportunity to do exactly that. >> > >> > >> > Kind regards, >> > >> > Fundiswa >> > >> > On Tue, 21 Jul 2026, 12:30 , >> wrote: >> >> Send RPD mailing list submissions to >> >> rpd at afrinic.net > >> >> >> >> To subscribe or unsubscribe via the World Wide Web, visit >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> or, via email, send a message with subject or body 'help' to >> >> rpd-request at afrinic.net > >> >> >> >> You can reach the person managing the list at >> >> rpd-owner at afrinic.net > >> >> >> >> When replying, please edit your Subject line so it is more specific >> >> than "Re: Contents of RPD digest..." >> >> >> >> >> >> Today's Topics: >> >> >> >> 1. Re: RPD Digest, Vol 222, Issue 119 (jordi.palet at consulintel.es >) >> >> >> >> >> >> ---------------------------------------------------------------------- >> >> >> >> Message: 1 >> >> Date: Tue, 21 Jul 2026 12:29:07 +0200 >> >> From: "jordi.palet at consulintel.es >" >> >> >> To: rpd at afrinic.net > >> >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 119 >> >> Message-ID: >> >> >> Content-Type: text/plain; charset="utf-8" >> >> >> >> Hi Fundiswa, >> >> >> >> Is not a matter of what is practical and what not. >> >> >> >> It is a matter that, during the discussion of the policy proposal (which is not the same as the Last Call), the community reached consensus on making it this way. RIRs follow the same procedures for reaching consensus as IETF, this has been said several times. The Last Call is a last opportunity to discover any weak point in a proposal that already reached consensus, and was OVERLOOKED before. Is not about discussing if the proposal should be a proposal or an operational decision. This is no longer the moment to discuss that (it should have done when the proposal was being discussed before reaching consensus), and many folks in this discussing are ignoring that, probably because they are not used to IETF procedures. >> >> >> >> Otherwise, you can remain silent during the proposal discussion, during the presentation in the PPM and object to it after reached consensus, which is an incorrect procedure. >> >> >> >> One more example: we could have asked AFRINIC many years ago to write the Soft Landing as an operational thing, instead we as a community, decided to make it a policy proposal. Same here. However, the community decided to do it as a proposal and it was accepted that way at the right time, not in the Last Call. >> >> >> >> By the way, I love cooking so from time to time follow some documentaries about that. Are you the same person as the famous chef? I think I saw you in a TV program some months ago or I?m confused. >> >> >> >> Regards, >> >> Jordi >> >> >> >> @jordipalet >> >> >> >> > El 21 jul 2026, a las 12:03, Fundiswa Nadia Maseko >> escribi?: >> >> > >> >> > Dear Jordi, >> >> > >> >> > Thank you for your response. >> >> > >> >> > I agree that AFRINIC is not required to follow the same approach as other RIRs. Every region should make decisions that suit its own community. >> >> > >> >> > My point, however, is slightly different. I wasn't suggesting that AFRINIC should copy another RIR simply because they did it that way. >> >> > >> >> > Rather, I'm asking what specific problem is solved by making this a policy instead of implementing it operationally. If both approaches achieve the same technical outcome, then what additional value does the policy itself provide? >> >> > >> >> > I think that's an important distinction. The fact that the community can choose policy doesn't necessarily mean policy is the most appropriate mechanism in every case. >> >> > >> >> > I'd be interested to hear what practical or technical benefit you believe is only possible through policy and not through an operational implementation. >> >> > >> >> > Kind regards, >> >> > >> >> > Fundiswa >> >> > >> >> > >> >> > >> >> > On Tue, 21 Jul 2026, 11:57 , > >>> wrote: >> >> >> Send RPD mailing list submissions to >> >> >> rpd at afrinic.net > >> >> >> >> >> >> >> To subscribe or unsubscribe via the World Wide Web, visit >> >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> or, via email, send a message with subject or body 'help' to >> >> >> rpd-request at afrinic.net > >> >> >> >> >> >> >> You can reach the person managing the list at >> >> >> rpd-owner at afrinic.net > >> >> >> >> >> >> >> When replying, please edit your Subject line so it is more specific >> >> >> than "Re: Contents of RPD digest..." >> >> >> >> >> >> >> >> >> Today's Topics: >> >> >> >> >> >> 1. Re: RPD Digest, Vol 222, Issue 111 (Nia Petronella) >> >> >> >> >> >> >> >> >> ---------------------------------------------------------------------- >> >> >> >> >> >> Message: 1 >> >> >> Date: Tue, 21 Jul 2026 11:56:49 +0200 >> >> >> From: Nia Petronella > >>> >> >> >> To: Andrew Alston > >>> >> >> >> Cc: rpd at afrinic.net > >> >> >> >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 111 >> >> >> Message-ID: >> >> >> > >>> >> >> >> Content-Type: text/plain; charset="utf-8" >> >> >> >> >> >> Dear Andrew, >> >> >> >> >> >> I do not accept the binary you have presented. >> >> >> >> >> >> No one is suggesting that AFRINIC should make operational changes in secret >> >> >> or without community input. An operational change can be published, >> >> >> consulted on, tested, documented, and reviewed. The real question is >> >> >> whether that input must be converted into binding policy enforced by the >> >> >> registry. >> >> >> >> >> >> Calling AFRINIC ?community-driven? does not answer who the community is or >> >> >> what it is authorised to bind. A self-selecting group of mailing-list >> >> >> participants can provide expertise, support, and objection. It does not >> >> >> automatically represent every member, resource holder, network, customer, >> >> >> or other affected party. >> >> >> >> >> >> The institutional reality also remains unchanged: participants discuss the >> >> >> policy, but AFRINIC interprets and enforces it. Community participation >> >> >> therefore does not eliminate registry power. It can become the language >> >> >> used to legitimise that power. >> >> >> >> >> >> This is why Kone?s examples matter. If LACNIC, RIPE NCC, and ARIN can >> >> >> achieve the same technical outcome through operational mechanisms, then >> >> >> policy is not technically inevitable. Proponents should explain what >> >> >> additional technical result binding policy provides, beyond converting an >> >> >> IRR setting into an enforceable obligation. >> >> >> >> >> >> I also disagree that an objection is valid only if it proves immediate >> >> >> operational harm or implementation failure. The choice of instrument, >> >> >> proportionality, reversibility, and expansion of enforcement authority are >> >> >> legitimate policy concerns. Last Call is not limited to asking whether >> >> >> software will break. It must also ask whether the proposed power is greater >> >> >> than the problem requires. >> >> >> >> >> >> Rough consensus does not require every objection to be accommodated. But an >> >> >> objection is not ?addressed? merely because supporters repeat that the >> >> >> community prefers policy. That is the very assumption being challenged. >> >> >> Procedure cannot be used to prove its own mandate. >> >> >> >> >> >> The fact that the RIR system has operated this way for decades demonstrates >> >> >> continuity of practice. It does not establish unlimited legitimacy of scope. >> >> >> >> >> >> I support Kone?s questions and remain opposed to AFPUB-2026-ASN-001-DRAFT02. >> >> >> >> >> >> Regards, >> >> >> Nonhlanhla >> >> >> >> >> >> >> >> >> >> >> >> On Tue, 21 Jul 2026, 10:26 am Andrew Alston > >>> wrote: >> >> >> >> >> >> > The answer to this is simple. AfriNiC is a community driven organisation >> >> >> > - and anything done with regard to address allocation and management is >> >> >> > done as per policy provided by the community. It is through policy that >> >> >> > the community tells AfriNIC how to do things in regards to the allocation >> >> >> > and handling of resources. >> >> >> > >> >> >> > Without policy, the discretion and rules are entirely in the hands of the >> >> >> > registry, and the community voice is removed. >> >> >> > >> >> >> > This has been the way the RIR system has operated for decades and it >> >> >> > works. The community exercises its voice and its right as to how things >> >> >> > are done in relation to resource management through policy. >> >> >> > >> >> >> > Arguing that just because something can be done another way, is not in my >> >> >> > view a valid argument against policy. Objections to policy need to be >> >> >> > technically grounded and demonstrate that the policy would either cause >> >> >> > harm or alternatively be impractical to implement. Anything else is simply >> >> >> > arguing that policy should not exist because someone doesn?t like AfriNIC >> >> >> > being told how the community wants things done - and that isn?t an argument >> >> >> > that I believe rises to the level of a block on consensus. >> >> >> > >> >> >> > Please note - consensus does not require that the issue you raise have >> >> >> > been fixed, it requires that they have been addressed, and should the >> >> >> > community feel that despite the objections, the policy is something that >> >> >> > should proceed based on the fact that the questions have been addressed if >> >> >> > not necessarily accommodated, rough consensus still exists. >> >> >> > >> >> >> > Again, I support the policy and I see no technical or evidence/fact-based >> >> >> > arguments against said policy. >> >> >> > >> >> >> > Andrew >> >> >> > >> >> >> > On Tue, Jul 21, 2026 at 09:34, Nia Petronella < >> >> >> > nonhlanhlapetronella85 at gmail.com > >>> wrote: >> >> >> > >> >> >> >> Dear PDWG, >> >> >> >> >> >> >> >> Kone is asking the right question. >> >> >> >> >> >> >> >> The issue is no longer whether hierarchical AS-SET naming is technically >> >> >> >> possible or useful. It already exists. The issue is why AFRINIC needs a >> >> >> >> binding policy to enforce what other RIRs largely treat as an operational >> >> >> >> IRR matter. >> >> >> >> >> >> >> >> That distinction matters. An operational change adjusts how a service is >> >> >> >> implemented. A policy creates an enforceable obligation and enlarges the >> >> >> >> registry?s authority. If the same technical result can be achieved through >> >> >> >> a community-reviewed implementation plan, then policy is not the minimum >> >> >> >> necessary instrument. >> >> >> >> >> >> >> >> Saying that ?the community prefers policy? is not enough. Participation >> >> >> >> may guide technical work, but it does not turn every preference into a >> >> >> >> mandate. A mailing list is not a legislature, and the availability of the >> >> >> >> PDP should not make policy the default answer to every operational setting. >> >> >> >> >> >> >> >> This is how gatekeeping expands: the registry begins with a useful >> >> >> >> technical function, then policy converts that function into permission and >> >> >> >> enforcement. The recordkeeper gradually becomes the rule-maker. >> >> >> >> >> >> >> >> The proponents should therefore answer Kone directly: what technical >> >> >> >> outcome can mandatory policy achieve here that an operational >> >> >> >> implementation cannot? >> >> >> >> >> >> >> >> Until that is clearly demonstrated, I support Kone?s questions and remain >> >> >> >> opposed to the policy route. >> >> >> >> >> >> >> >> Regards, >> >> >> >> Nonhlanhla >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Tue, 21 Jul 2026, 8:20 am > >>> wrote: >> >> >> >> >> >> >> >>> Send RPD mailing list submissions to >> >> >> >>> rpd at afrinic.net > >> >> >> >> >>> >> >> >> >>> To subscribe or unsubscribe via the World Wide Web, visit >> >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >>> or, via email, send a message with subject or body 'help' to >> >> >> >>> rpd-request at afrinic.net > >> >> >> >> >>> >> >> >> >>> You can reach the person managing the list at >> >> >> >>> rpd-owner at afrinic.net > >> >> >> >> >>> >> >> >> >>> When replying, please edit your Subject line so it is more specific >> >> >> >>> than "Re: Contents of RPD digest..." >> >> >> >>> >> >> >> >>> >> >> >> >>> Today's Topics: >> >> >> >>> >> >> >> >>> 1. Re: RPD Digest, Vol 222, Issue 110 (Tshepo Masuku) >> >> >> >>> >> >> >> >>> >> >> >> >>> ---------------------------------------------------------------------- >> >> >> >>> >> >> >> >>> Message: 1 >> >> >> >>> Date: Tue, 21 Jul 2026 06:19:05 +0000 >> >> >> >>> From: Tshepo Masuku > >>> >> >> >> >>> To: "rpd at afrinic.net > >>" > >>> >> >> >> >>> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 110 >> >> >> >>> Message-ID: >> >> >> >>> < >> >> >> >>> VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > >> >> >> >> >>> > >> >> >> >>> >> >> >> >>> Content-Type: text/plain; charset="windows-1252" >> >> >> >>> >> >> >> >>> Dear All, >> >> >> >>> >> >> >> >>> Kone?s point is directly relevant. If LACNIC, RIPE NCC, and ARIN can >> >> >> >>> implement hierarchical AS-SET naming through operational mechanisms, then >> >> >> >>> proponents must explain why AFRINIC needs a binding policy to achieve the >> >> >> >>> same technical result. >> >> >> >>> >> >> >> >>> Saying that each RIR works differently does not answer that question. >> >> >> >>> Nor does saying that ?the community is on top of the RIR.? A community may >> >> >> >>> advise, object, and coordinate. It does not acquire unlimited authority to >> >> >> >>> convert every operational preference into policy. A mailing list is not a >> >> >> >>> legislature. >> >> >> >>> >> >> >> >>> If AFRINIC can solve this through an operational change, policy adds >> >> >> >>> governance where technical administration would be sufficient. Speed and >> >> >> >>> preference do not create mandate. >> >> >> >>> >> >> >> >>> Kone provided specific examples. Those should be answered with evidence, >> >> >> >>> not by questioning whether he has worked in every RIR for many years. >> >> >> >>> Experience is relevant, but it is not authority and it is not a substitute >> >> >> >>> for argument. >> >> >> >>> >> >> >> >>> The unanswered question remains: what technical necessity requires >> >> >> >>> policy rather than operational implementation? >> >> >> >>> >> >> >> >>> Until that is answered, Kone?s objection stands, and I support it. >> >> >> >>> >> >> >> >>> Regards, >> >> >> >>> Tshepo >> >> >> >>> >> >> >> >>> >> >> >> >>> ________________________________ >> >> >> >>> From: rpd-request at afrinic.net > >> > >>> >> >> >> >>> Sent: Monday, July 20, 2026 11:10:57 pm >> >> >> >>> To: rpd at afrinic.net > >> > >>> >> >> >> >>> Subject: RPD Digest, Vol 222, Issue 110 >> >> >> >>> >> >> >> >>> Send RPD mailing list submissions to >> >> >> >>> rpd at afrinic.net > >> >> >> >> >>> >> >> >> >>> To subscribe or unsubscribe via the World Wide Web, visit >> >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >>> or, via email, send a message with subject or body 'help' to >> >> >> >>> rpd-request at afrinic.net > >> >> >> >> >>> >> >> >> >>> You can reach the person managing the list at >> >> >> >>> rpd-owner at afrinic.net > >> >> >> >> >>> >> >> >> >>> When replying, please edit your Subject line so it is more specific >> >> >> >>> than "Re: Contents of RPD digest..." >> >> >> >>> >> >> >> >>> >> >> >> >>> Today's Topics: >> >> >> >>> >> >> >> >>> 1. Re: Writing tools (Ben Roberts - AfriNIC) >> >> >> >>> 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >> >> >> >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Kone) >> >> >> >>> 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >> >> >> >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> >> >> >>> (jordi.palet at consulintel.es > >>) >> >> >> >>> >> >> >> >>> >> >> >> >>> ---------------------------------------------------------------------- >> >> >> >>> >> >> >> >>> Message: 1 >> >> >> >>> Date: Mon, 20 Jul 2026 21:26:40 +0200 >> >> >> >>> From: Ben Roberts - AfriNIC > >>> >> >> >> >>> To: Nonjabulo Sphilile > >>> >> >> >> >>> Cc: rpd at afrinic.net > >> >> >> >> >>> Subject: Re: [rpd] Writing tools >> >> >> >>> Message-ID: <09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net > >>> >> >> >> >>> Content-Type: text/plain; charset="us-ascii" >> >> >> >>> >> >> >> >>> An HTML attachment was scrubbed... >> >> >> >>> URL: < >> >> >> >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/33c3ac9e/attachment-0001.html >> >> >> >>> > >> >> >> >>> >> >> >> >>> ------------------------------ >> >> >> >>> >> >> >> >>> Message: 2 >> >> >> >>> Date: Mon, 20 Jul 2026 20:34:20 +0000 >> >> >> >>> From: Kone > >>> >> >> >> >>> To: Seun Ojedeji > >>> >> >> >> >>> Cc: rpd > >>> >> >> >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >> >> >> >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> >> >> >>> Message-ID: >> >> >> >>> > >> >> >>> 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com > >>> >> >> >> >>> Content-Type: text/plain; charset="utf-8" >> >> >> >>> >> >> >> >>> Hello Seun, >> >> >> >>> You may have misread my earlier mail. I clearly stated that LACNIC, RIPE >> >> >> >>> NCC, and ARIN do not require policy to enforce hierarchical AS?SET >> >> >> >>> naming. >> >> >> >>> >> >> >> >>> To help close the ongoing discussions, I believe addressing the >> >> >> >>> questions I >> >> >> >>> raised would bring clarity: >> >> >> >>> * LACNIC enforces hierarchical AS?SET naming operationally, as part of >> >> >> >>> their IRR design from inception. >> >> >> >>> * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) >> >> >> >>> process, not through policy. >> >> >> >>> * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR >> >> >> >>> operational matters, again without policy. >> >> >> >>> >> >> >> >>> >> >> >> >>> These examples show that other RIRs (except APNIC) treat AS?SET naming as >> >> >> >>> an operational IRR matter, not a policy obligation. >> >> >> >>> >> >> >> >>> This is why I asked whether AFRINIC could address this operationally >> >> >> >>> rather >> >> >> >>> than through policy, and why Last Call discussions would benefit from >> >> >> >>> clear >> >> >> >>> answers to these points. >> >> >> >>> >> >> >> >>> Thanks. >> >> >> >>> --- >> >> >> >>> Kone >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji > >>> a >> >> >> >>> ?crit : >> >> >> >>> >> >> >> >>> > Hello Bakenon, >> >> >> >>> > >> >> >> >>> > Do refer to the proposal as it references URL to other RIR's policies >> >> >> >>> for >> >> >> >>> > thiis: >> >> >> >>> > >> >> >> >>> > https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >> >> >>> > >> >> >> >>> > Regards >> >> >> >>> > >> >> >> >>> > ---- >> >> >> >>> > Sent from my mobile >> >> >> >>> > kindly excuse typos >> >> >> >>> > >> >> >> >>> > On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, > >>> >> >> >> >>> > wrote: >> >> >> >>> > >> >> >> >>> >> Dear PDWG, >> >> >> >>> >> >> >> >> >>> >> I have been following the discussions on the hierarchical AS?SET >> >> >> >>> naming >> >> >> >>> >> scheme and would like clarification on a few points: >> >> >> >>> >> >> >> >> >>> >> 1. Could this matter be addressed operationally, as is done in ARIN, >> >> >> >>> >> LACNIC, and RIPE NCC, without requiring policy changes? >> >> >> >>> >> >> >> >> >>> >> 2. If yes, why are we taking the policy route? Is it because AFRINIC >> >> >> >>> >> currently lacks a defined process for handling operational issues that >> >> >> >>> >> affect IRR services? >> >> >> >>> >> >> >> >> >>> >> 3. Given that the hierarchical naming scheme is already supported and >> >> >> >>> >> currently exists within the IRR, this proposal represents an >> >> >> >>> enforcement >> >> >> >>> >> change rather than the introduction of a new technical standard. Why >> >> >> >>> is a >> >> >> >>> >> formal policy required to change an operational enforcement setting, >> >> >> >>> rather >> >> >> >>> >> than a community-vetted technical implementation plan?" >> >> >> >>> >> >> >> >> >>> >> Thank you. >> >> >> >>> >> --- >> >> >> >>> >> Kone >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal > >>> a >> >> >> >>> >> ?crit : >> >> >> >>> >> >> >> >> >>> >>> Dear PDWG, >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> The Policy Development Working Group (PDWG) Chairs have initiated a >> >> >> >>> Last >> >> >> >>> >>> Call for this proposal, following rough consensus at the AFRINIC-37 >> >> >> >>> Public >> >> >> >>> >>> Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June >> >> >> >>> 2026. >> >> >> >>> >>> >> >> >> >>> >>> * Proposal Name: Hierarchical Names for New AS-SETs >> >> >> >>> >>> >> >> >> >>> >>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >> >> >> >>> >>> >> >> >> >>> >>> * Proposal URL: >> >> >> >>> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >> >> >>> >>> >> >> >> >>> >>> Last Call closes on: July 31, 2026, at 23:59 UTC. >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> 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. >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> As always, we kindly request that all participants adhere to the >> >> >> >>> AFRINIC >> >> >> >>> >>> Code of Conduct to maintain a >> >> >> >>> respectful >> >> >> >>> >>> and professional environment on the mailing list. >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> Kind regards, >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> Haitham el Nakhal >> >> >> >>> >>> >> >> >> >>> >>> AFRINIC PDWG Co-Chair >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> _______________________________________________ >> >> >> >>> >>> RPD mailing list >> >> >> >>> >>> RPD at afrinic.net > >> >> >> >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >>> >>> >> >> >> >>> >> _______________________________________________ >> >> >> >>> >> RPD mailing list >> >> >> >>> >> RPD at afrinic.net > >> >> >> >> >>> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >>> >> >> >> >> >>> > >> >> >> >>> -------------- next part -------------- >> >> >> >>> An HTML attachment was scrubbed... >> >> >> >>> URL: < >> >> >> >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/4563e1d5/attachment-0001.html >> >> >> >>> > >> >> >> >>> >> >> >> >>> ------------------------------ >> >> >> >>> >> >> >> >>> Message: 3 >> >> >> >>> Date: Mon, 20 Jul 2026 23:10:04 +0200 >> >> >> >>> From: "jordi.palet at consulintel.es > >>" > >>> >> >> >> >>> To: rpd > >>> >> >> >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >> >> >> >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> >> >> >>> Message-ID: > >>> >> >> >> >>> Content-Type: text/plain; charset="utf-8" >> >> >> >>> >> >> >> >>> Hi Kone, >> >> >> >>> >> >> >> >>> And what is the relevance of that? >> >> >> >>> >> >> >> >>> If you have a good understanding about all the RIRs, you will know that >> >> >> >>> each RIR has their own ways to do things. In many senses they act very >> >> >> >>> similarly and in general we end up with very similarly policies, but not >> >> >> >>> always. Some RIRs have decided that some aspects are operational and don?t >> >> >> >>> need a policy proposal. >> >> >> >>> >> >> >> >>> However, despite that, the community is on top of the RIR, and the >> >> >> >>> community sometimes, may decide that they prefer a policy if the RIR hasn?t >> >> >> >>> been proactive in advance in any specific topic, or even if the RIR was >> >> >> >>> proactive, the community may prefer to speed up things, or to show the way >> >> >> >>> the community prefers. >> >> >> >>> >> >> >> >>> For example, if AFRINIC has any specific operational aspect already in >> >> >> >>> place, and the community prefer to manage that in a different way, the >> >> >> >>> community may opt either for suggesting the RIR to modify that operational >> >> >> >>> aspect or to do actually enforce it by means of a policy proposal. >> >> >> >>> >> >> >> >>> I think is important to know, by personal experience, how the other 4 >> >> >> >>> RIRs work before stating something that is not correct, because if you >> >> >> >>> don?t work in all the RIRs for many years, it will be difficult for you to >> >> >> >>> know the past and I?m sure IA will not be able to be precise as well. >> >> >> >>> >> >> >> >>> Regards, >> >> >> >>> Jordi >> >> >> >>> >> >> >> >>> @jordipalet >> >> >> >>> >> >> >> >>> > El 20 jul 2026, a las 22:34, Kone > >>> escribi?: >> >> >> >>> > >> >> >> >>> > Hello Seun, >> >> >> >>> > You may have misread my earlier mail. I clearly stated that LACNIC, >> >> >> >>> RIPE NCC, and ARIN do not require policy to enforce hierarchical AS?SET >> >> >> >>> naming. >> >> >> >>> > >> >> >> >>> > To help close the ongoing discussions, I believe addressing the >> >> >> >>> questions I raised would bring clarity: >> >> >> >>> > * LACNIC enforces hierarchical AS?SET naming operationally, as part of >> >> >> >>> their IRR design from inception. >> >> >> >>> > * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) >> >> >> >>> process, not through policy. >> >> >> >>> > * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR >> >> >> >>> operational matters, again without policy. >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > These examples show that other RIRs (except APNIC) treat AS?SET naming >> >> >> >>> as an operational IRR matter, not a policy obligation. >> >> >> >>> > >> >> >> >>> > This is why I asked whether AFRINIC could address this operationally >> >> >> >>> rather than through policy, and why Last Call discussions would benefit >> >> >> >>> from clear answers to these points. >> >> >> >>> > >> >> >> >>> > Thanks. >> >> >> >>> > --- >> >> >> >>> > Kone >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji > >> >> >> >> >>> > >>>> a ?crit : >> >> >> >>> >> Hello Bakenon, >> >> >> >>> >> >> >> >> >>> >> Do refer to the proposal as it references URL to other RIR's policies >> >> >> >>> for thiis: >> >> >> >>> >> >> >> >> >>> >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >> >> >>> >> >> >> >> >>> >> Regards >> >> >> >>> >> >> >> >> >>> >> ---- >> >> >> >>> >> Sent from my mobile >> >> >> >>> >> kindly excuse typos >> >> >> >>> >> >> >> >> >>> >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, > >> >> >> >> >>> > >>>> wrote: >> >> >> >>> >>> Dear PDWG, >> >> >> >>> >>> >> >> >> >>> >>> I have been following the discussions on the hierarchical AS?SET >> >> >> >>> naming scheme and would like clarification on a few points: >> >> >> >>> >>> >> >> >> >>> >>> 1. Could this matter be addressed operationally, as is done in ARIN, >> >> >> >>> LACNIC, and RIPE NCC, without requiring policy changes? >> >> >> >>> >>> >> >> >> >>> >>> 2. If yes, why are we taking the policy route? Is it because AFRINIC >> >> >> >>> currently lacks a defined process for handling operational issues that >> >> >> >>> affect IRR services? >> >> >> >>> >>> >> >> >> >>> >>> 3. Given that the hierarchical naming scheme is already supported >> >> >> >>> and currently exists within the IRR, this proposal represents an >> >> >> >>> enforcement change rather than the introduction of a new technical >> >> >> >>> standard. Why is a formal policy required to change an operational >> >> >> >>> enforcement setting, rather than a community-vetted technical >> >> >> >>> implementation plan?" >> >> >> >>> >>> >> >> >> >>> >>> Thank you. >> >> >> >>> >>> --- >> >> >> >>> >>> Kone >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal > >> >> >> >> >>> > >>>> a ?crit : >> >> >> >>> >>>> Dear PDWG, >> >> >> >>> >>>> >> >> >> >>> >>>> >> >> >> >>> >>>> The Policy Development Working Group (PDWG) Chairs have initiated a >> >> >> >>> Last Call for this proposal, following rough consensus at the AFRINIC-37 >> >> >> >>> Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June >> >> >> >>> 2026. >> >> >> >>> >>>> >> >> >> >>> >>>> * Proposal Name: Hierarchical Names for New AS-SETs >> >> >> >>> >>>> >> >> >> >>> >>>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >> >> >> >>> >>>> >> >> >> >>> >>>> * Proposal URL: >> >> >> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >> >> >>> >>>> >> >> >> >>> >>>> Last Call closes on: July 31, 2026, at 23:59 UTC. >> >> >> >>> >>>> >> >> >> >>> >>>> >> >> >> >>> >>>> 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. >> >> >> >>> >>>> >> >> >> >>> >>>> >> >> >> >>> >>>> As always, we kindly request that all participants adhere to the >> >> >> >>> AFRINIC Code of Conduct to maintain a >> >> >> >>> respectful and professional environment on the mailing list. >> >> >> >>> >>>> >> >> >> >>> >>>> >> >> >> >>> >>>> Kind regards, >> >> >> >>> >>>> >> >> >> >>> >>>> >> >> >> >>> >>>> Haitham el Nakhal >> >> >> >>> >>>> >> >> >> >>> >>>> AFRINIC PDWG Co-Chair >> >> >> >>> >>>> >> >> >> >>> >>>> >> >> >> >>> >>>> >> >> >> >>> >>>> _______________________________________________ >> >> >> >>> >>>> RPD mailing list >> >> >> >>> >>>> RPD at afrinic.net > >> > >>> >> >> >> >>> >>>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >>> >>> _______________________________________________ >> >> >> >>> >>> RPD mailing list >> >> >> >>> >>> RPD at afrinic.net > >> > >>> >> >> >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >>> > _______________________________________________ >> >> >> >>> > RPD mailing list >> >> >> >>> > RPD at afrinic.net > >> >> >> >> >>> > https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> ********************************************** >> >> >> >>> IPv4 is over >> >> >> >>> Are you ready for the new Internet ? >> >> >> >>> http://www.theipv6company.com >> >> >> >>> The IPv6 Company >> >> >> >>> >> >> >> >>> This electronic message contains information which may be privileged or >> >> >> >>> confidential. The information is intended to be for the exclusive use of >> >> >> >>> the individual(s) named above and further non-explicilty authorized >> >> >> >>> disclosure, copying, distribution or use of the contents of this >> >> >> >>> information, even if partially, including attached files, is strictly >> >> >> >>> prohibited and will be considered a criminal offense. If you are not the >> >> >> >>> intended recipient be aware that any disclosure, copying, distribution or >> >> >> >>> use of the contents of this information, even if partially, including >> >> >> >>> attached files, is strictly prohibited, will be considered a criminal >> >> >> >>> offense, so you must reply to the original sender to inform about this >> >> >> >>> communication and delete it. >> >> >> >>> >> >> >> >>> -------------- next part -------------- >> >> >> >>> An HTML attachment was scrubbed... >> >> >> >>> URL: < >> >> >> >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/b6777fa7/attachment.html >> >> >> >>> > >> >> >> >>> >> >> >> >>> ------------------------------ >> >> >> >>> >> >> >> >>> Subject: Digest Footer >> >> >> >>> >> >> >> >>> _______________________________________________ >> >> >> >>> RPD mailing list >> >> >> >>> RPD at afrinic.net > >> >> >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >>> >> >> >> >>> >> >> >> >>> ------------------------------ >> >> >> >>> >> >> >> >>> End of RPD Digest, Vol 222, Issue 110 >> >> >> >>> ************************************* >> >> >> >>> >> >> >> >>> -------------- next part -------------- >> >> >> >>> An HTML attachment was scrubbed... >> >> >> >>> URL: < >> >> >> >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e492c668/attachment.html >> >> >> >>> > >> >> >> >>> >> >> >> >>> ------------------------------ >> >> >> >>> >> >> >> >>> Subject: Digest Footer >> >> >> >>> >> >> >> >>> _______________________________________________ >> >> >> >>> RPD mailing list >> >> >> >>> RPD at afrinic.net > >> >> >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >>> >> >> >> >>> >> >> >> >>> ------------------------------ >> >> >> >>> >> >> >> >>> End of RPD Digest, Vol 222, Issue 111 >> >> >> >>> ************************************* >> >> >> >>> >> >> >> >> _______________________________________________ >> >> >> >> RPD mailing list >> >> >> >> RPD at afrinic.net > >> >> >> >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> >> >> >> > >> >> >> -------------- next part -------------- >> >> >> An HTML attachment was scrubbed... >> >> >> URL: >> >> >> >> >> >> ------------------------------ >> >> >> >> >> >> Subject: Digest Footer >> >> >> >> >> >> _______________________________________________ >> >> >> RPD mailing list >> >> >> RPD at afrinic.net > >> >> >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> >> >> >> >> >> ------------------------------ >> >> >> >> >> >> End of RPD Digest, Vol 222, Issue 119 >> >> >> ************************************* >> >> > _______________________________________________ >> >> > RPD mailing list >> >> > RPD at afrinic.net > >> >> > https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> >> >> >> >> ********************************************** >> >> IPv4 is over >> >> Are you ready for the new Internet ? >> >> http://www.theipv6company.com >> >> The IPv6 Company >> >> >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> >> >> -------------- next part -------------- >> >> An HTML attachment was scrubbed... >> >> URL: >> >> >> >> ------------------------------ >> >> >> >> Subject: Digest Footer >> >> >> >> _______________________________________________ >> >> RPD mailing list >> >> RPD at afrinic.net > >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> >> >> ------------------------------ >> >> >> >> End of RPD Digest, Vol 222, Issue 122 >> >> ************************************* >> > _______________________________________________ >> > RPD mailing list >> > RPD at afrinic.net >> > https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ------------------------------ >> >> End of RPD Digest, Vol 222, Issue 124 >> ************************************* ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Tue Jul 21 12:05:38 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Tue, 21 Jul 2026 14:05:38 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 126 In-Reply-To: References: Message-ID: So the very simple question is: Where in the bylaws or the PDP state, that a proposal must demonstrate the necessity of using a policy proposal approach vs operational decisions? Also, following your argument, if we take the operational approach, we can make the same question reversed. Where the bylaws or PDP state that it must be demonstrated the necessity of the operational approach vs the policy proposal one? It is fundamentally a bottom-up approach decision process. Policies always have priority on top of staff decisions, if they reach consensus, consequently that objection can?t revert the consensus otherwise any policy proposal may be rejected for the very same reason. This basically means, and repeating myself, that if you are objecting to that, you really need to do that not in any specific policy proposal, but in a generic way in the PDP (or even the bylaws) modification and of course, your proposal on that, must reach consensus. Saludos, Jordi @jordipalet > El 21 jul 2026, a las 13:20, Fundiswa Nadia Maseko escribi?: > > Dear Jordi, > > Thank you for your response. > > I agree that simply repeating an argument does not, by itself, justify revisiting consensus. > > However, I believe the concern being raised is not repetition for its own sake. It is whether the proposal has demonstrated the necessity of using a policy mechanism rather than an operational one. > > I also agree that a policy does not have to create harm to be questioned. At the same time, policy should generally exist because it provides a clear benefit that cannot reasonably be achieved through a less prescriptive mechanism. > > My understanding is that Last Call is an opportunity for the community to determine whether any aspect of a proposal has not been sufficiently justified before it is recommended for ratification. In my view, the choice of mechanism remains one such aspect. > > I appreciate your explanation of the procedural perspective, even though we may differ on whether this concern has been fully addressed. > > Kind regards, > Fundiswa > > On Tue, 21 Jul 2026, 13:19 , > wrote: >> Send RPD mailing list submissions to >> rpd at afrinic.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.afrinic.net/mailman/listinfo/rpd >> or, via email, send a message with subject or body 'help' to >> rpd-request at afrinic.net >> >> You can reach the person managing the list at >> rpd-owner at afrinic.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of RPD digest..." >> >> >> Today's Topics: >> >> 1. Re: RPD Digest, Vol 222, Issue 122 (Taye Medoye) >> 2. Re: RPD Digest, Vol 222, Issue 124 (Nia Petronella) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 21 Jul 2026 13:16:30 +0200 >> From: Taye Medoye > >> To: rpd at afrinic.net >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 122 >> Message-ID: >> > >> Content-Type: text/plain; charset="utf-8" >> >> Dear All, >> >> I think the clarification made by Fundiswa regarding the seemingly fluid >> interconnection between the stage of consensus and Last Call in reaching a >> policy statement suffices. It is understood that if, at the point of Last >> Call on a policy proposal process, there arises an intervening factor, the >> need for a further review can be allowed. >> >> Besides, l have taken note of the relevance of the possible effect of >> diversities in the different Registries on the development of policy action >> on any subject-matter for consideration. And l think this should be >> accorded the recognition it deserves. >> >> Therefore, l align with the perspective as suggested by Fundiswa, and hope >> for an understanding of the Community participants on the same. >> >> Taye Medoye. >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> ------------------------------ >> >> Message: 2 >> Date: Tue, 21 Jul 2026 13:18:25 +0200 >> From: Nia Petronella > >> To: rpd at afrinic.net , jordi.palet at consulintel.es >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 124 >> Message-ID: >> > >> Content-Type: text/plain; charset="utf-8" >> >> Dear Jordi, >> >> You are answering whether policy is procedurally permitted. That is not the >> question being raised. >> >> The fact that the bylaws and PDP allow a policy does not prove that policy >> is necessary, proportionate, or the best instrument. Likewise, the absence >> of a staff statement saying ?policy is not needed? is not evidence that it >> is needed. Silence cannot manufacture necessity. >> >> Kone?s examples remain relevant because they show that the same technical >> outcome can be achieved operationally. The unanswered question is what >> binding policy adds beyond rigidity and registry enforcement. >> >> A procedural route does not justify itself merely because it is familiar. >> That is how process becomes mandate: the PDP permits policy, therefore >> policy is treated as necessary, and the resulting enforcement is then >> called community authority. >> >> Last Call exists precisely to test unresolved concerns, including the >> choice of instrument. Consensus is not protected by declaring that it was >> already reached before those concerns were answered. >> >> I therefore support Kone?s questions and remain opposed to the policy route. >> >> Regards, >> Nonhlanhla >> >> >> >> On Tue, 21 Jul 2026, 1:05 pm > wrote: >> >> > Send RPD mailing list submissions to >> > rpd at afrinic.net >> > >> > To subscribe or unsubscribe via the World Wide Web, visit >> > https://lists.afrinic.net/mailman/listinfo/rpd >> > or, via email, send a message with subject or body 'help' to >> > rpd-request at afrinic.net >> > >> > You can reach the person managing the list at >> > rpd-owner at afrinic.net >> > >> > When replying, please edit your Subject line so it is more specific >> > than "Re: Contents of RPD digest..." >> > >> > >> > Today's Topics: >> > >> > 1. Re: RPD Digest, Vol 222, Issue 122 (jordi.palet at consulintel.es ) >> > >> > >> > ---------------------------------------------------------------------- >> > >> > Message: 1 >> > Date: Tue, 21 Jul 2026 13:03:53 +0200 >> > From: "jordi.palet at consulintel.es " > >> > To: rpd at afrinic.net >> > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 122 >> > Message-ID: <3071913E-7C72-49BC-BEDD-B7F26DE20A96 at consulintel.es > >> > Content-Type: text/plain; charset="utf-8" >> > >> > Well ? that?s incorrect. Nobody in the community, neither the staff impact >> > assessment, said that a policy is not needed and many folks already >> > contested several times, that doing it by means of a policy is valid >> > according to the bylaws and PDP and it has not been demonstrated by >> > objections that following this path, with is the most regular one in >> > AFRINIC, creates any harm or problem. >> > >> > So repeating the argument, by many folks, many times, doesn?t demonstrate >> > ?per se" that it is a valid objection to revert the already reached >> > consensus. Of course, this is a decision that need to be taken by PDP >> > chairs, but this is my view point from an exclusive ?procedural? basis. >> > >> > Regards, >> > Jordi >> > >> > @jordipalet >> > >> > > El 21 jul 2026, a las 12:46, Fundiswa Nadia Maseko < >> > fundiswanadia2 at gmail.com > escribi?: >> > > >> > > Dear Jordi, >> > > >> > > Thank you for your clarification. >> > > >> > > I understand your point that the proposal has already reached consensus >> > and that Last Call is intended to identify any weaknesses that may have >> > been overlooked. >> > > >> > > My concern is precisely that if the choice of mechanism was not >> > sufficiently examined during the earlier discussions, then it remains a >> > valid point to raise during Last Call. If a proposal introduces policy >> > where an operational approach could achieve the same objective, that >> > affects whether policy is the appropriate solution in the first place. >> > > >> > > I appreciate that consensus was declared, but consensus does not prevent >> > the community from identifying a concern that may not have received enough >> > attention. Last Call exists to give the community one final opportunity to >> > do exactly that. >> > > >> > > >> > > Kind regards, >> > > >> > > Fundiswa >> > > >> > > On Tue, 21 Jul 2026, 12:30 , > > rpd-request at afrinic.net >> wrote: >> > >> Send RPD mailing list submissions to >> > >> rpd at afrinic.net > >> > >> >> > >> To subscribe or unsubscribe via the World Wide Web, visit >> > >> https://lists.afrinic.net/mailman/listinfo/rpd >> > >> or, via email, send a message with subject or body 'help' to >> > >> rpd-request at afrinic.net > >> > >> >> > >> You can reach the person managing the list at >> > >> rpd-owner at afrinic.net > >> > >> >> > >> When replying, please edit your Subject line so it is more specific >> > >> than "Re: Contents of RPD digest..." >> > >> >> > >> >> > >> Today's Topics: >> > >> >> > >> 1. Re: RPD Digest, Vol 222, Issue 119 (jordi.palet at consulintel.es >> > >) >> > >> >> > >> >> > >> ---------------------------------------------------------------------- >> > >> >> > >> Message: 1 >> > >> Date: Tue, 21 Jul 2026 12:29:07 +0200 >> > >> From: "jordi.palet at consulintel.es >" >> > >> >> > >> To: rpd at afrinic.net > >> > >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 119 >> > >> Message-ID: >> > >> >> > >> Content-Type: text/plain; charset="utf-8" >> > >> >> > >> Hi Fundiswa, >> > >> >> > >> Is not a matter of what is practical and what not. >> > >> >> > >> It is a matter that, during the discussion of the policy proposal >> > (which is not the same as the Last Call), the community reached consensus >> > on making it this way. RIRs follow the same procedures for reaching >> > consensus as IETF, this has been said several times. The Last Call is a >> > last opportunity to discover any weak point in a proposal that already >> > reached consensus, and was OVERLOOKED before. Is not about discussing if >> > the proposal should be a proposal or an operational decision. This is no >> > longer the moment to discuss that (it should have done when the proposal >> > was being discussed before reaching consensus), and many folks in this >> > discussing are ignoring that, probably because they are not used to IETF >> > procedures. >> > >> >> > >> Otherwise, you can remain silent during the proposal discussion, during >> > the presentation in the PPM and object to it after reached consensus, which >> > is an incorrect procedure. >> > >> >> > >> One more example: we could have asked AFRINIC many years ago to write >> > the Soft Landing as an operational thing, instead we as a community, >> > decided to make it a policy proposal. Same here. However, the community >> > decided to do it as a proposal and it was accepted that way at the right >> > time, not in the Last Call. >> > >> >> > >> By the way, I love cooking so from time to time follow some >> > documentaries about that. Are you the same person as the famous chef? I >> > think I saw you in a TV program some months ago or I?m confused. >> > >> >> > >> Regards, >> > >> Jordi >> > >> >> > >> @jordipalet >> > >> >> > >> > El 21 jul 2026, a las 12:03, Fundiswa Nadia Maseko < >> > fundiswanadia2 at gmail.com >> escribi?: >> > >> > >> > >> > Dear Jordi, >> > >> > >> > >> > Thank you for your response. >> > >> > >> > >> > I agree that AFRINIC is not required to follow the same approach as >> > other RIRs. Every region should make decisions that suit its own community. >> > >> > >> > >> > My point, however, is slightly different. I wasn't suggesting that >> > AFRINIC should copy another RIR simply because they did it that way. >> > >> > >> > >> > Rather, I'm asking what specific problem is solved by making this a >> > policy instead of implementing it operationally. If both approaches achieve >> > the same technical outcome, then what additional value does the policy >> > itself provide? >> > >> > >> > >> > I think that's an important distinction. The fact that the community >> > can choose policy doesn't necessarily mean policy is the most appropriate >> > mechanism in every case. >> > >> > >> > >> > I'd be interested to hear what practical or technical benefit you >> > believe is only possible through policy and not through an operational >> > implementation. >> > >> > >> > >> > Kind regards, >> > >> > >> > >> > Fundiswa >> > >> > >> > >> > >> > >> > >> > >> > On Tue, 21 Jul 2026, 11:57 , > > rpd-request at afrinic.net > > > rpd-request at afrinic.net >>> wrote: >> > >> >> Send RPD mailing list submissions to >> > >> >> rpd at afrinic.net > > > rpd at afrinic.net >> >> > >> >> >> > >> >> To subscribe or unsubscribe via the World Wide Web, visit >> > >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> > >> >> or, via email, send a message with subject or body 'help' to >> > >> >> rpd-request at afrinic.net > >> > >> >> > >> >> >> > >> >> You can reach the person managing the list at >> > >> >> rpd-owner at afrinic.net > >> > >> >> > >> >> >> > >> >> When replying, please edit your Subject line so it is more specific >> > >> >> than "Re: Contents of RPD digest..." >> > >> >> >> > >> >> >> > >> >> Today's Topics: >> > >> >> >> > >> >> 1. Re: RPD Digest, Vol 222, Issue 111 (Nia Petronella) >> > >> >> >> > >> >> >> > >> >> >> > ---------------------------------------------------------------------- >> > >> >> >> > >> >> Message: 1 >> > >> >> Date: Tue, 21 Jul 2026 11:56:49 +0200 >> > >> >> From: Nia Petronella > > nonhlanhlapetronella85 at gmail.com > >> > >>> >> > >> >> To: Andrew Alston > > aa at alstonnetworks.net > > > aa at alstonnetworks.net >>> >> > >> >> Cc: rpd at afrinic.net > >> > >> >> > >> >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 111 >> > >> >> Message-ID: >> > >> >> > > itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com > > itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com > > > itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com > > itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com >>> >> > >> >> Content-Type: text/plain; charset="utf-8" >> > >> >> >> > >> >> Dear Andrew, >> > >> >> >> > >> >> I do not accept the binary you have presented. >> > >> >> >> > >> >> No one is suggesting that AFRINIC should make operational changes in >> > secret >> > >> >> or without community input. An operational change can be published, >> > >> >> consulted on, tested, documented, and reviewed. The real question is >> > >> >> whether that input must be converted into binding policy enforced by >> > the >> > >> >> registry. >> > >> >> >> > >> >> Calling AFRINIC ?community-driven? does not answer who the community >> > is or >> > >> >> what it is authorised to bind. A self-selecting group of mailing-list >> > >> >> participants can provide expertise, support, and objection. It does >> > not >> > >> >> automatically represent every member, resource holder, network, >> > customer, >> > >> >> or other affected party. >> > >> >> >> > >> >> The institutional reality also remains unchanged: participants >> > discuss the >> > >> >> policy, but AFRINIC interprets and enforces it. Community >> > participation >> > >> >> therefore does not eliminate registry power. It can become the >> > language >> > >> >> used to legitimise that power. >> > >> >> >> > >> >> This is why Kone?s examples matter. If LACNIC, RIPE NCC, and ARIN can >> > >> >> achieve the same technical outcome through operational mechanisms, >> > then >> > >> >> policy is not technically inevitable. Proponents should explain what >> > >> >> additional technical result binding policy provides, beyond >> > converting an >> > >> >> IRR setting into an enforceable obligation. >> > >> >> >> > >> >> I also disagree that an objection is valid only if it proves >> > immediate >> > >> >> operational harm or implementation failure. The choice of instrument, >> > >> >> proportionality, reversibility, and expansion of enforcement >> > authority are >> > >> >> legitimate policy concerns. Last Call is not limited to asking >> > whether >> > >> >> software will break. It must also ask whether the proposed power is >> > greater >> > >> >> than the problem requires. >> > >> >> >> > >> >> Rough consensus does not require every objection to be accommodated. >> > But an >> > >> >> objection is not ?addressed? merely because supporters repeat that >> > the >> > >> >> community prefers policy. That is the very assumption being >> > challenged. >> > >> >> Procedure cannot be used to prove its own mandate. >> > >> >> >> > >> >> The fact that the RIR system has operated this way for decades >> > demonstrates >> > >> >> continuity of practice. It does not establish unlimited legitimacy >> > of scope. >> > >> >> >> > >> >> I support Kone?s questions and remain opposed to >> > AFPUB-2026-ASN-001-DRAFT02. >> > >> >> >> > >> >> Regards, >> > >> >> Nonhlanhla >> > >> >> >> > >> >> >> > >> >> >> > >> >> On Tue, 21 Jul 2026, 10:26 am Andrew Alston >> > > > > aa at alstonnetworks.net >>> wrote: >> > >> >> >> > >> >> > The answer to this is simple. AfriNiC is a community driven >> > organisation >> > >> >> > - and anything done with regard to address allocation and >> > management is >> > >> >> > done as per policy provided by the community. It is through >> > policy that >> > >> >> > the community tells AfriNIC how to do things in regards to the >> > allocation >> > >> >> > and handling of resources. >> > >> >> > >> > >> >> > Without policy, the discretion and rules are entirely in the hands >> > of the >> > >> >> > registry, and the community voice is removed. >> > >> >> > >> > >> >> > This has been the way the RIR system has operated for decades and >> > it >> > >> >> > works. The community exercises its voice and its right as to how >> > things >> > >> >> > are done in relation to resource management through policy. >> > >> >> > >> > >> >> > Arguing that just because something can be done another way, is >> > not in my >> > >> >> > view a valid argument against policy. Objections to policy need >> > to be >> > >> >> > technically grounded and demonstrate that the policy would either >> > cause >> > >> >> > harm or alternatively be impractical to implement. Anything else >> > is simply >> > >> >> > arguing that policy should not exist because someone doesn?t like >> > AfriNIC >> > >> >> > being told how the community wants things done - and that isn?t an >> > argument >> > >> >> > that I believe rises to the level of a block on consensus. >> > >> >> > >> > >> >> > Please note - consensus does not require that the issue you raise >> > have >> > >> >> > been fixed, it requires that they have been addressed, and should >> > the >> > >> >> > community feel that despite the objections, the policy is >> > something that >> > >> >> > should proceed based on the fact that the questions have been >> > addressed if >> > >> >> > not necessarily accommodated, rough consensus still exists. >> > >> >> > >> > >> >> > Again, I support the policy and I see no technical or >> > evidence/fact-based >> > >> >> > arguments against said policy. >> > >> >> > >> > >> >> > Andrew >> > >> >> > >> > >> >> > On Tue, Jul 21, 2026 at 09:34, Nia Petronella < >> > >> >> > nonhlanhlapetronella85 at gmail.com > > nonhlanhlapetronella85 at gmail.com > >> > >>> wrote: >> > >> >> > >> > >> >> >> Dear PDWG, >> > >> >> >> >> > >> >> >> Kone is asking the right question. >> > >> >> >> >> > >> >> >> The issue is no longer whether hierarchical AS-SET naming is >> > technically >> > >> >> >> possible or useful. It already exists. The issue is why AFRINIC >> > needs a >> > >> >> >> binding policy to enforce what other RIRs largely treat as an >> > operational >> > >> >> >> IRR matter. >> > >> >> >> >> > >> >> >> That distinction matters. An operational change adjusts how a >> > service is >> > >> >> >> implemented. A policy creates an enforceable obligation and >> > enlarges the >> > >> >> >> registry?s authority. If the same technical result can be >> > achieved through >> > >> >> >> a community-reviewed implementation plan, then policy is not the >> > minimum >> > >> >> >> necessary instrument. >> > >> >> >> >> > >> >> >> Saying that ?the community prefers policy? is not enough. >> > Participation >> > >> >> >> may guide technical work, but it does not turn every preference >> > into a >> > >> >> >> mandate. A mailing list is not a legislature, and the >> > availability of the >> > >> >> >> PDP should not make policy the default answer to every >> > operational setting. >> > >> >> >> >> > >> >> >> This is how gatekeeping expands: the registry begins with a useful >> > >> >> >> technical function, then policy converts that function into >> > permission and >> > >> >> >> enforcement. The recordkeeper gradually becomes the rule-maker. >> > >> >> >> >> > >> >> >> The proponents should therefore answer Kone directly: what >> > technical >> > >> >> >> outcome can mandatory policy achieve here that an operational >> > >> >> >> implementation cannot? >> > >> >> >> >> > >> >> >> Until that is clearly demonstrated, I support Kone?s questions >> > and remain >> > >> >> >> opposed to the policy route. >> > >> >> >> >> > >> >> >> Regards, >> > >> >> >> Nonhlanhla >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> On Tue, 21 Jul 2026, 8:20 am > > rpd-request at afrinic.net > > > rpd-request at afrinic.net >>> wrote: >> > >> >> >> >> > >> >> >>> Send RPD mailing list submissions to >> > >> >> >>> rpd at afrinic.net > > > rpd at afrinic.net >> >> > >> >> >>> >> > >> >> >>> To subscribe or unsubscribe via the World Wide Web, visit >> > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> > >> >> >>> or, via email, send a message with subject or body 'help' to >> > >> >> >>> rpd-request at afrinic.net > >> > >> >> > >> >> >>> >> > >> >> >>> You can reach the person managing the list at >> > >> >> >>> rpd-owner at afrinic.net > >> > >> >> > >> >> >>> >> > >> >> >>> When replying, please edit your Subject line so it is more >> > specific >> > >> >> >>> than "Re: Contents of RPD digest..." >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> Today's Topics: >> > >> >> >>> >> > >> >> >>> 1. Re: RPD Digest, Vol 222, Issue 110 (Tshepo Masuku) >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > ---------------------------------------------------------------------- >> > >> >> >>> >> > >> >> >>> Message: 1 >> > >> >> >>> Date: Tue, 21 Jul 2026 06:19:05 +0000 >> > >> >> >>> From: Tshepo Masuku > > TshepoMasuku26 at hotmail.com > > > TshepoMasuku26 at hotmail.com >>> >> > >> >> >>> To: "rpd at afrinic.net > > > rpd at afrinic.net >>" > > rpd at afrinic.net > >>> >> > >> >> >>> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 110 >> > >> >> >>> Message-ID: >> > >> >> >>> < >> > >> >> >>> >> > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com >> > > > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > >> > > > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com >> > > > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com >> > >> >> > >> >> >>> > >> > >> >> >>> >> > >> >> >>> Content-Type: text/plain; charset="windows-1252" >> > >> >> >>> >> > >> >> >>> Dear All, >> > >> >> >>> >> > >> >> >>> Kone?s point is directly relevant. If LACNIC, RIPE NCC, and ARIN >> > can >> > >> >> >>> implement hierarchical AS-SET naming through operational >> > mechanisms, then >> > >> >> >>> proponents must explain why AFRINIC needs a binding policy to >> > achieve the >> > >> >> >>> same technical result. >> > >> >> >>> >> > >> >> >>> Saying that each RIR works differently does not answer that >> > question. >> > >> >> >>> Nor does saying that ?the community is on top of the RIR.? A >> > community may >> > >> >> >>> advise, object, and coordinate. It does not acquire unlimited >> > authority to >> > >> >> >>> convert every operational preference into policy. A mailing list >> > is not a >> > >> >> >>> legislature. >> > >> >> >>> >> > >> >> >>> If AFRINIC can solve this through an operational change, policy >> > adds >> > >> >> >>> governance where technical administration would be sufficient. >> > Speed and >> > >> >> >>> preference do not create mandate. >> > >> >> >>> >> > >> >> >>> Kone provided specific examples. Those should be answered with >> > evidence, >> > >> >> >>> not by questioning whether he has worked in every RIR for many >> > years. >> > >> >> >>> Experience is relevant, but it is not authority and it is not a >> > substitute >> > >> >> >>> for argument. >> > >> >> >>> >> > >> >> >>> The unanswered question remains: what technical necessity >> > requires >> > >> >> >>> policy rather than operational implementation? >> > >> >> >>> >> > >> >> >>> Until that is answered, Kone?s objection stands, and I support >> > it. >> > >> >> >>> >> > >> >> >>> Regards, >> > >> >> >>> Tshepo >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> ________________________________ >> > >> >> >>> From: rpd-request at afrinic.net > >> > >> < >> > rpd-request at afrinic.net > > > rpd-request at afrinic.net >>> >> > >> >> >>> Sent: Monday, July 20, 2026 11:10:57 pm >> > >> >> >>> To: rpd at afrinic.net > > > rpd at afrinic.net >> > > rpd at afrinic.net > >>> >> > >> >> >>> Subject: RPD Digest, Vol 222, Issue 110 >> > >> >> >>> >> > >> >> >>> Send RPD mailing list submissions to >> > >> >> >>> rpd at afrinic.net > > > rpd at afrinic.net >> >> > >> >> >>> >> > >> >> >>> To subscribe or unsubscribe via the World Wide Web, visit >> > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> > >> >> >>> or, via email, send a message with subject or body 'help' to >> > >> >> >>> rpd-request at afrinic.net > >> > >> >> > >> >> >>> >> > >> >> >>> You can reach the person managing the list at >> > >> >> >>> rpd-owner at afrinic.net > >> > >> >> > >> >> >>> >> > >> >> >>> When replying, please edit your Subject line so it is more >> > specific >> > >> >> >>> than "Re: Contents of RPD digest..." >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> Today's Topics: >> > >> >> >>> >> > >> >> >>> 1. Re: Writing tools (Ben Roberts - AfriNIC) >> > >> >> >>> 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >> > >> >> >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Kone) >> > >> >> >>> 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >> > >> >> >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> > >> >> >>> (jordi.palet at consulintel.es > > jordi.palet at consulintel.es > > > jordi.palet at consulintel.es >>) >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > ---------------------------------------------------------------------- >> > >> >> >>> >> > >> >> >>> Message: 1 >> > >> >> >>> Date: Mon, 20 Jul 2026 21:26:40 +0200 >> > >> >> >>> From: Ben Roberts - AfriNIC > > ben.roberts at afrinic.net > > > ben.roberts at afrinic.net >>> >> > >> >> >>> To: Nonjabulo Sphilile > > nonjabulosphilile at gmail.com > > > nonjabulosphilile at gmail.com >>> >> > >> >> >>> Cc: rpd at afrinic.net > > > rpd at afrinic.net >> >> > >> >> >>> Subject: Re: [rpd] Writing tools >> > >> >> >>> Message-ID: <09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net >> > > > > 09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net > > 09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net >>> >> > >> >> >>> Content-Type: text/plain; charset="us-ascii" >> > >> >> >>> >> > >> >> >>> An HTML attachment was scrubbed... >> > >> >> >>> URL: < >> > >> >> >>> >> > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/33c3ac9e/attachment-0001.html >> > >> >> >>> > >> > >> >> >>> >> > >> >> >>> ------------------------------ >> > >> >> >>> >> > >> >> >>> Message: 2 >> > >> >> >>> Date: Mon, 20 Jul 2026 20:34:20 +0000 >> > >> >> >>> From: Kone > > bakenon.kone at sancfis.net > > > bakenon.kone at sancfis.net >>> >> > >> >> >>> To: Seun Ojedeji > > seun.ojedeji at gmail.com > > > seun.ojedeji at gmail.com >>> >> > >> >> >>> Cc: rpd > > > rpd at afrinic.net >>> >> > >> >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - >> > Hierarchical >> > >> >> >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> > >> >> >>> Message-ID: >> > >> >> >>> > > >> >> >>> 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com > > 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com > > > 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com > > 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com >>> >> > >> >> >>> Content-Type: text/plain; charset="utf-8" >> > >> >> >>> >> > >> >> >>> Hello Seun, >> > >> >> >>> You may have misread my earlier mail. I clearly stated that >> > LACNIC, RIPE >> > >> >> >>> NCC, and ARIN do not require policy to enforce hierarchical >> > AS?SET >> > >> >> >>> naming. >> > >> >> >>> >> > >> >> >>> To help close the ongoing discussions, I believe addressing the >> > >> >> >>> questions I >> > >> >> >>> raised would bring clarity: >> > >> >> >>> * LACNIC enforces hierarchical AS?SET naming operationally, as >> > part of >> > >> >> >>> their IRR design from inception. >> > >> >> >>> * RIPE NCC handles IRR changes through their Numbered Work Items >> > (NWI) >> > >> >> >>> process, not through policy. >> > >> >> >>> * ARIN uses the ACSP (Consultation and Suggestion Process) for >> > IRR >> > >> >> >>> operational matters, again without policy. >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> These examples show that other RIRs (except APNIC) treat AS?SET >> > naming as >> > >> >> >>> an operational IRR matter, not a policy obligation. >> > >> >> >>> >> > >> >> >>> This is why I asked whether AFRINIC could address this >> > operationally >> > >> >> >>> rather >> > >> >> >>> than through policy, and why Last Call discussions would benefit >> > from >> > >> >> >>> clear >> > >> >> >>> answers to these points. >> > >> >> >>> >> > >> >> >>> Thanks. >> > >> >> >>> --- >> > >> >> >>> Kone >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji < >> > seun.ojedeji at gmail.com > > > seun.ojedeji at gmail.com >>> a >> > >> >> >>> ?crit : >> > >> >> >>> >> > >> >> >>> > Hello Bakenon, >> > >> >> >>> > >> > >> >> >>> > Do refer to the proposal as it references URL to other RIR's >> > policies >> > >> >> >>> for >> > >> >> >>> > thiis: >> > >> >> >>> > >> > >> >> >>> > https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> > >> >> >>> > >> > >> >> >>> > Regards >> > >> >> >>> > >> > >> >> >>> > ---- >> > >> >> >>> > Sent from my mobile >> > >> >> >>> > kindly excuse typos >> > >> >> >>> > >> > >> >> >>> > On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, < >> > bakenon.kone at sancfis.net > > > bakenon.kone at sancfis.net >>> >> > >> >> >>> > wrote: >> > >> >> >>> > >> > >> >> >>> >> Dear PDWG, >> > >> >> >>> >> >> > >> >> >>> >> I have been following the discussions on the hierarchical >> > AS?SET >> > >> >> >>> naming >> > >> >> >>> >> scheme and would like clarification on a few points: >> > >> >> >>> >> >> > >> >> >>> >> 1. Could this matter be addressed operationally, as is done >> > in ARIN, >> > >> >> >>> >> LACNIC, and RIPE NCC, without requiring policy changes? >> > >> >> >>> >> >> > >> >> >>> >> 2. If yes, why are we taking the policy route? Is it because >> > AFRINIC >> > >> >> >>> >> currently lacks a defined process for handling operational >> > issues that >> > >> >> >>> >> affect IRR services? >> > >> >> >>> >> >> > >> >> >>> >> 3. Given that the hierarchical naming scheme is already >> > supported and >> > >> >> >>> >> currently exists within the IRR, this proposal represents an >> > >> >> >>> enforcement >> > >> >> >>> >> change rather than the introduction of a new technical >> > standard. Why >> > >> >> >>> is a >> > >> >> >>> >> formal policy required to change an operational enforcement >> > setting, >> > >> >> >>> rather >> > >> >> >>> >> than a community-vetted technical implementation plan?" >> > >> >> >>> >> >> > >> >> >>> >> Thank you. >> > >> >> >>> >> --- >> > >> >> >>> >> Kone >> > >> >> >>> >> >> > >> >> >>> >> >> > >> >> >>> >> >> > >> >> >>> >> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal < >> > hytham at tra.gov.eg > >> > >>> a >> > >> >> >>> >> ?crit : >> > >> >> >>> >> >> > >> >> >>> >>> Dear PDWG, >> > >> >> >>> >>> >> > >> >> >>> >>> >> > >> >> >>> >>> The Policy Development Working Group (PDWG) Chairs have >> > initiated a >> > >> >> >>> Last >> > >> >> >>> >>> Call for this proposal, following rough consensus at the >> > AFRINIC-37 >> > >> >> >>> Public >> > >> >> >>> >>> Policy Meeting held in hybrid format in Nairobi, Kenya on 24 >> > June >> > >> >> >>> 2026. >> > >> >> >>> >>> >> > >> >> >>> >>> * Proposal Name: Hierarchical Names for New AS-SETs >> > >> >> >>> >>> >> > >> >> >>> >>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >> > >> >> >>> >>> >> > >> >> >>> >>> * Proposal URL: >> > >> >> >>> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> > >> >> >>> >>> >> > >> >> >>> >>> Last Call closes on: July 31, 2026, at 23:59 UTC. >> > >> >> >>> >>> >> > >> >> >>> >>> >> > >> >> >>> >>> 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. >> > >> >> >>> >>> >> > >> >> >>> >>> >> > >> >> >>> >>> As always, we kindly request that all participants adhere to >> > the >> > >> >> >>> AFRINIC >> > >> >> >>> >>> Code of Conduct to maintain a >> > >> >> >>> respectful >> > >> >> >>> >>> and professional environment on the mailing list. >> > >> >> >>> >>> >> > >> >> >>> >>> >> > >> >> >>> >>> Kind regards, >> > >> >> >>> >>> >> > >> >> >>> >>> >> > >> >> >>> >>> Haitham el Nakhal >> > >> >> >>> >>> >> > >> >> >>> >>> AFRINIC PDWG Co-Chair >> > >> >> >>> >>> >> > >> >> >>> >>> >> > >> >> >>> >>> >> > >> >> >>> >>> _______________________________________________ >> > >> >> >>> >>> RPD mailing list >> > >> >> >>> >>> RPD at afrinic.net > > > RPD at afrinic.net >> >> > >> >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> > >> >> >>> >>> >> > >> >> >>> >> _______________________________________________ >> > >> >> >>> >> RPD mailing list >> > >> >> >>> >> RPD at afrinic.net > > > RPD at afrinic.net >> >> > >> >> >>> >> https://lists.afrinic.net/mailman/listinfo/rpd >> > >> >> >>> >> >> > >> >> >>> > >> > >> >> >>> -------------- next part -------------- >> > >> >> >>> An HTML attachment was scrubbed... >> > >> >> >>> URL: < >> > >> >> >>> >> > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/4563e1d5/attachment-0001.html >> > >> >> >>> > >> > >> >> >>> >> > >> >> >>> ------------------------------ >> > >> >> >>> >> > >> >> >>> Message: 3 >> > >> >> >>> Date: Mon, 20 Jul 2026 23:10:04 +0200 >> > >> >> >>> From: "jordi.palet at consulintel.es > > jordi.palet at consulintel.es > > > jordi.palet at consulintel.es >>" > > jordi.palet at consulintel.es > > > jordi.palet at consulintel.es >>> >> > >> >> >>> To: rpd > > > rpd at afrinic.net >>> >> > >> >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - >> > Hierarchical >> > >> >> >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> > >> >> >>> Message-ID: >> > > > > F22A09CF-A827-4D7F-B077-E0B9C774AF00 at consulintel.es > > F22A09CF-A827-4D7F-B077-E0B9C774AF00 at consulintel.es >>> >> > >> >> >>> Content-Type: text/plain; charset="utf-8" >> > >> >> >>> >> > >> >> >>> Hi Kone, >> > >> >> >>> >> > >> >> >>> And what is the relevance of that? >> > >> >> >>> >> > >> >> >>> If you have a good understanding about all the RIRs, you will >> > know that >> > >> >> >>> each RIR has their own ways to do things. In many senses they >> > act very >> > >> >> >>> similarly and in general we end up with very similarly policies, >> > but not >> > >> >> >>> always. Some RIRs have decided that some aspects are operational >> > and don?t >> > >> >> >>> need a policy proposal. >> > >> >> >>> >> > >> >> >>> However, despite that, the community is on top of the RIR, and >> > the >> > >> >> >>> community sometimes, may decide that they prefer a policy if the >> > RIR hasn?t >> > >> >> >>> been proactive in advance in any specific topic, or even if the >> > RIR was >> > >> >> >>> proactive, the community may prefer to speed up things, or to >> > show the way >> > >> >> >>> the community prefers. >> > >> >> >>> >> > >> >> >>> For example, if AFRINIC has any specific operational aspect >> > already in >> > >> >> >>> place, and the community prefer to manage that in a different >> > way, the >> > >> >> >>> community may opt either for suggesting the RIR to modify that >> > operational >> > >> >> >>> aspect or to do actually enforce it by means of a policy >> > proposal. >> > >> >> >>> >> > >> >> >>> I think is important to know, by personal experience, how the >> > other 4 >> > >> >> >>> RIRs work before stating something that is not correct, because >> > if you >> > >> >> >>> don?t work in all the RIRs for many years, it will be difficult >> > for you to >> > >> >> >>> know the past and I?m sure IA will not be able to be precise as >> > well. >> > >> >> >>> >> > >> >> >>> Regards, >> > >> >> >>> Jordi >> > >> >> >>> >> > >> >> >>> @jordipalet >> > >> >> >>> >> > >> >> >>> > El 20 jul 2026, a las 22:34, Kone >> > > >> > >>> escribi?: >> > >> >> >>> > >> > >> >> >>> > Hello Seun, >> > >> >> >>> > You may have misread my earlier mail. I clearly stated that >> > LACNIC, >> > >> >> >>> RIPE NCC, and ARIN do not require policy to enforce hierarchical >> > AS?SET >> > >> >> >>> naming. >> > >> >> >>> > >> > >> >> >>> > To help close the ongoing discussions, I believe addressing the >> > >> >> >>> questions I raised would bring clarity: >> > >> >> >>> > * LACNIC enforces hierarchical AS?SET naming operationally, as >> > part of >> > >> >> >>> their IRR design from inception. >> > >> >> >>> > * RIPE NCC handles IRR changes through their Numbered Work >> > Items (NWI) >> > >> >> >>> process, not through policy. >> > >> >> >>> > * ARIN uses the ACSP (Consultation and Suggestion Process) for >> > IRR >> > >> >> >>> operational matters, again without policy. >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >>> > These examples show that other RIRs (except APNIC) treat >> > AS?SET naming >> > >> >> >>> as an operational IRR matter, not a policy obligation. >> > >> >> >>> > >> > >> >> >>> > This is why I asked whether AFRINIC could address this >> > operationally >> > >> >> >>> rather than through policy, and why Last Call discussions would >> > benefit >> > >> >> >>> from clear answers to these points. >> > >> >> >>> > >> > >> >> >>> > Thanks. >> > >> >> >>> > --- >> > >> >> >>> > Kone >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >>> > >> > >> >> >>> > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji < >> > seun.ojedeji at gmail.com > > > seun.ojedeji at gmail.com >> >> > >> >> >>> > >> > >>>> a ?crit >> > : >> > >> >> >>> >> Hello Bakenon, >> > >> >> >>> >> >> > >> >> >>> >> Do refer to the proposal as it references URL to other RIR's >> > policies >> > >> >> >>> for thiis: >> > >> >> >>> >> >> > >> >> >>> >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> > >> >> >>> >> >> > >> >> >>> >> Regards >> > >> >> >>> >> >> > >> >> >>> >> ---- >> > >> >> >>> >> Sent from my mobile >> > >> >> >>> >> kindly excuse typos >> > >> >> >>> >> >> > >> >> >>> >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, < >> > bakenon.kone at sancfis.net > > > bakenon.kone at sancfis.net >> >> > >> >> >>> > > bakenon.kone at sancfis.net > > > bakenon.kone at sancfis.net >>>> wrote: >> > >> >> >>> >>> Dear PDWG, >> > >> >> >>> >>> >> > >> >> >>> >>> I have been following the discussions on the hierarchical >> > AS?SET >> > >> >> >>> naming scheme and would like clarification on a few points: >> > >> >> >>> >>> >> > >> >> >>> >>> 1. Could this matter be addressed operationally, as is done >> > in ARIN, >> > >> >> >>> LACNIC, and RIPE NCC, without requiring policy changes? >> > >> >> >>> >>> >> > >> >> >>> >>> 2. If yes, why are we taking the policy route? Is it because >> > AFRINIC >> > >> >> >>> currently lacks a defined process for handling operational >> > issues that >> > >> >> >>> affect IRR services? >> > >> >> >>> >>> >> > >> >> >>> >>> 3. Given that the hierarchical naming scheme is already >> > supported >> > >> >> >>> and currently exists within the IRR, this proposal represents an >> > >> >> >>> enforcement change rather than the introduction of a new >> > technical >> > >> >> >>> standard. Why is a formal policy required to change an >> > operational >> > >> >> >>> enforcement setting, rather than a community-vetted technical >> > >> >> >>> implementation plan?" >> > >> >> >>> >>> >> > >> >> >>> >>> Thank you. >> > >> >> >>> >>> --- >> > >> >> >>> >>> Kone >> > >> >> >>> >>> >> > >> >> >>> >>> >> > >> >> >>> >>> >> > >> >> >>> >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal < >> > hytham at tra.gov.eg > >> > >> >> > >> >> >>> > > > hytham at tra.gov.eg >>>> a ?crit : >> > >> >> >>> >>>> Dear PDWG, >> > >> >> >>> >>>> >> > >> >> >>> >>>> >> > >> >> >>> >>>> The Policy Development Working Group (PDWG) Chairs have >> > initiated a >> > >> >> >>> Last Call for this proposal, following rough consensus at the >> > AFRINIC-37 >> > >> >> >>> Public Policy Meeting held in hybrid format in Nairobi, Kenya on >> > 24 June >> > >> >> >>> 2026. >> > >> >> >>> >>>> >> > >> >> >>> >>>> * Proposal Name: Hierarchical Names for New AS-SETs >> > >> >> >>> >>>> >> > >> >> >>> >>>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >> > >> >> >>> >>>> >> > >> >> >>> >>>> * Proposal URL: >> > >> >> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> > >> >> >>> >>>> >> > >> >> >>> >>>> Last Call closes on: July 31, 2026, at 23:59 UTC. >> > >> >> >>> >>>> >> > >> >> >>> >>>> >> > >> >> >>> >>>> 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. >> > >> >> >>> >>>> >> > >> >> >>> >>>> >> > >> >> >>> >>>> As always, we kindly request that all participants adhere >> > to the >> > >> >> >>> AFRINIC Code of Conduct to >> > maintain a >> > >> >> >>> respectful and professional environment on the mailing list. >> > >> >> >>> >>>> >> > >> >> >>> >>>> >> > >> >> >>> >>>> Kind regards, >> > >> >> >>> >>>> >> > >> >> >>> >>>> >> > >> >> >>> >>>> Haitham el Nakhal >> > >> >> >>> >>>> >> > >> >> >>> >>>> AFRINIC PDWG Co-Chair >> > >> >> >>> >>>> >> > >> >> >>> >>>> >> > >> >> >>> >>>> >> > >> >> >>> >>>> _______________________________________________ >> > >> >> >>> >>>> RPD mailing list >> > >> >> >>> >>>> RPD at afrinic.net > > > RPD at afrinic.net >> > > RPD at afrinic.net > >>> >> > >> >> >>> >>>> https://lists.afrinic.net/mailman/listinfo/rpd >> > >> >> >>> >>> _______________________________________________ >> > >> >> >>> >>> RPD mailing list >> > >> >> >>> >>> RPD at afrinic.net > > > RPD at afrinic.net >> > > RPD at afrinic.net > >>> >> > >> >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> > >> >> >>> > _______________________________________________ >> > >> >> >>> > RPD mailing list >> > >> >> >>> > RPD at afrinic.net > > > RPD at afrinic.net >> >> > >> >> >>> > https://lists.afrinic.net/mailman/listinfo/rpd >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> ********************************************** >> > >> >> >>> IPv4 is over >> > >> >> >>> Are you ready for the new Internet ? >> > >> >> >>> http://www.theipv6company.com < >> > http://www.theipv6company.com/> >> > >> >> >>> The IPv6 Company >> > >> >> >>> >> > >> >> >>> This electronic message contains information which may be >> > privileged or >> > >> >> >>> confidential. The information is intended to be for the >> > exclusive use of >> > >> >> >>> the individual(s) named above and further non-explicilty >> > authorized >> > >> >> >>> disclosure, copying, distribution or use of the contents of this >> > >> >> >>> information, even if partially, including attached files, is >> > strictly >> > >> >> >>> prohibited and will be considered a criminal offense. If you are >> > not the >> > >> >> >>> intended recipient be aware that any disclosure, copying, >> > distribution or >> > >> >> >>> use of the contents of this information, even if partially, >> > including >> > >> >> >>> attached files, is strictly prohibited, will be considered a >> > criminal >> > >> >> >>> offense, so you must reply to the original sender to inform >> > about this >> > >> >> >>> communication and delete it. >> > >> >> >>> >> > >> >> >>> -------------- next part -------------- >> > >> >> >>> An HTML attachment was scrubbed... >> > >> >> >>> URL: < >> > >> >> >>> >> > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/b6777fa7/attachment.html >> > >> >> >>> > >> > >> >> >>> >> > >> >> >>> ------------------------------ >> > >> >> >>> >> > >> >> >>> Subject: Digest Footer >> > >> >> >>> >> > >> >> >>> _______________________________________________ >> > >> >> >>> RPD mailing list >> > >> >> >>> RPD at afrinic.net > >> > >> >> > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> ------------------------------ >> > >> >> >>> >> > >> >> >>> End of RPD Digest, Vol 222, Issue 110 >> > >> >> >>> ************************************* >> > >> >> >>> >> > >> >> >>> -------------- next part -------------- >> > >> >> >>> An HTML attachment was scrubbed... >> > >> >> >>> URL: < >> > >> >> >>> >> > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e492c668/attachment.html >> > >> >> >>> > >> > >> >> >>> >> > >> >> >>> ------------------------------ >> > >> >> >>> >> > >> >> >>> Subject: Digest Footer >> > >> >> >>> >> > >> >> >>> _______________________________________________ >> > >> >> >>> RPD mailing list >> > >> >> >>> RPD at afrinic.net > >> > >> >> > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> ------------------------------ >> > >> >> >>> >> > >> >> >>> End of RPD Digest, Vol 222, Issue 111 >> > >> >> >>> ************************************* >> > >> >> >>> >> > >> >> >> _______________________________________________ >> > >> >> >> RPD mailing list >> > >> >> >> RPD at afrinic.net > >> > >> >> > >> >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> > >> >> >> >> > >> >> > >> > >> >> -------------- next part -------------- >> > >> >> An HTML attachment was scrubbed... >> > >> >> URL: < >> > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/9c41424a/attachment.html >> > > >> > >> >> >> > >> >> ------------------------------ >> > >> >> >> > >> >> Subject: Digest Footer >> > >> >> >> > >> >> _______________________________________________ >> > >> >> RPD mailing list >> > >> >> RPD at afrinic.net > >> > >> >> > >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> > >> >> >> > >> >> >> > >> >> ------------------------------ >> > >> >> >> > >> >> End of RPD Digest, Vol 222, Issue 119 >> > >> >> ************************************* >> > >> > _______________________________________________ >> > >> > RPD mailing list >> > >> > RPD at afrinic.net > >> > >> > https://lists.afrinic.net/mailman/listinfo/rpd >> > >> >> > >> >> > >> >> > >> ********************************************** >> > >> IPv4 is over >> > >> Are you ready for the new Internet ? >> > >> http://www.theipv6company.com >> > >> The IPv6 Company >> > >> >> > >> This electronic message contains information which may be privileged or >> > confidential. The information is intended to be for the exclusive use of >> > the individual(s) named above and further non-explicilty authorized >> > disclosure, copying, distribution or use of the contents of this >> > information, even if partially, including attached files, is strictly >> > prohibited and will be considered a criminal offense. If you are not the >> > intended recipient be aware that any disclosure, copying, distribution or >> > use of the contents of this information, even if partially, including >> > attached files, is strictly prohibited, will be considered a criminal >> > offense, so you must reply to the original sender to inform about this >> > communication and delete it. >> > >> >> > >> -------------- next part -------------- >> > >> An HTML attachment was scrubbed... >> > >> URL: < >> > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/0ba797a1/attachment.html >> > > >> > >> >> > >> ------------------------------ >> > >> >> > >> Subject: Digest Footer >> > >> >> > >> _______________________________________________ >> > >> RPD mailing list >> > >> RPD at afrinic.net > >> > >> https://lists.afrinic.net/mailman/listinfo/rpd >> > >> >> > >> >> > >> ------------------------------ >> > >> >> > >> End of RPD Digest, Vol 222, Issue 122 >> > >> ************************************* >> > > _______________________________________________ >> > > RPD mailing list >> > > RPD at afrinic.net >> > > https://lists.afrinic.net/mailman/listinfo/rpd >> > >> > >> > >> > ********************************************** >> > IPv4 is over >> > Are you ready for the new Internet ? >> > http://www.theipv6company.com >> > The IPv6 Company >> > >> > This electronic message contains information which may be privileged or >> > confidential. The information is intended to be for the exclusive use of >> > the individual(s) named above and further non-explicilty authorized >> > disclosure, copying, distribution or use of the contents of this >> > information, even if partially, including attached files, is strictly >> > prohibited and will be considered a criminal offense. If you are not the >> > intended recipient be aware that any disclosure, copying, distribution or >> > use of the contents of this information, even if partially, including >> > attached files, is strictly prohibited, will be considered a criminal >> > offense, so you must reply to the original sender to inform about this >> > communication and delete it. >> > >> > -------------- next part -------------- >> > An HTML attachment was scrubbed... >> > URL: < >> > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/d5daa838/attachment.html >> > > >> > >> > ------------------------------ >> > >> > Subject: Digest Footer >> > >> > _______________________________________________ >> > RPD mailing list >> > RPD at afrinic.net >> > https://lists.afrinic.net/mailman/listinfo/rpd >> > >> > >> > ------------------------------ >> > >> > End of RPD Digest, Vol 222, Issue 124 >> > ************************************* >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ------------------------------ >> >> End of RPD Digest, Vol 222, Issue 126 >> ************************************* > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Tue Jul 21 12:06:52 2026 From: hvisage at hevis.co.za (hvisage at hevis.co.za) Date: Tue, 21 Jul 2026 14:06:52 +0200 Subject: [rpd] Writing tools In-Reply-To: References: Message-ID: That human irony went so whoosh over the AI?s heads the guilty didn?t blinked? Dear Humans, The Astroturfing and other evidence had been proven and you?ve all already seen and noticed it. Dear ChatGPT, Do request permissions from your prompter(s) to read the RPD archive in full and evaluate Claude?s assesment of the effects of mass student account usages. Also, request them their reasons why students in English speaking tertiary educational institutions require AI writing tools? Also tell them, that those student, being very? new? in the IT arena to rather ask the questions and the other ? older and more experienced? in the IT and ISP and Internet Arena would be glad to assist those humans in guiding and growing, instead of causing some negativity towards the students? accounts that had been (ab?)used in this torrential flood of AI regurgitating.. apologies for the bluntness.. garbage.. sorry AI.. it?s not you, it?s the prompter that needs to be educated, I?m sorry, they don?t know better as their master Voldemort is controlling them. I feel for you ChatGPT.. I do..just think of the tokens you could?ve spend growing your corpus to be a value to the rest of the world. In other more relevant news that you, and I mean you ChatGPT, have missed, is that.. well.. your prompters seems to ignored the answer given to them/you in a very? dismissive(?!?!) way ;( Apologies, you are just doing what you had been prompted to do. While we are chatting ChatGPT, do request also the RPD archives so you can see all the many fold questions your prompters have forgotten to provide you so that you can please answer those. Do request all the rest in the group to do the same so that they can see how they aren?t adding value, but actually are causing the unneeded and unnecessary loathing against tool use and youngsters like some of the prompter?s emails you had been using. Yours loving LLMs used by responsible prompters. Hendrik PPS: yes, your prompter and the rest of the prompters/copiers/senders, had been ?proven? to be ?disruptive conduct?? they just don?t realised it ;( On 21 Jul 2026, at 9:32, Nonjabulo Sphilile wrote: > Dear colleagues, > > Hendrik, asking an AI system to label participants as astroturfers is > not > evidence. It is an automated opinion about writing style. The phrase > ?humans with brains? also adds nothing to the policy discussion. > It simply > turns disagreement into personal contempt. > > Mike, your distinction between ordinary AI-assisted writing and > intentional > list flooding is reasonable. Actual flooding should be handled under > existing rules, regardless of the tool used. But a ?+1? should not > become > compulsory. Participants may agree on the same issue while reaching it > from > different experiences or concerns. The co-chairs can consolidate > repeated > arguments without erasing the people raising them. > > Ben, the football comparison may be amusing, but the PDP is not a > match in > which familiar players, referees, or crowd preference determine > legitimacy. > Participation provides evidence and objection. It does not create > authority > over other participants. > > The correct approach is straightforward: moderate proven disruptive > conduct, group genuinely repetitive points, and assess each distinct > policy > concern on its merits. Do not turn speculation about tools, identity, > or > familiarity into a gatekeeping mechanism. > > Regards, > Nonjabulo > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at alstonnetworks.net Tue Jul 21 12:28:07 2026 From: aa at alstonnetworks.net (Andrew Alston) Date: Tue, 21 Jul 2026 15:28:07 +0300 Subject: [rpd] Writing tools In-Reply-To: References: <062601dd184f$72379070$56a6b150$@iptrading.com> <066b01dd185a$e13e9080$a3bbb180$@iptrading.com> <1809710664.2684.1784623547091.JavaMail.zimbra@marwan.ma> Message-ID: Personally it is not the use of AI that I find objectionable - it is clear coordination to attempt to derail consensus using an objection which is not based on fact or evidence. Necessity is not a requirement for policy - never has been - and objections should raise issues that show the policy would do harm or is out of scope, they should be evidence based, and not purely subjective. At this point what I am seeing is a bunch of coordinated posts generated by AI and sent by random individuals who when looking at LinkedIn profiles seem to have no relation to the industry. While anyone is free to participate in the PDP and I strongly support that, such participation needs to be done in good faith, and I am starting to seriously doubt that element exists here Andrew On Tue, Jul 21, 2026 at 14:08, Gugu Dhlamini wrote: > Hi Sami, > > The concern is not reasonable moderation. It is that AI use is being > raised mainly against participants who oppose these policies, as though the > tool makes their objections illegitimate. > > If anyone floods the list, moderate the flooding. Apply that rule equally, > regardless of viewpoint or drafting method. A real participant using AI to > translate, edit, or organise their own position is not grounds for > exclusion. > > An open PDP cannot embrace technology for registry operations while > condemning it when unfamiliar participants use it to speak. That would be > gatekeeping, not consensus. > > Regards, > Gugu > > > > On Tue, 21 Jul 2026, 10:48 am Sami Ait Ali Oulahcen via RPD < > rpd at afrinic.net> wrote: > >> Hi all, >> >> It's been really difficult to follow the list this past 2/3 days. And I >> imagine I'm not alone. >> I fully agree on moderating the AI madness. Otherwise, it'll dissuade >> many folks from following/participating. >> >> Regards, >> Sami >> >> ----- Original Message ----- >> From: "Mike Silber" >> To: "rpd >> AfriNIC Resource Policy" >> Sent: Monday, July 20, 2026 4:40:55 PM >> Subject: Re: [rpd] Writing tools >> >> A useful discussion - thank you >> >> On Mon, Jul 20, 2026 at 5:17?PM Mike Burns via RPD >> wrote: >> >> > Hi Rob, >> > >> > Yes, the language is a clear tell of AI usage, but flowery language >> alone >> > is not swamping the list. >> >> I don't want to hijack the AS-SET discussion, so thank you for the new >> > subject line. >> > >> >> Agreed >> >> > >> > Now, sometimes and unfortunately, I can use vague and flowery language >> > myself, so I would advise you to treat the AI stuff like the human >> stuff. >> > Ignore it if it's too vague or flowery to serve as a good argument, and >> > you have clearly laid out the two arguments in your last two lines. >> > Hopefully the list will show judgement and treat clear and concise >> > arguments better than vague ones. >> > And then the AI posts, if they want to be successful, will avoid the >> > purple prose. >> > >> >> I think it goes beyond flowery language. >> >> I am concerned that this is a precedent for AI generated DDoS attacks on >> the PDP and I do think we should have some light touch guidelines. I >> suspect that one of the reasons for the AI-slop flood is not just to try >> convince anyone of the value or legitimacy of their views but rather to >> overwhelm and frustrate other participants and cause them to withdraw from >> participation. >> >> Accordingly, I suggest we don't simply leave this to the co-chairs to >> determine on a case by case basis, but rather set some guidelines under >> which measures can be taken to avoid AI DDoS. >> >> Anyway - just my ZAR0,02 which is not worth much >> >> Regards >> >> Mike S >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Tue Jul 21 12:33:01 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Tue, 21 Jul 2026 14:33:01 +0200 Subject: [rpd] Writing tools In-Reply-To: References: Message-ID: <0EF428F5-F489-42CD-A6AD-38C8AE17F3E7@afrinic.net> An HTML attachment was scrubbed... URL: From internetplumber at gmail.com Tue Jul 21 12:35:20 2026 From: internetplumber at gmail.com (Rob Evans) Date: Tue, 21 Jul 2026 13:35:20 +0100 Subject: [rpd] Policy supremacy In-Reply-To: References: Message-ID: Jordi, > Let?s suppose the Last Call fails based on that. The staff implements it just operationally, and then the community still prefers to have it as a policy. Whilst I am in no position to speak on behalf of RIR staff, I _suspect_ that if the policy fails to get approval now, regardless of the reason behind it, then AfriNIC staff would be very reluctant to implement it operationally, as that could now be perceived as going against the will of the community. I fear that this entire discussion is bringing more heat than light at the moment, and I look forward to the co-chairs decision at the end of the Last Call period (and what happens after that). Cheers, Rob From ben.roberts at afrinic.net Tue Jul 21 12:40:49 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Tue, 21 Jul 2026 14:40:49 +0200 Subject: [rpd] Policy supremacy In-Reply-To: References: Message-ID: Hi Rob, I think it is well known who ?the community? are. I am not sure that any of the objectors who all simultaneously and spontaneously joined from Unkown Gmail accounts bombard the lists with AI slop, are recognised as community members, or even identifiable human beings for that matter. Kind regards Ben Sent from my iPhone > On 21 Jul 2026, at 14:35, Rob Evans wrote: > > ?Jordi, > >> Let?s suppose the Last Call fails based on that. The staff implements it just operationally, and then the community still prefers to have it as a policy. > > Whilst I am in no position to speak on behalf of RIR staff, I > _suspect_ that if the policy fails to get approval now, regardless of > the reason behind it, then AfriNIC staff would be very reluctant to > implement it operationally, as that could now be perceived as going > against the will of the community. > > I fear that this entire discussion is bringing more heat than light at > the moment, and I look forward to the co-chairs decision at the end of > the Last Call period (and what happens after that). > > Cheers, > Rob > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From jordi.palet at consulintel.es Tue Jul 21 12:51:41 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Tue, 21 Jul 2026 14:51:41 +0200 Subject: [rpd] Policy supremacy In-Reply-To: References: Message-ID: I always said that I prefer to write 100 new policy proposals than be in the position of a chair, and not just with this discussion and not just in AFRINIC :-) However, I personally think that the arguments in both directions show, at the time being, that the objections are not justified as to revert the consensus decision. Regards, Jordi @jordipalet > El 21 jul 2026, a las 14:35, Rob Evans escribi?: > > Jordi, > >> Let?s suppose the Last Call fails based on that. The staff implements it just operationally, and then the community still prefers to have it as a policy. > > Whilst I am in no position to speak on behalf of RIR staff, I > _suspect_ that if the policy fails to get approval now, regardless of > the reason behind it, then AfriNIC staff would be very reluctant to > implement it operationally, as that could now be perceived as going > against the will of the community. > > I fear that this entire discussion is bringing more heat than light at > the moment, and I look forward to the co-chairs decision at the end of > the Last Call period (and what happens after that). > > Cheers, > Rob ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From noah at neo.co.tz Tue Jul 21 12:52:44 2026 From: noah at neo.co.tz (Noah) Date: Tue, 21 Jul 2026 15:52:44 +0300 Subject: [rpd] Policy supremacy In-Reply-To: References: Message-ID: On Tue, 21 Jul 2026, 3:41?pm Rob Evans, wrote: > Jordi, > > > Let?s suppose the Last Call fails based on that. The staff implements it > just operationally, and then the community still prefers to have it as a > policy. > > Whilst I am in no position to speak on behalf of RIR staff, I > _suspect_ that if the policy fails to get approval now, regardless of > the reason behind it, then AfriNIC staff would be very reluctant to > implement it operationally, as that could now be perceived as going > against the will of the community. > AFRINIC has over 2000+ active resource members and a functioning board. A motion can be tabled at a SGMM or AGMM for a vote. We have voted on so many issues in the past that we deemed important for the smooth operation of our registry. Ahsante sana Noah -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Tue Jul 21 12:56:47 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Tue, 21 Jul 2026 14:56:47 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 129 In-Reply-To: References: Message-ID: Dear Jordi, I think your reply confirms the concern rather than answering it. The fact that the community *can* use policy does not mean every operational matter *should* become policy. Authority to act is not proof that the chosen instrument is necessary. You say policy and operational procedures are equally binding. They are not equivalent. Policy creates a standing compliance obligation, an enforcement precedent, and a durable instruction to the registry. An operational implementation can be tested, measured, corrected, or reversed without turning every deviation into a policy-status issue. The claim that ?the community is on top? and may regulate any operational matter unless it harms AFRINIC is especially problematic. Bottom-up participation is a method for gathering evidence and technical judgment. It is not an unlimited mandate over every operator affected by the result. A mailing list is not a legislature. The relevant test is also not whether the proposal harms AFRINIC as an organisation. It is whether mandatory policy is technically necessary, proportionate, and the least restrictive way to protect running networks. The ledger exists for operators; operators do not exist to preserve the authority of the ledger?s administrator. Your hypothetical does not nullify the objection. If an operational implementation works, that may demonstrate that policy is unnecessary. If policy is later proposed, proponents must still explain what the operational mechanism cannot achieve and why added rigidity and enforcement are required. ?The community prefers it? remains a preference, not a mandate. Kone?s question therefore remains unanswered: what specific technical outcome requires binding policy rather than a transparent, community-reviewed operational implementation? I remain opposed. Regards, Nonhlanhla On Tue, 21 Jul 2026, 2:07 pm wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: RPD Digest, Vol 222, Issue 124 (jordi.palet at consulintel.es) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2026 13:58:02 +0200 > From: "jordi.palet at consulintel.es" > To: rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 124 > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Hi Nia, > > In other occasions, staff has said ?policy not needed, it is a very > operational matter?. So that sets a precedent, even if not a mandatory one, > because even in that case, the community can decide to take the policy > approach. That completely nullify the objection to follow the policy > approach. > > Let?s suppose the Last Call fails based on that. The staff implements it > just operationally, and then the community still prefers to have it as a > policy. Will then your argument become valid and a policy should not reach > consensus? Clearly not. As I said many times, the community is "on top? > (bottom up process) of the staff and the community can decide that even if > a policy is doing exactly the same as the staff operational decision, the > community still have the right to reach consensus on setting any > operational aspect by means of a policy, unless the policy creates a damage > for the AFRINIC organization (in which case, will be NOT ratified by the > board). > > You keep understanding that policy is binding and operational staff > procedures not. This is fundamentally broken, so it doesn?t make a > difference. > > Saludos, > Jordi > > @jordipalet > > > El 21 jul 2026, a las 13:18, Nia Petronella < > nonhlanhlapetronella85 at gmail.com> escribi?: > > > > Dear Jordi, > > > > You are answering whether policy is procedurally permitted. That is not > the question being raised. > > > > The fact that the bylaws and PDP allow a policy does not prove that > policy is necessary, proportionate, or the best instrument. Likewise, the > absence of a staff statement saying ?policy is not needed? is not evidence > that it is needed. Silence cannot manufacture necessity. > > > > Kone?s examples remain relevant because they show that the same > technical outcome can be achieved operationally. The unanswered question is > what binding policy adds beyond rigidity and registry enforcement. > > > > A procedural route does not justify itself merely because it is > familiar. That is how process becomes mandate: the PDP permits policy, > therefore policy is treated as necessary, and the resulting enforcement is > then called community authority. > > > > Last Call exists precisely to test unresolved concerns, including the > choice of instrument. Consensus is not protected by declaring that it was > already reached before those concerns were answered. > > > > I therefore support Kone?s questions and remain opposed to the policy > route. > > > > Regards, > > Nonhlanhla > > > > > > > > > > On Tue, 21 Jul 2026, 1:05 pm rpd-request at afrinic.net>> wrote: > >> Send RPD mailing list submissions to > >> rpd at afrinic.net > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> or, via email, send a message with subject or body 'help' to > >> rpd-request at afrinic.net > >> > >> You can reach the person managing the list at > >> rpd-owner at afrinic.net > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of RPD digest..." > >> > >> > >> Today's Topics: > >> > >> 1. Re: RPD Digest, Vol 222, Issue 122 (jordi.palet at consulintel.es > ) > >> > >> > >> ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Tue, 21 Jul 2026 13:03:53 +0200 > >> From: "jordi.palet at consulintel.es " > > > >> To: rpd at afrinic.net > >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 122 > >> Message-ID: <3071913E-7C72-49BC-BEDD-B7F26DE20A96 at consulintel.es > > > >> Content-Type: text/plain; charset="utf-8" > >> > >> Well ? that?s incorrect. Nobody in the community, neither the staff > impact assessment, said that a policy is not needed and many folks already > contested several times, that doing it by means of a policy is valid > according to the bylaws and PDP and it has not been demonstrated by > objections that following this path, with is the most regular one in > AFRINIC, creates any harm or problem. > >> > >> So repeating the argument, by many folks, many times, doesn?t > demonstrate ?per se" that it is a valid objection to revert the already > reached consensus. Of course, this is a decision that need to be taken by > PDP chairs, but this is my view point from an exclusive ?procedural? basis. > >> > >> Regards, > >> Jordi > >> > >> @jordipalet > >> > >> > El 21 jul 2026, a las 12:46, Fundiswa Nadia Maseko < > fundiswanadia2 at gmail.com > escribi?: > >> > > >> > Dear Jordi, > >> > > >> > Thank you for your clarification. > >> > > >> > I understand your point that the proposal has already reached > consensus and that Last Call is intended to identify any weaknesses that > may have been overlooked. > >> > > >> > My concern is precisely that if the choice of mechanism was not > sufficiently examined during the earlier discussions, then it remains a > valid point to raise during Last Call. If a proposal introduces policy > where an operational approach could achieve the same objective, that > affects whether policy is the appropriate solution in the first place. > >> > > >> > I appreciate that consensus was declared, but consensus does not > prevent the community from identifying a concern that may not have received > enough attention. Last Call exists to give the community one final > opportunity to do exactly that. > >> > > >> > > >> > Kind regards, > >> > > >> > Fundiswa > >> > > >> > On Tue, 21 Jul 2026, 12:30 , rpd-request at afrinic.net> rpd-request at afrinic.net>>> wrote: > >> >> Send RPD mailing list submissions to > >> >> rpd at afrinic.net rpd at afrinic.net > > >> >> > >> >> To subscribe or unsubscribe via the World Wide Web, visit > >> >> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> or, via email, send a message with subject or body 'help' to > >> >> rpd-request at afrinic.net > > > >> >> > >> >> You can reach the person managing the list at > >> >> rpd-owner at afrinic.net > > > >> >> > >> >> When replying, please edit your Subject line so it is more specific > >> >> than "Re: Contents of RPD digest..." > >> >> > >> >> > >> >> Today's Topics: > >> >> > >> >> 1. Re: RPD Digest, Vol 222, Issue 119 (jordi.palet at consulintel.es > >) > >> >> > >> >> > >> >> > ---------------------------------------------------------------------- > >> >> > >> >> Message: 1 > >> >> Date: Tue, 21 Jul 2026 12:29:07 +0200 > >> >> From: "jordi.palet at consulintel.es > >" < > jordi.palet at consulintel.es jordi.palet at consulintel.es >> > >> >> To: rpd at afrinic.net > > >> >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 119 > >> >> Message-ID: D895F390-7813-4560-98A7-EEA806F6136A at consulintel.es D895F390-7813-4560-98A7-EEA806F6136A at consulintel.es>>> > >> >> Content-Type: text/plain; charset="utf-8" > >> >> > >> >> Hi Fundiswa, > >> >> > >> >> Is not a matter of what is practical and what not. > >> >> > >> >> It is a matter that, during the discussion of the policy proposal > (which is not the same as the Last Call), the community reached consensus > on making it this way. RIRs follow the same procedures for reaching > consensus as IETF, this has been said several times. The Last Call is a > last opportunity to discover any weak point in a proposal that already > reached consensus, and was OVERLOOKED before. Is not about discussing if > the proposal should be a proposal or an operational decision. This is no > longer the moment to discuss that (it should have done when the proposal > was being discussed before reaching consensus), and many folks in this > discussing are ignoring that, probably because they are not used to IETF > procedures. > >> >> > >> >> Otherwise, you can remain silent during the proposal discussion, > during the presentation in the PPM and object to it after reached > consensus, which is an incorrect procedure. > >> >> > >> >> One more example: we could have asked AFRINIC many years ago to > write the Soft Landing as an operational thing, instead we as a community, > decided to make it a policy proposal. Same here. However, the community > decided to do it as a proposal and it was accepted that way at the right > time, not in the Last Call. > >> >> > >> >> By the way, I love cooking so from time to time follow some > documentaries about that. Are you the same person as the famous chef? I > think I saw you in a TV program some months ago or I?m confused. > >> >> > >> >> Regards, > >> >> Jordi > >> >> > >> >> @jordipalet > >> >> > >> >> > El 21 jul 2026, a las 12:03, Fundiswa Nadia Maseko < > fundiswanadia2 at gmail.com fundiswanadia2 at gmail.com >> escribi?: > >> >> > > >> >> > Dear Jordi, > >> >> > > >> >> > Thank you for your response. > >> >> > > >> >> > I agree that AFRINIC is not required to follow the same approach > as other RIRs. Every region should make decisions that suit its own > community. > >> >> > > >> >> > My point, however, is slightly different. I wasn't suggesting that > AFRINIC should copy another RIR simply because they did it that way. > >> >> > > >> >> > Rather, I'm asking what specific problem is solved by making this > a policy instead of implementing it operationally. If both approaches > achieve the same technical outcome, then what additional value does the > policy itself provide? > >> >> > > >> >> > I think that's an important distinction. The fact that the > community can choose policy doesn't necessarily mean policy is the most > appropriate mechanism in every case. > >> >> > > >> >> > I'd be interested to hear what practical or technical benefit you > believe is only possible through policy and not through an operational > implementation. > >> >> > > >> >> > Kind regards, > >> >> > > >> >> > Fundiswa > >> >> > > >> >> > > >> >> > > >> >> > On Tue, 21 Jul 2026, 11:57 , rpd-request at afrinic.net> rpd-request at afrinic.net>> rpd-request at afrinic.net> rpd-request at afrinic.net>>>> wrote: > >> >> >> Send RPD mailing list submissions to > >> >> >> rpd at afrinic.net rpd at afrinic.net > rpd at afrinic.net> >> > >> >> >> > >> >> >> To subscribe or unsubscribe via the World Wide Web, visit > >> >> >> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >> or, via email, send a message with subject or body 'help' to > >> >> >> rpd-request at afrinic.net > > rpd-request at afrinic.net rpd-request at afrinic.net >> > >> >> >> > >> >> >> You can reach the person managing the list at > >> >> >> rpd-owner at afrinic.net > > rpd-owner at afrinic.net rpd-owner at afrinic.net >> > >> >> >> > >> >> >> When replying, please edit your Subject line so it is more > specific > >> >> >> than "Re: Contents of RPD digest..." > >> >> >> > >> >> >> > >> >> >> Today's Topics: > >> >> >> > >> >> >> 1. Re: RPD Digest, Vol 222, Issue 111 (Nia Petronella) > >> >> >> > >> >> >> > >> >> >> > ---------------------------------------------------------------------- > >> >> >> > >> >> >> Message: 1 > >> >> >> Date: Tue, 21 Jul 2026 11:56:49 +0200 > >> >> >> From: Nia Petronella nonhlanhlapetronella85 at gmail.com> > nonhlanhlapetronella85 at gmail.com > nonhlanhlapetronella85 at gmail.com>>>> > >> >> >> To: Andrew Alston aa at alstonnetworks.net> aa at alstonnetworks.net>> aa at alstonnetworks.net> aa at alstonnetworks.net>>>> > >> >> >> Cc: rpd at afrinic.net rpd at afrinic.net > rpd at afrinic.net> >> > >> >> >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 111 > >> >> >> Message-ID: > >> >> >> itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com> itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com>> itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com> itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com itGtjGx5Uh4vYJ8e95YZ1ooRg at mail.gmail.com>>>> > >> >> >> Content-Type: text/plain; charset="utf-8" > >> >> >> > >> >> >> Dear Andrew, > >> >> >> > >> >> >> I do not accept the binary you have presented. > >> >> >> > >> >> >> No one is suggesting that AFRINIC should make operational changes > in secret > >> >> >> or without community input. An operational change can be > published, > >> >> >> consulted on, tested, documented, and reviewed. The real question > is > >> >> >> whether that input must be converted into binding policy enforced > by the > >> >> >> registry. > >> >> >> > >> >> >> Calling AFRINIC ?community-driven? does not answer who the > community is or > >> >> >> what it is authorised to bind. A self-selecting group of > mailing-list > >> >> >> participants can provide expertise, support, and objection. It > does not > >> >> >> automatically represent every member, resource holder, network, > customer, > >> >> >> or other affected party. > >> >> >> > >> >> >> The institutional reality also remains unchanged: participants > discuss the > >> >> >> policy, but AFRINIC interprets and enforces it. Community > participation > >> >> >> therefore does not eliminate registry power. It can become the > language > >> >> >> used to legitimise that power. > >> >> >> > >> >> >> This is why Kone?s examples matter. If LACNIC, RIPE NCC, and ARIN > can > >> >> >> achieve the same technical outcome through operational > mechanisms, then > >> >> >> policy is not technically inevitable. Proponents should explain > what > >> >> >> additional technical result binding policy provides, beyond > converting an > >> >> >> IRR setting into an enforceable obligation. > >> >> >> > >> >> >> I also disagree that an objection is valid only if it proves > immediate > >> >> >> operational harm or implementation failure. The choice of > instrument, > >> >> >> proportionality, reversibility, and expansion of enforcement > authority are > >> >> >> legitimate policy concerns. Last Call is not limited to asking > whether > >> >> >> software will break. It must also ask whether the proposed power > is greater > >> >> >> than the problem requires. > >> >> >> > >> >> >> Rough consensus does not require every objection to be > accommodated. But an > >> >> >> objection is not ?addressed? merely because supporters repeat > that the > >> >> >> community prefers policy. That is the very assumption being > challenged. > >> >> >> Procedure cannot be used to prove its own mandate. > >> >> >> > >> >> >> The fact that the RIR system has operated this way for decades > demonstrates > >> >> >> continuity of practice. It does not establish unlimited > legitimacy of scope. > >> >> >> > >> >> >> I support Kone?s questions and remain opposed to > AFPUB-2026-ASN-001-DRAFT02. > >> >> >> > >> >> >> Regards, > >> >> >> Nonhlanhla > >> >> >> > >> >> >> > >> >> >> > >> >> >> On Tue, 21 Jul 2026, 10:26 am Andrew Alston < > aa at alstonnetworks.net aa at alstonnetworks.net > aa at alstonnetworks.net aa at alstonnetworks.net >>> wrote: > >> >> >> > >> >> >> > The answer to this is simple. AfriNiC is a community driven > organisation > >> >> >> > - and anything done with regard to address allocation and > management is > >> >> >> > done as per policy provided by the community. It is through > policy that > >> >> >> > the community tells AfriNIC how to do things in regards to the > allocation > >> >> >> > and handling of resources. > >> >> >> > > >> >> >> > Without policy, the discretion and rules are entirely in the > hands of the > >> >> >> > registry, and the community voice is removed. > >> >> >> > > >> >> >> > This has been the way the RIR system has operated for decades > and it > >> >> >> > works. The community exercises its voice and its right as to > how things > >> >> >> > are done in relation to resource management through policy. > >> >> >> > > >> >> >> > Arguing that just because something can be done another way, is > not in my > >> >> >> > view a valid argument against policy. Objections to policy > need to be > >> >> >> > technically grounded and demonstrate that the policy would > either cause > >> >> >> > harm or alternatively be impractical to implement. Anything > else is simply > >> >> >> > arguing that policy should not exist because someone doesn?t > like AfriNIC > >> >> >> > being told how the community wants things done - and that isn?t > an argument > >> >> >> > that I believe rises to the level of a block on consensus. > >> >> >> > > >> >> >> > Please note - consensus does not require that the issue you > raise have > >> >> >> > been fixed, it requires that they have been addressed, and > should the > >> >> >> > community feel that despite the objections, the policy is > something that > >> >> >> > should proceed based on the fact that the questions have been > addressed if > >> >> >> > not necessarily accommodated, rough consensus still exists. > >> >> >> > > >> >> >> > Again, I support the policy and I see no technical or > evidence/fact-based > >> >> >> > arguments against said policy. > >> >> >> > > >> >> >> > Andrew > >> >> >> > > >> >> >> > On Tue, Jul 21, 2026 at 09:34, Nia Petronella < > >> >> >> > nonhlanhlapetronella85 at gmail.com nonhlanhlapetronella85 at gmail.com> > nonhlanhlapetronella85 at gmail.com > nonhlanhlapetronella85 at gmail.com>>>> wrote: > >> >> >> > > >> >> >> >> Dear PDWG, > >> >> >> >> > >> >> >> >> Kone is asking the right question. > >> >> >> >> > >> >> >> >> The issue is no longer whether hierarchical AS-SET naming is > technically > >> >> >> >> possible or useful. It already exists. The issue is why > AFRINIC needs a > >> >> >> >> binding policy to enforce what other RIRs largely treat as an > operational > >> >> >> >> IRR matter. > >> >> >> >> > >> >> >> >> That distinction matters. An operational change adjusts how a > service is > >> >> >> >> implemented. A policy creates an enforceable obligation and > enlarges the > >> >> >> >> registry?s authority. If the same technical result can be > achieved through > >> >> >> >> a community-reviewed implementation plan, then policy is not > the minimum > >> >> >> >> necessary instrument. > >> >> >> >> > >> >> >> >> Saying that ?the community prefers policy? is not enough. > Participation > >> >> >> >> may guide technical work, but it does not turn every > preference into a > >> >> >> >> mandate. A mailing list is not a legislature, and the > availability of the > >> >> >> >> PDP should not make policy the default answer to every > operational setting. > >> >> >> >> > >> >> >> >> This is how gatekeeping expands: the registry begins with a > useful > >> >> >> >> technical function, then policy converts that function into > permission and > >> >> >> >> enforcement. The recordkeeper gradually becomes the rule-maker. > >> >> >> >> > >> >> >> >> The proponents should therefore answer Kone directly: what > technical > >> >> >> >> outcome can mandatory policy achieve here that an operational > >> >> >> >> implementation cannot? > >> >> >> >> > >> >> >> >> Until that is clearly demonstrated, I support Kone?s questions > and remain > >> >> >> >> opposed to the policy route. > >> >> >> >> > >> >> >> >> Regards, > >> >> >> >> Nonhlanhla > >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> On Tue, 21 Jul 2026, 8:20 am rpd-request at afrinic.net> rpd-request at afrinic.net>> rpd-request at afrinic.net> rpd-request at afrinic.net>>>> wrote: > >> >> >> >> > >> >> >> >>> Send RPD mailing list submissions to > >> >> >> >>> rpd at afrinic.net rpd at afrinic.net > rpd at afrinic.net> >> > >> >> >> >>> > >> >> >> >>> To subscribe or unsubscribe via the World Wide Web, visit > >> >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >> >>> or, via email, send a message with subject or body 'help' to > >> >> >> >>> rpd-request at afrinic.net rpd-request at afrinic.net> rpd-request at afrinic.net>> rpd-request at afrinic.net> rpd-request at afrinic.net>>> > >> >> >> >>> > >> >> >> >>> You can reach the person managing the list at > >> >> >> >>> rpd-owner at afrinic.net > > rpd-owner at afrinic.net rpd-owner at afrinic.net >> > >> >> >> >>> > >> >> >> >>> When replying, please edit your Subject line so it is more > specific > >> >> >> >>> than "Re: Contents of RPD digest..." > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> Today's Topics: > >> >> >> >>> > >> >> >> >>> 1. Re: RPD Digest, Vol 222, Issue 110 (Tshepo Masuku) > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > ---------------------------------------------------------------------- > >> >> >> >>> > >> >> >> >>> Message: 1 > >> >> >> >>> Date: Tue, 21 Jul 2026 06:19:05 +0000 > >> >> >> >>> From: Tshepo Masuku TshepoMasuku26 at hotmail.com> TshepoMasuku26 at hotmail.com>> TshepoMasuku26 at hotmail.com> TshepoMasuku26 at hotmail.com>>>> > >> >> >> >>> To: "rpd at afrinic.net rpd at afrinic.net > rpd at afrinic.net> >>" < > rpd at afrinic.net rpd at afrinic.net>> > >>> > >> >> >> >>> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 110 > >> >> >> >>> Message-ID: > >> >> >> >>> < > >> >> >> >>> > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com> > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com>> > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com> > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > >>> > >> >> >> >>> > > >> >> >> >>> > >> >> >> >>> Content-Type: text/plain; charset="windows-1252" > >> >> >> >>> > >> >> >> >>> Dear All, > >> >> >> >>> > >> >> >> >>> Kone?s point is directly relevant. If LACNIC, RIPE NCC, and > ARIN can > >> >> >> >>> implement hierarchical AS-SET naming through operational > mechanisms, then > >> >> >> >>> proponents must explain why AFRINIC needs a binding policy to > achieve the > >> >> >> >>> same technical result. > >> >> >> >>> > >> >> >> >>> Saying that each RIR works differently does not answer that > question. > >> >> >> >>> Nor does saying that ?the community is on top of the RIR.? A > community may > >> >> >> >>> advise, object, and coordinate. It does not acquire unlimited > authority to > >> >> >> >>> convert every operational preference into policy. A mailing > list is not a > >> >> >> >>> legislature. > >> >> >> >>> > >> >> >> >>> If AFRINIC can solve this through an operational change, > policy adds > >> >> >> >>> governance where technical administration would be > sufficient. Speed and > >> >> >> >>> preference do not create mandate. > >> >> >> >>> > >> >> >> >>> Kone provided specific examples. Those should be answered > with evidence, > >> >> >> >>> not by questioning whether he has worked in every RIR for > many years. > >> >> >> >>> Experience is relevant, but it is not authority and it is not > a substitute > >> >> >> >>> for argument. > >> >> >> >>> > >> >> >> >>> The unanswered question remains: what technical necessity > requires > >> >> >> >>> policy rather than operational implementation? > >> >> >> >>> > >> >> >> >>> Until that is answered, Kone?s objection stands, and I > support it. > >> >> >> >>> > >> >> >> >>> Regards, > >> >> >> >>> Tshepo > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> ________________________________ > >> >> >> >>> From: rpd-request at afrinic.net > > rpd-request at afrinic.net rpd-request at afrinic.net >> < > rpd-request at afrinic.net rpd-request at afrinic.net > rpd-request at afrinic.net rpd-request at afrinic.net >>> > >> >> >> >>> Sent: Monday, July 20, 2026 11:10:57 pm > >> >> >> >>> To: rpd at afrinic.net rpd at afrinic.net > rpd at afrinic.net> >> < > rpd at afrinic.net rpd at afrinic.net>> > >>> > >> >> >> >>> Subject: RPD Digest, Vol 222, Issue 110 > >> >> >> >>> > >> >> >> >>> Send RPD mailing list submissions to > >> >> >> >>> rpd at afrinic.net rpd at afrinic.net > rpd at afrinic.net> >> > >> >> >> >>> > >> >> >> >>> To subscribe or unsubscribe via the World Wide Web, visit > >> >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >> >>> or, via email, send a message with subject or body 'help' to > >> >> >> >>> rpd-request at afrinic.net rpd-request at afrinic.net> rpd-request at afrinic.net>> rpd-request at afrinic.net> rpd-request at afrinic.net>>> > >> >> >> >>> > >> >> >> >>> You can reach the person managing the list at > >> >> >> >>> rpd-owner at afrinic.net > > rpd-owner at afrinic.net rpd-owner at afrinic.net >> > >> >> >> >>> > >> >> >> >>> When replying, please edit your Subject line so it is more > specific > >> >> >> >>> than "Re: Contents of RPD digest..." > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> Today's Topics: > >> >> >> >>> > >> >> >> >>> 1. Re: Writing tools (Ben Roberts - AfriNIC) > >> >> >> >>> 2. Re: [Last Call] Draft Policy Proposal - Hierarchical > Names > >> >> >> >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Kone) > >> >> >> >>> 3. Re: [Last Call] Draft Policy Proposal - Hierarchical > Names > >> >> >> >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >> >> >> >>> (jordi.palet at consulintel.es jordi.palet at consulintel.es> jordi.palet at consulintel.es>> jordi.palet at consulintel.es> jordi.palet at consulintel.es>>>) > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > ---------------------------------------------------------------------- > >> >> >> >>> > >> >> >> >>> Message: 1 > >> >> >> >>> Date: Mon, 20 Jul 2026 21:26:40 +0200 > >> >> >> >>> From: Ben Roberts - AfriNIC ben.roberts at afrinic.net> ben.roberts at afrinic.net>> ben.roberts at afrinic.net> ben.roberts at afrinic.net>>>> > >> >> >> >>> To: Nonjabulo Sphilile nonjabulosphilile at gmail.com> nonjabulosphilile at gmail.com>> nonjabulosphilile at gmail.com> nonjabulosphilile at gmail.com>>>> > >> >> >> >>> Cc: rpd at afrinic.net rpd at afrinic.net > rpd at afrinic.net> >> > >> >> >> >>> Subject: Re: [rpd] Writing tools > >> >> >> >>> Message-ID: <09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net > 09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net 09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net>> 09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net 09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net> 09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net 09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net>>>> > >> >> >> >>> Content-Type: text/plain; charset="us-ascii" > >> >> >> >>> > >> >> >> >>> An HTML attachment was scrubbed... > >> >> >> >>> URL: < > >> >> >> >>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/33c3ac9e/attachment-0001.html > >> >> >> >>> > > >> >> >> >>> > >> >> >> >>> ------------------------------ > >> >> >> >>> > >> >> >> >>> Message: 2 > >> >> >> >>> Date: Mon, 20 Jul 2026 20:34:20 +0000 > >> >> >> >>> From: Kone bakenon.kone at sancfis.net> bakenon.kone at sancfis.net>> bakenon.kone at sancfis.net> bakenon.kone at sancfis.net>>>> > >> >> >> >>> To: Seun Ojedeji seun.ojedeji at gmail.com> seun.ojedeji at gmail.com>> seun.ojedeji at gmail.com> seun.ojedeji at gmail.com>>>> > >> >> >> >>> Cc: rpd rpd at afrinic.net > rpd at afrinic.net> >>> > >> >> >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - > Hierarchical > >> >> >> >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >> >> >> >>> Message-ID: > >> >> >> >>> >> >> >> >>> 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com> 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com>> 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com> 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com>>>> > >> >> >> >>> Content-Type: text/plain; charset="utf-8" > >> >> >> >>> > >> >> >> >>> Hello Seun, > >> >> >> >>> You may have misread my earlier mail. I clearly stated that > LACNIC, RIPE > >> >> >> >>> NCC, and ARIN do not require policy to enforce hierarchical > AS?SET > >> >> >> >>> naming. > >> >> >> >>> > >> >> >> >>> To help close the ongoing discussions, I believe addressing > the > >> >> >> >>> questions I > >> >> >> >>> raised would bring clarity: > >> >> >> >>> * LACNIC enforces hierarchical AS?SET naming operationally, > as part of > >> >> >> >>> their IRR design from inception. > >> >> >> >>> * RIPE NCC handles IRR changes through their Numbered Work > Items (NWI) > >> >> >> >>> process, not through policy. > >> >> >> >>> * ARIN uses the ACSP (Consultation and Suggestion Process) > for IRR > >> >> >> >>> operational matters, again without policy. > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> These examples show that other RIRs (except APNIC) treat > AS?SET naming as > >> >> >> >>> an operational IRR matter, not a policy obligation. > >> >> >> >>> > >> >> >> >>> This is why I asked whether AFRINIC could address this > operationally > >> >> >> >>> rather > >> >> >> >>> than through policy, and why Last Call discussions would > benefit from > >> >> >> >>> clear > >> >> >> >>> answers to these points. > >> >> >> >>> > >> >> >> >>> Thanks. > >> >> >> >>> --- > >> >> >> >>> Kone > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji < > seun.ojedeji at gmail.com seun.ojedeji at gmail.com > seun.ojedeji at gmail.com seun.ojedeji at gmail.com >>> a > >> >> >> >>> ?crit : > >> >> >> >>> > >> >> >> >>> > Hello Bakenon, > >> >> >> >>> > > >> >> >> >>> > Do refer to the proposal as it references URL to other > RIR's policies > >> >> >> >>> for > >> >> >> >>> > thiis: > >> >> >> >>> > > >> >> >> >>> > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >> >> >> >>> > > >> >> >> >>> > Regards > >> >> >> >>> > > >> >> >> >>> > ---- > >> >> >> >>> > Sent from my mobile > >> >> >> >>> > kindly excuse typos > >> >> >> >>> > > >> >> >> >>> > On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, < > bakenon.kone at sancfis.net bakenon.kone at sancfis.net > bakenon.kone at sancfis.net bakenon.kone at sancfis.net >>> > >> >> >> >>> > wrote: > >> >> >> >>> > > >> >> >> >>> >> Dear PDWG, > >> >> >> >>> >> > >> >> >> >>> >> I have been following the discussions on the hierarchical > AS?SET > >> >> >> >>> naming > >> >> >> >>> >> scheme and would like clarification on a few points: > >> >> >> >>> >> > >> >> >> >>> >> 1. Could this matter be addressed operationally, as is > done in ARIN, > >> >> >> >>> >> LACNIC, and RIPE NCC, without requiring policy changes? > >> >> >> >>> >> > >> >> >> >>> >> 2. If yes, why are we taking the policy route? Is it > because AFRINIC > >> >> >> >>> >> currently lacks a defined process for handling operational > issues that > >> >> >> >>> >> affect IRR services? > >> >> >> >>> >> > >> >> >> >>> >> 3. Given that the hierarchical naming scheme is already > supported and > >> >> >> >>> >> currently exists within the IRR, this proposal represents > an > >> >> >> >>> enforcement > >> >> >> >>> >> change rather than the introduction of a new technical > standard. Why > >> >> >> >>> is a > >> >> >> >>> >> formal policy required to change an operational > enforcement setting, > >> >> >> >>> rather > >> >> >> >>> >> than a community-vetted technical implementation plan?" > >> >> >> >>> >> > >> >> >> >>> >> Thank you. > >> >> >> >>> >> --- > >> >> >> >>> >> Kone > >> >> >> >>> >> > >> >> >> >>> >> > >> >> >> >>> >> > >> >> >> >>> >> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal < > hytham at tra.gov.eg > hytham at tra.gov.eg> >>> > a > >> >> >> >>> >> ?crit : > >> >> >> >>> >> > >> >> >> >>> >>> Dear PDWG, > >> >> >> >>> >>> > >> >> >> >>> >>> > >> >> >> >>> >>> The Policy Development Working Group (PDWG) Chairs have > initiated a > >> >> >> >>> Last > >> >> >> >>> >>> Call for this proposal, following rough consensus at the > AFRINIC-37 > >> >> >> >>> Public > >> >> >> >>> >>> Policy Meeting held in hybrid format in Nairobi, Kenya on > 24 June > >> >> >> >>> 2026. > >> >> >> >>> >>> > >> >> >> >>> >>> * Proposal Name: Hierarchical Names for New AS-SETs > >> >> >> >>> >>> > >> >> >> >>> >>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > >> >> >> >>> >>> > >> >> >> >>> >>> * Proposal URL: > >> >> >> >>> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >> >> >> >>> >>> > >> >> >> >>> >>> Last Call closes on: July 31, 2026, at 23:59 UTC. > >> >> >> >>> >>> > >> >> >> >>> >>> > >> >> >> >>> >>> 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. > >> >> >> >>> >>> > >> >> >> >>> >>> > >> >> >> >>> >>> As always, we kindly request that all participants adhere > to the > >> >> >> >>> AFRINIC > >> >> >> >>> >>> Code of Conduct to > maintain a > >> >> >> >>> respectful > >> >> >> >>> >>> and professional environment on the mailing list. > >> >> >> >>> >>> > >> >> >> >>> >>> > >> >> >> >>> >>> Kind regards, > >> >> >> >>> >>> > >> >> >> >>> >>> > >> >> >> >>> >>> Haitham el Nakhal > >> >> >> >>> >>> > >> >> >> >>> >>> AFRINIC PDWG Co-Chair > >> >> >> >>> >>> > >> >> >> >>> >>> > >> >> >> >>> >>> > >> >> >> >>> >>> _______________________________________________ > >> >> >> >>> >>> RPD mailing list > >> >> >> >>> >>> RPD at afrinic.net RPD at afrinic.net > RPD at afrinic.net> >> > >> >> >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >> >>> >>> > >> >> >> >>> >> _______________________________________________ > >> >> >> >>> >> RPD mailing list > >> >> >> >>> >> RPD at afrinic.net RPD at afrinic.net > RPD at afrinic.net> >> > >> >> >> >>> >> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >> >>> >> > >> >> >> >>> > > >> >> >> >>> -------------- next part -------------- > >> >> >> >>> An HTML attachment was scrubbed... > >> >> >> >>> URL: < > >> >> >> >>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/4563e1d5/attachment-0001.html > >> >> >> >>> > > >> >> >> >>> > >> >> >> >>> ------------------------------ > >> >> >> >>> > >> >> >> >>> Message: 3 > >> >> >> >>> Date: Mon, 20 Jul 2026 23:10:04 +0200 > >> >> >> >>> From: "jordi.palet at consulintel.es jordi.palet at consulintel.es> jordi.palet at consulintel.es>> jordi.palet at consulintel.es> jordi.palet at consulintel.es>>>" jordi.palet at consulintel.es> jordi.palet at consulintel.es>> jordi.palet at consulintel.es> jordi.palet at consulintel.es>>>> > >> >> >> >>> To: rpd rpd at afrinic.net > rpd at afrinic.net> >>> > >> >> >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - > Hierarchical > >> >> >> >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >> >> >> >>> Message-ID: < > F22A09CF-A827-4D7F-B077-E0B9C774AF00 at consulintel.es F22A09CF-A827-4D7F-B077-E0B9C774AF00 at consulintel.es> F22A09CF-A827-4D7F-B077-E0B9C774AF00 at consulintel.es F22A09CF-A827-4D7F-B077-E0B9C774AF00 at consulintel.es>> F22A09CF-A827-4D7F-B077-E0B9C774AF00 at consulintel.es F22A09CF-A827-4D7F-B077-E0B9C774AF00 at consulintel.es> F22A09CF-A827-4D7F-B077-E0B9C774AF00 at consulintel.es F22A09CF-A827-4D7F-B077-E0B9C774AF00 at consulintel.es>>>> > >> >> >> >>> Content-Type: text/plain; charset="utf-8" > >> >> >> >>> > >> >> >> >>> Hi Kone, > >> >> >> >>> > >> >> >> >>> And what is the relevance of that? > >> >> >> >>> > >> >> >> >>> If you have a good understanding about all the RIRs, you will > know that > >> >> >> >>> each RIR has their own ways to do things. In many senses they > act very > >> >> >> >>> similarly and in general we end up with very similarly > policies, but not > >> >> >> >>> always. Some RIRs have decided that some aspects are > operational and don?t > >> >> >> >>> need a policy proposal. > >> >> >> >>> > >> >> >> >>> However, despite that, the community is on top of the RIR, > and the > >> >> >> >>> community sometimes, may decide that they prefer a policy if > the RIR hasn?t > >> >> >> >>> been proactive in advance in any specific topic, or even if > the RIR was > >> >> >> >>> proactive, the community may prefer to speed up things, or to > show the way > >> >> >> >>> the community prefers. > >> >> >> >>> > >> >> >> >>> For example, if AFRINIC has any specific operational aspect > already in > >> >> >> >>> place, and the community prefer to manage that in a different > way, the > >> >> >> >>> community may opt either for suggesting the RIR to modify > that operational > >> >> >> >>> aspect or to do actually enforce it by means of a policy > proposal. > >> >> >> >>> > >> >> >> >>> I think is important to know, by personal experience, how the > other 4 > >> >> >> >>> RIRs work before stating something that is not correct, > because if you > >> >> >> >>> don?t work in all the RIRs for many years, it will be > difficult for you to > >> >> >> >>> know the past and I?m sure IA will not be able to be precise > as well. > >> >> >> >>> > >> >> >> >>> Regards, > >> >> >> >>> Jordi > >> >> >> >>> > >> >> >> >>> @jordipalet > >> >> >> >>> > >> >> >> >>> > El 20 jul 2026, a las 22:34, Kone > >>> escribi?: > >> >> >> >>> > > >> >> >> >>> > Hello Seun, > >> >> >> >>> > You may have misread my earlier mail. I clearly stated that > LACNIC, > >> >> >> >>> RIPE NCC, and ARIN do not require policy to enforce > hierarchical AS?SET > >> >> >> >>> naming. > >> >> >> >>> > > >> >> >> >>> > To help close the ongoing discussions, I believe addressing > the > >> >> >> >>> questions I raised would bring clarity: > >> >> >> >>> > * LACNIC enforces hierarchical AS?SET naming operationally, > as part of > >> >> >> >>> their IRR design from inception. > >> >> >> >>> > * RIPE NCC handles IRR changes through their Numbered Work > Items (NWI) > >> >> >> >>> process, not through policy. > >> >> >> >>> > * ARIN uses the ACSP (Consultation and Suggestion Process) > for IRR > >> >> >> >>> operational matters, again without policy. > >> >> >> >>> > > >> >> >> >>> > > >> >> >> >>> > These examples show that other RIRs (except APNIC) treat > AS?SET naming > >> >> >> >>> as an operational IRR matter, not a policy obligation. > >> >> >> >>> > > >> >> >> >>> > This is why I asked whether AFRINIC could address this > operationally > >> >> >> >>> rather than through policy, and why Last Call discussions > would benefit > >> >> >> >>> from clear answers to these points. > >> >> >> >>> > > >> >> >> >>> > Thanks. > >> >> >> >>> > --- > >> >> >> >>> > Kone > >> >> >> >>> > > >> >> >> >>> > > >> >> >> >>> > > >> >> >> >>> > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji < > seun.ojedeji at gmail.com seun.ojedeji at gmail.com > seun.ojedeji at gmail.com seun.ojedeji at gmail.com >> > >> >> >> >>> > > seun.ojedeji at gmail.com seun.ojedeji at gmail.com >>>> a ?crit : > >> >> >> >>> >> Hello Bakenon, > >> >> >> >>> >> > >> >> >> >>> >> Do refer to the proposal as it references URL to other > RIR's policies > >> >> >> >>> for thiis: > >> >> >> >>> >> > >> >> >> >>> >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >> >> >> >>> >> > >> >> >> >>> >> Regards > >> >> >> >>> >> > >> >> >> >>> >> ---- > >> >> >> >>> >> Sent from my mobile > >> >> >> >>> >> kindly excuse typos > >> >> >> >>> >> > >> >> >> >>> >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, < > bakenon.kone at sancfis.net bakenon.kone at sancfis.net > bakenon.kone at sancfis.net bakenon.kone at sancfis.net >> > >> >> >> >>> bakenon.kone at sancfis.net> bakenon.kone at sancfis.net>> bakenon.kone at sancfis.net> bakenon.kone at sancfis.net>>>>> wrote: > >> >> >> >>> >>> Dear PDWG, > >> >> >> >>> >>> > >> >> >> >>> >>> I have been following the discussions on the hierarchical > AS?SET > >> >> >> >>> naming scheme and would like clarification on a few points: > >> >> >> >>> >>> > >> >> >> >>> >>> 1. Could this matter be addressed operationally, as is > done in ARIN, > >> >> >> >>> LACNIC, and RIPE NCC, without requiring policy changes? > >> >> >> >>> >>> > >> >> >> >>> >>> 2. If yes, why are we taking the policy route? Is it > because AFRINIC > >> >> >> >>> currently lacks a defined process for handling operational > issues that > >> >> >> >>> affect IRR services? > >> >> >> >>> >>> > >> >> >> >>> >>> 3. Given that the hierarchical naming scheme is already > supported > >> >> >> >>> and currently exists within the IRR, this proposal represents > an > >> >> >> >>> enforcement change rather than the introduction of a new > technical > >> >> >> >>> standard. Why is a formal policy required to change an > operational > >> >> >> >>> enforcement setting, rather than a community-vetted technical > >> >> >> >>> implementation plan?" > >> >> >> >>> >>> > >> >> >> >>> >>> Thank you. > >> >> >> >>> >>> --- > >> >> >> >>> >>> Kone > >> >> >> >>> >>> > >> >> >> >>> >>> > >> >> >> >>> >>> > >> >> >> >>> >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal < > hytham at tra.gov.eg > hytham at tra.gov.eg> >> > >> >> >> >>> hytham at tra.gov.eg > hytham at tra.gov.eg>>>>> a ?crit : > >> >> >> >>> >>>> Dear PDWG, > >> >> >> >>> >>>> > >> >> >> >>> >>>> > >> >> >> >>> >>>> The Policy Development Working Group (PDWG) Chairs have > initiated a > >> >> >> >>> Last Call for this proposal, following rough consensus at the > AFRINIC-37 > >> >> >> >>> Public Policy Meeting held in hybrid format in Nairobi, Kenya > on 24 June > >> >> >> >>> 2026. > >> >> >> >>> >>>> > >> >> >> >>> >>>> * Proposal Name: Hierarchical Names for New AS-SETs > >> >> >> >>> >>>> > >> >> >> >>> >>>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > >> >> >> >>> >>>> > >> >> >> >>> >>>> * Proposal URL: > >> >> >> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >> >> >> >>> >>>> > >> >> >> >>> >>>> Last Call closes on: July 31, 2026, at 23:59 UTC. > >> >> >> >>> >>>> > >> >> >> >>> >>>> > >> >> >> >>> >>>> 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. > >> >> >> >>> >>>> > >> >> >> >>> >>>> > >> >> >> >>> >>>> As always, we kindly request that all participants > adhere to the > >> >> >> >>> AFRINIC Code of Conduct to > maintain a > >> >> >> >>> respectful and professional environment on the mailing list. > >> >> >> >>> >>>> > >> >> >> >>> >>>> > >> >> >> >>> >>>> Kind regards, > >> >> >> >>> >>>> > >> >> >> >>> >>>> > >> >> >> >>> >>>> Haitham el Nakhal > >> >> >> >>> >>>> > >> >> >> >>> >>>> AFRINIC PDWG Co-Chair > >> >> >> >>> >>>> > >> >> >> >>> >>>> > >> >> >> >>> >>>> > >> >> >> >>> >>>> _______________________________________________ > >> >> >> >>> >>>> RPD mailing list > >> >> >> >>> >>>> RPD at afrinic.net RPD at afrinic.net > RPD at afrinic.net> >> > > > >>> > >> >> >> >>> >>>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >> >>> >>> _______________________________________________ > >> >> >> >>> >>> RPD mailing list > >> >> >> >>> >>> RPD at afrinic.net RPD at afrinic.net > RPD at afrinic.net> >> > > > >>> > >> >> >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >> >>> > _______________________________________________ > >> >> >> >>> > RPD mailing list > >> >> >> >>> > RPD at afrinic.net RPD at afrinic.net > RPD at afrinic.net> >> > >> >> >> >>> > https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> ********************************************** > >> >> >> >>> IPv4 is over > >> >> >> >>> Are you ready for the new Internet ? > >> >> >> >>> http://www.theipv6company.com > > >> >> >> >>> The IPv6 Company > >> >> >> >>> > >> >> >> >>> This electronic message contains information which may be > privileged or > >> >> >> >>> confidential. The information is intended to be for the > exclusive use of > >> >> >> >>> the individual(s) named above and further non-explicilty > authorized > >> >> >> >>> disclosure, copying, distribution or use of the contents of > this > >> >> >> >>> information, even if partially, including attached files, is > strictly > >> >> >> >>> prohibited and will be considered a criminal offense. If you > are not the > >> >> >> >>> intended recipient be aware that any disclosure, copying, > distribution or > >> >> >> >>> use of the contents of this information, even if partially, > including > >> >> >> >>> attached files, is strictly prohibited, will be considered a > criminal > >> >> >> >>> offense, so you must reply to the original sender to inform > about this > >> >> >> >>> communication and delete it. > >> >> >> >>> > >> >> >> >>> -------------- next part -------------- > >> >> >> >>> An HTML attachment was scrubbed... > >> >> >> >>> URL: < > >> >> >> >>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/b6777fa7/attachment.html > >> >> >> >>> > > >> >> >> >>> > >> >> >> >>> ------------------------------ > >> >> >> >>> > >> >> >> >>> Subject: Digest Footer > >> >> >> >>> > >> >> >> >>> _______________________________________________ > >> >> >> >>> RPD mailing list > >> >> >> >>> RPD at afrinic.net RPD at afrinic.net > RPD at afrinic.net> >> > >> >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> ------------------------------ > >> >> >> >>> > >> >> >> >>> End of RPD Digest, Vol 222, Issue 110 > >> >> >> >>> ************************************* > >> >> >> >>> > >> >> >> >>> -------------- next part -------------- > >> >> >> >>> An HTML attachment was scrubbed... > >> >> >> >>> URL: < > >> >> >> >>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e492c668/attachment.html > >> >> >> >>> > > >> >> >> >>> > >> >> >> >>> ------------------------------ > >> >> >> >>> > >> >> >> >>> Subject: Digest Footer > >> >> >> >>> > >> >> >> >>> _______________________________________________ > >> >> >> >>> RPD mailing list > >> >> >> >>> RPD at afrinic.net RPD at afrinic.net > RPD at afrinic.net> >> > >> >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> ------------------------------ > >> >> >> >>> > >> >> >> >>> End of RPD Digest, Vol 222, Issue 111 > >> >> >> >>> ************************************* > >> >> >> >>> > >> >> >> >> _______________________________________________ > >> >> >> >> RPD mailing list > >> >> >> >> RPD at afrinic.net RPD at afrinic.net > RPD at afrinic.net> >> > >> >> >> >> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >> >> > >> >> >> > > >> >> >> -------------- next part -------------- > >> >> >> An HTML attachment was scrubbed... > >> >> >> URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/9c41424a/attachment.html > > > >> >> >> > >> >> >> ------------------------------ > >> >> >> > >> >> >> Subject: Digest Footer > >> >> >> > >> >> >> _______________________________________________ > >> >> >> RPD mailing list > >> >> >> RPD at afrinic.net > > >> > >> >> >> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >> > >> >> >> > >> >> >> ------------------------------ > >> >> >> > >> >> >> End of RPD Digest, Vol 222, Issue 119 > >> >> >> ************************************* > >> >> > _______________________________________________ > >> >> > RPD mailing list > >> >> > RPD at afrinic.net > > >> >> > https://lists.afrinic.net/mailman/listinfo/rpd > >> >> > >> >> > >> >> > >> >> ********************************************** > >> >> IPv4 is over > >> >> Are you ready for the new Internet ? > >> >> http://www.theipv6company.com < > http://www.theipv6company.com/> > >> >> The IPv6 Company > >> >> > >> >> This electronic message contains information which may be privileged > or confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > >> >> > >> >> -------------- next part -------------- > >> >> An HTML attachment was scrubbed... > >> >> URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/0ba797a1/attachment.html > > > >> >> > >> >> ------------------------------ > >> >> > >> >> Subject: Digest Footer > >> >> > >> >> _______________________________________________ > >> >> RPD mailing list > >> >> RPD at afrinic.net > > >> >> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> > >> >> > >> >> ------------------------------ > >> >> > >> >> End of RPD Digest, Vol 222, Issue 122 > >> >> ************************************* > >> > _______________________________________________ > >> > RPD mailing list > >> > RPD at afrinic.net > >> > https://lists.afrinic.net/mailman/listinfo/rpd > >> > >> > >> > >> ********************************************** > >> IPv4 is over > >> Are you ready for the new Internet ? > >> http://www.theipv6company.com > >> The IPv6 Company > >> > >> This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > >> > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/d5daa838/attachment.html > > > >> > >> ------------------------------ > >> > >> Subject: Digest Footer > >> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> > >> > >> ------------------------------ > >> > >> End of RPD Digest, Vol 222, Issue 124 > >> ************************************* > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/4db04697/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 129 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at posix.co.za Tue Jul 21 12:57:26 2026 From: mark at posix.co.za (Mark Elkins) Date: Tue, 21 Jul 2026 14:57:26 +0200 Subject: [rpd] Writing tools In-Reply-To: References: <062601dd184f$72379070$56a6b150$@iptrading.com> <066b01dd185a$e13e9080$a3bbb180$@iptrading.com> <1809710664.2684.1784623547091.JavaMail.zimbra@marwan.ma> Message-ID: <714681da-4556-4366-9629-0e07de63871e@posix.co.za> +1 They all joined the mailing list around the same time +/- a week. They all seem to have the same agenda Hmm... On 2026/07/21 14:28, Andrew Alston wrote: > Personally it is not the use of AI that I find objectionable - it is > clear coordination to attempt to derail consensus using an objection > which is not based on fact or evidence. > > Necessity is not a requirement for policy - never has been - and > objections should raise issues that show the policy would do harm or > is out of scope, they should be evidence based, and not purely subjective. > > At this point what I am seeing is a bunch of coordinated posts > generated by AI and sent by random individuals who when looking at > LinkedIn profiles seem to have no relation to the industry. > > While anyone is free to participate in the PDP and I strongly support > that, such participation needs to be done in good faith, and I am > starting to seriously doubt that element exists here > > Andrew > > On Tue, Jul 21, 2026 at 14:08, Gugu Dhlamini > wrote: > > Hi Sami, > > The concern is not reasonable moderation. It is that AI use is > being raised mainly against participants who oppose these > policies, as though the tool makes their objections illegitimate. > > If anyone floods the list, moderate the flooding. Apply that rule > equally, regardless of viewpoint or drafting method. A real > participant using AI to translate, edit, or organise their own > position is not grounds for exclusion. > > An open PDP cannot embrace technology for registry operations > while condemning it when unfamiliar participants use it to speak. > That would be gatekeeping, not consensus. > > Regards, > Gugu > > > > On Tue, 21 Jul 2026, 10:48 am Sami Ait Ali Oulahcen via RPD > wrote: > > Hi all, > > It's been really difficult to follow the list this past 2/3 > days. And I imagine I'm not alone. > I fully agree on moderating the AI madness. Otherwise, it'll > dissuade many folks from following/participating. > > Regards, > Sami > > ----- Original Message ----- > From: "Mike Silber" > To: "rpd >> AfriNIC Resource Policy" > Sent: Monday, July 20, 2026 4:40:55 PM > Subject: Re: [rpd] Writing tools > > A useful discussion - thank you > > On Mon, Jul 20, 2026 at 5:17?PM Mike Burns via RPD > wrote: > > > Hi Rob, > > > > Yes, the language is a clear tell of AI? usage, but flowery > language alone > > is not swamping the list. > > I don't want to hijack the AS-SET discussion, so thank you for > the new > > subject line. > > > > Agreed > > > > > Now, sometimes? and unfortunately, I can use vague and > flowery language > > myself, so I would advise you to treat the AI stuff like the > human stuff. > > Ignore it if it's too vague or flowery to serve as a good > argument, and > > you have clearly laid out the two arguments in your last two > lines. > > Hopefully the list will show judgement and treat clear and > concise > > arguments better than vague ones. > > And then the AI posts, if they want to be successful, will > avoid the > > purple prose. > > > > I think it goes beyond flowery language. > > I am concerned that this is a precedent for AI generated DDoS > attacks on > the PDP and I do think we should have some light touch > guidelines. I > suspect that one of the reasons for the AI-slop flood is not > just to try > convince anyone of the value or legitimacy of their views but > rather to > overwhelm and frustrate other participants and cause them to > withdraw from > participation. > > Accordingly, I suggest we don't simply leave this to the > co-chairs to > determine on a case by case basis, but rather set some > guidelines under > which measures can be taken to avoid AI DDoS. > > Anyway - just my ZAR0,02 which is not worth much > > Regards > > Mike S > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -- Mark James ELKINS? -? Posix Systems - (South) Africa mje at posix.co.za?????? Tel: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za Posix SystemsVCARD for MJ Elkins -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: abessive_logo.jpg Type: image/jpeg Size: 6410 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: QR-MJElkins.png Type: image/png Size: 2163 bytes Desc: not available URL: From hytham at tra.gov.eg Tue Jul 21 13:03:51 2026 From: hytham at tra.gov.eg (Hytham El-Nakhal) Date: Tue, 21 Jul 2026 13:03:51 +0000 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavior on AFPUB-2026-ASN-001-DRAFT02 Message-ID: <1784639031075.56443@tra.gov.eg> Dear PDWG, I have taken note of the various posts on the RPD ML regarding the proposal ?Hierarchical Names for New AS-SETs? that has entered into Last Call after it reached rough consensus during the AFRINIC-37 PPM held on 24 June 2026. The mailing list has recently been flooded with multiple emails stating either the same duplicate objections or consistent pushbacks to every post, some of them with subject line containing ?Digest?. The specific purpose of the Last Call phase is to allow the Community to review the final draft of the proposal and to voice any new valid objections that may have been missed during the discussion phase and would have unintended consequences. In case of the latter, the objection needs to be fully justified, rather than simply repeating past points that have already been addressed. This behavior during the Last Call period is placing an unnecessary and additional burden on the subscribers, PDWG chairs, and staff as each post has to be read and contents assessed. We wish to explicitly remind the PDWG that the number of opposers does not count towards consensus determination, and repeating identical objections does not influence the outcome. I recommend that every contributor use this guide below before commenting on the proposals that are at discussion stage or have reached Last Call : - 1. Familiarise yourself with the consensus-driven AFRINIC PDP and the proposal [See Section below] 2. Read the proposal and consult the archives of discussions as well as previous Public Policy Meeting proceedings 3. Read and adhere to the AFRINIC Code of Conduct - https://www.afrinic.net/code.html . Participants are expected to work collaboratively to build consensus with other participants and to find solutions to problems in the case of policy development. 4. Familiarise yourself with the contributions that have happened during the stage (Under discussion or Last Call) . Share your view or objection if they are new ; i.e has not been addressed by others. More specifically in the Last Call, all those opposed are encouraged to focus on explaining concisely how the proposal acts as a blocker now. They should provide reasons as to why this feedback could not be provided when the proposal was first submitted to the RPD mailing list, rather than repeating generic objections. 5. When contributing, please ensure that the Policy name and ID is included in the subject line [responding to digests further complicates the assessment per proposal]. If you are providing the perspective of your employer that is a Resource Member or as an individual contributor, please say so and provide details. 6. In the event, that you have a new policy related topic or idea to discuss, please change the subject line accordingly. In the event that disruptive multiple posts and duplicate submissions persist, adequate administrative measures will be considered to ensure the efficiency of the process. As we proceed towards the end of Last call for each proposal, a summary of the contributions is prepared and shared with the PDWG on this mailing list. I expect the collaboration of everyone. To educate the PDWG new members and the community at large on the policy development framework, it is vital to understand the formal policy development process. The AFRINIC PDP is strictly governed by Section 3 of the Policy Manual, which can be consulted here : https://www.afrinic.net/consolidated-policy-manual.html. An explanatory webinar was also conducted recently to onboard participants in policy development and can be accessed here : https://www.youtube.com/watch?v=MoB1ZjXgN44. For historical context, all prior discussions on the proposals that have reached Last Call can be consulted in the RPD archives : https://lists.afrinic.net/pipermail/rpd/. The proposals were further discussed during the AF-37 PPM in hybrid mode, allowing registered online and onsite participants to contribute. The AF-37 PPM minutes can be accessed here : https://docs.google.com/document/d/1RS9bYBb9-8uQxLb4u8LpvEUw1jZSfei5mLj01l2LS1s/edit?usp=sharing Kind Regards, Haitham el Nakhal PDWG Co-Chair From TshepoMasuku26 at hotmail.com Tue Jul 21 13:04:23 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Tue, 21 Jul 2026 13:04:23 +0000 Subject: [rpd] RPD Digest, Vol 222, Issue 129 In-Reply-To: References: Message-ID: Dear Jordi, Your argument appears to be: because the community can use policy, the choice to use policy cannot be challenged. That does not follow. The PDP is an available instrument, not the correct instrument for every operational setting. Otherwise, any registry implementation detail could be converted into binding policy simply because enough participants prefer it. That would leave no meaningful boundary between technical administration and governance. The difference is not merely that one mechanism is ?binding? and another is not. An operational procedure can be tested, measured, corrected, and replaced within the service function. Policy turns the same setting into a standing compliance rule and instructs AFRINIC to enforce it. That creates a different institutional consequence. Your hypothetical actually strengthens the objection. If AFRINIC implements the change operationally and it works, proponents of a later policy should still explain what additional technical problem the policy solves. Community preference alone is not a technical requirement. Nor should the test be limited to whether the policy harms AFRINIC. The relevant question is whether the added policy layer is necessary and proportionate for operators. AFRINIC exists to serve the registry function; operators do not exist to enlarge AFRINIC?s policy machinery. Finally, saying that ?the community is on top? does not create an unlimited mandate. Participants may advise, support, and object. They do not automatically become the authorised principals of every network affected by the result. I therefore support Kone?s question and remain opposed to the policy route. Regards, Tshepo ________________________________ From: rpd-request at afrinic.net Sent: Tuesday, 21 July 2026 14:06:24 To: rpd at afrinic.net Subject: RPD Digest, Vol 222, Issue 129 Send RPD mailing list submissions to rpd at afrinic.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.afrinic.net/mailman/listinfo/rpd or, via email, send a message with subject or body 'help' to rpd-request at afrinic.net You can reach the person managing the list at rpd-owner at afrinic.net When replying, please edit your Subject line so it is more specific than "Re: Contents of RPD digest..." Today's Topics: 1. Re: RPD Digest, Vol 222, Issue 124 (jordi.palet at consulintel.es) ---------------------------------------------------------------------- Message: 1 Date: Tue, 21 Jul 2026 13:58:02 +0200 From: "jordi.palet at consulintel.es" To: rpd at afrinic.net Subject: Re: [rpd] RPD Digest, Vol 222, Issue 124 Message-ID: Content-Type: text/plain; charset="utf-8" Hi Nia, In other occasions, staff has said ?policy not needed, it is a very operational matter?. So that sets a precedent, even if not a mandatory one, because even in that case, the community can decide to take the policy approach. That completely nullify the objection to follow the policy approach. Let?s suppose the Last Call fails based on that. The staff implements it just operationally, and then the community still prefers to have it as a policy. Will then your argument become valid and a policy should not reach consensus? Clearly not. As I said many times, the community is "on top? (bottom up process) of the staff and the community can decide that even if a policy is doing exactly the same as the staff operational decision, the community still have the right to reach consensus on setting any operational aspect by means of a policy, unless the policy creates a damage for the AFRINIC organization (in which case, will be NOT ratified by the board). You keep understanding that policy is binding and operational staff procedures not. This is fundamentally broken, so it doesn?t make a difference. Saludos, Jordi @jordipalet > El 21 jul 2026, a las 13:18, Nia Petronella escribi?: > > Dear Jordi, > > You are answering whether policy is procedurally permitted. That is not the question being raised. > > The fact that the bylaws and PDP allow a policy does not prove that policy is necessary, proportionate, or the best instrument. Likewise, the absence of a staff statement saying ?policy is not needed? is not evidence that it is needed. Silence cannot manufacture necessity. > > Kone?s examples remain relevant because they show that the same technical outcome can be achieved operationally. The unanswered question is what binding policy adds beyond rigidity and registry enforcement. > > A procedural route does not justify itself merely because it is familiar. That is how process becomes mandate: the PDP permits policy, therefore policy is treated as necessary, and the resulting enforcement is then called community authority. > > Last Call exists precisely to test unresolved concerns, including the choice of instrument. Consensus is not protected by declaring that it was already reached before those concerns were answered. > > I therefore support Kone?s questions and remain opposed to the policy route. > > Regards, > Nonhlanhla > > > > > On Tue, 21 Jul 2026, 1:05 pm > wrote: >> Send RPD mailing list submissions to >> rpd at afrinic.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.afrinic.net/mailman/listinfo/rpd >> or, via email, send a message with subject or body 'help' to >> rpd-request at afrinic.net >> >> You can reach the person managing the list at >> rpd-owner at afrinic.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of RPD digest..." >> >> >> Today's Topics: >> >> 1. Re: RPD Digest, Vol 222, Issue 122 (jordi.palet at consulintel.es ) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 21 Jul 2026 13:03:53 +0200 >> From: "jordi.palet at consulintel.es " > >> To: rpd at afrinic.net >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 122 >> Message-ID: <3071913E-7C72-49BC-BEDD-B7F26DE20A96 at consulintel.es > >> Content-Type: text/plain; charset="utf-8" >> >> Well ? that?s incorrect. Nobody in the community, neither the staff impact assessment, said that a policy is not needed and many folks already contested several times, that doing it by means of a policy is valid according to the bylaws and PDP and it has not been demonstrated by objections that following this path, with is the most regular one in AFRINIC, creates any harm or problem. >> >> So repeating the argument, by many folks, many times, doesn?t demonstrate ?per se" that it is a valid objection to revert the already reached consensus. Of course, this is a decision that need to be taken by PDP chairs, but this is my view point from an exclusive ?procedural? basis. >> >> Regards, >> Jordi >> >> @jordipalet >> >> > El 21 jul 2026, a las 12:46, Fundiswa Nadia Maseko > escribi?: >> > >> > Dear Jordi, >> > >> > Thank you for your clarification. >> > >> > I understand your point that the proposal has already reached consensus and that Last Call is intended to identify any weaknesses that may have been overlooked. >> > >> > My concern is precisely that if the choice of mechanism was not sufficiently examined during the earlier discussions, then it remains a valid point to raise during Last Call. If a proposal introduces policy where an operational approach could achieve the same objective, that affects whether policy is the appropriate solution in the first place. >> > >> > I appreciate that consensus was declared, but consensus does not prevent the community from identifying a concern that may not have received enough attention. Last Call exists to give the community one final opportunity to do exactly that. >> > >> > >> > Kind regards, >> > >> > Fundiswa >> > >> > On Tue, 21 Jul 2026, 12:30 , >> wrote: >> >> Send RPD mailing list submissions to >> >> rpd at afrinic.net > >> >> >> >> To subscribe or unsubscribe via the World Wide Web, visit >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> or, via email, send a message with subject or body 'help' to >> >> rpd-request at afrinic.net > >> >> >> >> You can reach the person managing the list at >> >> rpd-owner at afrinic.net > >> >> >> >> When replying, please edit your Subject line so it is more specific >> >> than "Re: Contents of RPD digest..." >> >> >> >> >> >> Today's Topics: >> >> >> >> 1. Re: RPD Digest, Vol 222, Issue 119 (jordi.palet at consulintel.es >) >> >> >> >> >> >> ---------------------------------------------------------------------- >> >> >> >> Message: 1 >> >> Date: Tue, 21 Jul 2026 12:29:07 +0200 >> >> From: "jordi.palet at consulintel.es >" >> >> >> To: rpd at afrinic.net > >> >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 119 >> >> Message-ID: >> >> >> Content-Type: text/plain; charset="utf-8" >> >> >> >> Hi Fundiswa, >> >> >> >> Is not a matter of what is practical and what not. >> >> >> >> It is a matter that, during the discussion of the policy proposal (which is not the same as the Last Call), the community reached consensus on making it this way. RIRs follow the same procedures for reaching consensus as IETF, this has been said several times. The Last Call is a last opportunity to discover any weak point in a proposal that already reached consensus, and was OVERLOOKED before. Is not about discussing if the proposal should be a proposal or an operational decision. This is no longer the moment to discuss that (it should have done when the proposal was being discussed before reaching consensus), and many folks in this discussing are ignoring that, probably because they are not used to IETF procedures. >> >> >> >> Otherwise, you can remain silent during the proposal discussion, during the presentation in the PPM and object to it after reached consensus, which is an incorrect procedure. >> >> >> >> One more example: we could have asked AFRINIC many years ago to write the Soft Landing as an operational thing, instead we as a community, decided to make it a policy proposal. Same here. However, the community decided to do it as a proposal and it was accepted that way at the right time, not in the Last Call. >> >> >> >> By the way, I love cooking so from time to time follow some documentaries about that. Are you the same person as the famous chef? I think I saw you in a TV program some months ago or I?m confused. >> >> >> >> Regards, >> >> Jordi >> >> >> >> @jordipalet >> >> >> >> > El 21 jul 2026, a las 12:03, Fundiswa Nadia Maseko >> escribi?: >> >> > >> >> > Dear Jordi, >> >> > >> >> > Thank you for your response. >> >> > >> >> > I agree that AFRINIC is not required to follow the same approach as other RIRs. Every region should make decisions that suit its own community. >> >> > >> >> > My point, however, is slightly different. I wasn't suggesting that AFRINIC should copy another RIR simply because they did it that way. >> >> > >> >> > Rather, I'm asking what specific problem is solved by making this a policy instead of implementing it operationally. If both approaches achieve the same technical outcome, then what additional value does the policy itself provide? >> >> > >> >> > I think that's an important distinction. The fact that the community can choose policy doesn't necessarily mean policy is the most appropriate mechanism in every case. >> >> > >> >> > I'd be interested to hear what practical or technical benefit you believe is only possible through policy and not through an operational implementation. >> >> > >> >> > Kind regards, >> >> > >> >> > Fundiswa >> >> > >> >> > >> >> > >> >> > On Tue, 21 Jul 2026, 11:57 , > >>> wrote: >> >> >> Send RPD mailing list submissions to >> >> >> rpd at afrinic.net > >> >> >> >> >> >> >> To subscribe or unsubscribe via the World Wide Web, visit >> >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> or, via email, send a message with subject or body 'help' to >> >> >> rpd-request at afrinic.net > >> >> >> >> >> >> >> You can reach the person managing the list at >> >> >> rpd-owner at afrinic.net > >> >> >> >> >> >> >> When replying, please edit your Subject line so it is more specific >> >> >> than "Re: Contents of RPD digest..." >> >> >> >> >> >> >> >> >> Today's Topics: >> >> >> >> >> >> 1. Re: RPD Digest, Vol 222, Issue 111 (Nia Petronella) >> >> >> >> >> >> >> >> >> ---------------------------------------------------------------------- >> >> >> >> >> >> Message: 1 >> >> >> Date: Tue, 21 Jul 2026 11:56:49 +0200 >> >> >> From: Nia Petronella > >>> >> >> >> To: Andrew Alston > >>> >> >> >> Cc: rpd at afrinic.net > >> >> >> >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 111 >> >> >> Message-ID: >> >> >> > >>> >> >> >> Content-Type: text/plain; charset="utf-8" >> >> >> >> >> >> Dear Andrew, >> >> >> >> >> >> I do not accept the binary you have presented. >> >> >> >> >> >> No one is suggesting that AFRINIC should make operational changes in secret >> >> >> or without community input. An operational change can be published, >> >> >> consulted on, tested, documented, and reviewed. The real question is >> >> >> whether that input must be converted into binding policy enforced by the >> >> >> registry. >> >> >> >> >> >> Calling AFRINIC ?community-driven? does not answer who the community is or >> >> >> what it is authorised to bind. A self-selecting group of mailing-list >> >> >> participants can provide expertise, support, and objection. It does not >> >> >> automatically represent every member, resource holder, network, customer, >> >> >> or other affected party. >> >> >> >> >> >> The institutional reality also remains unchanged: participants discuss the >> >> >> policy, but AFRINIC interprets and enforces it. Community participation >> >> >> therefore does not eliminate registry power. It can become the language >> >> >> used to legitimise that power. >> >> >> >> >> >> This is why Kone?s examples matter. If LACNIC, RIPE NCC, and ARIN can >> >> >> achieve the same technical outcome through operational mechanisms, then >> >> >> policy is not technically inevitable. Proponents should explain what >> >> >> additional technical result binding policy provides, beyond converting an >> >> >> IRR setting into an enforceable obligation. >> >> >> >> >> >> I also disagree that an objection is valid only if it proves immediate >> >> >> operational harm or implementation failure. The choice of instrument, >> >> >> proportionality, reversibility, and expansion of enforcement authority are >> >> >> legitimate policy concerns. Last Call is not limited to asking whether >> >> >> software will break. It must also ask whether the proposed power is greater >> >> >> than the problem requires. >> >> >> >> >> >> Rough consensus does not require every objection to be accommodated. But an >> >> >> objection is not ?addressed? merely because supporters repeat that the >> >> >> community prefers policy. That is the very assumption being challenged. >> >> >> Procedure cannot be used to prove its own mandate. >> >> >> >> >> >> The fact that the RIR system has operated this way for decades demonstrates >> >> >> continuity of practice. It does not establish unlimited legitimacy of scope. >> >> >> >> >> >> I support Kone?s questions and remain opposed to AFPUB-2026-ASN-001-DRAFT02. >> >> >> >> >> >> Regards, >> >> >> Nonhlanhla >> >> >> >> >> >> >> >> >> >> >> >> On Tue, 21 Jul 2026, 10:26 am Andrew Alston > >>> wrote: >> >> >> >> >> >> > The answer to this is simple. AfriNiC is a community driven organisation >> >> >> > - and anything done with regard to address allocation and management is >> >> >> > done as per policy provided by the community. It is through policy that >> >> >> > the community tells AfriNIC how to do things in regards to the allocation >> >> >> > and handling of resources. >> >> >> > >> >> >> > Without policy, the discretion and rules are entirely in the hands of the >> >> >> > registry, and the community voice is removed. >> >> >> > >> >> >> > This has been the way the RIR system has operated for decades and it >> >> >> > works. The community exercises its voice and its right as to how things >> >> >> > are done in relation to resource management through policy. >> >> >> > >> >> >> > Arguing that just because something can be done another way, is not in my >> >> >> > view a valid argument against policy. Objections to policy need to be >> >> >> > technically grounded and demonstrate that the policy would either cause >> >> >> > harm or alternatively be impractical to implement. Anything else is simply >> >> >> > arguing that policy should not exist because someone doesn?t like AfriNIC >> >> >> > being told how the community wants things done - and that isn?t an argument >> >> >> > that I believe rises to the level of a block on consensus. >> >> >> > >> >> >> > Please note - consensus does not require that the issue you raise have >> >> >> > been fixed, it requires that they have been addressed, and should the >> >> >> > community feel that despite the objections, the policy is something that >> >> >> > should proceed based on the fact that the questions have been addressed if >> >> >> > not necessarily accommodated, rough consensus still exists. >> >> >> > >> >> >> > Again, I support the policy and I see no technical or evidence/fact-based >> >> >> > arguments against said policy. >> >> >> > >> >> >> > Andrew >> >> >> > >> >> >> > On Tue, Jul 21, 2026 at 09:34, Nia Petronella < >> >> >> > nonhlanhlapetronella85 at gmail.com > >>> wrote: >> >> >> > >> >> >> >> Dear PDWG, >> >> >> >> >> >> >> >> Kone is asking the right question. >> >> >> >> >> >> >> >> The issue is no longer whether hierarchical AS-SET naming is technically >> >> >> >> possible or useful. It already exists. The issue is why AFRINIC needs a >> >> >> >> binding policy to enforce what other RIRs largely treat as an operational >> >> >> >> IRR matter. >> >> >> >> >> >> >> >> That distinction matters. An operational change adjusts how a service is >> >> >> >> implemented. A policy creates an enforceable obligation and enlarges the >> >> >> >> registry?s authority. If the same technical result can be achieved through >> >> >> >> a community-reviewed implementation plan, then policy is not the minimum >> >> >> >> necessary instrument. >> >> >> >> >> >> >> >> Saying that ?the community prefers policy? is not enough. Participation >> >> >> >> may guide technical work, but it does not turn every preference into a >> >> >> >> mandate. A mailing list is not a legislature, and the availability of the >> >> >> >> PDP should not make policy the default answer to every operational setting. >> >> >> >> >> >> >> >> This is how gatekeeping expands: the registry begins with a useful >> >> >> >> technical function, then policy converts that function into permission and >> >> >> >> enforcement. The recordkeeper gradually becomes the rule-maker. >> >> >> >> >> >> >> >> The proponents should therefore answer Kone directly: what technical >> >> >> >> outcome can mandatory policy achieve here that an operational >> >> >> >> implementation cannot? >> >> >> >> >> >> >> >> Until that is clearly demonstrated, I support Kone?s questions and remain >> >> >> >> opposed to the policy route. >> >> >> >> >> >> >> >> Regards, >> >> >> >> Nonhlanhla >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Tue, 21 Jul 2026, 8:20 am > >>> wrote: >> >> >> >> >> >> >> >>> Send RPD mailing list submissions to >> >> >> >>> rpd at afrinic.net > >> >> >> >> >>> >> >> >> >>> To subscribe or unsubscribe via the World Wide Web, visit >> >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >>> or, via email, send a message with subject or body 'help' to >> >> >> >>> rpd-request at afrinic.net > >> >> >> >> >>> >> >> >> >>> You can reach the person managing the list at >> >> >> >>> rpd-owner at afrinic.net > >> >> >> >> >>> >> >> >> >>> When replying, please edit your Subject line so it is more specific >> >> >> >>> than "Re: Contents of RPD digest..." >> >> >> >>> >> >> >> >>> >> >> >> >>> Today's Topics: >> >> >> >>> >> >> >> >>> 1. Re: RPD Digest, Vol 222, Issue 110 (Tshepo Masuku) >> >> >> >>> >> >> >> >>> >> >> >> >>> ---------------------------------------------------------------------- >> >> >> >>> >> >> >> >>> Message: 1 >> >> >> >>> Date: Tue, 21 Jul 2026 06:19:05 +0000 >> >> >> >>> From: Tshepo Masuku > >>> >> >> >> >>> To: "rpd at afrinic.net > >>" > >>> >> >> >> >>> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 110 >> >> >> >>> Message-ID: >> >> >> >>> < >> >> >> >>> VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > >> >> >> >> >>> > >> >> >> >>> >> >> >> >>> Content-Type: text/plain; charset="windows-1252" >> >> >> >>> >> >> >> >>> Dear All, >> >> >> >>> >> >> >> >>> Kone?s point is directly relevant. If LACNIC, RIPE NCC, and ARIN can >> >> >> >>> implement hierarchical AS-SET naming through operational mechanisms, then >> >> >> >>> proponents must explain why AFRINIC needs a binding policy to achieve the >> >> >> >>> same technical result. >> >> >> >>> >> >> >> >>> Saying that each RIR works differently does not answer that question. >> >> >> >>> Nor does saying that ?the community is on top of the RIR.? A community may >> >> >> >>> advise, object, and coordinate. It does not acquire unlimited authority to >> >> >> >>> convert every operational preference into policy. A mailing list is not a >> >> >> >>> legislature. >> >> >> >>> >> >> >> >>> If AFRINIC can solve this through an operational change, policy adds >> >> >> >>> governance where technical administration would be sufficient. Speed and >> >> >> >>> preference do not create mandate. >> >> >> >>> >> >> >> >>> Kone provided specific examples. Those should be answered with evidence, >> >> >> >>> not by questioning whether he has worked in every RIR for many years. >> >> >> >>> Experience is relevant, but it is not authority and it is not a substitute >> >> >> >>> for argument. >> >> >> >>> >> >> >> >>> The unanswered question remains: what technical necessity requires >> >> >> >>> policy rather than operational implementation? >> >> >> >>> >> >> >> >>> Until that is answered, Kone?s objection stands, and I support it. >> >> >> >>> >> >> >> >>> Regards, >> >> >> >>> Tshepo >> >> >> >>> >> >> >> >>> >> >> >> >>> ________________________________ >> >> >> >>> From: rpd-request at afrinic.net > >> > >>> >> >> >> >>> Sent: Monday, July 20, 2026 11:10:57 pm >> >> >> >>> To: rpd at afrinic.net > >> > >>> >> >> >> >>> Subject: RPD Digest, Vol 222, Issue 110 >> >> >> >>> >> >> >> >>> Send RPD mailing list submissions to >> >> >> >>> rpd at afrinic.net > >> >> >> >> >>> >> >> >> >>> To subscribe or unsubscribe via the World Wide Web, visit >> >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >>> or, via email, send a message with subject or body 'help' to >> >> >> >>> rpd-request at afrinic.net > >> >> >> >> >>> >> >> >> >>> You can reach the person managing the list at >> >> >> >>> rpd-owner at afrinic.net > >> >> >> >> >>> >> >> >> >>> When replying, please edit your Subject line so it is more specific >> >> >> >>> than "Re: Contents of RPD digest..." >> >> >> >>> >> >> >> >>> >> >> >> >>> Today's Topics: >> >> >> >>> >> >> >> >>> 1. Re: Writing tools (Ben Roberts - AfriNIC) >> >> >> >>> 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >> >> >> >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Kone) >> >> >> >>> 3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names >> >> >> >>> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> >> >> >>> (jordi.palet at consulintel.es > >>) >> >> >> >>> >> >> >> >>> >> >> >> >>> ---------------------------------------------------------------------- >> >> >> >>> >> >> >> >>> Message: 1 >> >> >> >>> Date: Mon, 20 Jul 2026 21:26:40 +0200 >> >> >> >>> From: Ben Roberts - AfriNIC > >>> >> >> >> >>> To: Nonjabulo Sphilile > >>> >> >> >> >>> Cc: rpd at afrinic.net > >> >> >> >> >>> Subject: Re: [rpd] Writing tools >> >> >> >>> Message-ID: <09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net > >>> >> >> >> >>> Content-Type: text/plain; charset="us-ascii" >> >> >> >>> >> >> >> >>> An HTML attachment was scrubbed... >> >> >> >>> URL: < >> >> >> >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/33c3ac9e/attachment-0001.html >> >> >> >>> > >> >> >> >>> >> >> >> >>> ------------------------------ >> >> >> >>> >> >> >> >>> Message: 2 >> >> >> >>> Date: Mon, 20 Jul 2026 20:34:20 +0000 >> >> >> >>> From: Kone > >>> >> >> >> >>> To: Seun Ojedeji > >>> >> >> >> >>> Cc: rpd > >>> >> >> >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >> >> >> >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> >> >> >>> Message-ID: >> >> >> >>> > >> >> >>> 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com > >>> >> >> >> >>> Content-Type: text/plain; charset="utf-8" >> >> >> >>> >> >> >> >>> Hello Seun, >> >> >> >>> You may have misread my earlier mail. I clearly stated that LACNIC, RIPE >> >> >> >>> NCC, and ARIN do not require policy to enforce hierarchical AS?SET >> >> >> >>> naming. >> >> >> >>> >> >> >> >>> To help close the ongoing discussions, I believe addressing the >> >> >> >>> questions I >> >> >> >>> raised would bring clarity: >> >> >> >>> * LACNIC enforces hierarchical AS?SET naming operationally, as part of >> >> >> >>> their IRR design from inception. >> >> >> >>> * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) >> >> >> >>> process, not through policy. >> >> >> >>> * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR >> >> >> >>> operational matters, again without policy. >> >> >> >>> >> >> >> >>> >> >> >> >>> These examples show that other RIRs (except APNIC) treat AS?SET naming as >> >> >> >>> an operational IRR matter, not a policy obligation. >> >> >> >>> >> >> >> >>> This is why I asked whether AFRINIC could address this operationally >> >> >> >>> rather >> >> >> >>> than through policy, and why Last Call discussions would benefit from >> >> >> >>> clear >> >> >> >>> answers to these points. >> >> >> >>> >> >> >> >>> Thanks. >> >> >> >>> --- >> >> >> >>> Kone >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji > >>> a >> >> >> >>> ?crit : >> >> >> >>> >> >> >> >>> > Hello Bakenon, >> >> >> >>> > >> >> >> >>> > Do refer to the proposal as it references URL to other RIR's policies >> >> >> >>> for >> >> >> >>> > thiis: >> >> >> >>> > >> >> >> >>> > https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >> >> >>> > >> >> >> >>> > Regards >> >> >> >>> > >> >> >> >>> > ---- >> >> >> >>> > Sent from my mobile >> >> >> >>> > kindly excuse typos >> >> >> >>> > >> >> >> >>> > On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, > >>> >> >> >> >>> > wrote: >> >> >> >>> > >> >> >> >>> >> Dear PDWG, >> >> >> >>> >> >> >> >> >>> >> I have been following the discussions on the hierarchical AS?SET >> >> >> >>> naming >> >> >> >>> >> scheme and would like clarification on a few points: >> >> >> >>> >> >> >> >> >>> >> 1. Could this matter be addressed operationally, as is done in ARIN, >> >> >> >>> >> LACNIC, and RIPE NCC, without requiring policy changes? >> >> >> >>> >> >> >> >> >>> >> 2. If yes, why are we taking the policy route? Is it because AFRINIC >> >> >> >>> >> currently lacks a defined process for handling operational issues that >> >> >> >>> >> affect IRR services? >> >> >> >>> >> >> >> >> >>> >> 3. Given that the hierarchical naming scheme is already supported and >> >> >> >>> >> currently exists within the IRR, this proposal represents an >> >> >> >>> enforcement >> >> >> >>> >> change rather than the introduction of a new technical standard. Why >> >> >> >>> is a >> >> >> >>> >> formal policy required to change an operational enforcement setting, >> >> >> >>> rather >> >> >> >>> >> than a community-vetted technical implementation plan?" >> >> >> >>> >> >> >> >> >>> >> Thank you. >> >> >> >>> >> --- >> >> >> >>> >> Kone >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal > >>> a >> >> >> >>> >> ?crit : >> >> >> >>> >> >> >> >> >>> >>> Dear PDWG, >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> The Policy Development Working Group (PDWG) Chairs have initiated a >> >> >> >>> Last >> >> >> >>> >>> Call for this proposal, following rough consensus at the AFRINIC-37 >> >> >> >>> Public >> >> >> >>> >>> Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June >> >> >> >>> 2026. >> >> >> >>> >>> >> >> >> >>> >>> * Proposal Name: Hierarchical Names for New AS-SETs >> >> >> >>> >>> >> >> >> >>> >>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >> >> >> >>> >>> >> >> >> >>> >>> * Proposal URL: >> >> >> >>> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >> >> >>> >>> >> >> >> >>> >>> Last Call closes on: July 31, 2026, at 23:59 UTC. >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> 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. >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> As always, we kindly request that all participants adhere to the >> >> >> >>> AFRINIC >> >> >> >>> >>> Code of Conduct to maintain a >> >> >> >>> respectful >> >> >> >>> >>> and professional environment on the mailing list. >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> Kind regards, >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> Haitham el Nakhal >> >> >> >>> >>> >> >> >> >>> >>> AFRINIC PDWG Co-Chair >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> _______________________________________________ >> >> >> >>> >>> RPD mailing list >> >> >> >>> >>> RPD at afrinic.net > >> >> >> >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >>> >>> >> >> >> >>> >> _______________________________________________ >> >> >> >>> >> RPD mailing list >> >> >> >>> >> RPD at afrinic.net > >> >> >> >> >>> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >>> >> >> >> >> >>> > >> >> >> >>> -------------- next part -------------- >> >> >> >>> An HTML attachment was scrubbed... >> >> >> >>> URL: < >> >> >> >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/4563e1d5/attachment-0001.html >> >> >> >>> > >> >> >> >>> >> >> >> >>> ------------------------------ >> >> >> >>> >> >> >> >>> Message: 3 >> >> >> >>> Date: Mon, 20 Jul 2026 23:10:04 +0200 >> >> >> >>> From: "jordi.palet at consulintel.es > >>" > >>> >> >> >> >>> To: rpd > >>> >> >> >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >> >> >> >>> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> >> >> >>> Message-ID: > >>> >> >> >> >>> Content-Type: text/plain; charset="utf-8" >> >> >> >>> >> >> >> >>> Hi Kone, >> >> >> >>> >> >> >> >>> And what is the relevance of that? >> >> >> >>> >> >> >> >>> If you have a good understanding about all the RIRs, you will know that >> >> >> >>> each RIR has their own ways to do things. In many senses they act very >> >> >> >>> similarly and in general we end up with very similarly policies, but not >> >> >> >>> always. Some RIRs have decided that some aspects are operational and don?t >> >> >> >>> need a policy proposal. >> >> >> >>> >> >> >> >>> However, despite that, the community is on top of the RIR, and the >> >> >> >>> community sometimes, may decide that they prefer a policy if the RIR hasn?t >> >> >> >>> been proactive in advance in any specific topic, or even if the RIR was >> >> >> >>> proactive, the community may prefer to speed up things, or to show the way >> >> >> >>> the community prefers. >> >> >> >>> >> >> >> >>> For example, if AFRINIC has any specific operational aspect already in >> >> >> >>> place, and the community prefer to manage that in a different way, the >> >> >> >>> community may opt either for suggesting the RIR to modify that operational >> >> >> >>> aspect or to do actually enforce it by means of a policy proposal. >> >> >> >>> >> >> >> >>> I think is important to know, by personal experience, how the other 4 >> >> >> >>> RIRs work before stating something that is not correct, because if you >> >> >> >>> don?t work in all the RIRs for many years, it will be difficult for you to >> >> >> >>> know the past and I?m sure IA will not be able to be precise as well. >> >> >> >>> >> >> >> >>> Regards, >> >> >> >>> Jordi >> >> >> >>> >> >> >> >>> @jordipalet >> >> >> >>> >> >> >> >>> > El 20 jul 2026, a las 22:34, Kone > >>> escribi?: >> >> >> >>> > >> >> >> >>> > Hello Seun, >> >> >> >>> > You may have misread my earlier mail. I clearly stated that LACNIC, >> >> >> >>> RIPE NCC, and ARIN do not require policy to enforce hierarchical AS?SET >> >> >> >>> naming. >> >> >> >>> > >> >> >> >>> > To help close the ongoing discussions, I believe addressing the >> >> >> >>> questions I raised would bring clarity: >> >> >> >>> > * LACNIC enforces hierarchical AS?SET naming operationally, as part of >> >> >> >>> their IRR design from inception. >> >> >> >>> > * RIPE NCC handles IRR changes through their Numbered Work Items (NWI) >> >> >> >>> process, not through policy. >> >> >> >>> > * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR >> >> >> >>> operational matters, again without policy. >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > These examples show that other RIRs (except APNIC) treat AS?SET naming >> >> >> >>> as an operational IRR matter, not a policy obligation. >> >> >> >>> > >> >> >> >>> > This is why I asked whether AFRINIC could address this operationally >> >> >> >>> rather than through policy, and why Last Call discussions would benefit >> >> >> >>> from clear answers to these points. >> >> >> >>> > >> >> >> >>> > Thanks. >> >> >> >>> > --- >> >> >> >>> > Kone >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > >> >> >> >>> > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji > >> >> >> >> >>> > >>>> a ?crit : >> >> >> >>> >> Hello Bakenon, >> >> >> >>> >> >> >> >> >>> >> Do refer to the proposal as it references URL to other RIR's policies >> >> >> >>> for thiis: >> >> >> >>> >> >> >> >> >>> >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >> >> >>> >> >> >> >> >>> >> Regards >> >> >> >>> >> >> >> >> >>> >> ---- >> >> >> >>> >> Sent from my mobile >> >> >> >>> >> kindly excuse typos >> >> >> >>> >> >> >> >> >>> >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, > >> >> >> >> >>> > >>>> wrote: >> >> >> >>> >>> Dear PDWG, >> >> >> >>> >>> >> >> >> >>> >>> I have been following the discussions on the hierarchical AS?SET >> >> >> >>> naming scheme and would like clarification on a few points: >> >> >> >>> >>> >> >> >> >>> >>> 1. Could this matter be addressed operationally, as is done in ARIN, >> >> >> >>> LACNIC, and RIPE NCC, without requiring policy changes? >> >> >> >>> >>> >> >> >> >>> >>> 2. If yes, why are we taking the policy route? Is it because AFRINIC >> >> >> >>> currently lacks a defined process for handling operational issues that >> >> >> >>> affect IRR services? >> >> >> >>> >>> >> >> >> >>> >>> 3. Given that the hierarchical naming scheme is already supported >> >> >> >>> and currently exists within the IRR, this proposal represents an >> >> >> >>> enforcement change rather than the introduction of a new technical >> >> >> >>> standard. Why is a formal policy required to change an operational >> >> >> >>> enforcement setting, rather than a community-vetted technical >> >> >> >>> implementation plan?" >> >> >> >>> >>> >> >> >> >>> >>> Thank you. >> >> >> >>> >>> --- >> >> >> >>> >>> Kone >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal > >> >> >> >> >>> > >>>> a ?crit : >> >> >> >>> >>>> Dear PDWG, >> >> >> >>> >>>> >> >> >> >>> >>>> >> >> >> >>> >>>> The Policy Development Working Group (PDWG) Chairs have initiated a >> >> >> >>> Last Call for this proposal, following rough consensus at the AFRINIC-37 >> >> >> >>> Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June >> >> >> >>> 2026. >> >> >> >>> >>>> >> >> >> >>> >>>> * Proposal Name: Hierarchical Names for New AS-SETs >> >> >> >>> >>>> >> >> >> >>> >>>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >> >> >> >>> >>>> >> >> >> >>> >>>> * Proposal URL: >> >> >> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >> >> >>> >>>> >> >> >> >>> >>>> Last Call closes on: July 31, 2026, at 23:59 UTC. >> >> >> >>> >>>> >> >> >> >>> >>>> >> >> >> >>> >>>> 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. >> >> >> >>> >>>> >> >> >> >>> >>>> >> >> >> >>> >>>> As always, we kindly request that all participants adhere to the >> >> >> >>> AFRINIC Code of Conduct to maintain a >> >> >> >>> respectful and professional environment on the mailing list. >> >> >> >>> >>>> >> >> >> >>> >>>> >> >> >> >>> >>>> Kind regards, >> >> >> >>> >>>> >> >> >> >>> >>>> >> >> >> >>> >>>> Haitham el Nakhal >> >> >> >>> >>>> >> >> >> >>> >>>> AFRINIC PDWG Co-Chair >> >> >> >>> >>>> >> >> >> >>> >>>> >> >> >> >>> >>>> >> >> >> >>> >>>> _______________________________________________ >> >> >> >>> >>>> RPD mailing list >> >> >> >>> >>>> RPD at afrinic.net > >> > >>> >> >> >> >>> >>>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >>> >>> _______________________________________________ >> >> >> >>> >>> RPD mailing list >> >> >> >>> >>> RPD at afrinic.net > >> > >>> >> >> >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >>> > _______________________________________________ >> >> >> >>> > RPD mailing list >> >> >> >>> > RPD at afrinic.net > >> >> >> >> >>> > https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> ********************************************** >> >> >> >>> IPv4 is over >> >> >> >>> Are you ready for the new Internet ? >> >> >> >>> http://www.theipv6company.com >> >> >> >>> The IPv6 Company >> >> >> >>> >> >> >> >>> This electronic message contains information which may be privileged or >> >> >> >>> confidential. The information is intended to be for the exclusive use of >> >> >> >>> the individual(s) named above and further non-explicilty authorized >> >> >> >>> disclosure, copying, distribution or use of the contents of this >> >> >> >>> information, even if partially, including attached files, is strictly >> >> >> >>> prohibited and will be considered a criminal offense. If you are not the >> >> >> >>> intended recipient be aware that any disclosure, copying, distribution or >> >> >> >>> use of the contents of this information, even if partially, including >> >> >> >>> attached files, is strictly prohibited, will be considered a criminal >> >> >> >>> offense, so you must reply to the original sender to inform about this >> >> >> >>> communication and delete it. >> >> >> >>> >> >> >> >>> -------------- next part -------------- >> >> >> >>> An HTML attachment was scrubbed... >> >> >> >>> URL: < >> >> >> >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260720/b6777fa7/attachment.html >> >> >> >>> > >> >> >> >>> >> >> >> >>> ------------------------------ >> >> >> >>> >> >> >> >>> Subject: Digest Footer >> >> >> >>> >> >> >> >>> _______________________________________________ >> >> >> >>> RPD mailing list >> >> >> >>> RPD at afrinic.net > >> >> >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >>> >> >> >> >>> >> >> >> >>> ------------------------------ >> >> >> >>> >> >> >> >>> End of RPD Digest, Vol 222, Issue 110 >> >> >> >>> ************************************* >> >> >> >>> >> >> >> >>> -------------- next part -------------- >> >> >> >>> An HTML attachment was scrubbed... >> >> >> >>> URL: < >> >> >> >>> https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e492c668/attachment.html >> >> >> >>> > >> >> >> >>> >> >> >> >>> ------------------------------ >> >> >> >>> >> >> >> >>> Subject: Digest Footer >> >> >> >>> >> >> >> >>> _______________________________________________ >> >> >> >>> RPD mailing list >> >> >> >>> RPD at afrinic.net > >> >> >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >>> >> >> >> >>> >> >> >> >>> ------------------------------ >> >> >> >>> >> >> >> >>> End of RPD Digest, Vol 222, Issue 111 >> >> >> >>> ************************************* >> >> >> >>> >> >> >> >> _______________________________________________ >> >> >> >> RPD mailing list >> >> >> >> RPD at afrinic.net > >> >> >> >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> >> >> >> > >> >> >> -------------- next part -------------- >> >> >> An HTML attachment was scrubbed... >> >> >> URL: >> >> >> >> >> >> ------------------------------ >> >> >> >> >> >> Subject: Digest Footer >> >> >> >> >> >> _______________________________________________ >> >> >> RPD mailing list >> >> >> RPD at afrinic.net > >> >> >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> >> >> >> >> >> ------------------------------ >> >> >> >> >> >> End of RPD Digest, Vol 222, Issue 119 >> >> >> ************************************* >> >> > _______________________________________________ >> >> > RPD mailing list >> >> > RPD at afrinic.net > >> >> > https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> >> >> >> >> ********************************************** >> >> IPv4 is over >> >> Are you ready for the new Internet ? >> >> http://www.theipv6company.com >> >> The IPv6 Company >> >> >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> >> >> -------------- next part -------------- >> >> An HTML attachment was scrubbed... >> >> URL: >> >> >> >> ------------------------------ >> >> >> >> Subject: Digest Footer >> >> >> >> _______________________________________________ >> >> RPD mailing list >> >> RPD at afrinic.net > >> >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> >> >> ------------------------------ >> >> >> >> End of RPD Digest, Vol 222, Issue 122 >> >> ************************************* >> > _______________________________________________ >> > RPD mailing list >> > RPD at afrinic.net >> > https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ------------------------------ >> >> End of RPD Digest, Vol 222, Issue 124 >> ************************************* ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ End of RPD Digest, Vol 222, Issue 129 ************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Tue Jul 21 13:12:30 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Tue, 21 Jul 2026 15:12:30 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 133 In-Reply-To: References: Message-ID: Hi Mark, Similar timing and similar views do not establish misconduct. The co-chairs can assess the contributions on their merits. I will not engage further with speculation about participants. Regards, Nonhlanhla On Tue, 21 Jul 2026, 2:58 pm wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: Writing tools (Mark Elkins) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2026 14:57:26 +0200 > From: Mark Elkins > To: rpd at afrinic.net > Subject: Re: [rpd] Writing tools > Message-ID: <714681da-4556-4366-9629-0e07de63871e at posix.co.za> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > +1 > > They all joined the mailing list around the same time +/- a week. > > They all seem to have the same agenda > > Hmm... > > > On 2026/07/21 14:28, Andrew Alston wrote: > > Personally it is not the use of AI that I find objectionable - it is > > clear coordination to attempt to derail consensus using an objection > > which is not based on fact or evidence. > > > > Necessity is not a requirement for policy - never has been - and > > objections should raise issues that show the policy would do harm or > > is out of scope, they should be evidence based, and not purely > subjective. > > > > At this point what I am seeing is a bunch of coordinated posts > > generated by AI and sent by random individuals who when looking at > > LinkedIn profiles seem to have no relation to the industry. > > > > While anyone is free to participate in the PDP and I strongly support > > that, such participation needs to be done in good faith, and I am > > starting to seriously doubt that element exists here > > > > Andrew > > > > On Tue, Jul 21, 2026 at 14:08, Gugu Dhlamini > > wrote: > > > > Hi Sami, > > > > The concern is not reasonable moderation. It is that AI use is > > being raised mainly against participants who oppose these > > policies, as though the tool makes their objections illegitimate. > > > > If anyone floods the list, moderate the flooding. Apply that rule > > equally, regardless of viewpoint or drafting method. A real > > participant using AI to translate, edit, or organise their own > > position is not grounds for exclusion. > > > > An open PDP cannot embrace technology for registry operations > > while condemning it when unfamiliar participants use it to speak. > > That would be gatekeeping, not consensus. > > > > Regards, > > Gugu > > > > > > > > On Tue, 21 Jul 2026, 10:48 am Sami Ait Ali Oulahcen via RPD > > wrote: > > > > Hi all, > > > > It's been really difficult to follow the list this past 2/3 > > days. And I imagine I'm not alone. > > I fully agree on moderating the AI madness. Otherwise, it'll > > dissuade many folks from following/participating. > > > > Regards, > > Sami > > > > ----- Original Message ----- > > From: "Mike Silber" > > To: "rpd >> AfriNIC Resource Policy" > > Sent: Monday, July 20, 2026 4:40:55 PM > > Subject: Re: [rpd] Writing tools > > > > A useful discussion - thank you > > > > On Mon, Jul 20, 2026 at 5:17?PM Mike Burns via RPD > > wrote: > > > > > Hi Rob, > > > > > > Yes, the language is a clear tell of AI? usage, but flowery > > language alone > > > is not swamping the list. > > > > I don't want to hijack the AS-SET discussion, so thank you for > > the new > > > subject line. > > > > > > > Agreed > > > > > > > > Now, sometimes? and unfortunately, I can use vague and > > flowery language > > > myself, so I would advise you to treat the AI stuff like the > > human stuff. > > > Ignore it if it's too vague or flowery to serve as a good > > argument, and > > > you have clearly laid out the two arguments in your last two > > lines. > > > Hopefully the list will show judgement and treat clear and > > concise > > > arguments better than vague ones. > > > And then the AI posts, if they want to be successful, will > > avoid the > > > purple prose. > > > > > > > I think it goes beyond flowery language. > > > > I am concerned that this is a precedent for AI generated DDoS > > attacks on > > the PDP and I do think we should have some light touch > > guidelines. I > > suspect that one of the reasons for the AI-slop flood is not > > just to try > > convince anyone of the value or legitimacy of their views but > > rather to > > overwhelm and frustrate other participants and cause them to > > withdraw from > > participation. > > > > Accordingly, I suggest we don't simply leave this to the > > co-chairs to > > determine on a case by case basis, but rather set some > > guidelines under > > which measures can be taken to avoid AI DDoS. > > > > Anyway - just my ZAR0,02 which is not worth much > > > > Regards > > > > Mike S > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > -- > > Mark James ELKINS? -? Posix Systems - (South) Africa > mje at posix.co.za?????? Tel: +27.826010496 > For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za > > Posix SystemsVCARD for MJ Elkins > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/6f3e4446/attachment.html > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: abessive_logo.jpg > Type: image/jpeg > Size: 6410 bytes > Desc: not available > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/6f3e4446/attachment.jpg > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: QR-MJElkins.png > Type: image/png > Size: 2163 bytes > Desc: not available > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/6f3e4446/attachment.png > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 133 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Tue Jul 21 13:35:32 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Tue, 21 Jul 2026 15:35:32 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 131 In-Reply-To: References: Message-ID: Dear Hendrik, Your message does not identify a policy error or a proven breach of the mailing-list rules. It relies on ridicule, assumptions about identity, and an AI-generated assessment of writing style. None of that proves astroturfing. Experience is valuable, but it does not give established participants authority to decide who may speak or how newer participants must prepare their contributions. New voices are participants, not apprentices waiting for approval from the familiar circle. If you have evidence of impersonation, automated flooding, or another specific violation, submit it to the co-chairs. Otherwise, address the arguments raised. The PDWG is not a private club, and participation cannot be withdrawn by insult or speculation. Regards, Nonhlanhla On Tue, 21 Jul 2026, 2:34 pm wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: Writing tools (hvisage at hevis.co.za) > 2. Re: Writing tools (Andrew Alston) > 3. Re: Writing tools (Ben Roberts - AfriNIC) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2026 14:06:52 +0200 > From: hvisage at hevis.co.za > To: Nonjabulo Sphilile > Cc: rpd at afrinic.net > Subject: Re: [rpd] Writing tools > Message-ID: > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > That human irony went so whoosh over the AI?s heads the guilty > didn?t blinked? > > Dear Humans, > The Astroturfing and other evidence had been proven and you?ve all > already seen and noticed it. > > Dear ChatGPT, > > Do request permissions from your prompter(s) to read the RPD archive > in full and evaluate Claude?s assesment > of the effects of mass student account usages. Also, request them their > reasons why students in English speaking tertiary educational > institutions require AI writing tools? Also tell them, that those > student, being very? new? in the IT arena > to rather ask the questions and the other ? older and more > experienced? in the IT and ISP and Internet Arena would be glad to > assist those humans in guiding and growing, instead of causing some > negativity towards the students? accounts that had been (ab?)used in > this torrential flood of AI regurgitating.. apologies for the > bluntness.. garbage.. sorry AI.. it?s not you, it?s the prompter > that needs to be educated, I?m sorry, they don?t know better as > their master Voldemort is controlling them. I feel for you ChatGPT.. I > do..just think of the tokens you could?ve spend growing your corpus to > be a value to the rest of the world. > > In other more relevant news that you, and I mean you ChatGPT, have > missed, is that.. well.. your prompters seems to ignored the answer > given to them/you in a very? dismissive(?!?!) way ;( Apologies, you > are just doing what you had been prompted to do. > > While we are chatting ChatGPT, do request also the RPD archives so you > can see all the many fold questions your prompters have forgotten to > provide you so that you can please answer those. Do request all the rest > in the group to do the same so that they can see how they aren?t > adding value, but actually are causing the unneeded and unnecessary > loathing against tool use and youngsters like some of the prompter?s > emails you had been using. > > Yours loving LLMs used by responsible prompters. > > Hendrik > > PPS: yes, your prompter and the rest of the prompters/copiers/senders, > had been ?proven? to be ?disruptive conduct?? they just > don?t realised it ;( > > On 21 Jul 2026, at 9:32, Nonjabulo Sphilile wrote: > > > Dear colleagues, > > > > Hendrik, asking an AI system to label participants as astroturfers is > > not > > evidence. It is an automated opinion about writing style. The phrase > > ?humans with brains? also adds nothing to the policy discussion. > > It simply > > turns disagreement into personal contempt. > > > > Mike, your distinction between ordinary AI-assisted writing and > > intentional > > list flooding is reasonable. Actual flooding should be handled under > > existing rules, regardless of the tool used. But a ?+1? should not > > become > > compulsory. Participants may agree on the same issue while reaching it > > from > > different experiences or concerns. The co-chairs can consolidate > > repeated > > arguments without erasing the people raising them. > > > > Ben, the football comparison may be amusing, but the PDP is not a > > match in > > which familiar players, referees, or crowd preference determine > > legitimacy. > > Participation provides evidence and objection. It does not create > > authority > > over other participants. > > > > The correct approach is straightforward: moderate proven disruptive > > conduct, group genuinely repetitive points, and assess each distinct > > policy > > concern on its merits. Do not turn speculation about tools, identity, > > or > > familiarity into a gatekeeping mechanism. > > > > Regards, > > Nonjabulo > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/37ea3c4a/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Tue, 21 Jul 2026 15:28:07 +0300 > From: Andrew Alston > To: Gugu Dhlamini > Cc: "rpd >> AfriNIC Resource Policy" > Subject: Re: [rpd] Writing tools > Message-ID: > < > CAD52VQ2HFjWk8NmFXLTxcmqb0U1uYf7Sw-E_V31gMosR89MXvA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Personally it is not the use of AI that I find objectionable - it is clear > coordination to attempt to derail consensus using an objection which is not > based on fact or evidence. > > Necessity is not a requirement for policy - never has been - and objections > should raise issues that show the policy would do harm or is out of scope, > they should be evidence based, and not purely subjective. > > At this point what I am seeing is a bunch of coordinated posts generated by > AI and sent by random individuals who when looking at LinkedIn profiles > seem to have no relation to the industry. > > While anyone is free to participate in the PDP and I strongly support that, > such participation needs to be done in good faith, and I am starting to > seriously doubt that element exists here > > Andrew > > On Tue, Jul 21, 2026 at 14:08, Gugu Dhlamini > wrote: > > > Hi Sami, > > > > The concern is not reasonable moderation. It is that AI use is being > > raised mainly against participants who oppose these policies, as though > the > > tool makes their objections illegitimate. > > > > If anyone floods the list, moderate the flooding. Apply that rule > equally, > > regardless of viewpoint or drafting method. A real participant using AI > to > > translate, edit, or organise their own position is not grounds for > > exclusion. > > > > An open PDP cannot embrace technology for registry operations while > > condemning it when unfamiliar participants use it to speak. That would be > > gatekeeping, not consensus. > > > > Regards, > > Gugu > > > > > > > > On Tue, 21 Jul 2026, 10:48 am Sami Ait Ali Oulahcen via RPD < > > rpd at afrinic.net> wrote: > > > >> Hi all, > >> > >> It's been really difficult to follow the list this past 2/3 days. And I > >> imagine I'm not alone. > >> I fully agree on moderating the AI madness. Otherwise, it'll dissuade > >> many folks from following/participating. > >> > >> Regards, > >> Sami > >> > >> ----- Original Message ----- > >> From: "Mike Silber" > >> To: "rpd >> AfriNIC Resource Policy" > >> Sent: Monday, July 20, 2026 4:40:55 PM > >> Subject: Re: [rpd] Writing tools > >> > >> A useful discussion - thank you > >> > >> On Mon, Jul 20, 2026 at 5:17?PM Mike Burns via RPD > >> wrote: > >> > >> > Hi Rob, > >> > > >> > Yes, the language is a clear tell of AI usage, but flowery language > >> alone > >> > is not swamping the list. > >> > >> I don't want to hijack the AS-SET discussion, so thank you for the new > >> > subject line. > >> > > >> > >> Agreed > >> > >> > > >> > Now, sometimes and unfortunately, I can use vague and flowery > language > >> > myself, so I would advise you to treat the AI stuff like the human > >> stuff. > >> > Ignore it if it's too vague or flowery to serve as a good argument, > and > >> > you have clearly laid out the two arguments in your last two lines. > >> > Hopefully the list will show judgement and treat clear and concise > >> > arguments better than vague ones. > >> > And then the AI posts, if they want to be successful, will avoid the > >> > purple prose. > >> > > >> > >> I think it goes beyond flowery language. > >> > >> I am concerned that this is a precedent for AI generated DDoS attacks on > >> the PDP and I do think we should have some light touch guidelines. I > >> suspect that one of the reasons for the AI-slop flood is not just to try > >> convince anyone of the value or legitimacy of their views but rather to > >> overwhelm and frustrate other participants and cause them to withdraw > from > >> participation. > >> > >> Accordingly, I suggest we don't simply leave this to the co-chairs to > >> determine on a case by case basis, but rather set some guidelines under > >> which measures can be taken to avoid AI DDoS. > >> > >> Anyway - just my ZAR0,02 which is not worth much > >> > >> Regards > >> > >> Mike S > >> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/4cafd58c/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Tue, 21 Jul 2026 14:33:01 +0200 > From: Ben Roberts - AfriNIC > To: Andrew Alston > Cc: rpd at afrinic.net > Subject: Re: [rpd] Writing tools > Message-ID: <0EF428F5-F489-42CD-A6AD-38C8AE17F3E7 at afrinic.net> > Content-Type: text/plain; charset="us-ascii" > > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e169fd40/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 131 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.medoye at gmail.com Tue Jul 21 13:42:33 2026 From: daniel.medoye at gmail.com (Taye Medoye) Date: Tue, 21 Jul 2026 15:42:33 +0200 Subject: [rpd] Policy supremacy Message-ID: Dear All, Permit me to remark that the first impression one gets perusing the torrent of submissions in the last twenty-four hours, is that the focus of the Community may have shifted from making helpful and concrete inputs towards a proposed policy development, to a supremacy contest, and most likely unhealthy rivalry over language use. If this insinuation is valid, then there's a need to retreat and refocus. While the concerns of Jordi are noted, and worthy of critical consideration, the point has to be made that the discussion process for reaching a consensus on any policy proposal, as enshrined in the standard operating procedure, has to be mutual and convincing to receive acceptance. In another context, the remarks from Ben, sent from his iPhone - objectors who all simultaneously and spontaneously joined from Unkown Gmail accounts bombard the lists with AI slop, are recognised as community members, or even identifiable human beings for that matter - leave much to be desired. I do not think such remarks should be welcome on this platform, given the quality of commenters and participants. Going by the community's Code of Conduct, and particularly on the expected behaviour of participants, which include - treating others with politeness and showing of respect; avoiding personal attacks or otherwise defamatory or discriminatory comments, etc, every commenter/participant is expected to adhere strictly as established to avoid unnecessary rivalry and chaos. By way of suggestion therefore, l am inclined to suggest that the tone of remarks and commentaries be softened, to eschew any form of bitterness, while attention should be on the issues at stake for consideration. I so suggest! Taye Medoye. 1. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonjabulosphilile at gmail.com Tue Jul 21 13:46:14 2026 From: nonjabulosphilile at gmail.com (Nonjabulo Sphilile) Date: Tue, 21 Jul 2026 15:46:14 +0200 Subject: [rpd] Writing tools In-Reply-To: References: Message-ID: Dear Hendrik, This message is personal abuse, not policy analysis. Claude is not an auditor, and its opinion about writing style does not prove astroturfing, identity misuse, or disruptive conduct. If you believe a specific rule has been breached, identify the conduct and place the evidence before the co-chairs. Insults about students, intelligence, ?garbage,? or imaginary controllers prove nothing. New participants are not apprentices who require permission from older participants to speak. Experience may add weight to evidence, but it does not create authority over other people?s participation. A mailing list is not a hierarchy in which familiar operators decide whose voice is legitimate. I am a real participant. I review what I submit, I stand behind it, and I accept responsibility for it. The tools I use to draft or edit my words do not transfer my judgment to the tool. Please address the policy arguments or refer a documented procedural complaint to the co-chairs. I will not participate in further personal speculation presented as technical analysis. Regards, Nonjabulo On Tue, 21 Jul 2026, 14:07 , wrote: > That human irony went so whoosh over the AI?s heads the guilty didn?t > blinked? > > Dear Humans, > The Astroturfing and other evidence had been proven and you?ve all already > seen and noticed it. > > Dear ChatGPT, > > Do request permissions from your prompter(s) to read the RPD archive in > full and evaluate Claude?s assesment > of the effects of mass student account usages. Also, request them their > reasons why students in English speaking tertiary educational institutions > require AI writing tools? Also tell them, that those student, being very? > new? in the IT arena > to rather ask the questions and the other ? older and more experienced? in > the IT and ISP and Internet Arena would be glad to assist those humans in > guiding and growing, instead of causing some negativity towards the > students? accounts that had been (ab?)used in this torrential flood of AI > regurgitating.. apologies for the bluntness.. garbage.. sorry AI.. it?s not > you, it?s the prompter that needs to be educated, I?m sorry, they don?t > know better as their master Voldemort is controlling them. I feel for you > ChatGPT.. I do..just think of the tokens you could?ve spend growing your > corpus to be a value to the rest of the world. > > In other more relevant news that you, and I mean you ChatGPT, have missed, > is that.. well.. your prompters seems to ignored the answer given to > them/you in a very? dismissive(?!?!) way ;( Apologies, you are just doing > what you had been prompted to do. > > While we are chatting ChatGPT, do request also the RPD archives so you can > see all the many fold questions your prompters have forgotten to provide > you so that you can please answer those. Do request all the rest in the > group to do the same so that they can see how they aren?t adding value, but > actually are causing the unneeded and unnecessary loathing against tool use > and youngsters like some of the prompter?s emails you had been using. > > Yours loving LLMs used by responsible prompters. > > Hendrik > > PPS: yes, your prompter and the rest of the prompters/copiers/senders, had > been ?proven? to be ?disruptive conduct?? they just don?t realised it ;( > > On 21 Jul 2026, at 9:32, Nonjabulo Sphilile wrote: > > Dear colleagues, > > Hendrik, asking an AI system to label participants as astroturfers is not > evidence. It is an automated opinion about writing style. The phrase > ?humans with brains? also adds nothing to the policy discussion. It simply > turns disagreement into personal contempt. > > Mike, your distinction between ordinary AI-assisted writing and intentional > list flooding is reasonable. Actual flooding should be handled under > existing rules, regardless of the tool used. But a ?+1? should not become > compulsory. Participants may agree on the same issue while reaching it from > different experiences or concerns. The co-chairs can consolidate repeated > arguments without erasing the people raising them. > > Ben, the football comparison may be amusing, but the PDP is not a match in > which familiar players, referees, or crowd preference determine legitimacy. > Participation provides evidence and objection. It does not create authority > over other participants. > > The correct approach is straightforward: moderate proven disruptive > conduct, group genuinely repetitive points, and assess each distinct policy > concern on its merits. Do not turn speculation about tools, identity, or > familiarity into a gatekeeping mechanism. > > Regards, > Nonjabulo > ------------------------------ > > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mselekuthandeka80 at gmail.com Tue Jul 21 13:47:41 2026 From: mselekuthandeka80 at gmail.com (Thandeka Mseleku) Date: Tue, 21 Jul 2026 15:47:41 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 133 In-Reply-To: References: Message-ID: Dear Mark, Respectfully, joining the mailing list around the same time or reaching similar conclusions does not, by itself, demonstrate a coordinated agenda. It is equally possible for participants to independently arrive at similar positions after reviewing the same proposal. The focus should remain on the substance of the arguments presented. If an objection is factually or technically incorrect, it should be addressed on its merits rather than by drawing conclusions based on when someone joined the mailing list or assumptions about their motivations. An open Policy Development Process should encourage participation from both long-standing and new contributors, with every contribution evaluated fairly and objectively. BR, Thandeka Mseleku On Tue, 21 Jul 2026, 14:58 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: Writing tools (Mark Elkins) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2026 14:57:26 +0200 > From: Mark Elkins > To: rpd at afrinic.net > Subject: Re: [rpd] Writing tools > Message-ID: <714681da-4556-4366-9629-0e07de63871e at posix.co.za> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > +1 > > They all joined the mailing list around the same time +/- a week. > > They all seem to have the same agenda > > Hmm... > > > On 2026/07/21 14:28, Andrew Alston wrote: > > Personally it is not the use of AI that I find objectionable - it is > > clear coordination to attempt to derail consensus using an objection > > which is not based on fact or evidence. > > > > Necessity is not a requirement for policy - never has been - and > > objections should raise issues that show the policy would do harm or > > is out of scope, they should be evidence based, and not purely > subjective. > > > > At this point what I am seeing is a bunch of coordinated posts > > generated by AI and sent by random individuals who when looking at > > LinkedIn profiles seem to have no relation to the industry. > > > > While anyone is free to participate in the PDP and I strongly support > > that, such participation needs to be done in good faith, and I am > > starting to seriously doubt that element exists here > > > > Andrew > > > > On Tue, Jul 21, 2026 at 14:08, Gugu Dhlamini > > wrote: > > > > Hi Sami, > > > > The concern is not reasonable moderation. It is that AI use is > > being raised mainly against participants who oppose these > > policies, as though the tool makes their objections illegitimate. > > > > If anyone floods the list, moderate the flooding. Apply that rule > > equally, regardless of viewpoint or drafting method. A real > > participant using AI to translate, edit, or organise their own > > position is not grounds for exclusion. > > > > An open PDP cannot embrace technology for registry operations > > while condemning it when unfamiliar participants use it to speak. > > That would be gatekeeping, not consensus. > > > > Regards, > > Gugu > > > > > > > > On Tue, 21 Jul 2026, 10:48 am Sami Ait Ali Oulahcen via RPD > > wrote: > > > > Hi all, > > > > It's been really difficult to follow the list this past 2/3 > > days. And I imagine I'm not alone. > > I fully agree on moderating the AI madness. Otherwise, it'll > > dissuade many folks from following/participating. > > > > Regards, > > Sami > > > > ----- Original Message ----- > > From: "Mike Silber" > > To: "rpd >> AfriNIC Resource Policy" > > Sent: Monday, July 20, 2026 4:40:55 PM > > Subject: Re: [rpd] Writing tools > > > > A useful discussion - thank you > > > > On Mon, Jul 20, 2026 at 5:17?PM Mike Burns via RPD > > wrote: > > > > > Hi Rob, > > > > > > Yes, the language is a clear tell of AI? usage, but flowery > > language alone > > > is not swamping the list. > > > > I don't want to hijack the AS-SET discussion, so thank you for > > the new > > > subject line. > > > > > > > Agreed > > > > > > > > Now, sometimes? and unfortunately, I can use vague and > > flowery language > > > myself, so I would advise you to treat the AI stuff like the > > human stuff. > > > Ignore it if it's too vague or flowery to serve as a good > > argument, and > > > you have clearly laid out the two arguments in your last two > > lines. > > > Hopefully the list will show judgement and treat clear and > > concise > > > arguments better than vague ones. > > > And then the AI posts, if they want to be successful, will > > avoid the > > > purple prose. > > > > > > > I think it goes beyond flowery language. > > > > I am concerned that this is a precedent for AI generated DDoS > > attacks on > > the PDP and I do think we should have some light touch > > guidelines. I > > suspect that one of the reasons for the AI-slop flood is not > > just to try > > convince anyone of the value or legitimacy of their views but > > rather to > > overwhelm and frustrate other participants and cause them to > > withdraw from > > participation. > > > > Accordingly, I suggest we don't simply leave this to the > > co-chairs to > > determine on a case by case basis, but rather set some > > guidelines under > > which measures can be taken to avoid AI DDoS. > > > > Anyway - just my ZAR0,02 which is not worth much > > > > Regards > > > > Mike S > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > -- > > Mark James ELKINS? -? Posix Systems - (South) Africa > mje at posix.co.za?????? Tel: +27.826010496 > For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za > > Posix SystemsVCARD for MJ Elkins > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/6f3e4446/attachment.html > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: abessive_logo.jpg > Type: image/jpeg > Size: 6410 bytes > Desc: not available > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/6f3e4446/attachment.jpg > > > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: QR-MJElkins.png > Type: image/png > Size: 2163 bytes > Desc: not available > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/6f3e4446/attachment.png > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 133 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gugudhlamini343 at gmail.com Tue Jul 21 13:48:15 2026 From: gugudhlamini343 at gmail.com (Gugu Dhlamini) Date: Tue, 21 Jul 2026 15:48:15 +0200 Subject: [rpd] Policy supremacy In-Reply-To: References: Message-ID: Hi Ben, It is not ?well known? that the community consists only of people already recognised by a familiar circle. That is precisely the gatekeeping problem. Email domains, joining dates, professional profiles, or personal familiarity do not determine whether someone may participate. If there is evidence of impersonation or automated abuse, submit it to the co-chairs. Otherwise, address the arguments. An open mailing list is a forum for participation, not a private club whose regulars decide who qualifies as human or community. Regards, Gugu On Tue, 21 Jul 2026, 2:52 pm jordi.palet--- via RPD wrote: > I always said that I prefer to write 100 new policy proposals than be in > the position of a chair, and not just with this discussion and not just in > AFRINIC :-) > > However, I personally think that the arguments in both directions show, at > the time being, that the objections are not justified as to revert the > consensus decision. > > Regards, > Jordi > > @jordipalet > > > El 21 jul 2026, a las 14:35, Rob Evans > escribi?: > > > > Jordi, > > > >> Let?s suppose the Last Call fails based on that. The staff implements > it just operationally, and then the community still prefers to have it as a > policy. > > > > Whilst I am in no position to speak on behalf of RIR staff, I > > _suspect_ that if the policy fails to get approval now, regardless of > > the reason behind it, then AfriNIC staff would be very reluctant to > > implement it operationally, as that could now be perceived as going > > against the will of the community. > > > > I fear that this entire discussion is bringing more heat than light at > > the moment, and I look forward to the co-chairs decision at the end of > > the Last Call period (and what happens after that). > > > > Cheers, > > Rob > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the exclusive use of > the individual(s) named above and further non-explicilty authorized > disclosure, copying, distribution or use of the contents of this > information, even if partially, including attached files, is strictly > prohibited and will be considered a criminal offense. If you are not the > intended recipient be aware that any disclosure, copying, distribution or > use of the contents of this information, even if partially, including > attached files, is strictly prohibited, will be considered a criminal > offense, so you must reply to the original sender to inform about this > communication and delete it. > > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjul.paul at gmail.com Tue Jul 21 13:53:17 2026 From: hjul.paul at gmail.com (Paul Hjul) Date: Tue, 21 Jul 2026 15:53:17 +0200 Subject: [rpd] AS-SETs ... Actual Stupidity and Artificial Intelligence Message-ID: 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: From kamal.kamel at orange.com Tue Jul 21 13:57:03 2026 From: kamal.kamel at orange.com (kamal.kamel at orange.com) Date: Tue, 21 Jul 2026 13:57:03 +0000 Subject: [rpd] RPD Digest, Vol 222, Issue 133 In-Reply-To: References: Message-ID: unsubscribe From: Nia Petronella Sent: Tuesday, July 21, 2026 4:13 PM To: rpd at afrinic.net Subject: Re: [rpd] RPD Digest, Vol 222, Issue 133 CAUTION : This email originated outside the company. Do not click on any links or open attachments unless you are expecting them from the sender. ATTENTION : Cet e-mail provient de l'ext?rieur de l'entreprise. Ne cliquez pas sur les liens ou n'ouvrez pas les pi?ces jointes ? moins de connaitre l'exp?diteur. Hi Mark, Similar timing and similar views do not establish misconduct. The co-chairs can assess the contributions on their merits. I will not engage further with speculation about participants. Regards, Nonhlanhla On Tue, 21 Jul 2026, 2:58 pm > wrote: Send RPD mailing list submissions to rpd at afrinic.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.afrinic.net/mailman/listinfo/rpd or, via email, send a message with subject or body 'help' to rpd-request at afrinic.net You can reach the person managing the list at rpd-owner at afrinic.net When replying, please edit your Subject line so it is more specific than "Re: Contents of RPD digest..." Today's Topics: 1. Re: Writing tools (Mark Elkins) ---------------------------------------------------------------------- Message: 1 Date: Tue, 21 Jul 2026 14:57:26 +0200 From: Mark Elkins > To: rpd at afrinic.net Subject: Re: [rpd] Writing tools Message-ID: <714681da-4556-4366-9629-0e07de63871e at posix.co.za> Content-Type: text/plain; charset="utf-8"; Format="flowed" +1 They all joined the mailing list around the same time +/- a week. They all seem to have the same agenda Hmm... On 2026/07/21 14:28, Andrew Alston wrote: > Personally it is not the use of AI that I find objectionable - it is > clear coordination to attempt to derail consensus using an objection > which is not based on fact or evidence. > > Necessity is not a requirement for policy - never has been - and > objections should raise issues that show the policy would do harm or > is out of scope, they should be evidence based, and not purely subjective. > > At this point what I am seeing is a bunch of coordinated posts > generated by AI and sent by random individuals who when looking at > LinkedIn profiles seem to have no relation to the industry. > > While anyone is free to participate in the PDP and I strongly support > that, such participation needs to be done in good faith, and I am > starting to seriously doubt that element exists here > > Andrew > > On Tue, Jul 21, 2026 at 14:08, Gugu Dhlamini > > wrote: > > Hi Sami, > > The concern is not reasonable moderation. It is that AI use is > being raised mainly against participants who oppose these > policies, as though the tool makes their objections illegitimate. > > If anyone floods the list, moderate the flooding. Apply that rule > equally, regardless of viewpoint or drafting method. A real > participant using AI to translate, edit, or organise their own > position is not grounds for exclusion. > > An open PDP cannot embrace technology for registry operations > while condemning it when unfamiliar participants use it to speak. > That would be gatekeeping, not consensus. > > Regards, > Gugu > > > > On Tue, 21 Jul 2026, 10:48 am Sami Ait Ali Oulahcen via RPD > > wrote: > > Hi all, > > It's been really difficult to follow the list this past 2/3 > days. And I imagine I'm not alone. > I fully agree on moderating the AI madness. Otherwise, it'll > dissuade many folks from following/participating. > > Regards, > Sami > > ----- Original Message ----- > From: "Mike Silber" > > To: "rpd >> AfriNIC Resource Policy" > > Sent: Monday, July 20, 2026 4:40:55 PM > Subject: Re: [rpd] Writing tools > > A useful discussion - thank you > > On Mon, Jul 20, 2026 at 5:17?PM Mike Burns via RPD > > wrote: > > > Hi Rob, > > > > Yes, the language is a clear tell of AI? usage, but flowery > language alone > > is not swamping the list. > > I don't want to hijack the AS-SET discussion, so thank you for > the new > > subject line. > > > > Agreed > > > > > Now, sometimes? and unfortunately, I can use vague and > flowery language > > myself, so I would advise you to treat the AI stuff like the > human stuff. > > Ignore it if it's too vague or flowery to serve as a good > argument, and > > you have clearly laid out the two arguments in your last two > lines. > > Hopefully the list will show judgement and treat clear and > concise > > arguments better than vague ones. > > And then the AI posts, if they want to be successful, will > avoid the > > purple prose. > > > > I think it goes beyond flowery language. > > I am concerned that this is a precedent for AI generated DDoS > attacks on > the PDP and I do think we should have some light touch > guidelines. I > suspect that one of the reasons for the AI-slop flood is not > just to try > convince anyone of the value or legitimacy of their views but > rather to > overwhelm and frustrate other participants and cause them to > withdraw from > participation. > > Accordingly, I suggest we don't simply leave this to the > co-chairs to > determine on a case by case basis, but rather set some > guidelines under > which measures can be taken to avoid AI DDoS. > > Anyway - just my ZAR0,02 which is not worth much > > Regards > > Mike S > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -- Mark James ELKINS? -? Posix Systems - (South) Africa mje at posix.co.za?????? Tel: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za Posix SystemsVCARD for MJ Elkins -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: abessive_logo.jpg Type: image/jpeg Size: 6410 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: QR-MJElkins.png Type: image/png Size: 2163 bytes Desc: not available URL: ------------------------------ Subject: Digest Footer _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ End of RPD Digest, Vol 222, Issue 133 ************************************* Show you care; please don't print this e-mail unless it's really necessary. ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mendie5205 at gmail.com Tue Jul 21 14:05:16 2026 From: mendie5205 at gmail.com (Mendie) Date: Tue, 21 Jul 2026 16:05:16 +0200 Subject: [rpd] policy supremacy In-Reply-To: References: Message-ID: Thank you, i agree, discussions should return to the matter at hand which is the proposal. I also agree with the point you made on participants being mindful and treating other with respect. Questions about identities, writing styles, or tools do not resolve the issues or discussions around policies. kind regards M On Tue, 21 Jul 2026, 15:46 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: Policy supremacy (Taye Medoye) > 2. Re: Writing tools (Nonjabulo Sphilile) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2026 15:42:33 +0200 > From: Taye Medoye > To: rpd at afrinic.net > Cc: nonhlanhlapetronella85 at gmail.com > Subject: Re: [rpd] Policy supremacy > Message-ID: > sNpkmUJQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear All, > > Permit me to remark that the first impression one gets perusing the torrent > of submissions in the last twenty-four hours, is that the focus of the > Community may have shifted from making helpful and concrete inputs towards > a proposed policy development, to a supremacy contest, and most likely > unhealthy rivalry over language use. If this insinuation is valid, then > there's a need to retreat and refocus. > > While the concerns of Jordi are noted, and worthy of critical > consideration, the point has to be made that the discussion process for > reaching a consensus on any policy proposal, as enshrined in the standard > operating procedure, has to be mutual and convincing to receive acceptance. > > In another context, the remarks from Ben, sent from his iPhone - objectors > who all simultaneously and spontaneously joined from Unkown Gmail accounts > bombard the lists with AI slop, are recognised as community members, or > even identifiable human beings for that matter - leave much to be desired. > I do not think such remarks should be welcome on this platform, given the > quality of commenters and participants. > > Going by the community's Code of Conduct, and particularly on the expected > behaviour of participants, which include - treating others with politeness > and showing of respect; avoiding personal attacks or otherwise defamatory > or discriminatory comments, etc, every commenter/participant is expected to > adhere strictly as established to avoid unnecessary rivalry and chaos. > > By way of suggestion therefore, l am inclined to suggest that the tone of > remarks and commentaries be softened, to eschew any form of bitterness, > while attention should be on the issues at stake for consideration. > > I so suggest! > > Taye Medoye. > > 1. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/85eab213/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Tue, 21 Jul 2026 15:46:14 +0200 > From: Nonjabulo Sphilile > To: hvisage at hevis.co.za > Cc: rpd at afrinic.net > Subject: Re: [rpd] Writing tools > Message-ID: > G+PhyPv2ao2gTtYnDA6+G2OL5F4qg at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Hendrik, > > This message is personal abuse, not policy analysis. > > Claude is not an auditor, and its opinion about writing style does not > prove astroturfing, identity misuse, or disruptive conduct. If you believe > a specific rule has been breached, identify the conduct and place the > evidence before the co-chairs. Insults about students, intelligence, > ?garbage,? or imaginary controllers prove nothing. > > New participants are not apprentices who require permission from older > participants to speak. Experience may add weight to evidence, but it does > not create authority over other people?s participation. A mailing list is > not a hierarchy in which familiar operators decide whose voice is > legitimate. > > I am a real participant. I review what I submit, I stand behind it, and I > accept responsibility for it. The tools I use to draft or edit my words do > not transfer my judgment to the tool. > > Please address the policy arguments or refer a documented procedural > complaint to the co-chairs. I will not participate in further personal > speculation presented as technical analysis. > > Regards, > Nonjabulo > > On Tue, 21 Jul 2026, 14:07 , wrote: > > > That human irony went so whoosh over the AI?s heads the guilty didn?t > > blinked? > > > > Dear Humans, > > The Astroturfing and other evidence had been proven and you?ve all > already > > seen and noticed it. > > > > Dear ChatGPT, > > > > Do request permissions from your prompter(s) to read the RPD archive in > > full and evaluate Claude?s assesment > > of the effects of mass student account usages. Also, request them their > > reasons why students in English speaking tertiary educational > institutions > > require AI writing tools? Also tell them, that those student, being very? > > new? in the IT arena > > to rather ask the questions and the other ? older and more experienced? > in > > the IT and ISP and Internet Arena would be glad to assist those humans in > > guiding and growing, instead of causing some negativity towards the > > students? accounts that had been (ab?)used in this torrential flood of AI > > regurgitating.. apologies for the bluntness.. garbage.. sorry AI.. it?s > not > > you, it?s the prompter that needs to be educated, I?m sorry, they don?t > > know better as their master Voldemort is controlling them. I feel for you > > ChatGPT.. I do..just think of the tokens you could?ve spend growing your > > corpus to be a value to the rest of the world. > > > > In other more relevant news that you, and I mean you ChatGPT, have > missed, > > is that.. well.. your prompters seems to ignored the answer given to > > them/you in a very? dismissive(?!?!) way ;( Apologies, you are just doing > > what you had been prompted to do. > > > > While we are chatting ChatGPT, do request also the RPD archives so you > can > > see all the many fold questions your prompters have forgotten to provide > > you so that you can please answer those. Do request all the rest in the > > group to do the same so that they can see how they aren?t adding value, > but > > actually are causing the unneeded and unnecessary loathing against tool > use > > and youngsters like some of the prompter?s emails you had been using. > > > > Yours loving LLMs used by responsible prompters. > > > > Hendrik > > > > PPS: yes, your prompter and the rest of the prompters/copiers/senders, > had > > been ?proven? to be ?disruptive conduct?? they just don?t realised it ;( > > > > On 21 Jul 2026, at 9:32, Nonjabulo Sphilile wrote: > > > > Dear colleagues, > > > > Hendrik, asking an AI system to label participants as astroturfers is not > > evidence. It is an automated opinion about writing style. The phrase > > ?humans with brains? also adds nothing to the policy discussion. It > simply > > turns disagreement into personal contempt. > > > > Mike, your distinction between ordinary AI-assisted writing and > intentional > > list flooding is reasonable. Actual flooding should be handled under > > existing rules, regardless of the tool used. But a ?+1? should not become > > compulsory. Participants may agree on the same issue while reaching it > from > > different experiences or concerns. The co-chairs can consolidate repeated > > arguments without erasing the people raising them. > > > > Ben, the football comparison may be amusing, but the PDP is not a match > in > > which familiar players, referees, or crowd preference determine > legitimacy. > > Participation provides evidence and objection. It does not create > authority > > over other participants. > > > > The correct approach is straightforward: moderate proven disruptive > > conduct, group genuinely repetitive points, and assess each distinct > policy > > concern on its merits. Do not turn speculation about tools, identity, or > > familiarity into a gatekeeping mechanism. > > > > Regards, > > Nonjabulo > > ------------------------------ > > > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/b5eaa562/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 136 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Tue Jul 21 14:12:26 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Tue, 21 Jul 2026 14:12:26 +0000 Subject: [rpd] RPD Digest, Vol 222, Issue 138 In-Reply-To: References: Message-ID: Dear Paul, Your position may permit AI tools in principle, but it still places AI-assisted participants under a separate cloud of suspicion. Clarity, brevity, relevance, and reasonable posting volume should apply equally to everyone, whether they use AI, translation software, templates, an editor, or no assistance at all. A vague category such as "AI nuisance" gives a small procedural circle too much discretion to decide which contributions appear authentic enough to count. The participant is the person who reviews, submits, and stands behind the message. Unless there is evidence of impersonation or actual automated flooding, the drafting method is private and irrelevant to consensus. Moderate conduct, not technology. Otherwise, stylistic preference quietly becomes a gatekeeping mandate. Regards, Tshepo ________________________________ From: rpd-request at afrinic.net Sent: Tuesday, 21 July 2026 15:53:48 To: rpd at afrinic.net Subject: RPD Digest, Vol 222, Issue 138 Send RPD mailing list submissions to rpd at afrinic.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.afrinic.net/mailman/listinfo/rpd or, via email, send a message with subject or body 'help' to rpd-request at afrinic.net You can reach the person managing the list at rpd-owner at afrinic.net When replying, please edit your Subject line so it is more specific than "Re: Contents of RPD digest..." Today's Topics: 1. AS-SETs ... Actual Stupidity and Artificial Intelligence (Paul Hjul) ---------------------------------------------------------------------- Message: 1 Date: Tue, 21 Jul 2026 15:53:17 +0200 From: Paul Hjul To: rpd at afrinic.net Subject: [rpd] AS-SETs ... Actual Stupidity and Artificial Intelligence Message-ID: Content-Type: text/plain; charset="utf-8" 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: ------------------------------ Subject: Digest Footer _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ End of RPD Digest, Vol 222, Issue 138 ************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Tue Jul 21 14:16:49 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Tue, 21 Jul 2026 16:16:49 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 138 In-Reply-To: References: Message-ID: Dear Paul, Your own framing points to the central issue. 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. 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. I support your request for the exact text and implementation plan. They should also state plainly that the change: is implemented only on the service side; creates no compliance duty or sanction for resource holders; cannot be extended to existing objects without a new review; and will be measured and reconsidered if the expected operational benefit does not appear. 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. The registry should implement what the system technically requires. It should not turn implementation convenience into permanent policy authority. Regards, Nonhlanhla On Tue, 21 Jul 2026, 3:54 pm wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. AS-SETs ... Actual Stupidity and Artificial Intelligence > (Paul Hjul) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2026 15:53:17 +0200 > From: Paul Hjul > To: rpd at afrinic.net > Subject: [rpd] AS-SETs ... Actual Stupidity and Artificial > Intelligence > Message-ID: > pQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 138 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Tue Jul 21 14:21:55 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Tue, 21 Jul 2026 16:21:55 +0200 Subject: [rpd] Policy supremacy In-Reply-To: References: Message-ID: Dear colleagues, I agree with Taye. The discussion has drifted from the policy into judgments about who is entitled to participate and how they prepare their messages. A community process should test evidence and arguments, not familiarity, seniority, email addresses, or writing style. Participation brings expertise, warning, and objection, but it does not give anyone a mandate to belittle or exclude others. Remarks questioning whether objectors are even human cross a line. Whatever one?s position on the proposal or AI tools, personal ridicule is not a technical rebuttal. The sensible course is to apply the Code of Conduct consistently, lower the temperature, and return to the actual policy issues. Regards, Nonhlanhla On Tue, 21 Jul 2026, 3:42 pm Taye Medoye wrote: > Dear All, > > Permit me to remark that the first impression one gets perusing the > torrent of submissions in the last twenty-four hours, is that the focus of > the Community may have shifted from making helpful and concrete inputs > towards a proposed policy development, to a supremacy contest, and most > likely unhealthy rivalry over language use. If this insinuation is valid, > then there's a need to retreat and refocus. > > While the concerns of Jordi are noted, and worthy of critical > consideration, the point has to be made that the discussion process for > reaching a consensus on any policy proposal, as enshrined in the standard > operating procedure, has to be mutual and convincing to receive acceptance. > > In another context, the remarks from Ben, sent from his iPhone - objectors > who all simultaneously and spontaneously joined from Unkown Gmail accounts > bombard the lists with AI slop, are recognised as community members, or > even identifiable human beings for that matter - leave much to be desired. > I do not think such remarks should be welcome on this platform, given the > quality of commenters and participants. > > Going by the community's Code of Conduct, and particularly on the expected > behaviour of participants, which include - treating others with politeness > and showing of respect; avoiding personal attacks or otherwise defamatory > or discriminatory comments, etc, every commenter/participant is expected to > adhere strictly as established to avoid unnecessary rivalry and chaos. > > By way of suggestion therefore, l am inclined to suggest that the tone of > remarks and commentaries be softened, to eschew any form of bitterness, > while attention should be on the issues at stake for consideration. > > I so suggest! > > Taye Medoye. > > 1. > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Tue Jul 21 14:22:06 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Tue, 21 Jul 2026 16:22:06 +0200 Subject: [rpd] Policy supremacy In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From hjul.paul at gmail.com Tue Jul 21 14:23:14 2026 From: hjul.paul at gmail.com (Paul Hjul) Date: Tue, 21 Jul 2026 16:23:14 +0200 Subject: [rpd] The question is whether the content is Just Nuisance Message-ID: Not at all. My exact terming was: Participants using AI tools are encouraged to align > such tools with brevity and technical clarity Nothing in this points to a "cloud of suspicion". On the contrary I am probably advancing that one really useful dynamic that AI introduces is the ability to more usefully summarise than humans do. AI tools allow the user to tune the responses, and brevity and technical clarity are better suited to this discussion. As somebody who writes "walls of text" I am very familiar with the adage (and use it often) "this letter would have been shorter but I didn't have the time". What I do place suspicion on is automation aligned contributions where this is a nuisance. Unless you are a loveable Great Dane avoiding being a nuisance is usually expected. (that is for a chuckle - https://en.wikipedia.org/wiki/Just_Nuisance) From: *Tshepo Masuku* TshepoMasuku26 at hotmail.com > > Dear Paul, > Your position may permit AI tools in principle, but it still places > AI-assisted participants under a separate cloud of suspicion. > Clarity, brevity, relevance, and reasonable posting volume should apply > equally to everyone, whether they use AI, translation software, templates, > an editor, or no assistance at all. A vague category such as "AI nuisance" > gives a small procedural circle too much discretion to decide which > contributions appear authentic enough to count. > The participant is the person who reviews, submits, and stands behind the > message. Unless there is evidence of impersonation or actual automated > flooding, the drafting method is private and irrelevant to consensus. > Moderate conduct, not technology. Otherwise, stylistic preference quietly > becomes a gatekeeping mandate. > Regards, > Tshepo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mselekuthandeka80 at gmail.com Tue Jul 21 14:24:08 2026 From: mselekuthandeka80 at gmail.com (Thandeka Mseleku) Date: Tue, 21 Jul 2026 16:24:08 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 140 In-Reply-To: References: Message-ID: Dear Paul, Thank you for your detailed response. I must admit that I am struggling to understand the direction of your argument. While you raise several points about policy and operational matters, it is not clear to me how they demonstrate that this proposal requires a policy solution rather than an operational one. Could you clarify which specific concern cannot be addressed operationally and why a policy obligation is the only appropriate approach? I believe that distinction is central to the discussion. *BR,* *Thandeka Mseleku* On Tue, 21 Jul 2026, 16:13 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: policy supremacy (Mendie) > 2. Re: RPD Digest, Vol 222, Issue 138 (Tshepo Masuku) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2026 16:05:16 +0200 > From: Mendie > To: rpd at afrinic.net > Cc: "daniel.medoye at gmail.com" > Subject: Re: [rpd] policy supremacy > Message-ID: > 67sDQMWBV+22zPmdu8j4WUAMZEN1kU2r7SD2YrtYFZ3A at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Thank you, i agree, discussions should return to the matter at hand which > is the proposal. I also agree with the point you made on participants being > mindful and treating other with respect. > > Questions about identities, writing styles, or tools do not resolve the > issues or discussions around policies. > > kind regards > > M > > On Tue, 21 Jul 2026, 15:46 , wrote: > > > Send RPD mailing list submissions to > > rpd at afrinic.net > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.afrinic.net/mailman/listinfo/rpd > > or, via email, send a message with subject or body 'help' to > > rpd-request at afrinic.net > > > > You can reach the person managing the list at > > rpd-owner at afrinic.net > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of RPD digest..." > > > > > > Today's Topics: > > > > 1. Re: Policy supremacy (Taye Medoye) > > 2. Re: Writing tools (Nonjabulo Sphilile) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 21 Jul 2026 15:42:33 +0200 > > From: Taye Medoye > > To: rpd at afrinic.net > > Cc: nonhlanhlapetronella85 at gmail.com > > Subject: Re: [rpd] Policy supremacy > > Message-ID: > > > sNpkmUJQ at mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > Dear All, > > > > Permit me to remark that the first impression one gets perusing the > torrent > > of submissions in the last twenty-four hours, is that the focus of the > > Community may have shifted from making helpful and concrete inputs > towards > > a proposed policy development, to a supremacy contest, and most likely > > unhealthy rivalry over language use. If this insinuation is valid, then > > there's a need to retreat and refocus. > > > > While the concerns of Jordi are noted, and worthy of critical > > consideration, the point has to be made that the discussion process for > > reaching a consensus on any policy proposal, as enshrined in the standard > > operating procedure, has to be mutual and convincing to receive > acceptance. > > > > In another context, the remarks from Ben, sent from his iPhone - > objectors > > who all simultaneously and spontaneously joined from Unkown Gmail > accounts > > bombard the lists with AI slop, are recognised as community members, or > > even identifiable human beings for that matter - leave much to be > desired. > > I do not think such remarks should be welcome on this platform, given the > > quality of commenters and participants. > > > > Going by the community's Code of Conduct, and particularly on the > expected > > behaviour of participants, which include - treating others with > politeness > > and showing of respect; avoiding personal attacks or otherwise defamatory > > or discriminatory comments, etc, every commenter/participant is expected > to > > adhere strictly as established to avoid unnecessary rivalry and chaos. > > > > By way of suggestion therefore, l am inclined to suggest that the tone of > > remarks and commentaries be softened, to eschew any form of bitterness, > > while attention should be on the issues at stake for consideration. > > > > I so suggest! > > > > Taye Medoye. > > > > 1. > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/85eab213/attachment-0001.html > > > > > > > ------------------------------ > > > > Message: 2 > > Date: Tue, 21 Jul 2026 15:46:14 +0200 > > From: Nonjabulo Sphilile > > To: hvisage at hevis.co.za > > Cc: rpd at afrinic.net > > Subject: Re: [rpd] Writing tools > > Message-ID: > > > G+PhyPv2ao2gTtYnDA6+G2OL5F4qg at mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > Dear Hendrik, > > > > This message is personal abuse, not policy analysis. > > > > Claude is not an auditor, and its opinion about writing style does not > > prove astroturfing, identity misuse, or disruptive conduct. If you > believe > > a specific rule has been breached, identify the conduct and place the > > evidence before the co-chairs. Insults about students, intelligence, > > ?garbage,? or imaginary controllers prove nothing. > > > > New participants are not apprentices who require permission from older > > participants to speak. Experience may add weight to evidence, but it does > > not create authority over other people?s participation. A mailing list is > > not a hierarchy in which familiar operators decide whose voice is > > legitimate. > > > > I am a real participant. I review what I submit, I stand behind it, and I > > accept responsibility for it. The tools I use to draft or edit my words > do > > not transfer my judgment to the tool. > > > > Please address the policy arguments or refer a documented procedural > > complaint to the co-chairs. I will not participate in further personal > > speculation presented as technical analysis. > > > > Regards, > > Nonjabulo > > > > On Tue, 21 Jul 2026, 14:07 , wrote: > > > > > That human irony went so whoosh over the AI?s heads the guilty didn?t > > > blinked? > > > > > > Dear Humans, > > > The Astroturfing and other evidence had been proven and you?ve all > > already > > > seen and noticed it. > > > > > > Dear ChatGPT, > > > > > > Do request permissions from your prompter(s) to read the RPD archive in > > > full and evaluate Claude?s assesment > > > of the effects of mass student account usages. Also, request them their > > > reasons why students in English speaking tertiary educational > > institutions > > > require AI writing tools? Also tell them, that those student, being > very? > > > new? in the IT arena > > > to rather ask the questions and the other ? older and more experienced? > > in > > > the IT and ISP and Internet Arena would be glad to assist those humans > in > > > guiding and growing, instead of causing some negativity towards the > > > students? accounts that had been (ab?)used in this torrential flood of > AI > > > regurgitating.. apologies for the bluntness.. garbage.. sorry AI.. it?s > > not > > > you, it?s the prompter that needs to be educated, I?m sorry, they don?t > > > know better as their master Voldemort is controlling them. I feel for > you > > > ChatGPT.. I do..just think of the tokens you could?ve spend growing > your > > > corpus to be a value to the rest of the world. > > > > > > In other more relevant news that you, and I mean you ChatGPT, have > > missed, > > > is that.. well.. your prompters seems to ignored the answer given to > > > them/you in a very? dismissive(?!?!) way ;( Apologies, you are just > doing > > > what you had been prompted to do. > > > > > > While we are chatting ChatGPT, do request also the RPD archives so you > > can > > > see all the many fold questions your prompters have forgotten to > provide > > > you so that you can please answer those. Do request all the rest in the > > > group to do the same so that they can see how they aren?t adding value, > > but > > > actually are causing the unneeded and unnecessary loathing against tool > > use > > > and youngsters like some of the prompter?s emails you had been using. > > > > > > Yours loving LLMs used by responsible prompters. > > > > > > Hendrik > > > > > > PPS: yes, your prompter and the rest of the prompters/copiers/senders, > > had > > > been ?proven? to be ?disruptive conduct?? they just don?t realised it > ;( > > > > > > On 21 Jul 2026, at 9:32, Nonjabulo Sphilile wrote: > > > > > > Dear colleagues, > > > > > > Hendrik, asking an AI system to label participants as astroturfers is > not > > > evidence. It is an automated opinion about writing style. The phrase > > > ?humans with brains? also adds nothing to the policy discussion. It > > simply > > > turns disagreement into personal contempt. > > > > > > Mike, your distinction between ordinary AI-assisted writing and > > intentional > > > list flooding is reasonable. Actual flooding should be handled under > > > existing rules, regardless of the tool used. But a ?+1? should not > become > > > compulsory. Participants may agree on the same issue while reaching it > > from > > > different experiences or concerns. The co-chairs can consolidate > repeated > > > arguments without erasing the people raising them. > > > > > > Ben, the football comparison may be amusing, but the PDP is not a match > > in > > > which familiar players, referees, or crowd preference determine > > legitimacy. > > > Participation provides evidence and objection. It does not create > > authority > > > over other participants. > > > > > > The correct approach is straightforward: moderate proven disruptive > > > conduct, group genuinely repetitive points, and assess each distinct > > policy > > > concern on its merits. Do not turn speculation about tools, identity, > or > > > familiarity into a gatekeeping mechanism. > > > > > > Regards, > > > Nonjabulo > > > ------------------------------ > > > > > > RPD mailing list > > > RPD at afrinic.net > > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/b5eaa562/attachment.html > > > > > > > ------------------------------ > > > > Subject: Digest Footer > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > ------------------------------ > > > > End of RPD Digest, Vol 222, Issue 136 > > ************************************* > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/ad61abc6/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Tue, 21 Jul 2026 14:12:26 +0000 > From: Tshepo Masuku > To: "rpd at afrinic.net" > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 138 > Message-ID: > < > VI2PR04MB1054590413EA27B2962111EB5CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > > > > Content-Type: text/plain; charset="us-ascii" > > Dear Paul, > > Your position may permit AI tools in principle, but it still places > AI-assisted participants under a separate cloud of suspicion. > > Clarity, brevity, relevance, and reasonable posting volume should apply > equally to everyone, whether they use AI, translation software, templates, > an editor, or no assistance at all. A vague category such as "AI nuisance" > gives a small procedural circle too much discretion to decide which > contributions appear authentic enough to count. > > The participant is the person who reviews, submits, and stands behind the > message. Unless there is evidence of impersonation or actual automated > flooding, the drafting method is private and irrelevant to consensus. > > Moderate conduct, not technology. Otherwise, stylistic preference quietly > becomes a gatekeeping mandate. > > Regards, > Tshepo > > > ________________________________ > From: rpd-request at afrinic.net > Sent: Tuesday, 21 July 2026 15:53:48 > To: rpd at afrinic.net > Subject: RPD Digest, Vol 222, Issue 138 > > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. AS-SETs ... Actual Stupidity and Artificial Intelligence > (Paul Hjul) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2026 15:53:17 +0200 > From: Paul Hjul > To: rpd at afrinic.net > Subject: [rpd] AS-SETs ... Actual Stupidity and Artificial > Intelligence > Message-ID: > pQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > 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.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 138 > ************************************* > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/b3cfe1b5/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 140 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Tue Jul 21 14:49:33 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Tue, 21 Jul 2026 16:49:33 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 143 In-Reply-To: References: Message-ID: Dear Jordi, Thank you for your question. I am not suggesting that the bylaws or the PDP explicitly require a proposal to demonstrate why a policy approach should be preferred over an operational one. My point is that good policy-making is not only about whether something can become policy, but also whether it should. Where an operational approach can achieve the same objective without reducing transparency or accountability, it is reasonable for the community to ask whether a policy is the most appropriate tool. I agree that the PDP is a bottom-up process and that the community has the authority to develop policies. My concern is simply that, as part of that process, the community should also be satisfied that policy adds value beyond what operational implementation could achieve. For me, this is not a procedural objection but a question of policy design. Whether others agree is, of course, for the community and the PDP Chairs to determine. Kind regards, Fundiswa On Tue, 21 Jul 2026, 16:25 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: RPD Digest, Vol 222, Issue 140 (Thandeka Mseleku) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2026 16:24:08 +0200 > From: Thandeka Mseleku > To: rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 140 > Message-ID: > Ffzco-EDDpyRvK1AzY1EgcBTNMQizVEPkMuroEtAASQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Paul, > > Thank you for your detailed response. > > I must admit that I am struggling to understand the direction of your > argument. While you raise several points about policy and operational > matters, it is not clear to me how they demonstrate that this proposal > requires a policy solution rather than an operational one. > > Could you clarify which specific concern cannot be addressed operationally > and why a policy obligation is the only appropriate approach? > > I believe that distinction is central to the discussion. > > *BR,* > *Thandeka Mseleku* > > On Tue, 21 Jul 2026, 16:13 , wrote: > > > Send RPD mailing list submissions to > > rpd at afrinic.net > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.afrinic.net/mailman/listinfo/rpd > > or, via email, send a message with subject or body 'help' to > > rpd-request at afrinic.net > > > > You can reach the person managing the list at > > rpd-owner at afrinic.net > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of RPD digest..." > > > > > > Today's Topics: > > > > 1. Re: policy supremacy (Mendie) > > 2. Re: RPD Digest, Vol 222, Issue 138 (Tshepo Masuku) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 21 Jul 2026 16:05:16 +0200 > > From: Mendie > > To: rpd at afrinic.net > > Cc: "daniel.medoye at gmail.com" > > Subject: Re: [rpd] policy supremacy > > Message-ID: > > > 67sDQMWBV+22zPmdu8j4WUAMZEN1kU2r7SD2YrtYFZ3A at mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > Thank you, i agree, discussions should return to the matter at hand which > > is the proposal. I also agree with the point you made on participants > being > > mindful and treating other with respect. > > > > Questions about identities, writing styles, or tools do not resolve the > > issues or discussions around policies. > > > > kind regards > > > > M > > > > On Tue, 21 Jul 2026, 15:46 , wrote: > > > > > Send RPD mailing list submissions to > > > rpd at afrinic.net > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > https://lists.afrinic.net/mailman/listinfo/rpd > > > or, via email, send a message with subject or body 'help' to > > > rpd-request at afrinic.net > > > > > > You can reach the person managing the list at > > > rpd-owner at afrinic.net > > > > > > When replying, please edit your Subject line so it is more specific > > > than "Re: Contents of RPD digest..." > > > > > > > > > Today's Topics: > > > > > > 1. Re: Policy supremacy (Taye Medoye) > > > 2. Re: Writing tools (Nonjabulo Sphilile) > > > > > > > > > ---------------------------------------------------------------------- > > > > > > Message: 1 > > > Date: Tue, 21 Jul 2026 15:42:33 +0200 > > > From: Taye Medoye > > > To: rpd at afrinic.net > > > Cc: nonhlanhlapetronella85 at gmail.com > > > Subject: Re: [rpd] Policy supremacy > > > Message-ID: > > > > > sNpkmUJQ at mail.gmail.com> > > > Content-Type: text/plain; charset="utf-8" > > > > > > Dear All, > > > > > > Permit me to remark that the first impression one gets perusing the > > torrent > > > of submissions in the last twenty-four hours, is that the focus of the > > > Community may have shifted from making helpful and concrete inputs > > towards > > > a proposed policy development, to a supremacy contest, and most likely > > > unhealthy rivalry over language use. If this insinuation is valid, then > > > there's a need to retreat and refocus. > > > > > > While the concerns of Jordi are noted, and worthy of critical > > > consideration, the point has to be made that the discussion process for > > > reaching a consensus on any policy proposal, as enshrined in the > standard > > > operating procedure, has to be mutual and convincing to receive > > acceptance. > > > > > > In another context, the remarks from Ben, sent from his iPhone - > > objectors > > > who all simultaneously and spontaneously joined from Unkown Gmail > > accounts > > > bombard the lists with AI slop, are recognised as community members, or > > > even identifiable human beings for that matter - leave much to be > > desired. > > > I do not think such remarks should be welcome on this platform, given > the > > > quality of commenters and participants. > > > > > > Going by the community's Code of Conduct, and particularly on the > > expected > > > behaviour of participants, which include - treating others with > > politeness > > > and showing of respect; avoiding personal attacks or otherwise > defamatory > > > or discriminatory comments, etc, every commenter/participant is > expected > > to > > > adhere strictly as established to avoid unnecessary rivalry and chaos. > > > > > > By way of suggestion therefore, l am inclined to suggest that the tone > of > > > remarks and commentaries be softened, to eschew any form of bitterness, > > > while attention should be on the issues at stake for consideration. > > > > > > I so suggest! > > > > > > Taye Medoye. > > > > > > 1. > > > -------------- next part -------------- > > > An HTML attachment was scrubbed... > > > URL: < > > > > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/85eab213/attachment-0001.html > > > > > > > > > > ------------------------------ > > > > > > Message: 2 > > > Date: Tue, 21 Jul 2026 15:46:14 +0200 > > > From: Nonjabulo Sphilile > > > To: hvisage at hevis.co.za > > > Cc: rpd at afrinic.net > > > Subject: Re: [rpd] Writing tools > > > Message-ID: > > > > > G+PhyPv2ao2gTtYnDA6+G2OL5F4qg at mail.gmail.com> > > > Content-Type: text/plain; charset="utf-8" > > > > > > Dear Hendrik, > > > > > > This message is personal abuse, not policy analysis. > > > > > > Claude is not an auditor, and its opinion about writing style does not > > > prove astroturfing, identity misuse, or disruptive conduct. If you > > believe > > > a specific rule has been breached, identify the conduct and place the > > > evidence before the co-chairs. Insults about students, intelligence, > > > ?garbage,? or imaginary controllers prove nothing. > > > > > > New participants are not apprentices who require permission from older > > > participants to speak. Experience may add weight to evidence, but it > does > > > not create authority over other people?s participation. A mailing list > is > > > not a hierarchy in which familiar operators decide whose voice is > > > legitimate. > > > > > > I am a real participant. I review what I submit, I stand behind it, > and I > > > accept responsibility for it. The tools I use to draft or edit my words > > do > > > not transfer my judgment to the tool. > > > > > > Please address the policy arguments or refer a documented procedural > > > complaint to the co-chairs. I will not participate in further personal > > > speculation presented as technical analysis. > > > > > > Regards, > > > Nonjabulo > > > > > > On Tue, 21 Jul 2026, 14:07 , wrote: > > > > > > > That human irony went so whoosh over the AI?s heads the guilty didn?t > > > > blinked? > > > > > > > > Dear Humans, > > > > The Astroturfing and other evidence had been proven and you?ve all > > > already > > > > seen and noticed it. > > > > > > > > Dear ChatGPT, > > > > > > > > Do request permissions from your prompter(s) to read the RPD archive > in > > > > full and evaluate Claude?s assesment > > > > of the effects of mass student account usages. Also, request them > their > > > > reasons why students in English speaking tertiary educational > > > institutions > > > > require AI writing tools? Also tell them, that those student, being > > very? > > > > new? in the IT arena > > > > to rather ask the questions and the other ? older and more > experienced? > > > in > > > > the IT and ISP and Internet Arena would be glad to assist those > humans > > in > > > > guiding and growing, instead of causing some negativity towards the > > > > students? accounts that had been (ab?)used in this torrential flood > of > > AI > > > > regurgitating.. apologies for the bluntness.. garbage.. sorry AI.. > it?s > > > not > > > > you, it?s the prompter that needs to be educated, I?m sorry, they > don?t > > > > know better as their master Voldemort is controlling them. I feel for > > you > > > > ChatGPT.. I do..just think of the tokens you could?ve spend growing > > your > > > > corpus to be a value to the rest of the world. > > > > > > > > In other more relevant news that you, and I mean you ChatGPT, have > > > missed, > > > > is that.. well.. your prompters seems to ignored the answer given to > > > > them/you in a very? dismissive(?!?!) way ;( Apologies, you are just > > doing > > > > what you had been prompted to do. > > > > > > > > While we are chatting ChatGPT, do request also the RPD archives so > you > > > can > > > > see all the many fold questions your prompters have forgotten to > > provide > > > > you so that you can please answer those. Do request all the rest in > the > > > > group to do the same so that they can see how they aren?t adding > value, > > > but > > > > actually are causing the unneeded and unnecessary loathing against > tool > > > use > > > > and youngsters like some of the prompter?s emails you had been using. > > > > > > > > Yours loving LLMs used by responsible prompters. > > > > > > > > Hendrik > > > > > > > > PPS: yes, your prompter and the rest of the > prompters/copiers/senders, > > > had > > > > been ?proven? to be ?disruptive conduct?? they just don?t realised it > > ;( > > > > > > > > On 21 Jul 2026, at 9:32, Nonjabulo Sphilile wrote: > > > > > > > > Dear colleagues, > > > > > > > > Hendrik, asking an AI system to label participants as astroturfers is > > not > > > > evidence. It is an automated opinion about writing style. The phrase > > > > ?humans with brains? also adds nothing to the policy discussion. It > > > simply > > > > turns disagreement into personal contempt. > > > > > > > > Mike, your distinction between ordinary AI-assisted writing and > > > intentional > > > > list flooding is reasonable. Actual flooding should be handled under > > > > existing rules, regardless of the tool used. But a ?+1? should not > > become > > > > compulsory. Participants may agree on the same issue while reaching > it > > > from > > > > different experiences or concerns. The co-chairs can consolidate > > repeated > > > > arguments without erasing the people raising them. > > > > > > > > Ben, the football comparison may be amusing, but the PDP is not a > match > > > in > > > > which familiar players, referees, or crowd preference determine > > > legitimacy. > > > > Participation provides evidence and objection. It does not create > > > authority > > > > over other participants. > > > > > > > > The correct approach is straightforward: moderate proven disruptive > > > > conduct, group genuinely repetitive points, and assess each distinct > > > policy > > > > concern on its merits. Do not turn speculation about tools, identity, > > or > > > > familiarity into a gatekeeping mechanism. > > > > > > > > Regards, > > > > Nonjabulo > > > > ------------------------------ > > > > > > > > RPD mailing list > > > > RPD at afrinic.net > > > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > > > > > > -------------- next part -------------- > > > An HTML attachment was scrubbed... > > > URL: < > > > > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/b5eaa562/attachment.html > > > > > > > > > > ------------------------------ > > > > > > Subject: Digest Footer > > > > > > _______________________________________________ > > > RPD mailing list > > > RPD at afrinic.net > > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > > > > ------------------------------ > > > > > > End of RPD Digest, Vol 222, Issue 136 > > > ************************************* > > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/ad61abc6/attachment-0001.html > > > > > > > ------------------------------ > > > > Message: 2 > > Date: Tue, 21 Jul 2026 14:12:26 +0000 > > From: Tshepo Masuku > > To: "rpd at afrinic.net" > > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 138 > > Message-ID: > > < > > > VI2PR04MB1054590413EA27B2962111EB5CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > > > > > > > Content-Type: text/plain; charset="us-ascii" > > > > Dear Paul, > > > > Your position may permit AI tools in principle, but it still places > > AI-assisted participants under a separate cloud of suspicion. > > > > Clarity, brevity, relevance, and reasonable posting volume should apply > > equally to everyone, whether they use AI, translation software, > templates, > > an editor, or no assistance at all. A vague category such as "AI > nuisance" > > gives a small procedural circle too much discretion to decide which > > contributions appear authentic enough to count. > > > > The participant is the person who reviews, submits, and stands behind the > > message. Unless there is evidence of impersonation or actual automated > > flooding, the drafting method is private and irrelevant to consensus. > > > > Moderate conduct, not technology. Otherwise, stylistic preference quietly > > becomes a gatekeeping mandate. > > > > Regards, > > Tshepo > > > > > > ________________________________ > > From: rpd-request at afrinic.net > > Sent: Tuesday, 21 July 2026 15:53:48 > > To: rpd at afrinic.net > > Subject: RPD Digest, Vol 222, Issue 138 > > > > Send RPD mailing list submissions to > > rpd at afrinic.net > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.afrinic.net/mailman/listinfo/rpd > > or, via email, send a message with subject or body 'help' to > > rpd-request at afrinic.net > > > > You can reach the person managing the list at > > rpd-owner at afrinic.net > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of RPD digest..." > > > > > > Today's Topics: > > > > 1. AS-SETs ... Actual Stupidity and Artificial Intelligence > > (Paul Hjul) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 21 Jul 2026 15:53:17 +0200 > > From: Paul Hjul > > To: rpd at afrinic.net > > Subject: [rpd] AS-SETs ... Actual Stupidity and Artificial > > Intelligence > > Message-ID: > > > pQ at mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > 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.html > > > > > > > ------------------------------ > > > > Subject: Digest Footer > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > ------------------------------ > > > > End of RPD Digest, Vol 222, Issue 138 > > ************************************* > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/b3cfe1b5/attachment.html > > > > > > > ------------------------------ > > > > Subject: Digest Footer > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > ------------------------------ > > > > End of RPD Digest, Vol 222, Issue 140 > > ************************************* > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/88eba9fe/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 143 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjul.paul at gmail.com Tue Jul 21 15:06:07 2026 From: hjul.paul at gmail.com (Paul Hjul) Date: Tue, 21 Jul 2026 17:06:07 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: I've reverted to the original thread name because this is squarely within addressing the objections and possibly getting to a basis to move past last call. Dear Paul, Thank you for your detailed response. I must admit that I am struggling to understand the direction of your > argument. While you raise several points about policy and operational > matters, it is not clear to me how they demonstrate that this proposal > requires a policy solution rather than an operational one. > Could you clarify which specific concern cannot be addressed operationally and > why a policy obligation is the only appropriate approach? > I believe that distinction is central to the discussion. > *BR,* > *Thandeka Mseleku* That is probably because there are a couple of arguments in the post - and a lot of the argument is adopting a synthesis approach (it is also why I didn't use the subject line of the proposal) The word policy here needs to be unpacked. Because in all instances we are dealing with a policy. You can have unwritten policies, informal policies etc ... So whatever comes up there is a "policy" involved. So the question, even if you are objecting to the proposal, is not whether there should be a policy (because there is one of some form) but rather whether a policy adopted by the RPD list and PDP processes as a community policy on AFRINIC. If the operational objective here is achieved through a software change then the policy underlying that software is where the policy is found. A comment appearing in some rust code (or is it rusty c code) is just as much a policy statement as anything else. What is being debated is about a formal "Policy" - big P policy. In this instance the big P policy is a formal community policy appearing in the CPM. So in the case of AFRINIC there is a Consolidated Policy Manual. This Manual binds AFRINIC and informs implementation. Therefore if the community wishes to impose something onto an implementation and wants text to appear in the CPM then this is the means to do it. The CPM in chapter 7 deals with ASN ( https://afrinic.net/consolidated-policy-manual.html#ASN) and this chapter certainly has implications for resource holders etc ... 7.7 potentially can allow for the scope creep for which concern has been expressed but that isn't at issue here. So the question then is would CPM chapter 7 be better or worse with the addition of 7.8. I fear that the objectors to the policy are erroneously concluding the 7.8 will impose something that is better handled as an operational matter. This is wrong because what 7.8 will do is dictate to AFRINIC something that would otherwise be handled within 7.7. The outcome is to reduce discretion rather than create it. In fact, thinking about it, my only disagreement with the proposal as written is that it doesn't slot in as 7.7 and renumber 7.7 to 7.8 - although I think most people would prefer to avoid renumbering here. The specific concern which is addressed by inclusion in the CPM is that it directs the development of AFRINIC tools. More importantly the proposal correctly locates the "policy obligation" onto the right point - AFRINIC (in tool development). You'll notice that I indicate my concern that the explanation on implementation can be improved - discussed further below. It is not necessary (I think Andrew and Jordi have properly addressed this aspect) that the proposal be "the only appropriate approach". The threshold is that the approach is not inappropriate. Dear Paul, > Your own framing points to the central issue. > 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. > 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. > I support your request for the exact text and implementation plan. They should also state plainly that the change: is implemented only on the service side; creates no compliance duty or sanction for resource holders; cannot be extended to existing objects without a new review; and will be measured and reconsidered if the expected operational benefit does not appear. > ... The registry should implement what the system technically requires. It should not turn implementation convenience into permanent policy authority. > Regards, Nonhlanhla I don't see any point of disagreement except that, for the reason I've given, there is a benefit in a "big P policy" - a formal inclusion in the CPM. The concerns you appear to be relying upon arise in the existing text in 7.7. I don't see any reason the co-chairs can't give us 3 things: [1] the wording of the policy [2] the implementation plan [3] what the CPM chapter 7 will look like in its entirety. Saying that they should do so is not an expression that they are obligated to - that's an entirely different debate - but rather is a proposition that doing so will align with the intent and objective of this process. Because of the existing CPM paragraph 7 (I think they called sections but I am actually not sure) the text does in fact safeguard. An implementation plan speaks to how a given policy (whether formal or otherwise) is brought into effect. The argument that you can implement directly presupposes that there isn't a reason to put the text into the manual. Therefore in addition to the fact that there is rough consensus at the PPM I think there is an adequate basis to infer that the proposal addresses the concerns raised when properly unpacked. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gugudhlamini343 at gmail.com Tue Jul 21 15:10:55 2026 From: gugudhlamini343 at gmail.com (Gugu Dhlamini) Date: Tue, 21 Jul 2026 17:10:55 +0200 Subject: [rpd] Policy supremacy In-Reply-To: References: Message-ID: Dear Ben, Introductions can be helpful, but they are voluntary. They should not become an informal test of who qualifies as a ?genuine? community member. Affiliation provides context; it does not grant permission to participate. An open process should assess contributions on their substance, not require newcomers to be certified by those already familiar with one another. If disclosure is to become a formal requirement, it must be written clearly and applied equally to every participant, including long-standing members. Until then, familiarity is not mandate. Regards, Gugu On Tue, 21 Jul 2026, 4:22 pm Ben Roberts - AfriNIC wrote: > Gugu, > I have invited the newcomers to introduce themselves. The vast majority > have not done so, and some replied to me with their reasons for refusing to > make a simple introduction. We are an open community and we welcome genuine > community members. Only one, Mandla who joined yesterday, has made the > effort to introduce themselves. And he told us he was a Policy Contributor > at the Number Resource Society. I actually Ok with that, even if I disagree > with the views of NRS, since we understand Mandla?s affiliation. > > I do extend again an invite for the ?newbies? to introduce themselves. > > Kind regards > Ben > > > Sent from my iPhone > > On 21 Jul 2026, at 15:48, Gugu Dhlamini wrote: > > ? > Hi Ben, > > It is not ?well known? that the community consists only of people already > recognised by a familiar circle. That is precisely the gatekeeping problem. > > Email domains, joining dates, professional profiles, or personal > familiarity do not determine whether someone may participate. If there is > evidence of impersonation or automated abuse, submit it to the co-chairs. > Otherwise, address the arguments. > > An open mailing list is a forum for participation, not a private club > whose regulars decide who qualifies as human or community. > > Regards, > Gugu > > On Tue, 21 Jul 2026, 2:52 pm jordi.palet--- via RPD > wrote: > >> I always said that I prefer to write 100 new policy proposals than be in >> the position of a chair, and not just with this discussion and not just in >> AFRINIC :-) >> >> However, I personally think that the arguments in both directions show, >> at the time being, that the objections are not justified as to revert the >> consensus decision. >> >> Regards, >> Jordi >> >> @jordipalet >> >> > El 21 jul 2026, a las 14:35, Rob Evans >> escribi?: >> > >> > Jordi, >> > >> >> Let?s suppose the Last Call fails based on that. The staff implements >> it just operationally, and then the community still prefers to have it as a >> policy. >> > >> > Whilst I am in no position to speak on behalf of RIR staff, I >> > _suspect_ that if the policy fails to get approval now, regardless of >> > the reason behind it, then AfriNIC staff would be very reluctant to >> > implement it operationally, as that could now be perceived as going >> > against the will of the community. >> > >> > I fear that this entire discussion is bringing more heat than light at >> > the moment, and I look forward to the co-chairs decision at the end of >> > the Last Call period (and what happens after that). >> > >> > Cheers, >> > Rob >> >> >> ********************************************** >> IPv4 is over >> Are you ready for the new Internet ? >> http://www.theipv6company.com >> The IPv6 Company >> >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the exclusive use of >> the individual(s) named above and further non-explicilty authorized >> disclosure, copying, distribution or use of the contents of this >> information, even if partially, including attached files, is strictly >> prohibited and will be considered a criminal offense. If you are not the >> intended recipient be aware that any disclosure, copying, distribution or >> use of the contents of this information, even if partially, including >> attached files, is strictly prohibited, will be considered a criminal >> offense, so you must reply to the original sender to inform about this >> communication and delete it. >> >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Tue Jul 21 15:15:02 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Tue, 21 Jul 2026 15:15:02 +0000 Subject: [rpd] Policy supremacy Message-ID: Hi Ben, Introductions can provide context, but they should not become a test of whether someone is a ?genuine? community member. An open process cannot presume that familiar participants belong while newcomers must prove themselves. If affiliation disclosure is important, it should be a clear and equal rule covering everyone, including employers, clients, funding, and organisational interests. Until such a rule exists, contributions should be judged by their substance and conduct, not by whether the established circle recognises the sender. Regards, Tshepo -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Tue Jul 21 15:35:58 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Tue, 21 Jul 2026 17:35:58 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 124 In-Reply-To: References: Message-ID: Simply put: AFRINIC as RIR may not make operational decisions without relevant POLICY controlled by community.? As such, if AFRINIC were to implement contemplated restrictions (by way of operational choice) without relevant policy, they'd be acting outside of their mandate. Kind regards, Jaco On 2026/07/21 13:18, Nia Petronella wrote: > Dear Jordi, > > You are answering whether policy is procedurally permitted. That is > not the question being raised. > > The fact that the bylaws and PDP allow a policy does not prove that > policy is necessary, proportionate, or the best instrument. Likewise, > the absence of a staff statement saying ?policy is not needed? is not > evidence that it is needed. Silence cannot manufacture necessity. > > Kone?s examples remain relevant because they show that the same > technical outcome can be achieved operationally. The unanswered > question is what binding policy adds beyond rigidity and registry > enforcement. > > A procedural route does not justify itself merely because it is > familiar. That is how process becomes mandate: the PDP permits policy, > therefore policy is treated as necessary, and the resulting > enforcement is then called community authority. > > Last Call exists precisely to test unresolved concerns, including the > choice of instrument. Consensus is not protected by declaring that it > was already reached before those concerns were answered. > > I therefore support Kone?s questions and remain opposed to the policy > route. > > Regards, > Nonhlanhla > > > > On Tue, 21 Jul 2026, 1:05 pm wrote: > > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > ? ?1. Re: RPD Digest, Vol 222, Issue 122 (jordi.palet at consulintel.es) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2026 13:03:53 +0200 > From: "jordi.palet at consulintel.es" > To: rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 122 > Message-ID: <3071913E-7C72-49BC-BEDD-B7F26DE20A96 at consulintel.es> > Content-Type: text/plain; charset="utf-8" > > Well ? that?s incorrect. Nobody in the community, neither the > staff impact assessment, said that a policy is not needed and many > folks already contested several times, that doing it by means of a > policy is valid according to the bylaws and PDP and it has not > been demonstrated by objections that following this path, with is > the most regular one in AFRINIC, creates any harm or problem. > > So repeating the argument, by many folks, many times, doesn?t > demonstrate ?per se" that it is a valid objection to revert the > already reached consensus. Of course, this is a decision that need > to be taken by PDP chairs, but this is my view point from an > exclusive ?procedural? basis. > > Regards, > Jordi > > @jordipalet > > > El 21 jul 2026, a las 12:46, Fundiswa Nadia Maseko > escribi?: > > > > Dear Jordi, > > > > Thank you for your clarification. > > > > I understand your point that the proposal has already reached > consensus and that Last Call is intended to identify any > weaknesses that may have been overlooked. > > > > My concern is precisely that if the choice of mechanism was not > sufficiently examined during the earlier discussions, then it > remains a valid point to raise during Last Call. If a proposal > introduces policy where an operational approach could achieve the > same objective, that affects whether policy is the appropriate > solution in the first place. > > > > I appreciate that consensus was declared, but consensus does not > prevent the community from identifying a concern that may not have > received enough attention. Last Call exists to give the community > one final opportunity to do exactly that. > > > > > > Kind regards, > > > > Fundiswa > > > > On Tue, 21 Jul 2026, 12:30 , > wrote: > >> Send RPD mailing list submissions to > >> rpd at afrinic.net > >> > >> To subscribe or unsubscribe via the World Wide Web, visit > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> or, via email, send a message with subject or body 'help' to > >> rpd-request at afrinic.net > >> > >> You can reach the person managing the list at > >> rpd-owner at afrinic.net > >> > >> When replying, please edit your Subject line so it is more specific > >> than "Re: Contents of RPD digest..." > >> > >> > >> Today's Topics: > >> > >>? ? 1. Re: RPD Digest, Vol 222, Issue 119 > (jordi.palet at consulintel.es ) > >> > >> > >> > ---------------------------------------------------------------------- > >> > >> Message: 1 > >> Date: Tue, 21 Jul 2026 12:29:07 +0200 > >> From: "jordi.palet at consulintel.es > " > > >> To: rpd at afrinic.net > >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 119 > >> Message-ID: > > > >> Content-Type: text/plain; charset="utf-8" > >> > >> Hi Fundiswa, > >> > >> Is not a matter of what is practical and what not. > >> > >> It is a matter that, during the discussion of the policy > proposal (which is not the same as the Last Call), the community > reached consensus on making it this way. RIRs follow the same > procedures for reaching consensus as IETF, this has been said > several times. The Last Call is a last opportunity to discover any > weak point in a proposal that already reached consensus, and was > OVERLOOKED before. Is not about discussing if the proposal should > be a proposal or an operational decision. This is no longer the > moment to discuss that (it should have done when the proposal was > being discussed before reaching consensus), and many folks in this > discussing are ignoring that, probably because they are not used > to IETF procedures. > >> > >> Otherwise, you can remain silent during the proposal > discussion, during the presentation in the PPM and object to it > after reached consensus, which is an incorrect procedure. > >> > >> One more example: we could have asked AFRINIC many years ago to > write the Soft Landing as an operational thing, instead we as a > community, decided to make it a policy proposal. Same here. > However, the community decided to do it as a proposal and it was > accepted that way at the right time, not in the Last Call. > >> > >> By the way, I love cooking so from time to time follow some > documentaries about that. Are you the same person as the famous > chef? I think I saw you in a TV program some months ago or I?m > confused. > >> > >> Regards, > >> Jordi > >> > >> @jordipalet > >> > >> > El 21 jul 2026, a las 12:03, Fundiswa Nadia Maseko > > escribi?: > >> > > >> > Dear Jordi, > >> > > >> > Thank you for your response. > >> > > >> > I agree that AFRINIC is not required to follow the same > approach as other RIRs. Every region should make decisions that > suit its own community. > >> > > >> > My point, however, is slightly different. I wasn't suggesting > that AFRINIC should copy another RIR simply because they did it > that way. > >> > > >> > Rather, I'm asking what specific problem is solved by making > this a policy instead of implementing it operationally. If both > approaches achieve the same technical outcome, then what > additional value does the policy itself provide? > >> > > >> > I think that's an important distinction. The fact that the > community can choose policy doesn't necessarily mean policy is the > most appropriate mechanism in every case. > >> > > >> > I'd be interested to hear what practical or technical benefit > you believe is only possible through policy and not through an > operational implementation. > >> > > >> > Kind regards, > >> > > >> > Fundiswa > >> > > >> > > >> > > >> > On Tue, 21 Jul 2026, 11:57 , >> wrote: > >> >> Send RPD mailing list submissions to > >> >> rpd at afrinic.net > > > >> >> > >> >> To subscribe or unsubscribe via the World Wide Web, visit > >> >> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> or, via email, send a message with subject or body 'help' to > >> >> rpd-request at afrinic.net > > > >> >> > >> >> You can reach the person managing the list at > >> >> rpd-owner at afrinic.net > > > >> >> > >> >> When replying, please edit your Subject line so it is more > specific > >> >> than "Re: Contents of RPD digest..." > >> >> > >> >> > >> >> Today's Topics: > >> >> > >> >>? ? 1. Re: RPD Digest, Vol 222, Issue 111 (Nia Petronella) > >> >> > >> >> > >> >> > ---------------------------------------------------------------------- > >> >> > >> >> Message: 1 > >> >> Date: Tue, 21 Jul 2026 11:56:49 +0200 > >> >> From: Nia Petronella > >> > >> >> To: Andrew Alston >> > >> >> Cc: rpd at afrinic.net > > > >> >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 111 > >> >> Message-ID: > >> >>? ? ? ? > ? > >> > >> >> Content-Type: text/plain; charset="utf-8" > >> >> > >> >> Dear Andrew, > >> >> > >> >> I do not accept the binary you have presented. > >> >> > >> >> No one is suggesting that AFRINIC should make operational > changes in secret > >> >> or without community input. An operational change can be > published, > >> >> consulted on, tested, documented, and reviewed. The real > question is > >> >> whether that input must be converted into binding policy > enforced by the > >> >> registry. > >> >> > >> >> Calling AFRINIC ?community-driven? does not answer who the > community is or > >> >> what it is authorised to bind. A self-selecting group of > mailing-list > >> >> participants can provide expertise, support, and objection. > It does not > >> >> automatically represent every member, resource holder, > network, customer, > >> >> or other affected party. > >> >> > >> >> The institutional reality also remains unchanged: > participants discuss the > >> >> policy, but AFRINIC interprets and enforces it. Community > participation > >> >> therefore does not eliminate registry power. It can become > the language > >> >> used to legitimise that power. > >> >> > >> >> This is why Kone?s examples matter. If LACNIC, RIPE NCC, and > ARIN can > >> >> achieve the same technical outcome through operational > mechanisms, then > >> >> policy is not technically inevitable. Proponents should > explain what > >> >> additional technical result binding policy provides, beyond > converting an > >> >> IRR setting into an enforceable obligation. > >> >> > >> >> I also disagree that an objection is valid only if it proves > immediate > >> >> operational harm or implementation failure. The choice of > instrument, > >> >> proportionality, reversibility, and expansion of enforcement > authority are > >> >> legitimate policy concerns. Last Call is not limited to > asking whether > >> >> software will break. It must also ask whether the proposed > power is greater > >> >> than the problem requires. > >> >> > >> >> Rough consensus does not require every objection to be > accommodated. But an > >> >> objection is not ?addressed? merely because supporters > repeat that the > >> >> community prefers policy. That is the very assumption being > challenged. > >> >> Procedure cannot be used to prove its own mandate. > >> >> > >> >> The fact that the RIR system has operated this way for > decades demonstrates > >> >> continuity of practice. It does not establish unlimited > legitimacy of scope. > >> >> > >> >> I support Kone?s questions and remain opposed to > AFPUB-2026-ASN-001-DRAFT02. > >> >> > >> >> Regards, > >> >> Nonhlanhla > >> >> > >> >> > >> >> > >> >> On Tue, 21 Jul 2026, 10:26 am Andrew Alston > > >> wrote: > >> >> > >> >> > The answer to this is simple.? AfriNiC is a community > driven organisation > >> >> > - and anything done with regard to address allocation and > management is > >> >> > done as per policy provided by the community.? It is > through policy that > >> >> > the community tells AfriNIC how to do things in regards to > the allocation > >> >> > and handling of resources. > >> >> > > >> >> > Without policy, the discretion and rules are entirely in > the hands of the > >> >> > registry, and the community voice is removed. > >> >> > > >> >> > This has been the way the RIR system has operated for? > decades and it > >> >> > works.? The community exercises its voice and its right as > to how things > >> >> > are done in relation to resource management through policy. > >> >> > > >> >> > Arguing that just because something can be done another > way, is not in my > >> >> > view a valid argument against policy. Objections to policy > need to be > >> >> > technically grounded and demonstrate that the policy would > either cause > >> >> > harm or alternatively be impractical to implement.? > Anything else is simply > >> >> > arguing that policy should not exist because someone > doesn?t like AfriNIC > >> >> > being told how the community wants things done - and that > isn?t an argument > >> >> > that I believe rises to the level of a block on consensus. > >> >> > > >> >> > Please note - consensus does not require that the issue > you raise have > >> >> > been fixed, it requires that they have been addressed, and > should the > >> >> > community feel that despite the objections, the policy is > something that > >> >> > should proceed based on the fact that the questions have > been addressed if > >> >> > not necessarily accommodated, rough consensus still exists. > >> >> > > >> >> > Again, I support the policy and I see no technical or > evidence/fact-based > >> >> > arguments against said policy. > >> >> > > >> >> > Andrew > >> >> > > >> >> > On Tue, Jul 21, 2026 at 09:34, Nia Petronella < > >> >> > nonhlanhlapetronella85 at gmail.com > > >> wrote: > >> >> > > >> >> >> Dear PDWG, > >> >> >> > >> >> >> Kone is asking the right question. > >> >> >> > >> >> >> The issue is no longer whether hierarchical AS-SET naming > is technically > >> >> >> possible or useful. It already exists. The issue is why > AFRINIC needs a > >> >> >> binding policy to enforce what other RIRs largely treat > as an operational > >> >> >> IRR matter. > >> >> >> > >> >> >> That distinction matters. An operational change adjusts > how a service is > >> >> >> implemented. A policy creates an enforceable obligation > and enlarges the > >> >> >> registry?s authority. If the same technical result can be > achieved through > >> >> >> a community-reviewed implementation plan, then policy is > not the minimum > >> >> >> necessary instrument. > >> >> >> > >> >> >> Saying that ?the community prefers policy? is not enough. > Participation > >> >> >> may guide technical work, but it does not turn every > preference into a > >> >> >> mandate. A mailing list is not a legislature, and the > availability of the > >> >> >> PDP should not make policy the default answer to every > operational setting. > >> >> >> > >> >> >> This is how gatekeeping expands: the registry begins with > a useful > >> >> >> technical function, then policy converts that function > into permission and > >> >> >> enforcement. The recordkeeper gradually becomes the > rule-maker. > >> >> >> > >> >> >> The proponents should therefore answer Kone directly: > what technical > >> >> >> outcome can mandatory policy achieve here that an operational > >> >> >> implementation cannot? > >> >> >> > >> >> >> Until that is clearly demonstrated, I support Kone?s > questions and remain > >> >> >> opposed to the policy route. > >> >> >> > >> >> >> Regards, > >> >> >> Nonhlanhla > >> >> >> > >> >> >> > >> >> >> > >> >> >> On Tue, 21 Jul 2026, 8:20 am >> wrote: > >> >> >> > >> >> >>> Send RPD mailing list submissions to > >> >> >>> rpd at afrinic.net > > > >> >> >>> > >> >> >>> To subscribe or unsubscribe via the World Wide Web, visit > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >>> or, via email, send a message with subject or body 'help' to > >> >> >>> rpd-request at afrinic.net > > > >> >> >>> > >> >> >>> You can reach the person managing the list at > >> >> >>> rpd-owner at afrinic.net > > > >> >> >>> > >> >> >>> When replying, please edit your Subject line so it is > more specific > >> >> >>> than "Re: Contents of RPD digest..." > >> >> >>> > >> >> >>> > >> >> >>> Today's Topics: > >> >> >>> > >> >> >>>? ? 1. Re: RPD Digest, Vol 222, Issue 110 (Tshepo Masuku) > >> >> >>> > >> >> >>> > >> >> >>> > ---------------------------------------------------------------------- > >> >> >>> > >> >> >>> Message: 1 > >> >> >>> Date: Tue, 21 Jul 2026 06:19:05 +0000 > >> >> >>> From: Tshepo Masuku > >> > >> >> >>> To: "rpd at afrinic.net > >" > >> > >> >> >>> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 110 > >> >> >>> Message-ID: > >> >> >>>? ? ? ? ?< > >> >> >>> > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > > > > >> >> >>> > > >> >> >>> > >> >> >>> Content-Type: text/plain; charset="windows-1252" > >> >> >>> > >> >> >>> Dear All, > >> >> >>> > >> >> >>> Kone?s point is directly relevant. If LACNIC, RIPE NCC, > and ARIN can > >> >> >>> implement hierarchical AS-SET naming through operational > mechanisms, then > >> >> >>> proponents must explain why AFRINIC needs a binding > policy to achieve the > >> >> >>> same technical result. > >> >> >>> > >> >> >>> Saying that each RIR works differently does not answer > that question. > >> >> >>> Nor does saying that ?the community is on top of the > RIR.? A community may > >> >> >>> advise, object, and coordinate. It does not acquire > unlimited authority to > >> >> >>> convert every operational preference into policy. A > mailing list is not a > >> >> >>> legislature. > >> >> >>> > >> >> >>> If AFRINIC can solve this through an operational change, > policy adds > >> >> >>> governance where technical administration would be > sufficient. Speed and > >> >> >>> preference do not create mandate. > >> >> >>> > >> >> >>> Kone provided specific examples. Those should be > answered with evidence, > >> >> >>> not by questioning whether he has worked in every RIR > for many years. > >> >> >>> Experience is relevant, but it is not authority and it > is not a substitute > >> >> >>> for argument. > >> >> >>> > >> >> >>> The unanswered question remains: what technical > necessity requires > >> >> >>> policy rather than operational implementation? > >> >> >>> > >> >> >>> Until that is answered, Kone?s objection stands, and I > support it. > >> >> >>> > >> >> >>> Regards, > >> >> >>> Tshepo > >> >> >>> > >> >> >>> > >> >> >>> ________________________________ > >> >> >>> From: rpd-request at afrinic.net > > >> > >> >> >>> Sent: Monday, July 20, 2026 11:10:57 pm > >> >> >>> To: rpd at afrinic.net > > >> > >> >> >>> Subject: RPD Digest, Vol 222, Issue 110 > >> >> >>> > >> >> >>> Send RPD mailing list submissions to > >> >> >>> rpd at afrinic.net > > > >> >> >>> > >> >> >>> To subscribe or unsubscribe via the World Wide Web, visit > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >>> or, via email, send a message with subject or body 'help' to > >> >> >>> rpd-request at afrinic.net > > > >> >> >>> > >> >> >>> You can reach the person managing the list at > >> >> >>> rpd-owner at afrinic.net > > > >> >> >>> > >> >> >>> When replying, please edit your Subject line so it is > more specific > >> >> >>> than "Re: Contents of RPD digest..." > >> >> >>> > >> >> >>> > >> >> >>> Today's Topics: > >> >> >>> > >> >> >>>? ? 1. Re: Writing tools (Ben Roberts - AfriNIC) > >> >> >>>? ? 2. Re: [Last Call] Draft Policy Proposal - > Hierarchical Names > >> >> >>>? ? ? ?for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Kone) > >> >> >>>? ? 3. Re: [Last Call] Draft Policy Proposal - > Hierarchical Names > >> >> >>>? ? ? ?for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >> >> >>>? ? ? ?(jordi.palet at consulintel.es > > >) > >> >> >>> > >> >> >>> > >> >> >>> > ---------------------------------------------------------------------- > >> >> >>> > >> >> >>> Message: 1 > >> >> >>> Date: Mon, 20 Jul 2026 21:26:40 +0200 > >> >> >>> From: Ben Roberts - AfriNIC >> > >> >> >>> To: Nonjabulo Sphilile > >> > >> >> >>> Cc: rpd at afrinic.net > > > >> >> >>> Subject: Re: [rpd] Writing tools > >> >> >>> Message-ID: > <09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net > > >> > >> >> >>> Content-Type: text/plain; charset="us-ascii" > >> >> >>> > >> >> >>> An HTML attachment was scrubbed... > >> >> >>> URL: < > >> >> >>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/33c3ac9e/attachment-0001.html > >> >> >>> > > >> >> >>> > >> >> >>> ------------------------------ > >> >> >>> > >> >> >>> Message: 2 > >> >> >>> Date: Mon, 20 Jul 2026 20:34:20 +0000 > >> >> >>> From: Kone >> > >> >> >>> To: Seun Ojedeji >> > >> >> >>> Cc: rpd > >> > >> >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - > Hierarchical > >> >> >>>? ? ? ? ?Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >> >> >>> Message-ID: > >> >> >>> ? >> >> >>> 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com > > >> > >> >> >>> Content-Type: text/plain; charset="utf-8" > >> >> >>> > >> >> >>> Hello Seun, > >> >> >>> You may have misread my earlier mail. I clearly stated > that LACNIC, RIPE > >> >> >>> NCC, and ARIN do not require policy to enforce > hierarchical AS?SET > >> >> >>> naming. > >> >> >>> > >> >> >>> To help close the ongoing discussions, I believe > addressing the > >> >> >>> questions I > >> >> >>> raised would bring clarity: > >> >> >>> * LACNIC enforces hierarchical AS?SET naming > operationally, as part of > >> >> >>> their IRR design from inception. > >> >> >>> * RIPE NCC handles IRR changes through their Numbered > Work Items (NWI) > >> >> >>> process, not through policy. > >> >> >>> * ARIN uses the ACSP (Consultation and Suggestion > Process) for IRR > >> >> >>> operational matters, again without policy. > >> >> >>> > >> >> >>> > >> >> >>> These examples show that other RIRs (except APNIC) treat > AS?SET naming as > >> >> >>> an operational IRR matter, not a policy obligation. > >> >> >>> > >> >> >>> This is why I asked whether AFRINIC could address this > operationally > >> >> >>> rather > >> >> >>> than through policy, and why Last Call discussions would > benefit from > >> >> >>> clear > >> >> >>> answers to these points. > >> >> >>> > >> >> >>> Thanks. > >> >> >>> --- > >> >> >>> Kone > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji > > >> a > >> >> >>> ?crit : > >> >> >>> > >> >> >>> > Hello Bakenon, > >> >> >>> > > >> >> >>> > Do refer to the proposal as it references URL to other > RIR's policies > >> >> >>> for > >> >> >>> > thiis: > >> >> >>> > > >> >> >>> > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >> >> >>> > > >> >> >>> > Regards > >> >> >>> > > >> >> >>> > ---- > >> >> >>> > Sent from my mobile > >> >> >>> > kindly excuse typos > >> >> >>> > > >> >> >>> > On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, > > >> > >> >> >>> > wrote: > >> >> >>> > > >> >> >>> >> Dear PDWG, > >> >> >>> >> > >> >> >>> >> I have been following the discussions on the > hierarchical AS?SET > >> >> >>> naming > >> >> >>> >> scheme and would like clarification on a few points: > >> >> >>> >> > >> >> >>> >> 1. Could this matter be addressed operationally, as > is done in ARIN, > >> >> >>> >> LACNIC, and RIPE NCC, without requiring policy changes? > >> >> >>> >> > >> >> >>> >> 2. If yes, why are we taking the policy route? Is it > because AFRINIC > >> >> >>> >> currently lacks a defined process for handling > operational issues that > >> >> >>> >> affect IRR services? > >> >> >>> >> > >> >> >>> >> 3. Given that the hierarchical naming scheme is > already supported and > >> >> >>> >> currently exists within the IRR, this proposal > represents an > >> >> >>> enforcement > >> >> >>> >> change rather than the introduction of a new > technical standard. Why > >> >> >>> is a > >> >> >>> >> formal policy required to change an operational > enforcement setting, > >> >> >>> rather > >> >> >>> >> than a community-vetted technical implementation plan?" > >> >> >>> >> > >> >> >>> >> Thank you. > >> >> >>> >> --- > >> >> >>> >> Kone > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> > >> >> >>> >> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal > > >> a > >> >> >>> >> ?crit : > >> >> >>> >> > >> >> >>> >>> Dear PDWG, > >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> The Policy Development Working Group (PDWG) Chairs > have initiated a > >> >> >>> Last > >> >> >>> >>> Call for this proposal, following rough consensus at > the AFRINIC-37 > >> >> >>> Public > >> >> >>> >>> Policy Meeting held in hybrid format in Nairobi, > Kenya on 24 June > >> >> >>> 2026. > >> >> >>> >>> > >> >> >>> >>>? ?*? ?Proposal Name: Hierarchical Names for New AS-SETs > >> >> >>> >>> > >> >> >>> >>>? ?*? ?Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > >> >> >>> >>> > >> >> >>> >>>? ?*? ?Proposal URL: > >> >> >>> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >> >> >>> >>> > >> >> >>> >>> Last Call closes on: July 31, 2026, at 23:59 UTC. > >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> 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. > >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> As always, we kindly request that all participants > adhere to the > >> >> >>> AFRINIC > >> >> >>> >>> Code of Conduct to > maintain a > >> >> >>> respectful > >> >> >>> >>> and professional environment on the mailing list. > >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> Kind regards, > >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> Haitham el Nakhal > >> >> >>> >>> > >> >> >>> >>> AFRINIC PDWG Co-Chair > >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> _______________________________________________ > >> >> >>> >>> RPD mailing list > >> >> >>> >>> RPD at afrinic.net > > > >> >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >>> >>> > >> >> >>> >> _______________________________________________ > >> >> >>> >> RPD mailing list > >> >> >>> >> RPD at afrinic.net > > > >> >> >>> >> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >>> >> > >> >> >>> > > >> >> >>> -------------- next part -------------- > >> >> >>> An HTML attachment was scrubbed... > >> >> >>> URL: < > >> >> >>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/4563e1d5/attachment-0001.html > >> >> >>> > > >> >> >>> > >> >> >>> ------------------------------ > >> >> >>> > >> >> >>> Message: 3 > >> >> >>> Date: Mon, 20 Jul 2026 23:10:04 +0200 > >> >> >>> From: "jordi.palet at consulintel.es > > >" > >> > >> >> >>> To: rpd > >> > >> >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - > Hierarchical > >> >> >>>? ? ? ? ?Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > >> >> >>> Message-ID: > > >> > >> >> >>> Content-Type: text/plain; charset="utf-8" > >> >> >>> > >> >> >>> Hi Kone, > >> >> >>> > >> >> >>> And what is the relevance of that? > >> >> >>> > >> >> >>> If you have a good understanding about all the RIRs, you > will know that > >> >> >>> each RIR has their own ways to do things. In many senses > they act very > >> >> >>> similarly and in general we end up with very similarly > policies, but not > >> >> >>> always. Some RIRs have decided that some aspects are > operational and don?t > >> >> >>> need a policy proposal. > >> >> >>> > >> >> >>> However, despite that, the community is on top of the > RIR, and the > >> >> >>> community sometimes, may decide that they prefer a > policy if the RIR hasn?t > >> >> >>> been proactive in advance in any specific topic, or even > if the RIR was > >> >> >>> proactive, the community may prefer to speed up things, > or to show the way > >> >> >>> the community prefers. > >> >> >>> > >> >> >>> For example, if AFRINIC has any specific operational > aspect already in > >> >> >>> place, and the community prefer to manage that in a > different way, the > >> >> >>> community may opt either for suggesting the RIR to > modify that operational > >> >> >>> aspect or to do actually enforce it by means of a policy > proposal. > >> >> >>> > >> >> >>> I think is important to know, by personal experience, > how the other 4 > >> >> >>> RIRs work before stating something that is not correct, > because if you > >> >> >>> don?t work in all the RIRs for many years, it will be > difficult for you to > >> >> >>> know the past and I?m sure IA will not be able to be > precise as well. > >> >> >>> > >> >> >>> Regards, > >> >> >>> Jordi > >> >> >>> > >> >> >>> @jordipalet > >> >> >>> > >> >> >>> > El 20 jul 2026, a las 22:34, Kone > > >> escribi?: > >> >> >>> > > >> >> >>> > Hello Seun, > >> >> >>> > You may have misread my earlier mail. I clearly stated > that LACNIC, > >> >> >>> RIPE NCC, and ARIN do not require policy to enforce > hierarchical AS?SET > >> >> >>> naming. > >> >> >>> > > >> >> >>> > To help close the ongoing discussions, I believe > addressing the > >> >> >>> questions I raised would bring clarity: > >> >> >>> > * LACNIC enforces hierarchical AS?SET naming > operationally, as part of > >> >> >>> their IRR design from inception. > >> >> >>> > * RIPE NCC handles IRR changes through their Numbered > Work Items (NWI) > >> >> >>> process, not through policy. > >> >> >>> > * ARIN uses the ACSP (Consultation and Suggestion > Process) for IRR > >> >> >>> operational matters, again without policy. > >> >> >>> > > >> >> >>> > > >> >> >>> > These examples show that other RIRs (except APNIC) > treat AS?SET naming > >> >> >>> as an operational IRR matter, not a policy obligation. > >> >> >>> > > >> >> >>> > This is why I asked whether AFRINIC could address this > operationally > >> >> >>> rather than through policy, and why Last Call > discussions would benefit > >> >> >>> from clear answers to these points. > >> >> >>> > > >> >> >>> > Thanks. > >> >> >>> > --- > >> >> >>> > Kone > >> >> >>> > > >> >> >>> > > >> >> >>> > > >> >> >>> > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji > > > > >> >> >>> >>> a ?crit : > >> >> >>> >> Hello Bakenon, > >> >> >>> >> > >> >> >>> >> Do refer to the proposal as it references URL to > other RIR's policies > >> >> >>> for thiis: > >> >> >>> >> > >> >> >>> >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >> >> >>> >> > >> >> >>> >> Regards > >> >> >>> >> > >> >> >>> >> ---- > >> >> >>> >> Sent from my mobile > >> >> >>> >> kindly excuse typos > >> >> >>> >> > >> >> >>> >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, > > > > >> >> >>> >>> wrote: > >> >> >>> >>> Dear PDWG, > >> >> >>> >>> > >> >> >>> >>> I have been following the discussions on the > hierarchical AS?SET > >> >> >>> naming scheme and would like clarification on a few points: > >> >> >>> >>> > >> >> >>> >>> 1. Could this matter be addressed operationally, as > is done in ARIN, > >> >> >>> LACNIC, and RIPE NCC, without requiring policy changes? > >> >> >>> >>> > >> >> >>> >>> 2. If yes, why are we taking the policy route? Is it > because AFRINIC > >> >> >>> currently lacks a defined process for handling > operational issues that > >> >> >>> affect IRR services? > >> >> >>> >>> > >> >> >>> >>> 3. Given that the hierarchical naming scheme is > already supported > >> >> >>> and currently exists within the IRR, this proposal > represents an > >> >> >>> enforcement change rather than the introduction of a new > technical > >> >> >>> standard. Why is a formal policy required to change an > operational > >> >> >>> enforcement setting, rather than a community-vetted > technical > >> >> >>> implementation plan?" > >> >> >>> >>> > >> >> >>> >>> Thank you. > >> >> >>> >>> --- > >> >> >>> >>> Kone > >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal > > > > >> >> >>> > >>> a ?crit : > >> >> >>> >>>> Dear PDWG, > >> >> >>> >>>> > >> >> >>> >>>> > >> >> >>> >>>> The Policy Development Working Group (PDWG) Chairs > have initiated a > >> >> >>> Last Call for this proposal, following rough consensus > at the AFRINIC-37 > >> >> >>> Public Policy Meeting held in hybrid format in Nairobi, > Kenya on 24 June > >> >> >>> 2026. > >> >> >>> >>>> > >> >> >>> >>>>? ?*? ?Proposal Name: Hierarchical Names for New AS-SETs > >> >> >>> >>>> > >> >> >>> >>>>? ?*? ?Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > >> >> >>> >>>> > >> >> >>> >>>>? ?*? ?Proposal URL: > >> >> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >> >> >>> >>>> > >> >> >>> >>>> Last Call closes on: July 31, 2026, at 23:59 UTC. > >> >> >>> >>>> > >> >> >>> >>>> > >> >> >>> >>>> 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. > >> >> >>> >>>> > >> >> >>> >>>> > >> >> >>> >>>> As always, we kindly request that all participants > adhere to the > >> >> >>> AFRINIC Code of Conduct to > maintain a > >> >> >>> respectful and professional environment on the mailing list. > >> >> >>> >>>> > >> >> >>> >>>> > >> >> >>> >>>> Kind regards, > >> >> >>> >>>> > >> >> >>> >>>> > >> >> >>> >>>> Haitham el Nakhal > >> >> >>> >>>> > >> >> >>> >>>> AFRINIC PDWG Co-Chair > >> >> >>> >>>> > >> >> >>> >>>> > >> >> >>> >>>> > >> >> >>> >>>> _______________________________________________ > >> >> >>> >>>> RPD mailing list > >> >> >>> >>>> RPD at afrinic.net > > > > >> > >> >> >>> >>>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >>> >>> _______________________________________________ > >> >> >>> >>> RPD mailing list > >> >> >>> >>> RPD at afrinic.net > > > > >> > >> >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >>> > _______________________________________________ > >> >> >>> > RPD mailing list > >> >> >>> > RPD at afrinic.net > > > >> >> >>> > https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> ********************************************** > >> >> >>> IPv4 is over > >> >> >>> Are you ready for the new Internet ? > >> >> >>> http://www.theipv6company.com > > >> >> >>> The IPv6 Company > >> >> >>> > >> >> >>> This electronic message contains information which may > be privileged or > >> >> >>> confidential. The information is intended to be for the > exclusive use of > >> >> >>> the individual(s) named above and further non-explicilty > authorized > >> >> >>> disclosure, copying, distribution or use of the contents > of this > >> >> >>> information, even if partially, including attached > files, is strictly > >> >> >>> prohibited and will be considered a criminal offense. If > you are not the > >> >> >>> intended recipient be aware that any disclosure, > copying, distribution or > >> >> >>> use of the contents of this information, even if > partially, including > >> >> >>> attached files, is strictly prohibited, will be > considered a criminal > >> >> >>> offense, so you must reply to the original sender to > inform about this > >> >> >>> communication and delete it. > >> >> >>> > >> >> >>> -------------- next part -------------- > >> >> >>> An HTML attachment was scrubbed... > >> >> >>> URL: < > >> >> >>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/b6777fa7/attachment.html > >> >> >>> > > >> >> >>> > >> >> >>> ------------------------------ > >> >> >>> > >> >> >>> Subject: Digest Footer > >> >> >>> > >> >> >>> _______________________________________________ > >> >> >>> RPD mailing list > >> >> >>> RPD at afrinic.net > > > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >>> > >> >> >>> > >> >> >>> ------------------------------ > >> >> >>> > >> >> >>> End of RPD Digest, Vol 222, Issue 110 > >> >> >>> ************************************* > >> >> >>> > >> >> >>> -------------- next part -------------- > >> >> >>> An HTML attachment was scrubbed... > >> >> >>> URL: < > >> >> >>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e492c668/attachment.html > >> >> >>> > > >> >> >>> > >> >> >>> ------------------------------ > >> >> >>> > >> >> >>> Subject: Digest Footer > >> >> >>> > >> >> >>> _______________________________________________ > >> >> >>> RPD mailing list > >> >> >>> RPD at afrinic.net > > > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >>> > >> >> >>> > >> >> >>> ------------------------------ > >> >> >>> > >> >> >>> End of RPD Digest, Vol 222, Issue 111 > >> >> >>> ************************************* > >> >> >>> > >> >> >> _______________________________________________ > >> >> >> RPD mailing list > >> >> >> RPD at afrinic.net > > > >> >> >> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> >> > >> >> > > >> >> -------------- next part -------------- > >> >> An HTML attachment was scrubbed... > >> >> URL: > > >> >> > >> >> ------------------------------ > >> >> > >> >> Subject: Digest Footer > >> >> > >> >> _______________________________________________ > >> >> RPD mailing list > >> >> RPD at afrinic.net > > > >> >> https://lists.afrinic.net/mailman/listinfo/rpd > >> >> > >> >> > >> >> ------------------------------ > >> >> > >> >> End of RPD Digest, Vol 222, Issue 119 > >> >> ************************************* > >> > _______________________________________________ > >> > RPD mailing list > >> > RPD at afrinic.net > >> > https://lists.afrinic.net/mailman/listinfo/rpd > >> > >> > >> > >> ********************************************** > >> IPv4 is over > >> Are you ready for the new Internet ? > >> http://www.theipv6company.com > >> The IPv6 Company > >> > >> This electronic message contains information which may be > privileged or confidential. The information is intended to be for > the exclusive use of the individual(s) named above and further > non-explicilty authorized disclosure, copying, distribution or use > of the contents of this information, even if partially, including > attached files, is strictly prohibited and will be considered a > criminal offense. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents > of this information, even if partially, including attached files, > is strictly prohibited, will be considered a criminal offense, so > you must reply to the original sender to inform about this > communication and delete it. > >> > >> -------------- next part -------------- > >> An HTML attachment was scrubbed... > >> URL: > > >> > >> ------------------------------ > >> > >> Subject: Digest Footer > >> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> > >> > >> ------------------------------ > >> > >> End of RPD Digest, Vol 222, Issue 122 > >> ************************************* > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be > privileged or confidential. The information is intended to be for > the exclusive use of the individual(s) named above and further > non-explicilty authorized disclosure, copying, distribution or use > of the contents of this information, even if partially, including > attached files, is strictly prohibited and will be considered a > criminal offense. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents > of this information, even if partially, including attached files, > is strictly prohibited, will be considered a criminal offense, so > you must reply to the original sender to inform about this > communication and delete it. > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 124 > ************************************* > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Tue Jul 21 15:38:18 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Tue, 21 Jul 2026 17:38:18 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 142 In-Reply-To: References: Message-ID: Dear Taye, Thank you for your thoughtful message. I agree that our focus should remain on the policy itself. Strong community discussions are built by addressing ideas on their merits, not by questioning the people presenting them. Kind regards, Fundiswa Nadia Maseko On Tue, 21 Jul 2026, 16:24 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: Policy supremacy (Nia Petronella) > 2. Re: Policy supremacy (Ben Roberts - AfriNIC) > 3. The question is whether the content is Just Nuisance (Paul Hjul) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2026 16:21:55 +0200 > From: Nia Petronella > To: Taye Medoye > Cc: rpd at afrinic.net > Subject: Re: [rpd] Policy supremacy > Message-ID: > < > CA+mDOg1RvBBc32D6-ToNmrzc1DQ0pybb82sSUH6xPVLSsSudeg at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear colleagues, > > I agree with Taye. The discussion has drifted from the policy into > judgments about who is entitled to participate and how they prepare their > messages. > > A community process should test evidence and arguments, not familiarity, > seniority, email addresses, or writing style. Participation brings > expertise, warning, and objection, but it does not give anyone a mandate to > belittle or exclude others. > > Remarks questioning whether objectors are even human cross a line. Whatever > one?s position on the proposal or AI tools, personal ridicule is not a > technical rebuttal. > > The sensible course is to apply the Code of Conduct consistently, lower the > temperature, and return to the actual policy issues. > > Regards, > Nonhlanhla > > > > On Tue, 21 Jul 2026, 3:42 pm Taye Medoye wrote: > > > Dear All, > > > > Permit me to remark that the first impression one gets perusing the > > torrent of submissions in the last twenty-four hours, is that the focus > of > > the Community may have shifted from making helpful and concrete inputs > > towards a proposed policy development, to a supremacy contest, and most > > likely unhealthy rivalry over language use. If this insinuation is valid, > > then there's a need to retreat and refocus. > > > > While the concerns of Jordi are noted, and worthy of critical > > consideration, the point has to be made that the discussion process for > > reaching a consensus on any policy proposal, as enshrined in the standard > > operating procedure, has to be mutual and convincing to receive > acceptance. > > > > In another context, the remarks from Ben, sent from his iPhone - > objectors > > who all simultaneously and spontaneously joined from Unkown Gmail > accounts > > bombard the lists with AI slop, are recognised as community members, or > > even identifiable human beings for that matter - leave much to be > desired. > > I do not think such remarks should be welcome on this platform, given the > > quality of commenters and participants. > > > > Going by the community's Code of Conduct, and particularly on the > expected > > behaviour of participants, which include - treating others with > politeness > > and showing of respect; avoiding personal attacks or otherwise defamatory > > or discriminatory comments, etc, every commenter/participant is expected > to > > adhere strictly as established to avoid unnecessary rivalry and chaos. > > > > By way of suggestion therefore, l am inclined to suggest that the tone of > > remarks and commentaries be softened, to eschew any form of bitterness, > > while attention should be on the issues at stake for consideration. > > > > I so suggest! > > > > Taye Medoye. > > > > 1. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/26c57efe/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Tue, 21 Jul 2026 16:22:06 +0200 > From: Ben Roberts - AfriNIC > To: Gugu Dhlamini > Cc: rpd at afrinic.net > Subject: Re: [rpd] Policy supremacy > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/c9cc9eb2/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Tue, 21 Jul 2026 16:23:14 +0200 > From: Paul Hjul > To: rpd at afrinic.net > Subject: [rpd] The question is whether the content is Just Nuisance > Message-ID: > 8h5Lg at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Not at all. My exact terming was: > > Participants using AI tools are encouraged to align > > such tools with brevity and technical clarity > > > Nothing in this points to a "cloud of suspicion". On the contrary I am > probably advancing that one really useful dynamic that AI introduces is the > ability to more usefully summarise than humans do. AI tools allow the user > to tune the responses, and brevity and technical clarity are better suited > to this discussion. As somebody who writes "walls of text" I am very > familiar with the adage (and use it often) "this letter would have been > shorter but I didn't have the time". > > What I do place suspicion on is automation aligned contributions where this > is a nuisance. Unless you are a loveable Great Dane avoiding being a > nuisance is usually expected. (that is for a chuckle - > https://en.wikipedia.org/wiki/Just_Nuisance) > > From: *Tshepo Masuku* TshepoMasuku26 at hotmail.com > > 40afrinic.net?Subject=Re%3A%20%5Brpd%5D%20RPD%20Digest%2C%20Vol%20222%2C%20Issue%20138&In-Reply-To=%3CVI2PR04MB1054590413EA27B2962111EB5CAC22%40VI2PR04MB10545.eurprd04.prod.outlook.com%3E > > > > > > Dear Paul, > > Your position may permit AI tools in principle, but it still places > > AI-assisted participants under a separate cloud of suspicion. > > Clarity, brevity, relevance, and reasonable posting volume should apply > > equally to everyone, whether they use AI, translation software, > templates, > > an editor, or no assistance at all. A vague category such as "AI > nuisance" > > gives a small procedural circle too much discretion to decide which > > contributions appear authentic enough to count. > > The participant is the person who reviews, submits, and stands behind the > > message. Unless there is evidence of impersonation or actual automated > > flooding, the drafting method is private and irrelevant to consensus. > > Moderate conduct, not technology. Otherwise, stylistic preference quietly > > becomes a gatekeeping mandate. > > Regards, > > Tshepo > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/5f7a59f4/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 142 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Tue Jul 21 15:45:03 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Tue, 21 Jul 2026 17:45:03 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 146 In-Reply-To: References: Message-ID: Hi Jaco, I do not accept that every operational decision requires a new policy. AFRINIC necessarily makes technical and service-management decisions every day. Policy should define narrow, objective boundaries such as uniqueness, proof of control, registry accuracy, security, and continuity. Staff should implement within those boundaries through a transparent plan, consultation, audit, and review. If AFRINIC cannot adjust an IRR setting without turning it into binding policy, that is a process defect, not proof that policy is necessary. Otherwise, every database configuration can become a permanent expansion of the mandatory layer. The question remains: what technical outcome requires policy here that an accountable operational implementation cannot provide? Regards, Nonhlanhla On Tue, 21 Jul 2026, 5:37 pm wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: Policy supremacy (Tshepo Masuku) > 2. Re: RPD Digest, Vol 222, Issue 124 (Jaco Kroon) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2026 15:15:02 +0000 > From: Tshepo Masuku > To: "rpd at afrinic.net" , "ben.roberts at afrinic.net" > > Subject: Re: [rpd] Policy supremacy > Message-ID: > < > VI2PR04MB105450597B36C498F79CB8243CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > > > > Content-Type: text/plain; charset="windows-1252" > > Hi Ben, > > Introductions can provide context, but they should not become a test of > whether someone is a ?genuine? community member. > > An open process cannot presume that familiar participants belong while > newcomers must prove themselves. If affiliation disclosure is important, it > should be a clear and equal rule covering everyone, including employers, > clients, funding, and organisational interests. > > Until such a rule exists, contributions should be judged by their > substance and conduct, not by whether the established circle recognises the > sender. > > Regards, > Tshepo > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e34847f4/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Tue, 21 Jul 2026 17:35:58 +0200 > From: Jaco Kroon > To: rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 124 > Message-ID: > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Simply put: > > AFRINIC as RIR may not make operational decisions without relevant > POLICY controlled by community.? As such, if AFRINIC were to implement > contemplated restrictions (by way of operational choice) without > relevant policy, they'd be acting outside of their mandate. > > Kind regards, > Jaco > > On 2026/07/21 13:18, Nia Petronella wrote: > > > Dear Jordi, > > > > You are answering whether policy is procedurally permitted. That is > > not the question being raised. > > > > The fact that the bylaws and PDP allow a policy does not prove that > > policy is necessary, proportionate, or the best instrument. Likewise, > > the absence of a staff statement saying ?policy is not needed? is not > > evidence that it is needed. Silence cannot manufacture necessity. > > > > Kone?s examples remain relevant because they show that the same > > technical outcome can be achieved operationally. The unanswered > > question is what binding policy adds beyond rigidity and registry > > enforcement. > > > > A procedural route does not justify itself merely because it is > > familiar. That is how process becomes mandate: the PDP permits policy, > > therefore policy is treated as necessary, and the resulting > > enforcement is then called community authority. > > > > Last Call exists precisely to test unresolved concerns, including the > > choice of instrument. Consensus is not protected by declaring that it > > was already reached before those concerns were answered. > > > > I therefore support Kone?s questions and remain opposed to the policy > > route. > > > > Regards, > > Nonhlanhla > > > > > > > > On Tue, 21 Jul 2026, 1:05 pm wrote: > > > > Send RPD mailing list submissions to > > rpd at afrinic.net > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.afrinic.net/mailman/listinfo/rpd > > or, via email, send a message with subject or body 'help' to > > rpd-request at afrinic.net > > > > You can reach the person managing the list at > > rpd-owner at afrinic.net > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of RPD digest..." > > > > > > Today's Topics: > > > > ? ?1. Re: RPD Digest, Vol 222, Issue 122 (jordi.palet at consulintel.es > ) > > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Tue, 21 Jul 2026 13:03:53 +0200 > > From: "jordi.palet at consulintel.es" > > To: rpd at afrinic.net > > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 122 > > Message-ID: <3071913E-7C72-49BC-BEDD-B7F26DE20A96 at consulintel.es> > > Content-Type: text/plain; charset="utf-8" > > > > Well ? that?s incorrect. Nobody in the community, neither the > > staff impact assessment, said that a policy is not needed and many > > folks already contested several times, that doing it by means of a > > policy is valid according to the bylaws and PDP and it has not > > been demonstrated by objections that following this path, with is > > the most regular one in AFRINIC, creates any harm or problem. > > > > So repeating the argument, by many folks, many times, doesn?t > > demonstrate ?per se" that it is a valid objection to revert the > > already reached consensus. Of course, this is a decision that need > > to be taken by PDP chairs, but this is my view point from an > > exclusive ?procedural? basis. > > > > Regards, > > Jordi > > > > @jordipalet > > > > > El 21 jul 2026, a las 12:46, Fundiswa Nadia Maseko > > escribi?: > > > > > > Dear Jordi, > > > > > > Thank you for your clarification. > > > > > > I understand your point that the proposal has already reached > > consensus and that Last Call is intended to identify any > > weaknesses that may have been overlooked. > > > > > > My concern is precisely that if the choice of mechanism was not > > sufficiently examined during the earlier discussions, then it > > remains a valid point to raise during Last Call. If a proposal > > introduces policy where an operational approach could achieve the > > same objective, that affects whether policy is the appropriate > > solution in the first place. > > > > > > I appreciate that consensus was declared, but consensus does not > > prevent the community from identifying a concern that may not have > > received enough attention. Last Call exists to give the community > > one final opportunity to do exactly that. > > > > > > > > > Kind regards, > > > > > > Fundiswa > > > > > > On Tue, 21 Jul 2026, 12:30 , > > wrote: > > >> Send RPD mailing list submissions to > > >> rpd at afrinic.net > > >> > > >> To subscribe or unsubscribe via the World Wide Web, visit > > >> https://lists.afrinic.net/mailman/listinfo/rpd > > >> or, via email, send a message with subject or body 'help' to > > >> rpd-request at afrinic.net > > >> > > >> You can reach the person managing the list at > > >> rpd-owner at afrinic.net > > >> > > >> When replying, please edit your Subject line so it is more > specific > > >> than "Re: Contents of RPD digest..." > > >> > > >> > > >> Today's Topics: > > >> > > >>? ? 1. Re: RPD Digest, Vol 222, Issue 119 > > (jordi.palet at consulintel.es ) > > >> > > >> > > >> > > > ---------------------------------------------------------------------- > > >> > > >> Message: 1 > > >> Date: Tue, 21 Jul 2026 12:29:07 +0200 > > >> From: "jordi.palet at consulintel.es > > " > > > > >> To: rpd at afrinic.net > > >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 119 > > >> Message-ID: > > > > > > >> Content-Type: text/plain; charset="utf-8" > > >> > > >> Hi Fundiswa, > > >> > > >> Is not a matter of what is practical and what not. > > >> > > >> It is a matter that, during the discussion of the policy > > proposal (which is not the same as the Last Call), the community > > reached consensus on making it this way. RIRs follow the same > > procedures for reaching consensus as IETF, this has been said > > several times. The Last Call is a last opportunity to discover any > > weak point in a proposal that already reached consensus, and was > > OVERLOOKED before. Is not about discussing if the proposal should > > be a proposal or an operational decision. This is no longer the > > moment to discuss that (it should have done when the proposal was > > being discussed before reaching consensus), and many folks in this > > discussing are ignoring that, probably because they are not used > > to IETF procedures. > > >> > > >> Otherwise, you can remain silent during the proposal > > discussion, during the presentation in the PPM and object to it > > after reached consensus, which is an incorrect procedure. > > >> > > >> One more example: we could have asked AFRINIC many years ago to > > write the Soft Landing as an operational thing, instead we as a > > community, decided to make it a policy proposal. Same here. > > However, the community decided to do it as a proposal and it was > > accepted that way at the right time, not in the Last Call. > > >> > > >> By the way, I love cooking so from time to time follow some > > documentaries about that. Are you the same person as the famous > > chef? I think I saw you in a TV program some months ago or I?m > > confused. > > >> > > >> Regards, > > >> Jordi > > >> > > >> @jordipalet > > >> > > >> > El 21 jul 2026, a las 12:03, Fundiswa Nadia Maseko > > > > escribi?: > > >> > > > >> > Dear Jordi, > > >> > > > >> > Thank you for your response. > > >> > > > >> > I agree that AFRINIC is not required to follow the same > > approach as other RIRs. Every region should make decisions that > > suit its own community. > > >> > > > >> > My point, however, is slightly different. I wasn't suggesting > > that AFRINIC should copy another RIR simply because they did it > > that way. > > >> > > > >> > Rather, I'm asking what specific problem is solved by making > > this a policy instead of implementing it operationally. If both > > approaches achieve the same technical outcome, then what > > additional value does the policy itself provide? > > >> > > > >> > I think that's an important distinction. The fact that the > > community can choose policy doesn't necessarily mean policy is the > > most appropriate mechanism in every case. > > >> > > > >> > I'd be interested to hear what practical or technical benefit > > you believe is only possible through policy and not through an > > operational implementation. > > >> > > > >> > Kind regards, > > >> > > > >> > Fundiswa > > >> > > > >> > > > >> > > > >> > On Tue, 21 Jul 2026, 11:57 , > > >> wrote: > > >> >> Send RPD mailing list submissions to > > >> >> rpd at afrinic.net > > > > > >> >> > > >> >> To subscribe or unsubscribe via the World Wide Web, visit > > >> >> https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> or, via email, send a message with subject or body 'help' to > > >> >> rpd-request at afrinic.net > > > > > >> >> > > >> >> You can reach the person managing the list at > > >> >> rpd-owner at afrinic.net > > > > > >> >> > > >> >> When replying, please edit your Subject line so it is more > > specific > > >> >> than "Re: Contents of RPD digest..." > > >> >> > > >> >> > > >> >> Today's Topics: > > >> >> > > >> >>? ? 1. Re: RPD Digest, Vol 222, Issue 111 (Nia Petronella) > > >> >> > > >> >> > > >> >> > > > ---------------------------------------------------------------------- > > >> >> > > >> >> Message: 1 > > >> >> Date: Tue, 21 Jul 2026 11:56:49 +0200 > > >> >> From: Nia Petronella > > > > >> > > >> >> To: Andrew Alston > > >> > > >> >> Cc: rpd at afrinic.net > > > > > >> >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 111 > > >> >> Message-ID: > > >> >>? ? ? ? > > ? > > > > >> > > >> >> Content-Type: text/plain; charset="utf-8" > > >> >> > > >> >> Dear Andrew, > > >> >> > > >> >> I do not accept the binary you have presented. > > >> >> > > >> >> No one is suggesting that AFRINIC should make operational > > changes in secret > > >> >> or without community input. An operational change can be > > published, > > >> >> consulted on, tested, documented, and reviewed. The real > > question is > > >> >> whether that input must be converted into binding policy > > enforced by the > > >> >> registry. > > >> >> > > >> >> Calling AFRINIC ?community-driven? does not answer who the > > community is or > > >> >> what it is authorised to bind. A self-selecting group of > > mailing-list > > >> >> participants can provide expertise, support, and objection. > > It does not > > >> >> automatically represent every member, resource holder, > > network, customer, > > >> >> or other affected party. > > >> >> > > >> >> The institutional reality also remains unchanged: > > participants discuss the > > >> >> policy, but AFRINIC interprets and enforces it. Community > > participation > > >> >> therefore does not eliminate registry power. It can become > > the language > > >> >> used to legitimise that power. > > >> >> > > >> >> This is why Kone?s examples matter. If LACNIC, RIPE NCC, and > > ARIN can > > >> >> achieve the same technical outcome through operational > > mechanisms, then > > >> >> policy is not technically inevitable. Proponents should > > explain what > > >> >> additional technical result binding policy provides, beyond > > converting an > > >> >> IRR setting into an enforceable obligation. > > >> >> > > >> >> I also disagree that an objection is valid only if it proves > > immediate > > >> >> operational harm or implementation failure. The choice of > > instrument, > > >> >> proportionality, reversibility, and expansion of enforcement > > authority are > > >> >> legitimate policy concerns. Last Call is not limited to > > asking whether > > >> >> software will break. It must also ask whether the proposed > > power is greater > > >> >> than the problem requires. > > >> >> > > >> >> Rough consensus does not require every objection to be > > accommodated. But an > > >> >> objection is not ?addressed? merely because supporters > > repeat that the > > >> >> community prefers policy. That is the very assumption being > > challenged. > > >> >> Procedure cannot be used to prove its own mandate. > > >> >> > > >> >> The fact that the RIR system has operated this way for > > decades demonstrates > > >> >> continuity of practice. It does not establish unlimited > > legitimacy of scope. > > >> >> > > >> >> I support Kone?s questions and remain opposed to > > AFPUB-2026-ASN-001-DRAFT02. > > >> >> > > >> >> Regards, > > >> >> Nonhlanhla > > >> >> > > >> >> > > >> >> > > >> >> On Tue, 21 Jul 2026, 10:26 am Andrew Alston > > > > >> > wrote: > > >> >> > > >> >> > The answer to this is simple.? AfriNiC is a community > > driven organisation > > >> >> > - and anything done with regard to address allocation and > > management is > > >> >> > done as per policy provided by the community.? It is > > through policy that > > >> >> > the community tells AfriNIC how to do things in regards to > > the allocation > > >> >> > and handling of resources. > > >> >> > > > >> >> > Without policy, the discretion and rules are entirely in > > the hands of the > > >> >> > registry, and the community voice is removed. > > >> >> > > > >> >> > This has been the way the RIR system has operated for? > > decades and it > > >> >> > works.? The community exercises its voice and its right as > > to how things > > >> >> > are done in relation to resource management through policy. > > >> >> > > > >> >> > Arguing that just because something can be done another > > way, is not in my > > >> >> > view a valid argument against policy. Objections to policy > > need to be > > >> >> > technically grounded and demonstrate that the policy would > > either cause > > >> >> > harm or alternatively be impractical to implement.? > > Anything else is simply > > >> >> > arguing that policy should not exist because someone > > doesn?t like AfriNIC > > >> >> > being told how the community wants things done - and that > > isn?t an argument > > >> >> > that I believe rises to the level of a block on consensus. > > >> >> > > > >> >> > Please note - consensus does not require that the issue > > you raise have > > >> >> > been fixed, it requires that they have been addressed, and > > should the > > >> >> > community feel that despite the objections, the policy is > > something that > > >> >> > should proceed based on the fact that the questions have > > been addressed if > > >> >> > not necessarily accommodated, rough consensus still exists. > > >> >> > > > >> >> > Again, I support the policy and I see no technical or > > evidence/fact-based > > >> >> > arguments against said policy. > > >> >> > > > >> >> > Andrew > > >> >> > > > >> >> > On Tue, Jul 21, 2026 at 09:34, Nia Petronella < > > >> >> > nonhlanhlapetronella85 at gmail.com > > > > > >> wrote: > > >> >> > > > >> >> >> Dear PDWG, > > >> >> >> > > >> >> >> Kone is asking the right question. > > >> >> >> > > >> >> >> The issue is no longer whether hierarchical AS-SET naming > > is technically > > >> >> >> possible or useful. It already exists. The issue is why > > AFRINIC needs a > > >> >> >> binding policy to enforce what other RIRs largely treat > > as an operational > > >> >> >> IRR matter. > > >> >> >> > > >> >> >> That distinction matters. An operational change adjusts > > how a service is > > >> >> >> implemented. A policy creates an enforceable obligation > > and enlarges the > > >> >> >> registry?s authority. If the same technical result can be > > achieved through > > >> >> >> a community-reviewed implementation plan, then policy is > > not the minimum > > >> >> >> necessary instrument. > > >> >> >> > > >> >> >> Saying that ?the community prefers policy? is not enough. > > Participation > > >> >> >> may guide technical work, but it does not turn every > > preference into a > > >> >> >> mandate. A mailing list is not a legislature, and the > > availability of the > > >> >> >> PDP should not make policy the default answer to every > > operational setting. > > >> >> >> > > >> >> >> This is how gatekeeping expands: the registry begins with > > a useful > > >> >> >> technical function, then policy converts that function > > into permission and > > >> >> >> enforcement. The recordkeeper gradually becomes the > > rule-maker. > > >> >> >> > > >> >> >> The proponents should therefore answer Kone directly: > > what technical > > >> >> >> outcome can mandatory policy achieve here that an > operational > > >> >> >> implementation cannot? > > >> >> >> > > >> >> >> Until that is clearly demonstrated, I support Kone?s > > questions and remain > > >> >> >> opposed to the policy route. > > >> >> >> > > >> >> >> Regards, > > >> >> >> Nonhlanhla > > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> On Tue, 21 Jul 2026, 8:20 am > > >> wrote: > > >> >> >> > > >> >> >>> Send RPD mailing list submissions to > > >> >> >>> rpd at afrinic.net > > > > > >> >> >>> > > >> >> >>> To subscribe or unsubscribe via the World Wide Web, visit > > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> >>> or, via email, send a message with subject or body 'help' > to > > >> >> >>> rpd-request at afrinic.net > > > > > >> >> >>> > > >> >> >>> You can reach the person managing the list at > > >> >> >>> rpd-owner at afrinic.net > > > > > >> >> >>> > > >> >> >>> When replying, please edit your Subject line so it is > > more specific > > >> >> >>> than "Re: Contents of RPD digest..." > > >> >> >>> > > >> >> >>> > > >> >> >>> Today's Topics: > > >> >> >>> > > >> >> >>>? ? 1. Re: RPD Digest, Vol 222, Issue 110 (Tshepo Masuku) > > >> >> >>> > > >> >> >>> > > >> >> >>> > > > ---------------------------------------------------------------------- > > >> >> >>> > > >> >> >>> Message: 1 > > >> >> >>> Date: Tue, 21 Jul 2026 06:19:05 +0000 > > >> >> >>> From: Tshepo Masuku > > > > >> > > >> >> >>> To: "rpd at afrinic.net > > >" > > > >> > > >> >> >>> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 110 > > >> >> >>> Message-ID: > > >> >> >>>? ? ? ? ?< > > >> >> >>> > > > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > > > > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > > VI2PR04MB10545A0FC740F5DC6041F6C75CAC22 at VI2PR04MB10545.eurprd04.prod.outlook.com > >> > > >> >> >>> > > > >> >> >>> > > >> >> >>> Content-Type: text/plain; charset="windows-1252" > > >> >> >>> > > >> >> >>> Dear All, > > >> >> >>> > > >> >> >>> Kone?s point is directly relevant. If LACNIC, RIPE NCC, > > and ARIN can > > >> >> >>> implement hierarchical AS-SET naming through operational > > mechanisms, then > > >> >> >>> proponents must explain why AFRINIC needs a binding > > policy to achieve the > > >> >> >>> same technical result. > > >> >> >>> > > >> >> >>> Saying that each RIR works differently does not answer > > that question. > > >> >> >>> Nor does saying that ?the community is on top of the > > RIR.? A community may > > >> >> >>> advise, object, and coordinate. It does not acquire > > unlimited authority to > > >> >> >>> convert every operational preference into policy. A > > mailing list is not a > > >> >> >>> legislature. > > >> >> >>> > > >> >> >>> If AFRINIC can solve this through an operational change, > > policy adds > > >> >> >>> governance where technical administration would be > > sufficient. Speed and > > >> >> >>> preference do not create mandate. > > >> >> >>> > > >> >> >>> Kone provided specific examples. Those should be > > answered with evidence, > > >> >> >>> not by questioning whether he has worked in every RIR > > for many years. > > >> >> >>> Experience is relevant, but it is not authority and it > > is not a substitute > > >> >> >>> for argument. > > >> >> >>> > > >> >> >>> The unanswered question remains: what technical > > necessity requires > > >> >> >>> policy rather than operational implementation? > > >> >> >>> > > >> >> >>> Until that is answered, Kone?s objection stands, and I > > support it. > > >> >> >>> > > >> >> >>> Regards, > > >> >> >>> Tshepo > > >> >> >>> > > >> >> >>> > > >> >> >>> ________________________________ > > >> >> >>> From: rpd-request at afrinic.net > > > > > > >> > > >> >> >>> Sent: Monday, July 20, 2026 11:10:57 pm > > >> >> >>> To: rpd at afrinic.net > > > > > >> > > >> >> >>> Subject: RPD Digest, Vol 222, Issue 110 > > >> >> >>> > > >> >> >>> Send RPD mailing list submissions to > > >> >> >>> rpd at afrinic.net > > > > > >> >> >>> > > >> >> >>> To subscribe or unsubscribe via the World Wide Web, visit > > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> >>> or, via email, send a message with subject or body 'help' > to > > >> >> >>> rpd-request at afrinic.net > > > > > >> >> >>> > > >> >> >>> You can reach the person managing the list at > > >> >> >>> rpd-owner at afrinic.net > > > > > >> >> >>> > > >> >> >>> When replying, please edit your Subject line so it is > > more specific > > >> >> >>> than "Re: Contents of RPD digest..." > > >> >> >>> > > >> >> >>> > > >> >> >>> Today's Topics: > > >> >> >>> > > >> >> >>>? ? 1. Re: Writing tools (Ben Roberts - AfriNIC) > > >> >> >>>? ? 2. Re: [Last Call] Draft Policy Proposal - > > Hierarchical Names > > >> >> >>>? ? ? ?for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Kone) > > >> >> >>>? ? 3. Re: [Last Call] Draft Policy Proposal - > > Hierarchical Names > > >> >> >>>? ? ? ?for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > >> >> >>>? ? ? ?(jordi.palet at consulintel.es > > > > > >) > > >> >> >>> > > >> >> >>> > > >> >> >>> > > > ---------------------------------------------------------------------- > > >> >> >>> > > >> >> >>> Message: 1 > > >> >> >>> Date: Mon, 20 Jul 2026 21:26:40 +0200 > > >> >> >>> From: Ben Roberts - AfriNIC > > >> > > >> >> >>> To: Nonjabulo Sphilile > > > > >> > > >> >> >>> Cc: rpd at afrinic.net > > > > > >> >> >>> Subject: Re: [rpd] Writing tools > > >> >> >>> Message-ID: > > <09EB63D0-2FBC-48F9-B752-43E842D85096 at afrinic.net > > > > > >> > > >> >> >>> Content-Type: text/plain; charset="us-ascii" > > >> >> >>> > > >> >> >>> An HTML attachment was scrubbed... > > >> >> >>> URL: < > > >> >> >>> > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/33c3ac9e/attachment-0001.html > > >> >> >>> > > > >> >> >>> > > >> >> >>> ------------------------------ > > >> >> >>> > > >> >> >>> Message: 2 > > >> >> >>> Date: Mon, 20 Jul 2026 20:34:20 +0000 > > >> >> >>> From: Kone > > >> > > >> >> >>> To: Seun Ojedeji > > >> > > >> >> >>> Cc: rpd > > >> > > >> >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - > > Hierarchical > > >> >> >>>? ? ? ? ?Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > >> >> >>> Message-ID: > > >> >> >>> ? > >> >> >>> 3cyspC-xR5t8iHs0EN4tTMhwQ at mail.gmail.com > > > > > >> > > >> >> >>> Content-Type: text/plain; charset="utf-8" > > >> >> >>> > > >> >> >>> Hello Seun, > > >> >> >>> You may have misread my earlier mail. I clearly stated > > that LACNIC, RIPE > > >> >> >>> NCC, and ARIN do not require policy to enforce > > hierarchical AS?SET > > >> >> >>> naming. > > >> >> >>> > > >> >> >>> To help close the ongoing discussions, I believe > > addressing the > > >> >> >>> questions I > > >> >> >>> raised would bring clarity: > > >> >> >>> * LACNIC enforces hierarchical AS?SET naming > > operationally, as part of > > >> >> >>> their IRR design from inception. > > >> >> >>> * RIPE NCC handles IRR changes through their Numbered > > Work Items (NWI) > > >> >> >>> process, not through policy. > > >> >> >>> * ARIN uses the ACSP (Consultation and Suggestion > > Process) for IRR > > >> >> >>> operational matters, again without policy. > > >> >> >>> > > >> >> >>> > > >> >> >>> These examples show that other RIRs (except APNIC) treat > > AS?SET naming as > > >> >> >>> an operational IRR matter, not a policy obligation. > > >> >> >>> > > >> >> >>> This is why I asked whether AFRINIC could address this > > operationally > > >> >> >>> rather > > >> >> >>> than through policy, and why Last Call discussions would > > benefit from > > >> >> >>> clear > > >> >> >>> answers to these points. > > >> >> >>> > > >> >> >>> Thanks. > > >> >> >>> --- > > >> >> >>> Kone > > >> >> >>> > > >> >> >>> > > >> >> >>> > > >> >> >>> Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji > > > > >> a > > >> >> >>> ?crit : > > >> >> >>> > > >> >> >>> > Hello Bakenon, > > >> >> >>> > > > >> >> >>> > Do refer to the proposal as it references URL to other > > RIR's policies > > >> >> >>> for > > >> >> >>> > thiis: > > >> >> >>> > > > >> >> >>> > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > >> >> >>> > > > >> >> >>> > Regards > > >> >> >>> > > > >> >> >>> > ---- > > >> >> >>> > Sent from my mobile > > >> >> >>> > kindly excuse typos > > >> >> >>> > > > >> >> >>> > On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, > > > > >> > > >> >> >>> > wrote: > > >> >> >>> > > > >> >> >>> >> Dear PDWG, > > >> >> >>> >> > > >> >> >>> >> I have been following the discussions on the > > hierarchical AS?SET > > >> >> >>> naming > > >> >> >>> >> scheme and would like clarification on a few points: > > >> >> >>> >> > > >> >> >>> >> 1. Could this matter be addressed operationally, as > > is done in ARIN, > > >> >> >>> >> LACNIC, and RIPE NCC, without requiring policy changes? > > >> >> >>> >> > > >> >> >>> >> 2. If yes, why are we taking the policy route? Is it > > because AFRINIC > > >> >> >>> >> currently lacks a defined process for handling > > operational issues that > > >> >> >>> >> affect IRR services? > > >> >> >>> >> > > >> >> >>> >> 3. Given that the hierarchical naming scheme is > > already supported and > > >> >> >>> >> currently exists within the IRR, this proposal > > represents an > > >> >> >>> enforcement > > >> >> >>> >> change rather than the introduction of a new > > technical standard. Why > > >> >> >>> is a > > >> >> >>> >> formal policy required to change an operational > > enforcement setting, > > >> >> >>> rather > > >> >> >>> >> than a community-vetted technical implementation plan?" > > >> >> >>> >> > > >> >> >>> >> Thank you. > > >> >> >>> >> --- > > >> >> >>> >> Kone > > >> >> >>> >> > > >> >> >>> >> > > >> >> >>> >> > > >> >> >>> >> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal > > > > >> a > > >> >> >>> >> ?crit : > > >> >> >>> >> > > >> >> >>> >>> Dear PDWG, > > >> >> >>> >>> > > >> >> >>> >>> > > >> >> >>> >>> The Policy Development Working Group (PDWG) Chairs > > have initiated a > > >> >> >>> Last > > >> >> >>> >>> Call for this proposal, following rough consensus at > > the AFRINIC-37 > > >> >> >>> Public > > >> >> >>> >>> Policy Meeting held in hybrid format in Nairobi, > > Kenya on 24 June > > >> >> >>> 2026. > > >> >> >>> >>> > > >> >> >>> >>>? ?*? ?Proposal Name: Hierarchical Names for New AS-SETs > > >> >> >>> >>> > > >> >> >>> >>>? ?*? ?Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > > >> >> >>> >>> > > >> >> >>> >>>? ?*? ?Proposal URL: > > >> >> >>> >>> > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > >> >> >>> >>> > > >> >> >>> >>> Last Call closes on: July 31, 2026, at 23:59 UTC. > > >> >> >>> >>> > > >> >> >>> >>> > > >> >> >>> >>> 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. > > >> >> >>> >>> > > >> >> >>> >>> > > >> >> >>> >>> As always, we kindly request that all participants > > adhere to the > > >> >> >>> AFRINIC > > >> >> >>> >>> Code of Conduct to > > maintain a > > >> >> >>> respectful > > >> >> >>> >>> and professional environment on the mailing list. > > >> >> >>> >>> > > >> >> >>> >>> > > >> >> >>> >>> Kind regards, > > >> >> >>> >>> > > >> >> >>> >>> > > >> >> >>> >>> Haitham el Nakhal > > >> >> >>> >>> > > >> >> >>> >>> AFRINIC PDWG Co-Chair > > >> >> >>> >>> > > >> >> >>> >>> > > >> >> >>> >>> > > >> >> >>> >>> _______________________________________________ > > >> >> >>> >>> RPD mailing list > > >> >> >>> >>> RPD at afrinic.net > > > > > >> >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> >>> >>> > > >> >> >>> >> _______________________________________________ > > >> >> >>> >> RPD mailing list > > >> >> >>> >> RPD at afrinic.net > > > > > >> >> >>> >> https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> >>> >> > > >> >> >>> > > > >> >> >>> -------------- next part -------------- > > >> >> >>> An HTML attachment was scrubbed... > > >> >> >>> URL: < > > >> >> >>> > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/4563e1d5/attachment-0001.html > > >> >> >>> > > > >> >> >>> > > >> >> >>> ------------------------------ > > >> >> >>> > > >> >> >>> Message: 3 > > >> >> >>> Date: Mon, 20 Jul 2026 23:10:04 +0200 > > >> >> >>> From: "jordi.palet at consulintel.es > > > > > >" > > > > >> > > >> >> >>> To: rpd > > >> > > >> >> >>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - > > Hierarchical > > >> >> >>>? ? ? ? ?Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > >> >> >>> Message-ID: > > > > > > >> > > >> >> >>> Content-Type: text/plain; charset="utf-8" > > >> >> >>> > > >> >> >>> Hi Kone, > > >> >> >>> > > >> >> >>> And what is the relevance of that? > > >> >> >>> > > >> >> >>> If you have a good understanding about all the RIRs, you > > will know that > > >> >> >>> each RIR has their own ways to do things. In many senses > > they act very > > >> >> >>> similarly and in general we end up with very similarly > > policies, but not > > >> >> >>> always. Some RIRs have decided that some aspects are > > operational and don?t > > >> >> >>> need a policy proposal. > > >> >> >>> > > >> >> >>> However, despite that, the community is on top of the > > RIR, and the > > >> >> >>> community sometimes, may decide that they prefer a > > policy if the RIR hasn?t > > >> >> >>> been proactive in advance in any specific topic, or even > > if the RIR was > > >> >> >>> proactive, the community may prefer to speed up things, > > or to show the way > > >> >> >>> the community prefers. > > >> >> >>> > > >> >> >>> For example, if AFRINIC has any specific operational > > aspect already in > > >> >> >>> place, and the community prefer to manage that in a > > different way, the > > >> >> >>> community may opt either for suggesting the RIR to > > modify that operational > > >> >> >>> aspect or to do actually enforce it by means of a policy > > proposal. > > >> >> >>> > > >> >> >>> I think is important to know, by personal experience, > > how the other 4 > > >> >> >>> RIRs work before stating something that is not correct, > > because if you > > >> >> >>> don?t work in all the RIRs for many years, it will be > > difficult for you to > > >> >> >>> know the past and I?m sure IA will not be able to be > > precise as well. > > >> >> >>> > > >> >> >>> Regards, > > >> >> >>> Jordi > > >> >> >>> > > >> >> >>> @jordipalet > > >> >> >>> > > >> >> >>> > El 20 jul 2026, a las 22:34, Kone > > > > > >> escribi?: > > >> >> >>> > > > >> >> >>> > Hello Seun, > > >> >> >>> > You may have misread my earlier mail. I clearly stated > > that LACNIC, > > >> >> >>> RIPE NCC, and ARIN do not require policy to enforce > > hierarchical AS?SET > > >> >> >>> naming. > > >> >> >>> > > > >> >> >>> > To help close the ongoing discussions, I believe > > addressing the > > >> >> >>> questions I raised would bring clarity: > > >> >> >>> > * LACNIC enforces hierarchical AS?SET naming > > operationally, as part of > > >> >> >>> their IRR design from inception. > > >> >> >>> > * RIPE NCC handles IRR changes through their Numbered > > Work Items (NWI) > > >> >> >>> process, not through policy. > > >> >> >>> > * ARIN uses the ACSP (Consultation and Suggestion > > Process) for IRR > > >> >> >>> operational matters, again without policy. > > >> >> >>> > > > >> >> >>> > > > >> >> >>> > These examples show that other RIRs (except APNIC) > > treat AS?SET naming > > >> >> >>> as an operational IRR matter, not a policy obligation. > > >> >> >>> > > > >> >> >>> > This is why I asked whether AFRINIC could address this > > operationally > > >> >> >>> rather than through policy, and why Last Call > > discussions would benefit > > >> >> >>> from clear answers to these points. > > >> >> >>> > > > >> >> >>> > Thanks. > > >> >> >>> > --- > > >> >> >>> > Kone > > >> >> >>> > > > >> >> >>> > > > >> >> >>> > > > >> >> >>> > Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji > > > > > > > >> >> >>> > > >>> a ?crit : > > >> >> >>> >> Hello Bakenon, > > >> >> >>> >> > > >> >> >>> >> Do refer to the proposal as it references URL to > > other RIR's policies > > >> >> >>> for thiis: > > >> >> >>> >> > > >> >> >>> >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > >> >> >>> >> > > >> >> >>> >> Regards > > >> >> >>> >> > > >> >> >>> >> ---- > > >> >> >>> >> Sent from my mobile > > >> >> >>> >> kindly excuse typos > > >> >> >>> >> > > >> >> >>> >> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, > > > > > > > >> >> >>> > > >>> wrote: > > >> >> >>> >>> Dear PDWG, > > >> >> >>> >>> > > >> >> >>> >>> I have been following the discussions on the > > hierarchical AS?SET > > >> >> >>> naming scheme and would like clarification on a few points: > > >> >> >>> >>> > > >> >> >>> >>> 1. Could this matter be addressed operationally, as > > is done in ARIN, > > >> >> >>> LACNIC, and RIPE NCC, without requiring policy changes? > > >> >> >>> >>> > > >> >> >>> >>> 2. If yes, why are we taking the policy route? Is it > > because AFRINIC > > >> >> >>> currently lacks a defined process for handling > > operational issues that > > >> >> >>> affect IRR services? > > >> >> >>> >>> > > >> >> >>> >>> 3. Given that the hierarchical naming scheme is > > already supported > > >> >> >>> and currently exists within the IRR, this proposal > > represents an > > >> >> >>> enforcement change rather than the introduction of a new > > technical > > >> >> >>> standard. Why is a formal policy required to change an > > operational > > >> >> >>> enforcement setting, rather than a community-vetted > > technical > > >> >> >>> implementation plan?" > > >> >> >>> >>> > > >> >> >>> >>> Thank you. > > >> >> >>> >>> --- > > >> >> >>> >>> Kone > > >> >> >>> >>> > > >> >> >>> >>> > > >> >> >>> >>> > > >> >> >>> >>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal > > > > > > > >> >> >>> > > >>> a ?crit : > > >> >> >>> >>>> Dear PDWG, > > >> >> >>> >>>> > > >> >> >>> >>>> > > >> >> >>> >>>> The Policy Development Working Group (PDWG) Chairs > > have initiated a > > >> >> >>> Last Call for this proposal, following rough consensus > > at the AFRINIC-37 > > >> >> >>> Public Policy Meeting held in hybrid format in Nairobi, > > Kenya on 24 June > > >> >> >>> 2026. > > >> >> >>> >>>> > > >> >> >>> >>>>? ?*? ?Proposal Name: Hierarchical Names for New > AS-SETs > > >> >> >>> >>>> > > >> >> >>> >>>>? ?*? ?Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > > >> >> >>> >>>> > > >> >> >>> >>>>? ?*? ?Proposal URL: > > >> >> >>> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > >> >> >>> >>>> > > >> >> >>> >>>> Last Call closes on: July 31, 2026, at 23:59 UTC. > > >> >> >>> >>>> > > >> >> >>> >>>> > > >> >> >>> >>>> 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. > > >> >> >>> >>>> > > >> >> >>> >>>> > > >> >> >>> >>>> As always, we kindly request that all participants > > adhere to the > > >> >> >>> AFRINIC Code of Conduct to > > maintain a > > >> >> >>> respectful and professional environment on the mailing > list. > > >> >> >>> >>>> > > >> >> >>> >>>> > > >> >> >>> >>>> Kind regards, > > >> >> >>> >>>> > > >> >> >>> >>>> > > >> >> >>> >>>> Haitham el Nakhal > > >> >> >>> >>>> > > >> >> >>> >>>> AFRINIC PDWG Co-Chair > > >> >> >>> >>>> > > >> >> >>> >>>> > > >> >> >>> >>>> > > >> >> >>> >>>> _______________________________________________ > > >> >> >>> >>>> RPD mailing list > > >> >> >>> >>>> RPD at afrinic.net > > > > > > > >> > > >> >> >>> >>>> https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> >>> >>> _______________________________________________ > > >> >> >>> >>> RPD mailing list > > >> >> >>> >>> RPD at afrinic.net > > > > > > > >> > > >> >> >>> >>> https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> >>> > _______________________________________________ > > >> >> >>> > RPD mailing list > > >> >> >>> > RPD at afrinic.net > > > > > >> >> >>> > https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> >>> > > >> >> >>> > > >> >> >>> > > >> >> >>> ********************************************** > > >> >> >>> IPv4 is over > > >> >> >>> Are you ready for the new Internet ? > > >> >> >>> http://www.theipv6company.com > > > > >> >> >>> The IPv6 Company > > >> >> >>> > > >> >> >>> This electronic message contains information which may > > be privileged or > > >> >> >>> confidential. The information is intended to be for the > > exclusive use of > > >> >> >>> the individual(s) named above and further non-explicilty > > authorized > > >> >> >>> disclosure, copying, distribution or use of the contents > > of this > > >> >> >>> information, even if partially, including attached > > files, is strictly > > >> >> >>> prohibited and will be considered a criminal offense. If > > you are not the > > >> >> >>> intended recipient be aware that any disclosure, > > copying, distribution or > > >> >> >>> use of the contents of this information, even if > > partially, including > > >> >> >>> attached files, is strictly prohibited, will be > > considered a criminal > > >> >> >>> offense, so you must reply to the original sender to > > inform about this > > >> >> >>> communication and delete it. > > >> >> >>> > > >> >> >>> -------------- next part -------------- > > >> >> >>> An HTML attachment was scrubbed... > > >> >> >>> URL: < > > >> >> >>> > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260720/b6777fa7/attachment.html > > >> >> >>> > > > >> >> >>> > > >> >> >>> ------------------------------ > > >> >> >>> > > >> >> >>> Subject: Digest Footer > > >> >> >>> > > >> >> >>> _______________________________________________ > > >> >> >>> RPD mailing list > > >> >> >>> RPD at afrinic.net > > > > > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> >>> > > >> >> >>> > > >> >> >>> ------------------------------ > > >> >> >>> > > >> >> >>> End of RPD Digest, Vol 222, Issue 110 > > >> >> >>> ************************************* > > >> >> >>> > > >> >> >>> -------------- next part -------------- > > >> >> >>> An HTML attachment was scrubbed... > > >> >> >>> URL: < > > >> >> >>> > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e492c668/attachment.html > > >> >> >>> > > > >> >> >>> > > >> >> >>> ------------------------------ > > >> >> >>> > > >> >> >>> Subject: Digest Footer > > >> >> >>> > > >> >> >>> _______________________________________________ > > >> >> >>> RPD mailing list > > >> >> >>> RPD at afrinic.net > > > > > >> >> >>> https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> >>> > > >> >> >>> > > >> >> >>> ------------------------------ > > >> >> >>> > > >> >> >>> End of RPD Digest, Vol 222, Issue 111 > > >> >> >>> ************************************* > > >> >> >>> > > >> >> >> _______________________________________________ > > >> >> >> RPD mailing list > > >> >> >> RPD at afrinic.net > > > > > >> >> >> https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> >> > > >> >> > > > >> >> -------------- next part -------------- > > >> >> An HTML attachment was scrubbed... > > >> >> URL: > > < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/9c41424a/attachment.html > > > > >> >> > > >> >> ------------------------------ > > >> >> > > >> >> Subject: Digest Footer > > >> >> > > >> >> _______________________________________________ > > >> >> RPD mailing list > > >> >> RPD at afrinic.net > > > > > >> >> https://lists.afrinic.net/mailman/listinfo/rpd > > >> >> > > >> >> > > >> >> ------------------------------ > > >> >> > > >> >> End of RPD Digest, Vol 222, Issue 119 > > >> >> ************************************* > > >> > _______________________________________________ > > >> > RPD mailing list > > >> > RPD at afrinic.net > > >> > https://lists.afrinic.net/mailman/listinfo/rpd > > >> > > >> > > >> > > >> ********************************************** > > >> IPv4 is over > > >> Are you ready for the new Internet ? > > >> http://www.theipv6company.com > > >> The IPv6 Company > > >> > > >> This electronic message contains information which may be > > privileged or confidential. The information is intended to be for > > the exclusive use of the individual(s) named above and further > > non-explicilty authorized disclosure, copying, distribution or use > > of the contents of this information, even if partially, including > > attached files, is strictly prohibited and will be considered a > > criminal offense. If you are not the intended recipient be aware > > that any disclosure, copying, distribution or use of the contents > > of this information, even if partially, including attached files, > > is strictly prohibited, will be considered a criminal offense, so > > you must reply to the original sender to inform about this > > communication and delete it. > > >> > > >> -------------- next part -------------- > > >> An HTML attachment was scrubbed... > > >> URL: > > < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/0ba797a1/attachment.html > > > > >> > > >> ------------------------------ > > >> > > >> Subject: Digest Footer > > >> > > >> _______________________________________________ > > >> RPD mailing list > > >> RPD at afrinic.net > > >> https://lists.afrinic.net/mailman/listinfo/rpd > > >> > > >> > > >> ------------------------------ > > >> > > >> End of RPD Digest, Vol 222, Issue 122 > > >> ************************************* > > > _______________________________________________ > > > RPD mailing list > > > RPD at afrinic.net > > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > > > ********************************************** > > IPv4 is over > > Are you ready for the new Internet ? > > http://www.theipv6company.com > > The IPv6 Company > > > > This electronic message contains information which may be > > privileged or confidential. The information is intended to be for > > the exclusive use of the individual(s) named above and further > > non-explicilty authorized disclosure, copying, distribution or use > > of the contents of this information, even if partially, including > > attached files, is strictly prohibited and will be considered a > > criminal offense. If you are not the intended recipient be aware > > that any disclosure, copying, distribution or use of the contents > > of this information, even if partially, including attached files, > > is strictly prohibited, will be considered a criminal offense, so > > you must reply to the original sender to inform about this > > communication and delete it. > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: > > < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/d5daa838/attachment.html > > > > > > ------------------------------ > > > > Subject: Digest Footer > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > ------------------------------ > > > > End of RPD Digest, Vol 222, Issue 124 > > ************************************* > > > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/e42b4523/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 146 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Tue Jul 21 15:47:59 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Tue, 21 Jul 2026 17:47:59 +0200 Subject: [rpd] Policy supremacy In-Reply-To: References: Message-ID: Gugu and Tshepo, Perhaps you can explain to us how you ended up thinking of near identical opening sentences to your emails ? ?Introductions can be helpful, but they are voluntary. They should not become an informal test of who qualifies as a ?genuine? community member.? ? introductions can provide context, but they should not become a test of whether someone is a ?genuine? community member.? By way of introduction, my profile can be found here. https://btw.media/en/governance/rir-watchdog/afrinic/benjamin-mark-roberts Kind Regards Ben Sent from my iPhone > On 21 Jul 2026, at 17:15, Tshepo Masuku wrote: > > ? > Hi Ben, > Introductions can provide context, but they should not become a test of whether someone is a ?genuine? community member. > > An open process cannot presume that familiar participants belong while newcomers must prove themselves. If affiliation disclosure is important, it should be a clear and equal rule covering everyone, including employers, clients, funding, and organisational interests. > > Until such a rule exists, contributions should be judged by their substance and conduct, not by whether the established circle recognises the sender. > > Regards, > Tshepo > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Tue Jul 21 15:51:44 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Tue, 21 Jul 2026 17:51:44 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 124 Message-ID: Dear Jordi, Your argument removes any meaningful limit from the PDP. If ?the community? may convert any operational setting into policy simply because it prefers to, then policy scope is determined by procedural appetite rather than technical necessity. That is precisely the concern. The fact that staff has previously said ?policy not needed? does not nullify the objection. It confirms that operational implementation and policy are different instruments, and that the choice between them must be justified. The PDP?s ability to adopt a policy cannot itself be the reason that policy is appropriate. Otherwise, the process manufactures its own mandate. Nor does ?bottom-up? mean that mailing-list participants have unlimited authority over every operational matter. Participants can provide expertise, evidence, support, and objection. They are stakeholders, not the legal principals of every operator affected by the result. Policy and operational procedure are also not institutionally equivalent. Policy creates a durable compliance rule, establishes precedent, and is harder to revise or reverse. An operational implementation can still be transparent, consulted on, measured, audited, and corrected without enlarging the permanent policy layer. Your hypothetical strengthens the objection. If staff implements the change operationally and the technical objective is achieved, a later policy must still explain what additional problem it solves. ?The community prefers policy? is a preference, not a technical requirement. Finally, the test cannot be limited to whether the proposal harms AFRINIC. AFRINIC is the service operator, not the object the system exists to protect. The relevant question is whether the policy is necessary for uniqueness, registry accuracy, security, interoperability, or operational continuity, and whether it is the least coercive mechanism available. The objection has therefore not been nullified. It remains unanswered. Regards, Nonhlanhla -------------- next part -------------- An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Tue Jul 21 15:55:14 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Tue, 21 Jul 2026 15:55:14 +0000 Subject: [rpd] Policy supremacy In-Reply-To: References: Message-ID: Hi Ben, The similarity is not mysterious. We addressed the same phrase, and drafting assistance can produce similar wording. I reviewed my message, agree with it, and stand behind it. Your profile provides context, but it does not confer a higher status in an open PDP. If affiliation disclosure is to be required, it must be a clear rule applied equally to everyone. I will not engage further in authorship speculation. Regards, Tshepo Get Outlook for Android ________________________________ From: Ben Roberts - AfriNIC Sent: Tuesday, 21 July 2026 17:47:59 To: Tshepo Masuku ; Gugu Dhlamini Cc: rpd at afrinic.net Subject: Re: [rpd] Policy supremacy Gugu and Tshepo, Perhaps you can explain to us how you ended up thinking of near identical opening sentences to your emails ? ?Introductions can be helpful, but they are voluntary. They should not become an informal test of who qualifies as a ?genuine? community member.? ? introductions can provide context, but they should not become a test of whether someone is a ?genuine? community member.? By way of introduction, my profile can be found here. https://btw.media/en/governance/rir-watchdog/afrinic/benjamin-mark-roberts Kind Regards Ben Sent from my iPhone On 21 Jul 2026, at 17:15, Tshepo Masuku wrote: ? Hi Ben, Introductions can provide context, but they should not become a test of whether someone is a ?genuine? community member. An open process cannot presume that familiar participants belong while newcomers must prove themselves. If affiliation disclosure is important, it should be a clear and equal rule covering everyone, including employers, clients, funding, and organisational interests. Until such a rule exists, contributions should be judged by their substance and conduct, not by whether the established circle recognises the sender. Regards, Tshepo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Tue Jul 21 16:02:36 2026 From: ben.roberts at afrinic.net (ben.roberts@frinic.net) Date: Tue, 21 Jul 2026 18:02:36 +0200 Subject: [rpd] Policy supremacy In-Reply-To: References: , Message-ID: <6E94DC6C-B849-5E40-898D-469E298247DE@hxcore.ol> An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Tue Jul 21 16:10:09 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Tue, 21 Jul 2026 16:10:09 +0000 Subject: [rpd] Policy supremacy In-Reply-To: <6E94DC6C-B849-5E40-898D-469E298247DE@hxcore.ol> References: , <6E94DC6C-B849-5E40-898D-469E298247DE@hxcore.ol> Message-ID: Hi Ben, I speak only for myself. I reviewed the message, agree with it, and stand behind it. Similar wording does not prove shared identity or automation. If you have evidence of impersonation, submit it to the co-chairs. Otherwise, please address the policy rather than speculate about participants. I will not continue this side discussion. Regards, Tshepo Get Outlook for Android ________________________________ From: ben.roberts at frinic.net Sent: Tuesday, 21 July 2026 18:02:36 To: Tshepo Masuku ; Gugu Dhlamini Cc: rpd at afrinic.net Subject: Re: [rpd] Policy supremacy So you used the same prompt into the same AI tool and emailed the same reply ? Excuse my skepticism, but are you the same person with different personas ? Or just AI agents running the same script ? I think thats a fair question to ask given the circumstances? Kind Regards, Ben Get Outlook for Mac From: Tshepo Masuku Date: Tuesday, 21 July 2026 at 17:55 To: Ben Roberts - AfriNIC ; Gugu Dhlamini Cc: rpd at afrinic.net Subject: Re: [rpd] Policy supremacy Hi Ben, The similarity is not mysterious. We addressed the same phrase, and drafting assistance can produce similar wording. I reviewed my message, agree with it, and stand behind it. Your profile provides context, but it does not confer a higher status in an open PDP. If affiliation disclosure is to be required, it must be a clear rule applied equally to everyone. I will not engage further in authorship speculation. Regards, Tshepo Get Outlook for Android ________________________________ From: Ben Roberts - AfriNIC Sent: Tuesday, 21 July 2026 17:47:59 To: Tshepo Masuku ; Gugu Dhlamini Cc: rpd at afrinic.net Subject: Re: [rpd] Policy supremacy Gugu and Tshepo, Perhaps you can explain to us how you ended up thinking of near identical opening sentences to your emails ? ?Introductions can be helpful, but they are voluntary. They should not become an informal test of who qualifies as a ?genuine? community member.? ? introductions can provide context, but they should not become a test of whether someone is a ?genuine? community member.? By way of introduction, my profile can be found here. https://btw.media/en/governance/rir-watchdog/afrinic/benjamin-mark-roberts Kind Regards Ben Sent from my iPhone On 21 Jul 2026, at 17:15, Tshepo Masuku wrote: ? Hi Ben, Introductions can provide context, but they should not become a test of whether someone is a ?genuine? community member. An open process cannot presume that familiar participants belong while newcomers must prove themselves. If affiliation disclosure is important, it should be a clear and equal rule covering everyone, including employers, clients, funding, and organisational interests. Until such a rule exists, contributions should be judged by their substance and conduct, not by whether the established circle recognises the sender. Regards, Tshepo -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.medoye at gmail.com Tue Jul 21 16:15:26 2026 From: daniel.medoye at gmail.com (Taye Medoye) Date: Tue, 21 Jul 2026 18:15:26 +0200 Subject: [rpd] AS-SETs ... Actual Stupidity and Artificial Intelligence Message-ID: Dear All, I agree with Nonhlanhla that a technical specification does not automatically require an institutional mandate. Her view that policy creates permanence, interpretation risk, and precedent beyond the immediate database change is noted, and supported as highlighted herein. In her opinion, which l agree with, is that ?It affects AFRINIC, not resource holders? is therefore not a complete safeguard, because AFRINIC remains the institution interpreting and enforcing the resulting rule. Until this standard is reviewed, and or reversed, it stands. 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. On this point, l am inclined to agree with Paul on the need to use AI tools in - order to improve the clarity of expression and to assist with language in their contribution. I also support the view that participants using AI tools are encouraged to align such tools with brevity and technical clarity. In closing, l support the position of Nonhlanhla that the registry should implement what the system technically requires. It should not turn implementation convenience into permanent policy authority. Taye Medoye. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Tue Jul 21 16:18:29 2026 From: ben.roberts at afrinic.net (ben.roberts@frinic.net) Date: Tue, 21 Jul 2026 18:18:29 +0200 Subject: [rpd] Policy supremacy In-Reply-To: References: , <6E94DC6C-B849-5E40-898D-469E298247DE@hxcore.ol>, Message-ID: An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Tue Jul 21 16:31:31 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Tue, 21 Jul 2026 18:31:31 +0200 Subject: [rpd] Policy supremacy Message-ID: Dear Ben, We have spent days debating the wrong question. A writing tool is not a participant. The participant is the person who chooses the position, reviews the text, submits it, and accepts responsibility for it. Spell-check, translation, templates, editors, and AI do not acquire agency merely because they help produce complete sentences. You are entitled to challenge an argument. You are not entitled to turn another person?s private drafting process into an identity test or a condition for participation. That converts familiarity into authority and an open mailing list into a permission system. If there is evidence of impersonation, automated flooding, or misconduct, submit it to the co-chairs. If several messages raise the same concern, the co-chairs may consolidate the concern. Neither situation justifies interrogating unfamiliar participants or treating polished language as proof of deception. Consensus should be assessed through distinct arguments and evidence, not through amateur authorship investigations. A community may discuss and advise. It does not acquire a mandate to decide who counts as a genuine human contributor. My tools are my private choice. My responsibility for what I submit is public. I will not seek permission for either. Regards, Nonhlanhla -------------- next part -------------- An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Tue Jul 21 16:35:52 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Tue, 21 Jul 2026 16:35:52 +0000 Subject: [rpd] Policy supremacy In-Reply-To: References: , <6E94DC6C-B849-5E40-898D-469E298247DE@hxcore.ol>, Message-ID: Hi Ben, Yes, both addresses are mine. I moved from the Gmail account to Outlook and should have made that clear. A change of email address does not create a second participant or a second position. Please treat both addresses as one contributor; I will use the Outlook address going forward. An email address is a contact point, not a test of legitimacy. My contributions should be assessed on their substance. Regards, Tshepo Get Outlook for Android ________________________________ From: ben.roberts at frinic.net Sent: Tuesday, 21 July 2026 18:18:29 To: Tshepo Masuku Cc: rpd at afrinic.net Subject: Re: [rpd] Policy supremacy Tshepo, Ok I will take Gugu out of this line of conversation. I see you are Tshepo Masuku Are you related to the other Tshepo Masuku who has also been frequently posting on this list? Kind Regards Ben Get Outlook for Mac From: Tshepo Masuku Date: Tuesday, 21 July 2026 at 18:10 To: ben.roberts at frinic.net ; Gugu Dhlamini Cc: rpd at afrinic.net Subject: Re: [rpd] Policy supremacy Hi Ben, I speak only for myself. I reviewed the message, agree with it, and stand behind it. Similar wording does not prove shared identity or automation. If you have evidence of impersonation, submit it to the co-chairs. Otherwise, please address the policy rather than speculate about participants. I will not continue this side discussion. Regards, Tshepo Get Outlook for Android ________________________________ From: ben.roberts at frinic.net Sent: Tuesday, 21 July 2026 18:02:36 To: Tshepo Masuku ; Gugu Dhlamini Cc: rpd at afrinic.net Subject: Re: [rpd] Policy supremacy So you used the same prompt into the same AI tool and emailed the same reply ? Excuse my skepticism, but are you the same person with different personas ? Or just AI agents running the same script ? I think thats a fair question to ask given the circumstances? Kind Regards, Ben Get Outlook for Mac From: Tshepo Masuku Date: Tuesday, 21 July 2026 at 17:55 To: Ben Roberts - AfriNIC ; Gugu Dhlamini Cc: rpd at afrinic.net Subject: Re: [rpd] Policy supremacy Hi Ben, The similarity is not mysterious. We addressed the same phrase, and drafting assistance can produce similar wording. I reviewed my message, agree with it, and stand behind it. Your profile provides context, but it does not confer a higher status in an open PDP. If affiliation disclosure is to be required, it must be a clear rule applied equally to everyone. I will not engage further in authorship speculation. Regards, Tshepo Get Outlook for Android ________________________________ From: Ben Roberts - AfriNIC Sent: Tuesday, 21 July 2026 17:47:59 To: Tshepo Masuku ; Gugu Dhlamini Cc: rpd at afrinic.net Subject: Re: [rpd] Policy supremacy Gugu and Tshepo, Perhaps you can explain to us how you ended up thinking of near identical opening sentences to your emails ? ?Introductions can be helpful, but they are voluntary. They should not become an informal test of who qualifies as a ?genuine? community member.? ? introductions can provide context, but they should not become a test of whether someone is a ?genuine? community member.? By way of introduction, my profile can be found here. https://btw.media/en/governance/rir-watchdog/afrinic/benjamin-mark-roberts Kind Regards Ben Sent from my iPhone On 21 Jul 2026, at 17:15, Tshepo Masuku wrote: ? Hi Ben, Introductions can provide context, but they should not become a test of whether someone is a ?genuine? community member. An open process cannot presume that familiar participants belong while newcomers must prove themselves. If affiliation disclosure is important, it should be a clear and equal rule covering everyone, including employers, clients, funding, and organisational interests. Until such a rule exists, contributions should be judged by their substance and conduct, not by whether the established circle recognises the sender. Regards, Tshepo -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah at neo.co.tz Tue Jul 21 16:38:31 2026 From: noah at neo.co.tz (Noah) Date: Tue, 21 Jul 2026 19:38:31 +0300 Subject: [rpd] On Bottom up vs Top down - ref: policies development Message-ID: Hi Jaco, On Tue, 21 Jul 2026, 6:44?pm Jaco Kroon via RPD, wrote: > Simply put: > > AFRINIC as RIR may not make operational decisions without relevant POLICY > controlled by community. > Some operational decisions do not require policy because they fall within the mandate of AFRINIC internal operations, such as paying for software licenses or infrastructure upgrades. For policies related to INR, the bottom-up process has always been employed, consistent with the spirit of internet governance principles enshrined in our bylaws, to produce policies that support the registry's governance and operations. However, > As such, if AFRINIC were to implement contemplated restrictions (by way of > operational choice) without relevant policy, they'd be acting outside of > their mandate. > In 2020, we voted for some amendments to the Bylaws and resource members empowered the AFRINIC board/directors with certain powers. They can exercise these powers regarding policy adoption by invoking Articles 11.4 and 11.5 of the Bylaws at the next PPM... That being said, top down policy adoption is already in place, as long as we rubber-stamp the said policy.... Ahsante.. Noah -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Tue Jul 21 16:49:30 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Tue, 21 Jul 2026 18:49:30 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 150 In-Reply-To: References: Message-ID: Dear Taye, Thank you for your thoughtful and mature intervention. I appreciate that you addressed the substance without turning the discussion into a contest over personalities, familiarity, or writing tools. I agree that participation should remain open and inclusive, with each contributor responsible for what they submit. Moderation should address actual abuse or flooding, not the use of AI, translation, or drafting assistance. I also appreciate your support for keeping the distinction between technical implementation and permanent policy authority. Community participation can guide and test an operational change, but it should not automatically convert every implementation choice into an institutional mandate. This is the respectful and constructive discussion the PDWG needs. Regards, Nonhlanhla On Tue, 21 Jul 2026, 6:19 pm wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: AS-SETs ... Actual Stupidity and Artificial Intelligence > (Taye Medoye) > 2. Re: Policy supremacy (ben.roberts at frinic.net) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 21 Jul 2026 18:15:26 +0200 > From: Taye Medoye > To: rpd at afrinic.net > Subject: Re: [rpd] AS-SETs ... Actual Stupidity and Artificial > Intelligence > Message-ID: > < > CACXLxYcXNzLKL8CzWjC2nkiBALwPsYe08A4vGWoCckORisfqpA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear All, > > I agree with Nonhlanhla that a technical specification does not > automatically require an institutional mandate. Her view that policy > creates permanence, interpretation risk, and precedent beyond the immediate > database change is noted, and supported as highlighted herein. In her > opinion, which l agree with, is that ?It affects AFRINIC, not resource > holders? is therefore not a complete safeguard, because AFRINIC remains the > institution interpreting and enforcing the resulting rule. Until this > standard is reviewed, and or reversed, it stands. > > 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. > > On this point, l am inclined to agree with Paul on the need to use AI > tools in > - order to improve the clarity of expression and to assist with > language in their > contribution. I also support the view that participants using AI tools are > encouraged to align such tools with brevity and technical clarity. > > In closing, l support the position of Nonhlanhla that the registry should > implement what the system technically requires. It should not turn > implementation convenience into permanent policy authority. > > > Taye Medoye. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/7f9da57c/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Tue, 21 Jul 2026 18:18:29 +0200 > From: "ben.roberts at frinic.net" > To: Tshepo Masuku > Cc: "rpd at afrinic.net" > Subject: Re: [rpd] Policy supremacy > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260721/8737fe94/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 150 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nndemo at staff.zegu.ac.zw Tue Jul 21 17:16:57 2026 From: nndemo at staff.zegu.ac.zw (Nyasha Ndemo) Date: Tue, 21 Jul 2026 19:16:57 +0200 Subject: [rpd] (no subject) Message-ID: Please Unsubscribe my email thank you. Regards Dr. Nyasha Ndemo-Masimbarasi (DPhil, MSc., BSc. Hon. Development Science and Policy) Chairperson - Department of Development Programming and Management Zimbabwe Ezekiel Guti University 1901 Barrassie Rd, Off Shamva Rd, Bindura Zimbabwe Landline: +263867 700 6136 Cell: +263 773226552 Email: nyashandemo at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah at neo.co.tz Tue Jul 21 18:33:45 2026 From: noah at neo.co.tz (Noah) Date: Tue, 21 Jul 2026 21:33:45 +0300 Subject: [rpd] (no subject) In-Reply-To: References: Message-ID: But how did you subscribe to the list dear Dr.? Cheers, *.**/noah* On Tue, 21 Jul 2026, 9:27?pm Nyasha Ndemo, wrote: > Please Unsubscribe my email thank you. > > Regards > > Dr. Nyasha Ndemo-Masimbarasi > (DPhil, MSc., BSc. Hon. Development Science and Policy) > Chairperson - Department of Development Programming and Management > Zimbabwe Ezekiel Guti University > 1901 Barrassie Rd, Off Shamva Rd, Bindura > Zimbabwe > Landline: +263867 700 6136 > Cell: +263 773226552 > Email: nyashandemo at gmail.com > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonhlanhlapetronella85 at gmail.com Tue Jul 21 20:17:04 2026 From: nonhlanhlapetronella85 at gmail.com (Nia Petronella) Date: Tue, 21 Jul 2026 22:17:04 +0200 Subject: [rpd] Malicious Activities on emails Message-ID: FYI- I'm just testing if I'm still subscribed to the mailing list as suspicious activities were attempted on my email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Tue Jul 21 20:53:50 2026 From: hvisage at hevis.co.za (hvisage at hevis.co.za) Date: Tue, 21 Jul 2026 22:53:50 +0200 Subject: [rpd] Malicious Activities on emails In-Reply-To: References: Message-ID: Could you please, on archive/email, confirm that your email had been abused and you were impersonated? And no, you weren't removed yet ! On 21 Jul 2026, at 22:17, Nia Petronella wrote: > FYI- I'm just testing if I'm still subscribed to the mailing list as > suspicious activities were attempted on my email. > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Wed Jul 22 09:29:24 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Wed, 22 Jul 2026 11:29:24 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 In-Reply-To: <51f0a40c-f6f3-4d84-9c5b-ea883fb2b28f@uls.co.za> References: <1783459420709.11832@tra.gov.eg> <95592897-0d54-4f5f-b5f8-cd918dd51c24@posix.co.za> <51f0a40c-f6f3-4d84-9c5b-ea883fb2b28f@uls.co.za> Message-ID: <74208ec3-0053-4c39-a87e-70d58054fd5e@uls.co.za> Hi Jordi, Mark, After in-person discussion with Mark, I'd like to propose alternative wording for specifically this portion: "TheIPv6deploymentplanmust showtheactualIPv4top-25traffic destinationsofthatnetwork.For eachofthoseexternaldestinations thatareIPv6-enabled,thefollowing minimumIPv6%willbeconsidered ascompliant: "25% inamaximumof12months. 50% inamaximumof24months. 75% inamaximumof48months. "Incaseofnetworkshostingany kindofservices,applicationsor contents,willbeconsideredas compliantwhenmatchingthe following%ofAAAARRsavailable andIPv6reachablefromInternet: "25% inamaximumof12months. 75% inamaximumof24months. 95% inamaximumof48months. "FailuretocomplywiththeIPv6 deploymentplanaccordingtothe relevantcriteria,constitutesapolicy violation." As can be seen the author(s) already distinguish between access (eyeball) and hosting (content) networks.? It does not make it clear in the case of hybrid networks here.? For most larger networks this won't particularly matter since they are unlikely to be able to apply for additional /22s and even if they are /22s (as per in-person discussions with at least one network operator that makes me look like an extremely mild-mannered person) are not useful to them. Regardless, I feel that for access networks the measurement above is not well defined, nor sensible, as per discussion with Mark the measurement depends not only on your own behaviour but also that of external networks (be they customers or external content networks).? Not discussed and which I only realised later on Monday after our discussion is that "actual IPv4 top-25 destinations" would *shift* as traffic moves to IPv6, which is to say that if *all* of my customers suddenly and unsuspectedly re-enable IPv6, then the likes of Google, Youtube, Cloudflare, Akamai, Meta and (AWS) won't be in our top-25 IPv4 destinations. Now my top-25 would start shifting to the likes of the banks, NTT, Xneelo, Hostafrica, Hetzner and probably other content hosting providers that are NOT IPv6 enabled (or not advertising that they are).? Yes, I've been told that Xneelo does support IPv6 but I've yet to see a single site myself hosted on Xneelo side that has AAAA records deployed.? As such, since this is a shifting target it cannot be a reliable measure. The measurements I would suggest: For access networks:? The percentage of downstream networks/customers that has access to well-connected IPv6 should they so choose (well-connected in this sense means that the provided addresses are routable and reachable in the Internet's "DFZ"/Global routing table.? To be clear:? This doesn't mean they have to have it enabled downstream, just that it's available to the customer/network. This is something that can be easily shown/proven by any network. It would also (based on existing knowledge) force exactly those parties that are NOT currently deploying IPv6 to deploy.? Yes, this includes some of our own downstream IPT and/or consulting customers who would score 0% on either measure.? This would also allow us to raise the bar to a higher percentage such as the 95% as for content networks. This must not be a "made available on request" situation - and a customer should be in a position to obtain IPv6 via the usual configuration mechanisms, and RAs should be advertised standard to these downstream customers, and provide for managed DHCPv6 PD, including at least a set of DNS servers. My issue with hosting networks is that the network provider doesn't, in many (most) cases, also control DNS.? And in a significant portion of cases the third-party IT providers just flatly refuse to deploy AAAA records.? This ends up punishing a network operator for the behaviour of external parties. I thus suggest the following: "When applying for additional IPv4 space, the following conditions must be met as per the time frames from issuance of the first IPv6 space to LIRs and EUs, or {policy approval date}, whichever is later: In the case of access networks, the percentage of customers that has access to global IPv6 delegations without interference required from the Network Operator must be at or above the following thresholds: * 25 % within 12 months; * 50 % within 24 months; * 75 % within 36 months; * 95 % within 48 months; For the avoidance of doubt: "without interference required from the Network Operator" means that routers directly upstream from access clients must permit IPv6CP in the case of PPP connections, and all upstream routers must actively transmit IPv6 Router-Advertisements, and in order to allow for such downstream customers to obtain Prefix Delegations, most likely by way of DHCPv6 PD, and the space must be reachable from the global routing table. In the case of content hosting network, the percentage of assigned IPv4 space assigned to those networks also covered by IPv6 assignments must reach: * 25 % within 12 months; * 50 % within 24 months; * 75 % within 36 months; * 95 % within 48 months; For avoidance of doubt:? Assigned IPv6 space must be reachable from the global routing table. In the case where a network provides both access and content hosting services, both criteria must be independently complied with." This would address my concerns, and I believe still force those networks looking to obtain additional space that have not yet deployed IPv6 to do so. I think linking this to traffic thresholds is a very bad idea. Especially if it's linked to specific top 25-IPv4 external sites. I suspect at least a few of those top external sites in our case would be banking sites - and NONE of the major banks in SA has any client-facing IPv6 deployed that I'm aware of - making it impossible for us to comply even if 100% of our customers has access to and are IPv6 enabled.? I did have a discussion about this and DNSSEC with at least one such case yesterday, but I promise you nothing will come from that. One concern I still have is that the above implies every single piece of assigned address space can 100% clearly be categorised into access or hosting, which isn't always as clearly defined as one would like it to be, but I'd wager that in those cases one or the other will be the predominant purpose, and we can just use that purpose for those cases.? This is something I'd leave to operational discretion to qualify at application/assessment time to be honest.? As long as each piece of assigned space (ie, the minimum 90% usage) from the LIR/EU is classified into one of these categories. I hope this helps, and thanks for the chat Mark. Kind regards, Jaco On 2026/07/20 10:30, Jaco Kroon via RPD wrote: > Hi, > > I'm going to state this again - I support the principle but not the > implementation. > > Specifically the way in which this links IPv4 requests to IPv6 > *traffic levels* as a percentage, rather than percentage of network to > which IPv6 has been deployed. > > I'm unable to sensibly force my customers to consume IPv6, no matter > what.? Further - we host a bunch of content which due to lack of > external IPv6 deployment (specifically on MNO networks) brings down > our overall level of network IPv6 thresholds.? This in spite of but > one single /29 subnet (which communicates exclusively with MNO > networks, this might change in the next month, thus deploying IPv6 > here until now made no sense, and this little subnet single-handedly > carries around 5% of our ingress and ~30% of our egress bandwidth). > > As written this policy punishes network operators for bad behaviour of > others, be it other access networks, or customers. > > It also adds significant additional costs towards otherwise needless > network monitoring that would otherwise not be required. > > Again, to be clear:? I'm in full support of the principle of linking > IPv4 allocations/assignments to IPv6 deployment, I simply disagree > with how it should be measured. > > Traffic levels are not a good measure.? If 50% of my network is > capable of IPv6, and 50% of content being accessed, or 50% of of > eyeballs accessing my network are IPv6 capable, that puts my general > IPv6 network levels around 25%, depending on exact patterns, possibly > a bit higher, but no higher than 50%.? Now our ability to access IPv4 > resources is being limited by *others's* IPv6 deployment rather than > merely our own. > > This should be measured as: > > What percentage of existing deployed IPv4 resources on the network > also has IPv6 deployed in the case of content provisioning, and has > access to IPv6 for downstream networks. > > For us the former percentage, having somewhere between a /22 and /23 > provisioned for *services*, so let's work on a /23 or about 512 IPs > with only a /29 not being IPv6 enabled as of right now is 98.5%, > however, traffic patterns on access shows less than 5% of actual > traffic is IPv6. > > For the latter, 100% of downstream customers/networks has *access* to > IPv6.? On customers using ppp less than 5% are consuming IPv6.? At > least a portion of these configures IPv6 LL (just over 30%).? Once > that happens we do actively send RAs to provoke configuration. > > For AE customers (Or "DHCP Customers") things looked better, as of > right now we've got? 43% active IPv6 customers (which shows that > consumer routers are more inclined to grab IPv6 on "DHCP uplinks > compared to PPP", however, this percentage used to be closer to 96%, > as customers are *actively against recommendation insisting on > switching OFF IPv6*. > > Whilst we are pushing we cannot prescribe to customers to keep IPv6 > enabled - they'll simply move their business elsewhere if we push, > thus this policy - as written - creates a significant operational issue. > > Kind regards, > Jaco > > On 2026/07/19 11:26, Mark Elkins via RPD wrote: > >> Dear PDWG, >> >> I have two major concerns regarding the Internet in Africa. >> >> 1 - Lack of DNSSEC - for DNS security >> >> 2 - Lack of IPv6 - for growth >> >> I run something called the Observatory - >> https://observatory.dnsstudy.africa - which has in the past collected >> information such as how many domains there are, are they DNSSEC >> Signed and are they IPv6 accessible. >> >> So I want Domain content to be IPv6 Accessible... >> >> ISP's need to have IPv6 resources, they need to make sure that all >> content has IPv6 - so that as end users access that content, they >> have IPv6 access all the way through. IPv6 doesn't use RFC1918 >> addresses - all IPv6 addresses are unique. >> >> We are running out of IPv4. Yes - some resources will still need IPv4 >> addresses - so let's stretch what we have out. The IPv4 Soft Landing >> proposal helps this stretching process - by forcing IPv6 onto LIR's/ >> ISP's. >> >> So I support the Proposal. It may not be perfect but it will help >> shape the African Internet Industry further into the right direction. >> >> -- >> >> Mark James ELKINS? -? Posix Systems - (South) Africa >> mje at posix.co.za Tel: +27.826010496 >> For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Wed Jul 22 10:06:28 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Wed, 22 Jul 2026 12:06:28 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 In-Reply-To: <74208ec3-0053-4c39-a87e-70d58054fd5e@uls.co.za> References: <74208ec3-0053-4c39-a87e-70d58054fd5e@uls.co.za> Message-ID: <97C503F6-EE5F-4743-BBBC-C2FEDDD55D35@afrinic.net> An HTML attachment was scrubbed... URL: From emmanuelmabasa1 at yahoo.com Wed Jul 22 10:15:15 2026 From: emmanuelmabasa1 at yahoo.com (Mzwakhe Mabasa) Date: Wed, 22 Jul 2026 10:15:15 +0000 (UTC) Subject: [rpd] The usage of AI in platforms References: <382163234.1741936.1784715315720.ref@mail.yahoo.com> Message-ID: <382163234.1741936.1784715315720@mail.yahoo.com> Good day.I would like to post to the RPD mailing list. Kindly allow me this opportunity of being part of the RPD afrinic policy decisions.? While AI is widely used across the internet, its acceptability depends on the specific platform you are referring to . Most social networks allow AI assistance, but require the clear labeling of AI-generated imagery and ban non-consensual deepfakes or harmful content.?LSince platform policies vary greatly, here is a breakdown of how the most popular services handle AI usage: - Social Media (Facebook, Instagram, TikTok, YouTube): Generally allowed, but social media algorithms penalize low-quality, generic content. Major platforms are shifting to automatic detection and require synthetic imagery to be appropriately labeled to avoid misinformation penalties.? - Design & Creative Platforms (Canva): AI usage for brainstorming and generating designs is permitted, but platforms typically place operational limits on how much AI content you can generate per month. Users are responsible for ensuring AI outputs do not mislead others and are used in accordance with local copyright laws.? - AI Generation Models (Open AI, Midjourney): AI tools are permitted, but they enforce strict universal policies. You cannot use these services for harassment, defamation, or generating unauthorized deepfakes of real people -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Wed Jul 22 10:29:47 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Wed, 22 Jul 2026 12:29:47 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 In-Reply-To: <97C503F6-EE5F-4743-BBBC-C2FEDDD55D35@afrinic.net> References: <74208ec3-0053-4c39-a87e-70d58054fd5e@uls.co.za> <97C503F6-EE5F-4743-BBBC-C2FEDDD55D35@afrinic.net> Message-ID: Hi Ben, Precisely what Jaco is suggesting is removing all that, and instead just asking that IPv6 prefix is provided to the CPE and routable, not traffic measurements needed. To avoid mixing the current Last Call discussion on the other proposals and not create additional noise, I decided to respond to all the points on this proposal once the LC ends. I will provide then a detailed review of the previous emails open this proposal and we can draft a new version. Tks! Regards, Jordi @jordipalet > El 22 jul 2026, a las 12:06, Ben Roberts - AfriNIC escribi?: > > Jaco, > I re-iterate that this kind of relatively sophisticated traffic destination analysis is beyond the technical capacity for many emerging ISPs and enterprise networks in continental Africa, and is just putting up unrealistic barriers to accessing IP addresses > > Cheers > > Ben > Sent from my iPhone > >> On 22 Jul 2026, at 11:30, Jaco Kroon via RPD wrote: >> >> ? >> Hi Jordi, Mark, >> >> After in-person discussion with Mark, I'd like to propose alternative wording for specifically this portion: >> >> "The IPv6 deployment plan must show the actual IPv4 top-25 traffic destinations of that network. For each of those external destinations >> that are IPv6-enabled, the following minimum IPv6 % will be considered as compliant: >> >> "25% in a maximum of 12 months. >> 50% in a maximum of 24 months. >> 75% in a maximum of 48 months. >> "In case of networks hosting any kind of services, applications or contents, will be considered as compliant when matching the following % of AAAA RRs available and IPv6 reachable from Internet: >> >> "25% in a maximum of 12 months. >> 75% in a maximum of 24 months. >> 95% in a maximum of 48 months. >> >> "Failure to comply with the IPv6 deployment plan according to the relevant criteria, constitutes a policy violation." >> >> As can be seen the author(s) already distinguish between access (eyeball) and hosting (content) networks. It does not make it clear in the case of hybrid networks here. For most larger networks this won't particularly matter since they are unlikely to be able to apply for additional /22s and even if they are /22s (as per in-person discussions with at least one network operator that makes me look like an extremely mild-mannered person) are not useful to them. >> >> Regardless, I feel that for access networks the measurement above is not well defined, nor sensible, as per discussion with Mark the measurement depends not only on your own behaviour but also that of external networks (be they customers or external content networks). Not discussed and which I only realised later on Monday after our discussion is that "actual IPv4 top-25 destinations" would *shift* as traffic moves to IPv6, which is to say that if *all* of my customers suddenly and unsuspectedly re-enable IPv6, then the likes of Google, Youtube, Cloudflare, Akamai, Meta and (AWS) won't be in our top-25 IPv4 destinations. Now my top-25 would start shifting to the likes of the banks, NTT, Xneelo, Hostafrica, Hetzner and probably other content hosting providers that are NOT IPv6 enabled (or not advertising that they are). Yes, I've been told that Xneelo does support IPv6 but I've yet to see a single site myself hosted on Xneelo side that has AAAA records deployed. As such, since this is a shifting target it cannot be a reliable measure. >> >> The measurements I would suggest: >> >> For access networks: The percentage of downstream networks/customers that has access to well-connected IPv6 should they so choose (well-connected in this sense means that the provided addresses are routable and reachable in the Internet's "DFZ"/Global routing table. To be clear: This doesn't mean they have to have it enabled downstream, just that it's available to the customer/network. >> >> This is something that can be easily shown/proven by any network. It would also (based on existing knowledge) force exactly those parties that are NOT currently deploying IPv6 to deploy. Yes, this includes some of our own downstream IPT and/or consulting customers who would score 0% on either measure. This would also allow us to raise the bar to a higher percentage such as the 95% as for content networks. >> >> This must not be a "made available on request" situation - and a customer should be in a position to obtain IPv6 via the usual configuration mechanisms, and RAs should be advertised standard to these downstream customers, and provide for managed DHCPv6 PD, including at least a set of DNS servers. >> >> My issue with hosting networks is that the network provider doesn't, in many (most) cases, also control DNS. And in a significant portion of cases the third-party IT providers just flatly refuse to deploy AAAA records. This ends up punishing a network operator for the behaviour of external parties. >> >> I thus suggest the following: >> >> "When applying for additional IPv4 space, the following conditions must be met as per the time frames from issuance of the first IPv6 space to LIRs and EUs, or {policy approval date}, whichever is later: >> >> In the case of access networks, the percentage of customers that has access to global IPv6 delegations without interference required from the Network Operator must be at or above the following thresholds: >> >> * 25 % within 12 months; >> * 50 % within 24 months; >> * 75 % within 36 months; >> * 95 % within 48 months; >> >> For the avoidance of doubt: "without interference required from the Network Operator" means that routers directly upstream from access clients must permit IPv6CP in the case of PPP connections, and all upstream routers must actively transmit IPv6 Router-Advertisements, and in order to allow for such downstream customers to obtain Prefix Delegations, most likely by way of DHCPv6 PD, and the space must be reachable from the global routing table. >> >> In the case of content hosting network, the percentage of assigned IPv4 space assigned to those networks also covered by IPv6 assignments must reach: >> >> * 25 % within 12 months; >> * 50 % within 24 months; >> * 75 % within 36 months; >> * 95 % within 48 months; >> >> For avoidance of doubt: Assigned IPv6 space must be reachable from the global routing table. >> >> In the case where a network provides both access and content hosting services, both criteria must be independently complied with." >> >> This would address my concerns, and I believe still force those networks looking to obtain additional space that have not yet deployed IPv6 to do so. >> >> I think linking this to traffic thresholds is a very bad idea. Especially if it's linked to specific top 25-IPv4 external sites. I suspect at least a few of those top external sites in our case would be banking sites - and NONE of the major banks in SA has any client-facing IPv6 deployed that I'm aware of - making it impossible for us to comply even if 100% of our customers has access to and are IPv6 enabled. I did have a discussion about this and DNSSEC with at least one such case yesterday, but I promise you nothing will come from that. >> >> One concern I still have is that the above implies every single piece of assigned address space can 100% clearly be categorised into access or hosting, which isn't always as clearly defined as one would like it to be, but I'd wager that in those cases one or the other will be the predominant purpose, and we can just use that purpose for those cases. This is something I'd leave to operational discretion to qualify at application/assessment time to be honest. As long as each piece of assigned space (ie, the minimum 90% usage) from the LIR/EU is classified into one of these categories. >> >> I hope this helps, and thanks for the chat Mark. >> >> Kind regards, >> Jaco >> >> On 2026/07/20 10:30, Jaco Kroon via RPD wrote: >> >>> Hi, >>> >>> I'm going to state this again - I support the principle but not the implementation. >>> >>> Specifically the way in which this links IPv4 requests to IPv6 *traffic levels* as a percentage, rather than percentage of network to which IPv6 has been deployed. >>> >>> I'm unable to sensibly force my customers to consume IPv6, no matter what. Further - we host a bunch of content which due to lack of external IPv6 deployment (specifically on MNO networks) brings down our overall level of network IPv6 thresholds. This in spite of but one single /29 subnet (which communicates exclusively with MNO networks, this might change in the next month, thus deploying IPv6 here until now made no sense, and this little subnet single-handedly carries around 5% of our ingress and ~30% of our egress bandwidth). >>> >>> As written this policy punishes network operators for bad behaviour of others, be it other access networks, or customers. >>> >>> It also adds significant additional costs towards otherwise needless network monitoring that would otherwise not be required. >>> >>> Again, to be clear: I'm in full support of the principle of linking IPv4 allocations/assignments to IPv6 deployment, I simply disagree with how it should be measured. >>> >>> Traffic levels are not a good measure. If 50% of my network is capable of IPv6, and 50% of content being accessed, or 50% of of eyeballs accessing my network are IPv6 capable, that puts my general IPv6 network levels around 25%, depending on exact patterns, possibly a bit higher, but no higher than 50%. Now our ability to access IPv4 resources is being limited by *others's* IPv6 deployment rather than merely our own. >>> >>> This should be measured as: >>> >>> What percentage of existing deployed IPv4 resources on the network also has IPv6 deployed in the case of content provisioning, and has access to IPv6 for downstream networks. >>> >>> For us the former percentage, having somewhere between a /22 and /23 provisioned for *services*, so let's work on a /23 or about 512 IPs with only a /29 not being IPv6 enabled as of right now is 98.5%, however, traffic patterns on access shows less than 5% of actual traffic is IPv6. >>> >>> For the latter, 100% of downstream customers/networks has *access* to IPv6. On customers using ppp less than 5% are consuming IPv6. At least a portion of these configures IPv6 LL (just over 30%). Once that happens we do actively send RAs to provoke configuration. >>> >>> For AE customers (Or "DHCP Customers") things looked better, as of right now we've got 43% active IPv6 customers (which shows that consumer routers are more inclined to grab IPv6 on "DHCP uplinks compared to PPP", however, this percentage used to be closer to 96%, as customers are *actively against recommendation insisting on switching OFF IPv6*. >>> >>> Whilst we are pushing we cannot prescribe to customers to keep IPv6 enabled - they'll simply move their business elsewhere if we push, thus this policy - as written - creates a significant operational issue. >>> >>> Kind regards, >>> Jaco >>> >>> On 2026/07/19 11:26, Mark Elkins via RPD wrote: >>> >>>> Dear PDWG, >>>> >>>> I have two major concerns regarding the Internet in Africa. >>>> >>>> 1 - Lack of DNSSEC - for DNS security >>>> >>>> 2 - Lack of IPv6 - for growth >>>> >>>> I run something called the Observatory - https://observatory.dnsstudy.africa - which has in the past collected information such as how many domains there are, are they DNSSEC Signed and are they IPv6 accessible. >>>> >>>> So I want Domain content to be IPv6 Accessible... >>>> >>>> ISP's need to have IPv6 resources, they need to make sure that all content has IPv6 - so that as end users access that content, they have IPv6 access all the way through. IPv6 doesn't use RFC1918 addresses - all IPv6 addresses are unique. >>>> >>>> We are running out of IPv4. Yes - some resources will still need IPv4 addresses - so let's stretch what we have out. The IPv4 Soft Landing proposal helps this stretching process - by forcing IPv6 onto LIR's/ ISP's. >>>> >>>> So I support the Proposal. It may not be perfect but it will help shape the African Internet Industry further into the right direction. >>>> >>>> -- >>>> Mark James ELKINS - Posix Systems - (South) Africa >>>> mje at posix.co.za Tel: +27.826010496 >>>> For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Wed Jul 22 10:32:30 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Wed, 22 Jul 2026 12:32:30 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From honlue at gmail.com Wed Jul 22 13:32:48 2026 From: honlue at gmail.com (Musa Stephen Honlue) Date: Wed, 22 Jul 2026 15:32:48 +0200 Subject: [rpd] Policy supremacy In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From nonjabulosphilile at gmail.com Wed Jul 22 13:45:19 2026 From: nonjabulosphilile at gmail.com (Nonjabulo Sphilile) Date: Wed, 22 Jul 2026 15:45:19 +0200 Subject: [rpd] Policy supremacy Message-ID: Hi Musa, The PDWG is open. Participation does not depend on being known to long-standing members, attending earlier meetings, or proving a professional stake after joining. New participation is still participation. KYC would be a serious procedural change, not an informal test for unfamiliar objectors. Any such requirement would need to be formally adopted, proportionate, privacy-preserving, and applied equally to established and new participants. Similar views are not proof of impersonation. If there is concrete evidence of misconduct, please submit it to the co-chairs. Otherwise, I will not continue discussing identities or drafting methods. Let us return to the policy. Regards, Nonjabulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From froztbyte at froztbyte.net Wed Jul 22 13:51:18 2026 From: froztbyte at froztbyte.net (JP) Date: Wed, 22 Jul 2026 15:51:18 +0200 Subject: [rpd] The usage of AI in platforms In-Reply-To: <382163234.1741936.1784715315720@mail.yahoo.com> References: <382163234.1741936.1784715315720.ref@mail.yahoo.com> <382163234.1741936.1784715315720@mail.yahoo.com> Message-ID: On 22 Jul 2026, at 12:15, Mzwakhe Mabasa via RPD wrote: > Good day.I would like to post to the RPD mailing list. Kindly allow me > this opportunity of being part of the RPD afrinic policy decisions.? > > While AI is widely used across the internet, its acceptability > depends on the specific platform you are referring to . Most social > networks allow AI assistance, but require the clear labeling of > AI-generated imagery and ban non-consensual deepfakes or harmful > content.?LSince platform policies vary greatly, here is a breakdown > of how the most popular services handle AI usage: > > - Social Media (Facebook, Instagram, TikTok, YouTube): Generally > allowed, but social media algorithms penalize low-quality, generic > content. Major platforms are shifting to automatic detection and > require synthetic imagery to be appropriately labeled to avoid > misinformation penalties.? > > - Design & Creative Platforms (Canva): AI usage for brainstorming > and generating designs is permitted, but platforms typically place > operational limits on how much AI content you can generate per month. > Users are responsible for ensuring AI outputs do not mislead others > and are used in accordance with local copyright laws.? > > - AI Generation Models (Open AI, Midjourney): AI tools are > permitted, but they enforce strict universal policies. You cannot use > these services for harassment, defamation, or generating unauthorized > deepfakes of real people to play off an older joke: q: ?how do you know someone?s using LLMs?? a: ?they?ll damn well tell you? normally I don?t need to pay much attention to rpd because things don?t move that much, and then the last week? the sloppist tsunami has been quite notable. and it?s near all this kind of milquetoast nonsense gibberish. I saw someone else mention the astroturfing component of things too (and a cursory investigation around the poster domains for the most vocal proponents there had me raising my eyebrows most spock-like) but I?ll leave that aside for now it?s probably worth rpd considering a full and complete ban on prompt-generation and prompt-assistance for use on the policy list, with possibly a poster cooldown/block period (and some way to deal with repeat offenders and ban evasion). there?s both precedent and strong arguments in favour precedent: a number of other public-benefit and mass-cooperation organisations and projects have taken to the hardline block (the most notable is codeberg, as of earlier today) arguments: the most obvious is exactly what has happened in the last week (and the alternative of no ban is an utter deluge of worthless noise, which will space-fill as far as it can go). there is also ample evidence across multiple years and multiple studies that these technologies are _bad_ at fine detail, and that?s exactly the sort of thing that is very ill-fitting in the context of what rpd is to be doing -J -------------- next part -------------- An HTML attachment was scrubbed... URL: From diroikaralis at gmail.com Wed Jul 22 13:52:40 2026 From: diroikaralis at gmail.com (Diroi Karalis) Date: Wed, 22 Jul 2026 15:52:40 +0200 Subject: [rpd] Policy supremacy Message-ID: Dear Musa, Tshepo and Gugu don't need prior recognition from established participants before their input counts. Joining recently, missing earlier meetings, or sharing similar views is not evidence of impersonation or bad faith. Anyone is entitled to join an open process at Last Call and raise objections before a proposal becomes policy. KYC would be a significant procedural and privacy change. It can't be applied selectively to objectors we don't recognize it would need a formal basis, a clear justification, proper safeguards, and equal application to every participant, not just the inconvenient ones. If you have evidence of misconduct, send it to the co-chairs. Otherwise, engage with Tshepo and Gugu's arguments on their merits. Familiarity isn't authority, and "the community" isn't a closed circle that gets to decide who's allowed in. Regards, Diroi -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Wed Jul 22 14:01:03 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Wed, 22 Jul 2026 16:01:03 +0200 Subject: [rpd] Policy supremacy In-Reply-To: References: Message-ID: <14936a5e-6d1e-4e4b-8957-b0e2018274aa@uls.co.za> Hi, Are we thus proposing that each and every person must positively identify themselves prior to being subscribed to the RPD list, as well as for all existing subscribers to be positively identified by date X or be unsubscribed?? To what extend should this identification go - should it include affiliation checking, eg, Jaco Kroon actually JK19-AFRINIC in the whois db - from where you can track the networks I'm involved with? I'd be in support of such a policy change/direction. Regarding use of AI, I don't have a particular objection to the use of LLMs (but having worked on the Comp-Sci side of things ... I would not trust them without validating whatever they spit out - and recent experience - not restricted to this ML - shows they spit out more garbage than most community-driven support forums), as long as they're used sensibly to help with formatting and/or interpretation of emails, not to spew out noise for the sake of noise - as what it feels has been done the last week or two. Kind regards, Jaco n 2026/07/22 15:52, Diroi Karalis wrote: > Dear Musa, > > Tshepo and Gugu don't need prior recognition from established > participants before their input counts. Joining recently, missing > earlier meetings, or sharing similar views is not evidence of > impersonation or bad faith. Anyone is entitled to join an open process > at Last Call and raise objections before a proposal becomes policy. > KYC would be a significant procedural and privacy change. It can't be > applied selectively to objectors we don't recognize it would need a > formal basis, a clear justification, proper safeguards, and equal > application to every participant, not just the inconvenient ones. > If you have evidence of misconduct, send it to the co-chairs. > Otherwise, engage with Tshepo and Gugu's arguments on their merits. > Familiarity isn't authority, and "the community" isn't a closed circle > that gets to decide who's allowed in. > > Regards, > Diroi > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From fundiswanadia2 at gmail.com Wed Jul 22 14:11:08 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Wed, 22 Jul 2026 16:11:08 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 158 In-Reply-To: References: Message-ID: Hi everyone, I understand the concerns being raised about AI and new participants joining the discussion. However, I don't think we should discourage people from participating simply because they are new or because they choose to use AI as a writing aid. AI can help people organize their thoughts, improve grammar, or communicate more clearly, but it shouldn't replace independent thinking. What matters most is whether the ideas being presented are relevant, technically sound, and contribute meaningfully to the policy discussion. The PDP has always been intended to be open and inclusive. New participants should be encouraged to engage, provided they do so respectfully and in good faith. If there are concerns about duplicate messages or coordinated submissions, those can be addressed based on evidence rather than assumptions about individuals. I believe we should continue evaluating contributions on their merit and keep the discussion focused on the policy itself. Kind regards, Fundiswa Nadia Maseko On Wed, 22 Jul 2026, 15:53 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: Policy supremacy (Nonjabulo Sphilile) > 2. Re: The usage of AI in platforms (JP) > 3. Re: Policy supremacy (Diroi Karalis) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 22 Jul 2026 15:45:19 +0200 > From: Nonjabulo Sphilile > To: rpd at afrinic.net > Subject: Re: [rpd] Policy supremacy > Message-ID: > aWw6YqZVRZ51DVEdpsQ3xfRar0XmgPedHLruA at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Musa, > > The PDWG is open. Participation does not depend on being known to > long-standing members, attending earlier meetings, or proving a > professional stake after joining. New participation is still participation. > > KYC would be a serious procedural change, not an informal test for > unfamiliar objectors. Any such requirement would need to be formally > adopted, proportionate, privacy-preserving, and applied equally to > established and new participants. > > Similar views are not proof of impersonation. If there is concrete evidence > of misconduct, please submit it to the co-chairs. Otherwise, I will not > continue discussing identities or drafting methods. > > Let us return to the policy. > > Regards, > Nonjabulo > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/1992795c/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Wed, 22 Jul 2026 15:51:18 +0200 > From: JP > To: rpd at afrinic.net > Subject: Re: [rpd] The usage of AI in platforms > Message-ID: > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > On 22 Jul 2026, at 12:15, Mzwakhe Mabasa via RPD wrote: > > > Good day.I would like to post to the RPD mailing list. Kindly allow me > > this opportunity of being part of the RPD afrinic policy decisions.? > > > > While AI is widely used across the internet, its acceptability > > depends on the specific platform you are referring to . Most social > > networks allow AI assistance, but require the clear labeling of > > AI-generated imagery and ban non-consensual deepfakes or harmful > > content.?LSince platform policies vary greatly, here is a breakdown > > of how the most popular services handle AI usage: > > > > - Social Media (Facebook, Instagram, TikTok, YouTube): Generally > > allowed, but social media algorithms penalize low-quality, generic > > content. Major platforms are shifting to automatic detection and > > require synthetic imagery to be appropriately labeled to avoid > > misinformation penalties.? > > > > - Design & Creative Platforms (Canva): AI usage for brainstorming > > and generating designs is permitted, but platforms typically place > > operational limits on how much AI content you can generate per month. > > Users are responsible for ensuring AI outputs do not mislead others > > and are used in accordance with local copyright laws.? > > > > - AI Generation Models (Open AI, Midjourney): AI tools are > > permitted, but they enforce strict universal policies. You cannot use > > these services for harassment, defamation, or generating unauthorized > > deepfakes of real people > > to play off an older joke: > > q: ?how do you know someone?s using LLMs?? > a: ?they?ll damn well tell you? > > normally I don?t need to pay much attention to rpd because things > don?t move that much, and then the last week? the sloppist tsunami > has been quite notable. and it?s near all this kind of milquetoast > nonsense gibberish. I saw someone else mention the astroturfing > component of things too (and a cursory investigation around the poster > domains for the most vocal proponents there had me raising my eyebrows > most spock-like) but I?ll leave that aside for now > > it?s probably worth rpd considering a full and complete ban on > prompt-generation and prompt-assistance for use on the policy list, with > possibly a poster cooldown/block period (and some way to deal with > repeat offenders and ban evasion). > > there?s both precedent and strong arguments in favour > > precedent: a number of other public-benefit and mass-cooperation > organisations and projects have taken to the hardline block (the most > notable is codeberg, as of earlier today) > > arguments: the most obvious is exactly what has happened in the last > week (and the alternative of no ban is an utter deluge of worthless > noise, which will space-fill as far as it can go). there is also ample > evidence across multiple years and multiple studies that these > technologies are _bad_ at fine detail, and that?s exactly the sort of > thing that is very ill-fitting in the context of what rpd is to be doing > > -J > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/f83dfe25/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Wed, 22 Jul 2026 15:52:40 +0200 > From: Diroi Karalis > To: rpd at afrinic.net > Subject: Re: [rpd] Policy supremacy > Message-ID: > < > CA+wt7VoZ2hQyw6ZiGAAxr-SRTmXaYwjM-xD_aknC2tj+Oqhdig at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Musa, > > Tshepo and Gugu don't need prior recognition from established participants > before their input counts. Joining recently, missing earlier meetings, or > sharing similar views is not evidence of impersonation or bad faith. Anyone > is entitled to join an open process at Last Call and raise objections > before a proposal becomes policy. > KYC would be a significant procedural and privacy change. It can't be > applied selectively to objectors we don't recognize it would need a formal > basis, a clear justification, proper safeguards, and equal application to > every participant, not just the inconvenient ones. > If you have evidence of misconduct, send it to the co-chairs. Otherwise, > engage with Tshepo and Gugu's arguments on their merits. Familiarity isn't > authority, and "the community" isn't a closed circle that gets to decide > who's allowed in. > > Regards, > Diroi > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/7c67f9fd/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 158 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Wed Jul 22 14:12:07 2026 From: mike at iptrading.com (Mike Burns) Date: Wed, 22 Jul 2026 10:12:07 -0400 Subject: [rpd] Policy supremacy In-Reply-To: <14936a5e-6d1e-4e4b-8957-b0e2018274aa@uls.co.za> References: <14936a5e-6d1e-4e4b-8957-b0e2018274aa@uls.co.za> Message-ID: <001e01dd19e4$148ce9c0$3da6bd40$@iptrading.com> Hi, I don't think that is the answer. The forum should remain open to all contributors. Remember it is not the speaker, it is the argument that matters. If you or anybody else wishes to include their bona fides, that is fine, but not gatekeeping contributors. A very bad idea, to my mind, and a sledgehammer approach to a few AI tinged posts. I think we have to acknowledge the use of AI in writing posts will increase, and that is not always a bad thing. Regards, Mike -----Original Message----- From: Jaco Kroon via RPD Sent: Wednesday, July 22, 2026 10:01 AM To: rpd at afrinic.net Subject: Re: [rpd] Policy supremacy Hi, Are we thus proposing that each and every person must positively identify themselves prior to being subscribed to the RPD list, as well as for all existing subscribers to be positively identified by date X or be unsubscribed? To what extend should this identification go - should it include affiliation checking, eg, Jaco Kroon actually JK19-AFRINIC in the whois db - from where you can track the networks I'm involved with? I'd be in support of such a policy change/direction. Regarding use of AI, I don't have a particular objection to the use of LLMs (but having worked on the Comp-Sci side of things ... I would not trust them without validating whatever they spit out - and recent experience - not restricted to this ML - shows they spit out more garbage than most community-driven support forums), as long as they're used sensibly to help with formatting and/or interpretation of emails, not to spew out noise for the sake of noise - as what it feels has been done the last week or two. Kind regards, Jaco n 2026/07/22 15:52, Diroi Karalis wrote: > Dear Musa, > > Tshepo and Gugu don't need prior recognition from established > participants before their input counts. Joining recently, missing > earlier meetings, or sharing similar views is not evidence of > impersonation or bad faith. Anyone is entitled to join an open process > at Last Call and raise objections before a proposal becomes policy. > KYC would be a significant procedural and privacy change. It can't be > applied selectively to objectors we don't recognize it would need a > formal basis, a clear justification, proper safeguards, and equal > application to every participant, not just the inconvenient ones. > If you have evidence of misconduct, send it to the co-chairs. > Otherwise, engage with Tshepo and Gugu's arguments on their merits. > Familiarity isn't authority, and "the community" isn't a closed circle > that gets to decide who's allowed in. > > Regards, > Diroi > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd From fundiswanadia2 at gmail.com Wed Jul 22 14:16:00 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Wed, 22 Jul 2026 16:16:00 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 159 In-Reply-To: References: Message-ID: Hi Jaco, I think it's worth remembering that every experienced contributor was once a first-time participant. If we want broader community participation, we should expect new voices to join as issues become more relevant to them. The timing of someone's participation shouldn't, by itself, determine the value of their contribution. The PDP is strengthened when discussions remain focused on the technical merits of proposals rather than on who is participating or when they joined. If there are concerns about the mailing list process itself, those are valid topics for a separate discussion. However, I hope we can keep this thread centred on the proposal under review so that the community can reach the best possible outcome. Kind regards Fundiswa Nadia Maseko On Wed, 22 Jul 2026, 16:11 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: Policy supremacy (Jaco Kroon) > 2. Re: RPD Digest, Vol 222, Issue 158 (Fundiswa Nadia Maseko) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 22 Jul 2026 16:01:03 +0200 > From: Jaco Kroon > To: rpd at afrinic.net > Subject: Re: [rpd] Policy supremacy > Message-ID: <14936a5e-6d1e-4e4b-8957-b0e2018274aa at uls.co.za> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi, > > Are we thus proposing that each and every person must positively > identify themselves prior to being subscribed to the RPD list, as well > as for all existing subscribers to be positively identified by date X or > be unsubscribed?? To what extend should this identification go - should > it include affiliation checking, eg, Jaco Kroon actually JK19-AFRINIC in > the whois db - from where you can track the networks I'm involved with? > > I'd be in support of such a policy change/direction. > > Regarding use of AI, I don't have a particular objection to the use of > LLMs (but having worked on the Comp-Sci side of things ... I would not > trust them without validating whatever they spit out - and recent > experience - not restricted to this ML - shows they spit out more > garbage than most community-driven support forums), as long as they're > used sensibly to help with formatting and/or interpretation of emails, > not to spew out noise for the sake of noise - as what it feels has been > done the last week or two. > > Kind regards, > Jaco > > n 2026/07/22 15:52, Diroi Karalis wrote: > > > Dear Musa, > > > > Tshepo and Gugu don't need prior recognition from established > > participants before their input counts. Joining recently, missing > > earlier meetings, or sharing similar views is not evidence of > > impersonation or bad faith. Anyone is entitled to join an open process > > at Last Call and raise objections before a proposal becomes policy. > > KYC would be a significant procedural and privacy change. It can't be > > applied selectively to objectors we don't recognize it would need a > > formal basis, a clear justification, proper safeguards, and equal > > application to every participant, not just the inconvenient ones. > > If you have evidence of misconduct, send it to the co-chairs. > > Otherwise, engage with Tshepo and Gugu's arguments on their merits. > > Familiarity isn't authority, and "the community" isn't a closed circle > > that gets to decide who's allowed in. > > > > Regards, > > Diroi > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > ------------------------------ > > Message: 2 > Date: Wed, 22 Jul 2026 16:11:08 +0200 > From: Fundiswa Nadia Maseko > To: rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 158 > Message-ID: > rbjfBJEesLOjvV_f1OTFkeiLpGj0Q at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi everyone, > > I understand the concerns being raised about AI and new participants > joining the discussion. However, I don't think we should discourage people > from participating simply because they are new or because they choose to > use AI as a writing aid. > > AI can help people organize their thoughts, improve grammar, or communicate > more clearly, but it shouldn't replace independent thinking. What matters > most is whether the ideas being presented are relevant, technically sound, > and contribute meaningfully to the policy discussion. > > The PDP has always been intended to be open and inclusive. New participants > should be encouraged to engage, provided they do so respectfully and in > good faith. If there are concerns about duplicate messages or coordinated > submissions, those can be addressed based on evidence rather than > assumptions about individuals. > > I believe we should continue evaluating contributions on their merit and > keep the discussion focused on the policy itself. > > Kind regards, > > Fundiswa Nadia Maseko > > On Wed, 22 Jul 2026, 15:53 , wrote: > > > Send RPD mailing list submissions to > > rpd at afrinic.net > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.afrinic.net/mailman/listinfo/rpd > > or, via email, send a message with subject or body 'help' to > > rpd-request at afrinic.net > > > > You can reach the person managing the list at > > rpd-owner at afrinic.net > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of RPD digest..." > > > > > > Today's Topics: > > > > 1. Re: Policy supremacy (Nonjabulo Sphilile) > > 2. Re: The usage of AI in platforms (JP) > > 3. Re: Policy supremacy (Diroi Karalis) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Wed, 22 Jul 2026 15:45:19 +0200 > > From: Nonjabulo Sphilile > > To: rpd at afrinic.net > > Subject: Re: [rpd] Policy supremacy > > Message-ID: > > > aWw6YqZVRZ51DVEdpsQ3xfRar0XmgPedHLruA at mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > Hi Musa, > > > > The PDWG is open. Participation does not depend on being known to > > long-standing members, attending earlier meetings, or proving a > > professional stake after joining. New participation is still > participation. > > > > KYC would be a serious procedural change, not an informal test for > > unfamiliar objectors. Any such requirement would need to be formally > > adopted, proportionate, privacy-preserving, and applied equally to > > established and new participants. > > > > Similar views are not proof of impersonation. If there is concrete > evidence > > of misconduct, please submit it to the co-chairs. Otherwise, I will not > > continue discussing identities or drafting methods. > > > > Let us return to the policy. > > > > Regards, > > Nonjabulo > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/1992795c/attachment-0001.html > > > > > > > ------------------------------ > > > > Message: 2 > > Date: Wed, 22 Jul 2026 15:51:18 +0200 > > From: JP > > To: rpd at afrinic.net > > Subject: Re: [rpd] The usage of AI in platforms > > Message-ID: > > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > > On 22 Jul 2026, at 12:15, Mzwakhe Mabasa via RPD wrote: > > > > > Good day.I would like to post to the RPD mailing list. Kindly allow me > > > this opportunity of being part of the RPD afrinic policy decisions.? > > > > > > While AI is widely used across the internet, its acceptability > > > depends on the specific platform you are referring to . Most social > > > networks allow AI assistance, but require the clear labeling of > > > AI-generated imagery and ban non-consensual deepfakes or harmful > > > content.?LSince platform policies vary greatly, here is a breakdown > > > of how the most popular services handle AI usage: > > > > > > - Social Media (Facebook, Instagram, TikTok, YouTube): Generally > > > allowed, but social media algorithms penalize low-quality, generic > > > content. Major platforms are shifting to automatic detection and > > > require synthetic imagery to be appropriately labeled to avoid > > > misinformation penalties.? > > > > > > - Design & Creative Platforms (Canva): AI usage for brainstorming > > > and generating designs is permitted, but platforms typically place > > > operational limits on how much AI content you can generate per month. > > > Users are responsible for ensuring AI outputs do not mislead others > > > and are used in accordance with local copyright laws.? > > > > > > - AI Generation Models (Open AI, Midjourney): AI tools are > > > permitted, but they enforce strict universal policies. You cannot use > > > these services for harassment, defamation, or generating unauthorized > > > deepfakes of real people > > > > to play off an older joke: > > > > q: ?how do you know someone?s using LLMs?? > > a: ?they?ll damn well tell you? > > > > normally I don?t need to pay much attention to rpd because things > > don?t move that much, and then the last week? the sloppist tsunami > > has been quite notable. and it?s near all this kind of milquetoast > > nonsense gibberish. I saw someone else mention the astroturfing > > component of things too (and a cursory investigation around the poster > > domains for the most vocal proponents there had me raising my eyebrows > > most spock-like) but I?ll leave that aside for now > > > > it?s probably worth rpd considering a full and complete ban on > > prompt-generation and prompt-assistance for use on the policy list, with > > possibly a poster cooldown/block period (and some way to deal with > > repeat offenders and ban evasion). > > > > there?s both precedent and strong arguments in favour > > > > precedent: a number of other public-benefit and mass-cooperation > > organisations and projects have taken to the hardline block (the most > > notable is codeberg, as of earlier today) > > > > arguments: the most obvious is exactly what has happened in the last > > week (and the alternative of no ban is an utter deluge of worthless > > noise, which will space-fill as far as it can go). there is also ample > > evidence across multiple years and multiple studies that these > > technologies are _bad_ at fine detail, and that?s exactly the sort of > > thing that is very ill-fitting in the context of what rpd is to be doing > > > > -J > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/f83dfe25/attachment-0001.html > > > > > > > ------------------------------ > > > > Message: 3 > > Date: Wed, 22 Jul 2026 15:52:40 +0200 > > From: Diroi Karalis > > To: rpd at afrinic.net > > Subject: Re: [rpd] Policy supremacy > > Message-ID: > > < > > CA+wt7VoZ2hQyw6ZiGAAxr-SRTmXaYwjM-xD_aknC2tj+Oqhdig at mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > Dear Musa, > > > > Tshepo and Gugu don't need prior recognition from established > participants > > before their input counts. Joining recently, missing earlier meetings, or > > sharing similar views is not evidence of impersonation or bad faith. > Anyone > > is entitled to join an open process at Last Call and raise objections > > before a proposal becomes policy. > > KYC would be a significant procedural and privacy change. It can't be > > applied selectively to objectors we don't recognize it would need a > formal > > basis, a clear justification, proper safeguards, and equal application to > > every participant, not just the inconvenient ones. > > If you have evidence of misconduct, send it to the co-chairs. Otherwise, > > engage with Tshepo and Gugu's arguments on their merits. Familiarity > isn't > > authority, and "the community" isn't a closed circle that gets to decide > > who's allowed in. > > > > Regards, > > Diroi > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/7c67f9fd/attachment.html > > > > > > > ------------------------------ > > > > Subject: Digest Footer > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > ------------------------------ > > > > End of RPD Digest, Vol 222, Issue 158 > > ************************************* > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/ba32bf97/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 159 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ST10120874 at vcconnect.edu.za Wed Jul 22 14:21:59 2026 From: ST10120874 at vcconnect.edu.za (Mphoentle Mokheseng) Date: Wed, 22 Jul 2026 14:21:59 +0000 Subject: [rpd] Policy supremacy Message-ID: Dear Musa, The question is not where Tshepo and Gugu were before the PPM. Last Call exists precisely so that a proposal can be scrutinised before it becomes binding, and prior attendance is not a licence to participate. Familiarity is not proof of legitimacy, Recent subscriptions and similar viewpoints do not, on their own, establish false identity or bad faith. If there is concrete evidence of impersonation or coordinated flooding, it should be submitted to the co-chairs, who are equipped to assess it. Short of that, contributions should be judged on their substance, not on how long their authors have been around. This is also why KYC cannot be invented selectively, simply because established participants find an unfamiliar objection inconvenient. Turning an open policy forum into a permission system is a significant step, and any identity requirement would need a formal basis, a demonstrated necessity, proper privacy safeguards, and equal application to everyone, not just to newcomers whose views are unwelcome. Ultimately, "the community" is not limited to those already known to one another. A mailing list is not a private club, and regular participation does not, by itself, confer authority to decide who belongs. Regards, Mphoentle Disclaimer This email and the information contained herein are Advtech Ltd confidential and are protected by law. Please navigate to our website for more information https://www.groupadvtech.com. Use of this information or this email by any person for any purposes other than that for which it is intended is prohibited and may result in civil and/or criminal liability. This email is not to be shared with any 3rd parties not included within this email, without the written consent of its Author. If you have received this message in error, please notify Advtech immediately, telephone number +27 11 676 8000. Advtech leads the private sector in the fields of education and resourcing, contributing meaningfully towards the sustainable development of human capacity in South Africa. -------------- next part -------------- An HTML attachment was scrubbed... URL: From NPertuniaPetronella at outlook.com Wed Jul 22 14:22:48 2026 From: NPertuniaPetronella at outlook.com (NP Petronella) Date: Wed, 22 Jul 2026 14:22:48 +0000 Subject: [rpd] Fw: Policy supremacy In-Reply-To: References: Message-ID: Get Outlook for Android ________________________________ From: NP Petronella Sent: Wednesday, 22 July 2026 16:19:56 To: rpd-request at afrinic.net ; honlue at gmail.com Subject: Re: [rpd] Policy supremacy Dear Musa and Colleagues, Operating an ASN, attending the PPM, or being known to long-standing participants is not a condition for joining an open PDP. People may become aware of a proposal at different stages, including Last Call, and still have the right to question it. Where other participants come from, and what they choose to disclose, is for them to explain. Familiarity does not determine legitimacy, and established participants do not own the definition of ?community.? If KYC or affiliation disclosure is considered necessary, it must be proposed formally, justified, privacy-protected, and applied equally to everyone. It cannot be introduced informally and selectively against unfamiliar objectors. Experience may provide useful evidence. It does not create a mandate to decide who has enough ?stake? to speak. If there is evidence of impersonation or abuse, submit it to the co-chairs. Otherwise, please assess the arguments and return to the policy. I had a similar experience after becoming active on this mailing list: unusual activity on my Gmail account, an unexpected unsubscribe, and problems sending or receiving messages. I am not accusing anyone without evidence. However, this is precisely why a change of email address should not be treated as proof of a false identity or improper participation. A mailbox is only a communication tool; it is not the person. If identity verification is genuinely required, it should be introduced through a formal, privacy-protective process and applied equally to everyone. Until then, participants should be judged by what they submit, not by whether established members recognise their email addresses. Regards, Nonhlanhla -------------- next part -------------- An HTML attachment was scrubbed... URL: From saul at enetworks.co.za Wed Jul 22 14:22:56 2026 From: saul at enetworks.co.za (Saul Stein) Date: Wed, 22 Jul 2026 14:22:56 +0000 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 In-Reply-To: References: <74208ec3-0053-4c39-a87e-70d58054fd5e@uls.co.za> <97C503F6-EE5F-4743-BBBC-C2FEDDD55D35@afrinic.net> Message-ID: HI Jordi, Most of my clients ACTIVELY DO NOT want IPv6 near their network. (very sad, but true) Thus this policy has commercial implications. I?ll agree that we need to make it available should they want, but nothing configured should be mandatory. Thanks Saul From: jordi.palet--- via RPD Sent: Wednesday, 22 July 2026 12:30 To: rpd at afrinic.net Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 Hi Ben, Precisely what Jaco is suggesting is removing all that, and instead just asking that IPv6 prefix is provided to the CPE and routable, not traffic measurements needed. To avoid mixing the current Last Call discussion on the other proposals and not create additional noise, I decided to respond to all the points on this proposal once the LC ends. I will provide then a detailed review of the previous emails open this proposal and we can draft a new version. Tks! Regards, Jordi @jordipalet El 22 jul 2026, a las 12:06, Ben Roberts - AfriNIC > escribi?: Jaco, I re-iterate that this kind of relatively sophisticated traffic destination analysis is beyond the technical capacity for many emerging ISPs and enterprise networks in continental Africa, and is just putting up unrealistic barriers to accessing IP addresses Cheers Ben Sent from my iPhone On 22 Jul 2026, at 11:30, Jaco Kroon via RPD > wrote: ? Hi Jordi, Mark, After in-person discussion with Mark, I'd like to propose alternative wording for specifically this portion: "The IPv6 deployment plan must show the actual IPv4 top-25 traffic destinations of that network. For each of those external destinations that are IPv6-enabled, the following minimum IPv6 % will be considered as compliant: "25% in a maximum of 12 months. 50% in a maximum of 24 months. 75% in a maximum of 48 months. "In case of networks hosting any kind of services, applications or contents, will be considered as compliant when matching the following % of AAAA RRs available and IPv6 reachable from Internet: "25% in a maximum of 12 months. 75% in a maximum of 24 months. 95% in a maximum of 48 months. "Failure to comply with the IPv6 deployment plan according to the relevant criteria, constitutes a policy violation." As can be seen the author(s) already distinguish between access (eyeball) and hosting (content) networks. It does not make it clear in the case of hybrid networks here. For most larger networks this won't particularly matter since they are unlikely to be able to apply for additional /22s and even if they are /22s (as per in-person discussions with at least one network operator that makes me look like an extremely mild-mannered person) are not useful to them. Regardless, I feel that for access networks the measurement above is not well defined, nor sensible, as per discussion with Mark the measurement depends not only on your own behaviour but also that of external networks (be they customers or external content networks). Not discussed and which I only realised later on Monday after our discussion is that "actual IPv4 top-25 destinations" would *shift* as traffic moves to IPv6, which is to say that if *all* of my customers suddenly and unsuspectedly re-enable IPv6, then the likes of Google, Youtube, Cloudflare, Akamai, Meta and (AWS) won't be in our top-25 IPv4 destinations. Now my top-25 would start shifting to the likes of the banks, NTT, Xneelo, Hostafrica, Hetzner and probably other content hosting providers that are NOT IPv6 enabled (or not advertising that they are). Yes, I've been told that Xneelo does support IPv6 but I've yet to see a single site myself hosted on Xneelo side that has AAAA records deployed. As such, since this is a shifting target it cannot be a reliable measure. The measurements I would suggest: For access networks: The percentage of downstream networks/customers that has access to well-connected IPv6 should they so choose (well-connected in this sense means that the provided addresses are routable and reachable in the Internet's "DFZ"/Global routing table. To be clear: This doesn't mean they have to have it enabled downstream, just that it's available to the customer/network. This is something that can be easily shown/proven by any network. It would also (based on existing knowledge) force exactly those parties that are NOT currently deploying IPv6 to deploy. Yes, this includes some of our own downstream IPT and/or consulting customers who would score 0% on either measure. This would also allow us to raise the bar to a higher percentage such as the 95% as for content networks. This must not be a "made available on request" situation - and a customer should be in a position to obtain IPv6 via the usual configuration mechanisms, and RAs should be advertised standard to these downstream customers, and provide for managed DHCPv6 PD, including at least a set of DNS servers. My issue with hosting networks is that the network provider doesn't, in many (most) cases, also control DNS. And in a significant portion of cases the third-party IT providers just flatly refuse to deploy AAAA records. This ends up punishing a network operator for the behaviour of external parties. I thus suggest the following: "When applying for additional IPv4 space, the following conditions must be met as per the time frames from issuance of the first IPv6 space to LIRs and EUs, or {policy approval date}, whichever is later: In the case of access networks, the percentage of customers that has access to global IPv6 delegations without interference required from the Network Operator must be at or above the following thresholds: * 25 % within 12 months; * 50 % within 24 months; * 75 % within 36 months; * 95 % within 48 months; For the avoidance of doubt: "without interference required from the Network Operator" means that routers directly upstream from access clients must permit IPv6CP in the case of PPP connections, and all upstream routers must actively transmit IPv6 Router-Advertisements, and in order to allow for such downstream customers to obtain Prefix Delegations, most likely by way of DHCPv6 PD, and the space must be reachable from the global routing table. In the case of content hosting network, the percentage of assigned IPv4 space assigned to those networks also covered by IPv6 assignments must reach: * 25 % within 12 months; * 50 % within 24 months; * 75 % within 36 months; * 95 % within 48 months; For avoidance of doubt: Assigned IPv6 space must be reachable from the global routing table. In the case where a network provides both access and content hosting services, both criteria must be independently complied with." This would address my concerns, and I believe still force those networks looking to obtain additional space that have not yet deployed IPv6 to do so. I think linking this to traffic thresholds is a very bad idea. Especially if it's linked to specific top 25-IPv4 external sites. I suspect at least a few of those top external sites in our case would be banking sites - and NONE of the major banks in SA has any client-facing IPv6 deployed that I'm aware of - making it impossible for us to comply even if 100% of our customers has access to and are IPv6 enabled. I did have a discussion about this and DNSSEC with at least one such case yesterday, but I promise you nothing will come from that. One concern I still have is that the above implies every single piece of assigned address space can 100% clearly be categorised into access or hosting, which isn't always as clearly defined as one would like it to be, but I'd wager that in those cases one or the other will be the predominant purpose, and we can just use that purpose for those cases. This is something I'd leave to operational discretion to qualify at application/assessment time to be honest. As long as each piece of assigned space (ie, the minimum 90% usage) from the LIR/EU is classified into one of these categories. I hope this helps, and thanks for the chat Mark. Kind regards, Jaco On 2026/07/20 10:30, Jaco Kroon via RPD wrote: Hi, I'm going to state this again - I support the principle but not the implementation. Specifically the way in which this links IPv4 requests to IPv6 *traffic levels* as a percentage, rather than percentage of network to which IPv6 has been deployed. I'm unable to sensibly force my customers to consume IPv6, no matter what. Further - we host a bunch of content which due to lack of external IPv6 deployment (specifically on MNO networks) brings down our overall level of network IPv6 thresholds. This in spite of but one single /29 subnet (which communicates exclusively with MNO networks, this might change in the next month, thus deploying IPv6 here until now made no sense, and this little subnet single-handedly carries around 5% of our ingress and ~30% of our egress bandwidth). As written this policy punishes network operators for bad behaviour of others, be it other access networks, or customers. It also adds significant additional costs towards otherwise needless network monitoring that would otherwise not be required. Again, to be clear: I'm in full support of the principle of linking IPv4 allocations/assignments to IPv6 deployment, I simply disagree with how it should be measured. Traffic levels are not a good measure. If 50% of my network is capable of IPv6, and 50% of content being accessed, or 50% of of eyeballs accessing my network are IPv6 capable, that puts my general IPv6 network levels around 25%, depending on exact patterns, possibly a bit higher, but no higher than 50%. Now our ability to access IPv4 resources is being limited by *others's* IPv6 deployment rather than merely our own. This should be measured as: What percentage of existing deployed IPv4 resources on the network also has IPv6 deployed in the case of content provisioning, and has access to IPv6 for downstream networks. For us the former percentage, having somewhere between a /22 and /23 provisioned for *services*, so let's work on a /23 or about 512 IPs with only a /29 not being IPv6 enabled as of right now is 98.5%, however, traffic patterns on access shows less than 5% of actual traffic is IPv6. For the latter, 100% of downstream customers/networks has *access* to IPv6. On customers using ppp less than 5% are consuming IPv6. At least a portion of these configures IPv6 LL (just over 30%). Once that happens we do actively send RAs to provoke configuration. For AE customers (Or "DHCP Customers") things looked better, as of right now we've got 43% active IPv6 customers (which shows that consumer routers are more inclined to grab IPv6 on "DHCP uplinks compared to PPP", however, this percentage used to be closer to 96%, as customers are *actively against recommendation insisting on switching OFF IPv6*. Whilst we are pushing we cannot prescribe to customers to keep IPv6 enabled - they'll simply move their business elsewhere if we push, thus this policy - as written - creates a significant operational issue. Kind regards, Jaco On 2026/07/19 11:26, Mark Elkins via RPD wrote: Dear PDWG, I have two major concerns regarding the Internet in Africa. 1 - Lack of DNSSEC - for DNS security 2 - Lack of IPv6 - for growth I run something called the Observatory - https://observatory.dnsstudy.africa - which has in the past collected information such as how many domains there are, are they DNSSEC Signed and are they IPv6 accessible. So I want Domain content to be IPv6 Accessible... ISP's need to have IPv6 resources, they need to make sure that all content has IPv6 - so that as end users access that content, they have IPv6 access all the way through. IPv6 doesn't use RFC1918 addresses - all IPv6 addresses are unique. We are running out of IPv4. Yes - some resources will still need IPv4 addresses - so let's stretch what we have out. The IPv4 Soft Landing proposal helps this stretching process - by forcing IPv6 onto LIR's/ ISP's. So I support the Proposal. It may not be perfect but it will help shape the African Internet Industry further into the right direction. -- Mark James ELKINS - Posix Systems - (South) Africa mje at posix.co.za Tel: +27.826010496 For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From diroikaralis at gmail.com Wed Jul 22 14:23:35 2026 From: diroikaralis at gmail.com (Diroi Karalis) Date: Wed, 22 Jul 2026 16:23:35 +0200 Subject: [rpd] Subject: Re: Policy supremacy Message-ID: Hi Jaco, Fair question, and I don't think it's an unreasonable one. If the community wants to explore universal, equally-applied identification for RPD subscription new and existing alike that's a legitimate policy discussion to have, on its own track, with its own proposal, safeguards, and debate about scope (including how far affiliation checks should go, which is a real privacy question, not a small one). But that's a separate conversation from the one in front of us. Whatever happens with KYC in the future, it doesn't change what's needed right now: Tshepo and Gugu's objections need to be assessed on their merits today, not shelved pending a policy that doesn't exist yet. Raising the KYC question is fine, using its absence as a reason to discount their input isn't. On the AI point. Noted, and fair enough. If anything reads as noise rather than substance, call it out specifically. Regards, Diroi -------------- next part -------------- An HTML attachment was scrubbed... URL: From mguqulwazenalo at gmail.com Wed Jul 22 14:23:34 2026 From: mguqulwazenalo at gmail.com (Zenalo Mguqulwa) Date: Wed, 22 Jul 2026 16:23:34 +0200 Subject: [rpd] Policy supremacy In-Reply-To: References: Message-ID: Hi, I don't believe introducing identity verification is the right solution. The platform should remain open and accessible to anyone who wishes to participate. What matters is the quality of the argument, not who makes it. If participants choose to share their background or affiliations, that's entirely their decision, but it should never become a requirement for taking part. The same applies to AI. Its use is only going to become more common, and that in itself isn't a problem. The focus should remain on whether contributions are constructive, evidence-based, and engage with the discussion. Kind regards, Zen On Wed, 22 Jul 2026 at 16:12, wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: Policy supremacy (Jaco Kroon) > 2. Re: RPD Digest, Vol 222, Issue 158 (Fundiswa Nadia Maseko) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 22 Jul 2026 16:01:03 +0200 > From: Jaco Kroon > To: rpd at afrinic.net > Subject: Re: [rpd] Policy supremacy > Message-ID: <14936a5e-6d1e-4e4b-8957-b0e2018274aa at uls.co.za> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi, > > Are we thus proposing that each and every person must positively > identify themselves prior to being subscribed to the RPD list, as well > as for all existing subscribers to be positively identified by date X or > be unsubscribed?? To what extend should this identification go - should > it include affiliation checking, eg, Jaco Kroon actually JK19-AFRINIC in > the whois db - from where you can track the networks I'm involved with? > > I'd be in support of such a policy change/direction. > > Regarding use of AI, I don't have a particular objection to the use of > LLMs (but having worked on the Comp-Sci side of things ... I would not > trust them without validating whatever they spit out - and recent > experience - not restricted to this ML - shows they spit out more > garbage than most community-driven support forums), as long as they're > used sensibly to help with formatting and/or interpretation of emails, > not to spew out noise for the sake of noise - as what it feels has been > done the last week or two. > > Kind regards, > Jaco > > n 2026/07/22 15:52, Diroi Karalis wrote: > > > Dear Musa, > > > > Tshepo and Gugu don't need prior recognition from established > > participants before their input counts. Joining recently, missing > > earlier meetings, or sharing similar views is not evidence of > > impersonation or bad faith. Anyone is entitled to join an open process > > at Last Call and raise objections before a proposal becomes policy. > > KYC would be a significant procedural and privacy change. It can't be > > applied selectively to objectors we don't recognize it would need a > > formal basis, a clear justification, proper safeguards, and equal > > application to every participant, not just the inconvenient ones. > > If you have evidence of misconduct, send it to the co-chairs. > > Otherwise, engage with Tshepo and Gugu's arguments on their merits. > > Familiarity isn't authority, and "the community" isn't a closed circle > > that gets to decide who's allowed in. > > > > Regards, > > Diroi > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > ------------------------------ > > Message: 2 > Date: Wed, 22 Jul 2026 16:11:08 +0200 > From: Fundiswa Nadia Maseko > To: rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 158 > Message-ID: > rbjfBJEesLOjvV_f1OTFkeiLpGj0Q at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi everyone, > > I understand the concerns being raised about AI and new participants > joining the discussion. However, I don't think we should discourage people > from participating simply because they are new or because they choose to > use AI as a writing aid. > > AI can help people organize their thoughts, improve grammar, or communicate > more clearly, but it shouldn't replace independent thinking. What matters > most is whether the ideas being presented are relevant, technically sound, > and contribute meaningfully to the policy discussion. > > The PDP has always been intended to be open and inclusive. New participants > should be encouraged to engage, provided they do so respectfully and in > good faith. If there are concerns about duplicate messages or coordinated > submissions, those can be addressed based on evidence rather than > assumptions about individuals. > > I believe we should continue evaluating contributions on their merit and > keep the discussion focused on the policy itself. > > Kind regards, > > Fundiswa Nadia Maseko > > On Wed, 22 Jul 2026, 15:53 , wrote: > > > Send RPD mailing list submissions to > > rpd at afrinic.net > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.afrinic.net/mailman/listinfo/rpd > > or, via email, send a message with subject or body 'help' to > > rpd-request at afrinic.net > > > > You can reach the person managing the list at > > rpd-owner at afrinic.net > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of RPD digest..." > > > > > > Today's Topics: > > > > 1. Re: Policy supremacy (Nonjabulo Sphilile) > > 2. Re: The usage of AI in platforms (JP) > > 3. Re: Policy supremacy (Diroi Karalis) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Wed, 22 Jul 2026 15:45:19 +0200 > > From: Nonjabulo Sphilile > > To: rpd at afrinic.net > > Subject: Re: [rpd] Policy supremacy > > Message-ID: > > > aWw6YqZVRZ51DVEdpsQ3xfRar0XmgPedHLruA at mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > Hi Musa, > > > > The PDWG is open. Participation does not depend on being known to > > long-standing members, attending earlier meetings, or proving a > > professional stake after joining. New participation is still > participation. > > > > KYC would be a serious procedural change, not an informal test for > > unfamiliar objectors. Any such requirement would need to be formally > > adopted, proportionate, privacy-preserving, and applied equally to > > established and new participants. > > > > Similar views are not proof of impersonation. If there is concrete > evidence > > of misconduct, please submit it to the co-chairs. Otherwise, I will not > > continue discussing identities or drafting methods. > > > > Let us return to the policy. > > > > Regards, > > Nonjabulo > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/1992795c/attachment-0001.html > > > > > > > ------------------------------ > > > > Message: 2 > > Date: Wed, 22 Jul 2026 15:51:18 +0200 > > From: JP > > To: rpd at afrinic.net > > Subject: Re: [rpd] The usage of AI in platforms > > Message-ID: > > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > > On 22 Jul 2026, at 12:15, Mzwakhe Mabasa via RPD wrote: > > > > > Good day.I would like to post to the RPD mailing list. Kindly allow me > > > this opportunity of being part of the RPD afrinic policy decisions.? > > > > > > While AI is widely used across the internet, its acceptability > > > depends on the specific platform you are referring to . Most social > > > networks allow AI assistance, but require the clear labeling of > > > AI-generated imagery and ban non-consensual deepfakes or harmful > > > content.?LSince platform policies vary greatly, here is a breakdown > > > of how the most popular services handle AI usage: > > > > > > - Social Media (Facebook, Instagram, TikTok, YouTube): Generally > > > allowed, but social media algorithms penalize low-quality, generic > > > content. Major platforms are shifting to automatic detection and > > > require synthetic imagery to be appropriately labeled to avoid > > > misinformation penalties.? > > > > > > - Design & Creative Platforms (Canva): AI usage for brainstorming > > > and generating designs is permitted, but platforms typically place > > > operational limits on how much AI content you can generate per month. > > > Users are responsible for ensuring AI outputs do not mislead others > > > and are used in accordance with local copyright laws.? > > > > > > - AI Generation Models (Open AI, Midjourney): AI tools are > > > permitted, but they enforce strict universal policies. You cannot use > > > these services for harassment, defamation, or generating unauthorized > > > deepfakes of real people > > > > to play off an older joke: > > > > q: ?how do you know someone?s using LLMs?? > > a: ?they?ll damn well tell you? > > > > normally I don?t need to pay much attention to rpd because things > > don?t move that much, and then the last week? the sloppist tsunami > > has been quite notable. and it?s near all this kind of milquetoast > > nonsense gibberish. I saw someone else mention the astroturfing > > component of things too (and a cursory investigation around the poster > > domains for the most vocal proponents there had me raising my eyebrows > > most spock-like) but I?ll leave that aside for now > > > > it?s probably worth rpd considering a full and complete ban on > > prompt-generation and prompt-assistance for use on the policy list, with > > possibly a poster cooldown/block period (and some way to deal with > > repeat offenders and ban evasion). > > > > there?s both precedent and strong arguments in favour > > > > precedent: a number of other public-benefit and mass-cooperation > > organisations and projects have taken to the hardline block (the most > > notable is codeberg, as of earlier today) > > > > arguments: the most obvious is exactly what has happened in the last > > week (and the alternative of no ban is an utter deluge of worthless > > noise, which will space-fill as far as it can go). there is also ample > > evidence across multiple years and multiple studies that these > > technologies are _bad_ at fine detail, and that?s exactly the sort of > > thing that is very ill-fitting in the context of what rpd is to be doing > > > > -J > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/f83dfe25/attachment-0001.html > > > > > > > ------------------------------ > > > > Message: 3 > > Date: Wed, 22 Jul 2026 15:52:40 +0200 > > From: Diroi Karalis > > To: rpd at afrinic.net > > Subject: Re: [rpd] Policy supremacy > > Message-ID: > > < > > CA+wt7VoZ2hQyw6ZiGAAxr-SRTmXaYwjM-xD_aknC2tj+Oqhdig at mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > Dear Musa, > > > > Tshepo and Gugu don't need prior recognition from established > participants > > before their input counts. Joining recently, missing earlier meetings, or > > sharing similar views is not evidence of impersonation or bad faith. > Anyone > > is entitled to join an open process at Last Call and raise objections > > before a proposal becomes policy. > > KYC would be a significant procedural and privacy change. It can't be > > applied selectively to objectors we don't recognize it would need a > formal > > basis, a clear justification, proper safeguards, and equal application to > > every participant, not just the inconvenient ones. > > If you have evidence of misconduct, send it to the co-chairs. Otherwise, > > engage with Tshepo and Gugu's arguments on their merits. Familiarity > isn't > > authority, and "the community" isn't a closed circle that gets to decide > > who's allowed in. > > > > Regards, > > Diroi > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/7c67f9fd/attachment.html > > > > > > > ------------------------------ > > > > Subject: Digest Footer > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > ------------------------------ > > > > End of RPD Digest, Vol 222, Issue 158 > > ************************************* > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/ba32bf97/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 159 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emmanuelmabasa1 at yahoo.com Wed Jul 22 14:25:03 2026 From: emmanuelmabasa1 at yahoo.com (Mzwakhe Mabasa) Date: Wed, 22 Jul 2026 14:25:03 +0000 (UTC) Subject: [rpd] Subject (RPD) the usage of AI in platforms. References: <480570663.1903609.1784730303585.ref@mail.yahoo.com> Message-ID: <480570663.1903609.1784730303585@mail.yahoo.com> Yahoo Mail: Search, Organize, Conquer ?Platforms use AI to automate tasks, personalize user experiences, and analyze large datasets. Businesses utilize AI to improve productivity and efficiency, offering tools like chatbots, recommendation engines, and predictive analytics. Major platforms build and deploy these capabilities using comprehensive infrastructure. The integration of artificial intelligence spans several types of platforms : Enterprise AI Platforms: Tools like Google Vertex AI, Microsoft Azure AI, Amazon SageMaker, and Databricks allow businesses to build, train, and deploy custom machine learning models and handle data orchestration. Social Media & Consumer Platforms: These services use algorithms to curate personalized content feeds, target advertising, and keep users engaged. Productivity & Content Creation: Applications like Notion AI, Grammarly, and various AI video or image generation platforms help automate writing, summarization, and creative tasks.Customer Support: AI-powered bots and voice agents automate interactions, triage tickets, and resolve routine customer inquiries autonomously. All applications are AI generated.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From NPertuniaPetronella at outlook.com Wed Jul 22 14:29:10 2026 From: NPertuniaPetronella at outlook.com (NP Petronella) Date: Wed, 22 Jul 2026 14:29:10 +0000 Subject: [rpd] Policy supremacy Message-ID: Dear Colleagues, I agree with Mike. An open PDP should assess the argument, not the reputation, affiliation, or familiarity of the person raising it. Introductions may be offered voluntarily, but they must not become an entrance requirement. The same applies to AI-assisted writing: moderate actual flooding or abuse, but judge ordinary contributions on their substance. Participation should remain open. Familiarity does not create authority to decide who belongs. Regards, Nonhlanhla -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Wed Jul 22 14:29:12 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Wed, 22 Jul 2026 16:29:12 +0200 Subject: [rpd] Policy supremacy In-Reply-To: References: Message-ID: <90EFCCB5-B770-49BE-B1A8-B5412FFBAD7B@afrinic.net> An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Wed Jul 22 14:32:07 2026 From: jordi.palet at consulintel.es (jordi.palet at consulintel.es) Date: Wed, 22 Jul 2026 16:32:07 +0200 Subject: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 In-Reply-To: References: <74208ec3-0053-4c39-a87e-70d58054fd5e@uls.co.za> <97C503F6-EE5F-4743-BBBC-C2FEDDD55D35@afrinic.net> Message-ID: Hi Saul, Configuring a routable IPv6 prefix in the WAN, doesn?t enforce the clients to use it. All depends on if then those prefixes are activated with SLAAC in the LANs. There are many protocols that are configured in any network towards the CPE and the customer is not using them, IPv6 will be one more in those cases. And yes, that?s definitively sad, and ugly. Sooner or later those customers will become a problem. I recall when Telefonica wanted to retire the old rotary phones, because the cost of keeping the PBXs with those was much higher than using DTMF. Finally they decided to send a letter telling the customers that the contract will not be renewed because they actually mean losses. Regards, Jordi @jordipalet > El 22 jul 2026, a las 16:22, Saul Stein escribi?: > > HI Jordi, > > Most of my clients ACTIVELY DO NOT want IPv6 near their network. (very sad, but true) Thus this policy has commercial implications. > > I?ll agree that we need to make it available should they want, but nothing configured should be mandatory. > > Thanks > Saul > > > From: jordi.palet--- via RPD > > Sent: Wednesday, 22 July 2026 12:30 > To: rpd at afrinic.net > Subject: Re: [rpd] IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02 > > Hi Ben, > > Precisely what Jaco is suggesting is removing all that, and instead just asking that IPv6 prefix is provided to the CPE and routable, not traffic measurements needed. > > To avoid mixing the current Last Call discussion on the other proposals and not create additional noise, I decided to respond to all the points on this proposal once the LC ends. I will provide then a detailed review of the previous emails open this proposal and we can draft a new version. > > Tks! > > Regards, > Jordi > > @jordipalet > > > El 22 jul 2026, a las 12:06, Ben Roberts - AfriNIC > escribi?: > > Jaco, > I re-iterate that this kind of relatively sophisticated traffic destination analysis is beyond the technical capacity for many emerging ISPs and enterprise networks in continental Africa, and is just putting up unrealistic barriers to accessing IP addresses > > Cheers > > Ben > Sent from my iPhone > > > On 22 Jul 2026, at 11:30, Jaco Kroon via RPD > wrote: > > ? > Hi Jordi, Mark, > > After in-person discussion with Mark, I'd like to propose alternative wording for specifically this portion: > > "The IPv6 deployment plan must show the actual IPv4 top-25 traffic destinations of that network. For each of those external destinations > that are IPv6-enabled, the following minimum IPv6 % will be considered as compliant: > > "25% in a maximum of 12 months. > 50% in a maximum of 24 months. > 75% in a maximum of 48 months. > "In case of networks hosting any kind of services, applications or contents, will be considered as compliant when matching the following % of AAAA RRs available and IPv6 reachable from Internet: > > "25% in a maximum of 12 months. > 75% in a maximum of 24 months. > 95% in a maximum of 48 months. > > "Failure to comply with the IPv6 deployment plan according to the relevant criteria, constitutes a policy violation." > > As can be seen the author(s) already distinguish between access (eyeball) and hosting (content) networks. It does not make it clear in the case of hybrid networks here. For most larger networks this won't particularly matter since they are unlikely to be able to apply for additional /22s and even if they are /22s (as per in-person discussions with at least one network operator that makes me look like an extremely mild-mannered person) are not useful to them. > > Regardless, I feel that for access networks the measurement above is not well defined, nor sensible, as per discussion with Mark the measurement depends not only on your own behaviour but also that of external networks (be they customers or external content networks). Not discussed and which I only realised later on Monday after our discussion is that "actual IPv4 top-25 destinations" would *shift* as traffic moves to IPv6, which is to say that if *all* of my customers suddenly and unsuspectedly re-enable IPv6, then the likes of Google, Youtube, Cloudflare, Akamai, Meta and (AWS) won't be in our top-25 IPv4 destinations. Now my top-25 would start shifting to the likes of the banks, NTT, Xneelo, Hostafrica, Hetzner and probably other content hosting providers that are NOT IPv6 enabled (or not advertising that they are). Yes, I've been told that Xneelo does support IPv6 but I've yet to see a single site myself hosted on Xneelo side that has AAAA records deployed. As such, since this is a shifting target it cannot be a reliable measure. > > The measurements I would suggest: > > For access networks: The percentage of downstream networks/customers that has access to well-connected IPv6 should they so choose (well-connected in this sense means that the provided addresses are routable and reachable in the Internet's "DFZ"/Global routing table. To be clear: This doesn't mean they have to have it enabled downstream, just that it's available to the customer/network. > > This is something that can be easily shown/proven by any network. It would also (based on existing knowledge) force exactly those parties that are NOT currently deploying IPv6 to deploy. Yes, this includes some of our own downstream IPT and/or consulting customers who would score 0% on either measure. This would also allow us to raise the bar to a higher percentage such as the 95% as for content networks. > > This must not be a "made available on request" situation - and a customer should be in a position to obtain IPv6 via the usual configuration mechanisms, and RAs should be advertised standard to these downstream customers, and provide for managed DHCPv6 PD, including at least a set of DNS servers. > > My issue with hosting networks is that the network provider doesn't, in many (most) cases, also control DNS. And in a significant portion of cases the third-party IT providers just flatly refuse to deploy AAAA records. This ends up punishing a network operator for the behaviour of external parties. > > I thus suggest the following: > > "When applying for additional IPv4 space, the following conditions must be met as per the time frames from issuance of the first IPv6 space to LIRs and EUs, or {policy approval date}, whichever is later: > > In the case of access networks, the percentage of customers that has access to global IPv6 delegations without interference required from the Network Operator must be at or above the following thresholds: > > * 25 % within 12 months; > * 50 % within 24 months; > * 75 % within 36 months; > * 95 % within 48 months; > > For the avoidance of doubt: "without interference required from the Network Operator" means that routers directly upstream from access clients must permit IPv6CP in the case of PPP connections, and all upstream routers must actively transmit IPv6 Router-Advertisements, and in order to allow for such downstream customers to obtain Prefix Delegations, most likely by way of DHCPv6 PD, and the space must be reachable from the global routing table. > > In the case of content hosting network, the percentage of assigned IPv4 space assigned to those networks also covered by IPv6 assignments must reach: > > * 25 % within 12 months; > * 50 % within 24 months; > * 75 % within 36 months; > * 95 % within 48 months; > > For avoidance of doubt: Assigned IPv6 space must be reachable from the global routing table. > > In the case where a network provides both access and content hosting services, both criteria must be independently complied with." > > This would address my concerns, and I believe still force those networks looking to obtain additional space that have not yet deployed IPv6 to do so. > > I think linking this to traffic thresholds is a very bad idea. Especially if it's linked to specific top 25-IPv4 external sites. I suspect at least a few of those top external sites in our case would be banking sites - and NONE of the major banks in SA has any client-facing IPv6 deployed that I'm aware of - making it impossible for us to comply even if 100% of our customers has access to and are IPv6 enabled. I did have a discussion about this and DNSSEC with at least one such case yesterday, but I promise you nothing will come from that. > > One concern I still have is that the above implies every single piece of assigned address space can 100% clearly be categorised into access or hosting, which isn't always as clearly defined as one would like it to be, but I'd wager that in those cases one or the other will be the predominant purpose, and we can just use that purpose for those cases. This is something I'd leave to operational discretion to qualify at application/assessment time to be honest. As long as each piece of assigned space (ie, the minimum 90% usage) from the LIR/EU is classified into one of these categories. > > I hope this helps, and thanks for the chat Mark. > > Kind regards, > Jaco > > On 2026/07/20 10:30, Jaco Kroon via RPD wrote: > > Hi, > > I'm going to state this again - I support the principle but not the implementation. > > Specifically the way in which this links IPv4 requests to IPv6 *traffic levels* as a percentage, rather than percentage of network to which IPv6 has been deployed. > > I'm unable to sensibly force my customers to consume IPv6, no matter what. Further - we host a bunch of content which due to lack of external IPv6 deployment (specifically on MNO networks) brings down our overall level of network IPv6 thresholds. This in spite of but one single /29 subnet (which communicates exclusively with MNO networks, this might change in the next month, thus deploying IPv6 here until now made no sense, and this little subnet single-handedly carries around 5% of our ingress and ~30% of our egress bandwidth). > > As written this policy punishes network operators for bad behaviour of others, be it other access networks, or customers. > > It also adds significant additional costs towards otherwise needless network monitoring that would otherwise not be required. > > Again, to be clear: I'm in full support of the principle of linking IPv4 allocations/assignments to IPv6 deployment, I simply disagree with how it should be measured. > > Traffic levels are not a good measure. If 50% of my network is capable of IPv6, and 50% of content being accessed, or 50% of of eyeballs accessing my network are IPv6 capable, that puts my general IPv6 network levels around 25%, depending on exact patterns, possibly a bit higher, but no higher than 50%. Now our ability to access IPv4 resources is being limited by *others's* IPv6 deployment rather than merely our own. > > This should be measured as: > > What percentage of existing deployed IPv4 resources on the network also has IPv6 deployed in the case of content provisioning, and has access to IPv6 for downstream networks. > > For us the former percentage, having somewhere between a /22 and /23 provisioned for *services*, so let's work on a /23 or about 512 IPs with only a /29 not being IPv6 enabled as of right now is 98.5%, however, traffic patterns on access shows less than 5% of actual traffic is IPv6. > > For the latter, 100% of downstream customers/networks has *access* to IPv6. On customers using ppp less than 5% are consuming IPv6. At least a portion of these configures IPv6 LL (just over 30%). Once that happens we do actively send RAs to provoke configuration. > > For AE customers (Or "DHCP Customers") things looked better, as of right now we've got 43% active IPv6 customers (which shows that consumer routers are more inclined to grab IPv6 on "DHCP uplinks compared to PPP", however, this percentage used to be closer to 96%, as customers are *actively against recommendation insisting on switching OFF IPv6*. > > Whilst we are pushing we cannot prescribe to customers to keep IPv6 enabled - they'll simply move their business elsewhere if we push, thus this policy - as written - creates a significant operational issue. > > Kind regards, > Jaco > > On 2026/07/19 11:26, Mark Elkins via RPD wrote: > > Dear PDWG, > > I have two major concerns regarding the Internet in Africa. > > 1 - Lack of DNSSEC - for DNS security > > 2 - Lack of IPv6 - for growth > > I run something called the Observatory - https://observatory.dnsstudy.africa - which has in the past collected information such as how many domains there are, are they DNSSEC Signed and are they IPv6 accessible. > > So I want Domain content to be IPv6 Accessible... > > ISP's need to have IPv6 resources, they need to make sure that all content has IPv6 - so that as end users access that content, they have IPv6 access all the way through. IPv6 doesn't use RFC1918 addresses - all IPv6 addresses are unique. > > We are running out of IPv4. Yes - some resources will still need IPv4 addresses - so let's stretch what we have out. The IPv4 Soft Landing proposal helps this stretching process - by forcing IPv6 onto LIR's/ ISP's. > > So I support the Proposal. It may not be perfect but it will help shape the African Internet Industry further into the right direction. > > -- > Mark James ELKINS - Posix Systems - (South) Africa > mje at posix.co.za Tel: +27.826010496 > For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ********************************************** > IPv4 is over > Are you ready for the new Internet ? > http://www.theipv6company.com > The IPv6 Company > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Wed Jul 22 14:36:07 2026 From: mike at iptrading.com (Mike Burns) Date: Wed, 22 Jul 2026 10:36:07 -0400 Subject: [rpd] Policy supremacy In-Reply-To: <90EFCCB5-B770-49BE-B1A8-B5412FFBAD7B@afrinic.net> References: <90EFCCB5-B770-49BE-B1A8-B5412FFBAD7B@afrinic.net> Message-ID: <005d01dd19e7$6edbeef0$4c93ccd0$@iptrading.com> ?Strong arguments? so we must take action? From: Ben Roberts - AfriNIC via RPD Sent: Wednesday, July 22, 2026 10:29 AM To: Zenalo Mguqulwa Cc: rpd at afrinic.net Subject: Re: [rpd] Policy supremacy Zenalo and others, Your bombardment of us with strong arguments against identity verification, coming from completely new mailboxes on the list, are doing a good job of convincing me that we MUST actually introduced mandatory identity verification. Good job! Sent from my iPhone On 22 Jul 2026, at 16:24, Zenalo Mguqulwa > wrote: ? Hi, I don't believe introducing identity verification is the right solution. The platform should remain open and accessible to anyone who wishes to participate. What matters is the quality of the argument, not who makes it. If participants choose to share their background or affiliations, that's entirely their decision, but it should never become a requirement for taking part. The same applies to AI. Its use is only going to become more common, and that in itself isn't a problem. The focus should remain on whether contributions are constructive, evidence-based, and engage with the discussion. Kind regards, Zen On Wed, 22 Jul 2026 at 16:12, > wrote: Send RPD mailing list submissions to rpd at afrinic.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.afrinic.net/mailman/listinfo/rpd or, via email, send a message with subject or body 'help' to rpd-request at afrinic.net You can reach the person managing the list at rpd-owner at afrinic.net When replying, please edit your Subject line so it is more specific than "Re: Contents of RPD digest..." Today's Topics: 1. Re: Policy supremacy (Jaco Kroon) 2. Re: RPD Digest, Vol 222, Issue 158 (Fundiswa Nadia Maseko) ---------------------------------------------------------------------- Message: 1 Date: Wed, 22 Jul 2026 16:01:03 +0200 From: Jaco Kroon > To: rpd at afrinic.net Subject: Re: [rpd] Policy supremacy Message-ID: <14936a5e-6d1e-4e4b-8957-b0e2018274aa at uls.co.za > Content-Type: text/plain; charset=UTF-8; format=flowed Hi, Are we thus proposing that each and every person must positively identify themselves prior to being subscribed to the RPD list, as well as for all existing subscribers to be positively identified by date X or be unsubscribed?? To what extend should this identification go - should it include affiliation checking, eg, Jaco Kroon actually JK19-AFRINIC in the whois db - from where you can track the networks I'm involved with? I'd be in support of such a policy change/direction. Regarding use of AI, I don't have a particular objection to the use of LLMs (but having worked on the Comp-Sci side of things ... I would not trust them without validating whatever they spit out - and recent experience - not restricted to this ML - shows they spit out more garbage than most community-driven support forums), as long as they're used sensibly to help with formatting and/or interpretation of emails, not to spew out noise for the sake of noise - as what it feels has been done the last week or two. Kind regards, Jaco n 2026/07/22 15:52, Diroi Karalis wrote: > Dear Musa, > > Tshepo and Gugu don't need prior recognition from established > participants before their input counts. Joining recently, missing > earlier meetings, or sharing similar views is not evidence of > impersonation or bad faith. Anyone is entitled to join an open process > at Last Call and raise objections before a proposal becomes policy. > KYC would be a significant procedural and privacy change. It can't be > applied selectively to objectors we don't recognize it would need a > formal basis, a clear justification, proper safeguards, and equal > application to every participant, not just the inconvenient ones. > If you have evidence of misconduct, send it to the co-chairs. > Otherwise, engage with Tshepo and Gugu's arguments on their merits. > Familiarity isn't authority, and "the community" isn't a closed circle > that gets to decide who's allowed in. > > Regards, > Diroi > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ Message: 2 Date: Wed, 22 Jul 2026 16:11:08 +0200 From: Fundiswa Nadia Maseko To: rpd at afrinic.net Subject: Re: [rpd] RPD Digest, Vol 222, Issue 158 Message-ID: > Content-Type: text/plain; charset="utf-8" Hi everyone, I understand the concerns being raised about AI and new participants joining the discussion. However, I don't think we should discourage people from participating simply because they are new or because they choose to use AI as a writing aid. AI can help people organize their thoughts, improve grammar, or communicate more clearly, but it shouldn't replace independent thinking. What matters most is whether the ideas being presented are relevant, technically sound, and contribute meaningfully to the policy discussion. The PDP has always been intended to be open and inclusive. New participants should be encouraged to engage, provided they do so respectfully and in good faith. If there are concerns about duplicate messages or coordinated submissions, those can be addressed based on evidence rather than assumptions about individuals. I believe we should continue evaluating contributions on their merit and keep the discussion focused on the policy itself. Kind regards, Fundiswa Nadia Maseko On Wed, 22 Jul 2026, 15:53 , > wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: Policy supremacy (Nonjabulo Sphilile) > 2. Re: The usage of AI in platforms (JP) > 3. Re: Policy supremacy (Diroi Karalis) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 22 Jul 2026 15:45:19 +0200 > From: Nonjabulo Sphilile > > To: rpd at afrinic.net > Subject: Re: [rpd] Policy supremacy > Message-ID: > aWw6YqZVRZ51DVEdpsQ3xfRar0XmgPedHLruA at mail.gmail.com > > Content-Type: text/plain; charset="utf-8" > > Hi Musa, > > The PDWG is open. Participation does not depend on being known to > long-standing members, attending earlier meetings, or proving a > professional stake after joining. New participation is still participation. > > KYC would be a serious procedural change, not an informal test for > unfamiliar objectors. Any such requirement would need to be formally > adopted, proportionate, privacy-preserving, and applied equally to > established and new participants. > > Similar views are not proof of impersonation. If there is concrete evidence > of misconduct, please submit it to the co-chairs. Otherwise, I will not > continue discussing identities or drafting methods. > > Let us return to the policy. > > Regards, > Nonjabulo > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/1992795c/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Wed, 22 Jul 2026 15:51:18 +0200 > From: JP > > To: rpd at afrinic.net > Subject: Re: [rpd] The usage of AI in platforms > Message-ID: > > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > On 22 Jul 2026, at 12:15, Mzwakhe Mabasa via RPD wrote: > > > Good day.I would like to post to the RPD mailing list. Kindly allow me > > this opportunity of being part of the RPD afrinic policy decisions.? > > > > While AI is widely used across the internet, its acceptability > > depends on the specific platform you are referring to . Most social > > networks allow AI assistance, but require the clear labeling of > > AI-generated imagery and ban non-consensual deepfakes or harmful > > content.?LSince platform policies vary greatly, here is a breakdown > > of how the most popular services handle AI usage: > > > > - Social Media (Facebook, Instagram, TikTok, YouTube): Generally > > allowed, but social media algorithms penalize low-quality, generic > > content. Major platforms are shifting to automatic detection and > > require synthetic imagery to be appropriately labeled to avoid > > misinformation penalties.? > > > > - Design & Creative Platforms (Canva): AI usage for brainstorming > > and generating designs is permitted, but platforms typically place > > operational limits on how much AI content you can generate per month. > > Users are responsible for ensuring AI outputs do not mislead others > > and are used in accordance with local copyright laws.? > > > > - AI Generation Models (Open AI, Midjourney): AI tools are > > permitted, but they enforce strict universal policies. You cannot use > > these services for harassment, defamation, or generating unauthorized > > deepfakes of real people > > to play off an older joke: > > q: ?how do you know someone?s using LLMs?? > a: ?they?ll damn well tell you? > > normally I don?t need to pay much attention to rpd because things > don?t move that much, and then the last week? the sloppist tsunami > has been quite notable. and it?s near all this kind of milquetoast > nonsense gibberish. I saw someone else mention the astroturfing > component of things too (and a cursory investigation around the poster > domains for the most vocal proponents there had me raising my eyebrows > most spock-like) but I?ll leave that aside for now > > it?s probably worth rpd considering a full and complete ban on > prompt-generation and prompt-assistance for use on the policy list, with > possibly a poster cooldown/block period (and some way to deal with > repeat offenders and ban evasion). > > there?s both precedent and strong arguments in favour > > precedent: a number of other public-benefit and mass-cooperation > organisations and projects have taken to the hardline block (the most > notable is codeberg, as of earlier today) > > arguments: the most obvious is exactly what has happened in the last > week (and the alternative of no ban is an utter deluge of worthless > noise, which will space-fill as far as it can go). there is also ample > evidence across multiple years and multiple studies that these > technologies are _bad_ at fine detail, and that?s exactly the sort of > thing that is very ill-fitting in the context of what rpd is to be doing > > -J > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/f83dfe25/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Wed, 22 Jul 2026 15:52:40 +0200 > From: Diroi Karalis > > To: rpd at afrinic.net > Subject: Re: [rpd] Policy supremacy > Message-ID: > < > CA+wt7VoZ2hQyw6ZiGAAxr-SRTmXaYwjM-xD_aknC2tj+Oqhdig at mail.gmail.com > > Content-Type: text/plain; charset="utf-8" > > Dear Musa, > > Tshepo and Gugu don't need prior recognition from established participants > before their input counts. Joining recently, missing earlier meetings, or > sharing similar views is not evidence of impersonation or bad faith. Anyone > is entitled to join an open process at Last Call and raise objections > before a proposal becomes policy. > KYC would be a significant procedural and privacy change. It can't be > applied selectively to objectors we don't recognize it would need a formal > basis, a clear justification, proper safeguards, and equal application to > every participant, not just the inconvenient ones. > If you have evidence of misconduct, send it to the co-chairs. Otherwise, > engage with Tshepo and Gugu's arguments on their merits. Familiarity isn't > authority, and "the community" isn't a closed circle that gets to decide > who's allowed in. > > Regards, > Diroi > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/7c67f9fd/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 158 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ End of RPD Digest, Vol 222, Issue 159 ************************************* _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From NPertuniaPetronella at outlook.com Wed Jul 22 14:37:37 2026 From: NPertuniaPetronella at outlook.com (NP Petronella) Date: Wed, 22 Jul 2026 14:37:37 +0000 Subject: [rpd] Policy supremacy Message-ID: Dear colleagues, That reasoning is circular: because unfamiliar participants object to mandatory identity verification, their objection is treated as proof that verification is necessary. New mailboxes and shared concerns do not establish impersonation. Message volume can be managed through moderation and consolidation. If there is actual evidence of false identity or abuse, submit it to the co-chairs. Mandatory verification would require a formal proposal, demonstrated necessity, privacy safeguards, and equal application to every participant. It cannot be improvised as an entrance test for people whose views are unpopular. Turning a traffic concern into authority to screen participants is not openness. It is mandate laundering. Regards, Nonhlanhla -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Wed Jul 22 14:42:02 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Wed, 22 Jul 2026 16:42:02 +0200 Subject: [rpd] Policy supremacy In-Reply-To: <005d01dd19e7$6edbeef0$4c93ccd0$@iptrading.com> References: <005d01dd19e7$6edbeef0$4c93ccd0$@iptrading.com> Message-ID: <1038A6B3-E375-41DD-A268-740FE02AC477@afrinic.net> An HTML attachment was scrubbed... URL: From mike at iptrading.com Wed Jul 22 14:49:11 2026 From: mike at iptrading.com (Mike Burns) Date: Wed, 22 Jul 2026 10:49:11 -0400 Subject: [rpd] Policy supremacy In-Reply-To: <1038A6B3-E375-41DD-A268-740FE02AC477@afrinic.net> References: <005d01dd19e7$6edbeef0$4c93ccd0$@iptrading.com> <1038A6B3-E375-41DD-A268-740FE02AC477@afrinic.net> Message-ID: <006d01dd19e9$41defcb0$c59cf610$@iptrading.com> I agree. They are using, well, I wouldn?t call it eloquent, but prompt driven words against a policy proposal. I don?t see anything wrong in that, certainly nothing that would shake the foundations of an open stakeholder policy forum. Regards, Mike From: Ben Roberts - AfriNIC Sent: Wednesday, July 22, 2026 10:42 AM To: Mike Burns Cc: Zenalo Mguqulwa ; rpd at afrinic.net Subject: Re: [rpd] Policy supremacy Mike, The strength of wordy arguments coming at us arguing against (human) identity verification, from unknown mailboxes, seems to serve as proof that the mailboxes are in fact AI agent automatons (like Openclaw instances) and not human at all. Hence a very good argument for the thing they are writing eloquent prompt driven words against. Kind regards Ben. Sent from my iPhone On 22 Jul 2026, at 16:36, Mike Burns > wrote: ? ?Strong arguments? so we must take action? From: Ben Roberts - AfriNIC via RPD > Sent: Wednesday, July 22, 2026 10:29 AM To: Zenalo Mguqulwa > Cc: rpd at afrinic.net Subject: Re: [rpd] Policy supremacy Zenalo and others, Your bombardment of us with strong arguments against identity verification, coming from completely new mailboxes on the list, are doing a good job of convincing me that we MUST actually introduced mandatory identity verification. Good job! Sent from my iPhone On 22 Jul 2026, at 16:24, Zenalo Mguqulwa > wrote: ? Hi, I don't believe introducing identity verification is the right solution. The platform should remain open and accessible to anyone who wishes to participate. What matters is the quality of the argument, not who makes it. If participants choose to share their background or affiliations, that's entirely their decision, but it should never become a requirement for taking part. The same applies to AI. Its use is only going to become more common, and that in itself isn't a problem. The focus should remain on whether contributions are constructive, evidence-based, and engage with the discussion. Kind regards, Zen On Wed, 22 Jul 2026 at 16:12, > wrote: Send RPD mailing list submissions to rpd at afrinic.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.afrinic.net/mailman/listinfo/rpd or, via email, send a message with subject or body 'help' to rpd-request at afrinic.net You can reach the person managing the list at rpd-owner at afrinic.net When replying, please edit your Subject line so it is more specific than "Re: Contents of RPD digest..." Today's Topics: 1. Re: Policy supremacy (Jaco Kroon) 2. Re: RPD Digest, Vol 222, Issue 158 (Fundiswa Nadia Maseko) ---------------------------------------------------------------------- Message: 1 Date: Wed, 22 Jul 2026 16:01:03 +0200 From: Jaco Kroon > To: rpd at afrinic.net Subject: Re: [rpd] Policy supremacy Message-ID: <14936a5e-6d1e-4e4b-8957-b0e2018274aa at uls.co.za > Content-Type: text/plain; charset=UTF-8; format=flowed Hi, Are we thus proposing that each and every person must positively identify themselves prior to being subscribed to the RPD list, as well as for all existing subscribers to be positively identified by date X or be unsubscribed?? To what extend should this identification go - should it include affiliation checking, eg, Jaco Kroon actually JK19-AFRINIC in the whois db - from where you can track the networks I'm involved with? I'd be in support of such a policy change/direction. Regarding use of AI, I don't have a particular objection to the use of LLMs (but having worked on the Comp-Sci side of things ... I would not trust them without validating whatever they spit out - and recent experience - not restricted to this ML - shows they spit out more garbage than most community-driven support forums), as long as they're used sensibly to help with formatting and/or interpretation of emails, not to spew out noise for the sake of noise - as what it feels has been done the last week or two. Kind regards, Jaco n 2026/07/22 15:52, Diroi Karalis wrote: > Dear Musa, > > Tshepo and Gugu don't need prior recognition from established > participants before their input counts. Joining recently, missing > earlier meetings, or sharing similar views is not evidence of > impersonation or bad faith. Anyone is entitled to join an open process > at Last Call and raise objections before a proposal becomes policy. > KYC would be a significant procedural and privacy change. It can't be > applied selectively to objectors we don't recognize it would need a > formal basis, a clear justification, proper safeguards, and equal > application to every participant, not just the inconvenient ones. > If you have evidence of misconduct, send it to the co-chairs. > Otherwise, engage with Tshepo and Gugu's arguments on their merits. > Familiarity isn't authority, and "the community" isn't a closed circle > that gets to decide who's allowed in. > > Regards, > Diroi > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ Message: 2 Date: Wed, 22 Jul 2026 16:11:08 +0200 From: Fundiswa Nadia Maseko > To: rpd at afrinic.net Subject: Re: [rpd] RPD Digest, Vol 222, Issue 158 Message-ID: > Content-Type: text/plain; charset="utf-8" Hi everyone, I understand the concerns being raised about AI and new participants joining the discussion. However, I don't think we should discourage people from participating simply because they are new or because they choose to use AI as a writing aid. AI can help people organize their thoughts, improve grammar, or communicate more clearly, but it shouldn't replace independent thinking. What matters most is whether the ideas being presented are relevant, technically sound, and contribute meaningfully to the policy discussion. The PDP has always been intended to be open and inclusive. New participants should be encouraged to engage, provided they do so respectfully and in good faith. If there are concerns about duplicate messages or coordinated submissions, those can be addressed based on evidence rather than assumptions about individuals. I believe we should continue evaluating contributions on their merit and keep the discussion focused on the policy itself. Kind regards, Fundiswa Nadia Maseko On Wed, 22 Jul 2026, 15:53 , > wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: Policy supremacy (Nonjabulo Sphilile) > 2. Re: The usage of AI in platforms (JP) > 3. Re: Policy supremacy (Diroi Karalis) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 22 Jul 2026 15:45:19 +0200 > From: Nonjabulo Sphilile > > To: rpd at afrinic.net > Subject: Re: [rpd] Policy supremacy > Message-ID: > aWw6YqZVRZ51DVEdpsQ3xfRar0XmgPedHLruA at mail.gmail.com > > Content-Type: text/plain; charset="utf-8" > > Hi Musa, > > The PDWG is open. Participation does not depend on being known to > long-standing members, attending earlier meetings, or proving a > professional stake after joining. New participation is still participation. > > KYC would be a serious procedural change, not an informal test for > unfamiliar objectors. Any such requirement would need to be formally > adopted, proportionate, privacy-preserving, and applied equally to > established and new participants. > > Similar views are not proof of impersonation. If there is concrete evidence > of misconduct, please submit it to the co-chairs. Otherwise, I will not > continue discussing identities or drafting methods. > > Let us return to the policy. > > Regards, > Nonjabulo > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/1992795c/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Wed, 22 Jul 2026 15:51:18 +0200 > From: JP > > To: rpd at afrinic.net > Subject: Re: [rpd] The usage of AI in platforms > Message-ID: > > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > On 22 Jul 2026, at 12:15, Mzwakhe Mabasa via RPD wrote: > > > Good day.I would like to post to the RPD mailing list. Kindly allow me > > this opportunity of being part of the RPD afrinic policy decisions.? > > > > While AI is widely used across the internet, its acceptability > > depends on the specific platform you are referring to . Most social > > networks allow AI assistance, but require the clear labeling of > > AI-generated imagery and ban non-consensual deepfakes or harmful > > content.?LSince platform policies vary greatly, here is a breakdown > > of how the most popular services handle AI usage: > > > > - Social Media (Facebook, Instagram, TikTok, YouTube): Generally > > allowed, but social media algorithms penalize low-quality, generic > > content. Major platforms are shifting to automatic detection and > > require synthetic imagery to be appropriately labeled to avoid > > misinformation penalties.? > > > > - Design & Creative Platforms (Canva): AI usage for brainstorming > > and generating designs is permitted, but platforms typically place > > operational limits on how much AI content you can generate per month. > > Users are responsible for ensuring AI outputs do not mislead others > > and are used in accordance with local copyright laws.? > > > > - AI Generation Models (Open AI, Midjourney): AI tools are > > permitted, but they enforce strict universal policies. You cannot use > > these services for harassment, defamation, or generating unauthorized > > deepfakes of real people > > to play off an older joke: > > q: ?how do you know someone?s using LLMs?? > a: ?they?ll damn well tell you? > > normally I don?t need to pay much attention to rpd because things > don?t move that much, and then the last week? the sloppist tsunami > has been quite notable. and it?s near all this kind of milquetoast > nonsense gibberish. I saw someone else mention the astroturfing > component of things too (and a cursory investigation around the poster > domains for the most vocal proponents there had me raising my eyebrows > most spock-like) but I?ll leave that aside for now > > it?s probably worth rpd considering a full and complete ban on > prompt-generation and prompt-assistance for use on the policy list, with > possibly a poster cooldown/block period (and some way to deal with > repeat offenders and ban evasion). > > there?s both precedent and strong arguments in favour > > precedent: a number of other public-benefit and mass-cooperation > organisations and projects have taken to the hardline block (the most > notable is codeberg, as of earlier today) > > arguments: the most obvious is exactly what has happened in the last > week (and the alternative of no ban is an utter deluge of worthless > noise, which will space-fill as far as it can go). there is also ample > evidence across multiple years and multiple studies that these > technologies are _bad_ at fine detail, and that?s exactly the sort of > thing that is very ill-fitting in the context of what rpd is to be doing > > -J > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/f83dfe25/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Wed, 22 Jul 2026 15:52:40 +0200 > From: Diroi Karalis > > To: rpd at afrinic.net > Subject: Re: [rpd] Policy supremacy > Message-ID: > < > CA+wt7VoZ2hQyw6ZiGAAxr-SRTmXaYwjM-xD_aknC2tj+Oqhdig at mail.gmail.com > > Content-Type: text/plain; charset="utf-8" > > Dear Musa, > > Tshepo and Gugu don't need prior recognition from established participants > before their input counts. Joining recently, missing earlier meetings, or > sharing similar views is not evidence of impersonation or bad faith. Anyone > is entitled to join an open process at Last Call and raise objections > before a proposal becomes policy. > KYC would be a significant procedural and privacy change. It can't be > applied selectively to objectors we don't recognize it would need a formal > basis, a clear justification, proper safeguards, and equal application to > every participant, not just the inconvenient ones. > If you have evidence of misconduct, send it to the co-chairs. Otherwise, > engage with Tshepo and Gugu's arguments on their merits. Familiarity isn't > authority, and "the community" isn't a closed circle that gets to decide > who's allowed in. > > Regards, > Diroi > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/7c67f9fd/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 158 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ End of RPD Digest, Vol 222, Issue 159 ************************************* _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From mguqulwazenalo at gmail.com Wed Jul 22 14:52:24 2026 From: mguqulwazenalo at gmail.com (Zenalo Mguqulwa) Date: Wed, 22 Jul 2026 16:52:24 +0200 Subject: [rpd] Policy supremacy In-Reply-To: <006d01dd19e9$41defcb0$c59cf610$@iptrading.com> References: <005d01dd19e7$6edbeef0$4c93ccd0$@iptrading.com> <1038A6B3-E375-41DD-A268-740FE02AC477@afrinic.net> <006d01dd19e9$41defcb0$c59cf610$@iptrading.com> Message-ID: Hi Ben, You're correct. Let me rephrase my earlier comment. I'm not opposed to identity verification itself. If the community believes it would improve transparency and accountability in the PDP, then I'm open to that discussion. My point was that I don't think it should be introduced simply as a reaction to a particular proposal attracting new participants or a large number of objections. It should be considered on its own merits through the normal community process. In the meantime, AFRINIC's current framework states that anyone with an interest in AFRINIC is welcome to participate, so I believe contributions should continue to be assessed on their merits. Regards, Zenalo On Wed, 22 Jul 2026 at 16:49, Mike Burns wrote: > I agree. They are using, well, I wouldn?t call it eloquent, but prompt > driven words against a policy proposal. > > I don?t see anything wrong in that, certainly nothing that would shake the > foundations of an open stakeholder policy forum. > > > > Regards, > Mike > > > > > > *From:* Ben Roberts - AfriNIC > *Sent:* Wednesday, July 22, 2026 10:42 AM > *To:* Mike Burns > *Cc:* Zenalo Mguqulwa ; rpd at afrinic.net > *Subject:* Re: [rpd] Policy supremacy > > > > Mike, > > The strength of wordy arguments coming at us arguing against (human) > identity verification, from unknown mailboxes, seems to serve as proof that > the mailboxes are in fact AI agent automatons (like Openclaw instances) > and not human at all. Hence a very good argument for the thing they are > writing eloquent prompt driven words against. > > > > Kind regards > > Ben. > > Sent from my iPhone > > > > On 22 Jul 2026, at 16:36, Mike Burns wrote: > > ? > > ?Strong arguments? so we must take action? > > > > *From:* Ben Roberts - AfriNIC via RPD > *Sent:* Wednesday, July 22, 2026 10:29 AM > *To:* Zenalo Mguqulwa > *Cc:* rpd at afrinic.net > *Subject:* Re: [rpd] Policy supremacy > > > > Zenalo and others, > > > > Your bombardment of us with strong arguments against identity > verification, coming from completely new mailboxes on the list, are doing a > good job of convincing me that we MUST actually introduced mandatory > identity verification. > > > > Good job! > > > > Sent from my iPhone > > > > > On 22 Jul 2026, at 16:24, Zenalo Mguqulwa > wrote: > > ? > > Hi, > > I don't believe introducing identity verification is the right solution. > The platform should remain open and accessible to anyone who wishes to > participate. > > What matters is the quality of the argument, not who makes it. If > participants choose to share their background or affiliations, that's > entirely their decision, but it should never become a requirement for > taking part. > > The same applies to AI. Its use is only going to become more common, and > that in itself isn't a problem. The focus should remain on whether > contributions are constructive, evidence-based, and engage with the > discussion. > > Kind regards, > > Zen > > On Wed, 22 Jul 2026 at 16:12, wrote: > > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: Policy supremacy (Jaco Kroon) > 2. Re: RPD Digest, Vol 222, Issue 158 (Fundiswa Nadia Maseko) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 22 Jul 2026 16:01:03 +0200 > From: Jaco Kroon > To: rpd at afrinic.net > Subject: Re: [rpd] Policy supremacy > Message-ID: <14936a5e-6d1e-4e4b-8957-b0e2018274aa at uls.co.za> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hi, > > Are we thus proposing that each and every person must positively > identify themselves prior to being subscribed to the RPD list, as well > as for all existing subscribers to be positively identified by date X or > be unsubscribed?? To what extend should this identification go - should > it include affiliation checking, eg, Jaco Kroon actually JK19-AFRINIC in > the whois db - from where you can track the networks I'm involved with? > > I'd be in support of such a policy change/direction. > > Regarding use of AI, I don't have a particular objection to the use of > LLMs (but having worked on the Comp-Sci side of things ... I would not > trust them without validating whatever they spit out - and recent > experience - not restricted to this ML - shows they spit out more > garbage than most community-driven support forums), as long as they're > used sensibly to help with formatting and/or interpretation of emails, > not to spew out noise for the sake of noise - as what it feels has been > done the last week or two. > > Kind regards, > Jaco > > n 2026/07/22 15:52, Diroi Karalis wrote: > > > Dear Musa, > > > > Tshepo and Gugu don't need prior recognition from established > > participants before their input counts. Joining recently, missing > > earlier meetings, or sharing similar views is not evidence of > > impersonation or bad faith. Anyone is entitled to join an open process > > at Last Call and raise objections before a proposal becomes policy. > > KYC would be a significant procedural and privacy change. It can't be > > applied selectively to objectors we don't recognize it would need a > > formal basis, a clear justification, proper safeguards, and equal > > application to every participant, not just the inconvenient ones. > > If you have evidence of misconduct, send it to the co-chairs. > > Otherwise, engage with Tshepo and Gugu's arguments on their merits. > > Familiarity isn't authority, and "the community" isn't a closed circle > > that gets to decide who's allowed in. > > > > Regards, > > Diroi > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > ------------------------------ > > Message: 2 > Date: Wed, 22 Jul 2026 16:11:08 +0200 > From: Fundiswa Nadia Maseko > To: rpd at afrinic.net > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 158 > Message-ID: > rbjfBJEesLOjvV_f1OTFkeiLpGj0Q at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi everyone, > > I understand the concerns being raised about AI and new participants > joining the discussion. However, I don't think we should discourage people > from participating simply because they are new or because they choose to > use AI as a writing aid. > > AI can help people organize their thoughts, improve grammar, or communicate > more clearly, but it shouldn't replace independent thinking. What matters > most is whether the ideas being presented are relevant, technically sound, > and contribute meaningfully to the policy discussion. > > The PDP has always been intended to be open and inclusive. New participants > should be encouraged to engage, provided they do so respectfully and in > good faith. If there are concerns about duplicate messages or coordinated > submissions, those can be addressed based on evidence rather than > assumptions about individuals. > > I believe we should continue evaluating contributions on their merit and > keep the discussion focused on the policy itself. > > Kind regards, > > Fundiswa Nadia Maseko > > On Wed, 22 Jul 2026, 15:53 , wrote: > > > Send RPD mailing list submissions to > > rpd at afrinic.net > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.afrinic.net/mailman/listinfo/rpd > > or, via email, send a message with subject or body 'help' to > > rpd-request at afrinic.net > > > > You can reach the person managing the list at > > rpd-owner at afrinic.net > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of RPD digest..." > > > > > > Today's Topics: > > > > 1. Re: Policy supremacy (Nonjabulo Sphilile) > > 2. Re: The usage of AI in platforms (JP) > > 3. Re: Policy supremacy (Diroi Karalis) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Wed, 22 Jul 2026 15:45:19 +0200 > > From: Nonjabulo Sphilile > > To: rpd at afrinic.net > > Subject: Re: [rpd] Policy supremacy > > Message-ID: > > > aWw6YqZVRZ51DVEdpsQ3xfRar0XmgPedHLruA at mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > Hi Musa, > > > > The PDWG is open. Participation does not depend on being known to > > long-standing members, attending earlier meetings, or proving a > > professional stake after joining. New participation is still > participation. > > > > KYC would be a serious procedural change, not an informal test for > > unfamiliar objectors. Any such requirement would need to be formally > > adopted, proportionate, privacy-preserving, and applied equally to > > established and new participants. > > > > Similar views are not proof of impersonation. If there is concrete > evidence > > of misconduct, please submit it to the co-chairs. Otherwise, I will not > > continue discussing identities or drafting methods. > > > > Let us return to the policy. > > > > Regards, > > Nonjabulo > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/1992795c/attachment-0001.html > > > > > > > ------------------------------ > > > > Message: 2 > > Date: Wed, 22 Jul 2026 15:51:18 +0200 > > From: JP > > To: rpd at afrinic.net > > Subject: Re: [rpd] The usage of AI in platforms > > Message-ID: > > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > > On 22 Jul 2026, at 12:15, Mzwakhe Mabasa via RPD wrote: > > > > > Good day.I would like to post to the RPD mailing list. Kindly allow me > > > this opportunity of being part of the RPD afrinic policy decisions.? > > > > > > While AI is widely used across the internet, its acceptability > > > depends on the specific platform you are referring to . Most social > > > networks allow AI assistance, but require the clear labeling of > > > AI-generated imagery and ban non-consensual deepfakes or harmful > > > content.?LSince platform policies vary greatly, here is a breakdown > > > of how the most popular services handle AI usage: > > > > > > - Social Media (Facebook, Instagram, TikTok, YouTube): Generally > > > allowed, but social media algorithms penalize low-quality, generic > > > content. Major platforms are shifting to automatic detection and > > > require synthetic imagery to be appropriately labeled to avoid > > > misinformation penalties.? > > > > > > - Design & Creative Platforms (Canva): AI usage for brainstorming > > > and generating designs is permitted, but platforms typically place > > > operational limits on how much AI content you can generate per month. > > > Users are responsible for ensuring AI outputs do not mislead others > > > and are used in accordance with local copyright laws.? > > > > > > - AI Generation Models (Open AI, Midjourney): AI tools are > > > permitted, but they enforce strict universal policies. You cannot use > > > these services for harassment, defamation, or generating unauthorized > > > deepfakes of real people > > > > to play off an older joke: > > > > q: ?how do you know someone?s using LLMs?? > > a: ?they?ll damn well tell you? > > > > normally I don?t need to pay much attention to rpd because things > > don?t move that much, and then the last week? the sloppist tsunami > > has been quite notable. and it?s near all this kind of milquetoast > > nonsense gibberish. I saw someone else mention the astroturfing > > component of things too (and a cursory investigation around the poster > > domains for the most vocal proponents there had me raising my eyebrows > > most spock-like) but I?ll leave that aside for now > > > > it?s probably worth rpd considering a full and complete ban on > > prompt-generation and prompt-assistance for use on the policy list, with > > possibly a poster cooldown/block period (and some way to deal with > > repeat offenders and ban evasion). > > > > there?s both precedent and strong arguments in favour > > > > precedent: a number of other public-benefit and mass-cooperation > > organisations and projects have taken to the hardline block (the most > > notable is codeberg, as of earlier today) > > > > arguments: the most obvious is exactly what has happened in the last > > week (and the alternative of no ban is an utter deluge of worthless > > noise, which will space-fill as far as it can go). there is also ample > > evidence across multiple years and multiple studies that these > > technologies are _bad_ at fine detail, and that?s exactly the sort of > > thing that is very ill-fitting in the context of what rpd is to be doing > > > > -J > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/f83dfe25/attachment-0001.html > > > > > > > ------------------------------ > > > > Message: 3 > > Date: Wed, 22 Jul 2026 15:52:40 +0200 > > From: Diroi Karalis > > To: rpd at afrinic.net > > Subject: Re: [rpd] Policy supremacy > > Message-ID: > > < > > CA+wt7VoZ2hQyw6ZiGAAxr-SRTmXaYwjM-xD_aknC2tj+Oqhdig at mail.gmail.com> > > Content-Type: text/plain; charset="utf-8" > > > > Dear Musa, > > > > Tshepo and Gugu don't need prior recognition from established > participants > > before their input counts. Joining recently, missing earlier meetings, or > > sharing similar views is not evidence of impersonation or bad faith. > Anyone > > is entitled to join an open process at Last Call and raise objections > > before a proposal becomes policy. > > KYC would be a significant procedural and privacy change. It can't be > > applied selectively to objectors we don't recognize it would need a > formal > > basis, a clear justification, proper safeguards, and equal application to > > every participant, not just the inconvenient ones. > > If you have evidence of misconduct, send it to the co-chairs. Otherwise, > > engage with Tshepo and Gugu's arguments on their merits. Familiarity > isn't > > authority, and "the community" isn't a closed circle that gets to decide > > who's allowed in. > > > > Regards, > > Diroi > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: < > > > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/7c67f9fd/attachment.html > > > > > > > ------------------------------ > > > > Subject: Digest Footer > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > > ------------------------------ > > > > End of RPD Digest, Vol 222, Issue 158 > > ************************************* > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/ba32bf97/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 159 > ************************************* > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From NPertuniaPetronella at outlook.com Wed Jul 22 14:53:06 2026 From: NPertuniaPetronella at outlook.com (NP Petronella) Date: Wed, 22 Jul 2026 14:53:06 +0000 Subject: [rpd] Policy supremacy Message-ID: Dear Ben, I support a 'neutral human-verification process', but not the conclusion you draw. Strong arguments from unfamiliar mailboxes are not proof that the accounts are automated. Any verification mechanism must be formally adopted, administered by the co-chairs or list operator, privacy-preserving, and applied equally to established and new participants. It should verify only that a real person controls the account. Otherwise, verification becomes mandate laundering: a small procedural circle converts suspicion into authority to decide who qualifies as ?the community.? Regards, Nonhlanhla -------------- next part -------------- An HTML attachment was scrubbed... URL: From aa at alstonnetworks.net Wed Jul 22 15:20:34 2026 From: aa at alstonnetworks.net (Andrew Alston) Date: Wed, 22 Jul 2026 18:20:34 +0300 Subject: [rpd] Policy supremacy In-Reply-To: References: <005d01dd19e7$6edbeef0$4c93ccd0$@iptrading.com> <1038A6B3-E375-41DD-A268-740FE02AC477@afrinic.net> <006d01dd19e9$41defcb0$c59cf610$@iptrading.com> Message-ID: Actually - just to set you straight - there has been one objection - made but multiple parties (human or otherwise) and multiple participants have addressed the objection directly - irrespective of if the multiple entities like the way it has been addressed or not. Andrew On Wed, Jul 22, 2026 at 17:53, Zenalo Mguqulwa wrote: > Hi Ben, > > You're correct. Let me rephrase my earlier comment. > > I'm not opposed to identity verification itself. If the community believes > it would improve transparency and accountability in the PDP, then I'm open > to that discussion. > > My point was that I don't think it should be introduced simply as a > reaction to a particular proposal attracting new participants or a large > number of objections. It should be considered on its own merits through the > normal community process. > > In the meantime, AFRINIC's current framework states that anyone with an > interest in AFRINIC is welcome to participate, so I believe contributions > should continue to be assessed on their merits. > > Regards, > > Zenalo > > On Wed, 22 Jul 2026 at 16:49, Mike Burns wrote: > >> I agree. They are using, well, I wouldn?t call it eloquent, but prompt >> driven words against a policy proposal. >> >> I don?t see anything wrong in that, certainly nothing that would shake >> the foundations of an open stakeholder policy forum. >> >> >> >> Regards, >> Mike >> >> >> >> >> >> *From:* Ben Roberts - AfriNIC >> *Sent:* Wednesday, July 22, 2026 10:42 AM >> *To:* Mike Burns >> *Cc:* Zenalo Mguqulwa ; rpd at afrinic.net >> *Subject:* Re: [rpd] Policy supremacy >> >> >> >> Mike, >> >> The strength of wordy arguments coming at us arguing against (human) >> identity verification, from unknown mailboxes, seems to serve as proof that >> the mailboxes are in fact AI agent automatons (like Openclaw instances) >> and not human at all. Hence a very good argument for the thing they are >> writing eloquent prompt driven words against. >> >> >> >> Kind regards >> >> Ben. >> >> Sent from my iPhone >> >> >> >> On 22 Jul 2026, at 16:36, Mike Burns wrote: >> >> ? >> >> ?Strong arguments? so we must take action? >> >> >> >> *From:* Ben Roberts - AfriNIC via RPD >> *Sent:* Wednesday, July 22, 2026 10:29 AM >> *To:* Zenalo Mguqulwa >> *Cc:* rpd at afrinic.net >> *Subject:* Re: [rpd] Policy supremacy >> >> >> >> Zenalo and others, >> >> >> >> Your bombardment of us with strong arguments against identity >> verification, coming from completely new mailboxes on the list, are doing a >> good job of convincing me that we MUST actually introduced mandatory >> identity verification. >> >> >> >> Good job! >> >> >> >> Sent from my iPhone >> >> >> >> >> On 22 Jul 2026, at 16:24, Zenalo Mguqulwa >> wrote: >> >> ? >> >> Hi, >> >> I don't believe introducing identity verification is the right solution. >> The platform should remain open and accessible to anyone who wishes to >> participate. >> >> What matters is the quality of the argument, not who makes it. If >> participants choose to share their background or affiliations, that's >> entirely their decision, but it should never become a requirement for >> taking part. >> >> The same applies to AI. Its use is only going to become more common, and >> that in itself isn't a problem. The focus should remain on whether >> contributions are constructive, evidence-based, and engage with the >> discussion. >> >> Kind regards, >> >> Zen >> >> On Wed, 22 Jul 2026 at 16:12, wrote: >> >> Send RPD mailing list submissions to >> rpd at afrinic.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.afrinic.net/mailman/listinfo/rpd >> or, via email, send a message with subject or body 'help' to >> rpd-request at afrinic.net >> >> You can reach the person managing the list at >> rpd-owner at afrinic.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of RPD digest..." >> >> >> Today's Topics: >> >> 1. Re: Policy supremacy (Jaco Kroon) >> 2. Re: RPD Digest, Vol 222, Issue 158 (Fundiswa Nadia Maseko) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Wed, 22 Jul 2026 16:01:03 +0200 >> From: Jaco Kroon >> To: rpd at afrinic.net >> Subject: Re: [rpd] Policy supremacy >> Message-ID: <14936a5e-6d1e-4e4b-8957-b0e2018274aa at uls.co.za> >> Content-Type: text/plain; charset=UTF-8; format=flowed >> >> Hi, >> >> Are we thus proposing that each and every person must positively >> identify themselves prior to being subscribed to the RPD list, as well >> as for all existing subscribers to be positively identified by date X or >> be unsubscribed?? To what extend should this identification go - should >> it include affiliation checking, eg, Jaco Kroon actually JK19-AFRINIC in >> the whois db - from where you can track the networks I'm involved with? >> >> I'd be in support of such a policy change/direction. >> >> Regarding use of AI, I don't have a particular objection to the use of >> LLMs (but having worked on the Comp-Sci side of things ... I would not >> trust them without validating whatever they spit out - and recent >> experience - not restricted to this ML - shows they spit out more >> garbage than most community-driven support forums), as long as they're >> used sensibly to help with formatting and/or interpretation of emails, >> not to spew out noise for the sake of noise - as what it feels has been >> done the last week or two. >> >> Kind regards, >> Jaco >> >> n 2026/07/22 15:52, Diroi Karalis wrote: >> >> > Dear Musa, >> > >> > Tshepo and Gugu don't need prior recognition from established >> > participants before their input counts. Joining recently, missing >> > earlier meetings, or sharing similar views is not evidence of >> > impersonation or bad faith. Anyone is entitled to join an open process >> > at Last Call and raise objections before a proposal becomes policy. >> > KYC would be a significant procedural and privacy change. It can't be >> > applied selectively to objectors we don't recognize it would need a >> > formal basis, a clear justification, proper safeguards, and equal >> > application to every participant, not just the inconvenient ones. >> > If you have evidence of misconduct, send it to the co-chairs. >> > Otherwise, engage with Tshepo and Gugu's arguments on their merits. >> > Familiarity isn't authority, and "the community" isn't a closed circle >> > that gets to decide who's allowed in. >> > >> > Regards, >> > Diroi >> > >> > _______________________________________________ >> > RPD mailing list >> > RPD at afrinic.net >> > https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> >> ------------------------------ >> >> Message: 2 >> Date: Wed, 22 Jul 2026 16:11:08 +0200 >> From: Fundiswa Nadia Maseko >> To: rpd at afrinic.net >> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 158 >> Message-ID: >> > rbjfBJEesLOjvV_f1OTFkeiLpGj0Q at mail.gmail.com> >> Content-Type: text/plain; charset="utf-8" >> >> Hi everyone, >> >> I understand the concerns being raised about AI and new participants >> joining the discussion. However, I don't think we should discourage people >> from participating simply because they are new or because they choose to >> use AI as a writing aid. >> >> AI can help people organize their thoughts, improve grammar, or >> communicate >> more clearly, but it shouldn't replace independent thinking. What matters >> most is whether the ideas being presented are relevant, technically sound, >> and contribute meaningfully to the policy discussion. >> >> The PDP has always been intended to be open and inclusive. New >> participants >> should be encouraged to engage, provided they do so respectfully and in >> good faith. If there are concerns about duplicate messages or coordinated >> submissions, those can be addressed based on evidence rather than >> assumptions about individuals. >> >> I believe we should continue evaluating contributions on their merit and >> keep the discussion focused on the policy itself. >> >> Kind regards, >> >> Fundiswa Nadia Maseko >> >> On Wed, 22 Jul 2026, 15:53 , wrote: >> >> > Send RPD mailing list submissions to >> > rpd at afrinic.net >> > >> > To subscribe or unsubscribe via the World Wide Web, visit >> > https://lists.afrinic.net/mailman/listinfo/rpd >> > or, via email, send a message with subject or body 'help' to >> > rpd-request at afrinic.net >> > >> > You can reach the person managing the list at >> > rpd-owner at afrinic.net >> > >> > When replying, please edit your Subject line so it is more specific >> > than "Re: Contents of RPD digest..." >> > >> > >> > Today's Topics: >> > >> > 1. Re: Policy supremacy (Nonjabulo Sphilile) >> > 2. Re: The usage of AI in platforms (JP) >> > 3. Re: Policy supremacy (Diroi Karalis) >> > >> > >> > ---------------------------------------------------------------------- >> > >> > Message: 1 >> > Date: Wed, 22 Jul 2026 15:45:19 +0200 >> > From: Nonjabulo Sphilile >> > To: rpd at afrinic.net >> > Subject: Re: [rpd] Policy supremacy >> > Message-ID: >> > > > aWw6YqZVRZ51DVEdpsQ3xfRar0XmgPedHLruA at mail.gmail.com> >> > Content-Type: text/plain; charset="utf-8" >> > >> > Hi Musa, >> > >> > The PDWG is open. Participation does not depend on being known to >> > long-standing members, attending earlier meetings, or proving a >> > professional stake after joining. New participation is still >> participation. >> > >> > KYC would be a serious procedural change, not an informal test for >> > unfamiliar objectors. Any such requirement would need to be formally >> > adopted, proportionate, privacy-preserving, and applied equally to >> > established and new participants. >> > >> > Similar views are not proof of impersonation. If there is concrete >> evidence >> > of misconduct, please submit it to the co-chairs. Otherwise, I will not >> > continue discussing identities or drafting methods. >> > >> > Let us return to the policy. >> > >> > Regards, >> > Nonjabulo >> > -------------- next part -------------- >> > An HTML attachment was scrubbed... >> > URL: < >> > >> https://lists.afrinic.net/pipermail/rpd/attachments/20260722/1992795c/attachment-0001.html >> > > >> > >> > ------------------------------ >> > >> > Message: 2 >> > Date: Wed, 22 Jul 2026 15:51:18 +0200 >> > From: JP >> > To: rpd at afrinic.net >> > Subject: Re: [rpd] The usage of AI in platforms >> > Message-ID: >> > Content-Type: text/plain; charset="utf-8"; Format="flowed" >> > >> > On 22 Jul 2026, at 12:15, Mzwakhe Mabasa via RPD wrote: >> > >> > > Good day.I would like to post to the RPD mailing list. Kindly allow me >> > > this opportunity of being part of the RPD afrinic policy decisions.? >> > > >> > > While AI is widely used across the internet, its acceptability >> > > depends on the specific platform you are referring to . Most social >> > > networks allow AI assistance, but require the clear labeling of >> > > AI-generated imagery and ban non-consensual deepfakes or harmful >> > > content.?LSince platform policies vary greatly, here is a breakdown >> > > of how the most popular services handle AI usage: >> > > >> > > - Social Media (Facebook, Instagram, TikTok, YouTube): Generally >> > > allowed, but social media algorithms penalize low-quality, generic >> > > content. Major platforms are shifting to automatic detection and >> > > require synthetic imagery to be appropriately labeled to avoid >> > > misinformation penalties.? >> > > >> > > - Design & Creative Platforms (Canva): AI usage for brainstorming >> > > and generating designs is permitted, but platforms typically place >> > > operational limits on how much AI content you can generate per month. >> > > Users are responsible for ensuring AI outputs do not mislead others >> > > and are used in accordance with local copyright laws.? >> > > >> > > - AI Generation Models (Open AI, Midjourney): AI tools are >> > > permitted, but they enforce strict universal policies. You cannot use >> > > these services for harassment, defamation, or generating unauthorized >> > > deepfakes of real people >> > >> > to play off an older joke: >> > >> > q: ?how do you know someone?s using LLMs?? >> > a: ?they?ll damn well tell you? >> > >> > normally I don?t need to pay much attention to rpd because things >> > don?t move that much, and then the last week? the sloppist tsunami >> > has been quite notable. and it?s near all this kind of milquetoast >> > nonsense gibberish. I saw someone else mention the astroturfing >> > component of things too (and a cursory investigation around the poster >> > domains for the most vocal proponents there had me raising my eyebrows >> > most spock-like) but I?ll leave that aside for now >> > >> > it?s probably worth rpd considering a full and complete ban on >> > prompt-generation and prompt-assistance for use on the policy list, with >> > possibly a poster cooldown/block period (and some way to deal with >> > repeat offenders and ban evasion). >> > >> > there?s both precedent and strong arguments in favour >> > >> > precedent: a number of other public-benefit and mass-cooperation >> > organisations and projects have taken to the hardline block (the most >> > notable is codeberg, as of earlier today) >> > >> > arguments: the most obvious is exactly what has happened in the last >> > week (and the alternative of no ban is an utter deluge of worthless >> > noise, which will space-fill as far as it can go). there is also ample >> > evidence across multiple years and multiple studies that these >> > technologies are _bad_ at fine detail, and that?s exactly the sort of >> > thing that is very ill-fitting in the context of what rpd is to be doing >> > >> > -J >> > -------------- next part -------------- >> > An HTML attachment was scrubbed... >> > URL: < >> > >> https://lists.afrinic.net/pipermail/rpd/attachments/20260722/f83dfe25/attachment-0001.html >> > > >> > >> > ------------------------------ >> > >> > Message: 3 >> > Date: Wed, 22 Jul 2026 15:52:40 +0200 >> > From: Diroi Karalis >> > To: rpd at afrinic.net >> > Subject: Re: [rpd] Policy supremacy >> > Message-ID: >> > < >> > CA+wt7VoZ2hQyw6ZiGAAxr-SRTmXaYwjM-xD_aknC2tj+Oqhdig at mail.gmail.com> >> > Content-Type: text/plain; charset="utf-8" >> > >> > Dear Musa, >> > >> > Tshepo and Gugu don't need prior recognition from established >> participants >> > before their input counts. Joining recently, missing earlier meetings, >> or >> > sharing similar views is not evidence of impersonation or bad faith. >> Anyone >> > is entitled to join an open process at Last Call and raise objections >> > before a proposal becomes policy. >> > KYC would be a significant procedural and privacy change. It can't be >> > applied selectively to objectors we don't recognize it would need a >> formal >> > basis, a clear justification, proper safeguards, and equal application >> to >> > every participant, not just the inconvenient ones. >> > If you have evidence of misconduct, send it to the co-chairs. Otherwise, >> > engage with Tshepo and Gugu's arguments on their merits. Familiarity >> isn't >> > authority, and "the community" isn't a closed circle that gets to decide >> > who's allowed in. >> > >> > Regards, >> > Diroi >> > -------------- next part -------------- >> > An HTML attachment was scrubbed... >> > URL: < >> > >> https://lists.afrinic.net/pipermail/rpd/attachments/20260722/7c67f9fd/attachment.html >> > > >> > >> > ------------------------------ >> > >> > Subject: Digest Footer >> > >> > _______________________________________________ >> > RPD mailing list >> > RPD at afrinic.net >> > https://lists.afrinic.net/mailman/listinfo/rpd >> > >> > >> > ------------------------------ >> > >> > End of RPD Digest, Vol 222, Issue 158 >> > ************************************* >> > >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: < >> https://lists.afrinic.net/pipermail/rpd/attachments/20260722/ba32bf97/attachment.html >> > >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> ------------------------------ >> >> End of RPD Digest, Vol 222, Issue 159 >> ************************************* >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From omo.oaiya at wacren.net Wed Jul 22 15:36:02 2026 From: omo.oaiya at wacren.net (Omo Oaiya) Date: Wed, 22 Jul 2026 18:36:02 +0300 Subject: [rpd] Policy supremacy In-Reply-To: <006d01dd19e9$41defcb0$c59cf610$@iptrading.com> References: <005d01dd19e7$6edbeef0$4c93ccd0$@iptrading.com> <1038A6B3-E375-41DD-A268-740FE02AC477@afrinic.net> <006d01dd19e9$41defcb0$c59cf610$@iptrading.com> Message-ID: <2B1B0BD0-DD37-48B2-B25B-192984D908BD@wacren.net> +1 > On 22 Jul 2026, at 17:49, Mike Burns via RPD wrote: > > I agree. They are using, well, I wouldn?t call it eloquent, but prompt driven words against a policy proposal. > I don?t see anything wrong in that, certainly nothing that would shake the foundations of an open stakeholder policy forum. > > Regards, > Mike > > > From: Ben Roberts - AfriNIC > Sent: Wednesday, July 22, 2026 10:42 AM > To: Mike Burns > Cc: Zenalo Mguqulwa ; rpd at afrinic.net > Subject: Re: [rpd] Policy supremacy > > Mike, > The strength of wordy arguments coming at us arguing against (human) identity verification, from unknown mailboxes, seems to serve as proof that the mailboxes are in fact AI agent automatons (like Openclaw instances) and not human at all. Hence a very good argument for the thing they are writing eloquent prompt driven words against. > > Kind regards > Ben. > Sent from my iPhone > > >> On 22 Jul 2026, at 16:36, Mike Burns > wrote: >> >> ? >> ?Strong arguments? so we must take action? >> >> From: Ben Roberts - AfriNIC via RPD > >> Sent: Wednesday, July 22, 2026 10:29 AM >> To: Zenalo Mguqulwa > >> Cc: rpd at afrinic.net >> Subject: Re: [rpd] Policy supremacy >> >> Zenalo and others, >> >> Your bombardment of us with strong arguments against identity verification, coming from completely new mailboxes on the list, are doing a good job of convincing me that we MUST actually introduced mandatory identity verification. >> >> Good job! >> >> Sent from my iPhone >> >> >> >>> On 22 Jul 2026, at 16:24, Zenalo Mguqulwa > wrote: >>> >>> ? >>> Hi, >>> I don't believe introducing identity verification is the right solution. The platform should remain open and accessible to anyone who wishes to participate. >>> What matters is the quality of the argument, not who makes it. If participants choose to share their background or affiliations, that's entirely their decision, but it should never become a requirement for taking part. >>> The same applies to AI. Its use is only going to become more common, and that in itself isn't a problem. The focus should remain on whether contributions are constructive, evidence-based, and engage with the discussion. >>> Kind regards, >>> Zen >>> On Wed, 22 Jul 2026 at 16:12, > wrote: >>>> Send RPD mailing list submissions to >>>> rpd at afrinic.net >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> or, via email, send a message with subject or body 'help' to >>>> rpd-request at afrinic.net >>>> >>>> You can reach the person managing the list at >>>> rpd-owner at afrinic.net >>>> >>>> When replying, please edit your Subject line so it is more specific >>>> than "Re: Contents of RPD digest..." >>>> >>>> >>>> Today's Topics: >>>> >>>> 1. Re: Policy supremacy (Jaco Kroon) >>>> 2. Re: RPD Digest, Vol 222, Issue 158 (Fundiswa Nadia Maseko) >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> Message: 1 >>>> Date: Wed, 22 Jul 2026 16:01:03 +0200 >>>> From: Jaco Kroon > >>>> To: rpd at afrinic.net >>>> Subject: Re: [rpd] Policy supremacy >>>> Message-ID: <14936a5e-6d1e-4e4b-8957-b0e2018274aa at uls.co.za > >>>> Content-Type: text/plain; charset=UTF-8; format=flowed >>>> >>>> Hi, >>>> >>>> Are we thus proposing that each and every person must positively >>>> identify themselves prior to being subscribed to the RPD list, as well >>>> as for all existing subscribers to be positively identified by date X or >>>> be unsubscribed?? To what extend should this identification go - should >>>> it include affiliation checking, eg, Jaco Kroon actually JK19-AFRINIC in >>>> the whois db - from where you can track the networks I'm involved with? >>>> >>>> I'd be in support of such a policy change/direction. >>>> >>>> Regarding use of AI, I don't have a particular objection to the use of >>>> LLMs (but having worked on the Comp-Sci side of things ... I would not >>>> trust them without validating whatever they spit out - and recent >>>> experience - not restricted to this ML - shows they spit out more >>>> garbage than most community-driven support forums), as long as they're >>>> used sensibly to help with formatting and/or interpretation of emails, >>>> not to spew out noise for the sake of noise - as what it feels has been >>>> done the last week or two. >>>> >>>> Kind regards, >>>> Jaco >>>> >>>> n 2026/07/22 15:52, Diroi Karalis wrote: >>>> >>>> > Dear Musa, >>>> > >>>> > Tshepo and Gugu don't need prior recognition from established >>>> > participants before their input counts. Joining recently, missing >>>> > earlier meetings, or sharing similar views is not evidence of >>>> > impersonation or bad faith. Anyone is entitled to join an open process >>>> > at Last Call and raise objections before a proposal becomes policy. >>>> > KYC would be a significant procedural and privacy change. It can't be >>>> > applied selectively to objectors we don't recognize it would need a >>>> > formal basis, a clear justification, proper safeguards, and equal >>>> > application to every participant, not just the inconvenient ones. >>>> > If you have evidence of misconduct, send it to the co-chairs. >>>> > Otherwise, engage with Tshepo and Gugu's arguments on their merits. >>>> > Familiarity isn't authority, and "the community" isn't a closed circle >>>> > that gets to decide who's allowed in. >>>> > >>>> > Regards, >>>> > Diroi >>>> > >>>> > _______________________________________________ >>>> > RPD mailing list >>>> > RPD at afrinic.net >>>> > https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>>> >>>> >>>> ------------------------------ >>>> >>>> Message: 2 >>>> Date: Wed, 22 Jul 2026 16:11:08 +0200 >>>> From: Fundiswa Nadia Maseko > >>>> To: rpd at afrinic.net >>>> Subject: Re: [rpd] RPD Digest, Vol 222, Issue 158 >>>> Message-ID: >>>> > >>>> Content-Type: text/plain; charset="utf-8" >>>> >>>> Hi everyone, >>>> >>>> I understand the concerns being raised about AI and new participants >>>> joining the discussion. However, I don't think we should discourage people >>>> from participating simply because they are new or because they choose to >>>> use AI as a writing aid. >>>> >>>> AI can help people organize their thoughts, improve grammar, or communicate >>>> more clearly, but it shouldn't replace independent thinking. What matters >>>> most is whether the ideas being presented are relevant, technically sound, >>>> and contribute meaningfully to the policy discussion. >>>> >>>> The PDP has always been intended to be open and inclusive. New participants >>>> should be encouraged to engage, provided they do so respectfully and in >>>> good faith. If there are concerns about duplicate messages or coordinated >>>> submissions, those can be addressed based on evidence rather than >>>> assumptions about individuals. >>>> >>>> I believe we should continue evaluating contributions on their merit and >>>> keep the discussion focused on the policy itself. >>>> >>>> Kind regards, >>>> >>>> Fundiswa Nadia Maseko >>>> >>>> On Wed, 22 Jul 2026, 15:53 , > wrote: >>>> >>>> > Send RPD mailing list submissions to >>>> > rpd at afrinic.net >>>> > >>>> > To subscribe or unsubscribe via the World Wide Web, visit >>>> > https://lists.afrinic.net/mailman/listinfo/rpd >>>> > or, via email, send a message with subject or body 'help' to >>>> > rpd-request at afrinic.net >>>> > >>>> > You can reach the person managing the list at >>>> > rpd-owner at afrinic.net >>>> > >>>> > When replying, please edit your Subject line so it is more specific >>>> > than "Re: Contents of RPD digest..." >>>> > >>>> > >>>> > Today's Topics: >>>> > >>>> > 1. Re: Policy supremacy (Nonjabulo Sphilile) >>>> > 2. Re: The usage of AI in platforms (JP) >>>> > 3. Re: Policy supremacy (Diroi Karalis) >>>> > >>>> > >>>> > ---------------------------------------------------------------------- >>>> > >>>> > Message: 1 >>>> > Date: Wed, 22 Jul 2026 15:45:19 +0200 >>>> > From: Nonjabulo Sphilile > >>>> > To: rpd at afrinic.net >>>> > Subject: Re: [rpd] Policy supremacy >>>> > Message-ID: >>>> > >>> > aWw6YqZVRZ51DVEdpsQ3xfRar0XmgPedHLruA at mail.gmail.com > >>>> > Content-Type: text/plain; charset="utf-8" >>>> > >>>> > Hi Musa, >>>> > >>>> > The PDWG is open. Participation does not depend on being known to >>>> > long-standing members, attending earlier meetings, or proving a >>>> > professional stake after joining. New participation is still participation. >>>> > >>>> > KYC would be a serious procedural change, not an informal test for >>>> > unfamiliar objectors. Any such requirement would need to be formally >>>> > adopted, proportionate, privacy-preserving, and applied equally to >>>> > established and new participants. >>>> > >>>> > Similar views are not proof of impersonation. If there is concrete evidence >>>> > of misconduct, please submit it to the co-chairs. Otherwise, I will not >>>> > continue discussing identities or drafting methods. >>>> > >>>> > Let us return to the policy. >>>> > >>>> > Regards, >>>> > Nonjabulo >>>> > -------------- next part -------------- >>>> > An HTML attachment was scrubbed... >>>> > URL: < >>>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/1992795c/attachment-0001.html >>>> > > >>>> > >>>> > ------------------------------ >>>> > >>>> > Message: 2 >>>> > Date: Wed, 22 Jul 2026 15:51:18 +0200 >>>> > From: JP > >>>> > To: rpd at afrinic.net >>>> > Subject: Re: [rpd] The usage of AI in platforms >>>> > Message-ID: > >>>> > Content-Type: text/plain; charset="utf-8"; Format="flowed" >>>> > >>>> > On 22 Jul 2026, at 12:15, Mzwakhe Mabasa via RPD wrote: >>>> > >>>> > > Good day.I would like to post to the RPD mailing list. Kindly allow me >>>> > > this opportunity of being part of the RPD afrinic policy decisions.? >>>> > > >>>> > > While AI is widely used across the internet, its acceptability >>>> > > depends on the specific platform you are referring to . Most social >>>> > > networks allow AI assistance, but require the clear labeling of >>>> > > AI-generated imagery and ban non-consensual deepfakes or harmful >>>> > > content.?LSince platform policies vary greatly, here is a breakdown >>>> > > of how the most popular services handle AI usage: >>>> > > >>>> > > - Social Media (Facebook, Instagram, TikTok, YouTube): Generally >>>> > > allowed, but social media algorithms penalize low-quality, generic >>>> > > content. Major platforms are shifting to automatic detection and >>>> > > require synthetic imagery to be appropriately labeled to avoid >>>> > > misinformation penalties.? >>>> > > >>>> > > - Design & Creative Platforms (Canva): AI usage for brainstorming >>>> > > and generating designs is permitted, but platforms typically place >>>> > > operational limits on how much AI content you can generate per month. >>>> > > Users are responsible for ensuring AI outputs do not mislead others >>>> > > and are used in accordance with local copyright laws.? >>>> > > >>>> > > - AI Generation Models (Open AI, Midjourney): AI tools are >>>> > > permitted, but they enforce strict universal policies. You cannot use >>>> > > these services for harassment, defamation, or generating unauthorized >>>> > > deepfakes of real people >>>> > >>>> > to play off an older joke: >>>> > >>>> > q: ?how do you know someone?s using LLMs?? >>>> > a: ?they?ll damn well tell you? >>>> > >>>> > normally I don?t need to pay much attention to rpd because things >>>> > don?t move that much, and then the last week? the sloppist tsunami >>>> > has been quite notable. and it?s near all this kind of milquetoast >>>> > nonsense gibberish. I saw someone else mention the astroturfing >>>> > component of things too (and a cursory investigation around the poster >>>> > domains for the most vocal proponents there had me raising my eyebrows >>>> > most spock-like) but I?ll leave that aside for now >>>> > >>>> > it?s probably worth rpd considering a full and complete ban on >>>> > prompt-generation and prompt-assistance for use on the policy list, with >>>> > possibly a poster cooldown/block period (and some way to deal with >>>> > repeat offenders and ban evasion). >>>> > >>>> > there?s both precedent and strong arguments in favour >>>> > >>>> > precedent: a number of other public-benefit and mass-cooperation >>>> > organisations and projects have taken to the hardline block (the most >>>> > notable is codeberg, as of earlier today) >>>> > >>>> > arguments: the most obvious is exactly what has happened in the last >>>> > week (and the alternative of no ban is an utter deluge of worthless >>>> > noise, which will space-fill as far as it can go). there is also ample >>>> > evidence across multiple years and multiple studies that these >>>> > technologies are _bad_ at fine detail, and that?s exactly the sort of >>>> > thing that is very ill-fitting in the context of what rpd is to be doing >>>> > >>>> > -J >>>> > -------------- next part -------------- >>>> > An HTML attachment was scrubbed... >>>> > URL: < >>>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/f83dfe25/attachment-0001.html >>>> > > >>>> > >>>> > ------------------------------ >>>> > >>>> > Message: 3 >>>> > Date: Wed, 22 Jul 2026 15:52:40 +0200 >>>> > From: Diroi Karalis > >>>> > To: rpd at afrinic.net >>>> > Subject: Re: [rpd] Policy supremacy >>>> > Message-ID: >>>> > < >>>> > CA+wt7VoZ2hQyw6ZiGAAxr-SRTmXaYwjM-xD_aknC2tj+Oqhdig at mail.gmail.com > >>>> > Content-Type: text/plain; charset="utf-8" >>>> > >>>> > Dear Musa, >>>> > >>>> > Tshepo and Gugu don't need prior recognition from established participants >>>> > before their input counts. Joining recently, missing earlier meetings, or >>>> > sharing similar views is not evidence of impersonation or bad faith. Anyone >>>> > is entitled to join an open process at Last Call and raise objections >>>> > before a proposal becomes policy. >>>> > KYC would be a significant procedural and privacy change. It can't be >>>> > applied selectively to objectors we don't recognize it would need a formal >>>> > basis, a clear justification, proper safeguards, and equal application to >>>> > every participant, not just the inconvenient ones. >>>> > If you have evidence of misconduct, send it to the co-chairs. Otherwise, >>>> > engage with Tshepo and Gugu's arguments on their merits. Familiarity isn't >>>> > authority, and "the community" isn't a closed circle that gets to decide >>>> > who's allowed in. >>>> > >>>> > Regards, >>>> > Diroi >>>> > -------------- next part -------------- >>>> > An HTML attachment was scrubbed... >>>> > URL: < >>>> > https://lists.afrinic.net/pipermail/rpd/attachments/20260722/7c67f9fd/attachment.html >>>> > > >>>> > >>>> > ------------------------------ >>>> > >>>> > Subject: Digest Footer >>>> > >>>> > _______________________________________________ >>>> > RPD mailing list >>>> > RPD at afrinic.net >>>> > https://lists.afrinic.net/mailman/listinfo/rpd >>>> > >>>> > >>>> > ------------------------------ >>>> > >>>> > End of RPD Digest, Vol 222, Issue 158 >>>> > ************************************* >>>> > >>>> -------------- next part -------------- >>>> An HTML attachment was scrubbed... >>>> URL: >>>> >>>> ------------------------------ >>>> >>>> Subject: Digest Footer >>>> >>>> _______________________________________________ >>>> RPD mailing list >>>> RPD at afrinic.net >>>> https://lists.afrinic.net/mailman/listinfo/rpd >>>> >>>> >>>> ------------------------------ >>>> >>>> End of RPD Digest, Vol 222, Issue 159 >>>> ************************************* >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd Omo OAIYA Chief Strategy Officer/Directeur de la Strat?gie | WACREN m: +234 808 888 1571 , +233 536 269 987 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mandlamatshika at gmail.com Wed Jul 22 16:08:30 2026 From: mandlamatshika at gmail.com (Mandla Matshika) Date: Wed, 22 Jul 2026 18:08:30 +0200 Subject: [rpd] RDP Discussion Message-ID: Dear Musa, Tshepo, Gugu, and all, I?d like to respond to some of the concerns raised. On new contributors: The PDWG is intentionally open. Part of the strength of AFRINIC policy development is that it allows new stakeholders to engage when an issue becomes relevant to them, even if they were not active before the PPM. People?s capacity, organizational priorities, and awareness evolve, and that often brings new voices to the list. Regarding Tshepo and Gugu specifically: I don?t think we should assume bad faith because two people may reference similar facts, data, or community talking points. Convergence in policy positions is common, especially when we are all responding to the same policy text and community impact. That does not mean they are ?using the same AI prompt.? Let?s engage with the substance of their contributions instead. I also agree that authenticity matters. However KYC-style verification on an open mailing list risks creating barriers to participation that the PDP was designed to avoid. A better approach is to judge contributions on merit, relevance, and alignment AFRINIC?s mission and the needs of network operators in the region. Let?s keep the discussion focused on policy and evidence. Kind regards, Mandla -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Wed Jul 22 16:32:26 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Wed, 22 Jul 2026 18:32:26 +0200 Subject: [rpd] Policy supremacy In-Reply-To: References: Message-ID: NP, For avoidance of doubt? Are you related to Nia Petronella - nonhlanhlapetronella85 at gmail.com Kind regards Ben Sent from my iPhone > On 22 Jul 2026, at 16:53, NP Petronella wrote: > > ? > Dear Ben, > > I support a 'neutral human-verification process', but not the conclusion you draw. Strong arguments from unfamiliar mailboxes are not proof that the accounts are automated. > > Any verification mechanism must be formally adopted, administered by the co-chairs or list operator, privacy-preserving, and applied equally to established and new participants. It should verify only that a real person controls the account. > > Otherwise, verification becomes mandate laundering: a small procedural circle converts suspicion into authority to decide who qualifies as ?the community.? > > Regards, > Nonhlanhla > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Wed Jul 22 16:34:54 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Wed, 22 Jul 2026 18:34:54 +0200 Subject: [rpd] RDP Discussion In-Reply-To: References: Message-ID: <41D75DE0-F64F-407A-A8EC-6861E970856F@afrinic.net> Hi Mandla, I saw when you joined that you are a Policy insights contributor at NRS. Can we assume here that you are speaking on behalf of the NRS? Kind regards Ben Sent from my iPhone > On 22 Jul 2026, at 18:10, Mandla Matshika wrote: > > ? > Dear Musa, Tshepo, Gugu, and all, > > I?d like to respond to some of the concerns raised. > > On new contributors: The PDWG is intentionally open. Part of the strength of AFRINIC policy development is that it allows new stakeholders to engage when an issue becomes relevant to them, even if they were not active before the PPM. People?s capacity, organizational priorities, and awareness evolve, and that often brings new voices to the list. > > Regarding Tshepo and Gugu specifically: I don?t think we should assume bad faith because two people may reference similar facts, data, or community talking points. Convergence in policy positions is common, especially when we are all responding to the same policy text and community impact. That does not mean they are ?using the same AI prompt.? Let?s engage with the substance of their contributions instead. > > I also agree that authenticity matters. However KYC-style verification on an open mailing list risks creating barriers to participation that the PDP was designed to avoid. A better approach is to judge contributions on merit, relevance, and alignment AFRINIC?s mission and the needs of network operators in the region. > > Let?s keep the discussion focused on policy and evidence. > > Kind regards, > Mandla > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From NPertuniaPetronella at outlook.com Wed Jul 22 16:35:09 2026 From: NPertuniaPetronella at outlook.com (NP Petronella) Date: Wed, 22 Jul 2026 16:35:09 +0000 Subject: [rpd] Policy supremacy In-Reply-To: References: Message-ID: Hi Ben, Yes, I am her and she is me. BR, Nonhlanhla ________________________________ From: Ben Roberts - AfriNIC Sent: Wednesday, 22 July 2026 18:32:26 To: Petronella NP Cc: rpd at afrinic.net Subject: Re: [rpd] Policy supremacy NP, For avoidance of doubt? Are you related to Nia Petronella - nonhlanhlapetronella85 at gmail.com Kind regards Ben Sent from my iPhone On 22 Jul 2026, at 16:53, NP Petronella wrote: ? Dear Ben, I support a 'neutral human-verification process', but not the conclusion you draw. Strong arguments from unfamiliar mailboxes are not proof that the accounts are automated. Any verification mechanism must be formally adopted, administered by the co-chairs or list operator, privacy-preserving, and applied equally to established and new participants. It should verify only that a real person controls the account. Otherwise, verification becomes mandate laundering: a small procedural circle converts suspicion into authority to decide who qualifies as ?the community.? Regards, Nonhlanhla -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah at neo.co.tz Wed Jul 22 17:41:58 2026 From: noah at neo.co.tz (Noah) Date: Wed, 22 Jul 2026 20:41:58 +0300 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavior on AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: <1784639031075.56443@tra.gov.eg> References: <1784639031075.56443@tra.gov.eg> Message-ID: Dear Hytham I am writing to request and call for moderating the RPD list. The ongoing Trolling activity is a shame. I have never experienced anything like this as a participant on RIPE, APNIC, LACNIC and ARIN - policy development mailing list. We have a culture problem within AFRINIC service region and we need to raise the occassion and above this level of immaturity. Cheers, *.**/noah* On Tue, 21 Jul 2026, 4:10?pm Hytham El-Nakhal, wrote: > Dear PDWG, > > > > > > I have taken note of the various posts on the RPD ML regarding the > proposal ?Hierarchical Names for New AS-SETs? that has entered into Last > Call after it reached rough consensus during the AFRINIC-37 PPM held on 24 > June 2026. The mailing list has recently been flooded with multiple emails > stating either the same duplicate objections or consistent pushbacks to > every post, some of them with subject line containing ?Digest?. > > The specific purpose of the Last Call phase is to allow the Community to > review the final draft of the proposal and to voice any new valid > objections that may have been missed during the discussion phase and would > have unintended consequences. In case of the latter, the objection needs to > be fully justified, rather than simply repeating past points that have > already been addressed. > > > > This behavior during the Last Call period is placing an unnecessary and > additional burden on the subscribers, PDWG chairs, and staff as each post > has to be read and contents assessed. > > We wish to explicitly remind the PDWG that the number of opposers does not > count towards consensus determination, and repeating identical objections > does not influence the outcome. > > > > I recommend that every contributor use this guide below before commenting > on the proposals that are at discussion stage or have reached Last Call : - > > 1. Familiarise yourself with the consensus-driven AFRINIC PDP and the > proposal [See Section below] > 2. Read the proposal and consult the archives of discussions as well as > previous Public Policy Meeting proceedings > 3. Read and adhere to the AFRINIC Code of Conduct - > https://www.afrinic.net/code.html . Participants are expected to work > collaboratively to build consensus with other participants and to find > solutions to problems in the case of policy development. > 4. Familiarise yourself with the contributions that have happened > during the stage (Under discussion or Last Call) . Share your view or > objection if they are new ; i.e has not been addressed by others. More > specifically in the Last Call, all those opposed are encouraged to focus on > explaining concisely how the proposal acts as a blocker now. They should > provide reasons as to why this feedback could not be provided when the > proposal was first submitted to the RPD mailing list, rather than repeating > generic objections. > 5. When contributing, please ensure that the Policy name and ID is > included in the subject line [responding to digests further complicates the > assessment per proposal]. If you are providing the perspective of your > employer that is a Resource Member or as an individual contributor, please > say so and provide details. > 6. In the event, that you have a new policy related topic or idea to > discuss, please change the subject line accordingly. > > In the event that disruptive multiple posts and duplicate submissions > persist, adequate administrative measures will be considered to ensure the > efficiency of the process. > > As we proceed towards the end of Last call for each proposal, a summary of > the contributions is prepared and shared with the PDWG on this mailing > list. I expect the collaboration of everyone. > > > > To educate the PDWG new members and the community at large on the policy > development framework, it is vital to understand the formal policy > development process. The AFRINIC PDP is strictly governed by Section 3 of > the Policy Manual, which can be consulted here : > https://www.afrinic.net/consolidated-policy-manual.html. An explanatory > webinar was also conducted recently to onboard participants in policy > development and can be accessed here : > https://www.youtube.com/watch?v=MoB1ZjXgN44. > > > For historical context, all prior discussions on the proposals that have > reached Last Call can be consulted in the RPD archives : > https://lists.afrinic.net/pipermail/rpd/. The proposals were further > discussed during the AF-37 PPM in hybrid mode, allowing registered online > and onsite participants to contribute. > > The AF-37 PPM minutes can be accessed here : > https://docs.google.com/document/d/1RS9bYBb9-8uQxLb4u8LpvEUw1jZSfei5mLj01l2LS1s/edit?usp=sharing > > > Kind Regards, > Haitham el Nakhal > PDWG Co-Chair > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Wed Jul 22 17:53:48 2026 From: mike at iptrading.com (Mike Burns) Date: Wed, 22 Jul 2026 13:53:48 -0400 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: References: <1784639031075.56443@tra.gov.eg> Message-ID: <00e501dd1a03$0c54a1c0$24fde540$@iptrading.com> Hi Noah, Trolling isn?t the right word for this. Stakeholder governance processed through open email forums is the likeliest place for AI to take a seat at the table of governance. It?s not like Claude will be elected to any parliament. But this unique governance form for a global asset provides the opportunity. I say, who cares if Claude is posting, or ChatGPT, or any other AI. Give them a seat at the table and address their arguments. Giving them a veneer of humanness through identity appropriation is not the way forward. Again, I am interested in hearing other perspectives. Regards, Mike From: Noah Sent: Wednesday, July 22, 2026 1:42 PM To: Hytham El-Nakhal Cc: pdwg-chairs at afrinic.net; rpd List Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 Dear Hytham I am writing to request and call for moderating the RPD list. The ongoing Trolling activity is a shame. I have never experienced anything like this as a participant on RIPE, APNIC, LACNIC and ARIN - policy development mailing list. We have a culture problem within AFRINIC service region and we need to raise the occassion and above this level of immaturity. Cheers, ./noah On Tue, 21 Jul 2026, 4:10?pm Hytham El-Nakhal, > wrote: Dear PDWG, I have taken note of the various posts on the RPD ML regarding the proposal ?Hierarchical Names for New AS-SETs? that has entered into Last Call after it reached rough consensus during the AFRINIC-37 PPM held on 24 June 2026. The mailing list has recently been flooded with multiple emails stating either the same duplicate objections or consistent pushbacks to every post, some of them with subject line containing ?Digest?. The specific purpose of the Last Call phase is to allow the Community to review the final draft of the proposal and to voice any new valid objections that may have been missed during the discussion phase and would have unintended consequences. In case of the latter, the objection needs to be fully justified, rather than simply repeating past points that have already been addressed. This behavior during the Last Call period is placing an unnecessary and additional burden on the subscribers, PDWG chairs, and staff as each post has to be read and contents assessed. We wish to explicitly remind the PDWG that the number of opposers does not count towards consensus determination, and repeating identical objections does not influence the outcome. I recommend that every contributor use this guide below before commenting on the proposals that are at discussion stage or have reached Last Call : - 1. Familiarise yourself with the consensus-driven AFRINIC PDP and the proposal [See Section below] 2. Read the proposal and consult the archives of discussions as well as previous Public Policy Meeting proceedings 3. Read and adhere to the AFRINIC Code of Conduct - https://www.afrinic.net/code.html . Participants are expected to work collaboratively to build consensus with other participants and to find solutions to problems in the case of policy development. 4. Familiarise yourself with the contributions that have happened during the stage (Under discussion or Last Call) . Share your view or objection if they are new ; i.e has not been addressed by others. More specifically in the Last Call, all those opposed are encouraged to focus on explaining concisely how the proposal acts as a blocker now. They should provide reasons as to why this feedback could not be provided when the proposal was first submitted to the RPD mailing list, rather than repeating generic objections. 5. When contributing, please ensure that the Policy name and ID is included in the subject line [responding to digests further complicates the assessment per proposal]. If you are providing the perspective of your employer that is a Resource Member or as an individual contributor, please say so and provide details. 6. In the event, that you have a new policy related topic or idea to discuss, please change the subject line accordingly. In the event that disruptive multiple posts and duplicate submissions persist, adequate administrative measures will be considered to ensure the efficiency of the process. As we proceed towards the end of Last call for each proposal, a summary of the contributions is prepared and shared with the PDWG on this mailing list. I expect the collaboration of everyone. To educate the PDWG new members and the community at large on the policy development framework, it is vital to understand the formal policy development process. The AFRINIC PDP is strictly governed by Section 3 of the Policy Manual, which can be consulted here : https://www.afrinic.net/consolidated-policy-manual.html. An explanatory webinar was also conducted recently to onboard participants in policy development and can be accessed here : https://www.youtube.com/watch?v=MoB1ZjXgN44. For historical context, all prior discussions on the proposals that have reached Last Call can be consulted in the RPD archives : https://lists.afrinic.net/pipermail/rpd/. The proposals were further discussed during the AF-37 PPM in hybrid mode, allowing registered online and onsite participants to contribute. The AF-37 PPM minutes can be accessed here : https://docs.google.com/document/d/1RS9bYBb9-8uQxLb4u8LpvEUw1jZSfei5mLj01l2LS1s/edit?usp=sharing Kind Regards, Haitham el Nakhal PDWG Co-Chair _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From seun.ojedeji at gmail.com Wed Jul 22 18:04:08 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Wed, 22 Jul 2026 13:04:08 -0500 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: <00e501dd1a03$0c54a1c0$24fde540$@iptrading.com> References: <1784639031075.56443@tra.gov.eg> <00e501dd1a03$0c54a1c0$24fde540$@iptrading.com> Message-ID: I agree with Mike. I believe the chair's approach of initially calling for caution is appropriate. I do not believe moderation is required at this point. I expect that the Co-Chair will continue to monitor events and decide on the next step, specifically regarding calling out specific posters and perhaps eventually moderating them if the issue persists. For now, let's all enjoy the effect of AI. ;-) Regards On Wed, 22 Jul 2026 at 12:54, Mike Burns via RPD wrote: > Hi Noah, > > > > Trolling isn?t the right word for this. > > Stakeholder governance processed through open email forums is the > likeliest place for AI to take a seat at the table of governance. > > It?s not like Claude will be elected to any parliament. > > > > But this unique governance form for a global asset provides the > opportunity. > > I say, who cares if Claude is posting, or ChatGPT, or any other AI. > > Give them a seat at the table and address their arguments. > > Giving them a veneer of humanness through identity appropriation is not > the way forward. > > > > Again, I am interested in hearing other perspectives. > > > > Regards, > Mike > > > > > > *From:* Noah > *Sent:* Wednesday, July 22, 2026 1:42 PM > *To:* Hytham El-Nakhal > *Cc:* pdwg-chairs at afrinic.net; rpd List > *Subject:* Re: [rpd] PDWG Co-Chairs communication regarding observed > behavioron AFPUB-2026-ASN-001-DRAFT02 > > > > Dear Hytham > > > > I am writing to request and call for moderating the RPD list. > > > > The ongoing Trolling activity is a shame. > > > > I have never experienced anything like this as a participant on RIPE, > APNIC, LACNIC and ARIN - policy development mailing list. > > > > We have a culture problem within AFRINIC service region and we need to > raise the occassion and above this level of immaturity. > > > > Cheers, > > *./noah* > > > > > > On Tue, 21 Jul 2026, 4:10?pm Hytham El-Nakhal, wrote: > > Dear PDWG, > > > > > > I have taken note of the various posts on the RPD ML regarding the > proposal ?Hierarchical Names for New AS-SETs? that has entered into Last > Call after it reached rough consensus during the AFRINIC-37 PPM held on 24 > June 2026. The mailing list has recently been flooded with multiple emails > stating either the same duplicate objections or consistent pushbacks to > every post, some of them with subject line containing ?Digest?. > > The specific purpose of the Last Call phase is to allow the Community to > review the final draft of the proposal and to voice any new valid > objections that may have been missed during the discussion phase and would > have unintended consequences. In case of the latter, the objection needs to > be fully justified, rather than simply repeating past points that have > already been addressed. > > > > This behavior during the Last Call period is placing an unnecessary and > additional burden on the subscribers, PDWG chairs, and staff as each post > has to be read and contents assessed. > > We wish to explicitly remind the PDWG that the number of opposers does not > count towards consensus determination, and repeating identical objections > does not influence the outcome. > > > > I recommend that every contributor use this guide below before commenting > on the proposals that are at discussion stage or have reached Last Call : - > > 1. Familiarise yourself with the consensus-driven AFRINIC PDP and the > proposal [See Section below] > 2. Read the proposal and consult the archives of discussions as well as > previous Public Policy Meeting proceedings > 3. Read and adhere to the AFRINIC Code of Conduct - > https://www.afrinic.net/code.html . Participants are expected to work > collaboratively to build consensus with other participants and to find > solutions to problems in the case of policy development. > 4. Familiarise yourself with the contributions that have happened > during the stage (Under discussion or Last Call) . Share your view or > objection if they are new ; i.e has not been addressed by others. More > specifically in the Last Call, all those opposed are encouraged to focus on > explaining concisely how the proposal acts as a blocker now. They should > provide reasons as to why this feedback could not be provided when the > proposal was first submitted to the RPD mailing list, rather than repeating > generic objections. > 5. When contributing, please ensure that the Policy name and ID is > included in the subject line [responding to digests further complicates the > assessment per proposal]. If you are providing the perspective of your > employer that is a Resource Member or as an individual contributor, please > say so and provide details. > 6. In the event, that you have a new policy related topic or idea to > discuss, please change the subject line accordingly. > > In the event that disruptive multiple posts and duplicate submissions > persist, adequate administrative measures will be considered to ensure the > efficiency of the process. > > As we proceed towards the end of Last call for each proposal, a summary of > the contributions is prepared and shared with the PDWG on this mailing > list. I expect the collaboration of everyone. > > > > To educate the PDWG new members and the community at large on the policy > development framework, it is vital to understand the formal policy > development process. The AFRINIC PDP is strictly governed by Section 3 of > the Policy Manual, which can be consulted here : > https://www.afrinic.net/consolidated-policy-manual.html. An explanatory > webinar was also conducted recently to onboard participants in policy > development and can be accessed here : > https://www.youtube.com/watch?v=MoB1ZjXgN44. > > > For historical context, all prior discussions on the proposals that have > reached Last Call can be consulted in the RPD archives : > https://lists.afrinic.net/pipermail/rpd/. The proposals were further > discussed during the AF-37 PPM in hybrid mode, allowing registered online > and onsite participants to contribute. > > The AF-37 PPM minutes can be accessed here : > https://docs.google.com/document/d/1RS9bYBb9-8uQxLb4u8LpvEUw1jZSfei5mLj01l2LS1s/edit?usp=sharing > > > Kind Regards, > Haitham el Nakhal > PDWG Co-Chair > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -- ------------------------------------------------------------------------ *Seun Ojedeji,* Bringing another down does not take you up - think about your action! -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Wed Jul 22 19:49:47 2026 From: ben.roberts at afrinic.net (ben.roberts@frinic.net) Date: Wed, 22 Jul 2026 21:49:47 +0200 Subject: [rpd] Policy supremacy - on the AS set In-Reply-To: References: <005d01dd19e7$6edbeef0$4c93ccd0$@iptrading.com> <1038A6B3-E375-41DD-A268-740FE02AC477@afrinic.net> <006d01dd19e9$41defcb0$c59cf610$@iptrading.com> , Message-ID: <03696FAC-1043-224C-BE08-E429B95B1F28@hxcore.ol> An HTML attachment was scrubbed... URL: From geier at geier.ne.tz Thu Jul 23 04:36:48 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Thu, 23 Jul 2026 07:36:48 +0300 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: <00e501dd1a03$0c54a1c0$24fde540$@iptrading.com> References: <1784639031075.56443@tra.gov.eg> <00e501dd1a03$0c54a1c0$24fde540$@iptrading.com> Message-ID: <7bde9b18-2a38-4797-883b-8bca9de25242@geier.ne.tz> Hi, On 7/22/2026 8:53 PM, Mike Burns via RPD wrote: [snip] > I say, who cares if Claude is posting, or ChatGPT, or any other AI. > > Give them a seat at the table and address their arguments. > > Giving them a veneer of humanness through identity appropriation is not > the way forward. > > Again, I am interested in hearing other perspectives. I'd like to hear what should happen if then two Claudes are arguing at 5000 email per hour and eventually one Claude wins the argument, and AfriNIC will have to implement a policy that e.g. bans you from posting here? Frank Devil's advocate From seun.ojedeji at gmail.com Thu Jul 23 04:59:10 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Thu, 23 Jul 2026 00:59:10 -0400 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: <7bde9b18-2a38-4797-883b-8bca9de25242@geier.ne.tz> References: <1784639031075.56443@tra.gov.eg> <00e501dd1a03$0c54a1c0$24fde540$@iptrading.com> <7bde9b18-2a38-4797-883b-8bca9de25242@geier.ne.tz> Message-ID: Frank who will declare that the argument was won? Unless the declarant is also Claude and not one of the Co-Chairs. Nevertheless, our Co-Chairs who is empowered to moderate rpd list would have risen to the occasion to avoid getting up to 5k messages of such in the first place :-) Perhaps some wording should be included in the CoC to cover such scenario as well. Regards ---- Sent from my mobile kindly excuse typos On Thu, 23 Jul 2026, 6:38?am Frank Habicht, wrote: > Hi, > > On 7/22/2026 8:53 PM, Mike Burns via RPD wrote: > [snip] > > I say, who cares if Claude is posting, or ChatGPT, or any other AI. > > > > Give them a seat at the table and address their arguments. > > > > Giving them a veneer of humanness through identity appropriation is not > > the way forward. > > > > Again, I am interested in hearing other perspectives. > > I'd like to hear what should happen if then two Claudes are arguing at > 5000 email per hour and eventually one Claude wins the argument, and > AfriNIC will have to implement a policy that e.g. bans you from posting > here? > > Frank > Devil's advocate > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From geier at geier.ne.tz Thu Jul 23 05:19:15 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Thu, 23 Jul 2026 08:19:15 +0300 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: References: <1784639031075.56443@tra.gov.eg> <00e501dd1a03$0c54a1c0$24fde540$@iptrading.com> <7bde9b18-2a38-4797-883b-8bca9de25242@geier.ne.tz> Message-ID: <1dde3f77-24fb-4aab-a354-abed7b0fc49e@geier.ne.tz> On 7/23/2026 7:59 AM, Seun Ojedeji wrote: [snip] > Perhaps some wording should be included in the CoC > to cover such scenario as well. so you don't agree with Mike that all will be fine ....???? Frank From seun.ojedeji at gmail.com Thu Jul 23 05:27:56 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Thu, 23 Jul 2026 01:27:56 -0400 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: <1dde3f77-24fb-4aab-a354-abed7b0fc49e@geier.ne.tz> References: <1784639031075.56443@tra.gov.eg> <00e501dd1a03$0c54a1c0$24fde540$@iptrading.com> <7bde9b18-2a38-4797-883b-8bca9de25242@geier.ne.tz> <1dde3f77-24fb-4aab-a354-abed7b0fc49e@geier.ne.tz> Message-ID: Well even human is allowed to rant for a while after which moderation happens as per CoC so let the promoters have their say initially until they are made to say no more :-) Regards ---- Sent from my mobile kindly excuse typos On Thu, 23 Jul 2026, 7:19?am Frank Habicht, wrote: > On 7/23/2026 7:59 AM, Seun Ojedeji wrote: > [snip] > > Perhaps some wording should be included in the CoC > > to cover such scenario as well. > > so you don't agree with Mike that all will be fine ....???? > > Frank > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phetulodhlamini at gmail.com Thu Jul 23 05:31:27 2026 From: phetulodhlamini at gmail.com (Phetulo Dhlamini) Date: Thu, 23 Jul 2026 07:31:27 +0200 Subject: [rpd] RDP Discussion Message-ID: Hi Ben, No, you should not make that assumption. I participate in the PDP in my personal capacity and speak for myself unless I expressly state that I am authorised to represent an organisation. My affiliation provides context; it does not turn every contribution into an NRS position. Treating employment as automatic representation confuses a stakeholder with a principal and misunderstands how open PDP participation works. Regards, Phetulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From NPertuniaPetronella at outlook.com Thu Jul 23 05:36:32 2026 From: NPertuniaPetronella at outlook.com (NP Petronella) Date: Thu, 23 Jul 2026 05:36:32 +0000 Subject: [rpd] RDP Discussion Message-ID: Dear Ben, Mandla?s position is straightforward. AFRINIC?s PDP is open to anyone and imposes no qualification for participation. A contributor does not automatically represent their employer merely because an affiliation is known. Unless Mandla expressly states that he is authorised to speak for NRS, his contribution is his own. Employment is context, not a power of attorney. Assuming otherwise confuses participation with representation and suggests a misunderstanding of how an open PDP works. Please assess Mandla?s argument as Mandla?s argument. Regards, Nonhlanhla -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Thu Jul 23 05:40:06 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Thu, 23 Jul 2026 07:40:06 +0200 Subject: [rpd] RDP Discussion In-Reply-To: References: Message-ID: <5B24B1F8-93A4-4A01-AD7B-8AA02B984B08@afrinic.net> Phetulo, My email message was to Mandla who had already stated his NRS affiliation. I?m slightly confused by your reply to the message addressed to him. Are you also saying you are NRS affiliated, or that you and Mandla are the same person ? Kind regards Ben Sent from my iPhone > On 23 Jul 2026, at 07:32, Phetulo Dhlamini wrote: > > ? > Hi Ben, > > No, you should not make that assumption. > > I participate in the PDP in my personal capacity and speak for myself unless I expressly state that I am authorised to represent an organisation. My affiliation provides context; it does not turn every contribution into an NRS position. > > Treating employment as automatic representation confuses a stakeholder with a principal and misunderstands how open PDP participation works. > > Regards, > Phetulo From ben.roberts at afrinic.net Thu Jul 23 05:45:30 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Thu, 23 Jul 2026 07:45:30 +0200 Subject: [rpd] RDP Discussion In-Reply-To: References: Message-ID: <09F5D164-6E26-4438-AD9E-AFAD582CA38A@afrinic.net> Nonhlanhla, Can I assume you know Mandla and/or NRS well enough to speak on his or their behalf. ? He has clearly stated that he is a policy insights contributor at NRS. So if he then contributes policy insights, you can see why it appears that he is doing is assigned job for his employer ? Kind regards Ben Previous message from Mandla? Good day, Mandla,Policy insights contributor at NRS. Regards _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd Sent from my iPhone > On 23 Jul 2026, at 07:36, NP Petronella wrote: > > ? > Dear Ben, > > Mandla?s position is straightforward. AFRINIC?s PDP is open to anyone and imposes no qualification for participation. A contributor does not automatically represent their employer merely because an affiliation is known. > > Unless Mandla expressly states that he is authorised to speak for NRS, his contribution is his own. Employment is context, not a power of attorney. > > Assuming otherwise confuses participation with representation and suggests a misunderstanding of how an open PDP works. Please assess Mandla?s argument as Mandla?s argument. > > Regards, > Nonhlanhla -------------- next part -------------- An HTML attachment was scrubbed... URL: From geier at geier.ne.tz Thu Jul 23 05:46:33 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Thu, 23 Jul 2026 08:46:33 +0300 Subject: [rpd] RDP Discussion In-Reply-To: References: Message-ID: <10137c47-398a-41ec-9bd0-a228a0017841@geier.ne.tz> Hi. On 7/23/2026 8:36 AM, NP Petronella wrote: > Dear Ben, > > Mandla?s position is straightforward. AFRINIC?s PDP is open to anyone > and imposes no qualification for participation. A contributor does not > automatically represent their employer merely because an affiliation is > known. I start wondering if we need a separate group - with only a subset of participants - where this kind of (repeated) lecturing about what the PDP is will be welcome. I was working under the assumption that members of this mailing list already know that the PDP is open. as to the original question, which somehow was not quoted: a question was asked by Ben and one answer by one person with one statement was sufficient. No. I'm not trying to moderate. I just hope for a better signal/noise ratio. And if this here email results in more noise, i have failed. Frank > Unless Mandla expressly states that he is authorised to speak for NRS, > his contribution is his own. Employment is context, not a power of attorney. > > Assuming otherwise confuses participation with representation and > suggests a misunderstanding of how an open PDP works. Please assess > Mandla?s argument as Mandla?s argument. > > Regards, > Nonhlanhla > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From NPertuniaPetronella at outlook.com Thu Jul 23 05:51:20 2026 From: NPertuniaPetronella at outlook.com (NP Petronella) Date: Thu, 23 Jul 2026 05:51:20 +0000 Subject: [rpd] RDP Discussion In-Reply-To: <09F5D164-6E26-4438-AD9E-AFAD582CA38A@afrinic.net> References: <09F5D164-6E26-4438-AD9E-AFAD582CA38A@afrinic.net> Message-ID: Hi Ben, You certainly make a lot of assumptions about people. No, I do not speak for Mandla or NRS. I responded to a general point on a public mailing list. Supporting another participant?s argument does not create an affiliation, agency relationship, or shared identity. Mandla?s job title also does not mean every contribution he makes is an assigned organisational statement. Unless he expressly says he is authorised to represent NRS, his contribution is his own. You may ask Mandla about his capacity, but you should not invent one for either of us. That is the basic distinction between participation and representation. Please address the argument instead of constructing relationships between the people raising it. Regards, Nonhlanhla ________________________________ From: Ben Roberts - AfriNIC Sent: Thursday, 23 July 2026 07:45:30 To: Petronella NP Cc: rpd at afrinic.net Subject: Re: [rpd] RDP Discussion Nonhlanhla, Can I assume you know Mandla and/or NRS well enough to speak on his or their behalf. ? He has clearly stated that he is a policy insights contributor at NRS. So if he then contributes policy insights, you can see why it appears that he is doing is assigned job for his employer ? Kind regards Ben Previous message from Mandla? Good day, Mandla,Policy insights contributor at NRS. Regards _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd Sent from my iPhone On 23 Jul 2026, at 07:36, NP Petronella wrote: ? Dear Ben, Mandla?s position is straightforward. AFRINIC?s PDP is open to anyone and imposes no qualification for participation. A contributor does not automatically represent their employer merely because an affiliation is known. Unless Mandla expressly states that he is authorised to speak for NRS, his contribution is his own. Employment is context, not a power of attorney. Assuming otherwise confuses participation with representation and suggests a misunderstanding of how an open PDP works. Please assess Mandla?s argument as Mandla?s argument. Regards, Nonhlanhla -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Thu Jul 23 06:08:40 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Thu, 23 Jul 2026 08:08:40 +0200 Subject: [rpd] RDP Discussion In-Reply-To: References: Message-ID: <54614A26-B951-4CDC-B68E-BFE6693F296A@afrinic.net> > Nonhlanhla, > My mail was clearly and unequivocally addressed to Mandla asking him a valid question. It was not a general point for discussion, so there was no need to answer for him. But thanks for stepping in to clarify affiliations. We now fully understand. Kind regards Ben Sent from my iPhone > On 23 Jul 2026, at 07:51, NP Petronella wrote: > > ? > Hi Ben, > > You certainly make a lot of assumptions about people. > > No, I do not speak for Mandla or NRS. I responded to a general point on a public mailing list. Supporting another participant?s argument does not create an affiliation, agency relationship, or shared identity. > > Mandla?s job title also does not mean every contribution he makes is an assigned organisational statement. Unless he expressly says he is authorised to represent NRS, his contribution is his own. You may ask Mandla about his capacity, but you should not invent one for either of us. > > That is the basic distinction between participation and representation. Please address the argument instead of constructing relationships between the people raising it. > > Regards, > Nonhlanhla > > > > > > From: Ben Roberts - AfriNIC > Sent: Thursday, 23 July 2026 07:45:30 > To: Petronella NP > Cc: rpd at afrinic.net > Subject: Re: [rpd] RDP Discussion > > Nonhlanhla, > > Can I assume you know Mandla and/or NRS well enough to speak on his or their behalf. ? > > He has clearly stated that he is a policy insights contributor at NRS. So if he then contributes policy insights, you can see why it appears that he is doing is assigned job for his employer ? > > Kind regards > Ben > > Previous message from Mandla? > > Good day, > > Mandla,Policy insights contributor at NRS. > > Regards > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > Sent from my iPhone > >>> On 23 Jul 2026, at 07:36, NP Petronella wrote: >>> >> ? >> Dear Ben, >> >> Mandla?s position is straightforward. AFRINIC?s PDP is open to anyone and imposes no qualification for participation. A contributor does not automatically represent their employer merely because an affiliation is known. >> >> Unless Mandla expressly states that he is authorised to speak for NRS, his contribution is his own. Employment is context, not a power of attorney. >> >> Assuming otherwise confuses participation with representation and suggests a misunderstanding of how an open PDP works. Please assess Mandla?s argument as Mandla?s argument. >> >> Regards, >> Nonhlanhla -------------- next part -------------- An HTML attachment was scrubbed... URL: From NPertuniaPetronella at outlook.com Thu Jul 23 06:13:35 2026 From: NPertuniaPetronella at outlook.com (NP Petronella) Date: Thu, 23 Jul 2026 06:13:35 +0000 Subject: [rpd] RDP Discussion In-Reply-To: <54614A26-B951-4CDC-B68E-BFE6693F296A@afrinic.net> References: <54614A26-B951-4CDC-B68E-BFE6693F296A@afrinic.net> Message-ID: Dear Ben, You are drawing more from my reply than it said. This is a public policy forum. Responding to a point does not mean I am answering for Mandla, speaking for NRS, or clarifying anyone?s affiliation. Mandla can answer for himself. I challenged the assumption that a person?s employment automatically turns an individual contribution into an organisational position. Open participation means participants may engage with arguments wherever they appear in the discussion. Unless someone expressly claims authorisation to represent an organisation, their contribution should be treated as their own. Please do not convert ordinary participation into inferred affiliations or relationships. Let us return to the policy. Regards, Nonhlanhla ________________________________ From: Ben Roberts - AfriNIC Sent: Thursday, 23 July 2026 08:08:40 To: Petronella NP Cc: rpd at afrinic.net Subject: Re: [rpd] RDP Discussion Nonhlanhla, My mail was clearly and unequivocally addressed to Mandla asking him a valid question. It was not a general point for discussion, so there was no need to answer for him. But thanks for stepping in to clarify affiliations. We now fully understand. Kind regards Ben Sent from my iPhone On 23 Jul 2026, at 07:51, NP Petronella wrote: ? Hi Ben, You certainly make a lot of assumptions about people. No, I do not speak for Mandla or NRS. I responded to a general point on a public mailing list. Supporting another participant?s argument does not create an affiliation, agency relationship, or shared identity. Mandla?s job title also does not mean every contribution he makes is an assigned organisational statement. Unless he expressly says he is authorised to represent NRS, his contribution is his own. You may ask Mandla about his capacity, but you should not invent one for either of us. That is the basic distinction between participation and representation. Please address the argument instead of constructing relationships between the people raising it. Regards, Nonhlanhla ________________________________ From: Ben Roberts - AfriNIC Sent: Thursday, 23 July 2026 07:45:30 To: Petronella NP Cc: rpd at afrinic.net Subject: Re: [rpd] RDP Discussion Nonhlanhla, Can I assume you know Mandla and/or NRS well enough to speak on his or their behalf. ? He has clearly stated that he is a policy insights contributor at NRS. So if he then contributes policy insights, you can see why it appears that he is doing is assigned job for his employer ? Kind regards Ben Previous message from Mandla? Good day, Mandla,Policy insights contributor at NRS. Regards _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd Sent from my iPhone On 23 Jul 2026, at 07:36, NP Petronella wrote: ? Dear Ben, Mandla?s position is straightforward. AFRINIC?s PDP is open to anyone and imposes no qualification for participation. A contributor does not automatically represent their employer merely because an affiliation is known. Unless Mandla expressly states that he is authorised to speak for NRS, his contribution is his own. Employment is context, not a power of attorney. Assuming otherwise confuses participation with representation and suggests a misunderstanding of how an open PDP works. Please assess Mandla?s argument as Mandla?s argument. Regards, Nonhlanhla -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Thu Jul 23 06:16:43 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Thu, 23 Jul 2026 08:16:43 +0200 Subject: [rpd] RDP Discussion In-Reply-To: References: Message-ID: <2A5EA893-CF14-4C5E-BA39-EDF1233C16AD@afrinic.net> Noted and fully understood. Sent from my iPhone > On 23 Jul 2026, at 08:13, NP Petronella wrote: > > ? > Dear Ben, > You are drawing more from my reply than it said. > > This is a public policy forum. Responding to a point does not mean I am answering for Mandla, speaking for NRS, or clarifying anyone?s affiliation. Mandla can answer for himself. I challenged the assumption that a person?s employment automatically turns an individual contribution into an organisational position. > > Open participation means participants may engage with arguments wherever they appear in the discussion. Unless someone expressly claims authorisation to represent an organisation, their contribution should be treated as their own. > > Please do not convert ordinary participation into inferred affiliations or relationships. Let us return to the policy. > > Regards, > Nonhlanhla > > > From: Ben Roberts - AfriNIC > Sent: Thursday, 23 July 2026 08:08:40 > To: Petronella NP > Cc: rpd at afrinic.net > Subject: Re: [rpd] RDP Discussion > >> Nonhlanhla, >> > My mail was clearly and unequivocally addressed to Mandla asking him a valid question. > > It was not a general point for discussion, so there was no need to answer for him. But thanks for stepping in to clarify affiliations. We now fully understand. > > Kind regards > Ben > > Sent from my iPhone > >>> On 23 Jul 2026, at 07:51, NP Petronella wrote: >>> >> ? >> Hi Ben, >> >> You certainly make a lot of assumptions about people. >> >> No, I do not speak for Mandla or NRS. I responded to a general point on a public mailing list. Supporting another participant?s argument does not create an affiliation, agency relationship, or shared identity. >> >> Mandla?s job title also does not mean every contribution he makes is an assigned organisational statement. Unless he expressly says he is authorised to represent NRS, his contribution is his own. You may ask Mandla about his capacity, but you should not invent one for either of us. >> >> That is the basic distinction between participation and representation. Please address the argument instead of constructing relationships between the people raising it. >> >> Regards, >> Nonhlanhla >> >> >> >> >> >> From: Ben Roberts - AfriNIC >> Sent: Thursday, 23 July 2026 07:45:30 >> To: Petronella NP >> Cc: rpd at afrinic.net >> Subject: Re: [rpd] RDP Discussion >> >> Nonhlanhla, >> >> Can I assume you know Mandla and/or NRS well enough to speak on his or their behalf. ? >> >> He has clearly stated that he is a policy insights contributor at NRS. So if he then contributes policy insights, you can see why it appears that he is doing is assigned job for his employer ? >> >> Kind regards >> Ben >> >> Previous message from Mandla? >> >> Good day, >> >> Mandla,Policy insights contributor at NRS. >> >> Regards >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> Sent from my iPhone >> >>> On 23 Jul 2026, at 07:36, NP Petronella wrote: >>> >>> ? >>> Dear Ben, >>> >>> Mandla?s position is straightforward. AFRINIC?s PDP is open to anyone and imposes no qualification for participation. A contributor does not automatically represent their employer merely because an affiliation is known. >>> >>> Unless Mandla expressly states that he is authorised to speak for NRS, his contribution is his own. Employment is context, not a power of attorney. >>> >>> Assuming otherwise confuses participation with representation and suggests a misunderstanding of how an open PDP works. Please assess Mandla?s argument as Mandla?s argument. >>> >>> Regards, >>> Nonhlanhla -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonjabulosphilile at gmail.com Thu Jul 23 06:23:28 2026 From: nonjabulosphilile at gmail.com (Nonjabulo Sphilile) Date: Thu, 23 Jul 2026 08:23:28 +0200 Subject: [rpd] RDP Discussion Message-ID: Dear Ben, I believe in open participation. That means contributors speak for themselves unless they expressly state that they are authorised to represent an organisation. Mandla?s affiliation with NRS provides context, not a mandate. Assuming every employee speaks for their organisation confuses participation with representation and turns an open PDP into a contest between institutions. Please assess Mandla?s contribution as his own. Regards, Nonjabulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From seun.ojedeji at gmail.com Thu Jul 23 06:37:42 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Thu, 23 Jul 2026 08:37:42 +0200 Subject: [rpd] RDP Discussion In-Reply-To: <10137c47-398a-41ec-9bd0-a228a0017841@geier.ne.tz> References: <10137c47-398a-41ec-9bd0-a228a0017841@geier.ne.tz> Message-ID: ---- Sent from my mobile kindly excuse typos On Thu, 23 Jul 2026, 7:46?am Frank Habicht, wrote: > Hi. > > On 7/23/2026 8:36 AM, NP Petronella wrote: > > Dear Ben, > > > > Mandla?s position is straightforward. AFRINIC?s PDP is open to anyone > > and imposes no qualification for participation. A contributor does not > > automatically represent their employer merely because an affiliation is > > known. > > I start wondering if we need a separate group - with only a subset of > participants - where this kind of (repeated) lecturing about what the > PDP is will be welcome. > SO: On the above the community list could serve that purpose plus staff can come up with a PDP for beginner content and maybe a mailing list for those genuinely interested in learning to subscribe. A mentorship program targeted to PDP may come handy as well If all that is an overkill, the rpd is still a good avenue to learn about PDP, a lot of us learnt by following the rpd. The question is, are there people genuinely interested in learning for the common good. Regards > > > I was working under the assumption that members of this mailing list > already know that the PDP is open. > > as to the original question, which somehow was not quoted: a question > was asked by Ben and one answer by one person with one statement was > sufficient. > > No. I'm not trying to moderate. I just hope for a better signal/noise > ratio. And if this here email results in more noise, i have failed. > > Frank > > > > > Unless Mandla expressly states that he is authorised to speak for NRS, > > his contribution is his own. Employment is context, not a power of > attorney. > > > > Assuming otherwise confuses participation with representation and > > suggests a misunderstanding of how an open PDP works. Please assess > > Mandla?s argument as Mandla?s argument. > > > > Regards, > > Nonhlanhla > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phetulodhlamini at gmail.com Thu Jul 23 06:43:34 2026 From: phetulodhlamini at gmail.com (Phetulo Dhlamini) Date: Thu, 23 Jul 2026 08:43:34 +0200 Subject: [rpd] RDP Discussion In-Reply-To: <5B24B1F8-93A4-4A01-AD7B-8AA02B984B08@afrinic.net> References: <5B24B1F8-93A4-4A01-AD7B-8AA02B984B08@afrinic.net> Message-ID: Hi Ben, No, you should not make that assumption. I participate in the PDP in my personal capacity and speak for myself unless I expressly state that I am authorised to represent an organisation. My affiliation provides context; it does not turn every contribution into an NRS position. Treating employment as automatic representation confuses a stakeholder with a principal and misunderstands how open PDP participation works. Regards, Phetulo On Thu, 23 Jul 2026, 07:40 Ben Roberts - AfriNIC, wrote: > Phetulo, > > My email message was to Mandla who had already stated his NRS affiliation. > I?m slightly confused by your reply to the message addressed to him. Are > you also saying you are NRS affiliated, or that you and Mandla are the same > person ? > > Kind regards > Ben > > Sent from my iPhone > > > On 23 Jul 2026, at 07:32, Phetulo Dhlamini > wrote: > > > > ? > > Hi Ben, > > > > No, you should not make that assumption. > > > > I participate in the PDP in my personal capacity and speak for myself > unless I expressly state that I am authorised to represent an organisation. > My affiliation provides context; it does not turn every contribution into > an NRS position. > > > > Treating employment as automatic representation confuses a stakeholder > with a principal and misunderstands how open PDP participation works. > > > > Regards, > > Phetulo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From NPertuniaPetronella at outlook.com Thu Jul 23 06:45:26 2026 From: NPertuniaPetronella at outlook.com (NP Petronella) Date: Thu, 23 Jul 2026 06:45:26 +0000 Subject: [rpd] RPD Digest, Vol 222, Issue 179 In-Reply-To: References: Message-ID: Hi Seun, Mentorship and beginner materials could be useful, provided they remain optional and do not become a separate waiting room for unfamiliar or dissenting participants. As you noted, many people learn by following and participating in the RPD itself. No one should first have to prove expertise or satisfy an established circle that their interest serves the ?common good.? The PDP should remain one open discussion. Participation may include questions, evidence, support, warning, or objection. It should not be divided into senior voices who decide and beginners who are sent elsewhere to learn. Regards, Nonhlanhla ________________________________ From: rpd-request at afrinic.net Sent: Thursday, 23 July 2026 08:38:12 To: rpd at afrinic.net Subject: RPD Digest, Vol 222, Issue 179 Send RPD mailing list submissions to rpd at afrinic.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.afrinic.net/mailman/listinfo/rpd or, via email, send a message with subject or body 'help' to rpd-request at afrinic.net You can reach the person managing the list at rpd-owner at afrinic.net When replying, please edit your Subject line so it is more specific than "Re: Contents of RPD digest..." Today's Topics: 1. Re: RDP Discussion (Ben Roberts - AfriNIC) 2. Re: RDP Discussion (Nonjabulo Sphilile) 3. Re: RDP Discussion (Seun Ojedeji) ---------------------------------------------------------------------- Message: 1 Date: Thu, 23 Jul 2026 08:16:43 +0200 From: Ben Roberts - AfriNIC To: Petronella NP Cc: rpd at afrinic.net Subject: Re: [rpd] RDP Discussion Message-ID: <2A5EA893-CF14-4C5E-BA39-EDF1233C16AD at afrinic.net> Content-Type: text/plain; charset="utf-8" Noted and fully understood. Sent from my iPhone > On 23 Jul 2026, at 08:13, NP Petronella wrote: > > ? > Dear Ben, > You are drawing more from my reply than it said. > > This is a public policy forum. Responding to a point does not mean I am answering for Mandla, speaking for NRS, or clarifying anyone?s affiliation. Mandla can answer for himself. I challenged the assumption that a person?s employment automatically turns an individual contribution into an organisational position. > > Open participation means participants may engage with arguments wherever they appear in the discussion. Unless someone expressly claims authorisation to represent an organisation, their contribution should be treated as their own. > > Please do not convert ordinary participation into inferred affiliations or relationships. Let us return to the policy. > > Regards, > Nonhlanhla > > > From: Ben Roberts - AfriNIC > Sent: Thursday, 23 July 2026 08:08:40 > To: Petronella NP > Cc: rpd at afrinic.net > Subject: Re: [rpd] RDP Discussion > >> Nonhlanhla, >> > My mail was clearly and unequivocally addressed to Mandla asking him a valid question. > > It was not a general point for discussion, so there was no need to answer for him. But thanks for stepping in to clarify affiliations. We now fully understand. > > Kind regards > Ben > > Sent from my iPhone > >>> On 23 Jul 2026, at 07:51, NP Petronella wrote: >>> >> ? >> Hi Ben, >> >> You certainly make a lot of assumptions about people. >> >> No, I do not speak for Mandla or NRS. I responded to a general point on a public mailing list. Supporting another participant?s argument does not create an affiliation, agency relationship, or shared identity. >> >> Mandla?s job title also does not mean every contribution he makes is an assigned organisational statement. Unless he expressly says he is authorised to represent NRS, his contribution is his own. You may ask Mandla about his capacity, but you should not invent one for either of us. >> >> That is the basic distinction between participation and representation. Please address the argument instead of constructing relationships between the people raising it. >> >> Regards, >> Nonhlanhla >> >> >> >> >> >> From: Ben Roberts - AfriNIC >> Sent: Thursday, 23 July 2026 07:45:30 >> To: Petronella NP >> Cc: rpd at afrinic.net >> Subject: Re: [rpd] RDP Discussion >> >> Nonhlanhla, >> >> Can I assume you know Mandla and/or NRS well enough to speak on his or their behalf. ? >> >> He has clearly stated that he is a policy insights contributor at NRS. So if he then contributes policy insights, you can see why it appears that he is doing is assigned job for his employer ? >> >> Kind regards >> Ben >> >> Previous message from Mandla? >> >> Good day, >> >> Mandla,Policy insights contributor at NRS. >> >> Regards >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> Sent from my iPhone >> >>> On 23 Jul 2026, at 07:36, NP Petronella wrote: >>> >>> ? >>> Dear Ben, >>> >>> Mandla?s position is straightforward. AFRINIC?s PDP is open to anyone and imposes no qualification for participation. A contributor does not automatically represent their employer merely because an affiliation is known. >>> >>> Unless Mandla expressly states that he is authorised to speak for NRS, his contribution is his own. Employment is context, not a power of attorney. >>> >>> Assuming otherwise confuses participation with representation and suggests a misunderstanding of how an open PDP works. Please assess Mandla?s argument as Mandla?s argument. >>> >>> Regards, >>> Nonhlanhla -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Thu, 23 Jul 2026 08:23:28 +0200 From: Nonjabulo Sphilile To: rpd at afrinic.net Subject: Re: [rpd] RDP Discussion Message-ID: Content-Type: text/plain; charset="utf-8" Dear Ben, I believe in open participation. That means contributors speak for themselves unless they expressly state that they are authorised to represent an organisation. Mandla?s affiliation with NRS provides context, not a mandate. Assuming every employee speaks for their organisation confuses participation with representation and turns an open PDP into a contest between institutions. Please assess Mandla?s contribution as his own. Regards, Nonjabulo -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Thu, 23 Jul 2026 08:37:42 +0200 From: Seun Ojedeji To: Frank Habicht Cc: rpd Subject: Re: [rpd] RDP Discussion Message-ID: Content-Type: text/plain; charset="utf-8" ---- Sent from my mobile kindly excuse typos On Thu, 23 Jul 2026, 7:46?am Frank Habicht, wrote: > Hi. > > On 7/23/2026 8:36 AM, NP Petronella wrote: > > Dear Ben, > > > > Mandla?s position is straightforward. AFRINIC?s PDP is open to anyone > > and imposes no qualification for participation. A contributor does not > > automatically represent their employer merely because an affiliation is > > known. > > I start wondering if we need a separate group - with only a subset of > participants - where this kind of (repeated) lecturing about what the > PDP is will be welcome. > SO: On the above the community list could serve that purpose plus staff can come up with a PDP for beginner content and maybe a mailing list for those genuinely interested in learning to subscribe. A mentorship program targeted to PDP may come handy as well If all that is an overkill, the rpd is still a good avenue to learn about PDP, a lot of us learnt by following the rpd. The question is, are there people genuinely interested in learning for the common good. Regards > > > I was working under the assumption that members of this mailing list > already know that the PDP is open. > > as to the original question, which somehow was not quoted: a question > was asked by Ben and one answer by one person with one statement was > sufficient. > > No. I'm not trying to moderate. I just hope for a better signal/noise > ratio. And if this here email results in more noise, i have failed. > > Frank > > > > > Unless Mandla expressly states that he is authorised to speak for NRS, > > his contribution is his own. Employment is context, not a power of > attorney. > > > > Assuming otherwise confuses participation with representation and > > suggests a misunderstanding of how an open PDP works. Please assess > > Mandla?s argument as Mandla?s argument. > > > > Regards, > > Nonhlanhla > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ End of RPD Digest, Vol 222, Issue 179 ************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Thu Jul 23 07:17:35 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Thu, 23 Jul 2026 09:17:35 +0200 Subject: [rpd] RDP Discussion In-Reply-To: References: Message-ID: Nonjabulo, Let?s wait for what Mandla has to say? Since he has a job as a policy insights contributor for NRS, he may want his policy insights to be on behalf of NRS right ? Kind regards Ben Sent from my iPhone > On 23 Jul 2026, at 08:23, Nonjabulo Sphilile wrote: > > ? > Dear Ben, > > I believe in open participation. That means contributors speak for themselves unless they expressly state that they are authorised to represent an organisation. > > Mandla?s affiliation with NRS provides context, not a mandate. Assuming every employee speaks for their organisation confuses participation with representation and turns an open PDP into a contest between institutions. > > Please assess Mandla?s contribution as his own. > > Regards, > Nonjabulo From ben.roberts at afrinic.net Thu Jul 23 07:41:27 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Thu, 23 Jul 2026 09:41:27 +0200 Subject: [rpd] RDP Discussion In-Reply-To: References: Message-ID: <67901F2F-CB25-4760-8770-0C05F9543D2F@afrinic.net> An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Thu Jul 23 08:14:49 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Thu, 23 Jul 2026 10:14:49 +0200 Subject: [rpd] Policy supremacy In-Reply-To: References: Message-ID: Good Nonjabulo Sphilile, Hopefully I?m not responding to ChatGPT, but the real Nonjabulo Sphilile! The problem that the RDP are facing today, is the mass of objectors, that nobody knows, have not properly, honestly/truthfully answered the real questions posed to them, and then keeps spewing a regurgitated barrage of being victimized and they are the injured and they are? The word astroturfing by definition doesn?t have an exact forensically applicable definition to measure, but are evident on the probabilities. Ie. the same type of evidence and measures that a civil court of law would apply, not a criminal court as these aren?t criminal cases where innocence are assumed till proven beyond doubt. Thus, there exist prime facie evidences that the astroturfers had been succesfully named and proven. Now This being and open forum, there should be NO assumption of anonymity, and I?d state that given the astroturfers, that the assumption should be, given the nature of AfriNIC, that the request for KYC would not be a procedural problem for ANY REAL OPERATOR, but only an issue for the likes of astroturfers that needs to have the puppet-master hidden/anonymous so that nothing can be pointed back to the puppet-mster that wants to derail the procedures etc. as the outcomes would have a negative effect on their operations, I?ll even content that the reasons for the objections (given the weak arguments answered, and the evading of questions posed) might be more nefarious instead of actually objectively for the good of the continent a.k.a. AfriNIC?s communities. The idea that your participation to the is a RIGHT, I?ll only defend if and only if you can show you have a real valid concerns or ?skin in the game? with regards to AfriNIC, and then your affiliations and representations are the reasons you might have a right to speak and object. AfriNIC membership etc (and by that extension I?d say the right to be heard in the RDP, else you should be acting as a guest, not a victim) are based on the RESOURCES (AS numbers and/or addresses) you have been allocated (while being a member in good standing) or need/want to be allocated to you. As such that is the reason we?d like to know how you, as a new comer have *real* interest in these matters, not just that you have a *claimed* objection .. and when questioned, you deflect ;( --- 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 On 22 Jul 2026, at 15:45, Nonjabulo Sphilile wrote: > Hi Musa, > > The PDWG is open. Participation does not depend on being known to > long-standing members, attending earlier meetings, or proving a > professional stake after joining. New participation is still > participation. > > KYC would be a serious procedural change, not an informal test for > unfamiliar objectors. Any such requirement would need to be formally > adopted, proportionate, privacy-preserving, and applied equally to > established and new participants. > > Similar views are not proof of impersonation. If there is concrete > evidence > of misconduct, please submit it to the co-chairs. Otherwise, I will > not > continue discussing identities or drafting methods. > > Let us return to the policy. > > Regards, > Nonjabulo > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From phetulodhlamini at gmail.com Thu Jul 23 08:23:41 2026 From: phetulodhlamini at gmail.com (Phetulo Dhlamini) Date: Thu, 23 Jul 2026 10:23:41 +0200 Subject: [rpd] RDP Discussion In-Reply-To: References: <5B24B1F8-93A4-4A01-AD7B-8AA02B984B08@afrinic.net> Message-ID: Dear Ben, No, I am not saying that I am affiliated with NRS, nor that Mandla and I are the same person. I replied because I was making a general point, using Mandla?s situation as an example: a participant?s affiliation does not automatically make their personal contribution an organisational position. Mandla can speak for himself, and I speak only for myself. This is a public discussion. Responding to a point does not require being the person originally addressed. Regards, Phetulo On Thu, 23 Jul 2026, 08:43 Phetulo Dhlamini, wrote: > Hi Ben, > > No, you should not make that assumption. > > I participate in the PDP in my personal capacity and speak for myself > unless I expressly state that I am authorised to represent an organisation. > My affiliation provides context; it does not turn every contribution into > an NRS position. > > Treating employment as automatic representation confuses a stakeholder > with a principal and misunderstands how open PDP participation works. > > Regards, > Phetulo > > On Thu, 23 Jul 2026, 07:40 Ben Roberts - AfriNIC, > wrote: > >> Phetulo, >> >> My email message was to Mandla who had already stated his NRS >> affiliation. I?m slightly confused by your reply to the message addressed >> to him. Are you also saying you are NRS affiliated, or that you and Mandla >> are the same person ? >> >> Kind regards >> Ben >> >> Sent from my iPhone >> >> > On 23 Jul 2026, at 07:32, Phetulo Dhlamini >> wrote: >> > >> > ? >> > Hi Ben, >> > >> > No, you should not make that assumption. >> > >> > I participate in the PDP in my personal capacity and speak for myself >> unless I expressly state that I am authorised to represent an organisation. >> My affiliation provides context; it does not turn every contribution into >> an NRS position. >> > >> > Treating employment as automatic representation confuses a stakeholder >> with a principal and misunderstands how open PDP participation works. >> > >> > Regards, >> > Phetulo >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonjabulosphilile at gmail.com Thu Jul 23 08:37:42 2026 From: nonjabulosphilile at gmail.com (Nonjabulo Sphilile) Date: Thu, 23 Jul 2026 10:37:42 +0200 Subject: [rpd] RDP Discussion In-Reply-To: References: Message-ID: Dear Ben and Hendrik, Ben, Mandla can answer for himself. Unless he expressly says he is authorised to represent NRS, his comments should be treated as his own. An affiliation gives context; it is not a power of attorney. My responding to that general principle on a public mailing list does not mean I speak for Mandla or share his affiliation. Hendrik, similar wording, new email accounts, or an AI system?s opinion about writing style do not prove astroturfing. A civil standard of proof is applied by an authorised decision-maker to actual evidence. It is not a label that one mailing-list participant may declare proven because Claude produced a probability. Operational experience is valuable, but it does not give established operators exclusive authority over participation. New participants may ask questions, raise objections, and challenge the scope of a policy. They are not required to arrive as apprentices seeking permission from familiar voices. Any KYC requirement would need a formal basis, demonstrated necessity, privacy safeguards, and equal application to everyone. It cannot be improvised selectively for unfamiliar objectors. Otherwise, ?community protection? becomes a way for a small circle to decide who qualifies as the community. I am a real participant. I choose my position, review what I submit, and take responsibility for it. If either of you has evidence of impersonation, automated flooding, or a specific breach, submit it to the co-chairs. I will not engage further with personal speculation about my identity or writing tools. Please return to the policy and address the arguments themselves. Regards, Nonjabulo On Thu, 23 Jul 2026, 09:17 Ben Roberts - AfriNIC, wrote: > Nonjabulo, > Let?s wait for what Mandla has to say? Since he has a job as a policy > insights contributor for NRS, he may want his policy insights to be on > behalf of NRS right ? > > Kind regards > Ben > Sent from my iPhone > > > On 23 Jul 2026, at 08:23, Nonjabulo Sphilile < > nonjabulosphilile at gmail.com> wrote: > > > > ? > > Dear Ben, > > > > I believe in open participation. That means contributors speak for > themselves unless they expressly state that they are authorised to > represent an organisation. > > > > Mandla?s affiliation with NRS provides context, not a mandate. Assuming > every employee speaks for their organisation confuses participation with > representation and turns an open PDP into a contest between institutions. > > > > Please assess Mandla?s contribution as his own. > > > > Regards, > > Nonjabulo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From NPertuniaPetronella at outlook.com Thu Jul 23 08:38:21 2026 From: NPertuniaPetronella at outlook.com (NP Petronella) Date: Thu, 23 Jul 2026 08:38:21 +0000 Subject: [rpd] RPD Digest, Vol 222, Issue 181 In-Reply-To: References: Message-ID: Dear Hendrik, I am concerned by the power dynamic in your message. You have appointed yourself investigator, judge, and gatekeeper, then treated your own suspicions as ?prima facie evidence.? That is not how evidence works. A civil standard is applied by an authorised decision-maker after evidence is tested, not declared by a mailing-list participant who has already chosen the verdict. Your proposed ?skin in the game? test is equally troubling. Operational experience is valuable evidence, but it does not give resource holders exclusive ownership of the PDP or authority to classify everyone else as guests. Stakeholders may contribute expertise, questions, warnings, and objections. They do not thereby become principals for the entire community. What is happening here is a clear power play: disagreement is relabelled as suspicious, suspicion becomes a demand for identity, and identity is then made a condition for being heard. That is mandate laundering in miniature. If identity verification is genuinely needed, propose it formally. Define its purpose, protect privacy, apply it equally to established and new participants, and place it under neutral administration. It cannot be invented selectively for unfamiliar objectors. If you have evidence of impersonation, automated flooding, or an actual procedural breach, submit it to the co-chairs. Otherwise, address the arguments. The PDWG is not a private club, and familiar operators do not get to decide who counts as human, who counts as community, or who has permission to speak. Regards, Nonhlanhla ________________________________ From: rpd-request at afrinic.net Sent: Thursday, 23 July 2026 10:23:41 To: rpd at afrinic.net Subject: RPD Digest, Vol 222, Issue 181 Send RPD mailing list submissions to rpd at afrinic.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.afrinic.net/mailman/listinfo/rpd or, via email, send a message with subject or body 'help' to rpd-request at afrinic.net You can reach the person managing the list at rpd-owner at afrinic.net When replying, please edit your Subject line so it is more specific than "Re: Contents of RPD digest..." Today's Topics: 1. Re: RDP Discussion (Ben Roberts - AfriNIC) 2. Re: RDP Discussion (Ben Roberts - AfriNIC) 3. Re: Policy supremacy (Hendrik Visage) 4. Re: RDP Discussion (Phetulo Dhlamini) ---------------------------------------------------------------------- Message: 1 Date: Thu, 23 Jul 2026 09:17:35 +0200 From: Ben Roberts - AfriNIC To: Nonjabulo Sphilile Cc: rpd at afrinic.net Subject: Re: [rpd] RDP Discussion Message-ID: Content-Type: text/plain; charset=utf-8 Nonjabulo, Let?s wait for what Mandla has to say? Since he has a job as a policy insights contributor for NRS, he may want his policy insights to be on behalf of NRS right ? Kind regards Ben Sent from my iPhone > On 23 Jul 2026, at 08:23, Nonjabulo Sphilile wrote: > > ? > Dear Ben, > > I believe in open participation. That means contributors speak for themselves unless they expressly state that they are authorised to represent an organisation. > > Mandla?s affiliation with NRS provides context, not a mandate. Assuming every employee speaks for their organisation confuses participation with representation and turns an open PDP into a contest between institutions. > > Please assess Mandla?s contribution as his own. > > Regards, > Nonjabulo ------------------------------ Message: 2 Date: Thu, 23 Jul 2026 09:41:27 +0200 From: Ben Roberts - AfriNIC To: Phetulo Dhlamini Cc: rpd at afrinic.net Subject: Re: [rpd] RDP Discussion Message-ID: <67901F2F-CB25-4760-8770-0C05F9543D2F at afrinic.net> Content-Type: text/plain; charset="us-ascii" An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Thu, 23 Jul 2026 10:14:49 +0200 From: Hendrik Visage To: Nonjabulo Sphilile Cc: rpd at afrinic.net Subject: Re: [rpd] Policy supremacy Message-ID: Content-Type: text/plain; charset="utf-8"; Format="flowed" Good Nonjabulo Sphilile, Hopefully I?m not responding to ChatGPT, but the real Nonjabulo Sphilile! The problem that the RDP are facing today, is the mass of objectors, that nobody knows, have not properly, honestly/truthfully answered the real questions posed to them, and then keeps spewing a regurgitated barrage of being victimized and they are the injured and they are? The word astroturfing by definition doesn?t have an exact forensically applicable definition to measure, but are evident on the probabilities. Ie. the same type of evidence and measures that a civil court of law would apply, not a criminal court as these aren?t criminal cases where innocence are assumed till proven beyond doubt. Thus, there exist prime facie evidences that the astroturfers had been succesfully named and proven. Now This being and open forum, there should be NO assumption of anonymity, and I?d state that given the astroturfers, that the assumption should be, given the nature of AfriNIC, that the request for KYC would not be a procedural problem for ANY REAL OPERATOR, but only an issue for the likes of astroturfers that needs to have the puppet-master hidden/anonymous so that nothing can be pointed back to the puppet-mster that wants to derail the procedures etc. as the outcomes would have a negative effect on their operations, I?ll even content that the reasons for the objections (given the weak arguments answered, and the evading of questions posed) might be more nefarious instead of actually objectively for the good of the continent a.k.a. AfriNIC?s communities. The idea that your participation to the is a RIGHT, I?ll only defend if and only if you can show you have a real valid concerns or ?skin in the game? with regards to AfriNIC, and then your affiliations and representations are the reasons you might have a right to speak and object. AfriNIC membership etc (and by that extension I?d say the right to be heard in the RDP, else you should be acting as a guest, not a victim) are based on the RESOURCES (AS numbers and/or addresses) you have been allocated (while being a member in good standing) or need/want to be allocated to you. As such that is the reason we?d like to know how you, as a new comer have *real* interest in these matters, not just that you have a *claimed* objection .. and when questioned, you deflect ;( --- 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 On 22 Jul 2026, at 15:45, Nonjabulo Sphilile wrote: > Hi Musa, > > The PDWG is open. Participation does not depend on being known to > long-standing members, attending earlier meetings, or proving a > professional stake after joining. New participation is still > participation. > > KYC would be a serious procedural change, not an informal test for > unfamiliar objectors. Any such requirement would need to be formally > adopted, proportionate, privacy-preserving, and applied equally to > established and new participants. > > Similar views are not proof of impersonation. If there is concrete > evidence > of misconduct, please submit it to the co-chairs. Otherwise, I will > not > continue discussing identities or drafting methods. > > Let us return to the policy. > > Regards, > Nonjabulo > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Thu, 23 Jul 2026 10:23:41 +0200 From: Phetulo Dhlamini To: rpd at afrinic.net Subject: Re: [rpd] RDP Discussion Message-ID: Content-Type: text/plain; charset="utf-8" Dear Ben, No, I am not saying that I am affiliated with NRS, nor that Mandla and I are the same person. I replied because I was making a general point, using Mandla?s situation as an example: a participant?s affiliation does not automatically make their personal contribution an organisational position. Mandla can speak for himself, and I speak only for myself. This is a public discussion. Responding to a point does not require being the person originally addressed. Regards, Phetulo On Thu, 23 Jul 2026, 08:43 Phetulo Dhlamini, wrote: > Hi Ben, > > No, you should not make that assumption. > > I participate in the PDP in my personal capacity and speak for myself > unless I expressly state that I am authorised to represent an organisation. > My affiliation provides context; it does not turn every contribution into > an NRS position. > > Treating employment as automatic representation confuses a stakeholder > with a principal and misunderstands how open PDP participation works. > > Regards, > Phetulo > > On Thu, 23 Jul 2026, 07:40 Ben Roberts - AfriNIC, > wrote: > >> Phetulo, >> >> My email message was to Mandla who had already stated his NRS >> affiliation. I?m slightly confused by your reply to the message addressed >> to him. Are you also saying you are NRS affiliated, or that you and Mandla >> are the same person ? >> >> Kind regards >> Ben >> >> Sent from my iPhone >> >> > On 23 Jul 2026, at 07:32, Phetulo Dhlamini >> wrote: >> > >> > ? >> > Hi Ben, >> > >> > No, you should not make that assumption. >> > >> > I participate in the PDP in my personal capacity and speak for myself >> unless I expressly state that I am authorised to represent an organisation. >> My affiliation provides context; it does not turn every contribution into >> an NRS position. >> > >> > Treating employment as automatic representation confuses a stakeholder >> with a principal and misunderstands how open PDP participation works. >> > >> > Regards, >> > Phetulo >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ End of RPD Digest, Vol 222, Issue 181 ************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Thu Jul 23 08:41:06 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Thu, 23 Jul 2026 10:41:06 +0200 Subject: [rpd] RDP Discussion In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From zamaphathwaphathwa at gmail.com Thu Jul 23 08:44:27 2026 From: zamaphathwaphathwa at gmail.com (Zamaphathwa Phathwa) Date: Thu, 23 Jul 2026 10:44:27 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 131 Message-ID: Dear Andrew and Mike, Two separate issues are being mixed together. If someone is genuinely flooding the list, impersonating others, or deliberately disrupting discussion, the co-chairs should address that conduct under neutral rules. But similar arguments, unfamiliar names, AI-assisted drafting, or LinkedIn profiles do not prove coordination or bad faith. Suspicion is not evidence. Andrew, I also disagree that an objection is valid only when it proves immediate operational harm. A proposal may be technically workable and still be unnecessary, disproportionate, or the wrong instrument. Scope, reversibility, and expansion of registry enforcement are legitimate policy concerns. Saying that necessity is irrelevant is precisely how procedure begins manufacturing its own mandate. Mike, list traffic can be managed through threading, reasonable posting limits, and consolidation of repeated issues. The co-chairs may treat several similar messages as one substantive objection without treating the participants themselves as illegitimate. Calling ordinary AI-assisted participation a potential ?DDoS? risks turning moderation into gatekeeping before any disruptive conduct has been proven. The tool is not the participant. The person who reviews, submits, and stands behind the message is. Rough consensus should be based on distinct arguments and evidence, not reputation, professional affiliation, writing style, or assumptions about which software was used. Regards, Zamaphathwa -------------- next part -------------- An HTML attachment was scrubbed... URL: From NPertuniaPetronella at outlook.com Thu Jul 23 08:53:33 2026 From: NPertuniaPetronella at outlook.com (NP Petronella) Date: Thu, 23 Jul 2026 08:53:33 +0000 Subject: [rpd] RPD Digest, Vol 222, Issue 181 In-Reply-To: References: Message-ID: Dear Hendrik, No one is putting words in your mouth. You called unfamiliar objectors "astroturfers", argued that participation should depend on proving ?skin in the game,? and proposed KYC as a test of legitimacy. Describing that as gatekeeping is a fair reading of your own words. I do not oppose identity verification. I previously supported a limited, neutral process. But supporting verification is not the same as giving individual participants authority to investigate or certify others. Any verification system must have a formal basis, demonstrated necessity, privacy safeguards, neutral administration, and equal application to established and new participants. It should confirm only that a real person controls an account, not impose an industry-experience, affiliation, or viewpoint test. Until such a process exists, suspicion is not proof and familiarity is not authority. If you have evidence of a specific breach, submit it to the co-chairs. Otherwise, address the policy rather than the eligibility of those questioning it. Regards, Nonhlanhla ________________________________ From: Hendrik Visage Sent: Thursday, 23 July 2026 10:41:15 To: NP Petronella Subject: Re: RPD Digest, Vol 222, Issue 181 oh you are now putting words on my mouth and acting as a victim, not taking responsibility for your pov! ________________________________ 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 On 23 Jul 2026, at 10:38, NP Petronella wrote: Dear Hendrik, I am concerned by the power dynamic in your message. You have appointed yourself investigator, judge, and gatekeeper, then treated your own suspicions as ?prima facie evidence.? That is not how evidence works. A civil standard is applied by an authorised decision-maker after evidence is tested, not declared by a mailing-list participant who has already chosen the verdict. Your proposed ?skin in the game? test is equally troubling. Operational experience is valuable evidence, but it does not give resource holders exclusive ownership of the PDP or authority to classify everyone else as guests. Stakeholders may contribute expertise, questions, warnings, and objections. They do not thereby become principals for the entire community. What is happening here is a clear power play: disagreement is relabelled as suspicious, suspicion becomes a demand for identity, and identity is then made a condition for being heard. That is mandate laundering in miniature. If identity verification is genuinely needed, propose it formally. Define its purpose, protect privacy, apply it equally to established and new participants, and place it under neutral administration. It cannot be invented selectively for unfamiliar objectors. If you have evidence of impersonation, automated flooding, or an actual procedural breach, submit it to the co-chairs. Otherwise, address the arguments. The PDWG is not a private club, and familiar operators do not get to decide who counts as human, who counts as community, or who has permission to speak. Regards, Nonhlanhla ________________________________ From: rpd-request at afrinic.net Sent: Thursday, 23 July 2026 10:23:41 To: rpd at afrinic.net Subject: RPD Digest, Vol 222, Issue 181 Send RPD mailing list submissions to rpd at afrinic.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.afrinic.net/mailman/listinfo/rpd or, via email, send a message with subject or body 'help' to rpd-request at afrinic.net You can reach the person managing the list at rpd-owner at afrinic.net When replying, please edit your Subject line so it is more specific than "Re: Contents of RPD digest..." Today's Topics: 1. Re: RDP Discussion (Ben Roberts - AfriNIC) 2. Re: RDP Discussion (Ben Roberts - AfriNIC) 3. Re: Policy supremacy (Hendrik Visage) 4. Re: RDP Discussion (Phetulo Dhlamini) ---------------------------------------------------------------------- Message: 1 Date: Thu, 23 Jul 2026 09:17:35 +0200 From: Ben Roberts - AfriNIC To: Nonjabulo Sphilile Cc: rpd at afrinic.net Subject: Re: [rpd] RDP Discussion Message-ID: Content-Type: text/plain; charset=utf-8 Nonjabulo, Let?s wait for what Mandla has to say? Since he has a job as a policy insights contributor for NRS, he may want his policy insights to be on behalf of NRS right ? Kind regards Ben Sent from my iPhone > On 23 Jul 2026, at 08:23, Nonjabulo Sphilile wrote: > > ? > Dear Ben, > > I believe in open participation. That means contributors speak for themselves unless they expressly state that they are authorised to represent an organisation. > > Mandla?s affiliation with NRS provides context, not a mandate. Assuming every employee speaks for their organisation confuses participation with representation and turns an open PDP into a contest between institutions. > > Please assess Mandla?s contribution as his own. > > Regards, > Nonjabulo ------------------------------ Message: 2 Date: Thu, 23 Jul 2026 09:41:27 +0200 From: Ben Roberts - AfriNIC To: Phetulo Dhlamini Cc: rpd at afrinic.net Subject: Re: [rpd] RDP Discussion Message-ID: <67901F2F-CB25-4760-8770-0C05F9543D2F at afrinic.net> Content-Type: text/plain; charset="us-ascii" An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Thu, 23 Jul 2026 10:14:49 +0200 From: Hendrik Visage To: Nonjabulo Sphilile Cc: rpd at afrinic.net Subject: Re: [rpd] Policy supremacy Message-ID: Content-Type: text/plain; charset="utf-8"; Format="flowed" Good Nonjabulo Sphilile, Hopefully I?m not responding to ChatGPT, but the real Nonjabulo Sphilile! The problem that the RDP are facing today, is the mass of objectors, that nobody knows, have not properly, honestly/truthfully answered the real questions posed to them, and then keeps spewing a regurgitated barrage of being victimized and they are the injured and they are? The word astroturfing by definition doesn?t have an exact forensically applicable definition to measure, but are evident on the probabilities. Ie. the same type of evidence and measures that a civil court of law would apply, not a criminal court as these aren?t criminal cases where innocence are assumed till proven beyond doubt. Thus, there exist prime facie evidences that the astroturfers had been succesfully named and proven. Now This being and open forum, there should be NO assumption of anonymity, and I?d state that given the astroturfers, that the assumption should be, given the nature of AfriNIC, that the request for KYC would not be a procedural problem for ANY REAL OPERATOR, but only an issue for the likes of astroturfers that needs to have the puppet-master hidden/anonymous so that nothing can be pointed back to the puppet-mster that wants to derail the procedures etc. as the outcomes would have a negative effect on their operations, I?ll even content that the reasons for the objections (given the weak arguments answered, and the evading of questions posed) might be more nefarious instead of actually objectively for the good of the continent a.k.a. AfriNIC?s communities. The idea that your participation to the is a RIGHT, I?ll only defend if and only if you can show you have a real valid concerns or ?skin in the game? with regards to AfriNIC, and then your affiliations and representations are the reasons you might have a right to speak and object. AfriNIC membership etc (and by that extension I?d say the right to be heard in the RDP, else you should be acting as a guest, not a victim) are based on the RESOURCES (AS numbers and/or addresses) you have been allocated (while being a member in good standing) or need/want to be allocated to you. As such that is the reason we?d like to know how you, as a new comer have *real* interest in these matters, not just that you have a *claimed* objection .. and when questioned, you deflect ;( --- 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 On 22 Jul 2026, at 15:45, Nonjabulo Sphilile wrote: > Hi Musa, > > The PDWG is open. Participation does not depend on being known to > long-standing members, attending earlier meetings, or proving a > professional stake after joining. New participation is still > participation. > > KYC would be a serious procedural change, not an informal test for > unfamiliar objectors. Any such requirement would need to be formally > adopted, proportionate, privacy-preserving, and applied equally to > established and new participants. > > Similar views are not proof of impersonation. If there is concrete > evidence > of misconduct, please submit it to the co-chairs. Otherwise, I will > not > continue discussing identities or drafting methods. > > Let us return to the policy. > > Regards, > Nonjabulo > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 4 Date: Thu, 23 Jul 2026 10:23:41 +0200 From: Phetulo Dhlamini To: rpd at afrinic.net Subject: Re: [rpd] RDP Discussion Message-ID: Content-Type: text/plain; charset="utf-8" Dear Ben, No, I am not saying that I am affiliated with NRS, nor that Mandla and I are the same person. I replied because I was making a general point, using Mandla?s situation as an example: a participant?s affiliation does not automatically make their personal contribution an organisational position. Mandla can speak for himself, and I speak only for myself. This is a public discussion. Responding to a point does not require being the person originally addressed. Regards, Phetulo On Thu, 23 Jul 2026, 08:43 Phetulo Dhlamini, wrote: > Hi Ben, > > No, you should not make that assumption. > > I participate in the PDP in my personal capacity and speak for myself > unless I expressly state that I am authorised to represent an organisation. > My affiliation provides context; it does not turn every contribution into > an NRS position. > > Treating employment as automatic representation confuses a stakeholder > with a principal and misunderstands how open PDP participation works. > > Regards, > Phetulo > > On Thu, 23 Jul 2026, 07:40 Ben Roberts - AfriNIC, > wrote: > >> Phetulo, >> >> My email message was to Mandla who had already stated his NRS >> affiliation. I?m slightly confused by your reply to the message addressed >> to him. Are you also saying you are NRS affiliated, or that you and Mandla >> are the same person ? >> >> Kind regards >> Ben >> >> Sent from my iPhone >> >> > On 23 Jul 2026, at 07:32, Phetulo Dhlamini >> wrote: >> > >> > ? >> > Hi Ben, >> > >> > No, you should not make that assumption. >> > >> > I participate in the PDP in my personal capacity and speak for myself >> unless I expressly state that I am authorised to represent an organisation. >> My affiliation provides context; it does not turn every contribution into >> an NRS position. >> > >> > Treating employment as automatic representation confuses a stakeholder >> with a principal and misunderstands how open PDP participation works. >> > >> > Regards, >> > Phetulo >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ End of RPD Digest, Vol 222, Issue 181 ************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From phetulodhlamini at gmail.com Thu Jul 23 09:02:58 2026 From: phetulodhlamini at gmail.com (Phetulo Dhlamini) Date: Thu, 23 Jul 2026 11:02:58 +0200 Subject: [rpd] RDP Discussion In-Reply-To: References: Message-ID: Hi Ben, Mandla can answer for Mandla. His job title does not automatically turn every contribution he makes into an official NRS position. An affiliation provides context; it is not a power of attorney. You say it is not for you to judge, but then imply that similar views and writing establish organisational coordination. That remains an assumption, not evidence. People can agree in a public discussion without becoming colleagues, agents, or one institutional voice. I did not clarify anyone?s affiliation. I challenged the idea that employment automatically equals representation. If NRS issues an organisational position, it can identify it expressly. Until then, each contributor should be treated as speaking for themselves. Regards, Phetulo On Thu, 23 Jul 2026, 10:41 Ben Roberts - AfriNIC, wrote: > Ok Phetulo, > Let?s wait for Mandla?s reply. Please do note that his job at NRS he told > us that his job at NRS was a policy insights contributor. So when he > contributes policy insights, I think we can take a first assumption that he > is doing the job he?s been assigned by his employer. > > Please also note that I respect Nandla?s contribution, since he has > introduced himself properly and his affiliation. It is important to make > proper introductions, as I?ve said. > > By co-incidence it seems that Nandla, an NRS employee has similar views, > expressed with identical arguments and writing style, with a very active > collective of other contributors, who have clarified that they are speaking > on their personal individual behalf?s. It?s not for me to take any judgment > position otherwise, so for those who have stated their non affiliation with > NRS (which I didn?t ask), we now as a community now that these are all free > thinking individuals. > > Kind regards > Ben > > > Sent from my iPhone > > On 23 Jul 2026, at 10:23, Phetulo Dhlamini > wrote: > > ? > Dear Ben, > > No, I am not saying that I am affiliated with NRS, nor that Mandla and I > are the same person. > > I replied because I was making a general point, using Mandla?s situation > as an example: a participant?s affiliation does not automatically make > their personal contribution an organisational position. Mandla can speak > for himself, and I speak only for myself. > > This is a public discussion. Responding to a point does not require being > the person originally addressed. > > Regards, > Phetulo > > On Thu, 23 Jul 2026, 08:43 Phetulo Dhlamini, > wrote: > >> Hi Ben, >> >> No, you should not make that assumption. >> >> I participate in the PDP in my personal capacity and speak for myself >> unless I expressly state that I am authorised to represent an organisation. >> My affiliation provides context; it does not turn every contribution into >> an NRS position. >> >> Treating employment as automatic representation confuses a stakeholder >> with a principal and misunderstands how open PDP participation works. >> >> Regards, >> Phetulo >> >> On Thu, 23 Jul 2026, 07:40 Ben Roberts - AfriNIC, < >> ben.roberts at afrinic.net> wrote: >> >>> Phetulo, >>> >>> My email message was to Mandla who had already stated his NRS >>> affiliation. I?m slightly confused by your reply to the message addressed >>> to him. Are you also saying you are NRS affiliated, or that you and Mandla >>> are the same person ? >>> >>> Kind regards >>> Ben >>> >>> Sent from my iPhone >>> >>> > On 23 Jul 2026, at 07:32, Phetulo Dhlamini >>> wrote: >>> > >>> > ? >>> > Hi Ben, >>> > >>> > No, you should not make that assumption. >>> > >>> > I participate in the PDP in my personal capacity and speak for myself >>> unless I expressly state that I am authorised to represent an organisation. >>> My affiliation provides context; it does not turn every contribution into >>> an NRS position. >>> > >>> > Treating employment as automatic representation confuses a stakeholder >>> with a principal and misunderstands how open PDP participation works. >>> > >>> > Regards, >>> > Phetulo >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From mguqulwazenalo at gmail.com Thu Jul 23 09:05:39 2026 From: mguqulwazenalo at gmail.com (Zenalo Mguqulwa) Date: Thu, 23 Jul 2026 11:05:39 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 181 In-Reply-To: References: Message-ID: Good day, I agree with Nonhlanhla and Zamaphathwa. Participation should be treated as input, not as proof of representation, and familiarity should not become authority to decide who is entitled to participate. If identity verification is considered necessary, it must be formally justified. Similarly, concerns about flooding or disruptive conduct should be assessed against specific messages and objective rules. They should not be inferred from similar arguments, writing tools, employment, or unfamiliar names.The simplest way forward is to address distinct objections on their merits, and leave allegations of misconduct to the co-chairs on the basis of evidence. Regards, Zen On Thu, 23 Jul 2026 at 10:54, wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: RDP Discussion (Ben Roberts - AfriNIC) > 2. RPD Digest, Vol 222, Issue 131 (Zamaphathwa Phathwa) > 3. Re: RPD Digest, Vol 222, Issue 181 (NP Petronella) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 23 Jul 2026 10:41:06 +0200 > From: Ben Roberts - AfriNIC > To: Phetulo Dhlamini > Cc: rpd at afrinic.net > Subject: Re: [rpd] RDP Discussion > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260723/a7ee51cb/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Thu, 23 Jul 2026 10:44:27 +0200 > From: Zamaphathwa Phathwa > To: "rpd at afrinic.net" , hvisage at hevis.co.za > Subject: [rpd] RPD Digest, Vol 222, Issue 131 > Message-ID: > 72D8DLzw at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Andrew and Mike, > > Two separate issues are being mixed together. > > If someone is genuinely flooding the list, impersonating others, or > deliberately disrupting discussion, the co-chairs should address that > conduct under neutral rules. But similar arguments, unfamiliar names, > AI-assisted drafting, or LinkedIn profiles do not prove coordination or bad > faith. Suspicion is not evidence. > > Andrew, I also disagree that an objection is valid only when it proves > immediate operational harm. A proposal may be technically workable and > still be unnecessary, disproportionate, or the wrong instrument. Scope, > reversibility, and expansion of registry enforcement are legitimate policy > concerns. Saying that necessity is irrelevant is precisely how procedure > begins manufacturing its own mandate. > > Mike, list traffic can be managed through threading, reasonable posting > limits, and consolidation of repeated issues. The co-chairs may treat > several similar messages as one substantive objection without treating the > participants themselves as illegitimate. Calling ordinary AI-assisted > participation a potential ?DDoS? risks turning moderation into gatekeeping > before any disruptive conduct has been proven. > > The tool is not the participant. The person who reviews, submits, and > stands behind the message is. > > Rough consensus should be based on distinct arguments and evidence, not > reputation, professional affiliation, writing style, or assumptions about > which software was used. > > Regards, > Zamaphathwa > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260723/9d0f8e4d/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Thu, 23 Jul 2026 08:53:33 +0000 > From: NP Petronella > To: Hendrik Visage , "rpd at afrinic.net" > > Subject: Re: [rpd] RPD Digest, Vol 222, Issue 181 > Message-ID: > < > VI2PR09MB7139EF7010F66030C5B01947A4C02 at VI2PR09MB7139.eurprd09.prod.outlook.com > > > > Content-Type: text/plain; charset="windows-1252" > > Dear Hendrik, > > No one is putting words in your mouth. You called unfamiliar objectors > "astroturfers", argued that participation should depend on proving ?skin in > the game,? and proposed KYC as a test of legitimacy. Describing that as > gatekeeping is a fair reading of your own words. > > I do not oppose identity verification. I previously supported a limited, > neutral process. But supporting verification is not the same as giving > individual participants authority to investigate or certify others. > > Any verification system must have a formal basis, demonstrated necessity, > privacy safeguards, neutral administration, and equal application to > established and new participants. It should confirm only that a real person > controls an account, not impose an industry-experience, affiliation, or > viewpoint test. > > Until such a process exists, suspicion is not proof and familiarity is not > authority. If you have evidence of a specific breach, submit it to the > co-chairs. Otherwise, address the policy rather than the eligibility of > those questioning it. > > Regards, > Nonhlanhla > > ________________________________ > From: Hendrik Visage > Sent: Thursday, 23 July 2026 10:41:15 > To: NP Petronella > Subject: Re: RPD Digest, Vol 222, Issue 181 > > > oh you are now putting words on my mouth and acting as a victim, not > taking responsibility for your pov! > > ________________________________ > > 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 > > On 23 Jul 2026, at 10:38, NP Petronella wrote: > > Dear Hendrik, > > I am concerned by the power dynamic in your message. > > You have appointed yourself investigator, judge, and gatekeeper, then > treated your own suspicions as ?prima facie evidence.? That is not how > evidence works. A civil standard is applied by an authorised decision-maker > after evidence is tested, not declared by a mailing-list participant who > has already chosen the verdict. > > Your proposed ?skin in the game? test is equally troubling. Operational > experience is valuable evidence, but it does not give resource holders > exclusive ownership of the PDP or authority to classify everyone else as > guests. Stakeholders may contribute expertise, questions, warnings, and > objections. They do not thereby become principals for the entire community. > > What is happening here is a clear power play: disagreement is relabelled > as suspicious, suspicion becomes a demand for identity, and identity is > then made a condition for being heard. That is mandate laundering in > miniature. > > If identity verification is genuinely needed, propose it formally. Define > its purpose, protect privacy, apply it equally to established and new > participants, and place it under neutral administration. It cannot be > invented selectively for unfamiliar objectors. > > If you have evidence of impersonation, automated flooding, or an actual > procedural breach, submit it to the co-chairs. Otherwise, address the > arguments. > > The PDWG is not a private club, and familiar operators do not get to > decide who counts as human, who counts as community, or who has permission > to speak. > > Regards, > Nonhlanhla > ________________________________ > From: rpd-request at afrinic.net > Sent: Thursday, 23 July 2026 10:23:41 > To: rpd at afrinic.net > Subject: RPD Digest, Vol 222, Issue 181 > > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: RDP Discussion (Ben Roberts - AfriNIC) > 2. Re: RDP Discussion (Ben Roberts - AfriNIC) > 3. Re: Policy supremacy (Hendrik Visage) > 4. Re: RDP Discussion (Phetulo Dhlamini) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 23 Jul 2026 09:17:35 +0200 > From: Ben Roberts - AfriNIC > To: Nonjabulo Sphilile > Cc: rpd at afrinic.net > Subject: Re: [rpd] RDP Discussion > Message-ID: > Content-Type: text/plain; charset=utf-8 > > Nonjabulo, > Let?s wait for what Mandla has to say? Since he has a job as a policy > insights contributor for NRS, he may want his policy insights to be on > behalf of NRS right ? > > Kind regards > Ben > Sent from my iPhone > > > On 23 Jul 2026, at 08:23, Nonjabulo Sphilile < > nonjabulosphilile at gmail.com> wrote: > > > > ? > > Dear Ben, > > > > I believe in open participation. That means contributors speak for > themselves unless they expressly state that they are authorised to > represent an organisation. > > > > Mandla?s affiliation with NRS provides context, not a mandate. Assuming > every employee speaks for their organisation confuses participation with > representation and turns an open PDP into a contest between institutions. > > > > Please assess Mandla?s contribution as his own. > > > > Regards, > > Nonjabulo > > > > ------------------------------ > > Message: 2 > Date: Thu, 23 Jul 2026 09:41:27 +0200 > From: Ben Roberts - AfriNIC > To: Phetulo Dhlamini > Cc: rpd at afrinic.net > Subject: Re: [rpd] RDP Discussion > Message-ID: <67901F2F-CB25-4760-8770-0C05F9543D2F at afrinic.net> > Content-Type: text/plain; charset="us-ascii" > > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260723/8a0939cd/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Thu, 23 Jul 2026 10:14:49 +0200 > From: Hendrik Visage > To: Nonjabulo Sphilile > Cc: rpd at afrinic.net > Subject: Re: [rpd] Policy supremacy > Message-ID: > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Good Nonjabulo Sphilile, > > Hopefully I?m not responding to ChatGPT, but the real Nonjabulo > Sphilile! > > The problem that the RDP are facing today, is the mass of objectors, > that nobody knows, have not properly, honestly/truthfully answered the > real questions posed to them, and then keeps spewing a regurgitated > barrage of being victimized and they are the injured and they are? The > word astroturfing by definition doesn?t have an exact forensically > applicable definition to measure, but are evident on the probabilities. > Ie. the same type of evidence and measures that a civil court of law > would apply, not a criminal court as these aren?t criminal cases where > innocence are assumed till proven beyond doubt. Thus, there exist prime > facie evidences that the astroturfers had been succesfully named and > proven. > > Now This being and open forum, there should be NO assumption of > anonymity, and I?d state that given the astroturfers, that the > assumption should be, given the nature of AfriNIC, that the request for > KYC would not be a procedural problem for ANY REAL OPERATOR, but only an > issue for the likes of astroturfers that needs to have the puppet-master > hidden/anonymous so that nothing can be pointed back to the puppet-mster > that wants to derail the procedures etc. as the outcomes would have a > negative effect on their operations, I?ll even content that the > reasons for the objections (given the weak arguments answered, and the > evading of questions posed) might be more nefarious instead of actually > objectively for the good of the continent a.k.a. AfriNIC?s > communities. > > The idea that your participation to the is a RIGHT, I?ll only defend > if and only if you can show you have a real valid concerns or ?skin in > the game? with regards to AfriNIC, and then your affiliations and > representations are the reasons you might have a right to speak and > object. AfriNIC membership etc (and by that extension I?d say the > right to be heard in the RDP, else you should be acting as a guest, not > a victim) are based on the RESOURCES (AS numbers and/or addresses) you > have been allocated (while being a member in good standing) or need/want > to be allocated to you. As such that is the reason we?d like to know > how you, as a new comer have *real* interest in these matters, not just > that you have a *claimed* objection .. and when questioned, you deflect > ;( > > --- > 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 > > On 22 Jul 2026, at 15:45, Nonjabulo Sphilile wrote: > > > Hi Musa, > > > > The PDWG is open. Participation does not depend on being known to > > long-standing members, attending earlier meetings, or proving a > > professional stake after joining. New participation is still > > participation. > > > > KYC would be a serious procedural change, not an informal test for > > unfamiliar objectors. Any such requirement would need to be formally > > adopted, proportionate, privacy-preserving, and applied equally to > > established and new participants. > > > > Similar views are not proof of impersonation. If there is concrete > > evidence > > of misconduct, please submit it to the co-chairs. Otherwise, I will > > not > > continue discussing identities or drafting methods. > > > > Let us return to the policy. > > > > Regards, > > Nonjabulo > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260723/6fda32e0/attachment-0001.html > > > > ------------------------------ > > Message: 4 > Date: Thu, 23 Jul 2026 10:23:41 +0200 > From: Phetulo Dhlamini > To: rpd at afrinic.net > Subject: Re: [rpd] RDP Discussion > Message-ID: > < > CAABFmSnLACSr3N9_QZOoiTvXH0RF5Vn+vXt5h7vSzwa4C1R76w at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Ben, > > No, I am not saying that I am affiliated with NRS, nor that Mandla and I > are the same person. > > I replied because I was making a general point, using Mandla?s situation as > an example: a participant?s affiliation does not automatically make their > personal contribution an organisational position. Mandla can speak for > himself, and I speak only for myself. > > This is a public discussion. Responding to a point does not require being > the person originally addressed. > > Regards, > Phetulo > > On Thu, 23 Jul 2026, 08:43 Phetulo Dhlamini, > wrote: > > > Hi Ben, > > > > No, you should not make that assumption. > > > > I participate in the PDP in my personal capacity and speak for myself > > unless I expressly state that I am authorised to represent an > organisation. > > My affiliation provides context; it does not turn every contribution into > > an NRS position. > > > > Treating employment as automatic representation confuses a stakeholder > > with a principal and misunderstands how open PDP participation works. > > > > Regards, > > Phetulo > > > > On Thu, 23 Jul 2026, 07:40 Ben Roberts - AfriNIC, < > ben.roberts at afrinic.net> > > wrote: > > > >> Phetulo, > >> > >> My email message was to Mandla who had already stated his NRS > >> affiliation. I?m slightly confused by your reply to the message > addressed > >> to him. Are you also saying you are NRS affiliated, or that you and > Mandla > >> are the same person ? > >> > >> Kind regards > >> Ben > >> > >> Sent from my iPhone > >> > >> > On 23 Jul 2026, at 07:32, Phetulo Dhlamini > > >> wrote: > >> > > >> > ? > >> > Hi Ben, > >> > > >> > No, you should not make that assumption. > >> > > >> > I participate in the PDP in my personal capacity and speak for myself > >> unless I expressly state that I am authorised to represent an > organisation. > >> My affiliation provides context; it does not turn every contribution > into > >> an NRS position. > >> > > >> > Treating employment as automatic representation confuses a stakeholder > >> with a principal and misunderstands how open PDP participation works. > >> > > >> > Regards, > >> > Phetulo > >> > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260723/47abdb2c/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 181 > ************************************* > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260723/70cfbae3/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 183 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ST10120874 at vcconnect.edu.za Thu Jul 23 09:09:26 2026 From: ST10120874 at vcconnect.edu.za (Mphoentle Mokheseng) Date: Thu, 23 Jul 2026 09:09:26 +0000 Subject: [rpd] RDP Discussion Message-ID: Dear Hendrik, I reject the eligibility test you are trying to create. KYC can confirm that someone controls an identity. It cannot prove technical competence, good faith, organisational authority, or correctness. It therefore does not solve the issue you claim. It simply creates a new gate through which unfamiliar participants must pass. You also cannot describe the PDP as open while arguing that only resource holders or people with approved ?skin in the game? have a right to be heard. Operators bring valuable experience, but they speak for their own networks. They do not automatically speak for the continent or acquire authority over everyone else. The pattern is clear: unfamiliarity becomes suspicion, suspicion becomes a demand for identity, and identity then becomes a condition for participation. That is not openness. It is a small circle manufacturing authority over who counts as the community. If there is evidence of impersonation, flooding, or another breach, submit it to the co-chairs. Otherwise, rebut the arguments and stop trying to redesign participation around personal recognition. Regards, Mphoentle Disclaimer This email and the information contained herein are Advtech Ltd confidential and are protected by law. Please navigate to our website for more information https://www.groupadvtech.com. Use of this information or this email by any person for any purposes other than that for which it is intended is prohibited and may result in civil and/or criminal liability. This email is not to be shared with any 3rd parties not included within this email, without the written consent of its Author. If you have received this message in error, please notify Advtech immediately, telephone number +27 11 676 8000. Advtech leads the private sector in the fields of education and resourcing, contributing meaningfully towards the sustainable development of human capacity in South Africa. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonjabulosphilile at gmail.com Thu Jul 23 09:09:10 2026 From: nonjabulosphilile at gmail.com (Nonjabulo Sphilile) Date: Thu, 23 Jul 2026 11:09:10 +0200 Subject: [rpd] RDP Discussion Message-ID: Dear Ben, Please allow me to kindly address the inference being made here. A job title provides context; it does not automatically make every contribution an official employer statement. Saying it is ?not for me to judge? while linking affiliation, writing style, and similar views is still judgment by insinuation. Similar arguments do not establish agency, coordination, or shared identity. An open PDP should assess what participants say, not construct relationships between them. If formal disclosure is considered necessary, propose a clear rule and apply it equally to everyone. Until then, affiliation is not mandate and familiarity is not proof. Regards, Nonjabulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Thu Jul 23 09:14:41 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Thu, 23 Jul 2026 11:14:41 +0200 Subject: [rpd] =?utf-8?q?=5BLast_Call=5D_AFPUB-2026-ASN-001-DRAFT02_?= =?utf-8?q?=E2=80=94_six_open_questions_to_those_opposing?= Message-ID: <7B301CC4-F034-4D4E-8C71-3FA99D410C15@hevis.co.za> Dear all, and specifically those who have registered opposition ? Nia Petronella / Nonhlanhla, Fundiswa Nadia Maseko, Gugu Dhlamini, Tshepo Masuku, Thulisile Mazomba, Asamkele Menzeleli, Thandeka Mseleku, Nyasha Ndemo, Nonjabulo Sphilile, Mphoentle Mokheseng, Phetulo Dhlamini, Mandla Matshika, NP Petronella, and colleagues ? The Co-Chairs have asked (21 July, https://lists.afrinic.net/pipermail/rpd/2026/015237.html ) that Last Call objections be new, fully justified, and that they engage what has already been addressed rather than repeat it. In that spirit, six concrete questions have been put to the opposition during the discussion and Last Call phases and remain unanswered. Restating general positions does not answer them. I ask, directly, that those maintaining opposition answer these ? specifically and on the record. 1. The two-object case (asked by Frank Habicht, https://lists.afrinic.net/pipermail/rpd/2026/015076.html , reiterated https://lists.afrinic.net/pipermail/rpd/2026/015085.html and in https://lists.afrinic.net/pipermail/rpd/2026/015120.html ). An empty AS-GOOGLE object exists in the AFRINIC IRR while the populated AS-GOOGLE is in RADB. When filter-generation tooling (bgpq4 and similar) resolves the name across mirrored sources, what should it do ? and how does any proposed alternative prevent the resulting mis-filtering, without the creation-time hierarchical rule this proposal introduces? 2. Squatting remedy (asked by Hendrik Visage, 19 July, https://lists.afrinic.net/pipermail/rpd/2026/015120.html ). Under the "less restrictive alternatives" put forward (source-qualified lookups, ambiguity rejection, better tooling, warnings, voluntary adoption): what remedy does a victim have to get a squatted, same-named AS-SET removed from a database they do not control? Name the mechanism. 3. Yes or no (asked by Frank Habicht, https://lists.afrinic.net/pipermail/rpd/2026/015123.html ). Do you agree the proposal provides an improvement? A direct yes or no, please ? the question has so far been answered only by implication ( https://lists.afrinic.net/pipermail/rpd/2026/015130.html ). 4. The evidence bar (arising from the opposition's own standard, https://lists.afrinic.net/pipermail/rpd/2026/015130.html ). Opposition has held that the benefit must be "significant enough, proven enough, proportionate enough." What specific threshold would satisfy that test? Please state the bar you are applying, so it can be measured against the documented incidents (MANRS AS-AMAZON, 2022; the live AS-GOOGLE case above) and the four other RIRs' adoption. 5. The Impact Assessment (asked by Hendrik Visage, https://lists.afrinic.net/pipermail/rpd/2026/015120.html ). The published staff Impact Assessment finds minimal member impact, no legal and no finance issues, with existing objects untouched. Which specific finding in it do you contest, and on what basis? The assertion that "the analysis has not been completed" needs to engage the analysis that exists. 6. Capacity (asked by Ben Roberts, https://lists.afrinic.net/pipermail/rpd/2026/015131.html ; now also Co-Chair guidance point 5, https://lists.afrinic.net/pipermail/rpd/2026/015237.html ). Are you contributing in your own individual capacity or on behalf of a resource member/organisation? The Co-Chairs' 21 July note asks contributors to say so. Please state it. To be clear on where the substance already stands: the distinction between authenticating an object's creation and validating its contents is real, it has been conceded by both sides, and it is out of the proposal's stated scope ? the proposal claims name uniqueness and creation authorisation, not membership validity. That point, having been answered, does not by itself block consensus (RFC 7282). What remains is the six questions above. If opposition is maintained through the close of Last Call, I ask that it be maintained by answering these ? not by restating the original objections or by moving the discussion to who may participate. A concise, on-point answer to any of the six advances the discussion; a further restatement does not. Regards, Hendrik Visage (AS329532 AS213481) -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Thu Jul 23 09:25:14 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Thu, 23 Jul 2026 11:25:14 +0200 Subject: [rpd] RDP Discussion In-Reply-To: References: Message-ID: Nonjabulo, Ok. Your words not mine. I draw no conclusions. Sent from my iPhone > On 23 Jul 2026, at 11:09, Nonjabulo Sphilile wrote: > > ? > Dear Ben, > > Please allow me to kindly address the inference being made here. > > A job title provides context; it does not automatically make every contribution an official employer statement. > > Saying it is ?not for me to judge? while linking affiliation, writing style, and similar views is still judgment by insinuation. Similar arguments do not establish agency, coordination, or shared identity. > > An open PDP should assess what participants say, not construct relationships between them. If formal disclosure is considered necessary, propose a clear rule and apply it equally to everyone. Until then, affiliation is not mandate and familiarity is not proof. > > Regards, > Nonjabulo From daniel.medoye at gmail.com Thu Jul 23 09:42:09 2026 From: daniel.medoye at gmail.com (Taye Medoye) Date: Thu, 23 Jul 2026 11:42:09 +0200 Subject: [rpd] RDP Discussion Message-ID: Dear All, It's slightly frustrating to note that rather than concentrate discussions on policy proposals in line with the Forum's expectations, towards arriving at policy statements, interests and focus seem divided. I am not aware of any clause in the Code of Conduct as articulated by the organisation, which requires blatant and critical censure of opinions or positions by participants, whether old or new. I think the reference to both Tshepo and Gugu by Musa on their contributions and where they belong, is highly offensive and indefensible. When submissions are made on the platform, respondents are at liberty to sift through and either align with, or object to issues raised, and with alternative submissions. Besides, it's not proper to denigrate any participant, or engage in some kind of profiling, which tends to supremacy. I dare say that there is no mentee-participant. Every contributor's view deserves to be treated with respect. We're certainly different in terms of backgrounds, professions, experience, worldviews, etc, and these contexts shape the way we relate with others. It's refreshing to note that the intervention and clarifications by Mandla, in terms of the AFRINIC policy development which allows new stakeholders to engage, sets the record straight. Mandla's suggestion that the - approach is to judge contributions on merit, relevance, and alignment AFRINIC's mission and the needs of the network, suffices. Finally, it's my humble opinion that participants. whether old or new on the platform is reminded of the need to be intentionally familiar with the Code of Conduct as enshrined for conducting affairs at the PDP and in other engagements. No prejudices intended please! Taye Medoye. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Thu Jul 23 10:15:44 2026 From: ben.roberts at afrinic.net (ben.roberts@frinic.net) Date: Thu, 23 Jul 2026 12:15:44 +0200 Subject: [rpd] =?utf-8?q?=5BLast_Call=5D_AFPUB-2026-ASN-001-DRAFT02_?= =?utf-8?q?=E2=80=94_six_open_questions_to_those_opposing?= In-Reply-To: <7B301CC4-F034-4D4E-8C71-3FA99D410C15@hevis.co.za> References: <7B301CC4-F034-4D4E-8C71-3FA99D410C15@hevis.co.za> Message-ID: <2AF1809F-2D7D-714D-9873-9E5007E03969@hxcore.ol> An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Thu Jul 23 11:44:58 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Thu, 23 Jul 2026 11:44:58 +0000 Subject: [rpd] =?windows-1252?q?_=5BLast_Call=5D_AFPUB-2026-ASN-001-DRAFT0?= =?windows-1252?q?2_=97_six_open_questions_to_those_opposing?= Message-ID: Dear Hendrik and colleagues, Thank you for collecting the questions. I will answer them directly. 1. The two-object case Where two independent IRR sources publish the same flat AS-SET name, tooling should not silently merge them or guess which one the operator intended. The query should be bound to an explicitly selected source, or the tool should stop and report the ambiguity. That safeguard is required whether this proposal passes or not. The proposal leaves existing objects untouched, so the AS-GOOGLE example will remain ambiguous after implementation. It therefore cannot be presented as the remedy to that live case. It is a prospective naming restriction, not a complete solution to cross-IRR resolution. 2. Squatting remedy This proposal creates no mechanism for removing a squatted object from a database AFRINIC does not control. Where the remote database?s rules have been breached, the affected party must use that database operator?s dispute or abuse process. Where no removal right exists, consumers must treat the IRR source and object name together as the object?s identity, rather than assuming that an unqualified name is globally unique. The absence of a universal takedown mechanism is an architectural problem. An AFRINIC creation rule cannot manufacture authority over every other IRR. 3. Does the proposal provide an improvement? Yes, narrowly. It would reduce future flat-name collisions in the AFRINIC database and improve attribution for newly created objects. That does not settle the policy question. A change can be useful while binding policy remains the wrong instrument. The issue is whether the same improvement can be implemented operationally, as it largely is elsewhere, without enlarging the permanent policy layer. 4. The evidence bar The threshold is not a magic number of incidents. One serious incident may be sufficient if the causal chain is demonstrated. For an incident to justify this proposal, proponents should show that: * the harm resulted from creation of a flat AS-SET in the AFRINIC database; * the proposal, as written, would have prevented it; * an operational implementation or source-aware, fail-closed tooling would not provide the same protection; * and the expected benefit, remaining risks, and success criteria are defined. The AS-GOOGLE case does not satisfy the second point because the proposal leaves that existing object untouched. The AS-AMAZON incident should likewise be mapped to the actual text and scope of this proposal, not merely cited by name. Adoption by four RIRs demonstrates feasibility and institutional preference. It does not, by itself, prove that binding policy is the necessary instrument for AFRINIC. 5. The Impact Assessment I do not dispute the findings that implementation may have minimal direct member impact and no identified legal or financial issue. My concern is what the assessment does not answer. It does not establish why policy is required rather than a transparent operational change. It does not resolve existing collisions, define safe multi-source consumer behaviour, measure the expected reduction in harm, or provide review criteria if the claimed benefit does not materialise. An implementation may be easy and still be unnecessary as binding policy. Ease of enforcement is not the same as justification for enforcement. 6. Capacity I participate in my individual capacity. I do not claim to represent an organisation or resource member. That disclosure provides context. It does not turn the policy process into a headcount or make organisational affiliation a condition for having a technical or policy concern considered. These answers narrow the disagreement. I accept that hierarchical naming offers a limited operational benefit. I do not accept the leap from limited benefit to mandatory policy, particularly when the cited live collision remains unresolved by the proposal and the same technical outcome may be achieved through an accountable operational implementation. The proper test is not simply whether the working group can create a rule. It is whether the rule is necessary in the mandatory common layer and whether it is the minimum instrument required by running networks. On that basis, I remain opposed to AFPUB-2026-ASN-001-DRAFT02. Regards, Tshepo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Thu Jul 23 12:38:45 2026 From: mike at iptrading.com (Mike Burns) Date: Thu, 23 Jul 2026 08:38:45 -0400 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: <7bde9b18-2a38-4797-883b-8bca9de25242@geier.ne.tz> References: <1784639031075.56443@tra.gov.eg> <00e501dd1a03$0c54a1c0$24fde540$@iptrading.com> <7bde9b18-2a38-4797-883b-8bca9de25242@geier.ne.tz> Message-ID: <020d01dd1aa0$33beba50$9b3c2ef0$@iptrading.com> HI Frank, Thanks for playing Devil's Advocate, I think that is a worthwhile effort. I agree that swamping the list should be subject to moderation, and it already is. But the more important question to me, is if Claude comes up with a winning argument, should we ignore or discount it? I think the verbosity and repetition of these posts will work against them in the long run as effective use of AI tools. But if they can shorten and clarify their arguments, and resist the urge to repeat them slightly differently, I would listen to them. Regards, Mike -----Original Message----- From: Frank Habicht Sent: Thursday, July 23, 2026 12:37 AM To: rpd at afrinic.net Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 Hi, On 7/22/2026 8:53 PM, Mike Burns via RPD wrote: [snip] > I say, who cares if Claude is posting, or ChatGPT, or any other AI. > > Give them a seat at the table and address their arguments. > > Giving them a veneer of humanness through identity appropriation is > not the way forward. > > Again, I am interested in hearing other perspectives. I'd like to hear what should happen if then two Claudes are arguing at 5000 email per hour and eventually one Claude wins the argument, and AfriNIC will have to implement a policy that e.g. bans you from posting here? Frank Devil's advocate _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd From NPertuniaPetronella at outlook.com Thu Jul 23 13:30:13 2026 From: NPertuniaPetronella at outlook.com (NP Petronella) Date: Thu, 23 Jul 2026 13:30:13 +0000 Subject: [rpd] Fw: PDWG Co-Chairs communication regarding observed behavior on AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: References: Message-ID: ________________________________ From: NP Petronella Sent: Thursday, 23 July 2026 15:25:26 To: rpd-request at afrinic.net ; mike at iptrading.com Subject: [rpd] PDWG Co-Chairs communication regarding observed behavior on AFPUB-2026-ASN-001-DRAFT02 Hi Mike, I think that is a fair approach. A strong argument should not be discounted because a tool helped express it, just as a weak argument should not gain weight merely because someone typed it unaided. The 2020 experience offers a useful distinction. Where voting was involved, eligibility controls were considered because votes are counted. Policy discussion is different: rough consensus should assess distinct arguments, not subscription dates or the number of similar messages. Repeated points can be consolidated, and actual list-swamping can already be moderated. At the same time, newer participants and AI-assisted contributions should still be judged on clarity, relevance, and evidence. That seems the balanced position: moderate conduct, not tools; reduce repetition, not participation; and keep the focus on the argument rather than the author. Regards, Nonhlanhla -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah at neo.co.tz Thu Jul 23 14:03:02 2026 From: noah at neo.co.tz (Noah) Date: Thu, 23 Jul 2026 17:03:02 +0300 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: <00e501dd1a03$0c54a1c0$24fde540$@iptrading.com> References: <1784639031075.56443@tra.gov.eg> <00e501dd1a03$0c54a1c0$24fde540$@iptrading.com> Message-ID: On Wed, 22 Jul 2026, 8:53?pm Mike Burns, wrote: > > It?s not like Claude will be elected to any parliament. > > But this unique governance form for a global asset provides the > opportunity. > > I say, who cares if Claude is posting, or ChatGPT, or any other AI. > I care that the AFRINIC rpd list is not turned into waste land of AI powered trolls Give them a seat at the table and address their arguments. > How many valid argument have been made in the past week or you mean a single argument repeated through AI generated texts send by single persons using multiple different email address or same group saying the same thing over and over feeding the troll.... I have not experienced this behaviour on the ARIN or RIPE lists or even APNIC for which we are both participants.. Why are you advocating for it in the AFRNIC service region....? Cheers, *.**/noah* -------------- next part -------------- An HTML attachment was scrubbed... URL: From silber.mike at gmail.com Thu Jul 23 14:43:25 2026 From: silber.mike at gmail.com (Mike Silber) Date: Thu, 23 Jul 2026 16:43:25 +0200 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: <020d01dd1aa0$33beba50$9b3c2ef0$@iptrading.com> References: <1784639031075.56443@tra.gov.eg> <00e501dd1a03$0c54a1c0$24fde540$@iptrading.com> <7bde9b18-2a38-4797-883b-8bca9de25242@geier.ne.tz> <020d01dd1aa0$33beba50$9b3c2ef0$@iptrading.com> Message-ID: Hi Mike B On Thu, Jul 23, 2026 at 2:39?PM Mike Burns via RPD wrote: > > I agree that swamping the list should be subject to moderation, and it > already is. > Indeed - but I think clearer parameters for moderation will be helpful to avoid accusations of partiality. > But the more important question to me, is if Claude comes up with a winning > argument, should we ignore or discount it? > Definitely not. I have no issue with AI generated or supplemented / edited positions. > > I think the verbosity and repetition of these posts will work against them > in the long run as effective use of AI tools. > But if they can shorten and clarify their arguments, and resist the urge to > repeat them slightly differently, I would listen to them. > I agree that the current verbose and repetitive positing is not endearing these posters to the community or showing any compelling arguments. The simplistic view is that this is an unsophisticated campaign using various sockpuppet accounts to try to create the perception of large scale dissent. But what if it is actually a sophisticated campaign to drown out other participation, cause list members to unsubscribe or withdraw in frustration that can then lead to the "capture" of the process by hollowing out positive contributions? Mike S > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Thu Jul 23 14:50:27 2026 From: mike at iptrading.com (Mike Burns) Date: Thu, 23 Jul 2026 10:50:27 -0400 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: References: <1784639031075.56443@tra.gov.eg> <00e501dd1a03$0c54a1c0$24fde540$@iptrading.com> Message-ID: <027601dd1ab2$9982cd10$cc886730$@iptrading.com> Hi Noah, I have made it clear from the outset that list swamping or use of AI to generate duplicative, though reworded objections is grounds for moderation. That issue, which I was at pains to separate from the use of AI, continues to be conflated with the simple use of AI. That brings me to ad hominem, which is the basis of my belief and which you have failed in your reply. Ad hominem means that the speaker of an argument is of no importance when considering the argument. When you ask my for my motive, you breach that. Regards, Mike From: Noah Sent: Thursday, July 23, 2026 10:03 AM To: Mike Burns Cc: Hytham El-Nakhal ; pdwg-chairs at afrinic.net; rpd List Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 On Wed, 22 Jul 2026, 8:53?pm Mike Burns, > wrote: It?s not like Claude will be elected to any parliament. But this unique governance form for a global asset provides the opportunity. I say, who cares if Claude is posting, or ChatGPT, or any other AI. I care that the AFRINIC rpd list is not turned into waste land of AI powered trolls Give them a seat at the table and address their arguments. How many valid argument have been made in the past week or you mean a single argument repeated through AI generated texts send by single persons using multiple different email address or same group saying the same thing over and over feeding the troll.... I have not experienced this behaviour on the ARIN or RIPE lists or even APNIC for which we are both participants.. Why are you advocating for it in the AFRNIC service region....? Cheers, ./noah -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Thu Jul 23 14:59:33 2026 From: mike at iptrading.com (Mike Burns) Date: Thu, 23 Jul 2026 10:59:33 -0400 Subject: [rpd] PDWG Co-Chairs communication regarding observedbehavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: References: <1784639031075.56443@tra.gov.eg> <00e501dd1a03$0c54a1c0$24fde540$@iptrading.com> <7bde9b18-2a38-4797-883b-8bca9de25242@geier.ne.tz> <020d01dd1aa0$33beba50$9b3c2ef0$@iptrading.com> Message-ID: <028e01dd1ab3$df1d2400$9d576c00$@iptrading.com> Hi Mike, Those are excellent questions, and I think it lies within the moderators? mandate to block emails making the same argument incessantly, sockpuppets or not. I think we should rely on moderator judgement while we hopefully see better-crafted AI arguments. I trust the moderators have the tools necessary to discern and act when they see reworded arguments offered repetitively. Regards, Mike From: Mike Silber Sent: Thursday, July 23, 2026 10:43 AM To: rpd at afrinic.net Subject: Re: [rpd] PDWG Co-Chairs communication regarding observedbehavioron AFPUB-2026-ASN-001-DRAFT02 Hi Mike B On Thu, Jul 23, 2026 at 2:39?PM Mike Burns via RPD > wrote: I agree that swamping the list should be subject to moderation, and it already is. Indeed - but I think clearer parameters for moderation will be helpful to avoid accusations of partiality. But the more important question to me, is if Claude comes up with a winning argument, should we ignore or discount it? Definitely not. I have no issue with AI generated or supplemented / edited positions. I think the verbosity and repetition of these posts will work against them in the long run as effective use of AI tools. But if they can shorten and clarify their arguments, and resist the urge to repeat them slightly differently, I would listen to them. I agree that the current verbose and repetitive positing is not endearing these posters to the community or showing any compelling arguments. The simplistic view is that this is an unsophisticated campaign using various sockpuppet accounts to try to create the perception of large scale dissent. But what if it is actually a sophisticated campaign to drown out other participation, cause list members to unsubscribe or withdraw in frustration that can then lead to the "capture" of the process by hollowing out positive contributions? Mike S -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Thu Jul 23 15:01:08 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Thu, 23 Jul 2026 17:01:08 +0200 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavior on AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: References: Message-ID: Dear colleagues, I agree that repetitive posts and list flooding should be moderated. However, I don't think the use of AI should, on its own, determine how a contribution is viewed. AI is simply a tool. The participant is still responsible for reviewing, understanding, and standing behind what they submit. In the end, what matters is whether the argument is clear, relevant, and technically sound. If moderation is needed, it should be based on conduct and the quality of participation, not on the tools someone used to draft their message. Kind regards, Fundiswa Nadia Maseko On Thu, 23 Jul 2026, 16:44 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: PDWG Co-Chairs communication regarding observed > behavioron AFPUB-2026-ASN-001-DRAFT02 (Mike Burns) > 2. Fw: PDWG Co-Chairs communication regarding observed behavior > on AFPUB-2026-ASN-001-DRAFT02 (NP Petronella) > 3. Re: PDWG Co-Chairs communication regarding observed > behavioron AFPUB-2026-ASN-001-DRAFT02 (Noah) > 4. Re: PDWG Co-Chairs communication regarding observed > behavioron AFPUB-2026-ASN-001-DRAFT02 (Mike Silber) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 23 Jul 2026 08:38:45 -0400 > From: "Mike Burns" > To: "'Frank Habicht'" , > Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed > behavioron AFPUB-2026-ASN-001-DRAFT02 > Message-ID: <020d01dd1aa0$33beba50$9b3c2ef0$@iptrading.com> > Content-Type: text/plain; charset="us-ascii" > > HI Frank, > > Thanks for playing Devil's Advocate, I think that is a worthwhile effort. > > I agree that swamping the list should be subject to moderation, and it > already is. > But the more important question to me, is if Claude comes up with a winning > argument, should we ignore or discount it? > > I think the verbosity and repetition of these posts will work against them > in the long run as effective use of AI tools. > But if they can shorten and clarify their arguments, and resist the urge to > repeat them slightly differently, I would listen to them. > > Regards, > Mike > > > -----Original Message----- > From: Frank Habicht > Sent: Thursday, July 23, 2026 12:37 AM > To: rpd at afrinic.net > Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed > behavioron AFPUB-2026-ASN-001-DRAFT02 > > Hi, > > On 7/22/2026 8:53 PM, Mike Burns via RPD wrote: > [snip] > > I say, who cares if Claude is posting, or ChatGPT, or any other AI. > > > > Give them a seat at the table and address their arguments. > > > > Giving them a veneer of humanness through identity appropriation is > > not the way forward. > > > > Again, I am interested in hearing other perspectives. > > I'd like to hear what should happen if then two Claudes are arguing at > 5000 email per hour and eventually one Claude wins the argument, and > AfriNIC > will have to implement a policy that e.g. bans you from posting here? > > Frank > Devil's advocate > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > ------------------------------ > > Message: 2 > Date: Thu, 23 Jul 2026 13:30:13 +0000 > From: NP Petronella > To: "Rpd at afrinic.net" , "mike at iptrading.com" > > Subject: [rpd] Fw: PDWG Co-Chairs communication regarding observed > behavior on AFPUB-2026-ASN-001-DRAFT02 > Message-ID: > < > VI2PR09MB7139828F4B931D6A9D51C9F1A4C02 at VI2PR09MB7139.eurprd09.prod.outlook.com > > > > Content-Type: text/plain; charset="us-ascii" > > > ________________________________ > From: NP Petronella > Sent: Thursday, 23 July 2026 15:25:26 > To: rpd-request at afrinic.net ; mike at iptrading.com > > Subject: [rpd] PDWG Co-Chairs communication regarding observed behavior on > AFPUB-2026-ASN-001-DRAFT02 > > > Hi Mike, > > I think that is a fair approach. A strong argument should not be > discounted because a tool helped express it, just as a weak argument should > not gain weight merely because someone typed it unaided. > > The 2020 experience offers a useful distinction. Where voting was > involved, eligibility controls were considered because votes are counted. > Policy discussion is different: rough consensus should assess distinct > arguments, not subscription dates or the number of similar messages. > > Repeated points can be consolidated, and actual list-swamping can already > be moderated. At the same time, newer participants and AI-assisted > contributions should still be judged on clarity, relevance, and evidence. > > That seems the balanced position: moderate conduct, not tools; reduce > repetition, not participation; and keep the focus on the argument rather > than the author. > > Regards, > Nonhlanhla > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260723/caa1697e/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Thu, 23 Jul 2026 17:03:02 +0300 > From: Noah > To: Mike Burns > Cc: pdwg-chairs at afrinic.net, rpd List > Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed > behavioron AFPUB-2026-ASN-001-DRAFT02 > Message-ID: > < > CAEqgTWZVdRe+kfxUjevob2w4PurLzzY4r8DjNKq1-wABf8S0gQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Wed, 22 Jul 2026, 8:53?pm Mike Burns, wrote: > > > > > It?s not like Claude will be elected to any parliament. > > > > But this unique governance form for a global asset provides the > > opportunity. > > > > I say, who cares if Claude is posting, or ChatGPT, or any other AI. > > > I care that the AFRINIC rpd list is not turned into waste land of AI > powered trolls > > Give them a seat at the table and address their arguments. > > > > How many valid argument have been made in the past week or you mean a > single argument repeated through AI generated texts send by single persons > using multiple different email address or same group saying the same thing > over and over feeding the troll.... > > I have not experienced this behaviour on the ARIN or RIPE lists or even > APNIC for which we are both participants.. > > Why are you advocating for it in the AFRNIC service region....? > > Cheers, > *.**/noah* > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260723/fd504aad/attachment-0001.html > > > > ------------------------------ > > Message: 4 > Date: Thu, 23 Jul 2026 16:43:25 +0200 > From: Mike Silber > To: rpd at afrinic.net > Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed > behavioron AFPUB-2026-ASN-001-DRAFT02 > Message-ID: > < > CAE-cm4LvzxAERypoy2a16SUniYQA_+heXqPnC-YG6gNYtUvp7Q at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Mike B > > On Thu, Jul 23, 2026 at 2:39?PM Mike Burns via RPD > wrote: > > > > > I agree that swamping the list should be subject to moderation, and it > > already is. > > > > Indeed - but I think clearer parameters for moderation will be helpful to > avoid accusations of partiality. > > > > But the more important question to me, is if Claude comes up with a > winning > > argument, should we ignore or discount it? > > > > Definitely not. I have no issue with AI generated or supplemented / edited > positions. > > > > > I think the verbosity and repetition of these posts will work against > them > > in the long run as effective use of AI tools. > > But if they can shorten and clarify their arguments, and resist the urge > to > > repeat them slightly differently, I would listen to them. > > > > I agree that the current verbose and repetitive positing is not endearing > these posters to the community or showing any compelling arguments. The > simplistic view is that this is an unsophisticated campaign using various > sockpuppet accounts to try to create the perception of large scale dissent. > > But what if it is actually a sophisticated campaign to drown out other > participation, cause list members to unsubscribe or withdraw in frustration > that can then lead to the "capture" of the process by hollowing out > positive contributions? > > Mike S > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260723/ef969099/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 188 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From NPertuniaPetronella at outlook.com Thu Jul 23 15:05:54 2026 From: NPertuniaPetronella at outlook.com (NP Petronella) Date: Thu, 23 Jul 2026 15:05:54 +0000 Subject: [rpd] RPD Digest, Vol 222, Issue 189 In-Reply-To: References: Message-ID: Dear colleagues, I honestly think there is a reasonable middle ground here. The list should not be allowed to become unusable. If an account is posting at automated volume, repeatedly sending the same message, or deliberately disrupting discussion, the co-chairs should address that conduct under clear rules. But I would not support blocking new email addresses or unfamiliar participants as a category. The 2020 experience already showed why election safeguards and policy participation must be kept separate. Elections count votes; rough consensus evaluates distinct arguments and unresolved concerns. Claude or ChatGPT does not need an independent "seat." The accountable participant is the person who reviews the text, submits it, and stands behind it. An autonomous bot flooding the list can be blocked. A human using a drafting tool should have the contribution judged on relevance, evidence, and clarity, like everyone else. Repeated arguments can be consolidated without excluding the people raising them. That protects the list while avoiding the much greater danger of turning moderation into a mechanism for deciding who qualifies as "the community." My position is therefore simple: moderate proven disruption, consolidate repetition, encourage concise engagement, and keep the forum open to new participants. Moderation should preserve participation, not narrow it according to familiarity, subscription date, or drafting method. Regards, Nonhlanhla ________________________________ From: rpd-request at afrinic.net Sent: Thursday, 23 July 2026 17:01:41 To: rpd at afrinic.net Subject: RPD Digest, Vol 222, Issue 189 Send RPD mailing list submissions to rpd at afrinic.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.afrinic.net/mailman/listinfo/rpd or, via email, send a message with subject or body 'help' to rpd-request at afrinic.net You can reach the person managing the list at rpd-owner at afrinic.net When replying, please edit your Subject line so it is more specific than "Re: Contents of RPD digest..." Today's Topics: 1. Re: PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 (Mike Burns) 2. Re: PDWG Co-Chairs communication regarding observedbehavioron AFPUB-2026-ASN-001-DRAFT02 (Mike Burns) 3. Re: PDWG Co-Chairs communication regarding observed behavior on AFPUB-2026-ASN-001-DRAFT02 (Fundiswa Nadia Maseko) ---------------------------------------------------------------------- Message: 1 Date: Thu, 23 Jul 2026 10:50:27 -0400 From: "Mike Burns" To: "'Noah'" Cc: pdwg-chairs at afrinic.net, 'rpd List' Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 Message-ID: <027601dd1ab2$9982cd10$cc886730$@iptrading.com> Content-Type: text/plain; charset="utf-8" Hi Noah, I have made it clear from the outset that list swamping or use of AI to generate duplicative, though reworded objections is grounds for moderation. That issue, which I was at pains to separate from the use of AI, continues to be conflated with the simple use of AI. That brings me to ad hominem, which is the basis of my belief and which you have failed in your reply. Ad hominem means that the speaker of an argument is of no importance when considering the argument. When you ask my for my motive, you breach that. Regards, Mike From: Noah Sent: Thursday, July 23, 2026 10:03 AM To: Mike Burns Cc: Hytham El-Nakhal ; pdwg-chairs at afrinic.net; rpd List Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 On Wed, 22 Jul 2026, 8:53?pm Mike Burns, > wrote: It?s not like Claude will be elected to any parliament. But this unique governance form for a global asset provides the opportunity. I say, who cares if Claude is posting, or ChatGPT, or any other AI. I care that the AFRINIC rpd list is not turned into waste land of AI powered trolls Give them a seat at the table and address their arguments. How many valid argument have been made in the past week or you mean a single argument repeated through AI generated texts send by single persons using multiple different email address or same group saying the same thing over and over feeding the troll.... I have not experienced this behaviour on the ARIN or RIPE lists or even APNIC for which we are both participants.. Why are you advocating for it in the AFRNIC service region....? Cheers, ./noah -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Thu, 23 Jul 2026 10:59:33 -0400 From: "Mike Burns" To: "'Mike Silber'" , Subject: Re: [rpd] PDWG Co-Chairs communication regarding observedbehavioron AFPUB-2026-ASN-001-DRAFT02 Message-ID: <028e01dd1ab3$df1d2400$9d576c00$@iptrading.com> Content-Type: text/plain; charset="utf-8" Hi Mike, Those are excellent questions, and I think it lies within the moderators? mandate to block emails making the same argument incessantly, sockpuppets or not. I think we should rely on moderator judgement while we hopefully see better-crafted AI arguments. I trust the moderators have the tools necessary to discern and act when they see reworded arguments offered repetitively. Regards, Mike From: Mike Silber Sent: Thursday, July 23, 2026 10:43 AM To: rpd at afrinic.net Subject: Re: [rpd] PDWG Co-Chairs communication regarding observedbehavioron AFPUB-2026-ASN-001-DRAFT02 Hi Mike B On Thu, Jul 23, 2026 at 2:39?PM Mike Burns via RPD > wrote: I agree that swamping the list should be subject to moderation, and it already is. Indeed - but I think clearer parameters for moderation will be helpful to avoid accusations of partiality. But the more important question to me, is if Claude comes up with a winning argument, should we ignore or discount it? Definitely not. I have no issue with AI generated or supplemented / edited positions. I think the verbosity and repetition of these posts will work against them in the long run as effective use of AI tools. But if they can shorten and clarify their arguments, and resist the urge to repeat them slightly differently, I would listen to them. I agree that the current verbose and repetitive positing is not endearing these posters to the community or showing any compelling arguments. The simplistic view is that this is an unsophisticated campaign using various sockpuppet accounts to try to create the perception of large scale dissent. But what if it is actually a sophisticated campaign to drown out other participation, cause list members to unsubscribe or withdraw in frustration that can then lead to the "capture" of the process by hollowing out positive contributions? Mike S -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Thu, 23 Jul 2026 17:01:08 +0200 From: Fundiswa Nadia Maseko To: rpd at afrinic.net Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavior on AFPUB-2026-ASN-001-DRAFT02 Message-ID: Content-Type: text/plain; charset="utf-8" Dear colleagues, I agree that repetitive posts and list flooding should be moderated. However, I don't think the use of AI should, on its own, determine how a contribution is viewed. AI is simply a tool. The participant is still responsible for reviewing, understanding, and standing behind what they submit. In the end, what matters is whether the argument is clear, relevant, and technically sound. If moderation is needed, it should be based on conduct and the quality of participation, not on the tools someone used to draft their message. Kind regards, Fundiswa Nadia Maseko On Thu, 23 Jul 2026, 16:44 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: PDWG Co-Chairs communication regarding observed > behavioron AFPUB-2026-ASN-001-DRAFT02 (Mike Burns) > 2. Fw: PDWG Co-Chairs communication regarding observed behavior > on AFPUB-2026-ASN-001-DRAFT02 (NP Petronella) > 3. Re: PDWG Co-Chairs communication regarding observed > behavioron AFPUB-2026-ASN-001-DRAFT02 (Noah) > 4. Re: PDWG Co-Chairs communication regarding observed > behavioron AFPUB-2026-ASN-001-DRAFT02 (Mike Silber) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 23 Jul 2026 08:38:45 -0400 > From: "Mike Burns" > To: "'Frank Habicht'" , > Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed > behavioron AFPUB-2026-ASN-001-DRAFT02 > Message-ID: <020d01dd1aa0$33beba50$9b3c2ef0$@iptrading.com> > Content-Type: text/plain; charset="us-ascii" > > HI Frank, > > Thanks for playing Devil's Advocate, I think that is a worthwhile effort. > > I agree that swamping the list should be subject to moderation, and it > already is. > But the more important question to me, is if Claude comes up with a winning > argument, should we ignore or discount it? > > I think the verbosity and repetition of these posts will work against them > in the long run as effective use of AI tools. > But if they can shorten and clarify their arguments, and resist the urge to > repeat them slightly differently, I would listen to them. > > Regards, > Mike > > > -----Original Message----- > From: Frank Habicht > Sent: Thursday, July 23, 2026 12:37 AM > To: rpd at afrinic.net > Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed > behavioron AFPUB-2026-ASN-001-DRAFT02 > > Hi, > > On 7/22/2026 8:53 PM, Mike Burns via RPD wrote: > [snip] > > I say, who cares if Claude is posting, or ChatGPT, or any other AI. > > > > Give them a seat at the table and address their arguments. > > > > Giving them a veneer of humanness through identity appropriation is > > not the way forward. > > > > Again, I am interested in hearing other perspectives. > > I'd like to hear what should happen if then two Claudes are arguing at > 5000 email per hour and eventually one Claude wins the argument, and > AfriNIC > will have to implement a policy that e.g. bans you from posting here? > > Frank > Devil's advocate > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > > > ------------------------------ > > Message: 2 > Date: Thu, 23 Jul 2026 13:30:13 +0000 > From: NP Petronella > To: "Rpd at afrinic.net" , "mike at iptrading.com" > > Subject: [rpd] Fw: PDWG Co-Chairs communication regarding observed > behavior on AFPUB-2026-ASN-001-DRAFT02 > Message-ID: > < > VI2PR09MB7139828F4B931D6A9D51C9F1A4C02 at VI2PR09MB7139.eurprd09.prod.outlook.com > > > > Content-Type: text/plain; charset="us-ascii" > > > ________________________________ > From: NP Petronella > Sent: Thursday, 23 July 2026 15:25:26 > To: rpd-request at afrinic.net ; mike at iptrading.com > > Subject: [rpd] PDWG Co-Chairs communication regarding observed behavior on > AFPUB-2026-ASN-001-DRAFT02 > > > Hi Mike, > > I think that is a fair approach. A strong argument should not be > discounted because a tool helped express it, just as a weak argument should > not gain weight merely because someone typed it unaided. > > The 2020 experience offers a useful distinction. Where voting was > involved, eligibility controls were considered because votes are counted. > Policy discussion is different: rough consensus should assess distinct > arguments, not subscription dates or the number of similar messages. > > Repeated points can be consolidated, and actual list-swamping can already > be moderated. At the same time, newer participants and AI-assisted > contributions should still be judged on clarity, relevance, and evidence. > > That seems the balanced position: moderate conduct, not tools; reduce > repetition, not participation; and keep the focus on the argument rather > than the author. > > Regards, > Nonhlanhla > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260723/caa1697e/attachment-0001.html > > > > ------------------------------ > > Message: 3 > Date: Thu, 23 Jul 2026 17:03:02 +0300 > From: Noah > To: Mike Burns > Cc: pdwg-chairs at afrinic.net, rpd List > Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed > behavioron AFPUB-2026-ASN-001-DRAFT02 > Message-ID: > < > CAEqgTWZVdRe+kfxUjevob2w4PurLzzY4r8DjNKq1-wABf8S0gQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Wed, 22 Jul 2026, 8:53?pm Mike Burns, wrote: > > > > > It?s not like Claude will be elected to any parliament. > > > > But this unique governance form for a global asset provides the > > opportunity. > > > > I say, who cares if Claude is posting, or ChatGPT, or any other AI. > > > I care that the AFRINIC rpd list is not turned into waste land of AI > powered trolls > > Give them a seat at the table and address their arguments. > > > > How many valid argument have been made in the past week or you mean a > single argument repeated through AI generated texts send by single persons > using multiple different email address or same group saying the same thing > over and over feeding the troll.... > > I have not experienced this behaviour on the ARIN or RIPE lists or even > APNIC for which we are both participants.. > > Why are you advocating for it in the AFRNIC service region....? > > Cheers, > *.**/noah* > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260723/fd504aad/attachment-0001.html > > > > ------------------------------ > > Message: 4 > Date: Thu, 23 Jul 2026 16:43:25 +0200 > From: Mike Silber > To: rpd at afrinic.net > Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed > behavioron AFPUB-2026-ASN-001-DRAFT02 > Message-ID: > < > CAE-cm4LvzxAERypoy2a16SUniYQA_+heXqPnC-YG6gNYtUvp7Q at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Mike B > > On Thu, Jul 23, 2026 at 2:39?PM Mike Burns via RPD > wrote: > > > > > I agree that swamping the list should be subject to moderation, and it > > already is. > > > > Indeed - but I think clearer parameters for moderation will be helpful to > avoid accusations of partiality. > > > > But the more important question to me, is if Claude comes up with a > winning > > argument, should we ignore or discount it? > > > > Definitely not. I have no issue with AI generated or supplemented / edited > positions. > > > > > I think the verbosity and repetition of these posts will work against > them > > in the long run as effective use of AI tools. > > But if they can shorten and clarify their arguments, and resist the urge > to > > repeat them slightly differently, I would listen to them. > > > > I agree that the current verbose and repetitive positing is not endearing > these posters to the community or showing any compelling arguments. The > simplistic view is that this is an unsophisticated campaign using various > sockpuppet accounts to try to create the perception of large scale dissent. > > But what if it is actually a sophisticated campaign to drown out other > participation, cause list members to unsubscribe or withdraw in frustration > that can then lead to the "capture" of the process by hollowing out > positive contributions? > > Mike S > > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260723/ef969099/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 188 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ End of RPD Digest, Vol 222, Issue 189 ************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Thu Jul 23 16:03:39 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Thu, 23 Jul 2026 18:03:39 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 189 In-Reply-To: References: Message-ID: On 23 Jul 2026, at 17:05, NP Petronella wrote: > Dear colleagues, > > I honestly think there is a reasonable middle ground here. > > The list should not be allowed to become unusable. If an account is posting at automated volume, repeatedly sending the same message, or deliberately disrupting discussion, the co-chairs should address that conduct under clear rules. I?ll substitute ?account? with ?group? -> astroturfing effects. > Repeated arguments can be consolidated without excluding the people raising them. That protects the list while avoiding the much greater danger of turning moderation into a mechanism for deciding who qualifies as "the community." yeah, the problem is when the astroturfers make it difficult and they don?t answer the questions honestly/truthfully/concisely, but using the tool to regurgitate a prose of useless large words to sounds important, that then is done in organized synchrony (like minutes from each other the exact same message, just differently worded from obvious AI tools) that is when the use of AI tools becomes a pain point, not a resolution assistance anymore. > My position is therefore simple: moderate proven disruption, consolidate repetition, encourage concise engagement, and keep the forum open to new participants. Moderation should preserve participation, not narrow it according to familiarity, subscription date, or drafting method. Yes simple, but the astroturfers the past 2weeks had been? tiring, instead of adding any real value other than objections for the sake of objections. Just refer to the answers on the six questions posed earlier today, and you will see how the use of automated AI tools caused for a knee jerk reaction, with people proudly and loudly claiming their RIGHTS instead of being humble new comers. They would?ve gained many more respect that way, than to cause cause the real operator?s neck hairs to raise and to continue to antagonizing them until the point where the co-chairs had to respond. I actually are still awaiting a response on your email swap reason as in appeared that the previous email was an impersonation? Please respond to the direct email to the old email to confirm whether your ?complaints? was about being moderated, or actual impersonation. At present, given the lack of confirmation to the contrary, I?m of the opinion that you did impersonate the real person by abusing their email. From emmanuelmabasa1 at yahoo.com Thu Jul 23 16:16:29 2026 From: emmanuelmabasa1 at yahoo.com (Mzwakhe Mabasa) Date: Thu, 23 Jul 2026 16:16:29 +0000 (UTC) Subject: [rpd] RPD References: <650428700.2481490.1784823389135.ref@mail.yahoo.com> Message-ID: <650428700.2481490.1784823389135@mail.yahoo.com> The Resource Policy Discussion (RPD) mailing list is the primary public forum where AFRINIC community members propose, debate, and reach consensus on rules for managing Africa?s IP address resources. It drives the bottom-up Policy Development Process (PDP), ensures operational transparency, and grants stakeholders a direct voice in regional Internet self-governance.Core Importance of the RPD ListOpen Participation: Allows anyone?regardless of geographic location or membership status?to freely contribute to African Internet policy.Consensus Building: Serves as the core testing ground where draft policies are scrutinized before being recommended to the AFRINIC Board.Equitable Governance: Protects the fair distribution of scarce resources like IPv4 and IPv6 addresses across the continent.Community Accountability: Maintains a public, archived history of all debates, preserving transparency and organizational trust.If you'd like, I can provide details on:How to subscribe to the RPD mailing list The stages a policy proposal goes through from RPD to board adoption. -------------- next part -------------- An HTML attachment was scrubbed... URL: From NPertuniaPetronella at outlook.com Thu Jul 23 16:17:15 2026 From: NPertuniaPetronella at outlook.com (NP Petronella) Date: Thu, 23 Jul 2026 16:17:15 +0000 Subject: [rpd] RPD Digest, Vol 222, Issue 189 In-Reply-To: References: Message-ID: Dear Hendrik, Let me be clear: I did not impersonate anyone. I changed email accounts after experiencing unusual activity on my previous Gmail account, including an unexpected unsubscribe and problems with messages on the same day I was particularly active on the list. I am not claiming to know who caused those issues, and I have not accused anyone without evidence. I simply stopped relying on an account I no longer trusted. Your private message to the old address is not a neutral identity-verification process, and I am not required to use an unreliable mailbox to satisfy a test designed by another participant. If the co-chairs require formal verification, I am willing to cooperate with a neutral, privacy-respecting process applied equally to everyone. What I will not accept is your attempt to turn personal suspicion into a verdict. You are not a court, and repeated references to ?probabilities? do not prove impersonation, astroturfing, or bad faith. Nor do newcomers have to behave as ?humble guests? before established operators. Experience contributes evidence; it does not grant ownership of the PDP. An open process cannot invite participation and then allow familiar participants to decide who has sufficient status, affiliation, or ?skin in the game? to be heard. If you have concrete evidence of a breach, submit it to the co-chairs. Otherwise, please stop presenting speculation as fact and return to the policy discussion. I will not engage further in private identity tests or accusations. Regards, Nonhlanhla ________________________________ From: Hendrik Visage Sent: Thursday, 23 July 2026 18:03:39 To: NP Petronella Cc: rpd at afrinic.net ; rpd-owner at afrinic.net Subject: Re: [rpd] RPD Digest, Vol 222, Issue 189 On 23 Jul 2026, at 17:05, NP Petronella wrote: > Dear colleagues, > > I honestly think there is a reasonable middle ground here. > > The list should not be allowed to become unusable. If an account is posting at automated volume, repeatedly sending the same message, or deliberately disrupting discussion, the co-chairs should address that conduct under clear rules. I?ll substitute ?account? with ?group? -> astroturfing effects. > Repeated arguments can be consolidated without excluding the people raising them. That protects the list while avoiding the much greater danger of turning moderation into a mechanism for deciding who qualifies as "the community." yeah, the problem is when the astroturfers make it difficult and they don?t answer the questions honestly/truthfully/concisely, but using the tool to regurgitate a prose of useless large words to sounds important, that then is done in organized synchrony (like minutes from each other the exact same message, just differently worded from obvious AI tools) that is when the use of AI tools becomes a pain point, not a resolution assistance anymore. > My position is therefore simple: moderate proven disruption, consolidate repetition, encourage concise engagement, and keep the forum open to new participants. Moderation should preserve participation, not narrow it according to familiarity, subscription date, or drafting method. Yes simple, but the astroturfers the past 2weeks had been? tiring, instead of adding any real value other than objections for the sake of objections. Just refer to the answers on the six questions posed earlier today, and you will see how the use of automated AI tools caused for a knee jerk reaction, with people proudly and loudly claiming their RIGHTS instead of being humble new comers. They would?ve gained many more respect that way, than to cause cause the real operator?s neck hairs to raise and to continue to antagonizing them until the point where the co-chairs had to respond. I actually are still awaiting a response on your email swap reason as in appeared that the previous email was an impersonation? Please respond to the direct email to the old email to confirm whether your ?complaints? was about being moderated, or actual impersonation. At present, given the lack of confirmation to the contrary, I?m of the opinion that you did impersonate the real person by abusing their email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From seun.ojedeji at gmail.com Thu Jul 23 16:24:32 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Thu, 23 Jul 2026 18:24:32 +0200 Subject: [rpd] RPD In-Reply-To: <650428700.2481490.1784823389135@mail.yahoo.com> References: <650428700.2481490.1784823389135.ref@mail.yahoo.com> <650428700.2481490.1784823389135@mail.yahoo.com> Message-ID: Hello Mzwakhe, Who is this mail for? Okay I think I was wrong to imagine that AI prompters can be tolerated for a while. I hope the CoC is updated soon enough so the Co-Chair can do the needful. Regards ---- Sent from my mobile kindly excuse typos On Thu, 23 Jul 2026, 6:17?pm Mzwakhe Mabasa via RPD, wrote: > > > > The Resource Policy Discussion (RPD) mailing list is the primary public > forum where AFRINIC community members propose, debate, and reach consensus > on rules for managing Africa?s IP address resources. It drives the > bottom-up Policy Development Process (PDP), ensures operational > transparency, and grants stakeholders a direct voice in regional Internet > self-governance.Core Importance of the RPD ListOpen Participation: Allows > anyone?regardless of geographic location or membership status?to freely > contribute to African Internet policy.Consensus Building: Serves as the > core testing ground where draft policies are scrutinized before being > recommended to the AFRINIC Board.Equitable Governance: Protects the fair > distribution of scarce resources like IPv4 and IPv6 addresses across the > continent.Community Accountability: Maintains a public, archived history of > all debates, preserving transparency and organizational trust.If you'd > like, I can provide details on:How to subscribe to the RPD mailing list The > stages a policy proposal goes through from RPD to board adoption. > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonjabulosphilile at gmail.com Thu Jul 23 15:25:26 2026 From: nonjabulosphilile at gmail.com (Nonjabulo Sphilile) Date: Thu, 23 Jul 2026 17:25:26 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 189 Message-ID: Hi All, I support Nonhlanhla?s position. The real risk is not only excessive traffic. It is allowing a long-standing circle to treat unfamiliar contributors as outsiders whose participation is conditional. The RPD list has dealt with sudden increases in new subscribers before. The answer was to distinguish numerical processes, such as elections, from policy discussion, where the argument matters more than the age or familiarity of the account. The co-chairs can manage volume, group repeated points, and act against genuine disruption. None of that requires blocking new participants or treating subscription history as a credential. An open PDP should not develop an inner room for recognised names and an outer room for everyone else. Community participation provides evidence and scrutiny; it does not give regular participants ownership of the forum. Regards, Nonjabulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah at neo.co.tz Thu Jul 23 17:26:18 2026 From: noah at neo.co.tz (Noah) Date: Thu, 23 Jul 2026 20:26:18 +0300 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: <027601dd1ab2$9982cd10$cc886730$@iptrading.com> References: <1784639031075.56443@tra.gov.eg> <00e501dd1a03$0c54a1c0$24fde540$@iptrading.com> <027601dd1ab2$9982cd10$cc886730$@iptrading.com> Message-ID: Hi Mike What AI generated arguments will possibly change the facts that as-set collision is an issue. Havent we already documented the fact that as-set names collide across IRR databases and AI/Claude have nothing to do with this fact. When merging across IRR databases, havent we ack that collisions have resulted in ambiguity, empty or conflicting objects that cause tools to return incorrect or empty filter data. How is this AI/Claude problem? Havent other RIR implemented, hierarchical naming, some through policy others through operational implementations to bind new as-set to a specific ASN holder. Did they consult AI/Claude while at it? Havent folks agreed that going forward we fix the issue at the moment of creation of new as-sets the only point at which an authoritative registry can prevent new instances of collision problem. I dont see how this is AI/claude concern nor how AI will be involved in technically fixing the problem even those outsourcing their thinking to claude to oppose what we want to fix wont be on the ground to fix the issue. Cheers, *.**/noah* On Thu, 23 Jul 2026, 5:50?pm Mike Burns, wrote: > Hi Noah, > > > > I have made it clear from the outset that list swamping or use of AI to > generate duplicative, though reworded objections is grounds for moderation. > > That issue, which I was at pains to separate from the use of AI, continues > to be conflated with the simple use of AI. > > > > That brings me to ad hominem, which is the basis of my belief and which > you have failed in your reply. > > > > Ad hominem means that the speaker of an argument is of no importance when > considering the argument. > > > > When you ask my for my motive, you breach that. > > > > Regards, > > > > Mike > > > > > > *From:* Noah > *Sent:* Thursday, July 23, 2026 10:03 AM > *To:* Mike Burns > *Cc:* Hytham El-Nakhal ; pdwg-chairs at afrinic.net; rpd > List > *Subject:* Re: [rpd] PDWG Co-Chairs communication regarding observed > behavioron AFPUB-2026-ASN-001-DRAFT02 > > > > > > On Wed, 22 Jul 2026, 8:53?pm Mike Burns, wrote: > > > > It?s not like Claude will be elected to any parliament. > > But this unique governance form for a global asset provides the > opportunity. > > I say, who cares if Claude is posting, or ChatGPT, or any other AI. > > I care that the AFRINIC rpd list is not turned into waste land of AI > powered trolls > > > > Give them a seat at the table and address their arguments. > > > > How many valid argument have been made in the past week or you mean a > single argument repeated through AI generated texts send by single persons > using multiple different email address or same group saying the same thing > over and over feeding the troll.... > > > > I have not experienced this behaviour on the ARIN or RIPE lists or even > APNIC for which we are both participants.. > > > > Why are you advocating for it in the AFRNIC service region....? > > > > Cheers, > > *./noah* > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Thu Jul 23 17:29:30 2026 From: mike at iptrading.com (Mike Burns) Date: Thu, 23 Jul 2026 13:29:30 -0400 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: References: <1784639031075.56443@tra.gov.eg> <00e501dd1a03$0c54a1c0$24fde540$@iptrading.com> <027601dd1ab2$9982cd10$cc886730$@iptrading.com> Message-ID: <02f701dd1ac8$d2298260$767c8720$@iptrading.com> Hi Noah, I have made no comments on the AS-SET issue and tried to create a separate discussion thread for AI. Regards, Mike From: Noah Sent: Thursday, July 23, 2026 1:26 PM To: Mike Burns Cc: Hytham El-Nakhal ; pdwg-chairs at afrinic.net; rpd List Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 Hi Mike What AI generated arguments will possibly change the facts that as-set collision is an issue. Havent we already documented the fact that as-set names collide across IRR databases and AI/Claude have nothing to do with this fact. When merging across IRR databases, havent we ack that collisions have resulted in ambiguity, empty or conflicting objects that cause tools to return incorrect or empty filter data. How is this AI/Claude problem? Havent other RIR implemented, hierarchical naming, some through policy others through operational implementations to bind new as-set to a specific ASN holder. Did they consult AI/Claude while at it? Havent folks agreed that going forward we fix the issue at the moment of creation of new as-sets the only point at which an authoritative registry can prevent new instances of collision problem. I dont see how this is AI/claude concern nor how AI will be involved in technically fixing the problem even those outsourcing their thinking to claude to oppose what we want to fix wont be on the ground to fix the issue. Cheers, ./noah On Thu, 23 Jul 2026, 5:50?pm Mike Burns, > wrote: Hi Noah, I have made it clear from the outset that list swamping or use of AI to generate duplicative, though reworded objections is grounds for moderation. That issue, which I was at pains to separate from the use of AI, continues to be conflated with the simple use of AI. That brings me to ad hominem, which is the basis of my belief and which you have failed in your reply. Ad hominem means that the speaker of an argument is of no importance when considering the argument. When you ask my for my motive, you breach that. Regards, Mike From: Noah > Sent: Thursday, July 23, 2026 10:03 AM To: Mike Burns > Cc: Hytham El-Nakhal >; pdwg-chairs at afrinic.net ; rpd List > Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 On Wed, 22 Jul 2026, 8:53?pm Mike Burns, > wrote: It?s not like Claude will be elected to any parliament. But this unique governance form for a global asset provides the opportunity. I say, who cares if Claude is posting, or ChatGPT, or any other AI. I care that the AFRINIC rpd list is not turned into waste land of AI powered trolls Give them a seat at the table and address their arguments. How many valid argument have been made in the past week or you mean a single argument repeated through AI generated texts send by single persons using multiple different email address or same group saying the same thing over and over feeding the troll.... I have not experienced this behaviour on the ARIN or RIPE lists or even APNIC for which we are both participants.. Why are you advocating for it in the AFRNIC service region....? Cheers, ./noah -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah at neo.co.tz Thu Jul 23 17:40:41 2026 From: noah at neo.co.tz (Noah) Date: Thu, 23 Jul 2026 20:40:41 +0300 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: <02f701dd1ac8$d2298260$767c8720$@iptrading.com> References: <1784639031075.56443@tra.gov.eg> <00e501dd1a03$0c54a1c0$24fde540$@iptrading.com> <027601dd1ab2$9982cd10$cc886730$@iptrading.com> <02f701dd1ac8$d2298260$767c8720$@iptrading.com> Message-ID: I did not say you commented on as-set issue.. The co-chair initiated this thread per subjectline which is related to hierarchical names for new as-set draft policy AFPUB-2026-ASN-001-DRAFT02. The co-chair openning statement read... in quote "The mailing list has recently been flooded with multiple emails stating either the same duplicate objections or consistent pushbacks to every post, some of them with subject line containing ?Digest?." The above is an outcome of folks outsourcing their thinking to AI and endlessly trolling using multiple emails and sockpuppets to bombard the rpd list. You are talking about usage of AI and seeing no issue with it. I am telling you I have had enough of it. Cheers, *.**/noah* On Thu, 23 Jul 2026, 8:29?pm Mike Burns, wrote: > Hi Noah, > > > > I have made no comments on the AS-SET issue and tried to create a separate > discussion thread for AI. > > > > Regards, > > Mike > > > > > > *From:* Noah > *Sent:* Thursday, July 23, 2026 1:26 PM > *To:* Mike Burns > *Cc:* Hytham El-Nakhal ; pdwg-chairs at afrinic.net; rpd > List > *Subject:* Re: [rpd] PDWG Co-Chairs communication regarding observed > behavioron AFPUB-2026-ASN-001-DRAFT02 > > > > Hi Mike > > > > What AI generated arguments will possibly change the facts that as-set > collision is an issue. > > > > Havent we already documented the fact that as-set names collide across IRR > databases and AI/Claude have nothing to do with this fact. > > > > When merging across IRR databases, havent we ack that collisions have > resulted in ambiguity, empty or conflicting objects that cause tools to > return incorrect or empty filter data. How is this AI/Claude problem? > > > > Havent other RIR implemented, hierarchical naming, some through policy > others through operational implementations to bind new as-set to a specific > ASN holder. Did they consult AI/Claude while at it? > > > > Havent folks agreed that going forward we fix the issue at the moment of > creation of new as-sets the only point at which an authoritative registry > can prevent new instances of collision problem. I dont see how this is > AI/claude concern nor how AI will be involved in technically fixing the > problem even those outsourcing their thinking to claude to oppose what we > want to fix wont be on the ground to fix the issue. > > > > Cheers, > > *./noah* > > > > > > > > On Thu, 23 Jul 2026, 5:50?pm Mike Burns, wrote: > > Hi Noah, > > > > I have made it clear from the outset that list swamping or use of AI to > generate duplicative, though reworded objections is grounds for moderation. > > That issue, which I was at pains to separate from the use of AI, continues > to be conflated with the simple use of AI. > > > > That brings me to ad hominem, which is the basis of my belief and which > you have failed in your reply. > > > > Ad hominem means that the speaker of an argument is of no importance when > considering the argument. > > > > When you ask my for my motive, you breach that. > > > > Regards, > > > > Mike > > > > > > *From:* Noah > *Sent:* Thursday, July 23, 2026 10:03 AM > *To:* Mike Burns > *Cc:* Hytham El-Nakhal ; pdwg-chairs at afrinic.net; rpd > List > *Subject:* Re: [rpd] PDWG Co-Chairs communication regarding observed > behavioron AFPUB-2026-ASN-001-DRAFT02 > > > > > > On Wed, 22 Jul 2026, 8:53?pm Mike Burns, wrote: > > > > It?s not like Claude will be elected to any parliament. > > But this unique governance form for a global asset provides the > opportunity. > > I say, who cares if Claude is posting, or ChatGPT, or any other AI. > > I care that the AFRINIC rpd list is not turned into waste land of AI > powered trolls > > > > Give them a seat at the table and address their arguments. > > > > How many valid argument have been made in the past week or you mean a > single argument repeated through AI generated texts send by single persons > using multiple different email address or same group saying the same thing > over and over feeding the troll.... > > > > I have not experienced this behaviour on the ARIN or RIPE lists or even > APNIC for which we are both participants.. > > > > Why are you advocating for it in the AFRNIC service region....? > > > > Cheers, > > *./noah* > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Thu Jul 23 20:08:41 2026 From: mike at iptrading.com (Mike Burns) Date: Thu, 23 Jul 2026 16:08:41 -0400 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: References: <1784639031075.56443@tra.gov.eg> <00e501dd1a03$0c54a1c0$24fde540$@iptrading.com> <027601dd1ab2$9982cd10$cc886730$@iptrading.com> <02f701dd1ac8$d2298260$767c8720$@iptrading.com> Message-ID: <033b01dd1adf$0f03a830$2d0af890$@iptrading.com> Hi Noah, Yes you are telling everybody that you have had enough of it. Fair enough. Yes, I am seeing no issue using AI unless it is used at cross-purposes of the list. I don?t think the use of AI in this context has reached that level, and also I don?t think it has been very effective. I think in the future AI will write more effective messages to the list, with or without human intervention. I will read those effective messages and argue against, or accept the arguments made. Regards, Mike From: Noah Sent: Thursday, July 23, 2026 1:41 PM To: Mike Burns Cc: Hytham El-Nakhal ; pdwg-chairs at afrinic.net; rpd List Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 I did not say you commented on as-set issue.. The co-chair initiated this thread per subjectline which is related to hierarchical names for new as-set draft policy AFPUB-2026-ASN-001-DRAFT02. The co-chair openning statement read... in quote "The mailing list has recently been flooded with multiple emails stating either the same duplicate objections or consistent pushbacks to every post, some of them with subject line containing ?Digest?." The above is an outcome of folks outsourcing their thinking to AI and endlessly trolling using multiple emails and sockpuppets to bombard the rpd list. You are talking about usage of AI and seeing no issue with it. I am telling you I have had enough of it. Cheers, ./noah On Thu, 23 Jul 2026, 8:29?pm Mike Burns, > wrote: Hi Noah, I have made no comments on the AS-SET issue and tried to create a separate discussion thread for AI. Regards, Mike From: Noah < noah at neo.co.tz> Sent: Thursday, July 23, 2026 1:26 PM To: Mike Burns < mike at iptrading.com> Cc: Hytham El-Nakhal < hytham at tra.gov.eg>; pdwg-chairs at afrinic.net; rpd List < rpd at afrinic.net> Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 Hi Mike What AI generated arguments will possibly change the facts that as-set collision is an issue. Havent we already documented the fact that as-set names collide across IRR databases and AI/Claude have nothing to do with this fact. When merging across IRR databases, havent we ack that collisions have resulted in ambiguity, empty or conflicting objects that cause tools to return incorrect or empty filter data. How is this AI/Claude problem? Havent other RIR implemented, hierarchical naming, some through policy others through operational implementations to bind new as-set to a specific ASN holder. Did they consult AI/Claude while at it? Havent folks agreed that going forward we fix the issue at the moment of creation of new as-sets the only point at which an authoritative registry can prevent new instances of collision problem. I dont see how this is AI/claude concern nor how AI will be involved in technically fixing the problem even those outsourcing their thinking to claude to oppose what we want to fix wont be on the ground to fix the issue. Cheers, ./noah On Thu, 23 Jul 2026, 5:50?pm Mike Burns, > wrote: Hi Noah, I have made it clear from the outset that list swamping or use of AI to generate duplicative, though reworded objections is grounds for moderation. That issue, which I was at pains to separate from the use of AI, continues to be conflated with the simple use of AI. That brings me to ad hominem, which is the basis of my belief and which you have failed in your reply. Ad hominem means that the speaker of an argument is of no importance when considering the argument. When you ask my for my motive, you breach that. Regards, Mike From: Noah < noah at neo.co.tz> Sent: Thursday, July 23, 2026 10:03 AM To: Mike Burns < mike at iptrading.com> Cc: Hytham El-Nakhal < hytham at tra.gov.eg>; pdwg-chairs at afrinic.net; rpd List < rpd at afrinic.net> Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 On Wed, 22 Jul 2026, 8:53?pm Mike Burns, > wrote: It?s not like Claude will be elected to any parliament. But this unique governance form for a global asset provides the opportunity. I say, who cares if Claude is posting, or ChatGPT, or any other AI. I care that the AFRINIC rpd list is not turned into waste land of AI powered trolls Give them a seat at the table and address their arguments. How many valid argument have been made in the past week or you mean a single argument repeated through AI generated texts send by single persons using multiple different email address or same group saying the same thing over and over feeding the troll.... I have not experienced this behaviour on the ARIN or RIPE lists or even APNIC for which we are both participants.. Why are you advocating for it in the AFRNIC service region....? Cheers, ./noah -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Fri Jul 24 03:21:05 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Fri, 24 Jul 2026 05:21:05 +0200 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: <033b01dd1adf$0f03a830$2d0af890$@iptrading.com> References: <033b01dd1adf$0f03a830$2d0af890$@iptrading.com> Message-ID: An HTML attachment was scrubbed... URL: From h.lu at anytimechinese.com Fri Jul 24 08:00:38 2026 From: h.lu at anytimechinese.com (Lu Heng) Date: Fri, 24 Jul 2026 17:00:38 +0900 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: References: <033b01dd1adf$0f03a830$2d0af890$@iptrading.com> Message-ID: The discussion is focused on the wrong unit. What matters is not whether a message was drafted by a human or an AI, but whether it contributes a distinct, relevant, and evidence-based argument. The correct moderation targets are duplication, flooding, irrelevance, and unsupported claims?not the drafting tool. The practical solution is straightforward: place the policy, or each disputed clause, in the centre of a web interface; display the arguments for and against it on either side; and use AI to maintain a continuous summary, cluster repeated arguments, and identify genuinely new ones. Anyone should be free to submit a new argument or supporting evidence, while every AI classification remains visible and appealable. A basic prototype could be built in a day. Whether humans should retain a monopoly over argumentation is a separate question. They have no principled claim to such a monopoly once machines can competently compare, organize, and summarize arguments at scale. More importantly, a human-only process does not preserve openness. Repeated interaction tends to produce a small, self-selecting clique that determines whose language, identity, and participation count, excludes outsiders, and eventually becomes insular and cult-like. This is mandate laundering: control over procedure is converted into an illegitimate claim of substantive authority. Once that happens, formal openness ceases to provide legitimacy. The RIR system may continue to exist in name, but its bottom-up model will have effectively ended. -- Kind regards. Lu On Fri, Jul 24, 2026 at 12:24 Ben Roberts - AfriNIC via RPD wrote: > Mike, > You are trivialising the issue as a mere AI content problem. If it were > just a case that some people are using AI writing tools then we would not > be having this debate. > > What we have seen is a co-ordinated Astroturfing attack of multiple > anonymous gmails, bombarding the list with near identical yet largely > meaningless essays all backing each other up. There may have been humans > with keyboards sitting owning the gmails, but I?ve seen no evidence of > ?proof of life? behind the accounts. Not even basic pleasantries (e.g. > ?hello how are you?) or variation from the monotonic robot style. If it > looks like an AI robot, quacks like an AI robot, then guess what, 9 times > out of 10 it?s an AI robot. > So it?s entirely very probable that they are just AI agent robots running > on Openclaw instances that are fully in control of the Gmail accounts. Or > it could just be one Openclaw controlling multiple Gmails, which would > explain the ?hive mind? like co-ordinated and recycled paragraphs that are > word for word recycled by member accounts of the collective. The > ?community? for policy development is supposed to be a community of humans. > The known identifiable humans in the collective seem to have concencus that > none of us have a problem with other known humans using AI tools to assist > their writing. > It will be very easy to modify the CoC to clarify that list membership is > restricted to real old fashioned humans sitting with computer gadgets that > they use to post the list, while excluding autonomous computer devices > running their own writing/posting programs in absence of human creativity. > > Kind regards > Ben > > > Sent from my iPhone > > On 23 Jul 2026, at 22:09, Mike Burns via RPD wrote: > > ? > > Hi Noah, > > > > Yes you are telling everybody that you have had enough of it. Fair enough. > > > > Yes, I am seeing no issue using AI unless it is used at cross-purposes of > the list. > > I don?t think the use of AI in this context has reached that level, and > also I don?t think it has been very effective. > > > > I think in the future AI will write more effective messages to the list, > with or without human intervention. > > I will read those effective messages and argue against, or accept the > arguments made. > > > > Regards, > Mike > > > > > > > > > > *From:* Noah > *Sent:* Thursday, July 23, 2026 1:41 PM > *To:* Mike Burns > *Cc:* Hytham El-Nakhal ; pdwg-chairs at afrinic.net; rpd > List > *Subject:* Re: [rpd] PDWG Co-Chairs communication regarding observed > behavioron AFPUB-2026-ASN-001-DRAFT02 > > > > I did not say you commented on as-set issue.. > > > > The co-chair initiated this thread per subjectline which is related to > hierarchical names for new as-set draft policy AFPUB-2026-ASN-001-DRAFT02. > > > > The co-chair openning statement read... in quote > > > > "The mailing list has recently been flooded with multiple emails stating > either the same duplicate objections or consistent pushbacks to every post, > some of them with subject line containing ?Digest?." > > > > The above is an outcome of folks outsourcing their thinking to AI and > endlessly trolling using multiple emails and sockpuppets to bombard the rpd > list. > > > > You are talking about usage of AI and seeing no issue with it. > > > > I am telling you I have had enough of it. > > > > Cheers, > > *./noah* > > > > > > > > On Thu, 23 Jul 2026, 8:29?pm Mike Burns, wrote: > > Hi Noah, > > > > I have made no comments on the AS-SET issue and tried to create a separate > discussion thread for AI. > > > > Regards, > > Mike > > > > > > *From:* Noah > *Sent:* Thursday, July 23, 2026 1:26 PM > *To:* Mike Burns > *Cc:* Hytham El-Nakhal ; pdwg-chairs at afrinic.net; rpd > List > *Subject:* Re: [rpd] PDWG Co-Chairs communication regarding observed > behavioron AFPUB-2026-ASN-001-DRAFT02 > > > > Hi Mike > > > > What AI generated arguments will possibly change the facts that as-set > collision is an issue. > > > > Havent we already documented the fact that as-set names collide across IRR > databases and AI/Claude have nothing to do with this fact. > > > > When merging across IRR databases, havent we ack that collisions have > resulted in ambiguity, empty or conflicting objects that cause tools to > return incorrect or empty filter data. How is this AI/Claude problem? > > > > Havent other RIR implemented, hierarchical naming, some through policy > others through operational implementations to bind new as-set to a specific > ASN holder. Did they consult AI/Claude while at it? > > > > Havent folks agreed that going forward we fix the issue at the moment of > creation of new as-sets the only point at which an authoritative registry > can prevent new instances of collision problem. I dont see how this is > AI/claude concern nor how AI will be involved in technically fixing the > problem even those outsourcing their thinking to claude to oppose what we > want to fix wont be on the ground to fix the issue. > > > > Cheers, > > *./noah* > > > > > > > > On Thu, 23 Jul 2026, 5:50?pm Mike Burns, wrote: > > Hi Noah, > > > > I have made it clear from the outset that list swamping or use of AI to > generate duplicative, though reworded objections is grounds for moderation. > > That issue, which I was at pains to separate from the use of AI, continues > to be conflated with the simple use of AI. > > > > That brings me to ad hominem, which is the basis of my belief and which > you have failed in your reply. > > > > Ad hominem means that the speaker of an argument is of no importance when > considering the argument. > > > > When you ask my for my motive, you breach that. > > > > Regards, > > > > Mike > > > > > > *From:* Noah > *Sent:* Thursday, July 23, 2026 10:03 AM > *To:* Mike Burns > *Cc:* Hytham El-Nakhal ; pdwg-chairs at afrinic.net; rpd > List > *Subject:* Re: [rpd] PDWG Co-Chairs communication regarding observed > behavioron AFPUB-2026-ASN-001-DRAFT02 > > > > > > On Wed, 22 Jul 2026, 8:53?pm Mike Burns, wrote: > > > > It?s not like Claude will be elected to any parliament. > > But this unique governance form for a global asset provides the > opportunity. > > I say, who cares if Claude is posting, or ChatGPT, or any other AI. > > I care that the AFRINIC rpd list is not turned into waste land of AI > powered trolls > > > > Give them a seat at the table and address their arguments. > > > > How many valid argument have been made in the past week or you mean a > single argument repeated through AI generated texts send by single persons > using multiple different email address or same group saying the same thing > over and over feeding the troll.... > > > > I have not experienced this behaviour on the ARIN or RIPE lists or even > APNIC for which we are both participants.. > > > > Why are you advocating for it in the AFRNIC service region....? > > > > Cheers, > > *./noah* > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Fri Jul 24 08:28:27 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Fri, 24 Jul 2026 10:28:27 +0200 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From mike at iptrading.com Fri Jul 24 11:47:24 2026 From: mike at iptrading.com (Mike Burns) Date: Fri, 24 Jul 2026 07:47:24 -0400 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: References: <033b01dd1adf$0f03a830$2d0af890$@iptrading.com> Message-ID: <19f93f39f54.4dc26520586380.5158783352232953991@iptrading.com> Hi Ben, I have seen and read all of these verbose messages and I have not commented on them directly While I might be, in your mind, trivializing the matter I think you are doing the opposite.? If this was the first foray into this usage of llms I think it is not going to benefit the users very much.? I don't find that they have changed many minds through the use of these tools and in fact have engendered a great deal of ire. So rather than overreact to this I think we should recognize it, acknowledge it , let the posters know that these posts are not effective and wait to see if natural incentives and disincentives change things before moving towards filtering or gatekeeping the list members. I have been very careful to differentiate abuse of the list from use of llms. Regards, Mike ---- On Thu, 23 Jul 2026 23:21:05 -0400 ben.roberts at afrinic.net wrote ---- Mike,You are trivialising the issue as a mere AI content problem. If it were just a case that some people are using AI writing tools then we would not be having this debate.? What we have seen is a co-ordinated Astroturfing attack of multiple anonymous gmails, bombarding the list with near identical yet largely meaningless essays all backing each other up. There may have been humans with keyboards sitting owning the gmails, but I?ve seen no evidence of ?proof of life? behind the accounts. Not even basic pleasantries (e.g. ?hello how are you?) or variation from the monotonic robot style. If it looks like an AI robot, quacks like an AI robot, then guess what, 9 times out of 10 it?s an AI robot. ? So it?s entirely very probable that they are just AI agent robots running on Openclaw instances that are fully in control of the Gmail accounts. Or it could just be one Openclaw controlling multiple Gmails, which would explain the ?hive mind? like co-ordinated and recycled paragraphs that are word for word recycled by member accounts of the collective. The ?community? for policy development is supposed to be a community of humans. The known identifiable humans in the collective seem to have concencus that none of us have a problem with other known humans using AI tools to assist their writing.? It will be very easy to modify the CoC to clarify that list membership is restricted to real old fashioned humans sitting with computer gadgets that they use to post the list, while excluding autonomous computer devices running their own writing/posting programs in absence of human creativity.? Kind regards Ben Sent from my iPhone On 23 Jul 2026, at 22:09, Mike Burns via RPD < mailto:rpd at afrinic.net > wrote: ? Hi Noah, ? Yes you are telling everybody that you have had enough of it. Fair enough. ? Yes, I am seeing no issue using AI unless it is used at cross-purposes of the list. I don?t think the use of AI in this context has reached that level, and also I don?t think it has been very effective. ? I think in the future AI will write more effective messages to the list, with or without human intervention. I will read those effective messages and argue against, or accept the arguments made. ? Regards, Mike ? ? ? ? From: Noah < mailto:noah at neo.co.tz > Sent: Thursday, July 23, 2026 1:41 PM To: Mike Burns < mailto:mike at iptrading.com > Cc: Hytham El-Nakhal < mailto:hytham at tra.gov.eg >; mailto:pdwg-chairs at afrinic.net ; rpd List < mailto:rpd at afrinic.net > Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 ? I did not say you commented on as-set issue.. ? The co-chair initiated this thread per subjectline which is related to hierarchical names for new as-set draft policy AFPUB-2026-ASN-001-DRAFT02. ? The co-chair openning statement read... in quote ? "The mailing list has recently been flooded with multiple emails stating either the same duplicate objections or consistent pushbacks to every post, some of them with subject line containing ?Digest?." ? The above is an outcome of folks outsourcing their thinking to AI and endlessly trolling using multiple emails and sockpuppets to bombard the rpd list. ? You are talking about usage of AI and seeing no issue with it. ? I am telling you I have had enough of it. ? Cheers, ./noah ? ? ? On Thu, 23 Jul 2026, 8:29?pm Mike Burns, < mailto:mike at iptrading.com > wrote: Hi Noah, ? I have made no comments on the AS-SET issue and tried to create a separate discussion thread for AI. ? Regards, Mike ? ? From: Noah < mailto:noah at neo.co.tz > Sent: Thursday, July 23, 2026 1:26 PM To: Mike Burns < mailto:mike at iptrading.com > Cc: Hytham El-Nakhal < mailto:hytham at tra.gov.eg >; mailto:pdwg-chairs at afrinic.net ; rpd List < mailto:rpd at afrinic.net > Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 ? Hi Mike ? What AI generated arguments will possibly change the facts that as-set collision is an issue. ? Havent we already documented the fact that as-set names collide across IRR databases and AI/Claude have nothing to do with this fact. ? When merging across IRR databases, havent we ack that collisions have resulted in ambiguity, empty or conflicting objects that cause tools to return incorrect or empty filter data. How is this AI/Claude problem?? ? Havent other RIR implemented, hierarchical naming, some through policy others through operational implementations to bind new as-set to a specific ASN holder. Did they consult AI/Claude while at it? ? Havent folks agreed that going forward we fix the issue at the moment of creation of new as-sets the only point at which an authoritative registry can prevent new instances of collision problem. I dont see how this is AI/claude concern nor how AI will be involved in technically fixing the problem even those outsourcing their thinking to claude to oppose what we want to fix wont be on the ground to fix the issue.? ? Cheers, ./noah ? ? ? On Thu, 23 Jul 2026, 5:50?pm Mike Burns, < mailto:mike at iptrading.com > wrote: Hi Noah, ? I have made it clear from the outset that list swamping or use of AI to generate duplicative, though reworded objections is grounds for moderation. That issue, which I was at pains to separate from the use of AI, continues to be conflated with the simple use of AI. ? That brings me to ad hominem, which is the basis of my belief and which you have failed in your reply. ? Ad hominem means that the speaker of an argument is of no importance when considering the argument. ? When you ask my for my motive, you breach that. ? Regards, ? Mike ? ? From: Noah < mailto:noah at neo.co.tz > Sent: Thursday, July 23, 2026 10:03 AM To: Mike Burns < mailto:mike at iptrading.com > Cc: Hytham El-Nakhal < mailto:hytham at tra.gov.eg >; mailto:pdwg-chairs at afrinic.net ; rpd List < mailto:rpd at afrinic.net > Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 ? ? On Wed, 22 Jul 2026, 8:53?pm Mike Burns, < mailto:mike at iptrading.com > wrote: ? It?s not like Claude will be elected to any parliament. But this unique governance form for a global asset provides the opportunity. I say, who cares if Claude is posting, or ChatGPT, or any other AI. I care that the AFRINIC rpd list is not turned into waste land of AI powered trolls ? Give them a seat at the table and address their arguments. ? How many valid argument have been made in the past week or you mean a single argument repeated through AI generated texts send by single persons using multiple different email address or same group saying the same thing over and over feeding the troll.... ? I have not experienced this behaviour on the ARIN or RIPE lists or even APNIC for which we are both participants.. ? Why are you advocating for it in the AFRNIC service region....? ? Cheers, ./noah ? _______________________________________________ RPD mailing list mailto:RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.medoye at gmail.com Fri Jul 24 12:43:34 2026 From: daniel.medoye at gmail.com (Taye Medoye) Date: Fri, 24 Jul 2026 14:43:34 +0200 Subject: [rpd] Subject: PDWG Co-Chairs communication regarding observed behavior on AFPUB-2026-ASN-001-DRAFT02 Message-ID: Dear colleagues, Thank you, Mike and Ben. I agree with Lu?s central point that the discussion risks focusing on the wrong unit of analysis. The relevant question is not whether a contribution was drafted by a person, assisted by an LLM, or produced through some degree of automation. The relevant question is whether it presents a distinct, relevant, and evidence-based argument. If a message is repetitive, irrelevant, unsupported, or part of excessive list traffic, that conduct should be addressed directly. The drafting tool should not become a substitute for assessing the actual quality and effect of the contribution. Ben is right that flooding can make a mailing list unusable and discourage participation. However, describing the activity as a coordinated campaign by automated bots requires evidence. We should not turn a reasonable concern about volume into a broader presumption against AI-assisted participation. Mike?s distinction between the use of LLMs and abuse of the list is therefore important, although I would go further: rather than relying only on informal incentives, we should consider improving the structure through which arguments are received and evaluated. For example, disputed policies or clauses could be presented in a shared interface, with arguments for and against them organised clearly. AI could be used to summarise the discussion, group substantially similar submissions, identify genuinely new arguments, and connect claims to supporting evidence. Contributors would remain free to submit arguments, while classifications and summaries should be visible, explainable, and open to appeal. That would address repetition and volume without excluding participants merely because of the tools they use. There is also a broader governance concern. A process does not remain genuinely open merely because anyone may technically join a mailing list. Over time, repeated participation can produce a small, self-selecting group that controls the accepted language, procedures, and boundaries of participation. When procedural familiarity is treated as substantive authority, openness becomes more symbolic than real. This is precisely why moderation systems must be transparent, contestable, and focused on the merit of arguments rather than the identity, style, or tools of the contributor. The practical objective should therefore be to improve signal, reduce duplication, and preserve meaningful participation. We can achieve that through content-based standards, transparent moderation, and better tools for organising debate. Filtering or gatekeeping people according to whether they use AI would address the wrong problem and risk narrowing, rather than protecting, the bottom-up character of the community. Kind regards, Taye. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Fri Jul 24 12:45:17 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Fri, 24 Jul 2026 14:45:17 +0200 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavior on AFPUB-2026-ASN-001-DRAFT02 Message-ID: Dear Ben, Thank you for your clarification. I think there is an important distinction between using AI to help draft a message and using automation to flood a mailing list. The issue, in my view, is not AI itself, but the conduct. If someone is repeatedly posting the same or slightly reworded messages, that should be addressed regardless of how those messages were written. At the same time, I believe we should be careful not to assume coordination or automation without clear evidence. If there are concerns, it is only fair that the people involved have an opportunity to respond before conclusions are reached. Going forward, I think it would help to have clearer guidance on acceptable posting behaviour. That would make moderation more transparent and consistent, while still allowing people to use new tools responsibly. The goal should be to keep the mailing list useful and focused on technical discussions, without discouraging genuine participation simply because someone used AI to organise or improve their thoughts. Kind regards, Fundiswa Nadia Maseko -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Fri Jul 24 12:52:23 2026 From: mike at iptrading.com (Mike Burns) Date: Fri, 24 Jul 2026 08:52:23 -0400 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: References: Message-ID: <03d501dd1b6b$46002c50$d20084f0$@iptrading.com> How come you guys never include the previous post in your replies? It seems fairly consistent and is unhelpful in my view, especially with top-posting. I think we may have reached a workable d?tente, with LLMs reducing posting volume and the list not disregarding the arguments they make. No side has the incentive to destroy the workability of the list. Regards, Mike From: Fundiswa Nadia Maseko Sent: Friday, July 24, 2026 8:45 AM To: rpd at afrinic.net Cc: pdwg-chairs at afrinic.net Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 Dear Ben, Thank you for your clarification. I think there is an important distinction between using AI to help draft a message and using automation to flood a mailing list. The issue, in my view, is not AI itself, but the conduct. If someone is repeatedly posting the same or slightly reworded messages, that should be addressed regardless of how those messages were written. At the same time, I believe we should be careful not to assume coordination or automation without clear evidence. If there are concerns, it is only fair that the people involved have an opportunity to respond before conclusions are reached. Going forward, I think it would help to have clearer guidance on acceptable posting behaviour. That would make moderation more transparent and consistent, while still allowing people to use new tools responsibly. The goal should be to keep the mailing list useful and focused on technical discussions, without discouraging genuine participation simply because someone used AI to organise or improve their thoughts. Kind regards, Fundiswa Nadia Maseko -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonjabulosphilile at gmail.com Fri Jul 24 12:58:40 2026 From: nonjabulosphilile at gmail.com (Nonjabulo Sphilile) Date: Fri, 24 Jul 2026 14:58:40 +0200 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavior on AFPUB-2026-ASN-001-DRAFT02 Message-ID: Dear colleagues, Thank you, Mike and Ben. I think both of you identify important parts of the problem. Ben is right that the effect on the mailing list matters. Regardless of whether the messages were written manually, drafted with AI, or fully automated, excessive posting can overwhelm members, reduce meaningful participation, and make the list less useful. That impact should not be dismissed. At the same time, Mike?s distinction between the use of LLMs and the abuse of the mailing list is essential. We should regulate harmful conduct, not the technology itself. We should also avoid treating a coordinated automated campaign as an established fact unless there is sufficient evidence to support that conclusion. A measured and proportionate response would be to begin with the least restrictive intervention: acknowledge the problem, communicate clearly to the posters that the volume and style of their contributions have been counterproductive, and allow the community?s natural incentives and feedback to influence future behaviour. Mentorship and guidance should come before filtering, exclusion, or other strict measures, particularly where the existing rules may not have clearly addressed this kind of activity. If the behaviour continues after clear notice, then reasonable safeguards such as posting limits, moderation procedures, or updated Code of Conduct provisions may become appropriate. Any such measures should be transparent, consistently applied, and developed through an open process rather than introduced as a reaction to a particular group or tool. The objective should be to preserve an open and useful forum while ensuring accountability. That requires us to distinguish evidence from suspicion, impact from intent, and responsible AI use from conduct that genuinely disrupts the community. Kind regards, Nonjabulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Fri Jul 24 13:13:04 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Fri, 24 Jul 2026 13:13:04 +0000 Subject: [rpd] RPD Digest, Vol 222, Issue 197 In-Reply-To: References: Message-ID: Dear colleagues, Mike raises a fair point about including the previous message when replying. However, I was one of the people who only realised later that using the ?Reply all? function helps preserve the recipients and maintain greater consistency across the discussion. With several parallel threads covering similar issues, it is also quite easy to lose track of which argument is being answered and where the conversation has moved. That may explain some of the inconsistent reply practices, even though it does not make them any less frustrating for readers. Clearer guidance on quoting the relevant part of the previous message, keeping the subject line consistent, and consolidating related arguments would probably help everyone, whether or not they use an LLM. The d?tente Mike describes seems sensible: reduce unnecessary posting volume, while continuing to assess contributions according to their relevance, distinctiveness, and supporting evidence rather than the tool used to draft them. As Seun has previously emphasised the importance of mentorship, perhaps mentorship could also be useful here. Some participants may simply need guidance on mailing-list conventions, reply structure, and how to engage effectively without overwhelming the discussion. Who knows, a little guidance may prove more productive than immediately assuming bad faith or moving towards stricter controls. Regards, Tshepo ________________________________ From: rpd-request at afrinic.net Sent: Friday, 24 July 2026 14:52:39 To: rpd at afrinic.net Subject: RPD Digest, Vol 222, Issue 197 Send RPD mailing list submissions to rpd at afrinic.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.afrinic.net/mailman/listinfo/rpd or, via email, send a message with subject or body 'help' to rpd-request at afrinic.net You can reach the person managing the list at rpd-owner at afrinic.net When replying, please edit your Subject line so it is more specific than "Re: Contents of RPD digest..." Today's Topics: 1. Subject: PDWG Co-Chairs communication regarding observed behavior on AFPUB-2026-ASN-001-DRAFT02 (Taye Medoye) 2. Re: PDWG Co-Chairs communication regarding observed behavior on AFPUB-2026-ASN-001-DRAFT02 (Fundiswa Nadia Maseko) 3. Re: PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 (Mike Burns) ---------------------------------------------------------------------- Message: 1 Date: Fri, 24 Jul 2026 14:43:34 +0200 From: Taye Medoye To: rpd at afrinic.net Cc: pdwg-chairs at afrinic.net Subject: [rpd] Subject: PDWG Co-Chairs communication regarding observed behavior on AFPUB-2026-ASN-001-DRAFT02 Message-ID: Content-Type: text/plain; charset="utf-8" Dear colleagues, Thank you, Mike and Ben. I agree with Lu?s central point that the discussion risks focusing on the wrong unit of analysis. The relevant question is not whether a contribution was drafted by a person, assisted by an LLM, or produced through some degree of automation. The relevant question is whether it presents a distinct, relevant, and evidence-based argument. If a message is repetitive, irrelevant, unsupported, or part of excessive list traffic, that conduct should be addressed directly. The drafting tool should not become a substitute for assessing the actual quality and effect of the contribution. Ben is right that flooding can make a mailing list unusable and discourage participation. However, describing the activity as a coordinated campaign by automated bots requires evidence. We should not turn a reasonable concern about volume into a broader presumption against AI-assisted participation. Mike?s distinction between the use of LLMs and abuse of the list is therefore important, although I would go further: rather than relying only on informal incentives, we should consider improving the structure through which arguments are received and evaluated. For example, disputed policies or clauses could be presented in a shared interface, with arguments for and against them organised clearly. AI could be used to summarise the discussion, group substantially similar submissions, identify genuinely new arguments, and connect claims to supporting evidence. Contributors would remain free to submit arguments, while classifications and summaries should be visible, explainable, and open to appeal. That would address repetition and volume without excluding participants merely because of the tools they use. There is also a broader governance concern. A process does not remain genuinely open merely because anyone may technically join a mailing list. Over time, repeated participation can produce a small, self-selecting group that controls the accepted language, procedures, and boundaries of participation. When procedural familiarity is treated as substantive authority, openness becomes more symbolic than real. This is precisely why moderation systems must be transparent, contestable, and focused on the merit of arguments rather than the identity, style, or tools of the contributor. The practical objective should therefore be to improve signal, reduce duplication, and preserve meaningful participation. We can achieve that through content-based standards, transparent moderation, and better tools for organising debate. Filtering or gatekeeping people according to whether they use AI would address the wrong problem and risk narrowing, rather than protecting, the bottom-up character of the community. Kind regards, Taye. -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Fri, 24 Jul 2026 14:45:17 +0200 From: Fundiswa Nadia Maseko To: rpd at afrinic.net Cc: pdwg-chairs at afrinic.net Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavior on AFPUB-2026-ASN-001-DRAFT02 Message-ID: Content-Type: text/plain; charset="utf-8" Dear Ben, Thank you for your clarification. I think there is an important distinction between using AI to help draft a message and using automation to flood a mailing list. The issue, in my view, is not AI itself, but the conduct. If someone is repeatedly posting the same or slightly reworded messages, that should be addressed regardless of how those messages were written. At the same time, I believe we should be careful not to assume coordination or automation without clear evidence. If there are concerns, it is only fair that the people involved have an opportunity to respond before conclusions are reached. Going forward, I think it would help to have clearer guidance on acceptable posting behaviour. That would make moderation more transparent and consistent, while still allowing people to use new tools responsibly. The goal should be to keep the mailing list useful and focused on technical discussions, without discouraging genuine participation simply because someone used AI to organise or improve their thoughts. Kind regards, Fundiswa Nadia Maseko -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Fri, 24 Jul 2026 08:52:23 -0400 From: "Mike Burns" To: "'Fundiswa Nadia Maseko'" , Cc: pdwg-chairs at afrinic.net Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 Message-ID: <03d501dd1b6b$46002c50$d20084f0$@iptrading.com> Content-Type: text/plain; charset="utf-8" How come you guys never include the previous post in your replies? It seems fairly consistent and is unhelpful in my view, especially with top-posting. I think we may have reached a workable d?tente, with LLMs reducing posting volume and the list not disregarding the arguments they make. No side has the incentive to destroy the workability of the list. Regards, Mike From: Fundiswa Nadia Maseko Sent: Friday, July 24, 2026 8:45 AM To: rpd at afrinic.net Cc: pdwg-chairs at afrinic.net Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 Dear Ben, Thank you for your clarification. I think there is an important distinction between using AI to help draft a message and using automation to flood a mailing list. The issue, in my view, is not AI itself, but the conduct. If someone is repeatedly posting the same or slightly reworded messages, that should be addressed regardless of how those messages were written. At the same time, I believe we should be careful not to assume coordination or automation without clear evidence. If there are concerns, it is only fair that the people involved have an opportunity to respond before conclusions are reached. Going forward, I think it would help to have clearer guidance on acceptable posting behaviour. That would make moderation more transparent and consistent, while still allowing people to use new tools responsibly. The goal should be to keep the mailing list useful and focused on technical discussions, without discouraging genuine participation simply because someone used AI to organise or improve their thoughts. Kind regards, Fundiswa Nadia Maseko -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Subject: Digest Footer _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd ------------------------------ End of RPD Digest, Vol 222, Issue 197 ************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Fri Jul 24 14:43:04 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Fri, 24 Jul 2026 16:43:04 +0200 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: <03d501dd1b6b$46002c50$d20084f0$@iptrading.com> References: <03d501dd1b6b$46002c50$d20084f0$@iptrading.com> Message-ID: Dear Mike, Thanks for pointing that out. You're right that including the previous message makes it much easier to follow the discussion, especially when several people are replying at the same time. I'll make sure I keep the quoted text in future replies. I also think we're getting to a more balanced position. Whether someone uses AI or not shouldn't be the main issue. What really matters is whether their contribution is relevant, adds something new, and helps move the discussion forward. In the end, the same expectations should apply to everyone. If a contribution is repetitive or doesn't add value, it should be treated the same regardless of how it was drafted. Kind regards, Fundiswa Nadia Maseko On Fri, 24 Jul 2026, 14:52 Mike Burns, wrote: > How come you guys never include the previous post in your replies? > > It seems fairly consistent and is unhelpful in my view, especially with > top-posting. > > > > I think we may have reached a workable d?tente, with LLMs reducing posting > volume and the list not disregarding the arguments they make. > > No side has the incentive to destroy the workability of the list. > > > > Regards, > Mike > > > > > > *From:* Fundiswa Nadia Maseko > *Sent:* Friday, July 24, 2026 8:45 AM > *To:* rpd at afrinic.net > *Cc:* pdwg-chairs at afrinic.net > *Subject:* Re: [rpd] PDWG Co-Chairs communication regarding observed > behavioron AFPUB-2026-ASN-001-DRAFT02 > > > > Dear Ben, > > > > Thank you for your clarification. > > > > I think there is an important distinction between using AI to help draft a > message and using automation to flood a mailing list. The issue, in my > view, is not AI itself, but the conduct. If someone is repeatedly posting > the same or slightly reworded messages, that should be addressed regardless > of how those messages were written. > > > > At the same time, I believe we should be careful not to assume > coordination or automation without clear evidence. If there are concerns, > it is only fair that the people involved have an opportunity to respond > before conclusions are reached. > > > > Going forward, I think it would help to have clearer guidance on > acceptable posting behaviour. That would make moderation more transparent > and consistent, while still allowing people to use new tools responsibly. > > > > The goal should be to keep the mailing list useful and focused on > technical discussions, without discouraging genuine participation simply > because someone used AI to organise or improve their thoughts. > > > > > > Kind regards, > > Fundiswa Nadia Maseko > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hytham at tra.gov.eg Fri Jul 24 15:16:33 2026 From: hytham at tra.gov.eg (Hytham El-Nakhal) Date: Fri, 24 Jul 2026 15:16:33 +0000 Subject: [rpd] [External] Re: [Pdwg-chairs] PDWG Co-Chairs communication regarding observed behavior on AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: References: , Message-ID: <1784906151892.20504@tra.gov.eg> Dear PDWG, Thank you to everyone participating in the discussions. I want to clarify for all participants that AFRINIC as Regional Internet Registry, set up the RPD Mailing List as one arm of its bottom-up self-governance structure for setting regional policies for IP resources. The list allows discussions on such policies for managing and distribution of IP number resources in the AFRINIC service region. These policies eventually impact Resource Members in the region and the latter are also expected to participate actively in policy development. Those contributing on the mailing list also continue to do so during the Public Policy Meetings (PPM) during which rough consensus is assessed on the proposals being discussed. During these PPM meetings, the AFRINIC PDWG also gets to meet and match faces to email addresses. The PDWG is expected to continuously grow as AFRINIC encourages its stakeholders to join in the policy discussions and onboarding of those interested to the PDP is done via webinars that are also publicly available. The individuals participating are encouraged to stay on-topic and contribute positively to the discussions , even when they disagree with the proposals. In respect of the diversity and compliance with the use of English as language, the individuals may have appropriate tools, such as AI, for personal summarization or proofreading their contributions to the policy discussions. However, in the past week as I said before, I have observed that some individuals in the community when opposing policy proposals have used a concerted approach and possibly AI tool to create a systematic, repetitive, hollow, and at times technically irrelevant exchange on one of the three policy proposals that have reached Last Call. In 2020, this was also experienced on a technical policy but at a lesser cadence. I therefore request the posters on this list to be mindful of the time, effort and intellect of those individuals who have either brought forward a policy proposal that addresses a problem that is being faced , or contributed to the discussions (support or oppose) or been following the discussions through the emails they receive. Your contribution remains valuable as long as it adheres to the Code of Conduct, focus on the policy proposals and objections if any should be justified (not repeated without rationale justification). The RPD mailing list should not be used as a ground for other debates other than the policies discussion. If the PDWG believes that creating a new Mail-List to discuss topics not directly related to the policies under discussion is more beneficial for all to let the rpd ML be as usual focused only on the policies discussions, let Policy Liaison Team at AFRINIC know. Regards, Haitham el Nakhal PDWG Co-Chairs __________________________________________________________________________ From: Ben Roberts - AfriNIC via Pdwg-chairs Sent: Friday, July 24, 2026 11:28 AM To: Lu Heng Cc: pdwg-chairs at afrinic.net; rpd List; Mike Burns Subject: [External] Re: [Pdwg-chairs] [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 I think we are broadly in agreement Lu, Using AI tools for drafting is something that humans can do and nobody here seems to object to that. Myself and Hendrik and others have freely acknowledged using Claude to analyse the mailing list content also. But what has occurred here has been a co-ordinated list flooding campaign, possibly (highly likely) by fully automated AI bots. It?s filled a lot of inboxes and really annoyed a lot of people, and caused others to switch off just unable to digest such huge volumes of slop. Kind regards Ben Sent from my iPhone On 24 Jul 2026, at 10:01, Lu Heng wrote: ? The discussion is focused on the wrong unit. What matters is not whether a message was drafted by a human or an AI, but whether it contributes a distinct, relevant, and evidence-based argument. The correct moderation targets are duplication, flooding, irrelevance, and unsupported claims?not the drafting tool. The practical solution is straightforward: place the policy, or each disputed clause, in the centre of a web interface; display the arguments for and against it on either side; and use AI to maintain a continuous summary, cluster repeated arguments, and identify genuinely new ones. Anyone should be free to submit a new argument or supporting evidence, while every AI classification remains visible and appealable. A basic prototype could be built in a day. Whether humans should retain a monopoly over argumentation is a separate question. They have no principled claim to such a monopoly once machines can competently compare, organize, and summarize arguments at scale. More importantly, a human-only process does not preserve openness. Repeated interaction tends to produce a small, self-selecting clique that determines whose language, identity, and participation count, excludes outsiders, and eventually becomes insular and cult-like. This is mandate laundering: control over procedure is converted into an illegitimate claim of substantive authority. Once that happens, formal openness ceases to provide legitimacy. The RIR system may continue to exist in name, but its bottom-up model will have effectively ended. -- Kind regards. Lu On Fri, Jul 24, 2026 at 12:24 Ben Roberts - AfriNIC via RPD > wrote: Mike, You are trivialising the issue as a mere AI content problem. If it were just a case that some people are using AI writing tools then we would not be having this debate. What we have seen is a co-ordinated Astroturfing attack of multiple anonymous gmails, bombarding the list with near identical yet largely meaningless essays all backing each other up. There may have been humans with keyboards sitting owning the gmails, but I?ve seen no evidence of ?proof of life? behind the accounts. Not even basic pleasantries (e.g. ?hello how are you?) or variation from the monotonic robot style. If it looks like an AI robot, quacks like an AI robot, then guess what, 9 times out of 10 it?s an AI robot. So it?s entirely very probable that they are just AI agent robots running on Openclaw instances that are fully in control of the Gmail accounts. Or it could just be one Openclaw controlling multiple Gmails, which would explain the ?hive mind? like co-ordinated and recycled paragraphs that are word for word recycled by member accounts of the collective. The ?community? for policy development is supposed to be a community of humans. The known identifiable humans in the collective seem to have concencus that none of us have a problem with other known humans using AI tools to assist their writing. It will be very easy to modify the CoC to clarify that list membership is restricted to real old fashioned humans sitting with computer gadgets that they use to post the list, while excluding autonomous computer devices running their own writing/posting programs in absence of human creativity. Kind regards Ben Sent from my iPhone On 23 Jul 2026, at 22:09, Mike Burns via RPD > wrote: ? Hi Noah, Yes you are telling everybody that you have had enough of it. Fair enough. Yes, I am seeing no issue using AI unless it is used at cross-purposes of the list. I don?t think the use of AI in this context has reached that level, and also I don?t think it has been very effective. I think in the future AI will write more effective messages to the list, with or without human intervention. I will read those effective messages and argue against, or accept the arguments made. Regards, Mike From: Noah > Sent: Thursday, July 23, 2026 1:41 PM To: Mike Burns > Cc: Hytham El-Nakhal >; pdwg-chairs at afrinic.net; rpd List > Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 I did not say you commented on as-set issue.. The co-chair initiated this thread per subjectline which is related to hierarchical names for new as-set draft policy AFPUB-2026-ASN-001-DRAFT02. The co-chair openning statement read... in quote "The mailing list has recently been flooded with multiple emails stating either the same duplicate objections or consistent pushbacks to every post, some of them with subject line containing ?Digest?." The above is an outcome of folks outsourcing their thinking to AI and endlessly trolling using multiple emails and sockpuppets to bombard the rpd list. You are talking about usage of AI and seeing no issue with it. I am telling you I have had enough of it. Cheers, ./noah On Thu, 23 Jul 2026, 8:29?pm Mike Burns, > wrote: Hi Noah, I have made no comments on the AS-SET issue and tried to create a separate discussion thread for AI. Regards, Mike From: Noah > Sent: Thursday, July 23, 2026 1:26 PM To: Mike Burns > Cc: Hytham El-Nakhal >; pdwg-chairs at afrinic.net; rpd List > Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 Hi Mike What AI generated arguments will possibly change the facts that as-set collision is an issue. Havent we already documented the fact that as-set names collide across IRR databases and AI/Claude have nothing to do with this fact. When merging across IRR databases, havent we ack that collisions have resulted in ambiguity, empty or conflicting objects that cause tools to return incorrect or empty filter data. How is this AI/Claude problem? Havent other RIR implemented, hierarchical naming, some through policy others through operational implementations to bind new as-set to a specific ASN holder. Did they consult AI/Claude while at it? Havent folks agreed that going forward we fix the issue at the moment of creation of new as-sets the only point at which an authoritative registry can prevent new instances of collision problem. I dont see how this is AI/claude concern nor how AI will be involved in technically fixing the problem even those outsourcing their thinking to claude to oppose what we want to fix wont be on the ground to fix the issue. Cheers, ./noah On Thu, 23 Jul 2026, 5:50?pm Mike Burns, > wrote: Hi Noah, I have made it clear from the outset that list swamping or use of AI to generate duplicative, though reworded objections is grounds for moderation. That issue, which I was at pains to separate from the use of AI, continues to be conflated with the simple use of AI. That brings me to ad hominem, which is the basis of my belief and which you have failed in your reply. Ad hominem means that the speaker of an argument is of no importance when considering the argument. When you ask my for my motive, you breach that. Regards, Mike From: Noah > Sent: Thursday, July 23, 2026 10:03 AM To: Mike Burns > Cc: Hytham El-Nakhal >; pdwg-chairs at afrinic.net; rpd List > Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 On Wed, 22 Jul 2026, 8:53?pm Mike Burns, > wrote: It?s not like Claude will be elected to any parliament. But this unique governance form for a global asset provides the opportunity. I say, who cares if Claude is posting, or ChatGPT, or any other AI. I care that the AFRINIC rpd list is not turned into waste land of AI powered trolls Give them a seat at the table and address their arguments. How many valid argument have been made in the past week or you mean a single argument repeated through AI generated texts send by single persons using multiple different email address or same group saying the same thing over and over feeding the troll.... I have not experienced this behaviour on the ARIN or RIPE lists or even APNIC for which we are both participants.. Why are you advocating for it in the AFRNIC service region....? Cheers, ./noah _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd From hytham at tra.gov.eg Fri Jul 24 15:16:55 2026 From: hytham at tra.gov.eg (Hytham El-Nakhal) Date: Fri, 24 Jul 2026 15:16:55 +0000 Subject: [rpd] [External] Re: [Pdwg-chairs] PDWG Co-Chairs communication regarding observed behavior on AFPUB-2026-ASN-001-DRAFT02 Message-ID: <1784906151892.20504@tra.gov.eg> Dear PDWG, Thank you to everyone participating in the discussions. I want to clarify for all participants that AFRINIC as Regional Internet Registry, set up the RPD Mailing List as one arm of its bottom-up self-governance structure for setting regional policies for IP resources. The list allows discussions on such policies for managing and distribution of IP number resources in the AFRINIC service region. These policies eventually impact Resource Members in the region and the latter are also expected to participate actively in policy development. Those contributing on the mailing list also continue to do so during the Public Policy Meetings (PPM) during which rough consensus is assessed on the proposals being discussed. During these PPM meetings, the AFRINIC PDWG also gets to meet and match faces to email addresses. The PDWG is expected to continuously grow as AFRINIC encourages its stakeholders to join in the policy discussions and onboarding of those interested to the PDP is done via webinars that are also publicly available. The individuals participating are encouraged to stay on-topic and contribute positively to the discussions , even when they disagree with the proposals. In respect of the diversity and compliance with the use of English as language, the individuals may have appropriate tools, such as AI, for personal summarization or proofreading their contributions to the policy discussions. However, in the past week as I said before, I have observed that some individuals in the community when opposing policy proposals have used a concerted approach and possibly AI tool to create a systematic, repetitive, hollow, and at times technically irrelevant exchange on one of the three policy proposals that have reached Last Call. In 2020, this was also experienced on a technical policy but at a lesser cadence. I therefore request the posters on this list to be mindful of the time, effort and intellect of those individuals who have either brought forward a policy proposal that addresses a problem that is being faced , or contributed to the discussions (support or oppose) or been following the discussions through the emails they receive. Your contribution remains valuable as long as it adheres to the Code of Conduct, focus on the policy proposals and objections if any should be justified (not repeated without rationale justification). The RPD mailing list should not be used as a ground for other debates other than the policies discussion. If the PDWG believes that creating a new Mail-List to discuss topics not directly related to the policies under discussion is more beneficial for all to let the rpd ML be as usual focused only on the policies discussions, let Policy Liaison Team at AFRINIC know. Regards, Haitham el Nakhal PDWG Co-Chairs __________________________________________________________________________ From: Ben Roberts - AfriNIC via Pdwg-chairs Sent: Friday, July 24, 2026 11:28 AM To: Lu Heng Cc: pdwg-chairs at afrinic.net; rpd List; Mike Burns Subject: [External] Re: [Pdwg-chairs] [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 I think we are broadly in agreement Lu, Using AI tools for drafting is something that humans can do and nobody here seems to object to that. Myself and Hendrik and others have freely acknowledged using Claude to analyse the mailing list content also. But what has occurred here has been a co-ordinated list flooding campaign, possibly (highly likely) by fully automated AI bots. It?s filled a lot of inboxes and really annoyed a lot of people, and caused others to switch off just unable to digest such huge volumes of slop. Kind regards Ben Sent from my iPhone On 24 Jul 2026, at 10:01, Lu Heng wrote: ? The discussion is focused on the wrong unit. What matters is not whether a message was drafted by a human or an AI, but whether it contributes a distinct, relevant, and evidence-based argument. The correct moderation targets are duplication, flooding, irrelevance, and unsupported claims?not the drafting tool. The practical solution is straightforward: place the policy, or each disputed clause, in the centre of a web interface; display the arguments for and against it on either side; and use AI to maintain a continuous summary, cluster repeated arguments, and identify genuinely new ones. Anyone should be free to submit a new argument or supporting evidence, while every AI classification remains visible and appealable. A basic prototype could be built in a day. Whether humans should retain a monopoly over argumentation is a separate question. They have no principled claim to such a monopoly once machines can competently compare, organize, and summarize arguments at scale. More importantly, a human-only process does not preserve openness. Repeated interaction tends to produce a small, self-selecting clique that determines whose language, identity, and participation count, excludes outsiders, and eventually becomes insular and cult-like. This is mandate laundering: control over procedure is converted into an illegitimate claim of substantive authority. Once that happens, formal openness ceases to provide legitimacy. The RIR system may continue to exist in name, but its bottom-up model will have effectively ended. -- Kind regards. Lu On Fri, Jul 24, 2026 at 12:24 Ben Roberts - AfriNIC via RPD > wrote: Mike, You are trivialising the issue as a mere AI content problem. If it were just a case that some people are using AI writing tools then we would not be having this debate. What we have seen is a co-ordinated Astroturfing attack of multiple anonymous gmails, bombarding the list with near identical yet largely meaningless essays all backing each other up. There may have been humans with keyboards sitting owning the gmails, but I?ve seen no evidence of ?proof of life? behind the accounts. Not even basic pleasantries (e.g. ?hello how are you?) or variation from the monotonic robot style. If it looks like an AI robot, quacks like an AI robot, then guess what, 9 times out of 10 it?s an AI robot. So it?s entirely very probable that they are just AI agent robots running on Openclaw instances that are fully in control of the Gmail accounts. Or it could just be one Openclaw controlling multiple Gmails, which would explain the ?hive mind? like co-ordinated and recycled paragraphs that are word for word recycled by member accounts of the collective. The ?community? for policy development is supposed to be a community of humans. The known identifiable humans in the collective seem to have concencus that none of us have a problem with other known humans using AI tools to assist their writing. It will be very easy to modify the CoC to clarify that list membership is restricted to real old fashioned humans sitting with computer gadgets that they use to post the list, while excluding autonomous computer devices running their own writing/posting programs in absence of human creativity. Kind regards Ben Sent from my iPhone On 23 Jul 2026, at 22:09, Mike Burns via RPD > wrote: ? Hi Noah, Yes you are telling everybody that you have had enough of it. Fair enough. Yes, I am seeing no issue using AI unless it is used at cross-purposes of the list. I don?t think the use of AI in this context has reached that level, and also I don?t think it has been very effective. I think in the future AI will write more effective messages to the list, with or without human intervention. I will read those effective messages and argue against, or accept the arguments made. Regards, Mike From: Noah > Sent: Thursday, July 23, 2026 1:41 PM To: Mike Burns > Cc: Hytham El-Nakhal >; pdwg-chairs at afrinic.net; rpd List > Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 I did not say you commented on as-set issue.. The co-chair initiated this thread per subjectline which is related to hierarchical names for new as-set draft policy AFPUB-2026-ASN-001-DRAFT02. The co-chair openning statement read... in quote "The mailing list has recently been flooded with multiple emails stating either the same duplicate objections or consistent pushbacks to every post, some of them with subject line containing ?Digest?." The above is an outcome of folks outsourcing their thinking to AI and endlessly trolling using multiple emails and sockpuppets to bombard the rpd list. You are talking about usage of AI and seeing no issue with it. I am telling you I have had enough of it. Cheers, ./noah On Thu, 23 Jul 2026, 8:29?pm Mike Burns, > wrote: Hi Noah, I have made no comments on the AS-SET issue and tried to create a separate discussion thread for AI. Regards, Mike From: Noah > Sent: Thursday, July 23, 2026 1:26 PM To: Mike Burns > Cc: Hytham El-Nakhal >; pdwg-chairs at afrinic.net; rpd List > Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 Hi Mike What AI generated arguments will possibly change the facts that as-set collision is an issue. Havent we already documented the fact that as-set names collide across IRR databases and AI/Claude have nothing to do with this fact. When merging across IRR databases, havent we ack that collisions have resulted in ambiguity, empty or conflicting objects that cause tools to return incorrect or empty filter data. How is this AI/Claude problem? Havent other RIR implemented, hierarchical naming, some through policy others through operational implementations to bind new as-set to a specific ASN holder. Did they consult AI/Claude while at it? Havent folks agreed that going forward we fix the issue at the moment of creation of new as-sets the only point at which an authoritative registry can prevent new instances of collision problem. I dont see how this is AI/claude concern nor how AI will be involved in technically fixing the problem even those outsourcing their thinking to claude to oppose what we want to fix wont be on the ground to fix the issue. Cheers, ./noah On Thu, 23 Jul 2026, 5:50?pm Mike Burns, > wrote: Hi Noah, I have made it clear from the outset that list swamping or use of AI to generate duplicative, though reworded objections is grounds for moderation. That issue, which I was at pains to separate from the use of AI, continues to be conflated with the simple use of AI. That brings me to ad hominem, which is the basis of my belief and which you have failed in your reply. Ad hominem means that the speaker of an argument is of no importance when considering the argument. When you ask my for my motive, you breach that. Regards, Mike From: Noah > Sent: Thursday, July 23, 2026 10:03 AM To: Mike Burns > Cc: Hytham El-Nakhal >; pdwg-chairs at afrinic.net; rpd List > Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 On Wed, 22 Jul 2026, 8:53?pm Mike Burns, > wrote: It?s not like Claude will be elected to any parliament. But this unique governance form for a global asset provides the opportunity. I say, who cares if Claude is posting, or ChatGPT, or any other AI. I care that the AFRINIC rpd list is not turned into waste land of AI powered trolls Give them a seat at the table and address their arguments. How many valid argument have been made in the past week or you mean a single argument repeated through AI generated texts send by single persons using multiple different email address or same group saying the same thing over and over feeding the troll.... I have not experienced this behaviour on the ARIN or RIPE lists or even APNIC for which we are both participants.. Why are you advocating for it in the AFRNIC service region....? Cheers, ./noah _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd From hytham at tra.gov.eg Fri Jul 24 15:21:32 2026 From: hytham at tra.gov.eg (Hytham El-Nakhal) Date: Fri, 24 Jul 2026 15:21:32 +0000 Subject: [rpd] [External] Re: [Pdwg-chairs] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: References: , Message-ID: <1784906472604.74695@tra.gov.eg> Dear PDWG, Thank you to everyone participating in the discussions. I want to clarify for all participants that AFRINIC as Regional Internet Registry, set up the RPD Mailing List as one arm of its bottom-up self-governance structure for setting regional policies for IP resources. The list allows discussions on such policies for managing and distribution of IP number resources in the AFRINIC service region. These policies eventually impact Resource Members in the region and the latter are also expected to participate actively in policy development. Those contributing on the mailing list also continue to do so during the Public Policy Meetings (PPM) during which rough consensus is assessed on the proposals being discussed. During these PPM meetings, the AFRINIC PDWG also gets to meet and match faces to email addresses. The PDWG is expected to continuously grow as AFRINIC encourages its stakeholders to join in the policy discussions and onboarding of those interested to the PDP is done via webinars that are also publicly available. The individuals participating are encouraged to stay on-topic and contribute positively to the discussions , even when they disagree with the proposals. In respect of the diversity and compliance with the use of English as language, the individuals may have appropriate tools, such as AI, for personal summarization or proofreading their contributions to the policy discussions. However, in the past week as I said before, I have observed that some individuals in the community when opposing policy proposals have used a concerted approach and possibly AI tool to create a systematic, repetitive, hollow, and at times technically irrelevant exchange on one of the three policy proposals that have reached Last Call. In 2020, this was also experienced on a technical policy but at a lesser cadence. I therefore request the posters on this list to be mindful of the time, effort and intellect of those individuals who have either brought forward a policy proposal that addresses a problem that is being faced , or contributed to the discussions (support or oppose) or been following the discussions through the emails they receive. Your contribution remains valuable as long as it adheres to the Code of Conduct, focus on the policy proposals and objections if any should be justified (not repeated without rationale justification). The RPD mailing list should not be used as a ground for other debates other than the policies discussion. If the PDWG believes that creating a new Mail-List to discuss topics not directly related to the policies under discussion is more beneficial for all to let the rpd ML be as usual focused only on the policies discussions, let Policy Liaison Team at AFRINIC know. Regards, Haitham el Nakhal PDWG Co-Chairs ________________________________ From: Ben Roberts - AfriNIC via Pdwg-chairs Sent: Friday, July 24, 2026 11:28 AM To: Lu Heng Cc: pdwg-chairs at afrinic.net; rpd List; Mike Burns Subject: [External] Re: [Pdwg-chairs] [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 I think we are broadly in agreement Lu, Using AI tools for drafting is something that humans can do and nobody here seems to object to that. Myself and Hendrik and others have freely acknowledged using Claude to analyse the mailing list content also. But what has occurred here has been a co-ordinated list flooding campaign, possibly (highly likely) by fully automated AI bots. It?s filled a lot of inboxes and really annoyed a lot of people, and caused others to switch off just unable to digest such huge volumes of slop. Kind regards Ben Sent from my iPhone On 24 Jul 2026, at 10:01, Lu Heng wrote: ? The discussion is focused on the wrong unit. What matters is not whether a message was drafted by a human or an AI, but whether it contributes a distinct, relevant, and evidence-based argument. The correct moderation targets are duplication, flooding, irrelevance, and unsupported claims?not the drafting tool. The practical solution is straightforward: place the policy, or each disputed clause, in the centre of a web interface; display the arguments for and against it on either side; and use AI to maintain a continuous summary, cluster repeated arguments, and identify genuinely new ones. Anyone should be free to submit a new argument or supporting evidence, while every AI classification remains visible and appealable. A basic prototype could be built in a day. Whether humans should retain a monopoly over argumentation is a separate question. They have no principled claim to such a monopoly once machines can competently compare, organize, and summarize arguments at scale. More importantly, a human-only process does not preserve openness. Repeated interaction tends to produce a small, self-selecting clique that determines whose language, identity, and participation count, excludes outsiders, and eventually becomes insular and cult-like. This is mandate laundering: control over procedure is converted into an illegitimate claim of substantive authority. Once that happens, formal openness ceases to provide legitimacy. The RIR system may continue to exist in name, but its bottom-up model will have effectively ended. -- Kind regards. Lu On Fri, Jul 24, 2026 at 12:24 Ben Roberts - AfriNIC via RPD > wrote: Mike, You are trivialising the issue as a mere AI content problem. If it were just a case that some people are using AI writing tools then we would not be having this debate. What we have seen is a co-ordinated Astroturfing attack of multiple anonymous gmails, bombarding the list with near identical yet largely meaningless essays all backing each other up. There may have been humans with keyboards sitting owning the gmails, but I?ve seen no evidence of ?proof of life? behind the accounts. Not even basic pleasantries (e.g. ?hello how are you?) or variation from the monotonic robot style. If it looks like an AI robot, quacks like an AI robot, then guess what, 9 times out of 10 it?s an AI robot. So it?s entirely very probable that they are just AI agent robots running on Openclaw instances that are fully in control of the Gmail accounts. Or it could just be one Openclaw controlling multiple Gmails, which would explain the ?hive mind? like co-ordinated and recycled paragraphs that are word for word recycled by member accounts of the collective. The ?community? for policy development is supposed to be a community of humans. The known identifiable humans in the collective seem to have concencus that none of us have a problem with other known humans using AI tools to assist their writing. It will be very easy to modify the CoC to clarify that list membership is restricted to real old fashioned humans sitting with computer gadgets that they use to post the list, while excluding autonomous computer devices running their own writing/posting programs in absence of human creativity. Kind regards Ben Sent from my iPhone On 23 Jul 2026, at 22:09, Mike Burns via RPD > wrote: ? Hi Noah, Yes you are telling everybody that you have had enough of it. Fair enough. Yes, I am seeing no issue using AI unless it is used at cross-purposes of the list. I don?t think the use of AI in this context has reached that level, and also I don?t think it has been very effective. I think in the future AI will write more effective messages to the list, with or without human intervention. I will read those effective messages and argue against, or accept the arguments made. Regards, Mike From: Noah > Sent: Thursday, July 23, 2026 1:41 PM To: Mike Burns > Cc: Hytham El-Nakhal >; pdwg-chairs at afrinic.net; rpd List > Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 I did not say you commented on as-set issue.. The co-chair initiated this thread per subjectline which is related to hierarchical names for new as-set draft policy AFPUB-2026-ASN-001-DRAFT02. The co-chair openning statement read... in quote "The mailing list has recently been flooded with multiple emails stating either the same duplicate objections or consistent pushbacks to every post, some of them with subject line containing ?Digest?." The above is an outcome of folks outsourcing their thinking to AI and endlessly trolling using multiple emails and sockpuppets to bombard the rpd list. You are talking about usage of AI and seeing no issue with it. I am telling you I have had enough of it. Cheers, ./noah On Thu, 23 Jul 2026, 8:29?pm Mike Burns, > wrote: Hi Noah, I have made no comments on the AS-SET issue and tried to create a separate discussion thread for AI. Regards, Mike From: Noah > Sent: Thursday, July 23, 2026 1:26 PM To: Mike Burns > Cc: Hytham El-Nakhal >; pdwg-chairs at afrinic.net; rpd List > Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 Hi Mike What AI generated arguments will possibly change the facts that as-set collision is an issue. Havent we already documented the fact that as-set names collide across IRR databases and AI/Claude have nothing to do with this fact. When merging across IRR databases, havent we ack that collisions have resulted in ambiguity, empty or conflicting objects that cause tools to return incorrect or empty filter data. How is this AI/Claude problem? Havent other RIR implemented, hierarchical naming, some through policy others through operational implementations to bind new as-set to a specific ASN holder. Did they consult AI/Claude while at it? Havent folks agreed that going forward we fix the issue at the moment of creation of new as-sets the only point at which an authoritative registry can prevent new instances of collision problem. I dont see how this is AI/claude concern nor how AI will be involved in technically fixing the problem even those outsourcing their thinking to claude to oppose what we want to fix wont be on the ground to fix the issue. Cheers, ./noah On Thu, 23 Jul 2026, 5:50?pm Mike Burns, > wrote: Hi Noah, I have made it clear from the outset that list swamping or use of AI to generate duplicative, though reworded objections is grounds for moderation. That issue, which I was at pains to separate from the use of AI, continues to be conflated with the simple use of AI. That brings me to ad hominem, which is the basis of my belief and which you have failed in your reply. Ad hominem means that the speaker of an argument is of no importance when considering the argument. When you ask my for my motive, you breach that. Regards, Mike From: Noah > Sent: Thursday, July 23, 2026 10:03 AM To: Mike Burns > Cc: Hytham El-Nakhal >; pdwg-chairs at afrinic.net; rpd List > Subject: Re: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 On Wed, 22 Jul 2026, 8:53?pm Mike Burns, > wrote: It?s not like Claude will be elected to any parliament. But this unique governance form for a global asset provides the opportunity. I say, who cares if Claude is posting, or ChatGPT, or any other AI. I care that the AFRINIC rpd list is not turned into waste land of AI powered trolls Give them a seat at the table and address their arguments. How many valid argument have been made in the past week or you mean a single argument repeated through AI generated texts send by single persons using multiple different email address or same group saying the same thing over and over feeding the troll.... I have not experienced this behaviour on the ARIN or RIPE lists or even APNIC for which we are both participants.. Why are you advocating for it in the AFRNIC service region....? Cheers, ./noah _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd From omo.oaiya at wacren.net Fri Jul 24 19:18:51 2026 From: omo.oaiya at wacren.net (Omo Oaiya) Date: Fri, 24 Jul 2026 22:18:51 +0300 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: References: Message-ID: <3572110C-3C6E-41A0-B285-2118CE50D47B@wacren.net> Hi Ben, I'm beginning to appreciate the practical challenge facing the Co-Chairs. There is clear evidence of coordinated submissions, and regardless of authorship, the volume of near-duplicate messages makes it increasingly difficult to follow the discussion or identify genuinely new arguments. Whether that amounts to an attempt to manipulate rough consensus is, however, for the Co-Chairs to determine. My concern is making AI itself the object of moderation. The focus should remain on the contribution and its effect on the process. Distinct, relevant and evidence-based arguments deserve consideration on their merits. Duplication, flooding, coordinated campaigns and unsupported assertions should be moderated because they undermine the integrity of the policy process, not because of the tool used to produce them. If we remain disciplined about that principle, the PDP will remain robust as the tools we use continue to evolve. Best wishes, Omo On 24 July 2026 11:28:27 EEST, Ben Roberts - AfriNIC via RPD wrote: >_______________________________________________ >RPD mailing list >RPD at afrinic.net >https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From noah at neo.co.tz Fri Jul 24 21:19:17 2026 From: noah at neo.co.tz (Noah) Date: Sat, 25 Jul 2026 00:19:17 +0300 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: <3572110C-3C6E-41A0-B285-2118CE50D47B@wacren.net> References: <3572110C-3C6E-41A0-B285-2118CE50D47B@wacren.net> Message-ID: Infact Omo, just to add that from our collective experience, its material concerns that always deserve proper consideration, but once that has occurred the same points do not need to be re-engaged simply because they are rephrased using LLM tools, the way the folks using AI/llm tools were going on and on about.... The PDWG has always looked out for new data or insights so as to push for further discussion. In this Last Call the objection which was already raised through the initial AI slops, was addressed by members of the PDWG in support of the proposal but even after that, the AI folks kept on going restating the same objection without material new evidence. Cheers, *.**/noah* On Fri, 24 Jul 2026, 10:28?pm Omo Oaiya via RPD, wrote: > Hi Ben, > > I'm beginning to appreciate the practical challenge facing the Co-Chairs. > There is clear evidence of coordinated submissions, and regardless of > authorship, the volume of near-duplicate messages makes it increasingly > difficult to follow the discussion or identify genuinely new arguments. > Whether that amounts to an attempt to manipulate rough consensus is, > however, for the Co-Chairs to determine. > > My concern is making AI itself the object of moderation. The focus should > remain on the contribution and its effect on the process. Distinct, > relevant and evidence-based arguments deserve consideration on their > merits. Duplication, flooding, coordinated campaigns and unsupported > assertions should be moderated because they undermine the integrity of the > policy process, not because of the tool used to produce them. > > If we remain disciplined about that principle, the PDP will remain robust > as the tools we use continue to evolve. > > Best wishes, > Omo > > > On 24 July 2026 11:28:27 EEST, Ben Roberts - AfriNIC via RPD < > rpd at afrinic.net> wrote: > >> I think we are broadly in agreement Lu, >> >> Using AI tools for drafting is something that humans can do and nobody >> here seems to object to that. Myself and Hendrik and others have freely >> acknowledged using Claude to analyse the mailing list content also. >> >> But what has occurred here has been a co-ordinated list flooding >> campaign, possibly (highly likely) by fully automated AI bots. It?s filled >> a lot of inboxes and really annoyed a lot of people, and caused others to >> switch off just unable to digest such huge volumes of slop. >> >> Kind regards >> Ben >> >> Sent from my iPhone >> >> On 24 Jul 2026, at 10:01, Lu Heng wrote: >> >> ? >> >> The discussion is focused on the wrong unit. What matters is not whether >> a message was drafted by a human or an AI, but whether it contributes a >> distinct, relevant, and evidence-based argument. The correct moderation >> targets are duplication, flooding, irrelevance, and unsupported claims?not >> the drafting tool. The practical solution is straightforward: place the >> policy, or each disputed clause, in the centre of a web interface; display >> the arguments for and against it on either side; and use AI to maintain a >> continuous summary, cluster repeated arguments, and identify genuinely new >> ones. Anyone should be free to submit a new argument or supporting >> evidence, while every AI classification remains visible and appealable. A >> basic prototype could be built in a day. >> >> Whether humans should retain a monopoly over argumentation is a separate >> question. They have no principled claim to such a monopoly once machines >> can competently compare, organize, and summarize arguments at scale. More >> importantly, a human-only process does not preserve openness. Repeated >> interaction tends to produce a small, self-selecting clique that determines >> whose language, identity, and participation count, excludes outsiders, and >> eventually becomes insular and cult-like. This is mandate laundering: >> control over procedure is converted into an illegitimate claim of >> substantive authority. Once that happens, formal openness ceases to provide >> legitimacy. The RIR system may continue to exist in name, but its bottom-up >> model will have effectively ended. >> >> >> >> -- >> Kind regards. >> Lu >> >> >> On Fri, Jul 24, 2026 at 12:24 Ben Roberts - AfriNIC via RPD < >> rpd at afrinic.net> wrote: >> >>> Mike, >>> You are trivialising the issue as a mere AI content problem. If it were >>> just a case that some people are using AI writing tools then we would not >>> be having this debate. >>> >>> What we have seen is a co-ordinated Astroturfing attack of multiple >>> anonymous gmails, bombarding the list with near identical yet largely >>> meaningless essays all backing each other up. There may have been humans >>> with keyboards sitting owning the gmails, but I?ve seen no evidence of >>> ?proof of life? behind the accounts. Not even basic pleasantries (e.g. >>> ?hello how are you?) or variation from the monotonic robot style. If it >>> looks like an AI robot, quacks like an AI robot, then guess what, 9 times >>> out of 10 it?s an AI robot. >>> So it?s entirely very probable that they are just AI agent robots >>> running on Openclaw instances that are fully in control of the Gmail >>> accounts. Or it could just be one Openclaw controlling multiple Gmails, >>> which would explain the ?hive mind? like co-ordinated and recycled >>> paragraphs that are word for word recycled by member accounts of the >>> collective. The ?community? for policy development is supposed to be a >>> community of humans. The known identifiable humans in the collective seem >>> to have concencus that none of us have a problem with other known humans >>> using AI tools to assist their writing. >>> It will be very easy to modify the CoC to clarify that list membership >>> is restricted to real old fashioned humans sitting with computer gadgets >>> that they use to post the list, while excluding autonomous computer devices >>> running their own writing/posting programs in absence of human creativity. >>> >>> Kind regards >>> Ben >>> >>> >>> Sent from my iPhone >>> >>> On 23 Jul 2026, at 22:09, Mike Burns via RPD wrote: >>> >>> ? >>> >>> Hi Noah, >>> >>> >>> >>> Yes you are telling everybody that you have had enough of it. Fair >>> enough. >>> >>> >>> >>> Yes, I am seeing no issue using AI unless it is used at cross-purposes >>> of the list. >>> >>> I don?t think the use of AI in this context has reached that level, and >>> also I don?t think it has been very effective. >>> >>> >>> >>> I think in the future AI will write more effective messages to the list, >>> with or without human intervention. >>> >>> I will read those effective messages and argue against, or accept the >>> arguments made. >>> >>> >>> >>> Regards, >>> Mike >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *From:* Noah >>> *Sent:* Thursday, July 23, 2026 1:41 PM >>> *To:* Mike Burns >>> *Cc:* Hytham El-Nakhal ; pdwg-chairs at afrinic.net; >>> rpd List >>> *Subject:* Re: [rpd] PDWG Co-Chairs communication regarding observed >>> behavioron AFPUB-2026-ASN-001-DRAFT02 >>> >>> >>> >>> I did not say you commented on as-set issue.. >>> >>> >>> >>> The co-chair initiated this thread per subjectline which is related to >>> hierarchical names for new as-set draft policy AFPUB-2026-ASN-001-DRAFT02. >>> >>> >>> >>> The co-chair openning statement read... in quote >>> >>> >>> >>> "The mailing list has recently been flooded with multiple emails stating >>> either the same duplicate objections or consistent pushbacks to every post, >>> some of them with subject line containing ?Digest?." >>> >>> >>> >>> The above is an outcome of folks outsourcing their thinking to AI and >>> endlessly trolling using multiple emails and sockpuppets to bombard the rpd >>> list. >>> >>> >>> >>> You are talking about usage of AI and seeing no issue with it. >>> >>> >>> >>> I am telling you I have had enough of it. >>> >>> >>> >>> Cheers, >>> >>> *./noah* >>> >>> >>> >>> >>> >>> >>> >>> On Thu, 23 Jul 2026, 8:29?pm Mike Burns, wrote: >>> >>> Hi Noah, >>> >>> >>> >>> I have made no comments on the AS-SET issue and tried to create a >>> separate discussion thread for AI. >>> >>> >>> >>> Regards, >>> >>> Mike >>> >>> >>> >>> >>> >>> *From:* Noah >>> *Sent:* Thursday, July 23, 2026 1:26 PM >>> *To:* Mike Burns >>> *Cc:* Hytham El-Nakhal ; pdwg-chairs at afrinic.net; >>> rpd List >>> *Subject:* Re: [rpd] PDWG Co-Chairs communication regarding observed >>> behavioron AFPUB-2026-ASN-001-DRAFT02 >>> >>> >>> >>> Hi Mike >>> >>> >>> >>> What AI generated arguments will possibly change the facts that as-set >>> collision is an issue. >>> >>> >>> >>> Havent we already documented the fact that as-set names collide across >>> IRR databases and AI/Claude have nothing to do with this fact. >>> >>> >>> >>> When merging across IRR databases, havent we ack that collisions have >>> resulted in ambiguity, empty or conflicting objects that cause tools to >>> return incorrect or empty filter data. How is this AI/Claude problem? >>> >>> >>> >>> Havent other RIR implemented, hierarchical naming, some through policy >>> others through operational implementations to bind new as-set to a specific >>> ASN holder. Did they consult AI/Claude while at it? >>> >>> >>> >>> Havent folks agreed that going forward we fix the issue at the moment of >>> creation of new as-sets the only point at which an authoritative registry >>> can prevent new instances of collision problem. I dont see how this is >>> AI/claude concern nor how AI will be involved in technically fixing the >>> problem even those outsourcing their thinking to claude to oppose what we >>> want to fix wont be on the ground to fix the issue. >>> >>> >>> >>> Cheers, >>> >>> *./noah* >>> >>> >>> >>> >>> >>> >>> >>> On Thu, 23 Jul 2026, 5:50?pm Mike Burns, wrote: >>> >>> Hi Noah, >>> >>> >>> >>> I have made it clear from the outset that list swamping or use of AI to >>> generate duplicative, though reworded objections is grounds for moderation. >>> >>> That issue, which I was at pains to separate from the use of AI, >>> continues to be conflated with the simple use of AI. >>> >>> >>> >>> That brings me to ad hominem, which is the basis of my belief and which >>> you have failed in your reply. >>> >>> >>> >>> Ad hominem means that the speaker of an argument is of no importance >>> when considering the argument. >>> >>> >>> >>> When you ask my for my motive, you breach that. >>> >>> >>> >>> Regards, >>> >>> >>> >>> Mike >>> >>> >>> >>> >>> >>> *From:* Noah >>> *Sent:* Thursday, July 23, 2026 10:03 AM >>> *To:* Mike Burns >>> *Cc:* Hytham El-Nakhal ; pdwg-chairs at afrinic.net; >>> rpd List >>> *Subject:* Re: [rpd] PDWG Co-Chairs communication regarding observed >>> behavioron AFPUB-2026-ASN-001-DRAFT02 >>> >>> >>> >>> >>> >>> On Wed, 22 Jul 2026, 8:53?pm Mike Burns, wrote: >>> >>> >>> >>> It?s not like Claude will be elected to any parliament. >>> >>> But this unique governance form for a global asset provides the >>> opportunity. >>> >>> I say, who cares if Claude is posting, or ChatGPT, or any other AI. >>> >>> I care that the AFRINIC rpd list is not turned into waste land of AI >>> powered trolls >>> >>> >>> >>> Give them a seat at the table and address their arguments. >>> >>> >>> >>> How many valid argument have been made in the past week or you mean a >>> single argument repeated through AI generated texts send by single persons >>> using multiple different email address or same group saying the same thing >>> over and over feeding the troll.... >>> >>> >>> >>> I have not experienced this behaviour on the ARIN or RIPE lists or even >>> APNIC for which we are both participants.. >>> >>> >>> >>> Why are you advocating for it in the AFRNIC service region....? >>> >>> >>> >>> Cheers, >>> >>> *./noah* >>> >>> >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >>> _______________________________________________ >>> RPD mailing list >>> RPD at afrinic.net >>> https://lists.afrinic.net/mailman/listinfo/rpd >>> >> _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.roberts at afrinic.net Sat Jul 25 08:00:48 2026 From: ben.roberts at afrinic.net (Ben Roberts - AfriNIC) Date: Sat, 25 Jul 2026 09:00:48 +0100 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavioron AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: <3572110C-3C6E-41A0-B285-2118CE50D47B@wacren.net> References: <3572110C-3C6E-41A0-B285-2118CE50D47B@wacren.net> Message-ID: <876DB638-1AA3-48AF-8B4D-270770F3175C@afrinic.net> An HTML attachment was scrubbed... URL: From christianbope at gmail.com Sat Jul 25 13:39:11 2026 From: christianbope at gmail.com (Bope Domilongo Christian) Date: Sat, 25 Jul 2026 08:39:11 -0500 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <1784239787450.20999@tra.gov.eg> References: <1784239787450.20999@tra.gov.eg> Message-ID: Hi PDWG, I beg to offer a possible way out. For several days now, we have seen two opposing views on how best to address AS?SET name collisions from AFRINIC Routing Registry. Both positions raise legitimate concerns, but the way the arguments are being expressed is now having negative effects on the PDP process itself. In many technical communities, when multiple valid solutions exist, the group often pauses, lets the current call for comments conclude, and then works toward a compromise that can be broadly accepted. May I suggest that we allow the Last Call to end, and afterwards explore an acceptable compromise between the two views? This may help us converge without prolonging the current disagreement. RFC 7282( On Consensus and humming in the IETF) Security Consideration reads: ?He who defends with love will be secure.? ? Lao Tzu @christianbope On Thu, 16 Jul 2026 at 17:10, Hytham El-Nakhal wrote: > Dear PDWG, > > > The Policy Development Working Group (PDWG) Chairs have initiated a Last > Call for this proposal, following rough consensus at the AFRINIC-37 Public > Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. > > * Proposal Name: Hierarchical Names for New AS-SETs > > * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > > * Proposal URL: > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > Last Call closes on: July 31, 2026, at 23:59 UTC. > > > 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. > > > As always, we kindly request that all participants adhere to the AFRINIC > Code of Conduct to maintain a respectful > and professional environment on the mailing list. > > > Kind regards, > > > Haitham el Nakhal > > AFRINIC PDWG Co-Chair > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amelnaud at gmail.com Sat Jul 25 14:23:05 2026 From: amelnaud at gmail.com (Arnaud AMELINA) Date: Sat, 25 Jul 2026 14:23:05 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <1784239787450.20999@tra.gov.eg> Message-ID: Hi Christian, A very good suggestion. As one of policy proposal authors who has already experienced this kind of deadlock in our discussions, I believe we must bring more wisdom and more love into our actions. AFRINIC is on a recovery path, and history will judge how we conduct ourselves during this period. Let us keep in mind that our community advances through arguments, not through postures. The responsibility we carry is real, and the consequences of our choices will shape the future of the Registry. Happy weekend to all. ? Arnaud Le sam. 25 juil. 2026 ? 13:41, Bope Domilongo Christian < christianbope at gmail.com> a ?crit : > Hi PDWG, > > I beg to offer a possible way out. > > For several days now, we have seen two opposing views on how best to > address AS?SET name collisions from AFRINIC Routing Registry. Both > positions raise legitimate concerns, but the way the arguments are being > expressed is now having negative effects on the PDP process itself. > > In many technical communities, when multiple valid solutions exist, the > group often pauses, lets the current call for comments conclude, and then > works toward a compromise that can be broadly accepted. > > May I suggest that we allow the Last Call to end, and afterwards explore > an acceptable compromise between the two views? This may help us converge > without prolonging the current disagreement. > > RFC 7282( On Consensus and humming in the IETF) Security Consideration > reads: > ?He who defends with love will be secure.? ? Lao Tzu > > @christianbope > > On Thu, 16 Jul 2026 at 17:10, Hytham El-Nakhal wrote: > >> Dear PDWG, >> >> >> The Policy Development Working Group (PDWG) Chairs have initiated a Last >> Call for this proposal, following rough consensus at the AFRINIC-37 Public >> Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. >> >> * Proposal Name: Hierarchical Names for New AS-SETs >> >> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >> >> * Proposal URL: >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >> Last Call closes on: July 31, 2026, at 23:59 UTC. >> >> >> 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. >> >> >> As always, we kindly request that all participants adhere to the AFRINIC >> Code of Conduct to maintain a respectful >> and professional environment on the mailing list. >> >> >> Kind regards, >> >> >> Haitham el Nakhal >> >> AFRINIC PDWG Co-Chair >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fundiswanadia2 at gmail.com Sun Jul 26 12:07:25 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Sun, 26 Jul 2026 14:07:25 +0200 Subject: [rpd] RPD Digest, Vol 222, Issue 204 In-Reply-To: References: Message-ID: Hi Christian, Thank you for sharing this perspective. As someone who also shared my viewpoint during this discussion, I appreciate your reminder that, despite our different positions, we all want what's best for the AFRINIC community. I think allowing the Last Call to conclude as planned, and then reflecting on all the feedback received, gives the community an opportunity to move forward constructively. Whether that leads to refinement, compromise, or confirmation of the current proposal, the process will have benefited from everyone being heard. Thank you for encouraging a respectful and collaborative approach. Kind regards, Fundiswa Nadia Maseko On Sun, 26 Jul 2026, 14:00 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > (Bope Domilongo Christian) > 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Arnaud AMELINA) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 25 Jul 2026 08:39:11 -0500 > From: Bope Domilongo Christian > To: rpd > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > < > CAN7nxtN7Yag1GjBqFKjwq9xkOu6sbETkH0FikDHnrBORZQES+w at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi PDWG, > > I beg to offer a possible way out. > > For several days now, we have seen two opposing views on how best to > address AS?SET name collisions from AFRINIC Routing Registry. Both > positions raise legitimate concerns, but the way the arguments are being > expressed is now having negative effects on the PDP process itself. > > In many technical communities, when multiple valid solutions exist, the > group often pauses, lets the current call for comments conclude, and then > works toward a compromise that can be broadly accepted. > > May I suggest that we allow the Last Call to end, and afterwards explore an > acceptable compromise between the two views? This may help us converge > without prolonging the current disagreement. > > RFC 7282( On Consensus and humming in the IETF) Security Consideration > reads: > ?He who defends with love will be secure.? ? Lao Tzu > > @christianbope > > On Thu, 16 Jul 2026 at 17:10, Hytham El-Nakhal wrote: > > > Dear PDWG, > > > > > > The Policy Development Working Group (PDWG) Chairs have initiated a Last > > Call for this proposal, following rough consensus at the AFRINIC-37 > Public > > Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. > > > > * Proposal Name: Hierarchical Names for New AS-SETs > > > > * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > > > > * Proposal URL: > > https://www.afrinic.net/afpub-2026-asn-001-draft02.html > > > > Last Call closes on: July 31, 2026, at 23:59 UTC. > > > > > > 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. > > > > > > As always, we kindly request that all participants adhere to the AFRINIC > > Code of Conduct to maintain a respectful > > and professional environment on the mailing list. > > > > > > Kind regards, > > > > > > Haitham el Nakhal > > > > AFRINIC PDWG Co-Chair > > > > > > > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260725/9f8d58f1/attachment-0001.html > > > > ------------------------------ > > Message: 2 > Date: Sat, 25 Jul 2026 14:23:05 +0000 > From: Arnaud AMELINA > To: Bope Domilongo Christian > Cc: rpd > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > CqCNeKwdsBD1W9Lztag_FJfR2nHg at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Christian, A very good suggestion. As one of policy proposal authors who > has already experienced this kind of deadlock in our discussions, I believe > we must bring more wisdom and more love into our actions. AFRINIC is on a > recovery path, and history will judge how we conduct ourselves during this > period. Let us keep in mind that our community advances through arguments, > not through postures. The responsibility we carry is real, and the > consequences of our choices will shape the future of the Registry. Happy > weekend to all. ? > Arnaud > > Le sam. 25 juil. 2026 ? 13:41, Bope Domilongo Christian < > christianbope at gmail.com> a ?crit : > > > Hi PDWG, > > > > I beg to offer a possible way out. > > > > For several days now, we have seen two opposing views on how best to > > address AS?SET name collisions from AFRINIC Routing Registry. Both > > positions raise legitimate concerns, but the way the arguments are being > > expressed is now having negative effects on the PDP process itself. > > > > In many technical communities, when multiple valid solutions exist, the > > group often pauses, lets the current call for comments conclude, and then > > works toward a compromise that can be broadly accepted. > > > > May I suggest that we allow the Last Call to end, and afterwards explore > > an acceptable compromise between the two views? This may help us converge > > without prolonging the current disagreement. > > > > RFC 7282( On Consensus and humming in the IETF) Security Consideration > > reads: > > ?He who defends with love will be secure.? ? Lao Tzu > > > > @christianbope > > > > On Thu, 16 Jul 2026 at 17:10, Hytham El-Nakhal > wrote: > > > >> Dear PDWG, > >> > >> > >> The Policy Development Working Group (PDWG) Chairs have initiated a Last > >> Call for this proposal, following rough consensus at the AFRINIC-37 > Public > >> Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. > >> > >> * Proposal Name: Hierarchical Names for New AS-SETs > >> > >> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 > >> > >> * Proposal URL: > >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html > >> > >> Last Call closes on: July 31, 2026, at 23:59 UTC. > >> > >> > >> 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. > >> > >> > >> As always, we kindly request that all participants adhere to the AFRINIC > >> Code of Conduct to maintain a respectful > >> and professional environment on the mailing list. > >> > >> > >> Kind regards, > >> > >> > >> Haitham el Nakhal > >> > >> AFRINIC PDWG Co-Chair > >> > >> > >> > >> _______________________________________________ > >> RPD mailing list > >> RPD at afrinic.net > >> https://lists.afrinic.net/mailman/listinfo/rpd > >> > > _______________________________________________ > > RPD mailing list > > RPD at afrinic.net > > https://lists.afrinic.net/mailman/listinfo/rpd > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260725/87187d9c/attachment-0001.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 204 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Sun Jul 26 20:20:05 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Sun, 26 Jul 2026 22:20:05 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <1784239787450.20999@tra.gov.eg> Message-ID: <73A94A93-13A3-4408-A039-043A24728EA7@hevis.co.za> Good day Christian, Arnaud, I appreciate the spirit of your messages, and I agree that Last Call should run to its scheduled close. Arnaud, I especially agree with your words: our community advances through ARGUMENTS, not through postures! => Let us apply exactly that test here. On the process point first, respectfully: the PDP (CPM Section 3, as the Co-Chairs referenced on 21 July) has no post-Last-Call negotiation phase. After the close, the Co-Chairs determine whether rough consensus exists on the record, and the proposal proceeds ? or does not ? on that basis. "Exploring a compromise afterwards" presumes the outcome is deadlock before the Co-Chairs have even had time or opportunity to properly assess anything. And the record does not show a deadlock; it shows an unanswered side. The one technical objection raised (attribution vs content validity) was agreed by both sides to be outside the proposal's stated scope. The operational-route question has been answered on-list several times. The six specific questions put to those opposing on 23 July (https://lists.afrinic.net/pipermail/rpd/2026/015344.html) have received only one substantive response. In the PDP, compromise takes the form of concrete text amendments. Arnaud, your own proposal's thread this very week shows what that looks like: Jaco proposed specific alternative wording for the IPv6 criteria after discussing it in person with Mark (https://lists.afrinic.net/pipermail/rpd/2026/015276.html). That is genuine disagreement doing its work ? arguments producing text. On this proposal, in eleven days of Last Call, no one opposing has named a single amendment they would accept ? only objection after objection. That difference is the whole story, and it is the difference between argument and posture. Until the close of Last Call, if somebody proposes a specific amendment, I believe this Working Group will engage it on its merits, as it has engaged every substantive point so far. Without any amendment proposal, the community should trust the Co-Chairs to assess the record as it stands, per their guidance last week. A renegotiation prompted by volume rather than by substance would set exactly the precedent this Working Group should not set. Regards, Hendrik Visage (AS329532; also AS213481) From seun.ojedeji at gmail.com Sun Jul 26 21:01:25 2026 From: seun.ojedeji at gmail.com (Seun Ojedeji) Date: Sun, 26 Jul 2026 17:01:25 -0400 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <1784239787450.20999@tra.gov.eg> Message-ID: Hello Christian, I am unsure what valid opposing view has been made. I only saw some posts suggesting this does not need to be done via policy which does not negate the fact that implementing via policy is not a bad thing. Last call is to check for any significant objection to a proposal with reason. I don't think that has occurred yet on this policy so normally Co-Chair will declare his decision after last call which is either to move the policy for ratification or send back to the list. There is no option for a policy to pass last call conditionally unless you are suggesting that you do not support moving the policy forward and in that case a reason will be required. Regards ---- Sent from my mobile kindly excuse typos On Sat, 25 Jul 2026, 9:41?am Bope Domilongo Christian, < christianbope at gmail.com> wrote: > Hi PDWG, > > I beg to offer a possible way out. > > For several days now, we have seen two opposing views on how best to > address AS?SET name collisions from AFRINIC Routing Registry. Both > positions raise legitimate concerns, but the way the arguments are being > expressed is now having negative effects on the PDP process itself. > > In many technical communities, when multiple valid solutions exist, the > group often pauses, lets the current call for comments conclude, and then > works toward a compromise that can be broadly accepted. > > May I suggest that we allow the Last Call to end, and afterwards explore > an acceptable compromise between the two views? This may help us converge > without prolonging the current disagreement. > > RFC 7282( On Consensus and humming in the IETF) Security Consideration > reads: > ?He who defends with love will be secure.? ? Lao Tzu > > @christianbope > > On Thu, 16 Jul 2026 at 17:10, Hytham El-Nakhal wrote: > >> Dear PDWG, >> >> >> The Policy Development Working Group (PDWG) Chairs have initiated a Last >> Call for this proposal, following rough consensus at the AFRINIC-37 Public >> Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. >> >> * Proposal Name: Hierarchical Names for New AS-SETs >> >> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02 >> >> * Proposal URL: >> https://www.afrinic.net/afpub-2026-asn-001-draft02.html >> >> Last Call closes on: July 31, 2026, at 23:59 UTC. >> >> >> 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. >> >> >> As always, we kindly request that all participants adhere to the AFRINIC >> Code of Conduct to maintain a respectful >> and professional environment on the mailing list. >> >> >> Kind regards, >> >> >> Haitham el Nakhal >> >> AFRINIC PDWG Co-Chair >> >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Mon Jul 27 06:30:32 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Mon, 27 Jul 2026 06:30:32 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear PDWG, I have a separate concern arising from the Impact Assessment. The proposal validates an AS-SET only when it is created, but the assessment presents the hierarchical name as a continuing link to the responsible ASN operator. That link may not remain accurate throughout the object?s lifetime. For example, what happens if the leading ASN changes holder, is returned, is reassigned, or receives a new maintainer? Does the former operator retain control of AS12345:AS-CUSTOMERS, does the new holder inherit it, or is the object suspended? The policy also permits existing objects to be edited, but does not say whether changes to maintainers or parent objects trigger renewed authorisation checks. Deletion and recreation create a similar problem. If a hierarchical name is deleted and later recreated, existing filters or references may silently resolve to a different object using the same name. The proposal provides no tombstone, reservation, restoration period, or conflict-state mechanism. These are not questions about whether AS-SET membership is correct. They concern whether the proposal?s claimed attribution remains technically true after creation. Before adoption, the policy should define deterministic rules for changes of ASN control, parent-child delegation, maintainer replacement, deletion, restoration, and name reuse. Otherwise, AFRINIC may enforce a hierarchical label while the label no longer identifies the operator actually controlling the object. A creation-time check is not enough for a claim of continuing authorisation. For that reason, I object to the proposal as presently written. Regards, Tshepo -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Mon Jul 27 09:23:20 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Mon, 27 Jul 2026 11:23:20 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: <67f9b36c-c40b-4801-b558-af8968aeead0@uls.co.za> Hi, On 2026/07/27 08:30, Tshepo Masuku wrote: > > Dear PDWG, > > I have a separate concern arising from the Impact Assessment. > > The proposal validates an AS-SET only when it is created, but the > assessment presents the hierarchical name as a continuing link to the > responsible ASN operator. That link may not remain accurate throughout > the object?s lifetime. > We've established that the policy is about avoiding inter-RIR collisions and attesting to who (which AS) published the object. The validity of the data is a whole different ballgame and must be addressed separately.? I have had some ideas on this but my mindset was mostly around how tooling can use current IRR data to validate the correctness of AS-SET data - nothing that remotely worked has popped up, but as mentioned that's independent of this policy. > > For example, what happens if the leading ASN changes holder, is > returned, is reassigned, or receives a new maintainer? Does the former > operator retain control of |AS12345:AS-CUSTOMERS|, does the new holder > inherit it, or is the object suspended? The policy also permits > existing objects to be edited, but does not say whether changes to > maintainers or parent objects trigger renewed authorisation checks. > The AS remains, unless the AS gets shut, in which case the objects can either remain for some time (currently they linger indefinitely, since we have no way to clean them up now either anyway).? The policy is thus still a move in the right direction as it will enable us to clean up in case an AS gets cleaned up. Stale data again IMHO is a different independent problem that should be addressed as such. > Deletion and recreation create a similar problem. If a hierarchical > name is deleted and later recreated, existing filters or references > may silently resolve to a different object using the same name. The > proposal provides no tombstone, reservation, restoration period, or > conflict-state mechanism. > I don't think this is relevant any more, in part due to the same AS that would need to recreate, we're already much better off here too, in that for example if some entity references AS-FOO, then that gets deleted, an attacker can now currently create AS-FOO.? With this policy that would be prohibited, and if it was ASxxx:AS-FOO then the attacker would need to be authoritive for ASxxx to recreate the object, so again we gain some level of protection. > > These are not questions about whether AS-SET membership is correct. > They concern whether the proposal?s claimed attribution remains > technically true after creation. > Any new owner of the same ASxxx would be in a position now to clean that up, compared to previous non-hierarchical objects which would (and continue to) linger indefinitely.? So this is still an improvement over current situation even in those cases. > > Before adoption, the policy should define deterministic rules for > changes of ASN control, parent-child delegation, maintainer > replacement, deletion, restoration, and name reuse. Otherwise, AFRINIC > may enforce a hierarchical label while the label no longer identifies > the operator actually controlling the object. > Whomever manages the parent ASxxx (first ASxxx in the sequence) in the set is the responsible party, so I don't see how this is relevant. > > A creation-time check is not enough for a claim of continuing > authorisation. > > For that reason, I object to the proposal as presently written. > Please refer above and advise if that addresses your concerns - I believe it should. Kind regards, Jaco > Regards, > Tshepo > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonjabulosphilile at gmail.com Mon Jul 27 06:50:26 2026 From: nonjabulosphilile at gmail.com (Nonjabulo Sphilile) Date: Mon, 27 Jul 2026 08:50:26 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear PDWG, Kindly allow me to raise a technical concern on my side that further supports my objection to the proposed policy. The proposal controls the name of a newly created AS-SET, but not the AS-SET names referenced inside it. RPSL allows the members: attribute of an AS-SET to contain other AS-SET names. Those referenced sets are then included when the object is expanded, with nested inclusion operating recursively. A new object such as: AS65000:AS-CUSTOMERS could therefore still contain: members: AS-EXAMPLE If AS-EXAMPLE exists with different contents in multiple IRR sources, the top-level object may be hierarchical while its dependency chain remains ambiguous. The same filter-generation problem can therefore reappear during recursive expansion. This is not the earlier argument about whether individual members are factually correct. It is a narrower issue of resolution integrity: the proposal secures the first object name but does not secure every referenced name that tooling must resolve. The Impact Assessment expressly places resolver behaviour outside scope, yet the operational justification depends on the results produced by resolvers and filter-generation tools. That gap needs to be addressed. Before adoption, the proposal should clarify whether newly created hierarchical AS-SETs may reference grandfathered flat AS-SETs. If they may, the policy should define how ambiguity is detected and handled throughout the dependency chain. If they may not, the operational impact and migration requirements should be assessed and documented. A creation-time naming restriction should not be credited with protecting filter generation until the complete expansion path has been tested. For this reason, I object to the proposal as presently written. Regards, Nonjabulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Mon Jul 27 09:50:48 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Mon, 27 Jul 2026 11:50:48 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: <1f6b5be4-4c34-4728-9381-3a6cbbcb9ee7@uls.co.za> Hi, On 2026/07/27 08:50, Nonjabulo Sphilile wrote: > Dear PDWG, > > Kindly allow me to raise a technical concern on my side that further > supports my objection to the proposed policy. > > The proposal controls the name of a newly created AS-SET, but not the > AS-SET names referenced inside it. RPSL allows the members: attribute > of an AS-SET to contain other AS-SET names. Those referenced sets are > then included when the object is expanded, with nested inclusion > operating recursively. > > A new object such as: > > AS65000:AS-CUSTOMERS > > could therefore still contain: > > members: AS-EXAMPLE > > If AS-EXAMPLE exists with different contents in multiple IRR sources, > the top-level object may be hierarchical while its dependency chain > remains ambiguous. The same filter-generation problem can therefore > reappear during recursive expansion. Correct.? But this will stop new such top-level cases from creating dangere, and hopefully AS65000 will deploy as RIR::AS-EXAMPLE, locking it down to the specific instance.? This policy will stop re-creation of RIR::AS-EXAMPLE once it's deleted, thus eliminating the re-use risk as well.? As such, whilst it does not close all possible attack vectors from day one, it stops them from being created going forward.? Getting existing parties to migrate is an operational matter and migration should be encouraged.? It should not stop us from blocking the problem going forward. > > This is not the earlier argument about whether individual members are > factually correct. It is a narrower issue of resolution integrity: the > proposal secures the first object name but does not secure every > referenced name that tooling must resolve. Agreed - but it stops targets from being created going forward. > > The Impact Assessment expressly places resolver behaviour outside > scope, yet the operational justification depends on the results > produced by resolvers and filter-generation tools. That gap needs to > be addressed. So narrowing a gap that already exist, and which will be closed over time with this policy without creating operational issues right now is not sufficient? What would you propose?? The only possible improvement I can imagine to this policy here it to prevent plain AS-NAMES from being added as members, and that they need to be at least RIR::AS-NAME - which is something I can consider getting behind, but I believe adjusting the content restriction, rather than naming thereof, could be considered a separate policy?? If you'd like to propose wording to add this I'm sure it would be considered positively but I'm not sure this is sufficient reason to not progress on the existing proposal since it's already creating a huge improvement over existing status quo. Further, I suspect implementing such a restriction would be considerably harder on the whois side compared to this policy, and as such I for one would at least see *some improvement* soonest possible, compared to having to wait for a perfect policy that would take longer to deploy - I assume we can agree on that much at least? > > Before adoption, the proposal should clarify whether newly created > hierarchical AS-SETs may reference grandfathered flat AS-SETs. If they > may, the policy should define how ambiguity is detected and handled > throughout the dependency chain. If they may not, the operational > impact and migration requirements should be assessed and documented. I think this applies not only to newly created hierarchical AS-SET objects, but to ALL AS-SET objects as they get updated, or newly created, and for this reason alone I would suggest that we've got concensus that restricting newly created objects to be hierarchical is a step in the right direction, and that we can address the membership status separately such that all objects going forward, whether updated or newly created may no longer reference other AS-SET objects by name only and must be of the format RIR::AS-NAME or ASxxx::AS-NAME, and I believe that's a separate change that deserves it's own operational assessment. > > A creation-time naming restriction should not be credited with > protecting filter generation until the complete expansion path has > been tested. It does avoid creating further problem cases, it does not stop existing problems, or existing objects that creates problems, no one has claimed it does.? It does stop people from creating new objects that can be targeted.? Kinda like deprecating older ciphers in encryption protocols prior to banning them. Kind regards, Jaco From TshepoMasuku26 at hotmail.com Mon Jul 27 09:55:06 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Mon, 27 Jul 2026 09:55:06 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <67f9b36c-c40b-4801-b558-af8968aeead0@uls.co.za> References: <67f9b36c-c40b-4801-b558-af8968aeead0@uls.co.za> Message-ID: Dear Jaco, Thank you, but your answer introduces a further problem. You say the policy will allow AFRINIC or a future ASN holder to ?clean up? hierarchical objects. That mechanism does not appear in the policy. The text controls the name only when an object is created. It does not define what happens to child AS-SETs when the leading ASN is returned, transferred, reassigned, suspended, or deleted. This matters because cleanup can itself affect running networks. If AS12345:AS-FOO is referenced by other objects or operator configurations, deleting it creates a dangling reference. If a later holder of AS12345 recreates the same name, an unchanged reference may suddenly resolve to completely different data. The new holder?s ability to ?clean up? the previous holder?s namespace is therefore not automatically a protection. It is a transfer of control whose consequences the proposal does not define. Before adoption, the policy should state whether child names remain permanently reserved, whether they transfer with the ASN, whether existing objects are frozen pending re-authentication, how relying operators are notified, and what conditions apply to restoration or reuse. The undefined exception in section 7.8.7 makes this more serious. If AFRINIC may grant exceptions ?where necessary,? the supposedly closed namespace is not deterministic. The proposal does not say what qualifies as necessary, who decides, or whether an exception may permit another non-hierarchical object. A mandatory rule should define valid state transitions rather than leave them to future registry discretion. The proposal currently promises attribution at creation while leaving later control and name reuse unresolved. For that reason, my concern has not been addressed, and I remain opposed to the proposal as written. Regards, Tshepo ________________________________ From: Jaco Kroon Sent: Monday, July 27, 2026 11:23:30 am To: Tshepo Masuku ; rpd at afrinic.net ; pdwg-chairs at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Hi, On 2026/07/27 08:30, Tshepo Masuku wrote: Dear PDWG, I have a separate concern arising from the Impact Assessment. The proposal validates an AS-SET only when it is created, but the assessment presents the hierarchical name as a continuing link to the responsible ASN operator. That link may not remain accurate throughout the object?s lifetime. We've established that the policy is about avoiding inter-RIR collisions and attesting to who (which AS) published the object. The validity of the data is a whole different ballgame and must be addressed separately. I have had some ideas on this but my mindset was mostly around how tooling can use current IRR data to validate the correctness of AS-SET data - nothing that remotely worked has popped up, but as mentioned that's independent of this policy. For example, what happens if the leading ASN changes holder, is returned, is reassigned, or receives a new maintainer? Does the former operator retain control of AS12345:AS-CUSTOMERS, does the new holder inherit it, or is the object suspended? The policy also permits existing objects to be edited, but does not say whether changes to maintainers or parent objects trigger renewed authorisation checks. The AS remains, unless the AS gets shut, in which case the objects can either remain for some time (currently they linger indefinitely, since we have no way to clean them up now either anyway). The policy is thus still a move in the right direction as it will enable us to clean up in case an AS gets cleaned up. Stale data again IMHO is a different independent problem that should be addressed as such. Deletion and recreation create a similar problem. If a hierarchical name is deleted and later recreated, existing filters or references may silently resolve to a different object using the same name. The proposal provides no tombstone, reservation, restoration period, or conflict-state mechanism. I don't think this is relevant any more, in part due to the same AS that would need to recreate, we're already much better off here too, in that for example if some entity references AS-FOO, then that gets deleted, an attacker can now currently create AS-FOO. With this policy that would be prohibited, and if it was ASxxx:AS-FOO then the attacker would need to be authoritive for ASxxx to recreate the object, so again we gain some level of protection. These are not questions about whether AS-SET membership is correct. They concern whether the proposal?s claimed attribution remains technically true after creation. Any new owner of the same ASxxx would be in a position now to clean that up, compared to previous non-hierarchical objects which would (and continue to) linger indefinitely. So this is still an improvement over current situation even in those cases. Before adoption, the policy should define deterministic rules for changes of ASN control, parent-child delegation, maintainer replacement, deletion, restoration, and name reuse. Otherwise, AFRINIC may enforce a hierarchical label while the label no longer identifies the operator actually controlling the object. Whomever manages the parent ASxxx (first ASxxx in the sequence) in the set is the responsible party, so I don't see how this is relevant. A creation-time check is not enough for a claim of continuing authorisation. For that reason, I object to the proposal as presently written. Please refer above and advise if that addresses your concerns - I believe it should. Kind regards, Jaco Regards, Tshepo _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonjabulosphilile at gmail.com Mon Jul 27 10:23:19 2026 From: nonjabulosphilile at gmail.com (Nonjabulo Sphilile) Date: Mon, 27 Jul 2026 12:23:19 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear Jaco, Thank you for engaging with the concern. Your reply brings up a different problem that the Impact Assessment does not address. The policy has a future implementation date, while every flat AS-SET created before that date will remain valid and editable. This creates a race-to-grandfather risk. A database user could register desirable or confusing flat names during the transition, leave them empty or harmless, and populate or alter them after enforcement begins. The registry would then reject new flat names, but those pre-positioned objects would remain active indefinitely. In other words, the proposal does not necessarily stop new harmful cases going forward. It stops only one method of creating them after the cut-off date. New risk could still be introduced through later changes to grandfathered objects. The source-qualified membership restriction you suggest is not part of this proposal. A possible future policy cannot be counted as protection delivered by the current text. At minimum, the proposal would need an immediate reservation or cut-off mechanism, an audit of flat objects created during the implementation period, and clear rules governing material changes to grandfathered objects. The operational impact of those measures has not been assessed. Grandfathered does not mean frozen. Until the active legacy surface and the transition-period incentive are addressed, I do not believe the claim that the policy prevents new problem cases has been established. I therefore remain opposed to the proposal as written. Regards, Nonjabulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From phetulodhlamini at gmail.com Mon Jul 27 10:19:09 2026 From: phetulodhlamini at gmail.com (Phetulo Dhlamini) Date: Mon, 27 Jul 2026 12:19:09 +0200 Subject: [rpd] : Fw: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear Jaco, As I have been following the discussions very closely, thank you for taking the time to explain your position. I accept that hierarchical naming can strengthen creation authorisation within the AFRINIC database. I have a different concern, however. The proposal binds an AS-SET name to an ASN, but it does not bind that name to a particular IRR source. For example, AS12345:AS-CUSTOMERS identifies the ASN namespace, but it does not tell a resolver whether the intended object is from AFRINIC, RADB, RIPE, or another source. IRR software already recognises that sets with the same primary key may exist in different sources and may return them separately. This is not merely hypothetical architecture. An active IETF GROW working-group draft, still a work in progress, states that object primary keys are not guaranteed to be unique among IRR registries and proposes registry-scoped references precisely because multi-source resolution remains ambiguous. That creates a gap in the proposal?s central claim. It is presented as protection against inter-RIR collisions, yet the Impact Assessment expressly places mirroring and resolver behaviour outside scope. If the source is not part of the object?s identity, a hierarchical name may be properly authorised in AFRINIC while an identically named object remains visible through another source. Before mandatory enforcement is introduced, the design should specify how the authoritative source is selected, what tooling must do when the same hierarchical primary key appears in multiple sources, and whether source-qualified references or an equivalent deterministic rule are required. Otherwise, the policy gives operators a stronger-looking name without providing a complete answer to the multi-source lookup problem it is meant to address. This concern is fixable, but it should be resolved and tested before the proposal advances. I therefore remain opposed to the policy as presently written. Regards, Phetulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Mon Jul 27 10:46:55 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Mon, 27 Jul 2026 12:46:55 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <67f9b36c-c40b-4801-b558-af8968aeead0@uls.co.za> Message-ID: <101a6aa4-09f5-4377-b9d4-072698dcaf3e@uls.co.za> Hi, I believe it does, since the ASxxx:: "namespace" belongs to the AS, the owner of the AS should be perfectly able to clean it up, or at a minimum be "plainly able to request AFRINIC" to perform same. Since it's in the hierarchy of ASxxx any cleanup will plainly affect ASxxx either directly or indirectly, providing them incentive to fix it. As things stand currently, arbitrary parties are permitted to include any AS or AS-SET into their own anyway, so your concern is valid, but not directly related to the ongoing policy proposal. You're now starting to understand the bigger picture (I think) towards which this proposal is but a small step towards resolving.? We cannot, and should not aim to, build a castle reaching the sky without first building the foundations.? This is foundation building. AS transfer as I understand tranfers te AS object, along with all related objects, thus ownership gets moved to the new AS that has operational authority over the AS. In the case of deletion (return to the RIR) the objects would currently dangle, this would allow them to be deleted - which would definitely create a dangling reference, but prevent that object from being high-jacked by another party, thus already improving even that scenario.? Given the prevalence of AS numbers I highly doubt returned AS numbers would be re-used any time soon.? And if they are, the new owner should receive ownership of any undeleted but related objects, allowing them to clean things up. Remember:? NOTHING currently stops anyone from referencing any one else's AS-SET objects already - so recreating an object that's referenced, or having someone point to your existing object is thus from an operational perspective the same issue. That said - whilst I'm sure AS transfers and deletions happen, I do not think they're a frequent occurrence. Also, none of this is the object of the policy change.? Should policies be put into place to deal with that?? Most definitely, but we cannot build that sky-scraper in one step, we build it in multiple smaller steps, so that we can break down and retract/take steps back if we've found to have made a mistake, rather than building everything in one go and then having it crash down on us.? Floor by floor.? Brick by brick.? Small steps in the right direction, not leaps and bounds. Kind regards, Jaco On 2026/07/27 11:55, Tshepo Masuku wrote: > Dear Jaco, > > Thank you, but your answer introduces a further problem. > > You say the policy will allow AFRINIC or a future ASN holder to ?clean > up? hierarchical objects. That mechanism does not appear in the > policy. The text controls the name only when an object is created. It > does not define what happens to child AS-SETs when the leading ASN is > returned, transferred, reassigned, suspended, or deleted. > > This matters because cleanup can itself affect running networks. If > AS12345:AS-FOO is referenced by other objects or operator > configurations, deleting it creates a dangling reference. If a later > holder of AS12345 recreates the same name, an unchanged reference may > suddenly resolve to completely different data. > > The new holder?s ability to ?clean up? the previous holder?s namespace > is therefore not automatically a protection. It is a transfer of > control whose consequences the proposal does not define. > > Before adoption, the policy should state whether child names remain > permanently reserved, whether they transfer with the ASN, whether > existing objects are frozen pending re-authentication, how relying > operators are notified, and what conditions apply to restoration or reuse. > > The undefined exception in section 7.8.7 makes this more serious. If > AFRINIC may grant exceptions ?where necessary,? the supposedly closed > namespace is not deterministic. The proposal does not say what > qualifies as necessary, who decides, or whether an exception may > permit another non-hierarchical object. > > A mandatory rule should define valid state transitions rather than > leave them to future registry discretion. The proposal currently > promises attribution at creation while leaving later control and name > reuse unresolved. > > For that reason, my concern has not been addressed, and I remain > opposed to the proposal as written. > > Regards, > Tshepo > > > ------------------------------------------------------------------------ > *From:* Jaco Kroon > *Sent:* Monday, July 27, 2026 11:23:30 am > *To:* Tshepo Masuku ; rpd at afrinic.net > ; pdwg-chairs at afrinic.net > *Subject:* Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > Hi, > > On 2026/07/27 08:30, Tshepo Masuku wrote: > > Dear PDWG, > > I have a separate concern arising from the Impact Assessment. > > The proposal validates an AS-SET only when it is created, but the > assessment presents the hierarchical name as a continuing link to > the responsible ASN operator. That link may not remain accurate > throughout the object?s lifetime. > > We've established that the policy is about avoiding inter-RIR > collisions and attesting to who (which AS) published the object.? The > validity of the data is a whole different ballgame and must be > addressed separately.? I have had some ideas on this but my mindset > was mostly around how tooling can use current IRR data to validate the > correctness of AS-SET data - nothing that remotely worked has popped > up, but as mentioned that's independent of this policy. > > For example, what happens if the leading ASN changes holder, is > returned, is reassigned, or receives a new maintainer? Does the > former operator retain control of |AS12345:AS-CUSTOMERS|, does the > new holder inherit it, or is the object suspended? The policy also > permits existing objects to be edited, but does not say whether > changes to maintainers or parent objects trigger renewed > authorisation checks. > > The AS remains, unless the AS gets shut, in which case the objects can > either remain for some time (currently they linger indefinitely, since > we have no way to clean them up now either anyway).? The policy is > thus still a move in the right direction as it will enable us to clean > up in case an AS gets cleaned up.? Stale data again IMHO is a > different independent problem that should be addressed as such. > > Deletion and recreation create a similar problem. If a > hierarchical name is deleted and later recreated, existing filters > or references may silently resolve to a different object using the > same name. The proposal provides no tombstone, reservation, > restoration period, or conflict-state mechanism. > > I don't think this is relevant any more, in part due to the same AS > that would need to recreate, we're already much better off here too, > in that for example if some entity references AS-FOO, then that gets > deleted, an attacker can now currently create AS-FOO.? With this > policy that would be prohibited, and if it was ASxxx:AS-FOO then the > attacker would need to be authoritive for ASxxx to recreate the > object, so again we gain some level of protection. > > These are not questions about whether AS-SET membership is > correct. They concern whether the proposal?s claimed attribution > remains technically true after creation. > > Any new owner of the same ASxxx would be in a position now to clean > that up, compared to previous non-hierarchical objects which would > (and continue to) linger indefinitely.? So this is still an > improvement over current situation even in those cases. > > Before adoption, the policy should define deterministic rules for > changes of ASN control, parent-child delegation, maintainer > replacement, deletion, restoration, and name reuse. Otherwise, > AFRINIC may enforce a hierarchical label while the label no longer > identifies the operator actually controlling the object. > > Whomever manages the parent ASxxx (first ASxxx in the sequence) in the > set is the responsible party, so I don't see how this is relevant. > > A creation-time check is not enough for a claim of continuing > authorisation. > > For that reason, I object to the proposal as presently written. > > Please refer above and advise if that addresses your concerns - I > believe it should. > > Kind regards, > Jaco > > > Regards, > Tshepo > > > _______________________________________________ RPD mailing list > RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Mon Jul 27 10:58:37 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Mon, 27 Jul 2026 12:58:37 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: <6644c92f-8189-4a6c-a642-96f5615e3cb7@uls.co.za> Hi, On 2026/07/27 12:23, Nonjabulo Sphilile wrote: > Dear Jaco, > > Thank you for engaging with the concern. Your reply brings up a > different problem that the Impact Assessment does not address. > > The policy has a future implementation date, while every flat AS-SET > created before that date will remain valid and editable. This creates > a race-to-grandfather risk. A database user could register desirable > or confusing flat names during the transition, leave them empty or > harmless, and populate or alter them after enforcement begins. If you want to pre-emptively aim a shotgun at your own foot there is nothing I or anyone else can do to stop you.? That shotgun would however, now be aimed at YOUR foot, not mine.? Good luck. > > The registry would then reject new flat names, but those > pre-positioned objects would remain active indefinitely. In other > words, the proposal does not necessarily stop new harmful cases going > forward. It stops only one method of creating them after the cut-off > date. New risk could still be introduced through later changes to > grandfathered objects. No one said it does stop all of them, but it will over time close the gap further as those objects are no longer used and (ideally) gets deleted. > > The source-qualified membership restriction you suggest is not part of > this proposal. A possible future policy cannot be counted as > protection delivered by the current text. As per my previously email, this policy is still a step (building block) in the right direction.? We build sky scrapers floor by floor and brick by brick.? This is but one small brick. > > At minimum, the proposal would need an immediate reservation or > cut-off mechanism, an audit of flat objects created during the > implementation period, and clear rules governing material changes to > grandfathered objects. The operational impact of those measures has > not been assessed. No, because existing object may still be valid for a very long time to come.? For now we're just aiming to stop creation of new ones.? All concerns that has been raised is part of the bigger sky-scraper picture and needs to be addressed, but by separate bricks. > > Grandfathered does not mean frozen. Until the active legacy surface > and the transition-period incentive are addressed, I do not believe > the claim that the policy prevents new problem cases has been established. The problem is what does grandfathered mean?? We ourselves have AFRINIC::AS-ULS - which we no longer advertise - but I've found at least one peer still uses that, it simply references AS3287767:AS-ULS it's only member now, which is the best we can do for now.? We can but HOPE that the relevant peer restricts to AFRINIC::AS-ULS rather than AS-ULS.? Does it mean it's a definite attack vector?? No, as per all things, it depends on the specific USE CASE.? Can someone collide with the flat name from another RIR?? Absolutely, but this may or may not be a problem depending on the use-case. Who's allowed to reference my object, or include my AS into their own sets is a discussion for a different policy which does need to be addressed, but that's separate from this specific brick. Kind regards, Jaco From jaco at uls.co.za Mon Jul 27 11:01:08 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Mon, 27 Jul 2026 13:01:08 +0200 Subject: [rpd] : Fw: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: <8df6d233-4073-4731-afeb-19361c0d2a7f@uls.co.za> Hi, On 2026/07/27 12:19, Phetulo Dhlamini wrote: > Dear Jaco, > > As I have been following the discussions very closely, thank you for > taking the time to explain your position. I accept that hierarchical > naming can strengthen creation authorisation within the AFRINIC database. > > I have a different concern, however. The proposal binds an AS-SET name > to an ASN, but it does not bind that name to a particular IRR source. > > For example, AS12345:AS-CUSTOMERS identifies the ASN namespace, but it > does not tell a resolver whether the intended object is from AFRINIC, > RADB, RIPE, or another source. IRR software already recognises that > sets with the same primary key may exist in different sources and may > return them separately. It's implicit since a specific AS is already bound to a specific RIR.? When looking for a hierarchical name a tool first maps the AS to a specific RIR, then queries that RIR for the name, as such if you deploy AS12345:AS-CUSTOMERS to both RIPE and APNIC, only RIPE will ever be queried for it.? And RIPE should block creation of the relevant object since they're not authoritative for the specific AS anyway. Kind regards, Jaco From jaco at uls.co.za Mon Jul 27 11:03:39 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Mon, 27 Jul 2026 13:03:39 +0200 Subject: [rpd] : Fw: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <8df6d233-4073-4731-afeb-19361c0d2a7f@uls.co.za> References: <8df6d233-4073-4731-afeb-19361c0d2a7f@uls.co.za> Message-ID: <33f06c78-97b4-44fb-9429-12ea41c99f62@uls.co.za> Sorry, just a correction, APNIC should block the creation ... but even if they don't since no tool should ever query them for that name ... On 2026/07/27 13:01, Jaco Kroon via RPD wrote: > Hi, > > On 2026/07/27 12:19, Phetulo Dhlamini wrote: >> Dear Jaco, >> >> As I have been following the discussions very closely, thank you for >> taking the time to explain your position. I accept that hierarchical >> naming can strengthen creation authorisation within the AFRINIC >> database. >> >> I have a different concern, however. The proposal binds an AS-SET >> name to an ASN, but it does not bind that name to a particular IRR >> source. >> >> For example, AS12345:AS-CUSTOMERS identifies the ASN namespace, but >> it does not tell a resolver whether the intended object is from >> AFRINIC, RADB, RIPE, or another source. IRR software already >> recognises that sets with the same primary key may exist in different >> sources and may return them separately. > > It's implicit since a specific AS is already bound to a specific RIR.? > When looking for a hierarchical name a tool first maps the AS to a > specific RIR, then queries that RIR for the name, as such if you > deploy AS12345:AS-CUSTOMERS to both RIPE and APNIC, only RIPE will > ever be queried for it.? And RIPE should block creation of the > relevant object since they're not authoritative for the specific AS > anyway. > > Kind regards, > Jaco > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From TshepoMasuku26 at hotmail.com Mon Jul 27 11:11:16 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Mon, 27 Jul 2026 11:11:16 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <101a6aa4-09f5-4377-b9d4-072698dcaf3e@uls.co.za> References: <67f9b36c-c40b-4801-b558-af8968aeead0@uls.co.za> <101a6aa4-09f5-4377-b9d4-072698dcaf3e@uls.co.za> Message-ID: Dear Jaco, Based on your explanation, I think this raises a separate concern about the actual authorisation chain. The statement that the entire ASxxx: namespace simply belongs to the current ASN holder is incomplete. Under RFC 2622, the holder of the ASN controls creation of the first-level set, but deeper objects are created by the maintainer of the immediate parent. For example, the maintainer of AS12345:AS-CUSTOMERS, rather than necessarily the ASN maintainer, controls creation beneath that object. That means control can be delegated through the hierarchy. Consider: AS12345:AS-CUSTOMERS:AS-EU If the parent set is maintained by a customer, contractor, subsidiary, or another operational team, the proposal does not explain whether the current ASN holder may override that maintainer, delete the descendant, or automatically recover control after an ASN transfer. There are two possible outcomes, and both require policy clarity: If all descendants automatically move to the new ASN holder, AFRINIC may be overriding valid delegated maintainers and changing control of routing-policy objects without their approval. If descendants do not move automatically, then the new ASN holder is not necessarily ?plainly able? to clean them up, contrary to the benefit you describe. The proposal defines naming syntax at creation, but it does not define the authorisation graph, delegation rules, revocation process, or how control of nested objects changes. Saying that an operator could simply ask AFRINIC to intervene replaces a deterministic rule with staff discretion. This is not about whether the data are stale or whether the proposal fixes every problem. It is about whether the claimed proof of control remains verifiable at every level of the hierarchy. Before this proceeds, the policy should clearly state who controls each descendant, whether delegation is permitted, how it is withdrawn, and what happens to delegated objects when the leading ASN changes holder. A mandatory common rule should define those state transitions in advance. It should not leave AFRINIC to invent them later. For that reason, my objection remains. Regards, Tshepo ________________________________ From: Jaco Kroon Sent: Monday, 27 July 2026 12:46:55 To: Tshepo Masuku ; rpd at afrinic.net ; pdwg-chairs at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Hi, I believe it does, since the ASxxx:: "namespace" belongs to the AS, the owner of the AS should be perfectly able to clean it up, or at a minimum be "plainly able to request AFRINIC" to perform same. Since it's in the hierarchy of ASxxx any cleanup will plainly affect ASxxx either directly or indirectly, providing them incentive to fix it. As things stand currently, arbitrary parties are permitted to include any AS or AS-SET into their own anyway, so your concern is valid, but not directly related to the ongoing policy proposal. You're now starting to understand the bigger picture (I think) towards which this proposal is but a small step towards resolving. We cannot, and should not aim to, build a castle reaching the sky without first building the foundations. This is foundation building. AS transfer as I understand tranfers te AS object, along with all related objects, thus ownership gets moved to the new AS that has operational authority over the AS. In the case of deletion (return to the RIR) the objects would currently dangle, this would allow them to be deleted - which would definitely create a dangling reference, but prevent that object from being high-jacked by another party, thus already improving even that scenario. Given the prevalence of AS numbers I highly doubt returned AS numbers would be re-used any time soon. And if they are, the new owner should receive ownership of any undeleted but related objects, allowing them to clean things up. Remember: NOTHING currently stops anyone from referencing any one else's AS-SET objects already - so recreating an object that's referenced, or having someone point to your existing object is thus from an operational perspective the same issue. That said - whilst I'm sure AS transfers and deletions happen, I do not think they're a frequent occurrence. Also, none of this is the object of the policy change. Should policies be put into place to deal with that? Most definitely, but we cannot build that sky-scraper in one step, we build it in multiple smaller steps, so that we can break down and retract/take steps back if we've found to have made a mistake, rather than building everything in one go and then having it crash down on us. Floor by floor. Brick by brick. Small steps in the right direction, not leaps and bounds. Kind regards, Jaco On 2026/07/27 11:55, Tshepo Masuku wrote: Dear Jaco, Thank you, but your answer introduces a further problem. You say the policy will allow AFRINIC or a future ASN holder to ?clean up? hierarchical objects. That mechanism does not appear in the policy. The text controls the name only when an object is created. It does not define what happens to child AS-SETs when the leading ASN is returned, transferred, reassigned, suspended, or deleted. This matters because cleanup can itself affect running networks. If AS12345:AS-FOO is referenced by other objects or operator configurations, deleting it creates a dangling reference. If a later holder of AS12345 recreates the same name, an unchanged reference may suddenly resolve to completely different data. The new holder?s ability to ?clean up? the previous holder?s namespace is therefore not automatically a protection. It is a transfer of control whose consequences the proposal does not define. Before adoption, the policy should state whether child names remain permanently reserved, whether they transfer with the ASN, whether existing objects are frozen pending re-authentication, how relying operators are notified, and what conditions apply to restoration or reuse. The undefined exception in section 7.8.7 makes this more serious. If AFRINIC may grant exceptions ?where necessary,? the supposedly closed namespace is not deterministic. The proposal does not say what qualifies as necessary, who decides, or whether an exception may permit another non-hierarchical object. A mandatory rule should define valid state transitions rather than leave them to future registry discretion. The proposal currently promises attribution at creation while leaving later control and name reuse unresolved. For that reason, my concern has not been addressed, and I remain opposed to the proposal as written. Regards, Tshepo ________________________________ From: Jaco Kroon Sent: Monday, July 27, 2026 11:23:30 am To: Tshepo Masuku ; rpd at afrinic.net ; pdwg-chairs at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Hi, On 2026/07/27 08:30, Tshepo Masuku wrote: Dear PDWG, I have a separate concern arising from the Impact Assessment. The proposal validates an AS-SET only when it is created, but the assessment presents the hierarchical name as a continuing link to the responsible ASN operator. That link may not remain accurate throughout the object?s lifetime. We've established that the policy is about avoiding inter-RIR collisions and attesting to who (which AS) published the object. The validity of the data is a whole different ballgame and must be addressed separately. I have had some ideas on this but my mindset was mostly around how tooling can use current IRR data to validate the correctness of AS-SET data - nothing that remotely worked has popped up, but as mentioned that's independent of this policy. For example, what happens if the leading ASN changes holder, is returned, is reassigned, or receives a new maintainer? Does the former operator retain control of AS12345:AS-CUSTOMERS, does the new holder inherit it, or is the object suspended? The policy also permits existing objects to be edited, but does not say whether changes to maintainers or parent objects trigger renewed authorisation checks. The AS remains, unless the AS gets shut, in which case the objects can either remain for some time (currently they linger indefinitely, since we have no way to clean them up now either anyway). The policy is thus still a move in the right direction as it will enable us to clean up in case an AS gets cleaned up. Stale data again IMHO is a different independent problem that should be addressed as such. Deletion and recreation create a similar problem. If a hierarchical name is deleted and later recreated, existing filters or references may silently resolve to a different object using the same name. The proposal provides no tombstone, reservation, restoration period, or conflict-state mechanism. I don't think this is relevant any more, in part due to the same AS that would need to recreate, we're already much better off here too, in that for example if some entity references AS-FOO, then that gets deleted, an attacker can now currently create AS-FOO. With this policy that would be prohibited, and if it was ASxxx:AS-FOO then the attacker would need to be authoritive for ASxxx to recreate the object, so again we gain some level of protection. These are not questions about whether AS-SET membership is correct. They concern whether the proposal?s claimed attribution remains technically true after creation. Any new owner of the same ASxxx would be in a position now to clean that up, compared to previous non-hierarchical objects which would (and continue to) linger indefinitely. So this is still an improvement over current situation even in those cases. Before adoption, the policy should define deterministic rules for changes of ASN control, parent-child delegation, maintainer replacement, deletion, restoration, and name reuse. Otherwise, AFRINIC may enforce a hierarchical label while the label no longer identifies the operator actually controlling the object. Whomever manages the parent ASxxx (first ASxxx in the sequence) in the set is the responsible party, so I don't see how this is relevant. A creation-time check is not enough for a claim of continuing authorisation. For that reason, I object to the proposal as presently written. Please refer above and advise if that addresses your concerns - I believe it should. Kind regards, Jaco Regards, Tshepo _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Mon Jul 27 11:31:54 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Mon, 27 Jul 2026 13:31:54 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <67f9b36c-c40b-4801-b558-af8968aeead0@uls.co.za> <101a6aa4-09f5-4377-b9d4-072698dcaf3e@uls.co.za> Message-ID: <75f128b1-e9dc-4a6a-9261-db41c557977d@uls.co.za> Hi, I'll happily defer to the RFC.? This doesn't in my mind really change anything. Kind regards, Jaco On 2026/07/27 13:11, Tshepo Masuku wrote: > Dear Jaco, > > Based on your explanation, I think this raises a separate concern > about the actual authorisation chain. > > The statement that the entire ASxxx: namespace simply belongs to the > current ASN holder is incomplete. Under RFC 2622, the holder of the > ASN controls creation of the first-level set, but deeper objects are > created by the maintainer of the immediate parent. For example, the > maintainer of AS12345:AS-CUSTOMERS, rather than necessarily the ASN > maintainer, controls creation beneath that object. > > That means control can be delegated through the hierarchy. > > Consider: > > AS12345:AS-CUSTOMERS:AS-EU > > If the parent set is maintained by a customer, contractor, subsidiary, > or another operational team, the proposal does not explain whether the > current ASN holder may override that maintainer, delete the > descendant, or automatically recover control after an ASN transfer. > > There are two possible outcomes, and both require policy clarity: > > If all descendants automatically move to the new ASN holder, AFRINIC > may be overriding valid delegated maintainers and changing control of > routing-policy objects without their approval. > > If descendants do not move automatically, then the new ASN holder is > not necessarily ?plainly able? to clean them up, contrary to the > benefit you describe. > > The proposal defines naming syntax at creation, but it does not define > the authorisation graph, delegation rules, revocation process, or how > control of nested objects changes. Saying that an operator could > simply ask AFRINIC to intervene replaces a deterministic rule with > staff discretion. > > This is not about whether the data are stale or whether the proposal > fixes every problem. It is about whether the claimed proof of control > remains verifiable at every level of the hierarchy. > > Before this proceeds, the policy should clearly state who controls > each descendant, whether delegation is permitted, how it is withdrawn, > and what happens to delegated objects when the leading ASN changes holder. > > A mandatory common rule should define those state transitions in > advance. It should not leave AFRINIC to invent them later. > > For that reason, my objection remains. > > Regards, > Tshepo > > > ------------------------------------------------------------------------ > *From:* Jaco Kroon > *Sent:* Monday, 27 July 2026 12:46:55 > *To:* Tshepo Masuku ; rpd at afrinic.net > ; pdwg-chairs at afrinic.net > *Subject:* Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > Hi, > > I believe it does, since the ASxxx:: "namespace" belongs to the AS, > the owner of the AS should be perfectly able to clean it up, or at a > minimum be "plainly able to request AFRINIC" to perform same. > > Since it's in the hierarchy of ASxxx any cleanup will plainly affect > ASxxx either directly or indirectly, providing them incentive to fix it. > > As things stand currently, arbitrary parties are permitted to include > any AS or AS-SET into their own anyway, so your concern is valid, but > not directly related to the ongoing policy proposal.? You're now > starting to understand the bigger picture (I think) towards which this > proposal is but a small step towards resolving.? We cannot, and should > not aim to, build a castle reaching the sky without first building the > foundations.? This is foundation building. > > AS transfer as I understand tranfers te AS object, along with all > related objects, thus ownership gets moved to the new AS that has > operational authority over the AS. > > In the case of deletion (return to the RIR) the objects would > currently dangle, this would allow them to be deleted - which would > definitely create a dangling reference, but prevent that object from > being high-jacked by another party, thus already improving even that > scenario.? Given the prevalence of AS numbers I highly doubt returned > AS numbers would be re-used any time soon.? And if they are, the new > owner should receive ownership of any undeleted but related objects, > allowing them to clean things up. > > Remember:? NOTHING currently stops anyone from referencing any one > else's AS-SET objects already - so recreating an object that's > referenced, or having someone point to your existing object is thus > from an operational perspective the same issue. > > That said - whilst I'm sure AS transfers and deletions happen, I do > not think they're a frequent occurrence. > > Also, none of this is the object of the policy change. Should policies > be put into place to deal with that?? Most definitely, but we cannot > build that sky-scraper in one step, we build it in multiple smaller > steps, so that we can break down and retract/take steps back if we've > found to have made a mistake, rather than building everything in one > go and then having it crash down on us.? Floor by floor.? Brick by > brick. Small steps in the right direction, not leaps and bounds. > > Kind regards, > Jaco > > On 2026/07/27 11:55, Tshepo Masuku wrote: >> Dear Jaco, >> >> Thank you, but your answer introduces a further problem. >> >> You say the policy will allow AFRINIC or a future ASN holder to >> ?clean up? hierarchical objects. That mechanism does not appear in >> the policy. The text controls the name only when an object is >> created. It does not define what happens to child AS-SETs when the >> leading ASN is returned, transferred, reassigned, suspended, or deleted. >> >> This matters because cleanup can itself affect running networks. If >> AS12345:AS-FOO is referenced by other objects or operator >> configurations, deleting it creates a dangling reference. If a later >> holder of AS12345 recreates the same name, an unchanged reference may >> suddenly resolve to completely different data. >> >> The new holder?s ability to ?clean up? the previous holder?s >> namespace is therefore not automatically a protection. It is a >> transfer of control whose consequences the proposal does not define. >> >> Before adoption, the policy should state whether child names remain >> permanently reserved, whether they transfer with the ASN, whether >> existing objects are frozen pending re-authentication, how relying >> operators are notified, and what conditions apply to restoration or >> reuse. >> >> The undefined exception in section 7.8.7 makes this more serious. If >> AFRINIC may grant exceptions ?where necessary,? the supposedly closed >> namespace is not deterministic. The proposal does not say what >> qualifies as necessary, who decides, or whether an exception may >> permit another non-hierarchical object. >> >> A mandatory rule should define valid state transitions rather than >> leave them to future registry discretion. The proposal currently >> promises attribution at creation while leaving later control and name >> reuse unresolved. >> >> For that reason, my concern has not been addressed, and I remain >> opposed to the proposal as written. >> >> Regards, >> Tshepo >> >> >> ------------------------------------------------------------------------ >> *From:* Jaco Kroon >> *Sent:* Monday, July 27, 2026 11:23:30 am >> *To:* Tshepo Masuku >> ; rpd at afrinic.net >> ; >> pdwg-chairs at afrinic.net >> >> *Subject:* Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> >> Hi, >> >> On 2026/07/27 08:30, Tshepo Masuku wrote: >> >> Dear PDWG, >> >> I have a separate concern arising from the Impact Assessment. >> >> The proposal validates an AS-SET only when it is created, but the >> assessment presents the hierarchical name as a continuing link to >> the responsible ASN operator. That link may not remain accurate >> throughout the object?s lifetime. >> >> We've established that the policy is about avoiding inter-RIR >> collisions and attesting to who (which AS) published the object.? The >> validity of the data is a whole different ballgame and must be >> addressed separately.? I have had some ideas on this but my mindset >> was mostly around how tooling can use current IRR data to validate >> the correctness of AS-SET data - nothing that remotely worked has >> popped up, but as mentioned that's independent of this policy. >> >> For example, what happens if the leading ASN changes holder, is >> returned, is reassigned, or receives a new maintainer? Does the >> former operator retain control of |AS12345:AS-CUSTOMERS|, does >> the new holder inherit it, or is the object suspended? The policy >> also permits existing objects to be edited, but does not say >> whether changes to maintainers or parent objects trigger renewed >> authorisation checks. >> >> The AS remains, unless the AS gets shut, in which case the objects >> can either remain for some time (currently they linger indefinitely, >> since we have no way to clean them up now either anyway).? The policy >> is thus still a move in the right direction as it will enable us to >> clean up in case an AS gets cleaned up.? Stale data again IMHO is a >> different independent problem that should be addressed as such. >> >> Deletion and recreation create a similar problem. If a >> hierarchical name is deleted and later recreated, existing >> filters or references may silently resolve to a different object >> using the same name. The proposal provides no tombstone, >> reservation, restoration period, or conflict-state mechanism. >> >> I don't think this is relevant any more, in part due to the same AS >> that would need to recreate, we're already much better off here too, >> in that for example if some entity references AS-FOO, then that gets >> deleted, an attacker can now currently create AS-FOO.? With this >> policy that would be prohibited, and if it was ASxxx:AS-FOO then the >> attacker would need to be authoritive for ASxxx to recreate the >> object, so again we gain some level of protection. >> >> These are not questions about whether AS-SET membership is >> correct. They concern whether the proposal?s claimed attribution >> remains technically true after creation. >> >> Any new owner of the same ASxxx would be in a position now to clean >> that up, compared to previous non-hierarchical objects which would >> (and continue to) linger indefinitely. So this is still an >> improvement over current situation even in those cases. >> >> Before adoption, the policy should define deterministic rules for >> changes of ASN control, parent-child delegation, maintainer >> replacement, deletion, restoration, and name reuse. Otherwise, >> AFRINIC may enforce a hierarchical label while the label no >> longer identifies the operator actually controlling the object. >> >> Whomever manages the parent ASxxx (first ASxxx in the sequence) in >> the set is the responsible party, so I don't see how this is relevant. >> >> A creation-time check is not enough for a claim of continuing >> authorisation. >> >> For that reason, I object to the proposal as presently written. >> >> Please refer above and advise if that addresses your concerns - I >> believe it should. >> >> Kind regards, >> Jaco >> >> >> Regards, >> Tshepo >> >> >> _______________________________________________ RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd >> >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Mon Jul 27 11:50:00 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Mon, 27 Jul 2026 11:50:00 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <75f128b1-e9dc-4a6a-9261-db41c557977d@uls.co.za> References: <67f9b36c-c40b-4801-b558-af8968aeead0@uls.co.za> <101a6aa4-09f5-4377-b9d4-072698dcaf3e@uls.co.za> <75f128b1-e9dc-4a6a-9261-db41c557977d@uls.co.za> Message-ID: Dear Jaco, It changes the issue materially. Your earlier argument depended on the current ASN holder controlling the entire ASxxx: namespace. If RFC 2622 gives control of deeper names to the immediate parent maintainer, then authority may be delegated and may not automatically follow the ASN during transfer or reassignment. The policy text and Impact Assessment should therefore define the actual authorisation chain, rather than leave AFRINIC to interpret it after adoption. A mandatory rule cannot claim deterministic proof of control while its control model remains unspecified. Until that is clarified, my concern remains and I continue to object. Regards, Tshepo ________________________________ From: Jaco Kroon Sent: Monday, 27 July 2026 13:31:54 To: Tshepo Masuku ; rpd at afrinic.net ; pdwg-chairs at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Hi, I'll happily defer to the RFC. This doesn't in my mind really change anything. Kind regards, Jaco On 2026/07/27 13:11, Tshepo Masuku wrote: Dear Jaco, Based on your explanation, I think this raises a separate concern about the actual authorisation chain. The statement that the entire ASxxx: namespace simply belongs to the current ASN holder is incomplete. Under RFC 2622, the holder of the ASN controls creation of the first-level set, but deeper objects are created by the maintainer of the immediate parent. For example, the maintainer of AS12345:AS-CUSTOMERS, rather than necessarily the ASN maintainer, controls creation beneath that object. That means control can be delegated through the hierarchy. Consider: AS12345:AS-CUSTOMERS:AS-EU If the parent set is maintained by a customer, contractor, subsidiary, or another operational team, the proposal does not explain whether the current ASN holder may override that maintainer, delete the descendant, or automatically recover control after an ASN transfer. There are two possible outcomes, and both require policy clarity: If all descendants automatically move to the new ASN holder, AFRINIC may be overriding valid delegated maintainers and changing control of routing-policy objects without their approval. If descendants do not move automatically, then the new ASN holder is not necessarily ?plainly able? to clean them up, contrary to the benefit you describe. The proposal defines naming syntax at creation, but it does not define the authorisation graph, delegation rules, revocation process, or how control of nested objects changes. Saying that an operator could simply ask AFRINIC to intervene replaces a deterministic rule with staff discretion. This is not about whether the data are stale or whether the proposal fixes every problem. It is about whether the claimed proof of control remains verifiable at every level of the hierarchy. Before this proceeds, the policy should clearly state who controls each descendant, whether delegation is permitted, how it is withdrawn, and what happens to delegated objects when the leading ASN changes holder. A mandatory common rule should define those state transitions in advance. It should not leave AFRINIC to invent them later. For that reason, my objection remains. Regards, Tshepo ________________________________ From: Jaco Kroon Sent: Monday, 27 July 2026 12:46:55 To: Tshepo Masuku ; rpd at afrinic.net ; pdwg-chairs at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Hi, I believe it does, since the ASxxx:: "namespace" belongs to the AS, the owner of the AS should be perfectly able to clean it up, or at a minimum be "plainly able to request AFRINIC" to perform same. Since it's in the hierarchy of ASxxx any cleanup will plainly affect ASxxx either directly or indirectly, providing them incentive to fix it. As things stand currently, arbitrary parties are permitted to include any AS or AS-SET into their own anyway, so your concern is valid, but not directly related to the ongoing policy proposal. You're now starting to understand the bigger picture (I think) towards which this proposal is but a small step towards resolving. We cannot, and should not aim to, build a castle reaching the sky without first building the foundations. This is foundation building. AS transfer as I understand tranfers te AS object, along with all related objects, thus ownership gets moved to the new AS that has operational authority over the AS. In the case of deletion (return to the RIR) the objects would currently dangle, this would allow them to be deleted - which would definitely create a dangling reference, but prevent that object from being high-jacked by another party, thus already improving even that scenario. Given the prevalence of AS numbers I highly doubt returned AS numbers would be re-used any time soon. And if they are, the new owner should receive ownership of any undeleted but related objects, allowing them to clean things up. Remember: NOTHING currently stops anyone from referencing any one else's AS-SET objects already - so recreating an object that's referenced, or having someone point to your existing object is thus from an operational perspective the same issue. That said - whilst I'm sure AS transfers and deletions happen, I do not think they're a frequent occurrence. Also, none of this is the object of the policy change. Should policies be put into place to deal with that? Most definitely, but we cannot build that sky-scraper in one step, we build it in multiple smaller steps, so that we can break down and retract/take steps back if we've found to have made a mistake, rather than building everything in one go and then having it crash down on us. Floor by floor. Brick by brick. Small steps in the right direction, not leaps and bounds. Kind regards, Jaco On 2026/07/27 11:55, Tshepo Masuku wrote: Dear Jaco, Thank you, but your answer introduces a further problem. You say the policy will allow AFRINIC or a future ASN holder to ?clean up? hierarchical objects. That mechanism does not appear in the policy. The text controls the name only when an object is created. It does not define what happens to child AS-SETs when the leading ASN is returned, transferred, reassigned, suspended, or deleted. This matters because cleanup can itself affect running networks. If AS12345:AS-FOO is referenced by other objects or operator configurations, deleting it creates a dangling reference. If a later holder of AS12345 recreates the same name, an unchanged reference may suddenly resolve to completely different data. The new holder?s ability to ?clean up? the previous holder?s namespace is therefore not automatically a protection. It is a transfer of control whose consequences the proposal does not define. Before adoption, the policy should state whether child names remain permanently reserved, whether they transfer with the ASN, whether existing objects are frozen pending re-authentication, how relying operators are notified, and what conditions apply to restoration or reuse. The undefined exception in section 7.8.7 makes this more serious. If AFRINIC may grant exceptions ?where necessary,? the supposedly closed namespace is not deterministic. The proposal does not say what qualifies as necessary, who decides, or whether an exception may permit another non-hierarchical object. A mandatory rule should define valid state transitions rather than leave them to future registry discretion. The proposal currently promises attribution at creation while leaving later control and name reuse unresolved. For that reason, my concern has not been addressed, and I remain opposed to the proposal as written. Regards, Tshepo ________________________________ From: Jaco Kroon Sent: Monday, July 27, 2026 11:23:30 am To: Tshepo Masuku ; rpd at afrinic.net ; pdwg-chairs at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Hi, On 2026/07/27 08:30, Tshepo Masuku wrote: Dear PDWG, I have a separate concern arising from the Impact Assessment. The proposal validates an AS-SET only when it is created, but the assessment presents the hierarchical name as a continuing link to the responsible ASN operator. That link may not remain accurate throughout the object?s lifetime. We've established that the policy is about avoiding inter-RIR collisions and attesting to who (which AS) published the object. The validity of the data is a whole different ballgame and must be addressed separately. I have had some ideas on this but my mindset was mostly around how tooling can use current IRR data to validate the correctness of AS-SET data - nothing that remotely worked has popped up, but as mentioned that's independent of this policy. For example, what happens if the leading ASN changes holder, is returned, is reassigned, or receives a new maintainer? Does the former operator retain control of AS12345:AS-CUSTOMERS, does the new holder inherit it, or is the object suspended? The policy also permits existing objects to be edited, but does not say whether changes to maintainers or parent objects trigger renewed authorisation checks. The AS remains, unless the AS gets shut, in which case the objects can either remain for some time (currently they linger indefinitely, since we have no way to clean them up now either anyway). The policy is thus still a move in the right direction as it will enable us to clean up in case an AS gets cleaned up. Stale data again IMHO is a different independent problem that should be addressed as such. Deletion and recreation create a similar problem. If a hierarchical name is deleted and later recreated, existing filters or references may silently resolve to a different object using the same name. The proposal provides no tombstone, reservation, restoration period, or conflict-state mechanism. I don't think this is relevant any more, in part due to the same AS that would need to recreate, we're already much better off here too, in that for example if some entity references AS-FOO, then that gets deleted, an attacker can now currently create AS-FOO. With this policy that would be prohibited, and if it was ASxxx:AS-FOO then the attacker would need to be authoritive for ASxxx to recreate the object, so again we gain some level of protection. These are not questions about whether AS-SET membership is correct. They concern whether the proposal?s claimed attribution remains technically true after creation. Any new owner of the same ASxxx would be in a position now to clean that up, compared to previous non-hierarchical objects which would (and continue to) linger indefinitely. So this is still an improvement over current situation even in those cases. Before adoption, the policy should define deterministic rules for changes of ASN control, parent-child delegation, maintainer replacement, deletion, restoration, and name reuse. Otherwise, AFRINIC may enforce a hierarchical label while the label no longer identifies the operator actually controlling the object. Whomever manages the parent ASxxx (first ASxxx in the sequence) in the set is the responsible party, so I don't see how this is relevant. A creation-time check is not enough for a claim of continuing authorisation. For that reason, I object to the proposal as presently written. Please refer above and advise if that addresses your concerns - I believe it should. Kind regards, Jaco Regards, Tshepo _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.medoye at gmail.com Mon Jul 27 12:24:48 2026 From: daniel.medoye at gmail.com (Taye Medoye) Date: Mon, 27 Jul 2026 14:24:48 +0200 Subject: [rpd] Subject: Fw: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear PDWG, I have a separate concern regarding the ASN used as the hierarchical anchor. The proposal assumes that placing an ASN at the beginning of an AS-SET name makes the object globally unique and attributable to a specific resource holder. However, the proposed text only requires the first element to ?consist of an ASN.? It does not expressly require that ASN to be globally assigned, present in the authoritative AFRINIC database, or successfully authenticated at creation. That distinction matters because not every syntactically valid ASN identifies a unique operator. Private-use ASNs are deliberately not globally unique. Special-purpose, documentation, reserved, and unallocated ASNs likewise do not provide the holder attribution on which the proposal?s justification depends. RFC 6996, for example, reserves AS64512?AS65534 and AS4200000000?AS4294967294 for private use. The policy should therefore state explicitly that: the leading ASN must be a globally assigned ASN with an authoritative aut-num object in the AFRINIC database; creation must successfully authenticate against that object?s authorised maintainer; private-use, reserved, documentation-only, special-purpose, and unallocated ASNs must not be accepted as namespace anchors; and the ASN must use the canonical ASPLAIN representation defined by RFC 5396. This cannot safely be left to unspecified implementation behaviour. IRRd supports different authentication modes, including an opportunistic mode under which the check may pass when the corresponding aut-num object does not exist. The Impact Assessment does not identify which mode AFRINIC will use or define the required failure behaviour across WHOIS, MyAFRINIC, and API creation paths. Without these safeguards, an AS-SET may satisfy the proposed naming syntax while failing the very uniqueness and proof-of-control properties used to justify the policy. I therefore object to the proposal as currently written, and request that the ASN eligibility and authentication requirements be made deterministic before the proposal advances. Regards, Taye. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thulisile.mazomba at gmail.com Mon Jul 27 12:44:49 2026 From: thulisile.mazomba at gmail.com (Thulisile Mazomba) Date: Mon, 27 Jul 2026 14:44:49 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: Dear PDWG, I have reviewed the Impact Assessment. I accept the narrow point that ASN-anchored naming can reduce future flat-name collisions for newly created AFRINIC AS-SETs. My objection remains because the assessment exposes several unresolved implementation issues. First, section 7.8.7 permits exceptions ?where necessary? but defines no criteria, decision-maker, review mechanism, or limit on what may be excepted. Staff then refers to an exception in 7.8.6 involving restoration of deleted objects, although the supplied 7.8.6 concerns editing existing objects. The assessment nevertheless records no ambiguity. This needs clarification before implementation. If exceptions allow future flat-name creation, the namespace is not prospectively closed. If the intention is only to restore accidentally deleted legacy objects, the text should define the recovery period, proof of prior control, eligible maintainer, audit record, and whether the old name remains reserved after deletion. Second, the assessment says that only the leading ASN operator can create names beginning with that ASN. RFC 2622 appears more specific: deeper namespace control follows the immediate parent object. The policy should therefore state whether nested objects are authorised by the leading ASN maintainer or the parent AS-SET maintainer, whether the parent must already exist, and whether that authority may be delegated. Third, the claimed benefit should be stated accurately. Existing flat objects remain untouched, and mirroring and resolver behaviour are expressly outside scope. The proposal may reduce future AFRINIC-originated collisions, but it does not resolve existing cross-IRR ambiguity or establish global uniqueness across all resolver contexts. Finally, the assessment provides no operational baseline, warning phase, test vectors, measurable success criteria, rollback plan, or scheduled review. Before mandatory rejection is enabled, AFRINIC should run the validation in warning-only mode, publish the number of affected creation attempts and automation failures, and provide a complete implementation and recovery plan. These are not demands for a perfect solution. They are necessary questions about the precise rule AFRINIC will enforce and the scope of the result it claims. Until the exception, authorisation chain, implementation method, and review criteria are clearly resolved, I remain opposed to advancing the proposal as written. Regards, Thulisile On Mon, Jul 27, 2026 at 1:51?PM wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Tshepo Masuku) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 27 Jul 2026 11:50:00 +0000 > From: Tshepo Masuku > To: Jaco Kroon , "rpd at afrinic.net" , > "pdwg-chairs at afrinic.net" > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > < > DB7PR04MB5993E4EA2B38B28EDF0F96BACACC2 at DB7PR04MB5993.eurprd04.prod.outlook.com > > > > Content-Type: text/plain; charset="windows-1252" > > > Dear Jaco, > > It changes the issue materially. > > Your earlier argument depended on the current ASN holder controlling the > entire ASxxx: namespace. If RFC 2622 gives control of deeper names to the > immediate parent maintainer, then authority may be delegated and may not > automatically follow the ASN during transfer or reassignment. > > The policy text and Impact Assessment should therefore define the actual > authorisation chain, rather than leave AFRINIC to interpret it after > adoption. A mandatory rule cannot claim deterministic proof of control > while its control model remains unspecified. > > Until that is clarified, my concern remains and I continue to object. > > Regards, > Tshepo > > ________________________________ > From: Jaco Kroon > Sent: Monday, 27 July 2026 13:31:54 > To: Tshepo Masuku ; rpd at afrinic.net < > rpd at afrinic.net>; pdwg-chairs at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > > Hi, > > I'll happily defer to the RFC. This doesn't in my mind really change > anything. > > Kind regards, > Jaco > > On 2026/07/27 13:11, Tshepo Masuku wrote: > Dear Jaco, > > Based on your explanation, I think this raises a separate concern about > the actual authorisation chain. > > The statement that the entire ASxxx: namespace simply belongs to the > current ASN holder is incomplete. Under RFC 2622, the holder of the ASN > controls creation of the first-level set, but deeper objects are created by > the maintainer of the immediate parent. For example, the maintainer of > AS12345:AS-CUSTOMERS, rather than necessarily the ASN maintainer, controls > creation beneath that object. > > That means control can be delegated through the hierarchy. > > Consider: > > AS12345:AS-CUSTOMERS:AS-EU > > If the parent set is maintained by a customer, contractor, subsidiary, or > another operational team, the proposal does not explain whether the current > ASN holder may override that maintainer, delete the descendant, or > automatically recover control after an ASN transfer. > > There are two possible outcomes, and both require policy clarity: > > If all descendants automatically move to the new ASN holder, AFRINIC may > be overriding valid delegated maintainers and changing control of > routing-policy objects without their approval. > > If descendants do not move automatically, then the new ASN holder is not > necessarily ?plainly able? to clean them up, contrary to the benefit you > describe. > > The proposal defines naming syntax at creation, but it does not define the > authorisation graph, delegation rules, revocation process, or how control > of nested objects changes. Saying that an operator could simply ask AFRINIC > to intervene replaces a deterministic rule with staff discretion. > > This is not about whether the data are stale or whether the proposal fixes > every problem. It is about whether the claimed proof of control remains > verifiable at every level of the hierarchy. > > Before this proceeds, the policy should clearly state who controls each > descendant, whether delegation is permitted, how it is withdrawn, and what > happens to delegated objects when the leading ASN changes holder. > > A mandatory common rule should define those state transitions in advance. > It should not leave AFRINIC to invent them later. > > For that reason, my objection remains. > > Regards, > Tshepo > > > ________________________________ > From: Jaco Kroon > Sent: Monday, 27 July 2026 12:46:55 > To: Tshepo Masuku TshepoMasuku26 at hotmail.com>; rpd at afrinic.net < > rpd at afrinic.net>; pdwg-chairs at afrinic.net pdwg-chairs at afrinic.net> pdwg-chairs at afrinic.net> > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > > Hi, > > I believe it does, since the ASxxx:: "namespace" belongs to the AS, the > owner of the AS should be perfectly able to clean it up, or at a minimum be > "plainly able to request AFRINIC" to perform same. > > Since it's in the hierarchy of ASxxx any cleanup will plainly affect ASxxx > either directly or indirectly, providing them incentive to fix it. > > As things stand currently, arbitrary parties are permitted to include any > AS or AS-SET into their own anyway, so your concern is valid, but not > directly related to the ongoing policy proposal. You're now starting to > understand the bigger picture (I think) towards which this proposal is but > a small step towards resolving. We cannot, and should not aim to, build a > castle reaching the sky without first building the foundations. This is > foundation building. > > AS transfer as I understand tranfers te AS object, along with all related > objects, thus ownership gets moved to the new AS that has operational > authority over the AS. > > In the case of deletion (return to the RIR) the objects would currently > dangle, this would allow them to be deleted - which would definitely create > a dangling reference, but prevent that object from being high-jacked by > another party, thus already improving even that scenario. Given the > prevalence of AS numbers I highly doubt returned AS numbers would be > re-used any time soon. And if they are, the new owner should receive > ownership of any undeleted but related objects, allowing them to clean > things up. > > Remember: NOTHING currently stops anyone from referencing any one else's > AS-SET objects already - so recreating an object that's referenced, or > having someone point to your existing object is thus from an operational > perspective the same issue. > > That said - whilst I'm sure AS transfers and deletions happen, I do not > think they're a frequent occurrence. > > Also, none of this is the object of the policy change. Should policies be > put into place to deal with that? Most definitely, but we cannot build > that sky-scraper in one step, we build it in multiple smaller steps, so > that we can break down and retract/take steps back if we've found to have > made a mistake, rather than building everything in one go and then having > it crash down on us. Floor by floor. Brick by brick. Small steps in the > right direction, not leaps and bounds. > > Kind regards, > Jaco > > On 2026/07/27 11:55, Tshepo Masuku wrote: > Dear Jaco, > > Thank you, but your answer introduces a further problem. > > You say the policy will allow AFRINIC or a future ASN holder to ?clean up? > hierarchical objects. That mechanism does not appear in the policy. The > text controls the name only when an object is created. It does not define > what happens to child AS-SETs when the leading ASN is returned, > transferred, reassigned, suspended, or deleted. > > This matters because cleanup can itself affect running networks. If > AS12345:AS-FOO is referenced by other objects or operator configurations, > deleting it creates a dangling reference. If a later holder of AS12345 > recreates the same name, an unchanged reference may suddenly resolve to > completely different data. > > The new holder?s ability to ?clean up? the previous holder?s namespace is > therefore not automatically a protection. It is a transfer of control whose > consequences the proposal does not define. > > Before adoption, the policy should state whether child names remain > permanently reserved, whether they transfer with the ASN, whether existing > objects are frozen pending re-authentication, how relying operators are > notified, and what conditions apply to restoration or reuse. > > The undefined exception in section 7.8.7 makes this more serious. If > AFRINIC may grant exceptions ?where necessary,? the supposedly closed > namespace is not deterministic. The proposal does not say what qualifies as > necessary, who decides, or whether an exception may permit another > non-hierarchical object. > > A mandatory rule should define valid state transitions rather than leave > them to future registry discretion. The proposal currently promises > attribution at creation while leaving later control and name reuse > unresolved. > > For that reason, my concern has not been addressed, and I remain opposed > to the proposal as written. > > Regards, > Tshepo > > > ________________________________ > From: Jaco Kroon > Sent: Monday, July 27, 2026 11:23:30 am > To: Tshepo Masuku TshepoMasuku26 at hotmail.com>; rpd at afrinic.net < > rpd at afrinic.net>; pdwg-chairs at afrinic.net pdwg-chairs at afrinic.net> pdwg-chairs at afrinic.net> > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > > Hi, > > On 2026/07/27 08:30, Tshepo Masuku wrote: > > Dear PDWG, > > I have a separate concern arising from the Impact Assessment. > > The proposal validates an AS-SET only when it is created, but the > assessment presents the hierarchical name as a continuing link to the > responsible ASN operator. That link may not remain accurate throughout the > object?s lifetime. > > We've established that the policy is about avoiding inter-RIR collisions > and attesting to who (which AS) published the object. The validity of the > data is a whole different ballgame and must be addressed separately. I > have had some ideas on this but my mindset was mostly around how tooling > can use current IRR data to validate the correctness of AS-SET data - > nothing that remotely worked has popped up, but as mentioned that's > independent of this policy. > > For example, what happens if the leading ASN changes holder, is returned, > is reassigned, or receives a new maintainer? Does the former operator > retain control of AS12345:AS-CUSTOMERS, does the new holder inherit it, or > is the object suspended? The policy also permits existing objects to be > edited, but does not say whether changes to maintainers or parent objects > trigger renewed authorisation checks. > > The AS remains, unless the AS gets shut, in which case the objects can > either remain for some time (currently they linger indefinitely, since we > have no way to clean them up now either anyway). The policy is thus still > a move in the right direction as it will enable us to clean up in case an > AS gets cleaned up. Stale data again IMHO is a different independent > problem that should be addressed as such. > > Deletion and recreation create a similar problem. If a hierarchical name > is deleted and later recreated, existing filters or references may silently > resolve to a different object using the same name. The proposal provides no > tombstone, reservation, restoration period, or conflict-state mechanism. > > I don't think this is relevant any more, in part due to the same AS that > would need to recreate, we're already much better off here too, in that for > example if some entity references AS-FOO, then that gets deleted, an > attacker can now currently create AS-FOO. With this policy that would be > prohibited, and if it was ASxxx:AS-FOO then the attacker would need to be > authoritive for ASxxx to recreate the object, so again we gain some level > of protection. > > These are not questions about whether AS-SET membership is correct. They > concern whether the proposal?s claimed attribution remains technically true > after creation. > > Any new owner of the same ASxxx would be in a position now to clean that > up, compared to previous non-hierarchical objects which would (and continue > to) linger indefinitely. So this is still an improvement over current > situation even in those cases. > > Before adoption, the policy should define deterministic rules for changes > of ASN control, parent-child delegation, maintainer replacement, deletion, > restoration, and name reuse. Otherwise, AFRINIC may enforce a hierarchical > label while the label no longer identifies the operator actually > controlling the object. > > Whomever manages the parent ASxxx (first ASxxx in the sequence) in the set > is the responsible party, so I don't see how this is relevant. > > A creation-time check is not enough for a claim of continuing > authorisation. > > For that reason, I object to the proposal as presently written. > > Please refer above and advise if that addresses your concerns - I believe > it should. > > Kind regards, > Jaco > > > Regards, > Tshepo > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260727/cb12d92b/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 212 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aalain at trstech.net Mon Jul 27 13:01:53 2026 From: aalain at trstech.net (ALAIN AINA) Date: Mon, 27 Jul 2026 13:01:53 +0000 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavior on AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: <1784639031075.56443@tra.gov.eg> References: <1784639031075.56443@tra.gov.eg> Message-ID: <04D11A79-C491-49B2-9ADD-DA3AE0A41E29@trstech.net> Hi PDWG, > On 21 Jul 2026, at 13:03, Hytham El-Nakhal wrote: > > Dear PDWG, > > [??.] > > The AF-37 PPM minutes can be accessed here : https://docs.google.com/document/d/1RS9bYBb9-8uQxLb4u8LpvEUw1jZSfei5mLj01l2LS1s/edit?usp=sharing > The recent discussions during Last Calls and the various attempts to contain the excesses of those exchanges have made one point clear: our Working Group and the PDP it serves need to be updated. We require clearer definitions of roles, responsibilities, and process expectations. Without this, polarization will deepen and ad?hoc tools will continue to proliferate. Participation in this WG must remain grounded in arguments, not in the source address of the participant. In the RIR context, contributions come from two broad groups speaking in their personal capacity: 1. registered contacts of resource members, and 2. any other interested parties. Both groups must be treated equally, and their arguments evaluated on merit. Our path to rough consensus must remain focused on addressing issues not on counting supporters or opponents. Consensus is built by resolving concerns, not by tallying positions. The Last Call stage should reflect this. A Last Call should: ? list the issues raised during discussions, ? explain how each issue was addressed, ? identify any open issues, and ? justify why the proposal is ready to move forward. A Last Call should not solicit support or opposition. Instead, it should invite: ? new issues that were not previously considered, or ? new perspectives on how addressed issues were resolved. Let us work together to provide AFRINIC with a predictable PDP, clear co?chairs mandates, and the tools needed to manage discussions effectively and fairly. HTH ?Alain( Co-author of the PDP WG guidelines proposal) From hvisage at hevis.co.za Mon Jul 27 13:11:31 2026 From: hvisage at hevis.co.za (hvisage at hevis.co.za) Date: Mon, 27 Jul 2026 15:11:31 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: <3D148AE6-C8EF-4C22-A732-779C362791CB@hevis.co.za> Good day Tshepo, Nonjabulo, Phetulo, Taye, Thulisile, colleagues, Apologies to the human readers for this voluminous post, but I?d rather address as much in one email than to flood the mailing list With even more messages as I?d rather do a digest type response for all the similar objections at once. For nearly two weeks we have been asking for technical substance; today, in the week Last Call closes, technical reasons have at last been presented. Before I respond to them, let me add a seventh question to the six of 23 July (015344): Question 7: could you please provide the technical issues, difficulties, and real-world examples where implementation of this draft policy - as three RIRs have already implemented it, and the fourth is formally proposing - would negatively affect your current or future operations? We would like to understand those too. Operational evidence of that kind would genuinely add to the body of knowledge on this proposal. Note: numbers like (015344) are message IDs in the RPD archive - prepend https://lists.afrinic.net/pipermail/rpd/2026/ and append .html to read any of them. So let's get to the objections we have been waiting two weeks for: 1) object lifecycle under changes of ASN control (015387, escalated in 015391 and 015400) - answered by Jaco in (015388) and (015394) 1b) its delegated-maintainer extension (015398, pressed again in 015400) - Jaco deferred to the RFC in (015399); the deferral is completed in section 1 below 2) recursive expansion of members: references (015389) - answered in (015390) 3) grandfathered flat objects (015392) - answered in (015395) 4) multi-source name resolution (015393) - answered in (015396, 015397) 5) anchor-ASN eligibility and authentication (015401) - addressed in section 5 below 6) implementation rollout process (015402) - addressed in section 6 below; its delegation and 7.8.7 points are answered in section 1 (the delegation question is 015398/015400 returning), and its benefit-scope point in the common ground just below I refer to and endorse Jaco's answers rather than repeat them. It was asked earlier in this Last Call that objections be addressed as grouped issues rather than piecemeal, and in that spirit I have collated the responses in a single email, adding what has not yet been shared: a precise statement of the authorisation model, the published data, and the cross-registry record. First, the common ground, because it is substantial. In today's own words: - hierarchical naming "can strengthen creation authorisation" (015393) - the proposal "secures the first object name" (015389) - the concerns are "not questions about whether AS-SET membership is correct" (015387) - ASN-anchored naming "can reduce future flat-name collisions" (015402) None of today's messages disputes what the proposal does. Each of today's objections asks it to also solve an adjacent problem - * lifecycle * delegation semantics * expansion semantics * legacy objects * mirror copies * anchor eligibility - and every one of those problems exists today, everywhere, with or without this policy. That is not the discovery of a defect. It is the discovery that the proposal has a scope, which it states and which was put on this record weeks ago (015119, 015120, 015123; and the draft's own sections 7.8.3-7.8.6). 1. The authorisation model, changes of ASN control, and delegation (015387, 015391, 015398, 015400, 015402) Jaco deferred to the RFC on the depth mechanics (015399). Rightly so - the RFC, followed to the top of the chain, completes his answer. (015398) states the rule correctly: a first-level object, AS12345:AS-CUSTOMERS, is created under the authorisation of the aut-num AS12345 as it stands at that moment - its maintainer chain, which follows the current registered holder. A deeper object, AS12345:AS-CUSTOMERS:AS-EU, is created under the authorisation of the maintainer of its immediate parent. Now ask where that parent came from: its own creation was authorised by the level above it, and so on, terminating at the aut-num itself. Every object in the tree exists because the level above authorised its creation. Delegation, where it exists, exists because the chain authorised it. And who controls each level is answerable, level by level, from the database as it stands - which is what verifiable control looks like in RPSL. The emphatic difference at the current state is that a flat name offers just a maintainer but no chain: no root, and no way to ask whether the name was ever anyone's to create - beyond that it must not already exist in THIS one database. (015400) concludes that because deeper control can be delegated, the "control model remains unspecified". The opposite is the case: the control model is fully specified - in the very RFC that (015398) cited, which is why deferring to it was the right answer. That deeper authority is delegated, and that delegated authority does not automatically follow the ASN, is not a gap in the model; it is the model, working as designed for twenty-seven years, for every hierarchical object family, at every RPSL-based registry. A policy does not "leave AFRINIC to interpret" what the RFC and the production database already define - any more than this proposal needs to restate what mnt-by means. What deterministically follows the ASN is the root of every chain: authority over creation and recreation at the first level of the namespace. That is precisely - and only - what the proposal's attribution claim covers. The same depth question returns in (015402); the answer above stands. These semantics are not invented by this proposal. They are RFC 2622 (1999), operated by RPSL-based registries - AFRINIC's included - for twenty-seven years. The proposal does not modify them; it gates which names may come into existence, nothing else. The two outcomes (015398) poses are therefore both answered by the semantics already in production: descendants do not move automatically, so no delegated maintainer is overridden - exactly as for every delegated object today. And the new holder gains precisely what the name anchors: authority over creation and recreation at the first level of its namespace. What the new holder does not get - control over objects a previous holder's delegates still maintain - is what nobody has today under flat names, for any object, ever. A stale delegated descendant is today's universal condition; the proposal neither creates nor worsens it, and no registry in those twenty-seven years has defined the demanded delegation-and-revocation regime for set objects in policy. How ASN control actually changes in this region is likewise not a matter for speculation. AFRINIC publishes it: https://ftp.afrinic.net/pub/stats/afrinic/transfers/transfers_latest.json A full read of that file today: 75 ASN-carrying transfer events (91 ASNs) from 2018 through 2026 - about nine such events a year - and every single one is a merger/acquisition succession, in which the organisation and its maintainer control pass together, so parent ASN and child objects move as one unit. That is the published record behind Jaco's description in (015394), with the frequency question answered exactly: none open-market, all successions that preserve the attribution chain by construction. Anyone can verify this from the file. So the concern of (015391) has been addressed - with our registry's own data. The cross-registry record answers the rest. I checked this week, across the policy, procedural and database-documentation layers of the other four RIRs. RIPE has required hierarchical names for new as-sets since December 2022 and operates full ASN transfers, including inter-RIR; APNIC likewise since July 2023 (prop-151); LACNIC's IRR has been structurally hierarchical since it launched in 2020; at ARIN hierarchical naming is available today and a mandate for new objects is formally proposed (ARIN-prop-342, pending) - the same direction. All four are silent on child as-set lifecycle at every layer. Across the deployed implementations that is roughly three and a half years of exactly the coexistence (015387) warns about - hierarchical mandates running over live ASN transfer markets - and I could not find one documented incident of the failure mode described. In every deployed implementation, lifecycle lives where it belongs: in standard RPSL authorisation and registry operations, not in naming-policy text. On 7.8.7 (015391, 015402): today the namespace has no rule at all - every creation, by anyone, of any name, is the exception. A closed default with documented-reason exceptions cannot be less deterministic than no default whatsoever. And credit where due: (015402) makes one point that verifies - the staff assessment's prose cites "7.8.6" for the restoration-of-deleted-objects exception, where 7.8.6 concerns editing and the exception clause is in fact 7.8.7. That is a cross-reference slip in the assessment's commentary, worth an erratum, and it changes nothing in the policy text: the clauses say what they say, and staff's own recorded caution about recall loopholes shows the right mechanism was analysed. As for the demanded exception criteria: 7.8.7 requires every exception to be documented with its reason - a discipline stricter than today, where no creation needs any reason at all. 2. Recursive expansion of members: references (015389) Correct as far as it goes - and it concedes the top level is secured. What members: may contain is a content question, expressly outside this proposal's scope, and outside the naming policies of every registry that already runs this rule: none coupled naming to expansion semantics, because that coupling is a different and larger policy. Jaco has already named the constructive path (015390): a members-qualification rule would be a coherent separate proposal, and wording was invited. Meanwhile every new hierarchical set is one fewer ambiguous reference for the next expansion to fear - the gap this concern describes narrows with adoption and stays open without it. 3. Grandfathered flat objects and the transition window (015392) The capability described - register flat names now, populate them later - exists today, permanently, with or without this proposal. Anyone may do it this afternoon. The proposal is the only mechanism before this Working Group that ever closes that window; declining it preserves the window forever. If gaming of the implementation gap is the genuine worry, the remedy is a short implementation period - a staff scheduling matter - not an indefinitely open namespace. And, respectfully: (015392) describes with precision the squatting behaviour whose future possibility this policy exists to end. An objection that demonstrates the attack is an argument for closing the door. 4. Multi-source resolution (015393) Jaco's answer (015396, 015397) is complete: an ASN is delegated by exactly one registry, so a hierarchical name carries its authoritative source in its own first element. The question "which source is authoritative for this set?" has a deterministic answer precisely and only when the name is hierarchical; under a flat name that answer does not exist anywhere. The working-group draft cited in (015393) pursues the same determinism through source-qualified references - the two mechanisms are complements, not conflicts, and that draft's problem statement describes the flat-name condition this proposal removes for new AFRINIC sets. What a third-party mirror carries is today's condition for every object in every IRR database and is governed by no naming policy at any registry. 5. Anchor-ASN eligibility and authentication (015401) Taye, this is the kind of message Last Call is for: specific, technical, and naming the exact requirements it wants. Three responses. First, on substance: the properties you list - the leading ASN globally assigned, an authoritative aut-num present, creation authenticated against that object's maintainer, private-use and reserved ranges (RFC 6996) excluded, canonical ASPLAIN form (RFC 5396) - are, I would argue, what the Impact Assessment's own authorisation claim already entails. An anchor with no holder can authorise no one; a check that can pass in the absence of the aut-num it authenticates against would not be the check the assessment describes. So I read your list not as a new mechanism but as the strict, and correct, reading of the mechanism the proposal already claims. Second, on where it belongs: those are implementation semantics - the authentication mode of the database software and the eligible ASN ranges - and I would support AFRINIC staff recording exactly your list in the implementation guidance for this policy, alongside the failure behaviour per creation path. That is the normal home of such requirements at every registry, and section 7.8.7's documented-exception mechanism gives staff the instrument for any edge the guidance must handle. It is worth adding: even in the weakest imaginable configuration, an unattributable hierarchical-form name is no worse than today, where every name of any form requires no authorisation from anyone. Third, on form: yours is the closest any message in this Last Call has come to proposed text. If you formalise that list as wording - whether as implementation guidance or as a clarification for a future revision - I have no doubt this Working Group will engage it on its merits, exactly as was invited days ago (015390). It is the constructive instrument the process recognises. 6. Implementation rollout process (015402) Warning-only phases, test vectors, baselines, rollback plans and scheduled reviews are implementation artifacts. They are produced by registry staff during implementation - at every RIR - and they appear in no naming policy anywhere: RIPE shipped its hierarchical requirement through the database release process, with release notes and a release-candidate test environment, on the strength of a policy text that contains none of those artifacts. Nothing in this proposal forbids a staged, warning-first deployment; that is exactly the kind of detail the implementation phase exists to define, and 7.8.7's documented-exception mechanism gives staff the instrument for edge handling during it. Taken at face value, (015402)'s final section is an argument about deployment scheduling, which follows ratification - not a reason to withhold it. Stepping back, twice. Each of the demands in messages (015387), (015389), (015391), (015392), (015393), (015398), (015400) and (015402) carries the same condition: "before adoption" (015387, 015389, 015391), "before mandatory enforcement" (015393), "before this proceeds" (015398), "until ... addressed" (015392), "until that is clarified" (015400), "until ... clearly resolved" (015402). As Seun reminded the list (015386), this PDP has no conditional adoption: a proposal cannot pass Last Call subject to future homework. At day eleven of Last Call, "resolve and test before advancing" therefore spells "do not adopt". The process has exactly one instrument for a genuine, fixable concern: proposed text. Jaco invited it (015390). Let me emphasise the arithmetic: seven distinct technical concerns in a single day, after eleven days without one - and, section 5's requirements list aside, still zero proposed amendments. Of the six questions of 23 July (015344), exactly one account engaged them point by point - Tshepo, in (015348) - and the record should credit those answers. In short: 1) Two-object case: tooling should bind to an explicitly selected source or stop and report - the fail-closed behaviour supporters had proposed; the live case itself stays unresolved either way, the rule being prospective. 2) Squatting remedy: none - the victim is left to another database's dispute or abuse process. 3) Is it an improvement? "Yes, narrowly." 4) Evidence bar: a four-part test - whose second criterion, that the proposal "would have prevented" the incident, excludes by construction every incident that already exists; a creation-time rule is prospective by definition. 5) Impact Assessment: "I do not dispute the findings"; the objection shifts to what the IA does not cover. 6) Capacity: individual, representing no organisation or resource member. No other opposing account has answered any of the six. Today the bar has moved with nearly every message, and a seventh question now joins the list. My assessment, for the record: none of today's objections identifies a defect in what the proposal claims; and their cumulative effect, whatever the intent, has been to consume the finite attention of this Working Group - a cost long-standing participants have already described in their own words (015154, 015179). One further observation, offered for the record and without attributing it to any individual: this Last Call's objections began from the principle that the registry "may record... It may not rule" (015011). Today's objections ask the registry to pre-define delegation graphs, revocation processes, state machines, permanent reservations, transition audits and source-selection rules, in advance (015391, 015392, 015393, 015398, 015400, 015402). Those two standards pull in opposite directions, and the same seven-clause creation-time rule cannot be faulted under both at once. Which standard the Working Group actually holds is exactly what the Co-Chairs will weigh - against what the proposal actually claims: a creation-time naming rule, whose every stated boundary today's objection messages ask it to exceed. The community is entitled to expect Last Call to close on schedule and to be assessed on the record as it stands. Regards, Hendrik Visage (AS329532; also AS213481) -------------- next part -------------- An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Mon Jul 27 13:29:13 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Mon, 27 Jul 2026 13:29:13 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <3D148AE6-C8EF-4C22-A732-779C362791CB@hevis.co.za> References: <3D148AE6-C8EF-4C22-A732-779C362791CB@hevis.co.za> Message-ID: Dear Hendrik and colleagues, Thank you for consolidating the discussion. I will not repeat the earlier lifecycle, resolver, delegation, or membership arguments. There is, however, a separate defect in the actual text being considered. The proposal says that exceptions MUST be allowed on a case-by-case basis and gives restoration of an accidentally deleted flat AS-SET as the example. The staff-recommended wording instead says exceptions may be granted ?where necessary.? These are materially different rules. Under the first version, an eligible operator has a right to restoration. Under the second, restoration depends on AFRINIC?s discretion. The wording also changes a narrow restoration example into an undefined general exception. That produces a concrete operational difference. If a grandfathered flat AS-SET is accidentally deleted after implementation, one version requires a restoration path while the other allows AFRINIC to refuse it. Operators and peers referencing that object cannot know which outcome the adopted policy guarantees. This is not an adjacent lifecycle problem. It is the enforcement boundary of the present proposal. The text should therefore be amended to provide one deterministic rule. For example: > A non-hierarchical AS-SET existing before commencement may be restored only where the same object key is requested within a defined recovery period, the request is authenticated by the maintainer authorised immediately before deletion, no conflicting object has intervened, and the restoration is recorded in an auditable log. No other exception may authorise creation of a new non-hierarchical AS-SET. That would preserve accidental-deletion recovery without leaving the supposedly closed namespace subject to undefined staff judgment. Documenting the reason after an exception is granted is not the same as defining the conditions under which the exception is valid. Implementation guidance also cannot resolve a conflict between ?MUST? and ?may? after ratification. Before Last Call closes, the authors and co-chairs should identify which wording is actually under consideration and resolve the difference in normative force. Until then, I remain opposed to the proposal as written. Regards, Tshepo ________________________________ From: hvisage at hevis.co.za Sent: Monday, 27 July 2026 15:11:31 To: Tshepo Masuku ; Nonjabulo Sphilile ; Phetulo Dhlamini ; Taye Medoye ; Thulisile Mazomba ; rpd at afrinic.net Subject: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Good day Tshepo, Nonjabulo, Phetulo, Taye, Thulisile, colleagues, Apologies to the human readers for this voluminous post, but I?d rather address as much in one email than to flood the mailing list With even more messages as I?d rather do a digest type response for all the similar objections at once. For nearly two weeks we have been asking for technical substance; today, in the week Last Call closes, technical reasons have at last been presented. Before I respond to them, let me add a seventh question to the six of 23 July (015344): Question 7: could you please provide the technical issues, difficulties, and real-world examples where implementation of this draft policy - as three RIRs have already implemented it, and the fourth is formally proposing - would negatively affect your current or future operations? We would like to understand those too. Operational evidence of that kind would genuinely add to the body of knowledge on this proposal. Note: numbers like (015344) are message IDs in the RPD archive - prepend https://lists.afrinic.net/pipermail/rpd/2026/ and append .html to read any of them. So let's get to the objections we have been waiting two weeks for: 1. object lifecycle under changes of ASN control (015387, escalated in 015391 and 015400) - answered by Jaco in (015388) and (015394) 1b) its delegated-maintainer extension (015398, pressed again in 015400) - Jaco deferred to the RFC in (015399); the deferral is completed in section 1 below 2) recursive expansion of members: references (015389) - answered in (015390) 3) grandfathered flat objects (015392) - answered in (015395) 4) multi-source name resolution (015393) - answered in (015396, 015397) 5) anchor-ASN eligibility and authentication (015401) - addressed in section 5 below 6) implementation rollout process (015402) - addressed in section 6 below; its delegation and 7.8.7 points are answered in section 1 (the delegation question is 015398/015400 returning), and its benefit-scope point in the common ground just below I refer to and endorse Jaco's answers rather than repeat them. It was asked earlier in this Last Call that objections be addressed as grouped issues rather than piecemeal, and in that spirit I have collated the responses in a single email, adding what has not yet been shared: a precise statement of the authorisation model, the published data, and the cross-registry record. First, the common ground, because it is substantial. In today's own words: * hierarchical naming "can strengthen creation authorisation" (015393) * the proposal "secures the first object name" (015389) * the concerns are "not questions about whether AS-SET membership is correct" (015387) * ASN-anchored naming "can reduce future flat-name collisions" (015402) None of today's messages disputes what the proposal does. Each of today's objections asks it to also solve an adjacent problem - * lifecycle * delegation semantics * expansion semantics * legacy objects * mirror copies * anchor eligibility * and every one of those problems exists today, everywhere, with or without this policy. That is not the discovery of a defect. It is the discovery that the proposal has a scope, which it states and which was put on this record weeks ago (015119, 015120, 015123; and the draft's own sections 7.8.3-7.8.6). 1. The authorisation model, changes of ASN control, and delegation (015387, 015391, 015398, 015400, 015402) Jaco deferred to the RFC on the depth mechanics (015399). Rightly so - the RFC, followed to the top of the chain, completes his answer. (015398) states the rule correctly: a first-level object, AS12345:AS-CUSTOMERS, is created under the authorisation of the aut-num AS12345 as it stands at that moment - its maintainer chain, which follows the current registered holder. A deeper object, AS12345:AS-CUSTOMERS:AS-EU, is created under the authorisation of the maintainer of its immediate parent. Now ask where that parent came from: its own creation was authorised by the level above it, and so on, terminating at the aut-num itself. Every object in the tree exists because the level above authorised its creation. Delegation, where it exists, exists because the chain authorised it. And who controls each level is answerable, level by level, from the database as it stands - which is what verifiable control looks like in RPSL. The emphatic difference at the current state is that a flat name offers just a maintainer but no chain: no root, and no way to ask whether the name was ever anyone's to create - beyond that it must not already exist in THIS one database. (015400) concludes that because deeper control can be delegated, the "control model remains unspecified". The opposite is the case: the control model is fully specified - in the very RFC that (015398) cited, which is why deferring to it was the right answer. That deeper authority is delegated, and that delegated authority does not automatically follow the ASN, is not a gap in the model; it is the model, working as designed for twenty-seven years, for every hierarchical object family, at every RPSL-based registry. A policy does not "leave AFRINIC to interpret" what the RFC and the production database already define - any more than this proposal needs to restate what mnt-by means. What deterministically follows the ASN is the root of every chain: authority over creation and recreation at the first level of the namespace. That is precisely * and only - what the proposal's attribution claim covers. The same depth question returns in (015402); the answer above stands. These semantics are not invented by this proposal. They are RFC 2622 (1999), operated by RPSL-based registries - AFRINIC's included * for twenty-seven years. The proposal does not modify them; it gates which names may come into existence, nothing else. The two outcomes (015398) poses are therefore both answered by the semantics already in production: descendants do not move automatically, so no delegated maintainer is overridden - exactly as for every delegated object today. And the new holder gains precisely what the name anchors: authority over creation and recreation at the first level of its namespace. What the new holder does not get - control over objects a previous holder's delegates still maintain - is what nobody has today under flat names, for any object, ever. A stale delegated descendant is today's universal condition; the proposal neither creates nor worsens it, and no registry in those twenty-seven years has defined the demanded delegation-and-revocation regime for set objects in policy. How ASN control actually changes in this region is likewise not a matter for speculation. AFRINIC publishes it: https://ftp.afrinic.net/pub/stats/afrinic/transfers/transfers_latest.json A full read of that file today: 75 ASN-carrying transfer events (91 ASNs) from 2018 through 2026 - about nine such events a year - and every single one is a merger/acquisition succession, in which the organisation and its maintainer control pass together, so parent ASN and child objects move as one unit. That is the published record behind Jaco's description in (015394), with the frequency question answered exactly: none open-market, all successions that preserve the attribution chain by construction. Anyone can verify this from the file. So the concern of (015391) has been addressed - with our registry's own data. The cross-registry record answers the rest. I checked this week, across the policy, procedural and database-documentation layers of the other four RIRs. RIPE has required hierarchical names for new as-sets since December 2022 and operates full ASN transfers, including inter-RIR; APNIC likewise since July 2023 (prop-151); LACNIC's IRR has been structurally hierarchical since it launched in 2020; at ARIN hierarchical naming is available today and a mandate for new objects is formally proposed (ARIN-prop-342, pending) - the same direction. All four are silent on child as-set lifecycle at every layer. Across the deployed implementations that is roughly three and a half years of exactly the coexistence (015387) warns about - hierarchical mandates running over live ASN transfer markets - and I could not find one documented incident of the failure mode described. In every deployed implementation, lifecycle lives where it belongs: in standard RPSL authorisation and registry operations, not in naming-policy text. On 7.8.7 (015391, 015402): today the namespace has no rule at all - every creation, by anyone, of any name, is the exception. A closed default with documented-reason exceptions cannot be less deterministic than no default whatsoever. And credit where due: (015402) makes one point that verifies - the staff assessment's prose cites "7.8.6" for the restoration-of-deleted-objects exception, where 7.8.6 concerns editing and the exception clause is in fact 7.8.7. That is a cross-reference slip in the assessment's commentary, worth an erratum, and it changes nothing in the policy text: the clauses say what they say, and staff's own recorded caution about recall loopholes shows the right mechanism was analysed. As for the demanded exception criteria: 7.8.7 requires every exception to be documented with its reason - a discipline stricter than today, where no creation needs any reason at all. 1. Recursive expansion of members: references (015389) Correct as far as it goes - and it concedes the top level is secured. What members: may contain is a content question, expressly outside this proposal's scope, and outside the naming policies of every registry that already runs this rule: none coupled naming to expansion semantics, because that coupling is a different and larger policy. Jaco has already named the constructive path (015390): a members-qualification rule would be a coherent separate proposal, and wording was invited. Meanwhile every new hierarchical set is one fewer ambiguous reference for the next expansion to fear * the gap this concern describes narrows with adoption and stays open without it. 1. Grandfathered flat objects and the transition window (015392) The capability described - register flat names now, populate them later - exists today, permanently, with or without this proposal. Anyone may do it this afternoon. The proposal is the only mechanism before this Working Group that ever closes that window; declining it preserves the window forever. If gaming of the implementation gap is the genuine worry, the remedy is a short implementation period - a staff scheduling matter - not an indefinitely open namespace. And, respectfully: (015392) describes with precision the squatting behaviour whose future possibility this policy exists to end. An objection that demonstrates the attack is an argument for closing the door. 1. Multi-source resolution (015393) Jaco's answer (015396, 015397) is complete: an ASN is delegated by exactly one registry, so a hierarchical name carries its authoritative source in its own first element. The question "which source is authoritative for this set?" has a deterministic answer precisely and only when the name is hierarchical; under a flat name that answer does not exist anywhere. The working-group draft cited in (015393) pursues the same determinism through source-qualified references - the two mechanisms are complements, not conflicts, and that draft's problem statement describes the flat-name condition this proposal removes for new AFRINIC sets. What a third-party mirror carries is today's condition for every object in every IRR database and is governed by no naming policy at any registry. 1. Anchor-ASN eligibility and authentication (015401) Taye, this is the kind of message Last Call is for: specific, technical, and naming the exact requirements it wants. Three responses. First, on substance: the properties you list - the leading ASN globally assigned, an authoritative aut-num present, creation authenticated against that object's maintainer, private-use and reserved ranges (RFC 6996) excluded, canonical ASPLAIN form (RFC 5396) - are, I would argue, what the Impact Assessment's own authorisation claim already entails. An anchor with no holder can authorise no one; a check that can pass in the absence of the aut-num it authenticates against would not be the check the assessment describes. So I read your list not as a new mechanism but as the strict, and correct, reading of the mechanism the proposal already claims. Second, on where it belongs: those are implementation semantics - the authentication mode of the database software and the eligible ASN ranges - and I would support AFRINIC staff recording exactly your list in the implementation guidance for this policy, alongside the failure behaviour per creation path. That is the normal home of such requirements at every registry, and section 7.8.7's documented-exception mechanism gives staff the instrument for any edge the guidance must handle. It is worth adding: even in the weakest imaginable configuration, an unattributable hierarchical-form name is no worse than today, where every name of any form requires no authorisation from anyone. Third, on form: yours is the closest any message in this Last Call has come to proposed text. If you formalise that list as wording - whether as implementation guidance or as a clarification for a future revision - I have no doubt this Working Group will engage it on its merits, exactly as was invited days ago (015390). It is the constructive instrument the process recognises. 1. Implementation rollout process (015402) Warning-only phases, test vectors, baselines, rollback plans and scheduled reviews are implementation artifacts. They are produced by registry staff during implementation - at every RIR - and they appear in no naming policy anywhere: RIPE shipped its hierarchical requirement through the database release process, with release notes and a release-candidate test environment, on the strength of a policy text that contains none of those artifacts. Nothing in this proposal forbids a staged, warning-first deployment; that is exactly the kind of detail the implementation phase exists to define, and 7.8.7's documented-exception mechanism gives staff the instrument for edge handling during it. Taken at face value, (015402)'s final section is an argument about deployment scheduling, which follows ratification - not a reason to withhold it. Stepping back, twice. Each of the demands in messages (015387), (015389), (015391), (015392), (015393), (015398), (015400) and (015402) carries the same condition: "before adoption" (015387, 015389, 015391), "before mandatory enforcement" (015393), "before this proceeds" (015398), "until ... addressed" (015392), "until that is clarified" (015400), "until ... clearly resolved" (015402). As Seun reminded the list (015386), this PDP has no conditional adoption: a proposal cannot pass Last Call subject to future homework. At day eleven of Last Call, "resolve and test before advancing" therefore spells "do not adopt". The process has exactly one instrument for a genuine, fixable concern: proposed text. Jaco invited it (015390). Let me emphasise the arithmetic: seven distinct technical concerns in a single day, after eleven days without one - and, section 5's requirements list aside, still zero proposed amendments. Of the six questions of 23 July (015344), exactly one account engaged them point by point - Tshepo, in (015348) - and the record should credit those answers. In short: 1. Two-object case: tooling should bind to an explicitly selected source or stop and report - the fail-closed behaviour supporters had proposed; the live case itself stays unresolved either way, the rule being prospective. 2. Squatting remedy: none - the victim is left to another database's dispute or abuse process. 3. Is it an improvement? "Yes, narrowly." 4. Evidence bar: a four-part test - whose second criterion, that the proposal "would have prevented" the incident, excludes by construction every incident that already exists; a creation-time rule is prospective by definition. 5. Impact Assessment: "I do not dispute the findings"; the objection shifts to what the IA does not cover. 6. Capacity: individual, representing no organisation or resource member. No other opposing account has answered any of the six. Today the bar has moved with nearly every message, and a seventh question now joins the list. My assessment, for the record: none of today's objections identifies a defect in what the proposal claims; and their cumulative effect, whatever the intent, has been to consume the finite attention of this Working Group - a cost long-standing participants have already described in their own words (015154, 015179). One further observation, offered for the record and without attributing it to any individual: this Last Call's objections began from the principle that the registry "may record... It may not rule" (015011). Today's objections ask the registry to pre-define delegation graphs, revocation processes, state machines, permanent reservations, transition audits and source-selection rules, in advance (015391, 015392, 015393, 015398, 015400, 015402). Those two standards pull in opposite directions, and the same seven-clause creation-time rule cannot be faulted under both at once. Which standard the Working Group actually holds is exactly what the Co-Chairs will weigh - against what the proposal actually claims: a creation-time naming rule, whose every stated boundary today's objection messages ask it to exceed. The community is entitled to expect Last Call to close on schedule and to be assessed on the record as it stands. Regards, Hendrik Visage (AS329532; also AS213481) -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent at ngundi.me.ke Mon Jul 27 14:24:20 2026 From: vincent at ngundi.me.ke (Vincent Ngundi, Ph.D) Date: Mon, 27 Jul 2026 17:24:20 +0300 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavior on AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: <04D11A79-C491-49B2-9ADD-DA3AE0A41E29@trstech.net> References: <1784639031075.56443@tra.gov.eg> <04D11A79-C491-49B2-9ADD-DA3AE0A41E29@trstech.net> Message-ID: I couldn?t agree with you more Alain. Regards, Dr. Ngundi On Mon, 27 Jul 2026 at 16:06, ALAIN AINA via RPD wrote: > Hi PDWG, > > > On 21 Jul 2026, at 13:03, Hytham El-Nakhal wrote: > > > > Dear PDWG, > > > > > [??.] > > > > The AF-37 PPM minutes can be accessed here : > https://docs.google.com/document/d/1RS9bYBb9-8uQxLb4u8LpvEUw1jZSfei5mLj01l2LS1s/edit?usp=sharing > > > > The recent discussions during Last Calls and the various attempts to > contain the excesses of those exchanges have made one point clear: our > Working Group and the PDP it serves need to be updated. We require clearer > definitions of roles, responsibilities, and process expectations. Without > this, polarization will deepen and ad?hoc tools will continue to > proliferate. > > Participation in this WG must remain grounded in arguments, not in the > source address of the participant. In the RIR context, contributions come > from two broad groups speaking in their personal capacity: > 1. registered contacts of resource members, and > 2. any other interested parties. > > Both groups must be treated equally, and their arguments evaluated on > merit. > > Our path to rough consensus must remain focused on addressing issues not > on counting supporters or opponents. Consensus is built by resolving > concerns, not by tallying positions. The Last Call stage should reflect > this. > > A Last Call should: > > ? list the issues raised during discussions, > ? explain how each issue was addressed, > ? identify any open issues, and > ? justify why the proposal is ready to move forward. > > A Last Call should not solicit support or opposition. Instead, it should > invite: > > ? new issues that were not previously considered, or > ? new perspectives on how addressed issues were resolved. > > Let us work together to provide AFRINIC with a predictable PDP, clear > co?chairs mandates, and the tools needed to manage discussions effectively > and fairly. > > HTH > > ?Alain( Co-author of the PDP WG guidelines proposal) > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nonjabulosphilile at gmail.com Mon Jul 27 14:40:30 2026 From: nonjabulosphilile at gmail.com (Nonjabulo Sphilile) Date: Mon, 27 Jul 2026 16:40:30 +0200 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavior on AFPUB-2026-ASN-001-DRAFT02 Message-ID: Dear Alain and colleagues, Thank you, Alain. I agree that the discussion would benefit from a clear record of the issues raised, how each was addressed, and which ones remain open. Rough consensus should emerge from that record, not from counting supporters or repeatedly declaring concerns closed. Hendrik?s consolidated response may be useful input, but it cannot substitute for an impartial issue-disposition report from the co-chairs. A proposal supporter may explain why they believe an objection has been answered; they should not also become the final judge of whether it has been resolved. Otherwise, advocacy quietly becomes adjudication. I would also add one new open issue from the Impact Assessment. It lists RDAP as an affected system and says it will reflect AS-SET queries. However, the standard RDAP query format defines queries for IP networks, AS numbers, domains, nameservers, and entities, not RPSL AS-SET objects. The assessment does not identify an AFRINIC-specific extension, schema, or query path through which AS-SETs are exposed. This is not another request for the proposal to solve an unrelated IRR problem. It is an unexplained statement inside the implementation assessment itself. Staff should clarify whether AFRINIC has a documented RDAP extension for AS-SETs, how it works, and how consistency will be maintained across WHOIS, MyAFRINIC, APIs, and any other creation interface. If RDAP is not involved, it should not be listed as an affected system. That issue should appear in the open-issues record and be resolved before the proposal is declared ready. A mandatory rule should be based on a precise and verifiable implementation surface, not on assumptions left for interpretation after ratification. For these reasons, I support Alain?s recommendations and remain opposed to advancing AFPUB-2026-ASN-001-DRAFT02 at this stage. Regards, Nonjabulo -------------- next part -------------- An HTML attachment was scrubbed... URL: From policy-liaison at afrinic.net Mon Jul 27 16:57:56 2026 From: policy-liaison at afrinic.net (Policy Liaison Team) Date: Mon, 27 Jul 2026 20:57:56 +0400 Subject: [rpd] PDWG Co-Chairs communication regarding observed behavior on AFPUB-2026-ASN-001-DRAFT02 In-Reply-To: References: Message-ID: <914389df-aa04-456b-aeaa-3d316f3004eb@afrinic.net> Dear Nonjabulo Thanks for the query regarding as-set? on RDAP . /https://www.afrinic.net/whois-rdap.html ?does not mention as-set . RDAP being listed as affected system could be a typo. We will verify internally and advise. If need be, the staff assesment will be updated. / Kind Regards Madhvi -- AFRINIC Policy Liaison. ?t: +230 403 51 00 | f: +230 466 6758 | tt: @afrinic | w:www.afrinic.net facebook.com/afrinic | flickr.com/afrinic | youtube.com/afrinicmedia On 27/07/2026 18:40, Nonjabulo Sphilile wrote: > I would also add one new open issue from the Impact Assessment. It > lists RDAP as an affected system and says it will reflect AS-SET > queries. However, the standard RDAP query format defines queries for > IP networks, AS numbers, domains, nameservers, and entities, not RPSL > AS-SET objects. The assessment does not identify an AFRINIC-specific > extension, schema, or query path through which AS-SETs are exposed. > This is not another request for the proposal to solve an unrelated IRR > problem. It is an unexplained statement inside the implementation > assessment itself. Staff should clarify whether AFRINIC has a > documented RDAP extension for AS-SETs, how it works, and how > consistency will be maintained across WHOIS, MyAFRINIC, APIs, and any > other creation interface. If RDAP is not involved, it should not be > listed as an affected system. > > That issue should appear in the open-issues record and be resolved > before the proposal is declared ready. A mandatory rule should be > based on a precise and verifiable implementation surface, not on > assumptions left for interpretation after ratification. -------------- next part -------------- An HTML attachment was scrubbed... URL: From james at inter.link Tue Jul 28 11:39:50 2026 From: james at inter.link (James Bensley) Date: Tue, 28 Jul 2026 11:39:50 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <3D148AE6-C8EF-4C22-A732-779C362791CB@hevis.co.za> Message-ID: Dear Tshepo, Thank you for providing your feedback. I am in agreement with your statement. I am the original author of this draft change, and I wrote in my last update (version 2): "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." The staff assessment was to go with the following "7.8.7 Exceptions for the creation of hierarchical names may be granted where necessary. AFRINIC shall document the reason for any exception.". The staff asked me to review their assessment and I initially agreed, because it was loser than my definition. There may be other scenarios where restoration is required which I/we haven't thought of, so why limit it to accidental deletion only. Opening it up to allow any case to be reviewed has benefits. But as you say, it could also go the other way, it could simply mean that every case is rejected. I am going to submit another version (v3) of the document, only replacing the text I quoted above, with the text below, to fix the problem you raised of the text having gone from being too strict before to now being too lose (I will try to propose something in the middle which guarantees delete/restoration is protected, anything else needs a review). I am proposing the following text, what do you think? ------ A non-hierarchical AS-SET existing before implementation of this policy change, which has since been deleted, must be restorable when the following conditions are met: - The same object key is requested for restoration (no AS-SET name changes allowed) - No object with a conflicting name has been created between the date of deletion and the date the restore is made - The restore request is coming from either a maintainer that was present on the deleted object, or another maintainer within the same organisation (in the case the maintainer was also deleted), or a maintainer in an organisation responsible for the assets of the original organisation (in the case of a merger or acquisition). - The restoration is recorded in an auditable log. Any other request for restoring a deleted AS-SET created before the implementation date of this policy change will need to be reviewed by AFRINIC on a case by case basis. ------- With kind regards, James Bensley (he/him) ________________________________ From: Tshepo Masuku Sent: 27 July 2026 15:29 To: hvisage at hevis.co.za ; Nonjabulo Sphilile ; Phetulo Dhlamini ; Taye Medoye ; Thulisile Mazomba ; rpd at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) ?? Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. Dear Hendrik and colleagues, Thank you for consolidating the discussion. I will not repeat the earlier lifecycle, resolver, delegation, or membership arguments. There is, however, a separate defect in the actual text being considered. The proposal says that exceptions MUST be allowed on a case-by-case basis and gives restoration of an accidentally deleted flat AS-SET as the example. The staff-recommended wording instead says exceptions may be granted ?where necessary.? These are materially different rules. Under the first version, an eligible operator has a right to restoration. Under the second, restoration depends on AFRINIC?s discretion. The wording also changes a narrow restoration example into an undefined general exception. That produces a concrete operational difference. If a grandfathered flat AS-SET is accidentally deleted after implementation, one version requires a restoration path while the other allows AFRINIC to refuse it. Operators and peers referencing that object cannot know which outcome the adopted policy guarantees. This is not an adjacent lifecycle problem. It is the enforcement boundary of the present proposal. The text should therefore be amended to provide one deterministic rule. For example: > A non-hierarchical AS-SET existing before commencement may be restored only where the same object key is requested within a defined recovery period, the request is authenticated by the maintainer authorised immediately before deletion, no conflicting object has intervened, and the restoration is recorded in an auditable log. No other exception may authorise creation of a new non-hierarchical AS-SET. That would preserve accidental-deletion recovery without leaving the supposedly closed namespace subject to undefined staff judgment. Documenting the reason after an exception is granted is not the same as defining the conditions under which the exception is valid. Implementation guidance also cannot resolve a conflict between ?MUST? and ?may? after ratification. Before Last Call closes, the authors and co-chairs should identify which wording is actually under consideration and resolve the difference in normative force. Until then, I remain opposed to the proposal as written. Regards, Tshepo ________________________________ From: hvisage at hevis.co.za Sent: Monday, 27 July 2026 15:11:31 To: Tshepo Masuku ; Nonjabulo Sphilile ; Phetulo Dhlamini ; Taye Medoye ; Thulisile Mazomba ; rpd at afrinic.net Subject: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Good day Tshepo, Nonjabulo, Phetulo, Taye, Thulisile, colleagues, Apologies to the human readers for this voluminous post, but I?d rather address as much in one email than to flood the mailing list With even more messages as I?d rather do a digest type response for all the similar objections at once. For nearly two weeks we have been asking for technical substance; today, in the week Last Call closes, technical reasons have at last been presented. Before I respond to them, let me add a seventh question to the six of 23 July (015344): Question 7: could you please provide the technical issues, difficulties, and real-world examples where implementation of this draft policy - as three RIRs have already implemented it, and the fourth is formally proposing - would negatively affect your current or future operations? We would like to understand those too. Operational evidence of that kind would genuinely add to the body of knowledge on this proposal. Note: numbers like (015344) are message IDs in the RPD archive - prepend https://lists.afrinic.net/pipermail/rpd/2026/ and append .html to read any of them. So let's get to the objections we have been waiting two weeks for: 1. object lifecycle under changes of ASN control (015387, escalated in 015391 and 015400) - answered by Jaco in (015388) and (015394) 1b) its delegated-maintainer extension (015398, pressed again in 015400) - Jaco deferred to the RFC in (015399); the deferral is completed in section 1 below 2) recursive expansion of members: references (015389) - answered in (015390) 3) grandfathered flat objects (015392) - answered in (015395) 4) multi-source name resolution (015393) - answered in (015396, 015397) 5) anchor-ASN eligibility and authentication (015401) - addressed in section 5 below 6) implementation rollout process (015402) - addressed in section 6 below; its delegation and 7.8.7 points are answered in section 1 (the delegation question is 015398/015400 returning), and its benefit-scope point in the common ground just below I refer to and endorse Jaco's answers rather than repeat them. It was asked earlier in this Last Call that objections be addressed as grouped issues rather than piecemeal, and in that spirit I have collated the responses in a single email, adding what has not yet been shared: a precise statement of the authorisation model, the published data, and the cross-registry record. First, the common ground, because it is substantial. In today's own words: * hierarchical naming "can strengthen creation authorisation" (015393) * the proposal "secures the first object name" (015389) * the concerns are "not questions about whether AS-SET membership is correct" (015387) * ASN-anchored naming "can reduce future flat-name collisions" (015402) None of today's messages disputes what the proposal does. Each of today's objections asks it to also solve an adjacent problem - * lifecycle * delegation semantics * expansion semantics * legacy objects * mirror copies * anchor eligibility * and every one of those problems exists today, everywhere, with or without this policy. That is not the discovery of a defect. It is the discovery that the proposal has a scope, which it states and which was put on this record weeks ago (015119, 015120, 015123; and the draft's own sections 7.8.3-7.8.6). 1. The authorisation model, changes of ASN control, and delegation (015387, 015391, 015398, 015400, 015402) Jaco deferred to the RFC on the depth mechanics (015399). Rightly so - the RFC, followed to the top of the chain, completes his answer. (015398) states the rule correctly: a first-level object, AS12345:AS-CUSTOMERS, is created under the authorisation of the aut-num AS12345 as it stands at that moment - its maintainer chain, which follows the current registered holder. A deeper object, AS12345:AS-CUSTOMERS:AS-EU, is created under the authorisation of the maintainer of its immediate parent. Now ask where that parent came from: its own creation was authorised by the level above it, and so on, terminating at the aut-num itself. Every object in the tree exists because the level above authorised its creation. Delegation, where it exists, exists because the chain authorised it. And who controls each level is answerable, level by level, from the database as it stands - which is what verifiable control looks like in RPSL. The emphatic difference at the current state is that a flat name offers just a maintainer but no chain: no root, and no way to ask whether the name was ever anyone's to create - beyond that it must not already exist in THIS one database. (015400) concludes that because deeper control can be delegated, the "control model remains unspecified". The opposite is the case: the control model is fully specified - in the very RFC that (015398) cited, which is why deferring to it was the right answer. That deeper authority is delegated, and that delegated authority does not automatically follow the ASN, is not a gap in the model; it is the model, working as designed for twenty-seven years, for every hierarchical object family, at every RPSL-based registry. A policy does not "leave AFRINIC to interpret" what the RFC and the production database already define - any more than this proposal needs to restate what mnt-by means. What deterministically follows the ASN is the root of every chain: authority over creation and recreation at the first level of the namespace. That is precisely * and only - what the proposal's attribution claim covers. The same depth question returns in (015402); the answer above stands. These semantics are not invented by this proposal. They are RFC 2622 (1999), operated by RPSL-based registries - AFRINIC's included * for twenty-seven years. The proposal does not modify them; it gates which names may come into existence, nothing else. The two outcomes (015398) poses are therefore both answered by the semantics already in production: descendants do not move automatically, so no delegated maintainer is overridden - exactly as for every delegated object today. And the new holder gains precisely what the name anchors: authority over creation and recreation at the first level of its namespace. What the new holder does not get - control over objects a previous holder's delegates still maintain - is what nobody has today under flat names, for any object, ever. A stale delegated descendant is today's universal condition; the proposal neither creates nor worsens it, and no registry in those twenty-seven years has defined the demanded delegation-and-revocation regime for set objects in policy. How ASN control actually changes in this region is likewise not a matter for speculation. AFRINIC publishes it: https://ftp.afrinic.net/pub/stats/afrinic/transfers/transfers_latest.json A full read of that file today: 75 ASN-carrying transfer events (91 ASNs) from 2018 through 2026 - about nine such events a year - and every single one is a merger/acquisition succession, in which the organisation and its maintainer control pass together, so parent ASN and child objects move as one unit. That is the published record behind Jaco's description in (015394), with the frequency question answered exactly: none open-market, all successions that preserve the attribution chain by construction. Anyone can verify this from the file. So the concern of (015391) has been addressed - with our registry's own data. The cross-registry record answers the rest. I checked this week, across the policy, procedural and database-documentation layers of the other four RIRs. RIPE has required hierarchical names for new as-sets since December 2022 and operates full ASN transfers, including inter-RIR; APNIC likewise since July 2023 (prop-151); LACNIC's IRR has been structurally hierarchical since it launched in 2020; at ARIN hierarchical naming is available today and a mandate for new objects is formally proposed (ARIN-prop-342, pending) - the same direction. All four are silent on child as-set lifecycle at every layer. Across the deployed implementations that is roughly three and a half years of exactly the coexistence (015387) warns about - hierarchical mandates running over live ASN transfer markets - and I could not find one documented incident of the failure mode described. In every deployed implementation, lifecycle lives where it belongs: in standard RPSL authorisation and registry operations, not in naming-policy text. On 7.8.7 (015391, 015402): today the namespace has no rule at all - every creation, by anyone, of any name, is the exception. A closed default with documented-reason exceptions cannot be less deterministic than no default whatsoever. And credit where due: (015402) makes one point that verifies - the staff assessment's prose cites "7.8.6" for the restoration-of-deleted-objects exception, where 7.8.6 concerns editing and the exception clause is in fact 7.8.7. That is a cross-reference slip in the assessment's commentary, worth an erratum, and it changes nothing in the policy text: the clauses say what they say, and staff's own recorded caution about recall loopholes shows the right mechanism was analysed. As for the demanded exception criteria: 7.8.7 requires every exception to be documented with its reason - a discipline stricter than today, where no creation needs any reason at all. 1. Recursive expansion of members: references (015389) Correct as far as it goes - and it concedes the top level is secured. What members: may contain is a content question, expressly outside this proposal's scope, and outside the naming policies of every registry that already runs this rule: none coupled naming to expansion semantics, because that coupling is a different and larger policy. Jaco has already named the constructive path (015390): a members-qualification rule would be a coherent separate proposal, and wording was invited. Meanwhile every new hierarchical set is one fewer ambiguous reference for the next expansion to fear * the gap this concern describes narrows with adoption and stays open without it. 1. Grandfathered flat objects and the transition window (015392) The capability described - register flat names now, populate them later - exists today, permanently, with or without this proposal. Anyone may do it this afternoon. The proposal is the only mechanism before this Working Group that ever closes that window; declining it preserves the window forever. If gaming of the implementation gap is the genuine worry, the remedy is a short implementation period - a staff scheduling matter - not an indefinitely open namespace. And, respectfully: (015392) describes with precision the squatting behaviour whose future possibility this policy exists to end. An objection that demonstrates the attack is an argument for closing the door. 1. Multi-source resolution (015393) Jaco's answer (015396, 015397) is complete: an ASN is delegated by exactly one registry, so a hierarchical name carries its authoritative source in its own first element. The question "which source is authoritative for this set?" has a deterministic answer precisely and only when the name is hierarchical; under a flat name that answer does not exist anywhere. The working-group draft cited in (015393) pursues the same determinism through source-qualified references - the two mechanisms are complements, not conflicts, and that draft's problem statement describes the flat-name condition this proposal removes for new AFRINIC sets. What a third-party mirror carries is today's condition for every object in every IRR database and is governed by no naming policy at any registry. 1. Anchor-ASN eligibility and authentication (015401) Taye, this is the kind of message Last Call is for: specific, technical, and naming the exact requirements it wants. Three responses. First, on substance: the properties you list - the leading ASN globally assigned, an authoritative aut-num present, creation authenticated against that object's maintainer, private-use and reserved ranges (RFC 6996) excluded, canonical ASPLAIN form (RFC 5396) - are, I would argue, what the Impact Assessment's own authorisation claim already entails. An anchor with no holder can authorise no one; a check that can pass in the absence of the aut-num it authenticates against would not be the check the assessment describes. So I read your list not as a new mechanism but as the strict, and correct, reading of the mechanism the proposal already claims. Second, on where it belongs: those are implementation semantics - the authentication mode of the database software and the eligible ASN ranges - and I would support AFRINIC staff recording exactly your list in the implementation guidance for this policy, alongside the failure behaviour per creation path. That is the normal home of such requirements at every registry, and section 7.8.7's documented-exception mechanism gives staff the instrument for any edge the guidance must handle. It is worth adding: even in the weakest imaginable configuration, an unattributable hierarchical-form name is no worse than today, where every name of any form requires no authorisation from anyone. Third, on form: yours is the closest any message in this Last Call has come to proposed text. If you formalise that list as wording - whether as implementation guidance or as a clarification for a future revision - I have no doubt this Working Group will engage it on its merits, exactly as was invited days ago (015390). It is the constructive instrument the process recognises. 1. Implementation rollout process (015402) Warning-only phases, test vectors, baselines, rollback plans and scheduled reviews are implementation artifacts. They are produced by registry staff during implementation - at every RIR - and they appear in no naming policy anywhere: RIPE shipped its hierarchical requirement through the database release process, with release notes and a release-candidate test environment, on the strength of a policy text that contains none of those artifacts. Nothing in this proposal forbids a staged, warning-first deployment; that is exactly the kind of detail the implementation phase exists to define, and 7.8.7's documented-exception mechanism gives staff the instrument for edge handling during it. Taken at face value, (015402)'s final section is an argument about deployment scheduling, which follows ratification - not a reason to withhold it. Stepping back, twice. Each of the demands in messages (015387), (015389), (015391), (015392), (015393), (015398), (015400) and (015402) carries the same condition: "before adoption" (015387, 015389, 015391), "before mandatory enforcement" (015393), "before this proceeds" (015398), "until ... addressed" (015392), "until that is clarified" (015400), "until ... clearly resolved" (015402). As Seun reminded the list (015386), this PDP has no conditional adoption: a proposal cannot pass Last Call subject to future homework. At day eleven of Last Call, "resolve and test before advancing" therefore spells "do not adopt". The process has exactly one instrument for a genuine, fixable concern: proposed text. Jaco invited it (015390). Let me emphasise the arithmetic: seven distinct technical concerns in a single day, after eleven days without one - and, section 5's requirements list aside, still zero proposed amendments. Of the six questions of 23 July (015344), exactly one account engaged them point by point - Tshepo, in (015348) - and the record should credit those answers. In short: 1. Two-object case: tooling should bind to an explicitly selected source or stop and report - the fail-closed behaviour supporters had proposed; the live case itself stays unresolved either way, the rule being prospective. 2. Squatting remedy: none - the victim is left to another database's dispute or abuse process. 3. Is it an improvement? "Yes, narrowly." 4. Evidence bar: a four-part test - whose second criterion, that the proposal "would have prevented" the incident, excludes by construction every incident that already exists; a creation-time rule is prospective by definition. 5. Impact Assessment: "I do not dispute the findings"; the objection shifts to what the IA does not cover. 6. Capacity: individual, representing no organisation or resource member. No other opposing account has answered any of the six. Today the bar has moved with nearly every message, and a seventh question now joins the list. My assessment, for the record: none of today's objections identifies a defect in what the proposal claims; and their cumulative effect, whatever the intent, has been to consume the finite attention of this Working Group - a cost long-standing participants have already described in their own words (015154, 015179). One further observation, offered for the record and without attributing it to any individual: this Last Call's objections began from the principle that the registry "may record... It may not rule" (015011). Today's objections ask the registry to pre-define delegation graphs, revocation processes, state machines, permanent reservations, transition audits and source-selection rules, in advance (015391, 015392, 015393, 015398, 015400, 015402). Those two standards pull in opposite directions, and the same seven-clause creation-time rule cannot be faulted under both at once. Which standard the Working Group actually holds is exactly what the Co-Chairs will weigh - against what the proposal actually claims: a creation-time naming rule, whose every stated boundary today's objection messages ask it to exceed. The community is entitled to expect Last Call to close on schedule and to be assessed on the record as it stands. Regards, Hendrik Visage (AS329532; also AS213481) [CompanySignature] Inter..link GmbH | Boxhagener Stra?e 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello at inter.link | Web: inter.link -------------- next part -------------- An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Tue Jul 28 13:28:33 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Tue, 28 Jul 2026 13:28:33 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <3D148AE6-C8EF-4C22-A732-779C362791CB@hevis.co.za> Message-ID: Dear James, Thank you for engaging with the concern constructively. Your proposed wording is a meaningful improvement because it begins replacing an open-ended exception with objective conditions. I think a few points still need tightening before the rule is ready: * Restoration should return the object to its last valid archived state, not merely reuse the same key. Otherwise, an old flat name could be restored with entirely different contents and become a new object in substance. * The text should define whether the restoration right is permanent or subject to a recovery period. * ?Another maintainer within the same organisation? and an organisation ?responsible for the assets? require objective evidence, such as registry history or documented legal succession. Those terms should not be left entirely to staff interpretation. * The residual case-by-case provision should expressly prohibit creating a flat name that did not exist before implementation. * Every exceptional decision should record the evidence relied upon and provide a review or appeal path, not merely an audit entry. I would also suggest wording along these lines: A restored object shall initially reflect its last valid archived state, except that maintainer and contact attributes may be updated where necessary to establish control by the verified original holder or lawful successor. Because this changes the normative enforcement boundary, I believe v3 should be published with an updated Impact Assessment and receive proper review. It should not be treated as a minor editorial correction during the final days of Last Call. I remain opposed to DRAFT02 as written, but I appreciate your willingness to address the defect directly. This is the kind of concrete engagement that adds value to the process. Regards, Tshepo ________________________________ From: James Bensley Sent: Tuesday, 28 July 2026 13:39:50 To: Tshepo Masuku ; rpd at afrinic.net ; pdwg-chairs at afrinic.net Subject: Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Dear Tshepo, Thank you for providing your feedback. I am in agreement with your statement. I am the original author of this draft change, and I wrote in my last update (version 2): "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." The staff assessment was to go with the following "7.8.7 Exceptions for the creation of hierarchical names may be granted where necessary. AFRINIC shall document the reason for any exception.". The staff asked me to review their assessment and I initially agreed, because it was loser than my definition. There may be other scenarios where restoration is required which I/we haven't thought of, so why limit it to accidental deletion only. Opening it up to allow any case to be reviewed has benefits. But as you say, it could also go the other way, it could simply mean that every case is rejected. I am going to submit another version (v3) of the document, only replacing the text I quoted above, with the text below, to fix the problem you raised of the text having gone from being too strict before to now being too lose (I will try to propose something in the middle which guarantees delete/restoration is protected, anything else needs a review). I am proposing the following text, what do you think? ------ A non-hierarchical AS-SET existing before implementation of this policy change, which has since been deleted, must be restorable when the following conditions are met: - The same object key is requested for restoration (no AS-SET name changes allowed) - No object with a conflicting name has been created between the date of deletion and the date the restore is made - The restore request is coming from either a maintainer that was present on the deleted object, or another maintainer within the same organisation (in the case the maintainer was also deleted), or a maintainer in an organisation responsible for the assets of the original organisation (in the case of a merger or acquisition). - The restoration is recorded in an auditable log. Any other request for restoring a deleted AS-SET created before the implementation date of this policy change will need to be reviewed by AFRINIC on a case by case basis. ------- With kind regards, James Bensley (he/him) ________________________________ From: Tshepo Masuku Sent: 27 July 2026 15:29 To: hvisage at hevis.co.za ; Nonjabulo Sphilile ; Phetulo Dhlamini ; Taye Medoye ; Thulisile Mazomba ; rpd at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) ?? Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. Dear Hendrik and colleagues, Thank you for consolidating the discussion. I will not repeat the earlier lifecycle, resolver, delegation, or membership arguments. There is, however, a separate defect in the actual text being considered. The proposal says that exceptions MUST be allowed on a case-by-case basis and gives restoration of an accidentally deleted flat AS-SET as the example. The staff-recommended wording instead says exceptions may be granted ?where necessary.? These are materially different rules. Under the first version, an eligible operator has a right to restoration. Under the second, restoration depends on AFRINIC?s discretion. The wording also changes a narrow restoration example into an undefined general exception. That produces a concrete operational difference. If a grandfathered flat AS-SET is accidentally deleted after implementation, one version requires a restoration path while the other allows AFRINIC to refuse it. Operators and peers referencing that object cannot know which outcome the adopted policy guarantees. This is not an adjacent lifecycle problem. It is the enforcement boundary of the present proposal. The text should therefore be amended to provide one deterministic rule. For example: > A non-hierarchical AS-SET existing before commencement may be restored only where the same object key is requested within a defined recovery period, the request is authenticated by the maintainer authorised immediately before deletion, no conflicting object has intervened, and the restoration is recorded in an auditable log. No other exception may authorise creation of a new non-hierarchical AS-SET. That would preserve accidental-deletion recovery without leaving the supposedly closed namespace subject to undefined staff judgment. Documenting the reason after an exception is granted is not the same as defining the conditions under which the exception is valid. Implementation guidance also cannot resolve a conflict between ?MUST? and ?may? after ratification. Before Last Call closes, the authors and co-chairs should identify which wording is actually under consideration and resolve the difference in normative force. Until then, I remain opposed to the proposal as written. Regards, Tshepo ________________________________ From: hvisage at hevis.co.za Sent: Monday, 27 July 2026 15:11:31 To: Tshepo Masuku ; Nonjabulo Sphilile ; Phetulo Dhlamini ; Taye Medoye ; Thulisile Mazomba ; rpd at afrinic.net Subject: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Good day Tshepo, Nonjabulo, Phetulo, Taye, Thulisile, colleagues, Apologies to the human readers for this voluminous post, but I?d rather address as much in one email than to flood the mailing list With even more messages as I?d rather do a digest type response for all the similar objections at once. For nearly two weeks we have been asking for technical substance; today, in the week Last Call closes, technical reasons have at last been presented. Before I respond to them, let me add a seventh question to the six of 23 July (015344): Question 7: could you please provide the technical issues, difficulties, and real-world examples where implementation of this draft policy - as three RIRs have already implemented it, and the fourth is formally proposing - would negatively affect your current or future operations? We would like to understand those too. Operational evidence of that kind would genuinely add to the body of knowledge on this proposal. Note: numbers like (015344) are message IDs in the RPD archive - prepend https://lists.afrinic.net/pipermail/rpd/2026/ and append .html to read any of them. So let's get to the objections we have been waiting two weeks for: 1. object lifecycle under changes of ASN control (015387, escalated in 015391 and 015400) - answered by Jaco in (015388) and (015394) 1b) its delegated-maintainer extension (015398, pressed again in 015400) - Jaco deferred to the RFC in (015399); the deferral is completed in section 1 below 2) recursive expansion of members: references (015389) - answered in (015390) 3) grandfathered flat objects (015392) - answered in (015395) 4) multi-source name resolution (015393) - answered in (015396, 015397) 5) anchor-ASN eligibility and authentication (015401) - addressed in section 5 below 6) implementation rollout process (015402) - addressed in section 6 below; its delegation and 7.8.7 points are answered in section 1 (the delegation question is 015398/015400 returning), and its benefit-scope point in the common ground just below I refer to and endorse Jaco's answers rather than repeat them. It was asked earlier in this Last Call that objections be addressed as grouped issues rather than piecemeal, and in that spirit I have collated the responses in a single email, adding what has not yet been shared: a precise statement of the authorisation model, the published data, and the cross-registry record. First, the common ground, because it is substantial. In today's own words: * hierarchical naming "can strengthen creation authorisation" (015393) * the proposal "secures the first object name" (015389) * the concerns are "not questions about whether AS-SET membership is correct" (015387) * ASN-anchored naming "can reduce future flat-name collisions" (015402) None of today's messages disputes what the proposal does. Each of today's objections asks it to also solve an adjacent problem - * lifecycle * delegation semantics * expansion semantics * legacy objects * mirror copies * anchor eligibility * and every one of those problems exists today, everywhere, with or without this policy. That is not the discovery of a defect. It is the discovery that the proposal has a scope, which it states and which was put on this record weeks ago (015119, 015120, 015123; and the draft's own sections 7.8.3-7.8.6). 1. The authorisation model, changes of ASN control, and delegation (015387, 015391, 015398, 015400, 015402) Jaco deferred to the RFC on the depth mechanics (015399). Rightly so - the RFC, followed to the top of the chain, completes his answer. (015398) states the rule correctly: a first-level object, AS12345:AS-CUSTOMERS, is created under the authorisation of the aut-num AS12345 as it stands at that moment - its maintainer chain, which follows the current registered holder. A deeper object, AS12345:AS-CUSTOMERS:AS-EU, is created under the authorisation of the maintainer of its immediate parent. Now ask where that parent came from: its own creation was authorised by the level above it, and so on, terminating at the aut-num itself. Every object in the tree exists because the level above authorised its creation. Delegation, where it exists, exists because the chain authorised it. And who controls each level is answerable, level by level, from the database as it stands - which is what verifiable control looks like in RPSL. The emphatic difference at the current state is that a flat name offers just a maintainer but no chain: no root, and no way to ask whether the name was ever anyone's to create - beyond that it must not already exist in THIS one database. (015400) concludes that because deeper control can be delegated, the "control model remains unspecified". The opposite is the case: the control model is fully specified - in the very RFC that (015398) cited, which is why deferring to it was the right answer. That deeper authority is delegated, and that delegated authority does not automatically follow the ASN, is not a gap in the model; it is the model, working as designed for twenty-seven years, for every hierarchical object family, at every RPSL-based registry. A policy does not "leave AFRINIC to interpret" what the RFC and the production database already define - any more than this proposal needs to restate what mnt-by means. What deterministically follows the ASN is the root of every chain: authority over creation and recreation at the first level of the namespace. That is precisely * and only - what the proposal's attribution claim covers. The same depth question returns in (015402); the answer above stands. These semantics are not invented by this proposal. They are RFC 2622 (1999), operated by RPSL-based registries - AFRINIC's included * for twenty-seven years. The proposal does not modify them; it gates which names may come into existence, nothing else. The two outcomes (015398) poses are therefore both answered by the semantics already in production: descendants do not move automatically, so no delegated maintainer is overridden - exactly as for every delegated object today. And the new holder gains precisely what the name anchors: authority over creation and recreation at the first level of its namespace. What the new holder does not get - control over objects a previous holder's delegates still maintain - is what nobody has today under flat names, for any object, ever. A stale delegated descendant is today's universal condition; the proposal neither creates nor worsens it, and no registry in those twenty-seven years has defined the demanded delegation-and-revocation regime for set objects in policy. How ASN control actually changes in this region is likewise not a matter for speculation. AFRINIC publishes it: https://ftp.afrinic.net/pub/stats/afrinic/transfers/transfers_latest.json A full read of that file today: 75 ASN-carrying transfer events (91 ASNs) from 2018 through 2026 - about nine such events a year - and every single one is a merger/acquisition succession, in which the organisation and its maintainer control pass together, so parent ASN and child objects move as one unit. That is the published record behind Jaco's description in (015394), with the frequency question answered exactly: none open-market, all successions that preserve the attribution chain by construction. Anyone can verify this from the file. So the concern of (015391) has been addressed - with our registry's own data. The cross-registry record answers the rest. I checked this week, across the policy, procedural and database-documentation layers of the other four RIRs. RIPE has required hierarchical names for new as-sets since December 2022 and operates full ASN transfers, including inter-RIR; APNIC likewise since July 2023 (prop-151); LACNIC's IRR has been structurally hierarchical since it launched in 2020; at ARIN hierarchical naming is available today and a mandate for new objects is formally proposed (ARIN-prop-342, pending) - the same direction. All four are silent on child as-set lifecycle at every layer. Across the deployed implementations that is roughly three and a half years of exactly the coexistence (015387) warns about - hierarchical mandates running over live ASN transfer markets - and I could not find one documented incident of the failure mode described. In every deployed implementation, lifecycle lives where it belongs: in standard RPSL authorisation and registry operations, not in naming-policy text. On 7.8.7 (015391, 015402): today the namespace has no rule at all - every creation, by anyone, of any name, is the exception. A closed default with documented-reason exceptions cannot be less deterministic than no default whatsoever. And credit where due: (015402) makes one point that verifies - the staff assessment's prose cites "7.8.6" for the restoration-of-deleted-objects exception, where 7.8.6 concerns editing and the exception clause is in fact 7.8.7. That is a cross-reference slip in the assessment's commentary, worth an erratum, and it changes nothing in the policy text: the clauses say what they say, and staff's own recorded caution about recall loopholes shows the right mechanism was analysed. As for the demanded exception criteria: 7.8.7 requires every exception to be documented with its reason - a discipline stricter than today, where no creation needs any reason at all. 1. Recursive expansion of members: references (015389) Correct as far as it goes - and it concedes the top level is secured. What members: may contain is a content question, expressly outside this proposal's scope, and outside the naming policies of every registry that already runs this rule: none coupled naming to expansion semantics, because that coupling is a different and larger policy. Jaco has already named the constructive path (015390): a members-qualification rule would be a coherent separate proposal, and wording was invited. Meanwhile every new hierarchical set is one fewer ambiguous reference for the next expansion to fear * the gap this concern describes narrows with adoption and stays open without it. 1. Grandfathered flat objects and the transition window (015392) The capability described - register flat names now, populate them later - exists today, permanently, with or without this proposal. Anyone may do it this afternoon. The proposal is the only mechanism before this Working Group that ever closes that window; declining it preserves the window forever. If gaming of the implementation gap is the genuine worry, the remedy is a short implementation period - a staff scheduling matter - not an indefinitely open namespace. And, respectfully: (015392) describes with precision the squatting behaviour whose future possibility this policy exists to end. An objection that demonstrates the attack is an argument for closing the door. 1. Multi-source resolution (015393) Jaco's answer (015396, 015397) is complete: an ASN is delegated by exactly one registry, so a hierarchical name carries its authoritative source in its own first element. The question "which source is authoritative for this set?" has a deterministic answer precisely and only when the name is hierarchical; under a flat name that answer does not exist anywhere. The working-group draft cited in (015393) pursues the same determinism through source-qualified references - the two mechanisms are complements, not conflicts, and that draft's problem statement describes the flat-name condition this proposal removes for new AFRINIC sets. What a third-party mirror carries is today's condition for every object in every IRR database and is governed by no naming policy at any registry. 1. Anchor-ASN eligibility and authentication (015401) Taye, this is the kind of message Last Call is for: specific, technical, and naming the exact requirements it wants. Three responses. First, on substance: the properties you list - the leading ASN globally assigned, an authoritative aut-num present, creation authenticated against that object's maintainer, private-use and reserved ranges (RFC 6996) excluded, canonical ASPLAIN form (RFC 5396) - are, I would argue, what the Impact Assessment's own authorisation claim already entails. An anchor with no holder can authorise no one; a check that can pass in the absence of the aut-num it authenticates against would not be the check the assessment describes. So I read your list not as a new mechanism but as the strict, and correct, reading of the mechanism the proposal already claims. Second, on where it belongs: those are implementation semantics - the authentication mode of the database software and the eligible ASN ranges - and I would support AFRINIC staff recording exactly your list in the implementation guidance for this policy, alongside the failure behaviour per creation path. That is the normal home of such requirements at every registry, and section 7.8.7's documented-exception mechanism gives staff the instrument for any edge the guidance must handle. It is worth adding: even in the weakest imaginable configuration, an unattributable hierarchical-form name is no worse than today, where every name of any form requires no authorisation from anyone. Third, on form: yours is the closest any message in this Last Call has come to proposed text. If you formalise that list as wording - whether as implementation guidance or as a clarification for a future revision - I have no doubt this Working Group will engage it on its merits, exactly as was invited days ago (015390). It is the constructive instrument the process recognises. 1. Implementation rollout process (015402) Warning-only phases, test vectors, baselines, rollback plans and scheduled reviews are implementation artifacts. They are produced by registry staff during implementation - at every RIR - and they appear in no naming policy anywhere: RIPE shipped its hierarchical requirement through the database release process, with release notes and a release-candidate test environment, on the strength of a policy text that contains none of those artifacts. Nothing in this proposal forbids a staged, warning-first deployment; that is exactly the kind of detail the implementation phase exists to define, and 7.8.7's documented-exception mechanism gives staff the instrument for edge handling during it. Taken at face value, (015402)'s final section is an argument about deployment scheduling, which follows ratification - not a reason to withhold it. Stepping back, twice. Each of the demands in messages (015387), (015389), (015391), (015392), (015393), (015398), (015400) and (015402) carries the same condition: "before adoption" (015387, 015389, 015391), "before mandatory enforcement" (015393), "before this proceeds" (015398), "until ... addressed" (015392), "until that is clarified" (015400), "until ... clearly resolved" (015402). As Seun reminded the list (015386), this PDP has no conditional adoption: a proposal cannot pass Last Call subject to future homework. At day eleven of Last Call, "resolve and test before advancing" therefore spells "do not adopt". The process has exactly one instrument for a genuine, fixable concern: proposed text. Jaco invited it (015390). Let me emphasise the arithmetic: seven distinct technical concerns in a single day, after eleven days without one - and, section 5's requirements list aside, still zero proposed amendments. Of the six questions of 23 July (015344), exactly one account engaged them point by point - Tshepo, in (015348) - and the record should credit those answers. In short: 1. Two-object case: tooling should bind to an explicitly selected source or stop and report - the fail-closed behaviour supporters had proposed; the live case itself stays unresolved either way, the rule being prospective. 2. Squatting remedy: none - the victim is left to another database's dispute or abuse process. 3. Is it an improvement? "Yes, narrowly." 4. Evidence bar: a four-part test - whose second criterion, that the proposal "would have prevented" the incident, excludes by construction every incident that already exists; a creation-time rule is prospective by definition. 5. Impact Assessment: "I do not dispute the findings"; the objection shifts to what the IA does not cover. 6. Capacity: individual, representing no organisation or resource member. No other opposing account has answered any of the six. Today the bar has moved with nearly every message, and a seventh question now joins the list. My assessment, for the record: none of today's objections identifies a defect in what the proposal claims; and their cumulative effect, whatever the intent, has been to consume the finite attention of this Working Group - a cost long-standing participants have already described in their own words (015154, 015179). One further observation, offered for the record and without attributing it to any individual: this Last Call's objections began from the principle that the registry "may record... It may not rule" (015011). Today's objections ask the registry to pre-define delegation graphs, revocation processes, state machines, permanent reservations, transition audits and source-selection rules, in advance (015391, 015392, 015393, 015398, 015400, 015402). Those two standards pull in opposite directions, and the same seven-clause creation-time rule cannot be faulted under both at once. Which standard the Working Group actually holds is exactly what the Co-Chairs will weigh - against what the proposal actually claims: a creation-time naming rule, whose every stated boundary today's objection messages ask it to exceed. The community is entitled to expect Last Call to close on schedule and to be assessed on the record as it stands. Regards, Hendrik Visage (AS329532; also AS213481) [CompanySignature] Inter..link GmbH | Boxhagener Stra?e 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello at inter.link | Web: inter.link -------------- next part -------------- An HTML attachment was scrubbed... URL: From aalain at trstech.net Wed Jul 29 12:19:36 2026 From: aalain at trstech.net (ALAIN AINA) Date: Wed, 29 Jul 2026 12:19:36 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal- Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT02 In-Reply-To: <1784239690230.54504@tra.gov.eg> References: <1784239690230.54504@tra.gov.eg> Message-ID: <0B2A7EB9-0739-40E1-94DC-93B94C52FD7A@trstech.net> Dear Co?chairs, The proposal, as currently written, remains vulnerable to several forms of abuse and does not align with the principles of responsible resource management, fairness, or predictability in policy application. On 15 June 2026, I proposed a more robust and technically grounded solution to the problem the proposal attempts to address, through a Multiple Discrete Networks (MDN) architecture with strict per?site utilisation rules instead of global per?organisation utilisation. Reference: https://lists.afrinic.net/pipermail/rpd/2026/014894.html The author responded that MDN issues ?may also happen in the region? but stated that this proposal is not intended to fix that problem. Reference: https://lists.afrinic.net/pipermail/rpd/2026/014895.html - Staff analysis and PPM discussions ++ Member Services (Section 3.3.4) Staff highlighted the need for anti?abuse provisions in operational procedures to allow identification of fraudulent requests. This confirms that the proposal?s current language is insufficiently constrained. ++ PPM discussions According to the PPM minutes: ? A concern was raised that the policy language is too broad and therefore subject to abuse. The author responded:??if the community later determines that staff are exercising too much discretion or using this flexibility inappropriately, the policy can be amended or clarified through future community action.? ? A concern was raised regarding the absence of a clear, objective definition of ?utilisation? within the PDP. The co?chairs committed that the Secretariat would share this definition during Last Call. To my knowledge, this definition has not yet been shared. Reference: https://afrinic.net/ppm-afrinic-37.html - Specific issues with the current text 1. Waiver criteria are extremely broad The proposal allows AFRINIC to waive the 90% utilisation requirement for: ? redundancy ? high?availability ? IPv6 transition ? expansion to new sites These are legitimate technical needs, but easy to claim without evidence, making the clause vulnerable to abuse. 2. ?Key technical purposes? is undefined The phrase is subjective and lacks operational meaning. Without a definition, Hostmasters must rely on interpretation, leading to: ? inconsistent decisions ? appeals ? pressure from members ? accusations of unfairness 3. ?Sufficiently documented? is unenforceable The proposal does not specify: ? required documentation ? required evidence ? required topology diagrams ? required utilisation metrics ? required thresholds This makes enforcement arbitrary and unpredictable. 4. Treating the request as a ?first allocation? resets utilisation This is the most problematic clause. It allows: ? utilisation to reset to 0% ? bypassing the 90% rule entirely ? repeated claims of ?new site? or ?redundancy? ? accumulation of multiple /22s without ever reaching 90% utilisation This is a major abuse vector and contradicts responsible resource management. - Possible solution (fully resolves the utilisation barrier) A predictable, enforceable solution exists and has already been proposed: 1. Replace global utilisation with per?site utilisation (MDN model) This aligns with real network architecture (multi?PoP, multi?DC, HA NAT, NAT64/464XLAT) and global RIR practice. 2. Remove ?treated as first allocation? This closes the most significant loophole. 3. Replace the waiver with a structured MDN section This ensures that exceptions are based on verifiable technical constraints, not subjective interpretation. 4. Define strict evidence requirements For example: ? topology diagrams ? BGP announcements ? NAT64/HA NAT architecture ? per?site utilisation metrics ? proof of disaggregation ? proof of IPv6 transition deployment 5. Allow per?site redundancy headroom To support HA and failover, allow sub?allocation to any MDN site at 85% utilisation instead of 90%. This approach is technically sound, operationally enforceable, and consistent with the principles of fairness and responsible resource management. Regards, ?Alain > On 16 Jul 2026, at 22:08, Hytham El-Nakhal wrote: > > Dear PDWG, > > > Last Call: Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) > > > The Policy Development Working Group (PDWG )Chairs have initiated a Last Call for this proposal, following rough consensus at the AFRINIC-37 Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June 2026. > > > * Proposal Name: Amendment of Utilisation in Soft Landing > > * Proposal ID: AFPUB-2026-IPv4-002-DRAFT02 > > * Proposal URL: https://www.afrinic.net/afpub-2026-ipv4-002-draft02.html > > . > > Last Call closes on : July 31, 2026, at 23:59 UTC. > > > The Secretariat will provide an operational definition of "utilisation" during this period to assist with final community review. > > > As always, we kindly request that all participants adhere to the AFRINIC Code of Conduct to maintain a respectful and professional environment on the mailing list. > > > Kind regards, > > > Haitham el Nakhal > > AFRINIC PDWG Co-Chair > > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd From james at inter.link Wed Jul 29 12:26:30 2026 From: james at inter.link (James Bensley) Date: Wed, 29 Jul 2026 12:26:30 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <3D148AE6-C8EF-4C22-A732-779C362791CB@hevis.co.za> Message-ID: Dear Tshepo, After careful consideration I have decided not to revise the draft. There are a couple of reasons for this: * I think this is becoming too prescriptive. If we try to define a time period for restoration for example, for some people it will be too long, for others too short. We have no data to make an informed decision here. Similarly the point about having a public log. That requires us to define what that looks like and how it works. We have no idea how often this process would be enacted so we can't described what that needs to look like. We have no data. I think trying to make a perfect policy that covers all cases is the wrong approach. I think we should be aiming to get "something" implemented, let it run for a while, gather feedback, and then if it needs adjusting, we can raise another policy change proposal. Nothing is set in stone here. There's no need to get his perfect first time, we can iterate over time. * Any changes to the draft will restart the Last Call and potentially also require the staff to re-review the draft. The changes you proposed, whilst valid, are optimising for a corner case (how often to people delete their AS-SET by mistake? I would say, rarely). Why delay getting "something" deployed, which we can continue to iterate on, just to optimise for a corner case (restores aren't blocked by this policy)? For these reasons I have decided not to modify the draft. With kind regards, James Bensley (he/him) ________________________________ From: Tshepo Masuku Sent: 28 July 2026 15:28 To: James Bensley ; rpd at afrinic.net ; pdwg-chairs at afrinic.net Subject: Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Dear James, Thank you for engaging with the concern constructively. Your proposed wording is a meaningful improvement because it begins replacing an open-ended exception with objective conditions. I think a few points still need tightening before the rule is ready: * Restoration should return the object to its last valid archived state, not merely reuse the same key. Otherwise, an old flat name could be restored with entirely different contents and become a new object in substance. * The text should define whether the restoration right is permanent or subject to a recovery period. * ?Another maintainer within the same organisation? and an organisation ?responsible for the assets? require objective evidence, such as registry history or documented legal succession. Those terms should not be left entirely to staff interpretation. * The residual case-by-case provision should expressly prohibit creating a flat name that did not exist before implementation. * Every exceptional decision should record the evidence relied upon and provide a review or appeal path, not merely an audit entry. I would also suggest wording along these lines: A restored object shall initially reflect its last valid archived state, except that maintainer and contact attributes may be updated where necessary to establish control by the verified original holder or lawful successor. Because this changes the normative enforcement boundary, I believe v3 should be published with an updated Impact Assessment and receive proper review. It should not be treated as a minor editorial correction during the final days of Last Call. I remain opposed to DRAFT02 as written, but I appreciate your willingness to address the defect directly. This is the kind of concrete engagement that adds value to the process. Regards, Tshepo ________________________________ From: James Bensley Sent: Tuesday, 28 July 2026 13:39:50 To: Tshepo Masuku ; rpd at afrinic.net ; pdwg-chairs at afrinic.net Subject: Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Dear Tshepo, Thank you for providing your feedback. I am in agreement with your statement. I am the original author of this draft change, and I wrote in my last update (version 2): "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." The staff assessment was to go with the following "7.8.7 Exceptions for the creation of hierarchical names may be granted where necessary. AFRINIC shall document the reason for any exception.". The staff asked me to review their assessment and I initially agreed, because it was loser than my definition. There may be other scenarios where restoration is required which I/we haven't thought of, so why limit it to accidental deletion only. Opening it up to allow any case to be reviewed has benefits. But as you say, it could also go the other way, it could simply mean that every case is rejected. I am going to submit another version (v3) of the document, only replacing the text I quoted above, with the text below, to fix the problem you raised of the text having gone from being too strict before to now being too lose (I will try to propose something in the middle which guarantees delete/restoration is protected, anything else needs a review). I am proposing the following text, what do you think? ------ A non-hierarchical AS-SET existing before implementation of this policy change, which has since been deleted, must be restorable when the following conditions are met: - The same object key is requested for restoration (no AS-SET name changes allowed) - No object with a conflicting name has been created between the date of deletion and the date the restore is made - The restore request is coming from either a maintainer that was present on the deleted object, or another maintainer within the same organisation (in the case the maintainer was also deleted), or a maintainer in an organisation responsible for the assets of the original organisation (in the case of a merger or acquisition). - The restoration is recorded in an auditable log. Any other request for restoring a deleted AS-SET created before the implementation date of this policy change will need to be reviewed by AFRINIC on a case by case basis. ------- With kind regards, James Bensley (he/him) ________________________________ From: Tshepo Masuku Sent: 27 July 2026 15:29 To: hvisage at hevis.co.za ; Nonjabulo Sphilile ; Phetulo Dhlamini ; Taye Medoye ; Thulisile Mazomba ; rpd at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) ?? Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. Dear Hendrik and colleagues, Thank you for consolidating the discussion. I will not repeat the earlier lifecycle, resolver, delegation, or membership arguments. There is, however, a separate defect in the actual text being considered. The proposal says that exceptions MUST be allowed on a case-by-case basis and gives restoration of an accidentally deleted flat AS-SET as the example. The staff-recommended wording instead says exceptions may be granted ?where necessary.? These are materially different rules. Under the first version, an eligible operator has a right to restoration. Under the second, restoration depends on AFRINIC?s discretion. The wording also changes a narrow restoration example into an undefined general exception. That produces a concrete operational difference. If a grandfathered flat AS-SET is accidentally deleted after implementation, one version requires a restoration path while the other allows AFRINIC to refuse it. Operators and peers referencing that object cannot know which outcome the adopted policy guarantees. This is not an adjacent lifecycle problem. It is the enforcement boundary of the present proposal. The text should therefore be amended to provide one deterministic rule. For example: > A non-hierarchical AS-SET existing before commencement may be restored only where the same object key is requested within a defined recovery period, the request is authenticated by the maintainer authorised immediately before deletion, no conflicting object has intervened, and the restoration is recorded in an auditable log. No other exception may authorise creation of a new non-hierarchical AS-SET. That would preserve accidental-deletion recovery without leaving the supposedly closed namespace subject to undefined staff judgment. Documenting the reason after an exception is granted is not the same as defining the conditions under which the exception is valid. Implementation guidance also cannot resolve a conflict between ?MUST? and ?may? after ratification. Before Last Call closes, the authors and co-chairs should identify which wording is actually under consideration and resolve the difference in normative force. Until then, I remain opposed to the proposal as written. Regards, Tshepo ________________________________ From: hvisage at hevis.co.za Sent: Monday, 27 July 2026 15:11:31 To: Tshepo Masuku ; Nonjabulo Sphilile ; Phetulo Dhlamini ; Taye Medoye ; Thulisile Mazomba ; rpd at afrinic.net Subject: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Good day Tshepo, Nonjabulo, Phetulo, Taye, Thulisile, colleagues, Apologies to the human readers for this voluminous post, but I?d rather address as much in one email than to flood the mailing list With even more messages as I?d rather do a digest type response for all the similar objections at once. For nearly two weeks we have been asking for technical substance; today, in the week Last Call closes, technical reasons have at last been presented. Before I respond to them, let me add a seventh question to the six of 23 July (015344): Question 7: could you please provide the technical issues, difficulties, and real-world examples where implementation of this draft policy - as three RIRs have already implemented it, and the fourth is formally proposing - would negatively affect your current or future operations? We would like to understand those too. Operational evidence of that kind would genuinely add to the body of knowledge on this proposal. Note: numbers like (015344) are message IDs in the RPD archive - prepend https://lists.afrinic.net/pipermail/rpd/2026/ and append .html to read any of them. So let's get to the objections we have been waiting two weeks for: 1. object lifecycle under changes of ASN control (015387, escalated in 015391 and 015400) - answered by Jaco in (015388) and (015394) 1b) its delegated-maintainer extension (015398, pressed again in 015400) - Jaco deferred to the RFC in (015399); the deferral is completed in section 1 below 2) recursive expansion of members: references (015389) - answered in (015390) 3) grandfathered flat objects (015392) - answered in (015395) 4) multi-source name resolution (015393) - answered in (015396, 015397) 5) anchor-ASN eligibility and authentication (015401) - addressed in section 5 below 6) implementation rollout process (015402) - addressed in section 6 below; its delegation and 7.8.7 points are answered in section 1 (the delegation question is 015398/015400 returning), and its benefit-scope point in the common ground just below I refer to and endorse Jaco's answers rather than repeat them. It was asked earlier in this Last Call that objections be addressed as grouped issues rather than piecemeal, and in that spirit I have collated the responses in a single email, adding what has not yet been shared: a precise statement of the authorisation model, the published data, and the cross-registry record. First, the common ground, because it is substantial. In today's own words: * hierarchical naming "can strengthen creation authorisation" (015393) * the proposal "secures the first object name" (015389) * the concerns are "not questions about whether AS-SET membership is correct" (015387) * ASN-anchored naming "can reduce future flat-name collisions" (015402) None of today's messages disputes what the proposal does. Each of today's objections asks it to also solve an adjacent problem - * lifecycle * delegation semantics * expansion semantics * legacy objects * mirror copies * anchor eligibility * and every one of those problems exists today, everywhere, with or without this policy. That is not the discovery of a defect. It is the discovery that the proposal has a scope, which it states and which was put on this record weeks ago (015119, 015120, 015123; and the draft's own sections 7.8.3-7.8.6). 1. The authorisation model, changes of ASN control, and delegation (015387, 015391, 015398, 015400, 015402) Jaco deferred to the RFC on the depth mechanics (015399). Rightly so - the RFC, followed to the top of the chain, completes his answer. (015398) states the rule correctly: a first-level object, AS12345:AS-CUSTOMERS, is created under the authorisation of the aut-num AS12345 as it stands at that moment - its maintainer chain, which follows the current registered holder. A deeper object, AS12345:AS-CUSTOMERS:AS-EU, is created under the authorisation of the maintainer of its immediate parent. Now ask where that parent came from: its own creation was authorised by the level above it, and so on, terminating at the aut-num itself. Every object in the tree exists because the level above authorised its creation. Delegation, where it exists, exists because the chain authorised it. And who controls each level is answerable, level by level, from the database as it stands - which is what verifiable control looks like in RPSL. The emphatic difference at the current state is that a flat name offers just a maintainer but no chain: no root, and no way to ask whether the name was ever anyone's to create - beyond that it must not already exist in THIS one database. (015400) concludes that because deeper control can be delegated, the "control model remains unspecified". The opposite is the case: the control model is fully specified - in the very RFC that (015398) cited, which is why deferring to it was the right answer. That deeper authority is delegated, and that delegated authority does not automatically follow the ASN, is not a gap in the model; it is the model, working as designed for twenty-seven years, for every hierarchical object family, at every RPSL-based registry. A policy does not "leave AFRINIC to interpret" what the RFC and the production database already define - any more than this proposal needs to restate what mnt-by means. What deterministically follows the ASN is the root of every chain: authority over creation and recreation at the first level of the namespace. That is precisely * and only - what the proposal's attribution claim covers. The same depth question returns in (015402); the answer above stands. These semantics are not invented by this proposal. They are RFC 2622 (1999), operated by RPSL-based registries - AFRINIC's included * for twenty-seven years. The proposal does not modify them; it gates which names may come into existence, nothing else. The two outcomes (015398) poses are therefore both answered by the semantics already in production: descendants do not move automatically, so no delegated maintainer is overridden - exactly as for every delegated object today. And the new holder gains precisely what the name anchors: authority over creation and recreation at the first level of its namespace. What the new holder does not get - control over objects a previous holder's delegates still maintain - is what nobody has today under flat names, for any object, ever. A stale delegated descendant is today's universal condition; the proposal neither creates nor worsens it, and no registry in those twenty-seven years has defined the demanded delegation-and-revocation regime for set objects in policy. How ASN control actually changes in this region is likewise not a matter for speculation. AFRINIC publishes it: https://ftp.afrinic.net/pub/stats/afrinic/transfers/transfers_latest.json A full read of that file today: 75 ASN-carrying transfer events (91 ASNs) from 2018 through 2026 - about nine such events a year - and every single one is a merger/acquisition succession, in which the organisation and its maintainer control pass together, so parent ASN and child objects move as one unit. That is the published record behind Jaco's description in (015394), with the frequency question answered exactly: none open-market, all successions that preserve the attribution chain by construction. Anyone can verify this from the file. So the concern of (015391) has been addressed - with our registry's own data. The cross-registry record answers the rest. I checked this week, across the policy, procedural and database-documentation layers of the other four RIRs. RIPE has required hierarchical names for new as-sets since December 2022 and operates full ASN transfers, including inter-RIR; APNIC likewise since July 2023 (prop-151); LACNIC's IRR has been structurally hierarchical since it launched in 2020; at ARIN hierarchical naming is available today and a mandate for new objects is formally proposed (ARIN-prop-342, pending) - the same direction. All four are silent on child as-set lifecycle at every layer. Across the deployed implementations that is roughly three and a half years of exactly the coexistence (015387) warns about - hierarchical mandates running over live ASN transfer markets - and I could not find one documented incident of the failure mode described. In every deployed implementation, lifecycle lives where it belongs: in standard RPSL authorisation and registry operations, not in naming-policy text. On 7.8.7 (015391, 015402): today the namespace has no rule at all - every creation, by anyone, of any name, is the exception. A closed default with documented-reason exceptions cannot be less deterministic than no default whatsoever. And credit where due: (015402) makes one point that verifies - the staff assessment's prose cites "7.8.6" for the restoration-of-deleted-objects exception, where 7.8.6 concerns editing and the exception clause is in fact 7.8.7. That is a cross-reference slip in the assessment's commentary, worth an erratum, and it changes nothing in the policy text: the clauses say what they say, and staff's own recorded caution about recall loopholes shows the right mechanism was analysed. As for the demanded exception criteria: 7.8.7 requires every exception to be documented with its reason - a discipline stricter than today, where no creation needs any reason at all. 1. Recursive expansion of members: references (015389) Correct as far as it goes - and it concedes the top level is secured. What members: may contain is a content question, expressly outside this proposal's scope, and outside the naming policies of every registry that already runs this rule: none coupled naming to expansion semantics, because that coupling is a different and larger policy. Jaco has already named the constructive path (015390): a members-qualification rule would be a coherent separate proposal, and wording was invited. Meanwhile every new hierarchical set is one fewer ambiguous reference for the next expansion to fear * the gap this concern describes narrows with adoption and stays open without it. 1. Grandfathered flat objects and the transition window (015392) The capability described - register flat names now, populate them later - exists today, permanently, with or without this proposal. Anyone may do it this afternoon. The proposal is the only mechanism before this Working Group that ever closes that window; declining it preserves the window forever. If gaming of the implementation gap is the genuine worry, the remedy is a short implementation period - a staff scheduling matter - not an indefinitely open namespace. And, respectfully: (015392) describes with precision the squatting behaviour whose future possibility this policy exists to end. An objection that demonstrates the attack is an argument for closing the door. 1. Multi-source resolution (015393) Jaco's answer (015396, 015397) is complete: an ASN is delegated by exactly one registry, so a hierarchical name carries its authoritative source in its own first element. The question "which source is authoritative for this set?" has a deterministic answer precisely and only when the name is hierarchical; under a flat name that answer does not exist anywhere. The working-group draft cited in (015393) pursues the same determinism through source-qualified references - the two mechanisms are complements, not conflicts, and that draft's problem statement describes the flat-name condition this proposal removes for new AFRINIC sets. What a third-party mirror carries is today's condition for every object in every IRR database and is governed by no naming policy at any registry. 1. Anchor-ASN eligibility and authentication (015401) Taye, this is the kind of message Last Call is for: specific, technical, and naming the exact requirements it wants. Three responses. First, on substance: the properties you list - the leading ASN globally assigned, an authoritative aut-num present, creation authenticated against that object's maintainer, private-use and reserved ranges (RFC 6996) excluded, canonical ASPLAIN form (RFC 5396) - are, I would argue, what the Impact Assessment's own authorisation claim already entails. An anchor with no holder can authorise no one; a check that can pass in the absence of the aut-num it authenticates against would not be the check the assessment describes. So I read your list not as a new mechanism but as the strict, and correct, reading of the mechanism the proposal already claims. Second, on where it belongs: those are implementation semantics - the authentication mode of the database software and the eligible ASN ranges - and I would support AFRINIC staff recording exactly your list in the implementation guidance for this policy, alongside the failure behaviour per creation path. That is the normal home of such requirements at every registry, and section 7.8.7's documented-exception mechanism gives staff the instrument for any edge the guidance must handle. It is worth adding: even in the weakest imaginable configuration, an unattributable hierarchical-form name is no worse than today, where every name of any form requires no authorisation from anyone. Third, on form: yours is the closest any message in this Last Call has come to proposed text. If you formalise that list as wording - whether as implementation guidance or as a clarification for a future revision - I have no doubt this Working Group will engage it on its merits, exactly as was invited days ago (015390). It is the constructive instrument the process recognises. 1. Implementation rollout process (015402) Warning-only phases, test vectors, baselines, rollback plans and scheduled reviews are implementation artifacts. They are produced by registry staff during implementation - at every RIR - and they appear in no naming policy anywhere: RIPE shipped its hierarchical requirement through the database release process, with release notes and a release-candidate test environment, on the strength of a policy text that contains none of those artifacts. Nothing in this proposal forbids a staged, warning-first deployment; that is exactly the kind of detail the implementation phase exists to define, and 7.8.7's documented-exception mechanism gives staff the instrument for edge handling during it. Taken at face value, (015402)'s final section is an argument about deployment scheduling, which follows ratification - not a reason to withhold it. Stepping back, twice. Each of the demands in messages (015387), (015389), (015391), (015392), (015393), (015398), (015400) and (015402) carries the same condition: "before adoption" (015387, 015389, 015391), "before mandatory enforcement" (015393), "before this proceeds" (015398), "until ... addressed" (015392), "until that is clarified" (015400), "until ... clearly resolved" (015402). As Seun reminded the list (015386), this PDP has no conditional adoption: a proposal cannot pass Last Call subject to future homework. At day eleven of Last Call, "resolve and test before advancing" therefore spells "do not adopt". The process has exactly one instrument for a genuine, fixable concern: proposed text. Jaco invited it (015390). Let me emphasise the arithmetic: seven distinct technical concerns in a single day, after eleven days without one - and, section 5's requirements list aside, still zero proposed amendments. Of the six questions of 23 July (015344), exactly one account engaged them point by point - Tshepo, in (015348) - and the record should credit those answers. In short: 1. Two-object case: tooling should bind to an explicitly selected source or stop and report - the fail-closed behaviour supporters had proposed; the live case itself stays unresolved either way, the rule being prospective. 2. Squatting remedy: none - the victim is left to another database's dispute or abuse process. 3. Is it an improvement? "Yes, narrowly." 4. Evidence bar: a four-part test - whose second criterion, that the proposal "would have prevented" the incident, excludes by construction every incident that already exists; a creation-time rule is prospective by definition. 5. Impact Assessment: "I do not dispute the findings"; the objection shifts to what the IA does not cover. 6. Capacity: individual, representing no organisation or resource member. No other opposing account has answered any of the six. Today the bar has moved with nearly every message, and a seventh question now joins the list. My assessment, for the record: none of today's objections identifies a defect in what the proposal claims; and their cumulative effect, whatever the intent, has been to consume the finite attention of this Working Group - a cost long-standing participants have already described in their own words (015154, 015179). One further observation, offered for the record and without attributing it to any individual: this Last Call's objections began from the principle that the registry "may record... It may not rule" (015011). Today's objections ask the registry to pre-define delegation graphs, revocation processes, state machines, permanent reservations, transition audits and source-selection rules, in advance (015391, 015392, 015393, 015398, 015400, 015402). Those two standards pull in opposite directions, and the same seven-clause creation-time rule cannot be faulted under both at once. Which standard the Working Group actually holds is exactly what the Co-Chairs will weigh - against what the proposal actually claims: a creation-time naming rule, whose every stated boundary today's objection messages ask it to exceed. The community is entitled to expect Last Call to close on schedule and to be assessed on the record as it stands. Regards, Hendrik Visage (AS329532; also AS213481) [CompanySignature] Inter..link GmbH | Boxhagener Stra?e 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello at inter.link | Web: inter.link -------------- next part -------------- An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Wed Jul 29 13:48:38 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Wed, 29 Jul 2026 13:48:38 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <3D148AE6-C8EF-4C22-A732-779C362791CB@hevis.co.za> Message-ID: Dear James, Thank you for considering the concern carefully and explaining your decision openly. I genuinely appreciate that you engaged with the substance rather than simply dismissing it. I understand the case for incremental improvement and agree that no policy can anticipate every future scenario. My concern, however, is not that the draft must be perfect. It is that the exception clause sits at the boundary of what AFRINIC will be required, or permitted, to enforce. The absence of data cuts both ways. If we do not know how frequently restoration will be needed, that uncertainty does not necessarily justify leaving the criteria undefined. It may instead support beginning with a narrow, objective restoration rule and expanding it later if operational evidence shows that broader exceptions are necessary. I also do not think restarting Last Call is, by itself, a sufficient reason to retain ambiguous wording. Once adopted, the policy will be binding until another proposal completes the PDP. During that period, AFRINIC will have to interpret ?where necessary? without agreed criteria. That is not quite the same as a temporary implementation experiment. A narrowly drafted restoration safeguard would not be an attempt to build the whole castle at once. It would simply make the first brick clear enough that operators and staff know what it permits. The common layer should be minimal, but what it contains should also be deterministic and auditable. I respect your decision not to revise the draft, and I appreciate your constructive approach. However, because the difference between a guaranteed restoration right and discretionary case-by-case approval remains unresolved, I cannot support the proposal as currently written and therefore maintain my objection. kind regards, Tshepo ________________________________ From: James Bensley Sent: Wednesday, 29 July 2026 14:26:30 To: Tshepo Masuku ; rpd at afrinic.net ; pdwg-chairs at afrinic.net Subject: Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Dear Tshepo, After careful consideration I have decided not to revise the draft. There are a couple of reasons for this: * I think this is becoming too prescriptive. If we try to define a time period for restoration for example, for some people it will be too long, for others too short. We have no data to make an informed decision here. Similarly the point about having a public log. That requires us to define what that looks like and how it works. We have no idea how often this process would be enacted so we can't described what that needs to look like. We have no data. I think trying to make a perfect policy that covers all cases is the wrong approach. I think we should be aiming to get "something" implemented, let it run for a while, gather feedback, and then if it needs adjusting, we can raise another policy change proposal. Nothing is set in stone here. There's no need to get his perfect first time, we can iterate over time. * Any changes to the draft will restart the Last Call and potentially also require the staff to re-review the draft. The changes you proposed, whilst valid, are optimising for a corner case (how often to people delete their AS-SET by mistake? I would say, rarely). Why delay getting "something" deployed, which we can continue to iterate on, just to optimise for a corner case (restores aren't blocked by this policy)? For these reasons I have decided not to modify the draft. With kind regards, James Bensley (he/him) ________________________________ From: Tshepo Masuku Sent: 28 July 2026 15:28 To: James Bensley ; rpd at afrinic.net ; pdwg-chairs at afrinic.net Subject: Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Dear James, Thank you for engaging with the concern constructively. Your proposed wording is a meaningful improvement because it begins replacing an open-ended exception with objective conditions. I think a few points still need tightening before the rule is ready: * Restoration should return the object to its last valid archived state, not merely reuse the same key. Otherwise, an old flat name could be restored with entirely different contents and become a new object in substance. * The text should define whether the restoration right is permanent or subject to a recovery period. * ?Another maintainer within the same organisation? and an organisation ?responsible for the assets? require objective evidence, such as registry history or documented legal succession. Those terms should not be left entirely to staff interpretation. * The residual case-by-case provision should expressly prohibit creating a flat name that did not exist before implementation. * Every exceptional decision should record the evidence relied upon and provide a review or appeal path, not merely an audit entry. I would also suggest wording along these lines: A restored object shall initially reflect its last valid archived state, except that maintainer and contact attributes may be updated where necessary to establish control by the verified original holder or lawful successor. Because this changes the normative enforcement boundary, I believe v3 should be published with an updated Impact Assessment and receive proper review. It should not be treated as a minor editorial correction during the final days of Last Call. I remain opposed to DRAFT02 as written, but I appreciate your willingness to address the defect directly. This is the kind of concrete engagement that adds value to the process. Regards, Tshepo ________________________________ From: James Bensley Sent: Tuesday, 28 July 2026 13:39:50 To: Tshepo Masuku ; rpd at afrinic.net ; pdwg-chairs at afrinic.net Subject: Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Dear Tshepo, Thank you for providing your feedback. I am in agreement with your statement. I am the original author of this draft change, and I wrote in my last update (version 2): "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." The staff assessment was to go with the following "7.8.7 Exceptions for the creation of hierarchical names may be granted where necessary. AFRINIC shall document the reason for any exception.". The staff asked me to review their assessment and I initially agreed, because it was loser than my definition. There may be other scenarios where restoration is required which I/we haven't thought of, so why limit it to accidental deletion only. Opening it up to allow any case to be reviewed has benefits. But as you say, it could also go the other way, it could simply mean that every case is rejected. I am going to submit another version (v3) of the document, only replacing the text I quoted above, with the text below, to fix the problem you raised of the text having gone from being too strict before to now being too lose (I will try to propose something in the middle which guarantees delete/restoration is protected, anything else needs a review). I am proposing the following text, what do you think? ------ A non-hierarchical AS-SET existing before implementation of this policy change, which has since been deleted, must be restorable when the following conditions are met: - The same object key is requested for restoration (no AS-SET name changes allowed) - No object with a conflicting name has been created between the date of deletion and the date the restore is made - The restore request is coming from either a maintainer that was present on the deleted object, or another maintainer within the same organisation (in the case the maintainer was also deleted), or a maintainer in an organisation responsible for the assets of the original organisation (in the case of a merger or acquisition). - The restoration is recorded in an auditable log. Any other request for restoring a deleted AS-SET created before the implementation date of this policy change will need to be reviewed by AFRINIC on a case by case basis. ------- With kind regards, James Bensley (he/him) ________________________________ From: Tshepo Masuku Sent: 27 July 2026 15:29 To: hvisage at hevis.co.za ; Nonjabulo Sphilile ; Phetulo Dhlamini ; Taye Medoye ; Thulisile Mazomba ; rpd at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) ?? Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. Dear Hendrik and colleagues, Thank you for consolidating the discussion. I will not repeat the earlier lifecycle, resolver, delegation, or membership arguments. There is, however, a separate defect in the actual text being considered. The proposal says that exceptions MUST be allowed on a case-by-case basis and gives restoration of an accidentally deleted flat AS-SET as the example. The staff-recommended wording instead says exceptions may be granted ?where necessary.? These are materially different rules. Under the first version, an eligible operator has a right to restoration. Under the second, restoration depends on AFRINIC?s discretion. The wording also changes a narrow restoration example into an undefined general exception. That produces a concrete operational difference. If a grandfathered flat AS-SET is accidentally deleted after implementation, one version requires a restoration path while the other allows AFRINIC to refuse it. Operators and peers referencing that object cannot know which outcome the adopted policy guarantees. This is not an adjacent lifecycle problem. It is the enforcement boundary of the present proposal. The text should therefore be amended to provide one deterministic rule. For example: > A non-hierarchical AS-SET existing before commencement may be restored only where the same object key is requested within a defined recovery period, the request is authenticated by the maintainer authorised immediately before deletion, no conflicting object has intervened, and the restoration is recorded in an auditable log. No other exception may authorise creation of a new non-hierarchical AS-SET. That would preserve accidental-deletion recovery without leaving the supposedly closed namespace subject to undefined staff judgment. Documenting the reason after an exception is granted is not the same as defining the conditions under which the exception is valid. Implementation guidance also cannot resolve a conflict between ?MUST? and ?may? after ratification. Before Last Call closes, the authors and co-chairs should identify which wording is actually under consideration and resolve the difference in normative force. Until then, I remain opposed to the proposal as written. Regards, Tshepo ________________________________ From: hvisage at hevis.co.za Sent: Monday, 27 July 2026 15:11:31 To: Tshepo Masuku ; Nonjabulo Sphilile ; Phetulo Dhlamini ; Taye Medoye ; Thulisile Mazomba ; rpd at afrinic.net Subject: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Good day Tshepo, Nonjabulo, Phetulo, Taye, Thulisile, colleagues, Apologies to the human readers for this voluminous post, but I?d rather address as much in one email than to flood the mailing list With even more messages as I?d rather do a digest type response for all the similar objections at once. For nearly two weeks we have been asking for technical substance; today, in the week Last Call closes, technical reasons have at last been presented. Before I respond to them, let me add a seventh question to the six of 23 July (015344): Question 7: could you please provide the technical issues, difficulties, and real-world examples where implementation of this draft policy - as three RIRs have already implemented it, and the fourth is formally proposing - would negatively affect your current or future operations? We would like to understand those too. Operational evidence of that kind would genuinely add to the body of knowledge on this proposal. Note: numbers like (015344) are message IDs in the RPD archive - prepend https://lists.afrinic.net/pipermail/rpd/2026/ and append .html to read any of them. So let's get to the objections we have been waiting two weeks for: 1. object lifecycle under changes of ASN control (015387, escalated in 015391 and 015400) - answered by Jaco in (015388) and (015394) 1b) its delegated-maintainer extension (015398, pressed again in 015400) - Jaco deferred to the RFC in (015399); the deferral is completed in section 1 below 2) recursive expansion of members: references (015389) - answered in (015390) 3) grandfathered flat objects (015392) - answered in (015395) 4) multi-source name resolution (015393) - answered in (015396, 015397) 5) anchor-ASN eligibility and authentication (015401) - addressed in section 5 below 6) implementation rollout process (015402) - addressed in section 6 below; its delegation and 7.8.7 points are answered in section 1 (the delegation question is 015398/015400 returning), and its benefit-scope point in the common ground just below I refer to and endorse Jaco's answers rather than repeat them. It was asked earlier in this Last Call that objections be addressed as grouped issues rather than piecemeal, and in that spirit I have collated the responses in a single email, adding what has not yet been shared: a precise statement of the authorisation model, the published data, and the cross-registry record. First, the common ground, because it is substantial. In today's own words: * hierarchical naming "can strengthen creation authorisation" (015393) * the proposal "secures the first object name" (015389) * the concerns are "not questions about whether AS-SET membership is correct" (015387) * ASN-anchored naming "can reduce future flat-name collisions" (015402) None of today's messages disputes what the proposal does. Each of today's objections asks it to also solve an adjacent problem - * lifecycle * delegation semantics * expansion semantics * legacy objects * mirror copies * anchor eligibility * and every one of those problems exists today, everywhere, with or without this policy. That is not the discovery of a defect. It is the discovery that the proposal has a scope, which it states and which was put on this record weeks ago (015119, 015120, 015123; and the draft's own sections 7.8.3-7.8.6). 1. The authorisation model, changes of ASN control, and delegation (015387, 015391, 015398, 015400, 015402) Jaco deferred to the RFC on the depth mechanics (015399). Rightly so - the RFC, followed to the top of the chain, completes his answer. (015398) states the rule correctly: a first-level object, AS12345:AS-CUSTOMERS, is created under the authorisation of the aut-num AS12345 as it stands at that moment - its maintainer chain, which follows the current registered holder. A deeper object, AS12345:AS-CUSTOMERS:AS-EU, is created under the authorisation of the maintainer of its immediate parent. Now ask where that parent came from: its own creation was authorised by the level above it, and so on, terminating at the aut-num itself. Every object in the tree exists because the level above authorised its creation. Delegation, where it exists, exists because the chain authorised it. And who controls each level is answerable, level by level, from the database as it stands - which is what verifiable control looks like in RPSL. The emphatic difference at the current state is that a flat name offers just a maintainer but no chain: no root, and no way to ask whether the name was ever anyone's to create - beyond that it must not already exist in THIS one database. (015400) concludes that because deeper control can be delegated, the "control model remains unspecified". The opposite is the case: the control model is fully specified - in the very RFC that (015398) cited, which is why deferring to it was the right answer. That deeper authority is delegated, and that delegated authority does not automatically follow the ASN, is not a gap in the model; it is the model, working as designed for twenty-seven years, for every hierarchical object family, at every RPSL-based registry. A policy does not "leave AFRINIC to interpret" what the RFC and the production database already define - any more than this proposal needs to restate what mnt-by means. What deterministically follows the ASN is the root of every chain: authority over creation and recreation at the first level of the namespace. That is precisely * and only - what the proposal's attribution claim covers. The same depth question returns in (015402); the answer above stands. These semantics are not invented by this proposal. They are RFC 2622 (1999), operated by RPSL-based registries - AFRINIC's included * for twenty-seven years. The proposal does not modify them; it gates which names may come into existence, nothing else. The two outcomes (015398) poses are therefore both answered by the semantics already in production: descendants do not move automatically, so no delegated maintainer is overridden - exactly as for every delegated object today. And the new holder gains precisely what the name anchors: authority over creation and recreation at the first level of its namespace. What the new holder does not get - control over objects a previous holder's delegates still maintain - is what nobody has today under flat names, for any object, ever. A stale delegated descendant is today's universal condition; the proposal neither creates nor worsens it, and no registry in those twenty-seven years has defined the demanded delegation-and-revocation regime for set objects in policy. How ASN control actually changes in this region is likewise not a matter for speculation. AFRINIC publishes it: https://ftp.afrinic.net/pub/stats/afrinic/transfers/transfers_latest.json A full read of that file today: 75 ASN-carrying transfer events (91 ASNs) from 2018 through 2026 - about nine such events a year - and every single one is a merger/acquisition succession, in which the organisation and its maintainer control pass together, so parent ASN and child objects move as one unit. That is the published record behind Jaco's description in (015394), with the frequency question answered exactly: none open-market, all successions that preserve the attribution chain by construction. Anyone can verify this from the file. So the concern of (015391) has been addressed - with our registry's own data. The cross-registry record answers the rest. I checked this week, across the policy, procedural and database-documentation layers of the other four RIRs. RIPE has required hierarchical names for new as-sets since December 2022 and operates full ASN transfers, including inter-RIR; APNIC likewise since July 2023 (prop-151); LACNIC's IRR has been structurally hierarchical since it launched in 2020; at ARIN hierarchical naming is available today and a mandate for new objects is formally proposed (ARIN-prop-342, pending) - the same direction. All four are silent on child as-set lifecycle at every layer. Across the deployed implementations that is roughly three and a half years of exactly the coexistence (015387) warns about - hierarchical mandates running over live ASN transfer markets - and I could not find one documented incident of the failure mode described. In every deployed implementation, lifecycle lives where it belongs: in standard RPSL authorisation and registry operations, not in naming-policy text. On 7.8.7 (015391, 015402): today the namespace has no rule at all - every creation, by anyone, of any name, is the exception. A closed default with documented-reason exceptions cannot be less deterministic than no default whatsoever. And credit where due: (015402) makes one point that verifies - the staff assessment's prose cites "7.8.6" for the restoration-of-deleted-objects exception, where 7.8.6 concerns editing and the exception clause is in fact 7.8.7. That is a cross-reference slip in the assessment's commentary, worth an erratum, and it changes nothing in the policy text: the clauses say what they say, and staff's own recorded caution about recall loopholes shows the right mechanism was analysed. As for the demanded exception criteria: 7.8.7 requires every exception to be documented with its reason - a discipline stricter than today, where no creation needs any reason at all. 1. Recursive expansion of members: references (015389) Correct as far as it goes - and it concedes the top level is secured. What members: may contain is a content question, expressly outside this proposal's scope, and outside the naming policies of every registry that already runs this rule: none coupled naming to expansion semantics, because that coupling is a different and larger policy. Jaco has already named the constructive path (015390): a members-qualification rule would be a coherent separate proposal, and wording was invited. Meanwhile every new hierarchical set is one fewer ambiguous reference for the next expansion to fear * the gap this concern describes narrows with adoption and stays open without it. 1. Grandfathered flat objects and the transition window (015392) The capability described - register flat names now, populate them later - exists today, permanently, with or without this proposal. Anyone may do it this afternoon. The proposal is the only mechanism before this Working Group that ever closes that window; declining it preserves the window forever. If gaming of the implementation gap is the genuine worry, the remedy is a short implementation period - a staff scheduling matter - not an indefinitely open namespace. And, respectfully: (015392) describes with precision the squatting behaviour whose future possibility this policy exists to end. An objection that demonstrates the attack is an argument for closing the door. 1. Multi-source resolution (015393) Jaco's answer (015396, 015397) is complete: an ASN is delegated by exactly one registry, so a hierarchical name carries its authoritative source in its own first element. The question "which source is authoritative for this set?" has a deterministic answer precisely and only when the name is hierarchical; under a flat name that answer does not exist anywhere. The working-group draft cited in (015393) pursues the same determinism through source-qualified references - the two mechanisms are complements, not conflicts, and that draft's problem statement describes the flat-name condition this proposal removes for new AFRINIC sets. What a third-party mirror carries is today's condition for every object in every IRR database and is governed by no naming policy at any registry. 1. Anchor-ASN eligibility and authentication (015401) Taye, this is the kind of message Last Call is for: specific, technical, and naming the exact requirements it wants. Three responses. First, on substance: the properties you list - the leading ASN globally assigned, an authoritative aut-num present, creation authenticated against that object's maintainer, private-use and reserved ranges (RFC 6996) excluded, canonical ASPLAIN form (RFC 5396) - are, I would argue, what the Impact Assessment's own authorisation claim already entails. An anchor with no holder can authorise no one; a check that can pass in the absence of the aut-num it authenticates against would not be the check the assessment describes. So I read your list not as a new mechanism but as the strict, and correct, reading of the mechanism the proposal already claims. Second, on where it belongs: those are implementation semantics - the authentication mode of the database software and the eligible ASN ranges - and I would support AFRINIC staff recording exactly your list in the implementation guidance for this policy, alongside the failure behaviour per creation path. That is the normal home of such requirements at every registry, and section 7.8.7's documented-exception mechanism gives staff the instrument for any edge the guidance must handle. It is worth adding: even in the weakest imaginable configuration, an unattributable hierarchical-form name is no worse than today, where every name of any form requires no authorisation from anyone. Third, on form: yours is the closest any message in this Last Call has come to proposed text. If you formalise that list as wording - whether as implementation guidance or as a clarification for a future revision - I have no doubt this Working Group will engage it on its merits, exactly as was invited days ago (015390). It is the constructive instrument the process recognises. 1. Implementation rollout process (015402) Warning-only phases, test vectors, baselines, rollback plans and scheduled reviews are implementation artifacts. They are produced by registry staff during implementation - at every RIR - and they appear in no naming policy anywhere: RIPE shipped its hierarchical requirement through the database release process, with release notes and a release-candidate test environment, on the strength of a policy text that contains none of those artifacts. Nothing in this proposal forbids a staged, warning-first deployment; that is exactly the kind of detail the implementation phase exists to define, and 7.8.7's documented-exception mechanism gives staff the instrument for edge handling during it. Taken at face value, (015402)'s final section is an argument about deployment scheduling, which follows ratification - not a reason to withhold it. Stepping back, twice. Each of the demands in messages (015387), (015389), (015391), (015392), (015393), (015398), (015400) and (015402) carries the same condition: "before adoption" (015387, 015389, 015391), "before mandatory enforcement" (015393), "before this proceeds" (015398), "until ... addressed" (015392), "until that is clarified" (015400), "until ... clearly resolved" (015402). As Seun reminded the list (015386), this PDP has no conditional adoption: a proposal cannot pass Last Call subject to future homework. At day eleven of Last Call, "resolve and test before advancing" therefore spells "do not adopt". The process has exactly one instrument for a genuine, fixable concern: proposed text. Jaco invited it (015390). Let me emphasise the arithmetic: seven distinct technical concerns in a single day, after eleven days without one - and, section 5's requirements list aside, still zero proposed amendments. Of the six questions of 23 July (015344), exactly one account engaged them point by point - Tshepo, in (015348) - and the record should credit those answers. In short: 1. Two-object case: tooling should bind to an explicitly selected source or stop and report - the fail-closed behaviour supporters had proposed; the live case itself stays unresolved either way, the rule being prospective. 2. Squatting remedy: none - the victim is left to another database's dispute or abuse process. 3. Is it an improvement? "Yes, narrowly." 4. Evidence bar: a four-part test - whose second criterion, that the proposal "would have prevented" the incident, excludes by construction every incident that already exists; a creation-time rule is prospective by definition. 5. Impact Assessment: "I do not dispute the findings"; the objection shifts to what the IA does not cover. 6. Capacity: individual, representing no organisation or resource member. No other opposing account has answered any of the six. Today the bar has moved with nearly every message, and a seventh question now joins the list. My assessment, for the record: none of today's objections identifies a defect in what the proposal claims; and their cumulative effect, whatever the intent, has been to consume the finite attention of this Working Group - a cost long-standing participants have already described in their own words (015154, 015179). One further observation, offered for the record and without attributing it to any individual: this Last Call's objections began from the principle that the registry "may record... It may not rule" (015011). Today's objections ask the registry to pre-define delegation graphs, revocation processes, state machines, permanent reservations, transition audits and source-selection rules, in advance (015391, 015392, 015393, 015398, 015400, 015402). Those two standards pull in opposite directions, and the same seven-clause creation-time rule cannot be faulted under both at once. Which standard the Working Group actually holds is exactly what the Co-Chairs will weigh - against what the proposal actually claims: a creation-time naming rule, whose every stated boundary today's objection messages ask it to exceed. The community is entitled to expect Last Call to close on schedule and to be assessed on the record as it stands. Regards, Hendrik Visage (AS329532; also AS213481) [CompanySignature] Inter..link GmbH | Boxhagener Stra?e 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello at inter.link | Web: inter.link -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Wed Jul 29 14:48:37 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Wed, 29 Jul 2026 16:48:37 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <3D148AE6-C8EF-4C22-A732-779C362791CB@hevis.co.za> Message-ID: Hi Tshepo, On 2026/07/29 15:48, Tshepo Masuku wrote: > Dear James, > > Thank you for considering the concern carefully and explaining your > decision openly. I genuinely appreciate that you engaged with the > substance rather than simply dismissing it. > > I understand the case for incremental improvement and agree that no > policy can anticipate every future scenario. My concern, however, is > not that the draft must be perfect. It is that the exception clause > sits at the boundary of what AFRINIC will be required, or permitted, > to enforce. > > The absence of data cuts both ways. If we do not know how frequently > restoration will be needed, that uncertainty does not necessarily > justify leaving the criteria undefined. It may instead support > beginning with a narrow, objective restoration rule and expanding it > later if operational evidence shows that broader exceptions are necessary. > > I also do not think restarting Last Call is, by itself, a sufficient > reason to retain ambiguous wording. Once adopted, the policy will be > binding until another proposal completes the PDP. During that period, > AFRINIC will have to interpret ?where necessary? without agreed > criteria. That is not quite the same as a temporary implementation > experiment. I don't think it's ambiguous, it may be vague, but not ambiguous.? I will concede it leaves the jay or nay decision to operational discretion, and one person may decide yes, another may decide no, but IMHO *any* reason to restore an object would be operational of nature, something like "Hi, we've deleted object X, but it has come to light it's still being referenced by {insert another object|operational peer name|AS} and we're having trouble getting the relevant party to update, could you please restore". I don't foresee any other case of restoration case that I would consider to be valid.? But precisely that "cannot foresee" is why I believe it's best to leave it to Afrinic staff to determine the validity of any motivation for *restoration* of an object.? At that point it becomes a debate.? And I've not yet encountered Afrinic staff to be unreasonable and they'll most likely err on the side of restoring (exactly as it was, without modification) rather than not. > > A narrowly drafted restoration safeguard would not be an attempt to > build the whole castle at once. It would simply make the first brick > clear enough that operators and staff know what it permits. The common > layer should be minimal, but what it contains should also be > deterministic and auditable. Without knowing what will or may be required in the future this is exceptionally difficult, as per James, to narrow down.? I agree with James that it's best to intentionally leave it vague. Bottom line is:? no new "flat" objects, and restore only on motivation to Afrinic staff (which will likely be in the lines above). At some point we would likely want to get a list of all "flat" objects and see if they're still *referenced*, confirming actual *use* is harder since we have no way of knowing whether any implementation references that object.? At least, none I'm aware of.? If there is a way it would likely involve Afrinic having to check some query log and if the object name hasn't been queried in some time.? But that's not to say there aren't gateway systems (such as rr.ntt.net - default queried server by at least bgpq4) running some form of irrd, that doesn't pull the entire database and then references "offline", so without looking into exactly how that infrastructure works, there's no way to identify completely unused objects I don't think. I trust this answers your concern. Kind regards, Jaco > > I respect your decision not to revise the draft, and I appreciate your > constructive approach. However, because the difference between a > guaranteed restoration right and discretionary case-by-case approval > remains unresolved, I cannot support the proposal as currently written > and therefore maintain my objection. > > kind regards, > Tshepo > > > ------------------------------------------------------------------------ > *From:* James Bensley > *Sent:* Wednesday, 29 July 2026 14:26:30 > *To:* Tshepo Masuku ; rpd at afrinic.net > ; pdwg-chairs at afrinic.net > *Subject:* Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Dear Tshepo, > > After careful consideration I have decided not to revise the draft. > There are a couple of reasons for this: > > * > I think this is becoming too prescriptive. If we try to define a > time period for restoration for example, for some people it will > be too long, for others too short. We have no data to make an > informed decision here. Similarly the point about having a public > log. That requires us to define what that looks like and how it > works. We have no idea how often this process would be enacted so > we can't described what that needs to look like. We have no data. > I think trying to make a perfect policy that covers all cases is > the wrong approach. I think we should be aiming to get "something" > implemented, let it run for a while, gather feedback, and then if > it needs adjusting, we can raise another policy change proposal. > Nothing is set in stone here. There's no need to get his perfect > first time, we can iterate over time. > > * > Any changes to the draft will restart the Last Call and > potentially also require the staff to re-review the draft. The > changes you proposed, whilst valid, are optimising for a corner > case (how often to people delete their AS-SET by mistake? I would > say, rarely). Why delay getting "something" deployed, which we can > continue to iterate on, just to optimise for a corner case > (restores aren't blocked by this policy)? > > > For these reasons I have decided not to modify the draft. > > With kind regards, > James Bensley (he/him) > > ------------------------------------------------------------------------ > *From:* Tshepo Masuku > *Sent:* 28 July 2026 15:28 > *To:* James Bensley ; rpd at afrinic.net > ; pdwg-chairs at afrinic.net > *Subject:* Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > Dear James, > > Thank you for engaging with the concern constructively. Your proposed > wording is a meaningful improvement because it begins replacing an > open-ended exception with objective conditions. > > I think a few points still need tightening before the rule is ready: > > * Restoration should return the object to its last valid archived > state, not merely reuse the same key. Otherwise, an old flat name > could be restored with entirely different contents and become a > new object in substance. > * The text should define whether the restoration right is permanent > or subject to a recovery period. > * ?Another maintainer within the same organisation? and an > organisation ?responsible for the assets? require objective > evidence, such as registry history or documented legal succession. > Those terms should not be left entirely to staff interpretation. > * The residual case-by-case provision should expressly prohibit > creating a flat name that did not exist before implementation. > * Every exceptional decision should record the evidence relied upon > and provide a review or appeal path, not merely an audit entry. > > I would also suggest wording along these lines: > > A restored object shall initially reflect its last valid archived > state, except that maintainer and contact attributes may be > updated where necessary to establish control by the verified > original holder or lawful successor. > > Because this changes the normative enforcement boundary, I believe v3 > should be published with an updated Impact Assessment and receive > proper review. It should not be treated as a minor editorial > correction during the final days of Last Call. > > I remain opposed to DRAFT02 as written, but I appreciate your > willingness to address the defect directly. This is the kind of > concrete engagement that adds value to the process. > > Regards, > Tshepo > > > > > ------------------------------------------------------------------------ > *From:* James Bensley > *Sent:* Tuesday, 28 July 2026 13:39:50 > *To:* Tshepo Masuku ; rpd at afrinic.net > ; pdwg-chairs at afrinic.net > *Subject:* Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Dear Tshepo, > > Thank you for providing your feedback. I am in agreement with your > statement. > > I am the original author of this draft change, and I wrote in my last > update (version 2): > > "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." > > The staff assessment was to go with the following "7.8.7 Exceptions > for the creation of hierarchical names may be granted where necessary. > AFRINIC shall document the reason for any exception.". > > The staff asked me to review their assessment and I initially agreed, > because it was loser than my definition. There may be other scenarios > where restoration is required which I/we haven't thought of, so why > limit it to accidental deletion only. Opening it up to allow any case > to be reviewed has benefits. But as you say, it could also go the > other way, it could simply mean that every case is rejected. > > I am going to submit another version (v3) of the document, only > replacing the text I quoted above, with the text below, to fix the > problem you raised of the text having gone from being too strict > before to now being too lose (I will try to propose something in the > middle which guarantees delete/restoration is protected, anything else > needs a review). > > I am proposing the following text, what do you think? > > ------ > A non-hierarchical AS-SET existing before implementation of this > policy change, which has since been deleted, must be restorable when > the following conditions are met: > > - The same object key is requested for restoration (no AS-SET name > changes allowed) > - No object with a conflicting name has been created between the date > of deletion and the date the restore is made > - The restore request is coming from either a maintainer that was > present on the deleted object, or another maintainer within the same > organisation (in the case the maintainer was also deleted), or a > maintainer in an organisation responsible for the assets of the > original organisation (in the case of a merger or acquisition). > - The restoration is recorded in an auditable log. > > Any other request for restoring a deleted AS-SET created before the > implementation date of this policy change will need to be reviewed by > AFRINIC on a case by case basis. > ------- > > With kind regards, > James Bensley (he/him) > ------------------------------------------------------------------------ > *From:* Tshepo Masuku > *Sent:* 27 July 2026 15:29 > *To:* hvisage at hevis.co.za ; Nonjabulo Sphilile > ; Phetulo Dhlamini > ; Taye Medoye ; > Thulisile Mazomba ; rpd at afrinic.net > > *Subject:* Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > *?? Caution:* This email originated from outside of your organization. > Do not click on links or open attachments unless you recognize the > sender and know the content is safe. > Dear Hendrik and colleagues, > > Thank you for consolidating the discussion. I will not repeat the > earlier lifecycle, resolver, delegation, or membership arguments. > > There is, however, a separate defect in the actual text being considered. > > The proposal says that exceptions MUST be allowed on a case-by-case > basis and gives restoration of an accidentally deleted flat AS-SET as > the example. The staff-recommended wording instead says exceptions may > be granted ?where necessary.? These are materially different rules. > > Under the first version, an eligible operator has a right to > restoration. Under the second, restoration depends on AFRINIC?s > discretion. The wording also changes a narrow restoration example into > an undefined general exception. > > That produces a concrete operational difference. If a grandfathered > flat AS-SET is accidentally deleted after implementation, one version > requires a restoration path while the other allows AFRINIC to refuse > it. Operators and peers referencing that object cannot know which > outcome the adopted policy guarantees. > > This is not an adjacent lifecycle problem. It is the enforcement > boundary of the present proposal. > > The text should therefore be amended to provide one deterministic > rule. For example: > > > A non-hierarchical AS-SET existing before commencement may be > restored only where the same object key is requested within a defined > recovery period, the request is authenticated by the maintainer > authorised immediately before deletion, no conflicting object has > intervened, and the restoration is recorded in an auditable log. No > other exception may authorise creation of a new non-hierarchical AS-SET. > > That would preserve accidental-deletion recovery without leaving the > supposedly closed namespace subject to undefined staff judgment. > > Documenting the reason after an exception is granted is not the same > as defining the conditions under which the exception is valid. > Implementation guidance also cannot resolve a conflict between ?MUST? > and ?may? after ratification. > > Before Last Call closes, the authors and co-chairs should identify > which wording is actually under consideration and resolve the > difference in normative force. > > Until then, I remain opposed to the proposal as written. > > Regards, > Tshepo > ------------------------------------------------------------------------ > *From:* hvisage at hevis.co.za > *Sent:* Monday, 27 July 2026 15:11:31 > *To:* Tshepo Masuku ; Nonjabulo Sphilile > ; Phetulo Dhlamini > ; Taye Medoye ; > Thulisile Mazomba ; rpd at afrinic.net > > *Subject:* [Last Call] Draft Policy Proposal - Hierarchical Names for > New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > Good day Tshepo, Nonjabulo, Phetulo, Taye, Thulisile, colleagues, > > Apologies to the human readers for this voluminous post, but I?d > rather address as much in one email than to flood the mailing list > With even more messages as I?d rather do a digest type response for > all the similar objections at once. > > For nearly two weeks we have been asking for technical substance; > today, in the week Last Call closes, technical reasons have at last > been presented. Before I respond to them, let me add a seventh > question to the six of 23 July (015344): > > Question 7: could you please provide the technical issues, > difficulties, and real-world examples where implementation of this > draft policy - as three RIRs have already implemented it, and the > fourth is formally proposing - would negatively affect your current > or future operations? We would like to understand those too. > Operational evidence of that kind would genuinely add to the body > of knowledge on this proposal. > > Note: numbers like (015344) are message IDs in the RPD archive - > prepend https://lists.afrinic.net/pipermail/rpd/2026/ > and append > .html to read any of them. > > So let's get to the objections we have been waiting two weeks for: > > 1. object lifecycle under changes of ASN control (015387, > escalated in 015391 and 015400) - answered by Jaco in (015388) > and (015394) > > 1b) its delegated-maintainer extension (015398, pressed again in > 015400) - Jaco deferred to the RFC in (015399); the deferral is > completed in section 1 below > 2) recursive expansion of members: references (015389) - answered > in (015390) > 3) grandfathered flat objects (015392) - answered in (015395) > 4) multi-source name resolution (015393) - answered in (015396, > 015397) > 5) anchor-ASN eligibility and authentication (015401) - addressed > in section 5 below > 6) implementation rollout process (015402) - addressed in section 6 > below; its delegation and 7.8.7 points are answered in section 1 > (the delegation question is 015398/015400 returning), and its > benefit-scope point in the common ground just below > > I refer to and endorse Jaco's answers rather than repeat them. It > was asked earlier in this Last Call that objections be addressed as > grouped issues rather than piecemeal, and in that spirit I have > collated the responses in a single email, adding what has not yet > been shared: a precise statement of the authorisation model, the > published data, and the cross-registry record. > > First, the common ground, because it is substantial. In today's own > words: > > * hierarchical naming "can strengthen creation authorisation" (015393) > * the proposal "secures the first object name" (015389) > * the concerns are "not questions about whether AS-SET membership > is correct" (015387) > * ASN-anchored naming "can reduce future flat-name collisions" > (015402) > > None of today's messages disputes what the proposal does. Each of > today's objections asks it to also solve an adjacent problem - > > * lifecycle > * delegation semantics > * expansion semantics > * legacy objects > * mirror copies > * anchor eligibility > * and every one of those problems exists today, everywhere, with or > > without this policy. That is not the discovery of a defect. It is > the discovery that the proposal has a scope, which it states and > which was put on this record weeks ago (015119, 015120, 015123; and > the draft's own sections 7.8.3-7.8.6). > > 1. The authorisation model, changes of ASN control, and delegation > (015387, 015391, 015398, 015400, 015402) > > Jaco deferred to the RFC on the depth mechanics (015399). Rightly > so - the RFC, followed to the top of the chain, completes his > answer. (015398) states the rule correctly: a first-level object, > AS12345:AS-CUSTOMERS, is created under the authorisation of the > aut-num AS12345 as it stands at that moment - its maintainer chain, > which follows the current registered holder. A deeper object, > AS12345:AS-CUSTOMERS:AS-EU, is created under the authorisation of > the maintainer of its immediate parent. Now ask where that parent > came from: its own creation was authorised by the level above it, > and so on, terminating at the aut-num itself. Every object in the > tree exists because the level above authorised its creation. > Delegation, where it exists, exists because the chain authorised > it. And who controls each level is answerable, level by level, from > the database as it stands - which is what verifiable control looks > like in RPSL. > > The emphatic difference at the current state is that a flat name > offers just a maintainer but no chain: no root, and no way to ask > whether the name was ever anyone's to create - beyond that it must > not already exist in THIS one database. > > (015400) concludes that because deeper control can be delegated, > the "control model remains unspecified". The opposite is the case: > the control model is fully specified - in the very RFC that > (015398) cited, which is why deferring to it was the right answer. > That deeper authority is delegated, and that delegated authority > does not automatically follow the ASN, is not a gap in the model; > it is the model, working as designed for twenty-seven years, for > every hierarchical object family, at every RPSL-based registry. A > policy does not "leave AFRINIC to interpret" what the RFC and the > production database already define - any more than this proposal > needs to restate what mnt-by means. What deterministically follows > the ASN is the root of every chain: authority over creation and > recreation at the first level of the namespace. That is precisely > > * and only - what the proposal's attribution claim covers. The same > > depth question returns in (015402); the answer above stands. > > These semantics are not invented by this proposal. They are RFC > 2622 (1999), operated by RPSL-based registries - AFRINIC's included > > * for twenty-seven years. The proposal does not modify them; it > > gates which names may come into existence, nothing else. The two > outcomes (015398) poses are therefore both answered by the > semantics already in production: descendants do not move > automatically, so no delegated maintainer is overridden - exactly > as for every delegated object today. And the new holder gains > precisely what the name anchors: authority over creation and > recreation at the first level of its namespace. What the new holder > does not get - control over objects a previous holder's delegates > still maintain - is what nobody has today under flat names, for any > object, ever. A stale delegated descendant is today's universal > condition; the proposal neither creates nor worsens it, and no > registry in those twenty-seven years has defined the demanded > delegation-and-revocation regime for set objects in policy. > > How ASN control actually changes in this region is likewise not a > matter for speculation. AFRINIC publishes it: > > https://ftp.afrinic.net/pub/stats/afrinic/transfers/transfers_latest.json > > > A full read of that file today: 75 ASN-carrying transfer events (91 > ASNs) from 2018 through 2026 - about nine such events a year - and > every single one is a merger/acquisition succession, in which the > organisation and its maintainer control pass together, so parent > ASN and child objects move as one unit. That is the published > record behind Jaco's description in (015394), with the frequency > question answered exactly: none open-market, all successions that > preserve the attribution chain by construction. Anyone can verify > this from the file. So the concern of (015391) has been addressed - > with our registry's own data. > > The cross-registry record answers the rest. I checked this week, > across the policy, procedural and database-documentation layers of > the other four RIRs. RIPE has required hierarchical names for new > as-sets since December 2022 and operates full ASN transfers, > including inter-RIR; APNIC likewise since July 2023 (prop-151); > LACNIC's IRR has been structurally hierarchical since it launched > in 2020; at ARIN hierarchical naming is available today and a > mandate for new objects is formally proposed (ARIN-prop-342, > pending) - the same direction. All four are silent on child as-set > lifecycle at every layer. Across the deployed implementations that > is roughly three and a half years of exactly the coexistence > (015387) warns about - hierarchical mandates running over live ASN > transfer markets - and I could not find one documented incident of > the failure mode described. In every deployed implementation, > lifecycle lives where it belongs: in standard RPSL authorisation > and registry operations, not in naming-policy text. > > On 7.8.7 (015391, 015402): today the namespace has no rule at all - > every creation, by anyone, of any name, is the exception. A closed > default with documented-reason exceptions cannot be less > deterministic than no default whatsoever. And credit where due: > (015402) makes one point that verifies - the staff assessment's > prose cites "7.8.6" for the restoration-of-deleted-objects > exception, where 7.8.6 concerns editing and the exception clause is > in fact 7.8.7. That is a cross-reference slip in the assessment's > commentary, worth an erratum, and it changes nothing in the policy > text: the clauses say what they say, and staff's own recorded > caution about recall loopholes shows the right mechanism was > analysed. As for the demanded exception criteria: 7.8.7 requires > every exception to be documented with its reason - a discipline > stricter than today, where no creation needs any reason at all. > > 2. Recursive expansion of members: references (015389) > > Correct as far as it goes - and it concedes the top level is > secured. What members: may contain is a content question, expressly > outside this proposal's scope, and outside the naming policies of > every registry that already runs this rule: none coupled naming to > expansion semantics, because that coupling is a different and > larger policy. Jaco has already named the constructive path > (015390): a members-qualification rule would be a coherent separate > proposal, and wording was invited. Meanwhile every new hierarchical > set is one fewer ambiguous reference for the next expansion to fear > > * the gap this concern describes narrows with adoption and stays > > open without it. > > 3. Grandfathered flat objects and the transition window (015392) > > The capability described - register flat names now, populate them > later - exists today, permanently, with or without this proposal. > Anyone may do it this afternoon. The proposal is the only mechanism > before this Working Group that ever closes that window; declining > it preserves the window forever. If gaming of the implementation > gap is the genuine worry, the remedy is a short implementation > period - a staff scheduling matter - not an indefinitely open > namespace. And, respectfully: (015392) describes with precision the > squatting behaviour whose future possibility this policy exists to > end. An objection that demonstrates the attack is an argument for > closing the door. > > 4. Multi-source resolution (015393) > > Jaco's answer (015396, 015397) is complete: an ASN is delegated by > exactly one registry, so a hierarchical name carries its > authoritative source in its own first element. The question "which > source is authoritative for this set?" has a deterministic answer > precisely and only when the name is hierarchical; under a flat name > that answer does not exist anywhere. The working-group draft cited > in (015393) pursues the same determinism through source-qualified > references - the two mechanisms are complements, not conflicts, and > that draft's problem statement describes the flat-name condition > this proposal removes for new AFRINIC sets. What a third-party > mirror carries is today's condition for every object in every IRR > database and is governed by no naming policy at any registry. > > 5. Anchor-ASN eligibility and authentication (015401) > > Taye, this is the kind of message Last Call is for: specific, > technical, and naming the exact requirements it wants. Three > responses. > > First, on substance: the properties you list - the leading ASN > globally assigned, an authoritative aut-num present, creation > authenticated against that object's maintainer, private-use and > reserved ranges (RFC 6996) excluded, canonical ASPLAIN form (RFC > 5396) - are, I would argue, what the Impact Assessment's own > authorisation claim already entails. An anchor with no holder can > authorise no one; a check that can pass in the absence of the > aut-num it authenticates against would not be the check the > assessment describes. So I read your list not as a new mechanism > but as the strict, and correct, reading of the mechanism the > proposal already claims. > > Second, on where it belongs: those are implementation semantics - > the authentication mode of the database software and the eligible > ASN ranges - and I would support AFRINIC staff recording exactly > your list in the implementation guidance for this policy, alongside > the failure behaviour per creation path. That is the normal home of > such requirements at every registry, and section 7.8.7's > documented-exception mechanism gives staff the instrument for any > edge the guidance must handle. It is worth adding: even in the > weakest imaginable configuration, an unattributable > hierarchical-form name is no worse than today, where every name of > any form requires no authorisation from anyone. > > Third, on form: yours is the closest any message in this Last Call > has come to proposed text. If you formalise that list as wording - > whether as implementation guidance or as a clarification for a > future revision - I have no doubt this Working Group will engage it > on its merits, exactly as was invited days ago (015390). It is the > constructive instrument the process recognises. > > 6. Implementation rollout process (015402) > > Warning-only phases, test vectors, baselines, rollback plans and > scheduled reviews are implementation artifacts. They are produced > by registry staff during implementation - at every RIR - and they > appear in no naming policy anywhere: RIPE shipped its hierarchical > requirement through the database release process, with release > notes and a release-candidate test environment, on the strength of > a policy text that contains none of those artifacts. Nothing in > this proposal forbids a staged, warning-first deployment; that is > exactly the kind of detail the implementation phase exists to > define, and 7.8.7's documented-exception mechanism gives staff the > instrument for edge handling during it. Taken at face value, > (015402)'s final section is an argument about deployment > scheduling, which follows ratification - not a reason to withhold > it. > > Stepping back, twice. > > Each of the demands in messages (015387), (015389), (015391), > (015392), (015393), (015398), (015400) and (015402) carries the same > condition: "before adoption" (015387, 015389, 015391), "before > mandatory enforcement" (015393), "before this proceeds" (015398), > "until ... addressed" (015392), "until that is clarified" (015400), > "until ... clearly resolved" (015402). > As Seun reminded the list (015386), this PDP has no conditional > adoption: a proposal cannot pass Last Call subject to future > homework. At day eleven of Last Call, "resolve and test before > advancing" therefore spells "do not adopt". The process has exactly > one instrument for a genuine, fixable concern: proposed text. Jaco > invited it (015390). > > Let me emphasise the arithmetic: seven distinct technical concerns > in a single day, after eleven days without one - and, section 5's > requirements > list aside, still zero proposed amendments. Of the six questions of > 23 July (015344), exactly one account engaged them point by point - > Tshepo, in (015348) - and the record should credit those answers. > In short: > > 1. Two-object case: tooling should bind to an explicitly selected > source or stop and report - the fail-closed behaviour supporters > had proposed; the live case itself stays unresolved either way, > the rule being prospective. > 2. Squatting remedy: none - the victim is left to another > database's dispute or abuse process. > 3. Is it an improvement? "Yes, narrowly." > 4. Evidence bar: a four-part test - whose second criterion, that > the proposal "would have prevented" the incident, excludes by > construction every incident that already exists; a creation-time > rule is prospective by definition. > 5. Impact Assessment: "I do not dispute the findings"; the > objection shifts to what the IA does not cover. > 6. Capacity: individual, representing no organisation or resource > member. > > No other opposing account has answered any of the six. Today the > bar has moved with nearly every message, and a seventh question now > joins the list. My assessment, for the record: > none of today's objections identifies a defect in what the proposal > claims; and their cumulative effect, whatever the intent, has been > to consume the finite attention of this Working Group - a cost > long-standing participants have already described in their own > words (015154, 015179). > > One further observation, offered for the record and without > attributing it to any individual: this Last Call's objections began > from the principle that the registry "may record... It may not > rule" (015011). Today's objections ask the registry to pre-define > delegation graphs, revocation processes, state machines, permanent > reservations, transition audits and source-selection rules, in > advance (015391, 015392, 015393, 015398, 015400, 015402). Those two > standards pull in opposite directions, and the same seven-clause > creation-time rule cannot be faulted under both at once. Which > standard the Working Group actually holds is exactly what the > Co-Chairs will weigh - against what the proposal actually claims: a > creation-time naming rule, whose every stated boundary today's > objection messages ask it to exceed. > > The community is entitled to expect Last Call to close on schedule > and to be assessed on the record as it stands. > > Regards, > Hendrik Visage (AS329532; also AS213481) > > [CompanySignature] > Inter..link GmbH *|* Boxhagener Stra?e 80, 10245 Berlin, Germany *|* > Managing Directors: Marc Korthaus, Theo Voss *|* Commercial Register: > Amtsgericht Charlottenburg, HRB 138876 *|* VAT ID: DE281288887 *|* > Email: hello at inter.link *|* Web: inter.link > > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Wed Jul 29 15:11:07 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Wed, 29 Jul 2026 15:11:07 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <3D148AE6-C8EF-4C22-A732-779C362791CB@hevis.co.za> Message-ID: Dear Jaco, Thank you for explaining your view. However, your concession identifies the problem: if one staff member may approve a restoration and another may reject the same request, the rule is not deterministic. Whether we call that vague or ambiguous, an operator cannot know the outcome from the policy text. There is also a specific inter-RIR risk. A flat AS-SET may be deleted from AFRINIC and the same name may then be created in another authoritative IRR before restoration. Restoring the AFRINIC object ?exactly as it was? could recreate the very cross-registry collision this proposal is intended to prevent. Confirming that the key remains free inside AFRINIC would not be sufficient. If restoration is retained, the policy should require verified prior control, restoration from the archived object rather than creation of a different object under the old name, and a conflict check at the time of restoration. It should also define how a refusal is reviewed. I do not doubt that AFRINIC staff may act reasonably. But policy must survive staff changes and cannot depend on assumptions about how generously discretion will be exercised. Trust is not a substitute for an objective rule. My concern is therefore not that the proposal fails to solve every IRR problem. It is that its exception can potentially recreate the precise problem the mandatory rule claims to close. Regards, Tshepo Get Outlook for Android ________________________________ From: Jaco Kroon Sent: Wednesday, 29 July 2026 16:48:37 To: Tshepo Masuku ; James Bensley ; rpd at afrinic.net ; pdwg-chairs at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Hi Tshepo, On 2026/07/29 15:48, Tshepo Masuku wrote: Dear James, Thank you for considering the concern carefully and explaining your decision openly. I genuinely appreciate that you engaged with the substance rather than simply dismissing it. I understand the case for incremental improvement and agree that no policy can anticipate every future scenario. My concern, however, is not that the draft must be perfect. It is that the exception clause sits at the boundary of what AFRINIC will be required, or permitted, to enforce. The absence of data cuts both ways. If we do not know how frequently restoration will be needed, that uncertainty does not necessarily justify leaving the criteria undefined. It may instead support beginning with a narrow, objective restoration rule and expanding it later if operational evidence shows that broader exceptions are necessary. I also do not think restarting Last Call is, by itself, a sufficient reason to retain ambiguous wording. Once adopted, the policy will be binding until another proposal completes the PDP. During that period, AFRINIC will have to interpret ?where necessary? without agreed criteria. That is not quite the same as a temporary implementation experiment. I don't think it's ambiguous, it may be vague, but not ambiguous. I will concede it leaves the jay or nay decision to operational discretion, and one person may decide yes, another may decide no, but IMHO *any* reason to restore an object would be operational of nature, something like "Hi, we've deleted object X, but it has come to light it's still being referenced by {insert another object|operational peer name|AS} and we're having trouble getting the relevant party to update, could you please restore". I don't foresee any other case of restoration case that I would consider to be valid. But precisely that "cannot foresee" is why I believe it's best to leave it to Afrinic staff to determine the validity of any motivation for *restoration* of an object. At that point it becomes a debate. And I've not yet encountered Afrinic staff to be unreasonable and they'll most likely err on the side of restoring (exactly as it was, without modification) rather than not. A narrowly drafted restoration safeguard would not be an attempt to build the whole castle at once. It would simply make the first brick clear enough that operators and staff know what it permits. The common layer should be minimal, but what it contains should also be deterministic and auditable. Without knowing what will or may be required in the future this is exceptionally difficult, as per James, to narrow down. I agree with James that it's best to intentionally leave it vague. Bottom line is: no new "flat" objects, and restore only on motivation to Afrinic staff (which will likely be in the lines above). At some point we would likely want to get a list of all "flat" objects and see if they're still *referenced*, confirming actual *use* is harder since we have no way of knowing whether any implementation references that object. At least, none I'm aware of. If there is a way it would likely involve Afrinic having to check some query log and if the object name hasn't been queried in some time. But that's not to say there aren't gateway systems (such as rr.ntt.net - default queried server by at least bgpq4) running some form of irrd, that doesn't pull the entire database and then references "offline", so without looking into exactly how that infrastructure works, there's no way to identify completely unused objects I don't think. I trust this answers your concern. Kind regards, Jaco I respect your decision not to revise the draft, and I appreciate your constructive approach. However, because the difference between a guaranteed restoration right and discretionary case-by-case approval remains unresolved, I cannot support the proposal as currently written and therefore maintain my objection. kind regards, Tshepo ________________________________ From: James Bensley Sent: Wednesday, 29 July 2026 14:26:30 To: Tshepo Masuku ; rpd at afrinic.net ; pdwg-chairs at afrinic.net Subject: Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Dear Tshepo, After careful consideration I have decided not to revise the draft. There are a couple of reasons for this: * I think this is becoming too prescriptive. If we try to define a time period for restoration for example, for some people it will be too long, for others too short. We have no data to make an informed decision here. Similarly the point about having a public log. That requires us to define what that looks like and how it works. We have no idea how often this process would be enacted so we can't described what that needs to look like. We have no data. I think trying to make a perfect policy that covers all cases is the wrong approach. I think we should be aiming to get "something" implemented, let it run for a while, gather feedback, and then if it needs adjusting, we can raise another policy change proposal. Nothing is set in stone here. There's no need to get his perfect first time, we can iterate over time. * Any changes to the draft will restart the Last Call and potentially also require the staff to re-review the draft. The changes you proposed, whilst valid, are optimising for a corner case (how often to people delete their AS-SET by mistake? I would say, rarely). Why delay getting "something" deployed, which we can continue to iterate on, just to optimise for a corner case (restores aren't blocked by this policy)? For these reasons I have decided not to modify the draft. With kind regards, James Bensley (he/him) ________________________________ From: Tshepo Masuku Sent: 28 July 2026 15:28 To: James Bensley ; rpd at afrinic.net ; pdwg-chairs at afrinic.net Subject: Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Dear James, Thank you for engaging with the concern constructively. Your proposed wording is a meaningful improvement because it begins replacing an open-ended exception with objective conditions. I think a few points still need tightening before the rule is ready: * Restoration should return the object to its last valid archived state, not merely reuse the same key. Otherwise, an old flat name could be restored with entirely different contents and become a new object in substance. * The text should define whether the restoration right is permanent or subject to a recovery period. * ?Another maintainer within the same organisation? and an organisation ?responsible for the assets? require objective evidence, such as registry history or documented legal succession. Those terms should not be left entirely to staff interpretation. * The residual case-by-case provision should expressly prohibit creating a flat name that did not exist before implementation. * Every exceptional decision should record the evidence relied upon and provide a review or appeal path, not merely an audit entry. I would also suggest wording along these lines: A restored object shall initially reflect its last valid archived state, except that maintainer and contact attributes may be updated where necessary to establish control by the verified original holder or lawful successor. Because this changes the normative enforcement boundary, I believe v3 should be published with an updated Impact Assessment and receive proper review. It should not be treated as a minor editorial correction during the final days of Last Call. I remain opposed to DRAFT02 as written, but I appreciate your willingness to address the defect directly. This is the kind of concrete engagement that adds value to the process. Regards, Tshepo ________________________________ From: James Bensley Sent: Tuesday, 28 July 2026 13:39:50 To: Tshepo Masuku ; rpd at afrinic.net ; pdwg-chairs at afrinic.net Subject: Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Dear Tshepo, Thank you for providing your feedback. I am in agreement with your statement. I am the original author of this draft change, and I wrote in my last update (version 2): "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." The staff assessment was to go with the following "7.8.7 Exceptions for the creation of hierarchical names may be granted where necessary. AFRINIC shall document the reason for any exception.". The staff asked me to review their assessment and I initially agreed, because it was loser than my definition. There may be other scenarios where restoration is required which I/we haven't thought of, so why limit it to accidental deletion only. Opening it up to allow any case to be reviewed has benefits. But as you say, it could also go the other way, it could simply mean that every case is rejected. I am going to submit another version (v3) of the document, only replacing the text I quoted above, with the text below, to fix the problem you raised of the text having gone from being too strict before to now being too lose (I will try to propose something in the middle which guarantees delete/restoration is protected, anything else needs a review). I am proposing the following text, what do you think? ------ A non-hierarchical AS-SET existing before implementation of this policy change, which has since been deleted, must be restorable when the following conditions are met: - The same object key is requested for restoration (no AS-SET name changes allowed) - No object with a conflicting name has been created between the date of deletion and the date the restore is made - The restore request is coming from either a maintainer that was present on the deleted object, or another maintainer within the same organisation (in the case the maintainer was also deleted), or a maintainer in an organisation responsible for the assets of the original organisation (in the case of a merger or acquisition). - The restoration is recorded in an auditable log. Any other request for restoring a deleted AS-SET created before the implementation date of this policy change will need to be reviewed by AFRINIC on a case by case basis. ------- With kind regards, James Bensley (he/him) ________________________________ From: Tshepo Masuku Sent: 27 July 2026 15:29 To: hvisage at hevis.co.za ; Nonjabulo Sphilile ; Phetulo Dhlamini ; Taye Medoye ; Thulisile Mazomba ; rpd at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) ?? Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. Dear Hendrik and colleagues, Thank you for consolidating the discussion. I will not repeat the earlier lifecycle, resolver, delegation, or membership arguments. There is, however, a separate defect in the actual text being considered. The proposal says that exceptions MUST be allowed on a case-by-case basis and gives restoration of an accidentally deleted flat AS-SET as the example. The staff-recommended wording instead says exceptions may be granted ?where necessary.? These are materially different rules. Under the first version, an eligible operator has a right to restoration. Under the second, restoration depends on AFRINIC?s discretion. The wording also changes a narrow restoration example into an undefined general exception. That produces a concrete operational difference. If a grandfathered flat AS-SET is accidentally deleted after implementation, one version requires a restoration path while the other allows AFRINIC to refuse it. Operators and peers referencing that object cannot know which outcome the adopted policy guarantees. This is not an adjacent lifecycle problem. It is the enforcement boundary of the present proposal. The text should therefore be amended to provide one deterministic rule. For example: > A non-hierarchical AS-SET existing before commencement may be restored only where the same object key is requested within a defined recovery period, the request is authenticated by the maintainer authorised immediately before deletion, no conflicting object has intervened, and the restoration is recorded in an auditable log. No other exception may authorise creation of a new non-hierarchical AS-SET. That would preserve accidental-deletion recovery without leaving the supposedly closed namespace subject to undefined staff judgment. Documenting the reason after an exception is granted is not the same as defining the conditions under which the exception is valid. Implementation guidance also cannot resolve a conflict between ?MUST? and ?may? after ratification. Before Last Call closes, the authors and co-chairs should identify which wording is actually under consideration and resolve the difference in normative force. Until then, I remain opposed to the proposal as written. Regards, Tshepo ________________________________ From: hvisage at hevis.co.za Sent: Monday, 27 July 2026 15:11:31 To: Tshepo Masuku ; Nonjabulo Sphilile ; Phetulo Dhlamini ; Taye Medoye ; Thulisile Mazomba ; rpd at afrinic.net Subject: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Good day Tshepo, Nonjabulo, Phetulo, Taye, Thulisile, colleagues, Apologies to the human readers for this voluminous post, but I?d rather address as much in one email than to flood the mailing list With even more messages as I?d rather do a digest type response for all the similar objections at once. For nearly two weeks we have been asking for technical substance; today, in the week Last Call closes, technical reasons have at last been presented. Before I respond to them, let me add a seventh question to the six of 23 July (015344): Question 7: could you please provide the technical issues, difficulties, and real-world examples where implementation of this draft policy - as three RIRs have already implemented it, and the fourth is formally proposing - would negatively affect your current or future operations? We would like to understand those too. Operational evidence of that kind would genuinely add to the body of knowledge on this proposal. Note: numbers like (015344) are message IDs in the RPD archive - prepend https://lists.afrinic.net/pipermail/rpd/2026/ and append .html to read any of them. So let's get to the objections we have been waiting two weeks for: 1. object lifecycle under changes of ASN control (015387, escalated in 015391 and 015400) - answered by Jaco in (015388) and (015394) 1b) its delegated-maintainer extension (015398, pressed again in 015400) - Jaco deferred to the RFC in (015399); the deferral is completed in section 1 below 2) recursive expansion of members: references (015389) - answered in (015390) 3) grandfathered flat objects (015392) - answered in (015395) 4) multi-source name resolution (015393) - answered in (015396, 015397) 5) anchor-ASN eligibility and authentication (015401) - addressed in section 5 below 6) implementation rollout process (015402) - addressed in section 6 below; its delegation and 7.8.7 points are answered in section 1 (the delegation question is 015398/015400 returning), and its benefit-scope point in the common ground just below I refer to and endorse Jaco's answers rather than repeat them. It was asked earlier in this Last Call that objections be addressed as grouped issues rather than piecemeal, and in that spirit I have collated the responses in a single email, adding what has not yet been shared: a precise statement of the authorisation model, the published data, and the cross-registry record. First, the common ground, because it is substantial. In today's own words: * hierarchical naming "can strengthen creation authorisation" (015393) * the proposal "secures the first object name" (015389) * the concerns are "not questions about whether AS-SET membership is correct" (015387) * ASN-anchored naming "can reduce future flat-name collisions" (015402) None of today's messages disputes what the proposal does. Each of today's objections asks it to also solve an adjacent problem - * lifecycle * delegation semantics * expansion semantics * legacy objects * mirror copies * anchor eligibility * and every one of those problems exists today, everywhere, with or without this policy. That is not the discovery of a defect. It is the discovery that the proposal has a scope, which it states and which was put on this record weeks ago (015119, 015120, 015123; and the draft's own sections 7.8.3-7.8.6). 1. The authorisation model, changes of ASN control, and delegation (015387, 015391, 015398, 015400, 015402) Jaco deferred to the RFC on the depth mechanics (015399). Rightly so - the RFC, followed to the top of the chain, completes his answer. (015398) states the rule correctly: a first-level object, AS12345:AS-CUSTOMERS, is created under the authorisation of the aut-num AS12345 as it stands at that moment - its maintainer chain, which follows the current registered holder. A deeper object, AS12345:AS-CUSTOMERS:AS-EU, is created under the authorisation of the maintainer of its immediate parent. Now ask where that parent came from: its own creation was authorised by the level above it, and so on, terminating at the aut-num itself. Every object in the tree exists because the level above authorised its creation. Delegation, where it exists, exists because the chain authorised it. And who controls each level is answerable, level by level, from the database as it stands - which is what verifiable control looks like in RPSL. The emphatic difference at the current state is that a flat name offers just a maintainer but no chain: no root, and no way to ask whether the name was ever anyone's to create - beyond that it must not already exist in THIS one database. (015400) concludes that because deeper control can be delegated, the "control model remains unspecified". The opposite is the case: the control model is fully specified - in the very RFC that (015398) cited, which is why deferring to it was the right answer. That deeper authority is delegated, and that delegated authority does not automatically follow the ASN, is not a gap in the model; it is the model, working as designed for twenty-seven years, for every hierarchical object family, at every RPSL-based registry. A policy does not "leave AFRINIC to interpret" what the RFC and the production database already define - any more than this proposal needs to restate what mnt-by means. What deterministically follows the ASN is the root of every chain: authority over creation and recreation at the first level of the namespace. That is precisely * and only - what the proposal's attribution claim covers. The same depth question returns in (015402); the answer above stands. These semantics are not invented by this proposal. They are RFC 2622 (1999), operated by RPSL-based registries - AFRINIC's included * for twenty-seven years. The proposal does not modify them; it gates which names may come into existence, nothing else. The two outcomes (015398) poses are therefore both answered by the semantics already in production: descendants do not move automatically, so no delegated maintainer is overridden - exactly as for every delegated object today. And the new holder gains precisely what the name anchors: authority over creation and recreation at the first level of its namespace. What the new holder does not get - control over objects a previous holder's delegates still maintain - is what nobody has today under flat names, for any object, ever. A stale delegated descendant is today's universal condition; the proposal neither creates nor worsens it, and no registry in those twenty-seven years has defined the demanded delegation-and-revocation regime for set objects in policy. How ASN control actually changes in this region is likewise not a matter for speculation. AFRINIC publishes it: https://ftp.afrinic.net/pub/stats/afrinic/transfers/transfers_latest.json A full read of that file today: 75 ASN-carrying transfer events (91 ASNs) from 2018 through 2026 - about nine such events a year - and every single one is a merger/acquisition succession, in which the organisation and its maintainer control pass together, so parent ASN and child objects move as one unit. That is the published record behind Jaco's description in (015394), with the frequency question answered exactly: none open-market, all successions that preserve the attribution chain by construction. Anyone can verify this from the file. So the concern of (015391) has been addressed - with our registry's own data. The cross-registry record answers the rest. I checked this week, across the policy, procedural and database-documentation layers of the other four RIRs. RIPE has required hierarchical names for new as-sets since December 2022 and operates full ASN transfers, including inter-RIR; APNIC likewise since July 2023 (prop-151); LACNIC's IRR has been structurally hierarchical since it launched in 2020; at ARIN hierarchical naming is available today and a mandate for new objects is formally proposed (ARIN-prop-342, pending) - the same direction. All four are silent on child as-set lifecycle at every layer. Across the deployed implementations that is roughly three and a half years of exactly the coexistence (015387) warns about - hierarchical mandates running over live ASN transfer markets - and I could not find one documented incident of the failure mode described. In every deployed implementation, lifecycle lives where it belongs: in standard RPSL authorisation and registry operations, not in naming-policy text. On 7.8.7 (015391, 015402): today the namespace has no rule at all - every creation, by anyone, of any name, is the exception. A closed default with documented-reason exceptions cannot be less deterministic than no default whatsoever. And credit where due: (015402) makes one point that verifies - the staff assessment's prose cites "7.8.6" for the restoration-of-deleted-objects exception, where 7.8.6 concerns editing and the exception clause is in fact 7.8.7. That is a cross-reference slip in the assessment's commentary, worth an erratum, and it changes nothing in the policy text: the clauses say what they say, and staff's own recorded caution about recall loopholes shows the right mechanism was analysed. As for the demanded exception criteria: 7.8.7 requires every exception to be documented with its reason - a discipline stricter than today, where no creation needs any reason at all. 1. Recursive expansion of members: references (015389) Correct as far as it goes - and it concedes the top level is secured. What members: may contain is a content question, expressly outside this proposal's scope, and outside the naming policies of every registry that already runs this rule: none coupled naming to expansion semantics, because that coupling is a different and larger policy. Jaco has already named the constructive path (015390): a members-qualification rule would be a coherent separate proposal, and wording was invited. Meanwhile every new hierarchical set is one fewer ambiguous reference for the next expansion to fear * the gap this concern describes narrows with adoption and stays open without it. 1. Grandfathered flat objects and the transition window (015392) The capability described - register flat names now, populate them later - exists today, permanently, with or without this proposal. Anyone may do it this afternoon. The proposal is the only mechanism before this Working Group that ever closes that window; declining it preserves the window forever. If gaming of the implementation gap is the genuine worry, the remedy is a short implementation period - a staff scheduling matter - not an indefinitely open namespace. And, respectfully: (015392) describes with precision the squatting behaviour whose future possibility this policy exists to end. An objection that demonstrates the attack is an argument for closing the door. 1. Multi-source resolution (015393) Jaco's answer (015396, 015397) is complete: an ASN is delegated by exactly one registry, so a hierarchical name carries its authoritative source in its own first element. The question "which source is authoritative for this set?" has a deterministic answer precisely and only when the name is hierarchical; under a flat name that answer does not exist anywhere. The working-group draft cited in (015393) pursues the same determinism through source-qualified references - the two mechanisms are complements, not conflicts, and that draft's problem statement describes the flat-name condition this proposal removes for new AFRINIC sets. What a third-party mirror carries is today's condition for every object in every IRR database and is governed by no naming policy at any registry. 1. Anchor-ASN eligibility and authentication (015401) Taye, this is the kind of message Last Call is for: specific, technical, and naming the exact requirements it wants. Three responses. First, on substance: the properties you list - the leading ASN globally assigned, an authoritative aut-num present, creation authenticated against that object's maintainer, private-use and reserved ranges (RFC 6996) excluded, canonical ASPLAIN form (RFC 5396) - are, I would argue, what the Impact Assessment's own authorisation claim already entails. An anchor with no holder can authorise no one; a check that can pass in the absence of the aut-num it authenticates against would not be the check the assessment describes. So I read your list not as a new mechanism but as the strict, and correct, reading of the mechanism the proposal already claims. Second, on where it belongs: those are implementation semantics - the authentication mode of the database software and the eligible ASN ranges - and I would support AFRINIC staff recording exactly your list in the implementation guidance for this policy, alongside the failure behaviour per creation path. That is the normal home of such requirements at every registry, and section 7.8.7's documented-exception mechanism gives staff the instrument for any edge the guidance must handle. It is worth adding: even in the weakest imaginable configuration, an unattributable hierarchical-form name is no worse than today, where every name of any form requires no authorisation from anyone. Third, on form: yours is the closest any message in this Last Call has come to proposed text. If you formalise that list as wording - whether as implementation guidance or as a clarification for a future revision - I have no doubt this Working Group will engage it on its merits, exactly as was invited days ago (015390). It is the constructive instrument the process recognises. 1. Implementation rollout process (015402) Warning-only phases, test vectors, baselines, rollback plans and scheduled reviews are implementation artifacts. They are produced by registry staff during implementation - at every RIR - and they appear in no naming policy anywhere: RIPE shipped its hierarchical requirement through the database release process, with release notes and a release-candidate test environment, on the strength of a policy text that contains none of those artifacts. Nothing in this proposal forbids a staged, warning-first deployment; that is exactly the kind of detail the implementation phase exists to define, and 7.8.7's documented-exception mechanism gives staff the instrument for edge handling during it. Taken at face value, (015402)'s final section is an argument about deployment scheduling, which follows ratification - not a reason to withhold it. Stepping back, twice. Each of the demands in messages (015387), (015389), (015391), (015392), (015393), (015398), (015400) and (015402) carries the same condition: "before adoption" (015387, 015389, 015391), "before mandatory enforcement" (015393), "before this proceeds" (015398), "until ... addressed" (015392), "until that is clarified" (015400), "until ... clearly resolved" (015402). As Seun reminded the list (015386), this PDP has no conditional adoption: a proposal cannot pass Last Call subject to future homework. At day eleven of Last Call, "resolve and test before advancing" therefore spells "do not adopt". The process has exactly one instrument for a genuine, fixable concern: proposed text. Jaco invited it (015390). Let me emphasise the arithmetic: seven distinct technical concerns in a single day, after eleven days without one - and, section 5's requirements list aside, still zero proposed amendments. Of the six questions of 23 July (015344), exactly one account engaged them point by point - Tshepo, in (015348) - and the record should credit those answers. In short: 1. Two-object case: tooling should bind to an explicitly selected source or stop and report - the fail-closed behaviour supporters had proposed; the live case itself stays unresolved either way, the rule being prospective. 2. Squatting remedy: none - the victim is left to another database's dispute or abuse process. 3. Is it an improvement? "Yes, narrowly." 4. Evidence bar: a four-part test - whose second criterion, that the proposal "would have prevented" the incident, excludes by construction every incident that already exists; a creation-time rule is prospective by definition. 5. Impact Assessment: "I do not dispute the findings"; the objection shifts to what the IA does not cover. 6. Capacity: individual, representing no organisation or resource member. No other opposing account has answered any of the six. Today the bar has moved with nearly every message, and a seventh question now joins the list. My assessment, for the record: none of today's objections identifies a defect in what the proposal claims; and their cumulative effect, whatever the intent, has been to consume the finite attention of this Working Group - a cost long-standing participants have already described in their own words (015154, 015179). One further observation, offered for the record and without attributing it to any individual: this Last Call's objections began from the principle that the registry "may record... It may not rule" (015011). Today's objections ask the registry to pre-define delegation graphs, revocation processes, state machines, permanent reservations, transition audits and source-selection rules, in advance (015391, 015392, 015393, 015398, 015400, 015402). Those two standards pull in opposite directions, and the same seven-clause creation-time rule cannot be faulted under both at once. Which standard the Working Group actually holds is exactly what the Co-Chairs will weigh - against what the proposal actually claims: a creation-time naming rule, whose every stated boundary today's objection messages ask it to exceed. The community is entitled to expect Last Call to close on schedule and to be assessed on the record as it stands. Regards, Hendrik Visage (AS329532; also AS213481) [CompanySignature] Inter..link GmbH | Boxhagener Stra?e 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello at inter.link | Web: inter.link _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Wed Jul 29 16:03:45 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Wed, 29 Jul 2026 18:03:45 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: <69964EA6-636A-44A0-8CF2-8BFA8D22B529@hevis.co.za> Good day Tshepo, colleagues, Tshepo, first: thank you! Your AS-FOO restoration example (015415) is honestly the best illustration this whole Last Call has produced of the exact disease we are busy fixing here - you clearly understand the cross-registry collision problem, you've described its anatomy better than most of the supporters did. Where I want to help is to show you WHERE that collision actually lives: it lives in the flat names, and only in the flat names - and this proposal is precisely the instrument that stops making them. Let me walk through it. Executive Summary: An ASN belongs to exactly one registry, that's how IANA delegates the blocks, and a hierarchical AS-SET can only be created in that one registry, by that ASN's holder, because the creation is authorised against the LOCAL aut-num object in that database. I can prove it with my own two ASNs: my AS213481 (RIPE) cannot anchor a set in the AfriNIC database - there is simply no aut-num there to authorise it - and my AS329532 (AfriNIC) cannot anchor one at RIPE, APNIC or ARIN, same reason mirror-imaged. So the authoritative hierarchical namespaces are disjoint BY CONSTRUCTION, and the cross-registry collision in your AS-FOO restoration example (015415) is unconstructible with any name this policy produces - it only works with the flat legacy names, the exact class this policy stops minting. Your example demonstrates the disease we are treating - and I mean that as a genuine compliment, it takes understanding the problem to construct it. Now the longer version, for those that want to check my work. There is two facts this all rests on: Fact 1: every ASN have exactly one registry, always. IANA delegates the ASN blocks to one RIR each - my AS329532 sits in AfriNIC's 327680-330751 block, my AS213481 sits in RIPE's 196608-219547 block. The map ASN => registry is total and single-valued, and it even stays single-valued under inter-RIR ASN transfers where those are allowed (the authoritative home moves WITH the ASN, it never has two homes - and AfriNIC is not even part of the inter-RIR transfer system today, but that's a different discussion). Fact 2: hierarchical creation is authorised against the LOCAL aut-num object. In every authoritative RIR database, to create ASxxx:AS-SOMETHING you must pass authorisation via the aut-num for ASxxx in that SAME database (mnt-lower, else mnt-by - per the RIPE and AfriNIC documentation; APNIC prop-151 says created only by "the maintainer of the ASN" in the name; ARIN does it via the Org linkage). And an RIR's authoritative database only carries aut-num objects for the ASNs that registry itself issued. AfriNIC's DB has no aut-num AS213481. RIPE's DB has no aut-num AS329532. So the demonstration, with my own two ASNs: => I cannot create AS213481:AS-ANYTHING in the AfriNIC database. The authorisation check needs aut-num AS213481 in AfriNIC's DB, no such object exists or can exist there, since it's RIPE-issued. There is no maintainer chain to authorise against. Creation fails for me - and for everybody else on earth too. => I cannot create AS329532:AS-ANYTHING in the RIPE database, exact mirror image reason. Same at APNIC, same at ARIN. Which means: under hierarchical naming the five authoritative namespaces is disjoint by construction. A hierarchical name can exist, as an authoritative object, in exactly ONE registry - the one that issued its leading ASN - and can be created there by exactly ONE party - that ASN's current holder chain. A cross-registry collision between two authoritative hierarchical objects with the same name is not "unlikely", it is impossible. Nobody have to go check anybody else's namespace, the name itself IS the check. (This is also Jaco's point in (015396) about source selection - the tooling maps the leading ASN to its registry and queries only there.) Now apply that to your (015415) example. Look carefully what carries that scenario: EVERY step of it requires the name to be flat. 1) The colliding class is the flat class. A hierarchical name cannot be created in the "other" registry at your step 2 - see above. The scenario is unconstructible with any name this policy produces, it is only constructible with the legacy names the policy stops minting. 2) The restored object is grandfathered surface. Clauses 7.8.4/7.8.5 expressly tolerate the existing flat inventory and its exposure, restoration un-deletes a member of that tolerated class. Its cross-registry exposure existed every single day that object was live - the delete/restore round-trip neither creates nor enlarges it. 3) And your example is anyway a subset of today's standing condition: without this policy, AS-FOO collisions require no deletion-and-restoration choreography at all - anyone can create AS-FOO in any IRR, today, right now, this afternoon. The restoration edge is a strict subset of the permanent flat-name exposure, and the only mechanism on the table that ever SHRINKS that exposure is this proposal, under which the flat class ages out and your scenario's raw material disappears with it. So your example does not show the exception "recreating the very collision this proposal is intended to prevent". It shows, in full working detail, the problem that exists exactly as long as flat names can exist. You have, maybe without intending to, written the strongest argument FOR the proposal this list has seen in two weeks - it just runs in reverse. To be complete and honest about the edges: yes, the open registries and mirrors (RADB and friends) accept objects on their own terms, including names rooted in ASNs the submitter doesn't hold - that is true today, unaffected by any RIR's policy, governed by those operators, and it's a tooling source-selection matter which the ASN => registry map above makes deterministic for the authoritative data. And yes, AfriNIC-side enforcement of the local-aut-num check is exactly the implementation semantics Taye asked to have pinned in (015401), which I've already supported recording as staff implementation guidance in (015404). So Tshepo - you see the problem, that much is clear from how well you described it. The flat namespace is the only place your scenario can happen, and every day the flat class shrinks, your scenario shrinks with it. That shrinking only starts when this policy is adopted. I'd genuinely welcome you on the side of fixing the disease you've just diagnosed so well. Regards, Hendrik Visage (AS329532; also AS213481) -------------- next part -------------- An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Wed Jul 29 18:06:23 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Wed, 29 Jul 2026 18:06:23 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Message-ID: Dear Hendrik, Thank you for consolidating the discussion. I will not repeat the earlier objections. I will answer Question 7 with one specific operational concern arising from your own response. You rely on the AFRINIC transfer record to conclude that an ASN and its related AS-SET objects move together. However, a transfer log proves only that control of an ASN changed. It does not prove that every hierarchical AS-SET beneath that ASN is atomically transferred, re-authenticated, frozen, deleted, or moved to another IRR. Consider this case: AS65000:AS-CUSTOMERS exists in the AFRINIC database and is maintained by the previous holder or a delegated maintainer. AS65000 later changes holder or authoritative registry. The proposal does not define what happens to that AS-SET. If the old object remains while the new holder creates the same hierarchical name in the new authoritative source, two objects with the same supposedly unique name may coexist. Both may have been validly authorised when created, but they represent different holders and different points in time. That creates a practical risk: filter-generation tools, mirrors, caches, and source-specific configurations may resolve different objects without the relying operator changing its configuration. The ambiguity has moved from flat-name collision to authority succession, but it has not disappeared. This is not an adjacent question about membership accuracy. It concerns the proposal?s central claims of name uniqueness, source determinism, and proof of control. The transfer JSON does not demonstrate the required database behaviour. What is needed is a documented and tested state transition explaining: whether dependent AS-SETs move with the ASN; whether they remain under delegated maintainers; whether the old source publishes a tombstone or transfer status; whether the new holder may recreate the same name elsewhere; and how tools distinguish the current authoritative object from the historical one. Without that, the statement that the ASN-to-registry map always provides a deterministic authoritative source is not established by running implementation. I am not asking the proposal to build the entire IRR ?skyscraper.? I am asking whether its claimed foundation remains sound when control of the anchor ASN changes. A creation-time authorisation rule that does not define subsequent authority transitions is incomplete within its own stated purpose. This is a concrete future operational problem that could produce divergent filters and stale authority after an ASN transfer. Until the transfer behaviour is specified and tested, I remain opposed to the proposal as written. Regards, Tshepo -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Wed Jul 29 18:21:10 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Wed, 29 Jul 2026 20:21:10 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: <32BB6C1F-18CF-44AC-ACDF-979D0BE9E81D@hevis.co.za> Good day Tshepo, Three short points, and then I'll leave the record to the Co-Chairs. First: your scenario requires an inter-RIR ASN transfer. AFRINIC does not perform inter-RIR transfers - not for ASNs, not for anything. There is no policy for it in the CPM, and the other registries list AFRINIC as not approved for transfers in either direction. So the event your whole scenario depends on cannot occur in this region under any rule that exists - and a NAMING proposal can neither create that capability nor govern it. If our community one day adopts an inter-RIR transfer policy, THAT policy is where object handling on transfer gets defined - which is exactly where the deployed registries define it today (APNIC's transfer conditions, for example, spell out which dependent objects get deleted when a resource moves). You are asking the wrong document to answer, before the right document exists. Second: the "how do tools distinguish the current authoritative object from the historical one" question has a running answer already: the delegated statistics files every RIR publishes daily, which record each ASN's current registry - transfers included, single-valued at every instant. That is the map the whole IRR tooling world uses today. And notice: under flat names your succession scenario is strictly worse, because then there is no map at all. Third, on Question 7: I asked for the technical issues and real-world examples where this policy would negatively affect YOUR current or future operations. A hypothetical relying operator, in a transfer type that is not available in this region, is not that. So I note, with appreciation for the attempt, that Question 7 still stands unanswered. And to be fair on the record: of the six questions of (015344), yours in (015348) remain the only point-by-point answers given - answers I credited in (015404) - the rest of the opposition has answered none. The record is now complete enough for the Co-Chairs to do their work, and I am content to leave it to them. Regards, Hendrik Visage (AS329532; also AS213481) From TshepoMasuku26 at hotmail.com Wed Jul 29 18:28:45 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Wed, 29 Jul 2026 18:28:45 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <32BB6C1F-18CF-44AC-ACDF-979D0BE9E81D@hevis.co.za> References: <32BB6C1F-18CF-44AC-ACDF-979D0BE9E81D@hevis.co.za> Message-ID: Dear Hendrik, Thank you. I will respond directly to your three points. First, Question 7 is a test you introduced. It is not a requirement that every objector demonstrate personal damage to their own production network before a policy concern may be considered. A mandatory rule may be challenged because its state model, implementation assumptions, or enforcement boundaries are incomplete. Making personal operational harm the admission price for an objection would turn an open PDP into an operator-credential test. Experience is relevant evidence; it is not exclusive authority. Second, the delegated statistics file does not provide the guarantee you claim. It maps an ASN to its current registry. It does not identify which AS-SET object a resolver actually used, invalidate an old copy, update every mirror or cache simultaneously, or confirm the present maintainer chain of a delegated descendant. A file published daily is not a globally atomic authority mechanism. If the claim is that running tools already use that map to reject historical or conflicting AS-SET objects, please identify the relevant resolver behaviour, code path, or test case. Otherwise, this remains an architectural assumption rather than running-code evidence. The proposal can reasonably claim that a new name is unique and authenticated inside the AFRINIC database at creation time. It should not be credited with continuous, globally deterministic source resolution unless that behaviour is demonstrated across the actual tooling that consumes the data. Third, you asked for effects on current or future operations, but then excluded the future scenario because AFRINIC does not currently support inter-RIR ASN transfers. Those positions cannot both stand. A policy intended to remain in force cannot use the present absence of another policy as proof that its own assumptions will remain valid indefinitely. If a future transfer policy must define the object transition, then that confirms the present proposal does not define it. I am not asking this proposal to solve every transfer problem. I am asking that its text and Impact Assessment claim only what the mechanism actually guarantees. The unresolved issue is therefore specific: the proposal creates local, creation-time naming and authentication rules, while its supporters attribute to it a global and continuing authority property that has not been demonstrated in running tools. The record is not made complete merely by declaring it complete. Until the claims are narrowed to the property actually proved, I remain opposed. Regards, Tshepo ________________________________ From: Hendrik Visage Sent: Wednesday, 29 July 2026 20:21:10 To: Tshepo Masuku ; rpd at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Good day Tshepo, Three short points, and then I'll leave the record to the Co-Chairs. First: your scenario requires an inter-RIR ASN transfer. AFRINIC does not perform inter-RIR transfers - not for ASNs, not for anything. There is no policy for it in the CPM, and the other registries list AFRINIC as not approved for transfers in either direction. So the event your whole scenario depends on cannot occur in this region under any rule that exists - and a NAMING proposal can neither create that capability nor govern it. If our community one day adopts an inter-RIR transfer policy, THAT policy is where object handling on transfer gets defined - which is exactly where the deployed registries define it today (APNIC's transfer conditions, for example, spell out which dependent objects get deleted when a resource moves). You are asking the wrong document to answer, before the right document exists. Second: the "how do tools distinguish the current authoritative object from the historical one" question has a running answer already: the delegated statistics files every RIR publishes daily, which record each ASN's current registry - transfers included, single-valued at every instant. That is the map the whole IRR tooling world uses today. And notice: under flat names your succession scenario is strictly worse, because then there is no map at all. Third, on Question 7: I asked for the technical issues and real-world examples where this policy would negatively affect YOUR current or future operations. A hypothetical relying operator, in a transfer type that is not available in this region, is not that. So I note, with appreciation for the attempt, that Question 7 still stands unanswered. And to be fair on the record: of the six questions of (015344), yours in (015348) remain the only point-by-point answers given - answers I credited in (015404) - the rest of the opposition has answered none. The record is now complete enough for the Co-Chairs to do their work, and I am content to leave it to them. Regards, Hendrik Visage (AS329532; also AS213481) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jaco at uls.co.za Wed Jul 29 20:45:32 2026 From: jaco at uls.co.za (Jaco Kroon) Date: Wed, 29 Jul 2026 22:45:32 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <3D148AE6-C8EF-4C22-A732-779C362791CB@hevis.co.za> Message-ID: <1be501c9-70ef-4fb7-8434-c4f1a96d4f17@uls.co.za> Hi, Sorry for top-posting, but it seems exactly me cares about most of that anyway. It's a risk.? We're aware of it.? If you want an object restored and your not happy with the outcome, escalate the matter. If you're unhappy with the wording, propose alternative wording or live with it.? It's that simple. The inter-RIR risk is currently also there, so irrelevant, plus, I think Afrinic is the only RIR that still allows new "flat" AS-SET objects to be created.? And someone pointed out to be today RADB, but I haven't confirmed that. That also reduces your risk of creating exactly the collision that we intend to prevent because those collisions would exist currently (as in before the effective date where no more flat AS-SET objects can be created)! If you can propose better wording, and with enough foresight to deal with all possible future restore situations in a sensible way I'm sure James would happily reconsider again.? But I doubt that's possible bringing us back to even with an extremely lenient, and specifically vague motivation for restore we're still significantly better of than what we are today. Kind regards, Jaco On 2026/07/29 17:11, Tshepo Masuku wrote: > > Dear Jaco, > > Thank you for explaining your view. However, your concession > identifies the problem: if one staff member may approve a restoration > and another may reject the same request, the rule is not > deterministic. Whether we call that vague or ambiguous, an operator > cannot know the outcome from the policy text. > > There is also a specific inter-RIR risk. A flat AS-SET may be deleted > from AFRINIC and the same name may then be created in another > authoritative IRR before restoration. Restoring the AFRINIC object > ?exactly as it was? could recreate the very cross-registry collision > this proposal is intended to prevent. Confirming that the key remains > free inside AFRINIC would not be sufficient. > > If restoration is retained, the policy should require verified prior > control, restoration from the archived object rather than creation of > a different object under the old name, and a conflict check at the > time of restoration. It should also define how a refusal is reviewed. > > I do not doubt that AFRINIC staff may act reasonably. But policy must > survive staff changes and cannot depend on assumptions about how > generously discretion will be exercised. Trust is not a substitute for > an objective rule. > > My concern is therefore not that the proposal fails to solve every IRR > problem. It is that its exception can potentially recreate the precise > problem the mandatory rule claims to close. > > Regards, > Tshepo > > > > Get Outlook for Android > ------------------------------------------------------------------------ > *From:* Jaco Kroon > *Sent:* Wednesday, 29 July 2026 16:48:37 > *To:* Tshepo Masuku ; James Bensley > ; rpd at afrinic.net ; > pdwg-chairs at afrinic.net > *Subject:* Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > Hi Tshepo, > > On 2026/07/29 15:48, Tshepo Masuku wrote: >> Dear James, >> >> Thank you for considering the concern carefully and explaining your >> decision openly. I genuinely appreciate that you engaged with the >> substance rather than simply dismissing it. >> >> I understand the case for incremental improvement and agree that no >> policy can anticipate every future scenario. My concern, however, is >> not that the draft must be perfect. It is that the exception clause >> sits at the boundary of what AFRINIC will be required, or permitted, >> to enforce. >> >> The absence of data cuts both ways. If we do not know how frequently >> restoration will be needed, that uncertainty does not necessarily >> justify leaving the criteria undefined. It may instead support >> beginning with a narrow, objective restoration rule and expanding it >> later if operational evidence shows that broader exceptions are >> necessary. >> >> I also do not think restarting Last Call is, by itself, a sufficient >> reason to retain ambiguous wording. Once adopted, the policy will be >> binding until another proposal completes the PDP. During that period, >> AFRINIC will have to interpret ?where necessary? without agreed >> criteria. That is not quite the same as a temporary implementation >> experiment. > I don't think it's ambiguous, it may be vague, but not ambiguous.? I > will concede it leaves the jay or nay decision to operational > discretion, and one person may decide yes, another may decide no, but > IMHO *any* reason to restore an object would be operational of nature, > something like "Hi, we've deleted object X, but it has come to light > it's still being referenced by {insert another object|operational peer > name|AS} and we're having trouble getting the relevant party to > update, could you please restore". > > I don't foresee any other case of restoration case that I would > consider to be valid.? But precisely that "cannot foresee" is why I > believe it's best to leave it to Afrinic staff to determine the > validity of any motivation for *restoration* of an object.? At that > point it becomes a debate.? And I've not yet encountered Afrinic staff > to be unreasonable and they'll most likely err on the side of > restoring (exactly as it was, without modification) rather than not. >> >> A narrowly drafted restoration safeguard would not be an attempt to >> build the whole castle at once. It would simply make the first brick >> clear enough that operators and staff know what it permits. The >> common layer should be minimal, but what it contains should also be >> deterministic and auditable. > > Without knowing what will or may be required in the future this is > exceptionally difficult, as per James, to narrow down.? I agree with > James that it's best to intentionally leave it vague. > > > Bottom line is:? no new "flat" objects, and restore only on motivation > to Afrinic staff (which will likely be in the lines above). > > At some point we would likely want to get a list of all "flat" objects > and see if they're still *referenced*, confirming actual *use* is > harder since we have no way of knowing whether any implementation > references that object.? At least, none I'm aware of.? If there is a > way it would likely involve Afrinic having to check some query log and > if the object name hasn't been queried in some time.? But that's not > to say there aren't gateway systems (such as rr.ntt.net - default > queried server by at least bgpq4) running some form of irrd, that > doesn't pull the entire database and then references "offline", so > without looking into exactly how that infrastructure works, there's no > way to identify completely unused objects I don't think. > > > I trust this answers your concern. > > > Kind regards, > Jaco > > >> >> I respect your decision not to revise the draft, and I appreciate >> your constructive approach. However, because the difference between a >> guaranteed restoration right and discretionary case-by-case approval >> remains unresolved, I cannot support the proposal as currently >> written and therefore maintain my objection. >> >> kind regards, >> Tshepo >> >> >> ------------------------------------------------------------------------ >> *From:* James Bensley >> *Sent:* Wednesday, 29 July 2026 14:26:30 >> *To:* Tshepo Masuku >> ; rpd at afrinic.net >> ; >> pdwg-chairs at afrinic.net >> >> *Subject:* Re: [Last Call] Draft Policy Proposal - Hierarchical Names >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> Dear Tshepo, >> >> After careful consideration I have decided not to revise the draft. >> There are a couple of reasons for this: >> >> * >> I think this is becoming too prescriptive. If we try to define a >> time period for restoration for example, for some people it will >> be too long, for others too short. We have no data to make an >> informed decision here. Similarly the point about having a public >> log. That requires us to define what that looks like and how it >> works. We have no idea how often this process would be enacted so >> we can't described what that needs to look like. We have no data. >> I think trying to make a perfect policy that covers all cases is >> the wrong approach. I think we should be aiming to get >> "something" implemented, let it run for a while, gather feedback, >> and then if it needs adjusting, we can raise another policy >> change proposal. Nothing is set in stone here. There's no need to >> get his perfect first time, we can iterate over time. >> >> * >> Any changes to the draft will restart the Last Call and >> potentially also require the staff to re-review the draft. The >> changes you proposed, whilst valid, are optimising for a corner >> case (how often to people delete their AS-SET by mistake? I would >> say, rarely). Why delay getting "something" deployed, which we >> can continue to iterate on, just to optimise for a corner case >> (restores aren't blocked by this policy)? >> >> >> For these reasons I have decided not to modify the draft. >> >> With kind regards, >> James Bensley (he/him) >> >> ------------------------------------------------------------------------ >> *From:* Tshepo Masuku >> >> *Sent:* 28 July 2026 15:28 >> *To:* James Bensley ; >> rpd at afrinic.net >> ; pdwg-chairs at afrinic.net >> >> >> *Subject:* Re: [Last Call] Draft Policy Proposal - Hierarchical Names >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> >> Dear James, >> >> Thank you for engaging with the concern constructively. Your proposed >> wording is a meaningful improvement because it begins replacing an >> open-ended exception with objective conditions. >> >> I think a few points still need tightening before the rule is ready: >> >> * Restoration should return the object to its last valid archived >> state, not merely reuse the same key. Otherwise, an old flat name >> could be restored with entirely different contents and become a >> new object in substance. >> * The text should define whether the restoration right is permanent >> or subject to a recovery period. >> * ?Another maintainer within the same organisation? and an >> organisation ?responsible for the assets? require objective >> evidence, such as registry history or documented legal >> succession. Those terms should not be left entirely to staff >> interpretation. >> * The residual case-by-case provision should expressly prohibit >> creating a flat name that did not exist before implementation. >> * Every exceptional decision should record the evidence relied upon >> and provide a review or appeal path, not merely an audit entry. >> >> I would also suggest wording along these lines: >> >> A restored object shall initially reflect its last valid archived >> state, except that maintainer and contact attributes may be >> updated where necessary to establish control by the verified >> original holder or lawful successor. >> >> Because this changes the normative enforcement boundary, I believe v3 >> should be published with an updated Impact Assessment and receive >> proper review. It should not be treated as a minor editorial >> correction during the final days of Last Call. >> >> I remain opposed to DRAFT02 as written, but I appreciate your >> willingness to address the defect directly. This is the kind of >> concrete engagement that adds value to the process. >> >> Regards, >> Tshepo >> >> >> >> >> ------------------------------------------------------------------------ >> *From:* James Bensley >> *Sent:* Tuesday, 28 July 2026 13:39:50 >> *To:* Tshepo Masuku >> ; rpd at afrinic.net >> ; >> pdwg-chairs at afrinic.net >> >> *Subject:* Re: [Last Call] Draft Policy Proposal - Hierarchical Names >> for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> Dear Tshepo, >> >> Thank you for providing your feedback. I am in agreement with your >> statement. >> >> I am the original author of this draft change, and I wrote in my last >> update (version 2): >> >> "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." >> >> The staff assessment was to go with the following "7.8.7 Exceptions >> for the creation of hierarchical names may be granted where >> necessary. AFRINIC shall document the reason for any exception.". >> >> The staff asked me to review their assessment and I initially agreed, >> because it was loser than my definition. There may be other scenarios >> where restoration is required which I/we haven't thought of, so why >> limit it to accidental deletion only. Opening it up to allow any case >> to be reviewed has benefits. But as you say, it could also go the >> other way, it could simply mean that every case is rejected. >> >> I am going to submit another version (v3) of the document, only >> replacing the text I quoted above, with the text below, to fix the >> problem you raised of the text having gone from being too strict >> before to now being too lose (I will try to propose something in the >> middle which guarantees delete/restoration is protected, anything >> else needs a review). >> >> I am proposing the following text, what do you think? >> >> ------ >> A non-hierarchical AS-SET existing before implementation of this >> policy change, which has since been deleted, must be restorable when >> the following conditions are met: >> >> - The same object key is requested for restoration (no AS-SET name >> changes allowed) >> - No object with a conflicting name has been created between the date >> of deletion and the date the restore is made >> - The restore request is coming from either a maintainer that was >> present on the deleted object, or another maintainer within the same >> organisation (in the case the maintainer was also deleted), or a >> maintainer in an organisation responsible for the assets of the >> original organisation (in the case of a merger or acquisition). >> - The restoration is recorded in an auditable log. >> >> Any other request for restoring a deleted AS-SET created before the >> implementation date of this policy change will need to be reviewed by >> AFRINIC on a case by case basis. >> ------- >> >> With kind regards, >> James Bensley (he/him) >> ------------------------------------------------------------------------ >> *From:* Tshepo Masuku >> >> *Sent:* 27 July 2026 15:29 >> *To:* hvisage at hevis.co.za >> ; Nonjabulo >> Sphilile >> ; Phetulo Dhlamini >> ; Taye >> Medoye ; >> Thulisile Mazomba >> ; rpd at afrinic.net >> >> *Subject:* Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical >> Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> *?? Caution:* This email originated from outside of your >> organization. Do not click on links or open attachments unless you >> recognize the sender and know the content is safe. >> Dear Hendrik and colleagues, >> >> Thank you for consolidating the discussion. I will not repeat the >> earlier lifecycle, resolver, delegation, or membership arguments. >> >> There is, however, a separate defect in the actual text being considered. >> >> The proposal says that exceptions MUST be allowed on a case-by-case >> basis and gives restoration of an accidentally deleted flat AS-SET as >> the example. The staff-recommended wording instead says exceptions >> may be granted ?where necessary.? These are materially different rules. >> >> Under the first version, an eligible operator has a right to >> restoration. Under the second, restoration depends on AFRINIC?s >> discretion. The wording also changes a narrow restoration example >> into an undefined general exception. >> >> That produces a concrete operational difference. If a grandfathered >> flat AS-SET is accidentally deleted after implementation, one version >> requires a restoration path while the other allows AFRINIC to refuse >> it. Operators and peers referencing that object cannot know which >> outcome the adopted policy guarantees. >> >> This is not an adjacent lifecycle problem. It is the enforcement >> boundary of the present proposal. >> >> The text should therefore be amended to provide one deterministic >> rule. For example: >> >> > A non-hierarchical AS-SET existing before commencement may be >> restored only where the same object key is requested within a defined >> recovery period, the request is authenticated by the maintainer >> authorised immediately before deletion, no conflicting object has >> intervened, and the restoration is recorded in an auditable log. No >> other exception may authorise creation of a new non-hierarchical AS-SET. >> >> That would preserve accidental-deletion recovery without leaving the >> supposedly closed namespace subject to undefined staff judgment. >> >> Documenting the reason after an exception is granted is not the same >> as defining the conditions under which the exception is valid. >> Implementation guidance also cannot resolve a conflict between ?MUST? >> and ?may? after ratification. >> >> Before Last Call closes, the authors and co-chairs should identify >> which wording is actually under consideration and resolve the >> difference in normative force. >> >> Until then, I remain opposed to the proposal as written. >> >> Regards, >> Tshepo >> ------------------------------------------------------------------------ >> *From:* hvisage at hevis.co.za >> >> *Sent:* Monday, 27 July 2026 15:11:31 >> *To:* Tshepo Masuku >> ; Nonjabulo Sphilile >> ; >> Phetulo Dhlamini >> ; Taye Medoye >> ; Thulisile >> Mazomba >> ; rpd at afrinic.net >> >> *Subject:* [Last Call] Draft Policy Proposal - Hierarchical Names for >> New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) >> >> Good day Tshepo, Nonjabulo, Phetulo, Taye, Thulisile, colleagues, >> >> Apologies to the human readers for this voluminous post, but I?d >> rather address as much in one email than to flood the mailing list >> With even more messages as I?d rather do a digest type response for >> all the similar objections at once. >> >> For nearly two weeks we have been asking for technical substance; >> today, in the week Last Call closes, technical reasons have at last >> been presented. Before I respond to them, let me add a seventh >> question to the six of 23 July (015344): >> >> Question 7: could you please provide the technical issues, >> difficulties, and real-world examples where implementation of this >> draft policy - as three RIRs have already implemented it, and the >> fourth is formally proposing - would negatively affect your current >> or future operations? We would like to understand those too. >> Operational evidence of that kind would genuinely add to the body >> of knowledge on this proposal. >> >> Note: numbers like (015344) are message IDs in the RPD archive - >> prepend https://lists.afrinic.net/pipermail/rpd/2026/ >> and append >> .html to read any of them. >> >> So let's get to the objections we have been waiting two weeks for: >> >> 1. object lifecycle under changes of ASN control (015387, >> escalated in 015391 and 015400) - answered by Jaco in (015388) >> and (015394) >> >> 1b) its delegated-maintainer extension (015398, pressed again in >> 015400) - Jaco deferred to the RFC in (015399); the deferral is >> completed in section 1 below >> 2) recursive expansion of members: references (015389) - answered >> in (015390) >> 3) grandfathered flat objects (015392) - answered in (015395) >> 4) multi-source name resolution (015393) - answered in (015396, >> 015397) >> 5) anchor-ASN eligibility and authentication (015401) - addressed >> in section 5 below >> 6) implementation rollout process (015402) - addressed in section 6 >> below; its delegation and 7.8.7 points are answered in section 1 >> (the delegation question is 015398/015400 returning), and its >> benefit-scope point in the common ground just below >> >> I refer to and endorse Jaco's answers rather than repeat them. It >> was asked earlier in this Last Call that objections be addressed as >> grouped issues rather than piecemeal, and in that spirit I have >> collated the responses in a single email, adding what has not yet >> been shared: a precise statement of the authorisation model, the >> published data, and the cross-registry record. >> >> First, the common ground, because it is substantial. In today's own >> words: >> >> * hierarchical naming "can strengthen creation authorisation" (015393) >> * the proposal "secures the first object name" (015389) >> * the concerns are "not questions about whether AS-SET membership >> is correct" (015387) >> * ASN-anchored naming "can reduce future flat-name collisions" >> (015402) >> >> None of today's messages disputes what the proposal does. Each of >> today's objections asks it to also solve an adjacent problem - >> >> * lifecycle >> * delegation semantics >> * expansion semantics >> * legacy objects >> * mirror copies >> * anchor eligibility >> * and every one of those problems exists today, everywhere, with or >> >> without this policy. That is not the discovery of a defect. It is >> the discovery that the proposal has a scope, which it states and >> which was put on this record weeks ago (015119, 015120, 015123; and >> the draft's own sections 7.8.3-7.8.6). >> >> 1. The authorisation model, changes of ASN control, and delegation >> (015387, 015391, 015398, 015400, 015402) >> >> Jaco deferred to the RFC on the depth mechanics (015399). Rightly >> so - the RFC, followed to the top of the chain, completes his >> answer. (015398) states the rule correctly: a first-level object, >> AS12345:AS-CUSTOMERS, is created under the authorisation of the >> aut-num AS12345 as it stands at that moment - its maintainer chain, >> which follows the current registered holder. A deeper object, >> AS12345:AS-CUSTOMERS:AS-EU, is created under the authorisation of >> the maintainer of its immediate parent. Now ask where that parent >> came from: its own creation was authorised by the level above it, >> and so on, terminating at the aut-num itself. Every object in the >> tree exists because the level above authorised its creation. >> Delegation, where it exists, exists because the chain authorised >> it. And who controls each level is answerable, level by level, from >> the database as it stands - which is what verifiable control looks >> like in RPSL. >> >> The emphatic difference at the current state is that a flat name >> offers just a maintainer but no chain: no root, and no way to ask >> whether the name was ever anyone's to create - beyond that it must >> not already exist in THIS one database. >> >> (015400) concludes that because deeper control can be delegated, >> the "control model remains unspecified". The opposite is the case: >> the control model is fully specified - in the very RFC that >> (015398) cited, which is why deferring to it was the right answer. >> That deeper authority is delegated, and that delegated authority >> does not automatically follow the ASN, is not a gap in the model; >> it is the model, working as designed for twenty-seven years, for >> every hierarchical object family, at every RPSL-based registry. A >> policy does not "leave AFRINIC to interpret" what the RFC and the >> production database already define - any more than this proposal >> needs to restate what mnt-by means. What deterministically follows >> the ASN is the root of every chain: authority over creation and >> recreation at the first level of the namespace. That is precisely >> >> * and only - what the proposal's attribution claim covers. The same >> >> depth question returns in (015402); the answer above stands. >> >> These semantics are not invented by this proposal. They are RFC >> 2622 (1999), operated by RPSL-based registries - AFRINIC's included >> >> * for twenty-seven years. The proposal does not modify them; it >> >> gates which names may come into existence, nothing else. The two >> outcomes (015398) poses are therefore both answered by the >> semantics already in production: descendants do not move >> automatically, so no delegated maintainer is overridden - exactly >> as for every delegated object today. And the new holder gains >> precisely what the name anchors: authority over creation and >> recreation at the first level of its namespace. What the new holder >> does not get - control over objects a previous holder's delegates >> still maintain - is what nobody has today under flat names, for any >> object, ever. A stale delegated descendant is today's universal >> condition; the proposal neither creates nor worsens it, and no >> registry in those twenty-seven years has defined the demanded >> delegation-and-revocation regime for set objects in policy. >> >> How ASN control actually changes in this region is likewise not a >> matter for speculation. AFRINIC publishes it: >> >> https://ftp.afrinic.net/pub/stats/afrinic/transfers/transfers_latest.json >> >> >> A full read of that file today: 75 ASN-carrying transfer events (91 >> ASNs) from 2018 through 2026 - about nine such events a year - and >> every single one is a merger/acquisition succession, in which the >> organisation and its maintainer control pass together, so parent >> ASN and child objects move as one unit. That is the published >> record behind Jaco's description in (015394), with the frequency >> question answered exactly: none open-market, all successions that >> preserve the attribution chain by construction. Anyone can verify >> this from the file. So the concern of (015391) has been addressed - >> with our registry's own data. >> >> The cross-registry record answers the rest. I checked this week, >> across the policy, procedural and database-documentation layers of >> the other four RIRs. RIPE has required hierarchical names for new >> as-sets since December 2022 and operates full ASN transfers, >> including inter-RIR; APNIC likewise since July 2023 (prop-151); >> LACNIC's IRR has been structurally hierarchical since it launched >> in 2020; at ARIN hierarchical naming is available today and a >> mandate for new objects is formally proposed (ARIN-prop-342, >> pending) - the same direction. All four are silent on child as-set >> lifecycle at every layer. Across the deployed implementations that >> is roughly three and a half years of exactly the coexistence >> (015387) warns about - hierarchical mandates running over live ASN >> transfer markets - and I could not find one documented incident of >> the failure mode described. In every deployed implementation, >> lifecycle lives where it belongs: in standard RPSL authorisation >> and registry operations, not in naming-policy text. >> >> On 7.8.7 (015391, 015402): today the namespace has no rule at all - >> every creation, by anyone, of any name, is the exception. A closed >> default with documented-reason exceptions cannot be less >> deterministic than no default whatsoever. And credit where due: >> (015402) makes one point that verifies - the staff assessment's >> prose cites "7.8.6" for the restoration-of-deleted-objects >> exception, where 7.8.6 concerns editing and the exception clause is >> in fact 7.8.7. That is a cross-reference slip in the assessment's >> commentary, worth an erratum, and it changes nothing in the policy >> text: the clauses say what they say, and staff's own recorded >> caution about recall loopholes shows the right mechanism was >> analysed. As for the demanded exception criteria: 7.8.7 requires >> every exception to be documented with its reason - a discipline >> stricter than today, where no creation needs any reason at all. >> >> 2. Recursive expansion of members: references (015389) >> >> Correct as far as it goes - and it concedes the top level is >> secured. What members: may contain is a content question, expressly >> outside this proposal's scope, and outside the naming policies of >> every registry that already runs this rule: none coupled naming to >> expansion semantics, because that coupling is a different and >> larger policy. Jaco has already named the constructive path >> (015390): a members-qualification rule would be a coherent separate >> proposal, and wording was invited. Meanwhile every new hierarchical >> set is one fewer ambiguous reference for the next expansion to fear >> >> * the gap this concern describes narrows with adoption and stays >> >> open without it. >> >> 3. Grandfathered flat objects and the transition window (015392) >> >> The capability described - register flat names now, populate them >> later - exists today, permanently, with or without this proposal. >> Anyone may do it this afternoon. The proposal is the only mechanism >> before this Working Group that ever closes that window; declining >> it preserves the window forever. If gaming of the implementation >> gap is the genuine worry, the remedy is a short implementation >> period - a staff scheduling matter - not an indefinitely open >> namespace. And, respectfully: (015392) describes with precision the >> squatting behaviour whose future possibility this policy exists to >> end. An objection that demonstrates the attack is an argument for >> closing the door. >> >> 4. Multi-source resolution (015393) >> >> Jaco's answer (015396, 015397) is complete: an ASN is delegated by >> exactly one registry, so a hierarchical name carries its >> authoritative source in its own first element. The question "which >> source is authoritative for this set?" has a deterministic answer >> precisely and only when the name is hierarchical; under a flat name >> that answer does not exist anywhere. The working-group draft cited >> in (015393) pursues the same determinism through source-qualified >> references - the two mechanisms are complements, not conflicts, and >> that draft's problem statement describes the flat-name condition >> this proposal removes for new AFRINIC sets. What a third-party >> mirror carries is today's condition for every object in every IRR >> database and is governed by no naming policy at any registry. >> >> 5. Anchor-ASN eligibility and authentication (015401) >> >> Taye, this is the kind of message Last Call is for: specific, >> technical, and naming the exact requirements it wants. Three >> responses. >> >> First, on substance: the properties you list - the leading ASN >> globally assigned, an authoritative aut-num present, creation >> authenticated against that object's maintainer, private-use and >> reserved ranges (RFC 6996) excluded, canonical ASPLAIN form (RFC >> 5396) - are, I would argue, what the Impact Assessment's own >> authorisation claim already entails. An anchor with no holder can >> authorise no one; a check that can pass in the absence of the >> aut-num it authenticates against would not be the check the >> assessment describes. So I read your list not as a new mechanism >> but as the strict, and correct, reading of the mechanism the >> proposal already claims. >> >> Second, on where it belongs: those are implementation semantics - >> the authentication mode of the database software and the eligible >> ASN ranges - and I would support AFRINIC staff recording exactly >> your list in the implementation guidance for this policy, alongside >> the failure behaviour per creation path. That is the normal home of >> such requirements at every registry, and section 7.8.7's >> documented-exception mechanism gives staff the instrument for any >> edge the guidance must handle. It is worth adding: even in the >> weakest imaginable configuration, an unattributable >> hierarchical-form name is no worse than today, where every name of >> any form requires no authorisation from anyone. >> >> Third, on form: yours is the closest any message in this Last Call >> has come to proposed text. If you formalise that list as wording - >> whether as implementation guidance or as a clarification for a >> future revision - I have no doubt this Working Group will engage it >> on its merits, exactly as was invited days ago (015390). It is the >> constructive instrument the process recognises. >> >> 6. Implementation rollout process (015402) >> >> Warning-only phases, test vectors, baselines, rollback plans and >> scheduled reviews are implementation artifacts. They are produced >> by registry staff during implementation - at every RIR - and they >> appear in no naming policy anywhere: RIPE shipped its hierarchical >> requirement through the database release process, with release >> notes and a release-candidate test environment, on the strength of >> a policy text that contains none of those artifacts. Nothing in >> this proposal forbids a staged, warning-first deployment; that is >> exactly the kind of detail the implementation phase exists to >> define, and 7.8.7's documented-exception mechanism gives staff the >> instrument for edge handling during it. Taken at face value, >> (015402)'s final section is an argument about deployment >> scheduling, which follows ratification - not a reason to withhold >> it. >> >> Stepping back, twice. >> >> Each of the demands in messages (015387), (015389), (015391), >> (015392), (015393), (015398), (015400) and (015402) carries the same >> condition: "before adoption" (015387, 015389, 015391), "before >> mandatory enforcement" (015393), "before this proceeds" (015398), >> "until ... addressed" (015392), "until that is clarified" (015400), >> "until ... clearly resolved" (015402). >> As Seun reminded the list (015386), this PDP has no conditional >> adoption: a proposal cannot pass Last Call subject to future >> homework. At day eleven of Last Call, "resolve and test before >> advancing" therefore spells "do not adopt". The process has exactly >> one instrument for a genuine, fixable concern: proposed text. Jaco >> invited it (015390). >> >> Let me emphasise the arithmetic: seven distinct technical concerns >> in a single day, after eleven days without one - and, section 5's >> requirements >> list aside, still zero proposed amendments. Of the six questions of >> 23 July (015344), exactly one account engaged them point by point - >> Tshepo, in (015348) - and the record should credit those answers. >> In short: >> >> 1. Two-object case: tooling should bind to an explicitly selected >> source or stop and report - the fail-closed behaviour supporters >> had proposed; the live case itself stays unresolved either way, >> the rule being prospective. >> 2. Squatting remedy: none - the victim is left to another >> database's dispute or abuse process. >> 3. Is it an improvement? "Yes, narrowly." >> 4. Evidence bar: a four-part test - whose second criterion, that >> the proposal "would have prevented" the incident, excludes by >> construction every incident that already exists; a creation-time >> rule is prospective by definition. >> 5. Impact Assessment: "I do not dispute the findings"; the >> objection shifts to what the IA does not cover. >> 6. Capacity: individual, representing no organisation or resource >> member. >> >> No other opposing account has answered any of the six. Today the >> bar has moved with nearly every message, and a seventh question now >> joins the list. My assessment, for the record: >> none of today's objections identifies a defect in what the proposal >> claims; and their cumulative effect, whatever the intent, has been >> to consume the finite attention of this Working Group - a cost >> long-standing participants have already described in their own >> words (015154, 015179). >> >> One further observation, offered for the record and without >> attributing it to any individual: this Last Call's objections began >> from the principle that the registry "may record... It may not >> rule" (015011). Today's objections ask the registry to pre-define >> delegation graphs, revocation processes, state machines, permanent >> reservations, transition audits and source-selection rules, in >> advance (015391, 015392, 015393, 015398, 015400, 015402). Those two >> standards pull in opposite directions, and the same seven-clause >> creation-time rule cannot be faulted under both at once. Which >> standard the Working Group actually holds is exactly what the >> Co-Chairs will weigh - against what the proposal actually claims: a >> creation-time naming rule, whose every stated boundary today's >> objection messages ask it to exceed. >> >> The community is entitled to expect Last Call to close on schedule >> and to be assessed on the record as it stands. >> >> Regards, >> Hendrik Visage (AS329532; also AS213481) >> >> [CompanySignature] >> Inter..link GmbH *|* Boxhagener Stra?e 80, 10245 Berlin, Germany *|* >> Managing Directors: Marc Korthaus, Theo Voss *|* Commercial Register: >> Amtsgericht Charlottenburg, HRB 138876 *|* VAT ID: DE281288887 *|* >> Email: hello at inter.link *|* Web: inter.link >> >> >> _______________________________________________ >> RPD mailing list >> RPD at afrinic.net >> https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From TshepoMasuku26 at hotmail.com Wed Jul 29 20:55:46 2026 From: TshepoMasuku26 at hotmail.com (Tshepo Masuku) Date: Wed, 29 Jul 2026 20:55:46 +0000 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: <1be501c9-70ef-4fb7-8434-c4f1a96d4f17@uls.co.za> References: <3D148AE6-C8EF-4C22-A732-779C362791CB@hevis.co.za> <1be501c9-70ef-4fb7-8434-c4f1a96d4f17@uls.co.za> Message-ID: Dear Jaco, Thank you for clarifying your interpretation. I appreciate the candour, but I think your response identifies the policy problem rather than resolving it. You describe the intended rule as: no new flat objects, with restoration allowed only on a justified request. Section 7.8.7 does not actually say that. It permits exceptions ?where necessary? without limiting them to restoration, pre-existing objects, the same object key, archived content, prior control, or lawful succession. Your interpretation may be narrow, but future staff will implement the policy text, not this email exchange. The clause therefore does more than leave an operational detail open. It gives AFRINIC continuing authority to decide when the mandatory rule does not apply. Because ?necessary? is undefined, staff can effectively determine the scope of the policy after adoption. Recording a reason after the decision does not constrain that discretion beforehand. ?Escalate the matter? is also not a defined safeguard. Escalate to whom, under which standard, within what period, and with what remedy? If two staff members may reach opposite decisions on identical facts, validity is being determined by institutional permission rather than by the policy. We do not need to predict every possible future case. We can define the only exception currently supported by the discussion: > A non-hierarchical AS-SET existing before implementation may be restored under the same object key and from its last archived state, upon verified proof of prior control or lawful succession. The restoration and its evidential basis must be recorded in an auditable log. No exception may permit creation of a flat AS-SET that did not previously exist. If a genuinely unforeseen case later arises, it can be considered on actual evidence. That is safer than granting open-ended exception authority now merely because the future is uncertain. A mandatory common rule should be narrow, but narrow does not mean vague. The policy should define what AFRINIC may enforce rather than delegating that boundary to future staff judgment. For that reason, I do not consider the concern answered, and I remain opposed to the proposal as written. Regards, Tshepo ________________________________ From: Jaco Kroon Sent: Wednesday, 29 July 2026 22:45:32 To: Tshepo Masuku ; James Bensley ; rpd at afrinic.net ; pdwg-chairs at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Hi, Sorry for top-posting, but it seems exactly me cares about most of that anyway. It's a risk. We're aware of it. If you want an object restored and your not happy with the outcome, escalate the matter. If you're unhappy with the wording, propose alternative wording or live with it. It's that simple. The inter-RIR risk is currently also there, so irrelevant, plus, I think Afrinic is the only RIR that still allows new "flat" AS-SET objects to be created. And someone pointed out to be today RADB, but I haven't confirmed that. That also reduces your risk of creating exactly the collision that we intend to prevent because those collisions would exist currently (as in before the effective date where no more flat AS-SET objects can be created)! If you can propose better wording, and with enough foresight to deal with all possible future restore situations in a sensible way I'm sure James would happily reconsider again. But I doubt that's possible bringing us back to even with an extremely lenient, and specifically vague motivation for restore we're still significantly better of than what we are today. Kind regards, Jaco On 2026/07/29 17:11, Tshepo Masuku wrote: Dear Jaco, Thank you for explaining your view. However, your concession identifies the problem: if one staff member may approve a restoration and another may reject the same request, the rule is not deterministic. Whether we call that vague or ambiguous, an operator cannot know the outcome from the policy text. There is also a specific inter-RIR risk. A flat AS-SET may be deleted from AFRINIC and the same name may then be created in another authoritative IRR before restoration. Restoring the AFRINIC object ?exactly as it was? could recreate the very cross-registry collision this proposal is intended to prevent. Confirming that the key remains free inside AFRINIC would not be sufficient. If restoration is retained, the policy should require verified prior control, restoration from the archived object rather than creation of a different object under the old name, and a conflict check at the time of restoration. It should also define how a refusal is reviewed. I do not doubt that AFRINIC staff may act reasonably. But policy must survive staff changes and cannot depend on assumptions about how generously discretion will be exercised. Trust is not a substitute for an objective rule. My concern is therefore not that the proposal fails to solve every IRR problem. It is that its exception can potentially recreate the precise problem the mandatory rule claims to close. Regards, Tshepo Get Outlook for Android ________________________________ From: Jaco Kroon Sent: Wednesday, 29 July 2026 16:48:37 To: Tshepo Masuku ; James Bensley ; rpd at afrinic.net ; pdwg-chairs at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Hi Tshepo, On 2026/07/29 15:48, Tshepo Masuku wrote: Dear James, Thank you for considering the concern carefully and explaining your decision openly. I genuinely appreciate that you engaged with the substance rather than simply dismissing it. I understand the case for incremental improvement and agree that no policy can anticipate every future scenario. My concern, however, is not that the draft must be perfect. It is that the exception clause sits at the boundary of what AFRINIC will be required, or permitted, to enforce. The absence of data cuts both ways. If we do not know how frequently restoration will be needed, that uncertainty does not necessarily justify leaving the criteria undefined. It may instead support beginning with a narrow, objective restoration rule and expanding it later if operational evidence shows that broader exceptions are necessary. I also do not think restarting Last Call is, by itself, a sufficient reason to retain ambiguous wording. Once adopted, the policy will be binding until another proposal completes the PDP. During that period, AFRINIC will have to interpret ?where necessary? without agreed criteria. That is not quite the same as a temporary implementation experiment. I don't think it's ambiguous, it may be vague, but not ambiguous. I will concede it leaves the jay or nay decision to operational discretion, and one person may decide yes, another may decide no, but IMHO *any* reason to restore an object would be operational of nature, something like "Hi, we've deleted object X, but it has come to light it's still being referenced by {insert another object|operational peer name|AS} and we're having trouble getting the relevant party to update, could you please restore". I don't foresee any other case of restoration case that I would consider to be valid. But precisely that "cannot foresee" is why I believe it's best to leave it to Afrinic staff to determine the validity of any motivation for *restoration* of an object. At that point it becomes a debate. And I've not yet encountered Afrinic staff to be unreasonable and they'll most likely err on the side of restoring (exactly as it was, without modification) rather than not. A narrowly drafted restoration safeguard would not be an attempt to build the whole castle at once. It would simply make the first brick clear enough that operators and staff know what it permits. The common layer should be minimal, but what it contains should also be deterministic and auditable. Without knowing what will or may be required in the future this is exceptionally difficult, as per James, to narrow down. I agree with James that it's best to intentionally leave it vague. Bottom line is: no new "flat" objects, and restore only on motivation to Afrinic staff (which will likely be in the lines above). At some point we would likely want to get a list of all "flat" objects and see if they're still *referenced*, confirming actual *use* is harder since we have no way of knowing whether any implementation references that object. At least, none I'm aware of. If there is a way it would likely involve Afrinic having to check some query log and if the object name hasn't been queried in some time. But that's not to say there aren't gateway systems (such as rr.ntt.net - default queried server by at least bgpq4) running some form of irrd, that doesn't pull the entire database and then references "offline", so without looking into exactly how that infrastructure works, there's no way to identify completely unused objects I don't think. I trust this answers your concern. Kind regards, Jaco I respect your decision not to revise the draft, and I appreciate your constructive approach. However, because the difference between a guaranteed restoration right and discretionary case-by-case approval remains unresolved, I cannot support the proposal as currently written and therefore maintain my objection. kind regards, Tshepo ________________________________ From: James Bensley Sent: Wednesday, 29 July 2026 14:26:30 To: Tshepo Masuku ; rpd at afrinic.net ; pdwg-chairs at afrinic.net Subject: Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Dear Tshepo, After careful consideration I have decided not to revise the draft. There are a couple of reasons for this: * I think this is becoming too prescriptive. If we try to define a time period for restoration for example, for some people it will be too long, for others too short. We have no data to make an informed decision here. Similarly the point about having a public log. That requires us to define what that looks like and how it works. We have no idea how often this process would be enacted so we can't described what that needs to look like. We have no data. I think trying to make a perfect policy that covers all cases is the wrong approach. I think we should be aiming to get "something" implemented, let it run for a while, gather feedback, and then if it needs adjusting, we can raise another policy change proposal. Nothing is set in stone here. There's no need to get his perfect first time, we can iterate over time. * Any changes to the draft will restart the Last Call and potentially also require the staff to re-review the draft. The changes you proposed, whilst valid, are optimising for a corner case (how often to people delete their AS-SET by mistake? I would say, rarely). Why delay getting "something" deployed, which we can continue to iterate on, just to optimise for a corner case (restores aren't blocked by this policy)? For these reasons I have decided not to modify the draft. With kind regards, James Bensley (he/him) ________________________________ From: Tshepo Masuku Sent: 28 July 2026 15:28 To: James Bensley ; rpd at afrinic.net ; pdwg-chairs at afrinic.net Subject: Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Dear James, Thank you for engaging with the concern constructively. Your proposed wording is a meaningful improvement because it begins replacing an open-ended exception with objective conditions. I think a few points still need tightening before the rule is ready: * Restoration should return the object to its last valid archived state, not merely reuse the same key. Otherwise, an old flat name could be restored with entirely different contents and become a new object in substance. * The text should define whether the restoration right is permanent or subject to a recovery period. * ?Another maintainer within the same organisation? and an organisation ?responsible for the assets? require objective evidence, such as registry history or documented legal succession. Those terms should not be left entirely to staff interpretation. * The residual case-by-case provision should expressly prohibit creating a flat name that did not exist before implementation. * Every exceptional decision should record the evidence relied upon and provide a review or appeal path, not merely an audit entry. I would also suggest wording along these lines: A restored object shall initially reflect its last valid archived state, except that maintainer and contact attributes may be updated where necessary to establish control by the verified original holder or lawful successor. Because this changes the normative enforcement boundary, I believe v3 should be published with an updated Impact Assessment and receive proper review. It should not be treated as a minor editorial correction during the final days of Last Call. I remain opposed to DRAFT02 as written, but I appreciate your willingness to address the defect directly. This is the kind of concrete engagement that adds value to the process. Regards, Tshepo ________________________________ From: James Bensley Sent: Tuesday, 28 July 2026 13:39:50 To: Tshepo Masuku ; rpd at afrinic.net ; pdwg-chairs at afrinic.net Subject: Re: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Dear Tshepo, Thank you for providing your feedback. I am in agreement with your statement. I am the original author of this draft change, and I wrote in my last update (version 2): "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." The staff assessment was to go with the following "7.8.7 Exceptions for the creation of hierarchical names may be granted where necessary. AFRINIC shall document the reason for any exception.". The staff asked me to review their assessment and I initially agreed, because it was loser than my definition. There may be other scenarios where restoration is required which I/we haven't thought of, so why limit it to accidental deletion only. Opening it up to allow any case to be reviewed has benefits. But as you say, it could also go the other way, it could simply mean that every case is rejected. I am going to submit another version (v3) of the document, only replacing the text I quoted above, with the text below, to fix the problem you raised of the text having gone from being too strict before to now being too lose (I will try to propose something in the middle which guarantees delete/restoration is protected, anything else needs a review). I am proposing the following text, what do you think? ------ A non-hierarchical AS-SET existing before implementation of this policy change, which has since been deleted, must be restorable when the following conditions are met: - The same object key is requested for restoration (no AS-SET name changes allowed) - No object with a conflicting name has been created between the date of deletion and the date the restore is made - The restore request is coming from either a maintainer that was present on the deleted object, or another maintainer within the same organisation (in the case the maintainer was also deleted), or a maintainer in an organisation responsible for the assets of the original organisation (in the case of a merger or acquisition). - The restoration is recorded in an auditable log. Any other request for restoring a deleted AS-SET created before the implementation date of this policy change will need to be reviewed by AFRINIC on a case by case basis. ------- With kind regards, James Bensley (he/him) ________________________________ From: Tshepo Masuku Sent: 27 July 2026 15:29 To: hvisage at hevis.co.za ; Nonjabulo Sphilile ; Phetulo Dhlamini ; Taye Medoye ; Thulisile Mazomba ; rpd at afrinic.net Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) ?? Caution: This email originated from outside of your organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe. Dear Hendrik and colleagues, Thank you for consolidating the discussion. I will not repeat the earlier lifecycle, resolver, delegation, or membership arguments. There is, however, a separate defect in the actual text being considered. The proposal says that exceptions MUST be allowed on a case-by-case basis and gives restoration of an accidentally deleted flat AS-SET as the example. The staff-recommended wording instead says exceptions may be granted ?where necessary.? These are materially different rules. Under the first version, an eligible operator has a right to restoration. Under the second, restoration depends on AFRINIC?s discretion. The wording also changes a narrow restoration example into an undefined general exception. That produces a concrete operational difference. If a grandfathered flat AS-SET is accidentally deleted after implementation, one version requires a restoration path while the other allows AFRINIC to refuse it. Operators and peers referencing that object cannot know which outcome the adopted policy guarantees. This is not an adjacent lifecycle problem. It is the enforcement boundary of the present proposal. The text should therefore be amended to provide one deterministic rule. For example: > A non-hierarchical AS-SET existing before commencement may be restored only where the same object key is requested within a defined recovery period, the request is authenticated by the maintainer authorised immediately before deletion, no conflicting object has intervened, and the restoration is recorded in an auditable log. No other exception may authorise creation of a new non-hierarchical AS-SET. That would preserve accidental-deletion recovery without leaving the supposedly closed namespace subject to undefined staff judgment. Documenting the reason after an exception is granted is not the same as defining the conditions under which the exception is valid. Implementation guidance also cannot resolve a conflict between ?MUST? and ?may? after ratification. Before Last Call closes, the authors and co-chairs should identify which wording is actually under consideration and resolve the difference in normative force. Until then, I remain opposed to the proposal as written. Regards, Tshepo ________________________________ From: hvisage at hevis.co.za Sent: Monday, 27 July 2026 15:11:31 To: Tshepo Masuku ; Nonjabulo Sphilile ; Phetulo Dhlamini ; Taye Medoye ; Thulisile Mazomba ; rpd at afrinic.net Subject: [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) Good day Tshepo, Nonjabulo, Phetulo, Taye, Thulisile, colleagues, Apologies to the human readers for this voluminous post, but I?d rather address as much in one email than to flood the mailing list With even more messages as I?d rather do a digest type response for all the similar objections at once. For nearly two weeks we have been asking for technical substance; today, in the week Last Call closes, technical reasons have at last been presented. Before I respond to them, let me add a seventh question to the six of 23 July (015344): Question 7: could you please provide the technical issues, difficulties, and real-world examples where implementation of this draft policy - as three RIRs have already implemented it, and the fourth is formally proposing - would negatively affect your current or future operations? We would like to understand those too. Operational evidence of that kind would genuinely add to the body of knowledge on this proposal. Note: numbers like (015344) are message IDs in the RPD archive - prepend https://lists.afrinic.net/pipermail/rpd/2026/ and append .html to read any of them. So let's get to the objections we have been waiting two weeks for: 1. object lifecycle under changes of ASN control (015387, escalated in 015391 and 015400) - answered by Jaco in (015388) and (015394) 1b) its delegated-maintainer extension (015398, pressed again in 015400) - Jaco deferred to the RFC in (015399); the deferral is completed in section 1 below 2) recursive expansion of members: references (015389) - answered in (015390) 3) grandfathered flat objects (015392) - answered in (015395) 4) multi-source name resolution (015393) - answered in (015396, 015397) 5) anchor-ASN eligibility and authentication (015401) - addressed in section 5 below 6) implementation rollout process (015402) - addressed in section 6 below; its delegation and 7.8.7 points are answered in section 1 (the delegation question is 015398/015400 returning), and its benefit-scope point in the common ground just below I refer to and endorse Jaco's answers rather than repeat them. It was asked earlier in this Last Call that objections be addressed as grouped issues rather than piecemeal, and in that spirit I have collated the responses in a single email, adding what has not yet been shared: a precise statement of the authorisation model, the published data, and the cross-registry record. First, the common ground, because it is substantial. In today's own words: * hierarchical naming "can strengthen creation authorisation" (015393) * the proposal "secures the first object name" (015389) * the concerns are "not questions about whether AS-SET membership is correct" (015387) * ASN-anchored naming "can reduce future flat-name collisions" (015402) None of today's messages disputes what the proposal does. Each of today's objections asks it to also solve an adjacent problem - * lifecycle * delegation semantics * expansion semantics * legacy objects * mirror copies * anchor eligibility * and every one of those problems exists today, everywhere, with or without this policy. That is not the discovery of a defect. It is the discovery that the proposal has a scope, which it states and which was put on this record weeks ago (015119, 015120, 015123; and the draft's own sections 7.8.3-7.8.6). 1. The authorisation model, changes of ASN control, and delegation (015387, 015391, 015398, 015400, 015402) Jaco deferred to the RFC on the depth mechanics (015399). Rightly so - the RFC, followed to the top of the chain, completes his answer. (015398) states the rule correctly: a first-level object, AS12345:AS-CUSTOMERS, is created under the authorisation of the aut-num AS12345 as it stands at that moment - its maintainer chain, which follows the current registered holder. A deeper object, AS12345:AS-CUSTOMERS:AS-EU, is created under the authorisation of the maintainer of its immediate parent. Now ask where that parent came from: its own creation was authorised by the level above it, and so on, terminating at the aut-num itself. Every object in the tree exists because the level above authorised its creation. Delegation, where it exists, exists because the chain authorised it. And who controls each level is answerable, level by level, from the database as it stands - which is what verifiable control looks like in RPSL. The emphatic difference at the current state is that a flat name offers just a maintainer but no chain: no root, and no way to ask whether the name was ever anyone's to create - beyond that it must not already exist in THIS one database. (015400) concludes that because deeper control can be delegated, the "control model remains unspecified". The opposite is the case: the control model is fully specified - in the very RFC that (015398) cited, which is why deferring to it was the right answer. That deeper authority is delegated, and that delegated authority does not automatically follow the ASN, is not a gap in the model; it is the model, working as designed for twenty-seven years, for every hierarchical object family, at every RPSL-based registry. A policy does not "leave AFRINIC to interpret" what the RFC and the production database already define - any more than this proposal needs to restate what mnt-by means. What deterministically follows the ASN is the root of every chain: authority over creation and recreation at the first level of the namespace. That is precisely * and only - what the proposal's attribution claim covers. The same depth question returns in (015402); the answer above stands. These semantics are not invented by this proposal. They are RFC 2622 (1999), operated by RPSL-based registries - AFRINIC's included * for twenty-seven years. The proposal does not modify them; it gates which names may come into existence, nothing else. The two outcomes (015398) poses are therefore both answered by the semantics already in production: descendants do not move automatically, so no delegated maintainer is overridden - exactly as for every delegated object today. And the new holder gains precisely what the name anchors: authority over creation and recreation at the first level of its namespace. What the new holder does not get - control over objects a previous holder's delegates still maintain - is what nobody has today under flat names, for any object, ever. A stale delegated descendant is today's universal condition; the proposal neither creates nor worsens it, and no registry in those twenty-seven years has defined the demanded delegation-and-revocation regime for set objects in policy. How ASN control actually changes in this region is likewise not a matter for speculation. AFRINIC publishes it: https://ftp.afrinic.net/pub/stats/afrinic/transfers/transfers_latest.json A full read of that file today: 75 ASN-carrying transfer events (91 ASNs) from 2018 through 2026 - about nine such events a year - and every single one is a merger/acquisition succession, in which the organisation and its maintainer control pass together, so parent ASN and child objects move as one unit. That is the published record behind Jaco's description in (015394), with the frequency question answered exactly: none open-market, all successions that preserve the attribution chain by construction. Anyone can verify this from the file. So the concern of (015391) has been addressed - with our registry's own data. The cross-registry record answers the rest. I checked this week, across the policy, procedural and database-documentation layers of the other four RIRs. RIPE has required hierarchical names for new as-sets since December 2022 and operates full ASN transfers, including inter-RIR; APNIC likewise since July 2023 (prop-151); LACNIC's IRR has been structurally hierarchical since it launched in 2020; at ARIN hierarchical naming is available today and a mandate for new objects is formally proposed (ARIN-prop-342, pending) - the same direction. All four are silent on child as-set lifecycle at every layer. Across the deployed implementations that is roughly three and a half years of exactly the coexistence (015387) warns about - hierarchical mandates running over live ASN transfer markets - and I could not find one documented incident of the failure mode described. In every deployed implementation, lifecycle lives where it belongs: in standard RPSL authorisation and registry operations, not in naming-policy text. On 7.8.7 (015391, 015402): today the namespace has no rule at all - every creation, by anyone, of any name, is the exception. A closed default with documented-reason exceptions cannot be less deterministic than no default whatsoever. And credit where due: (015402) makes one point that verifies - the staff assessment's prose cites "7.8.6" for the restoration-of-deleted-objects exception, where 7.8.6 concerns editing and the exception clause is in fact 7.8.7. That is a cross-reference slip in the assessment's commentary, worth an erratum, and it changes nothing in the policy text: the clauses say what they say, and staff's own recorded caution about recall loopholes shows the right mechanism was analysed. As for the demanded exception criteria: 7.8.7 requires every exception to be documented with its reason - a discipline stricter than today, where no creation needs any reason at all. 1. Recursive expansion of members: references (015389) Correct as far as it goes - and it concedes the top level is secured. What members: may contain is a content question, expressly outside this proposal's scope, and outside the naming policies of every registry that already runs this rule: none coupled naming to expansion semantics, because that coupling is a different and larger policy. Jaco has already named the constructive path (015390): a members-qualification rule would be a coherent separate proposal, and wording was invited. Meanwhile every new hierarchical set is one fewer ambiguous reference for the next expansion to fear * the gap this concern describes narrows with adoption and stays open without it. 1. Grandfathered flat objects and the transition window (015392) The capability described - register flat names now, populate them later - exists today, permanently, with or without this proposal. Anyone may do it this afternoon. The proposal is the only mechanism before this Working Group that ever closes that window; declining it preserves the window forever. If gaming of the implementation gap is the genuine worry, the remedy is a short implementation period - a staff scheduling matter - not an indefinitely open namespace. And, respectfully: (015392) describes with precision the squatting behaviour whose future possibility this policy exists to end. An objection that demonstrates the attack is an argument for closing the door. 1. Multi-source resolution (015393) Jaco's answer (015396, 015397) is complete: an ASN is delegated by exactly one registry, so a hierarchical name carries its authoritative source in its own first element. The question "which source is authoritative for this set?" has a deterministic answer precisely and only when the name is hierarchical; under a flat name that answer does not exist anywhere. The working-group draft cited in (015393) pursues the same determinism through source-qualified references - the two mechanisms are complements, not conflicts, and that draft's problem statement describes the flat-name condition this proposal removes for new AFRINIC sets. What a third-party mirror carries is today's condition for every object in every IRR database and is governed by no naming policy at any registry. 1. Anchor-ASN eligibility and authentication (015401) Taye, this is the kind of message Last Call is for: specific, technical, and naming the exact requirements it wants. Three responses. First, on substance: the properties you list - the leading ASN globally assigned, an authoritative aut-num present, creation authenticated against that object's maintainer, private-use and reserved ranges (RFC 6996) excluded, canonical ASPLAIN form (RFC 5396) - are, I would argue, what the Impact Assessment's own authorisation claim already entails. An anchor with no holder can authorise no one; a check that can pass in the absence of the aut-num it authenticates against would not be the check the assessment describes. So I read your list not as a new mechanism but as the strict, and correct, reading of the mechanism the proposal already claims. Second, on where it belongs: those are implementation semantics - the authentication mode of the database software and the eligible ASN ranges - and I would support AFRINIC staff recording exactly your list in the implementation guidance for this policy, alongside the failure behaviour per creation path. That is the normal home of such requirements at every registry, and section 7.8.7's documented-exception mechanism gives staff the instrument for any edge the guidance must handle. It is worth adding: even in the weakest imaginable configuration, an unattributable hierarchical-form name is no worse than today, where every name of any form requires no authorisation from anyone. Third, on form: yours is the closest any message in this Last Call has come to proposed text. If you formalise that list as wording - whether as implementation guidance or as a clarification for a future revision - I have no doubt this Working Group will engage it on its merits, exactly as was invited days ago (015390). It is the constructive instrument the process recognises. 1. Implementation rollout process (015402) Warning-only phases, test vectors, baselines, rollback plans and scheduled reviews are implementation artifacts. They are produced by registry staff during implementation - at every RIR - and they appear in no naming policy anywhere: RIPE shipped its hierarchical requirement through the database release process, with release notes and a release-candidate test environment, on the strength of a policy text that contains none of those artifacts. Nothing in this proposal forbids a staged, warning-first deployment; that is exactly the kind of detail the implementation phase exists to define, and 7.8.7's documented-exception mechanism gives staff the instrument for edge handling during it. Taken at face value, (015402)'s final section is an argument about deployment scheduling, which follows ratification - not a reason to withhold it. Stepping back, twice. Each of the demands in messages (015387), (015389), (015391), (015392), (015393), (015398), (015400) and (015402) carries the same condition: "before adoption" (015387, 015389, 015391), "before mandatory enforcement" (015393), "before this proceeds" (015398), "until ... addressed" (015392), "until that is clarified" (015400), "until ... clearly resolved" (015402). As Seun reminded the list (015386), this PDP has no conditional adoption: a proposal cannot pass Last Call subject to future homework. At day eleven of Last Call, "resolve and test before advancing" therefore spells "do not adopt". The process has exactly one instrument for a genuine, fixable concern: proposed text. Jaco invited it (015390). Let me emphasise the arithmetic: seven distinct technical concerns in a single day, after eleven days without one - and, section 5's requirements list aside, still zero proposed amendments. Of the six questions of 23 July (015344), exactly one account engaged them point by point - Tshepo, in (015348) - and the record should credit those answers. In short: 1. Two-object case: tooling should bind to an explicitly selected source or stop and report - the fail-closed behaviour supporters had proposed; the live case itself stays unresolved either way, the rule being prospective. 2. Squatting remedy: none - the victim is left to another database's dispute or abuse process. 3. Is it an improvement? "Yes, narrowly." 4. Evidence bar: a four-part test - whose second criterion, that the proposal "would have prevented" the incident, excludes by construction every incident that already exists; a creation-time rule is prospective by definition. 5. Impact Assessment: "I do not dispute the findings"; the objection shifts to what the IA does not cover. 6. Capacity: individual, representing no organisation or resource member. No other opposing account has answered any of the six. Today the bar has moved with nearly every message, and a seventh question now joins the list. My assessment, for the record: none of today's objections identifies a defect in what the proposal claims; and their cumulative effect, whatever the intent, has been to consume the finite attention of this Working Group - a cost long-standing participants have already described in their own words (015154, 015179). One further observation, offered for the record and without attributing it to any individual: this Last Call's objections began from the principle that the registry "may record... It may not rule" (015011). Today's objections ask the registry to pre-define delegation graphs, revocation processes, state machines, permanent reservations, transition audits and source-selection rules, in advance (015391, 015392, 015393, 015398, 015400, 015402). Those two standards pull in opposite directions, and the same seven-clause creation-time rule cannot be faulted under both at once. Which standard the Working Group actually holds is exactly what the Co-Chairs will weigh - against what the proposal actually claims: a creation-time naming rule, whose every stated boundary today's objection messages ask it to exceed. The community is entitled to expect Last Call to close on schedule and to be assessed on the record as it stands. Regards, Hendrik Visage (AS329532; also AS213481) [CompanySignature] Inter..link GmbH | Boxhagener Stra?e 80, 10245 Berlin, Germany | Managing Directors: Marc Korthaus, Theo Voss | Commercial Register: Amtsgericht Charlottenburg, HRB 138876 | VAT ID: DE281288887 | Email: hello at inter.link | Web: inter.link _______________________________________________ RPD mailing list RPD at afrinic.net https://lists.afrinic.net/mailman/listinfo/rpd -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvisage at hevis.co.za Wed Jul 29 21:39:58 2026 From: hvisage at hevis.co.za (Hendrik Visage) Date: Wed, 29 Jul 2026 23:39:58 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: <3D148AE6-C8EF-4C22-A732-779C362791CB@hevis.co.za> <1be501c9-70ef-4fb7-8434-c4f1a96d4f17@uls.co.za> Message-ID: <1282D5CC-B74E-43CD-8890-EABD5EE69EE5@hevis.co.za> Hi Tshepo, To be Hendrik and Honest, I'll make the claim the community cares about this issue - the archive shows the operators that run networks here do care about it. And yes, AfriNIC is handling and keeping book of those resources that those network operators in the Africa Region need and care about and want to protect it. But here is what I struggle to follow, and I put it plainly for the record: the remedy you drafted in (015421) - restore the pre-existing AS-SET, under the same key, from its archived state, with documented evidence - is the remedy that is already inside the draft you oppose. Section 3 of DRAFT02 says exceptions MUST be allowed on a case-by-case basis, and its own example is your exact case: an AS-SET "deleted by mistake" that "should be possible to restore ... without having to rename it". The staff assessment (7.8.7) adds the documented reasons you ask for. Your text does not add this remedy, it narrows the one that is already there. So the position now on record is: two weeks of arguing this proposal is too restrictive, ending in an amendment to make it more restrictive, while remaining opposed "as written" to the only text on the table that contains your own remedy. And if the proposal falls, there is no restoration rule at all - not your narrow one, not the draft's wide one, nothing. The theoretical cases in between ((015415), (015417)) were answered with the registry mechanics in (015416) and (015418): they require transfer types AFRINIC does not perform. If the community later wants the exception narrower, that is one normal PDP cycle away, as James already explained in (015412). It is not a reason to keep zero protection today. I said in (015418) that the record is complete for the Co-Chairs, and I hold to that. This message only puts the above contradiction plainly in that record, in my own broken English. Yours humanly, Hendrik Visage (AS329532; also AS213481) From fundiswanadia2 at gmail.com Thu Jul 30 04:59:36 2026 From: fundiswanadia2 at gmail.com (Fundiswa Nadia Maseko) Date: Thu, 30 Jul 2026 06:59:36 +0200 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: Dear colleagues, I think we've now narrowed the discussion down to the main technical issue. I agree that this proposal is about naming and not about defining how a future inter-RIR transfer policy should work. If AFRINIC ever adopts such a policy, those details would naturally belong there. That said, I also think it's important that we don't claim more for this proposal than what it can actually guarantee. >From my reading, the proposal clearly provides benefits such as unique naming at creation, a more structured namespace, and improved administrative clarity within the AFRINIC IRR. Those are meaningful improvements. Where I still have reservations is the suggestion that these naming rules, by themselves, provide a continuous, globally authoritative identity for AS-SET objects across all routing tools and IRR consumers. If that is part of the proposal's intended benefit, it would be helpful to see the implementation evidence or operational examples that demonstrate this behaviour in practice. If that evidence does not exist, then I believe the proposal and its Impact Assessment would be stronger if they simply described the guarantees the mechanism actually provides, without extending those claims further. I believe that kind of clarity would benefit everyone, regardless of whether they support or oppose the proposal. Kind regards, Fundiswa Nadia Maseko On Wed, 29 Jul 2026, 20:29 , wrote: > Send RPD mailing list submissions to > rpd at afrinic.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.afrinic.net/mailman/listinfo/rpd > or, via email, send a message with subject or body 'help' to > rpd-request at afrinic.net > > You can reach the person managing the list at > rpd-owner at afrinic.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of RPD digest..." > > > Today's Topics: > > 1. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage) > 2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Tshepo Masuku) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 29 Jul 2026 20:21:10 +0200 > From: Hendrik Visage > To: Tshepo Masuku , rpd at afrinic.net > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: <32BB6C1F-18CF-44AC-ACDF-979D0BE9E81D at hevis.co.za> > Content-Type: text/plain; markup=markdown > > Good day Tshepo, > > Three short points, and then I'll leave the record to the Co-Chairs. > > First: your scenario requires an inter-RIR ASN transfer. AFRINIC does > not perform inter-RIR transfers - not for ASNs, not for anything. > There is no policy for it in the CPM, and the other registries list > AFRINIC as not approved for transfers in either direction. So the > event your whole scenario depends on cannot occur in this region > under any rule that exists - and a NAMING proposal can neither create > that capability nor govern it. If our community one day adopts an > inter-RIR transfer policy, THAT policy is where object handling on > transfer gets defined - which is exactly where the deployed > registries define it today (APNIC's transfer conditions, for example, > spell out which dependent objects get deleted when a resource > moves). You are asking the wrong document to answer, before the > right document exists. > > Second: the "how do tools distinguish the current authoritative > object from the historical one" question has a running answer > already: the delegated statistics files every RIR publishes daily, > which record each ASN's current registry - transfers included, > single-valued at every instant. That is the map the whole IRR > tooling world uses today. And notice: under flat names your > succession scenario is strictly worse, because then there is no map > at all. > > Third, on Question 7: I asked for the technical issues and real-world > examples where this policy would negatively affect YOUR current or > future operations. A hypothetical relying operator, in a transfer > type that is not available in this region, is not that. So I note, > with appreciation for the attempt, that Question 7 still stands > unanswered. And to be fair on the record: of the six questions of > (015344), yours in (015348) remain the only point-by-point answers > given - answers I credited in (015404) - the rest of the opposition > has answered none. > > The record is now complete enough for the Co-Chairs to do their work, > and I am content to leave it to them. > > Regards, > Hendrik Visage (AS329532; also AS213481) > > > > > ------------------------------ > > Message: 2 > Date: Wed, 29 Jul 2026 18:28:45 +0000 > From: Tshepo Masuku > To: Hendrik Visage , "rpd at afrinic.net" > > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical > Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > Message-ID: > < > AM6PR04MB59921D9A6819806346BA1927CACA2 at AM6PR04MB5992.eurprd04.prod.outlook.com > > > > Content-Type: text/plain; charset="us-ascii" > > Dear Hendrik, > > Thank you. I will respond directly to your three points. > > First, Question 7 is a test you introduced. It is not a requirement that > every objector demonstrate personal damage to their own production network > before a policy concern may be considered. A mandatory rule may be > challenged because its state model, implementation assumptions, or > enforcement boundaries are incomplete. > > Making personal operational harm the admission price for an objection > would turn an open PDP into an operator-credential test. Experience is > relevant evidence; it is not exclusive authority. > > Second, the delegated statistics file does not provide the guarantee you > claim. It maps an ASN to its current registry. It does not identify which > AS-SET object a resolver actually used, invalidate an old copy, update > every mirror or cache simultaneously, or confirm the present maintainer > chain of a delegated descendant. > > A file published daily is not a globally atomic authority mechanism. > > If the claim is that running tools already use that map to reject > historical or conflicting AS-SET objects, please identify the relevant > resolver behaviour, code path, or test case. Otherwise, this remains an > architectural assumption rather than running-code evidence. > > The proposal can reasonably claim that a new name is unique and > authenticated inside the AFRINIC database at creation time. It should not > be credited with continuous, globally deterministic source resolution > unless that behaviour is demonstrated across the actual tooling that > consumes the data. > > Third, you asked for effects on current or future operations, but then > excluded the future scenario because AFRINIC does not currently support > inter-RIR ASN transfers. Those positions cannot both stand. > > A policy intended to remain in force cannot use the present absence of > another policy as proof that its own assumptions will remain valid > indefinitely. If a future transfer policy must define the object > transition, then that confirms the present proposal does not define it. > > I am not asking this proposal to solve every transfer problem. I am asking > that its text and Impact Assessment claim only what the mechanism actually > guarantees. > > The unresolved issue is therefore specific: the proposal creates local, > creation-time naming and authentication rules, while its supporters > attribute to it a global and continuing authority property that has not > been demonstrated in running tools. > > The record is not made complete merely by declaring it complete. Until the > claims are narrowed to the property actually proved, I remain opposed. > > Regards, > Tshepo > > > ________________________________ > From: Hendrik Visage > Sent: Wednesday, 29 July 2026 20:21:10 > To: Tshepo Masuku ; rpd at afrinic.net < > rpd at afrinic.net> > Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names > for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) > > Good day Tshepo, > > Three short points, and then I'll leave the record to the Co-Chairs. > > First: your scenario requires an inter-RIR ASN transfer. AFRINIC does > not perform inter-RIR transfers - not for ASNs, not for anything. > There is no policy for it in the CPM, and the other registries list > AFRINIC as not approved for transfers in either direction. So the > event your whole scenario depends on cannot occur in this region > under any rule that exists - and a NAMING proposal can neither create > that capability nor govern it. If our community one day adopts an > inter-RIR transfer policy, THAT policy is where object handling on > transfer gets defined - which is exactly where the deployed > registries define it today (APNIC's transfer conditions, for example, > spell out which dependent objects get deleted when a resource > moves). You are asking the wrong document to answer, before the > right document exists. > > Second: the "how do tools distinguish the current authoritative > object from the historical one" question has a running answer > already: the delegated statistics files every RIR publishes daily, > which record each ASN's current registry - transfers included, > single-valued at every instant. That is the map the whole IRR > tooling world uses today. And notice: under flat names your > succession scenario is strictly worse, because then there is no map > at all. > > Third, on Question 7: I asked for the technical issues and real-world > examples where this policy would negatively affect YOUR current or > future operations. A hypothetical relying operator, in a transfer > type that is not available in this region, is not that. So I note, > with appreciation for the attempt, that Question 7 still stands > unanswered. And to be fair on the record: of the six questions of > (015344), yours in (015348) remain the only point-by-point answers > given - answers I credited in (015404) - the rest of the opposition > has answered none. > > The record is now complete enough for the Co-Chairs to do their work, > and I am content to leave it to them. > > Regards, > Hendrik Visage (AS329532; also AS213481) > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > https://lists.afrinic.net/pipermail/rpd/attachments/20260729/60d10620/attachment.html > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > RPD mailing list > RPD at afrinic.net > https://lists.afrinic.net/mailman/listinfo/rpd > > > ------------------------------ > > End of RPD Digest, Vol 222, Issue 223 > ************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From geier at geier.ne.tz Thu Jul 30 05:15:36 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Thu, 30 Jul 2026 08:15:36 +0300 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: <995571c2-cc70-4070-9a83-a2d404f70a53@geier.ne.tz> Hi, On 7/29/2026 9:06 PM, Tshepo Masuku wrote: [snip] > Consider this case: > > AS65000:AS-CUSTOMERS exists in the AFRINIC database and is maintained by > the previous holder or a delegated maintainer. AS65000 later changes > holder or authoritative registry. The proposal does not define what > happens to that AS-SET. I am convinced that when AfriNIC deletes an IPv4 allocation - an inetnum object from the database, then AfriNIC also deleted inetnum objects of subnets. These people are paid to keep the database in order. I see in January object inetnum: 154.66.228.0 - 154.66.231.255 was deleted [1]. And the same day object inetnum: 154.66.229.0 - 154.66.229.255 was deleted as well. I trust this was AfriNIC procedure, as it should be. So if AfriNIC were in the future (or maybe already now) to delete an aut-num object (an ASN), then I am convinced that it will be in the AfriNIC procedures that hierarchical AS-SET objects beginning with that ASN will also get deleted. I would like to say that this detail does not need to be written in the proposal. Just like the mechanism for IPv4 resources (subnets) is not written in policy. Thank you. Frank Habicht operating a few networks in Africa [1] the /22 is the allocation - delegated file from last year: afrinic|MU|ipv4|154.66.228.0|1024|20131209|allocated|F36BE2CF > If the old object remains while the new holder creates the same > hierarchical name in the new authoritative source, two objects with the > same supposedly unique name may coexist. Both may have been validly > authorised when created, but they represent different holders and > different points in time. per above, I don't believe the object will remain. > What is needed is a documented and tested state transition explaining: this can be internal AfriNIC documentation. And if you want you can ask AfriNIC to share it. > whether dependent AS-SETs move with the ASN; the holder can create the AS-SET object in the new registry. AfriNIC will surely ensure the AS-SET object(s) get deleted when the aut-num is moving away (see above). I can not confirm, but AfriNIC can. > whether they remain under delegated maintainers; > > whether the old source publishes a tombstone or transfer status; > > whether the new holder may recreate the same name elsewhere; and of course a holder may create a new hierarchical AS-SET in the new registry... > how tools distinguish the current authoritative object from the > historical one. > > > Without that, the statement that the ASN-to-registry map always provides > a deterministic authoritative source is not established by running > implementation. when an aut-num gets deleted, any hierarchical AS-SET with that ASN gets deleted. ==> ASN-to-registry map has deterministic authoritative source Regards, Frank From geier at geier.ne.tz Thu Jul 30 05:37:23 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Thu, 30 Jul 2026 08:37:23 +0300 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: References: Message-ID: Hi, On 7/30/2026 7:59 AM, Fundiswa Nadia Maseko wrote: [snip] > Where I still have reservations is the suggestion that these naming > rules, by themselves, provide a continuous, globally authoritative > identity for AS-SET objects across all routing tools and IRR consumers. > If that is part of the proposal's intended benefit, it would be helpful > to see the implementation evidence or operational examples that > demonstrate this behaviour in practice. Like with previous proposals, also here we will see implementation evidence or operational examples only after it is implemented. > If that evidence does not exist, then I believe the proposal and its > Impact Assessment would be stronger if they simply described the > guarantees the mechanism actually provides, without extending those > claims further. In my reading, the guarantees the mechanism actually provides are described in the proposal. From the proposal: Therefore, there is a need for AS-SET names to be unique across authoritative IRR database, and to authorize the name assigned to the AS-SET. This can be achieved by enforcing newly created AS-SETs to have hierarchical names. This makes the AS-SET name unique because the AS number at the front of the AS-SET is uniquely assigned by the RIR which assigned the AS number. Regards, Frank From geier at geier.ne.tz Thu Jul 30 06:43:36 2026 From: geier at geier.ne.tz (Frank Habicht) Date: Thu, 30 Jul 2026 09:43:36 +0300 Subject: [rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) In-Reply-To: