]> Swisscom

Binzring 17 Zurich 8045 Switzerland ahmed.elhassany@swisscom.com

Swisscom

Binzring 17 Zurich 8045 Switzerland thomas.graf@swisscom.com

General NETMOD The YANG "anydata" statement carries data whose data model is not known when the module is designed. This document defines the context that is needed to validate such content: the schema context, the "anydata" node, a schema anchor, and the datastore. It describes how this context is obtained for the uses of "anydata" in IETF YANG modules, how the schema node of each node in the content is found, and which YANG constraints are checked.

Introduction defines the "anydata" statement to represent an unknown set of nodes that can be modeled with YANG, but whose data model is not known at module design time. The same section notes that the data model for anydata content can become known through protocol signaling or other means and leaves those means out of scope nor requires them. Many IETF YANG modules use "anydata" (see ), including , , , , , , and . In most of these uses, the content is not arbitrary: the defining document states in prose that it is YANG instance data from a YANG datastore, instantiated from the same modules the producer implements. When a server receives such content as input, for example the value of a YANG Patch edit, it validates the content against its own schema and datastore as part of processing the operation. When anydata content is produced as output, however, for example in YANG-Push notifications or the reply to a datastore comparison, no such step exists on the receiving side. Current YANG implementations accept any well-formed, namespace-qualified content there and do not validate it against any YANG schema: not data types or ranges, and not "mandatory", "min-elements", "must", or "when" constraints. Even input is not always validated: YANG configuration templates store reusable configuration as anydata content in <running>, and because that content is opaque to the server, it cannot be validated when the template is defined, only once the template is expanded. That gap has become significant because anydata output is no longer consumed only by the client that requested it. For instance, network operators collect YANG-Push notifications from thousands of network nodes and forward them through message brokers into analytics pipelines . The components that consume this data are decoupled from the producer, have no protocol session through which to learn its schema, and process the data long after it was sent. For example, the "in-octets" counter of is of type "yang:counter64". If a network node with a software defect sends a YANG-Push update with a negative value for this counter, a consumer that validates the anydata content against the producer's schema rejects the value as a type violation. A consumer that cannot validate accepts it, and an analytics component that sums interface counters across the network computes a wrong traffic volume, which can lead to inaccurate billing or capacity planning. Such errors are costly to trace back to their source once the data has left the collection layer. Validating anydata content requires four pieces of context, none of which can be derived from the content alone:

1. The schema context: the set of YANG modules, revisions, features, and deviations from which the content was instantiated. A YANG Library instance is one way to describe it, but a validator can obtain the schema context by other means that are outside the scope of this document.
2. The anydata node: the schema node whose content is validated. A message can contain more than one anydata node, and each can carry differently scoped content.
3. The schema anchor: the schema node at which the content is rooted. Anydata content is not always encoded from the top of the schema tree. The value of a YANG Patch edit is encoded relative to the edit's target, and YANG-Push on-change updates and datastore comparison results both carry their data as YANG Patch edits. Configuration template content can likewise start at any level of the schema tree. A validator that assumes the top of the schema tree wrongly rejects such content.
4. The datastore from which the content was taken. It determines which schema applies and which nodes may appear: the conventional configuration datastores contain only "config true" nodes, while <operational> also contains "config false" nodes (). It also determines which constraints hold: constraints that hold in <running> or <intended> do not necessarily hold in <operational> (). Anydata content, however, is often a fragment of that datastore rather than a complete copy of it, because a subscription filter, a YANG Patch edit, or a configuration template selects only part of the data tree. The consumer therefore chooses between two options, which follow the split in . Under anydata-complete, the content, rooted at the schema anchor, is treated as a complete data tree, and all constraints are enforced. Under anydata-candidate, the content is treated like configuration in a candidate datastore that has not yet been committed: every node is still checked against its schema node, including data types, ranges, patterns, list keys, and choices, but none of the constraints that only a valid data tree satisfies ("must", "when", "unique", "mandatory", "min-elements", "max-elements", and references to other nodes) is enforced. The name refers to this uncommitted state; it does not mean validation against the <candidate> datastore. For example, content from a YANG-Push subscription to <running> whose filter excludes mandatory leaves fails anydata-complete by construction, but it can be validated with anydata-candidate.

