[rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01.

Thu May 21 18:19:07 UTC 2026

As I said, Jordi, I support the proposal. However, to address concerns about potential abuse, we need to define some safeguards.

The points I shared are not intended to be fully adopted as they are; they are simply the initial measures that came to my mind. Others may further refine, amend, or add additional safeguards as needed.

I recommend including as many of these measures as possible in the proposal itself. Then, during staff review and further community discussion, they can be consolidated into a final set of safeguards to prevent abuse.

I hope this clarifies how I see the way forward.

With Regards.

Sami Salih.

Sami Salih
________________________________
From: Musa Stephen Honlue <honlue at gmail.com>
Sent: Thursday, May 21, 2026 9:00:55 PM
To: jordi.palet at consulintel.es <jordi.palet at consulintel.es>; rpd at afrinic.net <rpd at afrinic.net>
Subject: Re: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01.

Dear Jordi,

On a lighter note, I sometimes feel that IPv4 has reached a stage where every remaining allocation feels like a very carefully managed shared resource — which only reinforces the importance of clear and consistent exhaustion-phase policy.

Thank you for the proposal to revise Section 5.4.6.1. The intent is positive, particularly in introducing flexibility for legitimate operational needs such as redundancy, high availability, IPv6 transition mechanisms, and expansion to new sites.

However, I would like to highlight a few concerns and suggest refinements to improve clarity, consistency, and implementation robustness.

1. 90% utilisation requirement

Firstly, while the 90% utilisation requirement provides a clear conservation baseline, it remains too rigid if not complemented by a more explicit consideration of architectural efficiency and operational context.

A more balanced approach could retain the threshold while allowing justified exceptions based on clearly defined criteria. For example:

“In order to receive IPv4 allocations or assignments during the Exhaustion Phase, the LIR or End User must have used at least 90% of all previous allocations or assignments (including those made during both the Current Phase and the Exhaustion Phase). The above requirement may be waived where the request is justified by clearly demonstrated operational requirements that cannot be reasonably met within existing address space.”

2. Scope of waiver clause

Secondly, the waiver clause for “key technical needs” is currently broad and open to interpretation. Terms such as “technical constraints” and “new sites” would benefit from clearer definitions or bounded conditions to ensure consistent application and to avoid unintended ambiguity while postmasters evaluate resources requests, or misuse.

It may be preferable to require documented justification demonstrating that the need cannot be satisfied within existing allocations.

3. “First allocation” equivalence

Thirdly, the provision stating that such cases are “treated as a first allocation” may be too strong, as it risks bypassing the exhaustion-phase intent of the policy. A more appropriate framing would be that such requests are evaluated under criteria equivalent to a first allocation, while still preserving exhaustion-phase conservation principles.

4. Broader PIER-related consistency items

Finally, I note that the proposal addresses an important part of the PIER findings, but there remain additional structural inconsistencies raised by staff that may require separate attention, including:

  *   planning horizon inconsistencies (8-month vs 12-month references),
  *   minimum allocation inconsistency (/22 vs /24),
  *   treatment and policy framework for recovered IPv4 address space (approximately 3 million addresses).

Addressing these alongside the current proposal may further improve overall policy coherence.

Overall, I support the direction of the proposal and encourage strengthening the language around definitions, evaluation criteria, and safeguards to ensure consistency, predictability, and policy integrity.

--
Best Regards
--
Musa Stephen HONLUE
Agile Coach | Project Manager | Digital Transformation Champion.
Systems/Network Engineer.
=
t: +230 57444041 / +237 6 9310 6174
 | tt: @mhonlue | linkedIn: https://www.linkedin.com/in/honluemusa/
w:
www.skillsblocks.com| facebook.com/mhonlue
___________________________

On 21 May 2026, at 13:28, jordi.palet--- via RPD <rpd at afrinic.net> wrote:

Hi all,

This proposal, continuing with the idea of resolving the issues that have been discovered by the staff, is attempting to fix the problem of operators that need additional resources for redundancy, new sites (for example data centers), or even transition technologies.

The actual soft landing proposal doesn’t cover those cases and only allows obtaining additional resources when 90% of utilizations is reached.

Of course, I think is clear for all, that you don’t setup a data-center or other kinds of redundancy when your 1st data center is almost full, you actually want to have them being built even at the same time.

Similarly when you, for example, want to deploy 464XLAT, and you have 4 PoPs where you will locate the NAT64 boxes, you will need some free IPv4 pools (for example 1x/24 and each POP), and you want to do that in all the PoPs, not one, wait for 90% utilization, then the next one, etc., because you want to make sure to provide high-availability. This is a very clear case for me, in my day-job deploying IPv6-only with IPv4-as-a-Service worldwide.

This is easily achieved by waiving those requests from the 90% utilization and considering them as a “first request” (in fact, it is a first request for a new site).

The advantage for Afrinic, compared with other RIRs, is that we have recovered 3 millions of IPv4 addresses, so multiple sites allocations for every member, doesn’t mean draining earlier than expected the available pool when we entered in soft landing phases.

Comments welcome!

Tks!

Regards,
Jordi

@jordipalet

El 15 may 2026, a las 17:51, dacostadarwin at gmail.com escribió:

Dear PDWG,

We have received a new draft policy proposal - Amendment of Utilisation in Soft Landing, ID AFPUB-2026-IPv4-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at:

https://afrinic.net/policy/proposals/afpub-2026-ipv4-002-draft01

We encourage you to take some time to go through the proposal contents and  provide feedback as follows :

a) Do you support or oppose the proposal?
b) If you oppose the proposal, state your reasons?
c) Is there anything in the proposal that is not clear?
d) What changes could be made to this proposal to make it more effective?

Regards,
Vincent Ngundi & Darwin Da Costa
AFRINIC PDWG Co-Chairs

_______________________________________________
RPD mailing list
RPD at afrinic.net
https://lists.afrinic.net/mailman/listinfo/rpd

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

_______________________________________________
RPD mailing list
RPD at afrinic.net
https://lists.afrinic.net/mailman/listinfo/rpd

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260521/94bc6a4e/attachment-0001.html>