Summary

  • APNIC-127 currently says the minimum IPv4 delegation is /24 and the maximum total from 103/8 is /23. Its initial-LIR test asks for immediate need for a /24, then a detailed plan to use at least a /23 within one year.
  • Prop-169, now for discussion at APNIC 62, would replace the fixed /23 with “the IPv4 delegation being assessed”. Its published scope preserves needs assessment, conservation and current limits, creates no new entitlement, and does not reopen broader delegation, transfer or waiting-list questions.
  • The repair should name three values that can otherwise collapse into one phrase: the prefix requested, the prefix assessed and the prefix finally delegated. A protected, versioned record can bind them without publishing customer plans or letting a registry design the applicant's network.

A one-bit contradiction

CIDR notation looks parsimonious enough to hide its politics. Add one to a prefix length and the address block halves. A /23 contains 512 IPv4 addresses. A /24 contains 256. The arithmetic is elementary. Its place in a decision rule is not.

The active APNIC Internet Number Resource Policies put both values into the same initial-LIR test. Section 6.1 sets /24 as the minimum delegation and /23 as the maximum total an account holder may receive from 103/8. Section 6.2.1 then asks an LIR to have used a /24 from an upstream provider or demonstrate immediate need for one, to have complied with policy for previous space, and to demonstrate a detailed plan to use at least a /23 within a year.

The rule can therefore ask a network to prove immediate need for 256 addresses and future use of at least 512. That may be coherent when the assessed delegation is a /23. It is awkward when the request concerns a /24. A plan can describe growth beyond the block being obtained, but the policy should say that this is what it is testing. Otherwise the applicant cannot tell whether the second quantity is an entitlement, a forecast, a hurdle or inherited wording.

The plain-text APNIC-127 identity document fixes the snapshot. It identifies itself as version 015, dated 20 February 2025 and active. It repeats the same /24 minimum, /23 maximum and /23 one-year plan. Prop-169 is not already inside it.

That status distinction matters. A proposal can identify a defect without changing the rule. A clear explanation can prepare an implementation without becoming the implementation.

The narrow repair is the right first move

The public mailing-list copy of prop-169 describes a surgical change. Instead of requiring a plan for at least a /23, the clause would require a detailed plan for use of the IPv4 delegation being assessed within one year, subject to APNIC-127's applicable delegation limits.

That is better language. It removes a fixed quantity from a sentence meant to operate over more than one possible quantity. It preserves the one-year horizon. It does not pretend that every initial LIR must receive the maximum.

It is also still a proposal. Version 1 went to the Policy SIG list on 13 July 2026 and is scheduled for discussion at the APNIC 62 Open Policy Meeting. Meeting discussion, consensus, later comment, endorsement, editorial text and operational use remain separate events.

The archived proposal is usefully restrained. It anticipates updates to assessment notes, guidance and applicant-facing material that still mention the fixed /23. It preserves needs assessment, conservation and the current limits, creates no new entitlement, and says the broader delegation, transfer and waiting-list questions are not being reopened.

A narrow text change can still change what the decision trail must remember. The registry may store the same prefix in the same kind of row while the denominator and evidence used to select it change. That difference lives in the request and review trail, not necessarily in the public delegation object.

The neutral NOG Alliance proposal tracker lists prop-169 as “To be discussed at APNIC 62”. That is a future meeting state, not an outcome. The proposal's own /24 example explains the wording problem; its stated scope leaves broader IPv4 policy outside this repair.

This article does not smuggle those subjects back in. The question is smaller: does the replacement phrase leave a result another reviewer can reconstruct?

A variable needs a referent

“The delegation being assessed” sounds precise because it contains a definite article. But definiteness in grammar is not identity in a transaction.

At least three quantities can exist in an address request.

The requested prefix is what the applicant submits. The assessed prefix is the denominator the reviewer uses when judging the one-year plan. The delegated prefix is what APNIC or an NIR finally puts into the registry. A routine request may carry the same /24 through all three stages. That is not a reason to merge the fields. It is a reason for the record to say same-as-requested and make the ordinary path cheap.

