摘要

  • Datatracker 记录显示，draft-ietf-intarea-legacy-registries-00 于 2026 年 9 月 11 日获准作为 INTAREA 工作组版本发布；它仍是 Internet-Draft，并非 RFC。
  • 草案拟关闭一处注册表，为一处规定 IESG Approval，为两处规定 First Come First Served，并删除 TTL 注册表或改写其说明。
  • 五处 IANA 页面尚未出现这些结果。面向公众的逐项执行凭证，应把草案状态、批准环节、执行时间和历史条目的保存方式连接起来。

新文件名只证明工作归属改变

当前 Datatracker 页面把“Updates to Legacy IANA Registries”列为 INTAREA 的活跃工作组文档。工作组版本历史在 9 月 11 日记录了两项动作：工作组 -00 获准发布，并取代此前的个人草案系列。

这不是毫无意义的改名。工作组采纳意味着 INTAREA 愿意把问题纳入共同议程，继续修改文字并对后续处理负责。但它没有让整份草案成为 IETF 已批准的拟议标准，更没有让“请 IANA 执行”的将来时文字自动变成完成记录。

个人草案历史把这层边界写得很清楚。8 月 27 日，主席记录工作组对采纳形成共识，同时说明有一项反对意见已经被听取和讨论；主席还强调，文档处理的是注册表维护程序，而不是对 IPv4 的未来表态。换言之，工作组可以决定接手一个可处理的问题，而不必先假装每一项理由都已无争议。

从个人版 03到工作组版 00，拟议动作没有实质变化。可见差异是一处语法订正和致谢名单增加一人。新闻事实是治理责任完成了一次交接，而不是技术政策突然改写，也不是 IANA 已经收到了可执行结果。

“清理”其实包含四种治理动作

这份短草案把若干历史遗留问题放在一起，但它没有对所有注册表采用同一种处置。

对于 NetWare/IP Option Type 63 Sub-Option Codes，草案要求关闭注册表，理由是 NetWare 已不再扩展。关闭意味着不再接受新登记，却不使旧值失效。RFC 8126明确规定：关闭后的注册表仍保留有效信息，已有登记仍可更新，历史内容继续可查。

对于 IP Option Numbers，草案并未要求关闭，而是拟补上 IESG Approval。RFC 8126 把它描述为少用的例外通道，不应成为日常方式。IESG 可以逐案批准，也可以要求材料或征求公众意见。它提高的是决策门槛和责任归属，并非宣布今后绝不分配 IPv4 选项编号。

Machine Names 与 Terminal Type Names 的方向恰好相反：草案拟为两者规定 First Come First Served。按照 RFC 8126，这是一种无需审查、只需最少文件的低门槛程序。草案承认可能出现无意义申请，并依靠 IANA 的常识性过滤。两张名单沉寂多年，但“给出明确入口”和“封闭入口”仍是完全不同的政策。

对于 IP Time to Live Parameter，首选动作是删除。草案认为 IPv4 TTL 可由节点操作系统或应用自行决定，这个注册表本就不应存在；如果无法彻底删除，则改写现有说明。删除页面、保留页面但换说明，以及关闭登记，各自留下不同的公共记录，不能都叫作“弃用”。

五处公开页面仍显示旧状态

IANA 的 DHCP 与 BOOTP 参数页仍列出 NetWare 子选项，登记程序仍是 Not defined，并未标记关闭。

IPv4 参数页对 IP Option Numbers 仍写着 Not defined。IP Time to Live Parameter 仍在页面中，并保留默认 TTL 为 64 的说明。实验用选项值也仍单列可见，但页面没有显示草案拟定的 IESG Approval。

Machine Names仍标作 Not defined；Terminal Type Names甚至仍保留带问号的 Not defined?。两页都没有出现 First Come First Served。

这种差异不构成 IANA 拖延的证据。RFC 8126 说，IANA 通常在文档获准出版时采取行动，而这份文本仍处于草案阶段。INTAREA 文档列表回答“文档走到哪一步”；IANA 页面回答“当前规则是什么”。用前者推断后者，正是报道最容易犯的状态错误。

被采纳的文档仍携带争论

IETF 126 的 INTAREA 会议记录保存了两类担忧。一位与会者认为，如果事实上堵住新的 IPv4 选项编号，可能妨碍受限域中的合理用途；另一位则强调，旧材料停止使用后仍要保存信息。作者回应说可使用实验值，而且已有注册项不会消失。

采纳讨论邮件还质疑草案如何概括 IPv4 选项的可靠性，并担心理由文字日后被扩大引用。邮件中也有明确支持。主席作出采纳决定后，这些发言没有失效，而是成为工作组继续完善文本时必须面对的记录。

准确的说法因此只能是：INTAREA 决定接手这份文档。它尚未最终批准四类 IANA 动作，也未证明任何页面已经改动。

为每个动作保留独立凭证

从草案指令到公共结果之间，还缺一条容易核验的连接。我建议为每一项操作发布一份简洁的注册表执行凭证。这是一项编辑建议，不是 IETF 或 IANA 已宣布的功能。

凭证应列出注册表的准确名称与网址、变更前的带日期快照、草案版本与哈希、所请求的动作词、工作组和 IESG 的后续状态、IANA 执行确认、生效引用、变更后快照，以及旧值如何保存。

Machine Names 和 Terminal Type Names 即使采用相同程序，也应各有一份记录，因为执行时间可以不同。NetWare 的结果应写“关闭并保留条目”，不能简写成“删除”。TTL 则要明确是页面移除还是采用备用说明。如果后续版本改变 IP Option Numbers 的程序，旧请求也应留在时间线上，而不是被覆盖。

这不是给小问题加上沉重流程。相反，它让公众能用最少信息区分四个事实：谁提出、谁接手、谁批准、谁执行。工作组文件名只证明第二项。当前 IANA 页面证明现实状态。二者之间的每一步，仍需要自己的证据。

来源

  1. IETF Datatracker — 当前工作组文档
  2. Datatracker — 工作组文档历史
  3. 工作组版本 00
  4. 被取代的个人草案历史
  5. 个人版本 03
  6. IETF 126 INTAREA 会议记录
  7. INTAREA 采纳讨论
  8. IANA — DHCP 与 BOOTP 参数
  9. IANA — IPv4 参数
  10. IANA — Machine Names
  11. IANA — Terminal Type Names
  12. RFC 8126 — IANA 注册程序指南
  13. INTAREA 文档列表