Summary

  • AFRINIC's 2018 implementation report recorded a concrete failure of a sequential utilisation rule: an anonymised End User could not obtain an additional /24 for a redundant second data centre because aggregate use remained below 90%.
  • AFPUB-2026-IPv4-002-DRAFT02, currently in Last Call, would let AFRINIC waive that threshold for demonstrated technical purposes that existing resources cannot practically serve. Yet the shared evidence rule is only that the justification be sufficiently documented; the meeting record deliberately supplies no universal document list.
  • Flexibility does not require invisible judgment. A protected, versioned exception receipt can name the minimum facts, evidence custody, reviewer dialogue, reason codes and appeal route while leaving topology, vendors and deployment choices with the operator.

The second data centre was already in the record

The oldest fact in this proposal is not the proposal. It is slide eight of AFRINIC's 2018 Policy Implementation Experience Report.

The report gives a compact hostmaster case. An End User member requested an additional IPv4 /24 for data-centre redundancy. Its current use totalled less than 90%. Under AFRINIC's interpretation of Soft Landing, the member was not eligible for more resources and would therefore be unable to set up the second data centre.

The record is narrow. It does not identify the member, country, ticket date, first prefix, topology, reason a different design would fail, later appeal or final outcome. It does not prove that every redundant site needs a fresh /24. It does establish the policy mismatch in AFRINIC's own operational voice: a rule that waits for one pool to fill can obstruct a second failure domain that must exist before the first one fails.

Eight years later, that difference still matters. Utilisation is a state of addresses already held. Redundancy is a relationship between functions that must be available at the same time. A sequential threshold can measure conservation faithfully and still misread concurrency.

Draft 2 fixes the category, conditionally

The neutral NOG Alliance proposal tracker indexes AFPUB-2026-IPv4-002-DRAFT02 under the broader label Under discussion. The AFRINIC-37 meeting recording records the co-chairs finding rough consensus and moving it to Last Call. Draft 1 was submitted on 6 May 2026; Draft 2 is dated 16 June and was presented on 24 June. As of 23 August, it remains a proposal, not an implemented exception.

The ordinary rule remains. During Exhaustion Phase, an LIR or End User seeking another IPv4 allocation or assignment must demonstrate at least 90% utilisation of all prior IPv4 resources. A new organisation with no previous allocation or assignment is exempt for its first request.

Draft 2 would add a third path. The threshold may be waived for demonstrated key technical purposes when the need cannot practically be serviced from the existing pool or creates technical constraints on that pool. Redundancy, high availability, IPv6 transition mechanisms and expansion to new sites are non-limiting examples. For this paragraph, the request would be treated like a first allocation or assignment request.

Then comes the entire shared evidence contract: the justification must be sufficiently documented so AFRINIC can verify compliance with the justification.

That sentence improves Draft 1. It says a label such as high availability is not self-proving. It assigns the applicant a burden and AFRINIC a verification task. But it does not yet say what proposition must be demonstrated, what minimum facts survive the dialogue, or how one reviewer can distinguish a technical constraint from an operational preference after the original ticket has aged.

The baseline has a percentage; the exception needs a type

The current Consolidated Policy Manual identifies version 1.6 as current. Its 90% threshold is visible. So are several general evidence principles. Requests may use engineering, subnetting, topology and routing plans; forecasts must be realistic and justifiable. Policy and practice should be fair regardless of location, nationality or size. Commercial information used for evaluation but not public registration must be kept confidential.

Those clauses give hostmasters a professional evidence environment. They do not type the new exception.

Consider two applicants with the same aggregate utilisation. One wants a second site because a customer contract prefers a different city. The other has two independently powered failure domains and cannot place both translation functions behind the same physical or routing dependency. Both can write redundancy. Only the evidence beneath the noun reveals whether the existing space can practically service the design and whether the constraint is technical under the proposed rule.

A field list cannot decide that case automatically. It can preserve what was decided. That distinction is the centre of the proposal's design problem.

