Summary

  • AFRINIC’s D2 proposal would keep 90% utilisation as the default for an additional Exhaustion Phase IPv4 request, but let staff waive it for a sufficiently documented key technical purpose that existing address space cannot practicably serve or that constrains the existing pool.
  • The defect D2 addresses is real: a four-PoP design, a separate data centre, high availability or NAT64/464XLAT may require a routable, failure-isolated prefix while aggregate use remains below 90%. Denial can impose renumbering, delay, provider dependence, leasing or purchase costs; an over-broad approval consumes scarcity that later applicants cannot receive.
  • D2 was still under discussion on 9 August 2026. Its Last Call had closed, but the sealed record contained no final co-chair consensus decision, Board ratification or implementation. The proposal is therefore an institutional act under review, not policy already in force.
  • The proposal is incomplete because its qualifying terms are open, repeated waivers are intended but uncapped, other live utilisation clauses are unreconciled, written reasons are not required and no tailored merits appeal is specified. The technical exception should survive, but only inside objective, auditable boundaries.

Imagine an operator preparing a fourth point of presence. Each site needs a globally routable /24 so that a failure at one location does not collapse the others into the same dependency. The first three prefixes are deliberately sparse: their job is separation, not dense host packing. Under AFRINIC’s current Exhaustion Phase rule, the operator must have used at least 90% of all previous allocations or assignments before it can receive another. Four /24s contain the same 1,024 addresses as a /22, the Phase 2 maximum for one request.

Yet the proposed fourth site can be technically necessary even when the older pools do not look full in aggregate.

That exact conflict is the reason AFPUB-2026-IPv4-002-DRAFT02 exists. Submitted in its first version on 6 May 2026 and published as Version 2 on 16 June, D2 proposes to amend only section 5.4.6.1 of the AFRINIC Consolidated Policy Manual. It would retain the 90% condition, retain the exemption for the first request by a new LIR or End User, and add a waiver for a documented key technical purpose. The request covered by the waiver would be treated as a first request for that provision. The proposal’s examples—redundancy, high availability, IPv6 transition mechanisms and expansion to new sites—are expressly non-limiting.

The engineering defect is real. So is the distributional choice. If AFRINIC refuses a technically necessary prefix, the operator may have to renumber, share an unsuitable failure domain, delay a facility, depend on provider space, deploy additional translation infrastructure, lease IPv4 or buy it. If AFRINIC approves a weak case, the cost falls on later applicants through a smaller residual pool. If decisions depend on who can produce the most polished diagrams, contracts and explanations, proof capacity—not technical necessity—becomes an allocation advantage. D2 is therefore not a minor exception to an administrative ratio.

It is a proposal to decide who receives an economically valuable /24-to-/22 allocation and who absorbs the cost of denial.

At the evidence cutoff, that choice had not been settled. The co-chairs declared rough consensus at AFRINIC-37 on 24 June and opened Last Call on 16 July through 31 July. Last Call closed at 23:59 UTC on that date. On 1 August, co-chair Hytham El-Nakhal said the co-chairs would consider the comments and announce decisions by 14 August. AFRINIC’s proposals index still listed D2 as “Under Discussion” on 9 August. The checked record contained no final consensus announcement, no Board ratification and no implementation. Any account that treats D2 as adopted mistakes a procedural waypoint for a rule.

What D2 would actually do

The four operative paragraphs matter because much of the disagreement concerns the space between them. The proposal first restates the default in formal language: an LIR or End User seeking an allocation or assignment during the Exhaustion Phase must demonstrate at least 90% utilisation of every prior allocation or assignment, whether received during the Current Phase or Exhaustion Phase. This is the visible numerical rule.

Second, D2 keeps the existing first-request treatment. A new LIR or End User with no prior IPv4 allocation or assignment does not have to satisfy a prior-use threshold for its first request. That exception makes logical sense because there is no previous pool to measure.

