摘要

  • 9 月 29 日发布的 draft-gerke-publication-process-reform-09 是个人 Internet-Draft，仍处于 I-D Exists 状态。它把拟更新的现行文件由 RFC 7841 扩至 RFC 6359，并增加一节，说明作者想让 Datatracker 承担程序性状态完整性约束；这不是已经生效的更新。
  • 第08版早已提出两阶段技术冻结。第09版的新鲜事实不是“发明了冻结”，而是把原本用于反映 IANA 与 RFC Editor 流程状态的 Datatracker 文献也列入拟更新范围。现行 RFC 6359 同时强调，这两个机构的后续状态有自己的权威系统。

同一份草案在第08版和第09版的封面上，出现了值得细读的一行差别。9 月22日版本写的是“若获批准，更新 RFC 7841”；9 月29日版本又把 RFC 6359 加了进去。前者讲 RFC 文档的流别、页眉和状态说明，后者讲 Datatracker 怎样汇集 IANA 与 RFC Editor 的处理信息。把二者并列，意味着提案不再只强调出版文本的标记，还明确触及跟踪系统中的状态转换。

这不是 IETF 已作出的程序决定。Datatracker 把第09版列为个人提交的活动草案，IESG 状态为 I-D Exists；封面写的 Best Current Practice 是作者拟定的目标。标题行的 Updates 也带有“if approved”的条件。没有证据表明该草案获工作组采纳、IESG 批准、编为 RFC，或使任何生产系统开始锁定编辑权限。

修订对照显示，新增的第1.2节是这次变化的核心。作者把 RFC 6359 的跨机构状态跟踪管道解释为自动化验证和写入边界的落点；摘要也加入“既有与未来核心处理流程均适用”的措辞。与此同时，草案第5节关于 IESG 放行后撤销写入权限、第6节要求流程维护方发表联合声明的构想并非第09版新添。将已有构想与新增的适用范围分开，才能准确判断新闻发生在哪里。

RFC 6359 提供了一个必要的对照。它想让读者在一处看见文件从 Internet-Draft 走到 RFC 的处理状态，也希望减少人工转录错误。但它明确说自己不定义 IANA、RFC Editor 和秘书处的具体流程；文件获准出版后，IANA 自己的系统是相应状态的权威来源，而 RFC Editor 状态始终以其系统为准。Datatracker 在这些环节反映外部状态，不是修改外部状态的通用控制台。

这并不说明未来绝不能在 Datatracker 实施更强的校验。真正的问题是，若显示平台变成跨流程的写入闸门，谁批准它作用于哪个流别？技术性改动与编辑性修改由谁判别？涉及勘误、例外和申诉时，哪个机构保有最终状态记录？单凭一份个人草案在封面添加 RFC 编号，不能替这些有权限边界的机构作决定。

第09版还把尚在 procon 工作组 Last Call 的 draft-ietf-procon-2026bis-11 移入规范性参考文献。它提高了提案对另一份未完成程序草案的文本依赖，却不等于两份草案将共同获批。读者应分别跟踪两条进程，而不是把“规范性引用”读成已发布的法律或运行事实。

资料来源