<html aria-label="message body"><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi Sylvain,<div><br></div><div>Some comments below, in-line.</div><div><br id="lineBreakAtBeginningOfMessage"><div>
<div>Regards,<br>Jordi<br><br>@jordipalet<br></div>
</div>
<div><br><blockquote type="cite"><div>El 15 jun 2026, a las 8:36, Sylvain BAYA <baya.sylvain@cmnog.cm> escribió:</div><br class="Apple-interchange-newline"><div>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<div text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">{sent with a registered email address
now!}<br>
{i hope i'm not too late to add my comment!}<br>
Le 21/05/2026 à 14:28, jordi.palet--- via RPD a écrit :<br>
</div>
<blockquote type="cite" cite="mid:29E79A7F-BF80-44DE-8B67-45521A95F2FB@consulintel.es">
<pre wrap="" class="moz-quote-pre">Hi all,
</pre>
<span style="white-space: normal">[...] </span><br style="white-space: normal;">
Comments welcome! <br>
<br>
</blockquote>
<br>
Hi Jordi,<br>
Thanks for your email, brother.<br>
It's my pleasure to be able to review the DPP <br>
(Draft Policy Proposal)!<br>
<br>
<blockquote type="cite" cite="mid:29E79A7F-BF80-44DE-8B67-45521A95F2FB@consulintel.es">
<pre wrap="" class="moz-quote-pre">Tks!
Regards,
Jordi
@jordipalet
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">El 15 may 2026, a las 17:51, <a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:dacostadarwin@gmail.com" moz-do-not-send="true">dacostadarwin@gmail.com</a> 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:
<a class="moz-txt-link-freetext" href="https://afrinic.net/policy/proposals/afpub-2026-ipv4-002-draft01" moz-do-not-send="true">https://afrinic.net/policy/proposals/afpub-2026-ipv4-002-draft01</a>
We encourage you to take some time to go through the proposal contents and provide feedback as follows :
</pre>
</blockquote>
</blockquote>
<br>
Dear PDWG,<br>
<br>
Do kindly consider my review of the <br>
AFPUB-2026-IPv4-002-DRAFT01 DPP <br>
(Draft Policy Proposal) below.<br>
<br>
<br>
<quote><br>
<h2><span style="">1. Summary of the problem being
addressed by this proposal</span></h2><p><span class="fabric-text-color-mark" data-renderer-mark="true" data-text-custom-color="#000000">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.</span></p><p data-renderer-start-pos="644"><span class="fabric-text-color-mark" data-renderer-mark="true" data-text-custom-color="#000000">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.</span></p><p data-renderer-start-pos="851"><span class="fabric-text-color-mark" data-renderer-mark="true" data-text-custom-color="#000000">Another example may be an <span data-highlighted="true" data-vc="highlighted-text"><span class="_kqswh2mm"><span class="_5pioz8co _189e1dm9 _1il9buyh _19lc184f _d0altlke" data-testid="definition-highlighter">ISP</span></span></span>,
with multiple <span data-highlighted="true" data-vc="highlighted-text"><span class="_kqswh2mm"><span class="_5pioz8co _189e1dm9 _1il9buyh _19lc184f _d0altlke" data-testid="definition-highlighter">BGP</span></span></span>
PoPs, setting up 464XLAT in the network, with <span data-highlighted="true" data-vc="highlighted-text"><span class="_kqswh2mm"><span class="_5pioz8co _189e1dm9 _1il9buyh _19lc184f _d0altlke" data-testid="definition-highlighter">NAT64</span></span></span>
devices in each <span data-highlighted="true" data-vc="highlighted-text"><span class="_kqswh2mm"><span class="_5pioz8co _189e1dm9 _1il9buyh _19lc184f _d0altlke" data-testid="definition-highlighter">PoP</span></span></span>
for high-availability purposes. Normally it will announce a
/22-/24 in each <span data-highlighted="true" data-vc="highlighted-text">PoP</span>, 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.</span></p>
</quote><br>
<br>
...maybe the Policy Liaison Team could tell us <br>
more about the number of such requests; the <br>
hostmaster is actually unable to satisfy. <br>
<br>
This problem seems to be reasonable; but i <br>
have a small doubt on the urgency; of these <br>
situation. Can we found at least three Orgs <br>
per case? prior to validate the problem which <br>
is formulated here.<br>
<br>
<br>
<quote><br></div></div></blockquote><div><br></div>According to my experience, with customers in all the 5 RIRs, those request not always come to the RIR.</div><div><br></div><div>If I need some resources, I see that the existing policy doesn’t allow me to request them, *most of the time* I will not waste my time going to the hostmasters to request something that the policy is clear I can’t request. So even if the hostmasters can provide some data, it may not be sufficiently representative.</div><div><br></div><div>The problem is there, can’t be denied, despite there have been 1 or 10 cases coming to the hostmasters.</div><div><br><blockquote type="cite"><div><div text="#000000" bgcolor="#FFFFFF">
<h2><span style="">2. Summary of how this proposal
addresses the problem</span></h2><p><span style=""> </span><span class="fabric-text-color-mark" data-renderer-mark="true" data-text-custom-color="#000000">This proposal suggests that the
utilisation criteria should allow cases such as those in the
previous examples and similar ones.</span></p><p data-renderer-start-pos="1420"><span class="fabric-text-color-mark" data-renderer-mark="true" data-text-custom-color="#000000">Because the 3 million <span data-highlighted="true" data-vc="highlighted-text">IPv4</span>
recovered addresses, this change will not create an immediate
drain of the AFRINIC pool, and instead, can help to increase the
number of <span data-highlighted="true" data-vc="highlighted-text"><span class="_kqswh2mm"><span class="_5pioz8co _189e1dm9 _1il9buyh _19lc184f _d0altlke" data-testid="definition-highlighter">DC</span></span></span>
and high-availability, <span data-highlighted="true" data-vc="highlighted-text">IPv6</span> deployment and better
connectivity for the region.</span></p>
</quote><br>
<br>
<span class="fabric-text-color-mark" data-renderer-mark="true" data-text-custom-color="#000000">3 million <span data-highlighted="true" data-vc="highlighted-text">IPv4</span>
recovered</span><br>
~ /11 + /12<br>
2²¹ + 2²⁰ =<span class="qv3Wpe" id="cwos"> 3145728</span> ?<br>
<br>
...while the problem, as formulated, might be <br>
validated (by real facts); i think if we want to <br>
keep "one shop", then it's necessary to keep <br>
the same definition of "first allocation"; for <br>
instance. <br>
<br>
<br>
<quote><br></div></div></blockquote><div><br></div><div>Please check the PIER, it talks about 3 years per each million, according to current delegation rates. It is clear, with IPv6 deployment, and the waiver provider by this proposal, that it may speed up a little bit, but even if it just give us 3 years for the 3 millions, once IPv6 is being deployed, less and less IPv4 addresses are needed. This is the reason why regions with more IPv6 deployment become the source for more IPv4 transfers.</div><br><blockquote type="cite"><div><div text="#000000" bgcolor="#FFFFFF">
Proposed<br>
<br>
~~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)<br>
<br>
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.~~<br>
<br>
"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."<br>
</quote><br>
<br>
...i disagree with the above approach; as it <br>
looks like a less optimal approach. It goes <br>
without saying that when a first allocation <br>
or assignment exists, any resource holder <br>
should be treated same as all the others in <br>
same conditions. <br>
<br>
What could be done, imho, if the edge cases <br>
you have described are proved true; should <br>
be to consider a different approach in order <br>
to address their specificity. <br>
<br>
...if applicable; then i would suggest the text <br>
below as a replacement to the part of text <br>
between double quotes above:<br>
<br>
"If a resource member (being a LIR or an <br>
End-user) can prove that its actual need for <br>
IPv4 resources can not be satisfied by its <br>
available allocation/assignment, even in <br>
case of a percentage of utilization lower <br>
than 90 %; then notwithstanding the above <br>
requirements, the requesting resource <br>
member shall be *specially considered* <br>
eligible to receive a new allocation or <br>
assignment. <br>
<br>
This *special consideration* shall also <br>
be applicable to a new LIR or End-user, <br>
with similar structural needs in IPv4 <br>
resources. In that case, the given LIR or <br>
End-user shall be *specially considered* <br>
eligible to receive a two allocations or <br>
assignments; to begin with."<br>
<br>
<br></div></div></blockquote><div><br></div><div>I’m confused here. I think you’re reading v1, not the text that I’m proposing for v2.</div><div><br></div><div>Nevertheless, your point seems to be a wording issue, not against the goal. My point to make the wording this way was to avoid changes in the existing text, and adding a new paragraph.</div><div><br></div><br><blockquote type="cite"><div><div text="#000000" bgcolor="#FFFFFF">
<quote><br>
<b>4. References</b><br>
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.<br>
</quote><br>
<br>
...i have found a counter-example to the above <br>
statement; see, brother: <br>
ARIN NRPM <a href="https://www.arin.net/participate/policy/nrpm/#four18" moz-do-not-send="true">Section 4.1.8</a><b>. ARIN Waitlist</b>.<br>
<br>
Do kindly include this precision, to your <br>
"References" section (4.), as you go.<br>
<br></div></div></blockquote><div><br></div><div>We have a waiting list in ARIN, LACNIC and RIPE NCC, but this is not the same as the soft landing.</div><br><blockquote type="cite"><div><div text="#000000" bgcolor="#FFFFFF">
Thanks.<br>
<br>
Shalom,<br>
--sb.
<div dir="auto"><br>
</div>
<div dir="auto"><font size="2"><br>
</font></div>
<br>
<blockquote type="cite" cite="mid:29E79A7F-BF80-44DE-8B67-45521A95F2FB@consulintel.es">
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">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
<a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:RPD@afrinic.net" moz-do-not-send="true">RPD@afrinic.net</a>
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/mailman/listinfo/rpd" moz-do-not-send="true">https://lists.afrinic.net/mailman/listinfo/rpd</a>
</pre>
</blockquote>
<font size="2">[...]<br>
</font><br>
</blockquote>
<br>
<br>
<br>
<div class="moz-signature">-- <br>
<font size="2"><br>
Best Regards !<br>
</font>
<font size="2"><br>
baya.sylvain [AT cmNOG DOT cm] | <br>
<a href="https://www.cmnog.cm/dokuwiki/Structure">cmNOG's
Structure</a> | <a href="https://www.camix.cm/">CAMIX's
Website</a> | <a href="https://tools.std.douala-ix.net/lg">Douala-IX's
Looking Glass</a> | <br>
<a href="https://survey2.cmnog.cm/">cmNOG's Surveys</a> |
Subscribe to <a href="https://lists.cmnog.cm/mailman/listinfo/cmnog">cmNOG's
Mailing List</a> | <br>
__
<br>
#LASAINTEBIBLE|#Ephé<a class="moz-txt-link-freetext" href="siens5:18,15-21%C2%AB">siens5:18,15-21«</a>[...] 18 Et <b><u>ne vous
enivrez</u></b> pas <b><u>de vin</u></b>, en quoi <b><u>il
y a de la dissolution</u></b>; mais <b><u>soyez remplis de
l'Esprit</u></b>, [...]» <br>
#LASAINTEBIBLE|#Hé<a class="moz-txt-link-freetext" href="breux13:9,5-15%C2%AB">breux13:9,5-15«</a>[...] 9 <u><b>Ne soyez pas
seduits par</b></u> des <u><b>doctrines diverses</b></u> et
<u><b>etrangeres</b></u>, car il est bon <u><b>que le coeur
soit affermi par la grace</b></u>, non par les viandes,
lesquels n'ont pas profite à ceux qui y ont marche. [...]»
<br>
#AMEN,#Maranatha,#MerciJÉSUS! #MaPrière est que tu naisses de
nouveau.#Chrétiennement</font><br>
</div>
</div>
<span id="cid:FF858B56-27A3-4726-AA49-3B502C7C8D79"><OpenPGP_0x0387408365AC8594.asc></span></div></blockquote></div><br></div><br>**********************************************<br>
IPv4 is over<br>
Are you ready for the new Internet ?<br>
http://www.theipv6company.com<br>
The IPv6 Company<br>
<br>
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.<br>
<br>
</body></html>