WHOIS SEARCH LOGIN TO MYAFRINIC

AFRINIC-37 | Public Policy Meeting

Policy Development Process (PDP)

AFRINIC-37 Public Policy Meeting - Draft Minutes of Meeting

  • Meeting Date: 24 June 2026
  • Time: 09h00 to 17h00 UTC+3
  • Format: Online and On-site Ole Sereni Hotel Nairobi Kenya

Logistical overview

Susan Otieno introduced the AFRINIC 37 public policy meeting, highlighting it as a significant milestone for the Africa Internet Summit 2026. She emphasised the community's shared responsibility in ensuring Africa's internet remains open, stable, and resilient, noting that these discussions will help shape the future management of internet resources across the continent and the Indian Ocean. Susan Otieno further underscored that the process relies on active, inclusive community engagement, and reminded all attendees that the meeting is guided by the Afrinic Code of Conduct to ensure professional and constructive participation.

She then invited the Policy Development Working Group co-chairs Dr. Vincent Ngundi and Darwin da Costa( joining online) , alongside the African Policy Liaison Team to officially commence the AFRINIC- 37 Public Policy Meeting.

Presentation URL: PDF

Delegates were welcomed to the meeting (by Dr. Vincent Ngundi, PDWG Chair). The agenda was presented and there were no modification requests. The agenda is as follows:

TimeSession
09h00 - 09h05Logistical Overview
09h05 - 09h10Opening & Agenda Walkthrough
09h10 - 10h00AFPUB-2026-IPv4-001-DRAFT02: Soft Landing, Recovered Space and Priority
10h00 - 10h15TEA BREAK
10h15 - 11h05AFPUB-2026-GEN-001-DRAFT01: PDP Working Group (WG) Guidelines and Procedures
11h05 - 11h55AFPUB-2026-IPv4-002-DRAFT02: Soft Landing Utilisation Amendment
11h55 - 12h45AFPUB-2026-ASN-001-DRAFT02: Hierarchical Names for New AS-SETs
12h45 - 13h00Status of Ratified Policies
13h00 - 14h25LUNCH BREAK
14:25 - 15:15IPv6 as a criteria in IPv4 Soft Landing AFPUB-2026-v6-001-DRAFT02
15:15 - 16:05AfriNIC Policy Compliance Dashboard AFPUB-2026-GEN-002-DRAFT01
16:05 - 16:20TEA BREAK
16:20 - 16:35Policy Implementation Experience Report
16:35 - 16:55Policy Update from other regions
16:55 - 17:20PDWG Chair selection
17:20 - 17:35Q&A and Open Microphone
17:35 - 17:40Closing of PPM
17:40 - 17:50ASO-AC election – Results
17:50 - 17:55Closing Remarks of the Day

Dr. Vincent Ngundi elaborated on the guidelines for participation, specifically highlighting the AFRINIC Code of Conduct. Participants in the Public Policy Meetings are expected to adhere to established standards of conduct, which include maintaining a professional and respectful demeanor at all times. All attendees must act in the best interest of AFRINIC. Furthermore, they are required to respect the agenda and ensure that their remarks remain strictly on topic during the relevant portions of the meeting. This measure is critical in light of previous occurrences. Consequently, any form of harassment, intimidation, or offensive behavior will not be tolerated. The complete AFRINIC Code of Conduct is accessible on the official AFRINIC website.

How do you participate in the PPM?

A dedicated Question and Answer (Q&A) session will be conducted, accommodating both online and on-site participants.

Participants are encouraged to utilise the Q&A window on the Zoom conference platform, which will be continuously monitored. Additionally, contributions can be made by subscribing to the RPD@afrinic.net mailing list.

Attendees are also encouraged to consult the RPD archives to review previous discussions.

Upon being granted the floor, participants must first introduce themselves by clearly stating their name and affiliation.

Strict adherence to timekeeping is requested, with individual remarks limited to a maximum of two minutes, though restricting comments to one minute is preferred. All interventions should remain reasonably concise.

To accommodate the diverse linguistic background of African participants and facilitate accurate translation, speakers are requested to articulate slowly and clearly.

In alignment with the principles of multistakeholderism, any position taken in support of or opposition to a policy proposal must be accompanied by an objective rationale rather than a simple statement of dissent or approval.

In the event that microphones are closed prior to an attendee having the opportunity to speak, comments may be submitted via the Zoom teleconference chat or the RPD mailing list, both of which will be monitored throughout the sessions.

Darwin da Costa then proceeded to the introduction of the first policy proposal under discussion on the agenda..

1. Proposal #1: Soft Landing, Recovered Space and Priority

1.1. PDWG Chair Introduction & Discussion Flow

Summary of Discussion Flow:

  • Presentation of the policy proposal by the author (10 minutes).
  • Presentation by the Secretariat on the staff impact assessment (10 minutes).
  • Presentation on contentious areas by the co-chairs (5 minutes).
  • Open mic discussions by the PDWG and a Q&A session (20 minutes), with a reminder for participants to state their name and affiliation and keep questions on-topic.
  • Announcement of the co-chairs' decision following a 5-minute break with the PLT to determine if the proposal is approved or returned to the RPD mailing list.

1.2. Author’s Presentation

  • Context for Proposal: The policy was developed in response to staff assessments following the recovery of 3 million IPv4 addresses after the transition to the "soft landing" phase. Staff have also provided forecasting information as to how much time it will take for these IP addresses to be delegated to SPs and End Users.
  • Irreversibility of Soft Landing: The proposal clarifies that the soft landing state is irreversible; any recovered resources(irrespective of its original pool) will return to the general "available space" pool and AFRINIC will remain in softlanding state.
  • Policy Prioritisation: It establishes that in the event of any discrepancies or conflicts within the Consolidated Policy Manual (CPM), the soft landing policy will take precedence.
  • Consistent Address Flow: The proposal permits the reserved /12 block to be refilled with recovered addresses (even those in a quarantine period), ensuring a more consistent flow for entities requesting addresses.
  • CPM Cleanup: Superseded sections are to be removed from the CPM to enhance clarity and prevent potential misinterpretation by readers.
  • Alignment of Timings: Policy-related timelines are being adjusted from 12 months to 8 months to align with the existing soft landing framework.
  • Future Flexibility: The author noted that this proposal offers immediate clarity but does not preclude future modifications if address recovery levels or circumstances change.

1.3. Staff Impact Assessment

Brice Abba , staff presented the impact assessment.

Objective of the Exercise: The impact assessment exercise enables AFRINIC staff to provide comprehensive feedback regarding the proposed policy and to guide the community through its various aspects, detailing how it will impact AFRINIC operations.

Staff Interpretation and Understanding of the Proposal: The policy proposal outlines a structured approach for managing recovered space by ensuring it is cleaned and returned to the available pool, where resources can be delegated under prevailing soft landing policy rules. It explicitly acknowledges that the phases of the soft landing policy are irreversible; consequently, no phase one conditions can be applied during phase two. The current phase conditions apply to all available IPv4 spaces, spaces reserved for future use as per the policy statement, and recovered spaces, unless an alternative policy is officially adopted.

In practice, AFRINIC shall maintain a 12-month quarantine period for its recovered pool, with the flexibility to adjust this duration to six months if necessary. Once cleaned, these addresses will be transferred to the available pool. In the event that AFRINIC is unable to satisfy requests from the available pool, the reserved /12 prefix will be brought into active availability.

Furthermore, the proposal introduces positive refinements by removing obsolete sections from the Consolidated Policy Manual (CPM)—specifically Sections 5.5.1.2.1, 5.5.1.4.1, and 5.6.3—thereby addressing major pain points within the current framework. These pre-soft landing sections directly conflicted with key provisions in the soft landing framework, particularly Section 5.4.3.2 and Section 5.4.6.1. Additionally, the proposal corrects the projected period of need from 12 months to 8 months in Sections 5.5.1.9 and 5.5.1.13.3.2 of the CPM. In any case where another condition conflicts with the soft landing framework, the soft landing section shall take precedence.

Benefits and Impact Analysis:

  • Benefit to AFRINIC: The policy effectively resolves the ambiguity surrounding the management of recovered space.
  • Impact on Resource Members: The readability of the CPM will be significantly improved through the elimination of conflicting sections.
  • Clarity of Policy Text: No issues identified.
  • Areas of Impact:
  • Interaction with the Existing CPM: Interaction with CPM Section 5.4.7.2 shall invalidate the preserved states of the prefix and make it available.
  • Interaction with Other DPPs Under Discussion: The removal of Sections 5.5.1.2.1, 5.5.1.4.1, and 5.6.3 facilitates smoother integration with other active policy proposals.
  • Impact on IP Number Registry System: None.
  • Member Service Operation Procedures: The policy introduces an automated cleanup monitoring tool, alongside necessary updates to web content, communication materials, and overall website documentation.
  • Organisational Resources: Existing systems will be utilised for IT, and current internal skill sets are sufficient for HR and Finance. No legal issues have been identified.

Recommendations and Implementation Plan:

  • Recommendations on Policy Wording: None.
  • Staff Clarification Requests: None.
  • Implementation Plan: AFRINIC will require system enhancements to implement an automatic workflow, which will improve the monitoring and cleanup procedures.

1.4. PDWG Chairs Summary of the discussions on the proposal

  • There have been no objections or concerns on the rpd mailing list on this draft
  • The first draft of the proposal has been supported on the RPD mailing list. The link was shared and the archives on this policy proposal can also be consulted.

Darwin da Costa then opened the discussion on two fundamental points : - i) to those who want clarifications on the proposal from the author or on the impact assessment presented by Staff. ii) to those who oppose the proposal to provide a clear justification.

He also reminded that consensus is not the number of people that say yes, but these are the ones who have a fundamental justification for ratification of any proposal which has been discussed.in the mailing list or during the physical PPMs.

1.5. Open Microphone Discussion

Andrew Alston, internet consultant commented as follows :-

i) A fixed quarantine period may be insufficient, as recovered address space might still be announced in the Default Free Zone (DFC).

ii) Quarantine periods should remain extensible until the space is verified as cleaned

iii) Staff should conduct comprehensive checks on recovered space to identify and resolve issues such as blacklisting or previous spam history.

iv) The criteria and methodologies for recovering and cleaning up address space must be fully documented and transparently published.

v) The absence of open and verifiable address recovery processes poses potential legal risks for the organisation.

vi) On the matter of how utilisation is measured, he stated that the minimum space that can be routed is a /24 , but only 6 addresses may be needed at a datacenter. If a /24 is announced, then that /24 is then fully utilised.

He then said that he had no objection to the policy in principle, but believed those 2 issues really do need addressing before we move ahead.

Jordi Palet Martinez responded as follows ➖

In the first version of the proposal, six months of quarantine were being contemplated. The staff suggested that this is too short. So in version two, we changed this to 12 months, but in addition, I added a sentence that says that Afrinic may reduce the quarantine period, for example when available space is below 13, or other operational reasons. Then regarding the utilisation, utilisation is something that we use along all the CPM. So I don't think this proposal should resolve what is utilisations. If we need to define utilisation better.than what is already defined in the policy manual, I think that deserves a specific policy proposal. Thank you.

Andrew Alston further clarified that he had an issue with the fact that the quarantine period was set to a maximum of 12 months.The quarantine period of 12 months. Madhvi Gokool, staff, mentioned that the quarantine period of 12 months has worked until now and that resources unless they have been been cleaned up , are not pushed to the available pool.The cleanliness of the address space is prioritised over the quarantine period. AFRINIC has also taken note of your request for transparency in regard to the cleanup process and will work on it. Utilisation at the moment is already coded on myafrinic as the IPv4 allocation policy has been implemented since 2005-2006, so the utilisation counts the registration of the assignments for the allocations at the moment. Exceptionally, in the case of the assigned anycast policy, a /24 prefix is counted as fully utilised.

