本文是利用AI创作的技术说明与实现示例。所发布的代码和步骤基于一手资料构建，但未经作者在实际设备上进行运行验证。根据环境和版本的不同，运行表现可能会有所差异。 本文将基于规范，安全且实用地产读RFC 10016中规定的“系统定义配置（System-Defined Configuration）”概念及其在网络管理数据存储架构（NMDA）中的定位。同时，将根据规范梳理设备自身提供的配置数据存储机制，以及与客户端管理下的数据存储的集成模型。
目的
本文旨在根据RFC 10016（系统定义配置）规范文档，明确系统配置数据存储（<system>）的定义、与传统配置数据存储的关系以及数据合并的概念。
前提与注意事项
本文基于互联网标准跟踪文档RFC 10016的公开信息。
本文针对禁止客户端直接写入的只读数据存储的行为。
若要在【计划于Windows环境中确认】的实机验证中进行测试，则取决于对应的NETCONF/RESTCONF服务器环境以及YANG模块（
ietf-system-datastore）的引入情况。
系统配置数据存储（<system>）概述
定义了网络管理数据存储架构（NMDA）的RFC 8342中，已经存在由设备自身提供并显现在运行状态中的系统配置概念。然而，无论是否处于运行状态，市场一直需要一种标准机制，以便服务器能够更清晰地公开系统配置。
为了响应这一需求，RFC 10016引入了只读配置数据存储 <system>。这使得NETCONF和RESTCONF客户端能够以标准方法获取服务器上可用的系统配置。
flowchart TD
Candidate["<candidate> (rw)"] --> Running["<running> (rw)"]
Startup["<startup> (rw)"] --> Running
System["<system> (ro)"] --> Intended["<intended> (ro)"]
Running --> Intended
Factory["<factory-default> (ro)"] --> Running
Intended --> Operational["<operational> (ro)"]
系统配置的类型
根据一手资料，系统配置大致可分为以下两种类型。
Always Present（常驻配置）
- 指设备上电时生成的配置，无论是否存在物理资源或特定功能是否启用。例如，始终存在的环回接口等。
Conditionally Present（条件配置）
- 此类配置仅在满足特定条件时生成。例如，当插入接口卡等物理资源时自动检测并加载的配置，或者在启用特定许可证或功能时创建的配置。
数据store的概念模型与合并处理
客户端可以在<running>中引用<system>定义的节点、覆盖系统提供的值，或者设置系统定义配置的子节点。
<intended>为确保<running>的有效性，<system>的配置将与<running>进行合并。在此过程中，出现在<system>中的配置将优先于同一步骤中的节点。此外，如果需要进行模板展开或删除未激活配置等配置转换，则这些转换将在每个数据store上独立执行后才进行合并。
关于客户端操作的限制事项
<system>数据store是只读的，必须拒绝（MUST）客户端的直接编辑请求。此外，<system>中的配置不会在重启（reboot）之间持久化，客户端也无法通过协议操作将其删除。
即使由于资源丢失等原因导致系统配置中的数据被清除，它也可能作为未应用的配置残留在<running>或<intended>中，但不会出现在表示实际生效状态的<operational>中。
总结
RFC 10016中添加的
<system>数据store是设备自身提供的只读配置数据store。客户端无法直接写入，
<running>但可以在一侧覆盖或引用这些值。作为执行前应确认的事项，需要逐个验证环境确认目标设备的 NMDA 支持情况、
ietf-system-datastore是否实现了 YANG 模块，以及协议（NETCONF/RESTCONF）的规范符合性。
