摘要

  • draft-ietf-netmod-yang-next-agreement-00 把 YANG Next 议题分成应纳入下一版本、可在兴趣足够时考虑、暂不进入下一版本，以及已关闭或建议关闭四类。
  • 这是一份绑定第 00 版的分类收据。议题所在栏目、GitHub 的关闭状态或 WG Document 标签，都不能单独证明逐项共识、最终纳入、规范性语义、向后兼容、实现可行、工具就绪或生产采用。

一张范围表最容易在它最有用的时候被误读。

对编辑者来说，四个栏目让约 160 个大小不一的 YANG 改进议题终于有了可讨论的边界。对工程经理来说，同一张表却很像路线图：“应纳入”仿佛等于下一个版本必做，“已关闭”仿佛等于技术争议已经解决。再往下，采购人员可能把工作组文档状态当成标准承诺，运营团队则可能在编译器、模型库和迁移证据出现之前就安排切换。

第 00 版 YANG Next Agreement 的真正价值，恰恰要求阻止这种越级。它把 netmod-wg/yang-next 的 GitHub 议题清单投影成一份 NETMOD 工作组 Internet-Draft，先回答“哪些问题值得进入下一阶段”，而不是直接回答“下一代 YANG 的语法和语义是什么”。它先治理范围，后面才可能形成语言。

同一页面上的两个状态表述

截至 2026 年 9 月 11 日，Datatracker 把该文档列为 active NETMOD WG Internet-Draft，修订号为 00，最近更新时间为 2026 年 6 月 23 日；WG state 是 WG Document，IESG state 是 I-D Exists。结构化的 Intended RFC status 一栏为空。

正文页眉同时写着另一组事实：Intended status: Informational，日期为 2026 年 6 月 23 日，并将在 2026 年 12 月 25 日到期。两者必须分别保留。前者是 Datatracker 当前字段，后者是草案正文声明；不能为了让故事更整齐而把它们合并成“IETF 已批准 Informational 文档”。

WG Document 说明工作组把它作为正式讨论载体。I-D Exists 说明一份互联网草案存在于流程中。它们都没有逐项批准表内议题。草案自己也写得很克制：目的在于讨论并争取就 YANG 下一版本的范围和形态达成意见；该文档没有作为 RFC 发布的目标，未来甚至可能用 GitHub 看板继续追踪。

所以，文档状态证明的是讨论发生在哪里，不是讨论已经得出什么最终结论。

四类的控制力来自“暂时不做”

草案统计当时大约有 125 个开放议题和 35 个关闭议题。它们的复杂度、重要性、兼容性影响相差很大。如果仅凭谁愿意写代码或提交文本来选择工作，新的语言版本可能在目标尚未确定时就变得庞大而不一致。

四类结构对此给出了一种范围冻结办法。

第一类是作者认为下一版本应当包含的改动；第二类是在兴趣足够时可考虑的事项；第三类暂不进入下一版本，但以后仍可重审；第四类则是不再推进、已经关闭或建议关闭的事项。最重要的并不是第一类的“承诺感”，而是第三、第四类赋予工作组暂缓和拒绝复杂度的能力。

这很接近“最小初始规范”的纪律：先锁定足够小、可检查的共同问题面，把其余选择留给后续，而不是一次把积压清单全部升格为核心设计。范围越明确，试验越容易归因；失败时也更容易知道该撤回哪一个决定。

不过，最强的一类仍只是作者意见。第二节原文说这些是“作者认为”应加入的议题，并承认某些澄清经过审查后可能不需要修改规范。附录中的 Issue 152 还给出了不同的打分和分类方案。分类表因此是争取共识的输入，不是共识本身。

“关闭”至少有六种含义

把关闭状态读成技术否决，是这份文档最危险的简化。

草案的关闭部分同时容纳：GitHub 已关闭的议题、作者建议关闭但尚未关闭的议题、重复项、对现有语言的误解、被认为会损害语言的改动，以及应当移交协议层而非语言层处理的问题。低优先级、存在更好绕行方案、实现过于复杂，也可能成为关闭理由。