Herve Clement from Orange mentioned that he was very happy that the PDP has been relaunched, and so till now, the discussion within the mailing list has been very constructive and respectful. He support the principles of the policy proposal . He stated that the implementation issues raised by Andrew are very interesting.Furthermore, it is noted that these implementation considerations could encompass a broader scope that extends beyond this individual policy alone.

Paul Hjul from Crystal Web mentioned that he supports the policy but has two areas of concern ➖

i) that the utilisation needs to be defined and be found in an adopted policy. This isn't the policy that should define utilisation. This policy should make reference to a utilisation policy, you know, another policy that defines utilisation.

ii) With regards to the quarantine period, in his view, if address space has been properly recovered and so on, 12 months is too long a quarantine period. Three months would be an adequate quarantine period. The problem is that a proper definition of final recovery is required. He proposed that if the policy were to be amended, wording to the effect of, finally recovered in accordance with policy be inserted and thus a policy proposal is required and until this policy is adopted, any address space will not be recovered.

He is supportive of the policy, but at this juncture without there being an amendment to ensure that utilisation is governed by a policy that is adopted, and that what is deemed final recovery is governed by an open and transparent policy that is duly adopted. He thinks it's easy to make those amendments if the rest of the community is supportive of that approach.

Author Jordi Palet Martinez: reemphasised that in his understanding, staff already has procedures for declaring a space recovered and then for the quarantine and they already have rules for the utilisation calculation. He also stated that in the event that consensus is not reached on this proposal, the problem raised above while being somehow isolated from the proposal will still exist and the problems that this proposal is trying to resolve will still remain. Or, consensus can be reached on the proposal and in parallel the staff is asked to provide a clear explanation of those two situations, the quarantine and utilisation. And if we believe that the operational measures that the staff has right now are not according to the community beliefs, two new policy proposals for each of these topics can be submitted.

James Chirwa, Head of Member Services at AFRINIC mentioned that he has seen a few concerns raised regarding the recovery of the space, but he can assure the community that the process that is in place ensures that a proper cleanup of the resources is done before they are made available and reissued. Feedback was provided on the initial proposals in that 6 months quarantine period will bring in constraints regarding the space that mostly is being used. It will not give us enough time to make sure that AFRINIC either recovers that space, gets the member to comply AFRINIC can publish the recovery procedure properly and the community will have full visibility of how it is being conducted

Seun Ojedeji stated that the policy proposal should not be punished because the point of utilisation is not actually a new thing. While the author has just basically used existing word utilisation, there's no reason to say that Because utilisation is not defined, then the policy should not pass. On the first issue with regards to six months and 12 months, staff has actually confirmed that 12 months is fine for them.

He supports the policy as written and staff can deal with the operational aspect of it and probably should publish the process that they're using to determine utilisation and whether the v4 space is to be quarantined or not. Andrew Alston stated that he completely agrees and thanks the staff that they have policies and procedures.However, he would like to see those policies and procedures incorporated into the CPM by community consensus to do this because How space is recovered, et cetera, is a very important issue for this community. He also proposed that if the staff have got these things, that they bring forward a policy proposal that is ratified by this PDP to preserve the transparency and the bottom-up approach. And once we have that in the CPM. This policy will become a lot — it will remove a lot of ambiguity for me. And to me, the removal of ambiguity in everything that we do and the transparent nature of it.

A participant intervened to say that she supports the policy and recommends definitions to remove ambiguities. She also support the 12 months quarantine for the numbers

Gregoire Ehoumi, Independent Consultant indicated that he had some concerns about the proposal. it says the soft landing is irreversible which seems premature. The author said that it can be changed if needed later, but it's creating some issues for the future.

His second concern is about the slash 12 that is the reserved block. The slash 12 can be refilled with quarantine addresses effectively bypassing the quarantine period. So this undermines the quarantine policy intent and eliminates the strategy that was put for the slash 12.

He also mentioned that there is another proposal that has been posted on the mailing list, which adds another period for cooling, like pre-soft landing period, that will resolve most of the issues that have been raised today.

The author Jordi Palet clarified that by irreversible, he means in the current state. The second point about the slash 12, which is the quarantine, basically what it means is that even if we need to use the existing addresses in the slash 12, but there are addresses under quarantine period. Shifting those addresses allows the flow of allocations and assignments to be more fluid. Of course, if we reach the point that in the slash 12, there are addresses that are quarantined, we need to wait until they are clear. That's obvious.

Abdulkarim Oloyede mentioned that the policy has some aspect which needs to be considered, He totally agree that the process in which the staff wants to put in place needs to be: quite clear, and that needs to also go into this policy, and thinks once that is done, then we can look at this again. So, just to be very clear, thank you.

1.6. PDWG Chairs Decision

  • After considering the discussions in the RPD mailing list and the current PPM, the authors having addressed the concerns raised by the PDWG, the co-chairs have determined that rough consensus has been reached.
  • Secretariat is requested to publish a clear recovered space cleanup procedure and definition of the utilisation during the last call. So please engage further during the last call.

2. Proposal #2: PDP Working Group (WG) Guidelines and Procedures

2.1. PDWG Chair Introduction & Discussion Flow

Dr. Vincent Ngundi introduced the second policy proposal on the agenda - the PDP Working Group Guidelines and Procedures that was drafted by three authors. Discussions are ongoing on the RPD mailing list, but the authors have indicated that this proposal is not ready to seek consensus. They have requested for extra time to present the concepts and the policy details.

Alain Aina , who is one of the authors of the policy proposal will present the thinking behind the draft policy proposal.

2.2. Author’s Presentation

Alain Aina informed the PDWG that the co-authors simply sought an opportunity to present the concept to the community and gather their feedback, acknowledging that the issues being addressed are quite complex.

The current PDP, adopted in 2010, utilises a working group framework and mandates that policy development occur through this group. Consequently, any established working group requires its own operating procedures and guidelines to define its functions. Since the group is tasked with executing specific work, it must determine how to properly organise its operational activities and the PDP we had from 2010 didn't really explicitly define.

The online PDP originally established a minimum baseline to allow community adjustments, but this has led to conflicting interpretations. Since unwritten rules and best practices are frequently rejected under strict policy interpretations, we are now trying to elaborate on the minimum guidelines and procedures for our working group.

Efforts to amend the PDP began in 2017 but failed multiple times due to resistance. The latest attempt started in July 2020 and went through several versions, but faced difficulties due to a competing policy. Although it reached the last call, the resulting conflict required the two groups to come together and propose a single, unified policy.

However, this never happened because everything was frozen. Now that the PDP has reopened, we are bringing the proposal forward with some amendments. Since June 2022, the AFRINIC Limited governance crisis has exposed vulnerabilities that impacted the entire community.

Policy discussions halted entirely because community activities depended heavily on the board, making it a single point of failure with no continuity mechanism.

In the current framework, policy development sits within the governance structure where members elect directors, and the Policy Development Working Group—comprising members, resource members, and the community—is led by two co-chairs. The process relies heavily on the Board, such as for appointing the appeal committee, recall committee, an ASO-AC representative, calls PPM, and makes a policy in case of an emergency. This new proposal has evolved beyond just establishing working group rules to address risk management and make the PDP more resilient.

The objectives are to clarify procedures for electing co-chairs and advancing discussions, strengthen community oversight, and reduce Board dependence. It introduces a mechanism for when the community adopts a policy but the Board cannot ratify it due to litigation, lack of quorum, or operational dysfunction.

Most importantly, the proposal aligns the PDP with the new ICP 2 requirements to fulfill ongoing RIR obligations and prevent potential de-recognition.

And the Board cannot ratify because the Board has no quorum, Board is in litigation, Board is not functional. So what do we do? We added something like that. And also, most importantly, we also are trying to align our PDP with the new ICP 2.

Aligning our PDP with the new ICP-2 requirements is critical to avoid RIR de-recognition. We must ensure the continuity of policy development regardless of organisational status, as community members' networks remain operational and require ongoing support.

We are not seeking consensus today due to the proposal's contentious nature. Contrary to concerns, we are not transferring board power to the community or attempting to bypass staff or governance structures. We are not creating any parallel governance. But this is what we've been hearing.

This proposal identifies two key governance changes: allowing an alternative entity to convene policy meetings if the Board is unavailable, and reviewing NRO NC election processes to establish a Regional Number Council . The proposal aims to reduce procedural dependency on the Board without altering its core governance powers. It suggests that community representatives and co-chairs—rather than the Board—convene Public Policy Meetings (PPMs) and appoint appeal and recall committees. This creates an automated mechanism for committee formation, ensuring continuity without encroaching on the Board's authority to ratify policy.

The proposal retains core Board functions, such as policy ratification and ASO AC appointments, while fostering community self-organisation in alignment with ICP-2 guidelines. It introduces a petition-based ratification mechanism, allowing the working group to finalise policies if the Board remains unable to act after 10 days.

The proposal introduces a petition-based ratification mechanism. If the Board is unable to act, Working Group members can initiate a petition supported by 15 members across at least three regions. Upon reaching this threshold, staff review the policy and ratify it if no issues are identified.

Regarding concerns about reducing Board power, the author clarified that the proposal only provides a mechanism to act when the Board is non-functional, rather than stripping power from an existing Board. Additionally, to resolve ambiguity in co-chair selection—where 'show of hands' is often contested—the proposal advocates for a clear, consensus-based selection process rather than voting. making decisions by consensus should be able to select co-chairs by consensus instead of voting..

The author proposed moving from a voting-based co-chair selection to a consensus-based process to improve accuracy. The PDWG should evaluate the merit of the candidate and decide by consensus. In cases of tight consensus, a lottery would decide. In the event that there is no consensus and co-chairs are needed, the Regional Number Council shall appoint one in interim capacity to guarantee continuity. The proposal also updates the model for NRO-NC representation, requiring Resource members as well as those individuals registered from this region who have attended one policy meeting before and in physical attendance of the meeting, to vote.

Furthermore, it outlines an automated mechanism for committee formation, such as appeal and recall committees, to ensure continuity and avoid over-reliance on the Board. The three ASO-AC representatives and 2 PDWG Chairs form the Regional Number Council

two community representatives of the ASO-AC and immediate past co-chair to form the appeal committee. The latter will exist before the appeal occurred

In regard to the Recall , criteria is being introduced to strengthen it. 10 different organisations that must be subscribed on the mailing list for more than at least one year and Must have attended some meeting before they can support a request to recall.

Gregoire Ehoumi mentioned that they have cleared most of the comments seen in the list and the area that we have found to amend in the bylaw, is already in a good timeline Because right now the bylaw review is ongoing and this proposal must represent the community view.re not seeking consensus on this draft policy proposal.

2.3. Open Microphone Discussion

Vincent Ngundi then directed the PDWG to the website for the staff impact assessment because the proposal is going back to the RPD mailing list.

Jordi Palet Martinez from the IPv6 Company clarified it's true that there were two competing proposals in the past that both reached consensus. The Chairs suggested that we should work together but that has not been conclusive despite im trying many times.

He agrees with most of the interactions that happened on the list regarding this proposal. He thinks it's fine we keep discussing the modification of the PDP, but also believes that because we are engaged in a modification of the bylaws and there are a lot of interactions with the PDP. He thinks we should halt trying to reach consensus on any PDP modification until the bylaws are clarified.

