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:[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=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
[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=x7sK1jWYtSsQJr8r6G7FjWR5gAoMtgv6zRwxT4bzMGQ&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=NFJL1RjYNxNMcnPhhm--ECwdEdyUXHGEVEq4fsjzruk&e=>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
