Hi, I appreciate the problem that this draft is trying to solve, and I fully support solving it (because validating data is important), but I'm concerned that it presented this is very coarse as a solution. I.e., for validation to work, it seems to make various constraints on all instances of anydata that appear in the YANG tree.
The draft mentioned two instances where anydata was used in IETF YANG modules, but from a quick search I found around 10-15 instances, mostly in protocols that are returning YANG data. Hence, I think that additional context information needs to be provided at the point that the validation is being performed: 1. What datastore the validation is being performed against (since in RFC 8525, it is the datastore that defines the schema that is being used). 2. Optionally the schema path of which anydata instances in the YANG schema the validation is being performed against (in case there is more than one anydata is the schema). E.g., I want to validate the anydata data node in the YANG Push message. 3. Optionally a relative schema path at which to validate the anydata instance data against. E.g., in a YANG Push on-change notifications, and for YANG Push v2 we are considering allowing the anydata to encode the data relative the target path (i.e., in the same way that it would be returned for a RESTCONF GET request rather than a subscription), and hence the schema validation would need to be performed relative to that instance-data path rather than from the root of the schema tree. 4. You might want some options to turn off some/all of the referential constraint checking (e.g., checking that leafrefs, must, when statements are all valid) Perhaps a YANG model could be defined as a schema for a JSON file to provide this extra information to the validation tool? Finally, given that, AIUI, this draft is really about how to amend the behaviour of tooling, I wonder whether it wouldn't be better as an Informational Draft rather than Standards Track. I presume that we are not trying to constrain how anydata nodes are used in YANG modules here. BTW, from a process POV, it looks like this document is named as if has been adopted, but I'm not sure whether a formal adoption call has happened in NETMOD or NMOP, but I think that is just a minor process issue that might need sorting out, and I may have missed it. Kind regards, Rob From: [email protected] <[email protected]> Date: Tuesday, 2 December 2025 at 14:34 To: [email protected] <[email protected]> Cc: [email protected] <[email protected]> Subject: [netmod] I-D Action: draft-ietf-netmod-yang-anydata-validation-00.txt Internet-Draft draft-ietf-netmod-yang-anydata-validation-00.txt is now available. It is a work item of the Network Modeling (NETMOD) WG of the IETF. Title: Validating anydata in YANG Library context Authors: Ahmed Elhassany Thomas Graf Name: draft-ietf-netmod-yang-anydata-validation-00.txt Pages: 8 Dates: 2025-11-30 Abstract: This document describes a method to use YANG RFC 8525 and standard YANG validation rules in RFC 7950 to validate YANG data nodes that are children of an "anydata" data node. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-anydata-validation/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-netmod-yang-anydata-validation-00.html Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
