摘要

  • IESG 于 2026 年 9 月 3 日完成对 Safe-IOC 第 12 版的 RFC 5742 冲突审查，结论是与 IETF 工作不存在冲突；这不是技术背书、IETF 共识或标准轨批准。
  • 第 13 版与第 14 版随后发布。公开差异能看出多项 ballot 建议进入新文本，Datatracker 也记录了 ISE、IANA 与 RFC 制作动作，但这些记录没有逐条说明每项评论由谁采纳、拒绝或部分采纳，以及对应哪一处修改。
  • 一张版本—评论处置回执应绑定被审查版本的哈希、RFC 5742 响应、评论稳定 ID、ISE 处置理由、实现差异、IANA/RPC 状态与最终 RFC boilerplate，避免把“进入队列”误写成“已经获批并发布”。

审查结论停在第 12 版

IESG 公告明确写出被审查对象：draft-grimminck-safe-ioc-sharing-12。IESG 表示对其作为 Informational RFC 发布没有问题，并认定它与 IETF 工作不存在冲突。紧接着，公告把另一个判断交给 Independent Submissions Editor：查看 Datatracker ballot 与 history 中的评论，自行决定是否值得纳入。

这不是一句话的重复，而是权责分割。对第 12 版的冲突检查已经结束；技术评论仍需 ISE 判断；Independent Submission 可以继续；RFC 尚未发布。任何一个状态都不能代替其余状态。

当前 Datatracker 页面已经显示第 14 版，同时仍把文件标为 active individual Internet-Draft、Independent Submission、预期状态 Informational。草案名称延续了，字节与制作状态却已改变。

RFC 5742 刻意限制 IESG 的判断范围

RFC 5742列出五种冲突审查响应。此次采用的是第一种、也是最窄的一种：文件与 IETF 工作不存在冲突。该 RFC 同时说明，非 IETF stream 的文件通常不寻求 IETF 共识或 IESG 批准；在无冲突后，技术价值与可能的互联网危害仍由 RFC Editor 体系判断。

这种安排同时防止两种越权。IESG 不应把冲突检查悄悄扩大成全面技术审查；ISE 也不能把无冲突当作技术审查的替代品。“对发布没有问题”只说明这个理由没有阻断 Independent stream，不说明 IETF 认可每项规范内容。

ballot 页面问的也是“拟议的冲突审查响应是否正确”。截至本文截止点，页面显示两张 Yes 与八张 No Objection。这十个位置回答的是制度问题，不是对每条转换规则、测试向量与安全论断分别投下赞成票。

评论确实改变了文本，但没有完整处置表

Mohamed Boucadair 在同意冲突响应后提出四项小型技术建议：引用 RFC 9424 解释 IOC；不要用 “safe” 暗示风险已归零；区分地址与前缀；补入 RFC 6052 的 IPv4 嵌入 IPv6 情形。Éric Vyncke 另留下一条关于 IPv6 内容很多的轻量评论。

第 13 版在公告后出现。版本历史与第 12 至 14 版差异显示出清晰对应：摘要把 “a safe obfuscation format” 改成 “an obfuscation format”；加入 RFC 9424；CIDR 描述改称前缀；加入 RFC 6052 和两个测试样例；致谢中也出现 Boucadair。

这些材料足以说“后续文本反映了建议”，却不足以证明每项建议已有正式处置。差异无法告诉读者：ISE 是否按原意采纳、是否因另一份审阅而改动、是否合并处理，或者是否用其他改动解决了更广的问题。

第 14 版又加入新内容：引入常用术语 “defanging”，收紧 host grammar 与 RFC 1035 引用，把两处大写规范词改成普通建议，并在安全考虑中增加 Path、Query、Fragment 内括号 token 歧义可能改变恢复结果的风险。公开页面没有把这些变化逐条连回稳定的审阅 ID 与具名的采纳、拒绝或部分采纳决定。

制作状态仍不是发布状态

9 月 9 日，第 14 版上传，ISE 随后把它送交 RFC Editor。IANA 状态先进入处理中，9 月 16 日变为 “No IANA Actions”。RFC 制作一度因需要作者输入而 blocked，次日恢复；RPC 历史后来显示从等待 reference checking 与 formatting 转向等待 editor assignment。

RFC Editor 官方队列 XML在截止时仍把第 14 版列于 ISE stream，收件日为 9 月 9 日，assignment 为 ref_checker。Datatracker 与队列是不同的制作投影，不能被压缩成一个模糊的 “approved”。目前也没有最终 RFC 号。

Independent Submission 流程说明明确列出反复审阅与修订、初始发布决定、交给 RPC、AUTH48，最后才是 publication。ISE 在 RFC 真正发布前仍可不予发布。因此，队列条目证明的是保管与制作，不是最终公共文本已经成立。

版本—评论处置回执

回执第一行应以精确哈希与时间戳绑定第 12 版和 RFC 5742 响应。每条 ballot/history 评论应携带稳定 ID、提出者、文本哈希与来源页面。ISE 应明确记录 accepted、rejected 或 partially accepted 以及理由；如被采纳，还应指向首次实现它的版本与精确 diff hunk。

同一回执可以继续记录 IANA 是否需要动作、RPC 阻塞与解除的原因、责任人、最终 RFC 号、stream/category boilerplate，以及今后的 errata 或替代文件。建议若只是 advisory，应明确写出；来自别处的修改，也不应倒算成 ballot 的成果。

这种纪律还能阻止过度安全宣传。可逆文本约定能够降低意外激活风险，却不能验证某个指标是否真的恶意、是否仍然有效、归因是否正确，也不能证明处理系统无害。文件版本的 provenance 与威胁指标的 provenance 是两套不同记录。

来源