YANG Modules Describing Capabilities for Systems and Datastore Update Notifications
Extracted elements (23)
A four-step capability lookup algorithm is defined: (1) find the datastore entry; (2) scan per-node-capabilities in order for the first entry matching the node and specifying the capability; (3) fall back to the system-level capability; (4) if still not found, the system behavior is unspecified. This hierarchy allows per-node values to override datastore-level values, which override system-level values.
Capability information must be available both at implementation time (for NMS designers who cannot wait for a live network node) and at runtime (for purely model-driven applications or to verify implementation claims). An NMS that supports on-change notifications cannot be built unless capability data is available before the node is deployed.
The capability representation format is designed to be vendor-independent, machine-readable, and available in an identical format at both implementation time and runtime. This allows NMS implementers and system integrators to plan management practices before buying a network node type.
For non-NMDA servers, 'config false' data is considered as if it were part of the running datastore, allowing the ietf-system-capabilities model to be used on both NMDA and non-NMDA systems.
If different data nodes covered by a single subscription have different values for a specific capability, using values acceptable for only some of those nodes may result in the rejection of the subscription. Subscribers must account for the most restrictive capability across the subscription scope.
Every set of capabilities augmented into ietf-system-capabilities MUST be wrapped in a container under the augment statement to cleanly separate different groups of capabilities. These wrapper containers SHALL be augmented at /sysc:system-capabilities and /sysc:system-capabilities/sysc:datastore-capabilities/sysc:per-node-capabilities.
For the implementation-time use case, capabilities SHOULD be provided by the implementer as YANG instance data files complying with RFC 9195. When provided, the file MUST already be available at implementation time and retrievable without a live network node.
For the runtime use case, capabilities SHOULD be available via NETCONF or RESTCONF from the live server during runtime. Implementations that support changing capabilities at runtime SHOULD support on-change notifications about the system-capabilities container.
The same grouping MUST be used to define hierarchical capabilities supported both at the system level and at the datastore/data-node level, ensuring consistency across the capability hierarchy.
The system SHALL order the per-node-capabilities entries according to their precedence. The order of the entries MUST NOT change unless the underlying capabilities also change. Longest-path matching is achieved by ordering more specific matches before less specific ones.
The ietf-notification-capabilities module augments ietf-system-capabilities at both the system level and per-node-capabilities level with a subscription-capabilities container. It imports the yp:on-change feature from ietf-yang-push (RFC 8641) to guard on-change-specific leaves.
The ietf-system-capabilities module provides a read-only system-capabilities container with a datastore-capabilities list (keyed by datastore leafref into yang-library) and nested per-node-capabilities entries with an optional node-selector of type nacm:node-instance-identifier. The module itself defines no concrete capabilities; it only provides augmentation points.
The max-nodes-per-update leaf (uint32, range 1..max) specifies the maximum number of data nodes that can be sent in a single update. The publisher MAY support more but SHOULD support at least this number; it can be used to avoid the 'update-too-big' error during subscription.
The minimum-dampening-period leaf (uint32, centiseconds, guarded by yp:on-change) specifies the minimum dampening period for on-change subscriptions. If present and greater than zero, dampening is mandatory for the selected data nodes.
The notification-support typedef is a bits type with two bits: config-changes (publisher can send notifications for 'config true' nodes) and state-changes (publisher can send notifications for 'config false' nodes). It is used by periodic-notifications-supported and on-change-supported leaves.
The on-change-supported leaf (type notification-support, guarded by yp:on-change feature) specifies whether the publisher can send on-change notifications for selected data nodes and their subtrees, distinguishing between config-changes and state-changes.
The supported-excluded-change-type leaf-list (guarded by yp:on-change) indicates which change types can be excluded in YANG-Push subscriptions. Special enum values 'none' (no change types can be excluded) and 'all' (any combination can be excluded) supplement the yp:change-type union. Default is 'none'.
The update-period choice contains either minimum-update-period (uint32, centiseconds) indicating the smallest acceptable period for a periodic subscription, or supported-update-period (leaf-list of uint32, centiseconds) listing the exact allowed values. A request outside these values results in a 'period-unsupported' error.
Two URIs are registered in the IETF XML Registry (RFC 3688): urn:ietf:params:xml:ns:yang:ietf-system-capabilities and urn:ietf:params:xml:ns:yang:ietf-notification-capabilities.
Two YANG modules are registered in the YANG Module Names registry (RFC 6020): ietf-system-capabilities (prefix sysc) and ietf-notification-capabilities (prefix notc), both referencing RFC 9196.
Capability information may allow an attacker to determine how long unauthorized configuration changes might remain undetected (e.g., from minimum update periods) and which communication channels to disrupt to extend the non-detection window. Documents augmenting this module are encouraged to document security considerations of their new YANG nodes per BCP 216.
NETCONF access to capability data MUST use SSH (RFC 6242) as the mandatory-to-implement secure transport; RESTCONF MUST use HTTPS with TLS (RFC 8446). NACM (RFC 8341) provides access control to restrict which users can read capability data.
When capability data is in file format it should be protected against modification or unauthorized access using normal file-handling mechanisms, and it inherits all security considerations of RFC 9195, including protections for data at rest and in motion.