Third, D2 creates the substantive change. AFRINIC may waive the utilisation condition for an operator seeking additional resources for a demonstrated key technical purpose that can be shown either not to be practically serviceable from its existing pool or to create technical constraints affecting that pool. Redundancy, high-availability deployments, IPv6 transition mechanisms and expansion to new sites illustrate the category, but do not close it.

Fourth, D2 says the relevant request is treated as a first allocation or assignment request for purposes of section 5.4.6.1. The justification must be sufficiently documented so AFRINIC can verify compliance with it. The phrase “the relevant request” is important. It does not erase the member’s allocation history or permanently make the member new; the text operates on that request within the named provision.

That is the proposal’s full mechanism: a visible default, a pre-existing first-request exception, a new open category of technical purposes, and verification by AFRINIC. It does not state a one-waiver-per-member rule. It does not set a cumulative cap, an inventory trigger, a sunset, a fixed evidence schedule, a prior-waiver deployment test, a duty to give written reasons or a tailored appeal route. The proposal author said in the RPD discussion that repeated, independently justified requests are intended. That statement is evidence of authorial intention; it is not additional operative text.

The distinction matters because an exception can be narrow in a single case and broad over time. The Phase 2 ceiling of /22 limits one request to 1,024 addresses. It does not limit the number of requests. Current CPM 5.4.4 contains no explicit request-count cap. A member can therefore make a sequence of truthful, technically intelligible requests. If each waived request is assessed as though it were a first request under section 5.4.6.1, the member may remain below 90% aggregate utilisation while receiving more space. No lie is necessary. Anti-fraud procedure cannot solve a design that permits lawful accumulation.

The percentage is precise but not necessarily truthful

Ninety per cent sounds objective. What it describes is narrower than the confidence the number projects. For a /24, which contains 256 addresses, illustrative whole-address arithmetic places 90% at 231, leaving 25 outside the threshold. For a /22, which contains 1,024 addresses, the comparable arithmetic is 922, leaving 102. But AFRINIC’s published LIR method is not a live-host census. The 30 July “Definition of Utilisation” describes utilisation as the unique address space covered by eligible child objects under a parent allocation, divided by that parent allocation, with Hostmasters validating supporting operational evidence.

That clarification gives many LIR records a deterministic numerator and denominator. It does not answer D2’s harder question. An address plan may reserve a full site prefix because routing autonomy, isolation or failover requires the prefix as a unit. A NAT64 or 464XLAT design may need separately addressable transition infrastructure. Redundancy is valuable precisely because capacity exists before normal traffic fills it. Counting eligible child-object coverage can tell AFRINIC how a pool is recorded.

It cannot, by itself, tell AFRINIC whether the operator’s topology is “practically serviceable” from another pool or whether a claimed constraint is sufficiently technical.

The difference is even clearer for End Users. The liaison document says an End User may document internal use externally, including through a spreadsheet, and that evidence differs across mobile, retail ISP, enterprise ISP, cloud and enterprise operating models. This is an honest acknowledgement that operating models create different evidence. It is also proof that counting does not eliminate judgment. A formula can calculate a ratio once the eligible objects are defined. It cannot settle which architecture deserves an exception from the ratio.

The proposal author’s rationale supplies concrete reasons not to worship the aggregate number. In the RPD discussion, he described four PoPs, separate data centres, high availability and NAT64/464XLAT. Jaco Kroon accepted the underlying problem but warned that the original waiver was too lenient, proposing the practical-serviceability constraint that later strengthened the draft. Supporters also said a rigid threshold can force unnecessary renumbering or obstruct technically distinct sites, while an exhaustive list would age badly. Those are serious arguments. Network architecture is lumpy.

A separately routed minimum-size prefix may be the correct technical object even where host density is low.

The strongest case for D2 therefore starts from operational truth. Existing pool utilisation is an imperfect proxy for the next site’s needs. The policy retains 90% as the default. Existing Phase 2 rules still place each request between /24 and /22 and use an eight-month planning horizon. The applicant must document the case. AFRINIC can verify it. Technical staff can examine architectures that no fixed list could anticipate. A flexible standard can spare operators forced aggregation, unsafe dependencies and renumbering while still requiring evidence.

