摘要

  • RFC 9907 明确规定，IANA 维护的 YANG 模块只是对应注册表的另一种表达格式；IANA 注册表仍是唯一权威来源。
  • 验证器可以完全正确地批准一份旧文件。完整证据必须连接注册表快照、模块修订与摘要、验证输入、服务器 YANG Library 状态、实际操作和最终观测结果。

自动化流水线没有报错：模块成功解析，依赖全部找到，IETF 检查也给出绿色结果。可触发这次部署的那个值，已经在对应的 IANA 注册表中发生变化。工具并没有失职；失误来自人们要求一个语法验证器替自己证明“这是当前权威状态”。

2026 年 3 月发布的 RFC 9907属于 BCP 216，取代 RFC 8407，并更新 RFC 8126中的注册政策指导。RFC Editor 页面固定了这些关系。它规范的是含 YANG 数据模型文件的撰写与审查方法，并不是远程改变设备的新协议。

它对 IANA 维护模块的定位非常克制。用 YANG 或 MIB 表达 IANA 注册表，只是增加一种表示格式，不会创设第二个注册表。新值先依照对应注册表的规则进入权威记录，再由 IANA 反映到维护模块中。IANA YANG Parameters页面提供带版本的模块文件及维护说明；文件服务于注册表，而不是反过来决定注册表。

RFC 9907 还主动拆除一个方便却危险的副本。Internet-Draft 可以附上生成脚本和完整初始模块，方便审稿人核对设计；正式出版 RFC 之前，作者必须请求 RFC Editor 删除初始模块附录。最终文件应当说明那只是初版，并把权威版本指向 IANA。否则，一份冻结在永久文档中的副本很容易因“看起来正式”而长期冒充最新状态。

即使从 IANA 获取，也要问取的是哪一种证据。“最新”链接适合获得此刻的投影，带修订号的链接适合复现特定历史文件。只保存一个可变网址或文件名，都不足以说明某次流水线实际读取了哪些字节。可复查记录至少要保存获取时间、注册表快照、模块修订、来源网址和内容摘要。

验证当然不可省略。RFC 9907 要求验证模块，并以 pyang --ietf 等工具为例；YANG 1.1提供语言规则。但验证报告的准确表述应是：某版本工具以某组选项和依赖检查了这组字节。它不证明输入就是最新修订，也不证明目标服务器实现了同一套模式。

服务器还有自己的证人。RFC 8525定义 YANG Library，使服务器能够公布模块集合、功能、偏差和数据存储模式；其中 content-id 在库信息变化时必须改变。于是，本地模块通过验证与服务器公布不同模块集，可以同时为真。二者必须比较，不能靠一个绿色结果互相代替。

部署又跨过一道边界。RFC 8342区分 intended、operational 等数据存储视图；NETCONF与 RESTCONF定义对模型化数据的操作和错误。请求被接受，不等于意图状态已经成为运行状态；运行状态出现，也不等于服务目标达成。

因此，一份可辩护的变更记录要把这些收据连接起来，却不把它们混为一谈：带时间的权威注册表快照、IANA 模块修订与摘要、必要时的生成来源、验证器版本/选项/依赖、服务器模块集与 content-id、具体操作与协议回执、前后数据存储观测、回退状态，以及服务层测试。这是基于多份标准形成的编辑性证据设计，不是某一 RFC 规定的统一表格。

Heng Lu 的最小初始规范允许共同层保持狭窄，把工具与部署选择留给可问责的本地责任人；运行代码优先要求运行证据只对它直接显示的层面负责；现实层次阻止注册表、文件、验证器、数据存储与服务结果被压成一个绿色徽章。这些是公开说明的编辑框架，并非新增的 IETF 要求。

缩小每项证据的权力，不会削弱自动化。恰恰相反，它让自动化可审计：注册表决定权威值，模块负责承载，验证器负责检查，服务器负责声明自身模式，操作负责改变状态；每一层都不冒充下一层。

Sources