If the values differ, the distinction becomes essential. The applicant might ask for /23, while the reviewer finds evidence for /24. The applicant might revise a request after questions. A total-holdings limit might constrain the final amount. The article is not saying these transitions occur in current practice. It is saying the proposed public sentence neither rules them out nor names their record.

There is a fourth number nearby, but it is not another transaction value. Remaining entitlement is a calculation: current relevant holdings subtracted from the applicable maximum. It may constrain a request, yet it should not be confused with the applicant's request or the reviewer’s factual conclusion.

The current policy already shows a more explicit grammar in a neighbouring path. Section 6.2.2 says multihoming applicants must demonstrate immediate use of 25% and one-year use of 50% of the requested addresses. That is a different eligibility category and must remain different. It nevertheless proves that APNIC-127 can bind a test to a named quantity rather than to a floating object.

The right question for prop-169 is not whether it should copy those percentages. It should not. The question is whether “being assessed” can be bound just as clearly.

The policy's three time horizons make the binding more important

Section 5.2.1 does not contain only a one-year forecast. It asks delegation requests to carry documented estimates for immediate need, one year and two years. It gives 25% immediate and 50% within one year as a general guideline. When an end user cannot confidently estimate two-year demand, the policy allows APNIC or the NIR to make a delegation sufficient for one-year needs only.

That introduces a second set of distinctions: forecast horizon, evidence confidence and decision quantity. A two-year forecast can be uncertain without making the immediate claim false. A one-year quantity can become the final delegation without turning the two-year number into a broken promise. A reviewer can test a forecast without adopting the applicant's architecture.

The public rule will be more durable if it records which horizon determined which quantity. Otherwise “the delegation being assessed” may mean the block in the request at submission, the block chosen after reviewing immediate use, or the block chosen after discounting the two-year forecast.

Subsequent-delegation policy supplies a useful procedural clue. Section 7 says decisions depend on verified past usage, documented plans and compliance and may meet estimated needs for up to one year. If APNIC or an NIR chooses a shorter period, it must tell the LIR the period and its reasons. That is the right instinct: where a variable result narrows, name the variable and explain the choice.

Current public guidance describes a ceiling, not the path to it

APNIC's post-exhaustion page tells members that the total maximum from 103/8 is /23, that a member at the maximum cannot receive more from APNIC, and that an existing member below the maximum may submit a request in MyAPNIC. It directs networks needing more than /23 toward transfers.

This is intelligible public guidance. It answers what the ceiling is and where to start. It does not claim to show the private application fields, the size against which staff assess the evidence, or the reason for a partial result. A public ceiling and a protected decision record do different jobs.

Scarcity makes that distinction more, not less, important. A free-pool decision does not need to expose customer contracts. It does need to be repeatable. When a smaller block is granted, the durable record should distinguish lack of entitlement, lack of evidence, remaining-holdings arithmetic and an applicant's voluntary revision. Those reasons do not have the same meaning and should not produce the same precedent.

/23 became the ceiling; /24 remained the floor

The two-size interval has documented history. The JPNIC Internet timeline records consensus on prop-127 at APNIC 47 and the later policy enactment; JPNIC then ended maximum /22 allocations from returned inventory and aligned that channel to /23. The archived current policy, not this history page, supplies today's /24 minimum.

That event does not explain the subjective intent behind every surviving sentence. It does explain why a current request can lie between two permitted sizes. A fixed /23 plan clause can look natural when read beside the maximum, even though the minimum remains available.

Later debate went in the other direction. Prop-152 proposed reducing the maximum to /24 after depletion of the then-current available pool and limiting later delegation to new account holders. It did not reach consensus and was abandoned in February 2024. It is not current policy.

Its impact assessment contains a useful design lesson without deciding prop-169. The Secretariat cautioned against embedding live inventory figures in policy because they could change during discussion. Stable policy should identify a variable and the source that supplies it. But a variable is not stable merely because its number has been removed. Its referent and version must also be fixed.