这些理由彼此并不等价。重复项可能只是把讨论合并到另一个编号；协议议题只是换了责任边界；作者的关闭建议还没有成为工作组结论；因 YANG 1.1 兼容压力而关闭的想法，在 YANG 2.0 语境下可能重新打开。草案明确承认，一些已关闭议题因为环境变化而重新出现在其他列表中。

因此，可靠收据至少要保留四个连接：精确的 GitHub 议题与时间点、它在精确草案修订版中的位置、分类或关闭理由，以及后续邮件列表和会议是否形成了有范围的工作组判断。只剩一个 closed 字段时，证据已经被压扁。

从清单到共识，还隔着反对意见

NETMOD 的会议记录说明这份文档为什么有必要。IETF 120 时，参与者对 YANG Next 有兴趣，却尚未明确要解决什么问题，甚至还没有决定目标应被称作 YANG 1.1、1.2 还是 2.0。主席要求先整理动机和目标，并特别说明 Git 的工作方式不会替代工作组共识流程。

到 IETF 121，议题打分由一个公开征集、成员自选的团队完成。会议上的意见是：这类工作必须回到工作组；应该先拿出高层方向和分类清单，再判断这个方向是否值得实现和采用。把结果写成草案并争取成为 WG 文档，是为了获得 buy-in 的办法，而不是说明 buy-in 已经完成。

RFC 7282 对粗略共识的解释进一步限制了“标签即共识”的说法。共识不是赞成票数量，而是识别有根据的反对意见、理解其技术理由，并证明问题已得到处理。任何单个议题如果要走到最终规范，都还需要邮件列表、会议讨论、反对意见、回应和主席判断组成的共识收据。

七层证据，不能由一个标签代办

对每项 YANG Next 提案，可以把证据拆成七层。

第一层是清单收据：谁提出了什么问题、例子是什么、当前状态为何。第二层是分类收据：第 00 版把它放在哪里，编辑理由是什么，有没有替代分类。第三层是共识收据：工作组实际讨论了哪些异议，主席对什么范围作出判断。第四层才是规范收据：后续草案中确切的规范性文本、依赖和变更历史。

第五层是兼容收据：旧、新语法与语义如何处理现有模块、扩展、deviation、客户端和服务端。第六层是实现收据：至少两个独立工具对正例、反例、错误路径和互操作得出可重复结果。第七层是部署收据：运营者能够分阶段采用、观测影响并回滚。

YANG Next Agreement 第 00 版最强的是第二层。它能让讨论变得可审计，但不能替代后五层。

不与既有 YANG 机制争夺结论

YANG 2.0 草案处理语言本身的基线；module versioning 处理修订身份和分支；schema comparison 在给定输入下判断差异类别；module filename 处理仓库命名和别名；YANG Packages 处理模块组合与符合性集合。它们各自的证据边界已经不同。

本篇不把四类议题表写成上述机制的总和。进入“应纳入”并不定义任何关键字；被归入“考虑”也不证明兼容；关闭一个议题更不证明现有工具链已经解决问题。分类只决定下一次讨论应从哪里开始。

对厂商，这意味着“应纳入”应触发可行性与兼容测试，而不是发布承诺。对工具维护者，它应触发实验分支和语料测试，而不是默认开启。对运营者，它应触发观察规范和实现证据，而不是迁移窗口。对工作组，它应当成为逐项寻找反对意见和最小共识的议程。

符号层可以用四个栏目协调注意力；现实层必须让文本能够编译、独立工具能够复现、运营者能够观察与撤销。把两层分开，才是对这份范围文档真正的尊重。

来源

当前文档与历史：YANG Next Agreement 第 00 版；Datatracker 当前记录；Datatracker 历史。

流程与技术背景：IETF 120 NETMOD 会议记录；IETF 121 NETMOD 会议记录；RFC 7282：粗略共识；RFC 7950：YANG 1.1；YANG 2.0 草案第 00 版。

解释框架：最小初始规范；论现实层；Running Code Primary。