Existing mechanisms do not provide this context. YANG Schema Mount mounts complete data models at a fixed point of the schema tree and cannot describe an arbitrary subset of an instantiated data tree, such as one selected by a YANG-Push subscription filter. YANG Full Embed complements Schema Mount at module design time but has the same limitation. A design-time substatement of "anydata" could declare that the content of a node is expected to be valid YANG instance data, but it cannot carry the schema anchor or the datastore, because both are often known only at run time, for example when a YANG-Push subscription is established. This document therefore defines the validation context of an anydata node: the four inputs listed above, how each one is obtained for the uses of "anydata" surveyed in , how the schema node of each node in the content is found, and which constraints are checked under each option. Today, each implementation that validates anydata content defines its own way to receive this context. Other specifications that use "anydata" can state how their content is validated by referencing this document. How the validation context is conveyed to a validator is outside the scope of this document. This document does not change the "anydata" statement, does not constrain how YANG modules use "anydata", and does not require any existing client or server to perform validation. Validation remains optional and is a decision of the consumer. A consumer that detects non-conforming content can, for example, discard the message, log it for further analysis, or alert an operator, instead of passing incorrect data on to the systems that depend on it.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses the terms data node, data tree, instance identifier, schema node, and schema tree as defined in ; datastore, datastore schema, conventional configuration datastore, operational state datastore (<operational>), client, server, and notification as defined in ; and event record, event stream, publisher, and receiver as defined in . The following terms are defined in this document:

content:

The value of one instance of an "anydata" node, that is, the data nodes encoded as its children, with their descendants ("anydata content" in ).

first-level node:

A node of the content that is a direct child of the "anydata" node in the encoded message.

fragment:

Content that is part of a data tree but leaves out nodes of that data tree, for example, because a selection filter, an edit, or a configuration template selects only part of it.

schema context:

The set of YANG modules, with their revisions, supported features, and deviations, and whether each module is implemented or import-only, from which the content was instantiated. For content taken from a datastore, it is the set of modules that defines the datastore schema of that datastore. The content-schema of a YANG instance data set () is a schema context.

schema anchor:

The schema node whose children are the first-level nodes of the content (). It is the root of the schema tree, written "/", when the content is encoded from the top of the data tree.

validation context:

The inputs needed to validate one instance of an "anydata" node: the schema context, the "anydata" node, the schema anchor, and the datastore.

producer:

The entity that encodes the content, for example a server or a publisher.

consumer:

An entity that receives the content, for example a client or a receiver, and decides whether it is validated, and with which option.

validator:

An implementation that validates content as defined in this document.

anydata-complete, anydata-candidate:

The two validation options defined in .

Survey of existing use of "anydata" This section lists the "anydata" nodes defined in published IETF YANG modules and in active Internet-Drafts at the time of writing. For each use it records four facts that a validator needs and that the defining document either states or leaves open:

Schema context:

where the set of YANG modules that describe the content comes from.

Anchor:

the schema node that the top-level nodes of the content are children of. The anchor is the datastore root only for some uses; others encode content relative to a path carried next to the "anydata" node.

Datastore:

the datastore whose schema and validation rules apply, if any.

Fragment:

whether the content can be a part of a data tree, for example because a selection filter or an edit leaves out nodes, including mandatory ones, that the full data tree contains. "may" means the content is a fragment when a filter is applied or when the defining document allows partial data.

lists the anchor, the datastore and whether the content is a fragment for each use. The subsections that follow group the uses by purpose and describe their schema context. "anydata" nodes in IETF YANG modules

Document	"anydata" node	Anchor	Datastore	Fragment
RFC 8526	get-data input subtree-filter	root	"datastore" input leaf	yes
RFC 8526	get-data output data	root	"datastore" input leaf	may
RFC 8526	edit-data input config	root	"datastore" input leaf (configuration datastore)	yes
RFC 8072	yang-patch edit value	content relative to edit "target"	datastore of the PATCH target resource	yes
RFC 9144	compare input subtree-filter	root	"source" and "target" input leaves	yes
RFC 9144	compare output edit value and source-value	content relative to edit "target"	"target" and "source" datastores respectively	yes
RFC 8639	stream-subtree-filter	"/" (first-level node is a notification)	none (event stream)	yes
RFC 8641	datastore-subtree-filter	root	subscription's target datastore	yes
RFC 8641	push-update datastore-contents	root	subscription's target datastore	may
RFC 8641	push-change-update yang-patch edit value	content relative to edit "target"	subscription's target datastore	yes
RFC 9195	content-data	root	not specified	may
RFC 9195	inline-yang-library	root	none (fixed schema: ietf-yang-library)	no
RFC 8040	errors error error-info	not specified	none	unknown
RFC 8532	test point root (schema mount point)	root of the mounted schema	as for the parent data tree	no
YANG Templates	template content	"data-path" leaf (any level)	<running>, or <system>	yes
Notif. Envelope	envelope contents	"/" (first-level node is a notification)	none (event stream)	no
YANG-Push 2	filter subtree	root	subscription's target datastore	yes
YANG-Push 2	update merge and replaced-by	content relative to "path-prefix" plus "target-path"	subscription's target datastore	yes
Telemetry Message	message payload	"/" (first-level node is a YANG-Push notification)	none; nested "datastore-contents" uses the subscription's target datastore	may
Telemetry Message	label anydata-values	not specified	none	unknown
Telemetry Message	subscription subtree-filter	"/" (first-level node is a data node or a notification)	as for the subscription	yes

