Hello Rob, WG, Thank you Rob for the valuable feedback. Let me try to break out your points and address them one by one (to the best of my understanding)
1. Anydata not always encoded from the schema root You've identified an important limitation: the current draft only works when anydata leaves are encoded from the root of the schema. We agree this needs to be addressed as well and will update the document accordingly. The proposed solution is to parameterize validation with two additional inputs: a. An absolute-schema-nodeid (RFC 7950 §6.5) identifying the anydata node being validated. b. A schema anchor: one or more absolute-schema-nodeid values identifying the schema location(s) against which the contents of the anydata node are validated. Multiple anchors are permitted to cover cases where an anydata payload spans more than one subtree (e.g., YANG Push filter XPath is a union of multiple subtrees). When omitted, the anchor defaults to the schema root, preserving today's behavior. We expect the burden on the users to be low: the anchor can typically be derived from context the user already has — the YANG Push subscription, the target of a YANG Patch edit (RFC 8072), or the request that produced an RFC 9144 reply. We acknowledge that for YANG Patch, the target is a data resource identifier (with list keys) rather than a schema-node identifier, so the next revision will specify the transformation explicitly rather than rely on "derivation" as a hand-wave. 2. Validation against arbitrary datastores Agreed. NMDA already defines the per-datastore schema mechanics, and we will make the target datastore an explicit input to the validation. The next revision will: a. Reference RFC 8342 for validation against selected datastore. b. Review factory-default (RFC 8808) and the system datastore (draft-ietf-netmod-system-config) for any additional constraints, and reference them as needed. 3. Instance data and leafref validation The current draft already distinguishes two modes via the anydata-candidate and anydata-complete flags, mirroring the validation rules in RFC 7950 §8.3.3: a. anydata-complete: the anydata payload is treated as a self-contained subtree that includes all nodes referenced by leafrefs; validation is fully resolvable from the payload alone. b. anydata-candidate: the payload is treated as candidate configuration, in which leafrefs are not validated to be resolvable. 4. Standalone document vs. a few paragraphs elsewhere We believe a standalone document is justified. Section 3 surveys several use cases that need this validation behavior, and the validation API is intended to be referenceable from multiple specifications — YANG Push, YANG Patch, and RFC 9144 among them. Embedding it inside any one of those would create awkward cross-references and risk divergence over time. A standalone Standards Track document gives the WG a single, stable reference. Best, -Ahmed and Thomas From: Rob Wilton (rwilton) <[email protected]> Date: Tuesday, 7 April 2026 at 18:04 To: Kent Watsen <[email protected]>, [email protected] <[email protected]> Subject: [netmod] Re: adoption call for draft-ietf-netmod-yang-anydata-validation (post factum) Be aware: This is an external email. Hi Ahmed, Kent, Thomas, WG, Sorry, but I don't know whether the WG should adopt this document yet. As per my previous email, my main problem is that I either don't understand how the solution works, or otherwise I believe that it is incomplete and I would like to understand what the precise scope/goal of this document is and to know that there is an outline of a viable technical solution. Alternatively, if this document is only intended to cover the anydata cases where anydata leaves are encoded from the root of the schema, then it becomes somewhat tautological in its meaning and intent. In this case then I think that the document should only be informational, and we might want to think whether we really need to publish it at all. E.g., could it just be a couple of paragraphs in another document? The crux of my issue is that I believe that this document assumes that YANG anydata nodes are always encoded from the root of the schema, but this isn't a requirement from RFC 7950 section 7.10. The encoding is just from the point of the node that is being returned (and that node must be correctly namespaced), but you don't need to include all the parent elements going back to the root of a data tree. I.e., in the general case you cannot assume that you can just validate an anydata node against the root of the schema. YANG Patch (RFC 8072) is perhaps a good example that uses anydata nodes in this relative-path way: My understanding of a YANG patch operation for an edit request, is that the "target" leaf gives the path to the data node that is being edited, and the value (which is any data) is encoded relative to that path rather than the root of the tree. Hence any tool that is trying to validate the anydata part of a yang-patch operation against the schema needs to know that the anydata is encoded relative to the target path, otherwise it will mistakenly fail. Hence a full solution here needs a generic way of specifying this additional path into the schema where the anydata needs to be validated against. Certainly, I don't think that we want to be trying to constrain the use of anydata in the YANG language to only encode data from the root of the schema tree! Another example would be RFC 9144, here, if the examples are correct, then the output is encoded relative to the input RPC xpath-filter. I.e., there isn't enough information in the RPC reply to validate the anydata node, you need to know the additional relative path context from the RPC input. Finally, the proposed encoding for Yang Push v2 is another example where the anydata isn't directly encoded from the root of the tree, but instead it is relative to the path specified in "target-prefix" concatenated with "updates/target-path". I.e., like how push-change-updates are encoded in RFC 8641. Separately, in terms of validation, I think that this should take an arbitrary datastore to validate against, and maybe even the ability to pass in some instance data for that datastore that is being validated against (e.g., if the goal is to validate leaf refs, etc). In the case of validating against operational, I think that this document should reference section 5.3 of RFC 8342. We should also check whether there are any other constraints, e.g., for factory-default or the system datastore that have been more recently specified in drafts/RFCs. Kind regards, Rob From: Kent Watsen <[email protected]> Date: Tuesday, 7 April 2026 at 02:41 To: [email protected] <[email protected]> Subject: [netmod] adoption call for draft-ietf-netmod-yang-anydata-validation (post factum) [This is a strange adoption call, as already the document was approved as a WG document, Nonetheless, it is a good thing to do an adoption call] This email begins a two-week *adoption* on: Validating anydata in YANG Library context https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-anydata-validation//00/ Yes, it is strange that the document title starts with "draft-ietf-". Please do not allow that designation to influence your adoption call reviews. No IPR was declared for this document: https://mailarchive.ietf.org/arch/msg/netmod/N-p2jnzvDmog8SU29riWTCzUaHE/ Please take time to review this draft and post comments by Apr 20. Both favorable comments and objections are welcomed. Kent (and Lou)
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
