Summary

  • Revision 09 of draft-ietf-sidrops-rtr-yang, dated 7 September 2026, adds a distinct refresh interval, Serial Query and Reset Query counters, Router Key and ASPA counters, and five newer Error Report categories.
  • The additions make the router-to-cache boundary more observable. They do not prove which party caused a failure, whether cached records influenced route policy or how long an incident affected traffic.
  • The proposed leaves are read-only operational state. RFC 8342 describes system state and collected statistics as transient, so a later query is not a substitute for a retained history.
  • The draft lists two known implementations, but both entries identify draft-03 and were last updated on 30 March 2026. The text does not establish implementation of revision 09's new leaves.
  • Daniel Kade proposes a revision-bound cache-state receipt carrying the collection time, counter-reset epoch, session and serial context, timing state, bounded error deltas and operator action. That is an editorial proposal, not a draft requirement.

One disconnect, several instructions

An outside dashboard can reduce every broken router-cache session to the same red light. The RPKI-to-Router protocol does not. Its developing Version-2 specification assigns different meanings to a transport failure, a cache restart and a cache shutdown.

A cache sends a restart report when it expects to become unavailable but intends to return before connected routers reach their expiry boundary. A shutdown report instead tells clients to flush the data learned from that cache. A prolonged transport stall can trigger a transport-failure report and termination of the session. The operational consequences are different even before a network applies its own route policy.

Timing is part of the distinction. The Refresh Interval tells a router when to poll normally. The Retry Interval governs another attempt after a failed query. The Expire Interval bounds how long previously fetched data may remain usable without a successful new query. A disconnected session can therefore coexist with temporarily retained validation material. “Cache down” says too little about the state that matters.

Revision 09 of the SIDROPS YANG draft makes more of that boundary machine-readable. This is the news event. It is not a claim that the protocol, the model or a particular implementation has failed.

Revision 09 separates interval from deadline

The 08-to-09 comparison adds refresh-interval as the number of seconds between periodic Serial Queries. At the same time, the existing refresh-time description is sharpened: it is the time, expressed in hundredths of a second, when the next refresh is expected to occur.

That separation is modest but useful. An interval expresses policy received from a cache. A deadline expresses the current device state after a particular exchange. If an operator retains only one undated number, a later reviewer cannot tell whether the router followed the interval, recalculated a deadline or had already lost contact.

The PDU subtree also gains explicit counters for Serial Query and Reset Query. One asks for changes since a known serial; the other asks for the full active dataset. A rise in Reset Queries can therefore identify a different recovery path from ordinary incremental polling. Revision 09 also adds counters for Router Key and ASPA PDUs, the newer payload classes carried by the proposed Version-2 protocol alongside prefix-origin data.

The error subtree is brought into the same vocabulary. New named leaves cover an invalid ASPA provider list, transport failure, ordering error, cache restart and cache shutdown. Existing error leaves receive clearer descriptions tied to Error Report codes. The model now exposes codes 0 through 13 rather than leaving the newer Version-2 conditions outside the proposed management surface.

These are state labels, not verdicts. An ASPA error count does not show that the bad list entered route selection. A Reset Query count does not explain why a full refresh occurred. A restart count records an exchanged report, not proof that the cache returned before expiry.

A counter needs a beginning

The draft describes the error leaves as counters of Error Report PDUs “exchanged” with the cache server. It does not split them into sent and received directions. Even a perfectly implemented counter therefore cannot assign responsibility without other evidence.

Nor does the value carry its own time base. A count of four could mean four events since boot, four since a line-card restart, four since a management process reset or four since a collector began watching. The YANG type is a zero-based counter, but the proposed schema does not turn that number into an append-only incident log.

This is consistent with the underlying standards. RFC 7950 uses config false for state data. RFC 8342 describes system state—including read-only status and collected statistics—as transient and subject to change through interactions with internal components or other systems. Operational state is valuable precisely because it shows what the device is using now. That virtue does not make it a durable history.

The surrounding context is therefore essential. A sample should travel with the module revision, collection time, successful or failed collection status, counter-reset epoch, cache/session identity, protocol version, session ID, serial state, last End of Data, and the current Refresh, Retry and Expire timing. Without those fields, two snapshots cannot reliably be compared.

Running code is evidence with a version

Revision 09 contains an implementation-status section, and that matters. It names implementations from Juniper Networks (HPE) and New H3C Technologies. The section also states the limit that must accompany any report of them: both entries identify Draft-03, both were last updated on 30 March 2026, and neither supplies specific implementation experience.

Those records support the narrow proposition that implementers reported work against an earlier schema. They do not establish that revision 09's new leaves are available, interoperable, enabled by default or deployed in production. “Implemented” without a revision would erase the most useful evidence in the section.

Institutional status needs the same care. Datatracker calls the document an active SIDROPS Working Group Internet-Draft intended for the Standards Track. Its IESG state is I-D Exists; the page lists no document shepherd and marks the consensus boilerplate unknown. Working Group custody gives the work more process context than an individual submission, but it is not an RFC and has not completed IETF review.

Sources