Keeping the discussion in the list.probably can also influence the bylaws modification.

Saul Stein from eNetworks stated that there are no two different organisations AFRINIC is AFRINIC, whether it's AFRINIC Limited or the members, we're the same organisation. We vote as AFRINIC members, we vote for the board. That's something very important to remember in some of your other points. As the community, we all come together to support AFRINIC. He observed that trying to push the proposal for so long may indicate that something is being missed and to wait for the bylaws to be cleaned up and then see what’s controversial and clean up in smaller steps. He suggested that :-

  • the not too controversial elements of the proposal could be looked at .
  • Operational processes should not be confused with policy Policy is not easy to change. Operational processes are very easy to change. It’s best to avoid putting something in policy that should be operational.
  • The community can't work in isolation.The community has no fiduciary duty for the company. If you make policies or you pass something that the board is accountable and responsible for. The board has to approve things. The company, AFRINIC has to have the final say, or not necessarily the final say, but have a say in the process. Does this make financial sense for me? Am I going to, am I as the CEO or director? going to go to jail for this policy. So, you've got to be careful about what you're trying to solve. You're trying to solve a whole bunch of processes which actually aren't for us to solve.

As an ASO member, he reflected that ➖

Many points that have been raised and are trying to be solved are actually in the new ICP2 document. He suggested waiting for all the processes to finish; to attend the ICP 2 update on the next day and to consult the draft document online. Under the new document, audits can be requested in the event things are not being done properly; an appeal process that you can actually submit as a group, as you can get a collective together and submit for an order to be done as to why that policy wasn't ratified.

He cautioned on asking the ASO-AC representatives what to do, and what their responsibilities, and also the time that they're giving. I think that might change the requirement of and the character that you're going to get for the ASO-AC responsibilities.

Lastly he suggested a review of the document so that it is structured in a methodological method to help in the readability of the document.

Abdulkarim Oloyede University of Illorin Speaking in his personal capacity thanked the co-authors of this proposal and said that the intention of this proposal is a valid one and are good. This proposal needs to be given some attention, because there are issues that have to be resolved. He thinks we have moved away from those days that if something is not broken, you don't need to be fixed.

there are some aspects that needs to still be worked on :- i) how to select the co-chair - there should be some requirements, basic requirements as to who and who can qualify to be the co-chair of the working group. He likes Alain's suggestion of probably having a ballot. Just have their names in a box, and somebody picks one, two, as long as they meet some certain pre-requirements that will be defined first of all. This would solve the problem of subjectivity. And those requirements needs to be clear and it needs to be something that can be evaluated and everybody will be sure And if you have more than the required number meeting that requirement, then a ballot in that manner would probably be required.

ii) On the issue of the requirements, one of the things that was mentioned is to have attended a number of PPMs. He agrees that co-chairs do not really need to be somebody new, and at the same time, it has to be somebody that has the experience. But physical attendees at PPMs might be an inconvenience for some people, and that should not be probably one of the requirements.

iii. Abdulkarim Oloyede supports limiting certain Board powers while emphasising that the Board must retain final authority over policy ratification. He argues that removing Board oversight entirely is impractical, noting that while the proposal's intent is valid, achieving complete independence from the Board is unrealistic.

iv)

  • More careful planning is required before establishing committees such as the recall committee.
  • The current proposal for committee organisation requires further refinement to be effective.
  • The framework in the proposal is currently too subjective, which may undermine the thoroughness of the committee's work.
  • There is concern that the current process, if left as is, could lead to destructive rather than constructive outcomes.
  • While these issues are fixable, the proposal needs additional time and structured attention to ensure the procedures are correctly fixed.

Dr Vincent Ngundi thanked Mr. Abdul Karim and requested him to please document his inputs on the RPD mailing list.

  • Daniel Khauka Nanghaka raised questions regarding the policy proposal's potential impact on the Governance Committee (GovCom).
  • He noted that limiting Board powers might reduce the volume of requests submitted to the GovCom, thereby affecting its operational workflow.
  • He requested clarification on how these procedural changes would specifically influence the committee’s standard operations.
  • Concerns were highlighted regarding potential unintended effects on the ratification of Policy Development Process (PDP) amendments or bylaws.
  • He emphasised that given the GovCom's remit for bylaw oversight, the proposed restructuring could have significant direct or indirect implications.

Paul Hjul from Crystal Web noted that keeping the proposal in a state of limbo is problematic as it allows unresolved issues to persist across meetings, and urged the authors to prioritise addressing the fundamental concerns raised. He also highlighted that PDP co-chairs lack the fiduciary responsibilities inherent to Board members, meaning that creating structures to circumvent the Board creates an untenable governance situation due to the lack of fiduciary accountability.

Paul Hjul emphasised that the lack of a functional board iindicates other massive problems that should be addressed by the bylaws committee. He cautioned against attempting to use the PDP to circumvent corporate and board structures, Instead, he urged the authors to align their proposals with good governance principles, the ICP-2 requirements, and ongoing bylaws committee initiatives to ensure long-term stability rather than short-term workarounds.

Alain Aina maintained that the proposal does not affect how the governance committee and the board and the Afrinic staff work. The current PDP does not give any role to the Governance Committee. He denied the creation of parallel governance and maintained that the Board remains the Board, with its own power.

  • Alain Aina reiterated that the proposal does not strip the Board of its core powers, including policy ratification and appointments, nor does it create parallel governance.
  • He highlighted the registry's operational continuity during past governance crises—where essential services remained functional despite the absence of a Board and CEO , but had any issue arise, the community would not have been able to provide a policy. —as evidence for why a community-driven mechanism is necessary for ongoing policy development.
  • He acknowledged concerns regarding the readability of policy texts on the website and confirmed he has shared a Google Doc format for easier access.
  • He Clarified that the proposal is not a rejection of previous work but rather a synthesis of lessons learned from the 2020 process, aiming to resolve ambiguity and provide a resilient framework for the future.
  • He emphasised that the proposal serves as an avenue for the community to provide input as to where the bylaws news=ds to be amended, aligning with the bottom-up, community-driven nature of the organisation as defined by ICP-2.

2.4. PDWG Chairs decision

Dr. Vincent Ngundi concluded by noting that the proposal will return to the RPD mailing list for further discussion. He urged community members to review the proposal’s problem statement, emphasising its importance in creating a resilient and futuristic policy framework following recent challenges.

3. Proposal#3: Amendment of utilisation in soft landing

3.1. PDWG Chair Introduction & Discussion Flow

Darwin da Costa commended the community for the constructive discussion surrounding the previous policy proposal. He noted that even without reaching consensus, the process was valuable, providing a model for future community-led, bottom-up discussions, and then transitioned the meeting to the next agenda item.

The third proposal is titled Amendment of Utilisation in soft landing and the first version was submitted on 6th May 2026 and then on 16th of June, the second version came up

3.2. Author’s Presentation

Jordi Palet Martinez , the author of the proposal started his presentation by saying that this proposal is also trying to fix some of the sharings of the staff about concerns of policy implementation the pier

  • The current 90% utilisation threshold hinders organisations that need to deploy resources across multiple sites simultaneously (e.g., for redundancy and high availability).
  • It is often impossible for organisations to reach the 90% threshold when spreading resources across various network points, even when those allocations are necessary.
  • Best Current Practices (BCP) generally prevent the announcement of prefixes smaller than /24, further complicating efficient address management.
  • The rigid utilisation rules create unnecessary operational bottlenecks, inadvertently slowing down IPv6 transitions and not just running multiple IPv4 only data centers
  • The proposal seeks to modify the utilisation criteria to permit simultaneous multi-site allocations, allowing for more flexible and efficient network operations.
  • Modification of Section 5.4.6.1: The proposal updates Section 5.4.6.1 to allow for the simultaneous request of multiple IPv4 allocations or assignments.
  • Removal of Utilisation Bottlenecks in certain cases: It eliminates the current requirement to demonstrate 90% utilisation of an initial allocation before a member can request additional resources
  • Impact on IPv4 Longevity: The author emphasises that increasing the delegation of recovered IPv4 addresses will not significantly shorten the lifespan of the existing IPv4 pool.
  • Operational Flexibility: This change allows organisations to deploy resources across multiple sites in parallel, rather than being restricted to single-site utilisation.
  • Jordi Palet Martinez explained that in other regions where IPv4 exhaustion is complete, members manage resources through transfer policies that allow for simultaneous, multi-site allocations without prior single-site utilisation requirements

3.3. Staff Impact Assessment

Brice Abba, staff presented the impact assessment on this policy proposal as follows :-

  • He shared the QR code to the full impact assessment that is published on the AFRINIC website.
  • The 90% threshold requirement remains the condition for receiving additional IPv4 resources, though technical constraints may allow for overrides. Operational constraints do not justify overriding this requirement.
  • The policy provides clear guidance for staff when managing these cases, and members can utilise the policy when facing documented technical constraints despite not meeting the 90% utilisation threshold.
  • The proposal improves the Consolidated Policy Manual (CPM) by updating Section 5.4.6.1. There are no identified overlaps with other policy proposals or impacts on the IP number registry system.
  • Member service procedures will be updated to include these provisions and monitor for abusive use. No impact is expected on website, communication, HR, legal, or finance departments.
  • The implementation plan allows for the policy to be enacted within the six-month CPM timeframe, ideally within 30 days of ratification.

3.4. PDWG Chairs Summary of the discussions on the proposal

Darwin da Costa, PDWG co-Chair mentioned that the version 1 of the proposal received support on the RPD mailing list . Links to the archived discussions were also provided to guide the PDWG. There have been some suggestions to amend the policy text which were taken into consideration and then no further discussion once the draft two of the proposal arrived on 16 of June 2026. There were no objections and concerns related to draft 2.

3.5. Open Microphone Discussion

Christian from KT Rwanda Network stated that since the policy language was new to him, he had a question related to operations, noting that some projects are time-sensitive. He wondered if the process of assessing whether 90% of the previously allocated space has been used could be completed within a very short timeline to avoid hindering a member's project. He emphasised that members often need these addresses quickly to proceed smoothly and requested clarification on the timeframe required for this assessment. Jordi Palet Martinez explained that the current proposal aims to resolve bottlenecks for projects requiring simultaneous multi-site resource deployment (e.g., for redundancy or high availability). The 90% utilisation requirement for standard single-site allocations remains unchanged. The proposal provides an exception for multi-site projects, allowing for parallel allocations without needing to wait for the 90% utilisation threshold to be met on an initial allocation.

James Chirwa, AFRINIC's Head of Member Services, addressed the discussion regarding the speed of the 90% utilisation assessment process for IPv4 allocations. He noted that:

  • For cases involving operational constraints, staff will work directly with members to assist them in achieving the 90% utilisation threshold as efficiently as possible.
  • To accelerate the process, members must provide comprehensive information and clear requirements upfront, allowing staff to quickly verify the 90% utilisation threshold.
  • Process Efficiency: The review process is fundamentally an "input/output" operation; the speed of the assessment depends heavily on the quality and completeness of the documentation submitted by the member.

Lexa Mpua from Malawi Research and Education Network Resource member mentioned that she is in full support of the proposal. She requested clarification on the technical documentation that will be required to be shared with the team in case more assignments are needed for different sites and the member has not yet reached the 90% utilisation threshold.

