摘要

  • 一个接口出现在设备上，不代表它就属于当前网络实例的有效引用范围；挂载时选择的父级数据会参与这个判断。
  • parent-reference 可以让父级节点参与挂载模型的 XPath 求值，但不会据此把这些节点开放成挂载树上的 NETCONF 或 RESTCONF 读写对象。
  • 模型作用范围、配置是否只读、用户具有什么权限，是三件不同的事。共享模型不能替代上下文交接，更不能直接证明租户隔离。

排查配置问题时，“这个接口明明存在”是一句很容易让讨论走错方向的话。它回答了设备有没有这个接口，却没有回答：当前网络实例的模型，校验时应当把哪些接口算进来？如果接口属于另一个实例，存在本身就不是充分条件。

YANG Schema Mount 所处理的，正是完整模型如何放进另一个模型的问题。它允许既有模型继续使用自己的定义，不必为了每一种外围设备结构另写一份版本。代价并不是规范失去确定性，而是决定具体含义的材料不再全部集中在那一份模型文件里。

理解这种代价，不妨先看 RFC 8528 的附录 A.3：示例按照接口绑定的网络实例名称，从父级模型筛选接口。挂载在网络实例之下的路由模型，因而可以引用对应的出接口，即使接口模块并不是这个挂载模式本身的一部分。规则得到了一组可以参照的对象，接口对象的管理权却没有因此一并转交。

这只是规范中的非规范性示例，不是某家设备商的现网记录，也不是一次故障复盘。它的价值在于把责任边界具体化：一份未改动的模块，仍然可能在不同的外围安排下，对同一段候选配置得出不同结果。要判断这种差异是否合理，必须把真正参与求值的上下文找出来。

复用的是模型，不是整个环境

挂载点由父级模型提供，位置可以是容器或列表。完整模型被放在这里以后，模型内部的路径以挂载点为根来理解，而不是天然指向物理设备的整棵数据树。父级设计者提供位置，运行时呈现的挂载信息说明这里采用什么模式，挂载模型提供自己的节点与约束。三者不是同一份东西。

这样的分工很有用。假如路由模型必须为所有可能的外围结构预先写好版本，维护负担会迅速膨胀。把组合关系放到模块之外，可以让同一套定义在多个场景中使用。可复用性因此提高，但“组合关系由谁维护”也成为一个独立问题。

模型团队说文件没有变化，可能完全正确；平台团队说父级分配符合平台规则，也可能完全正确。若没有人检查这次分配会让下层约束引用什么，两种正确仍然不足以解释最终结果。这里缺的不是再做一次文件比较，而是识别文件之外的依赖。

也不能把挂载元数据当作随手可改的配置入口。规范中的 schema-mounts 是运行状态信息，用来描述服务器提供的组合安排。规范没有统一规定服务器如何产生所有实例、从哪里取得底层数据，或者通过哪种管理动作改变这些安排。看到状态树，不等于找到了一个通用的写入开关。

“看见”不只有一种含义

共享模式中的 parent-reference 提供了一种有意保留的联系。它先在父级上下文中执行 XPath 表达式，选出节点集合，再把这些集合及其祖先节点加入挂载模型进行 XPath 求值时的可访问树。换句话说，外围数据可以成为下层规则的判断依据。

但规则能够引用，并不意味着客户端就能通过挂载树读取或修改这些外围节点。RFC 8528 明确区分了求值所用的可访问树与 NETCONF、RESTCONF 协议操作所能访问的数据。这一区分并非措辞上的修饰：一个团队可能负责下层配置，另一个团队仍然负责接口分配；下层规则必须理解分配结果，却没有因此取得上层管理权限。

规范有时用“mount jail”描述路径的范围。如果把这个词理解成租户安全牢笼，就会读错。它首先约束的是模型路径如何解释，不是进程如何隔离、网络如何分段，或者用户可以调用什么操作。给一项技术机制换上安全含义更强的名字，不会让它自动多出一层保证。

同样，把数据标成只读，也不等于决定了谁能读。挂载点或相应挂载信息的 config 为 false 时，挂载数据会成为只读状态；用户访问控制则还需要另外处理。某个普通用户不能改、所有用户都不能改、某个字段不属于配置数据，这几种情况不应混写成一句“受保护”。

接口归属怎样影响判断

在 YANG 1.1 语言规范 RFC 7950 中，must 用表达式声明数据必须满足的条件。叶引用还有一个重要区别：require-instance 为 true 时，合法数据需要满足对应实例存在的要求；为 false 时，实例可以不存在。默认值及配置数据之间的引用也有各自规则。不能把所有引用都压成同一种存在性检查。

回到接口筛选的例子。如果父级绑定变化，某个网络实例选到的接口集合也可能变化。恰好依赖这个集合的约束，就可能在候选配置和模块定义都未改动的情况下，面对不同的求值输入。这里说的是按规范机制得出的条件性分析，而不是宣称某台路由器已经接受错误配置或中断转发。

这个限定很重要。不是每个父级变化都会影响下层结果，也不是每条约束都读取父级数据。有的编辑并不改变筛选后的集合，有的约束与这组接口无关。调查必须沿着实际依赖追踪，不能把“父级变过”当作无需解释的结论。

标准示例也需要按对象关系阅读。已验证的第 5797 号编辑性勘误修正的是另一处逻辑网络元素示例：接口的绑定字段应填写逻辑元素名称，而不是接口自身名称。这不是推翻父级引用机制，而是提醒读者，字段中的两个字符串即使都像一个设备标识，也可能属于完全不同的对象范围。拿一份看起来像样的示例直接套用，不能代替核对关系含义。

共享模式也有每个实例自己的现实

共享模式要求同一挂载点的实例使用相同的模式；inline 模式允许各实例挂载不同模式。运行状态中的每个挂载实例都需要提供 YANG Library 信息。不过，两个 inline 实例的库内容标识恰好相等，并不能证明它们的库内容相同，RFC 8528 对此有明确提醒。

更容易遗漏的是另一层差异：共享模式不等于共享普通业务数据。同一条父级筛选表达式，从不同网络实例出发，可以选到不同接口。库信息描述了实现的模式，并没有把每一个被引用的父级数值都变成库版本的一部分。只盯着模块列表或库标识，未必能发现普通父级数据变化带来的影响。

因此，需要交接的不只是“挂了哪些模块”，还包括“这个实例会参考哪一组外围对象”。前者适合回答实现范围，后者才能帮助解释具体约束为什么在这里成立。二者可以共同记录，却不能相互替代。

权限审查不能在模型边界处结束

如果系统实现 NACM，挂载节点仍然通过组合后数据树中的路径受到访问控制。它并没有因为被挂载，就自然获得一套与父级无关的私有权限世界。共享管理与拆分管理描述的是会话组织方式，也不能单凭名称推断出计算资源或租户之间的完整隔离。

RFC 8341 的 NACM 安全讨论还指出，模型依赖、叶引用及隐含副作用值得额外检查。禁止直接读取，并不自动穷尽用户可能通过相关数据或允许操作获得的信息。这是一般性的模型与访问控制风险提示，不是本文发现了某个 Schema Mount 漏洞。

合理的审查应当同时避开两个极端：不能看到父级引用就断言隔离失败，也不能看到直接读权限被拒绝就宣称隔离已经证明。需要核对的是实际模型、会话、权限与可观察行为。在证据没有覆盖这些层次之前，结论也应停在相应边界。

对自动化运维而言，落点并不玄妙：模型验收要回答规则是否符合预期，集成验收还要回答规则究竟在什么环境里执行。把第二项责任漏掉，第一项做得再认真，也只能说明文件没有问题。