That case deserves more than a token rebuttal. A closed catalogue would be a mistake. It could recognize today’s named transition mechanism while failing to recognize tomorrow’s technically equivalent design. A single permanent ceiling might also defeat a genuine multi-site rollout. A new location does not become unnecessary because the same legal entity previously opened another one. The policy should not ask AFRINIC to design the network by deciding that three failure domains are worthy but the fourth is excessive.

Yet flexibility does not require opacity. The choice is not between a frozen list and unstructured staff intuition. Functional criteria can remain technology-neutral while still being observable: independently routed or failure-isolated operation; a specific inability to use existing space without renumbering, aggregation, reachability, resilience or transition harm; a route and address plan; evidence that the site, facility, upstream or equipment is ready; and an account of what happened to any prior waived block.

Such evidence verifies the narrow coordination condition without inviting AFRINIC to rank the applicant’s business model or preferred topology.

A registry can verify facts without becoming the allocator of architectural worth

The boundary is constitutional, not stylistic. AFRINIC is a registry coordinator and bookkeeper. Its legitimate surface is thin: preserve uniqueness; maintain accurate records; verify proof and prevent false registry claims; give notice and a meaningful opportunity to correct; preserve auditable state and operational continuity. Scarcity narrows that mandate. It does not transform a private registry into a sovereign authority over capital allocation.

Under this governing doctrine, the 90% rule is defensible only as a transparent queue discipline for distribution from a residual pool. The technical waiver is defensible only insofar as it corrects the rule where it collides with running network architecture. Neither gives AFRINIC a mandate to decide which customers, business models, deployment strategies or commercial risks are socially deserving. Official AFRINIC documents establish what AFRINIC proposed, recorded or assessed. They cannot prove the legitimacy of a power merely by asserting or exercising it.

The Registration Service Agreement illustrates both authority and limit. Section 3 gives AFRINIC sole and exclusive discretion to evaluate applications, but says that discretion is exercised in line with adopted policies and internal business processes and policies. Section 4 requires members to provide reasonably requested information, permits utilisation review and allows withholding future allocations or other remedies for non-cooperation or breach. Those provisions support verification of an adopted condition.

They do not write D2’s missing definition of technical purpose, decide how repeats accumulate, reconcile conflicting CPM rules or authorize staff to punish an applicant through a substantive rule that the adopted text never states.

AFRINIC staff’s own impact assessment makes the gap visible. Staff interpreted D2 to let technical constraints, but not operational constraints, override 90%. The operative proposal does not define either category. Staff called the draft clear and easy, requested no wording clarification, reported no legal or financial issue, reported no effect on WHOIS, RDAP, MyAFRINIC, NetSuite, NMRP or RPKI, and estimated implementation within 30 days after ratification. Yet the same assessment said Member Services procedures would evolve to identify fraud and prevent abusive use.

That is not a trivial implementation footnote. If procedure decides which constraint is technical, what documentation is sufficient and when a repeat is abusive, procedure contains the real eligibility rule. If it remains flexible and unpublished, similar applicants may receive unlike answers. If it becomes a detailed internal standard, staff—not the adopted CPM—have written the substantive allocation policy. Either outcome exceeds bookkeeping unless the boundaries, reasons and review are made public and auditable.

The danger is not that Hostmasters lack technical knowledge. Expertise is necessary. The danger is that expertise plus discretion plus scarce value creates an agency problem. The staff member does not bear the applicant’s cost if a launch is delayed or a network must renumber. Nor does the staff member bear the later applicant’s cost if too much space is approved. Procedure and caution are visible to the institution; opportunity cost and continuity damage sit on somebody else’s balance sheet. Reason-giving, comparable-case publication and independent review are therefore structural correctives, not accusations about individual motive.

Repeat use is the question fraud controls cannot answer

Last Call sharpened the most important issue. Nonjabulo Sphilile’s objection described a sequence in which multiple legitimate exceptions could cumulatively keep an operator below aggregate 90%. D2 has no prior-waiver deployment gate, cumulative cap, inventory trigger or sunset. The point was not that applicants would lie. It was that the text could work exactly as intended and still displace the aggregate rule over repeated requests.

