摘要

  • RFC 6020 原本要求 YANG 注册表里的所有模块名、子模块名和 XML 命名空间都必须唯一；IANA 的实际做法却让同一模块的不同修订版继续使用同一名称与命名空间。
  • Qin Wu 参与撰写的 RFC 9890 修正了规则：唯一性约束的是初始版本；修订版必须沿用初始名称，模块修订版还必须沿用初始 XML 命名空间。
  • 名称不变不等于内容不变。修订日期、文件字节、导入选择、实现测试和生产观察仍是彼此独立的证据，分别由不同主体控制。

截至2026年9月1日，IANA 的 YANG Module Names 注册表里可以找到三条 ietf-yang-types。它们分别指向 2010-09-24、2013-07-15 和 2025-12-22 的文件，却共享 ietf-yang-types 这个名称和同一个 XML 命名空间。

如果只看 RFC 6020 第14节的旧文字，这三行像是违反规则。旧文说，注册表里的所有模块名和子模块名都“必须唯一”，所有 XML 命名空间也都必须唯一。可是这三行并不是三个主体争夺同一标识符，而是同一模块的三次编辑修订。

2025年10月发布的 RFC 9890 用六页文字解决了这个错位。Andy Bierman、Mohamed Boucadair 与 Qin Wu 没有发明一种新的注册业务，也没有要求运营者增加新的管理动作。他们把“唯一”的对象说清楚：首次身份分配必须唯一；后来修订必须保持身份连续。

这是一处很小的规范补丁，也是一堂关于注册表权力边界的完整课程。

最容易误杀连续性的，是没有事件类型的去重

“唯一”从来不是一个脱离上下文的属性。首次创建名称，是分配身份；在既有身份下提交修订，是记录变化。把两类事件送进同一个去重按钮，系统会把正常连续性当作冲突。

RFC 9890 的新规则有四层。第一，初始模块与子模块名称必须唯一。第二，初始模块的 XML 命名空间必须唯一。第三，所有模块和子模块修订版必须使用初始版本的名称。第四，模块修订版必须使用初始版本的 XML 命名空间。

前两层阻止无关对象占用同一公共身份；后两层阻止同一对象每次更新都被迫改名。注册表只有同时做到这两点，才能既防碰撞，又不切断引用关系。

因此，监控台上一个红色的“duplicate”远远不够。两个相同字符串可能意味着初始分配冲突，也可能意味着一条获准的修订链。审计记录至少要保留事件类型、修订日期、来源 RFC、文件地址和命名空间。没有这些字段，自动清理越积极，越可能把正确记录删掉。

同一身份之下，内容仍然会变

规则纠正后，另一种误读随即出现：既然修订版必须同名、同命名空间，那它们是否可以互换？RFC 7950 对 YANG 1.1 的版本机制给出了明确否定。

模块里的 revision 语句记录编辑修订历史，参数是一项日期。每次已发布的编辑变化都应增加一条新修订记录，并以倒序排列。推荐的文件名把稳定名称和可选的 @revision-date 放在一起。

这个设计同时表达两句话：“它仍属于同一个模块谱系”，以及“它未必仍是同一份定义”。名称回答归属，日期回答编辑状态。任何一项都不能代替另一项。

导入行为把差异变成实际选择。导入语句写了 revision-date，就应使用指定修订版；指定日期不存在时属于错误。没有写日期，RFC 7950 说采用哪个修订版是未定义的。同一模块的多个修订版甚至可以在使用不同前缀时同时导入。

所以，同一命名空间不是升级许可。它不能证明工具装入了哪份文件，不能证明厂商实现了哪些行为，也不能证明运营者已经安全上线。它只保持公共身份不漂移，让其余证据仍有地方可以连接。

日期是选择器，不是装饰

IANA 的 ietf-yang-types 三行记录把这一点变得具体。2010年的记录引用 RFC 6021，2013年的记录引用 RFC 6991，2025年的记录引用 RFC 9911。名称与命名空间保持不变，日期文件与规范依据却发生了变化。

如果资产清单只保存 ietf-yang-types，三种编辑状态会塌缩成一个模糊对象。如果清单擅自改成 ietf-yang-types-v1、v2、v3，又会创造注册表从未分配的身份。正确方式是同时保存稳定身份与日期修订。

生产收据还要更长一些：模块名、命名空间、修订日期、文件哈希、来源 RFC、软件包或固件版本、解析器版本、验证结果、上线批次和运行观察。日期说明想选哪一版，哈希说明拿到哪些字节，清单说明哪些字节随产品交付，测试说明实现是否接受，观察说明真实系统最终做了什么。