No universal document list is not the same as no common interface

The AFRINIC-37 meeting recording contains the most useful disagreement. A participant asked what technical documentation would be required when a member had not met 90%. The author answered that there should be no single list because an IPv6-transition case and a multi-site deployment may require different evidence. Review would be an input/output dialogue with staff.

That is sensible. A topology diagram useful for a data centre may say little about a translator pool. A purchase order may prove acquisition but not failure-domain separation. A flow forecast may describe load but not routing independence.

Another participant supported the proposal but warned that any applicant could cite redundancy or high availability, leaving staff with language too broad for fair and consistent implementation. The author resisted enumerating every valid example because doing so would exclude legitimate cases and micromanage staff. AFRINIC's Head of Member Services supplied the crucial boundary: technical constraints may support the exception; operational constraints do not.

The meeting therefore rejected two bad extremes without resolving the middle. A universal dossier would be too rigid. An unstructured adjective would be too difficult to audit. The missing layer is a common interface whose values remain case-specific.

The co-chairs found rough consensus at the meeting and moved the draft to Last Call. The recording also says the Secretariat would share a definition of utilisation during that stage. The neutral tracker retains its broader label, and none of the public evidence used here establishes ratification, implementation or a field-level exception schema. That does not prove no definition was circulated elsewhere. It establishes what a reader cannot reconstruct from the proposed rule and meeting record.

“Sufficiently” moved the safeguard into the ticket

The proposal presentation and discussion place the safeguard in the phrase sufficiently documented. The draft makes two improvements: existing space must be impractical for the demonstrated technical need, and the applicant must give AFRINIC enough evidence to verify that claim.

The policy text therefore defines a relation, not merely an intention:

technical function → cannot practically be served from existing resources → additional IPv4 slice

Every arrow needs evidence. What is the function? Which existing blocks were considered? What makes reuse, renumbering, aggregation or a different placement impractical? Which site or failure domain consumes the new slice? Over what deployment window must both sides coexist? What would falsify the justification?

Without stable answers, the safeguard lives inside correspondence. The applicant may understand why it succeeded or failed today, while a replacement reviewer, an auditor or the applicant preparing an appeal sees only a conclusion and a folder of unlike attachments.

Discretion, reasons and review do different work

The meeting record describes review as an input/output dialogue rather than a universal dossier. It does not establish that a decision is final or prove any particular legal right of appeal. Professional discretion, recorded reasons and any applicable correction or review path are therefore separate design choices.

This exchange separates three things often collapsed into one word.

Discretion is the room to interpret facts that cannot be reduced to a machine test. Reasons are the record explaining how that discretion was used. Appeal is the path for testing whether the rule, facts and reasons were joined correctly. A system can preserve the first without withholding the second or disabling the third.

A correction or review request with no decision record only repeats the conversation at another level. The applicant needs to know which field failed: the architecture, the impossibility of reuse, the requested size, the evidence quality, the technical classification or the policy version. The reviewer needs the same record to avoid substituting a new rationale after the fact.

A multi-PoP example is not an entitlement

The proposal presentation uses a multi-PoP 464XLAT deployment as a motivating example. It is a design scenario, not an audit of a member network, an automatic entitlement to new space or a universal topology. Its value is narrower: a technical function may need to exist concurrently across failure domains before aggregate utilisation reaches a sequential threshold.

The 464XLAT architecture in RFC 6877 combines stateful translation in the core with stateless translation at the edge to provide limited IPv4 connectivity across an IPv6-only network. The RFC is Informational. It describes functional components and deployment considerations; it does not prescribe four PoPs, two devices per site or a particular public IPv4 prefix size.

That boundary is exactly why the policy should not encode one topology. The common layer needs to know which translation function and failure domain the new resource serves, why the existing slice cannot serve it and how demand was sized. The operator should retain the choice of platform, redundancy protocol, placement and routing design.

Minimum specification means strict fields, not thick design

