Re: [netmod] Query about augmenting module from submodule in YANG 1.0

Robert Wilton <rwilton@cisco.com> Wed, 23 August 2017 10:25 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 870F6132946 for <netmod@ietfa.amsl.com>; Wed, 23 Aug 2017 03:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 Q8tpuNyPu2jF for <netmod@ietfa.amsl.com>; Wed, 23 Aug 2017 03:25:47 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 786251321B6 for <netmod@ietf.org>; Wed, 23 Aug 2017 03:25:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7865; q=dns/txt; s=iport; t=1503483946; x=1504693546; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=oD9bcgZhylhThzBdyOA4b9x4dwm0aKzPxpG51L7B0rc=; b=VcRazRbClIiCUiPmQCXN/5KhDxxO8XLXIXYoU2llCGTsjjld6eoToeqz +yc9OqyLMk6oZFzt2lOyt0Q9xolEzHQ4zPdaLqiS4inkcxNZkEbSIuvOa LFxsMtDF6agTt9wTVTF87Jq4DXKSFYCByeoZNBIw9m93q2WWssdM9zw1R 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BuAQAxV51Z/xbLJq1SChkBAQEBAQEBAQEBAQcBAQEBAYMtgRGBFY8IkRaYNiyFGwKEfRUBAgEBAQEBAQFrKIUYAQEBAQIBIxU2BgUFBwQLEAEEAQEBAgIjAwICRgkIBgEMBgIBAReKDggQrhuCJotvAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBDYIdg06BYyuCfIMmgSIrgxOCYQWgWIdWjG6CEok8hxaJb4NPiHA1IoEKMiEIHBVJhxs/NgEBin8BAQE
X-IronPort-AV: E=Sophos;i="5.41,416,1498521600"; d="scan'208";a="696701929"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Aug 2017 10:25:42 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v7NAPfSl027256; Wed, 23 Aug 2017 10:25:41 GMT
To: "Ivory, William" <william.ivory@intl.att.com>, 'Juergen Schoenwaelder' <j.schoenwaelder@jacobs-university.de>
Cc: 'Alex Campbell' <Alex.Campbell@Aviatnet.com>, "'netmod@ietf.org'" <netmod@ietf.org>
References: <E3378E0605547F4E854DEE0CB1116AB02102DC@gbcdcmbx03.intl.att.com> <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com> <E3378E0605547F4E854DEE0CB1116AB0210631@gbcdcmbx03.intl.att.com> <defe35bb-bb8b-f1f0-d8c4-2d2d0f23731b@transpacket.com> <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com> <E3378E0605547F4E854DEE0CB1116AB021CE2D@gbcdcmbx03.intl.att.com> <1503440878003.28215@Aviatnet.com> <E3378E0605547F4E854DEE0CB1116AB02205D9@gbcdcmbx03.intl.att.com> <20170823072435.wv7pvndrm5du5q3x@elstar.local> <E3378E0605547F4E854DEE0CB1116AB0220656@gbcdcmbx03.intl.att.com> <a2f53f90-3bfc-38ba-7a7e-9d8d26202c48@cisco.com> <E3378E0605547F4E854DEE0CB1116AB02212E9@gbcdcmbx03.intl.att.com>
From: Robert Wilton <rwilton@cisco.com>
Message-ID: <f22eaa91-20c4-c458-f57a-212949397b6a@cisco.com>
Date: Wed, 23 Aug 2017 11:25:41 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <E3378E0605547F4E854DEE0CB1116AB02212E9@gbcdcmbx03.intl.att.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/JMbmvzmMAlBXOLkEVmfL8KSbgyg>
Subject: Re: [netmod] Query about augmenting module from submodule in YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 23 Aug 2017 10:25:50 -0000


On 23/08/2017 11:09, Ivory, William wrote:
> Hi Robert,
>
> Probably shouldn't have mentioned packages as that's really a diversion from the main point.  What submodules provide is a way to differentiate YANG nodes in a single namespace so that while still belonging to that single namespace, subsets may be handled by different daemons simply by routing according to submodule id.  That keeps all the identifying logic within YANG.
>
> Obviously if we could start afresh, we'd use separate modules from day one.  However, we have existing YANG that needs to remain to be backwards-compatible, so that isn't an option.
Another potential solution that doesn't use sub modules could be to 
define a bespoke YANG extension to annotate your YANG schema tree with 
any necessary routing information for it to be handled by the 
appropriate daemon.

Thanks,
Rob