The author (Jordi Palet Martinez) explained that the proposal requires requests to be "sufficiently documented" for AFRINIC staff to verify compliance. There is no single list of required documents, as needs will vary by case (e.g., IPv6 transition or multi-site deployment). The process is described as an "input/output" dialogue where staff evaluate each case individually to ensure justifications are demonstrated and verified

Ade Omololu from Mainone Nigeria mentioned he is in support of the policy but worries that the current policy language is too broad, potentially allowing any member to request additional IPv4 space by simply claiming a need for high availability or redundancy. He argued that without tighter conditions, the policy will be difficult for AFRINIC staff to implement fairly and consistently.

Jordi Palet Martinez, the author argued against adding overly specific text or listing every potential example of "sufficient documentation," as this could inadvertently exclude legitimate cases and "micromanage" AFRINIC staff in their duties.

He noted that the requirement for requests to be "sufficiently documented" provides the necessary safeguard for staff to verify the validity of each request, a process already supported by staff's existing impact assessment.

He emphasises that 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.

James Chirwa, Head of Member Services emphasised the need to clearly differentiate between "technical constraints" (which warrant policy application) and "operational constraints" (which do not) to prevent abuse of the policy.

Andrew Alston argued that the underlying issue is the lack of a clear, objective definition for "utilisation" within the Policy Development Process (PDP). He noted that this subjectivity is not the fault of the staff but a structural issue that leads to inconsistent application of policy and potential frustration for applicants. Jordi Palet Martinez responded that the same problem exists in all registries because it's almost impossible to find a definition which match all the cases. He further stated that the utilisation issue can be fixed with a clear definition in the manual. It’s a separate problem as it also affects many other sections of the manual.

Andrew Alston proposes a "conditional consensus" mechanism to resolve policy ambiguity during development:

  • He suggests that a policy could achieve community consensus while making its implementation contingent upon the successful adoption of a separate, related policy.
  • He draws a parallel to "normative references" used in IETF protocol standards, where one standard is dependent on the formal completion of another.
  • This model would allow the community to move forward with a proposal they support, while ensuring that critical, unresolved issues—such as the lack of a formal definition for "utilisation"—are addressed in a subsequent, properly defined policy, thereby preventing ambiguity without stalling the entire process.

Jordi Palet Martinez then suggested that Andrew Alston work on submitting a proposal on utilisation and offered to be co-author if need be.

Seun Ojedeji emphasised that the current PDP does not provide a mechanism for conditional policy adoption; policies must either be passed as-is or rejected entirely.

He argued that the definition of "utilisation" is a broader structural issue, not specific to this policy proposal, and should not be used as a condition for it to pass.

While he supports the current policy draft, he suggests that AFRINIC staff could improve the process by publishing high-level operational explanations of how they currently assess utilisation, which would help mitigate ambiguity without stalling the policy's progress.

Andrew Alston challenged the assertion that the Policy Development Process (PDP) cannot accommodate a "conditional pass" mechanism, arguing that the PDP should evolve to meet community needs. Seun Ojedeji clarified that he does not oppose the PDP's evolution, but simply noted that the current rules do not permit conditional policy adoption. A new policy proposal is required for this change. The misunderstanding was resolved.

3.6. PDWG Chairs decision

The two PDP co-chairs deliberated and Darwin da Costa stated the outcome as follows :-

So having considered the discussions of the RPD mailing list and the current PPM the authors have addressed the concerns raised by the PDWG, the co-chairs have determined that rough consensus has been reached. The Secretariat will share the definition of utilisation during the Last Call.

4. Proposal#4 Hierarchical Names for New AS-SETs

4.1. PDWG Chair Introduction & Discussion Flow

Dr. Vincent Ngundi introduced the next proposal that requires newly created AS-SETs to have hierarchical names. Since the author was indisposed, the PDWG co-chairs decided that the Secretariat could just give an overview in the Public Policy Meeting. Consequently, the feedback from the Community on the proposal would be received and then the PDWG Chairs will make a decision on how to progress.

4.2. Author’s Presentation[Read by staff in absence of author]

Madhvi Gokool , staff presented the proposal from the author James Bensley. The problem statement of the proposal highlights that AS-SET names are not unique across the five RIR databases, meaning the same name can exist across multiple registries. When an AS-SET is created, a database only checks for uniqueness within itself and cannot verify other databases, leading to name collisions. If a name is not unique, the wrong AS-SET may be used either accidentally or intentionally. Furthermore, flat names provide no clarity on which network an AS-SET belongs to, as nothing in a name like 'AS-FOO' indicates its related ASN. To address these issues, the proposed change adds a section to the policy manual requiring all newly created AS-SETs to use a hierarchical name as defined in RFC 2622, Section 5. Preceding the AS-SET name with an AS number ensures global uniqueness across all RIR databases and clearly identifies the associated network, effectively resolving both problems.

This proposal ensures global uniqueness of AS-SET names across all five RIR databases by requiring them to be hierarchical, as defined in RFC 2622, Section 5. By mandating that names begin with the holder's AS number (ASN) followed by a colon, the policy links the AS-SET directly to its associated network, effectively preventing naming collisions and "AS-SET squatting," where parties maliciously register ambiguous names. This approach resolves the current issue where databases only verify uniqueness locally, rather than globally, and provides clearer authorisation linkage between ASNs and their corresponding AS-SETs.

4.3. Staff Impact Assessment

Madhvi Gokool , staff provided the QR code to the impact assessment on the Afrinic website

  • Current AS-SET names are not unique across RIR databases, which leads to name collisions, ambiguity, and difficulty in resolving "AS-SET squatting." Because network operators do not own specific names, it is hard to prevent malicious or accidental reuse of names. So if AS-SET name squatting is carried out intentionally or maliciously the affected party has limited recourse to have the squatted asset removed particularly when it exists in a different RIR database.
  • The proposal mandates that all newly created AS-SETs in the AFRINIC database must use hierarchical names, as defined in RFC 2622, Section 5. This requires the name to begin with the holder's ASN followed by a colon (format: [ASN]:[AS-SET name]).
  • Enforcement is restricted to authoritative AFRINIC IRR creation workflows. Mirroring resolver behavior is out of scope.
  • Validation will occur server-side (via create forms or APIs).
  • The requirement applies only to newly created AS-SETs; there will be no retroactive cleanup or bulk migration of existing data.
  • Exceptions to the hierarchical naming rule may be granted when necessary, provided AFRINIC documents the reason.
  • Benefits:
  • Reduces the risk of global name collisions and squatting.
  • Creates a clearer authorisation link between an AS-SET and its associated network.
  • Aligns AFRINIC with other regional practices, improving ecosystem consistency.
  • Operational Impact:
  • Resource members will face a minor learning curve and may need to update automation tooling that assumes flat names.
  • The members may need guidance and examples to avoid creation failures
  • Existing non-hierarchical AS-SETs will remain valid and editable to minimise disruption.
  • Staff Observations:

There's one observation regarding the exception highlighted in section 7.8.6 in the policy text that could allow restoration of deleted objects; operational staff 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. Basically, we are meaning that you want us to fix something but then still allow a side door to remain open. But deletion of objects on the WHOIS database requires someone to actually authenticate against the maintainer, so they need to be sure that if they are deleting, that is the action they have to take.

Implementation will affect the WHOIS, RDAP, and Myafrinic portal/IRR interface systems.

Lastly, Madhvi Gokool mentioned that in regard to the implementation, the policy can be implemented as written and it would take us less than 6 months after the end of the last call. The CPM mandates that the implementation date should be less than 6 months after the end of the last call unless a waiver is requested. At present, all the AFRINIC human resources have been channeled to the MyAFRINIC V2 project which is expected to go live by the end of this year, and the implementation of this policy, if it gets ratified, will be prioritised once that implementation is concluded because we are limiting the amount of scope creep and we really need to get the V2 up.

4.4. PDWG Chairs Summary of the discussions on the Proposal

4.5. Open Microphone Discussion

The Q&A session was then opened so as to receive feedback from the Community , while acknowledging that the author was not present in the session.

Andrew Alston: I fully support the policy. I do think that the policy would be far more useful if it was globally done and globally aligned with other RIRs. To my knowledge, only RIPE at the moment is enforcing hierarchical AS-SETS. And this means that while this will clean up AFRINIC's own stuff, it does not stop somebody going and creating a duplicate AS-SET name in APNIC, LACNIC, or ARIN. And I think that it would be useful for this same policy to be put before all of the RIRs with a level of global coordination to make it a lot more useful. So yes, it does help some things, but to be more effective, it needs to be done with global coordination amongst all of the RIRs.

Seun Ojedeji, speaking on his personal behalf agreed with Andrew, and mentioned that his may be something that the NRO NC may be considering as a global policy if possible. But within the scope of AFRINIC, he supports this proposal.

However, he expressed a concern with the implementation constraint that was mentioned by staff, asking why, if this policy got ratified, it could not be part of the plan for AFRINIC version 2 that is expected to roll out in November.

Andrew Alston mentioned that a similar proposal was actually put before ARIN and it was rejected for being out of scope.

Sander Stefan from the RIPE NCC then clarified that it was rejected in the ARIN PDP because it was out of scope for their policy development process and referred to a different process. So the idea wasn't rejected. The way it was handled was rejected. But the RIPE NCC implemented it about 3 years ago and they have a similar policy.

Jordi Palet, The IPv6 Company.mentioned that he supports the policy.

He liked the wording provided by the staff and thinks that wording is not changing anything from the proposal. So probably in the last call, we can suggest if the author agrees to use that wording instead of the one provided by the author.

The second point, I want to respond to Seun: this cannot be implemented as a global policy because global policies are only related to interactions with IANA. So this cannot be a global policy unless we change the definition of global policy. .

4.6. PDWG Chairs decision

We are reconvening, and having considered the discussions in the RPD mailing list and the current PPM, the authors have addressed the concerns raised by the PDWG and the co-chairs have determined that rough consensus has been reached.

Now there are a few items and I think those can be handled during the last call. One of them being there are some comments on re-wording, but they don't change the meaning and the purpose of the policy proposal, an observation by staff, and then the resource constrained because of MyAFRINIC version two. I think those are things that we can discuss during the last call; they don't change the purpose or the objective of the policy proposal, and yet it's also a very important policy proposal for our service region. So rough consensus has been reached. The draft policy proposal moves to the last call.

5. Status of Ratified Policies

Presentation URL : PDF

Madhvi Gokool, AFRINIC staff presented on the status of the proposals that have already been ratified by the AFRINIC Board.

But, she first spoke about the myafrincv2 project which is the long awaited upgrade of myafrinic. Myafrinic is the primary interface for the AFRINIC Member Services staff and the members also use it to manage their resources and services. The current myafrinic has been operational for close to 20 years now and like a typical system at some point in time, it has become difficult to scale and lack certain workflows for modern usability and interoperability. So the development work on myafrinicv2 had in fact started in 2020, but we faced multi-year budgetary constraints as well as other resource constraints, which led to delays.

Last year, the project was revived and the development work is ongoing so that it can go live by the end of this year. In order to meet the deadline, we need to limit the scope to avoid scope creep. So this is what is happening at the moment.

The update regarding the ratified policies status are that we have brainstormed options as to whether they can be implemented on the other systems , e.g whois . But when the members update their resources on myafrinic, what will happen? We found that the business rules will break and more work will be created. he way the RIRs work, I mean, at some point in time, it touches the myafrinic portal.

