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

[Andy Bierman <[e-mail]>]

On Wed, Aug 9, 2017 at 7:20 AM, Vladimir Vassilev <[e-mail]>
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:[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=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
>>         [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=x7sK1j
>> WYtSsQJr8r6G7FjWR5gAoMtgv6zRwxT4bzMGQ&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=NFJL1R
>> jYNxNMcnPhhm--ECwdEdyUXHGEVEq4fsjzruk&e=>
>>
>>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>