For structure (and rc:yang-data), my validation scripts hack the YANG module to convert the "structure" to a "container" and then do the validation against the hacked-YANG module.
Kent > On Jun 6, 2022, at 6:50 AM, Scott Mansfield > <[email protected]> wrote: > > Thank you Michal for the information. I appreciate the work on yanglint and > look forward to future updates. > > Then my question is, what tool was used to validate the examples in RFC 9195? > Is there any tooling that can be used to validate the instance data? > > thanks, > -scott. > > > From: Michal Vasko > Sent: Monday, June 6, 2022 1:59 AM > To: Scott Mansfield; Kent Watsen > Cc: [email protected] <mailto:[email protected]> > Subject: Re: [netmod] Question about tooling for YANG Instance Data > > Hi Scott, > the main developer of libyang commenting. In your example there is a > "structure" extension instance, which we do not support currently so you will > not be able to validate it no matter what you do. I have already looked at > this extension recently and think that we can support it without much trouble > but I am currently swamped by lots of other issues so I have no idea when I > will get to this. > Regards, > Michal > On 5. 6. 2022 1:35, Scott Mansfield wrote: >> Excellent ideas. I will package up a tiny example and post to libyang. >> >> I am using yanglint 2.0.200. >> >> Since I’m starting from an example that is in RFC 9195, it is easy to build >> a small example and package up an expect script to show the issue. >> >> Regards, >> -scott. >> >> From: Kent Watsen <[email protected]> <mailto:[email protected]> >> Sent: Saturday, June 4, 2022 5:22 PM >> To: Scott Mansfield <[email protected]> >> <mailto:[email protected]> >> Cc: [email protected] <mailto:[email protected]> >> Subject: Re: [netmod] Question about tooling for YANG Instance Data >> >> Hi Scott, >> >> I consider myself a heavy `yanglint` user, as all examples in all my drafts >> are validated each time I "make" each draft, and I have several other >> projects that make heavy use of `yanglint` validation. I have run into a >> number of validation issues over years and generally first try to validate >> that my understanding of YANG is correct and, if unsure, I'll ping the >> NETMOD list (note: there are many YANG subtleties, such as the recent >> discovery that a module needs to be "implemented" in order for its features >> to be defined). Otherwise, I submit an Issue to the `libyang` GitHub issue >> tracker, typically containing the smallest possible module (or number of >> modules) demonstrating the issue, while also pointing out all relevant facts >> (e.g., foo is implemented, bar is defined, RFC 7950 Section X says this, >> etc.). Radek and Michal are pretty good with providing a response in 1-2 >> business days. Sometimes my YANG-understanding is challenged, at which >> point we bring it to the NETMOD list. >> >> FWIW, `yanglint` recently switched from the 1.x to the 2.x code base. A >> number of regressions were introduced at this time (resolved now, at least >> the ones affecting me) but, nicely, the 2.x code catches some issues that >> the 1.x code never did (it's a better validator). The CLI changed some, and >> I'm now very careful to ensure all modules that need to be implemented are, >> and that all features that need to be defined are. I now explicitly disable >> all features for implemented modules when no features from it are needed. >> I find that the new 2.x is picky, in a good way and that, after >> painstakingly working through each issue, all my validation tests are >> passing now. >> >> Best of luck, >> Kent >> >> >> >> On Jun 3, 2022, at 3:35 PM, Scott Mansfield >> <[email protected] >> <mailto:[email protected]>> wrote: >> >> I am trying to use two of the examples found in RFC 9195 >> https://www.rfc-editor.org/rfc/rfc9195.html#name-preloading-default-configur >> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-092ccfe7a6702a7c&q=1&e=4e9d6ab0-63b7-4e40-965d-5d89b0208d6e&u=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9195.html%23name-preloading-default-configur> >> and >> https://www.rfc-editor.org/rfc/rfc9195.html#name-storing-diagnostics-data >> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-4510ebc746564af0&q=1&e=4e9d6ab0-63b7-4e40-965d-5d89b0208d6e&u=https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9195.html%23name-storing-diagnostics-data> >> to test out how to validate that instance data is formatted correctly. >> >> Using yanglint, I load all the yang necessary and then load the data from >> either the xml file (read-only-acm-rules) or the json file >> (acme-router-netconf-diagnostics). I get a similar error for both... >> data -t data -f xml acme-router-netconf-diagnostics.json >> libyang[0]: Node "instance-data-set" not found in the >> "ietf-yang-instance-data" module. (path: Line number 2.) >> YANGLINT[E]: Failed to parse input data file >> "acme-router-netconf-diagnostics.json". >> >> What is the best tooling to use to validate the instance data? What tooling >> was used to validate the contents used in the examples? I'm trying to >> determine if this a yanglint issue, user error, or I'm just using the wrong >> tool. >> >> Here is a link to a github with my testing: >> https://github.com/samans/testing-yang/tree/main/ieee-60802/60802 >> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-20ec105f5d2f3377&q=1&e=4e9d6ab0-63b7-4e40-965d-5d89b0208d6e&u=https%3A%2F%2Fgithub.com%2Fsamans%2Ftesting-yang%2Ftree%2Fmain%2Fieee-60802%2F60802> >> If interested t.in in the expect script for the >> acme-router-netconf-diagnostics.json example and x.in is the expect script >> for the read-only-acm-rules.xml example. >> >> regards, >> -scott. >> >> _______________________________________________ >> netmod mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/netmod >> <https://www.ietf.org/mailman/listinfo/netmod> >> >> >> >> _______________________________________________ >> netmod mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/netmod >> <https://www.ietf.org/mailman/listinfo/netmod> > _______________________________________________ > netmod mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/netmod > <https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
