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

[Ladislav Lhotka <[e-mail]>]

Vladimir Vassilev píše v St 09. 08. 2017 v 16:20 +0200:
> 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.

I agree. I have seen quite a few bugs (both in my and somebody else's code)
directly caused by submodules, e.g. in definition lookup. You are right that in
YANG 1.0 the "include" logic was really horrible but still we may be better off
with no submodules at all.

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.

Lada

> 
> 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.
> 
> Vladimir
> 
> > Regards,
> > 
> > William
> > 
> > *From:*Vladimir Vassilev [mailto:[e-mail]]
> > *Sent:* 07 August 2017 20:31
> > *To:* Ivory, William <[e-mail]>
> > *Cc:* '[e-mail]' <[e-mail]>
> > *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:[e-mail]]
> >     *Sent:* 07 August 2017 14:28
> >     *To:* Ivory, William <[e-mail]>
> >     <mailto:[e-mail]>
> >     *Cc:* [e-mail] <mailto:[e-mail]>
> >     *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.h
> > tml
> >         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_m
> > ail-2Darchive_web_netmod_current_msg15418.html&d=DwMFaQ&c=LFYZ-
> > o9_HUMeMTSQicvjIg&r=FmJP9CH54z5mG3DFGBdc_9q1TLpYQ31-TQ-
> > 26_Qa9vw&m=YC4w6Zi9KhBp0MnnvA42_qdR2aM3uOFWpZYtgF122Ec&s=OxxQRDucETBaDPn4KGN
> > WcLlu4e8AMSfuyJJjrklp3R0&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_mbj
> > 4668_pyang_issues_194&d=DwMFaQ&c=LFYZ-
> > o9_HUMeMTSQicvjIg&r=FmJP9CH54z5mG3DFGBdc_9q1TLpYQ31-TQ-
> > 26_Qa9vw&m=YC4w6Zi9KhBp0MnnvA42_qdR2aM3uOFWpZYtgF122Ec&s=bkakKJEZzCBq3BkP5Nz
> > W-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
> >         [e-mail] <mailto:[e-mail]>
> >         https://www.ietf.org/mailman/listinfo/netmod
> >         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_m
> > ailman_listinfo_netmod&d=DwMFaQ&c=LFYZ-
> > o9_HUMeMTSQicvjIg&r=FmJP9CH54z5mG3DFGBdc_9q1TLpYQ31-TQ-
> > 26_Qa9vw&m=YC4w6Zi9KhBp0MnnvA42_qdR2aM3uOFWpZYtgF122Ec&s=x7sK1jWYtSsQJr8r6G7
> > FjWR5gAoMtgv6zRwxT4bzMGQ&e=>
> > 
> > 
> > 
> > 
> >     _______________________________________________
> > 
> >     netmod mailing list
> > 
> >     [e-mail] <mailto:[e-mail]>
> > 
> >     https://www.ietf.org/mailman/listinfo/netmod
> >     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailm
> > an_listinfo_netmod&d=DwMFaQ&c=LFYZ-
> > o9_HUMeMTSQicvjIg&r=FmJP9CH54z5mG3DFGBdc_9q1TLpYQ31-TQ-
> > 26_Qa9vw&m=M7t8vTUb71XRWW7ZfSHTMlFEaAhzOdmQuBmw2ah-uGc&s=NFJL1RjYNxNMcnPhhm-
> > -ECwdEdyUXHGEVEq4fsjzruk&e=>
> > 
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67