Summary

  • APNIC’s 2026 product roadmap proposes automating alignment among route management, resource holdings, Whois and RPKI after transfers, deallocations and system changes.
  • These records are related but not synonymous. A holding establishes registry authority; an IRR route object expresses routing policy or intent; a ROA authorizes an origin; an observed BGP route reports what is being announced.
  • APNIC’s public item does not yet say which state wins a conflict, where a transaction ends, how partial failure is contained, or what notice and rollback evidence an operator receives. That is a public documentation gap, not proof that APNIC has no internal design.
  • The useful deliverable is a type-specific precedence matrix and a durable task receipt. Automation should align decisions while retaining the different meanings of the records it touches.

The quiet verb that decides who may speak for a prefix

In a product roadmap, few words look safer than “alignment”. It suggests two untidy columns, a reconciliation job and a green tick. APNIC uses it in a Q3 2026 Registry item called “Route management alignment”. The item names ARMS, RPKI and Whois. Its summary proposes to “automate alignment between route management, resource holdings, Whois, and RPKI”. The intended result is less tedious, less error-prone reconciliation after transfers, deallocations and system changes.

That is a worthwhile aim. Manual coordination is slow precisely when an operator needs a clean change. It is also a description of institutional power hidden inside a maintenance verb. When four records disagree, alignment software must decide whether to preserve, reject, replace, delay or delete something. It must decide which actor is entitled to request the change and whether an apparently inconsistent record is stale, deliberately different or merely still propagating. The green tick arrives only after those choices.

The captured roadmap entry is a proposal, not evidence of a deployed service. Its structured record names the year, quarter, team, products, summary and intended solution. Its changelog is blank. It does not publicly state a precedence order, the boundary of any cross-system transaction, a partial-failure state, a rollback rule, an operator-notification rule, or the treatment of National Internet Registries and external routing registries. APNIC may have designed some or all of those controls internally. The narrow fact is that the public item does not yet expose them.

That omission matters because the named systems do not store four copies of one truth.

Four records, four different questions

A resource holding asks a registry question: which account or organisation is recognised as holding authority over an address block or autonomous-system number? That record can determine who may manage associated services. It does not, on its own, say which AS should originate every prefix today.

An Internet Routing Registry route object asks a policy question. APNIC describes the IRR as a distributed set of databases in which operators publish routing policies and announcements. Route objects can feed tools that build filters for peering and customer sessions. RFC 2725 requires authorization against both the address prefix and the origin AS when such an object is created. The same standard explicitly accommodates multiple origins for a prefix, overlapping more-specifics, changes of provider and renumbering grace periods. Difference is not automatically defect.

A Route Origin Authorization asks a narrower cryptographic question. RFC 9582 defines the ROA content as an authorization by an address-space holder for one AS to originate routes for specified prefixes. Multiple ASes require multiple ROAs. The object says permission has been granted. It does not certify that the AS is announcing now, that a route is reachable, that a router accepts it, or that an IRR object describes the same operational policy.

A BGP route asks an observational question: which prefix and origin are being presented through the routing system, with a path and other attributes? RFC 6483 explains how a relying party compares that observation with valid ROAs to produce Valid, Invalid or Unknown outcomes. It also leaves the treatment of those outcomes to local routing policy. A registry can issue and publish authorization; it does not command every network’s route-selection decision.

Those distinctions are not academic. A backup AS can be authorized before it announces. A route object can remain useful to a filter builder during an orderly migration. An observed route can be real but absent from an IRR, or visible before a new ROA reaches a relying-party cache. RFC 6483 warns that RPKI objects and routes propagate on different clocks. A momentary mismatch may be the expected shape of a safe change.

Alignment therefore cannot mean forcing every field to look identical. It needs to mean that each record has a declared source of authority, a permissible set of differences and a rule for transitions.

APNIC has seen this conflict before

An older APNIC Route Management Guide makes the history unusually useful. The guide is dated 2017 and must not be mistaken for the final contract of the proposed 2026 work. But it describes a predecessor interface that already understood the gap between a management record and a public Whois object.

