Validating anydata in YANG Library context

3.1. Selection filters

Subtree filters (Section 6 of [RFC6241]) are carried in "anydata" by [RFC8526], [RFC9144], [RFC8641] and [I-D.ietf-netconf-yang-push-2], where they select a subtree of a datastore, and by [RFC8639], where they select event records from an event stream. In the datastore case the anchor is the datastore root of the datastore named by the operation or the subscription. In the event stream case the top-level node is a notification, whose schema is defined by a "notification" statement in the publisher's YANG Library; the content is therefore not undefined YANG-like data.¶

A subtree filter is a pattern, not instance data: selection nodes are empty, containment nodes may omit list keys, and mandatory nodes are usually absent. Only the node names, and the values of content match nodes, can be checked against the schema.¶

3.2. Retrieved datastore content

The "data" output of get-data [RFC8526] and the "datastore-contents" of push-update [RFC8641] carry the part of a datastore that matched a selection filter, anchored at the datastore root. The schema and the validation rules are those of the selected datastore: content from <operational> includes "config false" nodes and may carry origin metadata [RFC7952], and it need not satisfy constraints that apply only to configuration datastores (Section 5.3 of [RFC8342]).¶

3.3. Edits and differences

The edit-data operation [RFC8526] carries configuration anchored at the datastore root, together with operation metadata, and the server validates the result.¶

YANG Patch [RFC8072] carries the new content of each edit in the "value" node. The top-level node of "value" is an instance of the data node identified by the "target" leaf. "target" is an absolute path when the PATCH request targets the datastore resource and a path relative to the target resource otherwise (Section 2.4 of [RFC8072]). The anchor is therefore the parent of the target data node, and it is only known after "target" is resolved. The anchor is kept as an instance path with its list key values: the schema node is found by ignoring the keys, and the keys identify the ancestor instances of the content, so that references from the content to its ancestors can be evaluated.¶

The YANG Patch structure is reused by push-change-update [RFC8641] to report on-change updates of the subscription's target datastore, and by the compare operation [RFC9144] to report differences. RFC 8641 and RFC 9144 do not state the base of "target"; their examples use absolute paths. In RFC 9144, one edit carries content from two datastores: "value" from the target datastore and "source-value", an augmentation, from the source datastore. The two nodes of the same edit can therefore be subject to different datastore rules, for example <intended> and <operational>.¶

The update notification of [I-D.ietf-netconf-yang-push-2] carries "merge" and "replaced-by" content relative to the path formed by a common "path-prefix" and a per-update "target-path".¶

3.4. Stored instance data and templates

YANG Instance Data [RFC9195] stores a data tree in "content-data", anchored at the root, and states that the data MUST conform to the YANG modules given in "content-schema". The schema context is given as a list of modules, as an inline YANG Library in the "inline-yang-library" node, or as a reference to another instance data file. RFC 9195 thus already describes the schema of "anydata" content with YANG Library. The "inline-yang-library" node is itself "anydata" whose schema is fixed by its description (ietf-yang-library revision 2019-01-04).¶

YANG Configuration Templates [I-D.tt-netmod-yang-config-templates] store template content as "anydata" in <running>, or in <system> where supported. A "data-path" leaf anchors the content at any location of the schema tree, defaulting to the root. Servers SHOULD validate a template when it is defined and MUST validate it when it is applied, but a template need not contain mandatory nodes, so definition-time validation cannot apply all constraints.¶

3.5. Message payloads

The notification envelope [I-D.ietf-netconf-notif-envelope] carries the content of a notification in the "contents" node of a YANG structure [RFC8791]. The name and namespace of the top-level node are those of the module that defines the notification, so the content can be validated against the publisher's YANG Library; it is not datastore content.¶

The telemetry message [I-D.ietf-nmop-message-broker-telemetry-message] carries the message received from a network element in the "payload" node. The payload is a YANG-Push notification [RFC8641], so its first-level node is that notification, under the root "/". The "datastore-contents" inside the notification is a nested "anydata" node with its own validation context: its anchor is again "/", and its datastore is the subscription's target datastore. The subscription metadata identifies that datastore and the filter, and can identify the publisher's YANG Library through "yang-library-content-id". Unlike most uses, the message thus carries the schema context and the datastore together with the content. Operator labels may also carry "anydata" values whose schema is not defined.¶

3.6. Content without a defined schema

RESTCONF [RFC8040] uses "error-info" to convey additional error information as a container of data nodes. Neither the anchor nor the schema of that information is defined by RESTCONF or signaled in the response.¶

3.7. Schema mount on an "anydata" node

