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

[Vladimir Vassilev <[e-mail]>]

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.

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.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=FmJP9CH54z5mG3DFGBdc_9q1TLpYQ31-TQ-26_Qa9vw&m=YC4w6Zi9KhBp0MnnvA42_qdR2aM3uOFWpZYtgF122Ec&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_HUMeMTSQicvjIg&r=FmJP9CH54z5mG3DFGBdc_9q1TLpYQ31-TQ-26_Qa9vw&m=YC4w6Zi9KhBp0MnnvA42_qdR2aM3uOFWpZYtgF122Ec&s=bkakKJEZzCBq3BkP5NzW-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_mailman_listinfo_netmod&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=FmJP9CH54z5mG3DFGBdc_9q1TLpYQ31-TQ-26_Qa9vw&m=YC4w6Zi9KhBp0MnnvA42_qdR2aM3uOFWpZYtgF122Ec&s=x7sK1jWYtSsQJr8r6G7FjWR5gAoMtgv6zRwxT4bzMGQ&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_mailman_listinfo_netmod&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=FmJP9CH54z5mG3DFGBdc_9q1TLpYQ31-TQ-26_Qa9vw&m=M7t8vTUb71XRWW7ZfSHTMlFEaAhzOdmQuBmw2ah-uGc&s=NFJL1RjYNxNMcnPhhm--ECwdEdyUXHGEVEq4fsjzruk&e=>
>