Re: [netmod] yanglint and implemented versus imported YANG modules

Ladislav Lhotka <> Tue, 07 March 2017 11:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1106D129624 for <>; Tue, 7 Mar 2017 03:53:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r88aJahgB3QU for <>; Tue, 7 Mar 2017 03:53:44 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C13AB1295D0 for <>; Tue, 7 Mar 2017 03:53:43 -0800 (PST)
Received: from localhost ( []) by (Postfix) with ESMTPSA id B95041820044; Tue, 7 Mar 2017 12:54:21 +0100 (CET)
From: Ladislav Lhotka <>
To: Radek =?utf-8?B?S3JlasSNw60=?= <>, Robert Wilton <>, William Lupton <>,
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 07 Mar 2017 12:53:39 +0100
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [netmod] yanglint and implemented versus imported YANG modules
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Mar 2017 11:53:46 -0000

Radek Krejčí <> writes:

> Hi Lada,
> Dne 7.3.2017 v 10:30 Ladislav Lhotka napsal(a):
>> Robert Wilton <> 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. 
> but does it affect the validation of the module?

Potentially it could - for example, the imported module may have some
default content with "must" statements. Practically, it shouldn't be a
problem most of the time.

>> 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]
> we have this feature in TODO for yanglint, but I'm afraid that it does

Now it's better to use yang-library, as Yangson does (but maybe this is
your plan, right?).

> not solve the issue - even now the script can read some additional
> file with the specification which modules are expected to be loaded
> before the module being validated (i.e. which imported module is
> supposed to be implemented). The root of the issue is that this
> information is not part of the importing module itself.

This would be one option, otherwise this information can also be
included in the document separately as metadata - validation
instructions. This could BTW also solve the issue of what modules are
supposed to be validated.


> Radek
>>> Thanks,
>>> Rob
>>> On 06/03/2017 16:44, William Lupton wrote:
>>>> All,
>>>> This message arose from a 
>>>> <> “draft-ietf-pim-igmp-mld-yang-02.txt: 
>>>> YANG compilation isuse” (sic) thread 
>>>> <> 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 mailing list

Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67