> Regards,
>
> William
>
> -----Original Message-----
> From: Robert Wilton [mailto:rwilton@cisco.com]
> Sent: 23 August 2017 10:46
> To: Ivory, William <william.ivory@intl.att.com>; 'Juergen Schoenwaelder' <j.schoenwaelder@jacobs-university.de>
> Cc: 'Alex Campbell' <Alex.Campbell@Aviatnet.com>; 'netmod@ietf.org' <netmod@ietf.org>
> Subject: Re: [netmod] Query about augmenting module from submodule in YANG 1.0
>
> Hi William,
>
> I think that there might be some downsides to your proposed solution of using submodules - which you may have already considered:
>
> 1) All of the debian packages will have to be installed together to allow the YANG module to be built, or otherwise there will be missing submodules, and the module will fail to compile (since the top level module must list all included sub-modules).
> 2) It might end up with your requiring tight versioning of all of your debian packages together with the same version number, or otherwise you may need greater care over how the sub-modules are updated and dependencies are handled.
>
> If your YANG was being designed from scratch then using separate YANG modules may allow for a cleaner solution - but I appreciate that may not help you with where you are now.
>
> Thanks,
> Rob
>
>
> On 23/08/2017 09:24, Ivory, William wrote:
>> Sorry - meant Debian packages.  We have a large YANG module that really ought to be handled by multiple daemons, so plan to use submodules so we can identify the different parts and process them in the right place.  Recombining into a single module would lose that granularity.
>>
>> William
>>
>> -----Original Message-----
>> From: Juergen Schoenwaelder
>> [mailto:j.schoenwaelder@jacobs-university.de]
>> Sent: 23 August 2017 08:25
>> To: Ivory, William <william.ivory@intl.att.com>
>> Cc: 'Alex Campbell' <Alex.Campbell@Aviatnet.com>; 'Robert Wilton'
>> <rwilton@cisco.com>; 'netmod@ietf.org' <netmod@ietf.org>
>> Subject: Re: [netmod] Query about augmenting module from submodule in
>> YANG 1.0
>>
>> What are packages? I think submodules declare to which module they belong, no? Perhaps you are doing something that submodules do not even support.
>>
>> /js
>>
>> On Wed, Aug 23, 2017 at 07:08:10AM +0000, Ivory, William wrote:
>>> ...  except that if the whole reason for splitting into submodules was to allow the submodules to belong to different packages in our system, combining them back again is not possible.  I wouldn't be splitting them unless I needed to for good reason.
>>>
>>> William
>>>
>>> -----Original Message-----
>>> From: Alex Campbell [mailto:Alex.Campbell@Aviatnet.com]
>>> Sent: 22 August 2017 23:28
>>> To: Ivory, William <william.ivory@intl.att.com>; 'Robert Wilton'
>>> <rwilton@cisco.com>; 'netmod@ietf.org' <netmod@ietf.org>
>>> Subject: Re: [netmod] Query about augmenting module from submodule in
>>> YANG 1.0
>>>
>>> Hi,
>>>
>>> I'm not Rob, but my understanding is that if a module author wanted to migrate to YANG 2.0, they could merge their submodules back into the main module - which is not a difficult procedure and does not break compatibility with clients.
>>>
>>> Alex
>>> ________________________________________
>>> From: netmod <netmod-bounces@ietf.org> on behalf of Ivory, William
>>> <william.ivory@intl.att.com>
>>> Sent: Tuesday, 22 August 2017 1:44 a.m.
>>> To: 'Robert Wilton'; 'netmod@ietf.org'
>>> Subject: Re: [netmod] Query about augmenting module from submodule in
>>> YANG 1.0
>>>
>>> Hi Rob,
>>>
>>> That would make it very hard to update existing 1.x YANG models to use new features in YANG 2.x if they used submodules.  Maybe that's something that no one would ever consider doing anyway, or maybe YANG 1.1 already has similar differences to 1.0?  I had (perhaps naively) assumed that you could migrate a namespace / model from YANG 1.0 to 2.0?
>>>
>>> Regards,
>>>
>>> William
>>>
>>> -----Original Message-----
>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert
>>> Wilton
>>> Sent: 21 August 2017 11:24
>>> To: netmod@ietf.org
>>> Subject: Re: [netmod] Query about augmenting module from submodule in
>>> YANG 1.0
>>>
>>>
>>>
>>> On 09/08/2017 16:13, Juergen Schoenwaelder wrote:
>>>> On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka wrote:
>>>>> I remember that in early stages of YANG there was some irrational
>>>>> fear of introducing too many namespaces, and submodules may be a
>>>>> consequence of it. As you write, submodules provide no benefits
>>>>> whatsoever in terms of modularity, but the overhead in terms of
>>>>> metadata, IANA registration etc. is pretty much the same as for
>>>>> modules.
>>>> In case YANG 2.0 is ever done, I suggest someone files a proposal to
>>>> remove submodules if the cost/benefit ratio is at odds. There is
>>>> nothing wrong with removing stuff that has been found problematic.
>>> I agree.
>>>
>>> I've added
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmo
>>> d
>>> -2Dwg_yang-2Dnext_issues_26&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kye
>>> K
>>> 3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU
>>> 6 1xSHgPlAT7owI&s=-kR4fUtXArQy0RwWb32DpT1bP4X_cNqt2zJVoC0JiX8&e=
>>>
>>> Rob
>>>
>>>> The motivation for submodules was that organizations maintaining
>>>> large modules with multiple people can do so without having to mess
>>>> around with tools like m4 scripts to produce a single module from 'snippets'
>>>> and to avoid integration surprises. But perhaps using m4 scripts and
>>>> decent version control systems (that can integrate and compile on
>>>> checkin) is indeed cheaper than having submodules part of the YANG
>>>> language itself.
>>>>
>>>> /js
>>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
>>> l
>>> man_listinfo_netmod&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYia
>>> Q
>>> 2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPl
>>> A T7owI&s=t7vGIH8ABuAm00e-bkSowD9eawModGq0N2OkjANtpYI&e=
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
>>> l
>>> man_listinfo_netmod&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYia
>>> Q
>>> 2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=esi8GPSc1xVjTt9SKxqzNHRDXT2P1h01a-Ueb
>>> n ST-Yo&s=PctKy3ij6W0TQs1NFp18SX8MQtYKeG9RxADh3cphcxU&e=
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
>>> l
>>> man_listinfo_netmod&d=DwIBAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYia
>>> Q
>>> 2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=RH3zvD2B8_s4uw1PXm_ka37vgz9_q2Rc87tD8
>>> K fZ9jA&s=XydU0vXE0AEg2FDE-kx_Ae6rOOAh5koxEeJ2cefgDNA&e=