The connectionless OAM model [RFC8532] defines an "anydata" node named "root" with the "mount-point" extension of [RFC8528], so that technology-specific modules can be mounted under each test point. The mounted schema is described by the schema mount data, which includes YANG library data for the mount point (Section 3.3 of [RFC8528]). The content is validated against that mounted schema, with the root of the mounted schema as the anchor. Section 3.1 of [RFC8528] allows "mount-point" only as a substatement of "container" and "list".¶

3.8. Related constructs that do not use "anydata"

• NETCONF [RFC6241] and NETCONF Monitoring [RFC6022] use "anyxml" for filters, retrieved data and edit content. RFC 8526 replaces these uses with "anydata" for NMDA datastores. This document does not change "anyxml".¶
• YANG Schema Mount [RFC8528] and YANG Library [RFC8525] define no "anydata" nodes.¶
• A YANG structure [RFC8791] is encoded in the same way as an "anydata" node, but its schema is defined by the "structure" statement.¶
• The list pagination extensions to NETCONF augment get-data [RFC8526] with input parameters and add no "anydata" nodes.¶

3.9. Observations

• Most uses carry content that a YANG Library can describe. Only RESTCONF "error-info" and the telemetry message labels leave the schema undefined.¶
• The anchor is not always the root. YANG Patch, its reuse in RFC 8641 and RFC 9144, YANG-Push version 2 and configuration templates encode content relative to a path carried next to the "anydata" node. For notification payloads the anchor is the root "/", and the first-level node is the notification itself.¶
• The applicable validation rules depend on the datastore, and one message can carry content from two datastores (RFC 9144).¶
• Most uses carry fragments: filters, filtered retrievals, edits, differences and templates leave out nodes of the full data tree. A fragment taken from a configuration datastore, such as a YANG-Push subscription to <running> whose filter excludes mandatory leaves, cannot satisfy the constraints that need complete data. The validation rules stay those of the datastore, and the consumer chooses whether to apply complete or candidate validation to a given "anydata" node.¶

4.1. Schema Anchor

When the content is encoded from the top of the data tree, the schema anchor is the root of the schema tree, written "/". Otherwise, the anchor is a container, a list, a notification, or the input or output of an RPC or action.¶

The anchor is represented as a node-instance-identifier ([RFC8341]): an instance-identifier in which key predicates are optional. The validator removes the key predicates and resolves the remaining path to a schema node. Choice and case nodes do not appear in the path, as in any instance-identifier. When the key predicates are present, the validator can also instantiate the ancestors of the content, including their list keys. This allows "must", "when", and leafref expressions in the content that refer to ancestor nodes to be evaluated. When they are absent, the ancestors cannot be instantiated: which list entry the content belongs to is unknown, so a reference that leaves the content through an ancestor cannot be resolved. Such references are treated as references to nodes outside the content (see Section 5). The lookup itself does not need the key predicates.¶

The anchor changes where the first-level nodes are looked up. It does not change the root of the data tree. Absolute paths that appear in the content or in its schema, such as leafref "path" statements, "must" and "when" expressions, and instance-identifier values, are evaluated from the root of the data tree, as defined in Section 6.4.1 of [RFC7950]. In this respect the anchor differs from a schema mount point, under which paths are interpreted with the mount point as the root node (Section 4 of [RFC8528]).¶

Defining documents identify the anchor in one of two ways:¶

Target:

A path carried with the content identifies the instance that the content is, for example the "target" of a YANG Patch edit [RFC8072]. The first-level node of the content is an instance of the schema node identified by the path, and the anchor is the parent of that schema node. A path of "/" is handled as defined by the document that carries it.¶

The "target" of [RFC8072], which [RFC8641] and [RFC9144] reuse, is not an instance-identifier. Its type, "target-resource-offset", is encoded as a data resource identifier of a RESTCONF request URI (Section 3.5.3 of [RFC8040]), for example "/song=Dear%20Rosemary". The validator converts such a path to the JSON encoding of an instance-identifier (Section 6.11 of [RFC7951]), which uses the same rule for module names: each "list=key1,key2" step becomes the list name followed by one key predicate per key, in the order of the list's "key" statement, and each key value is percent-decoded. When the target is relative to the target resource (Section 2.4 of [RFC8072]), the path of the target resource is converted in the same way and prepended.¶

Location:

A path carried with the content identifies the location under which the content is placed, for example the "data-path" of a configuration template [I-D.tt-netmod-yang-config-templates]. The first-level nodes of the content are children of the schema node identified by the path, and the anchor is that schema node.¶

In both cases, the anchor is a property of an instance of the "anydata" node, not of the "anydata" schema node. For example, each edit of a YANG Patch carries its own "target", and therefore the "value" of each edit has its own anchor.¶

