摘要

  • RFC 3167 没有修改 RFC 1745 的路由机制；它请求把这份 1994 年的标准轨 RFC 转为 Historic，理由是相关机制从未部署于公共互联网，且实现复杂度很高。
  • RFC Editor 当前的 RFC 1745 信息页标注 Historic，而归档正文首页仍保留发布时的“standards track”说明。两者对应不同时间，而非必然相互矛盾。

这种差异就在文档首页。RFC 1745 的原始首页说它规定了一项“standards track”协议；今天打开 RFC Editor 的信息页，归档正文上方却显示“Historic”。前一句是当年发布的状态说明，后一个标签是目录当前给出的分类。它们不是同一时点、也不是同一类记录。

RFC 3167 提供了这次状态讨论的线索。它于 2001 年 8 月以 Informational RFC 发布，标题直言“请求将 RFC 1745 移至 Historic 状态”。David Meyer 与 John Scudder 写道，他们在审查 BGP 相关标准时注意到，RFC 1745 描述的 BGP/IDRP 与 OSPF 交互机制从未部署在公共互联网，而且实现会带来显著复杂度。于是他们提议重新分类。

“提议”不能改写成“决定”。RFC 3167 记录的是一项请求，其自身的备忘录状态也说明它没有规定任何互联网标准。它能证明两位工程师公开提出过改变 RFC 1745 地位的理由，但它本身不是 IESG 的决定通知，不是一份有日期的全网部署调查，也不是状态更新的完整程序记录。当前 RFC Editor 信息页另行显示 RFC 1745 如今列为 Historic。现有材料足以确认请求和当前标签，却不足以补写两者之间没有出现在这些记录中的程序环节。

这里至少有两只文档时钟。RFC 1745 于 1994 年 12 月发布，首页的状态文字描述的是出版当时。那一页是历史档案的一部分；目录元数据则可以反映后续变化。状态更新不要求把原始 RFC 悄悄改写。保留旧首页反而让读者看见当年正式发行时的说法。若把档案正文当作实时状态面板，就会把出版记录误当成现行目录。

1996 年的 RFC 2026《互联网标准制定流程》解释了 Historic 的含义。第 4.2.4 节把它用于被更新规范取代、或因其他原因被认定为过时的规格。第 6.4 节则规定，退出标准轨应由 IESG 批准状态变更，经过 Last Call 和通知程序；工作组、Area Director 或其他相关方都可以提出请求。这些条款描述的是该版流程框架，不能证明 RFC 1745 的状态究竟在哪一天、经由哪个具体决定而改变。

Historic 不表示技术文本被删除，也不等于任何设备都不再实现它。RFC Editor 仍公开提供 RFC 1745。这个标签说明的是它在标准成熟度体系中的位置，不是全球运行代码的清单。类似地，RFC 3167 关于“公共互联网从未部署”的陈述应归于作者：短文没有给出普查方法，也不能据此断言任何私有或实验环境都从未使用过该机制。

因此，这段短短的档案最重要的不是再讲一遍 RFC 1745 如何交换路由，而是看清不同凭据各自能证明什么：技术文件曾经发布；作者后来提出使用状况不支持其原有地位；一项请求寻求重新分类；今天的目录显示 Historic。RFC 6410 又在 2011 年把标准轨的成熟度级别从三级缩为两级，并取消年度审查要求。那是更晚的制度变化，不是 RFC 1745 状态变更的解释；它说明描述标准状态的分类本身也有历史。严谨的读法，是把出版文本、请求、可能存在的决定和当前目录分别保存。

来源：RFC 3167，关于 RFC 1745 的状态请求；Datatracker 中的 RFC 3167；RFC 1745 原文；RFC 1745 当前信息页；Datatracker 中的 RFC 1745；RFC 2026，互联网标准流程；Datatracker 中的 RFC 2026；RFC 6410，标准成熟度级别；RFC 6410 当前信息页；RFC 系列指南。