The summary of the status of recently ratified policies:

  • RPKI ROAs for Unallocated and Unassigned AFRINIC Address Space
  • Implementation Status: The "RPKI ROAS for unallocated and assigned/unassigned AFRINIC address space" policy has been ratified but is not yet fully implemented.
  • Progress: While initial development faced delays, the implementation is currently undergoing internal testing using the evolved KRILL software.
  • Next Steps:
  • A beta release of this implementation is expected by the end of the month, though it will be announced as "partly implemented."
  • Full implementation as written in the policy text is dependent on the launch of MyAFRINIC V2, which is expected to go live by the end of this year.
  • Number Resources Transfer Policy:
  • This policy covers both intra-RIR (within AFRINIC) and inter-RIR transfers and has been confirmed as reciprocal with the other four RIRs as of April 2026.
  • Implementation is underway, with the Member Services team actively coordinating with counterparts at other RIRs to map the necessary procedures.
  • Technical system implementation will be prioritised following the deployment of MyAFRINIC V2.
  • Abuse Contact Policy Update:
  • This policy was ratified earlier this year.
  • Technical implementation on internal systems is scheduled to be prioritised after the MyAFRINIC v2 deployment is complete.

6. Policy Implementation Experience Report

The objective of the report is to provide feedback to members and the community regarding the practical experiences and challenges AFRINIC staff encounter while applying the implemented policies in their daily work.The feedback loop is essential because technological changes can impact existing policy sections. By sharing these experiences, staff aims to prompt the community to evaluate whether specific policies require updates or modifications. This presentation will mostly focus on Section 5.6.4 of the Consolidated Policy Manual, which talks about the PI assignments to critical infrastructure. In addition to that we'll also be looking conjunctively with section 11 of the CPM. section 5.6.4.1 has definitions for those two elements of critical infrastructure- internet exchange points and core DNS services. These are used when requests for IXPs are evaluated, alongside the other conditions defined in Section 11. The critical infrastructure definition has been in the policy manual for quite a while -it's been there for over 15 years. Section 11 of the CPM mandates AFRINIC to reserve a /16 IPv4 prefix for IXPs for peering purposes and another /16 IPv4 prefix for management purposes. When an organisation qualifies , they get resources from these reserved pools and at no cost.

Does the community consider that the current definition as per the CPM still caters for operations of IXPs .In the 15 years that have elapsed , here's been a lot of evolution in that space. This will help us to know that we are still aligned with the current practices of the internet exchange points. The policy details for 11.4 talks about the peering LAN. The peering LAN assignment for each IXP should ensure that the adjacent /24 IPv4 block is reserved to allow the IXP to grow , without having to renumber to a new contiguous growth. IXPs are growing faster than others and some have reached the threshold of /23. When

We request the community to look at the policy so that a clear wording in policy text that can also accommodate the growth of those fast growing IXPs.

Section 11 itself defines two sets of address pools that are reserved - one for peering and one for management. Members are swapping their prefixes - in clear nonconformance with the policy. We work with them to align but what we're trying to do here is to encourage members to stay within the parameters of how the resources are supposed to be used. Where it says peering members should ensure that the peering prefix is being used. Where it says management they should make sure they're using management prefixes.

The third element was on the core DNS service. The ICANN Managed Root server program that uses pre-defined L-root IP Number Resources. So practically operators already have their own infrastructure which they can actually use to help host the root servers. AFRINIC has received some requests recently that in practice wanted to fall under this policy set text but as hostmasters we find it different because the ICANN cluster comes with its own set of IPs and just need the hosting operator for routability. So unless the community thinks otherwise, we just wanted to bring this issue forward to the community.

Cedrick Mbeyet ,AFRINIC staff , commented that CCTLDs consider themselves as core DNS Providers and critical infrastructure but the CPM does not consider them as such. Paul Hjul commented whether the /16 reserved prefix was sufficient for the entire continent and if a /15 would not have been a more suitable reservation. James Chirwa responded that it’s up to the community to ponder on this issue. Staff would provide the statistics of how the consumption has been since that policy was ratified and then it can give a better picture to the community on how they can deliberate on that.

Andrew Owens from NAPafrica mentioned that they are in a potentially different position in terms of the numbers. So just in Johannesburg for example, NAPafrica has two /23s already. Now the problem they face is planning for that is incredibly difficult because he is running close to a /22 full utilisation, which means that if they need more space now, an additional 2 x /23 will be needed to get to a /21. This means that AFRINIC is going to have to predict from a very early point how many contiguous blocks it will keep for for each internet exchange point.

Andrew Owens of NAPafrica highlighted the immense difficulty of renumbering Internet Exchange Points (IXPs). He explained that renumbering NAPafrica's Johannesburg deployment started eight years ago and is still not complete. He hopes that Napafrica can get a reserved 2 /23s. He emphasised that current IP allocation and growth planning are challenging, as moving to new address space requires a multi-year renumbering process. He urged the community to consider how to better support fast-growing IXPs to avoid future renumbering and operational disruptions.

James Chirwa concluded that the community has heard from the operators of the critical infrastructure as to the challenges they face and can now look at how to ensure that the fast growing IXPs are able to get resources without having to renumber.

Andrew Owens also commented that he cannot create an AS0 ROA for the aggregated /22 NAPAFRICA holds( 2 x /23s) . James Chirwa responded that this issue will be looked into and feedback provided.

Jordi Palet from the IPv6 company mentioned that RFC8950 was updated recently and enables dual-stack Internet Exchanges (IXPs) to operate without requiring public IPv4 addresses for peering LANs. He also proposed submitting a policy proposal to address the issues presented , noting it is a feasible and necessary resolution for both IXPs and ccTLDs, and offered to co-author it. Gregoire Ehoumi requested that AFRINIC staff provide concrete statistics—specifically the number of members impacted by resource reservation constraints—when presenting issues. He argued that this data is essential for the community to understand the urgency of an issue before committing to the policy development process. James Chirwa (AFRINIC Staff) acknowledged this feedback and committed to sharing relevant statistics on the mailing list in the future.

7. Proposal#5: IPv6 as a criteria in IPv4 Soft Landing

7.1. PDWG Chair Introduction & Discussion Flow

PDWG co-chair Darwin da Costa introduced the next proposal on the agenda titled Ipv6 as a criteria in soft landing , authored by Jordi Palet Martinez. The first version has been submitted on the 22 of May 2026 and the second one was submitted on my birthday actually on the 14th of June 2026.

7.2. Author’s Presentation

Jordi Palet then took the floor and explained that during the discussions of his earlier 2 proposals on the mailing list, there was a suggestion that the allocation of IPv4 resources in softlanding be tied with IPv6. He opted for a separate proposal so as to not block a proposal in the event that one part of it does not reach consensus.

Jordi Palet Martinez noted that despite AFRINIC’s extensive training and support efforts, IPv6 deployment in Africa is lagging compared to other regions. To address this, he introduced a proposal to make IPv6 deployment a requirement for obtaining new IPv4 resources during the "soft landing" phase. This condition would only apply to those requesting additional IPv4 space, ensuring a commitment to IPv6 adoption alongside new IPv4 allocationsThose organisations that already have IPv4 but don’t need to grow are free to deploy IPv6 at leisure. But, in the case those requiring new IPv4 resources, the proposal ensures that entities requesting new IPv4 resources simultaneously commit to IPv6 deployment. The draft outlines proposed changes to the existing policy text, which are detailed in the accompanying documentation.

The additional policy text mentions that somebody requesting new IPv4 resources should present a coherent IPv6 addressing amd deployment plan. Coherent means consistent. The proposal is not changing the requirements for IPv6 from the existing IPv6 policy.

He stressed what points of the existing policy for LIRs and end users need to be depicted in the deployment plan -

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.

In response to another question on the RPD Mailing list in regard to how to measure the deployment plan , he mentioned that based on his experience of having done hundreds of deployments , he knows very well how to measure that. A simple way to measure is based on what all the operators know for example netflow or other tools that allow them to check how much traffic is going to certain destinations and he has picked the top 25 destinations of a specific operator.

  • Compliance is measured by checking IPv6 traffic volume to an operator’s top 25 destinations (e.g., major content providers like Meta or Google).
  • The proposal sets achievable goals, such as achieving 25% IPv6 traffic to those top destinations within the first 12 months.
  • The overall objective is to reach 75% deployment—not necessarily 100%—within four years.
  • The author argued that this method is "soft" and realistic, allowing operators to integrate IPv6 incrementally based on existing traffic data without needing costly new infrastructure or sudden, disruptive changes. For service and application providers,
  • deployment progress can be measured by checking how many resource records (AAAA) are reachable via IPv6 from the public internet.
  • The author characterises the 25% compliance target for the first year as a "soft" goal, noting that typical IPv6 deployments for residential customers often reach 85% traffic levels naturally without extra effort.
  • Progressive Implementation: This approach encourages a gradual, progressive transition rather than a sudden or costly operational overhaul.

7.3. Staff Impact Assessment

Madhvi Gokool, staff, presented the impact assessment. The QR code on the slide will directly go to the website where the full impact assessment is published.

Understanding of the proposal. the proposal maintains the current soft landing approach for IPv4 request during exhaustion while adding new eligibility conditions tied to IPv6 adoption. New and existing members requesting IPv4 must also request, justify, and satisfy the IPv6 allocation or assignment criteria, including a coherent deployment plan. For members already holding IPv6, additional IPv4 requests trigger a retrospective review of their IPv6 needs and utilisation.

The proposal, as understood, introduces measurable deployment expectations based on the top 25 IPv4 traffic destinations that are IPv6 enabled. The minimum IPv6 compliance threshold are stated and the policy proposal also mentions that failure to meet eligibility or follow the deployment plan will result in IPv4 ineligibility and may also be treated as a policy breach.

Benefit to Afrinic We understand that the proposal aims to encourage concrete IPv6 deployment rather than passive IPv6 holdings and introduces stronger accountability for organisations seeking scarce IPv4 resources during exhaustion. It may support Afrinic's broader policy and stewardship objectives by linking remaining IPv4 access to demonstrated IPv6 transition intent.

Impact on the resource members

We feel that the members without immediate IPv6 deployment plans would be required to justify IPv6 resources and also provide additional operational evidence before receiving the IPv4 prefixes. It creates a more demanding request process especially for members with limited IPv6 capability, expertise or infrastructure constraints. The proposal may also disproportionately affect small operators, example the wireless ISPs due to device compatibility, commercial realities or technical readiness. So staff considers that this may create some tension with the fairness objectives in the consolidated policy manual where justified applicants are denied IPv4 due to the practical barriers to IPv6.

So while the proposal introduces meaningful implementation expectations, several parts require some clarification before reliable and consistent operational enforcement becomes possible. So it is unclear whether the retrospective evaluation of already issued IPv6 should assess both the original stated need and the actual deployment process over the initial 12 months period. The policy requires requestors to satisfy IPv6 eligibility criteria under sections 6.5.1.1.3, 6.5.1.1.4 and 6.8.2.2(d) but it does not clearly address the interaction with CPM section 6.4.4 which explicitly allows IPv4 service providers to justify larger IPv6 requests based on the present IPv4 customers transitioning to IPv6.

The phrase requiring a coherent IPv6 deployment and addressing plan is operationally significant but the standard for coherence is not defined.The mechanism for measuring the top 25 IPv4 traffic destinations, validating which are IPv6 enabled and assessing progress against the percentage threshold is not specified. The proposal does not state what evidence is acceptable to demonstrate compliance, partial compliance or justified delay in deployment. Specific consolidated policy manual and procedural touch points requiring clarification include section 6.4.4 and the IPv6 eligibility provisions in section 6.5.1.1.1 through 6.5.1.1.4 and 6.8.2.2(d).

