<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;"><div dir="auto" style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi Fundiswa,<div><br></div><div>No, there is no difference, because AFRINIC can only allocate as much as /22, so nobody will get an allocation or assignment disaggregated.</div><div><br></div><div>Also, note that the proposal doesn’t enter into operational details, so the exact way of what chunks of recovered space replace that reserve, is up to the staff.</div><div><br></div><div>Finally, the existing CPM doesn’t state “contiguos”. I actually don’t know if this is the case. Nevertheless, as stated above, it doesn’t change the results of future allocations or assignments.</div><div><br></div><div>For the quarantine details, as I said in a previous email, and also reported by the staff, it is an operational procedure and not part of the policy proposal text.</div><div><br id="lineBreakAtBeginningOfMessage"><div>
<div>Regards,<br>Jordi<br><br>@jordipalet<br></div>
</div>
<div><br><blockquote type="cite"><div>El 31 jul 2026, a las 12:03, Fundiswa Nadia Maseko <fundiswanadia2@gmail.com> escribió:</div><br class="Apple-interchange-newline"><div><div dir="auto">Dear PDWG Members,<div dir="auto"><div dir="auto"><p>After reading the proposal, I have a concern about the way the /12 reserve is handled.</p><p>The current policy keeps a contiguous /12 set aside for future needs. The proposal suggests releasing that reserve and replacing it with recovered IPv4 space. While the total number of addresses may be the same, I'm not sure this provides the same practical value.</p><p>A single contiguous /12 offers flexibility for future allocations and routing. If it is replaced with smaller recovered prefixes, even if they add up to the same number of addresses, that doesn't necessarily provide the same capability. I think this distinction is important and should be addressed more clearly in the proposal.</p><p>I'm also unsure about how quarantined address space is being treated. If addresses are still in quarantine, should they already be considered part of the reserve? It would help if the policy clearly explained when address space moves between recovered, quarantined, available, reserved and delegated states. Each prefix should only exist in one state at a time so that the inventory remains clear and transparent.</p><p>Before the existing /12 reserve is released, I believe the proposal should clearly explain:</p>
<ul><li>Whether the replacement reserve must remain a contiguous /12.</li><li>Whether fragmented prefixes are acceptable, and if so, what minimum requirements they should meet.</li><li>Whether quarantined addresses can be counted as reserve space.</li><li>How the reserve will be reflected in AFRINIC's public inventory during the transition.</li></ul><p>The reserve exists to preserve future operational flexibility, not just to keep the same number of IPv4 addresses on record. Until these points are clarified, I have concerns about the proposed release and replacement mechanism.</p><p>Thank you for considering my comments.</p><p>Kind regards,</p><p><strong>Fundiswa Maseko</strong></p></div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, 31 Jul 2026, 11:40 , <<a href="mailto:rpd-request@afrinic.net">rpd-request@afrinic.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Send RPD mailing list submissions to<br>
<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:rpd-request@afrinic.net" target="_blank" rel="noreferrer">rpd-request@afrinic.net</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:rpd-owner@afrinic.net" target="_blank" rel="noreferrer">rpd-owner@afrinic.net</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of RPD digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Reminder: Deadline for Last Call ? Today 23:59 UTC.<br>
(Hytham El-Nakhal)<br>
2. Reminder: Deadline for Last Call ? Today 23:59 UTC.<br>
(Nonjabulo Sphilile)<br>
3. Reminder: Deadline for Last Call ? Today 23:59 UTC.<br>
(Tshepo Masuku)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 31 Jul 2026 08:35:56 +0000<br>
From: Hytham El-Nakhal <<a href="mailto:hytham@tra.gov.eg" target="_blank" rel="noreferrer">hytham@tra.gov.eg</a>><br>
To: rpd List <<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>><br>
Subject: [rpd] Reminder: Deadline for Last Call ? Today 23:59 UTC.<br>
Message-ID: <<a href="mailto:1785486882136.40622@tra.gov.eg" target="_blank" rel="noreferrer">1785486882136.40622@tra.gov.eg</a>><br>
Content-Type: text/plain; charset="Windows-1252"<br>
<br>
Dear PDWG Members,<br>
<br>
<br>
A gentle reminder that the deadline for Last Call phase to submit comments on the following policy proposals is 23:59 UTC today;<br>
<br>
<br>
? Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02) <a href="https://www.afrinic.net/afpub-2026-ipv4-002-draft02.html" rel="noreferrer noreferrer" target="_blank">https://www.afrinic.net/afpub-2026-ipv4-002-draft02.html</a><br>
<br>
? Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) <a href="https://www.afrinic.net/afpub-2026-asn-001-draft02.html" rel="noreferrer noreferrer" target="_blank">https://www.afrinic.net/afpub-2026-asn-001-draft02.html</a><br>
<br>
? Soft Landing, Recovered Space and Priority (AFPUB-2026-IPv4-001-DRAFT02) <a href="https://www.afrinic.net/afpub-2026-ipv4-001-draft02.html" rel="noreferrer noreferrer" target="_blank">https://www.afrinic.net/afpub-2026-ipv4-001-draft02.html</a><br>
<br>
<br>
Co-Chairs encourage you to share your comments and contributions within the remaining hours.<br>
<br>
<br>
Best regards,<br>
<br>
Haitham el Nakhal<br>
<br>
PDWG Co-Chair<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 31 Jul 2026 11:14:17 +0200<br>
From: Nonjabulo Sphilile <<a href="mailto:nonjabulosphilile@gmail.com" target="_blank" rel="noreferrer">nonjabulosphilile@gmail.com</a>><br>
To: <a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a><br>
Subject: [rpd] Reminder: Deadline for Last Call ? Today 23:59 UTC.<br>
Message-ID:<br>
<<a href="mailto:CAJwHbZOBp0A8X0SQzk79Ks7f-pFhpL_4oy5Nb7boLMjh6HOwTw@mail.gmail.com" target="_blank" rel="noreferrer">CAJwHbZOBp0A8X0SQzk79Ks7f-pFhpL_4oy5Nb7boLMjh6HOwTw@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Dear PDWG,<br>
<br>
I have reviewed AFPUB-2026-IPv4-002-DRAFT02 against the current CPM and the<br>
concurrent Soft Landing, Recovered Space and Priority proposal. I wish to<br>
raise one specific issue that does not appear to have been addressed.<br>
<br>
DRAFT02 amends only section 5.4.6.1. However, the current CPM contains<br>
separate utilisation requirements in sections 5.5.1.4.1, 5.5.1.4.2, and<br>
5.6.3.<br>
<br>
This means an operator could qualify for a waiver from the 90% requirement<br>
under DRAFT02 but still fail the existing 80% LIR threshold, the rule<br>
excluding future reservations from valid utilisation, or the separate PI<br>
utilisation requirements.<br>
<br>
The concurrent Soft Landing proposal proposes deleting those provisions,<br>
and its Impact Assessment says their removal will assist integration of<br>
this amendment. In contrast, the Impact Assessment for DRAFT02 records no<br>
interaction with other proposals.<br>
<br>
Those positions need to be reconciled.<br>
Before rough consensus is determined, AFRINIC should publish a combined<br>
interpretation explaining the outcome where:<br>
only AFPUB-2026-IPv4-002 is adopted;<br>
only AFPUB-2026-IPv4-001 is adopted;<br>
both are adopted;<br>
and the two are implemented on different dates.<br>
<br>
The treatment of future utilisation also remains undefined. If an<br>
allocation granted under the waiver is intentionally underutilised for<br>
redundancy or high availability, will it form part of ?all prior<br>
allocations or assignments? when the operator submits its next request?<br>
If it remains in the denominator, one waiver may create continuing<br>
dependence on further waivers. If it is excluded, the proposal creates a<br>
separate class of resources outside the normal utilisation calculation. The<br>
policy currently states neither result.<br>
<br>
There is also a timing issue in relying on approximately three million<br>
recovered addresses to justify the change. Recovered inventory is not<br>
necessarily immediately allocable inventory. The effective date should be<br>
supported by the amount actually available after quarantine and by a demand<br>
and depletion analysis.<br>
<br>
These are not demands that the proposal solve every possible future<br>
problem. They concern the rule that applicants and Hostmasters will<br>
actually be required to apply from the implementation date.<br>
A policy governing a finite pool should be internally consistent,<br>
measurable, and capable of producing the same result from the same facts.<br>
At present, DRAFT02 depends on another unresolved proposal, leaves future<br>
utilisation accounting undefined, and relies on inventory that may not yet<br>
be available.<br>
<br>
For these reasons, I do not believe the proposal is ready to advance and I<br>
object it.<br>
<br>
Regards,<br>
Nonjabulo<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20260731/8592c846/attachment-0001.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20260731/8592c846/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 31 Jul 2026 09:40:14 +0000<br>
From: Tshepo Masuku <<a href="mailto:TshepoMasuku26@hotmail.com" target="_blank" rel="noreferrer">TshepoMasuku26@hotmail.com</a>><br>
To: "<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>" <<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>>, "<a href="mailto:pdwg-chairs@afrinic.net" target="_blank" rel="noreferrer">pdwg-chairs@afrinic.net</a>"<br>
<<a href="mailto:pdwg-chairs@afrinic.net" target="_blank" rel="noreferrer">pdwg-chairs@afrinic.net</a>><br>
Subject: [rpd] Reminder: Deadline for Last Call ? Today 23:59 UTC.<br>
Message-ID:<br>
<<a href="mailto:DB7PR04MB59934C6F1B4BB50440CF6A95CAC82@DB7PR04MB5993.eurprd04.prod.outlook.com" target="_blank" rel="noreferrer">DB7PR04MB59934C6F1B4BB50440CF6A95CAC82@DB7PR04MB5993.eurprd04.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="windows-1252"<br>
<br>
Dear PDWG,<br>
<br>
I wish to raise a separate implementation concern arising from the Impact Assessment after reviewing the Soft Landing, Recovered Space and Priority Policy.<br>
<br>
The assessment records no impact on WHOIS, RDAP, MyAFRINIC, NetSuite, NMRP, RPKI, or IT. However, it also requires AFRINIC to introduce an automated cleanup and monitoring tool and allows six months for implementation of that workflow.<br>
<br>
These positions require clarification.<br>
If the proposed tool merely observes recovered resources, then it is unclear how it will implement or enforce the movement of resources from quarantine into the available pool.<br>
<br>
If the tool can change a prefix?s status, release it from quarantine, place it in reserve, or make it eligible for allocation, then it is a new operational control system. In that case, the conclusion that there is no systems or IT impact appears incomplete.<br>
The more important concern is that the policy does not define the decision logic that the automation will execute. The community has not been told:<br>
<br>
#which data sources determine whether a prefix is considered cleaned;<br>
#whether transitions are automatic or require human approval;<br>
#what happens when data are missing or inconsistent;<br>
#whether the system fails closed when a check cannot be completed;<br>
#who may override an automated result;<br>
#how changes to the tool?s decision rules will be reviewed;<br>
#or how every release decision will be audited and reproduced.<br>
<br>
These are not minor implementation details if they determine whether scarce IPv4 space becomes available for allocation. They are part of the substantive rule.<br>
<br>
Before the proposal advances, the Impact Assessment should be updated to identify the tool as an affected system and publish at least:<br>
its functional scope and authoritative data sources;<br>
the exact decisions it may make automatically;<br>
its human approval and override controls;<br>
its failure and rollback behaviour;<br>
its versioning and change-control process;<br>
test cases demonstrating the intended outcomes; and<br>
an auditable record of each decision affecting resource availability.<br>
No prefix should become allocable solely because an unpublished internal workflow classified it as clean.<br>
<br>
Otherwise, the community approves broad policy language while the real allocation rules are written later in software outside the PDP.<br>
<br>
That is not implementation of policy. It is policy being created through implementation.<br>
For this reason, I do not believe the current Impact Assessment is sufficient, and I remain opposed to the proposal advancing as written.<br>
<br>
Regards,<br>
Tshepo<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20260731/16b45b17/attachment.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20260731/16b45b17/attachment.html</a>><br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" target="_blank" rel="noreferrer">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
<br>
<br>
------------------------------<br>
<br>
End of RPD Digest, Vol 222, Issue 238<br>
*************************************<br>
</blockquote></div>
_______________________________________________<br>RPD mailing list<br>RPD@afrinic.net<br>https://lists.afrinic.net/mailman/listinfo/rpd<br></div></blockquote></div><br></div></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>