[rpd] Reminder: Deadline for Last Call – Today 23:59 UTC

Fri Jul 31 10:03:29 UTC 2026

Dear PDWG Members,

After reading the proposal, I have a concern about the way the /12 reserve
is handled.

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.

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.

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.

Before the existing /12 reserve is released, I believe the proposal should
clearly explain:

   - Whether the replacement reserve must remain a contiguous /12.
   - Whether fragmented prefixes are acceptable, and if so, what minimum
   requirements they should meet.
   - Whether quarantined addresses can be counted as reserve space.
   - How the reserve will be reflected in AFRINIC's public inventory during
   the transition.

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.

Thank you for considering my comments.

Kind regards,

*Fundiswa Maseko*

On Fri, 31 Jul 2026, 11:40 , <rpd-request at afrinic.net> wrote:

> Send RPD mailing list submissions to
>         rpd at afrinic.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.afrinic.net/mailman/listinfo/rpd
> or, via email, send a message with subject or body 'help' to
>         rpd-request at afrinic.net
>
> You can reach the person managing the list at
>         rpd-owner at afrinic.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of RPD digest..."
>
>
> Today's Topics:
>
>    1. Reminder: Deadline for Last Call ? Today 23:59 UTC.
>       (Hytham El-Nakhal)
>    2.  Reminder: Deadline for Last Call ? Today 23:59 UTC.
>       (Nonjabulo Sphilile)
>    3.  Reminder: Deadline for Last Call ? Today 23:59 UTC.
>       (Tshepo Masuku)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 31 Jul 2026 08:35:56 +0000
> From: Hytham El-Nakhal <hytham at tra.gov.eg>
> To: rpd List <rpd at afrinic.net>
> Subject: [rpd] Reminder: Deadline for Last Call ? Today 23:59 UTC.
> Message-ID: <1785486882136.40622 at tra.gov.eg>
> Content-Type: text/plain; charset="Windows-1252"
>
> Dear PDWG Members,
>
>
> A gentle reminder that the deadline for Last Call phase to submit comments
> on the following policy proposals is 23:59 UTC today;
>
>
> ?       Amendment of Utilisation in Soft Landing
> (AFPUB-2026-IPv4-002-DRAFT02)
> https://www.afrinic.net/afpub-2026-ipv4-002-draft02.html
>
> ?       Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)
>          https://www.afrinic.net/afpub-2026-asn-001-draft02.html
>
> ?       Soft Landing, Recovered Space and Priority
> (AFPUB-2026-IPv4-001-DRAFT02)
> https://www.afrinic.net/afpub-2026-ipv4-001-draft02.html
>
>
> Co-Chairs encourage you to share your comments and contributions within
> the remaining hours.
>
>
> Best regards,
>
> Haitham el Nakhal
>
> PDWG Co-Chair
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 31 Jul 2026 11:14:17 +0200
> From: Nonjabulo Sphilile <nonjabulosphilile at gmail.com>
> To: rpd at afrinic.net
> Subject: [rpd]  Reminder: Deadline for Last Call ? Today 23:59 UTC.
> Message-ID:
>         <
> CAJwHbZOBp0A8X0SQzk79Ks7f-pFhpL_4oy5Nb7boLMjh6HOwTw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Dear PDWG,
>
> I have reviewed AFPUB-2026-IPv4-002-DRAFT02 against the current CPM and the
> concurrent Soft Landing, Recovered Space and Priority proposal. I wish to
> raise one specific issue that does not appear to have been addressed.
>
> DRAFT02 amends only section 5.4.6.1. However, the current CPM contains
> separate utilisation requirements in sections 5.5.1.4.1, 5.5.1.4.2, and
> 5.6.3.
>
> This means an operator could qualify for a waiver from the 90% requirement
> under DRAFT02 but still fail the existing 80% LIR threshold, the rule
> excluding future reservations from valid utilisation, or the separate PI
> utilisation requirements.
>
> The concurrent Soft Landing proposal proposes deleting those provisions,
> and its Impact Assessment says their removal will assist integration of
> this amendment. In contrast, the Impact Assessment for DRAFT02 records no
> interaction with other proposals.
>
> Those positions need to be reconciled.
> Before rough consensus is determined, AFRINIC should publish a combined
> interpretation explaining the outcome where:
> only AFPUB-2026-IPv4-002 is adopted;
> only AFPUB-2026-IPv4-001 is adopted;
> both are adopted;
> and the two are implemented on different dates.
>
> The treatment of future utilisation also remains undefined. If an
> allocation granted under the waiver is intentionally underutilised for
> redundancy or high availability, will it form part of ?all prior
> allocations or assignments? when the operator submits its next request?
> If it remains in the denominator, one waiver may create continuing
> dependence on further waivers. If it is excluded, the proposal creates a
> separate class of resources outside the normal utilisation calculation. The
> policy currently states neither result.
>
> There is also a timing issue in relying on approximately three million
> recovered addresses to justify the change. Recovered inventory is not
> necessarily immediately allocable inventory. The effective date should be
> supported by the amount actually available after quarantine and by a demand
> and depletion analysis.
>
> These are not demands that the proposal solve every possible future
> problem. They concern the rule that applicants and Hostmasters will
> actually be required to apply from the implementation date.
> A policy governing a finite pool should be internally consistent,
> measurable, and capable of producing the same result from the same facts.
> At present, DRAFT02 depends on another unresolved proposal, leaves future
> utilisation accounting undefined, and relies on inventory that may not yet
> be available.
>
> For these reasons, I do not believe the proposal is ready to advance and I
> object it.
>
> Regards,
> Nonjabulo
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.afrinic.net/pipermail/rpd/attachments/20260731/8592c846/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Fri, 31 Jul 2026 09:40:14 +0000
> From: Tshepo Masuku <TshepoMasuku26 at hotmail.com>
> To: "rpd at afrinic.net" <rpd at afrinic.net>, "pdwg-chairs at afrinic.net"
>         <pdwg-chairs at afrinic.net>
> Subject: [rpd]  Reminder: Deadline for Last Call ? Today 23:59 UTC.
> Message-ID:
>         <
> DB7PR04MB59934C6F1B4BB50440CF6A95CAC82 at DB7PR04MB5993.eurprd04.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="windows-1252"
>
> Dear PDWG,
>
> I wish to raise a separate implementation concern arising from the Impact
> Assessment after reviewing the Soft Landing, Recovered Space and Priority
> Policy.
>
> 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.
>
> These positions require clarification.
> 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.
>
> 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.
> 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:
>
> #which data sources determine whether a prefix is considered cleaned;
> #whether transitions are automatic or require human approval;
> #what happens when data are missing or inconsistent;
> #whether the system fails closed when a check cannot be completed;
> #who may override an automated result;
> #how changes to the tool?s decision rules will be reviewed;
> #or how every release decision will be audited and reproduced.
>
> These are not minor implementation details if they determine whether
> scarce IPv4 space becomes available for allocation. They are part of the
> substantive rule.
>
> Before the proposal advances, the Impact Assessment should be updated to
> identify the tool as an affected system and publish at least:
> its functional scope and authoritative data sources;
> the exact decisions it may make automatically;
> its human approval and override controls;
> its failure and rollback behaviour;
> its versioning and change-control process;
> test cases demonstrating the intended outcomes; and
> an auditable record of each decision affecting resource availability.
> No prefix should become allocable solely because an unpublished internal
> workflow classified it as clean.
>
> Otherwise, the community approves broad policy language while the real
> allocation rules are written later in software outside the PDP.
>
> That is not implementation of policy. It is policy being created through
> implementation.
> For this reason, I do not believe the current Impact Assessment is
> sufficient, and I remain opposed to the proposal advancing as written.
>
> Regards,
> Tshepo
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.afrinic.net/pipermail/rpd/attachments/20260731/16b45b17/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>
>
> ------------------------------
>
> End of RPD Digest, Vol 222, Issue 238
> *************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260731/776c3c5f/attachment-0001.html>