On Tue, Dec 16, 2025 at 9:22 AM Rob Wilton (rwilton) <rwilton= [email protected]> wrote:
> 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. > > I did not really see anything to implement in this draft. The 'anydata' node type is often used in RPC input parameters to represent a 'config' or 'data' root. It is used in config for templates. In all cases the type of child nodes expected are documented in ad-hoc text. Completely free-form anydata is not really used. All anydata must contain known namespaces, or the XML parser will reject the message. The NETCONF protocol covers that constraint. The issue is determining which container to use to replace the 'anydata' root. We use proprietary annotations (XML attributes) in the anydata start tag to identify the replacement node to use. It can be the root or a node in the schema tree. It would be nice if there were standard annotations for this purpose. 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 > > Andy > > > *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] >
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
