Summary

  • APNIC’s Q3 2026 roadmap proposes displaying current and historical RPKI VRP information for individual Internet number resources in REx, but the short public entry does not yet define the fields, method, cadence or archive boundary of that history.
  • A signed ROA, a VRP derived by relying-party software, a BGP route’s Valid, Invalid or NotFound result, and an operator’s routing action are four different records. A trustworthy timeline must not collapse them.
  • REx should attach a compact provenance strip to each interval: queried resource and covering relationship, prefix–maxLength–origin tuple, observation time, dataset release, derivation method, retrieval-completeness note and an explicit statement that operator policy and forwarding are outside the view.

A timeline is a powerful piece of interface design because it quietly offers a cause. One line ends on Tuesday. Another begins on Wednesday. The eye supplies the verb: somebody changed something, the system noticed, and the network behaved differently.

That verb may be deserved. It may also be fiction.

APNIC’s current Product Roadmap contains a promising Q3 2026 item: “Display RPKI VRP information for individual INR in REx.” It belongs to the Information team and names REx and RPKI as the relevant products. The intended outcomes are modest and useful—make RPKI status information easier for the Internet community to access and provide historical context for individual Internet number resources. The proposed solution is equally concise: display current and historical RPKI VRP status information for an individual resource.

The card is a roadmap card, not an interface contract. At the time of inspection its machine-readable record had an empty changelog. It did not name the eventual fields, the observation cadence, the relying-party implementation, the trust-anchor set, the source-object identifiers, the comparison rules or the retention period. None of that proves APNIC lacks an internal design. It means the public promise has not yet told users exactly what kind of history they will be reading.

That distinction is worth making before the screen exists. Once a red, amber or green interval enters a public resource page, people will cite it. Abuse teams will paste it into tickets. Network engineers will compare it with incident clocks. Buyers will place it beside due-diligence records. Researchers will count state changes. A concise interface can therefore become evidence long before its evidence boundary is understood.

Four records that happen to stand near one another

RPKI vocabulary encourages compression because several records share the same prefix and origin number. They still do different jobs.

The first record is the Route Origin Authorization. APNIC describes a ROA as a digitally signed object specifying the autonomous system permitted to originate a route for an IP prefix. The object contains an AS number, a prefix and a maximum prefix length. RFC 9582 adds the cryptographic and structural discipline: before a relying party can use a ROA to validate a routing announcement, the party must validate the signed object and perform the ROA-specific checks. If those checks fail, the entire ROA is invalid.

The second record is the Validated ROA Payload. A VRP is not merely another name for the signed file. APNIC’s technical explanation describes relying-party software fetching and cryptographically validating RPKI objects, then extracting tuples containing the authorized ASN, the ROA prefix, the prefix length and maxLength. The tuple is a result of a validation and derivation process. It has left the signed container behind while preserving the authority relevant to origin validation.

The third record is a result about a route. RFC 6811 asks whether a particular BGP route prefix is covered by a VRP, whether its length is within maxLength and whether its origin ASN matches. Valid means at least one VRP matches. Invalid means at least one VRP covers the route but none matches. NotFound means no VRP covers it. The subject of those words is the route under evaluation, not a prefix floating alone in the registry.

The fourth record is an operator’s decision. RFC 7115 is plain about this: how origin-validation state is used in routing is specified by local policy. One network may reject an Invalid announcement; another may initially observe it; a third may integrate the result with other attributes and operational exceptions. The validation state does not carry the operator’s action inside it. Nor does BGP prove that traffic follows the advertised control-plane path.

These are not academic refinements. They are separate authority boundaries.

A holder can sign an authorization. A relying party can decide whether that signed object is valid and derive a payload. A route collector, router or analytical service can evaluate an observed announcement against a chosen payload set. A network operator can decide what the result means for route selection. A public REx page can report what its own data process observed. No participant acquires the authority of the next merely because the same prefix appears in every record.

“Status” needs a grammatical subject

The roadmap phrase “VRP status” may be harmless interface shorthand. The eventual page may define it beautifully. The current wording nevertheless exposes the design question: status of what, according to whom, and at what time?

A resource can be covered by zero, one or several VRPs. A VRP can be present in one validated snapshot and absent in the next. A signed ROA can fail validation and therefore produce no usable VRP. A BGP route can be Valid at one origin and Invalid at another, or be NotFound when there is no covering payload. The operator can continue, de-preference or reject according to local policy. These propositions cannot share one colour without losing information.

The cleanest design would make the object class visible before the state. “Derived VRP present” is different from “observed BGP route Valid”. “No derived VRP in this REx snapshot” is different from “the holder published no ROA”. The former is a bounded observation. The latter assigns a cause that may require evidence about publication, retrieval and validation.

The danger is greatest around absence. A blank interval may reflect a withdrawn or expired authorization. It may reflect a certificate or manifest validation problem. It may reflect delayed retrieval, a cache reset, an archive gap or a change in the method used to reconstruct history. It may even reflect that the queried resource did not map to the display in the way a reader assumed. The timeline should say what was absent from which dataset; it should not guess why.

A date is not a vantage point

RPKI is distributed. That fact does not make public history impossible. It makes provenance indispensable.

RFC 8210 describes the cache that supplies routers as a coalesced copy of published global RPKI data, fetched periodically by relying-party software. A serial number denotes the logical version of that cache. Refresh, retry and expiry intervals govern when a router polls, retries and stops using old data. If incremental state is unavailable, the cache can require a reset and a complete load. The document also acknowledges that distributed caches cannot be rigorously synchronous.

