Summary

  • RIPE NCC deployed a tree view and resource checks on its Database website on 19 October, replacing a flat table. The LIR Portal’s Assisted Registry Check integration is still ahead.
  • Its own design account identifies the next hard choice: separate a clear result, a condition to review and a child resource that has not been checked. A missing exact route object is a neutral observation, not a verdict.

A tree with a status light

On 19 October, RIPE NCC staff member Edward Shryane told the Database Working Group that the Resources page on the RIPE Database website had been deployed with a tree view and resource checks. The old table is gone. The tree makes parent allocations and their children visible together; the checks bring possible work to the member's attention. Shryane said the functionality would also appear in Assisted Registry Check workflows in the LIR Portal. That second step was a promise, not part of the announced DB website release.

Two days later, RIPE NCC's design team described the question the new tree makes harder to hide. A green parent may have a child that has not yet been checked. Large hierarchies can require many API calls. The team is still working out how to stop an unfinished check from looking like an all-clear. The release has turned a design concern into an immediate reporting question: which branches were checked, and which are still waiting?

The design account also describes a side panel for registration details, utilisation, RIPE Database objects and routing information. Those fields can turn registry data into a queue of possible work, provided the page says what it observed and where the evidence ends.

That queue can be useful. It can also sound more certain than its evidence. A check that never ran cannot earn the same badge as one that cleared a resource.

The portal needs three states, not two: checked and clear; checked and worth reviewing; not checked. “Unknown” is not a defect. It is a status. If the interface hides it, the user sees a green light where the system has only an empty clipboard.

What the checks can see

RIPE NCC’s design account describes checks across several distinct relationships: announced IPv6 allocations with no registered usage; IPv6 assignments below the expected size; allocations with registered assignments that are not announced; ASNs absent from the BGP table; and address space in use that may need an additional assignment registration. The deployment email confirms resource checks shipped; it does not publish a per-check production inventory.

Those signals do not all carry the same meaning. A missing registration can be a recordkeeping question. An ASN absent from a routing table is a visibility observation. A route object that does not exactly match a resource may reflect a more-specific prefix, a covering route or another intentional configuration. RIPE NCC says a simple exact-match test could mislead members, so the design uses neutral information where the system cannot establish a problem.

That is a better instinct than giving every mismatch a red triangle. In network operations, an alert is an invitation to spend someone’s afternoon. A dashboard that calls every odd shape an error will train people to ignore it. A dashboard that calls an unchecked item “fine” will train them to trust a blank test.

The My Resources API documentation shows the underlying account data can include ASNs, IPv4 and IPv6 allocations and assignments, and legacy IPv4 records, with fields such as status, registration date and a link to the relevant RIPE Database object. The new interface adds interpretation around those records; it does not make each record self-explanatory. The user still needs to know what was compared, what the comparison found and which action follows.

A warning is a small decision

The wording matters because these checks sit between a record and a person who may change it. “To review” leaves room for context. “Issue” sounds like a verdict. “No exact match found” says what the system observed without pretending it has solved the routing design.

RIPE NCC’s redesign recognises this. It separates actionable review items from information that needs interpretation, gives notifications an explanation, and proposes displaying related route objects in a hierarchy. The team scheduled RIPE 93 usability testing of the Resources page and plans to examine whether members can read the tree, understand the checks, choose an action and move between My Resources and the existing Registry Check service.

The public record lacks RIPE 93’s user-test results and a production coverage report; a dated test report and per-resource check-state definition would change the assessment.

Make the empty square visible

A registry portal is not only a window onto records. Once it sorts findings and recommends next steps, it shapes which records attract attention and which can wait. That is an operational role, not a reason to make the registry the judge of every unusual configuration.

Heng Lu’s registry-continuity argument draws a useful line: preserve accurate records and the services operators rely on; examine separately the institution’s choices about how it exercises authority. Applied here, the line is practical. A portal can help members keep resource data current without turning a missing exact match into a ruling.

The interface should show, for every resource, what was checked, when it was checked, what the comparison found and whether the result is clear, worth review or still unchecked. For a large tree, progress belongs beside the branches. If the system has not reached a child, the child gets an empty square—not a borrowed green light from its parent.

Sources: RIPE NCC deployment announcement; RIPE NCC October Member Update; RIPE Labs: Redesigning My Resources; RIPE NCC My Resources API; RIPE NCC Assisted Registry Check.