Tshepo Masuku’s objection approached the same defect from due process. An unpublished implementation procedure would either stay flexible, permitting inconsistency, or harden into the actual staff-written eligibility policy. The requested cure was a defined account of qualifying cases, evidence, grounds and review. Musa Stephen Honlue had earlier asked for clearer criteria around broad phrases such as “key technical” need and “new sites.” These objections identify missing architecture rather than merely expressing distrust.

Alain Aina offered a structured Multiple Discrete Networks alternative: the same legal entity, a non-sharing test, specified proof and a lower utilisation floor. The author rejected equivalence because his target could include several BGP points of presence under one ASN. That exchange is useful even without adopting the alternative. It shows that functional boundaries can be drafted and tested, and that a candidate safeguard can be rejected for a stated technical reason. That is healthier than leaving the entire distinction to unpublished practice.

A once-per-twelve-month ceiling was also proposed and opposed. The author said it would defeat the multi-site case. He later confirmed that repeated requests should remain possible where each independently satisfies the exception. Again, the author’s intention is clear, but the policy consequence is underdesigned. An arbitrary annual ban could obstruct a legitimate build. No repeat control at all makes the cumulative distribution unknowable.

The answer is to review deployment of earlier waived space for its approved function within the normal eight-month horizon, allow a documented external delay, measure cumulative waived space per member or controlled group, and trigger policy review at published volume or inventory thresholds.

This approach separates three things that D2 and its assessment risk blending. A fraudulent request contains false or abusive evidence. A failed deployment may involve a truthful plan frustrated by an external delay. A repeated legitimate request can satisfy every case-level criterion and still create a cumulative scarcity problem. Each requires a different response: verification and sanctions through proper authority for falsehood; a defined exception for documented delay; and policy-level monitoring for lawful accumulation. Calling all three “abuse” hides the design problem.

D2 sits inside a manual, not above it

The waiver also cannot be read as though section 5.4.6.1 were the only live utilisation rule. Current Phase 2 policy sets a /24 minimum, a /22 per-request maximum and an eight-month allocation or assignment period. CPM 5.4.4 states no explicit limit on the number of additional requests. Other current provisions say an LIR may receive an additional allocation at about 80% valid use, exclude reservations for future growth from valid utilisation, and impose further utilisation requirements for provider-independent assignments.

D2 does not remove or reconcile CPM 5.5.1.4.1, 5.5.1.4.2 or 5.6.3. A separate proposal, AFPUB-2026-IPv4-001-DRAFT02, proposes removing some of those provisions. Its staff assessment says the removals help integrate D2. D2’s own staff assessment says no overlap was detected. Both statements are official descriptions of their respective drafts. Their inconsistency is not cured by assuming the proposals will advance together.

Four adoption states must therefore be kept distinct. If neither proposal advances, the current 90% rule and the other live utilisation clauses remain. If D2 alone advances, the new waiver enters a manual that still contains the 80% LIR threshold, the future-reservation exclusion and PI rules; the adopted text must say which rule controls in a conflict. If IPv4-001 alone advances, some adjacent provisions may disappear without creating D2’s technical waiver. If both advance, the deletions and waiver may fit more cleanly, but only the actual adopted language and sequence can establish the result.

It is tempting to treat this as drafting housekeeping. It is not. Different clause hierarchies can change whether the same applicant qualifies. The registry cannot resolve that economic outcome by choosing whichever live percentage seems most convenient. An adopted rule must tell the operator what evidence matters and which threshold controls before the operator incurs the cost of the application.

The available stock figures also resist simplification. D2’s rationale refers to more than three million recovered addresses as protection against immediate pool drain. That is the proposer’s claim. D2 supplies no demand model, expected waiver count, burn-rate estimate or reconciliation of allocable inventory. A participant reconstructed a /11 plus a /12 as 3,145,728 addresses, theoretically 3,072 full /22s, but that is not verified clean inventory. The adjacent proposal reports 783,872 currently available addresses and a /12 reserve. Those figures are time-bound, attached to another draft and not independently refreshed at the cutoff.

