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 <[email protected]> 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 [email protected]
>> <mailto:[email protected]> “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.
>> 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)
>> 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.
>> 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”.
>> 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
>> 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
>> [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