Selection filters Subtree filters () are carried in "anydata" by , , and , where they select a subtree of a datastore, and by , 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.

Retrieved datastore content The "data" output of get-data and the "datastore-contents" of push-update 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 , and it need not satisfy constraints that apply only to configuration datastores ().

Edits and differences The edit-data operation carries configuration anchored at the datastore root, together with operation metadata, and the server validates the result. YANG Patch 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 (). 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 to report on-change updates of the subscription's target datastore, and by the compare operation 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 carries "merge" and "replaced-by" content relative to the path formed by a common "path-prefix" and a per-update "target-path".

Stored instance data and templates YANG Instance Data 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 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.

Message payloads The notification envelope carries the content of a notification in the "contents" node of a YANG structure . 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 carries the message received from a network element in the "payload" node. The payload is a YANG-Push notification , 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.

Content without a defined schema RESTCONF 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.

Schema mount on an "anydata" node The connectionless OAM model defines an "anydata" node named "root" with the "mount-point" extension of , 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 (). The content is validated against that mounted schema, with the root of the mounted schema as the anchor. allows "mount-point" only as a substatement of "container" and "list".

Related constructs that do not use "anydata"

• NETCONF and NETCONF Monitoring 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 and YANG Library define no "anydata" nodes.
• A YANG structure 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 with input parameters and add no "anydata" nodes.

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.

Instantiated data node schema lookup To validate "anydata" content, a validator first has to find, for each instantiated data node in the content, the schema node it is an instance of. This section defines that lookup. It uses the four inputs of the validation context: the schema context, the "anydata" node, the schema anchor, and the datastore. Below the first level of the content, no new rule is needed. Each encoding already identifies a child node relative to its parent (, , ). What the encodings do not define is the parent of the first-level nodes. This document uses the schema anchor as that parent.

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 (): 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 ). 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 . In this respect the anchor differs from a schema mount point, under which paths are interpreted with the mount point as the root node (). 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 . 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 , which and reuse, is not an instance-identifier. Its type, "target-resource-offset", is encoded as a data resource identifier of a RESTCONF request URI (), for example "/song=Dear%20Rosemary". The validator converts such a path to the JSON encoding of an instance-identifier (), 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 (), 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 . 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 and , the first-level node MUST be a notification.

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 ).
2. For each first-level node, determine its module from the encoding, as defined in .
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 (), 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 .

Encoding Rules for the First Level

XML The XML encoding needs no additional rule. The value of an "anydata" node is a set of nodes encoded as subelements of the "anydata" element (), and the namespace of each subelement is the XML namespace of the module that defines the node. The namespace of every element is resolved by the XML namespace rules, including declarations inherited from ancestor elements. A first-level element without its own namespace declaration therefore inherits the default namespace in scope at the "anydata" element, which is usually the namespace of the module that defines the "anydata" node. The namespace declarations in scope at the "anydata" element also apply to prefixes used in values of the content, such as identityref and instance-identifier values (, ). A validator that extracts the content from the message MUST preserve these declarations.

JSON A member name is either namespace-qualified or simple, and a simple name belongs to the module of its parent node (). The content of an "anydata" node follows the same rules (). For the first-level members, the anchor takes the role of the parent node. This matches the YANG Patch examples, where an edit whose target is a list entry of the target resource carries the list with a simple member name (), and an edit whose target is in the datastore carries a namespace-qualified name (). Therefore:

• A first-level member name MUST be namespace-qualified when the anchor is the root or when the module of the node differs from the module of the anchor. Otherwise, the simple form is used.
• A validator resolves a simple first-level member name in the module of the anchor. A simple first-level member name at the root anchor is an error.
• A validator SHOULD also accept a namespace-qualified first-level member name whose module is the module of the anchor, because a producer may have qualified it relative to the "anydata" node.

