[rpd] [Last Call] Draft Policy Proposal- Amendment of Utilisation in Soft Landing AFPUB-2026-IPv4-002-DRAFT02

[Nonjabulo Sphilile]

Dear Jordi and colleagues,

Thank you for the clarification. I want to focus on one issue that is
separate from MDN and from the broader debate over the definition of
utilisation.

You say that only the “relevant request” is treated as a first request.
That does not resolve the concern. It confirms that the waiver operates
independently for each request.

Nothing in the proposal prevents the same operator from later submitting
another qualifying request for a different site, another redundancy
deployment, or another IPv6 transition mechanism. The existing CPM also
places no explicit limit on the number of additional requests an
organisation may submit during the Exhaustion Phase.

Consider an operator with existing space below 90% utilisation:

it requests a /22 for a new site and receives a waiver;

it later requests another /22 for a second site and receives another waiver;

it then requests further space for high availability or a transition
mechanism.


Each request may be genuine, properly documented, and individually
compliant. No fraud is required. Yet the operator can continue receiving
additional space while remaining below the aggregate utilisation threshold
that ordinarily protects the remaining pool.

This is why the staff anti-abuse procedure does not answer the concern.
Fraud controls deal with false claims. They do not control cumulative
demand arising from several legitimate claims.

The proposal also contains no requirement that resources received under an
earlier waiver must first be deployed for their stated purpose before
another waiver may be granted. It evaluates an intended plan at the time of
application, but provides no later checkpoint if the project is delayed,
cancelled, or materially changed.

That matters in a finite, first-come-first-served pool. Every legitimate
waiver still reduces the space available to new entrants and to operators
that have actually reached 90% utilisation. The proposal relies on the
recovery of approximately three million addresses to argue that there will
be no immediate drain, but it provides no demand model, cumulative limit,
inventory trigger, or sunset mechanism.

At minimum, the policy should require that:

a previous waiver allocation be demonstrably deployed before another waiver
is considered;

cumulative waiver allocations be subject to a defined limit or waiting
period;

waiver processing be suspended when the available pool reaches an objective
threshold; and

AFRINIC publish aggregate figures showing the number, purpose, and pool
impact of approved waivers.


The precise limits can follow a staff demand analysis. What should not
happen is adopting a repeatable exception first and discovering its
aggregate effect only after the remaining pool has been consumed.

This is not a demand for a perfect policy. It is a request that the policy
control the recurrence mechanism it expressly creates.

For this reason, I remain opposed to AFPUB-2026-IPv4-002-DRAFT02 as
presently written.

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