摘要

  • RFC 10016 为 NMDA 增加只读的 <system> 数据存储，用来呈现系统自身提供且客户端不能删除的配置。客户端仍可在获准时通过 <running> 覆盖取值、引用系统节点，或在系统创建的条目下添加可配置的后代节点。
  • origin=system 只回答值从哪里来，不证明谁批准了它、它是否恒定或是否已经落到设备。删除覆盖值可能让原先被遮蔽的系统值重新进入 <intended>；硬件、许可证、功能或软件变化也可能让系统节点出现或消失。

一次例行清理把 <running> 里的覆盖项删掉了。变更说明写的是“恢复未配置状态”，审批者看到的也是一项删除操作。可设备并没有得到“空值”：此前被遮住的系统默认值重新浮现，合并进入 <intended>，并在条件满足后成为运行状态。

这不是设备擅自违背配置，而是变更界面把优先级说成了有无。RFC 10016 为网络管理数据存储架构增加 <system>，正是为了显露此前容易混淆的一层。它让客户端看到服务器提供了哪些配置，却没有把“看到来源”升级为“已经获得同意”。

治理上的关键问题不是系统值可不可读，而是谁能改变结果。一个数据存储可以对管理客户端只读，同时仍会随着系统条件改变；一个系统值可以无法被删除，同时被 <running> 暂时遮蔽；一个意图树可以通过校验，同时没有完全出现在 <operational>。把这些状态压成一个“当前配置”字段，责任链就会消失。

系统配置终于有了独立位置

RFC 8342 建立的 NMDA 已经区分预期应用的配置与实际使用的配置，并允许节点携带不同来源。RFC 10016 进一步定义：只要配置存在于 <system>，无论它此刻是否被引用、是否已经应用，都属于系统配置。服务器提供但客户端可以删除的内容，不在这里所说的系统配置范围内。

支持该能力的服务器实现 ietf-system-datastore 标识。其数据模型基础来自 RFC 7950 定义的 YANG，客户端可借助 RFC 8525 的 YANG Library 信息发现能力。标准化的价值在于，自动化工具不必再从厂商私有字段推断哪些节点由设备生成。

但“系统生成”有两种不同寿命。始终存在的配置会在设备启动时生成，不依赖某块特定资源，RFC 举出的例子是环回接口。条件存在的配置则依赖板卡、资源、许可证或功能。条件出现，节点随之出现；条件消失，节点也可能离开 <system>。

<system> 本身并非跨重启持久保存的数据库。服务器会按当时的条件重建它。因此，昨晚采集到的系统树不能单独证明今早重启后的输入相同。只备份 <running>，也不足以重构下一次启动时形成 <intended> 的全部材料。

只读边界之外仍有优先级

管理客户端不能直接编辑或删除 <system>，却不代表它对结果无能为力。客户端可以从 <running> 引用系统节点；服务器允许时，可以写入同一路径的值来覆盖系统值；还可能在系统创建的列表条目下面增加可配置的后代节点。

合并规则决定了谁胜出：匹配的 <running> 节点优先于 <system> 节点，然后共同形成 <intended>。如果某一输入需要模板展开、删除非活动配置或进行其他转换，两边要先各自转换，再合并。仅比较两棵原始树，不能证明合并后的值。

设系统提供 A，运营者在 <running> 写入 B，于是 B 成为胜者。后来删除 B 时，动作只移除了覆盖层，并未也不能删除 <system> 里的 A。A 随即再次进入 <intended>，随后可能应用。这类“删除引发启用”正是普通配置审计最容易漏掉的反直觉变化。

另一个方向同样危险。某块硬件退出、许可证失效或功能被关闭后，条件系统节点可能消失，而依赖它的配置仍留在 <running> 和 <intended>。由于资源已经不存在，相应节点可能不再出现在 <operational>。意图依旧存在，现实却失去了承载它的对象。

来源不是批准记录

RFC 7952 定义元数据机制，使节点能够携带来源等注记。RFC 10016 说明，从 <system> 流入且未被 <running> 明确配置或覆盖的内容，其来源为 system。来自 <running> 的配置则依照 NMDA 规则报告相应来源。

