Summary

  • ARIN’s accepted RPKI Routing Intelligence design gives ARIN Online users observed routes, validity states and warnings before confirming a ROA change, but says API users will still need third-party tools for the same information.
  • ARIN’s current RPKI REST interface can create, modify and delete ROAs in a unified transaction, and can combine those operations atomically with ASPA changes. The programmatic path is therefore a consequential writer, not a secondary viewer.
  • The proportionate remedy is an optional, machine-readable preflight using the same advisory model as the web screen. It should record its inputs and limits without becoming a gate, a claim of global visibility or a substitute for local routing policy.

One authority, two moments of doubt

ARIN has identified a useful pause in the ROA workflow. A resource holder has entered a prefix, an origin AS and a maximum length, but has not yet confirmed the change. At that moment a view of current announcements can reveal an obvious mismatch. A proposed authorization may turn an observed route Valid. It may leave it NotFound. It may cause a route that currently validates to appear Invalid. A warning cannot know the operator’s entire plan, but it can make an avoidable surprise visible while the change is still reversible.

The unusual part is where ARIN drew the product boundary. Its 2024 consultation proposed this help inside a new RPKI dashboard for customers using ARIN Online. It said API users would need third-party tools to collect the same information. The accepted result retained that sentence while adding detailed BGP data, current validity, mismatch guidance, express ROA creation and disclosure of the observation sources and their refresh frequency.

That decision creates no formal inequality in permission. A properly authenticated resource holder remains the party authorised to create the ROA. Yet the decision creates a practical inequality in evidence. The person clicking through the web workflow is offered a last view of likely effects. The system submitting a transaction through the API must construct, operate and preserve a separate prediction path.

ARIN’s current documentation makes the contrast sharper. Its RPKI REST operation can create, modify and delete several ROAs in one unified transaction. The same call can be combined with ASPA changes so that all of them succeed or fail together. Reg-RWS is described by ARIN as the provisioning interface for high-volume transactions. Scale is one reason to expose a guardrail in a reusable form, not a reason to reserve it for a screen.

No API-caused outage follows from these facts. No published record in this evidence set establishes that an automated ARIN customer created a harmful ROA. The point is structural: the interface capable of repeating a change consistently is also the interface from which the planned first-party warning is absent in the accepted public design.

The strongest case for a web-first feature

There is a good defence of ARIN’s choice. Most organisations using hosted RPKI may work through ARIN Online. A visual table is easier to explain than a new API response. It can put observed announcements, current validity and suggested corrections beside a staged change without forcing every automation client to understand a new schema. An organisation sophisticated enough to automate ROAs may already use RIPEstat, an RPKI validator, RouteViews, a commercial monitoring service or its own BGP feeds.

More importantly, the warning is based on observation, not omniscience. At ARIN 56, ARIN named RIPE RIS and Route Views as sources and described the result as a relatively recent snapshot. Those systems gather routes from named collectors and peers. They do not reveal every private announcement, every policy choice, every future traffic-engineering step or every relying party’s cache at one universal instant.

A blocking API rule built on such a view would cross an authority boundary. ARIN can tell whether the authenticated customer controls resources covered by its certificate. A collector view can only say what certain peers reported at certain times. A warning that is sensible for an accidental max-length error could be misleading during a planned migration, an emergency origination or a sequence whose later steps are not yet visible.

The right answer is therefore not to make the dashboard stricter. It is to make its evidence portable.

Prediction is not publication

Five states are easy to collapse into one word called “validation.” They should remain separate.

First, registry authority answers whether the authenticated resource holder may ask ARIN to issue the object. Second, a preflight compares a proposed transaction with a bounded set of observed routes and validated ROA payloads. Third, the write changes ARIN’s hosted configuration. Fourth, publication makes the resulting signed objects available through the RPKI repository. Fifth, each relying party fetches, validates and applies those objects according to its own cache timing and routing policy.

RFC 6811 defines Valid, Invalid and NotFound from the relationship between a route and locally available validated ROA payloads. RFC 7115 makes the local dimension operationally explicit: caches are synchronised on schedules chosen by operators, and routers depend on those caches. A dashboard can forecast a state under a stated input set. It cannot guarantee the state seen by every network.

