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

"Ivory, William" <william.ivory@intl.att.com> Tue, 08 August 2017 08:17 UTC

Return-Path: <william.ivory@intl.att.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582D41320D8 for <netmod@ietfa.amsl.com>; Tue, 8 Aug 2017 01:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level:
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZpVJ188HnFZ for <netmod@ietfa.amsl.com>; Tue, 8 Aug 2017 01:16:58 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C2B71320DC for <netmod@ietf.org>; Tue, 8 Aug 2017 01:16:58 -0700 (PDT)
Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v788FBDP000588; Tue, 8 Aug 2017 04:16:55 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 2c73806v8w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 08 Aug 2017 04:16:54 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v788GstT017413; Tue, 8 Aug 2017 04:16:54 -0400
Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v788GjrA017334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 8 Aug 2017 04:16:51 -0400
Received: from gbcdccas03.intl.att.com (gbcdccas03.intl.att.com [135.76.180.11]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 8 Aug 2017 08:16:36 GMT
Received: from GBCDCMBX03.intl.att.com ([135.76.31.134]) by gbcdccas03.intl.att.com ([135.76.180.11]) with mapi id 14.03.0361.001; Tue, 8 Aug 2017 09:16:35 +0100
From: "Ivory, William" <william.ivory@intl.att.com>
To: 'Vladimir Vassilev' <vladimir@transpacket.com>
CC: "'netmod@ietf.org'" <netmod@ietf.org>
Thread-Topic: [netmod] Query about augmenting module from submodule in YANG 1.0
Thread-Index: AdMMOPUClm48yMKSSEeEurX4RbXaiADP5++AAAR9DaAACC3kAAAcrpQg
Date: Tue, 08 Aug 2017 08:15:32 +0000
Deferred-Delivery: Tue, 8 Aug 2017 08:16:34 +0000
Message-ID: <E3378E0605547F4E854DEE0CB1116AB0210631@gbcdcmbx03.intl.att.com>
References: <E3378E0605547F4E854DEE0CB1116AB020865B@gbcdcmbx03.intl.att.com> <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com> <E3378E0605547F4E854DEE0CB1116AB02102DC@gbcdcmbx03.intl.att.com> <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com>
In-Reply-To: <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.76.181.254]
Content-Type: multipart/alternative; boundary="_000_E3378E0605547F4E854DEE0CB1116AB0210631gbcdcmbx03intlatt_"
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-08-08_03:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708080132
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/rq5rrhRMR0pyFhQgpmi6PiGTpRI>
Subject: Re: [netmod] Query about augmenting module from submodule in YANG 1.0
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Aug 2017 08:17:00 -0000

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.

Regards,

William

From: Vladimir Vassilev [mailto:vladimir@transpacket.com]
Sent: 07 August 2017 20:31
To: Ivory, William <william.ivory@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:janl@tail-f.com]
Sent: 07 August 2017 14:28
To: Ivory, William <wi274w@intl.att.com><mailto:wi274w@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,

> In https://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=>