摘要

  • draft-ietf-netmod-iana-yang-guidance-03 描述的是一条拟议出版交接链：带预发布版本的规范性 YANG 模块，经 RFC Editor 受控编辑、版本定稿和重新校验后，再由 RFC 与 IANA 近同步发布。
  • draft 后缀移除、pyang/yanglint 无报错、RFC 与 IANA 字节一致，各自都能形成有价值的收据；任何一张收据都不能单独证明语义未变、版本提升正确、客户端拿到同一字节、设备实际装载或运行兼容。
  • IETF-published module 与从 companion registry 派生的 IANA-maintained module 是两条不同的更新路径；registry 变化会触发后者修订，但 registry、模块与运行系统仍是不同观察层。

把两份完全相同的文件放在桌上，很容易产生一种完成感。哈希相同，revision 相同，YANG Semver 相同；一份从 RFC 中抽取，另一份来自 IANA YANG Module Names registry。出版团队确实可以据此回答一个重要问题：读者从两个权威发布面看到的最终模块是不是同一份字节。

但桌上没有客户端缓存，没有设备进程，没有 feature 与 deviation，没有实际 datastore，也没有一次网络操作。文件一致所关闭的是出版歧义，不是运行现实。

这正是 revision 03 最值得观察的地方。2026 年 9 月 11 日核验时，Datatracker 将它列为 active NETMOD WG Internet-Draft revision 03，状态包括 WG Document 与 I-D Exists，Intended RFC status 为 Informational。正文日期是 2026 年 7 月 6 日，到期日是 2027 年 1 月 7 日。页面的 Last updated 显示 8 月 27 日，是 shepherding AD 与 intended status 的元数据变化；latest revision 仍是 7 月 6 日。它尚未成为 RFC，也不能被写成已经执行过的 IANA 或部署事件。

预发布标记不是瑕疵，而是编辑空间

草案从一个少被解释的时点入手：文档若获 IESG 批准，内含的规范性 YANG 模块通常仍带预发布版本，例如主版本为零，或带 draft-number 后缀。这是在公开说明模块还可能于 RFC Editor 阶段改变，尚未获得正式 revision 的不可变性。

RFC Editor 可以改善不改变含义的描述、把 draft 引用换成最终 RFC 号、修正拼写，并统一格式。边界在于“编辑性”。若改动可能影响语义，就必须与作者协调；若 BC、NBC 或纯编辑分类不清，也应寻求 YANG Doctors 等进一步判断。

出版前要把 revision date 更新到最终修订日期，移除预发布后缀，并决定正式 YANG Semver。对已经发表过的模块，还要与此前版本比较，必要时添加 rev:non-backwards-compatible。如果之后又改了字节，就要重新做版本判断。版本号因此是一项需要保留理由的决定，而不是机器自然吐出的事实。

校验成功有明确、有限的主语

revision 03 建议在所有编辑和格式化完成后重新运行适当工具，出版时通常同时使用 pyang 与 yanglint。它也明确要求带上正确依赖；一组同时出版的模块可能需要一起抽取和校验。

工具的诚实边界写在草案里。描述变化究竟是澄清还是语义改变，工具未必能判断；update comparison 能发现一批已知 NBC 情形，却不能保证覆盖所有边缘；实现本身会有缺陷，可能给出假阳性或假阴性；当前一个版本还是 prerelease 时，自动推荐正式后继版本甚至可能不可用。

所以“无 warning、无 error”只证明特定工具版本、参数、输入字节和依赖上下文通过了规定检查。它不证明编辑没有改变意义，也不证明每个客户端、server 或设备都使用同一解析器和上下文。

IANA 的延迟把两个出版面锁在同一终点

拟议流程要求 IANA 等 RFC Editor 完成后再发布规范性模块。最终模块确定后，RFC 携带该内容，IANA 则在大致同一时间把对应版本发布到 YANG Module Names registry。目的很具体：两处字节精确匹配，引用指向最终 RFC，不让中途版本抢先固化。

这是一项出版控制，而不是部署编排。可审计收据应包含 RFC 抽取字节、IANA 对象、SHA-256、抓取时间、revision date 与版本。即便这些全部相同，也还不知道 unsuffixed URL 的缓存是否更新、客户端取了哪个对象、package 是否解析到同一依赖、server 是否实际装载、YANG Library 是否准确声明、实例数据能否迁移、行为是否兼容。

现有 BTW 文章已经分别处理文件名与 loader selection、schema comparison 的 ED/BC/NBC、module versioning 的分支与 ancestry，以及 packages 的递归组合。本篇只占有“最终出版候选如何被控制并同步到两个发布面”这一交接机制。

IANA-maintained module 是另一条时间线

草案随后讨论的并不是上述副本的同义词。IANA-maintained module 通常从 companion registry 的枚举或 identity 派生。新值先进入权威 registry；IANA 再识别 registry delta，把等价变化写入模块，更新 revision 与 version，检查 BC/NBC，校验，并发布按版本和日期可寻址的文件。

这条链能证明某个已识别 registry 变化被映射进某个模块版本。它不能证明模块在所有时刻都紧跟 registry，也不能证明映射没有遗漏、客户端已经取件、进程已经加载或设备已经采用。RFC 9907 所讨论的 registry 权威与 freshness 仍属于相邻但不同的问题。

一条可辩护的证据链不会省略中间人

至少应分开保留九类记录：获批的 prerelease candidate；RFC Editor 的逐项改动与咨询；最终 revision/Semver 判断；精确校验输入、依赖、工具版本和命令；RFC 中抽取的模块字节；IANA 发布字节与抓取时刻；客户端取件和缓存来源；设备加载及有效 schema 声明；datastore、协议、转发与业务结果。

Heng Lu 的 Running-Code Primacy 在这里是公开的解释框架，而不是对 IETF 动机的归因：协调产物可以定义目标，但不能替运行者完成采用。Minimum Initial Specification 解释了为何这份草案最有价值的部分恰恰很窄——每一项共同规则都应可验证，却不越权替未观察层作证。Reality, Not Advocacy 与 Reality Layers 要求报道停在最后一张真实收据上。

两份完全一致的出版副本当然重要。真正专业的做法，是既承认它解决了什么，也拒绝让它证明从未观察过的事。

信息来源

  1. Revision 03 正文
  2. Datatracker 当前记录
  3. Datatracker 历史
  4. RFC 9907
  5. RFC 9890
  6. RFC 7950
  7. YANG Module Versioning revision 17
  8. YANG Semantic Versioning revision 26
  9. YANG Schema Comparison revision 09
  10. YANG module filename revision 14
  11. IANA YANG Parameters
  12. Heng Lu：Running-Code Primacy
  13. Heng Lu：Minimum Initial Specification
  14. Heng Lu：Reality, Not Advocacy
  15. Heng Lu：Reality Layers