Recovered, quarantined, reserved, fragmented and immediately allocable space are not synonyms.

The per-request maximum is equally easy to overread. Eight /22s contain 8,192 addresses. The adjacent proposal reports that several members received more than eight /22s in a calendar year, without publishing member count, exact request count or distribution. That record proves only that a /22 ceiling does not necessarily cap annual receipt. It does not predict how many D2 waivers would be requested or approved.

The burden of proof has a distribution

An evidence rule does more than distinguish strong applications from weak ones. It allocates the cost of being believed. Large networks can spread the cost of technical staff, consultants, topology diagrams, invoices, facility agreements and procedural follow-up across more customers and capital. A small ISP, start-up, community network or lower-income institution can face the same fixed proof burden with fewer resources. A supposedly neutral case-by-case test can therefore reproduce unequal institutional capacity.

This poverty penalty is not cured by abandoning evidence. Scarce free-pool allocation requires an objective condition, and verification of proof is within the registry’s thin function. The cure is to make evidence cheaper to understand, predictable to supply and proportionate to the technical fact being verified. A published non-exclusive menu should say what kinds of topology, route plan, failure-domain separation, facility readiness, equipment deployment and address-plan material can establish the case. It should accept functionally equivalent evidence. It should distinguish missing proof from a rejected architecture.

It should protect commercially sensitive exhibits while publishing anonymised reasons.

NRS’s account of registry scarcity identifies the same structural risk: technical coordination acquired economic power when IPv4 became scarce. The resulting proof burdens fall hardest on smaller and lower-income operators when discretion, delay and fixed compliance costs become conditions of access. The answer is thin, verifiable coordination—uniqueness, accuracy, proof, correction and continuity—not a moral competition over which operator is worthy.

Market alternatives make the stakes visible but do not erase them. LARUS describes leasing as a way to reduce upfront capital commitment and meet immediate or uncertain demand during prolonged IPv4/IPv6 coexistence. It also describes costs beyond access: continuity, routing, reverse DNS, reputation and renewal. As a commercial lessor, LARUS has an interest in that alternative; its material is evidence of the operator-cost surface, not an independent price benchmark.

Leasing, transfers and provider space can bridge a denial, but they add price, counterparty dependence, renewal exposure, registry-recognition questions, renumbering and routing-continuity risk. They are not frictionless equivalents to an AFRINIC allocation.

BTW’s remaining-pool analysis captures the two-sided cost. Over-allocation harms later applicants. Wrongful denial harms the applicant standing before the registry. The defensible rule is neither suspicion nor generosity. It is narrow, auditable review. BTW’s work on idle-prefix option value also reinforces a technical truth relevant here: fallow-looking capacity may perform redundancy, failover, migration or credible growth functions. That does not prove every quiet prefix is necessary. It proves that “not densely filled” is not a complete diagnosis.

Process can test a rule; it cannot manufacture the missing rule

The proposal’s path shows substantial discussion. The co-chairs circulated the initial proposal on 15 May. On 21 May, RPD participants tested separate data centres, four points of presence, NAT64/464XLAT, redundancy, annual limits and the breadth of “new sites.” The author accepted stronger practical-serviceability wording. On 14 June he previewed the revised language, and AFRINIC circulated D2 on 16 June. Staff published its impact assessment on 19 June.

At AFRINIC-37 on 24 June, participants raised processing speed, proof, broad discretion, absent objective utilisation definitions and the meaning of conditional consensus. The co-chairs declared rough consensus and said the Secretariat would provide a utilisation definition during Last Call. The co-chairs opened Last Call on 16 July for 15 calendar days, longer than the CPM minimum of two weeks. The Policy Liaison published the two-page utilisation document on 30 July, the day before close.

Last-call participants then pressed the recurring-waiver, procedure-as-policy and CPM-conflict objections while others continued to defend a flexible exception.

