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

Robert Wilton <rwilton@cisco.com> Mon, 06 March 2017 16:59 UTC

Return-Path: <rwilton@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E569F129888 for <netmod@ietfa.amsl.com>; Mon, 6 Mar 2017 08:59:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpIezwPRQBpV for <netmod@ietfa.amsl.com>; Mon, 6 Mar 2017 08:59:41 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6F051294FB for <netmod@ietf.org>; Mon, 6 Mar 2017 08:59:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10216; q=dns/txt; s=iport; t=1488819580; x=1490029180; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=seDCv4ZKZAD4K+frjmtBGWRes5YieTkSdnpZyrtTn0A=; b=Ts1sN6QX7cSM1xdcA6bYMhRS8taERRtNkMIER0yNX0q39qcu7x53/Oa6 t1SoC2YxEatqpfLwTlCwOeDl9AxbaQz4r71WGCSVCofhZxyZ+DmUTLjRu nQpTj7vHqmOpy3Gv1Mwh8izumifOf3xPGLSMvPCvvpdqOBmB/P0Oub/ZE k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BvAwDolL1Y/xbLJq1eGQEBAQEBAQEBAQEBBwEBAQEBgyeBCwOBB4Nfig1zkDMfkAuFLIINHwEMhSxKAoJhGAECAQEBAQEBAWsohRYBAQQBASFLGwkCDgonAwICJx8RBgEMBgIBAYl4DpINnVmCJiuKKgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhk6CBQiCYoQ3AQGDIYJfBY9WjFaSM4pOhlGLMogJHziBAyIVCBcVP4RUHYFjQDUBhzkNFweCEAEBAQ
X-IronPort-AV: E=Sophos;i="5.35,254,1484006400"; d="scan'208,217";a="650208552"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Mar 2017 16:59:36 +0000
Received: from [10.63.23.115] (dhcp-ensft1-uk-vla370-10-63-23-115.cisco.com [10.63.23.115]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v26Gxab3007980; Mon, 6 Mar 2017 16:59:36 GMT
To: William Lupton <wlupton@broadband-forum.org>, netmod@ietf.org
References: <1C757F2F-D47A-4688-845D-ACCE04AE56D1@broadband-forum.org>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <9ceda4b1-6297-bab4-7c4e-da29bbea6890@cisco.com>
Date: Mon, 06 Mar 2017 16:59:36 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <1C757F2F-D47A-4688-845D-ACCE04AE56D1@broadband-forum.org>
Content-Type: multipart/alternative; boundary="------------966026CFC5E77544B9DBE013"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/NrJZm3URwWpgE-h1XET2rb_ZjrM>
Subject: Re: [netmod] yanglint and implemented versus imported YANG modules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Mar 2017 16:59:43 -0000

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 yang-multicast@ietf.org 
> <mailto:yang-multicast@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