The mdt-datastore indicates which datastore a given set of capabilities apply to. Datastores are described in RFC 8342 . • mdt-per-node: Below the mdt-datastore list is the per-node capabilities list, mdt-per-node . Each entry in this list represents an inflection point, and each of these entries contains an XPath and a set of capabilities. Determining the Capabilities of a Node To determine the capabilities of a particular node in a YANG model, the mdt-per-node list is searched to verify if any entry has an XPath that selects this node. The order of the entries is important. The first entry that selects a given node is what determines the capabilities of that node.
During a search, more-specific XPaths typically appear before less-specific ones. Note that the XPath in the mdt-per-node list may not be an exact match for the node being checked. In this example, the mdt-per-node list contains the following XPaths, in the order: 1. /interfaces/interface/state/counters 2. /interfaces/interface/state 3. /interfaces/interface The capabilities of the node /interfaces/interface/state will be entry 2, the capabilities of the node /interfaces/interface/config , will be entry 3, and the capabilities of the node /interfaces will be given by the system capabilities, because this node is not selected by any entry.
Transport-Specific Capabilities The capabilities model has another level—the transport-dependent, per-node capabilities list, mdt-transport-per-node . This node works the same as the mdt-per-node ; but it gives capabilities for a particular transport protocol (gNMI, gRPC, or NETCONF). This node is required because in some cases, on-change support can differ depending on the transport that is used to create subscriptions. For example, gRPC supports on-change on some paths that NETCONF does not support. To determine the capabilities of a node for a particular transport, first check the mdt-transport-per-node list for that transport. If no match is found, check the mdt-per-node list.
If again no match is found, then fall back to the system capabilities. To determine the general on-change support without regard to a particular transport, skip the mdt-transport-per-node list, and start checking from the mdt-per-node list. Capability Specification A capability specification, either at the system or per-node level consists of two fields, is-valid and a bit field. The is-valid field is an empty leaf node. The presence of the is-valid field indicates that the capability applies to that entry. Not all entries will specify all capabilities. For example, entries in the mdt-per-node list only specify the on-change capabilities, and not the periodic capabilities.
As a result, these entries will have on-change-is-valid set, and periodic-is-valid unset. The bit field indicates the actual support. There are two bit values, mdt-cap-notif-config and mdt-cap-notif-state , which indicate that the capability is supported for config or operational nodes, respectively. This sample capability specification indicates that on-change is supported for both config and operational nodes; however it does not indicate periodic support. Model-Driven Telemetry Displaying On-Change Subscription Capabilities Model-Driven Telemetry 30