Summary

  • APNIC’s current NIR API documentation demonstrates an asynchronous /nir-delegations/asn request, but the tutorial describes delegation from an NIR’s pool rather than proving the later roadmap project’s direct-delegation semantics.
  • Executive Council material moved “NIR ASN direct assignments” from implementation work in September 2024 to final QA in December; the current 2025 roadmap entry still has no target or changelog.
  • A compact release-and-assurance receipt would bind the plan, deployed schema, participating NIRs, migration cohort and aggregate registry checks without disclosing a Member’s application evidence.

A software endpoint is a tempting fact. It has a name, a method and an example payload. It can be pointed at, copied into a terminal and, with the proper credentials, asked to change state. A release is a different kind of fact. It says when a particular set of semantics became authoritative, where they were deployed, whom they covered and what happened to the records that existed before the cutover.

APNIC’s public material currently supplies the first fact more readily than the second. Its NIR API documentation says National Internet Registries can manage registration information for their subaccounts. A tutorial shows a request to /nir-delegations/asn. Contact details are required because they inform the resulting Whois and RDAP record. The request is asynchronous: the immediate answer is a task link, and a later example reports SUCCESSFUL. The general API guide adds a sensible protection against a lost response or a retry: an Idempotency-Key can ensure that the same call is not carried out twice.

Those details are useful. They tell an NIR engineer how the surface behaves. They do not identify which generation of APNIC’s ASN-assignment policy machinery is behind it.

That distinction matters because the same public tutorial calls its operation a delegation “from NIR’s pool delegations”. APNIC’s product roadmap describes a later and more specific objective: support direct delegation of ASNs to NIR account holders, developing the function in the registry and exposing it through MyAPNIC and the NIR API. One description starts with an NIR pool. The other starts with a direct registry delegation. They may now converge inside APNIC’s systems. They may describe old and new paths presented through the same URL. The evidence published today does not let an outside reader establish that join.

Three records, no common release identity

The project trail is not empty. In September 2024, APNIC’s Executive Council material said core-registry updates and NIR API updates were in progress. In December, the project had reached final QA testing. The reporting bundle published around February 2025 still placed NIR ASN direct assignments among work in progress. The current product-roadmap data places the item under 2025, names ARMS and MyAPNIC, states an intended outcome of better data consistency and validity, and repeats the plan to expose the function through MyAPNIC and the NIR API.

What the card does not contain is a target or a changelog. Both fields are blank. APNIC’s 2025 Annual Report says quarterly roadmap targets were achieved and names several registry deliveries, including updated Whois authorisation, RPKI Signed Checklists and an RDAP rearchitecture proof of concept. The complete report does not name NIR ASN direct assignments.

None of this proves that APNIC failed to deploy the function. Silence in an annual report is not a cancellation notice. An empty changelog is not an outage. A tutorial on a testbed documentation host is not evidence that a production transaction was attempted. The responsible conclusion is narrower: the public record does not bind the final-QA project to a dated production release with defined semantics.

The absence is easy to overlook because every fragment is plausible on its own. The roadmap states intent. The EC papers show progress. The API pages show a working request shape. A later researcher can arrange the three in chronological order and feel that a story has been proven. But chronology is not identity. Without a release identifier shared by the roadmap entry, API specification and deployment note, the reader is performing the join.

Why “successful” answers too little

Consider what the example task result actually establishes. It says a task with an example identifier reached a SUCCESSFUL state. It does not say which pool supplied the ASN, which organization approved eligibility, which schema version validated the request, whether the public aut-num object was created exactly once, or whether the corresponding Whois and RDAP projections agreed. Nor should a basic tutorial try to answer all those questions. Documentation becomes unreadable when every example is forced to double as an audit report.

The problem is not the tutorial. It is the lack of a second document designed for assurance.

An ASN is not a decorative row. It identifies an autonomous system that can exchange routing information under a distinct policy. APNIC policy allows an applicant to request an ASN from APNIC or its relevant NIR. Assigned ASNs must be publicly registered in the APNIC or relevant NIR Whois database. For a customer ASN requested by an upstream account holder, the rules also allocate continuing responsibilities: the customer must qualify, the requester maintains the registration, and a change in connectivity can trigger return or transfer choices.

