Summary

  • RIPE NCC marked its dedicated RPKI Dashboard maintenance record completed at 21:06:58 CET on 3 November 2026, following an in-progress update at 21:00:08. A separate Access, Portal and Database record was still in progress after 21:08 and now also listed the RPKI Dashboard among its components.
  • The live component API continued to label the Dashboard under_maintenance while the dedicated Dashboard event said completed. A completion stamp for one event and a component's operational state were different answers; the official record supplied no successful member ROA-management test to reconcile them.

At 21:06:58 CET, RIPE NCC put a completion stamp on its RPKI System Maintenance record. It had opened the work at 21:00:08. The named component was the RPKI Dashboard, the screen a member uses to manage Route Origin Authorizations. Six minutes and fifty seconds looks like a tidy maintenance window. The other official ticket made tidiness a poor guide.

The parallel maintenance record covered RIPE NCC Access, the LIR Portal and the RIPE Database. During the work, its component list also contained the RPKI Dashboard. Its update at 21:08:58 said maintenance was still in progress, and the record remained in progress after 21:41. Its displayed planned end first moved to 21:40 CET and then to 21:59. RIPE NCC's component feed showed the Dashboard as under_maintenance, with that label updated at 21:08:58, about two minutes after the dedicated Dashboard ticket closed. RIPE NCC Access returned to operational at 21:41:21 while the Dashboard, Portal and Database still carried maintenance labels. A person reading the dedicated Dashboard ticket saw “completed”; a person reading the component feed saw “under maintenance.” Both answers came from RIPE NCC.

The record had changed in another way. A saved copy of the Access ticket from before the window listed only the database, portal and access account, with a 21:10 planned end. Successive live captures listed the Dashboard as a fourth component and displayed 21:40, then 21:59. The API contained updates saying the work had started and was still in progress. It did not contain a dated explanation for adding the Dashboard or moving the displayed end by forty-nine minutes. In a status system, that missing edit history matters as much as the new end time: it leaves the user to reconstruct the event from separate snapshots.

The final stamps arrived before that last planned end. The Dashboard component returned to operational at 21:46:51, and the second maintenance event closed at 21:47:19. From the dedicated RPKI ticket's 21:06:58 completion to the component's operational timestamp, RIPE's public labels were separated by 39 minutes 52 seconds. The two event completion notices were 40 minutes 21 seconds apart. The displayed 21:59 was a revised plan, not the actual close. The sequence shows how a completed ticket can coexist with an unfinished status for the same component for most of an hour.

These are maintenance records, not packet traces. A completed event label states that RIPE posted completion for that event. An under_maintenance component label states what its public status system showed at capture time. Neither tells us whether a member successfully signed in, opened the Dashboard and submitted a ROA at 21:07, 21:22 or 21:31. RIPE NCC's hosted RPKI instructions make the dependency concrete: the member uses a RIPE NCC Account linked to an LIR to enter the Dashboard and manage ROAs. Its Access documentation places the Dashboard behind that account path. One user action crosses both maintenance tickets.

The operational question is therefore sharper than “which window ended first?” When the dedicated Dashboard event closed, did the component remain marked under maintenance because the second event still controlled it? Was an operator able to change a ROA through the account path? The public API did not answer. It made an operator choose between a finished ticket and an unfinished component label. That is a status-design problem even if the underlying service worked perfectly throughout the overlap.

RIPE NCC can repair the record without writing a novel about every internal change. Give each component one authoritative state, show which open incident or maintenance record holds that state, and log when a component is added to an event or a planned end changes. A completion note for the member workflow should say whether login, Dashboard load and a ROA submission were tested. Then the green stamp means something more useful than “one of several tickets closed.”

RIPE NCC original records