Areas of impact

So in regard to the areas of impact, the proposal interacts with some existing clauses in the consolidated policy manual. There's section 6.4.4 as well as the other three sections that we've spoken about. So this interaction materially changes how staff would assess IPv4 requests during exhaustion by making IPv6 readiness and deployment evidence part of the decision path. There are no direct interactions with the other proposals under the under discussion at this stage and should the proposal reach consensus and be ratified for implementation, it will impact the Myafrinic system, the hostmaster member portal as well as the transfer tool where we'll have to update the workflow and user interface changes to support the linked IPv4 and IPv6 request handling, capture deployment and addressing plans, trigger retrospective reviews and generate internal notifications or compliance tasks. There is an impact regarding our billing system -. Billing integration updates may be required depending on whether simultaneous IPv4 and IPv6 evaluation or additional review steps affect membership and resource processing flows. The NMRP system that's the new member registration portal - updates are required on this platform to reflect the new resource request criteria and retrospective review conditions. the procedures in the member services department - the department that handles evaluation have to be will have to be revised. No contractual updates have been identified. as usual since it's a resource policy the website and communications around the policy have to be updated

In regard to the IT changes are expected primarily on myafrinic and related internal workflow tooling. In regard to the human resource impact, the proposal is likely to require additional staff capacity with targeted training particularly for host masters involved in evaluating request justification and deployment evidence. So there's a need for training and also the expected case volume may increase materially which would motivate additional recruitment. No legal issue were raised for this proposal and if we have to invest further in recruitment or training etc, there will be a financial impact.

Recommendations regarding the policy wording. the deployment plan compliance details be moved to the relevant IPv6 sections of the CPM rather than being introduced indirectly through the IPv4 soft lending context. This would improve structural clarity, reduce ambiguity during evaluation and better align the operational obligations with the policy sections that already govern IPv6 qualification. Additional wording improvements should explicitly define what constitutes a coherent IPv6 deployment plan and How retrospective reviews to be conducted for existing IPv6 holders. What evidence is required to show progress against the 12, 24 and 48 months thresholds. how section 6.4.4 should be applied when existing IPv4 infrastructure is part of the IPv6 justification and what operational consequence follows from partial compliance justified delay or non-compliance on this

Author’s clarifications

Jordi Palet mentioned that he has responded to some points in his previous slides and further added that ➖

  • Impact on resource members. Actually, based on hundreds of deployments experience, deploying IPv6 is easier in smaller networks similarly deploying IPv6 using for example 464XLAT which is one of the recommended technologies especially the only one in mobile networks is cheaper than maintaining IPv4 artificially which carrier grade NAT
  • There is no unfairness otherwise we can also say that soft landing policy is unfair by itself because newcomers can only get a maximum of /22 versus a bigger prefix that were available before softlanding. Clearly policies need to adapt to the internet evolution and to the available resources and the evolution of the internet is that everyone should be moving to IPv6. So there is no discussion on that.
  • clarity of policy text the evaluation of the IPv6 usage.

i) The proposal does not change the core evaluation criteria for IPv6 requests; it only requires that specific, integral details be included in the deployment plan when an organisation requests additional IPv4 resources. ii) He argues that if an organisation is requesting more IPv4 capacity, their deployment plan should naturally cover that growth, and it would be illogical to limit IPv6 transition efforts to only a subset of customers.

  • He maintains that he is not changing existing policies, but rather reinforcing expectations for the deployment plans that are already a requirement under current policy.

The author explains that measuring IPv6 compliance is straightforward for network operators using existing tools and data:

  • Operators should already be monitoring their network traffic (using tools like SNMP or NetFlow) to manage operations effectively, so no new, costly infrastructure is needed.
  • By analysing top destinations (such as Google or Meta), operators can generate graphics showing current traffic behavior. These can be used to track and demonstrate IPv6 adoption progress over one to four years.
  • Determining appropriate prefix sizes (e.g., /32 or /31) based on customer counts is a simple mathematical calculation.
  • If an upstream provider lacks IPv6 support, the proposal accounts for this—if the top destinations are not reachable via IPv6, the required compliance percentage (based on 0% traffic) is automatically met, ensuring operators are not penalised for circumstances beyond their control. He also recommended that the organisation find an upstream that provides IPv6 or use a tunnel with BGP.

7.4. PDWG Chairs Summary of the discussions on the Proposal

PDWG co-chair Darwin da Costa noted that version one of the policy received mailing list support and suggestions, though concerns were also raised; draft two saw no further discussion.

7.5. Open Microphone Discussion

Saul Stein from eNetworks supported the proposal but argued that ISPs cannot force customer IPv6 adoption. They worried that low customer uptake could inadvertently place ISPs in breach of policy requirements.

Jordi Palet Martinez countered that residential IPv6 deployment is straightforward because ISPs control the equipment and can turn on IPv6 in the CPE. For enterprise clients, he maintained that the proposed 25% initial traffic target is a realistic, phased goal that allows ISPs time to educate customers rather than requiring immediate, full-scale implementation.

The speaker supports the proposal but raises two concerns:

  • Not all organisations possess the tools (e.g., NetFlow) required to measure utilisation as proposed.
  • The measurement criteria are ambiguous, questioning whether monitoring traffic volume to top destinations is a valid indicator of actual IP utilisation.

Jordi Palet explained as follows ➖

He understands that some smaller network operators and end users are not using netflow but this is something that they should do despite whether they want to deploy or not IPv6. Because platforms like Google, YouTube, and Meta are already IPv6-enabled, measuring traffic volume to these top destinations provides an immediate and realistic metric for deployment progress.

Operators should aim for 25% IPv6 traffic volume to their top 25 destinations within the first year. For smaller networks with fewer than 25 destinations, the measurement can simply be based on the available data.

While some operators may not currently use these monitoring tools, he argued that flow-based monitoring is an essential practice for healthy network management, regardless of IPv6 adoption. Operators can use standard tools like NetFlow (or similar open-source alternatives) to analyse traffic patterns; no costly new infrastructure or proprietary software is required.

Saul Stein countered back that the author assumes that most ISPs do retail(residential) . Those ISPs that most do B2B will face an issue.

Jordi Palet, the author responded that when an ISP has a majority of business customers, the proportions of the traffic will change .If the ISP is able to convince a small portion of its customers to deploy IPv6, it can get extra business by providing consultancy services and training.

Paul Hjul from Crystalweb intervened as follows :-

  • He fears that defining compliance solely by traffic volume (25% initial, 75% long-term) might encourage "bad behavior" or manipulation to show compliance , rather than authentic IPv6 deployment.
  • Legitimate enterprises may find the thresholds oppressive or commercially damaging.
  • He suggests a 12-month review period to evaluate whether these perverse incentives are actually manifesting.
  • He is concerned the proposal may suffer the same fate as a past "Policy Compliance Dashboard" proposal—community adoption followed by Board rejection due to staff objections.
  • He supports the policy.

Jordi Palet Martinez addressed concerns regarding potential manipulation of compliance metrics by 'bad actors,' arguing that this is a broad issue for all policies rather than a flaw specific to this proposal. He noted that failing to adhere to the IPv6 deployment plan is already a policy violation. Furthermore, he criticised the Board’s previous rejection of the 'Policy Compliance Dashboard' policy, stating that when consensus-backed policies are not ratified, the community requires transparent, clear explanations beyond relying solely on potentially flawed staff assessments.

He clarified that he is not demanding a strict implementation timeline. He is willing to accept an implementation period longer than the standard six months, noting that this would accommodate the current heavy staff workload and provide the community with more time to improve IPv6 deployment, making the policy’s targets more achievable once enacted.

Lexa Mpua from Malawi Research and Education Network commented as follows ➖ She acknowledged the concerns raised about the difficulty of mandating IPv6 adoption for clients and customers.

She noted that customers often lack the necessary technical understanding of network operations to make informed decisions.

It is the responsibility of the network experts to guide clients toward better network-related choices. While customers might initially feel restrained by these requirements, they will eventually realise that these decisions were in their best interest and helped them make good network choices.

Seun Ojedeji speaking as his personal self intervened as follows :-

Everyone is interested in seeing IPv6 adoption improve in this region, but the realities mentioned earlier are significant He suggested introducing a "grace period" for requests, such as allowing a specific number of IPv4 requests (e.g., five) before mandatory IPv6 requirements are triggered. Another alternative aims to provide a buffer for small businesses and providers who are not yet prepared for IPv6, ensuring they can remain commercially viable. He stated he is not comfortable supporting the proposal’s move to the Last call as currently written, preferring to discuss modifications to better accommodate different business realities.

The author (Jordi Palet Martinez) indicated openness to exploring these alternative possibilities and invited further contribution to improve the proposal.

7.6. PDWG Chairs Decision

Having considered the discussions in the RPD mailing list and the current PPM, the authors have not addressed all the concerns raised by the PDWG. The co-chairs have determined that consensus has not been reached. The draft policy proposal therefore goes back to the mailing list, and authors are encouraged to address all the concerns with regards to this policy proposal.

8. Proposal#6: Policy Compliance Dashboard

8.1. PDWG Chair Introduction & Discussion Flow

Dr. Vincent Ngundi introduced the policy proposal that was actually submitted on the 30th of April 2026.

8.2. Author’s Presentation

  • The proposal previously reached consensus a few years ago, around 2020 or 2022.
  • According to the CPM, an unratified proposal expires in one year, but the expiry timeline is supposed to restart when a new version is submitted.
  • However, the proposal was incorrectly allocated a completely new ID as if it were a new submission.
  • This change of ID makes it difficult for participants to follow the history of the proposal on the website or via the mailing list because the subject has changed.
  • The Consolidated Policy Manual (CPM) is updated regularly, usually following meetings like the Public Policy Meeting (PPM).
  • Many community members do not follow these discussions or belong to the mailing list, so they need a way to verify their compliance with the CPM.
  • The proposed policy compliance dashboard aims to implement an automatic system to notify members if changes affect their compliance.
  • Members will be given time to address non-compliance issues.
  • Under the mandate of the Registration Services Agreement (RSA), the staff can reclaim resources from members who fail to comply with the policies.
  • The previous version of the proposal reached consensus but was not ratified by the Board due to extensive text detailing how staff should behave to ensure fair treatment for non-compliant members.
  • The selected content discusses modifications made to the latest version of the Policy Compliance Dashboard proposal to address the Board's previous refusal to ratify it. The previous version was rejected due to extensive text detailing staff procedures, which was perceived as an encroachment. To achieve ratification, the authors simplified the proposed policy text to cover only the core elements: the dashboard's function, notifications, definitions of non-compliance, and the consequences of failing to comply. All procedural details and examples have been moved to an appendix, leaving operational workflows at the discretion of the staff without violating the RSA or bylaws. The goal remains an automated dashboard implemented in MyAFRINIC v2.
  • The speaker expresses that the impact assessment in the current proposal is not conducted in a fair manner.
  • Certain considerations removed from the previous version have introduced new legal suggestions that do not make sense to the authors.
  • There is a need for a clearer, more explicit response from the board when a proposal lacks ratification, explaining exactly what is not being accepted and why.
  • The board should conduct its own independent assessment rather than declining ratification solely based on the existing impact assessment.

8.3. Staff Impact Assessment

Madhvi Gokool, staff brought a clarification regarding this proposal that received a new ID.

  • The Consolidated Policy Manual (CPM) currently does not provide guidance on this matter.
  • Had the proposal been ratified by the board, it would not have expired as it would have moved toward implementation.
  • Because it was not ratified after 3 years, it had already expired based on its original submission date, leading to its expiration and the assignment of a new ID for the new proposal.
  • It would be beneficial for the CPM to provide further guidance in the future on how such proposals should be handled.

On the subject of the impact assessment, The QR code links directly to the web page where the impact assessments are published.

  • The proposal introduces a new section in the consolidated policy manual to establish a policy compliance dashboard.
  • It requires AFRINIC to monitor member compliance with existing implemented resource policies periodically and automatically.
  • The system will notify members when non-compliance is detected, escalate persistent non-compliance to staff, and define procedures for service withholding.
  • A board-level exception mechanism will be introduced for cases involving critical internet infrastructure, allowing AFRINIC to act under the RSA and bylaws.
  • A new compliance dashboard will be built within the MyAFRINIC system (hostmaster, member portal and transfer tool), ensuring members see only their own data while staff can see all data.
  • Automated checks will run against WHOIS contact accuracy, abuse validity, route object consistency, RPKI coverage, and reverse DNS requirements, feeding data automatically into the dashboard.
  • The dashboard will track and log compliance states—such as policy compliant, first notice sent, second notice sent, remediation in progress, escalated, or closed—with timestamps for audit purposes.
  • Automated email notifications to members and staff will be triggered by these state changes.
  • A new procedure for monitoring and actioning non-conformance will be introduced for member services operations, along with publication of the procedures on the website.
  • Implementation will be executed on existing IT systems.
  • There is a recommendation to recruit more staff due to the workload introduced for host masters to work with members, overcome non-compliance, and minimise resource revocation.
  • A significant legal assessment with recommendations has been provided to review

According to the legal assessment, the main and substantive legal issues of this present draft proposal are as follows:

  • Delegation of powers to staff: Several clauses leave substantive matters to be determined later by staff. Such an approach creates a legal uncertainty problem because while the draft policy itself establishes obligations and potential sanctions, it leaves essential elements undefined, such as what constitutes "persistent non-compliance."
  • Lack of provision concerning due process: Having regard to the principles of legal certainty and predictability, the draft proposal does not provide sufficient or adequate procedural safeguards. Consequently, as presently drafted, it may expose AFRINIC to allegations of procedural unfairness, arbitrary decision-making, and unequal treatment of members.
  • Conflict with existing RSA provisions: The proposal repeatedly refers to the RSA. However, the legal relationship is governed primarily by contract. Therefore, the legal position is that the intent of the authors is to merely operationalise existing RSA rights and not to create new contractual remedies. The latter could create enforceability issues; hence, clarity is required.
  • Board powers: The proposed paragraph is drafted in overly broad and vague terms, making it difficult to discern the specific issue or problem it seeks to address. Furthermore, essential terms have been left undefined, such as "special measures," "essential strategic infrastructure," "political instability," and "exceptional situations." From a governance perspective, such wording may be criticised for granting discretionary powers that are insufficiently constrained.
  • Privacy and data protection: The proposal contemplates automated compliance reviews and compliance dashboards, yet it is silent on what member data will be collected and processed, how compliance determinations will be made, whether third-party data sources are used, retention periods, accuracy verification, and members' rights to challenge data.
  • The risk of conflating objective metrics with policy compliance: The proposal seems to be grounded on the premise that compliance can be objectively measured. It is important to recall that many AFRINIC policies involve qualitative assessments such as justification of needs, proper resource utilisation, and documentation requirements. Accordingly, an automated dashboard may incorrectly suggest that all policy compliance can be reduced to objective metrics. Therefore, the proposal should distinguish between objective compliance indicators and matters requiring human assessment.

Recommendations:

The recommended course of action would be to limit the policy to establishing the principle of compliance monitoring while leaving investigations, sanctions, appeals, and revocations for separately adopted transparent operational procedures and contractual instruments that expressly incorporate due process safeguards.

The legal team has also made recommendations on policy wording:

  • Limit policy wording to compliance monitoring and transparency: Redraft the proposal so that the CPM establishes the principle, scope, and member-facing purpose of the policy compliance dashboard while avoiding language that creates new enforcement powers beyond the RSA and AFRINIC’s existing contractual framework.
  • Replace open-ended delegation to staff with defined operational procedures: Use wording that requires AFRINIC to publish transparent operational procedures approved through the appropriate governance process before enforcement actions are applied.
  • Clarify the relationship with the RSA and bylaws: State that the dashboard and related notices operationalise existing rights and obligations under the RSA bylaws and applicable policies and do not create new contractual remedies until those remedies are expressly incorporated through the appropriate contractual process.
  • Phase implementation to reduce operational and user impact: Recommend a staged rollout beginning with visibility-only reporting, followed by member notifications, staff review workflows, and only later enforcement-related steps once systems, procedures, staffing, and communications are ready.

To summarise, AFRINIC is not against the policy compliance dashboard. We are requesting wording that does not create further risk or challenges to how we manage our members, our contracts, and policy compliance.

8.4. PDWG Chairs Summary of the discussions on the Proposal

Dr. Ngundi mentioned that the dashboard is very important. He invited the PDWG to discuss the proposal. The author Jordi Palet requested for and was granted the permission to clarify on the impact assessment.

8.5. Open Microphone Discussion

Jordi Palet, author clarified as follows :-

  • Section 3.4.1 of the CPM states that the timeout period restarts when a draft policy is replaced by a more recent version of a proposal.
  • A draft policy expires after one calendar year unless it is officially approved as a policy by the African Board of Directors.
  • Out of four policy proposals on the table when AFRINIC was put on hold, three respected this text, but this specific proposal was treated differently and assigned a new ID.
  • The assignment of a new ID complicates the process of tracking the history and reading previous discussions for new participants.
  • The author fundamentally disagrees with the impact assessment, noting that points previously withdrawn due to staff requests are now being reintroduced.
  • Further discussion with the staff is required to achieve clarity, which may lead to a new version that follows the recommendations.
  • There was insufficient time to update the proposal to meet the recommendations because the assessment was published today, and the legal text was shared only a few days or a week ago.

[]Herve Clement from Orange mentioned that regarding this policy, I totally support the advice regarding the implementation aspect. The words have to be carefully weighed and checked; without that, this policy cannot be adopted in my view.

Seun Ojedeji intervention as follows :-

  • Agreement with Jordi regarding the ID issue.
  • Staff could operationally reference previous proposals on the current one to help website visitors follow through on previous policies without needing a formal policy to mandate it.
  • The board did provide a reason when they sent their decision, so it is inappropriate to state they did not; it is simply a matter of whether Jordi and the authors agree with that reason.
  • The idea that the board should conduct an independent assessment can be debated, but staff is currently performing the assessment as a data source for the board's consideration of ratification.
  • It would be beneficial to see what other regions are doing based on the references in the proposal.
  • The dashboard is likely an operational matter rather than a policy issue, and staff could take their time to implement it.
  • While the dashboard is good to have, this may not be the right time to turn it into a policy.
  • He does not support the policy to advance to the next level.

Paul Hjul from Crystal Web intervened as follows :-

  • The new version of the policy is likely not an improvement over the previous version.
  • The board acted appropriately within its fiduciary responsibility and good cause by rejecting the policy based on staff feedback.
  • Moving forward, the board should secure an independent legal opinion before rejecting any policy that has achieved community consensus.
  • Staff should not provide legal opinions that import their own legal understanding to the board.
  • Community policy documents are technically focused but are typically reviewed by legally qualified individuals, and members are encouraged to have their own legal teams examine them.
  • The continuous second-guessing of PDP participants by AFRINIC staff is concerning and offensive.
  • While the policy framing makes assumptions about the RSA and staff powers, this should not prevent the creation of tools useful to members.
  • The policy does not introduce improper enforcement measures as it strictly operates within the existing regulatory and governance framework.
  • The speaker opposes the assertions made in the impact assessment and fully supports the policy as written.

Jordi Palet Martinez clarified that he did not mean that staff is against the policy. Instead, he thinks that the staff is not doing a good impact assessment in this case, and that is why he proposed that the board should take a better look and discuss with the community.

Sylvain Baya commented that the impact assessment report is good . He questioned why the data protection requirements were being invoked when the Mauritius government already has a data protection act. His view was that this policy is needed and appealed to the author to bring forward a text that will enable the proposal to reach consensus.

Madhvi Gokool, staff , clarified as follows ➖

  • Assessing compliance involves handling more members' data, necessitating compliance with the Data Protection Act of Mauritius.
  • MyAFRINIC V2 specifications already included a planned policy compliance section to assist members and staff in speeding up request evaluations.
  • While the community wants this feature established through formal policy, it would eventually be deployed as a staged feature in MyAFRINIC anyway.
  • This feedback was already shared with the author, Jordi. Policy text could be a quicker route, or it could simply serve as an enhancement requested by resource members.
  • Staff does not oppose the policy, agreeing that the dashboard is a beneficial feature that would otherwise be offered via the myafrinicv2 implementation
  • A commitment was made to link previous proposals to the current version to preserve the historical context for reviewers.

Vincent Ngundi PDWG Chair intervened as follows :-

  • He is pleased the Secretariat agrees on the necessity of monitoring compliance with AFRINIC policies.
  • The community must align on how that process should look.
  • Although impact assessments are optional, providing them just a day before is unfair to the author.
  • He suggested the community define timelines for these assessments and decide through policy whether they should be mandatory.

8.6. PDWG Chairs Decision

After deliberations and having considered the discussions in the RPD meeting list as well as the discussions in this PPM, the author has not addressed all the concerns raised by the PDWG. The co-chairs have determined that rough consensus has not been reached and therefore the draft policy proposal goes back to the mailing list. The author is encouraged to address all the concerns and engage the PDWG

9. Policy Update from other regions

  1. Mr. John Sweeting, Chief Experience Officer from ARIN was invited to showcase the presentation of the Policy landscape at ARIN.
  • John Sweeting provided a quick policy update for the ARIN region.
  • The policy development process is community-driven and bottom-up, meaning that policies only advance with demonstrated community consensus.
  • ARIN utilises an Advisory Council of 15 elected community members who assign primary and secondary shepherds to guide proposals through the policy development process.
  • The current timeline includes one proposal today, ARIN Prop-351, which goes to the Advisory Council and can proceed to a Public Policy Meeting for presentation and then Last Call if consensus is reached.
  • There are two recommended policies under consideration:
  • Policy 2025-7: A simple fix to make the policy text in section 6.5.8.2 of the Number Resource Policy Manual match the given examples, resolving a discrepancy where the text described a /48 projection but the examples illustrated a /44 allocation.
  • Policy 2025-10 - Reserve 410 space for in region use: A clarification to specify that the Section 4.10 IPv4 space set aside for transitioning networks to IPv6 is reserved exclusively for use within the ARIN region. This policy will be presented at the next meeting as recommended and is expected to move to last call and adoption.
  • Four other draft policies are currently in progress.
  • The most notable draft policy is 2026-1: Taking IP to Other Planets (nicknamed "tiptop"). While this topic is being discussed across various regions, ARIN is uniquely the only region where the author's proposal met all requirements to officially become an active draft policy.
  1. A video recording of a presentation from Angela DAll’Ara, the Policy Officer at the RIPE NCC , the RIR for the European region was then played.
  • Angela DAll’Ara, Policy Officer at RIPE NCC, provided an update on the status of policy development in the RIPE region.
  • RIPE NCC implemented a new policy regarding the revocation of persistently nonfunctional delegated RPKI certificate authorities (RIPE-847).
  • Monitoring has started to revoke delegated RPKI certificate authorities that remain nonfunctional for more than 90 days, with RIPE NCC reaching out to them beforehand to encourage them to fix their issues or remove their CAs.
  • There are currently two policy proposals passing through different phases (discussion, review, and last call) in the PDP:
  • 2024-01 (Revised IPv6 PI assignment policy): Currently at version two, it aims to modify and clarify permitted use cases for IPv6 PI assignments and introduce IPv6 PI issuances at the nibble boundary. RIPE NCC is developing an impact analysis to initiate the review phase, after which working group chairs will determine if rough consensus has been achieved based on community feedback.
  • 2025-01 (ASN assignment criteria revisited): Aims to simplify the requirements for receiving new ASNs while preventing the exponential exhaustion of the 32-bit ASN space. A new version is being developed to start a new discussion phase following feedback received on the first two versions.
  • Community members are invited to read the proposals and share feedback under the policy working group mailing list, or contact pdo@ripe.net with any questions.