That makes the write path consequential. It connects an eligibility decision, a resource from a regional pool, an account relationship, fees, public contact data and an operational identity visible to other networks. A cleaner direct path into the core registry can reduce duplicate entry and drift. It can also make the hand-off between the NIR’s decision and APNIC’s authoritative state more dependent on software that outsiders cannot distinguish by looking at the resulting number alone.

Direct does not mean centralised away

The word “direct” needs care. APNIC’s NIR framework exists to provide registry services in local language and culture. NIRs remain responsible for policy compliance for resources under their management, and may adopt additional local policies so long as those do not conflict with regional or global rules. APNIC, meanwhile, must remain open to direct membership. A member that belongs to both structures may still obtain resource services from only one source at a time.

So a direct write into APNIC’s registry need not mean that APNIC has displaced the NIR as the applicant-facing authority. It can mean that an approved NIR decision is recorded without an intermediate allocation or manual re-entry. That is precisely why the implementation semantics matter. The public needs to know what became direct: the resource’s source pool, the database mutation, the approval, the account relationship, or merely the transport between two systems.

APNIC’s own history shows why these labels cannot be assumed. Its 2019 account of NIR data reconciliation explained that, after 2004, IPv4 allocations and assignments moved away from the old confederation model and were made from the common regional pool directly in the APNIC registry. Legacy blocks remained, and subsequent reconciliation corrected dates, holder identities and missing transfers. The total space did not change, but the explanation of who held which part did.

That history concerns IPv4, not the ASN project. It is valuable as a warning against analogy by shorthand. “Direct” can describe a pool model, a registry-writing path or a service relationship. When the term travels from an old address-space reform into a new ASN feature, a release record should define it again.

The public review cannot close the gap

APNIC’s resource-delegation review programme is serious work. Its public description covers reviews of allocation and transfer data across APNIC and each NIR, along with process checks, account-accuracy work and an intended review of NIR agreements. The Q2 2026 update says JPNIC, TWNIC and KRNIC reviews had been completed and work continued with other NIRs.

But the programme’s stated primary scope is explicit: IPv4 delegations and transfers over a ten-year period. That is not an ASN outcome measure. It cannot show how many direct ASN assignments entered through the newer path, whether every NIR used the same version, or whether public registry projections matched the approving record. It would be equally wrong to infer that APNIC performs no internal ASN controls. The point is simply that the cited public review cannot serve as the missing release evidence.

This leaves two audit layers unjoined. The API can produce a transaction task. The review can test a historical IPv4 population. Between them sits a product change about ASN authority whose public status is still reconstructed rather than declared.

A release receipt, not a document dump

The remedy is modest. APNIC does not need to publish applicant files, credentials, staff notes or NIR commercial arrangements. It needs a compact release-and-assurance receipt for material registry workflow changes.

The first part would identify the release: the roadmap item, an immutable version, the production cutover time, the affected API and schema, and the rollback state. It would say whether “direct delegation” means allocation from the APNIC-managed regional pool, a direct write to the core registry, or both. It would record whether deployment was universal or staged by NIR.

The second part would describe migration. Were existing ASN holdings backfilled into new subaccount structures? Did legacy NIR pools continue? Was the same endpoint retained while its backend semantics changed? Which records were deliberately out of scope? A count by cohort is enough; no applicant identity is required.

The third part would report assurance. For a bounded period, how many operations were attempted, accepted, rejected, reversed and reconciled? Did the resulting Whois and RDAP objects agree with the registry transaction? Were duplicate retries absorbed by the idempotency contract? How many exceptions remained open? Aggregate numbers and a method note would reveal far more about control quality than a claim that a roadmap target was achieved.

Most important, the receipt would keep three truths separate. Release truth says which semantics were deployed. Transaction truth says what one request did. Registry-state truth says what the public record contains now. A good system connects them. It does not pretend that one substitutes for the other.

Sources