In that guide, a MyAPNIC “route” acts as a template for creating an actual route object in Whois. The two can exist separately: a template without a Whois object, or a Whois object without a managed template. When a route object is changed outside the route-management tool, the MyAPNIC entry does not silently copy the external edit. The interface reports a conflict. The user can accept the change or revert the Whois object to the template.

That is an important design instinct. The system treats inconsistency as an event requiring interpretation, not merely as dirt to be scrubbed away. It tells the operator that another path changed the public record. It preserves a choice between importing that state and restoring the managed intention.

The same guide describes pending status while several objects synchronize. It also lets an eligible user request matching ROAs when creating routes. In one described deletion path, disabling a managed sub-route whose ROA is enabled also deletes that ROA. These details show why a modern alignment project is more than a faster copy job. APNIC’s own historical workflow contained separate states, asynchronous work, optional coupling and conflicts created outside the main interface.

The new roadmap may replace this model, refine it or retain parts of it. The public entry does not say. What should survive is the explicitness of the old conflict: an outside change was visible, and the operator was shown the decision instead of receiving an unexplained overwrite.

“Transactionally where possible” is a boundary, not a promise of magic

APNIC’s 2024 Registry API announcement provides a second piece of context. The API can retrieve delegation information and manage Whois records, reverse DNS, ROAs and route objects. APNIC gives the example of an operator adding a BGP announcement and using the API to create a ROA and a route object without separately working through MyAPNIC.

The announcement is careful about execution. Whois supports single-object retrieval and update. Reverse-DNS and abstract route-management operations support batches, which take effect “transactionally where possible”. All updates are asynchronous task objects: submit a request, receive a link, inspect status, then obtain outcome details.

That language is more honest than an unqualified claim of atomicity. A database transaction can often roll back changes inside one store. A published RPKI object has its own repository and cache life. A Whois update has its own visibility. An external IRR is another administrative domain. A receiving RIR in a transfer has another clock. BGP observations are outside the registry’s direct control. One button cannot make those boundaries disappear.

“Where possible” therefore needs a complement: where is it not possible, and what state does the task expose then? A task that writes a Whois route object but does not complete the intended ROA change is not adequately described by a generic Failed label. Nor is it necessarily safe to retry the whole request without knowing which side committed. The outcome should identify each attempted transition, the last authoritative state and the compensating action, if any.

This does not imply that APNIC’s API currently mishandles partial failure. No such incident was tested here. It means the vocabulary already contains asynchronous tasks and qualified transactions, making a precise receipt a natural extension of the public service model.

A transfer is where tidy records become consequential

The roadmap names transfers, deallocations and system changes as triggers for alignment. APNIC’s transfer conditions show why a transfer is not a cosmetic update. When an outbound inter-RIR transfer completes, the source entity no longer holds rights to the transferred number resources and the recipient becomes the registered entity. APNIC also says associated sub-assignments, route objects and domain objects are deleted from the APNIC Whois Database.

The cited clause is specific to Whois-associated objects. It does not say what happens to ROAs, and silence must not be converted into an invented deletion rule. That very boundary illustrates the documentation APNIC’s new automation will need. The holding transition is authoritative for control of the resource. The Whois cleanup is stated. The intended routing authorization after the transfer remains a separate question.

Imagine a recipient that will use the same origin AS. The registry holding changes, yet the desired BGP origin may not. Imagine a recipient that will originate through a new AS but wants the new authorization available before retiring the old path. Imagine an inter-RIR transfer where the source-side Whois objects disappear on one schedule and the receiving side’s records become visible on another. These are analytical scenarios, not reports of APNIC failures. They show why a single “aligned” flag is too small.

The safe sequence depends on authority and timing. Former credentials should cease to control the resource when the transfer takes effect. That does not automatically tell the system which new route object to publish. A replacement ROA should be signed by the party entitled to authorize it, but route continuity may require preparation and a controlled cutover. Deleting first and asking questions later creates an avoidable NotFound or Invalid interval. Preserving everything indefinitely leaves stale authority behind.

The answer is not one universal order. It is a published matrix for each trigger and record type.

Three conflicts the machine must not flatten

The first is a legitimate multi-origin arrangement. RFC 2725 acknowledges that more than one route object may exist for the same prefix because multihoming does not require a unique origin. RPKI similarly supports multiple ROAs when more than one AS is authorized. If a reconciliation rule expects one prefix to have one origin everywhere, it can “repair” a resilient design into a single point of failure.

The second is a propagation mismatch. A new ROA can be validly published while a relying party still has an older cache. A route can appear before authorization reaches that cache. The registry’s internal task may be complete while the operator’s validation view is not. Alignment software should distinguish committed, published, observed and sufficiently propagated states. It should not rewrite records repeatedly in response to a clock difference it created.

The third is a change through another authorized channel. APNIC’s old guide treated an external Whois edit as a conflict the user could accept or reverse. A new system needs a stronger version of the same question. Was the edit made by an authorized maintainer? Did it carry a newer declared intention? Does accepting it imply a ROA change, or should those remain separate? A machine that simply declares the route-management template superior may destroy a legitimate emergency correction. A machine that always imports the outside edit may let the managed plan drift without review.

None of these cases is solved by asking which database is “the source of truth”. Source of truth for what is the necessary question. Holdings should be authoritative for entitlement. A verified operator request can be authoritative for intended policy. A valid ROA is authoritative evidence of origin authorization within its certificate chain. BGP is evidence of announcement, not permission. Each can contradict another without being semantically malformed.

Publish the precedence before the software applies it

A useful precedence matrix would be compact. For each trigger—transfer, deallocation, account change, direct Whois edit, route-management edit, ROA edit or system migration—it would identify the authority that can initiate action, the records eligible to change, the differences that are allowed, and the conditions that require review rather than automatic resolution.

It would state what “aligned” means. It might mean that every managed route has an authorized resource holder, that each requested Whois object passed prefix-and-AS authorization, that every requested ROA reflects an explicitly chosen origin set, and that deviations are visible. It should not mean that a currently observed BGP route is copied into an authorization simply because it exists.

The matrix also needs an atomicity column. Which updates share a database transaction? Which are published asynchronously? Which depend on another registry or repository? At which point may the operator safely announce, withdraw or rebuild filters? If a task crosses those boundaries, what is quarantined after one side succeeds?

Finally, it needs a notice rule. A silent reconciliation is attractive to product teams because it reduces clicks. It is dangerous when it changes public records used for routing filters or cryptographic validation. The operator should know the before state, proposed after state, authority, reason and time available to contest or reverse a non-emergency change. Urgent remediation can use a shorter clock, but it still needs a record after the event.

The route-alignment receipt

The smallest durable control is a versioned receipt attached to each consequential task. It would identify the event, trigger and request authority. It would preserve the relevant holdings snapshot and the before-and-after state of the route template, Whois route objects and ROAs. Each change would carry a record-specific precedence rule and reason code.

The receipt would draw the transaction boundary rather than claiming global atomicity. It would show which writes committed together, which publication steps remained pending and which external systems were outside APNIC’s authority. A partial result would name the successful step, the failed step, the last safe state, the retry identifier and any compensating action or quarantine.

Visibility needs timestamps of its own: when the Whois object became queryable, when the RPKI object was published, when an independent validation check observed it, and when the task stopped waiting. A BGP observation may be attached as evidence, but not as a command or a guarantee of reachability.

Transfers, deallocations, NIR-managed resources and external-IRR objects should be explicit scope flags. Notices and acknowledgements should identify roles without publishing unnecessary personal credentials. Review and override should be possible under a named owner. The history pointer should survive rollback, because a tidy current record cannot explain a disputed past decision.

This receipt is a proposed control, not an APNIC-announced deliverable. It does not require exposing secret keys, authentication material or every internal log. It requires enough public or member-visible evidence to distinguish successful alignment from silent coercion, deliberate difference from stale data, and completed work from a partially synchronized task.

APNIC’s roadmap is right to target manual reconciliation. The risk lies not in automation but in treating the judgment automation performs as plumbing. Before the system selects a winner, the people whose routes and authorizations depend on it should be able to see the rules of the contest.

Sources