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."
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 <[email protected]
>> <mailto:[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.
>>>
>>> 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
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