This chronology proves that the problem was considered. It does not prove the objections were resolved. Rough consensus at the meeting was not final consensus. Under the process described in CPM 3.4, the co-chairs remained responsible for considering the PPM and Last Call record, deciding consensus and, if consensus existed, recommending the proposal to the Board. The Board retained ratification authority. The 3 August thin-registry follow-up came after Last Call closed, so it is evidence that debate continued, not timely Last Call input unless the co-chairs chose to treat it otherwise.

Review after implementation is also unclear. CPM 3.5 offers an appeal concerning a chair action through a Board-appointed Appeal Committee after discussion with the chairs. RSA section 13 separately describes an appeal path for a resource holder dissatisfied with an assigning registry action. D2 does not specify how either route applies to a Hostmaster’s waiver denial, what standard governs review, whether the requested block is preserved while review proceeds or whether reasons and comparator cases are available. It would be wrong to promise an effective merits appeal on this record.

That uncertainty matters because denial can become irreversible before a formal appeal concludes. A facility opening, customer contract or transition window can pass. A block distributed to somebody else may no longer be available. A review route that cannot preserve the subject of the dispute may vindicate an applicant too late to protect the network. A bounded waiver therefore needs independent merits review with authority to preserve the requested space temporarily, subject to the same objective inventory safeguards that protect later applicants.

The repair: a bounded technical-necessity waiver

D2 should not be reduced to a yes-or-no slogan. Its diagnosis should be preserved and its rule completed.

First, keep 90% as a rebuttable presumption rather than an absolute measure of waste. The percentage remains a visible default for ordinary additional requests, but it yields when an independently routed or failure-isolated function cannot use existing space without documented renumbering, aggregation, reachability, resilience or protocol-transition harm.

Second, publish a non-exclusive evidence menu. It should cover topology, proposed routes, failure-domain separation, facility or upstream readiness, equipment deployment, address plans and a specific explanation of why existing prefixes cannot practically serve the function. The menu should show paths to proof, not force one expensive format.

Third, require a written decision mapping the established facts to the adopted criteria. Commercially sensitive exhibits can remain protected. The reasoning, use-case category, prefix size, elapsed time and disposition can be published in anonymised form so operators can understand how like cases are treated.

Fourth, separate a repeat from a reset. Before another waiver, AFRINIC should verify that earlier waived space was deployed for the approved technical function within the normal eight-month horizon, unless a documented external delay applies. It should report cumulative waived space per member or controlled group. This does not let AFRINIC rank business merit; it tests whether the earlier exception did what it said it would do.

Fifth, link review to observable conditions. Publish requests, approvals, denials, withdrawals, prefix sizes, aggregate utilisation, prior-waiver totals, decision times, deployment at eight and twelve months, and available versus quarantined or reserved inventory. Trigger public review at adopted inventory or volume thresholds and set a sunset or mandatory review date. Measured outcomes should replace depletion rhetoric on both sides.

Sixth, state the CPM hierarchy. The amendment must expressly identify its relation to sections 5.5.1.4.1, 5.5.1.4.2 and 5.6.3 under each adoption sequence involving IPv4-001. Staff should apply the manual, not choose among unresolved clauses.

Seventh, create independent merits review with interim preservation where feasible. The reviewer should be able to examine the evidence standard and reasons without becoming a second network designer. The question is whether the adopted technical condition was applied consistently, not whether the reviewer prefers another architecture.

This design keeps AFRINIC where it belongs. The operator chooses its network and bears its capital risk. The adopted policy defines a narrow observable condition. AFRINIC verifies records and proof, provides notice and correction, records reasons and preserves continuity. Independent review checks the application. Scarcity remains real, but it does not become a licence for the registry to decide which business or architecture deserves to exist.

The judgment at the cutoff is therefore conditional and exact. D2 identifies a real technical defect. Aggregate utilisation can mistake site isolation, redundancy and transition capacity for waste. But the draft is not yet a complete scarcity-allocation rule. Until objective, auditable boundaries govern evidence, lawful recurrence, CPM hierarchy, reason-giving and independent review, the waiver risks replacing a crude visible number with an invisible permission system.