At the root anchor, a first-level node is either a top-level data node or a top-level notification. When the validation context names a datastore, the first-level nodes MUST be data nodes. When the content is an event record from an event stream, as in [RFC8639] and [I-D.ietf-netconf-notif-envelope], the first-level node MUST be a notification.¶

4.2. Lookup Procedure

A validator performs the lookup for one instance of an "anydata" node as follows:¶

1. Resolve the anchor in the schema context. If the anchor cannot be resolved, or resolves to a node that cannot have children, the content is not validated (see Section 4.6).¶
2. For each first-level node, determine its module from the encoding, as defined in Section 4.3.¶
3. Find the schema node with that module and identifier among the schema children of the anchor, looking through choice and case nodes and including nodes added by "augment" statements. A schema node is eligible only if the module that defines it is implemented in the schema context (Section 5.6.5 of [RFC7950]), its "if-feature" statements are satisfied, and no deviation in the schema context removes it.¶
4. Look up the descendants of each first-level node with the rules of the encoding, without change. When the lookup reaches an "anydata", "anyxml", or schema mount point node, continue as defined in Section 4.5.¶

4.3. Encoding Rules for the First Level

4.4. Anchor of the Surveyed Uses

For each use of "anydata" listed in Section 3, the anchor is obtained as follows.¶

A subtree filter is a pattern, not instance data (Section 6 of [RFC6241]): its nodes are looked up as defined here, but only node names and the values of content match nodes can be checked. Where the defining document gives no anchor and no schema, as for "error-info" and the telemetry message labels, the content is not validated.¶

Neither [RFC8641] nor [RFC9144] states what the "target" of an edit is relative to; their examples use absolute paths, and this document assumes absolute paths for both. In [RFC9144], "value" and "source-value" of the same edit share the anchor but come from different datastores, so each is validated with its own validation context.¶

A selection filter does not change the anchor. A subtree filter can select several subtrees of a datastore (Section 3.6 of [RFC8641]), and an XPath filter can select any node set, but the selected data is still encoded from the root of the data tree. One root anchor therefore covers all selected subtrees, and the nodes that the filter left out are handled by the option chosen in Section 5. None of the surveyed uses encodes, in one instance of an "anydata" node, first-level nodes that are children of different schema nodes, so a single anchor per instance is sufficient.¶

4.5. Nested "anydata", "anyxml", and Schema Mount Points

anyxml:

The content of an "anydata" node consists of nodes that can be modeled with YANG, except anyxml (Section 7.10 of [RFC7950]). An instance of an "anyxml" node in the content is an error.¶

Nested "anydata":

The content of an "anydata" node inside the content is validated only if the validator has a validation context for that "anydata" node, with its own anchor and datastore. Otherwise, its content is not validated, and the validator reports it as such. For example, the "payload" of a telemetry message [I-D.ietf-nmop-message-broker-telemetry-message] is a YANG-Push notification whose "datastore-contents" is itself an "anydata" node with a different datastore.¶

Schema mount points:

Below a schema mount point [RFC8528], the lookup continues in the mounted schema, which is identified by the schema mount data and the YANG library data of that mount point (Section 3.3 of [RFC8528]). When the content is a fragment, that data is usually not part of the content, so the schema context has to include it. If the mounted schema is not available, the content below the mount point is not validated.¶

Metadata annotations [RFC7952] attached to nodes in the content, such as the "origin" annotation of <operational>, are resolved in the schema context like any other annotation. This document defines no new annotations. The validation context applies to the whole content of one "anydata" instance and is known when the content is produced; it is not a property of individual nodes. The uses surveyed in Section 3 already carries the anchor and the datastore next to the "anydata" node, in the YANG Patch target, the template data-path, or the subscription, so an annotation would duplicate them. An annotation remains possible for a use that carries neither, and this document does not preclude one.¶

4.6. Lookup Outcomes

The lookup of one instance of an "anydata" node ends in one of three outcomes:¶

Found:

Every node in the content has a schema node. Validation continues as defined in Section 5.¶

Invalid:

At least one node in the content has no schema node, or is placed where its schema node is not allowed.¶

Not validated:

The validator lacks the context to perform the lookup, for all of the content or for a subtree of it. This is not evidence that the content is wrong.¶

A validator reports errors with the "error-tag" values of Appendix A of [RFC6241], as listed in Table 3.¶

5.1. The anydata-complete and anydata-candidate Options

Section 8.1 of [RFC7950] separates the properties that are true in all data trees from the properties that are true in a valid data tree. A configuration datastore that is not yet committed, such as <candidate>, satisfies the first set at all times and the second set only when it is validated (Section 8.3.3 of [RFC7950]). The two options follow this split.¶

