RFC 10016: Organizing the communication sequences and data structures of System-Defined Configuration

This article is a technical explanation and implementation example generated using AI. The code and procedures presented are based on primary sources, but have not been verified on actual hardware by the author. Behavior may vary depending on the environment and version. We safely and practically interpret the concept of ‘System-Defined Configuration’ defined in RFC 10016 and its positioning within the Network Management Datastore Architecture (NMDA). Based on the specification, we organize the mechanism of the configuration datastore provided by the device itself and the integration model with client-managed datastores.

Objective

Based on the RFC 10016 (System-Defined Configuration) specification, the objective is to clarify the definition of the system configuration datastore (<system>), its relationship with conventional configuration datastores, and the concept of data merging.

Prerequisites and Cautions

• This article is based on publicly available information from RFC 10016, which is an Internet Standards Track document.

• It covers the behavior of read-only datastores where direct writes from clients are prohibited.

• When performing actual hardware verification [planned to be checked in a Windows environment], it depends on the deployment status of the corresponding NETCONF/RESTCONF server environment and YANG modules (ietf-system-datastore).

Overview of the System Configuration Datastore (<system>)

RFC 8342, which defines the Network Management Datastore Architecture (NMDA), introduced the concept of system configuration supplied by the device itself and appearing in operational state. However, there was a need for a standard mechanism for servers to more clearly expose system configuration regardless of whether they are running.

To meet this requirement, RFC 10016 introduces <system>, which is a read-only configuration datastore. This enables NETCONF and RESTCONF clients to retrieve the system configurations available on the server using standard methods.

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)"]

Types of System Configurations

According to the primary source, system configurations are broadly explained to fall into the following two types.

1. Always Present Configuration

   • This configuration is generated when the device is powered on, regardless of the presence of physical resources or whether specific features are enabled or disabled. Examples include loopback interfaces that are always present.

2. Conditionally Present Configuration

   • This configuration is generated only when specific conditions are met. Examples include configurations that are automatically detected and loaded when physical resources, such as interface cards, are inserted, or configurations that are created when specific licenses and features are enabled.

Conceptual Model of Datastores and Merging Processing

Clients can reference nodes defined in <system> from within <running>, override system-provided values, or configure child nodes of system-defined configurations.

To ensure the validity of <intended>, the configuration of <system> is merged with <running>. In this process, configurations appearing in <running> take precedence over the same nodes in <system>. Additionally, when configuration transformations such as template expansion or removal of inactive configurations are required, these transformations are executed independently for each datastore before the merge takes place.

Limitations on Client Operations

<system> datastores are read-only, and direct edit requests from clients must be rejected (MUST). Furthermore, <system> configurations are not persistent across reboots, nor can they be deleted by clients through protocol operations.

Even if data is cleared from the system configuration due to resource loss or similar events, it may still remain in <running> or as an unapplied configuration, but it will not appear in <intended> or <operational> which indicate the operational state.

Conclusion

• Added in RFC 10016, <system> datastore is a read-only configuration datastore provided by the device itself.

• While clients cannot write directly, it is possible to overwrite or reference values on the <running> side.

• Points to check prior to execution include verifying the target device’s NMDA support status, the presence of ietf-system-datastore YANG module implementations, and protocol (NETCONF/RESTCONF) specification compliance for each verification environment.

Reference Information

• RFC 10016: System-Defined Configuration