Network Management Datastore Architecture (NMDA)
updates
- rfc-7950 — The YANG 1.1 Data Modeling Language
Extracted elements (25)
Configuration for missing resources (e.g., an interface not currently present) is allowed to exist in <running> and <intended> but will not appear in <operational>. This prevents a missing resource from rendering the configuration invalid and causing devices to restart with invalid configurations after a reboot.
<operational> incorporates 'config true' nodes (unlike the original NETCONF model which only had 'config false' nodes) to expose all operational settings without requiring replication of definitions in data models. This allows a single unified view of both configuration and state.
The original NETCONF datastore model required configuration and operational state data objects to be modeled twice in the YANG schema—as 'config true' and 'config false' nodes—leading to duplication, separate branches, and non-machine-readable relationships between branches. NMDA solves this by defining data objects only once while allowing independent instantiations in different datastores.
Conventional configuration datastores (<running>, <candidate>, <startup>, <intended>) share exactly the same datastore schema, enabling data to be copied between them (e.g., NETCONF <copy-config>). Modules with no configuration data nodes MAY be omitted from the conventional datastore schema.
This document updates RFC 7950 (YANG 1.1) by refining the accessible tree for XPath contexts (Section 6.1) and the invocation context of actions/RPCs (Section 6.2). XPath expressions on system state nodes now have access to all operational state, not just the configuration tree.
Actions are always invoked in the context of the operational state datastore. The node for which the action is invoked MUST exist in the operational state datastore.
For all configuration data nodes in <operational>, the device SHOULD report the origin that most accurately reflects the source of the configuration in use by the system. If a device cannot provide an accurate origin, it SHOULD use the origin 'unknown'.
Functionality that is neither enabled nor operational on the system is considered not to be 'in use' and SHOULD be omitted from <operational>. Requests to retrieve nodes from <operational> always return the value in use if the node exists.
Only semantic constraints (YANG 'when', 'must', 'mandatory', 'unique', 'min-elements', 'max-elements', and key uniqueness) MAY be violated in <operational>. Deviations SHOULD be used when it is known in advance that a device does not fully conform.
<running> MUST be supported if the device can be configured via conventional configuration datastores.
Syntactic constraints MUST NOT be violated in <operational>, including hierarchical organization, identifiers, and type-based constraints. If a node does not meet syntactic constraints, it MUST NOT be returned.
The datastore schema for <operational> MUST be a superset of the combined datastore schema used in all configuration datastores, except that configuration data nodes MAY be omitted from <operational> if a server cannot accurately report them.
Whenever data is written to <running>, the server MUST also immediately update and validate <intended>. <intended> MUST always be a valid configuration data tree as defined in RFC 7950 Section 8.1.
Dynamic configuration datastores hold configuration obtained dynamically during device operation through interaction with other systems, rather than through conventional configuration datastores. Their datastore schema MAY differ from conventional datastores, and they interact with the rest of the system through <operational>.
Six origin identity values are defined: 'intended' (from <intended>), 'dynamic' (from a dynamic configuration datastore), 'system' (provided by the device itself), 'learned' (from protocol interactions such as routing protocols or DHCP), 'default' (from YANG default values), and 'unknown' (origin cannot be identified).
The <candidate> configuration datastore can be manipulated without impacting the running configuration and committed to <running>. It does not persist across reboots; if stored in non-volatile storage, it is reset at boot to the contents of <running>.
The <intended> configuration datastore is a read-only datastore representing the configuration after all transformations to <running> are performed (template expansion, removal of inactive configuration). It is the configuration the system attempts to apply and must always be a valid configuration data tree.
The <operational> datastore is a read-only datastore containing all 'config true' and 'config false' nodes, representing the complete operational state including applied configuration from <intended>, learned configuration, system-provided configuration, dynamic configuration datastores, and default values.
The 'origin' metadata annotation (defined in ietf-origin YANG module) can appear on any configuration data node in <operational>, indicating its source. The annotation is inherited from parent nodes if not specified; it MUST be specified for all top-level configuration data nodes.
The <running> configuration datastore holds the current configuration of the device. It MAY include configuration requiring further transformation (e.g., inactive configuration, templates) before it can be applied, but MUST always be a valid configuration data tree per RFC 7950 Section 8.1.
The <startup> configuration datastore holds the configuration loaded by the device when it boots. It is only present on devices that separate startup from running configuration, and its contents persist across reboots via non-volatile storage.
Two URIs are registered in the IETF XML Registry (RFC 3688): urn:ietf:params:xml:ns:yang:ietf-datastores and urn:ietf:params:xml:ns:yang:ietf-origin, both as XML namespaces with IESG as registrant contact.
Two YANG modules are registered in the YANG Module Names registry (RFC 6020): 'ietf-datastores' (namespace urn:ietf:params:xml:ns:yang:ietf-datastores, prefix ds) and 'ietf-origin' (namespace urn:ietf:params:xml:ns:yang:ietf-origin, prefix or), both referencing RFC 8342.
The 'origin' metadata annotation exposes the origin of values in the applied configuration, potentially revealing which control-plane protocols are active on a device. Since origin information is tied to applied configuration values, it is only accessible to clients with permissions to read those values; security administrators should consider the sensitivity of origin information when defining access control rules.
Remnant configuration describes the state where <operational> contains nodes from both previous and current configuration during a transition period after configuration deletion. The remnant persists until resources used by the deleted configuration (network connections, memory, file handles) are fully released.