Re: [netmod] All IETF YANG modules MUST include revision-label statements
"Reshad Rahman (rrahman)" <rrahman@cisco.com> Mon, 30 March 2020 17:56 UTC
Return-Path: <rrahman@cisco.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 E8F9E3A0980 for <netmod@ietfa.amsl.com>; Mon, 30 Mar 2020 10:56:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.7
X-Spam-Level:
X-Spam-Status: No, score=-7.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=BatSS+v2; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=KX9o1Drh
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 qpBww2iqzSa0 for <netmod@ietfa.amsl.com>; Mon, 30 Mar 2020 10:56:24 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19DBB3A098B for <netmod@ietf.org>; Mon, 30 Mar 2020 10:56:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13392; q=dns/txt; s=iport; t=1585590983; x=1586800583; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=XX/YY9/FZ0gmVnzIWJ+2cyUkrRNzrH9clpk0v2HGjqY=; b=BatSS+v26l+7KwwTYtYF5fMbb6lJVx/8f/CLoOouAEzjKKGZEN0a04aa O41z0sCQ2rw9e8WUelOHdUv9GLnRjabc1qiRGjjTNk5uVrqiCB3+0vmAG YAsLVUEfovnRh0612EaKbCfjHz099MzG/ZgsOhsO6h4iKJiQOKbk61Ntm 8=;
IronPort-PHdr: 9a23:ZGFaSR0M8CqI7ZtYsmDT+zVfbzU7u7jyIg8e44YmjLQLaKm44pD+JxKHt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSwdDjMwXmwI6B8vQE1fyLPvjaQQxHd9JUxlu+HToeUU=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DdAQB7MoJe/4gNJK1mGwEBAQEBAQEFAQEBEQEBAwMBAQGBe4FUUAVsWCAECyoKhBCDRQOKaoJfmB+BQoEQA1QKAQEBDAEBGA0IAgQBAYN/RQIXghskOBMCAwEBCwEBBQEBAQIBBQRthVYMhXABAQEBAgEBARAREQwBASwLAQ8CAQgYAgImAgICJQsVEAIEDgUigwQBgksDDiABDqI5AoE5iGJ1gTKCfwEBBYJFgj4YggwDBoEOKowxGoFBP4ERJyCCHy4+gmcBAQIagS8xIQKCWDKCLI1/AQOCd4YemVEKgjyHYY80HYJMlEmEV5Bqh0WSbQIEAgQFAg4BAQWBaSKBWHAVOyoBgkFQGA2OHYNzhRSFQXQCEIEXjGEBgQ8BAQ
X-IronPort-AV: E=Sophos;i="5.72,325,1580774400"; d="scan'208";a="746413740"
Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Mar 2020 17:55:52 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 02UHtqA6008670 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 30 Mar 2020 17:55:52 GMT
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Mar 2020 12:55:52 -0500
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Mar 2020 12:55:51 -0500
Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 30 Mar 2020 12:55:51 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lRchMDDihjU5OF4m9BCzTum+lfWzQQLYCf7cnfs7+O6CL6rgree8m8fEe6BYhq0t3uVA5YnC3aThMC3012LqJPopwEoBp7jLTSIzxGAEvOls/amawkes/KX4+F30HmJXktsVmVdnFEWBkdbdwZofNhG78ECKRptfWfmE55ReP2wgS0lMLFHO8xUojOB3TWzkIykwPNwBcFxID7Y4pGnyXXI/zf8N45lhZ9Q3NQuQjjqG2AjkYnwmcoIjn0S7cIWrF4cDXxcqMBEbSRQLbfjcp6PvkNvZUtGZ0ZIMUUfo8Zi6celgBeedkNo4r2wRo9mUnYMB3NdwCiaGt8xzoiwk3A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XX/YY9/FZ0gmVnzIWJ+2cyUkrRNzrH9clpk0v2HGjqY=; b=QMtmW/TfMV97LYx9vjDmagOG/y9tq3mzKNCmjnuYAyL8QcIFZ0uXcy0V53OqLybvgfP9RuNVq9v9tcappI2TiRch1xkziwwqvqu473JvcqH+HYmtPS8x81ultxTGMp/PfT9xC9jZ0bP82J76dSlbWG9PuaROXMSwu+pt5MmCpEGfHgfzX0VsbZu4/4hFMUQrAShwa6kLLIPS3FyxNaC5lDL8uJjQHveojMJEkdCd+H9fo3cVYUpPbEPw7yzQYtznwhSMiuVEMOoGY/T8DGcf2lwOvqESbG4EiCfEvr9t0Hg35bQ7LzPh2+HW2ZJQv9BpK76LaOyv8OIuxCz6ZyPbbg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XX/YY9/FZ0gmVnzIWJ+2cyUkrRNzrH9clpk0v2HGjqY=; b=KX9o1DrhoVjZdmN3ONVqBYL8+inisUcrG154rreydJ/izO2I1sx/3XUmiS0H3K5XugOYn38ulwWo/eHPPCLGpTbaawt7bDDvRQ7s5MaBoH5wIQh+xYmttW6aa9wGWuV7cpJRbJoNXbCXx71iH46CyDNcee8Ys4xwXAzOXVI2Gdc=
Received: from DM6PR11MB3420.namprd11.prod.outlook.com (2603:10b6:5:69::31) by DM6PR11MB4612.namprd11.prod.outlook.com (2603:10b6:5:2a8::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.19; Mon, 30 Mar 2020 17:55:50 +0000
Received: from DM6PR11MB3420.namprd11.prod.outlook.com ([fe80::91cb:6555:db9b:53fa]) by DM6PR11MB3420.namprd11.prod.outlook.com ([fe80::91cb:6555:db9b:53fa%7]) with mapi id 15.20.2856.019; Mon, 30 Mar 2020 17:55:50 +0000
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Martin Björklund <mbj+ietf@4668.se>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: All IETF YANG modules MUST include revision-label statements
Thread-Index: AQHWBNyukTO5JXWurk2ljZZiFHPveKhhLBqA
Date: Mon, 30 Mar 2020 17:55:50 +0000
Message-ID: <76623C79-BB91-4B5F-8FEA-406ADEAD1647@cisco.com>
References: <75CFDBD9-143C-407A-B7C3-26CEC51E229C@cisco.com> <20200328.094121.1160081114435152145.id@4668.se>
In-Reply-To: <20200328.094121.1160081114435152145.id@4668.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.21.0.200113
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com;
x-originating-ip: [70.31.50.95]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 54ce3f13-8405-4af3-06f3-08d7d4d39587
x-ms-traffictypediagnostic: DM6PR11MB4612:
x-microsoft-antispam-prvs: <DM6PR11MB46129EF9B5879C9B6E0DEB25ABCB0@DM6PR11MB4612.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:6430;
x-forefront-prvs: 0358535363
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3420.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(39860400002)(366004)(376002)(396003)(136003)(8676002)(8936002)(66574012)(4326008)(2616005)(81156014)(81166006)(6512007)(33656002)(64756008)(66946007)(71200400001)(2906002)(91956017)(6486002)(76116006)(66446008)(66556008)(66476007)(6506007)(478600001)(316002)(26005)(53546011)(186003)(966005)(5660300002)(86362001)(36756003); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: Fv7Q3wTYW56WSYVcuJJ2JPwiTOob+0bqyDE6G0uo44nQTIfKkNumBJorRlEbwAMrxQBd7GGlJR02eWfA2yARrQeznaR3plsU3SkCZm8xUEY3PEM81AWt/cncS6HG9awfz+Ml4kO++Vi+IcTtK+F4Emb8QMJuADLpwEBy51jk2mXgVP8acvM+7H9odHOl/8F0WhI1afQlXJbOcvms71R/BNwn9bnIJpZwOoePYBTgdK9Q5Z7YTPHKS7U7kxAHpWb3eSxBpml2K76XPmh5amtelJKgERidRcXE/C5MQ5sTo5X0s1Up72TJNyjZB2Cs5a263Ky/VhsWohW7FvUAzi56/P4R/wpbffeNZaLUWK44KBgawktZ30bjJWXwnxdBjCduytxayPhIJp+68aGTdWyLIoNxY05xl5ytOpx1Qfh6znzRoqwIogh6yPZvs9M8wKOCmJqS1BW1XrC8izYo/UIoYMe5VLq9/RI4w6zF0LESCoedf1E1ofuKhjDN+xt0dWD4bGGNM0Py7KNtHAdP/ea6Kw==
x-ms-exchange-antispam-messagedata: YlrL1Z1CIjAx8Ik0+ZGBvQCaRGUALMpKcDNQ0LprRPoDqLbXhR7ILZnxGzDBwYuZ1WUAjMqb7LMfYBONlK2IECy9yYpCaYVeBFCdVZteKWG3BaQrwUCebID+aWXXMgmnuVxiD0Cfv3e6PQRPCZ+yOg==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <16AE95CDA0F5484EBB18B42DCD633687@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 54ce3f13-8405-4af3-06f3-08d7d4d39587
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2020 17:55:50.6387 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: L385+FfWL0PZhXleFlfEZWkMag11Pir7v/5VPzGrqNzQYbLJIagZWJCfICe3vfnN51NTKqqG5lkMnIhJIJxsMw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4612
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com
X-Outbound-Node: alln-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/K1s5HgsIUwJL5dovdsJPt8VQddU>
Subject: Re: [netmod] All IETF YANG modules MUST include revision-label statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 30 Mar 2020 17:56:26 -0000
On 2020-03-28, 4:41 AM, "Martin Björklund" <mbj+ietf@4668.se> wrote: "Reshad Rahman (rrahman)" <rrahman@cisco.com> wrote: > Hi, > > https://github.com/netmod-wg/yang-ver-dt/issues/45 > > o 7.1 > > The text says: > > All IETF YANG modules MUST include revision-label statements for > all > newly published YANG modules, and all newly published revisions of > existing YANG modules. The revision-label MUST take the form of a > YANG semantic version number [I-D.verdt-netmod-yang-semver]. > > I strongly disagree with this new rule. IETF modules use a linear > history, so there are no reasons to use "modified semver". > > It is ok to use rev:nbc-changes if needed, though. > > We believe some IETF models may not follow linear history, this was > brought up (I think) for IDR. Modified semver allows for non-linear > history and also doesn't preclude linear history. So even if we end up > having no IETF modules using branching, modified semver still works. With the clarifiactions and updates in draft-verdt-netmod-yang-module-versioning, non-linear versioning works without modified semver. So there is no technical reason to use modified semver in IETF modules. So are you proposing we use some other revision-label scheme (e.g. semver 2.0.0) for IETF modules? Or that IETF modules shouldn't use revision-labels? Or do you have something else in mind? Regards, Reshad. I can reluctantly accept that modified smever is published as Experimental. But that doesn't mean that IETF modules should use it. /martin > > Regards, > Reshad. > > > On 2020-03-20, 5:08 PM, "netmod on behalf of Reshad Rahman (rrahman)" > <netmod-bounces@ietf.org on behalf of > rrahman=40cisco.com@dmarc.ietf.org> wrote: > > Hi Martin, > > We've opened issues to track your review comments (see below). Will > kick off separate therads for each issue. > > https://github.com/netmod-wg/yang-ver-dt/issues?q=is%3Aissue+is%3Aopen+label%3Aupdated-mod-rev-handling > > Regards, > Reshad. > > On 2020-03-10, 3:31 PM, "netmod on behalf of Martin Björklund" > <netmod-bounces@ietf.org on behalf of mbj+ietf@4668.se> wrote: > > Hi, > > Here are my review comments of > draft-verdt-netmod-yang-module-versioning-01. > > > > o 3.1.1 > > o In statements that have any data definition statements as > substatements, those data definition substatements MAY be > reordered, as long as they do not change the ordering or any > "rpc" > "input" substatements. > > I think this needs to capture that no descendant statements to > "input" can be reordered. Same for "output" (note, "input" and > "output" in both "rpc" and "action"). > > > o 3.3 > > All revision labels that match the pattern for the "version" > typedef in the ietf-yang-semver YANG module MUST be interpreted as > YANG semantic version numbers. > > I don't think this is a good idea. Seems like a layer violation. > What if my project use another dialect of semver, that wouldn't be > possible with this rule. I think this needs to be removed. > > > o 3.3 > > Submodules MUST NOT use revision label schemes that could be > confused > with the including module's revision label scheme. > > Hmm, how do I ensure that this MUST NOT is handled correctly? What > exactly does "could be confused with" mean? > > > o 3.3 > > In the filename of a YANG module, where it takes the form: > module- > or-submodule-name ['@' revision-label] ( '.yang' / '.yin' ) > > Should this section update 5.2 of RFC 7950? I know that 5.2 just > says "SHOULD". But existing tools implement this SHOULD, and they > need to be updated to handle this new convention. > > But I wonder if this a good idea. It means that a tool that looks > for a module with a certain revision date cannot simply check the > filenames, but need to parse all available modules (wijust to find > the > > > > o 3.4 > > leaf imperial-temperature { > type int64; > units "degrees Fahrenheit"; > status deprecated { > rev:status-description > "Imperial measurements are being phased out in favor > of their metric equivalents. Use metric-temperature > instead."; > } > description > "Temperature in degrees Fahrenheit."; > } > > I don't think rev:status-description is necessary / worth it. This > can easily be written with the normal description statement instead: > > leaf imperial-temperature { > type int64; > units "degrees Fahrenheit"; > status deprecated; > description > "Imperial measurements are being phased out in favor > of their metric equivalents. Use metric-temperature > instead. > > Temperature in degrees Fahrenheit."; > } > > > o 3.5 > > The example modules should be legal YANG modules. Use e.g. > "urn:example:module" as namespace. > > Also, the modules are missing the last "}", which confuses the > "rfcstrip" tool. > > > o 4.1.1 > > Alternatively, the first example could have used the revision > label > "1.0.0" instead, which selects the same set of revisions/versions. > > import example-module { > rev:revision-or-derived 1.0.0; > } > > Shouldn't this be s/1.0.0/2.0.0/g ? > > > o 5 > > I think the module name "ietf-yl-revisions" should be changed to > "ietf-yang-library-revisions". "yl" is not a well-known acronym. > > > o 5.2.2 > > Wouldn't it be better if the leaf "deprecated-nodes-implemented" and > "obsolete-nodes-absent" were of type "boolean" rather than type > "empty"? > > > o 7.1 > > The text says: > > All IETF YANG modules MUST include revision-label statements for > all > newly published YANG modules, and all newly published revisions of > existing YANG modules. The revision-label MUST take the form of a > YANG semantic version number [I-D.verdt-netmod-yang-semver]. > > I strongly disagree with this new rule. IETF modules use a linear > history, so there are no reasons to use "modified semver". > > It is ok to use rev:nbc-changes if needed, though. > > > o 7.1.1 > > There is a missing " in: > > 4. For status "obsolete", it is RECOMMENDED to keep the "status- > description" information, from when the node had status > "deprecated, which is still relevant. > HERE -----------^ > > > o 8 > > s/CODE ENDS>/<CODE ENDS>/ > > > o Both YANG modules > > All extensions should specify the grammar; i.e., in which statements > they can be present and which substatements they can have. > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > >
- [netmod] All IETF YANG modules MUST include revis… Reshad Rahman (rrahman)
- Re: [netmod] All IETF YANG modules MUST include r… Martin Björklund
- Re: [netmod] All IETF YANG modules MUST include r… Reshad Rahman (rrahman)
- Re: [netmod] All IETF YANG modules MUST include r… Martin Björklund
- Re: [netmod] All IETF YANG modules MUST include r… Andy Bierman
- Re: [netmod] All IETF YANG modules MUST include r… Reshad Rahman (rrahman)
- Re: [netmod] All IETF YANG modules MUST include r… Reshad Rahman (rrahman)
- Re: [netmod] All IETF YANG modules MUST include r… Martin Björklund
- Re: [netmod] All IETF YANG modules MUST include r… Andy Bierman
- Re: [netmod] All IETF YANG modules MUST include r… Sterne, Jason (Nokia - CA/Ottawa)
- Re: [netmod] All IETF YANG modules MUST include r… Sterne, Jason (Nokia - CA/Ottawa)
- Re: [netmod] All IETF YANG modules MUST include r… Martin Björklund
- Re: [netmod] All IETF YANG modules MUST include r… Sterne, Jason (Nokia - CA/Ottawa)
- Re: [netmod] All IETF YANG modules MUST include r… Reshad Rahman (rrahman)
- Re: [netmod] All IETF YANG modules MUST include r… Andy Bierman
- Re: [netmod] All IETF YANG modules MUST include r… Kent Watsen
- Re: [netmod] All IETF YANG modules MUST include r… Reshad Rahman (rrahman)
- Re: [netmod] All IETF YANG modules MUST include r… Kent Watsen
- Re: [netmod] All IETF YANG modules MUST include r… Reshad Rahman (rrahman)
- Re: [netmod] All IETF YANG modules MUST include r… Ivory, William
- Re: [netmod] All IETF YANG modules MUST include r… Rob Wilton (rwilton)
- Re: [netmod] All IETF YANG modules MUST include r… Kent Watsen
- Re: [netmod] All IETF YANG modules MUST include r… Reshad Rahman (rrahman)
- Re: [netmod] All IETF YANG modules MUST include r… Andy Bierman
- Re: [netmod] All IETF YANG modules MUST include r… Sterne, Jason (Nokia - CA/Ottawa)
- Re: [netmod] All IETF YANG modules MUST include r… Sterne, Jason (Nokia - CA/Ottawa)
- Re: [netmod] All IETF YANG modules MUST include r… Sterne, Jason (Nokia - CA/Ottawa)
- Re: [netmod] All IETF YANG modules MUST include r… Andy Bierman
- Re: [netmod] All IETF YANG modules MUST include r… tom petch
- Re: [netmod] All IETF YANG modules MUST include r… Rob Wilton (rwilton)
- Re: [netmod] All IETF YANG modules MUST include r… Rob Wilton (rwilton)