这些字段不是重复劳动。相同日期出现不同哈希时，问题在供应或打包链；同一修订版被两个解析器作出不同解释时，问题在实现链；测试通过但没有进入生产时，实验室收据不能冒充上线事实。

注册表的职责越窄，证据链反而越清楚

RFC 9890 让自己成为 YANG Module Names 注册程序的权威参考，同时明确表示：这项调整没有引入新的运行或可管理性要求，也没有带来需要讨论的新增安全风险。

这段克制非常重要。注册表可以阻止初始身份碰撞，可以说明一条有日期的记录属于哪个名称谱系。它不能认证 YANG 模型质量，不能认证解析器正确，不能判断两个修订版兼容，更不能替运营者批准上线。

Lu Heng 的“最小初始规范”在这里提供了一个准确的尺度：只把各方必须共同认知的事实放进公共层。模块名称和命名空间若发生初始冲突，整个生态会失去共同引用，所以需要集中协调。升级窗口、导入图、厂商支持范围与本地风险承受能力则不需要由 IANA 决定。

未来决策应当保留在本地。修订版可以发布和注册，但不同工具、产品和网络可以按各自测试节奏采用。公共身份跨越这些决策保持稳定，采用责任则留在实际做决定的主体手中。

Qin Wu 的作者身份提供来源，不转移运行责任

RFC 9890 将 Huawei 的 Qin Wu 与 Andy Bierman、Mohamed Boucadair 一同列为作者。IETF Datatracker 官方档案在同一公开身份下记录了大量 RFC 工作。这些材料足以说明 Qin Wu 长期参与网络管理与 YANG 相关标准工作。

它们不足以把共同作者写成规则的所有者。RFC 是 IETF 流程与共识的产物；IANA 维护注册表；各规范作者编写修订；工具和产品团队实现；网络运营者决定什么进入生产并承担结果。

这不是礼貌性的降调，而是责任归属的必要条件。注册错误由注册流程解释，解析缺陷由实现链解释，未经充分测试的上线由批准上线的主体解释。作者姓名证明来源，不是一张可以转让的运行授权书。

Qin Wu 参与的这份文件，其价值恰恰在于边界够窄：它让成文规则不再否认注册表赖以运转的身份连续性，同时没有把实施和部署权收进标准文本。

当规范向实践纠偏，实践仍需接受目的检验

“运行代码优先”不等于“软件已经这样做，所以一定正确”。坏做法也可能流行，方便的实现也可能损害互操作和安全。实践是否值得写回规范，要看它是否服务于那条共同规则最初要保护的目标。

RFC 9890 的调整通过了这个检验。修订版沿用初始名称与命名空间，并没有削弱首次分配的唯一性；相反，它让注册表无需为每次编辑变化伪造一个新身份。唯一性边界和引用连续性同时得到保留。

这份 RFC 还展示了透明纠偏的方法：列出旧文字，说明实务不一致，给出替代文字，再指向受其约束的注册表。它没有用“编辑性澄清”掩盖矛盾。未来审计者可以逐句看到规范改了什么。

承认旧抽象选错对象，比假装旧文一直没有问题更能建立可信度。一个协调系统如果不能根据有边界、可验证的实践修正规则，最后就会要求现实去服从数据库外观。

建一张能活过下一次修订的收据

先记录初始分配：模块或子模块名称、模块命名空间、分配依据和注册时间，并明确标记为“初始版本”。唯一性检查应作用在这一层，而不是不分青红皂白地扫描所有修订记录。

每次修订继续保存不变的身份字段，同时加入修订日期、准确文件 URL、哈希、来源 RFC 和前序修订。还要记录工具是明确选择日期，还是接受了未定义或默认选择。省略 revision-date 与主动选定版本不是同一份证据。

再把链条延伸进软件：解析器及版本、验证输出、包含模块的软件包或固件、导入关系、deviation 与启用 feature。最后连接预生产测试、上线审批、灰度范围、运行错误和回滚结果。

仪表盘要为不同层使用不同动词。IANA“登记”，RFC“规定”，软件包“包含”，解析器“接受”，厂商“支持”，运营者“部署”，服务“持续”或“失败”。一项绿色状态不能替下一项发言。

这样做不是增加行政负担，而是在同一张证据图上同时保住两样东西：稳定的公共身份，以及身份之下每一次变化的真实可见性。

来源