10. Q&A and Open Microphone

  1. PDWG co-chairs opened the floor for comments
  2. Seun Ojedeji shared feedback on behalf of himself, drawing from their past experience as a board member and noted a lack of board presence at the meeting and emphasised the importance of the Board participating and listening to PPM discussions.He also observed that no Board representative came forward on the floor to address comments made regarding the board.
  • He commended the co-chairs for running the meeting, acknowledging from personal experience that leading the Public Policy Meeting is both interesting and challenging.
  • Regarding the "soft landing recovered space" policy, the speaker's understanding is that it passed and went to the Last Call with some modifications. However, the amendment of utilisation in the soft landing proposal did not pass, despite both being related to utility reasons.During discussions for the first policy, it was noted that the utilisation aspect still needs to be defined.The speaker expresses concern that both policies share similar constraints, yet one passed while the other did not.
  • There are quite a number of policy proposals pending implementation.Management and the board should look into helping expedite the implementation of these policies as the list keeps increasing. Proposals, such as the one recently moved to Last Call will soon go for ratification and remain in the queue with the rest.
  • He suggested that the Co-chairs Operational Experience Report be also part of the agenda so that the PDWG Chairs may relate their experience and the areas they wish to get clarity on to help them do their jobs better. The Community could also then consider what can be improved in the Policy Development process.
  • Lastly, Seun Ojedeji mentioned that a new chair is being selected during the current meeting. Having two co-chairs is generally considered desirable for the community. He therefore made a proposal to appoint a temporary co-chair at this meeting to support the incoming chair. The outgoing co-chairs were asked if one of them would be willing to step into this temporary role, subject to community agreement. This appointment aims to ensure continuity and provide support from someone with experience in the Policy Development Process (PDP).
  1. PDWG co-chair Dr. Vincent Ngundi responded that the Board Chairman was present in the session earlier today. In regard to the following draft proposals- soft landing recovered space and priority, Hierarchical Names for new AS-SETs and amendment of utilisation in soft landing, they passed (reached rough consensus). IPv6 as a criteria in IPv4 soft landing proposal and policy compliance dashboard and PDP Working Group (WG) Guidelines and Procedures were sent back to the mailing list. He mentioned that Hytham has been a PDWG Chair in the past and as outgoing chairs, he and Darwin will still serve the community.
  1. Jordi Palet, co-author of the two policy proposals that have been ratified by the Board, believes that even if the CPM specifies a 6-month implementation timeline, it is acceptable to proceed at their own pace due to the situation AFRINIC encountered over the past few years. The community understands the challenges related to time and budget restrictions. No complaints are expected from the community regarding the implementation pace, provided it does not take up to 10 years to finalise. He expressed gratitude to the AFRINIC staff for doing an excellent job during difficult times.
  1. Dewole Ajao , Board member intervened from the Boardroom and mentioned that in parallel to attending the PPM, the Board has been having meetings with different committees and working groups but were also following the PPM online.
  1. Darwin da Costa, the PDWG Chair, thanked the community overall and acknowledged Seun's comments. He noted that the team performed well under difficult circumstances and worked hard over the last five years to reach this level. Furthermore, he highlighted that they will leave behind a positive legacy of mutual respect and constructive discussions on proposals that matter for internet connectivity across the continent, stating that it is now time for others to step up.
  1. Cedrick Mbeyet , from AFRINIC clarified that his intervention regarding ccTLDs considering themselves critical infrastructure and seeking to benefit from AFRINIC internet number resources was brought forward on behalf of the ccTLDs themselves. He explained that he wanted to serve as a voice for those who may be hesitant to speak at the microphone, noting that community networks have also raised questions regarding what can be done for small networks.
  1. Dr. Vincent Ngundi expressed surprise over arguments that country code Top-Level Domains (ccTLDs) are not considered part of critical infrastructure. They highlight a 2008 policy they co-authored regarding provider-independent IPv4 address space for ISPs and ccTLDs, which enabled their own allocation at the time. Consequently, the speaker emphasises that the policy already exists and urges the community to recognise ccTLDs, data centers, and related infrastructure as critical infrastructure.
  1. Dr. Fiona Asonga CEO of TESPOK highlighted the importance of intentionally involving and reaching out to the ccTLD community within the AFRINIC space, ensuring they are included in program agendas to prevent them from feeling left out. It notes that for ccTLDs are factored into IP address allocation as critical infrastructure, it necessitates continuous outreach for new top-level domains and staff. Additionally, on behalf of service providers, gratitude is expressed to Darwin and Vincent for their dedicated efforts, time, and patience in bringing the community together and advancing the main policy development process during a challenging period.
  1. Dr. Vincent Ngundi expressed his gratitude to Dr. Fiona Asonga for her kind words and advice regarding AFRINIC's engagement with the ccTLD community. He acknowledged the challenging circumstances faced during the assignment and extended his thanks to co-chair Darwin da Costa and the Policy Liaison team, Madhvi and Brice, for their dedicated efforts and numerous meetings to bring sanity to the Policy Development Process. He recommended the AFTLD to review policies to ensure ccTLDs are officially recognised as critical infrastructure, noting that in the current policy, only internet exchange points are listed. He encouraged the mobilisation of the ccTLD community to propose these changes by the next PPM. He also expressed gratitude to Fiona for representing the board, supporting their work, and hosting the event alongside TESPOK. The hosts were commended for doing a fantastic job and for their years of dedication. The speaker noted pride in hosting Africa's recovery and recounted being called by elders in 2010 to support the continent due to deep affection for it. While acknowledging that they may not be able to continue further and might need to hand over responsibilities, they committed to offering ongoing support whenever and wherever needed in the future.
  1. Gregoire Ehoumi, an independent consultant, thanked the co-chairs for their excellent work. He highlighted the proposal on the PDP guidelines discussed during the meeting, noting that having a formalised process in place, such as an NRC, to handle situations where an outgoing co-chair supports a new co-chair would be highly beneficial. He encouraged continuing the discussion on the PDP guidelines and utilising past experiences to establish clear policies, which would help limit future contestations.
  2. Dr. Vincent Ngundi mentioned that there's a sustained call for one of the current co-chairs to continue with their role. He noted that since the next PPM is in November, a second co-chair can be elected then. He asked Darwin if he could remain available until November. Darwin replied that it was a tricky question and explained that his professional focus has shifted away from the continent. While he cannot give a definitive yes or no now, he committed to evaluating his availability over the coming weeks. Vincent thanked Darwin, expressing that serving until November should be doable. He then handed the floor over to the NOMCOM Chair to proceed with the next agenda item before formally closing the meeting.

11. PDWG Chair selection

Mr. Ganesh Ramalingum ,the Chairman of the Nomination Committee 2026 presented to the attendees of the PPM, the selection of the PDP co-chair for a term of 2 years and which is also a voluntary position. He showed the selection process and timeline. Call for nomination started on 8th of May and was closed on the 29th of May . Vetting and verification happened on the 30th of May and the final slate was published on the 4th June. Nomcom received 2 submissions for 2 unique candidates. The vetting criteria was as follows :-

  • Candidates must reside in the AFRINIC service region.
  • The documentation presented has to be complete.
  • The nominator and the seconder must be in good standing.
  • The candidate must show engagement within Africa AFRINIC on the event.
  • There must be no conflict of interest.
  • The selected candidate is Hytham El Nakhal from Egypt.

The details of the selected candidate were presented and the Community requested to give their acceptance and voting for that candidate.

  • The floor was opened to the community for acceptance of the candidate.
  • A call was made for participants to show their acceptance by a show of hands.
  • Participants who disagreed were requested to lift their hands.
  • The proposal was noted as accepted.

Incoming PDP chair Hytham El Nakhal expressed gratitude to everyone who supported his selection and participated in the policy proposal discussions. He extended special appreciation to the current PDP co-chairs, Dr. Vincent and Mr. Darwin, and expressed his hope to continue their valuable development work efficiently with the support of the community and Afrinic.

12. Closing of PPM

During the closing of the Public Policy Meeting (PPM), Vincent invited Darwin to share his closing remarks. Darwin congratulated Mr. Hytham on his appointment and expressed his gratitude to the African Policy Liaison Team (PLT), specifically highlighting the excellent work done by Brice and Madhvi. He commended the team for their resilience and collaboration during turbulent times, managing both intense and inactive periods effectively. Furthermore, Darwin thanked the community for their patience and praised the high level of respect and understanding demonstrated during the policy proposal discussions. Finally, he thanked the board for their trust and presence, and expressed appreciation to Kenya for hosting the event in Nairobi.

Dr. Vincent Ngundi expressed gratitude to his co-chair, Darwin, as well as Madhvi and Brice, for their extensive behind-the-scenes work, including reviewing documents, drafting emails, and managing logistics, which successfully supported operations during a challenging and uncertain period of organisational turbulence. Additionally, he thanked the PDWG community, noting that despite a heated previous meeting in Mauritius, the smooth-running meeting in Nairobi reflects how the organisation should be remembered, rather than the chaos experienced over a three-year period.

Seun Ojedeji formally put on record for both in room and online attendees that no member of the community is opposing the idea of having the outgoing co-chair support the new co-chair if they eventually determine that they can find time for it.

Dr. Vincent Ngundi mentioned that significant progress has been made over the years, bringing a level of tranquility, though challenges remain and substantial work lies ahead. Policy development is critical to protecting the Policy Development Process (PDP) and managing resources effectively, especially following recent turbulent times. Members are urged to review the policy proposal on the mailing list to understand how it addresses these challenges.

Additionally, there is a strong need to increase engagement with governments, strengthen the Africa government working group, and involve governments in policy development, as these decisions impact national and regional policies. The secretariat is requested to develop strategies for greater government engagement.

He requested for a show of hands in support of an outgoing PDWG Chair to support the incoming Chair and announced that there was consensus within the PDWG on this matter.

Dr. Vincent Ngundi formally closed this 37th Public Policy Meeting and thanked everyone for their contributions.

13. NRO-NC/ASO-AC Election Results

The Election Committee Chairperson, Wayne Gurunaden, announced the results for the voluntary NRO NC and ASO AC positions. The election process, which began with nominations on May 8 and concluded with voting on the day of the meeting, involved five initial submissions, resulting in two eligible candidates. Based on the final vote count, Musa Honlue received 106 votes and will serve a term extending to December 2029, while Nitin Sookun received 34 votes and will serve until December 2028. Following this announcement, the meeting was formally concluded.