摘要

  • RFC 6410 将标准轨道从三级改为两级，但既有 Draft Standard 文件在明确重分类前保留原分类。
  • 新规则允许按新的部署条件晋级，或由 IESG 在两年后选择降回 Proposed Standard；没有自动清理旧状态。

分析

旧一级要求什么

1996 年 10 月的 RFC 2026 设定了三个标准轨道成熟度：Proposed Standard、Draft Standard 和 Internet Standard。要进入 Draft Standard，至少需要两个来自不同代码基础、彼此独立且能够互操作的实现，并有足够成功的运行经验。工作组主席还要记录符合条件的实现及其互操作测试。Draft Standard 是已发布规范的成熟度分类，不是 Internet-Draft 的另一种叫法。

再往上一级，回答的是另一个问题。RFC 2026 把 Internet Standard 与显著的实现和运行经验、以及“该协议或服务对互联网社区有重大益处”的广泛共识联系起来。阶梯把早期实现证据与更广泛的成熟度区分开来。

2011 年改了什么

RFC 6410 指出，前一个十年里只有很少规范沿成熟度阶梯晋级，大多数仍停留在 Proposed Standard。它把 Draft Standard 和 Standard 合并为一个 Internet Standard 级别。部署与运行经验仍是晋级条件：至少两个彼此独立、能够互操作的实现需要广泛部署并成功运行。新条件也检查会导致互操作失败的勘误，以及会显著增加复杂度却未被使用的功能。

修订还删掉了两项程序义务。RFC 2026 要求对未到最高级别的规范每年复审；RFC 6410 说这项复审实际上没有发生，因此取消了该周期。它也不再强制提交正式互操作报告。测试仍然重要；RFC 6410 认为部署和使用可以证明互操作，RFC 5657 仍可作为编写报告的有用指南。

过渡不等于全量迁移

新规则对旧状态分别处理：Proposed Standard 继续保留为 Proposed；既有 Internet Standard 立即改称 Internet Standard。已经标为 Draft Standard 的文件则不同：没有明确行动，它继续保留旧分类。符合新条件时可以晋级。RFC 6410 获批成为 Best Current Practice 两年后，IESG 也可以选择把它重新分类为 Proposed Standard。

这既不是自动降级，也不是自动晋级，更不是对整张清单的批量重置。除非后续决定改变它，旧标签就继续附着在文档上。RFC 6410 没有统计有多少文档留在这一状态，也没有说明每份文档后来何时被重分类。

标签与实际网络

RFC 6410 简化了未来的晋级路径，却没有把分类变成在用软件的普查。一个沿用旧阶梯标签的 Draft Standard，单凭这一点不能证明现在仍可互操作或已经广泛部署。反过来，2011 年后不再要求正式报告，也不代表测试失去意义：新条件仍要求独立实现和成功使用。

记录范围很窄：它解释了一次标准流程修改及其过渡规则，不会告诉我们每个运营者部署了什么。当旧标签比产生它的流程存续得更久时，运行层面的差异很容易被忽视。

来源