<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="line-height: 120%; margin: 0in 0in 8pt; font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<b>Dear Jordi, Co-Chairs, and fellow PDWG members,</b></div>
<div class="elementToProof" style="line-height: 120%; margin: 0in 0in 8pt; font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thank you for this proposal — the technical rationale is sound and I support the intent.</div>
<div class="elementToProof" style="line-height: 120%; margin: 0in 0in 8pt; font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
That said, I have one focused concern: the waiver mechanism as drafted is broad enough to be systematically abused, as the qualifying categories are self-declared with no verification requirement in the policy text.</div>
<div class="elementToProof" style="line-height: 120%; margin: 0in 0in 8pt; font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
To address this, I suggest four improvements:</div>
<ol start="1" data-editing-info="{"orderedStyleType":1}" style="margin-top: 0in; margin-right: 0in; list-style-type: decimal;">
<li style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); line-height: normal; margin: 0in 0in 8pt;">
<b>Require documented justification</b> — applicants should submit supporting technical documentation to AFRINIC staff before the waiver is activated</li><li style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); line-height: normal; margin: 0in 0in 8pt;">
<b>Cap waiver-based allocations</b> — limit to one per member per 12-month period to prevent repeated invocations across rolling "new sites"</li><li style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); line-height: normal; margin: 0in 0in 8pt;">
<b>Post-allocation follow-up</b> — require utilisation reporting within 12 months, with reclamation if the stated deployment has not materialised</li><li style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0); line-height: normal; margin: 0in 0in 8pt;">
<b>Condition on IPv6 co-deployment</b> — require the requesting member to hold an active IPv6 allocation, ensuring the waiver supports transition rather than extending IPv4-only operations</li></ol>
<div class="elementToProof" style="line-height: 120%; margin: 0in 0in 8pt; font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I support this proposal with the above amendments and am happy to assist in drafting the updated text if required.</div>
<div class="elementToProof" style="line-height: 120%; margin: 0in 0in 8pt; font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="line-height: 120%; margin: 0in 0in 8pt; font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
With Regards.</div>
<div class="elementToProof" style="line-height: 120%; margin: 0in 0in 8pt; font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<b>Sami Salih.</b></div>
<b></b>
<hr style="display: inline-block; width: 98%;">
<div id="divRplyFwdMsg">
<div style="direction: ltr; font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<b>From: jordi.palet--- via RPD <rpd@afrinic.net><br>
Sent: Thursday, May 21, 2026 6:01 PM<br>
To: rpd@afrinic.net <rpd@afrinic.net><br>
Subject: Re: [rpd] New Draft Policy Proposal - Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT01.</b></div>
<div style="direction: ltr;"><b> </b></div>
</div>
<div><b>I will be happy myself with the text changes that you proposed.</b></div>
<div><b><br>
</b></div>
<div><b>Let’s make sure other folks agree/disagree and specially it will be awesome to get a confirmation from the staff that this doesn’t create excessive burden to them for the evaluation of the request, and we don’t miss the deadline for a v2.</b></div>
<div><b><br>
</b></div>
<div><b>Tks!</b></div>
<div><b><br>
</b></div>
<div><b>Regards,<br>
Jordi<br>
<br>
@jordipalet<br>
<br>
</b></div>
<div><b><br>
</b></div>
<blockquote>
<div><b>El 21 may 2026, a las 16:56, Jaco Kroon <jaco@uls.co.za> escribió:</b></div>
<div><b><br>
</b></div>
<p style="margin-top: 1em; margin-bottom: 1em;"><b>Hi,</b></p>
<div><b>On 2026/05/21 16:36, jordi.palet--- via RPD wrote:</b></div>
<blockquote>
<div><b>Hi and tks again,</b></div>
<div><b><br>
</b></div>
<div><b>I see your point that seems to easy, but we shall remember that you need to demonstrate the need to Afrinic *every time* you do a request. So if you say, I will build not 1 but 3 DCs, you will need to show contracts, right?</b></div>
<div><b><br>
</b></div>
<div><b>Is the same as when you request a bigger address block than what policies dictate, you need to justify the need, have network diagrams, etc.. If you need to deploy 4 NAT64 PoPs, you need to show the contracts, even the invoices for the NAT64 boxes,
etc.</b></div>
</blockquote>
<div><b>Well, right now I don't think you can get more than /22 no matter how well you can illustrate that. I would not mind being able to consolidate the resources that I have into a single block, however, there's one black that would be exceptionally hard
to renumber (And I believe this is part of your point about renumbering).</b></div>
<blockquote>
<div><b><br>
</b></div>
<div><b>All that are operational details, with don’t go into policy text. We want to avoid micromanagement of the RIR as much as possible, only got into the details if they are going to (clearly) do it wrong (or done wrong already previously).</b></div>
</blockquote>
<div><b>I agree. But we also want policy to be clear so as to avoid misinterpretation - accidentally or otherwise.</b></div>
<blockquote>
<div><b><br>
</b></div>
<div><b>If a request for 4 /24 for 4 NAT64 PoPs is fraudulent, the service agreement already enable Afrinic to review that and reclaim the space. I don’t think in general, people want to break rules on purpose.</b></div>
</blockquote>
<div><b>Agree, I expect most people to be rule-abiding and well-intentioned individuals.</b></div>
<blockquote>
<div><b><br>
</b></div>
<div><b>Also I think asking for demonstrating that it can’t be done with renumbering is too expensive (just the exercise to analyze is it often a big hurdle), renumbering is extremely hard, and imposing this may go against some IPv6 deployments “the deployment
cost me x and also I need to check if I can do it with renumbering first, then I just do with the renumbering, at least for some time”.</b></div>
</blockquote>
<div><b>Ok.</b></div>
<blockquote>
<div><b><br>
</b></div>
<div><b>****** Now, if the staff believes that they need some explicit text to demonstrate the need, please say so before the policy proposal submission deadline, because in that case, we still have time to incorporate that text into a v2.</b></div>
<div><b><br>
</b></div>
<div><b>May be something such as:</b></div>
<div><b><br>
</b></div>
<div><b>“</b><span style="font-family: -apple-system, system-ui, "Segoe UI", Roboto, Helvetica, Arial, sans-serif; color: rgb(209, 94, 20); background-color: rgb(255, 255, 255);"><b>The above requirement is waived for network operators requesting new IP addresses
for </b></span><b>demonstrated</b><span style="font-family: -apple-system, system-ui, "Segoe UI", Roboto, Helvetica, Arial, sans-serif; color: rgb(209, 94, 20); background-color: rgb(255, 255, 255);"><b> 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.</b></span><b>"</b></div>
</blockquote>
<p style="margin-top: 1em; margin-bottom: 1em;"><b>How about:<br>
<br>
“</b><span style="font-family: -apple-system, system-ui, "Segoe UI", Roboto, Helvetica, Arial, sans-serif; color: rgb(209, 94, 20); background-color: rgb(255, 255, 255);"><b>The above requirement is waived for network operators requesting new
</b></span><span style="font-family: -apple-system, system-ui, "Segoe UI", Roboto, Helvetica, Arial, sans-serif; background-color: rgb(255, 255, 255);"><b>IPv4</b></span><span style="font-family: -apple-system, system-ui, "Segoe UI", Roboto, Helvetica, Arial, sans-serif; color: rgb(209, 94, 20); background-color: rgb(255, 255, 255);"><b> addresses
for </b></span><b>demonstrated</b><span style="font-family: -apple-system, system-ui, "Segoe UI", Roboto, Helvetica, Arial, sans-serif; color: rgb(209, 94, 20); background-color: rgb(255, 255, 255);"><b> key technical
</b></span><span style="font-family: -apple-system, system-ui, "Segoe UI", Roboto, Helvetica, Arial, sans-serif; background-color: rgb(255, 255, 255);"><b>requirements, which can be illustrated to not be practically serviceable from existing assigned/allocated
IPv4 resources</b></span><span style="font-family: -apple-system, system-ui, "Segoe UI", Roboto, Helvetica, Arial, sans-serif; color: rgb(209, 94, 20); background-color: rgb(255, 255, 255);"><b> – 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.</b></span><b>"</b></p>
<p style="margin-top: 1em; margin-bottom: 1em;"><b>As you say, there could be practical limitations that could potentially be alleviated by renumbering but where it isn't practical to do so, so I believe this hits more the middle ground, I hope.</b></p>
<blockquote>
<div><b><br>
</b></div>
<div><b>Repeating myself:</b></div>
<div><b>I think overall, this way to approach what do to with the recovered space helps Africa to improve Internet penetration tied to IPv6 deployment, specially because dual-stack is not longer possible, so this helps IPv6 + IPv4aaS, so it is clearly in support
of IPv6 deployment.</b></div>
</blockquote>
<p style="margin-top: 1em; margin-bottom: 1em;"><b>I agree. I just feel extremely sorry for those entities that were forced to approach leasing entities in order to obtain some IPv4 space that may now have that space revoked again ... refer to the other discussion.<br>
<br>
Appreciate the discussion, use it don't use it, I think this is fine as is, my preference has been made known.</b></p>
<p style="margin-top: 1em; margin-bottom: 1em;"><b>Kind regards,<br>
Jaco</b></p>
</blockquote>
<div><b><br>
</b></div>
<div><b><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>
</b></div>
</body>
</html>