[rpd] Reminder: Deadline for Last Call – Today 23:59 UTC: Soft Landing, Recovered Space and Priority (AFPUB-2026-IPv4-001-DRAFT02)

[Phetulo Dhlamini]

Dear PDWG,

I wish to raise one specific concern regarding AFPUB-2026-IPv4-001-DRAFT02.

The proposal’s own problem statement notes that some Resource Members have
received more than eight separate /22 allocations within a calendar year.
However, the proposal does not change the mechanism that permits repeated
requests. Instead, it places recovered IPv4 space, and potentially the
reserved /12, into the same allocation framework.

A /22 limit per request is not a cumulative safeguard. One organisation may
satisfy the applicable criteria several times and receive multiple /22s
over a relatively short period. No fraud or policy breach is required. The
present structure simply allows repeated access to a finite pool.

This creates a concentration risk. Larger organisations with established
application processes, staff capacity, and continuous deployment pipelines
may repeatedly return for additional space, while smaller or newer networks
compete for whatever remains. Adding recovered addresses to the same
mechanism may extend the life of the pool, but it does not ensure broader
or more predictable access to it.

The solution should not be subjective staff judgment about which applicant
is more deserving. That would merely replace one problem with another
permission layer. Any safeguard should be automatic, published, and capable
of producing the same result from the same facts.

Before recovered space is released, the policy should therefore include an
objective free-pool distribution rule, such as:

a published rolling cumulative limit per organisation;

one active request per organisation at a time;

a defined interval before a repeat applicant may receive another
allocation; or

a round-based queue in which otherwise valid applicants who have not
recently received space are considered before repeat recipients.


The precise mechanism and threshold should be supported by published
allocation and demand data. AFRINIC should also publish aggregate
statistics showing the concentration of Phase 2 and recovered-space
allocations, without exposing applicants’ confidential operational
information.

For clarity, any cumulative limit or sequencing mechanism should apply only
to allocations from AFRINIC’s remaining unallocated free pool. It must not
create continuing restrictions over resources after allocation, and it must
not be extended to transfers, leasing, routing, customer geography,
commercial use, or other operator decisions. It should expire automatically
when the free pool is exhausted.

The purpose is not to give AFRINIC greater discretion. It is to prevent
repeated applications from becoming an administrative race through which a
small number of organisations consume a finite pool before other valid
requests can be considered.

DRAFT02 identifies repeated allocations as part of the problem, but leaves
the enabling mechanism unchanged. Releasing millions of recovered addresses
into that same process does not resolve the issue. It simply gives the
process more inventory.

For this reason, I do not believe the proposal is ready to advance in its
current form, and I maintain my objection.

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