Summary

  • RIPE NCC’s Q3 2026 plan names Routing History as RIPEstat’s next high-value visualisation to rebuild and says modernisation is needed for maintainability and to enable Content Security Policy.
  • The public Data API is the UI’s sole data source, but its soft row limit, peer threshold, first-hop option, visibility normalisation, time bounds and missing-data value leave room for two valid-looking views to support different conclusions.
  • A compact parity record should bind both views to fixed API responses, record their resolved defaults and deliberate differences, test representative cases and preserve a correction and retirement decision trail.

One route history, two possible readings

Consider a prefix whose announcement is visible to nine full-feed peers for part of an afternoon and eleven for the next interval. Nothing in that sequence has to be wrong. Yet a chart using the Routing History endpoint’s default minimum of ten peers may begin the line later than a chart configured to retain the lower-visibility interval. Put the two screenshots beside each other and a reader can easily mistake a display choice for a disagreement about when the route appeared.

That is the narrow risk in RIPE NCC’s next RIPEstat migration. The Q3 2026 plan says Routing History is the next visualisation to update and describes it as valuable to internal and external users. It also says legacy visualisations must be rebuilt with newer technology and a refreshed interface for long-term maintainability and to enable Content Security Policy, or CSP. The work is marked in progress.

The security case deserves to be stated without suspicion. Old front-end dependencies accumulate constraints. Modern browser policy is difficult to apply when an application assumes permissive script, style or resource loading. The W3C specification defines CSP as a way to control what a page may fetch or execute and other security-relevant browser decisions. It also provides a report-only mode so a policy can be observed before enforcement. Replacing code that blocks that protection is ordinary stewardship, not evidence of a breach.

Nor is a refreshed view required to reproduce every pixel of an old one. Better keyboard access, colour contrast, small-screen behaviour and clearer grouping may all change the picture. RIPEstat’s archived plans show a team that has previously completed old/new UI feature parity, introduced automated UI testing, rolled upgraded widget dependencies out carefully and monitored the effects of backend migration. There is no basis here for saying RIPE NCC lacks internal testing.

The case for a public parity record begins after that defence. Security parity asks whether the new application can operate under a stronger browser policy. Semantic parity asks whether a user looking at the same routing evidence will understand the same material facts. Passing the first test does not pass the second.

The API is an anchor, not the finished meaning

RIPEstat’s own documentation provides a clean authority boundary. The Data API overview calls the API the public interface and the only data source for RIPEstat widgets and the UI. The introductory documentation says the API supplies data and answers queries, while the UI shows how those data can be visualised.

That makes the API response an unusually good comparison anchor. It does not make the response self-explanatory. The current Routing History endpoint, version 2.3, returns announcement periods grouped by origin and prefix. Its data come from RIS route collectors. Its optional controls include:

  • max_rows, a soft limit whose default is 3,000; when the limit is reached, later origins are no longer returned even though all recorded routes for an included origin remain;
  • include_first_hop, which can turn an origin into an origin-and-first-hop pair;
  • normalise_visibility, which adds the proportion of full-table RIS peers seeing the route;
  • min_peers, defaulting to ten and excluding low-visibility or localised announcements below the threshold;
  • explicit start and end times, with the end otherwise following the latest available BGP data.

The output adds another important state. Normalised visibility may be -1 when peer information is missing or unreliable. That is neither zero nor a measured percentage. A new graph that puts it on the baseline would imply absence. One that silently drops it could imply continuity. One that connects points across it could imply an observation that was never made. The correct presentation may vary, but the choice must be named.

Observation scope matters too. The endpoint says its source is RIS. Related Routing Status documentation describes results as observed by RIS collectors and warns that an autonomous system may have neighbours those collectors do not observe. A RIPEstat chart is strong public evidence from a defined vantage system. It is not an omniscient map of the Internet.

Time creates a second comparison trap. RIPEstat says freshness can depend on collection frequency, store updates, processing delay, failures and caching. Two live screenshots taken minutes apart do not necessarily test the front end; they may test two backend moments. A credible migration test therefore needs a captured response, a hash and a fixed query interval. Live tests remain useful for service health, but they answer a different question.

What a parity record should contain

The answer is not a new committee and not a permanent duplicate UI. It is a small versioned record published with the rollout.

For each representative fixture, the record should identify the old and new build, Routing History endpoint and methodology version, resource, UTC interval, time-zone display, every supplied parameter and every resolved default. It should hash the captured API response and state the grouping, sorting, truncation and missing-value rules applied by each view.

The fixture set should be deliberately awkward: an ordinary single-origin prefix; an ASN with enough routes to exercise the soft limit; a multi-origin case; an interval on either side of the minimum-peer threshold; first-hop inclusion; unreliable peer information; an open-ended final period; and a narrow screen or keyboard-only reading. The aim is not pixel identity. It is to learn whether a material fact appears, disappears, changes group or acquires a different time boundary.

Expected differences belong in the record. A new accessible palette is not a failure. A reorganised legend may be better. A deliberate change from local time to UTC can be sound if the label and export follow it. Recording the rationale prevents future maintainers from “correcting” an intentional improvement back into an old limitation.

The record also needs an owner, unresolved exceptions, a review date, correction links and a decision rule for retiring the old view. The legacy visualisation should not survive until every decorative detail matches. It should retire when decision-changing differences have either been closed or explicitly accepted, the accessible use cases pass and the new view can reproduce its own reading from the recorded request.

What the evidence does not say

Nothing reviewed here shows that the current Routing History view is wrong, that the replacement has shipped, that CSP changes routing data, that an exploitable vulnerability exists or that RIPE NCC has lost information. The Q3 plan is a plan, not a post-implementation report. The API documentation describes public behaviour, not every internal test.

A parity record is therefore prospective. Its value is not to dramatise a migration. It is to preserve a useful distinction: the route evidence came from the API and RIS; the choice of what became visible came from a particular build with particular defaults. Security hardening can then move quickly without asking users to take semantic continuity on faith.

Sources