Sasha Romijn's NRTMv4 mismatch was in the draft

Summary

Sasha Romijn, IRRD's original developer and maintainer, co-authored NRTMv4, a protocol for keeping Internet Routing Registry mirrors in sync.
When IRRD and RIPE NCC built separate implementations, their disagreement sent Romijn back to her draft. It described a different rule from the one she had meant.
An IESG reviewer later corrected an IPv6 example that used route where the object should be route6. The current IETF document remains in the RFC Editor queue.

Sasha Romijn thought RIPE NCC had read NRTMv4 wrong. Then she reread the draft. The mismatch sat in the text she had written.

Romijn is an independent developer, the original developer and maintainer of IRRD version 4, and one of NRTMv4's authors. The protocol moves Internet Routing Registry records from an authoritative database to mirror systems. Operators use IRR data when building route filters and network configuration; a mirror that cannot tell whether it is current leaves operators guessing about the copy in front of them.

The previous version, NRTMv3, stitched together a database dump and later updates obtained through a separate query path. Serial numbers depended on the server instance, and the protocol offered weak signals for whether a mirror had caught up. NRTMv4 takes a different shape: servers publish snapshots and smaller delta files over HTTPS. A signed Update Notification File points clients to those files and carries their hashes. Clients can verify the signature and check that each downloaded file matches the listed hash.

That design reads cleanly on a page. Its meaning became less tidy when two codebases had to implement it. Romijn and RIPE NCC developed their implementations alongside each other but separately. When the behavior diverged, she initially suspected the RIPE version. Her own implementation had followed the rule she intended; the draft's wording expressed another one. The exercise exposed gaps in early versions before a single interpretation could quietly become the protocol by habit.

The review found a smaller error with the same lesson. An IESG reviewer noticed an IPv6 RPSL example labeled as a route object. It needed route6. No production failure followed from the example; it was caught while the protocol was being reviewed. Still, examples are where implementers often start. A mislabeled object can teach the wrong rule faster than a page of prose can correct it.

At RIPE 92 in May 2026, Romijn reported five interoperable implementations. She said RIPE NCC was running NRTMv4 in production, while IRRD worked as both client and server and other client implementations were available. RIPE's current Database documentation lists the production notification endpoint and public key. The IETF Datatracker now lists draft -11 in the RFC Editor queue, with final approval pending as checked on 2 November 2026.

That sequence gives NRTMv4 a stronger record than a draft that merely compiles for its author: separate implementations disagreed, the author went back to the submitted text, and a reviewer checked the protocol's own example. For infrastructure that distributes routing-registry records, the words have to survive contact with code written by someone else.