The APNIC-hosted study of relying-party synchronization divides the system into publication, intermediate caching and enforcement. Its warning is operational rather than philosophical: an incomplete or stale publication view can lead to erroneous validation or invalidation. The paper’s authors then define a freshness criterion for their own measurement. That is how careful evidence works. It names the test instead of turning “fresh” into a universal property.

A history page therefore needs more than from and to. It needs an observed_at, a named data release or snapshot, and enough method information to show what the observation represents. If REx later changes validators, trust anchors, archive reconstruction or comparison rules, the page should mark the method boundary. Otherwise a change caused by the measuring instrument can look exactly like a change in the measured world.

“Vantage point” here does not mean that REx must enumerate a secret server topology. It means that the public claim must have a bounded observer: this REx dataset, produced by this documented method, complete or qualified as of this time. The purpose is reproducibility, not surveillance of APNIC infrastructure.

Exact, covering and more-specific are different questions

An individual-resource lookup introduces another quiet ambiguity. If a reader enters a /24, should the history show only a VRP whose prefix is exactly that /24? Should it also show a covering /16 with maxLength /24? Should it show more-specific authorizations inside the queried range? Each view can be useful, but they answer different questions.

RFC 6811’s coverage rule depends on prefix length and shared leading bits. The maximum-length field then limits which more-specific announcements can match. A timeline that displays only a badge may conceal whether the relevant authority came from an exact tuple or a covering tuple. During a change, that difference can be the whole story.

The query relationship should therefore be a first-class field: exact, covering, more-specific, or an explicitly defined aggregate view. If several VRPs are relevant, the interface should preserve the set rather than select one representative line. If a set changes, the history should say which tuple appeared or disappeared. A count alone cannot show whether an origin changed, a maxLength narrowed or one redundant authorization was removed.

This is where REx can become much better than a generic status checker. It can teach the reader which object answered the query. The lesson need not arrive as a protocol lecture. A small disclosure—“covering VRP”, 203.0.113.0/24, maxLength /24, origin AS64496, observed in snapshot X—would do more than a confident colour ever could.

The provenance strip

The minimum public instrument is not a second dashboard. It is a provenance strip attached to each current state and each historical interval.

It should contain ten things:

  1. The Internet number resource entered by the reader and the relationship between that query and the displayed prefix: exact, covering, more-specific or aggregate.
  2. The class of record being displayed: signed ROA, derived VRP, or a route-validation result. If REx displays more than one, the rows should remain distinct.
  3. The VRP tuple itself: prefix, maxLength and origin ASN. The prefix length should not disappear inside presentation shorthand.
  4. The interval start and end, plus the actual observation timestamp and timezone. Open intervals should be labelled as current only as of the latest observation.
  5. A REx dataset release, snapshot identifier or stable equivalent that allows a cited view to be recovered.
  6. The validator or derivation method and version when a change could affect comparability.
  7. The trust-anchor and retrieval-completeness statement used for that snapshot, including a bounded warning when a source was unavailable or history could not be reconstructed.
  8. A method-change or archive-gap flag. The absence of data must not silently impersonate the absence of a payload.
  9. Links to the current definition and the next recorded observation, so that a screenshot is not the only surviving evidence.
  10. One explicit boundary sentence: this view does not show the VRP set in a particular operator cache, that operator’s local routing policy, its selected route or the path packets actually took.

The strip need not expose private keys, member credentials, unpublished incident details or the topology of internal collection systems. It is metadata about APNIC’s public claim, not a demand for operational secrets.

What the timeline can safely prove

With that strip, REx could make strong statements.

It could show that, at a recorded observation, its documented process derived a particular prefix–maxLength–origin tuple. It could show that the tuple remained present across consecutive snapshots. It could show that one tuple disappeared and another appeared. It could identify a known gap in collection. It could mark that a software or method change divides two otherwise similar intervals. It could let a researcher reproduce a count and let an operator compare REx’s public view with local evidence.

It could not, without additional evidence, show that a holder intentionally withdrew authority at the first missing observation. It could not prove that every relying party saw the change simultaneously. It could not prove that a named route was Invalid unless the route prefix and origin used in the evaluation were also identified. It could not prove that a network rejected that route. And it could not prove an outage, hijack, traffic shift or delivered-service effect.

APNIC’s own measurement writing demonstrates why that last boundary matters. Its ROA-and-ROV study explains that a single access point can distort an inference about filtering: if an upstream network drops Invalid routes, all single-homed networks behind it may appear to perform ROV themselves. The observation is real; the attribution is wrong. Public VRP history deserves the same discipline.

Historical context without historical theatre

There is a recurring temptation in transparency work to make the interface more decisive than the underlying system. A timeline seems disappointing if it must carry caveats. In fact, the caveats are what make the history usable.

An analyst investigating a routing event does not need REx to pronounce a verdict. The analyst needs a stable reference that says what REx could see, how it derived the view and where the boundary lies. That record can be joined with BGP observations, operator logs, incident notices and holder statements. It becomes one trustworthy witness rather than an omniscient narrator.

Likewise, a resource holder seeing an unexpected interval does not need a badge that appears to accuse them. The holder needs the relevant tuple, snapshot and method so that the difference can be reproduced. A researcher studying adoption needs to distinguish a change in RPKI data from a change in archival coverage. An APNIC Member evaluating a product improvement needs to know whether the history is stable enough to cite.

The roadmap’s modest wording is therefore an advantage. APNIC has not promised a global routing verdict. It has promised easier access and historical context. A provenance strip would let it keep exactly that promise.

Sources