[rpd] [Last Call] Draft Policy Proposal - Soft Landing, Recovered Space and Priority (AFPUB-2026-IPv4-001-DRAFT02)

[NP Petronella]

Dear Co-chairs and colleagues,

Thank you to Gregoire and Alain for their thoughtful interventions. Read together, their comments expose an important issue that should be resolved before DRAFT02 advances.

Alain is correct to point out that section 5.4.3 of the current CPM already applies the Exhaustion Phase rules to all IPv4 space allocated, assigned, or otherwise managed by AFRINIC, regardless of whether that space originated from the Final /8.

On that reading, recovered IPv4 space is not sitting in a policy vacuum. The existing CPM already supplies a default rule.
This changes the nature of the discussion. DRAFT02 cannot simultaneously be presented as urgently “filling a gap” and as merely confirming what the CPM already requires.
If the proposal simply restates section 5.4.3, then it is unnecessary. If it does more than restate the existing rule, then those additional provisions must be justified as substantive policy changes.

DRAFT02 does substantially more. It:
declares Soft Landing phases final and irreversible;
requires all returned or recovered resources, regardless of their original pool, to enter the available-space framework;
gives AFRINIC discretion to shorten the quarantine period for broadly described operational reasons;
permits the existing /12 reserve to be released and replaced with recovered space, including space still under quarantine;
gives the Soft Landing section priority over other CPM allocation criteria; and
removes or changes several provisions that go beyond the narrow question of recovered-space treatment.

These are not merely clarifications of section 5.4.3. They alter the policy architecture governing a finite and economically significant body of IPv4 resources.
Gregoire’s reference to the Dynamic IPv4 Pools Exhaustion Management Framework is therefore directly relevant. The Working Group is not choosing between “DRAFT02” and “no rule.” The current CPM already provides an interim rule.

The real choice is whether recovered space should remain subject to the existing default or be governed through a more specific framework with separate pools, clearer controls, and defined anti-abuse safeguards.

There is also no necessary reason why applying existing Phase 2 allocation criteria must erase the provenance or separate accounting of recovered resources. AFRINIC could continue recording recovered prefixes as a distinct inventory class while the community evaluates the long-term framework.

That would preserve policy optionality.
Once recovered prefixes are fully commingled with the ordinary Phase 2 pool and allocated, the community cannot later reconstruct a dedicated recovered-space pool without affecting operationally embedded allocations. A future policy may remain procedurally possible, but the resources already distributed will no longer be available to it.

This is the distinction between changing policy later and preserving the ability to make a meaningful choice later.
Before DRAFT02 proceeds, I suggest that the co-chairs request:
a clause-by-clause explanation of what DRAFT02 changes beyond existing section 5.4.3;
a comparative assessment of DRAFT02 and the Dynamic Framework, including depletion, concentration, reserve integrity, anti-abuse controls, and operational complexity;
separate and auditable reporting of recovered-space inventory and allocations; and
clarification of which provisions are genuinely necessary to answer the recovered-space question and which should be considered through separate proposals.

A policy should not duplicate an existing rule and then use that duplication to introduce irreversibility, supremacy, and additional administrative discretion around it.

The safer approach is to preserve the existing default while the community compares the available models using actual inventory and allocation data. That protects the remaining IPv4 resources without prematurely locking them into one institutional framework.

For these reasons, I support the concerns raised by both Gregoire and Alain, and I object to AFPUB-2026-IPv4-001-DRAFT02 advancing in its current form.

Regards,
Nonhlanhla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260731/3fed5685/attachment-0001.html>