Robert Wilton <rwil...@cisco.com> writes: > 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.
This will fail if a module just wants to use a grouping or typedef from an imported module but not data nodes that may also be there. It is exactly the problem that I mentioned in the discussion about NETMOD charter: we need a way to specify a complete data model. In my YANG/I-D development environment [1], a hello XML file is used for this purpose. Lada [1] https://github.com/llhotka/YANG-I-D > > 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 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
