摘要

  • IESG 于 8 月 28 日宣布 Security Dispatch 工作组结束，原邮件列表将关闭，其职能并入面向 ART、SEC 和 WIT 非传输议题的新 DISPATCH。
  • 场所合并不等于历史状态自动迁移。每项旧提案都应有一行可追溯记录，连接版本、旧讨论、处分原文、共识状态、权限类型、去向、返回条件和后续更新。

关掉的是独立入口，不是安全议题

结项公告列出 Christopher Inacio 和 Deb Cooley 为 IESG 联系人，也明确表示安全领域仍欢迎新想法进入 dispatch。变化在于入口：过去单独运行的 SECDISPATCH 不再继续，提案改由一个更宽的 DISPATCH 接收。

这个承接安排不是临时口头决定。IESG 在 7 月 2 日批准了新章程，范围包括 ART、SEC，以及 WIT 中不属于传输协议的部分。6 月 30 日已经举行过一次 DISPATCH 与 SECDISPATCH 联合临时会议；7 月的 IETF 126 也只安排了一场 DISPATCH 会议。正式结项之前，合并后的场所已经在工作。

统一入口有现实好处。一项身份、邮件或 Web 应用提案可能同时触及多个领域，让提案人先猜对 IETF 内部边界并不能改善技术质量。共同入口可以更早发现重复和依赖。

但 DISPATCH 只负责分流，不是批准机关。新章程允许它建议交给现有工作组、召开 BoF、准备新工作组章程、考虑 Area Director 赞助、建立讨论列表、暂缓或拒绝。章程同时明说，这些意见不具约束力；主席无法判断共识时，也不保证一定给出反馈。除非相关 Area Director 同意处理范围很窄的行政文档，它不负责完成技术文档。

六个议题留下了六种不同状态

6 月 30 日的联合会议大约有 50 人参加。会后，主席逐项记录六个结果，并请两个列表对这份粗略共识判断提出异议。

其中一项由提案人考虑 Independent Submission Editor 路线，记录特意说明这只是可能路径，不是 Dispatch 的动作。两项没有进行陈述。一项得到“不由 IETF 采取行动”的结论。另一项是“目前不采取行动”，同时列出需要更多独立实现兴趣和讨论场所。还有一项被引向 DAWN BoF 及其组织工作。

这些词不能被压成同一个“已处理”。“未陈述”不是技术否决；“目前不行动”不是永久拒绝；指向 BoF 也不等于工作组已经成立。合并如果只留下题目而丢掉状态，就会让后来者把建议误读成授权，或把暂缓误读成结案。

RFC 7957 对这种分工说得很清楚：DISPATCH 型工作组评估新工作、寻找去处，但不完成该工作；它可以记录为何某项工作没有推进。边界案件由相关 Area Director 和主席决定去向。RFC 2418 则规定，当任务或基础假设发生变化时，Area Director 在咨询工作组后可以重订章程、更换主席或解散工作组，异议可向 IESG 申诉。

需要迁移的是处分，而不是提案所有权

截至本文核查时，SECDISPATCH 公共档案仍可读取，页面显示 1,699 封邮件。这个观察不能保证永久可用，也不能证明有任何提案丢失。真正的问题是：读者能否从旧记录直接走到当前状态，而不必靠关键词、会议议程和个人记忆拼图。

一份公开迁移账应当为每个实质处理过的提案保留稳定标识、草案版本、最后相关讨论、会议记录、处分原文、共识是否确认、权限类型、目标场所、下一行动人、再次提交条件、合并截止状态、存续档案和新 DISPATCH 的后续记录。更正或替代应新增版本，不能抹掉原值。

这不会给旧提案创造排期权，也不会把分流建议提升为标准决定。它只确保“主席摘要”“工作组粗略共识”“Area Director 决定”“提案人自行选择”继续是四件不同的事。

结项公告中的 RFC 编号需要更正

公告说安全领域仍可“依照 RFC7975”提交新想法。RFC 7975 实际描述的是内容分发网络互联中的请求路由重定向接口。新 DISPATCH 章程引用的则是 RFC 7957，即解释 DISPATCH 型工作组的最佳当前实践。

这一位数字的错误没有让合并失效，现有材料也没有显示它改变了任何处分。不过结项公告很可能长期充当旧入口指向新流程的路标，因此应当更正或加注。

现有证据没有证明某个提案被搁浅、档案会消失、旧意见具有约束力或提案有权重新获得听证。核查时 IETF 126 材料页没有显示会议纪要，也不能据此断言没有其他结果记录。迁移账是 Daniel Kade 的治理建议，不是 IETF 已宣布的承诺。

来源