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]
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





_______________________________________________
netmod mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to