On Wed, Aug 9, 2017 at 7:20 AM, Vladimir Vassilev <[email protected]> wrote:
> > On 08/08/2017 10:15 AM, Ivory, William wrote: > >> >> Hi Vladimir, >> >> We have one YANG file that represents multiple components in the system. >> Currently they are bundled together, so having a single YANG file is ok. >> In future we’d like to be able to break this down into multiple daemons >> each dealing with a subset of the YANG. However, we don’t wish to change >> the namespace of the YANG as that would not be backwards compatible. So, >> submodules looked to be a good way to do this. I wouldn’t call it drastic >> – it is one YANG file we are talking about breaking up into parts. >> >> I see your point. IMO the only real justification for people designing > using submodules instead of modules is when they are limited to single > namespace and need a workaround solution like in your case. > I was hoping your problem could be something that can convince me that > submodules existence in YANG can be justified with more then its function > as a workaround replacement for modules in this particular case. > > My grudge against submodules is not only based on the significant > implementation and support effort they require for something that is used > very rarely. A completely separate source file quantum for YANG that lacks > the key property of a module at the YANG level - modularity. For submodules > are both non-reusable and interdependent. Very few organizations publish > submodule based designs probably for the same reasons I avoid them. > Submodules are great if you want to publish non-reusable YANG though. > > IETF went once for design with submodules in ietf-snmp.yang. Even in that > case (well organized YANG module) I would have preferred a single file with > some of the exotic features modularized in separate modules instead. > Dynamic compilers still need to go through all submodules even in device > that supports only the base SNMP functionality before features can be > evaluated. As a result instead of the 10KB of actually implemented schema > 60KB of additional YANG has to be retrieved in the worst case and compiled. > > Both submodules and alternative datastores are examples of how complexity > is introduced with innocent intentions and how it eventually multiplies > (ref. draft-nmdsdt-netconf-rfc7895bis-01). > > The biggest problem I have with submodules is they break the atomicity of > the module concept. There is something that is not right with that. Worse > than the unjustified implementation and standardization effort. A > compromise that should have been avoided. > > IMO If you absolutely don't need submodules it is best to stay away from > them. > > I argued against submodules from the start. They add a lot of complexity for implementors and module readers. Too much cost for the 1 benefit of reusing a namespace. Good summary about why they are quite rigid and not really modular at all. They work even worse when include-without-revision is used. In this most common case, the actual submodule revisions used are very implementation-dependent. There is no way to cross-check the main module revision against the submodule revisions. (i.e., no belongs-to foo@2017-01-01, just belongs-to foo). I have seen companies start to use submodules, then undo it when they figure out that a monolithic YANG-ball is not as workable as a module-set. > Vladimir > > Andy > Regards, >> >> William >> >> *From:*Vladimir Vassilev [mailto:[email protected]] >> *Sent:* 07 August 2017 20:31 >> *To:* Ivory, William <[email protected]> >> *Cc:* '[email protected]' <[email protected]> >> *Subject:* Re: [netmod] Query about augmenting module from submodule in >> YANG 1.0 >> >> Hello, >> >> IMO "submodule"s are a striking example of redundant complexity in an >> otherwise very close to perfection YANG (regardless if it is YANG 1.0 or >> 1.1). >> >> Modules and submodules have been around for a while however the ratio of >> the currently published modules compared with the submodules is about 40 >> modules to 1 submodule (if one ignores all the modules and submodules from >> particular networking hardware manufacturer that is particularly keen on >> using submodules). As a far but still relevant analogy Java has a >> limitation of 1 file per class and this atomicity has proven to be an >> advantage especially in terms of enforcing modularity. IMO there is nothing >> that can be done with the help of submodules that can not be done without >> them. >> >> For the sake of the argument can you provide a synthesized description of >> the problem that lead you to a drastic solution like "we’ll look at trying >> to put everything into submodules in this case."? >> >> Vladimir >> >> On 08/07/2017 04:37 PM, Ivory, William wrote: >> >> Hi Jan, >> >> Thanks – we’ll look at trying to put everything into submodules in >> this case. >> >> Regards, >> >> William >> >> *From:*Jan Lindblad [mailto:[email protected]] >> *Sent:* 07 August 2017 14:28 >> *To:* Ivory, William <[email protected]> >> <mailto:[email protected]> >> *Cc:* [email protected] <mailto:[email protected]> >> *Subject:* Re: [netmod] Query about augmenting module from >> submodule in YANG 1.0 >> >> The submodule concept in YANG 1.0 is, well, not very useful, and >> even less intuitive. That's why it saw major rework in YANG 1.1. >> >> A YANG 1.0 submodule cannot reference the module that includes it, >> directly or indirectly. This is because in YANG 1.0 the symbols in >> other submodules of the same namespace are invisible to the >> submodule unless they are explicitly included. And parent modules >> can't be included by a submodule because that would lead to an >> inclusion loop. It is possible to reference (augment, etc) other >> sibling submodules, though. So if you split your modules cleverly, >> you might be able to resolve your referential constraints anyway. >> >> If you really want to take the submodule path, I'd recommend >> moving to YANG 1.1. In the interest of preserving the hair tone of >> IT-architects. >> >> /jan >> >> We’re trying to solve a modularity problem with a YANG module >> by splitting it into submodules and augmenting the parent >> module from each submodule. However, despite the wording >> below in YANG 1.0 section 7.15, we’ve found a couple of >> threads online with comments suggesting it’s only allowed in >> YANG 1.1? Would appreciate clarification. >> >> RFC 6020 section 7.15 suggests it is allowed: >> >> ‘ >> >> The "augment" statement allows a module or submodule to add >> to the >> >> schema tree defined in an external module, or the current >> module and >> >> its submodules, and to add to the nodes from a grouping in >> a "uses" >> >> statement. >> >> ‘ >> >> Versus online comments >> here:https://www.ietf.org/mail-archive/web/netmod/current/ >> msg15418.html >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www. >> ietf.org_mail-2Darchive_web_netmod_current_msg15418.html& >> d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=FmJP9CH54z5mG >> 3DFGBdc_9q1TLpYQ31-TQ-26_Qa9vw&m=YC4w6Zi9KhBp0MnnvA42_q >> dR2aM3uOFWpZYtgF122Ec&s=OxxQRDucETBaDPn4KGNWcLlu4e8AMSfuyJJjrklp3R0&e=> >> >> ‘> On 01 Mar 2016, at 10:38, Anton Tkáčik <anton.tkacik at >> pantheon.tech> wrote: >> >> > >> >> > Hi, >> >> > Noticed other issue with example set, >> >> > Inhttps://github.com/mbj4668/pyang/issues/194 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__ >> github.com_mbj4668_pyang_issues_194&d=DwMFaQ&c=LFYZ-o9_HUMeM >> TSQicvjIg&r=FmJP9CH54z5mG3DFGBdc_9q1TLpYQ31-TQ-26_Qa9vw&m=YC >> 4w6Zi9KhBp0MnnvA42_qdR2aM3uOFWpZYtgF122Ec&s=bkakKJEZzCBq3BkP >> 5NzW-wDX6KOZHpOnT0u-ySg8rS0&e=> Lada stated that in YANG 1.0 submodule >> can not augment nodes >> >> > defined in parent model. >> >> > >> >> > Is that correct that submodule can not augment definition >> defined in parent module? >> >> >> This isn't possible in YANG 1.0 but will be possible in 1.1. >> However, in the present case the definition being augmented from the >> submodule is arguably in a different module. >> >> >> Lada >> >> ‘ >> >> Thanks, >> >> William >> >> _______________________________________________ >> netmod mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/netmod >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www. >> ietf.org_mailman_listinfo_netmod&d=DwMFaQ&c=LFYZ-o9_ >> HUMeMTSQicvjIg&r=FmJP9CH54z5mG3DFGBdc_9q1TLpYQ31-TQ-26_ >> Qa9vw&m=YC4w6Zi9KhBp0MnnvA42_qdR2aM3uOFWpZYtgF122Ec&s=x7sK1j >> WYtSsQJr8r6G7FjWR5gAoMtgv6zRwxT4bzMGQ&e=> >> >> >> >> >> _______________________________________________ >> >> netmod mailing list >> >> [email protected] <mailto:[email protected]> >> >> https://www.ietf.org/mailman/listinfo/netmod >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www. >> ietf.org_mailman_listinfo_netmod&d=DwMFaQ&c=LFYZ-o9_ >> HUMeMTSQicvjIg&r=FmJP9CH54z5mG3DFGBdc_9q1TLpYQ31-TQ-26_ >> Qa9vw&m=M7t8vTUb71XRWW7ZfSHTMlFEaAhzOdmQuBmw2ah-uGc&s=NFJL1R >> jYNxNMcnPhhm--ECwdEdyUXHGEVEq4fsjzruk&e=> >> >> > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