Lu Heng's Minimum Initial Specification draws a useful line. Common rules should contain the deterministic minimum needed for shared coordination; later operating choices should remain with participants running the network unless those choices alter a shared invariant.

IPv4 conservation is not imaginary. AFRINIC controls a finite available pool and must verify that an additional delegation has a defensible need. Registration accuracy, uniqueness and equitable application require a common decision rule. But the choice of data-centre vendor, NAT64 platform, internal routing or deployment order is not thereby a registry invariant.

The practical synthesis is smaller than a policy manual and stronger than an adjective. Specify the fields that every decision must preserve. Let each operator fill them with the evidence appropriate to its design. Keep sensitive attachments protected. Publish only privacy-safe aggregates and the schema version.

This is not less rigorous. A vague common layer forces every hostmaster and applicant to invent a private specification. A minimum interface makes the shared part explicit and leaves everything else local.

The exception receipt needs eighteen fields

The following is this article's proposed minimum interface. It is not an AFRINIC form and does not report an existing procedure.

  1. Request or ticket ID. Bind the evidence, dialogue and outcome to one application.
  2. Rule identity. Record the policy, draft or implementation version and the exact paragraph used.
  3. Applicant and request type. Distinguish LIR from End User, allocation from assignment, and initial from additional request.
  4. Ordinary baseline. Freeze the portfolio snapshot and exact 90% calculation that the applicant would otherwise have to pass.
  5. Exception class. Name redundancy, high availability, IPv6 transition, new site or another stated technical purpose.
  6. Functional units. Identify sites, PoPs or functions in the protected record, with pseudonymous or aggregated labels for any public output.
  7. Requested slices. Map the requested prefix or quantity to each site or function instead of approving an unexplained total.
  8. Concurrency window. State why the functions must be deployed together and the period during which old and new resources coexist.
  9. Impracticality relation. Explain the topology, routing, translation or failure-domain reason existing space cannot practically serve the function.
  10. Address plan. Preserve current and forecast use for every relevant slice, including the unit and time horizon.
  11. Unused-space analysis. Inventory unused holdings and record why reuse, renumbering or another placement was rejected.
  12. Evidence custody. List files, hashes, controller, access boundary and retention period without placing confidential topology in public metadata.
  13. Dialogue history. Preserve reviewer questions, applicant replies and timestamps additively rather than overwriting the ticket's reasoning.
  14. Classification and reasons. Record technical, operational or mixed treatment and use stable reason codes with natural-language explanation.
  15. Decision and conditions. Record approval or denial, granted size, conditions, expiry and any follow-up review.
  16. Correction and appeal. Identify notice, factual-correction channel, deadline and applicable appeal route.
  17. Supersession. Link the later policy or procedure version that changes the test while preserving the rule applied at decision time.
  18. Public aggregates. Permit consistency auditing by publishing counts, classes, processing bands, outcomes and corrections without member or topology disclosure.

None of these fields decides whether a four-PoP design is genuine. Together they make the judgment reproducible. A second reviewer can see the same portfolio, the same claimed constraint and the same unanswered question. An applicant can correct a fact without rewriting history. AFRINIC can observe whether one class, reviewer or organisation size produces unexplained outcome differences.

Publish the interface before the exception becomes a door

Draft 2's direction is defensible. A second failure domain should not be forced to wait until the first is almost full merely because utilisation is easy to count. The 2018 report is unusually direct evidence that the current sequence can obstruct the architecture it is meant to evaluate.

The draft also preserves an important constraint: a technical purpose must be demonstrated, not announced. The problem is not the presence of judgment. It is the absence of a stable public description of what the judgment leaves behind.

The phrase sufficiently documented can begin a conversation. It cannot be the durable record of a scarce-resource exception. AFRINIC should publish the minimum field schema, protected-evidence rules and reason codes before the waiver becomes operational. Then the registry can conserve the pool without choosing the network, and the operator can choose the network without choosing its own evidence standard.

Sources