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:vladi...@transpacket.com]
*Sent:* 07 August 2017 20:31
*To:* Ivory, William <william.iv...@intl.att.com>
*Cc:* 'netmod@ietf.org' <netmod@ietf.org>
*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:j...@tail-f.com]
    *Sent:* 07 August 2017 14:28
    *To:* Ivory, William <wi2...@intl.att.com>
    <mailto:wi2...@intl.att.com>
    *Cc:* netmod@ietf.org <mailto:netmod@ietf.org>
    *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
        netmod@ietf.org <mailto:netmod@ietf.org>
        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

    netmod@ietf.org <mailto:netmod@ietf.org>

    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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to