这项注记回答“谁提供了这个节点”，不回答“谁接受了这个值带来的风险”。值可能来自厂商平台、启动镜像、许可证服务、资源管理器或本地系统进程，其中未必存在一次当下的人类审批。反过来，<running> 里的值也可能是控制器自动写入，而不是工程师逐项决定。

若把 system 理解为可信或批准，组织会把厂商选择冒充本地政策；若把 running 理解为人为意图，又会把控制器产物冒充个人判断。来源是问责的必要材料，但必须和变更权限、政策审查与业务责任连接起来，才构成治理证据。

<intended> 仍然不是应用证明

当 <system> 发生变化时，RFC 10016 要求服务器立即更新并校验 <intended>。文档还表示，系统变化后 <running> 应维持为有效配置树，但如何做到并不在规范范围内。这些要求能说明数据处理发生过，不能说明每个值已经抵达硬件或转发行为。

RFC 10016 刻意不修改 <operational> 的含义。依据 RFC 8342，资源缺失、传播延迟、失败与残留状态都可能让预期和实际分离。完整路径是：<system> 与 <running> 分别完成转换，按优先级合并成 <intended>，再在现实条件允许时进入 <operational>。每一条箭头对应不同的责任和故障。

系统配置变化可以通过 RFC 8639 和 RFC 8641 所描述的 YANG 订阅与数据存储更新机制通知。通知能证明发布方在订阅覆盖范围内发出了事件，却不能单独证明消费方收到了、重新计算了政策，或验证了新的运行树。

<system> 也不应与 <factory-default> 混为一谈。RFC 8808 定义出厂默认数据存储与恢复出厂操作；RFC 10016 的 <system> 表达的是设备在当前软件、硬件与授权条件下正在提供什么。两者可能偶有相同值，却承担不同的架构角色。

建立“来源与优先级凭证”

要让有效配置可问责，可以为重大节点保留一张来源与优先级凭证。第一部分记录节点路径、值的指纹、来源和存在条件，并标注相关硬件、许可证、功能、启动或软件纪元。这样，“系统值”就不会被误写成无时间边界的常数。

第二部分记录可变性与合并：系统节点是否允许覆盖，哪个 <running> 节点引用或遮蔽它，系统条目下增加了哪些后代节点，两侧各执行了什么转换，最终哪个值进入 <intended>。任何删除覆盖的审批，都要事先展示将重新露出的系统值。

第三部分比较 <intended> 与 <operational>，记录应用时间、资源是否存在、延迟、失败、残留状态，以及用来判断“已经生效”的确切证据。引用语法有效，不代表目标资源活动；意图树合法，也不代表设备具备执行条件。

最后一部分分开记录系统提供方、配置客户端、运营批准者与风险责任人。软件升级、授权变化、硬件插入或政策提交，都应关联到接受结果的决定。敏感内容可以受控保存，但路径、指纹和审计引用不能因此消失。

这张凭证是 Daniel Kade 的编辑治理建议，不是 RFC 10016 新增的协议义务。它的作用，是防止组织把可见来源、合并胜者、批准决定与实际结果当成同一件事。

安全首先要求管好读取

只读并不等于无害。RFC 10016 提醒，<system> 可能暴露硬件标识、安全政策和关键资源。敏感节点与子树需要访问控制，读取尝试也应被记录。RFC 8341 提供 NACM，用于约束 NETCONF 与 RESTCONF 用户能访问的内容。

覆盖路径则带来另一类风险。攻击者或出错的客户端可以在 <running> 写入同路径叶子，遮蔽安全相关的系统值，造成政策绕过或可用性故障，而 <system> 自身从未被改动。如果监控只关注对 <system> 的写入，实际上是在守一条客户端本来就走不了的路。

RFC 10016 的贡献很明确：让系统配置可检查，让 NMDA 客户端能够以标准方式理解它。它没有保证系统选择永远不变，没有替运营者批准厂商默认，也没有证明配置已经应用。可见性只是控制的起点；治理必须继续追踪优先级和运行结果。

来源