Summary

  • 10月26日的 IANABIS 草案要求 IANA 为无需 IETF 流 RFC 即可登记的新注册表设置“变更控制者”字段，范围包括先到先得、专家审查、需要规范和需要 RFC 等程序。已有表格若缺这一栏，未来先增加空栏。草案仍是草案。
  • 2017年的 RFC 8126 早已建议明确变更控制。IANA 现有的 JSONPath 函数扩展表把专家和控制者分开记载：专家是 Glyn Normington，五项登记的变更控制者是 IETF。

登记完成后的第二道门

协议注册表通常在新号码分配时受到关注。一个号码被写入，冲突检查通过，大家便继续编码。随后真正麻烦的请求来了：某个旧号码的说明、引用或联系人需要更新。编号本身没有变，公共记录却要动。原作者的参与经历不是永久授权；技术专家可以判断改动是否合理，也未必是有权批准改动的一方。把这些角色揉成一个“熟悉此事的人”，是漫长维护工作的坏习惯。

现行 RFC 8126 已经识别了这道门。由 IETF 流 RFC 建立的注册表及登记项，默认由 IETF 经 IESG 行使变更控制。对于接纳该流程之外登记的表，它建议作者说明控制权归属；对于新建的先到先得和专家审查注册表，建议设置控制者字段。也就是说，草案要修补的不是概念缺口，而是建议与实际表格之间的距离。

IANABIS 的 -04 版草案 把动作写得更具体。第11.2节要求 IANA 在所有不要求 IETF 流 RFC 的新登记程序所用注册表里创建该字段，包括先到先得、专家审查、需要规范及需要 RFC。第2.5节还明确，IETF 流登记通常在字段里写 IETF，IESG 是代表它行事；若原始 RFC 明确指定 IESG，则按该文件处理。这一个词的差别决定读者看到的是机构权属还是执行机关。

空格是诚实的，比假签名强

旧表格的处理更值得看。草案说，IANA 今后会给缺字段的相关现有注册表增加空字段。空格没有自动确认任何一个作者、联系人或专家可以签字。它只是把缺失公开化，让下一次改动时不能轻易把熟人的邮箱当成制度。草案没有给出受影响旧表数量，也没有规定填满这些空格的日期。若后续出现清单和逐表认定方法，我们才知道迁移规模与速度。

IANA 现有的 JSONPath 函数扩展表 展示了另一种状态。其登记程序为专家审查，页面列出 Glyn Normington 为专家；length、count、match、search、value 五行则各写 IETF 为变更控制者。专家与控制者在同一页上各有位置。这个表早已存在，不能算成草案已经落实的证据，却能说明字段为何有用：技术审查者和批准后续改动的主体，读者不必猜。

草案第3.1.2节还将登记程序默认用于修改程序，除非注册表另有说明。对不通过 RFC 作出的登记，IANA 可以确认并批准联系人或控制者信息更新，必要时询问专家或领域主任。实际治理因此发生在两处：表里写的是谁，改写表里这个名字又遵循什么程序。只有前者而没有后者，任何人都能把铭牌换成自己的名字。

目前的生效依据仍是 RFC 8126；IANABIS 文本是工作组 Internet-Draft。下一版文本、IESG 状态以及 IANA 实际注册表的变动记录，才会告诉我们这项更强的写表指令能否落地。