Radek Krejčí <[email protected]> writes:
> 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."
Strictly speaking, this is incorrect. XPath expressions do not refer to
schema nodes but rather to nodes/nodesets in an instance data tree.
>
> I'm interested in "must" and "when". I'm not sure why it is mentioned
> here, because, in contrast to "path", "augment" and "deviation",
Actually, the argument of "path" is also a (simplified) XPath expression.
> "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.
Agreed, Lada
>
> 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
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
