Inline. Thanks, W. > On 7 Mar 2017, at 09:49, Radek Krejčí <rkre...@cesnet.cz> wrote: > > Hi, > I think that the default approach should be to expect that, until explicitly > stated, the imported module is just imported, not implemented. But it is fine > to me to add an option to force the implemented flag on all the modules. > Benoit can then use the flag in his scripts. > > However, I checked RFC 7950 again, and I would like to have a feedback from > the NETMOD group to the section 7.1.5, that states that > "the importing module may: > ... > o use any node in the imported module's schema tree in "must", > "path", and "when" statements, or as the target node in "augment" > and "deviation" statements.”
So this was the situation in the original message, right? This warning was being output: * warn: Schema node "ietf-ip:ipv4" not found (/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name = current()]/ietf-ip:ipv4) …not because "ietf-ip:ipv4” doesn’t exist, but because the ietf-ip module was imported rather than implemented. I think you are saying that (per RFC 7950 section 7.1.5) “ietf-ip:ipv4” should have been found, in which case there wouldn’t have been a warning. Is that correct? > I'm interested in "must" and "when". I'm not sure why it is mentioned here, > because, in contrast to "path", "augment" and "deviation", > "when" and "must" contain XPath expression, so actually even not defined > schema node can be used in it (and this is the reason why yanglint does not > complain with error, but just with warning). Of course, the result is then > always false (ok, depending on the rest of the expression, but it simply does > not depend on the data presence). And this is the reason to have it at least > as warning, because it is usually not the original intention of the author. > > Regards, > Radek > > Dne 7.3.2017 v 10:00 William Lupton napsal(a): >> Could this be the default in the first of these two cases? >> >> Usage: >> yanglint [options] [-f { yang | yin | tree }] <file>... >> Validates the YANG module in <file>, and all its dependencies. >> >> yanglint [options] [-f { xml | json }] <schema>... <file>... >> Validates the YANG modeled data in <file> according to the <schema>. >> >>> On 6 Mar 2017, at 16:59, Robert Wilton <rwil...@cisco.com >>> <mailto:rwil...@cisco.com>> wrote: >>> >>> Hi William, >>> >>> I think that what yanglint is doing here is sane, i.e. I think that its >>> interpretation/split between imported vs implemented modules is supported >>> by the YANG RFC. >>> >>> However, for validation purposes it seems that it would be useful if >>> yanglint had an option to assume that all imported modules are implicitly >>> implemented without requiring them to be explicitly specified. >>> >>> Thanks, >>> Rob >>> >>> On 06/03/2017 16:44, William Lupton wrote: >>>> All, >>>> >>>> This message arose from a yang-multic...@ietf.org >>>> <mailto:yang-multic...@ietf.org> “draft-ietf-pim-igmp-mld-yang-02.txt: >>>> YANG compilation isuse” (sic) thread >>>> <https://www.ietf.org/mail-archive/web/yang-multicast/current/threads.html#00232> >>>> initiated by Benoit. >>>> >>>> I thought it would be useful for NETMOD to see the part of the discussion >>>> that relates to implemented versus imported YANG modules. >>>> >>>> 1. Benoit Claise reported this warning: >>>> * warn: Schema node "ietf-ip:ipv4" not found >>>> (/ietf-interfaces:interfaces/ietf-interfaces:interface[ietf-interfaces:name >>>> = current()]/ietf-ip:ipv4) >>>> 2. Radek Krejčí replied: >>>> * These warnings are printed because in yanglint, until explicitly >>>> stated, the imported modules (such as ietf-interfaces and ietf-ip), are >>>> supposed to be only imported, not implemented. The data nodes in imported >>>> schemas are not available, which is the reason of these warnings. >>>> 3. William Lupton (that’s me!) asked / commented: >>>> * Why are the complaints only about ip:ipv4 (etc) and not about >>>> if:interfaces (etc), which are also referenced in the must statements? >>>> * This makes it hard for an automated tool (such as Benoit’s) because >>>> it needs to know which other YANG files to process in addition to the >>>> “file of interest”. >>>> 4. Radek Krejčí replied: >>>> * According to RFC 7950, sec 5.6.6 (3rd paragraph) [ED: 5.6.5?], when >>>> an implemented module augments another module (ietf-interfaces), the >>>> augmented module MUST be also implemented. So libyang automatically >>>> changes the augmented module from imported to the implemented. The same >>>> rule applies also in case of referring a module in path (leafref) and by >>>> deviating a module. But it does not apply when a module data is used in >>>> must or when conditions. That's the reason why it complains just about >>>> ietf-ip and not about ietf-interfaces. >>>> * YANG actually does not provide a way to specify that a particular >>>> import is also expected to be implemented. Therefore, libyang needs some >>>> help with setting modules implemented - all the explicitly loaded modules >>>> are supposed to be implemented, if the module is just implicitly loaded >>>> from the search directory and user did not expressed that it is supposed >>>> to be implemented, it is kept only imported to provide groupings or type >>>> definitions >>>> 5. Benoit Claise asked (referring to my reference to automated tools): >>>> * Would it be possible to improve the warning (and the related test, >>>> by testing implemented instead of import), basically telling that the >>>> module itself is fine? >>>> >>>> >>>> I’m interested to know that NETMOD thinks about this distinction between >>>> implemented versus imported (in the absence of any instance documents). I >>>> guess my (maybe naive) view is that if all I’m doing is checking for >>>> errors in my YANG model then I don’t care about this. If my YANG is good I >>>> want to see no warnings or errors, and if it’s bad then I want to be told >>>> this (and why). >>>> >>>> Thanks, >>>> William _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod