Summary

  • RIPE-859 is a useful public response to RSSAC001v2, with inspectable links for infrastructure, status and daily statistics.
  • Every expectation should also carry a dated evidence class, result, exception state and next review, without exposing sensitive topology or thresholds.

One table, several kinds of confidence

Published on 8 May 2026, RIPE-859 quotes an RSSAC001v2 expectation and places K-root's answer below it. Infrastructure rows link the K-root site, AS25152 and PeeringDB. Operational changes are meant to reach technical mailing lists and the status page. Measurement points to RSSAC002 files. RIPE NCC also describes TSIG protection, continuous monitoring, public contacts and observation from more than ten thousand RIPE Atlas vantage points.

Those links create evidence with edges. A daily RSSAC002 file has a date, metric and format. A status notice has a time. Routing identity can be checked against another public record. None proves the whole service, but each says what can be observed.

Other rows are assurances. Systems are said to have sufficient capacity, without a demand scenario or test period. The business-continuity plan is regularly reviewed and exercised, without the last exercise date or result. Operator communication channels are tested by daily use or meetings, without a bounded public receipt. These statements may be accurate. The public document does not show how current they are.

The missing object is an evidence matrix

Each row should identify the RSSAC version, responsible function, covered service and period. It should classify its basis as public observation, protected test, control description or independent assurance. It should then record method, last date, result class, unresolved exceptions, remediation and next review.

Security-sensitive detail can remain protected. A continuity receipt can say that specified failure classes were exercised in a quarter, acceptance criteria were met and two actions remain open. It need not disclose exact thresholds, recovery channels or site topology.

Implementation diversity shows why this matters. RIPE-859 says K-root uses at least two, usually three, DNS code bases, two software BGP-router code bases and two hardware-router implementations. That describes design intent. It does not show distribution, shared dependencies or the last assessment. A bounded assurance record can close that gap safely.

The same applies to freshness. An isolated site may continue serving until the zone expires, when service is automatically withdrawn. RIPE 92 minutes mention related service-withdrawal automation. The public question is not how to defeat it, but when the transition was tested, across which site classes, with what exceptions.

Standards divide authority deliberately

RFC 7720 covers protocol and deployment and leaves operational expectations to RSSAC001. RSSAC describes expectations; RIPE NCC runs K-root; the Root Zone Maintainer supplies zone data; external probes see only their own paths. A matrix must preserve those boundaries. It would not give RSSAC enforcement power or make RIPE NCC the owner of root-zone content.

ICANN's managed-root response calls itself a living page reviewed at least twice yearly. That is not a performance ranking. It shows that a compliance publication can declare its cadence. RIPE-859 should preserve revision dates, replaced evidence and correction history.

The document is therefore a beginning, not a failure. It has turned diffuse expectations into a checklist and opened several routes to observable data. The next version should label the differences honestly: metric, description, protected test or assertion. K-root needs an evidence map, not a ceremonial seal.

Sources