<div dir="auto">Dear PDWG,<div dir="auto"><br></div><div dir="auto">I wish to raise one specific concern regarding AFPUB-2026-IPv4-001-DRAFT02.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Before recovered space is released, the policy should therefore include an objective free-pool distribution rule, such as:</div><div dir="auto"><br></div><div dir="auto">a published rolling cumulative limit per organisation;</div><div dir="auto"><br></div><div dir="auto">one active request per organisation at a time;</div><div dir="auto"><br></div><div dir="auto">a defined interval before a repeat applicant may receive another allocation; or</div><div dir="auto"><br></div><div dir="auto">a round-based queue in which otherwise valid applicants who have not recently received space are considered before repeat recipients.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">For this reason, I do not believe the proposal is ready to advance in its current form, and I maintain my objection.</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Phetulo</div></div>