From nobody Tue Aug 1 01:46:32 2017 Return-Path: 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 CC265132C23; Tue, 1 Aug 2017 01:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 9xSO3mvBN-JD; Tue, 1 Aug 2017 01:46:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A978512EC13; Tue, 1 Aug 2017 01:46:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLR56844; Tue, 01 Aug 2017 08:46:27 +0000 (GMT) Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 1 Aug 2017 09:45:30 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Tue, 1 Aug 2017 16:45:27 +0800 From: Tianran Zhou To: "netmod@ietf.org" CC: "opsawg@ietf.org" Thread-Topic: Cross-post to Netmod for LC comments//FW: WG LC for Service Models Explained Thread-Index: AQHTCqKFiijio3W/uUKZZPsDSn27pQ== Date: Tue, 1 Aug 2017 08:45:27 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.59803FE3.0064, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4009a9bac0d8de1dd2390f4b5f6e353e Archived-At: Subject: [netmod] Cross-post to Netmod for LC comments//FW: WG LC for Service Models Explained X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 08:46:31 -0000 Hi NETMOD WG, This is a cross post for the ongoing WGLC in OPSAWG.=20 Service Models Explained https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/ Please send your comments by August 18, 2017. If you do not feel this docu= ment should advance, please state your reasons why. Regards, Tianran, OPSAWG co-chair -----Original Message----- From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Tianran Zhou Sent: Friday, July 28, 2017 11:06 AM To: opsawg@ietf.org Cc: opsawg-chairs@ietf.org Subject: [OPSAWG] WG LC for Service Models Explained Dear OPSAWG, This is a notice to start a three-week OPSAWG WG last call for the document= : Service Models Explained https://datatracker.ietf.org/doc/draft-ietf-opsawg-service-model-explained/ Please read the above draft and send any issues, comments, or corrections t= o this mailing list. Please indicate your support or concerns by Friday August 18, 2017. Authors:=20 Although this is an informational document, please indicate with an email o= n the mailing list explicitly whether you are aware or you are not aware of= any IPRs related to the drafts. Thanks, Tianran, as co-chair _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg From nobody Tue Aug 1 03:31:09 2017 Return-Path: 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 E060E131FFC; Tue, 1 Aug 2017 03:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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 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 VxFTZ33r2Q4N; Tue, 1 Aug 2017 03:31:04 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F484131FF9; Tue, 1 Aug 2017 03:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6146; q=dns/txt; s=iport; t=1501583464; x=1502793064; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sjTptGgs8sF4U4LIzzHh4/1CuwcBuW0fG3zTl93bvs0=; b=fckrIcCpigErQY9m6Cs6VCKIZ9VZx7JujyFAoRmcj+wtLSB0fYbN7Pso fTf9CmCGxyUPkW/J/pjuN5vCz/CrQfubjHsqZbvZKFhEfirFM7CAluRxI cM6TsePAt+bp54IpvUpRQW0q64p4bPx6KXF42Mhz5RP97Lw1nQrya1ZH6 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DbAAABV4BZ/4kNJK1TBAYZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDWmRtJweOB498gWyWDQ6CBCENhEpPAhqEAj8YAQIBAQEBAQE?= =?us-ascii?q?BayiFGAEBAQECAQEBGwYROgsFBwQCAQgRBAEBAQICIwMCAgIlCxQBCAgCBA4DA?= =?us-ascii?q?hSKEwgQrjKCJotOAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4IdggKBTIFhK4J?= =?us-ascii?q?7hD0DAQcLARENGIJ8MIIxBYlZlhsCh06HG4U9gg0ZhTuDeIZokSSEUgEfOH8Ld?= =?us-ascii?q?xVJEgGCcYITHBmBTkQyh36BI4EOAQEB?= X-IronPort-AV: E=Sophos;i="5.41,305,1498521600"; d="scan'208";a="277164236" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Aug 2017 10:31:03 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v71AV3H2015866 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Aug 2017 10:31:03 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 1 Aug 2017 05:31:02 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1210.000; Tue, 1 Aug 2017 05:31:02 -0500 From: "Carl Moberg (camoberg)" To: Tianran Zhou CC: "netmod@ietf.org" , "opsawg@ietf.org" Thread-Topic: [netmod] Cross-post to Netmod for LC comments//FW: WG LC for Service Models Explained Thread-Index: AQHTCqKFiijio3W/uUKZZPsDSn27paJvoT+A Date: Tue, 1 Aug 2017 10:31:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.147.40.95] Content-Type: text/plain; charset="utf-8" Content-ID: <701748482D71A140AAA69391FA2DDAA8@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Cross-post to Netmod for LC comments//FW: WG LC for Service Models Explained X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 10:31:08 -0000 VGlhbnJhbiwgT1BTQVdHLA0KDQogTm93IHRoYXQgUkZDODE5OSBpcyBwdWJsaXNoZWQsIEkgaGF2 ZSB0d28gKHNvbWV3aGF0IGFzc29jaWF0ZWQpIHBvaW50cyBvZg0KIGhpZ2gtbGV2ZWwgZmVlZGJh Y2sgb24gZHJhZnQtaWV0Zi1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQ6DQoNCiAgLSBU aGUgdGVybSDigJxOZXR3b3JrIFNlcnZpY2UgTW9kZWzigJ0gaW4gUkZDIDgxOTkgaXMgaW50ZW5k ZWQgdG8gY292ZXIgYm90aA0KICAgICJDdXN0b21lciBTZXJ2aWNlIE1vZGVs4oCdIGFzIHdlbGwg YXMg4oCcU2VydmljZSBEZWxpdmVyeSBNb2RlbOKAnSBhcyBkZWZpbmVkDQogICAgaW4gZHJhZnQt aWV0Zi1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQuIEF0IHRoZSB0aW1lIG9mIHRoZSBm aXJzdA0KICAgIHJldmlzaW9uIG9mIHdoYXQgd2FzIGRyYWZ0LWJvZ2Rhbm92aWMtbmV0bW9kLXlh bmctbW9kZWwtY2xhc3NpZmljYXRpb24NCiAgICB3ZSBkaXNjdXNzZWQgZnVydGhlciBzcGxpdHRp bmcgIk5ldHdvcmsgU2VydmljZSBNb2RlbOKAnSBpbnRvIHNtYWxsZXINCiAgICBjb21wb25lbnRz LCBidXQgZGVjaWRlZCBhZ2FpbnN0IGl0IHNpbmNlIHdlIGRpZCBub3Qgc2VlIGEgY29uc2Vuc3Vz IG9uDQogICAgd2hhdCB0aGF0IHNwbGl0IHdvdWxkIGxvb2sgbGlrZS4gSSBiZWxpZXZlIHRoZSBh dXRob3JzIGhlcmUgaXMNCiAgICBzdWdnZXN0aW5nIHN1Y2ggYSBmdXJ0aGVyIHNwbGl0Lg0KDQog ICAgVGhlcmUgaXMgb25lIHNwZWNpZmljIHBhc3NhZ2UgaW4gdGhpcyBkcmFmdCB0aGF0IEkgd291 bGQgc3VnZ2VzdCBjb3VsZA0KICAgIHVzZSByZXBocmFzaW5nIGlmIHRoZSBhdXRob3JzIGFncmVl IHRvIHRoZSBhYm92ZToNCg0KIiIiDQogICBBcyBwcmV2aW91c2x5IG5vdGVkLCBbSS1ELmlldGYt bmV0bW9kLXlhbmctbW9kZWwtY2xhc3NpZmljYXRpb25dDQogICBwcm92aWRlcyBhIGNsYXNzaWZp Y2F0aW9uIG9mIFlBTkcgZGF0YSBtb2RlbHMuICBJdCBpbnRyb2R1Y2VzIHRoZQ0KICAgdGVybSAi TmV0d29yayBTZXJ2aWNlIFlBTkcgTW9kdWxlIiB0byBpZGVudGlmeSB0aGUgdHlwZSBvZiBtb2Rl bCB1c2VkDQogICB0byAiZGVzY3JpYmUgdGhlIGNvbmZpZ3VyYXRpb24sIHN0YXRlIGRhdGEsIG9w ZXJhdGlvbnMgYW5kDQogICBub3RpZmljYXRpb25zIG9mIGFic3RyYWN0IHJlcHJlc2VudGF0aW9u cyBvZiBzZXJ2aWNlcyBpbXBsZW1lbnRlZCBvbg0KICAgb25lIG9yIG11bHRpcGxlIG5ldHdvcmsg ZWxlbWVudHMuIiAgVGhlc2UgYXJlIHNlcnZpY2UgZGVsaXZlcnkgbW9kZWxzDQogICBhcyBkZXNj cmliZWQgaW4gdGhpcyBkb2N1bWVudCwgdGhhdCBpcywgdGhleSBhcmUgdGhlIG1vZGVscyB1c2Vk IG9uDQogICB0aGUgaW50ZXJmYWNlIGJldHdlZW4gdGhlIFNlcnZpY2UgT3JjaGVzdHJhdG9yIG9y IE9TUy9CU1MgYW5kIHRoZQ0KICAgTmV0d29yayBPcmNoZXN0cmF0b3IgYXMgc2hvd24gaW4gRmln dXJlIDMuDQoiIiINCg0KIC0gQW5kIHRoaXMgZ2V0cyB0byBteSBzZWNvbmQgcG9pbnQgb2YgZmVl ZGJhY2suIEZpZ3VyZSA0LiBpbiB0aGUgZHJhZnQgc2VlbXMNCiAgIHRvIHN1Z2dlc3QgdGhhdCB0 aGUgIlNlcnZpY2UgT3JjaGVzdHJhdG9yIiBpcyBhbiBlbnRpdHkgc2VwYXJhdGUgZnJvbSB0aGUN CiAgICJPcGVyYXRpb25zIGFuZCBCdXNpbmVzcyBTdXBwb3J0IFN5c3RlbXMgKE9TUy9CU1MpIi4g QW5kIGFsc28gdGhhdA0KICAgQ3VzdG9tZXJzIChhcyBkZWZpbmVkKSBpbiBTZWN0aW9uIDIgaW50 ZXJmYWNlIGRpcmVjdGx5IHdpdGggdGhhdCBlbnRpdHkuDQogICBUaGlzIGlzIGEgdmVyeSB1bnVz dWFsIGNvbnN0cnVjdCwgaW4gdGhlIHNlbnNlIHRoYXQ6DQogICAgbyBUaGUgY29tbW9uIHRheG9u b21vbXkgZnJvbSBlLmcuIFRNRm9ydW0gd291bGQgY2xhc3NpZnkgYSBzZXJ2aWNlDQogICAgICBv cmNoZXN0cmF0b3IgYXMgYSBwYXJ0IG9mIHRoZSBPU1MvQlNTIHN0YWNrLCBzaW5jZS4uLg0KICAg IG8gVGhlIHN1Y2Nlc3NmdWwgYWN0aXZhdGlvbiBvZiBhIHNlcnZpY2UgaW5jbHVkZXMgbWFueSBw YXJ0cyBvZiB0aGUNCiAgICAgIE9TUy9CU1Mtc3RhY2sgaW5jbHVkaW5nIG9wZXJhdGlvbmFsIHJl YWRpbmVzcyAoYXJlIHRoZXJlIHBoeXNpY2FsIHBvcnRzDQogICAgICBhdmFpbGFibGUpLCBiaWxs aW5nIG1hbmFnZW1lbnQgKGlzIHRoZSBjdXN0b21lciBhbGxvd2VkIHRvIHBlcmZvcm0gZS5nLg0K ICAgICAgdGhpcyByZXNvdXJjZSBleHBhbnNpb24pLCBhbmQgYXNzdXJhbmNlIChjaGFuZ2VkIHNl cnZpY2VzIHJlcXVpcmUgbmV3DQogICAgICBhc3N1cmFuY2UgcGFyYW1ldGVycykuIFRoaXMgbWFr ZXMgaXQgaGFyZCB0byBzZXBhcmF0ZSBvdXQgYSBDdXN0b21lcg0KICAgICAgaW50ZXJmYWNlIHRv IHNlcnZpY2Ugb3JjaGVzdHJhdGlvbiBvbmx5LCBzZXBhcmF0ZSBmcm9tIHRoZSBPU1MvQlNTDQog ICAgICBzdGFjay4NCg0KIFRoaXMgYW4gaW5mb3JtYXRpb25hbCBkcmFmdCBhbmQgYXMgc3VjaCBp cyBmb3IgZ2VuZXJhbCBpbmZvcm1hdGlvbiwgYW5kIG5vdA0KIG5lY2Vzc2FyaWx5IGludGVuZGVk IHRvIHJlcHJlc2VudCBjb21tdW5pdHkgY29uc2Vuc3VzIG9yIHJlY29tbWVuZGF0aW9uLCBqdXN0 DQogbGlrZSA4MTE5LiBCdXQgSSB3b3VsZCBzdWdnZXN0IHRoZSBkb2N1bWVudCBjb3VsZCBiZSBp bXByb3ZlZCBieSBlbGFib3JhdGluZw0KIHRoZSBwb2ludCBvZiB0aGUgc2VwYXJhdGlvbiBvZiB0 aGUgb3JjaGVzdHJhdG9yIGFuZCB0aGUgQlNTL09TUyBhbmQgdGhlDQogcmVzdWx0aW5nIGRpZmZl cmVuY2UgaW4gbW9kdWxlIHR5cGVzLg0KDQotLQ0KQ2FybCBNb2JlcmcNCmNhbW9iZXJnQGNpc2Nv LmNvbQ0KDQo+IE9uIEF1ZyAxLCAyMDE3LCBhdCAxMDo0NSBBTSwgVGlhbnJhbiBaaG91IDx6aG91 dGlhbnJhbkBodWF3ZWkuY29tPiB3cm90ZToNCj4gDQo+IEhpIE5FVE1PRCBXRywNCj4gDQo+IFRo aXMgaXMgYSBjcm9zcyBwb3N0IGZvciB0aGUgb25nb2luZyBXR0xDIGluIE9QU0FXRy4gDQo+IA0K PiBTZXJ2aWNlIE1vZGVscyBFeHBsYWluZWQNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQvDQo+IA0KPiBQ bGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIGJ5IEF1Z3VzdCAxOCwgMjAxNy4gSWYgeW91IGRvIG5v dCBmZWVsIHRoaXMgIGRvY3VtZW50IHNob3VsZCBhZHZhbmNlLCBwbGVhc2Ugc3RhdGUgeW91ciBy ZWFzb25zIHdoeS4NCj4gDQo+IFJlZ2FyZHMsDQo+IFRpYW5yYW4sIE9QU0FXRyBjby1jaGFpcg0K PiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogT1BTQVdHIFttYWlsdG86 b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaWFucmFuIFpob3UNCj4gU2Vu dDogRnJpZGF5LCBKdWx5IDI4LCAyMDE3IDExOjA2IEFNDQo+IFRvOiBvcHNhd2dAaWV0Zi5vcmcN Cj4gQ2M6IG9wc2F3Zy1jaGFpcnNAaWV0Zi5vcmcNCj4gU3ViamVjdDogW09QU0FXR10gV0cgTEMg Zm9yIFNlcnZpY2UgTW9kZWxzIEV4cGxhaW5lZA0KPiANCj4gRGVhciBPUFNBV0csDQo+IA0KPiBU aGlzIGlzIGEgbm90aWNlIHRvIHN0YXJ0IGEgdGhyZWUtd2VlayBPUFNBV0cgV0cgbGFzdCBjYWxs IGZvciB0aGUgZG9jdW1lbnQ6DQo+IA0KPiBTZXJ2aWNlIE1vZGVscyBFeHBsYWluZWQNCj4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNhd2ctc2VydmljZS1t b2RlbC1leHBsYWluZWQvDQo+IA0KPiBQbGVhc2UgcmVhZCB0aGUgYWJvdmUgZHJhZnQgYW5kIHNl bmQgYW55IGlzc3VlcywgY29tbWVudHMsIG9yIGNvcnJlY3Rpb25zIHRvIHRoaXMgbWFpbGluZyBs aXN0Lg0KPiBQbGVhc2UgaW5kaWNhdGUgeW91ciBzdXBwb3J0IG9yIGNvbmNlcm5zIGJ5IEZyaWRh eSBBdWd1c3QgMTgsIDIwMTcuDQo+IA0KPiBBdXRob3JzOiANCj4gQWx0aG91Z2ggdGhpcyBpcyBh biBpbmZvcm1hdGlvbmFsIGRvY3VtZW50LCBwbGVhc2UgaW5kaWNhdGUgd2l0aCBhbiBlbWFpbCBv biB0aGUgbWFpbGluZyBsaXN0IGV4cGxpY2l0bHkgd2hldGhlciB5b3UgYXJlIGF3YXJlIG9yIHlv dSBhcmUgbm90IGF3YXJlIG9mIGFueSBJUFJzIHJlbGF0ZWQgdG8gdGhlIGRyYWZ0cy4NCj4gDQo+ IA0KPiBUaGFua3MsDQo+IFRpYW5yYW4sIGFzIGNvLWNoYWlyDQo+IA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBPUFNBV0cgbWFpbGluZyBsaXN0 DQo+IE9QU0FXR0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL29wc2F3Zw0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K From nobody Tue Aug 1 08:37:41 2017 Return-Path: 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 C932C13217B for ; Tue, 1 Aug 2017 08:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 obbVMSJUHTrD for ; Tue, 1 Aug 2017 08:37:38 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0107.outbound.protection.outlook.com [104.47.42.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C16E12EA95 for ; Tue, 1 Aug 2017 08:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rPwx/CcgViQh7Dk1qWz+6Od5S+JJgp0gX/Gipr+u2Jk=; b=dRl/VyCoJegwAAZ3unDYVruE4wIMAbwXjcPh4GVVaBoo//sHIJxTi7aV5brIWI95u9Z7Asn/3LtrZwrkxQ2lyIAvvbKEG2U9hbEU0IBEVMKE9wqePYwSQ5u+X3Y4lNLzthnOjsNTEAun+ZHe4xtgMLIlhLEsWnpL6O9f35PqaP8= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1569.namprd05.prod.outlook.com (10.161.217.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.10; Tue, 1 Aug 2017 15:37:37 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1320.010; Tue, 1 Aug 2017 15:37:37 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: accessible tree for rpcs? Thread-Index: AQHTCtwZEsEmlzSxhUeoKQkaPbrqIg== Date: Tue, 1 Aug 2017 15:37:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1569; 6:PgvFwS/HflpFVsFaDAYyQgU46hkrCNplMKyoAr/zl29kjiinjdPm05G/pqmT7WJz6zmn9edQQTSzmvZKUSp+u21ce9dB8+ZIiMtGgdI0HLpuJBzbZ38zyesuILLffO5cXi6/ro925DrYFv1Tmng3lkZxVHVdFLme07LmpTuOFqrMXCqYMYez72XGbf3akIixW0cTcuoUs8HoxNw/fqsACYgbk1MOrsAE2almzj+/Ex6olxFmtmS9qE3J/eN9HpZAZLe6BNzgt+kHDaNYR2pyB5Et88e3oou2J87AWzOTjQLtYBV/CZjhVEBR/A/FPiZjhniDtd60kLZq04vUxYKzGA==; 5:nWTNtAr365TZlXXfmHEq0dqQotmGBy4iK205wDRBiyj5RewNlVCShvxNYrbSpkxcTikMFKDdInJyYDweXAKLgBlr0YFKP8JHz0zm8SibWmzvWvYqLbvGudgoV9k/NOlHJouMhPfLCS4ugSLfdOMK+Q==; 24:/9M0mNEDr8gqzuqA5j+Q6+BK6HRPxtAjKOCEH/iIja9kF7zMm0hvbWKyfD2Z7fgd1inZZwKdq/0WNQm2iNeyKJObhQROrDdlaaCHeTQ7VSw=; 7:kSmTX+KqoaNfGpoCmCqze8wWtpI72ecRunq2tOEyvuuEQeWUtuithY6hEnGtENQzjE46dDE0rcE6itEGTZ8UJgw37Bu/Qs7wJdb1IKUAZWiMuxDA6aK2PgVXzOeki2Ag4l87UgHwEgpP0KFht7B+5W6y12l5VkcMshTWXBjRm5RRih5x3xQ4cdUgxFCV185p+aXNSFr157Gwgtr4j65ovc915qQjDCBIo4vacYrHjFY= x-ms-office365-filtering-correlation-id: dcc6cb01-b852-42ea-aa23-08d4d8f33c96 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1569; x-ms-traffictypediagnostic: BN3PR0501MB1569: x-exchange-antispam-report-test: UriScan:(158342451672863); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1569; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1569; x-forefront-prvs: 0386B406AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39850400002)(39450400003)(39410400002)(39840400002)(39860400002)(189002)(199003)(6506006)(38730400002)(110136004)(101416001)(5640700003)(7736002)(99286003)(6436002)(53936002)(6512007)(105586002)(6916009)(54356999)(50986999)(97736004)(106356001)(2351001)(86362001)(82746002)(189998001)(305945005)(36756003)(25786009)(2900100001)(8676002)(1730700003)(81166006)(81156014)(83506001)(8936002)(14454004)(33656002)(3846002)(3480700004)(6116002)(102836003)(68736007)(5660300001)(4001350100001)(66066001)(3280700002)(2906002)(6486002)(77096006)(478600001)(3660700001)(83716003)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1569; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <8E23AE42B0448C46B46A542CF621EB4D@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Aug 2017 15:37:36.9835 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1569 Archived-At: Subject: [netmod] accessible tree for rpcs? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 15:37:40 -0000 DQoNClJGQyA3OTUwLCBTNi40LjEuIChYUGF0aCBDb250ZXh0KSBzYXlzOg0KDQogICBvICBJZiB0 aGUgWFBhdGggZXhwcmVzc2lvbiBpcyBkZWZpbmVkIGluIGEgc3Vic3RhdGVtZW50IHRvIGFuICJp bnB1dCINCiAgICAgIHN0YXRlbWVudCBpbiBhbiAicnBjIiBvciAiYWN0aW9uIiBzdGF0ZW1lbnQs IHRoZSBhY2Nlc3NpYmxlIHRyZWUNCiAgICAgIGlzIHRoZSBSUEMgb3IgYWN0aW9uIG9wZXJhdGlv biBpbnN0YW5jZSwgYWxsIHN0YXRlIGRhdGEgaW4gdGhlDQogICAgICBzZXJ2ZXIsIGFuZCB0aGUg cnVubmluZyBjb25maWd1cmF0aW9uIGRhdGFzdG9yZS4gIFRoZSByb290IG5vZGUNCiAgICAgIGhh cyB0b3AtbGV2ZWwgZGF0YSBub2RlcyBpbiBhbGwgbW9kdWxlcyBhcyBjaGlsZHJlbi4NCiAgICAg IEFkZGl0aW9uYWxseSwgZm9yIGFuIFJQQywgdGhlIHJvb3Qgbm9kZSBhbHNvIGhhcyB0aGUgbm9k ZQ0KICAgICAgcmVwcmVzZW50aW5nIHRoZSBSUEMgb3BlcmF0aW9uIGJlaW5nIGRlZmluZWQgYXMg YSBjaGlsZC4gIFRoZSBub2RlDQogICAgICByZXByZXNlbnRpbmcgdGhlIG9wZXJhdGlvbiBiZWlu ZyBkZWZpbmVkIGhhcyB0aGUgb3BlcmF0aW9uJ3MgaW5wdXQNCiAgICAgIHBhcmFtZXRlcnMgYXMg Y2hpbGRyZW4uDQoNCiAgIG8gIElmIHRoZSBYUGF0aCBleHByZXNzaW9uIGlzIGRlZmluZWQgaW4g YSBzdWJzdGF0ZW1lbnQgdG8gYW4NCiAgICAgICJvdXRwdXQiIHN0YXRlbWVudCBpbiBhbiAicnBj IiBvciAiYWN0aW9uIiBzdGF0ZW1lbnQsIHRoZQ0KICAgICAgYWNjZXNzaWJsZSB0cmVlIGlzIHRo ZSBSUEMgb3IgYWN0aW9uIG9wZXJhdGlvbiBpbnN0YW5jZSwgYWxsIHN0YXRlDQogICAgICBkYXRh IGluIHRoZSBzZXJ2ZXIsIGFuZCB0aGUgcnVubmluZyBjb25maWd1cmF0aW9uIGRhdGFzdG9yZS4g IFRoZQ0KICAgICAgcm9vdCBub2RlIGhhcyB0b3AtbGV2ZWwgZGF0YSBub2RlcyBpbiBhbGwgbW9k dWxlcyBhcyBjaGlsZHJlbi4NCiAgICAgIEFkZGl0aW9uYWxseSwgZm9yIGFuIFJQQywgdGhlIHJv b3Qgbm9kZSBhbHNvIGhhcyB0aGUgbm9kZQ0KICAgICAgcmVwcmVzZW50aW5nIHRoZSBSUEMgb3Bl cmF0aW9uIGJlaW5nIGRlZmluZWQgYXMgYSBjaGlsZC4gIFRoZSBub2RlDQogICAgICByZXByZXNl bnRpbmcgdGhlIG9wZXJhdGlvbiBiZWluZyBkZWZpbmVkIGhhcyB0aGUgb3BlcmF0aW9uJ3MNCiAg ICAgIG91dHB1dCBwYXJhbWV0ZXJzIGFzIGNoaWxkcmVuLg0KDQoNCkRvZXMgaXQgbWFrZSBzZW5z ZSBmb3IgaW5wdXQvb3V0cHV0IHRvIGFjY2VzcyAiYWxsIHN0YXRlIGRhdGEgaW4gdGhlDQpzZXJ2 ZXIsIGFuZCB0aGUgcnVubmluZyBjb25maWd1cmF0aW9uIGRhdGFzdG9yZSI/ICBIb3cgd291bGQg dGhpcyBiZQ0KdXNlZD8NCg0KDQpLZW50ICAvLyBjb250cmlidXRvcg0KDQoNCg0KDQoNCg0K From nobody Tue Aug 1 16:50:49 2017 Return-Path: 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 6D338129ADD for ; Tue, 1 Aug 2017 16:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 cyDt-goDxh9w for ; Tue, 1 Aug 2017 16:50:46 -0700 (PDT) Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F04129B55 for ; Tue, 1 Aug 2017 16:50:46 -0700 (PDT) From: Alex Campbell To: Kent Watsen , "netmod@ietf.org" Thread-Topic: accessible tree for rpcs? Thread-Index: AQHTCtwZEsEmlzSxhUeoKQkaPbrqIqJwKuAP Date: Tue, 1 Aug 2017 23:50:44 +0000 Message-ID: <1501631444289.92159@Aviatnet.com> References: In-Reply-To: Accept-Language: en-NZ, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.15.6.10] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] accessible tree for rpcs? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 23:50:47 -0000 Why would it not make sense? Is your question about the datastores proposal= ?=0A= =0A= Usually an action will refer to some object that is defined as configuratio= n and/or state, and may depend on the particular properties of that object.= =0A= Here is a YANG fragment showing one possible application:=0A= =0A= list ospf-instance {=0A= config true;=0A= leaf id {type string;}=0A= leaf supports-graceful-restart {type boolean;}=0A= }=0A= =0A= rpc ospf-graceful-restart {=0A= input {=0A= leaf instance-id {type leafref {path "/ospf-instance/id";}}=0A= must "/ospf-instance[id=3Dcurrent()/instance-id]/supports-grace= ful-restart =3D 'true'" {=0A= error-message "Instance does not support graceful restart";= =0A= }=0A= }=0A= }=0A= =0A= As another application, a "mute transmitter" command might only apply to di= gital radio interfaces.=0A= =0A= Alex=0A= =0A= ________________________________________=0A= From: netmod on behalf of Kent Watsen =0A= Sent: Wednesday, 2 August 2017 3:37 a.m.=0A= To: netmod@ietf.org=0A= Subject: [netmod] accessible tree for rpcs?=0A= =0A= RFC 7950, S6.4.1. (XPath Context) says:=0A= =0A= o If the XPath expression is defined in a substatement to an "input"=0A= statement in an "rpc" or "action" statement, the accessible tree=0A= is the RPC or action operation instance, all state data in the=0A= server, and the running configuration datastore. The root node=0A= has top-level data nodes in all modules as children.=0A= Additionally, for an RPC, the root node also has the node=0A= representing the RPC operation being defined as a child. The node=0A= representing the operation being defined has the operation's input=0A= parameters as children.=0A= =0A= o If the XPath expression is defined in a substatement to an=0A= "output" statement in an "rpc" or "action" statement, the=0A= accessible tree is the RPC or action operation instance, all state=0A= data in the server, and the running configuration datastore. The=0A= root node has top-level data nodes in all modules as children.=0A= Additionally, for an RPC, the root node also has the node=0A= representing the RPC operation being defined as a child. The node=0A= representing the operation being defined has the operation's=0A= output parameters as children.=0A= =0A= =0A= Does it make sense for input/output to access "all state data in the=0A= server, and the running configuration datastore"? How would this be=0A= used?=0A= =0A= =0A= Kent // contributor=0A= =0A= =0A= =0A= =0A= =0A= =0A= _______________________________________________=0A= netmod mailing list=0A= netmod@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netmod=0A= From nobody Tue Aug 1 18:37:38 2017 Return-Path: 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 D56D9126BF3; Tue, 1 Aug 2017 18:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 b8amOlDOp1eU; Tue, 1 Aug 2017 18:37:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E8E12426E; Tue, 1 Aug 2017 18:37:26 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSN29179; Wed, 02 Aug 2017 01:37:24 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 2 Aug 2017 02:37:24 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Wed, 2 Aug 2017 09:37:17 +0800 From: Tianran Zhou To: "Carl Moberg (camoberg)" CC: "netmod@ietf.org" , "opsawg@ietf.org" Thread-Topic: [netmod] Cross-post to Netmod for LC comments//FW: WG LC for Service Models Explained Thread-Index: AQHTCqKFiijio3W/uUKZZPsDSn27paJvoT+AgACm82A= Date: Wed, 2 Aug 2017 01:37:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.156.116] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59812CD5.004F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5be9eb8e6bcf74f25c11aa298e0331df Archived-At: Subject: Re: [netmod] Cross-post to Netmod for LC comments//FW: WG LC for Service Models Explained X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 01:37:30 -0000 SGkgQ2FybCwNCg0KVGhhbmsgeW91IGZvciB0aGUgY29tbWVudHMuIEl0J3MgYSB2YWx1YWJsZSBm ZWVkYmFjayBmcm9tIHRoZSBhdXRob3Igb2YgdGhlIGFzc29jaWF0ZWQgUkZDLiANCkFsdGhvdWdo IGluZm9ybWF0aW9uYWwsIGFzIGEgd29ya2luZyBncm91cCBhY3Rpb24sIEkgaG9wZSB0aGUgZG9j dW1lbnQgY2FuIHJlcHJlc2VudCB0aGUgY29tbXVuaXR5IGNvbnNlbnN1cy4NCg0KQ2hlZXJzLA0K VGlhbnJhbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IENhcmwgTW9i ZXJnIChjYW1vYmVyZykgW21haWx0bzpjYW1vYmVyZ0BjaXNjby5jb21dDQo+IFNlbnQ6IFR1ZXNk YXksIEF1Z3VzdCAwMSwgMjAxNyA2OjMxIFBNDQo+IFRvOiBUaWFucmFuIFpob3UNCj4gQ2M6IG5l dG1vZEBpZXRmLm9yZzsgb3BzYXdnQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBD cm9zcy1wb3N0IHRvIE5ldG1vZCBmb3IgTEMgY29tbWVudHMvL0ZXOiBXRyBMQyBmb3INCj4gU2Vy dmljZSBNb2RlbHMgRXhwbGFpbmVkDQo+IA0KPiBUaWFucmFuLCBPUFNBV0csDQo+IA0KPiAgTm93 IHRoYXQgUkZDODE5OSBpcyBwdWJsaXNoZWQsIEkgaGF2ZSB0d28gKHNvbWV3aGF0IGFzc29jaWF0 ZWQpIHBvaW50cw0KPiBvZiAgaGlnaC1sZXZlbCBmZWVkYmFjayBvbiBkcmFmdC1pZXRmLW9wc2F3 Zy1zZXJ2aWNlLW1vZGVsLWV4cGxhaW5lZDoNCj4gDQo+ICAgLSBUaGUgdGVybSDigJxOZXR3b3Jr IFNlcnZpY2UgTW9kZWzigJ0gaW4gUkZDIDgxOTkgaXMgaW50ZW5kZWQgdG8gY292ZXIgYm90aA0K PiAgICAgIkN1c3RvbWVyIFNlcnZpY2UgTW9kZWzigJ0gYXMgd2VsbCBhcyDigJxTZXJ2aWNlIERl bGl2ZXJ5IE1vZGVs4oCdIGFzIGRlZmluZWQNCj4gICAgIGluIGRyYWZ0LWlldGYtb3BzYXdnLXNl cnZpY2UtbW9kZWwtZXhwbGFpbmVkLiBBdCB0aGUgdGltZSBvZiB0aGUgZmlyc3QNCj4gICAgIHJl dmlzaW9uIG9mIHdoYXQgd2FzDQo+IGRyYWZ0LWJvZ2Rhbm92aWMtbmV0bW9kLXlhbmctbW9kZWwt Y2xhc3NpZmljYXRpb24NCj4gICAgIHdlIGRpc2N1c3NlZCBmdXJ0aGVyIHNwbGl0dGluZyAiTmV0 d29yayBTZXJ2aWNlIE1vZGVs4oCdIGludG8gc21hbGxlcg0KPiAgICAgY29tcG9uZW50cywgYnV0 IGRlY2lkZWQgYWdhaW5zdCBpdCBzaW5jZSB3ZSBkaWQgbm90IHNlZSBhIGNvbnNlbnN1cyBvbg0K PiAgICAgd2hhdCB0aGF0IHNwbGl0IHdvdWxkIGxvb2sgbGlrZS4gSSBiZWxpZXZlIHRoZSBhdXRo b3JzIGhlcmUgaXMNCj4gICAgIHN1Z2dlc3Rpbmcgc3VjaCBhIGZ1cnRoZXIgc3BsaXQuDQo+IA0K PiAgICAgVGhlcmUgaXMgb25lIHNwZWNpZmljIHBhc3NhZ2UgaW4gdGhpcyBkcmFmdCB0aGF0IEkg d291bGQgc3VnZ2VzdCBjb3VsZA0KPiAgICAgdXNlIHJlcGhyYXNpbmcgaWYgdGhlIGF1dGhvcnMg YWdyZWUgdG8gdGhlIGFib3ZlOg0KPiANCj4gIiIiDQo+ICAgIEFzIHByZXZpb3VzbHkgbm90ZWQs IFtJLUQuaWV0Zi1uZXRtb2QteWFuZy1tb2RlbC1jbGFzc2lmaWNhdGlvbl0NCj4gICAgcHJvdmlk ZXMgYSBjbGFzc2lmaWNhdGlvbiBvZiBZQU5HIGRhdGEgbW9kZWxzLiAgSXQgaW50cm9kdWNlcyB0 aGUNCj4gICAgdGVybSAiTmV0d29yayBTZXJ2aWNlIFlBTkcgTW9kdWxlIiB0byBpZGVudGlmeSB0 aGUgdHlwZSBvZiBtb2RlbCB1c2VkDQo+ICAgIHRvICJkZXNjcmliZSB0aGUgY29uZmlndXJhdGlv biwgc3RhdGUgZGF0YSwgb3BlcmF0aW9ucyBhbmQNCj4gICAgbm90aWZpY2F0aW9ucyBvZiBhYnN0 cmFjdCByZXByZXNlbnRhdGlvbnMgb2Ygc2VydmljZXMgaW1wbGVtZW50ZWQgb24NCj4gICAgb25l IG9yIG11bHRpcGxlIG5ldHdvcmsgZWxlbWVudHMuIiAgVGhlc2UgYXJlIHNlcnZpY2UgZGVsaXZl cnkgbW9kZWxzDQo+ICAgIGFzIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50LCB0aGF0IGlzLCB0 aGV5IGFyZSB0aGUgbW9kZWxzIHVzZWQgb24NCj4gICAgdGhlIGludGVyZmFjZSBiZXR3ZWVuIHRo ZSBTZXJ2aWNlIE9yY2hlc3RyYXRvciBvciBPU1MvQlNTIGFuZCB0aGUNCj4gICAgTmV0d29yayBP cmNoZXN0cmF0b3IgYXMgc2hvd24gaW4gRmlndXJlIDMuDQo+ICIiIg0KPiANCj4gIC0gQW5kIHRo aXMgZ2V0cyB0byBteSBzZWNvbmQgcG9pbnQgb2YgZmVlZGJhY2suIEZpZ3VyZSA0LiBpbiB0aGUg ZHJhZnQNCj4gc2VlbXMNCj4gICAgdG8gc3VnZ2VzdCB0aGF0IHRoZSAiU2VydmljZSBPcmNoZXN0 cmF0b3IiIGlzIGFuIGVudGl0eSBzZXBhcmF0ZSBmcm9tDQo+IHRoZQ0KPiAgICAiT3BlcmF0aW9u cyBhbmQgQnVzaW5lc3MgU3VwcG9ydCBTeXN0ZW1zIChPU1MvQlNTKSIuIEFuZCBhbHNvIHRoYXQN Cj4gICAgQ3VzdG9tZXJzIChhcyBkZWZpbmVkKSBpbiBTZWN0aW9uIDIgaW50ZXJmYWNlIGRpcmVj dGx5IHdpdGggdGhhdCBlbnRpdHkuDQo+ICAgIFRoaXMgaXMgYSB2ZXJ5IHVudXN1YWwgY29uc3Ry dWN0LCBpbiB0aGUgc2Vuc2UgdGhhdDoNCj4gICAgIG8gVGhlIGNvbW1vbiB0YXhvbm9tb215IGZy b20gZS5nLiBUTUZvcnVtIHdvdWxkIGNsYXNzaWZ5IGEgc2VydmljZQ0KPiAgICAgICBvcmNoZXN0 cmF0b3IgYXMgYSBwYXJ0IG9mIHRoZSBPU1MvQlNTIHN0YWNrLCBzaW5jZS4uLg0KPiAgICAgbyBU aGUgc3VjY2Vzc2Z1bCBhY3RpdmF0aW9uIG9mIGEgc2VydmljZSBpbmNsdWRlcyBtYW55IHBhcnRz IG9mIHRoZQ0KPiAgICAgICBPU1MvQlNTLXN0YWNrIGluY2x1ZGluZyBvcGVyYXRpb25hbCByZWFk aW5lc3MgKGFyZSB0aGVyZSBwaHlzaWNhbA0KPiBwb3J0cw0KPiAgICAgICBhdmFpbGFibGUpLCBi aWxsaW5nIG1hbmFnZW1lbnQgKGlzIHRoZSBjdXN0b21lciBhbGxvd2VkIHRvIHBlcmZvcm0NCj4g ZS5nLg0KPiAgICAgICB0aGlzIHJlc291cmNlIGV4cGFuc2lvbiksIGFuZCBhc3N1cmFuY2UgKGNo YW5nZWQgc2VydmljZXMgcmVxdWlyZSBuZXcNCj4gICAgICAgYXNzdXJhbmNlIHBhcmFtZXRlcnMp LiBUaGlzIG1ha2VzIGl0IGhhcmQgdG8gc2VwYXJhdGUgb3V0IGEgQ3VzdG9tZXINCj4gICAgICAg aW50ZXJmYWNlIHRvIHNlcnZpY2Ugb3JjaGVzdHJhdGlvbiBvbmx5LCBzZXBhcmF0ZSBmcm9tIHRo ZSBPU1MvQlNTDQo+ICAgICAgIHN0YWNrLg0KPiANCj4gIFRoaXMgYW4gaW5mb3JtYXRpb25hbCBk cmFmdCBhbmQgYXMgc3VjaCBpcyBmb3IgZ2VuZXJhbCBpbmZvcm1hdGlvbiwgYW5kDQo+IG5vdCAg bmVjZXNzYXJpbHkgaW50ZW5kZWQgdG8gcmVwcmVzZW50IGNvbW11bml0eSBjb25zZW5zdXMgb3IN Cj4gcmVjb21tZW5kYXRpb24sIGp1c3QgIGxpa2UgODExOS4gQnV0IEkgd291bGQgc3VnZ2VzdCB0 aGUgZG9jdW1lbnQgY291bGQgYmUNCj4gaW1wcm92ZWQgYnkgZWxhYm9yYXRpbmcgIHRoZSBwb2lu dCBvZiB0aGUgc2VwYXJhdGlvbiBvZiB0aGUgb3JjaGVzdHJhdG9yDQo+IGFuZCB0aGUgQlNTL09T UyBhbmQgdGhlICByZXN1bHRpbmcgZGlmZmVyZW5jZSBpbiBtb2R1bGUgdHlwZXMuDQo+IA0KPiAt LQ0KPiBDYXJsIE1vYmVyZw0KPiBjYW1vYmVyZ0BjaXNjby5jb20NCj4gDQo+ID4gT24gQXVnIDEs IDIwMTcsIGF0IDEwOjQ1IEFNLCBUaWFucmFuIFpob3UgPHpob3V0aWFucmFuQGh1YXdlaS5jb20+ IHdyb3RlOg0KPiA+DQo+ID4gSGkgTkVUTU9EIFdHLA0KPiA+DQo+ID4gVGhpcyBpcyBhIGNyb3Nz IHBvc3QgZm9yIHRoZSBvbmdvaW5nIFdHTEMgaW4gT1BTQVdHLg0KPiA+DQo+ID4gU2VydmljZSBN b2RlbHMgRXhwbGFpbmVkDQo+ID4NCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYQ0KPiA+IGluZWQvDQo+ID4NCj4g PiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIGJ5IEF1Z3VzdCAxOCwgMjAxNy4gSWYgeW91IGRv IG5vdCBmZWVsIHRoaXMNCj4gZG9jdW1lbnQgc2hvdWxkIGFkdmFuY2UsIHBsZWFzZSBzdGF0ZSB5 b3VyIHJlYXNvbnMgd2h5Lg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPiBUaWFucmFuLCBPUFNBV0cg Y28tY2hhaXINCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTog T1BTQVdHIFttYWlsdG86b3BzYXdnLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaWFu cmFuDQo+ID4gWmhvdQ0KPiA+IFNlbnQ6IEZyaWRheSwgSnVseSAyOCwgMjAxNyAxMTowNiBBTQ0K PiA+IFRvOiBvcHNhd2dAaWV0Zi5vcmcNCj4gPiBDYzogb3BzYXdnLWNoYWlyc0BpZXRmLm9yZw0K PiA+IFN1YmplY3Q6IFtPUFNBV0ddIFdHIExDIGZvciBTZXJ2aWNlIE1vZGVscyBFeHBsYWluZWQN Cj4gPg0KPiA+IERlYXIgT1BTQVdHLA0KPiA+DQo+ID4gVGhpcyBpcyBhIG5vdGljZSB0byBzdGFy dCBhIHRocmVlLXdlZWsgT1BTQVdHIFdHIGxhc3QgY2FsbCBmb3IgdGhlIGRvY3VtZW50Og0KPiA+ DQo+ID4gU2VydmljZSBNb2RlbHMgRXhwbGFpbmVkDQo+ID4NCj4gaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYQ0KPiA+ IGluZWQvDQo+ID4NCj4gPiBQbGVhc2UgcmVhZCB0aGUgYWJvdmUgZHJhZnQgYW5kIHNlbmQgYW55 IGlzc3VlcywgY29tbWVudHMsIG9yIGNvcnJlY3Rpb25zDQo+IHRvIHRoaXMgbWFpbGluZyBsaXN0 Lg0KPiA+IFBsZWFzZSBpbmRpY2F0ZSB5b3VyIHN1cHBvcnQgb3IgY29uY2VybnMgYnkgRnJpZGF5 IEF1Z3VzdCAxOCwgMjAxNy4NCj4gPg0KPiA+IEF1dGhvcnM6DQo+ID4gQWx0aG91Z2ggdGhpcyBp cyBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50LCBwbGVhc2UgaW5kaWNhdGUgd2l0aCBhbiBlbWFp bA0KPiBvbiB0aGUgbWFpbGluZyBsaXN0IGV4cGxpY2l0bHkgd2hldGhlciB5b3UgYXJlIGF3YXJl IG9yIHlvdSBhcmUgbm90IGF3YXJlDQo+IG9mIGFueSBJUFJzIHJlbGF0ZWQgdG8gdGhlIGRyYWZ0 cy4NCj4gPg0KPiA+DQo+ID4gVGhhbmtzLA0KPiA+IFRpYW5yYW4sIGFzIGNvLWNoYWlyDQo+ID4N Cj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ IE9QU0FXRyBtYWlsaW5nIGxpc3QNCj4gPiBPUFNBV0dAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL29wc2F3Zw0KPiA+DQo+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBuZXRtb2QgbWFpbGluZyBs aXN0DQo+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2QNCg0K From nobody Wed Aug 2 03:29:14 2017 Return-Path: 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 56C08131EAA; Wed, 2 Aug 2017 03:29:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 C3SFrzHp_yyr; Wed, 2 Aug 2017 03:29:05 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3F04126C23; Wed, 2 Aug 2017 03:29:04 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v72ASsC3005760; Wed, 2 Aug 2017 11:28:54 +0100 Received: from 950129200 (25.70.114.87.dyn.plus.net [87.114.70.25]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v72ASmmX005678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Aug 2017 11:28:53 +0100 Reply-To: From: "Adrian Farrel" To: "'Tianran Zhou'" , "'Carl Moberg \(camoberg\)'" Cc: , References: In-Reply-To: Date: Wed, 2 Aug 2017 11:28:47 +0100 Message-ID: <01ca01d30b7a$24525ed0$6cf71c70$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHbAW31o9HwWBByTtTCkleEadoDZAGGyjiIAVq6DN+iSYZtgA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23232.006 X-TM-AS-Result: No--13.096-10.0-31-10 X-imss-scan-details: No--13.096-10.0-31-10 X-TMASE-MatchedRID: qsaWi0FWcYs4HKI/yaqRm8WUKBjERoYToUj+E6Ep7aJZps+y1VXzqeoP UWMnzVTmhl8BhrTenAn+5Tu3wgSyXHKzRQDC+n78j2FGM19l45fRahuPwaQ1Wmnf+v+Bv9DlWki Dtk1XHnVq4rFfCHYg9gzLDqEyu1hQkfLugziW86ezI1v7J4hECiFq4bKNOR/1PcFkClcmQNs+mZ LuHsKcOhQw4NetPOmNgXAwpNBCV1nmYx6DxF+ydUYmcTlfI8c1fkuZtv/FS5oahchoz+8vwvPxq 4CDAAaNg9gsQPN4r+3DRpsDfF9TvZ+/3E8wlr+DuIwLnB3Aqp2b/LTS0T1K1t02EDYL8YqmUS35 4uMGPVEqBq00VTznlULvrzj8lAWotemwkGxPacZMcRwauwQkhEbbuL7Y47c0Rxay6zLLCxgtjYL FZ2xmSlRHcqR3jRqp2xd9EQ8Wt0643QBcEf+g8X7siEtWY367UXlp1FHYSPVMpKclxGaCEdiz8u jSyOkYrTKkwsUc4lekn61ttGqIDY39U4x946BX+mHRL3uzOiJA8JZETQujwkYX5kyNXpCIp83IW P6+nSaeTJ2KWImGZ8NXbe00kNLgi8ICQO6ibxRx+x1f5juFEwvWQayvnHh3ClyrX4tOmxSjxYyR Ba/qJaEwgORH8p/AjaPj0W1qn0Q7AFczfjr/7Ay/OSZuzy1aOJkGXgCZnPLeq5Xw5DFhKvPiRVT 7GOosaahJTKV0sNo= Archived-At: Subject: Re: [netmod] [OPSAWG] Cross-post to Netmod for LC comments//FW: WG LC for Service Models Explained X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 10:29:06 -0000 Hi Carl, > - The term =E2=80=9CNetwork Service Model=E2=80=9D in RFC 8199 is = intended to cover both > "Customer Service Model=E2=80=9D as well as =E2=80=9CService = Delivery Model=E2=80=9D as defined > in draft-ietf-opsawg-service-model-explained. At the time of the = first > revision of what was > draft-bogdanovic-netmod-yang-model-classification > we discussed further splitting "Network Service Model=E2=80=9D = into smaller > components, but decided against it since we did not see a = consensus on > what that split would look like. I believe the authors here is > suggesting such a further split. I think that an "issue" with RFC 8199 is that is appears to imply that = the "Network Service Module" (sic) it defines is used on a specific = interface rather than simply being the classification of "all modules = used north of this point". This our draft is doing slightly more than = partitioning the classification. The last couple of rounds of edits to = what became 8199 were working with Dean to slightly soften thee language = used to make this more consistent. But see below... > There is one specific passage in this draft that I would suggest = could > use rephrasing if the authors agree to the above: > > """ > As previously noted, [I-D.ietf-netmod-yang-model-classification] > provides a classification of YANG data models. It introduces the > term "Network Service YANG Module" to identify the type of model = used > to "describe the configuration, state data, operations and > notifications of abstract representations of services implemented = on > one or multiple network elements." These are service delivery = models > as described in this document, that is, they are the models used on > the interface between the Service Orchestrator or OSS/BSS and the > Network Orchestrator as shown in Figure 3. > """ You suggest this could be rephrased, but don't suggest how:-) I just checked 8199 and I see that the quote we have is still accurate. I am wondering what it is specifically about this text that worries you. = Again, this may come back to the use of a module on a functional = interface. I read 8199 as saying that the "Network Service YANG Modules = are used by the OSS/BSS in talking to the network elements (o perhaps = Controllers?) to configure the network to deliver the service. Am I = wrong? If I'm right in my reading we are not "splitting" the classification, = but introducing a new class that lives further north (where the = atmosphere is thinner and the temperature colder) > - And this gets to my second point of feedback. Figure 4. in the = draft > seems to suggest that the "Service Orchestrator" is an entity = separate > from the "Operations and Business Support Systems (OSS/BSS)". I want to jump into this paragraph at once just to say "no, no, no!" This figure (like most I draw in ASCII these days) displays functional = components not physical entities. How you choose to implement is entirely up to you. It seems likely (to me) that the interface between customer and operator = is externally exposed (but not necessarily realised using RESTconf). It does not seem obvious to me that the Service Orchestrator and the = OSS/BSS are separate blobs, except to note that the OSS/BSS deployed = today does not support the Customer Service YANG Modules and so the = extent to which it provides "service orchestration" is limited. I might also claim that an OSS/BSS possibly operates on a single network = where the orchestration of a service *might* involve the coordination of = more than one network. > And also that > Customers (as defined) in Section 2 interface directly with that = entity. > This is a very unusual construct, in the sense that: > o The common taxonomomy from e.g. TMForum would classify a service > orchestrator as a part of the OSS/BSS stack, since... > o The successful activation of a service includes many parts of = the > OSS/BSS-stack including operational readiness (are there = physical > ports available), billing management (is the customer allowed to = > perform e.g. this resource expansion), and assurance (changed > services require new assurance parameters). This makes it hard > to separate out a Customer interface to service orchestration > only, separate from the OSS/BSS stack. I am not (overly) familiar with the TMF work, however, your text = "TMForum would classify a service orchestrator as a part of the OSS/BSS = stack" suggests the acceptance of service orchestration as "a thing". If = you were writing code, you *might* write a separate module (even = library) to handle service orchestration, and maintain that as a = separate module from billing management, etc. That does not make them = completely separate, but does result in them showing as separate = functional components in the "OSS/BSS stack." > This an informational draft and as such is for general information, = and > not necessarily intended to represent community consensus or > recommendation, just like 8119. I choose to disagree! 8199 had WG and IETF last call. It has community = consensus. The intention of this draft is that it, too, will have IETF community = consensus. But be aware that we are neither trying to force that consensus, nor = dictate the terminology. What we are doing is trying to answer the = (often repeated) question: "Where do L2SM and L3SM fit into the picture = since they don't seem to be intended to talk to network devices or = controllers?" > But I would suggest the document could be > improved by elaborating the point of the separation of the = orchestrator > and the BSS/OSS and the resulting difference in module types. I could certainly add text around Figure 4 to say "...this illustrates a = functional architecture and an implementation might not choose to make = the distinctions shown such that separations and interfaces illustrated = might fall within a single implementation." Would that help? Many thanks, Adrian From nobody Wed Aug 2 04:35:56 2017 Return-Path: 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 79792131EBA; Wed, 2 Aug 2017 04:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 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 opnMBebqRpSG; Wed, 2 Aug 2017 04:35:53 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F5B8120227; Wed, 2 Aug 2017 04:35:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13962; q=dns/txt; s=iport; t=1501673753; x=1502883353; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=RrzjLABJDCs+tT98jK1Jwf2ghCuybqx0aF0aVLP+N4g=; b=lHYo6gWEoK97Dtrxt4EqVZZ6CKU+2D14D2Yu7RkhZmDzQouMeOjh7DYU XaIRqmxEV0+B9pazEE4X8X+rK+0c7z2v4OUOzj41gWi2aFlLiQN7g6Lok xE47otQcHZflAAtxg1FJb7HgmabS16C2TF0ZslqqUXS/D/yHwxgRxADsr Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DDAACMuIFZ/5hdJa1TBAYZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDWoFRJweOB5ACgW6WEA6CBIVHAhqEGT8YAQIBAQEBAQEBax0?= =?us-ascii?q?LhRgBAQEBAgEjEUUFCwIBCBIGAgImAgICMBUCDgIEDgMCFIoTCK1MgiaLTQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEfgQuCHYICgUyBYyuCfIQ/AQEHBAcBEQ2DFDCCMQW?= =?us-ascii?q?JWRMFlgsCiF6CP4kNgg2JToZpkSgVhD0BHzh/C3cVWwGCcYITHBmBTkQyhywPF?= =?us-ascii?q?4EMgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,311,1498521600"; d="scan'208";a="277661254" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Aug 2017 11:35:52 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v72BZqH2030846 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 2 Aug 2017 11:35:52 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 2 Aug 2017 06:35:51 -0500 Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1210.000; Wed, 2 Aug 2017 06:35:51 -0500 From: "Carl Moberg (camoberg)" To: "adrian@olddog.co.uk" CC: Tianran Zhou , "opsawg@ietf.org" , "netmod@ietf.org" Thread-Topic: [OPSAWG] [netmod] Cross-post to Netmod for LC comments//FW: WG LC for Service Models Explained Thread-Index: AQHTCqKFiijio3W/uUKZZPsDSn27paJvoT+AgACm82CAAOqagIAAEr2A Date: Wed, 2 Aug 2017 11:35:51 +0000 Message-ID: <3AF5CE83-3B4C-4C5C-A79C-C54589F95A58@cisco.com> References: <01ca01d30b7a$24525ed0$6cf71c70$@olddog.co.uk> In-Reply-To: <01ca01d30b7a$24525ed0$6cf71c70$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.147.40.84] Content-Type: text/plain; charset="utf-8" Content-ID: <762885144285274EA4396A9DDC2BDCDC@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] [OPSAWG] Cross-post to Netmod for LC comments//FW: WG LC for Service Models Explained X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 11:35:55 -0000 QWRyaWFuLA0KDQo+IE9uIEF1ZyAyLCAyMDE3LCBhdCAxMjoyOCBQTSwgQWRyaWFuIEZhcnJlbCA8 YWRyaWFuQG9sZGRvZy5jby51az4gd3JvdGU6DQo+IA0KPiBIaSBDYXJsLA0KPiANCj4+ICAtIFRo ZSB0ZXJtIOKAnE5ldHdvcmsgU2VydmljZSBNb2RlbOKAnSBpbiBSRkMgODE5OSBpcyBpbnRlbmRl ZCB0byBjb3ZlciBib3RoDQo+PiAgICAiQ3VzdG9tZXIgU2VydmljZSBNb2RlbOKAnSBhcyB3ZWxs IGFzIOKAnFNlcnZpY2UgRGVsaXZlcnkgTW9kZWzigJ0gYXMgZGVmaW5lZA0KPj4gICAgaW4gZHJh ZnQtaWV0Zi1vcHNhd2ctc2VydmljZS1tb2RlbC1leHBsYWluZWQuIEF0IHRoZSB0aW1lIG9mIHRo ZSBmaXJzdA0KPj4gICAgcmV2aXNpb24gb2Ygd2hhdCB3YXMNCj4+IGRyYWZ0LWJvZ2Rhbm92aWMt bmV0bW9kLXlhbmctbW9kZWwtY2xhc3NpZmljYXRpb24NCj4+ICAgIHdlIGRpc2N1c3NlZCBmdXJ0 aGVyIHNwbGl0dGluZyAiTmV0d29yayBTZXJ2aWNlIE1vZGVs4oCdIGludG8gc21hbGxlcg0KPj4g ICAgY29tcG9uZW50cywgYnV0IGRlY2lkZWQgYWdhaW5zdCBpdCBzaW5jZSB3ZSBkaWQgbm90IHNl ZSBhIGNvbnNlbnN1cyBvbg0KPj4gICAgd2hhdCB0aGF0IHNwbGl0IHdvdWxkIGxvb2sgbGlrZS4g SSBiZWxpZXZlIHRoZSBhdXRob3JzIGhlcmUgaXMNCj4+ICAgIHN1Z2dlc3Rpbmcgc3VjaCBhIGZ1 cnRoZXIgc3BsaXQuDQo+IA0KPiBJIHRoaW5rIHRoYXQgYW4gImlzc3VlIiB3aXRoIFJGQyA4MTk5 IGlzIHRoYXQgaXMgYXBwZWFycyB0byBpbXBseSB0aGF0IHRoZSAiTmV0d29yayBTZXJ2aWNlIE1v ZHVsZSIgKHNpYykgaXQgZGVmaW5lcyBpcyB1c2VkIG9uIGEgc3BlY2lmaWMgaW50ZXJmYWNlIHJh dGhlciB0aGFuIHNpbXBseSBiZWluZyB0aGUgY2xhc3NpZmljYXRpb24gb2YgImFsbCBtb2R1bGVz IHVzZWQgbm9ydGggb2YgdGhpcyBwb2ludCIuIFRoaXMgb3VyIGRyYWZ0IGlzIGRvaW5nIHNsaWdo dGx5IG1vcmUgdGhhbiBwYXJ0aXRpb25pbmcgdGhlIGNsYXNzaWZpY2F0aW9uLiBUaGUgbGFzdCBj b3VwbGUgb2Ygcm91bmRzIG9mIGVkaXRzIHRvIHdoYXQgYmVjYW1lIDgxOTkgd2VyZSB3b3JraW5n IHdpdGggRGVhbiB0byBzbGlnaHRseSBzb2Z0ZW4gdGhlZSBsYW5ndWFnZSB1c2VkIHRvIG1ha2Ug dGhpcyBtb3JlIGNvbnNpc3RlbnQuDQoNCiBSaWdodCwgYW5kIHRoZSByZWFzb24gd2h5IHdlIHRv b2sgdGhlICJhbGwgbW9kdWxlcyB1c2VkIG5vcnRoIG9mIHRoaXMgcG9pbnTigJ0gaXMgdGhhdCB3 ZSBoYXZlIG5vdCBzZWVuIGFueSBzaWduIG9mIGNvbnZlcmdlbmNlIGFyb3VuZCBhYnN0cmFjdGlv bnMgaW50byBzbWFsbGVyIGNvbXBvbmVudHMuIEluIHNob3J0OiBpbXBsZW1lbnRhdGlvbnMgb2Yg 4oCcWUFORyBmb3Igc2VydmljZXPigJ0gaXMgY3VycmVudGx5IGFsbCBvdmVyIHRoZSBtYXAuDQoN Cj4gQnV0IHNlZSBiZWxvdy4uLg0KPiANCj4+ICAgIFRoZXJlIGlzIG9uZSBzcGVjaWZpYyBwYXNz YWdlIGluIHRoaXMgZHJhZnQgdGhhdCBJIHdvdWxkIHN1Z2dlc3QgY291bGQNCj4+ICAgIHVzZSBy ZXBocmFzaW5nIGlmIHRoZSBhdXRob3JzIGFncmVlIHRvIHRoZSBhYm92ZToNCj4+IA0KPj4gIiIi DQo+PiAgIEFzIHByZXZpb3VzbHkgbm90ZWQsIFtJLUQuaWV0Zi1uZXRtb2QteWFuZy1tb2RlbC1j bGFzc2lmaWNhdGlvbl0NCj4+ICAgcHJvdmlkZXMgYSBjbGFzc2lmaWNhdGlvbiBvZiBZQU5HIGRh dGEgbW9kZWxzLiAgSXQgaW50cm9kdWNlcyB0aGUNCj4+ICAgdGVybSAiTmV0d29yayBTZXJ2aWNl IFlBTkcgTW9kdWxlIiB0byBpZGVudGlmeSB0aGUgdHlwZSBvZiBtb2RlbCB1c2VkDQo+PiAgIHRv ICJkZXNjcmliZSB0aGUgY29uZmlndXJhdGlvbiwgc3RhdGUgZGF0YSwgb3BlcmF0aW9ucyBhbmQN Cj4+ICAgbm90aWZpY2F0aW9ucyBvZiBhYnN0cmFjdCByZXByZXNlbnRhdGlvbnMgb2Ygc2Vydmlj ZXMgaW1wbGVtZW50ZWQgb24NCj4+ICAgb25lIG9yIG11bHRpcGxlIG5ldHdvcmsgZWxlbWVudHMu IiAgVGhlc2UgYXJlIHNlcnZpY2UgZGVsaXZlcnkgbW9kZWxzDQo+PiAgIGFzIGRlc2NyaWJlZCBp biB0aGlzIGRvY3VtZW50LCB0aGF0IGlzLCB0aGV5IGFyZSB0aGUgbW9kZWxzIHVzZWQgb24NCj4+ ICAgdGhlIGludGVyZmFjZSBiZXR3ZWVuIHRoZSBTZXJ2aWNlIE9yY2hlc3RyYXRvciBvciBPU1Mv QlNTIGFuZCB0aGUNCj4+ICAgTmV0d29yayBPcmNoZXN0cmF0b3IgYXMgc2hvd24gaW4gRmlndXJl IDMuDQo+PiAiIiINCj4gDQo+IFlvdSBzdWdnZXN0IHRoaXMgY291bGQgYmUgcmVwaHJhc2VkLCBi dXQgZG9uJ3Qgc3VnZ2VzdCBob3c6LSkNCj4gSSBqdXN0IGNoZWNrZWQgODE5OSBhbmQgSSBzZWUg dGhhdCB0aGUgcXVvdGUgd2UgaGF2ZSBpcyBzdGlsbCBhY2N1cmF0ZS4NCj4gDQo+IEkgYW0gd29u ZGVyaW5nIHdoYXQgaXQgaXMgc3BlY2lmaWNhbGx5IGFib3V0IHRoaXMgdGV4dCB0aGF0IHdvcnJp ZXMgeW91LiBBZ2FpbiwgdGhpcyBtYXkgY29tZSBiYWNrIHRvIHRoZSB1c2Ugb2YgYSBtb2R1bGUg b24gYSBmdW5jdGlvbmFsIGludGVyZmFjZS4gSSByZWFkIDgxOTkgYXMgc2F5aW5nIHRoYXQgdGhl ICJOZXR3b3JrIFNlcnZpY2UgWUFORyBNb2R1bGVzIGFyZSB1c2VkIGJ5IHRoZSBPU1MvQlNTIGlu IHRhbGtpbmcgdG8gdGhlIG5ldHdvcmsgZWxlbWVudHMgKG8gcGVyaGFwcyBDb250cm9sbGVycz8p IHRvIGNvbmZpZ3VyZSB0aGUgbmV0d29yayB0byBkZWxpdmVyIHRoZSBzZXJ2aWNlLiBBbSBJIHdy b25nPw0KPiANCj4gSWYgSSdtIHJpZ2h0IGluIG15IHJlYWRpbmcgd2UgYXJlIG5vdCAic3BsaXR0 aW5nIiB0aGUgY2xhc3NpZmljYXRpb24sIGJ1dCBpbnRyb2R1Y2luZyBhIG5ldyBjbGFzcyB0aGF0 IGxpdmVzIGZ1cnRoZXIgbm9ydGggKHdoZXJlIHRoZSBhdG1vc3BoZXJlIGlzIHRoaW5uZXIgYW5k IHRoZSB0ZW1wZXJhdHVyZSBjb2xkZXIpDQoNCiBJIHRoaW5rIGF0IHRoZSBjb3JlIG9mIHRoZSBm ZWVkYmFjayAoYW5kIHNvcnJ5IHRoYXQgaXQgdG9vayB0d28gcm91bmRzIG9mIGVtYWlsIHRvIG1h a2UgaXQgc2hvcnRlciA6LSkgaXMgdGhhdCBpbiA4MTk5IHRoZSBTZXJ2aWNlIE9yY2hlc3RyYXRv ciBpcyBhc3N1bWVkIHRvIGJlIGFuIGludGVncmFsIHBhcnQgb2YgT1NTL0JTUy4gTW9yZSBiZWxv dy4NCg0KPj4gLSBBbmQgdGhpcyBnZXRzIHRvIG15IHNlY29uZCBwb2ludCBvZiBmZWVkYmFjay4g RmlndXJlIDQuIGluIHRoZSBkcmFmdA0KPj4gICBzZWVtcyB0byBzdWdnZXN0IHRoYXQgdGhlICJT ZXJ2aWNlIE9yY2hlc3RyYXRvciIgaXMgYW4gZW50aXR5IHNlcGFyYXRlDQo+PiAgIGZyb20gdGhl ICJPcGVyYXRpb25zIGFuZCBCdXNpbmVzcyBTdXBwb3J0IFN5c3RlbXMgKE9TUy9CU1MpIi4NCj4g DQo+IEkgd2FudCB0byBqdW1wIGludG8gdGhpcyBwYXJhZ3JhcGggYXQgb25jZSBqdXN0IHRvIHNh eSAibm8sIG5vLCBubyEiDQo+IFRoaXMgZmlndXJlIChsaWtlIG1vc3QgSSBkcmF3IGluIEFTQ0lJ IHRoZXNlIGRheXMpIGRpc3BsYXlzIGZ1bmN0aW9uYWwgY29tcG9uZW50cyBub3QgcGh5c2ljYWwg ZW50aXRpZXMuDQo+IEhvdyB5b3UgY2hvb3NlIHRvIGltcGxlbWVudCBpcyBlbnRpcmVseSB1cCB0 byB5b3UuDQo+IEl0IHNlZW1zIGxpa2VseSAodG8gbWUpIHRoYXQgdGhlIGludGVyZmFjZSBiZXR3 ZWVuIGN1c3RvbWVyIGFuZCBvcGVyYXRvciBpcyBleHRlcm5hbGx5IGV4cG9zZWQgKGJ1dCBub3Qg bmVjZXNzYXJpbHkgcmVhbGlzZWQgdXNpbmcgUkVTVGNvbmYpLg0KDQogVGhpcyBpcyBwZXJoYXBz IGFsc28gYXQgdGhlIGNvcmUgb2YgdGhlIGZlZWRiYWNrLiBJIGhhdmUgbmV2ZXIgc2VlbiBhbiBp bXBsZW1lbnRhdGlvbi9hcmNoaXRlY3R1cmUgd2l0aCBhIGZ1bmN0aW9uYWxseSBkaXN0aW5jdCBT ZXJ2aWNlIE9yY2hlc3RyYXRvciAob3V0c2lkZSBvZiBPU1MvQlNTKSBleHBvc2VkIGRpcmVjdGx5 IHRvIGN1c3RvbWVycy4gVGhlcmUgaXMgdXN1YWxseSBhdCBsZWFzdCBzb21ldGhpbmcgbGlrZSBh biBvcmRlciBtYW5hZ2VyIChhcyBwYXJ0IG9mIHRoZSBPU1MvQlNTKSBiZXR3ZWVuIHRoZSBjdXN0 b21lciBhbmQgdGhlIHNlcnZpY2Ugb3JjaGVzdHJhdG9yLiBFdmVuIGluIHRoZSBpbnN0YW5jZXMg b2Ygc2VsZi1zZXJ2aWNlIHBvcnRhbHMgKHdoaWNoIGFyZSBuYXR1cmFsbHkgbG9jYXRlZCB2ZXJ5 IGNsb3NlIHRvIHRoZSBuZXR3b3JrKSB0aGVyZSBpcyBhdCBsZWFzdCBzb21lIG5vdGlvbiBvZiBw cmljaW5nIGFuZCBiaWxsaW5nIGludm9sdmVkLg0KDQo+IEl0IGRvZXMgbm90IHNlZW0gb2J2aW91 cyB0byBtZSB0aGF0IHRoZSBTZXJ2aWNlIE9yY2hlc3RyYXRvciBhbmQgdGhlIE9TUy9CU1MgYXJl IHNlcGFyYXRlIGJsb2JzLCBleGNlcHQgdG8gbm90ZSB0aGF0IHRoZSBPU1MvQlNTIGRlcGxveWVk IHRvZGF5IGRvZXMgbm90IHN1cHBvcnQgdGhlIEN1c3RvbWVyIFNlcnZpY2UgWUFORyBNb2R1bGVz IGFuZCBzbyB0aGUgZXh0ZW50IHRvIHdoaWNoIGl0IHByb3ZpZGVzICJzZXJ2aWNlIG9yY2hlc3Ry YXRpb24iIGlzIGxpbWl0ZWQuDQoNCiBXZWxsLCBhIGNvbW1vbiBwYXR0ZXJuIGlzIHRvIGhhdmUg dGhlIG9yZGVyIG1hbmFnZXIgcHV0IGluIG9yZGVycyBmb3IgdGVjaG5pY2FsIHNlcnZpY2UgYWN0 aXZhdGlvbiBmcm9tIGEgc2VydmljZSBvcmNoZXN0cmF0b3IuIFRoZSB1cHRha2Ugb2YgWUFORyBz ZWVtcyB0byBiZSBtb3N0bHkgaW4gdGhlIGludGVyZmFjZSBiZXR3ZWVuIHRoZSBvcmRlciBtYW5h Z2VyIChhbiBpbnRlZ3JhbCBwYXJ0IG9mIE9TUy9CU1MpIGFuZCB0aGUgc2VydmljZSBvcmNoZXN0 cmF0b3IuDQoNCj4gSSBtaWdodCBhbHNvIGNsYWltIHRoYXQgYW4gT1NTL0JTUyBwb3NzaWJseSBv cGVyYXRlcyBvbiBhIHNpbmdsZSBuZXR3b3JrIHdoZXJlIHRoZSBvcmNoZXN0cmF0aW9uIG9mIGEg c2VydmljZSAqbWlnaHQqIGludm9sdmUgdGhlIGNvb3JkaW5hdGlvbiBvZiBtb3JlIHRoYW4gb25l IG5ldHdvcmsuDQoNCiBIbW0sIHNpbmNlIHRoZSBhY3R1YWwgYnVzaW5lc3MgaXMgYWNjb3VudGVk IGZvciBpbiB0aGUgT1NTL0JTUyAoaW5jbHVkaW5nIHJhdGluZywgY2hhcmdpbmcsIGJpbGxpbmcp IEnigJltIG5vdCBzdXJlIGhvdyBhIG11bHRpLW5ldHdvcmsgc2VydmljZSBvcmNoZXN0cmF0b3Ig b3V0c2lkZSBvZiBhbiBPU1MvQlNTIGNvbnRleHQgd291bGQgd29yay4NCg0KPj4gQW5kIGFsc28g dGhhdA0KPj4gICBDdXN0b21lcnMgKGFzIGRlZmluZWQpIGluIFNlY3Rpb24gMiBpbnRlcmZhY2Ug ZGlyZWN0bHkgd2l0aCB0aGF0IGVudGl0eS4NCj4+ICAgVGhpcyBpcyBhIHZlcnkgdW51c3VhbCBj b25zdHJ1Y3QsIGluIHRoZSBzZW5zZSB0aGF0Og0KPj4gICAgbyBUaGUgY29tbW9uIHRheG9ub21v bXkgZnJvbSBlLmcuIFRNRm9ydW0gd291bGQgY2xhc3NpZnkgYSBzZXJ2aWNlDQo+PiAgICAgIG9y Y2hlc3RyYXRvciBhcyBhIHBhcnQgb2YgdGhlIE9TUy9CU1Mgc3RhY2ssIHNpbmNlLi4uDQo+PiAg ICBvIFRoZSBzdWNjZXNzZnVsIGFjdGl2YXRpb24gb2YgYSBzZXJ2aWNlIGluY2x1ZGVzIG1hbnkg cGFydHMgb2YgdGhlDQo+PiAgICAgIE9TUy9CU1Mtc3RhY2sgaW5jbHVkaW5nIG9wZXJhdGlvbmFs IHJlYWRpbmVzcyAoYXJlIHRoZXJlIHBoeXNpY2FsDQo+PiAgICAgIHBvcnRzIGF2YWlsYWJsZSks IGJpbGxpbmcgbWFuYWdlbWVudCAoaXMgdGhlIGN1c3RvbWVyIGFsbG93ZWQgdG8gDQo+PiAgICAg IHBlcmZvcm0gZS5nLiB0aGlzIHJlc291cmNlIGV4cGFuc2lvbiksIGFuZCBhc3N1cmFuY2UgKGNo YW5nZWQNCj4+ICAgICAgc2VydmljZXMgcmVxdWlyZSBuZXcgYXNzdXJhbmNlIHBhcmFtZXRlcnMp LiBUaGlzIG1ha2VzIGl0IGhhcmQNCj4+ICAgICAgdG8gc2VwYXJhdGUgb3V0IGEgQ3VzdG9tZXIg aW50ZXJmYWNlIHRvIHNlcnZpY2Ugb3JjaGVzdHJhdGlvbg0KPj4gICAgICBvbmx5LCBzZXBhcmF0 ZSBmcm9tIHRoZSBPU1MvQlNTIHN0YWNrLg0KPiANCj4gSSBhbSBub3QgKG92ZXJseSkgZmFtaWxp YXIgd2l0aCB0aGUgVE1GIHdvcmssIGhvd2V2ZXIsIHlvdXIgdGV4dCAiVE1Gb3J1bSB3b3VsZCBj bGFzc2lmeSBhIHNlcnZpY2Ugb3JjaGVzdHJhdG9yIGFzIGEgcGFydCBvZiB0aGUgT1NTL0JTUyBz dGFjayIgc3VnZ2VzdHMgdGhlIGFjY2VwdGFuY2Ugb2Ygc2VydmljZSBvcmNoZXN0cmF0aW9uIGFz ICJhIHRoaW5nIi4gSWYgeW91IHdlcmUgd3JpdGluZyBjb2RlLCB5b3UgKm1pZ2h0KiB3cml0ZSBh IHNlcGFyYXRlIG1vZHVsZSAoZXZlbiBsaWJyYXJ5KSB0byBoYW5kbGUgc2VydmljZSBvcmNoZXN0 cmF0aW9uLCBhbmQgbWFpbnRhaW4gdGhhdCBhcyBhIHNlcGFyYXRlIG1vZHVsZSBmcm9tIGJpbGxp bmcgbWFuYWdlbWVudCwgZXRjLiBUaGF0IGRvZXMgbm90IG1ha2UgdGhlbSBjb21wbGV0ZWx5IHNl cGFyYXRlLCBidXQgZG9lcyByZXN1bHQgaW4gdGhlbSBzaG93aW5nIGFzIHNlcGFyYXRlIGZ1bmN0 aW9uYWwgY29tcG9uZW50cyBpbiB0aGUgIk9TUy9CU1Mgc3RhY2su4oCdDQoNCiBFeGFjdGx5IHJp Z2h0LiBUaGUgdGVybSDigJxPU1MvQlNT4oCdIGl0c2VsZiBhcyBJ4oCZbSB1c2VkIHRvIGhlYXJp bmcgaXQgaXMgYSBtZWFucyBvZiBncm91cGluZyBhIChodWdlKSBzZXQgb2YgZnVuY3Rpb25zIHVu ZGVyIGEgY29tbW9uIGxhYmVsLg0KDQo+PiBUaGlzIGFuIGluZm9ybWF0aW9uYWwgZHJhZnQgYW5k IGFzIHN1Y2ggaXMgZm9yIGdlbmVyYWwgaW5mb3JtYXRpb24sIGFuZA0KPj4gbm90ICBuZWNlc3Nh cmlseSBpbnRlbmRlZCB0byByZXByZXNlbnQgY29tbXVuaXR5IGNvbnNlbnN1cyBvcg0KPj4gcmVj b21tZW5kYXRpb24sIGp1c3QgbGlrZSA4MTE5Lg0KPiANCj4gSSBjaG9vc2UgdG8gZGlzYWdyZWUh IDgxOTkgaGFkIFdHIGFuZCBJRVRGIGxhc3QgY2FsbC4gSXQgaGFzIGNvbW11bml0eSBjb25zZW5z dXMuDQoNCiBUcnVlLiBJdCB3YXMgYSBoZWF2eS1oYW5kZWQgYXR0ZW1wdCBhdCBwdXNoaW5nIG9u IHRoZSBmYWN0IHRoYXQgd2XigJlyZSBub3Qgd3JpdGluZyBzdGFuZGFyZHMgaGVyZSwgYnV0IG1l cmVseSB3b3JraW5nIHRvIGluZm9ybS4gQnV0IHlvdeKAmXJlIGFic29sdXRlbHkgcmlnaHQgdGhh dCBXRyB3b3JrIGl0ZW1zIHJlZmxlY3QgY29uc2Vuc3VzLg0KDQo+IFRoZSBpbnRlbnRpb24gb2Yg dGhpcyBkcmFmdCBpcyB0aGF0IGl0LCB0b28sIHdpbGwgaGF2ZSBJRVRGIGNvbW11bml0eSBjb25z ZW5zdXMuDQo+IEJ1dCBiZSBhd2FyZSB0aGF0IHdlIGFyZSBuZWl0aGVyIHRyeWluZyB0byBmb3Jj ZSB0aGF0IGNvbnNlbnN1cywgbm9yIGRpY3RhdGUgdGhlIHRlcm1pbm9sb2d5LiBXaGF0IHdlIGFy ZSBkb2luZyBpcyB0cnlpbmcgdG8gYW5zd2VyIHRoZSAob2Z0ZW4gcmVwZWF0ZWQpIHF1ZXN0aW9u OiAiV2hlcmUgZG8gTDJTTSBhbmQgTDNTTSBmaXQgaW50byB0aGUgcGljdHVyZSBzaW5jZSB0aGV5 IGRvbid0IHNlZW0gdG8gYmUgaW50ZW5kZWQgdG8gdGFsayB0byBuZXR3b3JrIGRldmljZXMgb3Ig Y29udHJvbGxlcnM/4oCdDQoNCiBNYWtlcyBzZW5zZS4gQW5kIGluIG15IHNpbXBsaXN0aWMgKDgx OTktaW5mdXNlZCkgbWluZCwgZS5nLiBpZXRmLWwydnBuLXN2Y0AyMDE2LTA4LTE5LnlhbmcgaXMg YSBncmVhdCBleGFtcGxlIG9mIGEgTmV0d29yayBTZXJ2aWNlIE1vZHVsZS4gU28gZmFyIHNvIGdv b2QgOy0pIFdoZXRoZXIgd2UgY2FuIGNvbWUgdXAgd2l0aCBmdXJ0aGVyIGNsYXNzaWZpY2F0aW9u IHRvIHJvYnVzdGx5IGNhcHR1cmUgdGhlICJzY29wZSBvZiBhbmQgcHVycG9zZSBvZiBhbiBJRVRG IHNlcnZpY2UgbW9kZWzigJ0gaXMgbmV4dC4NCg0KPj4gQnV0IEkgd291bGQgc3VnZ2VzdCB0aGUg ZG9jdW1lbnQgY291bGQgYmUNCj4+IGltcHJvdmVkIGJ5IGVsYWJvcmF0aW5nICB0aGUgcG9pbnQg b2YgdGhlIHNlcGFyYXRpb24gb2YgdGhlIG9yY2hlc3RyYXRvcg0KPj4gYW5kIHRoZSBCU1MvT1NT IGFuZCB0aGUgcmVzdWx0aW5nIGRpZmZlcmVuY2UgaW4gbW9kdWxlIHR5cGVzLg0KPiANCj4gSSBj b3VsZCBjZXJ0YWlubHkgYWRkIHRleHQgYXJvdW5kIEZpZ3VyZSA0IHRvIHNheSAiLi4udGhpcyBp bGx1c3RyYXRlcyBhIGZ1bmN0aW9uYWwgYXJjaGl0ZWN0dXJlIGFuZCBhbiBpbXBsZW1lbnRhdGlv biBtaWdodCBub3QgY2hvb3NlIHRvIG1ha2UgdGhlIGRpc3RpbmN0aW9ucyBzaG93biBzdWNoIHRo YXQgc2VwYXJhdGlvbnMgYW5kIGludGVyZmFjZXMgaWxsdXN0cmF0ZWQgbWlnaHQgZmFsbCB3aXRo aW4gYSBzaW5nbGUgaW1wbGVtZW50YXRpb24uIiBXb3VsZCB0aGF0IGhlbHA/DQoNCiBXaXRoIHRo ZSBmdXJ0aGVyIGVsYWJvcmF0aW9uIGFib3ZlLCB3b3VsZCB0aGlzIG1ha2Ugc2Vuc2U/DQoNCg0K ICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0rDQogICAgICAgICAgfCAgICAgICAgICAgICAgIHwN CiAgICAgICAgICB8ICAgQ3VzdG9tZXJzICAgfA0KICAgICAgICAgIHwgICAgICAgICAgICAgICB8 DQogICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLSsNCg0KICAgICAgLSAtIC0gLSAtIC0gLSAtIC0g LSAtIC0gLSAtDQogICAgIEN1c3RvbWVyIFNlcnZpY2UgWUFORyBNb2R1bGVzDQoNCiAgICAgICst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKw0KICAgICAgfCAgICAgT3BlcmF0aW9ucyBhbmQgQnVzaW5lc3MgU3VwcG9ydCBTeXN0ZW0g KE9TUy9CU1MpICAgICAgICB8DQogICAgICB8ICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICAgIHwNCiAgICAgIHwgICAgICAgICAgICAgIHwg ICBTZXJ2aWNlIE9yY2hlc3RyYXRvciAgIHwgICAgICAgICAgICAgICAgICAgfA0KICAgICAgfCAg ICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAgICAg ICB8DQogICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsNCg0KICAgICAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAt IC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0NCiAgICAgTmV0d29yayBTZXJ2aWNlIFlB TkcgTW9kdWxlcw0KDQogICAgKy0tLS0tLS0tLS0tLSsgICArLS0tLS0tLS0tLS0tLSsgICArLS0t LS0tLS0tLS0tLSsgICArLS0tLS0tLS0tLS0tLSsNCiAgICB8ICAgICAgICAgICAgfCAgIHwgICAg ICAgICAgICAgfCAgIHwgICAgICAgICAgICAgfCAgIHwgICAgICAgICAgICAgfA0KICAgIHwgIC0g TDJWUE4gICB8ICAgfCAgIC0gTDJWUE4gICB8ICAgfCAgICBFVlBOICAgICB8ICAgfCAgICBMM1ZQ TiAgICB8DQogICAgfCAgLSBWUFdTICAgIHwgICB8ICAgLSBWUExTICAgIHwgICB8ICAgICAgICAg ICAgIHwgICB8ICAgICAgICAgICAgIHwNCiAgICB8ICAgICAgICAgICAgfCAgIHwgICAgICAgICAg ICAgfCAgIHwgICAgICAgICAgICAgfCAgIHwgICAgICAgICAgICAgfA0KICAgICstLS0tLS0tLS0t LS0rICAgKy0tLS0tLS0tLS0tLS0rICAgKy0tLS0tLS0tLS0tLS0rICAgKy0tLS0tLS0tLS0tLS0r DQoNCiAgICAgLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0g LSAtIC0gLSAtIC0gLSAtDQogICAgIE5ldHdvcmsgRWxlbWVudCBZQU5HIE1vZHVsZXMNCg0KICAg ICArLS0tLS0tLS0tLS0tKyAgKy0tLS0tLS0tLS0tLSsgICstLS0tLS0tLS0tLS0tKyAgKy0tLS0t LS0tLS0tLSsNCiAgICAgfCAgICAgICAgICAgIHwgIHwgICAgICAgICAgICB8ICB8ICAgICAgICAg ICAgIHwgIHwgICAgICAgICAgICB8DQogICAgIHwgICAgTVBMUyAgICB8ICB8ICAgIEJHUCAgICAg fCAgfCBJUHY0IC8gSVB2NiB8ICB8ICBFdGhlcm5ldCAgfA0KICAgICB8ICAgICAgICAgICAgfCAg fCAgICAgICAgICAgIHwgIHwgICAgICAgICAgICAgfCAgfCAgICAgICAgICAgIHwNCiAgICAgKy0t LS0tLS0tLS0tLSsgICstLS0tLS0tLS0tLS0rICArLS0tLS0tLS0tLS0tLSsgICstLS0tLS0tLS0t LS0rDQoNCiAgICAgICBMMlZQTjogTGF5ZXIgMiBWaXJ0dWFsIFByaXZhdGUgTmV0d29yaw0KICAg ICAgIEwzVlBOOiBMYXllciAzIFZpcnR1YWwgUHJpdmF0ZSBOZXR3b3JrDQogICAgICAgVlBXUzog VmlydHVhbCBQcml2YXRlIFdpcmUgU2VydmljZQ0KICAgICAgIFZQTFM6IFZpcnR1YWwgUHJpdmF0 ZSBMQU4gU2VydmljZQ0KDQoNCg0KPiBNYW55IHRoYW5rcywNCj4gDQo+IEFkcmlhbg0KPiANCg0K From nobody Wed Aug 2 07:52:00 2017 Return-Path: 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 EF9811319B4 for ; Wed, 2 Aug 2017 07:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 AlkG-yio9Osy for ; Wed, 2 Aug 2017 07:51:54 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0127.outbound.protection.outlook.com [104.47.37.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 129A5126BFD for ; Wed, 2 Aug 2017 07:51:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PeyIeqh3l0xSc1eyqCJCd828mxZBWbgpnN/pSkHS4h4=; b=LMOwVoLEthcpd6gXOeW7M+00HUfr5qmzt8rW7KzhJrtFOcvz7AjOm0gy3MYuVa0bZ1GY3agRwLlh9Nm/LBlr/WAKbF0aTO6THeeJD2F6cSdujNp0DFUNrKWoxRXRg0chTr2totWCAFCkA8mWkwTu3X80fiaZbvnCP7VM9cJCiT0= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.10; Wed, 2 Aug 2017 14:51:52 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1320.010; Wed, 2 Aug 2017 14:51:52 +0000 From: Kent Watsen To: Alex Campbell , "netmod@ietf.org" Thread-Topic: accessible tree for rpcs? Thread-Index: AQHTCtwZEsEmlzSxhUeoKQkaPbrqIqJwKuAPgAC6GgA= Date: Wed, 2 Aug 2017 14:51:52 +0000 Message-ID: <985EDF7D-1C05-4CDE-9FD1-32489D113853@juniper.net> References: <1501631444289.92159@Aviatnet.com> In-Reply-To: <1501631444289.92159@Aviatnet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 6:0VtfNdoAS09BaG323lAl54pGItA0uC/FV7z0KHZY+w42Zr/Ao0h+NUt+CQhbwT62Mkdbx2jM5NkvdHIcK9+i//2p7ck4N934GNewDh2aqmilWAs1d32jpgXt9JpkWsuu4MnuOrwMhgHe+COzmlZrpbezUL8GoOKmw5BuM13KLn+A0ZQ5ZYwC+BbyN1DKX0ngf8A0ha5tPA9IVr10geovVfWJiUGS6Fqi4vmFI1N+7EpgagXlZGGj213PaUNT+AQvTi7ooIE2rXNefpHmdIedptmrgbWR2KVUyUV4Rc+lPOsgM7N6pSFS4ptQPug5zZ91kOeqENLEiTv46YaDDmUwew==; 5:7QOWtR9n83ldyzO/1Fij/dWD/8uulqV0D2AbRJZ6gNkUGEndRSJNKXVvghyWh8HQXLbNZbtZKKf7cIIfMsRzIKhj0COG+VVtz0SSo4SnrZ8E3WWAFr9p5p1oi7qeDG6acnqyQIqP/8/prj8mqH8lpQ==; 24:xTe7XMEbloVn0ZSDNHCaZcT+BGtIYDkknrEwV80E8ODUUs/0xNt7niV2ODJzJnJxBOUmCBNISXMTJ8R2SRKELpzNRNswY/YaQZcTzAQj+zo=; 7:Lxo6nwdqABtCno5Yjli2K8d8VFoXWy5tfxD/pbi0OGAncN8i+sI2kLy1foZyogEFHGQfLu4HSDwmADtd4SI0N86rnyBrapmZw20MIf+j186RktIcJFCAWvRA0ZLfY7Brpx79RmPUcGYWpKck30FvUmMrIyPceWUiWL9GIU/RjUuYcuU+ov/8KzGEfu83k2i/aygaE1ehpLiDXP9g4gVhe1GeGIm9cNJlBoRXyMcp6Sc= x-ms-office365-filtering-correlation-id: 1222fb18-80c4-4c23-1928-08d4d9b602f5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1442; x-ms-traffictypediagnostic: BN3PR0501MB1442: x-exchange-antispam-report-test: UriScan:(158342451672863); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1442; x-forefront-prvs: 0387D64A71 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39850400002)(39450400003)(39840400002)(39860400002)(189002)(199003)(229853002)(14454004)(86362001)(2900100001)(189998001)(478600001)(561944003)(106356001)(105586002)(101416001)(33656002)(38730400002)(6246003)(54356999)(3280700002)(97736004)(2906002)(8676002)(4001350100001)(7736002)(6512007)(50986999)(3846002)(99286003)(102836003)(81166006)(3480700004)(3660700001)(6116002)(76176999)(68736007)(53936002)(77096006)(36756003)(6486002)(25786009)(2501003)(305945005)(8936002)(81156014)(5660300001)(83506001)(2950100002)(83716003)(82746002)(6506006)(6436002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <7A0091F416FF8C43AEA08BC1CFC6639C@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2017 14:51:52.2350 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: Re: [netmod] accessible tree for rpcs? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 14:51:56 -0000 SGkgQWxleCwNCg0KPiBXaHkgd291bGQgaXQgbm90IG1ha2Ugc2Vuc2U/IA0KDQpGaXJzdGx5LCBp dCBzZWVtcyBvdXRzaWRlIHRoZSBub3JtLiAgQXQgbGVhc3QsIEknbSB1bmF3YXJlIG9mIGFueSBv dGhlciBJREwgdGhhdCBhbGxvd3MgZm9yIHN1Y2ggbGlua2FnZS4gIFNlY29uZCwgSSdtIHRyeWlu ZyB0byB1bmRlcnN0YW5kIHRoZSB2YWx1ZS4gIEZvciBpbnN0YW5jZSwgaG93IGRvZXMgaXQgYmVu ZWZpdCB0aGUgbW9kdWxlIGRlc2lnbmVyLCB0aGUgc2VydmVyIGRldmVsb3BlciwgdGhlIGNsaWVu dCBkZXZlbG9wZXI/ICAobW9yZSBvbiB0aGlzIGJlbG93KQ0KDQpXaGlsZSBub3QgaW4gdGhlIHN1 YmplY3QsIG15IHF1ZXN0aW9uIGV4dGVuZHMgdG8gbm90aWZpY2F0aW9ucyBhcyB3ZWxsLiAgU2Vj dGlvbiA2LjQuMSBzYXlzIHRoYXQgdGhlIGFjY2Vzc2libGUgdHJlZSBpcyAidGhlIG5vdGlmaWNh dGlvbiBpbnN0YW5jZSwgYWxsIHN0YXRlIGRhdGEgaW4gdGhlIHNlcnZlciwgYW5kIHRoZSBydW5u aW5nIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlIi4gIE5vdGlmaWNhdGlvbnMgYXJlIHBhcnRpY3Vs YXJseSBpbnRlcmVzdGluZyBnaXZlbiB0aGVpciBvbmUtd2F5IGNvbW11bmljYXRpb24gcHJvcGVy dHkuICBJbiB0aGlzIHJlZ2FyZCwgbm90aWZpY2F0aW9ucyBhcmUgYSBiaXQgbGlrZSA8b3BlcmF0 aW9uYWw+IGluIHRoYXQgdGhlIHNlcnZlciB3aWxsL3Nob3VsZCBzZW5kIHRydXRoLCByZWdhcmRs ZXNzIHdoYXQgdGhlIHZhbGlkYXRpb24gbWlnaHQgYWxsb3cuDQoNCg0KPiBJcyB5b3VyIHF1ZXN0 aW9uIGFib3V0IHRoZSBkYXRhc3RvcmVzIHByb3Bvc2FsPw0KDQpJIHdhc24ndCB0aGlua2luZyBh Ym91dCBpdCBvcmlnaW5hbGx5LCBidXQgeW91IHJhaXNlIGEgZ29vZCBwb2ludC4gTG9va2luZyBh dCByZXZpc2VkLWRhdGFzdG9yZXMsIHdlIHNlZSB0aGF0IHRoZSBYUGF0aCBjb250ZXh0IHJ1bGVz IGFyZSByZXZpc2VkIGluIFM1LjEuICBJdCBzZWVtcyBsaWtlIHRoYXQgPHJ1bm5pbmc+IGlzIG5v IGxvbmdlciBpbmNsdWRlZCAoYmV0dGVyKSwgYnV0IHRoZSBjb25jZXJuIHJhaXNlZCBpbiB0aGlz IHRocmVhZCBwZXJzaXN0cy4gIEp1c3QgdGhpbmtpbmcgYWJvdXQgPHJ1bm5pbmc+IG5vIGxvbmdl ciBiZWluZyBpbmNsdWRlZCwgdGhpcyBzZWVtcyB0byBicmVhayBiYWNrd2FyZHMgY29tcGF0aWJp bGl0eS4gIEZvciBSUEMncywgbmVpdGhlciBORVRDT05GIG5vciBSRVNUQ09ORiBwcm92aWRlIGEg bWVjaGFuaXNtIHRvIGFkZHJlc3MgYSBkYXRhc3RvcmUuICBBbmQgZm9yIGFjdGlvbnMsIE5FVENP TkYgYWdhaW4gZG9lc24ndCBhZGRyZXNzIGEgZGF0YXN0b3JlLCB0aG91Z2ggUkVTVENPTkYgZG9l cy4gIFdoYXQgdGhpcyBtZWFucyBpcyB0aGF0IGEgbGVnYWN5IHNlcnZlciBhbHNvIHN1cHBvcnRp bmcgTk1EQSBpcyB1bmFibGUgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIGlmIGl0IHNob3VsZCB1 c2Ugb2xkIG9yIG5ldyBiZWhhdmlvci4gIE1heWJlIGl0J3MgYSBtdXRlIHBvaW50LCBpbiB0aGF0 IDxvcGVyYXRpb25hbD4gaXMgYSBzdWJzZXQgb2YgPHJ1bm5pbmc+LCBidXQgdGhlcmUgaXMgYSBz ZW1hbnRpYyBkaWZmZXJlbmNlIGJldHdlZW4gc29tZXRoaW5nIGNvbmZpZ3VyZWQgdmVyc3VzIGFw cGxpZWQuDQoNCkJUVywgdGhlIHJlc3Rjb25mLW5tZGEgZHJhZnQgY3VycmVudGx5IGRvZXNuJ3Qg c2F5IGFueXRoaW5nIGFib3V0IGFjdGlvbiBzdGF0ZW1lbnRzLCBidXQgaXQgc2VlbXMgdGhhdCBp dCBzaG91bGQgcmVzdHJpY3QgdGhlbSB0byBqdXN0IDxvcGVyYXRpb25hbD4gdW5kZXIgdGhlIHsr cmVzdGNvbmZ9L2RzLyByZXNvdXJjZS4gIFdlIHdvdWxkbid0IHdhbnQgdG8gc3VwcG9ydCwgZm9y IGluc3RhbmNlLCB7K3Jlc3Rjb25mfS9kcy9pZXRmLWRhdGFzdG9yZXM6Y2FuZGlkYXRlL2Zvb2Jh ci9yZXN0YXJ0LiAgDQoNCg0KDQo+IFVzdWFsbHkgYW4gYWN0aW9uIHdpbGwgcmVmZXIgdG8gc29t ZSBvYmplY3QgdGhhdCBpcyBkZWZpbmVkIGFzIGNvbmZpZ3VyYXRpb24NCj4gYW5kL29yIHN0YXRl LCBhbmQgbWF5IGRlcGVuZCBvbiB0aGUgcGFydGljdWxhciBwcm9wZXJ0aWVzIG9mIHRoYXQgb2Jq ZWN0Lg0KPiBIZXJlIGlzIGEgWUFORyBmcmFnbWVudCBzaG93aW5nIG9uZSBwb3NzaWJsZSBhcHBs aWNhdGlvbjoNCj4NCj4gICAgbGlzdCBvc3BmLWluc3RhbmNlIHsNCj4gICAgICAgIGNvbmZpZyB0 cnVlOw0KPiAgICAgICAgbGVhZiBpZCB7dHlwZSBzdHJpbmc7fQ0KPiAgICAgICAgbGVhZiBzdXBw b3J0cy1ncmFjZWZ1bC1yZXN0YXJ0IHt0eXBlIGJvb2xlYW47fQ0KPiAgIH0NCj4NCj4gICAgcnBj IG9zcGYtZ3JhY2VmdWwtcmVzdGFydCB7DQo+ICAgICAgICBpbnB1dCB7DQo+ICAgICAgICAgICAg bGVhZiBpbnN0YW5jZS1pZCB7dHlwZSBsZWFmcmVmIHtwYXRoICIvb3NwZi1pbnN0YW5jZS9pZCI7 fX0NCj4gICAgICAgICAgICBtdXN0ICIvb3NwZi1pbnN0YW5jZVtpZD1jdXJyZW50KCkvaW5zdGFu Y2UtaWRdL3N1cHBvcnRzLWdyYWNlZnVsLXJlc3RhcnQgPSAndHJ1ZSciIHsNCj4gICAgICAgICAg ICAgICAgZXJyb3ItbWVzc2FnZSAiSW5zdGFuY2UgZG9lcyBub3Qgc3VwcG9ydCBncmFjZWZ1bCBy ZXN0YXJ0IjsNCj4gICAgICAgICAgICB9DQo+ICAgICAgICB9DQo+ICAgIH0NCj4NCj4gQXMgYW5v dGhlciBhcHBsaWNhdGlvbiwgYSAibXV0ZSB0cmFuc21pdHRlciIgY29tbWFuZCBtaWdodCBvbmx5 IGFwcGx5IHRvDQo+IGRpZ2l0YWwgcmFkaW8gaW50ZXJmYWNlcy4NCg0KQWJvdXQgdGhpcyBleGFt cGxlLCBteSBmaXJzdCB0aG91Z2h0IGlzIHRoYXQgUlBDIGlucHV0IGlzIHByb2JhYmx5IHRoZSBt b3N0IGRlZmVuc2libGUgZXhhbXBsZSAtIFJQQyBvdXRwdXQgb3Igbm90aWZpY2F0aW9uIGV4YW1w bGVzIG1ha2UgZXZlbiBsZXNzIHNlbnNlLiAgV2l0aCB0aGlzIGV4YW1wbGUsIHRoZSBZQU5HIGlz IGRvaW5nIHR3byB0aGluZ3M6IDEpIGFzc2VydGluZyB0aGF0IHRoZSBpbnN0YW5jZSBleGlzdHMg YW5kIDIpIGFzc2VydGluZyB0aGF0IHRoZSBpbnN0YW5jZSBzdXBwb3J0cyBncmFjZWZ1bCByZXN0 YXJ0cy4gIFNvOg0KDQogIEZyb20gYSBtb2R1bGUgZGVzaWduZXIgcGVyc3BlY3RpdmU6DQogICAg LSBpdCBpcyBtb3JlIGV4YWN0IHRoYW4gYSBkZXNjcmlwdGlvbiBzdGF0ZW1lbnQgKGJ1dCBqdXN0 IG1pbGRseSBzbyksIGFuZA0KICAgICAgbm90ZSB0aGF0IHRoZSAnbGVhZicgYW5kICdtdXN0JyBz dGF0ZW1lbnRzIHNob3VsZCBoYXZlICdkZXNjcmlwdGlvbicgDQogICAgICBzdGF0ZW1lbnRzIHRv bw0KDQogIEZyb20gYSBzZXJ2ZXIgZGV2ZWxvcGVyIHBlcnNwZWN0aXZlOg0KICAgIC0gaXQgbW92 ZXMgYSBsaXR0bGUgbW9yZSBvZiB0aGUgdmFsaWRhdGlvbiBpbnRvIHRoZSBpbnB1dC1wYXJzaW5n IGxvZ2ljLA0KICAgICAgYnV0IEknbSBzdXJlIHRoYXQgdGhlIHNlcnZlciB3b3VsZCB0aHJvdyBh biBlcnJvciBhbnl3YXkgaWYgdGhlDQogICAgICBpbnN0YW5jZSBkaWRuJ3QgZXhpc3Qgb3IgaWYg aXQgZGlkbid0IHN1cHBvcnQgZ3JhY2VmdWwgcmVzdGFydC4NCg0KICBGcm9tIGEgY2xpZW50IGRl dmVsb3BlciBwZXJzcGVjdGl2ZToNCiAgICAtIGFnYWluLCB0aGUgbGVhZnJlZi9tdXN0IHN0YXRl bWVudHMgYXJlIG1vcmUgZXhhY3QgdGhhbiBkZXNjcmlwdGlvbg0KICAgICAgc3RhdGVtZW50cywg YnV0IEkgZG9uJ3QgYmVsaWV2ZSB0aGF0IHRoZXJlIGlzIGFueSBleHBlY3RhdGlvbiB0aGF0DQog ICAgICBhIGNsaWVudCB3b3VsZCBwZXJmb3JtIHZhbGlkYXRpb24gcHJpb3IgdG8gc2VuZGluZyB0 aGUgUlBDLiAgT2YNCiAgICAgIGNvdXJzZSBpdCBjb3VsZCBpZiBpdCBoYWQgYSBjb3B5IG9mIHRo ZSBzZXJ2ZXIncyBkYXRhc3RvcmVzIChlLmcuDQogICAgICBwZWVyIG1vdW50KSwgYnV0IHRoYXQg ZG9lc24ndCBndWFyYW50ZWUgYW55dGhpbmcgdW5sZXNzIHRoZSBjbGllbnQNCiAgICAgIGlzIGFs c28gZ29pbmcgdG8gdXNlIGxvY2tpbmcgKHdoaWNoIGRvZXNuJ3QgZXhpc3QgaW4gUkVTVENPTkYp DQogICAgICBhcm91bmQgdGhlIHN5bmNpbmcgb2YgdGhlIHNlcnZlcidzIGRhdGEgYW5kIHRoZSBl eGVjdXRpb24gUlBDLg0KDQoNCldlIGNhbiBkbyBzaW1pbGFyIGV4ZXJjaXNlcyB3aXRoIFJQQyBv dXRwdXQgYW5kIG5vdGlmaWNhdGlvbnMsIGJ1dCBteSBwb3NpdGlvbiBpcyB0aGF0IHdlJ2xsIGZp bmQgZXZlbiBsZXNzIHZhbHVlLiAgQWdhaW4sIHRoZXNlIHByb3Zpc2lvbnMgc2VlbSBsaWtlIGEg bG90IG9mIGNvbXBsZXhpdHkgZm9yIGxpdHRsZSBnYWluLi4uDQoNCktlbnQgIC8vIGNvbnRyaWJ1 dG9yDQoNCg0KDQoNCg== From nobody Wed Aug 2 08:11:32 2017 Return-Path: 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 DF36C131E75 for ; Wed, 2 Aug 2017 08:11:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com 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 ndXuEX59Z59a for ; Wed, 2 Aug 2017 08:11:29 -0700 (PDT) Received: from mail-wr0-x230.google.com (mail-wr0-x230.google.com [IPv6:2a00:1450:400c:c0c::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E40128C9C for ; Wed, 2 Aug 2017 08:11:27 -0700 (PDT) Received: by mail-wr0-x230.google.com with SMTP id k71so19965745wrc.2 for ; Wed, 02 Aug 2017 08:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DNx/GgVal0kkRyVPam1HU7VzVa2YbOyaq4Ati8DyiIM=; b=HuPZQqDxiUb4kh8U/rSpEtm08cBLUidSAAs+2PH8B8Y/JejeMq0N7r/fa7vP6lhfND xUK3JjCdJAvfmP7LLQCnmGkXP/1A774iY4I7MoBxQi4J8t6EQXSEuI1YGuZ05p5BqrgQ 0VvU+oaaCD2REodWH5WCDx37zbcXPl3YjI0dO1+gefBCZP9dURA4e/nQGeTsz9N6rm2u epD5XlVkwznE3/IamWneQpBXQ3ZbrvIs7vjrZ0gvVx7R2z/ulqXZsSmxxF33wcNjPiPV YemrGH9noODGsvgGcKWnYk0f7VgY2WWbqLFpLihpB7SPZXP6AlYdFyOrh4Qc7eDPl1gK a/Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DNx/GgVal0kkRyVPam1HU7VzVa2YbOyaq4Ati8DyiIM=; b=K2kPgaEd7kCMqQPNQmDHGXwoDV74LtwxnbVT7prR0K+H+bN1rr7OrEkj//8BfB4Hc1 nJiVD3vGzsL0GX4hOd5e9Z+vnj7EGxjF8VyozZD2JDknttDBIu9nmmPf9TGT+mo42aja EOKCe1BYGoyAiUik5P7w4Z6Bao+KwAVfF49djCn9SZ/+NAxFMhWbQJzYJhqP2WyEKAgT VMNZNr2BalopvBYqJhK/Sw9QYdkYjNnCXctm+6r/YWBfzN1Fj5b49f8U80sOaWsFt6GG poiSd4AdakmFjY+AhcU+Fgwa6aURk6eNMOMJXknXzExR6fKOUXF1j9hqzNTKqnsOf0ty IkYA== X-Gm-Message-State: AIVw11386vjQPqsQpPPfPqPzC4KTGsXTafYRwduhXmcLv0B92NJu3rU2 3KLGsqEsDavwTRxCtKzQH97NbhKpl5Bo X-Received: by 10.223.134.39 with SMTP id 36mr18440225wrv.244.1501686686510; Wed, 02 Aug 2017 08:11:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.160 with HTTP; Wed, 2 Aug 2017 08:11:25 -0700 (PDT) In-Reply-To: <985EDF7D-1C05-4CDE-9FD1-32489D113853@juniper.net> References: <1501631444289.92159@Aviatnet.com> <985EDF7D-1C05-4CDE-9FD1-32489D113853@juniper.net> From: Andy Bierman Date: Wed, 2 Aug 2017 08:11:25 -0700 Message-ID: To: Kent Watsen Cc: Alex Campbell , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a1146c380838cd10555c6ad99" Archived-At: Subject: Re: [netmod] accessible tree for rpcs? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 15:11:32 -0000 --001a1146c380838cd10555c6ad99 Content-Type: text/plain; charset="UTF-8" Hi Kent, I objected to this expansion of XPath context when YANG 1.1 was being developed. Then I realized the YANG constraints are totally worthless so no reason to do anything about it. The server will NEVER use these constraints. It does not run XPath validation on its own output. The client can NEVER reliably use these constraints because they need to be evaluated at the instant the RPC or notification output is generated, and the client does not have that snapshot of the running or operational datastores. So just ignore these YANG details. That's all real tools can do with them anyway. Andy On Wed, Aug 2, 2017 at 7:51 AM, Kent Watsen wrote: > Hi Alex, > > > Why would it not make sense? > > Firstly, it seems outside the norm. At least, I'm unaware of any other > IDL that allows for such linkage. Second, I'm trying to understand the > value. For instance, how does it benefit the module designer, the server > developer, the client developer? (more on this below) > > While not in the subject, my question extends to notifications as well. > Section 6.4.1 says that the accessible tree is "the notification instance, > all state data in the server, and the running configuration datastore". > Notifications are particularly interesting given their one-way > communication property. In this regard, notifications are a bit like > in that the server will/should send truth, regardless what > the validation might allow. > > > > Is your question about the datastores proposal? > > I wasn't thinking about it originally, but you raise a good point. Looking > at revised-datastores, we see that the XPath context rules are revised in > S5.1. It seems like that is no longer included (better), but the > concern raised in this thread persists. Just thinking about no > longer being included, this seems to break backwards compatibility. For > RPC's, neither NETCONF nor RESTCONF provide a mechanism to address a > datastore. And for actions, NETCONF again doesn't address a datastore, > though RESTCONF does. What this means is that a legacy server also > supporting NMDA is unable to differentiate between if it should use old or > new behavior. Maybe it's a mute point, in that is a subset > of , but there is a semantic difference between something > configured versus applied. > > BTW, the restconf-nmda draft currently doesn't say anything about action > statements, but it seems that it should restrict them to just > under the {+restconf}/ds/ resource. We wouldn't want to support, for > instance, {+restconf}/ds/ietf-datastores:candidate/foobar/restart. > > > > > Usually an action will refer to some object that is defined as > configuration > > and/or state, and may depend on the particular properties of that object. > > Here is a YANG fragment showing one possible application: > > > > list ospf-instance { > > config true; > > leaf id {type string;} > > leaf supports-graceful-restart {type boolean;} > > } > > > > rpc ospf-graceful-restart { > > input { > > leaf instance-id {type leafref {path "/ospf-instance/id";}} > > must "/ospf-instance[id=current()/instance-id]/supports-graceful-restart > = 'true'" { > > error-message "Instance does not support graceful > restart"; > > } > > } > > } > > > > As another application, a "mute transmitter" command might only apply to > > digital radio interfaces. > > About this example, my first thought is that RPC input is probably the > most defensible example - RPC output or notification examples make even > less sense. With this example, the YANG is doing two things: 1) asserting > that the instance exists and 2) asserting that the instance supports > graceful restarts. So: > > From a module designer perspective: > - it is more exact than a description statement (but just mildly so), > and > note that the 'leaf' and 'must' statements should have 'description' > statements too > > From a server developer perspective: > - it moves a little more of the validation into the input-parsing > logic, > but I'm sure that the server would throw an error anyway if the > instance didn't exist or if it didn't support graceful restart. > > From a client developer perspective: > - again, the leafref/must statements are more exact than description > statements, but I don't believe that there is any expectation that > a client would perform validation prior to sending the RPC. Of > course it could if it had a copy of the server's datastores (e.g. > peer mount), but that doesn't guarantee anything unless the client > is also going to use locking (which doesn't exist in RESTCONF) > around the syncing of the server's data and the execution RPC. > > > We can do similar exercises with RPC output and notifications, but my > position is that we'll find even less value. Again, these provisions seem > like a lot of complexity for little gain... > > Kent // contributor > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1146c380838cd10555c6ad99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Kent,


I objected to t= his expansion of XPath context when YANG 1.1 was being developed.
Then I realized the YANG constraints are totally worthless so no reason to= do anything
about it.

The server will N= EVER use these constraints.=C2=A0 It does not run XPath validation on its o= wn output.
The client can NEVER reliably use these constraints be= cause they need to be evaluated at the instant
the RPC or notific= ation output is generated, and the client does not have that snapshot
=
of the running or operational datastores.

So = just ignore these YANG details.=C2=A0 That's all real tools can do with= them anyway.


Andy


On Wed,= Aug 2, 2017 at 7:51 AM, Kent Watsen <kwatsen@juniper.net>= wrote:
Hi Alex,

> Why would it not make sense?

Firstly, it seems outside the norm.=C2=A0 At least, I'm unaware of any = other IDL that allows for such linkage.=C2=A0 Second, I'm trying to und= erstand the value.=C2=A0 For instance, how does it benefit the module desig= ner, the server developer, the client developer?=C2=A0 (more on this below)=

While not in the subject, my question extends to notifications as well.=C2= =A0 Section 6.4.1 says that the accessible tree is "the notification i= nstance, all state data in the server, and the running configuration datast= ore".=C2=A0 Notifications are particularly interesting given their one= -way communication property.=C2=A0 In this regard, notifications are a bit = like <operational> in that the server will/should send truth, regardl= ess what the validation might allow.


> Is your question about the datastores proposal?

I wasn't thinking about it originally, but you raise a good point. Look= ing at revised-datastores, we see that the XPath context rules are revised = in S5.1.=C2=A0 It seems like that <running> is no longer included (be= tter), but the concern raised in this thread persists.=C2=A0 Just thinking = about <running> no longer being included, this seems to break backwar= ds compatibility.=C2=A0 For RPC's, neither NETCONF nor RESTCONF provide= a mechanism to address a datastore.=C2=A0 And for actions, NETCONF again d= oesn't address a datastore, though RESTCONF does.=C2=A0 What this means= is that a legacy server also supporting NMDA is unable to differentiate be= tween if it should use old or new behavior.=C2=A0 Maybe it's a mute poi= nt, in that <operational> is a subset of <running>, but there i= s a semantic difference between something configured versus applied.

BTW, the restconf-nmda draft currently doesn't say anything about actio= n statements, but it seems that it should restrict them to just <operati= onal> under the {+restconf}/ds/ resource.=C2=A0 We wouldn't want to = support, for instance, {+restconf}/ds/ietf-datastores:candidate/foobar= /restart.



> Usually an action will refer to some object that is defined as configu= ration
> and/or state, and may depend on the particular properties of that obje= ct.
> Here is a YANG fragment showing one possible application:
>
>=C2=A0 =C2=A0 list ospf-instance {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 config true;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf id {type string;}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf supports-graceful-restart {type boolea= n;}
>=C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0 rpc ospf-graceful-restart {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 input {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf instance-id {type leafre= f {path "/ospf-instance/id";}}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 must "/ospf-instance[id= =3Dcurrent()/instance-id]/supports-graceful-restart =3D 'true= '" {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 error-message &= quot;Instance does not support graceful restart";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 }
>
> As another application, a "mute transmitter" command might o= nly apply to
> digital radio interfaces.

About this example, my first thought is that RPC input is probably the most= defensible example - RPC output or notification examples make even less se= nse.=C2=A0 With this example, the YANG is doing two things: 1) asserting th= at the instance exists and 2) asserting that the instance supports graceful= restarts.=C2=A0 So:

=C2=A0 From a module designer perspective:
=C2=A0 =C2=A0 - it is more exact than a description statement (but just mil= dly so), and
=C2=A0 =C2=A0 =C2=A0 note that the 'leaf' and 'must' statem= ents should have 'description'
=C2=A0 =C2=A0 =C2=A0 statements too

=C2=A0 From a server developer perspective:
=C2=A0 =C2=A0 - it moves a little more of the validation into the input-par= sing logic,
=C2=A0 =C2=A0 =C2=A0 but I'm sure that the server would throw an error = anyway if the
=C2=A0 =C2=A0 =C2=A0 instance didn't exist or if it didn't support = graceful restart.

=C2=A0 From a client developer perspective:
=C2=A0 =C2=A0 - again, the leafref/must statements are more exact than desc= ription
=C2=A0 =C2=A0 =C2=A0 statements, but I don't believe that there is any = expectation that
=C2=A0 =C2=A0 =C2=A0 a client would perform validation prior to sending the= RPC.=C2=A0 Of
=C2=A0 =C2=A0 =C2=A0 course it could if it had a copy of the server's d= atastores (e.g.
=C2=A0 =C2=A0 =C2=A0 peer mount), but that doesn't guarantee anything u= nless the client
=C2=A0 =C2=A0 =C2=A0 is also going to use locking (which doesn't exist = in RESTCONF)
=C2=A0 =C2=A0 =C2=A0 around the syncing of the server's data and the ex= ecution RPC.


We can do similar exercises with RPC output and notifications, but my posit= ion is that we'll find even less value.=C2=A0 Again, these provisions s= eem like a lot of complexity for little gain...

Kent=C2=A0 // contributor




_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--001a1146c380838cd10555c6ad99-- From nobody Wed Aug 2 08:20:19 2017 Return-Path: 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 24DC51320EC for ; Wed, 2 Aug 2017 08:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 pMfA3h3hP_2i for ; Wed, 2 Aug 2017 08:20:16 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2602913211D for ; Wed, 2 Aug 2017 08:20:14 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 34C9B3D; Wed, 2 Aug 2017 17:20:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id sjyxQmbwm_Sp; Wed, 2 Aug 2017 17:20:10 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 2 Aug 2017 17:20:12 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 13115200BA; Wed, 2 Aug 2017 17:20:12 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 4G065bWpmltq; Wed, 2 Aug 2017 17:20:11 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B953B200B8; Wed, 2 Aug 2017 17:20:11 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 9D3C44007028; Wed, 2 Aug 2017 17:20:11 +0200 (CEST) Date: Wed, 2 Aug 2017 17:20:11 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: Kent Watsen , "netmod@ietf.org" Message-ID: <20170802152011.GA34706@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , Kent Watsen , "netmod@ietf.org" References: <1501631444289.92159@Aviatnet.com> <985EDF7D-1C05-4CDE-9FD1-32489D113853@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] accessible tree for rpcs? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 15:20:18 -0000 On Wed, Aug 02, 2017 at 08:11:25AM -0700, Andy Bierman wrote: > > The server will NEVER use these constraints. It does not run XPath > validation on its own output. > > The client can NEVER reliably use these constraints because they need to be > evaluated at the instant > the RPC or notification output is generated, and the client does not have > that snapshot > of the running or operational datastores. > > So just ignore these YANG details. That's all real tools can do with them > anyway. I tend to agree when it comes to the output / notifications. But things are less clear on the input - a server can reject the execution of an operation if a must constraint on the input is not satisfied. But yes, constraints on config false data, operations and notifications are likely much less useful than constraints on config true data. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Aug 2 08:50:52 2017 Return-Path: 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 2750613213D for ; Wed, 2 Aug 2017 08:50:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com 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 ZjnXRq8jN6A4 for ; Wed, 2 Aug 2017 08:50:49 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EBDF131C33 for ; Wed, 2 Aug 2017 08:50:49 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id m85so45321299wma.1 for ; Wed, 02 Aug 2017 08:50:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=W6sj/Yc0NdaJ+MS5nLtTfk9J2YXSJA4VVm4rwrq8Who=; b=v5YpfV6+3sBujcGXYIs4jYytpIH7X36SrZWVMf9iD4a4wZ2GI2wa/9rBbxzxbPZ+4A 2bp4OCyI01FZcKOQILBld/aNydlpn5mxSOSA8+J06xHhnUfn/ZMR3lyeMLAlVMWgzh43 JfP5GyhKwaJRwbxlH0R3eQKHOvhchN/8Rqev6/xl0WBfEcQlcmUZyDAeEw2WKoBNaCt/ +MJNkGiLO+4NQk1YIEgsJ8jszZASfaZamm72f7yhQNKU0rB0jT0kcMPTkoGX05AYZSnS 6qfMWmchKVKckTpbKacZ0en7La771ZAcfMKM1vJB0LNnGQTIIerqVtvMnEvKFsaxnqjw kkHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=W6sj/Yc0NdaJ+MS5nLtTfk9J2YXSJA4VVm4rwrq8Who=; b=LGzQl9XWjiV+VZyJVXj6zCcU8GkrVjtdFo2HQjzVEf9qMGY1ZgsGLiWQQsMwPChoQ0 zUf7S2fNWsK5d69QJZLL00PiwnsDfq0be9L+rMkNDM/wU1d/WyNdRk5R6QKRRZzKEoEP U2BZcb0JRuDjhVyIBqszZIvs+phGPK/wMWhsJVvBxKgegS+hYgtG+Di/k9rHE9e1ajuG LtCo7I08HoV7ynsFPWAzIf0k21TzwQRAXbZTdwA6BVVvGXg760u0vCJzbfqOV/2n28xZ bCxf0OsmYeiIcJT0yWp1IdWKvdc7FJlmnxFHxMTUyo1/7bgCOprpanhkZPqbs5SXTyan gLqw== X-Gm-Message-State: AIVw110fy4bxvyuUSVTsUmU/7DM6tQlZjCN85FfsIWWt4IUUvVUIZi7s fhgvRmmNPAXlD90KDOkRo+6MQgDtgDYP X-Received: by 10.28.199.207 with SMTP id x198mr3945107wmf.156.1501689048086; Wed, 02 Aug 2017 08:50:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.160 with HTTP; Wed, 2 Aug 2017 08:50:47 -0700 (PDT) In-Reply-To: <20170802152011.GA34706@elstar.local> References: <1501631444289.92159@Aviatnet.com> <985EDF7D-1C05-4CDE-9FD1-32489D113853@juniper.net> <20170802152011.GA34706@elstar.local> From: Andy Bierman Date: Wed, 2 Aug 2017 08:50:47 -0700 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , Kent Watsen , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0d81804671810555c73a04" Archived-At: Subject: Re: [netmod] accessible tree for rpcs? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 15:50:51 -0000 --94eb2c0d81804671810555c73a04 Content-Type: text/plain; charset="UTF-8" On Wed, Aug 2, 2017 at 8:20 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Aug 02, 2017 at 08:11:25AM -0700, Andy Bierman wrote: > > > > The server will NEVER use these constraints. It does not run XPath > > validation on its own output. > > > > The client can NEVER reliably use these constraints because they need to > be > > evaluated at the instant > > the RPC or notification output is generated, and the client does not have > > that snapshot > > of the running or operational datastores. > > > > So just ignore these YANG details. That's all real tools can do with > them > > anyway. > > I tend to agree when it comes to the output / notifications. But > things are less clear on the input - a server can reject the execution > of an operation if a must constraint on the input is not satisfied. > > But yes, constraints on config false data, operations and > notifications are likely much less useful than constraints on > config true data. > > That's what I meant. RPC input MUST be honored by the server or it is not implementing correctly. Constraints on RPC output and notification output are for documentation purposes. A client could try to evaluate them with its own copies of the server's running and operational datastore contents, but I think the YANG definition says the constraint is enforced on the server. Maybe NMDA could clarify this issue. /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --94eb2c0d81804671810555c73a04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Aug 2, 2017 at 8:20 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Aug 02, 2017 at 08:11:25AM -0700, Andy Bierma= n wrote:
>
> The server will NEVER use these constraints.=C2=A0 It does not run XPa= th
> validation on its own output.
>
> The client can NEVER reliably use these constraints because they need = to be
> evaluated at the instant
> the RPC or notification output is generated, and the client does not h= ave
> that snapshot
> of the running or operational datastores.
>
> So just ignore these YANG details.=C2=A0 That's all real tools can= do with them
> anyway.

I tend to agree when it comes to the output / notifications.=C2=A0 But
things are less clear on the input - a server can reject the execution
of an operation if a must constraint on the input is not satisfied.

But yes, constraints on config false data, operations and
notifications are likely much less useful than constraints on
config true data.


That's what I meant.
RPC input MUST be= honored by the server or it is not implementing <rpc> correctly.

Constraints on RPC output and notification output are= for documentation purposes.
A client could try to evaluate them = with its own copies of the server's running and
operational d= atastore contents, but I think the YANG definition says the constraint
is enforced on the server.

Maybe NMDA could = clarify this issue.


/js


Andy

=C2=A0

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--94eb2c0d81804671810555c73a04-- From nobody Wed Aug 2 11:21:10 2017 Return-Path: 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 EB18D127136 for ; Wed, 2 Aug 2017 11:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 jR0H3luXEe0Z for ; Wed, 2 Aug 2017 11:21:06 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0090.outbound.protection.outlook.com [104.47.42.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12FD1270AC for ; Wed, 2 Aug 2017 11:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pWKD8dI4nwE/+Bv/LMZM0sbmZUyLe1e+7yRfXnOMFeM=; b=FC3ww1cxJRTonIaLCZvsTVJZI34EWDrNA+dbpNgSI0smulsXBf211SXidD9p86E8vDqMDDg0kYXYqtGWazDTu7/vugmEzrbP5GS/JOkCBSfV7ThsnSSCaZJAaOChSfDgfs9U2HdkBsbDxsXtgi5oo4Ogr9DUBVKwwTL2deZuqqI= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1172.namprd05.prod.outlook.com (10.160.113.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.10; Wed, 2 Aug 2017 18:21:05 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1320.010; Wed, 2 Aug 2017 18:21:05 +0000 From: Kent Watsen To: Andy Bierman , Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] accessible tree for rpcs? Thread-Index: AQHTCtwZEsEmlzSxhUeoKQkaPbrqIqJwKuAPgAC6GgCAAEiEgIAAAnOAgAAIjYD//+bvAA== Date: Wed, 2 Aug 2017 18:21:05 +0000 Message-ID: <52C938D9-B32B-4273-9DC3-268A4F0385F4@juniper.net> References: <1501631444289.92159@Aviatnet.com> <985EDF7D-1C05-4CDE-9FD1-32489D113853@juniper.net> <20170802152011.GA34706@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1172; 6:LO2EMvJMQDkPnOkld3rvnUrzFeLljTFVHBXJeZqIuWt+l2zbL5AYkxYdPnKUnhMWoPkBiEMWwRpuYG3KIA3bZ3wc7fXKke+3gy0S5PtHpT6Nb0zztL0j4LEdlnV3aTqwbMqUtZiA8UcSYK5rICrtEjgzaMUtBb+6HMge8vOQKz4+d7NrQZCpeTYvkVve5YRuKXbpy6CwNy83LG71zhGy2TSVuHFP7iCNpGk9gbOBS78yyuhnT/Ny+qtPfUkGuMb/7jomEGL2ZX0yJAxy3aCFABVG2N2fyZXkgSIAhLiE8c1ujMXTaxpUzyThTtnzm3UR0u7zt29thoR8L98UuyrQ5w==; 5:FvLfULmwd2JzYSocJewebTadFYgUnGRAS77o/SNZZ92cO7n393kNp6I+oiwUncqlXK/iURFxtcEzJ+ZPtONzvOEEftomVO2NWX+/F5UGgSuSlbllirkP+XNVLeNNwQCarSmb8uX7WvXVYwZ9uvlT+A==; 24:idwdGfIFh8EEBjh+XlF5hYyln0Y/kb5M6citQZmOKTmLsWO/njrKjGpW5ujKIq5BUlZIZMz5HLmVhvCWYEwHGPtjeANW7tyABYVSKci8ezY=; 7:MSy6dWoyWzgplNpWsQ1luZbApVLB6V9PutE/Ey+PKXEU5ZFKOVJEgffjxJ/ibilEt0qjTe3ypjOu5nENnanIGM3ezVIeT6O3eFxCIIgKLPFW2nJ6IQD7I1i/OM7LjiqCQBA38RaCLfjhvEmDL51GAUM6ed7GUdxN71N9lyJvuZI4miBX2d72wB0gypNdgVK0bWFNPqTHhOPkgL20hvCRGQ4TPVM3VfpId7rerXxwLRg= x-ms-office365-filtering-correlation-id: 9a3c9bdb-1339-48fc-7bef-08d4d9d33d49 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1172; x-ms-traffictypediagnostic: BN3PR0501MB1172: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1172; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1172; x-forefront-prvs: 0387D64A71 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39850400002)(39860400002)(39400400002)(39450400003)(39410400002)(189002)(199003)(82746002)(4001350100001)(229853002)(36756003)(66066001)(6506006)(7736002)(77096006)(6486002)(25786009)(83506001)(86362001)(83716003)(97736004)(189998001)(2950100002)(93886004)(2501003)(33656002)(105586002)(5660300001)(106356001)(50986999)(6436002)(478600001)(2900100001)(68736007)(2906002)(81166006)(8936002)(3846002)(8676002)(54896002)(3280700002)(6306002)(81156014)(14454004)(3660700001)(6512007)(76176999)(102836003)(99286003)(38730400002)(53936002)(6246003)(101416001)(6116002)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1172; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_52C938D9B32B42739DC3268A4F0385F4junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2017 18:21:05.4541 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1172 Archived-At: Subject: Re: [netmod] accessible tree for rpcs? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 18:21:09 -0000 --_000_52C938D9B32B42739DC3268A4F0385F4junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCj4gVGhhdCdzIHdoYXQgSSBtZWFudC4NCj4gUlBDIGlucHV0IE1VU1QgYmUgaG9ub3JlZCBi eSB0aGUgc2VydmVyIG9yIGl0IGlzIG5vdCBpbXBsZW1lbnRpbmcgPHJwYz4gY29ycmVjdGx5Lg0K Pg0KPiBDb25zdHJhaW50cyBvbiBSUEMgb3V0cHV0IGFuZCBub3RpZmljYXRpb24gb3V0cHV0IGFy ZSBmb3IgZG9jdW1lbnRhdGlvbiBwdXJwb3Nlcy4NCj4gQSBjbGllbnQgY291bGQgdHJ5IHRvIGV2 YWx1YXRlIHRoZW0gd2l0aCBpdHMgb3duIGNvcGllcyBvZiB0aGUgc2VydmVyJ3MgcnVubmluZyBh bmQNCj4gb3BlcmF0aW9uYWwgZGF0YXN0b3JlIGNvbnRlbnRzLCBidXQgSSB0aGluayB0aGUgWUFO RyBkZWZpbml0aW9uIHNheXMgdGhlIGNvbnN0cmFpbnQNCj4gaXMgZW5mb3JjZWQgb24gdGhlIHNl cnZlci4NCj4NCj4gTWF5YmUgTk1EQSBjb3VsZCBjbGFyaWZ5IHRoaXMgaXNzdWUuDQoNCldoYXQg d291bGQgYmUgdGhlIHVwZGF0ZT8gIFdvdWxkIHlvdSBjaGFuZ2UgdGhlIFhQYXRoIGNvbnRleHQg dGV4dCBpbiBTZWN0aW9uIDUuMQ0KdG8gbm90IGluY2x1ZGUgdGhlIGFkZGl0aW9uYWwgZGF0YXN0 b3JlIGNvbnRleHRzLCBvciBqdXN0IGFkZCBhIGNsYXJpZmljYXRpb24gdGhhdCBhbnkgc3VjaA0K Y29uc3RyYWludHMgYXJlIGp1c3QgY29uY2VwdHVhbCBhbmQgcHJpbWFyaWx5IGZvciBkZXNjcmlw dGlvbiBwdXJwb3NlPyAgQW5kLCBpZiB0aGUgbGF0dGVyLA0Kc2hvdWxkbid0IGl0IGJlIGEgY2xh cmlmaWNhdGlvbiBvbiBSRkMgNzk1MD8NCg0KS2VudA0KDQo= --_000_52C938D9B32B42739DC3268A4F0385F4junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <3CF6D4290F951340A48B3890F0CB0BBD@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVt YWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWls eTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xvcjp3aW5k b3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9u ZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwv aGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBUaGF0J3Mgd2hhdCBJIG1lYW50 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0 OyBSUEMgaW5wdXQgTVVTVCBiZSBob25vcmVkIGJ5IHRoZSBzZXJ2ZXIgb3IgaXQgaXMgbm90IGlt cGxlbWVudGluZyAmbHQ7cnBjJmd0OyBjb3JyZWN0bHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IENvbnN0cmFpbnRzIG9uIFJQ QyBvdXRwdXQgYW5kIG5vdGlmaWNhdGlvbiBvdXRwdXQgYXJlIGZvciBkb2N1bWVudGF0aW9uIHB1 cnBvc2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jmd0OyBBIGNsaWVudCBjb3VsZCB0cnkgdG8gZXZhbHVhdGUgdGhlbSB3aXRoIGl0cyBvd24g Y29waWVzIG9mIHRoZSBzZXJ2ZXIncyBydW5uaW5nIGFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBvcGVyYXRpb25hbCBkYXRhc3RvcmUg Y29udGVudHMsIGJ1dCBJIHRoaW5rIHRoZSBZQU5HIGRlZmluaXRpb24gc2F5cyB0aGUgY29uc3Ry YWludDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jmd0OyBpcyBlbmZvcmNlZCBvbiB0aGUgc2VydmVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBNYXliZSBOTURBIGNvdWxkIGNs YXJpZnkgdGhpcyBpc3N1ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCB3b3VsZCBiZSB0 aGUgdXBkYXRlPyAmbmJzcDtXb3VsZCB5b3UgY2hhbmdlIHRoZSBYUGF0aCBjb250ZXh0IHRleHQg aW4gU2VjdGlvbiA1LjE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRvIG5v dCBpbmNsdWRlIHRoZSBhZGRpdGlvbmFsIGRhdGFzdG9yZSBjb250ZXh0cywgb3IganVzdCBhZGQg YSBjbGFyaWZpY2F0aW9uIHRoYXQgYW55IHN1Y2gNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Y29uc3RyYWludHMgYXJlIGp1c3QgY29uY2VwdHVhbCBhbmQgcHJpbWFyaWx5 IGZvciBkZXNjcmlwdGlvbiBwdXJwb3NlPyZuYnNwOyBBbmQsIGlmIHRoZSBsYXR0ZXIsPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zaG91bGRuJ3QgaXQgYmUgYSBjbGFyaWZp Y2F0aW9uIG9uIFJGQyA3OTUwPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5LZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_52C938D9B32B42739DC3268A4F0385F4junipernet_-- From nobody Thu Aug 3 00:00:04 2017 Return-Path: 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 5252A131C95 for ; Thu, 3 Aug 2017 00:00:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 KbGb-k5BYfHD for ; Thu, 3 Aug 2017 00:00:01 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50132.outbound.protection.outlook.com [40.107.5.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 258CF126557 for ; Thu, 3 Aug 2017 00:00:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ka7jSgmnTvBmG0vBSOmwEwjmeJ34IpcsPxnKpSl4wSg=; b=tVSESD/PdDb4GSGARMmrD1DWmdCBMDvz2XCbkQ7pgDheuk56ZC9cq3+I2nhppD9+e0wMSfW+HPyq5PpSBt665QVGKH1udQNwklxIzYABSyj3q7DFTt63EOyZl/MY9SHAZFNQU7eC7eDthU0Wei4xo7Y1HhMvw/hTpt2jx6EnDE8= Received: from DB4PR07MB0640.eurprd07.prod.outlook.com (10.141.43.155) by DB4PR07MB331.eurprd07.prod.outlook.com (10.141.234.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1304.10; Thu, 3 Aug 2017 06:59:58 +0000 Received: from DB4PR07MB0640.eurprd07.prod.outlook.com ([fe80::b082:38f7:91ac:1e30]) by DB4PR07MB0640.eurprd07.prod.outlook.com ([fe80::b082:38f7:91ac:1e30%15]) with mapi id 15.01.1320.010; Thu, 3 Aug 2017 06:59:58 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: "netmod@ietf.org" Thread-Topic: Questions on NMDA and "merged config and state" Thread-Index: AdMMJZfihJGpR5QERlmLOT/dFpAbmw== Date: Thu, 3 Aug 2017 06:59:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; x-originating-ip: [135.245.212.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB331; 6:GQSGpGyil14rMyuXbC8w1e07WmsYlnb5ZA5NcF3kwO/V/I+GYrs4pLuX1rR0Nv6tARb6+Om8JOVzNAYGAe7ZzkK3aZCU1arbZZ+kfiipAPUlEAJXLyvT37P43L8oifOfNX/JFs1P4gVn8pTLF5AriIA/i7oUnmWdLLcbhWC8JoYxGsd3tKZB6kW/HdWb7JM/xzKrscCASYnvXSgAqhztaiHszmZPF3rd+2Ip9sYvzxWq9VEtF7SYyAZKtrHfQlN/6BpvuqsPB4WxTkJm1IPyEJcmaKo9APgDjVD+P4sBjAPAY6I0mFZUsAocMrsdIyGaPc8SXvLCuvAvAceRnHrHVw==; 5:KFiL9MfVQKSovxnQQXPFwzXqSU4TLwts4Nim6IiIT8rjpVGJmAKWmIeIBixz/fbFtahyGqRK72kHvlMr2ndJOaoYYO3gr1yHHPQJ0tm07Ac9T6eAJ6kJDOnP/1Vv7a0vFaEvKbyoflD8x00wjd8Wjg==; 24:vGst5dklJ8AMotgCo/rF2pkhOQrVRcjbILpB468Mxb2fmiGd8hsLUuzTuo3x2IdWEOb5lVkfZzO1fQSPgRbVLVqGY/3Gut5e9YGOzaztSkk=; 7:9+l+kWG2VxUlog/0L0jXLw391ocGwicvBStLFyBeI0YSbOALc2dEkPmLUYgCPkmk8SOmMxRjEjbKvOvETFXwcMZLtjhaDX9JcEBaW3mAv5cExNQNbzSOugtM1boME/MeEGohq8ebPJL5+ZZHGQp662X7qnO/HJfRQ/6GlMxseFOGQkGtz8LnB15iTTSrjzlcLdpzRdr+blq9CsHJ695c9gmmT+mWJM1jxRgxTQH+coo= x-ms-office365-filtering-correlation-id: 624c81a4-92c5-430c-3078-08d4da3d411b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603031)(49563074)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB4PR07MB331; x-ms-traffictypediagnostic: DB4PR07MB331: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB331; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB331; x-forefront-prvs: 03883BD916 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39400400002)(39850400002)(39860400002)(39840400002)(39410400002)(199003)(189002)(33656002)(105586002)(189998001)(2906002)(9326002)(3280700002)(2900100001)(9686003)(74316002)(25786009)(50986999)(54356999)(2501003)(99936001)(5250100002)(101416001)(2351001)(3846002)(66066001)(790700001)(6116002)(102836003)(6916009)(53936002)(7696004)(106356001)(1730700003)(81156014)(81166006)(6436002)(6506006)(38730400002)(8676002)(110136004)(55016002)(99286003)(7736002)(8936002)(97736004)(5660300001)(6306002)(14454004)(54896002)(5640700003)(5630700001)(478600001)(68736007)(86362001)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR07MB331; H:DB4PR07MB0640.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0048_01D30C36.E10D7840" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Aug 2017 06:59:58.5774 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB331 Archived-At: Subject: [netmod] Questions on NMDA and "merged config and state" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 07:00:03 -0000 ------=_NextPart_000_0048_01D30C36.E10D7840 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0049_01D30C36.E10D7840" ------=_NextPart_001_0049_01D30C36.E10D7840 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Just to get confirmation on my assumptions: In section 4.7.3 the origin metadata does not include 'running' as origin but only 'intended'. So it seems to be mandatory for a NC server to support the intended datastore? With the introduction of the operational datastore I assume it also means that when someone wants to know what the client has configured on the device a get-config on the running datastore is required while to know the 'in-use' configuration a get(-config) on the operational datastore is required? The Guidelines for YANG Module Authors (NMDA) - draft-dsdt-nmda-guidelines mentions that a derived module can be generated from the YANG models where state and config are merged in a single branch. In the simple example this results in another YANG model with its own namespace. I assume that this state YANG model will then also show up in the hello message? Best regards, Bart ------=_NextPart_001_0049_01D30C36.E10D7840 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Just to get confirmation on my = assumptions:

In section 4.7.3 the origin metadata does not include = ‘running’ as origin but only ‘intended’.  = So it seems to be mandatory for a NC server to support the intended = datastore?

 

With the introduction of the operational datastore I assume = it also means that when someone wants to know what the client has = configured on the device a get-config on the running datastore is = required while to know the ‘in-use’ configuration a = get(-config) on the operational datastore is = required?

 

The Guidelines for YANG Module Authors (NMDA) – = draft-dsdt-nmda-guidelines mentions that a derived module can be = generated from the YANG models where state and config are merged in a = single branch.  In the simple example this results in another YANG = model with its own namespace.  I assume that this state YANG model = will then also show up in the hello message?

 

Best regards,

Bart

------=_NextPart_001_0049_01D30C36.E10D7840-- ------=_NextPart_000_0048_01D30C36.E10D7840 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT 8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0 MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0 QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7 GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9 xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE 7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/ PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ 88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo +lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5 JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL 6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45 qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6 eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO 5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74 4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0 MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB 0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt 9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH 9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI /fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos 2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P /jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO 0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MDMwNjU5NTZaMCMGCSqGSIb3DQEJBDEWBBQQFQU2 kNdHwrQokaZwFyR7eb4LajCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9 xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAEyHy+eJWn/B8c7Nj8Du3ETOoUhgT5ezeGte2DG0wni799mlamoSgF+6GN3V dDDcvtKdkhAmEaxEvfAFe7NrzlQf1/u2pi+Yvfwxg3cpA6j3j4X3G87tHPEk0Gt/vBJC00mPI83W PAd5nWffgOVdU2hI6Jpzs14DjMsa9jYwcROaW46btz6BavbrEJM8ecXDkOqlhJIYl4yFFoiMqziK 2PXW4Tt55IoLTZwY0Td9RfEPJmqXcxhKK+HhswHNDG0cv6UkgYTQhm/+QaYs1GA3xO/hnNDkhkvb vXm51q0KhT0ENw5Tx+NBP8eOEBgJseJKZ5wCC6fk2rdiiFZFTwL7qPIAAAAAAAA= ------=_NextPart_000_0048_01D30C36.E10D7840-- From nobody Thu Aug 3 00:49:32 2017 Return-Path: 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 F2E5A131C31 for ; Thu, 3 Aug 2017 00:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 r4OgU3sO4D3r for ; Thu, 3 Aug 2017 00:49:28 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C98D124234 for ; Thu, 3 Aug 2017 00:49:28 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id EA65D3D; Thu, 3 Aug 2017 09:49:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id EnBSA-xQWSQS; Thu, 3 Aug 2017 09:49:24 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 3 Aug 2017 09:49:26 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id C7028200B8; Thu, 3 Aug 2017 09:49:26 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jUrJfgEVtUpa; Thu, 3 Aug 2017 09:49:26 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5CF74200AA; Thu, 3 Aug 2017 09:49:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id DBD7A4007BEE; Thu, 3 Aug 2017 09:49:25 +0200 (CEST) Date: Thu, 3 Aug 2017 09:49:25 +0200 From: Juergen Schoenwaelder To: "Bogaert, Bart (Nokia - BE/Antwerp)" Cc: "netmod@ietf.org" Message-ID: <20170803074925.GA35421@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] Questions on NMDA and "merged config and state" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 07:49:31 -0000 On Thu, Aug 03, 2017 at 06:59:58AM +0000, Bogaert, Bart (Nokia - BE/Antwerp) wrote: > > Just to get confirmation on my assumptions: > > In section 4.7.3 the origin metadata does not include 'running' as origin > but only 'intended'. So it seems to be mandatory for a NC server to support > the intended datastore? If your server does not support templates or inactive configuration or the like, then intended is just an alias for running. I do not think you need to expose intended in this case. Still, the value of the origin attribute is 'intended' since in the general case, the configuration is coming from . > With the introduction of the operational datastore I assume it also means > that when someone wants to know what the client has configured on the device > a get-config on the running datastore is required while to know the 'in-use' > configuration a get(-config) on the operational datastore is required? Yes. The operation, however, is likely called get-data in NETCONF, at least this is what draft-dsdt-nmda-netconf-00 suggested. > The Guidelines for YANG Module Authors (NMDA) - draft-dsdt-nmda-guidelines > mentions that a derived module can be generated from the YANG models where > state and config are merged in a single branch. In the simple example this > results in another YANG model with its own namespace. I assume that this > state YANG model will then also show up in the hello message? The general idea is that we produce YANG modules that have config and state merged into a single branch. Out of this YANG module, people may generate a separate module that consists of the config false nodes plus any additional key nodes needed to make it work. Such a YANG module will be treated as any other YANG module. Note that YANG 1.1 started to move module announcements to the ietf-yang-library to avoid very long module announcements during session startup. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Aug 3 09:26:34 2017 Return-Path: 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 442BA13236D for ; Thu, 3 Aug 2017 09:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com 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 EL_5POoiaQ-O for ; Thu, 3 Aug 2017 09:26:31 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD420132369 for ; Thu, 3 Aug 2017 09:26:30 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id f21so7677473wrf.5 for ; Thu, 03 Aug 2017 09:26:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=agL08/TMEUHnxITrICARtqRTKrGIY2i1Y33BrExFtPE=; b=jL/r58Fudeof41hef9JOyYzuaKlZI7Gg0TG2bv51obP2VqR/JWwbBhBZJ8PpcOycYi HzigsKn9KZixrWt4KzWr1svwWqPOWjWuh0TlMzqJFvGjn0Ly2UAXSxf4R+fUovGqu8DA /wi1GLFfZayRODr8MuWwZB1C7MnWZR8Ez5mNullT5oRcK7OAcxwYwrvj++hX9m6f5fnF y3Iic0lYPSxcAY4lC3De4wcwIgRId2MZWwaEv7kjXX5M8qWUaYSbBZaT1A2/D89srj5S Z0vWFN6Q/T/wtCd+mVswJukWIrujgX+BsFEhE0PyoRVm6GuoabRozV/GRHHueDLy85c7 wYrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=agL08/TMEUHnxITrICARtqRTKrGIY2i1Y33BrExFtPE=; b=mdEdRMlx+CEhBoNK3dqLfuLMJT5vr6xjQUhbqBVxmQV5aEX8G9hZrG0AeCuC1ZJK2u aUkOR0Cyipp0PkqzpoD3GvlvuQ2Ma0e13VDE8WWGAXSlAbqYQQDIDK//Xj+o9QwDf3eF 3JM+aab3/c2X0My8WII2VqUMNXIeFBHhT2Es2qVwLCBsKdBFjI8lztPk6r/mMmKkowLW PrUvH95rB6RoeGvj7zthAtg9l5gCLXkCqH2Xjqi2cZuI9bHeLaPJd+DCApZZqu1QI8AI Pdqoe89qKKMc2/HrcXaW6kBHPBrfzBZCetJ8vCxN9AsqP465eL2KEh6hmGaGGzkmjdcW DmOQ== X-Gm-Message-State: AIVw110hSX4CK9Zq+IhYP4ZybUgGNhfrj7IN/Dri0cP7kIH0g7g+zVq2 jK8O7U4sbK/+VWQ3xwM5hxq0uskLLq8F X-Received: by 10.223.134.39 with SMTP id 36mr1783533wrv.244.1501777091790; Thu, 03 Aug 2017 09:18:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.160 with HTTP; Thu, 3 Aug 2017 09:18:10 -0700 (PDT) In-Reply-To: <20170803074925.GA35421@elstar.local> References: <20170803074925.GA35421@elstar.local> From: Andy Bierman Date: Thu, 3 Aug 2017 09:18:10 -0700 Message-ID: To: Juergen Schoenwaelder , "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a1146c38016b97e0555dbba1a" Archived-At: Subject: Re: [netmod] Questions on NMDA and "merged config and state" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 16:26:33 -0000 --001a1146c38016b97e0555dbba1a Content-Type: text/plain; charset="UTF-8" On Thu, Aug 3, 2017 at 12:49 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Aug 03, 2017 at 06:59:58AM +0000, Bogaert, Bart (Nokia - > BE/Antwerp) wrote: > > > > Just to get confirmation on my assumptions: > > > > In section 4.7.3 the origin metadata does not include 'running' as origin > > but only 'intended'. So it seems to be mandatory for a NC server to > support > > the intended datastore? > > If your server does not support templates or inactive configuration or > the like, then intended is just an alias for running. IMO this is not correct. There are no standards at all to define these things. Our server supports an implementation of config templates that expands the template when it is first created. A different proprietary implementation MAY choose to expand templates in some other way. Since there are no standards for this purpose, any proprietary implementation decision is valid. The contents of the "intended" datastore are purely proprietary. The opaque nature of this datastore is by design and the WG accepts that servers are free to choose to implement whatever datastores they want. The origin metadata should just reflect what the server does, not mandate any sort of datastore conformance. Andy > I do not think > you need to expose intended in this case. Still, the value of the > origin attribute is 'intended' since in the general case, the > configuration is coming from . > > > With the introduction of the operational datastore I assume it also means > > that when someone wants to know what the client has configured on the > device > > a get-config on the running datastore is required while to know the > 'in-use' > > configuration a get(-config) on the operational datastore is required? > > Yes. The operation, however, is likely called get-data in NETCONF, at > least this is what draft-dsdt-nmda-netconf-00 suggested. > > > The Guidelines for YANG Module Authors (NMDA) - > draft-dsdt-nmda-guidelines > > mentions that a derived module can be generated from the YANG models > where > > state and config are merged in a single branch. In the simple example > this > > results in another YANG model with its own namespace. I assume that this > > state YANG model will then also show up in the hello message? > > The general idea is that we produce YANG modules that have config and > state merged into a single branch. Out of this YANG module, people may > generate a separate module that consists of the config false nodes > plus any additional key nodes needed to make it work. Such a YANG > module will be treated as any other YANG module. Note that YANG 1.1 > started to move module announcements to the ietf-yang-library to avoid > very long module announcements during session startup. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1146c38016b97e0555dbba1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 3, 2017 at 12:49 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Aug 03, 2017 at 06:59:58AM +0000, Bogaert, B= art (Nokia - BE/Antwerp) wrote:
>
> Just to get confirmation on my assumptions:
>
> In section 4.7.3 the origin metadata does not include 'running'= ; as origin
> but only 'intended'.=C2=A0 So it seems to be mandatory for a N= C server to support
> the intended datastore?

If your server does not support templates or inactive configuration or
the like, then intended is just an alias for running.

IMO this is not correct.
There are no = standards at all to define these things.
Our server supports an i= mplementation of config templates that expands the
template when = it is first created.=C2=A0 A different proprietary implementation MAY choos= e
to expand templates in some other way.=C2=A0 Since there are no= standards for this purpose,
any proprietary implementation decis= ion is valid.

The contents of the "intended&q= uot; datastore are purely proprietary.
The opaque nature of this = datastore is by design and the WG accepts that servers
are free t= o choose to implement whatever datastores they want.
The origin m= etadata should just reflect what the server does, not mandate
any= sort of datastore conformance.


And= y


=C2=A0
I do not think
you need to expose intended in this case. Still, the value of the
origin attribute is 'intended' since in the general case, the
configuration is coming from <intended>.

> With the introduction of the operational datastore I assume it also me= ans
> that when someone wants to know what the client has configured on the = device
> a get-config on the running datastore is required while to know the &#= 39;in-use'
> configuration a get(-config) on the operational datastore is required?=

Yes. The operation, however, is likely called get-data in NETCONF, at
least this is what draft-dsdt-nmda-netconf-00 suggested.

> The Guidelines for YANG Module Authors (NMDA) - draft-dsdt-nmda-guidel= ines
> mentions that a derived module can be generated from the YANG models w= here
> state and config are merged in a single branch.=C2=A0 In the simple ex= ample this
> results in another YANG model with its own namespace.=C2=A0 I assume t= hat this
> state YANG model will then also show up in the hello message?

The general idea is that we produce YANG modules that have config and
state merged into a single branch. Out of this YANG module, people may
generate a separate module that consists of the config false nodes
plus any additional key nodes needed to make it work. Such a YANG
module will be treated as any other YANG module. Note that YANG 1.1
started to move module announcements to the ietf-yang-library to avoid
very long module announcements during session startup.

/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--001a1146c38016b97e0555dbba1a-- From nobody Thu Aug 3 09:32:40 2017 Return-Path: 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 CB21C132451 for ; Thu, 3 Aug 2017 09:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 m11KmG3DL-1g for ; Thu, 3 Aug 2017 09:32:37 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D106F131D08 for ; Thu, 3 Aug 2017 09:32:36 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id A560E76; Thu, 3 Aug 2017 18:32:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id zNbI9opfE5HD; Thu, 3 Aug 2017 18:32:32 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 3 Aug 2017 18:32:35 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 606E4200BC; Thu, 3 Aug 2017 18:32:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FTWnk6MuzFob; Thu, 3 Aug 2017 18:32:35 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0C429200BA; Thu, 3 Aug 2017 18:32:34 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A9C504008721; Thu, 3 Aug 2017 18:32:34 +0200 (CEST) Date: Thu, 3 Aug 2017 18:32:34 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" Message-ID: <20170803163234.GB36084@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" References: <20170803074925.GA35421@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] Questions on NMDA and "merged config and state" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 16:32:40 -0000 On Thu, Aug 03, 2017 at 09:18:10AM -0700, Andy Bierman wrote: > On Thu, Aug 3, 2017 at 12:49 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Thu, Aug 03, 2017 at 06:59:58AM +0000, Bogaert, Bart (Nokia - > > BE/Antwerp) wrote: > > > > > > Just to get confirmation on my assumptions: > > > > > > In section 4.7.3 the origin metadata does not include 'running' as origin > > > but only 'intended'. So it seems to be mandatory for a NC server to > > support > > > the intended datastore? > > > > If your server does not support templates or inactive configuration or > > the like, then intended is just an alias for running. > > IMO this is not correct. > There are no standards at all to define these things. > Our server supports an implementation of config templates that expands the > template when it is first created. A different proprietary implementation > MAY choose > to expand templates in some other way. Since there are no standards for > this purpose, > any proprietary implementation decision is valid. So your implementation allows a client to write something to that transforms into something different at the time it is written (or committed I assume)? Anyway, my statement was: If your server does not support templates or inactive configuration or the like, then intended is just an alias for running. So it does not apply to your implementation. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Aug 3 09:49:32 2017 Return-Path: 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 4F7761323FB for ; Thu, 3 Aug 2017 09:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com 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 6gUUbs7puPUL for ; Thu, 3 Aug 2017 09:49:28 -0700 (PDT) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40D181323C6 for ; Thu, 3 Aug 2017 09:49:28 -0700 (PDT) Received: by mail-wm0-x22e.google.com with SMTP id k20so6032673wmg.0 for ; Thu, 03 Aug 2017 09:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=MaMdoSjhoTozOtWYugHICkSuHVwmONwhizeNd2boWvQ=; b=R9wgJMoBcV+wri1QxVIg6PUSfylwpgJ6BtaH1OD6D8YqBFEvCxtQi8HY3nYih65k8h 17tED+KIlAk4lqhhtD+qIPm1HO+dprK7BrZ9dzDQeClqcbx1E0/HcE/pZc90oiSJG9qm oQpt8bEIo06UoB2GMDZebdpC+TP5vBqOm97ShssZ3xun0fqWYDOi0hkbPjjICoSqnGJ4 8ccB4rPgFt4fx47uakfEYdcoq+GxGtc30plRBqcb42uV9VfJxvljBfWaeZPu0cOPIHEW 4VYcekTStWN10OkliZMZZ9ff0DfUC2k/lxFAuFkWnMaQa13lRTtJyXU9DnUPQc8lq6X8 ZZqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=MaMdoSjhoTozOtWYugHICkSuHVwmONwhizeNd2boWvQ=; b=na+uZr3cx5Xw92Lh4e0KCU+ynWbkcDN1yQT7/Th7feTk1WDrbNorLiJg84dtPDK2gL SS4B/0qopT0nEldr2NJpdDewv93GKZHbqUGTm/Y+hVF0FMUsBs9eBqBzd7RtpQXaTIje SXMYknDx0keyqFCwUnJFT6lTOceMLjbM+iseBQrK8J8QQn3OB1KzsFsxoBY72YB90sF3 Co0/NBTmC9cEmmYJQJgAqj0z+DHwxS/fOK2vhTD4M1ql/RWAH8bln4gYNOhvpCaiWk/9 iccJfl3oWN5nwaL+k61ilEKJSVDKpi0jAo1jAhM1VCR3aXHkkmzgkDZ98W5VvSAWmvxX onnQ== X-Gm-Message-State: AIVw111SFDIhMdnRwXUsuyWKjNPH0iajfcQoXo/zu11mXi5lYkiC8muh YJBsCK/Dj7NKBJ0Aggy+fTY9FdJ4acKg X-Received: by 10.28.163.198 with SMTP id m189mr1516579wme.154.1501778966740; Thu, 03 Aug 2017 09:49:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.160 with HTTP; Thu, 3 Aug 2017 09:49:25 -0700 (PDT) In-Reply-To: <20170803163234.GB36084@elstar.local> References: <20170803074925.GA35421@elstar.local> <20170803163234.GB36084@elstar.local> From: Andy Bierman Date: Thu, 3 Aug 2017 09:49:25 -0700 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a114cd998d821bf0555dc2969" Archived-At: Subject: Re: [netmod] Questions on NMDA and "merged config and state" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 16:49:30 -0000 --001a114cd998d821bf0555dc2969 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 3, 2017 at 9:32 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Aug 03, 2017 at 09:18:10AM -0700, Andy Bierman wrote: > > On Thu, Aug 3, 2017 at 12:49 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Thu, Aug 03, 2017 at 06:59:58AM +0000, Bogaert, Bart (Nokia - > > > BE/Antwerp) wrote: > > > > > > > > Just to get confirmation on my assumptions: > > > > > > > > In section 4.7.3 the origin metadata does not include 'running' as > origin > > > > but only 'intended'. So it seems to be mandatory for a NC server to > > > support > > > > the intended datastore? > > > > > > If your server does not support templates or inactive configuration or > > > the like, then intended is just an alias for running. > > > > IMO this is not correct. > > There are no standards at all to define these things. > > Our server supports an implementation of config templates that expands > the > > template when it is first created. A different proprietary > implementation > > MAY choose > > to expand templates in some other way. Since there are no standards for > > this purpose, > > any proprietary implementation decision is valid. > > So your implementation allows a client to write something to > that transforms into something different at the time it is written (or > committed I assume)? Anyway, my statement was: > > If your server does not support templates or inactive configuration or > the like, then intended is just an alias for running. > > So it does not apply to your implementation. > > IMO the concept of NMDA conformance is still very under-specified. There should be a clear statement in RFC 2119 terms for the exact datastores that are considered standard datastores. This needs to be 100% backward compatible with RFC 7950 and RFC 6241 requirements for the 3 traditional datastores. I don't care if new datastore usage is unbounded, as long as the client developer knows what to expect from an NMDA-compliant server. The WG needs to deliberately (not haphazardly) determine the interoperability boundaries. /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a114cd998d821bf0555dc2969 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 3, 2017 at 9:32 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Aug 03, 2017 at 09:18:10AM -0700, Andy Bierma= n wrote:
> On Thu, Aug 3, 2017 at 12:49 AM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > On Thu, Aug 03, 2017 at 06:59:58AM +0000, Bogaert, Bart (Nokia -<= br> > > BE/Antwerp) wrote:
> > >
> > > Just to get confirmation on my assumptions:
> > >
> > > In section 4.7.3 the origin metadata does not include 'r= unning' as origin
> > > but only 'intended'.=C2=A0 So it seems to be mandato= ry for a NC server to
> > support
> > > the intended datastore?
> >
> > If your server does not support templates or inactive configurati= on or
> > the like, then intended is just an alias for running.
>
> IMO this is not correct.
> There are no standards at all to define these things.
> Our server supports an implementation of config templates that expands= the
> template when it is first created.=C2=A0 A different proprietary imple= mentation
> MAY choose
> to expand templates in some other way.=C2=A0 Since there are no standa= rds for
> this purpose,
> any proprietary implementation decision is valid.

So your implementation allows a client to write something to <running>= ;
that transforms into something different at the time it is written (or
committed I assume)? Anyway, my statement was:

=C2=A0 If your server does not support templates or inactive configuration = or
=C2=A0 the like, then intended is just an alias for running.

So it does not apply to your implementation.



IMO the concept of NMDA conformance i= s still very under-specified.
There should be a clear statement i= n RFC 2119 terms for the exact
datastores that are considered sta= ndard datastores.=C2=A0 This needs to be 100% backward
compatible= with RFC 7950 and RFC 6241 requirements for the 3 traditional datastores.= =C2=A0
I don't care if new datastore usage is unbounded, as l= ong as the client developer
knows what to expect from an NMDA-com= pliant server.

The WG needs to deliberately (not h= aphazardly) determine the interoperability boundaries.

=

/js


Andy
=C2=A0
=
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--001a114cd998d821bf0555dc2969-- From nobody Thu Aug 3 09:53:53 2017 Return-Path: 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 1AA0F13246C for ; Thu, 3 Aug 2017 09:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 spyGKkwYQXxh for ; Thu, 3 Aug 2017 09:53:50 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F49F1324A0 for ; Thu, 3 Aug 2017 09:53:50 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 11ED576; Thu, 3 Aug 2017 18:53:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 8VRmrtDKUbzs; Thu, 3 Aug 2017 18:53:46 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 3 Aug 2017 18:53:48 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE6EB200B8; Thu, 3 Aug 2017 18:53:48 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7vXjwM_LcGCR; Thu, 3 Aug 2017 18:53:48 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6148E200AA; Thu, 3 Aug 2017 18:53:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4691F4008908; Thu, 3 Aug 2017 18:53:48 +0200 (CEST) Date: Thu, 3 Aug 2017 18:53:48 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" Message-ID: <20170803165348.GD36084@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" References: <20170803074925.GA35421@elstar.local> <20170803163234.GB36084@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] Questions on NMDA and "merged config and state" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 16:53:52 -0000 On Thu, Aug 03, 2017 at 09:49:25AM -0700, Andy Bierman wrote: > On Thu, Aug 3, 2017 at 9:32 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Thu, Aug 03, 2017 at 09:18:10AM -0700, Andy Bierman wrote: > > > On Thu, Aug 3, 2017 at 12:49 AM, Juergen Schoenwaelder < > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > On Thu, Aug 03, 2017 at 06:59:58AM +0000, Bogaert, Bart (Nokia - > > > > BE/Antwerp) wrote: > > > > > > > > > > Just to get confirmation on my assumptions: > > > > > > > > > > In section 4.7.3 the origin metadata does not include 'running' as > > origin > > > > > but only 'intended'. So it seems to be mandatory for a NC server to > > > > support > > > > > the intended datastore? > > > > > > > > If your server does not support templates or inactive configuration or > > > > the like, then intended is just an alias for running. > > > > > > IMO this is not correct. > > > There are no standards at all to define these things. > > > Our server supports an implementation of config templates that expands > > the > > > template when it is first created. A different proprietary > > implementation > > > MAY choose > > > to expand templates in some other way. Since there are no standards for > > > this purpose, > > > any proprietary implementation decision is valid. > > > > So your implementation allows a client to write something to > > that transforms into something different at the time it is written (or > > committed I assume)? Anyway, my statement was: > > > > If your server does not support templates or inactive configuration or > > the like, then intended is just an alias for running. > > > > So it does not apply to your implementation. > > > > > > IMO the concept of NMDA conformance is still very under-specified. Seems you are changing topic. > There should be a clear statement in RFC 2119 terms for the exact > datastores that are considered standard datastores. This needs to > be 100% backward compatible with RFC 7950 and RFC 6241 requirements > for the 3 traditional datastores. The protocols (with their various capabilities) expose different sets of datastores. I agree, the protocol documents should state clearly what is required to expose for the different protocols and what is optional to expose. > I don't care if new datastore usage is unbounded, as long as the > client developer knows what to expect from an NMDA-compliant server. > > The WG needs to deliberately (not haphazardly) determine the > interoperability boundaries. Yes, but it is not this WG but the other WG I think. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Aug 3 10:06:37 2017 Return-Path: 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 1A8921323A3 for ; Thu, 3 Aug 2017 10:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com 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 X13UlHsyHZdJ for ; Thu, 3 Aug 2017 10:06:34 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CE9D1320D4 for ; Thu, 3 Aug 2017 10:06:26 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id 33so8096545wrz.4 for ; Thu, 03 Aug 2017 10:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=zvCzMOTK8B8lESm2CRAg8hVlsB79Ht1zpLTskASXx1k=; b=i04OPUXQSzWLzJhPLQYtoeewSOfgUikBIBgkoVHWPaeYE1EEZkVCQ19n0l5vGBpJmN ZezdP8YqmeWdzy60kBY465cyb58U17lhTqat4NRY8ShATCGOCz+g10j4HcBAbRQozBmt WVmWUTxxpfM6QPkQc/1euzvNXOJ/hA7C0ILo1zOpD5gloBpWMrKi0z3zH35mZj+oJo7r 1YhidRGNGdI+eSEJfTf1Bh7rSj/VyZSDhO5csggFI91CWwiS1pLtxlc7j5CPVRIpWvsk c4rPQLYmiDwsChx6bzpJlN4BYlL1hfyPmm6ljugVbayyp+bRlMzE2Af7yX+eDvz4KG3p wlcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=zvCzMOTK8B8lESm2CRAg8hVlsB79Ht1zpLTskASXx1k=; b=gnFpspxlDx+miVgReIBBW3/PofAPJaoiUonpOmcYUgtlYMd+XWHn1YRpdqDnC4YoUs 5XqRWhRog0diMgwLNceBsvfOb9wEyWu53oLeuK0PSjmXDeawBBpGrvoEDJcO4xViTr3Q cycnow68duKOtI1cqW0fJILVchSJHcF95n8EelFzPIUpdcadDN+5OdvyoYQ0qTUsC+L2 k11M25hEtPD67PjnrDCQnjCsaTidItmgRV16MB7yUSiGDYoORpzV7ab5B5Bfma9FVtys ExO8blc2tLZkpld883ayvVAIvCcTXedFdZyOrBjUgb2zJPUt3+uSknRELyG/v7irAuaR l0Ig== X-Gm-Message-State: AIVw1104pz2Uyp8FbrbktSmqknpy6UtbVgeS3T16sAdPVbjV0qMT2UQf ns/xrce1KXR06Kbsep49gxv8d+SMm8sg X-Received: by 10.223.136.176 with SMTP id f45mr2064191wrf.289.1501779984563; Thu, 03 Aug 2017 10:06:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.160 with HTTP; Thu, 3 Aug 2017 10:06:23 -0700 (PDT) In-Reply-To: <20170803165348.GD36084@elstar.local> References: <20170803074925.GA35421@elstar.local> <20170803163234.GB36084@elstar.local> <20170803165348.GD36084@elstar.local> From: Andy Bierman Date: Thu, 3 Aug 2017 10:06:23 -0700 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="001a11492e6c82cf570555dc6696" Archived-At: Subject: Re: [netmod] Questions on NMDA and "merged config and state" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 17:06:36 -0000 --001a11492e6c82cf570555dc6696 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 3, 2017 at 9:53 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Aug 03, 2017 at 09:49:25AM -0700, Andy Bierman wrote: > > On Thu, Aug 3, 2017 at 9:32 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Thu, Aug 03, 2017 at 09:18:10AM -0700, Andy Bierman wrote: > > > > On Thu, Aug 3, 2017 at 12:49 AM, Juergen Schoenwaelder < > > > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > > > > > On Thu, Aug 03, 2017 at 06:59:58AM +0000, Bogaert, Bart (Nokia - > > > > > BE/Antwerp) wrote: > > > > > > > > > > > > Just to get confirmation on my assumptions: > > > > > > > > > > > > In section 4.7.3 the origin metadata does not include 'running' > as > > > origin > > > > > > but only 'intended'. So it seems to be mandatory for a NC > server to > > > > > support > > > > > > the intended datastore? > > > > > > > > > > If your server does not support templates or inactive > configuration or > > > > > the like, then intended is just an alias for running. > > > > > > > > IMO this is not correct. > > > > There are no standards at all to define these things. > > > > Our server supports an implementation of config templates that > expands > > > the > > > > template when it is first created. A different proprietary > > > implementation > > > > MAY choose > > > > to expand templates in some other way. Since there are no standards > for > > > > this purpose, > > > > any proprietary implementation decision is valid. > > > > > > So your implementation allows a client to write something to > > > that transforms into something different at the time it is written (or > > > committed I assume)? Anyway, my statement was: > > > > > > If your server does not support templates or inactive configuration > or > > > the like, then intended is just an alias for running. > > > > > > So it does not apply to your implementation. > > > > > > > > > > IMO the concept of NMDA conformance is still very under-specified. > > Seems you are changing topic. > > > There should be a clear statement in RFC 2119 terms for the exact > > datastores that are considered standard datastores. This needs to > > be 100% backward compatible with RFC 7950 and RFC 6241 requirements > > for the 3 traditional datastores. > > The protocols (with their various capabilities) expose different sets > of datastores. I agree, the protocol documents should state clearly > what is required to expose for the different protocols and what is > optional to expose. > > > I don't care if new datastore usage is unbounded, as long as the > > client developer knows what to expect from an NMDA-compliant server. > > > > The WG needs to deliberately (not haphazardly) determine the > > interoperability boundaries. > > Yes, but it is not this WG but the other WG I think. > So you are saying there is no such thing as an NMDA-compliant server. There are protocols that may use specific datastores in various ways. Different protocols can have different behavior for the same datastore. Sounds very fun for client developers to figure out. > > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a11492e6c82cf570555dc6696 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 3, 2017 at 9:53 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Aug 03, 2017 at 09:49:25AM -0700, Andy Bierma= n wrote:
> On Thu, Aug 3, 2017 at 9:32 AM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > On Thu, Aug 03, 2017 at 09:18:10AM -0700, Andy Bierman wrote:
> > > On Thu, Aug 3, 2017 at 12:49 AM, Juergen Schoenwaelder <<= br> > > > j.sc= hoenwaelder@jacobs-university.de> wrote:
> > >
> > > > On Thu, Aug 03, 2017 at 06:59:58AM +0000, Bogaert, Bart= (Nokia -
> > > > BE/Antwerp) wrote:
> > > > >
> > > > > Just to get confirmation on my assumptions:
> > > > >
> > > > > In section 4.7.3 the origin metadata does not incl= ude 'running' as
> > origin
> > > > > but only 'intended'.=C2=A0 So it seems to = be mandatory for a NC server to
> > > > support
> > > > > the intended datastore?
> > > >
> > > > If your server does not support templates or inactive c= onfiguration or
> > > > the like, then intended is just an alias for running. > > >
> > > IMO this is not correct.
> > > There are no standards at all to define these things.
> > > Our server supports an implementation of config templates th= at expands
> > the
> > > template when it is first created.=C2=A0 A different proprie= tary
> > implementation
> > > MAY choose
> > > to expand templates in some other way.=C2=A0 Since there are= no standards for
> > > this purpose,
> > > any proprietary implementation decision is valid.
> >
> > So your implementation allows a client to write something to <= running>
> > that transforms into something different at the time it is writte= n (or
> > committed I assume)? Anyway, my statement was:
> >
> >=C2=A0 =C2=A0If your server does not support templates or inactive= configuration or
> >=C2=A0 =C2=A0the like, then intended is just an alias for running.=
> >
> > So it does not apply to your implementation.
> >
> >
>
> IMO the concept of NMDA conformance is still very under-specified.

Seems you are changing topic.

> There should be a clear statement in RFC 2119 terms for the exact
> datastores that are considered standard datastores.=C2=A0 This needs t= o
> be 100% backward compatible with RFC 7950 and RFC 6241 requirements > for the 3 traditional datastores.

The protocols (with their various capabilities) expose different sets
of datastores. I agree, the protocol documents should state clearly
what is required to expose for the different protocols and what is
optional to expose.

> I don't care if new datastore usage is unbounded, as long as the > client developer knows what to expect from an NMDA-compliant server. >
> The WG needs to deliberately (not haphazardly) determine the
> interoperability boundaries.

Yes, but it is not this WG but the other WG I think.
<= br>
So you are saying there is no such thing as an NMDA-compliant= server.
There are protocols that may use specific datastores in = various ways.
Different protocols can have different behavior for= the same datastore.
Sounds very fun for client developers to fig= ure out.

=C2=A0

/js


Andy
=C2=A0
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--001a11492e6c82cf570555dc6696-- From wi274w@intl.att.com Thu Aug 3 02:24:19 2017 Return-Path: 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 DDBE1131CBF for ; Thu, 3 Aug 2017 02:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8] 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 9ZkpBE86M9BG for ; Thu, 3 Aug 2017 02:24:18 -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 881F8126CC4 for ; Thu, 3 Aug 2017 02:24:18 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v739F7E8039453 for ; Thu, 3 Aug 2017 05:24:15 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 2c3yggkpwx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 03 Aug 2017 05:24:15 -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 v739OEVf020841 for ; Thu, 3 Aug 2017 05:24:14 -0400 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v739OBVb020836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 3 Aug 2017 05:24:14 -0400 Received: from gbcdccas03.intl.att.com (gbcdccas03.intl.att.com [135.76.180.11]) by mlpi408.sfdc.sbc.com (RSA Interceptor) for ; Thu, 3 Aug 2017 09:24:00 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.0351.000; Thu, 3 Aug 2017 10:23:59 +0100 From: "Ivory, William" To: "'netmod@ietf.org'" Thread-Topic: Query about augmenting module from submodule in YANG 1.0 Thread-Index: AdMMOPUClm48yMKSSEeEurX4RbXaiA== Date: Thu, 3 Aug 2017 09:22:57 +0000 Deferred-Delivery: Thu, 3 Aug 2017 09:23:58 +0000 Message-ID: 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_E3378E0605547F4E854DEE0CB1116AB020865Bgbcdcmbx03intlatt_" 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-03_05:, , 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=1031 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1708030141 Archived-At: X-Mailman-Approved-At: Thu, 03 Aug 2017 11:26:40 -0700 Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Aug 2017 10:00:56 -0000 --_000_E3378E0605547F4E854DEE0CB1116AB020865Bgbcdcmbx03intlatt_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi, 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. H= owever, despite the wording below in YANG 1.0 section 7.15, we've found a c= ouple 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/c= urrent/msg15418.html '> On 01 Mar 2016, at 10:38, Anton Tk=E1=E8ik wrote: > > Hi, > Noticed other issue with example set, > In https://github.com/mbj4668/pyang/issues/194 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 pare= nt module? This isn't possible in YANG 1.0 but will be possible in 1.1. However, in th= e present case the definition being augmented from the submodule is arguabl= y in a different module. Lada ' Thanks, William --_000_E3378E0605547F4E854DEE0CB1116AB020865Bgbcdcmbx03intlatt_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hi,

 

We’re trying to solve a m= odularity problem with a YANG module by splitting it into submodules and au= gmenting 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 allowe= d in YANG 1.1?  Would appreciate clarification.

 

RFC 6020 section 7.15 suggests = it is allowed:

 

‘

   The "augment" statement allows a mo= dule 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=

 

‘> On 01 Mar 2016, at 10:38, Anto=
n Tk=E1=E8ik <anton.tkacik at pantheon.tech> wrote:
> 
> Hi,
> Noticed other issue with example set,
> In https:=
//github.com/mbj4668/pyang/issues/194 Lada stated that in YANG 1.0 subm=
odule 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 ar=
guably in a different module.
 
Lada

‘

 

Thanks,

 

William

 

 

--_000_E3378E0605547F4E854DEE0CB1116AB020865Bgbcdcmbx03intlatt_-- From nobody Thu Aug 3 23:29:10 2017 Return-Path: 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 CB48D12EA7C for ; Thu, 3 Aug 2017 23:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 t1zUbR7IvTs3 for ; Thu, 3 Aug 2017 23:29:06 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB436131A7C for ; Thu, 3 Aug 2017 23:29:06 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id E938176; Fri, 4 Aug 2017 08:29:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Zf98AazwRbj3; Fri, 4 Aug 2017 08:29:01 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 4 Aug 2017 08:29:04 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A2A79200BA; Fri, 4 Aug 2017 08:29:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Fptgl73QZIZC; Fri, 4 Aug 2017 08:29:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 593D5200B8; Fri, 4 Aug 2017 08:29:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2204F4009077; Fri, 4 Aug 2017 08:29:03 +0200 (CEST) Date: Fri, 4 Aug 2017 08:29:03 +0200 From: Juergen Schoenwaelder To: Andy Bierman Cc: "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" Message-ID: <20170804062903.GA36536@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" References: <20170803074925.GA35421@elstar.local> <20170803163234.GB36084@elstar.local> <20170803165348.GD36084@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] Questions on NMDA and "merged config and state" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 06:29:09 -0000 On Thu, Aug 03, 2017 at 10:06:23AM -0700, Andy Bierman wrote: > > So you are saying there is no such thing as an NMDA-compliant server. > There are protocols that may use specific datastores in various ways. > Different protocols can have different behavior for the same datastore. > Sounds very fun for client developers to figure out. > This is what I wrote: The protocols (with their various capabilities) expose different sets of datastores. I agree, the protocol documents should state clearly what is required to expose for the different protocols and what is optional to expose. I did not write that different protocols can have different behavior for the same datastore. I did not write that protocols may use specific datastores in various ways. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Aug 3 23:39:30 2017 Return-Path: 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 270911243F3 for ; Thu, 3 Aug 2017 23:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 L-_AnYZCHibC for ; Thu, 3 Aug 2017 23:39:25 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0135.outbound.protection.outlook.com [104.47.2.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC6B1127ABE for ; Thu, 3 Aug 2017 23:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PbYXMSJb6UJzWYLHF9GTqgp9w2xgUuqpHj6j2ei6U9w=; b=Tcv48h0Ie+yQj9zE8DvXKq0MieLmDtVri4avPnNJpihfBpXRO0R8eTD/bgShAgJYHgEJBdC+mJ3MygbJd0G0nqWNlhvxFj1xqY/F+4hs0JN8amOzfKyv0GuqeDwlJYKjSCfe4hIyx8URFQmdUaSdYh4+l6cd2s1r2wD2sx6KlCI= Received: from AM3PR07MB0632.eurprd07.prod.outlook.com (10.160.4.12) by AM3PR07MB0501.eurprd07.prod.outlook.com (10.141.47.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.10; Fri, 4 Aug 2017 06:39:22 +0000 Received: from AM3PR07MB0632.eurprd07.prod.outlook.com ([fe80::e826:100a:8484:38de]) by AM3PR07MB0632.eurprd07.prod.outlook.com ([fe80::e826:100a:8484:38de%13]) with mapi id 15.01.1320.010; Fri, 4 Aug 2017 06:39:22 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: Andy Bierman , Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: [netmod] Questions on NMDA and "merged config and state" Thread-Index: AdMMJZfihJGpR5QERlmLOT/dFpAbmwAToO6nAB4BnKA= Date: Fri, 4 Aug 2017 06:39:21 +0000 Message-ID: References: <20170803074925.GA35421@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; x-originating-ip: [135.245.212.3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB0501; 6:/GWYqNZXIxhmtLouyZIkGI7QoCqSZMoScnwObf5XJdJIXy7yjBrnRIZtRhJ9RUrZpz3WRj+s3fFApSfomI7/+J83FAiB+YtQUKC85IVK2Qi7cOxM74/TiGB92Vdn3390z+KxueZieW7MexfPGgMG7i/yNhYDleIKrl0qcN4k6bTjIGkRGn/M3W4asNd/eUarqzGfOaIOkYfi5IT1ERKThJTnxKYtwiUW23kuQUiXuSML9r4HUKbZfyA8JJCoREBSP+QoZ1FQsCa5FHXfoLAdw67M++3ul95/vfqrNFdyhIPQIlVs56kCPVmku1TF7kipl/Ig7CxNaIucZmP28YTGnw==; 5:C3ozRfDQFJ8jj5GyfH4lRPwjmlaOzTwAft9WRVJKiNtE9AMHxMFQK0+yYKNbNb6rz1i3NXhh/jMlKzaQ52Y7+6+AvsbxDN6IN3E8yyD5HPArUp2wDToDH3oGU2SDN4tjUy7JcPuVn6ltWqWN+xwohg==; 24:rz8wNiXWBGgVCY4a/47RF8n+w0ETdlPKpt8hFoxXdhdlZdtWy8kvYuW4neWFVV2f76ZW9wsS3vhgvr7LuJpCgduZrUgu2fbH6lQJ+kJhJ6g=; 7:8RgAtr7+svdoZRDDf+1G9QJa2aQU0Fnzv3du/6t4qRYbhcy69hhLSnCPB7RncXY+GtqjdFMDDkkSxM6TUUk6foQufDUeTz2NNFY3qbKlG1MiEnmXklsugxcp87V74YLbw1SoMaDsTDzysBs649+1vYsOQoyPrDTgvNeAJlJZqybq6Lj7icKnU+lEDNh5vHOvWlZp6/UVXTdbyPnqFHnM2w6aP033PU1zhnAIb5rO6JQ= x-ms-office365-filtering-correlation-id: 4d4432e6-f261-4ab7-71d4-08d4db038aa5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603031)(49563074)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB0501; x-ms-traffictypediagnostic: AM3PR07MB0501: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0501; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0501; x-forefront-prvs: 0389EDA07F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39400400002)(39850400002)(39860400002)(39840400002)(39450400003)(39410400002)(189002)(377454003)(24454002)(199003)(2501003)(236005)(76176999)(99936001)(101416001)(106356001)(25786009)(54356999)(6246003)(105586002)(6436002)(5250100002)(2906002)(38730400002)(50986999)(606006)(8676002)(229853002)(81156014)(97736004)(99286003)(14454004)(2900100001)(81166006)(55016002)(478600001)(33656002)(53936002)(790700001)(6306002)(54896002)(3660700001)(9686003)(7736002)(966005)(6506006)(3846002)(6116002)(102836003)(189998001)(3280700002)(86362001)(66066001)(68736007)(74316002)(8936002)(2950100002)(7696004)(53546010)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB0501; H:AM3PR07MB0632.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_001B_01D30CFD.29970A60" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2017 06:39:22.1222 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0501 Archived-At: Subject: Re: [netmod] Questions on NMDA and "merged config and state" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 06:39:28 -0000 ------=_NextPart_000_001B_01D30CFD.29970A60 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001C_01D30CFD.29970A60" ------=_NextPart_001_001C_01D30CFD.29970A60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, Aug 3, 2017 at 12:49 AM, Juergen Schoenwaelder > wrote: On Thu, Aug 03, 2017 at 06:59:58AM +0000, Bogaert, Bart (Nokia - BE/Antwerp) wrote: > > Just to get confirmation on my assumptions: > > In section 4.7.3 the origin metadata does not include 'running' as origin > but only 'intended'. So it seems to be mandatory for a NC server to support > the intended datastore? If your server does not support templates or inactive configuration or the like, then intended is just an alias for running. IMO this is not correct. There are no standards at all to define these things. Our server supports an implementation of config templates that expands the template when it is first created. A different proprietary implementation MAY choose to expand templates in some other way. Since there are no standards for this purpose, any proprietary implementation decision is valid. The contents of the "intended" datastore are purely proprietary. The opaque nature of this datastore is by design and the WG accepts that servers are free to choose to implement whatever datastores they want. The origin metadata should just reflect what the server does, not mandate any sort of datastore conformance. [Bart Bogaert] In that case I would expect that the running is also included as an origin of the data in the operational datastore? Regards, Bart Andy I do not think you need to expose intended in this case. Still, the value of the origin attribute is 'intended' since in the general case, the configuration is coming from . > With the introduction of the operational datastore I assume it also means > that when someone wants to know what the client has configured on the device > a get-config on the running datastore is required while to know the 'in-use' > configuration a get(-config) on the operational datastore is required? Yes. The operation, however, is likely called get-data in NETCONF, at least this is what draft-dsdt-nmda-netconf-00 suggested. > The Guidelines for YANG Module Authors (NMDA) - draft-dsdt-nmda-guidelines > mentions that a derived module can be generated from the YANG models where > state and config are merged in a single branch. In the simple example this > results in another YANG model with its own namespace. I assume that this > state YANG model will then also show up in the hello message? The general idea is that we produce YANG modules that have config and state merged into a single branch. Out of this YANG module, people may generate a separate module that consists of the config false nodes plus any additional key nodes needed to make it work. Such a YANG module will be treated as any other YANG module. Note that YANG 1.1 started to move module announcements to the ietf-yang-library to avoid very long module announcements during session startup. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_001_001C_01D30CFD.29970A60 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

On Thu, Aug 3, 2017 at 12:49 AM, Juergen Schoenwaelder = <j.schoenwaelder@jacobs-university.de> = wrote:

On Thu, = Aug 03, 2017 at 06:59:58AM +0000, Bogaert, Bart (Nokia - BE/Antwerp) = wrote:
>
> Just to get confirmation on my = assumptions:
>
> In section 4.7.3 the origin metadata does = not include 'running' as origin
> but only 'intended'.  So it = seems to be mandatory for a NC server to support
> the intended = datastore?

If your server does not support templates or inactive = configuration or
the like, then intended is just an alias for = running.

 

 

IMO this is not correct.

There are no standards at all to define these = things.

Our server = supports an implementation of config templates that expands = the

template when it is = first created.  A different proprietary implementation MAY = choose

to expand templates = in some other way.  Since there are no standards for this = purpose,

any proprietary = implementation decision is valid.

 

The contents of the "intended" datastore are = purely proprietary.

The = opaque nature of this datastore is by design and the WG accepts that = servers

are free to choose = to implement whatever datastores they want.

The origin metadata should just reflect what the = server does, not mandate

any sort of datastore conformance.

[Bart Bogaert] In that case I would expect that = the running is also included as an origin of the data in the operational = datastore?

 

Regards, = Bart

 

 

Andy

 

 

 

I do not = think
you need to expose intended in this case. Still, the value of = the
origin attribute is 'intended' since in the general case, = the
configuration is coming from <intended>.

> With = the introduction of the operational datastore I assume it also = means
> that when someone wants to know what the client has = configured on the device
> a get-config on the running datastore = is required while to know the 'in-use'
> configuration a = get(-config) on the operational datastore is required?

Yes. The = operation, however, is likely called get-data in NETCONF, at
least = this is what draft-dsdt-nmda-netconf-00 suggested.

> The = Guidelines for YANG Module Authors (NMDA) - = draft-dsdt-nmda-guidelines
> mentions that a derived module can be = generated from the YANG models where
> state and config are merged = in a single branch.  In the simple example this
> results in = another YANG model with its own namespace.  I assume that = this
> state YANG model will then also show up in the hello = message?

The general idea is that we produce YANG modules that = have config and
state merged into a single branch. Out of this YANG = module, people may
generate a separate module that consists of the = config false nodes
plus any additional key nodes needed to make it = work. Such a YANG
module will be treated as any other YANG module. = Note that YANG 1.1
started to move module announcements to the = ietf-yang-library to avoid
very long module announcements during = session startup.

/js

--
Juergen Schoenwaelder          =  Jacobs University Bremen gGmbH
Phone: +49 421 200 3587        =  Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103      =    <http://www.jacobs-university.de/>

= _______________________________________________
= netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod=

 

------=_NextPart_001_001C_01D30CFD.29970A60-- ------=_NextPart_000_001B_01D30CFD.29970A60 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT 8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0 MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0 QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7 GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9 xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE 7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/ PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ 88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo +lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5 JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL 6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45 qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6 eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO 5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74 4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0 MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB 0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt 9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH 9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI /fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos 2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P /jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO 0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MDQwNjM5MThaMCMGCSqGSIb3DQEJBDEWBBSIZ9GW rQTnOvWPmguiu6Wqtl/aUTCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9 xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAEYew3rc4DKEtU1Pum8FJpW+A8t/Db2bv9eqajuKTSWsdpZGGNeTcEGSc+f9 IegSE6TdvqJ/A4d1fRznkavdw9mr33lRm/4CH1Oy/vS7x2keiONLjEmB34kaiqCoumbmxx7go5Oj RsGRU2IuTwryyXbXmZapm9Q9eryGUdiDanudnZTlCkZmClhWbwe/sbHtL52u9FI5GB9eGWyc/G3B TIZ/iKsfJDWuT9JIJe9xReNMABt4+tnXtBhrvKV/69imRHxfeDqWLpF7nCaun1WvB7KmJ3WbBJ1I qUhY/wedrnE3Ys/YazgkzFrrD1yEKoGKJJeDb5NkvnJO5YSm8MyWwDMAAAAAAAA= ------=_NextPart_000_001B_01D30CFD.29970A60-- From nobody Fri Aug 4 00:03:50 2017 Return-Path: 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 82F171294A2 for ; Fri, 4 Aug 2017 00:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 QPz1c8mRNdih for ; Fri, 4 Aug 2017 00:03:46 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10110.outbound.protection.outlook.com [40.107.1.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC5DF13146E for ; Fri, 4 Aug 2017 00:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kXcH+zd4EFob+E0+Jg9uB5KSvDsZC9lVRqzfKLhopns=; b=SmFAcp0kZo5TvoDQza6jPDAE9/A34F5y100PBl4VVOo2eoF3eTiX8Y8TnSazDR422sVMVGai8Z+ekoVbKWdruJWEfflHoBYRqtD2IFxPLGyAaOXPH6S0o9WjzguBM7CuMjtSoYgDwu2YAQ0gqMWN2e6xfkQb8IKI4yvrT9V8bUw= Received: from AM3PR07MB0632.eurprd07.prod.outlook.com (10.160.4.12) by AM3PR07MB1138.eurprd07.prod.outlook.com (10.163.188.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.10; Fri, 4 Aug 2017 07:03:43 +0000 Received: from AM3PR07MB0632.eurprd07.prod.outlook.com ([fe80::e826:100a:8484:38de]) by AM3PR07MB0632.eurprd07.prod.outlook.com ([fe80::e826:100a:8484:38de%13]) with mapi id 15.01.1320.010; Fri, 4 Aug 2017 07:03:43 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: Juergen Schoenwaelder , Andy Bierman CC: "netmod@ietf.org" Thread-Topic: [netmod] Questions on NMDA and "merged config and state" Thread-Index: AdMMJZfihJGpR5QERlmLOT/dFpAbmwAxWIL+AADvZlA= Date: Fri, 4 Aug 2017 07:03:43 +0000 Message-ID: References: <20170803074925.GA35421@elstar.local> <20170803163234.GB36084@elstar.local> <20170803165348.GD36084@elstar.local> <20170804062903.GA36536@elstar.local> In-Reply-To: <20170804062903.GA36536@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.245.212.3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1138; 6:KFVp0QorVQG2igHiYFKfSm2p217wmUFOHlahpWrYUnI914aXMy2WVCiyem5n6v4WQrMRnDh++nzNxdam8ezAUzvzgu5VoDDk8nfhafdJsrpMHp8yROKgDxO+DQKgxe9sfwMxN7iZjbxJ93J5u+lBAILiKU7UH5TgtvT8lbhZThdT5Sr0Sd0UhP8PMFqYUzM4urPH9GIynU4SPdbcSkq/61G9I1BvBuaZ6BqZn7eexp2QHaAlS3Q/D9u4EDPIY9FfcA6Dta6ICvxqypC4zjjqpt6RaWf8avuUfTEGQ+lpp5D0185tTqsTjvE+sNNm7uD+gxDHs/F/A1WKlBtNSg3jYA==; 5:ngqEG2nrTGao21sdn678UAD1DtiHvCKOmqf2kK4nGne5/LYqgia7C6ei3KN3wm23KgJ84l1GP1BUpb0G3CK3l8Cscwnf40Gz1rMcj6KAlI0rDZ9p+/7MwrloEXK+9uNVljm1m7SA7z+hfde8WPcupw==; 24:B1b+jyuMW7gvGfahT84MgrDz7u9vPXHaSVBv19iSAu3pRCbbmEB9KiwfmioyCr4FV2XYVaJgRsctt6IemGWlWZags/NU/mj3ctJ9exgTcQE=; 7:oWMQ0iVoLfZzH7UV7xVZBuQMn/wBEVWJdhSiOvnHDrNzG6PpYFoWjLq62fayUiDoAxOKLLdxCQ7XyzsfCsB3gnsgVUOm8bVZ2+v64ccXVichyf2vffRu0DR6bPKh+Cep3eneJbtXAHH3N/4fWkxH87T9Bm72W6ryfpjkuxsXcL5zkyOiwlzKBXIm6vc+ZfKQAo4ZNnI1JMC1okpggIMGFGiQEyXDozsn54sXw5/YS/s= x-ms-office365-filtering-correlation-id: 4a57e210-9f03-4ed9-ae80-08d4db06f162 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603119)(49563074)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM3PR07MB1138; x-ms-traffictypediagnostic: AM3PR07MB1138: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; x-exchange-antispam-report-test: UriScan:(158342451672863)(82608151540597)(100405760836317); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123560025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1138; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1138; x-forefront-prvs: 0389EDA07F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39850400002)(39400400002)(39860400002)(39840400002)(39450400003)(39410400002)(13464003)(199003)(24454002)(189002)(377454003)(5660300001)(74316002)(3280700002)(7696004)(8936002)(8676002)(81166006)(99936001)(81156014)(54356999)(50986999)(105586002)(3660700001)(106356001)(2906002)(101416001)(76176999)(93886004)(53546010)(478600001)(14454004)(25786009)(33656002)(4326008)(99286003)(9686003)(6306002)(68736007)(229853002)(2950100002)(53936002)(2900100001)(6436002)(86362001)(97736004)(55016002)(189998001)(5250100002)(66066001)(305945005)(3846002)(102836003)(6116002)(38730400002)(6506006)(7736002)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR07MB1138; H:AM3PR07MB0632.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0054_01D30D00.911EC3F0" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2017 07:03:43.0739 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1138 Archived-At: Subject: Re: [netmod] Questions on NMDA and "merged config and state" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 07:03:48 -0000 ------=_NextPart_000_0054_01D30D00.911EC3F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Maybe a stupid question from my side (I'm not involved in the NMDA work) but is there some kind of consensus on what is proposed in this draft RFC or are we miles away from such a consensus? Since this is linked to how a server has to handle state in the proposed merging of config and state under one branch of the tree coming to a conclusion to me seems a requirement since in the current implementation we just can't change a CT leaf in the running DS by a value that is dynamically learned; in the NMDA approach that would be possible as the operational DS contains both CT and CF leaves and consequently a value as configured by the client can be overwritten by a dynamically learned value as the value configured by the client remains untouched in the running DS. In the current implementation we would need to model a CF leaf for this purpose. At least that is how I have always understood how it should be done. As long as we do not have NDMA-based server implementations we can't design and implement YANG models as proposed in NMDA and its associated guidelines. Regards, Bart -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Friday, August 04, 2017 8:29 AM To: Andy Bierman Cc: Bogaert, Bart (Nokia - BE/Antwerp) ; netmod@ietf.org Subject: Re: [netmod] Questions on NMDA and "merged config and state" On Thu, Aug 03, 2017 at 10:06:23AM -0700, Andy Bierman wrote: > > So you are saying there is no such thing as an NMDA-compliant server. > There are protocols that may use specific datastores in various ways. > Different protocols can have different behavior for the same datastore. > Sounds very fun for client developers to figure out. > This is what I wrote: The protocols (with their various capabilities) expose different sets of datastores. I agree, the protocol documents should state clearly what is required to expose for the different protocols and what is optional to expose. I did not write that different protocols can have different behavior for the same datastore. I did not write that protocols may use specific datastores in various ways. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 ------=_NextPart_000_0054_01D30D00.911EC3F0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT 8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0 MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0 QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7 GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9 xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE 7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/ PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ 88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo +lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5 JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL 6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45 qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6 eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO 5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74 4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0 MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB 0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt 9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH 9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI /fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos 2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P /jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO 0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MDQwNzAzNDBaMCMGCSqGSIb3DQEJBDEWBBSswlRp fs7d9T6QpSnG4DtKrzUENjCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9 xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAAMQi82zLneTd6LqEwoMiz0becFXwvnCrTMkyN7PS+WY+xK0vk0AgvM5OxSG 6akiHPDvoWIK+IwqQ64uv0MIXopm5iyh7s+arOtgHItGaz4sxK/DcKnmzS4V/DXCtVUwr3R7bdTN q+Asn7Qz0HDXY7VrFtO15XUYDbUBu/U407rgxRV/wmn8TQ8m/CNTFamxTAhiTImUcph8smTP3MiV LeeNV/9NFwpJz7lj3aUnx1u63fiKBOaxXejlsq4oMsASfPKMkT8X0tBf/8SLCas6B8SeQ0f6+TM+ FsfGapw2WauQnvPdSE4fW1YDxWd4hubnL/XxmEw5m7SCS4aD1Nx4rXwAAAAAAAA= ------=_NextPart_000_0054_01D30D00.911EC3F0-- From nobody Fri Aug 4 08:56:18 2017 Return-Path: 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 EFD4513218E for ; Fri, 4 Aug 2017 08:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com 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 Zfzxbhb-yP0C for ; Fri, 4 Aug 2017 08:56:14 -0700 (PDT) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6261E1321C1 for ; Fri, 4 Aug 2017 08:56:14 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id t201so23359133wmt.0 for ; Fri, 04 Aug 2017 08:56:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=frV1UpZjR0WLeCwVYo8mCrB4E9ANcAgwaldiRiQ+ybo=; b=JqvUVPhyQFI98/pPOHS+N1htTnMfDxQmoIKNtccaP2NUDt00bgMdOvK+aPgVxs7Rnb 5kJrn50jwcN2vwsLqWfeZbfY1RSXqQoxbo+XTXKiWfDQwHohv1eThr8QMbD6yZVExa1D KlFsHGsSkVqyITH32oFFlBTaG9yaRraT6FLrau2VzuCfoKnwR+9iI1RmBqS40YCowscx 6upwM42V8OhyDSYOH6w3wgQFev/DYsL1GOeHyUK8y+/R9g+IdVdyOSj4d2A+Xm+oQZdg /hUUBxDmeRUTqNPshLyOzqRtKBqmMxbZLh+cjKIhzwOTP6/aT/SpKKdYAuaayRnVR+9Z vh5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=frV1UpZjR0WLeCwVYo8mCrB4E9ANcAgwaldiRiQ+ybo=; b=lnZcaekmfgrQ/gcobSp1q6C4UdfLZkHIsHcma/kjNGxqgIZ723gudSSYc6gM9ZonHN H5M2sYwr3SB6pv/GvtIwGhj90m7RUqpbJMEdlC6jL125ng6pQfDND2ohmcq5xcTYYeyP 7QFAowaOE2GuLCMslxzJnWkL87n7t45svdo3YPw7S1a1M1XxZwgTsilC9EE37YhHtaLi sUXjJsbmkHK3EVFIvWZUrvcpI9leeePKolRIozmvIxsR10eKWZ2JYpMq1Kk1Iw77yv4w dODJvvTpe5MOd1+0FdID0471jSY4cCnBhghp4iSlWpBD74RyXp5graKeP/VydVR4JsrI E6JQ== X-Gm-Message-State: AHYfb5jrpww1AysfA5qiW0v3m6i9wMz8factzolQfVhh0/0rhOe7Aoc1 jRpCnsJwxExDzhp9Ref9VSS5TzmD37Sf X-Received: by 10.28.203.78 with SMTP id b75mr1586882wmg.50.1501862172792; Fri, 04 Aug 2017 08:56:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.160 with HTTP; Fri, 4 Aug 2017 08:56:11 -0700 (PDT) In-Reply-To: <20170804062903.GA36536@elstar.local> References: <20170803074925.GA35421@elstar.local> <20170803163234.GB36084@elstar.local> <20170803165348.GD36084@elstar.local> <20170804062903.GA36536@elstar.local> From: Andy Bierman Date: Fri, 4 Aug 2017 08:56:11 -0700 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , "Bogaert, Bart (Nokia - BE/Antwerp)" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1308fe4fb23a0555ef8926" Archived-At: Subject: Re: [netmod] Questions on NMDA and "merged config and state" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 15:56:17 -0000 --94eb2c1308fe4fb23a0555ef8926 Content-Type: text/plain; charset="UTF-8" On Thu, Aug 3, 2017 at 11:29 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Aug 03, 2017 at 10:06:23AM -0700, Andy Bierman wrote: > > > > So you are saying there is no such thing as an NMDA-compliant server. > > There are protocols that may use specific datastores in various ways. > > Different protocols can have different behavior for the same datastore. > > Sounds very fun for client developers to figure out. > > > > This is what I wrote: > > The protocols (with their various capabilities) expose different sets > of datastores. I agree, the protocol documents should state clearly > what is required to expose for the different protocols and what is > optional to expose. > > I did not write that different protocols can have different behavior > for the same datastore. I did not write that protocols may use > specific datastores in various ways. > > So the protocol designers will some how agree on the properties of a standard datastore? Actually it seems much worse than that. It seems each server implementation decides what it wants to support and just lists that. The 7895bis draft proposes that each server will list the properties it supports for each datastore container properties { leaf-list property { type identityref { base ds:property; } description "A property of the datastore."; } description "A list of properties supported by this datastore."; } Of course, these properties are just a list of identityrefs that match the base 'ds:property'. There is no official list of properties that a datastore is expected to support. There is this list in ietf-datastores that seems to be intended to replace the existing capability URIs for various NETCONF capabilities: There does not seem to be any guidance or normative text. NMS developers should take notice of these changes because the impact on code design could be significant. identity property { description "Abstract base identity for datastore identities."; } identity writable { base property; description "Used on the 'running' datastore to indicate that it can be written to." } identity auto-persist { base property; description "Used on the 'running' datastore to indicate that writes to it will be automatically persisted. If the 'startup' datastore is also supported, clients may query its contents to ensure its synchronization. If the 'startup' datastore is not supported, and this property is not set, then clients must use a mechanism provided by the protocol to explicitly persist the 'running' datastore's contents."; } identity rollback-on-error { base property; description "Used on either the 'running' or 'candidate' datastores to indicate that clients may request atomic update behavior."; } identity confirmed-commit { base property; description "Used on the 'candidate' datastore to indicate that clients may request confirmed-commit update behavior."; } identity validate { base property; description "Used on the 'candidate' datastore to indicate that clients may request datastore validation."; } > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --94eb2c1308fe4fb23a0555ef8926 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 3, 2017 at 11:29 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Aug 03, 2017 at 10:06:23A= M -0700, Andy Bierman wrote:
>
> So you are saying there is no such thing as an NMDA-compliant server.<= br> > There are protocols that may use specific datastores in various ways.<= br> > Different protocols can have different behavior for the same datastore= .
> Sounds very fun for client developers to figure out.
>

This is what I wrote:

=C2=A0 The protocols (with their various capabilities) expose different set= s
=C2=A0 of datastores. I agree, the protocol documents should state clearly<= br> =C2=A0 what is required to expose for the different protocols and what is =C2=A0 optional to expose.

I did not write that different protocols can have different behavior
for the same datastore. I did not write that protocols may use
specific datastores in various ways.



So the protocol designers will = some how agree on the properties of a standard datastore?
Actuall= y it seems much worse than that. It seems each server implementation
<= div>decides what it wants to support and just lists that.

The 7895bis draft proposes that each server will list the propertie= s it supports for each datastore

        container properties {
           leaf-list property {
             type identityref {
               base ds:property;
             }
             description
               "A property of the datastore.";
           }
           description
             "A list of properties supported by this datastore.";
         }

Of course, these properties are j= ust a list of identityrefs that match the base 'ds:property'.
=
There is no official list of properties that a datastore is expected t= o support.

There is this list in ietf-datastores t= hat seems to be intended to replace
the existing capability URIs = for various NETCONF capabilities:
There does not seem to be any g= uidance or normative text.
NMS developers should take notice of t= hese changes because the
impact on code design could be significa= nt.



     identity property {
       description
        "Abstract base identity for datastore identities.";
     }

     identity writable {
       base property;
       description
         "Used on the 'running' datastore to indicate that it =
can be
          written to."

     }

     identity auto-persist {
       base property;
       description
         "Used on the 'running' datastore to indicate that wri=
tes to
          it will be automatically persisted.

          If the 'startup' datastore is also supported, clients may
          query its contents to ensure its synchronization.

          If the 'startup' datastore is not supported, and this
          property is not set, then clients must use a mechanism
          provided by the protocol to explicitly persist the
          'running' datastore's contents.";
     }

     identity rollback-on-error {
       base property;
       description
         "Used on either the 'running' or 'candidate' =
datastores to
          indicate that clients may request atomic update behavior.";
     }

     identity confirmed-commit {
       base property;
       description
         "Used on the 'candidate' datastore to indicate that
          clients may request confirmed-commit update behavior.";
     }

     identity validate {
       base property;
       description
         "Used on the 'candidate' datastore to indicate that
          clients may request datastore validation.";
     }

=C2=A0
/js


Andy
=C2=A0

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--94eb2c1308fe4fb23a0555ef8926-- From nobody Fri Aug 4 09:24:26 2017 Return-Path: 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 24EE7132327; Fri, 4 Aug 2017 09:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 A_shfgyeO9t9; Fri, 4 Aug 2017 09:24:15 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0116.outbound.protection.outlook.com [104.47.37.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C87A132448; Fri, 4 Aug 2017 09:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=x00T5ZDvU8zqb3lZCc/oWwwUqPAM2HGtv/GjK8U6Yog=; b=ZVoK/fhQniTqtrNO9bm9T9KrVb2B+DT7sesgQScoZSOyDgblUmjsPVn404k+XxYLNUqKe7E3d1qlwcx28d9zCFbKV+owtsXawGY364OXVeDuJd7n2mHhgna44uzj6hO2/RaRhC8WyRI5cLHIbJ2qvR/+bC34GmEphtsxCHPxX4E= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1601.namprd05.prod.outlook.com (10.161.217.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1320.10; Fri, 4 Aug 2017 16:24:13 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1320.012; Fri, 4 Aug 2017 16:24:13 +0000 From: Kent Watsen To: Balazs Lengyel , "netmod@ietf.org" , "netconf@ietf.org" Thread-Topic: [Netconf] NMDA comments Thread-Index: AQHS/ujeB2vpJYYqyUKPyD0Sq6EwxaJ0O1qA Date: Fri, 4 Aug 2017 16:24:13 +0000 Message-ID: References: <240cfaf5-d752-5a11-2917-c1373a38470f@ericsson.com> In-Reply-To: <240cfaf5-d752-5a11-2917-c1373a38470f@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1601; 6:sIP5Z4XuoLadj513ja2xa2ax4Bf3ZL853u3+Al1YgPKZuu2ucfCJ7HxlxfXjh1XHAuwDWD32XvwfS6ShRUQO75AX9zORL5Zqz9Usr/Ty9ZgSEN8GGrRaXnpMIOIKnLybCgtF/caMtTkEfcl9pMMJB8NqGortbvAi1I7iOUiUcD8ZhaSFhODqoR0cB+6cdjyo9SwVoiZHw6M06TEmnuu3WqSwE1Nipv3/DTOdTRznZbLXs72FBJcGCGphU5Q2ZG0DUIiMLJt5EF/ZcvlH1lbCnTKBJ/RUcSuk4b8bd2SDkjnA79dZOYyOZwMs8MaoKdEfX7SJU7p3BdVO8iw+m2eFMA==; 5:CQMxZhLmwY7deIU/+Oge25CambywebZ+r2O94O8j52j46U6kpM+QDRK1wsMqvQQH4CgUd+tQ85lJFEi91mjSjbgX7YUKN3VKa0otU/cd4naUX2Z7b/VgXA0vdLEkmqThVQGuynBw7V4pSYDtURkW2g==; 24:d3hmVPQhD7U4biobPfMJL394msKHiv7ss4n/Crfcnbqn4GQeg5d9/xj9Mo/26wOFXE1x+g1gx108J86gZ3HyuxfXxfx2LFp8a0UaC7VpEJs=; 7:bn768uWUGH4Z4/4l/8uXNsC8WAh5dfKyrjX0lhs2zMJWRJd4jW/JxV2m8wXCWoCuSiBFk/eijACjg8BI+hKrtcTDqWy+8W/sz10YJxHJZvYXsGq77FNC72l86R/nLxkk1/3vnzQAEwoFMKpW3m50h4F0H0FUyMmBB438n2iMzV607E2qNFpyF0TXpi/cJV2V6mt+HnTSuj5gQIltdUbwM6mz7Nne8eQVo/M4thzD3ak= x-ms-office365-filtering-correlation-id: 556354a5-7a73-4e10-5741-08d4db553eba x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1601; x-ms-traffictypediagnostic: BN3PR0501MB1601: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-exchange-antispam-report-test: UriScan:(158342451672863); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1601; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1601; x-forefront-prvs: 0389EDA07F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39410400002)(39400400002)(39850400002)(39860400002)(39840400002)(39450400003)(76104003)(189002)(199003)(24454002)(25786009)(3660700001)(53936002)(7736002)(106356001)(99286003)(305945005)(189998001)(33656002)(6436002)(82746002)(83716003)(6512007)(6306002)(81166006)(8676002)(68736007)(2201001)(86362001)(81156014)(8936002)(2906002)(101416001)(2950100002)(5660300001)(2900100001)(478600001)(6486002)(105586002)(77096006)(4001350100001)(97736004)(38730400002)(3280700002)(6506006)(6246003)(229853002)(14454004)(66066001)(2501003)(966005)(6116002)(76176999)(36756003)(54356999)(50986999)(3846002)(83506001)(102836003)(21314002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1601; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Aug 2017 16:24:13.6403 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1601 Archived-At: Subject: Re: [netmod] [Netconf] NMDA comments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Aug 2017 16:24:18 -0000 SGkgQmFsYXpzLA0KDQoNCj4gR2VuZXJhbDogSXQgc2hvdWxkIGJlIG1vcmUgY2xlYXJseSBkZXNj cmliZSBob3cgbGVnYWN5IGRldmljZXMgdGhhdCBkbyANCj4gbm90IHdpc2ggdG8gc3VwcG9ydCBO TURBIHNob3VsZCBiZWhhdmUuIFRoZXkgc3RpbGwgbmVlZCBwYXJ0IG9mIHRoZSANCj4gb3BlcmF0 aW9uYWwgZGF0YXN0b3JlLCBidXQgbWlnaHQgbm90ICh3aWxsIHByb2JhYmx5IG5vdCkgaGF2ZSBh IHNlcGFyYXRlIA0KPiBvcGVyYXRpb25hbCBzdGF0ZSBmb3IgY29uZmlndXJhdGlvbiBmcm9tIHJ1 bm5pbmcvaW50ZW5kZWQuIFNoYWxsIHRoZXkgDQo+IGp1c3QgcHJlc2VudCB0aGUgcnVubmluZyBj b25maWd1cmF0aW9uIGFzIHBhcnQgb2Ygb3BlcmF0aW9uYWw/DQoNClRoZSByZXN0Y29uZi1ubWRh IGRyYWZ0IHN0YXRlcyB3aGF0IGEgc2VydmVyIG11c3QgZG8gaW4gb3JkZXIgdG8gaW5kaWNhdGUN Cml0IHN1cHBvcnRzIE5NREEuICBTaW1pbGFyIHN0YXRlbWVudHMgY291bGQgYmUgcHV0IGludG8g dGhlIG5tZGEtbmV0Y29uZg0KZHJhZnQuICBCdXQgSSB0aGluayB5b3VyIHF1ZXN0aW9uIGlzIG1v cmUgYWJvdXQgaG93IGEgc2VydmVyIGNhbiBpbXBsZW1lbnQNCnRoZSBuZXcgeWFuZyBsaWJyYXJ5 IG1vZHVsZSB3aGlsZSBoYXZpbmcgdGhlIHNhbWUgb3BlcmF0aW9uYWwgYmVoYXZpb3IgYXMNCmJl Zm9yZSAtIHJpZ2h0PyAgUGVyaGFwcyByZmM3ODk1YmlzIGNvdWxkIGhhdmUgYW4gQXBwZW5kaXgg c2VjdGlvbiB0aGF0IA0KbWFwcyB2YXJpb3VzIHNjZW5hcmlvcyAoZS5nLiwgTkVUQ09ORiB3aXRo IDpjYW5kaWRhdGUgKyA6d3JpdGFibGUtcnVubmluZywNClJFU1RDT05GIGFzIGl0IGlzKSB0byB5 YW5nLWxpYnJhcnkgJ2RhdGFzdG9yZXMnIHdpdGggJ3Byb3BlcnRpZXMnLiAgV291bGQNCnRoaXMg d29yaz8NCg0KDQoNCj4gZHJhZnQtaWV0Zi1uZXRtb2QtcmV2aXNlZC1kYXRhc3RvcmVzLTAzDQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gNC4xLCA0LjMp ICAiSWYgYSBkZXZpY2UgZG9lcyBub3QgaGF2ZSBhIGRpc3RpbmN0IDxzdGFydHVwPiBhbmQgDQo+ ICAgICAgICAgICAgbm9uLXZvbGF0aWxlIGlzIGF2YWlsYWJsZSwgdGhlIGRldmljZSB3aWxsIHR5 cGljYWxseQ0KPiAgICAgICAgICAgIHVzZSB0aGF0IG5vbi12b2xhdGlsZSBzdG9yYWdlIHRvIGFs bG93IDxydW5uaW5nPiB0bw0KPiAgICAgICAgICAgIHBlcnNpc3QgYWNyb3NzIHJlYm9vdHMuIg0K Pg0KPiBJdCBoYXMgYmVlbiBhIGxvbmcgc3RhbmRpbmcgcHJvYmxlbSBmb3IgdXMgdGhhdCB3ZSBk b24ndCBwcmVzY3JpYmUNCj4gaG93IGFuZCB3aGVuIHRoZSBkZXZpY2UgcGVyc2lzdHMgY29uZmln dXJhdGlvbi4gIlR5cGljYWxseSIgaXMgYQ0KPiB2ZXJ5IHdlZWsgd29yZCBJIHdvdWxkIGxpa2Ug dG8gc2VlIGEgU0hPVUxEIG9yIGJldHRlciBhIE1VU1QuDQoNCkknbSB1bnN1cmUgaWYgdGhlIGFy Y2hpdGVjdHVyZSBkb2N1bWVudCBzaG91bGQgYmUgb3Zlcmx5IA0KcHJvc2NyaXB0aXZlIG9uIHRo aXMuICBDdXJyZW50bHkgd2UgZGVmaW5lIG1lY2hhbmlzbXMgZW5hYmxpbmcNCnRoZSBzZXJ2ZXIg dG8gYWNjdXJhdGVseSBkZXNjcmliZSB3aGF0IGl0IGRvZXMsIHdpdGggdGhlIG5ldw0KZGF0YXN0 b3JlIHByb3BlcnRpZXMgKGUuZy4sIGF1dG8tcGVyc2lzdCksIHdoaWNoIHRoZW4gbGV0cyB0aGUN Cm1hcmtldCBkZWNpZGUgd2hhdCdzIGJlc3QuDQoNCg0KDQo+IGRyYWZ0LWRzZHQtbm1kYS1uZXRj b25mLTAwDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4N Cj4gRm9yIHVzIHRoZSBtb3N0IGltcG9ydGFudCBwYXJ0IG9mIHRoZSB3aG9sZSBkYXRhc3RvcmUg cmVzdHJ1Y3R1cmluZyBpcyANCj4gdGhlIGNsZWFuIGFzc29jaWF0aW9uIG9mIGNvbmZpZyBhbmQg c3lzdGVtLXN0YXRlIGRhdGEuIFdlIG11c3QgYmUgYWJsZSANCj4gdG8gaXNzdWUgYSBnZXQteHh4 IG9wZXJhdGlvbiB0byBnZXQgT05MWSB0aGUgc3lzdGVtLXN0YXRlIGRhdGEgZm9yIGEgDQo+IHBh cnRpY3VsYXIgYnJhbmNoLiBJIGRvbid0IHNlZSBhbnkgd2F5IHRvIGZpbHRlciBhIGdldC1kYXRh IG9uIA0KPiBjb25maWc9ZmFsc2UuIFByb2JsZW0uDQo+DQo+IEkgdGhpbmsgd2Ugc2hvdWxkIGhh dmUgYSBnZXQtZGF0YSBmaWx0ZXIgYmFzZWQgb24gb3JpZ2luDQo+DQo+IFlhbmcgbW9kZWwsIGdl dC1kYXRhKSBJTUhPIDIgbGVhZnMgYXJlIG1pc3NpbmcgZnJvbSBnZXQtZGF0YTogDQo+IHdpdGgt ZGVmYXVsdHMgYW5kIG9yaWdpbg0KDQpJJ2QgbGlrZSB0byB0aGluayB0aGF0IHdlIGNvdWxkIGV4 dGVuZCBzdWJ0cmVlIGZpbHRlcmluZyB0byBpbmNsdWRlDQptZXRhZGF0YSwgYnV0IHNvIGZhciB0 aGUgY29uZmlnIHRydWUvZmFsc2UgYXR0cmlidXRlIGlzIG5vdCBjb25zaWRlcmVkDQptZXRhZGF0 YS4gIEluIGxpZXUgb2YgdGhhdCwgcGVyaGFwcyA8Z2V0LWRhdGE+IGNvdWxkIHRha2UgYSAnY29u dGVudCcNCnBhcmFtZXRlciBsaWtlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MDQw I3NlY3Rpb24tNC44LjEuDQoNCg0KDQoNCj4gZHJhZnQtZHNkdC1ubWRhLWd1aWRlbGluZXMtMDEN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJIHdvdWxk IGxvdmUgdG8gc2VlIGEgcGxhbiBmb3IgdXBkYXRpbmcgZXhpc3RpbmcgbW9kZWxzLiANCg0KUGxl YXNlIHNlZSBSb2IncyA3LzIwIGVtYWlsIG9uIHRoZSBuZXRtb2QgbGlzdC4NCg0KDQo+IE91ciBw cmlvcml0aWVzIGJlaW5nIGlldGYtc3lzdGVtLCBpZXRmLWludGVyZmFjZXMNCg0KaWV0Zi1pbnRl cmZhY2UgaXMgYmVpbmcgd29ya2VkIG9uLiAgUmVnYXJkaW5nIGlldGYtc3lzdGVtLCBSb2Igd3Jv dGU6DQoNCiAgUkZDIDczMTc6IEEgWUFORyBEYXRhIE1vZGVsIGZvciBTeXN0ZW0gTWFuYWdlbWVu dA0KICBpZXRmLXN5c3RlbUAyMDE0LTA4LTA2LnlhbmcgZGVmaW5lcyBzeXN0ZW0tc3RhdGUNCiAg PT4gTW9kZWwgdXBkYXRlIGxvb2tzIHRvIGJlIHRyaXZpYWwuICBNYXJ0aW4gQmpvcmtsdW5kDQog IGlzIG9uZSBvZiB0aGUgYXV0aG9ycywgc28gaG9wZWZ1bGx5IGhlIGNhbiBoZWxwIGlzc3VlDQog IGEgdXBkYXRlZCB2ZXJzaW9uLg0KDQpUaGF0IHNhaWQsIHdpdGggYWxsIHRoYXQncyBnb2luZyBv biwgSSBkb24ndCBpbWFnaW5lIHRoaXMgbW9kdWxlJ3MNCnVwZGF0ZSB3aWxsIGJlIHByaW9yaXRp emVkLiAgSWYgaW1wb3J0YW50LCBtYXliZSB5b3UgY2FuIHN1Ym1pdA0KYW4gcmZjNzMxN2JpcyBJ LUQ/DQoNCg0KPiBQYWdlIDgpICIoYykgRm9yIHB1Ymxpc2hlZCBtb2RlbHMsIHRoZSBtb2RlbCBz aG91bGQgYmUgcmVwdWJsaXNoZWQgd2l0aCBhbg0KPiAgICBOTURBLWNvbXBhdGlibGUgc3RydWN0 dXJlLCBkZXByZWNhdGluZyBub24tTk1EQSBjb25zdHJ1Y3RzLiINCj4NCj4gUkZDNzk1MCBpcyB2 ZXJ5IHZhZ3VlIGFib3V0IHdoYXQgZGVwcmVjYXRlZCBtZWFucyAoSU1ITyB0aGlzIGlzIGEgDQo+ IHByb2JsZW0gaW4gdGhlIFJGQykuICAiZGVwcmVjYXRlZCIgaW5kaWNhdGVzIGFuIG9ic29sZXRl IGRlZmluaXRpb24sDQo+IGJ1dCBpdCBwZXJtaXRzIG5ldy9jb250aW51ZWQgaW1wbGVtZW50YXRp b24iLiAgIFRoaXMgZG9lcyBtZWFuIHRoZSBmdWxseQ0KPiBmdW5jdGlvbmFsIGltcGxlbWVudGF0 aW9uIE1VU1Qgc3RpbGwgYmUgaW4gcGxhY2UsIGl0IGFsbG93cyBhIG5vZGUgdG8NCj4gcmVtb3Zl IGl0LiAgSWYgd2UgYWxsb3cgYSBub2RlIHRvIHJlbW92ZSBlLmcuIC9pbnRlcmZhY2VzLXN0YXRl IHRoYXQNCj4gaXMgYSBwcm9ibGVtLg0KPg0KPiBXaGF0IGRvIHdlIHJlYWxseSBtZWFuIGluIHRo aXMgY2FzZT8gV2UgYmV0dGVyIHN0YXRlIGl0IGV4cGxpY2l0bHkuDQoNCkkgcGVyc29uYWxseSB0 aGluayB0aGUgZGVmaW5pdGlvbnMgYXJlIG9rYXkuICBXaGF0J3MgbWlzc2luZyBpcyBrbm93bGVk Z2UNCm9mIGlmIHRoZSBzZXJ2ZXIgaW1wbGVtZW50cyB0aGUgZGVwcmVjYXRlZCBub2RlcyBvciBu b3QuICBOb3RlIHRoYXQgZXZlbg0KdGhlICdvYnNvbGV0ZScgZGVmaW5pdGlvbiBhbGxvd3MgZm9y IGNvbnRpbnVlZCB1c2UuICAgT25lIHdheSBhIGNsaWVudA0KY2FuIGRldGVybWluZSBpdCBhIHNl cnZlciBpbXBsZW1lbnRzIGRlcHJlY2F0ZWQvb2Jzb2xldGUgbm9kZXMgaXMgYnkNCnRyeWluZyB0 byBnZXQgdGhlIG5vZGUocykgd2l0aC1kZWZhdWx0cy4gIEJ1dCBteSBndWVzcyBpcyB0aGF0IGEg Y2xpZW50DQp0aGF0IGhhcyB0aGUgd2hlcmV3aXRoYWwgdG8gZG8gdGhhdCBjYW4ganVzdCBhcyBl YXNpbHkgbW92ZSB0byBzdXBwb3J0DQp0aGUgbW9kdWxlJ3MgbmV3IG5vZGVzLiAgIFdoYXQgYXJl IHlvdSBhc2tpbmcgZm9yLCBlcnJhdGEgb24gUkZDIDc5NTA/DQoNCg0KDQo+IGRyYWZ0LW5tZHNk dC1uZXRjb25mLXJmYzc4OTViaXMtMDENCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiBBIGxvdCBvZiB0aGluZ3Mgc2hvdWxkIGJlIG1hbmRhdG9yeSBhbmQg YXJlIG5vdCBpbmNsdWRpbmcgbW9kdWxlLW5hbWUsIA0KPiByZXZpc2lvbi4gVGhleSBhcmUgbmVl ZGVkIGJ5IHRoZSB1c2VyLiBJdCBpcyBldmVuIHN0cmFuZ2VyIHRoYXQgDQo+IGRldmlhdGlvbnMg cmVmZXIgdCBtb2R1bGVzIGJ5IG5hbWUsIGJ1dCB0aGUgbmFtZSBpcyBvcHRpb25hbCBpbiB0aGUg bGlzdCANCj4gb2YgbW9kdWxlcy4NCg0KRml4ZWQgaW4gbXkgbG9jYWwgY29weS4NCg0KPiBJcyBp dCBhbiBlcnJvciBpZiBhIG1vZHVsZSBjb250YWluaW5nIG9ubHkgY29uZmlnPWZhbHNlIGRhdGEg aXMgbGlzdGVkIA0KPiBmb3IgdGhlIHJ1bm5pbmcgZGF0YXN0b3JlPyBJTUhPIG5vdCwgaXQgc2hv dWxkIGp1c3QgYmUgaWdub3JlZCBpbiB0aGUgDQo+IHJ1bm5pbmcgZGF0YXN0b3JlPw0KDQpJJ20g b2theSB3aXRoIHRoaXMsIGJ1dCBJJ2QgaG9wZSB0aGF0IHZhbGlkYXRpbmcgc29mdHdhcmUgd291 bGQgZmxhZyBpdA0Kd2l0aCBhIHdhcm5pbmcuDQoNCg0KPiBUaGUgbW9kdWxlLXNldC1pZCBvbmx5 IHJlZmVyZW5jZSB0byB0aGUgbGVnYWN5IHBhcnQgYm90aCBpbiANCj4gL3lhbmdsaWI6eWFuZy1s aWJyYXJ5LWNoYW5nZS95YW5nbGliOm1vZHVsZS1zZXQtaWQgYW5kIA0KPiAveWFuZ2xpYjptb2R1 bGVzLXN0YXRlL3lhbmdsaWI6bW9kdWxlLXNldC1pZC4gSSBhc3N1bWUgdGhpcyB3aWxsDQo+IGNo YW5nZSBhbHNvIGlmIHNvbWV0aGluZyBjaGFuZ2VzIGluIHRoZSAveWFuZ2xpYjp5YW5nLWxpYnJh cnkNCj4gYW5kIHRoZSBub3RpZmljYXRpb24gd2lsbCBhbHNvIGJlIHNlbnQuDQoNCkdvb2QgY2F0 Y2gsIHRoZSB5YW5nLWxpYnJhcnktY2hhbmdlIG5vdGlmaWNhdGlvbiBkZWZpbml0aW9uIHdhc24n dA0KdXBkYXRlZCBiZWZvcmUuICBSZWdhcmRsZXNzIHdoaWNoIG5vZGUgdGhlIGxlYWZyZWYgcG9p bnRzIHRvLA0KL21vZHVsZXMtc3RhdGUvbW9kdWxlLXNldC1pZCBvciAveWFuZy1saWJyYXJ5L21v ZHVsZS1zZXRzL21vZHVsZS1zZXQvaWQsDQp0aGUgbm9kZSBzIG9mIHR5cGUgJ3N0cmluZycuICBU aGlzIG5vdGlmaWNhdGlvbiBlbmFibGVzIGNsaWVudHMgdG8NCm1haW50YWluIGEgY2FjaGVkIGxp c3Rpbmcgb2YgdGhlIG1vZHVsZXMgYSBzZXJ2ZXIgc3VwcG9ydHMuICBUbyBiZQ0KYmFja3dhcmRz IGNvbXBhdGlibGUsIGEgc2VydmVyIHNob3VsZCBvbmx5IHNlbmQgdGhpcyBub3RpZmljYXRpb24g Zm9yDQp3aGVuIHRoZSBtb2R1bGUtc2V0IHVzZWQgYnkgdGhlIGNvbnZlbnRpb25hbCBkYXRhc3Rv cmVzIGlzIG1vZGlmaWVkLg0KSG93ZXZlciwganVzdCBkb2luZyB0aGlzIGRvZXNuJ3Qgc3VwcG9y dCB0aGUgbmV3IGRhdGFzdG9yZXMuICBJdCBzZWVtcw0KbGlrZSB3aGF0IGlzIG5lZWRlZCBpcyBh IGxpc3Rpbmcgb2YgZGF0YXN0b3JlcyB0aGF0IHVzZSB0aGUgbW9kdWxlLXNldC4NCldoYXQgZG8g eW91IHRoaW5rPw0KDQoNCg0KS2VudCAvLyBjb250cmlidXRvcg0KDQoNCg0KDQoNCg== From nobody Sat Aug 5 01:36:16 2017 Return-Path: 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 0C8C712EC13 for ; Sat, 5 Aug 2017 01:36:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 3XR3nWXRVxzu for ; Sat, 5 Aug 2017 01:36:13 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE63712708C for ; Sat, 5 Aug 2017 01:36:12 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 218D169; Sat, 5 Aug 2017 10:36:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id rN0Mfv7yHOTK; Sat, 5 Aug 2017 10:36:06 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Sat, 5 Aug 2017 10:36:11 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 01507200B8; Sat, 5 Aug 2017 10:36:11 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Fwn8kryn3EhD; Sat, 5 Aug 2017 10:36:10 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 974F0200AA; Sat, 5 Aug 2017 10:36:10 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 50501400A523; Sat, 5 Aug 2017 10:36:10 +0200 (CEST) Date: Sat, 5 Aug 2017 10:36:10 +0200 From: Juergen Schoenwaelder To: "Bogaert, Bart (Nokia - BE/Antwerp)" Cc: Andy Bierman , "netmod@ietf.org" Message-ID: <20170805083610.GA38024@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Bogaert, Bart (Nokia - BE/Antwerp)" , Andy Bierman , "netmod@ietf.org" References: <20170803074925.GA35421@elstar.local> <20170803163234.GB36084@elstar.local> <20170803165348.GD36084@elstar.local> <20170804062903.GA36536@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Subject: Re: [netmod] Questions on NMDA and "merged config and state" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Aug 2017 08:36:15 -0000 On Fri, Aug 04, 2017 at 07:03:43AM +0000, Bogaert, Bart (Nokia - BE/Antwerp) wrote: > Maybe a stupid question from my side (I'm not involved in the NMDA work) > but is there some kind of consensus on what is proposed in this draft RFC or > are we miles away from such a consensus? Since this is linked to how a > server has to handle state in the proposed merging of config and state under > one branch of the tree coming to a conclusion to me seems a requirement > since in the current implementation we just can't change a CT leaf in the > running DS by a value that is dynamically learned; in the NMDA approach that > would be possible as the operational DS contains both CT and CF leaves and > consequently a value as configured by the client can be overwritten by a > dynamically learned value as the value configured by the client remains > untouched in the running DS. In the current implementation we would need to > model a CF leaf for this purpose. At least that is how I have always > understood how it should be done. As long as we do not have NDMA-based > server implementations we can't design and implement YANG models as proposed > in NMDA and its associated guidelines. > Bart, you may want to look at draft-dsdt-nmda-guidelines-01. Protocol updates to support NMDA are on the way as well, draft-dsdt-nmda-netconf-00 and draft-dsdt-netconf-restconf-nmda-00. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Aug 6 00:57:55 2017 Return-Path: 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 241BC12EC11 for ; Sun, 6 Aug 2017 00:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.91 X-Spam-Level: X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 SjSxIVk6YYCU for ; Sun, 6 Aug 2017 00:57:51 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30105.outbound.protection.outlook.com [40.107.3.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B77131C96 for ; Sun, 6 Aug 2017 00:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5p7+NGqtFyihZmxE8gtdt6hZTU6iyrZsR2t4PsKOERk=; b=VejFE/ghQCLWlRGTKMOr70WJjqysoV91t5oh+GbVfMFcAWlkuLSRHrDmrCgG0ZINstw+BPSEEp87/rgWHpj8QRhX0EPfafOkIUqSKMYSgUeaofLIltZhsUEQvkwn43fRk8sjC1Vm92PkIKv7pTMM8ojS/5lMVAfIdJuhtRljCQ8= Received: from AM2PR07MB0627.eurprd07.prod.outlook.com (10.160.54.154) by AM2PR07MB0579.eurprd07.prod.outlook.com (10.160.33.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.9; Sun, 6 Aug 2017 07:57:47 +0000 Received: from AM2PR07MB0627.eurprd07.prod.outlook.com ([fe80::182e:6400:46fc:f36e]) by AM2PR07MB0627.eurprd07.prod.outlook.com ([fe80::182e:6400:46fc:f36e%13]) with mapi id 15.01.1341.010; Sun, 6 Aug 2017 07:57:47 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: Juergen Schoenwaelder CC: Andy Bierman , "netmod@ietf.org" Thread-Topic: [netmod] Questions on NMDA and "merged config and state" Thread-Index: AdMMJZfihJGpR5QERlmLOT/dFpAbmwAxWIL+AADvZlAANcr9AAAw554w Date: Sun, 6 Aug 2017 07:57:47 +0000 Message-ID: References: <20170803074925.GA35421@elstar.local> <20170803163234.GB36084@elstar.local> <20170803165348.GD36084@elstar.local> <20170804062903.GA36536@elstar.local> <20170805083610.GA38024@elstar.local> In-Reply-To: <20170805083610.GA38024@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; x-originating-ip: [135.245.212.8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0579; 6:P+C+1UUoc8Z4EQsHucRmq92JCHcrsbQf3HI2AHa4kRQucpnL7DBB1+DpKaQWtM9hPrEn1HJB381J8RAuKvo5kfEWAHRM+Ol7Rod68gHynzBjOcVbs2zJ3L0FdcMuzsQ8WsjUeXaXNZvqqbGgiik5qUAdz5NA9UtNmDvw3JV+nVv00T+2gRCTMKgoh2LPDyKfacJqWE6GIe+n+McOjd9u8F3SeUWzDXDSjuHzP4xedmwDZF4xG9JdNdZ3LhSpehVHzIlAqJLbbLj27HrNePRqAEYcrn/HhEM2Gs5fYJvN8haQfm45jx3H1zbAYd5sEbayPy/XCzkMB+RSrIg3VLbZwQ==; 5:FDvMxUhI1y8vs6gRE+RlcCfy475jn2AZnUCEpDPVyTuHPD8u9zC6/aZctbheUlF3rBSPI67EQszSuLp+OrmGYMHgwB8YczUNsNwcRM5EFdfZyrXbAJUiuIFRnvfjH50wpCSX/HrUeaNSXH9CfO+MQQ==; 24:+AufhOT49OUeGl9qUir+j+75AZANYahoJPIyRsuVkK2cRx+xfCtbiYgVTdEF4QNkHPXIOkNOOx8lJVyDjcUlfCvVD3yK4gxYebQIH8PUF/I=; 7:lHN0pqR2eMZDRVK7Nh1fpzoMH1DbrJgN8fhrRqULkQYTYvKea8QJ+Grth5t70E+TgQcsUBxKcBp6lvddMHxSYrm0451lHYUHfWsAaVCSnhuLQ9Y6//cG7j6GaaUoFIxTcEr+s6lI+grVCYd9+jh27wSIw5xnNqMgqfRcInZcLLwO2oVFSSeHsQLflsLHtcwwZhzoT1GP+2mgY049jRCwvnAGbjHr758m8o3Ss1ozH/c= x-ms-office365-filtering-correlation-id: de441b97-a660-40fe-a7fb-08d4dca0d425 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(49563074)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM2PR07MB0579; x-ms-traffictypediagnostic: AM2PR07MB0579: x-exchange-antispam-report-test: UriScan:(158342451672863)(82608151540597)(100405760836317); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0579; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0579; x-forefront-prvs: 039178EF4A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39840400002)(39860400002)(39850400002)(39410400002)(39400400002)(199003)(377454003)(189002)(24454002)(13464003)(305945005)(97736004)(99286003)(68736007)(55016002)(54906002)(6306002)(66066001)(6506006)(81156014)(81166006)(9686003)(53936002)(74316002)(8936002)(25786009)(5660300001)(6246003)(7696004)(86362001)(7736002)(38730400002)(93886004)(76176999)(2900100001)(33656002)(6916009)(2906002)(50986999)(189998001)(54356999)(6116002)(5250100002)(102836003)(3846002)(4326008)(2950100002)(6436002)(478600001)(229853002)(8676002)(110136004)(101416001)(106356001)(99936001)(3660700001)(53546010)(105586002)(14454004)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0579; H:AM2PR07MB0627.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0009_01D30E9A.722CFDE0" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Aug 2017 07:57:47.6635 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0579 Archived-At: Subject: Re: [netmod] Questions on NMDA and "merged config and state" X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Aug 2017 07:57:54 -0000 ------=_NextPart_000_0009_01D30E9A.722CFDE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Juergen, I have also noticed this but when I look at the type of remarks Andy is making I get an impression that "dust has not settled" on how this will work in "real life". Regards, Bart -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Saturday, August 05, 2017 10:36 AM To: Bogaert, Bart (Nokia - BE/Antwerp) Cc: Andy Bierman ; netmod@ietf.org Subject: Re: [netmod] Questions on NMDA and "merged config and state" On Fri, Aug 04, 2017 at 07:03:43AM +0000, Bogaert, Bart (Nokia - BE/Antwerp) wrote: > Maybe a stupid question from my side (I'm not involved in the NMDA > work) but is there some kind of consensus on what is proposed in this > draft RFC or are we miles away from such a consensus? Since this is > linked to how a server has to handle state in the proposed merging of > config and state under one branch of the tree coming to a conclusion > to me seems a requirement since in the current implementation we just > can't change a CT leaf in the running DS by a value that is > dynamically learned; in the NMDA approach that would be possible as > the operational DS contains both CT and CF leaves and consequently a > value as configured by the client can be overwritten by a dynamically > learned value as the value configured by the client remains untouched > in the running DS. In the current implementation we would need to > model a CF leaf for this purpose. At least that is how I have always > understood how it should be done. As long as we do not have > NDMA-based server implementations we can't design and implement YANG models as proposed in NMDA and its associated guidelines. > Bart, you may want to look at draft-dsdt-nmda-guidelines-01. Protocol updates to support NMDA are on the way as well, draft-dsdt-nmda-netconf-00 and draft-dsdt-netconf-restconf-nmda-00. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 ------=_NextPart_000_0009_01D30E9A.722CFDE0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT 8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0 MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0 QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7 GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9 xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE 7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/ PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ 88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo +lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5 JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL 6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45 qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6 eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO 5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74 4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0 MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB 0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt 9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH 9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI /fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos 2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P /jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO 0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MDYwNzU3NDJaMCMGCSqGSIb3DQEJBDEWBBTQhzOn hv6CwYSZCNkB7EmEj5skazCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9 xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAG2o14mwUoHUBcS9qtLnq8ozAN+k3a7RaTWsz7W7HViqMs0yAGrn43SKzHsi PkzRpoPwY75kftARD/6UEPb0dNCb7wsgjJKIfY4ikGUCvM1D3l8i/olb+M5df/GgBUeDA0rCah3S oMMcKV78pznZq2PC4m9oZesih2+LrBfUW4UuPNfUsSz0W86hYZFuxOlL8cCVyT/dFJckv6yScNPr Ipmly5vSIhnJHa2RJu376jDT+o0TxgtQFU449blo+68VAuUwgjjWfPpmnrx0DviJhEI7qOTK9KZG XYTpnp93ZFn+Yx3TSe2FcTLI3El6Hh1vvUePa5dBIF/uYdCahY7fCnEAAAAAAAA= ------=_NextPart_000_0009_01D30E9A.722CFDE0-- From nobody Mon Aug 7 06:28:03 2017 Return-Path: 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 2499C13232B for ; Mon, 7 Aug 2017 06:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-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 BORJllEbAUOj for ; Mon, 7 Aug 2017 06:27:58 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD841321E3 for ; Mon, 7 Aug 2017 06:27:58 -0700 (PDT) Received: from [10.147.40.56] (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id C305E1AE02EF; Mon, 7 Aug 2017 15:27:56 +0200 (CEST) From: Jan Lindblad Message-Id: <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_078050ED-65DF-4DFA-BEE0-3AB5488082C4" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 7 Aug 2017 15:27:49 +0200 In-Reply-To: Cc: "netmod@ietf.org" To: "Ivory, William" References: X-Mailer: Apple Mail (2.3273) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 13:28:01 -0000 --Apple-Mail=_078050ED-65DF-4DFA-BEE0-3AB5488082C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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.=20 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=E2=80=99re 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=E2=80=99ve found a couple of threads online with comments = suggesting it=E2=80=99s only allowed in YANG 1.1? Would appreciate = clarification. > =20 > RFC 6020 section 7.15 suggests it is allowed: > =20 > =E2=80=98 > 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. > =E2=80=98 > =20 > Versus online comments here: = https://www.ietf.org/mail-archive/web/netmod/current/msg15418.html = > =20 > =E2=80=98> On 01 Mar 2016, at 10:38, Anton Tk=C3=A1=C4=8Dik = wrote: > >=20 > > Hi, > > Noticed other issue with example set, > > In https://github.com/mbj4668/pyang/issues/194 = Lada stated that in YANG = 1.0 submodule can not augment nodes > > defined in parent model. > >=20 > > Is that correct that submodule can not augment definition defined in = parent module? > =20 > 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. > =20 > Lada > =E2=80=98 > =20 > Thanks, > =20 > William > =20 > =20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = --Apple-Mail=_078050ED-65DF-4DFA-BEE0-3AB5488082C4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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=E2=80=99re 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=E2=80=99ve found a couple = of threads online with comments suggesting it=E2=80=99s only allowed in = YANG 1.1?  Would appreciate clarification.
 
RFC = 6020 section 7.15 suggests it is allowed:
 
=E2=80=98
   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.
=E2=80=98
 
 
=E2=80=98> On 01 Mar 2016, at 10:38, =
Anton Tk=C3=A1=C4=8Dik <anton.tkacik at pantheon.tech> wrote:
> 
> Hi,
> Noticed =
other issue with example set,
> In https://github.com/mbj4668/pyang/issues/194 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
=E2=80=98=
 
Thanks,
 
William
 
 
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

= --Apple-Mail=_078050ED-65DF-4DFA-BEE0-3AB5488082C4-- From nobody Mon Aug 7 08:20:46 2017 Return-Path: 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 74663132442 for ; Mon, 7 Aug 2017 07:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 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] 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 cDDLuAs8C3J6 for ; Mon, 7 Aug 2017 07:38:39 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 3B0A8132440 for ; Mon, 7 Aug 2017 07:38:39 -0700 (PDT) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v77EZX1C039871; Mon, 7 Aug 2017 10:38:36 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0048589.ppops.net-00191d01. with ESMTP id 2c6gkyvdba-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Aug 2017 10:38:36 -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 v77EcYHD009375; Mon, 7 Aug 2017 10:38:35 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v77EcQXD009240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 7 Aug 2017 10:38:30 -0400 Received: from gbcdccas03.intl.att.com (gbcdccas03.intl.att.com [135.76.180.11]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 7 Aug 2017 14:38:14 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; Mon, 7 Aug 2017 15:38:06 +0100 From: "Ivory, William" To: "'Jan Lindblad'" CC: "'netmod@ietf.org'" Thread-Topic: [netmod] Query about augmenting module from submodule in YANG 1.0 Thread-Index: AdMMOPUClm48yMKSSEeEurX4RbXaiADP5++AAAR9DaA= Date: Mon, 7 Aug 2017 14:37:04 +0000 Deferred-Delivery: Mon, 7 Aug 2017 14:38:04 +0000 Message-ID: References: <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com> In-Reply-To: <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.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_E3378E0605547F4E854DEE0CB1116AB02102DCgbcdcmbx03intlatt_" 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-07_10:, , 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-1708070243 Archived-At: X-Mailman-Approved-At: Mon, 07 Aug 2017 08:20:45 -0700 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 14:38:41 -0000 --_000_E3378E0605547F4E854DEE0CB1116AB02102DCgbcdcmbx03intlatt_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSmFuLA0KDQpUaGFua3Mg4oCTIHdl4oCZbGwgbG9vayBhdCB0cnlpbmcgdG8gcHV0IGV2ZXJ5 dGhpbmcgaW50byBzdWJtb2R1bGVzIGluIHRoaXMgY2FzZS4NCg0KUmVnYXJkcywNCg0KV2lsbGlh bQ0KDQpGcm9tOiBKYW4gTGluZGJsYWQgW21haWx0bzpqYW5sQHRhaWwtZi5jb21dDQpTZW50OiAw NyBBdWd1c3QgMjAxNyAxNDoyOA0KVG86IEl2b3J5LCBXaWxsaWFtIDx3aTI3NHdAaW50bC5hdHQu Y29tPg0KQ2M6IG5ldG1vZEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIFF1ZXJ5IGFi b3V0IGF1Z21lbnRpbmcgbW9kdWxlIGZyb20gc3VibW9kdWxlIGluIFlBTkcgMS4wDQoNClRoZSBz dWJtb2R1bGUgY29uY2VwdCBpbiBZQU5HIDEuMCBpcywgd2VsbCwgbm90IHZlcnkgdXNlZnVsLCBh bmQgZXZlbiBsZXNzIGludHVpdGl2ZS4gVGhhdCdzIHdoeSBpdCBzYXcgbWFqb3IgcmV3b3JrIGlu IFlBTkcgMS4xLg0KDQpBIFlBTkcgMS4wIHN1Ym1vZHVsZSBjYW5ub3QgcmVmZXJlbmNlIHRoZSBt b2R1bGUgdGhhdCBpbmNsdWRlcyBpdCwgZGlyZWN0bHkgb3IgaW5kaXJlY3RseS4gVGhpcyBpcyBi ZWNhdXNlIGluIFlBTkcgMS4wIHRoZSBzeW1ib2xzIGluIG90aGVyIHN1Ym1vZHVsZXMgb2YgdGhl IHNhbWUgbmFtZXNwYWNlIGFyZSBpbnZpc2libGUgdG8gdGhlIHN1Ym1vZHVsZSB1bmxlc3MgdGhl eSBhcmUgZXhwbGljaXRseSBpbmNsdWRlZC4gQW5kIHBhcmVudCBtb2R1bGVzIGNhbid0IGJlIGlu Y2x1ZGVkIGJ5IGEgc3VibW9kdWxlIGJlY2F1c2UgdGhhdCB3b3VsZCBsZWFkIHRvIGFuIGluY2x1 c2lvbiBsb29wLiBJdCBpcyBwb3NzaWJsZSB0byByZWZlcmVuY2UgKGF1Z21lbnQsIGV0Yykgb3Ro ZXIgc2libGluZyBzdWJtb2R1bGVzLCB0aG91Z2guIFNvIGlmIHlvdSBzcGxpdCB5b3VyIG1vZHVs ZXMgY2xldmVybHksIHlvdSBtaWdodCBiZSBhYmxlIHRvIHJlc29sdmUgeW91ciByZWZlcmVudGlh bCBjb25zdHJhaW50cyBhbnl3YXkuDQoNCklmIHlvdSByZWFsbHkgd2FudCB0byB0YWtlIHRoZSBz dWJtb2R1bGUgcGF0aCwgSSdkIHJlY29tbWVuZCBtb3ZpbmcgdG8gWUFORyAxLjEuIEluIHRoZSBp bnRlcmVzdCBvZiBwcmVzZXJ2aW5nIHRoZSBoYWlyIHRvbmUgb2YgSVQtYXJjaGl0ZWN0cy4NCg0K L2phbg0KDQpXZeKAmXJlIHRyeWluZyB0byBzb2x2ZSBhIG1vZHVsYXJpdHkgcHJvYmxlbSB3aXRo IGEgWUFORyBtb2R1bGUgYnkgc3BsaXR0aW5nIGl0IGludG8gc3VibW9kdWxlcyBhbmQgYXVnbWVu dGluZyB0aGUgcGFyZW50IG1vZHVsZSBmcm9tIGVhY2ggc3VibW9kdWxlLiAgSG93ZXZlciwgZGVz cGl0ZSB0aGUgd29yZGluZyBiZWxvdyBpbiBZQU5HIDEuMCBzZWN0aW9uIDcuMTUsIHdl4oCZdmUg Zm91bmQgYSBjb3VwbGUgb2YgdGhyZWFkcyBvbmxpbmUgd2l0aCBjb21tZW50cyBzdWdnZXN0aW5n IGl04oCZcyBvbmx5IGFsbG93ZWQgaW4gWUFORyAxLjE/ICBXb3VsZCBhcHByZWNpYXRlIGNsYXJp ZmljYXRpb24uDQoNClJGQyA2MDIwIHNlY3Rpb24gNy4xNSBzdWdnZXN0cyBpdCBpcyBhbGxvd2Vk Og0KDQoNCuKAmA0KICAgVGhlICJhdWdtZW50IiBzdGF0ZW1lbnQgYWxsb3dzIGEgbW9kdWxlIG9y IHN1Ym1vZHVsZSB0byBhZGQgdG8gdGhlDQogICBzY2hlbWEgdHJlZSBkZWZpbmVkIGluIGFuIGV4 dGVybmFsIG1vZHVsZSwgb3IgdGhlIGN1cnJlbnQgbW9kdWxlIGFuZA0KICAgaXRzIHN1Ym1vZHVs ZXMsIGFuZCB0byBhZGQgdG8gdGhlIG5vZGVzIGZyb20gYSBncm91cGluZyBpbiBhICJ1c2VzIg0K ICAgc3RhdGVtZW50Lg0K4oCYDQoNClZlcnN1cyBvbmxpbmUgY29tbWVudHMgaGVyZTogaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRtb2QvY3VycmVudC9tc2cxNTQxOC5o dG1sPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f d3d3LmlldGYub3JnX21haWwtMkRhcmNoaXZlX3dlYl9uZXRtb2RfY3VycmVudF9tc2cxNTQxOC5o dG1sJmQ9RHdNRmFRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPUZtSlA5Q0g1NHo1bUczREZH QmRjXzlxMVRMcFlRMzEtVFEtMjZfUWE5dncmbT1ZQzR3NlppOUtoQnAwTW5udkE0Ml9xZFIyYU0z dU9GV3BaWXRnRjEyMkVjJnM9T3h4UVJEdWNFVEJhRFBuNEtHTldjTGx1NGU4QU1TZnV5Skpqcmts cDNSMCZlPT4NCg0KDQrigJg+IE9uIDAxIE1hciAyMDE2LCBhdCAxMDozOCwgQW50b24gVGvDocSN aWsgPGFudG9uLnRrYWNpayBhdCBwYW50aGVvbi50ZWNoPiB3cm90ZToNCg0KPg0KDQo+IEhpLA0K DQo+IE5vdGljZWQgb3RoZXIgaXNzdWUgd2l0aCBleGFtcGxlIHNldCwNCg0KPiBJbiBodHRwczov L2dpdGh1Yi5jb20vbWJqNDY2OC9weWFuZy9pc3N1ZXMvMTk0PGh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9tYmo0NjY4X3B5YW5n X2lzc3Vlc18xOTQmZD1Ed01GYVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9Rm1KUDlDSDU0 ejVtRzNERkdCZGNfOXExVExwWVEzMS1UUS0yNl9RYTl2dyZtPVlDNHc2Wmk5S2hCcDBNbm52QTQy X3FkUjJhTTN1T0ZXcFpZdGdGMTIyRWMmcz1ia2FrS0pFWnpDQnEzQmtQNU56Vy13RFg2S09aSHBP blQwdS15U2c4clMwJmU9PiBMYWRhIHN0YXRlZCB0aGF0IGluIFlBTkcgMS4wIHN1Ym1vZHVsZSBj YW4gbm90IGF1Z21lbnQgbm9kZXMNCg0KPiBkZWZpbmVkIGluIHBhcmVudCBtb2RlbC4NCg0KPg0K DQo+IElzIHRoYXQgY29ycmVjdCB0aGF0IHN1Ym1vZHVsZSBjYW4gbm90IGF1Z21lbnQgZGVmaW5p dGlvbiBkZWZpbmVkIGluIHBhcmVudCBtb2R1bGU/DQoNCg0KDQpUaGlzIGlzbid0IHBvc3NpYmxl IGluIFlBTkcgMS4wIGJ1dCB3aWxsIGJlIHBvc3NpYmxlIGluIDEuMS4gSG93ZXZlciwgaW4gdGhl IHByZXNlbnQgY2FzZSB0aGUgZGVmaW5pdGlvbiBiZWluZyBhdWdtZW50ZWQgZnJvbSB0aGUgc3Vi bW9kdWxlIGlzIGFyZ3VhYmx5IGluIGEgZGlmZmVyZW50IG1vZHVsZS4NCg0KDQoNCkxhZGENCuKA mA0KDQpUaGFua3MsDQoNCldpbGxpYW0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3Jn PG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL25ldG1vZDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3TUZhUSZj PUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1GbUpQOUNINTR6NW1HM0RGR0JkY185cTFUTHBZUTMx LVRRLTI2X1FhOXZ3Jm09WUM0dzZaaTlLaEJwME1ubnZBNDJfcWRSMmFNM3VPRldwWll0Z0YxMjJF YyZzPXg3c0sxaldZdFNzUUpyOHI2RzdGaldSNWdBb010Z3Y2elJ3eFQ0YnpNR1EmZT0+DQoNCg== --_000_E3378E0605547F4E854DEE0CB1116AB02102DCgbcdcmbx03intlatt_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRpbWVzTmV3Um9t YW5QU01UOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bh bi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVk LXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgSmFu LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIOKAkyB3 ZeKAmWxsIGxvb2sgYXQgdHJ5aW5nIHRvIHB1dCBldmVyeXRoaW5nIGludG8gc3VibW9kdWxlcyBp biB0aGlzIGNhc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5S ZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+V2lsbGlh bTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gSmFuIExpbmRibGFk IFttYWlsdG86amFubEB0YWlsLWYuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDA3IEF1Z3VzdCAy MDE3IDE0OjI4PGJyPg0KPGI+VG86PC9iPiBJdm9yeSwgV2lsbGlhbSAmbHQ7d2kyNzR3QGludGwu YXR0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IG5ldG1vZEBpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogW25ldG1vZF0gUXVlcnkgYWJvdXQgYXVnbWVudGluZyBtb2R1bGUgZnJvbSBz dWJtb2R1bGUgaW4gWUFORyAxLjA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIHN1Ym1vZHVsZSBjb25jZXB0IGluIFlBTkcgMS4wIGlzLCB3 ZWxsLCBub3QgdmVyeSB1c2VmdWwsIGFuZCBldmVuIGxlc3MgaW50dWl0aXZlLiBUaGF0J3Mgd2h5 IGl0IHNhdyBtYWpvciByZXdvcmsgaW4gWUFORyAxLjEuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgWUFORyAxLjAgc3VibW9kdWxlIGNhbm5v dCByZWZlcmVuY2UgdGhlIG1vZHVsZSB0aGF0IGluY2x1ZGVzIGl0LCBkaXJlY3RseSBvciBpbmRp cmVjdGx5LiBUaGlzIGlzIGJlY2F1c2UgaW4gWUFORyAxLjAgdGhlIHN5bWJvbHMgaW4gb3RoZXIg c3VibW9kdWxlcyBvZiB0aGUgc2FtZSBuYW1lc3BhY2UgYXJlIGludmlzaWJsZSB0byB0aGUgc3Vi bW9kdWxlIHVubGVzcyB0aGV5IGFyZSBleHBsaWNpdGx5IGluY2x1ZGVkLg0KIEFuZCBwYXJlbnQg bW9kdWxlcyBjYW4ndCBiZSBpbmNsdWRlZCBieSBhIHN1Ym1vZHVsZSBiZWNhdXNlIHRoYXQgd291 bGQgbGVhZCB0byBhbiBpbmNsdXNpb24gbG9vcC4gSXQgaXMgcG9zc2libGUgdG8gcmVmZXJlbmNl IChhdWdtZW50LCBldGMpIG90aGVyIHNpYmxpbmcgc3VibW9kdWxlcywgdGhvdWdoLiBTbyBpZiB5 b3Ugc3BsaXQgeW91ciBtb2R1bGVzIGNsZXZlcmx5LCB5b3UgbWlnaHQgYmUgYWJsZSB0byByZXNv bHZlIHlvdXIgcmVmZXJlbnRpYWwNCiBjb25zdHJhaW50cyBhbnl3YXkuJm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdSByZWFs bHkgd2FudCB0byB0YWtlIHRoZSBzdWJtb2R1bGUgcGF0aCwgSSdkIHJlY29tbWVuZCBtb3Zpbmcg dG8gWUFORyAxLjEuIEluIHRoZSBpbnRlcmVzdCBvZiBwcmVzZXJ2aW5nIHRoZSBoYWlyIHRvbmUg b2YgSVQtYXJjaGl0ZWN0cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+L2phbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdC IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPldl4oCZcmUgdHJ5aW5nIHRvIHNvbHZlIGEgbW9kdWxhcml0eSBwcm9ibGVt IHdpdGggYSBZQU5HIG1vZHVsZSBieSBzcGxpdHRpbmcgaXQgaW50byBzdWJtb2R1bGVzIGFuZCBh dWdtZW50aW5nIHRoZSBwYXJlbnQgbW9kdWxlIGZyb20gZWFjaCBzdWJtb2R1bGUuJm5ic3A7IEhv d2V2ZXIsIGRlc3BpdGUNCiB0aGUgd29yZGluZyBiZWxvdyBpbiBZQU5HIDEuMCBzZWN0aW9uIDcu MTUsIHdl4oCZdmUgZm91bmQgYSBjb3VwbGUgb2YgdGhyZWFkcyBvbmxpbmUgd2l0aCBjb21tZW50 cyBzdWdnZXN0aW5nIGl04oCZcyBvbmx5IGFsbG93ZWQgaW4gWUFORyAxLjE/Jm5ic3A7IFdvdWxk IGFwcHJlY2lhdGUgY2xhcmlmaWNhdGlvbi48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5SRkMgNjAyMCBzZWN0aW9uIDcuMTUgc3Vn Z2VzdHMgaXQgaXMgYWxsb3dlZDo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPuKAmDwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDsmbmJzcDsgVGhlICZxdW90O2F1Z21lbnQmcXVvdDsgc3RhdGVtZW50IGFsbG93cyBh IG1vZHVsZSBvciBzdWJtb2R1bGUgdG8gYWRkIHRvIHRoZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgc2NoZW1hIHRyZWUgZGVmaW5lZCBpbiBhbiBleHRl cm5hbCBtb2R1bGUsIG9yIHRoZSBjdXJyZW50IG1vZHVsZSBhbmQ8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGl0cyBzdWJtb2R1bGVzLCBhbmQgdG8gYWRk IHRvIHRoZSBub2RlcyBmcm9tIGEgZ3JvdXBpbmcgaW4gYSAmcXVvdDt1c2VzJnF1b3Q7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBzdGF0ZW1lbnQuPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+4oCY PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+VmVyc3VzIG9ubGluZSBjb21tZW50cyBoZXJlOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsLTJEYXJjaGl2 ZV93ZWJfbmV0bW9kX2N1cnJlbnRfbXNnMTU0MTguaHRtbCZhbXA7ZD1Ed01GYVEmYW1wO2M9TEZZ Wi1vOV9IVU1lTVRTUWljdmpJZyZhbXA7cj1GbUpQOUNINTR6NW1HM0RGR0JkY185cTFUTHBZUTMx LVRRLTI2X1FhOXZ3JmFtcDttPVlDNHc2Wmk5S2hCcDBNbm52QTQyX3FkUjJhTTN1T0ZXcFpZdGdG MTIyRWMmYW1wO3M9T3h4UVJEdWNFVEJhRFBuNEtHTldjTGx1NGU4QU1TZnV5SkpqcmtscDNSMCZh bXA7ZT0iPjxzcGFuIHN0eWxlPSJjb2xvcjojOTU0RjcyIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsLWFyY2hpdmUvd2ViL25ldG1vZC9jdXJyZW50L21zZzE1NDE4Lmh0bWw8L3NwYW4+PC9hPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1HQiI+4oCYPC9zcGFuPiZndDsgT24gMDEgTWFyIDIwMTYs IGF0IDEwOjM4LCBBbnRvbiBUa8OhxI1payAmbHQ7YW50b24udGthY2lrIGF0IHBhbnRoZW9uLnRl Y2gmZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZndDsgPG86cD48L286cD48L3By ZT4NCjxwcmU+Jmd0OyBIaSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mZ3Q7IE5vdGljZWQgb3Ro ZXIgaXNzdWUgd2l0aCBleGFtcGxlIHNldCw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mZ3Q7IElu IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fZ2l0aHViLmNvbV9tYmo0NjY4X3B5YW5nX2lzc3Vlc18xOTQmYW1wO2Q9RHdNRmFRJmFt cDtjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmYW1wO3I9Rm1KUDlDSDU0ejVtRzNERkdCZGNfOXEx VExwWVEzMS1UUS0yNl9RYTl2dyZhbXA7bT1ZQzR3NlppOUtoQnAwTW5udkE0Ml9xZFIyYU0zdU9G V3BaWXRnRjEyMkVjJmFtcDtzPWJrYWtLSkVaekNCcTNCa1A1TnpXLXdEWDZLT1pIcE9uVDB1LXlT ZzhyUzAmYW1wO2U9Ij48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+aHR0cHM6Ly9naXRodWIu Y29tL21iajQ2NjgvcHlhbmcvaXNzdWVzLzE5NDwvc3Bhbj48L2E+IExhZGEgc3RhdGVkIHRoYXQg aW4gWUFORyAxLjAgc3VibW9kdWxlIGNhbiBub3QgYXVnbWVudCBub2RlczxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPiZndDsgZGVmaW5lZCBpbiBwYXJlbnQgbW9kZWwuPG86cD48L286cD48L3ByZT4N CjxwcmU+Jmd0OyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mZ3Q7IElzIHRoYXQgY29ycmVjdCB0 aGF0IHN1Ym1vZHVsZSBjYW4gbm90IGF1Z21lbnQgZGVmaW5pdGlvbiBkZWZpbmVkIGluIHBhcmVu dCBtb2R1bGU/PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4N CjxwcmU+VGhpcyBpc24ndCBwb3NzaWJsZSBpbiBZQU5HIDEuMCBidXQgd2lsbCBiZSBwb3NzaWJs ZSBpbiAxLjEuIEhvd2V2ZXIsIGluIHRoZSBwcmVzZW50IGNhc2UgdGhlIGRlZmluaXRpb24gYmVp bmcgYXVnbWVudGVkIGZyb20gdGhlIHN1Ym1vZHVsZSBpcyBhcmd1YWJseSBpbiBhIGRpZmZlcmVu dCBtb2R1bGUuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4N CjxwcmU+TGFkYTxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+4oCYPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzLDwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldpbGxp YW08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzTmV3Um9tYW5QU01UJnF1b3Q7LHNlcmlmIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5ldG1v ZCBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9y ZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXNO ZXdSb21hblBTTVQmcXVvdDssc2VyaWY7Y29sb3I6Izk1NEY3MiI+bmV0bW9kQGlldGYub3JnPC9z cGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtU aW1lc05ld1JvbWFuUFNNVCZxdW90OyxzZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu b3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmFtcDtkPUR3TUZhUSZhbXA7Yz1MRllaLW85X0hV TWVNVFNRaWN2aklnJmFtcDtyPUZtSlA5Q0g1NHo1bUczREZHQmRjXzlxMVRMcFlRMzEtVFEtMjZf UWE5dncmYW1wO209WUM0dzZaaTlLaEJwME1ubnZBNDJfcWRSMmFNM3VPRldwWll0Z0YxMjJFYyZh bXA7cz14N3NLMWpXWXRTc1FKcjhyNkc3RmpXUjVnQW9NdGd2NnpSd3hUNGJ6TUdRJmFtcDtlPSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXNOZXdS b21hblBTTVQmcXVvdDssc2VyaWY7Y29sb3I6Izk1NEY3MiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E3378E0605547F4E854DEE0CB1116AB02102DCgbcdcmbx03intlatt_-- From nobody Mon Aug 7 10:05:19 2017 Return-Path: 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 0417513272F for ; Mon, 7 Aug 2017 10:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 xTnsK0pxhQ1s for ; Mon, 7 Aug 2017 10:05:15 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0100.outbound.protection.outlook.com [104.47.37.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0B6132792 for ; Mon, 7 Aug 2017 10:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=A8+Gylhca3CS83y3CTKC1vhJ0n/+ySJjEZzkpOSMTrM=; b=bBoF2ILaa45x9a9lknQzrNtuYFK6pTZeNU3khDbZluBg87eChU2/n/o5HGk13nAvo0zVY2BzP44H8F09fl80X6Puk3c97M0SnM/JUTDQfFYnK3N4z7eQwIIuShqCPBP4u9wLQGqupHF5jKvisPKFE9ENW80ih5yplIzwoNZ9fYc= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1314.namprd05.prod.outlook.com (10.160.183.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.9; Mon, 7 Aug 2017 17:05:13 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1341.010; Mon, 7 Aug 2017 17:05:13 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: ietf 99 minutes posted Thread-Index: AQHTD59VpJC0rifBb0K4lHstYTFgzA== Date: Mon, 7 Aug 2017 17:05:13 +0000 Message-ID: <591B6CDD-F8F6-4D52-96E7-F0DC25F7CF58@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1314; 6:O+4pRijNheowYcF035C0U+qdW55OtFsXe2oP2LUe+LXZbDsSrriS+ZMOBAQxkwkQG3vyRjUQcyMnM1F+gF6tCwEHFOG+hSvSQQ/2/TSBqkVfdozaZudxVcOj7O7VSqRFwXExFu+SLYCoWHqpzDaC8nYJRFgTHMICSzXQ3uhbwRfuzJsIq9h8lyc9nlBEpKrseIdYdrCgP5pbJZMF6ThpQfS6YKR6EM/e4yJMRdOSDtTEBQlwJAQFEWJKpyHbrOKV9n6dmTAuCkVS3v9QGsM8YtceuOJR4KcDmgZWXnpysCjkxPVLP2h0KM6wBmaXxE1PRmIa8lf2mJvHJScaVAiMXQ==; 5:BaHNrHuciLNBeaPh/Yka/+c2WJ5nrgoreZVxV/6POnVMP0rt+lnyhb7D5pqXNKOPo55vFJdsMB6eaw2u2ohp7+ISrUGtTyAAwKMrEIUEhRImUXECbJwL7DyL5xMAPbMSp8dmSXmeJ3kfiOJCjhi/1w==; 24:NoAjff6S1Llu4YhuVVoOqufCxy3zcL1cfaPUEkLZuE4Qz9EsWO7AiW4RhUSQG9G7xsQSzAzmGhy9s/ZvFu09tKOHXdbdh+tcG9h0q48D0IE=; 7:QkJqO0MYO2sf2ycQWuqFJxtcyJdFHtJdTmLsw8wXbhKytXaUnedkYCm+tZ6nUuspsWj5u4bOwZ/ZbuQSX87BoQwQYWK2MPoBP/qSF9R814PXKaKXRIVt3B8281ShxLOFCICN8pCotRpQRN0DseT7uYMZipHZujAKi6giZhJdZiPmC9F28pTxZX/pOzcqN7omaFe2DwWDLnjYi1+qrAxi9nnzXhLYYhIiKQh+C3HYSdw= x-ms-office365-filtering-correlation-id: 7523caf7-86ac-4d1f-fe86-08d4ddb6783d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1314; x-ms-traffictypediagnostic: BN3PR0501MB1314: x-exchange-antispam-report-test: UriScan:(120809045254105); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123562025)(20161123564025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1314; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1314; x-forefront-prvs: 0392679D18 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39840400002)(39410400002)(39450400003)(39860400002)(39400400002)(39850400002)(199003)(189002)(2900100001)(6116002)(68736007)(50986999)(102836003)(3846002)(54356999)(2351001)(6916009)(97736004)(6436002)(105586002)(36756003)(106356001)(1730700003)(53936002)(6306002)(6512007)(81166006)(38730400002)(33656002)(3660700001)(82746002)(110136004)(81156014)(2501003)(478600001)(8676002)(6506006)(83716003)(83506001)(966005)(7116003)(305945005)(6486002)(5660300001)(77096006)(99286003)(101416001)(3280700002)(5640700003)(7736002)(14454004)(189998001)(66066001)(2906002)(25786009)(86362001)(4001350100001)(558084003)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1314; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2017 17:05:13.6103 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1314 Archived-At: Subject: [netmod] ietf 99 minutes posted X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 17:05:17 -0000 DQpUaGUgbWludXRlcyBmb3IgdGhlIElFVEYgOTkgTkVUTU9EIHNlc3Npb25zIGhhdmUgYmVlbiBw b3N0ZWQuDQoNCiAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzk5L21hdGVy aWFscy9taW51dGVzLTk5LW5ldG1vZA0KDQoNClRoYW5rLXlvdSBNaWNoYWVsIGZvciByZXZpZXdp bmcgdGhlIHJlY29yZGluZ3MgdG8gZW5zdXJlIA0KY29tcGxldGVuZXNzIGFuZCBhY2N1cmFjeSEN Cg0KS2VudCANCg0K From nobody Mon Aug 7 12:30:40 2017 Return-Path: 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 9C3A91325CD for ; Mon, 7 Aug 2017 12:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-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 KP2o9LO09yre for ; Mon, 7 Aug 2017 12:30:36 -0700 (PDT) Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1041B13247F for ; Mon, 7 Aug 2017 12:30:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 0290514033DD; Mon, 7 Aug 2017 21:30:33 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id YYg3S2a2xgIY; Mon, 7 Aug 2017 21:30:32 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id C51C514033DE; Mon, 7 Aug 2017 21:30:32 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id zuV05tfqnBQ5; Mon, 7 Aug 2017 21:30:32 +0200 (CEST) Received: from [192.168.2.191] (cm-84.211.71.154.getinternet.no [84.211.71.154]) by mail.transpacket.com (Postfix) with ESMTPSA id 8837C14033D6; Mon, 7 Aug 2017 21:30:32 +0200 (CEST) To: "Ivory, William" References: <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com> Cc: "'netmod@ietf.org'" From: Vladimir Vassilev Message-ID: <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com> Date: Mon, 7 Aug 2017 21:30:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------867F8D49873980A68CDCA5DF" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 19:30:39 -0000 This is a multi-part message in MIME format. --------------867F8D49873980A68CDCA5DF Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hello, IMO "submodule"s are a striking example of redundant complexity in an=20 otherwise very close to perfection YANG (regardless if it is YANG 1.0 or=20 1.1). Modules and submodules have been around for a while however the ratio of=20 the currently published modules compared with the submodules is about 40=20 modules to 1 submodule (if one ignores all the modules and submodules=20 from particular networking hardware manufacturer that is particularly=20 keen on using submodules). As a far but still relevant analogy Java has=20 a limitation of 1 file per class and this atomicity has proven to be an=20 advantage especially in terms of enforcing modularity. IMO there is=20 nothing that can be done with the help of submodules that can not be=20 done without them. For the sake of the argument can you provide a synthesized description=20 of the problem that lead you to a drastic solution like "we=E2=80=99ll lo= ok at=20 trying to put everything into submodules in this case."? Vladimir On 08/07/2017 04:37 PM, Ivory, William wrote: > > Hi Jan, > > Thanks =E2=80=93 we=E2=80=99ll look at trying to put everything into su= bmodules in=20 > this case. > > Regards, > > William > > *From:*Jan Lindblad [mailto:janl@tail-f.com] > *Sent:* 07 August 2017 14:28 > *To:* Ivory, William > *Cc:* netmod@ietf.org > *Subject:* Re: [netmod] Query about augmenting module from submodule=20 > in YANG 1.0 > > The submodule concept in YANG 1.0 is, well, not very useful, and even=20 > 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,=20 > directly or indirectly. This is because in YANG 1.0 the symbols in=20 > other submodules of the same namespace are invisible to the submodule=20 > unless they are explicitly included. And parent modules can't be=20 > included by a submodule because that would lead to an inclusion loop.=20 > It is possible to reference (augment, etc) other sibling submodules,=20 > though. So if you split your modules cleverly, you might be able to=20 > resolve your referential constraints anyway. > > If you really want to take the submodule path, I'd recommend moving to=20 > YANG 1.1. In the interest of preserving the hair tone of IT-architects. > > /jan > > We=E2=80=99re trying to solve a modularity problem with a YANG modu= le 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=E2=80=99ve found a couple of threads online with c= omments > suggesting it=E2=80=99s only allowed in YANG 1.1? Would appreciate > clarification. > > RFC 6020 section 7.15 suggests it is allowed: > > =E2=80=98 > > The "augment" statement allows a module or submodule to add to t= he > > 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 "us= es" > > statement. > > =E2=80=98 > > Versus online comments > here:https://www.ietf.org/mail-archive/web/netmod/current/msg15418.= html > > > =E2=80=98> On 01 Mar 2016, at 10:38, Anton Tk=C3=A1=C4=8Dik wrote: > > > > > > Hi, > > > Noticed other issue with example set, > > > Inhttps://github.com/mbj4668/pyang/issues/194 > 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? > > =20 > > This isn't possible in YANG 1.0 but will be possible in 1.1. Howeve= r, in the present case the definition being augmented from the submodule = is arguably in a different module. > > =20 > > Lada > > =E2=80=98 > > Thanks, > > William > > _______________________________________________ > 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 --------------867F8D49873980A68CDCA5DF Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello,

IMO "submodule"s=C2=A0 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=C2=A0 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=E2=80=99ll look at trying to put everything into submodules in this case."?

Vladimir

On 08/07/2017 04:37 PM, Ivory, William wrote:

Hi Jan,

=C2=A0

Thanks =E2=80=93 we=E2=80=99ll look at trying to put everything into= submodules in this case.

=C2=A0

Regards,

=C2=A0

William

=C2=A0

From: Ja= n Lindblad [mailto:janl@tail-f.com]
Sent: 07 August 2017 14:28
To: Ivory, William <wi274w@intl.att.com> Cc: netmod@ietf.org
Subject: Re: [netmod] Query about augmenting module from submodule in YANG 1.0

=C2=A0

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.

=C2=A0

A YANG 1.0 submodule cannot reference th= e 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.=C2=A0

=C2=A0

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.

=C2=A0

/jan

=C2=A0

We=E2=80=99re trying to solve a modu= larity problem with a YANG module by splitting it into submodules and augmenting the parent module from each submodule.=C2=A0 However, despite the wording below in YANG 1.0 section 7.15, we=E2=80=99ve found= a couple of threads online with comments suggesting it=E2=80=99s only allowed in YANG 1.1?=C2=A0 Would = appreciate clarification.

=C2=A0

RFC 6020 section 7.15 suggests it is allowed:

=C2=A0

=E2=80=98
                

                  
=C2=A0=C2=A0 The "augment" statement all=
ows a
                      module or submodule to add to the

                

                

                  
=C2=A0=C2=A0 schema tree defined in an e=
xternal
                      module, or the current module and

                

                

                  
=C2=A0=C2=A0 its submodules, and to add =
to the
                      nodes from a grouping in a "uses"

                

                

                  
=C2=A0=C2=A0 statement.

                

                

                  
=E2=80=98

                

                

                  
=C2=A0

                

                
                

                  
=C2=A0

                

                
=E2=80=98> On 01 Mar =
2016, at 10:38, Anton Tk=C3=A1=C4=8Dik <anton.tkacik at pantheon.tech&=
gt; wrote:

                
> 

                
> Hi,

                
> Noticed other issue with example set,

                
> In https://github.com/mbj4668/pyang/issues/1=
94 Lada stated that in YANG 1.0 submodule can not augment node=
s

                
> defined in parent model.

                
> 

                
> Is that correct that submodule can not augment =
definition defined in parent module?

                
=C2=A0

                
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.

                
=C2=A0

                
Lada

                

                  
=E2=80=98

                

                

                  
=C2=A0

                

                

                  
Thanks,

                

                

                  
=C2=A0

                

                

                  
William

                

                

                  
=C2=A0

                

                

                  
=C2=A0

                

                
_______________________________________________

                    netmod mailing list

                  netmod@ietf.org

                  https://www.ietf.org/mailman/listinfo/netmod

=C2=A0



_______________________________________________
netmod mailing list
net=
mod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--------------867F8D49873980A68CDCA5DF-- From nobody Tue Aug 8 01:17:02 2017 Return-Path: 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 ; 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 ; 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 ; 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" To: "'Vladimir Vassilev'" CC: "'netmod@ietf.org'" Thread-Topic: [netmod] Query about augmenting module from submodule in YANG 1.0 Thread-Index: AdMMOPUClm48yMKSSEeEurX4RbXaiADP5++AAAR9DaAACC3kAAAcrpQg Date: Tue, 8 Aug 2017 08:15:32 +0000 Deferred-Delivery: Tue, 8 Aug 2017 08:16:34 +0000 Message-ID: References: <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 08:17:00 -0000 --_000_E3378E0605547F4E854DEE0CB1116AB0210631gbcdcmbx03intlatt_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVmxhZGltaXIsDQoNCldlIGhhdmUgb25lIFlBTkcgZmlsZSB0aGF0IHJlcHJlc2VudHMgbXVs dGlwbGUgY29tcG9uZW50cyBpbiB0aGUgc3lzdGVtLiAgQ3VycmVudGx5IHRoZXkgYXJlIGJ1bmRs ZWQgdG9nZXRoZXIsIHNvIGhhdmluZyBhIHNpbmdsZSBZQU5HIGZpbGUgaXMgb2suICBJbiBmdXR1 cmUgd2XigJlkIGxpa2UgdG8gYmUgYWJsZSB0byBicmVhayB0aGlzIGRvd24gaW50byBtdWx0aXBs ZSBkYWVtb25zIGVhY2ggZGVhbGluZyB3aXRoIGEgc3Vic2V0IG9mIHRoZSBZQU5HLiAgSG93ZXZl ciwgd2UgZG9u4oCZdCB3aXNoIHRvIGNoYW5nZSB0aGUgbmFtZXNwYWNlIG9mIHRoZSBZQU5HIGFz IHRoYXQgd291bGQgbm90IGJlIGJhY2t3YXJkcyBjb21wYXRpYmxlLiAgU28sIHN1Ym1vZHVsZXMg bG9va2VkIHRvIGJlIGEgZ29vZCB3YXkgdG8gZG8gdGhpcy4gIEkgd291bGRu4oCZdCBjYWxsIGl0 IGRyYXN0aWMg4oCTIGl0IGlzIG9uZSBZQU5HIGZpbGUgd2UgYXJlIHRhbGtpbmcgYWJvdXQgYnJl YWtpbmcgdXAgaW50byBwYXJ0cy4NCg0KUmVnYXJkcywNCg0KV2lsbGlhbQ0KDQpGcm9tOiBWbGFk aW1pciBWYXNzaWxldiBbbWFpbHRvOnZsYWRpbWlyQHRyYW5zcGFja2V0LmNvbV0NClNlbnQ6IDA3 IEF1Z3VzdCAyMDE3IDIwOjMxDQpUbzogSXZvcnksIFdpbGxpYW0gPHdpbGxpYW0uaXZvcnlAaW50 bC5hdHQuY29tPg0KQ2M6ICduZXRtb2RAaWV0Zi5vcmcnIDxuZXRtb2RAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogW25ldG1vZF0gUXVlcnkgYWJvdXQgYXVnbWVudGluZyBtb2R1bGUgZnJvbSBzdWJt b2R1bGUgaW4gWUFORyAxLjANCg0KDQpIZWxsbywNCklNTyAic3VibW9kdWxlInMgIGFyZSBhIHN0 cmlraW5nIGV4YW1wbGUgb2YgcmVkdW5kYW50IGNvbXBsZXhpdHkgaW4gYW4gb3RoZXJ3aXNlIHZl cnkgY2xvc2UgdG8gcGVyZmVjdGlvbiBZQU5HIChyZWdhcmRsZXNzIGlmIGl0IGlzIFlBTkcgMS4w IG9yIDEuMSkuDQoNCk1vZHVsZXMgYW5kIHN1Ym1vZHVsZXMgaGF2ZSBiZWVuIGFyb3VuZCBmb3Ig YSB3aGlsZSBob3dldmVyIHRoZSByYXRpbyBvZiB0aGUgY3VycmVudGx5IHB1Ymxpc2hlZCBtb2R1 bGVzIGNvbXBhcmVkIHdpdGggdGhlIHN1Ym1vZHVsZXMgaXMgYWJvdXQgNDAgbW9kdWxlcyB0byAx IHN1Ym1vZHVsZSAoaWYgb25lIGlnbm9yZXMgYWxsIHRoZSBtb2R1bGVzIGFuZCBzdWJtb2R1bGVz IGZyb20gIHBhcnRpY3VsYXIgbmV0d29ya2luZyBoYXJkd2FyZSBtYW51ZmFjdHVyZXIgdGhhdCBp cyBwYXJ0aWN1bGFybHkga2VlbiBvbiB1c2luZyBzdWJtb2R1bGVzKS4gQXMgYSBmYXIgYnV0IHN0 aWxsIHJlbGV2YW50IGFuYWxvZ3kgSmF2YSBoYXMgYSBsaW1pdGF0aW9uIG9mIDEgZmlsZSBwZXIg Y2xhc3MgYW5kIHRoaXMgYXRvbWljaXR5IGhhcyBwcm92ZW4gdG8gYmUgYW4gYWR2YW50YWdlIGVz cGVjaWFsbHkgaW4gdGVybXMgb2YgZW5mb3JjaW5nIG1vZHVsYXJpdHkuIElNTyB0aGVyZSBpcyBu b3RoaW5nIHRoYXQgY2FuIGJlIGRvbmUgd2l0aCB0aGUgaGVscCBvZiBzdWJtb2R1bGVzIHRoYXQg Y2FuIG5vdCBiZSBkb25lIHdpdGhvdXQgdGhlbS4NCg0KRm9yIHRoZSBzYWtlIG9mIHRoZSBhcmd1 bWVudCBjYW4geW91IHByb3ZpZGUgYSBzeW50aGVzaXplZCBkZXNjcmlwdGlvbiBvZiB0aGUgcHJv YmxlbSB0aGF0IGxlYWQgeW91IHRvIGEgZHJhc3RpYyBzb2x1dGlvbiBsaWtlICJ3ZeKAmWxsIGxv b2sgYXQgdHJ5aW5nIHRvIHB1dCBldmVyeXRoaW5nIGludG8gc3VibW9kdWxlcyBpbiB0aGlzIGNh c2UuIj8NCg0KVmxhZGltaXINCk9uIDA4LzA3LzIwMTcgMDQ6MzcgUE0sIEl2b3J5LCBXaWxsaWFt IHdyb3RlOg0KSGkgSmFuLA0KDQpUaGFua3Mg4oCTIHdl4oCZbGwgbG9vayBhdCB0cnlpbmcgdG8g cHV0IGV2ZXJ5dGhpbmcgaW50byBzdWJtb2R1bGVzIGluIHRoaXMgY2FzZS4NCg0KUmVnYXJkcywN Cg0KV2lsbGlhbQ0KDQpGcm9tOiBKYW4gTGluZGJsYWQgW21haWx0bzpqYW5sQHRhaWwtZi5jb21d DQpTZW50OiAwNyBBdWd1c3QgMjAxNyAxNDoyOA0KVG86IEl2b3J5LCBXaWxsaWFtIDx3aTI3NHdA aW50bC5hdHQuY29tPjxtYWlsdG86d2kyNzR3QGludGwuYXR0LmNvbT4NCkNjOiBuZXRtb2RAaWV0 Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBRdWVy eSBhYm91dCBhdWdtZW50aW5nIG1vZHVsZSBmcm9tIHN1Ym1vZHVsZSBpbiBZQU5HIDEuMA0KDQpU aGUgc3VibW9kdWxlIGNvbmNlcHQgaW4gWUFORyAxLjAgaXMsIHdlbGwsIG5vdCB2ZXJ5IHVzZWZ1 bCwgYW5kIGV2ZW4gbGVzcyBpbnR1aXRpdmUuIFRoYXQncyB3aHkgaXQgc2F3IG1ham9yIHJld29y ayBpbiBZQU5HIDEuMS4NCg0KQSBZQU5HIDEuMCBzdWJtb2R1bGUgY2Fubm90IHJlZmVyZW5jZSB0 aGUgbW9kdWxlIHRoYXQgaW5jbHVkZXMgaXQsIGRpcmVjdGx5IG9yIGluZGlyZWN0bHkuIFRoaXMg aXMgYmVjYXVzZSBpbiBZQU5HIDEuMCB0aGUgc3ltYm9scyBpbiBvdGhlciBzdWJtb2R1bGVzIG9m IHRoZSBzYW1lIG5hbWVzcGFjZSBhcmUgaW52aXNpYmxlIHRvIHRoZSBzdWJtb2R1bGUgdW5sZXNz IHRoZXkgYXJlIGV4cGxpY2l0bHkgaW5jbHVkZWQuIEFuZCBwYXJlbnQgbW9kdWxlcyBjYW4ndCBi ZSBpbmNsdWRlZCBieSBhIHN1Ym1vZHVsZSBiZWNhdXNlIHRoYXQgd291bGQgbGVhZCB0byBhbiBp bmNsdXNpb24gbG9vcC4gSXQgaXMgcG9zc2libGUgdG8gcmVmZXJlbmNlIChhdWdtZW50LCBldGMp IG90aGVyIHNpYmxpbmcgc3VibW9kdWxlcywgdGhvdWdoLiBTbyBpZiB5b3Ugc3BsaXQgeW91ciBt b2R1bGVzIGNsZXZlcmx5LCB5b3UgbWlnaHQgYmUgYWJsZSB0byByZXNvbHZlIHlvdXIgcmVmZXJl bnRpYWwgY29uc3RyYWludHMgYW55d2F5Lg0KDQpJZiB5b3UgcmVhbGx5IHdhbnQgdG8gdGFrZSB0 aGUgc3VibW9kdWxlIHBhdGgsIEknZCByZWNvbW1lbmQgbW92aW5nIHRvIFlBTkcgMS4xLiBJbiB0 aGUgaW50ZXJlc3Qgb2YgcHJlc2VydmluZyB0aGUgaGFpciB0b25lIG9mIElULWFyY2hpdGVjdHMu DQoNCi9qYW4NCg0KV2XigJlyZSB0cnlpbmcgdG8gc29sdmUgYSBtb2R1bGFyaXR5IHByb2JsZW0g d2l0aCBhIFlBTkcgbW9kdWxlIGJ5IHNwbGl0dGluZyBpdCBpbnRvIHN1Ym1vZHVsZXMgYW5kIGF1 Z21lbnRpbmcgdGhlIHBhcmVudCBtb2R1bGUgZnJvbSBlYWNoIHN1Ym1vZHVsZS4gIEhvd2V2ZXIs IGRlc3BpdGUgdGhlIHdvcmRpbmcgYmVsb3cgaW4gWUFORyAxLjAgc2VjdGlvbiA3LjE1LCB3ZeKA mXZlIGZvdW5kIGEgY291cGxlIG9mIHRocmVhZHMgb25saW5lIHdpdGggY29tbWVudHMgc3VnZ2Vz dGluZyBpdOKAmXMgb25seSBhbGxvd2VkIGluIFlBTkcgMS4xPyAgV291bGQgYXBwcmVjaWF0ZSBj bGFyaWZpY2F0aW9uLg0KDQpSRkMgNjAyMCBzZWN0aW9uIDcuMTUgc3VnZ2VzdHMgaXQgaXMgYWxs b3dlZDoNCg0KDQrigJgNCiAgIFRoZSAiYXVnbWVudCIgc3RhdGVtZW50IGFsbG93cyBhIG1vZHVs ZSBvciBzdWJtb2R1bGUgdG8gYWRkIHRvIHRoZQ0KICAgc2NoZW1hIHRyZWUgZGVmaW5lZCBpbiBh biBleHRlcm5hbCBtb2R1bGUsIG9yIHRoZSBjdXJyZW50IG1vZHVsZSBhbmQNCiAgIGl0cyBzdWJt b2R1bGVzLCBhbmQgdG8gYWRkIHRvIHRoZSBub2RlcyBmcm9tIGEgZ3JvdXBpbmcgaW4gYSAidXNl cyINCiAgIHN0YXRlbWVudC4NCuKAmA0KDQpWZXJzdXMgb25saW5lIGNvbW1lbnRzIGhlcmU6IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNnMTU0 MTguaHRtbDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3d3dy5pZXRmLm9yZ19tYWlsLTJEYXJjaGl2ZV93ZWJfbmV0bW9kX2N1cnJlbnRfbXNnMTU0 MTguaHRtbCZkPUR3TUZhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1GbUpQOUNINTR6NW1H M0RGR0JkY185cTFUTHBZUTMxLVRRLTI2X1FhOXZ3Jm09WUM0dzZaaTlLaEJwME1ubnZBNDJfcWRS MmFNM3VPRldwWll0Z0YxMjJFYyZzPU94eFFSRHVjRVRCYURQbjRLR05XY0xsdTRlOEFNU2Z1eUpK anJrbHAzUjAmZT0+DQoNCg0K4oCYPiBPbiAwMSBNYXIgMjAxNiwgYXQgMTA6MzgsIEFudG9uIFRr w6HEjWlrIDxhbnRvbi50a2FjaWsgYXQgcGFudGhlb24udGVjaD4gd3JvdGU6DQoNCj4NCg0KPiBI aSwNCg0KPiBOb3RpY2VkIG90aGVyIGlzc3VlIHdpdGggZXhhbXBsZSBzZXQsDQoNCj4gSW4gaHR0 cHM6Ly9naXRodWIuY29tL21iajQ2NjgvcHlhbmcvaXNzdWVzLzE5NDxodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21fbWJqNDY2OF9w eWFuZ19pc3N1ZXNfMTk0JmQ9RHdNRmFRJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPUZtSlA5 Q0g1NHo1bUczREZHQmRjXzlxMVRMcFlRMzEtVFEtMjZfUWE5dncmbT1ZQzR3NlppOUtoQnAwTW5u dkE0Ml9xZFIyYU0zdU9GV3BaWXRnRjEyMkVjJnM9Ymtha0tKRVp6Q0JxM0JrUDVOelctd0RYNktP WkhwT25UMHUteVNnOHJTMCZlPT4gTGFkYSBzdGF0ZWQgdGhhdCBpbiBZQU5HIDEuMCBzdWJtb2R1 bGUgY2FuIG5vdCBhdWdtZW50IG5vZGVzDQoNCj4gZGVmaW5lZCBpbiBwYXJlbnQgbW9kZWwuDQoN Cj4NCg0KPiBJcyB0aGF0IGNvcnJlY3QgdGhhdCBzdWJtb2R1bGUgY2FuIG5vdCBhdWdtZW50IGRl ZmluaXRpb24gZGVmaW5lZCBpbiBwYXJlbnQgbW9kdWxlPw0KDQoNCg0KVGhpcyBpc24ndCBwb3Nz aWJsZSBpbiBZQU5HIDEuMCBidXQgd2lsbCBiZSBwb3NzaWJsZSBpbiAxLjEuIEhvd2V2ZXIsIGlu IHRoZSBwcmVzZW50IGNhc2UgdGhlIGRlZmluaXRpb24gYmVpbmcgYXVnbWVudGVkIGZyb20gdGhl IHN1Ym1vZHVsZSBpcyBhcmd1YWJseSBpbiBhIGRpZmZlcmVudCBtb2R1bGUuDQoNCg0KDQpMYWRh DQrigJgNCg0KVGhhbmtzLA0KDQpXaWxsaWFtDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRm Lm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9uZXRtb2Q8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed01G YVEmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9Rm1KUDlDSDU0ejVtRzNERkdCZGNfOXExVExw WVEzMS1UUS0yNl9RYTl2dyZtPVlDNHc2Wmk5S2hCcDBNbm52QTQyX3FkUjJhTTN1T0ZXcFpZdGdG MTIyRWMmcz14N3NLMWpXWXRTc1FKcjhyNkc3RmpXUjVnQW9NdGd2NnpSd3hUNGJ6TUdRJmU9Pg0K DQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNCm5ldG1vZCBtYWlsaW5nIGxpc3QNCg0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RA aWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9k PGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3 LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmQ9RHdNRmFRJmM9TEZZWi1vOV9IVU1l TVRTUWljdmpJZyZyPUZtSlA5Q0g1NHo1bUczREZHQmRjXzlxMVRMcFlRMzEtVFEtMjZfUWE5dncm bT1NN3Q4dlRVYjcxWFJXVzdaZlNIVE1sRkVhQWh6T2RtUXVCbXcyYWgtdUdjJnM9TkZKTDFSallO eE5NY25QaGhtLS1FQ3dkRWR5VVhIR0VWRXE0ZnNqenJ1ayZlPT4NCg0K --_000_E3378E0605547F4E854DEE0CB1116AB0210631gbcdcmbx03intlatt_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRpbWVzTmV3Um9t YW5QU01UO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7DQoJY29sb3I6YmxhY2s7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjsNCgljb2xvcjpibGFjazt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9y bWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UN Cgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHls ZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGkgVmxhZGltaXIsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XZSBoYXZlIG9uZSBZQU5HIGZpbGUgdGhhdCBy ZXByZXNlbnRzIG11bHRpcGxlIGNvbXBvbmVudHMgaW4gdGhlIHN5c3RlbS4mbmJzcDsgQ3VycmVu dGx5IHRoZXkgYXJlIGJ1bmRsZWQgdG9nZXRoZXIsIHNvIGhhdmluZyBhIHNpbmdsZSBZQU5HIGZp bGUgaXMgb2suJm5ic3A7IEluIGZ1dHVyZQ0KIHdl4oCZZCBsaWtlIHRvIGJlIGFibGUgdG8gYnJl YWsgdGhpcyBkb3duIGludG8gbXVsdGlwbGUgZGFlbW9ucyBlYWNoIGRlYWxpbmcgd2l0aCBhIHN1 YnNldCBvZiB0aGUgWUFORy4mbmJzcDsgSG93ZXZlciwgd2UgZG9u4oCZdCB3aXNoIHRvIGNoYW5n ZSB0aGUgbmFtZXNwYWNlIG9mIHRoZSBZQU5HIGFzIHRoYXQgd291bGQgbm90IGJlIGJhY2t3YXJk cyBjb21wYXRpYmxlLiZuYnNwOyBTbywgc3VibW9kdWxlcyBsb29rZWQgdG8gYmUgYSBnb29kIHdh eSB0byBkbyB0aGlzLiZuYnNwOw0KIEkgd291bGRu4oCZdCBjYWxsIGl0IGRyYXN0aWMg4oCTIGl0 IGlzIG9uZSBZQU5HIGZpbGUgd2UgYXJlIHRhbGtpbmcgYWJvdXQgYnJlYWtpbmcgdXAgaW50byBw YXJ0cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaWxsaWFtPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjp3aW5kb3d0ZXh0Ij4gVmxhZGltaXIgVmFzc2lsZXYgW21haWx0bzp2bGFkaW1pckB0cmFuc3Bh Y2tldC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gMDcgQXVndXN0IDIwMTcgMjA6MzE8YnI+DQo8 Yj5Ubzo8L2I+IEl2b3J5LCBXaWxsaWFtICZsdDt3aWxsaWFtLml2b3J5QGludGwuYXR0LmNvbSZn dDs8YnI+DQo8Yj5DYzo8L2I+ICduZXRtb2RAaWV0Zi5vcmcnICZsdDtuZXRtb2RAaWV0Zi5vcmcm Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbmV0bW9kXSBRdWVyeSBhYm91dCBhdWdtZW50 aW5nIG1vZHVsZSBmcm9tIHN1Ym1vZHVsZSBpbiBZQU5HIDEuMDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwPkhlbGxvLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JTU8gJnF1b3Q7c3VibW9kdWxlJnF1b3Q7cyZuYnNw OyBhcmUgYSBzdHJpa2luZyBleGFtcGxlIG9mIHJlZHVuZGFudCBjb21wbGV4aXR5IGluIGFuIG90 aGVyd2lzZSB2ZXJ5IGNsb3NlIHRvIHBlcmZlY3Rpb24gWUFORyAocmVnYXJkbGVzcyBpZiBpdCBp cyBZQU5HIDEuMCBvciAxLjEpLg0KPGJyPg0KPGJyPg0KTW9kdWxlcyBhbmQgc3VibW9kdWxlcyBo YXZlIGJlZW4gYXJvdW5kIGZvciBhIHdoaWxlIGhvd2V2ZXIgdGhlIHJhdGlvIG9mIHRoZSBjdXJy ZW50bHkgcHVibGlzaGVkIG1vZHVsZXMgY29tcGFyZWQgd2l0aCB0aGUgc3VibW9kdWxlcyBpcyBh Ym91dCA0MCBtb2R1bGVzIHRvIDEgc3VibW9kdWxlIChpZiBvbmUgaWdub3JlcyBhbGwgdGhlIG1v ZHVsZXMgYW5kIHN1Ym1vZHVsZXMgZnJvbSZuYnNwOyBwYXJ0aWN1bGFyIG5ldHdvcmtpbmcgaGFy ZHdhcmUgbWFudWZhY3R1cmVyDQogdGhhdCBpcyBwYXJ0aWN1bGFybHkga2VlbiBvbiB1c2luZyBz dWJtb2R1bGVzKS4gQXMgYSBmYXIgYnV0IHN0aWxsIHJlbGV2YW50IGFuYWxvZ3kgSmF2YSBoYXMg YSBsaW1pdGF0aW9uIG9mIDEgZmlsZSBwZXIgY2xhc3MgYW5kIHRoaXMgYXRvbWljaXR5IGhhcyBw cm92ZW4gdG8gYmUgYW4gYWR2YW50YWdlIGVzcGVjaWFsbHkgaW4gdGVybXMgb2YgZW5mb3JjaW5n IG1vZHVsYXJpdHkuIElNTyB0aGVyZSBpcyBub3RoaW5nIHRoYXQgY2FuIGJlIGRvbmUNCiB3aXRo IHRoZSBoZWxwIG9mIHN1Ym1vZHVsZXMgdGhhdCBjYW4gbm90IGJlIGRvbmUgd2l0aG91dCB0aGVt Ljxicj4NCjxicj4NCjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZvciB0aGUgc2FrZSBv ZiB0aGUgYXJndW1lbnQgY2FuIHlvdSBwcm92aWRlIGEgc3ludGhlc2l6ZWQgZGVzY3JpcHRpb24g b2YgdGhlIHByb2JsZW0gdGhhdCBsZWFkIHlvdSB0byBhIGRyYXN0aWMgc29sdXRpb24gbGlrZSAm cXVvdDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj53 ZeKAmWxsDQogbG9vayBhdCB0cnlpbmcgdG8gcHV0IGV2ZXJ5dGhpbmcgaW50byBzdWJtb2R1bGVz IGluIHRoaXMgY2FzZS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+JnF1b3Q7 Pzwvc3Bhbj48YnI+DQo8YnI+DQpWbGFkaW1pcjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIDA4LzA3LzIwMTcgMDQ6MzcgUE0sIEl2b3J5LCBXaWxsaWFtIHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBKYW4sPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3Mg4oCTIHdl4oCZbGwgbG9vayBhdCB0cnlpbmcgdG8g cHV0IGV2ZXJ5dGhpbmcgaW50byBzdWJtb2R1bGVzIGluIHRoaXMgY2FzZS48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaWxsaWFtPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiBKYW4gTGluZGJsYWQgWzxhIGhyZWY9Im1haWx0bzpqYW5sQHRh aWwtZi5jb20iPm1haWx0bzpqYW5sQHRhaWwtZi5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+ IDA3IEF1Z3VzdCAyMDE3IDE0OjI4PGJyPg0KPGI+VG86PC9iPiBJdm9yeSwgV2lsbGlhbSA8YSBo cmVmPSJtYWlsdG86d2kyNzR3QGludGwuYXR0LmNvbSI+Jmx0O3dpMjc0d0BpbnRsLmF0dC5jb20m Z3Q7PC9hPjxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+ bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW25ldG1vZF0gUXVl cnkgYWJvdXQgYXVnbWVudGluZyBtb2R1bGUgZnJvbSBzdWJtb2R1bGUgaW4gWUFORyAxLjA8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHN1 Ym1vZHVsZSBjb25jZXB0IGluIFlBTkcgMS4wIGlzLCB3ZWxsLCBub3QgdmVyeSB1c2VmdWwsIGFu ZCBldmVuIGxlc3MgaW50dWl0aXZlLiBUaGF0J3Mgd2h5IGl0IHNhdyBtYWpvciByZXdvcmsgaW4g WUFORyAxLjEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkEgWUFORyAxLjAgc3VibW9kdWxlIGNhbm5vdCByZWZlcmVuY2UgdGhlIG1vZHVsZSB0 aGF0IGluY2x1ZGVzIGl0LCBkaXJlY3RseSBvciBpbmRpcmVjdGx5LiBUaGlzIGlzIGJlY2F1c2Ug aW4gWUFORyAxLjAgdGhlIHN5bWJvbHMgaW4gb3RoZXIgc3VibW9kdWxlcyBvZiB0aGUgc2FtZSBu YW1lc3BhY2UgYXJlIGludmlzaWJsZSB0byB0aGUgc3VibW9kdWxlIHVubGVzcyB0aGV5IGFyZSBl eHBsaWNpdGx5IGluY2x1ZGVkLg0KIEFuZCBwYXJlbnQgbW9kdWxlcyBjYW4ndCBiZSBpbmNsdWRl ZCBieSBhIHN1Ym1vZHVsZSBiZWNhdXNlIHRoYXQgd291bGQgbGVhZCB0byBhbiBpbmNsdXNpb24g bG9vcC4gSXQgaXMgcG9zc2libGUgdG8gcmVmZXJlbmNlIChhdWdtZW50LCBldGMpIG90aGVyIHNp Ymxpbmcgc3VibW9kdWxlcywgdGhvdWdoLiBTbyBpZiB5b3Ugc3BsaXQgeW91ciBtb2R1bGVzIGNs ZXZlcmx5LCB5b3UgbWlnaHQgYmUgYWJsZSB0byByZXNvbHZlIHlvdXIgcmVmZXJlbnRpYWwNCiBj b25zdHJhaW50cyBhbnl3YXkuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdSByZWFsbHkgd2FudCB0byB0YWtlIHRoZSBzdWJt b2R1bGUgcGF0aCwgSSdkIHJlY29tbWVuZCBtb3ZpbmcgdG8gWUFORyAxLjEuIEluIHRoZSBpbnRl cmVzdCBvZiBwcmVzZXJ2aW5nIHRoZSBoYWlyIHRvbmUgb2YgSVQtYXJjaGl0ZWN0cy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+L2phbjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldl4oCZcmUgdHJ5 aW5nIHRvIHNvbHZlIGEgbW9kdWxhcml0eSBwcm9ibGVtIHdpdGggYSBZQU5HIG1vZHVsZSBieSBz cGxpdHRpbmcgaXQgaW50byBzdWJtb2R1bGVzIGFuZCBhdWdtZW50aW5nIHRoZSBwYXJlbnQgbW9k dWxlIGZyb20gZWFjaCBzdWJtb2R1bGUuJm5ic3A7IEhvd2V2ZXIsIGRlc3BpdGUNCiB0aGUgd29y ZGluZyBiZWxvdyBpbiBZQU5HIDEuMCBzZWN0aW9uIDcuMTUsIHdl4oCZdmUgZm91bmQgYSBjb3Vw bGUgb2YgdGhyZWFkcyBvbmxpbmUgd2l0aCBjb21tZW50cyBzdWdnZXN0aW5nIGl04oCZcyBvbmx5 IGFsbG93ZWQgaW4gWUFORyAxLjE/Jm5ic3A7IFdvdWxkIGFwcHJlY2lhdGUgY2xhcmlmaWNhdGlv bi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5SRkMgNjAyMCBzZWN0aW9uIDcuMTUgc3VnZ2VzdHMgaXQgaXMgYWxs b3dlZDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tR0IiPuKAmDwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlm Ij4mbmJzcDsmbmJzcDsgVGhlICZxdW90O2F1Z21lbnQmcXVvdDsgc3RhdGVtZW50IGFsbG93cyBh IG1vZHVsZSBvciBzdWJtb2R1bGUgdG8gYWRkIHRvIHRoZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7LHNlcmlmIj4mbmJz cDsmbmJzcDsgc2NoZW1hIHRyZWUgZGVmaW5lZCBpbiBhbiBleHRlcm5hbCBtb2R1bGUsIG9yIHRo ZSBjdXJyZW50IG1vZHVsZSBhbmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7IGl0cyBz dWJtb2R1bGVzLCBhbmQgdG8gYWRkIHRvIHRoZSBub2RlcyBmcm9tIGEgZ3JvdXBpbmcgaW4gYSAm cXVvdDt1c2VzJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyBzdGF0ZW1lbnQu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+4oCYPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0Ii IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VmVyc3Vz IG9ubGluZSBjb21tZW50cyBoZXJlOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsLTJEYXJjaGl2ZV93ZWJfbmV0bW9k X2N1cnJlbnRfbXNnMTU0MTguaHRtbCZhbXA7ZD1Ed01GYVEmYW1wO2M9TEZZWi1vOV9IVU1lTVRT UWljdmpJZyZhbXA7cj1GbUpQOUNINTR6NW1HM0RGR0JkY185cTFUTHBZUTMxLVRRLTI2X1FhOXZ3 JmFtcDttPVlDNHc2Wmk5S2hCcDBNbm52QTQyX3FkUjJhTTN1T0ZXcFpZdGdGMTIyRWMmYW1wO3M9 T3h4UVJEdWNFVEJhRFBuNEtHTldjTGx1NGU4QU1TZnV5SkpqcmtscDNSMCZhbXA7ZT0iPjxzcGFu IHN0eWxlPSJjb2xvcjojOTU0RjcyIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUv d2ViL25ldG1vZC9jdXJyZW50L21zZzE1NDE4Lmh0bWw8L3NwYW4+PC9hPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHByZT48c3BhbiBsYW5nPSJFTi1HQiI+4oCYPC9zcGFuPiZndDsgT24gMDEgTWFyIDIwMTYsIGF0 IDEwOjM4LCBBbnRvbiBUa8OhxI1payAmbHQ7YW50b24udGthY2lrIGF0IHBhbnRoZW9uLnRlY2gm Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZndDsgPG86cD48L286cD48L3ByZT4N CjxwcmU+Jmd0OyBIaSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mZ3Q7IE5vdGljZWQgb3RoZXIg aXNzdWUgd2l0aCBleGFtcGxlIHNldCw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mZ3Q7IEluIDxh IGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fZ2l0aHViLmNvbV9tYmo0NjY4X3B5YW5nX2lzc3Vlc18xOTQmYW1wO2Q9RHdNRmFRJmFtcDtj PUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmYW1wO3I9Rm1KUDlDSDU0ejVtRzNERkdCZGNfOXExVExw WVEzMS1UUS0yNl9RYTl2dyZhbXA7bT1ZQzR3NlppOUtoQnAwTW5udkE0Ml9xZFIyYU0zdU9GV3Ba WXRnRjEyMkVjJmFtcDtzPWJrYWtLSkVaekNCcTNCa1A1TnpXLXdEWDZLT1pIcE9uVDB1LXlTZzhy UzAmYW1wO2U9Ij48c3BhbiBzdHlsZT0iY29sb3I6Izk1NEY3MiI+aHR0cHM6Ly9naXRodWIuY29t L21iajQ2NjgvcHlhbmcvaXNzdWVzLzE5NDwvc3Bhbj48L2E+IExhZGEgc3RhdGVkIHRoYXQgaW4g WUFORyAxLjAgc3VibW9kdWxlIGNhbiBub3QgYXVnbWVudCBub2RlczxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPiZndDsgZGVmaW5lZCBpbiBwYXJlbnQgbW9kZWwuPG86cD48L286cD48L3ByZT4NCjxw cmU+Jmd0OyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mZ3Q7IElzIHRoYXQgY29ycmVjdCB0aGF0 IHN1Ym1vZHVsZSBjYW4gbm90IGF1Z21lbnQgZGVmaW5pdGlvbiBkZWZpbmVkIGluIHBhcmVudCBt b2R1bGU/PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxw cmU+VGhpcyBpc24ndCBwb3NzaWJsZSBpbiBZQU5HIDEuMCBidXQgd2lsbCBiZSBwb3NzaWJsZSBp biAxLjEuIEhvd2V2ZXIsIGluIHRoZSBwcmVzZW50IGNhc2UgdGhlIGRlZmluaXRpb24gYmVpbmcg YXVnbWVudGVkIGZyb20gdGhlIHN1Ym1vZHVsZSBpcyBhcmd1YWJseSBpbiBhIGRpZmZlcmVudCBt b2R1bGUuPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjxw cmU+TGFkYTxvOnA+PC9vOnA+PC9wcmU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+4oCYPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzLDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPldpbGxpYW08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OlRpbWVzTmV3Um9tYW5QU01UIj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+ DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6VGltZXNOZXdSb21hblBTTVQ7Y29sb3I6Izk1NEY3 MiI+bmV0bW9kQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTpUaW1lc05ld1JvbWFuUFNNVCI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lmll dGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmFtcDtkPUR3TUZhUSZhbXA7Yz1MRllaLW85 X0hVTWVNVFNRaWN2aklnJmFtcDtyPUZtSlA5Q0g1NHo1bUczREZHQmRjXzlxMVRMcFlRMzEtVFEt MjZfUWE5dncmYW1wO209WUM0dzZaaTlLaEJwME1ubnZBNDJfcWRSMmFNM3VPRldwWll0Z0YxMjJF YyZhbXA7cz14N3NLMWpXWXRTc1FKcjhyNkc3RmpXUjVnQW9NdGd2NnpSd3hUNGJ6TUdRJmFtcDtl PSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6VGltZXNOZXdSb21h blBTTVQ7Y29sb3I6Izk1NEY3MiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2Q8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwv cD4NCjxwcmU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5uZXRtb2QgbWFpbGluZyBsaXN0PG86cD48L286cD48L3By ZT4NCjxwcmU+PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3Jn PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5w cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlz dGluZm9fbmV0bW9kJmFtcDtkPUR3TUZhUSZhbXA7Yz1MRllaLW85X0hVTWVNVFNRaWN2aklnJmFt cDtyPUZtSlA5Q0g1NHo1bUczREZHQmRjXzlxMVRMcFlRMzEtVFEtMjZfUWE5dncmYW1wO209TTd0 OHZUVWI3MVhSV1c3WmZTSFRNbEZFYUFoek9kbVF1Qm13MmFoLXVHYyZhbXA7cz1ORkpMMVJqWU54 Tk1jblBoaG0tLUVDd2RFZHlVWEhHRVZFcTRmc2p6cnVrJmFtcDtlPSI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_E3378E0605547F4E854DEE0CB1116AB0210631gbcdcmbx03intlatt_-- From nobody Wed Aug 9 04:37:01 2017 Return-Path: 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 C3AD8132143 for ; Wed, 9 Aug 2017 04:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 N47Fibn-AdTx for ; Wed, 9 Aug 2017 04:36:57 -0700 (PDT) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50098.outbound.protection.outlook.com [40.107.5.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFEC0131D32 for ; Wed, 9 Aug 2017 04:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=500hwAvBY2pqkTijbDVdWC8ed1rQXKHaimbvh/U/x+M=; b=Sspmk60bYXmkrDaNz8fmjspeJpn1+LkSW7qCKYSkbsckWW0iEuW9c1gncaTSRrzYmKvETUvx6VJ9hYKuPurDM2pzIAEpsUyUr+d5X6Qc017byW0CFYCCjy289A5bQe1CKqW3rJvtCJT9+ZoVkNwAe2saNIGiegi1A7YKmc5GxbE= Received: from pc6 (86.176.20.38) by HE1PR0701MB3002.eurprd07.prod.outlook.com (2603:10a6:3:4d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.9; Wed, 9 Aug 2017 11:36:54 +0000 Message-ID: <055c01d31103$28f51200$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Clyde Wildes \(cwildes\)" , "Kent Watsen" , References: <91FA5813-8D96-414F-BAC6-BA6C65C5149C@cisco.com> Date: Wed, 9 Aug 2017 12:32:03 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.176.20.38] X-ClientProxiedBy: VI1P194CA0011.EURP194.PROD.OUTLOOK.COM (2603:10a6:800:be::21) To HE1PR0701MB3002.eurprd07.prod.outlook.com (2603:10a6:3:4d::8) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2e17c27a-7359-4737-6044-08d4df1aef99 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 3:jZqDdAVfLpset28o/X+wk1iSjwD+P95nfh3UjpywkN2W/vgODMDGnrWOGMCbARjt93iIoLPvJQQktIa3IecIG3pSyaz1J1EjU+WwOSYDGypX+2EQUoIFxRaj2bs9S694EYH4UJYdBSi1ZCcpBSbvTWaMv/KVmwR8ewY4S6wZ4BWUObBeNfyRsShY6kttwOEKN1lEfYXIp9MuknXp2JQkcND2Xl0+vZ3iBv8PfzUyspiiY2MQlR7vO5DUbiE3pni7; 25:0571Wew9NdQm0YQkR7+h2oAI2xBjg5CEh+WgeyL1HPO3FY6oR/a4jDB2RBEc2fmAdM4Mw2f0MZ7Ysbv6jiugIjq6mHhL8rHDSh07XnChS0/StD3ZFzZ2DO7qwG2vOdmInzpPezH9GWnuPp4keOcCik15TKaN2WptQ/+Y29MWKIlryupzRX0a+RdOVbhher8D1CBcybkCJLxYWHBv8kPGJj/8/FxD9khOVUGZmjkUIy4ysgN0kaseDyboLlAx3NQj12yh66mtmUa3c1m6wTHJM24J4IYgjxbfcb8/KUIwD8tsK3DAF3pa+OJHj6PMTcIZhlJXGnBAbMUXPjE9YhA6Qg==; 31:kUnAw+0GLz5hPTHk0S+WdLx6ScSn/xSR04t3ngem2Z/fLc9xKdryBeDZY5DItC6ZhxDrj0V3p03Gsiv0Y9hxN/iSawt3yr2NGV3KSGY4KlRlRFWPGrP/S+BO+MivKgxL8tv+EsEnuMuGtCoVBZAskGKTVLLZPVv0XEnrkvMfeBe5M726uUTV8ipRvlrWive/5xwIC5f7rhJbMXhYEFbNtz8eU5iSRn50d67TC2BIRyM= X-MS-TrafficTypeDiagnostic: HE1PR0701MB3002: X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(95692535739014)(17755550239193); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 4:10fBFdMcQd6/mWTZlRIc1lYEJHRcLFKtdeuRXkrPXemsXn1GDrDneyMnOnmVdlDDAfYSuhsqvfJFjZX14WLw+taw908xsTXKMGObGCbCkvkjEndSuVV9H8LLkCqAPirDFlkd9EJNB9vVT00NLWLL+J94vjJfs5StPfsHiXI8b5upbHe1Z7s+YZmKitUmLz01xtle+rLxDr0k5Qm3ehJ77tIqUu5gWvgabwjQWHV997wcP1340xMq6F4cUr2vE+3Dw5kN1Kn/ZmMGlhMrgjIeuSf399hFXGO5izemAFlNcktFi1OJU6rYDSXDH+v900P/nzT0nyRAvBb6jiajrmokWohnXruRz6JejPUfwwPh88EpFvLutJAbbteXzO2PsRKK X-Forefront-PRVS: 0394259C80 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6009001)(39400400002)(39860400002)(39450400003)(39840400002)(39410400002)(39850400002)(199003)(377454003)(189002)(24454002)(13464003)(81156014)(6116002)(3846002)(7350300001)(6246003)(81166006)(42186005)(14496001)(61296003)(230783001)(6496005)(81816999)(86362001)(105586002)(68736007)(6486002)(2870700001)(62236002)(76176999)(6666003)(44736005)(47776003)(116806002)(50986999)(101416001)(4720700003)(8666007)(2906002)(229853002)(81686999)(9686003)(66066001)(44716002)(97736004)(1941001)(53936002)(7736002)(305945005)(84392002)(8676002)(38730400002)(25786009)(189998001)(478600001)(50226002)(1456003)(33646002)(50466002)(106356001)(23676002)(5660300001)(1556002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3002; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3MDFNQjMwMDI7MjM6UnRLRTNVajhDRU14eGVjTUFRZE1QM0Y3?= =?utf-8?B?ZzUvM3ZybTdZenV2V3VrTmRlemRVQ3M0TlJrQ2EzZ2pUVzQvWXhoM2NibUdv?= =?utf-8?B?SzdWQnRMYTQ0WjFEMXhpOEJFaTRZaXNFL09Calk1MXlqYnNKVGp2L09na1Vx?= =?utf-8?B?R09ReGtNc1ZmcnhzYk5MZ3o5RlVvTklFQmVnWU9NZXNRQ0k0c3pIRzNHZDBI?= =?utf-8?B?eWtBL1hwM1ZKK25yZmpSd2R2NUtMUXpQMENaZktUMVI3aGw4SkVjaHJSZmg2?= =?utf-8?B?SVIzVzRFbVI2OVByUUtMUjRtak9sVm0wSHJrN3hqYWVSamtJL3p5bTlUSzZH?= =?utf-8?B?akgvVjcyb2lYdHBoeTgyaXdlSEFoekcxOXlHTVg1UTFjNWl2Wm9YTWJYZTlO?= =?utf-8?B?VUVwYjNQM3Y1bWJuYjNJcDBJNjVmVTdNL3VENkdEN0RMY1hTTHpIbEgxMkxt?= =?utf-8?B?SXJxcVhGSmx4eXJ5c3Z1akU3ejFEaWtSZC9xMHBDbFFQdlJsN1RtQWo3TllV?= =?utf-8?B?cFp2dU1xdysyNzhIOHJMdldEWWJxVGZrVDlyWEQ5cVNQOWU2cnMvcmxwTytm?= =?utf-8?B?aEhtSFdPaXVEOXY5aHBMQUZwZWRYNUUvbFZkWkFHZGQyWTVUT1ZHY0g2YTZ2?= =?utf-8?B?WEJmdGo1TzBteUM3Q2pQM2lXc3NoTS96MHlsZ0hnM05DSFQ3MzAvVkMvdzRs?= =?utf-8?B?UytiNFIzZmpsTnZocGt4Y1FpQmRmSDJCa25lcE11TnUyeHVqNzBNODJZNERM?= =?utf-8?B?OTJPbEZOSUtLNnpCWWpLTUR3c1N6b3lzWXQrWitpd2tGdHB5b1BCbVdUVXlU?= =?utf-8?B?dGpCTDhuc2JZNHNCYlNOM25WMi9UWTE5WkRiUmNQZ2l5eHpJaTR2bVBzemZt?= =?utf-8?B?U2FBajQzU29mWFZMU2x5dG0xbThCdVZhKys1SlRWZERHT3hUeWZobVhYemFI?= =?utf-8?B?VzJrcy9jc0xoSUN3RDNWZU13NDgyaEIzeU9lVHh1VWtNcU42UTlpaDZvckZz?= =?utf-8?B?ZWVsdEtDU2ZmVEV4NkdmN0VLcEhTd3RqS05QOXFZRndMbVJtb21LaFRWME5m?= =?utf-8?B?YlRhTkZrNkJLSHYzZ0t5eUR0WDBsZWovSW0vd2t0S1VCYWJkMVVjMWtoeUhJ?= =?utf-8?B?b21IaTVIOVQ0WDU5bnZPRXVwN1k1NHl2TzhmMTB0allUZU04UlVTd3cydjdD?= =?utf-8?B?KythcUZlb2h5MWVqeWc5WWNrVFZXYXNnbDJseHNpeW9naHE1dXdDMVlmZWta?= =?utf-8?B?YWx3TFJZMnNrVHhDdkkrcUxqTVhMRHE1RU1WUGluZWZJSmRzSUR1RWFkL1Fu?= =?utf-8?B?dlBkREdhZkN6R2lmT3duY1IyMzlZQlk5U3kzZVY2TXRENEhqZ29IdjdXUzcv?= =?utf-8?B?ZVlPSTg5cGhmd1BKV2pzUlN3Q0MxY3FkYjRYbkJYaDR0OEliMzlDc00yZzNE?= =?utf-8?B?bHN3N1RSL2krek56Ym02SExzdTZzU2FyYzJYV21JV3FYdmR1NkpPZ3poSEh4?= =?utf-8?B?M2VaSVZVSXBlODMydEdsSWhyTHlqbFVJL1ZRLzVoK25Ma09OMkxDdmZsOXlq?= =?utf-8?B?SUE4dHRTa3k2Q3RzQjdvZEwwU0lheU9hc0F0dDFVOXBJdGNZZWV5NjR6a1pO?= =?utf-8?B?dGZCRVJEblp5M2xYb3FLU2IybXRrNnFYYVZKd1ZtNnRUSjcvRnpRbUU3S0Uy?= =?utf-8?B?RS9vcU5kbmVZM1BsMVY4c0xvZ3U3ODJhd0xrSnZWQTlZbVVId3ZoUHVDVDJK?= =?utf-8?B?UWJUdkZvazlYd3pCMHZNdWF3ZFVVK3QvOTlNYnh2Z1Q2L29maHFEY0VPYzB6?= =?utf-8?B?VXl2RWxwRm5FVDNDQXQ3SnNVRGhQd3NxbWtHWjlmVWVqRCs2b2hMYml6UDlP?= =?utf-8?B?Vyswb2ViS1Uvb25QdWNhV2pyUXpobGZPRUI1ZU04Y3phM0NGWFN1aGtGd3Q4?= =?utf-8?B?TUNhekxDWUN6UEZ3d3hTRVN1NXl1dDhkejhrZW5BY1pTbThISmRkYzZBbFZl?= =?utf-8?B?eHo2Qk1wNzFDL1paQmh0VHNVT1Zqd0JVOXBxMWcrOXRTWkZVTVJFWlZxeFdl?= =?utf-8?B?aDNLUnJUcHZPL0ZPU2tuYTk1c2IvY1BodmpjWjhzeVROK2dzcVVUU1NxOTFk?= =?utf-8?B?WGpDMTV4RVZCNGZKUHhML3BCSi9GSm9WNDIydGRwMTU4WlNXZ1dKU2FiTzZQ?= =?utf-8?B?NGQvZ25HOEZPcEJYemRYYXlhTXh4Zmc9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:qSGEFu09PHt6hfemhjs51nObiU40l0WDj5SJlAED64RxMdiUMlem6/49NdADlO0vA8MYS0Nyp/89o9pDoI2o43ZD2+84AUHNes7CK1dR7Ot95oLTfRLwG+eTexw5QMsYB9HgV464koUIQF7eoykg8RLYc+kZ5jtpzi1Z+sP4YmuylTzoMha80MJC+Y4r87S6MccP0Cw0gJ5Gwnp0eZ1FPYhaYt+8Y8xAhkJ103a9S27fFhtd0dj/noHLroYQg83mOH7tirxc0s8Kp9gwRWhk2JHcpPc906rZwY1u1xmpTTSkvumNw1uQGhee/h86uPzaq2nqR565wx4KGAEvGC9zlw==; 5:H557CfFBEF2OFMseOtrRuYmCN8K/Rs1KlgOJ95CrVww4ciPkavET8NhSjfyUVd5nwYcCY2vU6wOc3fr/ty2LC4hplPxPco5pq9lajENLiWvGNC8STQsf/QmAnt2Njp1sy+oDmGM58GK6/KMXLqrSAw==; 24:cdToY2WWdxPsp0W8B53K2/om2mLNczz2hO2IGEpMp7wYSfF3+HgvMFaLZbB0l6CuukCZ01waRfZQqDLqAfHjwvJF78YP9lU2UzrVEODwnN4=; 7:MsexAamuUS7brTmPizxT/bt9Lje5AzExF6mcrkqxJljsa9NVdLqGcbKyf45E0kuONx4oTg1AcQ9pwzJrwCHjqNPtUSuVAl26hI/UbQcyu5+tGsU20igXMGXRmIIfkYpGkAKpeyhW2X8TyltV/O7OfsADSEoLUjjA2iZm56t3zam0B5Gg8b9LDPwkcMpO6RhQZuj9/Ww0MiXFmSw8t1wWAGS+VPDezTVRy9opU2vX6PQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Aug 2017 11:36:54.0219 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3002 Archived-At: Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 11:37:00 -0000 Clyde You use xxxx as a placeholder for three different RFC and two of these do not appear AFAICT in the list of References. This might be a challenge for the RFC Editor. Tom Petch ----- Original Message ----- From: "Clyde Wildes (cwildes)" Sent: Wednesday, July 19, 2017 6:48 PM > Hi Alex, > > Answers inline as [clyde]… > > On 7/17/17, 4:20 PM, "netmod on behalf of Alex Campbell" wrote: > > I am considering to implement the data model in this draft. (dependent on business priorities of course) > I have reviewed this draft and found the following issues. > > * I see pattern-match is specified to use POSIX 1003.2 regular expressions. This is presumably for compatibility with existing implementations; however it is inconsistent with most of YANG (which is specified to use XPath regular expressions) - unless these are the same. > > [clyde] I believe that my answer in the other thread explains why we used Posix 1003.2 – it is commonly used. > > * pattern-match is inside the facility-filter container; common sense says this is wrong as pattern-match has nothing to do with facilities. > > [clyde] I will move pattern-match up one level in the next version of the draft. Thanks for catching this! > > * The advanced-compare container groups together two nodes that share a common "when" and "if-feature" statement, but don't seem to have any semantic relation to each other. Are there general guidelines on when to use a container? > > [clyde] The confusion may come as a result of the when clause appearing before the if-feature clause which is set by the IETF statement order recommendation. > > The when construct was suggested by Martin Björklund as a way of solving the case that advanced-compare does not apply for the ‘all’ and ‘none’ case. > > The if-feature applies to the entire container – it is either supported or not. > > * The advanced-compare container has a description starting with "This leaf ..." even though it is not a leaf. > > [clyde] This will be fixed in the next draft. > > * The examples are missing nodes. > > [clyde] This will be fixed in the next draft. > > * Perhaps there should be more consistent terminology for receivers of syslog messages; both "collectors" and "actions" are used in the draft. RFC 5424 uses "collector" for the ultimate recipient of a log message - which might not be applicable, because the sending system has no idea whether the receiving system is a collector or a relay. > > [clyde] The definition of “collector” in RFC 5424 is: A "collector" gathers syslog content for further analysis. > > actions relate to the “further analysis” taken by the “collector”. > > “Collectors” appears in the model under the remote action and I believe the usage is correct: > container remote { > if-feature remote-action; > description > "This container describes the configuration parameters for > forwarding syslog messages to remote relays or collectors."; > > I will revise the description of these terms in the next draft. > > Thanks, > > Clyde > > ________________________________________ > From: netmod on behalf of Kent Watsen > Sent: Saturday, 8 July 2017 6:34 a.m. From nobody Wed Aug 9 05:32:23 2017 Return-Path: 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 9680B13219C for ; Wed, 9 Aug 2017 05:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.478 X-Spam-Level: X-Spam-Status: No, score=-13.478 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 QE_MFm4-vpUt for ; Wed, 9 Aug 2017 05:32:17 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB87B129B14 for ; Wed, 9 Aug 2017 05:32:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11599; q=dns/txt; s=iport; t=1502281936; x=1503491536; h=subject:cc:references:from:message-id:date:mime-version: in-reply-to; bh=+jRAc3Gkfe08iFzommb+I+bpBDTdFr1GUvn22sfNMfo=; b=WMda0pzIJ2XJlMcCPya4KnwJb9ZFAuOPQkYCIzA//OIc9u6I2f25LfkJ LsB5nHW8uMVcdt2oG6uaD8BI9A49fL4G4R05hpAi55pSAsqwEbODbusIf JYqhL11JfydokCsMKrJ2FcmELph1LEzK/EcNphSVNyjubnrY4eIuYbfka 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D7AQDW/4pZ/xbLJq1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhD6BBQ+PApBPMZBihTMOggQhAQyBXoJXFU8CJoUXFgECAQEBAQEBAWs?= =?us-ascii?q?ohRAJAgEDAQEhKyALEAkCFBAeAgInCiYTBgIBARAGAQIEhVGEPRCQIJ1kgiYni?= =?us-ascii?q?y0BAQEBAQEEAQEBAQEBAQEggyiDToIOgnyBPIMBFEKCcxOCTgEEiXmCEJQOh1O?= =?us-ascii?q?MY4JoiFqHD40iiGkmATCBCjIhCBwVHyp2D4QegXk+NodVgjIBAQU?= X-IronPort-AV: E=Sophos;i="5.41,347,1498521600"; d="scan'208,217";a="654843028" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Aug 2017 12:32:12 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v79CWBc9019277 for ; Wed, 9 Aug 2017 12:32:11 GMT Cc: netmod@ietf.org References: <20170731183346.AFB3CB8107F@rfc-editor.org> From: Benoit Claise Message-ID: <9ec8b82c-f746-20c9-95ac-b9a84bd1217a@cisco.com> Date: Wed, 9 Aug 2017 14:32:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170731183346.AFB3CB8107F@rfc-editor.org> Content-Type: multipart/alternative; boundary="------------234E2B9A64A314DD19684963" Content-Language: en-US Archived-At: Subject: Re: [netmod] RFC 8199 on YANG Module Classification X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 12:32:22 -0000 This is a multi-part message in MIME format. --------------234E2B9A64A314DD19684963 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, The good news is that the module-classification is already added as a metadata in the yangcatalog.org. leaf module-classification { type enumeration { enum network-service { description "Network Service YANG Module that describes the configuration, state data, operations, and notifications of abstract representations of services implemented on one or multiple network elements."; } enum network-element { description "Network Element YANG Module that describes the configuration, state data, operations, and notifications of specific device-centric technologies or features."; } enum unknown { description "In case that there is not sufficient information about how to classify the module."; } enum not-applicable { description "The YANG module abstraction type is neither a Network Service YANG Module nor a Network Element YANG Module."; } } mandatory true; description "The high-level classification of the given YANG module."; reference "RFC8199 YANG Module Classification"; } description "These leafs are shared among the yang-catalog and its API."; } This metadata can't be extracted from the module, but must be populated. That's the reason why you would see "unknown" for most modules right now. Ex: https://yangcatalog.org:8443/search/modules/ietf-l3vpn-svc,2017-01-27,ietf When populated, this will provide the ability to search for service versus network elements YANG modules. Regards, Benoit > A new Request for Comments is now available in online RFC libraries. > > > RFC 8199 > > Title: YANG Module Classification > Author: D. Bogdanovic, > B. Claise, > C. Moberg > Status: Informational > Stream: IETF > Date: July 2017 > Mailbox: dean@voltanet.io, > bclaise@cisco.com, > camoberg@cisco.com > Pages: 11 > Characters: 23080 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-netmod-yang-model-classification-08.txt > > URL: https://www.rfc-editor.org/info/rfc8199 > > DOI: 10.17487/RFC8199 > > The YANG data modeling language is currently being considered for a > wide variety of applications throughout the networking industry at > large. Many standards development organizations (SDOs), open-source > software projects, vendors, and users are using YANG to develop and > publish YANG modules for a wide variety of applications. At the same > time, there is currently no well-known terminology to categorize > various types of YANG modules. > > A consistent terminology would help with the categorization of YANG > modules, assist in the analysis of the YANG data modeling efforts in > the IETF and other organizations, and bring clarity to the YANG- > related discussions between the different groups. > > This document describes a set of concepts and associated terms to > support consistent classification of YANG modules. > > This document is a product of the NETCONF Data Modeling Language Working Group of the IETF. > > > INFORMATIONAL: This memo provides information for the Internet community. > It does not specify an Internet standard of any kind. Distribution of > this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > --------------234E2B9A64A314DD19684963 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Dear all,

The good news is that the module-classification is already added as a metadata in the yangcatalog.org.
   leaf module-classification {
     type enumeration {
       enum network-service {
         description
           "Network Service YANG Module that describes the configuration, state
            data, operations, and notifications of abstract representations of
            services implemented on one or multiple network elements.";
       }
       enum network-element {
         description
           "Network Element YANG Module that describes the configuration, state
            data, operations, and notifications of specific device-centric
            technologies or features.";
       }
       enum unknown {
         description
           "In case that there is not sufficient information about how to classify the module.";
       }
       enum not-applicable {
         description
           "The YANG module abstraction type is neither a Network Service YANG Module
            nor a Network Element YANG Module.";
       }
     }
     mandatory true;
     description
       "The high-level classification of the given YANG module.";
     reference
       "RFC8199 YANG Module Classification";
   }
   description
     "These leafs are shared among the yang-catalog and its API.";
 }

This metadata can't be extracted from the module, but must be populated.
That's the reason why you would see "unknown" for most modules right now.
Ex: https://yangcatalog.org:8443/search/modules/ietf-l3vpn-svc,2017-01-27,ietf

When populated, this will provide the ability to search for service versus network elements YANG modules.

Regards, Benoit
A new Request for Comments is now available in online RFC libraries.

        
        RFC 8199

        Title:      YANG Module Classification 
        Author:     D. Bogdanovic, 
                    B. Claise,
                    C. Moberg
        Status:     Informational
        Stream:     IETF
        Date:       July 2017
        Mailbox:    dean@voltanet.io, 
                    bclaise@cisco.com, 
                    camoberg@cisco.com
        Pages:      11
        Characters: 23080
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-netmod-yang-model-classification-08.txt

        URL:        https://www.rfc-editor.org/info/rfc8199

        DOI:        10.17487/RFC8199

The YANG data modeling language is currently being considered for a
wide variety of applications throughout the networking industry at
large.  Many standards development organizations (SDOs), open-source
software projects, vendors, and users are using YANG to develop and
publish YANG modules for a wide variety of applications.  At the same
time, there is currently no well-known terminology to categorize
various types of YANG modules.

A consistent terminology would help with the categorization of YANG
modules, assist in the analysis of the YANG data modeling efforts in
the IETF and other organizations, and bring clarity to the YANG-
related discussions between the different groups.

This document describes a set of concepts and associated terms to
support consistent classification of YANG modules.

This document is a product of the NETCONF Data Modeling Language Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
.

--------------234E2B9A64A314DD19684963-- From nobody Wed Aug 9 07:20:33 2017 Return-Path: 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 9CA94132382 for ; Wed, 9 Aug 2017 07:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 mQK6YxFVQTXo for ; Wed, 9 Aug 2017 07:20:28 -0700 (PDT) Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54A441321F1 for ; Wed, 9 Aug 2017 07:20:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id CE23292017A; Wed, 9 Aug 2017 16:20:25 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 6vN2qvkA4aiS; Wed, 9 Aug 2017 16:20:25 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 942C5931B8E; Wed, 9 Aug 2017 16:20:25 +0200 (CEST) Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Rl22cHgdqOFS; Wed, 9 Aug 2017 16:20:25 +0200 (CEST) Received: from [192.168.209.181] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 6B17392017A; Wed, 9 Aug 2017 16:20:25 +0200 (CEST) To: "Ivory, William" References: <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com> <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com> Cc: "'netmod@ietf.org'" From: Vladimir Vassilev Message-ID: Date: Wed, 9 Aug 2017 16:20:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 14:20:33 -0000 On 08/08/2017 10:15 AM, Ivory, William wrote: > > Hi Vladimir, > > We have one YANG file that represents multiple components in the=20 > system. Currently they are bundled together, so having a single YANG=20 > file is ok. In future we=E2=80=99d like to be able to break this down = into=20 > multiple daemons each dealing with a subset of the YANG. However, we=20 > don=E2=80=99t wish to change the namespace of the YANG as that would no= t be=20 > backwards compatible. So, submodules looked to be a good way to do=20 > this. I wouldn=E2=80=99t call it drastic =E2=80=93 it is one YANG file= we are talking=20 > about breaking up into parts. > I see your point. IMO the only real justification for people designing=20 using submodules instead of modules is when they are limited to single=20 namespace and need a workaround solution like in your case. I was hoping your problem could be something that can convince me that=20 submodules existence in YANG can be justified with more then its=20 function as a workaround replacement for modules in this particular case. My grudge against submodules is not only based on the significant=20 implementation and support effort they require for something that is=20 used very rarely. A completely separate source file quantum for YANG=20 that lacks the key property of a module at the YANG level - modularity.=20 For submodules are both non-reusable and interdependent. Very few=20 organizations publish submodule based designs probably for the same=20 reasons I avoid them. Submodules are great if you want to publish=20 non-reusable YANG though. IETF went once for design with submodules in ietf-snmp.yang. Even in=20 that case (well organized YANG module) I would have preferred a single=20 file with some of the exotic features modularized in separate modules=20 instead. Dynamic compilers still need to go through all submodules even=20 in device that supports only the base SNMP functionality before features=20 can be evaluated. As a result instead of the 10KB of actually=20 implemented schema 60KB of additional YANG has to be retrieved in the=20 worst case and compiled. Both submodules and alternative datastores are examples of how=20 complexity is introduced with innocent intentions and how it eventually=20 multiplies (ref. draft-nmdsdt-netconf-rfc7895bis-01). The biggest problem I have with submodules is they break the atomicity=20 of the module concept. There is something that is not right with that.=20 Worse than the unjustified implementation and standardization effort. A=20 compromise that should have been avoided. IMO If you absolutely don't need submodules it is best to stay away from=20 them. Vladimir > Regards, > > William > > *From:*Vladimir Vassilev [mailto:vladimir@transpacket.com] > *Sent:* 07 August 2017 20:31 > *To:* Ivory, William > *Cc:* 'netmod@ietf.org' > *Subject:* Re: [netmod] Query about augmenting module from submodule=20 > in YANG 1.0 > > Hello, > > IMO "submodule"s are a striking example of redundant complexity in an=20 > otherwise very close to perfection YANG (regardless if it is YANG 1.0=20 > or 1.1). > > Modules and submodules have been around for a while however the ratio=20 > of the currently published modules compared with the submodules is=20 > about 40 modules to 1 submodule (if one ignores all the modules and=20 > submodules from particular networking hardware manufacturer that is=20 > particularly keen on using submodules). As a far but still relevant=20 > analogy Java has a limitation of 1 file per class and this atomicity=20 > has proven to be an advantage especially in terms of enforcing=20 > modularity. IMO there is nothing that can be done with the help of=20 > submodules that can not be done without them. > > For the sake of the argument can you provide a synthesized description=20 > of the problem that lead you to a drastic solution like "we=E2=80=99ll = look at=20 > trying to put everything into submodules in this case."? > > Vladimir > > On 08/07/2017 04:37 PM, Ivory, William wrote: > > Hi Jan, > > Thanks =E2=80=93 we=E2=80=99ll look at trying to put everything int= o submodules in > this case. > > Regards, > > William > > *From:*Jan Lindblad [mailto:janl@tail-f.com] > *Sent:* 07 August 2017 14:28 > *To:* Ivory, William > > *Cc:* 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=E2=80=99re 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=E2=80=99ve found a couple of > threads online with comments suggesting it=E2=80=99s only allow= ed in > YANG 1.1? Would appreciate clarification. > > RFC 6020 section 7.15 suggests it is allowed: > > =E2=80=98 > > 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. > > =E2=80=98 > > Versus online comments > here:https://www.ietf.org/mail-archive/web/netmod/current/msg15= 418.html > > > =E2=80=98> On 01 Mar 2016, at 10:38, Anton Tk=C3=A1=C4=8Dik wrote: > > > > > > Hi, > > > Noticed other issue with example set, > > > Inhttps://github.com/mbj4668/pyang/issues/194 > L= ada stated that in YANG 1.0 submodule can not augment nodes > > > defined in parent model. > > > > > > Is that correct that submodule can not augment definition def= ined in parent module? > > =20 > > This isn't possible in YANG 1.0 but will be possible in 1.1. Ho= wever, in the present case the definition being augmented from the submod= ule is arguably in a different module. > > =20 > > Lada > > =E2=80=98 > > Thanks, > > William > > _______________________________________________ > 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 > > From nobody Wed Aug 9 08:00:59 2017 Return-Path: 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 B67851323AC for ; Wed, 9 Aug 2017 08:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 wBYIDUTahuND for ; Wed, 9 Aug 2017 08:00:54 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 DFAD41323A9 for ; Wed, 9 Aug 2017 08:00:53 -0700 (PDT) Received: from birdie4305 (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id A10966243C for ; Wed, 9 Aug 2017 17:00:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1502290850; bh=tkPHPOQEn0jRHV+vAyb+/UOzoclp+VoSwm9M7enPaeM=; h=From:To:Date; b=ZQ2N6Fgh0ZaZoft26r6LH9WR/+grZ4Cezd8ZnyBU18rk1tlBY/ZLhvnpk+YWqAacF 4M++jsN3lyESb+XT89Xb92vyknbcxaFpNxJ0K2W6a+/p99bXWApbOqIycy7HLYPBum ZckpFhkJT+kVeMbQlpvW/df3I5H3kn3TKvGlEv6o= Message-ID: <1502290869.16638.15.camel@nic.cz> From: Ladislav Lhotka To: netmod@ietf.org Date: Wed, 09 Aug 2017 17:01:09 +0200 In-Reply-To: References: <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com> <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 15:00:58 -0000 Vladimir Vassilev píše v St 09. 08. 2017 v 16:20 +0200: > 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. I agree. I have seen quite a few bugs (both in my and somebody else's code) directly caused by submodules, e.g. in definition lookup. You are right that in YANG 1.0 the "include" logic was really horrible but still we may be better off with no submodules at all. I remember that in early stages of YANG there was some irrational fear of introducing too many namespaces, and submodules may be a consequence of it. As you write, submodules provide no benefits whatsoever in terms of modularity, but the overhead in terms of metadata, IANA registration etc. is pretty much the same as for modules. Lada > > 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:vladimir@transpacket.com] > > *Sent:* 07 August 2017 20:31 > > *To:* Ivory, William > > *Cc:* '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 > > > > *Cc:* 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.h > > tml > > > ail-2Darchive_web_netmod_current_msg15418.html&d=DwMFaQ&c=LFYZ- > > o9_HUMeMTSQicvjIg&r=FmJP9CH54z5mG3DFGBdc_9q1TLpYQ31-TQ- > > 26_Qa9vw&m=YC4w6Zi9KhBp0MnnvA42_qdR2aM3uOFWpZYtgF122Ec&s=OxxQRDucETBaDPn4KGN > > WcLlu4e8AMSfuyJJjrklp3R0&e=> > > > > ‘> On 01 Mar 2016, at 10:38, Anton Tkáčik > pantheon.tech> wrote: > > > > > > > > > > Hi, > > > > > Noticed other issue with example set, > > > > > Inhttps://github.com/mbj4668/pyang/issues/194 > > > 4668_pyang_issues_194&d=DwMFaQ&c=LFYZ- > > o9_HUMeMTSQicvjIg&r=FmJP9CH54z5mG3DFGBdc_9q1TLpYQ31-TQ- > > 26_Qa9vw&m=YC4w6Zi9KhBp0MnnvA42_qdR2aM3uOFWpZYtgF122Ec&s=bkakKJEZzCBq3BkP5Nz > > W-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 > > https://www.ietf.org/mailman/listinfo/netmod > > > ailman_listinfo_netmod&d=DwMFaQ&c=LFYZ- > > o9_HUMeMTSQicvjIg&r=FmJP9CH54z5mG3DFGBdc_9q1TLpYQ31-TQ- > > 26_Qa9vw&m=YC4w6Zi9KhBp0MnnvA42_qdR2aM3uOFWpZYtgF122Ec&s=x7sK1jWYtSsQJr8r6G7 > > FjWR5gAoMtgv6zRwxT4bzMGQ&e=> > > > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > an_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 -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Aug 9 08:13:20 2017 Return-Path: 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 3EF651323B2 for ; Wed, 9 Aug 2017 08:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 uj7M95o1zf4c for ; Wed, 9 Aug 2017 08:13:16 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6F051323AE for ; Wed, 9 Aug 2017 08:13:15 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id AAFEEF6F for ; Wed, 9 Aug 2017 17:13:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 6yl2uwRggY6K for ; Wed, 9 Aug 2017 17:13:13 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 9 Aug 2017 17:13:14 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C446200B8 for ; Wed, 9 Aug 2017 17:13:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nx02KB2VrDtc; Wed, 9 Aug 2017 17:13:14 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3BDD1200BA; Wed, 9 Aug 2017 17:13:14 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F3147400EA3B; Wed, 9 Aug 2017 17:13:12 +0200 (CEST) Date: Wed, 9 Aug 2017 17:13:12 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20170809151312.GC42207@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: netmod@ietf.org References: <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com> <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com> <1502290869.16638.15.camel@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1502290869.16638.15.camel@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 15:13:18 -0000 On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka wrote: > > I remember that in early stages of YANG there was some irrational > fear of introducing too many namespaces, and submodules may be a > consequence of it. As you write, submodules provide no benefits > whatsoever in terms of modularity, but the overhead in terms of > metadata, IANA registration etc. is pretty much the same as for > modules. In case YANG 2.0 is ever done, I suggest someone files a proposal to remove submodules if the cost/benefit ratio is at odds. There is nothing wrong with removing stuff that has been found problematic. The motivation for submodules was that organizations maintaining large modules with multiple people can do so without having to mess around with tools like m4 scripts to produce a single module from 'snippets' and to avoid integration surprises. But perhaps using m4 scripts and decent version control systems (that can integrate and compile on checkin) is indeed cheaper than having submodules part of the YANG language itself. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Aug 9 09:20:35 2017 Return-Path: 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 1D3BC132419 for ; Wed, 9 Aug 2017 09:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.64 X-Spam-Level: X-Spam-Status: No, score=-1.64 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com 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 1URqMdRzEpkL for ; Wed, 9 Aug 2017 09:20:30 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E9CF13240E for ; Wed, 9 Aug 2017 09:20:30 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id 33so25811273wrz.4 for ; Wed, 09 Aug 2017 09:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p8XjUdv+pwC1i/yA/Te8b6D5mlpadt+fQVH0DeOX8FU=; b=QSaZdyCNExelckgC0DRziwkly3jS87EC/Qbk9YpFlCerWJO1sTeJr/rOen56itFDiY Wg793LktdUkfSijPsRYtVeSBxdtUAJsgnmEqIoSoocKFvwk49OKKB1x+dsMMLdlEhupL JNfdF7q7BJRbz8lOrpS+nWzKGmJtx1ubpEbsub5ST8SJzeUqQIlHDE6jOQv824D0X2aS 9Nhtmj30XLpZ8vrHsk2jcY+JDKXl6lmxqV+tPmUmZybKdWMrAkcuJqXxJ1J2I71EiDE0 +WdiXpzxsKrP3U8XMUtxdKYD7LamHoFRcQ+v9pSuI5BuiXa8FcJAYyI7av//TzBQp3ey VjzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=p8XjUdv+pwC1i/yA/Te8b6D5mlpadt+fQVH0DeOX8FU=; b=s1BlZGCcTCi8uzoJFy6xk3V+ij/s7P+P8LpFKGAeRiW6EhIAB48JGLEI5ljzdoW+II y6qUWqL+l5aGL4AbHqqEUXqGKB7p9shP2TSlxyoWADmes6dSmUewLsxH6eAJV/Dantih hxkMVDmJKFL0YImPsDKLz9laQPCQXQAru8GjWUVXHeFmTNhlnqnEAHt7+x3+FldM0Lh/ loMHycymibR7u979RmjUEjCpfmUkP6D6t3O1uBTzxN5jCeJ8f3LQ1PUN2Xz/qYLETDAM kvfkmpvzIpEbS9HAffqUv3XSdrYltY7e6lAUq2GapGq74E87NIKAfCtz/7XWKfyeFPSA 0Tqg== X-Gm-Message-State: AHYfb5hp+CIf4ZRP4GyqdN4MF+hfVfJLB65bqGAg1Yr/k2az1e1V5Tof 9PmGMbZNgXiVFfKjpDRTUyyFgzd4sdZq X-Received: by 10.223.145.162 with SMTP id 31mr6789598wri.171.1502295628761; Wed, 09 Aug 2017 09:20:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.182.160 with HTTP; Wed, 9 Aug 2017 09:20:27 -0700 (PDT) In-Reply-To: References: <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com> <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com> From: Andy Bierman Date: Wed, 9 Aug 2017 09:20:27 -0700 Message-ID: To: Vladimir Vassilev Cc: "Ivory, William" , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0df1404ce5020556547587" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 16:20:34 -0000 --94eb2c0df1404ce5020556547587 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Aug 9, 2017 at 7:20 AM, Vladimir Vassilev 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=E2=80=99d like to be able to break this down into multiple = daemons >> each dealing with a subset of the YANG. However, we don=E2=80=99t 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=E2=80=99t call = it drastic >> =E2=80=93 it is one YANG file we are talking about breaking up into part= s. >> >> 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 lack= s > the key property of a module at the YANG level - modularity. For submodul= es > 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 wi= th > 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 compile= d. > > 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:vladimir@transpacket.com] >> *Sent:* 07 August 2017 20:31 >> *To:* Ivory, William >> *Cc:* '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 fr= om >> 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 noth= ing >> that can be done with the help of submodules that can not be done withou= t >> them. >> >> For the sake of the argument can you provide a synthesized description o= f >> the problem that lead you to a drastic solution like "we=E2=80=99ll 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 =E2=80=93 we=E2=80=99ll 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 >> >> *Cc:* 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=E2=80=99re trying to solve a modularity problem with a YANG m= odule >> 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=E2=80=99ve found a couple of >> threads online with comments suggesting it=E2=80=99s only allowe= d in >> YANG 1.1? Would appreciate clarification. >> >> RFC 6020 section 7.15 suggests it is allowed: >> >> =E2=80=98 >> >> 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. >> >> =E2=80=98 >> >> Versus online comments >> here:https://www.ietf.org/mail-archive/web/netmod/current/ >> msg15418.html >> > ietf.org_mail-2Darchive_web_netmod_current_msg15418.html& >> d=3DDwMFaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DFmJP9CH54z5mG >> 3DFGBdc_9q1TLpYQ31-TQ-26_Qa9vw&m=3DYC4w6Zi9KhBp0MnnvA42_q >> dR2aM3uOFWpZYtgF122Ec&s=3DOxxQRDucETBaDPn4KGNWcLlu4e8AMSfuyJJjrklp3R0&e= =3D> >> >> =E2=80=98> On 01 Mar 2016, at 10:38, Anton Tk=C3=A1=C4=8Dik > pantheon.tech> wrote: >> >> > >> >> > Hi, >> >> > Noticed other issue with example set, >> >> > Inhttps://github.com/mbj4668/pyang/issues/194 >> > github.com_mbj4668_pyang_issues_194&d=3DDwMFaQ&c=3DLFYZ-o9_HUMeM >> TSQicvjIg&r=3DFmJP9CH54z5mG3DFGBdc_9q1TLpYQ31-TQ-26_Qa9vw&m=3DYC >> 4w6Zi9KhBp0MnnvA42_qdR2aM3uOFWpZYtgF122Ec&s=3DbkakKJEZzCBq3BkP >> 5NzW-wDX6KOZHpOnT0u-ySg8rS0&e=3D> Lada stated that in YANG 1.0 submodul= e >> 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 >> >> =E2=80=98 >> >> Thanks, >> >> William >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > ietf.org_mailman_listinfo_netmod&d=3DDwMFaQ&c=3DLFYZ-o9_ >> HUMeMTSQicvjIg&r=3DFmJP9CH54z5mG3DFGBdc_9q1TLpYQ31-TQ-26_ >> Qa9vw&m=3DYC4w6Zi9KhBp0MnnvA42_qdR2aM3uOFWpZYtgF122Ec&s=3Dx7sK1j >> WYtSsQJr8r6G7FjWR5gAoMtgv6zRwxT4bzMGQ&e=3D> >> >> >> >> >> _______________________________________________ >> >> netmod mailing list >> >> netmod@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netmod >> > ietf.org_mailman_listinfo_netmod&d=3DDwMFaQ&c=3DLFYZ-o9_ >> HUMeMTSQicvjIg&r=3DFmJP9CH54z5mG3DFGBdc_9q1TLpYQ31-TQ-26_ >> Qa9vw&m=3DM7t8vTUb71XRWW7ZfSHTMlFEaAhzOdmQuBmw2ah-uGc&s=3DNFJL1R >> jYNxNMcnPhhm--ECwdEdyUXHGEVEq4fsjzruk&e=3D> >> >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --94eb2c0df1404ce5020556547587 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Aug 9, 2017 at 7:20 AM, Vladimir Vassilev <= ;vladimir@tra= nspacket.com> 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.=C2= =A0 Currently they are bundled together, so having a single YANG file is ok= .=C2=A0 In future we=E2=80=99d like to be able to break this down into mult= iple daemons each dealing with a subset of the YANG.=C2=A0 However, we don= =E2=80=99t wish to change the namespace of the YANG as that would not be ba= ckwards compatible.=C2=A0 So, submodules looked to be a good way to do this= .=C2=A0 I wouldn=E2=80=99t call it drastic =E2=80=93 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 usin= g submodules instead of modules is when they are limited to single namespac= e and need a workaround solution like in your case.
I was hoping your problem could be something that can convince me that subm= odules 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 implement= ation and support effort they require for something that is used very rarel= y. A completely separate source file quantum for YANG that lacks the key pr= operty of a module at the YANG level - modularity. For submodules are both = non-reusable and interdependent. Very few organizations publish submodule b= ased designs probably for the same reasons I avoid them. Submodules are gre= at if you want to publish non-reusable YANG though.

IETF went once for design with submodules in ietf-snmp.yang. Even in that c= ase (well organized YANG module) I would have preferred a single file with = some of the exotic features modularized in separate modules instead. Dynami= c compilers still need to go through all submodules even in device that sup= ports only the base SNMP functionality before features can be evaluated. As= a result instead of the 10KB of actually implemented schema 60KB of additi= onal YANG has to be retrieved in the worst case and compiled.

Both submodules and alternative datastores are examples of how complexity i= s 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 t= he module concept. There is something that is not right with that. Worse th= an 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 fro= m 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 s= ummary about why they are quite rigid and not really modular at all.
<= div>
They work even worse when include-without-revision is us= ed.
In this most common case, the actual submodule revisions used=
are very implementation-dependent.=C2=A0 There is no way to cros= s-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 und= o it when they figure out
that a monolithic YANG-ball is not as w= orkable as a module-set.

=C2=A0
Vladimir



Andy
=C2=A0
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' <netm= od@ietf.org>
*Subject:* Re: [netmod] Query about augmenting module from submodule in YAN= G 1.0

Hello,

IMO "submodule"s=C2=A0 are a striking example of redundant comple= xity in an otherwise very close to perfection YANG (regardless if it is YAN= G 1.0 or 1.1).

Modules and submodules have been around for a while however the ratio of th= e currently published modules compared with the submodules is about 40 modu= les to 1 submodule (if one ignores all the modules and submodules from=C2= =A0 particular networking hardware manufacturer that is particularly keen o= n using submodules). As a far but still relevant analogy Java has a limitat= ion of 1 file per class and this atomicity has proven to be an advantage es= pecially 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 t= he problem that lead you to a drastic solution like "we=E2=80=99ll loo= k at trying to put everything into submodules in this case."?

Vladimir

On 08/07/2017 04:37 PM, Ivory, William wrote:

=C2=A0 =C2=A0 Hi Jan,

=C2=A0 =C2=A0 Thanks =E2=80=93 we=E2=80=99ll look at trying to put everythi= ng into submodules in
=C2=A0 =C2=A0 this case.

=C2=A0 =C2=A0 Regards,

=C2=A0 =C2=A0 William

=C2=A0 =C2=A0 *From:*Jan Lindblad [mailto:janl@tail-f.com]
=C2=A0 =C2=A0 *Sent:* 07 August 2017 14:28
=C2=A0 =C2=A0 *To:* Ivory, William <wi274w@intl.att.com>
=C2=A0 =C2=A0 <mailto:wi274w@intl.att.com>
=C2=A0 =C2=A0 *Cc:* ne= tmod@ietf.org <mailto:netmod@ietf.org>
=C2=A0 =C2=A0 *Subject:* Re: [netmod] Query about augmenting module from =C2=A0 =C2=A0 submodule in YANG 1.0

=C2=A0 =C2=A0 The submodule concept in YANG 1.0 is, well, not very useful, = and
=C2=A0 =C2=A0 even less intuitive. That's why it saw major rework in YA= NG 1.1.

=C2=A0 =C2=A0 A YANG 1.0 submodule cannot reference the module that include= s it,
=C2=A0 =C2=A0 directly or indirectly. This is because in YANG 1.0 the symbo= ls in
=C2=A0 =C2=A0 other submodules of the same namespace are invisible to the =C2=A0 =C2=A0 submodule unless they are explicitly included. And parent mod= ules
=C2=A0 =C2=A0 can't be included by a submodule because that would lead = to an
=C2=A0 =C2=A0 inclusion loop. It is possible to reference (augment, etc) ot= her
=C2=A0 =C2=A0 sibling submodules, though. So if you split your modules clev= erly,
=C2=A0 =C2=A0 you might be able to resolve your referential constraints any= way.

=C2=A0 =C2=A0 If you really want to take the submodule path, I'd recomm= end
=C2=A0 =C2=A0 moving to YANG 1.1. In the interest of preserving the hair to= ne of
=C2=A0 =C2=A0 IT-architects.

=C2=A0 =C2=A0 /jan

=C2=A0 =C2=A0 =C2=A0 =C2=A0 We=E2=80=99re trying to solve a modularity prob= lem with a YANG module
=C2=A0 =C2=A0 =C2=A0 =C2=A0 by splitting it into submodules and augmenting = the parent
=C2=A0 =C2=A0 =C2=A0 =C2=A0 module from each submodule.=C2=A0 However, desp= ite the wording
=C2=A0 =C2=A0 =C2=A0 =C2=A0 below in YANG 1.0 section 7.15, we=E2=80=99ve f= ound a couple of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 threads online with comments suggesting it=E2= =80=99s only allowed in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 YANG 1.1?=C2=A0 Would appreciate clarification.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 6020 section 7.15 suggests it is allowed:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=98

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The "augment" statement = allows a module or submodule to add
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0schema tree defined in an external= module, or the current
=C2=A0 =C2=A0 =C2=A0 =C2=A0 module and

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0its submodules, and to add to the = nodes from a grouping in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a "uses"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0statement.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=98

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Versus online comments
=C2=A0 =C2=A0 =C2=A0 =C2=A0 here:h= ttps://www.ietf.org/mail-archive/web/netmod/current/msg15418.html=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://urldefense.proofpoint.com/v2= /url?u=3Dhttps-3A__www.ietf.org_mail-2Darchive_web_netmod_current= _msg15418.html&d=3DDwMFaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&= r=3DFmJP9CH54z5mG3DFGBdc_9q1TLpYQ31-TQ-26_Qa9vw&m=3DYC4w6Zi9K= hBp0MnnvA42_qdR2aM3uOFWpZYtgF122Ec&s=3DOxxQRDucETBaDPn4KGNWcL= lu4e8AMSfuyJJjrklp3R0&e=3D>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=98> On 01 Mar 2016, at 10:38, Anton T= k=C3=A1=C4=8Dik <anton.tkacik at pantheon.tech> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 >

=C2=A0 =C2=A0 =C2=A0 =C2=A0 > Hi,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 > Noticed other issue with example set,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 > Inhttps://github.com/mbj4= 668/pyang/issues/194
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__gi= thub.com_mbj4668_pyang_issues_194&d=3DDwMFaQ&c=3DLFYZ-o9_HUMeM= TSQicvjIg&r=3DFmJP9CH54z5mG3DFGBdc_9q1TLpYQ31-TQ-26_Qa9vw&= ;m=3DYC4w6Zi9KhBp0MnnvA42_qdR2aM3uOFWpZYtgF122Ec&s=3DbkakKJEZ= zCBq3BkP5NzW-wDX6KOZHpOnT0u-ySg8rS0&e=3D>=C2=A0 Lada s= tated that in YANG 1.0 submodule can not augment nodes

=C2=A0 =C2=A0 =C2=A0 =C2=A0 > defined in parent model.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 >

=C2=A0 =C2=A0 =C2=A0 =C2=A0 > Is that correct that submodule can not aug= ment definition defined in parent module?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 This isn't possible in YANG 1.0 but will be= possible in 1.1. However, in the present case the definition being augment= ed from the submodule is arguably in a different module.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Lada

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=98

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 William

=C2=A0 =C2=A0 =C2=A0 =C2=A0 __________________________________________= _____
=C2=A0 =C2=A0 =C2=A0 =C2=A0 netmod mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 netmod@ietf.org <mailto:netmod@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman= /listinfo/netmod
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_netmod&d=3DDwMFaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DFmJP9CH54z5mG3DFGBdc_9q1TLpYQ31-TQ-26_Qa= 9vw&m=3DYC4w6Zi9KhBp0MnnvA42_qdR2aM3uOFWpZYtgF122Ec&s=3Dx7sK1j= WYtSsQJr8r6G7FjWR5gAoMtgv6zRwxT4bzMGQ&e=3D>




=C2=A0 =C2=A0 _______________________________________________

=C2=A0 =C2=A0 netmod mailing list

=C2=A0 =C2=A0 netmod@i= etf.org <mailto:netmod@ietf.org>

=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/netmod
=C2=A0 =C2=A0 <http= s://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m= ailman_listinfo_netmod&d=3DDwMFaQ&c=3DLFYZ-o9_HUMeMTSQicv= jIg&r=3DFmJP9CH54z5mG3DFGBdc_9q1TLpYQ31-TQ-26_Qa9vw&m=3DM= 7t8vTUb71XRWW7ZfSHTMlFEaAhzOdmQuBmw2ah-uGc&s=3DNFJL1RjYNxNMcn= Phhm--ECwdEdyUXHGEVEq4fsjzruk&e=3D>


_______________________________________________
netmod mailing list
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod

--94eb2c0df1404ce5020556547587-- From nobody Wed Aug 9 09:53:54 2017 Return-Path: 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 0EEB213242B for ; Wed, 9 Aug 2017 09:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 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 J5uoUFRfC2zV for ; Wed, 9 Aug 2017 09:53:51 -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 1FFCE1321B6 for ; Wed, 9 Aug 2017 09:53:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5970; q=dns/txt; s=iport; t=1502297630; x=1503507230; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=SjmPomQ8Jt1vufOKGADaSoCuDBe2i01JSCOVKHlyIC8=; b=klIk81LH34nGV/UVG1ScUP8ogxS7/mIgFmyoAV0smCXX+mvMK5YpIJ+r r4qMYSEByfXLx8jjAxVu0CrjaVxUBtOkYyyDXwMNkplskr4stgpJ85Vj4 nG3J3xRddRIfyzKxyNcHeJwNBmFHu5jVYqwP7PmBuUbXSk9cFZJvQ3Zz3 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5AAAVPYtZ/4MNJK1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1qBeAeOCJAFgW6WFYIShUcCGoRkPxgBAgEBAQEBAQFrKIUYAQEBAQI?= =?us-ascii?q?BHQYRPhMEAgEIFQECAgImAgICMBUQAgQBEoonCK4MgiaLSQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2BC4IdggKBTIIOgnyIBjCCMQWgFwKLI4kRklGWCgEfOIEKdxV?= =?us-ascii?q?JEgGHB3aHUAaBLAGBDgEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,348,1498521600"; d="scan'208";a="278770943" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Aug 2017 16:53:49 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v79Gronx029355 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Aug 2017 16:53:50 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 9 Aug 2017 11:53:49 -0500 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1210.000; Wed, 9 Aug 2017 11:53:49 -0500 From: "Clyde Wildes (cwildes)" To: "t.petch" , Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15 Thread-Index: AQHTALcsnxmaKupZ/kyeF+fon7bzlqJ8BjHYgAA2+gA= Date: Wed, 9 Aug 2017 16:53:49 +0000 Message-ID: <55F0DA02-0E29-46B6-9F4A-B2525EE3F003@cisco.com> References: <91FA5813-8D96-414F-BAC6-BA6C65C5149C@cisco.com> <055c01d31103$28f51200$4001a8c0@gateway.2wire.net> In-Reply-To: <055c01d31103$28f51200$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [128.107.151.9] Content-Type: text/plain; charset="utf-8" Content-ID: <7B1A12BB3EF8C245B5209CE669E63D75@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 16:53:53 -0000 VG9tLA0KDQpUaGUgYWdyZWVtZW50IHdhcyB0aGF0IEkgc2hvdWxkIHVzZSDigJx4eHh44oCdIHVu dGlsIHRoZSB0d28gdW5hcHByb3ZlZCBSRkNzIHRoYXQgdGhlIG1vZGVsIGRlcGVuZHMgb24gYXJl IGFzc2lnbmVkIG51bWJlcnMuDQoNCiAgICAgUkZDIHh4eHg6IEtleXN0b3JlIE1hbmFnZW1lbnQN CiAgICAgUkZDIHh4eHg6IFRyYW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSBDbGllbnQiOw0K DQpJbXBvcnRlZCBhcmU6DQoNCiAgaW1wb3J0IGlldGYtdGxzLWNsaWVudCB7DQogICAgcHJlZml4 IHRsc2M7DQogIH0NCg0KICBpbXBvcnQgaWV0Zi1rZXlzdG9yZSB7DQogICAgcHJlZml4IGtzOw0K ICB9DQoNCg0KSGF2ZSBudW1iZXJzIGJlZW4gYXNzaWduZWQ/DQoNClRoYW5rcywNCg0KQ2x5ZGUN Cg0KT24gOC85LzE3LCA0OjMyIEFNLCAidC5wZXRjaCIgPGlldGZjQGJ0Y29ubmVjdC5jb20+IHdy b3RlOg0KDQogICAgQ2x5ZGUNCiAgICANCiAgICBZb3UgdXNlIHh4eHggYXMgYSBwbGFjZWhvbGRl ciBmb3IgdGhyZWUgZGlmZmVyZW50IFJGQyBhbmQgdHdvIG9mIHRoZXNlDQogICAgZG8gbm90IGFw cGVhciBBRkFJQ1QgaW4gdGhlIGxpc3Qgb2YgUmVmZXJlbmNlcy4NCiAgICANCiAgICBUaGlzIG1p Z2h0IGJlIGEgY2hhbGxlbmdlIGZvciB0aGUgUkZDIEVkaXRvci4NCiAgICANCiAgICBUb20gUGV0 Y2gNCiAgICANCiAgICANCiAgICAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQogICAgRnJv bTogIkNseWRlIFdpbGRlcyAoY3dpbGRlcykiIDxjd2lsZGVzQGNpc2NvLmNvbT4NCiAgICBTZW50 OiBXZWRuZXNkYXksIEp1bHkgMTksIDIwMTcgNjo0OCBQTQ0KICAgIA0KICAgIA0KICAgID4gSGkg QWxleCwNCiAgICA+DQogICAgPiBBbnN3ZXJzIGlubGluZSBhcyBbY2x5ZGVd4oCmDQogICAgPg0K ICAgID4gT24gNy8xNy8xNywgNDoyMCBQTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgQWxleCBDYW1w YmVsbCINCiAgICA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIEFsZXguQ2Ft cGJlbGxAQXZpYXRuZXQuY29tPiB3cm90ZToNCiAgICA+DQogICAgPiAgICAgSSBhbSBjb25zaWRl cmluZyB0byBpbXBsZW1lbnQgdGhlIGRhdGEgbW9kZWwgaW4gdGhpcyBkcmFmdC4NCiAgICAoZGVw ZW5kZW50IG9uIGJ1c2luZXNzIHByaW9yaXRpZXMgb2YgY291cnNlKQ0KICAgID4gICAgIEkgaGF2 ZSByZXZpZXdlZCB0aGlzIGRyYWZ0IGFuZCBmb3VuZCB0aGUgZm9sbG93aW5nIGlzc3Vlcy4NCiAg ICA+DQogICAgPiAgICAgKiBJIHNlZSBwYXR0ZXJuLW1hdGNoIGlzIHNwZWNpZmllZCB0byB1c2Ug UE9TSVggMTAwMy4yIHJlZ3VsYXINCiAgICBleHByZXNzaW9ucy4gVGhpcyBpcyBwcmVzdW1hYmx5 IGZvciBjb21wYXRpYmlsaXR5IHdpdGggZXhpc3RpbmcNCiAgICBpbXBsZW1lbnRhdGlvbnM7IGhv d2V2ZXIgaXQgaXMgaW5jb25zaXN0ZW50IHdpdGggbW9zdCBvZiBZQU5HICh3aGljaCBpcw0KICAg IHNwZWNpZmllZCB0byB1c2UgWFBhdGggcmVndWxhciBleHByZXNzaW9ucykgLSB1bmxlc3MgdGhl c2UgYXJlIHRoZSBzYW1lLg0KICAgID4NCiAgICA+IFtjbHlkZV0gSSBiZWxpZXZlIHRoYXQgbXkg YW5zd2VyIGluIHRoZSBvdGhlciB0aHJlYWQgZXhwbGFpbnMgd2h5IHdlDQogICAgdXNlZCBQb3Np eCAxMDAzLjIg4oCTIGl0IGlzIGNvbW1vbmx5IHVzZWQuDQogICAgPg0KICAgID4gICAgICogcGF0 dGVybi1tYXRjaCBpcyBpbnNpZGUgdGhlIGZhY2lsaXR5LWZpbHRlciBjb250YWluZXI7IGNvbW1v bg0KICAgIHNlbnNlIHNheXMgdGhpcyBpcyB3cm9uZyBhcyBwYXR0ZXJuLW1hdGNoIGhhcyBub3Ro aW5nIHRvIGRvIHdpdGgNCiAgICBmYWNpbGl0aWVzLg0KICAgID4NCiAgICA+IFtjbHlkZV0gSSB3 aWxsIG1vdmUgcGF0dGVybi1tYXRjaCB1cCBvbmUgbGV2ZWwgaW4gdGhlIG5leHQgdmVyc2lvbiBv Zg0KICAgIHRoZSBkcmFmdC4gVGhhbmtzIGZvciBjYXRjaGluZyB0aGlzIQ0KICAgID4NCiAgICA+ ICAgICAqIFRoZSBhZHZhbmNlZC1jb21wYXJlIGNvbnRhaW5lciBncm91cHMgdG9nZXRoZXIgdHdv IG5vZGVzIHRoYXQNCiAgICBzaGFyZSBhIGNvbW1vbiAid2hlbiIgYW5kICJpZi1mZWF0dXJlIiBz dGF0ZW1lbnQsIGJ1dCBkb24ndCBzZWVtIHRvIGhhdmUNCiAgICBhbnkgc2VtYW50aWMgcmVsYXRp b24gdG8gZWFjaCBvdGhlci4gQXJlIHRoZXJlIGdlbmVyYWwgZ3VpZGVsaW5lcyBvbg0KICAgIHdo ZW4gdG8gdXNlIGEgY29udGFpbmVyPw0KICAgID4NCiAgICA+IFtjbHlkZV0gVGhlIGNvbmZ1c2lv biBtYXkgY29tZSBhcyBhIHJlc3VsdCBvZiB0aGUgd2hlbiBjbGF1c2UNCiAgICBhcHBlYXJpbmcg YmVmb3JlIHRoZSBpZi1mZWF0dXJlIGNsYXVzZSB3aGljaCBpcyBzZXQgYnkgdGhlIElFVEYNCiAg ICBzdGF0ZW1lbnQgb3JkZXIgcmVjb21tZW5kYXRpb24uDQogICAgPg0KICAgID4gVGhlIHdoZW4g Y29uc3RydWN0IHdhcyBzdWdnZXN0ZWQgYnkgTWFydGluIEJqw7Zya2x1bmQgYXMgYSB3YXkgb2YN CiAgICBzb2x2aW5nIHRoZSBjYXNlIHRoYXQgYWR2YW5jZWQtY29tcGFyZSBkb2VzIG5vdCBhcHBs eSBmb3IgdGhlIOKAmGFsbOKAmSBhbmQNCiAgICDigJhub25l4oCZIGNhc2UuDQogICAgPg0KICAg ID4gVGhlIGlmLWZlYXR1cmUgYXBwbGllcyB0byB0aGUgZW50aXJlIGNvbnRhaW5lciDigJMgaXQg aXMgZWl0aGVyDQogICAgc3VwcG9ydGVkIG9yIG5vdC4NCiAgICA+DQogICAgPiAgICAgKiBUaGUg YWR2YW5jZWQtY29tcGFyZSBjb250YWluZXIgaGFzIGEgZGVzY3JpcHRpb24gc3RhcnRpbmcgd2l0 aA0KICAgICJUaGlzIGxlYWYgLi4uIiBldmVuIHRob3VnaCBpdCBpcyBub3QgYSBsZWFmLg0KICAg ID4NCiAgICA+IFtjbHlkZV0gVGhpcyB3aWxsIGJlIGZpeGVkIGluIHRoZSBuZXh0IGRyYWZ0Lg0K ICAgID4NCiAgICA+ICAgICAqIFRoZSBleGFtcGxlcyBhcmUgbWlzc2luZyA8ZmFjaWxpdHktZmls dGVyPiBub2Rlcy4NCiAgICA+DQogICAgPiBbY2x5ZGVdIFRoaXMgd2lsbCBiZSBmaXhlZCBpbiB0 aGUgbmV4dCBkcmFmdC4NCiAgICA+DQogICAgPiAgICAgKiBQZXJoYXBzIHRoZXJlIHNob3VsZCBi ZSBtb3JlIGNvbnNpc3RlbnQgdGVybWlub2xvZ3kgZm9yDQogICAgcmVjZWl2ZXJzIG9mIHN5c2xv ZyBtZXNzYWdlczsgYm90aCAiY29sbGVjdG9ycyIgYW5kICJhY3Rpb25zIiBhcmUgdXNlZA0KICAg IGluIHRoZSBkcmFmdC4gUkZDIDU0MjQgdXNlcyAiY29sbGVjdG9yIiBmb3IgdGhlIHVsdGltYXRl IHJlY2lwaWVudCBvZiBhDQogICAgbG9nIG1lc3NhZ2UgLSB3aGljaCBtaWdodCBub3QgYmUgYXBw bGljYWJsZSwgYmVjYXVzZSB0aGUgc2VuZGluZyBzeXN0ZW0NCiAgICBoYXMgbm8gaWRlYSB3aGV0 aGVyIHRoZSByZWNlaXZpbmcgc3lzdGVtIGlzIGEgY29sbGVjdG9yIG9yIGEgcmVsYXkuDQogICAg Pg0KICAgID4gW2NseWRlXSBUaGUgZGVmaW5pdGlvbiBvZiDigJxjb2xsZWN0b3LigJ0gaW4gUkZD IDU0MjQgaXM6IEEgImNvbGxlY3RvciINCiAgICBnYXRoZXJzIHN5c2xvZyBjb250ZW50IGZvciBm dXJ0aGVyIGFuYWx5c2lzLg0KICAgID4NCiAgICA+IGFjdGlvbnMgcmVsYXRlIHRvIHRoZSDigJxm dXJ0aGVyIGFuYWx5c2lz4oCdIHRha2VuIGJ5IHRoZSDigJxjb2xsZWN0b3LigJ0uDQogICAgPg0K ICAgID4g4oCcQ29sbGVjdG9yc+KAnSBhcHBlYXJzIGluIHRoZSBtb2RlbCB1bmRlciB0aGUgcmVt b3RlIGFjdGlvbiBhbmQgSQ0KICAgIGJlbGlldmUgdGhlIHVzYWdlIGlzIGNvcnJlY3Q6DQogICAg PiAgICAgICBjb250YWluZXIgcmVtb3RlIHsNCiAgICA+ICAgICAgICAgaWYtZmVhdHVyZSByZW1v dGUtYWN0aW9uOw0KICAgID4gICAgICAgICBkZXNjcmlwdGlvbg0KICAgID4gICAgICAgICAgICJU aGlzIGNvbnRhaW5lciBkZXNjcmliZXMgdGhlIGNvbmZpZ3VyYXRpb24gcGFyYW1ldGVycyBmb3IN CiAgICA+ICAgICAgICAgICAgZm9yd2FyZGluZyBzeXNsb2cgbWVzc2FnZXMgdG8gcmVtb3RlIHJl bGF5cyBvcg0KICAgIGNvbGxlY3RvcnMuIjsNCiAgICA+DQogICAgPiBJIHdpbGwgcmV2aXNlIHRo ZSBkZXNjcmlwdGlvbiBvZiB0aGVzZSB0ZXJtcyBpbiB0aGUgbmV4dCBkcmFmdC4NCiAgICA+DQog ICAgPiBUaGFua3MsDQogICAgPg0KICAgID4gQ2x5ZGUNCiAgICA+DQogICAgPiAgICAgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gICAgIEZyb206IG5ldG1v ZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBLZW50IFdhdHNlbg0KICAg IDxrd2F0c2VuQGp1bmlwZXIubmV0Pg0KICAgID4gICAgIFNlbnQ6IFNhdHVyZGF5LCA4IEp1bHkg MjAxNyA2OjM0IGEubS4NCiAgICANCiAgICANCg0K From nobody Wed Aug 9 10:38:08 2017 Return-Path: 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 D9839132350 for ; Wed, 9 Aug 2017 10:38:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.011 X-Spam-Level: X-Spam-Status: No, score=-3.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 cEjPh3ArJoqe for ; Wed, 9 Aug 2017 10:38:04 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0110.outbound.protection.outlook.com [104.47.40.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9853E1321C7 for ; Wed, 9 Aug 2017 10:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=b8nwGFNb9Ll68JRG6QALzCgaWjcXqE8GJN36nXKhBXY=; b=SUZexTpfwjF2hSqbe+iW/4GPJCjm9efiDFfjfY1eqHEiu5od/ePUojlwfCipDNlGaifpeO5zUyQGsGZGpRQlFZbto37RR0BFflFzATTT6Q/VpErLzIInIP2AruxHYCZwc6d0xVOEV3kOq8A6QcGzeaRNiGAjyJdJTJR1ThR5tLo= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1380.namprd05.prod.outlook.com (10.160.117.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.9; Wed, 9 Aug 2017 17:38:02 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1341.010; Wed, 9 Aug 2017 17:38:02 +0000 From: Kent Watsen To: "Clyde Wildes (cwildes)" , t.petch , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15 Thread-Index: AQHTALcsnxmaKupZ/kyeF+fon7bzlqJ8BjLwgABYhID//8lLgA== Date: Wed, 9 Aug 2017 17:38:02 +0000 Message-ID: <3B97E7D1-64CE-4BD4-9A56-D5E844D7448E@juniper.net> References: <91FA5813-8D96-414F-BAC6-BA6C65C5149C@cisco.com> <055c01d31103$28f51200$4001a8c0@gateway.2wire.net> <55F0DA02-0E29-46B6-9F4A-B2525EE3F003@cisco.com> In-Reply-To: <55F0DA02-0E29-46B6-9F4A-B2525EE3F003@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1380; 6:tXHngIGYtf4dftonq87AASjwutDMt9FPPlU3ho2gE11kr7JyNa7km2ibF9ZL07R1+/buAdbEuS5CN3U2MR0verBVTD+Q4vQCSbdm5jLoAsthnOk5+8IVLkZ9XATPPDlS5U8tq6ny+L0qvfUTIl2wQKmMDXX1m8jY1gCUzsn6ZslK0ISD19hblBdyB/M/BMm8sZz8x3LZzQZaJ9rnDtSC8bDfG6I5z2Ftz/MW+1Csmuhuw17xLaytg41I5FYV+OLXOW8LPVTDn8eDb8/tNRaXMT5bpZWnNiM2NoRb5kSTnRiVuJ3p7W706oyB8lNx/a+mO9dtpw7aFAsu0iYgNZkzqQ==; 5:IU/7IKh9STRLd1Mk2QO1zDgfY3zAVy/+BAL/WLXIQimEmID7kIZluC6XkjUBQ4AYMvuxaf1TUXbrqzma41R1yhG8ivrweMqy+TuzZub1skLa7D3PhrLw4XhqMbPoFMXvRLcmo5XTq7E8jyvGkRxpbw==; 24:SmXZHcnejWd3Zy2GyFmLGi4pArCho0gr0srk5TaWI1dsWiCQ0KkYjzLoiY8POmqktmqP5RE1RzFCoJA+It8OVdJV2/naNQ7WMYaFobnsZqk=; 7:sBj4JfZne4dPLkhEdFfogpLyo+REbIffxrMy2XacrNA9PpzkN3zmOgx6uPNQz2gV4lVgFiByWmqcyQRtZRk+6XjUalmlAf+d2x2Ky7wXDKUdg8l+5CAS6fUaJxAwhTpG/LIs0MtKRP5cMf7Xjn4EJfa9mDZhK/QMF0BMZxN5N2FzNBk+3XIES2VLGJC8llGx6Mu7I+Hv0q7clc7xH+F9CDM+gntQzFClrIkwPlYX2SU= x-ms-office365-filtering-correlation-id: 8ff71c4d-2c86-412a-b6f4-08d4df4d6292 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1380; x-ms-traffictypediagnostic: BN3PR0501MB1380: x-exchange-antispam-report-test: UriScan:(178726229863574)(192374486261705)(138986009662008)(95692535739014)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1380; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1380; x-forefront-prvs: 0394259C80 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39450400003)(39850400002)(39840400002)(39860400002)(39410400002)(39400400002)(13464003)(24454002)(189002)(199003)(377454003)(2950100002)(2906002)(6246003)(33656002)(38730400002)(50986999)(77096006)(105586002)(86362001)(76176999)(106356001)(54356999)(3280700002)(99286003)(6506006)(3660700001)(6436002)(6486002)(14454004)(6512007)(8666007)(101416001)(8676002)(229853002)(53546010)(66066001)(4001350100001)(83716003)(81156014)(8936002)(230783001)(53936002)(97736004)(7736002)(81166006)(82746002)(36756003)(305945005)(102836003)(68736007)(2501003)(189998001)(2900100001)(478600001)(6116002)(3846002)(5660300001)(83506001)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1380; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2017 17:38:02.4090 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1380 Archived-At: Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 17:38:07 -0000 SGkgQ2x5ZGUsDQoNCkluIG15IGRyYWZ0cyB0aGF0IGRlcGVuZCBvbiBtb3JlIHRoYW4gb25lIHdv cmsgaW4gcHJvZ3Jlc3MsIEkgdHlwaWNhbGx5IGFzc2lnbiBlYWNoIG9mIHRoZW0gYSB2YWx1ZSAo ZS5nLiwgWFhYWCwgWVlZWSwgWlpaWikgYW5kIHRoZW4gaGF2ZSBSRkMgRWRpdG9yIGluc3RydWN0 aW9ucyBtYXBwaW5nIGVhY2ggdG8gYSBzcGVjaWZpYyB2YWx1ZS4NCg0KS2VudCAvLyBjb250cmli dXRvcg0KDQotLQ0KDQpUb20sDQoNClRoZSBhZ3JlZW1lbnQgd2FzIHRoYXQgSSBzaG91bGQgdXNl IOKAnHh4eHjigJ0gdW50aWwgdGhlIHR3byB1bmFwcHJvdmVkIFJGQ3MgdGhhdCB0aGUgbW9kZWwg ZGVwZW5kcyBvbiBhcmUgYXNzaWduZWQgbnVtYmVycy4NCg0KICAgICBSRkMgeHh4eDogS2V5c3Rv cmUgTWFuYWdlbWVudA0KICAgICBSRkMgeHh4eDogVHJhbnNwb3J0IExheWVyIFNlY3VyaXR5IChU TFMpIENsaWVudCI7DQoNCkltcG9ydGVkIGFyZToNCg0KICBpbXBvcnQgaWV0Zi10bHMtY2xpZW50 IHsNCiAgICBwcmVmaXggdGxzYzsNCiAgfQ0KDQogIGltcG9ydCBpZXRmLWtleXN0b3JlIHsNCiAg ICBwcmVmaXgga3M7DQogIH0NCg0KDQpIYXZlIG51bWJlcnMgYmVlbiBhc3NpZ25lZD8NCg0KVGhh bmtzLA0KDQpDbHlkZQ0KDQpPbiA4LzkvMTcsIDQ6MzIgQU0sICJ0LnBldGNoIiA8aWV0ZmNAYnRj b25uZWN0LmNvbT4gd3JvdGU6DQoNCiAgICBDbHlkZQ0KICAgIA0KICAgIFlvdSB1c2UgeHh4eCBh cyBhIHBsYWNlaG9sZGVyIGZvciB0aHJlZSBkaWZmZXJlbnQgUkZDIGFuZCB0d28gb2YgdGhlc2UN CiAgICBkbyBub3QgYXBwZWFyIEFGQUlDVCBpbiB0aGUgbGlzdCBvZiBSZWZlcmVuY2VzLg0KICAg IA0KICAgIFRoaXMgbWlnaHQgYmUgYSBjaGFsbGVuZ2UgZm9yIHRoZSBSRkMgRWRpdG9yLg0KICAg IA0KICAgIFRvbSBQZXRjaA0KICAgIA0KICAgIA0KICAgIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0NCiAgICBGcm9tOiAiQ2x5ZGUgV2lsZGVzIChjd2lsZGVzKSIgPGN3aWxkZXNAY2lzY28u Y29tPg0KICAgIFNlbnQ6IFdlZG5lc2RheSwgSnVseSAxOSwgMjAxNyA2OjQ4IFBNDQogICAgDQog ICAgDQogICAgPiBIaSBBbGV4LA0KICAgID4NCiAgICA+IEFuc3dlcnMgaW5saW5lIGFzIFtjbHlk ZV3igKYNCiAgICA+DQogICAgPiBPbiA3LzE3LzE3LCA0OjIwIFBNLCAibmV0bW9kIG9uIGJlaGFs ZiBvZiBBbGV4IENhbXBiZWxsIg0KICAgIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhh bGYgb2YgQWxleC5DYW1wYmVsbEBBdmlhdG5ldC5jb20+IHdyb3RlOg0KICAgID4NCiAgICA+ICAg ICBJIGFtIGNvbnNpZGVyaW5nIHRvIGltcGxlbWVudCB0aGUgZGF0YSBtb2RlbCBpbiB0aGlzIGRy YWZ0Lg0KICAgIChkZXBlbmRlbnQgb24gYnVzaW5lc3MgcHJpb3JpdGllcyBvZiBjb3Vyc2UpDQog ICAgPiAgICAgSSBoYXZlIHJldmlld2VkIHRoaXMgZHJhZnQgYW5kIGZvdW5kIHRoZSBmb2xsb3dp bmcgaXNzdWVzLg0KICAgID4NCiAgICA+ICAgICAqIEkgc2VlIHBhdHRlcm4tbWF0Y2ggaXMgc3Bl Y2lmaWVkIHRvIHVzZSBQT1NJWCAxMDAzLjIgcmVndWxhcg0KICAgIGV4cHJlc3Npb25zLiBUaGlz IGlzIHByZXN1bWFibHkgZm9yIGNvbXBhdGliaWxpdHkgd2l0aCBleGlzdGluZw0KICAgIGltcGxl bWVudGF0aW9uczsgaG93ZXZlciBpdCBpcyBpbmNvbnNpc3RlbnQgd2l0aCBtb3N0IG9mIFlBTkcg KHdoaWNoIGlzDQogICAgc3BlY2lmaWVkIHRvIHVzZSBYUGF0aCByZWd1bGFyIGV4cHJlc3Npb25z KSAtIHVubGVzcyB0aGVzZSBhcmUgdGhlIHNhbWUuDQogICAgPg0KICAgID4gW2NseWRlXSBJIGJl bGlldmUgdGhhdCBteSBhbnN3ZXIgaW4gdGhlIG90aGVyIHRocmVhZCBleHBsYWlucyB3aHkgd2UN CiAgICB1c2VkIFBvc2l4IDEwMDMuMiDigJMgaXQgaXMgY29tbW9ubHkgdXNlZC4NCiAgICA+DQog ICAgPiAgICAgKiBwYXR0ZXJuLW1hdGNoIGlzIGluc2lkZSB0aGUgZmFjaWxpdHktZmlsdGVyIGNv bnRhaW5lcjsgY29tbW9uDQogICAgc2Vuc2Ugc2F5cyB0aGlzIGlzIHdyb25nIGFzIHBhdHRlcm4t bWF0Y2ggaGFzIG5vdGhpbmcgdG8gZG8gd2l0aA0KICAgIGZhY2lsaXRpZXMuDQogICAgPg0KICAg ID4gW2NseWRlXSBJIHdpbGwgbW92ZSBwYXR0ZXJuLW1hdGNoIHVwIG9uZSBsZXZlbCBpbiB0aGUg bmV4dCB2ZXJzaW9uIG9mDQogICAgdGhlIGRyYWZ0LiBUaGFua3MgZm9yIGNhdGNoaW5nIHRoaXMh DQogICAgPg0KICAgID4gICAgICogVGhlIGFkdmFuY2VkLWNvbXBhcmUgY29udGFpbmVyIGdyb3Vw cyB0b2dldGhlciB0d28gbm9kZXMgdGhhdA0KICAgIHNoYXJlIGEgY29tbW9uICJ3aGVuIiBhbmQg ImlmLWZlYXR1cmUiIHN0YXRlbWVudCwgYnV0IGRvbid0IHNlZW0gdG8gaGF2ZQ0KICAgIGFueSBz ZW1hbnRpYyByZWxhdGlvbiB0byBlYWNoIG90aGVyLiBBcmUgdGhlcmUgZ2VuZXJhbCBndWlkZWxp bmVzIG9uDQogICAgd2hlbiB0byB1c2UgYSBjb250YWluZXI/DQogICAgPg0KICAgID4gW2NseWRl XSBUaGUgY29uZnVzaW9uIG1heSBjb21lIGFzIGEgcmVzdWx0IG9mIHRoZSB3aGVuIGNsYXVzZQ0K ICAgIGFwcGVhcmluZyBiZWZvcmUgdGhlIGlmLWZlYXR1cmUgY2xhdXNlIHdoaWNoIGlzIHNldCBi eSB0aGUgSUVURg0KICAgIHN0YXRlbWVudCBvcmRlciByZWNvbW1lbmRhdGlvbi4NCiAgICA+DQog ICAgPiBUaGUgd2hlbiBjb25zdHJ1Y3Qgd2FzIHN1Z2dlc3RlZCBieSBNYXJ0aW4gQmrDtnJrbHVu ZCBhcyBhIHdheSBvZg0KICAgIHNvbHZpbmcgdGhlIGNhc2UgdGhhdCBhZHZhbmNlZC1jb21wYXJl IGRvZXMgbm90IGFwcGx5IGZvciB0aGUg4oCYYWxs4oCZIGFuZA0KICAgIOKAmG5vbmXigJkgY2Fz ZS4NCiAgICA+DQogICAgPiBUaGUgaWYtZmVhdHVyZSBhcHBsaWVzIHRvIHRoZSBlbnRpcmUgY29u dGFpbmVyIOKAkyBpdCBpcyBlaXRoZXINCiAgICBzdXBwb3J0ZWQgb3Igbm90Lg0KICAgID4NCiAg ICA+ICAgICAqIFRoZSBhZHZhbmNlZC1jb21wYXJlIGNvbnRhaW5lciBoYXMgYSBkZXNjcmlwdGlv biBzdGFydGluZyB3aXRoDQogICAgIlRoaXMgbGVhZiAuLi4iIGV2ZW4gdGhvdWdoIGl0IGlzIG5v dCBhIGxlYWYuDQogICAgPg0KICAgID4gW2NseWRlXSBUaGlzIHdpbGwgYmUgZml4ZWQgaW4gdGhl IG5leHQgZHJhZnQuDQogICAgPg0KICAgID4gICAgICogVGhlIGV4YW1wbGVzIGFyZSBtaXNzaW5n IDxmYWNpbGl0eS1maWx0ZXI+IG5vZGVzLg0KICAgID4NCiAgICA+IFtjbHlkZV0gVGhpcyB3aWxs IGJlIGZpeGVkIGluIHRoZSBuZXh0IGRyYWZ0Lg0KICAgID4NCiAgICA+ICAgICAqIFBlcmhhcHMg dGhlcmUgc2hvdWxkIGJlIG1vcmUgY29uc2lzdGVudCB0ZXJtaW5vbG9neSBmb3INCiAgICByZWNl aXZlcnMgb2Ygc3lzbG9nIG1lc3NhZ2VzOyBib3RoICJjb2xsZWN0b3JzIiBhbmQgImFjdGlvbnMi IGFyZSB1c2VkDQogICAgaW4gdGhlIGRyYWZ0LiBSRkMgNTQyNCB1c2VzICJjb2xsZWN0b3IiIGZv ciB0aGUgdWx0aW1hdGUgcmVjaXBpZW50IG9mIGENCiAgICBsb2cgbWVzc2FnZSAtIHdoaWNoIG1p Z2h0IG5vdCBiZSBhcHBsaWNhYmxlLCBiZWNhdXNlIHRoZSBzZW5kaW5nIHN5c3RlbQ0KICAgIGhh cyBubyBpZGVhIHdoZXRoZXIgdGhlIHJlY2VpdmluZyBzeXN0ZW0gaXMgYSBjb2xsZWN0b3Igb3Ig YSByZWxheS4NCiAgICA+DQogICAgPiBbY2x5ZGVdIFRoZSBkZWZpbml0aW9uIG9mIOKAnGNvbGxl Y3RvcuKAnSBpbiBSRkMgNTQyNCBpczogQSAiY29sbGVjdG9yIg0KICAgIGdhdGhlcnMgc3lzbG9n IGNvbnRlbnQgZm9yIGZ1cnRoZXIgYW5hbHlzaXMuDQogICAgPg0KICAgID4gYWN0aW9ucyByZWxh dGUgdG8gdGhlIOKAnGZ1cnRoZXIgYW5hbHlzaXPigJ0gdGFrZW4gYnkgdGhlIOKAnGNvbGxlY3Rv cuKAnS4NCiAgICA+DQogICAgPiDigJxDb2xsZWN0b3Jz4oCdIGFwcGVhcnMgaW4gdGhlIG1vZGVs IHVuZGVyIHRoZSByZW1vdGUgYWN0aW9uIGFuZCBJDQogICAgYmVsaWV2ZSB0aGUgdXNhZ2UgaXMg Y29ycmVjdDoNCiAgICA+ICAgICAgIGNvbnRhaW5lciByZW1vdGUgew0KICAgID4gICAgICAgICBp Zi1mZWF0dXJlIHJlbW90ZS1hY3Rpb247DQogICAgPiAgICAgICAgIGRlc2NyaXB0aW9uDQogICAg PiAgICAgICAgICAgIlRoaXMgY29udGFpbmVyIGRlc2NyaWJlcyB0aGUgY29uZmlndXJhdGlvbiBw YXJhbWV0ZXJzIGZvcg0KICAgID4gICAgICAgICAgICBmb3J3YXJkaW5nIHN5c2xvZyBtZXNzYWdl cyB0byByZW1vdGUgcmVsYXlzIG9yDQogICAgY29sbGVjdG9ycy4iOw0KICAgID4NCiAgICA+IEkg d2lsbCByZXZpc2UgdGhlIGRlc2NyaXB0aW9uIG9mIHRoZXNlIHRlcm1zIGluIHRoZSBuZXh0IGRy YWZ0Lg0KICAgID4NCiAgICA+IFRoYW5rcywNCiAgICA+DQogICAgPiBDbHlkZQ0KICAgID4NCiAg ICA+ICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiAg ICAgRnJvbTogbmV0bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEtl bnQgV2F0c2VuDQogICAgPGt3YXRzZW5AanVuaXBlci5uZXQ+DQogICAgPiAgICAgU2VudDogU2F0 dXJkYXksIDggSnVseSAyMDE3IDY6MzQgYS5tLg0KICAgIA0KICAgIA0KDQoNCg0K From nobody Wed Aug 9 14:26:49 2017 Return-Path: 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 3C7A3132339 for ; Wed, 9 Aug 2017 14:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 0unXMvSFIUbT for ; Wed, 9 Aug 2017 14:26:45 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0100.outbound.protection.outlook.com [104.47.41.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DBF7132191 for ; Wed, 9 Aug 2017 14:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=laNrFWraVwn8IY0aaVkR3izjmiNd4IckqhAd5vEV/Os=; b=ITMpK9MST9g+79+7KnHIG9bg3dE0Xksj6yQ2O0IFP+GAuSz+qr4jSZfA21Fszy7vj2NUq1RCzGziqfNRaIgG1snld29iFIjZjs4HqdZ2/aiFFGHal0NtVoDNNlFjNBJoP450NEztmN+1B9hLX3wC8JMt7aYaMiE9sYZdcphPnmc= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1569.namprd05.prod.outlook.com (10.161.217.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1341.9; Wed, 9 Aug 2017 21:26:44 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1341.010; Wed, 9 Aug 2017 21:26:44 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15 Thread-Index: AQHTEVYynxmaKupZ/kyeF+fon7bzlg== Date: Wed, 9 Aug 2017 21:26:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1569; 6:yFm0vZl7MSpt9aPgCDtXQEnK7XU7iX/6jdOBr8YZVSyuTEWx4TbbqMIKYRA+QH2BhUio83UAEixbIv7NMwTxnK5Nef7wiu3moxfCQEZvIpMDu47d8URGhnxiRdqzUf6lfe0mNpHELhQirEpAgj/izhWl+XCPr6fVydnaMwLgg2rjjFDTAJMWZR6kAQslwCpVh4RJH7QRlZAZyrSbIHn2xfEtDelRHEhH0s5sRmZFNcQRwcuduF1MgSZqjGJ79ooojc92vfRYXhIrcrZl4dOpRj+orv3FgI/mHkeMTkWDNEo5RFmpnRLEUt5m80044cPPZXMZN9hrY1Z3GuOk2ksndw==; 5:tUD885gn2w03JtE1JHWF3IgJmQhSdLvkPtm8D91okoNL7BVi56pE4ooRFpB+4mbB7Di/ty3tT09VY1QAeKLryO5sumZU61G8BGAtRlDDJNet4aBLI71cy8n687a5DF4Clt5VmhlEqwzitMaRnRlrKg==; 24:uiZ/lmpHZCI0axmDRmZs2yPwR+90CiMzO0gKey0Aky6pheziypJ9IWaklVirrruWjyVhmrL4LeNvnV0xCe3OB+Hhfl8/oZLAWkEHrfCnoHQ=; 7:Q5ZM23zGLiB1bm0PhcTjKK7IrBU9zu8blL11wD3Gy3/VHfmKqR2jgs0ySDwt1zfvLEmXt3+79oOTu5rJngX91SiqTrizSzGfL/z9GLErDrNZDPxguV6zDLuKsVdln1XAM0rZZ3y/umf9oVZtQR/fQjuliyLPzm/bxx1i657a81fEGZeTJTT78EZqQx5X/2vSZrnJLe9bvl9OGDcvwdE2m9RQymloaHwIfBeEgXoBYE4= x-ms-office365-filtering-correlation-id: 4585210f-9253-4f78-c0f2-08d4df6d554a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1569; x-ms-traffictypediagnostic: BN3PR0501MB1569: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123562025)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1569; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1569; x-forefront-prvs: 0394259C80 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39400400002)(39840400002)(39450400003)(39850400002)(39410400002)(39860400002)(189002)(199003)(2501003)(99286003)(8676002)(81166006)(86362001)(81156014)(4001350100001)(1730700003)(478600001)(6916009)(6486002)(230783001)(50986999)(38730400002)(2900100001)(6512007)(106356001)(54356999)(53936002)(6246003)(6116002)(305945005)(189998001)(110136004)(82746002)(77096006)(102836003)(101416001)(25786009)(14454004)(105586002)(83506001)(36756003)(5640700003)(2351001)(68736007)(3846002)(8936002)(7736002)(66066001)(5660300001)(83716003)(6436002)(33656002)(3280700002)(6506006)(229853002)(2906002)(3660700001)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1569; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2017 21:26:44.0536 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1569 Archived-At: Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 21:26:47 -0000 DQpUb2RheSdzIGFjdGl2aXR5IG9uIHRoaXMgdGhyZWFkIG5lY2Vzc2l0YXRlcyBhbm90aGVyIHJl c3BvbnNlIGFzIHdlbGw6DQoNClRoZSBXRyBMQyBpcyBjbG9zZWQuICBBdXRob3JzLCBwbGVhc2Ug YWRkcmVzcyBhbnkgY29tbWVudHMgdGhhdCBoYXZlDQpiZWVuIHJlY2VpdmVkLCBhbmQgbGV0IHRo ZSBXRyBrbm93IGhvdyB0aGUgaXNzdWVzIGhhdmUgYmVlbiBhZGRyZXNzZWQsDQphbmQgd2hlbiBh IHZlcnNpb24gaXMgYXZhaWxhYmxlIHRoYXQgaXMgcmVhZHkgdG8gYmUgc3VibWl0dGVkIGZvciAN CnB1YmxpY2F0aW9uLg0KDQpUaGFua3MsDQpLZW50IChhbmQgTG91KQ0KDQoNCg0K From nobody Fri Aug 11 08:30:36 2017 Return-Path: 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 2941D13256B for ; Fri, 11 Aug 2017 08:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 mL5lcCLsJMx3 for ; Fri, 11 Aug 2017 08:30:31 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0138.outbound.protection.outlook.com [104.47.1.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AE3013253B for ; Fri, 11 Aug 2017 08:30:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P8cpbJNPA7koj/LAQ6rKI6yk4svAApBkKBOvJJTp3pk=; b=EAV31v2Ku3LA24p29/t5BpHNIoFdvd72TLBwb1IJEnLL9ByeG51KtK9rNZ/dTC89svmRjSa5sOiZ0T5rTUNXSCwcjQA+/Fz9ZCu8hwDM/0tRzVE4VhrqRSBmmt3ag+AW+luHd421Ryho6soAfEJiyLlRkosFRaHvQGl5r1TFfsk= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.176.20.38) by AM5PR0701MB2993.eurprd07.prod.outlook.com (2603:10a6:203:48::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1341.9; Fri, 11 Aug 2017 15:30:27 +0000 Message-ID: <023901d312b6$1cb13640$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Clyde Wildes \(cwildes\)" , "Kent Watsen" , References: <91FA5813-8D96-414F-BAC6-BA6C65C5149C@cisco.com> <055c01d31103$28f51200$4001a8c0@gateway.2wire.net> <55F0DA02-0E29-46B6-9F4A-B2525EE3F003@cisco.com> Date: Fri, 11 Aug 2017 16:21:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.176.20.38] X-ClientProxiedBy: AM3PR07CA0145.eurprd07.prod.outlook.com (2603:10a6:207:8::31) To AM5PR0701MB2993.eurprd07.prod.outlook.com (2603:10a6:203:48::15) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7dbf1b5e-6d1a-4df9-1b87-08d4e0cde503 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2993; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 3:udeZqklr9sj567V0JGhTfF32QR0J6FX7xmgc7t1cxhP7Q4aSFMb57mfXCeXK4Q4FUPwzegeY9f9k8t+ETXCfcN37dMRpZnhAfDYJkmmWnpEXuqc55ZLlIsdksBHc98Gm9KZIFQcZTl1jSYyq+NxaLccgCRlgY7+E7y5JvLBuTSSdR0QSjMqQFBwkKNURDCGNY6hLNl2wmKaR3Q9aU5ZOaE6LwWgapgvAI+RNkA0oBGx1a/jCvFB88Jykzf/WCKN1; 25:TAk9q5Y4Q43e7igT2Pd4nhniWNxnx5gzWgOpBjomM6vE5JQrriszJYAeKSdDn2485nzMszs+VrmhmLNWThRrC7YJP7lD8VaCg1j3tr/GvRWzEQH8qWMejD/REcEShBb7eSIlJ82FHC4ju7RJKg5xNY0V+YtFzcCB7/pNvYy4gUvFHR2PpuX+IQi9fJQk9Rk3lRMonEki06/8SRH+h1DuTnOhPex11+ZCqZhUIkp/GDTYXDzVl6tSOLhS7KxxSt4Tc7voZX6vpi/HpPXCScnRJITUJQfFWQbICH+12SDlMkJ5QU8CfJ8LuqmkUAxAA5y+LXIjGzJBjZT8tKI66OItyA==; 31:L/zLLyAXnf4/8+HcGcK/O243nU3wi57Qnae9EMbgxdxoNMYbZXtvpkIQgxMaGdUFpGbwm7Lz5sXjjJSx5naqTIiMbk2wn8Efe3eopfSI/bmwp3foo9ghf3QnIwNWSRQscahIuvoHJ4ZlQZWPTFAyNTcz3Zt5B+WQ/4kKgkQfp1mVeQPrfOLWHgSU2DZLg8AMDZ3Y1CwgQ4yEG0aguvV4PUUGDP/oZ1sej3NLKslGVgg= X-MS-TrafficTypeDiagnostic: AM5PR0701MB2993: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(192374486261705)(138986009662008)(95692535739014)(17755550239193); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2993; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2993; X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 4:iYuFxTWQO8cUSj2GvVEKwHYG7AR0llJdE+D8LDGvMK+VtHlODpX7AhP6/OF+1drs/GzfMAugO7Ly07FXSdeOHQhv6C6jsX3Sm/MU5MYSAV84ckYHMjXOysPl6oBjbo5AV7uyLzMff12mfBxx8VU7zF4SaPeeW8UKz4JPQ7N5BK2E0dQ0bmubBzMB+BuQkRdimq0hf0KeJw+xaujwRf2f4+ja7SripfUZaen9tDIM9Py1b4fYYLdGALWqQEUNX5JpN9JiVBGB4Qw2CS1Jlq0NuZRdVXuLMiUV15ERgT5zWmqfduBLylD8JY5PepUOvbojJDtOWBG83W0l0LYhmNZYtKNQoC6SAqIjH3xQQk2zeOuU6/al1H7up+fOzoFl2yjgCn3JjspaZf29fvDqZc/Gd7Xi+sw9JjrucM61lgdH/9SWOvP2NuBC0IA7IKUmgkL8 X-Forefront-PRVS: 03965EFC76 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6009001)(39860400002)(189002)(24454002)(13464003)(199003)(51444003)(377454003)(47776003)(1556002)(189998001)(106356001)(42186005)(61296003)(7736002)(8666007)(50226002)(305945005)(25786009)(44736005)(14496001)(9686003)(66066001)(23676002)(6486002)(62236002)(44716002)(86362001)(1456003)(53936002)(105586002)(68736007)(229853002)(50466002)(81166006)(3846002)(101416001)(4720700003)(6666003)(8676002)(84392002)(53546010)(7350300001)(6246003)(81156014)(478600001)(6116002)(6496005)(230783001)(81816999)(97736004)(76176999)(33646002)(1941001)(2906002)(5660300001)(81686999)(116806002)(2870700001)(50986999)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0701MB2993; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjA3MDFNQjI5OTM7MjM6SEptalRNaFRva3gvMXRGNEpDdUJkdkRC?= =?utf-8?B?MDFrMmlySENMYk9Kblg2blhSbUZvU3Z4ejdjWFB1UU4rNlgwWUdDbXAvUzJQ?= =?utf-8?B?V3dldmhzMWxZWFlkZU5nQTQxVStsWWcxVkRhYVU3bkR2SzlrWlRiUStKaW1r?= =?utf-8?B?ZUhETWRvM0hjYTFKajZGdzdGTFN1QW5oeU43clU3K3A4dldEQXlVT3FSRkR4?= =?utf-8?B?OFNxbnRTS3p6bTVIRzRFZTBDckc5K3RvRVdheTlCRkowRSsyUjlIeHFPSUd5?= =?utf-8?B?ME9NYktHV1Y1Umo0d2JVV0h3MW5xNGVxWXU0MERsbzVIRzJvVWprVmd2MWFm?= =?utf-8?B?NG9qcmFzaDdTODM2YTdjZENobU12ME50c0QzUGY3ZG1DbVRzSTFHS1paS2h0?= =?utf-8?B?VytuZ3RtdVZPd0E2Uy9ldjNoV2NrODBwUEZBYnpHWUZad2VZeVE1cmt0Wmdu?= =?utf-8?B?YUtYOVhtOEE1a1dFU3YxM2NiUzZodXI0cHlzNlIvQmZLNFkxcmU3dUU2bFZ2?= =?utf-8?B?SUY2WFhrNjFGSXB5OG9tODJHU2ExNHBzV2I2d2YxNFNDRjhYNDBIOGRpQUtw?= =?utf-8?B?eUphaEdYVG9RdHYyWThIc1U4MnNmeHNxRSs0aFNKVEcwczk4NWtTRjJ6L2Jt?= =?utf-8?B?WGtaUDdxL1BTRE52alc0YlNFQzBCL2pjUldLL2IzWVhjUENSM2hhb0JoaDZ0?= =?utf-8?B?NjdJSGhDMzhJRjArb0wwT2JFb08xOHlRY3FuVUVXUXpGczc3eVBpSGZTaW5W?= =?utf-8?B?RVdicVV1ZUpWdkFyZGxtbFM0eVdSVmViWkw1WkdJRm4xT251UTBoekFMem1j?= =?utf-8?B?TWJENUZaQ3pyZDhNL0tpcUJjM0RLQWJWZTNSUHlzaWx4bW1YdDd0dU90UTMz?= =?utf-8?B?cjRLQTZ1SFc4bGZCQ04zUEFncHlpSDJFYjkwWFc1YnUwNkVRQWV5aDVpN2s1?= =?utf-8?B?dGswc1VDekFQbGxPbkJzNkFFdGhQZWhNbW9qNTJaRmFQVlpuYmRNZG45dkNo?= =?utf-8?B?NkVLN1A5ekY5ZXFUNjlLZkFkWnZCeWFwSlhoWHJpdFM4eEZ2V0laK0RyUElO?= =?utf-8?B?THc0NVBZTE1yV0RCMTN1SWR0N25VZS84eklGMDlIUDRrNitYcDdMN0xGSkVh?= =?utf-8?B?d3o0NDN2RktObzhQVTFvdFR4OGdrdVBJSWxxcjJtS0MyQWpwWm0yZzY2UkMv?= =?utf-8?B?dzhXNEpuV0ppY1NJc3JWTC85c0xlclhtREdHOXdxcytzWFNodlNIcG51b1FP?= =?utf-8?B?TEJwU3pwMHVyZlVpbGtpdHVxV1h3NXlCL2htbEJLKzJsUmR6RlBka2t0bWFY?= =?utf-8?B?M1JiaDd3cmdBYm9UZms2TnRxbS9PYURpRzN1aU5GMHV2VGljL3BXVG5pTmll?= =?utf-8?B?bC8wVmZFV1hYV3FZQml4aC9NVWVveG1pVDBOL3g2TFZJbmM0b2QxYWJ3ZjJl?= =?utf-8?B?WHhnVStuQkhKOXkwY2NSSlhsL2NFNTZEelVxZ3czN0kzckNKMmxjNEJrcGJk?= =?utf-8?B?bHNDYnQzVm9ZM202WDAvVzllMVVoSEVUSy9ldnRkWi9XVU85S0hzS213VDRu?= =?utf-8?B?YXVQTW5NR3htYld1UjJCQVNiVk43NDJMaGE2SUUwc21uL1U5QmMrbTYvVUF6?= =?utf-8?B?Ui83dy9MdE1Ra1BrRFJlYjF1YmpMUThQeTUzTk5HTkZJZlg2Ym9kaTRFVEpw?= =?utf-8?B?d0EyWnFrbCtqL3hsYUJoQ0ZWSXY4bys1MGtnNXpISi9SNExIOTY3b0VJald4?= =?utf-8?B?eEpZUm5wOGtXVU10WnhHTXhDQkpCYzgwSGszL25TdStEUjNoYnRZZDZJSENF?= =?utf-8?B?NlBkVzF1SnAvWmVnbDYvN2hIN2FsN0ZHNnh5R2JjUW9aQWlUQ2xubFlNdTY4?= =?utf-8?B?L1VjQk5HS2szR1JKWXNCRU5RdGoyYndkdGtvRjNYRkFjaXgxbmNoRm8zTGVv?= =?utf-8?B?aVJmNUgrZXhKTE5XQ21Gb1BnY25LTHI4b292c2ZzdmlTVExncHprQWJzU1Fp?= =?utf-8?B?M3ZmS3djSStVZHBadDVzc015VmVYYlN3a29oSDJ2d2p3U0h1NXBiMkowbmxt?= =?utf-8?Q?1KG/iw=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM5PR0701MB2993; 6:kn9PosDULt8fQ/ipegq3iOmfncAMG6LbjIXIvAZPhFLOXD9VqLbtBI4JrsXFkDkuqF9lW5jdPclb3/M7HFkUMqD092r3IFKeEgt9XbH1xbkTbb+q5ujbALNOuG5/lX12u2m0ZF29I3e3l5A4DpBITkIHzLK8NO90qie3JDHi+OOmOA6v5Qvjnb1V0dPbmS4xWjhwmYTm7bn22+PgwiEfuJ4NQvEvjcpnwLIlYRPhU77+PBm5wSgRWiowKzgOdPMzcrIHW6uQMRX/2z6eYmaeRZAoDmKbrHbjHV0EoM+B5l1MsoNRdinXT3g6ll2Rtl1ktHM+B2n7IeZIbVvM58AYvQ==; 5:epwHXEITrMgfk3LTKhShqjPIR/rz7kLHkOoOLmla3r86YR9HaxJI0VzRqnNcGPnWgxc5WsQwSTptiTAIinwH8IsfrgLMLo9v1HOPRvGdNFUf1hry9JPS2HQCoQ9DD+/vQlwvwvyAkeUrlEkjiyOOWQ==; 24:AEXM6epmiGnbaNnmFjzXsPl8x08yO66F9fwpK8LpSsAUBRzi34WP2fhX4O4r88AAFfZDP5I9zrCKr/VzAy9X7bGP7VSbJ2btdoVEEEwV3is=; 7:mraRlSEbKzNmkb7fRAhCvf1VTrFFkmwodtlJH42RHFjoE9bqgoPYtvORHOsR3ww2CdHOOfVRcTLnUeIxxaMPORhGcLVAltRyFAFWgmLNeSBV6Uw5S+/pGr3ljgvotPFjOX/7DsbHnCjzBqugyH1MTvAfeegOqRevHc0QxrIF82wMJ40dxbNBYVDwmTmoFmfoH4u+UdSvgSihtiVDobamktVQmNN09WCslmSVXvvFo+4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Aug 2017 15:30:27.7904 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2993 Archived-At: Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 15:30:34 -0000 Clyde As Kent says, I would prefer to see only one XXXX with others being YYYY or some such. Further, I think that this RFC xxxx to be should be in the list of References. Adding it there would then solve my additional problem of which I-D you have in mind. There are two relating to key management and neither are titled Keystore Management:-( I can guess which you mean but I do not think that I should be guessing! Tom Petch ----- Original Message ----- From: "Clyde Wildes (cwildes)" To: "t.petch" ; "Kent Watsen" ; Sent: Wednesday, August 09, 2017 5:53 PM Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15 > Tom, > > The agreement was that I should use “xxxx” until the two unapproved RFCs that the model depends on are assigned numbers. > > RFC xxxx: Keystore Management > RFC xxxx: Transport Layer Security (TLS) Client"; > > Imported are: > > import ietf-tls-client { > prefix tlsc; > } > > import ietf-keystore { > prefix ks; > } > > > Have numbers been assigned? > > Thanks, > > Clyde > > On 8/9/17, 4:32 AM, "t.petch" wrote: > > Clyde > > You use xxxx as a placeholder for three different RFC and two of these > do not appear AFAICT in the list of References. > > This might be a challenge for the RFC Editor. > > Tom Petch > > > ----- Original Message ----- > From: "Clyde Wildes (cwildes)" > Sent: Wednesday, July 19, 2017 6:48 PM > > > > Hi Alex, > > > > Answers inline as [clyde]… > > > > On 7/17/17, 4:20 PM, "netmod on behalf of Alex Campbell" > wrote: > > > > I am considering to implement the data model in this draft. > (dependent on business priorities of course) > > I have reviewed this draft and found the following issues. > > > > * I see pattern-match is specified to use POSIX 1003.2 regular > expressions. This is presumably for compatibility with existing > implementations; however it is inconsistent with most of YANG (which is > specified to use XPath regular expressions) - unless these are the same. > > > > [clyde] I believe that my answer in the other thread explains why we > used Posix 1003.2 – it is commonly used. > > > > * pattern-match is inside the facility-filter container; common > sense says this is wrong as pattern-match has nothing to do with > facilities. > > > > [clyde] I will move pattern-match up one level in the next version of > the draft. Thanks for catching this! > > > > * The advanced-compare container groups together two nodes that > share a common "when" and "if-feature" statement, but don't seem to have > any semantic relation to each other. Are there general guidelines on > when to use a container? > > > > [clyde] The confusion may come as a result of the when clause > appearing before the if-feature clause which is set by the IETF > statement order recommendation. > > > > The when construct was suggested by Martin Björklund as a way of > solving the case that advanced-compare does not apply for the ‘all ’ and > ‘none’ case. > > > > The if-feature applies to the entire container – it is either > supported or not. > > > > * The advanced-compare container has a description starting with > "This leaf ..." even though it is not a leaf. > > > > [clyde] This will be fixed in the next draft. > > > > * The examples are missing nodes. > > > > [clyde] This will be fixed in the next draft. > > > > * Perhaps there should be more consistent terminology for > receivers of syslog messages; both "collectors" and "actions" are used > in the draft. RFC 5424 uses "collector" for the ultimate recipient of a > log message - which might not be applicable, because the sending system > has no idea whether the receiving system is a collector or a relay. > > > > [clyde] The definition of “collector” in RFC 5424 is: A "collector" > gathers syslog content for further analysis. > > > > actions relate to the “further analysis” taken by the “collector”. > > > > “Collectors” appears in the model under the remote action and I > believe the usage is correct: > > container remote { > > if-feature remote-action; > > description > > "This container describes the configuration parameters for > > forwarding syslog messages to remote relays or > collectors."; > > > > I will revise the description of these terms in the next draft. > > > > Thanks, > > > > Clyde > > > > ________________________________________ > > From: netmod on behalf of Kent Watsen > > > Sent: Saturday, 8 July 2017 6:34 a.m. > > > > From nobody Fri Aug 11 19:05:12 2017 Return-Path: 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 D66AF132486 for ; Fri, 11 Aug 2017 19:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 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 TT0YQbKXyUip for ; Fri, 11 Aug 2017 19:05:09 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D100F13246A for ; Fri, 11 Aug 2017 19:05:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8138; q=dns/txt; s=iport; t=1502503508; x=1503713108; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=iM1j3EGzdmMkWP+rSmkdGNVKVFtXO/9JGesnAkInXOs=; b=JT0K9ljMQpYAY3k9kkLdjD0rxHKf19AF2DIQ3UAMNl4Y7cg3ML5wvLnE AuUqByHVGj7uN5gcuPOYuMMZcJIttwS27VSd1pvdWiQn1S2buTJtKU5Uf U6+1bJ6Km3/Y8eAJ/XmZ8TYgnVoLtGO96Po7eu8SyJzYF6Hg7rx2w6pBW 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C2AAB/YY5Z/5JdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkOFwHjgqQDZgFghIhC4RMTxyEXD8YAQIBAQEBAQEBayiFGQY?= =?us-ascii?q?BARsGETcDGwIBCA4MAiYCAgIlCxUQAgQBEoovEKsogiaLYwEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFgQuCHYExUYFMgWIBK4FwgQyEXS2CfDCCMQWRBI8iAodRjGe?= =?us-ascii?q?CD4Vdg3qGbpYSAR84gQp3FUkSAYUEHIFndogxgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,360,1498521600"; d="scan'208";a="279530966" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Aug 2017 02:05:08 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v7C257Ep002987 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 12 Aug 2017 02:05:07 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 11 Aug 2017 21:05:07 -0500 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1210.000; Fri, 11 Aug 2017 21:05:06 -0500 From: "Clyde Wildes (cwildes)" To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15 Thread-Index: AQHS+qgfFNU1WyBT406RudsboUthDA== Date: Sat, 12 Aug 2017 02:05:06 +0000 Message-ID: <0558E64E-2CE7-4C3E-94C8-1CA7CE78171E@cisco.com> References: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.145.6] Content-Type: text/plain; charset="utf-8" Content-ID: <0EE14168BA24E547B0F718DBCCF329B2@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 02:05:11 -0000 S2VudCwNCg0KVGhhbmtzIGZvciB5b3VyIGV4aGF1c3RpdmUgcmV2aWV3LiBJIHdpbGwgYmUgcHVi bGlzaGluZyB0aGUgcmV2aXNlZCBtb2RlbCBtb21lbnRhcmlseS4NCg0KQ29tbWVudHMgaW5saW5l IGFzIFtjbHlkZV0uDQoNCk9uIDcvMTIvMTcsIDI6NTUgUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9m IEtlbnQgV2F0c2VuIiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGt3YXRz ZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KDQogICAgQXMgc2hlcGhlcmQsIHlhbmcgZG9jdG9yLCBh bmQgaW5kaXZpZHVhbCBjb250cmlidXRvciwgZm9sbG93aW5nIGlzIA0KICAgIG15IExDL1lEIHJl dmlldy4NCiAgICANCiAgICAxLiBCZWNhdXNlIEkga25vdyB0aGlzIGRyYWZ0IHdpbGwgbm90IGJl IHByZXNlbnRlZCBpbiBQcmFndWUsIEkgZmlyc3QNCiAgICBjaGVja2VkIHRvIHNlZSBpZiBpdCB3 YXMgTk1EQS1jb21wYXRpYmxlLiAgVGhlIGRyYWZ0IGNvbnRhaW5zIGp1c3QNCiAgICBvbmUgbW9k dWxlLCBhbmQgaXQgb25seSBjb250YWlucyBjb25maWcgdHJ1ZSBub2RlcyAobm8gY29uZmlnIGZh bHNlDQogICAgbm9kZXMpLiAgVGhlcmUgaXMgbm8gY29tcGFuaW9uICItc3RhdGUiIG1vZHVsZSBp biB0aGUgQXBwZW5kaXguICBBcw0KICAgIGZhciBhcyBJIGNhbiB0ZWxsLCBhbGwgdGhpcyBpcyBh Y2N1cmF0ZSwgYXMgSSBkb24ndCBiZWxpZXZlIHRoaXMgDQogICAgbW9kdWxlIG5lZWRzIHRvIGRv IGFueXRoaW5nIHNwZWNpYWwgdG8gYmUgTk1EQSBjb21wYXRpYmxlLiAgQWdyZWVkPw0KICAgIA0K W2NseWRlXSBBZ3JlZWQuDQoNCiAgICAyLiB0aGUgYWJzdHJhY3Qgc2VlbXMganVzdCBhIGxpdHRs ZSBibGFuZC4gIElzIHRoZXJlIGFueSB3YXkgdG8gYmVlZg0KICAgIGl0IHVwIHdpdGggYSBzZW50 ZW5jZSBvciB0d28/DQoNCltjbHlkZV0gRG9uZS4NCiAgICANCiAgICAzLiBTMSwgUDEsIGxhc3Qg c2VudGVuY2UuICBzL3RoZSBtZXNzYWdlcy90aGVzZSBtZXNzYWdlcy8/DQoNCltjbHlkZV0gRG9u ZS4NCiAgICANCiAgICA0LiBTMSwgUDMsIDFzdCBzZW50ZW5jZTogImFuZCBwcm9jZXNzZXMgdGhv c2UiPyAgLSByZXdyaXRlIHNlbnRlbmNlPw0KDQpbY2x5ZGVdIERvbmUuDQogICAgDQogICAgNS4g UzEgYXMgYSB3aG9sZS4gIEknbSBhIGJpdCB1bmNsZWFyIHdoYXQgdGhpcyBzZWN0aW9uIGlzIGRv aW5nLiAgSXQNCiAgICBzZWVtcyB0byBiZSBhIGdlbmVyYWwgc3VtbWFyeSBvZiBTeXNsb2cgKFJG QzU0MjQpLiAgRG8gd2UgbmVlZCB0aGlzIGhlcmU/DQoNCltjbHlkZV0gU3VnZ2VzdGlvbnMgYXBw cmVjaWF0ZWQuIEkgd2FudGVkIHRvIHByb3ZpZGUgYSBoaWdoIGxldmVsIG92ZXJ2aWV3IG9mIHRo ZSBzeXNsb2cgcHJvY2Vzcy4gSSBjbGVhbmVkIGl0IHVwIGEgbGl0dGxlLg0KICAgIA0KICAgIDYu IFMxLjE6IHlvdSBzaG91bGQgYWxzbyByZWZlcmVuY2UgUkZDODE3NCBoZXJlLg0KDQpbY2x5ZGVd IERvbmUNCiAgICANCiAgICA3LiBTMS4yOiB0aHJlZSB0ZXJtcyBjb21lIGZyb20gNTQyNCwgYnV0 IG9ubHkgb25lIGhhcyBpdHMgZGVmaW5pdGlvbg0KICAgICAgIHByb3ZpZGVkLiAgVGhpcyBzZWVt cyBpbmNvbnNpc3RlbnQuLi4NCg0KW2NseWRlXSBEb25lDQogICAgDQogICAgOC4gUzI6IHMvNjAy MC83OTUwLw0KDQpbY2x5ZGVdIGRvbmUNCiAgICANCiAgICA5LiBTMywgUDM6IHRoaXMgcGFyYWdy YXBoIGlzIGhhcmQgdG8gcmVhZCBkdWUgdG8gdGhlIHByZXZpb3VzIHBhcmFncmFwaA0KICAgIHRh bGtpbmcgYWJvdXQgcHJvcHJpZXRhcnkgZmVhdHVyZXMuICBNYXliZSByZXBsYWNlIHRoZSBiZWdp bm5pbmcgb2YgdGhlIA0KICAgIHNlbnRlbmNlIHRvIHJlYWQgIlNvbWUgb3B0aW9uYWwgZmVhdHVy ZXMgYXJlIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudA0KICAgIHRvIHNwZWNpZnkiPw0KDQpbY2x5 ZGVdIGRvbmUNCiAgICANCiAgICAxMC4gUzMsIFA0OiBUaGUgZGlhZ3JhbSBhcHBlYXJzIHRvIHNo b3cgbXVsdGlwbGUgb3JpZ2luYXRvcnMsIG5vdCANCiAgICBqdXN0IG9uZSwgc28gcy9hbiBvcmln aW5hdG9yL29yaWdpbmF0b3JzLz8gIEFsc28sIEkgZG9uJ3QgdGhpbmsgDQogICAgZWl0aGVyIG9m IHRoZSBjb21tYXMgYXJlIG5lZWRlZC4NCg0KW2NseWRlXSBkb25lDQogICAgDQogICAgMTEuIFMz LCBQNjogVGhpcyBwYXJhZ3JhcGggc3RhcnRzIGEgbmV3IGFzcGVjdCBvZiB0aGUgZGVzaWduLCBy aWdodD8NCiAgICBUaGlzIGlzIGxpa2VseSBqdXN0IGEgdGV4dC1yZW5kZXJpbmcgaXNzdWUsIGJ1 dCB0aGUgdHJhbnNpdGlvbiBmcm9tDQogICAgdGhlIGRpYWdyYW0gYWJvdmUgKEZpZ3VyZSAxKSB0 byB0aGlzIGxpbmUgaXMgbm90IHZpc2libGUuICBDYW4geW91DQogICAgcHJvdmlkZSBhIHRyYW5z aXRpb24gc2VudGVuY2U/DQoNCltjbHlkZV0gZG9uZQ0KICAgIA0KICAgIDEyLiBTMywgUDg6IEkn bSBoYXZpbmcgdHJvdWJsZSB1bmRlcnN0YW5kaW5nIHRoZSBwc2V1ZG9jb2RlLiAgV2hhdA0KICAg IGhhcHBlbnMgaWYgUyBhbmQvb3IgRiBhcmUgbm90IHByZXNlbnQ/ICBDYW4gUyBvciBGIGV2ZXIg bm90IGJlDQogICAgcHJlc2VudD8gLSBsb29raW5nIGF0IHRoZSB0cmVlIGRpYWdyYW0sIGl0IHNl ZW1zIGxpa2UgdGhleSBtaWdodA0KICAgIGFsd2F5cyBiZSBzZXQgdG8gc29tZXRoaW5nIGluIHRo ZSBtb2RlbC4NCg0KW2NseWRlXSBTIG9yIEYgbWlnaHQgbm90IGJlIHByZXNlbnQuIA0KDQogICAg ICAgVGhlIG9wZXJhdGl2ZSBzZW50ZW5jZSBpbiB0aGUgcHNldWRvY29kZSBpczogDQogICAgICAg VGhlcmUgaXMgYW4gZWxlbWVudCBvZiBmYWNpbGl0eS1saXN0IChGLCBTKeKApg0KICAgICAgIG9y IHRoZSBtZXNzYWdlIHRleHQgbWF0Y2hlcyB0aGUgcmVnZXggcGF0dGVybiAoaWYgaXQgaXMgcHJl c2VudCkNCiAgICANCiAgICAxMy4gUzMuMSwgUDE6IFJGQyA2MDg3IGRpZCBub3QgZGVmaW5lIHRy ZWUgZGlhZ3JhbSBub3RhdGlvbiwgYW5kDQogICAgcmZjNjA4N2JpcyByZWZlcmVuY2VzIHRoZSB0 cmVlLWRpYWdyYW0gZHJhZnQuICBJIGRvbid0IHRoaW5rIHRoYXQNCiAgICBpdCBpcyBzYWZlIGZv ciB0aGlzIGRyYWZ0IHRvIHJlZmVyZW5jZSB0aGUgdHJlZS1kaWFncmFtIGRyYWZ0LCBhcw0KICAg IHRoYXQgZHJhZnQgaXMgdW5zdGFibGUgKHRoZSBub3RhdGlvbiBtYXkgY2hhbmdlKS4gIFlvdSBz aG91bGQgDQogICAgcHJvYmFibHkgY29weS9wYXN0ZSB0aGUgVHJlZSBEaWFncmFtIE5vdGF0aW9u IHNlY3Rpb24gZm91bmQgaW4NCiAgICBvdGhlciBkcmFmdHMgdG9kYXkgKGVzcGVjaWFsbHkgbWlu ZSkuDQoNCltjbHlkZV0gSSB1c2VkIHRvIHRoZSBUcmVlIERpYWdyYW0gTm90YXRpb24gZW1iZWRk ZWQgaW4gdGhlIGRvY3VtZW50IGFuZCB3YXMNCmFza2VkIGJ5IGFub3RoZXIgcmV2aWV3ZXIgdG8g dXNlIHdoYXQgaXMgdGhlcmUgbm93LiBJIHdpbGwgY2hhbmdlIHRvIHlvdXIgZG9jdW1lbnTigJlz IA0Kbm90YXRpb24uDQogICAgDQogICAgMTQuIFMzLjE6IGlzIC9zeXNsb2cvYWN0aW9ucy9yZW1v dGUvZGVzdGluYXRpb24vdGxzLyBtaXNzaW5nIGFuDQogICAgJ2FkZHJlc3MnIGxlYWY/DQoNCltj bHlkZV0gbm90IGFzIGZhciBhcyBJIGtub3cNCiAgICANCiAgICAxNS4gUzQuMSwgUDE6IERvZXNu J3QgdGhlIG1vZHVsZSBpbXBvcnQgKmdyb3VwaW5ncyogZnJvbSBpZXRmLWtleXN0b3JlDQogICAg YW5kIGlldGYtdGxzLWNsaWVudD8NCg0KW2NseWRlXSBkb25lDQogICAgDQogICAgMTYuIFM0LjEs IHRob3VnaCBpdCdzIG5vdCBpbiA2MDg3YmlzLCBJIHRoaW5rIHRoYXQgaXQgaXMgYmVzdA0KICAg IHByYWN0aWNlIGZvciAnaW1wb3J0JyBzdGF0ZW1lbnRzIHRvIGluY2x1ZGUgYSAncmVmZXJlbmNl Jw0KICAgIHN1YnN0YXRlbWVudDoNCiAgICANCiAgICAgIGltcG9ydCBpZXRmLWtleXN0b3JlIHsN CiAgICAgICAgcHJlZml4IGtzOw0KICAgICAgICByZWZlcmVuY2UNCiAgICAgICAgICAiUkZDIFlZ WVk6IEtleXN0b3JlIE1vZGVsIjsNCiAgICAgIH0NCiAgICANCiAgICAxNy4gUzQuMSwgaW1wb3J0 cyB0aGF0IGFyZSB1c2VkIGZvciBncm91cGluZ3Mgb25seSBzaG91bGQgdXNlIGENCiAgICByZXZp c2lvbiBzdGF0ZW1lbnQ6DQogICAgDQogICAgICBpbXBvcnQgaWV0Zi10bHMtY2xpZW50IHsNCiAg ICAgICAgcHJlZml4IHRsc2M7DQogICAgICAgIHJldmlzaW9uLWRhdGUgWVlZWS1NTS1ERDsgLy8g c3RhYmxlIGdyb3VwaW5nIGRlZmluaXRpb25zDQogICAgICAgIHJlZmVyZW5jZQ0KICAgICAgICAg ICJSRkMgWlpaWjogVExTIENsaWVudCBhbmQgU2VydmVyIE1vZGVscyI7DQogICAgICB9DQoNCltj bHlkZV0gZG9uZQ0KICAgIA0KICAgIDE4LiBTNC4xLCBjYW4geW91IHB1dCB0aGUgYmVnaW5uaW5n IG9mIHRoZSAnb3JnYW5pemF0aW9uJyAoaS5lLiAiSUVURiIpDQogICAgb24gdGhlIG5leHQgbGlu ZSwgcy9ORVRDT05GIERhdGEgTW9kZWxpbmcgTGFuZ3VhZ2UvTmV0d29yayBNb2RlbGluZy8sDQog ICAgYW5kIHB1dCBhIGJsYW5rIGxpbmUgaW4gYWZ0ZXIgdGhlICdvcmdhbml6YXRpb24nIGxpbmU/ DQoNCltjbHlkZV0gZG9uZQ0KICAgIA0KICAgIDE5LiBTNC4xLCBpbiB0aGUgJ3NldmVyaXR5LWZp bHRlcicgZ3JvdXBpbmcsIHdoeSBkb2VzIGxlYWYgJ3NldmVyaXR5Jw0KICAgIGhhdmUgdmFsdWVz IHNldCBmb3IgZW51bXMgJ25vbmUnIGFuZCAnYWxsJz8gIFdoZW4gd291bGQgdGhlc2UgdmFsdWVz DQogICAgYmUgdXNlZCwgYXMgb3Bwb3NlZCB0byB0aGUgZW51bSdzIG5hbWUgc3RyaW5nPyAgSWYg eW91IGRvIG5lZWQgdmFsdWVzLA0KICAgIHRoZW4gc2hvdWxkbid0ICdub25lJyBiZSAyMTQ3NDgz NjQ3IChzbyBub3RoaW5nIGNhbiBiZSBncmVhdGVyIHRoYW4gaXQpDQogICAgYW5kICdhbGwnIGJl IC0yMTQ3NDgzNjQ4IChzbyBldmVyeXRoaW5nIGlzIGdyZWF0ZXIgdGhhbiBpdCk/DQoNCltjbHlk ZV0g4oCYbm9uZeKAmSBhbmQg4oCYYWxs4oCZIGFyZSBzZXQgdG8gdmFsdWVzIHRoYXQgYXJlIG5v dCBkZWZpbmVkIGluIFJGQyA1NDI0LiBUaGVzZSB2YWx1ZXMNCndlcmUgcHJldmlvdXNseSBzdWdn ZXN0ZWQgYnkgTWFydGluIEJqw7Zya2x1bmQNCiAgICANCiAgICAyMC4gUzc6IGNhbiB5b3UgaW5k ZW50IHRoZSB0d28gYmxvY2tzIG9mIGRldGFpbHMgc28gdGhlIHdob2xlIHRoaW5nDQogICAgcmVh ZHMgYmV0dGVyPw0KDQpbY2x5ZGVdIEkgc2VhcmNoZWQgZm9yIGFuIGV4YW1wbGUgdGhhdCBzaG93 cyBob3cgdG8gZG8gdGhpcyBpbiBYTUwgYW5kIGNvdWxkbuKAmXQgZmluZCB0aGUga2V5d29yZC4N CiAgICANCiAgICAyMS4gUzg6IHBsZWFzZSByZXdvcmsgc28gdGhpcyBzZWN0aW9uIHNvIGl0IG1h dGNoZXMgdGhlIG5ldyB0ZW1wbGF0ZQ0KICAgIGF0OiBodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJh Yy9vcHMvd2lraS95YW5nLXNlY3VyaXR5LWd1aWRlbGluZXMNCg0KW2NseWRlXSBkb25lDQogICAg DQogICAgMjIuIFM4LjE6IGl0IHdvdWxkIGJlIGJldHRlciBpZiB0aGUgdGhpcmQgcGFyYWdyYXBo IHdhcyBtb3ZlZCB1cCB0bw0KICAgIGJlY29tZSB0aGUgZmlyc3QgcGFyYWdyYXBoLg0KDQpbY2x5 ZGVdIGRvbmUNCiAgICANClRoYW5rcywNCg0KQ2x5ZGUNCg0KICAgIA0KICAgIERJU0NMQUlNRVI6 IEknbSBub3QgYSBzeXNsb2cgZXhwZXJ0LCBidXQgaGF2ZSBpbnRlcmFjdGVkIHdpdGggaXQsDQog ICAgaW5jbHVkaW5nIHN0cnVjdHVyZWQtc3lzbG9nLCBvdmVyIHRoZSB5ZWFycy4NCiAgICANCiAg ICBLZW50DQogICAgDQogICAgDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCiAgICBuZXRtb2QgbWFpbGluZyBsaXN0DQogICAgbmV0bW9k QGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRt b2QNCiAgICANCg0KDQoNCg0K From nobody Fri Aug 11 19:17:27 2017 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B634E132328; Fri, 11 Aug 2017 19:17:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150250423969.24551.6610594688078341933@ietfa.amsl.com> Date: Fri, 11 Aug 2017 19:17:19 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-syslog-model-16.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Aug 2017 02:17:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : A YANG Data Model for Syslog Configuration Authors : Clyde Wildes Kiran Koushik Filename : draft-ietf-netmod-syslog-model-16.txt Pages : 30 Date : 2017-08-11 Abstract: This document defines a YANG data model for the configuration of a syslog process. It is intended this model be used by vendors who implement syslog in their systems. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "xxxx" --> the assigned RFC value for draft-ietf-netconf-keystore o "yyyy" --> the assigned RFC value for draft-ietf-netconf-tls- client-server o "zzzz" --> the assigned RFC value for this draft The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-16 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 14 06:53:52 2017 Return-Path: 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 F252A132223 for ; Mon, 14 Aug 2017 06:53:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 RzL3dm0GrbvH for ; Mon, 14 Aug 2017 06:53:48 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0131.outbound.protection.outlook.com [104.47.36.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7481321F5 for ; Mon, 14 Aug 2017 06:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5h/8QrqADBD8J4M1L4a9W7UdNt2lPIMRK/22Bhg6DTM=; b=EznJzSIm30aDIlPy0AKyTF+Hf3/K88RqwcCwVfYHPtYF89xxOus3+Xv3dRc3h3su1kQuG8nxuWC1uuvIb7QAF3rDfs1R1IxznaSlv/DNNHIv1g9xogszZH+XKY8PdQRrBjZZWU0QbEn/3LZ+57XpgDfYYVIBVWbV43TJ9RbESiE= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1619.namprd05.prod.outlook.com (10.161.220.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.12; Mon, 14 Aug 2017 13:53:46 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1362.012; Mon, 14 Aug 2017 13:53:46 +0000 From: Kent Watsen To: "Clyde Wildes (cwildes)" , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15 Thread-Index: AQHS+qgfFNU1WyBT406RudsboUthDKKD0SUA Date: Mon, 14 Aug 2017 13:53:46 +0000 Message-ID: References: <0558E64E-2CE7-4C3E-94C8-1CA7CE78171E@cisco.com> In-Reply-To: <0558E64E-2CE7-4C3E-94C8-1CA7CE78171E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.13] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1619; 6:ai5J1AuWOxSh++4/Ep691TsGH0GKQoL9K5CbC84MOxtYqI4LYDjv1+kEz6Q/fy6AQAAuUUru4ryUcjRb0OXeyiRq3ZbmuM6qC64EVteJV9pyxI6+ii/fslwNOtYhVy/eDbjO1TqJ+VINeqyW+0CnFFTtxk4jSsh81u6Cj/3L6FHhDSiG6l54vnCZ4PlhYGtaBeXYVr7/4qgY6h27Mp0c6sTb24I9grzdCUzXY9VtXibCQeYLZa3QfjkRXHu2A1Ijpy0boyxwceZdJ8+qtarAIkwblLGIATjf4j/MrUu7hoks3PvkyWiZJPICKAmYljZN1Ky030psAKE+iZ7cJUArIg==; 5:ahV7Qo1nHQsMZB6Q9uzronPA9/INEHvkP/yUi9P0rWsixGNO+rHgsxCLrq1ekhci4KhPXgQyUAuSlyPZdxlv7ofLxnDkSSehWqdGuHhu7KhZAPmAAPGCN3Mj9RV6J7B2GwiwERrs5X2vpGYThRZShQ==; 24:Hl57VuV7zwinB7HwFKocG8NqCGQrHlJWgHHLWTdSO0SzMvcFU6ebAcpYnYQptYSXUOsBrsdo4lRpWOZn9kcKmB5xJcwhJbGioqnVJPA70OE=; 7:Z+GoVluyJtKvoLqbs/jC65qEUgL8ePsBamWmOmlo62Z+y2Hztx2pel0SmPU45RlXVnXrVL8InAHiFyB9DTcyfNDIRYCgxVsAQD9qG6UKmkExEPQvvSDjTZi4BnYp6LOhrHGJzHR9NDgNIATMpzzTv+ddKV45U9LpRxMCFolCKHF8FsGhlLAkqFeuYpe/5UYjBPxiDeUOF0+6ukNEZOU7TKwd5qtJ3j3tRhFnw6FDC1s= x-ms-office365-filtering-correlation-id: 8ec6b165-e38d-48f5-5cf6-08d4e31be27f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1619; x-ms-traffictypediagnostic: BN3PR0501MB1619: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123558100)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1619; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1619; x-forefront-prvs: 039975700A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(57704003)(199003)(189002)(2900100001)(6246003)(86362001)(101416001)(33656002)(25786009)(36756003)(50986999)(478600001)(76176999)(54356999)(14454004)(99286003)(230783001)(6512007)(189998001)(2950100002)(6486002)(77096006)(53936002)(6506006)(6436002)(106356001)(229853002)(105586002)(2501003)(3280700002)(3660700001)(83506001)(5660300001)(97736004)(2906002)(4001350100001)(83716003)(82746002)(102836003)(6116002)(81156014)(81166006)(66066001)(68736007)(3846002)(8676002)(8936002)(305945005)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1619; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <9D50C794A183E54989CE8CDF3C339670@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Aug 2017 13:53:46.8921 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1619 Archived-At: Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 13:53:51 -0000 DQoNCj4gICAgNS4gUzEgYXMgYSB3aG9sZS4gIEknbSBhIGJpdCB1bmNsZWFyIHdoYXQgdGhpcyBz ZWN0aW9uIGlzIGRvaW5nLiAgSXQNCj4gICAgc2VlbXMgdG8gYmUgYSBnZW5lcmFsIHN1bW1hcnkg b2YgU3lzbG9nIChSRkM1NDI0KS4gIERvIHdlIG5lZWQgdGhpcyBoZXJlPw0KPg0KPiBbY2x5ZGVd IFN1Z2dlc3Rpb25zIGFwcHJlY2lhdGVkLiBJIHdhbnRlZCB0byBwcm92aWRlIGEgaGlnaCBsZXZl bCBvdmVydmlldw0KPiBvZiB0aGUgc3lzbG9nIHByb2Nlc3MuIEkgY2xlYW5lZCBpdCB1cCBhIGxp dHRsZS4NCiANCk1vdmUgU2VjdGlvbiAyIHRleHQgdG8gU2VjdGlvbiAxLCByZXBsYWNpbmcgdGhl IHRleHQgdGhhdCdzIHRoZXJlPw0KDQoNCg0KPiAgICAgICAxMi4gUzMsIFA4OiBJJ20gaGF2aW5n IHRyb3VibGUgdW5kZXJzdGFuZGluZyB0aGUgcHNldWRvY29kZS4gIFdoYXQNCj4gICAgaGFwcGVu cyBpZiBTIGFuZC9vciBGIGFyZSBub3QgcHJlc2VudD8gIENhbiBTIG9yIEYgZXZlciBub3QgYmUN Cj4gICAgcHJlc2VudD8gLSBsb29raW5nIGF0IHRoZSB0cmVlIGRpYWdyYW0sIGl0IHNlZW1zIGxp a2UgdGhleSBtaWdodA0KPiAgICBhbHdheXMgYmUgc2V0IHRvIHNvbWV0aGluZyBpbiB0aGUgbW9k ZWwuDQo+DQo+IFtjbHlkZV0gUyBvciBGIG1pZ2h0IG5vdCBiZSBwcmVzZW50LiANCg0KSW4gdGhl IFlBTkcgbW9kdWxlLCBmYWNpbGl0eS1saXN0IGlzIGtleWVkIGJ5IFtmYWNpbGl0eSBzZXZlcml0 eV0sIHdoaWNoDQptZWFucyB0aGUgdmFsdWVzIGFyZSBhbHdheXMgcHJlc2VudCwgcmlnaHQ/DQoN Cg0KDQo+ICAgIDE0LiBTMy4xOiBpcyAvc3lzbG9nL2FjdGlvbnMvcmVtb3RlL2Rlc3RpbmF0aW9u L3Rscy8gbWlzc2luZyBhbg0KPiAgICAnYWRkcmVzcycgbGVhZj8NCj4NCj4gW2NseWRlXSBub3Qg YXMgZmFyIGFzIEkga25vdw0KPg0KDQpMb29raW5nIGF0IHRoZSB0cmVlLWRpYWdyYW0sIHRoZSAn dGxzJyBjYXNlIGRvZXNuJ3Qgc2VlbSB0byBoYXZlIHRoZQ0KYWRkcmVzcyBvciBwb3J0IGZpZWxk cy4gIEZXSVcsIHRoZSBpZXRmLXRscy1jbGllbnQgbW9kdWxlIGRvZXNuJ3QgDQpwcm92aWRlIHRo ZXNlIGZpZWxkcyBzbyB0aGF0IGNvbnN1bWluZyBtb2R1bGVzIGNhbiBjb25maWd1cmUgYSBub3Jt YWwNCmNsaWVudCB2ZXJzdXMgYSBjbGllbnQgbGlzdGVuaW5nIGZvciBjYWxsLWhvbWUgY29ubmVj dGlvbnMuLi4NCg0KCSAgICstLToodGNwKQ0KCSAgIHwgICstLXJ3IHRjcA0KCSAgIHwgICAgICst LXJ3IGFkZHJlc3M/ICAgaW5ldDpob3N0DQoJICAgfCAgICAgKy0tcncgcG9ydD8gICAgICBpbmV0 OnBvcnQtbnVtYmVyDQoJICAgKy0tOih1ZHApDQoJICAgICAgKy0tcncgdWRwDQoJICAgICAgICAg Ky0tcncgYWRkcmVzcz8gICBpbmV0Omhvc3QNCgkgICAgICAgICArLS1ydyBwb3J0PyAgICAgIGlu ZXQ6cG9ydC1udW1iZXINCgkgICAgICArLS06KHRscykNCgkgICAgICAgICArLS1ydyB0bHMNCiAg ICAgICAgICAgICAgICAgIDxhZGRyZXNzL3BvcnQgbWlzc2luZyBoZXJlLCByaWdodD8+DQoJICAg ICAgICAgICAgKy0tcncgc2VydmVyLWF1dGgNCiAgICAgICAgICAgICAgICAgICAgIDxtb3JlIGll dGYtdGxzLWNsaWVudCBncm91cGluZyBoZXJlPg0KDQogICAgDQoNCj4gMTkuIFM0LjEsIGluIHRo ZSAnc2V2ZXJpdHktZmlsdGVyJyBncm91cGluZywgd2h5IGRvZXMgbGVhZiAnc2V2ZXJpdHknDQo+ ICAgIGhhdmUgdmFsdWVzIHNldCBmb3IgZW51bXMgJ25vbmUnIGFuZCAnYWxsJz8gIFdoZW4gd291 bGQgdGhlc2UgdmFsdWVzDQo+ICAgIGJlIHVzZWQsIGFzIG9wcG9zZWQgdG8gdGhlIGVudW0ncyBu YW1lIHN0cmluZz8gIElmIHlvdSBkbyBuZWVkIHZhbHVlcywNCj4gICAgdGhlbiBzaG91bGRuJ3Qg J25vbmUnIGJlIDIxNDc0ODM2NDcgKHNvIG5vdGhpbmcgY2FuIGJlIGdyZWF0ZXIgdGhhbiBpdCkN Cj4gICAgYW5kICdhbGwnIGJlIC0yMTQ3NDgzNjQ4IChzbyBldmVyeXRoaW5nIGlzIGdyZWF0ZXIg dGhhbiBpdCk/DQo+DQo+IFtjbHlkZV0g4oCYbm9uZeKAmSBhbmQg4oCYYWxs4oCZIGFyZSBzZXQg dG8gdmFsdWVzIHRoYXQgYXJlIG5vdCBkZWZpbmVkIGluIA0KPiBSRkMgNTQyNC4gVGhlc2UgdmFs dWVzIHdlcmUgcHJldmlvdXNseSBzdWdnZXN0ZWQgYnkgTWFydGluIEJqw7Zya2x1bmQNCg0KRmlu ZSwgYnV0IGxldCdzIHJlLWV2YWx1YXRlIHRoZSB2YWx1ZXMgbm93LiAgSW1hZ2UgaGF2aW5nIGEg dmFyaWFibGUgeA0KYW5kIHN0ZXBwaW5nIHRocm91Z2ggdGhlIHNlbGVjdG9yIGxpc3Q6DQoNCiAg aWYgeCA+PSBmYWNpbGl0eS1saXN0L3NldmVyaXR5IHRoZW4gZm9vLg0KDQpOb3cgaW1hZ2luZSBp dCByZWFkOg0KDQogIGlmIHggPj0gJ2FsbCcgdGhlbiBmb28uDQoNCldoYXQgaW50ZWdlciB2YWx1 ZSBmb3IgJ2FsbCcgd291bGQgYWx3YXlzIGVuc3VyZSBUcnVlPyAgTUlOLUlOVA0KTGlrZXdpc2Us IHlvdSBjYW4gc2VlIHRoYXQgTUFYLUlOVCBpcyB0aGUgYmVzdCB2YWx1ZSBmb3IgJ25vbmUnLg0K DQoNCg0KPiAgICAyMC4gUzc6IGNhbiB5b3UgaW5kZW50IHRoZSB0d28gYmxvY2tzIG9mIGRldGFp bHMgc28gdGhlIHdob2xlIHRoaW5nDQo+ICAgIHJlYWRzIGJldHRlcj8NCj4NCj4gW2NseWRlXSBJ IHNlYXJjaGVkIGZvciBhbiBleGFtcGxlIHRoYXQgc2hvd3MgaG93IHRvIGRvIHRoaXMgaW4gWE1M DQo+IGFuZCBjb3VsZG7igJl0IGZpbmQgdGhlIGtleXdvcmQuDQoNCkFzc3VtaW5nIHhtbDJyZmMg WE1MLCB0aGVuIHlvdSBjb3VsZCBjb252ZXJ0IHRoZSBjb250ZW50cyB0byBhIGZpZ3VyZSwNCm9y IGEgbGlzdCB3aXRoIHN0eWxlPSdlbXB0eScNCg0KDQogIA0KVGhhbmtzLA0KS2VudA0KDQoNCg== From nobody Mon Aug 14 07:22:27 2017 Return-Path: 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 D48D213228D for ; Mon, 14 Aug 2017 07:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 4_l9dGyM1ojs for ; Mon, 14 Aug 2017 07:22:24 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 679DF13234B for ; Mon, 14 Aug 2017 07:22:24 -0700 (PDT) Received: from localhost (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id A26E01AE048A; Mon, 14 Aug 2017 16:22:22 +0200 (CEST) Date: Mon, 14 Aug 2017 16:20:46 +0200 (CEST) Message-Id: <20170814.162046.2238120211326349720.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: Alex.Campbell@Aviatnet.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20170719055038.GA19325@elstar.local> References: <1500416980342.21019@Aviatnet.com> <20170719055038.GA19325@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] ACL draft defines ether-type as a string X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 14:22:27 -0000 Juergen Schoenwaelder wrote: > It may even mean that they plan to change ether-type-0xXXXX to foo > once 0xXXXX is allocated to foo, which would be a problem. It seems > a union of a uint16 and an enum can be more robust. > > type union { > type uint16; > type enumeration { > enum ipv4 { > value 0x0800; > description > "Internet Protocol version 4 (IPv4)"; > reference > "RFC 791: Internet Protocol" > } > } > } > > A caveat is that the canonical representation of a uint16 is decimal > (and YANG today has no way to control that), which may be a bit > inconvenient here. Perhaps the description clause should overwrite > this. Actually, the lexical representation of a uint16 is decimal. The canonical representation is just a subset of this (leading 0s are removed etc, see 9.2.2 of RFC 7950). The description cannot change the lexical representation. So the only way to handle this today (if you need hex notation) is to use a union between an enum and a string with a pattern for the hex values (as in the ethertype-type below). > There is probably also a need to remember implementors that the > canonical representation of the union retains the notation, that is, > if I write a numeric value (i.e., if I write '0x800' I get back the > numeric value 2048 but if I write the enum value 'ipv4' I get back the > enum 'ipv4' and not a numeric value. > > I have also found a definition in [1] that uses a string with a > pattern to match a different notation for ether type numeric values. > > typedef ethertype-type { > type string { > pattern '[0-9a-fA-F]{2}-[0-9a-fA-F]{2}'; > } > description > "The EtherType value represented in the canonical order defined > by IEEE 802. The canonical representation uses uppercase > characters."; > reference > "IEEE 802-2014 Clause 9.2"; > } > /martin > While this may be more compliant to IEEE 802-2014 Clause 9.2, having > some type that easily resolves to a number may be more desirable in > practice. > > [1] https://github.com/YangModels/yang/blob/master/standard/ieee/802.1/draft/ieee802-dot1q-types.yang > > /js > > PS: Writing definitions for seemingly simple types can be fun. > > On Tue, Jul 18, 2017 at 10:29:40PM +0000, Alex Campbell wrote: > > Doesn't this mean that if a new protocol is defined, then it won't be usable in ACLs until the server's data model is upgraded? (And with many devices, that is quite likely never) > > > > > > ________________________________ > > From: netmod on behalf of Mahesh Jethanandani > > Sent: Tuesday, 18 July 2017 6:21 p.m. > > To: NetMod WG > > Subject: [netmod] ACL draft defines ether-type as a string > > > > The issue of ether-type defined as a string was discussed with participants from IEEE in IETF. It was generally agreed that since ether-types are well known values, and centrally managed, that they be defined as enumerations. There was some clarification sought by IEEE on which values need to be published. It was suggested that ether-types that are either private or do not have a protocol identified would be named as ether-type-0xXXXX where 0xXXXX represents the value assigned. All the remaining ether-types will be defined as enums with the well known names. > > > > As far as the impact of that on the ACL draft is concerned, it will be to remove all local definitions for ether-type from the draft, such as the one below and instead use the definition from IEEE, whenever that is done. It does however put a dependency on the IEEE model. > > > > > > leaf ether-type { > > type string { > > pattern '[0-9a-fA-F]{4}'; > > } > > description > > "The Ethernet Type (or Length) value represented > > in the canonical order defined by IEEE 802. > > The canonical representation uses lowercase > > characters. > > > > Note: This is not the most ideal way to define > > ether-types. Ether-types are well known types > > and are registered with RAC in IEEE. So they > > should well defined types with values. For now > > this model is defining it as a string. > > > > > > There is a note out to IEEE that needs to be > > turned into a liaison statement asking them to > > define all ether-types for the industry to use."; > > reference > > "IEEE 802-2014 Clause 9.2"; > > } > > reference > > "IEEE 802: IEEE Standard for Local and Metropolitan > > Area Networks: Overview and Architecture."; > > } > > > > Mahesh Jethanandani > > mjethanandani@gmail.com > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Mon Aug 14 07:47:23 2017 Return-Path: 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 E620413232C for ; Mon, 14 Aug 2017 07:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 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 bDGh1Rjn602v for ; Mon, 14 Aug 2017 07:47:19 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EB43132250 for ; Mon, 14 Aug 2017 07:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8224; q=dns/txt; s=iport; t=1502722039; x=1503931639; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=mEAEKEDMO35YZHulmCV9NoS4NDO5C5XpjLH120/J4xw=; b=NtVvOqwkXaxqSlWjCyl0eNcFhzcH97zjuNMCqdKvgwjdqm1WjjsN/JhR K0lmxbpm//K/4D87szRe6V1Lf9Xvjct6h3fDJ1qx9mJ667cQ9RYbj+sXj J6O6JA/BLNF54h9T2VkNnBu05MhPCPKLT5BCipKUnTDK+BctT6aM7tgoI Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BcAQD4tpFZ/4MNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1qBHFwHjgqQDoFMIpYYghKFRwIahF4/GAECAQEBAQEBAWsohRkBBAE?= =?us-ascii?q?dBgQNVQIBCA4MAiYCAgIwFRACBAESiicIrFKBbDqLXwEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2BC4IdggKBTIFjKwuBZYEMhF0WF4J8MIIxAQSRC48mApQ6gg+FXYN?= =?us-ascii?q?6hm+WFAEfOIEKdxVJEgGHB3aJPoEPAQEB?= X-IronPort-AV: E=Sophos;i="5.41,373,1498521600"; d="scan'208";a="466388478" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Aug 2017 14:47:18 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v7EElIPq028709 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 14 Aug 2017 14:47:18 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 14 Aug 2017 09:47:18 -0500 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1210.000; Mon, 14 Aug 2017 09:47:17 -0500 From: "Clyde Wildes (cwildes)" To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15 Thread-Index: AQHS+qgfFNU1WyBT406RudsboUthDKKD0SUAgAAwdQA= Date: Mon, 14 Aug 2017 14:47:17 +0000 Message-ID: <3660A72B-4169-4577-8AE3-F9DB6EADC0CF@cisco.com> References: <0558E64E-2CE7-4C3E-94C8-1CA7CE78171E@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.131.0] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2017 14:47:22 -0000 S2VudCwNCg0KQ29tbWVudHMgaW5saW5lIGFzIFtjbHlkZV3igKYNCg0KT24gOC8xNC8xNywgNjo1 MyBBTSwgIktlbnQgV2F0c2VuIiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6DQoNCiAgICAN CiAgICANCiAgICA+ICAgIDUuIFMxIGFzIGEgd2hvbGUuICBJJ20gYSBiaXQgdW5jbGVhciB3aGF0 IHRoaXMgc2VjdGlvbiBpcyBkb2luZy4gIEl0DQogICAgPiAgICBzZWVtcyB0byBiZSBhIGdlbmVy YWwgc3VtbWFyeSBvZiBTeXNsb2cgKFJGQzU0MjQpLiAgRG8gd2UgbmVlZCB0aGlzIGhlcmU/DQog ICAgPg0KICAgID4gW2NseWRlXSBTdWdnZXN0aW9ucyBhcHByZWNpYXRlZC4gSSB3YW50ZWQgdG8g cHJvdmlkZSBhIGhpZ2ggbGV2ZWwgb3ZlcnZpZXcNCiAgICA+IG9mIHRoZSBzeXNsb2cgcHJvY2Vz cy4gSSBjbGVhbmVkIGl0IHVwIGEgbGl0dGxlLg0KICAgICANCiAgICBNb3ZlIFNlY3Rpb24gMiB0 ZXh0IHRvIFNlY3Rpb24gMSwgcmVwbGFjaW5nIHRoZSB0ZXh0IHRoYXQncyB0aGVyZT8NCiAgICAN CltjbHlkZV0gd2lsbCBkbyAgICANCiAgICANCiAgICA+ICAgICAgIDEyLiBTMywgUDg6IEknbSBo YXZpbmcgdHJvdWJsZSB1bmRlcnN0YW5kaW5nIHRoZSBwc2V1ZG9jb2RlLiAgV2hhdA0KICAgID4g ICAgaGFwcGVucyBpZiBTIGFuZC9vciBGIGFyZSBub3QgcHJlc2VudD8gIENhbiBTIG9yIEYgZXZl ciBub3QgYmUNCiAgICA+ICAgIHByZXNlbnQ/IC0gbG9va2luZyBhdCB0aGUgdHJlZSBkaWFncmFt LCBpdCBzZWVtcyBsaWtlIHRoZXkgbWlnaHQNCiAgICA+ICAgIGFsd2F5cyBiZSBzZXQgdG8gc29t ZXRoaW5nIGluIHRoZSBtb2RlbC4NCiAgICA+DQogICAgPiBbY2x5ZGVdIFMgb3IgRiBtaWdodCBu b3QgYmUgcHJlc2VudC4gDQogICAgDQogICAgSW4gdGhlIFlBTkcgbW9kdWxlLCBmYWNpbGl0eS1s aXN0IGlzIGtleWVkIGJ5IFtmYWNpbGl0eSBzZXZlcml0eV0sIHdoaWNoDQogICAgbWVhbnMgdGhl IHZhbHVlcyBhcmUgYWx3YXlzIHByZXNlbnQsIHJpZ2h0Pw0KICAgIA0KW2NseWRlXSBUaGVyZSBh cmUgdHdvIHBhdGhzIHNwZWNpZnlpbmcgYSBmYWNpbGl0eS1maWx0ZXIgaW4gd2hpY2ggY2FzZSBT IG9yIEYgYXJlIHByZXNlbnQsIG9yIHNwZWNpZnlpbmcgYSBwYXR0ZXJuLW1hdGNoIGluIHdoaWNo IGNhc2UgdGhleSBtaWdodCBub3QgYmUgcHJlc2VudCBpZiBmYWNpbGl0eS1maWx0ZXIgaXMgbm90 IHNwZWNpZmllZC4gICANCiAgICANCiAgICA+ICAgIDE0LiBTMy4xOiBpcyAvc3lzbG9nL2FjdGlv bnMvcmVtb3RlL2Rlc3RpbmF0aW9uL3Rscy8gbWlzc2luZyBhbg0KICAgID4gICAgJ2FkZHJlc3Mn IGxlYWY/DQogICAgPg0KICAgID4gW2NseWRlXSBub3QgYXMgZmFyIGFzIEkga25vdw0KICAgID4N CiAgICANCiAgICBMb29raW5nIGF0IHRoZSB0cmVlLWRpYWdyYW0sIHRoZSAndGxzJyBjYXNlIGRv ZXNuJ3Qgc2VlbSB0byBoYXZlIHRoZQ0KICAgIGFkZHJlc3Mgb3IgcG9ydCBmaWVsZHMuICBGV0lX LCB0aGUgaWV0Zi10bHMtY2xpZW50IG1vZHVsZSBkb2Vzbid0IA0KICAgIHByb3ZpZGUgdGhlc2Ug ZmllbGRzIHNvIHRoYXQgY29uc3VtaW5nIG1vZHVsZXMgY2FuIGNvbmZpZ3VyZSBhIG5vcm1hbA0K ICAgIGNsaWVudCB2ZXJzdXMgYSBjbGllbnQgbGlzdGVuaW5nIGZvciBjYWxsLWhvbWUgY29ubmVj dGlvbnMuLi4NCiAgICANCiAgICAJICAgKy0tOih0Y3ApDQogICAgCSAgIHwgICstLXJ3IHRjcA0K ICAgIAkgICB8ICAgICArLS1ydyBhZGRyZXNzPyAgIGluZXQ6aG9zdA0KICAgIAkgICB8ICAgICAr LS1ydyBwb3J0PyAgICAgIGluZXQ6cG9ydC1udW1iZXINCiAgICAJICAgKy0tOih1ZHApDQogICAg CSAgICAgICstLXJ3IHVkcA0KICAgIAkgICAgICAgICArLS1ydyBhZGRyZXNzPyAgIGluZXQ6aG9z dA0KICAgIAkgICAgICAgICArLS1ydyBwb3J0PyAgICAgIGluZXQ6cG9ydC1udW1iZXINCiAgICAJ ICAgICAgKy0tOih0bHMpDQogICAgCSAgICAgICAgICstLXJ3IHRscw0KICAgICAgICAgICAgICAg ICAgICAgIDxhZGRyZXNzL3BvcnQgbWlzc2luZyBoZXJlLCByaWdodD8+DQogICAgCSAgICAgICAg ICAgICstLXJ3IHNlcnZlci1hdXRoDQogICAgICAgICAgICAgICAgICAgICAgICAgPG1vcmUgaWV0 Zi10bHMtY2xpZW50IGdyb3VwaW5nIGhlcmU+DQoNCltjbHlkZV0gSGVyZSBpcyB3aGF0IHRoZSB0 cmVlIGxvb2tzIGxpa2UgaW4gdGhlIGxhdGVzdCBkcmFmdOKApg0KDQogICAgICAgICAgICAgICAg ICAgfCAgKy0tOih0bHMpDQogICAgICAgICAgICAgICAgICAgfCAgICAgKy0tcncgdGxzDQogICAg ICAgICAgICAgICAgICAgfCAgICAgICAgKy0tcncgc2VydmVyLWF1dGgNCiAgICAgICAgICAgICAg ICAgICB8ICAgICAgICB8ICArLS1ydyB0cnVzdGVkLWNhLWNlcnRzPyAgICAgICAtPiAva3M6a2V5 c3RvcmUvdHJ1c3RlZC1jZXJ0aWZpY2F0ZXMvbmFtZQ0KICAgICAgICAgICAgICAgICAgIHwgICAg ICAgIHwgICstLXJ3IHRydXN0ZWQtc2VydmVyLWNlcnRzPyAgIC0+IC9rczprZXlzdG9yZS90cnVz dGVkLWNlcnRpZmljYXRlcy9uYW1lDQogICAgICAgICAgICAgICAgICAgfCAgICAgICAgKy0tcncg Y2xpZW50LWF1dGgNCiAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8ICArLS1ydyAoYXV0aC10 eXBlKT8NCiAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8ICAgICArLS06KGNlcnRpZmljYXRl KQ0KICAgICAgICAgICAgICAgICAgIHwgICAgICAgIHwgICAgICAgICstLXJ3IGNlcnRpZmljYXRl PyAgIC0+IC9rczprZXlzdG9yZS9rZXlzL2tleS9jZXJ0aWZpY2F0ZXMvY2VydGlmaWNhdGUvbmFt ZQ0KICAgICAgICAgICAgICAgICAgIHwgICAgICAgICstLXJ3IGhlbGxvLXBhcmFtcyB7dGxzLWNs aWVudC1oZWxsby1wYXJhbXMtY29uZmlnfT8NCiAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8 ICArLS1ydyB0bHMtdmVyc2lvbnMNCiAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8ICB8ICAr LS1ydyB0bHMtdmVyc2lvbiogICBpZGVudGl0eXJlZg0KICAgICAgICAgICAgICAgICAgIHwgICAg ICAgIHwgICstLXJ3IGNpcGhlci1zdWl0ZXMNCiAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8 ICAgICArLS1ydyBjaXBoZXItc3VpdGUqICAgaWRlbnRpdHlyZWYNCiAgICAgICAgICAgICAgICAg ICB8ICAgICAgICArLS1ydyBhZGRyZXNzPyAgICAgICAgaW5ldDpob3N0DQogICAgICAgICAgICAg ICAgICAgfCAgICAgICAgKy0tcncgcG9ydD8gICAgICAgICAgIGluZXQ6cG9ydC1udW1iZXINCiAg ICANCkFkZHJlc3MgYW5kIHBvcnQgYXJlIHRoZXJlLiBQbGVhc2UgY2xhcmlmeSBvbiB3aGF0IHlv dSB0aGluayBpcyBtaXNzaW5nLg0KICANClRoaXMgaXMgd2hhdCBpdCBsb29rcyBsaWtlIGluIHRo ZSBtb2RlbDoNCg0KICAgICAgICAgICAgY2FzZSB0bHMgew0KICAgICAgICAgICAgICBjb250YWlu ZXIgdGxzIHsNCiAgICAgICAgICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAgICAgICAg IlRoaXMgY29udGFpbmVyIGRlc2NyaWJlcyB0aGUgVExTIHRyYW5zcG9ydCBvcHRpb25zLiI7DQog ICAgICAgICAgICAgICAgcmVmZXJlbmNlDQogICAgICAgICAgICAgICAgICAiUkZDIDU0MjU6IFRy YW5zcG9ydCBMYXllciBTZWN1cml0eSAoVExTKSBUcmFuc3BvcnQgDQogICAgICAgICAgICAgICAg ICAgTWFwcGluZyBmb3IgU3lzbG9nICI7DQogICAgICAgICAgICAgICAgdXNlcyB0bHNjOnRscy1j bGllbnQtZ3JvdXBpbmc7DQogICAgICAgICAgICAgICAgbGVhZiBhZGRyZXNzIHsNCiAgICAgICAg ICAgICAgICAgIHR5cGUgaW5ldDpob3N0Ow0KICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24N CiAgICAgICAgICAgICAgICAgICAgIlRoZSBsZWFmIHVuaXF1ZWx5IHNwZWNpZmllcyB0aGUgYWRk cmVzcyBvZiANCiAgICAgICAgICAgICAgICAgICAgIHRoZSByZW1vdGUgaG9zdC4gT25lIG9mIHRo ZSBmb2xsb3dpbmcgbXVzdCBiZSANCiAgICAgICAgICAgICAgICAgICAgIHNwZWNpZmllZDogYW4g aXB2NCBhZGRyZXNzLCBhbiBpcHY2IGFkZHJlc3MsIA0KICAgICAgICAgICAgICAgICAgICAgb3Ig YSBob3N0IG5hbWUuIjsNCiAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgbGVhZiBw b3J0IHsNCiAgICAgICAgICAgICAgICAgIHR5cGUgaW5ldDpwb3J0LW51bWJlcjsNCiAgICAgICAg ICAgICAgICAgIGRlZmF1bHQgNjUxNDsNCiAgICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQog ICAgICAgICAgICAgICAgICAgICJUQ1AgcG9ydCA2NTE0IGhhcyBiZWVuIGFsbG9jYXRlZCBhcyB0 aGUgZGVmYXVsdCANCiAgICAgICAgICAgICAgICAgICAgIHBvcnQgZm9yIHN5c2xvZyBvdmVyIFRM Uy4iOw0KICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgfQ0K DQogICANCiAgICANCiAgICA+IDE5LiBTNC4xLCBpbiB0aGUgJ3NldmVyaXR5LWZpbHRlcicgZ3Jv dXBpbmcsIHdoeSBkb2VzIGxlYWYgJ3NldmVyaXR5Jw0KICAgID4gICAgaGF2ZSB2YWx1ZXMgc2V0 IGZvciBlbnVtcyAnbm9uZScgYW5kICdhbGwnPyAgV2hlbiB3b3VsZCB0aGVzZSB2YWx1ZXMNCiAg ICA+ICAgIGJlIHVzZWQsIGFzIG9wcG9zZWQgdG8gdGhlIGVudW0ncyBuYW1lIHN0cmluZz8gIElm IHlvdSBkbyBuZWVkIHZhbHVlcywNCiAgICA+ICAgIHRoZW4gc2hvdWxkbid0ICdub25lJyBiZSAy MTQ3NDgzNjQ3IChzbyBub3RoaW5nIGNhbiBiZSBncmVhdGVyIHRoYW4gaXQpDQogICAgPiAgICBh bmQgJ2FsbCcgYmUgLTIxNDc0ODM2NDggKHNvIGV2ZXJ5dGhpbmcgaXMgZ3JlYXRlciB0aGFuIGl0 KT8NCiAgICA+DQogICAgPiBbY2x5ZGVdIOKAmG5vbmXigJkgYW5kIOKAmGFsbOKAmSBhcmUgc2V0 IHRvIHZhbHVlcyB0aGF0IGFyZSBub3QgZGVmaW5lZCBpbiANCiAgICA+IFJGQyA1NDI0LiBUaGVz ZSB2YWx1ZXMgd2VyZSBwcmV2aW91c2x5IHN1Z2dlc3RlZCBieSBNYXJ0aW4gQmrDtnJrbHVuZA0K ICAgIA0KICAgIEZpbmUsIGJ1dCBsZXQncyByZS1ldmFsdWF0ZSB0aGUgdmFsdWVzIG5vdy4gIElt YWdlIGhhdmluZyBhIHZhcmlhYmxlIHgNCiAgICBhbmQgc3RlcHBpbmcgdGhyb3VnaCB0aGUgc2Vs ZWN0b3IgbGlzdDoNCiAgICANCiAgICAgIGlmIHggPj0gZmFjaWxpdHktbGlzdC9zZXZlcml0eSB0 aGVuIGZvby4NCiAgICANCiAgICBOb3cgaW1hZ2luZSBpdCByZWFkOg0KICAgIA0KICAgICAgaWYg eCA+PSAnYWxsJyB0aGVuIGZvby4NCiAgICANCiAgICBXaGF0IGludGVnZXIgdmFsdWUgZm9yICdh bGwnIHdvdWxkIGFsd2F5cyBlbnN1cmUgVHJ1ZT8gIE1JTi1JTlQNCiAgICBMaWtld2lzZSwgeW91 IGNhbiBzZWUgdGhhdCBNQVgtSU5UIGlzIHRoZSBiZXN0IHZhbHVlIGZvciAnbm9uZScuDQogICAg DQpbY2x5ZGVdIEkgd2lsbCBiZSBjaGFuZ2UgdGhlc2UgdG86DQoNCidub25lJyAyMTQ3NDgzNjQ3 IChzbyBub3RoaW5nIGNhbiBiZSBncmVhdGVyIHRoYW4gaXQpDQonYWxsJyAtMjE0NzQ4MzY0OCAo c28gZXZlcnl0aGluZyBpcyBncmVhdGVyIHRoYW4gaXQpPw0KDQogICAgDQogICAgPiAgICAyMC4g Uzc6IGNhbiB5b3UgaW5kZW50IHRoZSB0d28gYmxvY2tzIG9mIGRldGFpbHMgc28gdGhlIHdob2xl IHRoaW5nDQogICAgPiAgICByZWFkcyBiZXR0ZXI/DQogICAgPg0KICAgID4gW2NseWRlXSBJIHNl YXJjaGVkIGZvciBhbiBleGFtcGxlIHRoYXQgc2hvd3MgaG93IHRvIGRvIHRoaXMgaW4gWE1MDQog ICAgPiBhbmQgY291bGRu4oCZdCBmaW5kIHRoZSBrZXl3b3JkLg0KICAgIA0KICAgIEFzc3VtaW5n IHhtbDJyZmMgWE1MLCB0aGVuIHlvdSBjb3VsZCBjb252ZXJ0IHRoZSBjb250ZW50cyB0byBhIGZp Z3VyZSwNCiAgICBvciBhIGxpc3Qgd2l0aCBzdHlsZT0nZW1wdHknDQoNCltjbHlkZV0gb2sgSSB3 aWxsIGZvbGxvdyB0aGlzIGFkdmljZSAgICANCiANCg0KVGhhbmtzIGFnYWluIGZvciBhbGwgeW91 ciByZXZpZXcgY29tbWVudHMhDQoNCkNseWRlDQogICAgICANCiAgICBUaGFua3MsDQogICAgS2Vu dA0KICAgIA0KICAgIA0KICAgIA0KDQo= From nobody Tue Aug 15 01:37:40 2017 Return-Path: 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 BE79D132025 for ; Tue, 15 Aug 2017 01:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 1I9oiAF7zfun for ; Tue, 15 Aug 2017 01:37:34 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0109.outbound.protection.outlook.com [104.47.0.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03D73131D27 for ; Tue, 15 Aug 2017 01:37:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8ThdCmZHqtSxNqUDCMXWdH9tGe+l+NSvIvf+BrjuXoY=; b=M5t8641PownBo4FulMMpLEI/qsFclWK0kBJs6u5rYlu79ty5eMTbgglmsTn0UzDXT1P6fi32Imlm6a2ZDIHVU5oSdfn2mSOQp+kVBsCpWGLqg1TsYt5TSOU8xHiofOEjvF4lnW9JKGhLHS6DlnRNVw+oCZKknHCJhvBL+ShcSMs= Received: from pc6 (86.176.21.247) by HE1PR0701MB3002.eurprd07.prod.outlook.com (2603:10a6:3:4d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1362.12; Tue, 15 Aug 2017 08:37:30 +0000 Message-ID: <00b401d315a1$1340ad00$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Clyde Wildes \(cwildes\)" , "Kent Watsen" , References: <91FA5813-8D96-414F-BAC6-BA6C65C5149C@cisco.com> <055c01d31103$28f51200$4001a8c0@gateway.2wire.net> <55F0DA02-0E29-46B6-9F4A-B2525EE3F003@cisco.com> Date: Tue, 15 Aug 2017 09:32:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.176.21.247] X-ClientProxiedBy: DB6PR07CA0151.eurprd07.prod.outlook.com (2603:10a6:6:16::44) To HE1PR0701MB3002.eurprd07.prod.outlook.com (2603:10a6:3:4d::8) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a3bdae37-6b26-4b06-cfd3-08d4e3b8de8e X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 3:z6dxj1SC1pPY2Zvu7bGxJFmOmceIATKllZGRsQNE6alx8ra7jgjPxJKpeN8e6ijQzAE85u1VlliIZDqRjUNLYm/Qc2Ouo1MEVMGW1G8j1K9axDgPRTJwwehNchgSihcGC2X316WhK2sIqjoLhS0rfHy8daZL9RkEylNRJp2z+QhaXz0Auq7a9gsLfoCvEnRZNX8kwahKTxwGvDleYbau1Z0a8Km49z3GdFqDIz1pNv4CFkEUoZWzlXo2g5WL8pws; 25:Kb/1HczYFxO1wnjvTU9ioHO2LLAGzUQ9QO1b7NrmUW/mpzx0r/PIp9n2e8zk7fzGPceTn3qnOKG9R8z9YKJNw8popydcpci2UZ8rUapgFPRG9f1ykWVjzicHBRM7FouWh8awM0dpYPbATQ+dNdaEJvSEO1d39JfsNySREIUta0D2YnHAeOipLSEe9+NHts9xRi9JxX1kns7hVHmDrjQ8l8dkFWpGYi0G0hEHPlGjW4X3WRQ8AFQCQCM4/cfQ6eesKpEAjmxetUXueUzH/WNb+ZNxVlU3mxGyW/N9QFpYfQyMqL6D/RKEYBN26/i4uuCVHlEyqRLbJ1hEVzaZPt2vtw==; 31:iRksnj0SjY7N7k8BJe6v/e33SkRGT+0DZQobjvKGJbiXjPG0fESmR4ZcLxn6B7SobZgdhY1ucYiNLsi9bZNw042aCvfg21y9QZbMeR28wxqLm7OMWtz85Vpy6pWg4WYtiyg3MV1a/08Gb4DGtWLjjTSaaHskpd0ymvzebkz/eXKtlo8imPpqrULwZtJKFADJootACDHJhJbZcer1TuhOxo6XsF/gC71SvpkCXxK9084= X-MS-TrafficTypeDiagnostic: HE1PR0701MB3002: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(192374486261705)(138986009662008)(95692535739014)(17755550239193); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 4:f8LshDA+BJ4Ar4C8SbFwSCi1ErtKQ2ve7xOllftFmcKvMX+T9kaC6LICCEXNC6ZeLHqxRfEMYggHOR5WENZnr/GPC++4DuUNYNTCljR8cC0poVpzAWBog525uucR7LcXOtkjUAuOb4C5yWEHW2hUXHwWXc/VYlbIa2J2SektyLkFbZHjUtIonGcRMgvJUsZ0vS1oqfzOOl2sOdMmM/FwnybtmNy/qwZG+czaNZfXPqmkMuj0leXAmwEd5v3Ula/opIsnImJJwlhKuGdqxri1B0dtWqqD4rk6Wj4mN/LnB6ezkFpW89bwpPkykKPBBlRxTKRd8+yWWjuNlhKRJmyO3EaloVXj9rhHlROdgz0gZKGlQ+RVCufp9kzmEqaHeydgAPWwrRzmZ8CqwJ5jDVpvJVfnw0fyPjayLm1H8je/aZ/n3uKOBpsgjfzj+xm+KZ7F X-Forefront-PRVS: 04004D94E2 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(979002)(6009001)(39860400002)(377454003)(24454002)(13464003)(189002)(199003)(14496001)(68736007)(81166006)(81156014)(81686999)(81816999)(5660300001)(76176999)(8676002)(9686003)(50226002)(50986999)(229853002)(3846002)(101416001)(6116002)(7350300001)(4720700003)(116806002)(189998001)(84392002)(25786009)(6486002)(86362001)(2870700001)(2906002)(8666007)(50466002)(106356001)(1556002)(23676002)(44736005)(230783001)(1941001)(478600001)(62236002)(53936002)(305945005)(6496005)(44716002)(1456003)(47776003)(66066001)(42186005)(105586002)(61296003)(5820100001)(6246003)(7736002)(53546010)(33646002)(97736004)(74416001)(7726001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3002; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3MDFNQjMwMDI7MjM6LzNaUUxsc21KUmN6Zk1FNHMydVB5aWFI?= =?utf-8?B?eHh6aUZESnBLQUNWUzVUMkFIakpWNVpsOXdXcG52T2RzM2c0d0lmU09Oaks1?= =?utf-8?B?N0pqdmpBajJVKyt2ZGxOanBHUlVTekplVnJLMml2Zm1LRWlpVHozdldzN3Bi?= =?utf-8?B?WE90Wk9EQXhZcUxUdWVkc2RBdzlISFZ6Tk9QV3M0Y0JQRjF1OTVhTTRVSDVr?= =?utf-8?B?M29xeDZZNEZxcGllMFNnOXR1UlF4UStkOWpqNk54TnE2SjJ4SnlXQWFMbzg5?= =?utf-8?B?UURYRS9BZGNVSzFzTWZOdXplK3BGUlViMUdrUHM5cm03cUVRdUR1em1tNHBF?= =?utf-8?B?T0xrVFBZK1FZKzBSUm80YmJ5RnVtZnJIYmYzaTlWQnRRYTBLSGVad1FnY2tD?= =?utf-8?B?cVkyNTBhbHFaNk4zeGw2T04rcUxpVGJyazRia3dqTklvU3pUNWk4VWkrbzdr?= =?utf-8?B?Z1dZREdvenA1aVdWYmdMYm1JaUd1MjFzK2h3M3VaVXBqQVpCNHNXbWZ1SXNJ?= =?utf-8?B?cEFqTHFQcFVpaW1jZUlkMWtmMWJzdzhSL0d1cnFTZVlQZDJYQXNycm52a3d1?= =?utf-8?B?MFBic2swbUdNZFlOR0RIclJ3RE1sOVlDSGsrSGVRSlh6YTl5YS9OWlhibTJp?= =?utf-8?B?c0tKSnVmc2dQamdHRG93N3Q5R0p0TWwwQTdqc0krWjZKSE9obk1ORnU0N3pO?= =?utf-8?B?SWJnck1ndFVtR3pRRENURjNsWmZueGVMc0NXd0cvNVVYdjBOWm1wYTBLZUxM?= =?utf-8?B?MU1KZC9vaWc4bnNNandxS1RjckpRL1BlNVA4UEFFMWVJRlozZVAwMVNEYU1J?= =?utf-8?B?aG9DVGpvaW4wcHBNL1JoNGNtbzQyV2NxK0J3VTJlMWxra2JvNUNGYjFEWjZJ?= =?utf-8?B?cDlJVGRjaEFTb1FDd09TNUt2b3h3bmVya1pMRHg4aXZiSEtzUVg1WTV0L3Np?= =?utf-8?B?S3ZRTElvOU9kRDBtT3ZHbFEveTJyYUg0dkIxSnRSL0x4dzBtTGhBYXRHNitI?= =?utf-8?B?QmNhN21ZcDZnSDZIV0RickJGWGhPYzFrRmdjbU8xaTV2aCtwck1LMDlxRTRE?= =?utf-8?B?YUkybm5LcnVBOEI3Y2xieC9HdHRSSlp3QlhGMkJqQnJJV2YwblRyYjJOb2FR?= =?utf-8?B?Ulp1RnpvOGRWRytWVHM5MHRybk9reUwyZ1h6S2tqTDJ5MGM4REg0NGM3citp?= =?utf-8?B?Z0U4cDVoM3c2bHVwMlVjNU40U2pEN0JxRWFYVHFRRk5GdWpBQ0k5UGVFaFNp?= =?utf-8?B?d1JSOWs4WU1mTlFtMEl3ZjV0T0dKZ2s1VVZSbDZSemxKTFVLanlmVE5uK1hB?= =?utf-8?B?MC9oRnUxQm85Tkd1dU44RWJFZUE4RFAzWGhxbTNuY2JMQ0NnT0F0MXdkcTNz?= =?utf-8?B?VjBMRjF0U2lkUFY0RE44empTWXAraDhwSjlDS3ZFRTd5MDA1MURvZlVwaFpO?= =?utf-8?B?ZTV0R3VOdEFqTE1UcmY3UmsvYW54bEFEWlNvVXZIbXVDRytrMjdlUEIyK2Nj?= =?utf-8?B?VTBnUURMbHZnVGlDRGdYbkZFYlVqd1ZQd21Tc2pVcVdxZ2Y0ZFNKSStFb3hl?= =?utf-8?B?dTYyVW5OM0lhODI0M1ZSS085RGYyWWVnOWdKMm9WWUJzOEJldTJ5ZC9hanov?= =?utf-8?B?VkdFQnJoUnp0eWg4d1lqcnFwSG1ybUxMQTBHTklMM3ZwcnVYT0NRSzNTWlNn?= =?utf-8?B?SkpLNUxhK3UyVDdXWmMrQ1pyM0lDcXd0MWlxOWpLTGE4ZHM4cXBJazNuaUxX?= =?utf-8?B?TnZVME54TkwrVlJENThWTmRwci9uZkdzLzU3SlhSL01wMUdVU1pJWW5mSVYy?= =?utf-8?B?Q2pWei9RUmVVd3dUajVCVGdhd2d6QXN6d2hTZ2NzemdSeVBFVWF2dUpUeHhy?= =?utf-8?B?eS9zNVdxQkdrUEszN1p2azd1aGxSclNpcjJ3ZzhRTytmYU5Zd3JyRytjMFhi?= =?utf-8?B?VmNQeUY4M0YyUGZPcE02bFVCWmdMakNDdkR6Yjg3S3FiWnlqNktpV0U3Zjdh?= =?utf-8?B?UkFyUUFubXplM2JyNXFxTHNJeDR6VFBCUXdkRVZac3FFMnBGQ0JDMGRwR2FB?= =?utf-8?B?MVVmT3J3Tm5GY0NFMU9BcDduZ0hqU2d6UHpUOWVMVFFQSFpzUGU3UVRKMWts?= =?utf-8?Q?HhwlJRsjT4gEJ59zxz4y7fwjM=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:stZW7SVhui1SKL+CfbqGhPpfrJVu0kiMvIGahVriqix3sWJAc5XJLSGP9oUI7lLtnZYMzmBu4itCqwCXZsQea0F+HHlZBXpt0O/+yjYKVACRhkKxn7mLWA57f4V19QtVWYtCQ2Hi6ZMXWv3gI5Bysond9pdGHJAimHBqWnIDGpiwPrPjmwmcgICH0nFUQgqvrsb9a36tjwvCsaL9nzbWhHR0YtOllgdBKBaDaXKZaUclKnjvTJnyJClwXsy40+qyD8ETww4QI7v//Tt5rgRTpn4YA/hTSUSgRXzjgESPr8gHWKdEvKRwHvkYJyX2hHcfXbWVa3dPyOX8rgn/UONgWg==; 5:LfR0hOPPCaDHRdU9Ap41zHU21ksaWesHCqoR6gYa/lxqsGZ0wHEKGgOcPQb+B35Q908NHb+RiTe/0jNdXG/R9TskK5AGGKhyQoW9poEV5FdfTBbRQdv72B4Faw9C6C2oy5wEnFgKgrrncTn5303Jtg==; 24:i9NMgwJap+qmXD3dnWi8IxL0jhwkB6XZkkVoyOvFjsF91qpmxWCVmqbh/3eFtKnw5/OZWvIpzDj1pSZwV0SSGCO+o8Z1xX0HO2JErcWxtZg=; 7:rFjifxtHGhEVwPYXDOCb9WVm+k4rlFdZOQqcGfY6V7W4YWeY3wetFpWtTNL5SDV+O2YUndNx+HxJlTY6uJe5Gq0nAIl5OgHTxnZc5ZjotWrU66ASRJJ9FIDRPKFRTVUnPH0fPPVHnQNvFjBD1qC/dKBcAGMySTibdxSqBY6XMdQGku9tee09hQsF1hDUlhmzrzN3Xf3eTD9v5S38d/977HJh721q77FFy7OzoyLrf5Y= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Aug 2017 08:37:30.8036 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3002 Archived-At: Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15 references X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 08:37:39 -0000 Clyde What concerns me most is that AFAICT anything that is referenced in a YANG module is a Normative Reference in the RFC that defines it and you do not have those two I-D in the list of references. Since they have not been published, then they would appear as I-Ds in the references and the RFC Editor knows to on the one hand, hold up the publication of the referring I-D until until the references become RFC, and on the other hand insert the RFC number when they do. I note that in other modules, I see no RFC for an import. Strictly one is not needed since the name should be unique and can be derefenced but it is nice to have (SNMP usually has it). But as I say, it is the lack of Normative Reference that worries me most. Tom Petch ----- Original Message ----- From: "Clyde Wildes (cwildes)" To: "t.petch" ; "Kent Watsen" ; Sent: Wednesday, August 09, 2017 5:53 PM > Tom, > > The agreement was that I should use “xxxx” until the two unapproved RFCs that the model depends on are assigned numbers. > > RFC xxxx: Keystore Management > RFC xxxx: Transport Layer Security (TLS) Client"; > > Imported are: > > import ietf-tls-client { > prefix tlsc; > } > > import ietf-keystore { > prefix ks; > } > > > Have numbers been assigned? > > Thanks, > > Clyde > > On 8/9/17, 4:32 AM, "t.petch" wrote: > > Clyde > > You use xxxx as a placeholder for three different RFC and two of these > do not appear AFAICT in the list of References. > > This might be a challenge for the RFC Editor. > > Tom Petch > > > ----- Original Message ----- > From: "Clyde Wildes (cwildes)" > Sent: Wednesday, July 19, 2017 6:48 PM > > > > Hi Alex, > > > > Answers inline as [clyde]… > > > > On 7/17/17, 4:20 PM, "netmod on behalf of Alex Campbell" > wrote: > > > > I am considering to implement the data model in this draft. > (dependent on business priorities of course) > > I have reviewed this draft and found the following issues. > > > > * I see pattern-match is specified to use POSIX 1003.2 regular > expressions. This is presumably for compatibility with existing > implementations; however it is inconsistent with most of YANG (which is > specified to use XPath regular expressions) - unless these are the same. > > > > [clyde] I believe that my answer in the other thread explains why we > used Posix 1003.2 – it is commonly used. > > > > * pattern-match is inside the facility-filter container; common > sense says this is wrong as pattern-match has nothing to do with > facilities. > > > > [clyde] I will move pattern-match up one level in the next version of > the draft. Thanks for catching this! > > > > * The advanced-compare container groups together two nodes that > share a common "when" and "if-feature" statement, but don't seem to have > any semantic relation to each other. Are there general guidelines on > when to use a container? > > > > [clyde] The confusion may come as a result of the when clause > appearing before the if-feature clause which is set by the IETF > statement order recommendation. > > > > The when construct was suggested by Martin Björklund as a way of > solving the case that advanced-compare does not apply for the ‘all ’ and > ‘none’ case. > > > > The if-feature applies to the entire container – it is either > supported or not. > > > > * The advanced-compare container has a description starting with > "This leaf ..." even though it is not a leaf. > > > > [clyde] This will be fixed in the next draft. > > > > * The examples are missing nodes. > > > > [clyde] This will be fixed in the next draft. > > > > * Perhaps there should be more consistent terminology for > receivers of syslog messages; both "collectors" and "actions" are used > in the draft. RFC 5424 uses "collector" for the ultimate recipient of a > log message - which might not be applicable, because the sending system > has no idea whether the receiving system is a collector or a relay. > > > > [clyde] The definition of “collector” in RFC 5424 is: A "collector" > gathers syslog content for further analysis. > > > > actions relate to the “further analysis” taken by the “collector”. > > > > “Collectors” appears in the model under the remote action and I > believe the usage is correct: > > container remote { > > if-feature remote-action; > > description > > "This container describes the configuration parameters for > > forwarding syslog messages to remote relays or > collectors."; > > > > I will revise the description of these terms in the next draft. > > > > Thanks, > > > > Clyde > > > > ________________________________________ > > From: netmod on behalf of Kent Watsen > > > Sent: Saturday, 8 July 2017 6:34 a.m. > > > > From nobody Thu Aug 17 02:31:58 2017 Return-Path: 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 2FD4413247A for ; Thu, 17 Aug 2017 02:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 lYTDo2PQ2RMX for ; Thu, 17 Aug 2017 02:31:53 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0117.outbound.protection.outlook.com [104.47.2.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A981413248B for ; Thu, 17 Aug 2017 02:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ItPnbVGoZPcjDPUkNDP6fK81rA6FA4qLyWxzL6BpYmw=; b=keJBks41jYfDoTybGRi6HaEw0BPj9N2l1UTX7PgTuBgn0hEX6BdlAoZz9CwC1WxQbxqOzuapVAW8tf41hY/IT4Y+9xAQQniPdkrPmpdMvQBgAo5w0Sx+WFw90yBgzt3Ag2kyKkdQiGHR4eP/ZylmKb7vCffEFUEEnJNYgIdQt7s= Received: from AM2PR07MB0627.eurprd07.prod.outlook.com (10.160.54.154) by AM2PR07MB0690.eurprd07.prod.outlook.com (10.160.56.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1362.12; Thu, 17 Aug 2017 09:31:48 +0000 Received: from AM2PR07MB0627.eurprd07.prod.outlook.com ([fe80::182e:6400:46fc:f36e]) by AM2PR07MB0627.eurprd07.prod.outlook.com ([fe80::182e:6400:46fc:f36e%13]) with mapi id 15.01.1362.018; Thu, 17 Aug 2017 09:31:48 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: "netmod@ietf.org" CC: "Pauwels, Ludwig (Nokia - BE/Antwerp)" , "joey.boyd@adtran.com" Thread-Topic: What is the best way to HW identities Thread-Index: AdMXOxJtbuifQeSdR6iiACPpuek3uw== Date: Thu, 17 Aug 2017 09:31:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.245.212.3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0690; 6:t82klX3qG5BdsvEWxR3VspSqfoRXpa1+rXDbvC9ZoGUtzKvzdfGP32NJCZsgDu6mqsDaWaVIZgL/VlX3FtM1tuTvAyXCfDnOaYzWKRhOvMylQQYCJUXUSX0cBQ4J+fk0M0SRpCTQvg89VaolhMuwlunqV/uua6e//Wkm1cT3FbPpDF4u2xN+M43ZBm+x0UdUfZP0v8d/opO5zXvuLeDd4Nr3YDuRvYGG4xt5B4PWu59kPWrT4IEeskQOXEvNVzuo3Sue0o/EQH936nYw8pNpYF1SThTO+YppJ07TmiMuE9JWo95URFls85Lm0Pm4zRsf9gP0iQIS/KEjZEXXxZGwKw==; 5:0BlEH+iEhps6Xn4yFfYJuvB6DSVcyWzVQiis4MzGnXFkusbtkL47b2rEUVabr/bAOdlfjR5QcSXbe1+KmMcjT/kQuJhF1GAhDDL+qbXj7NkfJLB0ooG+6b4hYs/mWQAeah3UJBRVx9C2Mi0aMhGiug==; 24:fENqkrAeakhzn5c1K3glfl2BB9RSKfWTNXs5F5EOeKv7UHfBi6AXyMQmVLjAu8kamAMNwdhGmNm1NF1IPC+avf/04ULt4S+G7ukBlD5tKPI=; 7:ZGzhIE2zXFURszZS7QipnYQcrqaMXRL//8wy+BqyxiFJRT5YboTIXMbUTadcS0otn0RsjO67zHMqC0tCwOBtAQ1p/XGPZN1F7DjGdUbTVb8mlFXi6L+FmxPAfK//tqiO4eCOLBF3xOUXIIjL1wNq5z/JNQhowOIJTWYcPk7fcgQkaZSWdxWjnSOy41nn4fvuxRK9MuFZDSu8dcKRpz3iKGw78ACNTDmIizB3DrqfZw8= x-ms-office365-filtering-correlation-id: 04c25d28-b9dc-4430-b2dc-08d4e552c8d9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603157)(49563074)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM2PR07MB0690; x-ms-traffictypediagnostic: AM2PR07MB0690: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; x-exchange-antispam-report-test: UriScan:(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0690; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0690; x-forefront-prvs: 0402872DA1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(199003)(189002)(5660300001)(6506006)(106356001)(5640700003)(8936002)(101416001)(50986999)(66066001)(54356999)(53936002)(99936001)(25786009)(74316002)(3280700002)(68736007)(9326002)(2906002)(5630700001)(3660700001)(6436002)(33656002)(54896002)(8676002)(99286003)(54906002)(81166006)(14454004)(55016002)(6306002)(1730700003)(9686003)(81156014)(4326008)(2351001)(105586002)(97736004)(110136004)(7696004)(6916009)(5250100002)(86362001)(189998001)(2900100001)(2501003)(3846002)(6116002)(7736002)(478600001)(790700001)(102836003)(43043002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0690; H:AM2PR07MB0627.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02DE_01D3174C.64A19220" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2017 09:31:48.4750 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0690 Archived-At: Subject: [netmod] What is the best way to HW identities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 09:31:56 -0000 ------=_NextPart_000_02DE_01D3174C.64A19220 Content-Type: multipart/alternative; boundary="----=_NextPart_001_02DF_01D3174C.64A19220" ------=_NextPart_001_02DF_01D3174C.64A19220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, Within BBF we have had a discussion on the use of draft-ietf-netmod-entity-03, and we would appreciate to hear the opinion of IETF. More specific the discussion is on the use of the leaf 'class' and the leaf 'parent-rel-pos'. First some BBF context: - the systems for which BBF specifies YANG models can be built with various 'types of hardware', e.g. as pluggable item (module) it can contain boards and it can contain SFP/XFPs. As 'type of port' it can have connectors to terminate fastdsl links (supported over copper wires), and it can have positions to insert optical fibers (e.g. the position in the SFP in which one can plug the optical fiber). - in the data model we have the need for some conditional data: e.g. an SFP/XFP has some data that is defined in SFF-8472. This data is not applicable to boards. Hence we need to distinguish between these 2 types of pluggable items. A 2nd example: for the optical fibers terminated by an SFP/XFP, we have specific data that is also defined in SFF-8472, e.g. the wavelength. This data is not applicable to fastdsl ports. On fastdsl ports we have specific data that relates to remote power feeding. Obviously there is no power feeding over the optical fiber. There might be other ports with (for now) no specific data, e.g. an rj45. Conclusion: need data conditional to the port type. In draft-ietf-netmod-entity-03 we read - "The "class" leaf is a YANG identity that describes the type of the hardware. Vendors are encouraged to either directly use one of the common IANA-defined identities, or derive a more specific identity from one of them. - As description for 'parent-rel-pos': "An indication of the relative position of this child component among all its sibling components. Sibling components are defined as components that share the same instance values of each of the 'parent' and 'class' nodes. Based on what we read in the first bullet a thought was to specialize the various hardware-class identities. Examples: identity board { base ianahw:module; description "A board is a special type of module that represents a physical item, commonly known as a board or a card."; } identity transceiver { base ianahw:module; description "A transceiver is a special type of module that represents a physical item like a pluggable SFP, an SFP+, or an XFP; or a soldered SFF."; } identity transceiver-link { base ianahw:port; description "A transceiver-link is a special type of port that terminates an optical fiber."; } identity rj45 { base ianahw:port; description "A RJ45 is a special type of port that terminates an electrical Ethernet link."; } identity fastdsl { base ianahw:port; description "A fastdsl is a special type of port that terminates a copper wire supporting a FAST or one of the DSL types link."; } The intention with this approach: the 'class' leaf is used to distinguish between all types of hardware. If hardware specific data is augmented to the hardware model, then it is using a 'when' condition referring to the value of the leaf 'class'. Based on the description of the parent-rel-pos it is understood that the value of this leaf is relative to the value of the class, so numbering of e.g. the various types of port supported by one board is independent of each other. Then the worry starts: - some of the BBF members understand this concept of specializing the hardware identities and use these values for the leaf class as the way to go, and take the impact on the numbering as a given. - Others think this impact on the parent-rel-pos is not the intention and assume a flat numbering of all childs within a parent, hence do not want to use the class leaf for further specialization, hence want to introduce a new separate leaf to contain the more detailed information, hence the conditional data for the various types of hardware shall be defined with a 'when statement' referring to this new separate leaf. The feedback we would appreciate from IETF: - did IETF consider the need for additional conditional data? - which approach is the IETF preference? - in case the IETF preference is to specialize the hardware identities, does IETF think it is worth to standardize them in IANA, or is the preference to keep these identities within BBF? Regards, Bart ------=_NextPart_001_02DF_01D3174C.64A19220 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Within BBF we have had a discussion on the use of = draft-ietf-netmod-entity-03, and we would appreciate to hear the opinion = of IETF. More specific the discussion is on the use of the leaf 'class' = and the leaf 'parent-rel-pos'.

 

First some BBF = context:

- = the systems for which BBF specifies YANG models can be built with = various 'types of hardware', e.g. as pluggable item (module) it can = contain boards and it can contain SFP/XFPs. As 'type of port' it can = have connectors to terminate fastdsl links (supported over copper = wires), and it can have positions to insert optical fibers (e.g. the = position in the SFP in which one can plug the optical = fiber).

 

- in the data model we have the need for some conditional = data: e.g. an SFP/XFP has some data that is defined in SFF-8472. This = data is not applicable to boards. Hence we need to distinguish between = these 2 types of pluggable items. A 2nd example: for the optical fibers = terminated by an SFP/XFP, we have specific data that is also defined in = SFF-8472, e.g. the wavelength. This data is not applicable to fastdsl = ports. On fastdsl ports we have specific data that relates to remote = power feeding. Obviously there is no power feeding over the optical = fiber. There might be other ports with (for now) no specific data, e.g. = an rj45. Conclusion: need data conditional to the port = type.

 

In draft-ietf-netmod-entity-03 we = read

- = "The "class" leaf is a YANG identity that describes the = type of the hardware.  Vendors are encouraged to either directly = use one of the common IANA-defined identities, or derive a more specific = identity from one of them.

 

- As description for = 'parent-rel-pos': "An indication of the relative position of this = child component among all its sibling components.  Sibling = components are defined as components that share the same instance values = of each of the 'parent' and 'class' nodes.

 

Based on what we read in the first = bullet a thought was to specialize the various hardware-class = identities. Examples:

 

  identity board {

    base = ianahw:module;

    description

      = "A board is a special type of module that represents a physical = item, commonly known as a board or a = card.";

  }

 

  identity transceiver {

    base = ianahw:module;

    description

      = "A transceiver is a special type of module that represents a = physical item like a pluggable SFP, an SFP+, or an XFP; or a soldered = SFF.";

  }

 

  identity transceiver-link {

    base = ianahw:port;

    description

      = "A transceiver-link is a special type of port that terminates an = optical fiber.";

  }

 

  identity rj45 = {

    base = ianahw:port;

    description

      = "A RJ45 is a special type of port that = terminates an electrical Ethernet link.";

  }

  identity fastdsl = {

    base = ianahw:port;

    description

      = "A fastdsl is a special type of port that terminates a copper wire = supporting a FAST or one of the DSL types = link.";

  }

 

The intention with this approach: the 'class' leaf is used = to distinguish between all types of hardware. If hardware specific data = is augmented to the hardware model, then it is using a 'when' condition = referring to the value of the leaf 'class'.

 

Based on the description of the = parent-rel-pos it is understood that the value of this leaf is relative = to the value of the class, so numbering of e.g. the various types of = port supported by one board is independent of each = other.

 

Then the worry starts:

- some of the BBF members = understand this concept of specializing the hardware identities and use = these values for the leaf class as the way to go, and take the impact on = the numbering as a given.

 

- Others think this impact on the = parent-rel-pos is not the intention and assume a flat numbering of all = childs within a parent, hence do not want to use the class leaf for = further specialization, hence want to introduce a new separate leaf to = contain the more detailed information, hence the conditional data for = the various types of hardware shall be defined with a 'when statement' = referring to this new separate leaf.

 

The feedback we would appreciate = from IETF:

- did IETF consider the need for additional conditional = data?

- = which approach is the IETF preference?

- in case the IETF preference is to = specialize the hardware identities, does IETF think it is worth to = standardize them in IANA, or is the preference to keep these identities = within BBF?

 

Regards,

Bart

------=_NextPart_001_02DF_01D3174C.64A19220-- ------=_NextPart_000_02DE_01D3174C.64A19220 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT 8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0 MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0 QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7 GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9 xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE 7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/ PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ 88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo +lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5 JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL 6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45 qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6 eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO 5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74 4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0 MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB 0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt 9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH 9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI /fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos 2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P /jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO 0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MTcwOTMxMzlaMCMGCSqGSIb3DQEJBDEWBBRFFSF8 8sPn2oPbOT9IPGUre+zIozCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9 xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAJ/PGyh4yJjHqDGA6olGWRpEYzvsQ98S412pmpWmQoh8QafwhhhkVlkNc+aG u9PJiOH1lMaCXWNYv/F9wLJgnwYAbxOEza+smJW0SlQgF/u0qxPfxCaIttpaQrlq2FxgfeRRW1KX e0okITSL5NXzy2dJUTSPlS4RasFKFTnnnW8vXZ9ZQm6Y4Rsr/QyQB5t07BxUfn+2yz3EIjkMkQJW zTb0TZ2zqUHZzHIBWbuX20cpjqklBQr3n27NlgkBtOh81LI0hR/joyOWh+L+peHe4mnck7doQAAj f74HUBt6g8IkjHuqROO9tQb3liUfNAnxeuhwe1YKFueZY+XLueRVgQsAAAAAAAA= ------=_NextPart_000_02DE_01D3174C.64A19220-- From nobody Thu Aug 17 04:03:57 2017 Return-Path: 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 490B01200B9 for ; Thu, 17 Aug 2017 04:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 cSfHB_gVFwjA for ; Thu, 17 Aug 2017 04:03:53 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E7892124207 for ; Thu, 17 Aug 2017 04:03:52 -0700 (PDT) Received: from localhost (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id D34E71AE01AA; Thu, 17 Aug 2017 13:03:51 +0200 (CEST) Date: Thu, 17 Aug 2017 13:02:22 +0200 (CEST) Message-Id: <20170817.130222.702011777700824230.mbj@tail-f.com> To: bart.bogaert@nokia.com Cc: netmod@ietf.org, joey.boyd@adtran.com, ludwig.pauwels@nokia.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] What is the best way to HW identities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 11:03:55 -0000 Hi, "Bogaert, Bart (Nokia - BE/Antwerp)" wrote: > Hello, > > > > Within BBF we have had a discussion on the use of > draft-ietf-netmod-entity-03, and we would appreciate to hear the opinion of > IETF. More specific the discussion is on the use of the leaf 'class' and the > leaf 'parent-rel-pos'. > > > > First some BBF context: > > - the systems for which BBF specifies YANG models can be built with various > 'types of hardware', e.g. as pluggable item (module) it can contain boards > and it can contain SFP/XFPs. As 'type of port' it can have connectors to > terminate fastdsl links (supported over copper wires), and it can have > positions to insert optical fibers (e.g. the position in the SFP in which > one can plug the optical fiber). > > > > - in the data model we have the need for some conditional data: e.g. an > SFP/XFP has some data that is defined in SFF-8472. This data is not > applicable to boards. Hence we need to distinguish between these 2 types of > pluggable items. A 2nd example: for the optical fibers terminated by an > SFP/XFP, we have specific data that is also defined in SFF-8472, e.g. the > wavelength. This data is not applicable to fastdsl ports. On fastdsl ports > we have specific data that relates to remote power feeding. Obviously there > is no power feeding over the optical fiber. There might be other ports with > (for now) no specific data, e.g. an rj45. Conclusion: need data conditional > to the port type. > > > > In draft-ietf-netmod-entity-03 we read > > - "The "class" leaf is a YANG identity that describes the type of the > hardware. Vendors are encouraged to either directly use one of the common > IANA-defined identities, or derive a more specific identity from one of > them. > > > > - As description for 'parent-rel-pos': "An indication of the relative > position of this child component among all its sibling components. Sibling > components are defined as components that share the same instance values of > each of the 'parent' and 'class' nodes. > > > > Based on what we read in the first bullet a thought was to specialize the > various hardware-class identities. Examples: > > > > identity board { > > base ianahw:module; > > description > > "A board is a special type of module that represents a physical item, > commonly known as a board or a card."; > > } > > > > identity transceiver { > > base ianahw:module; > > description > > "A transceiver is a special type of module that represents a physical > item like a pluggable SFP, an SFP+, or an XFP; or a soldered SFF."; > > } > > > > identity transceiver-link { > > base ianahw:port; > > description > > "A transceiver-link is a special type of port that terminates an > optical fiber."; > > } > > > > identity rj45 { > > base ianahw:port; > > description > > "A RJ45 is a special type of port that terminates an electrical > Ethernet link."; > > } > > identity fastdsl { > > base ianahw:port; > > description > > "A fastdsl is a special type of port that terminates a copper wire > supporting a FAST or one of the DSL types link."; > > } > > > > The intention with this approach: the 'class' leaf is used to distinguish > between all types of hardware. If hardware specific data is augmented to the > hardware model, then it is using a 'when' condition referring to the value > of the leaf 'class'. > > > > Based on the description of the parent-rel-pos it is understood that the > value of this leaf is relative to the value of the class, so numbering of > e.g. the various types of port supported by one board is independent of each > other. > > > > Then the worry starts: > > - some of the BBF members understand this concept of specializing the > hardware identities and use these values for the leaf class as the way to > go, and take the impact on the numbering as a given. > > > > - Others think this impact on the parent-rel-pos is not the intention and > assume a flat numbering of all childs within a parent Good point. In the original model (i.e. the MIB), with fixed values for the class, having separate numbering schemes for separate classes makes sense. For example, if a certain board has a set of ports, some fans and a power supply, it makes sense that these are numbered individually. However, with specialized ports, this may or may not make sense. It might be possible to define parent-rel-pos in a way that gives the implementation some flexibility. For example, all ports could share the same numbering scheme. The important thing in the current model is that there must not exist two components with the same values for 'parent', 'class', and 'parent-rel-pos'. (strictly speaking, there is no requirement that the parent-rel-pos is always monotonically increasing amongst siblings, so maybe this is possible even today) > , hence do not want to > use the class leaf for further specialization, hence want to introduce a new > separate leaf to contain the more detailed information, hence the > conditional data for the various types of hardware shall be defined with a > 'when statement' referring to this new separate leaf. > > > > The feedback we would appreciate from IETF: > > - did IETF consider the need for additional conditional data? Yes, the idea was to use the 'class' leaf for this. > - which approach is the IETF preference? I would prefer to see if we can find a definition of parent-rel-pos that makes numbering work better so that the 'class' identity can be used for specialization. > - in case the IETF preference is to specialize the hardware identities, does > IETF think it is worth to standardize them in IANA, or is the preference to > keep these identities within BBF? I don't know the answer to this question, but if we want to allow for standardized sub-classes, we have to create a new IANA registry (or extend the current one), since the current one only contains the top-level class (hmm, I just realized that the document needs an updated IANA considerations section anyway; it needs to mimic RFC 7224 -- probably needs to create a common registry for hardware types from which the MIB and YANG module can be generated) /martin From nobody Thu Aug 17 04:56:10 2017 Return-Path: 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 DA0901321B0 for ; Thu, 17 Aug 2017 04:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com 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 Xc--4zAbKXJX for ; Thu, 17 Aug 2017 04:56:05 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10125.outbound.protection.outlook.com [40.107.1.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 286121204DA for ; Thu, 17 Aug 2017 04:56:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZcCu/WzY8HOhASVnEcq375pw/ML4P0E5kKD2DmqlOpg=; b=XnJfxWYSETMZBRAo1e13sWtjFTLWsrIultpcVMNp4eFLSkkNr3On/PFGUy+JQn3PZJrIG03HMhvJ1P5pgUKXIYOapnqKCieYH8uVwrtNmgzdQGRexMHa3SGLtODm8gLpNyMh4fLrQyNY8CUZjEPflXD4Pnnd8Sx92bDL3eBtCWg= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.176.11.51) by DB6PR0701MB2997.eurprd07.prod.outlook.com (2603:10a6:4:73::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1362.12; Thu, 17 Aug 2017 11:56:00 +0000 Message-ID: <05fd01d3174f$aac0e5a0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "\"Clyde Wildes \(cwildes\)\"" Cc: , "\"Kent Watsen\"" References: <150250423969.24551.6610594688078341933@ietfa.amsl.com> Date: Thu, 17 Aug 2017 12:54:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.176.11.51] X-ClientProxiedBy: AM3PR03CA0062.eurprd03.prod.outlook.com (2603:10a6:207:5::20) To DB6PR0701MB2997.eurprd07.prod.outlook.com (2603:10a6:4:73::7) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e72c59f3-9dd3-4ab9-0b96-08d4e566edf9 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB6PR0701MB2997; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 3:fcPD8+6RmfNA0fTOMCIttXW6I5kJ15YGshcaGRss94vQ/PJTq92OUsGZ3gxpUzTbPsptjCHnjNEBFDZBDpWlxkkKyrBlx84fis4oB/gH3tyhmcVprwIMKFHWtPhkDfYkmUK7rD8NTDtWFvYzN22NlK+5+qdACNqBgyDDgiA1rNo2uRwXh83eQANBMz7KgJHXMKhRcwx/xSjoSsgq6GCRduqHPdJKWZfBil6+Y5BznBJxlPK9xtmELbbQts/sGUEi; 25:M0+7kzIYYlubplWWwcbwswG++GhGtREsCkeFS5Z8spXGnjgBdH1d78jZCeJHES5qH/x0KsanYFGKaHAKz1pBpZLskdN/wcnyftJn8McgGvVopsEmSGUWhaIsfher5XQK7fQ86PY9PEmWqufmuVQ2yK/FijNdO5emxvGplZPG+tWYz41GnoymNSXGjeO5c3sGFvfX+ajeoAfIvvhXvEnnEQ7sYzCfe8JjDRZCbeQ/5vq1cLm+XheUQ27rdX6vY8/hVNqrpb/vBEsO/F/EZ7PBHTEzWFdS86YhDUsLv7GGA03rPczsACbUig94I/E+BJMed6Akuw1urAE+w0aA5Tk0kw==; 31:IoEU9beYBdlQlZ3PN+nxWZ8zwuvlxSDviGP+cdixXxta59uDHC6Nld8ypeOvcCGOd/A+WKV6LHS3Ea+nPKTrpwjSGD+qU9D64WpVhUEhcGFqSbNOTPNKngzcSVZi6wK0FCkGJ35HrskenYPxmYqjq/4JPe/+T9JwBzSh38KBRn2o70cSAImKgeqoA2oOUc0cGN0RrpvGLWWlaNmn99OMyoAAIrjop8mFpnTklz/5e0c= X-MS-TrafficTypeDiagnostic: DB6PR0701MB2997: X-Exchange-Antispam-Report-Test: UriScan:(120809045254105); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0701MB2997; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0701MB2997; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 4:XYIyhERGOf5PAnbk3v0Uy5IPDKSiBDoC48EHwaMEpqacJtWEc6xaIZZ38qF1C5Cz1ljcjlodZeoUSz0PPDxoV0BI7ev/ZYqYf9X50zQESv0LAwO05nJ+Ua4Ieh+kmfXAQcgGjWVZj5JXUpUPmqFbDM7G1e9tCG7O8csdOppuPXCsxuypUV3ibjAJfopY5U9YlxhObSY+VpDeA/IRALz4mh5A5IEMUHO0WNx9+skw6/Q3Blehsko/lcZ/ayJUyU/JAMuv2Mhuq2/5tBMmJ/MSxc0A1iYWhclPS3wcXHo8Hq8= X-Forefront-PRVS: 0402872DA1 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6009001)(39860400002)(377454003)(377424004)(13464003)(51444003)(199003)(189002)(9686003)(44736005)(76176999)(50986999)(54906002)(478600001)(6306002)(6486002)(7350300001)(106356001)(14496001)(1456003)(6246003)(5660300001)(229853002)(6666003)(6916009)(110136004)(4720700003)(33646002)(8666007)(6496005)(101416001)(25786009)(1556002)(53936002)(81686999)(81816999)(4326008)(966005)(42186005)(189998001)(68736007)(97736004)(61296003)(3846002)(6116002)(8676002)(81156014)(81166006)(305945005)(2906002)(86362001)(84392002)(50226002)(105586002)(23756003)(230783001)(116806002)(44716002)(62236002)(66066001)(7736002)(230700001)(47776003)(50466002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2997; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB6PR0701MB2997; 23:6QEkuZdC52+pdz22iJn7jxYvyJBmbpUkIKp1K?= =?iso-8859-1?Q?gOgBANlD73POR4i10pJJg8U665VZw4niAm6BBQ7/X7V7kXOHLrTKWWEOmm?= =?iso-8859-1?Q?Y/nX7k9dhgBsBIbWERbAna0oVOSz5HJr9+nF4XfhSmfeOb+jbnBf7chykV?= =?iso-8859-1?Q?5mScRKYCPXOAHtf1Hl87mOAghJRulTnpq2xsolt7InbGPOZvDdFnSMeNY0?= =?iso-8859-1?Q?vvvAHhQhQLqGklZ4mQzRQ29ER2OqPgI1I3xizu1fjyIZXGLVcy1pj+RFpS?= =?iso-8859-1?Q?3Bdxp8RMGB5oi2KTqXZbTx0LVO25OueLIBBxFWrjWFZg1u3hlDb5ULBQoG?= =?iso-8859-1?Q?UTaxFXvsuP/z69xXk7HxcD6C1R5NLad8PTXG5SmBkksNOwteU4of8HCMTI?= =?iso-8859-1?Q?m9UsvSBFT2YumghOwhpM0sByLyl9PkRIpYv8TSJmW41NcsTJSW9lwosUfL?= =?iso-8859-1?Q?CavIo+T/F3Lcd8/5qwlTLMvlc6+58/2yAoyip1uzkrFGMH6AbMHwQqDwpN?= =?iso-8859-1?Q?zyqid5pHP8TRqJxZSOjPg05zylB7iUX+RyPlybbMpLtesF2MXAQa7rzqbh?= =?iso-8859-1?Q?xdgQd9gsR1o8uJRcvOhA/RmZBhRH7xJMmDgrhzt/yU4Loqrfmc4cvNpceA?= =?iso-8859-1?Q?V2SBSk1DLec/7yA8chj9s1pRiclEtzkHeU5Z2pxEeQyret6J4Pb4i3IiLc?= =?iso-8859-1?Q?XrbVVjzB6APxwhb3uV1fnv9x+F8EY7znEsrBX38IG9pr5rl2+1At9thXBX?= =?iso-8859-1?Q?kpsvA5qz3YzGpLi6bd+pRRX5zQTaHEro+TN004DurUT8L5geTCMbMt72w8?= =?iso-8859-1?Q?ekQXPMitpbr9iC7x+UYDW0Ku3OWWxNBkxG9Em5YOR1kXuuswsOyKXW+YIu?= =?iso-8859-1?Q?f1Zs/ku5/ldpmMCItzjraccmLpQn+npl9PLbWeo1YVsXgXSheADQqgCiVv?= =?iso-8859-1?Q?NFY3n5ryWZzXkvMH8of8tV+M532Tbm1coiXbnIWfzY9prnGVv22ZNtfPD1?= =?iso-8859-1?Q?vyY+9a9VKirXcYTPm+vGM8yIt/4WzXBDaK3PhHdCsk+Eg6SyJEK6sQGiiU?= =?iso-8859-1?Q?uC8WkIFZQWveUqbUpZg6JdFNRmZMp8jij59gQqI4v3v8kOPpEoCgu5sIHH?= =?iso-8859-1?Q?t0y+Cq41/7uw3QdFkkCjsKjnsqkSlzLBX+NQgg8kwYnACPM9txUBy/UmIv?= =?iso-8859-1?Q?vA+ZGMt/frKbefZ2GRdwuIVQNLRn/B6fjuECdADg0HCkb/iI+vwWCle8FQ?= =?iso-8859-1?Q?pPb27Xov7NRYHTtK4ry8QdjjWsCh1zX+T8LFi5RP8oAjdiERNlJ+BE2UME?= =?iso-8859-1?Q?px1HBT9uo8uJC4nztAZuDd964jnlph+Oi6KsLMJcDCa5QHRuCpsOs6XfZz?= =?iso-8859-1?Q?Kqtpko5aM2xo2Jnuvz/0RBgN7rcMjt6Ip+pJHlifi81yLnJ12hkqtnseF8?= =?iso-8859-1?Q?svMgNKVUo63fQyE9cykUgmU51lnjmf8hP6gGK1mZIN4XzEwS+IRlFuD/jP?= =?iso-8859-1?Q?G7GYXOslowyis7EQV4KkV3rfBFCBWVwu6GNYWpw6BO/IuHXh8K4uqpPJTz?= =?iso-8859-1?Q?fj/ZEDIyurEggHYADdYrkc5K9FsDPRBvMWYooKmA0L/nsnrcWKSGOZZTQM?= =?iso-8859-1?Q?01E8uasBNov6V6ntbfgeDewKdxTD5TXX8Q=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 6:HiawK0H1//RKbW062BYg04VrgupdqXwb1spFlrMAZqq2X0CW50qZ1Gdle3GzoCUfVqiMaZONVpguxUf5SBPfAsVog7N4r0P7Q9QwOfshBMKjr2k3iBv2P+oYmBZRdd6lHA0CL1f+3AJSiRZ6TleEao56wVHHkTt6B3l1r5IGYbvizoweA43rciVEcOA9ZCU3ZEax4vgrGXVmZcvUwftxs0WTx1qDQ+VceLNHg1EyeVx5nGz4GBgqzWiy7IDv6alp+DAKni/4hcsJ5cnX46/Piy+gq8ZhyTRMGxvMoP10aG1ZZBvzSKaf1AyM0qMKC8lHO4Wa4/UweKJ/kagaoM8wuA==; 5:hDg1rnY+vXIi7SJBjpDYleUNjbd2S5xdgMINubrOlO4fMp4hPOL2+5ht5wO05O4/Y0Yz7Bmn1G+spkT6wuy7gEebLxb2amoe1HqULEPYr5AGXRXnZAOUJWChH5rjXYecms6NHP0cD2Vwgxj+DqogMg==; 24:SWBPX28XrITUjRCzlWUdkGkeeKdROFkRqkSt9yzRZE3HubCOMKWzc2vHuj2vfdl6NfQuWfKH9zLvNKAMh6uJ8PtrKaNeyxqlUSAaHVdrJv0=; 7:fbwwjEZxNt+mX0X5+nbkrmd7kRn14QpXGb/kBDNbFw97jn8zXyw1vlkha4tWMqsNkcYyPol/hbWSbLsqZSU9D+YLwtU+Q+yQXC1jRIe0S9ZCzKm+aOuQaaNtI30zFrQlhxYEY22XgjHO219OFPmSZw1ohXX6OMShavBkuo6ZAT4wRpAZZ+BXnVd2lz3e7MGxo0Q6zkdrYwATyHzO7cZ15+VNB2ha+3JPRdVjHWD9Ph0= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Aug 2017 11:56:00.4435 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2997 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-16.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 11:56:08 -0000 Clyde I like the introduction of yyyy and zzzz; but I still hanker after Normative References to I-Ds, draft-ietf-netconf-keystore and draft-ietf-netconf-tls-client-server. I think that they are required. Also, in -15 and in -16, the line length seems to have gone wrong and is now too long; I notice it in the Description clauses. It was ok in -13. " Each line must be limited to 72 characters followed by the character sequence that denotes an end-of-line (EOL). This limit includes any left-side indentation. " Tom Petch ---- Original Message ----- From: To: Cc: Sent: Saturday, August 12, 2017 3:17 AM > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Modeling WG of the IETF. > > Title : A YANG Data Model for Syslog Configuration > Authors : Clyde Wildes > Kiran Koushik > Filename : draft-ietf-netmod-syslog-model-16.txt > Pages : 30 > Date : 2017-08-11 > > Abstract: > This document defines a YANG data model for the configuration of a > syslog process. It is intended this model be used by vendors who > implement syslog in their systems. > > Editorial Note (To be removed by RFC Editor) > > This draft contains many placeholder values that need to be replaced > with finalized values at the time of publication. This note > summarizes all of the substitutions that are needed. No other RFC > Editor instructions are specified elsewhere in this document. > > Artwork in this document contains shorthand references to drafts in > progress. Please apply the following replacements: > > o "xxxx" --> the assigned RFC value for draft-ietf-netconf-keystore > > o "yyyy" --> the assigned RFC value for draft-ietf-netconf-tls- > client-server > > o "zzzz" --> the assigned RFC value for this draft > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-16 > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-16 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-16 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Aug 17 05:19:35 2017 Return-Path: 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 DC37A13213D for ; Thu, 17 Aug 2017 05:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 34T3vhxlHmqn for ; Thu, 17 Aug 2017 05:19:31 -0700 (PDT) Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2341201F8 for ; Thu, 17 Aug 2017 05:19:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 40549261846 for ; Thu, 17 Aug 2017 14:19:31 +0200 (CEST) X-Virus-Scanned: amavisd-new at SpriteLink.NET Received: from Mail2.SpriteLink.NET ([195.182.5.83]) by localhost (Mail2.SpriteLink.NET [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgMVAs8AoyHl for ; Thu, 17 Aug 2017 14:19:29 +0200 (CEST) Received: from localhost (Mission-Control.spritelink.net [195.182.5.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@SpriteLink.NET) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id 3B4B3261838 for ; Thu, 17 Aug 2017 14:19:29 +0200 (CEST) Date: Thu, 17 Aug 2017 14:19:28 +0200 From: Kristian Larsson To: "netmod@ietf.org" Message-ID: <20170817121928.GB5993@spritelink.se> References: <1D830FD0-547F-4F5D-A169-B05A8DC013B3@juniper.net> <972a1bde-6316-1b9b-e032-5be7ca53fa3f@labn.net> <20170717151148.GB17340@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170717151148.GB17340@elstar.local> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-acl-model-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 12:19:34 -0000 On Mon, Jul 17, 2017 at 05:11:48PM +0200, Juergen Schoenwaelder wrote: > On Mon, Jul 17, 2017 at 04:18:47PM +0200, Lou Berger wrote: > > All, > > > > Per our discussion in today's session, another version of this draft > > is needed to address open issues. As this revision will include > > technical changes, another LC will be needed after that version is > > published. > > > > Please do comment on this version, but be aware this version will *not* > > be submitted for publication. > > > > I planned to review this I-D but I will now wait for the next > version. ;-) However, a few things I already noted: > > - The identifiers are long, I think this was discussed before. I > suggest to replace 'source' with 'src' and 'destination' with > 'dst'; this will likely also make the tree diagram fit the > traditional RFC format again. > > I am not sure about the idea to spell out all the mixed-x-y-z > combinations. This may turn out costly to maintain long term. > > The naming is also inconsistent I think. My understanding is that > mixed-l2-l3-ipv4-acl really means mixed-eth-ipv4-acl. In fact, > ipv4-acl is actually l3 and possibly l4 since the grouping > acl-ip-header-fields uses acl-transport-header-fields. You can skip > the l4 portions since they are in a presence container. Note that this > is different from how you deal with l2 and l3 combinations. +1, this bothered me too when reading the model. IPv4 and IPv6 is explicitly named while L2 just implies Ethernet. Should have eth-ipv4-acl in the name, or eth-ipv6-acl.. or if we support matches for other L2 technology then include that in the name. While Ethernet is popular we do still have other L2 technologies. > I guess I > would generally prefer a solution that is more orthogonal > wrt. layering and likely not causing maintenance headaches in 5-10 > years from now. I don't immediately see a better way of doing it. It is rather tricky. > That said, I am not planning to implement this YANG module myself so > as long as multiple implementors think this is all good, it might be > sufficient to simply fix terminology and naming to be clear, concise > and consistent. I'm trying to implement it, as a user :) kll -- Kristian Larsson KLL-RIPE +46 704 264511 kll@spritelink.net From nobody Thu Aug 17 06:40:12 2017 Return-Path: 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 51D9E132400 for ; Thu, 17 Aug 2017 06:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 6qdadOXweEiL for ; Thu, 17 Aug 2017 06:40:00 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0090.outbound.protection.outlook.com [104.47.2.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395101323CE for ; Thu, 17 Aug 2017 06:40:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JQxVUMSVY8aWgp+wkTMyHOMJNy/NElhzZzyfNJqL3Cc=; b=ELCPumOBirWPaeBcDDnfPrDLSIP77NxTzbrNs2hJeRUJ8tBR65dM5Z2MThfJdJu0VoFcbMzloUvA5iKrjoojw2Yn1F06O/BC5hopsgdGPaSBTmZPJaWZ4cjTATwRYjfabOt4WzoFkRjnu1zO28joceSDh7pxc6fVOlPXbHucGw4= Received: from AM2PR07MB0627.eurprd07.prod.outlook.com (10.160.54.154) by AM2PR07MB0850.eurprd07.prod.outlook.com (10.161.71.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.4; Thu, 17 Aug 2017 13:39:54 +0000 Received: from AM2PR07MB0627.eurprd07.prod.outlook.com ([fe80::182e:6400:46fc:f36e]) by AM2PR07MB0627.eurprd07.prod.outlook.com ([fe80::182e:6400:46fc:f36e%13]) with mapi id 15.01.1362.018; Thu, 17 Aug 2017 13:39:54 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: Martin Bjorklund , "netmod@ietf.org" CC: "Pauwels, Ludwig (Nokia - BE/Antwerp)" , "joey.boyd@adtran.com" Thread-Topic: [netmod] What is the best way to HW identities Thread-Index: AdMXOxJtbuifQeSdR6iiACPpuek3uwADTqEAAAUTp0A= Date: Thu, 17 Aug 2017 13:39:54 +0000 Message-ID: References: <20170817.130222.702011777700824230.mbj@tail-f.com> In-Reply-To: <20170817.130222.702011777700824230.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; x-originating-ip: [135.245.212.3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0850; 6:tm76oY3tSne7Oo40XJYaogwGdY0Amo0uk2yHZ2BbFRHgTUlVlLQQ8h9BiUrRLDQgsm47dvzUjaenSbefNJlzadtrBgDggRhVDwzBqN7RtCaakLSN6JJn/tOMT+th9FkygXIJjGmVWQ+QyN3fz9z2naeqGgBnWJ3Bf3YNCzRXjGKf859QFVP9tWbh3jlc6ikpNiemPJMcn0T8IIXRbw+lp6S1tHbQVpuVavsNNnRyl/bfV25xe2qR8ILKDUoWDB0vBQWV8WT3bT4n2Jq+QgdI9zbEKsQ+cHSH5R7LATqZJlprqGSYJfGPaKSEVWAEZ3B/BgP63ejgiBsAbTNrulXHbA==; 5:kg4EoTag5eDwjMoGbUdDhrhyMaxbMn3bEXUtg4reihjb9VuRkixKbbaglDSrIK3WFvGPqlejVPy+LM67Z94ezWOE9/pb9dG8Oapx4zQQHmoxvGia5bqZW+Bw+HV4nZYJCas0/aIW1fOGXaSSSTuSGQ==; 24:ehBKlISHS8UxTYxmzaE/fCxjIVvt39o80fWvndpzI31VcRyN865V503FxArM9XgPPeWIYb0ndoCE4jXCCI04JoTLHz/UU5XAKjWpzHCia9s=; 7:Nk4RS8xJ1mHBx1TyJUD0qfO4guMWQi3bUUhO8pAkZmo3qhXAk4YrH942MW7IUH0VVGyJmqNU3wMNyptfxUjSOme+Z1yVIBOoQeE1guv2+5WurWjzSgppTEum0/ZYdganRMfp3xm+ig48ACLrn5HabFJOZ97H1MGtZ+zc9ldV7H8v2vZH7xw9LN+ZVy/dzq3zgzwhZf9SGtG1XDVpn40c4geEMkg03ZkU/wg/6Sx4K9g= x-ms-office365-filtering-correlation-id: 366d9987-0af1-42b9-88d9-08d4e57571b3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(49563074)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM2PR07MB0850; x-ms-traffictypediagnostic: AM2PR07MB0850: x-exchange-antispam-report-test: UriScan:(82608151540597); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0850; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0850; x-forefront-prvs: 0402872DA1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(13464003)(199003)(189002)(24454002)(377454003)(2906002)(3846002)(102836003)(2950100002)(33656002)(7696004)(305945005)(105586002)(106356001)(4326008)(6116002)(53546010)(5660300001)(66066001)(68736007)(7736002)(6246003)(86362001)(3660700001)(14454004)(3280700002)(101416001)(8936002)(189998001)(2900100001)(54356999)(25786009)(97736004)(76176999)(50986999)(99936001)(9686003)(229853002)(74316002)(53936002)(81156014)(54906002)(5250100002)(81166006)(2501003)(99286003)(8676002)(6506006)(55016002)(478600001)(6436002)(43043002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0850; H:AM2PR07MB0627.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:3; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_03DA_01D3176F.11C0E7E0" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Aug 2017 13:39:54.6137 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0850 Archived-At: Subject: Re: [netmod] What is the best way to HW identities X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 13:40:07 -0000 ------=_NextPart_000_03DA_01D3176F.11C0E7E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Martin, Using this feedback, there is a basis to continue the work in BBF What is the best way to continue with the sub-classes w.r.t. IANA, who needs to initiate this? Your reply seems to suggest that irrespective of this email, still something was required? Anyhow, BBF can define sub-identities to continue and align later when there would be standardized HW sub-identities. Best regards, Bart -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: Thursday, August 17, 2017 1:02 PM To: Bogaert, Bart (Nokia - BE/Antwerp) Cc: netmod@ietf.org; joey.boyd@adtran.com; Pauwels, Ludwig (Nokia - BE/Antwerp) Subject: Re: [netmod] What is the best way to HW identities Hi, "Bogaert, Bart (Nokia - BE/Antwerp)" wrote: > Hello, > > > > Within BBF we have had a discussion on the use of > draft-ietf-netmod-entity-03, and we would appreciate to hear the > opinion of IETF. More specific the discussion is on the use of the > leaf 'class' and the leaf 'parent-rel-pos'. > > > > First some BBF context: > > - the systems for which BBF specifies YANG models can be built with > various 'types of hardware', e.g. as pluggable item (module) it can > contain boards and it can contain SFP/XFPs. As 'type of port' it can > have connectors to terminate fastdsl links (supported over copper > wires), and it can have positions to insert optical fibers (e.g. the > position in the SFP in which one can plug the optical fiber). > > > > - in the data model we have the need for some conditional data: e.g. > an SFP/XFP has some data that is defined in SFF-8472. This data is not > applicable to boards. Hence we need to distinguish between these 2 > types of pluggable items. A 2nd example: for the optical fibers > terminated by an SFP/XFP, we have specific data that is also defined > in SFF-8472, e.g. the wavelength. This data is not applicable to > fastdsl ports. On fastdsl ports we have specific data that relates to > remote power feeding. Obviously there is no power feeding over the > optical fiber. There might be other ports with (for now) no specific > data, e.g. an rj45. Conclusion: need data conditional to the port type. > > > > In draft-ietf-netmod-entity-03 we read > > - "The "class" leaf is a YANG identity that describes the type of the > hardware. Vendors are encouraged to either directly use one of the > common IANA-defined identities, or derive a more specific identity > from one of them. > > > > - As description for 'parent-rel-pos': "An indication of the relative > position of this child component among all its sibling components. > Sibling components are defined as components that share the same > instance values of each of the 'parent' and 'class' nodes. > > > > Based on what we read in the first bullet a thought was to specialize > the various hardware-class identities. Examples: > > > > identity board { > > base ianahw:module; > > description > > "A board is a special type of module that represents a physical > item, commonly known as a board or a card."; > > } > > > > identity transceiver { > > base ianahw:module; > > description > > "A transceiver is a special type of module that represents a > physical item like a pluggable SFP, an SFP+, or an XFP; or a soldered > SFF."; > > } > > > > identity transceiver-link { > > base ianahw:port; > > description > > "A transceiver-link is a special type of port that terminates an > optical fiber."; > > } > > > > identity rj45 { > > base ianahw:port; > > description > > "A RJ45 is a special type of port that terminates an electrical > Ethernet link."; > > } > > identity fastdsl { > > base ianahw:port; > > description > > "A fastdsl is a special type of port that terminates a copper > wire supporting a FAST or one of the DSL types link."; > > } > > > > The intention with this approach: the 'class' leaf is used to > distinguish between all types of hardware. If hardware specific data > is augmented to the hardware model, then it is using a 'when' > condition referring to the value of the leaf 'class'. > > > > Based on the description of the parent-rel-pos it is understood that > the value of this leaf is relative to the value of the class, so > numbering of e.g. the various types of port supported by one board is > independent of each other. > > > > Then the worry starts: > > - some of the BBF members understand this concept of specializing the > hardware identities and use these values for the leaf class as the way > to go, and take the impact on the numbering as a given. > > > > - Others think this impact on the parent-rel-pos is not the intention > and assume a flat numbering of all childs within a parent Good point. In the original model (i.e. the MIB), with fixed values for the class, having separate numbering schemes for separate classes makes sense. For example, if a certain board has a set of ports, some fans and a power supply, it makes sense that these are numbered individually. However, with specialized ports, this may or may not make sense. It might be possible to define parent-rel-pos in a way that gives the implementation some flexibility. For example, all ports could share the same numbering scheme. The important thing in the current model is that there must not exist two components with the same values for 'parent', 'class', and 'parent-rel-pos'. (strictly speaking, there is no requirement that the parent-rel-pos is always monotonically increasing amongst siblings, so maybe this is possible even today) > , hence do not want to > use the class leaf for further specialization, hence want to introduce > a new separate leaf to contain the more detailed information, hence > the conditional data for the various types of hardware shall be > defined with a 'when statement' referring to this new separate leaf. > > > > The feedback we would appreciate from IETF: > > - did IETF consider the need for additional conditional data? Yes, the idea was to use the 'class' leaf for this. > - which approach is the IETF preference? I would prefer to see if we can find a definition of parent-rel-pos that makes numbering work better so that the 'class' identity can be used for specialization. > - in case the IETF preference is to specialize the hardware > identities, does IETF think it is worth to standardize them in IANA, > or is the preference to keep these identities within BBF? I don't know the answer to this question, but if we want to allow for standardized sub-classes, we have to create a new IANA registry (or extend the current one), since the current one only contains the top-level class (hmm, I just realized that the document needs an updated IANA considerations section anyway; it needs to mimic RFC 7224 -- probably needs to create a common registry for hardware types from which the MIB and YANG module can be generated) /martin ------=_NextPart_000_03DA_01D3176F.11C0E7E0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT 8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0 MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0 QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7 GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9 xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE 7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/ PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ 88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo +lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5 JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL 6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45 qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6 eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO 5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74 4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0 MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB 0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt 9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH 9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI /fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos 2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P /jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO 0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MTcxMzM5NTNaMCMGCSqGSIb3DQEJBDEWBBTTs3Nv 0HET3XQJFZTD6tK5P/f3qzCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9 xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG SIb3DQEBAQUABIIBAHIT0F4NPLIon9+QtsBW1gGCsZcmABIocdm1v52z8jq/7FckIwzk+wG41ypm V4d1rpgv+VyPVKydtN5tI9PJ11lWMrTF75LhZ0kf7K2BnuT0RxGG5aVtdtAsq/QucnEVIyxnfj1j QZKNneI4dL83BVPY6fYpDBCdnkc7BRqI30XPDw1bjy0NlM6hw7wTWbLMqjlyNfVC1P/6yjNvMIpU W3LVtuF/xTcKl8ydh/PUORM0q2Bm8Q3P90pyFKHuu2/FsrP/8UesHbe+NHxFgws7tAcu8IllLwKC /B98N0Oz8e1wI/Vell9DRl55WrZFbQkfXyxH5gp3kC8Dm8Fr5OpeFgwAAAAAAAA= ------=_NextPart_000_03DA_01D3176F.11C0E7E0-- From nobody Thu Aug 17 08:17:39 2017 Return-Path: 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 60D911320D8 for ; Thu, 17 Aug 2017 08:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 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 3cWVYaR03R8e for ; Thu, 17 Aug 2017 08:17:36 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B89A1321B7 for ; Thu, 17 Aug 2017 08:17:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5034; q=dns/txt; s=iport; t=1502983056; x=1504192656; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iYe3TjfoB8QDdNc7S1VoyXRyTptTayOwACrTdwA6EV0=; b=LSGRwfYcu2R+ppRiia8TRdAF/p1ewTrkLDwy/CTx9l44VkfsU8SG7AE0 Pwsbi6yjSGnIoBkhvdu18FmQn5/ww4xLzo+Kis/xRv0dqRwgCLqT9xt2q DwrD3pyOOMhjEBieFzgvsQasePQpWU1JKTOkV02QBUc1fKNli7g5UDXb9 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C8AAD7spVZ/5RdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRUHjguQEYFMIpYbDoIEIQuETE8CGoQ+PxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUYAQEBAQIBAQEhBA06CwwEAgEIFQEEAiYCAgIlCxUQAgQOBYooCBCpaoFsO?= =?us-ascii?q?otgAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYELgh2CAoFMgg4LgnGDJoEmAQ4CFoM?= =?us-ascii?q?TMIIxBaBJAodShyqFRIIQGz6FB4pslhwBHziBCncVHyoSAYcHdodjASWBDIEPA?= =?us-ascii?q?QEB?= X-IronPort-AV: E=Sophos;i="5.41,388,1498521600"; d="scan'208";a="283990742" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Aug 2017 15:17:35 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v7HFHZAU008954 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 17 Aug 2017 15:17:35 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 17 Aug 2017 10:17:34 -0500 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1210.000; Thu, 17 Aug 2017 10:17:34 -0500 From: "Clyde Wildes (cwildes)" To: "t.petch" CC: "netmod@ietf.org" , "\"Kent Watsen\"" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-syslog-model-16.txt Thread-Index: AQHTExFDExSangGc6UuVj1J6pFAgdKKIeX3UgAAWvYA= Date: Thu, 17 Aug 2017 15:17:34 +0000 Message-ID: <4F1DBF8B-23BD-4291-99A2-02471D646CF3@cisco.com> References: <150250423969.24551.6610594688078341933@ietfa.amsl.com> <05fd01d3174f$aac0e5a0$4001a8c0@gateway.2wire.net> In-Reply-To: <05fd01d3174f$aac0e5a0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.154.131.7] Content-Type: text/plain; charset="utf-8" Content-ID: <15DC7723F4DE3B4B8A10A524554BCCF1@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-16.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 15:17:38 -0000 VG9tLA0KDQpJIGFtIHdvcmtpbmcgd2l0aCBNYWhlc2ggdG8gZml4IHRoZSBOb3JtYXRpdmUgUmVm ZXJlbmNlcy4NCg0KUmVnYXJkaW5nIGxpbmUgbGVuZ3RoOiBJIGFtIHVzaW5nIHB5YW5nIDEuNy4z IHdoaWNoIGlzIG5vdCBjb21wbGFpbmluZyBhYm91dCBsaW5lIGxlbmd0aCBpbiB0aGUgbW9kZWwu IEJ1dCB3aGVuIEkgbG9vayBhdCB0aGUgZHJhZnQgSSBzZWUgdGhhdCBib3RoIHRoZSB0cmVlIGFu ZCB0aGUgbW9kZWwgZXhjZWVkIDgwIGNoYXJhY3RlcnMuIEkgd2lsbCBtYWtlIGEgcGFzcyB0byBz aG9ydGVuIGxpbmVzLg0KDQpUaGFua3MsDQoNCkNseWRlDQoNCk9uIDgvMTcvMTcsIDQ6NTQgQU0s ICJ0LnBldGNoIiA8aWV0ZmNAYnRjb25uZWN0LmNvbT4gd3JvdGU6DQoNCiAgICBDbHlkZQ0KICAg IA0KICAgIEkgbGlrZSB0aGUgaW50cm9kdWN0aW9uIG9mIHl5eXkgYW5kIHp6eno7ICBidXQgSSBz dGlsbCBoYW5rZXIgYWZ0ZXINCiAgICBOb3JtYXRpdmUgUmVmZXJlbmNlcyB0byBJLURzLCAgZHJh ZnQtaWV0Zi1uZXRjb25mLWtleXN0b3JlIGFuZA0KICAgIGRyYWZ0LWlldGYtbmV0Y29uZi10bHMt Y2xpZW50LXNlcnZlci4gIEkgdGhpbmsgdGhhdCB0aGV5IGFyZSByZXF1aXJlZC4NCiAgICANCiAg ICBBbHNvLCBpbiAtMTUgIGFuZCBpbiAtMTYsIHRoZSBsaW5lIGxlbmd0aCBzZWVtcyB0byBoYXZl IGdvbmUgd3JvbmcgYW5kDQogICAgaXMgbm93IHRvbyBsb25nOyBJIG5vdGljZSBpdCBpbiB0aGUg RGVzY3JpcHRpb24gY2xhdXNlcy4gIEl0IHdhcyBvaw0KICAgIGluIC0xMy4NCiAgICANCiAgICAi ICAgICAgICAgICBFYWNoIGxpbmUgbXVzdCBiZSBsaW1pdGVkIHRvIDcyIGNoYXJhY3RlcnMgZm9s bG93ZWQgYnkgdGhlDQogICAgICAgICAgICAgICBjaGFyYWN0ZXIgc2VxdWVuY2UgdGhhdCBkZW5v dGVzIGFuIGVuZC1vZi1saW5lIChFT0wpLiAgVGhpcw0KICAgICAgICAgICAgICAgbGltaXQgaW5j bHVkZXMgYW55IGxlZnQtc2lkZSBpbmRlbnRhdGlvbi4NCiAgICAiDQogICAgDQogICAgVG9tIFBl dGNoDQogICAgDQogICAgDQogICAgLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQogICAgRnJv bTogPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCiAgICBUbzogPGktZC1hbm5vdW5jZUBpZXRm Lm9yZz4NCiAgICBDYzogPG5ldG1vZEBpZXRmLm9yZz4NCiAgICBTZW50OiBTYXR1cmRheSwgQXVn dXN0IDEyLCAyMDE3IDM6MTcgQU0NCiAgICANCiAgICA+IEEgTmV3IEludGVybmV0LURyYWZ0IGlz IGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KICAgIGRpcmVjdG9y aWVzLg0KICAgID4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTmV0d29yayBNb2Rl bGluZyBXRyBvZiB0aGUgSUVURi4NCiAgICA+DQogICAgPiAgICAgICAgIFRpdGxlICAgICAgICAg ICA6IEEgWUFORyBEYXRhIE1vZGVsIGZvciBTeXNsb2cgQ29uZmlndXJhdGlvbg0KICAgID4gICAg ICAgICBBdXRob3JzICAgICAgICAgOiBDbHlkZSBXaWxkZXMNCiAgICA+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgS2lyYW4gS291c2hpaw0KICAgID4gRmlsZW5hbWUgICAgICAgIDogZHJhZnQt aWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTE2LnR4dA0KICAgID4gUGFnZXMgICAgICAgICAgIDog MzANCiAgICA+IERhdGUgICAgICAgICAgICA6IDIwMTctMDgtMTENCiAgICA+DQogICAgPiBBYnN0 cmFjdDoNCiAgICA+ICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBhIFlBTkcgZGF0YSBtb2RlbCBm b3IgdGhlIGNvbmZpZ3VyYXRpb24gb2YgYQ0KICAgID4gICAgc3lzbG9nIHByb2Nlc3MuICBJdCBp cyBpbnRlbmRlZCB0aGlzIG1vZGVsIGJlIHVzZWQgYnkgdmVuZG9ycyB3aG8NCiAgICA+ICAgIGlt cGxlbWVudCBzeXNsb2cgaW4gdGhlaXIgc3lzdGVtcy4NCiAgICA+DQogICAgPiBFZGl0b3JpYWwg Tm90ZSAoVG8gYmUgcmVtb3ZlZCBieSBSRkMgRWRpdG9yKQ0KICAgID4NCiAgICA+ICAgIFRoaXMg ZHJhZnQgY29udGFpbnMgbWFueSBwbGFjZWhvbGRlciB2YWx1ZXMgdGhhdCBuZWVkIHRvIGJlDQog ICAgcmVwbGFjZWQNCiAgICA+ICAgIHdpdGggZmluYWxpemVkIHZhbHVlcyBhdCB0aGUgdGltZSBv ZiBwdWJsaWNhdGlvbi4gIFRoaXMgbm90ZQ0KICAgID4gICAgc3VtbWFyaXplcyBhbGwgb2YgdGhl IHN1YnN0aXR1dGlvbnMgdGhhdCBhcmUgbmVlZGVkLiAgTm8gb3RoZXIgUkZDDQogICAgPiAgICBF ZGl0b3IgaW5zdHJ1Y3Rpb25zIGFyZSBzcGVjaWZpZWQgZWxzZXdoZXJlIGluIHRoaXMgZG9jdW1l bnQuDQogICAgPg0KICAgID4gICAgQXJ0d29yayBpbiB0aGlzIGRvY3VtZW50IGNvbnRhaW5zIHNo b3J0aGFuZCByZWZlcmVuY2VzIHRvIGRyYWZ0cyBpbg0KICAgID4gICAgcHJvZ3Jlc3MuICBQbGVh c2UgYXBwbHkgdGhlIGZvbGxvd2luZyByZXBsYWNlbWVudHM6DQogICAgPg0KICAgID4gICAgbyAg Inh4eHgiIC0tPiB0aGUgYXNzaWduZWQgUkZDIHZhbHVlIGZvcg0KICAgIGRyYWZ0LWlldGYtbmV0 Y29uZi1rZXlzdG9yZQ0KICAgID4NCiAgICA+ICAgIG8gICJ5eXl5IiAtLT4gdGhlIGFzc2lnbmVk IFJGQyB2YWx1ZSBmb3IgZHJhZnQtaWV0Zi1uZXRjb25mLXRscy0NCiAgICA+ICAgICAgIGNsaWVu dC1zZXJ2ZXINCiAgICA+DQogICAgPiAgICBvICAienp6eiIgLS0+IHRoZSBhc3NpZ25lZCBSRkMg dmFsdWUgZm9yIHRoaXMgZHJhZnQNCiAgICA+DQogICAgPg0KICAgID4NCiAgICA+IFRoZSBJRVRG IGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KICAgID4gaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVs Lw0KICAgID4NCiAgICA+IFRoZXJlIGFyZSBhbHNvIGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJs ZSBhdDoNCiAgICA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1v ZC1zeXNsb2ctbW9kZWwtMTYNCiAgICA+DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1zeXNsb2ctbW9kZWwtMTYNCiAgICA+DQogICAg PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQogICAg PiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRtb2Qtc3lz bG9nLW1vZGVsLTE2DQogICAgPg0KICAgID4NCiAgICA+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5 IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQogICAgc3VibWlzc2lv bg0KICAgID4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJs ZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICA+DQogICAgPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFs c28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQogICAgPiBmdHA6Ly9mdHAuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzLw0KICAgID4NCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiBuZXRtb2QgbWFpbGluZyBsaXN0DQogICAg PiBuZXRtb2RAaWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vbmV0bW9kDQogICAgDQogICAgDQoNCg== From nobody Thu Aug 17 09:16:10 2017 Return-Path: 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 472131321EA for ; Thu, 17 Aug 2017 09:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 IV4N0dKu39Uo for ; Thu, 17 Aug 2017 09:16:05 -0700 (PDT) Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id BE2AB1321D5 for ; Thu, 17 Aug 2017 09:16:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 2F4CF261846; Thu, 17 Aug 2017 18:16:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at SpriteLink.NET Received: from Mail2.SpriteLink.NET ([195.182.5.83]) by localhost (Mail2.SpriteLink.NET [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16aGCFQCV6VL; Thu, 17 Aug 2017 18:16:01 +0200 (CEST) Received: from localhost (Mission-Control.spritelink.net [195.182.5.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@SpriteLink.NET) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id DDC81261838; Thu, 17 Aug 2017 18:16:01 +0200 (CEST) Date: Thu, 17 Aug 2017 18:16:01 +0200 From: Kristian Larsson To: Kent Watsen Cc: "netmod@ietf.org" Message-ID: <20170817161601.GC5993@spritelink.se> References: <1D830FD0-547F-4F5D-A169-B05A8DC013B3@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1D830FD0-547F-4F5D-A169-B05A8DC013B3@juniper.net> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [netmod] modelling of packet-action WG Last Call for draft-ietf-netmod-acl-model-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Aug 2017 16:16:08 -0000 Pardon my ignorance as this might have been asked before but why is the actions/packet-handling modelled as a choice? It would seem an identity would be better or perhaps even an enum? kll On Fri, Jul 07, 2017 at 06:34:28PM +0000, Kent Watsen wrote: > > > This is a notice to start a three week NETMOD WG last call for the > document: > > Network Access Control List (ACL) YANG Data Model > https://tools.ietf.org/html/draft-ietf-netmod-acl-model-11 > > Note: Three weeks is more than needed, especially given this > draft has been through Last Call before, but we understand > folks are busy these days. > > Please indicate your support or concerns by Friday, July 28, 2017. > > We are particularly interested in statements of the form: > * I have reviewed this draft and found no issues. > * I have reviewed this draft and found the following issues: ... > > As well as: > * I have implemented the data model in this draft. > * I am implementing the data model in this draft. > * I am considering to implement the data model in this draft. > * I am not considering to implement the data model in this draft. > > Thank you, > NETMOD WG Chairs > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Kristian Larsson KLL-RIPE +46 704 264511 kll@spritelink.net From nobody Sat Aug 19 12:02:16 2017 Return-Path: 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 66CB31329D1; Sat, 19 Aug 2017 12:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 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 AyqIkHcCRnTZ; Sat, 19 Aug 2017 12:02:07 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFE841329CD; Sat, 19 Aug 2017 12:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2721; q=dns/txt; s=iport; t=1503169326; x=1504378926; h=from:to:cc:subject:date:message-id:mime-version; bh=FsXG7NEjt2jkg555/WphkxwY4K8omMS0ZHFxvTS+x9s=; b=nJBYe2bVyH9CbjXrS+h3t+x63VpGw7Fd5Fa/+vcq15m3wmzbpUjNFi/L wDY54q5zz5RWquJc3u0N4p6Y8x77xv4YKbNtlDAgYrQo76tiYFATlF9Th srT3eT/yVGFKtF3Q75Isw2hqw4LTuD3sc+RFSmK7+wmtxmhHGWBYOCvqw M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CkAQCqiZhZ/40NJK1TCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJva4IAnh6SU4U5ghKFRxyDVEEWAQIBAQEBAQEBayiFQlYSAQw?= =?us-ascii?q?BPQIEMCcEAQ2JUmSwFYImi2UBAQEBAQEBAQEBAQEBAQEBAQEggyiCAoMvh3CDP?= =?us-ascii?q?YJhBaBPAoFmklqSXpYfASYCL4EKdxWHY4pKgQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,398,1498521600"; d="scan'208,217";a="474130368" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Aug 2017 19:02:06 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v7JJ25IG016996 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 19 Aug 2017 19:02:06 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 19 Aug 2017 15:02:05 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Sat, 19 Aug 2017 15:02:05 -0400 From: "Acee Lindem (acee)" To: YANG Doctors , "netmod@ietf.org" Thread-Topic: Identities vs enums Thread-Index: AQHTGR2lD0xqu8Yxx0SFPCqJBETSBw== Date: Sat, 19 Aug 2017 19:02:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.201] Content-Type: multipart/alternative; boundary="_000_D5BE0363C241Baceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: [netmod] Identities vs enums X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 19:02:08 -0000 --_000_D5BE0363C241Baceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxsLA0KSW4gdGhlIGNvbnRleHQgaWFuYS1yb3V0aW5nLXR5cGVzLnlhbmcsIHdl4oCZdmUgYmVl biBoYXZpbmcgYSBkaXNjdXNzaW9uIG9mIHRoZSBtZXJpdHMgb2YgaWRlbnRpdGllcyB2cyBlbnVt cy4gV2XigJl2ZSBmb2xsb3dlZCB0aGUgbGVhZCBvZiBSRkMgNzIyNCBhbmQgdXNlZCBpZGVudGl0 aWVzIHdoaWNoIGFsbG93IGF1Z21lbnRhdGlvbi4gSG93ZXZlciwgZm9yIElBTkEgY29kZSBwb2lu dHMsIHRoZXJlIGNvdWxkIGJlIG1lcml0IGluIGhhdmluZyB0aGUgdHlwZSByZXByZXNlbnQgdGhl IGFjdHVhbCBudW1lcmljIHZhbHVlLiBBbnkgdGhvdWdodHMgb24gdGhpcz8NCg0KSW4gdGhlIG5l eHQgdmVyc2lvbiBvZiBZQU5HLCBpdCB3b3VsZCBiZSB1c2VmdWwgZm9yIGEgYmFzZSBpZGVudGl0 eSB0byBhbGxvdyBpdCB0byBoYXZlIGEgImJhc2UtdHlwZSIgKG11dHVhbGx5IGV4Y2x1c2l2ZSBv ZiAiaWRlbnRpdHktcmVmIikuIEZvciBhbGwgaWRlbnRpdGllcyBhICJiYXNlLXZhbHVlIiB3b3Vs ZCBiZSBhbGxvd2VkIGFzIGxvbmcgYXMgaXQgY29uZm9ybWVkIHRvIHRoZSBjb25zdHJhaW50cyBv ZiB0aGUgYWN0dWFsIG9yIGluaGVyaXRlZCAodmlhIOKAnGlkZW50aXR5LXJlZuKAnSkg4oCcYmFz ZS10eXBl4oCdLg0KDQpUaGFua3MsDQpBY2VlDQo= --_000_D5BE0363C241Baceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <998FD784790379479722E47E7AAC3657@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5BbGwsJm5ic3A7 PC9kaXY+DQo8ZGl2PkluIHRoZSBjb250ZXh0IGlhbmEtcm91dGluZy10eXBlcy55YW5nLCB3ZeKA mXZlIGJlZW4gaGF2aW5nIGEgZGlzY3Vzc2lvbiBvZiB0aGUgbWVyaXRzIG9mIGlkZW50aXRpZXMg dnMgZW51bXMuIFdl4oCZdmUgZm9sbG93ZWQgdGhlIGxlYWQgb2YgUkZDIDcyMjQgYW5kIHVzZWQg aWRlbnRpdGllcyB3aGljaCBhbGxvdyBhdWdtZW50YXRpb24uIEhvd2V2ZXIsIGZvciBJQU5BIGNv ZGUgcG9pbnRzLCB0aGVyZSBjb3VsZCBiZSBtZXJpdCBpbiBoYXZpbmcNCiB0aGUgdHlwZSByZXBy ZXNlbnQgdGhlIGFjdHVhbCBudW1lcmljIHZhbHVlLiBBbnkgdGhvdWdodHMgb24gdGhpcz8mbmJz cDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkluIHRoZSBuZXh0IHZlcnNpb24gb2Yg WUFORywgaXQgd291bGQgYmUgdXNlZnVsIGZvciBhIGJhc2UgaWRlbnRpdHkgdG8gYWxsb3cgaXQg dG8gaGF2ZSBhICZxdW90O2Jhc2UtdHlwZSZxdW90OyAobXV0dWFsbHkgZXhjbHVzaXZlIG9mICZx dW90O2lkZW50aXR5LXJlZiZxdW90OykuIEZvciBhbGwgaWRlbnRpdGllcyBhICZxdW90O2Jhc2Ut dmFsdWUmcXVvdDsgd291bGQgYmUgYWxsb3dlZCBhcyBsb25nIGFzIGl0IGNvbmZvcm1lZCB0byB0 aGUgY29uc3RyYWludHMgb2YgdGhlIGFjdHVhbCBvcg0KIGluaGVyaXRlZCAodmlhIOKAnGlkZW50 aXR5LXJlZuKAnSkg4oCcYmFzZS10eXBl4oCdLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj5BY2VlPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_D5BE0363C241Baceeciscocom_-- From nobody Sun Aug 20 01:03:08 2017 Return-Path: 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 3C8CD132328; Sun, 20 Aug 2017 01:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 RnG5nogvfVq4; Sun, 20 Aug 2017 01:03:04 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B15CC1321B6; Sun, 20 Aug 2017 01:03:04 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id BD3C799; Sun, 20 Aug 2017 10:03:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id j5e1-Orqdygi; Sun, 20 Aug 2017 10:02:59 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Sun, 20 Aug 2017 10:03:02 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7AE65200DF; Sun, 20 Aug 2017 10:03:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3LU5I8B0lyfw; Sun, 20 Aug 2017 10:03:02 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0DB6E200DE; Sun, 20 Aug 2017 10:03:01 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B508E404474A; Sun, 20 Aug 2017 10:03:01 +0200 (CEST) Date: Sun, 20 Aug 2017 10:03:01 +0200 From: Juergen Schoenwaelder To: "Acee Lindem (acee)" Cc: YANG Doctors , "netmod@ietf.org" , Rodney Cummings Message-ID: <20170820080301.asf2fx6o4abupq4h@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: "Acee Lindem (acee)" , YANG Doctors , "netmod@ietf.org" , Rodney Cummings References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170714 (1.8.3) Archived-At: Subject: Re: [netmod] [yang-doctors] Identities vs enums X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Aug 2017 08:03:07 -0000 On Sat, Aug 19, 2017 at 07:02:04PM +0000, Acee Lindem (acee) wrote: > All, > In the context iana-routing-types.yang, we’ve been having a discussion of the merits of identities vs enums. We’ve followed the lead of RFC 7224 and used identities which allow augmentation. However, for IANA code points, there could be merit in having the type represent the actual numeric value. Any thoughts on this? > > In the next version of YANG, it would be useful for a base identity to allow it to have a "base-type" (mutually exclusive of "identity-ref"). For all identities a "base-value" would be allowed as long as it conformed to the constraints of the actual or inherited (via “identity-ref”) “base-type”. > The question here really is who is charge of controlling assignments of a name space. - If there is a single authority controlling the assignments, an enum works fine. - If the assignments are not controlled by a single authority, an identity works fine. We sometimes have situations that are somewhere in between, i.e., a central authority controlling assignments but delegating parts of the name space to other authoritities. I agree, we do not have good support to model this explicitly in YANG today. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Aug 21 01:08:03 2017 Return-Path: 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 F3163132938 for ; Mon, 21 Aug 2017 01:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 sPEeEf23awZE for ; Mon, 21 Aug 2017 01:07:59 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0201323A6 for ; Mon, 21 Aug 2017 01:07:59 -0700 (PDT) Received: from localhost (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 2A9601AE012C for ; Mon, 21 Aug 2017 10:07:58 +0200 (CEST) Date: Mon, 21 Aug 2017 10:06:29 +0200 (CEST) Message-Id: <20170821.100629.1135908044163191249.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Aug_21_10_06_29_2017_626)--" Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-rfc7223bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 08:08:02 -0000 ----Next_Part(Mon_Aug_21_10_06_29_2017_626)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, This document defines an NMDA-compliant update to the interfaces model (RFC 7223). This is done by deprectaing the /interfaces-state tree and moving the config false nodes into the /interfaces tree. I would like to ask the WG to adopt this individual draft as a working group document. /martin ----Next_Part(Mon_Aug_21_10_06_29_2017_626)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on metgos.tail-f.com X-Spam-Level: X-Spam-Status: No, score=-104.8 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RP_MATCHES_RCVD,SPF_PASS, USER_IN_WHITELIST autolearn=ham autolearn_force=no version=3.4.0 X-Original-To: mbj@tail-f.com Delivered-To: mbj@tail-f.com Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by mail.tail-f.com (Postfix) with ESMTPS id B99F21AE012C for ; Mon, 21 Aug 2017 10:05:33 +0200 (CEST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CAD13293B for ; Mon, 21 Aug 2017 01:05:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: "Martin Bjorklund" Subject: New Version Notification for draft-bjorklund-netmod-rfc7223bis-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150330273199.6538.9818189451525853696.idtracker@ietfa.amsl.com> Date: Mon, 21 Aug 2017 01:05:31 -0700 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 int cnt prob spamicity histogram 0.00 58 0.021314 0.020639 ################################################ 0.10 2 0.118703 0.024577 ## 0.20 0 0.000000 0.024577 0.30 0 0.000000 0.024577 0.40 0 0.000000 0.024577 0.50 0 0.000000 0.024577 0.60 0 0.000000 0.024577 0.70 0 0.000000 0.024577 0.80 0 0.000000 0.024577 0.90 0 0.000000 0.024577 A new version of I-D, draft-bjorklund-netmod-rfc7223bis-00.txt has been successfully submitted by Martin Bjorklund and posted to the IETF repository. Name: draft-bjorklund-netmod-rfc7223bis Revision: 00 Title: A YANG Data Model for Interface Management Document date: 2017-08-21 Group: Individual Submission Pages: 47 URL: https://www.ietf.org/internet-drafts/draft-bjorklund-netmod-rfc7223bis-00.txt Status: https://datatracker.ietf.org/doc/draft-bjorklund-netmod-rfc7223bis/ Htmlized: https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7223bis-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-bjorklund-netmod-rfc7223bis-00 Abstract: This document defines a YANG data model for the management of network interfaces. It is expected that interface-type-specific data models augment the generic interfaces data model defined in this document. The data model includes definitions for configuration and system state (status information and counters for the collection of statistics). This document obsoletes RFC 7223. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ----Next_Part(Mon_Aug_21_10_06_29_2017_626)---- From nobody Mon Aug 21 03:23:56 2017 Return-Path: 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 121E41329BD for ; Mon, 21 Aug 2017 03:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 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 zDLS83iygfZx for ; Mon, 21 Aug 2017 03:23:53 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE3181329B3 for ; Mon, 21 Aug 2017 03:23:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1237; q=dns/txt; s=iport; t=1503311033; x=1504520633; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=L4X8+gYtKSMniyXhVadv+ox3ra4dNTUxgBqxWGgTULA=; b=m6gPxAfftOUwuFEztao2E0dOIWKtocUEIgaQ5Jx7kV9CWXzTpm2PkBFR +EW68cNJQGUQZqTlDqrFPwx2jo4HVfMgpiEQKIQ67aCqyxCjSOY4y3ZBt 3Iix0Nt9FYZx+dowufIp9IZUO6/3BgP3VoinVpopuSOH9ZvYeQMHxayDz s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C2AgC+s5pZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD45hFOLDpEQmDAshRsChEAUAQIBAQEBAQEBayiFGAEBAQECASM?= =?us-ascii?q?VPBULGAICJgICVxMIAQGKJQgQrxmCJotWAQEBAQEFAQEBAR8FgQuCHYNOgWMrg?= =?us-ascii?q?nyFP4JHgmEFoE+HVIxui0mHFY0yiG42IYEKMiEIHBWHZD+LFgEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,408,1498521600"; d="scan'208";a="654089292" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Aug 2017 10:23:48 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7LANmxY014743 for ; Mon, 21 Aug 2017 10:23:48 GMT To: netmod@ietf.org References: <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com> <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com> <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> From: Robert Wilton Message-ID: <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com> Date: Mon, 21 Aug 2017 11:23:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170809151312.GC42207@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 10:23:55 -0000 On 09/08/2017 16:13, Juergen Schoenwaelder wrote: > On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka wrote: >> I remember that in early stages of YANG there was some irrational >> fear of introducing too many namespaces, and submodules may be a >> consequence of it. As you write, submodules provide no benefits >> whatsoever in terms of modularity, but the overhead in terms of >> metadata, IANA registration etc. is pretty much the same as for >> modules. > In case YANG 2.0 is ever done, I suggest someone files a proposal to > remove submodules if the cost/benefit ratio is at odds. There is > nothing wrong with removing stuff that has been found problematic. I agree. I've added https://github.com/netmod-wg/yang-next/issues/26 Rob > > The motivation for submodules was that organizations maintaining large > modules with multiple people can do so without having to mess around > with tools like m4 scripts to produce a single module from 'snippets' > and to avoid integration surprises. But perhaps using m4 scripts and > decent version control systems (that can integrate and compile on > checkin) is indeed cheaper than having submodules part of the YANG > language itself. > > /js > From nobody Mon Aug 21 05:07:43 2017 Return-Path: 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 46DF61329DE for ; Mon, 21 Aug 2017 05:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 nTLierEf2tnq for ; Mon, 21 Aug 2017 05:07:40 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 50B531329F1 for ; Mon, 21 Aug 2017 05:07:40 -0700 (PDT) Received: from localhost (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 657151AE012C for ; Mon, 21 Aug 2017 14:07:39 +0200 (CEST) Date: Mon, 21 Aug 2017 14:06:10 +0200 (CEST) Message-Id: <20170821.140610.1599460825983098893.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Aug_21_14_06_10_2017_067)--" Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-rfc7277bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 12:07:42 -0000 ----Next_Part(Mon_Aug_21_14_06_10_2017_067)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, This document defines an NMDA-compliant update to the IP model (RFC 7277). I would like to ask the WG to adopt this individual draft as a working group document. /martin ----Next_Part(Mon_Aug_21_14_06_10_2017_067)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on metgos.tail-f.com X-Spam-Level: X-Spam-Status: No, score=-104.8 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RP_MATCHES_RCVD,SPF_PASS, USER_IN_WHITELIST autolearn=ham autolearn_force=no version=3.4.0 X-Original-To: mbj@tail-f.com Delivered-To: mbj@tail-f.com Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) by mail.tail-f.com (Postfix) with ESMTPS id 16C671AE033A for ; Mon, 21 Aug 2017 14:06:14 +0200 (CEST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19AA71329F0 for ; Mon, 21 Aug 2017 05:06:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: "Martin Bjorklund" Subject: New Version Notification for draft-bjorklund-netmod-rfc7277bis-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150331717310.6602.8459279846737977907.idtracker@ietfa.amsl.com> Date: Mon, 21 Aug 2017 05:06:13 -0700 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 int cnt prob spamicity histogram 0.00 51 0.020264 0.019554 ################################################ 0.10 2 0.118667 0.024021 ## 0.20 0 0.000000 0.024021 0.30 0 0.000000 0.024021 0.40 0 0.000000 0.024021 0.50 0 0.000000 0.024021 0.60 0 0.000000 0.024021 0.70 0 0.000000 0.024021 0.80 0 0.000000 0.024021 0.90 0 0.000000 0.024021 A new version of I-D, draft-bjorklund-netmod-rfc7277bis-00.txt has been successfully submitted by Martin Bjorklund and posted to the IETF repository. Name: draft-bjorklund-netmod-rfc7277bis Revision: 00 Title: A YANG Data Model for IP Management Document date: 2017-08-21 Group: Individual Submission Pages: 32 URL: https://www.ietf.org/internet-drafts/draft-bjorklund-netmod-rfc7277bis-00.txt Status: https://datatracker.ietf.org/doc/draft-bjorklund-netmod-rfc7277bis/ Htmlized: https://tools.ietf.org/html/draft-bjorklund-netmod-rfc7277bis-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-bjorklund-netmod-rfc7277bis-00 Abstract: This document defines a YANG data model for management of IP implementations. The data model includes configuration and system state. This document obsoletes RFC 7277. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ----Next_Part(Mon_Aug_21_14_06_10_2017_067)---- From nobody Mon Aug 21 06:26:18 2017 Return-Path: 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 5FD49132A3B for ; Mon, 21 Aug 2017 06:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 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 Wer9ciaZSKoj for ; Mon, 21 Aug 2017 06:26:12 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 303BA132A3A for ; Mon, 21 Aug 2017 06:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2799; q=dns/txt; s=iport; t=1503321972; x=1504531572; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=8qtRNewBwGJ9w/XTflbjJk5BWxd/+3wIRsBL70w7kTM=; b=ACpmwE3NLtB2IXGaFQhp+jS8DJ9jp9mPD+1aJs1CRydXpF5mRglTwa54 Y7/K2VFdsWABceD7rTGjpe8FPLR8YZRJsaJY6SF+1Dd3XLncoxL6sOvMU qoWJLL3aaPOs6LzutlYtruNDIoHtUPEDF1ZEetqNtCB5gHOQdXGBBcpIJ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BXAgD43ZpZ/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBhD6BFY8FkG0ikGWHSyEBCoRMTwKEShUBAgEBAQEBAQFrKIUZAQE?= =?us-ascii?q?BAwEBbAkSCwQBCQouJzAGAQwGAgEBii0QsQonizABAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEYBYMog06BYysLgnGKZwWgT5RCghCJOSOGcolpg0mIbjUigQoyIQgcFUm?= =?us-ascii?q?FTIFPPzaKYQEBAQ?= X-IronPort-AV: E=Sophos;i="5.41,409,1498521600"; d="scan'208,217";a="654093925" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Aug 2017 13:26:07 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v7LDQ7uO029637; Mon, 21 Aug 2017 13:26:07 GMT To: Martin Bjorklund , netmod@ietf.org References: <20170821.100629.1135908044163191249.mbj@tail-f.com> From: Robert Wilton Message-ID: Date: Mon, 21 Aug 2017 14:26:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170821.100629.1135908044163191249.mbj@tail-f.com> Content-Type: multipart/alternative; boundary="------------1D5EAAFC60E1B6350DDD9860" Content-Language: en-US Archived-At: Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-rfc7223bis-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 13:26:14 -0000 This is a multi-part message in MIME format. --------------1D5EAAFC60E1B6350DDD9860 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I've read this draft and would also support it being adopted as a WG document. Given that lots of models depend on ietf-interfaces, the sooner that we can get this published as an updated RFC the better. Realistically, how quickly can we get the IETF machinery to move on this and the few other equivalent drafts? Thanks, Rob On 21/08/2017 09:06, Martin Bjorklund wrote: > Hi, > > This document defines an NMDA-compliant update to the interfaces model > (RFC 7223). This is done by deprectaing the /interfaces-state tree > and moving the config false nodes into the /interfaces tree. > > I would like to ask the WG to adopt this individual draft as a working > group document. > > > /martin > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------1D5EAAFC60E1B6350DDD9860 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

I've read this draft and would also support it being adopted as a WG document.

Given that lots of models depend on ietf-interfaces, the sooner that we can get this published as an updated RFC the better. Realistically, how quickly can we get the IETF machinery to move on this and the few other equivalent drafts?

Thanks,
Rob


On 21/08/2017 09:06, Martin Bjorklund wrote:
Hi,

This document defines an NMDA-compliant update to the interfaces model
(RFC 7223).  This is done by deprectaing the /interfaces-state tree
and moving the config false nodes into the /interfaces tree.

I would like to ask the WG to adopt this individual draft as a working
group document.


/martin




_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--------------1D5EAAFC60E1B6350DDD9860-- From nobody Mon Aug 21 06:34:42 2017 Return-Path: X-Original-To: netmod@ietf.org Delivered-To: netmod@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C0713243A; Mon, 21 Aug 2017 06:34:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150332248082.6866.4558465509766000982@ietfa.amsl.com> Date: Mon, 21 Aug 2017 06:34:40 -0700 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-entity-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 13:34:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : A YANG Data Model for Hardware Management Authors : Andy Bierman Martin Bjorklund Jie Dong Dan Romascanu Filename : draft-ietf-netmod-entity-04.txt Pages : 38 Date : 2017-08-21 Abstract: This document defines a YANG data model for the management of hardware on a single server. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-entity-04 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 21 06:38:00 2017 Return-Path: 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 3F66B132A44 for ; Mon, 21 Aug 2017 06:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 0kSqlidLeVgM for ; Mon, 21 Aug 2017 06:37:53 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 93A2F132A28 for ; Mon, 21 Aug 2017 06:37:53 -0700 (PDT) Received: from localhost (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 138C21AE012C for ; Mon, 21 Aug 2017 15:37:52 +0200 (CEST) Date: Mon, 21 Aug 2017 15:36:22 +0200 (CEST) Message-Id: <20170821.153622.1285855591065656893.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund In-Reply-To: <150332248082.6866.4558465509766000982@ietfa.amsl.com> References: <150332248082.6866.4558465509766000982@ietfa.amsl.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 13:38:00 -0000 Hi, This version of the hardware model is compatible with NMDA, with a single tree /hardware. The latest comment from Bart Bogaert about subclasses has not been addressed. /martin internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Network Modeling WG of the IETF. > > Title : A YANG Data Model for Hardware Management > Authors : Andy Bierman > Martin Bjorklund > Jie Dong > Dan Romascanu > Filename : draft-ietf-netmod-entity-04.txt > Pages : 38 > Date : 2017-08-21 > > Abstract: > This document defines a YANG data model for the management of > hardware on a single server. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-netmod-entity-04 > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-entity-04 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-entity-04 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Mon Aug 21 06:45:49 2017 Return-Path: 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 9DEE2132A28 for ; Mon, 21 Aug 2017 06:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 mHXnnC7lKYjq for ; Mon, 21 Aug 2017 06:45:46 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 BA30013235C for ; Mon, 21 Aug 2017 06:45:46 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id v7LDjNHO015892; Mon, 21 Aug 2017 09:45:44 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049287.ppops.net-00191d01. with ESMTP id 2cfx9tnhaj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Aug 2017 09:45:44 -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 v7LDjhsv005044; Mon, 21 Aug 2017 09:45:43 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7LDjYxi004818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 21 Aug 2017 09:45:38 -0400 Received: from gbcdccas03.intl.att.com (gbcdccas03.intl.att.com [135.76.180.11]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 21 Aug 2017 13:45:23 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; Mon, 21 Aug 2017 14:45:21 +0100 From: "Ivory, William" To: "'Robert Wilton'" , "'netmod@ietf.org'" Thread-Topic: [netmod] Query about augmenting module from submodule in YANG 1.0 Thread-Index: AdMMOPUClm48yMKSSEeEurX4RbXaiADP5++AAAR9DaAACC3kAAAcrpQgAD0R+IAAAWwvgAAAa7wAAlFjp4AACPgnkA== Date: Mon, 21 Aug 2017 13:44:20 +0000 Deferred-Delivery: Mon, 21 Aug 2017 13:45:20 +0000 Message-ID: References: <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com> <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com> <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com> In-Reply-To: <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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-21_09:, , 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-1707230000 definitions=main-1708210219 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 13:45:49 -0000 Hi Rob, That would make it very hard to update existing 1.x YANG models to use new = features in YANG 2.x if they used submodules. Maybe that's something that = no one would ever consider doing anyway, or maybe YANG 1.1 already has simi= lar differences to 1.0? I had (perhaps naively) assumed that you could mig= rate a namespace / model from YANG 1.0 to 2.0? Regards, William -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton Sent: 21 August 2017 11:24 To: netmod@ietf.org Subject: Re: [netmod] Query about augmenting module from submodule in YANG = 1.0 On 09/08/2017 16:13, Juergen Schoenwaelder wrote: > On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka wrote: >> I remember that in early stages of YANG there was some irrational=20 >> fear of introducing too many namespaces, and submodules may be a=20 >> consequence of it. As you write, submodules provide no benefits=20 >> whatsoever in terms of modularity, but the overhead in terms of=20 >> metadata, IANA registration etc. is pretty much the same as for=20 >> modules. > In case YANG 2.0 is ever done, I suggest someone files a proposal to=20 > remove submodules if the cost/benefit ratio is at odds. There is=20 > nothing wrong with removing stuff that has been found problematic. I agree. I've added https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.co= m_netmod-2Dwg_yang-2Dnext_issues_26&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r= =3Dp8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=3Dl7c4IPL049A2bVVO14fyBMly= 211xU61xSHgPlAT7owI&s=3D-kR4fUtXArQy0RwWb32DpT1bP4X_cNqt2zJVoC0JiX8&e=3D=20 Rob > > The motivation for submodules was that organizations maintaining large=20 > modules with multiple people can do so without having to mess around=20 > with tools like m4 scripts to produce a single module from 'snippets' > and to avoid integration surprises. But perhaps using m4 scripts and=20 > decent version control systems (that can integrate and compile on > checkin) is indeed cheaper than having submodules part of the YANG=20 > language itself. > > /js > _______________________________________________ netmod mailing list netmod@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_netmod&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3Dp8kyeK3u4ZYiaQ2Z= PGqwkyXmQgBH6r5jpYiYWzhqJ48&m=3Dl7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7owI= &s=3Dt7vGIH8ABuAm00e-bkSowD9eawModGq0N2OkjANtpYI&e=3D=20 From nobody Mon Aug 21 07:01:56 2017 Return-Path: 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 F3DB8124207 for ; Mon, 21 Aug 2017 07:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 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 m3bmkE7MlmZY for ; Mon, 21 Aug 2017 07:01:47 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62CDA132A53 for ; Mon, 21 Aug 2017 07:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4056; q=dns/txt; s=iport; t=1503324107; x=1504533707; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=mqtXEOJrb4DHeHX7s8inztGBd0Nh8EmXx57zTHmHr0Y=; b=QwBTzbvFghQbbq1c5Uid/tqWCWhL4kx9aYEQ16gvITJDu68JJ/5L+hZs g3NuNTEXyX5BuIdVB69GpLR2uYewxKV2CrvX1BSErkRoTz4wfS5YcBitE HZHe/PoFVtrJdX8p/cHVViVY1JWykao1ZuDOslL30qzTKSuG09zf1QFDq c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DRAACF5ppZ/51dJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRUHg3CKG5AUgW6WHoISIQ2ESk8CGoNuPxgBAgEBAQEBAQF?= =?us-ascii?q?rKIUYAQEBAQMBASEROgYRBAIBCBEEAQEBAgIjAwICAiULFAEICAIEARKKMRCvA?= =?us-ascii?q?oImi1kBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYELgh2CAoMvgyeDJoEmJxeCfIJ?= =?us-ascii?q?hBaBPAodSjG6CEJBOiWmMNgEfOIEKdxVJhxp2AQGIHoEygQ8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,409,1498521600"; d="scan'208";a="474098650" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Aug 2017 14:01:46 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v7LE1jll010867 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Aug 2017 14:01:46 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 21 Aug 2017 10:01:45 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 21 Aug 2017 10:01:45 -0400 From: "Acee Lindem (acee)" To: "Ivory, William" , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , "'netmod@ietf.org'" , Andy Bierman Thread-Topic: [netmod] Query about augmenting module from submodule in YANG 1.0 Thread-Index: AdMMOPUClm48yMKSSEeEurX4RbXaiADaYiWAAAJrJAAACj/MAAAat6IAAD8I6oAAAWwwgAAAa7wAAlFjp4AABwEOAP//wcQA Date: Mon, 21 Aug 2017 14:01:45 +0000 Message-ID: References: <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com> <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com> <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.201] Content-Type: text/plain; charset="utf-8" Content-ID: <13F2109C651447498FCC54FB98F3BF19@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 14:01:55 -0000 SGkgV2lsbGlhbSwgUm9iLCBBbmR5LA0KDQpHaXZlbiB0aGVpciBsaW1pdGVkIHVzZWZ1bG5lc3Mg YW5kIHRoZSBkZXRyaW1lbnRzLCBwZXJoYXBzIHdlIHNob3VsZA0KZGlzY291cmFnZSB0aGUgY3Jl YXRpb24gb2YgbmV3IHN1Ym1vZHVsZXMgaW4gUkZDNjA4N0Jpcy4NCg0KVGhhbmtzLA0KQWNlZQ0K DQpPbiA4LzIxLzE3LCA5OjQ0IEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBJdm9yeSwgV2lsbGlh bSINCjxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygd2lsbGlhbS5pdm9yeUBp bnRsLmF0dC5jb20+IHdyb3RlOg0KDQo+SGkgUm9iLA0KPg0KPlRoYXQgd291bGQgbWFrZSBpdCB2 ZXJ5IGhhcmQgdG8gdXBkYXRlIGV4aXN0aW5nIDEueCBZQU5HIG1vZGVscyB0byB1c2UNCj5uZXcg ZmVhdHVyZXMgaW4gWUFORyAyLnggaWYgdGhleSB1c2VkIHN1Ym1vZHVsZXMuICBNYXliZSB0aGF0 J3Mgc29tZXRoaW5nDQo+dGhhdCBubyBvbmUgd291bGQgZXZlciBjb25zaWRlciBkb2luZyBhbnl3 YXksIG9yIG1heWJlIFlBTkcgMS4xIGFscmVhZHkNCj5oYXMgc2ltaWxhciBkaWZmZXJlbmNlcyB0 byAxLjA/ICBJIGhhZCAocGVyaGFwcyBuYWl2ZWx5KSBhc3N1bWVkIHRoYXQgeW91DQo+Y291bGQg bWlncmF0ZSBhIG5hbWVzcGFjZSAvIG1vZGVsIGZyb20gWUFORyAxLjAgdG8gMi4wPw0KPg0KPlJl Z2FyZHMsDQo+DQo+V2lsbGlhbQ0KPg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJv bTogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBS b2JlcnQgV2lsdG9uDQo+U2VudDogMjEgQXVndXN0IDIwMTcgMTE6MjQNCj5UbzogbmV0bW9kQGll dGYub3JnDQo+U3ViamVjdDogUmU6IFtuZXRtb2RdIFF1ZXJ5IGFib3V0IGF1Z21lbnRpbmcgbW9k dWxlIGZyb20gc3VibW9kdWxlIGluDQo+WUFORyAxLjANCj4NCj4NCj4NCj5PbiAwOS8wOC8yMDE3 IDE2OjEzLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgd3JvdGU6DQo+PiBPbiBXZWQsIEF1ZyAwOSwg MjAxNyBhdCAwNTowMTowOVBNICswMjAwLCBMYWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+Pj4gSSBy ZW1lbWJlciB0aGF0IGluIGVhcmx5IHN0YWdlcyBvZiBZQU5HIHRoZXJlIHdhcyBzb21lIGlycmF0 aW9uYWwNCj4+PiBmZWFyIG9mIGludHJvZHVjaW5nIHRvbyBtYW55IG5hbWVzcGFjZXMsIGFuZCBz dWJtb2R1bGVzIG1heSBiZSBhDQo+Pj4gY29uc2VxdWVuY2Ugb2YgaXQuIEFzIHlvdSB3cml0ZSwg c3VibW9kdWxlcyBwcm92aWRlIG5vIGJlbmVmaXRzDQo+Pj4gd2hhdHNvZXZlciBpbiB0ZXJtcyBv ZiBtb2R1bGFyaXR5LCBidXQgdGhlIG92ZXJoZWFkIGluIHRlcm1zIG9mDQo+Pj4gbWV0YWRhdGEs IElBTkEgcmVnaXN0cmF0aW9uIGV0Yy4gaXMgcHJldHR5IG11Y2ggdGhlIHNhbWUgYXMgZm9yDQo+ Pj4gbW9kdWxlcy4NCj4+IEluIGNhc2UgWUFORyAyLjAgaXMgZXZlciBkb25lLCBJIHN1Z2dlc3Qg c29tZW9uZSBmaWxlcyBhIHByb3Bvc2FsIHRvDQo+PiByZW1vdmUgc3VibW9kdWxlcyBpZiB0aGUg Y29zdC9iZW5lZml0IHJhdGlvIGlzIGF0IG9kZHMuIFRoZXJlIGlzDQo+PiBub3RoaW5nIHdyb25n IHdpdGggcmVtb3Zpbmcgc3R1ZmYgdGhhdCBoYXMgYmVlbiBmb3VuZCBwcm9ibGVtYXRpYy4NCj5J IGFncmVlLg0KPg0KPkkndmUgYWRkZWQgDQo+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX25ldG1vZC0yRHcNCj5nX3lhbmctMkRu ZXh0X2lzc3Vlc18yNiZkPUR3SUNBZyZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1wOGt5ZUsz dTRaWWlhUQ0KPjJaUEdxd2t5WG1RZ0JINnI1anBZaVlXemhxSjQ4Jm09bDdjNElQTDA0OUEyYlZW TzE0ZnlCTWx5MjExeFU2MXhTSGdQbEFUN293DQo+SSZzPS1rUjRmVXRYQXJReTBSd1diMzJEcFQx YlA0WF9jTnF0MnpKVm9DMEppWDgmZT0NCj4NCj5Sb2INCj4NCj4+DQo+PiBUaGUgbW90aXZhdGlv biBmb3Igc3VibW9kdWxlcyB3YXMgdGhhdCBvcmdhbml6YXRpb25zIG1haW50YWluaW5nIGxhcmdl DQo+PiBtb2R1bGVzIHdpdGggbXVsdGlwbGUgcGVvcGxlIGNhbiBkbyBzbyB3aXRob3V0IGhhdmlu ZyB0byBtZXNzIGFyb3VuZA0KPj4gd2l0aCB0b29scyBsaWtlIG00IHNjcmlwdHMgdG8gcHJvZHVj ZSBhIHNpbmdsZSBtb2R1bGUgZnJvbSAnc25pcHBldHMnDQo+PiBhbmQgdG8gYXZvaWQgaW50ZWdy YXRpb24gc3VycHJpc2VzLiBCdXQgcGVyaGFwcyB1c2luZyBtNCBzY3JpcHRzIGFuZA0KPj4gZGVj ZW50IHZlcnNpb24gY29udHJvbCBzeXN0ZW1zICh0aGF0IGNhbiBpbnRlZ3JhdGUgYW5kIGNvbXBp bGUgb24NCj4+IGNoZWNraW4pIGlzIGluZGVlZCBjaGVhcGVyIHRoYW4gaGF2aW5nIHN1Ym1vZHVs ZXMgcGFydCBvZiB0aGUgWUFORw0KPj4gbGFuZ3VhZ2UgaXRzZWxmLg0KPj4NCj4+IC9qcw0KPj4N Cj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5l dG1vZCBtYWlsaW5nIGxpc3QNCj5uZXRtb2RAaWV0Zi5vcmcNCj5odHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuXw0K Pmxpc3RpbmZvX25ldG1vZCZkPUR3SUNBZyZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1wOGt5 ZUszdTRaWWlhUTJaUEdxd2t5DQo+WG1RZ0JINnI1anBZaVlXemhxSjQ4Jm09bDdjNElQTDA0OUEy YlZWTzE0ZnlCTWx5MjExeFU2MXhTSGdQbEFUN293SSZzPXQ3dkcNCj5JSDhBQnVBbTAwZS1ia1Nv d0Q5ZWF3TW9kR3EwTjJPa2pBTnRwWUkmZT0NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPm5ldG1vZCBtYWlsaW5nIGxpc3QNCj5uZXRtb2RAaWV0 Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQo= From nobody Mon Aug 21 07:04:14 2017 Return-Path: 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 C50F4132A50 for ; Mon, 21 Aug 2017 07:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 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 Qq5I_FSYS5iG for ; Mon, 21 Aug 2017 07:04:09 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5A4D124207 for ; Mon, 21 Aug 2017 07:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9757; q=dns/txt; s=iport; t=1503324248; x=1504533848; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=aqJ2IHKiDkQg4QVp5Z5ifOYLbtE5dym+Ep9TrCwR2Vo=; b=CYlDwLNvZeVdLH4zXL4C23ApD0usLeajV5oOMhvVA3RieTALcSJRRL9O jZUvUayLU+gwAbkCnT3EUYa09nu/VT7f632ltwq6FatFsSJ7UexpxCc9l tDABHkjuLlHlZNGjBy62F0y1SCcbOf9y7clrH5UHy4CgeBGg3SSWSgViR o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvAwDu55pZ/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8+gRGBFYN3iw6QbSKQZYU5DoIEK4UcAoRIFwECAQEBAQEBAWs?= =?us-ascii?q?ohRgBAQEBAyNLBhEECxEEAQEBJwMCAkYJCAYBDAYCAQEQih0QrnyCJieLMgEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR2DKINOgWMrC4JxgyaBNQuDIIJhBaBPh1SMboI?= =?us-ascii?q?QWYhghxWJaYNJiG4gATaBCjIhCBwVSYcbPzYBAYgggj8BAQE?= X-IronPort-AV: E=Sophos;i="5.41,409,1498521600"; d="scan'208,217";a="655117401" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Aug 2017 14:04:04 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v7LE44wU026765; Mon, 21 Aug 2017 14:04:04 GMT To: "Ivory, William" , "'netmod@ietf.org'" References: <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com> <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com> <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com> From: Robert Wilton Message-ID: <2c4b4d0c-daf0-899c-8025-38395ef9902e@cisco.com> Date: Mon, 21 Aug 2017 15:04:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E49EEFE75767679D52F30E5B" Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 14:04:13 -0000 This is a multi-part message in MIME format. --------------E49EEFE75767679D52F30E5B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi William, The github issue is really only to track this point for further discussion and to the avoid losing the useful discussion on the alias. I think that there is often useful discussion on the NETMOD alias that ends up at least with a partial resolution, but that never gets documented anywhere. In a few cases these end up as errata, but often they either get deferred to a future version, or are treated as collective wisdom from the WG participants. For the latter case, I'm hoping that we can store the summary of some of these discussions on a community maintained wiki. YANG 1/1.1 modules using sub-modules could be upgraded into a single YANG 2.0 module. This is an allowed backwards compatible change with no changes to the node paths or namespaces. The pertinent text is in RFC 7950, sec 11: o A module may be split into a set of submodules or a submodule may be removed, provided the definitions in the module do not change in any way other than those allowed here. Thanks, Rob On 21/08/2017 14:44, Ivory, William wrote: > Hi Rob, > > That would make it very hard to update existing 1.x YANG models to use new features in YANG 2.x if they used submodules. Maybe that's something that no one would ever consider doing anyway, or maybe YANG 1.1 already has similar differences to 1.0? I had (perhaps naively) assumed that you could migrate a namespace / model from YANG 1.0 to 2.0? > > Regards, > > William > > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton > Sent: 21 August 2017 11:24 > To: netmod@ietf.org > Subject: Re: [netmod] Query about augmenting module from submodule in YANG 1.0 > > > > On 09/08/2017 16:13, Juergen Schoenwaelder wrote: >> On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka wrote: >>> I remember that in early stages of YANG there was some irrational >>> fear of introducing too many namespaces, and submodules may be a >>> consequence of it. As you write, submodules provide no benefits >>> whatsoever in terms of modularity, but the overhead in terms of >>> metadata, IANA registration etc. is pretty much the same as for >>> modules. >> In case YANG 2.0 is ever done, I suggest someone files a proposal to >> remove submodules if the cost/benefit ratio is at odds. There is >> nothing wrong with removing stuff that has been found problematic. > I agree. > > I've added https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmod-2Dwg_yang-2Dnext_issues_26&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7owI&s=-kR4fUtXArQy0RwWb32DpT1bP4X_cNqt2zJVoC0JiX8&e= > > Rob > >> The motivation for submodules was that organizations maintaining large >> modules with multiple people can do so without having to mess around >> with tools like m4 scripts to produce a single module from 'snippets' >> and to avoid integration surprises. But perhaps using m4 scripts and >> decent version control systems (that can integrate and compile on >> checkin) is indeed cheaper than having submodules part of the YANG >> language itself. >> >> /js >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7owI&s=t7vGIH8ABuAm00e-bkSowD9eawModGq0N2OkjANtpYI&e= > . > --------------E49EEFE75767679D52F30E5B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi William,

The github issue is really only to track this point for further discussion and to the avoid losing the useful discussion on the alias.

I think that there is often useful discussion on the NETMOD alias that ends up at least with a partial resolution, but that never gets documented anywhere.  In a few cases these end up as errata, but often they either get deferred to a future version, or are treated as collective wisdom from the WG participants.  For the latter case, I'm hoping that we can store the summary of some of these discussions on a community maintained wiki.


YANG 1/1.1 modules using sub-modules could be upgraded into a single YANG 2.0 module.  This is an allowed backwards compatible change with no changes to the node paths or namespaces.

The pertinent text is in RFC 7950, sec 11: 

   o  A module may be split into a set of submodules or a submodule may
      be removed, provided the definitions in the module do not change
      in any way other than those allowed here.
Thanks,
Rob


On 21/08/2017 14:44, Ivory, William wrote:
Hi Rob,

That would make it very hard to update existing 1.x YANG models to use new features in YANG 2.x if they used submodules.  Maybe that's something that no one would ever consider doing anyway, or maybe YANG 1.1 already has similar differences to 1.0?  I had (perhaps naively) assumed that you could migrate a namespace / model from YANG 1.0 to 2.0?

Regards,

William

-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton
Sent: 21 August 2017 11:24
To: netmod@ietf.org
Subject: Re: [netmod] Query about augmenting module from submodule in YANG 1.0



On 09/08/2017 16:13, Juergen Schoenwaelder wrote:

On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka wrote:

I remember that in early stages of YANG there was some irrational 
fear of introducing too many namespaces, and submodules may be a 
consequence of it. As you write, submodules provide no benefits 
whatsoever in terms of modularity, but the overhead in terms of 
metadata, IANA registration etc. is pretty much the same as for 
modules.

In case YANG 2.0 is ever done, I suggest someone files a proposal to 
remove submodules if the cost/benefit ratio is at odds. There is 
nothing wrong with removing stuff that has been found problematic.

I agree.

I've added https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmod-2Dwg_yang-2Dnext_issues_26&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7owI&s=-kR4fUtXArQy0RwWb32DpT1bP4X_cNqt2zJVoC0JiX8&e= 

Rob


The motivation for submodules was that organizations maintaining large 
modules with multiple people can do so without having to mess around 
with tools like m4 scripts to produce a single module from 'snippets'
and to avoid integration surprises. But perhaps using m4 scripts and 
decent version control systems (that can integrate and compile on
checkin) is indeed cheaper than having submodules part of the YANG 
language itself.

/js


_______________________________________________
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7owI&s=t7vGIH8ABuAm00e-bkSowD9eawModGq0N2OkjANtpYI&e= 
.

--------------E49EEFE75767679D52F30E5B-- From nobody Mon Aug 21 07:18:23 2017 Return-Path: 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 CD6DF13247A for ; Mon, 21 Aug 2017 07:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.011 X-Spam-Level: X-Spam-Status: No, score=-3.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net 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 480QZHUStwNq for ; Mon, 21 Aug 2017 07:18:19 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0114.outbound.protection.outlook.com [104.47.40.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110471321A8 for ; Mon, 21 Aug 2017 07:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=w36q/Swrr150hH/5RwsW8J5MfLQth5kexyO2KqMelLc=; b=QWFJcSBIipnP6SRz0TqPiqG/9YRF3vGSREUbSNHxgmL+6uSd2cbpLf7Mb5F+7/HEKl8aSm6L1aQEdcyKe6INHYDGLoR/ABBZM/vAUi4tUWzsBotPsrgSvCpyNo72WDyVB70p+t+MP6cNP/x051VOufj9C5GJoMHVIpxPPrGoYyY= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1106.namprd05.prod.outlook.com (10.160.113.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.4; Mon, 21 Aug 2017 14:18:16 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1385.008; Mon, 21 Aug 2017 14:18:16 +0000 From: Kent Watsen To: "Clyde Wildes (cwildes)" , "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15 Thread-Index: AQHS+qgfFNU1WyBT406RudsboUthDKKD0SUAgAAwdQCACta0gA== Date: Mon, 21 Aug 2017 14:18:16 +0000 Message-ID: <6AF622E8-1CDE-45B2-ADB3-241BA6F0F610@juniper.net> References: <0558E64E-2CE7-4C3E-94C8-1CA7CE78171E@cisco.com> <3660A72B-4169-4577-8AE3-F9DB6EADC0CF@cisco.com> In-Reply-To: <3660A72B-4169-4577-8AE3-F9DB6EADC0CF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1106; 6:sGL3lrOX9YSY5VQQMUQguUU4hE9DB4bLHWH5miabMg3roxk8TaOddkeKkIFw0PiCXtFtup06E6H4oLeoqTYw7ECUgJuPFL/9S2Ed5Y+i7BLqIuhUIrDM++51jbhiDBtmEYOZtCWih/Toufr1qYIefyDsfwfoMB6kl1CGIKcMD+k04TVdvnmzcqDMt6FMY+K8Gb5JpBigFwrsp9AbYm20sgS9waTPMheLeDOGZX3bhdIqkqjdlUfdb9/LJgXyUk7cwrdrvnz0z70zKRPsKKwayU1mBDauKG/xiJS9AOZWQ1Ct3IhbAktOHX7Tj+aC89+d+F+PpGjcXoKgGnGq0nmTYA==; 5:VazLC/rJFvKEi+CQrW8hJ/AcPvharUGJ/ihmht/1sfUYDZVBv+mEC3UPmx6MXT3J2Ilatw8RwQ49FT+DJP+w75W4mHhiAsuyeaRvodAlYeEHKM/NfbaEY/x1MxG/sdlH8NmhozP2VWR8dcO++tHmow==; 24:Gf41TTEA1wYAReZ82xSI/IPaSVWigmc8DHfWzCtdsu+Z/2zpmcLUYLWj0GMonhmwD5UK4kjzmZVS9W7WeIwimztVGIRNyPO0SSryNoQzIQg=; 7:9RhqsQMvYoHQ7oBTbrMDbJ7K55l1CVbo8HZYSoD1m5d/K2h2jQNXdnDDdIFGEVU8xOk9KZDYGOrNZ/ceXxmyp53dLLWGDyC/SxQX6AmdzKObGHWdAjC9jNVH4hdnMKh7/cEeDzkcx8eV3Xhq3dTixFibKwfaIwxaSmwPt+07P9szrZf6fU+mcW4tReFea6qDmMnt40Ce/G7NntIsFCsPozhw9cdoIEYUiKWJGtbhJ08= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6d31a15f-9b83-44ca-0ae6-08d4e89f7753 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1106; x-ms-traffictypediagnostic: BN3PR0501MB1106: x-exchange-antispam-report-test: UriScan:(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1106; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1106; x-forefront-prvs: 040655413E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(189002)(76104003)(199003)(54356999)(76176999)(50986999)(82746002)(230783001)(6436002)(97736004)(189998001)(81156014)(81166006)(8676002)(229853002)(3846002)(7736002)(83716003)(36756003)(83506001)(6116002)(305945005)(102836003)(93886005)(2950100002)(66066001)(5660300001)(8936002)(2900100001)(3660700001)(105586002)(77096006)(6486002)(2501003)(3280700002)(33656002)(86362001)(6506006)(25786009)(6512007)(68736007)(99286003)(106356001)(53936002)(14454004)(478600001)(4001350100001)(2906002)(6246003)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1106; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <5E8CD69CDEB06D499E11086FBD4D7F5D@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Aug 2017 14:18:16.4676 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1106 Archived-At: Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-15 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 14:18:22 -0000 SGkgQ2x5ZGUsDQoNClRyaW1taW5nIGRvd24gdG8ganVzdCB0aGUgYWN0aXZlIGRpc2N1c3Npb24g cG9pbnRzLg0KDQoNCg0KDQogICAgPiAgICAgICAxMi4gUzMsIFA4OiBJJ20gaGF2aW5nIHRyb3Vi bGUgdW5kZXJzdGFuZGluZyB0aGUgcHNldWRvY29kZS4gIFdoYXQNCiAgICA+ICAgIGhhcHBlbnMg aWYgUyBhbmQvb3IgRiBhcmUgbm90IHByZXNlbnQ/ICBDYW4gUyBvciBGIGV2ZXIgbm90IGJlDQog ICAgPiAgICBwcmVzZW50PyAtIGxvb2tpbmcgYXQgdGhlIHRyZWUgZGlhZ3JhbSwgaXQgc2VlbXMg bGlrZSB0aGV5IG1pZ2h0DQogICAgPiAgICBhbHdheXMgYmUgc2V0IHRvIHNvbWV0aGluZyBpbiB0 aGUgbW9kZWwuDQogICAgPg0KICAgID4gW2NseWRlXSBTIG9yIEYgbWlnaHQgbm90IGJlIHByZXNl bnQuIA0KICAgIA0KICAgIEluIHRoZSBZQU5HIG1vZHVsZSwgZmFjaWxpdHktbGlzdCBpcyBrZXll ZCBieSBbZmFjaWxpdHkgc2V2ZXJpdHldLCB3aGljaA0KICAgIG1lYW5zIHRoZSB2YWx1ZXMgYXJl IGFsd2F5cyBwcmVzZW50LCByaWdodD8NCiAgICANCltjbHlkZV0gVGhlcmUgYXJlIHR3byBwYXRo cyBzcGVjaWZ5aW5nIGEgZmFjaWxpdHktZmlsdGVyIGluIHdoaWNoIGNhc2UgUyBvciBGIGFyZSBw cmVzZW50LCBvciBzcGVjaWZ5aW5nIGEgcGF0dGVybi1tYXRjaCBpbiB3aGljaCBjYXNlIHRoZXkg bWlnaHQgbm90IGJlIHByZXNlbnQgaWYgZmFjaWxpdHktZmlsdGVyIGlzIG5vdCBzcGVjaWZpZWQu ICAgDQoNCjxLRU5UPiBpZiB0aGlzIGlzIHdoYXQgeW91J3JlIHRyeWluZyB0byBzYXksIHRoZW4g eW91ciBwc2V1ZG9jb2RlIGlzbid0IHJpZ2h0Lg0KUmVnYXJkbGVzcyBpZiB5b3UgYWdyZWUgd2l0 aCBtZSBvciBub3QsIHlvdSBuZWVkIHRvIHNvbWVob3cgbWFrZSB0aGlzIHNlY3Rpb24gY2xlYXJl ci4NCg0KDQoNCiAgICA+ICAgIDE0LiBTMy4xOiBpcyAvc3lzbG9nL2FjdGlvbnMvcmVtb3RlL2Rl c3RpbmF0aW9uL3Rscy8gbWlzc2luZyBhbg0KICAgID4gICAgJ2FkZHJlc3MnIGxlYWY/DQogICAg Pg0KICAgID4gW2NseWRlXSBub3QgYXMgZmFyIGFzIEkga25vdw0KICAgID4NCiAgICANCiAgICBM b29raW5nIGF0IHRoZSB0cmVlLWRpYWdyYW0sIHRoZSAndGxzJyBjYXNlIGRvZXNuJ3Qgc2VlbSB0 byBoYXZlIHRoZQ0KICAgIGFkZHJlc3Mgb3IgcG9ydCBmaWVsZHMuICBGV0lXLCB0aGUgaWV0Zi10 bHMtY2xpZW50IG1vZHVsZSBkb2Vzbid0IA0KICAgIHByb3ZpZGUgdGhlc2UgZmllbGRzIHNvIHRo YXQgY29uc3VtaW5nIG1vZHVsZXMgY2FuIGNvbmZpZ3VyZSBhIG5vcm1hbA0KICAgIGNsaWVudCB2 ZXJzdXMgYSBjbGllbnQgbGlzdGVuaW5nIGZvciBjYWxsLWhvbWUgY29ubmVjdGlvbnMuLi4NCiAg ICANCiAgICAJICAgKy0tOih0Y3ApDQogICAgCSAgIHwgICstLXJ3IHRjcA0KICAgIAkgICB8ICAg ICArLS1ydyBhZGRyZXNzPyAgIGluZXQ6aG9zdA0KICAgIAkgICB8ICAgICArLS1ydyBwb3J0PyAg ICAgIGluZXQ6cG9ydC1udW1iZXINCiAgICAJICAgKy0tOih1ZHApDQogICAgCSAgICAgICstLXJ3 IHVkcA0KICAgIAkgICAgICAgICArLS1ydyBhZGRyZXNzPyAgIGluZXQ6aG9zdA0KICAgIAkgICAg ICAgICArLS1ydyBwb3J0PyAgICAgIGluZXQ6cG9ydC1udW1iZXINCiAgICAJICAgICAgKy0tOih0 bHMpDQogICAgCSAgICAgICAgICstLXJ3IHRscw0KICAgICAgICAgICAgICAgICAgICAgIDxhZGRy ZXNzL3BvcnQgbWlzc2luZyBoZXJlLCByaWdodD8+DQogICAgCSAgICAgICAgICAgICstLXJ3IHNl cnZlci1hdXRoDQogICAgICAgICAgICAgICAgICAgICAgICAgPG1vcmUgaWV0Zi10bHMtY2xpZW50 IGdyb3VwaW5nIGhlcmU+DQoNCltjbHlkZV0gSGVyZSBpcyB3aGF0IHRoZSB0cmVlIGxvb2tzIGxp a2UgaW4gdGhlIGxhdGVzdCBkcmFmdOKApg0KDQogICAgICAgICAgICAgICAgICAgfCAgKy0tOih0 bHMpDQogICAgICAgICAgICAgICAgICAgfCAgICAgKy0tcncgdGxzDQogICAgICAgICAgICAgICAg ICAgfCAgICAgICAgKy0tcncgc2VydmVyLWF1dGgNCiAgICAgICAgICAgICAgICAgICB8ICAgICAg ICB8ICArLS1ydyB0cnVzdGVkLWNhLWNlcnRzPyAgICAgICAtPiAva3M6a2V5c3RvcmUvdHJ1c3Rl ZC1jZXJ0aWZpY2F0ZXMvbmFtZQ0KICAgICAgICAgICAgICAgICAgIHwgICAgICAgIHwgICstLXJ3 IHRydXN0ZWQtc2VydmVyLWNlcnRzPyAgIC0+IC9rczprZXlzdG9yZS90cnVzdGVkLWNlcnRpZmlj YXRlcy9uYW1lDQogICAgICAgICAgICAgICAgICAgfCAgICAgICAgKy0tcncgY2xpZW50LWF1dGgN CiAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8ICArLS1ydyAoYXV0aC10eXBlKT8NCiAgICAg ICAgICAgICAgICAgICB8ICAgICAgICB8ICAgICArLS06KGNlcnRpZmljYXRlKQ0KICAgICAgICAg ICAgICAgICAgIHwgICAgICAgIHwgICAgICAgICstLXJ3IGNlcnRpZmljYXRlPyAgIC0+IC9rczpr ZXlzdG9yZS9rZXlzL2tleS9jZXJ0aWZpY2F0ZXMvY2VydGlmaWNhdGUvbmFtZQ0KICAgICAgICAg ICAgICAgICAgIHwgICAgICAgICstLXJ3IGhlbGxvLXBhcmFtcyB7dGxzLWNsaWVudC1oZWxsby1w YXJhbXMtY29uZmlnfT8NCiAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8ICArLS1ydyB0bHMt dmVyc2lvbnMNCiAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8ICB8ICArLS1ydyB0bHMtdmVy c2lvbiogICBpZGVudGl0eXJlZg0KICAgICAgICAgICAgICAgICAgIHwgICAgICAgIHwgICstLXJ3 IGNpcGhlci1zdWl0ZXMNCiAgICAgICAgICAgICAgICAgICB8ICAgICAgICB8ICAgICArLS1ydyBj aXBoZXItc3VpdGUqICAgaWRlbnRpdHlyZWYNCiAgICAgICAgICAgICAgICAgICB8ICAgICAgICAr LS1ydyBhZGRyZXNzPyAgICAgICAgaW5ldDpob3N0DQogICAgICAgICAgICAgICAgICAgfCAgICAg ICAgKy0tcncgcG9ydD8gICAgICAgICAgIGluZXQ6cG9ydC1udW1iZXINCiAgICANCkFkZHJlc3Mg YW5kIHBvcnQgYXJlIHRoZXJlLiBQbGVhc2UgY2xhcmlmeSBvbiB3aGF0IHlvdSB0aGluayBpcyBt aXNzaW5nLg0KICANClRoaXMgaXMgd2hhdCBpdCBsb29rcyBsaWtlIGluIHRoZSBtb2RlbDoNCg0K ICAgICAgICAgICAgY2FzZSB0bHMgew0KICAgICAgICAgICAgICBjb250YWluZXIgdGxzIHsNCiAg ICAgICAgICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICAgICAgICAgIlRoaXMgY29udGFp bmVyIGRlc2NyaWJlcyB0aGUgVExTIHRyYW5zcG9ydCBvcHRpb25zLiI7DQogICAgICAgICAgICAg ICAgcmVmZXJlbmNlDQogICAgICAgICAgICAgICAgICAiUkZDIDU0MjU6IFRyYW5zcG9ydCBMYXll ciBTZWN1cml0eSAoVExTKSBUcmFuc3BvcnQgDQogICAgICAgICAgICAgICAgICAgTWFwcGluZyBm b3IgU3lzbG9nICI7DQogICAgICAgICAgICAgICAgdXNlcyB0bHNjOnRscy1jbGllbnQtZ3JvdXBp bmc7DQogICAgICAgICAgICAgICAgbGVhZiBhZGRyZXNzIHsNCiAgICAgICAgICAgICAgICAgIHR5 cGUgaW5ldDpob3N0Ow0KICAgICAgICAgICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAgICAg ICAgICAgICAgIlRoZSBsZWFmIHVuaXF1ZWx5IHNwZWNpZmllcyB0aGUgYWRkcmVzcyBvZiANCiAg ICAgICAgICAgICAgICAgICAgIHRoZSByZW1vdGUgaG9zdC4gT25lIG9mIHRoZSBmb2xsb3dpbmcg bXVzdCBiZSANCiAgICAgICAgICAgICAgICAgICAgIHNwZWNpZmllZDogYW4gaXB2NCBhZGRyZXNz LCBhbiBpcHY2IGFkZHJlc3MsIA0KICAgICAgICAgICAgICAgICAgICAgb3IgYSBob3N0IG5hbWUu IjsNCiAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgbGVhZiBwb3J0IHsNCiAgICAg ICAgICAgICAgICAgIHR5cGUgaW5ldDpwb3J0LW51bWJlcjsNCiAgICAgICAgICAgICAgICAgIGRl ZmF1bHQgNjUxNDsNCiAgICAgICAgICAgICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgICAg ICAgICAgICJUQ1AgcG9ydCA2NTE0IGhhcyBiZWVuIGFsbG9jYXRlZCBhcyB0aGUgZGVmYXVsdCAN CiAgICAgICAgICAgICAgICAgICAgIHBvcnQgZm9yIHN5c2xvZyBvdmVyIFRMUy4iOw0KICAgICAg ICAgICAgICAgIH0NCiAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgfQ0KDQoNCjxLRU5UPiBT b3JyeSwgaXQgZGlkbid0IHNlZSB0aGVtIHdheSBkb3duIGF0IHRoZSBib3R0b20uICBJbiBhbGwg bXkgZHJhZnRzLCBJIGhhdmUgdGhlc2UgbGVhZnMgYmVmb3JlIHRoZSB0bHMtY2xpZW50LWdyb3Vw aW5nLiAgQ2FuIHlvdSBwbGVhc2Ugc3dpdGNoIHRoZSBvcmRlciBhcm91bmQ/DQoNCg0KDQoNCiAg ICA+IDE5LiBTNC4xLCBpbiB0aGUgJ3NldmVyaXR5LWZpbHRlcicgZ3JvdXBpbmcsIHdoeSBkb2Vz IGxlYWYgJ3NldmVyaXR5Jw0KICAgID4gICAgaGF2ZSB2YWx1ZXMgc2V0IGZvciBlbnVtcyAnbm9u ZScgYW5kICdhbGwnPyAgV2hlbiB3b3VsZCB0aGVzZSB2YWx1ZXMNCiAgICA+ICAgIGJlIHVzZWQs IGFzIG9wcG9zZWQgdG8gdGhlIGVudW0ncyBuYW1lIHN0cmluZz8gIElmIHlvdSBkbyBuZWVkIHZh bHVlcywNCiAgICA+ICAgIHRoZW4gc2hvdWxkbid0ICdub25lJyBiZSAyMTQ3NDgzNjQ3IChzbyBu b3RoaW5nIGNhbiBiZSBncmVhdGVyIHRoYW4gaXQpDQogICAgPiAgICBhbmQgJ2FsbCcgYmUgLTIx NDc0ODM2NDggKHNvIGV2ZXJ5dGhpbmcgaXMgZ3JlYXRlciB0aGFuIGl0KT8NCiAgICA+DQogICAg PiBbY2x5ZGVdIOKAmG5vbmXigJkgYW5kIOKAmGFsbOKAmSBhcmUgc2V0IHRvIHZhbHVlcyB0aGF0 IGFyZSBub3QgZGVmaW5lZCBpbiANCiAgICA+IFJGQyA1NDI0LiBUaGVzZSB2YWx1ZXMgd2VyZSBw cmV2aW91c2x5IHN1Z2dlc3RlZCBieSBNYXJ0aW4gQmrDtnJrbHVuZA0KICAgIA0KICAgIEZpbmUs IGJ1dCBsZXQncyByZS1ldmFsdWF0ZSB0aGUgdmFsdWVzIG5vdy4gIEltYWdlIGhhdmluZyBhIHZh cmlhYmxlIHgNCiAgICBhbmQgc3RlcHBpbmcgdGhyb3VnaCB0aGUgc2VsZWN0b3IgbGlzdDoNCiAg ICANCiAgICAgIGlmIHggPj0gZmFjaWxpdHktbGlzdC9zZXZlcml0eSB0aGVuIGZvby4NCiAgICAN CiAgICBOb3cgaW1hZ2luZSBpdCByZWFkOg0KICAgIA0KICAgICAgaWYgeCA+PSAnYWxsJyB0aGVu IGZvby4NCiAgICANCiAgICBXaGF0IGludGVnZXIgdmFsdWUgZm9yICdhbGwnIHdvdWxkIGFsd2F5 cyBlbnN1cmUgVHJ1ZT8gIE1JTi1JTlQNCiAgICBMaWtld2lzZSwgeW91IGNhbiBzZWUgdGhhdCBN QVgtSU5UIGlzIHRoZSBiZXN0IHZhbHVlIGZvciAnbm9uZScuDQogICAgDQpbY2x5ZGVdIEkgd2ls bCBiZSBjaGFuZ2UgdGhlc2UgdG86DQoNCidub25lJyAyMTQ3NDgzNjQ3IChzbyBub3RoaW5nIGNh biBiZSBncmVhdGVyIHRoYW4gaXQpDQonYWxsJyAtMjE0NzQ4MzY0OCAoc28gZXZlcnl0aGluZyBp cyBncmVhdGVyIHRoYW4gaXQpPw0KDQoNCjxLRU5UPiBJIHRoaW5rIHNvLCBidXQgd2Ugc2hvdWxk IGdldCBNYXJ0aW4ncyBjb25maXJtYXRpb24uDQoNCg0KDQpLLg0KDQoNCg0K From nobody Mon Aug 21 08:05:17 2017 Return-Path: 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 C68FD132A65 for ; Mon, 21 Aug 2017 08:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 FBCMBQMszMoM for ; Mon, 21 Aug 2017 08:05:14 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6F8B13207A for ; Mon, 21 Aug 2017 08:05:13 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id 16so83812977qtz.4 for ; Mon, 21 Aug 2017 08:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9Anh2JspWL+9M5nhB8efiGeEZeIMWZUoIt4Lb1kXRhI=; b=Bq4BSVp3OX6kAHYzQ0GGpvDojjMkmtbZQ7w20umiuSUwc3DNvASg/4+NXtgTJxo7Z4 75guPlfkF5uM5VRpY6VuE5Th7f+gsmkIzlgbkMkOlH8J6JRTjleNiWWrWVkCO93Fci5Y wipQhBI7m5TXw5+5m0bTnzzeijV2z1w4OJs6lC6ia9DYlvovyh2eseZeQuznZhVbMZdf 6M/jLY3A0JJwFTWZJiguRN9cAthVWvHkI4gK4GmIXm7535Zn0uuXU7gVwBpS+ruwQeEz h06G1h8kAD6N53EFNR2ftlKWSR7pWnmlAIsXeZlkaS0uRq01KKoLW4KfqMqMZJv2ZvPj vEsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9Anh2JspWL+9M5nhB8efiGeEZeIMWZUoIt4Lb1kXRhI=; b=liaXPS4JvcZ4lwZnigTBCfyqnCFaViwYitYj9OXtRo4nO38DPbvdLDTb5Ii9Fn00+5 ezgdF9VeL2xHU08E3r3L+QLjNt5J/L0JfjWU8MFULtiYulWE2669ua8fAGkSEwo7iBwu 1O3jitPESMwZRgtMqQHtVb5gqo3PI0Rmv3F+zbM6HVe65ZWHxeHxmt5l566X6fvmi5yi 7keob+kUeKDPK6mO5FNfn8sEHjydCAZw9TjSgQuDSDD878qk1KRMMikIfsqlmHqu1cX7 58PggfH+s/XY+jt+fYvHldPolaahUWQ1m1TmB56IVvIcXnC7j/o/S+t3ZxbvHjZmAs4l aiHg== X-Gm-Message-State: AHYfb5jMsdgil/EI3Zbpj/mrVhexg9SKcMziGj6jbxayfXHsbQshazOA PRjlnV//aEFtfA8scrG6nowY470wNw== X-Received: by 10.200.14.72 with SMTP id j8mr24231277qti.124.1503327912773; Mon, 21 Aug 2017 08:05:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.97.73 with HTTP; Mon, 21 Aug 2017 08:05:12 -0700 (PDT) In-Reply-To: <20170817161601.GC5993@spritelink.se> References: <1D830FD0-547F-4F5D-A169-B05A8DC013B3@juniper.net> <20170817161601.GC5993@spritelink.se> From: Sonal Agarwal Date: Mon, 21 Aug 2017 08:05:12 -0700 Message-ID: To: Kristian Larsson Cc: Kent Watsen , "netmod@ietf.org" Content-Type: multipart/alternative; boundary="089e08225dac38cd33055744ceaa" Archived-At: Subject: Re: [netmod] modelling of packet-action WG Last Call for draft-ietf-netmod-acl-model-11 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 15:05:16 -0000 --089e08225dac38cd33055744ceaa Content-Type: text/plain; charset="UTF-8" Hi Kristian, Thank you for your feedback on the model. I do not recollect that anybody has questioned the 'action' statement in the last year. The 'action' statement and the 'choice' container was something that was inherited when the model was initially written. It is easy to convert this to an identity. I am also wondering if we should explicitly define 3 identities. PERMIT/ACCEPT - allow/accept the packet DROP - drop packet and send ICMP message REJECT - drop packet and do not send ICMP message Could you please give me your thoughts on this? Best regards, Sonal. On Thu, Aug 17, 2017 at 9:16 AM, Kristian Larsson wrote: > Pardon my ignorance as this might have been asked before but why > is the actions/packet-handling modelled as a choice? It would > seem an identity would be better or perhaps even an enum? > > kll > > On Fri, Jul 07, 2017 at 06:34:28PM +0000, Kent Watsen wrote: > > > > > > This is a notice to start a three week NETMOD WG last call for the > > document: > > > > Network Access Control List (ACL) YANG Data Model > > https://tools.ietf.org/html/draft-ietf-netmod-acl-model-11 > > > > Note: Three weeks is more than needed, especially given this > > draft has been through Last Call before, but we understand > > folks are busy these days. > > > > Please indicate your support or concerns by Friday, July 28, 2017. > > > > We are particularly interested in statements of the form: > > * I have reviewed this draft and found no issues. > > * I have reviewed this draft and found the following issues: ... > > > > As well as: > > * I have implemented the data model in this draft. > > * I am implementing the data model in this draft. > > * I am considering to implement the data model in this draft. > > * I am not considering to implement the data model in this draft. > > > > Thank you, > > NETMOD WG Chairs > > > > > > > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Kristian Larsson KLL-RIPE > +46 704 264511 kll@spritelink.net > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --089e08225dac38cd33055744ceaa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Kristian,

Thank you for your feedbac= k on the model. I do not recollect that anybody has questioned the 'act= ion' statement in the last year. The 'action' statement and the= 'choice' container was something that was inherited when the model= was initially written.

It is easy to convert this= to an identity. I am also wondering if we should explicitly define 3 ident= ities.

PERMIT/ACCEPT - allow/accept the packet
DROP - drop packet and send ICMP message
REJECT - drop pac= ket and do not send ICMP message

Could you please = give me your thoughts on this?

Best regards,
=
Sonal.


On Thu, Aug 17, 2017 at 9:16 AM, Kristian Larsson <= kristian@spritelink.net> wrote:
Pardon my ignorance as this might have been asked before but why
is the actions/packet-handling modelled as a choice? It would
seem an identity would be better or perhaps even an enum?

=C2=A0 =C2=A0kll

On Fri, Jul 07, 2017 at 06:34:28PM +0000, Kent Watsen wrote:
>
>
> This is a notice to start a three week NETMOD WG last call for the
> document:
>
>=C2=A0 =C2=A0 =C2=A0Network Access Control List (ACL) YANG Data Model >=C2=A0 =C2=A0 =C2=A0https://tools.ietf= .org/html/draft-ietf-netmod-acl-model-11
>
> Note: Three weeks is more than needed, especially given this
>=C2=A0 =C2=A0 =C2=A0 =C2=A0draft has been through Last Call before, but= we understand
>=C2=A0 =C2=A0 =C2=A0 =C2=A0folks are busy these days.
>
> Please indicate your support or concerns by Friday, July 28, 2017.
>
> We are particularly interested in statements of the form:
>=C2=A0 =C2=A0* I have reviewed this draft and found no issues.
>=C2=A0 =C2=A0* I have reviewed this draft and found the following issue= s: ...
>
> As well as:
>=C2=A0 =C2=A0* I have implemented the data model in this draft.
>=C2=A0 =C2=A0* I am implementing the data model in this draft.
>=C2=A0 =C2=A0* I am considering to implement the data model in this dra= ft.
>=C2=A0 =C2=A0* I am not considering to implement the data model in this= draft.
>
> Thank you,
> NETMOD WG Chairs
>
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Kristian Larsson=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 KLL-RIPE
+46 704 264511<= /a>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 kll@spritelink.net

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

--089e08225dac38cd33055744ceaa-- From nobody Mon Aug 21 08:15:05 2017 Return-Path: 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 41C09132650 for ; Mon, 21 Aug 2017 08:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 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 k_gnAG6nSDO9 for ; Mon, 21 Aug 2017 08:14:53 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D7AE132A69 for ; Mon, 21 Aug 2017 08:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13183; q=dns/txt; s=iport; t=1503328492; x=1504538092; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=VHY6qykY5vo1CCWT4LP4RZKF8nRBg/bFdGDJ7ccuW/E=; b=Z6+3YbJ6ZexhskZxSOXZCC8nMjnombzqWfHVzliyyWeOV2250pE4vpjG ORc1eeYDGn5PShx30YK0M9EUbmxUL+6Y0CCClvFiCUGPG9dcoj8jcBGrk 9Pk91qCilAyVLWWi5sGOv5E0C8E8j/K9SThuFZ3B+7IoYBrBOm1NFAln7 g=; X-IronPort-AV: E=Sophos;i="5.41,409,1498521600"; d="scan'208,217";a="654096013" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Aug 2017 15:14:50 +0000 Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7LFEokN004704; Mon, 21 Aug 2017 15:14:50 GMT To: "Acee Lindem (acee)" , "Ivory, William" , "'netmod@ietf.org'" , Andy Bierman References: <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com> <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com> <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com> From: Robert Wilton Message-ID: <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com> Date: Mon, 21 Aug 2017 16:14:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------825ED476C42CF7428E698B97" Content-Language: en-US Archived-At: Subject: [netmod] Pattern statements [was Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 15:15:04 -0000 This is a multi-part message in MIME format. --------------825ED476C42CF7428E698B97 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Acee, That makes sense. The other thing that I think that we have got wrong is modelling regex pattern statements. I think that it would be much better if these were written to be less exhaustive and much simpler. E.g. the "route distinguisher" pattern in draft-ietf-rtgwg-routing-types-09 is defined as this: pattern '(0:(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|' + '6[0-4][0-9]{3}|' + '[0-5]?[0-9]{0,3}[0-9]):(429496729[0-5]|' + '42949672[0-8][0-9]|' + '4294967[01][0-9]{2}|429496[0-6][0-9]{3}|' + '42949[0-5][0-9]{4}|' + '4294[0-8][0-9]{5}|429[0-3][0-9]{6}|' + '42[0-8][0-9]{7}|4[01][0-9]{8}|' + '[0-3]?[0-9]{0,8}[0-9]))|' + '(1:((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|' + '25[0-5])\.){3}([0-9]|[1-9][0-9]|' + '1[0-9]{2}|2[0-4][0-9]|25[0-5])):(6553[0-5]|' + '655[0-2][0-9]|' + '65[0-4][0-9]{2}|6[0-4][0-9]{3}|' + '[0-5]?[0-9]{0,3}[0-9]))|' + '(2:(429496729[0-5]|42949672[0-8][0-9]|' + '4294967[01][0-9]{2}|' + '429496[0-6][0-9]{3}|42949[0-5][0-9]{4}|' + '4294[0-8][0-9]{5}|' + '429[0-3][0-9]{6}|42[0-8][0-9]{7}|4[01][0-9]{8}|' + '[0-3]?[0-9]{0,8}[0-9]):' + '(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|' + '6[0-4][0-9]{3}|' + '[0-5]?[0-9]{0,3}[0-9]))|' + '(6(:[a-fA-F0-9]{2}){6})|' + '(([3-57-9a-fA-F]|[1-9a-fA-F][0-9a-fA-F]{1,3}):' + '[0-9a-fA-F]{1,12})'; } But I think that it would be much easier to read, and quite possibly more performant to execute, if the pattern regex was written something like the following: pattern: '(0:[0-9]{1,5}:[0-9]{1,10})| (1:([0-9]{1,3}\.){4}:[0-9]{1,5})| (2:[0-9]{1,10}:0:[0-9]{1,5})| (6(:[a-fA-F0-9]{2}){6})'; Of course, this would allow more invalid values, but most servers would be expected to reject those when it converts them into an internal binary format any way. What do you, and others, think? Thanks, Rob On 21/08/2017 15:01, Acee Lindem (acee) wrote: > Hi William, Rob, Andy, > > Given their limited usefulness and the detriments, perhaps we should > discourage the creation of new submodules in RFC6087Bis. > > Thanks, > Acee > > On 8/21/17, 9:44 AM, "netmod on behalf of Ivory, William" > wrote: > >> Hi Rob, >> >> That would make it very hard to update existing 1.x YANG models to use >> new features in YANG 2.x if they used submodules. Maybe that's something >> that no one would ever consider doing anyway, or maybe YANG 1.1 already >> has similar differences to 1.0? I had (perhaps naively) assumed that you >> could migrate a namespace / model from YANG 1.0 to 2.0? >> >> Regards, >> >> William >> >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton >> Sent: 21 August 2017 11:24 >> To: netmod@ietf.org >> Subject: Re: [netmod] Query about augmenting module from submodule in >> YANG 1.0 >> >> >> >> On 09/08/2017 16:13, Juergen Schoenwaelder wrote: >>> On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka wrote: >>>> I remember that in early stages of YANG there was some irrational >>>> fear of introducing too many namespaces, and submodules may be a >>>> consequence of it. As you write, submodules provide no benefits >>>> whatsoever in terms of modularity, but the overhead in terms of >>>> metadata, IANA registration etc. is pretty much the same as for >>>> modules. >>> In case YANG 2.0 is ever done, I suggest someone files a proposal to >>> remove submodules if the cost/benefit ratio is at odds. There is >>> nothing wrong with removing stuff that has been found problematic. >> I agree. >> >> I've added >> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmod-2Dw >> g_yang-2Dnext_issues_26&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ >> 2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7ow >> I&s=-kR4fUtXArQy0RwWb32DpT1bP4X_cNqt2zJVoC0JiX8&e= >> >> Rob >> >>> The motivation for submodules was that organizations maintaining large >>> modules with multiple people can do so without having to mess around >>> with tools like m4 scripts to produce a single module from 'snippets' >>> and to avoid integration surprises. But perhaps using m4 scripts and >>> decent version control systems (that can integrate and compile on >>> checkin) is indeed cheaper than having submodules part of the YANG >>> language itself. >>> >>> /js >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_ >> listinfo_netmod&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwky >> XmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7owI&s=t7vG >> IH8ABuAm00e-bkSowD9eawModGq0N2OkjANtpYI&e= >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod --------------825ED476C42CF7428E698B97 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Acee,

That makes sense.

The other thing that I think that we have got wrong is modelling regex pattern statements.  I think that it would be much better if these were written to be less exhaustive and much simpler.

E.g. the "route distinguisher" pattern in draft-ietf-rtgwg-routing-types-09 is defined as this:

         pattern
           '(0:(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
         +     '6[0-4][0-9]{3}|'
         +     '[0-5]?[0-9]{0,3}[0-9]):(429496729[0-5]|'
         +     '42949672[0-8][0-9]|'
         +     '4294967[01][0-9]{2}|429496[0-6][0-9]{3}|'
         +     '42949[0-5][0-9]{4}|'
         +     '4294[0-8][0-9]{5}|429[0-3][0-9]{6}|'
         +     '42[0-8][0-9]{7}|4[01][0-9]{8}|'
         +     '[0-3]?[0-9]{0,8}[0-9]))|'
         + '(1:((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|'
         +     '25[0-5])\.){3}([0-9]|[1-9][0-9]|'
         +     '1[0-9]{2}|2[0-4][0-9]|25[0-5])):(6553[0-5]|'
         +     '655[0-2][0-9]|'
         +     '65[0-4][0-9]{2}|6[0-4][0-9]{3}|'
         +     '[0-5]?[0-9]{0,3}[0-9]))|'
         + '(2:(429496729[0-5]|42949672[0-8][0-9]|'
         +     '4294967[01][0-9]{2}|'
         +     '429496[0-6][0-9]{3}|42949[0-5][0-9]{4}|'
         +     '4294[0-8][0-9]{5}|'
         +     '429[0-3][0-9]{6}|42[0-8][0-9]{7}|4[01][0-9]{8}|'
         +     '[0-3]?[0-9]{0,8}[0-9]):'
         +     '(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
         +     '6[0-4][0-9]{3}|'
         +     '[0-5]?[0-9]{0,3}[0-9]))|'
         + '(6(:[a-fA-F0-9]{2}){6})|'
         + '(([3-57-9a-fA-F]|[1-9a-fA-F][0-9a-fA-F]{1,3}):'
         +     '[0-9a-fA-F]{1,12})';
       }

But I think that it would be much easier to read, and quite possibly more performant to execute, if the pattern regex was written something like the following:

 pattern:
    '(0:[0-9]{1,5}:[0-9]{1,10})|
     (1:([0-9]{1,3}\.){4}:[0-9]{1,5})|
     (2:[0-9]{1,10}:0:[0-9]{1,5})|
     (6(:[a-fA-F0-9]{2}){6})';
   
Of course, this would allow more invalid values, but most servers would be expected to reject those when it converts them into an internal binary format any way.

What do you, and others, think?

Thanks,
Rob


On 21/08/2017 15:01, Acee Lindem (acee) wrote:
Hi William, Rob, Andy,

Given their limited usefulness and the detriments, perhaps we should
discourage the creation of new submodules in RFC6087Bis.

Thanks,
Acee

On 8/21/17, 9:44 AM, "netmod on behalf of Ivory, William"
<netmod-bounces@ietf.org on behalf of william.ivory@intl.att.com> wrote:


Hi Rob,

That would make it very hard to update existing 1.x YANG models to use
new features in YANG 2.x if they used submodules.  Maybe that's something
that no one would ever consider doing anyway, or maybe YANG 1.1 already
has similar differences to 1.0?  I had (perhaps naively) assumed that you
could migrate a namespace / model from YANG 1.0 to 2.0?

Regards,

William

-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton
Sent: 21 August 2017 11:24
To: netmod@ietf.org
Subject: Re: [netmod] Query about augmenting module from submodule in
YANG 1.0



On 09/08/2017 16:13, Juergen Schoenwaelder wrote:

On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka wrote:

I remember that in early stages of YANG there was some irrational
fear of introducing too many namespaces, and submodules may be a
consequence of it. As you write, submodules provide no benefits
whatsoever in terms of modularity, but the overhead in terms of
metadata, IANA registration etc. is pretty much the same as for
modules.

In case YANG 2.0 is ever done, I suggest someone files a proposal to
remove submodules if the cost/benefit ratio is at odds. There is
nothing wrong with removing stuff that has been found problematic.

I agree.

I've added 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmod-2Dw
g_yang-2Dnext_issues_26&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ
2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7ow
I&s=-kR4fUtXArQy0RwWb32DpT1bP4X_cNqt2zJVoC0JiX8&e=

Rob


The motivation for submodules was that organizations maintaining large
modules with multiple people can do so without having to mess around
with tools like m4 scripts to produce a single module from 'snippets'
and to avoid integration surprises. But perhaps using m4 scripts and
decent version control systems (that can integrate and compile on
checkin) is indeed cheaper than having submodules part of the YANG
language itself.

/js


_______________________________________________
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_
listinfo_netmod&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwky
XmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7owI&s=t7vG
IH8ABuAm00e-bkSowD9eawModGq0N2OkjANtpYI&e=

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


    

    

  


--------------825ED476C42CF7428E698B97--


From nobody Mon Aug 21 11:54:28 2017
Return-Path: 
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 E4ABA13219C for ; Mon, 21 Aug 2017 11:54:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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
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 atTcYVBkFx16 for ; Mon, 21 Aug 2017 11:54:23 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2034C1321C0 for ; Mon, 21 Aug 2017 11:54:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7163; q=dns/txt; s=iport; t=1503341663; x=1504551263; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=DFZbz32h0o4WkrUn8QZqvAiOLjN405b3xyjdkB+93kE=; b=hM/kgynqhWt8BJxmt3sEjfTxSJMYdzyhfKv5TSPO1H1EET/dZ3WF0asw 8OeHg935My6ABlCOSSKpjDUcp2uc5jkAaZg50fCvgC5oVQMlgmPZo8k/w g3WdCzrcYeV5c3K9lVs2/D62r4Q8z4JwWP/oaxFBHaUiPXlF/FlxdEF7R Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DkAACzK5tZ/4QNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm9rZIEVB4NwihuQF4FukGWFOYISIQEKhExPAhqDdj8YAQIBAQE?= =?us-ascii?q?BAQEBayiFGAEBAQEDAQEhSwkSAgEIEQMBAigDAgICJQsUCQgCBAESCYlEZBCvG?= =?us-ascii?q?IImJ4s4AQEBAQEBAQEBAQEBAQEBAQEBAQEBHYMoggKDL4MngkaCBj4JgnOCYQW?= =?us-ascii?q?gTwKUQIIQiVyGcolpjDYBHzg/S3cVSYVMgU52h12BMoEPAQEB?=
X-IronPort-AV: E=Sophos;i="5.41,409,1498521600";  d="scan'208,217";a="473056847"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Aug 2017 18:54:22 +0000
Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v7LIsLvo016932 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Aug 2017 18:54:22 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 21 Aug 2017 14:54:21 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Mon, 21 Aug 2017 14:54:21 -0400
From: "Acee Lindem (acee)" 
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" ,  Martin Bjorklund , "netmod@ietf.org" 
Thread-Topic: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-rfc7223bis-00.txt
Thread-Index: AQHTGlSjedcT5kRFYEe7bE4c9YtwgqKPEHuAgAAYmYA=
Date: Mon, 21 Aug 2017 18:54:21 +0000
Message-ID: 
References: <20170821.100629.1135908044163191249.mbj@tail-f.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.201]
Content-Type: multipart/alternative; boundary="_000_D5C0A2A9C2792aceeciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-rfc7223bis-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Aug 2017 18:54:26 -0000

--_000_D5C0A2A9C2792aceeciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQoNCkZyb206IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1i
b3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mICJSb2JlcnQgV2lsdG9uIC1YIChyd2lsdG9u
IC0gRU5TT0ZUIExJTUlURUQgYXQgQ2lzY28pIiA8cndpbHRvbkBjaXNjby5jb208bWFpbHRvOnJ3
aWx0b25AY2lzY28uY29tPj4NCkRhdGU6IE1vbmRheSwgQXVndXN0IDIxLCAyMDE3IGF0IDk6MjYg
QU0NClRvOiBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbTxtYWlsdG86bWJqQHRhaWwt
Zi5jb20+PiwgIm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPiIgPG5ldG1v
ZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbbmV0bW9k
XSBGdzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1iam9ya2x1bmQtbmV0bW9k
LXJmYzcyMjNiaXMtMDAudHh0DQoNCg0KSSd2ZSByZWFkIHRoaXMgZHJhZnQgYW5kIHdvdWxkIGFs
c28gc3VwcG9ydCBpdCBiZWluZyBhZG9wdGVkIGFzIGEgV0cgZG9jdW1lbnQuDQoNCkdpdmVuIHRo
YXQgbG90cyBvZiBtb2RlbHMgZGVwZW5kIG9uIGlldGYtaW50ZXJmYWNlcywgdGhlIHNvb25lciB0
aGF0IHdlIGNhbiBnZXQgdGhpcyBwdWJsaXNoZWQgYXMgYW4gdXBkYXRlZCBSRkMgdGhlIGJldHRl
ci4gIFJlYWxpc3RpY2FsbHksIGhvdyBxdWlja2x5IGNhbiB3ZSBnZXQgdGhlIElFVEYgbWFjaGlu
ZXJ5IHRvIG1vdmUgb24gdGhpcyBhbmQgdGhlIGZldyBvdGhlciBlcXVpdmFsZW50IGRyYWZ0cz8N
Cg0KVGhhdCBpcyBkZWZpbml0ZWx5IGEgY29uc2lkZXJhdGlvbi4gSnVzdCBiZWNhdXNlIHRoZSBk
b2N1bWVudHMgc2F5IElBTkEgaXMgZ29pbmcgdG8gbWFpbnRhaW4gdGhlc2UgaWFuYS3igKYuIG1v
ZGVscyBkb2VzbuKAmXQgbWVhbiBpdCBpcyBnb2luZyB0byBoYXZlIGhhcHBlbiBpbiBhIHRpbWVs
eSBtYW5uZXIuDQoNClRoYW5rcywNCkFjZWUNCg0KDQoNClRoYW5rcywNClJvYg0KDQoNCk9uIDIx
LzA4LzIwMTcgMDk6MDYsIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6DQoNCkhpLA0KDQpUaGlzIGRv
Y3VtZW50IGRlZmluZXMgYW4gTk1EQS1jb21wbGlhbnQgdXBkYXRlIHRvIHRoZSBpbnRlcmZhY2Vz
IG1vZGVsDQooUkZDIDcyMjMpLiAgVGhpcyBpcyBkb25lIGJ5IGRlcHJlY3RhaW5nIHRoZSAvaW50
ZXJmYWNlcy1zdGF0ZSB0cmVlDQphbmQgbW92aW5nIHRoZSBjb25maWcgZmFsc2Ugbm9kZXMgaW50
byB0aGUgL2ludGVyZmFjZXMgdHJlZS4NCg0KSSB3b3VsZCBsaWtlIHRvIGFzayB0aGUgV0cgdG8g
YWRvcHQgdGhpcyBpbmRpdmlkdWFsIGRyYWZ0IGFzIGEgd29ya2luZw0KZ3JvdXAgZG9jdW1lbnQu
DQoNCg0KL21hcnRpbg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFp
bHRvOm5ldG1vZEBpZXRmLm9yZz5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L25ldG1vZA0KDQo=

--_000_D5C0A2A9C2792aceeciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <887ADCF19573B64DBE6A022C8B595D4C@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj48YnI+DQo8L2Rp
dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K
PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxp
Z246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVIt
TEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGlu
OyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JE
RVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJm
b250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+bmV0bW9kICZsdDs8YSBocmVmPSJtYWlsdG86
bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmciPm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsg
b24gYmVoYWxmIG9mICZxdW90O1JvYmVydCBXaWx0b24gLVggKHJ3aWx0b24gLSBFTlNPRlQgTElN
SVRFRCBhdCBDaXNjbykmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpyd2lsdG9uQGNpc2NvLmNv
bSI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo
dDpib2xkIj5EYXRlOiA8L3NwYW4+TW9uZGF5LCBBdWd1c3QgMjEsIDIwMTcgYXQgOToyNiBBTTxi
cj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPk1hcnRpbiBCam9y
a2x1bmQgJmx0OzxhIGhyZWY9Im1haWx0bzptYmpAdGFpbC1mLmNvbSI+bWJqQHRhaWwtZi5jb208
L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGll
dGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0
bW9kQGlldGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+
U3ViamVjdDogPC9zcGFuPlJlOiBbbmV0bW9kXSBGdzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9u
IGZvciBkcmFmdC1iam9ya2x1bmQtbmV0bW9kLXJmYzcyMjNiaXMtMDAudHh0PGJyPg0KPC9kaXY+
DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVU
SU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURE
SU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdiB0ZXh0PSIjMDAwMDAw
IiBiZ2NvbG9yPSIjRkZGRkZGIj4NCjxwPkkndmUgcmVhZCB0aGlzIGRyYWZ0IGFuZCB3b3VsZCBh
bHNvIHN1cHBvcnQgaXQgYmVpbmcgYWRvcHRlZCBhcyBhIFdHIGRvY3VtZW50LjwvcD4NCkdpdmVu
IHRoYXQgbG90cyBvZiBtb2RlbHMgZGVwZW5kIG9uIGlldGYtaW50ZXJmYWNlcywgdGhlIHNvb25l
ciB0aGF0IHdlIGNhbiBnZXQgdGhpcyBwdWJsaXNoZWQgYXMgYW4gdXBkYXRlZCBSRkMgdGhlIGJl
dHRlci4mbmJzcDsgUmVhbGlzdGljYWxseSwgaG93IHF1aWNrbHkgY2FuIHdlIGdldCB0aGUgSUVU
RiBtYWNoaW5lcnkgdG8gbW92ZSBvbiB0aGlzIGFuZCB0aGUgZmV3IG90aGVyIGVxdWl2YWxlbnQg
ZHJhZnRzPzwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4N
CjwvZGl2Pg0KPGRpdj5UaGF0IGlzIGRlZmluaXRlbHkgYSBjb25zaWRlcmF0aW9uLiBKdXN0IGJl
Y2F1c2UgdGhlIGRvY3VtZW50cyBzYXkgSUFOQSBpcyBnb2luZyB0byBtYWludGFpbiB0aGVzZSBp
YW5hLeKApi4gbW9kZWxzIGRvZXNu4oCZdCBtZWFuIGl0IGlzIGdvaW5nIHRvIGhhdmUgaGFwcGVu
IGluIGEgdGltZWx5IG1hbm5lci4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2
PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QWNlZSZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N
CjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09V
VExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRm
IDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8ZGl2
IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiPjxicj4NCjxicj4NClRoYW5rcyw8YnI+
DQpSb2I8YnI+DQo8YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPk9uIDIx
LzA4LzIwMTcgMDk6MDYsIE1hcnRpbiBCam9ya2x1bmQgd3JvdGU6PGJyPg0KPC9kaXY+DQo8Ymxv
Y2txdW90ZSB0eXBlPSJjaXRlIiBjaXRlPSJtaWQ6MjAxNzA4MjEuMTAwNjI5LjExMzU5MDgwNDQx
NjMxOTEyNDkubWJqQHRhaWwtZi5jb20iPg0KPHByZSB3cmFwPSIiPkhpLA0KDQpUaGlzIGRvY3Vt
ZW50IGRlZmluZXMgYW4gTk1EQS1jb21wbGlhbnQgdXBkYXRlIHRvIHRoZSBpbnRlcmZhY2VzIG1v
ZGVsDQooUkZDIDcyMjMpLiAgVGhpcyBpcyBkb25lIGJ5IGRlcHJlY3RhaW5nIHRoZSAvaW50ZXJm
YWNlcy1zdGF0ZSB0cmVlDQphbmQgbW92aW5nIHRoZSBjb25maWcgZmFsc2Ugbm9kZXMgaW50byB0
aGUgL2ludGVyZmFjZXMgdHJlZS4NCg0KSSB3b3VsZCBsaWtlIHRvIGFzayB0aGUgV0cgdG8gYWRv
cHQgdGhpcyBpbmRpdmlkdWFsIGRyYWZ0IGFzIGEgd29ya2luZw0KZ3JvdXAgZG9jdW1lbnQuDQoN
Cg0KL21hcnRpbg0KDQo8L3ByZT4NCjxicj4NCjxmaWVsZHNldCBjbGFzcz0ibWltZUF0dGFjaG1l
bnRIZWFkZXIiPjwvZmllbGRzZXQ+IDxicj4NCjxwcmUgd3JhcD0iIj5fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KPGEg
Y2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRm
Lm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQi
IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIj5odHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48L3ByZT4NCjwvYmxv
Y2txdW90ZT4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8
L2JvZHk+DQo8L2h0bWw+DQo=

--_000_D5C0A2A9C2792aceeciscocom_--


From nobody Tue Aug 22 03:21:55 2017
Return-Path: 
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 AF817132949 for ; Tue, 22 Aug 2017 03:21:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 HzrWqCKK0_1V for ; Tue, 22 Aug 2017 03:21:52 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E90781321C4 for ; Tue, 22 Aug 2017 03:21:51 -0700 (PDT)
Received: from localhost (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 25F8D1AE02C9 for ; Tue, 22 Aug 2017 12:21:51 +0200 (CEST)
Date: Tue, 22 Aug 2017 12:20:22 +0200 (CEST)
Message-Id: <20170822.122022.1375224682803846655.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Aug 2017 10:21:54 -0000

Hi,

Lada presented an open issue in schema mount in Prague.  (See slide 6
in
https://datatracker.ietf.org/meeting/99/materials/slides-99-netmod-sessb-schema-mount)

The original problem comes from the NI use case
(https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model).  In this
use case, interfaces are assigned to NIs by:

   augment /if:interfaces/if:interface:
     +--rw bind-ni-name?   -> /network-instances/network-instance/name

Modules that are mounted within the NI might have references to
interfaces.  The idea is that a specific NI can only reference the
interfaces that has been assigned to it.

In schema mount, we have the "parent-reference" XPath expression that
in this case will be "/if:interfaces/if:interface".  The problem is
that this XPath expression will evaluate to a node set that contains
*all* interfaces in the system.  We would like this to contain just
the interfaces assigned to the NI.

It turns out that this can be done with a simple change to the
"parent-reference" node.  If we state that this XPath expression is
evaluated in an XPath context where the context node is the node in
the data tree where the mount point is defined (instead of "/"), we
can use as parent-reference:

  /if:interfaces/if:interface[ni:bind-network-instance-name = ../ni:name]

Putting this together we'd have:

  augment "/if:interfaces/if:interface" {
    leaf bind-ni-name {
      type leafref {
        path "/network-instances/network-instance/name";
      }
    }
  }

  container network-instances {
    list network-instance {
      key name;
      leaf name { ... }
      ...
      container root {
        // this would be the XPath context root for parent-reference
        yangmnt:mount-point ni-root;
      }
    }
  }

And in state data:


"ietf-yang-schema-mount:schema-mounts": {
  "namespace": [
    {
      "prefix": "ni",
      "uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
    },
    {
      "prefix": "if",
      "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
    }
  ]
  "mount-point": [
    {
      "target": "/ni:network-instances/ni:network-instance/ni:root",
      "parent-reference": [
            "/if:interfaces/if:interface
             [ni:bind-network-instance-name = ../ni:name]"
                          ],
      "use-schema": [
        {
          "name": "ni-schema"
        }
      ]
    }
  ]



Note that this does NOT affect the schema that is mounted; it only
affects the result of the parent-reference XPath expressions.


I think that we should make this change, since it allows for more
precise parent-references.



/martin


From nobody Tue Aug 22 04:16:43 2017
Return-Path: 
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 AE37B132977 for ; Tue, 22 Aug 2017 04:16:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level: 
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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
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 2d8YF4tt1Ur0 for ; Tue, 22 Aug 2017 04:16:40 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2D913296D for ; Tue, 22 Aug 2017 04:16:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4488; q=dns/txt; s=iport; t=1503400599; x=1504610199; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=s7s2v0qjU+0XiGYERMc6/W8lbuTon49dsJlAZqsFNrs=; b=eIMtLLbtBx+gjl7HG5OU/umaQudrT7x7KX4DxJFkd2iQUbiF3JZ8IOld gfSKkkXiOFRhHOnpfony5DW8lq0gmEoxco52WqVIY+/cThpcXfqA7IoEi s/butrvZZyVR+1uMXpNBLQrgCPc5EHXGb3cJK3bhLStk9HPgLm2hoNqqd U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CdAAAwEpxZ/4cNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRUHjgyQGIFulh+CEiENhEpPAhqEBT8YAQIBAQEBAQEBayi?= =?us-ascii?q?FGQEBAQIBAQEhBA06GwIBCA4MAiYCAgIlCxUQAgQBEoopCBCtGIFsOoteAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGwWBDYIdggKGIjSEc4MTgmEFkRqPOwKHU4xukmCWKAE?= =?us-ascii?q?fOIEKdxVJhxp2igaBDwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.41,412,1498521600"; d="scan'208";a="288835374"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Aug 2017 11:16:28 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v7MBGRs6009341 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Aug 2017 11:16:28 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 22 Aug 2017 07:16:27 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 22 Aug 2017 07:16:27 -0400
From: "Acee Lindem (acee)" 
To: Martin Bjorklund , "netmod@ietf.org" 
Thread-Topic: [netmod] schema mount open issue #1
Thread-Index: AQHTGzCCt8V2jLxEeEiIUX0NVH7/VqKQOb+A
Date: Tue, 22 Aug 2017 11:16:27 +0000
Message-ID: 
References: <20170822.122022.1375224682803846655.mbj@tail-f.com>
In-Reply-To: <20170822.122022.1375224682803846655.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.201]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Aug 2017 11:16:42 -0000

SGkgTWFydGluLCANCg0KDQpPbiA4LzIyLzE3LCA2OjIwIEFNLCAibmV0bW9kIG9uIGJlaGFsZiBv
ZiBNYXJ0aW4gQmpvcmtsdW5kIg0KPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv
ZiBtYmpAdGFpbC1mLmNvbT4gd3JvdGU6DQoNCj5IaSwNCj4NCj5MYWRhIHByZXNlbnRlZCBhbiBv
cGVuIGlzc3VlIGluIHNjaGVtYSBtb3VudCBpbiBQcmFndWUuICAoU2VlIHNsaWRlIDYNCj5pbg0K
Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy85OS9tYXRlcmlhbHMvc2xpZGVz
LTk5LW5ldG1vZC1zZXNzYi1zDQo+Y2hlbWEtbW91bnQpDQo+DQo+VGhlIG9yaWdpbmFsIHByb2Js
ZW0gY29tZXMgZnJvbSB0aGUgTkkgdXNlIGNhc2UNCj4oaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o
dG1sL2RyYWZ0LWlldGYtcnRnd2ctbmktbW9kZWwpLiAgSW4gdGhpcw0KPnVzZSBjYXNlLCBpbnRl
cmZhY2VzIGFyZSBhc3NpZ25lZCB0byBOSXMgYnk6DQo+DQo+ICAgYXVnbWVudCAvaWY6aW50ZXJm
YWNlcy9pZjppbnRlcmZhY2U6DQo+ICAgICArLS1ydyBiaW5kLW5pLW5hbWU/ICAgLT4gL25ldHdv
cmstaW5zdGFuY2VzL25ldHdvcmstaW5zdGFuY2UvbmFtZQ0KPg0KPk1vZHVsZXMgdGhhdCBhcmUg
bW91bnRlZCB3aXRoaW4gdGhlIE5JIG1pZ2h0IGhhdmUgcmVmZXJlbmNlcyB0bw0KPmludGVyZmFj
ZXMuICBUaGUgaWRlYSBpcyB0aGF0IGEgc3BlY2lmaWMgTkkgY2FuIG9ubHkgcmVmZXJlbmNlIHRo
ZQ0KPmludGVyZmFjZXMgdGhhdCBoYXMgYmVlbiBhc3NpZ25lZCB0byBpdC4NCj4NCj5JbiBzY2hl
bWEgbW91bnQsIHdlIGhhdmUgdGhlICJwYXJlbnQtcmVmZXJlbmNlIiBYUGF0aCBleHByZXNzaW9u
IHRoYXQNCj5pbiB0aGlzIGNhc2Ugd2lsbCBiZSAiL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNl
Ii4gIFRoZSBwcm9ibGVtIGlzDQo+dGhhdCB0aGlzIFhQYXRoIGV4cHJlc3Npb24gd2lsbCBldmFs
dWF0ZSB0byBhIG5vZGUgc2V0IHRoYXQgY29udGFpbnMNCj4qYWxsKiBpbnRlcmZhY2VzIGluIHRo
ZSBzeXN0ZW0uICBXZSB3b3VsZCBsaWtlIHRoaXMgdG8gY29udGFpbiBqdXN0DQo+dGhlIGludGVy
ZmFjZXMgYXNzaWduZWQgdG8gdGhlIE5JLg0KPg0KPkl0IHR1cm5zIG91dCB0aGF0IHRoaXMgY2Fu
IGJlIGRvbmUgd2l0aCBhIHNpbXBsZSBjaGFuZ2UgdG8gdGhlDQo+InBhcmVudC1yZWZlcmVuY2Ui
IG5vZGUuICBJZiB3ZSBzdGF0ZSB0aGF0IHRoaXMgWFBhdGggZXhwcmVzc2lvbiBpcw0KPmV2YWx1
YXRlZCBpbiBhbiBYUGF0aCBjb250ZXh0IHdoZXJlIHRoZSBjb250ZXh0IG5vZGUgaXMgdGhlIG5v
ZGUgaW4NCj50aGUgZGF0YSB0cmVlIHdoZXJlIHRoZSBtb3VudCBwb2ludCBpcyBkZWZpbmVkIChp
bnN0ZWFkIG9mICIvIiksIHdlDQo+Y2FuIHVzZSBhcyBwYXJlbnQtcmVmZXJlbmNlOg0KPg0KPiAg
L2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlW25pOmJpbmQtbmV0d29yay1pbnN0YW5jZS1uYW1l
ID0gLi4vbmk6bmFtZV0NCj4NCj5QdXR0aW5nIHRoaXMgdG9nZXRoZXIgd2UnZCBoYXZlOg0KPg0K
PiAgYXVnbWVudCAiL2lmOmludGVyZmFjZXMvaWY6aW50ZXJmYWNlIiB7DQo+ICAgIGxlYWYgYmlu
ZC1uaS1uYW1lIHsNCj4gICAgICB0eXBlIGxlYWZyZWYgew0KPiAgICAgICAgcGF0aCAiL25ldHdv
cmstaW5zdGFuY2VzL25ldHdvcmstaW5zdGFuY2UvbmFtZSI7DQo+ICAgICAgfQ0KPiAgICB9DQo+
ICB9DQoNCldvdWxkIHRoaXMgd29yayBpZiBuZXR3b3JrLWluc3RhbmNlcyBpcyBtb3VudGVkIHNv
bWV3aGVyZSBvdGhlciB0aGFuIHRoZQ0Kcm9vdD8gRm9yIGV4YW1wbGUsIHdoYXQgaWYgbmV0d29y
ay1pbnN0YW5jZXMgaXMgbW91bnRlZCBpbiB3aXRoaW4gYW4gTE5FDQooTG9naWNhbCBOZXR3b3Jr
IEVsZW1lbnQpPw0KDQpUaGFua3MsDQpBY2VlIA0KDQo+DQo+ICBjb250YWluZXIgbmV0d29yay1p
bnN0YW5jZXMgew0KPiAgICBsaXN0IG5ldHdvcmstaW5zdGFuY2Ugew0KPiAgICAgIGtleSBuYW1l
Ow0KPiAgICAgIGxlYWYgbmFtZSB7IC4uLiB9DQo+ICAgICAgLi4uDQo+ICAgICAgY29udGFpbmVy
IHJvb3Qgew0KPiAgICAgICAgLy8gdGhpcyB3b3VsZCBiZSB0aGUgWFBhdGggY29udGV4dCByb290
IGZvciBwYXJlbnQtcmVmZXJlbmNlDQo+ICAgICAgICB5YW5nbW50Om1vdW50LXBvaW50IG5pLXJv
b3Q7DQo+ICAgICAgfQ0KPiAgICB9DQo+ICB9DQo+DQo+QW5kIGluIHN0YXRlIGRhdGE6DQo+DQo+
DQo+ImlldGYteWFuZy1zY2hlbWEtbW91bnQ6c2NoZW1hLW1vdW50cyI6IHsNCj4gICJuYW1lc3Bh
Y2UiOiBbDQo+ICAgIHsNCj4gICAgICAicHJlZml4IjogIm5pIiwNCj4gICAgICAidXJpIjogInVy
bjppZXRmOnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLW5ldHdvcmstaW5zdGFuY2UiDQo+ICAgIH0s
DQo+ICAgIHsNCj4gICAgICAicHJlZml4IjogImlmIiwNCj4gICAgICAidXJpIjogInVybjppZXRm
OnBhcmFtczp4bWw6bnM6eWFuZzppZXRmLWludGVyZmFjZXMiDQo+ICAgIH0NCj4gIF0NCj4gICJt
b3VudC1wb2ludCI6IFsNCj4gICAgew0KPiAgICAgICJ0YXJnZXQiOiAiL25pOm5ldHdvcmstaW5z
dGFuY2VzL25pOm5ldHdvcmstaW5zdGFuY2Uvbmk6cm9vdCIsDQo+ICAgICAgInBhcmVudC1yZWZl
cmVuY2UiOiBbDQo+ICAgICAgICAgICAgIi9pZjppbnRlcmZhY2VzL2lmOmludGVyZmFjZQ0KPiAg
ICAgICAgICAgICBbbmk6YmluZC1uZXR3b3JrLWluc3RhbmNlLW5hbWUgPSAuLi9uaTpuYW1lXSIN
Cj4gICAgICAgICAgICAgICAgICAgICAgICAgIF0sDQo+ICAgICAgInVzZS1zY2hlbWEiOiBbDQo+
ICAgICAgICB7DQo+ICAgICAgICAgICJuYW1lIjogIm5pLXNjaGVtYSINCj4gICAgICAgIH0NCj4g
ICAgICBdDQo+ICAgIH0NCj4gIF0NCj4NCj4NCj4NCj5Ob3RlIHRoYXQgdGhpcyBkb2VzIE5PVCBh
ZmZlY3QgdGhlIHNjaGVtYSB0aGF0IGlzIG1vdW50ZWQ7IGl0IG9ubHkNCj5hZmZlY3RzIHRoZSBy
ZXN1bHQgb2YgdGhlIHBhcmVudC1yZWZlcmVuY2UgWFBhdGggZXhwcmVzc2lvbnMuDQo+DQo+DQo+
SSB0aGluayB0aGF0IHdlIHNob3VsZCBtYWtlIHRoaXMgY2hhbmdlLCBzaW5jZSBpdCBhbGxvd3Mg
Zm9yIG1vcmUNCj5wcmVjaXNlIHBhcmVudC1yZWZlcmVuY2VzLg0KPg0KPg0KPg0KPi9tYXJ0aW4N
Cj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5l
dG1vZCBtYWlsaW5nIGxpc3QNCj5uZXRtb2RAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQo=


From nobody Tue Aug 22 04:53:43 2017
Return-Path: 
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 F14A01326F4 for ; Tue, 22 Aug 2017 04:53:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 l29RyDwuL-v9 for ; Tue, 22 Aug 2017 04:53:40 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DB4EF1326F3 for ; Tue, 22 Aug 2017 04:53:39 -0700 (PDT)
Received: from localhost (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 040231AE02C9; Tue, 22 Aug 2017 13:53:38 +0200 (CEST)
Date: Tue, 22 Aug 2017 13:52:10 +0200 (CEST)
Message-Id: <20170822.135210.1177161659945802293.mbj@tail-f.com>
To: acee@cisco.com
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <20170822.122022.1375224682803846655.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Aug 2017 11:53:42 -0000

"Acee Lindem (acee)"  wrote:
> Hi Martin, 
> 
> 
> On 8/22/17, 6:20 AM, "netmod on behalf of Martin Bjorklund"
>  wrote:
> 
> >Hi,
> >
> >Lada presented an open issue in schema mount in Prague.  (See slide 6
> >in
> >https://datatracker.ietf.org/meeting/99/materials/slides-99-netmod-sessb-s
> >chema-mount)
> >
> >The original problem comes from the NI use case
> >(https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model).  In this
> >use case, interfaces are assigned to NIs by:
> >
> >   augment /if:interfaces/if:interface:
> >     +--rw bind-ni-name?   -> /network-instances/network-instance/name
> >
> >Modules that are mounted within the NI might have references to
> >interfaces.  The idea is that a specific NI can only reference the
> >interfaces that has been assigned to it.
> >
> >In schema mount, we have the "parent-reference" XPath expression that
> >in this case will be "/if:interfaces/if:interface".  The problem is
> >that this XPath expression will evaluate to a node set that contains
> >*all* interfaces in the system.  We would like this to contain just
> >the interfaces assigned to the NI.
> >
> >It turns out that this can be done with a simple change to the
> >"parent-reference" node.  If we state that this XPath expression is
> >evaluated in an XPath context where the context node is the node in
> >the data tree where the mount point is defined (instead of "/"), we
> >can use as parent-reference:
> >
> >  /if:interfaces/if:interface[ni:bind-network-instance-name = ../ni:name]
> >
> >Putting this together we'd have:
> >
> >  augment "/if:interfaces/if:interface" {
> >    leaf bind-ni-name {
> >      type leafref {
> >        path "/network-instances/network-instance/name";
> >      }
> >    }
> >  }
> 
> Would this work if network-instances is mounted somewhere other than the
> root? For example, what if network-instances is mounted in within an LNE
> (Logical Network Element)?

Yes it will work, since the /if:interfaces will refer to the
interfaces within the LNE.  (Note that this does not change with my
proposal)



/martin


> 
> Thanks,
> Acee 
> 
> >
> >  container network-instances {
> >    list network-instance {
> >      key name;
> >      leaf name { ... }
> >      ...
> >      container root {
> >        // this would be the XPath context root for parent-reference
> >        yangmnt:mount-point ni-root;
> >      }
> >    }
> >  }
> >
> >And in state data:
> >
> >
> >"ietf-yang-schema-mount:schema-mounts": {
> >  "namespace": [
> >    {
> >      "prefix": "ni",
> >      "uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
> >    },
> >    {
> >      "prefix": "if",
> >      "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
> >    }
> >  ]
> >  "mount-point": [
> >    {
> >      "target": "/ni:network-instances/ni:network-instance/ni:root",
> >      "parent-reference": [
> >            "/if:interfaces/if:interface
> >             [ni:bind-network-instance-name = ../ni:name]"
> >                          ],
> >      "use-schema": [
> >        {
> >          "name": "ni-schema"
> >        }
> >      ]
> >    }
> >  ]
> >
> >
> >
> >Note that this does NOT affect the schema that is mounted; it only
> >affects the result of the parent-reference XPath expressions.
> >
> >
> >I think that we should make this change, since it allows for more
> >precise parent-references.
> >
> >
> >
> >/martin
> >
> >_______________________________________________
> >netmod mailing list
> >netmod@ietf.org
> >https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Tue Aug 22 11:33:37 2017
Return-Path: 
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 284DF132A07 for ; Tue, 22 Aug 2017 11:33:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 IsTFWaPLU27I for ; Tue, 22 Aug 2017 11:33:34 -0700 (PDT)
Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 EF156132A03 for ; Tue, 22 Aug 2017 11:33:33 -0700 (PDT)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 33FA31E07C5 for ; Tue, 22 Aug 2017 12:33:32 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id 0JZU1w00c2SSUrH01JZXfE; Tue, 22 Aug 2017 12:33:32 -0600
X-Authority-Analysis: v=2.2 cv=T7z8d7CQ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=KeKAF7QvOSUA:10 a=48vgC7mUAAAA:8 a=6e3FJO9Xp4FblCK-oIUA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=G7YDNuNbi4v+JbKzF/4tRAis6WAEkD8eDwpKuSQmHE8=; b=UzAOCcwUnfrsJ9mDEukxVipM3U fgVr+GLVQYlfAJGcaXJDmGtKlLJ9S0dhDJoMF+TkeZRc07z75lm9FYMeKWzQTLGcQzbMG3jB7eOQ6 ECyAqom93EVpipVhm/IMU/GV/;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:33992 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dkDzU-000ixi-0d; Tue, 22 Aug 2017 12:33:28 -0600
To: Martin Bjorklund , netmod@ietf.org
References: <20170822.122022.1375224682803846655.mbj@tail-f.com>
From: Lou Berger 
Message-ID: <1aa26e59-6999-8f8a-6cd6-5e74050453bd@labn.net>
Date: Tue, 22 Aug 2017 14:33:25 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170822.122022.1375224682803846655.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dkDzU-000ixi-0d
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:33992
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Aug 2017 18:33:36 -0000

Hi Martin,

See below.


On 8/22/2017 6:20 AM, Martin Bjorklund wrote:
> Hi,
>
> Lada presented an open issue in schema mount in Prague.  (See slide 6
> in
> https://datatracker.ietf.org/meeting/99/materials/slides-99-netmod-sessb-schema-mount)
>
> The original problem comes from the NI use case
> (https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model).  In this
> use case, interfaces are assigned to NIs by:
>
>    augment /if:interfaces/if:interface:
>      +--rw bind-ni-name?   -> /network-instances/network-instance/name
>
> Modules that are mounted within the NI might have references to
> interfaces.  The idea is that a specific NI can only reference the
> interfaces that has been assigned to it.
>
> In schema mount, we have the "parent-reference" XPath expression that
> in this case will be "/if:interfaces/if:interface".  The problem is
> that this XPath expression will evaluate to a node set that contains
> *all* interfaces in the system.  We would like this to contain just
> the interfaces assigned to the NI.
>
> It turns out that this can be done with a simple change to the
> "parent-reference" node.  If we state that this XPath expression is
> evaluated in an XPath context where the context node is the node in
> the data tree where the mount point is defined (instead of "/"), we
> can use as parent-reference:
>
>   /if:interfaces/if:interface[ni:bind-network-instance-name = ../ni:name]
>
> Putting this together we'd have:
>
>   augment "/if:interfaces/if:interface" {
>     leaf bind-ni-name {
>       type leafref {
>         path "/network-instances/network-instance/name";
>       }
>     }
>   }
>
>   container network-instances {
>     list network-instance {
>       key name;
>       leaf name { ... }
>       ...
>       container root {
>         // this would be the XPath context root for parent-reference
>         yangmnt:mount-point ni-root;
>       }
>     }
>   }

note that the current NI definition is:


   module: ietf-network-instance
     +--rw network-instances
        +--rw network-instance* [name]
           +--rw name           string
           +--rw enabled?       boolean
           +--rw description?   string
           +--rw (ni-type)?
           +--rw (root-type)?
              +--:(vrf-root)
              |  +--mp vrf-root?
              +--:(vsi-root)
              |  +--mp vsi-root?
              +--:(vv-root)
                 +--mp vv-root?
   augment /if:interfaces/if:interface:
     +--rw bind-ni-name?   -> /network-instances/network-instance/name
   augment /if:interfaces/if:interface/ip:ipv4:
     +--rw bind-ni-name?   -> /network-instances/network-instance/name
   augment /if:interfaces/if:interface/ip:ipv6:
     +--rw bind-ni-name?   -> /network-instances/network-instance/name

> And in state data:
>
>
> "ietf-yang-schema-mount:schema-mounts": {
>   "namespace": [
>     {
>       "prefix": "ni",
>       "uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
>     },
>     {
>       "prefix": "if",
>       "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
>     }
>   ]
>   "mount-point": [
>     {
>       "target": "/ni:network-instances/ni:network-instance/ni:root",
Can you confirm that with the current definition the target is:

      "target": "/ni:network-instances/ni:network-instance",

correct?

>       "parent-reference": [
>             "/if:interfaces/if:interface
>              [ni:bind-network-instance-name = ../ni:name]"
>                           ],
Also, can you confirm that if we wanted to cover v4, v6 (for example
purposes) interfaces-state, the full parent reference list would be:

      "parent-reference": [
            "/if:interfaces/if:interface
             [ni:bind-ni-name = ./ni:name]",
            "/if:interfaces/if:interface/ip:ipv4
             [ni:bind-ni-name = ./ni:name]",
            "/if:interfaces/if:interface/ip:ipv6
             [ni:bind-ni-name = ./ni:name]",
             "/if:interfaces-state/if:interface"

 correct?

Note that interfaces-state isn't filtered as the bind-ni-name isn't
present in -state.

>       "use-schema": [
>         {
>           "name": "ni-schema"
>         }
>       ]
>     }
>   ]
>
>
>
> Note that this does NOT affect the schema that is mounted; it only
> affects the result of the parent-reference XPath expressions.
>
>
> I think that we should make this change, since it allows for more
> precise parent-references.
I'm okay with the change (just want to see the draft moved forward ;-)

Lou
(As contributor)


>
>
> /martin
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Tue Aug 22 11:38:20 2017
Return-Path: 
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 E5BBB1323B8 for ; Tue, 22 Aug 2017 11:38:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 aQZRLRlU0dW7 for ; Tue, 22 Aug 2017 11:38:15 -0700 (PDT)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 BB6B213235C for ; Tue, 22 Aug 2017 11:38:15 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 4E80B1E0B83 for ; Tue, 22 Aug 2017 12:38:14 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id 0JeA1w01M2SSUrH01JeDcs; Tue, 22 Aug 2017 12:38:14 -0600
X-Authority-Analysis: v=2.2 cv=FrR1xyjq c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=KeKAF7QvOSUA:10 a=48vgC7mUAAAA:8 a=zQP7CpKOAAAA:8 a=RpNjiQI2AAAA:8 a=e9twNDyorWn3lGIp8qYA:9 a=jpIH26JlB8aEU1M81S3jpgcb7nU=:19 a=85xhRtfw19ZSP9lt:21 a=bOv-W-qRlpfPWqtC:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=vJuR_VyAocOa-HWBgGQO:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=H/P567ccE8wr5v2+cnspBsiIGa469qKvQlzDYx+w5i4=; b=PDv80zuF/WP774Popr+21qjaY5 tAqSYIrEPZqWAiiiVSbskfl+TzCLBouipN/AYm3CGfWlwv0Nsl1FIqcU1/koR8NXtswqpYurx9Yg8 yFD1KUsxDssW3AdoUqICzjfDx;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:34086 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dkE42-000jlI-9y; Tue, 22 Aug 2017 12:38:10 -0600
To: "Acee Lindem (acee)" , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , "'netmod@ietf.org'" , Andy Bierman 
References:  <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com>  <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com>   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>  
From: Lou Berger 
Message-ID: <7f789081-f5bb-7f91-58b4-63c6cc6dac81@labn.net>
Date: Tue, 22 Aug 2017 14:38:07 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dkE42-000jlI-9y
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:34086
X-Source-Auth: lberger@labn.net
X-Email-Count: 5
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Aug 2017 18:38:18 -0000

Acee, Rob,

    Can you propose a specific change/addition to 6087Bis?

Thanks,
Lou

On 8/21/2017 10:01 AM, Acee Lindem (acee) wrote:
> Hi William, Rob, Andy,
>
> Given their limited usefulness and the detriments, perhaps we should
> discourage the creation of new submodules in RFC6087Bis.
>
> Thanks,
> Acee
>
> On 8/21/17, 9:44 AM, "netmod on behalf of Ivory, William"
>  wrote:
>
>> Hi Rob,
>>
>> That would make it very hard to update existing 1.x YANG models to use
>> new features in YANG 2.x if they used submodules.  Maybe that's something
>> that no one would ever consider doing anyway, or maybe YANG 1.1 already
>> has similar differences to 1.0?  I had (perhaps naively) assumed that you
>> could migrate a namespace / model from YANG 1.0 to 2.0?
>>
>> Regards,
>>
>> William
>>
>> -----Original Message-----
>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton
>> Sent: 21 August 2017 11:24
>> To: netmod@ietf.org
>> Subject: Re: [netmod] Query about augmenting module from submodule in
>> YANG 1.0
>>
>>
>>
>> On 09/08/2017 16:13, Juergen Schoenwaelder wrote:
>>> On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka wrote:
>>>> I remember that in early stages of YANG there was some irrational
>>>> fear of introducing too many namespaces, and submodules may be a
>>>> consequence of it. As you write, submodules provide no benefits
>>>> whatsoever in terms of modularity, but the overhead in terms of
>>>> metadata, IANA registration etc. is pretty much the same as for
>>>> modules.
>>> In case YANG 2.0 is ever done, I suggest someone files a proposal to
>>> remove submodules if the cost/benefit ratio is at odds. There is
>>> nothing wrong with removing stuff that has been found problematic.
>> I agree.
>>
>> I've added 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmod-2Dw
>> g_yang-2Dnext_issues_26&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ
>> 2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7ow
>> I&s=-kR4fUtXArQy0RwWb32DpT1bP4X_cNqt2zJVoC0JiX8&e=
>>
>> Rob
>>
>>> The motivation for submodules was that organizations maintaining large
>>> modules with multiple people can do so without having to mess around
>>> with tools like m4 scripts to produce a single module from 'snippets'
>>> and to avoid integration surprises. But perhaps using m4 scripts and
>>> decent version control systems (that can integrate and compile on
>>> checkin) is indeed cheaper than having submodules part of the YANG
>>> language itself.
>>>
>>> /js
>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_
>> listinfo_netmod&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwky
>> XmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7owI&s=t7vG
>> IH8ABuAm00e-bkSowD9eawModGq0N2OkjANtpYI&e=
>>
>> _______________________________________________
>> 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
>


From nobody Tue Aug 22 12:53:50 2017
Return-Path: 
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 AFF6613218E for ; Tue, 22 Aug 2017 12:53:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 2phUMq3OsNqd for ; Tue, 22 Aug 2017 12:53:48 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0121.outbound.protection.outlook.com [104.47.34.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0258132494 for ; Tue, 22 Aug 2017 12:53:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MZJSzfpXecIFfbeCkaao45iSk/3E8Jk1cGcP5qkW+Tw=; b=P2P8mJ4bwFUHpOVgEcv9WzlN21VkT9XI1hFE5gS6Vg/CD2mMOtnDe5gtvmUe9n5ShA8gxMO5xuJxiD4LDnjP6iDn4n2RZ5GYKKYBfsvmRTAU/BwbABfV0wA5kzO9/sXnVA8Sa6n9dQTAvHNfUGYNm3avX3yz0mgxXeuKNc57oP8=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1307.namprd05.prod.outlook.com (10.160.226.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.4; Tue, 22 Aug 2017 19:53:46 +0000
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) by CY1PR0501MB1450.namprd05.prod.outlook.com ([10.160.149.11]) with mapi id 15.01.1385.008; Tue, 22 Aug 2017 19:53:46 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: rfc6087bis S4.23 replacement text
Thread-Index: AQHTG4BdACYCFz8ZdEeedIP50UiUzw==
Date: Tue, 22 Aug 2017 19:53:46 +0000
Message-ID: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1307; 6:c81rvG0mxjVUJ639YxA9hXBf9StU5bs1tS5ZJK1kW8RQTmbafFYk8Fti8xScuPbR6ki5Vy0wEA4ad294qwbBpc2cQL40Gd6hzqLvsgKXsPUJqnox3lfSiOTilM38KLL/3fOwQuhdol80EFpKOdIsJDqNL7vozLvllAVfwFjQQnjjbJbS4EqwJxRBcj6P6Q4vrPSZR8jzhL7qpluG9Eby2ukkaG7yMG2iMJTS2On4Mm7bkOkrBjnSHCLwJMRUcFSY2EA96USO0XPxdVKJs1Nfzpi57lS0dVArsgXO5IghohVbfFkrRG+b8te4Aa5F1uN27oBBxcQEguT4RpXdPlRQXA==; 5:sYLANhBf/8V/N5hHhAjy2/B+KAGowj7nhGz3jrvsYicLdsoxog8SMMHVtHPQo2N8bzvuM//PlA9eU7bBLm/7pMmu7S+zkzbcKde6nEnUFsYcMJMfc8UIcAB9Av5DRH7HUdQF96DYVvXgkKd7qe/NeA==; 24:0sTZXIz3q846WlYSRTVy6blO6i23Re86EXyDOGO65ecsEfgMnlYBNJ/tP217FJ3A44eIEkWTv7VRwvMGRMGBq+Nve5q2CSjEr7HueSHn9Dw=; 7:fKssg4KReD2LxqENaiLMCR7Z5yeh6icDNPUVrYDbyXR0ZUWNEpYuGe50yVmyjVeIyQzTjhTez1O1Qg2+oHmqvZrSXYr1MMim7c6LnqtEAt7xz4IdOI1yeFv6QTRGIBRVNOvX8Q91O+jmfeqzNSgm9nJG6ltDM6LMYNGViCJG+85UPk3QMM6Pyha4BRZnZXmMdAAyEikTuot04qksz3IwH/yNqpJKLiKCvzf2fNWZ2rg=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 1aac2258-264f-4109-969e-08d4e9978054
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR0501MB1307; 
x-ms-traffictypediagnostic: CY1PR0501MB1307:
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6055026)(6041248)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0501MB1307; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0501MB1307; 
x-forefront-prvs: 04073E895A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(189002)(199003)(81166006)(8676002)(14454004)(33656002)(77096006)(1730700003)(106356001)(36756003)(478600001)(81156014)(101416001)(105586002)(8936002)(5640700003)(2351001)(82746002)(6916009)(5660300001)(6506006)(110136004)(3280700002)(189998001)(53936002)(66066001)(2900100001)(99286003)(68736007)(6512007)(4001350100001)(3660700001)(86362001)(6116002)(2501003)(97736004)(83716003)(25786009)(3846002)(102836003)(7736002)(83506001)(2906002)(54356999)(6436002)(305945005)(50986999)(6486002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1307; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <45DC6138C4568344BF4ED66A053966A3@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2017 19:53:46.7505 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1307
Archived-At: 
Subject: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Aug 2017 19:53:50 -0000

DQpIaSwNCg0KRHVyaW5nIHRoZSBtZWV0aW5nIGluIENoaWNhZ28sIHRoZSBOTURBIGF1dGhvcnMg
dG9vayBhbiBhY3Rpb24gdG8gDQpwcm9wb3NlIHNvbWUgdGV4dCBmb3IgUzQuMjMuICBBZnRlciBh
IGxpdHRsZSByZXZpZXcsIHRoZSBmb2xsb3dpbmcNCmVtZXJnZWQuICBZZXMsIGl0J3Mgc2hvcnQs
IGJ1dCB3YXMgYW55dGhpbmcgbGVmdCBhbnl0aGluZyBvdXQ/DQoNCg0KPT09PT1TVEFSVD09PT09
DQoNCjQuMjMgT3BlcmF0aW9uYWwgRGF0YQ0KDQpPcGVyYXRpb25hbCBkYXRhIGluY2x1ZGVzIGJv
dGggY29uZmlnICJmYWxzZSIgbm9kZXMgYXMgd2VsbCBhcywNCm9uIHNlcnZlcnMgc3VwcG9ydGlu
ZyA8b3BlcmF0aW9uYWw+IFtkcmFmdC1pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXNdLA0K
dGhlIGFwcGxpZWQgdmFsdWUgb2YgY29uZmlnICJ0cnVlIiBub2Rlcy4NCiANCllBTkcgbW9kdWxl
cyBTSE9VTEQgYmUgZGVzaWduZWQgYXNzdW1pbmcgdGhleSB3aWxsIGJlIHVzZWQgb24gDQpzZXJ2
ZXJzIHN1cHBvcnRpbmcgPG9wZXJhdGlvbmFsPi4gIFdpdGggdGhpcyBpbiBtaW5kLCBZQU5HDQpt
b2R1bGVzIFNIT1VMRCBkZWZpbmUgY29uZmlnICJmYWxzZSIgd2hlcmV2ZXIgdGhleSBtYWtlIHNl
bnNlDQp0byB0aGUgZGF0YSBtb2RlbC4gIENvbmZpZyAiZmFsc2UiIG5vZGVzIFNIT1VMRCBOT1Qg
YmUgZGVmaW5lZA0KdG8gcHJvdmlkZSB0aGUgb3BlcmF0aW9uYWwgdmFsdWUgZm9yIGNvbmZpZ3Vy
YXRpb24gbm9kZXMsIA0KZXhjZXB0IHdoZW4gdGhlIHZhbHVlIHNwYWNlIG9mIGEgY29uZmlndXJl
ZCBhbmQgb3BlcmF0aW9uYWwNCnZhbHVlcyBtYXkgZGlmZmVyLCBpbiB3aGljaCBjYXNlIGEgZGlz
dGluY3QgY29uZmlnICJmYWxzZSIgDQpub2RlIFNIT1VMRCBiZSBkZWZpbmVkIHRvIGhvbGQgdGhl
IG9wZXJhdGlvbmFsIHZhbHVlIGZvciB0aGUNCmNvbmZpZ3VyZWQgbm9kZS4NCg0KPT09PT1TVE9Q
PT09PT0NCg0KDQpPbmUgcXVlc3Rpb24gdGhhdCBjYW1lIHVwIGlzIGlmICJvcGVyYXRpb25hbCBk
YXRhIiBpcyBhIHdlbGwtZGVmaW5lZA0KdGVybS4gIFRoaXMgc3RyaW5nIGFwcGVhcnMgMTAgdGlt
ZXMgaW4gcmZjNjA4N2Jpcy4gIE1vc3QgaW50ZXJlc3RpbmdseSwNCmFwcGVuZGl4IFNlY3Rpb24g
QS44LiAodjA1IHRvIHYwNikgaW5jbHVkZXMgdGhpcyBsaW5lIGl0ZW06DQoNCiAgICBDaGFuZ2Vk
IHRlcm0gIm9wZXJhdGlvbmFsIHN0YXRlIiB0byAib3BlcmF0aW9uYWwgZGF0YSINCg0KU28gaXQg
c2VlbXMgdG8gYmUgZGVsaWJlcmF0ZS4uLg0KDQoNCktlbnQgIC8vIGNvbnRyaWJ1dG9yDQoNCg0K
DQo=


From nobody Tue Aug 22 13:28:48 2017
Return-Path: 
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 541AD132A28 for ; Tue, 22 Aug 2017 13:28:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=calix.onmicrosoft.com
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 Vj7fLPEwnNa1 for ; Tue, 22 Aug 2017 13:28:44 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0180.outbound.protection.outlook.com [216.32.180.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03250132A30 for ; Tue, 22 Aug 2017 13:28:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=CALIX.onmicrosoft.com;  s=selector1-calix-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pz5iWSPjIwE9uEEgzalbjNiWixXh6UOiwgBVdhWppsk=; b=fTllM5sbg1oIXEp52pgtOxcnDBa6MUcWLKE+pyVsn5jxqchCdYvbR6EOZ4FWwTMgYiiaYb/rE1DF7TF43Y1Lfq0lnQQdd/r92saSbmwUcTpJbYV4KphFBLSRo5WDXdRDy4x9ZsDGvO4a2ueR8OHtdjOdAoolgkp9DiAR2MCzdQ4=
Received: from BY2PR0501MB1734.namprd05.prod.outlook.com (10.163.154.20) by BY2PR0501MB1767.namprd05.prod.outlook.com (10.163.154.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.4; Tue, 22 Aug 2017 20:28:40 +0000
Received: from BY2PR0501MB1734.namprd05.prod.outlook.com ([10.163.154.20]) by BY2PR0501MB1734.namprd05.prod.outlook.com ([10.163.154.20]) with mapi id 15.01.1385.008; Tue, 22 Aug 2017 20:28:40 +0000
From: Marta Seda 
To: "netmod@ietf.org" 
Thread-Topic: Question/Clarification of ietf-netmod-entity model
Thread-Index: AdMbhPfC2xmwFBNiRhifcmI0vcsz2w==
Date: Tue, 22 Aug 2017 20:28:40 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Marta.Seda@calix.com; 
x-originating-ip: [23.118.53.86]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BY2PR0501MB1767; 6:tN7jezy4IYXXkU/fK6YGibq82lM8pKm+D5ay+qEiUvcS6UaD5hP0xsTSx70DODx4RVoA+0gJ+m4axvxPHqD8wyQuyEL748otQcGjU6sn+3UxxPdUmA9I6ltW9DdsAExuFRwMf3t7770iyQ6UlLzLCCL7/LUfA61V3MvEHmPlS4kJ4SI7iwtM9D7ledPXVHSKRCf48SDR8GsFyI0pF6DkeRpbrvKHqVkd5uXcTFXVr7SoVT2zlBDIjWXDk9qdCEi7+69Scmp6xTJjM+iXqWTikG9t7lTHuu1IL83oghLTI0aVvaYBZqmlxpGWeFG/nAt7pWheN5PQmChiuT8lid997A==; 5:h8Ha2RG5hGenHxKfIKDii41wYjWBe/sDkITATweb6nLtezuKkOmys+cR/1qrnUXcMzERAwJBcofcP2OfIOkHuUvvEP8KQuxv5wpCqoEnJkuzqbmtOFLSwSFRaBpEbj6f5mDzHPRg0sXhwz5odOaGkA==; 24:xCnHcpJHuJGc9o6CVpFTbyWHgvKgJE5rvkNq7EoHqqbqSh6sIvchxhhaQsDWNvvS7juHeq3x1cYbnMIzj7Ai/MFVyecexrdYtWg4dlad7Ck=; 7:JW9ZTbFVCZcAslJrVw7RDcSOAbKLHbGL1UgLlSCLGUJteg/ZoY7A3IpWohr17f1/d7W7w0lunoJlH3c0WfWxBG7r3a1j2do7XTJlqSJYY7Di/GkHtEqkFgJEFGASOm5MwO5U2MFn/bFxzBPSzVN1vq1qDCaceW+0TEn557mqufbEZP+iWXX1Delw6GNJ8g2BYGYv76vvZEQgnYkXXv0IUfLlxAkKshq24Q0+Ady0cd8=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 30bfd53f-4268-4ef4-d9a8-08d4e99c6006
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BY2PR0501MB1767; 
x-ms-traffictypediagnostic: BY2PR0501MB1767:
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BY2PR0501MB1767; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BY2PR0501MB1767; 
x-forefront-prvs: 04073E895A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(3660700001)(2900100001)(8936002)(5630700001)(2906002)(72206003)(33656002)(189998001)(8676002)(230783001)(478600001)(105586002)(81166006)(81156014)(14454004)(68736007)(7696004)(2351001)(3846002)(1730700003)(5640700003)(54356999)(106356001)(5660300001)(50986999)(101416001)(7736002)(2501003)(9686003)(25786009)(110136004)(74316002)(99286003)(6916009)(3280700002)(6306002)(6436002)(54896002)(53936002)(86362001)(6506006)(66066001)(102836003)(55016002)(97736004)(790700001)(77096006)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR0501MB1767; H:BY2PR0501MB1734.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: calix.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR0501MB17340FD215471C0A5401349C9C840BY2PR0501MB1734_"
MIME-Version: 1.0
X-OriginatorOrg: calix.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Aug 2017 20:28:40.0376 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 8ffae2e5-6ff0-4510-bbf3-ca842d7ca55e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB1767
Archived-At: 
Subject: [netmod] Question/Clarification of ietf-netmod-entity model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Aug 2017 20:28:46 -0000

--_000_BY2PR0501MB17340FD215471C0A5401349C9C840BY2PR0501MB1734_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

RFC6933 Entity MIB contains the following tables:

     *   entPhysicalContainsTable (this is modeled in ietf-hardware-yang mo=
dule)
     *   entLPPhysicalTable (describes the mapping of logical entities and =
physical components supporting that entity).

There are some solution spaces that need to support logical entities (e.g.,=
 bridges, and other virtual entities).  The draft-ietf-netmod-entity-04 onl=
y addresses the entPhysicalContains Table.  Could someone comment as to the=
 reason for the omission of logical entities?  Is this by design  (ietf-net=
mod-entity is intended only to cover physical components and physical ports=
)? Or simply that it has not been gotten around to?

Thank you.

Regards,

Marta Seda
Calix


--_000_BY2PR0501MB17340FD215471C0A5401349C9C840BY2PR0501MB1734_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











RFC6933 Entity MIB contains the following tables:


    

      

    • e=
ntPhysicalContainsTable (this is modeled in ietf-hardware-yang module)=

    • entLPPhysicalTable (describes the mapping of logical entities and=
 physical components supporting that entity). 

    



 


There are some solution spaces that need to support =
logical entities (e.g., bridges, and other virtual entities).  The dra=
ft-ietf-netmod-entity-04 only addresses the entPhysicalContains Table. =
; Could someone comment as to the reason for
 the omission of logical entities?  Is this by design  (ietf-netm=
od-entity is intended only to cover physical components and physical ports)=
? Or simply that it has not been gotten around to? 



 


Thank you.


 


Regards,


 


Marta Seda


Calix


 






--_000_BY2PR0501MB17340FD215471C0A5401349C9C840BY2PR0501MB1734_--


From nobody Tue Aug 22 13:33:24 2017
Return-Path: 
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 2EE1B1329DC for ; Tue, 22 Aug 2017 13:33:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 T-3N4ZkG7cVu for ; Tue, 22 Aug 2017 13:33:17 -0700 (PDT)
Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 5F3B8132A28 for ; Tue, 22 Aug 2017 13:33:17 -0700 (PDT)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id C1D001762C0 for ; Tue, 22 Aug 2017 14:32:21 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id 0LYH1w00K2SSUrH01LYLZS; Tue, 22 Aug 2017 14:32:21 -0600
X-Authority-Analysis: v=2.2 cv=T7z8d7CQ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=KeKAF7QvOSUA:10 a=NEAV23lmAAAA:8 a=48vgC7mUAAAA:8 a=qeTzLgQg3ozEgAJRMAQA:9 a=1ghYXvFT8d5S5nKt:21 a=KRWQfoHPWQxBEuIO:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=tN978bO2MpzZR/hXVwUU+R0R+dmSKIPkx0C24vMR72U=; b=zkY4Xp7BeLYEO7/xRXQBg4dNAh hAoiCR09WYuMBRGagrqaK4KhEuiY4PO6yOKcrMVY2FFpBfT30bZEz8xZPpGcVpexVVVptdmT51T9A 8o15G22Fx7rNB1TxWA9e0/xFx;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:35578 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dkFqT-0015Sb-Qc; Tue, 22 Aug 2017 14:32:17 -0600
To: Kent Watsen , "netmod@ietf.org" 
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net>
From: Lou Berger 
Message-ID: <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net>
Date: Tue, 22 Aug 2017 16:32:14 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dkFqT-0015Sb-Qc
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:35578
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Aug 2017 20:33:21 -0000

Kent/WG,

    This seems a bit terse to me and not provide needed guidance during
the current transition period.  I understood  the discussion ended up 
with the options being to either (1) provide the guidance as a
standalone document, e.g., (a)-(s) in draft-dsdt-nmda-guidelines, with a
pointer to it from 6087bis or (2) just move those sections to 6087 bis. 
Either way, we'll need a new bis once the full NMDA solution makes it to
publication (request).

I thought the plan was to do (s).  If so, we need the full text. 
Looking at the current repo
(https://github.com/netmod-wg/datastore-dt/blob/master/guidelines/guidelines.txt)
it would be:

    4.23 Operational Data

    The following guidelines are meant to help modelers develop
    YANG models that will maximize the utility of the model with
    both current implementations and NMDA-capable implementations
    [draft-ietf-netmod-revised-datastores].

    (a) New models and models that are not concerned with the
    operational state of configuration information SHOULD
    immediately be structured to be NMDA-compatible.

    (b) Models that require immediate support for "in use" and
    "system created" information SHOULD be structured for NMDA.  A
    non-NMDA version of these models SHOULD exist, either an
    existing model or a model created either by hand or with
    suitable tools that mirror the current modeling strategies.
    Both the NMDA and the non-NMDA modules SHOULD be published in
    the same document, with NMDA modules in the document main body
    and the non-NMDA modules in a non-normative appendix.  The use
    of the non-NMDA model will allow temporary bridging of the
    time period until NMDA implementations are available.

    (c) For published models, the model should be republished with
    an NMDA-compatible structure, deprecating non-NMDA constructs.
    For example, the "ietf-interfaces" model in ^RFC7223^ will be
    restructured as an NMDA-compatible model.  The
    "/interfaces-state" hierarchy will be marked "status
    deprecated".  Models that mark their "/foo-state" hierarchy
    with "status deprecated" will allow NMDA-capable
    implementations to avoid the cost of duplicating the state
    nodes, while enabling non-NMDA-capable implementations to
    utilize them for access to the operational values.

    (d) For models that augment models which have not been
    structured with the NMDA, the modeler will have to consider
    the structure of the base model and the guidelines listed
    above.  Where possible, such models should move to new
    revisions of the base model that are NMDA-compatible.  When
    that is not possible, augmenting "state" containers SHOULD be
    avoided, with the expectation that the base model will be
    re-released with the state containers marked as deprecated.
    It is RECOMMENDED to augment only the "/foo" hierarchy of the
    base model.  Where this recommendation cannot be followed,
    then any new "state" elements SHOULD be included in their own
    module.

    To create the temporary non-NMDA model from an NMDA model, the
    following steps can be taken:
   
    - Rename the module name by postpending "-state" to the
      original module's name
    - Change the namespace by postpending "-state" to the original
      namespace value
    - Change the prefix by postpending "-s" to the original prefix
      value
    - Set all top-level nodes to have a "config" statement of
      value "false"
    - add an import to the original module (e.g., for typedef
      definitions)
    - modify any imports, used for leafrefs or identityrefs, to
      import the -state version of the module
    - remove any 'typedef' or 'identity' definitions
    - prefix any uses of the typedefs and identities accordingly
    - update leafref and augment paths to use the new "-s" prefix

For me (with any/all hats) the key downside is that we'll need to  rev
this text (again) in the not too distant future, but that we don't have
an alternative as LC on the full solution is still a bit away.

What do people think?  

Lou


On 8/22/2017 3:53 PM, Kent Watsen wrote:
> Hi,
>
> During the meeting in Chicago, the NMDA authors took an action to 
> propose some text for S4.23.  After a little review, the following
> emerged.  Yes, it's short, but was anything left anything out?
>
>
> =====START=====
>
> 4.23 Operational Data
>
> Operational data includes both config "false" nodes as well as,
> on servers supporting  [draft-ietf-netmod-revised-datastores],
> the applied value of config "true" nodes.
>  
> YANG modules SHOULD be designed assuming they will be used on 
> servers supporting .  With this in mind, YANG
> modules SHOULD define config "false" wherever they make sense
> to the data model.  Config "false" nodes SHOULD NOT be defined
> to provide the operational value for configuration nodes, 
> except when the value space of a configured and operational
> values may differ, in which case a distinct config "false" 
> node SHOULD be defined to hold the operational value for the
> configured node.
>
> =====STOP=====
>
>
> One question that came up is if "operational data" is a well-defined
> term.  This string appears 10 times in rfc6087bis.  Most interestingly,
> appendix Section A.8. (v05 to v06) includes this line item:
>
>     Changed term "operational state" to "operational data"
>
> So it seems to be deliberate...
>
>
> Kent  // contributor
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Tue Aug 22 15:21:29 2017
Return-Path: 
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 22F8A132A97; Tue, 22 Aug 2017 15:21:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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
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 UpwZ4U1b8CDQ; Tue, 22 Aug 2017 15:21:25 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87691132A95; Tue, 22 Aug 2017 15:21:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21053; q=dns/txt; s=iport; t=1503440485; x=1504650085; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=B5RQz2xTxhz+jJPjWedenAksSga9bXzBFLgjK692vJQ=; b=Tpp0xqpEUu4u+DWrlTn9mdZYkEgfu0GPHDUpUp/V/rXAfiaySNi5EARj kZall1rCWdjDdtumMSxVkOjV/+pjrzzfAM2RhxRZQcdugSUHDk6ENhtZ3 qls2i16XbQYi58SsAFVc/PglyCE72dkJdoL2EJN8kBp7ujKhkzGwV7acT o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmAAD4rZxZ/4kNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8+LWSBFQeODZAbgW6QZoU5ghIhAQyESk8CGoQXPxgBAgEBAQE?= =?us-ascii?q?BAQFrKIUYAQEBAQMBASFLBgUMBAIBCBEDAQEBKAMCAgIlCxQJCAIEAQ0FCYlEZ?= =?us-ascii?q?BCsXIImJ4tEAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYMqggKDL4MngkZggSY+CR6?= =?us-ascii?q?CVYJhBZghiDQCh1OMboIQWYkFhnKJbYw7AR84gQp3FUmFTIFOdgEBiD6BMoEPA?= =?us-ascii?q?QEB?=
X-IronPort-AV: E=Sophos;i="5.41,414,1498521600";  d="scan'208,217";a="446999873"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Aug 2017 22:21:24 +0000
Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v7MMLNuf029083 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Aug 2017 22:21:24 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 22 Aug 2017 18:21:23 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Tue, 22 Aug 2017 18:21:23 -0400
From: "Acee Lindem (acee)" 
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" ,  "'netmod@ietf.org'" 
CC: "bess@ietf.org" 
Thread-Topic: Pattern statements [was Re: [netmod] Query about augmenting module from submodule in YANG 1.0]
Thread-Index: AQHTGpA9Gl54VvqvVk+CY8qb3KBKRqKQ9NGA
Date: Tue, 22 Aug 2017 22:21:23 +0000
Message-ID: 
References:  <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com>  <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com>   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>   <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com>
In-Reply-To: <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.201]
Content-Type: multipart/alternative; boundary="_000_D5C2252FC2E98aceeciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] Pattern statements [was Re: 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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Aug 2017 22:21:29 -0000

--_000_D5C2252FC2E98aceeciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgUm9iLA0KSeKAmW0gZmluZSB3aXRoIHNpbXBsaWZ5aW5nIChldmVuIGlmIHRoZSByZXN1bHRh
bnQgcGF0dGVybiBpcyBtdWNoIGxlc3MgaW1wcmVzc2l2ZSA7XikuIEnigJl2ZSBjb3BpZWQgdGhl
IEJFU1MgV0cgdG8gc2VlIGlmIHRoZXJlIGFyZSBhbnkgb2JqZWN0aW9ucy4NClRoYW5rcywNCkFj
ZWUNCg0KRnJvbTogIlJvYmVydCBXaWx0b24gLVggKHJ3aWx0b24gLSBFTlNPRlQgTElNSVRFRCBh
dCBDaXNjbykiIDxyd2lsdG9uQGNpc2NvLmNvbTxtYWlsdG86cndpbHRvbkBjaXNjby5jb20+Pg0K
RGF0ZTogTW9uZGF5LCBBdWd1c3QgMjEsIDIwMTcgYXQgMTE6MTQgQU0NClRvOiBBY2VlIExpbmRl
bSA8YWNlZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lzY28uY29tPj4sICJJdm9yeSwgV2lsbGlh
bSIgPHdpbGxpYW0uaXZvcnlAaW50bC5hdHQuY29tPG1haWx0bzp3aWxsaWFtLml2b3J5QGludGwu
YXR0LmNvbT4+LCAiJ25ldG1vZEBpZXRmLm9yZzxtYWlsdG86J25ldG1vZEBpZXRmLm9yZz4nIiA8
bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+PiwgQW5keSBCaWVybWFuIDxh
bmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+DQpTdWJqZWN0OiBQ
YXR0ZXJuIHN0YXRlbWVudHMgW3dhcyBSZTogW25ldG1vZF0gUXVlcnkgYWJvdXQgYXVnbWVudGlu
ZyBtb2R1bGUgZnJvbSBzdWJtb2R1bGUgaW4gWUFORyAxLjBdDQoNCg0KSGkgQWNlZSwNCg0KVGhh
dCBtYWtlcyBzZW5zZS4NCg0KVGhlIG90aGVyIHRoaW5nIHRoYXQgSSB0aGluayB0aGF0IHdlIGhh
dmUgZ290IHdyb25nIGlzIG1vZGVsbGluZyByZWdleCBwYXR0ZXJuIHN0YXRlbWVudHMuICBJIHRo
aW5rIHRoYXQgaXQgd291bGQgYmUgbXVjaCBiZXR0ZXIgaWYgdGhlc2Ugd2VyZSB3cml0dGVuIHRv
IGJlIGxlc3MgZXhoYXVzdGl2ZSBhbmQgbXVjaCBzaW1wbGVyLg0KDQpFLmcuIHRoZSAicm91dGUg
ZGlzdGluZ3Vpc2hlciIgcGF0dGVybiBpbiBkcmFmdC1pZXRmLXJ0Z3dnLXJvdXRpbmctdHlwZXMt
MDkgaXMgZGVmaW5lZCBhcyB0aGlzOg0KDQogICAgICAgICBwYXR0ZXJuDQogICAgICAgICAgICco
MDooNjU1M1swLTVdfDY1NVswLTJdWzAtOV18NjVbMC00XVswLTldezJ9fCcNCiAgICAgICAgICsg
ICAgICc2WzAtNF1bMC05XXszfXwnDQogICAgICAgICArICAgICAnWzAtNV0/WzAtOV17MCwzfVsw
LTldKTooNDI5NDk2NzI5WzAtNV18Jw0KICAgICAgICAgKyAgICAgJzQyOTQ5NjcyWzAtOF1bMC05
XXwnDQogICAgICAgICArICAgICAnNDI5NDk2N1swMV1bMC05XXsyfXw0Mjk0OTZbMC02XVswLTld
ezN9fCcNCiAgICAgICAgICsgICAgICc0Mjk0OVswLTVdWzAtOV17NH18Jw0KICAgICAgICAgKyAg
ICAgJzQyOTRbMC04XVswLTldezV9fDQyOVswLTNdWzAtOV17Nn18Jw0KICAgICAgICAgKyAgICAg
JzQyWzAtOF1bMC05XXs3fXw0WzAxXVswLTldezh9fCcNCiAgICAgICAgICsgICAgICdbMC0zXT9b
MC05XXswLDh9WzAtOV0pKXwnDQogICAgICAgICArICcoMTooKChbMC05XXxbMS05XVswLTldfDFb
MC05XXsyfXwyWzAtNF1bMC05XXwnDQogICAgICAgICArICAgICAnMjVbMC01XSlcLil7M30oWzAt
OV18WzEtOV1bMC05XXwnDQogICAgICAgICArICAgICAnMVswLTldezJ9fDJbMC00XVswLTldfDI1
WzAtNV0pKTooNjU1M1swLTVdfCcNCiAgICAgICAgICsgICAgICc2NTVbMC0yXVswLTldfCcNCiAg
ICAgICAgICsgICAgICc2NVswLTRdWzAtOV17Mn18NlswLTRdWzAtOV17M318Jw0KICAgICAgICAg
KyAgICAgJ1swLTVdP1swLTldezAsM31bMC05XSkpfCcNCiAgICAgICAgICsgJygyOig0Mjk0OTY3
MjlbMC01XXw0Mjk0OTY3MlswLThdWzAtOV18Jw0KICAgICAgICAgKyAgICAgJzQyOTQ5NjdbMDFd
WzAtOV17Mn18Jw0KICAgICAgICAgKyAgICAgJzQyOTQ5NlswLTZdWzAtOV17M318NDI5NDlbMC01
XVswLTldezR9fCcNCiAgICAgICAgICsgICAgICc0Mjk0WzAtOF1bMC05XXs1fXwnDQogICAgICAg
ICArICAgICAnNDI5WzAtM11bMC05XXs2fXw0MlswLThdWzAtOV17N318NFswMV1bMC05XXs4fXwn
DQogICAgICAgICArICAgICAnWzAtM10/WzAtOV17MCw4fVswLTldKTonDQogICAgICAgICArICAg
ICAnKDY1NTNbMC01XXw2NTVbMC0yXVswLTldfDY1WzAtNF1bMC05XXsyfXwnDQogICAgICAgICAr
ICAgICAnNlswLTRdWzAtOV17M318Jw0KICAgICAgICAgKyAgICAgJ1swLTVdP1swLTldezAsM31b
MC05XSkpfCcNCiAgICAgICAgICsgJyg2KDpbYS1mQS1GMC05XXsyfSl7Nn0pfCcNCiAgICAgICAg
ICsgJygoWzMtNTctOWEtZkEtRl18WzEtOWEtZkEtRl1bMC05YS1mQS1GXXsxLDN9KTonDQogICAg
ICAgICArICAgICAnWzAtOWEtZkEtRl17MSwxMn0pJzsNCiAgICAgICB9DQoNCg0KQnV0IEkgdGhp
bmsgdGhhdCBpdCB3b3VsZCBiZSBtdWNoIGVhc2llciB0byByZWFkLCBhbmQgcXVpdGUgcG9zc2li
bHkgbW9yZSBwZXJmb3JtYW50IHRvIGV4ZWN1dGUsIGlmIHRoZSBwYXR0ZXJuIHJlZ2V4IHdhcyB3
cml0dGVuIHNvbWV0aGluZyBsaWtlIHRoZSBmb2xsb3dpbmc6DQoNCiBwYXR0ZXJuOg0KICAgICco
MDpbMC05XXsxLDV9OlswLTldezEsMTB9KXwNCiAgICAgKDE6KFswLTldezEsM31cLil7NH06WzAt
OV17MSw1fSl8DQogICAgICgyOlswLTldezEsMTB9OjA6WzAtOV17MSw1fSl8DQogICAgICg2KDpb
YS1mQS1GMC05XXsyfSl7Nn0pJzsNCg0KT2YgY291cnNlLCB0aGlzIHdvdWxkIGFsbG93IG1vcmUg
aW52YWxpZCB2YWx1ZXMsIGJ1dCBtb3N0IHNlcnZlcnMgd291bGQgYmUgZXhwZWN0ZWQgdG8gcmVq
ZWN0IHRob3NlIHdoZW4gaXQgY29udmVydHMgdGhlbSBpbnRvIGFuIGludGVybmFsIGJpbmFyeSBm
b3JtYXQgYW55IHdheS4NCg0KV2hhdCBkbyB5b3UsIGFuZCBvdGhlcnMsIHRoaW5rPw0KDQpUaGFu
a3MsDQpSb2INCg0KDQpPbiAyMS8wOC8yMDE3IDE1OjAxLCBBY2VlIExpbmRlbSAoYWNlZSkgd3Jv
dGU6DQoNCkhpIFdpbGxpYW0sIFJvYiwgQW5keSwNCg0KR2l2ZW4gdGhlaXIgbGltaXRlZCB1c2Vm
dWxuZXNzIGFuZCB0aGUgZGV0cmltZW50cywgcGVyaGFwcyB3ZSBzaG91bGQNCmRpc2NvdXJhZ2Ug
dGhlIGNyZWF0aW9uIG9mIG5ldyBzdWJtb2R1bGVzIGluIFJGQzYwODdCaXMuDQoNClRoYW5rcywN
CkFjZWUNCg0KT24gOC8yMS8xNywgOTo0NCBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgSXZvcnks
IFdpbGxpYW0iDQo8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHdpbGxpYW0u
aXZvcnlAaW50bC5hdHQuY29tPjxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmdvbmJlaGFs
Zm9md2lsbGlhbS5pdm9yeUBpbnRsLmF0dC5jb20+IHdyb3RlOg0KDQoNCg0KSGkgUm9iLA0KDQpU
aGF0IHdvdWxkIG1ha2UgaXQgdmVyeSBoYXJkIHRvIHVwZGF0ZSBleGlzdGluZyAxLnggWUFORyBt
b2RlbHMgdG8gdXNlDQpuZXcgZmVhdHVyZXMgaW4gWUFORyAyLnggaWYgdGhleSB1c2VkIHN1Ym1v
ZHVsZXMuICBNYXliZSB0aGF0J3Mgc29tZXRoaW5nDQp0aGF0IG5vIG9uZSB3b3VsZCBldmVyIGNv
bnNpZGVyIGRvaW5nIGFueXdheSwgb3IgbWF5YmUgWUFORyAxLjEgYWxyZWFkeQ0KaGFzIHNpbWls
YXIgZGlmZmVyZW5jZXMgdG8gMS4wPyAgSSBoYWQgKHBlcmhhcHMgbmFpdmVseSkgYXNzdW1lZCB0
aGF0IHlvdQ0KY291bGQgbWlncmF0ZSBhIG5hbWVzcGFjZSAvIG1vZGVsIGZyb20gWUFORyAxLjAg
dG8gMi4wPw0KDQpSZWdhcmRzLA0KDQpXaWxsaWFtDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t
LS0tDQpGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo
YWxmIE9mIFJvYmVydCBXaWx0b24NClNlbnQ6IDIxIEF1Z3VzdCAyMDE3IDExOjI0DQpUbzogbmV0
bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25ldG1v
ZF0gUXVlcnkgYWJvdXQgYXVnbWVudGluZyBtb2R1bGUgZnJvbSBzdWJtb2R1bGUgaW4NCllBTkcg
MS4wDQoNCg0KDQpPbiAwOS8wOC8yMDE3IDE2OjEzLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgd3Jv
dGU6DQoNCg0KT24gV2VkLCBBdWcgMDksIDIwMTcgYXQgMDU6MDE6MDlQTSArMDIwMCwgTGFkaXNs
YXYgTGhvdGthIHdyb3RlOg0KDQoNCkkgcmVtZW1iZXIgdGhhdCBpbiBlYXJseSBzdGFnZXMgb2Yg
WUFORyB0aGVyZSB3YXMgc29tZSBpcnJhdGlvbmFsDQpmZWFyIG9mIGludHJvZHVjaW5nIHRvbyBt
YW55IG5hbWVzcGFjZXMsIGFuZCBzdWJtb2R1bGVzIG1heSBiZSBhDQpjb25zZXF1ZW5jZSBvZiBp
dC4gQXMgeW91IHdyaXRlLCBzdWJtb2R1bGVzIHByb3ZpZGUgbm8gYmVuZWZpdHMNCndoYXRzb2V2
ZXIgaW4gdGVybXMgb2YgbW9kdWxhcml0eSwgYnV0IHRoZSBvdmVyaGVhZCBpbiB0ZXJtcyBvZg0K
bWV0YWRhdGEsIElBTkEgcmVnaXN0cmF0aW9uIGV0Yy4gaXMgcHJldHR5IG11Y2ggdGhlIHNhbWUg
YXMgZm9yDQptb2R1bGVzLg0KDQoNCkluIGNhc2UgWUFORyAyLjAgaXMgZXZlciBkb25lLCBJIHN1
Z2dlc3Qgc29tZW9uZSBmaWxlcyBhIHByb3Bvc2FsIHRvDQpyZW1vdmUgc3VibW9kdWxlcyBpZiB0
aGUgY29zdC9iZW5lZml0IHJhdGlvIGlzIGF0IG9kZHMuIFRoZXJlIGlzDQpub3RoaW5nIHdyb25n
IHdpdGggcmVtb3Zpbmcgc3R1ZmYgdGhhdCBoYXMgYmVlbiBmb3VuZCBwcm9ibGVtYXRpYy4NCg0K
DQpJIGFncmVlLg0KDQpJJ3ZlIGFkZGVkDQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j
b20vdjIvdXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21fbmV0bW9kLTJEdw0KZ195YW5nLTJEbmV4
dF9pc3N1ZXNfMjYmZD1Ed0lDQWcmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9cDhreWVLM3U0
WllpYVENCjJaUEdxd2t5WG1RZ0JINnI1anBZaVlXemhxSjQ4Jm09bDdjNElQTDA0OUEyYlZWTzE0
ZnlCTWx5MjExeFU2MXhTSGdQbEFUN293DQpJJnM9LWtSNGZVdFhBclF5MFJ3V2IzMkRwVDFiUDRY
X2NOcXQyekpWb0MwSmlYOCZlPQ0KDQpSb2INCg0KDQoNClRoZSBtb3RpdmF0aW9uIGZvciBzdWJt
b2R1bGVzIHdhcyB0aGF0IG9yZ2FuaXphdGlvbnMgbWFpbnRhaW5pbmcgbGFyZ2UNCm1vZHVsZXMg
d2l0aCBtdWx0aXBsZSBwZW9wbGUgY2FuIGRvIHNvIHdpdGhvdXQgaGF2aW5nIHRvIG1lc3MgYXJv
dW5kDQp3aXRoIHRvb2xzIGxpa2UgbTQgc2NyaXB0cyB0byBwcm9kdWNlIGEgc2luZ2xlIG1vZHVs
ZSBmcm9tICdzbmlwcGV0cycNCmFuZCB0byBhdm9pZCBpbnRlZ3JhdGlvbiBzdXJwcmlzZXMuIEJ1
dCBwZXJoYXBzIHVzaW5nIG00IHNjcmlwdHMgYW5kDQpkZWNlbnQgdmVyc2lvbiBjb250cm9sIHN5
c3RlbXMgKHRoYXQgY2FuIGludGVncmF0ZSBhbmQgY29tcGlsZSBvbg0KY2hlY2tpbikgaXMgaW5k
ZWVkIGNoZWFwZXIgdGhhbiBoYXZpbmcgc3VibW9kdWxlcyBwYXJ0IG9mIHRoZSBZQU5HDQpsYW5n
dWFnZSBpdHNlbGYuDQoNCi9qcw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxt
YWlsdG86bmV0bW9kQGlldGYub3JnPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92
Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fDQpsaXN0aW5mb19uZXRtb2Qm
ZD1Ed0lDQWcmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9cDhreWVLM3U0WllpYVEyWlBHcXdr
eQ0KWG1RZ0JINnI1anBZaVlXemhxSjQ4Jm09bDdjNElQTDA0OUEyYlZWTzE0ZnlCTWx5MjExeFU2
MXhTSGdQbEFUN293SSZzPXQ3dkcNCklIOEFCdUFtMDBlLWJrU293RDllYXdNb2RHcTBOMk9rakFO
dHBZSSZlPQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0
Zi5vcmc+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K

--_000_D5C2252FC2E98aceeciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBSb2IsJm5i
c3A7PC9kaXY+DQo8ZGl2PknigJltIGZpbmUgd2l0aCBzaW1wbGlmeWluZyAoZXZlbiBpZiB0aGUg
cmVzdWx0YW50IHBhdHRlcm4gaXMgbXVjaCBsZXNzIGltcHJlc3NpdmUgO14pLiBJ4oCZdmUgY29w
aWVkIHRoZSBCRVNTIFdHIHRvIHNlZSBpZiB0aGVyZSBhcmUgYW55IG9iamVjdGlvbnMuJm5ic3A7
PC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QWNlZSZuYnNwOzwvZGl2Pg0KPGRpdj48
YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxl
PSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBj
b2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRp
dW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkct
UklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDog
bWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0
OmJvbGQiPkZyb206IDwvc3Bhbj4mcXVvdDtSb2JlcnQgV2lsdG9uIC1YIChyd2lsdG9uIC0gRU5T
T0ZUIExJTUlURUQgYXQgQ2lzY28pJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cndpbHRvbkBj
aXNjby5jb20iPnJ3aWx0b25AY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9u
dC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPk1vbmRheSwgQXVndXN0IDIxLCAyMDE3IGF0IDEx
OjE0IEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+QWNl
ZSBMaW5kZW0gJmx0OzxhIGhyZWY9Im1haWx0bzphY2VlQGNpc2NvLmNvbSI+YWNlZUBjaXNjby5j
b208L2E+Jmd0OywgJnF1b3Q7SXZvcnksIFdpbGxpYW0mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0
bzp3aWxsaWFtLml2b3J5QGludGwuYXR0LmNvbSI+d2lsbGlhbS5pdm9yeUBpbnRsLmF0dC5jb208
L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOiduZXRtb2RAaWV0Zi5vcmciPiduZXRtb2RA
aWV0Zi5vcmc8L2E+JyZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3Jn
Ij5uZXRtb2RAaWV0Zi5vcmc8L2E+Jmd0OywgQW5keSBCaWVybWFuICZsdDs8YSBocmVmPSJtYWls
dG86YW5keUB5dW1hd29ya3MuY29tIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0Ozxicj4NCjxz
cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UGF0dGVybiBzdGF0
ZW1lbnRzIFt3YXMgUmU6IFtuZXRtb2RdIFF1ZXJ5IGFib3V0IGF1Z21lbnRpbmcgbW9kdWxlIGZy
b20gc3VibW9kdWxlIGluIFlBTkcgMS4wXTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N
CjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHls
ZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46
MCAwIDAgNTsiPg0KPGRpdj4NCjxkaXYgdGV4dD0iIzAwMDAwMCIgYmdjb2xvcj0iI0ZGRkZGRiI+
DQo8cD5IaSBBY2VlLDwvcD4NCjxwPlRoYXQgbWFrZXMgc2Vuc2UuPC9wPg0KPHA+VGhlIG90aGVy
IHRoaW5nIHRoYXQgSSB0aGluayB0aGF0IHdlIGhhdmUgZ290IHdyb25nIGlzIG1vZGVsbGluZyBy
ZWdleCBwYXR0ZXJuIHN0YXRlbWVudHMuJm5ic3A7IEkgdGhpbmsgdGhhdCBpdCB3b3VsZCBiZSBt
dWNoIGJldHRlciBpZiB0aGVzZSB3ZXJlIHdyaXR0ZW4gdG8gYmUgbGVzcyBleGhhdXN0aXZlIGFu
ZCBtdWNoIHNpbXBsZXIuPC9wPg0KPHA+RS5nLiB0aGUgJnF1b3Q7cm91dGUgZGlzdGluZ3Vpc2hl
ciZxdW90OyBwYXR0ZXJuIGluIGRyYWZ0LWlldGYtcnRnd2ctcm91dGluZy10eXBlcy0wOSBpcyBk
ZWZpbmVkIGFzIHRoaXM6PC9wPg0KPHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6
ZTogMTMuMzMzM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgYnJlYWst
YmVmb3JlOiBwYWdlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXN0eWxlOiBub3JtYWw7IGZv
bnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg
Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogMjsg
dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25l
OyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo
OiAwcHg7IHRleHQtZGVjb3JhdGlvbi1zdHlsZTogaW5pdGlhbDsgdGV4dC1kZWNvcmF0aW9uLWNv
bG9yOiBpbml0aWFsOyI+ICAgICAgICAgcGF0dGVybg0KICAgICAgICAgICAnKDA6KDY1NTNbMC01
XXw2NTVbMC0yXVswLTldfDY1WzAtNF1bMC05XXsyfXwnDQogICAgICAgICAmIzQzOyAgICAgJzZb
MC00XVswLTldezN9fCcNCiAgICAgICAgICYjNDM7ICAgICAnWzAtNV0/WzAtOV17MCwzfVswLTld
KTooNDI5NDk2NzI5WzAtNV18Jw0KICAgICAgICAgJiM0MzsgICAgICc0Mjk0OTY3MlswLThdWzAt
OV18Jw0KICAgICAgICAgJiM0MzsgICAgICc0Mjk0OTY3WzAxXVswLTldezJ9fDQyOTQ5NlswLTZd
WzAtOV17M318Jw0KICAgICAgICAgJiM0MzsgICAgICc0Mjk0OVswLTVdWzAtOV17NH18Jw0KICAg
ICAgICAgJiM0MzsgICAgICc0Mjk0WzAtOF1bMC05XXs1fXw0MjlbMC0zXVswLTldezZ9fCcNCiAg
ICAgICAgICYjNDM7ICAgICAnNDJbMC04XVswLTldezd9fDRbMDFdWzAtOV17OH18Jw0KICAgICAg
ICAgJiM0MzsgICAgICdbMC0zXT9bMC05XXswLDh9WzAtOV0pKXwnDQogICAgICAgICAmIzQzOyAn
KDE6KCgoWzAtOV18WzEtOV1bMC05XXwxWzAtOV17Mn18MlswLTRdWzAtOV18Jw0KICAgICAgICAg
JiM0MzsgICAgICcyNVswLTVdKVwuKXszfShbMC05XXxbMS05XVswLTldfCcNCiAgICAgICAgICYj
NDM7ICAgICAnMVswLTldezJ9fDJbMC00XVswLTldfDI1WzAtNV0pKTooNjU1M1swLTVdfCcNCiAg
ICAgICAgICYjNDM7ICAgICAnNjU1WzAtMl1bMC05XXwnDQogICAgICAgICAmIzQzOyAgICAgJzY1
WzAtNF1bMC05XXsyfXw2WzAtNF1bMC05XXszfXwnDQogICAgICAgICAmIzQzOyAgICAgJ1swLTVd
P1swLTldezAsM31bMC05XSkpfCcNCiAgICAgICAgICYjNDM7ICcoMjooNDI5NDk2NzI5WzAtNV18
NDI5NDk2NzJbMC04XVswLTldfCcNCiAgICAgICAgICYjNDM7ICAgICAnNDI5NDk2N1swMV1bMC05
XXsyfXwnDQogICAgICAgICAmIzQzOyAgICAgJzQyOTQ5NlswLTZdWzAtOV17M318NDI5NDlbMC01
XVswLTldezR9fCcNCiAgICAgICAgICYjNDM7ICAgICAnNDI5NFswLThdWzAtOV17NX18Jw0KICAg
ICAgICAgJiM0MzsgICAgICc0MjlbMC0zXVswLTldezZ9fDQyWzAtOF1bMC05XXs3fXw0WzAxXVsw
LTldezh9fCcNCiAgICAgICAgICYjNDM7ICAgICAnWzAtM10/WzAtOV17MCw4fVswLTldKTonDQog
ICAgICAgICAmIzQzOyAgICAgJyg2NTUzWzAtNV18NjU1WzAtMl1bMC05XXw2NVswLTRdWzAtOV17
Mn18Jw0KICAgICAgICAgJiM0MzsgICAgICc2WzAtNF1bMC05XXszfXwnDQogICAgICAgICAmIzQz
OyAgICAgJ1swLTVdP1swLTldezAsM31bMC05XSkpfCcNCiAgICAgICAgICYjNDM7ICcoNig6W2Et
ZkEtRjAtOV17Mn0pezZ9KXwnDQogICAgICAgICAmIzQzOyAnKChbMy01Ny05YS1mQS1GXXxbMS05
YS1mQS1GXVswLTlhLWZBLUZdezEsM30pOicNCiAgICAgICAgICYjNDM7ICAgICAnWzAtOWEtZkEt
Rl17MSwxMn0pJzsNCiAgICAgICB9DQo8L3ByZT4NCjxicj4NCkJ1dCBJIHRoaW5rIHRoYXQgaXQg
d291bGQgYmUgbXVjaCBlYXNpZXIgdG8gcmVhZCwgYW5kIHF1aXRlIHBvc3NpYmx5IG1vcmUgcGVy
Zm9ybWFudCB0byBleGVjdXRlLCBpZiB0aGUgcGF0dGVybiByZWdleCB3YXMgd3JpdHRlbiBzb21l
dGhpbmcgbGlrZSB0aGUgZm9sbG93aW5nOjxicj4NCjxicj4NCiZuYnNwO3BhdHRlcm46PGJyPg0K
PHR0PiZuYnNwOyZuYnNwOyZuYnNwOyAnKDA6WzAtOV17MSw1fTpbMC05XXsxLDEwfSl8PC90dD48
dHQ+PGJyPg0KPC90dD48dHQ+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICgxOihbMC05XXsxLDN9
XC4pezR9OlswLTldezEsNX0pfDwvdHQ+PHR0Pjxicj4NCjwvdHQ+PHR0PiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyAoMjpbMC05XXsxLDEwfTowOlswLTldezEsNX0pfDwvdHQ+PHR0Pjxicj4NCjwv
dHQ+PHR0PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoNig6W2EtZkEtRjAtOV17Mn0pezZ9KSc7
PC90dD48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgPGJyPg0KT2YgY291cnNlLCB0aGlzIHdvdWxk
IGFsbG93IG1vcmUgaW52YWxpZCB2YWx1ZXMsIGJ1dCBtb3N0IHNlcnZlcnMgd291bGQgYmUgZXhw
ZWN0ZWQgdG8gcmVqZWN0IHRob3NlIHdoZW4gaXQgY29udmVydHMgdGhlbSBpbnRvIGFuIGludGVy
bmFsIGJpbmFyeSBmb3JtYXQgYW55IHdheS48YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5l
d2xpbmUiPg0KPGJyPg0KV2hhdCBkbyB5b3UsIGFuZCBvdGhlcnMsIHRoaW5rPzxicj4NCjxicj4N
ClRoYW5rcyw8YnI+DQpSb2I8YnI+DQo8YnI+DQo8YnI+DQo8ZGl2IGNsYXNzPSJtb3otY2l0ZS1w
cmVmaXgiPk9uIDIxLzA4LzIwMTcgMTU6MDEsIEFjZWUgTGluZGVtIChhY2VlKSB3cm90ZTo8YnI+
DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9Im1pZDpENUMwNUVCMy5DMjY4
MSUyNWFjZWVAY2lzY28uY29tIj4NCjxwcmUgd3JhcD0iIj5IaSBXaWxsaWFtLCBSb2IsIEFuZHks
DQoNCkdpdmVuIHRoZWlyIGxpbWl0ZWQgdXNlZnVsbmVzcyBhbmQgdGhlIGRldHJpbWVudHMsIHBl
cmhhcHMgd2Ugc2hvdWxkDQpkaXNjb3VyYWdlIHRoZSBjcmVhdGlvbiBvZiBuZXcgc3VibW9kdWxl
cyBpbiBSRkM2MDg3QmlzLg0KDQpUaGFua3MsDQpBY2VlDQoNCk9uIDgvMjEvMTcsIDk6NDQgQU0s
ICZxdW90O25ldG1vZCBvbiBiZWhhbGYgb2YgSXZvcnksIFdpbGxpYW0mcXVvdDsNCjxhIGNsYXNz
PSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRm
Lm9yZ29uYmVoYWxmb2Z3aWxsaWFtLml2b3J5QGludGwuYXR0LmNvbSI+Jmx0O25ldG1vZC1ib3Vu
Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiB3aWxsaWFtLml2b3J5QGludGwuYXR0LmNvbSZndDs8
L2E+IHdyb3RlOg0KDQo8L3ByZT4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPHByZSB3cmFw
PSIiPkhpIFJvYiwNCg0KVGhhdCB3b3VsZCBtYWtlIGl0IHZlcnkgaGFyZCB0byB1cGRhdGUgZXhp
c3RpbmcgMS54IFlBTkcgbW9kZWxzIHRvIHVzZQ0KbmV3IGZlYXR1cmVzIGluIFlBTkcgMi54IGlm
IHRoZXkgdXNlZCBzdWJtb2R1bGVzLiAgTWF5YmUgdGhhdCdzIHNvbWV0aGluZw0KdGhhdCBubyBv
bmUgd291bGQgZXZlciBjb25zaWRlciBkb2luZyBhbnl3YXksIG9yIG1heWJlIFlBTkcgMS4xIGFs
cmVhZHkNCmhhcyBzaW1pbGFyIGRpZmZlcmVuY2VzIHRvIDEuMD8gIEkgaGFkIChwZXJoYXBzIG5h
aXZlbHkpIGFzc3VtZWQgdGhhdCB5b3UNCmNvdWxkIG1pZ3JhdGUgYSBuYW1lc3BhY2UgLyBtb2Rl
bCBmcm9tIFlBTkcgMS4wIHRvIDIuMD8NCg0KUmVnYXJkcywNCg0KV2lsbGlhbQ0KDQotLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbmV0bW9kIFs8YSBjbGFzcz0ibW96LXR4dC1saW5r
LWZyZWV0ZXh0IiBocmVmPSJtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpu
ZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBSb2JlcnQgV2lsdG9uDQpT
ZW50OiAyMSBBdWd1c3QgMjAxNyAxMToyNA0KVG86IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJi
cmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwv
YT4NClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBRdWVyeSBhYm91dCBhdWdtZW50aW5nIG1vZHVsZSBm
cm9tIHN1Ym1vZHVsZSBpbg0KWUFORyAxLjANCg0KDQoNCk9uIDA5LzA4LzIwMTcgMTY6MTMsIEp1
ZXJnZW4gU2Nob2Vud2FlbGRlciB3cm90ZToNCjwvcHJlPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0
ZSI+DQo8cHJlIHdyYXA9IiI+T24gV2VkLCBBdWcgMDksIDIwMTcgYXQgMDU6MDE6MDlQTSAmIzQz
OzAyMDAsIExhZGlzbGF2IExob3RrYSB3cm90ZToNCjwvcHJlPg0KPGJsb2NrcXVvdGUgdHlwZT0i
Y2l0ZSI+DQo8cHJlIHdyYXA9IiI+SSByZW1lbWJlciB0aGF0IGluIGVhcmx5IHN0YWdlcyBvZiBZ
QU5HIHRoZXJlIHdhcyBzb21lIGlycmF0aW9uYWwNCmZlYXIgb2YgaW50cm9kdWNpbmcgdG9vIG1h
bnkgbmFtZXNwYWNlcywgYW5kIHN1Ym1vZHVsZXMgbWF5IGJlIGENCmNvbnNlcXVlbmNlIG9mIGl0
LiBBcyB5b3Ugd3JpdGUsIHN1Ym1vZHVsZXMgcHJvdmlkZSBubyBiZW5lZml0cw0Kd2hhdHNvZXZl
ciBpbiB0ZXJtcyBvZiBtb2R1bGFyaXR5LCBidXQgdGhlIG92ZXJoZWFkIGluIHRlcm1zIG9mDQpt
ZXRhZGF0YSwgSUFOQSByZWdpc3RyYXRpb24gZXRjLiBpcyBwcmV0dHkgbXVjaCB0aGUgc2FtZSBh
cyBmb3INCm1vZHVsZXMuDQo8L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmUgd3JhcD0iIj5JbiBj
YXNlIFlBTkcgMi4wIGlzIGV2ZXIgZG9uZSwgSSBzdWdnZXN0IHNvbWVvbmUgZmlsZXMgYSBwcm9w
b3NhbCB0bw0KcmVtb3ZlIHN1Ym1vZHVsZXMgaWYgdGhlIGNvc3QvYmVuZWZpdCByYXRpbyBpcyBh
dCBvZGRzLiBUaGVyZSBpcw0Kbm90aGluZyB3cm9uZyB3aXRoIHJlbW92aW5nIHN0dWZmIHRoYXQg
aGFzIGJlZW4gZm91bmQgcHJvYmxlbWF0aWMuDQo8L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmUg
d3JhcD0iIj5JIGFncmVlLg0KDQpJJ3ZlIGFkZGVkIA0KPGEgY2xhc3M9Im1vei10eHQtbGluay1m
cmVldGV4dCIgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91
PWh0dHBzLTNBX19naXRodWIuY29tX25ldG1vZC0yRHciPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v
ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9uZXRtb2QtMkR3PC9hPg0K
Z195YW5nLTJEbmV4dF9pc3N1ZXNfMjYmYW1wO2Q9RHdJQ0FnJmFtcDtjPUxGWVotbzlfSFVNZU1U
U1FpY3ZqSWcmYW1wO3I9cDhreWVLM3U0WllpYVENCjJaUEdxd2t5WG1RZ0JINnI1anBZaVlXemhx
SjQ4JmFtcDttPWw3YzRJUEwwNDlBMmJWVk8xNGZ5Qk1seTIxMXhVNjF4U0hnUGxBVDdvdw0KSSZh
bXA7cz0ta1I0ZlV0WEFyUXkwUndXYjMyRHBUMWJQNFhfY05xdDJ6SlZvQzBKaVg4JmFtcDtlPQ0K
DQpSb2INCg0KPC9wcmU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxwcmUgd3JhcD0iIj5U
aGUgbW90aXZhdGlvbiBmb3Igc3VibW9kdWxlcyB3YXMgdGhhdCBvcmdhbml6YXRpb25zIG1haW50
YWluaW5nIGxhcmdlDQptb2R1bGVzIHdpdGggbXVsdGlwbGUgcGVvcGxlIGNhbiBkbyBzbyB3aXRo
b3V0IGhhdmluZyB0byBtZXNzIGFyb3VuZA0Kd2l0aCB0b29scyBsaWtlIG00IHNjcmlwdHMgdG8g
cHJvZHVjZSBhIHNpbmdsZSBtb2R1bGUgZnJvbSAnc25pcHBldHMnDQphbmQgdG8gYXZvaWQgaW50
ZWdyYXRpb24gc3VycHJpc2VzLiBCdXQgcGVyaGFwcyB1c2luZyBtNCBzY3JpcHRzIGFuZA0KZGVj
ZW50IHZlcnNpb24gY29udHJvbCBzeXN0ZW1zICh0aGF0IGNhbiBpbnRlZ3JhdGUgYW5kIGNvbXBp
bGUgb24NCmNoZWNraW4pIGlzIGluZGVlZCBjaGVhcGVyIHRoYW4gaGF2aW5nIHN1Ym1vZHVsZXMg
cGFydCBvZiB0aGUgWUFORw0KbGFuZ3VhZ2UgaXRzZWxmLg0KDQovanMNCg0KPC9wcmU+DQo8L2Js
b2NrcXVvdGU+DQo8cHJlIHdyYXA9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCjxhIGNsYXNzPSJtb3otdHh0LWxp
bmstYWJicmV2aWF0ZWQiIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRm
Lm9yZzwvYT48YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3Vy
bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19t
YWlsbWFuXyI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz
LTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl88L2E+DQpsaXN0aW5mb19uZXRtb2QmYW1wO2Q9RHdJ
Q0FnJmFtcDtjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmYW1wO3I9cDhreWVLM3U0WllpYVEyWlBH
cXdreQ0KWG1RZ0JINnI1anBZaVlXemhxSjQ4JmFtcDttPWw3YzRJUEwwNDlBMmJWVk8xNGZ5Qk1s
eTIxMXhVNjF4U0hnUGxBVDdvd0kmYW1wO3M9dDd2Rw0KSUg4QUJ1QW0wMGUtYmtTb3dEOWVhd01v
ZEdxME4yT2tqQU50cFlJJmFtcDtlPQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KPGEgY2xhc3M9Im1vei10eHQt
bGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGll
dGYub3JnPC9hPjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9Imh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIj5odHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxwcmUg
d3JhcD0iIj48L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js
b2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_D5C2252FC2E98aceeciscocom_--


From nobody Tue Aug 22 15:28:02 2017
Return-Path: 
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 16AB11329F1 for ; Tue, 22 Aug 2017 15:28:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 SXdgqirrvlWz for ; Tue, 22 Aug 2017 15:27:59 -0700 (PDT)
Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 360641329D0 for ; Tue, 22 Aug 2017 15:27:59 -0700 (PDT)
From: Alex Campbell 
To: "Ivory, William" , 'Robert Wilton' , "'netmod@ietf.org'" 
Thread-Topic: [netmod] Query about augmenting module from submodule in YANG 1.0
Thread-Index: AdMMOPUClm48yMKSSEeEurX4RbXaiADgq3iAAAJrJQAACj/LAAAat6MAAD8I6oAAAWwvgAAAa7wAAlFjp4AABwEPAAA113x4
Date: Tue, 22 Aug 2017 22:27:57 +0000
Message-ID: <1503440878003.28215@Aviatnet.com>
References:  <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com>  <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com>   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>, 
In-Reply-To: 
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.9]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Aug 2017 22:28:01 -0000

Hi,=0A=
=0A=
I'm not Rob, but my understanding is that if a module author wanted to migr=
ate to YANG 2.0, they could merge their submodules back into the main modul=
e - which is not a difficult procedure and does not break compatibility wit=
h clients.=0A=
=0A=
Alex=0A=
________________________________________=0A=
From: netmod  on behalf of Ivory, William =0A=
Sent: Tuesday, 22 August 2017 1:44 a.m.=0A=
To: 'Robert Wilton'; 'netmod@ietf.org'=0A=
Subject: Re: [netmod] Query about augmenting module from submodule in YANG =
1.0=0A=
=0A=
Hi Rob,=0A=
=0A=
That would make it very hard to update existing 1.x YANG models to use new =
features in YANG 2.x if they used submodules.  Maybe that's something that =
no one would ever consider doing anyway, or maybe YANG 1.1 already has simi=
lar differences to 1.0?  I had (perhaps naively) assumed that you could mig=
rate a namespace / model from YANG 1.0 to 2.0?=0A=
=0A=
Regards,=0A=
=0A=
William=0A=
=0A=
-----Original Message-----=0A=
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton=0A=
Sent: 21 August 2017 11:24=0A=
To: netmod@ietf.org=0A=
Subject: Re: [netmod] Query about augmenting module from submodule in YANG =
1.0=0A=
=0A=
=0A=
=0A=
On 09/08/2017 16:13, Juergen Schoenwaelder wrote:=0A=
> On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka wrote:=0A=
>> I remember that in early stages of YANG there was some irrational=0A=
>> fear of introducing too many namespaces, and submodules may be a=0A=
>> consequence of it. As you write, submodules provide no benefits=0A=
>> whatsoever in terms of modularity, but the overhead in terms of=0A=
>> metadata, IANA registration etc. is pretty much the same as for=0A=
>> modules.=0A=
> In case YANG 2.0 is ever done, I suggest someone files a proposal to=0A=
> remove submodules if the cost/benefit ratio is at odds. There is=0A=
> nothing wrong with removing stuff that has been found problematic.=0A=
I agree.=0A=
=0A=
I've added https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.co=
m_netmod-2Dwg_yang-2Dnext_issues_26&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=
=3Dp8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=3Dl7c4IPL049A2bVVO14fyBMly=
211xU61xSHgPlAT7owI&s=3D-kR4fUtXArQy0RwWb32DpT1bP4X_cNqt2zJVoC0JiX8&e=3D=0A=
=0A=
Rob=0A=
=0A=
>=0A=
> The motivation for submodules was that organizations maintaining large=0A=
> modules with multiple people can do so without having to mess around=0A=
> with tools like m4 scripts to produce a single module from 'snippets'=0A=
> and to avoid integration surprises. But perhaps using m4 scripts and=0A=
> decent version control systems (that can integrate and compile on=0A=
> checkin) is indeed cheaper than having submodules part of the YANG=0A=
> language itself.=0A=
>=0A=
> /js=0A=
>=0A=
=0A=
_______________________________________________=0A=
netmod mailing list=0A=
netmod@ietf.org=0A=
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman=
_listinfo_netmod&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3Dp8kyeK3u4ZYiaQ2Z=
PGqwkyXmQgBH6r5jpYiYWzhqJ48&m=3Dl7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7owI=
&s=3Dt7vGIH8ABuAm00e-bkSowD9eawModGq0N2OkjANtpYI&e=3D=0A=
=0A=
_______________________________________________=0A=
netmod mailing list=0A=
netmod@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/netmod=0A=


From nobody Tue Aug 22 22:42:31 2017
Return-Path: 
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 12F5C132334 for ; Tue, 22 Aug 2017 22:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YdSsqMioWgQu for ; Tue, 22 Aug 2017 22:42:27 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B16C1321ED for ; Tue, 22 Aug 2017 22:42:27 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id D886E3C; Wed, 23 Aug 2017 07:42:25 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id mzuqUprNh8Wr; Wed, 23 Aug 2017 07:42:25 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 23 Aug 2017 07:42:25 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 984AB200E2; Wed, 23 Aug 2017 07:42:25 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id z_aDw3TxEdmk; Wed, 23 Aug 2017 07:42:25 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 010BA200E0; Wed, 23 Aug 2017 07:42:24 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id C3927404886A; Wed, 23 Aug 2017 07:42:24 +0200 (CEST)
Date: Wed, 23 Aug 2017 07:42:24 +0200
From: Juergen Schoenwaelder 
To: Marta Seda 
Cc: "netmod@ietf.org" 
Message-ID: <20170823054224.ughywg3atbm3tu5k@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Marta Seda , "netmod@ietf.org" 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] Question/Clarification of ietf-netmod-entity model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 05:42:30 -0000

A logical entity in the ENTITY-MIB boils down to the SNMP parameters
needed to talk to an SNMP agent that provides a context view on say a
bridge. This all was needed because the original bridge MIB module
design was not prepared to expose virtual lans, multiple spanning
trees etc. I assume that YANG data model written for bridges in the
21st century would be able to expose that without requiring contexts
(that do not even exist as a concept in YANG/NETCONF/RESTCONF).
Perhaps the closest are schema mounts.

/js

On Tue, Aug 22, 2017 at 08:28:40PM +0000, Marta Seda wrote:
> RFC6933 Entity MIB contains the following tables:
> 
>      *   entPhysicalContainsTable (this is modeled in ietf-hardware-yang module)
>      *   entLPPhysicalTable (describes the mapping of logical entities and physical components supporting that entity).
> 
> There are some solution spaces that need to support logical entities (e.g., bridges, and other virtual entities).  The draft-ietf-netmod-entity-04 only addresses the entPhysicalContains Table.  Could someone comment as to the reason for the omission of logical entities?  Is this by design  (ietf-netmod-entity is intended only to cover physical components and physical ports)? Or simply that it has not been gotten around to?
> 
> Thank you.
> 
> Regards,
> 
> Marta Seda
> Calix
> 

> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Tue Aug 22 23:17:17 2017
Return-Path: 
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 765CD132332 for ; Tue, 22 Aug 2017 23:17:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 LWlMCnuh9R4Y for ; Tue, 22 Aug 2017 23:17:13 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 952251321ED for ; Tue, 22 Aug 2017 23:17:13 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 6549669; Wed, 23 Aug 2017 08:17:12 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id q1GwyOSocQne; Wed, 23 Aug 2017 08:17:11 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 23 Aug 2017 08:17:12 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 41882200E2; Wed, 23 Aug 2017 08:17:12 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8qpKb-vg4RVs; Wed, 23 Aug 2017 08:17:11 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 09FA2200E3; Wed, 23 Aug 2017 08:17:10 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id A45DC4048B71; Wed, 23 Aug 2017 08:17:09 +0200 (CEST)
Date: Wed, 23 Aug 2017 08:17:09 +0200
From: Juergen Schoenwaelder 
To: Lou Berger 
Cc: Kent Watsen , "netmod@ietf.org" 
Message-ID: <20170823061709.prezywubi7b32w7i@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Lou Berger , Kent Watsen , "netmod@ietf.org" 
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 06:17:16 -0000

My preference is to have the guidelines say what people should do,
namely design NMDA models. I would prefer to keep any transition
aspects out of the guidelines. If people want to include transition
aspects, it should be in the appendix (i.e., easy to remove / ignore
later on).

I understand that there is a timing issue. The question is what you
mean with "NMDA solution makes it to publication (request)". If you
mean the core NMDA document, this is pretty much in reach and keeping
this guidelines document on hold until then may be an option. If you
mean the complete solution set, including model updates and moving the
protocol extensions in NETCONF to publication request, then this may
take a bit more time.

/js

On Tue, Aug 22, 2017 at 04:32:14PM -0400, Lou Berger wrote:
> Kent/WG,
> 
>  This seems a bit terse to me and not provide needed guidance during
> the current transition period. I understood the discussion ended up
> with the options being to either (1) provide the guidance as a
> standalone document, e.g., (a)-(s) in draft-dsdt-nmda-guidelines, with a
> pointer to it from 6087bis or (2) just move those sections to 6087 bis.
> Either way, we'll need a new bis once the full NMDA solution makes it to
> publication (request).
> 
> I thought the plan was to do (s). If so, we need the full text.
> Looking at the current repo
> (https://github.com/netmod-wg/datastore-dt/blob/master/guidelines/guidelines.txt)
> it would be:
> 
>  4.23 Operational Data
> 
>  The following guidelines are meant to help modelers develop
>  YANG models that will maximize the utility of the model with
>  both current implementations and NMDA-capable implementations
>  [draft-ietf-netmod-revised-datastores].
> 
>  (a) New models and models that are not concerned with the
>  operational state of configuration information SHOULD
>  immediately be structured to be NMDA-compatible.
> 
>  (b) Models that require immediate support for "in use" and
>  "system created" information SHOULD be structured for NMDA. A
>  non-NMDA version of these models SHOULD exist, either an
>  existing model or a model created either by hand or with
>  suitable tools that mirror the current modeling strategies.
>  Both the NMDA and the non-NMDA modules SHOULD be published in
>  the same document, with NMDA modules in the document main body
>  and the non-NMDA modules in a non-normative appendix. The use
>  of the non-NMDA model will allow temporary bridging of the
>  time period until NMDA implementations are available.
> 
>  (c) For published models, the model should be republished with
>  an NMDA-compatible structure, deprecating non-NMDA constructs.
>  For example, the "ietf-interfaces" model in ^RFC7223^ will be
>  restructured as an NMDA-compatible model. The
>  "/interfaces-state" hierarchy will be marked "status
>  deprecated". Models that mark their "/foo-state" hierarchy
>  with "status deprecated" will allow NMDA-capable
>  implementations to avoid the cost of duplicating the state
>  nodes, while enabling non-NMDA-capable implementations to
>  utilize them for access to the operational values.
> 
>  (d) For models that augment models which have not been
>  structured with the NMDA, the modeler will have to consider
>  the structure of the base model and the guidelines listed
>  above. Where possible, such models should move to new
>  revisions of the base model that are NMDA-compatible. When
>  that is not possible, augmenting "state" containers SHOULD be
>  avoided, with the expectation that the base model will be
>  re-released with the state containers marked as deprecated.
>  It is RECOMMENDED to augment only the "/foo" hierarchy of the
>  base model. Where this recommendation cannot be followed,
>  then any new "state" elements SHOULD be included in their own
>  module.
> 
>  To create the temporary non-NMDA model from an NMDA model, the
>  following steps can be taken:
> 
>  - Rename the module name by postpending "-state" to the
>  original module's name
>  - Change the namespace by postpending "-state" to the original
>  namespace value
>  - Change the prefix by postpending "-s" to the original prefix
>  value
>  - Set all top-level nodes to have a "config" statement of
>  value "false"
>  - add an import to the original module (e.g., for typedef
>  definitions)
>  - modify any imports, used for leafrefs or identityrefs, to
>  import the -state version of the module
>  - remove any 'typedef' or 'identity' definitions
>  - prefix any uses of the typedefs and identities accordingly
>  - update leafref and augment paths to use the new "-s" prefix
> 
> For me (with any/all hats) the key downside is that we'll need to rev
> this text (again) in the not too distant future, but that we don't have
> an alternative as LC on the full solution is still a bit away.
> 
> What do people think?
> 
> Lou
> 
> 
> On 8/22/2017 3:53 PM, Kent Watsen wrote:
> > Hi,
> >
> > During the meeting in Chicago, the NMDA authors took an action to 
> > propose some text for S4.23.  After a little review, the following
> > emerged.  Yes, it's short, but was anything left anything out?
> >
> >
> > =====START=====
> >
> > 4.23 Operational Data
> >
> > Operational data includes both config "false" nodes as well as,
> > on servers supporting  [draft-ietf-netmod-revised-datastores],
> > the applied value of config "true" nodes.
> >  
> > YANG modules SHOULD be designed assuming they will be used on 
> > servers supporting .  With this in mind, YANG
> > modules SHOULD define config "false" wherever they make sense
> > to the data model.  Config "false" nodes SHOULD NOT be defined
> > to provide the operational value for configuration nodes, 
> > except when the value space of a configured and operational
> > values may differ, in which case a distinct config "false" 
> > node SHOULD be defined to hold the operational value for the
> > configured node.
> >
> > =====STOP=====
> >
> >
> > One question that came up is if "operational data" is a well-defined
> > term.  This string appears 10 times in rfc6087bis.  Most interestingly,
> > appendix Section A.8. (v05 to v06) includes this line item:
> >
> >     Changed term "operational state" to "operational data"
> >
> > So it seems to be deliberate...
> >
> >
> > Kent  // contributor
> >
> >
> >
> > _______________________________________________
> > 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

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Tue Aug 22 23:28:11 2017
Return-Path: 
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 9F2AA132332 for ; Tue, 22 Aug 2017 23:28:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 bLbXngrISyHw for ; Tue, 22 Aug 2017 23:28:07 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 340EB1321ED for ; Tue, 22 Aug 2017 23:28:07 -0700 (PDT)
Received: from localhost (h-40-225.A165.priv.bahnhof.se [94.254.40.225]) by mail.tail-f.com (Postfix) with ESMTPSA id 418DA1AE01AA; Wed, 23 Aug 2017 08:28:06 +0200 (CEST)
Date: Wed, 23 Aug 2017 08:29:06 +0200 (CEST)
Message-Id: <20170823.082906.1853252260651620253.mbj@tail-f.com>
To: lberger@labn.net
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <1aa26e59-6999-8f8a-6cd6-5e74050453bd@labn.net>
References: <20170822.122022.1375224682803846655.mbj@tail-f.com> <1aa26e59-6999-8f8a-6cd6-5e74050453bd@labn.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 06:28:10 -0000

Lou Berger  wrote:
> Hi Martin,
> =

> See below.
> =

> =

> On 8/22/2017 6:20 AM, Martin Bjorklund wrote:
> > Hi,
> >
> > Lada presented an open issue in schema mount in Prague.  (See slide=
 6
> > in
> > https://datatracker.ietf.org/meeting/99/materials/slides-99-netmod-=
sessb-schema-mount)
> >
> > The original problem comes from the NI use case
> > (https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model).  In this
> > use case, interfaces are assigned to NIs by:
> >
> >    augment /if:interfaces/if:interface:
> >      +--rw bind-ni-name?   -> /network-instances/network-instance/n=
ame
> >
> > Modules that are mounted within the NI might have references to
> > interfaces.  The idea is that a specific NI can only reference the
> > interfaces that has been assigned to it.
> >
> > In schema mount, we have the "parent-reference" XPath expression th=
at
> > in this case will be "/if:interfaces/if:interface".  The problem is=

> > that this XPath expression will evaluate to a node set that contain=
s
> > *all* interfaces in the system.  We would like this to contain just=

> > the interfaces assigned to the NI.
> >
> > It turns out that this can be done with a simple change to the
> > "parent-reference" node.  If we state that this XPath expression is=

> > evaluated in an XPath context where the context node is the node in=

> > the data tree where the mount point is defined (instead of "/"), we=

> > can use as parent-reference:
> >
> >   /if:interfaces/if:interface[ni:bind-network-instance-name =3D ../=
ni:name]
> >
> > Putting this together we'd have:
> >
> >   augment "/if:interfaces/if:interface" {
> >     leaf bind-ni-name {
> >       type leafref {
> >         path "/network-instances/network-instance/name";
> >       }
> >     }
> >   }
> >
> >   container network-instances {
> >     list network-instance {
> >       key name;
> >       leaf name { ... }
> >       ...
> >       container root {
> >         // this would be the XPath context root for parent-referenc=
e
> >         yangmnt:mount-point ni-root;
> >       }
> >     }
> >   }
> =

> note that the current NI definition is:

Yes I saw that.

>    module: ietf-network-instance
>      +--rw network-instances
>         +--rw network-instance* [name]
>            +--rw name           string
>            +--rw enabled?       boolean
>            +--rw description?   string
>            +--rw (ni-type)?
>            +--rw (root-type)?
>               +--:(vrf-root)
>               |  +--mp vrf-root?
>               +--:(vsi-root)
>               |  +--mp vsi-root?
>               +--:(vv-root)
>                  +--mp vv-root?

Note that the extension yangmnt:mount-point can only be present in a
container or list, not in a choice/case.

But what is the point of a choice with three different mount points?

>    augment /if:interfaces/if:interface:
>      +--rw bind-ni-name?   -> /network-instances/network-instance/nam=
e
>    augment /if:interfaces/if:interface/ip:ipv4:
>      +--rw bind-ni-name?   -> /network-instances/network-instance/nam=
e
>    augment /if:interfaces/if:interface/ip:ipv6:
>      +--rw bind-ni-name?   -> /network-instances/network-instance/nam=
e
> =

> > And in state data:
> >
> >
> > "ietf-yang-schema-mount:schema-mounts": {
> >   "namespace": [
> >     {
> >       "prefix": "ni",
> >       "uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
> >     },
> >     {
> >       "prefix": "if",
> >       "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
> >     }
> >   ]
> >   "mount-point": [
> >     {
> >       "target": "/ni:network-instances/ni:network-instance/ni:root"=
,
> Can you confirm that with the current definition the target is:
> =

>       "target": "/ni:network-instances/ni:network-instance",
> =

> correct?

See above; the current definition is invalid.

> >       "parent-reference": [
> >             "/if:interfaces/if:interface
> >              [ni:bind-network-instance-name =3D ../ni:name]"

Correction.  This should be:

            "/if:interfaces/if:interface
             [ni:bind-network-instance-name =3D current()/../ni:name]"

> >                           ],
> Also, can you confirm that if we wanted to cover v4, v6 (for example
> purposes) interfaces-state, the full parent reference list would be:
> =

>       "parent-reference": [
>             "/if:interfaces/if:interface
>              [ni:bind-ni-name =3D ./ni:name]",
>             "/if:interfaces/if:interface/ip:ipv4
>              [ni:bind-ni-name =3D ./ni:name]",
>             "/if:interfaces/if:interface/ip:ipv6
>              [ni:bind-ni-name =3D ./ni:name]",
>              "/if:interfaces-state/if:interface"
> =

> =A0correct?

No it would be:

  /if:interfaces-state/if:interface[
    if:name =3D /if:interfaces/if:interface[
      ni:bind-ni-name =3D current()/../ni:name]/if:name]

etc.

I.e., the interfaces in -state that that has the same names as the
interfaces in config that has the correct bind-ni-name.
   =


> Note that interfaces-state isn't filtered as the bind-ni-name isn't
> present in -state.
> =

> >       "use-schema": [
> >         {
> >           "name": "ni-schema"
> >         }
> >       ]
> >     }
> >   ]
> >
> >
> >
> > Note that this does NOT affect the schema that is mounted; it only
> > affects the result of the parent-reference XPath expressions.
> >
> >
> > I think that we should make this change, since it allows for more
> > precise parent-references.
> I'm okay with the change (just want to see the draft moved forward ;-=
)
> =

> Lou
> (As contributor)



/martin


From nobody Wed Aug 23 00:09:45 2017
Return-Path: 
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 01937132B01 for ; Wed, 23 Aug 2017 00:09:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level: 
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 dkJNLkYRQlbo for ; Wed, 23 Aug 2017 00:09:41 -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 BA8A7132B00 for ; Wed, 23 Aug 2017 00:09:41 -0700 (PDT)
Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id v7N754tQ006497; Wed, 23 Aug 2017 03:09:37 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 2ch4w7gedt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Aug 2017 03:09:37 -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 v7N79aVP008013; Wed, 23 Aug 2017 03:09:36 -0400
Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7N79Lmf007908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 23 Aug 2017 03:09:31 -0400
Received: from gbcdccas01.intl.att.com (gbcdccas01.intl.att.com [135.76.180.9]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 23 Aug 2017 07:09:14 GMT
Received: from GBCDCMBX03.intl.att.com ([135.76.31.134]) by gbcdccas01.intl.att.com ([135.76.180.9]) with mapi id 14.03.0361.001; Wed, 23 Aug 2017 08:09:13 +0100
From: "Ivory, William" 
To: "'Alex Campbell'" , "'Robert Wilton'" , "'netmod@ietf.org'" 
Thread-Topic: [netmod] Query about augmenting module from submodule in YANG 1.0
Thread-Index: AdMMOPUClm48yMKSSEeEurX4RbXaiADP5++AAAR9DaAACC3kAAAcrpQgAD0R+IAAAWwvgAAAa7wAAlFjp4AACPgnkABCnQKAABQ6ExA=
Date: Wed, 23 Aug 2017 07:08:10 +0000
Deferred-Delivery: Wed, 23 Aug 2017 07:09:10 +0000
Message-ID: 
References:  <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com>  <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com>   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>,  <1503440878003.28215@Aviatnet.com>
In-Reply-To: <1503440878003.28215@Aviatnet.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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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-23_01:, , 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-1707230000 definitions=main-1708230105
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 07:09:44 -0000

...  except that if the whole reason for splitting into submodules was to a=
llow the submodules to belong to different packages in our system, combinin=
g them back again is not possible.  I wouldn't be splitting them unless I n=
eeded to for good reason.

William

-----Original Message-----
From: Alex Campbell [mailto:Alex.Campbell@Aviatnet.com]=20
Sent: 22 August 2017 23:28
To: Ivory, William ; 'Robert Wilton' ; 'netmod@ietf.org' 
Subject: Re: [netmod] Query about augmenting module from submodule in YANG =
1.0

Hi,

I'm not Rob, but my understanding is that if a module author wanted to migr=
ate to YANG 2.0, they could merge their submodules back into the main modul=
e - which is not a difficult procedure and does not break compatibility wit=
h clients.

Alex
________________________________________
From: netmod  on behalf of Ivory, William 
Sent: Tuesday, 22 August 2017 1:44 a.m.
To: 'Robert Wilton'; 'netmod@ietf.org'
Subject: Re: [netmod] Query about augmenting module from submodule in YANG =
1.0

Hi Rob,

That would make it very hard to update existing 1.x YANG models to use new =
features in YANG 2.x if they used submodules.  Maybe that's something that =
no one would ever consider doing anyway, or maybe YANG 1.1 already has simi=
lar differences to 1.0?  I had (perhaps naively) assumed that you could mig=
rate a namespace / model from YANG 1.0 to 2.0?

Regards,

William

-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton
Sent: 21 August 2017 11:24
To: netmod@ietf.org
Subject: Re: [netmod] Query about augmenting module from submodule in YANG =
1.0



On 09/08/2017 16:13, Juergen Schoenwaelder wrote:
> On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka wrote:
>> I remember that in early stages of YANG there was some irrational=20
>> fear of introducing too many namespaces, and submodules may be a=20
>> consequence of it. As you write, submodules provide no benefits=20
>> whatsoever in terms of modularity, but the overhead in terms of=20
>> metadata, IANA registration etc. is pretty much the same as for=20
>> modules.
> In case YANG 2.0 is ever done, I suggest someone files a proposal to=20
> remove submodules if the cost/benefit ratio is at odds. There is=20
> nothing wrong with removing stuff that has been found problematic.
I agree.

I've added https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.co=
m_netmod-2Dwg_yang-2Dnext_issues_26&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=
=3Dp8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=3Dl7c4IPL049A2bVVO14fyBMly=
211xU61xSHgPlAT7owI&s=3D-kR4fUtXArQy0RwWb32DpT1bP4X_cNqt2zJVoC0JiX8&e=3D

Rob

>
> The motivation for submodules was that organizations maintaining large=20
> modules with multiple people can do so without having to mess around=20
> with tools like m4 scripts to produce a single module from 'snippets'
> and to avoid integration surprises. But perhaps using m4 scripts and=20
> decent version control systems (that can integrate and compile on
> checkin) is indeed cheaper than having submodules part of the YANG=20
> language itself.
>
> /js
>

_______________________________________________
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman=
_listinfo_netmod&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3Dp8kyeK3u4ZYiaQ2Z=
PGqwkyXmQgBH6r5jpYiYWzhqJ48&m=3Dl7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7owI=
&s=3Dt7vGIH8ABuAm00e-bkSowD9eawModGq0N2OkjANtpYI&e=3D

_______________________________________________
netmod mailing list
netmod@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman=
_listinfo_netmod&d=3DDwIFAw&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3Dp8kyeK3u4ZYiaQ2Z=
PGqwkyXmQgBH6r5jpYiYWzhqJ48&m=3Desi8GPSc1xVjTt9SKxqzNHRDXT2P1h01a-UebnST-Yo=
&s=3DPctKy3ij6W0TQs1NFp18SX8MQtYKeG9RxADh3cphcxU&e=3D=20


From nobody Wed Aug 23 00:24:46 2017
Return-Path: 
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 8B3F11321A0 for ; Wed, 23 Aug 2017 00:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MrMR-b-Fh5og for ; Wed, 23 Aug 2017 00:24:42 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA6CB132BC2 for ; Wed, 23 Aug 2017 00:24:37 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id B0FF299; Wed, 23 Aug 2017 09:24:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id MEXHJAZM4Iek; Wed, 23 Aug 2017 09:24:36 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 23 Aug 2017 09:24:36 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F8A5200E2; Wed, 23 Aug 2017 09:24:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gnc4PrWNuUG3; Wed, 23 Aug 2017 09:24:35 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9BB8E200E0; Wed, 23 Aug 2017 09:24:35 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 856BE4048DCB; Wed, 23 Aug 2017 09:24:35 +0200 (CEST)
Date: Wed, 23 Aug 2017 09:24:35 +0200
From: Juergen Schoenwaelder 
To: "Ivory, William" 
Cc: 'Alex Campbell' , 'Robert Wilton' , "'netmod@ietf.org'" 
Message-ID: <20170823072435.wv7pvndrm5du5q3x@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: "Ivory, William" , 'Alex Campbell' , 'Robert Wilton' , "'netmod@ietf.org'" 
References:  <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com>   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>  <1503440878003.28215@Aviatnet.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 07:24:44 -0000

What are packages? I think submodules declare to which module they
belong, no? Perhaps you are doing something that submodules do not
even support.

/js

On Wed, Aug 23, 2017 at 07:08:10AM +0000, Ivory, William wrote:
> ...  except that if the whole reason for splitting into submodules was to allow the submodules to belong to different packages in our system, combining them back again is not possible.  I wouldn't be splitting them unless I needed to for good reason.
> 
> William
> 
> -----Original Message-----
> From: Alex Campbell [mailto:Alex.Campbell@Aviatnet.com] 
> Sent: 22 August 2017 23:28
> To: Ivory, William ; 'Robert Wilton' ; 'netmod@ietf.org' 
> Subject: Re: [netmod] Query about augmenting module from submodule in YANG 1.0
> 
> Hi,
> 
> I'm not Rob, but my understanding is that if a module author wanted to migrate to YANG 2.0, they could merge their submodules back into the main module - which is not a difficult procedure and does not break compatibility with clients.
> 
> Alex
> ________________________________________
> From: netmod  on behalf of Ivory, William 
> Sent: Tuesday, 22 August 2017 1:44 a.m.
> To: 'Robert Wilton'; 'netmod@ietf.org'
> Subject: Re: [netmod] Query about augmenting module from submodule in YANG 1.0
> 
> Hi Rob,
> 
> That would make it very hard to update existing 1.x YANG models to use new features in YANG 2.x if they used submodules.  Maybe that's something that no one would ever consider doing anyway, or maybe YANG 1.1 already has similar differences to 1.0?  I had (perhaps naively) assumed that you could migrate a namespace / model from YANG 1.0 to 2.0?
> 
> Regards,
> 
> William
> 
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert Wilton
> Sent: 21 August 2017 11:24
> To: netmod@ietf.org
> Subject: Re: [netmod] Query about augmenting module from submodule in YANG 1.0
> 
> 
> 
> On 09/08/2017 16:13, Juergen Schoenwaelder wrote:
> > On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka wrote:
> >> I remember that in early stages of YANG there was some irrational 
> >> fear of introducing too many namespaces, and submodules may be a 
> >> consequence of it. As you write, submodules provide no benefits 
> >> whatsoever in terms of modularity, but the overhead in terms of 
> >> metadata, IANA registration etc. is pretty much the same as for 
> >> modules.
> > In case YANG 2.0 is ever done, I suggest someone files a proposal to 
> > remove submodules if the cost/benefit ratio is at odds. There is 
> > nothing wrong with removing stuff that has been found problematic.
> I agree.
> 
> I've added https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmod-2Dwg_yang-2Dnext_issues_26&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7owI&s=-kR4fUtXArQy0RwWb32DpT1bP4X_cNqt2zJVoC0JiX8&e=
> 
> Rob
> 
> >
> > The motivation for submodules was that organizations maintaining large 
> > modules with multiple people can do so without having to mess around 
> > with tools like m4 scripts to produce a single module from 'snippets'
> > and to avoid integration surprises. But perhaps using m4 scripts and 
> > decent version control systems (that can integrate and compile on
> > checkin) is indeed cheaper than having submodules part of the YANG 
> > language itself.
> >
> > /js
> >
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7owI&s=t7vGIH8ABuAm00e-bkSowD9eawModGq0N2OkjANtpYI&e=
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=esi8GPSc1xVjTt9SKxqzNHRDXT2P1h01a-UebnST-Yo&s=PctKy3ij6W0TQs1NFp18SX8MQtYKeG9RxADh3cphcxU&e= 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Aug 23 01:25:59 2017
Return-Path: 
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 DF601132195 for ; Wed, 23 Aug 2017 01:25:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level: 
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-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 JQBhyZ9tUitJ for ; Wed, 23 Aug 2017 01:25:56 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 26DFE132A0F for ; Wed, 23 Aug 2017 01:25:56 -0700 (PDT)
Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id v7N8P9N1035540; Wed, 23 Aug 2017 04:25:52 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049287.ppops.net-00191d01. with ESMTP id 2ch4vntmwt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Aug 2017 04:25:52 -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 v7N8Pprq009926; Wed, 23 Aug 2017 04:25:51 -0400
Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7N8PfVx009864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 23 Aug 2017 04:25:46 -0400
Received: from gbcdccas01.intl.att.com (gbcdccas01.intl.att.com [135.76.180.9]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 23 Aug 2017 08:25:33 GMT
Received: from GBCDCMBX03.intl.att.com ([135.76.31.134]) by gbcdccas01.intl.att.com ([135.76.180.9]) with mapi id 14.03.0361.001; Wed, 23 Aug 2017 09:25:31 +0100
From: "Ivory, William" 
To: "'Juergen Schoenwaelder'" 
CC: "'Alex Campbell'" , "'Robert Wilton'" , "'netmod@ietf.org'" 
Thread-Topic: [netmod] Query about augmenting module from submodule in YANG 1.0
Thread-Index: AdMMOPUClm48yMKSSEeEurX4RbXaiADP5++AAAR9DaAACC3kAAAcrpQgAD0R+IAAAWwvgAAAa7wAAlFjp4AACPgnkABCnQKAABQ6ExD///QegP//4ixw
Date: Wed, 23 Aug 2017 08:24:29 +0000
Deferred-Delivery: Wed, 23 Aug 2017 08:25:29 +0000
Message-ID: 
References:  <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com>   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>  <1503440878003.28215@Aviatnet.com>  <20170823072435.wv7pvndrm5du5q3x@elstar.local>
In-Reply-To: <20170823072435.wv7pvndrm5du5q3x@elstar.local>
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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-23_02:, , 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-1707230000 definitions=main-1708230125
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 08:25:58 -0000

Sorry - meant Debian packages.  We have a large YANG module that really oug=
ht to be handled by multiple daemons, so plan to use submodules so we can i=
dentify the different parts and process them in the right place.  Recombini=
ng into a single module would lose that granularity.

William

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20
Sent: 23 August 2017 08:25
To: Ivory, William 
Cc: 'Alex Campbell' ; 'Robert Wilton' ; 'netmod@ietf.org' 
Subject: Re: [netmod] Query about augmenting module from submodule in YANG =
1.0

What are packages? I think submodules declare to which module they belong, =
no? Perhaps you are doing something that submodules do not even support.

/js

On Wed, Aug 23, 2017 at 07:08:10AM +0000, Ivory, William wrote:
> ...  except that if the whole reason for splitting into submodules was to=
 allow the submodules to belong to different packages in our system, combin=
ing them back again is not possible.  I wouldn't be splitting them unless I=
 needed to for good reason.
>=20
> William
>=20
> -----Original Message-----
> From: Alex Campbell [mailto:Alex.Campbell@Aviatnet.com]
> Sent: 22 August 2017 23:28
> To: Ivory, William ; 'Robert Wilton'=20
> ; 'netmod@ietf.org' 
> Subject: Re: [netmod] Query about augmenting module from submodule in=20
> YANG 1.0
>=20
> Hi,
>=20
> I'm not Rob, but my understanding is that if a module author wanted to mi=
grate to YANG 2.0, they could merge their submodules back into the main mod=
ule - which is not a difficult procedure and does not break compatibility w=
ith clients.
>=20
> Alex
> ________________________________________
> From: netmod  on behalf of Ivory, William=20
> 
> Sent: Tuesday, 22 August 2017 1:44 a.m.
> To: 'Robert Wilton'; 'netmod@ietf.org'
> Subject: Re: [netmod] Query about augmenting module from submodule in=20
> YANG 1.0
>=20
> Hi Rob,
>=20
> That would make it very hard to update existing 1.x YANG models to use ne=
w features in YANG 2.x if they used submodules.  Maybe that's something tha=
t no one would ever consider doing anyway, or maybe YANG 1.1 already has si=
milar differences to 1.0?  I had (perhaps naively) assumed that you could m=
igrate a namespace / model from YANG 1.0 to 2.0?
>=20
> Regards,
>=20
> William
>=20
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert=20
> Wilton
> Sent: 21 August 2017 11:24
> To: netmod@ietf.org
> Subject: Re: [netmod] Query about augmenting module from submodule in=20
> YANG 1.0
>=20
>=20
>=20
> On 09/08/2017 16:13, Juergen Schoenwaelder wrote:
> > On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka wrote:
> >> I remember that in early stages of YANG there was some irrational=20
> >> fear of introducing too many namespaces, and submodules may be a=20
> >> consequence of it. As you write, submodules provide no benefits=20
> >> whatsoever in terms of modularity, but the overhead in terms of=20
> >> metadata, IANA registration etc. is pretty much the same as for=20
> >> modules.
> > In case YANG 2.0 is ever done, I suggest someone files a proposal to=20
> > remove submodules if the cost/benefit ratio is at odds. There is=20
> > nothing wrong with removing stuff that has been found problematic.
> I agree.
>=20
> I've added=20
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_netmod
> -2Dwg_yang-2Dnext_issues_26&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3Dp8k=
yeK
> 3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=3Dl7c4IPL049A2bVVO14fyBMly211xU6
> 1xSHgPlAT7owI&s=3D-kR4fUtXArQy0RwWb32DpT1bP4X_cNqt2zJVoC0JiX8&e=3D
>=20
> Rob
>=20
> >
> > The motivation for submodules was that organizations maintaining=20
> > large modules with multiple people can do so without having to mess=20
> > around with tools like m4 scripts to produce a single module from 'snip=
pets'
> > and to avoid integration surprises. But perhaps using m4 scripts and=20
> > decent version control systems (that can integrate and compile on
> > checkin) is indeed cheaper than having submodules part of the YANG=20
> > language itself.
> >
> > /js
> >
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail
> man_listinfo_netmod&d=3DDwICAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3Dp8kyeK3u4ZY=
iaQ
> 2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=3Dl7c4IPL049A2bVVO14fyBMly211xU61xSHgPlA
> T7owI&s=3Dt7vGIH8ABuAm00e-bkSowD9eawModGq0N2OkjANtpYI&e=3D
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail
> man_listinfo_netmod&d=3DDwIFAw&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3Dp8kyeK3u4ZY=
iaQ
> 2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=3Desi8GPSc1xVjTt9SKxqzNHRDXT2P1h01a-Uebn
> ST-Yo&s=3DPctKy3ij6W0TQs1NFp18SX8MQtYKeG9RxADh3cphcxU&e=3D
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail
> man_listinfo_netmod&d=3DDwIBAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3Dp8kyeK3u4ZY=
iaQ
> 2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=3DRH3zvD2B8_s4uw1PXm_ka37vgz9_q2Rc87tD8K
> fZ9jA&s=3DXydU0vXE0AEg2FDE-kx_Ae6rOOAh5koxEeJ2cefgDNA&e=3D

--=20
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Aug 23 02:46:26 2017
Return-Path: 
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 DA375132742 for ; Wed, 23 Aug 2017 02:46:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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
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 Nt5k0aUQoP1h for ; Wed, 23 Aug 2017 02:46:21 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82D27132BDC for ; Wed, 23 Aug 2017 02:46:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6381; q=dns/txt; s=iport; t=1503481580; x=1504691180; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=amd34gwLhw6cbUM9N2hbeIClyKkAHlCqze0f7IS+l5U=; b=ikiSFH/V8HtK68UyRS7Q9jW23qQGpAusxQvq0RseK5FK4hXEQiNChKPj mlrRKY9LPq4Dw4Yhc25SY5WmiSAqq1aM1YUXGyPyzwcIxJ7+ln1hWywxu ZkUkZ7i8IoDxW1Kthzrc6s2wUm+XJ9cpSQVVwTCK/D5JsLb1EnTg/IARj w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAQDATZ1Z/xbLJq1SChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ+gRWPCJEWmDYshRsChHsUAQIBAQEBAQEBayiFGAEBAQECASM?= =?us-ascii?q?VNgYFDAQLEAEEAQEBAgIjAwICRgkIBgEMBgIBAReKDggQrjWCJotvAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBGAWBDYIdg06BYyuCfIMmgSIrgxOCYQWgWIdWjG6CEok?= =?us-ascii?q?8hxaJb4NPiHA2IYEKMiEIHBVJhxs/NgEBin8BAQE?=
X-IronPort-AV: E=Sophos;i="5.41,416,1498521600"; d="scan'208";a="696701190"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Aug 2017 09:46:16 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7N9kFiN001075; Wed, 23 Aug 2017 09:46:16 GMT
To: "Ivory, William" , "'Juergen Schoenwaelder'" 
Cc: "'Alex Campbell'" , "'netmod@ietf.org'" 
References:  <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com>   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>  <1503440878003.28215@Aviatnet.com>  <20170823072435.wv7pvndrm5du5q3x@elstar.local> 
From: Robert Wilton 
Message-ID: 
Date: Wed, 23 Aug 2017 10:46:15 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 09:46:25 -0000

Hi William,

I think that there might be some downsides to your proposed solution of 
using submodules - which you may have already considered:

1) All of the debian packages will have to be installed together to 
allow the YANG module to be built, or otherwise there will be missing 
submodules, and the module will fail to compile (since the top level 
module must list all included sub-modules).
2) It might end up with your requiring tight versioning of all of your 
debian packages together with the same version number, or otherwise you 
may need greater care over how the sub-modules are updated and 
dependencies are handled.

If your YANG was being designed from scratch then using separate YANG 
modules may allow for a cleaner solution - but I appreciate that may not 
help you with where you are now.

Thanks,
Rob


On 23/08/2017 09:24, Ivory, William wrote:
> Sorry - meant Debian packages.  We have a large YANG module that really ought to be handled by multiple daemons, so plan to use submodules so we can identify the different parts and process them in the right place.  Recombining into a single module would lose that granularity.
>
> William
>
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
> Sent: 23 August 2017 08:25
> To: Ivory, William 
> Cc: 'Alex Campbell' ; 'Robert Wilton' ; 'netmod@ietf.org' 
> Subject: Re: [netmod] Query about augmenting module from submodule in YANG 1.0
>
> What are packages? I think submodules declare to which module they belong, no? Perhaps you are doing something that submodules do not even support.
>
> /js
>
> On Wed, Aug 23, 2017 at 07:08:10AM +0000, Ivory, William wrote:
>> ...  except that if the whole reason for splitting into submodules was to allow the submodules to belong to different packages in our system, combining them back again is not possible.  I wouldn't be splitting them unless I needed to for good reason.
>>
>> William
>>
>> -----Original Message-----
>> From: Alex Campbell [mailto:Alex.Campbell@Aviatnet.com]
>> Sent: 22 August 2017 23:28
>> To: Ivory, William ; 'Robert Wilton'
>> ; 'netmod@ietf.org' 
>> Subject: Re: [netmod] Query about augmenting module from submodule in
>> YANG 1.0
>>
>> Hi,
>>
>> I'm not Rob, but my understanding is that if a module author wanted to migrate to YANG 2.0, they could merge their submodules back into the main module - which is not a difficult procedure and does not break compatibility with clients.
>>
>> Alex
>> ________________________________________
>> From: netmod  on behalf of Ivory, William
>> 
>> Sent: Tuesday, 22 August 2017 1:44 a.m.
>> To: 'Robert Wilton'; 'netmod@ietf.org'
>> Subject: Re: [netmod] Query about augmenting module from submodule in
>> YANG 1.0
>>
>> Hi Rob,
>>
>> That would make it very hard to update existing 1.x YANG models to use new features in YANG 2.x if they used submodules.  Maybe that's something that no one would ever consider doing anyway, or maybe YANG 1.1 already has similar differences to 1.0?  I had (perhaps naively) assumed that you could migrate a namespace / model from YANG 1.0 to 2.0?
>>
>> Regards,
>>
>> William
>>
>> -----Original Message-----
>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert
>> Wilton
>> Sent: 21 August 2017 11:24
>> To: netmod@ietf.org
>> Subject: Re: [netmod] Query about augmenting module from submodule in
>> YANG 1.0
>>
>>
>>
>> On 09/08/2017 16:13, Juergen Schoenwaelder wrote:
>>> On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka wrote:
>>>> I remember that in early stages of YANG there was some irrational
>>>> fear of introducing too many namespaces, and submodules may be a
>>>> consequence of it. As you write, submodules provide no benefits
>>>> whatsoever in terms of modularity, but the overhead in terms of
>>>> metadata, IANA registration etc. is pretty much the same as for
>>>> modules.
>>> In case YANG 2.0 is ever done, I suggest someone files a proposal to
>>> remove submodules if the cost/benefit ratio is at odds. There is
>>> nothing wrong with removing stuff that has been found problematic.
>> I agree.
>>
>> I've added
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmod
>> -2Dwg_yang-2Dnext_issues_26&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK
>> 3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU6
>> 1xSHgPlAT7owI&s=-kR4fUtXArQy0RwWb32DpT1bP4X_cNqt2zJVoC0JiX8&e=
>>
>> Rob
>>
>>> The motivation for submodules was that organizations maintaining
>>> large modules with multiple people can do so without having to mess
>>> around with tools like m4 scripts to produce a single module from 'snippets'
>>> and to avoid integration surprises. But perhaps using m4 scripts and
>>> decent version control systems (that can integrate and compile on
>>> checkin) is indeed cheaper than having submodules part of the YANG
>>> language itself.
>>>
>>> /js
>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
>> man_listinfo_netmod&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ
>> 2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlA
>> T7owI&s=t7vGIH8ABuAm00e-bkSowD9eawModGq0N2OkjANtpYI&e=
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
>> man_listinfo_netmod&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ
>> 2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=esi8GPSc1xVjTt9SKxqzNHRDXT2P1h01a-Uebn
>> ST-Yo&s=PctKy3ij6W0TQs1NFp18SX8MQtYKeG9RxADh3cphcxU&e=
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
>> man_listinfo_netmod&d=DwIBAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ
>> 2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=RH3zvD2B8_s4uw1PXm_ka37vgz9_q2Rc87tD8K
>> fZ9jA&s=XydU0vXE0AEg2FDE-kx_Ae6rOOAh5koxEeJ2cefgDNA&e=


From nobody Wed Aug 23 02:48:41 2017
Return-Path: 
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 73898132BEA for ; Wed, 23 Aug 2017 02:48:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
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 UqFXTJMgul7l for ; Wed, 23 Aug 2017 02:48:32 -0700 (PDT)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00118.outbound.protection.outlook.com [40.107.0.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57FAC132BE2 for ; Wed, 23 Aug 2017 02:48:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rddC/xXi6EQeDsVOoRs+unICGwvoMDytUNdBuI5Rgfk=; b=eTvPZerIqMuIQVw/ZZTwb1vyvdsnbERN+6+fDctBW2SJ8vnFrq/1UpWwH82zYODG1WWerAo0RwwRof6IBgUBsJGQDGsMQVxumqhmoAH2QOoSft2COjBl0mBlFE9Xb0XWs0+yzxfGZptr/CMpihOudemKgEOfwY6lvir31tiRlB0=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (86.174.236.116) by DB6PR0701MB3000.eurprd07.prod.outlook.com (2603:10a6:4:73::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1385.4; Wed, 23 Aug 2017 09:48:27 +0000
Message-ID: <044b01d31bf4$d3b37500$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Acee Lindem \(acee\)" , "Ivory, William" , , "Andy Bierman" , "Robert Wilton" 
References:  <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com>  <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com>   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>   <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com>
Date: Wed, 23 Aug 2017 10:45:51 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.174.236.116]
X-ClientProxiedBy: VI1PR0801CA0081.eurprd08.prod.outlook.com (2603:10a6:800:7d::25) To DB6PR0701MB3000.eurprd07.prod.outlook.com (2603:10a6:4:73::10)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: ad69ee3c-46a1-48fb-0c36-08d4ea0c1b6b
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB6PR0701MB3000; 
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 3:LPrQ0Rbuqk7XFHRb6DebkxhAf0rhOnmS1iHyu7RgkNc2AwcGSUSggyv6jp4B/uWjEBLexgYzeoaJ2unDzRdRJlJPPphO90ATNiotYTYTOk8dSfEt3FAaXGMDuRuAILsM40YXiXQSyWAhOO60S/krmZYAKQL3zYpwvRciKPttXKLWyxxsCs9yPpZLQA0txySV56ayCdWrDnEw6STU107eKTUlcjPZIpmFQ2GsRsRCFq3vUe9NzQdn37s8geJzbudX; 25:QWZkNn9O2b4mSjxMrFf0VBGgi7RfkDnLOzAIbyj4qSMna7b5M+yXynDS0QrEEQj3NDI10ERfUl1nzQsmMDabvUuV526HqnPNGrejLbUbnBnhLl6IALny/Gjx+IkeRBxoXUJJj7ohqY4TnBRGsUe+btLMnEWBAlZwWNyXceckxys+4Z2COvFuwjyMoPRv34EW54W/PZhNGDR3k5YA5pg/zaipxBYpp2eccUJC24sOh9a/1LR4/OLT91pQ8bnq+CJ4m02OsB43MP8kZXdX501WJZ7pboz8InXKzXTxR3ELJWs9FVOKuqAsphX4MlcIzjecBlMS4+dgCrkwoAUUCK3IyA==; 31:TafvVvagculAXg4RAb95HuWf76Iiv+Y5lSaMe7Pn6X+E9QRBzYhw61QN9NL7zPGYE7FMhhIVDkiEZ3apdRfMshK4MQpG91JsCPzu6AYq7A+1MOrPHDxXQ9VYCZlsFrfofjP4lEt9mdno8c2c2VZhfxS3rocV1s8E8BaK466u7/O+CipRckL5xd72r7X0PZwRLsdv8P2VI0T1Zz1Aa6vONkQwJ3OsjQQxH9DfApYDkFw=
X-MS-TrafficTypeDiagnostic: DB6PR0701MB3000:
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 20:EdXU0i3xmN1FrC2ZPvxvb0FHZ98aO4iaxYdw6PhEahq3OQHbjzwDUk2+SFbPiUqYiYdY4XwWsvubFV1EaPHZEY+ypcb264WEqh4in9W08S9+ziZf1IJ4LwoZMyuP8ftDusaCU2jn1MqeYUigGe75G8d1GIJrco29GK9gSRSCkLCo3qgsMt/bIpcYmjH49BmF7h7ZqielcCKLP05Fkn0rNcP2pTBQWOrLCyUaeD9c95lu6H3EXub+85t0YLLCQRla; 4:RDtjW51yzv4fJ3zu90z3hYDEqqE9iDNUvkwoOkfmPqjL4zHS2Oiersw1LHanAaTi65l8NUQo/ZiqtIQcU4Uxa9evlORDRMnB0o1/S2tb/Ci3jJKWbEMMb768683fX5jfOLgQiT4ZA3cmHmM0ZWnyNc0GQuBDNnEXXho81RZujIaWNICOvx2lHE0mn06VgRSJNH4UvtWG6PSZdBqq1jqaQ2AdkTGV0iupCJs8jAN92uclT9SvyYvlrxDLHAu86busNdazzpK5MOzOHxTIAxXOMFiLyzNlYviGCuRsqggrIYhuGHtwsgW0lMhFz4i8Lzh7yJgfwXUDktJyCBcauAJ+dEBsMPcIkuGz851O3etESdY=
X-Exchange-Antispam-Report-Test: UriScan:(10436049006162)(97927398514766)(95692535739014); 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0701MB3000; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0701MB3000; 
X-Forefront-PRVS: 040866B734
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(7370300001)(4630300001)(6009001)(39860400002)(24454002)(52314003)(51444003)(377454003)(13464003)(199003)(189002)(7350300001)(478600001)(5660300001)(33646002)(14496001)(6306002)(53936002)(9686003)(61296003)(42186005)(6496005)(25786009)(105586002)(106356001)(6246003)(47776003)(50466002)(230700001)(53546010)(1556002)(86362001)(6666003)(575784001)(4720700003)(1456003)(6116002)(3846002)(44736005)(116806002)(62236002)(66066001)(6486002)(81686999)(189998001)(81816999)(561944003)(44716002)(81156014)(81166006)(93886005)(2906002)(84392002)(50226002)(8676002)(101416001)(68736007)(7736002)(966005)(305945005)(97736004)(76176999)(50986999)(229853002)(23676002)(74416001)(7726001)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB3000; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA3MDFNQjMwMDA7MjM6V3dUYkNlM2lUMm5rQWlDb3pVUkFHeXA0?= =?utf-8?B?WWZvTHhQdFpkdFVTUExPM2dqL1ZxNEtpN0x1OW1sUE9ZSGszL2FLQ2l5dXBH?= =?utf-8?B?VjVvRkVQSUdiZmVycHJLQU1JSEFNcFBobFlkSWhmTHB6K1NFeEV4ZEE0TTdi?= =?utf-8?B?OEJOY3NXdHlNQmRySUxiS3dMYW56OEw0eUlYYXpGakFvMktmR3M4eE1IVXlD?= =?utf-8?B?WG1JSTZGaFprWkVhK28xc3pYOW5tTWZsVi9kYXJqWCtNOXNYWk42eCtOWE1r?= =?utf-8?B?b3c0ZGNDc3lLTXFJTy9SQjlVcFlIbmp0VTQ4K2lLN1I5N3EwbnJTNUg0akpn?= =?utf-8?B?b2VneitQYXNzNU44NW5VYVh5VEFoU2I0ZUhSSk1NRVVmTGw3Y1NQQThoa2FO?= =?utf-8?B?SndPcW9YTmdIVnpGZk9SZmNlR1B2c2lqY0ZKdG0xUzVkQW9meUFmcm5KUmpH?= =?utf-8?B?bzJsM2lOSzdwOGtER1ppSGN0ZmNzS04xWmhrSVc4a2tGNm5kU3M5aXhEcldV?= =?utf-8?B?NVovQ2tpdkd3OGhDd0RUazJON1EybW1RZmJYdVM0dXJHdmU1L0Z1NUZ5TnNU?= =?utf-8?B?eTc2MWxjWVZLQVNzanQ0U094Zi9oMTMvQkE1V2dlZEh5dnhLRGptdFlwOGxY?= =?utf-8?B?bElodERaUnVPbzgxcGR0eVdHcU9tWUdMRUlmK0Y4bnVPRHpqcG5qUGZSL2Fi?= =?utf-8?B?d2ZsLys4Q1pzTDJ4S08wR2FBYzgrVzAxVFNMeERtdkloRU9VWXhPcWJaRURk?= =?utf-8?B?Z045VGpxbkJDdHNvWUtaazdLNzJ1bDRQakp1eTZzdmkzZFV1NE5nUVlYeSs4?= =?utf-8?B?dnNzWnJIdDQ0M3NrVUF3bHRhcU1mSVdkNC9ETjhGMElOcmJMMjdLVzYwTk1V?= =?utf-8?B?Ti8xNXZEY2hFTWJxU3VwZmhnTHZFNzZaQmlWOXFWSU1OdTBiNG5RRUI5Z0tK?= =?utf-8?B?S2hIMk9rSWlXOW0zMU8yUytnSVJoeGJ2WDZqU1BqN24xZVdWYlNmSkcxelRm?= =?utf-8?B?NFh3T2lUY0tmZzZxMlhVUi9nVUtPMkV0THRtOENNazl4M1NOaHVSNVRFcFF6?= =?utf-8?B?d0pGYkdTanVRSklIUGVmc3J3RE9hWHBlempmRVJ2SmhRRTZ3ZkVFZG9xMk9I?= =?utf-8?B?N0hWUGJqTEk3L2ZNQ0tocmNFc2pDcndWbmlVV1hnblU3RGtZdm5RTXgrTzg3?= =?utf-8?B?NzdidUc5VHJCRysxV2xMd2UrbVF3WEJJVldNS0pWNUdZM0IwMk5IaEZtZlND?= =?utf-8?B?ZmlkYmEvS3VEUkFnSTkvR2VKYUN1MGpFMG9YN0tQOEY1dUhxMUdHazFBSTFI?= =?utf-8?B?bjFkUk81TEZsYjJ0cGVyZ2hMWEp1YkxjSjgxbENlTnJYWm9mTkY4dDRHVzRu?= =?utf-8?B?Nld3cFpSdHAzSDJnL1AyaUVHdTRCSDhWaHpJWklCVUNMVllvekFOVDdzMkd2?= =?utf-8?B?ajFIRytkS3p1REUwdHFKWEhLQzY3QXoxdWx6bnhXVDRqLzFCU2M3QU1VejlM?= =?utf-8?B?VlI0Y3N0YUNqRkRnUmRzTnNHQVRwdDQrSXdhY21qU1NwSURzYXFtRnZIRmFx?= =?utf-8?B?Z01nQ3piVHMzZlBPWFRuT0p2Nm1xbytCZHB3Z2NKQnRkejJscUZaMEM5aFJF?= =?utf-8?B?ajdES3NVSXJVZXFXSjdsSXRsZDhWalFMeFZuUWVXQ0NiUE9XbzlZS05ab09P?= =?utf-8?B?OUlxYWo3azBwc0NtUHQzY2tJdFkxQkRTTGtoenUwa1lNRXQ4RER2QXROdXdB?= =?utf-8?B?SjRLd0lvZmh4SUovdk1ON3Y5Sno4MjhDamdONWZJN3pKalJUTzA3b3BFVzhB?= =?utf-8?B?Ym9VTjNhelpmeVI3N0VJUUI1eWFZYkRIeEtKdHg1cDlkMEpUVmlMWVFCRU9B?= =?utf-8?B?ZkNOTW1UQmRiUW42YXJoUThKWXZrM0k1SHE1SWxjekx0V2swdHBMakN4aFFC?= =?utf-8?B?SXRrV0pRendVc2E4N2FrVVhydlBmcjVZYlp2OW0xeE40aDR5KzdXSEk5MGFQ?= =?utf-8?B?MlFjUHh4eDdGSmoydzJHV050dkx4K1h1c1U0Tkx4NUtTU0VWMXpIL0lGb2s1?= =?utf-8?B?SmQ3ankzdUg1YzB4NVpwUnVoM0JaNDZ0dnBubENyTDlROU1JNWRCYUFYUXZP?= =?utf-8?Q?QNyB/VFEo17Jo0ETTn9CV4ATOj1+zR167EzeLx64UFnUlc?=
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB3000; 6:Db7xb4PZtkrrq8etEqi9kItzDk155lrxVwdk4KJ1AZPkUO1p0tEYVGF5HXuKwpfqbAeG3/LeFZleMwhjJnoKTvrt+28Dw2qG5U2hiR8gbdnxi5I1oGW/iqsxNh9lUrpUWD3WbwVCecaTA5OTZkMkaJf9P8BtB+cYdTiA7uQkIddiHKowVDQ6aqs8O8mNNFNxViXwQlnnMsCIDmfrv9PFahH3Ay+OBf8rbQGIKwkLjj5XMILiWg2qm1pq39A7M8r1mp4Q9P77F+T5s82roX/z2wQW8AGWa+vX/DbmnC/wiihIXBoYgD2vwqOpUGIcpBm0C0hQYr5ekVxqMLoyWJIZ6Q==; 5:sJJb0t3ky6/W8UxOYZqdQhJ4TVFJKwaF3lfe1pxjwtvuXMXkG16xudlxoH8m+v+qMPXQoof3Ane0mvHVAJPV4KRY7nQUxo0QjUPT1iIANCfs10tMvoLU+DXUoOh9UbBsrV7hqgrDB44RP4SgY7IqxA==; 24:VuL/iEctDPNmLRPX4KbZyL/EJPSw9ZdRF4G5havUTT5UpZKU7FiwiQ/xMfPE5zCM4wVHKngrcnUMEVubN4djabZzlOMGCpP6ZFjvePv7LrA=; 7:QdJYVjC4nku2CUVx2X0Br1/k+KftAYbTduUj0b1LO8D5Ffks56CnB2jnWPoErB2GlMM2W9O9KiXLojlz5sM75UF2QTgL6Bunes+xV8ZRSKH0bWWbeE2s04F7jwBcxEg8AqOl739K7nVS8SXQs0wSfN8eM0l2EukJlxqI2TU/2Yo4ANxNfhc3GkXUo0DSSdub8R+HMoP23XUCpYSfGsmMn8wdeW4FzMh6KLfx8w+95Bc=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Aug 2017 09:48:27.8464 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB3000
Archived-At: 
Subject: Re: [netmod] Pattern statements [was Re: 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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 09:48:36 -0000

----- Original Message -----
From: "Robert Wilton" 
Sent: Monday, August 21, 2017 4:14 PM

> That makes sense.
>
> The other thing that I think that we have got wrong is modelling regex
> pattern statements.  I think that it would be much better if these
were
> written to be less exhaustive and much simpler.
>
> E.g. the "route distinguisher" pattern in
> draft-ietf-rtgwg-routing-types-09 is defined as this:
>
>           pattern
>             '(0:(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
>           +     '6[0-4][0-9]{3}|'
>           +     '[0-5]?[0-9]{0,3}[0-9]):(429496729[0-5]|'
>           +     '42949672[0-8][0-9]|'
>           +     '4294967[01][0-9]{2}|429496[0-6][0-9]{3}|'
>           +     '42949[0-5][0-9]{4}|'
>           +     '4294[0-8][0-9]{5}|429[0-3][0-9]{6}|'
>           +     '42[0-8][0-9]{7}|4[01][0-9]{8}|'
>           +     '[0-3]?[0-9]{0,8}[0-9]))|'
>           + '(1:((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|'
>           +     '25[0-5])\.){3}([0-9]|[1-9][0-9]|'
>           +     '1[0-9]{2}|2[0-4][0-9]|25[0-5])):(6553[0-5]|'
>           +     '655[0-2][0-9]|'
>           +     '65[0-4][0-9]{2}|6[0-4][0-9]{3}|'
>           +     '[0-5]?[0-9]{0,3}[0-9]))|'
>           + '(2:(429496729[0-5]|42949672[0-8][0-9]|'
>           +     '4294967[01][0-9]{2}|'
>           +     '429496[0-6][0-9]{3}|42949[0-5][0-9]{4}|'
>           +     '4294[0-8][0-9]{5}|'
>           +     '429[0-3][0-9]{6}|42[0-8][0-9]{7}|4[01][0-9]{8}|'
>           +     '[0-3]?[0-9]{0,8}[0-9]):'
>           +     '(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
>           +     '6[0-4][0-9]{3}|'
>           +     '[0-5]?[0-9]{0,3}[0-9]))|'
>           + '(6(:[a-fA-F0-9]{2}){6})|'
>           + '(([3-57-9a-fA-F]|[1-9a-fA-F][0-9a-fA-F]{1,3}):'
>           +     '[0-9a-fA-F]{1,12})';
>         }
>
> But I think that it would be much easier to read, and quite possibly
> more performant to execute, if the pattern regex was written something
> like the following:
>
>   pattern:
>      '(0:[0-9]{1,5}:[0-9]{1,10})|
>       (1:([0-9]{1,3}\.){4}:[0-9]{1,5})|
>       (2:[0-9]{1,10}:0:[0-9]{1,5})|
>       (6(:[a-fA-F0-9]{2}){6})';
>
> Of course, this would allow more invalid values, but most servers
would
> be expected to reject those when it converts them into an internal
> binary format any way.
>
> What do you, and others, think?

Simplify!

Bear in mind that the regex for an IPv6 address was wrong for a long
time in base YANG before anyone noticed - it was just too complex.

And ABNF learnt long ago that just because something could be expressed
in code does not mean that it is a good idea to do so.  If a simple
English statement replaces many lines of ABNF, then that is a good
tradeoff.

Pragmatically I am not sure what the cutoff for complexity should be but
it should be less than we have now.

Paradoxically, given the original thread, the time when large
expressions may work ok is when they have a 'sub-module' like structure,
when I can look at a group of lines in isolation and form a view of what
it does then move on to the next group and so on, building up an overall
picture piece by piece.

Tom Petch

> Thanks,
> Rob
>
>
> On 21/08/2017 15:01, Acee Lindem (acee) wrote:
> > Hi William, Rob, Andy,
> >
> > Given their limited usefulness and the detriments, perhaps we should
> > discourage the creation of new submodules in RFC6087Bis.
> >
> > Thanks,
> > Acee
> >
> > On 8/21/17, 9:44 AM, "netmod on behalf of Ivory, William"
> > 
wrote:
> >
> >> Hi Rob,
> >>
> >> That would make it very hard to update existing 1.x YANG models to
use
> >> new features in YANG 2.x if they used submodules.  Maybe that's
something
> >> that no one would ever consider doing anyway, or maybe YANG 1.1
already
> >> has similar differences to 1.0?  I had (perhaps naively) assumed
that you
> >> could migrate a namespace / model from YANG 1.0 to 2.0?
> >>
> >> Regards,
> >>
> >> William
> >>
> >> -----Original Message-----
> >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert
Wilton
> >> Sent: 21 August 2017 11:24
> >> To: netmod@ietf.org
> >> Subject: Re: [netmod] Query about augmenting module from submodule
in
> >> YANG 1.0
> >>
> >>
> >>
> >> On 09/08/2017 16:13, Juergen Schoenwaelder wrote:
> >>> On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka wrote:
> >>>> I remember that in early stages of YANG there was some irrational
> >>>> fear of introducing too many namespaces, and submodules may be a
> >>>> consequence of it. As you write, submodules provide no benefits
> >>>> whatsoever in terms of modularity, but the overhead in terms of
> >>>> metadata, IANA registration etc. is pretty much the same as for
> >>>> modules.
> >>> In case YANG 2.0 is ever done, I suggest someone files a proposal
to
> >>> remove submodules if the cost/benefit ratio is at odds. There is
> >>> nothing wrong with removing stuff that has been found problematic.
> >> I agree.
> >>
> >> I've added
> >>
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmod-2
Dw
> >>
g_yang-2Dnext_issues_26&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYi
aQ
> >>
2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7
ow
> >> I&s=-kR4fUtXArQy0RwWb32DpT1bP4X_cNqt2zJVoC0JiX8&e=
> >>
> >> Rob
> >>
> >>> The motivation for submodules was that organizations maintaining
large
> >>> modules with multiple people can do so without having to mess
around
> >>> with tools like m4 scripts to produce a single module from
'snippets'
> >>> and to avoid integration surprises. But perhaps using m4 scripts
and
> >>> decent version control systems (that can integrate and compile on
> >>> checkin) is indeed cheaper than having submodules part of the YANG
> >>> language itself.
> >>>
> >>> /js
> >>>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailma
n_
> >>
listinfo_netmod&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqw
ky
> >>
XmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7owI&s=t7
vG
> >> IH8ABuAm00e-bkSowD9eawModGq0N2OkjANtpYI&e=
> >>
> >> _______________________________________________
> >> 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
>


From nobody Wed Aug 23 03:07:27 2017
Return-Path: 
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 B626E132BE2 for ; Wed, 23 Aug 2017 03:07:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level: 
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 SCDsBe9Tv3a5 for ; Wed, 23 Aug 2017 03:07:23 -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 DAE8A132BEA for ; Wed, 23 Aug 2017 03:07:21 -0700 (PDT)
Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id v7NA5XUF022547; Wed, 23 Aug 2017 06:07:17 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 2ch78dhngu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Aug 2017 06:07:17 -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 v7NA7G2m009754; Wed, 23 Aug 2017 06:07:16 -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 v7NA7A3p009708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 23 Aug 2017 06:07:11 -0400
Received: from gbcdccas01.intl.att.com (gbcdccas01.intl.att.com [135.76.180.9]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 23 Aug 2017 10:06:56 GMT
Received: from GBCDCMBX03.intl.att.com ([135.76.31.134]) by gbcdccas01.intl.att.com ([135.76.180.9]) with mapi id 14.03.0361.001; Wed, 23 Aug 2017 11:06:55 +0100
From: "Ivory, William" 
To: "'t.petch'" , "'Acee Lindem (acee)'" , "'netmod@ietf.org'" , "'Andy Bierman'" , "'Robert Wilton'" 
Thread-Topic: [netmod] Pattern statements [was Re: Query about augmenting module from submodule in YANG 1.0]
Thread-Index: AQHTG/UAWiAkh5lOqk+g0QCn4SiEOaKRswlQ
Date: Wed, 23 Aug 2017 10:05:52 +0000
Deferred-Delivery: Wed, 23 Aug 2017 10:06:52 +0000
Message-ID: 
References:  <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com>  <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com>   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>   <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com> <044b01d31bf4$d3b37500$4001a8c0@gateway.2wire.net>
In-Reply-To: <044b01d31bf4$d3b37500$4001a8c0@gateway.2wire.net>
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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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-23_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-1707230000 definitions=main-1708230151
Archived-At: 
Subject: Re: [netmod] Pattern statements [was Re: 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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 10:07:26 -0000

UGVyc29uYWxseSBJIGhhdGUgcmVnZXhwcyBhcyBhbnl0aGluZyBvdGhlciB0aGFuIHRoZSBzaW1w
bGVzdCB0ZW5kIHRvIGJlIHRvbyBjcnlwdGljIHRvIHVuZGVyc3RhbmQgZWFzaWx5IChvciB0byB0
ZXN0KS4gIEF0IGxlYXN0IGZyb20gWUFORyAxLjEgd2UgaGF2ZSB0aGUgYWJpbGl0eSB0byBoYXZl
ICdleGNsdWRlJyBwYXR0ZXJucyAoSUlSQyksIGJ1dCBpdCdzIHN0aWxsIG5vdCBpZGVhbC4NCg0K
V2hhdCBJJ2QgbGlrZSB0byBzZWUgaW5zdGVhZCBpcyBiaXR3aXNlIG9wZXJhdG9ycyAoJiwgfCwg
PDwgYW5kID4+KSBhbG9uZyB3aXRoICdmb3InIGxvb3BzIGFuZCBwb3NzaWJseSBsb2NhbCB2YXJp
YWJsZXMgYWxsb3dlZCBpbiB0aGUgdmVyc2lvbiBvZiBYUEFUSCAgdGhhdCB3ZSB1c2UuICBXb3Vs
ZCBsaWtlbHkgbmVlZCB0byBkZWZpbmUgWUFORy1zcGVjaWZpYyBmdW5jdGlvbnMgdG8gZXh0ZW5k
IFhQQVRILCBidXQgd2UgYWxyZWFkeSBoYXZlIHNvbWUgKGN1cnJlbnQoKSBldGMpIHNvIHRoYXQg
d291bGRuJ3QgYmUgYSBwcm9ibGVtLiAgV2UgaGF2ZSBxdWl0ZSBhIGZldyBjYXNlcyB3aGVyZSB3
ZSBoYXZlIHRvIHJlc29ydCB0byBjYWxsaW5nIG91dCB0byBzY3JpcHRzIHRvIHByb3ZpZGUgbG9j
YWwgdmFsaWRhdGlvbiB0aGF0IHdvdWxkIG5vdCBiZSBuZWNlc3NhcnkgaWYgd2UgaGFkIHN1Y2gg
b3BlcmF0b3JzIGluIFhQQVRILCBhbmQgd291bGQgYWxsb3cgTkVUQ09ORiBjbGllbnRzIHRvIHBl
cmZvcm0gdmFsaWRhdGlvbiBvZmYtYm94Lg0KDQpJdCB3b3VsZCBhbHNvIGJlIGZ1biB0byBpbXBs
ZW1lbnQgLSBJIHJhdGhlciBlbmpveWVkIGltcGxlbWVudGluZyBvdXIgWFBBVEggcGFyc2VyIC0g
YnV0IHdpbGwgY29uY2VkZSB0aGF0J3MgcHJvYmFibHkgbm90IGEgcHJpb3JpdHkgd2hlbiBkZXRl
cm1pbmluZyBmZWF0dXJlIHNldHMgZm9yIGZ1dHVyZSB2ZXJzaW9ucyAoLToNCg0KV2lsbGlhbQ0K
DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogdC5wZXRjaCBbbWFpbHRvOmlldGZj
QGJ0Y29ubmVjdC5jb21dIA0KU2VudDogMjMgQXVndXN0IDIwMTcgMTA6NDYNClRvOiBBY2VlIExp
bmRlbSAoYWNlZSkgPGFjZWVAY2lzY28uY29tPjsgSXZvcnksIFdpbGxpYW0gPHdpbGxpYW0uaXZv
cnlAaW50bC5hdHQuY29tPjsgbmV0bW9kQGlldGYub3JnOyBBbmR5IEJpZXJtYW4gPGFuZHlAeXVt
YXdvcmtzLmNvbT47IFJvYmVydCBXaWx0b24gPHJ3aWx0b25AY2lzY28uY29tPg0KU3ViamVjdDog
UmU6IFtuZXRtb2RdIFBhdHRlcm4gc3RhdGVtZW50cyBbd2FzIFJlOiBRdWVyeSBhYm91dCBhdWdt
ZW50aW5nIG1vZHVsZSBmcm9tIHN1Ym1vZHVsZSBpbiBZQU5HIDEuMF0NCg0KLS0tLS0gT3JpZ2lu
YWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIlJvYmVydCBXaWx0b24iIDxyd2lsdG9uQGNpc2NvLmNv
bT4NClNlbnQ6IE1vbmRheSwgQXVndXN0IDIxLCAyMDE3IDQ6MTQgUE0NCg0KPiBUaGF0IG1ha2Vz
IHNlbnNlLg0KPg0KPiBUaGUgb3RoZXIgdGhpbmcgdGhhdCBJIHRoaW5rIHRoYXQgd2UgaGF2ZSBn
b3Qgd3JvbmcgaXMgbW9kZWxsaW5nIHJlZ2V4IA0KPiBwYXR0ZXJuIHN0YXRlbWVudHMuICBJIHRo
aW5rIHRoYXQgaXQgd291bGQgYmUgbXVjaCBiZXR0ZXIgaWYgdGhlc2UNCndlcmUNCj4gd3JpdHRl
biB0byBiZSBsZXNzIGV4aGF1c3RpdmUgYW5kIG11Y2ggc2ltcGxlci4NCj4NCj4gRS5nLiB0aGUg
InJvdXRlIGRpc3Rpbmd1aXNoZXIiIHBhdHRlcm4gaW4NCj4gZHJhZnQtaWV0Zi1ydGd3Zy1yb3V0
aW5nLXR5cGVzLTA5IGlzIGRlZmluZWQgYXMgdGhpczoNCj4NCj4gICAgICAgICAgIHBhdHRlcm4N
Cj4gICAgICAgICAgICAgJygwOig2NTUzWzAtNV18NjU1WzAtMl1bMC05XXw2NVswLTRdWzAtOV17
Mn18Jw0KPiAgICAgICAgICAgKyAgICAgJzZbMC00XVswLTldezN9fCcNCj4gICAgICAgICAgICsg
ICAgICdbMC01XT9bMC05XXswLDN9WzAtOV0pOig0Mjk0OTY3MjlbMC01XXwnDQo+ICAgICAgICAg
ICArICAgICAnNDI5NDk2NzJbMC04XVswLTldfCcNCj4gICAgICAgICAgICsgICAgICc0Mjk0OTY3
WzAxXVswLTldezJ9fDQyOTQ5NlswLTZdWzAtOV17M318Jw0KPiAgICAgICAgICAgKyAgICAgJzQy
OTQ5WzAtNV1bMC05XXs0fXwnDQo+ICAgICAgICAgICArICAgICAnNDI5NFswLThdWzAtOV17NX18
NDI5WzAtM11bMC05XXs2fXwnDQo+ICAgICAgICAgICArICAgICAnNDJbMC04XVswLTldezd9fDRb
MDFdWzAtOV17OH18Jw0KPiAgICAgICAgICAgKyAgICAgJ1swLTNdP1swLTldezAsOH1bMC05XSkp
fCcNCj4gICAgICAgICAgICsgJygxOigoKFswLTldfFsxLTldWzAtOV18MVswLTldezJ9fDJbMC00
XVswLTldfCcNCj4gICAgICAgICAgICsgICAgICcyNVswLTVdKVwuKXszfShbMC05XXxbMS05XVsw
LTldfCcNCj4gICAgICAgICAgICsgICAgICcxWzAtOV17Mn18MlswLTRdWzAtOV18MjVbMC01XSkp
Oig2NTUzWzAtNV18Jw0KPiAgICAgICAgICAgKyAgICAgJzY1NVswLTJdWzAtOV18Jw0KPiAgICAg
ICAgICAgKyAgICAgJzY1WzAtNF1bMC05XXsyfXw2WzAtNF1bMC05XXszfXwnDQo+ICAgICAgICAg
ICArICAgICAnWzAtNV0/WzAtOV17MCwzfVswLTldKSl8Jw0KPiAgICAgICAgICAgKyAnKDI6KDQy
OTQ5NjcyOVswLTVdfDQyOTQ5NjcyWzAtOF1bMC05XXwnDQo+ICAgICAgICAgICArICAgICAnNDI5
NDk2N1swMV1bMC05XXsyfXwnDQo+ICAgICAgICAgICArICAgICAnNDI5NDk2WzAtNl1bMC05XXsz
fXw0Mjk0OVswLTVdWzAtOV17NH18Jw0KPiAgICAgICAgICAgKyAgICAgJzQyOTRbMC04XVswLTld
ezV9fCcNCj4gICAgICAgICAgICsgICAgICc0MjlbMC0zXVswLTldezZ9fDQyWzAtOF1bMC05XXs3
fXw0WzAxXVswLTldezh9fCcNCj4gICAgICAgICAgICsgICAgICdbMC0zXT9bMC05XXswLDh9WzAt
OV0pOicNCj4gICAgICAgICAgICsgICAgICcoNjU1M1swLTVdfDY1NVswLTJdWzAtOV18NjVbMC00
XVswLTldezJ9fCcNCj4gICAgICAgICAgICsgICAgICc2WzAtNF1bMC05XXszfXwnDQo+ICAgICAg
ICAgICArICAgICAnWzAtNV0/WzAtOV17MCwzfVswLTldKSl8Jw0KPiAgICAgICAgICAgKyAnKDYo
OlthLWZBLUYwLTldezJ9KXs2fSl8Jw0KPiAgICAgICAgICAgKyAnKChbMy01Ny05YS1mQS1GXXxb
MS05YS1mQS1GXVswLTlhLWZBLUZdezEsM30pOicNCj4gICAgICAgICAgICsgICAgICdbMC05YS1m
QS1GXXsxLDEyfSknOw0KPiAgICAgICAgIH0NCj4NCj4gQnV0IEkgdGhpbmsgdGhhdCBpdCB3b3Vs
ZCBiZSBtdWNoIGVhc2llciB0byByZWFkLCBhbmQgcXVpdGUgcG9zc2libHkgDQo+IG1vcmUgcGVy
Zm9ybWFudCB0byBleGVjdXRlLCBpZiB0aGUgcGF0dGVybiByZWdleCB3YXMgd3JpdHRlbiBzb21l
dGhpbmcgDQo+IGxpa2UgdGhlIGZvbGxvd2luZzoNCj4NCj4gICBwYXR0ZXJuOg0KPiAgICAgICco
MDpbMC05XXsxLDV9OlswLTldezEsMTB9KXwNCj4gICAgICAgKDE6KFswLTldezEsM31cLil7NH06
WzAtOV17MSw1fSl8DQo+ICAgICAgICgyOlswLTldezEsMTB9OjA6WzAtOV17MSw1fSl8DQo+ICAg
ICAgICg2KDpbYS1mQS1GMC05XXsyfSl7Nn0pJzsNCj4NCj4gT2YgY291cnNlLCB0aGlzIHdvdWxk
IGFsbG93IG1vcmUgaW52YWxpZCB2YWx1ZXMsIGJ1dCBtb3N0IHNlcnZlcnMNCndvdWxkDQo+IGJl
IGV4cGVjdGVkIHRvIHJlamVjdCB0aG9zZSB3aGVuIGl0IGNvbnZlcnRzIHRoZW0gaW50byBhbiBp
bnRlcm5hbCANCj4gYmluYXJ5IGZvcm1hdCBhbnkgd2F5Lg0KPg0KPiBXaGF0IGRvIHlvdSwgYW5k
IG90aGVycywgdGhpbms/DQoNClNpbXBsaWZ5IQ0KDQpCZWFyIGluIG1pbmQgdGhhdCB0aGUgcmVn
ZXggZm9yIGFuIElQdjYgYWRkcmVzcyB3YXMgd3JvbmcgZm9yIGEgbG9uZyB0aW1lIGluIGJhc2Ug
WUFORyBiZWZvcmUgYW55b25lIG5vdGljZWQgLSBpdCB3YXMganVzdCB0b28gY29tcGxleC4NCg0K
QW5kIEFCTkYgbGVhcm50IGxvbmcgYWdvIHRoYXQganVzdCBiZWNhdXNlIHNvbWV0aGluZyBjb3Vs
ZCBiZSBleHByZXNzZWQgaW4gY29kZSBkb2VzIG5vdCBtZWFuIHRoYXQgaXQgaXMgYSBnb29kIGlk
ZWEgdG8gZG8gc28uICBJZiBhIHNpbXBsZSBFbmdsaXNoIHN0YXRlbWVudCByZXBsYWNlcyBtYW55
IGxpbmVzIG9mIEFCTkYsIHRoZW4gdGhhdCBpcyBhIGdvb2QgdHJhZGVvZmYuDQoNClByYWdtYXRp
Y2FsbHkgSSBhbSBub3Qgc3VyZSB3aGF0IHRoZSBjdXRvZmYgZm9yIGNvbXBsZXhpdHkgc2hvdWxk
IGJlIGJ1dCBpdCBzaG91bGQgYmUgbGVzcyB0aGFuIHdlIGhhdmUgbm93Lg0KDQpQYXJhZG94aWNh
bGx5LCBnaXZlbiB0aGUgb3JpZ2luYWwgdGhyZWFkLCB0aGUgdGltZSB3aGVuIGxhcmdlIGV4cHJl
c3Npb25zIG1heSB3b3JrIG9rIGlzIHdoZW4gdGhleSBoYXZlIGEgJ3N1Yi1tb2R1bGUnIGxpa2Ug
c3RydWN0dXJlLCB3aGVuIEkgY2FuIGxvb2sgYXQgYSBncm91cCBvZiBsaW5lcyBpbiBpc29sYXRp
b24gYW5kIGZvcm0gYSB2aWV3IG9mIHdoYXQgaXQgZG9lcyB0aGVuIG1vdmUgb24gdG8gdGhlIG5l
eHQgZ3JvdXAgYW5kIHNvIG9uLCBidWlsZGluZyB1cCBhbiBvdmVyYWxsIHBpY3R1cmUgcGllY2Ug
YnkgcGllY2UuDQoNClRvbSBQZXRjaA0KDQo+IFRoYW5rcywNCj4gUm9iDQo+DQo+DQo+IE9uIDIx
LzA4LzIwMTcgMTU6MDEsIEFjZWUgTGluZGVtIChhY2VlKSB3cm90ZToNCj4gPiBIaSBXaWxsaWFt
LCBSb2IsIEFuZHksDQo+ID4NCj4gPiBHaXZlbiB0aGVpciBsaW1pdGVkIHVzZWZ1bG5lc3MgYW5k
IHRoZSBkZXRyaW1lbnRzLCBwZXJoYXBzIHdlIHNob3VsZCANCj4gPiBkaXNjb3VyYWdlIHRoZSBj
cmVhdGlvbiBvZiBuZXcgc3VibW9kdWxlcyBpbiBSRkM2MDg3QmlzLg0KPiA+DQo+ID4gVGhhbmtz
LA0KPiA+IEFjZWUNCj4gPg0KPiA+IE9uIDgvMjEvMTcsIDk6NDQgQU0sICJuZXRtb2Qgb24gYmVo
YWxmIG9mIEl2b3J5LCBXaWxsaWFtIg0KPiA+IDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBi
ZWhhbGYgb2Ygd2lsbGlhbS5pdm9yeUBpbnRsLmF0dC5jb20+DQp3cm90ZToNCj4gPg0KPiA+PiBI
aSBSb2IsDQo+ID4+DQo+ID4+IFRoYXQgd291bGQgbWFrZSBpdCB2ZXJ5IGhhcmQgdG8gdXBkYXRl
IGV4aXN0aW5nIDEueCBZQU5HIG1vZGVscyB0bw0KdXNlDQo+ID4+IG5ldyBmZWF0dXJlcyBpbiBZ
QU5HIDIueCBpZiB0aGV5IHVzZWQgc3VibW9kdWxlcy4gIE1heWJlIHRoYXQncw0Kc29tZXRoaW5n
DQo+ID4+IHRoYXQgbm8gb25lIHdvdWxkIGV2ZXIgY29uc2lkZXIgZG9pbmcgYW55d2F5LCBvciBt
YXliZSBZQU5HIDEuMQ0KYWxyZWFkeQ0KPiA+PiBoYXMgc2ltaWxhciBkaWZmZXJlbmNlcyB0byAx
LjA/ICBJIGhhZCAocGVyaGFwcyBuYWl2ZWx5KSBhc3N1bWVkDQp0aGF0IHlvdQ0KPiA+PiBjb3Vs
ZCBtaWdyYXRlIGEgbmFtZXNwYWNlIC8gbW9kZWwgZnJvbSBZQU5HIDEuMCB0byAyLjA/DQo+ID4+
DQo+ID4+IFJlZ2FyZHMsDQo+ID4+DQo+ID4+IFdpbGxpYW0NCj4gPj4NCj4gPj4gLS0tLS1Pcmln
aW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5j
ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb2JlcnQNCldpbHRvbg0KPiA+PiBTZW50OiAyMSBB
dWd1c3QgMjAxNyAxMToyNA0KPiA+PiBUbzogbmV0bW9kQGlldGYub3JnDQo+ID4+IFN1YmplY3Q6
IFJlOiBbbmV0bW9kXSBRdWVyeSBhYm91dCBhdWdtZW50aW5nIG1vZHVsZSBmcm9tIHN1Ym1vZHVs
ZQ0KaW4NCj4gPj4gWUFORyAxLjANCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gT24gMDkvMDgvMjAx
NyAxNjoxMywgSnVlcmdlbiBTY2hvZW53YWVsZGVyIHdyb3RlOg0KPiA+Pj4gT24gV2VkLCBBdWcg
MDksIDIwMTcgYXQgMDU6MDE6MDlQTSArMDIwMCwgTGFkaXNsYXYgTGhvdGthIHdyb3RlOg0KPiA+
Pj4+IEkgcmVtZW1iZXIgdGhhdCBpbiBlYXJseSBzdGFnZXMgb2YgWUFORyB0aGVyZSB3YXMgc29t
ZSBpcnJhdGlvbmFsIA0KPiA+Pj4+IGZlYXIgb2YgaW50cm9kdWNpbmcgdG9vIG1hbnkgbmFtZXNw
YWNlcywgYW5kIHN1Ym1vZHVsZXMgbWF5IGJlIGEgDQo+ID4+Pj4gY29uc2VxdWVuY2Ugb2YgaXQu
IEFzIHlvdSB3cml0ZSwgc3VibW9kdWxlcyBwcm92aWRlIG5vIGJlbmVmaXRzIA0KPiA+Pj4+IHdo
YXRzb2V2ZXIgaW4gdGVybXMgb2YgbW9kdWxhcml0eSwgYnV0IHRoZSBvdmVyaGVhZCBpbiB0ZXJt
cyBvZiANCj4gPj4+PiBtZXRhZGF0YSwgSUFOQSByZWdpc3RyYXRpb24gZXRjLiBpcyBwcmV0dHkg
bXVjaCB0aGUgc2FtZSBhcyBmb3IgDQo+ID4+Pj4gbW9kdWxlcy4NCj4gPj4+IEluIGNhc2UgWUFO
RyAyLjAgaXMgZXZlciBkb25lLCBJIHN1Z2dlc3Qgc29tZW9uZSBmaWxlcyBhIHByb3Bvc2FsDQp0
bw0KPiA+Pj4gcmVtb3ZlIHN1Ym1vZHVsZXMgaWYgdGhlIGNvc3QvYmVuZWZpdCByYXRpbyBpcyBh
dCBvZGRzLiBUaGVyZSBpcyANCj4gPj4+IG5vdGhpbmcgd3Jvbmcgd2l0aCByZW1vdmluZyBzdHVm
ZiB0aGF0IGhhcyBiZWVuIGZvdW5kIHByb2JsZW1hdGljLg0KPiA+PiBJIGFncmVlLg0KPiA+Pg0K
PiA+PiBJJ3ZlIGFkZGVkDQo+ID4+DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v
djIvdXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21fbmV0bW9kLTINCkR3DQo+ID4+DQpnX3lhbmct
MkRuZXh0X2lzc3Vlc18yNiZkPUR3SUNBZyZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1wOGt5
ZUszdTRaWWkNCmFRDQo+ID4+DQoyWlBHcXdreVhtUWdCSDZyNWpwWWlZV3pocUo0OCZtPWw3YzRJ
UEwwNDlBMmJWVk8xNGZ5Qk1seTIxMXhVNjF4U0hnUGxBVDcNCm93DQo+ID4+IEkmcz0ta1I0ZlV0
WEFyUXkwUndXYjMyRHBUMWJQNFhfY05xdDJ6SlZvQzBKaVg4JmU9DQo+ID4+DQo+ID4+IFJvYg0K
PiA+Pg0KPiA+Pj4gVGhlIG1vdGl2YXRpb24gZm9yIHN1Ym1vZHVsZXMgd2FzIHRoYXQgb3JnYW5p
emF0aW9ucyBtYWludGFpbmluZw0KbGFyZ2UNCj4gPj4+IG1vZHVsZXMgd2l0aCBtdWx0aXBsZSBw
ZW9wbGUgY2FuIGRvIHNvIHdpdGhvdXQgaGF2aW5nIHRvIG1lc3MNCmFyb3VuZA0KPiA+Pj4gd2l0
aCB0b29scyBsaWtlIG00IHNjcmlwdHMgdG8gcHJvZHVjZSBhIHNpbmdsZSBtb2R1bGUgZnJvbQ0K
J3NuaXBwZXRzJw0KPiA+Pj4gYW5kIHRvIGF2b2lkIGludGVncmF0aW9uIHN1cnByaXNlcy4gQnV0
IHBlcmhhcHMgdXNpbmcgbTQgc2NyaXB0cw0KYW5kDQo+ID4+PiBkZWNlbnQgdmVyc2lvbiBjb250
cm9sIHN5c3RlbXMgKHRoYXQgY2FuIGludGVncmF0ZSBhbmQgY29tcGlsZSBvbg0KPiA+Pj4gY2hl
Y2tpbikgaXMgaW5kZWVkIGNoZWFwZXIgdGhhbiBoYXZpbmcgc3VibW9kdWxlcyBwYXJ0IG9mIHRo
ZSBZQU5HIA0KPiA+Pj4gbGFuZ3VhZ2UgaXRzZWxmLg0KPiA+Pj4NCj4gPj4+IC9qcw0KPiA+Pj4N
Cj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g
Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiA+PiBuZXRtb2RAaWV0Zi5vcmcNCj4gPj4NCmh0dHBz
Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu
b3JnX21haWxtYQ0Kbl8NCj4gPj4NCmxpc3RpbmZvX25ldG1vZCZkPUR3SUNBZyZjPUxGWVotbzlf
SFVNZU1UU1FpY3ZqSWcmcj1wOGt5ZUszdTRaWWlhUTJaUEdxdw0Ka3kNCj4gPj4NClhtUWdCSDZy
NWpwWWlZV3pocUo0OCZtPWw3YzRJUEwwNDlBMmJWVk8xNGZ5Qk1seTIxMXhVNjF4U0hnUGxBVDdv
d0kmcz10Nw0KdkcNCj4gPj4gSUg4QUJ1QW0wMGUtYmtTb3dEOWVhd01vZEdxME4yT2tqQU50cFlJ
JmU9DQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+ID4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPj4gbmV0bW9kQGlldGYub3JnDQo+
ID4+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f
d3d3LmlldGYub3JnX20NCj4gPj4gYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUNhUSZjPUxG
WVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1wOGt5ZUszdQ0KPiA+PiA0WllpYVEyWlBHcXdreVhtUWdC
SDZyNWpwWWlZV3pocUo0OCZtPVYzWGQwOUllQmJ1d0h0SVBkNFlJdDlrUUJzeFNEDQo+ID4+IEs3
emxkRmZtVDEyT084JnM9VGtxNEdXT1VtZXpuRVR1X1VWeExwT29tM1VYRWlJNUkybUxlN3RwRG9a
dyZlPQ0KPg0KPg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0NCg0KDQo+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5n
IGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50
LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWwNCj4gbWFuX2xpc3RpbmZv
X25ldG1vZCZkPUR3SUNhUSZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1wOGt5ZUszdTRaWWlh
UQ0KPiAyWlBHcXdreVhtUWdCSDZyNWpwWWlZV3pocUo0OCZtPVYzWGQwOUllQmJ1d0h0SVBkNFlJ
dDlrUUJzeFNESzd6bGRGZm1UDQo+IDEyT084JnM9VGtxNEdXT1VtZXpuRVR1X1VWeExwT29tM1VY
RWlJNUkybUxlN3RwRG9adyZlPQ0KPg0KDQo=


From nobody Wed Aug 23 03:10:57 2017
Return-Path: 
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 4C325132BE2 for ; Wed, 23 Aug 2017 03:10:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level: 
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-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 o6hAi7xJU3us for ; Wed, 23 Aug 2017 03:10:54 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 4DB57132941 for ; Wed, 23 Aug 2017 03:10:54 -0700 (PDT)
Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id v7NA5Xsi006328; Wed, 23 Aug 2017 06:10:50 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 2ch6amu9dt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Aug 2017 06:10:50 -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 v7NAAms4012698; Wed, 23 Aug 2017 06:10:49 -0400
Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7NAAfAM012531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 23 Aug 2017 06:10:46 -0400
Received: from gbcdccas01.intl.att.com (gbcdccas01.intl.att.com [135.76.180.9]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Wed, 23 Aug 2017 10:10:32 GMT
Received: from GBCDCMBX03.intl.att.com ([135.76.31.134]) by gbcdccas01.intl.att.com ([135.76.180.9]) with mapi id 14.03.0361.001; Wed, 23 Aug 2017 11:10:30 +0100
From: "Ivory, William" 
To: "'Robert Wilton'" , "'Juergen Schoenwaelder'" 
CC: "'Alex Campbell'" , "'netmod@ietf.org'" 
Thread-Topic: [netmod] Query about augmenting module from submodule in YANG 1.0
Thread-Index: AdMMOPUClm48yMKSSEeEurX4RbXaiADP5++AAAR9DaAACC3kAAAcrpQgAD0R+IAAAWwvgAAAa7wAAlFjp4AACPgnkABCnQKAABQ6ExD///QegP//4ixwgABFaYD//+mjQA==
Date: Wed, 23 Aug 2017 10:09:27 +0000
Deferred-Delivery: Wed, 23 Aug 2017 10:10:27 +0000
Message-ID: 
References:  <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com>   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>  <1503440878003.28215@Aviatnet.com>  <20170823072435.wv7pvndrm5du5q3x@elstar.local>  
In-Reply-To: 
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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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-23_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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708230151
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 10:10:56 -0000

SGkgUm9iZXJ0LA0KDQpQcm9iYWJseSBzaG91bGRuJ3QgaGF2ZSBtZW50aW9uZWQgcGFja2FnZXMg
YXMgdGhhdCdzIHJlYWxseSBhIGRpdmVyc2lvbiBmcm9tIHRoZSBtYWluIHBvaW50LiAgV2hhdCBz
dWJtb2R1bGVzIHByb3ZpZGUgaXMgYSB3YXkgdG8gZGlmZmVyZW50aWF0ZSBZQU5HIG5vZGVzIGlu
IGEgc2luZ2xlIG5hbWVzcGFjZSBzbyB0aGF0IHdoaWxlIHN0aWxsIGJlbG9uZ2luZyB0byB0aGF0
IHNpbmdsZSBuYW1lc3BhY2UsIHN1YnNldHMgbWF5IGJlIGhhbmRsZWQgYnkgZGlmZmVyZW50IGRh
ZW1vbnMgc2ltcGx5IGJ5IHJvdXRpbmcgYWNjb3JkaW5nIHRvIHN1Ym1vZHVsZSBpZC4gIFRoYXQg
a2VlcHMgYWxsIHRoZSBpZGVudGlmeWluZyBsb2dpYyB3aXRoaW4gWUFORy4NCg0KT2J2aW91c2x5
IGlmIHdlIGNvdWxkIHN0YXJ0IGFmcmVzaCwgd2UnZCB1c2Ugc2VwYXJhdGUgbW9kdWxlcyBmcm9t
IGRheSBvbmUuICBIb3dldmVyLCB3ZSBoYXZlIGV4aXN0aW5nIFlBTkcgdGhhdCBuZWVkcyB0byBy
ZW1haW4gdG8gYmUgYmFja3dhcmRzLWNvbXBhdGlibGUsIHNvIHRoYXQgaXNuJ3QgYW4gb3B0aW9u
Lg0KDQpSZWdhcmRzLA0KDQpXaWxsaWFtDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG
cm9tOiBSb2JlcnQgV2lsdG9uIFttYWlsdG86cndpbHRvbkBjaXNjby5jb21dIA0KU2VudDogMjMg
QXVndXN0IDIwMTcgMTA6NDYNClRvOiBJdm9yeSwgV2lsbGlhbSA8d2lsbGlhbS5pdm9yeUBpbnRs
LmF0dC5jb20+OyAnSnVlcmdlbiBTY2hvZW53YWVsZGVyJyA8ai5zY2hvZW53YWVsZGVyQGphY29i
cy11bml2ZXJzaXR5LmRlPg0KQ2M6ICdBbGV4IENhbXBiZWxsJyA8QWxleC5DYW1wYmVsbEBBdmlh
dG5ldC5jb20+OyAnbmV0bW9kQGlldGYub3JnJyA8bmV0bW9kQGlldGYub3JnPg0KU3ViamVjdDog
UmU6IFtuZXRtb2RdIFF1ZXJ5IGFib3V0IGF1Z21lbnRpbmcgbW9kdWxlIGZyb20gc3VibW9kdWxl
IGluIFlBTkcgMS4wDQoNCkhpIFdpbGxpYW0sDQoNCkkgdGhpbmsgdGhhdCB0aGVyZSBtaWdodCBi
ZSBzb21lIGRvd25zaWRlcyB0byB5b3VyIHByb3Bvc2VkIHNvbHV0aW9uIG9mIHVzaW5nIHN1Ym1v
ZHVsZXMgLSB3aGljaCB5b3UgbWF5IGhhdmUgYWxyZWFkeSBjb25zaWRlcmVkOg0KDQoxKSBBbGwg
b2YgdGhlIGRlYmlhbiBwYWNrYWdlcyB3aWxsIGhhdmUgdG8gYmUgaW5zdGFsbGVkIHRvZ2V0aGVy
IHRvIGFsbG93IHRoZSBZQU5HIG1vZHVsZSB0byBiZSBidWlsdCwgb3Igb3RoZXJ3aXNlIHRoZXJl
IHdpbGwgYmUgbWlzc2luZyBzdWJtb2R1bGVzLCBhbmQgdGhlIG1vZHVsZSB3aWxsIGZhaWwgdG8g
Y29tcGlsZSAoc2luY2UgdGhlIHRvcCBsZXZlbCBtb2R1bGUgbXVzdCBsaXN0IGFsbCBpbmNsdWRl
ZCBzdWItbW9kdWxlcykuDQoyKSBJdCBtaWdodCBlbmQgdXAgd2l0aCB5b3VyIHJlcXVpcmluZyB0
aWdodCB2ZXJzaW9uaW5nIG9mIGFsbCBvZiB5b3VyIGRlYmlhbiBwYWNrYWdlcyB0b2dldGhlciB3
aXRoIHRoZSBzYW1lIHZlcnNpb24gbnVtYmVyLCBvciBvdGhlcndpc2UgeW91IG1heSBuZWVkIGdy
ZWF0ZXIgY2FyZSBvdmVyIGhvdyB0aGUgc3ViLW1vZHVsZXMgYXJlIHVwZGF0ZWQgYW5kIGRlcGVu
ZGVuY2llcyBhcmUgaGFuZGxlZC4NCg0KSWYgeW91ciBZQU5HIHdhcyBiZWluZyBkZXNpZ25lZCBm
cm9tIHNjcmF0Y2ggdGhlbiB1c2luZyBzZXBhcmF0ZSBZQU5HIG1vZHVsZXMgbWF5IGFsbG93IGZv
ciBhIGNsZWFuZXIgc29sdXRpb24gLSBidXQgSSBhcHByZWNpYXRlIHRoYXQgbWF5IG5vdCBoZWxw
IHlvdSB3aXRoIHdoZXJlIHlvdSBhcmUgbm93Lg0KDQpUaGFua3MsDQpSb2INCg0KDQpPbiAyMy8w
OC8yMDE3IDA5OjI0LCBJdm9yeSwgV2lsbGlhbSB3cm90ZToNCj4gU29ycnkgLSBtZWFudCBEZWJp
YW4gcGFja2FnZXMuICBXZSBoYXZlIGEgbGFyZ2UgWUFORyBtb2R1bGUgdGhhdCByZWFsbHkgb3Vn
aHQgdG8gYmUgaGFuZGxlZCBieSBtdWx0aXBsZSBkYWVtb25zLCBzbyBwbGFuIHRvIHVzZSBzdWJt
b2R1bGVzIHNvIHdlIGNhbiBpZGVudGlmeSB0aGUgZGlmZmVyZW50IHBhcnRzIGFuZCBwcm9jZXNz
IHRoZW0gaW4gdGhlIHJpZ2h0IHBsYWNlLiAgUmVjb21iaW5pbmcgaW50byBhIHNpbmdsZSBtb2R1
bGUgd291bGQgbG9zZSB0aGF0IGdyYW51bGFyaXR5Lg0KPg0KPiBXaWxsaWFtDQo+DQo+IC0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciANCj4g
W21haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGVdDQo+IFNlbnQ6IDIz
IEF1Z3VzdCAyMDE3IDA4OjI1DQo+IFRvOiBJdm9yeSwgV2lsbGlhbSA8d2lsbGlhbS5pdm9yeUBp
bnRsLmF0dC5jb20+DQo+IENjOiAnQWxleCBDYW1wYmVsbCcgPEFsZXguQ2FtcGJlbGxAQXZpYXRu
ZXQuY29tPjsgJ1JvYmVydCBXaWx0b24nIA0KPiA8cndpbHRvbkBjaXNjby5jb20+OyAnbmV0bW9k
QGlldGYub3JnJyA8bmV0bW9kQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW25ldG1vZF0gUXVl
cnkgYWJvdXQgYXVnbWVudGluZyBtb2R1bGUgZnJvbSBzdWJtb2R1bGUgaW4gDQo+IFlBTkcgMS4w
DQo+DQo+IFdoYXQgYXJlIHBhY2thZ2VzPyBJIHRoaW5rIHN1Ym1vZHVsZXMgZGVjbGFyZSB0byB3
aGljaCBtb2R1bGUgdGhleSBiZWxvbmcsIG5vPyBQZXJoYXBzIHlvdSBhcmUgZG9pbmcgc29tZXRo
aW5nIHRoYXQgc3VibW9kdWxlcyBkbyBub3QgZXZlbiBzdXBwb3J0Lg0KPg0KPiAvanMNCj4NCj4g
T24gV2VkLCBBdWcgMjMsIDIwMTcgYXQgMDc6MDg6MTBBTSArMDAwMCwgSXZvcnksIFdpbGxpYW0g
d3JvdGU6DQo+PiAuLi4gIGV4Y2VwdCB0aGF0IGlmIHRoZSB3aG9sZSByZWFzb24gZm9yIHNwbGl0
dGluZyBpbnRvIHN1Ym1vZHVsZXMgd2FzIHRvIGFsbG93IHRoZSBzdWJtb2R1bGVzIHRvIGJlbG9u
ZyB0byBkaWZmZXJlbnQgcGFja2FnZXMgaW4gb3VyIHN5c3RlbSwgY29tYmluaW5nIHRoZW0gYmFj
ayBhZ2FpbiBpcyBub3QgcG9zc2libGUuICBJIHdvdWxkbid0IGJlIHNwbGl0dGluZyB0aGVtIHVu
bGVzcyBJIG5lZWRlZCB0byBmb3IgZ29vZCByZWFzb24uDQo+Pg0KPj4gV2lsbGlhbQ0KPj4NCj4+
IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBBbGV4IENhbXBiZWxsIFttYWls
dG86QWxleC5DYW1wYmVsbEBBdmlhdG5ldC5jb21dDQo+PiBTZW50OiAyMiBBdWd1c3QgMjAxNyAy
MzoyOA0KPj4gVG86IEl2b3J5LCBXaWxsaWFtIDx3aWxsaWFtLml2b3J5QGludGwuYXR0LmNvbT47
ICdSb2JlcnQgV2lsdG9uJw0KPj4gPHJ3aWx0b25AY2lzY28uY29tPjsgJ25ldG1vZEBpZXRmLm9y
ZycgPG5ldG1vZEBpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBRdWVyeSBhYm91
dCBhdWdtZW50aW5nIG1vZHVsZSBmcm9tIHN1Ym1vZHVsZSBpbiANCj4+IFlBTkcgMS4wDQo+Pg0K
Pj4gSGksDQo+Pg0KPj4gSSdtIG5vdCBSb2IsIGJ1dCBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQg
aWYgYSBtb2R1bGUgYXV0aG9yIHdhbnRlZCB0byBtaWdyYXRlIHRvIFlBTkcgMi4wLCB0aGV5IGNv
dWxkIG1lcmdlIHRoZWlyIHN1Ym1vZHVsZXMgYmFjayBpbnRvIHRoZSBtYWluIG1vZHVsZSAtIHdo
aWNoIGlzIG5vdCBhIGRpZmZpY3VsdCBwcm9jZWR1cmUgYW5kIGRvZXMgbm90IGJyZWFrIGNvbXBh
dGliaWxpdHkgd2l0aCBjbGllbnRzLg0KPj4NCj4+IEFsZXgNCj4+IF9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCj4+IEZyb206IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNA
aWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBJdm9yeSwgV2lsbGlhbSANCj4+IDx3aWxsaWFtLml2b3J5
QGludGwuYXR0LmNvbT4NCj4+IFNlbnQ6IFR1ZXNkYXksIDIyIEF1Z3VzdCAyMDE3IDE6NDQgYS5t
Lg0KPj4gVG86ICdSb2JlcnQgV2lsdG9uJzsgJ25ldG1vZEBpZXRmLm9yZycNCj4+IFN1YmplY3Q6
IFJlOiBbbmV0bW9kXSBRdWVyeSBhYm91dCBhdWdtZW50aW5nIG1vZHVsZSBmcm9tIHN1Ym1vZHVs
ZSBpbiANCj4+IFlBTkcgMS4wDQo+Pg0KPj4gSGkgUm9iLA0KPj4NCj4+IFRoYXQgd291bGQgbWFr
ZSBpdCB2ZXJ5IGhhcmQgdG8gdXBkYXRlIGV4aXN0aW5nIDEueCBZQU5HIG1vZGVscyB0byB1c2Ug
bmV3IGZlYXR1cmVzIGluIFlBTkcgMi54IGlmIHRoZXkgdXNlZCBzdWJtb2R1bGVzLiAgTWF5YmUg
dGhhdCdzIHNvbWV0aGluZyB0aGF0IG5vIG9uZSB3b3VsZCBldmVyIGNvbnNpZGVyIGRvaW5nIGFu
eXdheSwgb3IgbWF5YmUgWUFORyAxLjEgYWxyZWFkeSBoYXMgc2ltaWxhciBkaWZmZXJlbmNlcyB0
byAxLjA/ICBJIGhhZCAocGVyaGFwcyBuYWl2ZWx5KSBhc3N1bWVkIHRoYXQgeW91IGNvdWxkIG1p
Z3JhdGUgYSBuYW1lc3BhY2UgLyBtb2RlbCBmcm9tIFlBTkcgMS4wIHRvIDIuMD8NCj4+DQo+PiBS
ZWdhcmRzLA0KPj4NCj4+IFdpbGxpYW0NCj4+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KPj4gRnJvbTogbmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl
aGFsZiBPZiBSb2JlcnQgDQo+PiBXaWx0b24NCj4+IFNlbnQ6IDIxIEF1Z3VzdCAyMDE3IDExOjI0
DQo+PiBUbzogbmV0bW9kQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW25ldG1vZF0gUXVlcnkg
YWJvdXQgYXVnbWVudGluZyBtb2R1bGUgZnJvbSBzdWJtb2R1bGUgaW4gDQo+PiBZQU5HIDEuMA0K
Pj4NCj4+DQo+Pg0KPj4gT24gMDkvMDgvMjAxNyAxNjoxMywgSnVlcmdlbiBTY2hvZW53YWVsZGVy
IHdyb3RlOg0KPj4+IE9uIFdlZCwgQXVnIDA5LCAyMDE3IGF0IDA1OjAxOjA5UE0gKzAyMDAsIExh
ZGlzbGF2IExob3RrYSB3cm90ZToNCj4+Pj4gSSByZW1lbWJlciB0aGF0IGluIGVhcmx5IHN0YWdl
cyBvZiBZQU5HIHRoZXJlIHdhcyBzb21lIGlycmF0aW9uYWwgDQo+Pj4+IGZlYXIgb2YgaW50cm9k
dWNpbmcgdG9vIG1hbnkgbmFtZXNwYWNlcywgYW5kIHN1Ym1vZHVsZXMgbWF5IGJlIGEgDQo+Pj4+
IGNvbnNlcXVlbmNlIG9mIGl0LiBBcyB5b3Ugd3JpdGUsIHN1Ym1vZHVsZXMgcHJvdmlkZSBubyBi
ZW5lZml0cyANCj4+Pj4gd2hhdHNvZXZlciBpbiB0ZXJtcyBvZiBtb2R1bGFyaXR5LCBidXQgdGhl
IG92ZXJoZWFkIGluIHRlcm1zIG9mIA0KPj4+PiBtZXRhZGF0YSwgSUFOQSByZWdpc3RyYXRpb24g
ZXRjLiBpcyBwcmV0dHkgbXVjaCB0aGUgc2FtZSBhcyBmb3IgDQo+Pj4+IG1vZHVsZXMuDQo+Pj4g
SW4gY2FzZSBZQU5HIDIuMCBpcyBldmVyIGRvbmUsIEkgc3VnZ2VzdCBzb21lb25lIGZpbGVzIGEg
cHJvcG9zYWwgdG8gDQo+Pj4gcmVtb3ZlIHN1Ym1vZHVsZXMgaWYgdGhlIGNvc3QvYmVuZWZpdCBy
YXRpbyBpcyBhdCBvZGRzLiBUaGVyZSBpcyANCj4+PiBub3RoaW5nIHdyb25nIHdpdGggcmVtb3Zp
bmcgc3R1ZmYgdGhhdCBoYXMgYmVlbiBmb3VuZCBwcm9ibGVtYXRpYy4NCj4+IEkgYWdyZWUuDQo+
Pg0KPj4gSSd2ZSBhZGRlZA0KPj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy
L3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX25ldG1vDQo+PiBkIA0KPj4gLTJEd2dfeWFuZy0y
RG5leHRfaXNzdWVzXzI2JmQ9RHdJQ0FnJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPXA4a3ll
DQo+PiBLDQo+PiAzdTRaWWlhUTJaUEdxd2t5WG1RZ0JINnI1anBZaVlXemhxSjQ4Jm09bDdjNElQ
TDA0OUEyYlZWTzE0ZnlCTWx5MjExeFUNCj4+IDYgMXhTSGdQbEFUN293SSZzPS1rUjRmVXRYQXJR
eTBSd1diMzJEcFQxYlA0WF9jTnF0MnpKVm9DMEppWDgmZT0NCj4+DQo+PiBSb2INCj4+DQo+Pj4g
VGhlIG1vdGl2YXRpb24gZm9yIHN1Ym1vZHVsZXMgd2FzIHRoYXQgb3JnYW5pemF0aW9ucyBtYWlu
dGFpbmluZyANCj4+PiBsYXJnZSBtb2R1bGVzIHdpdGggbXVsdGlwbGUgcGVvcGxlIGNhbiBkbyBz
byB3aXRob3V0IGhhdmluZyB0byBtZXNzIA0KPj4+IGFyb3VuZCB3aXRoIHRvb2xzIGxpa2UgbTQg
c2NyaXB0cyB0byBwcm9kdWNlIGEgc2luZ2xlIG1vZHVsZSBmcm9tICdzbmlwcGV0cycNCj4+PiBh
bmQgdG8gYXZvaWQgaW50ZWdyYXRpb24gc3VycHJpc2VzLiBCdXQgcGVyaGFwcyB1c2luZyBtNCBz
Y3JpcHRzIGFuZCANCj4+PiBkZWNlbnQgdmVyc2lvbiBjb250cm9sIHN5c3RlbXMgKHRoYXQgY2Fu
IGludGVncmF0ZSBhbmQgY29tcGlsZSBvbg0KPj4+IGNoZWNraW4pIGlzIGluZGVlZCBjaGVhcGVy
IHRoYW4gaGF2aW5nIHN1Ym1vZHVsZXMgcGFydCBvZiB0aGUgWUFORyANCj4+PiBsYW5ndWFnZSBp
dHNlbGYuDQo+Pj4NCj4+PiAvanMNCj4+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+IG5ldG1vZEBp
ZXRmLm9yZw0KPj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0
dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpDQo+PiBsIA0KPj4gbWFuX2xpc3RpbmZvX25ldG1vZCZk
PUR3SUNBZyZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1wOGt5ZUszdTRaWWlhDQo+PiBRIA0K
Pj4gMlpQR3F3a3lYbVFnQkg2cjVqcFlpWVd6aHFKNDgmbT1sN2M0SVBMMDQ5QTJiVlZPMTRmeUJN
bHkyMTF4VTYxeFNIZ1BsDQo+PiBBIFQ3b3dJJnM9dDd2R0lIOEFCdUFtMDBlLWJrU293RDllYXdN
b2RHcTBOMk9rakFOdHBZSSZlPQ0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+PiBuZXRtb2RAaWV0
Zi5vcmcNCj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw
cy0zQV9fd3d3LmlldGYub3JnX21haQ0KPj4gbCANCj4+IG1hbl9saXN0aW5mb19uZXRtb2QmZD1E
d0lGQXcmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9cDhreWVLM3U0WllpYQ0KPj4gUSANCj4+
IDJaUEdxd2t5WG1RZ0JINnI1anBZaVlXemhxSjQ4Jm09ZXNpOEdQU2MxeFZqVHQ5U0t4cXpOSFJE
WFQyUDFoMDFhLVVlYg0KPj4gbiBTVC1ZbyZzPVBjdEt5M2lqNlcwVFFzMU5GcDE4U1g4TVF0WUtl
RzlSeEFEaDNjcGhjeFUmZT0NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gbmV0bW9kQGlldGYu
b3JnDQo+PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt
M0FfX3d3dy5pZXRmLm9yZ19tYWkNCj4+IGwgDQo+PiBtYW5fbGlzdGluZm9fbmV0bW9kJmQ9RHdJ
QkFnJmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPXA4a3llSzN1NFpZaWENCj4+IFEgDQo+PiAy
WlBHcXdreVhtUWdCSDZyNWpwWWlZV3pocUo0OCZtPVJIM3p2RDJCOF9zNHV3MVBYbV9rYTM3dmd6
OV9xMlJjODd0RDgNCj4+IEsgZlo5akEmcz1YeWRVMHZYRTBBRWcyRkRFLWt4X0FlNnJPT0FoNWtv
eEVlSjJjZWZnRE5BJmU9DQoNCg==


From nobody Wed Aug 23 03:25:51 2017
Return-Path: 
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 870F6132946 for ; Wed, 23 Aug 2017 03:25:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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
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 Q8tpuNyPu2jF for ; Wed, 23 Aug 2017 03:25:47 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 786251321B6 for ; Wed, 23 Aug 2017 03:25:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7865; q=dns/txt; s=iport; t=1503483946; x=1504693546; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=oD9bcgZhylhThzBdyOA4b9x4dwm0aKzPxpG51L7B0rc=; b=VcRazRbClIiCUiPmQCXN/5KhDxxO8XLXIXYoU2llCGTsjjld6eoToeqz +yc9OqyLMk6oZFzt2lOyt0Q9xolEzHQ4zPdaLqiS4inkcxNZkEbSIuvOa LFxsMtDF6agTt9wTVTF87Jq4DXKSFYCByeoZNBIw9m93q2WWssdM9zw1R 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAQAxV51Z/xbLJq1SChkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMtgRGBFY8IkRaYNiyFGwKEfRUBAgEBAQEBAQFrKIUYAQEBAQI?= =?us-ascii?q?BIxU2BgUFBwQLEAEEAQEBAgIjAwICRgkIBgEMBgIBAReKDggQrhuCJotvAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBGAWBDYIdg06BYyuCfIMmgSIrgxOCYQWgWIdWjG6?= =?us-ascii?q?CEok8hxaJb4NPiHA1IoEKMiEIHBVJhxs/NgEBin8BAQE?=
X-IronPort-AV: E=Sophos;i="5.41,416,1498521600"; d="scan'208";a="696701929"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Aug 2017 10:25:42 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v7NAPfSl027256; Wed, 23 Aug 2017 10:25:41 GMT
To: "Ivory, William" , "'Juergen Schoenwaelder'" 
Cc: "'Alex Campbell'" , "'netmod@ietf.org'" 
References:  <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com>   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>  <1503440878003.28215@Aviatnet.com>  <20170823072435.wv7pvndrm5du5q3x@elstar.local>   
From: Robert Wilton 
Message-ID: 
Date: Wed, 23 Aug 2017 11:25:41 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 10:25:50 -0000

On 23/08/2017 11:09, Ivory, William wrote:
> Hi Robert,
>
> Probably shouldn't have mentioned packages as that's really a diversion from the main point.  What submodules provide is a way to differentiate YANG nodes in a single namespace so that while still belonging to that single namespace, subsets may be handled by different daemons simply by routing according to submodule id.  That keeps all the identifying logic within YANG.
>
> Obviously if we could start afresh, we'd use separate modules from day one.  However, we have existing YANG that needs to remain to be backwards-compatible, so that isn't an option.
Another potential solution that doesn't use sub modules could be to 
define a bespoke YANG extension to annotate your YANG schema tree with 
any necessary routing information for it to be handled by the 
appropriate daemon.

Thanks,
Rob

> Regards,
>
> William
>
> -----Original Message-----
> From: Robert Wilton [mailto:rwilton@cisco.com]
> Sent: 23 August 2017 10:46
> To: Ivory, William ; 'Juergen Schoenwaelder' 
> Cc: 'Alex Campbell' ; 'netmod@ietf.org' 
> Subject: Re: [netmod] Query about augmenting module from submodule in YANG 1.0
>
> Hi William,
>
> I think that there might be some downsides to your proposed solution of using submodules - which you may have already considered:
>
> 1) All of the debian packages will have to be installed together to allow the YANG module to be built, or otherwise there will be missing submodules, and the module will fail to compile (since the top level module must list all included sub-modules).
> 2) It might end up with your requiring tight versioning of all of your debian packages together with the same version number, or otherwise you may need greater care over how the sub-modules are updated and dependencies are handled.
>
> If your YANG was being designed from scratch then using separate YANG modules may allow for a cleaner solution - but I appreciate that may not help you with where you are now.
>
> Thanks,
> Rob
>
>
> On 23/08/2017 09:24, Ivory, William wrote:
>> Sorry - meant Debian packages.  We have a large YANG module that really ought to be handled by multiple daemons, so plan to use submodules so we can identify the different parts and process them in the right place.  Recombining into a single module would lose that granularity.
>>
>> William
>>
>> -----Original Message-----
>> From: Juergen Schoenwaelder
>> [mailto:j.schoenwaelder@jacobs-university.de]
>> Sent: 23 August 2017 08:25
>> To: Ivory, William 
>> Cc: 'Alex Campbell' ; 'Robert Wilton'
>> ; 'netmod@ietf.org' 
>> Subject: Re: [netmod] Query about augmenting module from submodule in
>> YANG 1.0
>>
>> What are packages? I think submodules declare to which module they belong, no? Perhaps you are doing something that submodules do not even support.
>>
>> /js
>>
>> On Wed, Aug 23, 2017 at 07:08:10AM +0000, Ivory, William wrote:
>>> ...  except that if the whole reason for splitting into submodules was to allow the submodules to belong to different packages in our system, combining them back again is not possible.  I wouldn't be splitting them unless I needed to for good reason.
>>>
>>> William
>>>
>>> -----Original Message-----
>>> From: Alex Campbell [mailto:Alex.Campbell@Aviatnet.com]
>>> Sent: 22 August 2017 23:28
>>> To: Ivory, William ; 'Robert Wilton'
>>> ; 'netmod@ietf.org' 
>>> Subject: Re: [netmod] Query about augmenting module from submodule in
>>> YANG 1.0
>>>
>>> Hi,
>>>
>>> I'm not Rob, but my understanding is that if a module author wanted to migrate to YANG 2.0, they could merge their submodules back into the main module - which is not a difficult procedure and does not break compatibility with clients.
>>>
>>> Alex
>>> ________________________________________
>>> From: netmod  on behalf of Ivory, William
>>> 
>>> Sent: Tuesday, 22 August 2017 1:44 a.m.
>>> To: 'Robert Wilton'; 'netmod@ietf.org'
>>> Subject: Re: [netmod] Query about augmenting module from submodule in
>>> YANG 1.0
>>>
>>> Hi Rob,
>>>
>>> That would make it very hard to update existing 1.x YANG models to use new features in YANG 2.x if they used submodules.  Maybe that's something that no one would ever consider doing anyway, or maybe YANG 1.1 already has similar differences to 1.0?  I had (perhaps naively) assumed that you could migrate a namespace / model from YANG 1.0 to 2.0?
>>>
>>> Regards,
>>>
>>> William
>>>
>>> -----Original Message-----
>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert
>>> Wilton
>>> Sent: 21 August 2017 11:24
>>> To: netmod@ietf.org
>>> Subject: Re: [netmod] Query about augmenting module from submodule in
>>> YANG 1.0
>>>
>>>
>>>
>>> On 09/08/2017 16:13, Juergen Schoenwaelder wrote:
>>>> On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka wrote:
>>>>> I remember that in early stages of YANG there was some irrational
>>>>> fear of introducing too many namespaces, and submodules may be a
>>>>> consequence of it. As you write, submodules provide no benefits
>>>>> whatsoever in terms of modularity, but the overhead in terms of
>>>>> metadata, IANA registration etc. is pretty much the same as for
>>>>> modules.
>>>> In case YANG 2.0 is ever done, I suggest someone files a proposal to
>>>> remove submodules if the cost/benefit ratio is at odds. There is
>>>> nothing wrong with removing stuff that has been found problematic.
>>> I agree.
>>>
>>> I've added
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmo
>>> d
>>> -2Dwg_yang-2Dnext_issues_26&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kye
>>> K
>>> 3u4ZYiaQ2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU
>>> 6 1xSHgPlAT7owI&s=-kR4fUtXArQy0RwWb32DpT1bP4X_cNqt2zJVoC0JiX8&e=
>>>
>>> Rob
>>>
>>>> The motivation for submodules was that organizations maintaining
>>>> large modules with multiple people can do so without having to mess
>>>> around with tools like m4 scripts to produce a single module from 'snippets'
>>>> and to avoid integration surprises. But perhaps using m4 scripts and
>>>> decent version control systems (that can integrate and compile on
>>>> checkin) is indeed cheaper than having submodules part of the YANG
>>>> language itself.
>>>>
>>>> /js
>>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
>>> l
>>> man_listinfo_netmod&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYia
>>> Q
>>> 2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPl
>>> A T7owI&s=t7vGIH8ABuAm00e-bkSowD9eawModGq0N2OkjANtpYI&e=
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
>>> l
>>> man_listinfo_netmod&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYia
>>> Q
>>> 2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=esi8GPSc1xVjTt9SKxqzNHRDXT2P1h01a-Ueb
>>> n ST-Yo&s=PctKy3ij6W0TQs1NFp18SX8MQtYKeG9RxADh3cphcxU&e=
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
>>> l
>>> man_listinfo_netmod&d=DwIBAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYia
>>> Q
>>> 2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=RH3zvD2B8_s4uw1PXm_ka37vgz9_q2Rc87tD8
>>> K fZ9jA&s=XydU0vXE0AEg2FDE-kx_Ae6rOOAh5koxEeJ2cefgDNA&e=


From nobody Wed Aug 23 03:28:47 2017
Return-Path: 
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 B627A13236D for ; Wed, 23 Aug 2017 03:28:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Level: 
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 pP3_lidlWI1z for ; Wed, 23 Aug 2017 03:28:44 -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 713091321B6 for ; Wed, 23 Aug 2017 03:28:44 -0700 (PDT)
Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id v7NAPhmj011678; Wed, 23 Aug 2017 06:28:40 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049459.ppops.net-00191d01. with ESMTP id 2ch7q0s939-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Aug 2017 06:28:40 -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 v7NASdGV024151; Wed, 23 Aug 2017 06:28:40 -0400
Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v7NASWfx024050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 23 Aug 2017 06:28:34 -0400
Received: from gbcdccas03.intl.att.com (gbcdccas03.intl.att.com [135.76.180.11]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Wed, 23 Aug 2017 10:28:19 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; Wed, 23 Aug 2017 11:28:17 +0100
From: "Ivory, William" 
To: "'Robert Wilton'" , "'Juergen Schoenwaelder'" 
CC: "'Alex Campbell'" , "'netmod@ietf.org'" 
Thread-Topic: [netmod] Query about augmenting module from submodule in YANG 1.0
Thread-Index: AdMMOPUClm48yMKSSEeEurX4RbXaiADP5++AAAR9DaAACC3kAAAcrpQgAD0R+IAAAWwvgAAAa7wAAlFjp4AACPgnkABCnQKAABQ6ExD///QegP//4ixwgABFaYD//+mjQIAAIWGA///u20A=
Date: Wed, 23 Aug 2017 10:27:17 +0000
Deferred-Delivery: Wed, 23 Aug 2017 10:28:17 +0000
Message-ID: 
References:  <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com>   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>  <1503440878003.28215@Aviatnet.com>  <20170823072435.wv7pvndrm5du5q3x@elstar.local>    
In-Reply-To: 
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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
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-23_04:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1708230156
Archived-At: 
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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 10:28:47 -0000

WWVzLCB3ZSdsbCBjb25zaWRlciB0aGF0Lg0KDQpUaGFua3MsDQoNCldpbGxpYW0NCg0KLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJvYmVydCBXaWx0b24gW21haWx0bzpyd2lsdG9u
QGNpc2NvLmNvbV0gDQpTZW50OiAyMyBBdWd1c3QgMjAxNyAxMToyNg0KVG86IEl2b3J5LCBXaWxs
aWFtIDx3aWxsaWFtLml2b3J5QGludGwuYXR0LmNvbT47ICdKdWVyZ2VuIFNjaG9lbndhZWxkZXIn
IDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+DQpDYzogJ0FsZXggQ2FtcGJl
bGwnIDxBbGV4LkNhbXBiZWxsQEF2aWF0bmV0LmNvbT47ICduZXRtb2RAaWV0Zi5vcmcnIDxuZXRt
b2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gUXVlcnkgYWJvdXQgYXVnbWVudGlu
ZyBtb2R1bGUgZnJvbSBzdWJtb2R1bGUgaW4gWUFORyAxLjANCg0KDQoNCk9uIDIzLzA4LzIwMTcg
MTE6MDksIEl2b3J5LCBXaWxsaWFtIHdyb3RlOg0KPiBIaSBSb2JlcnQsDQo+DQo+IFByb2JhYmx5
IHNob3VsZG4ndCBoYXZlIG1lbnRpb25lZCBwYWNrYWdlcyBhcyB0aGF0J3MgcmVhbGx5IGEgZGl2
ZXJzaW9uIGZyb20gdGhlIG1haW4gcG9pbnQuICBXaGF0IHN1Ym1vZHVsZXMgcHJvdmlkZSBpcyBh
IHdheSB0byBkaWZmZXJlbnRpYXRlIFlBTkcgbm9kZXMgaW4gYSBzaW5nbGUgbmFtZXNwYWNlIHNv
IHRoYXQgd2hpbGUgc3RpbGwgYmVsb25naW5nIHRvIHRoYXQgc2luZ2xlIG5hbWVzcGFjZSwgc3Vi
c2V0cyBtYXkgYmUgaGFuZGxlZCBieSBkaWZmZXJlbnQgZGFlbW9ucyBzaW1wbHkgYnkgcm91dGlu
ZyBhY2NvcmRpbmcgdG8gc3VibW9kdWxlIGlkLiAgVGhhdCBrZWVwcyBhbGwgdGhlIGlkZW50aWZ5
aW5nIGxvZ2ljIHdpdGhpbiBZQU5HLg0KPg0KPiBPYnZpb3VzbHkgaWYgd2UgY291bGQgc3RhcnQg
YWZyZXNoLCB3ZSdkIHVzZSBzZXBhcmF0ZSBtb2R1bGVzIGZyb20gZGF5IG9uZS4gIEhvd2V2ZXIs
IHdlIGhhdmUgZXhpc3RpbmcgWUFORyB0aGF0IG5lZWRzIHRvIHJlbWFpbiB0byBiZSBiYWNrd2Fy
ZHMtY29tcGF0aWJsZSwgc28gdGhhdCBpc24ndCBhbiBvcHRpb24uDQpBbm90aGVyIHBvdGVudGlh
bCBzb2x1dGlvbiB0aGF0IGRvZXNuJ3QgdXNlIHN1YiBtb2R1bGVzIGNvdWxkIGJlIHRvIGRlZmlu
ZSBhIGJlc3Bva2UgWUFORyBleHRlbnNpb24gdG8gYW5ub3RhdGUgeW91ciBZQU5HIHNjaGVtYSB0
cmVlIHdpdGggYW55IG5lY2Vzc2FyeSByb3V0aW5nIGluZm9ybWF0aW9uIGZvciBpdCB0byBiZSBo
YW5kbGVkIGJ5IHRoZSBhcHByb3ByaWF0ZSBkYWVtb24uDQoNClRoYW5rcywNClJvYg0KDQo+IFJl
Z2FyZHMsDQo+DQo+IFdpbGxpYW0NCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g
RnJvbTogUm9iZXJ0IFdpbHRvbiBbbWFpbHRvOnJ3aWx0b25AY2lzY28uY29tXQ0KPiBTZW50OiAy
MyBBdWd1c3QgMjAxNyAxMDo0Ng0KPiBUbzogSXZvcnksIFdpbGxpYW0gPHdpbGxpYW0uaXZvcnlA
aW50bC5hdHQuY29tPjsgJ0p1ZXJnZW4gDQo+IFNjaG9lbndhZWxkZXInIDxqLnNjaG9lbndhZWxk
ZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+DQo+IENjOiAnQWxleCBDYW1wYmVsbCcgPEFsZXguQ2Ft
cGJlbGxAQXZpYXRuZXQuY29tPjsgJ25ldG1vZEBpZXRmLm9yZycgDQo+IDxuZXRtb2RAaWV0Zi5v
cmc+DQo+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBRdWVyeSBhYm91dCBhdWdtZW50aW5nIG1vZHVs
ZSBmcm9tIHN1Ym1vZHVsZSBpbiANCj4gWUFORyAxLjANCj4NCj4gSGkgV2lsbGlhbSwNCj4NCj4g
SSB0aGluayB0aGF0IHRoZXJlIG1pZ2h0IGJlIHNvbWUgZG93bnNpZGVzIHRvIHlvdXIgcHJvcG9z
ZWQgc29sdXRpb24gb2YgdXNpbmcgc3VibW9kdWxlcyAtIHdoaWNoIHlvdSBtYXkgaGF2ZSBhbHJl
YWR5IGNvbnNpZGVyZWQ6DQo+DQo+IDEpIEFsbCBvZiB0aGUgZGViaWFuIHBhY2thZ2VzIHdpbGwg
aGF2ZSB0byBiZSBpbnN0YWxsZWQgdG9nZXRoZXIgdG8gYWxsb3cgdGhlIFlBTkcgbW9kdWxlIHRv
IGJlIGJ1aWx0LCBvciBvdGhlcndpc2UgdGhlcmUgd2lsbCBiZSBtaXNzaW5nIHN1Ym1vZHVsZXMs
IGFuZCB0aGUgbW9kdWxlIHdpbGwgZmFpbCB0byBjb21waWxlIChzaW5jZSB0aGUgdG9wIGxldmVs
IG1vZHVsZSBtdXN0IGxpc3QgYWxsIGluY2x1ZGVkIHN1Yi1tb2R1bGVzKS4NCj4gMikgSXQgbWln
aHQgZW5kIHVwIHdpdGggeW91ciByZXF1aXJpbmcgdGlnaHQgdmVyc2lvbmluZyBvZiBhbGwgb2Yg
eW91ciBkZWJpYW4gcGFja2FnZXMgdG9nZXRoZXIgd2l0aCB0aGUgc2FtZSB2ZXJzaW9uIG51bWJl
ciwgb3Igb3RoZXJ3aXNlIHlvdSBtYXkgbmVlZCBncmVhdGVyIGNhcmUgb3ZlciBob3cgdGhlIHN1
Yi1tb2R1bGVzIGFyZSB1cGRhdGVkIGFuZCBkZXBlbmRlbmNpZXMgYXJlIGhhbmRsZWQuDQo+DQo+
IElmIHlvdXIgWUFORyB3YXMgYmVpbmcgZGVzaWduZWQgZnJvbSBzY3JhdGNoIHRoZW4gdXNpbmcg
c2VwYXJhdGUgWUFORyBtb2R1bGVzIG1heSBhbGxvdyBmb3IgYSBjbGVhbmVyIHNvbHV0aW9uIC0g
YnV0IEkgYXBwcmVjaWF0ZSB0aGF0IG1heSBub3QgaGVscCB5b3Ugd2l0aCB3aGVyZSB5b3UgYXJl
IG5vdy4NCj4NCj4gVGhhbmtzLA0KPiBSb2INCj4NCj4NCj4gT24gMjMvMDgvMjAxNyAwOToyNCwg
SXZvcnksIFdpbGxpYW0gd3JvdGU6DQo+PiBTb3JyeSAtIG1lYW50IERlYmlhbiBwYWNrYWdlcy4g
IFdlIGhhdmUgYSBsYXJnZSBZQU5HIG1vZHVsZSB0aGF0IHJlYWxseSBvdWdodCB0byBiZSBoYW5k
bGVkIGJ5IG11bHRpcGxlIGRhZW1vbnMsIHNvIHBsYW4gdG8gdXNlIHN1Ym1vZHVsZXMgc28gd2Ug
Y2FuIGlkZW50aWZ5IHRoZSBkaWZmZXJlbnQgcGFydHMgYW5kIHByb2Nlc3MgdGhlbSBpbiB0aGUg
cmlnaHQgcGxhY2UuICBSZWNvbWJpbmluZyBpbnRvIGEgc2luZ2xlIG1vZHVsZSB3b3VsZCBsb3Nl
IHRoYXQgZ3JhbnVsYXJpdHkuDQo+Pg0KPj4gV2lsbGlhbQ0KPj4NCj4+IC0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCj4+IFttYWlsdG86
ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlXQ0KPj4gU2VudDogMjMgQXVndXN0
IDIwMTcgMDg6MjUNCj4+IFRvOiBJdm9yeSwgV2lsbGlhbSA8d2lsbGlhbS5pdm9yeUBpbnRsLmF0
dC5jb20+DQo+PiBDYzogJ0FsZXggQ2FtcGJlbGwnIDxBbGV4LkNhbXBiZWxsQEF2aWF0bmV0LmNv
bT47ICdSb2JlcnQgV2lsdG9uJw0KPj4gPHJ3aWx0b25AY2lzY28uY29tPjsgJ25ldG1vZEBpZXRm
Lm9yZycgPG5ldG1vZEBpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBRdWVyeSBh
Ym91dCBhdWdtZW50aW5nIG1vZHVsZSBmcm9tIHN1Ym1vZHVsZSBpbiANCj4+IFlBTkcgMS4wDQo+
Pg0KPj4gV2hhdCBhcmUgcGFja2FnZXM/IEkgdGhpbmsgc3VibW9kdWxlcyBkZWNsYXJlIHRvIHdo
aWNoIG1vZHVsZSB0aGV5IGJlbG9uZywgbm8/IFBlcmhhcHMgeW91IGFyZSBkb2luZyBzb21ldGhp
bmcgdGhhdCBzdWJtb2R1bGVzIGRvIG5vdCBldmVuIHN1cHBvcnQuDQo+Pg0KPj4gL2pzDQo+Pg0K
Pj4gT24gV2VkLCBBdWcgMjMsIDIwMTcgYXQgMDc6MDg6MTBBTSArMDAwMCwgSXZvcnksIFdpbGxp
YW0gd3JvdGU6DQo+Pj4gLi4uICBleGNlcHQgdGhhdCBpZiB0aGUgd2hvbGUgcmVhc29uIGZvciBz
cGxpdHRpbmcgaW50byBzdWJtb2R1bGVzIHdhcyB0byBhbGxvdyB0aGUgc3VibW9kdWxlcyB0byBi
ZWxvbmcgdG8gZGlmZmVyZW50IHBhY2thZ2VzIGluIG91ciBzeXN0ZW0sIGNvbWJpbmluZyB0aGVt
IGJhY2sgYWdhaW4gaXMgbm90IHBvc3NpYmxlLiAgSSB3b3VsZG4ndCBiZSBzcGxpdHRpbmcgdGhl
bSB1bmxlc3MgSSBuZWVkZWQgdG8gZm9yIGdvb2QgcmVhc29uLg0KPj4+DQo+Pj4gV2lsbGlhbQ0K
Pj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBBbGV4IENhbXBi
ZWxsIFttYWlsdG86QWxleC5DYW1wYmVsbEBBdmlhdG5ldC5jb21dDQo+Pj4gU2VudDogMjIgQXVn
dXN0IDIwMTcgMjM6MjgNCj4+PiBUbzogSXZvcnksIFdpbGxpYW0gPHdpbGxpYW0uaXZvcnlAaW50
bC5hdHQuY29tPjsgJ1JvYmVydCBXaWx0b24nDQo+Pj4gPHJ3aWx0b25AY2lzY28uY29tPjsgJ25l
dG1vZEBpZXRmLm9yZycgPG5ldG1vZEBpZXRmLm9yZz4NCj4+PiBTdWJqZWN0OiBSZTogW25ldG1v
ZF0gUXVlcnkgYWJvdXQgYXVnbWVudGluZyBtb2R1bGUgZnJvbSBzdWJtb2R1bGUgDQo+Pj4gaW4g
WUFORyAxLjANCj4+Pg0KPj4+IEhpLA0KPj4+DQo+Pj4gSSdtIG5vdCBSb2IsIGJ1dCBteSB1bmRl
cnN0YW5kaW5nIGlzIHRoYXQgaWYgYSBtb2R1bGUgYXV0aG9yIHdhbnRlZCB0byBtaWdyYXRlIHRv
IFlBTkcgMi4wLCB0aGV5IGNvdWxkIG1lcmdlIHRoZWlyIHN1Ym1vZHVsZXMgYmFjayBpbnRvIHRo
ZSBtYWluIG1vZHVsZSAtIHdoaWNoIGlzIG5vdCBhIGRpZmZpY3VsdCBwcm9jZWR1cmUgYW5kIGRv
ZXMgbm90IGJyZWFrIGNvbXBhdGliaWxpdHkgd2l0aCBjbGllbnRzLg0KPj4+DQo+Pj4gQWxleA0K
Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBGcm9tOiBu
ZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgSXZvcnksIFdpbGxp
YW0gDQo+Pj4gPHdpbGxpYW0uaXZvcnlAaW50bC5hdHQuY29tPg0KPj4+IFNlbnQ6IFR1ZXNkYXks
IDIyIEF1Z3VzdCAyMDE3IDE6NDQgYS5tLg0KPj4+IFRvOiAnUm9iZXJ0IFdpbHRvbic7ICduZXRt
b2RAaWV0Zi5vcmcnDQo+Pj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIFF1ZXJ5IGFib3V0IGF1Z21l
bnRpbmcgbW9kdWxlIGZyb20gc3VibW9kdWxlIA0KPj4+IGluIFlBTkcgMS4wDQo+Pj4NCj4+PiBI
aSBSb2IsDQo+Pj4NCj4+PiBUaGF0IHdvdWxkIG1ha2UgaXQgdmVyeSBoYXJkIHRvIHVwZGF0ZSBl
eGlzdGluZyAxLnggWUFORyBtb2RlbHMgdG8gdXNlIG5ldyBmZWF0dXJlcyBpbiBZQU5HIDIueCBp
ZiB0aGV5IHVzZWQgc3VibW9kdWxlcy4gIE1heWJlIHRoYXQncyBzb21ldGhpbmcgdGhhdCBubyBv
bmUgd291bGQgZXZlciBjb25zaWRlciBkb2luZyBhbnl3YXksIG9yIG1heWJlIFlBTkcgMS4xIGFs
cmVhZHkgaGFzIHNpbWlsYXIgZGlmZmVyZW5jZXMgdG8gMS4wPyAgSSBoYWQgKHBlcmhhcHMgbmFp
dmVseSkgYXNzdW1lZCB0aGF0IHlvdSBjb3VsZCBtaWdyYXRlIGEgbmFtZXNwYWNlIC8gbW9kZWwg
ZnJvbSBZQU5HIDEuMCB0byAyLjA/DQo+Pj4NCj4+PiBSZWdhcmRzLA0KPj4+DQo+Pj4gV2lsbGlh
bQ0KPj4+DQo+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBuZXRtb2Qg
W21haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvYmVydCANCj4+
PiBXaWx0b24NCj4+PiBTZW50OiAyMSBBdWd1c3QgMjAxNyAxMToyNA0KPj4+IFRvOiBuZXRtb2RA
aWV0Zi5vcmcNCj4+PiBTdWJqZWN0OiBSZTogW25ldG1vZF0gUXVlcnkgYWJvdXQgYXVnbWVudGlu
ZyBtb2R1bGUgZnJvbSBzdWJtb2R1bGUgDQo+Pj4gaW4gWUFORyAxLjANCj4+Pg0KPj4+DQo+Pj4N
Cj4+PiBPbiAwOS8wOC8yMDE3IDE2OjEzLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgd3JvdGU6DQo+
Pj4+IE9uIFdlZCwgQXVnIDA5LCAyMDE3IGF0IDA1OjAxOjA5UE0gKzAyMDAsIExhZGlzbGF2IExo
b3RrYSB3cm90ZToNCj4+Pj4+IEkgcmVtZW1iZXIgdGhhdCBpbiBlYXJseSBzdGFnZXMgb2YgWUFO
RyB0aGVyZSB3YXMgc29tZSBpcnJhdGlvbmFsIA0KPj4+Pj4gZmVhciBvZiBpbnRyb2R1Y2luZyB0
b28gbWFueSBuYW1lc3BhY2VzLCBhbmQgc3VibW9kdWxlcyBtYXkgYmUgYSANCj4+Pj4+IGNvbnNl
cXVlbmNlIG9mIGl0LiBBcyB5b3Ugd3JpdGUsIHN1Ym1vZHVsZXMgcHJvdmlkZSBubyBiZW5lZml0
cyANCj4+Pj4+IHdoYXRzb2V2ZXIgaW4gdGVybXMgb2YgbW9kdWxhcml0eSwgYnV0IHRoZSBvdmVy
aGVhZCBpbiB0ZXJtcyBvZiANCj4+Pj4+IG1ldGFkYXRhLCBJQU5BIHJlZ2lzdHJhdGlvbiBldGMu
IGlzIHByZXR0eSBtdWNoIHRoZSBzYW1lIGFzIGZvciANCj4+Pj4+IG1vZHVsZXMuDQo+Pj4+IElu
IGNhc2UgWUFORyAyLjAgaXMgZXZlciBkb25lLCBJIHN1Z2dlc3Qgc29tZW9uZSBmaWxlcyBhIHBy
b3Bvc2FsIA0KPj4+PiB0byByZW1vdmUgc3VibW9kdWxlcyBpZiB0aGUgY29zdC9iZW5lZml0IHJh
dGlvIGlzIGF0IG9kZHMuIFRoZXJlIGlzIA0KPj4+PiBub3RoaW5nIHdyb25nIHdpdGggcmVtb3Zp
bmcgc3R1ZmYgdGhhdCBoYXMgYmVlbiBmb3VuZCBwcm9ibGVtYXRpYy4NCj4+PiBJIGFncmVlLg0K
Pj4+DQo+Pj4gSSd2ZSBhZGRlZA0KPj4+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv
bS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHViLmNvbV9uZXRtDQo+Pj4gbw0KPj4+IGQNCj4+PiAt
MkR3Z195YW5nLTJEbmV4dF9pc3N1ZXNfMjYmZD1Ed0lDQWcmYz1MRllaLW85X0hVTWVNVFNRaWN2
aklnJnI9cDhreQ0KPj4+IGUNCj4+PiBLDQo+Pj4gM3U0WllpYVEyWlBHcXdreVhtUWdCSDZyNWpw
WWlZV3pocUo0OCZtPWw3YzRJUEwwNDlBMmJWVk8xNGZ5Qk1seTIxMXgNCj4+PiBVDQo+Pj4gNiAx
eFNIZ1BsQVQ3b3dJJnM9LWtSNGZVdFhBclF5MFJ3V2IzMkRwVDFiUDRYX2NOcXQyekpWb0MwSmlY
OCZlPQ0KPj4+DQo+Pj4gUm9iDQo+Pj4NCj4+Pj4gVGhlIG1vdGl2YXRpb24gZm9yIHN1Ym1vZHVs
ZXMgd2FzIHRoYXQgb3JnYW5pemF0aW9ucyBtYWludGFpbmluZyANCj4+Pj4gbGFyZ2UgbW9kdWxl
cyB3aXRoIG11bHRpcGxlIHBlb3BsZSBjYW4gZG8gc28gd2l0aG91dCBoYXZpbmcgdG8gbWVzcyAN
Cj4+Pj4gYXJvdW5kIHdpdGggdG9vbHMgbGlrZSBtNCBzY3JpcHRzIHRvIHByb2R1Y2UgYSBzaW5n
bGUgbW9kdWxlIGZyb20gJ3NuaXBwZXRzJw0KPj4+PiBhbmQgdG8gYXZvaWQgaW50ZWdyYXRpb24g
c3VycHJpc2VzLiBCdXQgcGVyaGFwcyB1c2luZyBtNCBzY3JpcHRzIA0KPj4+PiBhbmQgZGVjZW50
IHZlcnNpb24gY29udHJvbCBzeXN0ZW1zICh0aGF0IGNhbiBpbnRlZ3JhdGUgYW5kIGNvbXBpbGUg
DQo+Pj4+IG9uDQo+Pj4+IGNoZWNraW4pIGlzIGluZGVlZCBjaGVhcGVyIHRoYW4gaGF2aW5nIHN1
Ym1vZHVsZXMgcGFydCBvZiB0aGUgWUFORyANCj4+Pj4gbGFuZ3VhZ2UgaXRzZWxmLg0KPj4+Pg0K
Pj4+PiAvanMNCj4+Pj4NCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fXw0KPj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+PiBuZXRtb2RAaWV0Zi5vcmcN
Cj4+PiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff
X3d3dy5pZXRmLm9yZ19tYQ0KPj4+IGkNCj4+PiBsDQo+Pj4gbWFuX2xpc3RpbmZvX25ldG1vZCZk
PUR3SUNBZyZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj1wOGt5ZUszdTRaWWkNCj4+PiBhDQo+
Pj4gUQ0KPj4+IDJaUEdxd2t5WG1RZ0JINnI1anBZaVlXemhxSjQ4Jm09bDdjNElQTDA0OUEyYlZW
TzE0ZnlCTWx5MjExeFU2MXhTSGdQDQo+Pj4gbCBBIFQ3b3dJJnM9dDd2R0lIOEFCdUFtMDBlLWJr
U293RDllYXdNb2RHcTBOMk9rakFOdHBZSSZlPQ0KPj4+DQo+Pj4gX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+
Pj4gbmV0bW9kQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t
L3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWENCj4+PiBpDQo+Pj4gbA0KPj4+IG1h
bl9saXN0aW5mb19uZXRtb2QmZD1Ed0lGQXcmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9cDhr
eWVLM3U0WllpDQo+Pj4gYQ0KPj4+IFENCj4+PiAyWlBHcXdreVhtUWdCSDZyNWpwWWlZV3pocUo0
OCZtPWVzaThHUFNjMXhWalR0OVNLeHF6TkhSRFhUMlAxaDAxYS1VZQ0KPj4+IGIgbiBTVC1ZbyZz
PVBjdEt5M2lqNlcwVFFzMU5GcDE4U1g4TVF0WUtlRzlSeEFEaDNjcGhjeFUmZT0NCj4+Pg0KPj4+
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gbmV0
bW9kIG1haWxpbmcgbGlzdA0KPj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4+IGh0dHBzOi8vdXJsZGVm
ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21hDQo+
Pj4gaQ0KPj4+IGwNCj4+PiBtYW5fbGlzdGluZm9fbmV0bW9kJmQ9RHdJQkFnJmM9TEZZWi1vOV9I
VU1lTVRTUWljdmpJZyZyPXA4a3llSzN1NFpZaQ0KPj4+IGENCj4+PiBRDQo+Pj4gMlpQR3F3a3lY
bVFnQkg2cjVqcFlpWVd6aHFKNDgmbT1SSDN6dkQyQjhfczR1dzFQWG1fa2EzN3ZnejlfcTJSYzg3
dEQNCj4+PiA4IEsgZlo5akEmcz1YeWRVMHZYRTBBRWcyRkRFLWt4X0FlNnJPT0FoNWtveEVlSjJj
ZWZnRE5BJmU9DQoNCg==


From nobody Wed Aug 23 03:53:20 2017
Return-Path: 
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 5851A132946 for ; Wed, 23 Aug 2017 03:53:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Oc6SO0UNwTiw for ; Wed, 23 Aug 2017 03:53:15 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 120451321B6 for ; Wed, 23 Aug 2017 03:53:15 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id DAD4B1820E79; Wed, 23 Aug 2017 12:53:50 +0200 (CEST)
Received: from localhost (unknown [195.113.220.126]) by trail.lhotka.name (Postfix) with ESMTPSA id 1FFC01820E6E; Wed, 23 Aug 2017 12:53:46 +0200 (CEST)
From: Ladislav Lhotka 
To: "t.petch" , "Acee Lindem \(acee\)" ,  "Ivory\, William" , netmod@ietf.org, Andy Bierman , Robert Wilton 
In-Reply-To: <044b01d31bf4$d3b37500$4001a8c0@gateway.2wire.net>
References:  <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com>  <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com>   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>   <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com> <044b01d31bf4$d3b37500$4001a8c0@gateway.2wire.net>
Mail-Followup-To: "t.petch" , "Acee Lindem \(acee\)" , "Ivory\, William" , netmod@ietf.org, Andy Bierman , Robert Wilton 
Date: Wed, 23 Aug 2017 12:53:33 +0200
Message-ID: <87vale1ro2.fsf@cesnet.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Pattern statements [was Re: 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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 10:53:18 -0000

"t.petch"  writes:

> ----- Original Message -----
> From: "Robert Wilton" 
> Sent: Monday, August 21, 2017 4:14 PM
>
>> That makes sense.
>>
>> The other thing that I think that we have got wrong is modelling regex
>> pattern statements.  I think that it would be much better if these
> were
>> written to be less exhaustive and much simpler.
>>
>> E.g. the "route distinguisher" pattern in
>> draft-ietf-rtgwg-routing-types-09 is defined as this:
>>
>>           pattern
>>             '(0:(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
>>           +     '6[0-4][0-9]{3}|'
>>           +     '[0-5]?[0-9]{0,3}[0-9]):(429496729[0-5]|'
>>           +     '42949672[0-8][0-9]|'
>>           +     '4294967[01][0-9]{2}|429496[0-6][0-9]{3}|'
>>           +     '42949[0-5][0-9]{4}|'
>>           +     '4294[0-8][0-9]{5}|429[0-3][0-9]{6}|'
>>           +     '42[0-8][0-9]{7}|4[01][0-9]{8}|'
>>           +     '[0-3]?[0-9]{0,8}[0-9]))|'
>>           + '(1:((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|'
>>           +     '25[0-5])\.){3}([0-9]|[1-9][0-9]|'
>>           +     '1[0-9]{2}|2[0-4][0-9]|25[0-5])):(6553[0-5]|'
>>           +     '655[0-2][0-9]|'
>>           +     '65[0-4][0-9]{2}|6[0-4][0-9]{3}|'
>>           +     '[0-5]?[0-9]{0,3}[0-9]))|'
>>           + '(2:(429496729[0-5]|42949672[0-8][0-9]|'
>>           +     '4294967[01][0-9]{2}|'
>>           +     '429496[0-6][0-9]{3}|42949[0-5][0-9]{4}|'
>>           +     '4294[0-8][0-9]{5}|'
>>           +     '429[0-3][0-9]{6}|42[0-8][0-9]{7}|4[01][0-9]{8}|'
>>           +     '[0-3]?[0-9]{0,8}[0-9]):'
>>           +     '(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
>>           +     '6[0-4][0-9]{3}|'
>>           +     '[0-5]?[0-9]{0,3}[0-9]))|'
>>           + '(6(:[a-fA-F0-9]{2}){6})|'
>>           + '(([3-57-9a-fA-F]|[1-9a-fA-F][0-9a-fA-F]{1,3}):'
>>           +     '[0-9a-fA-F]{1,12})';
>>         }
>>
>> But I think that it would be much easier to read, and quite possibly
>> more performant to execute, if the pattern regex was written something
>> like the following:
>>
>>   pattern:
>>      '(0:[0-9]{1,5}:[0-9]{1,10})|
>>       (1:([0-9]{1,3}\.){4}:[0-9]{1,5})|
>>       (2:[0-9]{1,10}:0:[0-9]{1,5})|
>>       (6(:[a-fA-F0-9]{2}){6})';
>>
>> Of course, this would allow more invalid values, but most servers
> would
>> be expected to reject those when it converts them into an internal
>> binary format any way.
>>
>> What do you, and others, think?
>
> Simplify!
>
> Bear in mind that the regex for an IPv6 address was wrong for a long
> time in base YANG before anyone noticed - it was just too complex.

Why was it wrong? Just because it was too complex?

>
> And ABNF learnt long ago that just because something could be expressed
> in code does not mean that it is a good idea to do so.  If a simple
> English statement replaces many lines of ABNF, then that is a good
> tradeoff.

Well, YANG models are also intended to be read by tools that so far
don't understand English statements. Concerning human users, the easiest
thing might be to refer to a corresponding RFC, which the descriptions
already do.

>
> Pragmatically I am not sure what the cutoff for complexity should be but
> it should be less than we have now.
>
> Paradoxically, given the original thread, the time when large
> expressions may work ok is when they have a 'sub-module' like structure,
> when I can look at a group of lines in isolation and form a view of what
> it does then move on to the next group and so on, building up an overall
> picture piece by piece.

Of course, regular expression languages are notorically human
unfriendly, no matter what flavour we take. The ability to build them
step by step from reusable pieces, e.g. using non-terminals, would
certainly help.

Lada

>
> Tom Petch
>
>> Thanks,
>> Rob
>>
>>
>> On 21/08/2017 15:01, Acee Lindem (acee) wrote:
>> > Hi William, Rob, Andy,
>> >
>> > Given their limited usefulness and the detriments, perhaps we should
>> > discourage the creation of new submodules in RFC6087Bis.
>> >
>> > Thanks,
>> > Acee
>> >
>> > On 8/21/17, 9:44 AM, "netmod on behalf of Ivory, William"
>> > 
> wrote:
>> >
>> >> Hi Rob,
>> >>
>> >> That would make it very hard to update existing 1.x YANG models to
> use
>> >> new features in YANG 2.x if they used submodules.  Maybe that's
> something
>> >> that no one would ever consider doing anyway, or maybe YANG 1.1
> already
>> >> has similar differences to 1.0?  I had (perhaps naively) assumed
> that you
>> >> could migrate a namespace / model from YANG 1.0 to 2.0?
>> >>
>> >> Regards,
>> >>
>> >> William
>> >>
>> >> -----Original Message-----
>> >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Robert
> Wilton
>> >> Sent: 21 August 2017 11:24
>> >> To: netmod@ietf.org
>> >> Subject: Re: [netmod] Query about augmenting module from submodule
> in
>> >> YANG 1.0
>> >>
>> >>
>> >>
>> >> On 09/08/2017 16:13, Juergen Schoenwaelder wrote:
>> >>> On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka wrote:
>> >>>> I remember that in early stages of YANG there was some irrational
>> >>>> fear of introducing too many namespaces, and submodules may be a
>> >>>> consequence of it. As you write, submodules provide no benefits
>> >>>> whatsoever in terms of modularity, but the overhead in terms of
>> >>>> metadata, IANA registration etc. is pretty much the same as for
>> >>>> modules.
>> >>> In case YANG 2.0 is ever done, I suggest someone files a proposal
> to
>> >>> remove submodules if the cost/benefit ratio is at odds. There is
>> >>> nothing wrong with removing stuff that has been found problematic.
>> >> I agree.
>> >>
>> >> I've added
>> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmod-2
> Dw
>> >>
> g_yang-2Dnext_issues_26&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYi
> aQ
>> >>
> 2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7
> ow
>> >> I&s=-kR4fUtXArQy0RwWb32DpT1bP4X_cNqt2zJVoC0JiX8&e=
>> >>
>> >> Rob
>> >>
>> >>> The motivation for submodules was that organizations maintaining
> large
>> >>> modules with multiple people can do so without having to mess
> around
>> >>> with tools like m4 scripts to produce a single module from
> 'snippets'
>> >>> and to avoid integration surprises. But perhaps using m4 scripts
> and
>> >>> decent version control systems (that can integrate and compile on
>> >>> checkin) is indeed cheaper than having submodules part of the YANG
>> >>> language itself.
>> >>>
>> >>> /js
>> >>>
>> >> _______________________________________________
>> >> netmod mailing list
>> >> netmod@ietf.org
>> >>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailma
> n_
>> >>
> listinfo_netmod&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqw
> ky
>> >>
> XmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7owI&s=t7
> vG
>> >> IH8ABuAm00e-bkSowD9eawModGq0N2OkjANtpYI&e=
>> >>
>> >> _______________________________________________
>> >> 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 mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Aug 23 03:55:03 2017
Return-Path: 
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 44B22132BE6; Wed, 23 Aug 2017 03:55:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 6yqdHsHciM7G; Wed, 23 Aug 2017 03:54:58 -0700 (PDT)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2901E132946; Wed, 23 Aug 2017 03:54:57 -0700 (PDT)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7NAsjFx031520; Wed, 23 Aug 2017 11:54:45 +0100
Received: from 950129200 (196.252.114.87.dyn.plus.net [87.114.252.196]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v7NAse0g031495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Aug 2017 11:54:45 +0100
Reply-To: 
From: "Adrian Farrel" 
To: "'Carl Moberg \(camoberg\)'" 
Cc: "'Tianran Zhou'" , , 
Date: Wed, 23 Aug 2017 11:54:37 +0100
Message-ID: <046b01d31bfe$3958a430$ac09ec90$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdMb/cWLoe/agY+QSUOLBURNF8jkiA==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-23276.006
X-TM-AS-Result: No--18.242-10.0-31-10
X-imss-scan-details: No--18.242-10.0-31-10
X-TMASE-MatchedRID: yebcs53SkkAwJ6xbTjBa5nBRIrj8R47FC/ExpXrHizwwplGJ7NxS0yFS iPJ1ANBwZzS8ZvLgTL7FWxtOlTkSH/GU4m5A0eV9jNvYZHpO13escK/K2DlvjhrUQ7A9MrmGbwI uAyuB59z2q691x1hzEuIBOCyLid9eE0atn7xLb21jHWM8krL4PHJ8yHMhx0aa31GU/N5W5BDEZK HidzhUXFQrQWfNw93S+IzjYvoE5ups/McbADTE9hrnPqLp7GEA8A6q6O7uVrWbcaUfWN//FKpG5 DG7+eX49ZhzYUzjfq3El/ZgS/rppqjmA6eZ5vSkxuvd33/I/WR+K68qL2G5pmecrqZc3vabpdAU S79bY2P3Cch9qVOlxiDUpjC7ZebTHdkkLawA7SETfrsx9o3DwyQqzcugG1CVDYbe/PyX8gRjJEI JQgmokDGi8cBs2wIG+wpG/M7VPBc6TM2EjQ3+Mi1Hx9UxMGjdxJPgzHrfYvrSYAzZ6KmqWmyVWb I4AesfLEIJ3FoU1ViFDHJl22isXIxa53hcnHRIrK1919cGzDJQLBvX11RpSci9AjK6C8p1Ggdt5 59CgdQjQfvQ+LHAjA/T5w0N7FJJaRefeuTiJNyJZq1lQ6Po67/I3arxTrvio8y5CypU1eFdB6ml nUbtbdDszvlp5NqqsxaW9sBm3nsyquK3NWAbFhNEPNwNrw/rZijLrBI/sgWqG/oAv7EtlUaFMIz /3JwCx880dMw/la/YVWK8wmsL7b4OJaSfu96X+mHRL3uzOiJA8JZETQujwp4rd07+pHvAIwKXTP 7P9qXY0jno/xmKIX/y39vn+l1htnydkaPfO+OeAiCmPx4NwFkMvWAuahr8+gD2vYtOFhgqtq5d3 cxkNQP90fJP9eHt
Archived-At: 
Subject: Re: [netmod] [OPSAWG] Cross-post to Netmod for LC comments//FW: WG LC for Service Models Explained
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 10:55:01 -0000

Hi Carl,

I'm in the process of updating the document and wanted to let you know =
what changes are being made.

>>>  - The term =E2=80=9CNetwork Service Model=E2=80=9D in RFC 8199 is =
intended to cover both
>>>    "Customer Service Model=E2=80=9D as well as =E2=80=9CService =
Delivery Model=E2=80=9D as defined
>>>    in draft-ietf-opsawg-service-model-explained. At the time of the =
first
>>>    revision of what was
>>> draft-bogdanovic-netmod-yang-model-classification
>>>    we discussed further splitting "Network Service Model=E2=80=9D =
into smaller
>>>    components, but decided against it since we did not see a =
consensus on
>>>    what that split would look like. I believe the authors here is
>>>    suggesting such a further split.
>>
>> I think that an "issue" with RFC 8199 is that is appears to imply =
that the
>> "Network Service Module" (sic) it defines is used on a specific =
interface rather
>> than simply being the classification of "all modules used north of =
this point". This
>> our draft is doing slightly more than partitioning the =
classification. The last couple
>> of rounds of edits to what became 8199 were working with Dean to =
slightly
>> soften thee language used to make this more consistent.
>=20
> Right, and the reason why we took the "all modules used north of this =
point=E2=80=9D is
> that we have not seen any sign of convergence around abstractions into =
smaller
> components. In short: implementations of =E2=80=9CYANG for =
services=E2=80=9D is currently all
> over the map.
>=20
>> But see below...
>>
>>>    There is one specific passage in this draft that I would suggest =
could
>>>    use rephrasing if the authors agree to the above:
>>>
>>> """
>>>   As previously noted, [I-D.ietf-netmod-yang-model-classification]
>>>   provides a classification of YANG data models.  It introduces the
>>>   term "Network Service YANG Module" to identify the type of model =
used
>>>   to "describe the configuration, state data, operations and
>>>   notifications of abstract representations of services implemented =
on
>>>   one or multiple network elements."  These are service delivery =
models
>>>   as described in this document, that is, they are the models used =
on
>>>   the interface between the Service Orchestrator or OSS/BSS and the
>>>   Network Orchestrator as shown in Figure 3.
>>> """
>>
>> You suggest this could be rephrased, but don't suggest how:-)
>> I just checked 8199 and I see that the quote we have is still =
accurate.
>>
>> I am wondering what it is specifically about this text that worries =
you. Again, this
>> may come back to the use of a module on a functional interface. I =
read 8199 as
>> saying that the "Network Service YANG Modules are used by the OSS/BSS =
in
>> talking to the network elements (o perhaps Controllers?) to configure =
the
>> network to deliver the service. Am I wrong?
>>
>> If I'm right in my reading we are not "splitting" the classification, =
but introducing
>> a new class that lives further north (where the atmosphere is thinner =
and the
>> temperature colder)
>=20
>  I think at the core of the feedback (and sorry that it took two =
rounds of email to
> make it shorter :-) is that in 8199 the Service Orchestrator is =
assumed to be an
> integral part of OSS/BSS. More below.

OK. This is much clearer to me now, and leads into the stuff below.

>>> - And this gets to my second point of feedback. Figure 4. in the =
draft
>>>   seems to suggest that the "Service Orchestrator" is an entity =
separate
>>>   from the "Operations and Business Support Systems (OSS/BSS)".
>>
>> I want to jump into this paragraph at once just to say "no, no, no!"
>> This figure (like most I draw in ASCII these days) displays =
functional components
>> not physical entities.
>> How you choose to implement is entirely up to you.
>> It seems likely (to me) that the interface between customer and =
operator is
>> externally exposed (but not necessarily realised using RESTconf).
>=20
>  This is perhaps also at the core of the feedback. I have never seen =
an
> implementation/architecture with a functionally distinct Service =
Orchestrator
> (outside of OSS/BSS) exposed directly to customers. There is usually =
at least
> something like an order manager (as part of the OSS/BSS) between the =
customer
> and the service orchestrator. Even in the instances of self-service =
portals (which
> are naturally located very close to the network) there is at least =
some notion of
> pricing and billing involved.

Funny that I find I agree and disagree :-)
You are completely right about the status quo. Also about the importance =
of commercial tools as part of the system.
On the other hand, we (well, I) don't want to inhibit developmental =
approaches. For example, a customer might (within some pre-established =
bounds) be allowed to request and modify services directly and have the =
commercial repercussions follow on.

All that said we converge below...

>> It does not seem obvious to me that the Service Orchestrator and the =
OSS/BSS
>> are separate blobs, except to note that the OSS/BSS deployed today =
does not
>> support the Customer Service YANG Modules and so the extent to which =
it
>> provides "service orchestration" is limited.
>=20
> Well, a common pattern is to have the order manager put in orders for =
technical
> service activation from a service orchestrator. The uptake of YANG =
seems to be
> mostly in the interface between the order manager (an integral part of =
OSS/BSS)
> and the service orchestrator.
>=20
>> I might also claim that an OSS/BSS possibly operates on a single =
network where
>> the orchestration of a service *might* involve the coordination of =
more than one
>> network.
>=20
> Hmm, since the actual business is accounted for in the OSS/BSS =
(including rating,
> charging, billing) I=E2=80=99m not sure how a multi-network service =
orchestrator outside of
> an OSS/BSS context would work.
>=20
>>> And also that
>>>   Customers (as defined) in Section 2 interface directly with that =
entity.
>>>   This is a very unusual construct, in the sense that:
>>>    o The common taxonomomy from e.g. TMForum would classify a =
service
>>>      orchestrator as a part of the OSS/BSS stack, since...
>>>    o The successful activation of a service includes many parts of =
the
>>>      OSS/BSS-stack including operational readiness (are there =
physical
>>>      ports available), billing management (is the customer allowed =
to
>>>      perform e.g. this resource expansion), and assurance (changed
>>>      services require new assurance parameters). This makes it hard
>>>      to separate out a Customer interface to service orchestration
>>>      only, separate from the OSS/BSS stack.
>>
>> I am not (overly) familiar with the TMF work, however, your text =
"TMForum
>> would classify a service orchestrator as a part of the OSS/BSS stack" =
suggests the
>> acceptance of service orchestration as "a thing". If you were writing =
code, you
>> *might* write a separate module (even library) to handle service =
orchestration,
>> and maintain that as a separate module from billing management, etc. =
That does
>> not make them completely separate, but does result in them showing as
>> separate functional components in the "OSS/BSS stack.=E2=80=9D
>=20
> Exactly right. The term =E2=80=9COSS/BSS=E2=80=9D itself as =
I=E2=80=99m used to hearing it is a means of
> grouping a (huge) set of functions under a common label.
>=20
>>> This an informational draft and as such is for general information, =
and
>>> not  necessarily intended to represent community consensus or
>>> recommendation, just like 8119.
>>
>> I choose to disagree! 8199 had WG and IETF last call. It has =
community
>> consensus.
>=20
> True. It was a heavy-handed attempt at pushing on the fact that =
we=E2=80=99re not
> writing standards here, but merely working to inform. But =
you=E2=80=99re absolutely right
> that WG work items reflect consensus.
>=20
>> The intention of this draft is that it, too, will have IETF community =
consensus.
>> But be aware that we are neither trying to force that consensus, nor =
dictate the
>> terminology. What we are doing is trying to answer the (often =
repeated)
>> question: "Where do L2SM and L3SM fit into the picture since they =
don't seem to
>> be intended to talk to network devices or controllers?=E2=80=9D
>=20
> Makes sense. And in my simplistic (8199-infused) mind, e.g. =
ietf-l2vpn-
> svc@2016-08-19.yang is a great example of a Network Service Module. So =
far so
> good ;-) Whether we can come up with further classification to =
robustly capture
> the "scope of and purpose of an IETF service model=E2=80=9D is next.
>=20
>>> But I would suggest the document could be
>>> improved by elaborating  the point of the separation of the =
orchestrator
>>> and the BSS/OSS and the resulting difference in module types.
>>
>> I could certainly add text around Figure 4 to say "...this =
illustrates a functional
>> architecture and an implementation might not choose to make the =
distinctions
>> shown such that separations and interfaces illustrated might fall =
within a single
>> implementation." Would that help?
>=20
>  With the further elaboration above, would this make sense?

OK. We're working with that figure.

=20
>           +---------------+
>           |               |
>           |   Customers   |
>           |               |
>           +---------------+
>=20
>       - - - - - - - - - - - - - -
>      Customer Service YANG Modules
>=20
>       +-------------------------------------------------------------+
>       |     Operations and Business Support System (OSS/BSS)        |
>       |              +--------------------------+                   |
>       |              |   Service Orchestrator   |                   |
>       |              +--------------------------+                   |
>       +-------------------------------------------------------------+
>=20
>      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>      Network Service YANG Modules
>=20
>     +------------+   +-------------+   +-------------+   =
+-------------+
>     |            |   |             |   |             |   |             =
|
>     |  - L2VPN   |   |   - L2VPN   |   |    EVPN     |   |    L3VPN    =
|
>     |  - VPWS    |   |   - VPLS    |   |             |   |             =
|
>     |            |   |             |   |             |   |             =
|
>     +------------+   +-------------+   +-------------+   =
+-------------+
>=20
>      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>      Network Element YANG Modules
>=20
>      +------------+  +------------+  +-------------+  +------------+
>      |            |  |            |  |             |  |            |
>      |    MPLS    |  |    BGP     |  | IPv4 / IPv6 |  |  Ethernet  |
>      |            |  |            |  |             |  |            |
>      +------------+  +------------+  +-------------+  +------------+
>=20
>        L2VPN: Layer 2 Virtual Private Network
>        L3VPN: Layer 3 Virtual Private Network
>        VPWS: Virtual Private Wire Service
>        VPLS: Virtual Private LAN Service

Cheers,
Adrian


From nobody Wed Aug 23 04:52:19 2017
Return-Path: 
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 745A81326EC for ; Wed, 23 Aug 2017 04:52:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 yyCEm3JheC18 for ; Wed, 23 Aug 2017 04:52:16 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF1D01321DC for ; Wed, 23 Aug 2017 04:52:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id A2FCD1403A44; Wed, 23 Aug 2017 13:52:13 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ik-B2HT2CyC4; Wed, 23 Aug 2017 13:52:13 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 764CC1403A43; Wed, 23 Aug 2017 13:52:13 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id edI57olMZPxQ; Wed, 23 Aug 2017 13:52:13 +0200 (CEST)
Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 51CB41403A3D; Wed, 23 Aug 2017 13:52:13 +0200 (CEST)
To: Robert Wilton 
References:  <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com>  <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com>   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>   <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com>
From: Vladimir Vassilev 
Cc: "netmod@ietf.org" 
Message-ID: <5929631c-e51d-ae66-52d1-cbc87ca3506b@transpacket.com>
Date: Wed, 23 Aug 2017 13:52:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0
MIME-Version: 1.0
In-Reply-To: <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Pattern statements [was Re: 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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 11:52:18 -0000

On 08/21/2017 05:14 PM, Robert Wilton wrote:

> Hi Acee,
>
> That makes sense.
>
> The other thing that I think that we have got wrong is modelling regex 
> pattern statements.  I think that it would be much better if these 
> were written to be less exhaustive and much simpler.
>
> E.g. the "route distinguisher" pattern in 
> draft-ietf-rtgwg-routing-types-09 is defined as this:
>
>           pattern
>             '(0:(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
>           +     '6[0-4][0-9]{3}|'
>           +     '[0-5]?[0-9]{0,3}[0-9]):(429496729[0-5]|'
>           +     '42949672[0-8][0-9]|'
>           +     '4294967[01][0-9]{2}|429496[0-6][0-9]{3}|'
>           +     '42949[0-5][0-9]{4}|'
>           +     '4294[0-8][0-9]{5}|429[0-3][0-9]{6}|'
>           +     '42[0-8][0-9]{7}|4[01][0-9]{8}|'
>           +     '[0-3]?[0-9]{0,8}[0-9]))|'
>           + '(1:((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|'
>           +     '25[0-5])\.){3}([0-9]|[1-9][0-9]|'
>           +     '1[0-9]{2}|2[0-4][0-9]|25[0-5])):(6553[0-5]|'
>           +     '655[0-2][0-9]|'
>           +     '65[0-4][0-9]{2}|6[0-4][0-9]{3}|'
>           +     '[0-5]?[0-9]{0,3}[0-9]))|'
>           + '(2:(429496729[0-5]|42949672[0-8][0-9]|'
>           +     '4294967[01][0-9]{2}|'
>           +     '429496[0-6][0-9]{3}|42949[0-5][0-9]{4}|'
>           +     '4294[0-8][0-9]{5}|'
>           +     '429[0-3][0-9]{6}|42[0-8][0-9]{7}|4[01][0-9]{8}|'
>           +     '[0-3]?[0-9]{0,8}[0-9]):'
>           +     '(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
>           +     '6[0-4][0-9]{3}|'
>           +     '[0-5]?[0-9]{0,3}[0-9]))|'
>           + '(6(:[a-fA-F0-9]{2}){6})|'
>           + '(([3-57-9a-fA-F]|[1-9a-fA-F][0-9a-fA-F]{1,3}):'
>           +     '[0-9a-fA-F]{1,12})';
>         }
>
> But I think that it would be much easier to read, and quite possibly 
> more performant to execute, if the pattern regex was written something 
> like the following:
>
>  pattern:
>     '(0:[0-9]{1,5}:[0-9]{1,10})|
>      (1:([0-9]{1,3}\.){4}:[0-9]{1,5})|
>      (2:[0-9]{1,10}:0:[0-9]{1,5})|
>      (6(:[a-fA-F0-9]{2}){6})';
>
> Of course, this would allow more invalid values, but most servers 
> would be expected to reject those when it converts them into an 
> internal binary format any way.
>
> What do you, and others, think?
You still need the 
|(([3-57-9a-fA-F]|[1-9a-fA-F][0-9a-fA-F]{1,3}):[0-9a-fA-F]{1,12}) in the 
end to not reject valid values though.

IMO a pattern statement has value if it absolutely defines the set of 
valid strings. In general I do not see the benefit of pattern statements 
that do not reject all invalid string instances. I prefer the original 
pattern or none at all.

Vladimir

> Thanks,
> Rob


From nobody Wed Aug 23 05:07:40 2017
Return-Path: 
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 C434A1321AF for ; Wed, 23 Aug 2017 05:07:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 NPGWd1nGD1wK for ; Wed, 23 Aug 2017 05:07:36 -0700 (PDT)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (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 E92C3132954 for ; Wed, 23 Aug 2017 05:07:35 -0700 (PDT)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id C0FE51AB228 for ; Wed, 23 Aug 2017 06:07:34 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id 0c7X1w00m2SSUrH01c7aKi; Wed, 23 Aug 2017 06:07:34 -0600
X-Authority-Analysis: v=2.2 cv=ELV26xRC c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=KeKAF7QvOSUA:10 a=NEAV23lmAAAA:8 a=48vgC7mUAAAA:8 a=j3Z76cjpAAAA:8 a=2GAT9EY_w8f1hJmOUrQA:9 a=fP-I0mXSipU2HYux:21 a=LrlotqciyM6jJKf6:21 a=QEXdDO2ut3YA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=9ZYBcOd_X9kS2t7VFny2:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:References:Cc:To:Subject:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=r9BEiu5GbQ+Fb4hRn0peE3BDk1iWjHQlIiIFq4gmz7Q=; b=pNaLdurue5JG+wxGbR1vnWrZQt XrQMPv0dhYBFHaOx08aAW+hQ9gjBnboZWgMUSiBiiwldKm7Fvrwf7MQfziAHrBKdLZpNnUDzzkGux X1gact/ZaKnUUh+dE2FYhCwPw;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:43340 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dkURW-003b3e-U7; Wed, 23 Aug 2017 06:07:31 -0600
From: Lou Berger 
To: Juergen Schoenwaelder 
Cc: netmod@ietf.org
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local>
Message-ID: <95c65e38-a117-592d-5c3f-06d31f8845fa@labn.net>
Date: Wed, 23 Aug 2017 08:07:28 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170823061709.prezywubi7b32w7i@elstar.local>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dkURW-003b3e-U7
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:43340
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 12:07:39 -0000

Juergen,


On August 23, 2017 2:17:43 AM Juergen Schoenwaelder
 wrote:

> My preference is to have the guidelines say what people should do,
> namely design NMDA models. I would prefer to keep any transition
> aspects out of the guidelines.

Well, this approach works for those who are deeply enmeshed in netmod
and the IETF, it doesn't help those designing models/solutions during
the current transition period.  IMO we can't forget about this important
class of model developers and users.

> If people want to include transition
> aspects, it should be in the appendix (i.e., easy to remove / ignore
> later on).
>
I don't see a material difference here.  Either way the document needs
to be updated. See below for a specific proposed wording update.

> I understand that there is a timing issue. The question is what you
> mean with "NMDA solution makes it to publication (request)". If you
> mean the core NMDA document, this is pretty much in reach and keeping
> this guidelines document on hold until then may be an option. If you
> mean the complete solution set, including model updates and moving the
> protocol extensions in NETCONF to publication request, then this may
> take a bit more time.
>
I mean the time when implementors can reasonably be told that the old
way has been replaced by a fully defined (and able to be implemented)
NMDA solution.  I think includes both netconf and restconf NMDA
definitions.  I don't think it's reasonable to require implementation of
drafts that are in-flux.



> /js
>
> On Tue, Aug 22, 2017 at 04:32:14PM -0400, Lou Berger wrote:
>> Kent/WG,
>>
>>     This seems a bit terse to me and not provide needed guidance during
>> the current transition period.  I understood  the discussion ended up 
>> with the options being to either (1) provide the guidance as a
>> standalone document, e.g., (a)-(s) in draft-dsdt-nmda-guidelines, with a
>> pointer to it from 6087bis or (2) just move those sections to 6087 bis. 
>> Either way, we'll need a new bis once the full NMDA solution makes it to
>> publication (request).
>>
>> I thought the plan was to do (s).  If so, we need the full text. 
>> Looking at the current repo
>> (https://github.com/netmod-wg/datastore-dt/blob/master/guidelines/guidelines.txt)
>> it would be:
>>
>>     4.23 Operational Data
>>
>>     The following guidelines are meant to help modelers develop
>>     YANG models that will maximize the utility of the model with
>>     both current implementations and NMDA-capable implementations
>>     [draft-ietf-netmod-revised-datastores].
>>
remove (a) and re-letter rest of list
>>     (a) New models and models that are not concerned with the
>>     operational state of configuration information SHOULD
>>     immediately be structured to be NMDA-compatible.

Add:
   The remaining options MAY be followed during the time that
   NMDA mechanisms are being defined.  These options will be
   removed in a future update of this document once this definition
   is complete.

Does this work for you?  Moving it to an appendix just makes it harder
for the reader and, again, the document needs to be revised either way
in the future.

Lou

>>
>>     (b) Models that require immediate support for "in use" and
>>     "system created" information SHOULD be structured for NMDA.  A
>>     non-NMDA version of these models SHOULD exist, either an
>>     existing model or a model created either by hand or with
>>     suitable tools that mirror the current modeling strategies.
>>     Both the NMDA and the non-NMDA modules SHOULD be published in
>>     the same document, with NMDA modules in the document main body
>>     and the non-NMDA modules in a non-normative appendix.  The use
>>     of the non-NMDA model will allow temporary bridging of the
>>     time period until NMDA implementations are available.
>>
>>     (c) For published models, the model should be republished with
>>     an NMDA-compatible structure, deprecating non-NMDA constructs.
>>     For example, the "ietf-interfaces" model in ^RFC7223^ will be
>>     restructured as an NMDA-compatible model.  The
>>     "/interfaces-state" hierarchy will be marked "status
>>     deprecated".  Models that mark their "/foo-state" hierarchy
>>     with "status deprecated" will allow NMDA-capable
>>     implementations to avoid the cost of duplicating the state
>>     nodes, while enabling non-NMDA-capable implementations to
>>     utilize them for access to the operational values.
>>
>>     (d) For models that augment models which have not been
>>     structured with the NMDA, the modeler will have to consider
>>     the structure of the base model and the guidelines listed
>>     above.  Where possible, such models should move to new
>>     revisions of the base model that are NMDA-compatible.  When
>>     that is not possible, augmenting "state" containers SHOULD be
>>     avoided, with the expectation that the base model will be
>>     re-released with the state containers marked as deprecated.
>>     It is RECOMMENDED to augment only the "/foo" hierarchy of the
>>     base model.  Where this recommendation cannot be followed,
>>     then any new "state" elements SHOULD be included in their own
>>     module.
>>
>>     To create the temporary non-NMDA model from an NMDA model, the
>>     following steps can be taken:
>>    
>>     - Rename the module name by postpending "-state" to the
>>       original module's name
>>     - Change the namespace by postpending "-state" to the original
>>       namespace value
>>     - Change the prefix by postpending "-s" to the original prefix
>>       value
>>     - Set all top-level nodes to have a "config" statement of
>>       value "false"
>>     - add an import to the original module (e.g., for typedef
>>       definitions)
>>     - modify any imports, used for leafrefs or identityrefs, to
>>       import the -state version of the module
>>     - remove any 'typedef' or 'identity' definitions
>>     - prefix any uses of the typedefs and identities accordingly
>>     - update leafref and augment paths to use the new "-s" prefix
>>
>> For me (with any/all hats) the key downside is that we'll need to  rev
>> this text (again) in the not too distant future, but that we don't have
>> an alternative as LC on the full solution is still a bit away.
>>
>> What do people think?  
>>
>> Lou
>>
>>
>> On 8/22/2017 3:53 PM, Kent Watsen wrote:
>> > Hi,
>> >
>> > During the meeting in Chicago, the NMDA authors took an action to
>> > propose some text for S4.23.  After a little review, the following
>> > emerged.  Yes, it's short, but was anything left anything out?
>> >
>> >
>> > =====START=====
>> >
>> > 4.23 Operational Data
>> >
>> > Operational data includes both config "false" nodes as well as,
>> > on servers supporting  [draft-ietf-netmod-revised-datastores],
>> > the applied value of config "true" nodes.
>> >
>> > YANG modules SHOULD be designed assuming they will be used on
>> > servers supporting .  With this in mind, YANG
>> > modules SHOULD define config "false" wherever they make sense
>> > to the data model.  Config "false" nodes SHOULD NOT be defined
>> > to provide the operational value for configuration nodes,
>> > except when the value space of a configured and operational
>> > values may differ, in which case a distinct config "false"
>> > node SHOULD be defined to hold the operational value for the
>> > configured node.
>> >
>> > =====STOP=====
>> >
>> >
>> > One question that came up is if "operational data" is a well-defined
>> > term.  This string appears 10 times in rfc6087bis.  Most interestingly,
>> > appendix Section A.8. (v05 to v06) includes this line item:
>> >
>> >     Changed term "operational state" to "operational data"
>> >
>> > So it seems to be deliberate...
>> >
>> >
>> > Kent  // contributor
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>


From nobody Wed Aug 23 05:50:26 2017
Return-Path: 
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 8D6D1132983 for ; Wed, 23 Aug 2017 05:50:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 Ju82DunXEVur for ; Wed, 23 Aug 2017 05:50:23 -0700 (PDT)
Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 C55DF1321AF for ; Wed, 23 Aug 2017 05:50:23 -0700 (PDT)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id BE2AC1E06F6 for ; Wed, 23 Aug 2017 06:50:21 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id 0cqJ1w00V2SSUrH01cqMBl; Wed, 23 Aug 2017 06:50:21 -0600
X-Authority-Analysis: v=2.2 cv=T7z8d7CQ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=KeKAF7QvOSUA:10 a=u07AKapRAAAA:8 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=_vw6A1eyXwFnYnJxpsEA:9 a=QEXdDO2ut3YA:10 a=SkebfZ6J2Mmvk2rLHZle:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:References:Cc:To:Subject:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=JK9WEqjMT+ZiV8F/4N7m3aI98E9+5PIHi4aZ37YLwYg=; b=1ZGZP6gAFLmSEtfMmEN/gr3npw 7z2zIHCo13sfLNYBR7994ysesXOwlpxRq7bjfczF1RxJTtzPhfGOCMavaLUNFBQLJJsDFdxyhKAMk rUx12TICekDLLcuHrFrdOT1kE;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:43664 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dkV6v-003hzm-TE; Wed, 23 Aug 2017 06:50:17 -0600
From: Lou Berger 
To: Martin Bjorklund 
Cc: netmod@ietf.org
References: <20170822.122022.1375224682803846655.mbj@tail-f.com> <1aa26e59-6999-8f8a-6cd6-5e74050453bd@labn.net> <20170823.082906.1853252260651620253.mbj@tail-f.com>
Message-ID: 
Date: Wed, 23 Aug 2017 08:50:15 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170823.082906.1853252260651620253.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dkV6v-003hzm-TE
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:43664
X-Source-Auth: lberger@labn.net
X-Email-Count: 5
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 12:50:25 -0000

Martin,
See below


On August 23, 2017 2:28:37 AM Martin Bjorklund  wrote:

> Lou Berger  wrote:
>> Hi Martin,
>>
>> See below.
>>
>>
>> On 8/22/2017 6:20 AM, Martin Bjorklund wrote:
>> > Hi,
>> >
>> > Lada presented an open issue in schema mount in Prague.  (See slide 6
>> > in
>> > 
>> https://datatracker.ietf.org/meeting/99/materials/slides-99-netmod-sessb-schema-mount)
>> >
>> > The original problem comes from the NI use case
>> > (https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model).  In this
>> > use case, interfaces are assigned to NIs by:
>> >
>> >    augment /if:interfaces/if:interface:
>> >      +--rw bind-ni-name?   -> /network-instances/network-instance/name
>> >
>> > Modules that are mounted within the NI might have references to
>> > interfaces.  The idea is that a specific NI can only reference the
>> > interfaces that has been assigned to it.
>> >
>> > In schema mount, we have the "parent-reference" XPath expression that
>> > in this case will be "/if:interfaces/if:interface".  The problem is
>> > that this XPath expression will evaluate to a node set that contains
>> > *all* interfaces in the system.  We would like this to contain just
>> > the interfaces assigned to the NI.
>> >
>> > It turns out that this can be done with a simple change to the
>> > "parent-reference" node.  If we state that this XPath expression is
>> > evaluated in an XPath context where the context node is the node in
>> > the data tree where the mount point is defined (instead of "/"), we
>> > can use as parent-reference:
>> >
>> >   /if:interfaces/if:interface[ni:bind-network-instance-name = ../ni:name]
>> >
>> > Putting this together we'd have:
>> >
>> >   augment "/if:interfaces/if:interface" {
>> >     leaf bind-ni-name {
>> >       type leafref {
>> >         path "/network-instances/network-instance/name";
>> >       }
>> >     }
>> >   }
>> >
>> >   container network-instances {
>> >     list network-instance {
>> >       key name;
>> >       leaf name { ... }
>> >       ...
>> >       container root {
>> >         // this would be the XPath context root for parent-reference
>> >         yangmnt:mount-point ni-root;
>> >       }
>> >     }
>> >   }
>>
>> note that the current NI definition is:
>
> Yes I saw that.
>
>>    module: ietf-network-instance
>>      +--rw network-instances
>>         +--rw network-instance* [name]
>>            +--rw name           string
>>            +--rw enabled?       boolean
>>            +--rw description?   string
>>            +--rw (ni-type)?
>>            +--rw (root-type)?
>>               +--:(vrf-root)
>>               |  +--mp vrf-root?
>>               +--:(vsi-root)
>>               |  +--mp vsi-root?
>>               +--:(vv-root)
>>                  +--mp vv-root?
>
> Note that the extension yangmnt:mount-point can only be present in a
> container or list, not in a choice/case.

Okay, I missed that restriction in your draft.  What's the reason for
not allowing mounts under choices/cases?  Isn't the resulting path to
data nodes indistinguishable when the parent is a list or container?

>
> But what is the point of a choice with three different mount points?
>
>>    augment /if:interfaces/if:interface:
>>      +--rw bind-ni-name?   -> /network-instances/network-instance/name
>>    augment /if:interfaces/if:interface/ip:ipv4:
>>      +--rw bind-ni-name?   -> /network-instances/network-instance/name
>>    augment /if:interfaces/if:interface/ip:ipv6:
>>      +--rw bind-ni-name?   -> /network-instances/network-instance/name
>>
>> > And in state data:
>> >
>> >
>> > "ietf-yang-schema-mount:schema-mounts": {
>> >   "namespace": [
>> >     {
>> >       "prefix": "ni",
>> >       "uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
>> >     },
>> >     {
>> >       "prefix": "if",
>> >       "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
>> >     }
>> >   ]
>> >   "mount-point": [
>> >     {
>> >       "target": "/ni:network-instances/ni:network-instance/ni:root",
>> Can you confirm that with the current definition the target is:
>>
>>       "target": "/ni:network-instances/ni:network-instance",
>>
>> correct?
>
> See above; the current definition is invalid.

this is going to get really verbose if schema mount's restrictions
remain as we'll need a container and target per case mount point case.

Looking at this issue leads me to ask the question: why are parent
references tied to the mount point vs the schema?  Are the parent
references always going to the same in order for the schema to make
sense.  I think this question is separable from the restriction
discussion above, but it does help if we stick with the current
restrictions.

To be clear I'm suggesting:
Drop parent-reference from:

          |  +--ro (schema-ref)?
          |     +--:(inline)
          |     |  +--ro inline?       empty
          |     +--:(use-schema)
          |        +--ro use-schema* [name]
          |           +--ro name
          |           |       -> /schema-mounts/schema/name
          |           +--ro parent-reference*   yang:xpath1.0

and add it to

          +--ro schema* [name]
             +--ro name           string
             +--ro parent-reference*   yang:xpath1.0

>
>> >       "parent-reference": [
>> >             "/if:interfaces/if:interface
>> >              [ni:bind-network-instance-name = ../ni:name]"
>
> Correction.  This should be:
>
>             "/if:interfaces/if:interface
>              [ni:bind-network-instance-name = current()/../ni:name]"
>
>> >                           ],
>> Also, can you confirm that if we wanted to cover v4, v6 (for example
>> purposes) interfaces-state, the full parent reference list would be:
>>
>>       "parent-reference": [
>>             "/if:interfaces/if:interface
>>              [ni:bind-ni-name = ./ni:name]",
>>             "/if:interfaces/if:interface/ip:ipv4
>>              [ni:bind-ni-name = ./ni:name]",
>>             "/if:interfaces/if:interface/ip:ipv6
>>              [ni:bind-ni-name = ./ni:name]",
>>              "/if:interfaces-state/if:interface"
>>
>>  correct?
>
> No it would be:
>
>   /if:interfaces-state/if:interface[
>     if:name = /if:interfaces/if:interface[
>       ni:bind-ni-name = current()/../ni:name]/if:name]
>
> etc.
>
> I.e., the interfaces in -state that that has the same names as the
> interfaces in config that has the correct bind-ni-name.

okay, nice xpath foo

Thanks,
Lou

>
>
>> Note that interfaces-state isn't filtered as the bind-ni-name isn't
>> present in -state.
>>
>> >       "use-schema": [
>> >         {
>> >           "name": "ni-schema"
>> >         }
>> >       ]
>> >     }
>> >   ]
>> >
>> >
>> >
>> > Note that this does NOT affect the schema that is mounted; it only
>> > affects the result of the parent-reference XPath expressions.
>> >
>> >
>> > I think that we should make this change, since it allows for more
>> > precise parent-references.
>> I'm okay with the change (just want to see the draft moved forward ;-)
>>
>> Lou
>> (As contributor)
>
>
>
> /martin
>


From nobody Wed Aug 23 05:59:02 2017
Return-Path: 
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 5D3D3132BF3 for ; Wed, 23 Aug 2017 05:59:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 OBhX4aOFlnlj for ; Wed, 23 Aug 2017 05:58:58 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBACD132BF0 for ; Wed, 23 Aug 2017 05:58:57 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 9E41369; Wed, 23 Aug 2017 14:58:56 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 8F1OcbePeywF; Wed, 23 Aug 2017 14:58:55 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 23 Aug 2017 14:58:56 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 78F3E200E2; Wed, 23 Aug 2017 14:58:56 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xoWJ671znEbp; Wed, 23 Aug 2017 14:58:55 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 404BB200E0; Wed, 23 Aug 2017 14:58:55 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 34796404974F; Wed, 23 Aug 2017 14:58:55 +0200 (CEST)
Date: Wed, 23 Aug 2017 14:58:55 +0200
From: Juergen Schoenwaelder 
To: Lou Berger 
Cc: netmod@ietf.org
Message-ID: <20170823125855.mfuel6iwv5sxl3wy@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Lou Berger , netmod@ietf.org
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local> <95c65e38-a117-592d-5c3f-06d31f8845fa@labn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <95c65e38-a117-592d-5c3f-06d31f8845fa@labn.net>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 12:59:00 -0000

Lets do it this way then. If we plan to revise this again in ~1 year,
so be it. We started this revision in Feb 2014. ;-)

/js

On Wed, Aug 23, 2017 at 08:07:28AM -0400, Lou Berger wrote:
> Juergen,
> 
> 
> On August 23, 2017 2:17:43 AM Juergen Schoenwaelder
>  wrote:
> 
> > My preference is to have the guidelines say what people should do,
> > namely design NMDA models. I would prefer to keep any transition
> > aspects out of the guidelines.
> 
> Well, this approach works for those who are deeply enmeshed in netmod
> and the IETF, it doesn't help those designing models/solutions during
> the current transition period.  IMO we can't forget about this important
> class of model developers and users.
> 
> > If people want to include transition
> > aspects, it should be in the appendix (i.e., easy to remove / ignore
> > later on).
> >
> I don't see a material difference here.  Either way the document needs
> to be updated. See below for a specific proposed wording update.
> 
> > I understand that there is a timing issue. The question is what you
> > mean with "NMDA solution makes it to publication (request)". If you
> > mean the core NMDA document, this is pretty much in reach and keeping
> > this guidelines document on hold until then may be an option. If you
> > mean the complete solution set, including model updates and moving the
> > protocol extensions in NETCONF to publication request, then this may
> > take a bit more time.
> >
> I mean the time when implementors can reasonably be told that the old
> way has been replaced by a fully defined (and able to be implemented)
> NMDA solution.  I think includes both netconf and restconf NMDA
> definitions.  I don't think it's reasonable to require implementation of
> drafts that are in-flux.
> 
> 
> 
> > /js
> >
> > On Tue, Aug 22, 2017 at 04:32:14PM -0400, Lou Berger wrote:
> >> Kent/WG,
> >>
> >>  This seems a bit terse to me and not provide needed guidance during
> >> the current transition period. I understood the discussion ended up
> >> with the options being to either (1) provide the guidance as a
> >> standalone document, e.g., (a)-(s) in draft-dsdt-nmda-guidelines, with a
> >> pointer to it from 6087bis or (2) just move those sections to 6087 bis.
> >> Either way, we'll need a new bis once the full NMDA solution makes it to
> >> publication (request).
> >>
> >> I thought the plan was to do (s). If so, we need the full text.
> >> Looking at the current repo
> >> (https://github.com/netmod-wg/datastore-dt/blob/master/guidelines/guidelines.txt)
> >> it would be:
> >>
> >>  4.23 Operational Data
> >>
> >>  The following guidelines are meant to help modelers develop
> >>  YANG models that will maximize the utility of the model with
> >>  both current implementations and NMDA-capable implementations
> >>  [draft-ietf-netmod-revised-datastores].
> >>
> remove (a) and re-letter rest of list
> >>  (a) New models and models that are not concerned with the
> >>  operational state of configuration information SHOULD
> >>  immediately be structured to be NMDA-compatible.
> 
> Add:
>    The remaining options MAY be followed during the time that
>    NMDA mechanisms are being defined.  These options will be
>    removed in a future update of this document once this definition
>    is complete.
> 
> Does this work for you?  Moving it to an appendix just makes it harder
> for the reader and, again, the document needs to be revised either way
> in the future.
> 
> Lou
> 
> >>
> >>  (b) Models that require immediate support for "in use" and
> >>  "system created" information SHOULD be structured for NMDA. A
> >>  non-NMDA version of these models SHOULD exist, either an
> >>  existing model or a model created either by hand or with
> >>  suitable tools that mirror the current modeling strategies.
> >>  Both the NMDA and the non-NMDA modules SHOULD be published in
> >>  the same document, with NMDA modules in the document main body
> >>  and the non-NMDA modules in a non-normative appendix. The use
> >>  of the non-NMDA model will allow temporary bridging of the
> >>  time period until NMDA implementations are available.
> >>
> >>  (c) For published models, the model should be republished with
> >>  an NMDA-compatible structure, deprecating non-NMDA constructs.
> >>  For example, the "ietf-interfaces" model in ^RFC7223^ will be
> >>  restructured as an NMDA-compatible model. The
> >>  "/interfaces-state" hierarchy will be marked "status
> >>  deprecated". Models that mark their "/foo-state" hierarchy
> >>  with "status deprecated" will allow NMDA-capable
> >>  implementations to avoid the cost of duplicating the state
> >>  nodes, while enabling non-NMDA-capable implementations to
> >>  utilize them for access to the operational values.
> >>
> >>  (d) For models that augment models which have not been
> >>  structured with the NMDA, the modeler will have to consider
> >>  the structure of the base model and the guidelines listed
> >>  above. Where possible, such models should move to new
> >>  revisions of the base model that are NMDA-compatible. When
> >>  that is not possible, augmenting "state" containers SHOULD be
> >>  avoided, with the expectation that the base model will be
> >>  re-released with the state containers marked as deprecated.
> >>  It is RECOMMENDED to augment only the "/foo" hierarchy of the
> >>  base model. Where this recommendation cannot be followed,
> >>  then any new "state" elements SHOULD be included in their own
> >>  module.
> >>
> >>  To create the temporary non-NMDA model from an NMDA model, the
> >>  following steps can be taken:
> >> 
> >>  - Rename the module name by postpending "-state" to the
> >>  original module's name
> >>  - Change the namespace by postpending "-state" to the original
> >>  namespace value
> >>  - Change the prefix by postpending "-s" to the original prefix
> >>  value
> >>  - Set all top-level nodes to have a "config" statement of
> >>  value "false"
> >>  - add an import to the original module (e.g., for typedef
> >>  definitions)
> >>  - modify any imports, used for leafrefs or identityrefs, to
> >>  import the -state version of the module
> >>  - remove any 'typedef' or 'identity' definitions
> >>  - prefix any uses of the typedefs and identities accordingly
> >>  - update leafref and augment paths to use the new "-s" prefix
> >>
> >> For me (with any/all hats) the key downside is that we'll need to rev
> >> this text (again) in the not too distant future, but that we don't have
> >> an alternative as LC on the full solution is still a bit away.
> >>
> >> What do people think?
> >>
> >> Lou
> >>
> >>
> >> On 8/22/2017 3:53 PM, Kent Watsen wrote:
> >> > Hi,
> >> >
> >> > During the meeting in Chicago, the NMDA authors took an action to
> >> > propose some text for S4.23.  After a little review, the following
> >> > emerged.  Yes, it's short, but was anything left anything out?
> >> >
> >> >
> >> > =====START=====
> >> >
> >> > 4.23 Operational Data
> >> >
> >> > Operational data includes both config "false" nodes as well as,
> >> > on servers supporting  [draft-ietf-netmod-revised-datastores],
> >> > the applied value of config "true" nodes.
> >> >
> >> > YANG modules SHOULD be designed assuming they will be used on
> >> > servers supporting .  With this in mind, YANG
> >> > modules SHOULD define config "false" wherever they make sense
> >> > to the data model.  Config "false" nodes SHOULD NOT be defined
> >> > to provide the operational value for configuration nodes,
> >> > except when the value space of a configured and operational
> >> > values may differ, in which case a distinct config "false"
> >> > node SHOULD be defined to hold the operational value for the
> >> > configured node.
> >> >
> >> > =====STOP=====
> >> >
> >> >
> >> > One question that came up is if "operational data" is a well-defined
> >> > term.  This string appears 10 times in rfc6087bis.  Most interestingly,
> >> > appendix Section A.8. (v05 to v06) includes this line item:
> >> >
> >> >     Changed term "operational state" to "operational data"
> >> >
> >> > So it seems to be deliberate...
> >> >
> >> >
> >> > Kent  // contributor
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > 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
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103         
> >
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Aug 23 06:23:40 2017
Return-Path: 
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 C40F3132C0D for ; Wed, 23 Aug 2017 06:23:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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
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 uGIrY8nVcmdU for ; Wed, 23 Aug 2017 06:23:36 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332FD1326F3 for ; Wed, 23 Aug 2017 06:23:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4353; q=dns/txt; s=iport; t=1503494616; x=1504704216; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=05S+Tiganwx6++2brd7a2OOSoa0cGQpETx3yZDLOeLE=; b=LD9E3LjRj6WRZHr9ffraJEaD57Y3TFdKN3UQ+7o8/SKKKzYLrcgJgXmJ oYV6SYNu1ZPGNUeYOaCFJQggqI3RjePTM5jL5Z0YXubz6Mm94CICRxA8x 82Rl3LRiMEMfLxKDU9AgfB3cARWyipRrtmdiHSUE+Iw9Pa6TxjcmyrCW7 E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DiAQCBgZ1Z/xbLJq1ZAxoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAZRbkRaWMoIEhUcChQcUAQIBAQEBAQEBayiFGAEBAQECAThBBQsLGC5?= =?us-ascii?q?XBg0IAQGKJQiwfItsAQEBAQEBAQEBAQEBAQEBAQEBIIMqg06CDoFwWDSEQAESA?= =?us-ascii?q?UAmhS0FoFiLK4kZghKJPCSGco0+iHA2IX8LMiEIHBVJhUyBTz+IeA0XB4IUAQE?= =?us-ascii?q?B?=
X-IronPort-AV: E=Sophos;i="5.41,417,1498521600"; d="scan'208";a="696705512"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Aug 2017 13:23:12 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v7NDNC6J013069; Wed, 23 Aug 2017 13:23:12 GMT
To: Vladimir Vassilev 
Cc: "netmod@ietf.org" 
References:  <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com>  <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com>   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>   <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com> <5929631c-e51d-ae66-52d1-cbc87ca3506b@transpacket.com>
From: Robert Wilton 
Message-ID: <321a45fb-77e1-23c7-184b-d3bff9d41c39@cisco.com>
Date: Wed, 23 Aug 2017 14:23:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <5929631c-e51d-ae66-52d1-cbc87ca3506b@transpacket.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Pattern statements [was Re: 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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 13:23:39 -0000

On 23/08/2017 12:52, Vladimir Vassilev wrote:
> On 08/21/2017 05:14 PM, Robert Wilton wrote:
>
>> Hi Acee,
>>
>> That makes sense.
>>
>> The other thing that I think that we have got wrong is modelling 
>> regex pattern statements.  I think that it would be much better if 
>> these were written to be less exhaustive and much simpler.
>>
>> E.g. the "route distinguisher" pattern in 
>> draft-ietf-rtgwg-routing-types-09 is defined as this:
>>
>>           pattern
>>             '(0:(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
>>           +     '6[0-4][0-9]{3}|'
>>           +     '[0-5]?[0-9]{0,3}[0-9]):(429496729[0-5]|'
>>           +     '42949672[0-8][0-9]|'
>>           +     '4294967[01][0-9]{2}|429496[0-6][0-9]{3}|'
>>           +     '42949[0-5][0-9]{4}|'
>>           +     '4294[0-8][0-9]{5}|429[0-3][0-9]{6}|'
>>           +     '42[0-8][0-9]{7}|4[01][0-9]{8}|'
>>           +     '[0-3]?[0-9]{0,8}[0-9]))|'
>>           + '(1:((([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|'
>>           +     '25[0-5])\.){3}([0-9]|[1-9][0-9]|'
>>           +     '1[0-9]{2}|2[0-4][0-9]|25[0-5])):(6553[0-5]|'
>>           +     '655[0-2][0-9]|'
>>           +     '65[0-4][0-9]{2}|6[0-4][0-9]{3}|'
>>           +     '[0-5]?[0-9]{0,3}[0-9]))|'
>>           + '(2:(429496729[0-5]|42949672[0-8][0-9]|'
>>           +     '4294967[01][0-9]{2}|'
>>           +     '429496[0-6][0-9]{3}|42949[0-5][0-9]{4}|'
>>           +     '4294[0-8][0-9]{5}|'
>>           + '429[0-3][0-9]{6}|42[0-8][0-9]{7}|4[01][0-9]{8}|'
>>           +     '[0-3]?[0-9]{0,8}[0-9]):'
>>           +     '(6553[0-5]|655[0-2][0-9]|65[0-4][0-9]{2}|'
>>           +     '6[0-4][0-9]{3}|'
>>           +     '[0-5]?[0-9]{0,3}[0-9]))|'
>>           + '(6(:[a-fA-F0-9]{2}){6})|'
>>           + '(([3-57-9a-fA-F]|[1-9a-fA-F][0-9a-fA-F]{1,3}):'
>>           +     '[0-9a-fA-F]{1,12})';
>>         }
>>
>> But I think that it would be much easier to read, and quite possibly 
>> more performant to execute, if the pattern regex was written 
>> something like the following:
>>
>>  pattern:
>>     '(0:[0-9]{1,5}:[0-9]{1,10})|
>>      (1:([0-9]{1,3}\.){4}:[0-9]{1,5})|
>>      (2:[0-9]{1,10}:0:[0-9]{1,5})|
>>      (6(:[a-fA-F0-9]{2}){6})';
>>
>> Of course, this would allow more invalid values, but most servers 
>> would be expected to reject those when it converts them into an 
>> internal binary format any way.
>>
>> What do you, and others, think?
> You still need the 
> |(([3-57-9a-fA-F]|[1-9a-fA-F][0-9a-fA-F]{1,3}):[0-9a-fA-F]{1,12}) in 
> the end to not reject valid values though.
Sure, OK.

>
> IMO a pattern statement has value if it absolutely defines the set of 
> valid strings.
It still has value if it also performs some simple checks and removes 
obvious mistakes.

But even if a value passes the regex filter, it still doesn't guarantee 
that is the value is correct.  Someone could put a typo in there, or 
perhaps configure a multicast IP address where only unicast addresses 
are allowed, or put the same IP address on two separate interfaces, or 
use a IP address that they don't own, etc ...

> In general I do not see the benefit of pattern statements that do not 
> reject all invalid string instances. I prefer the original pattern or 
> none at all.
OK, so some potential counter examples:
1) Email address.  I understand that the full regex to validate all 
email addresses is very complex, but checking that it at least contains 
an @ symbol still has benefit.  It would seem that a short imperfect 
regex is better than a complete perfect regex.
2) A list of VLAN ranges, e.g. want to allow strings that look like 
this: "1-10,20-400,600,2000-3000", but only with non overlapping values 
in ascending order.  It is easy to write a regex to check that the 
structure is right, but AFAIK it is hard (impossible?) to write a regex 
that ensures that the ranges don't overlap and are specified in 
ascending order.

So, I propose that we use regexes for checking that the string is 
structurally correct, but don't use regexes to perform numerical range 
checks of string encoded numbers, since it makes the regexes hard to 
read/verify, and doesn't improve the readability of the YANG file either.

Thanks,
Rob


>
> Vladimir
>
>> Thanks,
>> Rob
>
> .
>


From nobody Wed Aug 23 06:37:04 2017
Return-Path: 
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 76283132C12 for ; Wed, 23 Aug 2017 06:37:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 E9R7Gv8OLQmR for ; Wed, 23 Aug 2017 06:36:59 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ECB2132518 for ; Wed, 23 Aug 2017 06:36:59 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 3F2E73C; Wed, 23 Aug 2017 15:36:58 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id erXAH9V8XqqN; Wed, 23 Aug 2017 15:36:57 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 23 Aug 2017 15:36:58 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1D702200E2; Wed, 23 Aug 2017 15:36:58 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GctgnEKS9HHj; Wed, 23 Aug 2017 15:36:57 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B5344200E0; Wed, 23 Aug 2017 15:36:57 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 931F94049A07; Wed, 23 Aug 2017 15:36:57 +0200 (CEST)
Date: Wed, 23 Aug 2017 15:36:57 +0200
From: Juergen Schoenwaelder 
To: Robert Wilton 
Cc: Vladimir Vassilev , "netmod@ietf.org" 
Message-ID: <20170823133657.76s5wbcxbpgjfkiy@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , Vladimir Vassilev , "netmod@ietf.org" 
References:   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>   <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com> <5929631c-e51d-ae66-52d1-cbc87ca3506b@transpacket.com> <321a45fb-77e1-23c7-184b-d3bff9d41c39@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <321a45fb-77e1-23c7-184b-d3bff9d41c39@cisco.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] Pattern statements [was Re: 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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 13:37:01 -0000

On Wed, Aug 23, 2017 at 02:23:12PM +0100, Robert Wilton wrote:
> 
> 1) Email address.  I understand that the full regex to validate all email
> addresses is very complex, but checking that it at least contains an @
> symbol still has benefit.  It would seem that a short imperfect regex is
> better than a complete perfect regex.

What is your definition of 'better'? A stricter pattern catches more
errors. An imperfect pattern is better than none.

> 2) A list of VLAN ranges, e.g. want to allow strings that look like this:
> "1-10,20-400,600,2000-3000", but only with non overlapping values in
> ascending order.  It is easy to write a regex to check that the structure is
> right, but AFAIK it is hard (impossible?) to write a regex that ensures that
> the ranges don't overlap and are specified in ascending order.

So what. Does this provide a helpful argument whether patterns should
be strict or imperfect?

> So, I propose that we use regexes for checking that the string is
> structurally correct, but don't use regexes to perform numerical range
> checks of string encoded numbers, since it makes the regexes hard to
> read/verify, and doesn't improve the readability of the YANG file either.

So here is the point I think:

   It is desirable that regexes are as strict as they can be.
   However, if regexes become so complicated that they become a
   verification and maintenance problem by themself, then less strict
   regexes may be a better choice.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Aug 23 07:21:48 2017
Return-Path: 
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 6170A132C21 for ; Wed, 23 Aug 2017 07:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 FSa-AqRpsfm7 for ; Wed, 23 Aug 2017 07:21:43 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 4803D13294B for ; Wed, 23 Aug 2017 07:21:43 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 6D2BA60E84 for ; Wed, 23 Aug 2017 16:21:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1503498100; bh=UZezoI2TKkQ/mMEYgskBY68WLFaWNzLX/8NOyeN5dXE=; h=From:To:Date; b=eSbCwNFfcbpxu3bGFoz1k72/S0uYd+UQLNPjzdLkFqFMXmlRorvGTqryDX1BonZFT Tk129q4NEb7zwRTUXdt1T80mmsCqAv7QO1+H7UHJqs2F1ge/D1fEW4kbButOwFckBi Oitca2+iXKq2Vinqskyvg02GE+/+/CpTVARWQ62Q=
Message-ID: <1503498125.32530.12.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Wed, 23 Aug 2017 16:22:05 +0200
In-Reply-To: <20170823133657.76s5wbcxbpgjfkiy@elstar.local>
References:   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>   <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com> <5929631c-e51d-ae66-52d1-cbc87ca3506b@transpacket.com> <321a45fb-77e1-23c7-184b-d3bff9d41c39@cisco.com> <20170823133657.76s5wbcxbpgjfkiy@elstar.local>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Pattern statements [was Re: 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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 14:21:47 -0000

Juergen Schoenwaelder píše v St 23. 08. 2017 v 15:36 +0200:
> On Wed, Aug 23, 2017 at 02:23:12PM +0100, Robert Wilton wrote:
> > 
> > 1) Email address.  I understand that the full regex to validate all email
> > addresses is very complex, but checking that it at least contains an @
> > symbol still has benefit.  It would seem that a short imperfect regex is
> > better than a complete perfect regex.
> 
> What is your definition of 'better'? A stricter pattern catches more
> errors. An imperfect pattern is better than none.
> 
> > 2) A list of VLAN ranges, e.g. want to allow strings that look like this:
> > "1-10,20-400,600,2000-3000", but only with non overlapping values in
> > ascending order.  It is easy to write a regex to check that the structure is
> > right, but AFAIK it is hard (impossible?) to write a regex that ensures that
> > the ranges don't overlap and are specified in ascending order.
> 
> So what. Does this provide a helpful argument whether patterns should
> be strict or imperfect?
> 
> > So, I propose that we use regexes for checking that the string is
> > structurally correct, but don't use regexes to perform numerical range
> > checks of string encoded numbers, since it makes the regexes hard to
> > read/verify, and doesn't improve the readability of the YANG file either.
> 
> So here is the point I think:
> 
>    It is desirable that regexes are as strict as they can be.
>    However, if regexes become so complicated that they become a
>    verification and maintenance problem by themself, then less strict
>    regexes may be a better choice.

Either way, the regex must not produce false negatives, i.e. reject valid
values. For some regexes this is what makes them complicated.

Also, I don't see any need for replacing existing patterns unless they are
wrong. We have descriptions to tell human readers about the permitted value set.

Lada

> 
> /js
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Aug 23 09:38:31 2017
Return-Path: 
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 D27181329C1 for ; Wed, 23 Aug 2017 09:38:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 lcOfTdxC-6ro for ; Wed, 23 Aug 2017 09:38:27 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0120.outbound.protection.outlook.com [104.47.33.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A99B91329CC for ; Wed, 23 Aug 2017 09:38:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9fcHyWjY0wYxGCo1XuzEHaGycj4nRGe5Ze2FRBHdpuw=; b=ci6SdTyuARLIrqjuvusbxEPMvcvoyH2l0HiYYS6xjJ33iHUl5L/j+QoxR9Knqmiadu/Za2aMu0uHCKH4BNCOJNoR87JjL1lOeUTobO/0hxr/9VG8i8DBj4fCbEFNUtS1E0c5zRFBDX5W91jaO2h/IUc0thRziAaWglR/Z8WmDxc=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1186.namprd05.prod.outlook.com (10.160.113.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.4; Wed, 23 Aug 2017 16:38:16 +0000
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.1385.008; Wed, 23 Aug 2017 16:38:16 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder , Lou Berger 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] rfc6087bis S4.23 replacement text
Thread-Index: AQHTG4BdACYCFz8ZdEeedIP50UiUz6KQ1HkAgACjbICAAGHhAIAADmCA///6OoA=
Date: Wed, 23 Aug 2017 16:38:16 +0000
Message-ID: 
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local> <95c65e38-a117-592d-5c3f-06d31f8845fa@labn.net> <20170823125855.mfuel6iwv5sxl3wy@elstar.local>
In-Reply-To: <20170823125855.mfuel6iwv5sxl3wy@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1186; 6:ent5yrP+c0cIhGGHF5Tu9CFsOGycgaA9H0cSqcux40k0woRWTSSFBmgQVP2nE03QrQY4+pMtU3NN2XXrCehlvJkMIJNdFVj/bFRMxkFnuLWqqJ4NU6wzBuW1XOXpUJm6nroDzcgnjAdLe1DwR2hInS0mF77s3ax72PqcMoz5xXGpeP0+KHfY7h7497GyajO471SWXqZBqlEAGqAG05ORjTDOMehQxvzHOjWAWkcTGRzc903pNPXq55TFW9nAZ7jphKq7Db54boGPBqESDFhyYr8eiLq+IaaicB9OWttxJi0/DgxdXNsLMLGGxFMv/TXle+k620crw7AMj/3aENfMQg==; 5:J2GIak5gOOQxFsyIU7xL3/KnPNtCsjLGhZuYMQ1u/Jc/M6Z0QO+msRm3O4tCphOgfF5uwwvnDX5Xm/LVgGgEkDw7b7px3afnw0zeYP95iPVX5asxCnLL+A+Lc3sYHdl9LnEy+Byp96cd6ovee81OZA==; 24:9ExZMdA99rS1A6P000yvghSJJDO0KZT+AqKYZmqx5K48gSvVfA6OQrue6O7dvhCsGQH1eShBLR+asorJBQ9lHtN4/CGV50b5RSJABJk/fVg=; 7:mU8rYmRmV9uLXnSCdlFEJOe6t7YnytCL4vFQe/u81QgL/oFUkjHBGdZ+3LaYIKDO/Il5PvMRgrPm/+AnjUm8RKnehRanUUQmN9MV4eR3WDTTUmXyLXFc1AlvUPlVtQkf4XrWgvBJkJsh8ZY320xnUXu8OnV8YZLdbCJwAg5PhFbXo4GYNuea2AdUXAVqXtb/r4jnWgvbiN1LpSd4oL5VsGHYX1KqaHdNazs6Lbm70PU=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: abe7ea82-9a5a-4af0-91bf-08d4ea455af2
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603186)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1186; 
x-ms-traffictypediagnostic: BN3PR0501MB1186:
x-exchange-antispam-report-test: UriScan:(166708455590820)(131327999870524);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1186; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1186; 
x-forefront-prvs: 040866B734
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(189002)(377454003)(24454002)(199003)(2950100002)(99286003)(305945005)(106356001)(189998001)(25786009)(83716003)(68736007)(6512007)(5660300001)(229853002)(7736002)(966005)(6506006)(8936002)(83506001)(93886005)(4001350100001)(2900100001)(6486002)(82746002)(53546010)(97736004)(6436002)(8676002)(77096006)(14454004)(86362001)(3660700001)(4326008)(101416001)(478600001)(105586002)(81156014)(2906002)(50986999)(81166006)(76176999)(54356999)(33656002)(3280700002)(6116002)(6306002)(36756003)(66066001)(3846002)(6246003)(53936002)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1186; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <18E7F07A7C4ECF40A1670EC50AE35CE8@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2017 16:38:16.4165 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1186
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 16:38:30 -0000

DQpKdXN0IHdvbmRlcmluZywgYnV0IGlzIGFuIFJGQyB0aGUgYXBwcm9wcmlhdGUgdmVoaWNsZSBm
b3IgdGhpcyBjb250ZW50PyAgV291bGQgYSB3aWtpIGJlIGJldHRlcj8NCg0KSy4NCg0KDQotLQ0K
DQpMZXRzIGRvIGl0IHRoaXMgd2F5IHRoZW4uIElmIHdlIHBsYW4gdG8gcmV2aXNlIHRoaXMgYWdh
aW4gaW4gfjEgeWVhciwNCnNvIGJlIGl0LiBXZSBzdGFydGVkIHRoaXMgcmV2aXNpb24gaW4gRmVi
IDIwMTQuIDstKQ0KDQovanMNCg0KT24gV2VkLCBBdWcgMjMsIDIwMTcgYXQgMDg6MDc6MjhBTSAt
MDQwMCwgTG91IEJlcmdlciB3cm90ZToNCj4gSnVlcmdlbiwNCj4gDQo+IA0KPiBPbiBBdWd1c3Qg
MjMsIDIwMTcgMjoxNzo0MyBBTSBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCj4gPGouc2Nob2Vud2Fl
bGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+IA0KPiA+IE15IHByZWZlcmVuY2Ug
aXMgdG8gaGF2ZSB0aGUgZ3VpZGVsaW5lcyBzYXkgd2hhdCBwZW9wbGUgc2hvdWxkIGRvLA0KPiA+
IG5hbWVseSBkZXNpZ24gTk1EQSBtb2RlbHMuIEkgd291bGQgcHJlZmVyIHRvIGtlZXAgYW55IHRy
YW5zaXRpb24NCj4gPiBhc3BlY3RzIG91dCBvZiB0aGUgZ3VpZGVsaW5lcy4NCj4gDQo+IFdlbGws
IHRoaXMgYXBwcm9hY2ggd29ya3MgZm9yIHRob3NlIHdobyBhcmUgZGVlcGx5IGVubWVzaGVkIGlu
IG5ldG1vZA0KPiBhbmQgdGhlIElFVEYsIGl0IGRvZXNuJ3QgaGVscCB0aG9zZSBkZXNpZ25pbmcg
bW9kZWxzL3NvbHV0aW9ucyBkdXJpbmcNCj4gdGhlIGN1cnJlbnQgdHJhbnNpdGlvbiBwZXJpb2Qu
ICBJTU8gd2UgY2FuJ3QgZm9yZ2V0IGFib3V0IHRoaXMgaW1wb3J0YW50DQo+IGNsYXNzIG9mIG1v
ZGVsIGRldmVsb3BlcnMgYW5kIHVzZXJzLg0KPiANCj4gPiBJZiBwZW9wbGUgd2FudCB0byBpbmNs
dWRlIHRyYW5zaXRpb24NCj4gPiBhc3BlY3RzLCBpdCBzaG91bGQgYmUgaW4gdGhlIGFwcGVuZGl4
IChpLmUuLCBlYXN5IHRvIHJlbW92ZSAvIGlnbm9yZQ0KPiA+IGxhdGVyIG9uKS4NCj4gPg0KPiBJ
IGRvbid0IHNlZSBhIG1hdGVyaWFsIGRpZmZlcmVuY2UgaGVyZS4gIEVpdGhlciB3YXkgdGhlIGRv
Y3VtZW50IG5lZWRzDQo+IHRvIGJlIHVwZGF0ZWQuIFNlZSBiZWxvdyBmb3IgYSBzcGVjaWZpYyBw
cm9wb3NlZCB3b3JkaW5nIHVwZGF0ZS4NCj4gDQo+ID4gSSB1bmRlcnN0YW5kIHRoYXQgdGhlcmUg
aXMgYSB0aW1pbmcgaXNzdWUuIFRoZSBxdWVzdGlvbiBpcyB3aGF0IHlvdQ0KPiA+IG1lYW4gd2l0
aCAiTk1EQSBzb2x1dGlvbiBtYWtlcyBpdCB0byBwdWJsaWNhdGlvbiAocmVxdWVzdCkiLiBJZiB5
b3UNCj4gPiBtZWFuIHRoZSBjb3JlIE5NREEgZG9jdW1lbnQsIHRoaXMgaXMgcHJldHR5IG11Y2gg
aW4gcmVhY2ggYW5kIGtlZXBpbmcNCj4gPiB0aGlzIGd1aWRlbGluZXMgZG9jdW1lbnQgb24gaG9s
ZCB1bnRpbCB0aGVuIG1heSBiZSBhbiBvcHRpb24uIElmIHlvdQ0KPiA+IG1lYW4gdGhlIGNvbXBs
ZXRlIHNvbHV0aW9uIHNldCwgaW5jbHVkaW5nIG1vZGVsIHVwZGF0ZXMgYW5kIG1vdmluZyB0aGUN
Cj4gPiBwcm90b2NvbCBleHRlbnNpb25zIGluIE5FVENPTkYgdG8gcHVibGljYXRpb24gcmVxdWVz
dCwgdGhlbiB0aGlzIG1heQ0KPiA+IHRha2UgYSBiaXQgbW9yZSB0aW1lLg0KPiA+DQo+IEkgbWVh
biB0aGUgdGltZSB3aGVuIGltcGxlbWVudG9ycyBjYW4gcmVhc29uYWJseSBiZSB0b2xkIHRoYXQg
dGhlIG9sZA0KPiB3YXkgaGFzIGJlZW4gcmVwbGFjZWQgYnkgYSBmdWxseSBkZWZpbmVkIChhbmQg
YWJsZSB0byBiZSBpbXBsZW1lbnRlZCkNCj4gTk1EQSBzb2x1dGlvbi4gIEkgdGhpbmsgaW5jbHVk
ZXMgYm90aCBuZXRjb25mIGFuZCByZXN0Y29uZiBOTURBDQo+IGRlZmluaXRpb25zLiAgSSBkb24n
dCB0aGluayBpdCdzIHJlYXNvbmFibGUgdG8gcmVxdWlyZSBpbXBsZW1lbnRhdGlvbiBvZg0KPiBk
cmFmdHMgdGhhdCBhcmUgaW4tZmx1eC4NCj4gDQo+IA0KPiANCj4gPiAvanMNCj4gPg0KPiA+IE9u
IFR1ZSwgQXVnIDIyLCAyMDE3IGF0IDA0OjMyOjE0UE0gLTA0MDAsIExvdSBCZXJnZXIgd3JvdGU6
DQo+ID4+IEtlbnQvV0csDQo+ID4+DQo+ID4+ICAgICBUaGlzIHNlZW1zIGEgYml0IHRlcnNlIHRv
IG1lIGFuZCBub3QgcHJvdmlkZSBuZWVkZWQgZ3VpZGFuY2UgZHVyaW5nDQo+ID4+IHRoZSBjdXJy
ZW50IHRyYW5zaXRpb24gcGVyaW9kLiAgSSB1bmRlcnN0b29kICB0aGUgZGlzY3Vzc2lvbiBlbmRl
ZCB1cCANCj4gPj4gd2l0aCB0aGUgb3B0aW9ucyBiZWluZyB0byBlaXRoZXIgKDEpIHByb3ZpZGUg
dGhlIGd1aWRhbmNlIGFzIGENCj4gPj4gc3RhbmRhbG9uZSBkb2N1bWVudCwgZS5nLiwgKGEpLShz
KSBpbiBkcmFmdC1kc2R0LW5tZGEtZ3VpZGVsaW5lcywgd2l0aCBhDQo+ID4+IHBvaW50ZXIgdG8g
aXQgZnJvbSA2MDg3YmlzIG9yICgyKSBqdXN0IG1vdmUgdGhvc2Ugc2VjdGlvbnMgdG8gNjA4NyBi
aXMuIA0KPiA+PiBFaXRoZXIgd2F5LCB3ZSdsbCBuZWVkIGEgbmV3IGJpcyBvbmNlIHRoZSBmdWxs
IE5NREEgc29sdXRpb24gbWFrZXMgaXQgdG8NCj4gPj4gcHVibGljYXRpb24gKHJlcXVlc3QpLg0K
PiA+Pg0KPiA+PiBJIHRob3VnaHQgdGhlIHBsYW4gd2FzIHRvIGRvIChzKS4gIElmIHNvLCB3ZSBu
ZWVkIHRoZSBmdWxsIHRleHQuIA0KPiA+PiBMb29raW5nIGF0IHRoZSBjdXJyZW50IHJlcG8NCj4g
Pj4gKGh0dHBzOi8vZ2l0aHViLmNvbS9uZXRtb2Qtd2cvZGF0YXN0b3JlLWR0L2Jsb2IvbWFzdGVy
L2d1aWRlbGluZXMvZ3VpZGVsaW5lcy50eHQpDQo+ID4+IGl0IHdvdWxkIGJlOg0KPiA+Pg0KPiA+
PiAgICAgNC4yMyBPcGVyYXRpb25hbCBEYXRhDQo+ID4+DQo+ID4+ICAgICBUaGUgZm9sbG93aW5n
IGd1aWRlbGluZXMgYXJlIG1lYW50IHRvIGhlbHAgbW9kZWxlcnMgZGV2ZWxvcA0KPiA+PiAgICAg
WUFORyBtb2RlbHMgdGhhdCB3aWxsIG1heGltaXplIHRoZSB1dGlsaXR5IG9mIHRoZSBtb2RlbCB3
aXRoDQo+ID4+ICAgICBib3RoIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIGFuZCBOTURBLWNhcGFi
bGUgaW1wbGVtZW50YXRpb25zDQo+ID4+ICAgICBbZHJhZnQtaWV0Zi1uZXRtb2QtcmV2aXNlZC1k
YXRhc3RvcmVzXS4NCj4gPj4NCj4gcmVtb3ZlIChhKSBhbmQgcmUtbGV0dGVyIHJlc3Qgb2YgbGlz
dA0KPiA+PiAgICAgKGEpIE5ldyBtb2RlbHMgYW5kIG1vZGVscyB0aGF0IGFyZSBub3QgY29uY2Vy
bmVkIHdpdGggdGhlDQo+ID4+ICAgICBvcGVyYXRpb25hbCBzdGF0ZSBvZiBjb25maWd1cmF0aW9u
IGluZm9ybWF0aW9uIFNIT1VMRA0KPiA+PiAgICAgaW1tZWRpYXRlbHkgYmUgc3RydWN0dXJlZCB0
byBiZSBOTURBLWNvbXBhdGlibGUuDQo+IA0KPiBBZGQ6DQo+ICAgIFRoZSByZW1haW5pbmcgb3B0
aW9ucyBNQVkgYmUgZm9sbG93ZWQgZHVyaW5nIHRoZSB0aW1lIHRoYXQNCj4gICAgTk1EQSBtZWNo
YW5pc21zIGFyZSBiZWluZyBkZWZpbmVkLiAgVGhlc2Ugb3B0aW9ucyB3aWxsIGJlDQo+ICAgIHJl
bW92ZWQgaW4gYSBmdXR1cmUgdXBkYXRlIG9mIHRoaXMgZG9jdW1lbnQgb25jZSB0aGlzIGRlZmlu
aXRpb24NCj4gICAgaXMgY29tcGxldGUuDQo+IA0KPiBEb2VzIHRoaXMgd29yayBmb3IgeW91PyAg
TW92aW5nIGl0IHRvIGFuIGFwcGVuZGl4IGp1c3QgbWFrZXMgaXQgaGFyZGVyDQo+IGZvciB0aGUg
cmVhZGVyIGFuZCwgYWdhaW4sIHRoZSBkb2N1bWVudCBuZWVkcyB0byBiZSByZXZpc2VkIGVpdGhl
ciB3YXkNCj4gaW4gdGhlIGZ1dHVyZS4NCj4gDQo+IExvdQ0KPiANCj4gPj4NCj4gPj4gICAgIChi
KSBNb2RlbHMgdGhhdCByZXF1aXJlIGltbWVkaWF0ZSBzdXBwb3J0IGZvciAiaW4gdXNlIiBhbmQN
Cj4gPj4gICAgICJzeXN0ZW0gY3JlYXRlZCIgaW5mb3JtYXRpb24gU0hPVUxEIGJlIHN0cnVjdHVy
ZWQgZm9yIE5NREEuICBBDQo+ID4+ICAgICBub24tTk1EQSB2ZXJzaW9uIG9mIHRoZXNlIG1vZGVs
cyBTSE9VTEQgZXhpc3QsIGVpdGhlciBhbg0KPiA+PiAgICAgZXhpc3RpbmcgbW9kZWwgb3IgYSBt
b2RlbCBjcmVhdGVkIGVpdGhlciBieSBoYW5kIG9yIHdpdGgNCj4gPj4gICAgIHN1aXRhYmxlIHRv
b2xzIHRoYXQgbWlycm9yIHRoZSBjdXJyZW50IG1vZGVsaW5nIHN0cmF0ZWdpZXMuDQo+ID4+ICAg
ICBCb3RoIHRoZSBOTURBIGFuZCB0aGUgbm9uLU5NREEgbW9kdWxlcyBTSE9VTEQgYmUgcHVibGlz
aGVkIGluDQo+ID4+ICAgICB0aGUgc2FtZSBkb2N1bWVudCwgd2l0aCBOTURBIG1vZHVsZXMgaW4g
dGhlIGRvY3VtZW50IG1haW4gYm9keQ0KPiA+PiAgICAgYW5kIHRoZSBub24tTk1EQSBtb2R1bGVz
IGluIGEgbm9uLW5vcm1hdGl2ZSBhcHBlbmRpeC4gIFRoZSB1c2UNCj4gPj4gICAgIG9mIHRoZSBu
b24tTk1EQSBtb2RlbCB3aWxsIGFsbG93IHRlbXBvcmFyeSBicmlkZ2luZyBvZiB0aGUNCj4gPj4g
ICAgIHRpbWUgcGVyaW9kIHVudGlsIE5NREEgaW1wbGVtZW50YXRpb25zIGFyZSBhdmFpbGFibGUu
DQo+ID4+DQo+ID4+ICAgICAoYykgRm9yIHB1Ymxpc2hlZCBtb2RlbHMsIHRoZSBtb2RlbCBzaG91
bGQgYmUgcmVwdWJsaXNoZWQgd2l0aA0KPiA+PiAgICAgYW4gTk1EQS1jb21wYXRpYmxlIHN0cnVj
dHVyZSwgZGVwcmVjYXRpbmcgbm9uLU5NREEgY29uc3RydWN0cy4NCj4gPj4gICAgIEZvciBleGFt
cGxlLCB0aGUgImlldGYtaW50ZXJmYWNlcyIgbW9kZWwgaW4gXlJGQzcyMjNeIHdpbGwgYmUNCj4g
Pj4gICAgIHJlc3RydWN0dXJlZCBhcyBhbiBOTURBLWNvbXBhdGlibGUgbW9kZWwuICBUaGUNCj4g
Pj4gICAgICIvaW50ZXJmYWNlcy1zdGF0ZSIgaGllcmFyY2h5IHdpbGwgYmUgbWFya2VkICJzdGF0
dXMNCj4gPj4gICAgIGRlcHJlY2F0ZWQiLiAgTW9kZWxzIHRoYXQgbWFyayB0aGVpciAiL2Zvby1z
dGF0ZSIgaGllcmFyY2h5DQo+ID4+ICAgICB3aXRoICJzdGF0dXMgZGVwcmVjYXRlZCIgd2lsbCBh
bGxvdyBOTURBLWNhcGFibGUNCj4gPj4gICAgIGltcGxlbWVudGF0aW9ucyB0byBhdm9pZCB0aGUg
Y29zdCBvZiBkdXBsaWNhdGluZyB0aGUgc3RhdGUNCj4gPj4gICAgIG5vZGVzLCB3aGlsZSBlbmFi
bGluZyBub24tTk1EQS1jYXBhYmxlIGltcGxlbWVudGF0aW9ucyB0bw0KPiA+PiAgICAgdXRpbGl6
ZSB0aGVtIGZvciBhY2Nlc3MgdG8gdGhlIG9wZXJhdGlvbmFsIHZhbHVlcy4NCj4gPj4NCj4gPj4g
ICAgIChkKSBGb3IgbW9kZWxzIHRoYXQgYXVnbWVudCBtb2RlbHMgd2hpY2ggaGF2ZSBub3QgYmVl
bg0KPiA+PiAgICAgc3RydWN0dXJlZCB3aXRoIHRoZSBOTURBLCB0aGUgbW9kZWxlciB3aWxsIGhh
dmUgdG8gY29uc2lkZXINCj4gPj4gICAgIHRoZSBzdHJ1Y3R1cmUgb2YgdGhlIGJhc2UgbW9kZWwg
YW5kIHRoZSBndWlkZWxpbmVzIGxpc3RlZA0KPiA+PiAgICAgYWJvdmUuICBXaGVyZSBwb3NzaWJs
ZSwgc3VjaCBtb2RlbHMgc2hvdWxkIG1vdmUgdG8gbmV3DQo+ID4+ICAgICByZXZpc2lvbnMgb2Yg
dGhlIGJhc2UgbW9kZWwgdGhhdCBhcmUgTk1EQS1jb21wYXRpYmxlLiAgV2hlbg0KPiA+PiAgICAg
dGhhdCBpcyBub3QgcG9zc2libGUsIGF1Z21lbnRpbmcgInN0YXRlIiBjb250YWluZXJzIFNIT1VM
RCBiZQ0KPiA+PiAgICAgYXZvaWRlZCwgd2l0aCB0aGUgZXhwZWN0YXRpb24gdGhhdCB0aGUgYmFz
ZSBtb2RlbCB3aWxsIGJlDQo+ID4+ICAgICByZS1yZWxlYXNlZCB3aXRoIHRoZSBzdGF0ZSBjb250
YWluZXJzIG1hcmtlZCBhcyBkZXByZWNhdGVkLg0KPiA+PiAgICAgSXQgaXMgUkVDT01NRU5ERUQg
dG8gYXVnbWVudCBvbmx5IHRoZSAiL2ZvbyIgaGllcmFyY2h5IG9mIHRoZQ0KPiA+PiAgICAgYmFz
ZSBtb2RlbC4gIFdoZXJlIHRoaXMgcmVjb21tZW5kYXRpb24gY2Fubm90IGJlIGZvbGxvd2VkLA0K
PiA+PiAgICAgdGhlbiBhbnkgbmV3ICJzdGF0ZSIgZWxlbWVudHMgU0hPVUxEIGJlIGluY2x1ZGVk
IGluIHRoZWlyIG93bg0KPiA+PiAgICAgbW9kdWxlLg0KPiA+Pg0KPiA+PiAgICAgVG8gY3JlYXRl
IHRoZSB0ZW1wb3Jhcnkgbm9uLU5NREEgbW9kZWwgZnJvbSBhbiBOTURBIG1vZGVsLCB0aGUNCj4g
Pj4gICAgIGZvbGxvd2luZyBzdGVwcyBjYW4gYmUgdGFrZW46DQo+ID4+ICAgIA0KPiA+PiAgICAg
LSBSZW5hbWUgdGhlIG1vZHVsZSBuYW1lIGJ5IHBvc3RwZW5kaW5nICItc3RhdGUiIHRvIHRoZQ0K
PiA+PiAgICAgICBvcmlnaW5hbCBtb2R1bGUncyBuYW1lDQo+ID4+ICAgICAtIENoYW5nZSB0aGUg
bmFtZXNwYWNlIGJ5IHBvc3RwZW5kaW5nICItc3RhdGUiIHRvIHRoZSBvcmlnaW5hbA0KPiA+PiAg
ICAgICBuYW1lc3BhY2UgdmFsdWUNCj4gPj4gICAgIC0gQ2hhbmdlIHRoZSBwcmVmaXggYnkgcG9z
dHBlbmRpbmcgIi1zIiB0byB0aGUgb3JpZ2luYWwgcHJlZml4DQo+ID4+ICAgICAgIHZhbHVlDQo+
ID4+ICAgICAtIFNldCBhbGwgdG9wLWxldmVsIG5vZGVzIHRvIGhhdmUgYSAiY29uZmlnIiBzdGF0
ZW1lbnQgb2YNCj4gPj4gICAgICAgdmFsdWUgImZhbHNlIg0KPiA+PiAgICAgLSBhZGQgYW4gaW1w
b3J0IHRvIHRoZSBvcmlnaW5hbCBtb2R1bGUgKGUuZy4sIGZvciB0eXBlZGVmDQo+ID4+ICAgICAg
IGRlZmluaXRpb25zKQ0KPiA+PiAgICAgLSBtb2RpZnkgYW55IGltcG9ydHMsIHVzZWQgZm9yIGxl
YWZyZWZzIG9yIGlkZW50aXR5cmVmcywgdG8NCj4gPj4gICAgICAgaW1wb3J0IHRoZSAtc3RhdGUg
dmVyc2lvbiBvZiB0aGUgbW9kdWxlDQo+ID4+ICAgICAtIHJlbW92ZSBhbnkgJ3R5cGVkZWYnIG9y
ICdpZGVudGl0eScgZGVmaW5pdGlvbnMNCj4gPj4gICAgIC0gcHJlZml4IGFueSB1c2VzIG9mIHRo
ZSB0eXBlZGVmcyBhbmQgaWRlbnRpdGllcyBhY2NvcmRpbmdseQ0KPiA+PiAgICAgLSB1cGRhdGUg
bGVhZnJlZiBhbmQgYXVnbWVudCBwYXRocyB0byB1c2UgdGhlIG5ldyAiLXMiIHByZWZpeA0KPiA+
Pg0KPiA+PiBGb3IgbWUgKHdpdGggYW55L2FsbCBoYXRzKSB0aGUga2V5IGRvd25zaWRlIGlzIHRo
YXQgd2UnbGwgbmVlZCB0byAgcmV2DQo+ID4+IHRoaXMgdGV4dCAoYWdhaW4pIGluIHRoZSBub3Qg
dG9vIGRpc3RhbnQgZnV0dXJlLCBidXQgdGhhdCB3ZSBkb24ndCBoYXZlDQo+ID4+IGFuIGFsdGVy
bmF0aXZlIGFzIExDIG9uIHRoZSBmdWxsIHNvbHV0aW9uIGlzIHN0aWxsIGEgYml0IGF3YXkuDQo+
ID4+DQo+ID4+IFdoYXQgZG8gcGVvcGxlIHRoaW5rPyAgDQo+ID4+DQo+ID4+IExvdQ0KPiA+Pg0K
PiA+Pg0KPiA+PiBPbiA4LzIyLzIwMTcgMzo1MyBQTSwgS2VudCBXYXRzZW4gd3JvdGU6DQo+ID4+
ID4gSGksDQo+ID4+ID4NCj4gPj4gPiBEdXJpbmcgdGhlIG1lZXRpbmcgaW4gQ2hpY2FnbywgdGhl
IE5NREEgYXV0aG9ycyB0b29rIGFuIGFjdGlvbiB0bw0KPiA+PiA+IHByb3Bvc2Ugc29tZSB0ZXh0
IGZvciBTNC4yMy4gIEFmdGVyIGEgbGl0dGxlIHJldmlldywgdGhlIGZvbGxvd2luZw0KPiA+PiA+
IGVtZXJnZWQuICBZZXMsIGl0J3Mgc2hvcnQsIGJ1dCB3YXMgYW55dGhpbmcgbGVmdCBhbnl0aGlu
ZyBvdXQ/DQo+ID4+ID4NCj4gPj4gPg0KPiA+PiA+ID09PT09U1RBUlQ9PT09PQ0KPiA+PiA+DQo+
ID4+ID4gNC4yMyBPcGVyYXRpb25hbCBEYXRhDQo+ID4+ID4NCj4gPj4gPiBPcGVyYXRpb25hbCBk
YXRhIGluY2x1ZGVzIGJvdGggY29uZmlnICJmYWxzZSIgbm9kZXMgYXMgd2VsbCBhcywNCj4gPj4g
PiBvbiBzZXJ2ZXJzIHN1cHBvcnRpbmcgPG9wZXJhdGlvbmFsPiBbZHJhZnQtaWV0Zi1uZXRtb2Qt
cmV2aXNlZC1kYXRhc3RvcmVzXSwNCj4gPj4gPiB0aGUgYXBwbGllZCB2YWx1ZSBvZiBjb25maWcg
InRydWUiIG5vZGVzLg0KPiA+PiA+DQo+ID4+ID4gWUFORyBtb2R1bGVzIFNIT1VMRCBiZSBkZXNp
Z25lZCBhc3N1bWluZyB0aGV5IHdpbGwgYmUgdXNlZCBvbg0KPiA+PiA+IHNlcnZlcnMgc3VwcG9y
dGluZyA8b3BlcmF0aW9uYWw+LiAgV2l0aCB0aGlzIGluIG1pbmQsIFlBTkcNCj4gPj4gPiBtb2R1
bGVzIFNIT1VMRCBkZWZpbmUgY29uZmlnICJmYWxzZSIgd2hlcmV2ZXIgdGhleSBtYWtlIHNlbnNl
DQo+ID4+ID4gdG8gdGhlIGRhdGEgbW9kZWwuICBDb25maWcgImZhbHNlIiBub2RlcyBTSE9VTEQg
Tk9UIGJlIGRlZmluZWQNCj4gPj4gPiB0byBwcm92aWRlIHRoZSBvcGVyYXRpb25hbCB2YWx1ZSBm
b3IgY29uZmlndXJhdGlvbiBub2RlcywNCj4gPj4gPiBleGNlcHQgd2hlbiB0aGUgdmFsdWUgc3Bh
Y2Ugb2YgYSBjb25maWd1cmVkIGFuZCBvcGVyYXRpb25hbA0KPiA+PiA+IHZhbHVlcyBtYXkgZGlm
ZmVyLCBpbiB3aGljaCBjYXNlIGEgZGlzdGluY3QgY29uZmlnICJmYWxzZSINCj4gPj4gPiBub2Rl
IFNIT1VMRCBiZSBkZWZpbmVkIHRvIGhvbGQgdGhlIG9wZXJhdGlvbmFsIHZhbHVlIGZvciB0aGUN
Cj4gPj4gPiBjb25maWd1cmVkIG5vZGUuDQo+ID4+ID4NCj4gPj4gPiA9PT09PVNUT1A9PT09PQ0K
PiA+PiA+DQo+ID4+ID4NCj4gPj4gPiBPbmUgcXVlc3Rpb24gdGhhdCBjYW1lIHVwIGlzIGlmICJv
cGVyYXRpb25hbCBkYXRhIiBpcyBhIHdlbGwtZGVmaW5lZA0KPiA+PiA+IHRlcm0uICBUaGlzIHN0
cmluZyBhcHBlYXJzIDEwIHRpbWVzIGluIHJmYzYwODdiaXMuICBNb3N0IGludGVyZXN0aW5nbHks
DQo+ID4+ID4gYXBwZW5kaXggU2VjdGlvbiBBLjguICh2MDUgdG8gdjA2KSBpbmNsdWRlcyB0aGlz
IGxpbmUgaXRlbToNCj4gPj4gPg0KPiA+PiA+ICAgICBDaGFuZ2VkIHRlcm0gIm9wZXJhdGlvbmFs
IHN0YXRlIiB0byAib3BlcmF0aW9uYWwgZGF0YSINCj4gPj4gPg0KPiA+PiA+IFNvIGl0IHNlZW1z
IHRvIGJlIGRlbGliZXJhdGUuLi4NCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4gS2VudCAgLy8gY29u
dHJpYnV0b3INCj4gPj4gPg0KPiA+PiA+DQo+ID4+ID4NCj4gPj4gPiBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+PiA+IG5ldG1vZCBtYWlsaW5nIGxp
c3QNCj4gPj4gPiBuZXRtb2RAaWV0Zi5vcmcNCj4gPj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9t
YWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPiA+PiA+DQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IG5ldG1vZCBtYWlsaW5nIGxp
c3QNCj4gPj4gbmV0bW9kQGlldGYub3JnDQo+ID4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt
YW4vbGlzdGluZm8vbmV0bW9kDQo+ID4NCj4gPiAtLQ0KPiA+IEp1ZXJnZW4gU2Nob2Vud2FlbGRl
ciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+ID4gUGhvbmU6ICs0
OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2Vy
bWFueQ0KPiA+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFj
b2JzLXVuaXZlcnNpdHkuZGUvPg0KPiA+DQo+IA0KDQotLSANCkp1ZXJnZW4gU2Nob2Vud2FlbGRl
ciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQpQaG9uZTogKzQ5IDQy
MSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55
DQpGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2
ZXJzaXR5LmRlLz4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KDQo=


From nobody Wed Aug 23 09:46:15 2017
Return-Path: 
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 055281329D2 for ; Wed, 23 Aug 2017 09:46:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.91
X-Spam-Level: 
X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
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 Cs-BnTL57qZx for ; Wed, 23 Aug 2017 09:46:09 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0127.outbound.protection.outlook.com [104.47.2.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D533F1329C9 for ; Wed, 23 Aug 2017 09:46:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Vp94IoSajGBLXJDANW2F4OdaGB/VPMFVT3lmrmb/+dM=; b=OlTYJMTOB8fhPiv9EPGDTzyFbsT9swLTpjE6eJ06S8orNi1evR+jc+S6EJb73YeRWn2kAi9bGGRo5UpvPtuGaHKQYNVkkWKirFfVaWfOlsPqcLnTZ6ZK/SHPXZVHgOS5qCtVpIZpuoHGsgn8JkZAL4G8xGtQbklOMDxcGh0Yfbg=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (86.174.236.116) by DB6PR0701MB2997.eurprd07.prod.outlook.com (2603:10a6:4:73::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1385.4; Wed, 23 Aug 2017 16:46:03 +0000
Message-ID: <01de01d31c2f$2a7c34a0$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Ladislav Lhotka" , , "Andy Bierman" 
References:  <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com>  <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com>   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>   <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com> <044b01d31bf4$d3b37500$4001a8c0@gateway.2wire.net> <87vale1ro2.fsf@cesnet.cz>
Date: Wed, 23 Aug 2017 17:28:49 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.174.236.116]
X-ClientProxiedBy: HE1P18901CA0004.EURP189.PROD.OUTLOOK.COM (2603:10a6:3:8b::14) To DB6PR0701MB2997.eurprd07.prod.outlook.com (2603:10a6:4:73::7)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 68aaab07-e1cc-4a4a-b512-08d4ea4671fa
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:DB6PR0701MB2997; 
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 3:Q2e8VqfMGcJauS3egu/vxSRHaJBZxMBuz08MXdYA1mkp+tuWrAKn6Ihg9G/TJHJo0mps7uBfB0S5c5gf897Nmkw+9HsYKTpfjZRAYAtXemBirlO0ryqBowlXozV3NVPwoxprvJdRbNM9b0rlwmV85jJm9FKF+EAyAr5USeDXBIfwMoGqxEnJ5hTlwbKLjuq6pis04vJDAY6Sztml72Gets16QStjwKQYWZuP2wYY3GFySWKaoRVdQyl+qKEpqhOz; 25:xcs+42PSXVIIF+mQo8Zw0IKJoW0Y2/HPseJZmm5gtLcdDogzzyruJZpWRKzQrbWXuIHNTCVKJ0cZTRFpYYJnZcjOXUGcwnJWQ8F7n9F461DLwwPm+zQVcaS6jw0mmQklIj4QKO4h3z8Dta1NOdsvniSPqr8VtYrqQ4X8oIQKFKB9erwJ2KQlZWE5CycnwqGS+4mu89dSWSo4b9dVQEEBwQaksh+ZBTdFZes+S9RdJ4GWX3Zg3kR8XtKvL5qIFSarIiXTKrRolbBTwtXpyy2yGykLOVNFw3D4AkWmr4oGDqG9hX+qITLtwISn5lqV16jUG07sD00cG88/As8YahdHXw==; 31:G17tc+YbRLfxCsZnHlx2jRa2SbeSpZD+In/DxhdOSevuKOP08KI/MRT7UbHkok/2w+PGr9b4txsWMjKf7YgsVxr57S202nEp++4WtHSDDlSE9Rfh1536FOduwlgnCr7KAqlvp30JM6Q3kpOKMqp73VHcLY+8b0ZzNewcVxha7DCWGAJzVfYd/Ztv5J9E6Uwc6bnlz3r4GDipuWErOSvHEOTKfwB9rybhcJeCt39FkFc=
X-MS-TrafficTypeDiagnostic: DB6PR0701MB2997:
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 20:LX+nUdqeysBqV3xBxaTghaKq21Yj+lvGiht8IG3M1a0/kAhQ3ysvzc7xTmx/XYfumCXRMluweb5aX2F9DgHl8asfnMnWU870uer2xG4enWD57+d+thbH/ZUUCQtXFUBOQyvbfoxa0gezS0BC4mcDU/GIWX/uhIxHf/486ATx1AzYmTnx0J81SGUlAkHc8q+vmxgxZZpQuuJfRLBlel0c+pyBQylE42Zd+0Q9LVLLTKhQIoDKMT+ZW4No8FYUE0rj; 4:F0en5qql+u1eTwhG26XtmjeER20tLChlYenGvPiMxgnuag2fsPdphIsvkWGb91IS1F2YDGl+hnynADV0DF+xE1sJOpJ4rXeO4kyZutgGQ7E1bXNc5Y0ILouDqoYAvNYRZQPk1mfy0m6FtFWE4dTsjflsxfEXr92RleYP0Evj8/ytd5pIr5rNK8IjBwC8r4jtjcwzPKo4Ezkgk3OR7JWYTbWGcF/JVeMXevd9adB8WjAHCAaYn9Hib90fjYh7+3QWl0ggkkVAGXttKgBmb8gJvam9hNUR/M/30ayxRLOT3ZyZu9cZAffWDpWj2wmPHqPNf5BqsuXzAuupifMgSbDIUf0Uclb6IHLMlN0Grw2Px/TW0CIYv0Y+HChWsikAwvyTORmsn4OGxxJi/MxL4FJ0yg==
X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(10436049006162)(97927398514766)(95692535739014); 
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR0701MB2997; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR0701MB2997; 
X-Forefront-PRVS: 040866B734
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(7370300001)(6009001)(39860400002)(52314003)(24454002)(199003)(377454003)(189002)(13464003)(44736005)(76176999)(1556002)(114624004)(4720700003)(53936002)(62236002)(66066001)(53546010)(229853002)(47776003)(9686003)(44716002)(6666003)(6306002)(25786009)(50986999)(6246003)(230700001)(6496005)(81686999)(116806002)(7736002)(61296003)(93886005)(97736004)(2906002)(478600001)(68736007)(966005)(81166006)(81156014)(42186005)(8676002)(106356001)(305945005)(1456003)(50466002)(101416001)(6486002)(81816999)(5660300001)(23756003)(575784001)(86362001)(3846002)(189998001)(7350300001)(33646002)(50226002)(105586002)(84392002)(14496001)(6116002)(561944003)(74416001)(7726001)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2997; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB6PR0701MB2997; 23:U7FOHM+y3o3DUWwQHwI/sbor1WNyIwY/LlH4P?= =?iso-8859-1?Q?qeL6Ck4iE32ioS6qVFvjSAbRpqygmMdkaynI1fTnE+ECBR9fIG03Omh9ay?= =?iso-8859-1?Q?MNcalqWLtCCtalnynbXpjIMeEpkJ8MGyzfj7HL/O+WLtw9oJKbQxAOxF4J?= =?iso-8859-1?Q?fHHLMvhjslJQadMwVwZ7FYXkU2vjeTaRfAE8JlQ6rwMYtaZ/xRP3VAzSXo?= =?iso-8859-1?Q?LNNP/bAPNVh9/ppUoKwICNA/cgB6Y/9Hl3nVrLwlYTgXrX643TbhVVKgr7?= =?iso-8859-1?Q?YNdfsShsmy+MF8zXR/s05z5pIZhCYw5858SS5JtNNhYY0XGzcXrBMGwcq/?= =?iso-8859-1?Q?fyIbkqYeyYwoK6Zv037FR2f2s9W2YzJhcm6O59h6C3cbuFS3yFUZO1t/rP?= =?iso-8859-1?Q?6BRhGGED9V6FJq7O7iCH7UG2nt5aIr4lnDDyC86TigPfukrtlOe2yaxt9S?= =?iso-8859-1?Q?oyO8QlK7QmDcny/d900zc18/ao5UmwRRUCB4i7l37FKqp1XLkvFrbGgiNV?= =?iso-8859-1?Q?QIitvpyXSX8o9Rus4P/QYr0vq1t4Le6WrDVGlB3hyhANjGkNBZa3KzNQ2h?= =?iso-8859-1?Q?Liz7Xn+mCIxLs1esYsoaNgi8gXheEI/EPPwKhbUJEIQtbL9XBB357V2wHP?= =?iso-8859-1?Q?uQv9PQEd/0Zf61EsRqS0i2CCVJMQhn3sieewa3zTFYFfbnmImibJPs6G47?= =?iso-8859-1?Q?wphH06OUQ/gwvo7EpVyob4n2QHtjMdizUSw5AGyU8Ds8oqusaLZGWNlHx5?= =?iso-8859-1?Q?TqIzCp1n6l+M5hhvY4foO5HJGxcU6jV/f1fEmZlTWNkTNzTVzYOelrBVPD?= =?iso-8859-1?Q?l5JHB8XOSZ73bP5CGNGvo8uWnlfLdsgBsZSTDEXAEBUXzVXlDHv0nlQQMk?= =?iso-8859-1?Q?Avp9MfJS3vqoJZPsJaIIWp9PfHwCy2RZyvJ5hE7dQs0trMg3QroXWyV8N0?= =?iso-8859-1?Q?Vd7O98VGERa/5Vdx9bLZJ6qw5v8OmG9Hf5HzU9WFo+Vz4Iw55eWvK48RGM?= =?iso-8859-1?Q?doWPZx29jFOyzYhlRpsjO58mAqZNfZH8aPq1KyBRV8dq+gPY3YWGpgsLJH?= =?iso-8859-1?Q?KGYdvwC+kNF6ymD8Nvc+PhfPBekt5/XAS/YPpZ3dBPM9Zj+cB4bBAVNqgU?= =?iso-8859-1?Q?iEir8KhNpY76G0RGZUrAMLzKIy6eESv1hF41n0NXBLxKysUYkmRPzFBhuM?= =?iso-8859-1?Q?jYCY8U3s4bjtgbb4H76Bunte0fVHZVJy8WJngTG5cNk8eWbHcwhcwsof2v?= =?iso-8859-1?Q?/xxyH1TDY1twzUCCgoSiotR5LrjaPfH+dBuxlAC1YOn1XwZeW3M+1OXhwk?= =?iso-8859-1?Q?fOGIYyhQQY+MaoC9IUn5yxx2Mvb6n2L+6pL4I+Wlke4xUZyyW2+yrXnTQp?= =?iso-8859-1?Q?gt74fLkYSvxvXT2sIcEIblorH38dI5MD2o6x3bFRKUeafQL49EfWSzIDLj?= =?iso-8859-1?Q?AijlKhje294G8PCd+kLAeOGlM3f6/GR78AeBP5F9zzi1yHJjCS+iBfv6mA?= =?iso-8859-1?Q?sHn7VAdJM5iOI6l6KdlKdrSMx+bEkWUgVtCGfW0/9+lSegRfau+CZs7znO?= =?iso-8859-1?Q?TG0EgFNBrIYRY8r9SaY6+eRy7/MlOYaVNPxQi803lrPXdEHVy213RxC8jD?= =?iso-8859-1?Q?DFYpfzomqAAI2I0X70CnuFW7UN41pF1Fz1DZtx6vt7hghzHz9T6hyB3?=
X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 6:YTYSZ9hm2ZmOmik36MoD9UOAp+xk1fGqlI/OuZvVjplHm0PxPCbVIGEEuRP68tp6xJimM5H62k2bnxQn/+3eUVpbfs1Kjn9WjhBwraf1p+3F6ybymGluuL25tEQKdFWMSg3NH613L9wTs4EIB6rAYcfLdyqPivZFvsgE1F6SgAjEAsu163OHox09i3QsmZX64gcfMc6w/zm2G+g+iJ/SYGvIkTwycqomuoUTogYpfVrIcRo+lHKYmrwjttFW/8aoYkzGx17WZ/xNWup5CNGDqNFxwKFIJkvHoh3w8LOXfdL0WaX/N2efc5dIcpUm1zmULzWCQfuZMLSXIZo1+9F9JA==; 5:Pa1B+g2N33vmsupmuNn1IkWFXL2dCAPk9pITLoGj4vymvyzUqP4uj+Gd/YqcI9ZhPeDmO5/0qIo/Z/8wZR3s+XxBez7mOgABEnYm0XdpWGnTaQSSKx8RsGchaeoZ+IICEc7wUUf3QSuJbouexTCe6w==; 24:CWTU1Unzhfkk7SMV1hhDHipvzB81e3k4PZD8NegT5lFdW+2JIC/O6yo+0rnxeM+Vx7v9zu241YQDqPnzceWGw09AvPNTKv9tenco/1ISJhw=; 7:AewloI17Z3WHG9IamJ7/3NeqN0XjTVl/ZzaqXVXeOVIcPjUSVWnkPIgW2MND1OrRVggq7ubvuFBp/2Bky6nOTX3d+20AsPcwEsySCpZppe45thTnZta/3iiCDWA6YyyY7/6yEopT5WfZo9LzvWj3Y877aTJFwPkoT8siJ2+qnsly/ViDo4cM7nRXHMZJnUzdl4R5XxpeuSKhXiJzxmPTtbHHxqwHkL/ssyPktII5jag=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Aug 2017 16:46:03.9917 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2997
Archived-At: 
Subject: Re: [netmod] Pattern statements [was Re: 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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 16:46:13 -0000

----- Original Message -----
From: "Ladislav Lhotka" 
Sent: Wednesday, August 23, 2017 11:53 AM

> "t.petch"  writes:
>
> > ----- Original Message -----
> > From: "Robert Wilton" 
> > Sent: Monday, August 21, 2017 4:14 PM
> >
> >> That makes sense.

> >>
> >> Of course, this would allow more invalid values, but most servers
> > would
> >> be expected to reject those when it converts them into an internal
> >> binary format any way.
> >>
> >> What do you, and others, think?
> >
> > Simplify!
> >
> > Bear in mind that the regex for an IPv6 address was wrong for a long
> > time in base YANG before anyone noticed - it was just too complex.
>
> Why was it wrong? Just because it was too complex?

No; it contained a definite error.

This was probably in yang-types and probably around 2012, quite late in
the day, and it stuck in my mind that so many had looked at it and
failed to spot that it was wrong, not just that it did not cater for
some aspects such as interface I-D.  I have used it before as an example
of over complexity

I will have the e-mail filed, along with several thousand other NETMOD
ones so I will find it later rather than sooner.

Tom Petch



> >
> > And ABNF learnt long ago that just because something could be
expressed
> > in code does not mean that it is a good idea to do so.  If a simple
> > English statement replaces many lines of ABNF, then that is a good
> > tradeoff.
>
> Well, YANG models are also intended to be read by tools that so far
> don't understand English statements. Concerning human users, the
easiest
> thing might be to refer to a corresponding RFC, which the descriptions
> already do.
>
> >
> > Pragmatically I am not sure what the cutoff for complexity should be
but
> > it should be less than we have now.
> >
> > Paradoxically, given the original thread, the time when large
> > expressions may work ok is when they have a 'sub-module' like
structure,
> > when I can look at a group of lines in isolation and form a view of
what
> > it does then move on to the next group and so on, building up an
overall
> > picture piece by piece.
>
> Of course, regular expression languages are notorically human
> unfriendly, no matter what flavour we take. The ability to build them
> step by step from reusable pieces, e.g. using non-terminals, would
> certainly help.
>
> Lada
>
> >
> > Tom Petch
> >
> >> Thanks,
> >> Rob
> >>
> >>
> >> On 21/08/2017 15:01, Acee Lindem (acee) wrote:
> >> > Hi William, Rob, Andy,
> >> >
> >> > Given their limited usefulness and the detriments, perhaps we
should
> >> > discourage the creation of new submodules in RFC6087Bis.
> >> >
> >> > Thanks,
> >> > Acee
> >> >
> >> > On 8/21/17, 9:44 AM, "netmod on behalf of Ivory, William"
> >> > 
> > wrote:
> >> >
> >> >> Hi Rob,
> >> >>
> >> >> That would make it very hard to update existing 1.x YANG models
to
> > use
> >> >> new features in YANG 2.x if they used submodules.  Maybe that's
> > something
> >> >> that no one would ever consider doing anyway, or maybe YANG 1.1
> > already
> >> >> has similar differences to 1.0?  I had (perhaps naively) assumed
> > that you
> >> >> could migrate a namespace / model from YANG 1.0 to 2.0?
> >> >>
> >> >> Regards,
> >> >>
> >> >> William
> >> >>
> >> >> -----Original Message-----
> >> >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of
Robert
> > Wilton
> >> >> Sent: 21 August 2017 11:24
> >> >> To: netmod@ietf.org
> >> >> Subject: Re: [netmod] Query about augmenting module from
submodule
> > in
> >> >> YANG 1.0
> >> >>
> >> >>
> >> >>
> >> >> On 09/08/2017 16:13, Juergen Schoenwaelder wrote:
> >> >>> On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka
wrote:
> >> >>>> I remember that in early stages of YANG there was some
irrational
> >> >>>> fear of introducing too many namespaces, and submodules may be
a
> >> >>>> consequence of it. As you write, submodules provide no
benefits
> >> >>>> whatsoever in terms of modularity, but the overhead in terms
of
> >> >>>> metadata, IANA registration etc. is pretty much the same as
for
> >> >>>> modules.
> >> >>> In case YANG 2.0 is ever done, I suggest someone files a
proposal
> > to
> >> >>> remove submodules if the cost/benefit ratio is at odds. There
is
> >> >>> nothing wrong with removing stuff that has been found
problematic.
> >> >> I agree.
> >> >>
> >> >> I've added
> >> >>
> >
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmod-2
> > Dw
> >> >>
> >
g_yang-2Dnext_issues_26&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYi
> > aQ
> >> >>
> >
2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7
> > ow
> >> >> I&s=-kR4fUtXArQy0RwWb32DpT1bP4X_cNqt2zJVoC0JiX8&e=
> >> >>
> >> >> Rob
> >> >>
> >> >>> The motivation for submodules was that organizations
maintaining
> > large
> >> >>> modules with multiple people can do so without having to mess
> > around
> >> >>> with tools like m4 scripts to produce a single module from
> > 'snippets'
> >> >>> and to avoid integration surprises. But perhaps using m4
scripts
> > and
> >> >>> decent version control systems (that can integrate and compile
on
> >> >>> checkin) is indeed cheaper than having submodules part of the
YANG
> >> >>> language itself.
> >> >>>
> >> >>> /js
> >> >>>
> >> >> _______________________________________________
> >> >> netmod mailing list
> >> >> netmod@ietf.org
> >> >>
> >
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailma
> > n_
> >> >>
> >
listinfo_netmod&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqw
> > ky
> >> >>
> >
XmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7owI&s=t7
> > vG
> >> >> IH8ABuAm00e-bkSowD9eawModGq0N2OkjANtpYI&e=
> >> >>
> >> >> _______________________________________________
> >> >> 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 mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Aug 23 09:56:06 2017
Return-Path: 
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 C6A0E132113 for ; Wed, 23 Aug 2017 09:56:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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
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 8qeJ6szYxD-3 for ; Wed, 23 Aug 2017 09:56:04 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D164E13208E for ; Wed, 23 Aug 2017 09:56:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2319; q=dns/txt; s=iport; t=1503507363; x=1504716963; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=1K8A77SKHJnA5D+eF2AYsyi1nr417k6FBHe9jvrbRVo=; b=gBj9uwGg285E/JEin/TA7N6oEOebS8lYpJRan6j7JnZIKJ8lw4G61LLT zib/P3e7HLw0i/g3ijn5Y0i4oinBA1kHXJ1pEoSED7dw5zgMlfpvhJCfl nrR/lIA4YgIUUWStaGVCE5LeUO9NL1568fV64DN9DeC09gOU/wIbnRPoS Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DjAQDOsp1Z/xbLJq1aAxoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYMtkS6RF5YyggSFRwKFCRQBAgEBAQEBAQFrHQuFGAEBAQECASMVUQs?= =?us-ascii?q?YAgImAgJXBg0IAQGKJQiwQ4Imi2EBAQEBAQEBAwEBAQEBAQEhgQ2CHYNOgg6Bc?= =?us-ascii?q?Fg0hEABEgFAJoJMgmEFoFiLK4kZghKJPCSGco0+iHA2IX8LMiEIHBVJhUyBTz+?= =?us-ascii?q?IeA0XB4IUAQEB?=
X-IronPort-AV: E=Sophos;i="5.41,417,1498521600"; d="scan'208";a="655164264"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Aug 2017 16:55:59 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7NGtxhr019676 for ; Wed, 23 Aug 2017 16:55:59 GMT
To: "netmod@ietf.org" 
References:   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>   <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com> <5929631c-e51d-ae66-52d1-cbc87ca3506b@transpacket.com> <321a45fb-77e1-23c7-184b-d3bff9d41c39@cisco.com> <20170823133657.76s5wbcxbpgjfkiy@elstar.local>
From: Robert Wilton 
Message-ID: <1dc6969a-af55-e28a-447f-ad5092d26ec1@cisco.com>
Date: Wed, 23 Aug 2017 17:55:59 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20170823133657.76s5wbcxbpgjfkiy@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Pattern statements [was Re: 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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 16:56:06 -0000

On 23/08/2017 14:36, Juergen Schoenwaelder wrote:
> On Wed, Aug 23, 2017 at 02:23:12PM +0100, Robert Wilton wrote:
>> 1) Email address.  I understand that the full regex to validate all email
>> addresses is very complex, but checking that it at least contains an @
>> symbol still has benefit.  It would seem that a short imperfect regex is
>> better than a complete perfect regex.
> What is your definition of 'better'? A stricter pattern catches more
> errors. An imperfect pattern is better than none.
My definition of 'better' is:
- is relatively easy for a human to read/review.
- doesn't exclude any valid values.
- doesn't check numerical ranges, only the number of digits.
- is simple enough to trivially work with most normal regex engines.
- otherwise the pattern is as strict as possible given the constraints 
above.

>
>> 2) A list of VLAN ranges, e.g. want to allow strings that look like this:
>> "1-10,20-400,600,2000-3000", but only with non overlapping values in
>> ascending order.  It is easy to write a regex to check that the structure is
>> right, but AFAIK it is hard (impossible?) to write a regex that ensures that
>> the ranges don't overlap and are specified in ascending order.
> So what. Does this provide a helpful argument whether patterns should
> be strict or imperfect?
My point is only that it is very easy to produce invalid config that 
passes whatever regex is used so it is better to produce a simpler and 
more human readable regex rather than expand it to perform range 
checking of numerical values as well.

>
>> So, I propose that we use regexes for checking that the string is
>> structurally correct, but don't use regexes to perform numerical range
>> checks of string encoded numbers, since it makes the regexes hard to
>> read/verify, and doesn't improve the readability of the YANG file either.
> So here is the point I think:
>
>     It is desirable that regexes are as strict as they can be.
>     However, if regexes become so complicated that they become a
>     verification and maintenance problem by themself, then less strict
>     regexes may be a better choice.
I partly agree, but the line of where I would define a regex as being 
too complicated may be different from you ;-).

Thanks,
Rob

>
> /js
>


From nobody Wed Aug 23 09:56:23 2017
Return-Path: 
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 407DD13208E for ; Wed, 23 Aug 2017 09:56:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 LNMzoELq7WZL for ; Wed, 23 Aug 2017 09:56:02 -0700 (PDT)
Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E01B132025 for ; Wed, 23 Aug 2017 09:56:02 -0700 (PDT)
Received: by mail-wr0-x22b.google.com with SMTP id k46so2303392wre.2 for ; Wed, 23 Aug 2017 09:56:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bJeL7w37TIZssiTVF8hxD275ejRSkeebbPLETHSk9cs=; b=r7eBnZE+Trcza/deO7eYJWlOXiU0vAVQs7mTvd1C0GgpxiXav9vgU0kpw8REhDEBwy EwDK8q61iAGwm/H9Of+o+tOmlDdb1yge1cNowQtSgBpXjnumgRJ8yY4uMLXV25nHfNpE lDUerExckGu6jbO1UE1e1z2/LHh808dho07BfIW8fIOuxtkn40Xct8r0b8kPuv4Z9TDY IhPmwsRifPXSyleo2EnLnCGzvdqeBR8efZ3va2sbyGzaHf/cbntA5ol7NGo05PzZEE/m d8pLZ0M5cW0fJYmIif62/EkY5UnZA34/Jz2g90L5V+2277BeHFQn+i/vUR+KIiRhmjbW M/HA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bJeL7w37TIZssiTVF8hxD275ejRSkeebbPLETHSk9cs=; b=Z106zSB/LDiv84wP8W+VskzqOZsNpzEWA3SmzeUXSw2n0gTKgeQFW1YrWUX4L5VNFJ akJZymSCCsz6d5IGTAebOwVQ+9TKFqAZbCVZ2dUEXOKeyiCEL0Qo9/QgmepKvM6KPijQ q3NHmVeNusOkLoDy/evO4pGsv/SRNKkxHw9ANXsQwCuD7m2UX7x3ESD+NIBiMYlLRZ4u Fg39hcVaS+FzE6NUdhCwra7kkXnNRYgdNcTK9jcsIQXoH9rCwcF3DOo3ZLW1gAm/tVYE CtK0NHCrPwKlZX+8n1foXGo2zohGklTBH3nonnplV0Gnro26XZ1AQluggna9U/l/Poae 14Fw==
X-Gm-Message-State: AHYfb5jzmpfHwsZxWcb1VHiPETLxkv+YAlO1FeI59m3uyOe1v8Zf8SxX b/pHORGupPjFgghabYpwx/jlpBUUoxKN
X-Received: by 10.223.171.90 with SMTP id r26mr1899473wrc.88.1503507360465; Wed, 23 Aug 2017 09:56:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.221 with HTTP; Wed, 23 Aug 2017 09:55:59 -0700 (PDT)
In-Reply-To: 
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local> <95c65e38-a117-592d-5c3f-06d31f8845fa@labn.net> <20170823125855.mfuel6iwv5sxl3wy@elstar.local> 
From: Andy Bierman 
Date: Wed, 23 Aug 2017 09:55:59 -0700
Message-ID: 
To: Kent Watsen 
Cc: Juergen Schoenwaelder , Lou Berger , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c1b4da023954c05576e9671"
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 16:56:06 -0000

--94eb2c1b4da023954c05576e9671
Content-Type: text/plain; charset="UTF-8"

Hi,

I think Lou's text is a good start for the replacement text.
We should finish the details and finish this document.
Ongoing tips and guidelines should go on a wiki.

The IETF cannot declare an official start and stop date for NMDA transition.
The community outside the NETMOD WG has yet to learn or care about NMDA.
Write exactly what you what them to do, as if they have not read the 14000
emails
that provide the context needed to know what "NMDA-compatible" means.


Andy



On Wed, Aug 23, 2017 at 9:38 AM, Kent Watsen  wrote:

>
> Just wondering, but is an RFC the appropriate vehicle for this content?
> Would a wiki be better?
>
> K.
>
>
> --
>
> Lets do it this way then. If we plan to revise this again in ~1 year,
> so be it. We started this revision in Feb 2014. ;-)
>
> /js
>
> On Wed, Aug 23, 2017 at 08:07:28AM -0400, Lou Berger wrote:
> > Juergen,
> >
> >
> > On August 23, 2017 2:17:43 AM Juergen Schoenwaelder
> >  wrote:
> >
> > > My preference is to have the guidelines say what people should do,
> > > namely design NMDA models. I would prefer to keep any transition
> > > aspects out of the guidelines.
> >
> > Well, this approach works for those who are deeply enmeshed in netmod
> > and the IETF, it doesn't help those designing models/solutions during
> > the current transition period.  IMO we can't forget about this important
> > class of model developers and users.
> >
> > > If people want to include transition
> > > aspects, it should be in the appendix (i.e., easy to remove / ignore
> > > later on).
> > >
> > I don't see a material difference here.  Either way the document needs
> > to be updated. See below for a specific proposed wording update.
> >
> > > I understand that there is a timing issue. The question is what you
> > > mean with "NMDA solution makes it to publication (request)". If you
> > > mean the core NMDA document, this is pretty much in reach and keeping
> > > this guidelines document on hold until then may be an option. If you
> > > mean the complete solution set, including model updates and moving the
> > > protocol extensions in NETCONF to publication request, then this may
> > > take a bit more time.
> > >
> > I mean the time when implementors can reasonably be told that the old
> > way has been replaced by a fully defined (and able to be implemented)
> > NMDA solution.  I think includes both netconf and restconf NMDA
> > definitions.  I don't think it's reasonable to require implementation of
> > drafts that are in-flux.
> >
> >
> >
> > > /js
> > >
> > > On Tue, Aug 22, 2017 at 04:32:14PM -0400, Lou Berger wrote:
> > >> Kent/WG,
> > >>
> > >>     This seems a bit terse to me and not provide needed guidance
> during
> > >> the current transition period.  I understood  the discussion ended up
> > >> with the options being to either (1) provide the guidance as a
> > >> standalone document, e.g., (a)-(s) in draft-dsdt-nmda-guidelines,
> with a
> > >> pointer to it from 6087bis or (2) just move those sections to 6087
> bis.
> > >> Either way, we'll need a new bis once the full NMDA solution makes it
> to
> > >> publication (request).
> > >>
> > >> I thought the plan was to do (s).  If so, we need the full text.
> > >> Looking at the current repo
> > >> (https://github.com/netmod-wg/datastore-dt/blob/master/
> guidelines/guidelines.txt)
> > >> it would be:
> > >>
> > >>     4.23 Operational Data
> > >>
> > >>     The following guidelines are meant to help modelers develop
> > >>     YANG models that will maximize the utility of the model with
> > >>     both current implementations and NMDA-capable implementations
> > >>     [draft-ietf-netmod-revised-datastores].
> > >>
> > remove (a) and re-letter rest of list
> > >>     (a) New models and models that are not concerned with the
> > >>     operational state of configuration information SHOULD
> > >>     immediately be structured to be NMDA-compatible.
> >
> > Add:
> >    The remaining options MAY be followed during the time that
> >    NMDA mechanisms are being defined.  These options will be
> >    removed in a future update of this document once this definition
> >    is complete.
> >
> > Does this work for you?  Moving it to an appendix just makes it harder
> > for the reader and, again, the document needs to be revised either way
> > in the future.
> >
> > Lou
> >
> > >>
> > >>     (b) Models that require immediate support for "in use" and
> > >>     "system created" information SHOULD be structured for NMDA.  A
> > >>     non-NMDA version of these models SHOULD exist, either an
> > >>     existing model or a model created either by hand or with
> > >>     suitable tools that mirror the current modeling strategies.
> > >>     Both the NMDA and the non-NMDA modules SHOULD be published in
> > >>     the same document, with NMDA modules in the document main body
> > >>     and the non-NMDA modules in a non-normative appendix.  The use
> > >>     of the non-NMDA model will allow temporary bridging of the
> > >>     time period until NMDA implementations are available.
> > >>
> > >>     (c) For published models, the model should be republished with
> > >>     an NMDA-compatible structure, deprecating non-NMDA constructs.
> > >>     For example, the "ietf-interfaces" model in ^RFC7223^ will be
> > >>     restructured as an NMDA-compatible model.  The
> > >>     "/interfaces-state" hierarchy will be marked "status
> > >>     deprecated".  Models that mark their "/foo-state" hierarchy
> > >>     with "status deprecated" will allow NMDA-capable
> > >>     implementations to avoid the cost of duplicating the state
> > >>     nodes, while enabling non-NMDA-capable implementations to
> > >>     utilize them for access to the operational values.
> > >>
> > >>     (d) For models that augment models which have not been
> > >>     structured with the NMDA, the modeler will have to consider
> > >>     the structure of the base model and the guidelines listed
> > >>     above.  Where possible, such models should move to new
> > >>     revisions of the base model that are NMDA-compatible.  When
> > >>     that is not possible, augmenting "state" containers SHOULD be
> > >>     avoided, with the expectation that the base model will be
> > >>     re-released with the state containers marked as deprecated.
> > >>     It is RECOMMENDED to augment only the "/foo" hierarchy of the
> > >>     base model.  Where this recommendation cannot be followed,
> > >>     then any new "state" elements SHOULD be included in their own
> > >>     module.
> > >>
> > >>     To create the temporary non-NMDA model from an NMDA model, the
> > >>     following steps can be taken:
> > >>
> > >>     - Rename the module name by postpending "-state" to the
> > >>       original module's name
> > >>     - Change the namespace by postpending "-state" to the original
> > >>       namespace value
> > >>     - Change the prefix by postpending "-s" to the original prefix
> > >>       value
> > >>     - Set all top-level nodes to have a "config" statement of
> > >>       value "false"
> > >>     - add an import to the original module (e.g., for typedef
> > >>       definitions)
> > >>     - modify any imports, used for leafrefs or identityrefs, to
> > >>       import the -state version of the module
> > >>     - remove any 'typedef' or 'identity' definitions
> > >>     - prefix any uses of the typedefs and identities accordingly
> > >>     - update leafref and augment paths to use the new "-s" prefix
> > >>
> > >> For me (with any/all hats) the key downside is that we'll need to  rev
> > >> this text (again) in the not too distant future, but that we don't
> have
> > >> an alternative as LC on the full solution is still a bit away.
> > >>
> > >> What do people think?
> > >>
> > >> Lou
> > >>
> > >>
> > >> On 8/22/2017 3:53 PM, Kent Watsen wrote:
> > >> > Hi,
> > >> >
> > >> > During the meeting in Chicago, the NMDA authors took an action to
> > >> > propose some text for S4.23.  After a little review, the following
> > >> > emerged.  Yes, it's short, but was anything left anything out?
> > >> >
> > >> >
> > >> > =====START=====
> > >> >
> > >> > 4.23 Operational Data
> > >> >
> > >> > Operational data includes both config "false" nodes as well as,
> > >> > on servers supporting  [draft-ietf-netmod-revised-
> datastores],
> > >> > the applied value of config "true" nodes.
> > >> >
> > >> > YANG modules SHOULD be designed assuming they will be used on
> > >> > servers supporting .  With this in mind, YANG
> > >> > modules SHOULD define config "false" wherever they make sense
> > >> > to the data model.  Config "false" nodes SHOULD NOT be defined
> > >> > to provide the operational value for configuration nodes,
> > >> > except when the value space of a configured and operational
> > >> > values may differ, in which case a distinct config "false"
> > >> > node SHOULD be defined to hold the operational value for the
> > >> > configured node.
> > >> >
> > >> > =====STOP=====
> > >> >
> > >> >
> > >> > One question that came up is if "operational data" is a well-defined
> > >> > term.  This string appears 10 times in rfc6087bis.  Most
> interestingly,
> > >> > appendix Section A.8. (v05 to v06) includes this line item:
> > >> >
> > >> >     Changed term "operational state" to "operational data"
> > >> >
> > >> > So it seems to be deliberate...
> > >> >
> > >> >
> > >> > Kent  // contributor
> > >> >
> > >> >
> > >> >
> > >> > _______________________________________________
> > >> > 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
> > >
> > > --
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   +49 421 200 3103         
> > >
> >
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> 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
>

--94eb2c1b4da023954c05576e9671
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

I think Lou's text is a good st=
art for the replacement text.
We should finish the details and fi=
nish this document.
Ongoing tips and guidelines should go on a wi=
ki.

The IETF cannot declare an official start and =
stop date for NMDA transition.
The community outside the NETMOD W=
G has yet to learn or care about NMDA.
Write exactly what you wha=
t them to do, as if they have not read the 14000 emails
that prov=
ide the context needed to know what "NMDA-compatible" means.


Andy



On Wed, Aug 23, =
2017 at 9:38 AM, Kent Watsen <kwatsen@juniper.net> wrote:<=
br>


Just wondering, but is an RFC the appropriate vehicle for this content?=C2=
=A0 Would a wiki be better?



K.





--



Lets do it this way then. If we plan to revise this again in ~1 year,

so be it. We started this revision in Feb 2014. ;-)



/js



On Wed, Aug 23, 2017 at 08:07:28AM -0400, Lou Berger wrote:

> Juergen,

>

>

> On August 23, 2017 2:17:43 AM Juergen Schoenwaelder

> <j.schoenwa=
elder@jacobs-university.de> wrote:

>

> > My preference is to have the guidelines say what people should do=
,

> > namely design NMDA models. I would prefer to keep any transition<=
br>
> > aspects out of the guidelines.

>

> Well, this approach works for those who are deeply enmeshed in netmod<=
br>
> and the IETF, it doesn't help those designing models/solutions dur=
ing

> the current transition period.=C2=A0 IMO we can't forget about thi=
s important

> class of model developers and users.

>

> > If people want to include transition

> > aspects, it should be in the appendix (i.e., easy to remove / ign=
ore

> > later on).

> >

> I don't see a material difference here.=C2=A0 Either way the docum=
ent needs

> to be updated. See below for a specific proposed wording update.

>

> > I understand that there is a timing issue. The question is what y=
ou

> > mean with "NMDA solution makes it to publication (request)&q=
uot;. If you

> > mean the core NMDA document, this is pretty much in reach and kee=
ping

> > this guidelines document on hold until then may be an option. If =
you

> > mean the complete solution set, including model updates and movin=
g the

> > protocol extensions in NETCONF to publication request, then this =
may

> > take a bit more time.

> >

> I mean the time when implementors can reasonably be told that the old<=
br>
> way has been replaced by a fully defined (and able to be implemented)<=
br>
> NMDA solution.=C2=A0 I think includes both netconf and restconf NMDA
> definitions.=C2=A0 I don't think it's reasonable to require im=
plementation of

> drafts that are in-flux.

>

>

>

> > /js

> >

> > On Tue, Aug 22, 2017 at 04:32:14PM -0400, Lou Berger wrote:

> >> Kent/WG,

> >>

> >>=C2=A0 =C2=A0 =C2=A0This seems a bit terse to me and not provi=
de needed guidance during

> >> the current transition period.=C2=A0 I understood=C2=A0 the d=
iscussion ended up

> >> with the options being to either (1) provide the guidance as =
a

> >> standalone document, e.g., (a)-(s) in draft-dsdt-nmda-guideli=
nes, with a

> >> pointer to it from 6087bis or (2) just move those sections to=
 6087 bis.

> >> Either way, we'll need a new bis once the full NMDA solut=
ion makes it to

> >> publication (request).

> >>

> >> I thought the plan was to do (s).=C2=A0 If so, we need the fu=
ll text.

> >> Looking at the current repo

> >> (https:=
//github.com/netmod-wg/datastore-dt/blob/master/guidelines/guidel=
ines.txt)

> >> it would be:

> >>

> >>=C2=A0 =C2=A0 =C2=A04.23 Operational Data

> >>

> >>=C2=A0 =C2=A0 =C2=A0The following guidelines are meant to help=
 modelers develop

> >>=C2=A0 =C2=A0 =C2=A0YANG models that will maximize the utility=
 of the model with

> >>=C2=A0 =C2=A0 =C2=A0both current implementations and NMDA-capa=
ble implementations

> >>=C2=A0 =C2=A0 =C2=A0[draft-ietf-netmod-revised-datastores=
].

> >>

> remove (a) and re-letter rest of list

> >>=C2=A0 =C2=A0 =C2=A0(a) New models and models that are not con=
cerned with the

> >>=C2=A0 =C2=A0 =C2=A0operational state of configuration informa=
tion SHOULD

> >>=C2=A0 =C2=A0 =C2=A0immediately be structured to be NMDA-compa=
tible.

>

> Add:

>=C2=A0 =C2=A0 The remaining options MAY be followed during the time tha=
t

>=C2=A0 =C2=A0 NMDA mechanisms are being defined.=C2=A0 These options wi=
ll be

>=C2=A0 =C2=A0 removed in a future update of this document once this def=
inition

>=C2=A0 =C2=A0 is complete.

>

> Does this work for you?=C2=A0 Moving it to an appendix just makes it h=
arder

> for the reader and, again, the document needs to be revised either way=


> in the future.

>

> Lou

>

> >>

> >>=C2=A0 =C2=A0 =C2=A0(b) Models that require immediate support =
for "in use" and

> >>=C2=A0 =C2=A0 =C2=A0"system created" information SHO=
ULD be structured for NMDA.=C2=A0 A

> >>=C2=A0 =C2=A0 =C2=A0non-NMDA version of these models SHOULD ex=
ist, either an

> >>=C2=A0 =C2=A0 =C2=A0existing model or a model created either b=
y hand or with

> >>=C2=A0 =C2=A0 =C2=A0suitable tools that mirror the current mod=
eling strategies.

> >>=C2=A0 =C2=A0 =C2=A0Both the NMDA and the non-NMDA modules SHO=
ULD be published in

> >>=C2=A0 =C2=A0 =C2=A0the same document, with NMDA modules in th=
e document main body

> >>=C2=A0 =C2=A0 =C2=A0and the non-NMDA modules in a non-normativ=
e appendix.=C2=A0 The use

> >>=C2=A0 =C2=A0 =C2=A0of the non-NMDA model will allow temporary=
 bridging of the

> >>=C2=A0 =C2=A0 =C2=A0time period until NMDA implementations are=
 available.

> >>

> >>=C2=A0 =C2=A0 =C2=A0(c) For published models, the model should=
 be republished with

> >>=C2=A0 =C2=A0 =C2=A0an NMDA-compatible structure, deprecating =
non-NMDA constructs.

> >>=C2=A0 =C2=A0 =C2=A0For example, the "ietf-interfaces&quo=
t; model in ^RFC7223^ will be

> >>=C2=A0 =C2=A0 =C2=A0restructured as an NMDA-compatible model.=
=C2=A0 The

> >>=C2=A0 =C2=A0 =C2=A0"/interfaces-state" hierarchy wi=
ll be marked "status

> >>=C2=A0 =C2=A0 =C2=A0deprecated".=C2=A0 Models that mark t=
heir "/foo-state" hierarchy

> >>=C2=A0 =C2=A0 =C2=A0with "status deprecated" will al=
low NMDA-capable

> >>=C2=A0 =C2=A0 =C2=A0implementations to avoid the cost of dupli=
cating the state

> >>=C2=A0 =C2=A0 =C2=A0nodes, while enabling non-NMDA-capable imp=
lementations to

> >>=C2=A0 =C2=A0 =C2=A0utilize them for access to the operational=
 values.

> >>

> >>=C2=A0 =C2=A0 =C2=A0(d) For models that augment models which h=
ave not been

> >>=C2=A0 =C2=A0 =C2=A0structured with the NMDA, the modeler will=
 have to consider

> >>=C2=A0 =C2=A0 =C2=A0the structure of the base model and the gu=
idelines listed

> >>=C2=A0 =C2=A0 =C2=A0above.=C2=A0 Where possible, such models s=
hould move to new

> >>=C2=A0 =C2=A0 =C2=A0revisions of the base model that are NMDA-=
compatible.=C2=A0 When

> >>=C2=A0 =C2=A0 =C2=A0that is not possible, augmenting "sta=
te" containers SHOULD be

> >>=C2=A0 =C2=A0 =C2=A0avoided, with the expectation that the bas=
e model will be

> >>=C2=A0 =C2=A0 =C2=A0re-released with the state containers mark=
ed as deprecated.

> >>=C2=A0 =C2=A0 =C2=A0It is RECOMMENDED to augment only the &quo=
t;/foo" hierarchy of the

> >>=C2=A0 =C2=A0 =C2=A0base model.=C2=A0 Where this recommendatio=
n cannot be followed,

> >>=C2=A0 =C2=A0 =C2=A0then any new "state" elements SH=
OULD be included in their own

> >>=C2=A0 =C2=A0 =C2=A0module.

> >>

> >>=C2=A0 =C2=A0 =C2=A0To create the temporary non-NMDA model fro=
m an NMDA model, the

> >>=C2=A0 =C2=A0 =C2=A0following steps can be taken:

> >>

> >>=C2=A0 =C2=A0 =C2=A0- Rename the module name by postpending &q=
uot;-state" to the

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0original module's name

> >>=C2=A0 =C2=A0 =C2=A0- Change the namespace by postpending &quo=
t;-state" to the original

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0namespace value

> >>=C2=A0 =C2=A0 =C2=A0- Change the prefix by postpending "-=
s" to the original prefix

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0value

> >>=C2=A0 =C2=A0 =C2=A0- Set all top-level nodes to have a "=
config" statement of

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0value "false"

> >>=C2=A0 =C2=A0 =C2=A0- add an import to the original module (e.=
g., for typedef

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0definitions)

> >>=C2=A0 =C2=A0 =C2=A0- modify any imports, used for leafrefs or=
 identityrefs, to

> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0import the -state version of the mo=
dule

> >>=C2=A0 =C2=A0 =C2=A0- remove any 'typedef' or 'ide=
ntity' definitions

> >>=C2=A0 =C2=A0 =C2=A0- prefix any uses of the typedefs and iden=
tities accordingly

> >>=C2=A0 =C2=A0 =C2=A0- update leafref and augment paths to use =
the new "-s" prefix

> >>

> >> For me (with any/all hats) the key downside is that we'll=
 need to=C2=A0 rev

> >> this text (again) in the not too distant future, but that we =
don't have

> >> an alternative as LC on the full solution is still a bit away=
.

> >>

> >> What do people think?

> >>

> >> Lou

> >>

> >>

> >> On 8/22/2017 3:53 PM, Kent Watsen wrote:

> >> > Hi,

> >> >

> >> > During the meeting in Chicago, the NMDA authors took an =
action to

> >> > propose some text for S4.23.=C2=A0 After a little review=
, the following

> >> > emerged.=C2=A0 Yes, it's short, but was anything lef=
t anything out?

> >> >

> >> >

> >> > =3D=3D=3D=3D=3DSTART=3D=3D=3D=3D=3D

> >> >

> >> > 4.23 Operational Data

> >> >

> >> > Operational data includes both config "false" =
nodes as well as,

> >> > on servers supporting <operational> [draft-ietf-ne=
tmod-revised-datastores],

> >> > the applied value of config "true" nodes.

> >> >

> >> > YANG modules SHOULD be designed assuming they will be us=
ed on

> >> > servers supporting <operational>.=C2=A0 With this =
in mind, YANG

> >> > modules SHOULD define config "false" wherever =
they make sense

> >> > to the data model.=C2=A0 Config "false" nodes =
SHOULD NOT be defined

> >> > to provide the operational value for configuration nodes=
,

> >> > except when the value space of a configured and operatio=
nal

> >> > values may differ, in which case a distinct config "=
;false"

> >> > node SHOULD be defined to hold the operational value for=
 the

> >> > configured node.

> >> >

> >> > =3D=3D=3D=3D=3DSTOP=3D=3D=3D=3D=3D

> >> >

> >> >

> >> > One question that came up is if "operational data&q=
uot; is a well-defined

> >> > term.=C2=A0 This string appears 10 times in rfc6087bis.=
=C2=A0 Most interestingly,

> >> > appendix Section A.8. (v05 to v06) includes this line it=
em:

> >> >

> >> >=C2=A0 =C2=A0 =C2=A0Changed term "operational state&=
quot; to "operational data"

> >> >

> >> > So it seems to be deliberate...

> >> >

> >> >

> >> > Kent=C2=A0 // contributor

> >> >

> >> >

> >> >

> >> > _______________________________________________

> >> > netmod mailing list

> >> > netmod@ietf.org
> >> > https://www.ietf.org/mailman/lis=
tinfo/netmod

> >> >

> >>

> >> _______________________________________________

> >> netmod mailing list

> >> netmod@ietf.org

> >> https://www.ietf.org/mailman/listinf=
o/netmod

> >

> > --

> > Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jac=
obs University Bremen gGmbH

> > Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus R=
ing 1 | 28759 Bremen | Germany

> > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0<http://www.jacobs-university.de/>

> >

>



--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>



_______________________________________________

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




--94eb2c1b4da023954c05576e9671--


From nobody Wed Aug 23 09:58:48 2017
Return-Path: 
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 61FE113208E for ; Wed, 23 Aug 2017 09:58:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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
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 pNaXKFK0LEo2 for ; Wed, 23 Aug 2017 09:58:46 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9419132025 for ; Wed, 23 Aug 2017 09:58:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2219; q=dns/txt; s=iport; t=1503507525; x=1504717125; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=UL7jgJPDG/BUQnuZyntcAJWo3Xh0+G1rsoqTdgYQ9CM=; b=FAp4qYbLObhvAZHaJ2/CXo041TzISL/PFg5gts/CEhT3rsHkpoj31N2p j+KywK4DSUd7fJ38J13zctwCwbnLxyVy+JhzIOgIEcy/hDdhB+QFLULea ONpMIqr9Mp17fckeFBP0QRPxREIhasqYx/Ije4tLfYrz6Id9+K/NJYZtQ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DiAQDOsp1Z/xbLJq1aAxoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAZRbkReWMoIEhUcChQkUAQIBAQEBAQEBayiFGAEBAQECASMPAQVGCwk?= =?us-ascii?q?CGAICJgICVwYBDAgBAYolCJJdnWaCJothAQEBAQEBAQMBAQEBAQEBASCBDYIdg?= =?us-ascii?q?06CDoFwWDSEQAESAUAmgkyCYQWgWIsriRmCEok8JIZyjT6IcDYhfwsyIQgcFUm?= =?us-ascii?q?FTIFPP4h4DRcHghQBAQE?=
X-IronPort-AV: E=Sophos;i="5.41,417,1498521600"; d="scan'208";a="655164329"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Aug 2017 16:58:41 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v7NGwfWq018232; Wed, 23 Aug 2017 16:58:41 GMT
To: Ladislav Lhotka , netmod@ietf.org
References:   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>   <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com> <5929631c-e51d-ae66-52d1-cbc87ca3506b@transpacket.com> <321a45fb-77e1-23c7-184b-d3bff9d41c39@cisco.com> <20170823133657.76s5wbcxbpgjfkiy@elstar.local> <1503498125.32530.12.camel@nic.cz>
From: Robert Wilton 
Message-ID: 
Date: Wed, 23 Aug 2017 17:58:41 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <1503498125.32530.12.camel@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Pattern statements [was Re: 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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 16:58:47 -0000

On 23/08/2017 15:22, Ladislav Lhotka wrote:
> Juergen Schoenwaelder píše v St 23. 08. 2017 v 15:36 +0200:
>> On Wed, Aug 23, 2017 at 02:23:12PM +0100, Robert Wilton wrote:
>>> 1) Email address.  I understand that the full regex to validate all email
>>> addresses is very complex, but checking that it at least contains an @
>>> symbol still has benefit.  It would seem that a short imperfect regex is
>>> better than a complete perfect regex.
>> What is your definition of 'better'? A stricter pattern catches more
>> errors. An imperfect pattern is better than none.
>>
>>> 2) A list of VLAN ranges, e.g. want to allow strings that look like this:
>>> "1-10,20-400,600,2000-3000", but only with non overlapping values in
>>> ascending order.  It is easy to write a regex to check that the structure is
>>> right, but AFAIK it is hard (impossible?) to write a regex that ensures that
>>> the ranges don't overlap and are specified in ascending order.
>> So what. Does this provide a helpful argument whether patterns should
>> be strict or imperfect?
>>
>>> So, I propose that we use regexes for checking that the string is
>>> structurally correct, but don't use regexes to perform numerical range
>>> checks of string encoded numbers, since it makes the regexes hard to
>>> read/verify, and doesn't improve the readability of the YANG file either.
>> So here is the point I think:
>>
>>     It is desirable that regexes are as strict as they can be.
>>     However, if regexes become so complicated that they become a
>>     verification and maintenance problem by themself, then less strict
>>     regexes may be a better choice.
> Either way, the regex must not produce false negatives, i.e. reject valid
> values. For some regexes this is what makes them complicated.
I agree.

>
> Also, I don't see any need for replacing existing patterns unless they are
> wrong.
I also agree.  I'm not trying to retroactively change existing regexes, 
just tweak the guidance when new regexes are being constructed so that 
they end up being a bit simpler.

Thanks,
Rob


>   We have descriptions to tell human readers about the permitted value set.
>
> Lada
>
>> /js
>>


From nobody Wed Aug 23 10:47:42 2017
Return-Path: 
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 413DD13239C for ; Wed, 23 Aug 2017 10:47:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CLzoWjJj46uL for ; Wed, 23 Aug 2017 10:47:37 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7967913213F for ; Wed, 23 Aug 2017 10:47:37 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 51C9B3C; Wed, 23 Aug 2017 19:47:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id tqxfwHvdSMDn; Wed, 23 Aug 2017 19:47:35 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 23 Aug 2017 19:47:36 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1660D200E2; Wed, 23 Aug 2017 19:47:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id el8OlLZp0NDP; Wed, 23 Aug 2017 19:47:35 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A56DA200E0; Wed, 23 Aug 2017 19:47:35 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 5351E404A05D; Wed, 23 Aug 2017 19:47:35 +0200 (CEST)
Date: Wed, 23 Aug 2017 19:47:35 +0200
From: Juergen Schoenwaelder 
To: Robert Wilton 
Cc: "netmod@ietf.org" 
Message-ID: <20170823174735.cdp5vrryaqas7l6g@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , "netmod@ietf.org" 
References: <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>   <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com> <5929631c-e51d-ae66-52d1-cbc87ca3506b@transpacket.com> <321a45fb-77e1-23c7-184b-d3bff9d41c39@cisco.com> <20170823133657.76s5wbcxbpgjfkiy@elstar.local> <1dc6969a-af55-e28a-447f-ad5092d26ec1@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1dc6969a-af55-e28a-447f-ad5092d26ec1@cisco.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] Pattern statements [was Re: 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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 17:47:40 -0000

On Wed, Aug 23, 2017 at 05:55:59PM +0100, Robert Wilton wrote:
> My definition of 'better' is:
> - is relatively easy for a human to read/review.

likely subjective

> - doesn't exclude any valid values.

obviously

> - doesn't check numerical ranges, only the number of digits.

seems arbitrary, why are numerical ranges special?

> - is simple enough to trivially work with most normal regex engines.

and I thought we rely on a standard...

> - otherwise the pattern is as strict as possible given the constraints
> above.

> > So here is the point I think:
> > 
> >     It is desirable that regexes are as strict as they can be.
> >     However, if regexes become so complicated that they become a
> >     verification and maintenance problem by themself, then less strict
> >     regexes may be a better choice.
> I partly agree, but the line of where I would define a regex as being too
> complicated may be different from you ;-).

Very likely and as frustrating as it is, there likely is no precise
guideline that does not leave room for interpretation. For me, the
more complex the pattern gets (and my bar for 'complex' is very low),
the more I am interested in test cases (valid data that must be
accepted by the pattern and invalid data that must be rejected by the
pattern). But yes, all this is somewhat subjective.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Aug 23 11:10:04 2017
Return-Path: 
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 E54511329C1 for ; Wed, 23 Aug 2017 11:10:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 8O3u4wC5UtxA for ; Wed, 23 Aug 2017 11:10:00 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81EF213239C for ; Wed, 23 Aug 2017 11:10:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 15BB61403A8A; Wed, 23 Aug 2017 20:09:58 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id cY-zaagLKdRe; Wed, 23 Aug 2017 20:09:58 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id E57291403A88; Wed, 23 Aug 2017 20:09:57 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZEMLRQVfOKpX; Wed, 23 Aug 2017 20:09:57 +0200 (CEST)
Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id C2DB0140395E; Wed, 23 Aug 2017 20:09:57 +0200 (CEST)
From: Vladimir Vassilev 
To: Robert Wilton , "netmod@ietf.org" 
References:   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>   <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com> <5929631c-e51d-ae66-52d1-cbc87ca3506b@transpacket.com> <321a45fb-77e1-23c7-184b-d3bff9d41c39@cisco.com> <20170823133657.76s5wbcxbpgjfkiy@elstar.local>
Message-ID: <9fc4b41f-5994-79f6-43dc-f3ba5b09f36d@transpacket.com>
Date: Wed, 23 Aug 2017 20:09:57 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0
MIME-Version: 1.0
In-Reply-To: <20170823133657.76s5wbcxbpgjfkiy@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Pattern statements [was Re: 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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 18:10:03 -0000

On 08/23/2017 03:36 PM, Juergen Schoenwaelder wrote:

> On Wed, Aug 23, 2017 at 02:23:12PM +0100, Robert Wilton wrote:
>> 1) Email address.  I understand that the full regex to validate all email
>> addresses is very complex, but checking that it at least contains an @
>> symbol still has benefit.  It would seem that a short imperfect regex is
>> better than a complete perfect regex.
> What is your definition of 'better'? A stricter pattern catches more
> errors. An imperfect pattern is better than none.
In the case of e-mail address string pattern complying without 
exceptions to rfc5322#section-3.4 specification a ~500 characters of 
pattern expression is needed. There is value in defining data types that 
can be automatically verified by YANG. IMO in this case a strict pattern 
is justified.
>> 2) A list of VLAN ranges, e.g. want to allow strings that look like this:
>> "1-10,20-400,600,2000-3000", but only with non overlapping values in
>> ascending order.  It is easy to write a regex to check that the structure is
>> right, but AFAIK it is hard (impossible?) to write a regex that ensures that
>> the ranges don't overlap and are specified in ascending order.
> So what. Does this provide a helpful argument whether patterns should
> be strict or imperfect?
IMO loading strings with semantics instead of using YANG is example of 
bad model design. There is no RFC (like in the e-mail example) that 
mandates use of string with complex format instead of YANG to model 
range configuration. Complex strings can and should be avoided in cases 
like this one.
>> So, I propose that we use regexes for checking that the string is
>> structurally correct, but don't use regexes to perform numerical range
>> checks of string encoded numbers, since it makes the regexes hard to
>> read/verify, and doesn't improve the readability of the YANG file either.
> So here is the point I think:
> c.
>     It is desirable that regexes are as strict as they can be.
>     However, if regexes become so complicated that they become a
>     verification and maintenance problem by themself, then less strict
>     regexes may be a better choice.
I agree. But it is the enthropy of having configuration that can not be 
strictly validated by model aware automation tools that has been the 
reason for introduction of leafref, must, when, range, pattern etc. So 
giving up the goal of handling validation in automated model driven way 
to the advantage of readability is a tough compromise.

I agree with Rob that the pattern in draft-ietf-rtgwg-routing-types-09 
is complicated to read. I have the feeling the design can be improved 
without compromising the strictnes of the data type. Redefinig the 
typedef as a union of 5 string based types with seperate strict patterns 
is one suggestion for moving logic from the string type to YANG.

Vladimir
> /js
>


From nobody Wed Aug 23 12:45:23 2017
Return-Path: 
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 D81351323FD for ; Wed, 23 Aug 2017 12:45:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 1ggU20cV6zcD for ; Wed, 23 Aug 2017 12:45:18 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 186D4132192 for ; Wed, 23 Aug 2017 12:45:18 -0700 (PDT)
Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id ECB6160991; Wed, 23 Aug 2017 21:45:15 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1503517516; bh=+YvReGNL/PHkcZ3vMCM9kU9KAtRBOYfBGKOsQMeE3u0=; h=From:To:Date; b=XDyNVjZAuufb9Usp/dLV7uW7b2rjZtI1+5oM7mrekcziLq0nHf/qj3OB9+KLqgizG 7IHqnPvMjTnZic2wUVqf9qowKuYIKLY+CymVA81HKu14mXWGw8K5qg3YGsARw5AHju X8MeHFvOaBJfwswNkBTJ4+835mIKEP6tzFLXsMLE=
Message-ID: <1503517541.5001.18.camel@nic.cz>
From: Ladislav Lhotka 
To: "t.petch" , netmod@ietf.org, Andy Bierman 
Date: Wed, 23 Aug 2017 21:45:41 +0200
In-Reply-To: <01de01d31c2f$2a7c34a0$4001a8c0@gateway.2wire.net>
References:  <85A1FF5A-EF0B-4278-B4FF-3FE431486B2C@tail-f.com>  <11857e8e-f46e-dc2e-cf99-80224859d221@transpacket.com>   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>   <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com> <044b01d31bf4$d3b37500$4001a8c0@gateway.2wire.net> <87vale1ro2.fsf@cesnet.cz> <01de01d31c2f$2a7c34a0$4001a8c0@gateway.2wire.net>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Pattern statements [was Re: 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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 19:45:22 -0000

t.petch píše v St 23. 08. 2017 v 17:28 +0100:
> ----- Original Message -----
> From: "Ladislav Lhotka" 
> Sent: Wednesday, August 23, 2017 11:53 AM
> 
> > "t.petch"  writes:
> > 
> > > ----- Original Message -----
> > > From: "Robert Wilton" 
> > > Sent: Monday, August 21, 2017 4:14 PM
> > > 
> > > > That makes sense.
> 
> 
> > > > 
> > > > Of course, this would allow more invalid values, but most servers
> > > 
> > > would
> > > > be expected to reject those when it converts them into an internal
> > > > binary format any way.
> > > > 
> > > > What do you, and others, think?
> > > 
> > > Simplify!
> > > 
> > > Bear in mind that the regex for an IPv6 address was wrong for a long
> > > time in base YANG before anyone noticed - it was just too complex.
> > 
> > Why was it wrong? Just because it was too complex?
> 
> No; it contained a definite error.
> 
> This was probably in yang-types and probably around 2012, quite late in
> the day, and it stuck in my mind that so many had looked at it and
> failed to spot that it was wrong, not just that it did not cater for
> some aspects such as interface I-D.  I have used it before as an example
> of over complexity
> 
> I will have the e-mail filed, along with several thousand other NETMOD
> ones so I will find it later rather than sooner.

I believe you mean the case when it was realized that "ipv4-address" and "ipv6-
address" permit also zone indices: 

https://www.ietf.org/mail-archive/web/netmod/current/msg07456.html

We can hardly blaim the pattern expression for this though.

Other than that, I am not aware of any reported problem concerning the "ipv6-
address" type. In fact, I even don't think the two ANDed regexs are excessively
complex. Just compare them to ABNF productions proposed for the same purpose in
RFC 3986, Appendix A.

Lada

PS. Yes, it's my child, so I do have a reason to feel offended. :-)

> 
> Tom Petch
> 
> 
> 
> > > 
> > > And ABNF learnt long ago that just because something could be
> 
> expressed
> > > in code does not mean that it is a good idea to do so.  If a simple
> > > English statement replaces many lines of ABNF, then that is a good
> > > tradeoff.
> > 
> > Well, YANG models are also intended to be read by tools that so far
> > don't understand English statements. Concerning human users, the
> 
> easiest
> > thing might be to refer to a corresponding RFC, which the descriptions
> > already do.
> > 
> > > 
> > > Pragmatically I am not sure what the cutoff for complexity should be
> 
> but
> > > it should be less than we have now.
> > > 
> > > Paradoxically, given the original thread, the time when large
> > > expressions may work ok is when they have a 'sub-module' like
> 
> structure,
> > > when I can look at a group of lines in isolation and form a view of
> 
> what
> > > it does then move on to the next group and so on, building up an
> 
> overall
> > > picture piece by piece.
> > 
> > Of course, regular expression languages are notorically human
> > unfriendly, no matter what flavour we take. The ability to build them
> > step by step from reusable pieces, e.g. using non-terminals, would
> > certainly help.
> > 
> > Lada
> > 
> > > 
> > > Tom Petch
> > > 
> > > > Thanks,
> > > > Rob
> > > > 
> > > > 
> > > > On 21/08/2017 15:01, Acee Lindem (acee) wrote:
> > > > > Hi William, Rob, Andy,
> > > > > 
> > > > > Given their limited usefulness and the detriments, perhaps we
> 
> should
> > > > > discourage the creation of new submodules in RFC6087Bis.
> > > > > 
> > > > > Thanks,
> > > > > Acee
> > > > > 
> > > > > On 8/21/17, 9:44 AM, "netmod on behalf of Ivory, William"
> > > > > 
> > > 
> > > wrote:
> > > > > 
> > > > > > Hi Rob,
> > > > > > 
> > > > > > That would make it very hard to update existing 1.x YANG models
> 
> to
> > > use
> > > > > > new features in YANG 2.x if they used submodules.  Maybe that's
> > > 
> > > something
> > > > > > that no one would ever consider doing anyway, or maybe YANG 1.1
> > > 
> > > already
> > > > > > has similar differences to 1.0?  I had (perhaps naively) assumed
> > > 
> > > that you
> > > > > > could migrate a namespace / model from YANG 1.0 to 2.0?
> > > > > > 
> > > > > > Regards,
> > > > > > 
> > > > > > William
> > > > > > 
> > > > > > -----Original Message-----
> > > > > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of
> 
> Robert
> > > Wilton
> > > > > > Sent: 21 August 2017 11:24
> > > > > > To: netmod@ietf.org
> > > > > > Subject: Re: [netmod] Query about augmenting module from
> 
> submodule
> > > in
> > > > > > YANG 1.0
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > On 09/08/2017 16:13, Juergen Schoenwaelder wrote:
> > > > > > > On Wed, Aug 09, 2017 at 05:01:09PM +0200, Ladislav Lhotka
> 
> wrote:
> > > > > > > > I remember that in early stages of YANG there was some
> 
> irrational
> > > > > > > > fear of introducing too many namespaces, and submodules may be
> 
> a
> > > > > > > > consequence of it. As you write, submodules provide no
> 
> benefits
> > > > > > > > whatsoever in terms of modularity, but the overhead in terms
> 
> of
> > > > > > > > metadata, IANA registration etc. is pretty much the same as
> 
> for
> > > > > > > > modules.
> > > > > > > 
> > > > > > > In case YANG 2.0 is ever done, I suggest someone files a
> 
> proposal
> > > to
> > > > > > > remove submodules if the cost/benefit ratio is at odds. There
> 
> is
> > > > > > > nothing wrong with removing stuff that has been found
> 
> problematic.
> > > > > > I agree.
> > > > > > 
> > > > > > I've added
> > > > > > 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_netmod-2
> > > Dw
> > > > > > 
> 
> g_yang-2Dnext_issues_26&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYi
> > > aQ
> > > > > > 
> 
> 2ZPGqwkyXmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7
> > > ow
> > > > > > I&s=-kR4fUtXArQy0RwWb32DpT1bP4X_cNqt2zJVoC0JiX8&e=
> > > > > > 
> > > > > > Rob
> > > > > > 
> > > > > > > The motivation for submodules was that organizations
> 
> maintaining
> > > large
> > > > > > > modules with multiple people can do so without having to mess
> > > 
> > > around
> > > > > > > with tools like m4 scripts to produce a single module from
> > > 
> > > 'snippets'
> > > > > > > and to avoid integration surprises. But perhaps using m4
> 
> scripts
> > > and
> > > > > > > decent version control systems (that can integrate and compile
> 
> on
> > > > > > > checkin) is indeed cheaper than having submodules part of the
> 
> YANG
> > > > > > > language itself.
> > > > > > > 
> > > > > > > /js
> > > > > > > 
> > > > > > 
> > > > > > _______________________________________________
> > > > > > netmod mailing list
> > > > > > netmod@ietf.org
> > > > > > 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailma
> > > n_
> > > > > > 
> 
> listinfo_netmod&d=DwICAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=p8kyeK3u4ZYiaQ2ZPGqw
> > > ky
> > > > > > 
> 
> XmQgBH6r5jpYiYWzhqJ48&m=l7c4IPL049A2bVVO14fyBMly211xU61xSHgPlAT7owI&s=t7
> > > vG
> > > > > > IH8ABuAm00e-bkSowD9eawModGq0N2OkjANtpYI&e=
> > > > > > 
> > > > > > _______________________________________________
> > > > > > 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 mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> > 
> > --
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Aug 23 12:46:43 2017
Return-Path: 
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 B44CD1323FD for ; Wed, 23 Aug 2017 12:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 N4KSGei9FwxA for ; Wed, 23 Aug 2017 12:46:40 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26C75132661 for ; Wed, 23 Aug 2017 12:46:40 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id b189so6194389wmd.0 for ; Wed, 23 Aug 2017 12:46:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=9VRftAyTDOnL4vVPBWXBnzgBjjSIta4zvFAPCWY3O7o=; b=U6vCI4Z6Mh20tx3ZvNDkoaZzyKY/x894YSVswGcs7jDLRpqlfnic24eIdXo1KX79J8 1srzcZfLTRDHEDOLN3YzV3dx9FbshWoTHklqYAOXpCP3fJ7BL7jif9pv9dDIhw7p3/SF /bSiXiLo06RaPpd87I7nJcAVZrohxz9/jU4gO/L/WQxnK43xoGEzym4esv0yGiFwXrfb NPlW8fRfqJEPG7ds6VuuDosrI7mTn0iniIXiioM9MnaICVh+rJjAGu6hNfNFKAZHHDGj If09fnCggGtRLvAQIgKA15t50ED2WQN4ZTwd0AW3amCW+Q1y39cZ/xRKdbStn9JwOQ1a 80lA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=9VRftAyTDOnL4vVPBWXBnzgBjjSIta4zvFAPCWY3O7o=; b=MLKr6OhPa9LSQU7B3qInzke1FTdjahlDl+preOjTr/iVvnV1YNFeyPl4voWapYNn/P 8EwtCcA7TbyjYI95duGhgyzdde3O6uTcnfe4MvVNa5v6uNa+CmFeTIjCrhVlRc0TMuCA 5wNFmEXDjZ79qdAojo4alXc5zOFVqr1UFgIX5SzUYj9XzX+D3UjdH4yY/CO4NIgQKV/e /WIQNeLRwEDmSIipwLsqp3ASMeWLlVKoNFnu4dVkNQBGXkKnhZtdATzGuWMztu7CXXSv o0BOP+lZYB7bwhndkw6WqWAfm4UTr2gipacWTjuOr1uZi59GaPIdnyAg5Gt/Z4PtGoUD UxKQ==
X-Gm-Message-State: AHYfb5g2/WLy+tAT0Jv6CxETn79ozFxiGPeJNHuFyUiVf0iKgL0KIKD6 dFyrEmyxTGtVMoNseBI1H2GJmmqByJKD
X-Received: by 10.28.101.5 with SMTP id z5mr2724325wmb.136.1503517598515; Wed, 23 Aug 2017 12:46:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.221 with HTTP; Wed, 23 Aug 2017 12:46:37 -0700 (PDT)
In-Reply-To: <20170820080301.asf2fx6o4abupq4h@elstar.local>
References:  <20170820080301.asf2fx6o4abupq4h@elstar.local>
From: Andy Bierman 
Date: Wed, 23 Aug 2017 12:46:37 -0700
Message-ID: 
To: Juergen Schoenwaelder ,  "Acee Lindem (acee)" , YANG Doctors ,  "netmod@ietf.org" , Rodney Cummings 
Content-Type: multipart/alternative; boundary="001a114b31165ffb5b055770f8be"
Archived-At: 
Subject: Re: [netmod] [yang-doctors] Identities vs enums
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 19:46:42 -0000

--001a114b31165ffb5b055770f8be
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, Aug 20, 2017 at 1:03 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Sat, Aug 19, 2017 at 07:02:04PM +0000, Acee Lindem (acee) wrote:
> > All,
> > In the context iana-routing-types.yang, we=E2=80=99ve been having a dis=
cussion
> of the merits of identities vs enums. We=E2=80=99ve followed the lead of =
RFC 7224
> and used identities which allow augmentation. However, for IANA code
> points, there could be merit in having the type represent the actual
> numeric value. Any thoughts on this?
> >
> > In the next version of YANG, it would be useful for a base identity to
> allow it to have a "base-type" (mutually exclusive of "identity-ref"). Fo=
r
> all identities a "base-value" would be allowed as long as it conformed to
> the constraints of the actual or inherited (via =E2=80=9Cidentity-ref=E2=
=80=9D) =E2=80=9Cbase-type=E2=80=9D.
> >
>
> The question here really is who is charge of controlling assignments
> of a name space.
>
> - If there is a single authority controlling the assignments, an enum
>   works fine.
>
> - If the assignments are not controlled by a single authority, an
>   identity works fine.
>
> We sometimes have situations that are somewhere in between, i.e., a
> central authority controlling assignments but delegating parts of the
> name space to other authoritities. I agree, we do not have good
> support to model this explicitly in YANG today.
>
>
I think Acee is asking about a new feature that does not exist in YANG,
which is to add
an enum value-stmt to an identity-stmt somehow.  Seems like a valid
use-case.

It is easy to be confused into thinking the "value" and "position"
assignments have any
relevance to the protocols, but unfortunately they do not (for NETCONF and
RESTCONF).
Think of them as "reference" statements, to identify conceptual codepoints
that are never
sent on the wire. Only the enum or bit names are sent on the wire in XML or
JSON.

Actually CORE WG is developing YANG-to-CBOR, which does use the value
and position fields for the binary encoding.


/js
>
>
Andy


> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> yang-doctors mailing list
> yang-doctors@ietf.org
> https://www.ietf.org/mailman/listinfo/yang-doctors
>

--001a114b31165ffb5b055770f8be
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Sun, Aug 20, 2017 at 1:03 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sat, Aug 19, 2017 at 07:02:04PM +0000, Acee Linde=
m (acee) wrote:

> All,

> In the context iana-routing-types.yang, we=E2=80=99ve been having a di=
scussion of the merits of identities vs enums. We=E2=80=99ve followed the l=
ead of RFC 7224 and used identities which allow augmentation. However, for =
IANA code points, there could be merit in having the type represent the act=
ual numeric value. Any thoughts on this?

>

> In the next version of YANG, it would be useful for a base identity to=
 allow it to have a "base-type" (mutually exclusive of "iden=
tity-ref"). For all identities a "base-value" would be allow=
ed as long as it conformed to the constraints of the actual or inherited (v=
ia =E2=80=9Cidentity-ref=E2=80=9D) =E2=80=9Cbase-type=E2=80=9D.

>



The question here really is who is charge of controlling assignments

of a name space.



- If there is a single authority controlling the assignments, an enum

=C2=A0 works fine.



- If the assignments are not controlled by a single authority, an

=C2=A0 identity works fine.



We sometimes have situations that are somewhere in between, i.e., a

central authority controlling assignments but delegating parts of the

name space to other authoritities. I agree, we do not have good

support to model this explicitly in YANG today.



I think Acee is asking about a new feature that does=
 not exist in YANG, which is to add
an enum value-stmt to an iden=
tity-stmt somehow.=C2=A0 Seems like a valid use-case.

<=
div>It is easy to be confused into thinking the "value" and "=
;position" assignments have any
relevance to the protocols, =
but unfortunately they do not (for NETCONF and RESTCONF).
Think o=
f them as "reference" statements, to identify conceptual codepoin=
ts that are never
sent on the wire. Only the enum or bit names ar=
e sent on the wire in XML or JSON.

Actually CORE W=
G is developing YANG-to-CBOR, which does use the value
and positi=
on fields for the binary encoding.=C2=A0



/js



Andy
=C2=A0

--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>



_______________________________________________

yang-doctors mailing list

yang-doctors@ietf.org

https://www.ietf.org/mailman/listinfo/yang-do=
ctors





--001a114b31165ffb5b055770f8be--


From nobody Wed Aug 23 13:03:38 2017
Return-Path: 
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 58C421323C9 for ; Wed, 23 Aug 2017 13:03:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 i8z3jrkJFodj for ; Wed, 23 Aug 2017 13:03:34 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9E62113209C for ; Wed, 23 Aug 2017 13:03:33 -0700 (PDT)
Received: from pluto.hedeland.org (81-228-155-109-no289.tbcn.telia.com [81.228.155.109]) by mail.tail-f.com (Postfix) with ESMTPSA id AC0F91AE01AA; Wed, 23 Aug 2017 22:03:32 +0200 (CEST)
To: Vladimir Vassilev , "netmod@ietf.org" 
References:   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>   <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com> <5929631c-e51d-ae66-52d1-cbc87ca3506b@transpacket.com> <321a45fb-77e1-23c7-184b-d3bff9d41c39@cisco.com> <20170823133657.76s5wbcxbpgjfkiy@elstar.local> <9fc4b41f-5994-79f6-43dc-f3ba5b09f36d@transpacket.com>
From: Per Hedeland 
Message-ID: 
Date: Wed, 23 Aug 2017 22:03:32 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <9fc4b41f-5994-79f6-43dc-f3ba5b09f36d@transpacket.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Pattern statements [was Re: 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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 20:03:36 -0000

On 2017-08-23 20:09, Vladimir Vassilev wrote:
> On 08/23/2017 03:36 PM, Juergen Schoenwaelder wrote:
> 
>> On Wed, Aug 23, 2017 at 02:23:12PM +0100, Robert Wilton wrote:
>>> 1) Email address.  I understand that the full regex to validate all email
>>> addresses is very complex, but checking that it at least contains an @
>>> symbol still has benefit.  It would seem that a short imperfect regex is
>>> better than a complete perfect regex.
>> What is your definition of 'better'? A stricter pattern catches more
>> errors. An imperfect pattern is better than none.
> In the case of e-mail address string pattern complying without exceptions to rfc5322#section-3.4 specification a ~500 characters of pattern expression is needed. There is value in defining data types 
> that can be automatically verified by YANG. IMO in this case a strict pattern is justified.
>>> 2) A list of VLAN ranges, e.g. want to allow strings that look like this:
>>> "1-10,20-400,600,2000-3000", but only with non overlapping values in
>>> ascending order.  It is easy to write a regex to check that the structure is
>>> right, but AFAIK it is hard (impossible?) to write a regex that ensures that
>>> the ranges don't overlap and are specified in ascending order.
>> So what. Does this provide a helpful argument whether patterns should
>> be strict or imperfect?
> IMO loading strings with semantics instead of using YANG is example of bad model design. There is no RFC (like in the e-mail example) that mandates use of string with complex format instead of YANG to 
> model range configuration. Complex strings can and should be avoided in cases like this one.
>>> So, I propose that we use regexes for checking that the string is
>>> structurally correct, but don't use regexes to perform numerical range
>>> checks of string encoded numbers, since it makes the regexes hard to
>>> read/verify, and doesn't improve the readability of the YANG file either.
>> So here is the point I think:
>> c.
>>     It is desirable that regexes are as strict as they can be.
>>     However, if regexes become so complicated that they become a
>>     verification and maintenance problem by themself, then less strict
>>     regexes may be a better choice.
> I agree. But it is the enthropy of having configuration that can not be strictly validated by model aware automation tools that has been the reason for introduction of leafref, must, when, range, 
> pattern etc. So giving up the goal of handling validation in automated model driven way to the advantage of readability is a tough compromise.

If I may offer a more "philosophical" view: in my mind, a YANG module is
not an instruction for a server (or client) implementation as to what
validation to perform (and I say that with the bias of working for a
company that uses YANG modules precisely for that, and with the specific
components that translate them into such instructions) - it is a
specification of the data model. If the pattern statement allows values
that are actually invalid, the specification is incorrect.

I.e. I'm with your original comment - if you can't get it right, leave
it out. "Under-specification" will always exist, and is acceptable in my
opinion. Specification that gives the appearance of being complete
(admittedly this is also subjective), but actually isn't, is not (in my
opinion).

--Per

> I agree with Rob that the pattern in draft-ietf-rtgwg-routing-types-09 is complicated to read. I have the feeling the design can be improved without compromising the strictnes of the data type. 
> Redefinig the typedef as a union of 5 string based types with seperate strict patterns is one suggestion for moving logic from the string type to YANG.
> 
> Vladimir
>> /js
>>
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Aug 23 13:03:55 2017
Return-Path: 
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 9E21D132377 for ; Wed, 23 Aug 2017 13:03:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 BhIy76gFZGYN for ; Wed, 23 Aug 2017 13:03:47 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 3C62113209C for ; Wed, 23 Aug 2017 13:03:47 -0700 (PDT)
Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id 871BD622CE; Wed, 23 Aug 2017 22:03:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1503518625; bh=lHEYhBmtMBaUtns/P3076omX7+5Vj59wjbMI02jJRec=; h=From:To:Date; b=kJL5NTj7jmiLzNGSv2oj+FejDlQXJJg5MnPcPk4GtjGVssITTEDbVs8pTW6/OoBV/ lEHvNAaODpqTcZjqwQp6RW8BiWpnK7ilVN/PBuwUmbpmLwyUrx5z5hJ9hB5hff/Deh Nb1VS3+pzGGm/HRhh5Gq6dnEoD4Gr7HtGjZn6g4c=
Message-ID: <1503518651.5001.27.camel@nic.cz>
From: Ladislav Lhotka 
To: Robert Wilton , netmod@ietf.org
Date: Wed, 23 Aug 2017 22:04:11 +0200
In-Reply-To: 
References:   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>   <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com> <5929631c-e51d-ae66-52d1-cbc87ca3506b@transpacket.com> <321a45fb-77e1-23c7-184b-d3bff9d41c39@cisco.com> <20170823133657.76s5wbcxbpgjfkiy@elstar.local> <1503498125.32530.12.camel@nic.cz> 
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Pattern statements [was Re: 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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 20:03:53 -0000

Robert Wilton píše v St 23. 08. 2017 v 17:58 +0100:
> 
> On 23/08/2017 15:22, Ladislav Lhotka wrote:
> > Juergen Schoenwaelder píše v St 23. 08. 2017 v 15:36 +0200:
> > > On Wed, Aug 23, 2017 at 02:23:12PM +0100, Robert Wilton wrote:
> > > > 1) Email address.  I understand that the full regex to validate all email
> > > > addresses is very complex, but checking that it at least contains an @
> > > > symbol still has benefit.  It would seem that a short imperfect regex is
> > > > better than a complete perfect regex.
> > > 
> > > What is your definition of 'better'? A stricter pattern catches more
> > > errors. An imperfect pattern is better than none.
> > > 
> > > > 2) A list of VLAN ranges, e.g. want to allow strings that look like this:
> > > > "1-10,20-400,600,2000-3000", but only with non overlapping values in
> > > > ascending order.  It is easy to write a regex to check that the structure is
> > > > right, but AFAIK it is hard (impossible?) to write a regex that ensures that
> > > > the ranges don't overlap and are specified in ascending order.
> > > 
> > > So what. Does this provide a helpful argument whether patterns should
> > > be strict or imperfect?
> > > 
> > > > So, I propose that we use regexes for checking that the string is
> > > > structurally correct, but don't use regexes to perform numerical range
> > > > checks of string encoded numbers, since it makes the regexes hard to
> > > > read/verify, and doesn't improve the readability of the YANG file either.
> > > 
> > > So here is the point I think:
> > > 
> > >     It is desirable that regexes are as strict as they can be.
> > >     However, if regexes become so complicated that they become a
> > >     verification and maintenance problem by themself, then less strict
> > >     regexes may be a better choice.
> > 
> > Either way, the regex must not produce false negatives, i.e. reject valid
> > values. For some regexes this is what makes them complicated.
> 
> I agree.
> 
> > 
> > Also, I don't see any need for replacing existing patterns unless they are
> > wrong.
> 
> I also agree.  I'm not trying to retroactively change existing regexes, 
> just tweak the guidance when new regexes are being constructed so that 
> they end up being a bit simpler.

This is really subjective, and I am certainly on the side of making the regexes
as strict as possible because they guard not only against typos but also against
intentionally invalid values, i.e. attacks.

Lada

> 
> Thanks,
> Rob
> 
> 
> >   We have descriptions to tell human readers about the permitted value set.
> > 
> > Lada
> > 
> > > /js
> > > 
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Aug 23 13:36:43 2017
Return-Path: 
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 80C1C13218E; Wed, 23 Aug 2017 13:36:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 w2ckjAOpvbDB; Wed, 23 Aug 2017 13:36:35 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 860C7120720; Wed, 23 Aug 2017 13:36:35 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 5E3E599; Wed, 23 Aug 2017 22:36:34 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id he4bMZYzdL8y; Wed, 23 Aug 2017 22:36:33 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 23 Aug 2017 22:36:34 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 35B41200E2; Wed, 23 Aug 2017 22:36:34 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tKNL_litf-Tk; Wed, 23 Aug 2017 22:36:33 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BE35A200E0; Wed, 23 Aug 2017 22:36:33 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 79627404A4CB; Wed, 23 Aug 2017 22:36:33 +0200 (CEST)
Date: Wed, 23 Aug 2017 22:36:33 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Cc: "Acee Lindem (acee)" , YANG Doctors , "netmod@ietf.org" , Rodney Cummings 
Message-ID: <20170823203633.4yseukdqncuchxdf@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , "Acee Lindem (acee)" , YANG Doctors , "netmod@ietf.org" , Rodney Cummings 
References:  <20170820080301.asf2fx6o4abupq4h@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] [yang-doctors] Identities vs enums
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 20:36:37 -0000

On Wed, Aug 23, 2017 at 12:46:37PM -0700, Andy Bierman wrote:
> On Sun, Aug 20, 2017 at 1:03 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> 
> > On Sat, Aug 19, 2017 at 07:02:04PM +0000, Acee Lindem (acee) wrote:
> > > All,
> > > In the context iana-routing-types.yang, we’ve been having a discussion
> > of the merits of identities vs enums. We’ve followed the lead of RFC 7224
> > and used identities which allow augmentation. However, for IANA code
> > points, there could be merit in having the type represent the actual
> > numeric value. Any thoughts on this?
> > >
> > > In the next version of YANG, it would be useful for a base identity to
> > allow it to have a "base-type" (mutually exclusive of "identity-ref"). For
> > all identities a "base-value" would be allowed as long as it conformed to
> > the constraints of the actual or inherited (via “identity-ref”) “base-type”.
> > >
> >
> > The question here really is who is charge of controlling assignments
> > of a name space.
> >
> > - If there is a single authority controlling the assignments, an enum
> >   works fine.
> >
> > - If the assignments are not controlled by a single authority, an
> >   identity works fine.
> >
> > We sometimes have situations that are somewhere in between, i.e., a
> > central authority controlling assignments but delegating parts of the
> > name space to other authoritities. I agree, we do not have good
> > support to model this explicitly in YANG today.
> >
> >
> I think Acee is asking about a new feature that does not exist in YANG,
> which is to add
> an enum value-stmt to an identity-stmt somehow.  Seems like a valid
> use-case.

Identities can be without a central authority controlling assignments
- so there is little hope that values assigned to identities carry a
useful meaning unless there is a mechanism to partition and delegate
number spaces along the identity hierarchy.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Aug 23 13:36:53 2017
Return-Path: 
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 384941326FE for ; Wed, 23 Aug 2017 13:36:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level: 
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 dMdN6DJChQps for ; Wed, 23 Aug 2017 13:36:43 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 6A17A120720 for ; Wed, 23 Aug 2017 13:36:43 -0700 (PDT)
Received: from birdie (unknown [IPv6:2a01:5e0:29:ffff:ffc6:c393:cdb9:8db1]) by mail.nic.cz (Postfix) with ESMTPSA id 75F67608F3 for ; Wed, 23 Aug 2017 22:36:41 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1503520601; bh=4JEgeEcOFwxwwWAG/vjtlr3wWEDosKN89lB9ykPaS5g=; h=From:To:Date; b=RJk8UdtQE+gN0EwdDQZnQpOa7HCzYl+ltFdH2ibfZh+CCdsC4oxexTP4owFuyNjux bQ4oKixN/vnQTc34BYuRxxekmX7VJSW/SnXEXRdrjY4ejwN8BP6TaOWgZ/LKFRZLrU UJkXJBxLYrVo8V6M3SFWAW/7jkAFZo0Gp1ZlfrSs=
Message-ID: <1503520626.8890.6.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Wed, 23 Aug 2017 22:37:06 +0200
In-Reply-To: 
References:   <1502290869.16638.15.camel@nic.cz> <20170809151312.GC42207@elstar.local> <6ef68131-f731-0edc-b731-d7ec85924f03@cisco.com>   <7614040f-9f8f-09c2-1854-63ad9ffb6be1@cisco.com> <5929631c-e51d-ae66-52d1-cbc87ca3506b@transpacket.com> <321a45fb-77e1-23c7-184b-d3bff9d41c39@cisco.com> <20170823133657.76s5wbcxbpgjfkiy@elstar.local> <9fc4b41f-5994-79f6-43dc-f3ba5b09f36d@transpacket.com> 
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Pattern statements [was Re: 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 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 20:36:52 -0000

Per Hedeland píše v St 23. 08. 2017 v 22:03 +0200:
> On 2017-08-23 20:09, Vladimir Vassilev wrote:
> > On 08/23/2017 03:36 PM, Juergen Schoenwaelder wrote:
> > 
> > > On Wed, Aug 23, 2017 at 02:23:12PM +0100, Robert Wilton wrote:
> > > > 1) Email address.  I understand that the full regex to validate all email
> > > > addresses is very complex, but checking that it at least contains an @
> > > > symbol still has benefit.  It would seem that a short imperfect regex is
> > > > better than a complete perfect regex.
> > > 
> > > What is your definition of 'better'? A stricter pattern catches more
> > > errors. An imperfect pattern is better than none.
> > 
> > In the case of e-mail address string pattern complying without exceptions to rfc5322#section-3.4 specification a ~500 characters of pattern expression is needed. There is value in defining data types 
> > that can be automatically verified by YANG. IMO in this case a strict pattern is justified.
> > > > 2) A list of VLAN ranges, e.g. want to allow strings that look like this:
> > > > "1-10,20-400,600,2000-3000", but only with non overlapping values in
> > > > ascending order.  It is easy to write a regex to check that the structure is
> > > > right, but AFAIK it is hard (impossible?) to write a regex that ensures that
> > > > the ranges don't overlap and are specified in ascending order.
> > > 
> > > So what. Does this provide a helpful argument whether patterns should
> > > be strict or imperfect?
> > 
> > IMO loading strings with semantics instead of using YANG is example of bad model design. There is no RFC (like in the e-mail example) that mandates use of string with complex format instead of YANG to 
> > model range configuration. Complex strings can and should be avoided in cases like this one.
> > > > So, I propose that we use regexes for checking that the string is
> > > > structurally correct, but don't use regexes to perform numerical range
> > > > checks of string encoded numbers, since it makes the regexes hard to
> > > > read/verify, and doesn't improve the readability of the YANG file either.
> > > 
> > > So here is the point I think:
> > > c.
> > >     It is desirable that regexes are as strict as they can be.
> > >     However, if regexes become so complicated that they become a
> > >     verification and maintenance problem by themself, then less strict
> > >     regexes may be a better choice.
> > 
> > I agree. But it is the enthropy of having configuration that can not be strictly validated by model aware automation tools that has been the reason for introduction of leafref, must, when, range, 
> > pattern etc. So giving up the goal of handling validation in automated model driven way to the advantage of readability is a tough compromise.
> 
> If I may offer a more "philosophical" view: in my mind, a YANG module is
> not an instruction for a server (or client) implementation as to what
> validation to perform (and I say that with the bias of working for a
> company that uses YANG modules precisely for that, and with the specific
> components that translate them into such instructions) - it is a
> specification of the data model. If the pattern statement allows values
> that are actually invalid, the specification is incorrect.
> 
> I.e. I'm with your original comment - if you can't get it right, leave
> it out. "Under-specification" will always exist, and is acceptable in my
> opinion. Specification that gives the appearance of being complete
> (admittedly this is also subjective), but actually isn't, is not (in my
> opinion).

I completely agree.

Lada

> 
> --Per
> 
> > I agree with Rob that the pattern in draft-ietf-rtgwg-routing-types-09 is complicated to read. I have the feeling the design can be improved without compromising the strictnes of the data type. 
> > Redefinig the typedef as a union of 5 string based types with seperate strict patterns is one suggestion for moving logic from the string type to YANG.
> > 
> > Vladimir
> > > /js
> > > 
> > 
> > _______________________________________________
> > 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
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Wed Aug 23 14:19:31 2017
Return-Path: 
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 51A46132714 for ; Wed, 23 Aug 2017 14:19:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 8fl2aRO10TJt for ; Wed, 23 Aug 2017 14:19:27 -0700 (PDT)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 1B6A1132719 for ; Wed, 23 Aug 2017 14:19:27 -0700 (PDT)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id DE8261E08D5 for ; Wed, 23 Aug 2017 15:19:25 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id 0lKM1w01p2SSUrH01lKQTx; Wed, 23 Aug 2017 15:19:25 -0600
X-Authority-Analysis: v=2.2 cv=G8xsK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=KeKAF7QvOSUA:10 a=NEAV23lmAAAA:8 a=48vgC7mUAAAA:8 a=j3Z76cjpAAAA:8 a=YHccSxKhpErIJaqqc7EA:9 a=lygVVBSpf36Rlvus:21 a=C394CX_yu7TcOXcJ:21 a=QEXdDO2ut3YA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=9ZYBcOd_X9kS2t7VFny2:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=YWxKHpDKYvPERHN+qnBsjNU332wn2SJ1ughW3/Q6ZcU=; b=W6TFzSUAHbgKZQQTv1xoiROp4k kJa7VJ7QAXDVnkXClpQHokUhAo7OzGFZLF23zmcOApLUhYZbox/NE/jpuz9CyglV9Z8lZnGkF2R1c IE0iHfSoIUruQSa4YrPy6OzGL;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:57404 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dkd3Z-000kho-Oo; Wed, 23 Aug 2017 15:19:21 -0600
To: Kent Watsen 
Cc: "netmod@ietf.org" 
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local> <95c65e38-a117-592d-5c3f-06d31f8845fa@labn.net> <20170823125855.mfuel6iwv5sxl3wy@elstar.local> 
From: Lou Berger 
Message-ID: <8063c77b-511a-474b-0a59-3c25c01123ac@labn.net>
Date: Wed, 23 Aug 2017 17:19:17 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dkd3Z-000kho-Oo
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:57404
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 21:19:30 -0000

My view is wikis are fine for folks "in the know" but RFCs are good for
the wide distribution of interoperability standards and information
related to their implementation. 

It seems to me that this is a case of the latter.

Oh, RFCS are also sometimes used to ensure community consensus on IETF
operation.

Lou

On 8/23/2017 12:38 PM, Kent Watsen wrote:
> Just wondering, but is an RFC the appropriate vehicle for this content?  Would a wiki be better?
>
> K.
>
>
> --
>
> Lets do it this way then. If we plan to revise this again in ~1 year,
> so be it. We started this revision in Feb 2014. ;-)
>
> /js
>
> On Wed, Aug 23, 2017 at 08:07:28AM -0400, Lou Berger wrote:
>> Juergen,
>>
>>
>> On August 23, 2017 2:17:43 AM Juergen Schoenwaelder
>>  wrote:
>>
>>> My preference is to have the guidelines say what people should do,
>>> namely design NMDA models. I would prefer to keep any transition
>>> aspects out of the guidelines.
>> Well, this approach works for those who are deeply enmeshed in netmod
>> and the IETF, it doesn't help those designing models/solutions during
>> the current transition period.  IMO we can't forget about this important
>> class of model developers and users.
>>
>>> If people want to include transition
>>> aspects, it should be in the appendix (i.e., easy to remove / ignore
>>> later on).
>>>
>> I don't see a material difference here.  Either way the document needs
>> to be updated. See below for a specific proposed wording update.
>>
>>> I understand that there is a timing issue. The question is what you
>>> mean with "NMDA solution makes it to publication (request)". If you
>>> mean the core NMDA document, this is pretty much in reach and keeping
>>> this guidelines document on hold until then may be an option. If you
>>> mean the complete solution set, including model updates and moving the
>>> protocol extensions in NETCONF to publication request, then this may
>>> take a bit more time.
>>>
>> I mean the time when implementors can reasonably be told that the old
>> way has been replaced by a fully defined (and able to be implemented)
>> NMDA solution.  I think includes both netconf and restconf NMDA
>> definitions.  I don't think it's reasonable to require implementation of
>> drafts that are in-flux.
>>
>>
>>
>>> /js
>>>
>>> On Tue, Aug 22, 2017 at 04:32:14PM -0400, Lou Berger wrote:
>>>> Kent/WG,
>>>>
>>>>     This seems a bit terse to me and not provide needed guidance during
>>>> the current transition period.  I understood  the discussion ended up 
>>>> with the options being to either (1) provide the guidance as a
>>>> standalone document, e.g., (a)-(s) in draft-dsdt-nmda-guidelines, with a
>>>> pointer to it from 6087bis or (2) just move those sections to 6087 bis. 
>>>> Either way, we'll need a new bis once the full NMDA solution makes it to
>>>> publication (request).
>>>>
>>>> I thought the plan was to do (s).  If so, we need the full text. 
>>>> Looking at the current repo
>>>> (https://github.com/netmod-wg/datastore-dt/blob/master/guidelines/guidelines.txt)
>>>> it would be:
>>>>
>>>>     4.23 Operational Data
>>>>
>>>>     The following guidelines are meant to help modelers develop
>>>>     YANG models that will maximize the utility of the model with
>>>>     both current implementations and NMDA-capable implementations
>>>>     [draft-ietf-netmod-revised-datastores].
>>>>
>> remove (a) and re-letter rest of list
>>>>     (a) New models and models that are not concerned with the
>>>>     operational state of configuration information SHOULD
>>>>     immediately be structured to be NMDA-compatible.
>> Add:
>>    The remaining options MAY be followed during the time that
>>    NMDA mechanisms are being defined.  These options will be
>>    removed in a future update of this document once this definition
>>    is complete.
>>
>> Does this work for you?  Moving it to an appendix just makes it harder
>> for the reader and, again, the document needs to be revised either way
>> in the future.
>>
>> Lou
>>
>>>>     (b) Models that require immediate support for "in use" and
>>>>     "system created" information SHOULD be structured for NMDA.  A
>>>>     non-NMDA version of these models SHOULD exist, either an
>>>>     existing model or a model created either by hand or with
>>>>     suitable tools that mirror the current modeling strategies.
>>>>     Both the NMDA and the non-NMDA modules SHOULD be published in
>>>>     the same document, with NMDA modules in the document main body
>>>>     and the non-NMDA modules in a non-normative appendix.  The use
>>>>     of the non-NMDA model will allow temporary bridging of the
>>>>     time period until NMDA implementations are available.
>>>>
>>>>     (c) For published models, the model should be republished with
>>>>     an NMDA-compatible structure, deprecating non-NMDA constructs.
>>>>     For example, the "ietf-interfaces" model in ^RFC7223^ will be
>>>>     restructured as an NMDA-compatible model.  The
>>>>     "/interfaces-state" hierarchy will be marked "status
>>>>     deprecated".  Models that mark their "/foo-state" hierarchy
>>>>     with "status deprecated" will allow NMDA-capable
>>>>     implementations to avoid the cost of duplicating the state
>>>>     nodes, while enabling non-NMDA-capable implementations to
>>>>     utilize them for access to the operational values.
>>>>
>>>>     (d) For models that augment models which have not been
>>>>     structured with the NMDA, the modeler will have to consider
>>>>     the structure of the base model and the guidelines listed
>>>>     above.  Where possible, such models should move to new
>>>>     revisions of the base model that are NMDA-compatible.  When
>>>>     that is not possible, augmenting "state" containers SHOULD be
>>>>     avoided, with the expectation that the base model will be
>>>>     re-released with the state containers marked as deprecated.
>>>>     It is RECOMMENDED to augment only the "/foo" hierarchy of the
>>>>     base model.  Where this recommendation cannot be followed,
>>>>     then any new "state" elements SHOULD be included in their own
>>>>     module.
>>>>
>>>>     To create the temporary non-NMDA model from an NMDA model, the
>>>>     following steps can be taken:
>>>>    
>>>>     - Rename the module name by postpending "-state" to the
>>>>       original module's name
>>>>     - Change the namespace by postpending "-state" to the original
>>>>       namespace value
>>>>     - Change the prefix by postpending "-s" to the original prefix
>>>>       value
>>>>     - Set all top-level nodes to have a "config" statement of
>>>>       value "false"
>>>>     - add an import to the original module (e.g., for typedef
>>>>       definitions)
>>>>     - modify any imports, used for leafrefs or identityrefs, to
>>>>       import the -state version of the module
>>>>     - remove any 'typedef' or 'identity' definitions
>>>>     - prefix any uses of the typedefs and identities accordingly
>>>>     - update leafref and augment paths to use the new "-s" prefix
>>>>
>>>> For me (with any/all hats) the key downside is that we'll need to  rev
>>>> this text (again) in the not too distant future, but that we don't have
>>>> an alternative as LC on the full solution is still a bit away.
>>>>
>>>> What do people think?  
>>>>
>>>> Lou
>>>>
>>>>
>>>> On 8/22/2017 3:53 PM, Kent Watsen wrote:
>>>>> Hi,
>>>>>
>>>>> During the meeting in Chicago, the NMDA authors took an action to
>>>>> propose some text for S4.23.  After a little review, the following
>>>>> emerged.  Yes, it's short, but was anything left anything out?
>>>>>
>>>>>
>>>>> =====START=====
>>>>>
>>>>> 4.23 Operational Data
>>>>>
>>>>> Operational data includes both config "false" nodes as well as,
>>>>> on servers supporting  [draft-ietf-netmod-revised-datastores],
>>>>> the applied value of config "true" nodes.
>>>>>
>>>>> YANG modules SHOULD be designed assuming they will be used on
>>>>> servers supporting .  With this in mind, YANG
>>>>> modules SHOULD define config "false" wherever they make sense
>>>>> to the data model.  Config "false" nodes SHOULD NOT be defined
>>>>> to provide the operational value for configuration nodes,
>>>>> except when the value space of a configured and operational
>>>>> values may differ, in which case a distinct config "false"
>>>>> node SHOULD be defined to hold the operational value for the
>>>>> configured node.
>>>>>
>>>>> =====STOP=====
>>>>>
>>>>>
>>>>> One question that came up is if "operational data" is a well-defined
>>>>> term.  This string appears 10 times in rfc6087bis.  Most interestingly,
>>>>> appendix Section A.8. (v05 to v06) includes this line item:
>>>>>
>>>>>     Changed term "operational state" to "operational data"
>>>>>
>>>>> So it seems to be deliberate...
>>>>>
>>>>>
>>>>> Kent  // contributor
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>> --
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:   +49 421 200 3103         
>>>


From nobody Wed Aug 23 14:20:45 2017
Return-Path: 
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 CB04B132714 for ; Wed, 23 Aug 2017 14:20:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.909
X-Spam-Level: 
X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.com
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 bDYXUVdppbo9 for ; Wed, 23 Aug 2017 14:20:39 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0124.outbound.protection.outlook.com [104.47.34.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB0B21329E4 for ; Wed, 23 Aug 2017 14:20:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com;  s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PQSp5+/MwFkbHuhxTdOy5aQRi19HDXjI0gZn77MqrrY=; b=VDmDe1iHj/BKeQdorv37APx1fBnhgh28ohoVQbTNMR5X8YNE1fAmeB0RBWwErI8iFRQLxavx5KC29wy2xngTQLhEjKU9EeZEro7Tdlq+ofczpFxcIg4ev50+74rs9Kb3AB5ISKlXOzk5syc1uq60sqaGZl57LqyM7N0dt+VxQTs=
Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by BN3PR0201MB0932.namprd02.prod.outlook.com (10.160.155.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.9; Wed, 23 Aug 2017 21:20:36 +0000
Received: from BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) by BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) with mapi id 15.01.1362.019; Wed, 23 Aug 2017 21:20:36 +0000
From: Xufeng Liu 
To: "'netmod@ietf.org'" 
Thread-Topic: Potential additions to rfc6087bis: RegEx guidelines
Thread-Index: AdMcU4SqqeTEr3DWR4ygcD75zJMNgA==
Date: Wed, 23 Aug 2017 21:20:36 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXHhsaXVcYXBwZGF0YVxyb2FtaW5nXDA5ZDg0OWI2LTMyZDMtNGE0MC04NWVlLTZiODRiYTI5ZTM1Ylxtc2dzXG1zZy1lNWM0ZWVkOC04ODQ4LTExZTctOWMyOC0xODVlMGZlM2M0NWNcYW1lLXRlc3RcZTVjNGVlZDktODg0OC0xMWU3LTljMjgtMTg1ZTBmZTNjNDVjYm9keS5odG1sIiBzej0iMjEyNDgiIHQ9IjEzMTQ3OTk2ODM0NzgyMDI2NiIgaD0iamc4QWxOdmRjSmdsckwxL1dJNE1oWVkrMjNjPSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg==
x-dg-tag-bcast: 
x-dg-paste: 
x-originating-ip: [98.191.72.170]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0201MB0932; 6:1KgptufSJ5toU2QTGFzy9zqAnU/dgfv53S54bNINHADMU1TqSs0821f5fdHRaEFjycAlIIqzM5A+5pEj0hrl5a/LztXCj9DqPOOYQsdnm54H2zLf0XqNmv877ntkSF4tckxCweVW9rIXyzvIj5Q7yWvm6WbsnPa93CVQVDfSlZEpV7bhj9HQeRUUQKknc0n3DvJZ/lbUclDZm0rke59SsX4mbsaTwfNpJeV/geW/7jzGxT48/JQSDJTkNQIuTxCC+fAbCcO8sVM1pv0AIZ4ANxax5UFQoyUyTA9//XfxlIr2W37sJWX3qCqckemGlYoLiUqBf2Ct/VTabjxwvkSuVA==; 5:aZ4zjsnXgFFttnCGpQbOAbn0scI+DOJA2D6FfCXKgVQhvAndcBzV1rhvG20cYtR8+PBmFExIfkO2vLBze+SkGqvc7NHO1GCxvuSS/3uI3/zMaHVcK4nUfI0HSgwc432teX+NG9jNy8xXo5zrPSmzXA==; 24:N1DqJgsPWgyUaQmgKHhX0xNPNjma0FyMB6Az02z58LVHf0JOqhThsi7Ne6k2/n7eEUqUc1shtI9viiR+B383KSoFi2Skj+d2MaCYQH8nZbY=; 7:FLCry9u0LymFL7CF+MHYJNgaFfjR9MdiL2CcqUtsK/4tszTpF7Uu2Hx0JWuu/6ukezQMt11SX3k1A6po2BT1Xe1NYYVZWlLRLem4Ik1YvijLPLq+90II/4FRFudufpB5e1edRKvJ67BU5gGILyho0Q5fP/3nBJEFJKa2MEFPc8MBkveG5sbFc7rAxZvpG55hfJi1jJljvpPIHLB812nhCNcLWBJYcTH9/QRKT9E9HFo=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 10cd7614-b823-4b80-3768-08d4ea6ccc1b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603189)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0201MB0932; 
x-ms-traffictypediagnostic: BN3PR0201MB0932:
x-exchange-antispam-report-test: UriScan:(166708455590820)(21748063052155);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0201MB0932; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0201MB0932; 
x-forefront-prvs: 040866B734
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(189002)(199003)(7696004)(966005)(478600001)(33656002)(72206003)(6916009)(189998001)(68736007)(101416001)(6116002)(3846002)(790700001)(74316002)(5660300001)(50986999)(66066001)(54356999)(86362001)(105586002)(8936002)(106356001)(55016002)(110136004)(99286003)(102836003)(2900100001)(6306002)(54896002)(3280700002)(3660700001)(9686003)(25786009)(7736002)(81166006)(81156014)(8676002)(6436002)(77096006)(97736004)(6506006)(2906002)(14454004)(80792005)(53936002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB0932; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: jabil.com does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Xufeng_Liu@jabil.com; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BN3PR0201MB0867DAD1212DBA2E88570AD5F1850BN3PR0201MB0867_"
MIME-Version: 1.0
X-OriginatorOrg: jabil.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Aug 2017 21:20:36.7160 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB0932
Archived-At: 
Subject: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 21:20:43 -0000

--_000_BN3PR0201MB0867DAD1212DBA2E88570AD5F1850BN3PR0201MB0867_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Members of Routing Area Yang DT have had some discussions about the handlin=
g of various variants of regular expressions. The followings are the curren=
t state, and we are thinking that if this topic can be added to RFC6087bis:

1. Regular Expression Usage
YANG uses regular expressions to restrict string values. Such a restriction=
 can be a part of a "pattern" statement or a string matching function. [RFC=
7950] specifies that YANG regular expressions will conform to Appendix F in=
 [XSD-TYPES].
YANG models have been implemented in many different environments and the XS=
D variant of the regular expressions is not supported in many of these envi=
ronments. There are currently more than a dozen popular regular expression =
variants implemented in various environments. While the usage of the XSD va=
riant of regular expression described in [RFC7950] remains the preferred st=
andard, a few conventions are prescribed to maximize the portability of YAN=
G models between environments.

1.1. Regular Expression Variant Choice Precedence
YANG model designers SHOULD use the most portable syntax whenever possible.=
 Under the condition that XSD compliance is satisfied and there are multipl=
e choices for a given expression, the following precedence SHOULD be used t=
o choose a regular expressions variant:

o    POSIX base

o    POSIX extended

o    BSD

o    GNU Regular Expression Extensions

o    C++ Regular Expressions with std::regex

o    Others

For example, either \d or [0-9] can be used with equivalent semantics and t=
hey are both compliant to [XSD-TYPES]. [0-9] is recommended because [0-9] i=
s supported by POSIX base but \d is not.

1.2.  Convention Guidelines
1.2.1. Avoid Character Category Escapes
For example, in XSD regular expression, \d is a Character Category Escape d=
enoting the range of digits, i.e.,  [0-9]. To maximize portability, the mod=
el designers SHOULD use [0-9] instead of \d.

1.2.2. Avoid Unicode Characters
Unicode characters are allowed in XSD regular expressions, but are not supp=
orted in the POSIX variant. If possible, the model designers SHOULD avoid u=
sing Unicode characters, such as: \p{L} and \p{N}.

1.3. Conversion Tools
Tools can automatically convert regular expressions from one variant to ano=
ther. When a YANG model is implemented in an environment where XSD regular =
expressions are not supported, the recommended approach is to use a convers=
ion tool. For example, if needed, anchor position characters, i.e., '^' and=
 '$', can be added by a regular expression conversion tool.

1.4. Validation Tools
Tools can be used to validate regular expressions in YANG files. The follow=
ings are some of these tools:

o    YANG W3C Regex Expression Validator: https://yangcatalog.org/yangre

This an on-line tool with a WEB interface.

o    yangre as a part of the libyang package:
https://github.com/CESNET/libyang

This is an open source tool with a command line interface.

Usage:

    yangre [-hvV] -p  [-i] [-p  [-i] ...] 



Returns 0 if string matches the pattern(s), 1 if not and -1 on error.



Options:

  -h, --help              Show this help message and exit.

  -v, --version           Show version number and exit.

  -V, --verbose           Print the processing information.

  -i, --invert-match      Invert-match modifier for the closest preceeding

                          pattern.

  -p, --pattern=3D"REGEXP"  Regular expression including the quoting,

                          which is applied the same way as in a YANG module=
.



Examples:

  pattern "[0-9a-fA-F]*";      -> yangre -p '"[0-9a-fA-F]*"' '1F'

  pattern '[a-zA-Z0-9\-_.]*';  -> yangre -p "'[a-zA-Z0-9\-_.]*'" 'a-b'

  pattern [xX][mM][lL].*;      -> yangre -p '[xX][mM][lL].*' 'xml-encoding'



References



[XSD-TYPES] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second=
 Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-2004102=
8, October 2004, 

[POSIX]   IEEE Std 1003.1-2008, 2016, 

[BSD]     Regular Expression, 

[C++]     ISO/IEC DIS 14882: Programming Languages - C++, 2017.

Thanks,
- Xufeng

--_000_BN3PR0201MB0867DAD1212DBA2E88570AD5F1850BN3PR0201MB0867_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Members of Routing Area Yang DT have had some discus=
sions about the handling of various variants of regular expressions. The fo=
llowings are the current state, and we are thinking that if this topic can =
be added to RFC6087bis:


 


1.
Regular Expression Usage


YANG uses regular expressions to restrict string val=
ues. Such a restriction can be a part of a “pattern” statement =
or a string matching function. [RFC7950] specifies that YANG regular expres=
sions will conform to Appendix F in [XSD-TYPES].



YANG models have been implemented in many different =
environments and the XSD variant of the regular expressions is not supporte=
d in many of these environments. There are currently more than a dozen popu=
lar regular expression variants implemented
 in various environments. While the usage of the XSD variant of regular exp=
ression described in [RFC7950] remains the preferred standard, a few conven=
tions are prescribed to maximize the portability of YANG models between env=
ironments.


 


1.1.
Regular Expression Variant Choice Precedence

YANG model designers SHOULD use the most portable sy=
ntax whenever possible. Under the condition that XSD compliance is satisfie=
d and there are multiple choices for a given expression, the following prec=
edence SHOULD be used to choose a
 regular expressions variant:


o   
POSIX base


o   
POSIX extended


o   
BSD


o   
GNU Regular Expression Extensions


o   
C++ Regular Expressions with std::regex


o   
Others


For example, either \d or [0-9] can be used with equivalent semant=
ics and they are both compliant to [XSD-TYPES]. [0-9] is recommended becaus=
e [0-9] is supported by POSIX base but
 \d is not.


1.2.
 Convention Guidelines


1.2.1.
Avoid Character Category Escapes


For example, in XSD regular expression, \d is a Char=
acter Category Escape denoting the range of digits, i.e.,  [0-9]. To m=
aximize portability, the model designers SHOULD use [0-9] instead of \d.


 


1.2.2.
Avoid Unicode Characters


Unicode characters are allowed in XSD regular expres=
sions, but are not supported in the POSIX variant. If possible, the model d=
esigners SHOULD avoid using Unicode characters, such as: \p{L} and \p{N}.


 


1.3.
Conversion Tools


Tools can automatically convert regular expressions =
from one variant to another. When a YANG model is implemented in an environ=
ment where XSD regular expressions are not supported, the recommended appro=
ach is to use a conversion tool. For
 example, if needed, anchor position characters, i.e., ‘^’ and =
‘$’, can be added by a regular expression conversion tool.=



 


1.4.
Validation Tools


Tools can be used to validate regular expressions in=
 YANG files. The followings are some of these tools:


o   
YANG W3C Regex Expression Validator: https://yangca=
talog.org/yangre


This an =
on-line tool with a WEB interface.


o   
yangre as a part of the libyang package:

https://github.com/CESNET/libyang


This is =
an open source tool with a command line interface.


Usage:


    yangre [-hvV] -p <regexp1> [-i] =
[-p <regexp2> [-i] ...] <string>


 


Returns 0 if string matches the pattern(s), 1 if not and =
-1 on error.


 


Options:


  -h, --help      &nbs=
p;       Show this help message and exit.


  -v, --version      &=
nbsp;    Show version number and exit.


  -V, --verbose      &=
nbsp;    Print the processing information.


  -i, --invert-match      I=
nvert-match modifier for the closest preceeding


         &nb=
sp;            =
    pattern.


  -p, --pattern=3D"REGEXP"  Regular e=
xpression including the quoting,


         &nb=
sp;            =
    which is applied the same way as in a YANG module.<=
/o:p>


 


Examples:


  pattern "[0-9a-fA-F]*";   =
;   -> yangre -p '"[0-9a-fA-F]*"' '1F'

  pattern '[a-zA-Z0-9\-_.]*';  -> yangre -p =
"'[a-zA-Z0-9\-_.]*'" 'a-b'


  pattern [xX][mM][lL].*;    &nb=
sp; -> yangre -p '[xX][mM][lL].*' 'xml-encoding'


 


References


 


[XSD-TYPES] Biron, P. and A. Malhotra, &=
quot;XML Schema Part 2: Datatypes Second Edition", World Wide Web Cons=
ortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://ww=
w.w3.org/TR/2004/REC-xmlschema-2-20041028>



[POSIX]   IEEE Std 1003.1-2008=
, 2016, <https://standards.ieee.org/findstds/standard/1003.1-2008.html&g=
t;


[BSD]     Regular Ex=
pression, <http://www.bsd.org/regexintro.html>


[C++]     IS=
O/IEC DIS 14882: Programming Languages — C++, 2017.


 


Thanks,


- Xufeng






--_000_BN3PR0201MB0867DAD1212DBA2E88570AD5F1850BN3PR0201MB0867_--


From nobody Wed Aug 23 14:27:28 2017
Return-Path: 
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 401E91329EA for ; Wed, 23 Aug 2017 14:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 TL5XofEWrFNA for ; Wed, 23 Aug 2017 14:27:22 -0700 (PDT)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE62132714 for ; Wed, 23 Aug 2017 14:27:22 -0700 (PDT)
Received: by mail-wm0-x231.google.com with SMTP id x128so7670693wmg.1 for ; Wed, 23 Aug 2017 14:27:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NZQ21hpjZnrTdHToaHltmriWZwlm3NHDYd3kiK8TJDA=; b=B0dOpXDwKsc6JUe2irBDQ456jYuwkD692I5NfCnPLuWgXEyKteHxoozpa0xxZ3VNJH XuuaK59lyico5XHwA4W+OrFOYvR9QToi9M9/i6y+Hk021mYH0QOMGWRw4PL6nUYru6Px 9HLuPw9NWmaIe9kwPdHdiPqlvqZGDeKEWMISBvHRG+GtsKRjzErGIF4p4HrImk1z8VzZ 5M8GNEmnI/dcFDgPzMUYpfjv56+Ztykop0Av+zTmgLakMvobZYGmiNXZ/VbpA+Blm4Cs Ms164VWmaibKVdL26ArN9DbTML8ggt3nfBsiys8B5Rz3IZYCz0P55ulfrsy3eNtKaeyL Lkrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NZQ21hpjZnrTdHToaHltmriWZwlm3NHDYd3kiK8TJDA=; b=jk1/jFMOWBLbbnBe+JWUPyoG5NYndoqO3U/PzPHoT5M1ZzE/bHoDrCfqXrU2bAb81G BK8T7KusJMmOJn49UC0D+J8fDoWHsMmeHS3BZNliYmgEbbAWvgWF9QnNuGQu+gDCYemF Pr2z5hiWo+u4i9ldr8lUb7A2Ab+/gJ1au9Um8rIgiD8gRW6xzWZYNZWxvw/2KjYjz32M MGpqrszPujf8FFE3WHdP0G9km+cKKxb74nXiOnWDpxeS3C4G3Lr1yAKUTE1Na+mYbl59 F7LBZMvrTmGh44ASrWXKEuSg+VH8Rq4K3hPX34d8MgrzoWS6s2IuiHS0OGkgch0zOchD Ft8A==
X-Gm-Message-State: AHYfb5hkqjBC/Gc3iIm3QOnHq7LDHiabOYTMStFUV3vZQqT8xd4jj6/b QpLAE8YkNjWzhEhQ++Ik3tliBTnmGN8G
X-Received: by 10.28.180.138 with SMTP id d132mr2468481wmf.153.1503523640509;  Wed, 23 Aug 2017 14:27:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.221 with HTTP; Wed, 23 Aug 2017 14:27:19 -0700 (PDT)
In-Reply-To: <8063c77b-511a-474b-0a59-3c25c01123ac@labn.net>
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local> <95c65e38-a117-592d-5c3f-06d31f8845fa@labn.net> <20170823125855.mfuel6iwv5sxl3wy@elstar.local>  <8063c77b-511a-474b-0a59-3c25c01123ac@labn.net>
From: Andy Bierman 
Date: Wed, 23 Aug 2017 14:27:19 -0700
Message-ID: 
To: Lou Berger 
Cc: Kent Watsen , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114b33288147ee05577260ad"
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 21:27:26 -0000

--001a114b33288147ee05577260ad
Content-Type: text/plain; charset="UTF-8"

On Wed, Aug 23, 2017 at 2:19 PM, Lou Berger  wrote:

> My view is wikis are fine for folks "in the know" but RFCs are good for
> the wide distribution of interoperability standards and information
> related to their implementation.
>
> It seems to me that this is a case of the latter.
>
> Oh, RFCS are also sometimes used to ensure community consensus on IETF
> operation.
>
>
This work item is over 3 1/2 years old already.
The feature-creep just doesn't end.


> Lou
>

Andy


>
> On 8/23/2017 12:38 PM, Kent Watsen wrote:
> > Just wondering, but is an RFC the appropriate vehicle for this content?
> Would a wiki be better?
> >
> > K.
> >
> >
> > --
> >
> > Lets do it this way then. If we plan to revise this again in ~1 year,
> > so be it. We started this revision in Feb 2014. ;-)
> >
> > /js
> >
> > On Wed, Aug 23, 2017 at 08:07:28AM -0400, Lou Berger wrote:
> >> Juergen,
> >>
> >>
> >> On August 23, 2017 2:17:43 AM Juergen Schoenwaelder
> >>  wrote:
> >>
> >>> My preference is to have the guidelines say what people should do,
> >>> namely design NMDA models. I would prefer to keep any transition
> >>> aspects out of the guidelines.
> >> Well, this approach works for those who are deeply enmeshed in netmod
> >> and the IETF, it doesn't help those designing models/solutions during
> >> the current transition period.  IMO we can't forget about this important
> >> class of model developers and users.
> >>
> >>> If people want to include transition
> >>> aspects, it should be in the appendix (i.e., easy to remove / ignore
> >>> later on).
> >>>
> >> I don't see a material difference here.  Either way the document needs
> >> to be updated. See below for a specific proposed wording update.
> >>
> >>> I understand that there is a timing issue. The question is what you
> >>> mean with "NMDA solution makes it to publication (request)". If you
> >>> mean the core NMDA document, this is pretty much in reach and keeping
> >>> this guidelines document on hold until then may be an option. If you
> >>> mean the complete solution set, including model updates and moving the
> >>> protocol extensions in NETCONF to publication request, then this may
> >>> take a bit more time.
> >>>
> >> I mean the time when implementors can reasonably be told that the old
> >> way has been replaced by a fully defined (and able to be implemented)
> >> NMDA solution.  I think includes both netconf and restconf NMDA
> >> definitions.  I don't think it's reasonable to require implementation of
> >> drafts that are in-flux.
> >>
> >>
> >>
> >>> /js
> >>>
> >>> On Tue, Aug 22, 2017 at 04:32:14PM -0400, Lou Berger wrote:
> >>>> Kent/WG,
> >>>>
> >>>>     This seems a bit terse to me and not provide needed guidance
> during
> >>>> the current transition period.  I understood  the discussion ended up
> >>>> with the options being to either (1) provide the guidance as a
> >>>> standalone document, e.g., (a)-(s) in draft-dsdt-nmda-guidelines,
> with a
> >>>> pointer to it from 6087bis or (2) just move those sections to 6087
> bis.
> >>>> Either way, we'll need a new bis once the full NMDA solution makes it
> to
> >>>> publication (request).
> >>>>
> >>>> I thought the plan was to do (s).  If so, we need the full text.
> >>>> Looking at the current repo
> >>>> (https://github.com/netmod-wg/datastore-dt/blob/master/
> guidelines/guidelines.txt)
> >>>> it would be:
> >>>>
> >>>>     4.23 Operational Data
> >>>>
> >>>>     The following guidelines are meant to help modelers develop
> >>>>     YANG models that will maximize the utility of the model with
> >>>>     both current implementations and NMDA-capable implementations
> >>>>     [draft-ietf-netmod-revised-datastores].
> >>>>
> >> remove (a) and re-letter rest of list
> >>>>     (a) New models and models that are not concerned with the
> >>>>     operational state of configuration information SHOULD
> >>>>     immediately be structured to be NMDA-compatible.
> >> Add:
> >>    The remaining options MAY be followed during the time that
> >>    NMDA mechanisms are being defined.  These options will be
> >>    removed in a future update of this document once this definition
> >>    is complete.
> >>
> >> Does this work for you?  Moving it to an appendix just makes it harder
> >> for the reader and, again, the document needs to be revised either way
> >> in the future.
> >>
> >> Lou
> >>
> >>>>     (b) Models that require immediate support for "in use" and
> >>>>     "system created" information SHOULD be structured for NMDA.  A
> >>>>     non-NMDA version of these models SHOULD exist, either an
> >>>>     existing model or a model created either by hand or with
> >>>>     suitable tools that mirror the current modeling strategies.
> >>>>     Both the NMDA and the non-NMDA modules SHOULD be published in
> >>>>     the same document, with NMDA modules in the document main body
> >>>>     and the non-NMDA modules in a non-normative appendix.  The use
> >>>>     of the non-NMDA model will allow temporary bridging of the
> >>>>     time period until NMDA implementations are available.
> >>>>
> >>>>     (c) For published models, the model should be republished with
> >>>>     an NMDA-compatible structure, deprecating non-NMDA constructs.
> >>>>     For example, the "ietf-interfaces" model in ^RFC7223^ will be
> >>>>     restructured as an NMDA-compatible model.  The
> >>>>     "/interfaces-state" hierarchy will be marked "status
> >>>>     deprecated".  Models that mark their "/foo-state" hierarchy
> >>>>     with "status deprecated" will allow NMDA-capable
> >>>>     implementations to avoid the cost of duplicating the state
> >>>>     nodes, while enabling non-NMDA-capable implementations to
> >>>>     utilize them for access to the operational values.
> >>>>
> >>>>     (d) For models that augment models which have not been
> >>>>     structured with the NMDA, the modeler will have to consider
> >>>>     the structure of the base model and the guidelines listed
> >>>>     above.  Where possible, such models should move to new
> >>>>     revisions of the base model that are NMDA-compatible.  When
> >>>>     that is not possible, augmenting "state" containers SHOULD be
> >>>>     avoided, with the expectation that the base model will be
> >>>>     re-released with the state containers marked as deprecated.
> >>>>     It is RECOMMENDED to augment only the "/foo" hierarchy of the
> >>>>     base model.  Where this recommendation cannot be followed,
> >>>>     then any new "state" elements SHOULD be included in their own
> >>>>     module.
> >>>>
> >>>>     To create the temporary non-NMDA model from an NMDA model, the
> >>>>     following steps can be taken:
> >>>>
> >>>>     - Rename the module name by postpending "-state" to the
> >>>>       original module's name
> >>>>     - Change the namespace by postpending "-state" to the original
> >>>>       namespace value
> >>>>     - Change the prefix by postpending "-s" to the original prefix
> >>>>       value
> >>>>     - Set all top-level nodes to have a "config" statement of
> >>>>       value "false"
> >>>>     - add an import to the original module (e.g., for typedef
> >>>>       definitions)
> >>>>     - modify any imports, used for leafrefs or identityrefs, to
> >>>>       import the -state version of the module
> >>>>     - remove any 'typedef' or 'identity' definitions
> >>>>     - prefix any uses of the typedefs and identities accordingly
> >>>>     - update leafref and augment paths to use the new "-s" prefix
> >>>>
> >>>> For me (with any/all hats) the key downside is that we'll need to  rev
> >>>> this text (again) in the not too distant future, but that we don't
> have
> >>>> an alternative as LC on the full solution is still a bit away.
> >>>>
> >>>> What do people think?
> >>>>
> >>>> Lou
> >>>>
> >>>>
> >>>> On 8/22/2017 3:53 PM, Kent Watsen wrote:
> >>>>> Hi,
> >>>>>
> >>>>> During the meeting in Chicago, the NMDA authors took an action to
> >>>>> propose some text for S4.23.  After a little review, the following
> >>>>> emerged.  Yes, it's short, but was anything left anything out?
> >>>>>
> >>>>>
> >>>>> =====START=====
> >>>>>
> >>>>> 4.23 Operational Data
> >>>>>
> >>>>> Operational data includes both config "false" nodes as well as,
> >>>>> on servers supporting  [draft-ietf-netmod-revised-
> datastores],
> >>>>> the applied value of config "true" nodes.
> >>>>>
> >>>>> YANG modules SHOULD be designed assuming they will be used on
> >>>>> servers supporting .  With this in mind, YANG
> >>>>> modules SHOULD define config "false" wherever they make sense
> >>>>> to the data model.  Config "false" nodes SHOULD NOT be defined
> >>>>> to provide the operational value for configuration nodes,
> >>>>> except when the value space of a configured and operational
> >>>>> values may differ, in which case a distinct config "false"
> >>>>> node SHOULD be defined to hold the operational value for the
> >>>>> configured node.
> >>>>>
> >>>>> =====STOP=====
> >>>>>
> >>>>>
> >>>>> One question that came up is if "operational data" is a well-defined
> >>>>> term.  This string appears 10 times in rfc6087bis.  Most
> interestingly,
> >>>>> appendix Section A.8. (v05 to v06) includes this line item:
> >>>>>
> >>>>>     Changed term "operational state" to "operational data"
> >>>>>
> >>>>> So it seems to be deliberate...
> >>>>>
> >>>>>
> >>>>> Kent  // contributor
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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
> >>> --
> >>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> >>> Fax:   +49 421 200 3103         
> >>>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--001a114b33288147ee05577260ad
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Aug 23, 2017 at 2:19 PM, Lou Berger <lberger@labn.net> wrote:
My view is wikis are fine fo=
r folks "in the know" but RFCs are good for

the wide distribution of interoperability standards and information

related to their implementation.=C2=A0



It seems to me that this is a case of the latter.



Oh, RFCS are also sometimes used to ensure community consensus on IETF

operation.



This work item is over 3 1/2 years old=
 already.
The feature-creep just doesn't end.
=C2=
=A0

Lou

Andy
=C2=A0



On 8/23/2017 12:38 PM, Kent Watsen wrote:

> Just wondering, but is an RFC the appropriate vehicle for this content=
?=C2=A0 Would a wiki be better?

>

> K.

>

>

> --

>

> Lets do it this way then. If we plan to revise this again in ~1 year,<=
br>
> so be it. We started this revision in Feb 2014. ;-)

>

> /js

>

> On Wed, Aug 23, 2017 at 08:07:28AM -0400, Lou Berger wrote:

>> Juergen,

>>

>>

>> On August 23, 2017 2:17:43 AM Juergen Schoenwaelder

>> <j.scho=
enwaelder@jacobs-university.de> wrote:

>>

>>> My preference is to have the guidelines say what people should=
 do,

>>> namely design NMDA models. I would prefer to keep any transiti=
on

>>> aspects out of the guidelines.

>> Well, this approach works for those who are deeply enmeshed in net=
mod

>> and the IETF, it doesn't help those designing models/solutions=
 during

>> the current transition period.=C2=A0 IMO we can't forget about=
 this important

>> class of model developers and users.

>>

>>> If people want to include transition

>>> aspects, it should be in the appendix (i.e., easy to remove / =
ignore

>>> later on).

>>>

>> I don't see a material difference here.=C2=A0 Either way the d=
ocument needs

>> to be updated. See below for a specific proposed wording update.
>>

>>> I understand that there is a timing issue. The question is wha=
t you

>>> mean with "NMDA solution makes it to publication (request=
)". If you

>>> mean the core NMDA document, this is pretty much in reach and =
keeping

>>> this guidelines document on hold until then may be an option. =
If you

>>> mean the complete solution set, including model updates and mo=
ving the

>>> protocol extensions in NETCONF to publication request, then th=
is may

>>> take a bit more time.

>>>

>> I mean the time when implementors can reasonably be told that the =
old

>> way has been replaced by a fully defined (and able to be implement=
ed)

>> NMDA solution.=C2=A0 I think includes both netconf and restconf NM=
DA

>> definitions.=C2=A0 I don't think it's reasonable to requir=
e implementation of

>> drafts that are in-flux.

>>

>>

>>

>>> /js

>>>

>>> On Tue, Aug 22, 2017 at 04:32:14PM -0400, Lou Berger wrote:
>>>> Kent/WG,

>>>>

>>>>=C2=A0 =C2=A0 =C2=A0This seems a bit terse to me and not pr=
ovide needed guidance during

>>>> the current transition period.=C2=A0 I understood=C2=A0 th=
e discussion ended up

>>>> with the options being to either (1) provide the guidance =
as a

>>>> standalone document, e.g., (a)-(s) in draft-dsdt-nmda-guid=
elines, with a

>>>> pointer to it from 6087bis or (2) just move those sections=
 to 6087 bis.

>>>> Either way, we'll need a new bis once the full NMDA so=
lution makes it to

>>>> publication (request).

>>>>

>>>> I thought the plan was to do (s).=C2=A0 If so, we need the=
 full text.

>>>> Looking at the current repo

>>>> (htt=
ps://github.com/netmod-wg/datastore-dt/blob/master/guidelines/gui=
delines.txt)

>>>> it would be:

>>>>

>>>>=C2=A0 =C2=A0 =C2=A04.23 Operational Data

>>>>

>>>>=C2=A0 =C2=A0 =C2=A0The following guidelines are meant to h=
elp modelers develop

>>>>=C2=A0 =C2=A0 =C2=A0YANG models that will maximize the util=
ity of the model with

>>>>=C2=A0 =C2=A0 =C2=A0both current implementations and NMDA-c=
apable implementations

>>>>=C2=A0 =C2=A0 =C2=A0[draft-ietf-netmod-revised-datasto=
res].

>>>>

>> remove (a) and re-letter rest of list

>>>>=C2=A0 =C2=A0 =C2=A0(a) New models and models that are not =
concerned with the

>>>>=C2=A0 =C2=A0 =C2=A0operational state of configuration info=
rmation SHOULD

>>>>=C2=A0 =C2=A0 =C2=A0immediately be structured to be NMDA-co=
mpatible.

>> Add:

>>=C2=A0 =C2=A0 The remaining options MAY be followed during the time=
 that

>>=C2=A0 =C2=A0 NMDA mechanisms are being defined.=C2=A0 These option=
s will be

>>=C2=A0 =C2=A0 removed in a future update of this document once this=
 definition

>>=C2=A0 =C2=A0 is complete.

>>

>> Does this work for you?=C2=A0 Moving it to an appendix just makes =
it harder

>> for the reader and, again, the document needs to be revised either=
 way

>> in the future.

>>

>> Lou

>>

>>>>=C2=A0 =C2=A0 =C2=A0(b) Models that require immediate suppo=
rt for "in use" and

>>>>=C2=A0 =C2=A0 =C2=A0"system created" information =
SHOULD be structured for NMDA.=C2=A0 A

>>>>=C2=A0 =C2=A0 =C2=A0non-NMDA version of these models SHOULD=
 exist, either an

>>>>=C2=A0 =C2=A0 =C2=A0existing model or a model created eithe=
r by hand or with

>>>>=C2=A0 =C2=A0 =C2=A0suitable tools that mirror the current =
modeling strategies.

>>>>=C2=A0 =C2=A0 =C2=A0Both the NMDA and the non-NMDA modules =
SHOULD be published in

>>>>=C2=A0 =C2=A0 =C2=A0the same document, with NMDA modules in=
 the document main body

>>>>=C2=A0 =C2=A0 =C2=A0and the non-NMDA modules in a non-norma=
tive appendix.=C2=A0 The use

>>>>=C2=A0 =C2=A0 =C2=A0of the non-NMDA model will allow tempor=
ary bridging of the

>>>>=C2=A0 =C2=A0 =C2=A0time period until NMDA implementations =
are available.

>>>>

>>>>=C2=A0 =C2=A0 =C2=A0(c) For published models, the model sho=
uld be republished with

>>>>=C2=A0 =C2=A0 =C2=A0an NMDA-compatible structure, deprecati=
ng non-NMDA constructs.

>>>>=C2=A0 =C2=A0 =C2=A0For example, the "ietf-interfaces&=
quot; model in ^RFC7223^ will be

>>>>=C2=A0 =C2=A0 =C2=A0restructured as an NMDA-compatible mode=
l.=C2=A0 The

>>>>=C2=A0 =C2=A0 =C2=A0"/interfaces-state" hierarchy=
 will be marked "status

>>>>=C2=A0 =C2=A0 =C2=A0deprecated".=C2=A0 Models that mar=
k their "/foo-state" hierarchy

>>>>=C2=A0 =C2=A0 =C2=A0with "status deprecated" will=
 allow NMDA-capable

>>>>=C2=A0 =C2=A0 =C2=A0implementations to avoid the cost of du=
plicating the state

>>>>=C2=A0 =C2=A0 =C2=A0nodes, while enabling non-NMDA-capable =
implementations to

>>>>=C2=A0 =C2=A0 =C2=A0utilize them for access to the operatio=
nal values.

>>>>

>>>>=C2=A0 =C2=A0 =C2=A0(d) For models that augment models whic=
h have not been

>>>>=C2=A0 =C2=A0 =C2=A0structured with the NMDA, the modeler w=
ill have to consider

>>>>=C2=A0 =C2=A0 =C2=A0the structure of the base model and the=
 guidelines listed

>>>>=C2=A0 =C2=A0 =C2=A0above.=C2=A0 Where possible, such model=
s should move to new

>>>>=C2=A0 =C2=A0 =C2=A0revisions of the base model that are NM=
DA-compatible.=C2=A0 When

>>>>=C2=A0 =C2=A0 =C2=A0that is not possible, augmenting "=
state" containers SHOULD be

>>>>=C2=A0 =C2=A0 =C2=A0avoided, with the expectation that the =
base model will be

>>>>=C2=A0 =C2=A0 =C2=A0re-released with the state containers m=
arked as deprecated.

>>>>=C2=A0 =C2=A0 =C2=A0It is RECOMMENDED to augment only the &=
quot;/foo" hierarchy of the

>>>>=C2=A0 =C2=A0 =C2=A0base model.=C2=A0 Where this recommenda=
tion cannot be followed,

>>>>=C2=A0 =C2=A0 =C2=A0then any new "state" elements=
 SHOULD be included in their own

>>>>=C2=A0 =C2=A0 =C2=A0module.

>>>>

>>>>=C2=A0 =C2=A0 =C2=A0To create the temporary non-NMDA model =
from an NMDA model, the

>>>>=C2=A0 =C2=A0 =C2=A0following steps can be taken:

>>>>

>>>>=C2=A0 =C2=A0 =C2=A0- Rename the module name by postpending=
 "-state" to the

>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0original module's name

>>>>=C2=A0 =C2=A0 =C2=A0- Change the namespace by postpending &=
quot;-state" to the original

>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0namespace value

>>>>=C2=A0 =C2=A0 =C2=A0- Change the prefix by postpending &quo=
t;-s" to the original prefix

>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0value

>>>>=C2=A0 =C2=A0 =C2=A0- Set all top-level nodes to have a &qu=
ot;config" statement of

>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0value "false"

>>>>=C2=A0 =C2=A0 =C2=A0- add an import to the original module =
(e.g., for typedef

>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0definitions)

>>>>=C2=A0 =C2=A0 =C2=A0- modify any imports, used for leafrefs=
 or identityrefs, to

>>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0import the -state version of the=
 module

>>>>=C2=A0 =C2=A0 =C2=A0- remove any 'typedef' or '=
identity' definitions

>>>>=C2=A0 =C2=A0 =C2=A0- prefix any uses of the typedefs and i=
dentities accordingly

>>>>=C2=A0 =C2=A0 =C2=A0- update leafref and augment paths to u=
se the new "-s" prefix

>>>>

>>>> For me (with any/all hats) the key downside is that we'=
;ll need to=C2=A0 rev

>>>> this text (again) in the not too distant future, but that =
we don't have

>>>> an alternative as LC on the full solution is still a bit a=
way.

>>>>

>>>> What do people think?

>>>>

>>>> Lou

>>>>

>>>>

>>>> On 8/22/2017 3:53 PM, Kent Watsen wrote:

>>>>> Hi,

>>>>>

>>>>> During the meeting in Chicago, the NMDA authors took a=
n action to

>>>>> propose some text for S4.23.=C2=A0 After a little revi=
ew, the following

>>>>> emerged.=C2=A0 Yes, it's short, but was anything l=
eft anything out?

>>>>>

>>>>>

>>>>> =3D=3D=3D=3D=3DSTART=3D=3D=3D=3D=3D

>>>>>

>>>>> 4.23 Operational Data

>>>>>

>>>>> Operational data includes both config "false"=
; nodes as well as,

>>>>> on servers supporting <operational> [draft-ietf-=
netmod-revised-datastores],

>>>>> the applied value of config "true" nodes.
>>>>>

>>>>> YANG modules SHOULD be designed assuming they will be =
used on

>>>>> servers supporting <operational>.=C2=A0 With thi=
s in mind, YANG

>>>>> modules SHOULD define config "false" whereve=
r they make sense

>>>>> to the data model.=C2=A0 Config "false" node=
s SHOULD NOT be defined

>>>>> to provide the operational value for configuration nod=
es,

>>>>> except when the value space of a configured and operat=
ional

>>>>> values may differ, in which case a distinct config &qu=
ot;false"

>>>>> node SHOULD be defined to hold the operational value f=
or the

>>>>> configured node.

>>>>>

>>>>> =3D=3D=3D=3D=3DSTOP=3D=3D=3D=3D=3D

>>>>>

>>>>>

>>>>> One question that came up is if "operational data=
" is a well-defined

>>>>> term.=C2=A0 This string appears 10 times in rfc6087bis=
.=C2=A0 Most interestingly,

>>>>> appendix Section A.8. (v05 to v06) includes this line =
item:

>>>>>

>>>>>=C2=A0 =C2=A0 =C2=A0Changed term "operational stat=
e" to "operational data"

>>>>>

>>>>> So it seems to be deliberate...

>>>>>

>>>>>

>>>>> Kent=C2=A0 // contributor

>>>>>

>>>>>

>>>>>

>>>>> _______________________________________________
>>>>> netmod mailing list

>>>>> netmod@ietf.org=


>>>>> https://www.ietf.org/mailman/l=
istinfo/netmod

>>>>>

>>>> _______________________________________________

>>>> netmod mailing list

>>>> netmod@ietf.org

>>>> https://www.ietf.org/mailman/listi=
nfo/netmod

>>> --

>>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
Jacobs University Bremen gGmbH

>>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campu=
s Ring 1 | 28759 Bremen | Germany

>>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0<http://www.jacobs-university.de/>

>>>



_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod




--001a114b33288147ee05577260ad--


From nobody Wed Aug 23 14:52:49 2017
Return-Path: 
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 9A9C0132A21 for ; Wed, 23 Aug 2017 14:52:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 a1iUKPsoArTR for ; Wed, 23 Aug 2017 14:52:47 -0700 (PDT)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 105F9132A04 for ; Wed, 23 Aug 2017 14:52:47 -0700 (PDT)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id D603C1E08A8 for ; Wed, 23 Aug 2017 15:52:45 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id 0lsi1w00g2SSUrH01lslnT; Wed, 23 Aug 2017 15:52:45 -0600
X-Authority-Analysis: v=2.2 cv=IspuSP3g c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=KeKAF7QvOSUA:10 a=fwUzw_mm6kEFxbMRcQoA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=xhtsHIkuA1VsuS1Zel4BgZ0nTrfnrUWefLJdsVu4vH0=; b=T057fAUpZNSSKC13+Dnr4+IcTQ qGW1ItNmZtsBci3JjPuHhniNUd4TMw4aJtewlCtwwPSWzrgIwb+2xAAGuIDYPOOIotjIDkhJK29GC RinCiZqgAVJ6F7sVTCDaXT1jZ;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:57942 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dkdZp-000rDK-Rg; Wed, 23 Aug 2017 15:52:41 -0600
To: Andy Bierman 
Cc: Kent Watsen , "netmod@ietf.org" 
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local> <95c65e38-a117-592d-5c3f-06d31f8845fa@labn.net> <20170823125855.mfuel6iwv5sxl3wy@elstar.local>  <8063c77b-511a-474b-0a59-3c25c01123ac@labn.net> 
From: Lou Berger 
Message-ID: <4160c56d-b94d-bf0a-123a-260a8b107f48@labn.net>
Date: Wed, 23 Aug 2017 17:52:37 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dkdZp-000rDK-Rg
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:57942
X-Source-Auth: lberger@labn.net
X-Email-Count: 10
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 21:52:49 -0000

On 8/23/2017 5:27 PM, Andy Bierman wrote:
> This work item is over 3 1/2 years old already.
> The feature-creep just doesn't end.

This is a hugely valid point.  This was the major gating item. If it'll
help I'll make the change as proposed and send you a pull request.

I have heard two other issues:  avoiding submodules and use of common
regex, IMO let's get NMDA and whatever changes we can in in the next
week or two and then restart LC.  (Note Kent is Shepherd)

Lou


From nobody Wed Aug 23 15:01:28 2017
Return-Path: 
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 07CE5132A2A for ; Wed, 23 Aug 2017 15:01:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 t7S6477qw-5c for ; Wed, 23 Aug 2017 15:01:25 -0700 (PDT)
Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2D2E132A18 for ; Wed, 23 Aug 2017 15:01:24 -0700 (PDT)
Received: by mail-wr0-x22b.google.com with SMTP id p8so4387067wrf.5 for ; Wed, 23 Aug 2017 15:01:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LIbHoGVBgcLi9CneywwmheNdRylJs2CpEwcHuTH7PDk=; b=jOeBcV0ob9ww5Q7eU1/FEmR6wEt6de0Up/6qzhQkc6q7cX8FCTJAJpxVpTxUW4uSjq WvfYxwV7J9om1wCCdCMgcvGhOcv1OfyKeets+5YnuEnSVU9QKKjDVP9uhUnAetoTwEEA SuIoolyWwntf3uf8tbGlGc6Whr7TKxwc6aBxaKUmiG34DReWmmW8QzS+bgJF0QCigHcl Y7B4tfkH8cWs8PWnvEt1SkDFPe/cprMlFjd9ai6lEKC0T5y5VNQ61enKkHWmBfrh6uqJ IdGPu/cxpMYE4KSu17hedtVElsrM+KJHPPko9mnaRmTY8tSvMcMjWx46IfvPLABJ/jpf dD6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LIbHoGVBgcLi9CneywwmheNdRylJs2CpEwcHuTH7PDk=; b=UWbNfkZkPEQL6le084KiZdlaQyH2WdWToNmPLIWVR3TvFFvJzueZlYGrxe+LoOSORC ThVFBgyoqQ0GuSi2gzfwzPaNBUIPaOvdX/km/5sjM2cuCtvq84zSQwn0UbvPaX5y7E7k uVhtCSi43l4jKfuSERP3TolV/rJa8QNT6m7v4QxczMyEGnvHrXKxtfcK3P+4JyrvdPiD 9gc/z6dR6am9sCsEdRxR3LMSFgQ3q2rQHSCnoxalQ5wJhj+ZcagP0eSQS76/J5jR2qP6 GyZfxhhf8kQu8gtDHA5uiGHG3yaSQb8IwzhvTO7mlkcruZhpZAVUN4rdzToW5xFk9z/G N+jg==
X-Gm-Message-State: AHYfb5jqz2YKYErM0Cjheg4hXjUyaS9tWEpocN7cKc2+llFwwhi+Z9Tp LTQB/vrBEPgAZ5iRPiWFUia/D+8zwUBW
X-Received: by 10.223.174.89 with SMTP id u25mr2738382wrd.228.1503525683389; Wed, 23 Aug 2017 15:01:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.221 with HTTP; Wed, 23 Aug 2017 15:01:22 -0700 (PDT)
In-Reply-To: <4160c56d-b94d-bf0a-123a-260a8b107f48@labn.net>
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local> <95c65e38-a117-592d-5c3f-06d31f8845fa@labn.net> <20170823125855.mfuel6iwv5sxl3wy@elstar.local>  <8063c77b-511a-474b-0a59-3c25c01123ac@labn.net>  <4160c56d-b94d-bf0a-123a-260a8b107f48@labn.net>
From: Andy Bierman 
Date: Wed, 23 Aug 2017 15:01:22 -0700
Message-ID: 
To: Lou Berger 
Cc: Kent Watsen , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c1cd1a644fbdf055772da8f"
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 22:01:27 -0000

--94eb2c1cd1a644fbdf055772da8f
Content-Type: text/plain; charset="UTF-8"

On Wed, Aug 23, 2017 at 2:52 PM, Lou Berger  wrote:

>
>
> On 8/23/2017 5:27 PM, Andy Bierman wrote:
> > This work item is over 3 1/2 years old already.
> > The feature-creep just doesn't end.
>
> This is a hugely valid point.  This was the major gating item. If it'll
> help I'll make the change as proposed and send you a pull request.
>
>
OK


> I have heard two other issues:  avoiding submodules and use of common
> regex, IMO let's get NMDA and whatever changes we can in in the next
> week or two and then restart LC.  (Note Kent is Shepherd)
>
>
The regex text looks good. I am not saying the WG does not continue
to come up with new details that would benefit from further clarification.
(The opposite -- the WG will ALWAYS come up with more issues)

If there is a wiki it can be mentioned in 6087bis, and new issues can go to
the wiki.


Lou
>
>
Andy

--94eb2c1cd1a644fbdf055772da8f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Aug 23, 2017 at 2:52 PM, Lou Berger <lberger@labn.net> wrote:




On 8/23/2017 5:27 PM, Andy Bierman wrote:

> This work item is over 3 1/2 years old already.

> The feature-creep just doesn't end.



This is a hugely valid point.=C2=A0 This was the major gating item. If it&#=
39;ll

help I'll make the change as proposed and send you a pull request.



OK
=C2=A0

I have heard two other issues:=C2=A0 avoiding submodules and use of common<=
br>
regex, IMO let's get NMDA and whatever changes we can in in the next
week or two and then restart LC.=C2=A0 (Note Kent is Shepherd)



The regex text looks good. I am not saying the WG do=
es not continue
to come up with new details that would benefit fr=
om further clarification.
(The opposite -- the WG will ALWAYS com=
e up with more issues)

If there is a wiki it can b=
e mentioned in 6087bis, and new issues can go to the wiki.



Lou





Andy<=
/div>



--94eb2c1cd1a644fbdf055772da8f--


From nobody Wed Aug 23 15:06:08 2017
Return-Path: 
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 06E131323AA for ; Wed, 23 Aug 2017 15:06:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 G0YCwD5UGk8z for ; Wed, 23 Aug 2017 15:06:04 -0700 (PDT)
Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (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 81E78132A26 for ; Wed, 23 Aug 2017 15:06:04 -0700 (PDT)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id E6E79403AB for ; Wed, 23 Aug 2017 16:06:02 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id 0m5z1w01Y2SSUrH01m62yt; Wed, 23 Aug 2017 16:06:02 -0600
X-Authority-Analysis: v=2.2 cv=G8xsK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=KeKAF7QvOSUA:10 a=Gytp14BMhPakrdO9lysA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=9USgPcTOlJHNf23PcggWPUcjsIqn7a1hbDrsFNRZcgY=; b=KkhXVCmAXJY6bF6H1k9Cwcmldi o6RvuMjhY9ET62Kit8M2REaNPs/HOtLU2ieLRuk1/Ohx/dVQANYrOQNuGdrWo9t/jylp+7RZxZMTP MUB+Ckn6lO/SkImcmTNGirOHI;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:58054 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dkdmg-000tQN-RP; Wed, 23 Aug 2017 16:05:58 -0600
To: Andy Bierman 
Cc: Kent Watsen , "netmod@ietf.org" 
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local> <95c65e38-a117-592d-5c3f-06d31f8845fa@labn.net> <20170823125855.mfuel6iwv5sxl3wy@elstar.local>  <8063c77b-511a-474b-0a59-3c25c01123ac@labn.net>  <4160c56d-b94d-bf0a-123a-260a8b107f48@labn.net> 
From: Lou Berger 
Message-ID: <5430dd9c-89ea-b6bf-1b11-9689e7a24126@labn.net>
Date: Wed, 23 Aug 2017 18:05:54 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dkdmg-000tQN-RP
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:58054
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 22:06:06 -0000

On 8/23/2017 6:01 PM, Andy Bierman wrote:
> If there is a wiki it can be mentioned in 6087bis, and new issues can
> go to the wiki.
>

That's an interesting idea, i.e., replace the contents of the current
6087 bis with one line that says go look at a wiki.  My only reservation
is will this work for other SDOs, e.g., IEEE or BBF produced models?

Lou


From nobody Wed Aug 23 15:12:52 2017
Return-Path: 
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 4E2FD132A32 for ; Wed, 23 Aug 2017 15:12:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 G7N5sUTv8tvV for ; Wed, 23 Aug 2017 15:12:49 -0700 (PDT)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C01B132A2A for ; Wed, 23 Aug 2017 15:12:48 -0700 (PDT)
Received: by mail-wm0-x231.google.com with SMTP id x128so8241340wmg.1 for ; Wed, 23 Aug 2017 15:12:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OZErCDWsIvm7mHAUd/hsl1cncotSEB6kY/T8MfIOq2g=; b=ryvlrvGWGpG9vhdlyCTnwaYD7ibWVmRQeXYR9l2umkh5Wbjl15VnJcHRabE0/JvuhS anyYiCggl6j/EIHaVMyOmE4UHCp1rTCVmtJ4MAm4J6GRxemqlj1M/75R9kRTcaN0y0wr lyNufHdUmUKfZ8wO8Zs+kbhxmeK8xMH9sUcS+l2wih7NhRHRNv+2OZVAfU8ZvPz7q+pI XUGV4V3w3MzHQMveck8qARmQLOBIUmSIiRI3MJsGceT62Qoanxl0zk4DfAgxKi1qVCEK cTXKsJ9Lna8uwIQRtCaz0sbtEfTnY8haONzayyDjFzjihxYUgYkegtbP2nX+Z2E4M3HT KUjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OZErCDWsIvm7mHAUd/hsl1cncotSEB6kY/T8MfIOq2g=; b=JSVEpeCYqR3EC0ekmz+y7gLA1An4+HXI7hLZoDbT0qofgokvpiZbX71CZL/Nlip3Zw zRybH3nkrcuo9li4ezngFJGNG0PgwjGScE8lBq0CwfgTCoX4NTTwx0wh4rV6bzvXw60F HzBIfBOJjkaSeZ8w/IIgkKzdzNoPC2Ep55xFR76J91cEWdr4o2NNAe/3dVOGGc44rC+S 40n5P8QL4xCIZx1et0jEPhSGcz/mCDPm2lkeJkxIZYvZnzLr+rvR7oplt5GHfD42EF06 RnQVC9cdwog2p5Ke1uBM7HVGzjpVxJpzP9fzcq3DjRpUa20S7zwOtk11PQjMRp8gR1pm 7SaQ==
X-Gm-Message-State: AHYfb5h/Erhn+xptuJWZolKVFstdlZb1lXoFOK5/t9rgmwNHPvoxmA+k ruiOkVoj0vCoEyHyCMTTm8sKWCJjRx8B
X-Received: by 10.28.103.6 with SMTP id b6mr2346927wmc.28.1503526367012; Wed, 23 Aug 2017 15:12:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.221 with HTTP; Wed, 23 Aug 2017 15:12:46 -0700 (PDT)
In-Reply-To: <5430dd9c-89ea-b6bf-1b11-9689e7a24126@labn.net>
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local> <95c65e38-a117-592d-5c3f-06d31f8845fa@labn.net> <20170823125855.mfuel6iwv5sxl3wy@elstar.local>  <8063c77b-511a-474b-0a59-3c25c01123ac@labn.net>  <4160c56d-b94d-bf0a-123a-260a8b107f48@labn.net>  <5430dd9c-89ea-b6bf-1b11-9689e7a24126@labn.net>
From: Andy Bierman 
Date: Wed, 23 Aug 2017 15:12:46 -0700
Message-ID: 
To: Lou Berger 
Cc: Kent Watsen , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114b30d80450ed05577303cc"
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 22:12:51 -0000

--001a114b30d80450ed05577303cc
Content-Type: text/plain; charset="UTF-8"

On Wed, Aug 23, 2017 at 3:05 PM, Lou Berger  wrote:

>
>
> On 8/23/2017 6:01 PM, Andy Bierman wrote:
> > If there is a wiki it can be mentioned in 6087bis, and new issues can
> > go to the wiki.
> >
>
> That's an interesting idea, i.e., replace the contents of the current
> 6087 bis with one line that says go look at a wiki.  My only reservation
> is will this work for other SDOs, e.g., IEEE or BBF produced models?
>
>
I did not mean that.
I meant just a note to look to the wiki for new guidelines.
The RFC can be updated every few years.
If wait long enough, then this draft can be held up until YANG 2.0 is done
in 2021. ;-)
For people looking for stable references instead of work-in-progress, the
delays are  too long.




> Lou
>
>

Andy

--001a114b30d80450ed05577303cc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Aug 23, 2017 at 3:05 PM, Lou Berger <lberger@labn.net> wrote:




On 8/23/2017 6:01 PM, Andy Bierman wrote:

> If there is a wiki it can be mentioned in 6087bis, and new issues can<=
br>
> go to the wiki.

>



That's an interesting idea, i.e., replace the contents of the current
6087 bis with one line that says go look at a wiki.=C2=A0 My only reservati=
on

is will this work for other SDOs, e.g., IEEE or BBF produced models?



I did not mean that.
I meant just a note t=
o look to the wiki for new guidelines.
The RFC can be updated eve=
ry few years.
If wait long enough, then this draft can be held up=
 until YANG 2.0 is done in 2021. ;-)
For people looking for stabl=
e references instead of work-in-progress, the delays are =C2=A0too long.


=C2=A0

Lou






<=
/div>
Andy



--001a114b30d80450ed05577303cc--


From nobody Wed Aug 23 16:04:06 2017
Return-Path: 
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 39668132A6D for ; Wed, 23 Aug 2017 16:04:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 chMt-CCxNDe0 for ; Wed, 23 Aug 2017 16:04:00 -0700 (PDT)
Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3095D1326DF for ; Wed, 23 Aug 2017 16:04:00 -0700 (PDT)
Received: by mail-pg0-x235.google.com with SMTP id 83so6699235pgb.3 for ; Wed, 23 Aug 2017 16:04:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:subject:message-id:date:to:mime-version; bh=tVmcuNqsOfkXyRSORnzF+tMm46NGyG4PlFUioGKgoBA=; b=oGuVtI7ZVadIqrT9pO4avxMTBeBmH5Wnz5nUtTtfK0+XNZbC6JXj/t6rl2qUXlfBlw o4m+BmHXf3f8FKw6KDLOItRfLCN0+c9uxHIFaHbJJPN4l2EuPFsbsG4X+JXX7w21h6T3 XNoaW6/SAr0bp/Go1LJpgnHgozPS3thHrPT7NhtX+Bqf8UfVhBT0arB4qHpd0IEJUNrS ZZAeWR6oL+XaZkp/Mou+dn/Td0dGgV6a9Q1z66L2nGGscRmGxLjzsMqlpZEDv99iCgfg xdTHU/tbNTNHsDhAf0vuzI+GfgjOPPBv6BLrerz8lTkrAMIunnoEhaNOgt58aXFHVxsi AmNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=tVmcuNqsOfkXyRSORnzF+tMm46NGyG4PlFUioGKgoBA=; b=Uvm2GNKnQ63jbV+V31wSGEqFxP2CIY2/cf5NvjUdCbx/G09TSphtG/9dL814A4egou ahe2pUaXBou5x5FWcmDgaDtq1K1xF3KLDODG28r21PNW8+jVLOYzqao2paZyRwrDUARh 4uDA44pMC+a0LDC8MbMS/L38n02/OZgE6LAKdDg1UUdNn3Sr1nXzTpqy7Noam6Nkjmd0 fksE8i98YnghgTf1sqcuUWpySdsxwlWNw6tTpLAKIJzHfkxQ366TPGTXd73k7gJI5F42 NVgdS4ByL5o3WZTFtjHMXStk9dfCVbDb08AsVycItAe80r2pabjJI8Ed9ch2hzIW+s+H sexw==
X-Gm-Message-State: AHYfb5g65OwarL2CRHl62rfecAE1aS7i6D7hScnNYwepIRwrwP8dQdIW /cZMWa6Bqawxuh6TUG0=
X-Received: by 10.99.2.197 with SMTP id 188mr4402538pgc.307.1503529439501; Wed, 23 Aug 2017 16:03:59 -0700 (PDT)
Received: from ?IPv6:2001:420:30d:1320:5bc:1622:6565:a11a? ([2001:420:30d:1320:5bc:1622:6565:a11a]) by smtp.gmail.com with ESMTPSA id i128sm4798916pfg.81.2017.08.23.16.03.57 for  (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 23 Aug 2017 16:03:58 -0700 (PDT)
From: Mahesh Jethanandani 
Content-Type: multipart/alternative; boundary="Apple-Mail=_FE65FCE6-EF46-4768-B4A9-A2D9A74855DD"
Message-Id: 
Date: Wed, 23 Aug 2017 16:03:56 -0700
To: NetMod WG 
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: [netmod] draft-ietf-netmod-acl-model, issue#8&9
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Aug 2017 23:04:04 -0000

--Apple-Mail=_FE65FCE6-EF46-4768-B4A9-A2D9A74855DD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

An issue was opened against the ACL model to report that the current =
model does not support dscp (and ecn). A separate issue reported that =
precedence is missing in the model, since it defines the entire field as =
a tos field.

Is there a requirement to support TOS bits/field going forward? We are =
assuming that most implementations support DSCP than TOS. So the current =
thought is to replace the TOS field with DSCP (and ECN) bits as such.

leaf dscp {
      type uint8 {
        range 0..63;
      }
      description
        "Also known as Traffic Class in IPv6. The Diffrentiated
         Services Code Point (DSCP) provides an indication of=20
         the abstract parameters of the quality of service desired.";
      reference
        "RFC 2474.";
}=20
leaf ecn {
      type uint8 {
        range 0..3;
      }
      description
        "Explicit Congestion Notification.";
      reference
        "RFC 3168.";
}
Thoughts?

Mahesh Jethanandani
mjethanandani@gmail.com




--Apple-Mail=_FE65FCE6-EF46-4768-B4A9-A2D9A74855DD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

An issue was opened against the ACL model to report that the =
current model does not support dscp (and ecn). A separate issue reported =
that precedence is missing in the model, since it defines the entire =
field as a tos field.

Is there a requirement to support TOS bits/field going =
forward? We are assuming that most implementations support DSCP than =
TOS. So the current thought is to replace the TOS field with DSCP (and =
ECN) bits as such.

leaf dscp {
      type uint8 {
        range 0..63;
      }
      description
        "Also known as Traffic Class in IPv6. The Diffrentiated
         Services Code Point (DSCP) provides an indication of=20
         the abstract parameters of the quality of service desired.";
      reference
        "RFC 2474.";
}=20
leaf ecn {
      type uint8 {
        range 0..3;
      }
      description
        "Explicit Congestion Notification.";
      reference
        "RFC 3168.";
}
Thoughts?



Mahesh Jethanandani
mjethanandani@gmail.com








=

--Apple-Mail=_FE65FCE6-EF46-4768-B4A9-A2D9A74855DD--


From nobody Wed Aug 23 23:09:09 2017
Return-Path: 
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 EA874126E64 for ; Wed, 23 Aug 2017 23:09:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 EIfvDCqPc9VX for ; Wed, 23 Aug 2017 23:09:05 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04EED12426E for ; Wed, 23 Aug 2017 23:09:05 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id D169669; Thu, 24 Aug 2017 08:09:03 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id U5-ciEWqzcXt; Thu, 24 Aug 2017 08:09:02 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 24 Aug 2017 08:09:03 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8E648200E2; Thu, 24 Aug 2017 08:09:03 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 974HKAXZuH0n; Thu, 24 Aug 2017 08:09:02 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D18AF200E0; Thu, 24 Aug 2017 08:09:02 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id BFFB0404AAEB; Thu, 24 Aug 2017 08:09:00 +0200 (CEST)
Date: Thu, 24 Aug 2017 08:09:00 +0200
From: Juergen Schoenwaelder 
To: Xufeng Liu 
Cc: "'netmod@ietf.org'" 
Message-ID: <20170824060900.u5kcffzvwjr7mmob@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Xufeng Liu , "'netmod@ietf.org'" 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Aug 2017 06:09:08 -0000

On Wed, Aug 23, 2017 at 09:20:36PM +0000, Xufeng Liu wrote:
> Members of Routing Area Yang DT have had some discussions about the handling of various variants of regular expressions. The followings are the current state, and we are thinking that if this topic can be added to RFC6087bis:
> 
> 1. Regular Expression Usage
> YANG uses regular expressions to restrict string values. Such a restriction can be a part of a "pattern" statement or a string matching function. [RFC7950] specifies that YANG regular expressions will conform to Appendix F in [XSD-TYPES].
> YANG models have been implemented in many different environments and the XSD variant of the regular expressions is not supported in many of these environments. There are currently more than a dozen popular regular expression variants implemented in various environments. While the usage of the XSD variant of regular expression described in [RFC7950] remains the preferred standard, a few conventions are prescribed to maximize the portability of YANG models between environments.
>

I strongly disagree with this statement. The standard format are XSD
regular expressions. RFC 7950 section 9.4.5:

   The "pattern" statement, which is an optional substatement to the
   "type" statement, takes as an argument a regular expression string,
   as defined in [XSD-TYPES].

There is no notion of a 'preferred' standard.

> 1.1. Regular Expression Variant Choice Precedence
> YANG model designers SHOULD use the most portable syntax whenever possible. Under the condition that XSD compliance is satisfied and there are multiple choices for a given expression, the following precedence SHOULD be used to choose a regular expressions variant:
> 
> o    POSIX base
> 
> o    POSIX extended
> 
> o    BSD
> 
> o    GNU Regular Expression Extensions
> 
> o    C++ Regular Expressions with std::regex
> 
> o    Others

Strongly disagree. You either write YANG or something different. There
is no way to recognize what kind of regular expressions have been used
by the model designer. The value of a standard is that everybody does
the same.

> For example, either \d or [0-9] can be used with equivalent semantics and they are both compliant to [XSD-TYPES]. [0-9] is recommended because [0-9] is supported by POSIX base but \d is not.
> 
> 1.2.  Convention Guidelines
> 1.2.1. Avoid Character Category Escapes
> For example, in XSD regular expression, \d is a Character Category Escape denoting the range of digits, i.e.,  [0-9]. To maximize portability, the model designers SHOULD use [0-9] instead of \d.
> 
> 1.2.2. Avoid Unicode Characters
> Unicode characters are allowed in XSD regular expressions, but are not supported in the POSIX variant. If possible, the model designers SHOULD avoid using Unicode characters, such as: \p{L} and \p{N}.
> 
> 1.3. Conversion Tools
> Tools can automatically convert regular expressions from one variant to another. When a YANG model is implemented in an environment where XSD regular expressions are not supported, the recommended approach is to use a conversion tool. For example, if needed, anchor position characters, i.e., '^' and '$', can be added by a regular expression conversion tool.

If conversion tools exist that can convert, then by all means use XSD
in the YANG model and use tools to convert to whatever format your
implementation prefers to use.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Thu Aug 24 00:09:17 2017
Return-Path: 
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 4CC10132AD0 for ; Thu, 24 Aug 2017 00:09:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 j1obFWFIxa8O for ; Thu, 24 Aug 2017 00:09:14 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5F7132ACF for ; Thu, 24 Aug 2017 00:09:14 -0700 (PDT)
Received: from localhost (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 81FB61AE033A; Thu, 24 Aug 2017 09:09:11 +0200 (CEST)
Date: Thu, 24 Aug 2017 09:07:43 +0200 (CEST)
Message-Id: <20170824.090743.378914697216857460.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: ietfc@btconnect.com, netmod@ietf.org, andy@yumaworks.com
From: Martin Bjorklund 
In-Reply-To: <1503517541.5001.18.camel@nic.cz>
References: <87vale1ro2.fsf@cesnet.cz> <01de01d31c2f$2a7c34a0$4001a8c0@gateway.2wire.net> <1503517541.5001.18.camel@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] Pattern statements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Aug 2017 07:09:16 -0000

Ladislav Lhotka  wrote:
> t.petch p=ED=A8e v St 23. 08. 2017 v 17:28 +0100:
> > ----- Original Message -----
> > From: "Ladislav Lhotka" 
> > Sent: Wednesday, August 23, 2017 11:53 AM
> > =

> > > "t.petch"  writes:

[...]

> > > > time in base YANG before anyone noticed - it was just too compl=
ex.
> > > =

> > > Why was it wrong? Just because it was too complex?
> > =

> > No; it contained a definite error.
> > =

> > This was probably in yang-types and probably around 2012, quite lat=
e in
> > the day, and it stuck in my mind that so many had looked at it and
> > failed to spot that it was wrong, not just that it did not cater fo=
r
> > some aspects such as interface I-D.  I have used it before as an ex=
ample
> > of over complexity
> > =

> > I will have the e-mail filed, along with several thousand other NET=
MOD
> > ones so I will find it later rather than sooner.
> =

> I believe you mean the case when it was realized that "ipv4-address" =
and "ipv6-
> address" permit also zone indices: =

> =

> https://www.ietf.org/mail-archive/web/netmod/current/msg07456.html
> =

> We can hardly blaim the pattern expression for this though.
> =

> Other than that, I am not aware of any reported problem concerning th=
e "ipv6-
> address" type. In fact, I even don't think the two ANDed regexs are e=
xcessively
> complex. Just compare them to ABNF productions proposed for the same =
purpose in
> RFC 3986, Appendix A.
> =

> Lada
> =

> PS. Yes, it's my child, so I do have a reason to feel offended. :-)

Note that we had a different pattern to start with.

The new pattern was added 2009-03-27, and it is still the same as in
RFC 6991.

The new pattern was a simplified version using AND; the old version
was a single pattern.


/martin


From nobody Thu Aug 24 00:25:03 2017
Return-Path: 
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 ED1E613234E for ; Thu, 24 Aug 2017 00:25:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 JqqVTL6kwB_j for ; Thu, 24 Aug 2017 00:25:00 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 34BEF132332 for ; Thu, 24 Aug 2017 00:25:00 -0700 (PDT)
Received: from pluto.hedeland.org (81-228-155-109-no289.tbcn.telia.com [81.228.155.109]) by mail.tail-f.com (Postfix) with ESMTPSA id 830361AE033A; Thu, 24 Aug 2017 09:24:59 +0200 (CEST)
To: Xufeng Liu , "'netmod@ietf.org'" 
References:  <20170824060900.u5kcffzvwjr7mmob@elstar.local>
From: Per Hedeland 
Message-ID: <152f24b2-7947-9c76-714c-af226ab3fe91@tail-f.com>
Date: Thu, 24 Aug 2017 09:24:59 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20170824060900.u5kcffzvwjr7mmob@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Aug 2017 07:25:02 -0000

I strongly agree with all of Juergen's statements, and disagree also
with the suggestion to include the parts of the text that he didn't
specifically disagree with. And I'd like to add that the "lack of XSD
support" argument is pretty weak - there exists at least one freely
available implementation in the form of libxml2, which is actually
present by default in basically all "normal" Linux installations.
It is portable C code, and the parts needed for regexp matching amount
to just above 100 kB of compiled code on an x86_64 CPU.

--Per

On 2017-08-24 08:09, Juergen Schoenwaelder wrote:
> On Wed, Aug 23, 2017 at 09:20:36PM +0000, Xufeng Liu wrote:
>> Members of Routing Area Yang DT have had some discussions about the handling of various variants of regular expressions. The followings are the current state, and we are thinking that if this topic can be added to RFC6087bis:
>>
>> 1. Regular Expression Usage
>> YANG uses regular expressions to restrict string values. Such a restriction can be a part of a "pattern" statement or a string matching function. [RFC7950] specifies that YANG regular expressions will conform to Appendix F in [XSD-TYPES].
>> YANG models have been implemented in many different environments and the XSD variant of the regular expressions is not supported in many of these environments. There are currently more than a dozen popular regular expression variants implemented in various environments. While the usage of the XSD variant of regular expression described in [RFC7950] remains the preferred standard, a few conventions are prescribed to maximize the portability of YANG models between environments.
>>
> 
> I strongly disagree with this statement. The standard format are XSD
> regular expressions. RFC 7950 section 9.4.5:
> 
>     The "pattern" statement, which is an optional substatement to the
>     "type" statement, takes as an argument a regular expression string,
>     as defined in [XSD-TYPES].
> 
> There is no notion of a 'preferred' standard.
> 
>> 1.1. Regular Expression Variant Choice Precedence
>> YANG model designers SHOULD use the most portable syntax whenever possible. Under the condition that XSD compliance is satisfied and there are multiple choices for a given expression, the following precedence SHOULD be used to choose a regular expressions variant:
>>
>> o    POSIX base
>>
>> o    POSIX extended
>>
>> o    BSD
>>
>> o    GNU Regular Expression Extensions
>>
>> o    C++ Regular Expressions with std::regex
>>
>> o    Others
> 
> Strongly disagree. You either write YANG or something different. There
> is no way to recognize what kind of regular expressions have been used
> by the model designer. The value of a standard is that everybody does
> the same.
> 
>> For example, either \d or [0-9] can be used with equivalent semantics and they are both compliant to [XSD-TYPES]. [0-9] is recommended because [0-9] is supported by POSIX base but \d is not.
>>
>> 1.2.  Convention Guidelines
>> 1.2.1. Avoid Character Category Escapes
>> For example, in XSD regular expression, \d is a Character Category Escape denoting the range of digits, i.e.,  [0-9]. To maximize portability, the model designers SHOULD use [0-9] instead of \d.
>>
>> 1.2.2. Avoid Unicode Characters
>> Unicode characters are allowed in XSD regular expressions, but are not supported in the POSIX variant. If possible, the model designers SHOULD avoid using Unicode characters, such as: \p{L} and \p{N}.
>>
>> 1.3. Conversion Tools
>> Tools can automatically convert regular expressions from one variant to another. When a YANG model is implemented in an environment where XSD regular expressions are not supported, the recommended approach is to use a conversion tool. For example, if needed, anchor position characters, i.e., '^' and '$', can be added by a regular expression conversion tool.
> 
> If conversion tools exist that can convert, then by all means use XSD
> in the YANG model and use tools to convert to whatever format your
> implementation prefers to use.
> 
> /js
> 


From nobody Thu Aug 24 07:50:29 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE551321D8; Thu, 24 Aug 2017 07:50:26 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.58.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150358622687.24472.11560304513835259467@ietfa.amsl.com>
Date: Thu, 24 Aug 2017 07:50:26 -0700
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-revised-datastores-04.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Aug 2017 14:50:27 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

        Title           : Network Management Datastore Architecture
        Authors         : Martin Bjorklund
                          Juergen Schoenwaelder
                          Phil Shafer
                          Kent Watsen
                          Robert Wilton
	Filename        : draft-ietf-netmod-revised-datastores-04.txt
	Pages           : 35
	Date            : 2017-08-24

Abstract:
   Datastores are a fundamental concept binding the data models written
   in the YANG data modeling language to network management protocols
   such as NETCONF and RESTCONF.  This document defines an architectural
   framework for datastores based on the experience gained with the
   initial simpler model, addressing requirements that were not well
   supported in the initial model.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-04
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-revised-datastores-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-revised-datastores-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu Aug 24 07:52:30 2017
Return-Path: 
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 9E544132962 for ; Thu, 24 Aug 2017 07:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 sCxlajpmLKjr for ; Thu, 24 Aug 2017 07:52:28 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DA98E132981 for ; Thu, 24 Aug 2017 07:52:27 -0700 (PDT)
Received: from localhost (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id AF2D11AE046A for ; Thu, 24 Aug 2017 16:52:26 +0200 (CEST)
Date: Thu, 24 Aug 2017 16:50:58 +0200 (CEST)
Message-Id: <20170824.165058.1482838604076084317.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <150358622687.24472.11560304513835259467@ietfa.amsl.com>
References: <150358622687.24472.11560304513835259467@ietfa.amsl.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-revised-datastores-04.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Aug 2017 14:52:30 -0000

Hi,

This version addresses all known issues.  The authors believe that
this document is now ready for WG LC.


/martin


internet-drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Network Modeling WG of the IETF.
> 
>         Title           : Network Management Datastore Architecture
>         Authors         : Martin Bjorklund
>                           Juergen Schoenwaelder
>                           Phil Shafer
>                           Kent Watsen
>                           Robert Wilton
> 	Filename        : draft-ietf-netmod-revised-datastores-04.txt
> 	Pages           : 35
> 	Date            : 2017-08-24
> 
> Abstract:
>    Datastores are a fundamental concept binding the data models written
>    in the YANG data modeling language to network management protocols
>    such as NETCONF and RESTCONF.  This document defines an architectural
>    framework for datastores based on the experience gained with the
>    initial simpler model, addressing requirements that were not well
>    supported in the initial model.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-04
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-revised-datastores-04
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-revised-datastores-04
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Thu Aug 24 08:53:50 2017
Return-Path: 
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 9C2B4126DD9 for ; Thu, 24 Aug 2017 08:53:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 5wqP9ocYSzaE for ; Thu, 24 Aug 2017 08:53:46 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id A026413239A for ; Thu, 24 Aug 2017 08:53:44 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 108DF1820E76; Thu, 24 Aug 2017 17:53:43 +0200 (CEST)
Received: from localhost (cst-prg-99-26.cust.vodafone.cz [46.135.99.26]) by trail.lhotka.name (Postfix) with ESMTPSA id 3E77B1820043; Thu, 24 Aug 2017 17:53:39 +0200 (CEST)
From: Ladislav Lhotka 
To: Per Hedeland , Xufeng Liu , "'netmod\@ietf.org'" 
In-Reply-To: <152f24b2-7947-9c76-714c-af226ab3fe91@tail-f.com>
References:  <20170824060900.u5kcffzvwjr7mmob@elstar.local> <152f24b2-7947-9c76-714c-af226ab3fe91@tail-f.com>
Mail-Followup-To: Per Hedeland , Xufeng Liu , "'netmod\@ietf.org'" 
Date: Thu, 24 Aug 2017 17:54:05 +0200
Message-ID: <8760ddc676.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Aug 2017 15:53:49 -0000

Per Hedeland  writes:

> I strongly agree with all of Juergen's statements, and disagree also
> with the suggestion to include the parts of the text that he didn't
> specifically disagree with. And I'd like to add that the "lack of XSD
> support" argument is pretty weak - there exists at least one freely
> available implementation in the form of libxml2, which is actually
> present by default in basically all "normal" Linux installations.
> It is portable C code, and the parts needed for regexp matching amount
> to just above 100 kB of compiled code on an x86_64 CPU.

I wouldn't be so strict here. Libxml2 has its share of problems - for
one, its "official" bindings do not support Python3, so e.g. in Yangson
I had to use PyXB package instead and pyang gives up pattern validation
in Python 3 entirely. 

That being said, there doesn't seem to be a clearly superior
replacement, and some aspects of XSD regexes, such as support for
Unicode and the absence of ^ and $ anchors, make a lot of sense in
YANG. So I am also not in favour of the proposed change.

BTW, it is actually a shame that there is no standard regex language
that could be easily used in all programming languages. Oh well ...

Lada

>
> --Per
>
> On 2017-08-24 08:09, Juergen Schoenwaelder wrote:
>> On Wed, Aug 23, 2017 at 09:20:36PM +0000, Xufeng Liu wrote:
>>> Members of Routing Area Yang DT have had some discussions about the handling of various variants of regular expressions. The followings are the current state, and we are thinking that if this topic can be added to RFC6087bis:
>>>
>>> 1. Regular Expression Usage
>>> YANG uses regular expressions to restrict string values. Such a restriction can be a part of a "pattern" statement or a string matching function. [RFC7950] specifies that YANG regular expressions will conform to Appendix F in [XSD-TYPES].
>>> YANG models have been implemented in many different environments and the XSD variant of the regular expressions is not supported in many of these environments. There are currently more than a dozen popular regular expression variants implemented in various environments. While the usage of the XSD variant of regular expression described in [RFC7950] remains the preferred standard, a few conventions are prescribed to maximize the portability of YANG models between environments.
>>>
>> 
>> I strongly disagree with this statement. The standard format are XSD
>> regular expressions. RFC 7950 section 9.4.5:
>> 
>>     The "pattern" statement, which is an optional substatement to the
>>     "type" statement, takes as an argument a regular expression string,
>>     as defined in [XSD-TYPES].
>> 
>> There is no notion of a 'preferred' standard.
>> 
>>> 1.1. Regular Expression Variant Choice Precedence
>>> YANG model designers SHOULD use the most portable syntax whenever possible. Under the condition that XSD compliance is satisfied and there are multiple choices for a given expression, the following precedence SHOULD be used to choose a regular expressions variant:
>>>
>>> o    POSIX base
>>>
>>> o    POSIX extended
>>>
>>> o    BSD
>>>
>>> o    GNU Regular Expression Extensions
>>>
>>> o    C++ Regular Expressions with std::regex
>>>
>>> o    Others
>> 
>> Strongly disagree. You either write YANG or something different. There
>> is no way to recognize what kind of regular expressions have been used
>> by the model designer. The value of a standard is that everybody does
>> the same.
>> 
>>> For example, either \d or [0-9] can be used with equivalent semantics and they are both compliant to [XSD-TYPES]. [0-9] is recommended because [0-9] is supported by POSIX base but \d is not.
>>>
>>> 1.2.  Convention Guidelines
>>> 1.2.1. Avoid Character Category Escapes
>>> For example, in XSD regular expression, \d is a Character Category Escape denoting the range of digits, i.e.,  [0-9]. To maximize portability, the model designers SHOULD use [0-9] instead of \d.
>>>
>>> 1.2.2. Avoid Unicode Characters
>>> Unicode characters are allowed in XSD regular expressions, but are not supported in the POSIX variant. If possible, the model designers SHOULD avoid using Unicode characters, such as: \p{L} and \p{N}.
>>>
>>> 1.3. Conversion Tools
>>> Tools can automatically convert regular expressions from one variant to another. When a YANG model is implemented in an environment where XSD regular expressions are not supported, the recommended approach is to use a conversion tool. For example, if needed, anchor position characters, i.e., '^' and '$', can be added by a regular expression conversion tool.
>> 
>> If conversion tools exist that can convert, then by all means use XSD
>> in the YANG model and use tools to convert to whatever format your
>> implementation prefers to use.
>> 
>> /js
>> 
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Thu Aug 24 10:15:04 2017
Return-Path: 
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 0C71413202D for ; Thu, 24 Aug 2017 10:15:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 k7mkUOrNArB7 for ; Thu, 24 Aug 2017 10:15:00 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DC634126BF0 for ; Thu, 24 Aug 2017 10:14:59 -0700 (PDT)
Received: from mars.tail-f.com (unknown [173.38.220.44]) by mail.tail-f.com (Postfix) with ESMTPSA id B1CC01AE046A; Thu, 24 Aug 2017 19:14:58 +0200 (CEST)
References:  <20170824060900.u5kcffzvwjr7mmob@elstar.local> <152f24b2-7947-9c76-714c-af226ab3fe91@tail-f.com> <8760ddc676.fsf@nic.cz>
To: Ladislav Lhotka 
From: Per Hedeland 
Cc: "'netmod@ietf.org'" , Xufeng Liu 
Message-ID: <599F0991.7020900@tail-f.com>
Date: Thu, 24 Aug 2017 19:14:57 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <8760ddc676.fsf@nic.cz>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Aug 2017 17:15:02 -0000

On 2017-08-24 17:54, Ladislav Lhotka wrote:
> Per Hedeland  writes:
> 
>> I strongly agree with all of Juergen's statements, and disagree also
>> with the suggestion to include the parts of the text that he didn't
>> specifically disagree with. And I'd like to add that the "lack of XSD
>> support" argument is pretty weak - there exists at least one freely
>> available implementation in the form of libxml2, which is actually
>> present by default in basically all "normal" Linux installations.
>> It is portable C code, and the parts needed for regexp matching amount
>> to just above 100 kB of compiled code on an x86_64 CPU.
> 
> I wouldn't be so strict here. Libxml2 has its share of problems - for
> one, its "official" bindings do not support Python3, so e.g. in Yangson
> I had to use PyXB package instead and pyang gives up pattern validation
> in Python 3 entirely. 

I don't really see how claiming that the "lack of XSD support" argument
is weak amounts to being "strict" - and I suspect that the claim is
valid even considering the amount of pattern-validating server and
client implementations written in Python3. For a validation/translation
tool such as pyang, having a minuscule C program that is invoked for
validation would seem to be a reasonable implementation if no other
options exist, though admittedly it is an annoyance.

> That being said, there doesn't seem to be a clearly superior
> replacement, and some aspects of XSD regexes, such as support for
> Unicode and the absence of ^ and $ anchors, make a lot of sense in
> YANG. So I am also not in favour of the proposed change.

I did not see a proposed change to the standard YANG specification
regarding the regexp flavor, only a proposal that module authors SHOULD
show consideration for implementations that don't comply with the
standard.

--Per

> BTW, it is actually a shame that there is no standard regex language
> that could be easily used in all programming languages. Oh well ...
> 
> Lada
> 
>>
>> --Per
>>
>> On 2017-08-24 08:09, Juergen Schoenwaelder wrote:
>>> On Wed, Aug 23, 2017 at 09:20:36PM +0000, Xufeng Liu wrote:
>>>> Members of Routing Area Yang DT have had some discussions about the handling of various variants of regular expressions. The followings are the current state, and we are thinking that if this topic can be added to RFC6087bis:
>>>>
>>>> 1. Regular Expression Usage
>>>> YANG uses regular expressions to restrict string values. Such a restriction can be a part of a "pattern" statement or a string matching function. [RFC7950] specifies that YANG regular expressions will conform to Appendix F in [XSD-TYPES].
>>>> YANG models have been implemented in many different environments and the XSD variant of the regular expressions is not supported in many of these environments. There are currently more than a dozen popular regular expression variants implemented in various environments. While the usage of the XSD variant of regular expression described in [RFC7950] remains the preferred standard, a few conventions are prescribed to maximize the portability of YANG models between environments.
>>>>
>>>
>>> I strongly disagree with this statement. The standard format are XSD
>>> regular expressions. RFC 7950 section 9.4.5:
>>>
>>>     The "pattern" statement, which is an optional substatement to the
>>>     "type" statement, takes as an argument a regular expression string,
>>>     as defined in [XSD-TYPES].
>>>
>>> There is no notion of a 'preferred' standard.
>>>
>>>> 1.1. Regular Expression Variant Choice Precedence
>>>> YANG model designers SHOULD use the most portable syntax whenever possible. Under the condition that XSD compliance is satisfied and there are multiple choices for a given expression, the following precedence SHOULD be used to choose a regular expressions variant:
>>>>
>>>> o    POSIX base
>>>>
>>>> o    POSIX extended
>>>>
>>>> o    BSD
>>>>
>>>> o    GNU Regular Expression Extensions
>>>>
>>>> o    C++ Regular Expressions with std::regex
>>>>
>>>> o    Others
>>>
>>> Strongly disagree. You either write YANG or something different. There
>>> is no way to recognize what kind of regular expressions have been used
>>> by the model designer. The value of a standard is that everybody does
>>> the same.
>>>
>>>> For example, either \d or [0-9] can be used with equivalent semantics and they are both compliant to [XSD-TYPES]. [0-9] is recommended because [0-9] is supported by POSIX base but \d is not.
>>>>
>>>> 1.2.  Convention Guidelines
>>>> 1.2.1. Avoid Character Category Escapes
>>>> For example, in XSD regular expression, \d is a Character Category Escape denoting the range of digits, i.e.,  [0-9]. To maximize portability, the model designers SHOULD use [0-9] instead of \d.
>>>>
>>>> 1.2.2. Avoid Unicode Characters
>>>> Unicode characters are allowed in XSD regular expressions, but are not supported in the POSIX variant. If possible, the model designers SHOULD avoid using Unicode characters, such as: \p{L} and \p{N}.
>>>>
>>>> 1.3. Conversion Tools
>>>> Tools can automatically convert regular expressions from one variant to another. When a YANG model is implemented in an environment where XSD regular expressions are not supported, the recommended approach is to use a conversion tool. For example, if needed, anchor position characters, i.e., '^' and '$', can be added by a regular expression conversion tool.
>>>
>>> If conversion tools exist that can convert, then by all means use XSD
>>> in the YANG model and use tools to convert to whatever format your
>>> implementation prefers to use.
>>>
>>> /js
>>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Thu Aug 24 11:10:45 2017
Return-Path: 
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 79D3F132644 for ; Thu, 24 Aug 2017 11:10:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 14sN15wuAswR for ; Thu, 24 Aug 2017 11:10:44 -0700 (PDT)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 0632F13219C for ; Thu, 24 Aug 2017 11:10:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v7OIAene029701; Thu, 24 Aug 2017 20:10:40 +0200 (CEST)
Received: from [192.168.217.119] (p5DC7FC78.dip0.t-ipconnect.de [93.199.252.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3xdXQm5Cx3zDM9P; Thu, 24 Aug 2017 20:10:40 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Carsten Bormann 
In-Reply-To: 
Date: Thu, 24 Aug 2017 20:10:40 +0200
Cc: "netmod@ietf.org" 
X-Mao-Original-Outgoing-Id: 525291040.045082-41f0eca348b80ff97ffd46467522a377
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Xufeng Liu 
X-Mailer: Apple Mail (2.3273)
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 24 Aug 2017 18:10:45 -0000

On Aug 23, 2017, at 23:20, Xufeng Liu  wrote:
>=20
> 1.2.2. Avoid Unicode Characters
>=20
> Unicode characters are allowed in XSD regular expressions, but are not =
supported in the POSIX variant. If possible, the model designers SHOULD =
avoid using Unicode characters, such as: \p{L} and \p{N}.

All ASCII characters are Unicode Characters. =20
I think ASCII characters are useful and should be allowed.

(Is this maybe about Unicode categories and character classes?)

Gr=C3=BC=C3=9Fe, Carsten


From nobody Fri Aug 25 05:40:26 2017
Return-Path: 
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 3046C132027 for ; Fri, 25 Aug 2017 05:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.com
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 pF0-MP-aQQuJ for ; Fri, 25 Aug 2017 05:40:21 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0093.outbound.protection.outlook.com [104.47.32.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13405132BE4 for ; Fri, 25 Aug 2017 05:40:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com;  s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KFDa/ZNQiUqLLMNLijHTLdZ71iluGwk32U/luinnh/w=; b=kQvQuwtmF2Ak718SAJVhGioyRxFNXz2dppqAUJJkOMaTiJqI/G3720YH8NeKYXIMDPhYJBv/euTaybjRN/Ev4arl2FUG+Sv5o17LaAx2+dI+fWY1H4gi/nJMrQdk+hNImVs19Qr+flXPLoCS+yekfFNyt3CoWr8u72kttQaexB0=
Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by BN3PR0201MB1058.namprd02.prod.outlook.com (10.161.209.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.9; Fri, 25 Aug 2017 12:40:18 +0000
Received: from BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) by BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) with mapi id 15.01.1385.010; Fri, 25 Aug 2017 12:40:18 +0000
From: Xufeng Liu 
To: Per Hedeland , Ladislav Lhotka 
CC: "'netmod@ietf.org'" 
Thread-Topic: [netmod] Potential additions to rfc6087bis: RegEx guidelines
Thread-Index: AdMcU4SqqeTEr3DWR4ygcD75zJMNgAAS/WQAAAKnWIAAEce1gAAC0wKAACiZxdA=
Date: Fri, 25 Aug 2017 12:40:18 +0000
Message-ID: 
References:  <20170824060900.u5kcffzvwjr7mmob@elstar.local> <152f24b2-7947-9c76-714c-af226ab3fe91@tail-f.com> <8760ddc676.fsf@nic.cz> <599F0991.7020900@tail-f.com>
In-Reply-To: <599F0991.7020900@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNceGxpdVxhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLThjZGM5NWFlLTg5OTItMTFlNy05YzI4LTE4NWUwZmUzYzQ1Y1xhbWUtdGVzdFw4Y2RjOTViMC04OTkyLTExZTctOWMyOC0xODVlMGZlM2M0NWNib2R5LnR4dCIgc3o9IjY3MjgiIHQ9IjEzMTQ4MTM4NDE5MjQxMzQ4OCIgaD0iMURnMThvRkc1TUdMR2RwU0FrUjhUSXhaYkZRPSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg==
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Xufeng_Liu@jabil.com; 
x-originating-ip: [72.209.195.86]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0201MB1058; 6:lLnPOOs5QitKe1e6wM32tV4vZzgGYPirkcUGR3qPebZkFkDkChCtnqkxgEm6ivNXzBo0ELgeR6SX3RkRAthWppt4tcezgBe8QmxeZjlY6WXLyS1Yr5Zyq0m/PoRBtVixrEXCb+kOM2LbxHKkEqEQ38BIhPqy3bTu3rvtqqyGt7ikwd0EJaqSh5ysfYwNjQe8RpEUuuwFD3c5ddBI9U7fvcHOt6P+Gk43f6js2PYT6m2DEkKvWQlxFFre5FfWk4arox7bOINi9iv5AiNwGGzbilspJKOZQdVEyShp7uDE8x3GTg2fmZIIvqFd7aPgd63IUjAMXOTnZh50hzErsAIbuw==; 5:qBjqkN7pwt3nw7hOs+94q6/qFtfMs7FO9XQFsk/ndxFFzHxRSs2FM+cIb5cbdJ2U5D8gvpu9FX5Hjkxp031bgG+W/ISHzwb9ByRs5Pw4pTgcE87fnjEvlnPhgjUKOHQHiIaQPiS6tXfNEYLqda6GIg==; 24:+wJiiqHkIqypoEv5eA1KiRZG1vQjZeKfFODPsq5GKoWSWptXBwibVu68kVdp37M8Gr5/ViJZh8XwoW9IVfvRjaembROCl237f4Sj8yuyJ0I=; 7:blgKQXS/bTzTdIelC5kw4M4D6tKDXLR1a9IFYzsylPDbpIgu18b8pdEsYZ2gGyxIa3JSvCCkH0UNVSg4GV2s5zOk5vHJcmu7a4lRtxzB2xtmy8QqJSZ26izXxlaM24NOedaiaNIEfuzwLTJATg4IF08Ope0EnP7LISaX6vaWZNnItYWlQakz2QFcdg/SIFIqpPZJ4NOTCeHUJdhtS4A/B4LYne2i4EL+5TTYDwc3y/I=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: f4ea312a-1893-4cc8-d455-08d4ebb67175
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0201MB1058; 
x-ms-traffictypediagnostic: BN3PR0201MB1058:
x-exchange-antispam-report-test: UriScan:(158342451672863)(21534305686606);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123558100)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0201MB1058; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0201MB1058; 
x-forefront-prvs: 041032FF37
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(13464003)(189002)(24454002)(377424004)(377454003)(199003)(76176999)(77096006)(6116002)(53936002)(189998001)(7736002)(305945005)(102836003)(25786009)(3846002)(101416001)(54356999)(14454004)(72206003)(561944003)(50986999)(478600001)(8676002)(81166006)(5660300001)(81156014)(6246003)(6306002)(9686003)(6506006)(8936002)(33656002)(3280700002)(966005)(229853002)(106356001)(68736007)(55016002)(105586002)(3660700001)(99286003)(6436002)(74316002)(4326008)(7696004)(86362001)(2906002)(80792005)(2950100002)(66066001)(53546010)(2900100001)(93886005)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB1058; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: jabil.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: jabil.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2017 12:40:18.3493 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB1058
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Aug 2017 12:40:25 -0000

> -----Original Message-----
> From: Per Hedeland [mailto:per@tail-f.com]
> Sent: Thursday, August 24, 2017 1:15 PM
> To: Ladislav Lhotka 
> Cc: 'netmod@ietf.org' ; Xufeng Liu 
> Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
>=20
> On 2017-08-24 17:54, Ladislav Lhotka wrote:
> > Per Hedeland  writes:
> >
> >> I strongly agree with all of Juergen's statements, and disagree also
> >> with the suggestion to include the parts of the text that he didn't
> >> specifically disagree with. And I'd like to add that the "lack of XSD
> >> support" argument is pretty weak - there exists at least one freely
> >> available implementation in the form of libxml2, which is actually
> >> present by default in basically all "normal" Linux installations.
> >> It is portable C code, and the parts needed for regexp matching
> >> amount to just above 100 kB of compiled code on an x86_64 CPU.
> >
> > I wouldn't be so strict here. Libxml2 has its share of problems - for
> > one, its "official" bindings do not support Python3, so e.g. in
> > Yangson I had to use PyXB package instead and pyang gives up pattern
> > validation in Python 3 entirely.
>=20
> I don't really see how claiming that the "lack of XSD support" argument i=
s weak
> amounts to being "strict" - and I suspect that the claim is valid even co=
nsidering
> the amount of pattern-validating server and client implementations writte=
n in
> Python3. For a validation/translation tool such as pyang, having a minusc=
ule C
> program that is invoked for validation would seem to be a reasonable
> implementation if no other options exist, though admittedly it is an anno=
yance.
>=20
[Xufeng] Besides the language issue, there are situations where XML is not =
used, so that it is not desirable to include the libxml2 library.

> > That being said, there doesn't seem to be a clearly superior
> > replacement, and some aspects of XSD regexes, such as support for
> > Unicode and the absence of ^ and $ anchors, make a lot of sense in
> > YANG. So I am also not in favour of the proposed change.
>=20
> I did not see a proposed change to the standard YANG specification regard=
ing
> the regexp flavor, only a proposal that module authors SHOULD show
> consideration for implementations that don't comply with the standard.
>=20
[Xufeng] This is the point.

> --Per
>=20
> > BTW, it is actually a shame that there is no standard regex language
> > that could be easily used in all programming languages. Oh well ...
> >
> > Lada
> >
> >>
> >> --Per
> >>
> >> On 2017-08-24 08:09, Juergen Schoenwaelder wrote:
> >>> On Wed, Aug 23, 2017 at 09:20:36PM +0000, Xufeng Liu wrote:
> >>>> Members of Routing Area Yang DT have had some discussions about the
> handling of various variants of regular expressions. The followings are t=
he
> current state, and we are thinking that if this topic can be added to RFC=
6087bis:
> >>>>
> >>>> 1. Regular Expression Usage
> >>>> YANG uses regular expressions to restrict string values. Such a rest=
riction
> can be a part of a "pattern" statement or a string matching function. [RF=
C7950]
> specifies that YANG regular expressions will conform to Appendix F in [XS=
D-
> TYPES].
> >>>> YANG models have been implemented in many different environments and
> the XSD variant of the regular expressions is not supported in many of th=
ese
> environments. There are currently more than a dozen popular regular expre=
ssion
> variants implemented in various environments. While the usage of the XSD
> variant of regular expression described in [RFC7950] remains the preferre=
d
> standard, a few conventions are prescribed to maximize the portability of=
 YANG
> models between environments.
> >>>>
> >>>
> >>> I strongly disagree with this statement. The standard format are XSD
> >>> regular expressions. RFC 7950 section 9.4.5:
> >>>
> >>>     The "pattern" statement, which is an optional substatement to the
> >>>     "type" statement, takes as an argument a regular expression strin=
g,
> >>>     as defined in [XSD-TYPES].
> >>>
> >>> There is no notion of a 'preferred' standard.
> >>>
> >>>> 1.1. Regular Expression Variant Choice Precedence YANG model
> >>>> designers SHOULD use the most portable syntax whenever possible. Und=
er
> the condition that XSD compliance is satisfied and there are multiple cho=
ices for
> a given expression, the following precedence SHOULD be used to choose a
> regular expressions variant:
> >>>>
> >>>> o    POSIX base
> >>>>
> >>>> o    POSIX extended
> >>>>
> >>>> o    BSD
> >>>>
> >>>> o    GNU Regular Expression Extensions
> >>>>
> >>>> o    C++ Regular Expressions with std::regex
> >>>>
> >>>> o    Others
> >>>
> >>> Strongly disagree. You either write YANG or something different.
> >>> There is no way to recognize what kind of regular expressions have
> >>> been used by the model designer. The value of a standard is that
> >>> everybody does the same.
> >>>
> >>>> For example, either \d or [0-9] can be used with equivalent semantic=
s and
> they are both compliant to [XSD-TYPES]. [0-9] is recommended because [0-9=
] is
> supported by POSIX base but \d is not.
> >>>>
> >>>> 1.2.  Convention Guidelines
> >>>> 1.2.1. Avoid Character Category Escapes For example, in XSD regular
> >>>> expression, \d is a Character Category Escape denoting the range of =
digits,
> i.e.,  [0-9]. To maximize portability, the model designers SHOULD use [0-=
9]
> instead of \d.
> >>>>
> >>>> 1.2.2. Avoid Unicode Characters
> >>>> Unicode characters are allowed in XSD regular expressions, but are n=
ot
> supported in the POSIX variant. If possible, the model designers SHOULD a=
void
> using Unicode characters, such as: \p{L} and \p{N}.
> >>>>
> >>>> 1.3. Conversion Tools
> >>>> Tools can automatically convert regular expressions from one variant=
 to
> another. When a YANG model is implemented in an environment where XSD
> regular expressions are not supported, the recommended approach is to use=
 a
> conversion tool. For example, if needed, anchor position characters, i.e.=
, '^' and
> '$', can be added by a regular expression conversion tool.
> >>>
> >>> If conversion tools exist that can convert, then by all means use
> >>> XSD in the YANG model and use tools to convert to whatever format
> >>> your implementation prefers to use.
> >>>
> >>> /js
> >>>
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >


From nobody Fri Aug 25 05:42:44 2017
Return-Path: 
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 CF4AD132BE4 for ; Fri, 25 Aug 2017 05:42:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.com
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 ZFWMKGkwHl17 for ; Fri, 25 Aug 2017 05:42:42 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0101.outbound.protection.outlook.com [104.47.34.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4C1D132027 for ; Fri, 25 Aug 2017 05:42:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com;  s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sQ7hQZb9F5B50RhXqhS6OIfO1M5t2ONKXq0vIjYAdlk=; b=uBZKjU77S1vCnev1XODKNCd+5hj2D3phawyiv49qI+KcQAnpiN7KMtGiud71L0baXiNWNArMGDufBp5KBa7uUgvi8SVBrGD6pHYtYovimFnuNm5GdM+3/3PX6NmxirFDjnH0M6XUKkBiJ46uOycs3q+fvtHVhzf5859clxdm6s8=
Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by BN3PR0201MB1058.namprd02.prod.outlook.com (10.161.209.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.9; Fri, 25 Aug 2017 12:42:40 +0000
Received: from BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) by BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) with mapi id 15.01.1385.010; Fri, 25 Aug 2017 12:42:40 +0000
From: Xufeng Liu 
To: Carsten Bormann 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] Potential additions to rfc6087bis: RegEx guidelines
Thread-Index: AdMcU4SqqeTEr3DWR4ygcD75zJMNgAAsMZgAACbDoGA=
Date: Fri, 25 Aug 2017 12:42:39 +0000
Message-ID: 
References:  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNceGxpdVxhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLWUxMDFhZGY1LTg5OTItMTFlNy05YzI4LTE4NWUwZmUzYzQ1Y1xhbWUtdGVzdFxlMTAxYWRmNy04OTkyLTExZTctOWMyOC0xODVlMGZlM2M0NWNib2R5LnR4dCIgc3o9Ijk4OSIgdD0iMTMxNDgxMzg1NjA0OTA2MjI5IiBoPSJGT2YyeG5sekRwaDh6U1NFVDY0RU5Qb0RVeVk9IiBpZD0iIiBibD0iMCIgYm89IjEiLz48L21ldGE+
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Xufeng_Liu@jabil.com; 
x-originating-ip: [72.209.195.86]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0201MB1058; 6:QZw86dfITFfZ5BednebD9MyLS2Uljwl9hBRTUPL0BdhyfYgnGtffNwsfXdE6wZ9nI4Mo2RB6nEtPLECxVmJPSMpM7vQK35vZI0Yp7HuTuB526LkOkORXSTM5BVynl1qQlSD8jpRWvQzFftlQu4J/q1S0Rqyn+6SPtqT5HKOr+tCcnESkZJf8dNTGYof3mij8knrcVJPAHrUL97Mw9FeRT61ByOf6z4ZlAtZeqAD0HgPpO93jairkVg06sz/lF6Oz3qbNA1uf+tQvhnmWh3DnGrH0txX87uNafkzxhoxd8B1LVucer5BTCR1YmGbWzPcpJXw78s4oLrZRuxyg+W5IKg==; 5:4HrY6BvRVPpw2y7O3WQefkAWff+g4N8xY5RWN+hNqRn2vmJQiHzvIaDsX8uoIeRvjDoyTWwLkROfKkzU5mhE1kGKUptwuDFC+5OUt+3w56H2lDOfXRDX8IijbDKiFEToCdVYZL7yzmLL7KNach+zRw==; 24:Cy1j4k0zNK0oI0In+XjixzCGv+RYPQQLE4zNglabeUZWVylrZitIhzx50eGGhQR2loXG/42iXYnYUARg+xUi9WGJj9EceRMWHYgOK4s8V1w=; 7:lpZk1mEU+C9MfKcetf7NPFddFWfvpxDqQ1oBN4nJVyKclXdmfm29JvWBZJ4zZLtlpa4mRTrRTa924Oqr4noiiT6petYKXfyzpMTQzHZc1H7bM3UAxkG/jPsZj33UUmhd8Sg/c8WFUkBYwys5zmXujoSJ0POpnpz2oKowQWSRMnJVRK6JQ+eIb271jHsZtrfiIFPR9dOnwE6XcTKkqvVCDn0tp4xhkBfxcMbu60jVwtM=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 8460f666-2d27-432b-a63e-08d4ebb6c5e7
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0201MB1058; 
x-ms-traffictypediagnostic: BN3PR0201MB1058:
x-exchange-antispam-report-test: UriScan:(21534305686606);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123558100)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0201MB1058; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0201MB1058; 
x-forefront-prvs: 041032FF37
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(13464003)(189002)(24454002)(377454003)(199003)(76176999)(77096006)(6116002)(53936002)(189998001)(7736002)(305945005)(102836003)(25786009)(3846002)(101416001)(54356999)(14454004)(72206003)(50986999)(478600001)(8676002)(81166006)(5660300001)(81156014)(6246003)(9686003)(6506006)(8936002)(110136004)(33656002)(3280700002)(229853002)(106356001)(68736007)(55016002)(105586002)(3660700001)(99286003)(6436002)(74316002)(4326008)(7696004)(6916009)(86362001)(2906002)(80792005)(2950100002)(66066001)(53546010)(2900100001)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB1058; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: jabil.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: jabil.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2017 12:42:39.8607 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB1058
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Aug 2017 12:42:44 -0000

DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQ2Fyc3RlbiBCb3JtYW5u
IFttYWlsdG86Y2Fib0B0emkub3JnXQ0KPiBTZW50OiBUaHVyc2RheSwgQXVndXN0IDI0LCAyMDE3
IDI6MTEgUE0NCj4gVG86IFh1ZmVuZyBMaXUgPFh1ZmVuZ19MaXVAamFiaWwuY29tPg0KPiBDYzog
bmV0bW9kQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBQb3RlbnRpYWwgYWRkaXRp
b25zIHRvIHJmYzYwODdiaXM6IFJlZ0V4IGd1aWRlbGluZXMNCj4gDQo+IE9uIEF1ZyAyMywgMjAx
NywgYXQgMjM6MjAsIFh1ZmVuZyBMaXUgPFh1ZmVuZ19MaXVAamFiaWwuY29tPiB3cm90ZToNCj4g
Pg0KPiA+IDEuMi4yLiBBdm9pZCBVbmljb2RlIENoYXJhY3RlcnMNCj4gPg0KPiA+IFVuaWNvZGUg
Y2hhcmFjdGVycyBhcmUgYWxsb3dlZCBpbiBYU0QgcmVndWxhciBleHByZXNzaW9ucywgYnV0IGFy
ZSBub3QNCj4gc3VwcG9ydGVkIGluIHRoZSBQT1NJWCB2YXJpYW50LiBJZiBwb3NzaWJsZSwgdGhl
IG1vZGVsIGRlc2lnbmVycyBTSE9VTEQgYXZvaWQNCj4gdXNpbmcgVW5pY29kZSBjaGFyYWN0ZXJz
LCBzdWNoIGFzOiBccHtMfSBhbmQgXHB7Tn0uDQo+IA0KPiBBbGwgQVNDSUkgY2hhcmFjdGVycyBh
cmUgVW5pY29kZSBDaGFyYWN0ZXJzLg0KPiBJIHRoaW5rIEFTQ0lJIGNoYXJhY3RlcnMgYXJlIHVz
ZWZ1bCBhbmQgc2hvdWxkIGJlIGFsbG93ZWQuDQo+IA0KPiAoSXMgdGhpcyBtYXliZSBhYm91dCBV
bmljb2RlIGNhdGVnb3JpZXMgYW5kIGNoYXJhY3RlciBjbGFzc2VzPykNCltYdWZlbmddIENlcnRh
aW5seSB5b3UgYXJlIHJpZ2h0LiBJdCB3YXMgbWVhbnQgdG8gc2F5IG5vbi1BU0NJSSBVbmljb2Rl
IGNoYXJhY3RlcnMuDQoNCj4gDQo+IEdyw7zDn2UsIENhcnN0ZW4NCg0K


From nobody Fri Aug 25 05:53:09 2017
Return-Path: 
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 C8878132027 for ; Fri, 25 Aug 2017 05:53:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7VWFbCDFTv_c for ; Fri, 25 Aug 2017 05:53:05 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3642E132BEB for ; Fri, 25 Aug 2017 05:52:58 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 4410FF01; Fri, 25 Aug 2017 14:52:56 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id FllDP4u6g0PJ; Fri, 25 Aug 2017 14:52:53 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 25 Aug 2017 14:52:56 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24E10200E2; Fri, 25 Aug 2017 14:52:56 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id gEGuTak7Gc8d; Fri, 25 Aug 2017 14:52:55 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id ADA87200E0; Fri, 25 Aug 2017 14:52:55 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 46200404C84D; Fri, 25 Aug 2017 14:52:54 +0200 (CEST)
Date: Fri, 25 Aug 2017 14:52:54 +0200
From: Juergen Schoenwaelder 
To: Xufeng Liu 
Cc: Per Hedeland , Ladislav Lhotka , "'netmod@ietf.org'" 
Message-ID: <20170825125254.6nhnzkrar6fhu7zr@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Xufeng Liu , Per Hedeland , Ladislav Lhotka , "'netmod@ietf.org'" 
References:  <20170824060900.u5kcffzvwjr7mmob@elstar.local> <152f24b2-7947-9c76-714c-af226ab3fe91@tail-f.com> <8760ddc676.fsf@nic.cz> <599F0991.7020900@tail-f.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Aug 2017 12:53:08 -0000

On Fri, Aug 25, 2017 at 12:40:18PM +0000, Xufeng Liu wrote:
> 
> > I did not see a proposed change to the standard YANG specification
> > regarding the regexp flavor, only a proposal that module authors
> > SHOULD show consideration for implementations that don't comply
> > with the standard.
> >

> [Xufeng] This is the point.
 
Perhaps this did not come out properly.

Anyway, why would I as a YANG author have to replace \d with [0..9] so
that implementations that can't handle \d are happy? An implementation
can easily do this substitution itself before passing the pattern to
the regex engine it prefers to use. (I think this is what libyang is
actually doing, I think it uses pcre internally.)

YANG 1.0 and 1.1 are pretty clear which pattern syntax they use.
Implementations should try to support that.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Fri Aug 25 10:57:03 2017
Return-Path: 
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 6DF60132961 for ; Fri, 25 Aug 2017 10:57:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.01
X-Spam-Level: 
X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 qF4ejQbmDqNE for ; Fri, 25 Aug 2017 10:56:59 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0109.outbound.protection.outlook.com [104.47.40.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BBA5126BF0 for ; Fri, 25 Aug 2017 10:56:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vkPQ2nCJl/f+Yd+8J/lNLBJpFU5rRCv/IqZXETYSDYE=; b=I+J2WQ86fZjBgdBmkf5LrtXj/ln78Z4IPMN/diT4z0J7Lvf7yiplClhBbfvR8Rp5f2rDmUuYigS1mAp+SI5BDHNF+x5uobySwdIVRmpEKtxvfdXMfFlKrSE5bpdEQo3Fy9CV4nF6IjejumuPQFc/InMrZvijCO6f0KrYW7mNK98=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1587.namprd05.prod.outlook.com (10.161.217.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Fri, 25 Aug 2017 17:56:57 +0000
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.20.0013.005; Fri, 25 Aug 2017 17:56:57 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder , Lou Berger 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] rfc6087bis S4.23 replacement text
Thread-Index: AQHTG4BdACYCFz8ZdEeedIP50UiUz6KQ1HkAgACjbICAA6UgAA==
Date: Fri, 25 Aug 2017 17:56:57 +0000
Message-ID: 
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local>
In-Reply-To: <20170823061709.prezywubi7b32w7i@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1587; 6:Fa/IPwwWvJU4AkPibpgpegZdAei0lxWL+0DLxmznHiSii4s0dpgKDTb2N4sUF/49IxPmlUt6hhoFUsnCp0VOUpihFhJFXtXVuh9N8Fgq2oSqzBpYFaaptMrmEGqC/jC905zawif4AS5lvtIbuKk23ZqGSRsP6SkTEIKqh+/ZLDpxs8vO1mpmtELL1sRgqx1Z10ZA3pDt3l69Vi7qFZwJTgjvYt+pQoeJ3qD6bPS24tvYOBP9H+eCHGfflY4gJQ4/VL0GDwqhu5dsekIvErHW/u5RJdmn5sDXFwe6GZJ1lg+565F1uFBFH60yDIkC/QJL8NH/f68o79g0Yb6e9QpePQ==; 5:P6CaD3I4t1/3cDAj0nU8+xcJjB2uFova6+OUvNkWk/MRQs6DkrAUs9z8iqiEY3FSnxbCxO4SnrxJQNz8VoNWLdGEJaiXA5mDrSA0arjlXbUbCZug8zICuWJYdZ7KWIQVNkKd6yxD5kj7/6ASF7sQyw==; 24:uDu2FUPxXMWWlq5WC0V34y4oCkoOH+vSMB3R1hT/ABWjh/KGAK5TLw/E3nrAW13XML/L14w5kS2gkbZAjIq99PK37BKE1xIadZyWHWDVxaE=; 7:RCpQYHBsyMIgcTqrKt3FJk9YJ+tKJI7qMswGr11QcZQjKSDgrJrqEKhU/AIYrlD2/cpJ25kEm2TkZwLeGx91+BWW4odlYiWSVbcWZNxLHpOgY4UQppqo+TFcxFF8wSi96lWyrBspWeFluycR1n+dnMAbplF/dtoZfSn2gICWXyriNotB21d4/8RBKPvnSvNqT6HqiaHmfDGoBhqu4e/MEa+Ae9J+rc/cqPFaSv60dK4=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 2c769c48-b2f7-4b0f-f883-08d4ebe2adbc
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1587; 
x-ms-traffictypediagnostic: BN3PR0501MB1587:
x-exchange-antispam-report-test: UriScan:(166708455590820)(131327999870524);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1587; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1587; 
x-forefront-prvs: 041032FF37
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(24454002)(377454003)(199003)(189002)(6486002)(83506001)(5660300001)(8936002)(53546010)(77096006)(33656002)(66066001)(53936002)(305945005)(478600001)(68736007)(6436002)(97736004)(8676002)(81156014)(4001350100001)(81166006)(36756003)(229853002)(7736002)(2900100001)(189998001)(6506006)(83716003)(25786009)(3660700001)(4326008)(3280700002)(50986999)(54356999)(76176999)(2906002)(105586002)(106356001)(6116002)(6246003)(3846002)(102836003)(6306002)(6512007)(82746002)(966005)(2950100002)(101416001)(14454004)(86362001)(99286003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1587; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <971DFD3CE3967144857682B05CD59717@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2017 17:56:57.5124 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1587
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Aug 2017 17:57:02 -0000

DQpJIGhhdmUgdGhlIHNhbWUgcHJlZmVyZW5jZS4gIFRoZSBzdWdnZXN0ZWQgdGV4dCBkb2Vzbid0
IHNlZW0gdG8gcHJvdmlkZQ0KYWN0dWFsIG1vZGVsaW5nIHJlY29tbWVuZGF0aW9ucy4gIEFyZW4n
dCB0aGVyZSBkZXRhaWxzIGJleW9uZCBob3cgb3Igd2hlbg0KYSBtb2R1bGUgdHJhbnNpdGlvbnMg
dG8gTk1EQSB0aGF0IHNob3VsZCBiZSBtZW50aW9uZWQ/ICBGb3IgaW5zdGFuY2UsIHRoZQ0KdGV4
dCBkb2Vzbid0IHNheSBhbnl0aGluZyBhYm91dCBob3cgdG8gYmVzdCBsb2NhdGUgY29uZmlnIGZh
bHNlIG5vZGVzLCBvcg0KaG93IHRvIGhhbmRsZSB0aGUgY2FzZSB3aGVuIHRoZSB2YWx1ZS1zcGFj
ZSBmb3IgYSBub2RlJ3MgY29uZmlndXJlZCBhbmQNCm9wZXJhdGlvbmFsIHZhbHVlcyBkaWZmZXIu
ICBJcyB0aGUgcGxhbiB0aGVuIHRvIHJlbW92ZSB0aGlzIHNlY3Rpb24gDQplbnRpcmVseSBvbmNl
IHRoZSBOTURBLXRyYW5zaXRpb24gaXMgY29tcGxldGU/DQoNCkFzIEkgcmVjYWxsLCB0aGUgbWFp
biByZWFzb24gd2h5IHdlIGFyZSBub3QgcHJvZ3Jlc3NpbmcgdGhlIGd1aWRlbGluZXMgDQpkcmFm
dCBpcyBiZWNhdXNlIHdlIGRpZG4ndCB3YW50IHRoZSBzaG9ydC10ZXJtIHRleHQgaW4gYW4gUkZD
LiAgUHV0dGluZw0KZXNzZW50aWFsbHkgdGhlIHNhbWUgdGV4dCBpbnRvIGFub3RoZXIgUkZDIHNl
ZW1zIGluY29uc2lzdGVudC4gIEJ1dCwNCmlmIHRoaXMgaXMgd2hhdCBwZW9wbGUgd2FudCwgSSBz
dXBwb3NlIGl0J3MgYmV0dGVyIHRvIGNodXJuIHRoaXMgZG9jdW1lbnQNCnRoYW4gdG8gaW50cm9k
dWNlIGEgZGlzdGluY3QgImd1aWRlbGluZXMiIFJGQy4uLg0KDQpLLiAgLy8gY29udHJpYnV0b3IN
Cg0KDQotLQ0KDQpNeSBwcmVmZXJlbmNlIGlzIHRvIGhhdmUgdGhlIGd1aWRlbGluZXMgc2F5IHdo
YXQgcGVvcGxlIHNob3VsZCBkbywNCm5hbWVseSBkZXNpZ24gTk1EQSBtb2RlbHMuIEkgd291bGQg
cHJlZmVyIHRvIGtlZXAgYW55IHRyYW5zaXRpb24NCmFzcGVjdHMgb3V0IG9mIHRoZSBndWlkZWxp
bmVzLiBJZiBwZW9wbGUgd2FudCB0byBpbmNsdWRlIHRyYW5zaXRpb24NCmFzcGVjdHMsIGl0IHNo
b3VsZCBiZSBpbiB0aGUgYXBwZW5kaXggKGkuZS4sIGVhc3kgdG8gcmVtb3ZlIC8gaWdub3JlDQps
YXRlciBvbikuDQoNCkkgdW5kZXJzdGFuZCB0aGF0IHRoZXJlIGlzIGEgdGltaW5nIGlzc3VlLiBU
aGUgcXVlc3Rpb24gaXMgd2hhdCB5b3UNCm1lYW4gd2l0aCAiTk1EQSBzb2x1dGlvbiBtYWtlcyBp
dCB0byBwdWJsaWNhdGlvbiAocmVxdWVzdCkiLiBJZiB5b3UNCm1lYW4gdGhlIGNvcmUgTk1EQSBk
b2N1bWVudCwgdGhpcyBpcyBwcmV0dHkgbXVjaCBpbiByZWFjaCBhbmQga2VlcGluZw0KdGhpcyBn
dWlkZWxpbmVzIGRvY3VtZW50IG9uIGhvbGQgdW50aWwgdGhlbiBtYXkgYmUgYW4gb3B0aW9uLiBJ
ZiB5b3UNCm1lYW4gdGhlIGNvbXBsZXRlIHNvbHV0aW9uIHNldCwgaW5jbHVkaW5nIG1vZGVsIHVw
ZGF0ZXMgYW5kIG1vdmluZyB0aGUNCnByb3RvY29sIGV4dGVuc2lvbnMgaW4gTkVUQ09ORiB0byBw
dWJsaWNhdGlvbiByZXF1ZXN0LCB0aGVuIHRoaXMgbWF5DQp0YWtlIGEgYml0IG1vcmUgdGltZS4N
Cg0KL2pzDQoNCk9uIFR1ZSwgQXVnIDIyLCAyMDE3IGF0IDA0OjMyOjE0UE0gLTA0MDAsIExvdSBC
ZXJnZXIgd3JvdGU6DQo+IEtlbnQvV0csDQo+IA0KPiAgICAgVGhpcyBzZWVtcyBhIGJpdCB0ZXJz
ZSB0byBtZSBhbmQgbm90IHByb3ZpZGUgbmVlZGVkIGd1aWRhbmNlIGR1cmluZw0KPiB0aGUgY3Vy
cmVudCB0cmFuc2l0aW9uIHBlcmlvZC4gIEkgdW5kZXJzdG9vZCAgdGhlIGRpc2N1c3Npb24gZW5k
ZWQgdXAgDQo+IHdpdGggdGhlIG9wdGlvbnMgYmVpbmcgdG8gZWl0aGVyICgxKSBwcm92aWRlIHRo
ZSBndWlkYW5jZSBhcyBhDQo+IHN0YW5kYWxvbmUgZG9jdW1lbnQsIGUuZy4sIChhKS0ocykgaW4g
ZHJhZnQtZHNkdC1ubWRhLWd1aWRlbGluZXMsIHdpdGggYQ0KPiBwb2ludGVyIHRvIGl0IGZyb20g
NjA4N2JpcyBvciAoMikganVzdCBtb3ZlIHRob3NlIHNlY3Rpb25zIHRvIDYwODcgYmlzLiANCj4g
RWl0aGVyIHdheSwgd2UnbGwgbmVlZCBhIG5ldyBiaXMgb25jZSB0aGUgZnVsbCBOTURBIHNvbHV0
aW9uIG1ha2VzIGl0IHRvDQo+IHB1YmxpY2F0aW9uIChyZXF1ZXN0KS4NCj4gDQo+IEkgdGhvdWdo
dCB0aGUgcGxhbiB3YXMgdG8gZG8gKHMpLiAgSWYgc28sIHdlIG5lZWQgdGhlIGZ1bGwgdGV4dC4g
DQo+IExvb2tpbmcgYXQgdGhlIGN1cnJlbnQgcmVwbw0KPiAoaHR0cHM6Ly9naXRodWIuY29tL25l
dG1vZC13Zy9kYXRhc3RvcmUtZHQvYmxvYi9tYXN0ZXIvZ3VpZGVsaW5lcy9ndWlkZWxpbmVzLnR4
dCkNCj4gaXQgd291bGQgYmU6DQo+IA0KPiAgICAgNC4yMyBPcGVyYXRpb25hbCBEYXRhDQo+IA0K
PiAgICAgVGhlIGZvbGxvd2luZyBndWlkZWxpbmVzIGFyZSBtZWFudCB0byBoZWxwIG1vZGVsZXJz
IGRldmVsb3ANCj4gICAgIFlBTkcgbW9kZWxzIHRoYXQgd2lsbCBtYXhpbWl6ZSB0aGUgdXRpbGl0
eSBvZiB0aGUgbW9kZWwgd2l0aA0KPiAgICAgYm90aCBjdXJyZW50IGltcGxlbWVudGF0aW9ucyBh
bmQgTk1EQS1jYXBhYmxlIGltcGxlbWVudGF0aW9ucw0KPiAgICAgW2RyYWZ0LWlldGYtbmV0bW9k
LXJldmlzZWQtZGF0YXN0b3Jlc10uDQo+IA0KPiAgICAgKGEpIE5ldyBtb2RlbHMgYW5kIG1vZGVs
cyB0aGF0IGFyZSBub3QgY29uY2VybmVkIHdpdGggdGhlDQo+ICAgICBvcGVyYXRpb25hbCBzdGF0
ZSBvZiBjb25maWd1cmF0aW9uIGluZm9ybWF0aW9uIFNIT1VMRA0KPiAgICAgaW1tZWRpYXRlbHkg
YmUgc3RydWN0dXJlZCB0byBiZSBOTURBLWNvbXBhdGlibGUuDQo+IA0KPiAgICAgKGIpIE1vZGVs
cyB0aGF0IHJlcXVpcmUgaW1tZWRpYXRlIHN1cHBvcnQgZm9yICJpbiB1c2UiIGFuZA0KPiAgICAg
InN5c3RlbSBjcmVhdGVkIiBpbmZvcm1hdGlvbiBTSE9VTEQgYmUgc3RydWN0dXJlZCBmb3IgTk1E
QS4gIEENCj4gICAgIG5vbi1OTURBIHZlcnNpb24gb2YgdGhlc2UgbW9kZWxzIFNIT1VMRCBleGlz
dCwgZWl0aGVyIGFuDQo+ICAgICBleGlzdGluZyBtb2RlbCBvciBhIG1vZGVsIGNyZWF0ZWQgZWl0
aGVyIGJ5IGhhbmQgb3Igd2l0aA0KPiAgICAgc3VpdGFibGUgdG9vbHMgdGhhdCBtaXJyb3IgdGhl
IGN1cnJlbnQgbW9kZWxpbmcgc3RyYXRlZ2llcy4NCj4gICAgIEJvdGggdGhlIE5NREEgYW5kIHRo
ZSBub24tTk1EQSBtb2R1bGVzIFNIT1VMRCBiZSBwdWJsaXNoZWQgaW4NCj4gICAgIHRoZSBzYW1l
IGRvY3VtZW50LCB3aXRoIE5NREEgbW9kdWxlcyBpbiB0aGUgZG9jdW1lbnQgbWFpbiBib2R5DQo+
ICAgICBhbmQgdGhlIG5vbi1OTURBIG1vZHVsZXMgaW4gYSBub24tbm9ybWF0aXZlIGFwcGVuZGl4
LiAgVGhlIHVzZQ0KPiAgICAgb2YgdGhlIG5vbi1OTURBIG1vZGVsIHdpbGwgYWxsb3cgdGVtcG9y
YXJ5IGJyaWRnaW5nIG9mIHRoZQ0KPiAgICAgdGltZSBwZXJpb2QgdW50aWwgTk1EQSBpbXBsZW1l
bnRhdGlvbnMgYXJlIGF2YWlsYWJsZS4NCj4gDQo+ICAgICAoYykgRm9yIHB1Ymxpc2hlZCBtb2Rl
bHMsIHRoZSBtb2RlbCBzaG91bGQgYmUgcmVwdWJsaXNoZWQgd2l0aA0KPiAgICAgYW4gTk1EQS1j
b21wYXRpYmxlIHN0cnVjdHVyZSwgZGVwcmVjYXRpbmcgbm9uLU5NREEgY29uc3RydWN0cy4NCj4g
ICAgIEZvciBleGFtcGxlLCB0aGUgImlldGYtaW50ZXJmYWNlcyIgbW9kZWwgaW4gXlJGQzcyMjNe
IHdpbGwgYmUNCj4gICAgIHJlc3RydWN0dXJlZCBhcyBhbiBOTURBLWNvbXBhdGlibGUgbW9kZWwu
ICBUaGUNCj4gICAgICIvaW50ZXJmYWNlcy1zdGF0ZSIgaGllcmFyY2h5IHdpbGwgYmUgbWFya2Vk
ICJzdGF0dXMNCj4gICAgIGRlcHJlY2F0ZWQiLiAgTW9kZWxzIHRoYXQgbWFyayB0aGVpciAiL2Zv
by1zdGF0ZSIgaGllcmFyY2h5DQo+ICAgICB3aXRoICJzdGF0dXMgZGVwcmVjYXRlZCIgd2lsbCBh
bGxvdyBOTURBLWNhcGFibGUNCj4gICAgIGltcGxlbWVudGF0aW9ucyB0byBhdm9pZCB0aGUgY29z
dCBvZiBkdXBsaWNhdGluZyB0aGUgc3RhdGUNCj4gICAgIG5vZGVzLCB3aGlsZSBlbmFibGluZyBu
b24tTk1EQS1jYXBhYmxlIGltcGxlbWVudGF0aW9ucyB0bw0KPiAgICAgdXRpbGl6ZSB0aGVtIGZv
ciBhY2Nlc3MgdG8gdGhlIG9wZXJhdGlvbmFsIHZhbHVlcy4NCj4gDQo+ICAgICAoZCkgRm9yIG1v
ZGVscyB0aGF0IGF1Z21lbnQgbW9kZWxzIHdoaWNoIGhhdmUgbm90IGJlZW4NCj4gICAgIHN0cnVj
dHVyZWQgd2l0aCB0aGUgTk1EQSwgdGhlIG1vZGVsZXIgd2lsbCBoYXZlIHRvIGNvbnNpZGVyDQo+
ICAgICB0aGUgc3RydWN0dXJlIG9mIHRoZSBiYXNlIG1vZGVsIGFuZCB0aGUgZ3VpZGVsaW5lcyBs
aXN0ZWQNCj4gICAgIGFib3ZlLiAgV2hlcmUgcG9zc2libGUsIHN1Y2ggbW9kZWxzIHNob3VsZCBt
b3ZlIHRvIG5ldw0KPiAgICAgcmV2aXNpb25zIG9mIHRoZSBiYXNlIG1vZGVsIHRoYXQgYXJlIE5N
REEtY29tcGF0aWJsZS4gIFdoZW4NCj4gICAgIHRoYXQgaXMgbm90IHBvc3NpYmxlLCBhdWdtZW50
aW5nICJzdGF0ZSIgY29udGFpbmVycyBTSE9VTEQgYmUNCj4gICAgIGF2b2lkZWQsIHdpdGggdGhl
IGV4cGVjdGF0aW9uIHRoYXQgdGhlIGJhc2UgbW9kZWwgd2lsbCBiZQ0KPiAgICAgcmUtcmVsZWFz
ZWQgd2l0aCB0aGUgc3RhdGUgY29udGFpbmVycyBtYXJrZWQgYXMgZGVwcmVjYXRlZC4NCj4gICAg
IEl0IGlzIFJFQ09NTUVOREVEIHRvIGF1Z21lbnQgb25seSB0aGUgIi9mb28iIGhpZXJhcmNoeSBv
ZiB0aGUNCj4gICAgIGJhc2UgbW9kZWwuICBXaGVyZSB0aGlzIHJlY29tbWVuZGF0aW9uIGNhbm5v
dCBiZSBmb2xsb3dlZCwNCj4gICAgIHRoZW4gYW55IG5ldyAic3RhdGUiIGVsZW1lbnRzIFNIT1VM
RCBiZSBpbmNsdWRlZCBpbiB0aGVpciBvd24NCj4gICAgIG1vZHVsZS4NCj4gDQo+ICAgICBUbyBj
cmVhdGUgdGhlIHRlbXBvcmFyeSBub24tTk1EQSBtb2RlbCBmcm9tIGFuIE5NREEgbW9kZWwsIHRo
ZQ0KPiAgICAgZm9sbG93aW5nIHN0ZXBzIGNhbiBiZSB0YWtlbjoNCj4gICAgDQo+ICAgICAtIFJl
bmFtZSB0aGUgbW9kdWxlIG5hbWUgYnkgcG9zdHBlbmRpbmcgIi1zdGF0ZSIgdG8gdGhlDQo+ICAg
ICAgIG9yaWdpbmFsIG1vZHVsZSdzIG5hbWUNCj4gICAgIC0gQ2hhbmdlIHRoZSBuYW1lc3BhY2Ug
YnkgcG9zdHBlbmRpbmcgIi1zdGF0ZSIgdG8gdGhlIG9yaWdpbmFsDQo+ICAgICAgIG5hbWVzcGFj
ZSB2YWx1ZQ0KPiAgICAgLSBDaGFuZ2UgdGhlIHByZWZpeCBieSBwb3N0cGVuZGluZyAiLXMiIHRv
IHRoZSBvcmlnaW5hbCBwcmVmaXgNCj4gICAgICAgdmFsdWUNCj4gICAgIC0gU2V0IGFsbCB0b3At
bGV2ZWwgbm9kZXMgdG8gaGF2ZSBhICJjb25maWciIHN0YXRlbWVudCBvZg0KPiAgICAgICB2YWx1
ZSAiZmFsc2UiDQo+ICAgICAtIGFkZCBhbiBpbXBvcnQgdG8gdGhlIG9yaWdpbmFsIG1vZHVsZSAo
ZS5nLiwgZm9yIHR5cGVkZWYNCj4gICAgICAgZGVmaW5pdGlvbnMpDQo+ICAgICAtIG1vZGlmeSBh
bnkgaW1wb3J0cywgdXNlZCBmb3IgbGVhZnJlZnMgb3IgaWRlbnRpdHlyZWZzLCB0bw0KPiAgICAg
ICBpbXBvcnQgdGhlIC1zdGF0ZSB2ZXJzaW9uIG9mIHRoZSBtb2R1bGUNCj4gICAgIC0gcmVtb3Zl
IGFueSAndHlwZWRlZicgb3IgJ2lkZW50aXR5JyBkZWZpbml0aW9ucw0KPiAgICAgLSBwcmVmaXgg
YW55IHVzZXMgb2YgdGhlIHR5cGVkZWZzIGFuZCBpZGVudGl0aWVzIGFjY29yZGluZ2x5DQo+ICAg
ICAtIHVwZGF0ZSBsZWFmcmVmIGFuZCBhdWdtZW50IHBhdGhzIHRvIHVzZSB0aGUgbmV3ICItcyIg
cHJlZml4DQo+IA0KPiBGb3IgbWUgKHdpdGggYW55L2FsbCBoYXRzKSB0aGUga2V5IGRvd25zaWRl
IGlzIHRoYXQgd2UnbGwgbmVlZCB0byAgcmV2DQo+IHRoaXMgdGV4dCAoYWdhaW4pIGluIHRoZSBu
b3QgdG9vIGRpc3RhbnQgZnV0dXJlLCBidXQgdGhhdCB3ZSBkb24ndCBoYXZlDQo+IGFuIGFsdGVy
bmF0aXZlIGFzIExDIG9uIHRoZSBmdWxsIHNvbHV0aW9uIGlzIHN0aWxsIGEgYml0IGF3YXkuDQo+
IA0KPiBXaGF0IGRvIHBlb3BsZSB0aGluaz8gIA0KPiANCj4gTG91DQo+IA0KPiANCj4gT24gOC8y
Mi8yMDE3IDM6NTMgUE0sIEtlbnQgV2F0c2VuIHdyb3RlOg0KPiA+IEhpLA0KPiA+DQo+ID4gRHVy
aW5nIHRoZSBtZWV0aW5nIGluIENoaWNhZ28sIHRoZSBOTURBIGF1dGhvcnMgdG9vayBhbiBhY3Rp
b24gdG8gDQo+ID4gcHJvcG9zZSBzb21lIHRleHQgZm9yIFM0LjIzLiAgQWZ0ZXIgYSBsaXR0bGUg
cmV2aWV3LCB0aGUgZm9sbG93aW5nDQo+ID4gZW1lcmdlZC4gIFllcywgaXQncyBzaG9ydCwgYnV0
IHdhcyBhbnl0aGluZyBsZWZ0IGFueXRoaW5nIG91dD8NCj4gPg0KPiA+DQo+ID4gPT09PT1TVEFS
VD09PT09DQo+ID4NCj4gPiA0LjIzIE9wZXJhdGlvbmFsIERhdGENCj4gPg0KPiA+IE9wZXJhdGlv
bmFsIGRhdGEgaW5jbHVkZXMgYm90aCBjb25maWcgImZhbHNlIiBub2RlcyBhcyB3ZWxsIGFzLA0K
PiA+IG9uIHNlcnZlcnMgc3VwcG9ydGluZyA8b3BlcmF0aW9uYWw+IFtkcmFmdC1pZXRmLW5ldG1v
ZC1yZXZpc2VkLWRhdGFzdG9yZXNdLA0KPiA+IHRoZSBhcHBsaWVkIHZhbHVlIG9mIGNvbmZpZyAi
dHJ1ZSIgbm9kZXMuDQo+ID4gIA0KPiA+IFlBTkcgbW9kdWxlcyBTSE9VTEQgYmUgZGVzaWduZWQg
YXNzdW1pbmcgdGhleSB3aWxsIGJlIHVzZWQgb24gDQo+ID4gc2VydmVycyBzdXBwb3J0aW5nIDxv
cGVyYXRpb25hbD4uICBXaXRoIHRoaXMgaW4gbWluZCwgWUFORw0KPiA+IG1vZHVsZXMgU0hPVUxE
IGRlZmluZSBjb25maWcgImZhbHNlIiB3aGVyZXZlciB0aGV5IG1ha2Ugc2Vuc2UNCj4gPiB0byB0
aGUgZGF0YSBtb2RlbC4gIENvbmZpZyAiZmFsc2UiIG5vZGVzIFNIT1VMRCBOT1QgYmUgZGVmaW5l
ZA0KPiA+IHRvIHByb3ZpZGUgdGhlIG9wZXJhdGlvbmFsIHZhbHVlIGZvciBjb25maWd1cmF0aW9u
IG5vZGVzLCANCj4gPiBleGNlcHQgd2hlbiB0aGUgdmFsdWUgc3BhY2Ugb2YgYSBjb25maWd1cmVk
IGFuZCBvcGVyYXRpb25hbA0KPiA+IHZhbHVlcyBtYXkgZGlmZmVyLCBpbiB3aGljaCBjYXNlIGEg
ZGlzdGluY3QgY29uZmlnICJmYWxzZSIgDQo+ID4gbm9kZSBTSE9VTEQgYmUgZGVmaW5lZCB0byBo
b2xkIHRoZSBvcGVyYXRpb25hbCB2YWx1ZSBmb3IgdGhlDQo+ID4gY29uZmlndXJlZCBub2RlLg0K
PiA+DQo+ID4gPT09PT1TVE9QPT09PT0NCj4gPg0KPiA+DQo+ID4gT25lIHF1ZXN0aW9uIHRoYXQg
Y2FtZSB1cCBpcyBpZiAib3BlcmF0aW9uYWwgZGF0YSIgaXMgYSB3ZWxsLWRlZmluZWQNCj4gPiB0
ZXJtLiAgVGhpcyBzdHJpbmcgYXBwZWFycyAxMCB0aW1lcyBpbiByZmM2MDg3YmlzLiAgTW9zdCBp
bnRlcmVzdGluZ2x5LA0KPiA+IGFwcGVuZGl4IFNlY3Rpb24gQS44LiAodjA1IHRvIHYwNikgaW5j
bHVkZXMgdGhpcyBsaW5lIGl0ZW06DQo+ID4NCj4gPiAgICAgQ2hhbmdlZCB0ZXJtICJvcGVyYXRp
b25hbCBzdGF0ZSIgdG8gIm9wZXJhdGlvbmFsIGRhdGEiDQo+ID4NCj4gPiBTbyBpdCBzZWVtcyB0
byBiZSBkZWxpYmVyYXRlLi4uDQo+ID4NCj4gPg0KPiA+IEtlbnQgIC8vIGNvbnRyaWJ1dG9yDQo+
ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCj4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gbmV0bW9kQGlldGYub3JnDQo+
ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPg0KPiAN
Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0
bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KLS0gDQpKdWVyZ2VuIFNjaG9lbndhZWxkZXIg
ICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KUGhvbmU6ICs0OSA0MjEg
MjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0K
RmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVy
c2l0eS5kZS8+DQoNCg0K


From nobody Fri Aug 25 11:21:35 2017
Return-Path: 
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 EEE38132C0C for ; Fri, 25 Aug 2017 11:21:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 JOnrUfOp5_cj for ; Fri, 25 Aug 2017 11:21:31 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21905132256 for ; Fri, 25 Aug 2017 11:21:31 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id z132so4229651wmg.1 for ; Fri, 25 Aug 2017 11:21:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bIEltPcid7kh4ylaI8eURjaji5n5jzde3+iiSvObjTk=; b=gEFbADE9x7Mt9ked3gkxgaG6WzxL4dn/ONY0R5w0fB8Os67EHGyZRgw3Fxx8n8p5tD zm0wrX5+u24Z1CMsh8IodBE7uoDEw3e0Sx2iWGqtTN9Vh54X2ckENqB6Hs//nb7ouTuc sbhVXolTC8s22nv+hmuGnQw2xEDt5qGR+RXNRgApBMmKAOd5hJnsMD/S5zaa25gl9n8m 3CSL9a4l/3/uQ/H9cVNdl181tuUatsjc79QEnJ/f0PalDUl1mQ+3NcUohqunDpHvNt9Q uEueE+Ij0MUNa9Tnc4YM+10wyYKaOVtaiHueIwgMWZpeLCYJmunzo3P8OENLggg5D7ne Gj/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bIEltPcid7kh4ylaI8eURjaji5n5jzde3+iiSvObjTk=; b=fdg207MHmH3cmwa6WaKPK9jB8bxtUruq3FPQqI2Tm4eBnjBpwgOPXlGXGEGFsgT6YU zjHWReh/doJ/fVL/O2rRofkBIEYRyn+7/8tQeE06t7jr63/ZNhGSB7iyIWpHvhn19JdM aqyudQXV4F/WV8nZMIPUHBtNMhA/ft7jJU9btv8CBUUriLS1R2uMJaE8dcEm391fKSAX fleGJcoREhRQ7TTmMA01B0dkDYWw959+oA/qZGlWQCGShT96M9GQ6ZHKakHYGSFXUtwj ePxV6ebZe+qUsltqLtrQqIvV0AHOFxr8I1+3WuerJChoVY4g1Z/YBLHHczdA3oa5k3nT KRXQ==
X-Gm-Message-State: AHYfb5jy75HkNBWa9j1VqdP+37deTPWgWw+ua1eB5BkFruFFHzxJa4o0 y99tD2x3ZX92mV1T3Tu0U1r5lEnLCMmf
X-Received: by 10.28.101.5 with SMTP id z5mr200371wmb.136.1503685289495; Fri, 25 Aug 2017 11:21:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.221 with HTTP; Fri, 25 Aug 2017 11:21:28 -0700 (PDT)
In-Reply-To: 
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local> 
From: Andy Bierman 
Date: Fri, 25 Aug 2017 11:21:28 -0700
Message-ID: 
To: Kent Watsen 
Cc: Juergen Schoenwaelder , Lou Berger , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114b311688f8ae055798034e"
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Aug 2017 18:21:35 -0000

--001a114b311688f8ae055798034e
Content-Type: text/plain; charset="UTF-8"

On Fri, Aug 25, 2017 at 10:56 AM, Kent Watsen  wrote:

>
> I have the same preference.  The suggested text doesn't seem to provide
> actual modeling recommendations.  Aren't there details beyond how or when
> a module transitions to NMDA that should be mentioned?  For instance, the
> text doesn't say anything about how to best locate config false nodes, or
> how to handle the case when the value-space for a node's configured and
> operational values differ.  Is the plan then to remove this section
> entirely once the NMDA-transition is complete?
>
>

Obviously NMDA cannot be used for objects where the configuration value set
and the operstate value set differ, such as with the interface
admin-status/oper-status.
Do you want a sentence added that says to use config false leafs as needed
within the
configuration entry? A sentence that says operational data is embedded in
the
configuration entry?



> As I recall, the main reason why we are not progressing the guidelines
> draft is because we didn't want the short-term text in an RFC.  Putting
> essentially the same text into another RFC seems inconsistent.  But,
> if this is what people want, I suppose it's better to churn this document
> than to introduce a distinct "guidelines" RFC...


6087bis was supposed to be a minor update, not a living draft that doubles
as a YANG tutorial and ongoing issues list.



>
>
K.  // contributor
>
>
>
Andy


> --
>
> My preference is to have the guidelines say what people should do,
> namely design NMDA models. I would prefer to keep any transition
> aspects out of the guidelines. If people want to include transition
> aspects, it should be in the appendix (i.e., easy to remove / ignore
> later on).
>
> I understand that there is a timing issue. The question is what you
> mean with "NMDA solution makes it to publication (request)". If you
> mean the core NMDA document, this is pretty much in reach and keeping
> this guidelines document on hold until then may be an option. If you
> mean the complete solution set, including model updates and moving the
> protocol extensions in NETCONF to publication request, then this may
> take a bit more time.
>
> /js
>
> On Tue, Aug 22, 2017 at 04:32:14PM -0400, Lou Berger wrote:
> > Kent/WG,
> >
> >     This seems a bit terse to me and not provide needed guidance during
> > the current transition period.  I understood  the discussion ended up
> > with the options being to either (1) provide the guidance as a
> > standalone document, e.g., (a)-(s) in draft-dsdt-nmda-guidelines, with a
> > pointer to it from 6087bis or (2) just move those sections to 6087 bis.
> > Either way, we'll need a new bis once the full NMDA solution makes it to
> > publication (request).
> >
> > I thought the plan was to do (s).  If so, we need the full text.
> > Looking at the current repo
> > (https://github.com/netmod-wg/datastore-dt/blob/master/
> guidelines/guidelines.txt)
> > it would be:
> >
> >     4.23 Operational Data
> >
> >     The following guidelines are meant to help modelers develop
> >     YANG models that will maximize the utility of the model with
> >     both current implementations and NMDA-capable implementations
> >     [draft-ietf-netmod-revised-datastores].
> >
> >     (a) New models and models that are not concerned with the
> >     operational state of configuration information SHOULD
> >     immediately be structured to be NMDA-compatible.
> >
> >     (b) Models that require immediate support for "in use" and
> >     "system created" information SHOULD be structured for NMDA.  A
> >     non-NMDA version of these models SHOULD exist, either an
> >     existing model or a model created either by hand or with
> >     suitable tools that mirror the current modeling strategies.
> >     Both the NMDA and the non-NMDA modules SHOULD be published in
> >     the same document, with NMDA modules in the document main body
> >     and the non-NMDA modules in a non-normative appendix.  The use
> >     of the non-NMDA model will allow temporary bridging of the
> >     time period until NMDA implementations are available.
> >
> >     (c) For published models, the model should be republished with
> >     an NMDA-compatible structure, deprecating non-NMDA constructs.
> >     For example, the "ietf-interfaces" model in ^RFC7223^ will be
> >     restructured as an NMDA-compatible model.  The
> >     "/interfaces-state" hierarchy will be marked "status
> >     deprecated".  Models that mark their "/foo-state" hierarchy
> >     with "status deprecated" will allow NMDA-capable
> >     implementations to avoid the cost of duplicating the state
> >     nodes, while enabling non-NMDA-capable implementations to
> >     utilize them for access to the operational values.
> >
> >     (d) For models that augment models which have not been
> >     structured with the NMDA, the modeler will have to consider
> >     the structure of the base model and the guidelines listed
> >     above.  Where possible, such models should move to new
> >     revisions of the base model that are NMDA-compatible.  When
> >     that is not possible, augmenting "state" containers SHOULD be
> >     avoided, with the expectation that the base model will be
> >     re-released with the state containers marked as deprecated.
> >     It is RECOMMENDED to augment only the "/foo" hierarchy of the
> >     base model.  Where this recommendation cannot be followed,
> >     then any new "state" elements SHOULD be included in their own
> >     module.
> >
> >     To create the temporary non-NMDA model from an NMDA model, the
> >     following steps can be taken:
> >
> >     - Rename the module name by postpending "-state" to the
> >       original module's name
> >     - Change the namespace by postpending "-state" to the original
> >       namespace value
> >     - Change the prefix by postpending "-s" to the original prefix
> >       value
> >     - Set all top-level nodes to have a "config" statement of
> >       value "false"
> >     - add an import to the original module (e.g., for typedef
> >       definitions)
> >     - modify any imports, used for leafrefs or identityrefs, to
> >       import the -state version of the module
> >     - remove any 'typedef' or 'identity' definitions
> >     - prefix any uses of the typedefs and identities accordingly
> >     - update leafref and augment paths to use the new "-s" prefix
> >
> > For me (with any/all hats) the key downside is that we'll need to  rev
> > this text (again) in the not too distant future, but that we don't have
> > an alternative as LC on the full solution is still a bit away.
> >
> > What do people think?
> >
> > Lou
> >
> >
> > On 8/22/2017 3:53 PM, Kent Watsen wrote:
> > > Hi,
> > >
> > > During the meeting in Chicago, the NMDA authors took an action to
> > > propose some text for S4.23.  After a little review, the following
> > > emerged.  Yes, it's short, but was anything left anything out?
> > >
> > >
> > > =====START=====
> > >
> > > 4.23 Operational Data
> > >
> > > Operational data includes both config "false" nodes as well as,
> > > on servers supporting  [draft-ietf-netmod-revised-
> datastores],
> > > the applied value of config "true" nodes.
> > >
> > > YANG modules SHOULD be designed assuming they will be used on
> > > servers supporting .  With this in mind, YANG
> > > modules SHOULD define config "false" wherever they make sense
> > > to the data model.  Config "false" nodes SHOULD NOT be defined
> > > to provide the operational value for configuration nodes,
> > > except when the value space of a configured and operational
> > > values may differ, in which case a distinct config "false"
> > > node SHOULD be defined to hold the operational value for the
> > > configured node.
> > >
> > > =====STOP=====
> > >
> > >
> > > One question that came up is if "operational data" is a well-defined
> > > term.  This string appears 10 times in rfc6087bis.  Most interestingly,
> > > appendix Section A.8. (v05 to v06) includes this line item:
> > >
> > >     Changed term "operational state" to "operational data"
> > >
> > > So it seems to be deliberate...
> > >
> > >
> > > Kent  // contributor
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--001a114b311688f8ae055798034e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Fri, Aug 25, 2017 at 10:56 AM, Kent Watsen <kwatsen@juniper.net> wrote:


I have the same preference.=C2=A0 The suggested text doesn't seem to pr=
ovide

actual modeling recommendations.=C2=A0 Aren't there details beyond how =
or when

a module transitions to NMDA that should be mentioned?=C2=A0 For instance, =
the

text doesn't say anything about how to best locate config false nodes, =
or

how to handle the case when the value-space for a node's configured and=


operational values differ.=C2=A0 Is the plan then to remove this section
entirely once the NMDA-transition is complete?




Obviously NMDA cannot b=
e used for objects where the configuration value set
and the oper=
state value set differ, such as with the interface admin-status/oper-status=
.
Do you want a sentence added that says to use config false leaf=
s as needed within the
configuration entry? A sentence that says =
operational data is embedded in the
configuration entry?


As I recall, the main reason why we are not progressing the guidelines

draft is because we didn't want the short-term text in an RFC.=C2=A0 Pu=
tting

essentially the same text into another RFC seems inconsistent.=C2=A0 But,
if this is what people want, I suppose it's better to churn this docume=
nt

than to introduce a distinct "guidelines" RFC...

=


=C2=A0
=C2=A0

K.=C2=A0 // contributor





Andy
=C2=A0

--



My preference is to have the guidelines say what people should do,

namely design NMDA models. I would prefer to keep any transition

aspects out of the guidelines. If people want to include transition

aspects, it should be in the appendix (i.e., easy to remove / ignore

later on).



I understand that there is a timing issue. The question is what you

mean with "NMDA solution makes it to publication (request)". If y=
ou

mean the core NMDA document, this is pretty much in reach and keeping

this guidelines document on hold until then may be an option. If you

mean the complete solution set, including model updates and moving the

protocol extensions in NETCONF to publication request, then this may

take a bit more time.



/js



On Tue, Aug 22, 2017 at 04:32:14PM -0400, Lou Berger wrote:

> Kent/WG,

>

>=C2=A0 =C2=A0 =C2=A0This seems a bit terse to me and not provide needed=
 guidance during

> the current transition period.=C2=A0 I understood=C2=A0 the discussion=
 ended up

> with the options being to either (1) provide the guidance as a

> standalone document, e.g., (a)-(s) in draft-dsdt-nmda-guidelines, with=
 a

> pointer to it from 6087bis or (2) just move those sections to 6087 bis=
.

> Either way, we'll need a new bis once the full NMDA solution makes=
 it to

> publication (request).

>

> I thought the plan was to do (s).=C2=A0 If so, we need the full text.<=
br>
> Looking at the current repo

> (https://github.=
com/netmod-wg/datastore-dt/blob/master/guidelines/guidelines.txt<=
/a>)

> it would be:

>

>=C2=A0 =C2=A0 =C2=A04.23 Operational Data

>

>=C2=A0 =C2=A0 =C2=A0The following guidelines are meant to help modelers=
 develop

>=C2=A0 =C2=A0 =C2=A0YANG models that will maximize the utility of the m=
odel with

>=C2=A0 =C2=A0 =C2=A0both current implementations and NMDA-capable imple=
mentations

>=C2=A0 =C2=A0 =C2=A0[draft-ietf-netmod-revised-datastores].

>

>=C2=A0 =C2=A0 =C2=A0(a) New models and models that are not concerned wi=
th the

>=C2=A0 =C2=A0 =C2=A0operational state of configuration information SHOU=
LD

>=C2=A0 =C2=A0 =C2=A0immediately be structured to be NMDA-compatible.
>

>=C2=A0 =C2=A0 =C2=A0(b) Models that require immediate support for "=
;in use" and

>=C2=A0 =C2=A0 =C2=A0"system created" information SHOULD be st=
ructured for NMDA.=C2=A0 A

>=C2=A0 =C2=A0 =C2=A0non-NMDA version of these models SHOULD exist, eith=
er an

>=C2=A0 =C2=A0 =C2=A0existing model or a model created either by hand or=
 with

>=C2=A0 =C2=A0 =C2=A0suitable tools that mirror the current modeling str=
ategies.

>=C2=A0 =C2=A0 =C2=A0Both the NMDA and the non-NMDA modules SHOULD be pu=
blished in

>=C2=A0 =C2=A0 =C2=A0the same document, with NMDA modules in the documen=
t main body

>=C2=A0 =C2=A0 =C2=A0and the non-NMDA modules in a non-normative appendi=
x.=C2=A0 The use

>=C2=A0 =C2=A0 =C2=A0of the non-NMDA model will allow temporary bridging=
 of the

>=C2=A0 =C2=A0 =C2=A0time period until NMDA implementations are availabl=
e.

>

>=C2=A0 =C2=A0 =C2=A0(c) For published models, the model should be repub=
lished with

>=C2=A0 =C2=A0 =C2=A0an NMDA-compatible structure, deprecating non-NMDA =
constructs.

>=C2=A0 =C2=A0 =C2=A0For example, the "ietf-interfaces" model =
in ^RFC7223^ will be

>=C2=A0 =C2=A0 =C2=A0restructured as an NMDA-compatible model.=C2=A0 The=


>=C2=A0 =C2=A0 =C2=A0"/interfaces-state" hierarchy will be mar=
ked "status

>=C2=A0 =C2=A0 =C2=A0deprecated".=C2=A0 Models that mark their &quo=
t;/foo-state" hierarchy

>=C2=A0 =C2=A0 =C2=A0with "status deprecated" will allow NMDA-=
capable

>=C2=A0 =C2=A0 =C2=A0implementations to avoid the cost of duplicating th=
e state

>=C2=A0 =C2=A0 =C2=A0nodes, while enabling non-NMDA-capable implementati=
ons to

>=C2=A0 =C2=A0 =C2=A0utilize them for access to the operational values.<=
br>
>

>=C2=A0 =C2=A0 =C2=A0(d) For models that augment models which have not b=
een

>=C2=A0 =C2=A0 =C2=A0structured with the NMDA, the modeler will have to =
consider

>=C2=A0 =C2=A0 =C2=A0the structure of the base model and the guidelines =
listed

>=C2=A0 =C2=A0 =C2=A0above.=C2=A0 Where possible, such models should mov=
e to new

>=C2=A0 =C2=A0 =C2=A0revisions of the base model that are NMDA-compatibl=
e.=C2=A0 When

>=C2=A0 =C2=A0 =C2=A0that is not possible, augmenting "state" =
containers SHOULD be

>=C2=A0 =C2=A0 =C2=A0avoided, with the expectation that the base model w=
ill be

>=C2=A0 =C2=A0 =C2=A0re-released with the state containers marked as dep=
recated.

>=C2=A0 =C2=A0 =C2=A0It is RECOMMENDED to augment only the "/foo&qu=
ot; hierarchy of the

>=C2=A0 =C2=A0 =C2=A0base model.=C2=A0 Where this recommendation cannot =
be followed,

>=C2=A0 =C2=A0 =C2=A0then any new "state" elements SHOULD be i=
ncluded in their own

>=C2=A0 =C2=A0 =C2=A0module.

>

>=C2=A0 =C2=A0 =C2=A0To create the temporary non-NMDA model from an NMDA=
 model, the

>=C2=A0 =C2=A0 =C2=A0following steps can be taken:

>

>=C2=A0 =C2=A0 =C2=A0- Rename the module name by postpending "-stat=
e" to the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0original module's name

>=C2=A0 =C2=A0 =C2=A0- Change the namespace by postpending "-state&=
quot; to the original

>=C2=A0 =C2=A0 =C2=A0 =C2=A0namespace value

>=C2=A0 =C2=A0 =C2=A0- Change the prefix by postpending "-s" t=
o the original prefix

>=C2=A0 =C2=A0 =C2=A0 =C2=A0value

>=C2=A0 =C2=A0 =C2=A0- Set all top-level nodes to have a "config&qu=
ot; statement of

>=C2=A0 =C2=A0 =C2=A0 =C2=A0value "false"

>=C2=A0 =C2=A0 =C2=A0- add an import to the original module (e.g., for t=
ypedef

>=C2=A0 =C2=A0 =C2=A0 =C2=A0definitions)

>=C2=A0 =C2=A0 =C2=A0- modify any imports, used for leafrefs or identity=
refs, to

>=C2=A0 =C2=A0 =C2=A0 =C2=A0import the -state version of the module

>=C2=A0 =C2=A0 =C2=A0- remove any 'typedef' or 'identity'=
; definitions

>=C2=A0 =C2=A0 =C2=A0- prefix any uses of the typedefs and identities ac=
cordingly

>=C2=A0 =C2=A0 =C2=A0- update leafref and augment paths to use the new &=
quot;-s" prefix

>

> For me (with any/all hats) the key downside is that we'll need to=
=C2=A0 rev

> this text (again) in the not too distant future, but that we don't=
 have

> an alternative as LC on the full solution is still a bit away.

>

> What do people think?

>

> Lou

>

>

> On 8/22/2017 3:53 PM, Kent Watsen wrote:

> > Hi,

> >

> > During the meeting in Chicago, the NMDA authors took an action to=


> > propose some text for S4.23.=C2=A0 After a little review, the fol=
lowing

> > emerged.=C2=A0 Yes, it's short, but was anything left anythin=
g out?

> >

> >

> > =3D=3D=3D=3D=3DSTART=3D=3D=3D=3D=3D

> >

> > 4.23 Operational Data

> >

> > Operational data includes both config "false" nodes as =
well as,

> > on servers supporting <operational> [draft-ietf-netmod-revi=
sed-datastores],

> > the applied value of config "true" nodes.

> >

> > YANG modules SHOULD be designed assuming they will be used on

> > servers supporting <operational>.=C2=A0 With this in mind, =
YANG

> > modules SHOULD define config "false" wherever they make=
 sense

> > to the data model.=C2=A0 Config "false" nodes SHOULD NO=
T be defined

> > to provide the operational value for configuration nodes,

> > except when the value space of a configured and operational

> > values may differ, in which case a distinct config "false&qu=
ot;

> > node SHOULD be defined to hold the operational value for the

> > configured node.

> >

> > =3D=3D=3D=3D=3DSTOP=3D=3D=3D=3D=3D

> >

> >

> > One question that came up is if "operational data" is a=
 well-defined

> > term.=C2=A0 This string appears 10 times in rfc6087bis.=C2=A0 Mos=
t interestingly,

> > appendix Section A.8. (v05 to v06) includes this line item:

> >

> >=C2=A0 =C2=A0 =C2=A0Changed term "operational state" to =
"operational data"

> >

> > So it seems to be deliberate...

> >

> >

> > Kent=C2=A0 // contributor

> >

> >

> >

> > _______________________________________________

> > netmod mailing list

> > netmod@ietf.org

> > https://www.ietf.org/mailman/listinfo/net=
mod

> >

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

> https://www.ietf.org/mailman/listinfo/netmod



--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>





_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod




--001a114b311688f8ae055798034e--


From nobody Fri Aug 25 12:11:12 2017
Return-Path: 
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 E48F7132649 for ; Fri, 25 Aug 2017 12:11:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.799
X-Spam-Level: 
X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 x9CquXambDVZ for ; Fri, 25 Aug 2017 12:11:09 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0129.outbound.protection.outlook.com [104.47.36.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6875C126E64 for ; Fri, 25 Aug 2017 12:11:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jo6y8WtWGgQltzEMS7/WUMt1IkIMxeNvnxxB7YSBaSQ=; b=UV7Wca8gdF6/2/d97PBkQwXfgoSUgtKXL5NC/Tg8PccALWGMdejt/XkZlF0WcI4zKy5G4+6REA6k1yDebRSSAEZtpcBgoy4qtn/PJ2jtLZ9yqZNexXa96lveaixsVRp1f/2sp5D2+KptxdYX5uuIfIBugMxJBmWok6iQow29l2M=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1362.namprd05.prod.outlook.com (10.160.183.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Fri, 25 Aug 2017 19:11:07 +0000
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.20.0013.005; Fri, 25 Aug 2017 19:11:07 +0000
From: Kent Watsen 
To: Andy Bierman 
CC: Juergen Schoenwaelder , Lou Berger , "netmod@ietf.org" 
Thread-Topic: [netmod] rfc6087bis S4.23 replacement text
Thread-Index: AQHTG4BdACYCFz8ZdEeedIP50UiUz6KQ1HkAgACjbICAA6UgAIAASekA///K0YA=
Date: Fri, 25 Aug 2017 19:11:07 +0000
Message-ID: 
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1362; 6:VeLgYA+9y0RFGmPte0NnX0De0denyeisNLhcHTpKTL2kPbZlz1h9ScDzeBMd+cPVvKm4upPyDroiSRyhdrLTPSheq7VqupQaMmlxsewF37pJf2k9upMj1xwdPBKOh6Gh4NKRN+kuaFZ9IFGakElfBVRvzFgB+5KjFjla2Jzaavr2Gvu0GBrkvfGL9BRJZ2fUarHu4oWUbJzgb3xAADXR797DD4jBfrQKjz8xzCdyk2JgL4XIlnw7uu2IieVsl+8BKt3kLgGFULHaGoX6n7/ni+6NO7kFLgQMV+4tyusbjUv/ptAY/iohk009Tm59tES0jOgcKM5YKmoNlTB7eLa0vg==; 5:l7LLXse4blBrKrs/SACotE/Vv0FaIMdIvXHEep9o0HtozFpcvv70nnB1srllNmWmyEnlRadKVlDt2XuzeJMh+0k7Xx6B8+tNRXmvO/RKJwwq64+GFSfRB875K/at9dmDDnZMAHfSgR6r22gaoUy87w==; 24:nLPZCJhcFR2qyklhO8PMXM4tAqkGV+lhupnKIyWD3D2GTi37KGrPPbQG3/YrfU2GRUE6xCb38/SZ1yWh/OP6cV9xbEsQLFSGQkco4opCWXc=; 7:ACgvNX/GhZD6CwAPYri0UQx6PvECbqi0n6qTPq5RW14I5AqgSHaacMFc6WkOlUoI8oaC4yNvFtp+ldNJsA2A3CuhsF1iEM2pnYgt4NC0/H8aJ8F1fN+yeVGi3qEdeKolT+uUXzPTfq0SUDks4teKXz0Gxta47jo6o1FLcOHN2RrGZBxN9asZvLp+wAZWnDcN69qLPozbpd5kKAbAs2UsF2CXn8VD90tDdwkFfykiFwY=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 488c88c4-94c1-4cce-650b-08d4ebed0a36
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(300000502095)(300135100095)(22001)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1362; 
x-ms-traffictypediagnostic: BN3PR0501MB1362:
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1362; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1362; 
x-forefront-prvs: 041032FF37
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(199003)(24454002)(377454003)(189002)(4326008)(36756003)(6246003)(25786009)(86362001)(229853002)(110136004)(3280700002)(7736002)(97736004)(5660300001)(478600001)(101416001)(6916009)(102836003)(2906002)(6116002)(2950100002)(3846002)(99286003)(66066001)(76176999)(50986999)(54356999)(6506006)(53546010)(53936002)(93886005)(189998001)(54906002)(33656002)(54896002)(6306002)(6512007)(2900100001)(77096006)(6486002)(236005)(68736007)(6436002)(83506001)(3660700001)(8676002)(81156014)(83716003)(81166006)(8936002)(14454004)(4001350100001)(105586002)(106356001)(82746002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1362; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AD1D598E92EF49F2AE2A048EE9746E12junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2017 19:11:07.6102 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1362
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Aug 2017 19:11:12 -0000

--_000_AD1D598E92EF49F2AE2A048EE9746E12junipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQoNCk9uIDgvMjUvMTcsIDI6MjEgUE0sICJBbmR5IEJpZXJtYW4iIDxhbmR5QHl1bWF3b3Jrcy5j
b208bWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbT4+IHdyb3RlOg0KDQo+IE9idmlvdXNseSBOTURB
IGNhbm5vdCBiZSB1c2VkIGZvciBvYmplY3RzIHdoZXJlIHRoZSBjb25maWd1cmF0aW9uIHZhbHVl
IHNldA0KPiBhbmQgdGhlIG9wZXJzdGF0ZSB2YWx1ZSBzZXQgZGlmZmVyLCBzdWNoIGFzIHdpdGgg
dGhlIGludGVyZmFjZSBhZG1pbi1zdGF0dXMvb3Blci1zdGF0dXMuDQo+IERvIHlvdSB3YW50IGEg
c2VudGVuY2UgYWRkZWQgdGhhdCBzYXlzIHRvIHVzZSBjb25maWcgZmFsc2UgbGVhZnMgYXMgbmVl
ZGVkIHdpdGhpbiB0aGUNCj4gY29uZmlndXJhdGlvbiBlbnRyeT8gQSBzZW50ZW5jZSB0aGF0IHNh
eXMgb3BlcmF0aW9uYWwgZGF0YSBpcyBlbWJlZGRlZCBpbiB0aGUNCj4gY29uZmlndXJhdGlvbiBl
bnRyeT8NCg0KWWVzLCBhbmQgYW55IG90aGVyIGdlbmVyYWwgZ3VpZGVsaW5lcyBhcm91bmQgdXNp
bmcgY29uZmlnIGZhbHNlLiAgIFRoZSB0ZXh0IEkgcG9zdGVkDQp3aGVuIHN0YXJ0aW5nIHRoaXMg
dGhyZWFkIGhhZCBzb21lIG9mIHRoYXQuICBUaGUgb3JpZ2luYWwgUkZDNjA4NyB0ZXh0IG1pZ2h0
IGhhdmUNCnNvbWUgbW9yZS4NCg0KDQo+IDYwODdiaXMgd2FzIHN1cHBvc2VkIHRvIGJlIGEgbWlu
b3IgdXBkYXRlLCBub3QgYSBsaXZpbmcgZHJhZnQgdGhhdCBkb3VibGVzDQo+IGFzIGEgWUFORyB0
dXRvcmlhbCBhbmQgb25nb2luZyBpc3N1ZXMgbGlzdC4NCg0KIDspDQoNCkFzIG11Y2ggYXMgSSBs
aWtlIFJGQ3MsIEkgdGhpbmsgdGhpcyBjb250ZW50IHdvdWxkIGJlIGJldHRlciBzZXJ2ZWQgYnkg
YSBXaWtpLiAgIElmDQp3ZSB3ZXJlIHN0YXJ0aW5nIGZvciBzY3JhdGNoIChubyBSRkM2MDg3KSwg
dGhlbiB0aGF0IG1pZ2h0IG1ha2Ugc2Vuc2UgYnV0LCBnaXZlbg0Kd2hlcmUgd2UgYXJlLCBub3Qg
c28gbXVjaC4gIFNvLCBJIGd1ZXNzIHdlJ3JlIGNvbW1pdHRlZCB0byBmcmVxdWVudCB1cGRhdGVz
IG9uIHRoaXMNCmRvY3VtZW50IHVudGlsIFlBTkcgc2V0dGxlcyBkb3duLg0KDQoNCktlbnQgLy8g
Y29udHJpYnV0b3INCg0KDQo=

--_000_AD1D598E92EF49F2AE2A048EE9746E12junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxl
MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJy
aTsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJY29sb3I6d2luZG93dGV4dDsN
Cgl0ZXh0LXRyYW5zZm9ybTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7DQoJdmVy
dGljYWwtYWxpZ246YmFzZWxpbmU7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw
b3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu
ZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y
dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y
ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8
Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw
bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJy
aSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5PbiA4LzI1LzE3LCAyOjIxIFBNLCAmcXVvdDtBbmR5IEJpZXJtYW4mcXVvdDsg
Jmx0OzxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iPmFuZHlAeXVtYXdvcmtzLmNv
bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgT2J2aW91c2x5
IE5NREEgY2Fubm90IGJlIHVzZWQgZm9yIG9iamVjdHMgd2hlcmUgdGhlIGNvbmZpZ3VyYXRpb24g
dmFsdWUgc2V0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mZ3Q7IGFuZCB0aGUgb3BlcnN0YXRlIHZhbHVlIHNldCBkaWZmZXIsIHN1Y2ggYXMgd2l0
aCB0aGUgaW50ZXJmYWNlIGFkbWluLXN0YXR1cy9vcGVyLXN0YXR1cy48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgRG8geW91IHdhbnQgYSBz
ZW50ZW5jZSBhZGRlZCB0aGF0IHNheXMgdG8gdXNlIGNvbmZpZyBmYWxzZSBsZWFmcyBhcyBuZWVk
ZWQgd2l0aGluIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+Jmd0OyBjb25maWd1cmF0aW9uIGVudHJ5PyBBIHNlbnRlbmNlIHRoYXQgc2F5cyBv
cGVyYXRpb25hbCBkYXRhIGlzIGVtYmVkZGVkIGluIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBjb25maWd1cmF0aW9uIGVudHJ5Pzxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIGFuZCBhbnkgb3RoZXIg
Z2VuZXJhbCBndWlkZWxpbmVzIGFyb3VuZCB1c2luZyBjb25maWcgZmFsc2UuJm5ic3A7Jm5ic3A7
IFRoZSB0ZXh0IEkgcG9zdGVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53
aGVuIHN0YXJ0aW5nIHRoaXMgdGhyZWFkIGhhZCBzb21lIG9mIHRoYXQuJm5ic3A7IFRoZSBvcmln
aW5hbCBSRkM2MDg3IHRleHQgbWlnaHQgaGF2ZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+c29tZSBtb3JlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZndDsgNjA4N2JpcyB3YXMgc3VwcG9zZWQgdG8gYmUgYSBtaW5vciB1cGRhdGUsIG5vdCBh
IGxpdmluZyBkcmFmdCB0aGF0IGRvdWJsZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgYXMgYSBZQU5HIHR1dG9yaWFsIGFuZCBvbmdvaW5n
IGlzc3VlcyBsaXN0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj4mbmJzcDs7KSA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkFzIG11Y2ggYXMgSSBsaWtlIFJGQ3MsIEkgdGhpbmsgdGhpcyBjb250ZW50IHdvdWxkIGJl
IGJldHRlciBzZXJ2ZWQgYnkgYSBXaWtpLiZuYnNwOyZuYnNwOyBJZjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+d2Ugd2VyZSBzdGFydGluZyBmb3Igc2NyYXRjaCAobm8gUkZD
NjA4NyksIHRoZW4gdGhhdCBtaWdodCBtYWtlIHNlbnNlIGJ1dCwgZ2l2ZW48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndoZXJlIHdlIGFyZSwgbm90IHNvIG11Y2guJm5ic3A7
IFNvLCBJIGd1ZXNzIHdlJ3JlIGNvbW1pdHRlZCB0byBmcmVxdWVudCB1cGRhdGVzIG9uIHRoaXM8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRvY3VtZW50IHVudGlsIFlBTkcg
c2V0dGxlcyBkb3duLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPktlbnQgLy8gY29udHJpYnV0b3I8bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_AD1D598E92EF49F2AE2A048EE9746E12junipernet_--


From nobody Fri Aug 25 12:17:20 2017
Return-Path: 
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 A0628132C21 for ; Fri, 25 Aug 2017 12:17:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 WhKzzlIVEFlM for ; Fri, 25 Aug 2017 12:17:11 -0700 (PDT)
Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53628126E64 for ; Fri, 25 Aug 2017 12:17:11 -0700 (PDT)
Received: by mail-wr0-x233.google.com with SMTP id z91so2048974wrc.1 for ; Fri, 25 Aug 2017 12:17:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=a+6B6bgTw0Av4uJWBmvulcA2v9MXFI9h8Wdrs2S4fOQ=; b=lA9P1M6x6+9hzedY76fQmwzOwKRPE6kHAlnmpoflPooK1dv8wI2aBoXZUoUmuwnnL6 oNTY8YwUi+I/S7VD7BYLwHU8HL6dzHPLaBnMgzVTKMUk5k0thtHdXaIN+SRwXFdl+zJH k2AlOS1xi/XofL3u0lKvNIwhxiT5YomKB0MrwvxlmcV5ieiLq8OiCBdtujZsDy+O38TE /M7JPs9YoFULCPpnQL3ZZ0qIXG05W0GM4wyYI58NPTeIZu7A0R10n6Fqb/GrpjO/5zKk bvoLmuL89Mk3KBZURpA15aZlKiTbJKQRPuyeiQrz3jNLBI6PI0Nf8GvavdRkWfBcB2QL t7Ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a+6B6bgTw0Av4uJWBmvulcA2v9MXFI9h8Wdrs2S4fOQ=; b=Hs30lYq1zBCQRyfjx2RzvLAZ7fMuZLpljAcy554jr5r3WskvKhZ5JgZ5F2/dikdFEA f7vuOVLxTUYKW7ctuTYhlMb7o/JkReOroHkkb0fSv/kAok+SALZDzHUDL+PToAcSHoj4 CyuxThEQ/fObLW1Hkqh617uYqrXFfOuo+zOK/uEy1tmwXHU3Uf9+MZsYUl3WTzpzZbF2 hE1svM5qPoLLnWlLj/En6iQA6zF/FBA86M9ULSBtzNQ0ARZM35IB/SGWB2fK9jcj5Bzh P2gjNXrn6Qmz6tJ/L6/kWh4InTtmbd+9uzYJPQJjwUEzP6OFZhEROzqMpkVYVM1fq6V0 bnUA==
X-Gm-Message-State: AHYfb5iBw9rRZTaLRAHOLmTgPzc0Sy35ZEhOqc2MdNusrl6WMzP2ANiA 458lwo43rfwB6JFThKUWscahTCZubUEK
X-Received: by 10.223.174.73 with SMTP id u9mr3079094wrd.228.1503688629750; Fri, 25 Aug 2017 12:17:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.221 with HTTP; Fri, 25 Aug 2017 12:17:09 -0700 (PDT)
In-Reply-To: 
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local> 
From: Andy Bierman 
Date: Fri, 25 Aug 2017 12:17:09 -0700
Message-ID: 
To: Kent Watsen 
Cc: Juergen Schoenwaelder , Lou Berger , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c1cd31aa135bb055798ca33"
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Aug 2017 19:17:19 -0000

--94eb2c1cd31aa135bb055798ca33
Content-Type: text/plain; charset="UTF-8"

Hi,

I think there should be text about admin-state/oper-state objects.
It is fairly common that the oper-state enums will differ from the
admin-state enums.
The only linkage between these objects is description-stmt text.

Not only does NMDA ignore this linkage problem, it acutally makes it worse.
Look at rfc7223bis for an example.

How does the client know that the get-data result for the
/interfaces/interface/admin-status
leaf in the operational datastore is worthless, and that
/interfaces/interface/oper-status
should be used instead?  What is an NMDA server supposed to return for the
operational
value of admin-status?

Should 6087bis mention that NMDA allows the YANG library to be different on
each datastore?
And that the same module can be different revisions, features, and
deviations on each datastore?
Should the advice to client developers be "Have fun with that."


Andy


On Fri, Aug 25, 2017 at 10:56 AM, Kent Watsen  wrote:

>
> I have the same preference.  The suggested text doesn't seem to provide
> actual modeling recommendations.  Aren't there details beyond how or when
> a module transitions to NMDA that should be mentioned?  For instance, the
> text doesn't say anything about how to best locate config false nodes, or
> how to handle the case when the value-space for a node's configured and
> operational values differ.  Is the plan then to remove this section
> entirely once the NMDA-transition is complete?
>
> As I recall, the main reason why we are not progressing the guidelines
> draft is because we didn't want the short-term text in an RFC.  Putting
> essentially the same text into another RFC seems inconsistent.  But,
> if this is what people want, I suppose it's better to churn this document
> than to introduce a distinct "guidelines" RFC...
>
> K.  // contributor
>
>
> --
>
> My preference is to have the guidelines say what people should do,
> namely design NMDA models. I would prefer to keep any transition
> aspects out of the guidelines. If people want to include transition
> aspects, it should be in the appendix (i.e., easy to remove / ignore
> later on).
>
> I understand that there is a timing issue. The question is what you
> mean with "NMDA solution makes it to publication (request)". If you
> mean the core NMDA document, this is pretty much in reach and keeping
> this guidelines document on hold until then may be an option. If you
> mean the complete solution set, including model updates and moving the
> protocol extensions in NETCONF to publication request, then this may
> take a bit more time.
>
> /js
>
> On Tue, Aug 22, 2017 at 04:32:14PM -0400, Lou Berger wrote:
> > Kent/WG,
> >
> >     This seems a bit terse to me and not provide needed guidance during
> > the current transition period.  I understood  the discussion ended up
> > with the options being to either (1) provide the guidance as a
> > standalone document, e.g., (a)-(s) in draft-dsdt-nmda-guidelines, with a
> > pointer to it from 6087bis or (2) just move those sections to 6087 bis.
> > Either way, we'll need a new bis once the full NMDA solution makes it to
> > publication (request).
> >
> > I thought the plan was to do (s).  If so, we need the full text.
> > Looking at the current repo
> > (https://github.com/netmod-wg/datastore-dt/blob/master/
> guidelines/guidelines.txt)
> > it would be:
> >
> >     4.23 Operational Data
> >
> >     The following guidelines are meant to help modelers develop
> >     YANG models that will maximize the utility of the model with
> >     both current implementations and NMDA-capable implementations
> >     [draft-ietf-netmod-revised-datastores].
> >
> >     (a) New models and models that are not concerned with the
> >     operational state of configuration information SHOULD
> >     immediately be structured to be NMDA-compatible.
> >
> >     (b) Models that require immediate support for "in use" and
> >     "system created" information SHOULD be structured for NMDA.  A
> >     non-NMDA version of these models SHOULD exist, either an
> >     existing model or a model created either by hand or with
> >     suitable tools that mirror the current modeling strategies.
> >     Both the NMDA and the non-NMDA modules SHOULD be published in
> >     the same document, with NMDA modules in the document main body
> >     and the non-NMDA modules in a non-normative appendix.  The use
> >     of the non-NMDA model will allow temporary bridging of the
> >     time period until NMDA implementations are available.
> >
> >     (c) For published models, the model should be republished with
> >     an NMDA-compatible structure, deprecating non-NMDA constructs.
> >     For example, the "ietf-interfaces" model in ^RFC7223^ will be
> >     restructured as an NMDA-compatible model.  The
> >     "/interfaces-state" hierarchy will be marked "status
> >     deprecated".  Models that mark their "/foo-state" hierarchy
> >     with "status deprecated" will allow NMDA-capable
> >     implementations to avoid the cost of duplicating the state
> >     nodes, while enabling non-NMDA-capable implementations to
> >     utilize them for access to the operational values.
> >
> >     (d) For models that augment models which have not been
> >     structured with the NMDA, the modeler will have to consider
> >     the structure of the base model and the guidelines listed
> >     above.  Where possible, such models should move to new
> >     revisions of the base model that are NMDA-compatible.  When
> >     that is not possible, augmenting "state" containers SHOULD be
> >     avoided, with the expectation that the base model will be
> >     re-released with the state containers marked as deprecated.
> >     It is RECOMMENDED to augment only the "/foo" hierarchy of the
> >     base model.  Where this recommendation cannot be followed,
> >     then any new "state" elements SHOULD be included in their own
> >     module.
> >
> >     To create the temporary non-NMDA model from an NMDA model, the
> >     following steps can be taken:
> >
> >     - Rename the module name by postpending "-state" to the
> >       original module's name
> >     - Change the namespace by postpending "-state" to the original
> >       namespace value
> >     - Change the prefix by postpending "-s" to the original prefix
> >       value
> >     - Set all top-level nodes to have a "config" statement of
> >       value "false"
> >     - add an import to the original module (e.g., for typedef
> >       definitions)
> >     - modify any imports, used for leafrefs or identityrefs, to
> >       import the -state version of the module
> >     - remove any 'typedef' or 'identity' definitions
> >     - prefix any uses of the typedefs and identities accordingly
> >     - update leafref and augment paths to use the new "-s" prefix
> >
> > For me (with any/all hats) the key downside is that we'll need to  rev
> > this text (again) in the not too distant future, but that we don't have
> > an alternative as LC on the full solution is still a bit away.
> >
> > What do people think?
> >
> > Lou
> >
> >
> > On 8/22/2017 3:53 PM, Kent Watsen wrote:
> > > Hi,
> > >
> > > During the meeting in Chicago, the NMDA authors took an action to
> > > propose some text for S4.23.  After a little review, the following
> > > emerged.  Yes, it's short, but was anything left anything out?
> > >
> > >
> > > =====START=====
> > >
> > > 4.23 Operational Data
> > >
> > > Operational data includes both config "false" nodes as well as,
> > > on servers supporting  [draft-ietf-netmod-revised-
> datastores],
> > > the applied value of config "true" nodes.
> > >
> > > YANG modules SHOULD be designed assuming they will be used on
> > > servers supporting .  With this in mind, YANG
> > > modules SHOULD define config "false" wherever they make sense
> > > to the data model.  Config "false" nodes SHOULD NOT be defined
> > > to provide the operational value for configuration nodes,
> > > except when the value space of a configured and operational
> > > values may differ, in which case a distinct config "false"
> > > node SHOULD be defined to hold the operational value for the
> > > configured node.
> > >
> > > =====STOP=====
> > >
> > >
> > > One question that came up is if "operational data" is a well-defined
> > > term.  This string appears 10 times in rfc6087bis.  Most interestingly,
> > > appendix Section A.8. (v05 to v06) includes this line item:
> > >
> > >     Changed term "operational state" to "operational data"
> > >
> > > So it seems to be deliberate...
> > >
> > >
> > > Kent  // contributor
> > >
> > >
> > >
> > > _______________________________________________
> > > 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
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--94eb2c1cd31aa135bb055798ca33
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

I think there should be text about =
admin-state/oper-state objects.
It is fairly common that the oper=
-state enums will differ from the admin-state enums.
The only lin=
kage between these objects is description-stmt text.

Not only does NMDA ignore this linkage problem, it acutally makes it wor=
se.
Look at rfc7223bis for an example.

H=
ow does the client know that the get-data result for the /interfaces/interf=
ace/admin-status
leaf in the operational datastore is worthless, =
and that /interfaces/interface/oper-status
should be used instead=
?=C2=A0 What is an NMDA server supposed to return for the operational
=

value of admin-status?

Should 6087bis mention=
 that NMDA allows the YANG library to be different on each datastore?
=

And that the same module can be different revisions, features, and dev=
iations on each datastore?
Should the advice to client developers=
 be "Have fun with that."


Andy


On Fri, Aug 25, 2017 at 10:56 AM, Kent Watsen <kwatsen@jun=
iper.net> wrote:


I have the same preference.=C2=A0 The suggested text doesn't seem to pr=
ovide

actual modeling recommendations.=C2=A0 Aren't there details beyond how =
or when

a module transitions to NMDA that should be mentioned?=C2=A0 For instance, =
the

text doesn't say anything about how to best locate config false nodes, =
or

how to handle the case when the value-space for a node's configured and=


operational values differ.=C2=A0 Is the plan then to remove this section
entirely once the NMDA-transition is complete?



As I recall, the main reason why we are not progressing the guidelines

draft is because we didn't want the short-term text in an RFC.=C2=A0 Pu=
tting

essentially the same text into another RFC seems inconsistent.=C2=A0 But,
if this is what people want, I suppose it's better to churn this docume=
nt

than to introduce a distinct "guidelines" RFC...



K.=C2=A0 // contributor





--



My preference is to have the guidelines say what people should do,

namely design NMDA models. I would prefer to keep any transition

aspects out of the guidelines. If people want to include transition

aspects, it should be in the appendix (i.e., easy to remove / ignore

later on).



I understand that there is a timing issue. The question is what you

mean with "NMDA solution makes it to publication (request)". If y=
ou

mean the core NMDA document, this is pretty much in reach and keeping

this guidelines document on hold until then may be an option. If you

mean the complete solution set, including model updates and moving the

protocol extensions in NETCONF to publication request, then this may

take a bit more time.



/js



On Tue, Aug 22, 2017 at 04:32:14PM -0400, Lou Berger wrote:

> Kent/WG,

>

>=C2=A0 =C2=A0 =C2=A0This seems a bit terse to me and not provide needed=
 guidance during

> the current transition period.=C2=A0 I understood=C2=A0 the discussion=
 ended up

> with the options being to either (1) provide the guidance as a

> standalone document, e.g., (a)-(s) in draft-dsdt-nmda-guidelines, with=
 a

> pointer to it from 6087bis or (2) just move those sections to 6087 bis=
.

> Either way, we'll need a new bis once the full NMDA solution makes=
 it to

> publication (request).

>

> I thought the plan was to do (s).=C2=A0 If so, we need the full text.<=
br>
> Looking at the current repo

> (https://github.=
com/netmod-wg/datastore-dt/blob/master/guidelines/guidelines.txt<=
/a>)

> it would be:

>

>=C2=A0 =C2=A0 =C2=A04.23 Operational Data

>

>=C2=A0 =C2=A0 =C2=A0The following guidelines are meant to help modelers=
 develop

>=C2=A0 =C2=A0 =C2=A0YANG models that will maximize the utility of the m=
odel with

>=C2=A0 =C2=A0 =C2=A0both current implementations and NMDA-capable imple=
mentations

>=C2=A0 =C2=A0 =C2=A0[draft-ietf-netmod-revised-datastores].

>

>=C2=A0 =C2=A0 =C2=A0(a) New models and models that are not concerned wi=
th the

>=C2=A0 =C2=A0 =C2=A0operational state of configuration information SHOU=
LD

>=C2=A0 =C2=A0 =C2=A0immediately be structured to be NMDA-compatible.
>

>=C2=A0 =C2=A0 =C2=A0(b) Models that require immediate support for "=
;in use" and

>=C2=A0 =C2=A0 =C2=A0"system created" information SHOULD be st=
ructured for NMDA.=C2=A0 A

>=C2=A0 =C2=A0 =C2=A0non-NMDA version of these models SHOULD exist, eith=
er an

>=C2=A0 =C2=A0 =C2=A0existing model or a model created either by hand or=
 with

>=C2=A0 =C2=A0 =C2=A0suitable tools that mirror the current modeling str=
ategies.

>=C2=A0 =C2=A0 =C2=A0Both the NMDA and the non-NMDA modules SHOULD be pu=
blished in

>=C2=A0 =C2=A0 =C2=A0the same document, with NMDA modules in the documen=
t main body

>=C2=A0 =C2=A0 =C2=A0and the non-NMDA modules in a non-normative appendi=
x.=C2=A0 The use

>=C2=A0 =C2=A0 =C2=A0of the non-NMDA model will allow temporary bridging=
 of the

>=C2=A0 =C2=A0 =C2=A0time period until NMDA implementations are availabl=
e.

>

>=C2=A0 =C2=A0 =C2=A0(c) For published models, the model should be repub=
lished with

>=C2=A0 =C2=A0 =C2=A0an NMDA-compatible structure, deprecating non-NMDA =
constructs.

>=C2=A0 =C2=A0 =C2=A0For example, the "ietf-interfaces" model =
in ^RFC7223^ will be

>=C2=A0 =C2=A0 =C2=A0restructured as an NMDA-compatible model.=C2=A0 The=


>=C2=A0 =C2=A0 =C2=A0"/interfaces-state" hierarchy will be mar=
ked "status

>=C2=A0 =C2=A0 =C2=A0deprecated".=C2=A0 Models that mark their &quo=
t;/foo-state" hierarchy

>=C2=A0 =C2=A0 =C2=A0with "status deprecated" will allow NMDA-=
capable

>=C2=A0 =C2=A0 =C2=A0implementations to avoid the cost of duplicating th=
e state

>=C2=A0 =C2=A0 =C2=A0nodes, while enabling non-NMDA-capable implementati=
ons to

>=C2=A0 =C2=A0 =C2=A0utilize them for access to the operational values.<=
br>
>

>=C2=A0 =C2=A0 =C2=A0(d) For models that augment models which have not b=
een

>=C2=A0 =C2=A0 =C2=A0structured with the NMDA, the modeler will have to =
consider

>=C2=A0 =C2=A0 =C2=A0the structure of the base model and the guidelines =
listed

>=C2=A0 =C2=A0 =C2=A0above.=C2=A0 Where possible, such models should mov=
e to new

>=C2=A0 =C2=A0 =C2=A0revisions of the base model that are NMDA-compatibl=
e.=C2=A0 When

>=C2=A0 =C2=A0 =C2=A0that is not possible, augmenting "state" =
containers SHOULD be

>=C2=A0 =C2=A0 =C2=A0avoided, with the expectation that the base model w=
ill be

>=C2=A0 =C2=A0 =C2=A0re-released with the state containers marked as dep=
recated.

>=C2=A0 =C2=A0 =C2=A0It is RECOMMENDED to augment only the "/foo&qu=
ot; hierarchy of the

>=C2=A0 =C2=A0 =C2=A0base model.=C2=A0 Where this recommendation cannot =
be followed,

>=C2=A0 =C2=A0 =C2=A0then any new "state" elements SHOULD be i=
ncluded in their own

>=C2=A0 =C2=A0 =C2=A0module.

>

>=C2=A0 =C2=A0 =C2=A0To create the temporary non-NMDA model from an NMDA=
 model, the

>=C2=A0 =C2=A0 =C2=A0following steps can be taken:

>

>=C2=A0 =C2=A0 =C2=A0- Rename the module name by postpending "-stat=
e" to the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0original module's name

>=C2=A0 =C2=A0 =C2=A0- Change the namespace by postpending "-state&=
quot; to the original

>=C2=A0 =C2=A0 =C2=A0 =C2=A0namespace value

>=C2=A0 =C2=A0 =C2=A0- Change the prefix by postpending "-s" t=
o the original prefix

>=C2=A0 =C2=A0 =C2=A0 =C2=A0value

>=C2=A0 =C2=A0 =C2=A0- Set all top-level nodes to have a "config&qu=
ot; statement of

>=C2=A0 =C2=A0 =C2=A0 =C2=A0value "false"

>=C2=A0 =C2=A0 =C2=A0- add an import to the original module (e.g., for t=
ypedef

>=C2=A0 =C2=A0 =C2=A0 =C2=A0definitions)

>=C2=A0 =C2=A0 =C2=A0- modify any imports, used for leafrefs or identity=
refs, to

>=C2=A0 =C2=A0 =C2=A0 =C2=A0import the -state version of the module

>=C2=A0 =C2=A0 =C2=A0- remove any 'typedef' or 'identity'=
; definitions

>=C2=A0 =C2=A0 =C2=A0- prefix any uses of the typedefs and identities ac=
cordingly

>=C2=A0 =C2=A0 =C2=A0- update leafref and augment paths to use the new &=
quot;-s" prefix

>

> For me (with any/all hats) the key downside is that we'll need to=
=C2=A0 rev

> this text (again) in the not too distant future, but that we don't=
 have

> an alternative as LC on the full solution is still a bit away.

>

> What do people think?

>

> Lou

>

>

> On 8/22/2017 3:53 PM, Kent Watsen wrote:

> > Hi,

> >

> > During the meeting in Chicago, the NMDA authors took an action to=


> > propose some text for S4.23.=C2=A0 After a little review, the fol=
lowing

> > emerged.=C2=A0 Yes, it's short, but was anything left anythin=
g out?

> >

> >

> > =3D=3D=3D=3D=3DSTART=3D=3D=3D=3D=3D

> >

> > 4.23 Operational Data

> >

> > Operational data includes both config "false" nodes as =
well as,

> > on servers supporting <operational> [draft-ietf-netmod-revi=
sed-datastores],

> > the applied value of config "true" nodes.

> >

> > YANG modules SHOULD be designed assuming they will be used on

> > servers supporting <operational>.=C2=A0 With this in mind, =
YANG

> > modules SHOULD define config "false" wherever they make=
 sense

> > to the data model.=C2=A0 Config "false" nodes SHOULD NO=
T be defined

> > to provide the operational value for configuration nodes,

> > except when the value space of a configured and operational

> > values may differ, in which case a distinct config "false&qu=
ot;

> > node SHOULD be defined to hold the operational value for the

> > configured node.

> >

> > =3D=3D=3D=3D=3DSTOP=3D=3D=3D=3D=3D

> >

> >

> > One question that came up is if "operational data" is a=
 well-defined

> > term.=C2=A0 This string appears 10 times in rfc6087bis.=C2=A0 Mos=
t interestingly,

> > appendix Section A.8. (v05 to v06) includes this line item:

> >

> >=C2=A0 =C2=A0 =C2=A0Changed term "operational state" to =
"operational data"

> >

> > So it seems to be deliberate...

> >

> >

> > Kent=C2=A0 // contributor

> >

> >

> >

> > _______________________________________________

> > netmod mailing list

> > netmod@ietf.org

> > https://www.ietf.org/mailman/listinfo/net=
mod

> >

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

> https://www.ietf.org/mailman/listinfo/netmod



--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>





_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod




--94eb2c1cd31aa135bb055798ca33--


From nobody Fri Aug 25 12:32:04 2017
Return-Path: 
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 4E051132C3E for ; Fri, 25 Aug 2017 12:32:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 AjMLflTn8pHW for ; Fri, 25 Aug 2017 12:32:00 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1E6C132C3C for ; Fri, 25 Aug 2017 12:31:59 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id z132so5360110wmg.1 for ; Fri, 25 Aug 2017 12:31:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uTKW4z+a/e5FGUDJ09mq3x4nUN+v3CsiNdegu4hR55E=; b=K59T5MwaDGCODjzq2DWvP0BPasoliOh8IjRsLY5QASV5DWS2hWwJIR0Hj5Mh4vuAUO rvyNtP9v6mJ3WtyVIa0dGUP6yrO6dYEd3E83YgLMjjFgaiD9za1QYqsGrkPx9ed39cA/ cWiDHdy9iCi3FuMHbMcGh1cC3RmeHNHOPbndE33AmUxoLUuWt0OOaTUzjRp5nSk8wDGW ItV+ptMpiq0z0LQCcSDAylNkndJuXWB1gJBYr6ZGTC226KxqIJyzrmnsfnYGyWgiBKIe cJmNIM4XWULm/e659yQHDA5/XbLcG/RygLGRfXM4YC+6flXYe1mo0VbBSCrZVp4EsHm7 9Ong==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uTKW4z+a/e5FGUDJ09mq3x4nUN+v3CsiNdegu4hR55E=; b=jbSDyGHZi84Jc5jsdP+BxdiLamzfB8L4spRTaQ8OhN5vrNbJk+Dub8xRSNXzbVH+ra rY8ZDbkXA8J9Y8RoFYbbbO0Ri+TsKodjVj+/mPfSJET2Y/vLUmLjxcLAqGVDgnsotH5N 1UXqzlGmZ1UlWoEp4TzN7HNVgiqZCu8M4n0e1SL0m7wumvvZtmj64ggPaSNl2l5fJIcd C4OyMTZ18Xsv5Im5LkbtySokc8Odr8XRn/97BDVfXRCaijMSUo3PtwYWRyVyxgysOQyl 26f0VPfNZb2wwdDYdVBNAJpuajrT+4fnpMbE6iUJHuOdTDh6/WQ2cL/IwnJunwGBo3qB w9Ww==
X-Gm-Message-State: AHYfb5hiSrJuF+P+zSBSYokh8mznuhF0RfW4sPcGKgSHk8beOG0FG4vS gLWyriHF/pYyhvy2gkFS0EsnjejqSKUY
X-Received: by 10.28.103.6 with SMTP id b6mr245401wmc.28.1503689518428; Fri, 25 Aug 2017 12:31:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.221 with HTTP; Fri, 25 Aug 2017 12:31:57 -0700 (PDT)
In-Reply-To: 
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local>   
From: Andy Bierman 
Date: Fri, 25 Aug 2017 12:31:57 -0700
Message-ID: 
To: Kent Watsen 
Cc: Juergen Schoenwaelder , Lou Berger , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114b30d8999df8055798ffc0"
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Aug 2017 19:32:02 -0000

--001a114b30d8999df8055798ffc0
Content-Type: text/plain; charset="UTF-8"

On Fri, Aug 25, 2017 at 12:11 PM, Kent Watsen  wrote:

>
>
>
>
> On 8/25/17, 2:21 PM, "Andy Bierman"  wrote:
>
>
>
> > Obviously NMDA cannot be used for objects where the configuration value
> set
>
> > and the operstate value set differ, such as with the interface
> admin-status/oper-status.
>
> > Do you want a sentence added that says to use config false leafs as
> needed within the
>
> > configuration entry? A sentence that says operational data is embedded
> in the
>
> > configuration entry?
>
>
>
> Yes, and any other general guidelines around using config false.   The
> text I posted
>
> when starting this thread had some of that.  The original RFC6087 text
> might have
>
> some more.
>
>
>

OK -- I will work on adding in text from -12, your text, and Lou's text.


>
> > 6087bis was supposed to be a minor update, not a living draft that
> doubles
>
> > as a YANG tutorial and ongoing issues list.
>
>
>
>  ;)
>
>
>
> As much as I like RFCs, I think this content would be better served by a
> Wiki.   If
>
> we were starting for scratch (no RFC6087), then that might make sense but,
> given
>
> where we are, not so much.  So, I guess we're committed to frequent
> updates on this
>
> document until YANG settles down.
>
>
>

It is better to have as few moving targets (and normative references) as
possible.
YANG modules in an RFC have to conform to a specific version of the YANG
guidelines.


>
>
> Kent // contributor
>
>
>
>
>

Andy

--001a114b30d8999df8055798ffc0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Fri, Aug 25, 2017 at 12:11 PM, Kent Watsen <kwatsen@juniper.net> wrote:













=C2=A0=



=C2=A0=







On 8/25/17, 2:21 PM, "Andy Bierman" <andy@yumaworks.com> wrote:








=C2=A0












> Obviously NMDA cannot be used for objects where=
 the configuration value set






> and the operstate value set differ, such as wit=
h the interface admin-status/oper-status.






> Do you want a sentence added that says to use c=
onfig false leafs as needed within the






> configuration entry? A sentence that says opera=
tional data is embedded in the






> configuration entry?






=C2=A0


Yes, and any other general guidelines around using c=
onfig false.=C2=A0=C2=A0 The text I posted


when starting this thread had some of that.=C2=A0 Th=
e original RFC6087 text might have


some more.


=C2=A0

OK -- I will work on adding in text from =
-12, your text, and Lou's text.







=C2=A0






> 6087bis was supposed to be a minor update, not =
a living draft that doubles






> as a YANG tutorial and ongoing issues list.<=
/u>






=C2=A0






=C2=A0;) 






=C2=A0


As much as I like RFCs, I think this content would b=
e better served by a Wiki.=C2=A0=C2=A0 If


we were starting for scratch (no RFC6087), then that=
 might make sense but, given


where we are, not so much.=C2=A0 So, I guess we'=
re committed to frequent updates on this


document until YANG settles down.


=C2=A0



=C2=A0


Kent // contributor


=C2=A0


=C2=A0












Andy



--001a114b30d8999df8055798ffc0--


From nobody Fri Aug 25 13:21:42 2017
Return-Path: 
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 1A2581321A4 for ; Fri, 25 Aug 2017 13:21:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 C09GDepfqdKu for ; Fri, 25 Aug 2017 13:21:38 -0700 (PDT)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 85CFE126BF3 for ; Fri, 25 Aug 2017 13:21:38 -0700 (PDT)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 35D9F1E1DA2 for ; Fri, 25 Aug 2017 14:20:52 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id 1YLo1w02A2SSUrH01YLrLi; Fri, 25 Aug 2017 14:20:52 -0600
X-Authority-Analysis: v=2.2 cv=IspuSP3g c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=Th1HI2LWORYA:10 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=KeKAF7QvOSUA:10 a=48vgC7mUAAAA:8 a=-tsAPJKn6S7ax0J5AdsA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:To:Subject:From:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=YC5Qp95XOQVyrlklaQhaTsRKvEnm9RljdtEdz+Wc1GI=; b=2UpzcWQGWau87hd84cObjGK95Z roQ5pxbjfXKtUTslhLLo/LIKTl11IAAB2V015kVNy1XcuMtTEXEO08EWKTi4Oe3h5PMQZ64k4bCjy yWzlVHvUDE8RJffn/Mr6Gft9+;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:42304 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dlL5x-0000uJ-Sp; Fri, 25 Aug 2017 14:20:48 -0600
From: Lou Berger 
To: mbj@tail-f.com, j.schoenwaelder@jacobs-university.de, phil@juniper.net, kwatsen@juniper.net, rwilton@cisco.com, NetMod WG 
Message-ID: <904712c6-038f-ea33-5a1a-62dd493a9481@labn.net>
Date: Fri, 25 Aug 2017 16:20:20 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dlL5x-0000uJ-Sp
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:42304
X-Source-Auth: lberger@labn.net
X-Email-Count: 20
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] Regarding IPR on draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Aug 2017 20:21:41 -0000

Authors, Contributors, WG,

As part of the preparation for WG Last Call:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think
appropriate.

If you are listed as a document author or contributor please answer the
above by responding to this email regardless of whether or not you are
aware of any relevant IPR. This document will not advance to the next
stage until a response has been received from each author and listed
contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
TO LINES.

If you are on the WG email list or attend WG meetings but are not listed
as an author or contributor, we remind you of your obligations under
the IETF IPR rules which encourages you to notify the IETF if you are
aware of IPR of others on an IETF contribution, or to refrain from
participating in any contribution or discussion related to your
undisclosed IPR. For more information, please see the RFCs listed above
and
http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.

Thank you,
NetMod WG Chairs

PS Please include all listed in the headers of this message in your
response.



From nobody Fri Aug 25 16:03:53 2017
Return-Path: 
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 7B9FD132C7D for ; Fri, 25 Aug 2017 16:03:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.01
X-Spam-Level: 
X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 Q3K9f0-t0d-m for ; Fri, 25 Aug 2017 16:03:49 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0103.outbound.protection.outlook.com [104.47.40.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E351323B5 for ; Fri, 25 Aug 2017 16:03:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vLncsQRUD00NiVp2JfPEGzczbQFd9lT2e3X1Z4K6X78=; b=c+5/r+PlddgE6TUfVdb4jHTZ/hpjBwEIyFHlkNXgaly6xdHXUdZ1XrwAbE/Ypqw8Hmu+JKzbHCcdoxz6c0OPSA4RfRsf7Sg/PLJ9qkbOF9IIhE4WjEzExTbxU4D0DUfUOauzSSbfHu3FA7Oyy22Ey8uvYdCTIApLIryCh0Qhzik=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1601.namprd05.prod.outlook.com (10.161.217.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Fri, 25 Aug 2017 23:03:47 +0000
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.20.0013.005; Fri, 25 Aug 2017 23:03:47 +0000
From: Kent Watsen 
To: Lou Berger 
CC: "mbj@tail-f.com" , "j.schoenwaelder@jacobs-university.de" , Phil Shafer , "rwilton@cisco.com" , NetMod WG 
Thread-Topic: Regarding IPR on draft-ietf-netmod-revised-datastores-04
Thread-Index: AQHTHd+n0durDwqPZ0KpKP9Zj6DNgqKVsRAc
Date: Fri, 25 Aug 2017 23:03:46 +0000
Message-ID: 
References: <904712c6-038f-ea33-5a1a-62dd493a9481@labn.net>
In-Reply-To: <904712c6-038f-ea33-5a1a-62dd493a9481@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [96.231.191.4]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1601; 6:WQTWcS8TqGtrUPrRdY+M3Nvp7nDPvtE2hDrs9MUemEG9v0B5NtsQorrixUpr9G4cjtc7PUf93FJH8zE6/HzvYObAN/XC0TBH7rDIqTdd6s97sIHw+a10BPAxcNaSTK+tMaE9Fju04Lzm4Q6pQ0rhIUaRVcl2+7PFaXDdhyhKdFGS4mQH8dGCy+e08+eQ1AuU/DTUBQnkGqsLB21ed/Ns/475Zp1yGjMdh67U5Uaib1Dc1MeilGfMOJRbaSX59YAdt4HvAPsdNlS+awqrHsuvq2PymCyOHRIp4HS03d4s45MMAQh3cjrbZEziemAxUaCB3ZdrAg6IWAUJ0dAZPf4UZg==; 5:AUp8ypipS4InnoZcqNCbQG2hnkVPWZuYbx3mfTzVODXMRoUi8QflmBeNcVMAer3g6tlBQse71gDUESVPOz9/7zROxV6AFq0q+vaZ0Gl6IiP7F/oAXGmCFzdgVE4VWffNKLAg+4uNmP/dZ0LBq5AfZw==; 24:a+WNbQmLz1ZBhBw6zgL5Unv7mVILPSqC7GD0prNiAa8rXnAMtpWb713z0hnvx4QlzrGqxxLyvNIJxcX7gU2b/ldZUYwkfz0n227cz2Qlk48=; 7:WarcpJPH2WL/vwfJC+IDkrgzQ+XEvBqi0VIlPSnQqLtp5Rc1QIyYYvd+zpo/0m8vrA4D5ZMfFQG1s2cuOpJpI8efXTXWxJcfhnC2pNysZLKslk4xdHXWXsXFRWELLY+AE+qrca23VLvOSfSrvfrxkRsZQP95C4PPKlF2Tn2s+uGu3nx+fSKc2tTva3BfLcqEtcflf9j9R4INHo60usysMKp/aq2uyveepqL+Z0v0pR0=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 6c4349d8-dbf4-46d1-a908-08d4ec0d8a9d
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1601; 
x-ms-traffictypediagnostic: BN3PR0501MB1601:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1601; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1601; 
x-forefront-prvs: 041032FF37
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(189002)(377454003)(199003)(101416001)(189998001)(6916009)(25786009)(6512007)(106356001)(3846002)(6306002)(2900100001)(54906002)(6116002)(4326008)(102836003)(105586002)(77096006)(53936002)(50986999)(54356999)(76176999)(5660300001)(53546010)(33656002)(99286003)(2950100002)(230783001)(229853002)(8936002)(97736004)(966005)(66066001)(82746002)(6436002)(8676002)(5003630100001)(6486002)(68736007)(81156014)(36756003)(9886003)(81166006)(6506006)(83716003)(478600001)(110136004)(86362001)(14454004)(6246003)(3280700002)(7736002)(2906002)(3660700001)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1601; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2017 23:03:46.9463 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1601
Archived-At: 
Subject: Re: [netmod] Regarding IPR on draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 25 Aug 2017 23:03:51 -0000

No, I'm not aware of any IPR that applies to this draft.=20

K.=20

Sent from my iPhone

> On Aug 25, 2017, at 4:20 PM, Lou Berger  wrote:
>=20
> Authors, Contributors, WG,
>=20
> As part of the preparation for WG Last Call:
>=20
> Are you aware of any IPR that applies to drafts identified above?
>=20
> Please state either:
>=20
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
>=20
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
>=20
> If yes to the above, please state either:
>=20
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
>=20
> If you answer no, please provide any additional details you think
> appropriate.
>=20
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
>=20
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>=20
> Thank you,
> NetMod WG Chairs
>=20
> PS Please include all listed in the headers of this message in your
> response.
>=20
>=20


From nobody Sat Aug 26 03:09:38 2017
Return-Path: 
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 F1EC91329D4 for ; Sat, 26 Aug 2017 03:09:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 9uaExKEOHEhL for ; Sat, 26 Aug 2017 03:09:35 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87F18132331 for ; Sat, 26 Aug 2017 03:09:34 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id E1DA16AA; Sat, 26 Aug 2017 12:09:32 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id zMxoNWn0FOX7; Sat, 26 Aug 2017 12:09:29 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Sat, 26 Aug 2017 12:09:32 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C193200E3; Sat, 26 Aug 2017 12:09:32 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id z_OU6kNHFAbM; Sat, 26 Aug 2017 12:09:32 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D6B0200E2; Sat, 26 Aug 2017 12:09:31 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id DE98C404D505; Sat, 26 Aug 2017 12:09:29 +0200 (CEST)
Date: Sat, 26 Aug 2017 12:09:29 +0200
From: Juergen Schoenwaelder 
To: Lou Berger 
Cc: mbj@tail-f.com, phil@juniper.net, kwatsen@juniper.net, rwilton@cisco.com, NetMod WG 
Message-ID: <20170826100929.hnx3wuazvp54qgva@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Lou Berger , mbj@tail-f.com, phil@juniper.net, kwatsen@juniper.net, rwilton@cisco.com, NetMod WG 
References: <904712c6-038f-ea33-5a1a-62dd493a9481@labn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <904712c6-038f-ea33-5a1a-62dd493a9481@labn.net>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] Regarding IPR on draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 26 Aug 2017 10:09:38 -0000

No, I'm not aware of any IPR that applies to this draft

/js

PS: (this IPR polling procedure seems to get worse every other year;
     what about an "understands IPR rules" bit in the datatracker?)

On Fri, Aug 25, 2017 at 04:20:20PM -0400, Lou Berger wrote:
> Authors, Contributors, WG,
> 
> As part of the preparation for WG Last Call:
> 
> Are you aware of any IPR that applies to drafts identified above?
> 
> Please state either:
> 
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
> 
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
> 
> If yes to the above, please state either:
> 
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
> 
> If you answer no, please provide any additional details you think
> appropriate.
> 
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
> 
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
> 
> Thank you,
> NetMod WG Chairs
> 
> PS Please include all listed in the headers of this message in your
> response.
> 
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Sun Aug 27 18:08:36 2017
Return-Path: 
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 7A0F7132710 for ; Sun, 27 Aug 2017 18:08:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 kQzbk5jNcA7c for ; Sun, 27 Aug 2017 18:08:31 -0700 (PDT)
Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EF6813264C for ; Sun, 27 Aug 2017 18:08:31 -0700 (PDT)
Received: by mail-wr0-x233.google.com with SMTP id p37so3523110wrc.0 for ; Sun, 27 Aug 2017 18:08:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EtEZg4tbn3SfYQurrpz4P91ubjgFvJhTuU2nOHseb/w=; b=nRV/PK84eBvkmpo3PH1kLXq5lHKiChoCujICcD/mKQ3MRBxCtKan+u1n8CUSRvyPG2 3ZoylR9Woi7ffPXE3NKasl39zy/mohOvJ39vOlTicyymWB6+zwmSnPLpqv9r6nkbMkGw YDsbWmTS8U7ZudnSnJbF8TexT1RrSGMU4Wy1AW1clb4HhA0eOYWIFQXAVhx5+NZOpAL8 BrSGWWXiEHS5Yc5xSD7ZdcHrqiAmm93KdU9DxdmwX2+4ma3qnuFX749P1YBCUvqcIRTQ 1Kn3MIu226Qf6caI+/uUqIscFyBiu3Vqdo/Uen6FLh2Y0Uue7/POKt6qtOsAkb0PtrDy ukmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EtEZg4tbn3SfYQurrpz4P91ubjgFvJhTuU2nOHseb/w=; b=nUkwkJrKQJngy1BXzhLwJOf0FhrQo7V+yAg5W3/qh5Xy6G9ML699v57zJJsBJaDvQ7 mYMO9MMXkbt8tB5TNlQqVgmnLILcGVZf59bNQAnGi3yVTrEhubalKr/Qu69Z+zpgoM/Q Cejb0Sf8196qZIeAeDZyfoj6mtK1A5ft+q/bMymjZKz/jAELLXxN+DbKBobJ6Zw9I5t2 NUe6Bu317u5I6ApfeDYMMiQFQTRy+FaxEx6ZFRkS0n8tYkKGKE5BqlSI6g8OhmHy3rMQ A5yZhqRIlQRBIiXyaxV6TTcU7zoztBHTBoTV33DM7I7w2sgaHQhImO0N6GHgFTtgkoTR pG8w==
X-Gm-Message-State: AHYfb5jjbSGvQaoB7pCYZFTFAjvvXIWwi05NCjjKJviXYwlSj+6J+cOO /px+TOKtpxJawtxqJKmFGS/tYCy61OsVU8A=
X-Received: by 10.223.171.66 with SMTP id r2mr1237526wrc.88.1503882509415; Sun, 27 Aug 2017 18:08:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.221 with HTTP; Sun, 27 Aug 2017 18:08:28 -0700 (PDT)
In-Reply-To: 
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local>    
From: Andy Bierman 
Date: Sun, 27 Aug 2017 18:08:28 -0700
Message-ID: 
To: Kent Watsen 
Cc: Juergen Schoenwaelder , Lou Berger , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="94eb2c1b4fd0c20b640557c5ee9a"
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 01:08:34 -0000

--94eb2c1b4fd0c20b640557c5ee9a
Content-Type: text/plain; charset="UTF-8"

Hi,

Here is the proposed rewrite of 4.23.
I changed a few details in the temporary non-NMDA procedure.
This module cannot duplicate the NMDA module as read-only.
Only the top-level config=false nodes that would have been exposed pre-NMDA
need to be present.

4.23.  Operational State

   The management of YANG operational state has been refined over time.
   At first, only data that has a "config" statement value of "false"
   was considered to be operational state.  This data was not considered
   to be part of any datastore, which made YANG XPath definition much
   more complicated.

   YANG operational state is now modeled according to new NMDA, and is
   now conceptually contained in the operational datastore, which also
   includes the operational values of configuration data.  There is no
   longer any need to duplicate data structures to provide separate
   configuration and operational data sections.

   This section describes some data modeling issues related to
   operational state, and guidelines for transitioning YANG data model
   design to be NMDA-compatible.

4.23.1.  Combining Operational State and Configuration Data

   If possible, operational state SHOULD be combined with its associated
   configuration data.  This prevents duplication of key leafs and
   ancestor nodes.  It also prevents race conditions for retrieval of
   dynamic entries, and allows configuration and operational state to be
   retrieved together with minimal message overhead.

   Not NMDA-Compliant:

      container foo {
        ...
      }

      container foo-state {
        config false;
        ...
      }

   NMDA-Compliant:

      container foo {
        ...
        // contains config=true and config=false nodes that have
        // no corresponding config=true object (e.g., counters)
      }

4.23.2.  Representing Operational Values of Configuration Data

   If possible the same data type SHOULD be used to represent the
   configured value and the operational value, for a given leaf or leaf-
   list object.

   Sometimes the configured value set is different than the operational
   value set for that object.  For example, the "admin-state" and
   "oper-state" leafs in [RFC7223].  In this case a separate object MAY
   be used to represent the configured and operational values.

   Sometimes the list keys are not identical for configuration data and
   the corresponding operational state.  In this case separate lists MAY
   be used to represent the configured and operational values.

   If it is not possible to combine configuration and operational state,
   then the keys used to represent list entries SHOULD be the same type.
   The "leafref" data type SHOULD be used in operational state for key
   leafs that have corresponding configuration instances.  The
   "require-instance" statement MAY be set to "false" (in YANG 1.1
   modules only) to indicate instances are allowed in the operational
   state that do not exist in the associated configuration data.

   If all the data model properties are aligned between configuration
   data and operational state, then it can be useful to define the
   configuration parameters within a grouping, and then replicate that
   grouping within the operational state portion of the data model.

       grouping parms {
          // do not use config-stmt in any of the nodes
          // placed in this grouping
       }

       container bar { // bar config can exist without bar-state
         config true;
         uses parms;
       }

       container bar-state {  // bar-state can exist without bar
         status deprecated;
         config false;
         uses parms;
       }

   The need to replicate objects or define different operational state
   objects depends on the data model.  It is not possible to define one
   approach that will be optimal for all data models.

   Designers SHOULD describe and justify any NMDA exceptions in detail,
   such as the use of separate subtrees and/or separate leafs.  The
   "description" statements for both the configuration and the
   operational state SHOULD be used for this purpose.

4.23.3.  NMDA Transition Guidelines

   YANG modules SHOULD be designed assuming they will be used on servers
   supporting the operational datastore.  With this in mind, YANG
   modules SHOULD define config "false" wherever they make sense to the
   data model.  Config "false" nodes SHOULD NOT be defined to provide
   the operational value for configuration nodes, except when the value
   space of a configured and operational values may differ, in which
   case a distinct config "false" node SHOULD be defined to hold the
   operational value for the configured node.

   The following guidelines are meant to help modelers develop YANG
   models that will maximize the utility of the model with both current
   and new implementations.

   New models and models that are not concerned with the operational
   state of configuration information SHOULD immediately be structured
   to be NMDA-compatible, as described in Section 4.23.1.

   The remaining are options that MAY be followed during the time that
   NMDA mechanisms are being defined.

   (a) Models that require immediate support for the NMDA "origin" meta
   data, such as "in use" and "system created" information, SHOULD be
   structured for NMDA.  A non-NMDA version of these models SHOULD
   exist, either an existing model or a model created either by hand or
   with suitable tools that mirror the current modeling strategies.
   Both the NMDA and the non-NMDA modules SHOULD be published in the
   same document, with NMDA modules in the document main body and the
   non-NMDA modules in a non-normative appendix.  The use of the non-
   NMDA model will allow temporary bridging of the time period until
   NMDA implementations are available.

   (b) For published models, the model should be republished with an
   NMDA-compatible structure, deprecating non-NMDA constructs.  For
   example, the "ietf-interfaces" model in [RFC7223] will be
   restructured as an NMDA-compatible model.  The "/interfaces-state"
   hierarchy will be marked "status deprecated".  Models that mark their
   "/foo-state" hierarchy with "status deprecated" will allow NMDA-
   capable implementations to avoid the cost of duplicating the state
   nodes, while enabling non-NMDA-capable implementations to utilize
   them for access to the operational values.

   (c) For models that augment models which have not been structured
   with the NMDA, the modeler will have to consider the structure of the
   base model and the guidelines listed above.  Where possible, such
   models should move to new revisions of the base model that are NMDA-
   compatible.  When that is not possible, augmenting "state" containers
   SHOULD be avoided, with the expectation that the base model will be
   re-released with the state containers marked as deprecated.  It is
   RECOMMENDED to augment only the "/foo" hierarchy of the base model.
   Where this recommendation cannot be followed, then any new "state"
   elements SHOULD be included in their own module.

4.23.3.1.  Temporary non-NMDA Modules

   A temporary non-NMDA module allows a non-NMDA aware client to access
   operational state from an NMDA-compliant server.  It contains the
   top-level config=false data nodes that would have been defined in a
   legacy YANG module (before NMDA).

   A server that needs to support both NMDA and non-NMDA clients can
   advertise both the new NMDA module and the temporary non-NMDA module.
   A non-NMDA client can use separate "foo" and "foo-state" subtrees,
   except the "foo-state" subtree is located in a different (temporary)
   module.  The NMDA module can be used by a non-NMDA client to access
   the conventional datastores, and the deprecated  operation to
   access nested config=false data nodes.

   To create the temporary non-NMDA model from an NMDA model, the
   following steps can be taken:

   o  Change the module name by appending "-state" to the original
      module name

   o  Change the namespace by appending "-state" to the original
      namespace value

   o  Change the prefix by appending "-s" to the original prefix value

   o  Add an import to the original module (e.g., for typedef
      definitions)

   o  Retain or create only the top-level nodes that have a "config"
      statement value "false".  These subtrees represent config=false
      data nodes that were combined into the configuration subtree, and
      therefore not available to non-NMDA aware clients.  Set the
      "status" statement to "deprecated" for each new node.

   o  The module description SHOULD clearly identify the module as a
      temporary non-NMDA module

4.23.3.2.  NMDA Module Examples

   Example: Create a New Module

   Create an NMDA-compliant module, using combined configuration and
   state subtrees, whenever possible.

     module example-foo {
       namespace "urn:example.com:params:xml:ns:yang:example-foo";
       prefix "foo-";

       container foo {
         // configuration data child nodes
         // operational value in operational datastore only
         // may contain config=false nodes as needed
       }
    }

   Example: Convert an old Non-NMDA Module

   Do not remove non-complaint objects from existing modules.  Instead,
   change the status to "deprecated".  At some point, usually after 1
   year, the status MAY be changed to "obsolete".

   Old Module:

     module example-foo {
       namespace "urn:example.com:params:xml:ns:yang:example-foo";
       prefix "foo";

       container foo {
         // configuration data child nodes
       }

       container foo-state {
         config false;
         // operational state child nodes
       }
    }

   Converted NMDA Module:

     module example-foo {
       namespace "urn:example.com:params:xml:ns:yang:example-foo";
       prefix "foo-";

       container foo {
         // configuration data child nodes
         // operational value in operational datastore only
         // may contain config=false nodes as needed
         // will contain any data nodes from old foo-state
       }

       // keep original foo-state but change status to deprecated
       container foo-state {
         config false;
         status deprecated;
         // operational state child nodes
       }
    }

   Example: Create a Temporary NMDA Module:

   Create a new module that contains the top-level operational state
   data nodes that would have been available before they were combined
   with configuration data nodes (to be NMDA compliant).

     module example-foo-state {
       namespace "urn:example.com:params:xml:ns:yang:example-foo-state";
       prefix "foo-s";

       // import new or converted module; not used in this example
       import example-foo { prefix foo; }

       container foo-state {
         config false;
         status deprecated;
         // operational state child nodes
       }
    }



Andy



On Fri, Aug 25, 2017 at 12:31 PM, Andy Bierman  wrote:

>
>
> On Fri, Aug 25, 2017 at 12:11 PM, Kent Watsen  wrote:
>
>>
>>
>>
>>
>> On 8/25/17, 2:21 PM, "Andy Bierman"  wrote:
>>
>>
>>
>> > Obviously NMDA cannot be used for objects where the configuration value
>> set
>>
>> > and the operstate value set differ, such as with the interface
>> admin-status/oper-status.
>>
>> > Do you want a sentence added that says to use config false leafs as
>> needed within the
>>
>> > configuration entry? A sentence that says operational data is embedded
>> in the
>>
>> > configuration entry?
>>
>>
>>
>> Yes, and any other general guidelines around using config false.   The
>> text I posted
>>
>> when starting this thread had some of that.  The original RFC6087 text
>> might have
>>
>> some more.
>>
>>
>>
>
> OK -- I will work on adding in text from -12, your text, and Lou's text.
>
>
>>
>> > 6087bis was supposed to be a minor update, not a living draft that
>> doubles
>>
>> > as a YANG tutorial and ongoing issues list.
>>
>>
>>
>>  ;)
>>
>>
>>
>> As much as I like RFCs, I think this content would be better served by a
>> Wiki.   If
>>
>> we were starting for scratch (no RFC6087), then that might make sense
>> but, given
>>
>> where we are, not so much.  So, I guess we're committed to frequent
>> updates on this
>>
>> document until YANG settles down.
>>
>>
>>
>
> It is better to have as few moving targets (and normative references) as
> possible.
> YANG modules in an RFC have to conform to a specific version of the YANG
> guidelines.
>
>
>>
>>
>> Kent // contributor
>>
>>
>>
>>
>>
>
> Andy
>
>

--94eb2c1b4fd0c20b640557c5ee9a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

Here is the proposed rewrite of 4.2=
3.
I changed a few details in the temporary non-NMDA procedure.
This module cannot duplicate the NMDA module as read-only.
Only the top-level config=3Dfalse nodes that would have been exposed pre=
-NMDA
need to be present.

4.23.=C2=
=A0 Operational State

=C2=A0 =C2=A0The management =
of YANG operational state has been refined over time.
=C2=A0 =C2=
=A0At first, only data that has a "config" statement value of &qu=
ot;false"
=C2=A0 =C2=A0was considered to be operational stat=
e.=C2=A0 This data was not considered
=C2=A0 =C2=A0to be part of =
any datastore, which made YANG XPath definition much
=C2=A0 =C2=
=A0more complicated.

=C2=A0 =C2=A0YANG operational=
 state is now modeled according to new NMDA, and is
=C2=A0 =C2=A0=
now conceptually contained in the operational datastore, which also
=C2=A0 =C2=A0includes the operational values of configuration data.=C2=
=A0 There is no
=C2=A0 =C2=A0longer any need to duplicate data st=
ructures to provide separate
=C2=A0 =C2=A0configuration and opera=
tional data sections.

=C2=A0 =C2=A0This section de=
scribes some data modeling issues related to
=C2=A0 =C2=A0operati=
onal state, and guidelines for transitioning YANG data model
=C2=
=A0 =C2=A0design to be NMDA-compatible.

4.23.1.=C2=
=A0 Combining Operational State and Configuration Data

=

=C2=A0 =C2=A0If possible, operational state SHOULD be combined with it=
s associated
=C2=A0 =C2=A0configuration data.=C2=A0 This prevents=
 duplication of key leafs and
=C2=A0 =C2=A0ancestor nodes.=C2=A0 =
It also prevents race conditions for retrieval of
=C2=A0 =C2=A0dy=
namic entries, and allows configuration and operational state to be
=C2=A0 =C2=A0retrieved together with minimal message overhead.






<=
div>=C2=A0 =C2=A0configured value and the operational value, for a given le=
af or leaf-

=
=C2=A0 =C2=A0be used to represent the configured and operational values.

=C2=A0 =C2=A0Sometimes the list keys are not identic=
al for configuration data and
=C2=A0 =C2=A0the corresponding oper=
ational state.=C2=A0 In this case separate lists MAY
=C2=A0 =C2=
=A0be used to represent the configured and operational values.
=C2=A0 =C2=A0If it is not possible to combine configuration an=
d operational state,
=C2=A0 =C2=A0then the keys used to represent=
 list entries SHOULD be the same type.
=C2=A0 =C2=A0The "lea=
fref" data type SHOULD be used in operational state for key
=
=C2=A0 =C2=A0leafs that have corresponding configuration instances.=C2=A0 T=
he
=C2=A0 =C2=A0"require-instance" statement MAY be set=
 to "false" (in YANG 1.1
=C2=A0 =C2=A0modules only) to =
indicate instances are allowed in the operational
=C2=A0 =C2=A0st=
ate that do not exist in the associated configuration data.

<=
/div>
=C2=A0 =C2=A0If all the data model properties are aligned between=
 configuration
=C2=A0 =C2=A0data and operational state, then it c=
an be useful to define the
=C2=A0 =C2=A0configuration parameters =
within a grouping, and then replicate that
=C2=A0 =C2=A0grouping =
within the operational state portion of the data model.

=C2=A0 =C2=A0 =C2=A0 =C2=A0grouping parms {
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 // do not use config-stmt in any of the nodes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // placed in this grouping
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0 =
=C2=A0container bar { // bar config can exist without bar-state
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0config true;
=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0uses parms;
=C2=A0 =C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0 =C2=A0container bar-state { =C2=A0//=
 bar-state can exist without bar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0status deprecated;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0config fa=
lse;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uses parms;
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0The need to=
 replicate objects or define different operational state
=C2=A0 =
=C2=A0objects depends on the data model.=C2=A0 It is not possible to define=
 one
=C2=A0 =C2=A0approach that will be optimal for all data mode=
ls.

=C2=A0 =C2=A0Designers SHOULD describe and jus=
tify any NMDA exceptions in detail,
=C2=A0 =C2=A0such as the use =
of separate subtrees and/or separate leafs.=C2=A0 The
=C2=A0 =C2=
=A0"description" statements for both the configuration and the
=C2=A0 =C2=A0operational state SHOULD be used for this purpose.

4.23.3.=C2=A0 NMDA Transition Guidelines
=C2=A0 =C2=A0YANG modules SHOULD be designed assuming they wil=
l be used on servers
=C2=A0 =C2=A0supporting the operational data=
store.=C2=A0 With this in mind, YANG
=C2=A0 =C2=A0modules SHOULD =
define config "false" wherever they make sense to the
=
=C2=A0 =C2=A0data model.=C2=A0 Config "false" nodes SHOULD NOT be=
 defined to provide
=C2=A0 =C2=A0the operational value for config=
uration nodes, except when the value
=C2=A0 =C2=A0space of a conf=
igured and operational values may differ, in which
=C2=A0 =C2=A0c=
ase a distinct config "false" node SHOULD be defined to hold the<=
/div>
=C2=A0 =C2=A0operational value for the configured node.

=C2=A0 =C2=A0The following guidelines are meant to help mod=
elers develop YANG
=C2=A0 =C2=A0models that will maximize the uti=
lity of the model with both current
=C2=A0 =C2=A0and new implemen=
tations.

=C2=A0 =C2=A0New models and models that a=
re not concerned with the operational
=C2=A0 =C2=A0state of confi=
guration information SHOULD immediately be structured
=C2=A0 =C2=
=A0to be NMDA-compatible, as described in Section 4.23.1.

=C2=A0 =C2=A0The remaining are options that MAY be followed during =
the time that
=C2=A0 =C2=A0NMDA mechanisms are being defined.

=C2=A0 =C2=A0(a) Models that require immediate suppor=
t for the NMDA "origin" meta
=C2=A0 =C2=A0data, such as=
 "in use" and "system created" information, SHOULD be
=C2=A0 =C2=A0structured for NMDA.=C2=A0 A non-NMDA version of thes=
e models SHOULD
=C2=A0 =C2=A0exist, either an existing model or a=
 model created either by hand or
=C2=A0 =C2=A0with suitable tools=
 that mirror the current modeling strategies.
=C2=A0 =C2=A0Both t=
he NMDA and the non-NMDA modules SHOULD be published in the
=C2=
=A0 =C2=A0same document, with NMDA modules in the document main body and th=
e
=C2=A0 =C2=A0non-NMDA modules in a non-normative appendix.=C2=
=A0 The use of the non-
=C2=A0 =C2=A0NMDA model will allow tempor=
ary bridging of the time period until
=C2=A0 =C2=A0NMDA implement=
ations are available.

=C2=A0 =C2=A0(b) For publish=
ed models, the model should be republished with an
=C2=A0 =C2=A0N=
MDA-compatible structure, deprecating non-NMDA constructs.=C2=A0 For
<=
div>=C2=A0 =C2=A0example, the "ietf-interfaces" model in [RFC7223=
] will be
=C2=A0 =C2=A0restructured as an NMDA-compatible model.=
=C2=A0 The "/interfaces-state"
=C2=A0 =C2=A0hierarchy w=
ill be marked "status deprecated".=C2=A0 Models that mark their
=C2=A0 =C2=A0"/foo-state" hierarchy with "status de=
precated" will allow NMDA-
=C2=A0 =C2=A0capable implementati=
ons to avoid the cost of duplicating the state
=C2=A0 =C2=A0nodes=
, while enabling non-NMDA-capable implementations to utilize
=C2=
=A0 =C2=A0them for access to the operational values.

=C2=A0 =C2=A0(c) For models that augment models which have not been stru=
ctured
=C2=A0 =C2=A0with the NMDA, the modeler will have to consi=
der the structure of the
=C2=A0 =C2=A0base model and the guidelin=
es listed above.=C2=A0 Where possible, such
=C2=A0 =C2=A0models s=
hould move to new revisions of the base model that are NMDA-
=C2=
=A0 =C2=A0compatible.=C2=A0 When that is not possible, augmenting "sta=
te" containers
=C2=A0 =C2=A0SHOULD be avoided, with the expe=
ctation that the base model will be
=C2=A0 =C2=A0re-released with=
 the state containers marked as deprecated.=C2=A0 It is
=C2=A0 =
=C2=A0RECOMMENDED to augment only the "/foo" hierarchy of the bas=
e model.
=C2=A0 =C2=A0Where this recommendation cannot be followe=
d, then any new "state"
=C2=A0 =C2=A0elements SHOULD be=
 included in their own module.

4.23.3.1.=C2=A0 Tem=
porary non-NMDA Modules

=C2=A0 =C2=A0A temporary n=
on-NMDA module allows a non-NMDA aware client to access
=C2=A0 =
=C2=A0operational state from an NMDA-compliant server.=C2=A0 It contains th=
e
=C2=A0 =C2=A0top-level config=3Dfalse data nodes that would hav=
e been defined in a
=C2=A0 =C2=A0legacy YANG module (before NMDA)=
.

=C2=A0 =C2=A0A server that needs to support both=
 NMDA and non-NMDA clients can
=C2=A0 =C2=A0advertise both the ne=
w NMDA module and the temporary non-NMDA module.
=C2=A0 =C2=A0A n=
on-NMDA client can use separate "foo" and "foo-state" s=
ubtrees,
=C2=A0 =C2=A0except the "foo-state" subtree is=
 located in a different (temporary)
=C2=A0 =C2=A0module.=C2=A0 Th=
e NMDA module can be used by a non-NMDA client to access
=C2=A0 =
=C2=A0the conventional datastores, and the deprecated <get> operation=
 to
=C2=A0 =C2=A0access nested config=3Dfalse data nodes.

=C2=A0 =C2=A0To create the temporary non-NMDA model from =
an NMDA model, the
=C2=A0 =C2=A0following steps can be taken:

=C2=A0 =C2=A0o =C2=A0Change the module name by append=
ing "-state" to the original
=C2=A0 =C2=A0 =C2=A0 modul=
e name

=C2=A0 =C2=A0o =C2=A0Change the namespace b=
y appending "-state" to the original
=C2=A0 =C2=A0 =C2=
=A0 namespace value

=C2=A0 =C2=A0o =C2=A0Change th=
e prefix by appending "-s" to the original prefix value

=C2=A0 =C2=A0o =C2=A0Add an import to the original module (=
e.g., for typedef
=C2=A0 =C2=A0 =C2=A0 definitions)
=C2=A0 =C2=A0o =C2=A0Retain or create only the top-level nodes =
that have a "config"
=C2=A0 =C2=A0 =C2=A0 statement val=
ue "false".=C2=A0 These subtrees represent config=3Dfalse
=C2=A0 =C2=A0 =C2=A0 data nodes that were combined into the configuratio=
n subtree, and
=C2=A0 =C2=A0 =C2=A0 therefore not available to no=
n-NMDA aware clients.=C2=A0 Set the
=C2=A0 =C2=A0 =C2=A0 "st=
atus" statement to "deprecated" for each new node.

=C2=A0 =C2=A0o =C2=A0The module description SHOULD clearly =
identify the module as a
=C2=A0 =C2=A0 =C2=A0 temporary non-NMDA =
module

4.23.3.2.=C2=A0 NMDA Module Examples
<=
div>
=C2=A0 =C2=A0Example: Create a New Module

=

=C2=A0 =C2=A0Create an NMDA-compliant module, using combined con=
figuration and
=C2=A0 =C2=A0state subtrees, whenever possible.

=C2=A0 =C2=A0 =C2=A0module example-foo {
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0namespace "urn:example.com:params:xml:ns:ya=
ng:example-foo";
=C2=A0 =C2=A0 =C2=A0 =C2=A0prefix "foo=
-";

=C2=A0 =C2=A0 =C2=A0 =C2=A0container foo =
{
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// configuration data child n=
odes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// operational value in op=
erational datastore only
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// may=
 contain config=3Dfalse nodes as needed
=C2=A0 =C2=A0 =C2=A0 =C2=
=A0}
=C2=A0 =C2=A0 }

=C2=A0 =C2=A0Exampl=
e: Convert an old Non-NMDA Module

=C2=A0 =C2=A0Do =
not remove non-complaint objects from existing modules.=C2=A0 Instead,
=C2=A0 =C2=A0change the status to "deprecated".=C2=A0 At so=
me point, usually after 1
=C2=A0 =C2=A0year, the status MAY be ch=
anged to "obsolete".

=C2=A0 =C2=A0Old Mo=
dule:

=C2=A0 =C2=A0 =C2=A0module example-foo {
=C2=A0 =C2=A0 =C2=A0 =C2=A0namespace "urn:example.com:params:xm=
l:ns:yang:example-foo";
=C2=A0 =C2=A0 =C2=A0 =C2=A0prefix &q=
uot;foo";

=C2=A0 =C2=A0 =C2=A0 =C2=A0containe=
r foo {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// configuration data c=
hild nodes
=C2=A0 =C2=A0 =C2=A0 =C2=A0}

=
=C2=A0 =C2=A0 =C2=A0 =C2=A0container foo-state {
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0config false;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0// operational state child nodes
=C2=A0 =C2=A0 =C2=A0 =C2=A0}<=
/div>
=C2=A0 =C2=A0 }

=C2=A0 =C2=A0Converted N=
MDA Module:

=C2=A0 =C2=A0 =C2=A0module example-foo=
 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0namespace "urn:example.com:par=
ams:xml:ns:yang:example-foo";
=C2=A0 =C2=A0 =C2=A0 =C2=A0pre=
fix "foo-";

=C2=A0 =C2=A0 =C2=A0 =C2=A0c=
ontainer foo {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// configuration=
 data child nodes
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// operationa=
l value in operational datastore only
=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0// may contain config=3Dfalse nodes as needed
=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0// will contain any data nodes from old foo-state
=C2=A0 =C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=
=A0 =C2=A0 =C2=A0// keep original foo-state but change status to deprecated=

=C2=A0 =C2=A0 =C2=A0 =C2=A0container foo-state {
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0config false;
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0status deprecated;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0// operational state child nodes
=C2=A0 =C2=A0 =C2=A0 =C2=A0}<=
/div>
=C2=A0 =C2=A0 }

=C2=A0 =C2=A0Example: Cr=
eate a Temporary NMDA Module:

=C2=A0 =C2=A0Create =
a new module that contains the top-level operational state
=C2=A0=
 =C2=A0data nodes that would have been available before they were combined<=
/div>
=C2=A0 =C2=A0with configuration data nodes (to be NMDA compliant)=
.

=C2=A0 =C2=A0 =C2=A0module example-foo-state {
=C2=A0 =C2=A0 =C2=A0 =C2=A0namespace "urn:example.com:params:=
xml:ns:yang:example-foo-state";
=C2=A0 =C2=A0 =C2=A0 =C2=A0p=
refix "foo-s";

=C2=A0 =C2=A0 =C2=A0 =C2=
=A0// import new or converted module; not used in this example
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0import example-foo { prefix foo; }
=C2=A0 =C2=A0 =C2=A0 =C2=A0container foo-state {
=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0config false;
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0status deprecated;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0// operational state child nodes
=C2=A0 =C2=A0 =C2=A0 =C2=A0}<=
/div>
=C2=A0 =C2=A0 }


Andy



On Fri, Aug 25, 2017 at 12:31 PM, Andy B=
ierman <andy@yumaworks.com> wrote:


On Fri, Aug 25, 2017 at 12:11 PM, Kent Watsen <kwats=
en@juniper.net> wrote:













=C2=A0=



=C2=A0=







On 8/25/17, 2:21 PM, "Andy Bierman" <andy@yumaworks.com> wrote:








=C2=A0












> Obviously NMDA cannot be used for objects where=
 the configuration value set






> and the operstate value set differ, such as wit=
h the interface admin-status/oper-status.






> Do you want a sentence added that says to use c=
onfig false leafs as needed within the






> configuration entry? A sentence that says opera=
tional data is embedded in the






> configuration entry?






=C2=A0


Yes, and any other general guidelines around using c=
onfig false.=C2=A0=C2=A0 The text I posted


when starting this thread had some of that.=C2=A0 Th=
e original RFC6087 text might have


some more.


=C2=A0

OK -- I will work on adding in text from =
-12, your text, and Lou's text.







=C2=A0






> 6087bis was supposed to be a minor update, not =
a living draft that doubles






> as a YANG tutorial and ongoing issues list.<=
/u>






=C2=A0






=C2=A0;) 






=C2=A0


As much as I like RFCs, I think this content would b=
e better served by a Wiki.=C2=A0=C2=A0 If


we were starting for scratch (no RFC6087), then that=
 might make sense but, given


where we are, not so much.=C2=A0 So, I guess we'=
re committed to frequent updates on this


document until YANG settles down.


=C2=A0

It is better to have as few moving targets (and norma=
tive references) as possible.
YANG modules in an RFC have to conf=
orm to a specific version of the YANG guidelines.
=C2=A0


=C2=A0


Kent // contributor


=C2=A0


=C2=A0












Andy

=






--94eb2c1b4fd0c20b640557c5ee9a--


From nobody Mon Aug 28 01:23:17 2017
Return-Path: 
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 4DB98132CF6 for ; Mon, 28 Aug 2017 01:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 LCh9fzehKveV for ; Mon, 28 Aug 2017 01:23:14 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5C629132CF0 for ; Mon, 28 Aug 2017 01:23:14 -0700 (PDT)
Received: from localhost (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 2E4C11AE02C9; Mon, 28 Aug 2017 10:23:13 +0200 (CEST)
Date: Mon, 28 Aug 2017 10:21:45 +0200 (CEST)
Message-Id: <20170828.102145.2099496813314080522.mbj@tail-f.com>
To: lberger@labn.net
Cc: j.schoenwaelder@jacobs-university.de, phil@juniper.net, kwatsen@juniper.net, rwilton@cisco.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <904712c6-038f-ea33-5a1a-62dd493a9481@labn.net>
References: <904712c6-038f-ea33-5a1a-62dd493a9481@labn.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Regarding IPR on draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 08:23:16 -0000

Hi,

Lou Berger  wrote:
> Authors, Contributors, WG,
> 
> As part of the preparation for WG Last Call:
> 
> Are you aware of any IPR that applies to drafts identified above?
> 
> Please state either:
> 
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"

No, I'm not aware of any IPR that applies to this draft.


/martin


> 
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
> 
> If yes to the above, please state either:
> 
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
> 
> If you answer no, please provide any additional details you think
> appropriate.
> 
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
> 
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
> 
> Thank you,
> NetMod WG Chairs
> 
> PS Please include all listed in the headers of this message in your
> response.
> 
> 
>


From nobody Mon Aug 28 03:11:22 2017
Return-Path: 
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 2C3C3132A1A for ; Mon, 28 Aug 2017 03:11:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 oXBgRnXLBHsx for ; Mon, 28 Aug 2017 03:11:17 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B839B1201F8 for ; Mon, 28 Aug 2017 03:11:16 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id C40278E4; Mon, 28 Aug 2017 12:11:14 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id XgSdJm1Sd1HU; Mon, 28 Aug 2017 12:11:09 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 28 Aug 2017 12:11:14 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9C1B6200AA; Mon, 28 Aug 2017 12:11:14 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ikCOnedlaEkF; Mon, 28 Aug 2017 12:11:12 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 89FFB200EE; Mon, 28 Aug 2017 12:11:12 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 0440F404EC6F; Mon, 28 Aug 2017 12:11:11 +0200 (CEST)
Date: Mon, 28 Aug 2017 12:11:11 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Cc: Kent Watsen , Lou Berger , "netmod@ietf.org" 
Message-ID: <20170828101111.bedfkeoxw3xcj4ex@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , Kent Watsen , Lou Berger , "netmod@ietf.org" 
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local>     
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 10:11:20 -0000

On Sun, Aug 27, 2017 at 06:08:28PM -0700, Andy Bierman wrote:
> Hi,
> 
> Here is the proposed rewrite of 4.23.
> I changed a few details in the temporary non-NMDA procedure.
> This module cannot duplicate the NMDA module as read-only.
> Only the top-level config=false nodes that would have been exposed pre-NMDA
> need to be present.

Thanks for taking the time to produce detailed text. Some comments
inline.
 
> 4.23.  Operational State
> 
>    The management of YANG operational state has been refined over time.

I think you mean:

  The modeling of operational state with YANG has been refied over time.

>    At first, only data that has a "config" statement value of "false"
>    was considered to be operational state.  This data was not considered
>    to be part of any datastore, which made YANG XPath definition much
>    more complicated.
> 
>    YANG operational state is now modeled according to new NMDA, and is

I think we do not have the term 'YANG operational state'. Hence:

  Operational state is now modeled using YANG according to ...

>    now conceptually contained in the operational datastore, which also
>    includes the operational values of configuration data.  There is no
>    longer any need to duplicate data structures to provide separate
>    configuration and operational data sections.
> 
>    This section describes some data modeling issues related to
>    operational state, and guidelines for transitioning YANG data model
>    design to be NMDA-compatible.
> 
> 4.23.1.  Combining Operational State and Configuration Data
> 
>    If possible, operational state SHOULD be combined with its associated
>    configuration data.  This prevents duplication of key leafs and
>    ancestor nodes.  It also prevents race conditions for retrieval of
>    dynamic entries, and allows configuration and operational state to be
>    retrieved together with minimal message overhead.
> 
>    Not NMDA-Compliant:
> 
>       container foo {
>         ...
>       }
> 
>       container foo-state {
>         config false;
>         ...
>       }
> 
>    NMDA-Compliant:
> 
>       container foo {
>         ...
>         // contains config=true and config=false nodes that have
>         // no corresponding config=true object (e.g., counters)
>       }
> 
> 4.23.2.  Representing Operational Values of Configuration Data
> 
>    If possible the same data type SHOULD be used to represent the
>    configured value and the operational value, for a given leaf or leaf-
>    list object.
> 
>    Sometimes the configured value set is different than the operational
>    value set for that object.  For example, the "admin-state" and
>    "oper-state" leafs in [RFC7223].  In this case a separate object MAY
>    be used to represent the configured and operational values.
> 
>    Sometimes the list keys are not identical for configuration data and
>    the corresponding operational state.  In this case separate lists MAY
>    be used to represent the configured and operational values.
> 
>    If it is not possible to combine configuration and operational state,
>    then the keys used to represent list entries SHOULD be the same type.
>    The "leafref" data type SHOULD be used in operational state for key
>    leafs that have corresponding configuration instances.  The
>    "require-instance" statement MAY be set to "false" (in YANG 1.1
>    modules only) to indicate instances are allowed in the operational
>    state that do not exist in the associated configuration data.
> 
>    If all the data model properties are aligned between configuration
>    data and operational state, then it can be useful to define the
>    configuration parameters within a grouping, and then replicate that
>    grouping within the operational state portion of the data model.
> 
>        grouping parms {
>           // do not use config-stmt in any of the nodes
>           // placed in this grouping
>        }
> 
>        container bar { // bar config can exist without bar-state
>          config true;
>          uses parms;
>        }
> 
>        container bar-state {  // bar-state can exist without bar
>          status deprecated;
>          config false;
>          uses parms;
>        }
> 
>    The need to replicate objects or define different operational state
>    objects depends on the data model.  It is not possible to define one
>    approach that will be optimal for all data models.

Well, having bar (config true) and bar-state (config false) is what
NMDA tries to avoid. Even in NMDA, bar can exist in 
without having  in say . (Example, no IP addresses
statically configured but IP addresses learned from DHCP or created by
the system.) I am not sure the discussion starting with "If all the
data model properties" is needed.
 
>    Designers SHOULD describe and justify any NMDA exceptions in detail,
>    such as the use of separate subtrees and/or separate leafs.  The
>    "description" statements for both the configuration and the
>    operational state SHOULD be used for this purpose.
> 
> 4.23.3.  NMDA Transition Guidelines
> 
>    YANG modules SHOULD be designed assuming they will be used on servers
>    supporting the operational datastore.  With this in mind, YANG

It is actually called the 'operational state datastore'.

>    modules SHOULD define config "false" wherever they make sense to the
>    data model.  Config "false" nodes SHOULD NOT be defined to provide
>    the operational value for configuration nodes, except when the value
>    space of a configured and operational values may differ, in which
>    case a distinct config "false" node SHOULD be defined to hold the
>    operational value for the configured node.

Perhaps the text needs to say somewhere very clearly that the
operationally used values of configuration objects are part of the
operational state datastore and hence config false nodes SHOULD NOT be
defined to provide the operational value for configuration nodes...

>    The following guidelines are meant to help modelers develop YANG
>    models that will maximize the utility of the model with both current
>    and new implementations.

Do we generally talk about YANG modules or YANG models in the guidelines
document? Are these used as synonyms? Just wondering...

>    New models and models that are not concerned with the operational
>    state of configuration information SHOULD immediately be structured
>    to be NMDA-compatible, as described in Section 4.23.1.
> 
>    The remaining are options that MAY be followed during the time that
>    NMDA mechanisms are being defined.
> 
>    (a) Models that require immediate support for the NMDA "origin" meta
>    data, such as "in use" and "system created" information, SHOULD be
>    structured for NMDA.

Not sure I parsed this correctly. What does 'in use' and 'system
created' information refer to? I think in general models should follow
NMDA (once it went through the approval process), no?

>    A non-NMDA version of these models SHOULD
>    exist, either an existing model or a model created either by hand or
>    with suitable tools that mirror the current modeling strategies.
>    Both the NMDA and the non-NMDA modules SHOULD be published in the
>    same document, with NMDA modules in the document main body and the
>    non-NMDA modules in a non-normative appendix.  The use of the non-
>    NMDA model will allow temporary bridging of the time period until
>    NMDA implementations are available.

I do not think that it is always a SHOULD to have a non-NMDA model but
then I did not understand the condition of (a). RFC 8194 for instance
is NMDA compatible and this is good enough. If an implementation needs
to expose applied configuration, it will have to implement NMDA.

>    (b) For published models, the model should be republished with an
>    NMDA-compatible structure, deprecating non-NMDA constructs.  For
>    example, the "ietf-interfaces" model in [RFC7223] will be
>    restructured as an NMDA-compatible model.  The "/interfaces-state"
>    hierarchy will be marked "status deprecated".  Models that mark their
>    "/foo-state" hierarchy with "status deprecated" will allow NMDA-
>    capable implementations to avoid the cost of duplicating the state
>    nodes, while enabling non-NMDA-capable implementations to utilize
>    them for access to the operational values.
> 
>    (c) For models that augment models which have not been structured
>    with the NMDA, the modeler will have to consider the structure of the
>    base model and the guidelines listed above.  Where possible, such
>    models should move to new revisions of the base model that are NMDA-
>    compatible.  When that is not possible, augmenting "state" containers
>    SHOULD be avoided, with the expectation that the base model will be
>    re-released with the state containers marked as deprecated.  It is
>    RECOMMENDED to augment only the "/foo" hierarchy of the base model.
>    Where this recommendation cannot be followed, then any new "state"
>    elements SHOULD be included in their own module.
> 
> 4.23.3.1.  Temporary non-NMDA Modules
> 
>    A temporary non-NMDA module allows a non-NMDA aware client to access
>    operational state from an NMDA-compliant server.  It contains the
>    top-level config=false data nodes that would have been defined in a
>    legacy YANG module (before NMDA).
> 
>    A server that needs to support both NMDA and non-NMDA clients can
>    advertise both the new NMDA module and the temporary non-NMDA module.
>    A non-NMDA client can use separate "foo" and "foo-state" subtrees,
>    except the "foo-state" subtree is located in a different (temporary)
>    module.  The NMDA module can be used by a non-NMDA client to access
>    the conventional datastores, and the deprecated  operation to
>    access nested config=false data nodes.
> 
>    To create the temporary non-NMDA model from an NMDA model, the
>    following steps can be taken:
> 
>    o  Change the module name by appending "-state" to the original
>       module name
> 
>    o  Change the namespace by appending "-state" to the original
>       namespace value
> 
>    o  Change the prefix by appending "-s" to the original prefix value
> 
>    o  Add an import to the original module (e.g., for typedef
>       definitions)
> 
>    o  Retain or create only the top-level nodes that have a "config"
>       statement value "false".  These subtrees represent config=false
>       data nodes that were combined into the configuration subtree, and
>       therefore not available to non-NMDA aware clients.  Set the
>       "status" statement to "deprecated" for each new node.
> 
>    o  The module description SHOULD clearly identify the module as a
>       temporary non-NMDA module
> 
> 4.23.3.2.  NMDA Module Examples
> 
>    Example: Create a New Module
> 
>    Create an NMDA-compliant module, using combined configuration and
>    state subtrees, whenever possible.
> 
>      module example-foo {
>        namespace "urn:example.com:params:xml:ns:yang:example-foo";
>        prefix "foo-";
> 
>        container foo {
>          // configuration data child nodes
>          // operational value in operational datastore only
>          // may contain config=false nodes as needed
>        }
>     }

Why would the prefix be "foo-" and not just "foo"?
 
>    Example: Convert an old Non-NMDA Module
> 
>    Do not remove non-complaint objects from existing modules.  Instead,

compliant

>    change the status to "deprecated".  At some point, usually after 1
>    year, the status MAY be changed to "obsolete".
> 
>    Old Module:
> 
>      module example-foo {
>        namespace "urn:example.com:params:xml:ns:yang:example-foo";
>        prefix "foo";
> 
>        container foo {
>          // configuration data child nodes
>        }
> 
>        container foo-state {
>          config false;
>          // operational state child nodes
>        }
>     }
> 
>    Converted NMDA Module:
> 
>      module example-foo {
>        namespace "urn:example.com:params:xml:ns:yang:example-foo";
>        prefix "foo-";

"foo-" vs "foo"

>        container foo {
>          // configuration data child nodes
>          // operational value in operational datastore only
>          // may contain config=false nodes as needed
>          // will contain any data nodes from old foo-state
>        }
> 
>        // keep original foo-state but change status to deprecated
>        container foo-state {
>          config false;
>          status deprecated;
>          // operational state child nodes
>        }
>     }
> 
>    Example: Create a Temporary NMDA Module:
> 
>    Create a new module that contains the top-level operational state
>    data nodes that would have been available before they were combined
>    with configuration data nodes (to be NMDA compliant).
> 
>      module example-foo-state {
>        namespace "urn:example.com:params:xml:ns:yang:example-foo-state";
>        prefix "foo-s";
> 
>        // import new or converted module; not used in this example
>        import example-foo { prefix foo; }
> 
>        container foo-state {
>          config false;
>          status deprecated;
>          // operational state child nodes
>        }
>     }

Perhaps put the examples in separate sections 4.23.3.2, 4.23.3.3,
4.23.3.4 so that they are more clearly separated?
 
> 
> Andy
> 
> 
> 
> On Fri, Aug 25, 2017 at 12:31 PM, Andy Bierman  wrote:
> 
> >
> >
> > On Fri, Aug 25, 2017 at 12:11 PM, Kent Watsen  wrote:
> >
> >>
> >>
> >>
> >>
> >> On 8/25/17, 2:21 PM, "Andy Bierman"  wrote:
> >>
> >>
> >>
> >> > Obviously NMDA cannot be used for objects where the configuration value
> >> set
> >>
> >> > and the operstate value set differ, such as with the interface
> >> admin-status/oper-status.
> >>
> >> > Do you want a sentence added that says to use config false leafs as
> >> needed within the
> >>
> >> > configuration entry? A sentence that says operational data is embedded
> >> in the
> >>
> >> > configuration entry?
> >>
> >>
> >>
> >> Yes, and any other general guidelines around using config false.   The
> >> text I posted
> >>
> >> when starting this thread had some of that.  The original RFC6087 text
> >> might have
> >>
> >> some more.
> >>
> >>
> >>
> >
> > OK -- I will work on adding in text from -12, your text, and Lou's text.
> >
> >
> >>
> >> > 6087bis was supposed to be a minor update, not a living draft that
> >> doubles
> >>
> >> > as a YANG tutorial and ongoing issues list.
> >>
> >>
> >>
> >>  ;)
> >>
> >>
> >>
> >> As much as I like RFCs, I think this content would be better served by a
> >> Wiki.   If
> >>
> >> we were starting for scratch (no RFC6087), then that might make sense
> >> but, given
> >>
> >> where we are, not so much.  So, I guess we're committed to frequent
> >> updates on this
> >>
> >> document until YANG settles down.
> >>
> >>
> >>
> >
> > It is better to have as few moving targets (and normative references) as
> > possible.
> > YANG modules in an RFC have to conform to a specific version of the YANG
> > guidelines.
> >
> >
> >>
> >>
> >> Kent // contributor
> >>
> >>
> >>
> >>
> >>
> >
> > Andy
> >
> >

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Aug 28 03:30:18 2017
Return-Path: 
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 5837C132932 for ; Mon, 28 Aug 2017 03:30:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 zOg8mYkUrKuj for ; Mon, 28 Aug 2017 03:30:15 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D8F0E1201F8 for ; Mon, 28 Aug 2017 03:30:14 -0700 (PDT)
Received: from localhost (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id E5F451AE02C9; Mon, 28 Aug 2017 12:30:12 +0200 (CEST)
Date: Mon, 28 Aug 2017 12:28:45 +0200 (CEST)
Message-Id: <20170828.122845.1527315474517128533.mbj@tail-f.com>
To: lberger@labn.net
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <1aa26e59-6999-8f8a-6cd6-5e74050453bd@labn.net> <20170823.082906.1853252260651620253.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 10:30:17 -0000

Lou Berger  wrote:
> Martin,
> See below
> 
> 
> On August 23, 2017 2:28:37 AM Martin Bjorklund  wrote:
> 
> > Lou Berger  wrote:
> >> Hi Martin,
> >>
> >> See below.
> >>
> >>
> >> On 8/22/2017 6:20 AM, Martin Bjorklund wrote:
> >> > Hi,
> >> >
> >> > Lada presented an open issue in schema mount in Prague.  (See slide 6
> >> > in
> >> > 
> >> https://datatracker.ietf.org/meeting/99/materials/slides-99-netmod-sessb-schema-mount)
> >> >
> >> > The original problem comes from the NI use case
> >> > (https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model).  In this
> >> > use case, interfaces are assigned to NIs by:
> >> >
> >> >    augment /if:interfaces/if:interface:
> >> >      +--rw bind-ni-name?   -> /network-instances/network-instance/name
> >> >
> >> > Modules that are mounted within the NI might have references to
> >> > interfaces.  The idea is that a specific NI can only reference the
> >> > interfaces that has been assigned to it.
> >> >
> >> > In schema mount, we have the "parent-reference" XPath expression that
> >> > in this case will be "/if:interfaces/if:interface".  The problem is
> >> > that this XPath expression will evaluate to a node set that contains
> >> > *all* interfaces in the system.  We would like this to contain just
> >> > the interfaces assigned to the NI.
> >> >
> >> > It turns out that this can be done with a simple change to the
> >> > "parent-reference" node.  If we state that this XPath expression is
> >> > evaluated in an XPath context where the context node is the node in
> >> > the data tree where the mount point is defined (instead of "/"), we
> >> > can use as parent-reference:
> >> >
> >> >   /if:interfaces/if:interface[ni:bind-network-instance-name = ../ni:name]
> >> >
> >> > Putting this together we'd have:
> >> >
> >> >   augment "/if:interfaces/if:interface" {
> >> >     leaf bind-ni-name {
> >> >       type leafref {
> >> >         path "/network-instances/network-instance/name";
> >> >       }
> >> >     }
> >> >   }
> >> >
> >> >   container network-instances {
> >> >     list network-instance {
> >> >       key name;
> >> >       leaf name { ... }
> >> >       ...
> >> >       container root {
> >> >         // this would be the XPath context root for parent-reference
> >> >         yangmnt:mount-point ni-root;
> >> >       }
> >> >     }
> >> >   }
> >>
> >> note that the current NI definition is:
> >
> > Yes I saw that.
> >
> >>    module: ietf-network-instance
> >>      +--rw network-instances
> >>         +--rw network-instance* [name]
> >>            +--rw name           string
> >>            +--rw enabled?       boolean
> >>            +--rw description?   string
> >>            +--rw (ni-type)?
> >>            +--rw (root-type)?
> >>               +--:(vrf-root)
> >>               |  +--mp vrf-root?
> >>               +--:(vsi-root)
> >>               |  +--mp vsi-root?
> >>               +--:(vv-root)
> >>                  +--mp vv-root?
> >
> > Note that the extension yangmnt:mount-point can only be present in a
> > container or list, not in a choice/case.
> 
> Okay, I missed that restriction in your draft.  What's the reason for
> not allowing mounts under choices/cases?  Isn't the resulting path to
> data nodes indistinguishable when the parent is a list or container?

Suppose a server lists a couple of modules for "vrf-root" and some
other for "vsi-root" in the /schema-mounts/mount-point list.  How can
a client tell if a certain NI instance is has the "vrf" modules or
"vsi" modules?

In general, when you have a choice with cases, all nodes from all
cases are disjoint, and the client can tell which case is active by
checking which nodes are present.

Wouldn't it be possible to restructure as bit so you have:

   choice ni-type {
     container vrf {
       ymt:mount-point vrf-root;
       // additional vrf-specific config params goes here
     }
     container vsi {
       ymt:mount-point vsi-root;
       // additional vsi-specific config params goes here
     }
     ...
   }


> > But what is the point of a choice with three different mount points?
> >
> >>    augment /if:interfaces/if:interface:
> >>      +--rw bind-ni-name?   -> /network-instances/network-instance/name
> >>    augment /if:interfaces/if:interface/ip:ipv4:
> >>      +--rw bind-ni-name?   -> /network-instances/network-instance/name
> >>    augment /if:interfaces/if:interface/ip:ipv6:
> >>      +--rw bind-ni-name?   -> /network-instances/network-instance/name
> >>
> >> > And in state data:
> >> >
> >> >
> >> > "ietf-yang-schema-mount:schema-mounts": {
> >> >   "namespace": [
> >> >     {
> >> >       "prefix": "ni",
> >> >       "uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
> >> >     },
> >> >     {
> >> >       "prefix": "if",
> >> >       "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
> >> >     }
> >> >   ]
> >> >   "mount-point": [
> >> >     {
> >> >       "target": "/ni:network-instances/ni:network-instance/ni:root",
> >> Can you confirm that with the current definition the target is:
> >>
> >>       "target": "/ni:network-instances/ni:network-instance",
> >>
> >> correct?
> >
> > See above; the current definition is invalid.
> 
> this is going to get really verbose if schema mount's restrictions
> remain as we'll need a container and target per case mount point case.
> 
> Looking at this issue leads me to ask the question: why are parent
> references tied to the mount point vs the schema?

This gives more flexibility, since several mount points can share a
single schema.  Also, if we had parent-reference per schema, we cannot
solve the original issue that started this thread.

> Are the parent
> references always going to the same in order for the schema to make
> sense.  I think this question is separable from the restriction
> discussion above, but it does help if we stick with the current
> restrictions.
> 
> To be clear I'm suggesting:
> Drop parent-reference from:
> 
>           |  +--ro (schema-ref)?
>           |     +--:(inline)
>           |     |  +--ro inline?       empty
>           |     +--:(use-schema)
>           |        +--ro use-schema* [name]
>           |           +--ro name
>           |           |       -> /schema-mounts/schema/name
>           |           +--ro parent-reference*   yang:xpath1.0
> 
> and add it to
> 
>           +--ro schema* [name]
>              +--ro name           string
>              +--ro parent-reference*   yang:xpath1.0
> 


/martin


From nobody Mon Aug 28 03:39:56 2017
Return-Path: 
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 809A9132932 for ; Mon, 28 Aug 2017 03:39:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
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 gt1H3plzeXxs for ; Mon, 28 Aug 2017 03:39:53 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50099.outbound.protection.outlook.com [40.107.5.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABBBA1201F8 for ; Mon, 28 Aug 2017 03:39:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=h2Aa9iOBbvTjTtFbX9HqbjiwYA0xDxsAV4Aq0sXW1io=; b=CBcCMzmA8u4jq//WETXqtvf7kabPBQ73NmbzKXuZyUw6j2oF7h9lT6zvZ1PxPqsMLXxlHWENB6rDmBuFZgbahSNgMljsVq/hD58ft/5qOcUb7VfBzB3A4OPCZjWPRdWs14sgNnmEIRV0LoWh4ger5+5EkIkq4GGHMdM6hrO+vrI=
Received: from AM2PR07MB0627.eurprd07.prod.outlook.com (10.160.54.154) by AM2PR07MB0627.eurprd07.prod.outlook.com (10.160.54.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Mon, 28 Aug 2017 10:39:50 +0000
Received: from AM2PR07MB0627.eurprd07.prod.outlook.com ([fe80::29ff:1d4:e609:1ac9]) by AM2PR07MB0627.eurprd07.prod.outlook.com ([fe80::29ff:1d4:e609:1ac9%13]) with mapi id 15.20.0013.008; Mon, 28 Aug 2017 10:39:50 +0000
From: "Bogaert, Bart (Nokia - BE/Antwerp)" 
To: "netmod@ietf.org" 
Thread-Topic: draft-ietf-netmod-rfc6087bis-13 - section 4.26.2
Thread-Index: AdMf6AkHeZqeSOpkR0uJ21uWjEaq5Q==
Date: Mon, 28 Aug 2017 10:39:50 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; 
x-originating-ip: [135.245.212.3]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM2PR07MB0627; 6:cYXaSSCk0Pr83ucfT4FWLG6V85/je3QwU3tO406Q+b7Y9DuENK3XnC9OGfjyfmqYSZAWwJndu19fDAPOmquxh6r0dknBthRHYeQoq9KP2ADMmXQBj2fiaA1f4ZTo2/L4Gb114bxF4xMScIXCfcJ69DsHyNSoA8ER4HHJl8CCeDDD/RKqh53nx+IzyzES1eFfJKfRCLK3l1VDit9Eku4UL7DpWnVgUP2xe2akgB04qUzBDj7mBMNGM+B/bhnpjLpmKUTcB1vb3pn1wPMz9KIAAZCZf6hcIXM98ng7nR8I1S3OlWBNzRuEVvO08HgU9VYZvynpInrVd5ALo5DNE4rhTg==; 5:+NoVjW5kD1s1h+36ANNdaTUBoudOX4AM5FpioFmp3XUkecGAhfYjI3UK4gbgdMxTR48aZseb7xTJxpE7ePj960g60h278RFfh3UdlsELO/M/FbmAfMIw5x6k89jIc4Ta+Wu9kUNkBXktzZVrUiCH6A==; 24:kGHGO76XV70NCDMDR43JNOG+0i3nnzFHK82gJweIC2vEUIYG+/zl5bpDpUgFn+TeCGtDKhtJjSWAc8MdT8z7+1qKnkoU2StajNtXs16YDHs=; 7:Npp+C6CTFHY3+3hlnB2F+KW8ZHPkZtjlTZ0DcqubP9ZZtpHqD1I+t3ESc9S5BFhIhqdk3GIigbcsanHKzNQYCqlbYmlCKewzY6LH/AxdoFh/kH18zu8utbLCZEaebBJsKG5a9ND2vuduIVAGBUuteXUfpaefMZDMOXQAJeWrvyxyiF9RdrrAJuYgoKjzOx43vNcWDv9SZOvhU7kzHM6KPyGuPsd0uAtR38iomSbamAc=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 215cfc15-ae9f-4342-47a5-08d4ee011c40
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(49563074)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM2PR07MB0627; 
x-ms-traffictypediagnostic: AM2PR07MB0627:
x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0627; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0627; 
x-forefront-prvs: 0413C9F1ED
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(51874003)(199003)(189002)(105586002)(54896002)(6916009)(7696004)(106356001)(55016002)(99286003)(97736004)(2351001)(25786009)(9686003)(6306002)(6506006)(6436002)(101416001)(5640700003)(66066001)(8936002)(2906002)(2501003)(5250100002)(790700001)(6116002)(102836003)(5630700001)(3846002)(53936002)(3660700001)(5660300001)(1730700003)(3280700002)(68736007)(2900100001)(110136004)(230783001)(81166006)(81156014)(8676002)(33656002)(86362001)(14454004)(189998001)(74316002)(99936001)(7736002)(54356999)(50986999)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0627; H:AM2PR07MB0627.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0490_01D31FFA.BC496CD0"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2017 10:39:50.1497 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0627
Archived-At: 
Subject: [netmod] draft-ietf-netmod-rfc6087bis-13 - section 4.26.2
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 10:39:55 -0000

------=_NextPart_000_0490_01D31FFA.BC496CD0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_001_0491_01D31FFA.BC496CD0"


------=_NextPart_001_0491_01D31FFA.BC496CD0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I would like to understand why the YANG 1.1 feature logic is *much more
expensive* than YANG 1.0.  As far as I can see the way YANG features are
being defined has not changed between YANG 1.0 and YANG 1.1.

 

On the other hand, the second paragraph of this section seems to deal with
"when" versus "if-feature" and the preference to use if-feature instead of
when, if possible.  But as far as I'm aware there are no changes w.r.t. when
between YANG 1.0 and YANG 1.1.  This paragraph seems to suggest that "when"
is worse than if-feature.  I can understand that when is to be evaluated and
depends on the when-condition while a feature can be considered as a design
and implementation choice (the feature is supported or not) and does not
need any run-time 'validation'.  But why is this so different in YANG 1.1
versus YANG 1.0?

 

Where can we find more background on the statement made in this section
about much more expensive and what exactly is meant by this, certainly when
we want to see this in the perspective of the run-time characteristics and
impact on a NC server running in a device.

 

Thanks in advance,

Bart


------=_NextPart_001_0491_01D31FFA.BC496CD0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


I would like to understand why the YANG 1.1 feature logic =
is *much more expensive* than YANG 1.0.  As far as I can see =
the way YANG features are being defined has not changed between YANG 1.0 =
and YANG 1.1.
 
On the other hand, the second paragraph of this section =
seems to deal with “when” versus “if-feature” =
and the preference to use if-feature instead of when, if possible.  =
But as far as I’m aware there are no changes w.r.t. when between =
YANG 1.0 and YANG 1.1.  This paragraph seems to suggest that =
“when” is worse than if-feature.  I can understand that =
when is to be evaluated and depends on the when-condition while a =
feature can be considered as a design and implementation choice (the =
feature is supported or not) and does not need any run-time =
‘validation’.  But why is this so different in YANG 1.1 =
versus YANG 1.0?
 
Where can we find more background on the statement made in =
this section about much more expensive and what exactly is meant by =
this, certainly when we want to see this in the perspective of the =
run-time characteristics and impact on a NC server running in a =
device.
 
Thanks in advance,
Bart

------=_NextPart_001_0491_01D31FFA.BC496CD0--

------=_NextPart_000_0490_01D31FFA.BC496CD0
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw
ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT
8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx
HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0
MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0
QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm
cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK
AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7
GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI
gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn
wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9
xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG
CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI
KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA
MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w
HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt
tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r
aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov
L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH
MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ
HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K
eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ
hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE
7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/
PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA
AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT
LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO
b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET
MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk
ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ
88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY
IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo
+lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5
JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB
JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL
6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD
VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br
aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE
MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h
bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45
qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv
ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F
cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6
eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m
NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f
n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO
5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g
MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs
cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74
4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE
CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT
Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0
MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp
YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg
Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB
0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht
KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM
uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA
J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi
nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN
YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F
c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt
9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH
9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE
AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr
BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB
FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB
AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI
/fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn
FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos
2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR
x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz
iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P
/jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO
0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L
ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT
MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj
ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew
MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MjgxMDM5NDhaMCMGCSqGSIb3DQEJBDEWBBTjg7+k
ZWpj/oUa8PWMzHgtbdhUvDCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t
MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW
Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ
AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS
BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9
xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl
AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC
AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG
SIb3DQEBAQUABIIBAGCvCTP+dXlvzAM8Q1QEPSZf/HmGrUdiU0dyiTyIFvfXwsFhdCdQxn+UiT+D
pSLtzc5QbMahnXufMUu/EPs/pztDacdom+P6Vare0lsPiXT4PAp4/ff2LztwoNdCFV+j9IQ+qHwm
RcXAxZxYRpboXkCNnTmenvOfwu6N1C2+95pSCUM+3aifLDmGANEOObJCF2j5Q1nv7xgo3E6mG6AR
ED6L6KMGeoBC0RWSwYfqSuMoxWromrwX/14xcHhEJJolI/WQtQtIvMDGIZ2QyJk8V2zid/fNLh69
D2dhGSt0WlNXNVqs7hwwtpU1grUKRdId21o4/vricQnClKLjlA8MbCEAAAAAAAA=

------=_NextPart_000_0490_01D31FFA.BC496CD0--


From nobody Mon Aug 28 04:13:13 2017
Return-Path: 
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 F3CB813213F for ; Mon, 28 Aug 2017 04:13:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 mFWA37j6AJpB for ; Mon, 28 Aug 2017 04:13:10 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C75791329C5 for ; Mon, 28 Aug 2017 04:13:09 -0700 (PDT)
Received: from localhost (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id EA6181AE043A; Mon, 28 Aug 2017 13:13:07 +0200 (CEST)
Date: Mon, 28 Aug 2017 13:11:40 +0200 (CEST)
Message-Id: <20170828.131140.1417940736768839828.mbj@tail-f.com>
To: bart.bogaert@nokia.com
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis-13 - section 4.26.2
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 11:13:12 -0000

Hi,

"Bogaert, Bart (Nokia - BE/Antwerp)"  wrote:
> I would like to understand why the YANG 1.1 feature logic is *much more
> expensive* than YANG 1.0.

The document says "much more _expressive_".

> As far as I can see the way YANG features are
> being defined has not changed between YANG 1.0 and YANG 1.1.

if-feature can in YANG 1.1 be a boolean expression of features, e.g.,
"foo or bar and not baz".


> On the other hand, the second paragraph of this section seems to deal with
> "when" versus "if-feature" and the preference to use if-feature instead of
> when, if possible.  But as far as I'm aware there are no changes w.r.t. when
> between YANG 1.0 and YANG 1.1.  This paragraph seems to suggest that "when"
> is worse than if-feature.  I can understand that when is to be evaluated and
> depends on the when-condition while a feature can be considered as a design
> and implementation choice (the feature is supported or not) and does not
> need any run-time 'validation'.  But why is this so different in YANG 1.1
> versus YANG 1.0?

This was true also in 1.0 (i.e., 'if-feature' is simpler than 'when')



/martin




> Where can we find more background on the statement made in this section
> about much more expensive and what exactly is meant by this, certainly when
> we want to see this in the perspective of the run-time characteristics and
> impact on a NC server running in a device.
> 
>  
> 
> Thanks in advance,
> 
> Bart
> 


From nobody Mon Aug 28 04:27:47 2017
Return-Path: 
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 7D414132CF9 for ; Mon, 28 Aug 2017 04:27:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 ewICeu-zD_ZB for ; Mon, 28 Aug 2017 04:27:43 -0700 (PDT)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 2E8991329C5 for ; Mon, 28 Aug 2017 04:27:43 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id 7F380215C5F for ; Mon, 28 Aug 2017 05:27:42 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id 2bTe1w00q2SSUrH01bThxq; Mon, 28 Aug 2017 05:27:42 -0600
X-Authority-Analysis: v=2.2 cv=fJ5J5dSe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=KeKAF7QvOSUA:10 a=wU2YTnxGAAAA:8 a=u07AKapRAAAA:8 a=48vgC7mUAAAA:8 a=YO-WnUvhk5TAcHNkvwwA:9 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=SkebfZ6J2Mmvk2rLHZle:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=WIgkX4F6NraH5miuzsvAsUhCQMZpusKGHtrioKxbWaE=; b=xFYt7zLmazaXuTdI7RHf5MSUww 3dWYD34Rraf1vb56tFVbj28xj5QS1Zj/1KHGqQ3mHq9b7hn5JN8cdGPV3CIlgGsY2qOAe9ob49ivG HJbW1SwWc/8j3a4MXYK7DC+J6;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:45996 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dmICg-003ybP-Bj; Mon, 28 Aug 2017 05:27:38 -0600
To: Martin Bjorklund 
Cc: netmod@ietf.org
References: <1aa26e59-6999-8f8a-6cd6-5e74050453bd@labn.net> <20170823.082906.1853252260651620253.mbj@tail-f.com>  <20170828.122845.1527315474517128533.mbj@tail-f.com>
From: Lou Berger 
Message-ID: 
Date: Mon, 28 Aug 2017 07:27:37 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20170828.122845.1527315474517128533.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dmICg-003ybP-Bj
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net (fs2.dc.labn.net) [100.15.84.20]:45996
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 11:27:45 -0000

Martin,
	See below.

On 08/28/2017 06:28 AM, Martin Bjorklund wrote:
> Lou Berger  wrote:
>> Martin,
>> See below
>>
>>
>> On August 23, 2017 2:28:37 AM Martin Bjorklund  wrote:
>>
>>> Lou Berger  wrote:
>>>> Hi Martin,
>>>>
>>>> See below.
>>>>
>>>>
>>>> On 8/22/2017 6:20 AM, Martin Bjorklund wrote:
>>>>> Hi,
>>>>>
>>>>> Lada presented an open issue in schema mount in Prague.  (See slide 6
>>>>> in
>>>>>
>>>> https://datatracker.ietf.org/meeting/99/materials/slides-99-netmod-sessb-schema-mount)
>>>>>
>>>>> The original problem comes from the NI use case
>>>>> (https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model).  In this
>>>>> use case, interfaces are assigned to NIs by:
>>>>>
>>>>>    augment /if:interfaces/if:interface:
>>>>>      +--rw bind-ni-name?   -> /network-instances/network-instance/name
>>>>>
>>>>> Modules that are mounted within the NI might have references to
>>>>> interfaces.  The idea is that a specific NI can only reference the
>>>>> interfaces that has been assigned to it.
>>>>>
>>>>> In schema mount, we have the "parent-reference" XPath expression that
>>>>> in this case will be "/if:interfaces/if:interface".  The problem is
>>>>> that this XPath expression will evaluate to a node set that contains
>>>>> *all* interfaces in the system.  We would like this to contain just
>>>>> the interfaces assigned to the NI.
>>>>>
>>>>> It turns out that this can be done with a simple change to the
>>>>> "parent-reference" node.  If we state that this XPath expression is
>>>>> evaluated in an XPath context where the context node is the node in
>>>>> the data tree where the mount point is defined (instead of "/"), we
>>>>> can use as parent-reference:
>>>>>
>>>>>   /if:interfaces/if:interface[ni:bind-network-instance-name = ../ni:name]
>>>>>
>>>>> Putting this together we'd have:
>>>>>
>>>>>   augment "/if:interfaces/if:interface" {
>>>>>     leaf bind-ni-name {
>>>>>       type leafref {
>>>>>         path "/network-instances/network-instance/name";
>>>>>       }
>>>>>     }
>>>>>   }
>>>>>
>>>>>   container network-instances {
>>>>>     list network-instance {
>>>>>       key name;
>>>>>       leaf name { ... }
>>>>>       ...
>>>>>       container root {
>>>>>         // this would be the XPath context root for parent-reference
>>>>>         yangmnt:mount-point ni-root;
>>>>>       }
>>>>>     }
>>>>>   }
>>>>
>>>> note that the current NI definition is:
>>>
>>> Yes I saw that.
>>>
>>>>    module: ietf-network-instance
>>>>      +--rw network-instances
>>>>         +--rw network-instance* [name]
>>>>            +--rw name           string
>>>>            +--rw enabled?       boolean
>>>>            +--rw description?   string
>>>>            +--rw (ni-type)?
>>>>            +--rw (root-type)?
>>>>               +--:(vrf-root)
>>>>               |  +--mp vrf-root?
>>>>               +--:(vsi-root)
>>>>               |  +--mp vsi-root?
>>>>               +--:(vv-root)
>>>>                  +--mp vv-root?
>>>
>>> Note that the extension yangmnt:mount-point can only be present in a
>>> container or list, not in a choice/case.
>>
>> Okay, I missed that restriction in your draft.  What's the reason for
>> not allowing mounts under choices/cases?  Isn't the resulting path to
>> data nodes indistinguishable when the parent is a list or container?
> 
> Suppose a server lists a couple of modules for "vrf-root" and some
> other for "vsi-root" in the /schema-mounts/mount-point list.  How can
> a client tell if a certain NI instance is has the "vrf" modules or
> "vsi" modules?

umm, my understanding is that only one of the cases under a choice can
be present in the data (tree) at a time so the client *can* only see one
 mount point {vrf-root, vsi-root or vv-root} node and all the mounted
schemas will be under that '-root' node.  What have I missed?


> 
> In general, when you have a choice with cases, all nodes from all
> cases are disjoint, and the client can tell which case is active by
> checking which nodes are present.
> 
> Wouldn't it be possible to restructure as bit so you have:
> 
>    choice ni-type {
>      container vrf {
>        ymt:mount-point vrf-root;
>        // additional vrf-specific config params goes here
>      }
>      container vsi {
>        ymt:mount-point vsi-root;
>        // additional vsi-specific config params goes here
>      }
>      ...
>    }
> 

Yes, but there will *never* be any additional type specific parameters
in the container (by definition), so the container serves no purpose and
just adds to the path unnecessarily.

> 
>>> But what is the point of a choice with three different mount points?
>>>
>>>>    augment /if:interfaces/if:interface:
>>>>      +--rw bind-ni-name?   -> /network-instances/network-instance/name
>>>>    augment /if:interfaces/if:interface/ip:ipv4:
>>>>      +--rw bind-ni-name?   -> /network-instances/network-instance/name
>>>>    augment /if:interfaces/if:interface/ip:ipv6:
>>>>      +--rw bind-ni-name?   -> /network-instances/network-instance/name
>>>>
>>>>> And in state data:
>>>>>
>>>>>
>>>>> "ietf-yang-schema-mount:schema-mounts": {
>>>>>   "namespace": [
>>>>>     {
>>>>>       "prefix": "ni",
>>>>>       "uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
>>>>>     },
>>>>>     {
>>>>>       "prefix": "if",
>>>>>       "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
>>>>>     }
>>>>>   ]
>>>>>   "mount-point": [
>>>>>     {
>>>>>       "target": "/ni:network-instances/ni:network-instance/ni:root",
>>>> Can you confirm that with the current definition the target is:
>>>>
>>>>       "target": "/ni:network-instances/ni:network-instance",
>>>>
>>>> correct?
>>>
>>> See above; the current definition is invalid.
>>
>> this is going to get really verbose if schema mount's restrictions
>> remain as we'll need a container and target per case mount point case.
>>
>> Looking at this issue leads me to ask the question: why are parent
>> references tied to the mount point vs the schema?
> 
> This gives more flexibility, since several mount points can share a
> single schema.

from my (user) perspective, the parent references are an equally
intrinsic part of the schema and the flexibility adds unneeded complexity.

>  Also, if we had parent-reference per schema, we cannot
> solve the original issue that started this thread.

We/I can live with the current solution (and its overhead), so this
isn't a critical discussion.  Let's focus on the open point covered above.

Thanks,
Lou


From nobody Mon Aug 28 04:36:40 2017
Return-Path: 
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 DC4F3132CF8 for ; Mon, 28 Aug 2017 04:36:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 VEvFLWUIzWc0 for ; Mon, 28 Aug 2017 04:36:36 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EB735132CFA for ; Mon, 28 Aug 2017 04:36:35 -0700 (PDT)
Received: from localhost (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 438061AE02C9; Mon, 28 Aug 2017 13:36:34 +0200 (CEST)
Date: Mon, 28 Aug 2017 13:35:07 +0200 (CEST)
Message-Id: <20170828.133507.2047018591752852829.mbj@tail-f.com>
To: lberger@labn.net
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References:  <20170828.122845.1527315474517128533.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 11:36:39 -0000

Lou Berger  wrote:
> Martin,
> 	See below.
> 
> On 08/28/2017 06:28 AM, Martin Bjorklund wrote:
> > Lou Berger  wrote:
> >> Martin,
> >> See below
> >>
> >>
> >> On August 23, 2017 2:28:37 AM Martin Bjorklund  wrote:
> >>
> >>> Lou Berger  wrote:
> >>>> Hi Martin,
> >>>>
> >>>> See below.
> >>>>
> >>>>
> >>>> On 8/22/2017 6:20 AM, Martin Bjorklund wrote:
> >>>>> Hi,
> >>>>>
> >>>>> Lada presented an open issue in schema mount in Prague.  (See slide 6
> >>>>> in
> >>>>>
> >>>> https://datatracker.ietf.org/meeting/99/materials/slides-99-netmod-sessb-schema-mount)
> >>>>>
> >>>>> The original problem comes from the NI use case
> >>>>> (https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model).  In this
> >>>>> use case, interfaces are assigned to NIs by:
> >>>>>
> >>>>>    augment /if:interfaces/if:interface:
> >>>>>      +--rw bind-ni-name?   -> /network-instances/network-instance/name
> >>>>>
> >>>>> Modules that are mounted within the NI might have references to
> >>>>> interfaces.  The idea is that a specific NI can only reference the
> >>>>> interfaces that has been assigned to it.
> >>>>>
> >>>>> In schema mount, we have the "parent-reference" XPath expression that
> >>>>> in this case will be "/if:interfaces/if:interface".  The problem is
> >>>>> that this XPath expression will evaluate to a node set that contains
> >>>>> *all* interfaces in the system.  We would like this to contain just
> >>>>> the interfaces assigned to the NI.
> >>>>>
> >>>>> It turns out that this can be done with a simple change to the
> >>>>> "parent-reference" node.  If we state that this XPath expression is
> >>>>> evaluated in an XPath context where the context node is the node in
> >>>>> the data tree where the mount point is defined (instead of "/"), we
> >>>>> can use as parent-reference:
> >>>>>
> >>>>>   /if:interfaces/if:interface[ni:bind-network-instance-name = ../ni:name]
> >>>>>
> >>>>> Putting this together we'd have:
> >>>>>
> >>>>>   augment "/if:interfaces/if:interface" {
> >>>>>     leaf bind-ni-name {
> >>>>>       type leafref {
> >>>>>         path "/network-instances/network-instance/name";
> >>>>>       }
> >>>>>     }
> >>>>>   }
> >>>>>
> >>>>>   container network-instances {
> >>>>>     list network-instance {
> >>>>>       key name;
> >>>>>       leaf name { ... }
> >>>>>       ...
> >>>>>       container root {
> >>>>>         // this would be the XPath context root for parent-reference
> >>>>>         yangmnt:mount-point ni-root;
> >>>>>       }
> >>>>>     }
> >>>>>   }
> >>>>
> >>>> note that the current NI definition is:
> >>>
> >>> Yes I saw that.
> >>>
> >>>>    module: ietf-network-instance
> >>>>      +--rw network-instances
> >>>>         +--rw network-instance* [name]
> >>>>            +--rw name           string
> >>>>            +--rw enabled?       boolean
> >>>>            +--rw description?   string
> >>>>            +--rw (ni-type)?
> >>>>            +--rw (root-type)?
> >>>>               +--:(vrf-root)
> >>>>               |  +--mp vrf-root?
> >>>>               +--:(vsi-root)
> >>>>               |  +--mp vsi-root?
> >>>>               +--:(vv-root)
> >>>>                  +--mp vv-root?
> >>>
> >>> Note that the extension yangmnt:mount-point can only be present in a
> >>> container or list, not in a choice/case.
> >>
> >> Okay, I missed that restriction in your draft.  What's the reason for
> >> not allowing mounts under choices/cases?  Isn't the resulting path to
> >> data nodes indistinguishable when the parent is a list or container?
> > 
> > Suppose a server lists a couple of modules for "vrf-root" and some
> > other for "vsi-root" in the /schema-mounts/mount-point list.  How can
> > a client tell if a certain NI instance is has the "vrf" modules or
> > "vsi" modules?
> 
> umm, my understanding is that only one of the cases under a choice can
> be present in the data (tree) at a time so the client *can* only see one
>  mount point {vrf-root, vsi-root or vv-root} node and all the mounted
> schemas will be under that '-root' node.  What have I missed?

The mount point itself is not a node.  So the client will just see
some mounted top-level nodes.  If you require that all mount points
have disjoint sets of modules, then this could work.  But I assume
that this is not the case.

> > In general, when you have a choice with cases, all nodes from all
> > cases are disjoint, and the client can tell which case is active by
> > checking which nodes are present.
> > 
> > Wouldn't it be possible to restructure as bit so you have:
> > 
> >    choice ni-type {
> >      container vrf {
> >        ymt:mount-point vrf-root;
> >        // additional vrf-specific config params goes here
> >      }
> >      container vsi {
> >        ymt:mount-point vsi-root;
> >        // additional vsi-specific config params goes here
> >      }
> >      ...
> >    }
> > 
> 
> Yes, but there will *never* be any additional type specific parameters
> in the container (by definition)

Why is that?  Why not have them in the same container?

Hmm, maybe in general it is better to not mix mounted data with normal
data in the same container.

> so the container serves no purpose and
> just adds to the path unnecessarily.

Well, its presence would inform the client about which mount point is
used, so I don't think it is unnecessary.

> >>> But what is the point of a choice with three different mount points?
> >>>
> >>>>    augment /if:interfaces/if:interface:
> >>>>      +--rw bind-ni-name?   -> /network-instances/network-instance/name
> >>>>    augment /if:interfaces/if:interface/ip:ipv4:
> >>>>      +--rw bind-ni-name?   -> /network-instances/network-instance/name
> >>>>    augment /if:interfaces/if:interface/ip:ipv6:
> >>>>      +--rw bind-ni-name?   -> /network-instances/network-instance/name
> >>>>
> >>>>> And in state data:
> >>>>>
> >>>>>
> >>>>> "ietf-yang-schema-mount:schema-mounts": {
> >>>>>   "namespace": [
> >>>>>     {
> >>>>>       "prefix": "ni",
> >>>>>       "uri": "urn:ietf:params:xml:ns:yang:ietf-network-instance"
> >>>>>     },
> >>>>>     {
> >>>>>       "prefix": "if",
> >>>>>       "uri": "urn:ietf:params:xml:ns:yang:ietf-interfaces"
> >>>>>     }
> >>>>>   ]
> >>>>>   "mount-point": [
> >>>>>     {
> >>>>>       "target": "/ni:network-instances/ni:network-instance/ni:root",
> >>>> Can you confirm that with the current definition the target is:
> >>>>
> >>>>       "target": "/ni:network-instances/ni:network-instance",
> >>>>
> >>>> correct?
> >>>
> >>> See above; the current definition is invalid.
> >>
> >> this is going to get really verbose if schema mount's restrictions
> >> remain as we'll need a container and target per case mount point case.
> >>
> >> Looking at this issue leads me to ask the question: why are parent
> >> references tied to the mount point vs the schema?
> > 
> > This gives more flexibility, since several mount points can share a
> > single schema.
> 
> from my (user) perspective, the parent references are an equally
> intrinsic part of the schema and the flexibility adds unneeded complexity.
> 
> >  Also, if we had parent-reference per schema, we cannot
> > solve the original issue that started this thread.
> 
> We/I can live with the current solution (and its overhead), so this
> isn't a critical discussion.  Let's focus on the open point covered above.
> 
> Thanks,
> Lou
> 



/martin


From nobody Mon Aug 28 04:37:46 2017
Return-Path: 
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 698D5132CF9 for ; Mon, 28 Aug 2017 04:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level: 
X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com
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 DFZHstwUoiXE for ; Mon, 28 Aug 2017 04:37:43 -0700 (PDT)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0112.outbound.protection.outlook.com [104.47.2.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2D35132968 for ; Mon, 28 Aug 2017 04:37:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com;  s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7igI4ryE0AO7qKyIMMyeRq6GHcc0VwcnYD8eEv3c8X0=; b=IuN1iFjLRUTPB8iCT3sVI1DsEu2YPI+fDKvk9dLrEUY4fRut00SGFuqVBEM2YaxULSgZISvOmvCFHHeDiG4QF8qBy5UIExWFUfcinJqXZAhD99UXuIghjt1cVRLOHQBUBUzXyjdvv04gjTYQ79/3UnJaJfpdgQz35vdveUPfG5s=
Received: from AM2PR07MB0627.eurprd07.prod.outlook.com (10.160.54.154) by AM2PR07MB0516.eurprd07.prod.outlook.com (10.160.31.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Mon, 28 Aug 2017 11:37:40 +0000
Received: from AM2PR07MB0627.eurprd07.prod.outlook.com ([fe80::29ff:1d4:e609:1ac9]) by AM2PR07MB0627.eurprd07.prod.outlook.com ([fe80::29ff:1d4:e609:1ac9%13]) with mapi id 15.20.0013.008; Mon, 28 Aug 2017 11:37:39 +0000
From: "Bogaert, Bart (Nokia - BE/Antwerp)" 
To: Martin Bjorklund 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] draft-ietf-netmod-rfc6087bis-13 - section 4.26.2
Thread-Index: AdMf6AkHeZqeSOpkR0uJ21uWjEaq5QABmMMAAADYuDA=
Date: Mon, 28 Aug 2017 11:37:39 +0000
Message-ID: 
References:  <20170828.131140.1417940736768839828.mbj@tail-f.com>
In-Reply-To: <20170828.131140.1417940736768839828.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [135.245.212.3]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM2PR07MB0516; 6:gz2fnitUwyBXwy5yhIx8siSze1UkBCE0XNP6qOOik7CYmKnMgKjZPIMuBwFiy4RwcRVBDQxFi6v8vrS5wk1vs1tKHjYdvnXs3MO8OszgJ8Fcl7oXvUUwpGHs+DGBwhNvkAANHl6kSuDaXs8ZByA0c0FWfnhTCe8ov95eJ2PDojcyN09EZBo9ghPCPF1nLuNmRehg0b7jZLGSSijthuA8/wt/SxjeLDcJvwWKuatLp2p0mFd7G1L2jzdKbdneab7vUZaEZLIL1m18DOMw+M8EzB+JtC16GHqr858oWdzbq+bJjw1TuEy68V2Tap0ZQORcep0TtOI/wtP9FdKvlvchNg==; 5:bpd4Ba64B6l8yKa4/7I96UCnXPKbzbCsVKsO2HGQatRR3jIRQ9bAqAmaBA6zhSlFNXjDCbaD5TwcXOR6wZPW2Wivjo1QkfU5Uh0hpKBFfqngoClWJFewrhA3IELpRudjGWkI/E9KkEPQEkMOTcPPSQ==; 24:maF6LJnWyPK6YqEe4XDn/DGzPTb3R5fImgMqL/1arTMh/SHnRd1XUHk3F++fBrvsibxh0Ym5zn0sSsvkSnPhT66IWdbPdJH2pLnTHu9hduM=; 7:cV369qBzy1Aj4r/0gDKjeeAyVIIDeJCg7zdjgaSGEE8WD6DQWm5UbR26Xj1qXw6eG/ejacbfD1CjamBNxsYhRt5JaB8hIywCyCILkzaYsxWp2ghjMCO/t3M+UNvaw5+nFTBM+MMZ7czWgOnhcL3QBRj23keG10LoFzLYQ6S/qBD+tQd0ieBcBvNTHTTLufLXU+1jtsmIL8K5GC/ouTUMappeLZCv8svzPlGQErDe+ig=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: fa964814-d2b2-480f-ab81-08d4ee093058
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(49563074)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM2PR07MB0516; 
x-ms-traffictypediagnostic: AM2PR07MB0516:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; 
x-exchange-antispam-report-test: UriScan:(82608151540597);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0516; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0516; 
x-forefront-prvs: 0413C9F1ED
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(199003)(13464003)(377454003)(189002)(24454002)(25786009)(8936002)(14454004)(3280700002)(4326008)(478600001)(3660700001)(5660300001)(8676002)(76176999)(54356999)(99936001)(53936002)(81156014)(81166006)(50986999)(53546010)(230783001)(7736002)(2906002)(189998001)(305945005)(101416001)(68736007)(97736004)(110136004)(6246003)(2900100001)(33656002)(6506006)(6436002)(9686003)(74316002)(55016002)(5250100002)(66066001)(99286003)(86362001)(105586002)(229853002)(6916009)(7696004)(106356001)(102836003)(2950100002)(6116002)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM2PR07MB0516; H:AM2PR07MB0627.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_04BE_01D32002.D0B3E3F0"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2017 11:37:39.8378 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0516
Archived-At: 
Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis-13 - section 4.26.2
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 11:37:45 -0000

------=_NextPart_000_04BE_01D32002.D0B3E3F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

-----Original Message-----
From: Martin Bjorklund [mailto:mbj@tail-f.com] 
Sent: Monday, August 28, 2017 1:12 PM
To: Bogaert, Bart (Nokia - BE/Antwerp) 
Cc: netmod@ietf.org
Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis-13 - section 4.26.2

Hi,

"Bogaert, Bart (Nokia - BE/Antwerp)"  wrote:
> I would like to understand why the YANG 1.1 feature logic is *much 
> more
> expensive* than YANG 1.0.

The document says "much more _expressive_".
[Bart Bogaert] Oops... need to have my eyes checked...  thanks for pointing
out.

Regards, Bart


------=_NextPart_000_04BE_01D32002.D0B3E3F0
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQ8TCCBTkw
ggQhoAMCAQICE2kAAL3F0weq80nDargAAAAAvcUwDQYJKoZIhvcNAQELBQAwZDETMBEGCgmSJomT
8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBHJlczEx
HzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwHhcNMTcwMjE0MDgxMzAyWhcNMTkwMjE0
MDgxMzAyWjA6MREwDwYDVQQDEwhib2dhZXJ0YjElMCMGCSqGSIb3DQEJARYWYmFydC5ib2dhZXJ0
QG5va2lhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKR2q9tW6UNuzHCUu6Jm
cua8esn6Cw3rhbOYWpnxUKrHO/CEOh0gl1qjHRerRs9/GK6VI95VI5WyW6LeXvIpIj/2FbBMWQgK
AgZ1KJTm0zpeXLT3tE9gc9A7eSGy4mvJxnBgKw04zWQVRAnJgQQNvhntQocuiQGFmE8X+lQK97p7
GfgzMiiPz6CQRmYPhFZK1tlvd3pD0yFP82jKsLV7F5fRgdTdEAlmElMrXdTvKDdGjbjumi0+X9dI
gxRHBmZS09oPm8Ne0pqPaeXsRmIY6Th0aZmQ5b/DCEVI7LUpkYw9lP57lC76u9w/0yjpdnaO2nMn
wbsSOFfHAN3JJodmxMUCAwEAAaOCAgwwggIIMD0GCSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIW9
xVmD47E5h6WBKoa/w0KFlJgZgQv55kyE/bVaAgFkAgEFMB8GA1UdJQQYMBYGCisGAQQBgjcKAwQG
CCsGAQUFBwMEMAsGA1UdDwQEAwIFoDApBgkrBgEEAYI3FQoEHDAaMAwGCisGAQQBgjcKAwQwCgYI
KwYBBQUHAwQwRAYJKoZIhvcNAQkPBDcwNTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCA
MAcGBSsOAwIHMAoGCCqGSIb3DQMHMCEGA1UdEQQaMBiBFmJhcnQuYm9nYWVydEBub2tpYS5jb20w
HQYDVR0OBBYEFO9rKrBQsC+Cxx24dqpXeDSebD28MB8GA1UdIwQYMBaAFKFIHrb0lRfLkvqL6aCt
tK+kaoByMEYGA1UdHwQ/MD0wO6A5oDeGNWh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9r
aWFJbnRlcm5hbFN1YkNBMDEuY3JsMH0GCCsGAQUFBwEBBHEwbzBBBggrBgEFBQcwAoY1aHR0cDov
L3BraS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsU3ViQ0EwMS5jcnQwKgYIKwYBBQUH
MAGGHmh0dHA6Ly9vY3NwLm5ldC5ub2tpYS5jb20vb2NzcDANBgkqhkiG9w0BAQsFAAOCAQEAKPRZ
HIDzMzfDRd5n62yU/+ao8sEBsDsxWpN0B91/3xHfSnGaCnbOJMJbYyj98MBYJIFbpnhiz2142K4K
eL6F1iNxbjTZmjHpCaEQVosNGfvHr2yrKVZE9Dy/Un7psxx78ZGjxg7U4VA+NYhahlVABhEyACZJ
hxwtnwC1hwoDFG1RdS57RzsY0bbniWp+2Yi7hjW61X1twLNtXVipEXPLqj3tBg+/4ot2sZ5EB7aE
7ExN5Gg7WH4kna6cf+vtqt1qu08DzJh2rv9H0i3WxzeGPcxC280IYadqaKSVOKpNta+/iqdcdvs/
PR2F+gqG9YrOwtLb/H3TJ26NDoBHQzNF4jCCBZIwggN6oAMCAQICExcAAAAF0Ly0uh0kOr4AAAAA
AAUwDQYJKoZIhvcNAQELBQAwdDEaMBgGA1UEChMRTm9raWEgQ29ycG9yYXRpb24xNTAzBgNVBAsT
LENvcHlyaWdodCAoQykgTm9raWEgMjAxNiBBbGwgcmlnaHRzIHJlc2VydmVkMR8wHQYDVQQDExZO
b2tpYSBJbnRlcm5hbCBSb290IENBMB4XDTE2MDQzMDExNDA1NloXDTIyMDQzMDExNTA1NlowZDET
MBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixk
ARkWBHJlczExHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFN1YkNBMDEwggEiMA0GCSqGSIb3DQEB
AQUAA4IBDwAwggEKAoIBAQDIMhMWn4oR+AXTckn1i4i0Svej5B4KueXls+KErSvld+pSFTHy0pAZ
88+X7jLWQYMs6OmZ/JOLIwy6mZWcPVLZtN/k+1pzA0JHf8AD/QjYQbYefh/Es1Cpfdg5lMG6gfKY
IsuU5qTeZ3+AgkSrNaC/Lzr3wVqrmBXuAX72SvgB4zMcWvdxPjuke5Mj7UMPFgmuUNM/B7CNQbvo
+lxDDQa9oE4mOSWQIOn3R3RGNw2qf7YIadV8M/YEnDMF/jyNaP3CeA3upCf3HNyng0peQ5EGb9B5
JOAPQZxLrHRSAxvptCc8YKZUpJG1+qA8CGZ8rvakN1ict7kk+wQKB2lYZKJpAgMBAAGjggErMIIB
JzAOBgNVHQ8BAf8EBAMCAQYwEAYJKwYBBAGCNxUBBAMCAQAwHQYDVR0OBBYEFKFIHrb0lRfLkvqL
6aCttK+kaoByMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA8GA1UdEwEB/wQFMAMBAf8wHwYD
VR0jBBgwFoAUmUW7Vznwh7mBSTDZPld5X/xQnuEwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL3Br
aS5uZXQubm9raWEuY29tL1BLSS9Ob2tpYUludGVybmFsUm9vdENBLmNybDBQBggrBgEFBQcBAQRE
MEIwQAYIKwYBBQUHMAKGNGh0dHA6Ly9wa2kubmV0Lm5va2lhLmNvbS9QS0kvTm9raWFJbnRlcm5h
bFJvb3RDQS5jcnQwDQYJKoZIhvcNAQELBQADggIBAM1oAhXOiiZacE4Getv/pUT9heOFOGLl4/45
qmG8x1DB0QLsYKAifjfyfG1ykge9zV6yd8VI++tSlcpkv2RjIJV1pks9Pik4KtkP7Bd4F5PCs1Jv
ON9tX+iBmWy6PZf+eQDDhJpHTvW8xzxyWQIVf25PD0Rp78+A39zawfxVWoNQ80NCDQF9AxajUN7F
cgja/Qo0F7vz/Tp29c0YrEmcaXHEYhua9JdR4WPv7M38wFkWhSvaucXxqTeo7sRXHq/roU7+gYJ6
eblHY+BOrb3MyB/rTGECsTvmKyRdNBdWQlZcp4LhP+t/6H6BtajbbzAyQFGJi95v3XncN0ZH6r5m
NUW2GMCiw39UjTsJW2P7FoIK12xamNO+aroGy+Bkv4eELzA8ZNx+WPNVCFANHxv6JwyEdaTS8S7f
n0OzjVMWH6hCn4W9SdxgqKC8/8qmgmOrQvCfZsha53fiO2mXyTA7qVnSKuqZOZ2EayEe17J+X4PO
5MIKB+kTfKayZoxxVYebCDxS36OMBDMohKJ7d1SVtw8ZtkmrqUj2lL7WKKG64itWfU1iB8RvQg1g
MvUgvzLAPVAORlrzgbMW/2KX9v6UlCz10wFf1dn/ieYxYygmopnuqllXfo5k3MEA+PDJCai/ftAs
cBubPPWaAuKq4smuMtqTKt9juzNvROLfh9PJlHZPMIIGGjCCBAKgAwIBAgIQe5pN0EOlOKxAGx74
4RskETANBgkqhkiG9w0BAQsFADB0MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UE
CxMsQ29weXJpZ2h0IChDKSBOb2tpYSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMT
Fk5va2lhIEludGVybmFsIFJvb3QgQ0EwHhcNMTYwNDMwMTA1OTQ2WhcNMzYwNDMwMTEwNDM2WjB0
MRowGAYDVQQKExFOb2tpYSBDb3Jwb3JhdGlvbjE1MDMGA1UECxMsQ29weXJpZ2h0IChDKSBOb2tp
YSAyMDE2IEFsbCByaWdodHMgcmVzZXJ2ZWQxHzAdBgNVBAMTFk5va2lhIEludGVybmFsIFJvb3Qg
Q0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDXs/D67CdVEMZFkfSjSvrZWiCrXwaB
0ycsUFRaUdBsXn7VVdbo/qd54BkU2+d6J6SmfABWU2ulFwQoWsUg34MURpP7HS+vtlkj4odiQrht
KC34+KK8E3Jba4dQDc5sBQAHG3d6lMUsuDIwKnIEg9/rGM9ATvqBub9SOXA8CCjBo5P8CVwynJxM
uzIZxMRNRH6ccDMQ9wqK/5s72ZZodGl30366y6M69Xgs+2NlYuO6bpDe52+wpJRqWFzTZJiBvwtA
J23dDexZiL+tCDK+Rq33lmdHcX8nt5AhydHKNFyzhPt4pWFA2ptHht9zYORHSp839HxLCRYh/THi
nt+TziJzfKJGoCPgvAAWULWUvtHZE6sUeiwEB0obTK+MW7w0lIngAyG0/8KvG3v9nUmS63P1fDoN
YMAoLa54wCjZVH/5V3qKIFKtww67TB5KTHDdjStMbMPJqGT84mvdZT9N/+4PG8/wBO2sTgX3WX6F
c7tg2WR0nXgtejseSlW2Usg8BaZ7heRnf1557yM1Nqum6aBF2qTKDggbQ6TZaBMUs+wTA+gy2JDt
9dyzcd0isVsVVbcsPeTXKXFLZm9c7m8UPMMHihrgSRrmw1IIPStiHIAZgd/sIgEy+h3JQ71/GybH
9UkfNdoAb8z+S6tn5K1kgBc/JlT+jrVww0AcDA0mxuDJjQIDAQABo4GnMIGkMA4GA1UdDwEB/wQE
AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBSZRbtXOfCHuYFJMNk+V3lf/FCe4TAQBgkr
BgEEAYI3FQEEAwIBADBQBgNVHSAESTBHMEUGDysGAQQBgd4qAQ0GAgEBBDAyMDAGCCsGAQUFBwIB
FiRodHRwOi8vcGtpLm5ldC5ub2tpYS5jb20vUEtJL2NwLmh0bQAwDQYJKoZIhvcNAQELBQADggIB
AATlizFQ7ZVdA0+kboRTRlkFt2GOst5y8GNkq1/Dzz24hs2smwC2Nct1WBsm8K22SkrFjYKpkNtI
/fniQN35BnSx8WUUZMqhWgPNo7tqkEbVTPhokFHv9W0WRomZl5gD8NApPrMfJsOIbmJ+/KrUv7Bn
FRQCSpNuzm1ZH7DxYp59QdIhHCNo2KmImYLg1ay9iWaVNYy+7U0XJ4Vutntr2BDbpVgLlZfWwRos
2W35eZCgv82pKtpgU/1rxnlDR8fz/55nUp8HSWGVMKKLofvgSlrohWFab3cL8ZiLQcqu3fCM0YhR
x9Khh1OeXeUqi9A4O0zPHO3TunyNZL6fO2VQZt2I2MyBMpCzvOYwo2CvnqTirC4WD/YbniK3vkPz
iyI+77x1pDHpmZAznCnuTlUHBvqjeJ7ZKGGBVkD3YJRTlmzMIQzUKhxwEX8e6hA7SlPknyKWUL4P
/jQ40/++F57BWgMA8ufw4+NPdGlQvU+v6+A8xPMczwKFRkAV/yaMUF2cZ1oFjhFyJ/U2b0iOvcCO
0PB0/iobLrr6CDmR2aWxF5j3N/Yw2xYfazPB6w/b/1Wx5ukXDNBwHSiPnVNB8CqxSvFqWQKFPI7L
ntolxpyIuWcpv2cjeb+c3ieD9wrRt2GRjzZ/GMo4CDZR1k8unUNLDtMdxDhRzq5uUROanOskOygT
MYIDtTCCA7ECAQEwezBkMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVj
ZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMWTm9raWEgSW50ZXJuYWwgU3ViQ0Ew
MQITaQAAvcXTB6rzScNquAAAAAC9xTAJBgUrDgMCGgUAoIICDzAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzA4MjgxMTM3MzhaMCMGCSqGSIb3DQEJBDEWBBSkg4WW
ojOnoQ79GT0sc2DqXYsNYDCBigYJKwYBBAGCNxAEMX0wezBkMRMwEQYKCZImiZPyLGQBGRYDY29t
MRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEcmVzMTEfMB0GA1UEAxMW
Tm9raWEgSW50ZXJuYWwgU3ViQ0EwMQITaQAAvcXTB6rzScNquAAAAAC9xTCBjAYLKoZIhvcNAQkQ
AgsxfaB7MGQxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDAS
BgoJkiaJk/IsZAEZFgRyZXMxMR8wHQYDVQQDExZOb2tpYSBJbnRlcm5hbCBTdWJDQTAxAhNpAAC9
xdMHqvNJw2q4AAAAAL3FMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFl
AwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMC
AgFAMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzALBglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMA0GCSqG
SIb3DQEBAQUABIIBADX1F3j298Ox4Qa9xn2jxQxDrK8bFErEOx9cE/NTEla0xyrQsD/n9+//6S+0
3ZhETceS2Eyd8HuWR27GrtBtMxL5iRsNuRuw7KKzQ0TH+iYF9bTgamgpkNwxD+qcBPEipcbF/CM1
Mm8FO+41kSPoWvbg7wuDUOCBkfydsjMbQbMDj9M7+CylqLWkLT0VtmoLvryRRFpSipqvvb+GWh/r
FpfqvXyQ7UQPgSNzEu2J43YO/EgI2wkHA7IU8uSH8h69lscQrYJvuHzSfDzmV3HqITY7u1DW7iuI
XjcFwPaXDDE4XmrjN9CJ2jfMYUWOJzXl32+1d4kwFmTNtfLBeA7oUaYAAAAAAAA=

------=_NextPart_000_04BE_01D32002.D0B3E3F0--


From nobody Mon Aug 28 05:53:30 2017
Return-Path: 
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 9B6CD132C38; Mon, 28 Aug 2017 05:53:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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
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 Mbic6LaVJKto; Mon, 28 Aug 2017 05:53:22 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58BA11329F9; Mon, 28 Aug 2017 05:53:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=402; q=dns/txt; s=iport; t=1503924801; x=1505134401; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=ANIz9lp5LUHA2SJo81okn77SYmNU+xJx3kHoiMvfPjg=; b=U2abvCk+vFBT61bPnkEBYeJTLfFr6Re2ZUgt9rkTquN8ul2k2phAsx0X LiU6YK9qW2iQ5qzs0Zy2yssdJr6nmPTsDq/CjQkwlocD08OHrwZgh46GN r5mV22Uj3N/pZaEBggfB9sOEMO0VSxkxBjlMB4PVCtzmcFgrYviipC4Zj A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CWAwC/EKRZ/xbLJq1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhD6BFYN3ijlYkHOWVoIELIURhEgUAQIBAQEBAQEBayiFQhV2AiYCXwE?= =?us-ascii?q?MCAEBii0QsRSCJ4tfAQEBAQYCJoENgh2DUIIOC4QugwErgyCCYQWgZIdWjHACg?= =?us-ascii?q?XgBF1qFDINZhU6BSY1LiHI2IYENMiEIHBWFbYF5PjYBiCgrghQBAQE?=
X-IronPort-AV: E=Sophos;i="5.41,441,1498521600"; d="scan'208";a="655257805"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Aug 2017 12:53:17 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v7SCrHAZ012860; Mon, 28 Aug 2017 12:53:17 GMT
To: NETMOD Working Group , YANG Doctors 
From: Benoit Claise 
Message-ID: <26131545-049c-9a1a-eb2b-cdad6fce3190@cisco.com>
Date: Mon, 28 Aug 2017 14:53:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: [netmod] YumaPro SDK 17.10-B3 and yanglint 0.13.49 upgraded on claise.be
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 12:53:23 -0000

Dear all,

With these two upgrades, we received way more warnings. Most comes from 
yanglint, to be candid.
Please check your YANG modules at 
http://www.claise.be/IETFYANGPageCompilation.html
About 50 YANG modules PASSED previously and now report PASSED WITH WARNINGS.

It's great that validators check more and more things. This leads to 
increased quality YANG modules.

Regards, Benoit



From nobody Mon Aug 28 05:54:44 2017
Return-Path: 
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 5E507132D09 for ; Mon, 28 Aug 2017 05:54:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 i4CXUIouGjub for ; Mon, 28 Aug 2017 05:54:35 -0700 (PDT)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 3406D132199 for ; Mon, 28 Aug 2017 05:54:35 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id DF8A0215E34 for ; Mon, 28 Aug 2017 06:54:33 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id 2cuW1w00g2SSUrH01cuZu7; Mon, 28 Aug 2017 06:54:33 -0600
X-Authority-Analysis: v=2.2 cv=fJ5J5dSe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=KeKAF7QvOSUA:10 a=wU2YTnxGAAAA:8 a=u07AKapRAAAA:8 a=48vgC7mUAAAA:8 a=qo_yGb_QLt_5vNEFytgA:9 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=SkebfZ6J2Mmvk2rLHZle:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=nlJ4XKEVg4v+wkXNScO/oV7DQxh6D700isprwvnakyY=; b=Xoa8DlATEul1Uip3Jizynyhy49 DzvFK7udN69jck+tR6qJB1XixD2zsrCWSakHSdCd5zk/siNRNVCYBbQ5LVKgXsKPoOuQUezKU4MgP EqCsYmbllnZjzwOsRjenZNPZv;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:47028 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dmJYj-004CxU-Tx; Mon, 28 Aug 2017 06:54:30 -0600
To: Martin Bjorklund 
Cc: netmod@ietf.org
References:  <20170828.122845.1527315474517128533.mbj@tail-f.com>  <20170828.133507.2047018591752852829.mbj@tail-f.com>
From: Lou Berger 
Message-ID: 
Date: Mon, 28 Aug 2017 08:54:24 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170828.133507.2047018591752852829.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dmJYj-004CxU-Tx
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:47028
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 12:54:41 -0000

On 8/28/2017 7:35 AM, Martin Bjorklund wrote:
> Lou Berger  wrote:
>> Martin,
>> 	See below.
>>
>> On 08/28/2017 06:28 AM, Martin Bjorklund wrote:
>>> Lou Berger  wrote:
>>>> Martin,
>>>> See below
>>>>
>>>>
>>>> On August 23, 2017 2:28:37 AM Martin Bjorklund  wrote:
>>>>
>>>>> Lou Berger  wrote:
>>>>>> Hi Martin,
>>>>>>
>>>>>> See below.
>>>>>>
>>>>>>
>>>>>> On 8/22/2017 6:20 AM, Martin Bjorklund wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Lada presented an open issue in schema mount in Prague.  (See slide 6
>>>>>>> in
>>>>>>>
>>>>>> https://datatracker.ietf.org/meeting/99/materials/slides-99-netmod-sessb-schema-mount)
>>>>>>> The original problem comes from the NI use case
>>>>>>> (https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model).  In this
>>>>>>> use case, interfaces are assigned to NIs by:
>>>>>>>
>>>>>>>    augment /if:interfaces/if:interface:
>>>>>>>      +--rw bind-ni-name?   -> /network-instances/network-instance/name
>>>>>>>
>>>>>>> Modules that are mounted within the NI might have references to
>>>>>>> interfaces.  The idea is that a specific NI can only reference the
>>>>>>> interfaces that has been assigned to it.
>>>>>>>
>>>>>>> In schema mount, we have the "parent-reference" XPath expression that
>>>>>>> in this case will be "/if:interfaces/if:interface".  The problem is
>>>>>>> that this XPath expression will evaluate to a node set that contains
>>>>>>> *all* interfaces in the system.  We would like this to contain just
>>>>>>> the interfaces assigned to the NI.
>>>>>>>
>>>>>>> It turns out that this can be done with a simple change to the
>>>>>>> "parent-reference" node.  If we state that this XPath expression is
>>>>>>> evaluated in an XPath context where the context node is the node in
>>>>>>> the data tree where the mount point is defined (instead of "/"), we
>>>>>>> can use as parent-reference:
>>>>>>>
>>>>>>>   /if:interfaces/if:interface[ni:bind-network-instance-name = ../ni:name]
>>>>>>>
>>>>>>> Putting this together we'd have:
>>>>>>>
>>>>>>>   augment "/if:interfaces/if:interface" {
>>>>>>>     leaf bind-ni-name {
>>>>>>>       type leafref {
>>>>>>>         path "/network-instances/network-instance/name";
>>>>>>>       }
>>>>>>>     }
>>>>>>>   }
>>>>>>>
>>>>>>>   container network-instances {
>>>>>>>     list network-instance {
>>>>>>>       key name;
>>>>>>>       leaf name { ... }
>>>>>>>       ...
>>>>>>>       container root {
>>>>>>>         // this would be the XPath context root for parent-reference
>>>>>>>         yangmnt:mount-point ni-root;
>>>>>>>       }
>>>>>>>     }
>>>>>>>   }
>>>>>> note that the current NI definition is:
>>>>> Yes I saw that.
>>>>>
>>>>>>    module: ietf-network-instance
>>>>>>      +--rw network-instances
>>>>>>         +--rw network-instance* [name]
>>>>>>            +--rw name           string
>>>>>>            +--rw enabled?       boolean
>>>>>>            +--rw description?   string
>>>>>>            +--rw (ni-type)?
>>>>>>            +--rw (root-type)?
>>>>>>               +--:(vrf-root)
>>>>>>               |  +--mp vrf-root?
>>>>>>               +--:(vsi-root)
>>>>>>               |  +--mp vsi-root?
>>>>>>               +--:(vv-root)
>>>>>>                  +--mp vv-root?
>>>>> Note that the extension yangmnt:mount-point can only be present in a
>>>>> container or list, not in a choice/case.
>>>> Okay, I missed that restriction in your draft.  What's the reason for
>>>> not allowing mounts under choices/cases?  Isn't the resulting path to
>>>> data nodes indistinguishable when the parent is a list or container?
>>> Suppose a server lists a couple of modules for "vrf-root" and some
>>> other for "vsi-root" in the /schema-mounts/mount-point list.  How can
>>> a client tell if a certain NI instance is has the "vrf" modules or
>>> "vsi" modules?
>> umm, my understanding is that only one of the cases under a choice can
>> be present in the data (tree) at a time so the client *can* only see one
>>  mount point {vrf-root, vsi-root or vv-root} node and all the mounted
>> schemas will be under that '-root' node.  What have I missed?
> The mount point itself is not a node.  
okay, I think we're getting to the crux of this issue!  I certainly
didn't see this (that a schema-mount root node is *not* represented in
the data, but only in the schema) stated in
draft-ietf-netmod-schema-mount.  In fact, I read the text as saying just
the opposite:

   The basic idea of schema mount is to label a data node in the parent
   schema as the mount point, and then define a complete data model to
   be attached to the mount point so that the labeled data node
   effectively becomes the root node of the mounted data model.

Why don't you think an MP should be represented in the data (tree)?

In our example usage
(https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B) we
include the mount point as a node in the data.  You're saying that this
doesn't line up with your expectation, right?

Can you please take a look at it and see if we have any other disconnects?

> So the client will just see
> some mounted top-level nodes.  If you require that all mount points
> have disjoint sets of modules, then this could work.  But I assume
> that this is not the case.



Lou


From nobody Mon Aug 28 05:59:07 2017
Return-Path: 
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 0F43E1328DB for ; Mon, 28 Aug 2017 05:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jabil.onmicrosoft.com
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 079JNWh_ri1W for ; Mon, 28 Aug 2017 05:59:02 -0700 (PDT)
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0112.outbound.protection.outlook.com [104.47.38.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAB9F132199 for ; Mon, 28 Aug 2017 05:59:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jabil.onmicrosoft.com;  s=selector1-jabil-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1+3zsr7hMUSYfpW6xSWyO+27tFGqc+BbQqgqSy2XANA=; b=6VeVmPNJZpwaTlDOhA9M8dreU/BbI9X2sx8AgYItrCedE6YqgCAg8B66kM97ZIlYDH6ZfGcgi3H88n62Wz951x2Y9kM2K3Mhz/OcqVri5xgJUXsuOPOxJoyKhfVdB1nH9fzzapIU5ONL6zzgqPO4BX+5JJpcRvhBh+cjZZbgH6I=
Received: from BN3PR0201MB0867.namprd02.prod.outlook.com (10.160.154.13) by BN3PR0201MB1058.namprd02.prod.outlook.com (10.161.209.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1385.9; Mon, 28 Aug 2017 12:58:59 +0000
Received: from BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) by BN3PR0201MB0867.namprd02.prod.outlook.com ([10.160.154.13]) with mapi id 15.01.1385.014; Mon, 28 Aug 2017 12:58:59 +0000
From: Xufeng Liu 
To: Juergen Schoenwaelder 
CC: Per Hedeland , Ladislav Lhotka , "'netmod@ietf.org'" 
Thread-Topic: [netmod] Potential additions to rfc6087bis: RegEx guidelines
Thread-Index: AdMcU4SqqeTEr3DWR4ygcD75zJMNgAAS/WQAAAKnWIAAEce1gAAC0wKAACiZxdAAAInsAACWumgg
Date: Mon, 28 Aug 2017 12:58:59 +0000
Message-ID: 
References:  <20170824060900.u5kcffzvwjr7mmob@elstar.local> <152f24b2-7947-9c76-714c-af226ab3fe91@tail-f.com> <8760ddc676.fsf@nic.cz> <599F0991.7020900@tail-f.com>  <20170825125254.6nhnzkrar6fhu7zr@elstar.local>
In-Reply-To: <20170825125254.6nhnzkrar6fhu7zr@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNceGxpdVxhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLWE2ZjRkOTg1LThiZjAtMTFlNy05YzI4LTE4NWUwZmUzYzQ1Y1xhbWUtdGVzdFxhNmY0ZDk4Ny04YmYwLTExZTctOWMyOC0xODVlMGZlM2M0NWNib2R5LnR4dCIgc3o9IjE4MzYiIHQ9IjEzMTQ4Mzk4NzM4NTUxNjc2OSIgaD0iS29UckczK2ZsWFlHd2J1Sk8rSTVLd2J3TVNBPSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg==
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Xufeng_Liu@jabil.com; 
x-originating-ip: [98.191.72.170]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0201MB1058; 6:oX5Sf1hiS6eIyYr31LXhd7BVPdN/SerUIf+x8V0od0wbW2gHx//WWw6I5wZ1FIEGkVG8MUHKUF32os580dcRXFs1FKtY8CPWMYiuARvYxd3sPpoPUSE6Zdkj2220HO0w3GBrof0QxfKs/BjeATx1dLFitlGWbaQiFhboAcDsJ1fGZqu0EeeIxumj967y7ltRpF7juT1DDNxw/k99PXV/TSsEp7kAKo5mJR4lKAWNrTIF2RXEytphIXLUMZ7zkZQeReGgSt3ibkyLSQYvQq0a1YAKq/H/fmHyMp8lF6YWaBaVQoR/YoWZWL91SxMmHM5e2++Lqq6wUYoSogiV0s51hQ==; 5:RnWXn4ZwYqTQ7mb4+QR/z5UzeLIwtCV2PjuivJ3dGykcCtuIduDK5FV4FE4rGsH1L6NYNbv+EQkjWebrPR3pq/1HBtqSNfjhNTFlaYJyP+YwoNuoaXamwxtrlajW3V9keT7XprpGf4b4sG0mS0eakA==; 24:mv5ElPkY9ZhZzF/El2AFlbN1EIxV8ZHy4TZK62nDa+bAfegbL6fYl1o5g0J5Ov7rgxHxLOeTCXHgYBI2tdu9G2TQsec/OjJszIAelIsInIo=; 7:YARu5I3ts45VqHjxmomYud2cBadywrBfgz/yHoxJ2Gw/Th0Vk3TdwH5jPsahyB10032Exp/wrZtuUbVoQBKvRlqEzttDnFjeiY60RJwoqLSHxrG2lLRsMhTmWSXjwdFzqZB9+pXCeTf7aa5mD6re8J2XXuw9wmblx6m+tjrhhzaGd+BuSugC+6J6CS6nPY7YXICmUIwUiqM/tv19/QqPijflXlOdtL/Uq2aibv68xEE=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 917a371e-81e6-4292-ba6a-08d4ee148ce2
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0201MB1058; 
x-ms-traffictypediagnostic: BN3PR0201MB1058:
x-exchange-antispam-report-test: UriScan:(788757137089)(21534305686606);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0201MB1058; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0201MB1058; 
x-forefront-prvs: 0413C9F1ED
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(377454003)(199003)(189002)(52314003)(24454002)(13464003)(53936002)(3660700001)(6506006)(3846002)(102836003)(6116002)(99286003)(54906002)(74316002)(189998001)(55016002)(106356001)(105586002)(4326008)(478600001)(86362001)(97736004)(7696004)(68736007)(66066001)(93886005)(25786009)(2900100001)(3280700002)(72206003)(54356999)(110136004)(6246003)(8936002)(81156014)(50986999)(8676002)(76176999)(80792005)(561944003)(2950100002)(6916009)(81166006)(229853002)(6306002)(9686003)(53546010)(6436002)(2906002)(7736002)(77096006)(33656002)(101416001)(14454004)(5660300001)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0201MB1058; H:BN3PR0201MB0867.namprd02.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: jabil.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: jabil.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2017 12:58:59.4008 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bc876b21-f134-4c12-a265-8ed26b7f0f3b
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0201MB1058
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 12:59:05 -0000

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
> Sent: Friday, August 25, 2017 8:53 AM
> To: Xufeng Liu 
> Cc: Per Hedeland ; Ladislav Lhotka ;
> 'netmod@ietf.org' 
> Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
>=20
> On Fri, Aug 25, 2017 at 12:40:18PM +0000, Xufeng Liu wrote:
> >
> > > I did not see a proposed change to the standard YANG specification
> > > regarding the regexp flavor, only a proposal that module authors
> > > SHOULD show consideration for implementations that don't comply with
> > > the standard.
> > >
>=20
> > [Xufeng] This is the point.
>=20
> Perhaps this did not come out properly.
>=20
> Anyway, why would I as a YANG author have to replace \d with [0..9] so th=
at
> implementations that can't handle \d are happy? An implementation can eas=
ily
> do this substitution itself before passing the pattern to the regex engin=
e it
> prefers to use. (I think this is what libyang is actually doing, I think =
it uses pcre
> internally.)
>=20
> YANG 1.0 and 1.1 are pretty clear which pattern syntax they use.
> Implementations should try to support that.

[Xufeng] [0..9] is still compliant with the XSD pattern specified by YANG 1=
.0 and 1.1. Using [0..9] instead of [\d] will make the implementations with=
 native POSIX RegEx easier without the need for a tool to inspect every ele=
ment of the RegEx pattern.

>=20
> /js
>=20
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         


From nobody Mon Aug 28 06:30:09 2017
Return-Path: 
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 C11771329F9 for ; Mon, 28 Aug 2017 06:30:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 snNqk4QjXN1v for ; Mon, 28 Aug 2017 06:30:04 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 A70F3124B18 for ; Mon, 28 Aug 2017 06:30:02 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:509a:2bff:fe5b:b691]) by mail.nic.cz (Postfix) with ESMTPSA id 557CB620C4; Mon, 28 Aug 2017 15:30:00 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1503927000; bh=2jxjCtIG+Hva/OzfX37u5296FZLk3XwkbsMdP1c6KRI=; h=From:To:Date; b=h4fqdcL9tX+ve8qLHqkDFf3hXXWPm7qC6V5AaI9nzw3RyDxXynrCUjNp4aYq/JQ30 QJKLaZoZIRFj+1qgwMLnNQlFv5a97HyftyE2sk7SJQaC1J/7+uCOOuMPxKligNmtoo ttYwI5n3k7tVqWLLjCUnxWMLzTUNQAoGWR6mGPjY=
Message-ID: <1503927029.1715.46.camel@nic.cz>
From: Ladislav Lhotka 
To: Lou Berger , Martin Bjorklund 
Cc: netmod@ietf.org
Date: Mon, 28 Aug 2017 15:30:29 +0200
In-Reply-To: 
References:  <20170828.122845.1527315474517128533.mbj@tail-f.com>  <20170828.133507.2047018591752852829.mbj@tail-f.com> 
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 13:30:08 -0000

Lou Berger píše v Po 28. 08. 2017 v 08:54 -0400:
> 
> On 8/28/2017 7:35 AM, Martin Bjorklund wrote:
> > Lou Berger  wrote:
> > > Martin,
> > > 	See below.
> > > 
> > > On 08/28/2017 06:28 AM, Martin Bjorklund wrote:
> > > > Lou Berger  wrote:
> > > > > Martin,
> > > > > See below
> > > > > 
> > > > > 
> > > > > On August 23, 2017 2:28:37 AM Martin Bjorklund  wrote:
> > > > > 
> > > > > > Lou Berger  wrote:
> > > > > > > Hi Martin,
> > > > > > > 
> > > > > > > See below.
> > > > > > > 
> > > > > > > 
> > > > > > > On 8/22/2017 6:20 AM, Martin Bjorklund wrote:
> > > > > > > > Hi,
> > > > > > > > 
> > > > > > > > Lada presented an open issue in schema mount in Prague.  (See slide 6
> > > > > > > > in
> > > > > > > > 
> > > > > > > 
> > > > > > > https://datatracker.ietf.org/meeting/99/materials/slides-99-netmod-sessb-schema-mount)
> > > > > > > > The original problem comes from the NI use case
> > > > > > > > (https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model).  In this
> > > > > > > > use case, interfaces are assigned to NIs by:
> > > > > > > > 
> > > > > > > >    augment /if:interfaces/if:interface:
> > > > > > > >      +--rw bind-ni-name?   -> /network-instances/network-instance/name
> > > > > > > > 
> > > > > > > > Modules that are mounted within the NI might have references to
> > > > > > > > interfaces.  The idea is that a specific NI can only reference the
> > > > > > > > interfaces that has been assigned to it.
> > > > > > > > 
> > > > > > > > In schema mount, we have the "parent-reference" XPath expression that
> > > > > > > > in this case will be "/if:interfaces/if:interface".  The problem is
> > > > > > > > that this XPath expression will evaluate to a node set that contains
> > > > > > > > *all* interfaces in the system.  We would like this to contain just
> > > > > > > > the interfaces assigned to the NI.
> > > > > > > > 
> > > > > > > > It turns out that this can be done with a simple change to the
> > > > > > > > "parent-reference" node.  If we state that this XPath expression is
> > > > > > > > evaluated in an XPath context where the context node is the node in
> > > > > > > > the data tree where the mount point is defined (instead of "/"), we
> > > > > > > > can use as parent-reference:
> > > > > > > > 
> > > > > > > >   /if:interfaces/if:interface[ni:bind-network-instance-name = ../ni:name]
> > > > > > > > 
> > > > > > > > Putting this together we'd have:
> > > > > > > > 
> > > > > > > >   augment "/if:interfaces/if:interface" {
> > > > > > > >     leaf bind-ni-name {
> > > > > > > >       type leafref {
> > > > > > > >         path "/network-instances/network-instance/name";
> > > > > > > >       }
> > > > > > > >     }
> > > > > > > >   }
> > > > > > > > 
> > > > > > > >   container network-instances {
> > > > > > > >     list network-instance {
> > > > > > > >       key name;
> > > > > > > >       leaf name { ... }
> > > > > > > >       ...
> > > > > > > >       container root {
> > > > > > > >         // this would be the XPath context root for parent-reference
> > > > > > > >         yangmnt:mount-point ni-root;
> > > > > > > >       }
> > > > > > > >     }
> > > > > > > >   }
> > > > > > > 
> > > > > > > note that the current NI definition is:
> > > > > > 
> > > > > > Yes I saw that.
> > > > > > 
> > > > > > >    module: ietf-network-instance
> > > > > > >      +--rw network-instances
> > > > > > >         +--rw network-instance* [name]
> > > > > > >            +--rw name           string
> > > > > > >            +--rw enabled?       boolean
> > > > > > >            +--rw description?   string
> > > > > > >            +--rw (ni-type)?
> > > > > > >            +--rw (root-type)?
> > > > > > >               +--:(vrf-root)
> > > > > > >               |  +--mp vrf-root?
> > > > > > >               +--:(vsi-root)
> > > > > > >               |  +--mp vsi-root?
> > > > > > >               +--:(vv-root)
> > > > > > >                  +--mp vv-root?
> > > > > > 
> > > > > > Note that the extension yangmnt:mount-point can only be present in a
> > > > > > container or list, not in a choice/case.
> > > > > 
> > > > > Okay, I missed that restriction in your draft.  What's the reason for
> > > > > not allowing mounts under choices/cases?  Isn't the resulting path to
> > > > > data nodes indistinguishable when the parent is a list or container?
> > > > 
> > > > Suppose a server lists a couple of modules for "vrf-root" and some
> > > > other for "vsi-root" in the /schema-mounts/mount-point list.  How can
> > > > a client tell if a certain NI instance is has the "vrf" modules or
> > > > "vsi" modules?
> > > 
> > > umm, my understanding is that only one of the cases under a choice can
> > > be present in the data (tree) at a time so the client *can* only see one
> > >  mount point {vrf-root, vsi-root or vv-root} node and all the mounted
> > > schemas will be under that '-root' node.  What have I missed?
> > 
> > The mount point itself is not a node.  
> 
> okay, I think we're getting to the crux of this issue!  I certainly
> didn't see this (that a schema-mount root node is *not* represented in
> the data, but only in the schema) stated in
> draft-ietf-netmod-schema-mount.  In fact, I read the text as saying just
> the opposite:

I don't think so, it just says that an (existing) node in the parent schema gets
the mount-point label. The mount-point extension itself generates no extra node.

If we used schema node identifiers denoting the mount points instead of the
extension (as I proposed earlier), there would be no additions to the schema
proper, so this confusion couldn't arise.

> 
>    The basic idea of schema mount is to label a data node in the parent
>    schema as the mount point, and then define a complete data model to
>    be attached to the mount point so that the labeled data node
>    effectively becomes the root node of the mounted data model.
> 
> Why don't you think an MP should be represented in the data (tree)?
> 
> In our example usage
> (https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B) we
> include the mount point as a node in the data.  You're saying that this
> doesn't line up with your expectation, right?
> 
> Can you please take a look at it and see if we have any other disconnects?

This is really scary. How can we expect poor data modellers to understand the
concept if we have such fundamental disconnects, after so many hours of
discussing it?

Lada

> 
> > So the client will just see
> > some mounted top-level nodes.  If you require that all mount points
> > have disjoint sets of modules, then this could work.  But I assume
> > that this is not the case.
> 
> 
> 
> Lou
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Mon Aug 28 06:40:39 2017
Return-Path: 
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 AE37C13292B for ; Mon, 28 Aug 2017 06:40:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 b7p6yqNCtxt1 for ; Mon, 28 Aug 2017 06:40:36 -0700 (PDT)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 3362313234E for ; Mon, 28 Aug 2017 06:40:36 -0700 (PDT)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 1FCE31E0CA9 for ; Mon, 28 Aug 2017 07:40:28 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id 2dgR1w00k2SSUrH01dgU5M; Mon, 28 Aug 2017 07:40:28 -0600
X-Authority-Analysis: v=2.2 cv=F98nTupN c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=KeKAF7QvOSUA:10 a=jaZ_GjIonMUI_OeF4boA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=grhOoEHLf+QyP6+5mfTu9lGtWQIgBYrXPpkJsUOwY4M=; b=xYXODxmUJGRO0Q2ozCUzjqWnTv XXG0EaG+k0cZTDzo2l+Q2oLWkAnTZm//iNGpdOiuWCU9YqFZAS+xDrJr0Hi2TzHqA2tds9JqU99wv JPusxD3WIypTDrt6IBV4J2FSz;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:47652 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dmKHB-004LKN-0h; Mon, 28 Aug 2017 07:40:25 -0600
To: Ladislav Lhotka , Martin Bjorklund 
Cc: netmod@ietf.org
References:  <20170828.122845.1527315474517128533.mbj@tail-f.com>  <20170828.133507.2047018591752852829.mbj@tail-f.com>  <1503927029.1715.46.camel@nic.cz>
From: Lou Berger 
Message-ID: <7c99497f-d719-0fe2-01f5-a06d53c8fc68@labn.net>
Date: Mon, 28 Aug 2017 09:40:15 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <1503927029.1715.46.camel@nic.cz>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dmKHB-004LKN-0h
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:47652
X-Source-Auth: lberger@labn.net
X-Email-Count: 6
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 13:40:38 -0000

Lada,

On 8/28/2017 9:30 AM, Ladislav Lhotka wrote:
>> Can you please take a look at it and see if we have any other disconnects?
> This is really scary. 
I agree!

> How can we expect poor data modellers to understand the
> concept if we have such fundamental disconnects, after so many hours of
> discussing it?

This highlights why getting the text in (any) document is so important,
and why discussions shouldn't be viewed as being closed until the impact
on the text is agreed to!

Lou

PS is your view aligned with martin or our example?

> Lada
>


From nobody Mon Aug 28 07:15:55 2017
Return-Path: 
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 EBB3B1321ED for ; Mon, 28 Aug 2017 07:15:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level: 
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 RcGubT7QrXxd for ; Mon, 28 Aug 2017 07:15:51 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 A8F12132076 for ; Mon, 28 Aug 2017 07:15:51 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:509a:2bff:fe5b:b691]) by mail.nic.cz (Postfix) with ESMTPSA id 35340623B2; Mon, 28 Aug 2017 16:15:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1503929750; bh=K0XpsMLkHrvz4WvxeWN+6LHEbAupyRavD7ez2qURYhM=; h=From:To:Date; b=qD1vq7Q09ewkwoA99qk092Mtd4Jg6sy9Htn4SNYR2+C1LwGC4iDeiSQBtS0eWIZjY f7yD8PMHmmVGwx8MTfcakSdx3+8XMSEEyJMRDoikaQWJ9izpPlHLCOMaRTLCKwYsMM ShRKaaANFr1j4Z040M+gM4Qupbm0ul++xmkKhLeY=
Message-ID: <1503929779.1715.65.camel@nic.cz>
From: Ladislav Lhotka 
To: Lou Berger , Martin Bjorklund 
Cc: netmod@ietf.org
Date: Mon, 28 Aug 2017 16:16:19 +0200
In-Reply-To: <7c99497f-d719-0fe2-01f5-a06d53c8fc68@labn.net>
References:  <20170828.122845.1527315474517128533.mbj@tail-f.com>  <20170828.133507.2047018591752852829.mbj@tail-f.com>  <1503927029.1715.46.camel@nic.cz> <7c99497f-d719-0fe2-01f5-a06d53c8fc68@labn.net>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 14:15:54 -0000

Lou Berger píše v Po 28. 08. 2017 v 09:40 -0400:
> Lada,
> 
> On 8/28/2017 9:30 AM, Ladislav Lhotka wrote:
> > > Can you please take a look at it and see if we have any other disconnects?
> > 
> > This is really scary. 
> 
> I agree!
> 
> > How can we expect poor data modellers to understand the
> > concept if we have such fundamental disconnects, after so many hours of
> > discussing it?
> 
> This highlights why getting the text in (any) document is so important,
> and why discussions shouldn't be viewed as being closed until the impact
> on the text is agreed to!

I think many people still don't make much distinction between schema mount
(manipulation of the schema) and data mount. I still believe we need to clearly
separate these two concepts, preferably using two different mechanisms.

Moreover, draft-clemm-netmod-mount-06 adds heavily to this confusion. I myself
feel dizzy when reading e.g. this:

     extension mountpoint {
       argument name;
       description
         "This YANG extension is used to mount data from another
          subtree in place of the node under which this YANG extension
          statement is used.
          ..."

See? The data has to be placed to a *data tree*, and the extension is used in
the *schema tree*, but the description talks about just one node.

> 
> Lou
> 
> PS is your view aligned with martin or our example?

If you mean shifting the XPath context node to the mount point instance, then
yes.

Lada

> 
> > Lada
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Mon Aug 28 08:46:46 2017
Return-Path: 
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 49AC3132355 for ; Mon, 28 Aug 2017 08:46:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 sFUDVvu7iaXY for ; Mon, 28 Aug 2017 08:46:43 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8663126C7A for ; Mon, 28 Aug 2017 08:46:42 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id C09D2F38; Mon, 28 Aug 2017 17:46:41 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id rcjfjpIbQwDb; Mon, 28 Aug 2017 17:46:36 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 28 Aug 2017 17:46:41 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9E070200E0; Mon, 28 Aug 2017 17:46:41 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id f-zZSBRYLFve; Mon, 28 Aug 2017 17:46:41 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 352A7200AA; Mon, 28 Aug 2017 17:46:41 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id F356C40669D9; Mon, 28 Aug 2017 17:46:40 +0200 (CEST)
Date: Mon, 28 Aug 2017 17:46:40 +0200
From: Juergen Schoenwaelder 
To: Xufeng Liu 
Cc: Per Hedeland , Ladislav Lhotka , "'netmod@ietf.org'" 
Message-ID: <20170828154640.pzg7jfy5uepkb22q@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Xufeng Liu , Per Hedeland , Ladislav Lhotka , "'netmod@ietf.org'" 
References:  <20170824060900.u5kcffzvwjr7mmob@elstar.local> <152f24b2-7947-9c76-714c-af226ab3fe91@tail-f.com> <8760ddc676.fsf@nic.cz> <599F0991.7020900@tail-f.com>  <20170825125254.6nhnzkrar6fhu7zr@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 15:46:45 -0000

On Mon, Aug 28, 2017 at 12:58:59PM +0000, Xufeng Liu wrote:
> 
> [Xufeng] [0..9] is still compliant with the XSD pattern specified by
> YANG 1.0 and 1.1. Using [0..9] instead of [\d] will make the
> implementations with native POSIX RegEx easier without the need for
> a tool to inspect every element of the RegEx pattern.

Yes, but then \d is legal in YANG (and it is used in a couple of
published RFCs).

Educating _all_ module authors to write [0..9] instead of \d will
likely be more expensive than improving the code of implementations
that did not implement YANG entirely to accept \d.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Aug 28 09:24:27 2017
Return-Path: 
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 5A91F1321B8 for ; Mon, 28 Aug 2017 09:24:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 My6YES9IpBfc for ; Mon, 28 Aug 2017 09:24:21 -0700 (PDT)
Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EB001321B6 for ; Mon, 28 Aug 2017 09:24:20 -0700 (PDT)
Received: by mail-wr0-x22a.google.com with SMTP id j29so2231420wre.2 for ; Mon, 28 Aug 2017 09:24:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=jLXU+pYAp568/5HI9/DA1ncRhXSHU/huVZubjvURskk=; b=itKXdEjGPR1YsGZFMTESAHCnVjlGnO3eVOi0bIvI8ysyMIwj4ctdUrXFcwBL4dL7qT JuOzl7k4QXA24GEnWmNEjj5G4Fug9Nv+mG9U4hi91w4VW73kiL4UoFab/BnRFnmhM16F 31Kufjzyjq+uGIgE7OuIkP5aLQyatXmBB+Yl33WjFT7l6+El8fmYQX0lNajF4zZZGV1P O9Tnvio8L7NtHMO+zPke1dilL7bn50iv79+ZMLxAlURneYXQwmxpcd/aGRKjhnUbrF54 9S6ACCT3hvxRSAkoofhObELxyixY+ezdyhV53yRl4WmV0vMGGVXJJA/0inbbu5qVT2Ck SYFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=jLXU+pYAp568/5HI9/DA1ncRhXSHU/huVZubjvURskk=; b=FIcYEOduN+0latJg96Zb1Pk1dXjThx9U/TMzL8k1QNb5PRkXHcCFmkolBBkF1jHzN3 092w8HayH35Rv5yPPkMD5X6gZ/9/JqdxnWeT0OR8zNGSqBRZgVAODLu48NwJnOIEc3rA n/QeRVF9UFKdCywx532R8V4hwtyelPl4PBBgA1ookthV2mmwBTtFFFrmBWYbm1seI0sB AvqPc2iFdeeAETdme/uWrLozpCnhbMfirC1aq4mT5ig2Tbs+YZddCh4lStdd+Hz6nSg7 eHdKh4lFAWe47z0jBNNocUkxfWkNu1GDQnGWnzestzpE+gHW4YEgDC3edb1xVunRHG6N 9deA==
X-Gm-Message-State: AHYfb5geyROn4Gc7uJMs7xdJU9QrhaANnu9nBs2d1FL7j+6uJIhqWm3V GZukBJmUbS7WdqaRzSwSQpQaoHRR9vfrN2U=
X-Received: by 10.223.142.237 with SMTP id q100mr862878wrb.228.1503937458544;  Mon, 28 Aug 2017 09:24:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.221 with HTTP; Mon, 28 Aug 2017 09:24:17 -0700 (PDT)
In-Reply-To: <20170828101111.bedfkeoxw3xcj4ex@elstar.local>
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local>      <20170828101111.bedfkeoxw3xcj4ex@elstar.local>
From: Andy Bierman 
Date: Mon, 28 Aug 2017 09:24:17 -0700
Message-ID: 
To: Juergen Schoenwaelder , Andy Bierman ,  Kent Watsen , Lou Berger ,  "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="f403045f51a2fb333c0557d2b943"
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 16:24:25 -0000

--f403045f51a2fb333c0557d2b943
Content-Type: text/plain; charset="UTF-8"

On Mon, Aug 28, 2017 at 3:11 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Sun, Aug 27, 2017 at 06:08:28PM -0700, Andy Bierman wrote:
> > Hi,
> >
> > Here is the proposed rewrite of 4.23.
> > I changed a few details in the temporary non-NMDA procedure.
> > This module cannot duplicate the NMDA module as read-only.
> > Only the top-level config=false nodes that would have been exposed
> pre-NMDA
> > need to be present.
>
> Thanks for taking the time to produce detailed text. Some comments
> inline.
>
> > 4.23.  Operational State
> >
> >    The management of YANG operational state has been refined over time.
>
> I think you mean:
>
>   The modeling of operational state with YANG has been refied over time.
>
>

fixed



> >    At first, only data that has a "config" statement value of "false"
> >    was considered to be operational state.  This data was not considered
> >    to be part of any datastore, which made YANG XPath definition much
> >    more complicated.
> >
> >    YANG operational state is now modeled according to new NMDA, and is
>
> I think we do not have the term 'YANG operational state'. Hence:
>
>   Operational state is now modeled using YANG according to ...
>
>
fixed



> >    now conceptually contained in the operational datastore, which also
> >    includes the operational values of configuration data.  There is no
> >    longer any need to duplicate data structures to provide separate
> >    configuration and operational data sections.
> >
> >    This section describes some data modeling issues related to
> >    operational state, and guidelines for transitioning YANG data model
> >    design to be NMDA-compatible.
> >
> > 4.23.1.  Combining Operational State and Configuration Data
> >
> >    If possible, operational state SHOULD be combined with its associated
> >    configuration data.  This prevents duplication of key leafs and
> >    ancestor nodes.  It also prevents race conditions for retrieval of
> >    dynamic entries, and allows configuration and operational state to be
> >    retrieved together with minimal message overhead.
> >
> >    Not NMDA-Compliant:
> >
> >       container foo {
> >         ...
> >       }
> >
> >       container foo-state {
> >         config false;
> >         ...
> >       }
> >
> >    NMDA-Compliant:
> >
> >       container foo {
> >         ...
> >         // contains config=true and config=false nodes that have
> >         // no corresponding config=true object (e.g., counters)
> >       }
> >
> > 4.23.2.  Representing Operational Values of Configuration Data
> >
> >    If possible the same data type SHOULD be used to represent the
> >    configured value and the operational value, for a given leaf or leaf-
> >    list object.
> >
> >    Sometimes the configured value set is different than the operational
> >    value set for that object.  For example, the "admin-state" and
> >    "oper-state" leafs in [RFC7223].  In this case a separate object MAY
> >    be used to represent the configured and operational values.
> >
> >    Sometimes the list keys are not identical for configuration data and
> >    the corresponding operational state.  In this case separate lists MAY
> >    be used to represent the configured and operational values.
> >
> >    If it is not possible to combine configuration and operational state,
> >    then the keys used to represent list entries SHOULD be the same type.
> >    The "leafref" data type SHOULD be used in operational state for key
> >    leafs that have corresponding configuration instances.  The
> >    "require-instance" statement MAY be set to "false" (in YANG 1.1
> >    modules only) to indicate instances are allowed in the operational
> >    state that do not exist in the associated configuration data.
> >
> >    If all the data model properties are aligned between configuration
> >    data and operational state, then it can be useful to define the
> >    configuration parameters within a grouping, and then replicate that
> >    grouping within the operational state portion of the data model.
> >
> >        grouping parms {
> >           // do not use config-stmt in any of the nodes
> >           // placed in this grouping
> >        }
> >
> >        container bar { // bar config can exist without bar-state
> >          config true;
> >          uses parms;
> >        }
> >
> >        container bar-state {  // bar-state can exist without bar
> >          status deprecated;
> >          config false;
> >          uses parms;
> >        }
> >
> >    The need to replicate objects or define different operational state
> >    objects depends on the data model.  It is not possible to define one
> >    approach that will be optimal for all data models.
>
> Well, having bar (config true) and bar-state (config false) is what
> NMDA tries to avoid. Even in NMDA, bar can exist in 
> without having  in say . (Example, no IP addresses
> statically configured but IP addresses learned from DHCP or created by
> the system.) I am not sure the discussion starting with "If all the
> data model properties" is needed.
>
>
removed "If all the data" .. through groupings example



> >    Designers SHOULD describe and justify any NMDA exceptions in detail,
> >    such as the use of separate subtrees and/or separate leafs.  The
> >    "description" statements for both the configuration and the
> >    operational state SHOULD be used for this purpose.
> >
> > 4.23.3.  NMDA Transition Guidelines
> >
> >    YANG modules SHOULD be designed assuming they will be used on servers
> >    supporting the operational datastore.  With this in mind, YANG
>
> It is actually called the 'operational state datastore'.
>


Except that we never use that term.
It is always called operational datastore when we talk about it in meetings.
Hence, the new NMDA terms section:

 ** NMDA Terms

The following terms are defined in the
Network Management Datastore Architecture
(NMDA) ^I-D.ietf-netmod-revised-datastores^.
and are not redefined here:

- configuration
- conventional configuration datastore (also called conventional datastore)
- datastore
- operational state
- operational state datastore (also called operational datastore)

IMO these alternates should be put in the RD draft since they reflect the
terms we actually use.


> >    modules SHOULD define config "false" wherever they make sense to the
> >    data model.  Config "false" nodes SHOULD NOT be defined to provide
> >    the operational value for configuration nodes, except when the value
> >    space of a configured and operational values may differ, in which
> >    case a distinct config "false" node SHOULD be defined to hold the
> >    operational value for the configured node.
>
> Perhaps the text needs to say somewhere very clearly that the
> operationally used values of configuration objects are part of the
> operational state datastore and hence config false nodes SHOULD NOT be
> defined to provide the operational value for configuration nodes...
>


I think the text from Lou is OK.


>
> >    The following guidelines are meant to help modelers develop YANG
> >    models that will maximize the utility of the model with both current
> >    and new implementations.
>
> Do we generally talk about YANG modules or YANG models in the guidelines
> document? Are these used as synonyms? Just wondering...
>


changed models to modules. -- here and several other places




>
> >    New models and models that are not concerned with the operational
> >    state of configuration information SHOULD immediately be structured
> >    to be NMDA-compatible, as described in Section 4.23.1.
> >
> >    The remaining are options that MAY be followed during the time that
> >    NMDA mechanisms are being defined.
> >
> >    (a) Models that require immediate support for the NMDA "origin" meta
> >    data, such as "in use" and "system created" information, SHOULD be
> >    structured for NMDA.
>
> Not sure I parsed this correctly. What does 'in use' and 'system
> created' information refer to? I think in general models should follow
> NMDA (once it went through the approval process), no?
>

This is from Lou. I just pasted in his text here, but added the origin
metadata part.
See new fix below.



>
> >    A non-NMDA version of these models SHOULD
> >    exist, either an existing model or a model created either by hand or
> >    with suitable tools that mirror the current modeling strategies.
> >    Both the NMDA and the non-NMDA modules SHOULD be published in the
> >    same document, with NMDA modules in the document main body and the
> >    non-NMDA modules in a non-normative appendix.  The use of the non-
> >    NMDA model will allow temporary bridging of the time period until
> >    NMDA implementations are available.
>
> I do not think that it is always a SHOULD to have a non-NMDA model but
> then I did not understand the condition of (a). RFC 8194 for instance
> is NMDA compatible and this is good enough. If an implementation needs
> to expose applied configuration, it will have to implement NMDA.
>

Please do implement it -- especially the client-side, which got much more
complex
because of NMDA.

I think the first sentence refers to the temporary non-NMDA module.

NEW:

(a) Modules that require immediate support for the NMDA features
SHOULD be structured for NMDA.  A temporary non-NMDA version of these
models SHOULD exist, either an
existing model or a model created either by hand or with
suitable tools that mirror the current modeling strategies.



> >    (b) For published models, the model should be republished with an
> >    NMDA-compatible structure, deprecating non-NMDA constructs.  For
> >    example, the "ietf-interfaces" model in [RFC7223] will be
> >    restructured as an NMDA-compatible model.  The "/interfaces-state"
> >    hierarchy will be marked "status deprecated".  Models that mark their
> >    "/foo-state" hierarchy with "status deprecated" will allow NMDA-
> >    capable implementations to avoid the cost of duplicating the state
> >    nodes, while enabling non-NMDA-capable implementations to utilize
> >    them for access to the operational values.
> >
> >    (c) For models that augment models which have not been structured
> >    with the NMDA, the modeler will have to consider the structure of the
> >    base model and the guidelines listed above.  Where possible, such
> >    models should move to new revisions of the base model that are NMDA-
> >    compatible.  When that is not possible, augmenting "state" containers
> >    SHOULD be avoided, with the expectation that the base model will be
> >    re-released with the state containers marked as deprecated.  It is
> >    RECOMMENDED to augment only the "/foo" hierarchy of the base model.
> >    Where this recommendation cannot be followed, then any new "state"
> >    elements SHOULD be included in their own module.
> >
> > 4.23.3.1.  Temporary non-NMDA Modules
> >
> >    A temporary non-NMDA module allows a non-NMDA aware client to access
> >    operational state from an NMDA-compliant server.  It contains the
> >    top-level config=false data nodes that would have been defined in a
> >    legacy YANG module (before NMDA).
> >
> >    A server that needs to support both NMDA and non-NMDA clients can
> >    advertise both the new NMDA module and the temporary non-NMDA module.
> >    A non-NMDA client can use separate "foo" and "foo-state" subtrees,
> >    except the "foo-state" subtree is located in a different (temporary)
> >    module.  The NMDA module can be used by a non-NMDA client to access
> >    the conventional datastores, and the deprecated  operation to
> >    access nested config=false data nodes.
> >
> >    To create the temporary non-NMDA model from an NMDA model, the
> >    following steps can be taken:
> >
> >    o  Change the module name by appending "-state" to the original
> >       module name
> >
> >    o  Change the namespace by appending "-state" to the original
> >       namespace value
> >
> >    o  Change the prefix by appending "-s" to the original prefix value
> >
> >    o  Add an import to the original module (e.g., for typedef
> >       definitions)
> >
> >    o  Retain or create only the top-level nodes that have a "config"
> >       statement value "false".  These subtrees represent config=false
> >       data nodes that were combined into the configuration subtree, and
> >       therefore not available to non-NMDA aware clients.  Set the
> >       "status" statement to "deprecated" for each new node.
> >
> >    o  The module description SHOULD clearly identify the module as a
> >       temporary non-NMDA module
> >
> > 4.23.3.2.  NMDA Module Examples
> >
> >    Example: Create a New Module
> >
> >    Create an NMDA-compliant module, using combined configuration and
> >    state subtrees, whenever possible.
> >
> >      module example-foo {
> >        namespace "urn:example.com:params:xml:ns:yang:example-foo";
> >        prefix "foo-";
> >
> >        container foo {
> >          // configuration data child nodes
> >          // operational value in operational datastore only
> >          // may contain config=false nodes as needed
> >        }
> >     }
>
> Why would the prefix be "foo-" and not just "foo"?
>
> >    Example: Convert an old Non-NMDA Module
> >
> >    Do not remove non-complaint objects from existing modules.  Instead,
>
> compliant
>
>
fixed



> >    change the status to "deprecated".  At some point, usually after 1
> >    year, the status MAY be changed to "obsolete".
> >
> >    Old Module:
> >
> >      module example-foo {
> >        namespace "urn:example.com:params:xml:ns:yang:example-foo";
> >        prefix "foo";
> >
> >        container foo {
> >          // configuration data child nodes
> >        }
> >
> >        container foo-state {
> >          config false;
> >          // operational state child nodes
> >        }
> >     }
> >
> >    Converted NMDA Module:
> >
> >      module example-foo {
> >        namespace "urn:example.com:params:xml:ns:yang:example-foo";
> >        prefix "foo-";
>
> "foo-" vs "foo"
>

fixed


>
> >        container foo {
> >          // configuration data child nodes
> >          // operational value in operational datastore only
> >          // may contain config=false nodes as needed
> >          // will contain any data nodes from old foo-state
> >        }
> >
> >        // keep original foo-state but change status to deprecated
> >        container foo-state {
> >          config false;
> >          status deprecated;
> >          // operational state child nodes
> >        }
> >     }
> >
> >    Example: Create a Temporary NMDA Module:
> >
> >    Create a new module that contains the top-level operational state
> >    data nodes that would have been available before they were combined
> >    with configuration data nodes (to be NMDA compliant).
> >
> >      module example-foo-state {
> >        namespace "urn:example.com:params:xml:ns:yang:example-foo-state";
> >        prefix "foo-s";
> >
> >        // import new or converted module; not used in this example
> >        import example-foo { prefix foo; }
> >
> >        container foo-state {
> >          config false;
> >          status deprecated;
> >          // operational state child nodes
> >        }
> >     }
>
> Perhaps put the examples in separate sections 4.23.3.2, 4.23.3.3,
> 4.23.3.4 so that they are more clearly separated?
>
>
OK


> >
> > Andy
> >
>



Andy




> >
> >
> > On Fri, Aug 25, 2017 at 12:31 PM, Andy Bierman 
> wrote:
> >
> > >
> > >
> > > On Fri, Aug 25, 2017 at 12:11 PM, Kent Watsen 
> wrote:
> > >
> > >>
> > >>
> > >>
> > >>
> > >> On 8/25/17, 2:21 PM, "Andy Bierman"  wrote:
> > >>
> > >>
> > >>
> > >> > Obviously NMDA cannot be used for objects where the configuration
> value
> > >> set
> > >>
> > >> > and the operstate value set differ, such as with the interface
> > >> admin-status/oper-status.
> > >>
> > >> > Do you want a sentence added that says to use config false leafs as
> > >> needed within the
> > >>
> > >> > configuration entry? A sentence that says operational data is
> embedded
> > >> in the
> > >>
> > >> > configuration entry?
> > >>
> > >>
> > >>
> > >> Yes, and any other general guidelines around using config false.   The
> > >> text I posted
> > >>
> > >> when starting this thread had some of that.  The original RFC6087 text
> > >> might have
> > >>
> > >> some more.
> > >>
> > >>
> > >>
> > >
> > > OK -- I will work on adding in text from -12, your text, and Lou's
> text.
> > >
> > >
> > >>
> > >> > 6087bis was supposed to be a minor update, not a living draft that
> > >> doubles
> > >>
> > >> > as a YANG tutorial and ongoing issues list.
> > >>
> > >>
> > >>
> > >>  ;)
> > >>
> > >>
> > >>
> > >> As much as I like RFCs, I think this content would be better served
> by a
> > >> Wiki.   If
> > >>
> > >> we were starting for scratch (no RFC6087), then that might make sense
> > >> but, given
> > >>
> > >> where we are, not so much.  So, I guess we're committed to frequent
> > >> updates on this
> > >>
> > >> document until YANG settles down.
> > >>
> > >>
> > >>
> > >
> > > It is better to have as few moving targets (and normative references)
> as
> > > possible.
> > > YANG modules in an RFC have to conform to a specific version of the
> YANG
> > > guidelines.
> > >
> > >
> > >>
> > >>
> > >> Kent // contributor
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > > Andy
> > >
> > >
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>

--f403045f51a2fb333c0557d2b943
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Aug 28, 2017 at 3:11 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Sun, Aug 27, 2017 at 06:08:28P=
M -0700, Andy Bierman wrote:

> Hi,

>

> Here is the proposed rewrite of 4.23.

> I changed a few details in the temporary non-NMDA procedure.

> This module cannot duplicate the NMDA module as read-only.

> Only the top-level config=3Dfalse nodes that would have been exposed p=
re-NMDA

> need to be present.



Thanks for taking the time to produce detailed text. Some comments

inline.



> 4.23.=C2=A0 Operational State

>

>=C2=A0 =C2=A0 The management of YANG operational state has been refined=
 over time.



I think you mean:



=C2=A0 The modeling of operational state with YANG has been refied over tim=
e.




fixed

=C2=A0

>=C2=A0 =C2=A0 At first, only data that has a "config" stateme=
nt value of "false"

>=C2=A0 =C2=A0 was considered to be operational state.=C2=A0 This data w=
as not considered

>=C2=A0 =C2=A0 to be part of any datastore, which made YANG XPath defini=
tion much

>=C2=A0 =C2=A0 more complicated.

>

>=C2=A0 =C2=A0 YANG operational state is now modeled according to new NM=
DA, and is



I think we do not have the term 'YANG operational state'. Hence:


=C2=A0 Operational state is now modeled using YANG according to ...



fixed

=C2=A0<=
/div>

>=C2=A0 =C2=A0 now conceptually contained in the operational datastore, =
which also

>=C2=A0 =C2=A0 includes the operational values of configuration data.=C2=
=A0 There is no

>=C2=A0 =C2=A0 longer any need to duplicate data structures to provide s=
eparate

>=C2=A0 =C2=A0 configuration and operational data sections.

>

>=C2=A0 =C2=A0 This section describes some data modeling issues related =
to

>=C2=A0 =C2=A0 operational state, and guidelines for transitioning YANG =
data model

>=C2=A0 =C2=A0 design to be NMDA-compatible.

>

> 4.23.1.=C2=A0 Combining Operational State and Configuration Data

>

>=C2=A0 =C2=A0 If possible, operational state SHOULD be combined with it=
s associated

>=C2=A0 =C2=A0 configuration data.=C2=A0 This prevents duplication of ke=
y leafs and

>=C2=A0 =C2=A0 ancestor nodes.=C2=A0 It also prevents race conditions fo=
r retrieval of

>=C2=A0 =C2=A0 dynamic entries, and allows configuration and operational=
 state to be

>=C2=A0 =C2=A0 retrieved together with minimal message overhead.

>

>=C2=A0 =C2=A0 Not NMDA-Compliant:

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0container foo {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...

>=C2=A0 =C2=A0 =C2=A0 =C2=A0}

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0container foo-state {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0config false;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...

>=C2=A0 =C2=A0 =C2=A0 =C2=A0}

>

>=C2=A0 =C2=A0 NMDA-Compliant:

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0container foo {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// contains config=3Dtrue and config=
=3Dfalse nodes that have

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// no corresponding config=3Dtrue obj=
ect (e.g., counters)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0}

>

> 4.23.2.=C2=A0 Representing Operational Values of Configuration Data
>

>=C2=A0 =C2=A0 If possible the same data type SHOULD be used to represen=
t the

>=C2=A0 =C2=A0 configured value and the operational value, for a given l=
eaf or leaf-

>=C2=A0 =C2=A0 list object.

>

>=C2=A0 =C2=A0 Sometimes the configured value set is different than the =
operational

>=C2=A0 =C2=A0 value set for that object.=C2=A0 For example, the "a=
dmin-state" and

>=C2=A0 =C2=A0 "oper-state" leafs in [RFC7223].=C2=A0 In this =
case a separate object MAY

>=C2=A0 =C2=A0 be used to represent the configured and operational value=
s.

>

>=C2=A0 =C2=A0 Sometimes the list keys are not identical for configurati=
on data and

>=C2=A0 =C2=A0 the corresponding operational state.=C2=A0 In this case s=
eparate lists MAY

>=C2=A0 =C2=A0 be used to represent the configured and operational value=
s.

>

>=C2=A0 =C2=A0 If it is not possible to combine configuration and operat=
ional state,

>=C2=A0 =C2=A0 then the keys used to represent list entries SHOULD be th=
e same type.

>=C2=A0 =C2=A0 The "leafref" data type SHOULD be used in opera=
tional state for key

>=C2=A0 =C2=A0 leafs that have corresponding configuration instances.=C2=
=A0 The

>=C2=A0 =C2=A0 "require-instance" statement MAY be set to &quo=
t;false" (in YANG 1.1

>=C2=A0 =C2=A0 modules only) to indicate instances are allowed in the op=
erational

>=C2=A0 =C2=A0 state that do not exist in the associated configuration d=
ata.

>

>=C2=A0 =C2=A0 If all the data model properties are aligned between conf=
iguration

>=C2=A0 =C2=A0 data and operational state, then it can be useful to defi=
ne the

>=C2=A0 =C2=A0 configuration parameters within a grouping, and then repl=
icate that

>=C2=A0 =C2=A0 grouping within the operational state portion of the data=
 model.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 grouping parms {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// do not use config-stmt in a=
ny of the nodes

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// placed in this grouping

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 container bar { // bar config can exist wit=
hout bar-state

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 config true;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uses parms;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 container bar-state {=C2=A0 // bar-state ca=
n exist without bar

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 status deprecated;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 config false;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uses parms;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

>

>=C2=A0 =C2=A0 The need to replicate objects or define different operati=
onal state

>=C2=A0 =C2=A0 objects depends on the data model.=C2=A0 It is not possib=
le to define one

>=C2=A0 =C2=A0 approach that will be optimal for all data models.



Well, having bar (config true) and bar-state (config false) is what

NMDA tries to avoid. Even in NMDA, bar can exist in <operational>

without having <bar> in say <running>. (Example, no IP addresse=
s

statically configured but IP addresses learned from DHCP or created by

the system.) I am not sure the discussion starting with "If all the
data model properties" is needed.



removed "If all the data" ..=
 through groupings example

=C2=A0

>=C2=A0 =C2=A0 Designers SHOULD describe and justify any NMDA exceptions=
 in detail,

>=C2=A0 =C2=A0 such as the use of separate subtrees and/or separate leaf=
s.=C2=A0 The

>=C2=A0 =C2=A0 "description" statements for both the configura=
tion and the

>=C2=A0 =C2=A0 operational state SHOULD be used for this purpose.

>

> 4.23.3.=C2=A0 NMDA Transition Guidelines

>

>=C2=A0 =C2=A0 YANG modules SHOULD be designed assuming they will be use=
d on servers

>=C2=A0 =C2=A0 supporting the operational datastore.=C2=A0 With this in =
mind, YANG



It is actually called the 'operational state datastore'.


Except that we never use that term=
.
It is always called operational datastore when we talk about it=
 in meetings.
Hence, the new NMDA terms section:

=C2=A0** NMDA Terms

The following ter=
ms are defined in the
Network Management Datastore Architecture
(NMDA) ^I-D.ietf-netmod-revised-datastores^.
and are not=
 redefined here:

- configuration
- conve=
ntional configuration datastore (also called conventional datastore)
<=
div>- datastore
- operational state
- operational state=
 datastore (also called operational datastore)

IMO=
 these alternates should be put in the RD draft since they reflect the
terms we actually use.




>=C2=A0 =C2=A0 modules SHOULD define config "false" wherever t=
hey make sense to the

>=C2=A0 =C2=A0 data model.=C2=A0 Config "false" nodes SHOULD N=
OT be defined to provide

>=C2=A0 =C2=A0 the operational value for configuration nodes, except whe=
n the value

>=C2=A0 =C2=A0 space of a configured and operational values may differ, =
in which

>=C2=A0 =C2=A0 case a distinct config "false" node SHOULD be d=
efined to hold the

>=C2=A0 =C2=A0 operational value for the configured node.



Perhaps the text needs to say somewhere very clearly that the

operationally used values of configuration objects are part of the

operational state datastore and hence config false nodes SHOULD NOT be

defined to provide the operational value for configuration nodes...


I think the text from Lou is OK=
.
=C2=A0



>=C2=A0 =C2=A0 The following guidelines are meant to help modelers devel=
op YANG

>=C2=A0 =C2=A0 models that will maximize the utility of the model with b=
oth current

>=C2=A0 =C2=A0 and new implementations.



Do we generally talk about YANG modules or YANG models in the guidelines
document? Are these used as synonyms? Just wondering...


changed models to modules. -- here and seve=
ral other places


=C2=A0



>=C2=A0 =C2=A0 New models and models that are not concerned with the ope=
rational

>=C2=A0 =C2=A0 state of configuration information SHOULD immediately be =
structured

>=C2=A0 =C2=A0 to be NMDA-compatible, as described in Section 4.23.1.
>

>=C2=A0 =C2=A0 The remaining are options that MAY be followed during the=
 time that

>=C2=A0 =C2=A0 NMDA mechanisms are being defined.

>

>=C2=A0 =C2=A0 (a) Models that require immediate support for the NMDA &q=
uot;origin" meta

>=C2=A0 =C2=A0 data, such as "in use" and "system created=
" information, SHOULD be

>=C2=A0 =C2=A0 structured for NMDA.



Not sure I parsed this correctly. What does 'in use' and 'syste=
m

created' information refer to? I think in general models should follow<=
br>
NMDA (once it went through the approval process), no?
=

This is from Lou. I just pasted in his text here, but added =
the origin metadata part.
See new fix below.

=

=C2=A0



>=C2=A0 =C2=A0 A non-NMDA version of these models SHOULD

>=C2=A0 =C2=A0 exist, either an existing model or a model created either=
 by hand or

>=C2=A0 =C2=A0 with suitable tools that mirror the current modeling stra=
tegies.

>=C2=A0 =C2=A0 Both the NMDA and the non-NMDA modules SHOULD be publishe=
d in the

>=C2=A0 =C2=A0 same document, with NMDA modules in the document main bod=
y and the

>=C2=A0 =C2=A0 non-NMDA modules in a non-normative appendix.=C2=A0 The u=
se of the non-

>=C2=A0 =C2=A0 NMDA model will allow temporary bridging of the time peri=
od until

>=C2=A0 =C2=A0 NMDA implementations are available.



I do not think that it is always a SHOULD to have a non-NMDA model but

then I did not understand the condition of (a). RFC 8194 for instance

is NMDA compatible and this is good enough. If an implementation needs

to expose applied configuration, it will have to implement NMDA.

Please do implement it -- especially the client-s=
ide, which got much more complex
because of NMDA.

<=
/div>
I think the first sentence refers to the temporary non-NMDA modul=
e.
=C2=A0
NEW:

(a) Module=
s that require immediate support for the NMDA features
SHOULD be =
structured for NMDA.=C2=A0 A temporary non-NMDA version of these
=
models SHOULD exist, either an
existing model or a model created =
either by hand or with
suitable tools that mirror the current mod=
eling strategies.





>=C2=A0 =C2=A0 (b) For published models, the model should be republished=
 with an

>=C2=A0 =C2=A0 NMDA-compatible structure, deprecating non-NMDA construct=
s.=C2=A0 For

>=C2=A0 =C2=A0 example, the "ietf-interfaces" model in [RFC722=
3] will be

>=C2=A0 =C2=A0 restructured as an NMDA-compatible model.=C2=A0 The "=
;/interfaces-state"

>=C2=A0 =C2=A0 hierarchy will be marked "status deprecated".=
=C2=A0 Models that mark their

>=C2=A0 =C2=A0 "/foo-state" hierarchy with "status deprec=
ated" will allow NMDA-

>=C2=A0 =C2=A0 capable implementations to avoid the cost of duplicating =
the state

>=C2=A0 =C2=A0 nodes, while enabling non-NMDA-capable implementations to=
 utilize

>=C2=A0 =C2=A0 them for access to the operational values.

>

>=C2=A0 =C2=A0 (c) For models that augment models which have not been st=
ructured

>=C2=A0 =C2=A0 with the NMDA, the modeler will have to consider the stru=
cture of the

>=C2=A0 =C2=A0 base model and the guidelines listed above.=C2=A0 Where p=
ossible, such

>=C2=A0 =C2=A0 models should move to new revisions of the base model tha=
t are NMDA-

>=C2=A0 =C2=A0 compatible.=C2=A0 When that is not possible, augmenting &=
quot;state" containers

>=C2=A0 =C2=A0 SHOULD be avoided, with the expectation that the base mod=
el will be

>=C2=A0 =C2=A0 re-released with the state containers marked as deprecate=
d.=C2=A0 It is

>=C2=A0 =C2=A0 RECOMMENDED to augment only the "/foo" hierarch=
y of the base model.

>=C2=A0 =C2=A0 Where this recommendation cannot be followed, then any ne=
w "state"

>=C2=A0 =C2=A0 elements SHOULD be included in their own module.

>

> 4.23.3.1.=C2=A0 Temporary non-NMDA Modules

>

>=C2=A0 =C2=A0 A temporary non-NMDA module allows a non-NMDA aware clien=
t to access

>=C2=A0 =C2=A0 operational state from an NMDA-compliant server.=C2=A0 It=
 contains the

>=C2=A0 =C2=A0 top-level config=3Dfalse data nodes that would have been =
defined in a

>=C2=A0 =C2=A0 legacy YANG module (before NMDA).

>

>=C2=A0 =C2=A0 A server that needs to support both NMDA and non-NMDA cli=
ents can

>=C2=A0 =C2=A0 advertise both the new NMDA module and the temporary non-=
NMDA module.

>=C2=A0 =C2=A0 A non-NMDA client can use separate "foo" and &q=
uot;foo-state" subtrees,

>=C2=A0 =C2=A0 except the "foo-state" subtree is located in a =
different (temporary)

>=C2=A0 =C2=A0 module.=C2=A0 The NMDA module can be used by a non-NMDA c=
lient to access

>=C2=A0 =C2=A0 the conventional datastores, and the deprecated <get&g=
t; operation to

>=C2=A0 =C2=A0 access nested config=3Dfalse data nodes.

>

>=C2=A0 =C2=A0 To create the temporary non-NMDA model from an NMDA model=
, the

>=C2=A0 =C2=A0 following steps can be taken:

>

>=C2=A0 =C2=A0 o=C2=A0 Change the module name by appending "-state&=
quot; to the original

>=C2=A0 =C2=A0 =C2=A0 =C2=A0module name

>

>=C2=A0 =C2=A0 o=C2=A0 Change the namespace by appending "-state&qu=
ot; to the original

>=C2=A0 =C2=A0 =C2=A0 =C2=A0namespace value

>

>=C2=A0 =C2=A0 o=C2=A0 Change the prefix by appending "-s" to =
the original prefix value

>

>=C2=A0 =C2=A0 o=C2=A0 Add an import to the original module (e.g., for t=
ypedef

>=C2=A0 =C2=A0 =C2=A0 =C2=A0definitions)

>

>=C2=A0 =C2=A0 o=C2=A0 Retain or create only the top-level nodes that ha=
ve a "config"

>=C2=A0 =C2=A0 =C2=A0 =C2=A0statement value "false".=C2=A0 The=
se subtrees represent config=3Dfalse

>=C2=A0 =C2=A0 =C2=A0 =C2=A0data nodes that were combined into the confi=
guration subtree, and

>=C2=A0 =C2=A0 =C2=A0 =C2=A0therefore not available to non-NMDA aware cl=
ients.=C2=A0 Set the

>=C2=A0 =C2=A0 =C2=A0 =C2=A0"status" statement to "deprec=
ated" for each new node.

>

>=C2=A0 =C2=A0 o=C2=A0 The module description SHOULD clearly identify th=
e module as a

>=C2=A0 =C2=A0 =C2=A0 =C2=A0temporary non-NMDA module

>

> 4.23.3.2.=C2=A0 NMDA Module Examples

>

>=C2=A0 =C2=A0 Example: Create a New Module

>

>=C2=A0 =C2=A0 Create an NMDA-compliant module, using combined configura=
tion and

>=C2=A0 =C2=A0 state subtrees, whenever possible.

>

>=C2=A0 =C2=A0 =C2=A0 module example-foo {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 namespace "urn:example.com:params:xml:=
ns:yang:example-foo";

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 prefix "foo-";

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 container foo {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // configuration data child nodes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // operational value in operational =
datastore only

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // may contain config=3Dfalse nodes =
as needed

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

>=C2=A0 =C2=A0 =C2=A0}



Why would the prefix be "foo-" and not just "foo"?



>=C2=A0 =C2=A0 Example: Convert an old Non-NMDA Module

>

>=C2=A0 =C2=A0 Do not remove non-complaint objects from existing modules=
.=C2=A0 Instead,



compliant



fixed

=C2=A0<=
/div>

>=C2=A0 =C2=A0 change the status to "deprecated".=C2=A0 At som=
e point, usually after 1

>=C2=A0 =C2=A0 year, the status MAY be changed to "obsolete".<=
br>
>

>=C2=A0 =C2=A0 Old Module:

>

>=C2=A0 =C2=A0 =C2=A0 module example-foo {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 namespace "urn:example.com:params:xml:=
ns:yang:example-foo";

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 prefix "foo";

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 container foo {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // configuration data child nodes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 container foo-state {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 config false;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // operational state child nodes

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

>=C2=A0 =C2=A0 =C2=A0}

>

>=C2=A0 =C2=A0 Converted NMDA Module:

>

>=C2=A0 =C2=A0 =C2=A0 module example-foo {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 namespace "urn:example.com:params:xml:=
ns:yang:example-foo";

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 prefix "foo-";



"foo-" vs "foo"

fix=
ed
=C2=A0



>=C2=A0 =C2=A0 =C2=A0 =C2=A0 container foo {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // configuration data child nodes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // operational value in operational =
datastore only

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // may contain config=3Dfalse nodes =
as needed

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // will contain any data nodes from =
old foo-state

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // keep original foo-state but change statu=
s to deprecated

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 container foo-state {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 config false;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 status deprecated;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // operational state child nodes

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

>=C2=A0 =C2=A0 =C2=A0}

>

>=C2=A0 =C2=A0 Example: Create a Temporary NMDA Module:

>

>=C2=A0 =C2=A0 Create a new module that contains the top-level operation=
al state

>=C2=A0 =C2=A0 data nodes that would have been available before they wer=
e combined

>=C2=A0 =C2=A0 with configuration data nodes (to be NMDA compliant).

>

>=C2=A0 =C2=A0 =C2=A0 module example-foo-state {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 namespace "urn:example.com:params:xml:=
ns:yang:example-foo-state";

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 prefix "foo-s";

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 // import new or converted module; not used=
 in this example

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 import example-foo { prefix foo; }

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 container foo-state {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 config false;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 status deprecated;

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // operational state child nodes

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

>=C2=A0 =C2=A0 =C2=A0}



Perhaps put the examples in separate sections 4.23.3.2, 4.23.3.3,

4.23.3.4 so that they are more clearly separated?



OK
=C2=A0

>

> Andy

>



Andy=



=C2=A0

>

>

> On Fri, Aug 25, 2017 at 12:31 PM, Andy Bierman <andy@yumaworks.com> wrote:

>

> >

> >

> > On Fri, Aug 25, 2017 at 12:11 PM, Kent Watsen <kwatsen@juniper.net> wrote:

> >

> >>

> >>

> >>

> >>

> >> On 8/25/17, 2:21 PM, "Andy Bierman" <andy@yumaworks.com> wrote:

> >>

> >>

> >>

> >> > Obviously NMDA cannot be used for objects where the conf=
iguration value

> >> set

> >>

> >> > and the operstate value set differ, such as with the int=
erface

> >> admin-status/oper-status.

> >>

> >> > Do you want a sentence added that says to use config fal=
se leafs as

> >> needed within the

> >>

> >> > configuration entry? A sentence that says operational da=
ta is embedded

> >> in the

> >>

> >> > configuration entry?

> >>

> >>

> >>

> >> Yes, and any other general guidelines around using config fal=
se.=C2=A0 =C2=A0The

> >> text I posted

> >>

> >> when starting this thread had some of that.=C2=A0 The origina=
l RFC6087 text

> >> might have

> >>

> >> some more.

> >>

> >>

> >>

> >

> > OK -- I will work on adding in text from -12, your text, and Lou&=
#39;s text.

> >

> >

> >>

> >> > 6087bis was supposed to be a minor update, not a living =
draft that

> >> doubles

> >>

> >> > as a YANG tutorial and ongoing issues list.

> >>

> >>

> >>

> >>=C2=A0 ;)

> >>

> >>

> >>

> >> As much as I like RFCs, I think this content would be better =
served by a

> >> Wiki.=C2=A0 =C2=A0If

> >>

> >> we were starting for scratch (no RFC6087), then that might ma=
ke sense

> >> but, given

> >>

> >> where we are, not so much.=C2=A0 So, I guess we're commit=
ted to frequent

> >> updates on this

> >>

> >> document until YANG settles down.

> >>

> >>

> >>

> >

> > It is better to have as few moving targets (and normative referen=
ces) as

> > possible.

> > YANG modules in an RFC have to conform to a specific version of t=
he YANG

> > guidelines.

> >

> >

> >>

> >>

> >> Kent // contributor

> >>

> >>

> >>

> >>

> >>

> >

> > Andy

> >

> >



--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>





--f403045f51a2fb333c0557d2b943--


From nobody Mon Aug 28 11:42:16 2017
Return-Path: 
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 8762D1200F3 for ; Mon, 28 Aug 2017 11:42:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 Os5rrpauZRKS for ; Mon, 28 Aug 2017 11:42:13 -0700 (PDT)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 4E716132143 for ; Mon, 28 Aug 2017 11:42:13 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 9B6AE1E0A59 for ; Mon, 28 Aug 2017 12:41:09 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id 2ih51w00l2SSUrH01ih8k4; Mon, 28 Aug 2017 12:41:09 -0600
X-Authority-Analysis: v=2.2 cv=fJ5J5dSe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=KeKAF7QvOSUA:10 a=95lr9KeUgX8SecYMb1UA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=09FWlPiIi4JTnKPy95gaxfyc3dzs+nmb07OqqDHyD80=; b=i5pkzkeynZqpaJW2sxHyoOTDYz N6tUBLaIitXHG62ViH0W1pguSYg/E6vJ/NpVUXvuS5DydlG2zApQArqDXSEntds0lwy5IfP/bbrGH x0YoBiNmSnO9zAUIY9td5pKTN;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:52440 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dmOy9-000sIW-H4; Mon, 28 Aug 2017 12:41:05 -0600
To: Andy Bierman , Juergen Schoenwaelder , Kent Watsen , "netmod@ietf.org" 
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local>      <20170828101111.bedfkeoxw3xcj4ex@elstar.local> 
From: Lou Berger 
Message-ID: <75d35cde-644b-31ac-e784-516cfc8162a1@labn.net>
Date: Mon, 28 Aug 2017 14:40:59 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dmOy9-000sIW-H4
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:52440
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 18:42:15 -0000

Hi Andy,


On 8/28/2017 12:24 PM, Andy Bierman wrote:
> > 4.23.1.  Combining Operational State and Configuration Data
> >
> >    If possible, operational state SHOULD be combined with its associated
> >    configuration data.  This prevents duplication of key leafs and
> >    ancestor nodes.  It also prevents race conditions for retrieval of
> >    dynamic entries, and allows configuration and operational state to be
> >    retrieved together with minimal message overhead.
> >
I find the inclusion of the non NMDA form in this section a bit
confusing, do you have any objection to dropping the following?

> >    Not NMDA-Compliant:
> >
> >       container foo {
> >         ...
> >       }
> >
> >       container foo-state {
> >         config false;
> >         ...
> >       }
> >

Thanks,
Lou


From nobody Mon Aug 28 11:54:15 2017
Return-Path: 
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 ABEB413291C for ; Mon, 28 Aug 2017 11:54:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 aiuLytk3elkw for ; Mon, 28 Aug 2017 11:54:11 -0700 (PDT)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C36B1321C7 for ; Mon, 28 Aug 2017 11:54:11 -0700 (PDT)
Received: by mail-wm0-x230.google.com with SMTP id u26so9118109wma.0 for ; Mon, 28 Aug 2017 11:54:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NnoQTwQ+z1Ygl5QA6HHrKblb3Nr0dbdB6O8zlLgORug=; b=kyDHmSfH0ER63gsOhyrVvWHF+76HB0hnFc6YWqSUw9t/qoqnkrwKGDt2B1XqtWJQJy lV1kvzN3AEPMk8V3ELi2Fb/3O/Oar1KTle3NGtAFyku9wWHk/HmSvmYZSSNWYB7zr3MR FCCOWquoeR72uv6Yv8hEguhv6JOdaoiMES9Zz37yzAxeh+2o8WtCZEkVvdEwlPGz/2Fs zximc00ayGCNRVd2QBKDm5NnfqMsH+YmpzQSwOQbrhfvOx4ZN2nH+iBUwSyd8+c+0DLL wqJ4vpDR2Xgyl5puvRy+6vlGfvhXr5bsTNGrLbJ7BawATCsmVuSwOpSNt8m+0l8sAZO3 A0NQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NnoQTwQ+z1Ygl5QA6HHrKblb3Nr0dbdB6O8zlLgORug=; b=fYtr9KHav8hmc5EWE1YcZmeYB78NI2VHl24vXApQ+c5RNvdj94WcOFlwqCFyUmBhrH 5e6A7QWVeWZ9l+/Dhoab2i/l/S3FN2XIggWE0mmyuqbM5otCvcq1a0WIn5Q7a3ovLSwT C/WoyOeDQik7DTXMoYNJ5Fid0ZEpL5G6wSjbkheuPnopwJfgbDSVYd2N7RiWS7Fnayd/ X4ns6lNL1W1NpXrKKt9Jh76h4fhLsZqgt9srjGRuzx6CZ08clm+O+Om6hpUWGuYKWyfW QejviA97knKGam+AxItb+iT1T3k8GayIh1sDGTxhz+yIRk78cd6BNmr3Vfac3Wy0lvWk zOWw==
X-Gm-Message-State: AHYfb5ipYymfTgdH8sTFtGxUFKp9DLX0Y1tcQGmr5+uEbHeSwSXsH/X5 OPnWoMVu5dt0QRBxDdDFmlXPnfPUkplf
X-Received: by 10.28.159.141 with SMTP id i135mr861004wme.153.1503946450005; Mon, 28 Aug 2017 11:54:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.221 with HTTP; Mon, 28 Aug 2017 11:54:09 -0700 (PDT)
In-Reply-To: <75d35cde-644b-31ac-e784-516cfc8162a1@labn.net>
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local>      <20170828101111.bedfkeoxw3xcj4ex@elstar.local>  <75d35cde-644b-31ac-e784-516cfc8162a1@labn.net>
From: Andy Bierman 
Date: Mon, 28 Aug 2017 11:54:09 -0700
Message-ID: 
To: Lou Berger 
Cc: Juergen Schoenwaelder , Kent Watsen , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a1144e7f6ea119e0557d4d1db"
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 18:54:13 -0000

--001a1144e7f6ea119e0557d4d1db
Content-Type: text/plain; charset="UTF-8"

On Mon, Aug 28, 2017 at 11:40 AM, Lou Berger  wrote:

> Hi Andy,
>
>
> On 8/28/2017 12:24 PM, Andy Bierman wrote:
> > > 4.23.1.  Combining Operational State and Configuration Data
> > >
> > >    If possible, operational state SHOULD be combined with its
> associated
> > >    configuration data.  This prevents duplication of key leafs and
> > >    ancestor nodes.  It also prevents race conditions for retrieval of
> > >    dynamic entries, and allows configuration and operational state to
> be
> > >    retrieved together with minimal message overhead.
> > >
> I find the inclusion of the non NMDA form in this section a bit
> confusing, do you have any objection to dropping the following?
>
> > >    Not NMDA-Compliant:
> > >
> > >       container foo {
> > >         ...
> > >       }
> > >
> > >       container foo-state {
> > >         config false;
> > >         ...
> > >       }
> > >
>
>
removed



> Thanks,
> Lou
>
>

--001a1144e7f6ea119e0557d4d1db
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Aug 28, 2017 at 11:40 AM, Lou Berger <lberger@labn.net><=
/span> wrote:
Hi Andy,





On 8/28/2017 12:24 PM, Andy Bierman wrote:

> > 4.23.1.=C2=A0 Combining Operational State and Configuration Data<=
br>
> >

> >=C2=A0 =C2=A0 If possible, operational state SHOULD be combined wi=
th its associated

> >=C2=A0 =C2=A0 configuration data.=C2=A0 This prevents duplication =
of key leafs and

> >=C2=A0 =C2=A0 ancestor nodes.=C2=A0 It also prevents race conditio=
ns for retrieval of

> >=C2=A0 =C2=A0 dynamic entries, and allows configuration and operat=
ional state to be

> >=C2=A0 =C2=A0 retrieved together with minimal message overhead.
> >

I find the inclusion of the non NMDA form in this section a bit

confusing, do you have any objection to dropping the following?



> >=C2=A0 =C2=A0 Not NMDA-Compliant:

> >

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0container foo {

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}

> >

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0container foo-state {

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0config false;

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0}

> >



removed

=C2=
=A0

Thanks,

Lou







--001a1144e7f6ea119e0557d4d1db--


From nobody Mon Aug 28 11:59:01 2017
Return-Path: 
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 A294A132143 for ; Mon, 28 Aug 2017 11:58:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 3kFoABCDiV8n for ; Mon, 28 Aug 2017 11:58:58 -0700 (PDT)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 EAC8E132925 for ; Mon, 28 Aug 2017 11:58:57 -0700 (PDT)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id AED0A1E07E3 for ; Mon, 28 Aug 2017 12:58:57 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id 2iyt1w00J2SSUrH01iywy1; Mon, 28 Aug 2017 12:58:57 -0600
X-Authority-Analysis: v=2.2 cv=G8xsK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=KeKAF7QvOSUA:10 a=wU2YTnxGAAAA:8 a=6f13sgRxtjv3C5GwbYEA:9 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=3xNiM1UenmZ1tjvr1L5jLEu0MuDW12Cc/4PQ/NDL8rM=; b=UMDJz/mDklNjlzwsHyAP/xI+n6 LVQtCynmBYIdorMWZdeI+npSiQ78eed9R/+jPqPyTBBc9Mfwck/7XZVwZ/ro+00HRQLk6qVF4Brjq 8GdGIpX81JnAydUmWjhTax4NC;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:52684 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dmPFN-000vDK-NB; Mon, 28 Aug 2017 12:58:53 -0600
To: Andy Bierman 
Cc: Juergen Schoenwaelder , Kent Watsen , "netmod@ietf.org" 
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local>      <20170828101111.bedfkeoxw3xcj4ex@elstar.local>  <75d35cde-644b-31ac-e784-516cfc8162a1@labn.net> 
From: Lou Berger 
Message-ID: <0e4ad497-93d7-3f8f-209c-b4505de77d96@labn.net>
Date: Mon, 28 Aug 2017 14:58:48 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dmPFN-000vDK-NB
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:52684
X-Source-Auth: lberger@labn.net
X-Email-Count: 12
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 18:59:00 -0000

Thanks!


On 8/28/2017 2:54 PM, Andy Bierman wrote:
>
>
> On Mon, Aug 28, 2017 at 11:40 AM, Lou Berger  > wrote:
>
>     Hi Andy,
>
>
>     On 8/28/2017 12:24 PM, Andy Bierman wrote:
>     > > 4.23.1.  Combining Operational State and Configuration Data
>     > >
>     > >    If possible, operational state SHOULD be combined with its
>     associated
>     > >    configuration data.  This prevents duplication of key leafs and
>     > >    ancestor nodes.  It also prevents race conditions for
>     retrieval of
>     > >    dynamic entries, and allows configuration and operational
>     state to be
>     > >    retrieved together with minimal message overhead.
>     > >
>     I find the inclusion of the non NMDA form in this section a bit
>     confusing, do you have any objection to dropping the following?
>
>     > >    Not NMDA-Compliant:
>     > >
>     > >       container foo {
>     > >         ...
>     > >       }
>     > >
>     > >       container foo-state {
>     > >         config false;
>     > >         ...
>     > >       }
>     > >
>
>
> removed
>
>  
>
>     Thanks,
>     Lou
>
>


From nobody Mon Aug 28 12:13:44 2017
Return-Path: 
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 1E4DE132360 for ; Mon, 28 Aug 2017 12:13:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 kehDQ-k4MUIL for ; Mon, 28 Aug 2017 12:13:40 -0700 (PDT)
Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 8615A132143 for ; Mon, 28 Aug 2017 12:13:40 -0700 (PDT)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id C004D1E07E4 for ; Mon, 28 Aug 2017 13:13:36 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id 2jDZ1w01N2SSUrH01jDc4W; Mon, 28 Aug 2017 13:13:36 -0600
X-Authority-Analysis: v=2.2 cv=G8xsK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=KeKAF7QvOSUA:10 a=48vgC7mUAAAA:8 a=HYdXEmAEtF05-tEcD6wA:9 a=ERfcdGFNRYMmk1YL:21 a=7JH8CNHjtSvyIUsG:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Pp/aQsrEemZ4e6T/mvRy+xALh4Wdj81XsE0Sbv18ND8=; b=08BLv/eqYft4L9idPP/BkthmVb igqEur5frtzaXImjcRriy50t9QeYyZ9ZI8VeVnUzPaUnDWGEpNBwOYrRTXrs4x+ayLR2M2C+IdE/X ygf9yIYuHdEDMUOa3ood2fbxn;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:52788 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dmPTZ-000y1k-ID; Mon, 28 Aug 2017 13:13:33 -0600
To: Ladislav Lhotka , Martin Bjorklund 
Cc: netmod@ietf.org
References:  <20170828.122845.1527315474517128533.mbj@tail-f.com>  <20170828.133507.2047018591752852829.mbj@tail-f.com>  <1503927029.1715.46.camel@nic.cz> <7c99497f-d719-0fe2-01f5-a06d53c8fc68@labn.net> <1503929779.1715.65.camel@nic.cz>
From: Lou Berger 
Message-ID: <81b138c6-9941-3313-979c-61edad7819a7@labn.net>
Date: Mon, 28 Aug 2017 15:13:25 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <1503929779.1715.65.camel@nic.cz>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dmPTZ-000y1k-ID
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:52788
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 19:13:43 -0000

Lada,


On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
> Lou Berger píše v Po 28. 08. 2017 v 09:40 -0400:
>> Lada,
>>
>> On 8/28/2017 9:30 AM, Ladislav Lhotka wrote:
>>>> Can you please take a look at it and see if we have any other disconnects?
>>> This is really scary. 
>> I agree!
>>
>>> How can we expect poor data modellers to understand the
>>> concept if we have such fundamental disconnects, after so many hours of
>>> discussing it?
>> This highlights why getting the text in (any) document is so important,
>> and why discussions shouldn't be viewed as being closed until the impact
>> on the text is agreed to!
> I think many people still don't make much distinction between schema mount
> (manipulation of the schema) and data mount. I still believe we need to clearly
> separate these two concepts, preferably using two different mechanisms.

Frankly, I'm focused on removing blocking issues on the current WG
deliverable, i.e., schema mount.
...
>> Lou
>>
>> PS is your view aligned with martin or our example?
> If you mean shifting the XPath context node to the mount point instance, then
> yes.

funny, you answered yes to a choice!  I was asking if you think the
mount point shows up as a node in the data tree, i.e., as shown in the
example in
https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B.1?

from my perspective and my co-authors in the RTG area using schema
mount, we've never heard of a (filesystem) mount point that doesn't show
in the (directory) structure and this is the mental analogue we've been
assuming. Since there never was an explicit example/discussion or text
to dissuade us of this, this disconnect was never noticed.  Certainly
this needs to be explicit in the document (either way). The following
change could be made to the schema mount draft (at a minimum):

OLD
          A mount point defines a place in the node hierarchy where
          other data models may be attached. A server that implements a
NEW
          A mount point defines a node in a data tree under which
instances of
          other data models may be attached. A server that implements a

Lou

> Lada
>
>>> Lada
>>>


From nobody Mon Aug 28 12:20:14 2017
Return-Path: 
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 C63711321B0 for ; Mon, 28 Aug 2017 12:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 xP8y7h7quvg1 for ; Mon, 28 Aug 2017 12:20:10 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C38E51320CC for ; Mon, 28 Aug 2017 12:20:09 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id D6ED069; Mon, 28 Aug 2017 21:20:07 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id xhHfD2yWkXbM; Mon, 28 Aug 2017 21:20:01 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 28 Aug 2017 21:20:07 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 96E6F200E0; Mon, 28 Aug 2017 21:20:07 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id QS2A80ubwh6j; Mon, 28 Aug 2017 21:20:07 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2172D200AA; Mon, 28 Aug 2017 21:20:07 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id A93C3406C601; Mon, 28 Aug 2017 21:20:05 +0200 (CEST)
Date: Mon, 28 Aug 2017 21:20:05 +0200
From: Juergen Schoenwaelder 
To: Andy Bierman 
Cc: Kent Watsen , Lou Berger , "netmod@ietf.org" 
Message-ID: <20170828192005.vyt75puyicqxh3oe@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , Kent Watsen , Lou Berger , "netmod@ietf.org" 
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local>      <20170828101111.bedfkeoxw3xcj4ex@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 19:20:13 -0000

On Mon, Aug 28, 2017 at 09:24:17AM -0700, Andy Bierman wrote:
> 
> Except that we never use that term.
> It is always called operational datastore when we talk about it in meetings.
> Hence, the new NMDA terms section:
> 
>  ** NMDA Terms
> 
> The following terms are defined in the
> Network Management Datastore Architecture
> (NMDA) ^I-D.ietf-netmod-revised-datastores^.
> and are not redefined here:
> 
> - configuration
> - conventional configuration datastore (also called conventional datastore)
> - datastore
> - operational state
> - operational state datastore (also called operational datastore)
> 
> IMO these alternates should be put in the RD draft since they reflect the
> terms we actually use.
>

I know that we tend to be sloppy in meetings and often in emails but
in written RFCs (specifications) I would personally prefer to use a
single term.

> I think the first sentence refers to the temporary non-NMDA module.
> 
> NEW:
> 
> (a) Modules that require immediate support for the NMDA features
> SHOULD be structured for NMDA.  A temporary non-NMDA version of these
> models SHOULD exist, either an
> existing model or a model created either by hand or with
> suitable tools that mirror the current modeling strategies.

I am not sure about the second SHOULD. I think the temporary non-NMDA
version is more a MAY than a SHOULD. 

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Mon Aug 28 12:38:46 2017
Return-Path: 
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 EBC22132814 for ; Mon, 28 Aug 2017 12:38:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 6_2e2_ENxEIb for ; Mon, 28 Aug 2017 12:38:44 -0700 (PDT)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC9C8126BF0 for ; Mon, 28 Aug 2017 12:38:43 -0700 (PDT)
Received: by mail-wr0-x22f.google.com with SMTP id p14so4410717wrg.3 for ; Mon, 28 Aug 2017 12:38:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=t3mNgZXgbhUEWKubL1mbYrLbyBRkLGIqIAejjoekyrc=; b=L8PArXai38QsK9xh5pYYrHaa9quUvRQyCGeQarm2M8ktEjOYSN6QwC0PwA09TkI7XW PEF1nktImyXwBn82+v1LdusPLphxKOrnelfPMjTxpy68CSknRDWaqz3hwOoeOczLRd5/ CZ/DCZey4yU0kkGjQGGdG54YHp9FSXyP89yzbL3FHtJPjexCjaQalLYqX10c8p1ufKE4 wfKDkobTBWn+jQtXyEWRUtiQmgob+p4p0FMzHXTlgaHb1z/5+T+liEUp1g+PemvxitvI UlOrh2z8jYwPeDK/uQ8xzeVRm3vfSPdwYiMfE2yk5oRdjXmsXTh4G5tagpgKx0FPzc8m V8EA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=t3mNgZXgbhUEWKubL1mbYrLbyBRkLGIqIAejjoekyrc=; b=aq97+U+mbxpSX3AaDafd+YTojW+JOub6aa7Qy9LpFwqyLmnRqquc6GSQwpQIRgkvuV DoqYI+qcWLU65VjVVAn2klXb7yBx0Z7yUIpPKtqdWrAAW3EDl8J06hH09bX6rZKhJQI+ 9XB9PRcXR00U7FtaMagyw3Uh0uw2gB6NR+C3yvbgaCAxEHKeaYjbCf+0803lHdfHrHLR ZdyQuHfWEfPfvkznMPKReLXPHZAli9kagd85ADn49/lW/D1wDK/fHFOSNoORZLSz5T9L r5/Ig7G6qZ6l8ZAOJk1htAkLfpkYnGc4zgsYVzTscUl0uFi82FajnAXLnv49thtZf0On SHFQ==
X-Gm-Message-State: AHYfb5hEo43bHtiHjMoIUJoR2vhzwPi88rD5jXZiw2sDKcJPe4WZnXrz md+p4ngJunIFxrPT2Zu3OyJDDpG1Yxaf
X-Received: by 10.223.188.4 with SMTP id s4mr1020488wrg.88.1503949122259; Mon, 28 Aug 2017 12:38:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.221 with HTTP; Mon, 28 Aug 2017 12:38:41 -0700 (PDT)
In-Reply-To: <20170828192005.vyt75puyicqxh3oe@elstar.local>
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local>      <20170828101111.bedfkeoxw3xcj4ex@elstar.local>  <20170828192005.vyt75puyicqxh3oe@elstar.local>
From: Andy Bierman 
Date: Mon, 28 Aug 2017 12:38:41 -0700
Message-ID: 
To: Juergen Schoenwaelder , Andy Bierman ,  Kent Watsen , Lou Berger ,  "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="089e0820d4a4318b490557d57151"
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 19:38:46 -0000

--089e0820d4a4318b490557d57151
Content-Type: text/plain; charset="UTF-8"

On Mon, Aug 28, 2017 at 12:20 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Mon, Aug 28, 2017 at 09:24:17AM -0700, Andy Bierman wrote:
> >
> > Except that we never use that term.
> > It is always called operational datastore when we talk about it in
> meetings.
> > Hence, the new NMDA terms section:
> >
> >  ** NMDA Terms
> >
> > The following terms are defined in the
> > Network Management Datastore Architecture
> > (NMDA) ^I-D.ietf-netmod-revised-datastores^.
> > and are not redefined here:
> >
> > - configuration
> > - conventional configuration datastore (also called conventional
> datastore)
> > - datastore
> > - operational state
> > - operational state datastore (also called operational datastore)
> >
> > IMO these alternates should be put in the RD draft since they reflect the
> > terms we actually use.
> >
>
> I know that we tend to be sloppy in meetings and often in emails but
> in written RFCs (specifications) I would personally prefer to use a
> single term.
>


So change it in the RD draft to the term we actually use "operational
datastore".




>
> > I think the first sentence refers to the temporary non-NMDA module.
> >
> > NEW:
> >
> > (a) Modules that require immediate support for the NMDA features
> > SHOULD be structured for NMDA.  A temporary non-NMDA version of these
> > models SHOULD exist, either an
> > existing model or a model created either by hand or with
> > suitable tools that mirror the current modeling strategies.
>
> I am not sure about the second SHOULD. I think the temporary non-NMDA
> version is more a MAY than a SHOULD.
>
>
OK -- changed 2nd SHOULD to MAY



> /js
>

Andy


>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>

--089e0820d4a4318b490557d57151
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Aug 28, 2017 at 12:20 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Aug 28, 2017 at 09:24:17AM -0700, Andy Bier=
man wrote:

>

> Except that we never use that term.

> It is always called operational datastore when we talk about it in mee=
tings.

> Hence, the new NMDA terms section:

>

>=C2=A0 ** NMDA Terms

>

> The following terms are defined in the

> Network Management Datastore Architecture

> (NMDA) ^I-D.ietf-netmod-revised-datastores^.

> and are not redefined here:

>

> - configuration

> - conventional configuration datastore (also called conventional datas=
tore)

> - datastore

> - operational state

> - operational state datastore (also called operational datastore)

>

> IMO these alternates should be put in the RD draft since they reflect =
the

> terms we actually use.

>



I know that we tend to be sloppy in meetings and often in emails but

in written RFCs (specifications) I would personally prefer to use a

single term.
=C2=A0

So change=
 it in the RD draft to the term we actually use "operational datastore=
".


=C2=A0



> I think the first sentence refers to the temporary non-NMDA module.
>

> NEW:

>

> (a) Modules that require immediate support for the NMDA features

> SHOULD be structured for NMDA.=C2=A0 A temporary non-NMDA version of t=
hese

> models SHOULD exist, either an

> existing model or a model created either by hand or with

> suitable tools that mirror the current modeling strategies.



I am not sure about the second SHOULD. I think the temporary non-NMDA

version is more a MAY than a SHOULD.



OK -- changed 2nd SHOULD to MAY

=

=C2=A0

/js

Andy
=C2=A0=




--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>





--089e0820d4a4318b490557d57151--


From nobody Mon Aug 28 14:49:52 2017
Return-Path: 
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 2FE42132A9B for ; Mon, 28 Aug 2017 14:49:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.011
X-Spam-Level: 
X-Spam-Status: No, score=-3.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 NvgNB-b1ByoU for ; Mon, 28 Aug 2017 14:49:46 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0127.outbound.protection.outlook.com [104.47.41.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E1F126BF0 for ; Mon, 28 Aug 2017 14:49:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=duiui4hfeteOWSMT9A+Jqt84isUGn61W+v0sS7r4CE8=; b=WHlB1mX8hKcEDJytaYhVnq3JrQ34a73xN9CaHuuNHwvQClr78tT1SBkxwBQDQi1tGhSEkG8FB+GoIaUp7gpLBvqFBHwvPvyMZbYuR8rSOiQFZ6/Wl6+4WYobl6B+SCWsznjurGdODeW1PtZCXFFInHMt1WAwIlainqeqegKv5sI=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1570.namprd05.prod.outlook.com (10.161.217.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Mon, 28 Aug 2017 21:49:38 +0000
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.20.0013.008; Mon, 28 Aug 2017 21:49:38 +0000
From: Kent Watsen 
To: Andy Bierman , Juergen Schoenwaelder , Lou Berger , "netmod@ietf.org" 
Thread-Topic: [netmod] rfc6087bis S4.23 replacement text
Thread-Index: AQHTG4BdACYCFz8ZdEeedIP50UiUz6KQ1HkAgACjbICAA6UgAIAASekA///K0YCAAEjhgIADgq8AgACXooCAAGg+gIAAMR6AgAAFM4D//+GHgA==
Date: Mon, 28 Aug 2017 21:49:37 +0000
Message-ID: <91670535-4730-494E-AA25-EC831B05E016@juniper.net>
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local>      <20170828101111.bedfkeoxw3xcj4ex@elstar.local>  <20170828192005.vyt75puyicqxh3oe@elstar.local> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1570; 6:YCL1HlMRgeanPHfCelXryj0fOjLmt0OAwa4fjpPRgedmWOHHQpD3PEQpzKJn+QSPuOKf5iq/IprKGCbIqvN2QR9xtSyjNjsFBGMPixdwnChyrFaU+KvrCmoATVS0ElAeDvIgF9HCKw+CUUbP+PLa3qc/NL1Q5lWLJcZQFzHM3c2T+c0c3lt84Cu/c57P/P5VIHNlCCOw6mmsBLJOtQSnBkv8iYSoCHhpy31kQDsijt9y6NUx+DRzqopPVlAHmvpyrQsRmq6vyRvth4QvKJEprSG3s/fPhSvuQzV3cVFcgh/crMSLtI8IGLjcXorcBoMjAPbeZrHGa60Jk9gm99x04w==; 5:bOZA2IQU4ZJbeAapvk6H7NR3FLELiYtt3ChHfxBNZ5KpiDdTu1F3uPM1v3aJQJf392T1+pIdzEK0SAmpzdqNFm+fTwLb3CtsGzF/S63H2w9yVt0Nj9DkZwt/ucqTNtLoun10ai0OXO2f+z8EqV4gKQ==; 24:RCKPaidCV7jaF/ZAAJN7ayR7iSMfLFGxtU4eEKvwSyUxz6Hwrr5133V+FLH7oL4T/IquTiP/jhF6dOnfLGy8VW5uuKG4TqkpPAaM89fMgtw=; 7:8P3lJ/ETpLILeAB8MfHYsiVsHs7uIlFnFT+mOanqSYSR9GUJch353QZeQgWI0UQNgCG8tVwjNpAfsUuGCzLf5mYBgcifDYjVOC+grlEmdM3rmbuB02eM9snXEVXEaIo1u448/HV8lRHxAPukBFuW+Ycyx1WlYILyLoGhsHBcFYu7mYM5DxHE/d16Fy/eVnS2UZdPUmlNukvy+Vx+neJ6F/3FFaQ9wOl2X41orVcIFOg=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: ea1ca606-d2af-4142-08f0-08d4ee5eae18
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1570; 
x-ms-traffictypediagnostic: BN3PR0501MB1570:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123558100)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1570; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1570; 
x-forefront-prvs: 0413C9F1ED
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(189002)(51444003)(199003)(8936002)(478600001)(81156014)(81166006)(2900100001)(8676002)(53936002)(305945005)(7736002)(189998001)(105586002)(83716003)(6246003)(106356001)(3846002)(2950100002)(102836003)(6116002)(93886005)(86362001)(82746002)(4001350100001)(2501003)(36756003)(33656002)(50986999)(76176999)(101416001)(97736004)(54356999)(6436002)(6486002)(77096006)(229853002)(6506006)(6512007)(25786009)(83506001)(5660300001)(14454004)(3660700001)(2906002)(3280700002)(66066001)(99286003)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1570; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2017 21:49:38.0136 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1570
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 21:49:50 -0000

Pj4gSSBrbm93IHRoYXQgd2UgdGVuZCB0byBiZSBzbG9wcHkgaW4gbWVldGluZ3MgYW5kIG9mdGVu
IGluIGVtYWlscyBidXQNCj4+IGluIHdyaXR0ZW4gUkZDcyAoc3BlY2lmaWNhdGlvbnMpIEkgd291
bGQgcGVyc29uYWxseSBwcmVmZXIgdG8gdXNlIGENCj4+IHNpbmdsZSB0ZXJtLg0KPg0KPiBTbyBj
aGFuZ2UgaXQgaW4gdGhlIFJEIGRyYWZ0IHRvIHRoZSB0ZXJtIHdlIGFjdHVhbGx5IHVzZSAib3Bl
cmF0aW9uYWwgZGF0YXN0b3JlIi4NCg0KQSBsb3Qgb2YgZWZmb3J0IHdlbnQgaW50byBkZWZpbmlu
ZyB0aGUgdGVybXMuICBIYXZpbmcgImZvbyBjb25maWd1cmF0aW9uIGRhdGFzdG9yZSIgKG5vdCAi
Zm9vIGRhdGFzdG9yZSIpIGlzIHJlYWxseSBpbXBvcnRhbnQsIGJlY2F1c2UgaXQgYmluZHMgdG8g
dGhlIHRlcm0gZm9yICJjb25maWd1cmF0aW9uIi4gIEZXSVcsIEkgdGhpbmsgdGhhdCAidGhlIG9w
ZXJhdGlvbmFsIHN0YXRlIGRhdGFzdG9yZSIgZmVsbCBvdXQgbW9yZSBmb3Igc3ltbWV0cnkgLSBi
ZWNhdXNlIGl0IGNsZWFybHkgZG9lc24ndCBiaW5kIHRvIGVpdGhlciAic3lzdGVtIHN0YXRlIiBv
ciAiYXBwbGllZCBjb25maWd1cmF0aW9uIiA7KQ0KDQpUaGUgZW5kIG9mIHRoZSAnb3BlcmF0aW9u
YWwgc3RhdGUgZGF0YXN0b3JlJyB0ZXJtIHNheXMgIlRoaXMgZGF0YXN0b3JlIGlzIGNvbW1vbmx5
IHJlZmVycmVkIHRvIGFzICI8b3BlcmF0aW9uYWw+Ii4gICBBbmQgPG9wZXJhdGlvbmFsPiBleHBh
bmRzIGNvbGxvcXVpYWxseSB0byAidGhlIG9wZXJhdGlvbmFsIGRhdGFzdG9yZSIsIGFsYmVpdCBv
bmUgbWF5IHV0dGVyIHRoZSBmdWxsIGV4cGFuc2lvbiBpZiBkZXNpcmVkLiANCg0KU28sIHRoZSBu
ZXQtbmV0IChJIHRoaW5rKSBpcyB0aGF0LCBpbiB3cml0aW5nLCB3ZSBoYXZlIDxvcGVyYXRpb25h
bD4gYW5kICJ0aGUgb3BlcmF0aW9uYWwgc3RhdGUgZGF0YXN0b3JlIiBidXQsIHdoZW4gc3Bva2Vu
LCB3ZSBoYXZlICJvcGVyYXRpb25hbCIgYW5kICJ0aGUgb3BlcmF0aW9uYWwgZGF0YXN0b3JlIi4N
Cg0KTWFrZXMgc2Vuc2U/DQoNCktlbnQgLy8gY29udHJpYnV0b3INCg0KDQo=


From nobody Mon Aug 28 15:26:12 2017
Return-Path: 
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 A02C71326BB for ; Mon, 28 Aug 2017 15:26:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 khpeLHp-ai7y for ; Mon, 28 Aug 2017 15:26:08 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7584A132139 for ; Mon, 28 Aug 2017 15:26:08 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id f13so15972670wme.1 for ; Mon, 28 Aug 2017 15:26:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uYJv/cFPlZuExZZKfZN9BXRYWxiUMB+Non3xZ/JsKlI=; b=Vp0alpuCkGJkqWAj68X/9L4C/J5YeJYEhXsxnKXkE7FIx0PNYJb59USyy6MKDdRirt daG3lQ5Ehfj4ueM43cmaMxsZEPXlSP/Vl+zvXnL7RsBX4UM2y5adHp0Oy9WHQbSQezWv JYY9aekxp9x3m4Bva/KsEMoC1ARC/ERSEiUaTXzS4q4sZ3zuZt8fSXj2eNHq85J5cnc4 zPyVQ6WILMRFHfAlwXa/ppon7sb0VP4aIJ8Y0zHqE9frCaVNgpg0HNNDq3T6ABtGUpPB CV8pVEvQN61S8vwFINj+VRiKJw7GxXb6gAvQ5um6fHucT9DRatLdQFj2r8B2cgsorEcM oXYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uYJv/cFPlZuExZZKfZN9BXRYWxiUMB+Non3xZ/JsKlI=; b=MGn9dRoQX+/zTtBJPqrLAccZ/svMLd1TODqofm1WmcVtkX5QSAishnBpceHuFynsKz sQl5JehtmF4su50QMlIzvpGZDbViV69o7zPHBkg/Q9eEyrpPFH5tbYdr14p7S+H901JB OWAYYHPRdSIORMJnlzga4lqv59sJXs3eISYIetRVx8u0elCcQ0lDA3okrFXfaW379sig Deiioamf0CWGmzNBozQnIGICAnXUrnoDHxxfjHStxxQ/G6xaNL/8RDq3HvEe2S3ev+f6 rddMgP6qEcDmCVUH2/3QMJU+MsQXeGQhCMD2cMIlX+x6IkX6xgTQIGaFHrdoASW8DAz4 ak/A==
X-Gm-Message-State: AHYfb5i70v1OS36ta9rsAgtt0kdpxwGuUA9FQRioIu7yuItCTANuk64X LHJP0uogQPLwlNsxReU4SEfGop3MkO4R
X-Received: by 10.28.16.133 with SMTP id 127mr54257wmq.75.1503959166953; Mon, 28 Aug 2017 15:26:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.164.221 with HTTP; Mon, 28 Aug 2017 15:26:06 -0700 (PDT)
In-Reply-To: <91670535-4730-494E-AA25-EC831B05E016@juniper.net>
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local>      <20170828101111.bedfkeoxw3xcj4ex@elstar.local>  <20170828192005.vyt75puyicqxh3oe@elstar.local>  <91670535-4730-494E-AA25-EC831B05E016@juniper.net>
From: Andy Bierman 
Date: Mon, 28 Aug 2017 15:26:06 -0700
Message-ID: 
To: Kent Watsen 
Cc: Juergen Schoenwaelder , Lou Berger , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a1146d950e740580557d7c788"
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 22:26:11 -0000

--001a1146d950e740580557d7c788
Content-Type: text/plain; charset="UTF-8"

On Mon, Aug 28, 2017 at 2:49 PM, Kent Watsen  wrote:

> >> I know that we tend to be sloppy in meetings and often in emails but
> >> in written RFCs (specifications) I would personally prefer to use a
> >> single term.
> >
> > So change it in the RD draft to the term we actually use "operational
> datastore".
>
> A lot of effort went into defining the terms.  Having "foo configuration
> datastore" (not "foo datastore") is really important, because it binds to
> the term for "configuration".  FWIW, I think that "the operational state
> datastore" fell out more for symmetry - because it clearly doesn't bind to
> either "system state" or "applied configuration" ;)
>
> The end of the 'operational state datastore' term says "This datastore is
> commonly referred to as "".   And  expands
> colloquially to "the operational datastore", albeit one may utter the full
> expansion if desired.
>
> So, the net-net (I think) is that, in writing, we have  and
> "the operational state datastore" but, when spoken, we have "operational"
> and "the operational datastore".
>
> Makes sense?
>
>
rather confusing, since this  notation is not defined anywhere.
If the term 'state' added any value, we would use it more often, but I will
change the text just to get done faster.




> Kent // contributor
>
>
>
Andy

--001a1146d950e740580557d7c788
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Mon, Aug 28, 2017 at 2:49 PM, Kent Watsen <kwatsen@juniper.net> wrote:
>> I know that =
we tend to be sloppy in meetings and often in emails but

>> in written RFCs (specifications) I would personally prefer to use =
a

>> single term.

>

> So change it in the RD draft to the term we actually use "operati=
onal datastore".



A lot of effort went into defining the terms.=C2=A0 Having "foo config=
uration datastore" (not "foo datastore") is really important=
, because it binds to the term for "configuration".=C2=A0 FWIW, I=
 think that "the operational state datastore" fell out more for s=
ymmetry - because it clearly doesn't bind to either "system state&=
quot; or "applied configuration" ;)



The end of the 'operational state datastore' term says "This d=
atastore is commonly referred to as "<operational>".=C2=A0 =
=C2=A0And <operational> expands colloquially to "the operational=
 datastore", albeit one may utter the full expansion if desired.



So, the net-net (I think) is that, in writing, we have <operational> =
and "the operational state datastore" but, when spoken, we have &=
quot;operational" and "the operational datastore".



Makes sense?



rather confusing, since this <opera=
tional> notation is not defined anywhere.
If the term 'sta=
te' added any value, we would use it more often, but I will
c=
hange the text just to get done faster.


=

=C2=A0

Kent // contributor







Andy



--001a1146d950e740580557d7c788--


From nobody Mon Aug 28 16:01:51 2017
Return-Path: 
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 A29E6132961 for ; Mon, 28 Aug 2017 16:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Level: 
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 zakbZwxnjaPi for ; Mon, 28 Aug 2017 16:01:47 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0103.outbound.protection.outlook.com [104.47.41.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A07B13295F for ; Mon, 28 Aug 2017 16:01:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=E4NSVX249jQ58jc6Qm4hp1O72GlgvIuBNnEGkCYvUgU=; b=YudVoEaoqP6x7HdSRGkKfWeqZbTr9uovbxmb1JPyh9X4MMvZW3+BRjFT53PG9zwTZ2ZpIL8Fa1JoztfCYfJ5wE6rEZLKObBa7w5QuXxUUx27J9YsWXHdymfEBHZKhzRhvXKw7A44KaEyx9TBJCSdffUPlGNr78esFokD4RnBWpg=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1554.namprd05.prod.outlook.com (10.161.217.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Mon, 28 Aug 2017 23:01:46 +0000
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.20.0013.008; Mon, 28 Aug 2017 23:01:46 +0000
From: Kent Watsen 
To: Andy Bierman 
CC: Juergen Schoenwaelder , Lou Berger , "netmod@ietf.org" 
Thread-Topic: [netmod] rfc6087bis S4.23 replacement text
Thread-Index: AQHTG4BdACYCFz8ZdEeedIP50UiUz6KQ1HkAgACjbICAA6UgAIAASekA///K0YCAAEjhgIADgq8AgACXooCAAGg+gIAAMR6AgAAFM4D//+GHgIAATT8A///G6IA=
Date: Mon, 28 Aug 2017 23:01:46 +0000
Message-ID: 
References: <4425D564-7AD1-40B7-853F-FA9328E10F2D@juniper.net> <9596582d-17cf-e851-f88f-fd7a79d88e4f@labn.net> <20170823061709.prezywubi7b32w7i@elstar.local>      <20170828101111.bedfkeoxw3xcj4ex@elstar.local>  <20170828192005.vyt75puyicqxh3oe@elstar.local>  <91670535-4730-494E-AA25-EC831B05E016@juniper.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1554; 6:77WbRcBqdpwmPwghK2SUX8OXBtr+dlQzAW+UawNEM1XLLSIVI8GaRjokSy1VCOe5L6ms+OMKlmpbTBCC25laH6jRBdHbLeJVs3qe6yfvZTnY/A+rox2DLSDvF/uWYQB/vNCJpmlA4BtIEWI/eiAA35LfhBRZNG90Ro/pFiq0a5rXawTNSrOaBbOM/WKL7Pi9er7IkkPiB8cRQ+hL160r4U3aehDdFza257VWS4F4KT5P0f/9VsQk35EjCU7VB0TOjiy2XDhYcoYGsQTzQDD+Bn79VAxs8Cdn1nwc4fC5gm/Su1fpC+dKa01cGYl//FacXJUuJhy/zyBtDlQcdW0waA==; 5:OjfbhuPb+R5krJBSGGMuQO2F46wPdJhx2/zaQfyLLr6EV8hckEsmeW6r7BY+rGF6+Bc7WemeYBWcujpr7WgJly7sXgTkhj1zf7UPoEjesP2OX8bmkHouE2mxYWLdnJpc3Dp1As+yel/aBYNFCPRorQ==; 24:hnBAuU03YeiPx8dpQIH50ySNIsmhTHie7OUI61mryDLd+/I5HRguiDOgAOHgHrUFez+BUuqkTzVdFuLqaDVUzKLMyvMoCZbrnH1A7GUtdvI=; 7:9jXrRAxG1mAGco7ymvChj5hOynXM5WfwDZCytmz9GQ0c9OCgQcp6Ragrf6Ngs9inmMEFKrvzvqN0EEL2/H/GtA9aD7BxYa6nbfLrCxB7nmpaGM9ENFMd13WjyxvLI1pXbnYUgu0J4beSYJqwoHITdNiKcsTvbL8K3lulDXz7ZSC4X27pB5U2XcuzWNwD6SvQbIly1u1YBA86bk3jZ7MkygJqTmql6/feAfOrcv+Kf9A=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: cf66fd22-cacb-4f80-79cf-08d4ee68c1e2
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1554; 
x-ms-traffictypediagnostic: BN3PR0501MB1554:
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1554; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1554; 
x-forefront-prvs: 0413C9F1ED
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(199003)(189002)(86362001)(110136004)(6916009)(5660300001)(106356001)(14454004)(7736002)(101416001)(6506006)(2906002)(105586002)(3280700002)(2950100002)(3660700001)(76176999)(50986999)(54356999)(6436002)(8936002)(68736007)(99286003)(66066001)(83506001)(53936002)(2900100001)(36756003)(77096006)(6116002)(6486002)(3846002)(102836003)(6306002)(54896002)(54906002)(81166006)(81156014)(6512007)(4326008)(229853002)(83716003)(93886005)(8676002)(25786009)(82746002)(33656002)(6246003)(97736004)(4001350100001)(189998001)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1554; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D656FE788B604262A60A5F9C3C41CF7Bjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Aug 2017 23:01:46.2155 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1554
Archived-At: 
Subject: Re: [netmod] rfc6087bis S4.23 replacement text
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Aug 2017 23:01:49 -0000

--_000_D656FE788B604262A60A5F9C3C41CF7Bjunipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQo+IHJhdGhlciBjb25mdXNpbmcsIHNpbmNlIHRoaXMgPG9wZXJhdGlvbmFsPiBub3RhdGlvbiBp
cyBub3QgZGVmaW5lZCBhbnl3aGVyZS4NCg0KQSBiaXQsIHllcy4gIEkgdHJpZWQgdG8gZ2V0IHRo
ZSA8Zm9vPiBzeW50YXggZGVmaW5lZCBpbiBSRCwgYnV0IG15IGNvLWF1dGhvcnMNCmRpZG4ndCB0
aGluayBpdCB3YXMgbmVjZXNzYXJ5LiAgSSBhY3F1aWVzY2VkIGFzIHdlbGwganVzdCB0byBtb3Zl
IHRoaW5ncyBhbG9uZy4NCg0KDQo+IElmIHRoZSB0ZXJtICdzdGF0ZScgYWRkZWQgYW55IHZhbHVl
LCB3ZSB3b3VsZCB1c2UgaXQgbW9yZSBvZnRlbiwgYnV0IEkgd2lsbA0KPiBjaGFuZ2UgdGhlIHRl
eHQganVzdCB0byBnZXQgZG9uZSBmYXN0ZXIuDQoNCkV4YWN0bHkuDQoNCg0KSy4NCg0K

--_000_D656FE788B604262A60A5F9C3C41CF7Bjunipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm
b250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCglj
b2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9u
Om5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXtt
c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRl
Y29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv
LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk
U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu
IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z
dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i
Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mZ3Q7IHJhdGhlciBjb25mdXNpbmcsIHNpbmNlIHRoaXMgJmx0O29wZXJh
dGlvbmFsJmd0OyBub3RhdGlvbiBpcyBub3QgZGVmaW5lZCBhbnl3aGVyZS48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBiaXQsIHllcy4mbmJzcDsgSSB0cmllZCB0byBn
ZXQgdGhlICZsdDtmb28mZ3Q7IHN5bnRheCBkZWZpbmVkIGluIFJELCBidXQgbXkgY28tYXV0aG9y
czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZGlkbid0IHRoaW5rIGl0IHdh
cyBuZWNlc3NhcnkuJm5ic3A7IEkgYWNxdWllc2NlZCBhcyB3ZWxsIGp1c3QgdG8gbW92ZSB0aGlu
Z3MgYWxvbmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw
OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBJZiB0aGUgdGVybSAnc3RhdGUnIGFkZGVkIGFueSB2
YWx1ZSwgd2Ugd291bGQgdXNlIGl0IG1vcmUgb2Z0ZW4sIGJ1dCBJIHdpbGw8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgY2hhbmdlIHRoZSB0
ZXh0IGp1c3QgdG8gZ2V0IGRvbmUgZmFzdGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXhhY3RseS48bzpwPjwv
bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5LLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_D656FE788B604262A60A5F9C3C41CF7Bjunipernet_--


From nobody Tue Aug 29 00:39:13 2017
Return-Path: 
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 814891323C6 for ; Tue, 29 Aug 2017 00:39:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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
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 vdD8bDPRYYj0 for ; Tue, 29 Aug 2017 00:39:10 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966091326DF for ; Tue, 29 Aug 2017 00:39:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1052; q=dns/txt; s=iport; t=1503992349; x=1505201949; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=SBwRodBKp4gdL/2a8eZgvMW8aQaDKkkcSEmHJv9jWSA=; b=Y2aylBJABWCZy/UnX7yjjPs05Jr7+4PBvUcMREhj2pCBVRAvFZxlUwB+ uz6J55CWYIAAANdTol4Xthy15ms22wHlfxVAHsra18fTmr4oAiOL3aYAh J7eUkxeutEyoxVcrIlomYB/KfoXJPljS8MBe+4mTYbfxUIe8MVX1ae6mk E=;
X-IronPort-AV: E=Sophos;i="5.41,444,1498521600"; d="scan'208";a="655272725"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2017 07:39:07 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v7T7d4Xm004248; Tue, 29 Aug 2017 07:39:04 GMT
To: Xufeng Liu , Per Hedeland , Ladislav Lhotka , "'netmod@ietf.org'" , "Pieter Lewyllie (pilewyll)" 
References:  <20170824060900.u5kcffzvwjr7mmob@elstar.local> <152f24b2-7947-9c76-714c-af226ab3fe91@tail-f.com> <8760ddc676.fsf@nic.cz> <599F0991.7020900@tail-f.com>  <20170825125254.6nhnzkrar6fhu7zr@elstar.local>  <20170828154640.pzg7jfy5uepkb22q@elstar.local>
From: Benoit Claise 
Message-ID: <68e772f6-327e-268c-522b-3b480cccbdb4@cisco.com>
Date: Tue, 29 Aug 2017 09:39:05 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170828154640.pzg7jfy5uepkb22q@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Aug 2017 07:39:11 -0000

In this discussion, let's keep in mind that the openconfig modules use 
the POSIX regex while the IETF uses the W3C regex.
So for operators that have to deal with a mix of openconfig and IETF 
modules, this type of advice could be handy from a tooling point of 
view. Such advice, if not in RFC6087bis, could be provided in the yangre 
tool or in its GUI equivalent: https://yangcatalog.org/yangre

Regards, Benoit
> On Mon, Aug 28, 2017 at 12:58:59PM +0000, Xufeng Liu wrote:
>> [Xufeng] [0..9] is still compliant with the XSD pattern specified by
>> YANG 1.0 and 1.1. Using [0..9] instead of [\d] will make the
>> implementations with native POSIX RegEx easier without the need for
>> a tool to inspect every element of the RegEx pattern.
> Yes, but then \d is legal in YANG (and it is used in a couple of
> published RFCs).
>
> Educating _all_ module authors to write [0..9] instead of \d will
> likely be more expensive than improving the code of implementations
> that did not implement YANG entirely to accept \d.
>
> /js
>


From nobody Tue Aug 29 00:39:26 2017
Return-Path: 
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 AA6391329B5 for ; Tue, 29 Aug 2017 00:39:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 Aw9WrHH_ZKvl for ; Tue, 29 Aug 2017 00:39:12 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 587111323C6 for ; Tue, 29 Aug 2017 00:39:12 -0700 (PDT)
Received: from localhost (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 053F91AE00A0; Tue, 29 Aug 2017 09:39:10 +0200 (CEST)
Date: Tue, 29 Aug 2017 09:37:43 +0200 (CEST)
Message-Id: <20170829.093743.762532630259333653.mbj@tail-f.com>
To: lberger@labn.net
Cc: lhotka@nic.cz, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <81b138c6-9941-3313-979c-61edad7819a7@labn.net>
References: <7c99497f-d719-0fe2-01f5-a06d53c8fc68@labn.net> <1503929779.1715.65.camel@nic.cz> <81b138c6-9941-3313-979c-61edad7819a7@labn.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Aug 2017 07:39:15 -0000

Lou Berger  wrote:
> Lada,
> =

> =

> On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
> > Lou Berger p=ED=A8e v Po 28. 08. 2017 v 09:40 -0400:
> >> Lada,
> >>
> >> On 8/28/2017 9:30 AM, Ladislav Lhotka wrote:
> >>>> Can you please take a look at it and see if we have any other di=
sconnects?
> >>> This is really scary. =

> >> I agree!
> >>
> >>> How can we expect poor data modellers to understand the
> >>> concept if we have such fundamental disconnects, after so many ho=
urs of
> >>> discussing it?
> >> This highlights why getting the text in (any) document is so impor=
tant,
> >> and why discussions shouldn't be viewed as being closed until the =
impact
> >> on the text is agreed to!
> > I think many people still don't make much distinction between schem=
a mount
> > (manipulation of the schema) and data mount. I still believe we nee=
d to clearly
> > separate these two concepts, preferably using two different mechani=
sms.
> =

> Frankly, I'm focused on removing blocking issues on the current WG
> deliverable, i.e., schema mount.
> ...
> >> Lou
> >>
> >> PS is your view aligned with martin or our example?
> > If you mean shifting the XPath context node to the mount point inst=
ance, then
> > yes.
> =

> funny, you answered yes to a choice!=A0 I was asking if you think the=

> mount point shows up as a node in the data tree, i.e., as shown in th=
e
> example in
> https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B.1=
?
> =

> from my perspective and my co-authors in the RTG area using schema
> mount, we've never heard of a (filesystem) mount point that doesn't s=
how
> in the (directory) structure and this is the mental analogue we've be=
en
> assuming. Since there never was an explicit example/discussion or tex=
t
> to dissuade us of this

The current text says:

  A "container" or "list" node becomes a mount point if the
  "mount-point" extension (defined in the "ietf-yang-schema-mount"
  module) is used in its definition.

But of course we should clarify this.

>, this disconnect was never noticed.=A0 Certainly
> this needs to be explicit in the document (either way). The following=

> change could be made to the schema mount draft (at a minimum):
> =

> OLD
> =A0=A0=A0=A0=A0=A0=A0=A0=A0 A mount point defines a place in the node=
 hierarchy where
> =A0=A0=A0=A0=A0=A0=A0=A0=A0 other data models may be attached. A serv=
er that implements a
> NEW
> =A0=A0=A0=A0=A0=A0=A0=A0=A0 A mount point defines a node in a data tr=
ee under which
> instances of
> =A0=A0=A0=A0=A0=A0=A0=A0=A0 other data models may be attached. A serv=
er that implements a

I strongly object to letting the extension define a new data node.
This would be a new type of data node that presumably look a lot like
a container, and you'd have to define all sorts of rules for this new
node (how it is encoded in XML, JSON, CBOR; how it is handled in
edit-config, how it is mapped to RESTCONF resources etc etc).

If you thought that the extension implicitly creates a node, adding an
explicit container won't do any harm; it will not change the schema
tree from what you thought it was.

But I think we should also restrict the mount-point extension so that
there cannot be more than one mount-point in a given container.


/martin


From nobody Tue Aug 29 00:51:28 2017
Return-Path: 
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 6BBE2132620 for ; Tue, 29 Aug 2017 00:51:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 intBvo8cSpkT for ; Tue, 29 Aug 2017 00:51:15 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1810113235C for ; Tue, 29 Aug 2017 00:51:15 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 237028E4; Tue, 29 Aug 2017 09:51:13 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Dho4U8P9CmrM; Tue, 29 Aug 2017 09:51:06 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 29 Aug 2017 09:51:13 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 026C2200E0; Tue, 29 Aug 2017 09:51:13 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BzgzpGPPkzQU; Tue, 29 Aug 2017 09:51:12 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 871CE200AA; Tue, 29 Aug 2017 09:51:12 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 2E23C406D00C; Tue, 29 Aug 2017 09:51:12 +0200 (CEST)
Date: Tue, 29 Aug 2017 09:51:12 +0200
From: Juergen Schoenwaelder 
To: Benoit Claise 
Cc: Xufeng Liu , Per Hedeland , Ladislav Lhotka , "'netmod@ietf.org'" , "Pieter Lewyllie (pilewyll)" 
Message-ID: <20170829075112.rc4p5umivwyxpv66@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Benoit Claise , Xufeng Liu , Per Hedeland , Ladislav Lhotka , "'netmod@ietf.org'" , "Pieter Lewyllie (pilewyll)" 
References:  <20170824060900.u5kcffzvwjr7mmob@elstar.local> <152f24b2-7947-9c76-714c-af226ab3fe91@tail-f.com> <8760ddc676.fsf@nic.cz> <599F0991.7020900@tail-f.com>  <20170825125254.6nhnzkrar6fhu7zr@elstar.local>  <20170828154640.pzg7jfy5uepkb22q@elstar.local> <68e772f6-327e-268c-522b-3b480cccbdb4@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <68e772f6-327e-268c-522b-3b480cccbdb4@cisco.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Aug 2017 07:51:19 -0000

On Tue, Aug 29, 2017 at 09:39:05AM +0200, Benoit Claise wrote:
> In this discussion, let's keep in mind that the openconfig modules use the
> POSIX regex while the IETF uses the W3C regex.
> So for operators that have to deal with a mix of openconfig and IETF
> modules, this type of advice could be handy from a tooling point of view.
> Such advice, if not in RFC6087bis, could be provided in the yangre tool or
> in its GUI equivalent: https://yangcatalog.org/yangre

But we might make things worse. POSIX regex != XSD regex and trying to
make them look more similar likely worsens the confusion by making it
even more subtle that there are differences. From this perspective,
using \d instead of [0-9] is actually a good thing.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Tue Aug 29 01:05:03 2017
Return-Path: 
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 0EFFE132620 for ; Tue, 29 Aug 2017 01:05:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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
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 GoEwJwIp-Rnd for ; Tue, 29 Aug 2017 01:04:59 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F44132197 for ; Tue, 29 Aug 2017 01:04:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1834; q=dns/txt; s=iport; t=1503993899; x=1505203499; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=lojjd8hH5eN/g2dIyjSwIr8nNVQwLkchwz+Sfl9XTvg=; b=FtOwh0VNuIdXsGXGK2s4Rj42J0NnLPxYDE0jAnXRm6zBdEtjmLWficgs W+6ug1IHwErx6YPDNIv6PVlGFS0ZReIx0rt6oPDUhhv+v9K/2ti0i0jz8 LgLyFReAraQ9G/H/79U6DnQctIYT1Pc65dbOX2YBcQNZ/HK+ZzPHJBWwn s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmAgCHH6VZ/xbLJq1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBhD6BFQGDdosRkHUiljWCBCyFGwKERxQBAgEBAQEBAQFrKIUZAQUjFTw?= =?us-ascii?q?VCw4KAgImAgJXBgEMCAEBii0QsTyCJ4tlAQEBAQEBAQEBAQEBAQEBAQEBIIENg?= =?us-ascii?q?h2DUIFjKwuCcoRCARIBgzKCYQEEoGeHWYxyghJahQyDWYcZjU2IcjYhgQILMiE?= =?us-ascii?q?IHBVJhxw/N4hogjIBAQE?=
X-IronPort-AV: E=Sophos;i="5.41,444,1498521600"; d="scan'208";a="654250211"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2017 08:04:57 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v7T84uY3028795; Tue, 29 Aug 2017 08:04:57 GMT
To: Lou Berger , NetMod WG 
References: <904712c6-038f-ea33-5a1a-62dd493a9481@labn.net>
From: Robert Wilton 
Message-ID: <981f9d4b-b39a-2918-cf55-f4a982edfd5b@cisco.com>
Date: Tue, 29 Aug 2017 09:04:55 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <904712c6-038f-ea33-5a1a-62dd493a9481@labn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Regarding IPR on draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Aug 2017 08:05:02 -0000

No, I'm not aware of any IPR that applies to this draft.

Rob


On 25/08/2017 21:20, Lou Berger wrote:
> Authors, Contributors, WG,
>
> As part of the preparation for WG Last Call:
>
> Are you aware of any IPR that applies to drafts identified above?
>
> Please state either:
>
> "No, I'm not aware of any IPR that applies to this draft"
> or
> "Yes, I'm aware of IPR that applies to this draft"
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3669, 5378 and 8179 for more details)?
>
> If yes to the above, please state either:
>
> "Yes, the IPR has been disclosed in compliance with IETF IPR rules"
> or
> "No, the IPR has not been disclosed"
>
> If you answer no, please provide any additional details you think
> appropriate.
>
> If you are listed as a document author or contributor please answer the
> above by responding to this email regardless of whether or not you are
> aware of any relevant IPR. This document will not advance to the next
> stage until a response has been received from each author and listed
> contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S
> TO LINES.
>
> If you are on the WG email list or attend WG meetings but are not listed
> as an author or contributor, we remind you of your obligations under
> the IETF IPR rules which encourages you to notify the IETF if you are
> aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed above
> and
> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>
> Thank you,
> NetMod WG Chairs
>
> PS Please include all listed in the headers of this message in your
> response.
>
>
> .
>


From nobody Tue Aug 29 05:35:00 2017
Return-Path: 
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 D709A1329C5 for ; Tue, 29 Aug 2017 05:34:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 c9dNsqOzEt6K for ; Tue, 29 Aug 2017 05:34:58 -0700 (PDT)
Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 1331E132968 for ; Tue, 29 Aug 2017 05:34:58 -0700 (PDT)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 446441E0745 for ; Tue, 29 Aug 2017 06:34:50 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id 30am1w0072SSUrH010ap1f; Tue, 29 Aug 2017 06:34:50 -0600
X-Authority-Analysis: v=2.2 cv=F98nTupN c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=Q9fys5e9bTEA:10 a=KeKAF7QvOSUA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=BITaCbhJX4eeEuJkCuEA:9 a=Uo1TAxcZBB5w_AzH:21 a=VILcoSNmgfWgjEKG:21 a=PUjeQqilurYA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=FMwZbVBw84j4RKH0u7b2yOVQW6vj5SQTl/VH9tBhaXg=; b=nshe5RMNgOeIcXPUPnIhnvgX1i XYECgXNj9T/LMFL8ZUgkXsEUa8PuXalFbWPfE+QFQZsspu+jKG4hKmoMVJFS+MVvsfhDZ7w+1VL+a 3UxLIVYmFbYS/zGAP3i9uHO1I;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:41262 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dmfjC-003ryC-45; Tue, 29 Aug 2017 06:34:46 -0600
To: Martin Bjorklund 
Cc: lhotka@nic.cz, netmod@ietf.org
References: <7c99497f-d719-0fe2-01f5-a06d53c8fc68@labn.net> <1503929779.1715.65.camel@nic.cz> <81b138c6-9941-3313-979c-61edad7819a7@labn.net> <20170829.093743.762532630259333653.mbj@tail-f.com>
From: Lou Berger 
Message-ID: <647a5ef0-968a-4eb7-322e-b3862a1252bd@labn.net>
Date: Tue, 29 Aug 2017 08:34:45 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20170829.093743.762532630259333653.mbj@tail-f.com>
Content-Type: text/plain; charset=iso-8859-15
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dmfjC-003ryC-45
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net (fs2.dc.labn.net) [100.15.84.20]:41262
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Aug 2017 12:35:00 -0000

On 08/29/2017 03:37 AM, Martin Bjorklund wrote:
> Lou Berger  wrote:
>> Lada,
>>
>>
>> On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
>>> Lou Berger pe v Po 28. 08. 2017 v 09:40 -0400:
>>>> Lada,
>>>>
>>>> On 8/28/2017 9:30 AM, Ladislav Lhotka wrote:
>>>>>> Can you please take a look at it and see if we have any other disconnects?
>>>>> This is really scary. 
>>>> I agree!
>>>>
>>>>> How can we expect poor data modellers to understand the
>>>>> concept if we have such fundamental disconnects, after so many hours of
>>>>> discussing it?
>>>> This highlights why getting the text in (any) document is so important,
>>>> and why discussions shouldn't be viewed as being closed until the impact
>>>> on the text is agreed to!
>>> I think many people still don't make much distinction between schema mount
>>> (manipulation of the schema) and data mount. I still believe we need to clearly
>>> separate these two concepts, preferably using two different mechanisms.
>>
>> Frankly, I'm focused on removing blocking issues on the current WG
>> deliverable, i.e., schema mount.
>> ...
>>>> Lou
>>>>
>>>> PS is your view aligned with martin or our example?
>>> If you mean shifting the XPath context node to the mount point instance, then
>>> yes.
>>
>> funny, you answered yes to a choice!  I was asking if you think the
>> mount point shows up as a node in the data tree, i.e., as shown in the
>> example in
>> https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B.1?
>>
>> from my perspective and my co-authors in the RTG area using schema
>> mount, we've never heard of a (filesystem) mount point that doesn't show
>> in the (directory) structure and this is the mental analogue we've been
>> assuming. Since there never was an explicit example/discussion or text
>> to dissuade us of this
> 
> The current text says:
> 
>   A "container" or "list" node becomes a mount point if the
>   "mount-point" extension (defined in the "ietf-yang-schema-mount"
>   module) is used in its definition.

interesting, read that a few times to (now) get the gist of your intent.

> 
> But of course we should clarify this.
> 



>> , this disconnect was never noticed.  Certainly
>> this needs to be explicit in the document (either way). The following
>> change could be made to the schema mount draft (at a minimum):
>>
>> OLD
>>           A mount point defines a place in the node hierarchy where
>>           other data models may be attached. A server that implements a
>> NEW
>>           A mount point defines a node in a data tree under which
>> instances of
>>           other data models may be attached. A server that implements a
> 
> I strongly object to letting the extension define a new data node.

> This would be a new type of data node that presumably look a lot like
> a container, 

agreed, just like a mount point looks a lot like a directory in a unix
file system.

> and you'd have to define all sorts of rules for this new
> node (how it is encoded in XML, JSON, CBOR; how it is handled in
> edit-config, how it is mapped to RESTCONF resources etc etc).

I'm don't see this, the rules would be the same as a container, as in
"mount points in data trees are encoded identically as containers".

> 
> If you thought that the extension implicitly creates a node, adding an
> explicit container won't do any harm; it will not change the schema
> tree from what you thought it was.

Well we could make this work, but it feels like every model that uses
schema has added complexity to its definition and use to perhaps avoid
making some minor tooling changes.  Keep in mind that any use of the
mount point extension will required changes in tooling.

> 
> But I think we should also restrict the mount-point extension so that
> there cannot be more than one mount-point in a given container.
> 
In this case, I'd go further and say that the only thing in the
container (of the module schema) is the mount point and a mount point
extension is only valid within a container. (Then the semantics are the
same as we expected, just the syntax is different.)

Lou


> 
> /martin
> 
> 


From nobody Tue Aug 29 05:45:45 2017
Return-Path: 
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 09E56132C31 for ; Tue, 29 Aug 2017 05:45:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 yVqFGyZSrNuc for ; Tue, 29 Aug 2017 05:45:39 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EB490132A0D for ; Tue, 29 Aug 2017 05:45:37 -0700 (PDT)
Received: from localhost (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 276001AE00A0; Tue, 29 Aug 2017 14:45:36 +0200 (CEST)
Date: Tue, 29 Aug 2017 14:44:09 +0200 (CEST)
Message-Id: <20170829.144409.1459812722022735947.mbj@tail-f.com>
To: lberger@labn.net
Cc: lhotka@nic.cz, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <647a5ef0-968a-4eb7-322e-b3862a1252bd@labn.net>
References: <81b138c6-9941-3313-979c-61edad7819a7@labn.net> <20170829.093743.762532630259333653.mbj@tail-f.com> <647a5ef0-968a-4eb7-322e-b3862a1252bd@labn.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Aug 2017 12:45:43 -0000

Lou Berger  wrote:
> On 08/29/2017 03:37 AM, Martin Bjorklund wrote:
> > Lou Berger  wrote:
> >> Lada,
> >>
> >>
> >> On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
> >>> Lou Berger p=ED=A8e v Po 28. 08. 2017 v 09:40 -0400:
> >>>> Lada,
> >>>>
> >>>> On 8/28/2017 9:30 AM, Ladislav Lhotka wrote:
> >>>>>> Can you please take a look at it and see if we have any other =
disconnects?
> >>>>> This is really scary. =

> >>>> I agree!
> >>>>
> >>>>> How can we expect poor data modellers to understand the
> >>>>> concept if we have such fundamental disconnects, after so many =
hours of
> >>>>> discussing it?
> >>>> This highlights why getting the text in (any) document is so imp=
ortant,
> >>>> and why discussions shouldn't be viewed as being closed until th=
e impact
> >>>> on the text is agreed to!
> >>> I think many people still don't make much distinction between sch=
ema mount
> >>> (manipulation of the schema) and data mount. I still believe we n=
eed to clearly
> >>> separate these two concepts, preferably using two different mecha=
nisms.
> >>
> >> Frankly, I'm focused on removing blocking issues on the current WG=

> >> deliverable, i.e., schema mount.
> >> ...
> >>>> Lou
> >>>>
> >>>> PS is your view aligned with martin or our example?
> >>> If you mean shifting the XPath context node to the mount point in=
stance, then
> >>> yes.
> >>
> >> funny, you answered yes to a choice!  I was asking if you think th=
e
> >> mount point shows up as a node in the data tree, i.e., as shown in=
 the
> >> example in
> >> https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-=
B.1?
> >>
> >> from my perspective and my co-authors in the RTG area using schema=

> >> mount, we've never heard of a (filesystem) mount point that doesn'=
t show
> >> in the (directory) structure and this is the mental analogue we've=
 been
> >> assuming. Since there never was an explicit example/discussion or =
text
> >> to dissuade us of this
> > =

> > The current text says:
> > =

> >   A "container" or "list" node becomes a mount point if the
> >   "mount-point" extension (defined in the "ietf-yang-schema-mount"
> >   module) is used in its definition.
> =

> interesting, read that a few times to (now) get the gist of your inte=
nt.
> =

> > =

> > But of course we should clarify this.
> > =

> =

> =

> =

> >> , this disconnect was never noticed.  Certainly
> >> this needs to be explicit in the document (either way). The follow=
ing
> >> change could be made to the schema mount draft (at a minimum):
> >>
> >> OLD
> >>           A mount point defines a place in the node hierarchy wher=
e
> >>           other data models may be attached. A server that impleme=
nts a
> >> NEW
> >>           A mount point defines a node in a data tree under which
> >> instances of
> >>           other data models may be attached. A server that impleme=
nts a
> > =

> > I strongly object to letting the extension define a new data node.
> =

> > This would be a new type of data node that presumably look a lot li=
ke
> > a container, =

> =

> agreed, just like a mount point looks a lot like a directory in a uni=
x
> file system.
> =

> > and you'd have to define all sorts of rules for this new
> > node (how it is encoded in XML, JSON, CBOR; how it is handled in
> > edit-config, how it is mapped to RESTCONF resources etc etc).
> =

> I'm don't see this, the rules would be the same as a container, as in=

> "mount points in data trees are encoded identically as containers".
> =

> > =

> > If you thought that the extension implicitly creates a node, adding=
 an
> > explicit container won't do any harm; it will not change the schema=

> > tree from what you thought it was.
> =

> Well we could make this work, but it feels like every model that uses=

> schema has added complexity to its definition and use to perhaps avoi=
d
> making some minor tooling changes.  Keep in mind that any use of the
> mount point extension will required changes in tooling.
> =

> > =

> > But I think we should also restrict the mount-point extension so th=
at
> > there cannot be more than one mount-point in a given container.
> > =

> In this case, I'd go further and say that the only thing in the
> container (of the module schema) is the mount point and a mount point=

> extension is only valid within a container. (Then the semantics are t=
he
> same as we expected, just the syntax is different.)

I was thinking about this as well, but I thought that maybe rejecting
any other data node is a CLR.  Maybe there is a good use case for
e.g. an action in a mount point.


/martin


From nobody Tue Aug 29 05:54:20 2017
Return-Path: 
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 2BEB1132320 for ; Tue, 29 Aug 2017 05:54:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 g3fWt701LYfI for ; Tue, 29 Aug 2017 05:54:16 -0700 (PDT)
Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (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 EF4641200F3 for ; Tue, 29 Aug 2017 05:54:15 -0700 (PDT)
Received: from cmgw3 (unknown [10.0.90.84]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id 6A2FA14063F for ; Tue, 29 Aug 2017 06:54:15 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with  id 30uC1w00R2SSUrH010uFmU; Tue, 29 Aug 2017 06:54:15 -0600
X-Authority-Analysis: v=2.2 cv=F98nTupN c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=KeKAF7QvOSUA:10 a=u07AKapRAAAA:8 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=_1n61X6UIw9fpt1jsnwA:9 a=OSdAWL87u_1_Iiba:21 a=UjIHFwsZ_RL7G_IZ:21 a=QEXdDO2ut3YA:10 a=SkebfZ6J2Mmvk2rLHZle:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=bjhnnM08C22HswioDfk3fhXrmU6nYfzsotdIAqFWe8M=; b=dRAb8AmlE9xbwhDJjD7dVz8pri LWVgxR7XgtEHbeIq4MEaAqZrwiIeOQWf9pLY6+5uA++K3zH5JaZHUhBg3Z4tSenz57K0gqFPU40Vy ZmOjJFMFSI9xB5AND6RUqb6sj;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:38695 helo=[11.4.0.6]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dmg20-003uyn-5d; Tue, 29 Aug 2017 06:54:12 -0600
From: Lou Berger 
To: Martin Bjorklund 
CC: , 
Date: Tue, 29 Aug 2017 08:54:10 -0400
Message-ID: <15e2e0e6950.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <20170829.144409.1459812722022735947.mbj@tail-f.com>
References: <81b138c6-9941-3313-979c-61edad7819a7@labn.net> <20170829.093743.762532630259333653.mbj@tail-f.com> <647a5ef0-968a-4eb7-322e-b3862a1252bd@labn.net> <20170829.144409.1459812722022735947.mbj@tail-f.com>
User-Agent: AquaMail/1.10.0-403 (build: 101000001)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dmg20-003uyn-5d
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([11.4.0.6]) [100.15.84.20]:38695
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Aug 2017 12:54:18 -0000

For me usage standpoint it really would be much simpler in the model 
definition and use for the mount point to behave like a container. What are 
your technical objections to this change? Note that the encoding from a 
protocol standpoint would be the same as a container.

Thanks
Lou


On August 29, 2017 8:46:18 AM Martin Bjorklund  wrote:

> Lou Berger  wrote:
>> On 08/29/2017 03:37 AM, Martin Bjorklund wrote:
>> > Lou Berger  wrote:
>> >> Lada,
>> >>
>> >>
>> >> On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
>> >>> Lou Berger píše v Po 28. 08. 2017 v 09:40 -0400:
>> >>>> Lada,
>> >>>>
>> >>>> On 8/28/2017 9:30 AM, Ladislav Lhotka wrote:
>> >>>>>> Can you please take a look at it and see if we have any other 
>> disconnects?
>> >>>>> This is really scary.
>> >>>> I agree!
>> >>>>
>> >>>>> How can we expect poor data modellers to understand the
>> >>>>> concept if we have such fundamental disconnects, after so many hours of
>> >>>>> discussing it?
>> >>>> This highlights why getting the text in (any) document is so important,
>> >>>> and why discussions shouldn't be viewed as being closed until the impact
>> >>>> on the text is agreed to!
>> >>> I think many people still don't make much distinction between schema mount
>> >>> (manipulation of the schema) and data mount. I still believe we need to 
>> clearly
>> >>> separate these two concepts, preferably using two different mechanisms.
>> >>
>> >> Frankly, I'm focused on removing blocking issues on the current WG
>> >> deliverable, i.e., schema mount.
>> >> ...
>> >>>> Lou
>> >>>>
>> >>>> PS is your view aligned with martin or our example?
>> >>> If you mean shifting the XPath context node to the mount point 
>> instance, then
>> >>> yes.
>> >>
>> >> funny, you answered yes to a choice!  I was asking if you think the
>> >> mount point shows up as a node in the data tree, i.e., as shown in the
>> >> example in
>> >> https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B.1?
>> >>
>> >> from my perspective and my co-authors in the RTG area using schema
>> >> mount, we've never heard of a (filesystem) mount point that doesn't show
>> >> in the (directory) structure and this is the mental analogue we've been
>> >> assuming. Since there never was an explicit example/discussion or text
>> >> to dissuade us of this
>> >
>> > The current text says:
>> >
>> >   A "container" or "list" node becomes a mount point if the
>> >   "mount-point" extension (defined in the "ietf-yang-schema-mount"
>> >   module) is used in its definition.
>>
>> interesting, read that a few times to (now) get the gist of your intent.
>>
>> >
>> > But of course we should clarify this.
>> >
>>
>>
>>
>> >> , this disconnect was never noticed.  Certainly
>> >> this needs to be explicit in the document (either way). The following
>> >> change could be made to the schema mount draft (at a minimum):
>> >>
>> >> OLD
>> >>           A mount point defines a place in the node hierarchy where
>> >>           other data models may be attached. A server that implements a
>> >> NEW
>> >>           A mount point defines a node in a data tree under which
>> >> instances of
>> >>           other data models may be attached. A server that implements a
>> >
>> > I strongly object to letting the extension define a new data node.
>>
>> > This would be a new type of data node that presumably look a lot like
>> > a container,
>>
>> agreed, just like a mount point looks a lot like a directory in a unix
>> file system.
>>
>> > and you'd have to define all sorts of rules for this new
>> > node (how it is encoded in XML, JSON, CBOR; how it is handled in
>> > edit-config, how it is mapped to RESTCONF resources etc etc).
>>
>> I'm don't see this, the rules would be the same as a container, as in
>> "mount points in data trees are encoded identically as containers".
>>
>> >
>> > If you thought that the extension implicitly creates a node, adding an
>> > explicit container won't do any harm; it will not change the schema
>> > tree from what you thought it was.
>>
>> Well we could make this work, but it feels like every model that uses
>> schema has added complexity to its definition and use to perhaps avoid
>> making some minor tooling changes.  Keep in mind that any use of the
>> mount point extension will required changes in tooling.
>>
>> >
>> > But I think we should also restrict the mount-point extension so that
>> > there cannot be more than one mount-point in a given container.
>> >
>> In this case, I'd go further and say that the only thing in the
>> container (of the module schema) is the mount point and a mount point
>> extension is only valid within a container. (Then the semantics are the
>> same as we expected, just the syntax is different.)
>
> I was thinking about this as well, but I thought that maybe rejecting
> any other data node is a CLR.  Maybe there is a good use case for
> e.g. an action in a mount point.
>
>
> /martin
>



From nobody Tue Aug 29 06:02:50 2017
Return-Path: 
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 683001326EA for ; Tue, 29 Aug 2017 06:02:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 EXTwSnKe0qSc for ; Tue, 29 Aug 2017 06:02:45 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 07655132055 for ; Tue, 29 Aug 2017 06:02:45 -0700 (PDT)
Received: from mars.tail-f.com (unknown [173.38.220.44]) by mail.tail-f.com (Postfix) with ESMTPSA id 0E8331AE00A0; Tue, 29 Aug 2017 15:02:43 +0200 (CEST)
To: Lou Berger 
References: <7c99497f-d719-0fe2-01f5-a06d53c8fc68@labn.net> <1503929779.1715.65.camel@nic.cz> <81b138c6-9941-3313-979c-61edad7819a7@labn.net> <20170829.093743.762532630259333653.mbj@tail-f.com> <647a5ef0-968a-4eb7-322e-b3862a1252bd@labn.net>
Cc: Martin Bjorklund , netmod@ietf.org
From: Per Hedeland 
Message-ID: <59A565F3.5030808@tail-f.com>
Date: Tue, 29 Aug 2017 15:02:43 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <647a5ef0-968a-4eb7-322e-b3862a1252bd@labn.net>
Content-Type: text/plain; charset=iso-8859-15
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Aug 2017 13:02:48 -0000

On 2017-08-29 14:34, Lou Berger wrote:
> On 08/29/2017 03:37 AM, Martin Bjorklund wrote:
>> Lou Berger  wrote:
>>> Lada,
>>>
>>>
>>> On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
>>>> Lou Berger pae v Po 28. 08. 2017 v 09:40 -0400:
>>>>> Lada,
>>>>>
>>>>> On 8/28/2017 9:30 AM, Ladislav Lhotka wrote:
>>>>>>> Can you please take a look at it and see if we have any other disconnects?
>>>>>> This is really scary. 
>>>>> I agree!
>>>>>
>>>>>> How can we expect poor data modellers to understand the
>>>>>> concept if we have such fundamental disconnects, after so many hours of
>>>>>> discussing it?
>>>>> This highlights why getting the text in (any) document is so important,
>>>>> and why discussions shouldn't be viewed as being closed until the impact
>>>>> on the text is agreed to!
>>>> I think many people still don't make much distinction between schema mount
>>>> (manipulation of the schema) and data mount. I still believe we need to clearly
>>>> separate these two concepts, preferably using two different mechanisms.
>>>
>>> Frankly, I'm focused on removing blocking issues on the current WG
>>> deliverable, i.e., schema mount.
>>> ...
>>>>> Lou
>>>>>
>>>>> PS is your view aligned with martin or our example?
>>>> If you mean shifting the XPath context node to the mount point instance, then
>>>> yes.
>>>
>>> funny, you answered yes to a choice!  I was asking if you think the
>>> mount point shows up as a node in the data tree, i.e., as shown in the
>>> example in
>>> https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B.1?
>>>
>>> from my perspective and my co-authors in the RTG area using schema
>>> mount, we've never heard of a (filesystem) mount point that doesn't show
>>> in the (directory) structure and this is the mental analogue we've been
>>> assuming. Since there never was an explicit example/discussion or text
>>> to dissuade us of this
>>
>> The current text says:
>>
>>   A "container" or "list" node becomes a mount point if the
>>   "mount-point" extension (defined in the "ietf-yang-schema-mount"
>>   module) is used in its definition.
> 
> interesting, read that a few times to (now) get the gist of your intent.
> 
>>
>> But of course we should clarify this.
>>
> 
> 
> 
>>> , this disconnect was never noticed.  Certainly
>>> this needs to be explicit in the document (either way). The following
>>> change could be made to the schema mount draft (at a minimum):
>>>
>>> OLD
>>>           A mount point defines a place in the node hierarchy where
>>>           other data models may be attached. A server that implements a
>>> NEW
>>>           A mount point defines a node in a data tree under which
>>> instances of
>>>           other data models may be attached. A server that implements a
>>
>> I strongly object to letting the extension define a new data node.
> 
>> This would be a new type of data node that presumably look a lot like
>> a container, 
> 
> agreed, just like a mount point looks a lot like a directory in a unix
> file system.

It seems to me that the schema mount concept is 100% equivalent to the
Unix file system analogy in this particular respect. You need a
pre-existing directory to mount a remote file system (or for that matter
a disk device). The directory gains the property of being a mount point
by the process of mounting, and loses it by the process of unmounting:

# mount earth:/home /foo
mount: /foo: No such file or directory
# mkdir /foo
# mount earth:/home /foo
# ls /foo
(... lots of user directories ...)
# umount /foo
# ls /foo
#

--Per

>> and you'd have to define all sorts of rules for this new
>> node (how it is encoded in XML, JSON, CBOR; how it is handled in
>> edit-config, how it is mapped to RESTCONF resources etc etc).
> 
> I'm don't see this, the rules would be the same as a container, as in
> "mount points in data trees are encoded identically as containers".
> 
>>
>> If you thought that the extension implicitly creates a node, adding an
>> explicit container won't do any harm; it will not change the schema
>> tree from what you thought it was.
> 
> Well we could make this work, but it feels like every model that uses
> schema has added complexity to its definition and use to perhaps avoid
> making some minor tooling changes.  Keep in mind that any use of the
> mount point extension will required changes in tooling.
> 
>>
>> But I think we should also restrict the mount-point extension so that
>> there cannot be more than one mount-point in a given container.
>>
> In this case, I'd go further and say that the only thing in the
> container (of the module schema) is the mount point and a mount point
> extension is only valid within a container. (Then the semantics are the
> same as we expected, just the syntax is different.)
> 
> Lou
> 
> 
>>
>> /martin
>>
>>
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Tue Aug 29 06:41:07 2017
Return-Path: 
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 4632213217D for ; Tue, 29 Aug 2017 06:41:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 vEYhyZJ06viC for ; Tue, 29 Aug 2017 06:41:04 -0700 (PDT)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 DE56E132C4C for ; Tue, 29 Aug 2017 06:40:59 -0700 (PDT)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id AD8C21E0E6E for ; Tue, 29 Aug 2017 07:40:58 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id 31gu1w01P2SSUrH011gxJE; Tue, 29 Aug 2017 07:40:58 -0600
X-Authority-Analysis: v=2.2 cv=IspuSP3g c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=KeKAF7QvOSUA:10 a=u07AKapRAAAA:8 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=EwEooPLsBYmfBx2WU6oA:9 a=J4lT-D8vVw5ktCCS:21 a=VNpXgIbHjyh3UvqL:21 a=QEXdDO2ut3YA:10 a=SkebfZ6J2Mmvk2rLHZle:22 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=lagfsn6uQTHeg4tN+N8mXKrrCiSgVQ9Bb95IlkPPMwg=; b=Qc3QOP6dK6SOXayylMyT+XexaV WuHWHESt/FqSWJiVXAw5m52ktnSQPTT0+pRmLHTedqYU5SHoLM64Hxpgc9bxmtqoN4e8z/LjFaxCu cDAE3ikxsQMDKbI1qFPHViQvE;
Received: from [172.56.3.121] (port=35681 helo=[IPV6:2607:fb90:138f:8a15:0:49:a23d:a001]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dmglC-0042eV-F7; Tue, 29 Aug 2017 07:40:54 -0600
From: Lou Berger 
To: Per Hedeland 
CC: Martin Bjorklund , 
Date: Tue, 29 Aug 2017 09:40:51 -0400
Message-ID: <15e2e384bf8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <59A565F3.5030808@tail-f.com>
References: <7c99497f-d719-0fe2-01f5-a06d53c8fc68@labn.net> <1503929779.1715.65.camel@nic.cz> <81b138c6-9941-3313-979c-61edad7819a7@labn.net> <20170829.093743.762532630259333653.mbj@tail-f.com> <647a5ef0-968a-4eb7-322e-b3862a1252bd@labn.net> <59A565F3.5030808@tail-f.com>
User-Agent: AquaMail/1.10.0-403 (build: 101000001)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 172.56.3.121
X-Exim-ID: 1dmglC-0042eV-F7
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: ([IPV6:2607:fb90:138f:8a15:0:49:a23d:a001]) [172.56.3.121]:35681
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Aug 2017 13:41:06 -0000

On August 29, 2017 9:03:22 AM Per Hedeland  wrote:

> On 2017-08-29 14:34, Lou Berger wrote:
>> On 08/29/2017 03:37 AM, Martin Bjorklund wrote:
>>> Lou Berger  wrote:
>>>> Lada,
>>>>
>>>>
>>>> On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
>>>>> Lou Berger píae v Po 28. 08. 2017 v 09:40 -0400:
>>>>>> Lada,
>>>>>>
>>>>>> On 8/28/2017 9:30 AM, Ladislav Lhotka wrote:
>>>>>>>> Can you please take a look at it and see if we have any other disconnects?
>>>>>>> This is really scary.
>>>>>> I agree!
>>>>>>
>>>>>>> How can we expect poor data modellers to understand the
>>>>>>> concept if we have such fundamental disconnects, after so many hours of
>>>>>>> discussing it?
>>>>>> This highlights why getting the text in (any) document is so important,
>>>>>> and why discussions shouldn't be viewed as being closed until the impact
>>>>>> on the text is agreed to!
>>>>> I think many people still don't make much distinction between schema mount
>>>>> (manipulation of the schema) and data mount. I still believe we need to clearly
>>>>> separate these two concepts, preferably using two different mechanisms.
>>>>
>>>> Frankly, I'm focused on removing blocking issues on the current WG
>>>> deliverable, i.e., schema mount.
>>>> ...
>>>>>> Lou
>>>>>>
>>>>>> PS is your view aligned with martin or our example?
>>>>> If you mean shifting the XPath context node to the mount point instance, then
>>>>> yes.
>>>>
>>>> funny, you answered yes to a choice!  I was asking if you think the
>>>> mount point shows up as a node in the data tree, i.e., as shown in the
>>>> example in
>>>> https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B.1?
>>>>
>>>> from my perspective and my co-authors in the RTG area using schema
>>>> mount, we've never heard of a (filesystem) mount point that doesn't show
>>>> in the (directory) structure and this is the mental analogue we've been
>>>> assuming. Since there never was an explicit example/discussion or text
>>>> to dissuade us of this
>>>
>>> The current text says:
>>>
>>>   A "container" or "list" node becomes a mount point if the
>>>   "mount-point" extension (defined in the "ietf-yang-schema-mount"
>>>   module) is used in its definition.
>>
>> interesting, read that a few times to (now) get the gist of your intent.
>>
>>>
>>> But of course we should clarify this.
>>>
>>
>>
>>
>>>> , this disconnect was never noticed.  Certainly
>>>> this needs to be explicit in the document (either way). The following
>>>> change could be made to the schema mount draft (at a minimum):
>>>>
>>>> OLD
>>>>           A mount point defines a place in the node hierarchy where
>>>>           other data models may be attached. A server that implements a
>>>> NEW
>>>>           A mount point defines a node in a data tree under which
>>>> instances of
>>>>           other data models may be attached. A server that implements a
>>>
>>> I strongly object to letting the extension define a new data node.
>>
>>> This would be a new type of data node that presumably look a lot like
>>> a container,
>>
>> agreed, just like a mount point looks a lot like a directory in a unix
>> file system.
>
> It seems to me that the schema mount concept is 100% equivalent to the
> Unix file system analogy in this particular respect. You need a
> pre-existing directory to mount a remote file system (or for that matter
> a disk device). The directory gains the property of being a mount point
> by the process of mounting, and loses it by the process of unmounting:
>

This point was at the root of the discussion of whether or not we even 
needed the mount Point extension at all and whether just having the scheme 
amount module identify mounts with in a container was sufficient.

I believe the perspective from Lada and Martin was that it didn't really 
add value. Those of us in the routing area working on models using scheme 
mount uniformly agreed that it was important to keep the extension to 
enable module designers to indicate to implementers where Mount points were 
intended to be used in the modules they were defining and for client users/ 
implementers to reliably identify where modules would be mounted. We also 
thought that the use of the mount Point extension in modules would have 
certain tooling benefits over just putting a comment in the description of 
a container that it was to be used as a mount point.

Yes, we can make the current node-less Mount Point extension work, but it 
certainly seems like a clumsier and more complex solution

Lou




> # mount earth:/home /foo
> mount: /foo: No such file or directory
> # mkdir /foo
> # mount earth:/home /foo
> # ls /foo
> (... lots of user directories ...)
> # umount /foo
> # ls /foo
> #
>
> --Per
>
>>> and you'd have to define all sorts of rules for this new
>>> node (how it is encoded in XML, JSON, CBOR; how it is handled in
>>> edit-config, how it is mapped to RESTCONF resources etc etc).
>>
>> I'm don't see this, the rules would be the same as a container, as in
>> "mount points in data trees are encoded identically as containers".
>>
>>>
>>> If you thought that the extension implicitly creates a node, adding an
>>> explicit container won't do any harm; it will not change the schema
>>> tree from what you thought it was.
>>
>> Well we could make this work, but it feels like every model that uses
>> schema has added complexity to its definition and use to perhaps avoid
>> making some minor tooling changes.  Keep in mind that any use of the
>> mount point extension will required changes in tooling.
>>
>>>
>>> But I think we should also restrict the mount-point extension so that
>>> there cannot be more than one mount-point in a given container.
>>>
>> In this case, I'd go further and say that the only thing in the
>> container (of the module schema) is the mount point and a mount point
>> extension is only valid within a container. (Then the semantics are the
>> same as we expected, just the syntax is different.)
>>
>> Lou
>>
>>
>>>
>>> /martin
>>>
>>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>



From nobody Tue Aug 29 07:07:33 2017
Return-Path: 
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 EBDC5132CF2 for ; Tue, 29 Aug 2017 07:07:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 W_OhqORVnTUx for ; Tue, 29 Aug 2017 07:07:29 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id D4E1B132C36 for ; Tue, 29 Aug 2017 07:07:28 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 4221C1820E76; Tue, 29 Aug 2017 16:07:03 +0200 (CEST)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id E20E61820E71; Tue, 29 Aug 2017 16:07:00 +0200 (CEST)
From: Ladislav Lhotka 
To: Lou Berger , Martin Bjorklund 
Cc: netmod@ietf.org
In-Reply-To: <81b138c6-9941-3313-979c-61edad7819a7@labn.net>
References:  <20170828.122845.1527315474517128533.mbj@tail-f.com>  <20170828.133507.2047018591752852829.mbj@tail-f.com>  <1503927029.1715.46.camel@nic.cz> <7c99497f-d719-0fe2-01f5-a06d53c8fc68@labn.net> <1503929779.1715.65.camel@nic.cz> <81b138c6-9941-3313-979c-61edad7819a7@labn.net>
Mail-Followup-To: Lou Berger , Martin Bjorklund , netmod@ietf.org
Date: Tue, 29 Aug 2017 16:07:52 +0200
Message-ID: <87shgacvrb.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Aug 2017 14:07:33 -0000

Lou Berger  writes:

> Lada,
>
>
> On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
>> Lou Berger p=C3=AD=C5=A1e v Po 28. 08. 2017 v 09:40 -0400:
>>> Lada,
>>>
>>> On 8/28/2017 9:30 AM, Ladislav Lhotka wrote:
>>>>> Can you please take a look at it and see if we have any other disconn=
ects?
>>>> This is really scary.=20
>>> I agree!
>>>
>>>> How can we expect poor data modellers to understand the
>>>> concept if we have such fundamental disconnects, after so many hours of
>>>> discussing it?
>>> This highlights why getting the text in (any) document is so important,
>>> and why discussions shouldn't be viewed as being closed until the impact
>>> on the text is agreed to!
>> I think many people still don't make much distinction between schema mou=
nt
>> (manipulation of the schema) and data mount. I still believe we need to =
clearly
>> separate these two concepts, preferably using two different mechanisms.
>
> Frankly, I'm focused on removing blocking issues on the current WG
> deliverable, i.e., schema mount.

Sure, and one serious issue is the complexity of the spec that makes it
difficult to understand. I have always insisted that the two mechanisms
- inline and use-schema - are fundamentally different concepts. The
former is basically data mount while the latter is an additional
mechanism for schema modularity comparable to augment.

Presenting them together is IMO confusing and wrong. For the use-schema
case, I would even suggest to avoid the term "mount".

> ...
>>> Lou
>>>
>>> PS is your view aligned with martin or our example?
>> If you mean shifting the XPath context node to the mount point instance,=
 then
>> yes.
>
> funny, you answered yes to a choice!=C2=A0 I was asking if you think the

Not at all, I wasn't sure what you meant by "our example". What I wanted
to say is that I am aligned with Martin on his exposition of open issue
#1 that started this thread.

The mount point directly under choice is of course broken, and because
of it I couldn't use the schema from the most recent NI draft
revision in my presentation in Prague. I just forgot to discuss this
issue with you.

> mount point shows up as a node in the data tree, i.e., as shown in the
> example in
> https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B.1?

I was pretty clear in my previous reply: "The mount-point extension
itself generates no extra node." The mount point does show up in the data
tree if it is instantiated, because it it defined by a "container" or
"list" statement. But the "mount-point" extension just tags this already
existing data node as a mount point.

>
> from my perspective and my co-authors in the RTG area using schema
> mount, we've never heard of a (filesystem) mount point that doesn't show
> in the (directory) structure and this is the mental analogue we've been
> assuming. Since there never was an explicit example/discussion or text
> to dissuade us of this, this disconnect was never noticed.=C2=A0 Certainly

I agree it would be useful to extend some of the examples so as to
include a tree view of the resulting schema.

> this needs to be explicit in the document (either way). The following
> change could be made to the schema mount draft (at a minimum):
>
> OLD
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A mount point defi=
nes a place in the node hierarchy where
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 other data models =
may be attached. A server that implements a
> NEW
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A mount point defi=
nes a node in a data tree under which
> instances of
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 other data models =
may be attached. A server that implements
> a

You nicely illustrate the confusion between data mount and schema
mount. Schema mount (or the "use-schema" approach at least) is a method
of schema construction analogical to an augment. This really means
nothing in terms of instance data - similarly, we don't expect instance
data modelled with an augment to be augmented somehow into the data
tree. The schema is constructed first and it describes constraints for a
data tree.

Note that this is different for the "inline" case because it relies on
instance data (YANG library) appearing somehow under the mount point.

Lada

>
> Lou
>
>> Lada
>>
>>>> Lada
>>>>
>

--=20
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Aug 29 07:27:06 2017
Return-Path: 
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 1642A132CF7 for ; Tue, 29 Aug 2017 07:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, 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 UtpBfSlTJ29V for ; Tue, 29 Aug 2017 07:27:02 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F3D96132A81 for ; Tue, 29 Aug 2017 07:27:01 -0700 (PDT)
Received: from mars.tail-f.com (unknown [173.38.220.44]) by mail.tail-f.com (Postfix) with ESMTPSA id BF0B21AE00A0; Tue, 29 Aug 2017 16:27:00 +0200 (CEST)
To: Lou Berger 
References: <7c99497f-d719-0fe2-01f5-a06d53c8fc68@labn.net> <1503929779.1715.65.camel@nic.cz> <81b138c6-9941-3313-979c-61edad7819a7@labn.net> <20170829.093743.762532630259333653.mbj@tail-f.com> <647a5ef0-968a-4eb7-322e-b3862a1252bd@labn.net> <59A565F3.5030808@tail-f.com> <15e2e384bf8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
Cc: Martin Bjorklund , netmod@ietf.org
From: Per Hedeland 
Message-ID: <59A579B4.7010203@tail-f.com>
Date: Tue, 29 Aug 2017 16:27:00 +0200
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <15e2e384bf8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Aug 2017 14:27:05 -0000

On 2017-08-29 15:40, Lou Berger wrote:
> 
> 
> On August 29, 2017 9:03:22 AM Per Hedeland  wrote:
> 
>> On 2017-08-29 14:34, Lou Berger wrote:
>>> On 08/29/2017 03:37 AM, Martin Bjorklund wrote:
>>>> Lou Berger  wrote:
>>>>> Lada,
>>>>>
>>>>>
>>>>> On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
>>>>>> Lou Berger píae v Po 28. 08. 2017 v 09:40 -0400:
>>>>>>> Lada,
>>>>>>>
>>>>>>> On 8/28/2017 9:30 AM, Ladislav Lhotka wrote:
>>>>>>>>> Can you please take a look at it and see if we have any other disconnects?
>>>>>>>> This is really scary.
>>>>>>> I agree!
>>>>>>>
>>>>>>>> How can we expect poor data modellers to understand the
>>>>>>>> concept if we have such fundamental disconnects, after so many hours of
>>>>>>>> discussing it?
>>>>>>> This highlights why getting the text in (any) document is so important,
>>>>>>> and why discussions shouldn't be viewed as being closed until the impact
>>>>>>> on the text is agreed to!
>>>>>> I think many people still don't make much distinction between schema mount
>>>>>> (manipulation of the schema) and data mount. I still believe we need to clearly
>>>>>> separate these two concepts, preferably using two different mechanisms.
>>>>>
>>>>> Frankly, I'm focused on removing blocking issues on the current WG
>>>>> deliverable, i.e., schema mount.
>>>>> ...
>>>>>>> Lou
>>>>>>>
>>>>>>> PS is your view aligned with martin or our example?
>>>>>> If you mean shifting the XPath context node to the mount point instance, then
>>>>>> yes.
>>>>>
>>>>> funny, you answered yes to a choice!  I was asking if you think the
>>>>> mount point shows up as a node in the data tree, i.e., as shown in the
>>>>> example in
>>>>> https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B.1?
>>>>>
>>>>> from my perspective and my co-authors in the RTG area using schema
>>>>> mount, we've never heard of a (filesystem) mount point that doesn't show
>>>>> in the (directory) structure and this is the mental analogue we've been
>>>>> assuming. Since there never was an explicit example/discussion or text
>>>>> to dissuade us of this
>>>>
>>>> The current text says:
>>>>
>>>>   A "container" or "list" node becomes a mount point if the
>>>>   "mount-point" extension (defined in the "ietf-yang-schema-mount"
>>>>   module) is used in its definition.
>>>
>>> interesting, read that a few times to (now) get the gist of your intent.
>>>
>>>>
>>>> But of course we should clarify this.
>>>>
>>>
>>>
>>>
>>>>> , this disconnect was never noticed.  Certainly
>>>>> this needs to be explicit in the document (either way). The following
>>>>> change could be made to the schema mount draft (at a minimum):
>>>>>
>>>>> OLD
>>>>>           A mount point defines a place in the node hierarchy where
>>>>>           other data models may be attached. A server that implements a
>>>>> NEW
>>>>>           A mount point defines a node in a data tree under which
>>>>> instances of
>>>>>           other data models may be attached. A server that implements a
>>>>
>>>> I strongly object to letting the extension define a new data node.
>>>
>>>> This would be a new type of data node that presumably look a lot like
>>>> a container,
>>>
>>> agreed, just like a mount point looks a lot like a directory in a unix
>>> file system.
>>
>> It seems to me that the schema mount concept is 100% equivalent to the
>> Unix file system analogy in this particular respect. You need a
>> pre-existing directory to mount a remote file system (or for that matter
>> a disk device). The directory gains the property of being a mount point
>> by the process of mounting, and loses it by the process of unmounting:
>>
> 
> This point was at the root of the discussion of whether or not we even needed the mount Point extension at all and whether just having the scheme amount module identify mounts with in a container was
> sufficient.
> 
> I believe the perspective from Lada and Martin was that it didn't really add value. Those of us in the routing area working on models using scheme mount uniformly agreed that it was important to keep
> the extension to enable module designers to indicate to implementers where Mount points were intended to be used in the modules they were defining and for client users/ implementers to reliably
> identify where modules would be mounted. We also thought that the use of the mount Point extension in modules would have certain tooling benefits over just putting a comment in the description of a
> container that it was to be used as a mount point.
> 
> Yes, we can make the current node-less Mount Point extension work, but it certainly seems like a clumsier and more complex solution

Well, my comment *only* addressed your repeated claim that it was
different from file system semantics - I can't see that it is. The
mount-point extension does not define a data node. Mounting a file
system does not create a directory node. Whether this is a strong
argument for the non-data-node-defining semantics of mount-point is
perhaps a subjective matter.

--Per

> Lou
> 
> 
> 
> 
>> # mount earth:/home /foo
>> mount: /foo: No such file or directory
>> # mkdir /foo
>> # mount earth:/home /foo
>> # ls /foo
>> (... lots of user directories ...)
>> # umount /foo
>> # ls /foo
>> #
>>
>> --Per
>>
>>>> and you'd have to define all sorts of rules for this new
>>>> node (how it is encoded in XML, JSON, CBOR; how it is handled in
>>>> edit-config, how it is mapped to RESTCONF resources etc etc).
>>>
>>> I'm don't see this, the rules would be the same as a container, as in
>>> "mount points in data trees are encoded identically as containers".
>>>
>>>>
>>>> If you thought that the extension implicitly creates a node, adding an
>>>> explicit container won't do any harm; it will not change the schema
>>>> tree from what you thought it was.
>>>
>>> Well we could make this work, but it feels like every model that uses
>>> schema has added complexity to its definition and use to perhaps avoid
>>> making some minor tooling changes.  Keep in mind that any use of the
>>> mount point extension will required changes in tooling.
>>>
>>>>
>>>> But I think we should also restrict the mount-point extension so that
>>>> there cannot be more than one mount-point in a given container.
>>>>
>>> In this case, I'd go further and say that the only thing in the
>>> container (of the module schema) is the mount point and a mount point
>>> extension is only valid within a container. (Then the semantics are the
>>> same as we expected, just the syntax is different.)
>>>
>>> Lou
>>>
>>>
>>>>
>>>> /martin
>>>>
>>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>
>>
> 
> 


From nobody Tue Aug 29 07:27:23 2017
Return-Path: 
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 134A8132D52 for ; Tue, 29 Aug 2017 07:27:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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
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 8glDm6SpYkRs for ; Tue, 29 Aug 2017 07:27:06 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97AAF132A81 for ; Tue, 29 Aug 2017 07:27:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7059; q=dns/txt; s=iport; t=1504016825; x=1505226425; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=swh55UGQ2xVtd9mQaWyAVaxWD/ZT27wZyWPzQkGAWwc=; b=O69rjdcM1sBJQGnWYHdkWsw1RRFu/wC1J0d2O8s2Dpn0nWKnaGMb2+2M 1oswNTNdZ4SKJdvDADooqmMLWzv0DUvoqyWL3dhEmP2IaKVPCoJKgN+My nxKOCnWfM1/xzqGbopAxqlEl3EId0ZPF8poTjaUlu2Gij/kF5ed8sCr4U 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAwB7eKVZ/xbLJq1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBgm+GW4sRkRiQaYdQhUcChFMUAQIBAQEBAQEBayiFGAEBAQECASNmCxg?= =?us-ascii?q?qAgJXBgEMCAEBiiUIsQ+CJyeLOAEBAQEBAQEBAgEBAQEBAQEBAR+DKoNQgg6Cf?= =?us-ascii?q?YRPgzmCYQWgaJRMi1KHGY1QiHI2IYENMiEIHBWFYRyBaD+JF4JAAQEB?=
X-IronPort-AV: E=Sophos;i="5.41,445,1498521600";  d="scan'208,217";a="657101976"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Aug 2017 14:27:03 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v7TER3fs021282; Tue, 29 Aug 2017 14:27:03 GMT
To: Xufeng Liu , Per Hedeland , Ladislav Lhotka , "'netmod@ietf.org'" 
References:  <20170824060900.u5kcffzvwjr7mmob@elstar.local> <152f24b2-7947-9c76-714c-af226ab3fe91@tail-f.com> <8760ddc676.fsf@nic.cz> <599F0991.7020900@tail-f.com>  <20170825125254.6nhnzkrar6fhu7zr@elstar.local>  <20170828154640.pzg7jfy5uepkb22q@elstar.local>
From: Robert Wilton 
Message-ID: 
Date: Tue, 29 Aug 2017 15:27:03 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20170828154640.pzg7jfy5uepkb22q@elstar.local>
Content-Type: multipart/alternative; boundary="------------10B542FCF0AB0BE9E6ADE825"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Aug 2017 14:27:08 -0000

This is a multi-part message in MIME format.
--------------10B542FCF0AB0BE9E6ADE825
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit


On 28/08/2017 16:46, Juergen Schoenwaelder wrote:
> On Mon, Aug 28, 2017 at 12:58:59PM +0000, Xufeng Liu wrote:
>> [Xufeng] [0..9] is still compliant with the XSD pattern specified by
>> YANG 1.0 and 1.1. Using [0..9] instead of [\d] will make the
>> implementations with native POSIX RegEx easier without the need for
>> a tool to inspect every element of the RegEx pattern.
> Yes, but then \d is legal in YANG (and it is used in a couple of
> published RFCs).
I entirely agree that YANG regular expressions must be legal XML Schema 
regular expressions.

However, I don't think that the majority of YANG implementations are 
going to want to either use libxml or write their own implementation of 
the XML RE language.  Instead it is desirable that they can use whatever 
standard regex implementation comes with their language, or is readily 
available in a library.

Most of the pattern statements I see in YANG modules use a basic subset 
of regular expressions, and hence it looks like they can often be used 
by most RE engines, perhaps with some trivial tweaks or conversions.  
However, there is no formal guidance recommending that pattern 
statements in standard modules are restricted to a subset of XML RE.

Hence, ideally I would like 6087bis to state that pattern statements 
SHOULD also conform to the following additional RE syntax restrictions, 
which I think should make them easy to convert to most other standard 
regex implementations (subject to unicode support limitations):

(1) Allow \d, \D, \s, \S, \w and \W; but not inside character classes.
(2) Disallow \i, \c; and their negative equivalents.
(3) Disallow character class subtraction (e.g. "[A-Z-[RW]]").
(4) Limit the supported unicode categories to only the following 8. Both 
\p and \P syntax is supported, but not inside character classes:
   \p{L} or any kind of letter from any language.
   \p{Ll} a lowercase letter that has an uppercase variant.
   \p{Lu} an uppercase letter that has a lowercase variant.
   \p{Z} any kind of whitespace or invisible separator.
   \p{Zs} a whitespace character that is invisible, but does take up space.
   \p{Zl} a line separator character U+2028.
   \p{N} any kind of numeric character in any script.
   \p{Nd}: a digit zero through nine in any script except ideographic
(5) Disallow matching of unicode blocks.

Thanks,
Rob


>
> Educating _all_ module authors to write [0..9] instead of \d will
> likely be more expensive than improving the code of implementations
> that did not implement YANG entirely to accept \d.
>
> /js
>


--------------10B542FCF0AB0BE9E6ADE825
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    

    
On 28/08/2017 16:46, Juergen
      Schoenwaelder wrote:

    

    

      
On Mon, Aug 28, 2017 at 12:58:59PM +0000, Xufeng Liu wrote:


      

        
[Xufeng] [0..9] is still compliant with the XSD pattern specified by
YANG 1.0 and 1.1. Using [0..9] instead of [\d] will make the
implementations with native POSIX RegEx easier without the need for
a tool to inspect every element of the RegEx pattern.


      

      
Yes, but then \d is legal in YANG (and it is used in a couple of
published RFCs).

    

    I entirely agree that YANG regular expressions must be legal XML
    Schema regular expressions.

    

    However, I don't think that the majority of YANG implementations are
    going to want to either use libxml or write their own implementation
    of the XML RE language.  Instead it is desirable that they can use
    whatever standard regex implementation comes with their language, or
    is readily available in a library.

    

    Most of the pattern statements I see in YANG modules use a basic
    subset of regular expressions, and hence it looks like they can
    often be used by most RE engines, perhaps with some trivial tweaks
    or conversions.  However, there is no formal guidance recommending
    that pattern statements in standard modules are restricted to a
    subset of XML RE.

    

    Hence, ideally I would like 6087bis to state that pattern statements
    SHOULD also conform to the following additional RE syntax
    restrictions, which I think should make them easy to convert to most
    other standard regex implementations (subject to unicode support
    limitations):

    

    (1) Allow \d, \D, \s, \S, \w and \W; but not inside character
    classes.

    (2) Disallow \i, \c; and their negative equivalents.

    (3) Disallow character class subtraction (e.g. "[A-Z-[RW]]").

    (4) Limit the supported unicode categories to only the following 8. 
    Both \p and \P syntax is supported, but not inside character
    classes:

      \p{L} or any kind of letter from any language.

        \p{Ll} a lowercase letter that has an uppercase variant.

        \p{Lu} an uppercase letter that has a lowercase variant.

        \p{Z} any kind of whitespace or invisible separator.

        \p{Zs} a whitespace character that is invisible, but does take
      up space.

        \p{Zl} a line separator character U+2028.

        \p{N} any kind of numeric character in any script.

        \p{Nd}: a digit zero through nine in any script except
      ideographic 

    (5)
    Disallow matching of unicode blocks.

    

    Thanks,

    Rob

    

    

    

      

Educating _all_ module authors to write [0..9] instead of \d will
likely be more expensive than improving the code of implementations
that did not implement YANG entirely to accept \d.

/js



    

    

  


--------------10B542FCF0AB0BE9E6ADE825--


From nobody Tue Aug 29 09:15:46 2017
Return-Path: 
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 6607D132D60 for ; Tue, 29 Aug 2017 09:15:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 pGV7UmkqfufD for ; Tue, 29 Aug 2017 09:15:43 -0700 (PDT)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB0C1132D59 for ; Tue, 29 Aug 2017 09:15:42 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id v191so576082wmf.1 for ; Tue, 29 Aug 2017 09:15:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y4i8TG0nIAnT5+9PLAq4P0ubv+BYR80sx0szMKtxEHY=; b=kiakNFwBbZOr42AduzjOvrQAL1hlgtRBRWQM57mkDmwSG5Q+Ut7ZuWliS6h+pVAqBI 6Ooaivk0/M+6EMzFAB1jIVWGTQScfxOqq2kJJ/YN7iwYiSfpaYqoZ8Vjo9ImfkU27w6e KB6K75TmpqK2OpHQR+qLAoMVzcRpcNl8PbBIwX57236IKs+hG0F3x9Hp1HYhntBzwAQc 07KCe2+V2DqF4im78xL/ZD60aCsQThzabl5Ff/4gu3iZ5Zrnu8lw50Qu1AhmYunRtdFF ZHHVyRc7JkQ6x3UajB1xfFyok1R8tpZQnqKH/Qso68lMiDoN9iUXNOMb1erjCrlq9bY3 57Sg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=y4i8TG0nIAnT5+9PLAq4P0ubv+BYR80sx0szMKtxEHY=; b=JMlmyBV3s61aIYWsRQt04uNgV6w/qD4K22KrxYfz2lk6sVAJVfvmWsYE2x0o8lVGMN FiZPbd43yEAiJqMZaeYCAYQDCDoDsZgXQ/FWed4EMtPt6l4XAKu4ZRMaVSK10VJ/Etfz /PhyvFPaNVEsc4knP07pdZWohHud2zT99mTYGci0Y9Ea5CRocR/y+dHQn92cu/Jxn/sV c50pAypQ+L/StXZFX86WOjL6q+b//oChdhy10kfFyhx08mla7UfeDna4yMAB/E/kq6ce gbuyzebRpdSio8kEdGcNw/Ft/e/+do48vUJ6etLesoP1dNdC4wMRPHusaqs9TLqBhQPY m9RA==
X-Gm-Message-State: AHYfb5iznThMcXrNpKx5qfrkJft5dI+tDoMEaGdlb4nbw7mfK7JPvrx8 JUDha5WOQ8tCR5nbS5GDh7rLd4rlOAbW
X-Received: by 10.28.103.6 with SMTP id b6mr159079wmc.28.1504023341188; Tue, 29 Aug 2017 09:15:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.171.84 with HTTP; Tue, 29 Aug 2017 09:15:40 -0700 (PDT)
In-Reply-To: 
References:  <20170824060900.u5kcffzvwjr7mmob@elstar.local> <152f24b2-7947-9c76-714c-af226ab3fe91@tail-f.com> <8760ddc676.fsf@nic.cz> <599F0991.7020900@tail-f.com>  <20170825125254.6nhnzkrar6fhu7zr@elstar.local>  <20170828154640.pzg7jfy5uepkb22q@elstar.local> 
From: Andy Bierman 
Date: Tue, 29 Aug 2017 09:15:40 -0700
Message-ID: 
To: Robert Wilton 
Cc: Xufeng Liu , Per Hedeland ,  Ladislav Lhotka , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="001a114b30d8fc78a50557e6b8aa"
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Aug 2017 16:15:45 -0000

--001a114b30d8fc78a50557e6b8aa
Content-Type: text/plain; charset="UTF-8"

Hi,

I agree with Juergen that these proposed guidelines are not a good idea.
The priority order for YANG is (1) readers (2) writers and (3) toolmakers.
It seems trivial for group (3) to convert the XSD pattern to some other
format.
It seems difficult to train all the people in groups (1) and (2) that there
are lots of
special new rules to learn.


Andy


On Tue, Aug 29, 2017 at 7:27 AM, Robert Wilton  wrote:

>
> On 28/08/2017 16:46, Juergen Schoenwaelder wrote:
>
> On Mon, Aug 28, 2017 at 12:58:59PM +0000, Xufeng Liu wrote:
>
> [Xufeng] [0..9] is still compliant with the XSD pattern specified by
> YANG 1.0 and 1.1. Using [0..9] instead of [\d] will make the
> implementations with native POSIX RegEx easier without the need for
> a tool to inspect every element of the RegEx pattern.
>
> Yes, but then \d is legal in YANG (and it is used in a couple of
> published RFCs).
>
> I entirely agree that YANG regular expressions must be legal XML Schema
> regular expressions.
>
> However, I don't think that the majority of YANG implementations are going
> to want to either use libxml or write their own implementation of the XML
> RE language.  Instead it is desirable that they can use whatever standard
> regex implementation comes with their language, or is readily available in
> a library.
>
> Most of the pattern statements I see in YANG modules use a basic subset of
> regular expressions, and hence it looks like they can often be used by most
> RE engines, perhaps with some trivial tweaks or conversions.  However,
> there is no formal guidance recommending that pattern statements in
> standard modules are restricted to a subset of XML RE.
>
> Hence, ideally I would like 6087bis to state that pattern statements
> SHOULD also conform to the following additional RE syntax restrictions,
> which I think should make them easy to convert to most other standard regex
> implementations (subject to unicode support limitations):
>
> (1) Allow \d, \D, \s, \S, \w and \W; but not inside character classes.
> (2) Disallow \i, \c; and their negative equivalents.
> (3) Disallow character class subtraction (e.g. "[A-Z-[RW]]").
> (4) Limit the supported unicode categories to only the following 8.  Both
> \p and \P syntax is supported, but not inside character classes:
>   \p{L} or any kind of letter from any language.
>   \p{Ll} a lowercase letter that has an uppercase variant.
>   \p{Lu} an uppercase letter that has a lowercase variant.
>   \p{Z} any kind of whitespace or invisible separator.
>   \p{Zs} a whitespace character that is invisible, but does take up space.
>   \p{Zl} a line separator character U+2028.
>   \p{N} any kind of numeric character in any script.
>   \p{Nd}: a digit zero through nine in any script except ideographic
> (5) Disallow matching of unicode blocks.
>
> Thanks,
> Rob
>
>
> Educating _all_ module authors to write [0..9] instead of \d will
> likely be more expensive than improving the code of implementations
> that did not implement YANG entirely to accept \d.
>
> /js
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

--001a114b30d8fc78a50557e6b8aa
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

I agree with Juergen that these pro=
posed guidelines are not a good idea.
The priority order for YANG=
 is (1) readers (2) writers and (3) toolmakers.
It seems trivial =
for group (3) to convert the XSD pattern to some other format.
It=
 seems difficult to train all the people in groups (1) and (2) that there a=
re lots of
special new rules to learn.

<=
br>
Andy


=

On Tue, Aug 29, 2017 at 7:27 AM, Robert Wilton <=
span dir=3D"ltr"><rwilton@cisco.com> wrote:

 =20
   =20
 =20
  

    

    
On 28/08/2017 16:46=
, Juergen
      Schoenwaelder wrote:

    

    

      
On Mon, Aug 28, 2017 at 12:58:59PM +0000, Xufeng Liu wrote:


      

        
[Xufeng] [0..9] is still compliant with the XSD pattern specif=
ied by
YANG 1.0 and 1.1. Using [0..9] instead of [\d] will make the
implementations with native POSIX RegEx easier without the need for
a tool to inspect every element of the RegEx pattern.


      

      
Yes, but then \d is legal in YANG (and it is used in a couple of
published RFCs).

    

    I entirely agree that YANG regular expressions must be legal XML
    Schema regular expressions.

    

    However, I don't think that the majority of YANG implementations ar=
e
    going to want to either use libxml or write their own implementation
    of the XML RE language.=C2=A0 Instead it is desirable that they can use
    whatever standard regex implementation comes with their language, or
    is readily available in a library.

    

    Most of the pattern statements I see in YANG modules use a basic
    subset of regular expressions, and hence it looks like they can
    often be used by most RE engines, perhaps with some trivial tweaks
    or conversions.=C2=A0 However, there is no formal guidance recommending
    that pattern statements in standard modules are restricted to a
    subset of XML RE.

    

    Hence, ideally I would like 6087bis to state that pattern statements
    SHOULD also conform to the following additional RE syntax
    restrictions, which I think should make them easy to convert to most
    other standard regex implementations (subject to unicode support
    limitations):

    

    (1) Allow \d, \D, \s, \S, \w and \W; but not inside character
    classes.

    (2) Disallow \i, \c; and their negative equivalents.

    (3) Disallow character class subtraction (e.g. "[A-Z-[RW]]").=


    (4) Limit the supported unicode categories to only the following 8.=C2=
=A0
    Both \p and \P syntax is supported, but not inside character
    classes:

    =C2=A0 \p{L} or any kind of letter from any language.

      =C2=A0 \p{Ll} a lowercase letter that has an uppercase variant.

      =C2=A0 \p{Lu} an uppercase letter that has a lowercase variant.

      =C2=A0 \p{Z} any kind of whitespace or invisible separator.

      =C2=A0 \p{Zs} a whitespace character that is invisible, but does take
      up space.

      =C2=A0 \p{Zl} a line separator character U+2028.

      =C2=A0 \p{N} any kind of numeric character in any script.

      =C2=A0 \p{Nd}: a digit zero through nine in any script except
      ideographic 

    (5)
    Disallow matching of unicode blocks.

    

    Thanks,

    Rob

    

    

    

      
Educating _all_ module authors to write [0..9] instead of \d wil=
l
likely be more expensive than improving the code of implementations
that did not implement YANG entirely to accept \d.

/js



    

    

  



_______________________________________________

netmod mailing list

netmod@ietf.org

https://www.ietf.org/mailman/listinfo/netmod




--001a114b30d8fc78a50557e6b8aa--


From nobody Tue Aug 29 13:59:11 2017
Return-Path: 
X-Original-To: netmod@ietf.org
Delivered-To: netmod@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEE4124E15; Tue, 29 Aug 2017 13:59:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: IETF Meeting Session Request Tool 
To: 
Cc: netmod-chairs@ietf.org, bclaise@cisco.com, lberger@labn.net, netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.59.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150404035002.32229.4793527936887367472.idtracker@ietfa.amsl.com>
Date: Tue, 29 Aug 2017 13:59:10 -0700
Archived-At: 
Subject: [netmod] netmod - New Meeting Session Request for IETF 100
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Aug 2017 20:59:10 -0000

A new meeting session request has just been submitted by Lou Berger, a Chair of the netmod working group.


---------------------------------------------------------
Working Group Name: Network Modeling
Area Name: Operations and Management Area
Session Requester: Lou Berger

Number of Sessions: 2
Length of Session(s):  1.5 Hours, 1.5 Hours
Number of Attendees: 100
Conflicts to Avoid: 
 First Priority: netconf rtgwg
 Second Priority: teas i2rs anima
 Third Priority: saag isis ospf


People who must be present:
  Lou Berger
  Benoit Claise
  Kent Watsen

Resources Requested:

Special Requests:
  
---------------------------------------------------------


From nobody Tue Aug 29 14:10:10 2017
Return-Path: 
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 2D32C124E15 for ; Tue, 29 Aug 2017 14:10:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level: 
X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 YFfkxnoEUP-p for ; Tue, 29 Aug 2017 14:10:07 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0102.outbound.protection.outlook.com [104.47.40.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66ADE1321B9 for ; Tue, 29 Aug 2017 14:10:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lCmjWvi+5CPRDH2flI8qK6x6jryrywWlxOWUQIcuh6Y=; b=auPzJJl+PhXyrHbenjCOJauosFurOISdTv/hfRQK4IcBsr/OP1m/8sSXnNWLEzC9Sp/juBXgC+v7hZi+Tj00uHPJ3qpYci2oIKxmjWQOKo9lrTaH7rvc2nZgJM9gD8gDDUecNn0P531TaOgHWOwN4IZm9tSMEkA89OUUyjPS9D4=
Received: from DM5PR05CA0043.namprd05.prod.outlook.com (10.174.188.160) by CY1PR0501MB1257.namprd05.prod.outlook.com (10.160.225.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Tue, 29 Aug 2017 21:10:05 +0000
Received: from DM3NAM05FT061.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::205) by DM5PR05CA0043.outlook.office365.com (2603:10b6:4:39::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2 via Frontend Transport; Tue, 29 Aug 2017 21:10:04 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.12) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=fail action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.12 as permitted sender)
Received: from p-emfe01a-sac.jnpr.net (66.129.239.12) by DM3NAM05FT061.mail.protection.outlook.com (10.152.98.179) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P256) id 15.1.1385.11 via Frontend Transport; Tue, 29 Aug 2017 21:10:04 +0000
Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 29 Aug 2017 14:10:03 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v7TLA2uY031031; Tue, 29 Aug 2017 14:10:02 -0700	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.15.2/8.15.2) with ESMTP id v7TLA1Oq040472; Tue, 29 Aug 2017 17:10:01 -0400 (EDT)	(envelope-from phil@juniper.net)
Message-ID: <201708292110.v7TLA1Oq040472@idle.juniper.net>
From: Phil Shafer 
To: Kent Watsen 
CC: Lou Berger , 
In-Reply-To: 
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <40470.1504041000.1@idle.juniper.net>
Date: Tue, 29 Aug 2017 17:10:00 -0400
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.12; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(2980300002)(199003)(189002)(1076002)(305945005)(97736004)(86362001)(8936002)(6862004)(23726003)(229853002)(77096006)(558084003)(189998001)(6246003)(478600001)(68736007)(356003)(110136004)(2810700001)(4326008)(97756001)(626005)(8676002)(81156014)(81166006)(8276002)(2906002)(54906002)(53936002)(54356999)(50986999)(105596002)(76506005)(106466001)(69596002)(47776003)(1941001)(53416004)(50466002)(7126002)(5660300001)(2950100002)(46406003)(230783001)(7696004)(6636002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1257; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT061; 1:K7Wi882fjHOW9V7zmehTg8+1Ra9yeVLIFgKAgvlrojWUVHm2wBm3cgOK6Lt4vEd3TBtL/n/BwuQB9w/00bPhfC9CJJm5zKSMIXMD8uFdZmRhx3nxA9R+hHbFiqNPGLN2
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 367aa111-8431-4d09-a1dc-08d4ef2251ea
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:CY1PR0501MB1257; 
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1257; 3:OQQ5bkoQ3CPkphvQSjiK2WLUy/pJywQ0JuhWihubbB7jRIrNBfp/F9axtUZwOZqum+e4fkz55weFlML9XkXHkZ21JFU5/16IBg4yrxOqtbJMQXCOBRy7i0hZPUdkZj+E4JzF6RxNH9vkt3VMumi2HGWdC67quAdTawSkc4kdPw9xnK2n554hGrU3XB+yYQF4PwxL36vK2dE1d7YLaRID597zywQ4ZsfGceHldGntsZKRz5K5N+m+v7Hi0aBGv6U58Y2XZj5q3Ww2BRRldehpmSoXXGh3/2xag4viGadsoa+5/qCH1FhAEW8e7ZCKH73XXS49mI708NHn5Ki/FLohWaKc+NC8FX33/qxZwRtlT9k=; 25:52tZbygxMRJ2fYLi1ATR+Ug9c703D45x2ETx/r8sUC1/bsvG3HnwWtfLTiKxLSs71txuGgKNuzKuMfRfoYrrWYRc5Jf3YKdturwR4Q5Fe9iS2J5rCigNFLPWOYO/IwqTqN5HnNaoi0+Py1RkOBgOQlkcSOrpHhNQHDdCAFxWMZ0CfEH+PG/jJKyJewI6cKjNR1i04c872z6OD97fj/EsYkw2+6Cwy6MCnBcRYscVrejb7HSUf5TQC40c5YZOjLSCJC6PlRbdgOXrpCQV3AZT7NeHDzWs14eGMNCM/juZ7nSbYsdUfRKRb0OrLPDiHt0+bq1ZbQ9Dy2t3kf/aVG4XCg==
X-MS-TrafficTypeDiagnostic: CY1PR0501MB1257:
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1257; 31:O5aMMMJ1xV7DTtEvmakbPNwFY+bA5VNIwrmKiAULV3eS7EJ4NzDljwZRpV6Nt28P1apHNIaMoLlyupgzhHdbI8WsTsKOq7K4pa54sYdNsRTPQZS1pRGFNl50tLIAWN7j7mgQuF2FP1Os0fgpgtNttbqpaqb8iVHKLSc4D2CVVC7xrrz/q2YEgHuAfFgy3ph2V7fdaFZF/Oe4Q5092v9ld8s36RplC0kVoqnDq6Am+yo=; 20:5YU1YAZGHaO9yY+VLAUV4ZiV5u1cNfiKi6uVdCozQhvRTKXm7S+CJs8CEdXN1521BV29+RGFui4mSDV9Lq2Ne0YMK+U3A0QJ5FVMbIULSoGOHcwZD8LAOm+8FNe869476r9FA6QF8/pishSV7WB8fUKfuDmdoFo+NLfYLbmd5zcjS+BRI9mOUHjU15DfXpFX/HiRAPvf/LXDJFgp3yHeC3dwLXEje1zeoENSUTFpwQWWd/rfbSUWeFH5yqVRYZ+vEAsjyGIRbZHXJTwY1D9hDUJGsCEiquYm82QmVODJv0oa7CqzwAfMaVmEMRko0dzJ3J+9YexZgWasNrQylY9pppB/NF5g9K0o8kTvSLbKHbPswkLcteCvKj7YxZhdOKlDcmZxIRRbqn06tJx/lRf77gVD7/W+UFVNr6yLha/X+p8pmJGgZpZCbA5TX5JH5le/rq1QKkZ0y3HJ6LhaW6e2zkNdwxZEVfKNt78A9aXmYVUdykYCl/M2Wa8DIzAPQ8TL
X-Exchange-Antispam-Report-Test: UriScan:;
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(13018025)(8121501046)(13016025)(5005006)(3002001)(10201501046)(93006095)(93003095)(100000703101)(100105400095)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY1PR0501MB1257; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY1PR0501MB1257; 
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1257; 4:ANf1sM9gSQpb2ENd11Qm5RqWepoERgZh7upNxonHN3/g9y9cZ000NvUxR0g4TpJREYhvPlKv5E+WOne6Ff502ZE22FCG0jIqKOhzjR6BiZ69WAePeU78L4evQJF+kbhxWAXYfUuB+Lxzj8WWoYxOuCkwgf4Xj9L/if+pNRN1CK7L7SSUq21fz0NXZt9q9Png+RVbkZOZSKXeoo9T6/JgC3vX+0bMhz5g0YcMsCw5pHMb9PuYxCwXxDEZTHP4VExv
X-Forefront-PRVS: 0414DF926F
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB1257; 23:l32MVKuwU/sRzxW3LYl/eOq9Ows0n1td6pFMGrl?= =?us-ascii?Q?4Rdn15z3MOZPbJBYcfEnTr/I/VBlCiDvE32r5ziY2O+5hhWhEwk8K+wytM+n?= =?us-ascii?Q?qQxP0SPner61lKLD3B53nvKtm30MmNm+Xeut5lrbUl7QAW8jr/r1y31oMncs?= =?us-ascii?Q?GoLMWQhKMTxtQCrTTsvr6B5m4OxZ20F50YkQ33bp5xv13d/cGMnjXXOJM4o6?= =?us-ascii?Q?z9uTwx9wW+bmXpE998pLVUAWK0iqy27a4B9vGzcIWvDW8O4o/y/kY0oJSZMc?= =?us-ascii?Q?bJ6i7uvuDpxq6rSETMl3qRd7fU4Dh4A/CjXZb5/K/EYunTSC3YNZWeSslu43?= =?us-ascii?Q?sTSTYiIvLNi/DgBbMgl6/TGDQT1CR6t8VZ/m/V9VQV56Kk5MNAh7UNFsrcYO?= =?us-ascii?Q?hhfP2GiGwb37ir86Xets17havbL6QWsraTn/rIDoL1pv8nTtHJPP5vu5JWh3?= =?us-ascii?Q?uULF/7l6Xs8d1NxfZNVwFJWRC8LL2hNiwUSpNn5EgTmkecxxo/QO7IhID8em?= =?us-ascii?Q?CwqfUbCI+AWKXwjO0NDI/gOPcVsP3DAObi09CfQulue9Y0bVLLF9u9V4wK7N?= =?us-ascii?Q?GchVhEZzwB/2HZpT3Bt08gOExJJswm1CxyxqqiwjlVyjF4iyl0psFOg2/YPx?= =?us-ascii?Q?a/4g5qeqI+GcZomg2JB9g8iuYzXUTx2CzMk5gDlhNM9wMRg27fMx/Rr4fMCj?= =?us-ascii?Q?rFbshAP+8I+tnW4KET//SE9kP632GW7O64SFc1g23S1s1TpRPAxvfQIE0u7v?= =?us-ascii?Q?PnLrvRra4kKCM0qBU6ACzmpE11A0W41ubX0pAzozsxns1HZ3NeUIAd1YdyCy?= =?us-ascii?Q?qRBtUAUX9nXXLWfw6BnPbTdCfAbH+8/0The8lfL7GrhYA1pD9PPX8fCPG/lR?= =?us-ascii?Q?8fqe5cOc8yO0p4TqpPuH9854CoBy8xTCkHarZ58pLT80+ufNshOGefwgCOZ7?= =?us-ascii?Q?Iin9Xf0SnAvdM3K+vWCcpAh5QGlc+MTjGBdTziOKLE2HWOSOsPs6dtjz3Uqp?= =?us-ascii?Q?Yoh3APRr5igwXFoawOpZ1We2WhwfmtJMmNmMTi/qSZL4aM/bLAh9pe45oXV7?= =?us-ascii?Q?ghDGontZlPZBJnfPS0POlj7wGEfwpHso79ke8swG9RQmISBQUR5UibdQImhE?= =?us-ascii?Q?ySo9yJETOc0Amx+o3pRKMPSSP8Wj37Tcbog8XnJ6QC2ZszNTX4NlaYA=3D?= =?us-ascii?Q?=3D?=
X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1257; 6:5fS4Bor4B5J1hyNdM8TbMDI/arQ3+OfO0QMDsiHTbpAC9Q95jlK28tW6cLoZsEByyHu+gmhlmIhQXAabVQDo7TbtPGR0A8nUsTturd6WnHA+1MMWoGLHDcjc96ejnZ/s/iZchH7WlNGSle1oAatJEc45S4bjue340sAVgs8/SNq3Ir0Agb98LoKtKM8r/t9BKh3YA7v9yjSLP/nfyyR+l5kUZKGGMUl8iJfvN5WoVN2lKTK+lsi33i1KJcDFT1mRuHB6ceqGY7mMuncyEAizK6xxYCVNNbkE3tl1NIn1zFIK6Ym0n7hhIqqwuw3sO6FiQrxPxIdgz/dDWSxI1KVNcg==; 5:YLOTPgWSKjAmEGlYLfILcBnoBHr3tgAL394ywRNtYZEBeBhrVipHAQ1I1j2n6ZmU3CztcjbjnQ4rzPj+hZxjZm1d3wBBsY+BzW85LFr8MiMf6OKnhcON2ssjfySGrIS1VVnt0KOLcS9P5maBUW5VHA==; 24:lxsQZCXCzFwfz14SUu52oC+2uYDKky2sWH69cE8A8uJ8b4r7SOUpFSX9f+Zsgny8qxVoKWTYhSVXX0Q5CbI7cwiNethb7/5SvrR9Myh0sP4=; 7:CV6v0IS6w84eEEiJt5cJYMgx9cj4uCxRS0XyDKI23MT21OqSdBBySogmVyqSmFKIYWVGYOTpOeFTOxoBaigD3v/MQ9/CPFppN6rVSUUibEqddBElg0S6Uq8tns1pc2EdSz7c1oR8WJe0bW/tZZcsUIZ8yoYULFRHoBCCMHU7/ustdHmw8rMr1WSApSMBgY9dDaRfJgVS3ht8e2unw33i7Ib+28KEvCCReBEOOVDQ4WQ=
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Aug 2017 21:10:04.4121 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.12];  Helo=[p-emfe01a-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1257
Archived-At: 
Subject: Re: [netmod] FW: Regarding IPR on draft-ietf-netmod-revised-datastores-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Aug 2017 21:10:09 -0000

Kent Watsen writes:
>The NETMOD chairs need your on-list response to this email.
>- all the other authors have already replied...

I know of no IPR related to this draft.

Thanks,
 Phil


From nobody Tue Aug 29 16:46:46 2017
Return-Path: 
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 F351A132A94 for ; Tue, 29 Aug 2017 16:46:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.01
X-Spam-Level: 
X-Spam-Status: No, score=-3.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 0zXU1qPw1jFv for ; Tue, 29 Aug 2017 16:46:43 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0100.outbound.protection.outlook.com [104.47.36.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28661132113 for ; Tue, 29 Aug 2017 16:46:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7gDMWae65gCru5s+00hNS+UGcQieSdFiyeXAtdTyLow=; b=Gbhx+Xvn9a1W30EEghPfMbpUQRK9hEC1Y+8+qDfx4LrP9d69/a1Kd9vBjC5GpdW/tIXXN9wjyr8K6G8qHKPIv1e1JzQeafWroYFw6C8nJBqYqZGYCEXczzyrJXCo5j3Zi8tloCJl4Nf6VWyXVtBPrqSJ0DHFWdUsv84vk2BJNBY=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1252.namprd05.prod.outlook.com (10.160.183.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.13.2; Tue, 29 Aug 2017 23:46:41 +0000
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.20.0013.011; Tue, 29 Aug 2017 23:46:41 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: upcoming adoptions
Thread-Index: AQHTISEQvmg9jr+3gUCv+5ltP9XhHg==
Date: Tue, 29 Aug 2017 23:46:41 +0000
Message-ID: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1252; 6:+EyQH2INXj0h5FACZBSHWXMeDKfYjI8X3o8VqD4dSertv+LS/BZOoLo9VU8Hgt86WB/GswytiYHTusciScKY0jlIUCoj+NUeIIrayUnMn8cCiuq/6+JcCitKW5D5dts81VbpNFtVXL4B84cl3m1rw3TFFldUePjGvVHdtNqcFc8Nfd18RVjGhqdcAMHvl5GDkJtH2mxzZ5QJLLPIc0C3kJz8xlHgunCl08Se3vxdQ2bfpBQG7I091xAK0Dz/hPqC+oMzOEQHYBHX5sgdEdv0dTWaPaGyNc1DS5IfMG7N8jsgryXDuiNC3U1RYbyAllZedyPnwayxKMWwyPuswV5jZA==; 5:BewzAYkUUDp3FvXE1Z4OyKGvxmkfpK+XKkeuU8VAZnUtMCNc3EyzRqPgDJFeg5QSSOjGAThK1OB/8+I0vSDovzFMaLXkI1QBkmsRwUiPfEPgh/XxnzB9nLdD9qWZrf+zYy2zGWTNciahSFW/qFZUUA==; 24:IHARgIW9Z7sZDRo/8KBr/g+fwlAWDuZ2o4c9eyV7IikxxbqD+TmDiG47rwKJC6PD8mgDQ5LTBEC1lOK29AWybMuo7IDPuAANofmpKH3Ozos=; 7:rLdc4tbWsMVSa1159LKnXo9hSdxSN0XSdKbtfzCKJ9e87BkahvVUb2nvs9rXyG32ig1DyTs8bU28r3pcYdyns5c6s/TJFVXApsq/4pcjrp2ywFHI02gTnla6IO/vbTur1SIF0Nw6VQDySmNfc2z4gMci0VIuVk262lBZ6SqN4ETKKPqlWyozIoktqO4/KQ9hWS+0wImQ+5EjU6hCE48F+DTHy48PlzcMVV0LiN0lIAU=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: ea69ad35-6b40-4881-71c8-08d4ef3832ba
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1252; 
x-ms-traffictypediagnostic: BN3PR0501MB1252:
x-exchange-antispam-report-test: UriScan:;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6055026)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1252; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1252; 
x-forefront-prvs: 0414DF926F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(199003)(189002)(6506006)(8936002)(3846002)(3280700002)(1730700003)(102836003)(81156014)(83506001)(81166006)(3660700001)(2501003)(83716003)(3480700004)(101416001)(106356001)(6486002)(105586002)(2351001)(7116003)(2900100001)(2906002)(6116002)(6436002)(5660300001)(77096006)(6916009)(4001350100001)(50986999)(54356999)(305945005)(82746002)(5640700003)(7736002)(66066001)(25786009)(68736007)(86362001)(33656002)(36756003)(53936002)(14454004)(8676002)(221733001)(189998001)(110136004)(478600001)(99286003)(6306002)(97736004)(966005)(6512007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1252; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <5411EBF98C26F24F8CADD11B32CCDFC8@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Aug 2017 23:46:41.3119 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1252
Archived-At: 
Subject: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Aug 2017 23:46:45 -0000

DQpIZXkgZm9sa3MsDQoNCkFzIGRpc2N1c3NlZCBhdCB0aGUgbGFzdCBtZWV0aW5nLCB3ZSBhcmUg
aGVhZGluZyB0byByZXZpc2luZyBleGlzdGluZyBSRkNzIHRvIGFsaWduIHRoZW0gd2l0aCBOTURB
LiAgVGhlIGZpcnN0IGJhdGNoIGhhdmUgYmVlbiBwdWJsaXNoZWQgYXMgaW5kaXZpZHVhbCBkcmFm
dHM6DQoNCjEuIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iam9ya2x1bmQtbmV0
bW9kLXJmYzcyMjNiaXMtMDANCjIuIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1i
am9ya2x1bmQtbmV0bW9kLXJmYzcyNzdiaXMtMDANCjMuIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv
aHRtbC9kcmFmdC1hY2VlLW5ldG1vZC1yZmM4MDIyYmlzLTAwDQoNClBsZWFzZSB0YWtlIGEgbG9v
ayAoY29tbWVudHMgd2VsY29tZSEpIGFuZCBzdGF5IHR1bmVkIGZvciB0aGUgcmVsYXRlZCBhZG9w
dGlvbiBjYWxscy4NCg0KVGhhbmtzLA0KS2VudCAoYW5kIExvdSkNCg0KDQo=


From nobody Wed Aug 30 00:42:00 2017
Return-Path: 
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 88AB41326FE for ; Wed, 30 Aug 2017 00:41:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 QmtvZK_HFoW1 for ; Wed, 30 Aug 2017 00:41:58 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E954C132386 for ; Wed, 30 Aug 2017 00:41:57 -0700 (PDT)
Received: from localhost (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id A0E9A1AE012C; Wed, 30 Aug 2017 09:41:55 +0200 (CEST)
Date: Wed, 30 Aug 2017 09:40:28 +0200 (CEST)
Message-Id: <20170830.094028.1809893324608957744.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: lberger@labn.net, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <87shgacvrb.fsf@nic.cz>
References: <1503929779.1715.65.camel@nic.cz> <81b138c6-9941-3313-979c-61edad7819a7@labn.net> <87shgacvrb.fsf@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-15
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Aug 2017 07:41:59 -0000

Ladislav Lhotka  wrote:
> Lou Berger  writes:
> =

> > Lada,
> >
> >
> > On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
> >> Lou Berger p=ED=A8e v Po 28. 08. 2017 v 09:40 -0400:

[...]

> >>> PS is your view aligned with martin or our example?
> >> If you mean shifting the XPath context node to the mount point ins=
tance, then
> >> yes.

So, going back to the original issue; does anyone have any objection
to changing the XPath context for parent-reference as describied in my
original post?


/martin


From nobody Wed Aug 30 02:16:37 2017
Return-Path: 
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 979CA132715 for ; Wed, 30 Aug 2017 02:16:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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
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 H6r-s2942x2h for ; Wed, 30 Aug 2017 02:16:33 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938F21321C4 for ; Wed, 30 Aug 2017 02:16:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13178; q=dns/txt; s=iport; t=1504084592; x=1505294192; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=0kdOcE2sH2yaCjm+fNEfYU7fyjUK0S7J+rwG8kNj7cc=; b=VYAsk2QzujC23kq9cgTMFE7ohsgHOB/AP7affVyOiilwzLtzhca4rPFN JCDbjECY6DBCqfAvcg0Sz0nGykc/6834uKK5dHcSEcWZBzYxdtZHWYpP3 V26RH/fSBmuVQOhioRB6j4yOIfIM9HZefIa50BZ1DCpNP7jgJGFPNgRv8 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CYAgAMgaZZ/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm8+gRGBFYN3ixKRF5BphT6CEiEBCoRMTwKEXhYBAgEBAQEBAQF?= =?us-ascii?q?rKIUZAQEBAwEBIUsLEAsYJwMCAicfEQYNBgIBAYotEK1Cgicnix8BAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEYBYMqg1CCDoJ9hE+DOYJhBZgsiDyLMokaghKJQCSGdY1?= =?us-ascii?q?QiHImDSRBTDIhCBwVSYRfORyBaD82iC2CQAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.41,448,1498521600";  d="scan'208,217";a="657122349"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2017 09:16:30 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v7U9GULW013528; Wed, 30 Aug 2017 09:16:30 GMT
To: Andy Bierman 
Cc: Xufeng Liu , Per Hedeland , Ladislav Lhotka , "netmod@ietf.org" 
References:  <20170824060900.u5kcffzvwjr7mmob@elstar.local> <152f24b2-7947-9c76-714c-af226ab3fe91@tail-f.com> <8760ddc676.fsf@nic.cz> <599F0991.7020900@tail-f.com>  <20170825125254.6nhnzkrar6fhu7zr@elstar.local>  <20170828154640.pzg7jfy5uepkb22q@elstar.local>  
From: Robert Wilton 
Message-ID: 
Date: Wed, 30 Aug 2017 10:16:30 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------C440BC0D3500F8DDB4E2DAA1"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Aug 2017 09:16:35 -0000

This is a multi-part message in MIME format.
--------------C440BC0D3500F8DDB4E2DAA1
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Andy,

What I am suggesting makes it easier for readers, because I am a 
proponent of simpler regular expressions that are easy to read and 
understand.

For example, I wonder how many YANG model readers would immediately 
comprehend what this pattern statement means:

pattern "\p{Sc}\p{Zs}?\p{Nd}+\.\p{Nd}{2}"?

Does allowing such patterns really make it easier for model readers?

The proposes guidelines obviously make it easier (or at least no harder) 
for tool makers.

I agree that there is an minor impact to model writers, but really only 
in the sense that the guidelines would be telling them not to use the 
esoteric options of the XML regex syntax that they probably don't know 
about anyway.

If explicitly putting this in the YANG author guidelines is not liked, 
then another possible option could be a softer recommendation in the 
guidelines RFC, with some more explicit examples of stuff to avoid on an 
YANG FAQ Wiki page.

Thanks,
Rob


On 29/08/2017 17:15, Andy Bierman wrote:
> Hi,
>
> I agree with Juergen that these proposed guidelines are not a good idea.
> The priority order for YANG is (1) readers (2) writers and (3) toolmakers.
> It seems trivial for group (3) to convert the XSD pattern to some 
> other format.
> It seems difficult to train all the people in groups (1) and (2) that 
> there are lots of
> special new rules to learn.
>
>
> Andy
>
>
> On Tue, Aug 29, 2017 at 7:27 AM, Robert Wilton  > wrote:
>
>
>     On 28/08/2017 16:46, Juergen Schoenwaelder wrote:
>>     On Mon, Aug 28, 2017 at 12:58:59PM +0000, Xufeng Liu wrote:
>>>     [Xufeng] [0..9] is still compliant with the XSD pattern specified by
>>>     YANG 1.0 and 1.1. Using [0..9] instead of [\d] will make the
>>>     implementations with native POSIX RegEx easier without the need for
>>>     a tool to inspect every element of the RegEx pattern.
>>     Yes, but then \d is legal in YANG (and it is used in a couple of
>>     published RFCs).
>     I entirely agree that YANG regular expressions must be legal XML
>     Schema regular expressions.
>
>     However, I don't think that the majority of YANG implementations
>     are going to want to either use libxml or write their own
>     implementation of the XML RE language.  Instead it is desirable
>     that they can use whatever standard regex implementation comes
>     with their language, or is readily available in a library.
>
>     Most of the pattern statements I see in YANG modules use a basic
>     subset of regular expressions, and hence it looks like they can
>     often be used by most RE engines, perhaps with some trivial tweaks
>     or conversions.  However, there is no formal guidance recommending
>     that pattern statements in standard modules are restricted to a
>     subset of XML RE.
>
>     Hence, ideally I would like 6087bis to state that pattern
>     statements SHOULD also conform to the following additional RE
>     syntax restrictions, which I think should make them easy to
>     convert to most other standard regex implementations (subject to
>     unicode support limitations):
>
>     (1) Allow \d, \D, \s, \S, \w and \W; but not inside character classes.
>     (2) Disallow \i, \c; and their negative equivalents.
>     (3) Disallow character class subtraction (e.g. "[A-Z-[RW]]").
>     (4) Limit the supported unicode categories to only the following
>     8.  Both \p and \P syntax is supported, but not inside character
>     classes:
>       \p{L} or any kind of letter from any language.
>       \p{Ll} a lowercase letter that has an uppercase variant.
>       \p{Lu} an uppercase letter that has a lowercase variant.
>       \p{Z} any kind of whitespace or invisible separator.
>       \p{Zs} a whitespace character that is invisible, but does take
>     up space.
>       \p{Zl} a line separator character U+2028.
>       \p{N} any kind of numeric character in any script.
>       \p{Nd}: a digit zero through nine in any script except ideographic
>     (5) Disallow matching of unicode blocks.
>
>     Thanks,
>     Rob
>
>
>>     Educating _all_ module authors to write [0..9] instead of \d will
>>     likely be more expensive than improving the code of implementations
>>     that did not implement YANG entirely to accept \d.
>>
>>     /js
>>
>
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org 
>     https://www.ietf.org/mailman/listinfo/netmod
>     
>
>


--------------C440BC0D3500F8DDB4E2DAA1
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Andy,

    
What I am suggesting makes it easier for readers, because I am a
      proponent of simpler regular expressions that are easy to read and
      understand.

    

    
For example, I wonder how many YANG model readers would
      immediately comprehend what this pattern statement means: 

    

    
 pattern "\p{Sc}\p{Zs}?\p{Nd}+\.\p{Nd}{2}"?

    

    
Does allowing such patterns really make it easier for model
      readers?

    

    
The proposes guidelines obviously make it easier (or at least no
      harder) for tool makers.

    

    
I agree that there is an minor impact to model writers, but
      really only in the sense that the guidelines would be telling them
      not to use the esoteric options of the XML regex syntax that they
      probably don't know about anyway.

    
If explicitly putting this in the YANG author guidelines is not
      liked, then another possible option could be a softer
      recommendation in the guidelines RFC, with some more explicit
      examples of stuff to avoid on an YANG FAQ Wiki page.

    

    
Thanks,

      Rob

    

    

    
On 29/08/2017 17:15, Andy Bierman
      wrote:

    

    

      
      
Hi,
        


        

        
I agree with Juergen that these proposed guidelines are not
          a good idea.

        
The priority order for YANG is (1) readers (2) writers and
          (3) toolmakers.

        
It seems trivial for group (3) to convert the XSD pattern
          to some other format.

        
It seems difficult to train all the people in groups (1)
          and (2) that there are lots of

        
special new rules to learn.

        


        

        


        

        
Andy

        


        

        

          


            
On Tue, Aug 29, 2017 at 7:27 AM,
              Robert Wilton <rwilton@cisco.com>
              wrote:

              

                
 

                  
On
                    28/08/2017 16:46, Juergen Schoenwaelder wrote:

                  

                  

                    
On Mon, Aug 28, 2017 at 12:58:59PM +0000, Xufeng Liu wrote:


                    

                      
[Xufeng] [0..9] is still compliant with the XSD pattern specified by
YANG 1.0 and 1.1. Using [0..9] instead of [\d] will make the
implementations with native POSIX RegEx easier without the need for
a tool to inspect every element of the RegEx pattern.


                    

                    
Yes, but then \d is legal in YANG (and it is used in a couple of
published RFCs).

                  

                  I entirely agree that YANG regular expressions must be
                  legal XML Schema regular expressions.

                  

                  However, I don't think that the majority of YANG
                  implementations are going to want to either use libxml
                  or write their own implementation of the XML RE
                  language.  Instead it is desirable that they can use
                  whatever standard regex implementation comes with
                  their language, or is readily available in a library.

                  

                  Most of the pattern statements I see in YANG modules
                  use a basic subset of regular expressions, and hence
                  it looks like they can often be used by most RE
                  engines, perhaps with some trivial tweaks or
                  conversions.  However, there is no formal guidance
                  recommending that pattern statements in standard
                  modules are restricted to a subset of XML RE.

                  

                  Hence, ideally I would like 6087bis to state that
                  pattern statements SHOULD also conform to the
                  following additional RE syntax restrictions, which I
                  think should make them easy to convert to most other
                  standard regex implementations (subject to unicode
                  support limitations):

                  

                  (1) Allow \d, \D, \s, \S, \w and \W; but not inside
                  character classes.

                  (2) Disallow \i, \c; and their negative equivalents.

                  (3) Disallow character class subtraction (e.g.
                  "[A-Z-[RW]]").

                  (4) Limit the supported unicode categories to only the
                  following 8.  Both \p and \P syntax is supported, but
                  not inside character classes:

                    \p{L} or any kind of letter from any language.

                      \p{Ll} a lowercase letter that has an uppercase
                    variant.

                      \p{Lu} an uppercase letter that has a lowercase
                    variant.

                      \p{Z} any kind of whitespace or invisible
                    separator.

                      \p{Zs} a whitespace character that is invisible,
                    but does take up space.

                      \p{Zl} a line separator character U+2028.

                      \p{N} any kind of numeric character in any script.

                      \p{Nd}: a digit zero through nine in any script
                    except ideographic 

                  (5)
                  Disallow matching of unicode blocks.

                  

                  Thanks,

                  Rob

                  

                  

                  

                    
Educating _all_ module authors to write [0..9] instead of \d will
likely be more expensive than improving the code of implementations
that did not implement YANG entirely to accept \d.

/js



                  

                  

                

                

                _______________________________________________

                netmod mailing list

                netmod@ietf.org

                https://www.ietf.org/mailman/listinfo/netmod

                

              

            

            

          

        

      

    

    

  


--------------C440BC0D3500F8DDB4E2DAA1--


From nobody Wed Aug 30 02:29:21 2017
Return-Path: 
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 DD832132620 for ; Wed, 30 Aug 2017 02:29:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.701
X-Spam-Level: 
X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 ouiyBFXNAgZb for ; Wed, 30 Aug 2017 02:29:18 -0700 (PDT)
Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (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 589EE1323F7 for ; Wed, 30 Aug 2017 02:29:18 -0700 (PDT)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id B2DD714054D for ; Wed, 30 Aug 2017 03:29:17 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id 3MVE1w00W2SSUrH01MVHVy; Wed, 30 Aug 2017 03:29:17 -0600
X-Authority-Analysis: v=2.2 cv=G8xsK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=KeKAF7QvOSUA:10 a=u07AKapRAAAA:8 a=wU2YTnxGAAAA:8 a=B4eHQB-JjU6rmOT_XCgA:9 a=QEXdDO2ut3YA:10 a=SkebfZ6J2Mmvk2rLHZle:22 a=Yz9wTY_ffGCQnEDHKrcv:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=1+4HyxbqOkBZPx1DmDvFIP/RP2qb9ei7w7Eio/GR0u8=; b=0hRAYwIXQ4iMq76sts4j+l2aQW moixZ8ChETn+DQSV2E7/EJ7RPwSb4nJiBTaMF5z/Zq0W4XfJAW8zPFPFaRrt9cor5Q/dEHexGbduN qZhX7P9sDHd33PAX/cACVzdwc;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:42875 helo=[11.4.0.6]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dmzJC-0033ol-DO; Wed, 30 Aug 2017 03:29:14 -0600
From: Lou Berger 
To: Martin Bjorklund , 
CC: 
Date: Wed, 30 Aug 2017 05:29:12 -0400
Message-ID: <15e32791e40.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <20170830.094028.1809893324608957744.mbj@tail-f.com>
References: <1503929779.1715.65.camel@nic.cz> <81b138c6-9941-3313-979c-61edad7819a7@labn.net> <87shgacvrb.fsf@nic.cz> <20170830.094028.1809893324608957744.mbj@tail-f.com>
User-Agent: AquaMail/1.10.0-403 (build: 101000001)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dmzJC-0033ol-DO
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([11.4.0.6]) [100.15.84.20]:42875
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Aug 2017 09:29:20 -0000

FYI I've asked folks in the routing area, i.e., the ietf users of schema 
mount, if they have an opinion on the node discussion. I will also do so on 
the point I raised on parent reference location. (Which is independent from 
your format change.) Clearly, if I'm the only one to be raising objections, 
I'll be the one in the rough on these points.

Thanks,

Lou
- as contributor


On August 30, 2017 3:42:26 AM Martin Bjorklund  wrote:

> Ladislav Lhotka  wrote:
>> Lou Berger  writes:
>>
>> > Lada,
>> >
>> >
>> > On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
>> >> Lou Berger píše v Po 28. 08. 2017 v 09:40 -0400:
>
> [...]
>
>> >>> PS is your view aligned with martin or our example?
>> >> If you mean shifting the XPath context node to the mount point instance, 
>> then
>> >> yes.
>
> So, going back to the original issue; does anyone have any objection
> to changing the XPath context for parent-reference as describied in my
> original post?
>
>
> /martin
>



From nobody Wed Aug 30 03:29:11 2017
Return-Path: 
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 615301321E3 for ; Wed, 30 Aug 2017 03:29:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 BfZE_IBDTKQW for ; Wed, 30 Aug 2017 03:29:08 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA12B132139 for ; Wed, 30 Aug 2017 03:29:07 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 33658F4B; Wed, 30 Aug 2017 12:29:05 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id v0_V-jK-uPrG; Wed, 30 Aug 2017 12:29:04 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 30 Aug 2017 12:29:05 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 11130200E0; Wed, 30 Aug 2017 12:29:05 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id D6Yzi3He3onT; Wed, 30 Aug 2017 12:29:04 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8AD3D200AA; Wed, 30 Aug 2017 12:29:04 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id E46C740731A6; Wed, 30 Aug 2017 12:29:02 +0200 (CEST)
Date: Wed, 30 Aug 2017 12:29:02 +0200
From: Juergen Schoenwaelder 
To: Robert Wilton 
Cc: Andy Bierman , Xufeng Liu , "netmod@ietf.org" 
Message-ID: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , Andy Bierman , Xufeng Liu , "netmod@ietf.org" 
References: <152f24b2-7947-9c76-714c-af226ab3fe91@tail-f.com> <8760ddc676.fsf@nic.cz> <599F0991.7020900@tail-f.com>  <20170825125254.6nhnzkrar6fhu7zr@elstar.local>  <20170828154640.pzg7jfy5uepkb22q@elstar.local>   
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Aug 2017 10:29:10 -0000

On Wed, Aug 30, 2017 at 10:16:30AM +0100, Robert Wilton wrote:
> Hi Andy,
> 
> What I am suggesting makes it easier for readers, because I am a proponent
> of simpler regular expressions that are easy to read and understand.
> 
> For example, I wonder how many YANG model readers would immediately
> comprehend what this pattern statement means:
> 
> pattern "\p{Sc}\p{Zs}?\p{Nd}+\.\p{Nd}{2}"?
> 
> Does allowing such patterns really make it easier for model readers?

This is always difficult to judge but to be fair you have to show how
you express _the same_ (and not a subset) with some other kind of
regular expressions. (My understanding is that \p{Sc} is a currency
symbol.)

> The proposes guidelines obviously make it easier (or at least no harder) for
> tool makers.
> 
> I agree that there is an minor impact to model writers, but really only in
> the sense that the guidelines would be telling them not to use the esoteric
> options of the XML regex syntax that they probably don't know about anyway.

What is 'esoteric' largely depends on your language environment. What
you are saying by 'do not use \p{}' is essentially 'do not use any
unicode long live ASCII'.
 
/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Aug 30 03:29:54 2017
Return-Path: 
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 11D7213240D for ; Wed, 30 Aug 2017 03:29:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 d0ty1Ded848A for ; Wed, 30 Aug 2017 03:29:51 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 24B121321E3 for ; Wed, 30 Aug 2017 03:29:51 -0700 (PDT)
Received: from localhost (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 39F861AE012C; Wed, 30 Aug 2017 12:29:50 +0200 (CEST)
Date: Wed, 30 Aug 2017 12:28:23 +0200 (CEST)
Message-Id: <20170830.122823.2236525312698458242.mbj@tail-f.com>
To: acee@cisco.com
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net>
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Aug 2017 10:29:53 -0000

Hi,

Kent Watsen  wrote:
> 3. https://tools.ietf.org/html/draft-acee-netmod-rfc8022bis-00

I found some trivial errors in this draft:

  o  The revision for ietf-routing doesn't match the filename's date.

  o  The filename for ietf-ipv6-router-advertisements is wrong (last
     "s" is missing)

  o  All the old -state definitions are removed, rather than being
     marked as "deprecated".


/martin


From nobody Wed Aug 30 04:48:26 2017
Return-Path: 
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 82F3D133026 for ; Wed, 30 Aug 2017 04:48:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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
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 Rc-pfJ0nLvaM for ; Wed, 30 Aug 2017 04:48:24 -0700 (PDT)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2F2813301E for ; Wed, 30 Aug 2017 04:48:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2268; q=dns/txt; s=iport; t=1504093703; x=1505303303; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=45uRaNC/d3OweqOJEdKEF2LBOF55rIv6Vc2dmi2yCog=; b=OHCQdYJKpRbO0pJc7zLqd9l6DTnnRXgd/yd9vOAG5euFZc/EQthMw67i mrSvxuObw9g53yZYgk/gpxHIL/U4piB93DmfDSMApN5U1ME0KqwKOVmMi lwWtRT1aYBMiGK8SJsN1bmQwYSWwWykg1wkrjKBSF8teGSss/3reitAw1 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DbAwBTpaZZ/xbLJq1eGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBiUqLEpEXmDmFRwKEZhQBAgEBAQEBAQFrKIUYAQEBAQIBIxVRCxgCAiY?= =?us-ascii?q?CAlcGAQwIAQGKJQitH4Ini0YBAQEBAQEBAQEBAQEBAQEBAQEggQ2CHYNQgg6CS?= =?us-ascii?q?DWICIJhAQSgbJRMghKJQCSGdY1QiHM2IYENMiEIHBWHZT+LIwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.41,448,1498521600"; d="scan'208";a="696850297"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2017 11:48:19 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v7UBmJj7004604; Wed, 30 Aug 2017 11:48:19 GMT
To: Andy Bierman , Xufeng Liu , "netmod@ietf.org" 
References: <152f24b2-7947-9c76-714c-af226ab3fe91@tail-f.com> <8760ddc676.fsf@nic.cz> <599F0991.7020900@tail-f.com>  <20170825125254.6nhnzkrar6fhu7zr@elstar.local>  <20170828154640.pzg7jfy5uepkb22q@elstar.local>    <20170830102902.2n5q6rgq2x2dxfq2@elstar.local>
From: Robert Wilton 
Message-ID: 
Date: Wed, 30 Aug 2017 12:48:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <20170830102902.2n5q6rgq2x2dxfq2@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Aug 2017 11:48:25 -0000

On 30/08/2017 11:29, Juergen Schoenwaelder wrote:
> On Wed, Aug 30, 2017 at 10:16:30AM +0100, Robert Wilton wrote:
>> Hi Andy,
>>
>> What I am suggesting makes it easier for readers, because I am a proponent
>> of simpler regular expressions that are easy to read and understand.
>>
>> For example, I wonder how many YANG model readers would immediately
>> comprehend what this pattern statement means:
>>
>> pattern "\p{Sc}\p{Zs}?\p{Nd}+\.\p{Nd}{2}"?
>>
>> Does allowing such patterns really make it easier for model readers?
> This is always difficult to judge but to be fair you have to show how
> you express _the same_ (and not a subset) with some other kind of
> regular expressions. (My understanding is that \p{Sc} is a currency
> symbol.)
Yes, the expression would cover a currency amount, along with associated 
symbol (e.g. "$200.00").

If I was writing a module, I would probably use the following pattern 
statement instead, which I think a lot more people would likely be able 
to comprehend:

pattern "[A-Z]{3}\s?\d+\.\d{2}", using the 3 letter, ISO 4217, currency codes.  e.g. ("USD 200.00")



>
>> The proposes guidelines obviously make it easier (or at least no harder) for
>> tool makers.
>>
>> I agree that there is an minor impact to model writers, but really only in
>> the sense that the guidelines would be telling them not to use the esoteric
>> options of the XML regex syntax that they probably don't know about anyway.
> What is 'esoteric' largely depends on your language environment. What
> you are saying by 'do not use \p{}' is essentially 'do not use any
> unicode long live ASCII'.
No, that is not my intention, i.e. I'm not suggesting banning all use of 
\p{}, but instead limiting it to the character classes that seem like 
they may plausibly be used in standardized YANG modules.

I'm not trying to change what 6020/7950 defines the pattern statement 
as, just give what I perceive as some pragmatic guidance as to what 
parts of XML RE it makes sense to use in standardized YANG modules, 
making it easier for readers and implementations.

I think that it is fine for companies, vendors, etc to use the full 
breadth of XML RE if they wish.

Thanks,
Rob

>   
> /js
>


From nobody Wed Aug 30 04:53:40 2017
Return-Path: 
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 6BA71133061 for ; Wed, 30 Aug 2017 04:53:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.521
X-Spam-Level: 
X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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
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 por_Rq7rC-G7 for ; Wed, 30 Aug 2017 04:53:38 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7292133059 for ; Wed, 30 Aug 2017 04:53:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1458; q=dns/txt; s=iport; t=1504094017; x=1505303617; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=C6sQpoL9m4RLJ7QGgvy25Qgco/XyWr2nBN9evPmzrJ4=; b=R3W7/Ub6Nk/LQbSfYtUfWdZd5vsfU/AOMpfDOpplpGtRbrT4FVMVJhM6 N2mZN9Kms7aMlHYtcJdN59Zj9dxNdD0TBpatgNdxKl5/RoI2KCG3uA5Dx JoZOexnQD1YRWGzMjp9eot5VzHUPNBsYBSXcdn+GdA+/cDogvgj72Nsz3 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AQDxpqZZ/5xdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1pkgRUHg3CKHpAagXGWJw6CBCyFGwIahAo/GAECAQEBAQEBAWs?= =?us-ascii?q?ohRkBBSMRRRACAQgOCgICJgICAjAVEAIEDgWKMRCtCIIni0YBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYENgh2CAoMxgyiEXYMrgmEFoGwCh1eMc4ISiWSGdZZCAR8?= =?us-ascii?q?4gQ13FYdkdolegQ8BAQE?=
X-IronPort-AV: E=Sophos;i="5.41,448,1498521600"; d="scan'208";a="473971844"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2017 11:53:37 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v7UBra8M028404 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 30 Aug 2017 11:53:37 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 30 Aug 2017 07:53:36 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1263.000; Wed, 30 Aug 2017 07:53:36 -0400
From: "Acee Lindem (acee)" 
To: Martin Bjorklund 
CC: "netmod@ietf.org" 
Thread-Topic: [netmod] upcoming adoptions
Thread-Index: AQHTISEQvmg9jr+3gUCv+5ltP9XhHqKc9jWA///UrAA=
Date: Wed, 30 Aug 2017 11:53:36 +0000
Message-ID: 
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <20170830.122823.2236525312698458242.mbj@tail-f.com>
In-Reply-To: <20170830.122823.2236525312698458242.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.196]
Content-Type: text/plain; charset="utf-8"
Content-ID: <03E732358FA01447BA1950106B706473@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Aug 2017 11:53:39 -0000

SGkgTWFydGluLCANCg0KT24gOC8zMC8xNywgNjoyOCBBTSwgIk1hcnRpbiBCam9ya2x1bmQiIDxt
YmpAdGFpbC1mLmNvbT4gd3JvdGU6DQoNCj5IaSwNCj4NCj5LZW50IFdhdHNlbiA8a3dhdHNlbkBq
dW5pcGVyLm5ldD4gd3JvdGU6DQo+PiAzLiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh
ZnQtYWNlZS1uZXRtb2QtcmZjODAyMmJpcy0wMA0KPg0KPkkgZm91bmQgc29tZSB0cml2aWFsIGVy
cm9ycyBpbiB0aGlzIGRyYWZ0Og0KPg0KPiAgbyAgVGhlIHJldmlzaW9uIGZvciBpZXRmLXJvdXRp
bmcgZG9lc24ndCBtYXRjaCB0aGUgZmlsZW5hbWUncyBkYXRlLg0KPg0KPiAgbyAgVGhlIGZpbGVu
YW1lIGZvciBpZXRmLWlwdjYtcm91dGVyLWFkdmVydGlzZW1lbnRzIGlzIHdyb25nIChsYXN0DQo+
ICAgICAicyIgaXMgbWlzc2luZykNCj4NCj4gIG8gIEFsbCB0aGUgb2xkIC1zdGF0ZSBkZWZpbml0
aW9ucyBhcmUgcmVtb3ZlZCwgcmF0aGVyIHRoYW4gYmVpbmcNCj4gICAgIG1hcmtlZCBhcyAiZGVw
cmVjYXRlZCIuDQoNCg0KSeKAmW0gZ2xhZCB5b3UgYnJvdWdodCB0aGlzIHVwLiBXZSBkaXNjdXNz
ZWQgdGhpcyBpbiB0aGUgUm91dGluZyBZQU5HIERlc2lnbg0KVGVhbSBhbmQgd2VyZSBwbGFubmlu
ZyB0byBkaXNjdXNzIGl0IG9uIGEgd2lkZSBzY2FsZS4NCg0KT25lIG9mIHRoZSBhZHZhbnRhZ2Vz
IG9mIHRoZSBOTURBIGlzIHRoYXQgaXQgbWFrZXMgdGhlIG1vZGVscyBlYXNpZXIgdG8NCnJlYWQg
YW5kIGNvbnN1bWUuIFRoaXMgaXMgc29tZXdoYXQgbmVnYXRlZCBpZiB3ZSBoYXZlIHRvIHJldGFp
biBhbGwgdGhlc2UNCmRhdGEgbm9kZXMgaW4gdGhlIGFzc29jaWF0ZWQgbW9kdWxlcyBhbmQgbWFy
ayB0aGVtIGFzIOKAnGRlcHJlY2F0ZWTigJ0uIFdoYXQNCmlzIHRoZSBjb25zZXF1ZW5jZSBvZiBu
b3QgaW5jbHVkaW5nIHRoZW0/IFRoZXkgYXJlIGF2YWlsYWJsZSBpbiB0aGUNCnByZXZpb3VzIHZl
cnNpb24gb2YgdGhlIG1vZGVsIGlmIHRoZXkgYXJlIG5lZWQgZm9yIGNvbXBhdGliaWxpdHkuDQoN
ClRoYW5rcywNCkFjZWUgDQoNCg0KPg0KPg0KPi9tYXJ0aW4NCg0K


From nobody Wed Aug 30 05:09:36 2017
Return-Path: 
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 509421330E3 for ; Wed, 30 Aug 2017 05:09:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 H0gcacEUj5Qv for ; Wed, 30 Aug 2017 05:09:33 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E1BD413310A for ; Wed, 30 Aug 2017 05:09:23 -0700 (PDT)
Received: from localhost (unknown [173.38.220.57]) by mail.tail-f.com (Postfix) with ESMTPSA id D08BE1AE012C; Wed, 30 Aug 2017 14:09:22 +0200 (CEST)
Date: Wed, 30 Aug 2017 14:07:56 +0200 (CEST)
Message-Id: <20170830.140756.691227201120065042.mbj@tail-f.com>
To: acee@cisco.com
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: 
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <20170830.122823.2236525312698458242.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Aug 2017 12:09:35 -0000

IkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPiB3cm90ZToNCj4gSGkgTWFydGlu
LCANCj4gDQo+IE9uIDgvMzAvMTcsIDY6MjggQU0sICJNYXJ0aW4gQmpvcmtsdW5kIiA8bWJqQHRh
aWwtZi5jb20+IHdyb3RlOg0KPiANCj4gPkhpLA0KPiA+DQo+ID5LZW50IFdhdHNlbiA8a3dhdHNl
bkBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+ID4+IDMuIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1hY2VlLW5ldG1vZC1yZmM4MDIyYmlzLTAwDQo+ID4NCj4gPkkgZm91bmQgc29tZSB0
cml2aWFsIGVycm9ycyBpbiB0aGlzIGRyYWZ0Og0KPiA+DQo+ID4gIG8gIFRoZSByZXZpc2lvbiBm
b3IgaWV0Zi1yb3V0aW5nIGRvZXNuJ3QgbWF0Y2ggdGhlIGZpbGVuYW1lJ3MgZGF0ZS4NCj4gPg0K
PiA+ICBvICBUaGUgZmlsZW5hbWUgZm9yIGlldGYtaXB2Ni1yb3V0ZXItYWR2ZXJ0aXNlbWVudHMg
aXMgd3JvbmcgKGxhc3QNCj4gPiAgICAgInMiIGlzIG1pc3NpbmcpDQo+ID4NCj4gPiAgbyAgQWxs
IHRoZSBvbGQgLXN0YXRlIGRlZmluaXRpb25zIGFyZSByZW1vdmVkLCByYXRoZXIgdGhhbiBiZWlu
Zw0KPiA+ICAgICBtYXJrZWQgYXMgImRlcHJlY2F0ZWQiLg0KPiANCj4gDQo+IEnigJltIGdsYWQg
eW91IGJyb3VnaHQgdGhpcyB1cC4gV2UgZGlzY3Vzc2VkIHRoaXMgaW4gdGhlIFJvdXRpbmcgWUFO
RyBEZXNpZ24NCj4gVGVhbSBhbmQgd2VyZSBwbGFubmluZyB0byBkaXNjdXNzIGl0IG9uIGEgd2lk
ZSBzY2FsZS4NCj4gDQo+IE9uZSBvZiB0aGUgYWR2YW50YWdlcyBvZiB0aGUgTk1EQSBpcyB0aGF0
IGl0IG1ha2VzIHRoZSBtb2RlbHMgZWFzaWVyIHRvDQo+IHJlYWQgYW5kIGNvbnN1bWUuIFRoaXMg
aXMgc29tZXdoYXQgbmVnYXRlZCBpZiB3ZSBoYXZlIHRvIHJldGFpbiBhbGwgdGhlc2UNCj4gZGF0
YSBub2RlcyBpbiB0aGUgYXNzb2NpYXRlZCBtb2R1bGVzIGFuZCBtYXJrIHRoZW0gYXMg4oCcZGVw
cmVjYXRlZOKAnS4gV2hhdA0KPiBpcyB0aGUgY29uc2VxdWVuY2Ugb2Ygbm90IGluY2x1ZGluZyB0
aGVtPyBUaGV5IGFyZSBhdmFpbGFibGUgaW4gdGhlDQo+IHByZXZpb3VzIHZlcnNpb24gb2YgdGhl
IG1vZGVsIGlmIHRoZXkgYXJlIG5lZWQgZm9yIGNvbXBhdGliaWxpdHkuDQoNCkl0IGlzIGZhaXJs
eSBjb21tb24gdGhhdCBpbnN0ZWFkIG9mIHJlbW92aW5nIGZ1bmN0aW9ucyBmcm9tIGENCnB1Ymxp
c2hlZCBBUEksIHlvdSBtYXJrIHRoZW0gYXMgZGVwcmVjYXRlZCBmb3Igc29tZSB0aW1lLCBhbmQg
dGhlbiwNCmxhdGVyLCByZW1vdmUgdGhlbSAoKikuDQoNCk5vdGUgdGhhdCBzaW5jZSBhIHNlcnZl
ciBjYW5ub3QgaW1wbGVtZW50IHR3byB2ZXJzaW9ucyBvZiBhIGdpdmVuDQptb2R1bGUsIGl0IGhh
cyB0byBkZWNpZGUgd2hpY2ggdmVyc2lvbiB0byBpbXBsZW1lbnQuICBUaGVyZSBtaWdodCBiZQ0K
b3RoZXIgbW9kdWxlcyB0aGF0IHVzZSAvIGF1Z21lbnQgdGhlIC1zdGF0ZSB0cmVlOyBpZiB0aGUg
c2VydmVyDQppbXBsZW1lbnRzIHRoZSBsYXRlc3QgdmVyc2lvbiB3L28gdGhlIC1zdGF0ZSB0cmVl
LCBpdCBjYW5ub3QgYXQgdGhlDQpzYW1lIHRpbWUgaW1wbGVtZW50IHRoZXNlIGF1Z21lbnRpbmcg
bW9kdWxlcy4NCg0KKCopIFlBTkcgaW5oZXJpdHMgdGhlIGRlcHJlY2F0aW9uIG1vZGVsIGZyb20g
U01JdjIuICBXZSBhY3R1YWxseSBoYXZlDQp0aHJlZSBzdGF0ZXM6IGN1cnJlbnQgLT4gZGVwcmVj
YXRlZCAtPiBvYnNvbGV0ZS4gIEFuZCBldmVuIHdoZW4NCnNvbWV0aGluZyBpcyBvYnNvbGV0ZSwg
aXQgaXMgbm90IHJlbW92ZWQuICBJIGd1ZXNzIGluIFNNSXYyIHRoaXMgd2FzDQpuZWNlc3Nhcnkg
Yi9jIG9mIE9JRCBhc3NpZ25tZW50czsgbWF5YmUgdGhpcyBjb3VsZCBiZSByZXZpc2l0ZWQgZm9y
DQpZQU5HLiAgQnV0IHRoaXMgd291bGQgcmVxdWlyZSBhbiB1cGRhdGUgdG8gUkZDIDc5NTAuDQoN
Cg0KSWYgd2UgdGhpbmsgdGhhdCBhIG1vZHVsZSBiZWNvbWVzIGNsdXR0ZXJlZCB3aXRoIGFsbCB0
aGUgZGVwcmVjYXRlZA0KZGVmaW5pdGlvbnMsIHdlIGNhbiBhY3R1YWxseSBtb3ZlIHRoZW0gYWxs
IHRvIGEgc2VwYXJhdGUgc3VibW9kdWxlLg0KDQoNCi9tYXJ0aW4NCg==


From nobody Wed Aug 30 05:32:03 2017
Return-Path: 
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 CC15713316C for ; Wed, 30 Aug 2017 05:32:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 UKTeVTP4BVap for ; Wed, 30 Aug 2017 05:32:00 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA824133164 for ; Wed, 30 Aug 2017 05:31:59 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 82C36F4B; Wed, 30 Aug 2017 14:31:58 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Ar16u74Hby9R; Wed, 30 Aug 2017 14:31:57 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 30 Aug 2017 14:31:58 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6133D200E0; Wed, 30 Aug 2017 14:31:58 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ruflHKF_w3Dc; Wed, 30 Aug 2017 14:31:57 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 80DDD200AA; Wed, 30 Aug 2017 14:31:57 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 2F70640735CD; Wed, 30 Aug 2017 14:31:56 +0200 (CEST)
Date: Wed, 30 Aug 2017 14:31:56 +0200
From: Juergen Schoenwaelder 
To: Robert Wilton 
Cc: Andy Bierman , Xufeng Liu , "netmod@ietf.org" 
Message-ID: <20170830123156.cssrg5kklpo67fie@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , Andy Bierman , Xufeng Liu , "netmod@ietf.org" 
References: <599F0991.7020900@tail-f.com>  <20170825125254.6nhnzkrar6fhu7zr@elstar.local>  <20170828154640.pzg7jfy5uepkb22q@elstar.local>    <20170830102902.2n5q6rgq2x2dxfq2@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Aug 2017 12:32:02 -0000

On Wed, Aug 30, 2017 at 12:48:19PM +0100, Robert Wilton wrote:
> 
> 
> On 30/08/2017 11:29, Juergen Schoenwaelder wrote:
> > On Wed, Aug 30, 2017 at 10:16:30AM +0100, Robert Wilton wrote:
> > > Hi Andy,
> > > 
> > > What I am suggesting makes it easier for readers, because I am a proponent
> > > of simpler regular expressions that are easy to read and understand.
> > > 
> > > For example, I wonder how many YANG model readers would immediately
> > > comprehend what this pattern statement means:
> > > 
> > > pattern "\p{Sc}\p{Zs}?\p{Nd}+\.\p{Nd}{2}"?
> > > 
> > > Does allowing such patterns really make it easier for model readers?
> > This is always difficult to judge but to be fair you have to show how
> > you express _the same_ (and not a subset) with some other kind of
> > regular expressions. (My understanding is that \p{Sc} is a currency
> > symbol.)
> Yes, the expression would cover a currency amount, along with associated
> symbol (e.g. "$200.00").
> 
> If I was writing a module, I would probably use the following pattern
> statement instead, which I think a lot more people would likely be able to
> comprehend:
> 
> pattern "[A-Z]{3}\s?\d+\.\d{2}", using the 3 letter, ISO 4217, currency codes.  e.g. ("USD 200.00")

But that is not the same. Apples versus oranges. (I expect people to
tell me that (i) currency is irrelevant and (ii) that three ASCII
letter currency acronyms are better than currency symbols anyway but
this is a separate discussion I am not interested in.)

> > 
> > > The proposes guidelines obviously make it easier (or at least no harder) for
> > > tool makers.
> > > 
> > > I agree that there is an minor impact to model writers, but really only in
> > > the sense that the guidelines would be telling them not to use the esoteric
> > > options of the XML regex syntax that they probably don't know about anyway.
> > What is 'esoteric' largely depends on your language environment. What
> > you are saying by 'do not use \p{}' is essentially 'do not use any
> > unicode long live ASCII'.
> No, that is not my intention, i.e. I'm not suggesting banning all use of
> \p{}, but instead limiting it to the character classes that seem like they
> may plausibly be used in standardized YANG modules.

This is entirely subjective. And if you still allow some \p{}, what is
the point of the exercise?

> I'm not trying to change what 6020/7950 defines the pattern statement as,
> just give what I perceive as some pragmatic guidance as to what parts of XML
> RE it makes sense to use in standardized YANG modules, making it easier for
> readers and implementations.
> 
> I think that it is fine for companies, vendors, etc to use the full breadth
> of XML RE if they wish.

Implementations have to be prepared to handle XSD pattern if they
claim compliance to YANG 1.0 and 1.1. So all this only helps
non-compliant implementations. This may indeed be a goal - but then we
should spell this out as such - this helps non-compliant
implementations (and they may still fail on the first \p{} that
you still allow).

If implementations do not implement the YANG pattern statement but
something else, then then they should ignore patterns they can't
understand and treat the pattern as if it would have been in a
description clause - i.e., leave it to humans to write the code that
implements the pattern correctly. Note that YANG does not say anything
how stuff is implemented.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Aug 30 05:35:49 2017
Return-Path: 
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 B6CBC133180 for ; Wed, 30 Aug 2017 05:35:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 gvQqSc8fWkSM for ; Wed, 30 Aug 2017 05:35:38 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0C113317A for ; Wed, 30 Aug 2017 05:35:37 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id B93B1F4B; Wed, 30 Aug 2017 14:35:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id j1JG0kHrNaV4; Wed, 30 Aug 2017 14:35:36 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 30 Aug 2017 14:35:36 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 98008200E2; Wed, 30 Aug 2017 14:35:36 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id x0PqfKOxxlyh; Wed, 30 Aug 2017 14:35:36 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36E60200E0; Wed, 30 Aug 2017 14:35:36 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 1FD704073640; Wed, 30 Aug 2017 14:35:36 +0200 (CEST)
Date: Wed, 30 Aug 2017 14:35:36 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Cc: acee@cisco.com, netmod@ietf.org
Message-ID: <20170830123536.cmfq5azhz3i7t7xp@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Bjorklund , acee@cisco.com, netmod@ietf.org
References: <14299503-509D-43BE-A938-0B7B88C3B249@juniper.net> <20170830.122823.2236525312698458242.mbj@tail-f.com>  <20170830.140756.691227201120065042.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170830.140756.691227201120065042.mbj@tail-f.com>
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: 
Subject: Re: [netmod] upcoming adoptions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Aug 2017 12:35:40 -0000

On Wed, Aug 30, 2017 at 02:07:56PM +0200, Martin Bjorklund wrote:
> 
> (*) YANG inherits the deprecation model from SMIv2.  We actually have
> three states: current -> deprecated -> obsolete.  And even when
> something is obsolete, it is not removed.  I guess in SMIv2 this was
> necessary b/c of OID assignments; maybe this could be revisited for
> YANG.  But this would require an update to RFC 7950.

The equivalent to the OID assignment is the name of a data node, I
think it should not be reused. It is bad for interoperability if /foo
suddenly means something entirely different.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         


From nobody Wed Aug 30 06:36:36 2017
Return-Path: 
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 7411C133241 for ; Wed, 30 Aug 2017 06:36:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 DHu30iib1IWt for ; Wed, 30 Aug 2017 06:36:32 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8DE81332AE for ; Wed, 30 Aug 2017 06:36:24 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id p67so27939270qkd.2 for ; Wed, 30 Aug 2017 06:36:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=/S5iFfCVMP7nepdtHkPjHyi6g/5Sau1546012w9q74Y=; b=l4DMnasy/Mpi8GJGVK0tErUAG3e1vAZqRqAFZbZUwGoRSHXrd0EZQF2Y5YAOQAIKq0 ur4xvJT+4mKMq+qvoMIVJQc8/QhWmws3lLLeJXTk1SSI2pMVeoZbvhGqv3L8Z7JHS1vH nTFyou0gGwSgjxkWmXKjlCo6t4b8R7pSXasOSJgac4M4P0eg3GNio4/L7QZk9mSHlR+0 tZFD8JAQ736wHoCIJAZ8geP4xwwVjvQmjwdKloHyyH2NKHueP7S5nUReZNEFXmu+JcQj JoxU2tqS20uVnYBqAsKHPc29d9R1EqkbITbydPpWTnuSkvhJU63RpuQad/fitEHmAhxQ 0Kyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=/S5iFfCVMP7nepdtHkPjHyi6g/5Sau1546012w9q74Y=; b=aup6UK1dV9mGZ6HM4+slIT8cR3DV834GBVwK6bMjYRTmjZnmUEBXNoh6v2QhBuf8qf Mj//SA8D4arJk2gkO0+j45nDdQByxtJ/0nMLrtulF1x8F2az9ifTDUdUCOAja+ClS3yr BZvmr/CoUFDJvUTArbFS5l3VI05Vqca5DivUxzYXrJWFl/uIXPlxp/pKSllFeh8XZTSv XVp8xM2LyGRIwkNzRLUMUSAsHtpmXxbXK6ACrEUHYOr0FjSDL9D5XvYf6doq2LQIWpqR iaegkaJLtk3+bexnjYgVkW4JOAdY87SU7693hIL9OS4wXoNwLZQ617e1gI3qS+AyIUIZ YVBQ==
X-Gm-Message-State: AHYfb5hEaAvnvPk05ShzTy37GA65LsJREjJsuPOxERF2bZX8nqnWb6xA elVaT6I8ED06PA==
X-Received: by 10.55.72.6 with SMTP id v6mr9755658qka.254.1504100183832; Wed, 30 Aug 2017 06:36:23 -0700 (PDT)
Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id g16sm3887163qkh.41.2017.08.30.06.36.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 30 Aug 2017 06:36:23 -0700 (PDT)
From: "Xufeng Liu" 
To: "'Lou Berger'" , "'Martin Bjorklund'" 
Cc: 
References: <7c99497f-d719-0fe2-01f5-a06d53c8fc68@labn.net> <1503929779.1715.65.camel@nic.cz> <81b138c6-9941-3313-979c-61edad7819a7@labn.net> <20170829.093743.762532630259333653.mbj@tail-f.com> <647a5ef0-968a-4eb7-322e-b3862a1252bd@labn.net>
In-Reply-To: <647a5ef0-968a-4eb7-322e-b3862a1252bd@labn.net>
Date: Wed, 30 Aug 2017 09:36:22 -0400
Message-ID: <032b01d32194$f876ad80$e9640880$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHxUPEv69dJWF6Of5ei10Qtp3GdWALIFXl0AoP40qwBbZrRBgFKp3geoiBcwQA=
Content-Language: en-us
x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5LnR4dCIgcD0iYzpcdXNlcnNceGxpdVxhcHBkYXRhXHJvYW1pbmdcMDlkODQ5YjYtMzJkMy00YTQwLTg1ZWUtNmI4NGJhMjllMzViXG1zZ3NcbXNnLTM0YTVhN2MwLThkODgtMTFlNy05YzI4LTE4NWUwZmUzYzQ1Y1xhbWUtdGVzdFwzNGE1YTdjMS04ZDg4LTExZTctOWMyOC0xODVlMGZlM2M0NWNib2R5LnR4dCIgc3o9IjY0NDAiIHQ9IjEzMTQ4NTczNzgxODc4ODE0OSIgaD0icmtSckppSTBlQnhBWFFEZkNHeXNCR2xITElZPSIgaWQ9IiIgYmw9IjAiIGJvPSIxIi8+PC9tZXRhPg==
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Aug 2017 13:36:34 -0000

> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Lou Berger
> Sent: Tuesday, August 29, 2017 8:35 AM
> To: Martin Bjorklund 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] schema mount open issue #1
>=20
> On 08/29/2017 03:37 AM, Martin Bjorklund wrote:
> > Lou Berger  wrote:
> >> Lada,
> >>
> >>
> >> On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
> >>> Lou Berger p=ED=B9e v Po 28. 08. 2017 v 09:40 -0400:
> >>>> Lada,
> >>>>
> >>>> On 8/28/2017 9:30 AM, Ladislav Lhotka wrote:
> >>>>>> Can you please take a look at it and see if we have any other
> disconnects?
> >>>>> This is really scary.
> >>>> I agree!
> >>>>
> >>>>> How can we expect poor data modellers to understand the concept =
if
> >>>>> we have such fundamental disconnects, after so many hours of
> >>>>> discussing it?
> >>>> This highlights why getting the text in (any) document is so
> >>>> important, and why discussions shouldn't be viewed as being =
closed
> >>>> until the impact on the text is agreed to!
> >>> I think many people still don't make much distinction between =
schema
> >>> mount (manipulation of the schema) and data mount. I still believe
> >>> we need to clearly separate these two concepts, preferably using =
two
> different mechanisms.
> >>
> >> Frankly, I'm focused on removing blocking issues on the current WG
> >> deliverable, i.e., schema mount.
> >> ...
> >>>> Lou
> >>>>
> >>>> PS is your view aligned with martin or our example?
> >>> If you mean shifting the XPath context node to the mount point
> >>> instance, then yes.
> >>
> >> funny, you answered yes to a choice!  I was asking if you think the
> >> mount point shows up as a node in the data tree, i.e., as shown in
> >> the example in
> >> =
https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B.1?
> >>
> >> from my perspective and my co-authors in the RTG area using schema
> >> mount, we've never heard of a (filesystem) mount point that doesn't
> >> show in the (directory) structure and this is the mental analogue
> >> we've been assuming. Since there never was an explicit
> >> example/discussion or text to dissuade us of this
> >
> > The current text says:
> >
> >   A "container" or "list" node becomes a mount point if the
> >   "mount-point" extension (defined in the "ietf-yang-schema-mount"
> >   module) is used in its definition.
>=20
> interesting, read that a few times to (now) get the gist of your =
intent.
>=20
> >
> > But of course we should clarify this.
> >
>=20
>=20
>=20
> >> , this disconnect was never noticed.  Certainly this needs to be
> >> explicit in the document (either way). The following change could =
be
> >> made to the schema mount draft (at a minimum):
> >>
> >> OLD
> >>           A mount point defines a place in the node hierarchy where
> >>           other data models may be attached. A server that =
implements
> >> a NEW
> >>           A mount point defines a node in a data tree under which
> >> instances of
> >>           other data models may be attached. A server that =
implements
> >> a
> >
> > I strongly object to letting the extension define a new data node.
>=20
> > This would be a new type of data node that presumably look a lot =
like
> > a container,
>=20
> agreed, just like a mount point looks a lot like a directory in a unix
file system.
>=20
> > and you'd have to define all sorts of rules for this new node (how =
it
> > is encoded in XML, JSON, CBOR; how it is handled in edit-config, how
> > it is mapped to RESTCONF resources etc etc).
>=20
> I'm don't see this, the rules would be the same as a container, as in
"mount
> points in data trees are encoded identically as containers".
>=20
> >
> > If you thought that the extension implicitly creates a node, adding =
an
> > explicit container won't do any harm; it will not change the schema
> > tree from what you thought it was.
>=20
> Well we could make this work, but it feels like every model that uses
schema has
> added complexity to its definition and use to perhaps avoid making =
some
minor
> tooling changes.  Keep in mind that any use of the mount point =
extension
will
> required changes in tooling.
>=20
> >
> > But I think we should also restrict the mount-point extension so =
that
> > there cannot be more than one mount-point in a given container.
> >
> In this case, I'd go further and say that the only thing in the =
container
(of the
> module schema) is the mount point and a mount point extension is only
valid
> within a container. (Then the semantics are the same as we expected, =
just
the
> syntax is different.)
>=20
[Xufeng] To me, the statement "mount-point" is confusing, because it
indicates more like an object such as "leaf", "leaf-list", or "list", =
rather
than a property such as "presence" or "must". It would be better to make =
the
name sound more towards "making the container a mount point". The =
following
current description on the mount-point statement does not make this =
better:

       description
         "The argument 'name' is a YANG identifier, i.e., it is of the
          type 'yang:yang-identifier'.
          ...
          A mount point defines a place in the node hierarchy where
          other data models may be attached.
          ...";

Added to the confusion is the history of LNE and NI models, which =
initially
used "leaf root", then "anydata root", and then changed to "mount-point
root". Since the beginning, the "root" has always been shown in the tree
view, just like a "leaf" (not like the "presence"). In the Sec 4 of the
current draft-ietf-netmod-schema-mount-06, there still the following =
tree:

     +--rw interfaces
     |  +--rw interface* [name]
     |     ...
     +--rw network-instances
        +--rw network-instance* [name]
           +--rw name
           +--rw root
              +--rw routing
                 ...

   Here, the "root" node is the mount point for the NI schema.

In a container, it is confusing syntax to use the similar substatement
syntax for both property and contained objects, but this is beyond the
point.

Thanks,
- Xufeng

> Lou
>=20
>=20
> >
> > /martin
> >
> >
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Aug 30 07:52:08 2017
Return-Path: 
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 7CF93132C36 for ; Wed, 30 Aug 2017 07:52:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 ljvXhL8MvMVX for ; Wed, 30 Aug 2017 07:52:04 -0700 (PDT)
Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B81EA124B18 for ; Wed, 30 Aug 2017 07:52:03 -0700 (PDT)
Received: by mail-wr0-x22d.google.com with SMTP id z91so19228845wrc.1 for ; Wed, 30 Aug 2017 07:52:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=FE6LuSj/ftXhdqx8xpAnNL7r+UDWdHwFr6it7D9bx+E=; b=swxQcAEZa9uoqY/JiWy7AGDMZLoPz73+ZUR5oIXtxa12e2A3Yr5k5wh4fthogrcV5/ T+kecihOQBK7xHlvEIE+QWyeRr5PqkXGbUSm3njPFycLCb6mHvVFYsPDwNbLCh/nXmAs qbz40UJtTmBB9jGMPfGwCU5DpNUt4NTw2jhkSYR4JQrP4s4rCdrsFX4OqFFhn+qI61W6 n52ETLXA3r+fkcQeNBptkWykRHhqsvTBSuWaJIxy6xX7ZIyYBA/3TuOCqVH+Z3BwPHaE Yx+J7LJSy5deZztfS4DR0cPG2OhtvQEcquWL8WHX3xIlpFmiW8LjFbeZC12PWqoPcZn7 xd1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=FE6LuSj/ftXhdqx8xpAnNL7r+UDWdHwFr6it7D9bx+E=; b=OxRT0YW9V85kFJMO/NJGhyz0WDEk+4QVa0PXz4qNTp6EWINnb/RO3F1gBfr8raJFhr NIGlwtzv4Ft1mNcZOuIhr8JzOhtJByx7CTQdFL96c1awUD8iXySaIx4Aa0/52ySGCn/r 3X3PNSI3RJ9ZdtVhByOThHgiacg1I64h+G0F0C0IWcAMpbr/HzPll1MGYNf8ISxrluDo 5IL8U7Z/Cgm3CgS1cp7gCpmG75btwVsceA32TZSSg611DJsAgoTJpY679P9OIgMkncJy FVKEAxOi0AlrAkabFNfFjNLhJi6UKCZTRsFajpvHn2ChekLw+DXurSbe+0GBbheBymz9 yXpg==
X-Gm-Message-State: AHYfb5g7/UdEc3kplnuFwi2G3FyxfA4zLP4E9u2xysCP73T7V/8PNoDw pyle289S5VdM3vHlRCkg9WPgF2xh3Yb/
X-Received: by 10.223.142.237 with SMTP id q100mr1399797wrb.228.1504104722108;  Wed, 30 Aug 2017 07:52:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.171.84 with HTTP; Wed, 30 Aug 2017 07:52:01 -0700 (PDT)
In-Reply-To: <20170830123156.cssrg5kklpo67fie@elstar.local>
References: <599F0991.7020900@tail-f.com>  <20170825125254.6nhnzkrar6fhu7zr@elstar.local>  <20170828154640.pzg7jfy5uepkb22q@elstar.local>    <20170830102902.2n5q6rgq2x2dxfq2@elstar.local>  <20170830123156.cssrg5kklpo67fie@elstar.local>
From: Andy Bierman 
Date: Wed, 30 Aug 2017 07:52:01 -0700
Message-ID: 
To: Juergen Schoenwaelder , Robert Wilton ,  Andy Bierman , Xufeng Liu ,  "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="f403045f51a2aaa8d30557f9ab56"
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Aug 2017 14:52:06 -0000

--f403045f51a2aaa8d30557f9ab56
Content-Type: text/plain; charset="UTF-8"

On Wed, Aug 30, 2017 at 5:31 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Wed, Aug 30, 2017 at 12:48:19PM +0100, Robert Wilton wrote:
> >
> >
> > On 30/08/2017 11:29, Juergen Schoenwaelder wrote:
> > > On Wed, Aug 30, 2017 at 10:16:30AM +0100, Robert Wilton wrote:
> > > > Hi Andy,
> > > >
> > > > What I am suggesting makes it easier for readers, because I am a
> proponent
> > > > of simpler regular expressions that are easy to read and understand.
> > > >
> > > > For example, I wonder how many YANG model readers would immediately
> > > > comprehend what this pattern statement means:
> > > >
> > > > pattern "\p{Sc}\p{Zs}?\p{Nd}+\.\p{Nd}{2}"?
> > > >
> > > > Does allowing such patterns really make it easier for model readers?
> > > This is always difficult to judge but to be fair you have to show how
> > > you express _the same_ (and not a subset) with some other kind of
> > > regular expressions. (My understanding is that \p{Sc} is a currency
> > > symbol.)
> > Yes, the expression would cover a currency amount, along with associated
> > symbol (e.g. "$200.00").
> >
> > If I was writing a module, I would probably use the following pattern
> > statement instead, which I think a lot more people would likely be able
> to
> > comprehend:
> >
> > pattern "[A-Z]{3}\s?\d+\.\d{2}", using the 3 letter, ISO 4217, currency
> codes.  e.g. ("USD 200.00")
>
> But that is not the same. Apples versus oranges. (I expect people to
> tell me that (i) currency is irrelevant and (ii) that three ASCII
> letter currency acronyms are better than currency symbols anyway but
> this is a separate discussion I am not interested in.)
>
> > >
> > > > The proposes guidelines obviously make it easier (or at least no
> harder) for
> > > > tool makers.
> > > >
> > > > I agree that there is an minor impact to model writers, but really
> only in
> > > > the sense that the guidelines would be telling them not to use the
> esoteric
> > > > options of the XML regex syntax that they probably don't know about
> anyway.
> > > What is 'esoteric' largely depends on your language environment. What
> > > you are saying by 'do not use \p{}' is essentially 'do not use any
> > > unicode long live ASCII'.
> > No, that is not my intention, i.e. I'm not suggesting banning all use of
> > \p{}, but instead limiting it to the character classes that seem like
> they
> > may plausibly be used in standardized YANG modules.
>
> This is entirely subjective. And if you still allow some \p{}, what is
> the point of the exercise?
>
> > I'm not trying to change what 6020/7950 defines the pattern statement as,
> > just give what I perceive as some pragmatic guidance as to what parts of
> XML
> > RE it makes sense to use in standardized YANG modules, making it easier
> for
> > readers and implementations.
> >
> > I think that it is fine for companies, vendors, etc to use the full
> breadth
> > of XML RE if they wish.
>
> Implementations have to be prepared to handle XSD pattern if they
> claim compliance to YANG 1.0 and 1.1. So all this only helps
> non-compliant implementations. This may indeed be a goal - but then we
> should spell this out as such - this helps non-compliant
> implementations (and they may still fail on the first \p{} that
> you still allow).
>
> If implementations do not implement the YANG pattern statement but
> something else, then then they should ignore patterns they can't
> understand and treat the pattern as if it would have been in a
> description clause - i.e., leave it to humans to write the code that
> implements the pattern correctly. Note that YANG does not say anything
> how stuff is implemented.
>


This does not work.
There are 3 outcomes from the regex compiler

1) proper syntax was used and accepted; pattern matches correctly
2) improper syntax was used and accepted; pattern matches incorrectly
3) improper syntax was used and rejected; compiler error generated

Case (2) is the really bad one and we have seen in in bug reports.

This issue was discussed in detail for almost 2 years and the conclusion was
that a YANG extension would be used to specify other pattern types than
the XSD pattern mandated by the standard.


> /js
>
>
Andy


> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>

--f403045f51a2aaa8d30557f9ab56
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Wed, Aug 30, 2017 at 5:31 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Aug 30, 2017 at 12:48:19P=
M +0100, Robert Wilton wrote:

>

>

> On 30/08/2017 11:29, Juergen Schoenwaelder wrote:

> > On Wed, Aug 30, 2017 at 10:16:30AM +0100, Robert Wilton wrote:
> > > Hi Andy,

> > >

> > > What I am suggesting makes it easier for readers, because I =
am a proponent

> > > of simpler regular expressions that are easy to read and und=
erstand.

> > >

> > > For example, I wonder how many YANG model readers would imme=
diately

> > > comprehend what this pattern statement means:

> > >

> > > pattern "\p{Sc}\p{Zs}?\p{Nd}+\.\p{Nd}{2}"?
> > >

> > > Does allowing such patterns really make it easier for model =
readers?

> > This is always difficult to judge but to be fair you have to show=
 how

> > you express _the same_ (and not a subset) with some other kind of=


> > regular expressions. (My understanding is that \p{Sc} is a curren=
cy

> > symbol.)

> Yes, the expression would cover a currency amount, along with associat=
ed

> symbol (e.g. "$200.00").

>

> If I was writing a module, I would probably use the following pattern<=
br>
> statement instead, which I think a lot more people would likely be abl=
e to

> comprehend:

>

> pattern "[A-Z]{3}\s?\d+\.\d{2}", using the 3 letter, ISO 421=
7, currency codes.=C2=A0 e.g. ("USD 200.00")



But that is not the same. Apples versus oranges. (I expect people to

tell me that (i) currency is irrelevant and (ii) that three ASCII

letter currency acronyms are better than currency symbols anyway but

this is a separate discussion I am not interested in.)



> >

> > > The proposes guidelines obviously make it easier (or at leas=
t no harder) for

> > > tool makers.

> > >

> > > I agree that there is an minor impact to model writers, but =
really only in

> > > the sense that the guidelines would be telling them not to u=
se the esoteric

> > > options of the XML regex syntax that they probably don't=
 know about anyway.

> > What is 'esoteric' largely depends on your language envir=
onment. What

> > you are saying by 'do not use \p{}' is essentially 'd=
o not use any

> > unicode long live ASCII'.

> No, that is not my intention, i.e. I'm not suggesting banning all =
use of

> \p{}, but instead limiting it to the character classes that seem like =
they

> may plausibly be used in standardized YANG modules.



This is entirely subjective. And if you still allow some \p{}, what is

the point of the exercise?



> I'm not trying to change what 6020/7950 defines the pattern statem=
ent as,

> just give what I perceive as some pragmatic guidance as to what parts =
of XML

> RE it makes sense to use in standardized YANG modules, making it easie=
r for

> readers and implementations.

>

> I think that it is fine for companies, vendors, etc to use the full br=
eadth

> of XML RE if they wish.



Implementations have to be prepared to handle XSD pattern if they

claim compliance to YANG 1.0 and 1.1. So all this only helps

non-compliant implementations. This may indeed be a goal - but then we

should spell this out as such - this helps non-compliant

implementations (and they may still fail on the first \p{} that

you still allow).



If implementations do not implement the YANG pattern statement but

something else, then then they should ignore patterns they can't

understand and treat the pattern as if it would have been in a

description clause - i.e., leave it to humans to write the code that

implements the pattern correctly. Note that YANG does not say anything

how stuff is implemented.


This does not work.
There are 3 outcomes from the regex compile=
r

1) proper syntax was used and accepted; pattern =
matches correctly
2) improper syntax was used and accepted; patte=
rn matches incorrectly
3) improper syntax was used and rejec=
ted; compiler error generated

Case (2) is th=
e really bad one and we have seen in in bug reports.

This issue was discussed in detail for almost 2 years and the conclusion=
 was
that a YANG extension would be used to specify other pattern=
 types than
the XSD pattern mandated by the standard.=C2=A0
=





/js



Andy
=C2=A0

--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28=
759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>





--f403045f51a2aaa8d30557f9ab56--


From nobody Wed Aug 30 09:44:12 2017
Return-Path: 
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 29F1F126BFD for ; Wed, 30 Aug 2017 09:44:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level: 
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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
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 cvtbKizcsHDx for ; Wed, 30 Aug 2017 09:44:07 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C2181201F8 for ; Wed, 30 Aug 2017 09:44:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22330; q=dns/txt; s=iport; t=1504111446; x=1505321046; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=MVFgRSa0Ff75OZPeIOQ+t2BgEzM2XOV3bDwdDBT2bmU=; b=ULt3Yr2+Qq1yAUn+hsjUW1W4zE+X7YUW553vOerVmr1pqTDntwS/6m8Y wJWqhTpB3BnBJ64PKhe8iBWY+oZCInicYm6krXFUWBgOI/gECpeWqfJf8 ZWTyiRagqigWqSEPmsFPHTGsujlSo5U+dyMnhvR5WVGkBXMycsE8ZtkgW g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CDAwA66qZZ/xbLJq1bAxoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYQ+gRWDd4sSkHUiljWCBCiDQIFfAoRqFAECAQEBAQEBAWsohRgBAQE?= =?us-ascii?q?BAgEjWwkCCQIQCCcDAgIbKxEGAQwGAgEBFYoQCI8LnWaCJyeLGwEBAQEBAQEBA?= =?us-ascii?q?gEBAQEBAQEBAQEBHQWDJYNQgg4Lgj01hEIBEgEJHBsmgkyCYQWKFoh2hSKIPpR?= =?us-ascii?q?MghKJQCSGdY1QiHM2IUFBCzIhCBwVhSiCPT82iFqCMgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.41,449,1498521600";  d="scan'208,217";a="654288007"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2017 16:44:01 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v7UGi1Fh016275; Wed, 30 Aug 2017 16:44:01 GMT
To: Andy Bierman , Juergen Schoenwaelder , Xufeng Liu , "netmod@ietf.org" 
References: <599F0991.7020900@tail-f.com>  <20170825125254.6nhnzkrar6fhu7zr@elstar.local>  <20170828154640.pzg7jfy5uepkb22q@elstar.local>    <20170830102902.2n5q6rgq2x2dxfq2@elstar.local>  <20170830123156.cssrg5kklpo67fie@elstar.local> 
From: Robert Wilton 
Message-ID: 
Date: Wed, 30 Aug 2017 17:44:01 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------398571CD940287B8D048BEF3"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Aug 2017 16:44:10 -0000

This is a multi-part message in MIME format.
--------------398571CD940287B8D048BEF3
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

On 30/08/2017 15:52, Andy Bierman wrote:
>
>
> On Wed, Aug 30, 2017 at 5:31 AM, Juergen Schoenwaelder 
>  > wrote:
>
>     On Wed, Aug 30, 2017 at 12:48:19PM +0100, Robert Wilton wrote:
>     >
>     >
>     > On 30/08/2017 11:29, Juergen Schoenwaelder wrote:
>     > > On Wed, Aug 30, 2017 at 10:16:30AM +0100, Robert Wilton wrote:
>     > > > Hi Andy,
>     > > >
>     > > > What I am suggesting makes it easier for readers, because I
>     am a proponent
>     > > > of simpler regular expressions that are easy to read and
>     understand.
>     > > >
>     > > > For example, I wonder how many YANG model readers would
>     immediately
>     > > > comprehend what this pattern statement means:
>     > > >
>     > > > pattern "\p{Sc}\p{Zs}?\p{Nd}+\.\p{Nd}{2}"?
>     > > >
>     > > > Does allowing such patterns really make it easier for model
>     readers?
>     > > This is always difficult to judge but to be fair you have to
>     show how
>     > > you express _the same_ (and not a subset) with some other kind of
>     > > regular expressions. (My understanding is that \p{Sc} is a
>     currency
>     > > symbol.)
>     > Yes, the expression would cover a currency amount, along with
>     associated
>     > symbol (e.g. "$200.00").
>     >
>     > If I was writing a module, I would probably use the following
>     pattern
>     > statement instead, which I think a lot more people would likely
>     be able to
>     > comprehend:
>     >
>     > pattern "[A-Z]{3}\s?\d+\.\d{2}", using the 3 letter, ISO 4217,
>     currency codes.  e.g. ("USD 200.00")
>
>     But that is not the same. Apples versus oranges. (I expect people to
>     tell me that (i) currency is irrelevant and (ii) that three ASCII
>     letter currency acronyms are better than currency symbols anyway but
>     this is a separate discussion I am not interested in.)
>
>     > >
>     > > > The proposes guidelines obviously make it easier (or at
>     least no harder) for
>     > > > tool makers.
>     > > >
>     > > > I agree that there is an minor impact to model writers, but
>     really only in
>     > > > the sense that the guidelines would be telling them not to
>     use the esoteric
>     > > > options of the XML regex syntax that they probably don't
>     know about anyway.
>     > > What is 'esoteric' largely depends on your language
>     environment. What
>     > > you are saying by 'do not use \p{}' is essentially 'do not use any
>     > > unicode long live ASCII'.
>     > No, that is not my intention, i.e. I'm not suggesting banning
>     all use of
>     > \p{}, but instead limiting it to the character classes that seem
>     like they
>     > may plausibly be used in standardized YANG modules.
>
>     This is entirely subjective. And if you still allow some \p{}, what is
>     the point of the exercise?
>
>     > I'm not trying to change what 6020/7950 defines the pattern
>     statement as,
>     > just give what I perceive as some pragmatic guidance as to what
>     parts of XML
>     > RE it makes sense to use in standardized YANG modules, making it
>     easier for
>     > readers and implementations.
>     >
>     > I think that it is fine for companies, vendors, etc to use the
>     full breadth
>     > of XML RE if they wish.
>
>     Implementations have to be prepared to handle XSD pattern if they
>     claim compliance to YANG 1.0 and 1.1. So all this only helps
>     non-compliant implementations. This may indeed be a goal - but then we
>     should spell this out as such - this helps non-compliant
>     implementations (and they may still fail on the first \p{} that
>     you still allow).
>
>     If implementations do not implement the YANG pattern statement but
>     something else, then then they should ignore patterns they can't
>     understand and treat the pattern as if it would have been in a
>     description clause - i.e., leave it to humans to write the code that
>     implements the pattern correctly. Note that YANG does not say anything
>     how stuff is implemented.
>
>
>
> This does not work.
> There are 3 outcomes from the regex compiler
>
> 1) proper syntax was used and accepted; pattern matches correctly
> 2) improper syntax was used and accepted; pattern matches incorrectly
> 3) improper syntax was used and rejected; compiler error generated
>
> Case (2) is the really bad one and we have seen in in bug reports.
>
> This issue was discussed in detail for almost 2 years and the 
> conclusion was
> that a YANG extension would be used to specify other pattern types than
> the XSD pattern mandated by the standard.
I actually think that XML RE is a good choice for YANG pattern 
statements (because it is one of the more simple RE languages), I just 
don't think that we need all of it.


First question: How many pattern statements in draft and standard IETF 
YANG modules actually use Unicode properties (e.g \p{}).
Answer: Just 2.  To add a zone at the end of the IPv4/IPv6 address.

E.g.       pattern
         '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
       +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
       + '(%[\p{N}\p{L}]+)?';

This could quite possibly have been written just as 
"\d{1,3}\.{3}\d{1,3)(%\w+)?" and not use Unicode properties at all.

There a couple more occurrences of Unicode character classes in the 
vendor models on github, but only to restrict them to the ASCII 
character set (oh the irony), which I believe can be accomplished 
without resorting to Unicode properties.


Another question: How often is character class subtraction (e.g. 
[A-Z-[PQ]] used in standard & the github YANG modules?
Answer: 0.  AFAICT, it isn't used at all, anywhere ...



Now, I'm not proposing using a different regex syntax for pattern 
statements, just a sensible subset of XSD RE, such that it easier for 
folks to read/review pattern statements, and it is easier for client and 
server implementations to translate into other common regex 
implementations if they so wish.

Of course, as part of that translation, I would expect a translation 
function to check and generate an error if the translation cannot handle 
the input regex (e.g. if it uses an obscure unmatched unicode property 
or a unicode block, or character class subtraction syntax).  This really 
doesn't seem hard to me.

But the XML RE language has stuff in it that I don't think anyone is 
ever going to use in a standardized network management YANG model. 
Forcing everyone to implement support for this stuff just seems like a 
complete waste of time and effort.  Looking at the regex info website it 
looks like there are about 143 unicode properties and blocks defined (it 
may be incomplete), or which I think that 135+ of these probably have no 
relevance in network management YANG modules, and the benefit of the 
remaining ones is pretty suspect.

I mean, how many network management YANG modules really need a pattern 
statement that only matches Runic characters?  Perhaps someone out there 
is busy defining "middle-earth.yang" ;-)

If I am the only person opposed to making life unnecessarily difficult 
to readers of YANG models, and client/server tool implementors 
interacting with YANG then it is probably time to give up this 
discussion. ;-)

Python, quite likely a common tool for client side network management, 
also doesn't seem to have any support of unicode properties or blocks.  
Perhaps implementations will hook it up to libxml2 instead, or write a 
full translation XML RE to Python RE conversion tool.  But probably most 
people will just feed the pattern statement into the native Python regex 
engine, and my guess is that this will probably work 95% of the time.  
The other 5% ... who knows what will happen ... oh well, better to try 
and fail than to not try at all.

Apologies if this email comes across as a rant.

Rob


>
>
>     /js
>
>
> Andy
>
>     --
>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>     Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>     Fax:   +49 421 200 3103              >
>
>


--------------398571CD940287B8D048BEF3
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi,

    

    
On 30/08/2017 15:52, Andy Bierman
      wrote:

    

    

      
      


        


          
On Wed, Aug 30, 2017 at 5:31 AM,
            Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
            wrote:

            
On Wed, Aug 30, 2017 at
              12:48:19PM +0100, Robert Wilton wrote:

              >

              >

              > On 30/08/2017 11:29, Juergen Schoenwaelder wrote:

              > > On Wed, Aug 30, 2017 at 10:16:30AM +0100, Robert
              Wilton wrote:

              > > > Hi Andy,

              > > >

              > > > What I am suggesting makes it easier for
              readers, because I am a proponent

              > > > of simpler regular expressions that are
              easy to read and understand.

              > > >

              > > > For example, I wonder how many YANG model
              readers would immediately

              > > > comprehend what this pattern statement
              means:

              > > >

              > > > pattern "\p{Sc}\p{Zs}?\p{Nd}+\.\p{Nd}{2}"?

              > > >

              > > > Does allowing such patterns really make it
              easier for model readers?

              > > This is always difficult to judge but to be fair
              you have to show how

              > > you express _the same_ (and not a subset) with
              some other kind of

              > > regular expressions. (My understanding is that
              \p{Sc} is a currency

              > > symbol.)

              > Yes, the expression would cover a currency amount,
              along with associated

              > symbol (e.g. "$200.00").

              >

              > If I was writing a module, I would probably use the
              following pattern

              > statement instead, which I think a lot more people
              would likely be able to

              > comprehend:

              >

              > pattern "[A-Z]{3}\s?\d+\.\d{2}", using the 3 letter,
              ISO 4217, currency codes.  e.g. ("USD 200.00")

              

              But that is not the same. Apples versus oranges. (I expect
              people to

              tell me that (i) currency is irrelevant and (ii) that
              three ASCII

              letter currency acronyms are better than currency symbols
              anyway but

              this is a separate discussion I am not interested in.)

              

              > >

              > > > The proposes guidelines obviously make it
              easier (or at least no harder) for

              > > > tool makers.

              > > >

              > > > I agree that there is an minor impact to
              model writers, but really only in

              > > > the sense that the guidelines would be
              telling them not to use the esoteric

              > > > options of the XML regex syntax that they
              probably don't know about anyway.

              > > What is 'esoteric' largely depends on your
              language environment. What

              > > you are saying by 'do not use \p{}' is
              essentially 'do not use any

              > > unicode long live ASCII'.

              > No, that is not my intention, i.e. I'm not suggesting
              banning all use of

              > \p{}, but instead limiting it to the character
              classes that seem like they

              > may plausibly be used in standardized YANG modules.

              

              This is entirely subjective. And if you still allow some
              \p{}, what is

              the point of the exercise?

              

              > I'm not trying to change what 6020/7950 defines the
              pattern statement as,

              > just give what I perceive as some pragmatic guidance
              as to what parts of XML

              > RE it makes sense to use in standardized YANG
              modules, making it easier for

              > readers and implementations.

              >

              > I think that it is fine for companies, vendors, etc
              to use the full breadth

              > of XML RE if they wish.

              

              Implementations have to be prepared to handle XSD pattern
              if they

              claim compliance to YANG 1.0 and 1.1. So all this only
              helps

              non-compliant implementations. This may indeed be a goal -
              but then we

              should spell this out as such - this helps non-compliant

              implementations (and they may still fail on the first \p{}
              that

              you still allow).

              

              If implementations do not implement the YANG pattern
              statement but

              something else, then then they should ignore patterns they
              can't

              understand and treat the pattern as if it would have been
              in a

              description clause - i.e., leave it to humans to write the
              code that

              implements the pattern correctly. Note that YANG does not
              say anything

              how stuff is implemented.

            

            


            

            


            

            
This does not work.

          

        

      

    

    

      

        

          

            
There are 3 outcomes from the regex compiler

            


            

            
1) proper syntax was used and accepted; pattern matches
              correctly

            
2) improper syntax was used and accepted; pattern
              matches incorrectly

            

              
3) improper syntax was used and rejected; compiler
                error generated

            

            


            

            
Case (2) is the really bad one and we have seen in in
              bug reports.

            


            

            
This issue was discussed in detail for almost 2 years
              and the conclusion was

            
that a YANG extension would be used to specify other
              pattern types than

            
the XSD pattern mandated by the standard. 

            

          

        

      

    

    I actually think that XML RE is a good choice for YANG pattern
    statements (because it is one of the more simple RE languages), I
    just don't think that we need all of it.

    

    

    First question: How many pattern statements in draft and standard
    IETF YANG modules actually use Unicode properties (e.g \p{}).

    Answer: Just 2.  To add a zone at the end of the IPv4/IPv6 address.

    

    E.g.       pattern

            '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'

          +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'

          + '(%[\p{N}\p{L}]+)?';

    

    This could quite possibly have been written just as
    "\d{1,3}\.{3}\d{1,3)(%\w+)?" and not use Unicode properties at all.

    

    There a couple more occurrences of Unicode character classes in the
    vendor models on github, but only to restrict them to the ASCII
    character set (oh the irony), which I believe can be accomplished
    without resorting to Unicode properties.

    

    

    Another question: How often is character class subtraction (e.g.
    [A-Z-[PQ]] used in standard & the github YANG modules?

    Answer: 0.  AFAICT, it isn't used at all, anywhere ...

    

    

    

    Now, I'm not proposing using a different regex syntax for pattern
    statements, just a sensible subset of XSD RE, such that it easier
    for folks to read/review pattern statements, and it is easier for
    client and server implementations to translate into other common
    regex implementations if they so wish.

    

    Of course, as part of that translation, I would expect a translation
    function to check and generate an error if the translation cannot
    handle the input regex (e.g. if it uses an obscure unmatched unicode
    property or a unicode block, or character class subtraction
    syntax).  This really doesn't seem hard to me.

     

    But the XML RE language has stuff in it that I don't think anyone is
    ever going to use in a standardized network management YANG model.  
    Forcing everyone to implement support for this stuff just seems like
    a complete waste of time and effort.  Looking at the regex info
    website it looks like there are about 143 unicode properties and
    blocks defined (it may be incomplete), or which I think that 135+ of
    these probably have no relevance in network management YANG modules,
    and the benefit of the remaining ones is pretty suspect.

    

    I mean, how many network management YANG modules really need a
    pattern statement that only matches Runic characters?  Perhaps
    someone out there is busy defining "middle-earth.yang" ;-)

    

    If I am the only person opposed to making life unnecessarily
    difficult to readers of YANG models, and client/server tool
    implementors interacting with YANG then it is probably time to give
    up this discussion. ;-)

    

    Python, quite likely a common tool for client side network
    management, also doesn't seem to have any support of unicode
    properties or blocks.  Perhaps implementations will hook it up to
    libxml2 instead, or write a full translation XML RE to Python RE
    conversion tool.  But probably most people will just feed the
    pattern statement into the native Python regex engine, and my guess
    is that this will probably work 95% of the time.  The other 5% ...
    who knows what will happen ... oh well, better to try and fail than
    to not try at all.

    

    Apologies if this email comes across as a rant.

    

    Rob

    

    

    

      

        

          

            


            

            

              

                  /js

                  

                

            


            

            
Andy

            
 

            

                  --

                  Juergen Schoenwaelder           Jacobs University
                  Bremen gGmbH

                  Phone: +49 421 200 3587         Campus Ring 1 | 28759
                  Bremen | Germany

                  Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

                

          

          

        

      

    

    

  


--------------398571CD940287B8D048BEF3--


From nobody Wed Aug 30 13:03:51 2017
Return-Path: 
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 86BFD1326EC for ; Wed, 30 Aug 2017 13:03:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.8
X-Spam-Level: 
X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 lhXM4ydO4WMv for ; Wed, 30 Aug 2017 13:03:46 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0116.outbound.protection.outlook.com [104.47.33.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C881132955 for ; Wed, 30 Aug 2017 13:03:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=T+F9zVXMePsYAzw1AUFArIRW2UmcrKug5gsWN9k535Y=; b=Vbcuj/rTHO9DC77HLdRiHSUDyKdlD9l5wEzq+c7lYK+QAfiyUXTktW5izUqLJ1jQLohWXcZeaAqNcHj0pYYeySl912SUNWEb0ip037zBViADiB5tSkk2Gml7yVf0fBqE//U9CjABYbqBgjue8hMospffSGXm4ZhkIFmPS4JGWKo=
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1169.namprd05.prod.outlook.com (10.160.113.154) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.3; Wed, 30 Aug 2017 20:03:44 +0000
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.20.0013.011; Wed, 30 Aug 2017 20:03:44 +0000
From: Kent Watsen 
To: Robert Wilton , Andy Bierman , Juergen Schoenwaelder , Xufeng Liu , "netmod@ietf.org" 
Thread-Topic: [netmod] Potential additions to rfc6087bis: RegEx guidelines
Thread-Index: AdMcU4SqqeTEr3DWR4ygcD75zJMNgAAS/WQAAAKnWIAAEce1gAAC0wKAACiZxdAAAInsAACWumggAAY3AAAAL4LGgAADyxwAACOm9gAAAoiAAAACxNmAAAGF9gAABORygAAD6VuA///0vgA=
Date: Wed, 30 Aug 2017 20:03:44 +0000
Message-ID: <36B35912-1FC1-4B05-A61A-44D21813CC79@juniper.net>
References: <599F0991.7020900@tail-f.com>  <20170825125254.6nhnzkrar6fhu7zr@elstar.local>  <20170828154640.pzg7jfy5uepkb22q@elstar.local>    <20170830102902.2n5q6rgq2x2dxfq2@elstar.local>  <20170830123156.cssrg5kklpo67fie@elstar.local>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.10]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1169; 6:aKly56dno1eW8l4aH2yyCcPivJDoC6HLDkygxMHZrYTpMIXh++UjceKcNQzGCdBu709qhMPXtfM5tbc/zs7E1W2TU3w35aGgCj9vN+DW8poLHR+CBypABnFmxVEcgQeTA643rea/YdvyMV89ttneWwRkTIKVV/xwcjNoFDXB1TmlO1Oufc08KeUgYH0fhXusf6Bl3UG8XvrZSeTvqXewXnTiTPzfZlD9YB/n6EogxMbE3lZ2Iui/ry4EB9FJyl1ntMIXv5FLVzsSBtRqhdQFqfLA0VfcaQP3Xpvf1DCWNWvLlh/LhV9A9w19RHsXhiG7sBvie5sU5ekVd7hPD8eiRg==; 5:yy2WvuvR39nPelNG6QZ7kIiDvmXZuz3Ijkx7xQM5UcSlk/sL2j712tz2y5D5v6GKIYIFQOiebSa/LXsFgdVjSvzUp3rUiAB7SSXfsobkMFvf0V4Rv3wP0eKR9fgxlVNcrXTR8F1XXDDdLJi020XEkA==; 24:6NqgEEWVhpEHtNVvXjOoLPdhJISIxcktJIMA2H0sQoDZm+ivmS1dQ2kYaX9rwQZa0zVxCxww0ArXD0g11cMLIjE7joTWsTaX7NJP8Tez/nk=; 7:ixDqFNctwAH/tnrZ1+GTCOk1dYJGdvc4VLbsuZsI0/7zUdBjiTMXk42SAmKuLhtYUotPjsre1Zk0PS1+noxOVMofXUTWtUiRfU4fl/ngbLiaE3ZvQngA1mU8SMMyPTiHSdLj2Du2HuBRVj24WQZ1e8abYcXxaxWBGTrLmql+JazNF6GkoaJiIaIkdk0YBqXudqsDpcs39Zd+3Z2HAJS/ajGCRXt1wXgdy8bZthc+fQ4=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: b423f92e-211e-42f4-6f7b-08d4efe237c7
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(48565401081)(300000503095)(300135400095)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1169; 
x-ms-traffictypediagnostic: BN3PR0501MB1169:
x-exchange-antispam-report-test: UriScan:(158342451672863)(244540007438412)(95692535739014)(21748063052155); 
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(6055026)(6041248)(20161123558100)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1169; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1169; 
x-forefront-prvs: 041517DFAB
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(24454002)(189002)(199003)(51444003)(377454003)(83716003)(6436002)(105586002)(25786009)(2950100002)(229853002)(6246003)(106356001)(6486002)(77096006)(99286003)(6506006)(236005)(53936002)(6512007)(54896002)(6306002)(33656002)(36756003)(5660300001)(86362001)(101416001)(50986999)(2900100001)(76176999)(54356999)(66066001)(189998001)(3846002)(102836003)(6116002)(53546010)(3660700001)(8936002)(478600001)(7736002)(8676002)(83506001)(68736007)(81166006)(82746002)(93886005)(4001350100001)(14454004)(3280700002)(2906002)(81156014)(97736004)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1169; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_36B359121FC14B05A61A44D21813CC79junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2017 20:03:44.2922 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1169
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Aug 2017 20:03:49 -0000

--_000_36B359121FC14B05A61A44D21813CC79junipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpBcyBBbmR5IHNheXMsIHJlYWRhYmlsaXR5IGlzICMxLCBhbmQgaXQgZm9sbG93cyB0aGF0IGEg
cmVzdHJpY3RlZCBzdWJzZXQgd291bGQgYmUgbW9yZSB1bmRlcnN0YW5kYWJsZS4gIFN0YW5kYXJk
aXppbmcgdGhpcyB3b3VsZCByZXF1aXJlIGFuIHVwZGF0ZSB0byBSRkMgNzk1MCAocmVhZDogbm90
IGdvaW5nIHRvIGhhcHBlbiBhbnl0aW1lIHNvb24pLiAgTWF5YmUgd2UgY291bGQgc3RhcnQgd2l0
aCBqdXN0IGhhdmluZyBhIHRvb2wgZGV0ZWN0IHdoZW4gc29tZXRoaW5nIG91dHNpZGUgdGhlIGNv
bW1vbi1zdWJzZXQgaXMgdXNlZC4gICBDYW4gYSAiY29tbW9uIHN1YnNldCIgYmUgd2VsbC1kZWZp
bmVkPyAgLSAiY29tbW9uIiBiZXR3ZWVuIGhvdyBtYW55IGVuZ2luZXM/IC0gd291bGQgaXQgYmUg
Zm9yZXZlciBldm9sdmluZz8NCg0KSy4gLy8gY29udHJpYnV0b3INCg0KDQpPbiA4LzMwLzE3LCAx
Mjo0NCBQTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgUm9iZXJ0IFdpbHRvbiIgPG5ldG1vZC1ib3Vu
Y2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9m
IHJ3aWx0b25AY2lzY28uY29tPG1haWx0bzpyd2lsdG9uQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpJ
IGFjdHVhbGx5IHRoaW5rIHRoYXQgWE1MIFJFIGlzIGEgZ29vZCBjaG9pY2UgZm9yIFlBTkcgcGF0
dGVybiBzdGF0ZW1lbnRzIChiZWNhdXNlIGl0IGlzIG9uZSBvZiB0aGUgbW9yZSBzaW1wbGUgUkUg
bGFuZ3VhZ2VzKSwgSSBqdXN0IGRvbid0IHRoaW5rIHRoYXQgd2UgbmVlZCBhbGwgb2YgaXQuDQoN
Cg0KRmlyc3QgcXVlc3Rpb246IEhvdyBtYW55IHBhdHRlcm4gc3RhdGVtZW50cyBpbiBkcmFmdCBh
bmQgc3RhbmRhcmQgSUVURiBZQU5HIG1vZHVsZXMgYWN0dWFsbHkgdXNlIFVuaWNvZGUgcHJvcGVy
dGllcyAoZS5nIFxwe30pLg0KQW5zd2VyOiBKdXN0IDIuICBUbyBhZGQgYSB6b25lIGF0IHRoZSBl
bmQgb2YgdGhlIElQdjQvSVB2NiBhZGRyZXNzLg0KDQpFLmcuICAgICAgIHBhdHRlcm4NCiAgICAg
ICAgJygoWzAtOV18WzEtOV1bMC05XXwxWzAtOV1bMC05XXwyWzAtNF1bMC05XXwyNVswLTVdKVwu
KXszfScNCiAgICAgICsgICcoWzAtOV18WzEtOV1bMC05XXwxWzAtOV1bMC05XXwyWzAtNF1bMC05
XXwyNVswLTVdKScNCiAgICAgICsgJyglW1xwe059XHB7TH1dKyk/JzsNCg0KVGhpcyBjb3VsZCBx
dWl0ZSBwb3NzaWJseSBoYXZlIGJlZW4gd3JpdHRlbiBqdXN0IGFzICJcZHsxLDN9XC57M31cZHsx
LDMpKCVcdyspPyIgYW5kIG5vdCB1c2UgVW5pY29kZSBwcm9wZXJ0aWVzIGF0IGFsbC4NCg0KVGhl
cmUgYSBjb3VwbGUgbW9yZSBvY2N1cnJlbmNlcyBvZiBVbmljb2RlIGNoYXJhY3RlciBjbGFzc2Vz
IGluIHRoZSB2ZW5kb3IgbW9kZWxzIG9uIGdpdGh1YiwgYnV0IG9ubHkgdG8gcmVzdHJpY3QgdGhl
bSB0byB0aGUgQVNDSUkgY2hhcmFjdGVyIHNldCAob2ggdGhlIGlyb255KSwgd2hpY2ggSSBiZWxp
ZXZlIGNhbiBiZSBhY2NvbXBsaXNoZWQgd2l0aG91dCByZXNvcnRpbmcgdG8gVW5pY29kZSBwcm9w
ZXJ0aWVzLg0KDQoNCkFub3RoZXIgcXVlc3Rpb246IEhvdyBvZnRlbiBpcyBjaGFyYWN0ZXIgY2xh
c3Mgc3VidHJhY3Rpb24gKGUuZy4gW0EtWi1bUFFdXSB1c2VkIGluIHN0YW5kYXJkICYgdGhlIGdp
dGh1YiBZQU5HIG1vZHVsZXM/DQpBbnN3ZXI6IDAuICBBRkFJQ1QsIGl0IGlzbid0IHVzZWQgYXQg
YWxsLCBhbnl3aGVyZSAuLi4NCg0KDQoNCk5vdywgSSdtIG5vdCBwcm9wb3NpbmcgdXNpbmcgYSBk
aWZmZXJlbnQgcmVnZXggc3ludGF4IGZvciBwYXR0ZXJuIHN0YXRlbWVudHMsIGp1c3QgYSBzZW5z
aWJsZSBzdWJzZXQgb2YgWFNEIFJFLCBzdWNoIHRoYXQgaXQgZWFzaWVyIGZvciBmb2xrcyB0byBy
ZWFkL3JldmlldyBwYXR0ZXJuIHN0YXRlbWVudHMsIGFuZCBpdCBpcyBlYXNpZXIgZm9yIGNsaWVu
dCBhbmQgc2VydmVyIGltcGxlbWVudGF0aW9ucyB0byB0cmFuc2xhdGUgaW50byBvdGhlciBjb21t
b24gcmVnZXggaW1wbGVtZW50YXRpb25zIGlmIHRoZXkgc28gd2lzaC4NCg0KT2YgY291cnNlLCBh
cyBwYXJ0IG9mIHRoYXQgdHJhbnNsYXRpb24sIEkgd291bGQgZXhwZWN0IGEgdHJhbnNsYXRpb24g
ZnVuY3Rpb24gdG8gY2hlY2sgYW5kIGdlbmVyYXRlIGFuIGVycm9yIGlmIHRoZSB0cmFuc2xhdGlv
biBjYW5ub3QgaGFuZGxlIHRoZSBpbnB1dCByZWdleCAoZS5nLiBpZiBpdCB1c2VzIGFuIG9ic2N1
cmUgdW5tYXRjaGVkIHVuaWNvZGUgcHJvcGVydHkgb3IgYSB1bmljb2RlIGJsb2NrLCBvciBjaGFy
YWN0ZXIgY2xhc3Mgc3VidHJhY3Rpb24gc3ludGF4KS4gIFRoaXMgcmVhbGx5IGRvZXNuJ3Qgc2Vl
bSBoYXJkIHRvIG1lLg0KDQpCdXQgdGhlIFhNTCBSRSBsYW5ndWFnZSBoYXMgc3R1ZmYgaW4gaXQg
dGhhdCBJIGRvbid0IHRoaW5rIGFueW9uZSBpcyBldmVyIGdvaW5nIHRvIHVzZSBpbiBhIHN0YW5k
YXJkaXplZCBuZXR3b3JrIG1hbmFnZW1lbnQgWUFORyBtb2RlbC4gICBGb3JjaW5nIGV2ZXJ5b25l
IHRvIGltcGxlbWVudCBzdXBwb3J0IGZvciB0aGlzIHN0dWZmIGp1c3Qgc2VlbXMgbGlrZSBhIGNv
bXBsZXRlIHdhc3RlIG9mIHRpbWUgYW5kIGVmZm9ydC4gIExvb2tpbmcgYXQgdGhlIHJlZ2V4IGlu
Zm8gd2Vic2l0ZSBpdCBsb29rcyBsaWtlIHRoZXJlIGFyZSBhYm91dCAxNDMgdW5pY29kZSBwcm9w
ZXJ0aWVzIGFuZCBibG9ja3MgZGVmaW5lZCAoaXQgbWF5IGJlIGluY29tcGxldGUpLCBvciB3aGlj
aCBJIHRoaW5rIHRoYXQgMTM1KyBvZiB0aGVzZSBwcm9iYWJseSBoYXZlIG5vIHJlbGV2YW5jZSBp
biBuZXR3b3JrIG1hbmFnZW1lbnQgWUFORyBtb2R1bGVzLCBhbmQgdGhlIGJlbmVmaXQgb2YgdGhl
IHJlbWFpbmluZyBvbmVzIGlzIHByZXR0eSBzdXNwZWN0Lg0KDQpJIG1lYW4sIGhvdyBtYW55IG5l
dHdvcmsgbWFuYWdlbWVudCBZQU5HIG1vZHVsZXMgcmVhbGx5IG5lZWQgYSBwYXR0ZXJuIHN0YXRl
bWVudCB0aGF0IG9ubHkgbWF0Y2hlcyBSdW5pYyBjaGFyYWN0ZXJzPyAgUGVyaGFwcyBzb21lb25l
IG91dCB0aGVyZSBpcyBidXN5IGRlZmluaW5nICJtaWRkbGUtZWFydGgueWFuZyIgOy0pDQoNCklm
IEkgYW0gdGhlIG9ubHkgcGVyc29uIG9wcG9zZWQgdG8gbWFraW5nIGxpZmUgdW5uZWNlc3Nhcmls
eSBkaWZmaWN1bHQgdG8gcmVhZGVycyBvZiBZQU5HIG1vZGVscywgYW5kIGNsaWVudC9zZXJ2ZXIg
dG9vbCBpbXBsZW1lbnRvcnMgaW50ZXJhY3Rpbmcgd2l0aCBZQU5HIHRoZW4gaXQgaXMgcHJvYmFi
bHkgdGltZSB0byBnaXZlIHVwIHRoaXMgZGlzY3Vzc2lvbi4gOy0pDQoNClB5dGhvbiwgcXVpdGUg
bGlrZWx5IGEgY29tbW9uIHRvb2wgZm9yIGNsaWVudCBzaWRlIG5ldHdvcmsgbWFuYWdlbWVudCwg
YWxzbyBkb2Vzbid0IHNlZW0gdG8gaGF2ZSBhbnkgc3VwcG9ydCBvZiB1bmljb2RlIHByb3BlcnRp
ZXMgb3IgYmxvY2tzLiAgUGVyaGFwcyBpbXBsZW1lbnRhdGlvbnMgd2lsbCBob29rIGl0IHVwIHRv
IGxpYnhtbDIgaW5zdGVhZCwgb3Igd3JpdGUgYSBmdWxsIHRyYW5zbGF0aW9uIFhNTCBSRSB0byBQ
eXRob24gUkUgY29udmVyc2lvbiB0b29sLiAgQnV0IHByb2JhYmx5IG1vc3QgcGVvcGxlIHdpbGwg
anVzdCBmZWVkIHRoZSBwYXR0ZXJuIHN0YXRlbWVudCBpbnRvIHRoZSBuYXRpdmUgUHl0aG9uIHJl
Z2V4IGVuZ2luZSwgYW5kIG15IGd1ZXNzIGlzIHRoYXQgdGhpcyB3aWxsIHByb2JhYmx5IHdvcmsg
OTUlIG9mIHRoZSB0aW1lLiAgVGhlIG90aGVyIDUlIC4uLiB3aG8ga25vd3Mgd2hhdCB3aWxsIGhh
cHBlbiAuLi4gb2ggd2VsbCwgYmV0dGVyIHRvIHRyeSBhbmQgZmFpbCB0aGFuIHRvIG5vdCB0cnkg
YXQgYWxsLg0KDQpBcG9sb2dpZXMgaWYgdGhpcyBlbWFpbCBjb21lcyBhY3Jvc3MgYXMgYSByYW50
Lg0KDQpSb2INCg0KDQoNCg==

--_000_36B359121FC14B05A61A44D21813CC79junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN
CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp
bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iO30NCnNwYW4uZ21haWwtaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLWhvZW56
Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN
Cglmb250LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsN
Cgljb2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0
aW9uOm5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0K
CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0
LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7
bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX
b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu
MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+
PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGlu
az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LWZhbWlseTpDYWxpYnJpIj5BcyBBbmR5IHNheXMsIHJlYWRhYmlsaXR5IGlzICMxLCBh
bmQgaXQgZm9sbG93cyB0aGF0IGEgcmVzdHJpY3RlZCBzdWJzZXQgd291bGQgYmUgbW9yZSB1bmRl
cnN0YW5kYWJsZS4gJm5ic3A7U3RhbmRhcmRpemluZyB0aGlzIHdvdWxkIHJlcXVpcmUgYW4gdXBk
YXRlIHRvIFJGQyA3OTUwIChyZWFkOiBub3QgZ29pbmcgdG8gaGFwcGVuIGFueXRpbWUgc29vbiku
ICZuYnNwO01heWJlDQogd2UgY291bGQgc3RhcnQgd2l0aCBqdXN0IGhhdmluZyBhIHRvb2wgZGV0
ZWN0IHdoZW4gc29tZXRoaW5nIG91dHNpZGUgdGhlIGNvbW1vbi1zdWJzZXQgaXMgdXNlZC4mbmJz
cDsgJm5ic3A7Q2FuIGEgJnF1b3Q7Y29tbW9uIHN1YnNldCZxdW90OyBiZSB3ZWxsLWRlZmluZWQ/
Jm5ic3A7IC0gJnF1b3Q7Y29tbW9uJnF1b3Q7IGJldHdlZW4gaG93IG1hbnkgZW5naW5lcz8gLSB3
b3VsZCBpdCBiZSBmb3JldmVyIGV2b2x2aW5nPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Sy4gLy8gY29udHJpYnV0b3I8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJy
aSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gOC8zMC8xNywgMTI6NDQg
UE0sICZxdW90O25ldG1vZCBvbiBiZWhhbGYgb2YgUm9iZXJ0IFdpbHRvbiZxdW90OyAmbHQ7PGEg
aHJlZj0ibWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnIj5uZXRtb2QtYm91bmNlc0BpZXRm
Lm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86cndpbHRvbkBjaXNjby5jb20i
PnJ3aWx0b25AY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFjdHVhbGx5IHRoaW5rIHRoYXQgWE1M
IFJFIGlzIGEgZ29vZCBjaG9pY2UgZm9yIFlBTkcgcGF0dGVybiBzdGF0ZW1lbnRzIChiZWNhdXNl
IGl0IGlzIG9uZSBvZiB0aGUgbW9yZSBzaW1wbGUgUkUgbGFuZ3VhZ2VzKSwgSSBqdXN0IGRvbid0
IHRoaW5rIHRoYXQgd2UgbmVlZCBhbGwgb2YgaXQuPGJyPg0KPGJyPg0KPGJyPg0KRmlyc3QgcXVl
c3Rpb246IEhvdyBtYW55IHBhdHRlcm4gc3RhdGVtZW50cyBpbiBkcmFmdCBhbmQgc3RhbmRhcmQg
SUVURiBZQU5HIG1vZHVsZXMgYWN0dWFsbHkgdXNlIFVuaWNvZGUgcHJvcGVydGllcyAoZS5nIFxw
e30pLjxicj4NCkFuc3dlcjogSnVzdCAyLiZuYnNwOyBUbyBhZGQgYSB6b25lIGF0IHRoZSBlbmQg
b2YgdGhlIElQdjQvSVB2NiBhZGRyZXNzLjxicj4NCjxicj4NCkUuZy4gJm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IHBhdHRlcm48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgJygoWzAtOV18WzEtOV1bMC05XXwxWzAtOV1bMC05XXwyWzAtNF1bMC05
XXwyNVswLTVdKVwuKXszfSc8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0
MzsmbmJzcDsgJyhbMC05XXxbMS05XVswLTldfDFbMC05XVswLTldfDJbMC00XVswLTldfDI1WzAt
NV0pJzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOyAnKCVbXHB7Tn1c
cHtMfV0mIzQzOyk/Jzs8YnI+DQo8YnI+DQpUaGlzIGNvdWxkIHF1aXRlIHBvc3NpYmx5IGhhdmUg
YmVlbiB3cml0dGVuIGp1c3QgYXMgJnF1b3Q7XGR7MSwzfVwuezN9XGR7MSwzKSglXHcmIzQzOyk/
JnF1b3Q7IGFuZCBub3QgdXNlIFVuaWNvZGUgcHJvcGVydGllcyBhdCBhbGwuPGJyPg0KPGJyPg0K
VGhlcmUgYSBjb3VwbGUgbW9yZSBvY2N1cnJlbmNlcyBvZiBVbmljb2RlIGNoYXJhY3RlciBjbGFz
c2VzIGluIHRoZSB2ZW5kb3IgbW9kZWxzIG9uIGdpdGh1YiwgYnV0IG9ubHkgdG8gcmVzdHJpY3Qg
dGhlbSB0byB0aGUgQVNDSUkgY2hhcmFjdGVyIHNldCAob2ggdGhlIGlyb255KSwgd2hpY2ggSSBi
ZWxpZXZlIGNhbiBiZSBhY2NvbXBsaXNoZWQgd2l0aG91dCByZXNvcnRpbmcgdG8gVW5pY29kZSBw
cm9wZXJ0aWVzLjxicj4NCjxicj4NCjxicj4NCkFub3RoZXIgcXVlc3Rpb246IEhvdyBvZnRlbiBp
cyBjaGFyYWN0ZXIgY2xhc3Mgc3VidHJhY3Rpb24gKGUuZy4gW0EtWi1bUFFdXSB1c2VkIGluIHN0
YW5kYXJkICZhbXA7IHRoZSBnaXRodWIgWUFORyBtb2R1bGVzPzxicj4NCkFuc3dlcjogMC4mbmJz
cDsgQUZBSUNULCBpdCBpc24ndCB1c2VkIGF0IGFsbCwgYW55d2hlcmUgLi4uPGJyPg0KPGJyPg0K
PGJyPg0KPGJyPg0KTm93LCBJJ20gbm90IHByb3Bvc2luZyB1c2luZyBhIGRpZmZlcmVudCByZWdl
eCBzeW50YXggZm9yIHBhdHRlcm4gc3RhdGVtZW50cywganVzdCBhIHNlbnNpYmxlIHN1YnNldCBv
ZiBYU0QgUkUsIHN1Y2ggdGhhdCBpdCBlYXNpZXIgZm9yIGZvbGtzIHRvIHJlYWQvcmV2aWV3IHBh
dHRlcm4gc3RhdGVtZW50cywgYW5kIGl0IGlzIGVhc2llciBmb3IgY2xpZW50IGFuZCBzZXJ2ZXIg
aW1wbGVtZW50YXRpb25zIHRvIHRyYW5zbGF0ZSBpbnRvIG90aGVyIGNvbW1vbg0KIHJlZ2V4IGlt
cGxlbWVudGF0aW9ucyBpZiB0aGV5IHNvIHdpc2guPGJyPg0KPGJyPg0KT2YgY291cnNlLCBhcyBw
YXJ0IG9mIHRoYXQgdHJhbnNsYXRpb24sIEkgd291bGQgZXhwZWN0IGEgdHJhbnNsYXRpb24gZnVu
Y3Rpb24gdG8gY2hlY2sgYW5kIGdlbmVyYXRlIGFuIGVycm9yIGlmIHRoZSB0cmFuc2xhdGlvbiBj
YW5ub3QgaGFuZGxlIHRoZSBpbnB1dCByZWdleCAoZS5nLiBpZiBpdCB1c2VzIGFuIG9ic2N1cmUg
dW5tYXRjaGVkIHVuaWNvZGUgcHJvcGVydHkgb3IgYSB1bmljb2RlIGJsb2NrLCBvciBjaGFyYWN0
ZXIgY2xhc3Mgc3VidHJhY3Rpb24NCiBzeW50YXgpLiZuYnNwOyBUaGlzIHJlYWxseSBkb2Vzbid0
IHNlZW0gaGFyZCB0byBtZS48YnI+DQombmJzcDs8YnI+DQpCdXQgdGhlIFhNTCBSRSBsYW5ndWFn
ZSBoYXMgc3R1ZmYgaW4gaXQgdGhhdCBJIGRvbid0IHRoaW5rIGFueW9uZSBpcyBldmVyIGdvaW5n
IHRvIHVzZSBpbiBhIHN0YW5kYXJkaXplZCBuZXR3b3JrIG1hbmFnZW1lbnQgWUFORyBtb2RlbC4m
bmJzcDsmbmJzcDsgRm9yY2luZyBldmVyeW9uZSB0byBpbXBsZW1lbnQgc3VwcG9ydCBmb3IgdGhp
cyBzdHVmZiBqdXN0IHNlZW1zIGxpa2UgYSBjb21wbGV0ZSB3YXN0ZSBvZiB0aW1lIGFuZCBlZmZv
cnQuJm5ic3A7IExvb2tpbmcgYXQgdGhlDQogcmVnZXggaW5mbyB3ZWJzaXRlIGl0IGxvb2tzIGxp
a2UgdGhlcmUgYXJlIGFib3V0IDE0MyB1bmljb2RlIHByb3BlcnRpZXMgYW5kIGJsb2NrcyBkZWZp
bmVkIChpdCBtYXkgYmUgaW5jb21wbGV0ZSksIG9yIHdoaWNoIEkgdGhpbmsgdGhhdCAxMzUmIzQz
OyBvZiB0aGVzZSBwcm9iYWJseSBoYXZlIG5vIHJlbGV2YW5jZSBpbiBuZXR3b3JrIG1hbmFnZW1l
bnQgWUFORyBtb2R1bGVzLCBhbmQgdGhlIGJlbmVmaXQgb2YgdGhlIHJlbWFpbmluZyBvbmVzIGlz
IHByZXR0eQ0KIHN1c3BlY3QuPGJyPg0KPGJyPg0KSSBtZWFuLCBob3cgbWFueSBuZXR3b3JrIG1h
bmFnZW1lbnQgWUFORyBtb2R1bGVzIHJlYWxseSBuZWVkIGEgcGF0dGVybiBzdGF0ZW1lbnQgdGhh
dCBvbmx5IG1hdGNoZXMgUnVuaWMgY2hhcmFjdGVycz8mbmJzcDsgUGVyaGFwcyBzb21lb25lIG91
dCB0aGVyZSBpcyBidXN5IGRlZmluaW5nICZxdW90O21pZGRsZS1lYXJ0aC55YW5nJnF1b3Q7IDst
KTxicj4NCjxicj4NCklmIEkgYW0gdGhlIG9ubHkgcGVyc29uIG9wcG9zZWQgdG8gbWFraW5nIGxp
ZmUgdW5uZWNlc3NhcmlseSBkaWZmaWN1bHQgdG8gcmVhZGVycyBvZiBZQU5HIG1vZGVscywgYW5k
IGNsaWVudC9zZXJ2ZXIgdG9vbCBpbXBsZW1lbnRvcnMgaW50ZXJhY3Rpbmcgd2l0aCBZQU5HIHRo
ZW4gaXQgaXMgcHJvYmFibHkgdGltZSB0byBnaXZlIHVwIHRoaXMgZGlzY3Vzc2lvbi4gOy0pPGJy
Pg0KPGJyPg0KUHl0aG9uLCBxdWl0ZSBsaWtlbHkgYSBjb21tb24gdG9vbCBmb3IgY2xpZW50IHNp
ZGUgbmV0d29yayBtYW5hZ2VtZW50LCBhbHNvIGRvZXNuJ3Qgc2VlbSB0byBoYXZlIGFueSBzdXBw
b3J0IG9mIHVuaWNvZGUgcHJvcGVydGllcyBvciBibG9ja3MuJm5ic3A7IFBlcmhhcHMgaW1wbGVt
ZW50YXRpb25zIHdpbGwgaG9vayBpdCB1cCB0byBsaWJ4bWwyIGluc3RlYWQsIG9yIHdyaXRlIGEg
ZnVsbCB0cmFuc2xhdGlvbiBYTUwgUkUgdG8gUHl0aG9uIFJFIGNvbnZlcnNpb24NCiB0b29sLiZu
YnNwOyBCdXQgcHJvYmFibHkgbW9zdCBwZW9wbGUgd2lsbCBqdXN0IGZlZWQgdGhlIHBhdHRlcm4g
c3RhdGVtZW50IGludG8gdGhlIG5hdGl2ZSBQeXRob24gcmVnZXggZW5naW5lLCBhbmQgbXkgZ3Vl
c3MgaXMgdGhhdCB0aGlzIHdpbGwgcHJvYmFibHkgd29yayA5NSUgb2YgdGhlIHRpbWUuJm5ic3A7
IFRoZSBvdGhlciA1JSAuLi4gd2hvIGtub3dzIHdoYXQgd2lsbCBoYXBwZW4gLi4uIG9oIHdlbGws
IGJldHRlciB0byB0cnkgYW5kIGZhaWwgdGhhbiB0bw0KIG5vdCB0cnkgYXQgYWxsLjxicj4NCjxi
cj4NCkFwb2xvZ2llcyBpZiB0aGlzIGVtYWlsIGNvbWVzIGFjcm9zcyBhcyBhIHJhbnQuPGJyPg0K
PGJyPg0KUm9iPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_36B359121FC14B05A61A44D21813CC79junipernet_--


From nobody Wed Aug 30 13:29:12 2017
Return-Path: 
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 C97E9132153 for ; Wed, 30 Aug 2017 13:29:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.7
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 c2mvwyCr48_D for ; Wed, 30 Aug 2017 13:29:07 -0700 (PDT)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (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 4F72F132027 for ; Wed, 30 Aug 2017 13:29:07 -0700 (PDT)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id BCB971AB30F for ; Wed, 30 Aug 2017 14:28:59 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id 3YUv1w00j2SSUrH01YUyeW; Wed, 30 Aug 2017 14:28:59 -0600
X-Authority-Analysis: v=2.2 cv=fJ5J5dSe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=xqWC_Br6kY4A:10 a=KeKAF7QvOSUA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=AUd_NHdVAAAA:8 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=MTE66lYk7uOODUV6ctkA:9 a=RVGzd9TZlGtLIOoA:21 a=ZGdhZczLGRZAguD5:21 a=QEXdDO2ut3YA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=CIz-Ma2wDdfP3nXu0Q0A:9 a=oRBO0ZCgHuQTvlZa:21 a=lXX0cFCtKZMzALt6:21 a=HW2NdUlOYq9rkfRE:21 a=_W_S_7VecoQA:10 a=9ZYBcOd_X9kS2t7VFny2:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To: Message-ID:Date:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ee1W0LyIdkPrKrZyKM6WMBkumoHays3rSK8FDZf0KpQ=; b=tRDNpaBFaPtragCnidEzrAIn1m HBQOhiaWL07hnNU028+hMJURA/LtLHsdoYNufLTFVpaMeDRVKi41eFe4Irt5nb6ghnZQc0SC8a6Qs Mvk6hsolpz2DkrVXxy4jjpM6G;
Received: from [172.58.217.215] (port=44835 helo=[IPV6:2607:fb90:68ad:3afb:0:47:9828:f201]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dn9bb-000WGv-6A; Wed, 30 Aug 2017 14:28:55 -0600
From: Lou Berger 
To: Robert Wilton , Andy Bierman , Juergen Schoenwaelder , Xufeng Liu , 
Date: Wed, 30 Aug 2017 16:28:51 -0400
Message-ID: <15e34d507d0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: 
References: <599F0991.7020900@tail-f.com>  <20170825125254.6nhnzkrar6fhu7zr@elstar.local>  <20170828154640.pzg7jfy5uepkb22q@elstar.local>    <20170830102902.2n5q6rgq2x2dxfq2@elstar.local>  <20170830123156.cssrg5kklpo67fie@elstar.local>  
User-Agent: AquaMail/1.10.0-403 (build: 101000001)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----------15e34d50bf06fc827d33f07b37"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 172.58.217.215
X-Exim-ID: 1dn9bb-000WGv-6A
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: ([IPV6:2607:fb90:68ad:3afb:0:47:9828:f201]) [172.58.217.215]:44835
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Aug 2017 20:29:11 -0000

This is a multi-part message in MIME format.
------------15e34d50bf06fc827d33f07b37
Content-Type: text/plain; format=flowed; charset="UTF-8"
Content-Transfer-Encoding: 8bit

Rob

Speaking as a contributor.


On August 30, 2017 12:44:42 PM Robert Wilton  wrote:

> Hi,
>
> On 30/08/2017 15:52, Andy Bierman wrote:
>>
>>
>> On Wed, Aug 30, 2017 at 5:31 AM, Juergen Schoenwaelder
>> > > wrote:
>>
>>     On Wed, Aug 30, 2017 at 12:48:19PM +0100, Robert Wilton wrote:
>>     >
>>     >
>>     > On 30/08/2017 11:29, Juergen Schoenwaelder wrote:
>>     > > On Wed, Aug 30, 2017 at 10:16:30AM +0100, Robert Wilton wrote:
>>     > > > Hi Andy,
>>     > > >
>>     > > > What I am suggesting makes it easier for readers, because I
>>     am a proponent
>>     > > > of simpler regular expressions that are easy to read and
>>     understand.
>>     > > >
>>     > > > For example, I wonder how many YANG model readers would
>>     immediately
>>     > > > comprehend what this pattern statement means:
>>     > > >
>>     > > > pattern "\p{Sc}\p{Zs}?\p{Nd}+\.\p{Nd}{2}"?
>>     > > >
>>     > > > Does allowing such patterns really make it easier for model
>>     readers?
>>     > > This is always difficult to judge but to be fair you have to
>>     show how
>>     > > you express _the same_ (and not a subset) with some other kind of
>>     > > regular expressions. (My understanding is that \p{Sc} is a
>>     currency
>>     > > symbol.)
>>     > Yes, the expression would cover a currency amount, along with
>>     associated
>>     > symbol (e.g. "$200.00").
>>     >
>>     > If I was writing a module, I would probably use the following
>>     pattern
>>     > statement instead, which I think a lot more people would likely
>>     be able to
>>     > comprehend:
>>     >
>>     > pattern "[A-Z]{3}\s?\d+\.\d{2}", using the 3 letter, ISO 4217,
>>     currency codes.  e.g. ("USD 200.00")
>>
>>     But that is not the same. Apples versus oranges. (I expect people to
>>     tell me that (i) currency is irrelevant and (ii) that three ASCII
>>     letter currency acronyms are better than currency symbols anyway but
>>     this is a separate discussion I am not interested in.)
>>
>>     > >
>>     > > > The proposes guidelines obviously make it easier (or at
>>     least no harder) for
>>     > > > tool makers.
>>     > > >
>>     > > > I agree that there is an minor impact to model writers, but
>>     really only in
>>     > > > the sense that the guidelines would be telling them not to
>>     use the esoteric
>>     > > > options of the XML regex syntax that they probably don't
>>     know about anyway.
>>     > > What is 'esoteric' largely depends on your language
>>     environment. What
>>     > > you are saying by 'do not use \p{}' is essentially 'do not use any
>>     > > unicode long live ASCII'.
>>     > No, that is not my intention, i.e. I'm not suggesting banning
>>     all use of
>>     > \p{}, but instead limiting it to the character classes that seem
>>     like they
>>     > may plausibly be used in standardized YANG modules.
>>
>>     This is entirely subjective. And if you still allow some \p{}, what is
>>     the point of the exercise?
>>
>>     > I'm not trying to change what 6020/7950 defines the pattern
>>     statement as,
>>     > just give what I perceive as some pragmatic guidance as to what
>>     parts of XML
>>     > RE it makes sense to use in standardized YANG modules, making it
>>     easier for
>>     > readers and implementations.
>>     >
>>     > I think that it is fine for companies, vendors, etc to use the
>>     full breadth
>>     > of XML RE if they wish.
>>
>>     Implementations have to be prepared to handle XSD pattern if they
>>     claim compliance to YANG 1.0 and 1.1. So all this only helps
>>     non-compliant implementations. This may indeed be a goal - but then we
>>     should spell this out as such - this helps non-compliant
>>     implementations (and they may still fail on the first \p{} that
>>     you still allow).
>>
>>     If implementations do not implement the YANG pattern statement but
>>     something else, then then they should ignore patterns they can't
>>     understand and treat the pattern as if it would have been in a
>>     description clause - i.e., leave it to humans to write the code that
>>     implements the pattern correctly. Note that YANG does not say anything
>>     how stuff is implemented.
>>
>>
>>
>> This does not work.
>> There are 3 outcomes from the regex compiler
>>
>> 1) proper syntax was used and accepted; pattern matches correctly
>> 2) improper syntax was used and accepted; pattern matches incorrectly
>> 3) improper syntax was used and rejected; compiler error generated
>>
>> Case (2) is the really bad one and we have seen in in bug reports.
>>
>> This issue was discussed in detail for almost 2 years and the
>> conclusion was
>> that a YANG extension would be used to specify other pattern types than
>> the XSD pattern mandated by the standard.
> I actually think that XML RE is a good choice for YANG pattern
> statements (because it is one of the more simple RE languages), I just
> don't think that we need all of it.
>
>
> First question: How many pattern statements in draft and standard IETF
> YANG modules actually use Unicode properties (e.g \p{}).
> Answer: Just 2.  To add a zone at the end of the IPv4/IPv6 address.
>
> E.g.       pattern
>          '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
>        +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
>        + '(%[\p{N}\p{L}]+)?';
>
> This could quite possibly have been written just as
> "\d{1,3}\.{3}\d{1,3)(%\w+)?" and not use Unicode properties at all.
>
> There a couple more occurrences of Unicode character classes in the
> vendor models on github, but only to restrict them to the ASCII
> character set (oh the irony), which I believe can be accomplished
> without resorting to Unicode properties.
>
>
> Another question: How often is character class subtraction (e.g.
> [A-Z-[PQ]] used in standard & the github YANG modules?
> Answer: 0.  AFAICT, it isn't used at all, anywhere ...
>
>
>
> Now, I'm not proposing using a different regex syntax for pattern
> statements, just a sensible subset of XSD RE, such that it easier for
> folks to read/review pattern statements, and it is easier for client and
> server implementations to translate into other common regex
> implementations if they so wish.
>
> Of course, as part of that translation, I would expect a translation
> function to check and generate an error if the translation cannot handle
> the input regex (e.g. if it uses an obscure unmatched unicode property
> or a unicode block, or character class subtraction syntax).  This really
> doesn't seem hard to me.
>
> But the XML RE language has stuff in it that I don't think anyone is
> ever going to use in a standardized network management YANG model.
> Forcing everyone to implement support for this stuff just seems like a
> complete waste of time and effort.  Looking at the regex info website it
> looks like there are about 143 unicode properties and blocks defined (it
> may be incomplete), or which I think that 135+ of these probably have no
> relevance in network management YANG modules, and the benefit of the
> remaining ones is pretty suspect.
>
> I mean, how many network management YANG modules really need a pattern
> statement that only matches Runic characters?  Perhaps someone out there
> is busy defining "middle-earth.yang" ;-)
>
> If I am the only person opposed to making life unnecessarily difficult
> to readers of YANG models, and client/server tool implementors
> interacting with YANG then it is probably time to give up this
> discussion. ;-)
>

I agree with you 100%

And I see Xufeng's proposal for 6087bis as an attempt at putting some 
language together to support this desire. Perhaps you can suggest alternate 
language.

Lou

> Python, quite likely a common tool for client side network management,
> also doesn't seem to have any support of unicode properties or blocks. 
> Perhaps implementations will hook it up to libxml2 instead, or write a
> full translation XML RE to Python RE conversion tool.  But probably most
> people will just feed the pattern statement into the native Python regex
> engine, and my guess is that this will probably work 95% of the time. 
> The other 5% ... who knows what will happen ... oh well, better to try
> and fail than to not try at all.
>
> Apologies if this email comes across as a rant.
>
> Rob
>
>
>>
>>
>>     /js
>>
>>
>> Andy
>>
>>     --
>>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>     Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>>     Fax:   +49 421 200 3103         >     >
>>
>>
>
>
>
>
> ----------
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

------------15e34d50bf06fc827d33f07b37
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit









Rob


Speaking as a contributor.





On
August 30, 2017 12:44:42 PM Robert Wilton <rwilton@cisco.com> wrote:


>
Hi,

>

> On 30/08/2017 15:52, Andy Bierman wrote:

>>

>>

>> On Wed, Aug 30, 2017 at 5:31 AM, Juergen Schoenwaelder 

>> <j.schoenwaelder@jacobs-university.de 

>> <mailto:j.schoenwaelder@jacobs-university.de>> wrote:

>>

>>     On Wed, Aug 30, 2017 at 12:48:19PM +0100,
Robert Wilton wrote:

>>     >

>>     >

>>     > On 30/08/2017 11:29, Juergen
Schoenwaelder wrote:

>>     > > On Wed, Aug 30, 2017 at
10:16:30AM +0100, Robert Wilton wrote:

>>     > > > Hi Andy,

>>     > > >

>>     > > > What I am suggesting makes
it easier for readers, because I

>>     am a proponent

>>     > > > of simpler regular
expressions that are easy to read and

>>     understand.

>>     > > >

>>     > > > For example, I wonder how
many YANG model readers would

>>     immediately

>>     > > > comprehend what this
pattern statement means:

>>     > > >

>>     > > > pattern
"\p{Sc}\p{Zs}?\p{Nd}+\.\p{Nd}{2}"?

>>     > > >

>>     > > > Does allowing such patterns
really make it easier for model

>>     readers?

>>     > > This is always difficult to
judge but to be fair you have to

>>     show how

>>     > > you express _the same_ (and not
a subset) with some other kind of

>>     > > regular expressions. (My
understanding is that \p{Sc} is a

>>     currency

>>     > > symbol.)

>>     > Yes, the expression would cover a
currency amount, along with

>>     associated

>>     > symbol (e.g. "$200.00").

>>     >

>>     > If I was writing a module, I would
probably use the following

>>     pattern

>>     > statement instead, which I think a
lot more people would likely

>>     be able to

>>     > comprehend:

>>     >

>>     > pattern "[A-Z]{3}\s?\d+\.\d{2}",
using the 3 letter, ISO 4217,

>>     currency codes.  e.g. ("USD 200.00")

>>

>>     But that is not the same. Apples versus
oranges. (I expect people to

>>     tell me that (i) currency is irrelevant
and (ii) that three ASCII

>>     letter currency acronyms are better than
currency symbols anyway but

>>     this is a separate discussion I am not
interested in.)

>>

>>     > >

>>     > > > The proposes guidelines
obviously make it easier (or at

>>     least no harder) for

>>     > > > tool makers.

>>     > > >

>>     > > > I agree that there is an
minor impact to model writers, but

>>     really only in

>>     > > > the sense that the
guidelines would be telling them not to

>>     use the esoteric

>>     > > > options of the XML regex
syntax that they probably don't

>>     know about anyway.

>>     > > What is 'esoteric' largely
depends on your language

>>     environment. What

>>     > > you are saying by 'do not use
\p{}' is essentially 'do not use any

>>     > > unicode long live ASCII'.

>>     > No, that is not my intention, i.e.
I'm not suggesting banning

>>     all use of

>>     > \p{}, but instead limiting it to the
character classes that seem

>>     like they

>>     > may plausibly be used in standardized
YANG modules.

>>

>>     This is entirely subjective. And if you
still allow some \p{}, what is

>>     the point of the exercise?

>>

>>     > I'm not trying to change what
6020/7950 defines the pattern

>>     statement as,

>>     > just give what I perceive as some
pragmatic guidance as to what

>>     parts of XML

>>     > RE it makes sense to use in
standardized YANG modules, making it

>>     easier for

>>     > readers and implementations.

>>     >

>>     > I think that it is fine for
companies, vendors, etc to use the

>>     full breadth

>>     > of XML RE if they wish.

>>

>>     Implementations have to be prepared to
handle XSD pattern if they

>>     claim compliance to YANG 1.0 and 1.1. So
all this only helps

>>     non-compliant implementations. This may
indeed be a goal - but then we

>>     should spell this out as such - this helps
non-compliant

>>     implementations (and they may still fail
on the first \p{} that

>>     you still allow).

>>

>>     If implementations do not implement the
YANG pattern statement but

>>     something else, then then they should
ignore patterns they can't

>>     understand and treat the pattern as if it
would have been in a

>>     description clause - i.e., leave it to
humans to write the code that

>>     implements the pattern correctly. Note
that YANG does not say anything

>>     how stuff is implemented.

>>

>>

>>

>> This does not work.

>> There are 3 outcomes from the regex compiler

>>

>> 1) proper syntax was used and accepted; pattern matches correctly

>> 2) improper syntax was used and accepted; pattern matches
incorrectly

>> 3) improper syntax was used and rejected; compiler error generated

>>

>> Case (2) is the really bad one and we have seen in in bug reports.

>>

>> This issue was discussed in detail for almost 2 years and the 

>> conclusion was

>> that a YANG extension would be used to specify other pattern types
than

>> the XSD pattern mandated by the standard.

> I actually think that XML RE is a good choice for YANG pattern 

> statements (because it is one of the more simple RE languages), I just


> don't think that we need all of it.

>

>

> First question: How many pattern statements in draft and standard IETF


> YANG modules actually use Unicode properties (e.g \p{}).

> Answer: Just 2.  To add a zone at the end of the IPv4/IPv6 address.

>

> E.g.       pattern

>         
'(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'

>        +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'

>        + '(%[\p{N}\p{L}]+)?';

>

> This could quite possibly have been written just as 

> "\d{1,3}\.{3}\d{1,3)(%\w+)?" and not use Unicode properties at all.

>

> There a couple more occurrences of Unicode character classes in the 

> vendor models on github, but only to restrict them to the ASCII 

> character set (oh the irony), which I believe can be accomplished 

> without resorting to Unicode properties.

>

>

> Another question: How often is character class subtraction (e.g. 

> [A-Z-[PQ]] used in standard & the github YANG modules?

> Answer: 0.  AFAICT, it isn't used at all, anywhere ...

>

>

>

> Now, I'm not proposing using a different regex syntax for pattern 

> statements, just a sensible subset of XSD RE, such that it easier for 

> folks to read/review pattern statements, and it is easier for client
and 

> server implementations to translate into other common regex 

> implementations if they so wish.

>

> Of course, as part of that translation, I would expect a translation 

> function to check and generate an error if the translation cannot
handle 

> the input regex (e.g. if it uses an obscure unmatched unicode property


> or a unicode block, or character class subtraction syntax).  This
really 

> doesn't seem hard to me.

>

> But the XML RE language has stuff in it that I don't think anyone is 

> ever going to use in a standardized network management YANG model. 

> Forcing everyone to implement support for this stuff just seems like a


> complete waste of time and effort.  Looking at the regex info website
it 

> looks like there are about 143 unicode properties and blocks defined
(it 

> may be incomplete), or which I think that 135+ of these probably have
no 

> relevance in network management YANG modules, and the benefit of the 

> remaining ones is pretty suspect.

>

> I mean, how many network management YANG modules really need a pattern


> statement that only matches Runic characters?  Perhaps someone out
there 

> is busy defining "middle-earth.yang" ;-)

>

> If I am the only person opposed to making life unnecessarily difficult


> to readers of YANG models, and client/server tool implementors 

> interacting with YANG then it is probably time to give up this 

> discussion. ;-)

>




I agree with you 100%


And I see Xufeng's proposal for
6087bis as an attempt at putting some language together to support this
desire. Perhaps you can suggest alternate language.


Lou 






> Python, quite likely a common tool for client side network management,


> also doesn't seem to have any support of unicode properties or
blocks.  

> Perhaps implementations will hook it up to libxml2 instead, or write a


> full translation XML RE to Python RE conversion tool.  But probably
most 

> people will just feed the pattern statement into the native Python
regex 

> engine, and my guess is that this will probably work 95% of the time. 


> The other 5% ... who knows what will happen ... oh well, better to try


> and fail than to not try at all.

>

> Apologies if this email comes across as a rant.

>

> Rob

>

>

>>

>>

>>     /js

>>

>>

>> Andy

>>

>>     --

>>     Juergen Schoenwaelder           Jacobs
University Bremen gGmbH

>>     Phone: +49 421 200 3587         Campus
Ring 1 | 28759 Bremen | Germany

>>     Fax:   +49 421 200 3103         <http://www.jacobs-university.de/

>>     <http://www.jacobs-university.de/>>

>>

>>

>

>

>

>

> ----------

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

> https://www.ietf.org/mailman/listinfo/netmod

>








------------15e34d50bf06fc827d33f07b37--


From nobody Wed Aug 30 13:43:30 2017
Return-Path: 
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 851AE1252BA for ; Wed, 30 Aug 2017 13:43:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 uOWoZPWZePCV for ; Wed, 30 Aug 2017 13:43:25 -0700 (PDT)
Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE91132153 for ; Wed, 30 Aug 2017 13:43:25 -0700 (PDT)
Received: by mail-wr0-x22d.google.com with SMTP id j29so20572269wre.2 for ; Wed, 30 Aug 2017 13:43:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5boL/FriCPOQ6IsbdHBNg8sk/HFIQtvzAFBv1QrYbz8=; b=AcmA5dU1a0kHFlQZqE3Os/PM3v4JlT6/jCe7atXuM2UftDPklXHLi9SW1ljQ8Rmk6R ZHS5XD2Pomc91Oct8ElkL6ETyIi4juBm0l78gWmoBTzgqMbdN/WNgUwj+kR6yRLKcPlf xj9Wko+Ymbqn/Kxsi6YHhXviGssaRrQrG4VeglGQ39cF4FUYq4SU39GHaBwCn0aweBY2 hUlGzIR0tR4NuGHL348vSNBgyylHfCmmxUhKaHCBafeOtj+asQWV++ztUgE6gXzJK0lS UJRvAybJFauOBHA8tWDnjVsDjA56uwhczNJE+lwiafJBNhBPqht9+rxQQbz+R/4BGAqK N1HQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5boL/FriCPOQ6IsbdHBNg8sk/HFIQtvzAFBv1QrYbz8=; b=MJ62gmjP1wIUl50fZtWqPTVgfHlkHmoyzoA/7sn8c/udZ42ntwkk7Leyobzw1JrTn9 ehd2iY9H6mYlQcUdy64r6QemCrNl+ZlWRLO5nu3i4waMng2k+0m6656G/t0QQAYljKeI pHRggytWNOf1FFH7lU+xpBMtORbI/qDzwgqWjSt7x+5G+RDVL0UK5zaV+e6cV4/T/aXA KY6Vv+idwlnbOoHgkTH2fW1tI4EgKAutmMtAIFXR78cuQgwsr8Xwod0L4MJpIYpJhuws 8GWd9utdHPFtBfRXZclTL0OLkUa38zbzjkuiavsQUCc5rIceZLv88eHSiQZFNLTrEwBr Qs2A==
X-Gm-Message-State: AHYfb5jEv/+4LxwQQxwubymzaaKkyGNJYUcxb2YYb5GAZWgARKLJW3r8 dmO/+R/7k9DDKZTWVYRKctE9QCUSmNci
X-Received: by 10.223.142.237 with SMTP id q100mr1980423wrb.228.1504125803679;  Wed, 30 Aug 2017 13:43:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.171.84 with HTTP; Wed, 30 Aug 2017 13:43:22 -0700 (PDT)
In-Reply-To: <36B35912-1FC1-4B05-A61A-44D21813CC79@juniper.net>
References: <599F0991.7020900@tail-f.com>  <20170825125254.6nhnzkrar6fhu7zr@elstar.local>  <20170828154640.pzg7jfy5uepkb22q@elstar.local>    <20170830102902.2n5q6rgq2x2dxfq2@elstar.local>  <20170830123156.cssrg5kklpo67fie@elstar.local>   <36B35912-1FC1-4B05-A61A-44D21813CC79@juniper.net>
From: Andy Bierman 
Date: Wed, 30 Aug 2017 13:43:22 -0700
Message-ID: 
To: Kent Watsen 
Cc: Robert Wilton ,  Juergen Schoenwaelder , Xufeng Liu , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary="f403045f51a239e52e0557fe948e"
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Aug 2017 20:43:28 -0000

--f403045f51a239e52e0557fe948e
Content-Type: text/plain; charset="UTF-8"

Hi,

The burden this would place on YANG writers would be excessive.
We learned in SNMP-land about CLRs (clever little rules) and how they need
to be avoided. We learned that special-casing and sub-setting technology has
its own costs, which are usually more than the problem they solved
(e.g., counter names MUST be in the plural form).


Andy



On Wed, Aug 30, 2017 at 1:03 PM, Kent Watsen  wrote:

>
>
> As Andy says, readability is #1, and it follows that a restricted subset
> would be more understandable.  Standardizing this would require an update
> to RFC 7950 (read: not going to happen anytime soon).  Maybe we could start
> with just having a tool detect when something outside the common-subset is
> used.   Can a "common subset" be well-defined?  - "common" between how many
> engines? - would it be forever evolving?
>
>
>
> K. // contributor
>
>
>
>
>
> On 8/30/17, 12:44 PM, "netmod on behalf of Robert Wilton" <
> netmod-bounces@ietf.org on behalf of rwilton@cisco.com> wrote:
>
>
>
> I actually think that XML RE is a good choice for YANG pattern statements
> (because it is one of the more simple RE languages), I just don't think
> that we need all of it.
>
>
> First question: How many pattern statements in draft and standard IETF
> YANG modules actually use Unicode properties (e.g \p{}).
> Answer: Just 2.  To add a zone at the end of the IPv4/IPv6 address.
>
> E.g.       pattern
>         '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
>       +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
>       + '(%[\p{N}\p{L}]+)?';
>
> This could quite possibly have been written just as
> "\d{1,3}\.{3}\d{1,3)(%\w+)?" and not use Unicode properties at all.
>
> There a couple more occurrences of Unicode character classes in the vendor
> models on github, but only to restrict them to the ASCII character set (oh
> the irony), which I believe can be accomplished without resorting to
> Unicode properties.
>
>
> Another question: How often is character class subtraction (e.g.
> [A-Z-[PQ]] used in standard & the github YANG modules?
> Answer: 0.  AFAICT, it isn't used at all, anywhere ...
>
>
>
> Now, I'm not proposing using a different regex syntax for pattern
> statements, just a sensible subset of XSD RE, such that it easier for folks
> to read/review pattern statements, and it is easier for client and server
> implementations to translate into other common regex implementations if
> they so wish.
>
> Of course, as part of that translation, I would expect a translation
> function to check and generate an error if the translation cannot handle
> the input regex (e.g. if it uses an obscure unmatched unicode property or a
> unicode block, or character class subtraction syntax).  This really doesn't
> seem hard to me.
>
> But the XML RE language has stuff in it that I don't think anyone is ever
> going to use in a standardized network management YANG model.   Forcing
> everyone to implement support for this stuff just seems like a complete
> waste of time and effort.  Looking at the regex info website it looks like
> there are about 143 unicode properties and blocks defined (it may be
> incomplete), or which I think that 135+ of these probably have no relevance
> in network management YANG modules, and the benefit of the remaining ones
> is pretty suspect.
>
> I mean, how many network management YANG modules really need a pattern
> statement that only matches Runic characters?  Perhaps someone out there is
> busy defining "middle-earth.yang" ;-)
>
> If I am the only person opposed to making life unnecessarily difficult to
> readers of YANG models, and client/server tool implementors interacting
> with YANG then it is probably time to give up this discussion. ;-)
>
> Python, quite likely a common tool for client side network management,
> also doesn't seem to have any support of unicode properties or blocks.
> Perhaps implementations will hook it up to libxml2 instead, or write a full
> translation XML RE to Python RE conversion tool.  But probably most people
> will just feed the pattern statement into the native Python regex engine,
> and my guess is that this will probably work 95% of the time.  The other 5%
> ... who knows what will happen ... oh well, better to try and fail than to
> not try at all.
>
> Apologies if this email comes across as a rant.
>
> Rob
>
>
>
>

--f403045f51a239e52e0557fe948e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,

The burden this would place on YANG=
 writers would be excessive.
We learned in SNMP-land about CLRs (=
clever little rules) and how they need
to be avoided. We learned =
that special-casing and sub-setting technology has
its own costs,=
 which are usually more than the problem they solved
(e.g., count=
er names MUST be in the plural form).


Andy



On Wed, Aug 30, 2017 at 1:03 PM, Kent Watse=
n <kwatsen@juniper.net> wrote:













=C2=A0=



As Andy says, re=
adability is #1, and it follows that a restricted subset would be more unde=
rstandable.=C2=A0 Standardizing this would require an update to RFC 7950 (r=
ead: not going to happen anytime soon).=C2=A0 Maybe
 we could start with just having a tool detect when something outside the c=
ommon-subset is used.=C2=A0 =C2=A0Can a "common subset" be well-d=
efined?=C2=A0 - "common" between how many engines? - would it be =
forever evolving?


=C2=A0=



K. // contributo=
r


=C2=A0=



=C2=A0=







On 8/30/17, 12:44 PM, "netmod on behalf of Robe=
rt Wilton" <netmod-bounces@ietf.org on behalf of
rwilton@cisco.com> wrote:








=C2=A0




I actually think that XML RE is a good choice for YA=
NG pattern statements (because it is one of the more simple RE languages), =
I just don't think that we need all of it.





First question: How many pattern statements in draft and standard IETF YANG=
 modules actually use Unicode properties (e.g \p{}).

Answer: Just 2.=C2=A0 To add a zone at the end of the IPv4/IPv6 address.


E.g. =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 pattern

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 '(([0-9]|[1-9][0-9]|1[0-9][0=
-9]|2[0-4][0-9]|25[0-5])\.){3}'

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +=C2=A0 '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 + '(%[\p{N}\p{L}]+)?';



This could quite possibly have been written just as "\d{1,3}\.{3}\d{1,=
3)(%\w+)?" and not use Unicode properties at all.



There a couple more occurrences of Unicode character classes in the vendor =
models on github, but only to restrict them to the ASCII character set (oh =
the irony), which I believe can be accomplished without resorting to Unicod=
e properties.





Another question: How often is character class subtraction (e.g. [A-Z-[PQ]]=
 used in standard & the github YANG modules?

Answer: 0.=C2=A0 AFAICT, it isn't used at all, anywhere ...







Now, I'm not proposing using a different regex syntax for pattern state=
ments, just a sensible subset of XSD RE, such that it easier for folks to r=
ead/review pattern statements, and it is easier for client and server imple=
mentations to translate into other common
 regex implementations if they so wish.



Of course, as part of that translation, I would expect a translation functi=
on to check and generate an error if the translation cannot handle the inpu=
t regex (e.g. if it uses an obscure unmatched unicode property or a unicode=
 block, or character class subtraction
 syntax).=C2=A0 This really doesn't seem hard to me.

=C2=A0

But the XML RE language has stuff in it that I don't think anyone is ev=
er going to use in a standardized network management YANG model.=C2=A0=C2=
=A0 Forcing everyone to implement support for this stuff just seems like a =
complete waste of time and effort.=C2=A0 Looking at the
 regex info website it looks like there are about 143 unicode properties an=
d blocks defined (it may be incomplete), or which I think that 135+ of thes=
e probably have no relevance in network management YANG modules, and the be=
nefit of the remaining ones is pretty
 suspect.



I mean, how many network management YANG modules really need a pattern stat=
ement that only matches Runic characters?=C2=A0 Perhaps someone out there i=
s busy defining "middle-earth.yang" ;-)



If I am the only person opposed to making life unnecessarily difficult to r=
eaders of YANG models, and client/server tool implementors interacting with=
 YANG then it is probably time to give up this discussion. ;-)



Python, quite likely a common tool for client side network management, also=
 doesn't seem to have any support of unicode properties or blocks.=C2=
=A0 Perhaps implementations will hook it up to libxml2 instead, or write a =
full translation XML RE to Python RE conversion
 tool.=C2=A0 But probably most people will just feed the pattern statement =
into the native Python regex engine, and my guess is that this will probabl=
y work 95% of the time.=C2=A0 The other 5% ... who knows what will happen .=
.. oh well, better to try and fail than to
 not try at all.



Apologies if this email comes across as a rant.



Rob








=C2=A0










--f403045f51a239e52e0557fe948e--


From nobody Wed Aug 30 18:46:10 2017
Return-Path: 
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 E0AFD1204DA for ; Wed, 30 Aug 2017 18:46:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Level: 
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 AEiFuk1uoBT0 for ; Wed, 30 Aug 2017 18:46:06 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 843D712008A for ; Wed, 30 Aug 2017 18:46:05 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DNQ26744; Thu, 31 Aug 2017 01:46:03 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 31 Aug 2017 02:46:01 +0100
Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.219]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Thu, 31 Aug 2017 09:45:49 +0800
From: "Zhengguangying (Walker)" 
To: "stefan@wallan.se" , "mbj@tail-f.com" ,  "netmod@ietf.org" 
CC: "Zhangjun (Echo, CSD)" 
Thread-Topic: =?gb2312?B?uOa+r7LdsLi1xMG9uPbOyszio6zH67ni062w78Om16q3orj41/fV39fJ0a8=?= =?gb2312?B?z8I=?=
Thread-Index: AdMhPjJcmmc5jdtSRiOSfvMqurRiVQAvIQYA
Date: Thu, 31 Aug 2017 01:45:49 +0000
Message-ID: <381D7D55085B1E4D8B581BD652E1E140C91B1D8E@nkgeml513-mbx.china.huawei.com>
References: <096E479692B7D446AFC9FF3AE53CDB558BC01F04@nkgeml513-mbx.china.huawei.com>
In-Reply-To: <096E479692B7D446AFC9FF3AE53CDB558BC01F04@nkgeml513-mbx.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.134.169.155]
Content-Type: multipart/alternative; boundary="_000_381D7D55085B1E4D8B581BD652E1E140C91B1D8Enkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59A76A5B.012A, ss=1, re=0.000, recu=0.000, reip=0.000,  cl=1, cld=1, fgs=0, ip=169.254.1.219, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 2c3b0719804ddab62e040b42417bd6b5
Archived-At: 
Subject: Re: [netmod]  =?gb2312?b?uOa+r7LdsLi1xMG9uPbOyszio6zH67ni062w78Om16o=?= =?gb2312?b?t6K4+Nf31d/XydGvz8I=?=
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Aug 2017 01:46:09 -0000

--_000_381D7D55085B1E4D8B581BD652E1E140C91B1D8Enkgeml513mbxchi_
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64

SGkgYWxsLA0KDQpJIGhhdmUgcmVhZCAgdGhlIKGwZHJhZnQtdmFsbGluLW5ldG1vZC1hbGFybS1t
b2R1bGUtMDKhsSwgd2UgaGF2ZSBzb21lIGNvbW1lbnRzIHdhbnQgdG8gZGlzY3VzcyB3aXRoIHlv
dSBhbGwsDQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXZhbGxpbi1uZXRtb2QtYWxh
cm0tbW9kdWxlLTAyLnR4dA0KDQpub3RpZmljYXRpb24gYWxhcm0tbm90aWZpY2F0aW9uIHsNCiAg
ZGVzY3JpcHRpb24NCiJUaGlzIG5vdGlmaWNhdGlvbiBpcyB1c2VkIHRvIHJlcG9ydCBhIHN0YXRl
IGNoYW5nZSBmb3IgYW4NCmFsYXJtLiBUaGUgc2FtZSBub3RpZmljYXRpb24gaXMgdXNlZCBmb3Ig
cmVwb3J0aW5nIGEgbmV3bHkNCnJhaXNlZCBhbGFybSwgYSBjbGVhcmVkIGFsYXJtIG9yIGNoYW5n
aW5nIHRoZSB0ZXh0IGFuZC9vcg0Kc2V2ZXJpdHkgb2YgYW4gZXhpc3RpbmcgYWxhcm0uIjsNCnVz
ZXMgY29tbW9uLWFsYXJtLXBhcmFtZXRlcnM7DQp1c2VzIGFsYXJtLXN0YXRlLWNoYW5nZS1wYXJh
bWV0ZXJzOw0KfQ0KDQoxLiBJbiBhbGFybS1ub3RpZmljYXRpb24sIEkgaGF2ZSBub3QgZmluZCCh
sGlzLWNsZWFyZWShsSwgaG93IHRvIGV4cHJlc3MgYWxhcm0gIGFjdGl2ZSBvciBjbGVhcmVkID8N
CjIuIFdoYXQgaXMgeW91ciBzdWdnZXN0aW9uIGZvciChsGFsYXJtIHJlYXNvbqGxIGluIGFsYXJt
LW5vdGlmaWNhdGlvbiBvciBhbGFybS1saXN0PyBJIGhhdmUgbm90IGZpbmQgaXQgaW4gdGhlIGRy
YWZ0Lg0KDQpQbGVhc2UgaGVscCB0byBjb25maXJtIHRoZXNlIGNvbW1lbnRzLCB0aGFua3MNCg0K
UmVnYXJkcw0KWmhhbmdqdW4sIFdhbGtlcg0KDQoNCiBjb21tb24tYWxhcm0tcGFyYW1ldGVycyAg
IC8vIFdpdGhvdXQgobBpcy1jbGVhcmVkobEsaG93IHRvIGV4cHJlc3MgYWxhcm0gIGFjdGl2ZSBv
ciBjbGVhcmVkID8NCiAgICByZXNvdXJjZQ0KICAgIGFsYXJtLXR5cGUtaWQNCiAgICBhbGFybS10
eXBlLXF1YWxpZmllcg0KICAgIGFsdC1yZXNvdXJjZQ0KICAgIHJlbGF0ZWQtYWxhcm0qDQogICAg
ICByZXNvdXJjZQ0KICAgICAgYWxhcm0tdHlwZS1pZA0KICAgICAgYWxhcm0tdHlwZS1xdWFsaWZp
ZXINCiAgICBpbXBhY3RlZC1yZXNvdXJjZQ0KICAgIHJvb3QtY2F1c2UtcmVzb3VyY2UqDQoNCiBh
bGFybS1zdGF0ZS1jaGFuZ2UtcGFyYW1ldGVycyAgLy8gV2l0aG91dCChsGlzLWNsZWFyZWShsSxo
b3cgdG8gZXhwcmVzcyBhbGFybSBpcyBhY3RpdmUgb3IgY2xlYXJlZCA/DQogICAgdGltZQ0KICAg
IHBlcmNlaXZlZC1zZXZlcml0eQ0KICAgIGFsYXJtLXRleHQNCg0KWmhhbmdqdW4NCndhbGtlcg0K

--_000_381D7D55085B1E4D8B581BD652E1E140C91B1D8Enkgeml513mbxchi_
Content-Type: text/html; charset="gb2312"
Content-Transfer-Encoding: quoted-printable











Hi all,


 


I have read
 the
=
=A1=B0draft-vallin-netmod-alarm-module-02=A1=B1,
 we have some comments want to discuss with you all,


 


https://www.ietf.org/id/draft-vallin-netmod-alarm-module-02.txt=



 


notification alarm-notification {


  description



"T=
his notification is used to report a state change for an<=
/p>


alarm. =
The same notification is used for reporting a newly



raised =
alarm, a cleared alarm or changing the text and/or



severit=
y of an existing alarm.";



uses common-alarm-parameters;



uses alarm-state-change-parameters;


}


 


1. In alarm-notification, I have not find =A1=B0is-clear=
ed=A1=B1, how to express alarm
 active or cleared ?<=
/o:p>


2. What is your suggestion for =A1=B0alarm reason=A1=B1 =
in alarm-notification or alarm-list? I have not find it in the draft.<=
/o:p>


 


Please help to confirm these comments, thanks


 


Regards


Zhangjun, Walker


 


 


 common-alarm-parameters
   // With=
out =A1=B0is-cleared=A1=B1,how
 to express alarm  active or cleared ?

 
  resource



 
  alarm-type-id



 
  alarm-type-qualifier



 
  alt-resource



 
  related-alarm*



 
 
  resource
 


 
 
  alarm-type-id



 
 
  alarm-type-qualifier
 



 
  impacted-resource 



 
  root-cause-resource*



 <=
/o:p>


 alarm-state-change-parameters
 // Withou=
t
=A1=B0is-cleared=A1=B1,how
 to express alarm is active or cleared ?


 
  time



 
  perceived-severity



 
  alarm-text



&n=
bsp;


Zhangju=
n


walker<=
o:p>






--_000_381D7D55085B1E4D8B581BD652E1E140C91B1D8Enkgeml513mbxchi_--


From nobody Thu Aug 31 04:48:14 2017
Return-Path: 
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 208DF132D5D for ; Thu, 31 Aug 2017 04:48:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Rdstnpc_QZ-E for ; Thu, 31 Aug 2017 04:48:09 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id C95FB132D69 for ; Thu, 31 Aug 2017 04:48:05 -0700 (PDT)
Received: by trail.lhotka.name (Postfix, from userid 109) id 14B881820E76; Thu, 31 Aug 2017 13:48:02 +0200 (CEST)
Received: from localhost (unknown [195.113.220.126]) by trail.lhotka.name (Postfix) with ESMTPSA id 1F47F1820E6E; Thu, 31 Aug 2017 13:47:58 +0200 (CEST)
From: Ladislav Lhotka 
To: Lou Berger , Per Hedeland 
Cc: netmod@ietf.org
In-Reply-To: <15e2e384bf8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
References: <7c99497f-d719-0fe2-01f5-a06d53c8fc68@labn.net> <1503929779.1715.65.camel@nic.cz> <81b138c6-9941-3313-979c-61edad7819a7@labn.net> <20170829.093743.762532630259333653.mbj@tail-f.com> <647a5ef0-968a-4eb7-322e-b3862a1252bd@labn.net> <59A565F3.5030808@tail-f.com> <15e2e384bf8.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
Mail-Followup-To: Lou Berger , Per Hedeland , netmod@ietf.org
Date: Thu, 31 Aug 2017 13:48:29 +0200
Message-ID: <87y3q0t0tu.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Aug 2017 11:48:13 -0000

Lou Berger  writes:

> On August 29, 2017 9:03:22 AM Per Hedeland  wrote:
>
>> On 2017-08-29 14:34, Lou Berger wrote:
>>> On 08/29/2017 03:37 AM, Martin Bjorklund wrote:
>>>> Lou Berger  wrote:
>>>>> Lada,
>>>>>
>>>>>
>>>>> On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
>>>>>> Lou Berger p=C3=ADae v Po 28. 08. 2017 v 09:40 -0400:
>>>>>>> Lada,
>>>>>>>
>>>>>>> On 8/28/2017 9:30 AM, Ladislav Lhotka wrote:
>>>>>>>>> Can you please take a look at it and see if we have any other dis=
connects?
>>>>>>>> This is really scary.
>>>>>>> I agree!
>>>>>>>
>>>>>>>> How can we expect poor data modellers to understand the
>>>>>>>> concept if we have such fundamental disconnects, after so many hou=
rs of
>>>>>>>> discussing it?
>>>>>>> This highlights why getting the text in (any) document is so import=
ant,
>>>>>>> and why discussions shouldn't be viewed as being closed until the i=
mpact
>>>>>>> on the text is agreed to!
>>>>>> I think many people still don't make much distinction between schema=
 mount
>>>>>> (manipulation of the schema) and data mount. I still believe we need=
 to clearly
>>>>>> separate these two concepts, preferably using two different mechanis=
ms.
>>>>>
>>>>> Frankly, I'm focused on removing blocking issues on the current WG
>>>>> deliverable, i.e., schema mount.
>>>>> ...
>>>>>>> Lou
>>>>>>>
>>>>>>> PS is your view aligned with martin or our example?
>>>>>> If you mean shifting the XPath context node to the mount point insta=
nce, then
>>>>>> yes.
>>>>>
>>>>> funny, you answered yes to a choice!  I was asking if you think the
>>>>> mount point shows up as a node in the data tree, i.e., as shown in the
>>>>> example in
>>>>> https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B.1?
>>>>>
>>>>> from my perspective and my co-authors in the RTG area using schema
>>>>> mount, we've never heard of a (filesystem) mount point that doesn't s=
how
>>>>> in the (directory) structure and this is the mental analogue we've be=
en
>>>>> assuming. Since there never was an explicit example/discussion or text
>>>>> to dissuade us of this
>>>>
>>>> The current text says:
>>>>
>>>>   A "container" or "list" node becomes a mount point if the
>>>>   "mount-point" extension (defined in the "ietf-yang-schema-mount"
>>>>   module) is used in its definition.
>>>
>>> interesting, read that a few times to (now) get the gist of your intent.
>>>
>>>>
>>>> But of course we should clarify this.
>>>>
>>>
>>>
>>>
>>>>> , this disconnect was never noticed.  Certainly
>>>>> this needs to be explicit in the document (either way). The following
>>>>> change could be made to the schema mount draft (at a minimum):
>>>>>
>>>>> OLD
>>>>>           A mount point defines a place in the node hierarchy where
>>>>>           other data models may be attached. A server that implements=
 a
>>>>> NEW
>>>>>           A mount point defines a node in a data tree under which
>>>>> instances of
>>>>>           other data models may be attached. A server that implements=
 a
>>>>
>>>> I strongly object to letting the extension define a new data node.
>>>
>>>> This would be a new type of data node that presumably look a lot like
>>>> a container,
>>>
>>> agreed, just like a mount point looks a lot like a directory in a unix
>>> file system.
>>
>> It seems to me that the schema mount concept is 100% equivalent to the
>> Unix file system analogy in this particular respect. You need a
>> pre-existing directory to mount a remote file system (or for that matter
>> a disk device). The directory gains the property of being a mount point
>> by the process of mounting, and loses it by the process of unmounting:
>>
>
> This point was at the root of the discussion of whether or not we even=20
> needed the mount Point extension at all and whether just having the schem=
e=20
> amount module identify mounts with in a container was sufficient.

I don't like this analogy very much (and, for that matter, the term
"mount" itself) because Unix mount deals with data.

>
> I believe the perspective from Lada and Martin was that it didn't really=
=20
> add value. Those of us in the routing area working on models using scheme

In fact, I think Martin was never in favour of getting rid of the extension.

> mount uniformly agreed that it was important to keep the extension to=20
> enable module designers to indicate to implementers where Mount points we=
re=20
> intended to be used in the modules they were defining and for client user=
s/=20
> implementers to reliably identify where modules would be mounted. We
> also

Without the extra data specifying what is going to be added here, the
extension itself doesn't tell you much.

YANG already has an analogy: each container and list is basically an
implicit "augment point" where external modules can place stuff. Yet we
apparently don't need any explicit indication of the augment point in
the recipient module.

So I wonder why we need it for schema mount.

> thought that the use of the mount Point extension in modules would have=20
> certain tooling benefits over just putting a comment in the description o=
f=20
> a container that it was to be used as a mount point.
>
> Yes, we can make the current node-less Mount Point extension work, but it=
=20
> certainly seems like a clumsier and more complex solution

I don't agree. The current "node-less" solution is more flexible in that
it allows you to have a container or list as the mount point.

It would be a completely different story though (and IMO the cleanest
solution) to implement the schema mount concept directly in YANG with a
specification of the mounted schema (i.e. as a design-time thing),
perhaps something like embedded grammars in RELAX NG:

http://books.xmlschemata.org/relaxng/relax-CHP-10-SECT-1.html#relax-CHP-10-=
SECT-1.3

This would however need a fairly massive redesign. We tried to avoid
changes to YANG but ended up with something that is, I am afraid, too
complex and non-intuitive.

Lada

>
> Lou
>
>
>
>
>> # mount earth:/home /foo
>> mount: /foo: No such file or directory
>> # mkdir /foo
>> # mount earth:/home /foo
>> # ls /foo
>> (... lots of user directories ...)
>> # umount /foo
>> # ls /foo
>> #
>>
>> --Per
>>
>>>> and you'd have to define all sorts of rules for this new
>>>> node (how it is encoded in XML, JSON, CBOR; how it is handled in
>>>> edit-config, how it is mapped to RESTCONF resources etc etc).
>>>
>>> I'm don't see this, the rules would be the same as a container, as in
>>> "mount points in data trees are encoded identically as containers".
>>>
>>>>
>>>> If you thought that the extension implicitly creates a node, adding an
>>>> explicit container won't do any harm; it will not change the schema
>>>> tree from what you thought it was.
>>>
>>> Well we could make this work, but it feels like every model that uses
>>> schema has added complexity to its definition and use to perhaps avoid
>>> making some minor tooling changes.  Keep in mind that any use of the
>>> mount point extension will required changes in tooling.
>>>
>>>>
>>>> But I think we should also restrict the mount-point extension so that
>>>> there cannot be more than one mount-point in a given container.
>>>>
>>> In this case, I'd go further and say that the only thing in the
>>> container (of the module schema) is the mount point and a mount point
>>> extension is only valid within a container. (Then the semantics are the
>>> same as we expected, just the syntax is different.)
>>>
>>> Lou
>>>
>>>
>>>>
>>>> /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

--=20
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Thu Aug 31 06:53:46 2017
Return-Path: 
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 07292132DA2 for ; Thu, 31 Aug 2017 06:53:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level: 
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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
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 NR4qTGn0XPpb for ; Thu, 31 Aug 2017 06:53:41 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70F19132D87 for ; Thu, 31 Aug 2017 06:53:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37409; q=dns/txt; s=iport; t=1504187620; x=1505397220; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=5+O19vIdBWcSlefbcMJSxb+WK61Qs1SJ11Ikl6PmH8A=; b=WHLaTd8Iojkpi0Y7bm++OaLse606DcL+6ubjcc4ays0+XRcnTMRvcMGy WOrfh9F3c4XLnvpAfXkdnHddAvAkby2DE3/NiNYn0jG7yxW3IhjvDq0Jw FLXzK6vS7Nxkv5ph9ADFpXOgwiiNXXTBrp8D78vriBvz0qbBYIqNGpY06 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BvAQA0FKhZ/xbLJq1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ+gRWPC5Ebd5UwDoIBAyEBCoRMTwKESxYBAgEBAQEBAQFrKIU?= =?us-ascii?q?YAQEBAQIBAQEYCUsQCQIJAg4CCCABBgMCAhsMHxEGAQwGAgEBFYoQCBCPZ51mg?= =?us-ascii?q?icnix4BAQEBAQEBAQEBAQEBAQEBAQEBAQEdBYMlg1CBYyuCSDWEQgESAQkcGya?= =?us-ascii?q?CTIJhBYoDE4h2hSWIPpRRghOJQCSGd41SiHMmCyaBAgsyIQgcFUmHHD82iBqCM?= =?us-ascii?q?gEBAQ?=
X-IronPort-AV: E=Sophos;i="5.41,453,1498521600";  d="scan'208,217";a="655331464"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2017 13:53:35 +0000
Received: from [10.63.23.66] (dhcp-ensft1-uk-vla370-10-63-23-66.cisco.com [10.63.23.66]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v7VDrZ0f005516; Thu, 31 Aug 2017 13:53:35 GMT
To: Lou Berger , Andy Bierman , Juergen Schoenwaelder , Xufeng Liu , netmod@ietf.org
References: <599F0991.7020900@tail-f.com>  <20170825125254.6nhnzkrar6fhu7zr@elstar.local>  <20170828154640.pzg7jfy5uepkb22q@elstar.local>    <20170830102902.2n5q6rgq2x2dxfq2@elstar.local>  <20170830123156.cssrg5kklpo67fie@elstar.local>   <15e34d507d0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
From: Robert Wilton 
Message-ID: 
Date: Thu, 31 Aug 2017 14:53:35 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <15e34d507d0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
Content-Type: multipart/alternative; boundary="------------D0C0CD24D03586F38C92A9C8"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Aug 2017 13:53:44 -0000

This is a multi-part message in MIME format.
--------------D0C0CD24D03586F38C92A9C8
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Lou, all

Proposed 6087bis text inline below.

On 30/08/2017 21:28, Lou Berger wrote:
>
> Rob
>
> Speaking as a contributor.
>
>
> On August 30, 2017 12:44:42 PM Robert Wilton  wrote:
>
> > Hi,
> >
> > On 30/08/2017 15:52, Andy Bierman wrote:
> >>
> >>
> >> On Wed, Aug 30, 2017 at 5:31 AM, Juergen Schoenwaelder
> >>  >> > wrote:
> >>
> >>     On Wed, Aug 30, 2017 at 12:48:19PM +0100, Robert Wilton wrote:
> >>     >
> >>     >
> >>     > On 30/08/2017 11:29, Juergen Schoenwaelder wrote:
> >>     > > On Wed, Aug 30, 2017 at 10:16:30AM +0100, Robert Wilton wrote:
> >>     > > > Hi Andy,
> >>     > > >
> >>     > > > What I am suggesting makes it easier for readers, because I
> >>     am a proponent
> >>     > > > of simpler regular expressions that are easy to read and
> >>     understand.
> >>     > > >
> >>     > > > For example, I wonder how many YANG model readers would
> >>     immediately
> >>     > > > comprehend what this pattern statement means:
> >>     > > >
> >>     > > > pattern "\p{Sc}\p{Zs}?\p{Nd}+\.\p{Nd}{2}"?
> >>     > > >
> >>     > > > Does allowing such patterns really make it easier for model
> >>     readers?
> >>     > > This is always difficult to judge but to be fair you have to
> >>     show how
> >>     > > you express _the same_ (and not a subset) with some other 
> kind of
> >>     > > regular expressions. (My understanding is that \p{Sc} is a
> >>     currency
> >>     > > symbol.)
> >>     > Yes, the expression would cover a currency amount, along with
> >>     associated
> >>     > symbol (e.g. "$200.00").
> >>     >
> >>     > If I was writing a module, I would probably use the following
> >>     pattern
> >>     > statement instead, which I think a lot more people would likely
> >>     be able to
> >>     > comprehend:
> >>     >
> >>     > pattern "[A-Z]{3}\s?\d+\.\d{2}", using the 3 letter, ISO 4217,
> >>     currency codes.  e.g. ("USD 200.00")
> >>
> >>     But that is not the same. Apples versus oranges. (I expect 
> people to
> >>     tell me that (i) currency is irrelevant and (ii) that three ASCII
> >>     letter currency acronyms are better than currency symbols 
> anyway but
> >>     this is a separate discussion I am not interested in.)
> >>
> >>     > >
> >>     > > > The proposes guidelines obviously make it easier (or at
> >>     least no harder) for
> >>     > > > tool makers.
> >>     > > >
> >>     > > > I agree that there is an minor impact to model writers, but
> >>     really only in
> >>     > > > the sense that the guidelines would be telling them not to
> >>     use the esoteric
> >>     > > > options of the XML regex syntax that they probably don't
> >>     know about anyway.
> >>     > > What is 'esoteric' largely depends on your language
> >>     environment. What
> >>     > > you are saying by 'do not use \p{}' is essentially 'do not 
> use any
> >>     > > unicode long live ASCII'.
> >>     > No, that is not my intention, i.e. I'm not suggesting banning
> >>     all use of
> >>     > \p{}, but instead limiting it to the character classes that seem
> >>     like they
> >>     > may plausibly be used in standardized YANG modules.
> >>
> >>     This is entirely subjective. And if you still allow some \p{}, 
> what is
> >>     the point of the exercise?
> >>
> >>     > I'm not trying to change what 6020/7950 defines the pattern
> >>     statement as,
> >>     > just give what I perceive as some pragmatic guidance as to what
> >>     parts of XML
> >>     > RE it makes sense to use in standardized YANG modules, making it
> >>     easier for
> >>     > readers and implementations.
> >>     >
> >>     > I think that it is fine for companies, vendors, etc to use the
> >>     full breadth
> >>     > of XML RE if they wish.
> >>
> >>     Implementations have to be prepared to handle XSD pattern if they
> >>     claim compliance to YANG 1.0 and 1.1. So all this only helps
> >>     non-compliant implementations. This may indeed be a goal - but 
> then we
> >>     should spell this out as such - this helps non-compliant
> >>     implementations (and they may still fail on the first \p{} that
> >>     you still allow).
> >>
> >>     If implementations do not implement the YANG pattern statement but
> >>     something else, then then they should ignore patterns they can't
> >>     understand and treat the pattern as if it would have been in a
> >>     description clause - i.e., leave it to humans to write the code 
> that
> >>     implements the pattern correctly. Note that YANG does not say 
> anything
> >>     how stuff is implemented.
> >>
> >>
> >>
> >> This does not work.
> >> There are 3 outcomes from the regex compiler
> >>
> >> 1) proper syntax was used and accepted; pattern matches correctly
> >> 2) improper syntax was used and accepted; pattern matches incorrectly
> >> 3) improper syntax was used and rejected; compiler error generated
> >>
> >> Case (2) is the really bad one and we have seen in in bug reports.
> >>
> >> This issue was discussed in detail for almost 2 years and the
> >> conclusion was
> >> that a YANG extension would be used to specify other pattern types than
> >> the XSD pattern mandated by the standard.
> > I actually think that XML RE is a good choice for YANG pattern
> > statements (because it is one of the more simple RE languages), I just
> > don't think that we need all of it.
> >
> >
> > First question: How many pattern statements in draft and standard IETF
> > YANG modules actually use Unicode properties (e.g \p{}).
> > Answer: Just 2.  To add a zone at the end of the IPv4/IPv6 address.
> >
> > E.g.       pattern
> > '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
> >        + '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
> >        + '(%[\p{N}\p{L}]+)?';
> >
> > This could quite possibly have been written just as
> > "\d{1,3}\.{3}\d{1,3)(%\w+)?" and not use Unicode properties at all.
> >
> > There a couple more occurrences of Unicode character classes in the
> > vendor models on github, but only to restrict them to the ASCII
> > character set (oh the irony), which I believe can be accomplished
> > without resorting to Unicode properties.
> >
> >
> > Another question: How often is character class subtraction (e.g.
> > [A-Z-[PQ]] used in standard & the github YANG modules?
> > Answer: 0.  AFAICT, it isn't used at all, anywhere ...
> >
> >
> >
> > Now, I'm not proposing using a different regex syntax for pattern
> > statements, just a sensible subset of XSD RE, such that it easier for
> > folks to read/review pattern statements, and it is easier for client 
> and
> > server implementations to translate into other common regex
> > implementations if they so wish.
> >
> > Of course, as part of that translation, I would expect a translation
> > function to check and generate an error if the translation cannot 
> handle
> > the input regex (e.g. if it uses an obscure unmatched unicode property
> > or a unicode block, or character class subtraction syntax).  This 
> really
> > doesn't seem hard to me.
> >
> > But the XML RE language has stuff in it that I don't think anyone is
> > ever going to use in a standardized network management YANG model.
> > Forcing everyone to implement support for this stuff just seems like a
> > complete waste of time and effort.  Looking at the regex info 
> website it
> > looks like there are about 143 unicode properties and blocks defined 
> (it
> > may be incomplete), or which I think that 135+ of these probably 
> have no
> > relevance in network management YANG modules, and the benefit of the
> > remaining ones is pretty suspect.
> >
> > I mean, how many network management YANG modules really need a pattern
> > statement that only matches Runic characters?  Perhaps someone out 
> there
> > is busy defining "middle-earth.yang" ;-)
> >
> > If I am the only person opposed to making life unnecessarily difficult
> > to readers of YANG models, and client/server tool implementors
> > interacting with YANG then it is probably time to give up this
> > discussion. ;-)
> >
>
> I agree with you 100%
>
> And I see Xufeng's proposal for 6087bis as an attempt at putting some 
> language together to support this desire. Perhaps you can suggest 
> alternate language.
>
I propose adding the following 2 paragraphs to 6087bis section on 
pattern and ranges:

NEW:
To ensure patterns are easy to read and implement, authors SHOULD
restrict themselves to the parts of the XML schema regular expression
language that are common across most regular expression languages.  In
particular, pattern statements SHOULD avoid using 'character class
subtraction' (e.g. '[a-z-[aeiou]]').  They SHOULD avoid matching
unicode properties and blocks (e.g. '\p{L} or \p{IsBasic_Latin}').
They MAY use the '\d', '\w', '\s' character class shorthands and their
negated versions, where appropriate, but SHOULD avoid other character
class shorthands.  To match ASCII digits 0-9 the character class
'[0-9]' MUST be used instead of the '\d' character class shorthand
that matches Unicode digits in all scripts.

Pattern statements do not have to strictly restrict numerical values,
and a simple less specific pattern may be preferable over a more
complex and precise pattern, e.g. as illustrated in the
'ipv4-address-no-zone' example pattern below.


Or, in context of the existing text 6087bis text:

*** Patterns and Ranges

For string data types, if a machine-readable pattern
can be defined for the desired semantics, then
one or more pattern statements SHOULD be present.
A single quoted string SHOULD be used to specify the pattern,
since a double-quoted string can modify the content.

To ensure patterns are easy to read and implement, authors SHOULD
restrict themselves to the parts of the XML schema regular expression
language that are common across most regular expression languages.  In
particular, pattern statements SHOULD avoid using 'character class
subtraction' (e.g. '[a-z-[aeiou]]').  They SHOULD avoid matching
unicode properties and blocks (e.g. '\p{L} or \p{IsBasic_Latin}').
They MAY use the '\d', '\w', '\s' character class shorthands and their
negated versions, where appropriate, but SHOULD avoid other character
class shorthands.  To match ASCII digits 0-9 the character class
'[0-9]' MUST be used instead of the '\d' character class shorthand
that also matches Unicode digits in all scripts.

Pattern statements do not have to strictly restrict numerical values,
and a simple less specific pattern may be preferable over a more
complex and precise pattern, e.g. as illustrated in the
'ipv4-address-no-zone' example pattern below.

The following typedef from ^RFC6991^ demonstrates the proper
use of the "pattern" statement:

     typedef ipv4-address-no-zone {
       type inet:ipv4-address {
         pattern '[0-9\.]*';
       }
       ...
     }

For string data types, if the length of the string
is required to be bounded in all implementations,
then a length statement MUST be present.

The following typedef from ^RFC6991^ demonstrates the proper
use of the "length" statement:

     typedef yang-identifier {
       type string {
         length "1..max";
         pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
         pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*';
       }
       ...
     }

For numeric data types, if the values allowed
by the intended semantics are different than
those allowed by the unbounded intrinsic data
type (e.g., 'int32'), then a range statement SHOULD be present.

The following typedef from ^RFC6991^ demonstrates the proper
use of the "range" statement:

     typedef dscp {
       type uint8 {
          range "0..63";
       }
       ...
     }

Thanks,
Rob


> Lou
>
>
> > Python, quite likely a common tool for client side network management,
> > also doesn't seem to have any support of unicode properties or blocks.
> > Perhaps implementations will hook it up to libxml2 instead, or write a
> > full translation XML RE to Python RE conversion tool. But probably most
> > people will just feed the pattern statement into the native Python 
> regex
> > engine, and my guess is that this will probably work 95% of the time.
> > The other 5% ... who knows what will happen ... oh well, better to try
> > and fail than to not try at all.
> >
> > Apologies if this email comes across as a rant.
> >
> > Rob
> >
> >
> >>
> >>
> >>     /js
> >>
> >>
> >> Andy
> >>
> >>     --
> >>     Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >>     Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | 
> Germany
> >>     Fax:   +49 421 200 3103          >>     >
> >>
> >>
> >
> >
> >
> >
> > ----------
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>


--------------D0C0CD24D03586F38C92A9C8
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Lou, all

    

    Proposed 6087bis text inline below.

    

    
On 30/08/2017 21:28, Lou Berger wrote:

    

    

      
      

        
Rob

        
Speaking as a
          contributor.

        


        

        
On
          August 30, 2017 12:44:42 PM Robert Wilton
          <rwilton@cisco.com> wrote:

        
>
          Hi,

          >

          > On 30/08/2017 15:52, Andy Bierman wrote:

          >>

          >>

          >> On Wed, Aug 30, 2017 at 5:31 AM, Juergen
          Schoenwaelder 

          >> <j.schoenwaelder@jacobs-university.de 

          >>
          <mailto:j.schoenwaelder@jacobs-university.de>> wrote:

          >>

          >>     On Wed, Aug 30, 2017 at 12:48:19PM +0100,
          Robert Wilton wrote:

          >>     >

          >>     >

          >>     > On 30/08/2017 11:29, Juergen
          Schoenwaelder wrote:

          >>     > > On Wed, Aug 30, 2017 at
          10:16:30AM +0100, Robert Wilton wrote:

          >>     > > > Hi Andy,

          >>     > > >

          >>     > > > What I am suggesting makes
          it easier for readers, because I

          >>     am a proponent

          >>     > > > of simpler regular
          expressions that are easy to read and

          >>     understand.

          >>     > > >

          >>     > > > For example, I wonder how
          many YANG model readers would

          >>     immediately

          >>     > > > comprehend what this
          pattern statement means:

          >>     > > >

          >>     > > > pattern
          "\p{Sc}\p{Zs}?\p{Nd}+\.\p{Nd}{2}"?

          >>     > > >

          >>     > > > Does allowing such patterns
          really make it easier for model

          >>     readers?

          >>     > > This is always difficult to
          judge but to be fair you have to

          >>     show how

          >>     > > you express _the same_ (and not
          a subset) with some other kind of

          >>     > > regular expressions. (My
          understanding is that \p{Sc} is a

          >>     currency

          >>     > > symbol.)

          >>     > Yes, the expression would cover a
          currency amount, along with

          >>     associated

          >>     > symbol (e.g. "$200.00").

          >>     >

          >>     > If I was writing a module, I would
          probably use the following

          >>     pattern

          >>     > statement instead, which I think a
          lot more people would likely

          >>     be able to

          >>     > comprehend:

          >>     >

          >>     > pattern "[A-Z]{3}\s?\d+\.\d{2}",
          using the 3 letter, ISO 4217,

          >>     currency codes.  e.g. ("USD 200.00")

          >>

          >>     But that is not the same. Apples versus
          oranges. (I expect people to

          >>     tell me that (i) currency is irrelevant
          and (ii) that three ASCII

          >>     letter currency acronyms are better than
          currency symbols anyway but

          >>     this is a separate discussion I am not
          interested in.)

          >>

          >>     > >

          >>     > > > The proposes guidelines
          obviously make it easier (or at

          >>     least no harder) for

          >>     > > > tool makers.

          >>     > > >

          >>     > > > I agree that there is an
          minor impact to model writers, but

          >>     really only in

          >>     > > > the sense that the
          guidelines would be telling them not to

          >>     use the esoteric

          >>     > > > options of the XML regex
          syntax that they probably don't

          >>     know about anyway.

          >>     > > What is 'esoteric' largely
          depends on your language

          >>     environment. What

          >>     > > you are saying by 'do not use
          \p{}' is essentially 'do not use any

          >>     > > unicode long live ASCII'.

          >>     > No, that is not my intention, i.e.
          I'm not suggesting banning

          >>     all use of

          >>     > \p{}, but instead limiting it to the
          character classes that seem

          >>     like they

          >>     > may plausibly be used in standardized
          YANG modules.

          >>

          >>     This is entirely subjective. And if you
          still allow some \p{}, what is

          >>     the point of the exercise?

          >>

          >>     > I'm not trying to change what
          6020/7950 defines the pattern

          >>     statement as,

          >>     > just give what I perceive as some
          pragmatic guidance as to what

          >>     parts of XML

          >>     > RE it makes sense to use in
          standardized YANG modules, making it

          >>     easier for

          >>     > readers and implementations.

          >>     >

          >>     > I think that it is fine for
          companies, vendors, etc to use the

          >>     full breadth

          >>     > of XML RE if they wish.

          >>

          >>     Implementations have to be prepared to
          handle XSD pattern if they

          >>     claim compliance to YANG 1.0 and 1.1. So
          all this only helps

          >>     non-compliant implementations. This may
          indeed be a goal - but then we

          >>     should spell this out as such - this helps
          non-compliant

          >>     implementations (and they may still fail
          on the first \p{} that

          >>     you still allow).

          >>

          >>     If implementations do not implement the
          YANG pattern statement but

          >>     something else, then then they should
          ignore patterns they can't

          >>     understand and treat the pattern as if it
          would have been in a

          >>     description clause - i.e., leave it to
          humans to write the code that

          >>     implements the pattern correctly. Note
          that YANG does not say anything

          >>     how stuff is implemented.

          >>

          >>

          >>

          >> This does not work.

          >> There are 3 outcomes from the regex compiler

          >>

          >> 1) proper syntax was used and accepted; pattern
          matches correctly

          >> 2) improper syntax was used and accepted; pattern
          matches
          incorrectly

          >> 3) improper syntax was used and rejected; compiler
          error generated

          >>

          >> Case (2) is the really bad one and we have seen in in
          bug reports.

          >>

          >> This issue was discussed in detail for almost 2 years
          and the 

          >> conclusion was

          >> that a YANG extension would be used to specify other
          pattern types
          than

          >> the XSD pattern mandated by the standard.

          > I actually think that XML RE is a good choice for YANG
          pattern 

          > statements (because it is one of the more simple RE
          languages), I just
          

          > don't think that we need all of it.

          >

          >

          > First question: How many pattern statements in draft and
          standard IETF
          

          > YANG modules actually use Unicode properties (e.g \p{}).

          > Answer: Just 2.  To add a zone at the end of the
          IPv4/IPv6 address.

          >

          > E.g.       pattern

          >         
          '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'

          >        + 
          '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'

          >        + '(%[\p{N}\p{L}]+)?';

          >

          > This could quite possibly have been written just as 

          > "\d{1,3}\.{3}\d{1,3)(%\w+)?" and not use Unicode
          properties at all.

          >

          > There a couple more occurrences of Unicode character
          classes in the 

          > vendor models on github, but only to restrict them to the
          ASCII 

          > character set (oh the irony), which I believe can be
          accomplished 

          > without resorting to Unicode properties.

          >

          >

          > Another question: How often is character class
          subtraction (e.g. 

          > [A-Z-[PQ]] used in standard & the github YANG
          modules?

          > Answer: 0.  AFAICT, it isn't used at all, anywhere ...

          >

          >

          >

          > Now, I'm not proposing using a different regex syntax for
          pattern 

          > statements, just a sensible subset of XSD RE, such that
          it easier for 

          > folks to read/review pattern statements, and it is easier
          for client
          and 

          > server implementations to translate into other common
          regex 

          > implementations if they so wish.

          >

          > Of course, as part of that translation, I would expect a
          translation 

          > function to check and generate an error if the
          translation cannot
          handle 

          > the input regex (e.g. if it uses an obscure unmatched
          unicode property
          

          > or a unicode block, or character class subtraction
          syntax).  This
          really 

          > doesn't seem hard to me.

          >

          > But the XML RE language has stuff in it that I don't
          think anyone is 

          > ever going to use in a standardized network management
          YANG model. 

          > Forcing everyone to implement support for this stuff just
          seems like a
          

          > complete waste of time and effort.  Looking at the regex
          info website
          it 

          > looks like there are about 143 unicode properties and
          blocks defined
          (it 

          > may be incomplete), or which I think that 135+ of these
          probably have
          no 

          > relevance in network management YANG modules, and the
          benefit of the 

          > remaining ones is pretty suspect.

          >

          > I mean, how many network management YANG modules really
          need a pattern
          

          > statement that only matches Runic characters?  Perhaps
          someone out
          there 

          > is busy defining "middle-earth.yang" ;-)

          >

          > If I am the only person opposed to making life
          unnecessarily difficult
          

          > to readers of YANG models, and client/server tool
          implementors 

          > interacting with YANG then it is probably time to give up
          this 

          > discussion. ;-)

          >

        
I agree with you
          100%

        
And I see Xufeng's
          proposal for
          6087bis as an attempt at putting some language together to
          support this
          desire. Perhaps you can suggest alternate language.

      

    

    I propose adding the following 2 paragraphs to 6087bis section on
    pattern and ranges:

    

    NEW:

    To ensure patterns are easy to read and implement, authors
      SHOULD

    restrict themselves to the parts of the XML schema regular
      expression

    language that are common across most regular expression
      languages.  In

    particular, pattern statements SHOULD avoid using
      'character class

    subtraction' (e.g. '[a-z-[aeiou]]').  They SHOULD avoid
      matching

    unicode properties and blocks (e.g. '\p{L} or
      \p{IsBasic_Latin}').

    They MAY use the '\d', '\w', '\s' character class
      shorthands and their

    negated versions, where appropriate, but SHOULD avoid other
      character

    class shorthands.  To match ASCII digits 0-9 the character
      class

    '[0-9]' MUST be used instead of the '\d' character class
      shorthand

    that matches Unicode digits in all scripts.

    

    Pattern statements do not have to strictly restrict
      numerical values,

    and a simple less specific pattern may be preferable over a
      more

    complex and precise pattern, e.g. as illustrated in the

    'ipv4-address-no-zone' example pattern below.

    

    

    Or, in context of the existing text 6087bis text:

    

    *** Patterns and Ranges

    

    For string data types, if a machine-readable pattern

    can be defined for the desired semantics, then

    one or more pattern statements SHOULD be present.

    A single quoted string SHOULD be used to specify the
      pattern,

    since a double-quoted string can modify the content.

    

    To ensure patterns are easy to read and implement, authors
      SHOULD

    restrict themselves to the parts of the XML schema regular
      expression

    language that are common across most regular expression
      languages.  In

    particular, pattern statements SHOULD avoid using
      'character class

    subtraction' (e.g. '[a-z-[aeiou]]').  They SHOULD avoid
      matching

    unicode properties and blocks (e.g. '\p{L} or
      \p{IsBasic_Latin}').

    They MAY use the '\d', '\w', '\s' character class
      shorthands and their

    negated versions, where appropriate, but SHOULD avoid other
      character

    class shorthands.  To match ASCII digits 0-9 the character
      class

    '[0-9]' MUST be used instead of the '\d' character class
      shorthand

    that also matches Unicode digits in all scripts.

    

    Pattern statements do not have to strictly restrict
      numerical values,

    and a simple less specific pattern may be preferable over a
      more

    complex and precise pattern, e.g. as illustrated in the

    'ipv4-address-no-zone' example pattern below.

    

    The following typedef from ^RFC6991^ demonstrates the
      proper

    use of the "pattern" statement:

    

        typedef ipv4-address-no-zone {

          type inet:ipv4-address {

            pattern '[0-9\.]*';

          }

          ...

        }

    

    For string data types, if the length of the string

    is required to be bounded in all implementations,

    then a length statement MUST be present.

    

    The following typedef from ^RFC6991^ demonstrates the
      proper

    use of the "length" statement:

    

        typedef yang-identifier {

          type string {

            length "1..max";

            pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';

            pattern '.|..|[^xX].*|.[^mM].*|..[^lL].*';

          }

          ...

        }

    

    For numeric data types, if the values allowed

    by the intended semantics are different than

    those allowed by the unbounded intrinsic data

    type (e.g., 'int32'), then a range statement SHOULD be
      present.

    

    The following typedef from ^RFC6991^ demonstrates the
      proper

    use of the "range" statement:

    

        typedef dscp {

          type uint8 {

             range "0..63";

          }

          ...

        }

    

    Thanks,

    Rob

    

    

    

      

        
Lou 

        

        


          > Python, quite likely a common tool for client side
          network management,
          

          > also doesn't seem to have any support of unicode
          properties or
          blocks.  

          > Perhaps implementations will hook it up to libxml2
          instead, or write a
          

          > full translation XML RE to Python RE conversion tool. 
          But probably
          most 

          > people will just feed the pattern statement into the
          native Python
          regex 

          > engine, and my guess is that this will probably work 95%
          of the time. 
          

          > The other 5% ... who knows what will happen ... oh well,
          better to try
          

          > and fail than to not try at all.

          >

          > Apologies if this email comes across as a rant.

          >

          > Rob

          >

          >

          >>

          >>

          >>     /js

          >>

          >>

          >> Andy

          >>

          >>     --

          >>     Juergen Schoenwaelder           Jacobs
          University Bremen gGmbH

          >>     Phone: +49 421 200 3587         Campus
          Ring 1 | 28759 Bremen | Germany

          >>     Fax:   +49 421 200 3103         <http://www.jacobs-university.de/

          >>     <http://www.jacobs-university.de/>>

          >>

          >>

          >

          >

          >

          >

          > ----------

          > _______________________________________________

          > netmod mailing list

          > netmod@ietf.org

          > https://www.ietf.org/mailman/listinfo/netmod

          >

        

      

    

    

  


--------------D0C0CD24D03586F38C92A9C8--


From nobody Thu Aug 31 16:57:41 2017
Return-Path: 
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 D1DBA13307F for ; Thu, 31 Aug 2017 16:57:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 Nm8koVpJNufD for ; Thu, 31 Aug 2017 16:57:36 -0700 (PDT)
Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E62E133056 for ; Thu, 31 Aug 2017 16:57:36 -0700 (PDT)
From: Alex Campbell 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] Potential additions to rfc6087bis: RegEx guidelines
Thread-Index: AdMcU4SqqeTEr3DWR4ygcD75zJMNgAAhqHwAAAKnWIAAEce1gAAC0wGAACizCwAAAHCnAACXFjOAAAXbNQAAL4LGgAADyxwAACOm9gAAAoh/AAACxNqAAAGF9gAABORxgAAD6VyAADKKfzw=
Date: Thu, 31 Aug 2017 23:57:34 +0000
Message-ID: <1504223854014.55228@Aviatnet.com>
References: <599F0991.7020900@tail-f.com>  <20170825125254.6nhnzkrar6fhu7zr@elstar.local>  <20170828154640.pzg7jfy5uepkb22q@elstar.local>    <20170830102902.2n5q6rgq2x2dxfq2@elstar.local>  <20170830123156.cssrg5kklpo67fie@elstar.local> , 
In-Reply-To: 
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.10]
Content-Type: multipart/alternative; boundary="_000_150422385401455228Aviatnetcom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 Aug 2017 23:57:40 -0000

--_000_150422385401455228Aviatnetcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,


I'd be very wary of adding guidelines that restrict the regex syntax.


A tool that supports YANG must implement the full regex language anyway (or=
 ignore regexes altogether if they are not relevant to the tool's function)=
. However, these guidelines will inevitably encourage some tool authors to =
take shortcuts.


I'm sure there are already tools that take shortcuts - but if the shortcuts=
 cause problems, right now it's squarely the tool's fault, rather than the =
model being processed.

If there are official guidelines saying not to use such-and-such regex feat=
ure, then the tool author can point to the guideline and say "See? You aren=
't supposed to be using that".


We may end up with a compatibility nightmare on our hands where certain mod=
ules are only compatible with certain tools, even more-so than is the case =
now.


The only way I'd ever approve of this is if it was a MUST requirement in a =
new version of YANG.



________________________________
From: netmod  on behalf of Robert Wilton 
Sent: Thursday, 31 August 2017 4:44 a.m.
To: Andy Bierman; Juergen Schoenwaelder; Xufeng Liu; netmod@ietf.org
Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guidelines


Hi,

On 30/08/2017 15:52, Andy Bierman wrote:


On Wed, Aug 30, 2017 at 5:31 AM, Juergen Schoenwaelder > wrote:
On Wed, Aug 30, 2017 at 12:48:19PM +0100, Robert Wilton wrote:
>
>
> On 30/08/2017 11:29, Juergen Schoenwaelder wrote:
> > On Wed, Aug 30, 2017 at 10:16:30AM +0100, Robert Wilton wrote:
> > > Hi Andy,
> > >
> > > What I am suggesting makes it easier for readers, because I am a prop=
onent
> > > of simpler regular expressions that are easy to read and understand.
> > >
> > > For example, I wonder how many YANG model readers would immediately
> > > comprehend what this pattern statement means:
> > >
> > > pattern "\p{Sc}\p{Zs}?\p{Nd}+\.\p{Nd}{2}"?
> > >
> > > Does allowing such patterns really make it easier for model readers?
> > This is always difficult to judge but to be fair you have to show how
> > you express _the same_ (and not a subset) with some other kind of
> > regular expressions. (My understanding is that \p{Sc} is a currency
> > symbol.)
> Yes, the expression would cover a currency amount, along with associated
> symbol (e.g. "$200.00").
>
> If I was writing a module, I would probably use the following pattern
> statement instead, which I think a lot more people would likely be able t=
o
> comprehend:
>
> pattern "[A-Z]{3}\s?\d+\.\d{2}", using the 3 letter, ISO 4217, currency c=
odes.  e.g. ("USD 200.00")

But that is not the same. Apples versus oranges. (I expect people to
tell me that (i) currency is irrelevant and (ii) that three ASCII
letter currency acronyms are better than currency symbols anyway but
this is a separate discussion I am not interested in.)

> >
> > > The proposes guidelines obviously make it easier (or at least no hard=
er) for
> > > tool makers.
> > >
> > > I agree that there is an minor impact to model writers, but really on=
ly in
> > > the sense that the guidelines would be telling them not to use the es=
oteric
> > > options of the XML regex syntax that they probably don't know about a=
nyway.
> > What is 'esoteric' largely depends on your language environment. What
> > you are saying by 'do not use \p{}' is essentially 'do not use any
> > unicode long live ASCII'.
> No, that is not my intention, i.e. I'm not suggesting banning all use of
> \p{}, but instead limiting it to the character classes that seem like the=
y
> may plausibly be used in standardized YANG modules.

This is entirely subjective. And if you still allow some \p{}, what is
the point of the exercise?

> I'm not trying to change what 6020/7950 defines the pattern statement as,
> just give what I perceive as some pragmatic guidance as to what parts of =
XML
> RE it makes sense to use in standardized YANG modules, making it easier f=
or
> readers and implementations.
>
> I think that it is fine for companies, vendors, etc to use the full bread=
th
> of XML RE if they wish.

Implementations have to be prepared to handle XSD pattern if they
claim compliance to YANG 1.0 and 1.1. So all this only helps
non-compliant implementations. This may indeed be a goal - but then we
should spell this out as such - this helps non-compliant
implementations (and they may still fail on the first \p{} that
you still allow).

If implementations do not implement the YANG pattern statement but
something else, then then they should ignore patterns they can't
understand and treat the pattern as if it would have been in a
description clause - i.e., leave it to humans to write the code that
implements the pattern correctly. Note that YANG does not say anything
how stuff is implemented.


This does not work.
There are 3 outcomes from the regex compiler

1) proper syntax was used and accepted; pattern matches correctly
2) improper syntax was used and accepted; pattern matches incorrectly
3) improper syntax was used and rejected; compiler error generated

Case (2) is the really bad one and we have seen in in bug reports.

This issue was discussed in detail for almost 2 years and the conclusion wa=
s
that a YANG extension would be used to specify other pattern types than
the XSD pattern mandated by the standard.
I actually think that XML RE is a good choice for YANG pattern statements (=
because it is one of the more simple RE languages), I just don't think that=
 we need all of it.


First question: How many pattern statements in draft and standard IETF YANG=
 modules actually use Unicode properties (e.g \p{}).
Answer: Just 2.  To add a zone at the end of the IPv4/IPv6 address.

E.g.       pattern
        '(([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])\.){3}'
      +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5])'
      + '(%[\p{N}\p{L}]+)?';

This could quite possibly have been written just as "\d{1,3}\.{3}\d{1,3)(%\=
w+)?" and not use Unicode properties at all.

There a couple more occurrences of Unicode character classes in the vendor =
models on github, but only to restrict them to the ASCII character set (oh =
the irony), which I believe can be accomplished without resorting to Unicod=
e properties.


Another question: How often is character class subtraction (e.g. [A-Z-[PQ]]=
 used in standard & the github YANG modules?
Answer: 0.  AFAICT, it isn't used at all, anywhere ...



Now, I'm not proposing using a different regex syntax for pattern statement=
s, just a sensible subset of XSD RE, such that it easier for folks to read/=
review pattern statements, and it is easier for client and server implement=
ations to translate into other common regex implementations if they so wish=
.

Of course, as part of that translation, I would expect a translation functi=
on to check and generate an error if the translation cannot handle the inpu=
t regex (e.g. if it uses an obscure unmatched unicode property or a unicode=
 block, or character class subtraction syntax).  This really doesn't seem h=
ard to me.

But the XML RE language has stuff in it that I don't think anyone is ever g=
oing to use in a standardized network management YANG model.   Forcing ever=
yone to implement support for this stuff just seems like a complete waste o=
f time and effort.  Looking at the regex info website it looks like there a=
re about 143 unicode properties and blocks defined (it may be incomplete), =
or which I think that 135+ of these probably have no relevance in network m=
anagement YANG modules, and the benefit of the remaining ones is pretty sus=
pect.

I mean, how many network management YANG modules really need a pattern stat=
ement that only matches Runic characters?  Perhaps someone out there is bus=
y defining "middle-earth.yang" ;-)

If I am the only person opposed to making life unnecessarily difficult to r=
eaders of YANG models, and client/server tool implementors interacting with=
 YANG then it is probably time to give up this discussion. ;-)

Python, quite likely a common tool for client side network management, also=
 doesn't seem to have any support of unicode properties or blocks.  Perhaps=
 implementations will hook it up to libxml2 instead, or write a full transl=
ation XML RE to Python RE conversion tool.  But probably most people will j=
ust feed the pattern statement into the native Python regex engine, and my =
guess is that this will probably work 95% of the time.  The other 5% ... wh=
o knows what will happen ... oh well, better to try and fail than to not tr=
y at all.

Apologies if this email comes across as a rant.

Rob




/js


Andy

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         



--_000_150422385401455228Aviatnetcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








Hi,







I'd be very wary of adding guidelines that restrict the regex syntax.






A tool that supports YANG must implement the full regex language anyway =
(or ignore regexes altogether if they are not relevant to the tool's functi=
on). However, these guidelines will inevitably encourage some tool authors =
to take shortcuts.







I'm sure there are already tools that take shortcuts - but if the s=
hortcuts cause problems, right now it's squarely the tool's fault, rather t=
han the model being processed.


If there are official guidelines saying not to use such-and-such regex f=
eature, then the tool author can point to the guideline and say "See? =
You aren't supposed to be using that".







We may end up with a compatibility nightmare on our hands where certain =
modules are only compatible with certain tools, even more-so than is the ca=
se now.









The only way I'd ever approve of this is if it was a MUST requirement in=
 a new version of YANG.
















From: netmod <netmod-bo=
unces@ietf.org> on behalf of Robert Wilton <rwilton@cisco.com>

Sent: Thursday, 31 August 2017 4:44 a.m.

To: Andy Bierman; Juergen Schoenwaelder; Xufeng Liu; netmod@ietf.org=


Subject: Re: [netmod] Potential additions to rfc6087bis: RegEx guide=
lines

 






Hi,




On 30/08/2017 15:52, Andy Bierman wrote:












On Wed, Aug 30, 2017 at 5:31 AM, Juergen Schoenw=
aelder 
<j.schoenwaelder@jacobs-university.de> wrote:



On Wed, Aug 30, 2017 at 12:48:19PM +0100, Robert Wilton wrote:

>

>

> On 30/08/2017 11:29, Juergen Schoenwaelder wrote:

> > On Wed, Aug 30, 2017 at 10:16:30AM +0100, Robert Wilton wrote=
:

> > > Hi Andy,

> > >

> > > What I am suggesting makes it easier for readers, because I =
am a proponent

> > > of simpler regular expressions that are easy to read and und=
erstand.

> > >

> > > For example, I wonder how many YANG model readers would imme=
diately

> > > comprehend what this pattern statement means:

> > >

> > > pattern "\p{Sc}\p{Zs}?\p{Nd}+\.\p{Nd}{2}"=
?

> > >

> > > Does allowing such patterns really make it easier for model =
readers?

> > This is always difficult to judge but to be fair you have to show=
 how

> > you express _the same_ (and not a subset) with some other kind of=


> > regular expressions. (My understanding is that \p{Sc} is a curren=
cy

> > symbol.)

> Yes, the expression would cover a currency amount, along with associat=
ed

> symbol (e.g. "$200.00").

>

> If I was writing a module, I would probably use the following pattern<=
br>
> statement instead, which I think a lot more people would likely be abl=
e to

> comprehend:

>

> pattern "[A-Z]{3}\s?\d+\.\d{2}", using the 3 letter, ISO=
 4217, currency codes.  e.g. ("USD 200.00")



But that is not the same. Apples versus oranges. (I expect people to

tell me that (i) currency is irrelevant and (ii) that three ASCII

letter currency acronyms are better than currency symbols anyway but

this is a separate discussion I am not interested in.)



> >

> > > The proposes guidelines obviously make it easier (or at leas=
t no harder) for

> > > tool makers.

> > >

> > > I agree that there is an minor impact to model writers, but =
really only in

> > > the sense that the guidelines would be telling them not to u=
se the esoteric

> > > options of the XML regex syntax that they probably don't kno=
w about anyway.

> > What is 'esoteric' largely depends on your language environment. =
What

> > you are saying by 'do not use \p{}' is essentially 'do not use an=
y

> > unicode long live ASCII'.

> No, that is not my intention, i.e. I'm not suggesting banning all use =
of

> \p{}, but instead limiting it to the character classes that seem like =
they

> may plausibly be used in standardized YANG modules.



This is entirely subjective. And if you still allow some \p{}, what is

the point of the exercise?



> I'm not trying to change what 6020/7950 defines the pattern statement =
as,

> just give what I perceive as some pragmatic guidance as to what parts =
of XML

> RE it makes sense to use in standardized YANG modules, making it easie=
r for

> readers and implementations.

>

> I think that it is fine for companies, vendors, etc to use the full br=
eadth

> of XML RE if they wish.



Implementations have to be prepared to handle XSD pattern if they

claim compliance to YANG 1.0 and 1.1. So all this only helps

non-compliant implementations. This may indeed be a goal - but then we

should spell this out as such - this helps non-compliant

implementations (and they may still fail on the first \p{} that

you still allow).



If implementations do not implement the YANG pattern statement but

something else, then then they should ignore patterns they can't

understand and treat the pattern as if it would have been in a

description clause - i.e., leave it to humans to write the code that

implements the pattern correctly. Note that YANG does not say anything

how stuff is implemented.














This does not work.


















There are 3 outcomes from the regex compiler







1) proper syntax was used and accepted; pattern matches correctly

2) improper syntax was used and accepted; pattern matches incorrectly<=
/div>



3) improper syntax was used and rejected; compiler error generated








Case (2) is the really bad one and we have seen in in bug reports.






This issue was discussed in detail for almost 2 years and the conclusi=
on was


that a YANG extension would be used to specify other pattern types tha=
n


the XSD pattern mandated by the standard. 











I actually think that XML RE is a good choice for YANG pattern statements (=
because it is one of the more simple RE languages), I just don't think that=
 we need all of it.





First question: How many pattern statements in draft and standard IETF YANG=
 modules actually use Unicode properties (e.g \p{}).

Answer: Just 2.  To add a zone at the end of the IPv4/IPv6 address.


E.g.       pattern

        '(([0-9]|[1-9][0-9]|1[0-9][0-9]|=
2[0-4][0-9]|25[0-5])\.){3}'

      +  '([0-9]|[1-9][0-9]|1[0-9][0-9]|2=
[0-4][0-9]|25[0-5])'

      + '(%[\p{N}\p{L}]+)?';



This could quite possibly have been written just as "\d{1,3}\.{3}\d{1,=
3)(%\w+)?" and not use Unicode properties at all.



There a couple more occurrences of Unicode character classes in the vendor =
models on github, but only to restrict them to the ASCII character set (oh =
the irony), which I believe can be accomplished without resorting to Unicod=
e properties.





Another question: How often is character class subtraction (e.g. [A-Z-[PQ]]=
 used in standard & the github YANG modules?

Answer: 0.  AFAICT, it isn't used at all, anywhere ...







Now, I'm not proposing using a different regex syntax for pattern statement=
s, just a sensible subset of XSD RE, such that it easier for folks to read/=
review pattern statements, and it is easier for client and server implement=
ations to translate into other common
 regex implementations if they so wish.



Of course, as part of that translation, I would expect a translation functi=
on to check and generate an error if the translation cannot handle the inpu=
t regex (e.g. if it uses an obscure unmatched unicode property or a unicode=
 block, or character class subtraction
 syntax).  This really doesn't seem hard to me.

 

But the XML RE language has stuff in it that I don't think anyone is ever g=
oing to use in a standardized network management YANG model.   Fo=
rcing everyone to implement support for this stuff just seems like a comple=
te waste of time and effort.  Looking at the
 regex info website it looks like there are about 143 unicode properties an=
d blocks defined (it may be incomplete), or which I think that 135+ of =
these probably have no relevance in network management YANG modules, and th=
e benefit of the remaining ones is pretty
 suspect.



I mean, how many network management YANG modules really need a pattern stat=
ement that only matches Runic characters?  Perhaps someone out there i=
s busy defining "middle-earth.yang" ;-)



If I am the only person opposed to making life unnecessarily difficult to r=
eaders of YANG models, and client/server tool implementors interacting with=
 YANG then it is probably time to give up this discussion. ;-)



Python, quite likely a common tool for client side network management, also=
 doesn't seem to have any support of unicode properties or blocks.  Pe=
rhaps implementations will hook it up to libxml2 instead, or write a full t=
ranslation XML RE to Python RE conversion
 tool.  But probably most people will just feed the pattern statement =
into the native Python regex engine, and my guess is that this will probabl=
y work 95% of the time.  The other 5% ... who knows what will happen .=
.. oh well, better to try and fail than to
 not try at all.



Apologies if this email comes across as a rant.



Rob






















/js











Andy


 



--

Juergen Schoenwaelder           Jacobs Univer=
sity Bremen gGmbH

Phone: +49 421 200 3587         Campus Ring 1 =
| 28759 Bremen | Germany

Fax:   +49 421 200 3103         <=
http://www.jacobs-university.de/>






















--_000_150422385401455228Aviatnetcom_--