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

Mon Jun 15 06:36:56 UTC 2026

{sent with a registered email address now!}
{i hope i'm not too late to add my comment!}
Le 21/05/2026 à 14:28, jordi.palet--- via RPD a écrit :
> Hi all,
> [...]
> Comments welcome!
>

Hi Jordi,
Thanks for your email, brother.
It's my pleasure to be able to review the DPP
(Draft Policy Proposal)!

> Tks!
>
> Regards,
> Jordi
>
> @jordipalet
>
>
>> El 15 may 2026, a las 17:51,dacostadarwin at gmail.com escribió:
>>
>> Dear PDWG,
>>
>> We have received a new draft policy proposal - Amendment of Utilisation in Soft Landing, ID AFPUB-2026-IPv4-002-DRAFT01 from author Jordi Palet Martinez. The proposal contents are published at:
>>
>> https://afrinic.net/policy/proposals/afpub-2026-ipv4-002-draft01
>>
>> We encourage you to take some time to go through the proposal contents and  provide feedback as follows :
>>

Dear PDWG,

Do kindly consider my review of the
AFPUB-2026-IPv4-002-DRAFT01 DPP
(Draft Policy Proposal) below.

<quote>

    1. Summary of the problem being addressed by this proposal

The Soft-Landing utilisation criteria is preventing organisations that 
may have multiple sites, redundancy or high availability needs to 
achieve that, because section 5.4.6.1 states that 90% of the previous 
allocations or assignments must have been used.

For example, an end-user member may have received a /24 for a Data 
Centre and now is setting up new Data Centres. Current policy will not 
allow that until 90% of the first Data Centre prefix is utilised.

Another example may be an ISP, with multiple BGP PoPs, setting up 
464XLAT in the network, with NAT64 devices in each PoP for 
high-availability purposes. Normally it will announce a /22-/24 in each 
PoP, even if all the addresses are not being used simultaneously all the 
time, so 90% utilisation is not allowing that deployment offering 
high-availability to the subscribers.

</quote>

...maybe the Policy Liaison Team could tell us
more about the number of such requests; the
hostmaster is actually unable to satisfy.

This problem seems to be reasonable; but i
have a small doubt on the urgency; of these
situation. Can we found at least three Orgs
per case? prior to validate the problem which
is formulated here.

<quote>

    2. Summary of how this proposal addresses the problem

This proposal suggests that the utilisation criteria should allow cases 
such as those in the previous examples and similar ones.

Because the 3 million IPv4 recovered addresses, this change will not 
create an immediate drain of the AFRINIC pool, and instead, can help to 
increase the number of DC and high-availability, IPv6 deployment and 
better connectivity for the region.

</quote>

3 million IPv4 recovered
~ /11 + /12
2²¹ + 2²⁰ = 3145728 ?

...while the problem, as formulated, might be
validated (by real facts); i think if we want to
keep "one shop", then it's necessary to keep
the same definition of "first allocation"; for
instance.

<quote>
Proposed

~~5.4.6.1 In order to receive IPv4 allocations or assignments during the 
Exhaustion Phase, the LIR or End User must have used at least 90% of all 
previous allocations or assignments (including those made during both 
the Current Phase and the Exhaustion Phase)

In the case of new LIRs or End Users with no previous allocations or 
assignments, this requirement does not apply to their first allocation 
or assignment request.~~

"The above requirement is waived for network operators requesting new IP 
addresses for key technical needs – such as redundancy and 
high-availability sites, IPv6 transition technologies, or expansion to 
new sites which pose a technical constraint on their current resource 
pool – and in these cases, the request is treated as a first allocation 
or request."
</quote>

...i disagree with the above approach; as it
looks like a less optimal approach. It goes
without saying that when a first allocation
or assignment exists, any resource holder
should be treated same as all the others in
same conditions.

What could be done, imho, if the edge cases
you have described are proved true; should
be to consider a different approach in order
to address their specificity.

...if applicable; then i would suggest the text
below as a replacement to the part of text
between double quotes above:

"If a resource member (being a LIR or an
End-user) can prove that its actual need for
IPv4 resources can not be satisfied by its
available allocation/assignment, even in
case of a percentage of utilization lower
than 90 %; then notwithstanding the above
requirements, the requesting resource
member shall be *specially considered*
eligible to receive a new allocation or
assignment.

This *special consideration* shall also
be applicable to a new LIR or End-user,
with similar structural needs in IPv4
resources. In that case, the given LIR or
End-user shall be *specially considered*
eligible to receive a two allocations or
assignments; to begin with."

<quote>
*4. References*
In other regions, all IPv4 addresses have been exhausted and it seems 
that the equivalent to the soft-landing is not any more an issue, 
because most of the existing members only can access IPv4 addresses via 
transfers.
  </quote>

...i have found a counter-example to the above
statement; see, brother:
ARIN NRPM Section 4.1.8 
<https://www.arin.net/participate/policy/nrpm/#four18>*. ARIN Waitlist*.

Do kindly include this precision, to your
"References" section (4.), as you go.

Thanks.

Shalom,
--sb.

>> a) Do you support or oppose the proposal?
>> b) If you oppose the proposal, state your reasons?
>> c) Is there anything in the proposal that is not clear?
>> d) What changes could be made to this proposal to make it more effective?
>>
>> Regards,
>> Vincent Ngundi & Darwin Da Costa
>> AFRINIC PDWG Co-Chairs
>>
>>
>> _______________________________________________
>> RPD mailing list
>> RPD at afrinic.net
>> https://lists.afrinic.net/mailman/listinfo/rpd
> [...]
>

-- 

Best Regards !

baya.sylvain [AT cmNOG DOT cm] |
cmNOG's Structure <https://www.cmnog.cm/dokuwiki/Structure> | CAMIX's 
Website <https://www.camix.cm/> | Douala-IX's Looking Glass 
<https://tools.std.douala-ix.net/lg> |
cmNOG's Surveys <https://survey2.cmnog.cm/> | Subscribe to cmNOG's 
Mailing List <https://lists.cmnog.cm/mailman/listinfo/cmnog> |
__
#LASAINTEBIBLE|#Ephésiens5:18,15-21«[...] 18 Et *_ne vous enivrez_* pas 
*_de vin_*, en quoi *_il y a de la dissolution_*; mais *_soyez remplis 
de l'Esprit_*, [...]»
‬#LASAINTEBIBLE|#Hébreux13:9,5-15«[...] 9 _*Ne soyez pas seduits par*_ 
des _*doctrines diverses*_ et _*etrangeres*_, car il est bon _*que le 
coeur soit affermi par la grace*_, non par les viandes, lesquels n'ont 
pas profite à ceux qui y ont marche. [...]»
#AMEN,#Maranatha,#MerciJÉSUS! #‎MaPrière‬ est que tu naisses de 
nouveau.#Chrétiennement
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260615/7074bba7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x0387408365AC8594.asc
Type: application/pgp-keys
Size: 19438 bytes
Desc: OpenPGP public key
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260615/7074bba7/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260615/7074bba7/attachment-0001.sig>