Sasha Romijn 的 NRTMv4 草案没有写出她想表达的规则

摘要

Sasha Romijn 是 IRRD 的原始开发者和维护者，也是 NRTMv4 的共同作者；该协议用于同步 Internet Routing Registry 镜像。
IRRD 与 RIPE NCC 分别实现后，双方对规则的理解出现偏差。Romijn 回看草案，发现文字表达的并非她想写的规则。
IESG 审稿人后来指出，一条例子把 IPv6 对象写成 route，应为 route6。截至 11 月 2 日，IETF 文件仍在 RFC Editor 队列等待最终批准。

协议草案最容易让作者误以为“我知道自己写的是什么意思”。Sasha Romijn 曾先认为，是 RIPE NCC 把 NRTMv4 理解错了；再读一遍文本，她发现实现并没有背离文字，草案没有写出她原本的意思。

Romijn 是独立开发者，也是 IRRD 4 版的原始开发者和维护者。她共同设计的 NRTMv4 负责把互联网路由注册表（IRR）的记录从权威数据库传给镜像。运营商会用这些记录生成路由过滤规则和网络配置；镜像是否同步，关系到他们手里的副本能不能反映当前状态。

旧版 NRTMv3 把完整数据库转储和之后的增量查询拆成不同流程。序列号依赖具体服务器实例，协议也很难明确告诉客户端镜像是否已经追上。NRTMv4 改用 HTTPS 发布快照和增量文件，再用带签名的更新通知文件列出文件及其哈希。客户端验证签名，并核对下载文件的哈希，确认数据和通知中的记录一致。

真正的考验来自两套代码。Romijn 的 IRRD 与 RIPE NCC 的实现并行开发、彼此独立。出现差异时，她最初怀疑对方实现有误。IRRD 执行的是她脑中那条规则，而草案文字指向另一条。两边对照后，早期草案中的几个漏洞才显形，团队有机会在一种解释变成默认习惯前把它们挑出来。

审稿阶段还发现了一个更具体的例子问题：IPv6 路由对象应该写成 route6，示例却用了 route。这不是生产事故，而是审稿人阻止错误示例进入协议文本。对开发者来说，示例往往比长段规范文字更直接；错一个对象类型，就会把读者带到另一条路上。

在 2026 年 5 月的 RIPE 92 上，Romijn 报告当时已有五个可互操作的实现。她说 RIPE NCC 已在生产环境运行 NRTMv4，IRRD 同时支持客户端和服务器端。RIPE 当前文档列出了生产通知文件地址和公钥。IETF Datatracker 截至 11 月 2 日仍把 -11 版放在 RFC Editor 队列，最终批准尚未完成。

这段经历说明，一套协议是否能跑起来，不应只看作者自己的实现。另一套独立代码能把草案中的每个词都变成一个必须执行的选择。路由注册表数据进入运营决策之前，文字得先经得起这种交叉检验。