A minimum protected size-decision record

This need not become a forty-page application constitution. The common record can be strict and small. Sensitive evidence can remain protected. The public projection can show bounded reason codes and aggregate paths without exposing customers, topology or contracts.

The record should contain sixteen fields.

  1. Request identity and timestamp. Give the request a stable identifier, submission time and an explicit link to any revision or superseding submission.
  2. Rule identity. Record the APNIC-127 version, exact clause, effective date and any proposal-derived implementation version used for the decision.
  3. Decision authority. Name APNIC or the relevant NIR, the reviewer role and the delegation channel; do not hide authority behind a generic system name.
  4. Applicant class and eligibility path. Distinguish initial LIR, multihoming, critical infrastructure, IXP or another authorized path so one test is not borrowed silently by another.
  5. Current relevant holdings. Record 103/8 holdings, other relevant space and the remaining-entitlement calculation used, with the policy scope of each input.
  6. Requested prefix. Store the exact prefix length, address count and applicant-declared revision. /23 and 512 should be machine-checkable views of one value.
  7. Immediate-need baseline. Bind the quantity and operational function to protected evidence references. Do not make one favored network diagram the rule.
  8. One-year plan denominator. State the exact prefix and address count against which the forecast is evaluated. This is the field prop-169's noun needs.
  9. Two-year forecast status. Mark it supplied, not confidently estimable or not applicable, and record the clause supporting that treatment.
  10. Evidence custody. Keep document identifiers, hashes, access class, retention, privacy treatment and corrections without publishing customer detail.
  11. Assessed prefix. Record the exact quantity, when it became the decision denominator and which rule allowed it.
  12. Difference code. If assessment differs from request, give a bounded reason tied to the relevant fact. If it does not, record same-as-requested.
  13. Question-and-response history. Preserve material questions, answers and timestamps, and identify which field changed after each exchange.
  14. Final delegated prefix. Bind the final quantity to the registry event, prefix and time, and record any difference from the assessed value.
  15. Outcome and correction path. Distinguish granted, partially granted, declined, withdrawn and pending; carry reasons, review or reconsideration route and any correction.
  16. Privacy-safe aggregate projection. Publish counts of request-to-assessment-to-delegation paths, processing bands, difference reasons, withdrawals and corrections without naming applicants.

The field list is not an argument for putting business plans on the open Internet. A hash does not make sensitive evidence public. A public count does not need an applicant name. A reason code can say remaining-entitlement-limit without disclosing customers. Privacy and repeatability are not opposites.

A ledger field is not an architecture order

The Minimum Initial Specification supplies the useful boundary. The common layer should be exact about the minimum facts required for shared coordination. It should leave later operating choices with the people who run the network.

In this case, request identity, rule version, quantity, authority and registry transition are common facts. Customer mix, router vendor, addressing plan, translation method, product design and commercial timing are not. If APNIC continues to test need before issuing scarce free-pool space, it can examine relevant evidence without converting its preferred evidence format into an approved network design.

That boundary also disciplines both parties. The applicant cannot turn “future growth” into an untestable slogan. The reviewer cannot turn “detail” into an unlimited demand for private information. Each question must connect to a named quantity and a rule. Each result must connect to the same fields.

The APNIC Policy Development Process describes openness, transparency and bottom-up decision-making, and treats proposal outcomes as public records. Those values work only when the object moving through the process remains identifiable. A consensus on a variable phrase is not a consensus on every unpublished way the variable might later be filled.

The public policy can remain narrow. The implementation record must be exact.

Sources

What the evidence does not show

No public source in this record shows that APNIC or an NIR has denied, delayed or reduced a specific request because of the fixed /23 clause. No source counts requests by requested, assessed or final size. No source exposes current internal forms or reviewer notes. The article therefore identifies a textual ambiguity and recommends a record; it does not report a pattern of misconduct.

The evidence also does not predict APNIC 62. The meeting has not occurred at this snapshot. A new version could bind the quantity more tightly, preserve the current wording or change the proposal's scope. Each would be a new fact.