摘要

  • RFC 2000 同时记录两项彼此独立的判断：一项是规范处于标准化流程的哪一层，另一项是特定适用范围内的系统应以多大强度实现它。
  • 被列入、达到某成熟度或标为 Required，都是带日期和范围的制度证据；它们不自动证明部署、实现一致、互操作成功、流量、采购授权或今天仍有效，Historic 也不证明设备已经消失。

RFC 2000 在 1997 年 2 月以 STD 1 发布，取代 RFC 1920 等前版。它说这类汇总预计约每季度发行，并直接告诫读者：6 月 16 日之后不要再用这一版。到了 6 月，RFC 2200 接替它，又给出 10 月 15 日的新期限。版本更替不是例外，而是这套记录方式的组成部分。

因此，清单中每一行首先回答的是“当时如何分类”，而不是“现实中有多少机器在跑”。RFC 2000 自己就承认，一些没有得到 IESG 批准的厂商协议已经被广泛实现。正式地位与实际采用可以相互分离。

第 4 节把分类画成两个独立坐标。成熟度 STATE 包括 Standard、Draft Standard、Proposed Standard、Experimental、Informational、Historic；适用性 STATUS 包括 Required、Recommended、Elective、Limited Use、Not Recommended。矩阵中的 X 只是常见组合的大致分布，不是市场份额、节点数量或流量统计。

第一条轴描述规范地位。Standard 表示 IESG 已把它确立为互联网官方标准，并分配 STD 编号。按照几个月前发布的 RFC 2026，Draft Standard 需要至少两个来自不同代码库、独立且互操作的实现，并积累足够的成功运行经验；但规范仍提醒，大规模生产可能暴露未预见行为。Proposed Standard 通常连实现与运行经验都不是前提，它证明规范已经进入轨道、相对稳定并接受过审议，不证明多家产品已经一致工作。

三种非标准轨道标签也不能偷换含义。Experimental 保存研究与开发成果，RFC 2000 明说它们进入汇总是为社区提供便利，不是标准化证据。Informational 可能承载其他标准组织或厂商材料。Historic 表示规范被后续发展取代，或因缺乏兴趣而不太可能成为标准。这里判断的是文件与制度路径；清单没有扫描现场资产，也没有把仍运行的旧实现关机。

第二条轴处理的是适用范围内的实现建议。RFC 2000 用“系统必须实现”解释 Required，却随即提醒：主机、网关、路由器和服务器的情况不同，一个词不足以覆盖所有场景。RFC 2026 把边界写得更清楚——只有在对应 Applicability Statement 指定的域内，Required 才是达到最小一致性的必要条件。Recommended 并非最小一致性的硬要求；Elective 不制造一般性义务，但一旦选择实现，就要遵循规范；Limited Use 与 Not Recommended 限制一般使用，却都不能说明还有多少设备保留该协议。

两条轴的控制动作也不同。RFC 2000 说，沿标准轨道推进的是 STATE 变化，STATUS 则可在任何时候重新审议。一个规范可能更加成熟，却仍只适用于某类系统；也可能在狭窄领域很重要，却不成为普遍要求。把两列压成一个“标准等级”，会抹掉做决定的人与适用范围。

这份快照内部甚至留下了不同更新时钟的痕迹。第一节仍称 RFC 1602 是标准流程的权威说明，而“新 RFC”部分已经列入 1996 年 10 月取代 RFC 1602 的 RFC 2026。这不能证明编辑者为何保留旧句，却能证明一份汇编不会因为拥有同一个发布日期，就让每个段落同时更新。

后来，制度和载体都继续变化。RFC 6410 在 2011 年把三层标准轨道合并为 Proposed Standard 与 Internet Standard 两层，并把独立实现、互操作、广泛部署和成功运行经验保留在高层门槛中。RFC 7100 在 2013 年退役周期性 STD 1 汇总，因为它多年未能保持更新，读者已经改用 RFC Editor 在线清单。

RFC 2000 今天仍有价值，但价值在于边界清楚：它证明 1997 年一个时间窗口里的官方分类、两项不同判断的编码方法，以及继续核查所需的线索。要证明实际采用、互操作、现存资产或当前有效性，还必须拿出实现清单、测试、遥测、采购范围和现行状态来源。

来源：RFC 2000、RFC Editor 记录、RFC 1920、RFC 2026、RFC 2200、RFC 6410、RFC 7100。