摘要

  • draft-ietf-opsawg-rfc5706bis-07 于 2026 年 9 月 7 日发布，目前仍处于 AD Evaluation，Datatracker 显示需要修订版本；它拟成为最佳现行实践，但尚不是 RFC。
  • 第 07 版新增五种章节处置：实质讨论、解释部分不适用、用固定声明加理由说明没有新增考量、概述并指向本文其他章节，或概述并规范性引用另一份文件。
  • 草案建议固定章节位置，其中一个理由是方便工具检测。标题存在只能证明“找到了标题”，不能证明五种路径中的哪一种成立，更不能证明引用内容完整。
  • Daniel Kade 建议在审查侧保留一张简短的处置回执，写明路径、定位、版本和审查状态；这不是 IETF 已提出的要求，也不是部署风险的批准书。

新增的不是一个标题，而是五种回答

Datatracker 当前记录显示，这份 OPSAWG 工作组草案已经提交 IESG 考虑发布，拟定状态为 Best Current Practice。页面仍把它置于 AD Evaluation，并标注 Revised I-D Needed，没有列出 telechat 日期。9 月 7 日的草案公告也明确说明它是进行中的工作。只有未来获批后，它才会取代 RFC 5706，并更新 RFC 2360。

第 07 版的新闻价值集中在一段新文字。官方 06—07 差异页显示，第 06 版已经提出新的技术规范应包含 Operational Considerations 章节，但尚未列出五种处置。第 07 版现在先说该章节总要出现，再说明其内容取决于具体情形。

第一种情形是协议、扩展或用法确实带来运营和可管理性问题，章节应直接讨论。第二种是清单中的部分问题不适用，作者要简要说明原因，不能让沉默代替判断。

第三种情形是完全没有新增运营或管理要求。第 3.2 节给出固定句式：“本文没有引入新的运营或可管理性要求”，但紧接着仍要求简要理由。固定句不是免责按钮，理由才让审查者知道作者考虑过什么。

第四种情形是相关内容已经散布在同一份草案的其他位置。运营章节不必复制全文，但要概述并准确指路。第五种则把大篇幅分析放在另一份文件中；本章节需要给出简短概述，并以规范性引用连接那份材料。

五种写法可以拥有完全相同的标题，审查任务却不同。实质讨论要检验覆盖是否充分；“部分不适用”要逐项检查理由；“没有新增考量”要挑战其边界；内部指引要确认目的地真的有相关内容；外部配套文件则要核对引用性质、版本与进度是否匹配。

工具最容易把最低证据说成最终结论

第 3.3 节建议把运营考量放在 Security Considerations 之前。这样便于读者寻找，也可能方便开发检测章节是否存在的工具。这是一条合理的最小规则：检查器可以统一标题写法，可以报告缺失，也能较可靠地识别第 3.2 节的固定句。

问题在于，其余四种处置都由自然语言承载。一个“见第 6 节”的链接，可能通向完整分析，也可能只是空泛交叉引用。一条规范性参考文献，可能真正承载部署模型，也可能只有邻近背景。篇幅很长的章节同样可能漏掉决定性的失效场景。

当“标题存在”这个二元结果离开原始检查环境，风险就会放大。看板会把它变成绿色，文档摘要会复用绿色，后来的实现者又可能把绿色理解为“运营问题已审完”。实际上，自动化只证明了一行标题存在。

反向误判同样存在。第 07 版允许数据模型自身承载运营说明，也允许在同一文档别处展开。一个短小但准确的指引章节，可能比冗长重复更好。不能以字数猜测分类，更不能以章节长度代替审查。

为处置结果留一张小回执

合比例的补丁不是把新数据格式强塞进每一份 RFC，而是在现有审查材料旁保留一个轻量字段组。可以暂称它为 operational-disposition。

回执先绑定草案名称和精确版本，再从五个主状态中选一个：substantive、partial-not-applicable、no-new-considerations、in-document-reference 或 companion-document。随后记录章节位置、内部目标或配套文件、作者理由、审查状态和仍未解决的依赖。

“一个主状态”不否认混合情形。正文可能正面讨论多数问题，同时说明两项不适用；回执可以在主状态下列出例外。关键是让人看见作者声称走了哪条路，并把这种自我声明同审查者的判断分开。

版本绑定尤其重要。草案升级后，章节号可能变化，配套文件可能过期，规范性引用可能改为信息性引用，Area Director 也可能要求重写。旧版本的“已审查”不能无声覆盖新字节。回执应随版本失效或重新开启，而不是永久发绿。

这张回执不会取代 OPS Directorate 的审查模板，也不会代替工作组共识、IESG 审批或运营商的上线判断。它只是明确这些判断面对的对象。草案还说，缺少工具本身不足以推迟规范发布；回执完全可以先由人在审查文本中填写，自动化不是前提。

新增的安全段落说明为什么要分清路径

第 07 版还补充了安全运营讨论。它指出，QUIC、TLS 1.3、Encrypted Client Hello 与 DNS over HTTPS 会加密过去可被动观察的元数据，协议设计者应承认隐私目标与安全可见性之间的张力，并考虑端点遥测或日志等替代诊断方式，同时不破坏隐私目标。草案用 RFC 9424说明入侵指标会随攻击和运营经验演化。

这显然属于实质运营分析，却不是端点监控命令，也不是“没有同等工具就不能发布”的否决权。处置回执能把这一点说清：本节走的是实质讨论路径，文本提出权衡和待设计问题，但没有替所有实现与部署作出同一个选择。

强制章节能防止运营问题彻底消失，五种合法路径能防止短章节自动被视为失败。再增加一张可版本化的处置回执，则能防止标题本身被误用为完成证明。

来源