摘要

  • RFC 1264 没有把“路由协议成熟”当成一个标签，而是分别要求可独立实现的规范、可管理性、安全架构、独立实现、完整特性测试、运行经验和规模分析。
  • RFC 4794 在 2006 年以时效性为由取消面向所有路由文档的额外统一规则，但明确保留 IESG 按 RFC 2026 要求实现或运行经验的权力，也允许工作组延续自己的流程。
  • 后续制度仍未把发布等同于部署：RFC 6410 把互联网标准与独立互操作、广泛部署和成功运行相连；RFC 7942 则把实现状态设为有用但自愿、且未必独立核验的记录。

进入评审室的是一柜证据

RFC 1264 面对的不是一段静态格式，而是分布式、实时、会随拓扑和规模改变行为的路由算法。一个实现能在一间实验室里运行，不代表另一份代码会作出相同解释；一张小网稳定，也不代表路由数量增加十倍后仍然稳定。

因此，它要求的不是一枚“通过”印章。规范和用途说明回答外部开发者能否仅凭文字写出可互操作实现；MIB 回答运行者能否看到并管理状态；安全架构说明预期如何认证路由消息；代码来源、测试场景、测试结果和运行报告则分别回答这些设计是否真的出现、相遇和工作。

这些记录不能相互代填。写出认证机制不等于认证已被两个实现正确执行；发布 MIB 不等于运行者已使用它发现故障；规范清晰也不等于网络已经部署。

“独立”首先是来源问题

RFC 1264 通常要求多个可互操作实现，其中至少两个独立编写。两款产品若共享同一代码库，可能同时继承同一种误读和缺陷。独立来源提高了测试强度：实现者若不必向原作者询问也能得到相同行为，规范本身才承担了更多协调工作。

所以实现清单要记录代码来源，测试报告要列出场景和结果。进入 Draft Standard 时，所有特性都要在至少两个实现之间运行，安全特性也必须被证明能够工作并提供预期保护。产品数量不能替代逐项覆盖表。

成功互操作仍有边界。它证明特定版本、输入和环境下的一次关系，不自动证明大规模多厂商运行、所有攻击路径或用户服务结果。

“有运行经验”必须带坐标

RFC 1264 要求运行报告写明拓扑、环境、时间、持续期、涉及实现、总体结果与结论，并实际锻炼重要特性。外部网关协议要携带完整外部路由；内部网关协议也要处理内部和外部路由，除非另有机制承担后者。

不同成熟阶段的负担不同。Proposed Standard 需要已有实现和主要特性测试，却不强制运行经验。Draft Standard 要求在运营互联网中，以中等数量路由器和中等复杂拓扑取得显著经验。完整 Standard 则要求更大规模、更复杂拓扑和多厂商运行。

这些是晋级条件，不是 RFC 1264 对某个协议完成情况的认定。标准动作、实现报告和现场观测仍应各有标识、日期和范围。

第二份报告要问“何时会坏”

这套制度最有价值的部分，或许不是数实现，而是要求第二份协议分析报告。它要解释关键算法，估计正常条件下的链路带宽、内存和 CPU 消耗，分析网络扩大至少一个数量级时的变化，并说明资源极限与不适用环境。

“可扩展”由此不再是形容词，而是一组假设、资源函数和边界条件。与现有路由协议的比较，也让改进主张可以被检查。

但模型仍不是现场事实。设计者预测的断点、实验逼近的断点、生产网络真正遇到的断点可能不同。把分析、试验和运行分开，才能避免一份乐观曲线冒充部署凭证。

2006 年改变的是控制面

RFC 4794 把 RFC 1264 重新归类为 Historic，理由是针对某一类协议附加统一规则会妨碍及时发布，而通用标准流程和现实压力已经能约束不合理方案。它没有宣称路由因此变得简单，也没有宣称运行证据失去价值。

撤销范围很精确：不再要求每一份路由文档都经过同一额外清单。Routing Area Directors 仍可依据 RFC 2026 要求实现或运行经验；工作组若认为有益，也可保留源自 RFC 1264 的程序。可管理性和安全性仍由更广泛政策承接。

于是，决定权从统一默认规则移到 IESG 和工作组。灵活性提高了，决策记录也更重要：是谁针对什么风险要求了哪些证据，又为什么认为现有证据足够？

两级成熟度仍然保留证据梯度

RFC 2026 已把 Proposed Standard 描述为仍可能因经验而修改甚至撤回的初级成熟状态。通常无需先有实现或运行经验，但若文档影响核心协议或可能产生重大运行影响，IESG 可以要求这些材料。它还提醒实现者，不要把 Proposed Standard 当成已经稳定的生产结论。

RFC 6410 后来把三层梯子缩成 Proposed Standard 与 Internet Standard 两层。高层门槛并未消失：至少两个独立互操作实现、广泛部署和成功运行经验仍是互联网标准的明确条件，还要检查严重勘误、无用复杂特性和许可问题。

即便如此，“广泛部署”也不是某一家网络的实时状态。它仍需版本、范围、时间和观测对象，不能替代具体运营者的配置与结果。

较轻的实现记录主动声明了局限

RFC 7942 为 Internet-Draft 提供自愿的 Implementation Status 章节。作者可以列出实现成熟度、许可、经验、联系人以及互操作报告，让工作组更早看到“运行代码”带来的反馈。

它的模板同时声明：条目不代表 IETF 背书，提交者提供的信息未必经过独立核验，也不是可用实现或完整特性的目录。这正是来源边界。实现状态能辅助决策，却不能替代测试工件、运行遥测或部署清单。

来源与证据边界

1991 年的路由专用规则来自 RFC 1264，通用标准权力来自 RFC 2026，撤销统一清单的决定来自 RFC 4794。两级成熟度来自 RFC 6410，自愿实现状态机制来自 RFC 7942。

这些文档确立流程、条件和变更理由，不证明任何具名路由协议曾满足全部条件，不证明某个实现条目经过独立核验，也不证明特定网络已经部署或获得结果。Historic 是制度状态，不会抹掉旧证据，也不会自动判定旧主张为假。