ARIN’s own ROA documentation reflects the sequence. Its web workflow has a review step. Its repository is refreshed every few minutes, and operators are told to use a validator to verify that resources are active. A removal takes effect in ARIN’s RPKI database immediately and is reflected in the public repository within a stated outer window. These are different receipts for different transitions.

That is why an API preflight should not silently create, stage or authorise anything. It should be a pure advisory call: proposed transaction in, bounded comparison out.

The smallest useful preflight

A useful response does not require ARIN to expose a global routing oracle. It needs enough structure for an operator to answer a narrower question: what exactly did the registry’s advisory system compare, what did it observe, and how long should that answer be trusted?

The response should begin with a digest of the proposed transaction. An API client may delete one ROA, create two others and alter an ASPA in one atomic unit. A warning detached from those exact bytes is a warning about an idea, not the change that was later submitted.

It should identify the relevant resource-certificate state used in the calculation. The proposed prefixes must be interpreted against the resources ARIN can currently cover. A version or digest is enough; the preflight need not disclose private account material.

For the routing side, the response should name the source set, give each snapshot time and report freshness. It should list the observed prefix and origin, the current result, the predicted result under the proposed transaction, and a stable warning code. Human prose can explain the code, but automation needs something more durable than a sentence rendered in a browser.

Finally, the response needs an expiry. A result based on routes observed ten minutes ago is not a timeless approval. If ARIN cannot obtain a current source, the response should say the advisory is unavailable or stale. Unavailability must not be silently interpreted as either permission or prohibition.

An optional correlation token could bind the advisory digest to a later write for audit purposes. It should not be mandatory. It should not become proof that the change was safe. It would merely show that a particular prediction accompanied a particular transaction.

ARIN already records the channel after the change

The idea of preserving interface provenance is not foreign to ARIN. Its ROA Change Log records whether an operation came from a Web User, API User or ARIN System, along with the time, operation, origin AS, prefix, maximum length and changed-by identity. That is a valuable post-change ledger. It can answer who changed what and through which channel.

It cannot answer what the operator was shown before acting. Nor should it be redesigned to do so. A change log and a preflight result have different jobs. The log proves lineage after the mutation. The preflight preserves the evidence available while the mutation was still optional. Joining their digests later would make the sequence auditable without pretending the forecast was a verdict.

ARIN has also treated parity as an explicit product property before. In 2023 it announced a new REST endpoint intended to provide parity with improvements to the web ROA workflow, including auto-renewal. That precedent does not promise Routing Intelligence parity. It does show that parity is a decision that can be named, designed and verified rather than left to inference.

What the public timeline supports

The feature’s public status must be stated carefully. ARIN said in October 2025 that development had begun on 30 September. In April 2026 it still described Routing Intelligence as close on the horizon and as ongoing work. Its implemented-functionality log through the 28 July 2026 release does not announce the feature. That record supports describing a planned or upcoming capability. It does not prove that no limited build, later internal milestone or unannounced API plan exists.

ARIN 57 also mentioned additional API capabilities in general. It did not publicly connect that statement to Routing Intelligence. The fair reading is neither “API parity is coming” nor “ARIN has rejected it forever.” The fair reading is that the accepted, specific design puts the route-impact view in ARIN Online and assigns API users a third-party path, while later general roadmap language leaves room for change.

An open community suggestion adds a useful adjacent detail. It asks for a web “analyze” function and a downloadable CSV of candidate prefixes and ASNs before commitment. ARIN said the similar web feature was in its pipeline and that the report would be considered. A CSV would make evidence more portable for a human workflow. It is not the same as a stable preflight contract that can evaluate the exact transaction an automated system is about to submit.

Keep the warning honest

The best version of this feature will be valuable precisely because it declines to claim too much. Its screen and API response should name the observation set. They should display age, not “real time” as an undifferentiated promise. They should distinguish a route absent from the selected views from a route absent from the Internet. They should separate a proposed RPKI state from repository publication and from downstream routing treatment.

Then the web user and the API user can receive the same class of evidence without being forced into the same interface. One can read a table. The other can parse a result, compare it with local intent, stop a pipeline or attach a reviewer. ARIN remains the issuer, the resource holder remains the decision-maker, collectors remain observers, and relying networks retain their routing policy.

That is a modest product change. It is also the difference between saying that automation may write and showing automation what the registry already plans to show a person before the write.

Sources