anydata-candidate:

The validator checks every node of the content against its schema node:¶

• All leaf and leaf-list values match the type of their schema node, including "range", "length", and "pattern" restrictions. The value of a leafref matches the type of the leaf it refers to, but the referenced instance is not required to exist.¶
• All key leafs are present for all list entries.¶
• Nodes are present for at most one case branch of each choice.¶
• No node is present whose "if-feature" expression evaluates to "false" in the schema context.¶
• No "config false" node is present when the datastore is a conventional configuration datastore (Section 5 of [RFC8342]).¶

"must", "when", "unique", "mandatory", "min-elements", and "max-elements" statements are not checked, and leafref and instance-identifier references are not required to resolve. Evaluating "when" can require nodes that are not part of the content, so it is not checked under this option even though Section 8.1 of [RFC7950] lists it among the properties of all data trees.¶

anydata-complete:

The validator performs all checks of anydata-candidate and, in addition, checks every property that Section 8.1 of [RFC7950] requires of a valid data tree: "when", "must", "unique", "mandatory", "min-elements", and "max-elements", and the referential integrity of leafref and instance-identifier values whose "require-instance" is "true".¶

The content is treated as self-contained. Expressions and references are evaluated on a data tree that consists of the ancestors instantiated from the schema anchor (Section 4.1) and the content. A reference to a node that is not in this data tree is not satisfied.¶

The anydata-complete option is intended for content that is complete for its schema anchor, such as the full reply to a get-data operation [RFC8526] on <running> or a YANG instance data file [RFC9195]. Content that is a fragment, such as the output of a subscription filter, a YANG Patch edit, or a configuration template, is expected to fail anydata-complete, and so is content from <operational>, in which semantic constraints may be violated (Section 5.3 of [RFC8342]). Such content is validated with anydata-candidate.¶

A validator can use additional instance data of the datastore, such as a copy of it, to resolve references that leave the content. The content is then validated as part of that data tree. How such data is obtained is outside the scope of this document. Without such data, a reference to a node that is not in the data tree formed by the ancestors of the schema anchor and the content is not satisfied under anydata-complete and is not checked under anydata-candidate.¶

5.2. Validation Procedure

A validator validates one instance of an "anydata" node as follows:¶

1. Perform the schema lookup of Section 4.2. If the lookup ends in "invalid" or "not validated" (Section 4.6), validation ends with the same outcome.¶
2. Instantiate the ancestors of the content from the schema anchor, including the key leafs given in its predicates, and place the content under the anchor.¶
3. Apply the checks of the selected option (Section 5.1).¶
4. For each nested "anydata" node in the content, repeat this procedure with the validation context of that node if one is available. Otherwise, its content is not validated (Section 4.5).¶

A validator MUST support both options and MUST follow this procedure. A validator MUST NOT report content as invalid because context needed for the lookup or for validation is missing.¶

5.3. Outcomes and Error Reporting

Validation of one instance of an "anydata" node ends in one of the outcomes of Section 4.6: valid, invalid, or not validated. A result also names the option that was applied, and lists any subtrees that were not validated.¶

A validator reports errors with the "error-tag" and "error-app-tag" values that [RFC7950] already assigns to each violation, as listed in Table 4. The "error-path" is the path from the root of the data tree, including the ancestors instantiated from the schema anchor.¶

What a consumer does with the outcome is outside the scope of this document. A consumer can, for example, pass valid content on, discard or quarantine invalid content and alert an operator, and pass on content that was not validated while counting it.¶

5.4. Example

A YANG-Push subscription [RFC8641] to <operational> selects the interface statistics of [RFC8343]. The anchor of the "datastore-contents" node is "/", the datastore is <operational>, and the consumer chooses anydata-candidate. A network node with a software defect sends the following update:¶

        <notification
            xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
          <eventTime>2026-10-09T10:00:00Z</eventTime>
          <push-update xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
            <id>1011</id>
            <datastore-contents>
              <interfaces
                  xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
                <interface>
                  <name>eth0</name>
                  <statistics>
                    <in-octets>-4271233</in-octets>
                  </statistics>
                </interface>
              </interfaces>
            </datastore-contents>
          </push-update>
        </notification>

The lookup finds a schema node for every element. Step 3 checks the value of "in-octets" against its type, "yang:counter64", whose range is 0 to 18446744073709551615. The value is outside that range, so the outcome is invalid, with error-tag "invalid-value" and error-path "/if:interfaces/if:interface[if:name='eth0']/if:statistics/if:in-octets". Because the update is a fragment, anydata-complete would also report the missing mandatory "type" leaf with error-tag "missing-element", even though the content is a correct part of <operational>.¶