摘要

  • 10 月 28 日提交的个人 Internet-Draft 为 RPKI-to-Router 协议提出事件推送、周期推送和六种新报文；路由器先订阅，也能退订。
  • 事件报文 Push Notify 只有订阅号、变更类别和序列号，没有变更对象。周期报文 Periodic Update 才携带数据；现行 RFC 8210 已有缓存主动发送的 Serial Notify。

一条 ROA 变了，运维人员需要的不是“缓存已发现变化”这句话，而是路由器已经接收了哪一版验证数据。新发布的 RTR 推送草案把紧急响应写进动机，甚至提出路由更新应在数秒内传播。沿着报文字段读下去，立即到达的是警报；装货的车有另一个时刻表。

RFC 8210 的 Serial Notify 本就允许缓存不等请求先通知路由器。路由器收到后，可以马上发 Serial Query 或 Reset Query，无须守着刷新定时器。现行 8210bis 草案保留这个安排：缓存发信号，路由器决定是否立刻查询，响应再送变更记录。把整个过程笼统叫作“拉取”，容易把第一声主动警报抹掉。

新提案在初次同步后添加订阅。路由器可以选事件通知、周期更新，或两者兼用；也可以取消订阅。六种新报文包括订阅请求与回应、退订请求与回应、Push Notify 和 Periodic Update。缓存要为订阅者维持状态，运营方则有理由追问：增加这些状态究竟省下了多少从对象变更到路由器接受的时间？

事件模式的 Push Notify 报出订阅号、通知类别和序列号。草案举出 ROA、ASPA、路由器密钥等变化，但包格式没有承载这些对象的字段。它也没有画出通知后送达变更数据的交互。这个包能比下次定时查询先到；它自己不能把路由器的验证表换成新内容。旧协议的 Serial Notify 已经能催促路由器立即查询。

Periodic Update 才是载货通道：在商定的间隔内发送 Cache Response、零个或多个数据报文，最后用 End of Data 收尾。草案要求缓存写入它认为路由器持有的序列号；若与路由器本地序列号不同，路由器必须拒绝处理这些数据。这道闸把“缓存想推”与“路由器可接受”分开，也决定速度测试必须算到接受为止。

IETF Datatracker把文件列为个人 Standards Track 草案，状态仍是 I-D Exists。文本没有给出可复现的时延对照或部署试验。下一版若补齐事件后的数据路径和同口径计时，速度承诺才有可检验的对象；当前能确认的是一枚新警报和一条定时送货线。