摘要

  • RFC 10035 给 YANG Library 增加只读 augmented-by 列表，让管理服务器声明同一 module-set 中哪些模块直接向另一个模块添加模式节点。
  • 这项标准补足直接关系的发现，却不会自动计算传递依赖、定位所有受影响路径、证明目录新鲜、判定语义兼容或授权线上模块变更。

A 的下游有 C，但 A 只列 B

RFC 10035 用三个模块说明“直接”一词的含义。A 提供基础容器，B 在该容器中加入新容器，C 又在 B 的容器里加入一个叶节点。查询结果中，A 的 augmented-by 是 B，B 的 augmented-by 是 C。

C 的 XPath 虽然扎根于 A 的树，却没有直接修改 A 拥有的节点。它的直接目标父模块是 B。因此 C 不出现在 A 的列表里。需要 A→B→C 闭包的应用，必须自行遍历。

这一区分阻止自动化把不同依赖混成一个模糊的“有关联”。YANG 还存在 import、include 和 deviation。导入定义、包含子模块、插入节点与改变节点属性，各自给升级、订阅和配置带来不同后果。

新列表公开了一类反向边，但没有接管应用对图的解释权。

RFC 10035 补上 RFC 8525 的一块信息

RFC 10035 于 2026 年 8 月作为 IETF Standards Track 文档发布，其中 ietf-yang-library-augmentedby 模块的修订日期为 2026-08-26。IANA 已登记模块名、XML 命名空间与 yanglib-aug 前缀。

RFC 8525 允许服务器公布数据存储、module-set、实现模块、import-only 模块、特性和 deviation。deviation 已经是一种反向依赖，因为另一个模块改变了基础模块被支持的行为。

此前 augment 没有同等入口。客户端若要知道谁向基础模块增加节点，只能下载相关 YANG 文件并联合解析。对完整配置客户端来说尚可接受；对目录、遥测解析器或分布式数据应用来说，则迫使每个消费者重复建立模式分析能力。

RFC 10035 在 NMDA 的 yang-library/module-set/module 下加入列表，也为兼容 RFC 7895 而在已弃用的 modules-state/module 下提供同一信息。它改善的是发现交接，而不是消除新旧库形状的差异。

module-set 是声明的边界

列表值通过 leafref 指向同一 module-set 内的模块名。基础模块和扩展模块必须位于同一集合；只用于 import 的模块不得冒充实际扩展者；引用也不得直接或间接回到被扩展模块自身。

这些约束保证边的两个端点属于服务器所描述的同一模式。但它们不能证明客户端查询的是正确集合。RFC 8525 可为多个数据存储和模式选择提供不同视图，设备软件激活、替换或新模块上架也会改变内容。

RFC 10035 明确指出，反向依赖会增加 YANG Library 实例体积，新模块上架时应更新库和 augmented-by 信息。于是一次查询必须连同设备身份、认证主体、数据存储、模式选择、content identity、模块修订与抓取时间保存。

没有这些坐标，结构正确的边也可能来自错误范围或过期快照。

可见关系不等于兼容

服务器声明 B 直接扩展 A，只说明它在当前模式树中用 B 添加节点。它没有说明某个客户端理解这些节点，没有说明应用可以忽略它们，也没有说明 B 的下一版保持相同语义。

数据目录可以据此拉取相关模型，遥测解析器可以发现基础模块之外的字段，测试系统可以扩大验证范围。但客户端仍需检查模块修订、feature、deviation、import 和具体 target path，并判断新增节点是否进入相关数据存储、策略或业务流程。

删除场景尤其危险。A 列出 B 是一个影响提示，不是卸载 B 的许可。C 可能直接依赖 B，现有配置可能包含 B 新增的节点，订阅与合规证据也可能使用它们。可执行的影响结论必须来自特定运行模式与工作负载的完整图。

只读元数据仍可能泄露结构

新模块没有可写数据节点，读取列表本身不会改变设备配置。但它可以透露服务器如何组合管理表面：哪些厂商或领域模块扩展标准基础，哪些能力已经上架，进一步的模式节点可能位于哪里。

RFC 10035 因而要求经安全的 YANG 管理协议、双向认证与 NACM 等访问控制获取数据。认证证明哪个端点回答，授权决定某个用户能读到什么；二者都不保证该视图对另一用户、另一数据存储或稍后状态仍完整。

自动化必须记录可见性范围。若高权限采集器和受限采集器得到不同图，边的“消失”可能只是访问控制。只有查询权限与范围已知，缺失边才可作为缺失证据。

实现证明可行，不证明每台设备

IESG writeup 记录四个实现，并提到 IETF hackathon 的测试与验证。这证明机制能够实现和查询，却不能证明每个生产设备运行哪一版本，也不能证明模式变化与列表更新在所有实现中原子完成。

操作测试应从已知模块开始：激活一个直接扩展基础模块的模块，确认两者在同一 module-set、基础条目出现正确边、content identity 如预期变化。再建立两跳案例，确认服务器分别公布 A←B 与 B←C，而不是错误压平为 A←C。

负向测试同样重要：import-only 项不得出现为扩展者；循环应验证失败或被客户端安全处理；低权限用户不得绕过控制得到敏感结构；旧快照不得批准新变更。

三种权限必须分开

服务器负责准确描述它实际暴露的模式组合；客户端负责从这些直接声明构造所需分析；应用所有者或运营者负责批准执行及承担服务风险。

RFC 10035 改善了交接，因为消费者不必为基本反向边重复解析全部模型。它却不知道每个业务工作流如何使用节点，也不知道一次生产变更是否已经获批。IANA 登记的模块更不可能证明某台设备刚刚刷新了库。

需要保存的证据链是：认证端点、数据存储和模式选择，content identity，模块修订与角色，直接边，客户端计算的闭包，受影响路径和消费者，候选变更，验证与回滚，以及最终配置、遥测和服务结果。

Sources