CBOR When the content of an "anydata" node () uses names as map keys, the rules for JSON above apply, as uses the same qualification rule as JSON. When the content uses YANG Schema Item iDentifiers (SIDs) as map keys, the reference SID of the first-level map is determined by : it is the SID of the "anydata" node, or zero if the "anydata" node is encoded with a name as its key. A first-level key can also be an absolute SID (tag 47). Because a SID identifies a schema node independently of its position, the anchor is not needed to identify the node. The validator MUST check that the identified schema node is a child of the anchor. When SIDs are used, the schema context includes the SID assignments of its modules.

Anchor of the Surveyed Uses For each use of "anydata" listed in , the anchor is obtained as follows. Anchor of the surveyed "anydata" uses

Use	Anchor	Way
get-data output "data" and edit-data input "config" ; "content-data" ; push-update "datastore-contents"	"/"	fixed
YANG Patch edit "value"	the edit's "target", relative to the target resource unless the target resource is the datastore ()	Target
push-change-update edit "value"	the edit's "target"	Target
compare output edit "value" and "source-value"	the edit's "target"	Target
update "merge" and "replaced-by"	"path-prefix" followed by "target-path"	Target
template "content"	"data-path"	Location
envelope "contents" ; telemetry message "payload"	"/" (a notification)	fixed
subtree filters: get-data , compare , "datastore-subtree-filter" , filter "subtree" , subscription "subtree-filter"	"/"	fixed
"stream-subtree-filter"	"/" (a notification)	fixed
"inline-yang-library"	"/", with ietf-yang-library revision 2019-01-04 as the schema context	fixed
test point "root"	root of the mounted schema; the schema context is the mounted YANG library data ()	fixed
"error-info" ; label "anydata-values"	not defined	none

A subtree filter is a pattern, not instance data (): 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 nor states what the "target" of an edit is relative to; their examples use absolute paths, and this document assumes absolute paths for both. In , "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 (), 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 . 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.

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 (). 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 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 , the lookup continues in the mounted schema, which is identified by the schema mount data and the YANG library data of that mount point (). 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 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 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.

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 .

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 , as listed in . Lookup failures

Case	Outcome	error-tag
The namespace or module name of a node is not in the schema context	invalid	unknown-namespace
The module is in the schema context but not implemented, or the node is removed by a feature or deviation	invalid	unknown-element
The schema node exists, but not as a child of the anchor or of the parent node	invalid	unknown-element
A JSON or CBOR member name is not a valid name, or is simple at the root anchor	invalid	bad-element
An instance of an "anyxml" node	invalid	bad-element
The anchor cannot be resolved	not validated	none
Nested "anydata" without a validation context, or a mounted schema that is not available	not validated (subtree)	none

Validating "anydata" Content This section defines how a validator checks "anydata" content once the schema lookup of has found a schema node for every node in it. It does not define new constraints. It selects which of the constraints of are checked, using two options: anydata-complete and anydata-candidate. The consumer chooses the option for each instance of an "anydata" node; this document does not define a default.

The anydata-complete and anydata-candidate Options 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 (). 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 ().

"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 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 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 () 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 on <running> or a YANG instance data file . 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 (). 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.

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

1. Perform the schema lookup of . If the lookup ends in "invalid" or "not validated" (), 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 ().
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 ().

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.

Outcomes and Error Reporting Validation of one instance of an "anydata" node ends in one of the outcomes of : 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 already assigns to each violation, as listed in . The "error-path" is the path from the root of the data tree, including the ancestors instantiated from the schema anchor. Validation errors

Violation	error-tag	error-app-tag	Option
Value does not match its type ()	invalid-value	from the restriction, if any	both
Missing key leaf ()	missing-element		both
More than one case branch ()	bad-element		both
Node with a false "if-feature" (), or "config false" in a conventional configuration datastore	unknown-element		both
Node with a false "when" ()	unknown-element		complete
"unique" ()	operation-failed	data-not-unique	complete
"max-elements" ()	operation-failed	too-many-elements	complete
"min-elements" ()	operation-failed	too-few-elements	complete
"must" ()	operation-failed	must-violation, unless the statement has its own	complete
Leafref or instance-identifier without instance ()	data-missing	instance-required	complete
Mandatory choice ()	data-missing	missing-choice	complete
Mandatory leaf	missing-element		complete

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.

Example A YANG-Push subscription to <operational> selects the interface statistics of . 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: 2026-10-09T10:00:00Z 1011 eth0 -4271233 ]]> 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>.

Note to the RFC-Editor: Please remove this section before publishing. anydata-candidate validation is implemented for libyang and available at

IANA Considerations This memo includes no request to IANA.

Security Considerations TBD

References Normative References Informative References

Acknowledgements The authors would like to thank Jean Quilbeuf, Benoit Claise, and Alex Huang Feng for their review and valuable comments.