Summary

  • RFC 5237 删除了以保密信息进行 Expert Review 的分配方式；IPv4 Protocol 与 IPv6 Next Header 值此后通过 IESG Approval 或 Standards Action，并以公开可审查的规范为前提。
  • 协议号登记解决唯一性协调，不证明代码存在、实现互通、安全主张成立、已经部署或产生真实流量。公开规范只是分配证据，不是运行结果。

一份秘密要求所有后来者让出位置

RFC 2780 原先保留了一个特殊入口：涉及非披露信息时，可以由 IESG 指定专家，在保密条件下审查 IPv4 Protocol 值的申请。专家能看到材料，命名空间的其他使用者却不能。

这种安排保护了申请人的秘密，却把后果交给外部。数值一旦分配，协议设计者、操作系统开发者、防火墙维护者、报文分析工具以及后续标准工作都必须把它视为已占用，却无法检查这次占用解决了什么问题。

RFC 5237 终止的正是这种交换。设计仍可以保密，产品也可以继续开发；但保密偏好不再自动构成占用这一有限公共字段的理由。

拒绝协议号并不等于禁止协议。它只是拒绝把一个组织的不可见性成本转化为整个技术共同体的永久协调成本。

稀缺改变了举证责任

Protocol 字段只有 256 个可能值。RFC 5237 写作时称其中 55% 已在使用。这个比例属于 2008 年的历史快照，不能被当作今天的登记统计；它在文中的作用，是说明分配需要审慎核验。

规范保留了两条路径。Standards Action 服务于标准制定；IESG Approval 则允许确有必要的非标准轨或非 IETF 用途获得数值。

审查问题很具体：是否有稳定规范，是否确有使用群体，是否与已有分配重复，问题是否真的需要 IP Protocol 值，还是 TCP 或 UDP 端口更适合。它们衡量的是共同成本是否必要、可见且合比例，而不是产品路线图是否动听。

公开不等于成为标准

RFC 5237 要求规范可公开审查，却没有把每次分配都变成 IETF 标准。IESG Approval 的保留恰恰说明，合适的非 IETF 设计仍可进入登记表。

因此要拆开两张收据。公开规范使人能够核验申请理由；Standards Action 才对应特定标准程序。即使文档公开，如果功能重复或层级选择错误，也未必需要新协议号。

公开也不会自动解决知识产权、许可或商业权利。RFC 5237 修改的是登记前提，不是围绕设计的一切法律关系。

IANA 记录决定，而不是制造政策

IANA Protocol Numbers 表是分配及其依据的公共账本。RFC 5237 改变的是登记所遵循的政策。IANA 执行记录工作，表中的一行并不证明 IANA 设计了协议、认可商业价值或保证工程质量。

登记也不能向上膨胀成运行证据。它说明某个数值在规范记录下有了指定含义，但不证明存在可用实现、不同实现可以互通、安全机制有效、网络已经部署或真实流量正在发生。

这与 Lu Heng 对唯一性协调的边界一致：账本要防止冲突，却不能因此成为协议所有者；申请人获得一个条目，也没有取得剩余命名空间的权利。

实验有自己的出口

取消保密 Expert Review 并没有关闭实验。RFC 4727 为实验和测试保留了 253 与 254。设计可以在不先取得永久唯一含义的情况下运行验证。

实验值也有明确限制。多个实验可能相互干扰，中间设备和分析器可能特殊处理或完全不支持它们，局部成功更不能赋予全球永久语义。

这种次序更诚实：先在允许临时歧义的范围里验证，再在协议、使用群体和公开证据足以承担全球协调成本时申请持久分配。

具体规则不能机械外推

RFC 5237 明确表示，它不讨论其他参数空间在保密协议下如何分配。不同登记表的容量、冲突代价、委派结构和运行后果并不相同。这条具体政策不能直接复制到所有 IANA 命名空间。

但它揭示的激励结构可以复用：保密给申请人带来私益，占用共享标识却制造公共成本。政策必须决定谁承担这两个目标之间的差额。在这个 256 值字段里，答案是申请人不能把秘密变成不可复核的永久保留。

RFC 8126 后来更新了登记政策术语，可用于理解 Specification Required、Expert Review 与 IESG Approval 等机制；它不能抹去历史事实。RFC 5237 是 2008 年发布的 BCP 37，其动作是针对 RFC 2780 的一个特定选项。

把分配放在运行证据之下

完整链条应当逐项保存：收到提案，规范可公开检查，授权路径作出决定，IANA 登记数值，实现者编写代码，多个实现完成互通，网络部署，最后才可能观察到运行效果。

前一阶段成功，后一阶段仍可能失败。公开文档可能暴露设计缺陷；获得数值后可能无人实现；两个实现可能不能互通；可用代码可能从未部署；部署报文也未必产生预期结果。

Lu Heng 所强调的“现实而非倡议”在这里是一条证据纪律。公开规范优于私下承诺，但公开文档仍不是运行代码；登记行更不是性能报告。

Sources

Additional standards record

  1. RFC 5237 纯文本
  2. RFC 5237 信息页
  3. RFC 5237 Datatracker 页面
  4. RFC 5237 历史
  5. RFC 5237 勘误
  6. RFC 5237 引用记录