<div dir="auto">Dear Jordi and colleagues,<div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">Consider an operator with existing space below 90% utilisation:</div><div dir="auto"><br></div><div dir="auto">it requests a /22 for a new site and receives a waiver;</div><div dir="auto"><br></div><div dir="auto">it later requests another /22 for a second site and receives another waiver;</div><div dir="auto"><br></div><div dir="auto">it then requests further space for high availability or a transition mechanism.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">At minimum, the policy should require that:</div><div dir="auto"><br></div><div dir="auto">a previous waiver allocation be demonstrably deployed before another waiver is considered;</div><div dir="auto"><br></div><div dir="auto">cumulative waiver allocations be subject to a defined limit or waiting period;</div><div dir="auto"><br></div><div dir="auto">waiver processing be suspended when the available pool reaches an objective threshold; and</div><div dir="auto"><br></div><div dir="auto">AFRINIC publish aggregate figures showing the number, purpose, and pool impact of approved waivers.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">This is not a demand for a perfect policy. It is a request that the policy control the recurrence mechanism it expressly creates.</div><div dir="auto"><br></div><div dir="auto">For this reason, I remain opposed to AFPUB-2026-IPv4-002-DRAFT02 as presently written.</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Nonjabulo</div></div>