Yes, we'll consider that. Thanks,
William -----Original Message----- From: Robert Wilton [mailto:rwil...@cisco.com] Sent: 23 August 2017 11:26 To: Ivory, William <william.iv...@intl.att.com>; 'Juergen Schoenwaelder' <j.schoenwael...@jacobs-university.de> Cc: 'Alex Campbell' <alex.campb...@aviatnet.com>; 'netmod@ietf.org' <netmod@ietf.org> Subject: Re: [netmod] Query about augmenting module from submodule in YANG 1.0 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:rwil...@cisco.com] > Sent: 23 August 2017 10:46 > To: Ivory, William <william.iv...@intl.att.com>; 'Juergen > Schoenwaelder' <j.schoenwael...@jacobs-university.de> > Cc: 'Alex Campbell' <alex.campb...@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.schoenwael...@jacobs-university.de] >> Sent: 23 August 2017 08:25 >> To: Ivory, William <william.iv...@intl.att.com> >> Cc: 'Alex Campbell' <alex.campb...@aviatnet.com>; 'Robert Wilton' >> <rwil...@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.campb...@aviatnet.com] >>> Sent: 22 August 2017 23:28 >>> To: Ivory, William <william.iv...@intl.att.com>; 'Robert Wilton' >>> <rwil...@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-boun...@ietf.org> on behalf of Ivory, William >>> <william.iv...@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-boun...@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_netm >>> o >>> d >>> -2Dwg_yang-2Dnext_issues_26&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8ky >>> e >>> K >>> 3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211x >>> U >>> 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_ma >>> i >>> l >>> man_listinfo_netmod&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYi >>> a >>> Q >>> 2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgP >>> l A T7owI&s=t7vGIH8ABuAm00e-bkSowD9eawModGq0N2OkjANtpYI&e= >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ma >>> i >>> l >>> man_listinfo_netmod&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYi >>> a >>> Q >>> 2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=esi8GPSc1xVjTt9SKxqzNHRDXT2P1h01a-Ue >>> b n ST-Yo&s=PctKy3ij6W0TQs1NFp18SX8MQtYKeG9RxADh3cphcxU&e= >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ma >>> i >>> l >>> man_listinfo_netmod&d=DwIBAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYi >>> a >>> Q >>> 2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=RH3zvD2B8_s4uw1PXm_ka37vgz9_q2Rc87tD >>> 8 K fZ9jA&s=XydU0vXE0AEg2FDE-kx_Ae6rOOAh5koxEeJ2cefgDNA&e= _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
