摘要
- IESG 于 8 月 28 日启动
draft-ietf-sidrops-publication-server-bcp-10的 Last Call；该文件拟成为 Best Current Practice，Datatracker 所列截止日为 9 月 11 日。 - 草案沿用 BCP 14 的大写要求词，同时明确说明：这些词在此强调运行重要性，并非正式的实施要求。
- 若文件最终成为 BCP，它能够证明文本经过 IETF 审议，不能证明某个具名发布服务已逐条落实，更不能替代审计、合同、监管或本地路由决策。
- 运营者需要一份逐项实施回执：对应文件版本和章节，说明架构、当前状态、例外、测量口径、观测窗口、恢复、RRDP 会话重置、通知与重新同步结果。
- 现有证据没有认定任何 RIR、NIR、CA、发布服务商或 CDN 合规或违规，也没有证明草案已经获批。
签名完成之后，还有一段路没有走完
RPKI 路由意图从签名到被网络使用，要跨过几种控制面。认证机构生成签名对象，RFC 8181 发布引擎接收变更，RRDP 和 rsync 仓库供依赖方拉取，网络运营者最后决定如何用于本地策略。
8 月 28 日进入 Last Call 的版本 10，讨论的正是中间这段。文件 Best Practices for Operating Resource Public Key Infrastructure (RPKI) Publication Services 拟成为 BCP。它不改变签名含义，而是整理功能隔离、高可用、恢复、同步、网络依赖、缓存与多节点一致性等十多年运行经验。
这段中间层很容易被“可访问”掩盖。CA 可以已经正确签发对象，而发布引擎不可用；引擎可以接收变更，外部节点仍呈现旧快照；恢复可以让内容退回；通知文件也可能先于所引用的 delta 或 snapshot 到达。
签名能回答对象由谁产生、有没有被改动。它不能独自回答对象何时进入公开视图、恢复是否丢了状态、所有节点是否一致。草案的价值，就在于没有把这些问题都塞进“RPKI 正常”四个字里。
大写的分量与权力边界
RFC 2119 定义 MUST 与 SHOULD 的规范强度；RFC 8174 明确，只有全部大写时才具有 BCP 14 的特殊含义。
发布服务草案照例引入了这套词汇，随后加了一条罕见但关键的注释：大写词是为了强调对运行的重要性，并不要求把它们当作正式实施要求。
若只读前一句，很容易把未来 BCP 包装成一套自动生效的认证标准。若只读后一句，又会把所有 MUST 降格成可有可无的建议。正确读法是把文本权威与实施证明分开。
IETF 可以通过公开审议形成强有力的最佳实践。RFC 7841 的类别与状态文字记录文件来源和共识，却不会检查运营者的机器，也不会自动产生审计范围、服务承诺或认证标志。
换言之，BCP 说的是“值得怎样运行”；具体运营者必须另行回答“我实际怎样运行，谁在何时看见了什么”。
一个 uptime 数字装不下三个表面
草案要求公开仓库内容与发布引擎都保持高可用，却给出了不同的风险机制。
面向 CA 的引擎停机，发布者无法送出新签发或新撤销的对象，拖久后签名材料会变旧。RRDP 或 rsync 停机，则阻碍依赖方拉取当前状态。两者风险机制不同。
因此，99.99% RPKI 可用性 没有说明究竟测了什么。至少应分开：发布写入端、RRDP 获取端、rsync 获取端。每项都要有分母、测量点、失败定义与维护排除规则。
草案还建议把发布引擎与公开请求服务放在不同机器上，防止公开访问的负载拖垮写入能力。它建议进行闭环监测：重新签发一个受控对象，记录预期出现时间，再从公开路径记录实际出现时间。这比测试一个 HTTP 端点是否回包更接近真实控制面。
闭环指标也必须带上下文。草案引用的研究在被研究的 CA 与仓库中观察到 15 至 95 分钟的传播时间。这不是全行业 SLA，更不是每个对象都必须落在其中。要把它变成运营者证据，必须说明对象类别、起止事件、观测位置、样本期、分位数、失败和剔除项。
恢复时，谁都不能只说“备份成功”
草案对内容回退的处理尤其具体。若服务器恢复导致内容退回较早状态，服务器必须重置 RRDP 会话；运营者还应尽快通知依赖的 CA，让它们进行完整重新同步。
这是一条责任链：备份版本、发现回退、RRDP session_id 变化、发布者通知、RFC 8181 list 核对、完整重发与外部一致性确认。
草案建议 CA 在发送变更之前先列出仓库状态；本应原子生效的一组变更，应放在一个多元素请求中，以减少部分成功造成的不一致。它也承认协议的限流与退避信号不足，因此，除非另有约定，计划性同步不应频繁到十分钟一次以上。
这些规则把不同主体的动作接起来。RRDP 重置不能证明 CA 已重发；CA 重发不能证明每个公共节点已呈现；外部探针也不能独自解释先前为何回退。
只公布月度 uptime，会让一次真正的恢复过程在最需要追责时失去细节。
serial 在增长，不等于证据已经完整
RRDP 使用 session_id 与 serial，依赖方可借此判断是继续拉取 delta，还是下载完整 snapshot。不可变的 snapshot 和 delta 也便于缓存。这套设计让分发更有效率，并能提供某个时点的一致视图。
但 serial 增长，只证明某个会话公布了后续修订。它不证明发布者期待的全集都被正确接纳，不证明负载均衡后的每台后端都暴露相同文件，也不证明所有依赖方已经看到变化。
因此，草案要求新通知文件不得先于所引用的 snapshot 和 delta 对外可见；多后端部署也必须提供一致视图。文件出现的先后顺序本身就是状态，不是部署细节。
RFC 9286 的 manifest 提供另一种有边界的证明：文件名和哈希可帮助发现特定的旧版本替换、删除或传输中修改，却不检测维护通知、双栈可达、备份新鲜度、CDN 缓存或发布者支持。
若把 serial、manifest、端点响应和恢复记录统一叫作“符合 BCP”，就抹掉了它们各自能证明和不能证明的内容。
集中发布是一项工程选择，不是特许权
草案指出，从实践看，自建仓库比大型专业机构提供的服务更常遇到可用性问题；发布点越多，依赖方负担也越大。因此，它建议父 CA 向子 CA 提供发布服务，子 CA 在可用时优先使用；父 CA 不提供时，也可选择可靠第三方，而非再建一个孤立仓库。
这是规模与可靠性的判断，不是给 RIR、NIR 或商业服务商授予独占权。文件同时承认，一个对象少、变化不频繁的小型仓库，靠适度配置也能实现高可用。对孙级 CA，它列出了直接注册、代注册与发布代理等不同路径。
拓扑建议也不是一刀切。公开服务最好同时支持 IPv4 与 IPv6，RRDP 与 rsync 可放在不同网络，地址与 AS 不宜完全受制于只能通过该仓库发布修复信息的权威。可与此同时，使用其他机构管理的地址或网络又引入新的依赖。运营者需要公开选择逻辑和测试结果，而不是暴露可被攻击的详细拓扑。
一份实施回执应先标明架构：自建、父 CA 承载、第三方或代理。对每项控制，可以写“已实施”“不适用”“计划中”“例外”或“未知”。有理由的不适用是真实状态；无范围的“全部符合”不是。
应当公布什么样的实施回执
第一栏是身份：运营者、服务名称、架构、公开仓库标识、适用客户范围，以及精确到版本的草案或 RFC。遵循 IETF 最佳实践 若没有版本，会在下一次修订时立即变得含糊。
第二栏是逐项状态。每个重要章节有稳定编号，记录当前结论、作出结论的人、复核时间、例外理由和适用边界。私钥、凭据、私人发布者身份和安全敏感拓扑不进入公开回执。
第三栏是测量定义。闭环传播要写对象类别、起点、终点、观测点、窗口与失败；可用性要拆分引擎、RRDP、rsync；CDN 要说明通知文件缓存规则及观测；负载均衡要有不会泄露攻击方法的一致性测试。
第四栏是变更与恢复。维护、内容回退、会话重置、发布者通知、重新同步请求、完成证据和残留分歧都要保留。修正追加新版本，不覆盖旧记录。
最后一栏说明证据是谁提供的：运营者自述、独立观测、合同审计，还是事故复盘。它必须明确时间与系统范围。除非未来真的出现相应机制，任何一栏都不能写成“IETF 已认证”。
这种回执没有一个漂亮徽章那么省事。也正因为不省事，读者才能逐项质疑。
目前不能得出的结论
Last Call 不是批准。草案可能修改，IESG 仍需评估，也可能不发布。当前没有 RFC 或 BCP 编号。
作者来自 RIPE NCC、ARIN、APNIC、BSD 等机构，不等于这些机构已经逐条实施，更不等于它们接受了同一套审计。现有来源也没有显示哪家运营者发生了隐瞒、回退或违规。
BCP 不会取代服务合同、采购要求、法院命令或网络本地路由策略。RFC 8181、RFC 8182 与 RFC 9286 分别解决重要技术状态，却没有让一篇文档的标题自动成为运行证明。
稳妥结论只有一条：IETF 正在形成一份细致的 RPKI 发布运行实践。它若获批，文献权威会增强；某个服务究竟做到了什么，仍要看该服务自己的证据。
来源
会员简报
档案背景详情
使用相应会员等级登录，即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance