摘要

  • RFC 10016 新增只允许管理客户端读取的 <system> 数据存储，用来暴露设备自行提供的配置；只读不等于静止，软件、许可证和硬件变化都可能重写它。
  • <running> 中获准覆盖的同名节点优先于系统值。删除覆盖后，系统值会重新出现在 <intended>；硬件撤下时，客户端配置又可能留在 <running> 与 <intended>，却无法进入 <operational>。
  • 标准确定了先分别变换、再合并、立即校验的次序，但没有替运营者解决通知覆盖、校验失败、应用延迟、例外和回滚责任。

一个“成功”的控制器与一台没有该功能的设备

许可证到期后，设备取消了一组系统生成的策略节点。自动化平台没有报提交失败，因为它几个月前写入 <running> 的参数还在。平台的期望状态页面依旧是绿色，设备却不再把这组参数应用到运行状态。

如果把所有层都叫“配置”，双方看起来只能有一个是错的。RFC 10016 给出了更精确的解释。<system> 表示设备当前提供的系统配置；<running> 保存客户端明确提交的配置；<intended> 是分别完成必要变换后，把两者合并并通过校验的目标；<operational> 才显示实际使用的配置与状态。

许可证撤下的是系统条件，不是客户端历史。客户端条目因此可以继续存在于 <running>，甚至出现在 <intended>，但在缺少功能或资源时不会应用，也不会出现在 <operational>。绿色的提交记录只证明控制器曾写入成功，不能证明设备今天仍有执行条件。

只读限制的是入口，不是时间

RFC 10016 要求 NETCONF、RESTCONF 等管理客户端不能直接编辑 <system>。这个规则防止客户端冒充系统来源，却没有承诺内容永远不变。设备上电可生成始终存在的节点；插卡、启用许可证或功能可生成条件节点；拔卡、关闭功能或软件升级又可使它们变化或消失。

<system> 也不跨重启持久化。设备重启后重新生成当前系统配置。这一点与 RFC 8808 的 <factory-default> 相反：后者由厂商定义，必须跨重启保留，并可在恢复出厂时初始化可写数据存储。把两者都简称为“默认值”，会在恢复场景中制造错误假设。

只读还不等于不可覆盖。服务器可以允许某些系统节点由客户端在 <running> 中写入同名值。客户端没有修改 <system>；它只是让自己的值在合并时拥有更高优先级。是否允许覆盖、允许到哪个节点，仍由服务器能力与访问策略决定。

删除操作可能让另一个值复活

设想设备在 <system> 中给某接口提供一个启用值。控制器在获准范围内写入不同值，因此 <running> 在合并结果中胜出。以后系统值即使变化，只要覆盖还在，客户端值仍优先。

维护人员若删除这条覆盖，结果并不是“没有值”。RFC 10016 明确说明，系统初始化值会重新进入 <intended>，若应用成功便可能投入使用。表面上的清理动作，实际是在释放下层来源的执行机会。变更审批不能只显示被删路径，还必须显示覆盖下面当前等待的系统值。

硬件撤下产生另一种反转。系统节点随着物理条件消失，客户端为该资源准备的地址或描述仍可保留。重新插卡时，新的系统节点与旧的客户端意图再次相遇。若团队没有在恢复资源前审查这组休眠配置，历史意图可能在新的设备条件下突然生效。

这两种情形不能用同一个“漂移修复”动作处理。删除覆盖要验证将要回归的系统值；撤下资源要保留但标明未应用的客户端意图；恢复资源则要重新评估两者合并后的目标。

次序是共同规则，处置仍是本地责任

RFC 10016 规定，若 <system> 或 <running> 包含模板展开、停用节点移除等变换，两边必须各自完成变换，再进行合并。允许覆盖时，<running> 的同名节点优先。系统配置一旦变化，服务器必须立即更新并校验 <intended>。

但文档只说系统变化后 <running> 应保持有效，如何做到则不在规范范围。许可证变化可能撤掉一个被客户端引用的目标，升级可能改变约束，硬件消失可能让一组合法目标无法应用。标准给出校验时点，不替组织选择暂停发布、隔离设备、修复引用还是回滚软件。

RFC 8342 对 <intended> 与 <operational> 的区分因此至关重要。前者是系统尝试应用的配置，后者反映真正运行的结果。资源缺失、延迟等本地因素都可能造成差异。校验通过不能替代运行证据。

可见性扩大了安全面

标准化 <system> 让控制器可以看见原先只能猜测的系统来源。旧 NMDA 客户端仍能使用原有数据存储，但若要理解覆盖和系统节点，就必须升级自己的模型。

新的读取面可能包含硬件标识、安全策略和关键资源。RFC 10016 要求对敏感节点限制读取，并强烈建议记录访问尝试。RFC 8341 提供 NACM，但具体身份、组和许可仍需运营者配置。

覆盖能力也可能成为绕过路径。错误或恶意的 <running> 值可以遮蔽敏感系统节点，导致策略绕过或可用性损失。因此，“系统源只读”并不能证明最终合并结果安全。

设备可通过 RFC 8639 与 RFC 8641 的订阅和 on-change 更新报告变化，但不同实现、不同对象的覆盖能力可能不同。安静的通知流既可能表示没有变化，也可能表示该对象从未被覆盖。必须保留完整同步、序列连续性和定期对账。

Heng Lu 的运行代码优先原则在这里不是修辞：控制器记录、标准模型和注册表分别描述意图与规则，只有设备执行出的 <operational> 能证明哪一层成为现实。他提出的最小初始规范与未来本地决策也给出合理边界：共同层固定合并和校验规则，具体覆盖、上线、止损与回滚仍由运行设备的责任主体决定。