摘要

  • RFC 10035 在 YANG Library 中加入只读 augmented-by 清单，让服务器说明同一模块集里哪些模块直接增强另一个模块；仅解析基础模块本身，无法发现这类外部反向依赖。
  • 清单故意不返回传递闭包。若 B 在 A 下增加节点，C 又在 B 所定义的节点下增加叶子，那么 A 只列 B，B 列 C；不能因为 C 的路径以 A 为根，就把 C 伪装成 A 的直接增强者。
  • 正确理解这条边，必须同时保存服务器身份、模块集、修订版、YANG Library content-id、访问结果、客户端遍历和最终运行结果；它不是完整模式图、实现一致性证明或自动化安全证书。

打开一个普通依赖文件，通常可以顺着 import 往外走。RFC 7950 定义的 YANG import 和 include 也遵循这种方向：需要别处定义的模块，会在自己的源码里说出依赖对象。读者只要解析当前文件，就能看见这条线索。

augment 改变了观察位置。另一个模块可以指定基础模式树中的目标，在那里插入新节点。知道目标的是增强模块，不是被增强的模块。基础模块的有效形状可能因此改变，但它的源码没有必要留下“谁后来接入”的名单。

RFC 10035 处理的正是这处缺口。这份题为《YANG Library: Addition of the augmented-by List》的标准轨 RFC 于2026年8月发布，更新 RFC 8525，作者为 Zhuoyao Lin、Benoît Claise 和 Ignacio Dominguez Martinez-Casanueva。它在 YANG Library 的模块条目下加入只读 augmented-by 叶列表，让服务器报告当前模块集中直接增强该模块的模块名称。

Claise 的人物意义也应保持同样准确。2026年8月31日保存的 IETF Datatracker 档案列出他参与的45份 RFC，其中包括 RFC 10035，并记载他当时在网络管理和运营工作组、性能指标评审、IAB 下一代网络管理研讨会及 YangCatalog 支持中的公开职责。IETF 104 的历史简介还记载他于2012年至2018年担任运营与管理领域联席主任，并长期从事 YANG、遥测和网络自动化工作。这些资料解释他为何出现在这项工作里，却不把集体标准变成个人财产，也不证明他控制任何部署。

基础模块看得到调用，看不到来访者

import 是正向依赖：当前模块要使用另一个模块的定义，声明就写在当前模块里。include 也由模块点名要纳入的子模块。解析器从文件出发，能找到它主动依靠的对象。

外部 augment 是反向依赖。某个模块在别处声明增强语句，目标却落在基础模块的模式树中。RFC 10035 将 augment 与 deviation 放在同一类观察问题下：改变可能从目标模块之外发生。只读目标文件，不足以还原有效模式。

RFC 8525 的 YANG Library 原本已经可以说明偏差模块，却缺少与增强相对应的服务器报告。客户端可以搜索大范围模块目录，但“可能存在的模块”不同于“这台服务器在这个 module-set 中报告的模块”。RFC 10035 把答案放回部署语境：基础模块和被列出的增强模块都必须出现在同一个模块集中。

因此，augmented-by 提供的不是互联网范围内永久不变的模块关系，而是一个带服务器语境的直接相邻事实。它回答“当前模块集中，谁直接增强了这个模块”，不回答“从这里递归可达的所有节点是什么”，更不回答“服务器实现是否正确”。

直接关系取决于新节点的父节点是谁定义的

RFC 10035 的第二组三模块示例划出了最关键的边界。模块 A 定义 foo-a；模块 B 在 foo-a 下加入 foo-b；模块 C 再在 foo-b 下加入一个叶子。

C 所用的完整路径确实从 A 的节点开始。若只看路径前缀，很容易说 C 也增强了 A。但 C 新节点的父节点 foo-b 是 B 定义的。标准因此要求：A 的 augmented-by 列 B，B 的清单列 C，A 不列 C。

这不是漏报，而是保护“直接”二字的含义。若把每个后代模块都复制到所有祖先清单，服务器给出的相邻边会与客户端计算出的传递关系混在一起。在大型模式中，同一模块还会被反复列出，读者无法知道真正的挂接点在哪里。

需要完整闭包的应用可以自行遍历 A→B→C，并保存路径、递归上限、循环和错误处理。需要判断某个具体节点的应用，可以取得模块源码并解析模式树。服务器给出原子化的直接边；应用对自己的问题负责。这正符合最小初始规范：共享层只承诺最小、可互操作的事实，不替各类客户端预先决定所有图算法。

边必须绑定 content-id

模块集会改变。RFC 8525 用 content-id 标识一台服务器当前的 YANG Library 信息；信息改变时，标识也必须改变。客户端可据此缓存一次结果，并在标识变化后重新取得库实例。RFC 10035 进一步说明，新模块上线时应更新 YANG Library 和 augmented-by 实例。

这使“新鲜度”成为证据的一部分。一张 A→B 的截图若没有服务器、管理端点、抓取时间和 content-id，无法说明它属于哪个库状态。缺少某条边更不能直接解释为“没有增强”：也可能是库陈旧、服务器尚未支持 RFC 10035、访问被过滤或实现上报错误。

可复核的记录应保存认证主体及访问控制结果、数据存储与模式身份、module-set 名称、模块名、修订版、命名空间、原样上报的直接边以及 content-id。客户端若计算闭包，还要单独记录算法版本、递归限制、输出与异常。这样，服务器声明和客户端推导就不会被压成同一个“完成”标记。

只读关系也会泄露实现轮廓

augmented-by 不修改配置，却可能暴露可选模块、功能或实现组件。RFC 10035 明确提醒，这种结构信息可能帮助针对性攻击，建议通过管理访问控制边界把读取限制给获授权用户。

所以，不同主体看到不同库信息并非纯理论问题。某条边没有返回，既可能是图为空，也可能是权限结果。证据必须保存“谁在什么访问条件下读到了什么”，而不能把未返回与不存在视为同义词。

清单还会扩大 YANG Library 实例。运营者要在模块变动时维护数据，客户端要决定缓存何时失效。合理做法不是把服务器变成万能模式分析器，而是让它可靠提供紧凑的直接关系；只有当业务决定需要更深含义时，客户端才进一步抓取源码和运行状态。

模式邻接不能替代运行结果

若一个自动化客户端声称“已经理解有效模式”，仅看到 A→B 还不够。它还需证明取得了 B 的正确修订版，解析成功，必要时沿 B→C 继续遍历，正确处理偏差、功能条件、数据存储和访问范围，并把计算结果交给了明确的决策步骤。

即使图计算完全正确，也没有证明运行服务器与模型一致。RFC 8342 展示了网络管理系统面对的预期与运行状态边界。模式可以组织预期，真正的配置、状态、遥测和自动化结果才说明系统发生了什么。

因此，证据链应继续延伸到源码取得与解析结果、使用图的应用决定、可访问的数据存储、预期节点或约束、实际结果、例外责任人和补救记录。运行代码优先并不是否认模型价值，而是拒绝让模型存在本身替运行事实作证。

来源