摘要

  • IESG 于 8 月 27 日对一项提案启动最后审议征询。提案允许 IANA 在创设文件获批成为 RFC 之前，先建立一张为期两年、公开标明临时状态的登记表；之后可能续期、关闭或转为正式登记表。
  • 登记表本身和表内条目可能沿着不同的时间线演变。除了创建日与到期日，还应有一份公开的状态迁移账，把具体草案版本、共识与批准链、当时适用的临时准入程序，以及后续的规则变更、续期、关闭和转正连在一起。

协议参数有一种特殊的传播方式：数字很容易被复制，来历却很容易丢失。工程师把一个代码点写进程序、测试向量或设备配置时，通常会保留数值和含义，却未必把“临时”“等待哪份文件获批”“由谁批准”一并带走。

如果临时的只是某一行，风险已经存在；如果连整张表都是在创设 RFC 获批前建立的，治理问题就多了一层。

8 月 27 日，IESG 对 《提前创建 IANA 登记表》启动最后审议征询，实质意见的截止日期是 9 月 10 日。当前 02 版草案拟进入标准轨道，但它仍是一份工作文件，并非已经通过的 RFC。

提案要解决的协调难题很现实。一个工作组可能在甲草案中定义新登记表，乙、丙草案却已经需要从中取得数值；IETF 之外的标准组织也可能急需持续分配。工作组若先维护一份内部清单，等正式登记表上线后，旧清单可能继续流传，形成两个事实来源。若一律等到创设 RFC 获批，实施验证又可能被拖延。

因此，提案选择让 IANA 提前把表建起来。这并非把现有登记表多填一行，而是提前启动一个新的公共协调界面：谁可以批准条目、用什么临时规则、何时关闭，都要在正式制度尚未落定时运行。

建表权经过四个环节

草案作者先向工作组主席提出请求，说明要创建哪张表、放在哪里。主席核对条件，并判断工作组是否对“提前创建”形成共识。随后由领域主任审查；如果登记表可能始终无法转正，领域主任可以据此作出判断。只有这些环节完成，主席才向 IANA 提交建表请求。

IANA 会在适当位置创建登记表，标注临时状态，并公开创建日与到期日。初始期限为两年。到期前，IANA 会询问主席和领域主任是否再延长两年。第一次延长之后，若还要继续续期，则必须再取得 IESG 批准，并说明理由和创设文件的推进计划。

若延期未获批准，IANA 将关闭登记表并注明状态。主席也可随时要求关闭。另有一个暂停条件：只要登记表在创设文件进入 IESG 审查时仍然有效，它就不会在审查期间到期。若提前建表引发安全或其他问题，IANA 还可请求 IESG 暂停这套程序。

这些门槛说明，提案并没有把临时表当作无期限的捷径。问题在于，对外明确要求的可见字段主要是“临时”、创建日和到期日。读者可以看到当前状态，却未必能从同一处查明是哪次共识判断、哪位职务主体、哪个草案版本把它推到这里。

表的时钟与行的时钟并不相同

创设草案会写明未来正式登记表的登记政策，但在登记表转正前，这套政策并不直接生效。IANA 要根据未来政策的类型，采用一套过渡期程序。

如果正式政策预计是“先到先得”或“专家审查”，每个过渡期条目须由负责该文件的工作组主席批准。草案明确说，这些已批准条目无需续期。若文件由领域主任直接发起，则由该主任承担批准角色。

如果正式政策要求 RFC，例如 IETF 审查或标准行动，条目必须走配套的提前分配程序。即使整张登记表后来转正，这类条目仍保持临时标记，直到它自己的文件获批。“需要规范”政策还要再分叉：Internet-Draft 是否可以成为永久登记所依据的规范，会决定过渡期的准入路径。

于是，同一张临时表内可能同时出现三种状态：由主席批准且无需续期的条目、有独立期限的提前分配、以及随创设草案初始化的条目。之后，表本身可能已经转正，其中某一行却仍然是临时的。用一个到期字段概括全部状态，会把容器和内容混为一谈。

这也划清了本次提案与现行 RFC 7120 的边界。RFC 7120 处理的是：在一张已经存在的登记表里提前分配代码点。2026 年的草案处理的是：创设文件尚未获批时，整张登记表能否先运行。被提前投入运行的对象不同。

草案变了，入口规则也可能跟着变

建立临时表并不会冻结创设草案。假设未来政策从专家审查改为 IETF 审查，相应的过渡期准入程序也要改变。草案要求将变化通知 IANA，同时明确 IANA 不负责跟踪创设文件的每一次修订。

这是必要的职责边界。IANA 的工作是执行已收到的登记指令，不是替工作组阅读每一版草案并推断政策。作者与主席负责审视内容和结构变化，必要时发出通知。

但职责分开以后，证据必须接上。通知需要绑定具体版本与内容摘要，说明旧规则、新规则、生效时间、批准主体及受影响的条目。否则，公开登记表可能在操作上已经更新，读者却无法判断某个值当初是经主席批准、提前分配还是依照一项只打算在转正后生效的政策进入。

要保存的是迁移过程，而不是最后一张截图

一份两层状态迁移账可以补上这条证据链，同时不扩大 IANA 的政策权力。

登记表层应保存：稳定标识、所属登记组、创设草案名称与精确版本、文件摘要、工作组共识记录、主席决定、领域主任批准、请求日期、创建日、当前到期日、预计正式政策和当前临时程序。结构或政策变化要新增一条带时间的事件，而不是覆盖旧值。续期、IESG 审查期间的暂停、IANA 的暂停请求、关闭和转正，都应保留前后状态与决定依据。

条目层应保存：数值、含义、引用文件、变更控制者、实际采用的批准路径、政策版本和时间状态。如果条目依赖另一份草案，它自己的到期或转正条件要直接挂在该行。整表关闭或转正时，每一行都要说明哪些属性改变、哪些保持不变。

公开这类记录不等于公开私人邮件。职务角色、决定链接、文件摘要、日期和结果，已经足以验证制度迁移；个人资料和内部讨论仍可留在公开面之外。

一行记录不会变成部署许可证

提前登记能避免数值冲突，却不会提前完成其他决定。主席批准不等于 IETF 已经最终认可创设文件，更不等于认可每项相关技术。最后审议征询也不是 IESG 的批准。一条 IANA 记录能证明某个值按某条路径被登记，不能证明产品质量、市场采用或运营者必须部署。

关闭也不能被夸大解释。02 版草案说，若延期未获批准，IANA 会关闭登记表并标注状态；它没有写明表内所有数值必须立刻删除、失效或重新分配。没有逐行依据，就不能自行补出这种结论。

本次查阅也没有发现已有登记表按该提案创建、已有部署依赖它，或有人滥用这套路径。现在讨论状态迁移账，正是为了在首次使用前把边界写清。代码点会离开网页，临时权力的说明也必须具备同样的可携带性。

来源