From nobody Tue Dec 1 08:54:19 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4408B1ACE1B; Tue, 1 Dec 2015 08:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 NApCeWSuRM7i; Tue, 1 Dec 2015 08:54:15 -0800 (PST) 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 5CBBF1ACE10; Tue, 1 Dec 2015 08:54:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4278; q=dns/txt; s=iport; t=1448988855; x=1450198455; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6maZPBg7+JU84wvVB5ESCOyS4fUgu2YTSnzjBZFmI4g=; b=Zpu9qsAxpO3qcE/2GhrvSgRJTIiVUyPs8pzYM3n+uI2rdnYQW7z3frDQ np04KGLfR+4o9QhH1gYGnWaLYFTIHdwcErkARg7EJHCi5pIP/sQN2GbEO gt0HoqhWl0D0QvegLlom6qYl/sz70qNNVWJ+r0BYKj0ZfNxJ1XFKiEJby A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAgAR0F1W/4YNJK1egztTbwa+MQENg?= =?us-ascii?q?WYXCoUkSgIcgS84FAEBAQEBAQGBCoQ1AQEEAQEBIBE6CxACAQgYAgImAgICJQs?= =?us-ascii?q?VEAIEAQ0FiC4NrCaQaAEBAQEBAQEBAQEBAQEBAQEBAQEBARQEgQGKUYd1gUQFj?= =?us-ascii?q?SKJNQGFKYgOnGABHwEBQoQEcgGEaYEHAQEB?= X-IronPort-AV: E=Sophos;i="5.20,369,1444694400"; d="scan'208";a="51542504" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 01 Dec 2015 16:54:14 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id tB1GsEHf015805 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 1 Dec 2015 16:54:14 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.1104.5; Tue, 1 Dec 2015 11:54:13 -0500 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.1104.000; Tue, 1 Dec 2015 11:54:13 -0500 From: "Acee Lindem (acee)" To: Ladislav Lhotka , Martin Bjorklund Thread-Topic: [Rtg-yang-coord] [netmod] draft-ietf-netmod-routing-cfg Thread-Index: AQHRJpn047JQ40dIlkSrKyodTLwzgp6roMYAgAEb1wCACaf3gA== Date: Tue, 1 Dec 2015 16:54:13 +0000 Message-ID: References: <20151124.102441.1278595679799542000.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.199] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "rtg-yang-coord@ietf.org" , "rtg-dt-yang-arch@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [Rtg-yang-coord] draft-ietf-netmod-routing-cfg X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2015 16:54:17 -0000 SGkgTGFkYSwgDQoNCk9uIDExLzI1LzE1LCAzOjI2IEFNLCAiTGFkaXNsYXYgTGhvdGthIiA8bGhv dGthQG5pYy5jej4gd3JvdGU6DQoNCj4iQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5j b20+IHdyaXRlczoNCj4NCj4+IEhpIE1hcnRpbiwNCj4+ICANCj4+IEkgdGhpbmsgdXNpbmcgdGhl IG1vcmUgZ2VuZXJpYyB0ZXJtLCDigJxuZXR3b3JraW5n4oCdLCBhdCB0aGUgdG9wIHdvdWxkIGJl DQo+PiBwcmVmZXJhYmxlLiBXaGF0IHdlIG5lZWQgaXMgYW4gaW5zdGFuY2UgYWJzdHJhY3Rpb24g dGhhdCBjb3ZlcnMgTDMNCj4NCj5IbW0sIHNoYWxsIHdlIGFsc28gcmVuYW1lICJyb3V0aW5nLXBy b3RvY29sIiB0byAibmV0d29ya2luZy1wcm90b2NvbCI/DQo+U2VyaW91c2x5LCBJIGFtIGNvbmNl cm5lZCB0aGF0IHdlIGFyZSBkcmlmdGluZyBhd2F5IGZyb20gdGhlIG9yaWdpbmFsDQo+Zm9jdXMg b2YgdGhlIGRhdGEgbW9kZWwuIFdlIHNob3VsZCBrZWVwIGluIG1pbmQgaXQgbmVlZHMgdG8gcmVt YWluDQo+dXNhYmxlIGJ5IGhvc3RzIChldmVuIGNvbnN0cmFpbmVkIG9uZXMpIGFuZCBzaW1wbGUg cm91dGVycyBiZWNhdXNlIHRoZXJlDQo+aXMgbm8gb3RoZXIgbW9kZWwgc3VjaCBkZXZpY2VzIGNv dWxkIHVzZS4NCg0KSW4gdGhlIFJvdXRpbmcgWUFORyBkZXNpZ24gdGVhbSwgd2UgYXJlIG5vdyBj b25zaWRlcmluZyBhIGRpZmZlcmVudA0KYXBwcm9hY2ggd2hpY2ggd291bGQgc2F0aXNmeSB0aGlz IHJlcXVpcmVtZW50IGFuZCBtb3ZlIHRoZSBlbGVtZW50cyB0aGUgb2YNCmlldGYtcm91dGluZy4g VGhlcmUgaXMgbm8gbmVlZCB0byByZW5hbWUgaWYgd2UgY2FuIG1ha2UgdGhpcyB3b3JrLg0KDQpU aGFua3MsDQpBY2VlDQoNCg0KPg0KPj4gKGUuZy4sIHZpcnR1YWwgcm91dGVyIG9yIFZSRiksIEwy IChlLmcuLCBWaXJ0dWFsIFN3aXRjaCBJbnN0YW5jZSksIG9yDQo+PiBhIGNvbWJpbmF0aW9uIChz b21lIEVWUE4sIFRSSUxMLCBldGMpLiBUaGlzIGNvdWxkIGJlIHVzZWQgaW4gbGlldSBvZg0KPj4g ZWFjaCBMMiBtb2RlbCBjcmVhdGluZyB0aGVpciBvd24gdG9wIHNlcGFyYXRlIGxpc3Qgb2YgaW5z dGFuY2VzLiBGb3INCj4+IGV4YW1wbGUsIHRoZSBuZXR3b3JraW5nLWluc3RhbmNlIGNvdWxkIGJl IGF1Z21lbnRlZCB3aXRoIGJvdGggdGhlIFZQTFMNCj4+IGFuZCBWUFdTIGluc3RhbmNlcyBpbg0K Pj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNoYWgtYmVzcy1sMnZwbi15YW5n LTAwLg0KPj4NCj4+IFNvbWUgWUFORyBtb2RlbHMgYXNjcmliZSBncmVhdG5lc3MgZnJvbSB0aGUg c3RhcnQsIG90aGVycyBhY2hpZXZlDQo+PiBncmVhdG5lc3MgdGhyb3VnaCByZWZpbmVtZW50LCB3 aGlsZSBzdGlsbCBvdGhlcnMgaGF2ZSBncmVhdG5lc3MgdGhydXN0DQo+PiB1cG9uIHRoZW0uIHJv dXRpbmctY2ZnIHdvdWxkIGZhbGwgaW50byB0aGUgbGFzdCBjYXRlZ29yeeKApg0KPg0KPklmIGl0 IGV2ZXIgZ2V0cyBmaW5pc2hlZC4NCj4NCj5MYWRhDQo+DQo+Pg0KPj4gVGhhbmtzLA0KPj4gQWNl ZSANCj4+DQo+PiBPbiAxMS8yNC8xNSwgNDoyNCBBTSwgIk1hcnRpbiBCam9ya2x1bmQiIDxtYmpA dGFpbC1mLmNvbT4gd3JvdGU6DQo+Pg0KPj4+SGksDQo+Pj4NCj4+PiJBY2VlIExpbmRlbSAoYWNl ZSkiIDxhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4+IFdlIGhhZCBhIGxvdCBvZiBnb29kIGRp c2N1c3Npb25zIGF0IElFVEYgOTQgd2l0aCByZXNwZWN0IHRvIHRoZQ0KPj4+PiBpZXRmLXJvdXRp bmcgYW5kIGhvdyBpdCBjb3VsZCBiZSBhdWdtZW50ZWQgaW4gdGhlIGZ1dHVyZSB0byBzdXBwb3J0 DQo+Pj4+STJSUy4NCj4+Pj4gVGhlc2UgZGlzY3Vzc2lvbnMgYXJlIG9uZ29pbmcuDQo+Pj4+IA0K Pj4+PiBPbmUgY3VycmVudCBjaGFuZ2UgdGhhdCBJIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSBpcyB0 byBjaGFuZ2UgdGhlIGJhc2UNCj4+Pj4gaW5zdGFuY2UgY29udGFpbmVyIGZyb20gcm91dGluZy1p bnN0YW5jZSB0byBuZXR3b3JraW5nLWluc3RhbmNlLg0KPj4+DQo+Pj5JcyB0aGUgaWRlYSB0byBz aW1wbHkgcmVuYW1lIHRoZSAicm91dGluZy1pbnN0YW5jZSIgY29udGFpbmVyIHRvDQo+Pj4ibmV0 d29ya2luZy1pbnN0YW5jZSI/DQo+Pj4NCj4+PlRoZW4gd2Ugd291bGQgaGF2ZToNCj4+Pg0KPj4+ ICAgKy0tcncgcm91dGluZw0KPj4+ICAgICAgKy0tcncgbmV0d29ya2luZy1pbnN0YW5jZQ0KPj4+ DQo+Pj5Xb3VsZCB5b3Uga2VlcCB0aGUgdG9wLWxldmVsIG5hbWUgInJvdXRpbmciPw0KPj4+DQo+ Pj4NCj4+Pg0KPj4+DQo+Pj4vbWFydGluDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4NCj4+Pj4gVGhpcw0K Pj4+PiB3b3VsZCBwcm92aWRlIGFuIGluc3RhbmNlIGRlZmluaXRpb24gdGhhdCBjb3VsZCBiZSBh dWdtZW50ZWQgZm9yIEwyDQo+Pj4+IHByb3RvY29scyBhbmQgc2VydmljZSBmdW5jdGlvbmFsaXR5 IGFzIHdlbGwgYXMgTDMuIEl0IGlzIGFsc28NCj4+Pj5jb25zaXN0ZW50DQo+Pj4+IHdpdGggdGhl IHRlcm0gdXNlZCBpbiBib3RoDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXJ0 Z3lhbmdkdC1ydGd3Zy1kZXZpY2UtbW9kZWwtMDEudHh0IGFuZA0KPj4+PiANCj4+Pj5odHRwczov L3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1vcGVuY29uZmlnLXJ0Z3dnLW5ldHdvcmstaW5zdGFuY2Ut MDEudHh0Lg0KPj4+PiANCj4+Pj4gVGhhbmtzLA0KPj4+PiBBY2VlIA0KPj4+PiANCj4+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gbmV0bW9k IG1haWxpbmcgbGlzdA0KPj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4+Pj4gDQo+Pg0KPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IFJ0Zy15YW5nLWNvb3JkIG1h aWxpbmcgbGlzdA0KPj4gUnRnLXlhbmctY29vcmRAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcnRnLXlhbmctY29vcmQNCj4NCj4tLSANCj5MYWRpc2xh diBMaG90a2EsIENaLk5JQyBMYWJzDQo+UEdQIEtleSBJRDogRTc0RThDMEMNCg0K From nobody Mon Dec 7 11:29:40 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5216E1A01EC for ; Mon, 7 Dec 2015 11:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.688 X-Spam-Level: X-Spam-Status: No, score=0.688 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 K702BM7XA-Ra for ; Mon, 7 Dec 2015 11:29:27 -0800 (PST) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 EAC931A017E for ; Mon, 7 Dec 2015 11:29:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1449516546; bh=JJjRtR4UMpl96M+15mIE9Amxq0hjrAgIEaMoXyrBAkI=; h=Subject:From:In-Reply-To:Date:References:To; b=uCeW3K9QB9SWUkFrurWIKGWky6v4zUnYy1UmqQ9VBpl7PX4F7HWNyC10GrgX0wY9P rtZmK7uBITjORyfqVlI0sdyWmjzx+3T2BqOJxLyDKX9QxSQGeiPWB7/xOEVxe4aSRB laYsSsjpm1zVFPQ9WsSJQtjK5Y0BoAiMG1fWtiUM= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=144.49.132.3; Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Nadeau Thomas In-Reply-To: <9E8B211C-DBCA-4BBF-92E6-A2240874579C@lucidvision.com> Date: Mon, 7 Dec 2015 11:29:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <58F953E4-9ED8-4A6C-A5C7-823DCD4F1B8B@lucidvision.com> References: <9E8B211C-DBCA-4BBF-92E6-A2240874579C@lucidvision.com> To: netmod WG X-Mailer: Apple Mail (2.3096.5) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=Unknown ip=144.49.132.3 X-IP-stats: Notspam Incoming Last 75, First 181, in=36, out=0, spam=0 Known=true ip=144.49.132.3 Archived-At: Subject: Re: [netmod] Call to adopt draft-bogdanovic-netmod-yang-model-classification-05 as NETMOD WG Draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 19:29:29 -0000 There have been no negative comments during the call for = adoption, so we will move forward with the document. Will the authors please publish the document as = draft-netmod-yang-model-classification-00 and notify the WG? Thank you, =E2=80=94Tom > On Nov 30, 2015:4:40 AM, at 4:40 AM, Nadeau Thomas = wrote: >=20 >=20 > NETMOD: >=20 > This is an official call to adopt = draft-bogdanovic-netmod-yang-model-classification-05=20 > as a NETMOD WG draft. Joel our AD has agreed with the chairs and = authors that it is a good idea=20 > for this to go through the working group rather than it going as an = AD-sponsored draft. This=20 > will explicitly give the draft feedback from the working group and = make it a better > document. Please provide any feedback you might have on this by = Monday, December 7, 2015 at=20 > 8AM EST.=20 >=20 > Kent and Tom (as NETMOD co-chairs) >=20 >=20 >=20 >=20 From nobody Mon Dec 7 11:35:31 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B63841A6FAE for ; Mon, 7 Dec 2015 11:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 FvlfBYxjdE-A for ; Mon, 7 Dec 2015 11:35:28 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 279341A00BE for ; Mon, 7 Dec 2015 11:35:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1660; q=dns/txt; s=iport; t=1449516928; x=1450726528; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=lTmjH3a8ieptpylgiuwr7HhiuQ0KBQeoP9bgIvVZhH8=; b=OqJF8VqQcp4lUoJeO5RFZ3d3jOloCekg7a9Y1bfdZ0gQmJ3KrbB20pYU llZjiu/nUNankrQxyeKE4+4J0JRtMPgJSmAtx82CwFC67SyYDdCGjgobW jKjY+RErL9KSaX4AEFKNT4dw14ailoa7I+1AwprUcBAx3eDOftNIGw8ZD I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AAAgAH32VW/4kNJK1egzpTbga9KwENg?= =?us-ascii?q?W4XCoUjSgIcgSo4FAEBAQEBAQGBCoQ0AQEBAwEBAQEaBhE6CwULAgEIDgoCAiY?= =?us-ascii?q?CAgIlCxUQAgQOBYgnCA2wFJBaAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASBAYVTg?= =?us-ascii?q?g+Cbod3L4EVBZZhAY07gVuEQ5ZOAR8BAUKCRIFAcoRogQcBAQE?= X-IronPort-AV: E=Sophos;i="5.20,396,1444694400"; d="scan'208";a="215667288" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Dec 2015 19:35:27 +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 tB7JZRso009127 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 7 Dec 2015 19:35:27 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.1104.5; Mon, 7 Dec 2015 13:35:26 -0600 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.1104.009; Mon, 7 Dec 2015 13:35:26 -0600 From: "Carl Moberg (camoberg)" To: Nadeau Thomas Thread-Topic: [netmod] Call to adopt draft-bogdanovic-netmod-yang-model-classification-05 as NETMOD WG Draft Thread-Index: AQHRMSWi7RKl1XLwSE+UoBUZAG0C0Z7ATyEA Date: Mon, 7 Dec 2015 19:35:26 +0000 Message-ID: References: <9E8B211C-DBCA-4BBF-92E6-A2240874579C@lucidvision.com> <58F953E4-9ED8-4A6C-A5C7-823DCD4F1B8B@lucidvision.com> In-Reply-To: <58F953E4-9ED8-4A6C-A5C7-823DCD4F1B8B@lucidvision.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.157.60.187] Content-Type: text/plain; charset="utf-8" Content-ID: <1EA286CEC3B8F846B356785098EC6CB0@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: netmod WG Subject: Re: [netmod] Call to adopt draft-bogdanovic-netmod-yang-model-classification-05 as NETMOD WG Draft X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 19:35:30 -0000 DQogV2lsbCBkbywgdGhhbmtzLg0KDQo+IE9uIERlYyA3LCAyMDE1LCBhdCAxMToyOSBBTSwgTmFk ZWF1IFRob21hcyA8dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20+IHdyb3RlOg0KPiANCj4gDQo+IAlU aGVyZSBoYXZlIGJlZW4gbm8gbmVnYXRpdmUgY29tbWVudHMgZHVyaW5nIHRoZSBjYWxsIGZvciBh ZG9wdGlvbiwgc28gd2Ugd2lsbCBtb3ZlIGZvcndhcmQNCj4gd2l0aCB0aGUgZG9jdW1lbnQuDQo+ IA0KPiAJV2lsbCB0aGUgYXV0aG9ycyBwbGVhc2UgcHVibGlzaCB0aGUgZG9jdW1lbnQgYXMgZHJh ZnQtbmV0bW9kLXlhbmctbW9kZWwtY2xhc3NpZmljYXRpb24tMDAgYW5kIG5vdGlmeSB0aGUgV0c/ DQo+IA0KPiAJVGhhbmsgeW91LA0KPiANCj4gCeKAlFRvbQ0KPiANCj4gDQo+IA0KPj4gT24gTm92 IDMwLCAyMDE1OjQ6NDAgQU0sIGF0IDQ6NDAgQU0sIE5hZGVhdSBUaG9tYXMgPHRuYWRlYXVAbHVj aWR2aXNpb24uY29tPiB3cm90ZToNCj4+IA0KPj4gDQo+PiAJTkVUTU9EOg0KPj4gDQo+PiAJVGhp cyBpcyBhbiBvZmZpY2lhbCBjYWxsIHRvIGFkb3B0IGRyYWZ0LWJvZ2Rhbm92aWMtbmV0bW9kLXlh bmctbW9kZWwtY2xhc3NpZmljYXRpb24tMDUgDQo+PiBhcyBhIE5FVE1PRCBXRyBkcmFmdC4gIEpv ZWwgb3VyIEFEIGhhcyBhZ3JlZWQgd2l0aCB0aGUgY2hhaXJzIGFuZCBhdXRob3JzIHRoYXQgaXQg aXMgYSBnb29kIGlkZWEgDQo+PiBmb3IgdGhpcyB0byBnbyB0aHJvdWdoIHRoZSB3b3JraW5nIGdy b3VwIHJhdGhlciB0aGFuIGl0IGdvaW5nIGFzIGFuIEFELXNwb25zb3JlZCBkcmFmdC4gIFRoaXMg DQo+PiB3aWxsIGV4cGxpY2l0bHkgZ2l2ZSB0aGUgZHJhZnQgZmVlZGJhY2sgZnJvbSB0aGUgd29y a2luZyBncm91cCBhbmQgbWFrZSBpdCBhIGJldHRlcg0KPj4gZG9jdW1lbnQuICBQbGVhc2UgcHJv dmlkZSBhbnkgZmVlZGJhY2sgeW91IG1pZ2h0IGhhdmUgb24gdGhpcyBieSBNb25kYXksIERlY2Vt YmVyIDcsIDIwMTUgYXQgDQo+PiA4QU0gRVNULiANCj4+IA0KPj4gCUtlbnQgYW5kIFRvbSAoYXMg TkVUTU9EIGNvLWNoYWlycykNCj4+IA0KPj4gDQo+PiANCj4+IA0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcgbGlz dA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9uZXRtb2QNCg0K From nobody Mon Dec 7 18:17:21 2015 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 4AB731B2AC4; Mon, 7 Dec 2015 18:17:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151208021720.13395.5568.idtracker@ietfa.amsl.com> Date: Mon, 07 Dec 2015 18:17:20 -0800 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-yang-model-classification-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 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 NETCONF Data Modeling Language Working Group of the IETF. Title : YANG Model Classification Authors : Dean Bogdanovic Benoit Claise Carl Moberg Filename : draft-ietf-netmod-yang-model-classification-00.txt Pages : 9 Date : 2015-12-07 Abstract: The YANG [RFC6020] data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards defining organizations, open source software projects, and vendors are using YANG to develop and publish models of configuration, state data and operations for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG models. A consistent terminology would help with the categorization of models, assist in the analysis 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 models. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-model-classification-00 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 Tue Dec 8 00:10:08 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9371A01A8 for ; Tue, 8 Dec 2015 00:10:06 -0800 (PST) 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] autolearn=ham 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 NmuBM7nzAp2r for ; Tue, 8 Dec 2015 00:10:03 -0800 (PST) Received: from mailscan1.extendcp.co.uk (mailscan28.extendcp.co.uk [176.32.228.2]) (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 D14281A01A2 for ; Tue, 8 Dec 2015 00:10:02 -0800 (PST) Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mailscan3.hi.local) by mailscan-g69.hi.local with esmtp (Exim 4.80.1) (envelope-from ) id 1a6DLU-0005nK-Jn for netmod@ietf.org; Tue, 08 Dec 2015 08:10:00 +0000 Received: from mailscanlb0.hi.local ([10.0.44.160] helo=mail149.extendcp.co.uk) by mailscan3.hi.local with esmtps (UNKNOWN:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.80.1) (envelope-from ) id 1a6DLT-0003eM-S6 for netmod@ietf.org; Tue, 08 Dec 2015 08:10:00 +0000 Received: from host-79-77-2-126.static.as9105.com ([79.77.2.126] helo=[IPv6:::ffff:172.16.0.65]) by mail149.extendcp.com with esmtpa (Exim 4.80.1) id 1a6DLS-000CAQ-JE for netmod@ietf.org; Tue, 08 Dec 2015 08:09:58 +0000 MIME-Version: 1.0 To: "netmod@ietf.org" From: Jonathan Hansford Date: Tue, 8 Dec 2015 08:14:00 +0000 Importance: normal X-Priority: 3 In-Reply-To: <20151208021720.13395.5568.idtracker@ietfa.amsl.com> References: <20151208021720.13395.5568.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="_03786860-8C61-4440-9D4F-04D7030A9FB1_" X-Authenticated-As: jonathan@hansfords.net X-Extend-Src: mailout Message-Id: Archived-At: Subject: Re: [netmod] I-D Action:draft-ietf-netmod-yang-model-classification-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 08:10:06 -0000 --_03786860-8C61-4440-9D4F-04D7030A9FB1_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I=E2=80=99ve picked up some possible typos in the document. Being British, = I accept some of these may purely reflect different approaches to a common = (!) language. Section 2 =E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s/to developing Y= ANG model/to developing a YANG model =E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s/benefits that a= ppeals/benefits that appeal =E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s/this documents = suggests/this document suggests =E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s/YANG Models des= cribes/YANG Models describe =E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s/Layering of mod= els allow for/Layering of models allows for =E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s/e.g/e.g. =E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s/with experience= from/with experience of Section 2.1 =E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s/YANG models def= ines/YANG models define Section 3 =E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s/and to Network = Service/and Network Service Section 3.1 =E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s/lifecycle of th= ese models are/lifecycle of these models is Section 3.2 =E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s/to, or adopted = by/to or adopted by =E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s/lifecycle of th= ese models are/lifecycle of these models is =E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Section 3.3 =E2=80=A2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 s/what is covered= /that covered HTH, Jonathan From: internet-drafts@ietf.org Sent: 08 December 2015 02:17 To: i-d-announce@ietf.org Cc: netmod@ietf.org Subject: [netmod] I-D Action:draft-ietf-netmod-yang-model-classification-00= .txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the NETCONF Data Modeling Language Working Gr= oup of the IETF. Title : YANG Model Classification Authors : Dean Bogdanovic Benoit Claise Carl Moberg Filename : draft-ietf-netmod-yang-model-classification-00.txt Pages : 9 Date : 2015-12-07 Abstract: The YANG [RFC6020] data modeling language is currently being considered for a wide variety of applications throughout the networking industry at large. Many standards defining organizations, open source software projects, and vendors are using YANG to develop and publish models of configuration, state data and operations for a wide variety of applications. At the same time, there is currently no well-known terminology to categorize various types of YANG models. A consistent terminology would help with the categorization of models, assist in the analysis 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 models. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classificatio= n/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-model-classification-00 Please note that it may take a couple of minutes from the time of submissio= n 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 --_03786860-8C61-4440-9D4F-04D7030A9FB1_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

I=E2=80=99ve picked up some possible typos in the document. Being = British, I accept some of these may purely reflect different approaches to = a common (!) language.

 =

Section 2

=C2=B7         s/to developing YANG model/to developing a YANG model

=C2=B7    &n= bsp;    s/benefits that appeals/benefits that appeal<= o:p>

=C2=B7 &nbs= p;       s/this documents suggests/thi= s document suggests

=C2=B7=          s/YANG Mo= dels describes/YANG Models describe

=C2=B7         = s/Layering of models allow for/Layering of models allows for

= =C2=B7   = ;      s/e.g/e.g.

=C2=B7      &= nbsp;  s/with experience from/with experience of

=

Section 2.1

=C2=B7         s/YANG= models defines/YANG models define

Secti= on 3

=C2=B7  &nb= sp;      s/and to Network Service/and Netwo= rk Service

Section 3.1

=C2=B7      &= nbsp;  s/lifecycle of these models are/lifecycle of these model= s is

Section 3.2

=C2=B7     &nb= sp;   s/to, or adopted by/to or adopted by

<= p class=3DMsoListParagraphCxSpMiddle style=3D'text-indent:-18.0pt'>=C2=B7    &= nbsp;    s/lifecycle of these models are/lifecycle of= these models is

=C2=B7    &nbs= p;    Section 3.3

=C2=B7        = ; s/what is covered/that covered

=  

HTH,

 

Jonathan

 =


From: internet-drafts@ietf.org
Sent: 08 December = 2015 02:17
To: i-d-announce@ietf.org
Cc: netmod@ietf.or= g
Subject: [netmod] I-D Action:draft-ietf-netmod-yang-model-class= ification-00.txt

 

 

 <= /p>

A New Internet-Draft is available from the on-line = Internet-Drafts directories.

This draft is a work = item of the NETCONF Data Modeling Language Working Group of the IETF.

 

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Title=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 : YANG Model Classification

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Authors=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 : Dean Bogdanovic

=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Benoi= t Claise

=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=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Carl Moberg

=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 Filename=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : draft-iet= f-netmod-yang-model-classification-00.txt

=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 Pages=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : = 9

=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 Date=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : 2015-12-07

 

Abstract:

=C2=A0=C2=A0 The YANG [RFC6020] data modeling language is currently bein= g

=C2=A0=C2=A0 considered for a wide variety of app= lications throughout the

=C2=A0=C2=A0 networking in= dustry at large.=C2=A0 Many standards defining organizations,

=C2=A0=C2=A0 open source software projects, and vendors are us= ing YANG to develop

=C2=A0=C2=A0 and publish models= of configuration, state data and operations for a

= =C2=A0=C2=A0 wide variety of applications.=C2=A0 At the same time, there is= currently

=C2=A0=C2=A0 no well-known terminology t= o categorize various types of YANG models.

&nb= sp;

=C2=A0=C2=A0 A consistent terminology wou= ld help with the categorization of

=C2=A0=C2=A0 mod= els, assist in the analysis the YANG data modeling efforts in the

=C2=A0=C2=A0 IETF and other organizations, and bring clarity= to the YANG-related

=C2=A0=C2=A0 discussions betwe= en the different groups.

 

=C2=A0=C2=A0 This document describes a set of concepts and = associated terms to

=C2=A0=C2=A0 support consistent= classification of YANG models.

 

 

The IETF d= atatracker status page for this draft is:

https://d= atatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/

 

There's also a = htmlized version available at:

https://tools.ietf.o= rg/html/draft-ietf-netmod-yang-model-classification-00

 

 

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.

 <= /p>

Internet-Drafts are also available by anonymous FTP= at:

ftp://ftp.ietf.org/internet-drafts/

 

___________________= ____________________________

netmod mailing list

netmod@ietf.org

https://www.i= etf.org/mailman/listinfo/netmod

 

 

= --_03786860-8C61-4440-9D4F-04D7030A9FB1_-- From nobody Tue Dec 8 09:59:53 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8921A1A07 for ; Tue, 8 Dec 2015 09:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ZeHvrP9kfKzT for ; Tue, 8 Dec 2015 09:59:50 -0800 (PST) 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 069B01A1A06 for ; Tue, 8 Dec 2015 09:59:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5148; q=dns/txt; s=iport; t=1449597590; x=1450807190; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PZPZLGv4W+5H6QnljMtdoFnr9kCIPu79Vqx6KOx/LJQ=; b=be9KgeytMoxjEgwVKYy6Xu8o3ibvXpGqMJ4zg2Zdua6MbkaNiGqPB0ZW GZAyZFZ1oi4FrIfy3NRAAfpog8msVNfGjw5g3sjjbJAUXq3tcCsWKC0YT uEQK3UXpCiRrdNdMWtloCQPOgaXHDNnu1y0+iToVJ5xZFA2u8aPyBmF+l k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgBJGWdW/5pdJa1egzpTbga9OgENg?= =?us-ascii?q?W4XDII7gmZKAhyBIjgUAQEBAQEBAYEKhDQBAQEDAQEBASAROgsFCwIBCBEEAQE?= =?us-ascii?q?BAgImAgICJQsVCAgCBA4FiCcIDa85kHABAQEBAQEBAQEBAQEBAQEBAQEBAQEYg?= =?us-ascii?q?QGFU4IPgm6EWYMeL4EVBZZhAYUsiA+BW0mDepZOAR8BAUKEBHKEaIEHAQEB?= X-IronPort-AV: E=Sophos;i="5.20,400,1444694400"; d="scan'208";a="214657224" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Dec 2015 17:59:49 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tB8HxnHh030630 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 8 Dec 2015 17:59:49 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 8 Dec 2015 11:59:48 -0600 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.1104.009; Tue, 8 Dec 2015 11:59:48 -0600 From: "Carl Moberg (camoberg)" To: Jonathan Hansford Thread-Topic: [netmod] I-D Action:draft-ietf-netmod-yang-model-classification-00.txt Thread-Index: AQHRMY/i5xbi+Pne/UGLJ5Y/bq7FKZ7BxeiA Date: Tue, 8 Dec 2015 17:59:48 +0000 Message-ID: <3D3E3728-C30C-4FB6-9B28-2023498339E6@cisco.com> References: <20151208021720.13395.5568.idtracker@ietfa.amsl.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.157.60.154] Content-Type: text/plain; charset="utf-8" Content-ID: <2C2E085ACA87BF43A3F39389AC31AD0C@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] I-D Action:draft-ietf-netmod-yang-model-classification-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 17:59:52 -0000 DQogRXhjZWxsZW50LCB0aGFua3MhIFF1ZXVlaW5nIGZpeGVzIHRvIHRoZSBiZWxvdyB1cCBmb3Ig bmV4dCB2ZXJzaW9uLg0KDQoNCj4gT24gRGVjIDgsIDIwMTUsIGF0IDEyOjE0IEFNLCBKb25hdGhh biBIYW5zZm9yZCA8am9uYXRoYW5AaGFuc2ZvcmRzLm5ldD4gd3JvdGU6DQo+IA0KPiBJ4oCZdmUg cGlja2VkIHVwIHNvbWUgcG9zc2libGUgdHlwb3MgaW4gdGhlIGRvY3VtZW50LiBCZWluZyBCcml0 aXNoLCBJIGFjY2VwdCBzb21lIG9mIHRoZXNlIG1heSBwdXJlbHkgcmVmbGVjdCBkaWZmZXJlbnQg YXBwcm9hY2hlcyB0byBhIGNvbW1vbiAoISkgbGFuZ3VhZ2UuDQo+ICANCj4gU2VjdGlvbiAyDQo+ IMK3ICAgICAgICAgcy90byBkZXZlbG9waW5nIFlBTkcgbW9kZWwvdG8gZGV2ZWxvcGluZyBhIFlB TkcgbW9kZWwNCj4gwrcgICAgICAgICBzL2JlbmVmaXRzIHRoYXQgYXBwZWFscy9iZW5lZml0cyB0 aGF0IGFwcGVhbA0KPiDCtyAgICAgICAgIHMvdGhpcyBkb2N1bWVudHMgc3VnZ2VzdHMvdGhpcyBk b2N1bWVudCBzdWdnZXN0cw0KPiDCtyAgICAgICAgIHMvWUFORyBNb2RlbHMgZGVzY3JpYmVzL1lB TkcgTW9kZWxzIGRlc2NyaWJlDQo+IMK3ICAgICAgICAgcy9MYXllcmluZyBvZiBtb2RlbHMgYWxs b3cgZm9yL0xheWVyaW5nIG9mIG1vZGVscyBhbGxvd3MgZm9yDQo+IMK3ICAgICAgICAgcy9lLmcv ZS5nLg0KPiDCtyAgICAgICAgIHMvd2l0aCBleHBlcmllbmNlIGZyb20vd2l0aCBleHBlcmllbmNl IG9mDQo+IFNlY3Rpb24gMi4xDQo+IMK3ICAgICAgICAgcy9ZQU5HIG1vZGVscyBkZWZpbmVzL1lB TkcgbW9kZWxzIGRlZmluZQ0KPiBTZWN0aW9uIDMNCj4gwrcgICAgICAgICBzL2FuZCB0byBOZXR3 b3JrIFNlcnZpY2UvYW5kIE5ldHdvcmsgU2VydmljZQ0KPiBTZWN0aW9uIDMuMQ0KPiDCtyAgICAg ICAgIHMvbGlmZWN5Y2xlIG9mIHRoZXNlIG1vZGVscyBhcmUvbGlmZWN5Y2xlIG9mIHRoZXNlIG1v ZGVscyBpcw0KPiBTZWN0aW9uIDMuMg0KPiDCtyAgICAgICAgIHMvdG8sIG9yIGFkb3B0ZWQgYnkv dG8gb3IgYWRvcHRlZCBieQ0KPiDCtyAgICAgICAgIHMvbGlmZWN5Y2xlIG9mIHRoZXNlIG1vZGVs cyBhcmUvbGlmZWN5Y2xlIG9mIHRoZXNlIG1vZGVscyBpcw0KPiDCtyAgICAgICAgIFNlY3Rpb24g My4zDQo+IMK3ICAgICAgICAgcy93aGF0IGlzIGNvdmVyZWQvdGhhdCBjb3ZlcmVkDQo+ICANCj4g SFRILA0KPiAgDQo+IEpvbmF0aGFuDQo+ICANCj4gDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0Bp ZXRmLm9yZw0KPiBTZW50OiAwOCBEZWNlbWJlciAyMDE1IDAyOjE3DQo+IFRvOiBpLWQtYW5ub3Vu Y2VAaWV0Zi5vcmcNCj4gQ2M6IG5ldG1vZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbbmV0bW9kXSBJ LUQgQWN0aW9uOmRyYWZ0LWlldGYtbmV0bW9kLXlhbmctbW9kZWwtY2xhc3NpZmljYXRpb24tMDAu dHh0DQo+ICANCj4gIA0KPiAgDQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBm cm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4gVGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTkVUQ09ORiBEYXRhIE1vZGVsaW5nIExhbmd1YWdlIFdv cmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+ICANCj4gICAgICAgICBUaXRsZSAgICAgICAgICAg OiBZQU5HIE1vZGVsIENsYXNzaWZpY2F0aW9uDQo+ICAgICAgICAgQXV0aG9ycyAgICAgICAgIDog RGVhbiBCb2dkYW5vdmljDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgQmVub2l0IENsYWlz ZQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIENhcmwgTW9iZXJnDQo+ICAgICAgICAgICAg ICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW5ldG1vZC15YW5nLW1vZGVsLWNsYXNz aWZpY2F0aW9uLTAwLnR4dA0KPiAgICAgICAgICAgICAgICAgUGFnZXMgICAgICAgICAgIDogOQ0K PiAgICAgICAgICAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxNS0xMi0wNw0KPiAgDQo+IEFi c3RyYWN0Og0KPiAgICBUaGUgWUFORyBbUkZDNjAyMF0gZGF0YSBtb2RlbGluZyBsYW5ndWFnZSBp cyBjdXJyZW50bHkgYmVpbmcNCj4gICAgY29uc2lkZXJlZCBmb3IgYSB3aWRlIHZhcmlldHkgb2Yg YXBwbGljYXRpb25zIHRocm91Z2hvdXQgdGhlDQo+ICAgIG5ldHdvcmtpbmcgaW5kdXN0cnkgYXQg bGFyZ2UuICBNYW55IHN0YW5kYXJkcyBkZWZpbmluZyBvcmdhbml6YXRpb25zLA0KPiAgICBvcGVu IHNvdXJjZSBzb2Z0d2FyZSBwcm9qZWN0cywgYW5kIHZlbmRvcnMgYXJlIHVzaW5nIFlBTkcgdG8g ZGV2ZWxvcA0KPiAgICBhbmQgcHVibGlzaCBtb2RlbHMgb2YgY29uZmlndXJhdGlvbiwgc3RhdGUg ZGF0YSBhbmQgb3BlcmF0aW9ucyBmb3IgYQ0KPiAgICB3aWRlIHZhcmlldHkgb2YgYXBwbGljYXRp b25zLiAgQXQgdGhlIHNhbWUgdGltZSwgdGhlcmUgaXMgY3VycmVudGx5DQo+ICAgIG5vIHdlbGwt a25vd24gdGVybWlub2xvZ3kgdG8gY2F0ZWdvcml6ZSB2YXJpb3VzIHR5cGVzIG9mIFlBTkcgbW9k ZWxzLg0KPiAgDQo+ICAgIEEgY29uc2lzdGVudCB0ZXJtaW5vbG9neSB3b3VsZCBoZWxwIHdpdGgg dGhlIGNhdGVnb3JpemF0aW9uIG9mDQo+ICAgIG1vZGVscywgYXNzaXN0IGluIHRoZSBhbmFseXNp cyB0aGUgWUFORyBkYXRhIG1vZGVsaW5nIGVmZm9ydHMgaW4gdGhlDQo+ICAgIElFVEYgYW5kIG90 aGVyIG9yZ2FuaXphdGlvbnMsIGFuZCBicmluZyBjbGFyaXR5IHRvIHRoZSBZQU5HLXJlbGF0ZWQN Cj4gICAgZGlzY3Vzc2lvbnMgYmV0d2VlbiB0aGUgZGlmZmVyZW50IGdyb3Vwcy4NCj4gIA0KPiAg ICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIHNldCBvZiBjb25jZXB0cyBhbmQgYXNzb2NpYXRl ZCB0ZXJtcyB0bw0KPiAgICBzdXBwb3J0IGNvbnNpc3RlbnQgY2xhc3NpZmljYXRpb24gb2YgWUFO RyBtb2RlbHMuDQo+ICANCj4gIA0KPiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBm b3IgdGhpcyBkcmFmdCBpczoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1uZXRtb2QteWFuZy1tb2RlbC1jbGFzc2lmaWNhdGlvbi8NCj4gIA0KPiBUaGVyZSdz IGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbmV0bW9kLXlhbmctbW9kZWwtY2xhc3NpZmljYXRpb24t MDANCj4gIA0KPiAgDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gIA0K PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6 DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+ICANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbmV0bW9kIG1haWxpbmcg bGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRtb2QNCj4gIA0KPiAgDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg== From nobody Tue Dec 8 10:01:19 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCDB1A1A13 for ; Tue, 8 Dec 2015 10:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 xCgDZmmFqRvT for ; Tue, 8 Dec 2015 10:01:15 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F0C31A1A06 for ; Tue, 8 Dec 2015 10:01:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2271; q=dns/txt; s=iport; t=1449597675; x=1450807275; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=WbKNc8JcZoETueS2CI8Wz0k4gkblf+bc8N1U+43Qvnc=; b=ZGvKQUa34uEYf1QXg1SdR+pphr7Rb+9wUmqWKNB6Vrj6TUAOGlYvEnZV YJaVCFZANnmswJVlFF/5hK35wMR4w12MBvjp+44Wlk0h/GLU4p1AO9azb lkC4fa90exr6ww4BYI7WiDY+6FSepYFw3XfGZsIncY5yPQI9N7gxqdpkY c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D/AQAyGmdW/4sNJK1egzpTbga9OgENg?= =?us-ascii?q?W4jgjuDMAKBPjgUAQEBAQEBAYEKhDQBAQEDATo9BwsCARkDAQIfECERGwIIAgQ?= =?us-ascii?q?TiBoDCggNu14NhEQBAQEBAQEBAwEBAQEBAQEBG4ZUgg+CboJThVOBFQWNKYk4A?= =?us-ascii?q?YUshhiBd4FbSYN6jnaHWAEfAQFCgkSBQHIBhGeBBwEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,400,1444694400"; d="scan'208";a="51710910" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Dec 2015 18:01:14 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id tB8I1Edi003646 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 8 Dec 2015 18:01:14 GMT Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 8 Dec 2015 12:01:13 -0600 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.1104.009; Tue, 8 Dec 2015 12:01:13 -0600 From: "Carl Moberg (camoberg)" To: netmod WG Thread-Topic: New Version Notification for draft-ietf-netmod-yang-model-classification-00.txt Thread-Index: AQHRMV6SUx2QGfZFSEeDfGvtwGYlmw== Date: Tue, 8 Dec 2015 18:01:13 +0000 Message-ID: <484827C9-F191-4EB0-B1F2-33D273CE39BC@cisco.com> References: <20151208021720.13395.22205.idtracker@ietfa.amsl.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.157.60.154] Content-Type: text/plain; charset="us-ascii" Content-ID: <414D741F563BC348816ED09281FEAF61@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [netmod] Fwd: New Version Notification for draft-ietf-netmod-yang-model-classification-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Dec 2015 18:01:16 -0000 NETMOD, Please find a renamed and slightly updated -00 version of what used to be = draft-bogdanovic-netmod-yang-model-classification-05 > Begin forwarded message: >=20 > From: > Subject: New Version Notification for draft-ietf-netmod-yang-model-classi= fication-00.txt > Date: December 7, 2015 at 6:17:20 PM PST > To: Benoit Claise , Carl Moberg , = "Dean Bogdanovic" >=20 >=20 > A new version of I-D, draft-ietf-netmod-yang-model-classification-00.txt > has been successfully submitted by Carl Moberg and posted to the > IETF repository. >=20 > Name: draft-ietf-netmod-yang-model-classification > Revision: 00 > Title: YANG Model Classification > Document date: 2015-12-07 > Group: netmod > Pages: 9 > URL: https://www.ietf.org/internet-drafts/draft-ietf-netmod-ya= ng-model-classification-00.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-m= odel-classification/ > Htmlized: https://tools.ietf.org/html/draft-ietf-netmod-yang-model-= classification-00 >=20 >=20 > Abstract: > The YANG [RFC6020] data modeling language is currently being > considered for a wide variety of applications throughout the > networking industry at large. Many standards defining organizations, > open source software projects, and vendors are using YANG to develop > and publish models of configuration, state data and operations for a > wide variety of applications. At the same time, there is currently > no well-known terminology to categorize various types of YANG models. >=20 > A consistent terminology would help with the categorization of > models, assist in the analysis the YANG data modeling efforts in the > IETF and other organizations, and bring clarity to the YANG-related > discussions between the different groups. >=20 > This document describes a set of concepts and associated terms to > support consistent classification of YANG models. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Wed Dec 9 03:52:06 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E17BA1A89A9 for ; Wed, 9 Dec 2015 03:52:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 CpnSJmjazgCI for ; Wed, 9 Dec 2015 03:52:02 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 51A761A89A5 for ; Wed, 9 Dec 2015 03:52:02 -0800 (PST) Received: from localhost (unknown [173.38.220.62]) by mail.tail-f.com (Postfix) with ESMTPSA id 489A81AE0483 for ; Wed, 9 Dec 2015 12:52:00 +0100 (CET) Date: Wed, 09 Dec 2015 12:52:01 +0100 (CET) Message-Id: <20151209.125201.1881722819009601986.mbj@tail-f.com> To: netmod@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: [netmod] new text for Y26 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 11:52:04 -0000 Hi, It seems we will not reach full agreement on some of the remaining issues in 6020bis. Re-opening Y26 is one of them. I don't think this is a good idea, but I realize that the consensus is to relax the "MUST NOT augment mandatory nodes" rule. Here is my proposal for new text. Most of this text is copied from 6087bis, so if we add this to 6020bis, 6087bis should probably be updated as well. This new subsection would go into 7.17 The augment Statement. *** Augmenting Conditionally Mandatory Nodes If the target node is in another module, then nodes added by the augmentation MUST NOT be mandatory nodes (see ^terminology^), except as described below. The reason for this is that clients that do not know about the augmenting module should contiune to work. It is possible to add conditional augment statements such that an old client would not know about the new condition, and would not specify the new condition. The conditional augment statement can contain mandatory nodes only if the condition is false unless explicitly requested by the client. If the augmentation adds mandatory nodes to a target node in another module, the augmentation MUST be conditional with a "when" statement. Care must be taken when defining the "when" expression, so that clients that do not know about the augmenting module do not break. **** Usage Example In the following example, it is OK to augment the "interface" entry with "mandatory-leaf" because the augmentation depends on support for "some-new-iftype". The old client does not know about this type so it would never select this type, and therefore not be adding a mandatory data node. module example-augment { namespace "urn:example:augment"; prefix mymod; import ietf-interfaces { prefix if; } identity some-new-iftype { base if:interface-type; } augment "/if:interfaces/if:interface" { when "if:type = 'mymod:some-new-iftype'"; leaf mandatory-leaf { mandatory true; type string; } } } /martin From nobody Wed Dec 9 06:17:04 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 356FE1A8A28 for ; Wed, 9 Dec 2015 06:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 0N2tn9iXzyfx for ; Wed, 9 Dec 2015 06:17:01 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFD111B2BA3 for ; Wed, 9 Dec 2015 06:17:00 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:3921:c37d:6a4a:d707] (unknown [IPv6:2001:718:1a02:1:3921:c37d:6a4a:d707]) by mail.nic.cz (Postfix) with ESMTPSA id 4253A1816FA; Wed, 9 Dec 2015 15:16:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1449670618; bh=MbZUWN2DthzkE6PygDTuBeqOQ5Jngf54273PNWbwZ/E=; h=From:Date:To; b=BGSzxAJ7rTffFaWZg88fSEf2oPbhIecKD0ukNUGljKnhwMYyFUuJk8ByGWyl6HSHU 7+Re+G9b5cTdY07yYFzkMShYvHBL3ITWb74PuOpT6sGZWYT/EmHda7NeMXhbD2vQyq dN7q3WCL4Ws3ZhfLtv9IQZlVHLNMgbTCUEHv5Zr8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20151209.125201.1881722819009601986.mbj@tail-f.com> Date: Wed, 9 Dec 2015 15:16:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <70DC07E4-58A7-458A-A498-87EEF737FD4E@nic.cz> References: <20151209.125201.1881722819009601986.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new text for Y26 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 14:17:03 -0000 > On 09 Dec 2015, at 12:52, Martin Bjorklund wrote: >=20 > Hi, >=20 > It seems we will not reach full agreement on some of the remaining > issues in 6020bis. Re-opening Y26 is one of them. I don't think this > is a good idea, but I realize that the consensus is to relax the "MUST > NOT augment mandatory nodes" rule. >=20 > Here is my proposal for new text. Most of this text is copied from > 6087bis, so if we add this to 6020bis, 6087bis should probably be > updated as well. I'd prefer to keep it simple, e.g. as in Rob's proposal: https://mailarchive.ietf.org/arch/msg/netmod/JLPDwi9ZqvaOBIw6KjLBGkCSxTU Your text is rather complicated to understand but 1. added nodes can be made mandatory using a "must" statement, to the = same effect. 2. there may be other "safe augments", for example via if-feature, or = when augmenting a choice. Lada >=20 > This new subsection would go into 7.17 The augment Statement. >=20 >=20 > *** Augmenting Conditionally Mandatory Nodes >=20 > If the target node is in another module, then nodes added by the > augmentation MUST NOT be mandatory nodes (see ^terminology^), except > as described below. The reason for this is that clients that do not > know about the augmenting module should contiune to work. >=20 > It is possible to add conditional augment statements such that an old > client would not know about the new condition, and would not specify > the new condition. The conditional augment statement can contain > mandatory nodes only if the condition is false unless explicitly > requested by the client. >=20 > If the augmentation adds mandatory nodes to a target node in another > module, the augmentation MUST be conditional with a "when" statement. > Care must be taken when defining the "when" expression, so that > clients that do not know about the augmenting module do not break. >=20 > **** Usage Example >=20 > In the following example, it is OK to augment the "interface" entry > with "mandatory-leaf" because the augmentation depends on support for > "some-new-iftype". The old client does not know about this type so it > would never select this type, and therefore not be adding a mandatory > data node. >=20 > module example-augment { > namespace "urn:example:augment"; > prefix mymod; >=20 > import ietf-interfaces { > prefix if; > } >=20 > identity some-new-iftype { > base if:interface-type; > } >=20 > augment "/if:interfaces/if:interface" { > when "if:type =3D 'mymod:some-new-iftype'"; >=20 > leaf mandatory-leaf { > mandatory true; > type string; > } > } > } >=20 >=20 >=20 > /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Dec 9 06:28:38 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890EE1B2BDF for ; Wed, 9 Dec 2015 06:28:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 kvUWXgJkZLJy for ; Wed, 9 Dec 2015 06:28:36 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CB3581B2BE0 for ; Wed, 9 Dec 2015 06:28:35 -0800 (PST) Received: from localhost (unknown [173.38.220.62]) by mail.tail-f.com (Postfix) with ESMTPSA id E71871AE0483; Wed, 9 Dec 2015 15:28:33 +0100 (CET) Date: Wed, 09 Dec 2015 15:28:34 +0100 (CET) Message-Id: <20151209.152834.929769218738670712.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <70DC07E4-58A7-458A-A498-87EEF737FD4E@nic.cz> References: <20151209.125201.1881722819009601986.mbj@tail-f.com> <70DC07E4-58A7-458A-A498-87EEF737FD4E@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new text for Y26 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 14:28:37 -0000 Ladislav Lhotka wrote: > > > On 09 Dec 2015, at 12:52, Martin Bjorklund wrote: > > > > Hi, > > > > It seems we will not reach full agreement on some of the remaining > > issues in 6020bis. Re-opening Y26 is one of them. I don't think this > > is a good idea, but I realize that the consensus is to relax the "MUST > > NOT augment mandatory nodes" rule. > > > > Here is my proposal for new text. Most of this text is copied from > > 6087bis, so if we add this to 6020bis, 6087bis should probably be > > updated as well. > > I'd prefer to keep it simple, e.g. as in Rob's proposal: > > https://mailarchive.ietf.org/arch/msg/netmod/JLPDwi9ZqvaOBIw6KjLBGkCSxTU I don't want to refer to 6087bis here. Note that 6087bis is Informational. So I basically copied the text from 6087bis. > Your text is rather complicated to understand but > > 1. added nodes can be made mandatory using a "must" statement, to > the same effect. Yes, and we won't do anything about that. This isn't handled by Robs text / the reference in 6087bis. > 2. there may be other "safe augments", for example via if-feature, No, if-feature is NOT safe. See Andy's text in 6087bis. > or when augmenting a choice. Sure, but this already works in YANG 1.0, since it technically doesn't add any mandatory nodes. /martin > > Lada > > > > > This new subsection would go into 7.17 The augment Statement. > > > > > > *** Augmenting Conditionally Mandatory Nodes > > > > If the target node is in another module, then nodes added by the > > augmentation MUST NOT be mandatory nodes (see ^terminology^), except > > as described below. The reason for this is that clients that do not > > know about the augmenting module should contiune to work. > > > > It is possible to add conditional augment statements such that an old > > client would not know about the new condition, and would not specify > > the new condition. The conditional augment statement can contain > > mandatory nodes only if the condition is false unless explicitly > > requested by the client. > > > > If the augmentation adds mandatory nodes to a target node in another > > module, the augmentation MUST be conditional with a "when" statement. > > Care must be taken when defining the "when" expression, so that > > clients that do not know about the augmenting module do not break. > > > > **** Usage Example > > > > In the following example, it is OK to augment the "interface" entry > > with "mandatory-leaf" because the augmentation depends on support for > > "some-new-iftype". The old client does not know about this type so it > > would never select this type, and therefore not be adding a mandatory > > data node. > > > > module example-augment { > > namespace "urn:example:augment"; > > prefix mymod; > > > > import ietf-interfaces { > > prefix if; > > } > > > > identity some-new-iftype { > > base if:interface-type; > > } > > > > augment "/if:interfaces/if:interface" { > > when "if:type = 'mymod:some-new-iftype'"; > > > > leaf mandatory-leaf { > > mandatory true; > > type string; > > } > > } > > } > > > > > > > > /martin > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > From nobody Wed Dec 9 07:02:51 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 190661B2C8B for ; Wed, 9 Dec 2015 07:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 yzPMUf776hbj for ; Wed, 9 Dec 2015 07:02:48 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6961B2C95 for ; Wed, 9 Dec 2015 07:02:48 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:3921:c37d:6a4a:d707] (unknown [IPv6:2001:718:1a02:1:3921:c37d:6a4a:d707]) by mail.nic.cz (Postfix) with ESMTPSA id C2A6C1818BD; Wed, 9 Dec 2015 16:02:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1449673366; bh=HLgqyo83M6LCb1TMVmSAxTaoBEsiu1xp/3dyIs9J/p0=; h=From:Date:To; b=A9kFzK+oloQrKnRBHI0CN0ZNymxsJiDDZYP2LqhSTCJQcFXK24KyTD0xyNVgfg0qM IJxMsG55iZ/5iD2iytdZItm/2RP2O0n1k5jSPUQDXp61vVz8eI53rp+R5cs058LQjT 6c3LhmupRjpn3hN2JvX1DDD0Prs/FTpt9pjDaKkU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20151209.152834.929769218738670712.mbj@tail-f.com> Date: Wed, 9 Dec 2015 16:02:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151209.125201.1881722819009601986.mbj@tail-f.com> <70DC07E4-58A7-458A-A498-87EEF737FD4E@nic.cz> <20151209.152834.929769218738670712.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new text for Y26 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 15:02:51 -0000 > On 09 Dec 2015, at 15:28, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 09 Dec 2015, at 12:52, Martin Bjorklund wrote: >>>=20 >>> Hi, >>>=20 >>> It seems we will not reach full agreement on some of the remaining >>> issues in 6020bis. Re-opening Y26 is one of them. I don't think = this >>> is a good idea, but I realize that the consensus is to relax the = "MUST >>> NOT augment mandatory nodes" rule. >>>=20 >>> Here is my proposal for new text. Most of this text is copied from >>> 6087bis, so if we add this to 6020bis, 6087bis should probably be >>> updated as well. >>=20 >> I'd prefer to keep it simple, e.g. as in Rob's proposal: >>=20 >> = https://mailarchive.ietf.org/arch/msg/netmod/JLPDwi9ZqvaOBIw6KjLBGkCSxTU >=20 > I don't want to refer to 6087bis here. Note that 6087bis is > Informational. So I basically copied the text from 6087bis. OK, right. In this case I would simply change "MUST NOT" to "SHOULD = NOT".=20 >=20 >> Your text is rather complicated to understand but >>=20 >> 1. added nodes can be made mandatory using a "must" statement, to >> the same effect. >=20 > Yes, and we won't do anything about that. This isn't handled by Robs > text / the reference in 6087bis. Sure, I just don't understand why it is so critical to bother with = "mandatory true" if another door for achieving the same is wide open. I believe your main concern (and mine as well) is that rogue vendors may = try to create silos by augmenting standard modules with mandatory = proprietary stuff. This is a real danger but we can't avoid it anyway. >=20 >> 2. there may be other "safe augments", for example via if-feature, >=20 > No, if-feature is NOT safe. See Andy's text in 6087bis. Hmm, section 11 permits a module to be updated with mandatory nodes "if = they are conditionally dependent on a new feature". Why is the augment = case different? >=20 >> or when augmenting a choice. >=20 > Sure, but this already works in YANG 1.0, since it technically doesn't > add any mandatory nodes. module A: choice foo { ... } module B: augment "A:/foo" { container top { leaf bar { type empty; } leaf baz { mandatory true; type empty; } } } IMO this is also perfectly safe yet not allowed by your wording. Lada >=20 >=20 > /martin >=20 >=20 >=20 >>=20 >> Lada >>=20 >>>=20 >>> This new subsection would go into 7.17 The augment Statement. >>>=20 >>>=20 >>> *** Augmenting Conditionally Mandatory Nodes >>>=20 >>> If the target node is in another module, then nodes added by the >>> augmentation MUST NOT be mandatory nodes (see ^terminology^), except >>> as described below. The reason for this is that clients that do not >>> know about the augmenting module should contiune to work. >>>=20 >>> It is possible to add conditional augment statements such that an = old >>> client would not know about the new condition, and would not specify >>> the new condition. The conditional augment statement can contain >>> mandatory nodes only if the condition is false unless explicitly >>> requested by the client. >>>=20 >>> If the augmentation adds mandatory nodes to a target node in another >>> module, the augmentation MUST be conditional with a "when" = statement. >>> Care must be taken when defining the "when" expression, so that >>> clients that do not know about the augmenting module do not break. >>>=20 >>> **** Usage Example >>>=20 >>> In the following example, it is OK to augment the "interface" entry >>> with "mandatory-leaf" because the augmentation depends on support = for >>> "some-new-iftype". The old client does not know about this type so = it >>> would never select this type, and therefore not be adding a = mandatory >>> data node. >>>=20 >>> module example-augment { >>> namespace "urn:example:augment"; >>> prefix mymod; >>>=20 >>> import ietf-interfaces { >>> prefix if; >>> } >>>=20 >>> identity some-new-iftype { >>> base if:interface-type; >>> } >>>=20 >>> augment "/if:interfaces/if:interface" { >>> when "if:type =3D 'mymod:some-new-iftype'"; >>>=20 >>> leaf mandatory-leaf { >>> mandatory true; >>> type string; >>> } >>> } >>> } >>>=20 >>>=20 >>>=20 >>> /martin >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Dec 9 07:13:54 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20591B2C7C for ; Wed, 9 Dec 2015 07:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 bXIiSed13Nho for ; Wed, 9 Dec 2015 07:13:52 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 90E9D1B2C6B for ; Wed, 9 Dec 2015 07:13:52 -0800 (PST) Received: from localhost (unknown [173.38.220.62]) by mail.tail-f.com (Postfix) with ESMTPSA id 76B971AE0483; Wed, 9 Dec 2015 16:13:51 +0100 (CET) Date: Wed, 09 Dec 2015 16:13:52 +0100 (CET) Message-Id: <20151209.161352.813749384940357198.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <70DC07E4-58A7-458A-A498-87EEF737FD4E@nic.cz> <20151209.152834.929769218738670712.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new text for Y26 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 15:13:54 -0000 Ladislav Lhotka wrote: > > > On 09 Dec 2015, at 15:28, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> or when augmenting a choice. > > > > Sure, but this already works in YANG 1.0, since it technically doesn't > > add any mandatory nodes. > > module A: > > choice foo { > ... > } > > module B: > > augment "A:/foo" { > container top { > leaf bar { type empty; } > leaf baz { mandatory true; type empty; } > } > } > > IMO this is also perfectly safe yet not allowed by your wording. It is allowed even in YANG 1. Note that there is a precise definition of "mandatory node", and note that the augment really is: augment "A:/foo" { case top { container top { leaf bar { type empty; } leaf baz { mandatory true; type empty; } } } } /martin From nobody Wed Dec 9 07:18:50 2015 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 CA2DF1B2CC1; Wed, 9 Dec 2015 07:18:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.11.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151209151847.20132.64663.idtracker@ietfa.amsl.com> Date: Wed, 09 Dec 2015 07:18:47 -0800 Archived-At: Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-acl-model-06.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 15:18:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : Network Access Control List (ACL) YANG Data Model Authors : Dean Bogdanovic Kiran Agrahara Sreenivasa Lisa Huang Dana Blair Filename : draft-ietf-netmod-acl-model-06.txt Pages : 28 Date : 2015-12-09 Abstract: This document describes a data model of Access Control List (ACL) basic building blocks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netmod-acl-model-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-06 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 Wed Dec 9 07:24:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928DD1B2CDA for ; Wed, 9 Dec 2015 07:24:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.21 X-Spam-Level: X-Spam-Status: No, score=-14.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 LX7EE_qe95F1 for ; Wed, 9 Dec 2015 07:24:07 -0800 (PST) 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 9E9D61B2CBD for ; Wed, 9 Dec 2015 07:24:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2597; q=dns/txt; s=iport; t=1449674646; x=1450884246; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=T6mbnMajb/a9WTRqOOdQNy2Qy21rVyi6cD7g0tydGik=; b=FEwQGPH76kwWysbygQofjyuTtziqaFSbKExDxvBjY0QtprZgxmwOcvLj BRiaBpv5+guqEzLGxgLBI2z7xkp8wP78+nzLjxPSwcrJ5Vum3SoUmu7Gh wOBskdmqLRplML8g0CSFMtzoykGNMB3aGafug3ZyJKcd0VSok2w6t4gin o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBAC7RmhW/xbLJq1ehA1uvzkjhWwCg?= =?us-ascii?q?XEBAQEBAQGBC4Q1AQEEOEABEAsYCRYPCQMCAQIBRQYBDAYCAQGIKw0Dv1cBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEUBIZVhH2CQYIBCYR1AQSWaYUziBCBW4REgwWPb?= =?us-ascii?q?YNzY4QEPjSEMYFIAQEB?= X-IronPort-AV: E=Sophos;i="5.20,404,1444694400"; d="scan'208";a="607100994" 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; 09 Dec 2015 15:24:04 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tB9FO4Sv030095; Wed, 9 Dec 2015 15:24:04 GMT To: Ladislav Lhotka , =?UTF-8?Q?Martin_Bj=c3=b6rklund?= References: <20151209.125201.1881722819009601986.mbj@tail-f.com> <70DC07E4-58A7-458A-A498-87EEF737FD4E@nic.cz> <20151209.152834.929769218738670712.mbj@tail-f.com> From: Robert Wilton Message-ID: <56684793.6030609@cisco.com> Date: Wed, 9 Dec 2015 15:24:03 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new text for Y26 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 15:24:08 -0000 Hi Lada, Please see inline [RW] ... On 09/12/2015 15:02, Ladislav Lhotka wrote: >> On 09 Dec 2015, at 15:28, Martin Bjorklund wrote: >> >> Ladislav Lhotka wrote: >>>> On 09 Dec 2015, at 12:52, Martin Bjorklund wrote: >>>> >>>> Hi, >>>> >>>> It seems we will not reach full agreement on some of the remaining >>>> issues in 6020bis. Re-opening Y26 is one of them. I don't think this >>>> is a good idea, but I realize that the consensus is to relax the "MUST >>>> NOT augment mandatory nodes" rule. >>>> >>>> Here is my proposal for new text. Most of this text is copied from >>>> 6087bis, so if we add this to 6020bis, 6087bis should probably be >>>> updated as well. >>> I'd prefer to keep it simple, e.g. as in Rob's proposal: >>> >>> https://mailarchive.ietf.org/arch/msg/netmod/JLPDwi9ZqvaOBIw6KjLBGkCSxTU >> I don't want to refer to 6087bis here. Note that 6087bis is >> Informational. So I basically copied the text from 6087bis. > OK, right. In this case I would simply change "MUST NOT" to "SHOULD NOT". > >>> Your text is rather complicated to understand but >>> >>> 1. added nodes can be made mandatory using a "must" statement, to >>> the same effect. >> Yes, and we won't do anything about that. This isn't handled by Robs >> text / the reference in 6087bis. > Sure, I just don't understand why it is so critical to bother with "mandatory true" if another door for achieving the same is wide open. > > I believe your main concern (and mine as well) is that rogue vendors may try to create silos by augmenting standard modules with mandatory proprietary stuff. This is a real danger but we can't avoid it anyway. [RW] Personally I think that there are two areas of concern. The one that you have listed above, and also the module upgrade case. E.g. a server has been upgraded to a new module version but a client is still coded to an older version. The client should continue to have the same service/support available as they had previously even though they are not using the latest module version. > >>> 2. there may be other "safe augments", for example via if-feature, >> No, if-feature is NOT safe. See Andy's text in 6087bis. > Hmm, section 11 permits a module to be updated with mandatory nodes "if they are conditionally dependent on a new feature". Why is the augment case different? [RW] I would think that augmenting with if-feature can't be safe because it is only the server that chooses whether a feature is enabled, not the client. Thanks, Rob From nobody Wed Dec 9 07:30:45 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C28D1B2D18 for ; Wed, 9 Dec 2015 07:30:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ChVHGzNybrEo for ; Wed, 9 Dec 2015 07:30:43 -0800 (PST) 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 086491B2D19 for ; Wed, 9 Dec 2015 07:30:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1249; q=dns/txt; s=iport; t=1449675043; x=1450884643; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=e3fWGE5psna1jxD0d/L01o6miFSqbDsYgcR4Rxr1+4s=; b=PBwX+wqutlfZ/KOHSM+gLX5yXoOcoRkMhXTmepSBoem4uyw6C3pRewOu 8UPh4lYq/bRQ92hGFTwVHDjrppJ8vchng7Z3Yc0bbEYp/Fi5oV/gQbQ9i 6yyxZfxnGHpsbmN+dYpA55v1xpV3A7jZdfiypw+NWjNpD6IG+LT3tDleR A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CnBAATSGhW/xbLJq1ehHu9V4Fihg8Cg?= =?us-ascii?q?WASAQEBAQEBAYEKhDUBAQQ4QAEQCw4KCRYPCQMCAQIBRQYBDAYCAQGIK79oAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBG4ZVhH2JQAEElmmNQ4FbhESDBY9tg3MoCjGEBD40h?= =?us-ascii?q?XkBAQE?= X-IronPort-AV: E=Sophos;i="5.20,404,1444694400"; d="scan'208";a="632481174" 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; 09 Dec 2015 15:30:40 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tB9FUehl013358; Wed, 9 Dec 2015 15:30:40 GMT To: Martin Bjorklund , lhotka@nic.cz References: <70DC07E4-58A7-458A-A498-87EEF737FD4E@nic.cz> <20151209.152834.929769218738670712.mbj@tail-f.com> <20151209.161352.813749384940357198.mbj@tail-f.com> From: Robert Wilton Message-ID: <5668491F.1080903@cisco.com> Date: Wed, 9 Dec 2015 15:30:39 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151209.161352.813749384940357198.mbj@tail-f.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new text for Y26 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 15:30:45 -0000 Hi Martin, Please see inline [RW] ... On 09/12/2015 15:13, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>> On 09 Dec 2015, at 15:28, Martin Bjorklund wrote: >>> >>> Ladislav Lhotka wrote: >>>> or when augmenting a choice. >>> Sure, but this already works in YANG 1.0, since it technically doesn't >>> add any mandatory nodes. >> module A: >> >> choice foo { >> ... >> } >> >> module B: >> >> augment "A:/foo" { >> container top { >> leaf bar { type empty; } >> leaf baz { mandatory true; type empty; } >> } >> } >> >> IMO this is also perfectly safe yet not allowed by your wording. > It is allowed even in YANG 1. > > Note that there is a precise definition of "mandatory node", and note > that the augment really is: [RW] Agreed, but I find the distinction to be a bit subtle. I suspect that quite a lot of readers are likely to think that a mandatory node is any node with an associated "mandatory true" condition, and not make the mental leap to the above example being OK. Hence I would suggest that we call out this case as being explicitly allowed either in 6020bis or perhaps more appropriately in 6087bis. Thanks, Rob From nobody Wed Dec 9 07:56:35 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609171B2E4E for ; Wed, 9 Dec 2015 07:56:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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 GMosHyabBu6k for ; Wed, 9 Dec 2015 07:56:30 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A6851B2E3E for ; Wed, 9 Dec 2015 07:56:30 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:3921:c37d:6a4a:d707] (unknown [IPv6:2001:718:1a02:1:3921:c37d:6a4a:d707]) by mail.nic.cz (Postfix) with ESMTPSA id 870E8180D64; Wed, 9 Dec 2015 16:56:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1449676588; bh=k7p4uB7xMnexSjZ1303fFE42JjTBbYIWEiTaiw422Vw=; h=From:Date:To; b=aMDvdmWNBKnj85LzSlqajRinZY6b6FwHNvJGJmI/C74rlTILn+j0AusbNyXQQLWco /8Ta0f5cvm5uDsFJHsjIl461la3z2bYXePYuH9KzPzgaoWHQSMVZ6M9lk4XW34Lwtg CZqS8avfXdWnHeKokPe1sovkNNxsIXEwxzHM6fIA= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <56684793.6030609@cisco.com> Date: Wed, 9 Dec 2015 16:56:27 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3459C09E-E665-464E-B6CE-E69612015B47@nic.cz> References: <20151209.125201.1881722819009601986.mbj@tail-f.com> <70DC07E4-58A7-458A-A498-87EEF737FD4E@nic.cz> <20151209.152834.929769218738670712.mbj@tail-f.com> <56684793.6030609@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new text for Y26 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 15:56:33 -0000 > On 09 Dec 2015, at 16:24, Robert Wilton wrote: >=20 > Hi Lada, >=20 > Please see inline [RW] ... >=20 > On 09/12/2015 15:02, Ladislav Lhotka wrote: >>> On 09 Dec 2015, at 15:28, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>>> On 09 Dec 2015, at 12:52, Martin Bjorklund wrote: >>>>>=20 >>>>> Hi, >>>>>=20 >>>>> It seems we will not reach full agreement on some of the remaining >>>>> issues in 6020bis. Re-opening Y26 is one of them. I don't think = this >>>>> is a good idea, but I realize that the consensus is to relax the = "MUST >>>>> NOT augment mandatory nodes" rule. >>>>>=20 >>>>> Here is my proposal for new text. Most of this text is copied = from >>>>> 6087bis, so if we add this to 6020bis, 6087bis should probably be >>>>> updated as well. >>>> I'd prefer to keep it simple, e.g. as in Rob's proposal: >>>>=20 >>>> = https://mailarchive.ietf.org/arch/msg/netmod/JLPDwi9ZqvaOBIw6KjLBGkCSxTU >>> I don't want to refer to 6087bis here. Note that 6087bis is >>> Informational. So I basically copied the text from 6087bis. >> OK, right. In this case I would simply change "MUST NOT" to "SHOULD = NOT". >>=20 >>>> Your text is rather complicated to understand but >>>>=20 >>>> 1. added nodes can be made mandatory using a "must" statement, to >>>> the same effect. >>> Yes, and we won't do anything about that. This isn't handled by = Robs >>> text / the reference in 6087bis. >> Sure, I just don't understand why it is so critical to bother with = "mandatory true" if another door for achieving the same is wide open. >>=20 >> I believe your main concern (and mine as well) is that rogue vendors = may try to create silos by augmenting standard modules with mandatory = proprietary stuff. This is a real danger but we can't avoid it anyway. > [RW] > Personally I think that there are two areas of concern. The one that = you have listed above, and also the module upgrade case. E.g. a server = has been upgraded to a new module version but a client is still coded to = an older version. The client should continue to have the same = service/support available as they had previously even though they are = not using the latest module version. The service will be different anyway because the server may send the = client unknown data installed by another client that happens to be new. = I wonder how many client implementations are resilient to such schema = violations. A situation where the server and client work with different = data models is IMO extremely problematic and we can't pretend that some = CLRs make it safe. My favorite example is this *non-mandatory* node: leaf launch-missiles { type boolean; default true; } If an old client isn't aware of this leaf, it won't encounter any = syntactic problems but is it still the same service/support? >=20 >>=20 >>>> 2. there may be other "safe augments", for example via if-feature, >>> No, if-feature is NOT safe. See Andy's text in 6087bis. >> Hmm, section 11 permits a module to be updated with mandatory nodes = "if they are conditionally dependent on a new feature". Why is the = augment case different? > [RW] > I would think that augmenting with if-feature can't be safe because it = is only the server that chooses whether a feature is enabled, not the = client. Sure, but the same happens if the server advertises a new revision of a = module along with a feature that's defined in that new revision. Lada >=20 > Thanks, > Rob -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Dec 9 08:28:05 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBDB1AC3FB; Wed, 9 Dec 2015 08:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.012 X-Spam-Level: X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 xflz0A7WcCiz; Wed, 9 Dec 2015 08:28:01 -0800 (PST) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 E6D291AC3E1; Wed, 9 Dec 2015 08:27:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1449678403; bh=wzn8JavSRkN0UBIwBXWXZeLCp9E3ZJIcDRjs4/TDkbU=; h=From:Subject:Date:Cc:To; b=Iqbg0ui5bMxR6r8iF2OLrdp0tRkQHvEwqBOFFH/vC/2LHO+BgH3mKqWfFsuAswuaN 7ufhOtpnZ7RWPKosYsFYQ7cJjgdRB+SfbBPTPbcvvmtYj/XcTt3iCwXKbHJQt109rv aPojq3NLwwjmvEPnSa8YoRtFHH7f8bnY4XYmNyJs= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.214.13.123; From: Nadeau Thomas Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 9 Dec 2015 08:27:04 -0800 Message-Id: To: netmod WG Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=2 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=70.214.13.123 X-IP-stats: Notspam Incoming Last 0, First 0, in=2, out=0, spam=0 Known=true ip=70.214.13.123 Archived-At: Cc: Benoit Claise , RTG YANG Design Team Subject: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 16:28:02 -0000 This email initiates a NETMOD WG Last call for = draft-ietf-netmod-acl-model-06.=20 Please review the draft and make any comments to the list by Wednesday, = 16 December, 2015 by 8AM EST. Tom and Kent (as NETMOD Co-chairs) From nobody Wed Dec 9 08:29:36 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D121AC3FB for ; Wed, 9 Dec 2015 08:29:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 ru9hvCLgUrXW for ; Wed, 9 Dec 2015 08:29:33 -0800 (PST) Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 2E0361A92BA for ; Wed, 9 Dec 2015 08:29:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1449678542; bh=VVs8JRxBoDaqSKD8lcoC1rln1Rv7u17mQrM+z0+Ul3w=; h=From:Subject:Date:Cc:To; b=b53btLQvuRo5O3TU66ZPbtdfvapBvCASpQSF1t3TRhSZ/ZPj8BGOY386clih0ArX1 ov8oZBMVSBh4TctXN8VjuEyYll1O5W4upH1m+fzg+9CDKtQE6ROe9jSnOsByR/PONX tt336r2vw92Da6n8p7ZVw/NgH1nC7jUwvr6g4SLs= X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=70.214.13.123; From: Nadeau Thomas Content-Type: multipart/alternative; boundary="Apple-Mail=_052B9185-8C20-4B55-9FDC-480974CCB6E3" Date: Wed, 9 Dec 2015 08:29:20 -0800 Message-Id: <7D3E013C-EAA1-4F85-88BF-054AD13884E5@lucidvision.com> To: netmod WG Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) X-Authenticated-User: tnadeau@lucidvision.com X-Info: aspam skipped due to (g_smite_skip_relay) X-Encryption: SSL encrypted X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=3 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=70.214.13.123 X-IP-stats: Notspam Incoming Last 0, First 0, in=3, out=0, spam=0 Known=true ip=70.214.13.123 Archived-At: Cc: draft-bogdanovic-netmod-acl-model@tools.ietf.org Subject: [netmod] IPR Check: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 16:29:34 -0000 --Apple-Mail=_052B9185-8C20-4B55-9FDC-480974CCB6E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This mail starts the IPR poll on draft-ietf-netmod-acl-model-06. Are you aware of any IPR that applies to draft-ietf-netmod-acl-model-06? If so, has this IPR been disclosed in compliance with IETF IPR rules = (see RFCs 3979, 4879, 3669 and 5378 for more details)? If you are listed as a document author or contributor please respond to = this email explicitly regardless of whether or not you are aware of any = relevant IPR. The response needs to be sent to the NETMOD WG mailing list. The = document will not advance to the next stage until a response has been received = from each author and contributor. If you are on the NETMOD WG email list but are not listed as an author = or contributor, then please explicitly respond only if you are aware of any = IPR that has not yet been disclosed in conformance with IETF rules. Thank you, Kent and Tom, NETMOD WG Chairs --Apple-Mail=_052B9185-8C20-4B55-9FDC-480974CCB6E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii


This mail starts the IPR poll on = draft-ietf-netmod-acl-model-06.

Are you aware of any IPR that applies = to draft-ietf-netmod-acl-model-06?
If so, has this = IPR been disclosed in compliance with IETF IPR rules (see RFCs
3979, 4879, 3669 and 5378 for more details)?

If you are listed = as a document author or contributor please respond to this
email explicitly regardless of whether or not = you are aware of any relevant IPR.
The response = needs to be sent to the NETMOD WG mailing list.  The document
will not advance to the next stage until a = response has been received from each
author and contributor.

If you are on the NETMOD WG email list = but are not listed as an author or
contributor, = then please explicitly respond only if you are aware of any IPR that
has not yet been disclosed in conformance with = IETF rules.

Thank you,

Kent and Tom, NETMOD WG Chairs


= --Apple-Mail=_052B9185-8C20-4B55-9FDC-480974CCB6E3-- From nobody Wed Dec 9 08:41:24 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F261ACD30 for ; Wed, 9 Dec 2015 08:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 IOAGEqWCIfnt for ; Wed, 9 Dec 2015 08:41:20 -0800 (PST) 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 2E2DE1ACD23 for ; Wed, 9 Dec 2015 08:41:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4737; q=dns/txt; s=iport; t=1449679280; x=1450888880; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=x6s+keMNVhQSWLMob0AYEJbmykBdX69lMnWPv0BPo/o=; b=g7WgCJfq2x3uOQQ8nCLXbFmgrijvLDNeILdHvKYnR8wdifjJeyF0zhJy q/7CkzDi2OG5A1zHuJiegrv1PTGASwv/7lmYMnnPZR7QratNHSfRBpliT ZxokG4lC63z311reL87CB5MaHh7iUlVxl3mFOCO+TD6E/y58s8kdQl2Vc s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQD/WGhW/xbLJq1ehA1uvUoBDYFiI?= =?us-ascii?q?4VsAoFfFAEBAQEBAQGBCoQ0AQEBAwE4QAEFCwsYCRYPCQMCAQIBRQYNBgIBAYg?= =?us-ascii?q?jCA0Dv3cBAQEBAQEBAQEBAQEBAQEBAQEBARUEhlWDd4EGgkGBdA0JhHUBBJZph?= =?us-ascii?q?TOIEIFbhESDBY9tg3MfAQFChAQ+NIQwAR6BKgEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,404,1444694400"; d="scan'208";a="632483786" 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; 09 Dec 2015 16:41:18 +0000 Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tB9GfHAl015092; Wed, 9 Dec 2015 16:41:18 GMT To: Ladislav Lhotka References: <20151209.125201.1881722819009601986.mbj@tail-f.com> <70DC07E4-58A7-458A-A498-87EEF737FD4E@nic.cz> <20151209.152834.929769218738670712.mbj@tail-f.com> <56684793.6030609@cisco.com> <3459C09E-E665-464E-B6CE-E69612015B47@nic.cz> From: Robert Wilton Message-ID: <566859AC.6040906@cisco.com> Date: Wed, 9 Dec 2015 16:41:16 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <3459C09E-E665-464E-B6CE-E69612015B47@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new text for Y26 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 16:41:22 -0000 Hi Lada, On 09/12/2015 15:56, Ladislav Lhotka wrote: >> On 09 Dec 2015, at 16:24, Robert Wilton wrote: >> >> Hi Lada, >> >> Please see inline [RW] ... >> >> On 09/12/2015 15:02, Ladislav Lhotka wrote: >>>> On 09 Dec 2015, at 15:28, Martin Bjorklund wrote: >>>> >>>> Ladislav Lhotka wrote: >>>>>> On 09 Dec 2015, at 12:52, Martin Bjorklund wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> It seems we will not reach full agreement on some of the remaining >>>>>> issues in 6020bis. Re-opening Y26 is one of them. I don't think this >>>>>> is a good idea, but I realize that the consensus is to relax the "MUST >>>>>> NOT augment mandatory nodes" rule. >>>>>> >>>>>> Here is my proposal for new text. Most of this text is copied from >>>>>> 6087bis, so if we add this to 6020bis, 6087bis should probably be >>>>>> updated as well. >>>>> I'd prefer to keep it simple, e.g. as in Rob's proposal: >>>>> >>>>> https://mailarchive.ietf.org/arch/msg/netmod/JLPDwi9ZqvaOBIw6KjLBGkCSxTU >>>> I don't want to refer to 6087bis here. Note that 6087bis is >>>> Informational. So I basically copied the text from 6087bis. >>> OK, right. In this case I would simply change "MUST NOT" to "SHOULD NOT". >>> >>>>> Your text is rather complicated to understand but >>>>> >>>>> 1. added nodes can be made mandatory using a "must" statement, to >>>>> the same effect. >>>> Yes, and we won't do anything about that. This isn't handled by Robs >>>> text / the reference in 6087bis. >>> Sure, I just don't understand why it is so critical to bother with "mandatory true" if another door for achieving the same is wide open. >>> >>> I believe your main concern (and mine as well) is that rogue vendors may try to create silos by augmenting standard modules with mandatory proprietary stuff. This is a real danger but we can't avoid it anyway. >> [RW] >> Personally I think that there are two areas of concern. The one that you have listed above, and also the module upgrade case. E.g. a server has been upgraded to a new module version but a client is still coded to an older version. The client should continue to have the same service/support available as they had previously even though they are not using the latest module version. > The service will be different anyway because the server may send the client unknown data installed by another client that happens to be new. I wonder how many client implementations are resilient to such schema violations. I would think that in a tightly constrained environment (e.g. an ISP that is controlling all the network mgmt clients and network device implementations/versions) might just have specific schemas defined and supported on the clients. But I can also quite easily imagine other off the shelf clients that have been written to be more flexible. I.e. they will handle the specific nodes that they are interested in but otherwise ignore other unknown nodes that may be due to vendor specific augmentations or future version upgrades. > A situation where the server and client work with different data models is IMO extremely problematic and we can't pretend that some CLRs make it safe. > > My favorite example is this *non-mandatory* node: > > leaf launch-missiles { > type boolean; > default true; > } > > If an old client isn't aware of this leaf, it won't encounter any syntactic problems but is it still the same service/support? OK, I'm not actually convinced this specific example is a problem, if launching missiles is the correct/normal default behaviour for the new version of the YANG module! But I agree with you that this isn't necessarily exactly the same service/support. Perhaps a better way that I could have express this would be along the lines of: "The existing nodes used by an old client should still provide a consistent service inline with the documented description of the older version of the YANG module". I.e. a updated module should be allowed to provide new optional functionality which may also include appropriate defaults, but it shouldn't be changing the semantics of the existing functionality specified in the older version (excluding bug fixes). But I do get your general point that the YANG language can't really prevent someone from doing something silly or naughty when either augmenting or upgrading a module, and I also agree with you that there is a limit to how much we should be trying to prevent this. For me, the compromise is that we should try and make it hard to have accidental violations, but not try overly hard to prevent the wilful violations. Thanks, Rob From nobody Wed Dec 9 09:02:24 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 323411B29E0 for ; Wed, 9 Dec 2015 09:02:18 -0800 (PST) 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, SPF_PASS=-0.001] autolearn=ham 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 ZrN4gVBtoQeV for ; Wed, 9 Dec 2015 09:02:07 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 D7D431ACD04 for ; Wed, 9 Dec 2015 09:00:45 -0800 (PST) Received: by wmec201 with SMTP id c201so82873450wme.1 for ; Wed, 09 Dec 2015 09:00:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=M13a9H5eNOGKKdUtofHsoei8aU1LS+MAONcGmQ/QrRo=; b=URXYRHYv8wq32BzHKtOFlxt2USWF1bfelhpbdEpqWXULG2d8M6dSIL1IG1hL5nb4l1 KFKAD894SycDkkdw3aGnnTtiPq/2KGos+02Nug5A59Af9eEMYqg5nqyNPJR54qpa5mpV DbhtRKjB0JgThEqZdi6OgiJC/ylRXgMv/puPrYfWegH2saxCAIaCW+IVpPM+904Tactz O2YVbzX0NyK+zT3JBFFBeGGp2VcISq01JbbEU8qb1HHauUSFHE8fjR6bbdRVA0wpmlwv S/2S8atFlza0BUmWJIIHzg+Ox7GlWhCG07y7AqtQB7hMqdSRwrWCibHKkEDk8Q3Cmmns ARfA== X-Received: by 10.194.104.227 with SMTP id gh3mr7010678wjb.148.1449680444383; Wed, 09 Dec 2015 09:00:44 -0800 (PST) Received: from [192.168.254.136] ([147.83.206.82]) by smtp.gmail.com with ESMTPSA id q6sm8476594wjx.28.2015.12.09.09.00.43 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 09 Dec 2015 09:00:43 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_C88820BC-06C3-4609-BC1F-F4370E3F8B56" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Dean Bogdanovic In-Reply-To: <7D3E013C-EAA1-4F85-88BF-054AD13884E5@lucidvision.com> Date: Wed, 9 Dec 2015 18:00:42 +0100 Message-Id: <691E342F-2C5A-49F2-B77D-BDAA4B2E7D62@gmail.com> References: <7D3E013C-EAA1-4F85-88BF-054AD13884E5@lucidvision.com> To: Nadeau Thomas X-Mailer: Apple Mail (2.3096.5) Archived-At: Cc: draft-bogdanovic-netmod-acl-model@tools.ietf.org, netmod WG Subject: Re: [netmod] IPR Check: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 17:02:18 -0000 --Apple-Mail=_C88820BC-06C3-4609-BC1F-F4370E3F8B56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m not aware of any IPR related to this draft. Dean > On Dec 9, 2015, at 5:29 PM, Nadeau Thomas = wrote: >=20 >=20 >=20 > This mail starts the IPR poll on draft-ietf-netmod-acl-model-06. >=20 > Are you aware of any IPR that applies to = draft-ietf-netmod-acl-model-06? > If so, has this IPR been disclosed in compliance with IETF IPR rules = (see RFCs > 3979, 4879, 3669 and 5378 for more details)? >=20 > If you are listed as a document author or contributor please respond = to this > email explicitly regardless of whether or not you are aware of any = relevant IPR. > The response needs to be sent to the NETMOD WG mailing list. The = document > will not advance to the next stage until a response has been received = from each > author and contributor. >=20 > If you are on the NETMOD WG email list but are not listed as an author = or > contributor, then please explicitly respond only if you are aware of = any IPR that > has not yet been disclosed in conformance with IETF rules. >=20 > Thank you, >=20 > Kent and Tom, NETMOD WG Chairs >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_C88820BC-06C3-4609-BC1F-F4370E3F8B56 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99m not aware of any IPR related to this draft.

Dean

On Dec 9, 2015, at 5:29 PM, Nadeau Thomas <tnadeau@lucidvision.com> wrote:



This mail starts the IPR poll on = draft-ietf-netmod-acl-model-06.

Are you aware of any IPR that applies = to draft-ietf-netmod-acl-model-06?
If so, has this = IPR been disclosed in compliance with IETF IPR rules (see RFCs
3979, 4879, 3669 and 5378 for more details)?

If you are listed = as a document author or contributor please respond to this
email explicitly regardless of whether or not = you are aware of any relevant IPR.
The response = needs to be sent to the NETMOD WG mailing list.  The document
will not advance to the next stage until a = response has been received from each
author and contributor.

If you are on the NETMOD WG email list = but are not listed as an author or
contributor, = then please explicitly respond only if you are aware of any IPR that
has not yet been disclosed in conformance with = IETF rules.

Thank you,

Kent and Tom, NETMOD WG Chairs


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

= --Apple-Mail=_C88820BC-06C3-4609-BC1F-F4370E3F8B56-- From nobody Wed Dec 9 09:20:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 414351A00FE for ; Wed, 9 Dec 2015 09:20:09 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 IgaaATMObepC for ; Wed, 9 Dec 2015 09:20:05 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0792.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::792]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A28911A00E0 for ; Wed, 9 Dec 2015 09:20:04 -0800 (PST) Received: from BL2PR05MB065.namprd05.prod.outlook.com (10.255.232.16) by BL2PR05MB065.namprd05.prod.outlook.com (10.255.232.16) with Microsoft SMTP Server (TLS) id 15.1.337.19; Wed, 9 Dec 2015 17:19:47 +0000 Received: from BL2PR05MB065.namprd05.prod.outlook.com ([169.254.4.94]) by BL2PR05MB065.namprd05.prod.outlook.com ([169.254.4.94]) with mapi id 15.01.0337.015; Wed, 9 Dec 2015 17:19:47 +0000 From: "Lisa (Yi) Huang" To: Dean Bogdanovic , Nadeau Thomas Thread-Topic: [netmod] IPR Check: draft-ietf-netmod-acl-model-06 Thread-Index: AQHRMp7NlCOArc9Qi0eAYjecMslWDZ7C4QgA//9/NoA= Date: Wed, 9 Dec 2015 17:19:46 +0000 Message-ID: References: <7D3E013C-EAA1-4F85-88BF-054AD13884E5@lucidvision.com> <691E342F-2C5A-49F2-B77D-BDAA4B2E7D62@gmail.com> In-Reply-To: <691E342F-2C5A-49F2-B77D-BDAA4B2E7D62@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 authentication-results: spf=none (sender IP is ) smtp.mailfrom=lyihuang@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.239.13] x-microsoft-exchange-diagnostics: 1; BL2PR05MB065; 5:MDyNGp57IsKekpc6JxjOz2vSTjZ5fHbWgM0EknX4CqegQiM0t9eoKNElyFWSbcdVUcJ9es71C3Xws4VVw7gtJxwTOu2zNzzba7CqtRs7mdLRO9sRWwzuuFuut09nXgHee4SLY7TlJIOcmQNNfMtK3w==; 24:H+yYEI7DorA7apqLKkRPm/wmxjMfvpIx6wvrxBu0RQJ56UIyVADexdVtDohQRRNKKS3FB1EHyWhtiqgk6XqH13N5aOLAJcFsbBXux2kJ9co= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR05MB065; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(520078)(3002001)(10201501046); SRVR:BL2PR05MB065; BCL:0; PCL:0; RULEID:; SRVR:BL2PR05MB065; x-forefront-prvs: 0785459C39 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(199003)(189002)(377454003)(189998001)(5008740100001)(122556002)(586003)(3846002)(105586002)(40100003)(19580405001)(36756003)(106116001)(5001770100001)(106356001)(92566002)(4001350100001)(50986999)(81156007)(87936001)(5004730100002)(66066001)(102836003)(6116002)(1220700001)(76176999)(99286002)(5002640100001)(230783001)(1096002)(54356999)(15975445007)(2900100001)(101416001)(19617315012)(97736004)(5001960100002)(11100500001)(2950100001)(19580395003)(16236675004)(83506001)(10400500002)(86362001)(94096001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR05MB065; H:BL2PR05MB065.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:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D28DA2A1FBB2lyihuangjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2015 17:19:46.9730 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR05MB065 Archived-At: Cc: "draft-bogdanovic-netmod-acl-model@tools.ietf.org" , netmod WG Subject: Re: [netmod] IPR Check: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 17:20:09 -0000 --_000_D28DA2A1FBB2lyihuangjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm not aware of any IPR related to this draft. Lisa From: netmod > on b= ehalf of Dean Bogdanovic > Date: Wednesday, December 9, 2015 at 9:00 AM To: Nadeau Thomas > Cc: "draft-bogdanovic-netmod-acl-model@tools.ietf.org" >, netm= od WG > Subject: Re: [netmod] IPR Check: draft-ietf-netmod-acl-model-06 I'm not aware of any IPR related to this draft. Dean On Dec 9, 2015, at 5:29 PM, Nadeau Thomas > wrote: This mail starts the IPR poll on draft-ietf-netmod-acl-model-06. Are you aware of any IPR that applies to draft-ietf-netmod-acl-model-06? If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If you are listed as a document author or contributor please respond to thi= s email explicitly regardless of whether or not you are aware of any relevant= IPR. The response needs to be sent to the NETMOD WG mailing list. The document will not advance to the next stage until a response has been received from = each author and contributor. If you are on the NETMOD WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IP= R that has not yet been disclosed in conformance with IETF rules. Thank you, Kent and Tom, NETMOD WG Chairs _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_D28DA2A1FBB2lyihuangjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
I’m not aware of any IPR related to this draft.

Lisa

From: netmod <netmod-bounces@ietf.org> on behalf of Dean = Bogdanovic <ivandean@gmail.com= >
Date: Wednesday, December 9, 2015 a= t 9:00 AM
To: Nadeau Thomas <tnadeau@lucidvision.com>
Cc: "draft-bogdanovic-netmod-acl-mode= l@tools.ietf.org" <draft-bogdanovic-netmod-acl-model@tools.ietf.org>, netmod WG <netmod@ietf.org> Subject: Re: [netmod] IPR Check: dr= aft-ietf-netmod-acl-model-06

I’m not aware of any IPR related to this draft.

Dean

On Dec 9, 2015, at 5:29 PM, Nadeau Thomas <tnadeau@lucidvision.com> wr= ote:



This mail starts the IPR poll on draft-ietf-netmod-acl-model-06.
Are you aware of any IPR that applies to draft-ietf-netmod-acl-model-06?
If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs
3979, 4879, 3669 and 5378 for more details)?
If you are listed as a document author or contributor please respond to thi= s
email explicitly regardless of whether or not you are aware of any relevant= IPR.
The response needs to be sent to the NETMOD WG mailing list.  The docu= ment
will not advance to the next stage until a response has been received from = each
author and contributor.
If you are on the NETMOD WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any IP= R that
has not yet been disclosed in conformance with IETF rules.
Thank you,

Kent and Tom, NETMOD WG Chairs


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

 --_000_D28DA2A1FBB2lyihuangjunipernet_-- From nobody Wed Dec 9 09:46:01 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDA91B29E4 for ; Wed, 9 Dec 2015 09:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 yz5p1NjGD4jB for ; Wed, 9 Dec 2015 09:45:57 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EEC11A00F3 for ; Wed, 9 Dec 2015 09:45:56 -0800 (PST) Received: from [IPv6:2a01:5e0:29:ffff:e591:6ba5:7c91:30fc] (unknown [IPv6:2a01:5e0:29:ffff:e591:6ba5:7c91:30fc]) by mail.nic.cz (Postfix) with ESMTPSA id B4308181158; Wed, 9 Dec 2015 18:45:54 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1449683154; bh=4MQZpiNo0BMplXfZHbvlhVCfcdAjEX9q3bjx7GPeqZE=; h=From:Date:To; b=PIUc5qph4cnkeF8jB03lHHeiKeK3V5yl/rZcvV4mn/s1Wo6wVXqfY4e4HBNBAfHU4 PuPGPI6LPsvOaSqtZduWc/8Qzz830aj6IBmFUoqMM2FAXdpaPVIRXKvpxVQ1H0qJZK cWiwZuLh2qEV3+wJ2tIXRxnO1++4Y0b1PBwNepEo= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <566859AC.6040906@cisco.com> Date: Wed, 9 Dec 2015 18:45:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151209.125201.1881722819009601986.mbj@tail-f.com> <70DC07E4-58A7-458A-A498-87EEF737FD4E@nic.cz> <20151209.152834.929769218738670712.mbj@tail-f.com> <56684793.6030609@cisco.com> <3459C09E-E665-464E-B6CE-E69612015B47@nic.cz> <566859AC.6040906@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] new text for Y26 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Dec 2015 17:45:59 -0000 > On 09 Dec 2015, at 17:41, Robert Wilton wrote: >=20 > Hi Lada, >=20 > On 09/12/2015 15:56, Ladislav Lhotka wrote: >>> On 09 Dec 2015, at 16:24, Robert Wilton wrote: >>>=20 >>> Hi Lada, >>>=20 >>> Please see inline [RW] ... >>>=20 >>> On 09/12/2015 15:02, Ladislav Lhotka wrote: >>>>> On 09 Dec 2015, at 15:28, Martin Bjorklund wrote: >>>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>>> On 09 Dec 2015, at 12:52, Martin Bjorklund = wrote: >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> It seems we will not reach full agreement on some of the = remaining >>>>>>> issues in 6020bis. Re-opening Y26 is one of them. I don't = think this >>>>>>> is a good idea, but I realize that the consensus is to relax the = "MUST >>>>>>> NOT augment mandatory nodes" rule. >>>>>>>=20 >>>>>>> Here is my proposal for new text. Most of this text is copied = from >>>>>>> 6087bis, so if we add this to 6020bis, 6087bis should probably = be >>>>>>> updated as well. >>>>>> I'd prefer to keep it simple, e.g. as in Rob's proposal: >>>>>>=20 >>>>>> = https://mailarchive.ietf.org/arch/msg/netmod/JLPDwi9ZqvaOBIw6KjLBGkCSxTU >>>>> I don't want to refer to 6087bis here. Note that 6087bis is >>>>> Informational. So I basically copied the text from 6087bis. >>>> OK, right. In this case I would simply change "MUST NOT" to "SHOULD = NOT". >>>>=20 >>>>>> Your text is rather complicated to understand but >>>>>>=20 >>>>>> 1. added nodes can be made mandatory using a "must" statement, to >>>>>> the same effect. >>>>> Yes, and we won't do anything about that. This isn't handled by = Robs >>>>> text / the reference in 6087bis. >>>> Sure, I just don't understand why it is so critical to bother with = "mandatory true" if another door for achieving the same is wide open. >>>>=20 >>>> I believe your main concern (and mine as well) is that rogue = vendors may try to create silos by augmenting standard modules with = mandatory proprietary stuff. This is a real danger but we can't avoid it = anyway. >>> [RW] >>> Personally I think that there are two areas of concern. The one = that you have listed above, and also the module upgrade case. E.g. a = server has been upgraded to a new module version but a client is still = coded to an older version. The client should continue to have the same = service/support available as they had previously even though they are = not using the latest module version. >> The service will be different anyway because the server may send the = client unknown data installed by another client that happens to be new. = I wonder how many client implementations are resilient to such schema = violations. > I would think that in a tightly constrained environment (e.g. an ISP = that is controlling all the network mgmt clients and network device = implementations/versions) might just have specific schemas defined and = supported on the clients. >=20 > But I can also quite easily imagine other off the shelf clients that = have been written to be more flexible. I.e. they will handle the = specific nodes that they are interested in but otherwise ignore other = unknown nodes that may be due to vendor specific augmentations or future = version upgrades. >=20 >> A situation where the server and client work with different data = models is IMO extremely problematic and we can't pretend that some CLRs = make it safe. >>=20 >> My favorite example is this *non-mandatory* node: >>=20 >> leaf launch-missiles { >> type boolean; >> default true; >> } >>=20 >> If an old client isn't aware of this leaf, it won't encounter any = syntactic problems but is it still the same service/support? > OK, I'm not actually convinced this specific example is a problem, if = launching missiles is the correct/normal default behaviour for the new = version of the YANG module! >=20 > But I agree with you that this isn't necessarily exactly the same = service/support. Perhaps a better way that I could have express this = would be along the lines of: "The existing nodes used by an old client = should still provide a consistent service inline with the documented = description of the older version of the YANG module". I.e. a updated = module should be allowed to provide new optional functionality which may = also include appropriate defaults, but it shouldn't be changing the = semantics of the existing functionality specified in the older version = (excluding bug fixes). >=20 > But I do get your general point that the YANG language can't really = prevent someone from doing something silly or naughty when either = augmenting or upgrading a module, and I also agree with you that there = is a limit to how much we should be trying to prevent this. For me, the = compromise is that we should try and make it hard to have accidental = violations, but not try overly hard to prevent the wilful violations. Yes, exactly! I do agree it is useful to be able to upgrade a network = gradually without breaking management tools but it's IMO a matter of = data-modelling discipline and careful planning. So everybody should read = 6087bis to be aware of the potential problems for backward = compatibility, but cluttering the specification of a data modelling = language with convoluted CLRs in order to prevent incompatible updates = of the data model is IMO wrong. Lada=20 >=20 > Thanks, > Rob -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Dec 10 02:12:08 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FB01A894A for ; Thu, 10 Dec 2015 02:12:06 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 0B_fyT0AiaMt for ; Thu, 10 Dec 2015 02:12:05 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EDE41A8943 for ; Thu, 10 Dec 2015 02:12:05 -0800 (PST) X-AuditID: c1b4fb3a-f79df6d0000013b1-38-56694ff3852a Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id F5.90.05041.3FF49665; Thu, 10 Dec 2015 11:12:03 +0100 (CET) Received: from [159.107.197.121] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.248.2; Thu, 10 Dec 2015 11:12:02 +0100 To: "netmod@ietf.org" From: Balazs Lengyel Message-ID: <56694FF2.1030108@ericsson.com> Date: Thu, 10 Dec 2015 11:12:02 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMLMWRmVeSWpSXmKPExsUyM2K7hO5n/8wwg3l/FSzmX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvsXP1kLWlgqrnROZm5gbGXuYuTkkBAwkdjyahELhC0mceHe erYuRi4OIYHDjBIHd+xghXDWMkpc2jCfHaRKREBdYuZOkCpODjYBI4mp/efBuoUFdCU6Xl1l BbF5BbQltv27AWazCKhKLLr4B6xeVCBG4v2mVYwQNYISJ2c+AetlFrCQmDn/PCOELS+x/e0c sOuEBDQkHl74yzqBkW8WkpZZSFpmIWlZwMi8ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMw qA5u+W21g/Hgc8dDjAIcjEo8vB+UMsOEWBPLiitzDzFKcDArifCucQMK8aYkVlalFuXHF5Xm pBYfYpTmYFES521mehAqJJCeWJKanZpakFoEk2Xi4JRqYFzF7575eIWswxeh2oi7DmrhW6t2 Pj9THdCu9Hj/o/r1VuGbWOes4mac+HuNyoYF7FOFd/i9ylWY6Lbuf576CU3pyNbmoIiMnDfv pSO2lZvW598MTHvJd9Ylf3penbH3mXetd+sMVT61srucbjarO8lrvfF7zZvjHW3mGtVXQ7Wk b9Y/+l/poMRSnJFoqMVcVJwIAN0BiWUmAgAA Archived-At: Subject: [netmod] Multiple deviations with same target X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 10:12:06 -0000 Hello, What happens if I have multiple deviation statements with the same target node, possibly in separate deviation files. E.g it is possible to have two deviation statements setting the range for an integer type leaf to 1..20 in one statement while setting it to 2..8 in another. What is the end result? Error? regards Balazs -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Thu Dec 10 07:54:36 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19AD81A0146 for ; Thu, 10 Dec 2015 07:54:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham 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 kGHdSAdBCmaM for ; Thu, 10 Dec 2015 07:54:34 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6611A0126 for ; Thu, 10 Dec 2015 07:54:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 2447F1E5A3F; Thu, 10 Dec 2015 07:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Kw2keqrRkC3y; Thu, 10 Dec 2015 07:54:16 -0800 (PST) Received: from [192.168.1.129] (host5-81-222-81.range5-81.btcentralplus.com [5.81.222.81]) by c8a.amsl.com (Postfix) with ESMTPSA id 48E1B1E5A3E; Thu, 10 Dec 2015 07:54:15 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=us-ascii From: William Lupton In-Reply-To: <20151116.205149.2072469068908119414.mbj@tail-f.com> Date: Thu, 10 Dec 2015 15:53:51 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <3AFDB786-BFEE-4E82-BCA7-3CC1B41F31EF@broadband-forum.org> References: <20151116.205149.2072469068908119414.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.2104) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] derived-from() and derived-from-or-self() arguments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Dec 2015 15:54:35 -0000 Martin, Thanks for the reply and sorry for my delay in following up. Maybe I'm = misunderstanding your point, but surely any node-set argument can be a = prefixed string, e.g I found this example in a NETMOD "Y26 again, sorry" = thread. augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," + "'TLSA')"; Arguably YANG authors might find it more natural always to use prefixed = strings such as 'iana-dns-parameters:TLSA' when referring to a = namespace-qualified entity? William PS, The current definitions perhaps need to be tightened up wrt = module-name (MUST be valid prefix) and identity-name (MUST NOT be = qualified)? > On 16 Nov 2015, at 19:51, Martin Bjorklund wrote: >=20 > Hi, >=20 > William Lupton wrote: >> Hi, >>=20 >> I'm sure there's an obvious reason for this, but could someone = explain why >> these functions need a separate module-name argument rather than just = using >> that module's prefix on the identity-name argument? >=20 > The only reason is that there are no existing functions that take a > prefixed string as an argument. I think it would be possible to > change these functions to take just two arguments, but I am not sure > it is worth it? >=20 > /martin >=20 >> For example, I saw derived-from(x, "ex-module", "foo") in a recent = message >> but (assuming that "ex" is the prefix for "ex-module") will this = always be >> the same as derived-from(x, "ex:foo")? >>=20 >> Thanks, >> William From nobody Fri Dec 11 00:23:13 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311561A6FD9 for ; Fri, 11 Dec 2015 00:23:12 -0800 (PST) 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, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 MIO9GPjKAt9m for ; Fri, 11 Dec 2015 00:23:08 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4DA1ACD49 for ; Fri, 11 Dec 2015 00:23:08 -0800 (PST) Received: from localhost (unknown [173.38.220.62]) by mail.tail-f.com (Postfix) with ESMTPSA id 8EC981AE098B; Fri, 11 Dec 2015 09:23:06 +0100 (CET) Date: Fri, 11 Dec 2015 09:23:07 +0100 (CET) Message-Id: <20151211.092307.2130639629608897598.mbj@tail-f.com> To: wlupton@broadband-forum.org From: Martin Bjorklund In-Reply-To: <3AFDB786-BFEE-4E82-BCA7-3CC1B41F31EF@broadband-forum.org> References: <20151116.205149.2072469068908119414.mbj@tail-f.com> <3AFDB786-BFEE-4E82-BCA7-3CC1B41F31EF@broadband-forum.org> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] derived-from() and derived-from-or-self() arguments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 08:23:12 -0000 William Lupton wrote: > Martin, > > Thanks for the reply and sorry for my delay in following up. Maybe I'm > misunderstanding your point, but surely any node-set argument can be a > prefixed string, e.g I found this example in a NETMOD "Y26 again, > sorry" thread. > > augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { > when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," > + "'TLSA')"; But in this example there is no prefixed *string value* - the prefix is used in a LocationPath, not a string. > Arguably YANG authors might find it more natural always to use > prefixed strings such as 'iana-dns-parameters:TLSA' when referring to > a namespace-qualified entity? Maybe, yes. It would be useful to hear others opinions! /martin > William > > PS, The current definitions perhaps need to be tightened up wrt > module-name (MUST be valid prefix) and identity-name (MUST NOT be > qualified)? > > > On 16 Nov 2015, at 19:51, Martin Bjorklund wrote: > > > > Hi, > > > > William Lupton wrote: > >> Hi, > >> > >> I'm sure there's an obvious reason for this, but could someone explain > >> why > >> these functions need a separate module-name argument rather than just > >> using > >> that module's prefix on the identity-name argument? > > > > The only reason is that there are no existing functions that take a > > prefixed string as an argument. I think it would be possible to > > change these functions to take just two arguments, but I am not sure > > it is worth it? > > > > /martin > > > >> For example, I saw derived-from(x, "ex-module", "foo") in a recent > >> message > >> but (assuming that "ex" is the prefix for "ex-module") will this > >> always be > >> the same as derived-from(x, "ex:foo")? > >> > >> Thanks, > >> William > From nobody Fri Dec 11 00:55:32 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27BD31ACDE7 for ; Fri, 11 Dec 2015 00:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.351 X-Spam-Level: X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=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 O3g_iR-B60xs for ; Fri, 11 Dec 2015 00:55:22 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A751ACDD5 for ; Fri, 11 Dec 2015 00:55:21 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:b92e:71f4:f0d3:f2b9] (unknown [IPv6:2001:718:1a02:1:b92e:71f4:f0d3:f2b9]) by mail.nic.cz (Postfix) with ESMTPSA id F3CC7181ABE; Fri, 11 Dec 2015 09:55:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1449824120; bh=k+g+hFCxxJ5r45tPOuQoLlMTFqRZ0+t+UPgB6SsikVs=; h=From:Date:To; b=ghJM0hwN5ypqMzlEo3PPXta8fFrYc612Eu3GruiUA2EVSbPVhS69kyxA+3yq+S1Yq jPnhjZzN+A+bxyTYZT3oMAK4ObU311Mba8JCVVikHyN1oEp6gze6CEp/4ddL54jBk4 HyN/fGfRKViW54/JaCYaX+vvya9wjzdcD3HudWuQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20151211.092307.2130639629608897598.mbj@tail-f.com> Date: Fri, 11 Dec 2015 09:55:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <033FA2FC-8BD6-4383-87EB-7C1CE3E8E726@nic.cz> References: <20151116.205149.2072469068908119414.mbj@tail-f.com> <3AFDB786-BFEE-4E82-BCA7-3CC1B41F31EF@broadband-forum.org> <20151211.092307.2130639629608897598.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] derived-from() and derived-from-or-self() arguments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 08:55:30 -0000 > On 11 Dec 2015, at 09:23, Martin Bjorklund wrote: >=20 > William Lupton wrote: >> Martin, >>=20 >> Thanks for the reply and sorry for my delay in following up. Maybe = I'm >> misunderstanding your point, but surely any node-set argument can be = a >> prefixed string, e.g I found this example in a NETMOD "Y26 again, >> sorry" thread. >>=20 >> augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { >> when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," >> + "'TLSA')"; >=20 > But in this example there is no prefixed *string value* - the prefix > is used in a LocationPath, not a string. Right, an identity isn't a node-set. >=20 >> Arguably YANG authors might find it more natural always to use >> prefixed strings such as 'iana-dns-parameters:TLSA' when referring to >> a namespace-qualified entity? >=20 > Maybe, yes. It would be useful to hear others opinions! A code that evaluating these functions needs to know a lot about the = underlying YANG data model anyway, so I think it is no problem to = resolve arbitrary QNames. I am thus in favour of William's proposal. Lada >=20 >=20 > /martin >=20 >=20 >> William >>=20 >> PS, The current definitions perhaps need to be tightened up wrt >> module-name (MUST be valid prefix) and identity-name (MUST NOT be >> qualified)? >>=20 >>> On 16 Nov 2015, at 19:51, Martin Bjorklund wrote: >>>=20 >>> Hi, >>>=20 >>> William Lupton wrote: >>>> Hi, >>>>=20 >>>> I'm sure there's an obvious reason for this, but could someone = explain >>>> why >>>> these functions need a separate module-name argument rather than = just >>>> using >>>> that module's prefix on the identity-name argument? >>>=20 >>> The only reason is that there are no existing functions that take a >>> prefixed string as an argument. I think it would be possible to >>> change these functions to take just two arguments, but I am not sure >>> it is worth it? >>>=20 >>> /martin >>>=20 >>>> For example, I saw derived-from(x, "ex-module", "foo") in a recent >>>> message >>>> but (assuming that "ex" is the prefix for "ex-module") will this >>>> always be >>>> the same as derived-from(x, "ex:foo")? >>>>=20 >>>> Thanks, >>>> William >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 11 01:22:28 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9DD1ACE6A for ; Fri, 11 Dec 2015 01:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.339 X-Spam-Level: ** X-Spam-Status: No, score=2.339 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 9RiCJRpb3llY for ; Fri, 11 Dec 2015 01:22:26 -0800 (PST) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [78.128.211.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5D11ACE5E for ; Fri, 11 Dec 2015 01:22:24 -0800 (PST) Received: by kalendar.cesnet.cz (Postfix, from userid 999) id ED040603AA; Fri, 11 Dec 2015 10:22:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1449825743; bh=bPEmZwfLu4kA8LTdmewJtzmZ65jgZ+OX3EHBFZ78jck=; h=to:date:subject:from; b=o0BadKMlfPryGEwpV9Q9APwm6tyQPePcyT8n/mpPqt7qpV+yL/1tJ2BuUI0Zi/QZu TsH8G1qqU+QMck65qHjugupMov7yQDYll9DR3DkyA+BwOPVfU51iBXknE3QpmlBQNQ jab3j8Jj2HLVBZY9hgxvn6TrA5R2aZEcHbEYhXJw= content-type: text/plain; charset="utf-8" to: netmod@ietf.org User-Agent: SOGoMail 2.3.3a MIME-Version: 1.0 date: Fri, 11 Dec 2015 10:22:23 +0100 message-id: <1837-566a9600-5-4813bd80@167277660> X-Forward: 2001:67c:1220:80c:2848:4cd3:51b6:11c3 from: =?utf-8?q?Michal_Va=C5=A1ko?= content-transfer-encoding: quoted-printable Archived-At: Subject: [netmod] effect of include in a submodule X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 09:22:28 -0000 Hi, I want to make sure I understand the effect of including a submodule in= another submodule (of the same belongs-to parent, naturally). RFC 6020 sec. 7.1.6 says: "When a module includes a submodule, it incorporates the contents of the submodule into the node hierarchy of the module. When a submodule includes another submodule, the target submodule's definitions are made available to the current submodule." >From the first sentence I understand that include in a module has the e= ffect of both the definitions (typedefs, indentities, ..., as defined i= n the bullets in the sec. 7.1.5) and the data (containers, lists, and t= he rest) being part of the module. This means one can refer in the modu= le to both the definitions and the data from the submodule without usin= g any prefix or the prefix of the module. From the second sentence I ga= ther that including a submodule2 in submodule1 makes only the definitio= ns from submodule2 available in submodule1 and they can be referred to = without any prefix or the belongs-to prefix from submodule1. My underst= anding of the second sentence is supported by the first sentence of the= sec. 7.1.5: "The "import" statement makes definitions from one module available inside another module or submodule." With import you make only the definitions available and the import pref= ix must be specified to use them. My actual question then is, does the effect of include in a submodule d= iffer from the effect of include in a module? Is it actually an import = (but you cannot import a submodule) in the former, while a C-style #inc= lude in the latter? Thank you. Regards, Michal Vasko From nobody Fri Dec 11 01:50:47 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7455B1A017D for ; Fri, 11 Dec 2015 01:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=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-hdF9IqJLrs for ; Fri, 11 Dec 2015 01:50:41 -0800 (PST) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id F03BD1A017A for ; Fri, 11 Dec 2015 01:50:40 -0800 (PST) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id D5602C4175C1; Fri, 11 Dec 2015 10:50:36 +0100 (CET) To: Ladislav Lhotka , =?UTF-8?Q?Martin_Bj=c3=b6rklund?= References: <20151116.205149.2072469068908119414.mbj@tail-f.com> <3AFDB786-BFEE-4E82-BCA7-3CC1B41F31EF@broadband-forum.org> <20151211.092307.2130639629608897598.mbj@tail-f.com> <033FA2FC-8BD6-4383-87EB-7C1CE3E8E726@nic.cz> From: Jernej Tuljak Message-ID: <566A9C68.7090007@mg-soft.si> Date: Fri, 11 Dec 2015 10:50:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <033FA2FC-8BD6-4383-87EB-7C1CE3E8E726@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] derived-from() and derived-from-or-self() arguments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 09:50:44 -0000 Ladislav Lhotka je 11.12.2015 ob 9:55 napisal: >> On 11 Dec 2015, at 09:23, Martin Bjorklund wrote: >> >> William Lupton wrote: >>> Martin, >>> >>> Thanks for the reply and sorry for my delay in following up. Maybe I'm >>> misunderstanding your point, but surely any node-set argument can be a >>> prefixed string, e.g I found this example in a NETMOD "Y26 again, >>> sorry" thread. >>> >>> augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { >>> when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," >>> + "'TLSA')"; >> But in this example there is no prefixed *string value* - the prefix >> is used in a LocationPath, not a string. > Right, an identity isn't a node-set. > >>> Arguably YANG authors might find it more natural always to use >>> prefixed strings such as 'iana-dns-parameters:TLSA' when referring to >>> a namespace-qualified entity? >> Maybe, yes. It would be useful to hear others opinions! > A code that evaluating these functions needs to know a lot about the underlying YANG data model anyway, so I think it is no problem to resolve arbitrary QNames. I am thus in favour of William's proposal. If there are no existing functions that take a prefixed string literal, why not simply replace the module name argument with a prefix string? I don't see why a module name needs to be used here at all either - in fact, it seems to be promoting the idea of breaking out of module containment using XPath instead of discouraging it - you should not be able to refer to an identity if it is not defined within an imported or the enclosing module. Jernej > > Lada > >> >> /martin >> >> >>> William >>> >>> PS, The current definitions perhaps need to be tightened up wrt >>> module-name (MUST be valid prefix) and identity-name (MUST NOT be >>> qualified)? >>> >>>> On 16 Nov 2015, at 19:51, Martin Bjorklund wrote: >>>> >>>> Hi, >>>> >>>> William Lupton wrote: >>>>> Hi, >>>>> >>>>> I'm sure there's an obvious reason for this, but could someone explain >>>>> why >>>>> these functions need a separate module-name argument rather than just >>>>> using >>>>> that module's prefix on the identity-name argument? >>>> The only reason is that there are no existing functions that take a >>>> prefixed string as an argument. I think it would be possible to >>>> change these functions to take just two arguments, but I am not sure >>>> it is worth it? >>>> >>>> /martin >>>> >>>>> For example, I saw derived-from(x, "ex-module", "foo") in a recent >>>>> message >>>>> but (assuming that "ex" is the prefix for "ex-module") will this >>>>> always be >>>>> the same as derived-from(x, "ex:foo")? >>>>> >>>>> Thanks, >>>>> William >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Fri Dec 11 02:00:03 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23701A6FF5 for ; Fri, 11 Dec 2015 02:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.361 X-Spam-Level: X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 KfoaaQv66sjl for ; Fri, 11 Dec 2015 02:00:00 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7A001A01EC for ; Fri, 11 Dec 2015 01:50:51 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:b92e:71f4:f0d3:f2b9] (unknown [IPv6:2001:718:1a02:1:b92e:71f4:f0d3:f2b9]) by mail.nic.cz (Postfix) with ESMTPSA id 712D3181B2B; Fri, 11 Dec 2015 10:50:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1449827450; bh=Toh5RhRNB1QWureTCGr8D2Aq4CNI7sTEW5O0obAqP4Y=; h=From:Date:To; b=I7z1fHitnFFQ42f+6kArPeJXaAI/skXXclnhmRlN3cnBvgyqR96y90G/dEa1meQuH JllBIv+XjYNsbTcKs8G1rjVGUi8kEYns+TRPjmJ/4lx4l6wYv88B/KkAEPD7YyZowE eJ2iBgpqtG7+9dxeptKQb81ShnDLYxBkE48nvgNA= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <1837-566a9600-5-4813bd80@167277660> Date: Fri, 11 Dec 2015 10:50:49 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <610D56E3-AA53-41E2-BC6D-BF897A35E7AF@nic.cz> References: <1837-566a9600-5-4813bd80@167277660> To: =?utf-8?Q?Michal_Va=C5=A1ko?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] effect of include in a submodule X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 10:00:02 -0000 Hi Michal, submodule stuff was considerably simplified in = draft-ietf-netmod-rfc6020bis, I think it would be better to use the new = logic everywhere. Essentially, in YANG 1.1 includes are only effective = in the main module, and the result is the same as if the submodule = definition were placed in the main module, so they can be used in the = main module and all submodules without further includes. Lada > On 11 Dec 2015, at 10:22, Michal Va=C5=A1ko wrote: >=20 > Hi, > I want to make sure I understand the effect of including a submodule = in another submodule (of the same belongs-to parent, naturally). >=20 > RFC 6020 sec. 7.1.6 says: >=20 > "When a module includes a submodule, it incorporates the contents of > the submodule into the node hierarchy of the module. When a > submodule includes another submodule, the target submodule's > definitions are made available to the current submodule." >=20 >> =46rom the first sentence I understand that include in a module has = the effect of both the definitions (typedefs, indentities, ..., as = defined in the bullets in the sec. 7.1.5) and the data (containers, = lists, and the rest) being part of the module. This means one can refer = in the module to both the definitions and the data from the submodule = without using any prefix or the prefix of the module. =46rom the second = sentence I gather that including a submodule2 in submodule1 makes only = the definitions from submodule2 available in submodule1 and they can be = referred to without any prefix or the belongs-to prefix from submodule1. = My understanding of the second sentence is supported by the first = sentence of the sec. 7.1.5: >=20 > "The "import" statement makes definitions from one module available > inside another module or submodule." >=20 > With import you make only the definitions available and the import = prefix must be specified to use them. >=20 > My actual question then is, does the effect of include in a submodule = differ from the effect of include in a module? Is it actually an import = (but you cannot import a submodule) in the former, while a C-style = #include in the latter? Thank you. >=20 > Regards, > Michal Vasko >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 11 02:08:41 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165991A711A for ; Fri, 11 Dec 2015 02:08:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 pWPtMPSfqeIj for ; Fri, 11 Dec 2015 02:08:38 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 4A2D31A7034 for ; Fri, 11 Dec 2015 02:08:38 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id A7AEEE40E449C for ; Fri, 11 Dec 2015 10:08:34 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id tBB9YsDk029872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 11 Dec 2015 10:37:45 +0100 Received: from FR712WXCHMBA13.zeu.alcatel-lucent.com ([169.254.5.200]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 11 Dec 2015 10:29:59 +0100 From: "GUBALLA, JENS (JENS)" To: "netmod@ietf.org" Thread-Topic: How to model a leafref in union conforming to RFC6020? Thread-Index: AdEz9oAIA2bEc2jiS3etOwkqv3A8AQ== Date: Fri, 11 Dec 2015 09:29:58 +0000 Message-ID: <547EE95EB794FD4DB8062F7A4C86D0BC4A3A3184@FR712WXCHMBA13.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0230_01D133FE.E1D24A60" MIME-Version: 1.0 Archived-At: Subject: [netmod] How to model a leafref in union conforming to RFC6020? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 10:08:40 -0000 ------=_NextPart_000_0230_01D133FE.E1D24A60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, According to RFC6020 a leafref within a union is not allowed. This issue is captured by Y30 of the yang1.1 issue list. My question: how can such a construct as show below be modeled conforming to RFC6020? leaf the_reference {type uint8;} leaf something { type union { type leafref { path "../the_reference"; } type enumeration { enum "none"; enum "something-else"; } } } Has anyone any ideas or can someone provide me a pointer if this has been discussed already? Thanks, Jens ------=_NextPart_000_0230_01D133FE.E1D24A60 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/DCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYjCCBkqgAwIBAgIKE1mSVAAAAADt+zANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDI0MDYyNDM5WhcNMTcwNDIz MDYyNDM5WjBCMRAwDgYDVQQDEwdsdnBzYWFlMS4wLAYJKoZIhvcNAQkBFh9qZW5zLmd1YmFsbGFA YWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuZZTGrNK 9hSyYEI9w2lnABbWQBeU1DyJ9jX33JSOfgMGYaQ0ZZZFRwX5vDIgj499CxaWmpImbQTxdYa/vxpS U7SfqtYF7B2AB2irUYdCu/GGjTqHaXmPyyktPaiEOgR7AOz8oXxUdaECsKmTBANOpkE1J6yA3KPJ Yxde3h5bTqnjxvJB5IJhr9rIvcf5V3v6ZyW0MHOkDXn20xjEDJVMVdhhjlnwM4WmUiA/SNq7IiQ8 elmivF5NuEK9mwZEXqkR6aXHVcgPc1fuMxwsxJbdfdmMyIDV62kSTVlb/iXNJDByQJ/GRnuYHCFA qIld1HgdJCpECl+ohveGLG46CvD6iwIDAQABo4IEFDCCBBAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIhb3FWYPjsTmHpYEqhr/DQoWUmBmBC/nmTIT9tVoCAWQCAQUwHwYDVR0lBBgwFgYKKwYB BAGCNwoDBAYIKwYBBQUHAwQwCwYDVR0PBAQDAgWgMCkGCSsGAQQBgjcVCgQcMBowDAYKKwYBBAGC NwoDBDAKBggrBgEFBQcDBDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG 9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFPUv0vuw2MQvQ81rxR/PDOlK po4KMB8GA1UdIwQYMBaAFNnsa72WWCL32KZ3zf5Nge+6l70SMIIBXQYDVR0fBIIBVDCCAVAwggFM oIIBSKCCAUSGgdlsZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQlMjBJbnRlcm5hbCUyMFN1YiUy MENBLENOPXVzbmF2c3BraTAzcCxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1sdWFkLERDPWx1Y2VudCxEQz1jb20/Y2VydGlm aWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50 hixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNybIY4aHR0cDovL3Nl cnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmwwggFhBggrBgEF BQcBAQSCAVMwggFPMIHMBggrBgEFBQcwAoaBv2xkYXA6Ly8vQ049QWxjYXRlbCUyMEx1Y2VudCUy MEludGVybmFsJTIwU3ViJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NBQ2Vy dGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDgGCCsGAQUF BzAChixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNydDBEBggrBgEF BQcwAoY4aHR0cDovL3NlcnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJD QS5jcnQwKgYDVR0RBCMwIYEfamVucy5ndWJhbGxhQGFsY2F0ZWwtbHVjZW50LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAXRHvujXQqqJMH1wCrG+0UrRv0v7CpjhIyuLwJ5XDhTj9JcKsYLpWREi/zXhN Sy6TC61uUKLrAuX0uXAXW0zsBYgPDFkq481gTgdxG/brcg8lXF8Xm787ixPR8Mp8j80ZHZ5OnA1k +Xuw/QPsE4wp8RZrjqvoJQpSXtXPdX3+XBE0VsANBYszCWfrR0ByI4hZ9Saoc26umYnOY8sU0UZ/ 1XnEcRfUmVWRxTydYAFdTtOHRjBn3V7TZnfeGYpKSxrqdh6nTqk0FR832p8Z8RyNjEv3qdaX9BK7 jsjQgGNH0gxWPf+wARDdk5abnalyChTjv8B70KeLOYbsrF0greiw3TGCBCkwggQlAgEBMIGUMIGF MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPy LGQBGRYEbmEwMjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVj ZW50IEludGVybmFsIFN1YiBDQQIKE1mSVAAAAADt+zAJBgUrDgMCGgUAoIICaTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMTEwOTI5NTdaMCMGCSqGSIb3DQEJ BDEWBBSPOo9jBS1JqX1g7FJTOoczlzb/3zCBpQYJKwYBBAGCNxAEMYGXMIGUMIGFMRMwEQYKCZIm iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy bmFsIFN1YiBDQQIKE1mSVAAAAADt+zCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYUxEzARBgoJkiaJ k/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJkiaJk/IsZAEZFgRuYTAy MRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRlbCBMdWNlbnQgSW50ZXJu YWwgU3ViIENBAgoTWZJUAAAAAO37MIG3BgkqhkiG9w0BCQ8xgakwgaYwCwYJYIZIAWUDBAEqMAsG CWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzAL BglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBABSV llQZ2wbUQ9nygyM11ymaCHAwxVjvHW0HK1+xPkS5PBa5y3YXxcus5c0+i8NI2AHeP0MXWR4QRcca VweJL4dbqMc0xMHT91L0TLSZGWS42Mr6CGYGnJkYQyY9tlXD+RsDhAdsyVDnhWLdB7koaZA3quws ZSFyashJFJGC0nBcpjcBI+XquDmbmKqBJdNrx/+NNX7ukOhcjWyfKXOFP87qwv4feupL/c+75KnU e1/9i50ajwlmLaL3MiUCWSNyLW5E0xFqXDcfNV4xwb4xiB6Yt5DOz8hnsq2QaU9hwYRPXr7+nCkS KD47qzld1FtWFEIpSybT6z8OTUh0f/vLeZAAAAAAAAA= ------=_NextPart_000_0230_01D133FE.E1D24A60-- From nobody Fri Dec 11 02:51:13 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F33B1A8833 for ; Fri, 11 Dec 2015 02:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.661 X-Spam-Level: X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 xq71Ak4PlZQh for ; Fri, 11 Dec 2015 02:51:07 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9B11A87CD for ; Fri, 11 Dec 2015 02:51:04 -0800 (PST) Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 8F20E181ACA; Fri, 11 Dec 2015 11:51:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1449831061; bh=5ZNPABlJ+hfj34C3aP6MA0KNPn7BIMEs1NzfdfrNnjI=; h=From:Date:To; b=x+fqxtf63XujYin98LRRlrjVML0JaD7my0ZQqOROC+ZuHXlUC/HDM5mTSV7jR+ZbM V4Kx621b7tTcHGQbp7ijUTLH4WuSrLBbOKmt/oWhBVSDgeTEplvg5GaSuHnvYmFlEo FWr3uoxsFCNT6QNsKw/iBvNp1XN8Fux3wDjHOfkE= Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C574B431-B908-4DDF-BC33-0BC0BC578BD1"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.6b2 From: Ladislav Lhotka In-Reply-To: <547EE95EB794FD4DB8062F7A4C86D0BC4A3A3184@FR712WXCHMBA13.zeu.alcatel-lucent.com> Date: Fri, 11 Dec 2015 11:51:00 +0100 Message-Id: <35171113-FCC6-4CF9-A37F-0E6E27EEA624@nic.cz> References: <547EE95EB794FD4DB8062F7A4C86D0BC4A3A3184@FR712WXCHMBA13.zeu.alcatel-lucent.com> To: "GUBALLA, JENS (JENS)" X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] How to model a leafref in union conforming to RFC6020? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 10:51:09 -0000 --Apple-Mail=_C574B431-B908-4DDF-BC33-0BC0BC578BD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 11 Dec 2015, at 10:29, GUBALLA, JENS (JENS) = wrote: >=20 > Hi, >=20 > According to RFC6020 a leafref within a union is not allowed. This = issue is > captured by Y30 of the yang1.1 issue list. >=20 > My question: how can such a construct as show below be modeled = conforming to > RFC6020? >=20 > leaf the_reference {type uint8;} > leaf something { > type union { > type leafref { > path "../the_reference"; > } > type enumeration { > enum "none"; > enum "something-else"; > } > } > } >=20 > Has anyone any ideas or can someone provide me a pointer if this has = been > discussed already? You can define the first union member simply as uint8, without being = formally coupled with "the_reference". I'd suggest to use YANG 1.1 = though where that CLR was removed. Lada >=20 > Thanks, > Jens > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C --Apple-Mail=_C574B431-B908-4DDF-BC33-0BC0BC578BD1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAlZqqpUACgkQWQVCj+dOjAzLhQCfQ3Sbz9ZKekOF2XdeB7CiKUIF i8cAoKG5f7BjtB2fjuYMlHgWwsHZsnFi =lUEL -----END PGP SIGNATURE----- --Apple-Mail=_C574B431-B908-4DDF-BC33-0BC0BC578BD1-- From nobody Fri Dec 11 03:22:47 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D54B1A890E for ; Fri, 11 Dec 2015 03:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 5dH_-watRvud for ; Fri, 11 Dec 2015 03:22:43 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A606A1A8909 for ; Fri, 11 Dec 2015 03:22:43 -0800 (PST) Received: from localhost (unknown [173.38.220.62]) by mail.tail-f.com (Postfix) with ESMTPSA id F08201AE098B; Fri, 11 Dec 2015 12:22:40 +0100 (CET) Date: Fri, 11 Dec 2015 12:22:41 +0100 (CET) Message-Id: <20151211.122241.1330245997181704886.mbj@tail-f.com> To: jernejt@mg-soft.si From: Martin Bjorklund In-Reply-To: <566A9C68.7090007@mg-soft.si> References: <20151211.092307.2130639629608897598.mbj@tail-f.com> <033FA2FC-8BD6-4383-87EB-7C1CE3E8E726@nic.cz> <566A9C68.7090007@mg-soft.si> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] derived-from() and derived-from-or-self() arguments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 11:22:45 -0000 Jernej Tuljak wrote: > Ladislav Lhotka je 11.12.2015 ob 9:55 napisal: > >> On 11 Dec 2015, at 09:23, Martin Bjorklund wrote: > >> > >> William Lupton wrote: > >>> Martin, > >>> > >>> Thanks for the reply and sorry for my delay in following up. Maybe I'm > >>> misunderstanding your point, but surely any node-set argument can be a > >>> prefixed string, e.g I found this example in a NETMOD "Y26 again, > >>> sorry" thread. > >>> > >>> augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { > >>> when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," > >>> + "'TLSA')"; > >> But in this example there is no prefixed *string value* - the prefix > >> is used in a LocationPath, not a string. > > Right, an identity isn't a node-set. > > > >>> Arguably YANG authors might find it more natural always to use > >>> prefixed strings such as 'iana-dns-parameters:TLSA' when referring to > >>> a namespace-qualified entity? > >> Maybe, yes. It would be useful to hear others opinions! > > A code that evaluating these functions needs to know a lot about the > > underlying YANG data model anyway, so I think it is no problem to > > resolve arbitrary QNames. I am thus in favour of William's proposal. > > If there are no existing functions that take a prefixed string > literal, why not simply replace the module name argument with a prefix > string? I don't see why a module name needs to be used here at all > either - in fact, it seems to be promoting the idea of breaking out of > module containment using XPath instead of discouraging it - you should > not be able to refer to an identity if it is not defined within an > imported or the enclosing module. If we're going to use the prefix, I prefer to use a single QName. I agree with your comment as well. So unless anyone objects, I will make this change. /martin From nobody Fri Dec 11 03:23:44 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88CE81A88F5 for ; Fri, 11 Dec 2015 03:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.361 X-Spam-Level: X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 jqtXhlBB6nZA for ; Fri, 11 Dec 2015 03:23:41 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F5D71A8825 for ; Fri, 11 Dec 2015 03:23:40 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:35a8:f200:6e13:d928] (unknown [IPv6:2001:718:1a02:1:35a8:f200:6e13:d928]) by mail.nic.cz (Postfix) with ESMTPSA id 41325181A7D; Fri, 11 Dec 2015 12:23:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1449833019; bh=Z49wgR6zDPnnGIoLH2YAX40IYWJuWQpvxzk8qWal3Ko=; h=From:Date:To; b=he3NlLbeC7w9JC4iv+K+CoyqA/HWxRW18GIHmsHpMPL8VEixXSXVsnluqXrE1PZPa CwHpCLlfLoNt7q3ZDFusGUN6VSYSYit+2SADyodLrA/nWG4J81aOeRYRVQXz34mhKV 2MSoaHXoPIRyZOFooqu94UjgDrXjf+9fcsr/vqyo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Ladislav Lhotka In-Reply-To: <20151211.122241.1330245997181704886.mbj@tail-f.com> Date: Fri, 11 Dec 2015 12:23:39 +0100 Content-Transfer-Encoding: 7bit Message-Id: <706F387A-9026-437F-BED9-C07562C31DA7@nic.cz> References: <20151211.092307.2130639629608897598.mbj@tail-f.com> <033FA2FC-8BD6-4383-87EB-7C1CE3E8E726@nic.cz> <566A9C68.7090007@mg-soft.si> <20151211.122241.1330245997181704886.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3112) X-Virus-Scanned: clamav-milter 0.98.7 at mail X-Virus-Status: Clean Archived-At: Cc: Jernej Tuljak , netmod@ietf.org Subject: Re: [netmod] derived-from() and derived-from-or-self() arguments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 11:23:43 -0000 > On 11 Dec 2015, at 12:22, Martin Bjorklund wrote: > > Jernej Tuljak wrote: >> Ladislav Lhotka je 11.12.2015 ob 9:55 napisal: >>>> On 11 Dec 2015, at 09:23, Martin Bjorklund wrote: >>>> >>>> William Lupton wrote: >>>>> Martin, >>>>> >>>>> Thanks for the reply and sorry for my delay in following up. Maybe I'm >>>>> misunderstanding your point, but surely any node-set argument can be a >>>>> prefixed string, e.g I found this example in a NETMOD "Y26 again, >>>>> sorry" thread. >>>>> >>>>> augment "/dnsz:zones/dnsz:zone/dnsz:rrset/dnsz:rdata" { >>>>> when "derived-from-or-self(../dnsz:type,'iana-dns-parameters'," >>>>> + "'TLSA')"; >>>> But in this example there is no prefixed *string value* - the prefix >>>> is used in a LocationPath, not a string. >>> Right, an identity isn't a node-set. >>> >>>>> Arguably YANG authors might find it more natural always to use >>>>> prefixed strings such as 'iana-dns-parameters:TLSA' when referring to >>>>> a namespace-qualified entity? >>>> Maybe, yes. It would be useful to hear others opinions! >>> A code that evaluating these functions needs to know a lot about the >>> underlying YANG data model anyway, so I think it is no problem to >>> resolve arbitrary QNames. I am thus in favour of William's proposal. >> >> If there are no existing functions that take a prefixed string >> literal, why not simply replace the module name argument with a prefix >> string? I don't see why a module name needs to be used here at all >> either - in fact, it seems to be promoting the idea of breaking out of >> module containment using XPath instead of discouraging it - you should >> not be able to refer to an identity if it is not defined within an >> imported or the enclosing module. > > If we're going to use the prefix, I prefer to use a single QName. I > agree with your comment as well. So unless anyone objects, I will > make this change. +1 Lada > > > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Dec 11 03:25:29 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC04D1A8889 for ; Fri, 11 Dec 2015 03:25:27 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 QUPqs4r5sm1H for ; Fri, 11 Dec 2015 03:25:26 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id BACCA1A8937 for ; Fri, 11 Dec 2015 03:24:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 8C0F51E5A37; Fri, 11 Dec 2015 03:24:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 4vYXjBDA3P5p; Fri, 11 Dec 2015 03:24:24 -0800 (PST) Received: from [192.168.1.129] (host5-81-222-81.range5-81.btcentralplus.com [5.81.222.81]) by c8a.amsl.com (Postfix) with ESMTPSA id B3ABB1E5A25; Fri, 11 Dec 2015 03:24:23 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=us-ascii From: William Lupton In-Reply-To: <566A9C68.7090007@mg-soft.si> Date: Fri, 11 Dec 2015 11:24:42 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20151116.205149.2072469068908119414.mbj@tail-f.com> <3AFDB786-BFEE-4E82-BCA7-3CC1B41F31EF@broadband-forum.org> <20151211.092307.2130639629608897598.mbj@tail-f.com> <033FA2FC-8BD6-4383-87EB-7C1CE3E8E726@nic.cz> <566A9C68.7090007@mg-soft.si> To: Ladislav Lhotka , Jernej Tuljak X-Mailer: Apple Mail (2.2104) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] derived-from() and derived-from-or-self() arguments X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 11:25:27 -0000 Thanks all. > On 11 Dec 2015, at 09:50, Jernej Tuljak wrote: >=20 > Ladislav Lhotka je 11.12.2015 ob 9:55 napisal: >>=20 >> A code that evaluating these functions needs to know a lot about the = underlying YANG data model anyway, so I think it is no problem to = resolve arbitrary QNames. I am thus in favour of William's proposal. I like the idea of just thinking of it as a QName. This also suggests a = general principle that any future functions that needed to refer to = types, identities etc would use QNames? > If there are no existing functions that take a prefixed string = literal, why not simply replace the module name argument with a prefix = string? I don't see why a module name needs to be used here at all = either - in fact, it seems to be promoting the idea of breaking out of = module containment using XPath instead of discouraging it - you should = not be able to refer to an identity if it is not defined within an = imported or the enclosing module. I assume that "module name" always meant "prefix" because otherwise how = would one deal with namespaces and revisions? Using a QName clarifies = that it's a prefix. William= From nobody Fri Dec 11 03:32:13 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3143C1A8948; Fri, 11 Dec 2015 03:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 XU6bAHwvSs0x; Fri, 11 Dec 2015 03:32:07 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC5F1A8949; Fri, 11 Dec 2015 03:32:06 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B7E47F68; Fri, 11 Dec 2015 12:32:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 0tYmV3m987vi; Fri, 11 Dec 2015 12:32:04 +0100 (CET) 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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 11 Dec 2015 12:32:04 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BBCFE20058; Fri, 11 Dec 2015 12:32:03 +0100 (CET) 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 BOeQffE-nToc; Fri, 11 Dec 2015 12:32:02 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A2C220055; Fri, 11 Dec 2015 12:32:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E32DC392D7C4; Fri, 11 Dec 2015 12:31:59 +0100 (CET) Date: Fri, 11 Dec 2015 12:31:58 +0100 From: Juergen Schoenwaelder To: Nadeau Thomas Message-ID: <20151211113156.GA43862@elstar.local> Mail-Followup-To: Nadeau Thomas , netmod WG , Benoit Claise , RTG YANG Design Team References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: Cc: Benoit Claise , RTG YANG Design Team , netmod WG Subject: Re: [netmod] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 11:32:09 -0000 On Wed, Dec 09, 2015 at 08:27:04AM -0800, Nadeau Thomas wrote: > > This email initiates a NETMOD WG Last call for draft-ietf-netmod-acl-model-06. > Please review the draft and make any comments to the list by Wednesday, 16 December, 2015 > by 8AM EST. > Technical - I am not sure I personally like the acl-oper-data and ace-oper-data containers in the middle of the config true tree. I understand that operational state in this case is likely tightly bound to the lifetime of the config state but I also generally prefer to have a clean separation of config from state. But since I am not implementing this, I am happy to leave the decision to those who write the code. - I would probably have used src-ipv4-prefix and dst-ipv4-prefix instead of source-ipv4-network and destination-ipv4-network and I would probably have used src-mac-address and src-mac-address-mask and dst-mac-address and dst-mac-address-mask. Generally simple src instead source and dst instead destination - lines up all much more nicely. - I would have put the acl-name and acl-type first followed by the entries list. - I also wonder why we use both the term 'entry' and 'rule', why not pick one of them? You have for example rule-name (which is the key of the list but again comes last). - Should there be features for ace-eth and ace-ipv4 and ace-ipv6 or do we expect that all implementations will always support all three? Another option would be to have the generic model completely without any protocol specific elements and to have separate models to augment in ipv4, ipv6, and ethernet specific ace types. I actually think this would make much more sense since you would not have a module 'packet fields' but instead a clear extension of the ietf-access-control-list module. You could also drop the examples how to extend the core model since the ip and ethernet extensions would already serve the purpose. You also would not need features since an implementation advertises the extension modules. - The 'uses packet-fields:metadata' resolves to a leaf 'input-interface' which is of type string. Is this the only metadata field we ever envision to be there? If so, why not make it part of the base model? If not, what is the extensibility model here? And should the interface reference not use a more specific type than 'string'? - Some implementations support the action to jump or goto other acls. Is this not common enough to include it as a base action, perhaps protected by a feature? - In the example in section 4.3, does the CLI shown really help much? The syntax is pretty system specific. In the XML shown, can you not leave out all the fields that are not set? This would remove a lot of noise. I do not understand what having both actions deny and permit at the same time means. Did you validate the example against the data model? (I also find the keys at the end somewhat strange and not that NETCONF XML serialization actually requires the keys to be sent first.) - The clarification whether the boundary port numbers are included in a port range should be in the YANG model. The YANG model should also say what it means if one of the ranges is not present. We should not define the semantics by examples. - I do not understand section 5. It shows some nftables syntax but does not really shed a light on what the example shown does or how that maps to the YANG data model. So I am left somewhat clueless. - Can I trigger multiple actions from an ace? Or do I have to replicate the ace to do that? In general, there is extension of a choice (means one of several) and there are extension of a choice already present. - Empty description statements or descriptions statements "(null)" need to be fixed. - I am a bit surprised that we do not define how to attach an ACL to an interfaces or a set of interfaces given that we do have an interfaces YANG data model. The example given in A.3 makes me wonder why there should be a counter in the interfaces config tree. The targets/interface-name back-reference seems to indicate that I can attach an ACL only to a single interface. - I do not understand A.4 at all. Defining an identity does not make the choice work differently. - Has someone tried to implement this? Organization - Section 3 to a large extend is a repetition of section 1. Perhaps make section 1 shorter and leave the details to section 3? - Some empty lines in the YANG definition would have pleased my eyes. Editorial - there are a couple of missing articles throughout the text - sometimes singular/plural is at odds - s/this draft/this document/ - you may add another 'e' to my name ;-) /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 Dec 11 04:06:27 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB301A8A64 for ; Fri, 11 Dec 2015 04:06:26 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 6PJ-IOVjQ1SR for ; Fri, 11 Dec 2015 04:06:25 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC281A8A55 for ; Fri, 11 Dec 2015 04:06:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 441911E5A36; Fri, 11 Dec 2015 04:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HXL0ffNRNy6C; Fri, 11 Dec 2015 04:06:03 -0800 (PST) Received: from [192.168.1.129] (host5-81-222-81.range5-81.btcentralplus.com [5.81.222.81]) by c8a.amsl.com (Postfix) with ESMTPSA id B4BF21E5A35; Fri, 11 Dec 2015 04:06:02 -0800 (PST) From: William Lupton Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Dec 2015 12:06:21 +0000 To: netmod@ietf.org Message-Id: <9E945837-9041-48E5-BBDA-6F629F9E9047@broadband-forum.org> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [netmod] Broadband Forum questions on RFC 6020bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 12:06:26 -0000 All, Here are a couple of questions from the Broadband Forum on RFC = 6020bis-08 and draft-ietf-netconf-yang-library-02. Thanks, William -------- 1. RFC 6020bis and updating modules 6020bis Section 11 (Updating a Module) lists all the ways in which a = definition can be revised, but it's not clear whether this is intended = to be an exhaustive list or just to illustrate the principle of allowing = the value space to be broadened. If the latter then presumably other = changes that adhere to this principle would also be valid. For example, it seems that the following might also be permitted: a. Extending a "when" statement so it is true for a wider set of = conditions (example: realising that an RFC 7223 interface object applies = to additional interface types). b. Re-writing a "when" statement to use a base identity rather than an = explicit list of identities (with no change to the conditions for which = it is true). c. Converting a leaf node to a choice (with no change to default = behaviour). 2. ietf-yang-library and reporting submodules As we understand them, submodules have no impact on a module's external = interface, and (6020 Section 11) "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 other way than allowed here". draft-ietf-netconf-yang-library-02 says (Section 1) "submodule list: The = name and revision of each submodule used by the module MUST be = identified" but the YANG module's "submodules" container appears not to = be mandatory. Is it intended that the submodules MUST be listed? If so, what is the = rationale for requiring this?= From nobody Fri Dec 11 04:41:10 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F521A9238 for ; Fri, 11 Dec 2015 04:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 nbYQrSrLSwjq for ; Fri, 11 Dec 2015 04:41:07 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5381A910F for ; Fri, 11 Dec 2015 04:41:07 -0800 (PST) Received: from localhost (unknown [173.38.220.62]) by mail.tail-f.com (Postfix) with ESMTPSA id 9DD711AE098B; Fri, 11 Dec 2015 13:41:04 +0100 (CET) Date: Fri, 11 Dec 2015 13:41:05 +0100 (CET) Message-Id: <20151211.134105.1834516894657485640.mbj@tail-f.com> To: wlupton@broadband-forum.org From: Martin Bjorklund In-Reply-To: <9E945837-9041-48E5-BBDA-6F629F9E9047@broadband-forum.org> References: <9E945837-9041-48E5-BBDA-6F629F9E9047@broadband-forum.org> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Broadband Forum questions on RFC 6020bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 12:41:08 -0000 Hi, William Lupton wrote: > All, > > Here are a couple of questions from the Broadband Forum on RFC > 6020bis-08 and draft-ietf-netconf-yang-library-02. > > Thanks, > William > > -------- > > 1. RFC 6020bis and updating modules > > 6020bis Section 11 (Updating a Module) lists all the ways in which a > definition can be revised, but it's not clear whether this is intended > to be an exhaustive list or just to illustrate the principle of > allowing the value space to be broadened. If the latter then > presumably other changes that adhere to this principle would also be > valid. The former. > For example, it seems that the following might also be permitted: > > a. Extending a "when" statement so it is true for a wider set of > conditions (example: realising that an RFC 7223 interface object > applies to additional interface types). This is allowed by: o A "when" statement may be removed or its constraint relaxed. > b. Re-writing a "when" statement to use a base identity rather than an > explicit list of identities (with no change to the conditions for > which it is true). Same as above. > c. Converting a leaf node to a choice (with no change to default > behaviour). This is not allowed, but maybe it should. I.e., it should be ok to wrap a node that is not a mandatory node (see terminology) in a choice (+ case). > 2. ietf-yang-library and reporting submodules > > As we understand them, submodules have no impact on a module's > external interface, and (6020 Section 11) "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 other way than allowed > here". > > draft-ietf-netconf-yang-library-02 says (Section 1) "submodule list: > The name and revision of each submodule used by the module MUST be > identified" but the YANG module's "submodules" container appears not > to be mandatory. A container cannot be mandatory. > Is it intended that the submodules MUST be listed? Yes, that's what the text "The name and revision of each submodule used by the module MUST be identified" says. > If so, what is the rationale for requiring this? The module may have used include w/o revision. Unless the submodule is listed by the server, the client won't know which revision the server uses. /martin From nobody Fri Dec 11 04:52:16 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796491A1BC0 for ; Fri, 11 Dec 2015 04:52:15 -0800 (PST) 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 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 vH9nB2b93dGG for ; Fri, 11 Dec 2015 04:52:14 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1900:3001:11::28]) by ietfa.amsl.com (Postfix) with ESMTP id 8F26A1A00BF for ; Fri, 11 Dec 2015 04:52:14 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 208A41E5A36; Fri, 11 Dec 2015 04:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RQdaiHrATm5d; Fri, 11 Dec 2015 04:51:53 -0800 (PST) Received: from [192.168.1.129] (host5-81-222-81.range5-81.btcentralplus.com [5.81.222.81]) by c8a.amsl.com (Postfix) with ESMTPSA id 6DD171E5A35; Fri, 11 Dec 2015 04:51:52 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=us-ascii From: William Lupton In-Reply-To: <20151211.134105.1834516894657485640.mbj@tail-f.com> Date: Fri, 11 Dec 2015 12:52:11 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9E945837-9041-48E5-BBDA-6F629F9E9047@broadband-forum.org> <20151211.134105.1834516894657485640.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.2104) Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Broadband Forum questions on RFC 6020bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 12:52:15 -0000 Thanks for the clarifications. A few follow-ups below. Cheers, W. >> a. Extending a "when" statement so it is true for a wider set of >> conditions (example: realising that an RFC 7223 interface object >> applies to additional interface types). >=20 > This is allowed by: >=20 > o A "when" statement may be removed or its constraint relaxed. OK. I see this for "must" but not for "when"; in 08 I can find only one = instance of "relax". >> c. Converting a leaf node to a choice (with no change to default >> behaviour). >=20 > This is not allowed, but maybe it should. I.e., it should be ok to > wrap a node that is not a mandatory node (see terminology) in a choice > (+ case). OK. Maybe this already happened but perhaps it would be worth checking = whether there are any other cases that could/should be included (given = that the list is exhaustive)? > A container cannot be mandatory. OK! I should have phrased it more loosely. But you answered the basic = question, which was whether listing the submodules is REQUIRED. Yes it = is. From nobody Fri Dec 11 04:54:07 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976641A1BC0 for ; Fri, 11 Dec 2015 04:54:05 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 gmmi9QIObWNJ for ; Fri, 11 Dec 2015 04:54:04 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 395A41A1A9B for ; Fri, 11 Dec 2015 04:54:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id C4A2F1E5A36; Fri, 11 Dec 2015 04:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id AXfF1QVceo_M; Fri, 11 Dec 2015 04:53:42 -0800 (PST) Received: from [192.168.1.129] (host5-81-222-81.range5-81.btcentralplus.com [5.81.222.81]) by c8a.amsl.com (Postfix) with ESMTPSA id 414AA1E5A35; Fri, 11 Dec 2015 04:53:42 -0800 (PST) From: William Lupton Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Dec 2015 12:54:02 +0000 To: netmod@ietf.org Message-Id: <2431FE7A-9CC9-48A6-92FF-AE383DB71394@broadband-forum.org> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [netmod] Broadband Forum questions on RFC 6087bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 12:54:05 -0000 All, Here are some questions / comments from the Broadband Forum on RFC = 6087bis-05. Thanks, William -------- 1. Potentially confusing use of the term "prefix" Section 5.1 (Module Naming Conventions) talks about prefixes but in this = context means "strings at the beginning of module names" rather than = YANG prefixes that are the topic of Section 5.2. This could (and did!) = cause confusion. 2. Rules re changing submodule names Section 5.7 (Lifecycle Management) says that "The [...] submodule name = MUST NOT be changed, once the document containing the module or = submodule is published" but this might contradict RFC 6020 Section 11, = which says "A module may be split into a set of submodules, or a = submodule may be removed...". More specifically, 6020 doesn't mention renaming a submodule (so = presumably that's not permitted), but the mention of both splitting = modules into submodules AND removing submodules suggests that arbitrary = module/submodule refactoring is permitted. And if I'm being pedantic, = revision #1 could have submodule A1, revision #2 could remove it, and = revision #3 could reintroduce it as submodule A2, so that's effectively = a rename! 3. References to RPCs need also to mention actions In most (or all?) places that RPCs are mentioned, presumably actions = need to be mentioned? 4. Implications of adding defaults Section 5.12 (Reusable Type Definitions) says that "If an appropriate = default value can be associated with the desired semantics, then a = default statement SHOULD be present". Is it correct that adding a = default effectively adds a MANDATORY requirement for a server to support = the default value for that node, and therefore to support the concept = modelled by the node (albeit only with the default behaviour)? Whereas = if there were no default then there would be no requirement at all to = support the concept modelled by that node? If so, then adding a default = seems like something that shouldn't be done lightly... or am I making = too much of this? 5. Guidance re YANG features 6087 doesn't always refer to features consistently. For example Section = 5.5 (Conditional Statements) says "If a data definition is optional, = depending on server support for a NETCONF protocol capability, then a = YANG 'feature' statement SHOULD be defined" (which seems to tie the = "feature" concept to NETCONF protocol capabilities), whereas Section = 5.17 (Feature Definitions) says "The YANG "feature" statement is used to = define a label for a set of optional functionality within a module". The = latter description seems more in keeping with the spirit of 6020, so = perhaps the former text could be adjusted to align with it? 6. Guidance re YANG deviations The 6020 discussion of deviations is mostly about implementing LESS = rather than MORE. Obviously the deviate statement's "add" argument is = described (and there is an example) but there seems to be no discussion = that use of deviate with "add" might be a GOOD thing. The 6087 discussion of deviations says that they can be useful for = documenting server capabilities but again the emphasis seems to be on = documenting implementing LESS rather than MORE. The result seems to be that deviations have a bad name. If indeed there = are accepted good uses of deviations then it would be good if this was = made clearer, both in 6020 and in 6087.= From nobody Fri Dec 11 04:59:52 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 350041A8A85 for ; Fri, 11 Dec 2015 04:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 brqdSH7_jLKO for ; Fri, 11 Dec 2015 04:59:50 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 116861A6EE4 for ; Fri, 11 Dec 2015 04:59:50 -0800 (PST) Received: from localhost (unknown [173.38.220.62]) by mail.tail-f.com (Postfix) with ESMTPSA id 202BA1AE098B; Fri, 11 Dec 2015 13:59:49 +0100 (CET) Date: Fri, 11 Dec 2015 13:59:50 +0100 (CET) Message-Id: <20151211.135950.1552677235018345615.mbj@tail-f.com> To: wlupton@broadband-forum.org From: Martin Bjorklund In-Reply-To: References: <9E945837-9041-48E5-BBDA-6F629F9E9047@broadband-forum.org> <20151211.134105.1834516894657485640.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] Broadband Forum questions on RFC 6020bis X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 12:59:51 -0000 William Lupton wrote: > Thanks for the clarifications. A few follow-ups below. Cheers, W. > > >> a. Extending a "when" statement so it is true for a wider set of > >> conditions (example: realising that an RFC 7223 interface object > >> applies to additional interface types). > > > > This is allowed by: > > > > o A "when" statement may be removed or its constraint relaxed. > > OK. I see this for "must" but not for "when"; in 08 I can find only > one instance of "relax". Aha, I was looking at the upcomign -09 - this was already pointed out by Andy and fixed. Sorry for the confusion. > >> c. Converting a leaf node to a choice (with no change to default > >> behaviour). > > > > This is not allowed, but maybe it should. I.e., it should be ok to > > wrap a node that is not a mandatory node (see terminology) in a choice > > (+ case). > > OK. Maybe this already happened but perhaps it would be worth checking > whether there are any other cases that could/should be included (given > that the list is exhaustive)? Yes, this is why we need reviewers, so thanks for spotting this! > > A container cannot be mandatory. > > OK! I should have phrased it more loosely. But you answered the basic > question, which was whether listing the submodules is REQUIRED. Yes it > is. /martin From nobody Fri Dec 11 05:00:11 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99A5C1A8A96 for ; Fri, 11 Dec 2015 05:00:09 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 rWy4o6DE3Lua for ; Fri, 11 Dec 2015 05:00:08 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id BDEFD1A6EE4 for ; Fri, 11 Dec 2015 05:00:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 50EE71E5A35; Fri, 11 Dec 2015 04:59:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5X5vWcs2LuLQ; Fri, 11 Dec 2015 04:59:47 -0800 (PST) Received: from [192.168.1.129] (host5-81-222-81.range5-81.btcentralplus.com [5.81.222.81]) by c8a.amsl.com (Postfix) with ESMTPSA id C38D31E5A36; Fri, 11 Dec 2015 04:59:46 -0800 (PST) From: William Lupton Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Dec 2015 13:00:06 +0000 To: netmod@ietf.org Message-Id: <3D09C93F-EA97-4E60-B89C-E077CA1DD66B@broadband-forum.org> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [netmod] Broadband Forum intention of using ietf-entity YANG module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 13:00:09 -0000 All, The Broadband Forum would like to use the ietf-entity YANG module = (currently draft-entitydt-netmod-entity) for equipment management but we = are a bit concerned about its draft status and its dependence on YANG = 1.1. Any advice or reassurance? Thanks, William= From nobody Fri Dec 11 05:41:12 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5D31ACEE3 for ; Fri, 11 Dec 2015 05:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 jPdNn-E6RrJJ for ; Fri, 11 Dec 2015 05:41:08 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 3EC0A1ACEDA for ; Fri, 11 Dec 2015 05:41:07 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 9E54E73B88928; Fri, 11 Dec 2015 13:41:03 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id tBBDf4NL023941 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 11 Dec 2015 14:41:05 +0100 Received: from FR712WXCHMBA13.zeu.alcatel-lucent.com ([169.254.5.200]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Fri, 11 Dec 2015 14:40:50 +0100 From: "GUBALLA, JENS (JENS)" To: Ladislav Lhotka Thread-Topic: [netmod] How to model a leafref in union conforming to RFC6020? Thread-Index: AdEz9oAIA2bEc2jiS3etOwkqv3A8AQAAvCYAAAeC7EA= Date: Fri, 11 Dec 2015 13:40:50 +0000 Message-ID: <547EE95EB794FD4DB8062F7A4C86D0BC4A3A33BB@FR712WXCHMBA13.zeu.alcatel-lucent.com> References: <547EE95EB794FD4DB8062F7A4C86D0BC4A3A3184@FR712WXCHMBA13.zeu.alcatel-lucent.com> <35171113-FCC6-4CF9-A37F-0E6E27EEA624@nic.cz> In-Reply-To: <35171113-FCC6-4CF9-A37F-0E6E27EEA624@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0299_01D13421.ECDDA990" MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] How to model a leafref in union conforming to RFC6020? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 13:41:10 -0000 ------=_NextPart_000_0299_01D13421.ECDDA990 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Lada, > -----Original Message----- > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > Sent: Freitag, 11. Dezember 2015 11:51 > To: GUBALLA, JENS (JENS) > Cc: netmod@ietf.org > Subject: Re: [netmod] How to model a leafref in union conforming to > RFC6020? > > > > On 11 Dec 2015, at 10:29, GUBALLA, JENS (JENS) lucent.com> wrote: > > > > Hi, > > > > According to RFC6020 a leafref within a union is not allowed. This > > issue is captured by Y30 of the yang1.1 issue list. > > > > My question: how can such a construct as show below be modeled > > conforming to RFC6020? > > > > leaf the_reference {type uint8;} > > leaf something { > > type union { > > type leafref { > > path "../the_reference"; > > } > > type enumeration { > > enum "none"; > > enum "something-else"; > > } > > } > > } > > > > Has anyone any ideas or can someone provide me a pointer if this has > > been discussed already? > > You can define the first union member simply as uint8, without being > formally coupled with "the_reference". I'd suggest to use YANG 1.1 > though where that CLR was removed. [JG] Thanks a lot for your suggestions. Replacing "type leafref" by "type unit8" would mean to lose the semantic of the leafref type. Thus 5 4 would unfortunately be regarded as compliant to the model. On the other hand the data model should be Yang1.0 compliant. So I want to check if there is any other solution to the issue. Best regards, Jens > > Lada > > > > > Thanks, > > Jens > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > ------=_NextPart_000_0299_01D13421.ECDDA990 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIP/DCCA7Ew ggKZoAMCAQICEBErBTlXKN63QvT+VRPTt1EwDQYJKoZIhvcNAQEFBQAwQzEXMBUGA1UEChMOQWxj YXRlbCBMdWNlbnQxKDAmBgNVBAMTH0FsY2F0ZWwgTHVjZW50IEludGVybmFsIFJvb3QgQ0EwHhcN MDgxMTAzMTU0MTE2WhcNMjgxMTAzMTU0MTE2WjBDMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEo MCYGA1UEAxMfQWxjYXRlbCBMdWNlbnQgSW50ZXJuYWwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAL5IGBVth8afQdnpuLDI0Z37GgIcPWznOOzFJUV1gVbztqQ5CIxkVL4K soAfLzc8LQHqNl2Nk3YbVBputIyCe2nzGsRjQeVt+HO2PV7h2YpMQlVd+XGsmpJ4fAP3A38wkTl6 tFPAYspyUFvjNON1J3BJE/2cuY7apvn9ZfSz99x7y4QBZh3hvm4g5Fn7mK04/q7K6O4Z8Y6zkSxG ZFNyZ6NIuAPNCODZASqYnHiAgtEcCR4WPs6rj+Y8MU0q56ddwuIZ0qeP2ScHY0wVtnmqXzHyCzEQ Eb2eJCsGpXFwUalVaxPUZEVoVDfjO+2ZN5gNJrGMTu7Mv9k1WG0LR3zZ1QsCAwEAAaOBoDCBnTAL BgNVHQ8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUB6yyWvZhiXxcfOvilycpaQyK H/AwEAYJKwYBBAGCNxUBBAMCAQAwTAYDVR0gBEUwQzBBBgRVHSAAMDkwNwYIKwYBBQUHAgEWK2h0 dHA6Ly93d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9jcC9jcC5odG0wDQYJKoZIhvcNAQEFBQAD ggEBADBMWG3WQyC6+mBzuuFuCGqJAiC4v+TQ3ZErd5KKSRGh8dwjzK5L2C51wJPVe6EAjb59CEb2 p2aPKSkoMrCC8seBRM/bs23DMyna1Jr9Q5EZDrmRqBLJy3Cs8NFpa/cKb6SkegFHcB/vi+SYgSdR BwoNE5+y6MRPXcEBadI/9W8Zlkk5sJ3w55e+i8OCNg/fDYAQuJPa+hD3/byWGxUgGSMNGQ/GS2st NETAa5Z/88Sh9FHk2BtrxSz7jPtekKhjsidD2ANJZTCyj9iRB+Nt9FEetNpcN6ke1FlepRbCsV10 I0y6weLwZ34h2GWbN9qEOSQV88NBA149a5ugJ/oCbHEwggTdMIIDxaADAgECAgoanQrOAAAAAAAG MA0GCSqGSIb3DQEBBQUAMEMxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MSgwJgYDVQQDEx9BbGNh dGVsIEx1Y2VudCBJbnRlcm5hbCBSb290IENBMB4XDTA4MTEyMTIxNTcyOFoXDTE4MTEyMTIyMDcy OFowgYUxEzARBgoJkiaJk/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJ kiaJk/IsZAEZFgRuYTAyMRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRl bCBMdWNlbnQgSW50ZXJuYWwgU3ViIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA 2Ocmcli3LbVU6TRh+JLMtquBr5/grS+gzfN5YL/lauFCHmDlF7kNQvxtDWqwNpOkzb97CwWcVsdf kyWAiGzVWeRIrYGhK/xNPFRYXOKYXLGqxFWkltZkYpSRudHzjTneUC4EVdMXnREMu8FTC0CM38Vb xMvQ+ygjEyicg2QT9lZHWkKP9kCI1818P+AmS7905t6kXR9Q2m1GjcCa0KqARPGX/xe2toQS+Vdi UwDary1Enk8j19KFmvFg1bhY2mNSHgzN2AWnhsOi/EID1SalzBwHylByB/UbbEv2dZUsAdMuOtYt Z/8dM1axS0d3fW7q7mAYV5uM42mYX9o1B/RzjwIDAQABo4IBjjCCAYowDwYDVR0TAQH/BAUwAwEB /zAdBgNVHQ4EFgQU2exrvZZYIvfYpnfN/k2B77qXvRIwCwYDVR0PBAQDAgHGMBAGCSsGAQQBgjcV AQQDAgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMB8GA1UdIwQYMBaAFAesslr2YYl8XHzr 4pcnKWkMih/wMHgGA1UdHwRxMG8wbaBroGmGOWh0dHA6Ly9zZXJ2aWNlcy5zdXBwb3J0LmFsY2F0 ZWwtbHVjZW50LmNvbS9QS0kvcm9vdENBLmNybIYsaHR0cDovL3d3dy5hbGNhdGVsLWx1Y2VudC5j b20vUEtJL3Jvb3RDQS5jcmwwgYIGCCsGAQUFBwEBBHYwdDA4BggrBgEFBQcwAoYsaHR0cDovL3d3 dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3Jvb3RDQS5jcnQwOAYIKwYBBQUHMAKGLGh0dHA6Ly93 d3cuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9yb290Q0EuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCl GxDp5Z1IDjIEz8VaTEWa8Q1OWUbXwsszdoNg5Gg3F1a2VFFVegmsrpt4axbESlgE6AT/rkUUiyjb EhcUgY2OHdeKN5Gc7VOGh9D7SER9peARwSwx4NYRrsIaRXDrUswWAM6T6ilDUogjKYk3uK2zZ6Vy 7z3JewxVlhpeSsNPQSMoyNibKkYLRoh6rvz94vB0mvcT0uVx7xowPNoTOjjGRAk4J/MBaNOupvwf RfPmwRetdnD6NC5x8aRkhr4ZNBjvYxFT8IJaeLk8piQYMPRDlzi7dlb9d6C5WuC0LRpomk2r3bd6 /XpNOx2FyG18axeeASWtENgPvqEirM5MjwkCMIIHYjCCBkqgAwIBAgIKE1mSVAAAAADt+zANBgkq hkiG9w0BAQUFADCBhTETMBEGCgmSJomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2Vu dDEUMBIGCgmSJomT8ixkARkWBG5hMDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQD Ex5BbGNhdGVsIEx1Y2VudCBJbnRlcm5hbCBTdWIgQ0EwHhcNMTUwNDI0MDYyNDM5WhcNMTcwNDIz MDYyNDM5WjBCMRAwDgYDVQQDEwdsdnBzYWFlMS4wLAYJKoZIhvcNAQkBFh9qZW5zLmd1YmFsbGFA YWxjYXRlbC1sdWNlbnQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuZZTGrNK 9hSyYEI9w2lnABbWQBeU1DyJ9jX33JSOfgMGYaQ0ZZZFRwX5vDIgj499CxaWmpImbQTxdYa/vxpS U7SfqtYF7B2AB2irUYdCu/GGjTqHaXmPyyktPaiEOgR7AOz8oXxUdaECsKmTBANOpkE1J6yA3KPJ Yxde3h5bTqnjxvJB5IJhr9rIvcf5V3v6ZyW0MHOkDXn20xjEDJVMVdhhjlnwM4WmUiA/SNq7IiQ8 elmivF5NuEK9mwZEXqkR6aXHVcgPc1fuMxwsxJbdfdmMyIDV62kSTVlb/iXNJDByQJ/GRnuYHCFA qIld1HgdJCpECl+ohveGLG46CvD6iwIDAQABo4IEFDCCBBAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIhb3FWYPjsTmHpYEqhr/DQoWUmBmBC/nmTIT9tVoCAWQCAQUwHwYDVR0lBBgwFgYKKwYB BAGCNwoDBAYIKwYBBQUHAwQwCwYDVR0PBAQDAgWgMCkGCSsGAQQBgjcVCgQcMBowDAYKKwYBBAGC NwoDBDAKBggrBgEFBQcDBDBEBgkqhkiG9w0BCQ8ENzA1MA4GCCqGSIb3DQMCAgIAgDAOBggqhkiG 9w0DBAICAIAwBwYFKw4DAgcwCgYIKoZIhvcNAwcwHQYDVR0OBBYEFPUv0vuw2MQvQ81rxR/PDOlK po4KMB8GA1UdIwQYMBaAFNnsa72WWCL32KZ3zf5Nge+6l70SMIIBXQYDVR0fBIIBVDCCAVAwggFM oIIBSKCCAUSGgdlsZGFwOi8vL0NOPUFsY2F0ZWwlMjBMdWNlbnQlMjBJbnRlcm5hbCUyMFN1YiUy MENBLENOPXVzbmF2c3BraTAzcCxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz1sdWFkLERDPWx1Y2VudCxEQz1jb20/Y2VydGlm aWNhdGVSZXZvY2F0aW9uTGlzdD9iYXNlP29iamVjdENsYXNzPWNSTERpc3RyaWJ1dGlvblBvaW50 hixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNybIY4aHR0cDovL3Nl cnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJDQS5jcmwwggFhBggrBgEF BQcBAQSCAVMwggFPMIHMBggrBgEFBQcwAoaBv2xkYXA6Ly8vQ049QWxjYXRlbCUyMEx1Y2VudCUy MEludGVybmFsJTIwU3ViJTIwQ0EsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENO PVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9bHVhZCxEQz1sdWNlbnQsREM9Y29tP2NBQ2Vy dGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5MDgGCCsGAQUF BzAChixodHRwczovL3d3dy5hbGNhdGVsLWx1Y2VudC5jb20vUEtJL3N1YkNBLmNydDBEBggrBgEF BQcwAoY4aHR0cDovL3NlcnZpY2VzLnN1cHBvcnQuYWxjYXRlbC1sdWNlbnQuY29tL1BLSS9zdWJD QS5jcnQwKgYDVR0RBCMwIYEfamVucy5ndWJhbGxhQGFsY2F0ZWwtbHVjZW50LmNvbTANBgkqhkiG 9w0BAQUFAAOCAQEAXRHvujXQqqJMH1wCrG+0UrRv0v7CpjhIyuLwJ5XDhTj9JcKsYLpWREi/zXhN Sy6TC61uUKLrAuX0uXAXW0zsBYgPDFkq481gTgdxG/brcg8lXF8Xm787ixPR8Mp8j80ZHZ5OnA1k +Xuw/QPsE4wp8RZrjqvoJQpSXtXPdX3+XBE0VsANBYszCWfrR0ByI4hZ9Saoc26umYnOY8sU0UZ/ 1XnEcRfUmVWRxTydYAFdTtOHRjBn3V7TZnfeGYpKSxrqdh6nTqk0FR832p8Z8RyNjEv3qdaX9BK7 jsjQgGNH0gxWPf+wARDdk5abnalyChTjv8B70KeLOYbsrF0greiw3TGCBCkwggQlAgEBMIGUMIGF MRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPy LGQBGRYEbmEwMjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVj ZW50IEludGVybmFsIFN1YiBDQQIKE1mSVAAAAADt+zAJBgUrDgMCGgUAoIICaTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMTExMzQwNDhaMCMGCSqGSIb3DQEJ BDEWBBRRaTgPNLUD5wJL4aySudcInidZ5zCBpQYJKwYBBAGCNxAEMYGXMIGUMIGFMRMwEQYKCZIm iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy bmFsIFN1YiBDQQIKE1mSVAAAAADt+zCBpwYLKoZIhvcNAQkQAgsxgZeggZQwgYUxEzARBgoJkiaJ k/IsZAEZFgNjb20xFjAUBgoJkiaJk/IsZAEZFgZsdWNlbnQxFDASBgoJkiaJk/IsZAEZFgRuYTAy MRcwFQYDVQQKEw5BbGNhdGVsIEx1Y2VudDEnMCUGA1UEAxMeQWxjYXRlbCBMdWNlbnQgSW50ZXJu YWwgU3ViIENBAgoTWZJUAAAAAO37MIG3BgkqhkiG9w0BCQ8xgakwgaYwCwYJYIZIAWUDBAEqMAsG CWCGSAFlAwQBFjAKBggqhkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAsGCWCGSAFlAwQCAzAL BglghkgBZQMEAgIwCwYJYIZIAWUDBAIBMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAH2j YjYK/Lp+3bzrqTTFERbz/QfDDLvZ33c9ztH9MwLTcq+rLHyr2OxrZwmWKZqhStLqRCHOAeO2nKq8 cCMDeYPTAfHQpLt3dhivQ7YntTBvuQAbf7lRAsxjWAo6bnpJFwNisbeOI0wpAjxVyeTCEcrGT0JG pc+3v1iNMKmdudXK7K3vWLGbVlFtpgr7pfL4oVtbpjfwKMcsEz1mpKx+Y4OLCfVT1EXMK2uuAjYJ XW7CE3iZuxN0qrpxyajvBiPjlTZhoizKi9HBlXpI78U0lLm/A5jJ8FYYxHnyug7B6PrGhkThForE HqMWZ/dHvE943bLFoSNxhq1TrBleEbXYQsgAAAAAAAA= ------=_NextPart_000_0299_01D13421.ECDDA990-- From nobody Fri Dec 11 05:50:24 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C9ED1A9071 for ; Fri, 11 Dec 2015 05:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 gF-GpIe-2m6p for ; Fri, 11 Dec 2015 05:50:21 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 63EC41A1B89 for ; Fri, 11 Dec 2015 05:50:21 -0800 (PST) Received: from localhost (unknown [173.38.220.62]) by mail.tail-f.com (Postfix) with ESMTPSA id 4B2281AE098B; Fri, 11 Dec 2015 14:50:19 +0100 (CET) Date: Fri, 11 Dec 2015 14:50:20 +0100 (CET) Message-Id: <20151211.145020.1897926527841042702.mbj@tail-f.com> To: jens.guballa@alcatel-lucent.com From: Martin Bjorklund In-Reply-To: <547EE95EB794FD4DB8062F7A4C86D0BC4A3A33BB@FR712WXCHMBA13.zeu.alcatel-lucent.com> References: <547EE95EB794FD4DB8062F7A4C86D0BC4A3A3184@FR712WXCHMBA13.zeu.alcatel-lucent.com> <35171113-FCC6-4CF9-A37F-0E6E27EEA624@nic.cz> <547EE95EB794FD4DB8062F7A4C86D0BC4A3A33BB@FR712WXCHMBA13.zeu.alcatel-lucent.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] How to model a leafref in union conforming to RFC6020? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 13:50:22 -0000 "GUBALLA, JENS (JENS)" wrote: > Hi Lada, > > > -----Original Message----- > > From: Ladislav Lhotka [mailto:lhotka@nic.cz] > > Sent: Freitag, 11. Dezember 2015 11:51 > > To: GUBALLA, JENS (JENS) > > Cc: netmod@ietf.org > > Subject: Re: [netmod] How to model a leafref in union conforming to > > RFC6020? > > > > > > > On 11 Dec 2015, at 10:29, GUBALLA, JENS (JENS) > lucent.com> wrote: > > > > > > Hi, > > > > > > According to RFC6020 a leafref within a union is not allowed. This > > > issue is captured by Y30 of the yang1.1 issue list. > > > > > > My question: how can such a construct as show below be modeled > > > conforming to RFC6020? > > > > > > leaf the_reference {type uint8;} > > > leaf something { > > > type union { > > > type leafref { > > > path "../the_reference"; > > > } > > > type enumeration { > > > enum "none"; > > > enum "something-else"; > > > } > > > } > > > } > > > > > > Has anyone any ideas or can someone provide me a pointer if this has > > > been discussed already? > > > > You can define the first union member simply as uint8, without being > > formally coupled with "the_reference". I'd suggest to use YANG 1.1 > > though where that CLR was removed. > [JG] Thanks a lot for your suggestions. Replacing "type leafref" by "type > unit8" would mean to lose the semantic of the leafref type. Thus > > 5 > 4 > > would unfortunately be regarded as compliant to the model. > > On the other hand the data model should be Yang1.0 compliant. So I want to > check if there is any other solution to the issue. Another common way to handle this is to do a choice of two leafs: choice s { leaf something-as-leafreaf { type leafreaf ... } leaf something-as-enum { ... } } /martin From nobody Fri Dec 11 05:58:17 2015 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ECF81ACE6D for ; Fri, 11 Dec 2015 05:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 q62jXOY33t1y for ; Fri, 11 Dec 2015 05:58:13 -0800 (PST) Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFEA1ACE62 for ; Fri, 11 Dec 2015 05:58:13 -0800 (PST) Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 46F64C4175C1; Fri, 11 Dec 2015 14:58:12 +0100 (CET) To: "GUBALLA, JENS (JENS)" , Ladislav Lhotka References: <547EE95EB794FD4DB8062F7A4C86D0BC4A3A3184@FR712WXCHMBA13.zeu.alcatel-lucent.com> <35171113-FCC6-4CF9-A37F-0E6E27EEA624@nic.cz> <547EE95EB794FD4DB8062F7A4C86D0BC4A3A33BB@FR712WXCHMBA13.zeu.alcatel-lucent.com> From: Jernej Tuljak Message-ID: <566AD66F.8070108@mg-soft.si> Date: Fri, 11 Dec 2015 14:58:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <547EE95EB794FD4DB8062F7A4C86D0BC4A3A33BB@FR712WXCHMBA13.zeu.alcatel-lucent.com> Content-Type: multipart/alternative; boundary="------------050107060900020502050501" Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] How to model a leafref in union conforming to RFC6020? X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Dec 2015 13:58:16 -0000 This is a multi-part message in MIME format. --------------050107060900020502050501 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit GUBALLA, JENS (JENS) je 11.12.2015 ob 14:40 napisal: > Hi Lada, > >> -----Original Message----- >> From: Ladislav Lhotka [mailto:lhotka@nic.cz] >> Sent: Freitag, 11. Dezember 2015 11:51 >> To: GUBALLA, JENS (JENS) >> Cc: netmod@ietf.org >> Subject: Re: [netmod] How to model a leafref in union conforming to >> RFC6020? >> >> >>> On 11 Dec 2015, at 10:29, GUBALLA, JENS (JENS) > lucent.com> wrote: >>> Hi, >>> >>> According to RFC6020 a leafref within a union is not allowed. This >>> issue is captured by Y30 of the yang1.1 issue list. >>> >>> My question: how can such a construct as show below be modeled >>> conforming to RFC6020? >>> >>> leaf the_reference {type uint8;} >>> leaf something { >>> type union { >>> type leafref { >>> path "../the_reference"; >>> } >>> type enumeration { >>> enum "none"; >>> enum "something-else"; >>> } >>> } >>> } >>> >>> Has anyone any ideas or can someone provide me a pointer if this has >>> been discussed already? >> You can define the first union member simply as uint8, without being >> formally coupled with "the_reference". I'd suggest to use YANG 1.1 >> though where that CLR was removed. > [JG] Thanks a lot for your suggestions. Replacing "type leafref" by "type > unit8" would mean to lose the semantic of the leafref type. Thus > > 5 > 4 > > would unfortunately be regarded as compliant to the model. > > On the other hand the data model should be Yang1.0 compliant. So I want to > check if there is any other solution to the issue. Add a (very specific) must constraint to the "something" leaf? Something along the lines of: leaf the_reference {type uint8;} leaf something { must "(not(number()) and not(. = 0)) or . = /the_reference"; type union { type uint8; type enumeration { enum "none"; enum "something-else"; } } } for this particular example. Ugly, yes, but (probably) works. The above requires "not a number or same as 'the_reference'". Jernej > > Best regards, > Jens > >> Lada >> >>> Thanks, >>> Jens >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------050107060900020502050501 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
GUBALLA, JENS (JENS) je 11.12.2015 ob 14:40 napisal:
Hi Lada,


-----Original Message-----
From: Ladislav Lhotka [mailto:lhotka@nic.cz]
Sent: Freitag, 11. Dezember 2015 11:51
To: GUBALLA, JENS (JENS)
Cc: netmod@ietf.org
Subject: Re: [netmod] How to model a leafref in union conforming to
RFC6020?



On 11 Dec 2015, at 10:29, GUBALLA, JENS (JENS) <jens.guballa@alcatel-

lucent.com> wrote:

Hi,

According to RFC6020 a leafref within a union is not allowed. This
issue is captured by Y30 of the yang1.1 issue list.

My question: how can such a construct as show below be modeled
conforming to RFC6020?

   leaf the_reference {type uint8;}
   leaf something {
       type union {
           type leafref {
               path "../the_reference";
           }
           type enumeration {
               enum "none";
               enum "something-else";
           }
       }
   }

Has anyone any ideas or can someone provide me a pointer if this has
been discussed already?

You can define the first union member simply as uint8, without being
formally coupled with "the_reference". I'd suggest to use YANG 1.1
though where that CLR was removed.

[JG] Thanks a lot for your suggestions. Replacing "type leafref" by "type
unit8" would mean to lose the semantic of the leafref type. Thus

    <the_reference>5</the_reference>
    <something>4</something>

would unfortunately be regarded as compliant to the model.

On the other hand the data model should be Yang1.0 compliant. So I want to
check if there is any other solution to the issue.

Add a (very specific) must constraint to the "something" leaf? Something along the lines of:

  leaf the_reference {type uint8;}
  leaf something {
    must "(not(number()) and not(. = 0)) or . = /the_reference";
    type union {
      type uint8;
      type enumeration {
        enum "none";
        enum "something-else";
      }
    }
  }

for this particular example. Ugly, yes, but (probably) works. The above requires "not a number or same as 'the_reference'".

Jernej


Best regards,
Jens


Lada


Thanks,
Jens

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





      

      

      

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


    

    

  


--------------050107060900020502050501--


From nobody Fri Dec 11 06:27:13 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F6D1A8ACC for ; Fri, 11 Dec 2015 06:27:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 5VZo3Lwsatas for ; Fri, 11 Dec 2015 06:27:11 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 9CBC61A6F90 for ; Fri, 11 Dec 2015 06:27:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1449844007; bh=ftGmmOLqv02JCNRvQq1b4Gcw6Y9SFzLJFRcHlTx3XqU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=LgjXJMl+P+LzlbLiyaci1rSDRY3sn+281afa2JAmD5ZkLadG4F3/8W90WiHpOKswF eoBFnfMe5B3GypL2GIZELg5tXB3Jpp2lwix1hfZdkZ8jNkB1o9BeiLJIt13Lo6/qtG 7aIRjCpJgvjIR1ZyENO01fAr2D8ThVMunQpsJ32k=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Nadeau Thomas 
In-Reply-To: <3D09C93F-EA97-4E60-B89C-E077CA1DD66B@broadband-forum.org>
Date: Fri, 11 Dec 2015 09:27:08 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <6E0FC5E2-AC0C-40B8-BB46-44B9877CE39A@lucidvision.com>
References: <3D09C93F-EA97-4E60-B89C-E077CA1DD66B@broadband-forum.org>
To: William Lupton 
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=5 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 210, in=2828, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Broadband Forum intention of using ietf-entity YANG module
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Dec 2015 14:27:12 -0000

	Dependance on 1.1 should not be an issue as that is almost ready =
to be approved. You should be building your model to comply with the 1.1 =
rules.

	=E2=80=94Tom


> On Dec 11, 2015:8:00 AM, at 8:00 AM, William Lupton =
 wrote:
>=20
> All,
>=20
> The Broadband Forum would like to use the ietf-entity YANG module =
(currently draft-entitydt-netmod-entity) for equipment management but we =
are a bit concerned about its draft status and its dependence on YANG =
1.1. Any advice or reassurance?
>=20
> Thanks,
> William
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Dec 11 13:51:42 2015
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 844231A9028; Fri, 11 Dec 2015 13:51:38 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.11.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151211215138.14138.64206.idtracker@ietfa.amsl.com>
Date: Fri, 11 Dec 2015 13:51:38 -0800
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-09.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Dec 2015 21:51:38 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

        Title           : The YANG 1.1 Data Modeling Language
        Author          : Martin Bjorklund
	Filename        : draft-ietf-netmod-rfc6020bis-09.txt
	Pages           : 201
	Date            : 2015-12-11

Abstract:
   YANG is a data modeling language used to model configuration data,
   state data, remote procedure calls, and notifications for network
   management protocols like the Network Configuration Protocol
   (NETCONF).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-09


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 Fri Dec 11 13:55:58 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C701A1B2D for ; Fri, 11 Dec 2015 13:55:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 34mCRIVioc-L for ; Fri, 11 Dec 2015 13:55:54 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A0B521A00F5 for ; Fri, 11 Dec 2015 13:55:54 -0800 (PST)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 43E7C1AE098B for ; Fri, 11 Dec 2015 22:55:53 +0100 (CET)
Date: Fri, 11 Dec 2015 22:56:08 +0100 (CET)
Message-Id: <20151211.225608.2419309897626325.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20151211215138.14138.64206.idtracker@ietfa.amsl.com>
References: <20151211215138.14138.64206.idtracker@ietfa.amsl.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / 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-rfc6020bis-09.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 11 Dec 2015 21:55:56 -0000

Hi,

This version addresses all issues reported on -08 during (and after)
the WGLC period.  We didn't reach full agreement on all these issues,
but I believe the document reflects WG consensus.


/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 NETCONF Data Modeling Language Working Group of the IETF.
> 
>         Title           : The YANG 1.1 Data Modeling Language
>         Author          : Martin Bjorklund
> 	Filename        : draft-ietf-netmod-rfc6020bis-09.txt
> 	Pages           : 201
> 	Date            : 2015-12-11
> 
> Abstract:
>    YANG is a data modeling language used to model configuration data,
>    state data, remote procedure calls, and notifications for network
>    management protocols like the Network Configuration Protocol
>    (NETCONF).
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6020bis-09
> 
> 
> 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 Fri Dec 11 23:31:54 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47ED01A1AAE; Fri, 11 Dec 2015 23:31:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 JWKTS2PYOQSk; Fri, 11 Dec 2015 23:31:50 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCBFD1A1AA2; Fri, 11 Dec 2015 23:31:50 -0800 (PST)
Received: from [IPv6:2a01:5e0:29:ffff:ec1f:e275:6cff:bf70] (unknown [IPv6:2a01:5e0:29:ffff:ec1f:e275:6cff:bf70]) by mail.nic.cz (Postfix) with ESMTPSA id F33F81816F9; Sat, 12 Dec 2015 08:31:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1449905508; bh=hy2UAqQU6MXDCpvqpC/P5R4Qfx4OdUEfwxGKUahqT4k=; h=From:Date:To; b=g98xytm9isEbEueTGcvLTC9DZliHSLH03WE60LPGvxQChafBqP1xSbKmXSfKqhpaT dYhJ2pdS35MH26luQYX2gwK3IrkZkA8ll5CIwvwdJxauKuODZTlhJHAs/fC0oEeTn9 umr6mev/yioEuLgfSHX8T3KrkS/9QyIqb7aOFCaw=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <20151211215138.14138.64206.idtracker@ietfa.amsl.com>
Date: Sat, 12 Dec 2015 08:31:50 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20151211215138.14138.64206.idtracker@ietfa.amsl.com>
To: internet-drafts@ietf.org
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org, i-d-announce@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-09.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Dec 2015 07:31:53 -0000

Hi,

I propose an additional change to the new text in sec. 7.17, paragraph =
7:

OLD

    If the augmentation adds mandatory nodes=E2=80=A6

NEW

    If the augmentation adds mandatory configuration nodes=E2=80=A6


Unknown nodes appearing in state data, RPC output or notification may =
possibly break an old client, too, but that would happen even if the =
nodes are not defined as mandatory. Therefore, I don't see any reason =
for applying the restriction on non-config data.

Lada

> On 11 Dec 2015, at 22:51, internet-drafts@ietf.org wrote:
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the NETCONF Data Modeling Language =
Working Group of the IETF.
>=20
>        Title           : The YANG 1.1 Data Modeling Language
>        Author          : Martin Bjorklund
> 	Filename        : draft-ietf-netmod-rfc6020bis-09.txt
> 	Pages           : 201
> 	Date            : 2015-12-11
>=20
> Abstract:
>   YANG is a data modeling language used to model configuration data,
>   state data, remote procedure calls, and notifications for network
>   management protocols like the Network Configuration Protocol
>   (NETCONF).
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/
>=20
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-rfc6020bis-09
>=20
>=20
> 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.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Fri Dec 11 23:37:04 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0B51A1AC6 for ; Fri, 11 Dec 2015 23:37:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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 1o0TCrSzbAn0 for ; Fri, 11 Dec 2015 23:37:01 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 737891A1ABF for ; Fri, 11 Dec 2015 23:37:01 -0800 (PST)
Received: from [IPv6:2a01:5e0:29:ffff:ec1f:e275:6cff:bf70] (unknown [IPv6:2a01:5e0:29:ffff:ec1f:e275:6cff:bf70]) by mail.nic.cz (Postfix) with ESMTPSA id 243F7180C5B for ; Sat, 12 Dec 2015 08:37:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1449905820; bh=Q9ZFuKqqd9tm+qWQsF19RQs234rn9hbzaB7EBNPTcuM=; h=From:Date:To; b=k9lo/ikqZxEt96Jxr2XrwuRTaO0AFoZP25F+C8ID+LZkwQtR1W41swoPDSfvi2t7g mCPnDF7FrQCuzU7ERPnO+yqSTyeIi6+ym/51JutpLdYLFy2rLASOj+AobpYue0P5ue FluYYaHjyEntpJ0Ov50R3dkn3fUUgR7izcfKUjvg=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Sat, 12 Dec 2015 08:37:02 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <58A4A113-C656-4EF1-9919-8F0CFDD76DA9@nic.cz>
References: <20151211215138.14138.64206.idtracker@ietfa.amsl.com> 
To: NETMOD WG 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-09.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Dec 2015 07:37:02 -0000

Sorry, I sent my message by mistake also to internet-drafts and =
i-d-announce mailing lists. Please remove them from your reply.

Lada
=20
> On 12 Dec 2015, at 08:31, Ladislav Lhotka  wrote:
>=20
> Hi,
>=20
> I propose an additional change to the new text in sec. 7.17, paragraph =
7:
>=20
> OLD
>=20
>    If the augmentation adds mandatory nodes=E2=80=A6
>=20
> NEW
>=20
>    If the augmentation adds mandatory configuration nodes=E2=80=A6
>=20
>=20
> Unknown nodes appearing in state data, RPC output or notification may =
possibly break an old client, too, but that would happen even if the =
nodes are not defined as mandatory. Therefore, I don't see any reason =
for applying the restriction on non-config data.
>=20
> Lada
>=20
>> On 11 Dec 2015, at 22:51, internet-drafts@ietf.org wrote:
>>=20
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>> This draft is a work item of the NETCONF Data Modeling Language =
Working Group of the IETF.
>>=20
>>       Title           : The YANG 1.1 Data Modeling Language
>>       Author          : Martin Bjorklund
>> 	Filename        : draft-ietf-netmod-rfc6020bis-09.txt
>> 	Pages           : 201
>> 	Date            : 2015-12-11
>>=20
>> Abstract:
>>  YANG is a data modeling language used to model configuration data,
>>  state data, remote procedure calls, and notifications for network
>>  management protocols like the Network Configuration Protocol
>>  (NETCONF).
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6020bis/
>>=20
>> There's also a htmlized version available at:
>> https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09
>>=20
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-rfc6020bis-09
>>=20
>>=20
>> 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.
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Sat Dec 12 05:52:28 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9061A8794 for ; Sat, 12 Dec 2015 05:52:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 UkIzmw9MfnDs for ; Sat, 12 Dec 2015 05:52:26 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EC91C1A8792 for ; Sat, 12 Dec 2015 05:52:25 -0800 (PST)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id BA8CA1AE0483; Sat, 12 Dec 2015 14:52:23 +0100 (CET)
Date: Sat, 12 Dec 2015 14:52:45 +0100 (CET)
Message-Id: <20151212.145245.1238649856752575502.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References: <20151211215138.14138.64206.idtracker@ietfa.amsl.com> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-rfc6020bis-09.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 12 Dec 2015 13:52:27 -0000

TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gSGksDQo+IA0KPiBJIHBy
b3Bvc2UgYW4gYWRkaXRpb25hbCBjaGFuZ2UgdG8gdGhlIG5ldyB0ZXh0IGluIHNlYy4gNy4xNywg
cGFyYWdyYXBoDQo+IDc6DQo+IA0KPiBPTEQNCj4gDQo+ICAgICBJZiB0aGUgYXVnbWVudGF0aW9u
IGFkZHMgbWFuZGF0b3J5IG5vZGVz4oCmDQo+IA0KPiBORVcNCj4gDQo+ICAgICBJZiB0aGUgYXVn
bWVudGF0aW9uIGFkZHMgbWFuZGF0b3J5IGNvbmZpZ3VyYXRpb24gbm9kZXPigKYNCj4gDQo+IA0K
PiBVbmtub3duIG5vZGVzIGFwcGVhcmluZyBpbiBzdGF0ZSBkYXRhLCBSUEMgb3V0cHV0IG9yIG5v
dGlmaWNhdGlvbiBtYXkNCj4gcG9zc2libHkgYnJlYWsgYW4gb2xkIGNsaWVudCwgdG9vLCBidXQg
dGhhdCB3b3VsZCBoYXBwZW4gZXZlbiBpZiB0aGUNCj4gbm9kZXMgYXJlIG5vdCBkZWZpbmVkIGFz
IG1hbmRhdG9yeS4gVGhlcmVmb3JlLCBJIGRvbid0IHNlZSBhbnkgcmVhc29uDQo+IGZvciBhcHBs
eWluZyB0aGUgcmVzdHJpY3Rpb24gb24gbm9uLWNvbmZpZyBkYXRhLg0KDQpJIGFncmVlLCB0aGlz
IG1ha2VzIHNlbnNlLg0KDQoNCi9tYXJ0aW4NCg0KDQoNCj4gDQo+IExhZGENCj4gDQo+ID4gT24g
MTEgRGVjIDIwMTUsIGF0IDIyOjUxLCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgd3JvdGU6DQo+
ID4gDQo+ID4gDQo+ID4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhl
IG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+ID4gZGlyZWN0b3JpZXMuDQo+ID4gVGhpcyBkcmFm
dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTkVUQ09ORiBEYXRhIE1vZGVsaW5nIExhbmd1YWdlDQo+
ID4gV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4gPiANCj4gPiAgICAgICAgVGl0bGUgICAg
ICAgICAgIDogVGhlIFlBTkcgMS4xIERhdGEgTW9kZWxpbmcgTGFuZ3VhZ2UNCj4gPiAgICAgICAg
QXV0aG9yICAgICAgICAgIDogTWFydGluIEJqb3JrbHVuZA0KPiA+IAlGaWxlbmFtZSAgICAgICAg
OiBkcmFmdC1pZXRmLW5ldG1vZC1yZmM2MDIwYmlzLTA5LnR4dA0KPiA+IAlQYWdlcyAgICAgICAg
ICAgOiAyMDENCj4gPiAJRGF0ZSAgICAgICAgICAgIDogMjAxNS0xMi0xMQ0KPiA+IA0KPiA+IEFi
c3RyYWN0Og0KPiA+ICAgWUFORyBpcyBhIGRhdGEgbW9kZWxpbmcgbGFuZ3VhZ2UgdXNlZCB0byBt
b2RlbCBjb25maWd1cmF0aW9uIGRhdGEsDQo+ID4gICBzdGF0ZSBkYXRhLCByZW1vdGUgcHJvY2Vk
dXJlIGNhbGxzLCBhbmQgbm90aWZpY2F0aW9ucyBmb3IgbmV0d29yaw0KPiA+ICAgbWFuYWdlbWVu
dCBwcm90b2NvbHMgbGlrZSB0aGUgTmV0d29yayBDb25maWd1cmF0aW9uIFByb3RvY29sDQo+ID4g
ICAoTkVUQ09ORikuDQo+ID4gDQo+ID4gDQo+ID4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz
IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y
Zy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNjAyMGJpcy8NCj4gPiANCj4gPiBUaGVyZSdzIGFs
c28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4gPiBodHRwczovL3Rvb2xzLmll
dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNjAyMGJpcy0wOQ0KPiA+IA0KPiA+IEEg
ZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj4gPiBodHRw
czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRtb2QtcmZjNjAyMGJp
cy0wOQ0KPiA+IA0KPiA+IA0KPiA+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw
bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQo+ID4gc3VibWlzc2lvbg0KPiA+IHVudGls
IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0
Zi5vcmcuDQo+ID4gDQo+ID4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBh
bm9ueW1vdXMgRlRQIGF0Og0KPiA+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv
DQo+ID4gDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCj4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gbmV0bW9kQGlldGYub3JnDQo+ID4gaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gDQo+IC0tDQo+IExh
ZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCj4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4gDQo+
IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo=


From nobody Sun Dec 13 03:56:49 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4920E1A3BA7 for ; Sun, 13 Dec 2015 03:56:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 DAzmU0_sD7RG for ; Sun, 13 Dec 2015 03:56:45 -0800 (PST)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CA0A1A6ED9 for ; Sun, 13 Dec 2015 03:56:44 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2BZBQD5W21W/yYyC4deGQEBAQEPAQEBAYJfK4FBBrsGgieBY4YOAhx9ORMBAQEBAQEBgQqENAEBAQEDEhERRQwEAgEIDQEDBAEBAQICBh0DAgICMBQBCAgCBAENBQgaiA0BoFuKXZFXAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIEBhVeEe4RbgxwvgRoFlnYBjx6HYY9kg3QjAz2EBHKDawGBBwEBAQ
X-IPAS-Result: A2BZBQD5W21W/yYyC4deGQEBAQEPAQEBAYJfK4FBBrsGgieBY4YOAhx9ORMBAQEBAQEBgQqENAEBAQEDEhERRQwEAgEIDQEDBAEBAQICBh0DAgICMBQBCAgCBAENBQgaiA0BoFuKXZFXAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIEBhVeEe4RbgxwvgRoFlnYBjx6HYY9kg3QjAz2EBHKDawGBBwEBAQ
X-IronPort-AV: E=Sophos;i="5.20,422,1444708800"; d="scan'208";a="150432096"
Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 13 Dec 2015 06:56:43 -0500
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES256-SHA; 13 Dec 2015 06:56:43 -0500
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Sun, 13 Dec 2015 12:56:42 +0100
From: "Romascanu, Dan (Dan)" 
To: Nadeau Thomas , William Lupton 
Thread-Topic: [netmod] Broadband Forum intention of using ietf-entity YANG module
Thread-Index: AQHRNBPh5mnDLbAOxEuvwrvbNBHmh57FxxwAgAMKyDA=
Date: Sun, 13 Dec 2015 11:56:41 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BEC13F2@AZ-FFEXMB04.global.avaya.com>
References: <3D09C93F-EA97-4E60-B89C-E077CA1DD66B@broadband-forum.org> <6E0FC5E2-AC0C-40B8-BB46-44B9877CE39A@lucidvision.com>
In-Reply-To: <6E0FC5E2-AC0C-40B8-BB46-44B9877CE39A@lucidvision.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.48]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Broadband Forum intention of using ietf-entity YANG module
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 13 Dec 2015 11:56:47 -0000

Q29uY2VybmluZyB0aGUgJ2RyYWZ0IHN0YXR1cycgLSBhbnl0aGluZyBwcmV2ZW50cyB0aGUgd2cg
ZnJvbSBydW5uaW5nIGEgc2hvcnQgY29uc2Vuc3VzIGNhbGwgYW5kIGFkZGluZyB0aGlzIGl0ZW0g
dG8gdGhlIG5ldG1vZCBtaWxlc3RvbmVzPyANCg0KUmVnYXJkcywNCg0KRGFuDQoNCg0KPiAtLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBuZXRtb2QgW21haWx0bzpuZXRtb2QtYm91
bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE5hZGVhdQ0KPiBUaG9tYXMNCj4gU2VudDogRnJp
ZGF5LCBEZWNlbWJlciAxMSwgMjAxNSA0OjI3IFBNDQo+IFRvOiBXaWxsaWFtIEx1cHRvbg0KPiBD
YzogbmV0bW9kQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBCcm9hZGJhbmQgRm9y
dW0gaW50ZW50aW9uIG9mIHVzaW5nIGlldGYtZW50aXR5IFlBTkcNCj4gbW9kdWxlDQo+IA0KPiAN
Cj4gCURlcGVuZGFuY2Ugb24gMS4xIHNob3VsZCBub3QgYmUgYW4gaXNzdWUgYXMgdGhhdCBpcyBh
bG1vc3QgcmVhZHkgdG8NCj4gYmUgYXBwcm92ZWQuIFlvdSBzaG91bGQgYmUgYnVpbGRpbmcgeW91
ciBtb2RlbCB0byBjb21wbHkgd2l0aCB0aGUgMS4xIHJ1bGVzLg0KPiANCj4gCeKAlFRvbQ0KPiAN
Cj4gDQo+ID4gT24gRGVjIDExLCAyMDE1Ojg6MDAgQU0sIGF0IDg6MDAgQU0sIFdpbGxpYW0gTHVw
dG9uDQo+IDx3bHVwdG9uQGJyb2FkYmFuZC1mb3J1bS5vcmc+IHdyb3RlOg0KPiA+DQo+ID4gQWxs
LA0KPiA+DQo+ID4gVGhlIEJyb2FkYmFuZCBGb3J1bSB3b3VsZCBsaWtlIHRvIHVzZSB0aGUgaWV0
Zi1lbnRpdHkgWUFORyBtb2R1bGUNCj4gKGN1cnJlbnRseSBkcmFmdC1lbnRpdHlkdC1uZXRtb2Qt
ZW50aXR5KSBmb3IgZXF1aXBtZW50IG1hbmFnZW1lbnQgYnV0IHdlDQo+IGFyZSBhIGJpdCBjb25j
ZXJuZWQgYWJvdXQgaXRzIGRyYWZ0IHN0YXR1cyBhbmQgaXRzIGRlcGVuZGVuY2Ugb24gWUFORyAx
LjEuDQo+IEFueSBhZHZpY2Ugb3IgcmVhc3N1cmFuY2U/DQo+ID4NCj4gPiBUaGFua3MsDQo+ID4g
V2lsbGlhbQ0KDQo=


From nobody Mon Dec 14 06:59:16 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F8A1A3BA1 for ; Mon, 14 Dec 2015 06:59:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 tGJW8gRUwG1J for ; Mon, 14 Dec 2015 06:59:08 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17D81A3B9F for ; Mon, 14 Dec 2015 06:59:07 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C11B1AC1; Mon, 14 Dec 2015 15:59:05 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id MWVs5nday7Co; Mon, 14 Dec 2015 15:59:04 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 14 Dec 2015 15:59:04 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A51720056; Mon, 14 Dec 2015 15:59:04 +0100 (CET)
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 YjXGc49Agw_k; Mon, 14 Dec 2015 15:59:03 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3B02F20055; Mon, 14 Dec 2015 15:59:02 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 8D75B392F82D; Mon, 14 Dec 2015 15:59:01 +0100 (CET)
Date: Mon, 14 Dec 2015 15:59:00 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20151214145900.GA50445@elstar.local>
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
References: <20151209.125201.1881722819009601986.mbj@tail-f.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151209.125201.1881722819009601986.mbj@tail-f.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] new text for Y26
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Dec 2015 14:59:13 -0000

On Wed, Dec 09, 2015 at 12:52:01PM +0100, Martin Bjorklund wrote:
> Hi,
> 
> It seems we will not reach full agreement on some of the remaining
> issues in 6020bis.  Re-opening Y26 is one of them.  I don't think this
> is a good idea, but I realize that the consensus is to relax the "MUST
> NOT augment mandatory nodes" rule.
> 
> Here is my proposal for new text.  Most of this text is copied from
> 6087bis, so if we add this to 6020bis, 6087bis should probably be
> updated as well.
> 
> This new subsection would go into 7.17 The augment Statement.
> 
> 
> *** Augmenting Conditionally Mandatory Nodes
> 
> If the target node is in another module, then nodes added by the
> augmentation MUST NOT be mandatory nodes (see ^terminology^), except
> as described below.  The reason for this is that clients that do not
> know about the augmenting module should contiune to work.

Replace

  MUST NOT be mandatory nodes (see ^terminology^), except as described below.

with

  SHOULD NOT be mandatory nodes (see ^terminology^).

to avoid the 'MUST NOT ... except' logic?

/js
 
> It is possible to add conditional augment statements such that an old
> client would not know about the new condition, and would not specify
> the new condition.  The conditional augment statement can contain
> mandatory nodes only if the condition is false unless explicitly
> requested by the client.
> 
> If the augmentation adds mandatory nodes to a target node in another
> module, the augmentation MUST be conditional with a "when" statement.
> Care must be taken when defining the "when" expression, so that
> clients that do not know about the augmenting module do not break.
> 
> **** Usage Example
> 
> In the following example, it is OK to augment the "interface" entry
> with "mandatory-leaf" because the augmentation depends on support for
> "some-new-iftype".  The old client does not know about this type so it
> would never select this type, and therefore not be adding a mandatory
> data node.
> 
>   module example-augment {
>     namespace "urn:example:augment";
>     prefix mymod;
> 
>     import ietf-interfaces {
>       prefix if;
>     }
> 
>     identity some-new-iftype {
>        base if:interface-type;
>     }
> 
>     augment "/if:interfaces/if:interface" {
>        when "if:type = 'mymod:some-new-iftype'";
> 
>        leaf mandatory-leaf {
>           mandatory true;
>           type string;
>        }
>     }
>   }
> 
> 
> 
> /martin
> 
> _______________________________________________
> 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 Mon Dec 14 07:16:01 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40F931A6F66 for ; Mon, 14 Dec 2015 07:16:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 Qnxu3--Jo4LZ for ; Mon, 14 Dec 2015 07:15:56 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EBB121A1BE3 for ; Mon, 14 Dec 2015 07:14:43 -0800 (PST)
Received: from localhost (unknown [173.38.220.62]) by mail.tail-f.com (Postfix) with ESMTPSA id 4376E1AE035C; Mon, 14 Dec 2015 16:14:42 +0100 (CET)
Date: Mon, 14 Dec 2015 16:14:43 +0100 (CET)
Message-Id: <20151214.161443.488678550310517160.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20151214145900.GA50445@elstar.local>
References: <20151209.125201.1881722819009601986.mbj@tail-f.com> <20151214145900.GA50445@elstar.local>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] new text for Y26
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Dec 2015 15:16:00 -0000

Juergen Schoenwaelder  wrote:
> On Wed, Dec 09, 2015 at 12:52:01PM +0100, Martin Bjorklund wrote:
> > Hi,
> > 
> > It seems we will not reach full agreement on some of the remaining
> > issues in 6020bis.  Re-opening Y26 is one of them.  I don't think this
> > is a good idea, but I realize that the consensus is to relax the "MUST
> > NOT augment mandatory nodes" rule.
> > 
> > Here is my proposal for new text.  Most of this text is copied from
> > 6087bis, so if we add this to 6020bis, 6087bis should probably be
> > updated as well.
> > 
> > This new subsection would go into 7.17 The augment Statement.
> > 
> > 
> > *** Augmenting Conditionally Mandatory Nodes
> > 
> > If the target node is in another module, then nodes added by the
> > augmentation MUST NOT be mandatory nodes (see ^terminology^), except
> > as described below.  The reason for this is that clients that do not
> > know about the augmenting module should contiune to work.
> 
> Replace
> 
>   MUST NOT be mandatory nodes (see ^terminology^), except as described below.
> 
> with
> 
>   SHOULD NOT be mandatory nodes (see ^terminology^).
> 
> to avoid the 'MUST NOT ... except' logic?

I think "MUST NOT ... except" is correct.  I also searched existing
RFCs for this construct, and found quite a few.


/martin






> 
> /js
>  
> > It is possible to add conditional augment statements such that an old
> > client would not know about the new condition, and would not specify
> > the new condition.  The conditional augment statement can contain
> > mandatory nodes only if the condition is false unless explicitly
> > requested by the client.
> > 
> > If the augmentation adds mandatory nodes to a target node in another
> > module, the augmentation MUST be conditional with a "when" statement.
> > Care must be taken when defining the "when" expression, so that
> > clients that do not know about the augmenting module do not break.
> > 
> > **** Usage Example
> > 
> > In the following example, it is OK to augment the "interface" entry
> > with "mandatory-leaf" because the augmentation depends on support for
> > "some-new-iftype".  The old client does not know about this type so it
> > would never select this type, and therefore not be adding a mandatory
> > data node.
> > 
> >   module example-augment {
> >     namespace "urn:example:augment";
> >     prefix mymod;
> > 
> >     import ietf-interfaces {
> >       prefix if;
> >     }
> > 
> >     identity some-new-iftype {
> >        base if:interface-type;
> >     }
> > 
> >     augment "/if:interfaces/if:interface" {
> >        when "if:type = 'mymod:some-new-iftype'";
> > 
> >        leaf mandatory-leaf {
> >           mandatory true;
> >           type string;
> >        }
> >     }
> >   }
> > 
> > 
> > 
> > /martin
> > 
> > _______________________________________________
> > 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 Mon Dec 14 07:22:38 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BEF1A6F80 for ; Mon, 14 Dec 2015 07:22:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level: 
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 MNGtFUoU8QZw for ; Mon, 14 Dec 2015 07:22:35 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E43781A7000 for ; Mon, 14 Dec 2015 07:20:37 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:608d:5d4c:5037:6f1] (unknown [IPv6:2001:718:1a02:1:608d:5d4c:5037:6f1]) by mail.nic.cz (Postfix) with ESMTPSA id 7F4CE181A64; Mon, 14 Dec 2015 16:20:36 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450106436; bh=iyePgaBtN6VQDnIkY7WPc7hLLNwPHJ2SyTw6TEZidYk=; h=From:Date:To; b=jUuCa4sugZLW0YytGI7QayJ8xcVw9jf2/hiU5qCihusJC4s7J+8oBylFxXvfArXah HRj3jxyGrGDksimanjxLENqnW2L7LvDVJyY45/WnnvdW4WOlVNKi4ZLg7gBs93myLa n3hXon+jhUGDEbJAWdBIdtBvOGNJDFmkjROFhpK8=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <20151214.161443.488678550310517160.mbj@tail-f.com>
Date: Mon, 14 Dec 2015 16:20:35 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <38875EAA-52F4-4589-8610-EED69965B8E6@nic.cz>
References: <20151209.125201.1881722819009601986.mbj@tail-f.com> <20151214145900.GA50445@elstar.local> <20151214.161443.488678550310517160.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] new text for Y26
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Dec 2015 15:22:36 -0000

> On 14 Dec 2015, at 16:14, Martin Bjorklund  wrote:
>=20
> Juergen Schoenwaelder  wrote:
>> On Wed, Dec 09, 2015 at 12:52:01PM +0100, Martin Bjorklund wrote:
>>> Hi,
>>>=20
>>> It seems we will not reach full agreement on some of the remaining
>>> issues in 6020bis.  Re-opening Y26 is one of them.  I don't think =
this
>>> is a good idea, but I realize that the consensus is to relax the =
"MUST
>>> NOT augment mandatory nodes" rule.
>>>=20
>>> Here is my proposal for new text.  Most of this text is copied from
>>> 6087bis, so if we add this to 6020bis, 6087bis should probably be
>>> updated as well.
>>>=20
>>> This new subsection would go into 7.17 The augment Statement.
>>>=20
>>>=20
>>> *** Augmenting Conditionally Mandatory Nodes
>>>=20
>>> If the target node is in another module, then nodes added by the
>>> augmentation MUST NOT be mandatory nodes (see ^terminology^), except
>>> as described below.  The reason for this is that clients that do not
>>> know about the augmenting module should contiune to work.
>>=20
>> Replace
>>=20
>>  MUST NOT be mandatory nodes (see ^terminology^), except as described =
below.
>>=20
>> with
>>=20
>>  SHOULD NOT be mandatory nodes (see ^terminology^).
>>=20
>> to avoid the 'MUST NOT ... except' logic?
>=20
> I think "MUST NOT ... except" is correct.  I also searched existing
> RFCs for this construct, and found quite a few.

Hmm, but the latest revision rfc6020bis has a different text without =
this "MUST NOT ... except" logic. Am I missing something?

Lada

>=20
>=20
> /martin
>=20
>=20
>=20
>=20
>=20
>=20
>>=20
>> /js
>>=20
>>> It is possible to add conditional augment statements such that an =
old
>>> client would not know about the new condition, and would not specify
>>> the new condition.  The conditional augment statement can contain
>>> mandatory nodes only if the condition is false unless explicitly
>>> requested by the client.
>>>=20
>>> If the augmentation adds mandatory nodes to a target node in another
>>> module, the augmentation MUST be conditional with a "when" =
statement.
>>> Care must be taken when defining the "when" expression, so that
>>> clients that do not know about the augmenting module do not break.
>>>=20
>>> **** Usage Example
>>>=20
>>> In the following example, it is OK to augment the "interface" entry
>>> with "mandatory-leaf" because the augmentation depends on support =
for
>>> "some-new-iftype".  The old client does not know about this type so =
it
>>> would never select this type, and therefore not be adding a =
mandatory
>>> data node.
>>>=20
>>>  module example-augment {
>>>    namespace "urn:example:augment";
>>>    prefix mymod;
>>>=20
>>>    import ietf-interfaces {
>>>      prefix if;
>>>    }
>>>=20
>>>    identity some-new-iftype {
>>>       base if:interface-type;
>>>    }
>>>=20
>>>    augment "/if:interfaces/if:interface" {
>>>       when "if:type =3D 'mymod:some-new-iftype'";
>>>=20
>>>       leaf mandatory-leaf {
>>>          mandatory true;
>>>          type string;
>>>       }
>>>    }
>>>  }
>>>=20
>>>=20
>>>=20
>>> /martin
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>> --=20
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | =
Germany
>> Fax:   +49 421 200 3103         
>>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon Dec 14 07:27:00 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1011A6FBE for ; Mon, 14 Dec 2015 07:26:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 u0TAUI9NFbzW for ; Mon, 14 Dec 2015 07:26:54 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7CBAD1A6FE2 for ; Mon, 14 Dec 2015 07:25:40 -0800 (PST)
Received: from localhost (unknown [173.38.220.62]) by mail.tail-f.com (Postfix) with ESMTPSA id 640A61AE035C; Mon, 14 Dec 2015 16:25:39 +0100 (CET)
Date: Mon, 14 Dec 2015 16:25:40 +0100 (CET)
Message-Id: <20151214.162540.1969763118240390047.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <38875EAA-52F4-4589-8610-EED69965B8E6@nic.cz>
References: <20151214145900.GA50445@elstar.local> <20151214.161443.488678550310517160.mbj@tail-f.com> <38875EAA-52F4-4589-8610-EED69965B8E6@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] new text for Y26
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Dec 2015 15:26:59 -0000

Ladislav Lhotka  wrote:
> 
> > On 14 Dec 2015, at 16:14, Martin Bjorklund  wrote:
> > 
> > Juergen Schoenwaelder  wrote:
> >> On Wed, Dec 09, 2015 at 12:52:01PM +0100, Martin Bjorklund wrote:
> >>> Hi,
> >>> 
> >>> It seems we will not reach full agreement on some of the remaining
> >>> issues in 6020bis.  Re-opening Y26 is one of them.  I don't think this
> >>> is a good idea, but I realize that the consensus is to relax the "MUST
> >>> NOT augment mandatory nodes" rule.
> >>> 
> >>> Here is my proposal for new text.  Most of this text is copied from
> >>> 6087bis, so if we add this to 6020bis, 6087bis should probably be
> >>> updated as well.
> >>> 
> >>> This new subsection would go into 7.17 The augment Statement.
> >>> 
> >>> 
> >>> *** Augmenting Conditionally Mandatory Nodes
> >>> 
> >>> If the target node is in another module, then nodes added by the
> >>> augmentation MUST NOT be mandatory nodes (see ^terminology^), except
> >>> as described below.  The reason for this is that clients that do not
> >>> know about the augmenting module should contiune to work.
> >> 
> >> Replace
> >> 
> >>  MUST NOT be mandatory nodes (see ^terminology^), except as described
> >>  below.
> >> 
> >> with
> >> 
> >>  SHOULD NOT be mandatory nodes (see ^terminology^).
> >> 
> >> to avoid the 'MUST NOT ... except' logic?
> > 
> > I think "MUST NOT ... except" is correct.  I also searched existing
> > RFCs for this construct, and found quite a few.
> 
> Hmm, but the latest revision rfc6020bis has a different text without
> this "MUST NOT ... except" logic. Am I missing something?

No you're right; sorry I was confused by Juergen's comment ;-)

The text in -09 is weaker than what I originally proposed, based on
the comments I received.



/martin



> 
> Lada
> 
> > 
> > 
> > /martin
> > 
> > 
> > 
> > 
> > 
> > 
> >> 
> >> /js
> >> 
> >>> It is possible to add conditional augment statements such that an old
> >>> client would not know about the new condition, and would not specify
> >>> the new condition.  The conditional augment statement can contain
> >>> mandatory nodes only if the condition is false unless explicitly
> >>> requested by the client.
> >>> 
> >>> If the augmentation adds mandatory nodes to a target node in another
> >>> module, the augmentation MUST be conditional with a "when" statement.
> >>> Care must be taken when defining the "when" expression, so that
> >>> clients that do not know about the augmenting module do not break.
> >>> 
> >>> **** Usage Example
> >>> 
> >>> In the following example, it is OK to augment the "interface" entry
> >>> with "mandatory-leaf" because the augmentation depends on support for
> >>> "some-new-iftype".  The old client does not know about this type so it
> >>> would never select this type, and therefore not be adding a mandatory
> >>> data node.
> >>> 
> >>>  module example-augment {
> >>>    namespace "urn:example:augment";
> >>>    prefix mymod;
> >>> 
> >>>    import ietf-interfaces {
> >>>      prefix if;
> >>>    }
> >>> 
> >>>    identity some-new-iftype {
> >>>       base if:interface-type;
> >>>    }
> >>> 
> >>>    augment "/if:interfaces/if:interface" {
> >>>       when "if:type = 'mymod:some-new-iftype'";
> >>> 
> >>>       leaf mandatory-leaf {
> >>>          mandatory true;
> >>>          type string;
> >>>       }
> >>>    }
> >>>  }
> >>> 
> >>> 
> >>> 
> >>> /martin
> >>> 
> >>> _______________________________________________
> >>> 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
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 


From nobody Mon Dec 14 10:13:15 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07BE71B2A60 for ; Mon, 14 Dec 2015 10:13:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 Emhl45NYV7bI for ; Mon, 14 Dec 2015 10:13:11 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 DD0621B2AB6 for ; Mon, 14 Dec 2015 10:13:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450116765; bh=ey+DsSJEPPihUbUYtUJkBK4ObDzNxhfKf9ZizdPNz2c=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=EhyDCwxVoZBYjF8PBB01MujEPz/jUB0MxEG66PUSL/AT/MBrc8+uPAkiXKGokcnO/ xY3Yolzz7WBxoZDUASLuxHvwMCpTeZxu91ZUIzQLIR3O2fBJZq7zcVbODssmkvt4ut zxwmKsVhvZTWUptaCjiZYLfIb8/+uhQhlcN3RVzU=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Nadeau Thomas 
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BEC13F2@AZ-FFEXMB04.global.avaya.com>
Date: Mon, 14 Dec 2015 13:13:09 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <3D09C93F-EA97-4E60-B89C-E077CA1DD66B@broadband-forum.org> <6E0FC5E2-AC0C-40B8-BB46-44B9877CE39A@lucidvision.com> <9904FB1B0159DA42B0B887B7FA8119CA6BEC13F2@AZ-FFEXMB04.global.avaya.com>
To: "Romascanu, Dan (Dan)" 
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=2 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 213, in=2843, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Broadband Forum intention of using ietf-entity YANG module
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Dec 2015 18:13:14 -0000

	I personally don=E2=80=99t see anything that prevents this. =20

	=E2=80=94Tom

> On Dec 13, 2015:6:56 AM, at 6:56 AM, Romascanu, Dan (Dan) =
 wrote:
>=20
> Concerning the 'draft status' - anything prevents the wg from running =
a short consensus call and adding this item to the netmod milestones?=20
>=20
> Regards,
>=20
> Dan
>=20
>=20
>> -----Original Message-----
>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Nadeau
>> Thomas
>> Sent: Friday, December 11, 2015 4:27 PM
>> To: William Lupton
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] Broadband Forum intention of using ietf-entity =
YANG
>> module
>>=20
>>=20
>> 	Dependance on 1.1 should not be an issue as that is almost ready =
to
>> be approved. You should be building your model to comply with the 1.1 =
rules.
>>=20
>> 	=E2=80=94Tom
>>=20
>>=20
>>> On Dec 11, 2015:8:00 AM, at 8:00 AM, William Lupton
>>  wrote:
>>>=20
>>> All,
>>>=20
>>> The Broadband Forum would like to use the ietf-entity YANG module
>> (currently draft-entitydt-netmod-entity) for equipment management but =
we
>> are a bit concerned about its draft status and its dependence on YANG =
1.1.
>> Any advice or reassurance?
>>>=20
>>> Thanks,
>>> William
>=20


From nobody Mon Dec 14 11:17:35 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796401B2DCB for ; Mon, 14 Dec 2015 11:17:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 ujyTwv45yUBv for ; Mon, 14 Dec 2015 11:17:32 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5D231B2DD4 for ; Mon, 14 Dec 2015 11:17:31 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A699393A for ; Mon, 14 Dec 2015 20:17:30 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id q1LlwlPdKROL for ; Mon, 14 Dec 2015 20:17:29 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 14 Dec 2015 20:17:29 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6F2D520056 for ; Mon, 14 Dec 2015 20:17:29 +0100 (CET)
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 TkjYl0RLRPym; Mon, 14 Dec 2015 20:17:28 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2780320055; Mon, 14 Dec 2015 20:17:28 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 92FDA392FFCC; Mon, 14 Dec 2015 20:17:26 +0100 (CET)
Date: Mon, 14 Dec 2015 20:17:25 +0100
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20151214191724.GA51110@elstar.local>
Mail-Followup-To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Subject: [netmod] 2nd WG Last Call on YANG 1.1 (draft-ietf-netmod-rfc6020bis-09) [until 2016-01-06]
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Dec 2015 19:17:34 -0000

This is a notice to start the second NETMOD WG last-call for the
document "The YANG 1.1 Data Modeling Language":

  https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-09

Due to the upcoming holiday season, the WG last-call runs until
Wednesday January 6th, 2016. Please indicate your support of this
version of the document. We are not only interested in receiving
defect reports, we are equally interested in statements of the form:

  "I have reviewed I-D XYZ and I found no issues"
  "I have implemented I-D XYZ"
  "I am implementing I-D XYZ"
  "I am considering to implement I-D XYZ"

We will track non-editorial defect reports in this document:

  https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/last-call-comments.html

This is the second WG last-call for this document. The first WG
last-call (draft-ietf-netmod-rfc6020bis-07) did end on October 12th
2015 and lead to a number of changes. A diff of -07 to -09 can be
found here:

http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-netmod-rfc6020bis-07.txt&url2=https://tools.ietf.org/id/draft-ietf-netmod-rfc6020bis-09.txt

/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 Dec 14 11:18:33 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF121B2DCD for ; Mon, 14 Dec 2015 11:18:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 bSDycN5dykd1 for ; Mon, 14 Dec 2015 11:18:31 -0800 (PST)
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 526141B2DDC for ; Mon, 14 Dec 2015 11:18:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1433; q=dns/txt; s=iport; t=1450120695; x=1451330295; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=OHmGe5TB22olJVm36ZivEPJqF/9+5FngGKC+yonwoqU=; b=Vw+prHSLGZljsxHwDHa+3j5IAe4Kll3hLnryJCQauUpXkZqVoBvBnm1N 4gaslNE55mow3cuxkgn6PL2GcR9ber41xTu/uJAwFajIJE/4upIVYTP4W ojnYK1nSHOvzW8KsobVvHQb4QbObHr1XEEp2FVZxsX57acasYayWAmjD7 Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuBAALFW9W/xbLJq1ehA1uvyUXCoUjS?= =?us-ascii?q?gKBdwEBAQEBAYELhDQBAQEDAQEBASAPAQU2CgEFBwQLDgMEAQEBAgIFFggDAgI?= =?us-ascii?q?JAwIBAgEVHwkIBg0GAgEBiCMIDatXkWABAQEBAQEBAQEBAQEBAQEBAQEBAQEUB?= =?us-ascii?q?IEBhVWEfYd3gUkBBJZ2jUSBW4dKj3uDdGOEBT00hQYBAQE?=
X-IronPort-AV: E=Sophos;i="5.20,428,1444694400"; d="scan'208";a="609010987"
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; 14 Dec 2015 19:18:13 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tBEJICwC014191; Mon, 14 Dec 2015 19:18:12 GMT
To: Nadeau Thomas , "Romascanu, Dan (Dan)" 
References: <3D09C93F-EA97-4E60-B89C-E077CA1DD66B@broadband-forum.org> <6E0FC5E2-AC0C-40B8-BB46-44B9877CE39A@lucidvision.com> <9904FB1B0159DA42B0B887B7FA8119CA6BEC13F2@AZ-FFEXMB04.global.avaya.com> 
From: Benoit Claise 
Message-ID: <566F15F3.4060408@cisco.com>
Date: Mon, 14 Dec 2015 20:18:11 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Broadband Forum intention of using ietf-entity YANG module
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 14 Dec 2015 19:18:32 -0000

> 	I personally don’t see anything that prevents this.
Same opinion here.

Regards, Benoit
>
> 	—Tom
>
>> On Dec 13, 2015:6:56 AM, at 6:56 AM, Romascanu, Dan (Dan)  wrote:
>>
>> Concerning the 'draft status' - anything prevents the wg from running a short consensus call and adding this item to the netmod milestones?
>>
>> Regards,
>>
>> Dan
>>
>>
>>> -----Original Message-----
>>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Nadeau
>>> Thomas
>>> Sent: Friday, December 11, 2015 4:27 PM
>>> To: William Lupton
>>> Cc: netmod@ietf.org
>>> Subject: Re: [netmod] Broadband Forum intention of using ietf-entity YANG
>>> module
>>>
>>>
>>> 	Dependance on 1.1 should not be an issue as that is almost ready to
>>> be approved. You should be building your model to comply with the 1.1 rules.
>>>
>>> 	—Tom
>>>
>>>
>>>> On Dec 11, 2015:8:00 AM, at 8:00 AM, William Lupton
>>>  wrote:
>>>> All,
>>>>
>>>> The Broadband Forum would like to use the ietf-entity YANG module
>>> (currently draft-entitydt-netmod-entity) for equipment management but we
>>> are a bit concerned about its draft status and its dependence on YANG 1.1.
>>> Any advice or reassurance?
>>>> Thanks,
>>>> William
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Mon Dec 14 17:56:05 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B07571AD213 for ; Mon, 14 Dec 2015 17:56:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 AMl6HlJokHXQ for ; Mon, 14 Dec 2015 17:56:02 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 310861AD1F5 for ; Mon, 14 Dec 2015 17:56:02 -0800 (PST)
Received: from stubbs.local.chopps.org (75-128-113-61.dhcp.aldl.mi.charter.com [75.128.113.61]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 5C57D60222; Tue, 15 Dec 2015 01:56:01 +0000 (UTC)
User-agent: mu4e 0.9.15; emacs 24.5.1
From: Christian Hopps 
To: netmod@ietf.org
Date: Mon, 14 Dec 2015 20:56:00 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: 
Subject: [netmod] Guidance on list vs. container of list
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Dec 2015 01:56:03 -0000

--=-=-=
Content-Type: text/plain; format=flowed


Some models seem to place a single list of things inside a 
container also named after the items in the list, e.g.,
 
+--ro modulename
   +--rw ribs
      +--rw rib* [name] 
         +--rw name 
 
I don't see the purpose of these containers. It seems to me that 
one can model and query the exact same data without the outer 
container. That is,
 
+--ro modulename
   +--rw rib* [name] 
      +--rw name 

Is there something useful about these containers that I've missed, 
as it's a fairly common pattern in the models I've been looking 
at.   Example comparisons below.. 

Thanks,
Chris.


w/ container: 
 
     
       
         
          foo 
          
          bar 
         ... 
       
     

w/o container: 
 
    
       
        foo 
        
        bar 
       ... 
     

Likewise if you want to fetch all ribs you can either way:

    
      
        
      
     
 
or
 
    
      
        
      
     
 
Or a particular rib
 
    
      
         
           
            foo
           
        
      
     
 
or
 
    
       
         
          foo
        
      
     

Using xpath:

    /modulename/ribs/rib[name='foo'] 

or

    /modulename/rib[name='foo']

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWb3MwAAoJEC4dgw7XuDAljx4P/3ljfzkGefJZo/rIDU9bW9S2
Qt5dKWKjx7/4NWkkVw+CP396LxW1MifPJcA+8ZzLSaKGosvPJEG+zf9Bqjxfk4ZY
Mr/i6xQy19yJJWqpcRZF0U3OeFe75SJd5A9pVb1Eo1wtaOJEHSCozo0scxHKwZ20
+3ikyU5kKrhwuv1o65TaofByQaaVDAtEswWApEO2DjkuXz06OIkTT9gIkPPBv8BV
VnjT5Ri0DNMZtF1ec1Y2txrDX0/rb5X9JmGMUrZfhAFQpGOEED6oiKEdXxxxu2Lg
D82hV/oA8qymEGWuj7MDwllyQxww6lOTck47hL46AlgCpJifP0/FQnZKgcYUbTfi
fqWZU9t2x5M8JG/rdqpAq00sfcxIyrVmv3qC5txtTBzkarqaVN9jjsVw/LmL9lZL
zVra5XOONdEFewKBd3SBkBOq4/ss7h4jIOXezVUudszistcZLct68vTzrpIe14NH
1raoxffuh81gjzs71j3FnKEJbo8hLyigVBUO26h5t+vx+9v2OVy08kcJ3UhWsqPj
yyfleung3UCmq9vkLB4QsHC8DTp8OcqQx0xNuH8lfasl//Fb1ZmFP3Xd6L4kMWf0
1fS9SduCGU1rwgA0Y4JhqhSoD7VAurH1WvhYsEJ2FU5+xVwUjDh30OpB9LdrqZTw
ZHEwjao4i1UZ1+aax0EX
=gOow
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Mon Dec 14 18:30:53 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BB171ADBFC for ; Mon, 14 Dec 2015 18:30:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 ADEs5MZbuWT0 for ; Mon, 14 Dec 2015 18:30:50 -0800 (PST)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 9D5D21B29A3 for ; Mon, 14 Dec 2015 18:30:21 -0800 (PST)
Received: by lfcy184 with SMTP id y184so61503017lfc.1 for ; Mon, 14 Dec 2015 18:30:19 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=Pyy18goQT20/z7Ne57/uEbNvw3Jk2qOWTGf3iu2mUG0=; b=oGoaQDVQBXpCP/qC+diSbWuyMqC7YYhC1ignjbbmKGiuiKFb3dUeCl954gnesChHgC G4LQdnvqCntuCwmM3XLyzDpQ/XiAksuqQWQcucWrriClV4giUezC/DSu7Ki5tLSxH0Kl +o18vFJB8IAxBOVe+SZEhXYET2Wje/e4NizWr1UemabpVrlnkmvUxM6Jr5u6ay2+bJdL J1QBGtabhe81Fb+YIrQaEN8m6e30gSpLSC6wz3AiknPgD/GbzOx7pmGmRYqcV4A7rVGj +xrAwyLFTBplW1QQcZYIov9l8K4x9uUnUnPNMmTO0RriW2aepJ2bQDfWK58TG9waziVP +z9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Pyy18goQT20/z7Ne57/uEbNvw3Jk2qOWTGf3iu2mUG0=; b=MIYO4HV7FWpos7q76iMiiafRLXt8ionLBGjnY8gdhl7XuhlGXdojiT5ijXrqL4wHH4 v+Jb/kkFTZePwQ0LmwnprS6qV791aixfHLfCYYaCZkZzEF4gCJLBjYo0vNovIJgvWd3a /g/4PCMbIsIHd5WYAGAA3Xryj1c+R40UXjaHN15Fvyo1kEKoRnWkjdIkO+OObAepYZuV I8ooJw33yj3+ewdpu4khV5Ua/+hpRZnDJ4jeCH10IOz0u/o6dOp50Be8f3L4yhYa/TVz YTfHoD7qPZKew/BJEvPEnS3m/zdedJHrSCDYrwNA+anc8GAJYklKcXWn8WWuhtBbRJNO io1Q==
X-Gm-Message-State: ALoCoQmKLp+rfeRgZRazpkcLjdXbY2f2rHLHnxPU7DBiBZDO/rYfHo3aQO0HgPaJ83UHulsYFu5O9GrlXnv+tOn9H5DR3liiHg==
MIME-Version: 1.0
X-Received: by 10.25.218.9 with SMTP id r9mr14695777lfg.138.1450146619719; Mon, 14 Dec 2015 18:30:19 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Mon, 14 Dec 2015 18:30:19 -0800 (PST)
In-Reply-To: 
References: 
Date: Mon, 14 Dec 2015 18:30:19 -0800
Message-ID: 
From: Andy Bierman 
To: Christian Hopps 
Content-Type: multipart/alternative; boundary=001a11402600241d5f0526e6925e
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Guidance on list vs. container of list
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Dec 2015 02:30:52 -0000

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

Hi,

Use of NP-containers are subjective, based on how you
want to organize your data.  The extra layer of containment
may be a waste, but it sometimes has a purpose

  - 2 or more sibling lists with lots of entries can be mixed in JSON,
    so putting each list in its container prevents that.
 - There is no standard way to 'delete-all' in NETCONF or RESTCONF
    but a 'replace' on the parent container can be used for this purpose.
    (container of list or leaf-list)
 - container servers as a conceptual 'root' for external augments

Andy


On Mon, Dec 14, 2015 at 5:56 PM, Christian Hopps  wrote:

>
> Some models seem to place a single list of things inside a container also
> named after the items in the list, e.g.,
>
> +--ro modulename
>   +--rw ribs
>      +--rw rib* [name]         +--rw name
> I don't see the purpose of these containers. It seems to me that one can
> model and query the exact same data without the outer container. That is,
>
> +--ro modulename
>   +--rw rib* [name]      +--rw name
> Is there something useful about these containers that I've missed, as it's
> a fairly common pattern in the models I've been looking at.   Example
> comparisons below..
> Thanks,
> Chris.
>
>
> w/ container:
>                            foo
>            bar         ...      
> 
> w/o container:
>    
>              foo       
> bar       ...    
> Likewise if you want to fetch all ribs you can either way:
>
>    
>      
>        
>      
>    
> or
>
>    
>      
>        
>      
>    
> Or a particular rib
>
>    
>      
>                              foo
>                  
>      
>    
> or
>
>    
>                        foo
>        
>      
>    
> Using xpath:
>
>    /modulename/ribs/rib[name='foo']
> or
>
>    /modulename/rib[name='foo']
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

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


Hi,

Use of NP-containers are subjective=
, based on how you
want to organize your data.=C2=A0 The extra la=
yer of containment
may be a waste, but it sometimes has a purpose=


=C2=A0 - 2 or more sibling lists with lots of ent=
ries can be mixed in JSON,
=C2=A0 =C2=A0 so putting each list in =
its container prevents that.
=C2=A0- There is no standard way to =
'delete-all' in NETCONF or RESTCONF
=C2=A0 =C2=A0 but a &=
#39;replace' on the parent container can be used for this purpose.
=C2=A0 =C2=A0 (container of list or leaf-list)
=C2=A0- cont=
ainer servers as a conceptual 'root' for external augments

Andy

=

On Mon, Dec 14, 2015 at 5:56 PM, Christian H=
opps <chopps@chopps.org> wrote:


Some models seem to place a single list of things inside a container also n=
amed after the items in the list, e.g.,



+--ro modulename

=C2=A0 +--rw ribs

=C2=A0 =C2=A0 =C2=A0+--rw rib* [name]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--r=
w name 

I don't see the purpose of these containers. It seems to me that one ca=
n model and query the exact same data without the outer container. That is,=




+--ro modulename

=C2=A0 +--rw rib* [name]=C2=A0 =C2=A0 =C2=A0 +--rw name 

Is there something useful about these containers that I've missed, as i=
t's a fairly common pattern in the models I've been looking at.=C2=
=A0 =C2=A0Example comparisons below.. 

Thanks,

Chris.





w/ container: 

=C2=A0 =C2=A0<modulename>=C2=A0 =C2=A0 =C2=A0 <ribs>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 <rib>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>=
;foo</name>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </rib> <rib>=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>bar</name>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 </rib> ...=C2=A0 =C2=A0 =C2=A0 </ribs>=C2=A0 =C2=A0 =
</modulename> 

w/o container: 

=C2=A0 =C2=A0<modulename>

=C2=A0 =C2=A0 =C2=A0<rib>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>foo&=
lt;/name>=C2=A0 =C2=A0 =C2=A0 </rib> <rib>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 <name>bar</name>=C2=A0 =C2=A0 =C2=A0 </rib> ..=
.=C2=A0 =C2=A0 </modulename> 

Likewise if you want to fetch all ribs you can either way:



=C2=A0 =C2=A0<filter>

=C2=A0 =C2=A0 =C2=A0<modulename>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<ribs/>

=C2=A0 =C2=A0 =C2=A0</modulename>

=C2=A0 =C2=A0</filter> 

or



=C2=A0 =C2=A0<filter>

=C2=A0 =C2=A0 =C2=A0<modulename>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<rib/>

=C2=A0 =C2=A0 =C2=A0</modulename>

=C2=A0 =C2=A0</filter> 

Or a particular rib



=C2=A0 =C2=A0<filter>

=C2=A0 =C2=A0 =C2=A0<modulename>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<ribs>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &=
lt;rib>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>foo</nam=
e>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</rib>=C2=A0 =C2=A0 =C2=A0 =C2=A0 &=
lt;/ribs>

=C2=A0 =C2=A0 =C2=A0</modulename>

=C2=A0 =C2=A0</filter> 

or



=C2=A0 =C2=A0<filter>

=C2=A0 =C2=A0 =C2=A0<modulename>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <rib&g=
t;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>foo</name>

=C2=A0 =C2=A0 =C2=A0 =C2=A0</rib>

=C2=A0 =C2=A0 =C2=A0</modulename>

=C2=A0 =C2=A0</filter> 

Using xpath:



=C2=A0 =C2=A0/modulename/ribs/rib[name=3D'foo'] 

or



=C2=A0 =C2=A0/modulename/rib[name=3D'foo']


_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a11402600241d5f0526e6925e--


From nobody Mon Dec 14 19:17:36 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1B41B2A05 for ; Mon, 14 Dec 2015 19:17:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 SG1Qu2DMJTsS for ; Mon, 14 Dec 2015 19:17:33 -0800 (PST)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 628821B2A04 for ; Mon, 14 Dec 2015 19:17:33 -0800 (PST)
Received: by mail-io0-x22b.google.com with SMTP id q126so5691307iof.2 for ; Mon, 14 Dec 2015 19:17:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I+T94xqCiP33TGztMUeG29w4MJShTl1TIJHL3wgoauM=; b=ldqVmJW2e5ENOwDqq+EEEq15YwOi2LB7NBijL0/CWiS9MWDgzii4N9LiX7938z/hVE 7F6cdN+0NDTcsuo/oH2qtivEioLqy6vXwK1qov00FjDwBRWw6RhMocVDVl+Xb8pWFAdC c715J2K+4sE8DWDI+kXbGyGc0d1n57O+lnZZMwbsJLStHiC6AlHq/PLYKWFBrX4KLzuW c9drp60byiIxw92QPix6znSkugfxJJpb6kwE/268YKfngMbbq4nvVScsC61gB6HTJonk 0a45Zc5Q0I3KsM8htm/m2HWjbJ+KMj5pxF7By3/r1X5s/+fI/yGKg+zJpL2+ACwwdda9 3ZgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=I+T94xqCiP33TGztMUeG29w4MJShTl1TIJHL3wgoauM=; b=FfGdodQoxghuUe3yDqepMUyryT51EWCcQWcNhPU56pBBmanAQ9EOfmLVtVes8qzcA8 jQHIxT205rBlvcuNTDJHHxryPDNxAosWNAnPP5WXihDRSa4GPLguINL8CFMX1s0J00qF kjRs0LhmU2d4CL6HhJgJMYlh+ku9ynh5NqlnJJSQbmQsLSGEY/G7wtBylE0e9Qsj1k04 qPfQJ8Spd5DDvf6kwKmtFCE1e6+qN7HceNKhqqrVtS7fiyLOlbbZign+I218IsEEXCRi 0+shx8u3qAFPWJ+jAuD+Tcs9/2pj6eRY/IgCJ+/dHpztKdyXyHGJtE83m/7lxLDCSV/Y w0+g==
X-Gm-Message-State: ALoCoQmDmUf+IR7P/bLixWyoJaciqEXSaDImEASwQ1dIaxKlOj9upbbeQEySUCNTQnhxelNsOXdy0LyyF6ZuxMWSUPcVLkz/2FBMT1qKL9r1+7zYQXvKpcw=
MIME-Version: 1.0
X-Received: by 10.107.11.147 with SMTP id 19mr31288252iol.165.1450149452696; Mon, 14 Dec 2015 19:17:32 -0800 (PST)
Received: by 10.36.38.133 with HTTP; Mon, 14 Dec 2015 19:17:32 -0800 (PST)
In-Reply-To: 
References:  
Date: Mon, 14 Dec 2015 19:17:32 -0800
Message-ID: 
From: Anees Shaikh 
To: Andy Bierman 
Content-Type: multipart/alternative; boundary=001a113deb240029970526e73b29
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Guidance on list vs. container of list
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Dec 2015 03:17:35 -0000

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

hi Chris, in OpenConfig models we use enclosing containers on lists based
on feedback from some implementors who claimed that it made it more
efficient to, for example, retrieve the entire list (ask for the
container), retrieve the keys in the list (ask for the list node), or
retrieve a particular element of the list (specify the key).

Aside from some stuttering in the paths (which can be a little annoying but
I don't expect to write the config instances by hand), there didn't seem to
be a major downside.  So we try to be consistent across the models with
this approach.  After getting some more experience with the
implementations, we might revisit.

thanks.
-- Anees

On Mon, Dec 14, 2015 at 6:30 PM, Andy Bierman  wrote:

> Hi,
>
> Use of NP-containers are subjective, based on how you
> want to organize your data.  The extra layer of containment
> may be a waste, but it sometimes has a purpose
>
>   - 2 or more sibling lists with lots of entries can be mixed in JSON,
>     so putting each list in its container prevents that.
>  - There is no standard way to 'delete-all' in NETCONF or RESTCONF
>     but a 'replace' on the parent container can be used for this purpose.
>     (container of list or leaf-list)
>  - container servers as a conceptual 'root' for external augments
>
> Andy
>
>
> On Mon, Dec 14, 2015 at 5:56 PM, Christian Hopps 
> wrote:
>
>>
>> Some models seem to place a single list of things inside a container also
>> named after the items in the list, e.g.,
>>
>> +--ro modulename
>>   +--rw ribs
>>      +--rw rib* [name]         +--rw name
>> I don't see the purpose of these containers. It seems to me that one can
>> model and query the exact same data without the outer container. That is,
>>
>> +--ro modulename
>>   +--rw rib* [name]      +--rw name
>> Is there something useful about these containers that I've missed, as
>> it's a fairly common pattern in the models I've been looking at.   Example
>> comparisons below..
>> Thanks,
>> Chris.
>>
>>
>> w/ container:
>>                            foo
>>            bar         ...      
>> 
>> w/o container:
>>    
>>              foo       
>> bar       ...    
>> Likewise if you want to fetch all ribs you can either way:
>>
>>    
>>      
>>        
>>      
>>    
>> or
>>
>>    
>>      
>>        
>>      
>>    
>> Or a particular rib
>>
>>    
>>      
>>                              foo
>>                  
>>      
>>    
>> or
>>
>>    
>>                        foo
>>        
>>      
>>    
>> Using xpath:
>>
>>    /modulename/ribs/rib[name='foo']
>> or
>>
>>    /modulename/rib[name='foo']
>>
>> _______________________________________________
>> 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
>
>

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


hi Chris, in OpenConfig models we use enclosing containers=
 on lists based on feedback from some implementors who claimed that it made=
 it more efficient to, for example, retrieve the entire list (ask for the c=
ontainer), retrieve the keys in the list (ask for the list node), or retrie=
ve a particular element of the list (specify the key).

A=
side from some stuttering in the paths (which can be a little annoying but =
I don't expect to write the config instances by hand), there didn't=
 seem to be a major downside.=C2=A0 So we try to be consistent across the m=
odels with this approach.=C2=A0 After getting some more experience with the=
 implementations, we might revisit.

thanks.
<=
div>-- Anees

On Mon, Dec 14, 2015 at 6:30 PM, Andy Bierman <=
andy@yumaworks.com<=
/a>> wrote:
Hi=
,

Use of NP-containers are subjective, based on how you<=
/div>
want to organize your data.=C2=A0 The extra layer of containment<=
/div>
may be a waste, but it sometimes has a purpose

=C2=A0 - 2 or more sibling lists with lots of entries can be mixed i=
n JSON,
=C2=A0 =C2=A0 so putting each list in its container preve=
nts that.
=C2=A0- There is no standard way to 'delete-all'=
; in NETCONF or RESTCONF
=C2=A0 =C2=A0 but a 'replace' on=
 the parent container can be used for this purpose.
=C2=A0 =C2=A0=
 (container of list or leaf-list)
=C2=A0- container servers as a =
conceptual 'root' for external augments

An=
dy




Some models seem to place a single list of things inside a container also n=
amed after the items in the list, e.g.,



+--ro modulename

=C2=A0 +--rw ribs

=C2=A0 =C2=A0 =C2=A0+--rw rib* [name]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--r=
w name 

I don't see the purpose of these containers. It seems to me that one ca=
n model and query the exact same data without the outer container. That is,=




+--ro modulename

=C2=A0 +--rw rib* [name]=C2=A0 =C2=A0 =C2=A0 +--rw name 

Is there something useful about these containers that I've missed, as i=
t's a fairly common pattern in the models I've been looking at.=C2=
=A0 =C2=A0Example comparisons below.. 

Thanks,

Chris.





w/ container: 

=C2=A0 =C2=A0<modulename>=C2=A0 =C2=A0 =C2=A0 <ribs>=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 <rib>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>=
;foo</name>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </rib> <rib>=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>bar</name>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 </rib> ...=C2=A0 =C2=A0 =C2=A0 </ribs>=C2=A0 =C2=A0 =
</modulename> 

w/o container: 

=C2=A0 =C2=A0<modulename>

=C2=A0 =C2=A0 =C2=A0<rib>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>foo&=
lt;/name>=C2=A0 =C2=A0 =C2=A0 </rib> <rib>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 <name>bar</name>=C2=A0 =C2=A0 =C2=A0 </rib> ..=
.=C2=A0 =C2=A0 </modulename> 

Likewise if you want to fetch all ribs you can either way:



=C2=A0 =C2=A0<filter>

=C2=A0 =C2=A0 =C2=A0<modulename>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<ribs/>

=C2=A0 =C2=A0 =C2=A0</modulename>

=C2=A0 =C2=A0</filter> 

or



=C2=A0 =C2=A0<filter>

=C2=A0 =C2=A0 =C2=A0<modulename>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<rib/>

=C2=A0 =C2=A0 =C2=A0</modulename>

=C2=A0 =C2=A0</filter> 

Or a particular rib



=C2=A0 =C2=A0<filter>

=C2=A0 =C2=A0 =C2=A0<modulename>

=C2=A0 =C2=A0 =C2=A0 =C2=A0<ribs>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 &=
lt;rib>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>foo</nam=
e>

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</rib>=C2=A0 =C2=A0 =C2=A0 =C2=A0 &=
lt;/ribs>

=C2=A0 =C2=A0 =C2=A0</modulename>

=C2=A0 =C2=A0</filter> 

or



=C2=A0 =C2=A0<filter>

=C2=A0 =C2=A0 =C2=A0<modulename>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <rib&g=
t;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>foo</name>

=C2=A0 =C2=A0 =C2=A0 =C2=A0</rib>

=C2=A0 =C2=A0 =C2=A0</modulename>

=C2=A0 =C2=A0</filter> 

Using xpath:



=C2=A0 =C2=A0/modulename/ribs/rib[name=3D'foo'] 

or



=C2=A0 =C2=A0/modulename/rib[name=3D'foo']


_______________________________________________

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





--001a113deb240029970526e73b29--


From nobody Tue Dec 15 00:41:19 2015
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 72EAA1A0052 for ; Tue, 15 Dec 2015 00:41:17 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.11.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151215084117.23362.41330.idtracker@ietfa.amsl.com>
Date: Tue, 15 Dec 2015 00:41:17 -0800
From: IETF Secretariat 
Archived-At: 
Subject: [netmod] Milestones changed for netmod WG
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Dec 2015 08:41:17 -0000

Changed milestone "Submit YANG 1.1 to the IESG", set due date to
January 2016 from October 2015.

URL: https://datatracker.ietf.org/wg/netmod/charter/


From nobody Tue Dec 15 02:17:39 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8A11A1AB3 for ; Tue, 15 Dec 2015 02:17:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 1tMDUjmNi6T5 for ; Tue, 15 Dec 2015 02:17:37 -0800 (PST)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C87951A1B23 for ; Tue, 15 Dec 2015 02:17:35 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2BTBQA3Q8ZV/xUHmMZbGQEBAYJTLFRpBoMeplAGlUOFeQIcgQo7EQEBAQEBAQGBCoQjAQEBAQMSERE6CwwEAgEIDQEDBAEBAQICBh0DAgICMBQBCAgCBAENBQgaiAwBDKxpilaVZAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSKEfYUyhFgxBwaCYy+BFAWVCwGFAYkqhzCNHoNmFw+DfW+BSIEEAQEB
X-IPAS-Result: A2BTBQA3Q8ZV/xUHmMZbGQEBAYJTLFRpBoMeplAGlUOFeQIcgQo7EQEBAQEBAQGBCoQjAQEBAQMSERE6CwwEAgEIDQEDBAEBAQICBh0DAgICMBQBCAgCBAENBQgaiAwBDKxpilaVZAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEgSKEfYUyhFgxBwaCYy+BFAWVCwGFAYkqhzCNHoNmFw+DfW+BSIEEAQEB
X-IronPort-AV: E=Sophos;i="5.15,634,1432612800"; d="scan'208";a="156447953"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 15 Dec 2015 05:17:34 -0500
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 15 Dec 2015 05:17:34 -0500
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0174.001; Tue, 15 Dec 2015 05:17:32 -0500
From: "Romascanu, Dan (Dan)" 
To: Benoit Claise , Nadeau Thomas 
Thread-Topic: [netmod] Broadband Forum intention of using ietf-entity YANG module
Thread-Index: AQHRNpshQUCi08H7RUqovlafkn4MmZ7Kyl6AgAELpeA=
Date: Tue, 15 Dec 2015 10:17:31 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BEC7616@AZ-FFEXMB04.global.avaya.com>
References: <3D09C93F-EA97-4E60-B89C-E077CA1DD66B@broadband-forum.org> <6E0FC5E2-AC0C-40B8-BB46-44B9877CE39A@lucidvision.com> <9904FB1B0159DA42B0B887B7FA8119CA6BEC13F2@AZ-FFEXMB04.global.avaya.com>  <566F15F3.4060408@cisco.com>
In-Reply-To: <566F15F3.4060408@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.48]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Broadband Forum intention of using ietf-entity YANG module
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Dec 2015 10:17:38 -0000

U28sIGxldCdzIGRvIGl0LiBUb20sIG9yIG9uZSBvZiB0aGUgb3RoZXIgY2hhaXJzIC0geW91IG5l
ZWQgdG8gcnVuIHRoaXMuIA0KDQpSZWdhcmRzLA0KDQpEYW4NCg0KDQo+IC0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQo+IEZyb206IEJlbm9pdCBDbGFpc2UgW21haWx0bzpiY2xhaXNlQGNpc2Nv
LmNvbV0NCj4gU2VudDogTW9uZGF5LCBEZWNlbWJlciAxNCwgMjAxNSA5OjE4IFBNDQo+IFRvOiBO
YWRlYXUgVGhvbWFzOyBSb21hc2NhbnUsIERhbiAoRGFuKQ0KPiBDYzogbmV0bW9kQGlldGYub3Jn
DQo+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBCcm9hZGJhbmQgRm9ydW0gaW50ZW50aW9uIG9mIHVz
aW5nIGlldGYtZW50aXR5IFlBTkcNCj4gbW9kdWxlDQo+IA0KPiANCj4gPiAJSSBwZXJzb25hbGx5
IGRvbuKAmXQgc2VlIGFueXRoaW5nIHRoYXQgcHJldmVudHMgdGhpcy4NCj4gU2FtZSBvcGluaW9u
IGhlcmUuDQo+IA0KPiBSZWdhcmRzLCBCZW5vaXQNCj4gPg0KPiA+IAnigJRUb20NCj4gPg0KPiA+
PiBPbiBEZWMgMTMsIDIwMTU6Njo1NiBBTSwgYXQgNjo1NiBBTSwgUm9tYXNjYW51LCBEYW4gKERh
bikNCj4gPGRyb21hc2NhQGF2YXlhLmNvbT4gd3JvdGU6DQo+ID4+DQo+ID4+IENvbmNlcm5pbmcg
dGhlICdkcmFmdCBzdGF0dXMnIC0gYW55dGhpbmcgcHJldmVudHMgdGhlIHdnIGZyb20gcnVubmlu
ZyBhDQo+IHNob3J0IGNvbnNlbnN1cyBjYWxsIGFuZCBhZGRpbmcgdGhpcyBpdGVtIHRvIHRoZSBu
ZXRtb2QgbWlsZXN0b25lcz8NCj4gPj4NCj4gPj4gUmVnYXJkcywNCj4gPj4NCj4gPj4gRGFuDQo+
ID4+DQo+ID4+DQo+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4gRnJvbTog
bmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOYWRl
YXUNCj4gPj4+IFRob21hcw0KPiA+Pj4gU2VudDogRnJpZGF5LCBEZWNlbWJlciAxMSwgMjAxNSA0
OjI3IFBNDQo+ID4+PiBUbzogV2lsbGlhbSBMdXB0b24NCj4gPj4+IENjOiBuZXRtb2RAaWV0Zi5v
cmcNCj4gPj4+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBCcm9hZGJhbmQgRm9ydW0gaW50ZW50aW9u
IG9mIHVzaW5nIGlldGYtZW50aXR5DQo+ID4+PiBZQU5HIG1vZHVsZQ0KPiA+Pj4NCj4gPj4+DQo+
ID4+PiAJRGVwZW5kYW5jZSBvbiAxLjEgc2hvdWxkIG5vdCBiZSBhbiBpc3N1ZSBhcyB0aGF0IGlz
IGFsbW9zdCByZWFkeSB0bw0KPiA+Pj4gYmUgYXBwcm92ZWQuIFlvdSBzaG91bGQgYmUgYnVpbGRp
bmcgeW91ciBtb2RlbCB0byBjb21wbHkgd2l0aCB0aGUgMS4xDQo+IHJ1bGVzLg0KPiA+Pj4NCj4g
Pj4+IAnigJRUb20NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4+IE9uIERlYyAxMSwgMjAxNTo4OjAwIEFN
LCBhdCA4OjAwIEFNLCBXaWxsaWFtIEx1cHRvbg0KPiA+Pj4gPHdsdXB0b25AYnJvYWRiYW5kLWZv
cnVtLm9yZz4gd3JvdGU6DQo+ID4+Pj4gQWxsLA0KPiA+Pj4+DQo+ID4+Pj4gVGhlIEJyb2FkYmFu
ZCBGb3J1bSB3b3VsZCBsaWtlIHRvIHVzZSB0aGUgaWV0Zi1lbnRpdHkgWUFORyBtb2R1bGUNCj4g
Pj4+IChjdXJyZW50bHkgZHJhZnQtZW50aXR5ZHQtbmV0bW9kLWVudGl0eSkgZm9yIGVxdWlwbWVu
dCBtYW5hZ2VtZW50DQo+ID4+PiBidXQgd2UgYXJlIGEgYml0IGNvbmNlcm5lZCBhYm91dCBpdHMg
ZHJhZnQgc3RhdHVzIGFuZCBpdHMgZGVwZW5kZW5jZSBvbg0KPiBZQU5HIDEuMS4NCj4gPj4+IEFu
eSBhZHZpY2Ugb3IgcmVhc3N1cmFuY2U/DQo+ID4+Pj4gVGhhbmtzLA0KPiA+Pj4+IFdpbGxpYW0N
Cj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+
IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiBodHRwczovL3Vy
bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX193d3cuaWV0Zi5v
cmdfbWFpbA0KPiA+DQo+IG1hbl9saXN0aW5mb19uZXRtb2QmZD1CUUlEYVEmYz1CRnBXUXc4YnN1
S3BsMVNnaVpINjRRJnI9STRkekd4DQo+IFIzMU9jTlhDSmZRenZsc2lMUWZ1Y0JYUnVjUHZkcnBo
cEJzRkEmbT05aktjUjJFYktEM2xiNzN0Y2lKTUpBazBKNg0KPiAyZFFBYnNVXzRSODV6bHVYcyZz
PWVCbGtPWmU0YzVJWE1vel8yWUpuSUtnbHViTkJEUW1TMEVqMDNBbDhtZUkNCj4gJmU9DQoNCg==


From nobody Tue Dec 15 03:38:03 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EC41A802E for ; Tue, 15 Dec 2015 03:38:02 -0800 (PST)
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
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 SgLRzRBwu9VR for ; Tue, 15 Dec 2015 03:38:00 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E4D2A1A701D for ; Tue, 15 Dec 2015 03:37:59 -0800 (PST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 130361CC008F; Tue, 15 Dec 2015 12:37:59 +0100 (CET)
From: Ladislav Lhotka 
To: Andy Bierman , Christian Hopps 
In-Reply-To: 
References:  
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Tue, 15 Dec 2015 12:37:57 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Guidance on list vs. container of list
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Dec 2015 11:38:02 -0000

Andy Bierman  writes:

> Hi,
>
> Use of NP-containers are subjective, based on how you
> want to organize your data.  The extra layer of containment
> may be a waste, but it sometimes has a purpose
>
>   - 2 or more sibling lists with lots of entries can be mixed in JSON,
>     so putting each list in its container prevents that.

No, in JSON all list entries are always nicely packed in an array. It is
the XML encoding where entries of two lists can be interleaved.

For example, if we have

list foo { ... }
list bar { ... }

then JSON encoding is always

"foo": [...foo entries...]
"bar": [...bar entries...]

whereas in XML we can have, e.g.

...
...
...
...
...

Lada

>  - There is no standard way to 'delete-all' in NETCONF or RESTCONF
>     but a 'replace' on the parent container can be used for this purpose.
>     (container of list or leaf-list)
>  - container servers as a conceptual 'root' for external augments
>
> Andy
>
>
> On Mon, Dec 14, 2015 at 5:56 PM, Christian Hopps  wrote:
>
>>
>> Some models seem to place a single list of things inside a container also
>> named after the items in the list, e.g.,
>>
>> +--ro modulename
>>   +--rw ribs
>>      +--rw rib* [name]         +--rw name
>> I don't see the purpose of these containers. It seems to me that one can
>> model and query the exact same data without the outer container. That is,
>>
>> +--ro modulename
>>   +--rw rib* [name]      +--rw name
>> Is there something useful about these containers that I've missed, as it's
>> a fairly common pattern in the models I've been looking at.   Example
>> comparisons below..
>> Thanks,
>> Chris.
>>
>>
>> w/ container:
>>                            foo
>>            bar         ...      
>> 
>> w/o container:
>>    
>>              foo       
>> bar       ...    
>> Likewise if you want to fetch all ribs you can either way:
>>
>>    
>>      
>>        
>>      
>>    
>> or
>>
>>    
>>      
>>        
>>      
>>    
>> Or a particular rib
>>
>>    
>>      
>>                              foo
>>                  
>>      
>>    
>> or
>>
>>    
>>                        foo
>>        
>>      
>>    
>> Using xpath:
>>
>>    /modulename/ribs/rib[name='foo']
>> or
>>
>>    /modulename/rib[name='foo']
>>
>> _______________________________________________
>> 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, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Tue Dec 15 04:34:47 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 492E81A1B8C for ; Tue, 15 Dec 2015 04:34:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 XoSnSAlJrajw for ; Tue, 15 Dec 2015 04:34:44 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 913BC1A1ABF for ; Tue, 15 Dec 2015 04:34:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450182857; bh=2Te2/RIe62EGpqgtrfiaGDO0Sz/1F5I7tvOYcEUJbko=; h=From:Subject:Date:To; b=lTCGx0L2lUX+XGxu71gPpktj+GqeOrf97Ufu1nIcYtBr402usNGjuM8V26n4TwIg4 kz2ebSLA0o09AjqSeT3pBkEVBofpWbFjYyQ78jwhxLxFXo75Ib6fk0bPSuHAf3M+e2 tZSMuAjdj0EpR0M/Ofsn/FjypWm912oGf7+FtHWI=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
From: Nadeau Thomas 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <0C987A22-5602-438D-B42D-82C8476AA513@lucidvision.com>
Date: Tue, 15 Dec 2015 07:34:41 -0500
To: netmod WG 
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=5 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 214, in=2863, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Subject: [netmod] call for consensus to adopt draft-entitydt-netmod-entity as NETMOD WG draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Dec 2015 12:34:46 -0000

	NETMOD:

	The Broadband Forum and the members of the design team who =
worked on the
IETF Entity module have asked that the working group considerthe =
ietf-entity YANG module
(currently =
https://datatracker.ietf.org/doc/draft-entitydt-netmod-entity/ which is
still in individual draft status) as a working group item.

	Should we move to adopt draft-entitydt-netmod-entity as a WG =
item and=20
correspondingly add this to the WG charter as a milestone?  Please =
comment by
Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs will=20=

gauge whether or not there is consensus to move forward with the =
document.

	=E2=80=94Tom


From nobody Tue Dec 15 05:23:33 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D06A1A88FF for ; Tue, 15 Dec 2015 05:23:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 b1PwtbUMmTHr for ; Tue, 15 Dec 2015 05:23:30 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C0E1A88F7 for ; Tue, 15 Dec 2015 05:23:30 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:3866:58f8:a503:2482] (unknown [IPv6:2001:718:1a02:1:3866:58f8:a503:2482]) by mail.nic.cz (Postfix) with ESMTPSA id 1206F181A6B; Tue, 15 Dec 2015 14:23:28 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450185808; bh=+EHnFLCmQBSMP8Ok1WNLrfhf+Tlb59/a5BHnI/Gmxqc=; h=From:Date:To; b=kw6d9D77FeWcmhuoVKWy47tCmO1Iom/eQ8aRtRbyGS3S++SaQbYGWnlymfWnJSRsr EcTbnpVT4JJgoMLAx+O3G1tHI6Le5DY9Q74ZE4pU5yXDsk9OkM/BleL2OAIVVlIDzg mFPlR2xgZoQIIRn3WhG69e51BmDMKZ3iFMfnQasc=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <0C987A22-5602-438D-B42D-82C8476AA513@lucidvision.com>
Date: Tue, 15 Dec 2015 14:23:29 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <23D79879-556D-4523-8CAB-845C10BC76CC@nic.cz>
References: <0C987A22-5602-438D-B42D-82C8476AA513@lucidvision.com>
To: Thomas Nadeau 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] call for consensus to adopt draft-entitydt-netmod-entity as NETMOD WG draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Dec 2015 13:23:32 -0000

> On 15 Dec 2015, at 13:34, Nadeau Thomas  =
wrote:
>=20
>=20
> 	NETMOD:
>=20
> 	The Broadband Forum and the members of the design team who =
worked on the
> IETF Entity module have asked that the working group considerthe =
ietf-entity YANG module
> (currently =
https://datatracker.ietf.org/doc/draft-entitydt-netmod-entity/ which is
> still in individual draft status) as a working group item.
>=20
> 	Should we move to adopt draft-entitydt-netmod-entity as a WG =
item and=20
> correspondingly add this to the WG charter as a milestone?  Please =
comment by
> Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs will=20=

> gauge whether or not there is consensus to move forward with the =
document.

I would strongly prefer to finish the existing items first, or at least =
the critical ones on which other work depends. Adding more items would =
mean that both old and new items receive less attention on the average. =
We already have at most one or two reviews per WGLC, and this is IMO =
insufficient.

Lada

>=20
> 	=E2=80=94Tom
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Tue Dec 15 08:48:41 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D28941A9096 for ; Tue, 15 Dec 2015 08:48:40 -0800 (PST)
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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 4milCCUYUN8P for ; Tue, 15 Dec 2015 08:48:39 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0776.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:776]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52171A8713 for ; Tue, 15 Dec 2015 08:48:38 -0800 (PST)
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 (TLS) id 15.1.355.16; Tue, 15 Dec 2015 16:48:21 +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.0355.012; Tue, 15 Dec 2015 16:48:21 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft
Thread-Index: AQHRN1hnQ70LlCEAQ02XjL34VtayGw==
Date: Tue, 15 Dec 2015 16:48:21 +0000
Message-ID: <411F084C-B435-4CBA-93C7-AA4213958A21@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.151105
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.13]
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:i+2e1kgvsLhhJuRwBo1SyK5Ul376PeXaW0M+QU4f9p1o9Xbd94U3U9Jp/5JOLDx3C29Lsik+F48xs2+LbWheHPNEdzOz9iB/zW3kKeK35U3qlVqdq4MMcOJhggPcTjDibFwKt6kMoAHbH900JRi/jQ==; 24:XeAau9sTlldC/sGIUzobTcBmuO4i5fOjnDpC5bgw7mG7/+SIsbS1KpGFUy06V3JX/P5eS6YP6d6lvtdTsisSMOm7M7aIETrlA/HeitbFWPM=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1442;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; 
x-forefront-prvs: 07915F544A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(189002)(199003)(4001350100001)(230783001)(229853001)(97736004)(1096002)(10400500002)(2900100001)(2501003)(1220700001)(586003)(101416001)(82746002)(99286002)(102836003)(6116002)(122556002)(83506001)(86362001)(66066001)(83716003)(2351001)(3846002)(106116001)(77096005)(33656002)(107886002)(105586002)(106356001)(16236675004)(11100500001)(189998001)(110136002)(50986999)(54356999)(92566002)(40100003)(87936001)(5008740100001)(5001960100002)(5002640100001)(450100001)(36756003)(1730700002)(5004730100002)(81156007)(104396002); 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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_411F084CB4354CBA93C7AA4213958A21junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2015 16:48:21.2184 (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: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Dec 2015 16:48:41 -0000

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

DQpUaGUgbWludXRlcyBmb3IgSUVURiA5NSBzaG93IHRoYXQgdGhlcmUgd2FzIGluLXJvb20gc3Vw
cG9ydCBmb3IgYWRvcHRpbmcgZHJhZnQtd2lsdG9uLW5ldG1vZC1pbnRmLWV4dC15YW5nIGFzIGEg
V0cgZHJhZnQuICAgVGhlIG1pbnV0ZXMgYWxzbyBzaG93IHRoYXQgdGhpcyBkZWNpc2lvbiB3b3Vs
ZCBiZSBjb25maXJtZWQgb24gdGhlIG1haWxpbmcgbGlzdCwgd2hpY2ggSSBhbSBkb2luZyBub3cu
DQoNClNob3VsZCB3ZSBtb3ZlIHRvIGFkb3B0IGRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQt
eWFuZyBhcyBhIFdHIGl0ZW0gYW5kIGNvcnJlc3BvbmRpbmdseSBhZGQgdGhpcyB0byB0aGUgV0cg
Y2hhcnRlciBhcyBhIG1pbGVzdG9uZT8gIFBsZWFzZSBjb21tZW50IGJ5IFR1ZXNkYXksIERlY2Vt
YmVyIDIyLCAyMDE1IGF0IDlBTSBFU1QgYXQgd2hpY2ggdGltZSB0aGUgV0cgQ2hhaXJzIHdpbGwg
Z2F1Z2Ugd2hldGhlciBvciBub3QgdGhlcmUgaXMgY29uc2Vuc3VzIHRvIG1vdmUgZm9yd2FyZCB3
aXRoIHRoZSBkb2N1bWVudC4NCg0KVGhhbmtzLA0KS2VudA0KDQoNCg==

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+PGJy
Pg0KPC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+VGhlIG1pbnV0
ZXMgZm9yIElFVEYgOTUgc2hvdyB0aGF0IHRoZXJlIHdhcyBpbi1yb29tIHN1cHBvcnQgZm9yIGFk
b3B0aW5nJm5ic3A7PC9mb250PmRyYWZ0LXdpbHRvbi1uZXRtb2QtaW50Zi1leHQteWFuZyBhcyBh
IFdHIGRyYWZ0LiAmbmJzcDsgVGhlIG1pbnV0ZXMgYWxzbyBzaG93IHRoYXQgdGhpcyBkZWNpc2lv
biB3b3VsZCBiZSBjb25maXJtZWQgb24gdGhlIG1haWxpbmcgbGlzdCwgd2hpY2ggSQ0KIGFtIGRv
aW5nIG5vdy4gJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5TaG91bGQgd2Ug
bW92ZSB0byBhZG9wdCBkcmFmdC13aWx0b24tbmV0bW9kLWludGYtZXh0LXlhbmcgYXMgYSBXRyBp
dGVtIGFuZCBjb3JyZXNwb25kaW5nbHkgYWRkIHRoaXMgdG8gdGhlIFdHIGNoYXJ0ZXIgYXMgYSBt
aWxlc3RvbmU/ICZuYnNwO1BsZWFzZSBjb21tZW50IGJ5IFR1ZXNkYXksIERlY2VtYmVyIDIyLCAy
MDE1IGF0IDlBTSBFU1QgYXQgd2hpY2ggdGltZSB0aGUgV0cgQ2hhaXJzIHdpbGwgZ2F1Z2Ugd2hl
dGhlciBvciBub3QgdGhlcmUgaXMNCiBjb25zZW5zdXMgdG8gbW92ZSBmb3J3YXJkIHdpdGggdGhl
IGRvY3VtZW50LjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjxi
cj4NCjwvZm9udD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5U
aGFua3MsPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYi
PktlbnQ8L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5z
LXNlcmlmIj48YnI+DQo8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmksc2Fu
cy1zZXJpZiI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAw
LCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsi
Pg0KPGRpdiBpZD0iTUFDX09VVExPT0tfU0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5
Pg0KPC9odG1sPg0K

--_000_411F084CB4354CBA93C7AA4213958A21junipernet_--


From nobody Tue Dec 15 09:08:12 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75DA1A908D for ; Tue, 15 Dec 2015 09:08:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 mWdPPd48lV-4 for ; Tue, 15 Dec 2015 09:08:06 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 321411A8F3D for ; Tue, 15 Dec 2015 09:08:06 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9100D132B; Tue, 15 Dec 2015 18:08:04 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id T6oecqVQs2IV; Tue, 15 Dec 2015 18:08:03 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 15 Dec 2015 18:08:03 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 93A4F20055; Tue, 15 Dec 2015 18:08:03 +0100 (CET)
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 xtAhb2l8nOtt; Tue, 15 Dec 2015 18:08:02 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8ADF820056; Tue, 15 Dec 2015 18:08:02 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 197E3393E351; Tue, 15 Dec 2015 18:08:02 +0100 (CET)
Date: Tue, 15 Dec 2015 18:08:01 +0100
From: Juergen Schoenwaelder 
To: Kent Watsen 
Message-ID: <20151215170801.GA64085@elstar.local>
Mail-Followup-To: Kent Watsen , "netmod@ietf.org" 
References: <411F084C-B435-4CBA-93C7-AA4213958A21@juniper.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <411F084C-B435-4CBA-93C7-AA4213958A21@juniper.net>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Dec 2015 17:08:11 -0000

On Tue, Dec 15, 2015 at 04:48:21PM +0000, Kent Watsen wrote:
> 
> The minutes for IETF 95 show that there was in-room support for adopting draft-wilton-netmod-intf-ext-yang as a WG draft.   The minutes also show that this decision would be confirmed on the mailing list, which I am doing now.
> 
> Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG item and correspondingly add this to the WG charter as a milestone?  Please comment by Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs will gauge whether or not there is consensus to move forward with the document.
> 

This I-D contains some Ethernet specific definitions. Are we going to
define Ethernet specific things in the IETF or is IEEE ready to take
over data models for 'their' interfaces? In other words, what exactly
is the scope of this work?

And (likely depending on the answer to the first question), is it
meaningful to produce an interface extension module or is it better to
simply carefully revise the model we already have?

If we add something to the work of this WG, what will be realistic
milestones and how do we make sure we stay focused? Is there a need
for some prioritization?

/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 Dec 15 09:10:44 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD2081A8A3A for ; Tue, 15 Dec 2015 09:10:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 b64djkl_8QRj for ; Tue, 15 Dec 2015 09:10:41 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 4A6DB1A6F45 for ; Tue, 15 Dec 2015 09:10:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450199413; bh=aO0qO16yhA9eSHlhByVSi/gqmOUw6AGCGkkxOSCYuXc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=n8AdoVNgxQhUdeCiRO+mzYUvRD5NoUuxCitl71MHhShQCjxb8+RR4PpLpZfNPQf9R ADanCANSOv4fkrFem6LxIXTETtrd2Iqxp6zNVX2yT6hgzBWcvBr9E7xbTSJd/p0GSN jZXUigUAOX4C3GAqApLdts3Ur3QwGwiF0iWKXmM0=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Nadeau Thomas 
In-Reply-To: <20151215170801.GA64085@elstar.local>
Date: Tue, 15 Dec 2015 12:10:37 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <125DC20B-0D91-4B59-A7F4-3639E4A6726A@lucidvision.com>
References: <411F084C-B435-4CBA-93C7-AA4213958A21@juniper.net> <20151215170801.GA64085@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=8 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 214, in=2866, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Dec 2015 17:10:42 -0000

> On Dec 15, 2015:12:08 PM, at 12:08 PM, Juergen Schoenwaelder =
 wrote:
>=20
> On Tue, Dec 15, 2015 at 04:48:21PM +0000, Kent Watsen wrote:
>>=20
>> The minutes for IETF 95 show that there was in-room support for =
adopting draft-wilton-netmod-intf-ext-yang as a WG draft.   The minutes =
also show that this decision would be confirmed on the mailing list, =
which I am doing now.
>>=20
>> Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG =
item and correspondingly add this to the WG charter as a milestone?  =
Please comment by Tuesday, December 22, 2015 at 9AM EST at which time =
the WG Chairs will gauge whether or not there is consensus to move =
forward with the document.
>>=20
>=20
> This I-D contains some Ethernet specific definitions. Are we going to
> define Ethernet specific things in the IETF or is IEEE ready to take
> over data models for 'their' interfaces? In other words, what exactly
> is the scope of this work?

	The IEEE has officially started working on Ethernet models on
the public github repo here, so I suggest taking a look at that for any
overlaps.

	https://github.com/YangModels/yang/tree/master/experimental/ieee

	=E2=80=94Tom

>=20
> And (likely depending on the answer to the first question), is it
> meaningful to produce an interface extension module or is it better to
> simply carefully revise the model we already have?
>=20
> If we add something to the work of this WG, what will be realistic
> milestones and how do we make sure we stay focused? Is there a need
> for some prioritization?
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Dec 15 11:12:14 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906EA1A6F42 for ; Tue, 15 Dec 2015 11:12:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 AK0I0PeXY7qT for ; Tue, 15 Dec 2015 11:12:10 -0800 (PST)
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 2EB6E1A90D4 for ; Tue, 15 Dec 2015 11:12:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4252; q=dns/txt; s=iport; t=1450206730; x=1451416330; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=0OPngo1nAk1KxFvJv403KimZldpdCyyQw+39knSshR4=; b=FIAPpSSioEJKcEXyNyLnF++kIOI72nvbhqU/r73vYBx/7747/W6IJkZ+ W53ddFUi7ocHFzmBjEhqsSsYocVFn6KosrnIxn0mIsEkfd5laLGKBoDrz 1FEVyYfz1Yw3lHTAKv9NACbJRHV2C9gJfR9y+/1yFYLzhgrThuvRXcUoP M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQDkZHBW/xbLJq1ehAy8LYIZAQ2BY?= =?us-ascii?q?yGFbAKCABQBAQEBAQEBgQqENAEBAQMBHRs2ChELDgoJFg8JAwIBAgFFBgEMCAE?= =?us-ascii?q?BiCMIDr4KAQEBAQEBAQEBAQEBAQEBAQEBAQEVBIZWhH2JQAEEh1yPIIU5iA+BX?= =?us-ascii?q?IRFgwWQAIN0HwEBQoJEgUA+hSgBAQE?=
X-IronPort-AV: E=Sophos;i="5.20,433,1444694400"; d="scan'208";a="639062382"
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; 15 Dec 2015 19:12:07 +0000
Received: from [10.63.23.129] (dhcp-ensft1-uk-vla370-10-63-23-129.cisco.com [10.63.23.129]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tBFJC7WK004926; Tue, 15 Dec 2015 19:12:07 GMT
To: Kent Watsen , "netmod@ietf.org" 
References: <411F084C-B435-4CBA-93C7-AA4213958A21@juniper.net> <20151215170801.GA64085@elstar.local>
From: Robert Wilton 
Message-ID: <56706607.9080606@cisco.com>
Date: Tue, 15 Dec 2015 19:12:07 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <20151215170801.GA64085@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Dec 2015 19:12:12 -0000

Hi Juergen,

Hopefully I can answer your questions inline ...

On 15/12/2015 17:08, Juergen Schoenwaelder wrote:
> On Tue, Dec 15, 2015 at 04:48:21PM +0000, Kent Watsen wrote:
>> The minutes for IETF 95 show that there was in-room support for adopting draft-wilton-netmod-intf-ext-yang as a WG draft.   The minutes also show that this decision would be confirmed on the mailing list, which I am doing now.
>>
>> Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG item and correspondingly add this to the WG charter as a milestone?  Please comment by Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs will gauge whether or not there is consensus to move forward with the document.
>>
> This I-D contains some Ethernet specific definitions. Are we going to
> define Ethernet specific things in the IETF or is IEEE ready to take
> over data models for 'their' interfaces? In other words, what exactly
> is the scope of this work?
There is an informal IEEE 802.3 Ethernet design team (that has the 
backing of the 802.3 WG chair, and that I'm part of) that is working on 
YANG models for Ethernet interfaces.  The intention is that this 
informal design team will become a formal IEEE 802.3 WG design team once 
it traverses the necessary IEEE 802.3 WG processes (i.e. likely to be 
sometime later on next year).  The exact scope of this project hasn't 
been defined yet, and can't formally be defined until the IEEE 802.3 WG 
agrees that we can do it, but my expectation is that the long term goal 
will surely be to define YANG models to cover all of the 802.3 work, 
although there may be various interim goals along the way.

In the interim, whilst we wait for the formal WG to be started, the 
Ethernet design team are working on Ethernet models in Github 
(https://github.com/8023YangDesignTeam/EthernetYang).

How does that overlap with draft-wilton-netmod-intf-ext-yang?  The basic 
answer is that it shouldn't and arguably doesn't.  The only thing that 
it defines related to Ethernet is three leaves related to MAC address 
(configured value, operational value, and burnt-in value) that are 
applicable to all interfaces that use Ethernet framing.  There are 
various types of interface that use Ethernet framing but are not 
Ethernet interfaces, nor necessarily defined in IEEE.  I.e. I'm thinking 
of interfaces where a VPLS instances terminates to a layer 3 forwarding 
instances, or where a pseudo-wire is terminated directly to a layer 3 
forwarding instance.  But at the end of the day, if this part of the 
draft needs to be defined as part of the IEEE 802.3 space then I think 
that would be fine too - I don't think that it should really be an 
issue, and I think that we can involve the necessary folks to ensure 
that this bit gets to the right home.

>
> And (likely depending on the answer to the first question), is it
> meaningful to produce an interface extension module or is it better to
> simply carefully revise the model we already have?
I'm not sure that I know the answer to this one.

Some of the extra configuration that is being defined by this module is 
more router specific, whereas I see the base interfaces model as 
potentially having a wider applicability across devices.

>
> If we add something to the work of this WG, what will be realistic
> milestones and how do we make sure we stay focused? Is there a need
> for some prioritization?
I believe that at least some of this configuration is required to 
configure networks in a reliable way, so I would have thought that we 
need to progress these models at the same time as the routing protocol 
models.

On a related note, any VPLS or Pseudowire models defined by IETF are 
basically going to be undeployable without 
draft-wilton-netmod-intf-vlan-yang-01 (or an equivalent) being defined 
because there will be no configuration mechanism to bind the 
classification of traffic from a particular VLAN to a VPLS instance.  
Note that I don't see that any models coming out of IEEE 802.1Q are 
likely to help here.  This point was also raised in PALS at IETF 94 by 
some of the folks working on, or reviewing, those models.

Thanks,
Rob


>
> /js
>


From nobody Tue Dec 15 11:19:14 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6366A1AC429 for ; Tue, 15 Dec 2015 11:19:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 4os62q73fIxk for ; Tue, 15 Dec 2015 11:19:11 -0800 (PST)
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 5C62A1AC432 for ; Tue, 15 Dec 2015 11:19:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2643; q=dns/txt; s=iport; t=1450207151; x=1451416751; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=vm3d/PZf7Ya1j5ds/868due6XOrMIMsWFxRE0PkJ/Yk=; b=UaWjY3p6JIFU0v+fYScPhLI/b5kupJttCyeCdWHgMx+88xpzD/ydERFq bHAnVzb58ZxC4bABlcnezdom8U8VYGloAe6RMWzX8NAodv1TDYfjYHTTS OaaRmbcAC8b8Ujpq4ZKvpKqCLemnmgbt8nqDv4gZIfH7z3PcqhtdAceNp 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQA2Z3BW/xbLJq1bA4QMbb1ZAQ2BY?= =?us-ascii?q?xcMhSBKAoIAFAEBAQEBAQGBCoQ1AQEEAQEBGgYPAQU2CgEOAgsOAggCAgUWCwI?= =?us-ascii?q?CCQMCAQIBCQwwBg0GAgEBiCsOrA+RfQEBAQEBAQEBAQEBAQEBAQEBAQEBARgEf?= =?us-ascii?q?YVVhH2EfCaCVYFJBZZ8hTmID4FchEWDBZN0HwEBQoJEgUA+NIR0AQEB?=
X-IronPort-AV: E=Sophos;i="5.20,433,1444694400"; d="scan'208";a="639062433"
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; 15 Dec 2015 19:19:08 +0000
Received: from [10.63.23.129] (dhcp-ensft1-uk-vla370-10-63-23-129.cisco.com [10.63.23.129]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tBFJJ8TL006048; Tue, 15 Dec 2015 19:19:08 GMT
To: Nadeau Thomas 
References: <411F084C-B435-4CBA-93C7-AA4213958A21@juniper.net> <20151215170801.GA64085@elstar.local> <125DC20B-0D91-4B59-A7F4-3639E4A6726A@lucidvision.com>
From: Robert Wilton 
Message-ID: <567067AC.9040706@cisco.com>
Date: Tue, 15 Dec 2015 19:19:08 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <125DC20B-0D91-4B59-A7F4-3639E4A6726A@lucidvision.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Dec 2015 19:19:13 -0000

Hi Tom,

On 15/12/2015 17:10, Nadeau Thomas wrote:
>> On Dec 15, 2015:12:08 PM, at 12:08 PM, Juergen Schoenwaelder  wrote:
>>
>> On Tue, Dec 15, 2015 at 04:48:21PM +0000, Kent Watsen wrote:
>>> The minutes for IETF 95 show that there was in-room support for adopting draft-wilton-netmod-intf-ext-yang as a WG draft.   The minutes also show that this decision would be confirmed on the mailing list, which I am doing now.
>>>
>>> Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG item and correspondingly add this to the WG charter as a milestone?  Please comment by Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs will gauge whether or not there is consensus to move forward with the document.
>>>
>> This I-D contains some Ethernet specific definitions. Are we going to
>> define Ethernet specific things in the IETF or is IEEE ready to take
>> over data models for 'their' interfaces? In other words, what exactly
>> is the scope of this work?
> 	The IEEE has officially started working on Ethernet models on
> the public github repo here, so I suggest taking a look at that for any
> overlaps.
>
> 	https://github.com/YangModels/yang/tree/master/experimental/ieee
The latest (work in progress) models are actually at:
https://github.com/8023YangDesignTeam/EthernetYang/tree/master/experimental/ieee/802.3

This repo is a direct fork of YangModels so that we can iterate the IEEE 
802.3 models at a faster pace, with an intention that we periodically 
fold the IEEE model updates back into YangModels when they have been 
reviewed and reached some level of stability and consensus in the design 
team.

Thanks,
Rob


>
> 	—Tom
>
>> And (likely depending on the answer to the first question), is it
>> meaningful to produce an interface extension module or is it better to
>> simply carefully revise the model we already have?
>>
>> If we add something to the work of this WG, what will be realistic
>> milestones and how do we make sure we stay focused? Is there a need
>> for some prioritization?
>>
>> /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
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Dec 15 11:28:01 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0901AC44E for ; Tue, 15 Dec 2015 11:27:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 nc3uyhzx_tRm for ; Tue, 15 Dec 2015 11:27:58 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 4CBF31AC447 for ; Tue, 15 Dec 2015 11:27:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450207650; bh=makECLiSOX6LKb64uiso1ZneghUT3oBPqB68fDKwINQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=gzKX1o7+nDkpBte6p8zuphBK5Oa6gYJ1zUkRIbXJb7we4I9czxSQZ0j8MziMWLjMc 0ggiNzGuplFOq3J4xr9vYScu0fh2O/pSbY13aE7l85yJE2HSgefi7C4UZF5j2mrhRM 1Fffq1Ui32hxohfp3Tu9R/qU8kad06ViHcmf7OmU=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Nadeau Thomas 
In-Reply-To: <567067AC.9040706@cisco.com>
Date: Tue, 15 Dec 2015 14:27:48 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F5F53BA-4459-46BD-8311-80C440E1A5BD@lucidvision.com>
References: <411F084C-B435-4CBA-93C7-AA4213958A21@juniper.net> <20151215170801.GA64085@elstar.local> <125DC20B-0D91-4B59-A7F4-3639E4A6726A@lucidvision.com> <567067AC.9040706@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=13 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 214, in=2871, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Dec 2015 19:28:00 -0000

Cool. Thanks for the update!

> On Dec 15, 2015:2:19 PM, at 2:19 PM, Robert Wilton  =
wrote:
>=20
> Hi Tom,
>=20
> On 15/12/2015 17:10, Nadeau Thomas wrote:
>>> On Dec 15, 2015:12:08 PM, at 12:08 PM, Juergen Schoenwaelder =
 wrote:
>>>=20
>>> On Tue, Dec 15, 2015 at 04:48:21PM +0000, Kent Watsen wrote:
>>>> The minutes for IETF 95 show that there was in-room support for =
adopting draft-wilton-netmod-intf-ext-yang as a WG draft.   The minutes =
also show that this decision would be confirmed on the mailing list, =
which I am doing now.
>>>>=20
>>>> Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG =
item and correspondingly add this to the WG charter as a milestone?  =
Please comment by Tuesday, December 22, 2015 at 9AM EST at which time =
the WG Chairs will gauge whether or not there is consensus to move =
forward with the document.
>>>>=20
>>> This I-D contains some Ethernet specific definitions. Are we going =
to
>>> define Ethernet specific things in the IETF or is IEEE ready to take
>>> over data models for 'their' interfaces? In other words, what =
exactly
>>> is the scope of this work?
>> 	The IEEE has officially started working on Ethernet models on
>> the public github repo here, so I suggest taking a look at that for =
any
>> overlaps.
>>=20
>> 	https://github.com/YangModels/yang/tree/master/experimental/ieee
> The latest (work in progress) models are actually at:
> =
https://github.com/8023YangDesignTeam/EthernetYang/tree/master/experimenta=
l/ieee/802.3
>=20
> This repo is a direct fork of YangModels so that we can iterate the =
IEEE 802.3 models at a faster pace, with an intention that we =
periodically fold the IEEE model updates back into YangModels when they =
have been reviewed and reached some level of stability and consensus in =
the design team.
>=20
> Thanks,
> Rob
>=20
>=20
>>=20
>> 	=E2=80=94Tom
>>=20
>>> And (likely depending on the answer to the first question), is it
>>> meaningful to produce an interface extension module or is it better =
to
>>> simply carefully revise the model we already have?
>>>=20
>>> If we add something to the work of this WG, what will be realistic
>>> milestones and how do we make sure we stay focused? Is there a need
>>> for some prioritization?
>>>=20
>>> /js
>>>=20
>>> --=20
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | =
Germany
>>> Fax:   +49 421 200 3103         
>>>=20
>>> _______________________________________________
>>> 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


From nobody Tue Dec 15 11:30:05 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D001ACC80 for ; Tue, 15 Dec 2015 11:30:04 -0800 (PST)
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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 VssB-NcE9X3W for ; Tue, 15 Dec 2015 11:30:02 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0782.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:782]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5951AC438 for ; Tue, 15 Dec 2015 11:30:02 -0800 (PST)
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1451.namprd05.prod.outlook.com (10.160.149.12) with Microsoft SMTP Server (TLS) id 15.1.355.16; Tue, 15 Dec 2015 19:29:41 +0000
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0355.012; Tue, 15 Dec 2015 19:29:41 +0000
From: Gert Grammel 
To: Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft
Thread-Index: AQHRN27xQ70LlCEAQ02XjL34VtayGw==
Date: Tue, 15 Dec 2015 19:29:41 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.9.151119
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [193.110.55.12]
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1451; 5:YLLfZO1c3r6Co9VWBQICqOSibV0j1DdqB/WLTqbVYXFhtk2tfTYZz2yXDldzfDJuN+etXm+CN3NfRFz6TqVDzq8X+LrWkHGSZlNqFTC2rb8oT9EjqNPITsnZtO89g6+Dry+rpi/sf1LkTwUoGOnrPg==; 24:o+hrDZO0DTiiWTyNDzUiopmNVX7JhSwD4+KeJ/ZsIYyhLIMvqiBgu1GrZtLo3lnSzu7yqoXOmu4BQt2J6i29ZWFAHG2hPqsrZkqul+jTePk=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1451;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:CY1PR0501MB1451; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1451; 
x-forefront-prvs: 07915F544A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(164054003)(19580405001)(4001350100001)(19580395003)(92566002)(40100003)(5001770100001)(97736004)(77096005)(5008740100001)(2900100001)(450100001)(189998001)(1941001)(81156007)(66066001)(5001960100002)(101416001)(5002640100001)(36756003)(50986999)(16236675004)(586003)(11100500001)(83506001)(102836003)(86362001)(107886002)(122556002)(105586002)(99286002)(87936001)(5004730100002)(3846002)(1096002)(6116002)(106116001)(54356999)(2501003)(106356001)(1220700001)(10400500002)(230783001)(94096001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1451; H:CY1PR0501MB1609.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)
Content-Type: multipart/alternative; boundary="_000_D29628A9C925ggrammeljunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2015 19:29:41.6193 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1451
Archived-At: 
Subject: Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Dec 2015 19:30:04 -0000

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

+1

From: netmod > on b=
ehalf of Kent Watsen >
Date: Tuesday 15 December 2015 17:48
To: "netmod@ietf.org" >
Subject: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-=
yang as NETMOD WG draft


The minutes for IETF 95 show that there was in-room support for adopting dr=
aft-wilton-netmod-intf-ext-yang as a WG draft.   The minutes also show that=
 this decision would be confirmed on the mailing list, which I am doing now=
.

Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG item and =
correspondingly add this to the WG charter as a milestone?  Please comment =
by Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs will g=
auge whether or not there is consensus to move forward with the document.

Thanks,
Kent



--_000_D29628A9C925ggrammeljunipernet_
Content-Type: text/html; charset="us-ascii"
Content-ID: <14B5D7103791AF4D873E0DDABD24D4EB@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable







+1









From: netmod <netmod-bounces@ietf.org> on behalf of Kent =
Watsen <kwatsen@juniper.net&g=
t;

Date: Tuesday 15 December 2015 17:4=
8

To: "netmod@ietf.org" <=
netmod@ietf.org>

Subject: [netmod] call for consensu=
s to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft




















The minutes for IETF 95 show that th=
ere was in-room support for adopting draft-wilton-netmod-intf-e=
xt-yang as a WG draft.   The minutes also show that this decision woul=
d be confirmed on the mailing list, which I
 am doing now.  







Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG item=
 and correspondingly add this to the WG charter as a milestone?  Pleas=
e comment by Tuesday, December 22, 2015 at 9AM EST at which time the WG Cha=
irs will gauge whether or not there is
 consensus to move forward with the document.







Thanks,


Kent



























--_000_D29628A9C925ggrammeljunipernet_--


From nobody Tue Dec 15 12:22:28 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718B81ACD62 for ; Tue, 15 Dec 2015 12:22:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 m_uur4xo9vln for ; Tue, 15 Dec 2015 12:22:23 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BD2A1ACD4B for ; Tue, 15 Dec 2015 12:22:23 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0643510EF; Tue, 15 Dec 2015 21:22:22 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id X2sfi-x-GIBU; Tue, 15 Dec 2015 21:22:20 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 15 Dec 2015 21:22:20 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7A36D20056; Tue, 15 Dec 2015 21:22:20 +0100 (CET)
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 6HzSIUBcSxii; Tue, 15 Dec 2015 21:22:19 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A415F20055; Tue, 15 Dec 2015 21:22:18 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id A3B47393E5E5; Tue, 15 Dec 2015 21:22:17 +0100 (CET)
Date: Tue, 15 Dec 2015 21:22:16 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
Message-ID: <20151215202215.GA64429@elstar.local>
Mail-Followup-To: Robert Wilton , Kent Watsen , "netmod@ietf.org" 
References: <411F084C-B435-4CBA-93C7-AA4213958A21@juniper.net> <20151215170801.GA64085@elstar.local> <56706607.9080606@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56706607.9080606@cisco.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Dec 2015 20:22:26 -0000

On Tue, Dec 15, 2015 at 07:12:07PM +0000, Robert Wilton wrote:
> Hi Juergen,
> 
> Hopefully I can answer your questions inline ...
> 
> On 15/12/2015 17:08, Juergen Schoenwaelder wrote:
> >On Tue, Dec 15, 2015 at 04:48:21PM +0000, Kent Watsen wrote:
> >>The minutes for IETF 95 show that there was in-room support for adopting 
> >>draft-wilton-netmod-intf-ext-yang as a WG draft.   The minutes also show 
> >>that this decision would be confirmed on the mailing list, which I am 
> >>doing now.
> >>
> >>Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG item 
> >>and correspondingly add this to the WG charter as a milestone?  Please 
> >>comment by Tuesday, December 22, 2015 at 9AM EST at which time the WG 
> >>Chairs will gauge whether or not there is consensus to move forward with 
> >>the document.
> >>
> >This I-D contains some Ethernet specific definitions. Are we going to
> >define Ethernet specific things in the IETF or is IEEE ready to take
> >over data models for 'their' interfaces? In other words, what exactly
> >is the scope of this work?
> There is an informal IEEE 802.3 Ethernet design team (that has the 
> backing of the 802.3 WG chair, and that I'm part of) that is working on 
> YANG models for Ethernet interfaces.  The intention is that this 
> informal design team will become a formal IEEE 802.3 WG design team once 
> it traverses the necessary IEEE 802.3 WG processes (i.e. likely to be 
> sometime later on next year).  The exact scope of this project hasn't 
> been defined yet, and can't formally be defined until the IEEE 802.3 WG 
> agrees that we can do it, but my expectation is that the long term goal 
> will surely be to define YANG models to cover all of the 802.3 work, 
> although there may be various interim goals along the way.
> 
> In the interim, whilst we wait for the formal WG to be started, the 
> Ethernet design team are working on Ethernet models in Github 
> (https://github.com/8023YangDesignTeam/EthernetYang).
> 
> How does that overlap with draft-wilton-netmod-intf-ext-yang?  The basic 
> answer is that it shouldn't and arguably doesn't.  The only thing that 
> it defines related to Ethernet is three leaves related to MAC address 
> (configured value, operational value, and burnt-in value) that are 
> applicable to all interfaces that use Ethernet framing.  There are 
> various types of interface that use Ethernet framing but are not 
> Ethernet interfaces, nor necessarily defined in IEEE.  I.e. I'm thinking 
> of interfaces where a VPLS instances terminates to a layer 3 forwarding 
> instances, or where a pseudo-wire is terminated directly to a layer 3 
> forwarding instance.  But at the end of the day, if this part of the 
> draft needs to be defined as part of the IEEE 802.3 space then I think 
> that would be fine too - I don't think that it should really be an 
> issue, and I think that we can involve the necessary folks to ensure 
> that this bit gets to the right home.

Thanks for the background and explanation.

> >If we add something to the work of this WG, what will be realistic
> >milestones and how do we make sure we stay focused? Is there a need
> >for some prioritization?
> I believe that at least some of this configuration is required to 
> configure networks in a reliable way, so I would have thought that we 
> need to progress these models at the same time as the routing protocol 
> models.
> 
> On a related note, any VPLS or Pseudowire models defined by IETF are 
> basically going to be undeployable without 
> draft-wilton-netmod-intf-vlan-yang-01 (or an equivalent) being defined 
> because there will be no configuration mechanism to bind the 
> classification of traffic from a particular VLAN to a VPLS instance.  
> Note that I don't see that any models coming out of IEEE 802.1Q are 
> likely to help here.  This point was also raised in PALS at IETF 94 by 
> some of the folks working on, or reviewing, those models.

So what will be realistic milestones? There are many things needed to
configure a complete network using YANG models and we need to make
sure we are able to finish what we start with realistic milestones
(and realistic really boils down to have a sufficient number of
dedicated reviewers lined up with the necessary cycles available to
make the milestones happen).

It might help the WG chairs to not only see "I support this work"
statements but also explicit "I support this work and I will provide
the time necessary to review the drafts as they progress through the
WG" statements.

/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 Dec 15 13:09:59 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 419F71ACE2A for ; Tue, 15 Dec 2015 13:09:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
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 e1StJ4mc0Hdu for ; Tue, 15 Dec 2015 13:09:53 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (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 65A511ACE2B for ; Tue, 15 Dec 2015 13:09:53 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.15.2/8.15.2) with ESMTPS id tBFL9pRu008877 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 15 Dec 2015 21:09:51 GMT
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id tBFL9pFs029750 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 15 Dec 2015 22:09:51 +0100
Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 15 Dec 2015 22:09:50 +0100
Received: from DEMUMBX005.nsn-intra.net ([169.254.5.48]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0248.002; Tue, 15 Dec 2015 22:09:50 +0100
From: "Ersue, Mehmet (Nokia - DE/Munich)" 
To: "netmod@ietf.org" 
Thread-Topic: WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03
Thread-Index: AdE3eTk+yj/4s/NrQu2LeR6gt3+K2gAA3ymg
Date: Tue, 15 Dec 2015 21:09:50 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.159.42.106]
Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F81986CB61DEMUMBX005nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 12171
X-purgate-ID: 151667::1450213791-00002C61-AAEB42E7/0/0
Archived-At: 
Subject: [netmod] FW: WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Dec 2015 21:09:58 -0000

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

FYI and attention.

Please provide your comments to NETCONF WG maillist.

Mehmet

From: Ersue, Mehmet (Nokia - DE/Munich)
Sent: Tuesday, December 15, 2015 9:59 PM
To: netconf@ietf.org
Cc: 'core@ietf.org' ; 'i2rs@ietf.org' ; '6lo@=
ietf.org' <6lo@ietf.org>; '6tisch@ietf.org' <6tisch@ietf.org>
Subject: WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf-netcon=
f-yang-patch-07 and draft-ietf-netconf-yang-library-03

Dear NETCONF WG,

we hereby issue a WG Last Call for the drafts below:

http://tools.ietf.org/html/draft-ietf-netconf-restconf-09.txt
http://tools.ietf.org/html/draft-ietf-netconf-yang-patch-07.txt
http://tools.ietf.org/html/draft-ietf-netconf-yang-library-03.txt

Please review and send your comments to the NETCONF WG mailing list by Janu=
ary 22, 2015 EOB PT.

The drafts on RESTCONF, YANG patch and YANG library are planned to publish =
as standard track documents.

As RESTCONF is a major protocol we seek a detailed and thorough review with=
in NETCONF WG but also by the related WGs before publishing.
Therefore the WGLC is planned to finalize on January 22th (covering the hol=
iday time in between) and APP, INT and RTG area ADs will be informed as wel=
l as Core, I2RS, 6lo, and 6tisch WGs are invited to review.

Please take your time to review the documents and send your comments to the=
 NETCONF maillist by the deadline.
Please state on NETCONF maillist also explicitly, whether you have read/rev=
iewed and whether you support the publication.
Furthermore please indicate if you plan to implement or have already implem=
entations for RESTCONF and its supplementary drafts.

Thank you for your review and kind help getting RESTCONF specifications sta=
ble.

Best Regards,
Mehmet and Mahesh


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











FYI and attention.<=
/p>

 


Please provide your comments to NETCO=
NF WG maillist.


 




Mehmet





 






From: Ersue, Mehmet (Nokia - DE/Muni=
ch)


Sent: Tuesday, December 15, 2015 9:59 PM

To: netconf@ietf.org

Cc: 'core@ietf.org' <core@ietf.org>; 'i2rs@ietf.org' <i2rs@=
ietf.org>; '6lo@ietf.org' <6lo@ietf.org>; '6tisch@ietf.org' <6t=
isch@ietf.org>

Subject: WG Last Call for draft-ietf-netconf-restconf-09, draft-ietf=
-netconf-yang-patch-07 and draft-ietf-netconf-yang-library-03






 


Dear NETCONF WG,

 


we hereby issue a WG Last Call for th=
e drafts below:



 


http://tools.ietf.org/html/draft-ietf-ne=
tconf-restconf-09.txt


http://tools.ietf.org/html/draft-ietf-=
netconf-yang-patch-07.txt


http://tools.ietf.org/html/draft-iet=
f-netconf-yang-library-03.txt


 


Please review and send your comments =
to the NETCONF WG mailing list by January 22, 2015 EOB PT.



 


The drafts on RESTCONF, YANG patch an=
d YANG library are planned to publish as standard track documents.


 


As RESTCONF is a major protocol we se=
ek a detailed and thorough review within NETCONF WG but also by the related=
 WGs before publishing.


Therefore the WGLC is planned to fina=
lize on January 22th (covering the holiday time in between) and APP, INT an=
d RTG area ADs will be informed as well as Core,
 I2RS, 6lo, and 6tisch WGs are invited to review.


 


Please take your time to review the d=
ocuments and send your comments to the NETCONF maillist by the deadline.


Please state on NETCONF maillist also=
 explicitly, whether you have read/reviewed and whether you support the pub=
lication.



Furthermore please indicate if you pl=
an to implement or have already implementations
for RESTCONF and its supplementary drafts.=



 


Thank you for your review and kind he=
lp getting RESTCONF specifications stable.


 


Best Regards,


Mehmet and Mahesh

 






--_000_E4DE949E6CE3E34993A2FF8AE79131F81986CB61DEMUMBX005nsnin_--


From nobody Tue Dec 15 13:30:38 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8DE1AD062 for ; Tue, 15 Dec 2015 13:30:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level: 
X-Spam-Status: No, score=-14.509 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 0wdUcUNAzoZn for ; Tue, 15 Dec 2015 13:30:34 -0800 (PST)
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 92CC51ACE55 for ; Tue, 15 Dec 2015 13:30:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6440; q=dns/txt; s=iport; t=1450215033; x=1451424633; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=Kcd0D45WDg5DSmXPqLrnNv4IBXvSRwp0hEMqDSUWZRA=; b=C4R9/IlmKjcGSPfRiFwUX9ZiEkHkYXeQW+mi4dH9FY2sZ4XgNqKGd0DF ry+oTHeX+IpXxbLKJiYZQv64v0V4TYd6/dwrVADOWExlwDFUlTR7HQw1H OyzHaCykP3pzPSGoOZC1GpMHSaECHL2NvxJECdsGo/LzqDX8Sm/miVVvG M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqBAADhXBW/xbLJq1ehAxtv0ohhWwCg?= =?us-ascii?q?hYBAQEBAQGBC4Q1AQEEI0sKESwWCwICCQMCAQIBRQYNBgIBARAHiBQOq3ORdwE?= =?us-ascii?q?BAQEBAQQBAQEBAQEdhlaJJxEBgzuBSQWWfIU5iA+BXEmDfIMFk3RjghEdgVc9N?= =?us-ascii?q?IMygUIBAQE?=
X-IronPort-AV: E=Sophos;i="5.20,434,1444694400";  d="scan'208,217";a="609814630"
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; 15 Dec 2015 21:30:31 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tBFLUUMw028250 for ; Tue, 15 Dec 2015 21:30:31 GMT
References: <56707D11.2050604@cisco.com>
To: NETMOD Working Group 
From: Benoit Claise 
X-Forwarded-Message-Id: <56707D11.2050604@cisco.com>
Message-ID: <56708676.9040501@cisco.com>
Date: Tue, 15 Dec 2015 22:30:30 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <56707D11.2050604@cisco.com>
Content-Type: multipart/alternative; boundary="------------070103070308070805080407"
Archived-At: 
Subject: [netmod] operational state: next step
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Dec 2015 21:30:36 -0000

This is a multi-part message in MIME format.
--------------070103070308070805080407
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear all:

Background: the operational state is a blocking factor for the 
publication of the YANG models. For example, I've been told that the 
ISIS and OSPF models are ready, pending resolution on the operational state.

Let me try to clarify the situation and the next steps.

During the NETMOD WG meeting in Yokohama, Kent, as a chair, did a hum 
related to draft-ietf-netmod-opstate-reqs-00 

As explained during the previous operational state-related interim 
meetings, we wanted to extract the requirements.
Kent carefully asked: "humm if in you are in favor of the definitions of 
the requirements", meaning: have we correctly documented the requirements?
draft-ietf-netmod-opstate-reqs-01 
 will 
be published soon, with no changes to the requirements scope, but only 
clarifying text and editorial changes.
Once published, a WGLC will follow, with hopefully a quick publication.

Now, what is the next step regarding the solution?
As mentioned during the NETMOD meeting in Japan, there are currently 3 
proposals:
     1. openconfig draft-openconfig-netmod-opstate-01 

     2. based on the data stores draft-kwatsen-netmod-opstate-00 

     3. based on the metadata draft-wilton-netmod-opstate-yang-01 


During the NETMOD WG meeting, Kent asked the sense of the room on which 
solution the community favored. There was an advantage for solution 2.
However, we want to make that the WG to make an informed decision.

Kent and I have searching for independent people who could analyze the 
different solutions, and provide the pros/cons of each solutions. Note 
that some of this has already been done (Rob Wilton's presentation in 
Yokohama, YANG Model Coordination Group email to the list, etc.)
Lou Berger and Acee Lindem have agreed to help with this, with a 
tentative date of Jan 15 for an initial analysis.
They will start collecting the arguments. Please direct emails to both 
of them (lberger@labn.net, acee@cisco.com). Note that for discussions, 
the WG mailing list is more appropriate.

This process should ease the solution selection.

Regards, Benoit













--------------070103070308070805080407
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    Dear all:

    
 

      Background: the operational state is a blocking factor for the
      publication of the YANG models. For example, I've been told that
      the ISIS and OSPF models are ready, pending resolution on the
      operational state.

      

      Let me try to clarify the situation and the next steps.

      

      During the NETMOD WG meeting in Yokohama, Kent, as a chair, did a
      hum related to draft-ietf-netmod-opstate-reqs-00

      As explained during the previous operational state-related interim
      meetings, we wanted to extract the requirements.

      Kent carefully asked: "humm if in you are in favor of the
      definitions of the requirements", meaning: have we correctly
      documented the requirements?

      draft-ietf-netmod-opstate-reqs-01
      will be published soon, with no changes to the requirements scope,
      but only clarifying text and editorial changes.

      Once published, a WGLC will follow, with hopefully a quick
      publication.

      

      Now, what is the next step regarding the solution?

      As mentioned during the NETMOD meeting in Japan, there are
      currently 3 proposals:

          1. openconfig draft-openconfig-netmod-opstate-01

          2. based on the data stores draft-kwatsen-netmod-opstate-00

          3. based on the metadata draft-wilton-netmod-opstate-yang-01

      

      During the NETMOD WG meeting, Kent asked the sense of the room on
      which solution the community favored. There was an advantage for
      solution 2.

      However, we want to make that the WG to make an informed decision.

      

      Kent and I have searching for independent people who could analyze
      the different solutions, and provide the pros/cons of each
      solutions. Note that some of this has already been done (Rob
      Wilton's presentation in Yokohama, YANG Model Coordination Group
      email to the list, etc.)

      Lou Berger and Acee Lindem have agreed to help with this, with a
      tentative date of Jan 15 for an initial analysis.

      They will start collecting the arguments. Please direct emails to
      both of them (lberger@labn.net,
      acee@cisco.com). Note that for
      discussions, the WG mailing list is more appropriate.

      

      This process should ease the solution selection.

      

      Regards, Benoit 

          

      

      

      

      

      

      

      

      

      

      

    

    

  


--------------070103070308070805080407--


From nobody Tue Dec 15 13:47:10 2015
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 D2AAF1B29C4; Tue, 15 Dec 2015 13:47:07 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.11.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151215214707.9920.56949.idtracker@ietfa.amsl.com>
Date: Tue, 15 Dec 2015 13:47:07 -0800
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Dec 2015 21:47:08 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

        Title           : NETMOD Operational State Requirements
        Authors         : Kent Watsen
                          Thomas Nadeau
	Filename        : draft-ietf-netmod-opstate-reqs-01.txt
	Pages           : 8
	Date            : 2015-12-15

Abstract:
   This document defines requirements for servers enabling better
   visibility and control over the server's operational state.  To
   achieve this end, this document also defines terminology describing a
   conceptual model enabling the requirements to be expressed.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-opstate-reqs-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-opstate-reqs-01


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 Tue Dec 15 13:55:55 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B93281B2ACA for ; Tue, 15 Dec 2015 13:55:53 -0800 (PST)
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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 vYj2ueJ4sdgb for ; Tue, 15 Dec 2015 13:55:49 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0131.outbound.protection.outlook.com [207.46.100.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 706C91A8A47 for ; Tue, 15 Dec 2015 13:55:49 -0800 (PST)
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (TLS) id 15.1.355.16; Tue, 15 Dec 2015 21:55: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.01.0355.012; Tue, 15 Dec 2015 21:55:48 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-01.txt
Thread-Index: AQHRN4IuVTit1Lj/CUiWo9RINadSrp7MQ90A
Date: Tue, 15 Dec 2015 21:55:47 +0000
Message-ID: <9D274E21-3552-4F92-B892-A6B6FFEEBED3@juniper.net>
References: <20151215214707.9920.56949.idtracker@ietfa.amsl.com>
In-Reply-To: <20151215214707.9920.56949.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.151105
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.13]
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 5:jmQAthh8x/MsSOyqae7L3d+QgbkRobzQVi3aN0cnRMtGfRA2Pnw4NrjuoYB6EdR0l8DBtIwBATFUx+AEWMhUbDhBx1rZXLruJLta+9FMx8reZnSLGi4s8gE9vdykLMr2QaNvIx+URXOlwpdAddl1gQ==; 24:KlEu1gBChOzCX6EDBKRnDloCD/hMWoVWB6MMIX/iWJvPH/Ab5+lv30q2Hm3WFFxeFOxHANJUBfm25GX49CkW/hbSbSBbUVeijKR2GW2Est8=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1443;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; 
x-forefront-prvs: 07915F544A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377424004)(199003)(24454002)(377454003)(164054003)(189002)(479174004)(106356001)(5001960100002)(83716003)(2950100001)(86362001)(50986999)(54356999)(76176999)(110136002)(92566002)(122556002)(82746002)(19580405001)(83506001)(189998001)(230783001)(107886002)(5008740100001)(19580395003)(4001350100001)(40100003)(575784001)(66066001)(87936001)(15975445007)(77096005)(2900100001)(81156007)(99286002)(105586002)(106116001)(2351001)(101416001)(97736004)(1220700001)(33656002)(3846002)(5004730100002)(102836003)(586003)(450100001)(6116002)(36756003)(2501003)(1730700002)(1096002)(4001150100001)(5002640100001)(10400500002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; 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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <59E2297F4771CD409CD725343415AE83@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Dec 2015 21:55:47.9695 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443
Archived-At: 
Subject: Re: [netmod] I-D Action: draft-ietf-netmod-opstate-reqs-01.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 15 Dec 2015 21:55:53 -0000

W0FzIGEgY29udHJpYnV0b3JdDQoNCg0KVGhpcyB1cGRhdGUgcmVmbGVjdHMgdGhlIGZvdXIgb24t
bGlzdCBlbWFpbCB0aHJlYWRzIHNpbmNlIC0wMCB3YXMgcHVibGlzaGVkIGFzIGZvbGxvd3M6DQoN
Cg0KMS4gUmVnYXJkaW5nIEJhbGF6cywgR2VydCwgYW5kIFJvYmVydOKAmXMgdGhyZWFkIGhlcmU6
IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNn
MTQyNDMuaHRtbA0KDQpUaGUgdGVybSDigJxub24tZGVyaXZlZOKAnSBzdGF0ZSBpbiBSZXEgIzQg
aGFzIGJlZW4gcmVtb3ZlZCBhbmQgbmV3IHRlcm0g4oCcT3BlcmF0aW9uYWwgU3RhdGXigJ0gaGFz
IGJlZW4gYWRkZWQuICBUaGUgbmV3IHJlcXVpcmVtZW50ICMzIGlzIGEgbGl0dGxlIGRpZmZlcmVu
dCB0aGFuIHdoYXTigJlzIGluIGRyYWZ0LW9wZW5jb25maWctbmV0bW9kLW9wc3RhdGUsIGJ1dCBJ
IGJlbGlldmUgdGhhdCBpdCBpcyB3aGF04oCZcyBpbnRlbmRlZCAobm8gcHVuIGludGVuZGVkLCBk
b2ghKS4gIE5vIGNoYW5nZSBtYWRlIGNsYXJpZnlpbmcgbG9uZyBydW5uaW5nIG9wZXJhdGlvbnMg
bGlrZSBiYWNrdXAsIGFzIHRoaXMgcmVxdWlyZW1lbnRzIGRyYWZ0LCB3aGVuIHJlZmVycmluZyB0
byDigJxhc3luY2hyb25vdXMiLCByZWdhcmRzIGNvbmZpZ3VyYXRpb24gb3BlcmF0aW9ucy4gICBB
bHNvIG5vIGNoYW5nZSBtYWRlIHRvIGFkZCBhIG5ldyByZXF1aXJlbWVudCBmb3IgYSBZQU5HIGFu
bm90YXRpb24gZm9yIGNvbmZpZyBub2RlcyB0aGF0IGFyZSBrbm93biB0byBoYXZlIHBvdGVudGlh
bGx5IGRpZmZlcmVudCBpbnRlbnRlZC1jb25maWcgdmFsdWUuDQoNCkdpdCBkaWZmczogDQpodHRw
czovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL29wc3RhdGUtcmVxcy9jb21taXQvNmJjODJkMjRlMzUz
MzdjYjIyMjlmYjYzMzhmMjFhZjJiZjEwNjY0Nw0KaHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13
Zy9vcHN0YXRlLXJlcXMvY29tbWl0LzNkYWJjNGZhOTA1YzRkMzAzN2Y4MDhkYmM4ZjE4NTg0ZDNl
NjEzZDUNCg0KDQoNCjIuIFJlZ2FyZGluZyBKYXNvbiBhbmQgR2VydOKAmXMgdGhyZWFkIGhlcmU6
IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNn
MTQzNDIuaHRtbA0KDQpJIGhhdmUgbm90IGRvbmUgYW55dGhpbmcgYWJvdXQgdGhpcyB5ZXQsIGJ1
dCBpdCBzZWVtcyB0aGF0IHNvbWV0aGluZyBtaWdodCBuZWVkIHRvIGJlIGRvbmUuICBQZXJzb25h
bGx5LCBJIGRvbuKAmXQgc2VlIGhvdyBSb2xsYmFjayBvbiBFcnJvciBjb3VsZCBiZSBhbGxvd2Vk
IHRvIHJvbGxiYWNrIHRoZSBpbnRlbmRlZCBjb25maWcgc2V0IHZpYSBhbiBhc3luY2hyb25vdXMg
Y29tbWl0IChlLmcuLCBhZnRlciA8b2svPiBoYXMgYmVlbiBzZW50KS4gIE15IHRoaW5raW5nIGlz
IHRoYXQgdGhlIHNlcnZlciBzaG91bGQgc2VuZCA8cnBjLWVycm9yPiBpZiB0aGUgY2xpZW50IHJl
cXVlc3RzIHRoYXQgY29tYmluYXRpb24uICBGV0lXLCBJ4oCZbSBub3QgdHJvdWJsZWQgYnkgJ2h5
YnJpZCcgb3IgY2hlYXRpbmctc3luY2hyb25vdXMgaW1wbGVtZW50YXRpb25zLCBhcyBpbiBteSB2
aWV3LCB0aGV5IGRvbuKAmXQgYWR2ZXJ0aXNlIHN1cHBvcnQgZm9yIGFwcGxpZWQgY29uZmlndXJh
dGlvbnMgb3IgZm9yIHN5bmNocm9ub3VzIGNvbW1pdHMuDQoNCg0KDQozLiBSZWdhcmRpbmcgSmFz
b24gYW5kIFJhbmR54oCZcyB0aHJlYWQgaGVyZTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbC1h
cmNoaXZlL3dlYi9uZXRtb2QvY3VycmVudC9tc2cxNDM0NC5odG1sDQoNClRoZSBvbGQgMi1BIHdh
cyByZW1vdmVkIHNpbmNlIGl04oCZcyBhIGR1cGxpY2F0ZSB0byA0LUMsIGFuZCB0aGVuIHRoZSBv
bGQgMiB3YXMgcmVtb3ZlZCBzaW5jZSBpdOKAmXMgY292ZXJlZCBpbiB0aGUgbmV3IE9wZXJhdGlv
bmFsIFN0YXRlIHRlcm0uICBUaGUgb2xkICM1IHdhcyBhbHNvIHJlbW92ZWQgdG8gZWxpbWluYXRl
IGNydWZ0IGZyb20gdGhlIGRyYWZ0LiAgVGhlbiBJIGZpeGVkIEFwcGVuZGl4IEIgdG8gcG9pbnQg
dG8gbmV3IHNlY3Rpb24gbnVtYmVycy4NCg0KR2l0IGRpZmZzOiANCmh0dHBzOi8vZ2l0aHViLmNv
bS9uZXRtb2Qtd2cvb3BzdGF0ZS1yZXFzL2NvbW1pdC8wMmVmNWZlZGQ0MjkzMDI0ZGFiNzA1MTQ4
ODRlOTY2MWI5Yzg2Mjg1DQpodHRwczovL2dpdGh1Yi5jb20vbmV0bW9kLXdnL29wc3RhdGUtcmVx
cy9jb21taXQvNGEwNjc0NDE1N2RhZGE0NzA3YTQ1N2VjMDZhMTdiMDQ4NzE5YWUwYiAgDQoNCg0K
DQo0LiBSZWdhcmRpbmcgSmFzb24gYW5kIEdlcnTigJlzIHRocmVhZCBoZXJlOiBodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldG1vZC9jdXJyZW50L21zZzE0MzQzLmh0bWwN
Cg0KTm8gY2hhbmdlcyBtYWRlIGhlcmUgYmVjYXVzZSBJIGRvbuKAmXQgdGhpbmsgdGhpcyBoeWJy
aWQgY2FzZSBuZWVkcyB0byBiZSBkZWZpbmVkLiAgIEluIG15IHZpZXcsIGEgZGV2aWNlIGVpdGhl
ciBhZHZlcnRpc2VzIHN1cHBvcnQgZm9yIHN5bmNoIG9yIGFzeW5jaCBvciBib3RoIG9yIG5vbmUg
KGRlZmF1bHQpLiAgRm9yIHRoZSBmaXJzdCB0aHJlZSBjYXNlcywgdGhlIGJlaGF2aW9yIGlzIGV4
cGxpY2l0bHkgZGVmaW5lZC4gIEZvciB0aGUgbGFzdCBjYXNlLCB0aGUgYmVoYXZpb3IgcmVtYWlu
cyBzYW1lIGFzIHRvZGF5ICh1bmRlZmluZWQpLCB3aGljaCBpcyBuZWVkZWQgZm9yIGJhY2t3YXJk
cyBjb21wYXRpYmlsaXR5Lg0KDQoNCg0KVGhhbmtzLA0KS2VudA0KDQoNCg0KDQoNCg0KDQoNCk9u
IDEyLzE1LzE1LCA0OjQ3IFBNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNA
aWV0Zi5vcmciIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgaW50ZXJuZXQt
ZHJhZnRzQGlldGYub3JnPiB3cm90ZToNCg0KPg0KPkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2
YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4g
VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTkVUQ09ORiBEYXRhIE1vZGVsaW5nIExh
bmd1YWdlIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+DQo+ICAgICAgICBUaXRsZSAgICAg
ICAgICAgOiBORVRNT0QgT3BlcmF0aW9uYWwgU3RhdGUgUmVxdWlyZW1lbnRzDQo+ICAgICAgICBB
dXRob3JzICAgICAgICAgOiBLZW50IFdhdHNlbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAg
VGhvbWFzIE5hZGVhdQ0KPglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLW5ldG1vZC1vcHN0
YXRlLXJlcXMtMDEudHh0DQo+CVBhZ2VzICAgICAgICAgICA6IDgNCj4JRGF0ZSAgICAgICAgICAg
IDogMjAxNS0xMi0xNQ0KPg0KPkFic3RyYWN0Og0KPiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBy
ZXF1aXJlbWVudHMgZm9yIHNlcnZlcnMgZW5hYmxpbmcgYmV0dGVyDQo+ICAgdmlzaWJpbGl0eSBh
bmQgY29udHJvbCBvdmVyIHRoZSBzZXJ2ZXIncyBvcGVyYXRpb25hbCBzdGF0ZS4gIFRvDQo+ICAg
YWNoaWV2ZSB0aGlzIGVuZCwgdGhpcyBkb2N1bWVudCBhbHNvIGRlZmluZXMgdGVybWlub2xvZ3kg
ZGVzY3JpYmluZyBhDQo+ICAgY29uY2VwdHVhbCBtb2RlbCBlbmFibGluZyB0aGUgcmVxdWlyZW1l
bnRzIHRvIGJlIGV4cHJlc3NlZC4NCj4NCj4NCj5UaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMg
cGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv
Yy9kcmFmdC1pZXRmLW5ldG1vZC1vcHN0YXRlLXJlcXMvDQo+DQo+VGhlcmUncyBhbHNvIGEgaHRt
bGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s
L2RyYWZ0LWlldGYtbmV0bW9kLW9wc3RhdGUtcmVxcy0wMQ0KPg0KPkEgZGlmZiBmcm9tIHRoZSBw
cmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCj5odHRwczovL3d3dy5pZXRmLm9yZy9y
ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRtb2Qtb3BzdGF0ZS1yZXFzLTAxDQo+DQo+DQo+UGxl
YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp
bWUgb2Ygc3VibWlzc2lvbg0KPnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFy
ZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+DQo+SW50ZXJuZXQtRHJhZnRzIGFyZSBh
bHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPmZ0cDovL2Z0cC5pZXRmLm9yZy9p
bnRlcm5ldC1kcmFmdHMvDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg==


From nobody Wed Dec 16 00:56:03 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF441AC415 for ; Wed, 16 Dec 2015 00:56:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 4NQEl60yyRf3 for ; Wed, 16 Dec 2015 00:56:00 -0800 (PST)
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 0EA4E1AC413 for ; Wed, 16 Dec 2015 00:55:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1706; q=dns/txt; s=iport; t=1450256160; x=1451465760; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=WgfFXurDTORReTnUVXMEHDK1zJ72wOIBtnjHOvKmPto=; b=FhA9So5gTeUFBxFNc6ugmVTMuDFOsI/3kbtE71aLPQoyYS3+1OoxQ14X lpRnN1b3fadxcfBNcEYdUL9/PypbcT6ClFcL82VotU25lfgKSY8KuEH2w zH3zoU/6yIOFqkSlPTJPjwYXkYnr0SrUBPumq+NhZKaeUxC37WV4sBZPf E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsBAB5JnFW/xbLJq1ehAxtv1EXCoUiS?= =?us-ascii?q?gKCBgEBAQEBAYELhDUBAQQBAQEaBg8BBTYLEAsYAgIFIQICDwIWMAYBDAYCAQG?= =?us-ascii?q?IKw6sFJIJAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASBAYVVhH2Hd4FJBYVZkSOFO?= =?us-ascii?q?YVUgjuBXIRFgwWTdGOCRIFBPTSEdAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.20,436,1444694400"; d="scan'208";a="609823148"
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; 16 Dec 2015 08:55:58 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tBG8tvJt028842; Wed, 16 Dec 2015 08:55:57 GMT
To: Ladislav Lhotka , Thomas Nadeau 
References: <0C987A22-5602-438D-B42D-82C8476AA513@lucidvision.com> <23D79879-556D-4523-8CAB-845C10BC76CC@nic.cz>
From: Benoit Claise 
Message-ID: <5671271D.40603@cisco.com>
Date: Wed, 16 Dec 2015 09:55:57 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <23D79879-556D-4523-8CAB-845C10BC76CC@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] call for consensus to adopt draft-entitydt-netmod-entity as NETMOD WG draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 08:56:02 -0000

Dear all,
>> On 15 Dec 2015, at 13:34, Nadeau Thomas  wrote:
>>
>>
>> 	NETMOD:
>>
>> 	The Broadband Forum and the members of the design team who worked on the
>> IETF Entity module have asked that the working group considerthe ietf-entity YANG module
>> (currently https://datatracker.ietf.org/doc/draft-entitydt-netmod-entity/ which is
>> still in individual draft status) as a working group item.
>>
>> 	Should we move to adopt draft-entitydt-netmod-entity as a WG item and
>> correspondingly add this to the WG charter as a milestone?  Please comment by
>> Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs will
>> gauge whether or not there is consensus to move forward with the document.
Support.
> I would strongly prefer to finish the existing items first, or at least the critical ones on which other work depends. Adding more items would mean that both old and new items receive less attention on the average. We already have at most one or two reviews per WGLC, and this is IMO insufficient.
While I understand the concern of work prioritization, one of the issues 
in NETMOD is that we need to grow the number of people involved in 
participating/editing/reviewing, and I'm happy to see Dan and Jimmy 
taking the lead here.

Regards, Benoit
>
> Lada
>
>> 	—Tom
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Dec 16 02:25:51 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F161A1A2E for ; Wed, 16 Dec 2015 02:25:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 7X_EYh3y9wg8 for ; Wed, 16 Dec 2015 02:25:43 -0800 (PST)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 148A71ACE36 for ; Wed, 16 Dec 2015 02:25:43 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2AeAwA3Q8ZV/xUHmMZYAxkBAQGCUyxUaQapbgaTNgmCBIV5AoEmOBQBAQEBAQEBgQqEIwEBAQEDEgsdNAsMAgICAQgNAQIBBAEBAQoUCQcbFxQJCAIEAQ0FCBqIDAEMrGmgOgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEBIYbhTKEWCEQBwYMgwaBFAWHHY1uAYUBiSqEJYMLjR6DZhcPgj+BPm8BgUeBBAEBAQ
X-IPAS-Result: A2AeAwA3Q8ZV/xUHmMZYAxkBAQGCUyxUaQapbgaTNgmCBIV5AoEmOBQBAQEBAQEBgQqEIwEBAQEDEgsdNAsMAgICAQgNAQIBBAEBAQoUCQcbFxQJCAIEAQ0FCBqIDAEMrGmgOgEBAQEBAQEBAQEBAQEBAQEBAQEBARMEBIYbhTKEWCEQBwYMgwaBFAWHHY1uAYUBiSqEJYMLjR6DZhcPgj+BPm8BgUeBBAEBAQ
X-IronPort-AV: E=Sophos;i="5.15,634,1432612800"; d="scan'208";a="156642093"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 16 Dec 2015 05:25:41 -0500
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 16 Dec 2015 05:25:40 -0500
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0174.001; Wed, 16 Dec 2015 11:25:38 +0100
From: "Romascanu, Dan (Dan)" 
To: Juergen Schoenwaelder , "Robert Wilton" 
Thread-Topic: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft
Thread-Index: AQHRN1hnQ70LlCEAQ02XjL34VtayG57MNtqAgAAirICAABOZAIAA/CkA
Date: Wed, 16 Dec 2015 10:25:37 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA6BEC8C7F@AZ-FFEXMB04.global.avaya.com>
References: <411F084C-B435-4CBA-93C7-AA4213958A21@juniper.net> <20151215170801.GA64085@elstar.local> <56706607.9080606@cisco.com> <20151215202215.GA64429@elstar.local>
In-Reply-To: <20151215202215.GA64429@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.47]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 10:25:50 -0000

"I support this work and I will provide the time necessary to review the dr=
afts as they progress through the WG"

Regards,

Dan


> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen
> Schoenwaelder
> Sent: Tuesday, December 15, 2015 10:22 PM
> To: Robert Wilton
> Cc: netmod@ietf.org
> Subject: Re: [netmod] call for consensus to adopt draft-wilton-netmod-int=
f-
> ext-yang as NETMOD WG draft
>=20
> On Tue, Dec 15, 2015 at 07:12:07PM +0000, Robert Wilton wrote:
> > Hi Juergen,
> >
> > Hopefully I can answer your questions inline ...
> >
> > On 15/12/2015 17:08, Juergen Schoenwaelder wrote:
> > >On Tue, Dec 15, 2015 at 04:48:21PM +0000, Kent Watsen wrote:
> > >>The minutes for IETF 95 show that there was in-room support for
> adopting
> > >>draft-wilton-netmod-intf-ext-yang as a WG draft.   The minutes also
> show
> > >>that this decision would be confirmed on the mailing list, which I
> > >>am doing now.
> > >>
> > >>Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG
> > >>item and correspondingly add this to the WG charter as a milestone?
> > >>Please comment by Tuesday, December 22, 2015 at 9AM EST at which
> > >>time the WG Chairs will gauge whether or not there is consensus to
> > >>move forward with the document.
> > >>
> > >This I-D contains some Ethernet specific definitions. Are we going to
> > >define Ethernet specific things in the IETF or is IEEE ready to take
> > >over data models for 'their' interfaces? In other words, what exactly
> > >is the scope of this work?
> > There is an informal IEEE 802.3 Ethernet design team (that has the
> > backing of the 802.3 WG chair, and that I'm part of) that is working
> > on YANG models for Ethernet interfaces.  The intention is that this
> > informal design team will become a formal IEEE 802.3 WG design team
> > once it traverses the necessary IEEE 802.3 WG processes (i.e. likely
> > to be sometime later on next year).  The exact scope of this project
> > hasn't been defined yet, and can't formally be defined until the IEEE
> > 802.3 WG agrees that we can do it, but my expectation is that the long
> > term goal will surely be to define YANG models to cover all of the
> > 802.3 work, although there may be various interim goals along the way.
> >
> > In the interim, whilst we wait for the formal WG to be started, the
> > Ethernet design team are working on Ethernet models in Github
> > (https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> 3A__github.com_8023YangDesignTeam_EthernetYang&d=3DBQICAg&c=3DBFpW
> Qw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA
> &m=3D3tQyUrqfsDAP33LXzgkILy2EMU_0VWz161hD3GFUwRI&s=3DTrgAGrPT06kL
> wOQzvXNfrBVOFWyoF77-gC0jg_K8EZI&e=3D ).
> >
> > How does that overlap with draft-wilton-netmod-intf-ext-yang?  The
> > basic answer is that it shouldn't and arguably doesn't.  The only
> > thing that it defines related to Ethernet is three leaves related to
> > MAC address (configured value, operational value, and burnt-in value)
> > that are applicable to all interfaces that use Ethernet framing.
> > There are various types of interface that use Ethernet framing but are
> > not Ethernet interfaces, nor necessarily defined in IEEE.  I.e. I'm
> > thinking of interfaces where a VPLS instances terminates to a layer 3
> > forwarding instances, or where a pseudo-wire is terminated directly to
> > a layer 3 forwarding instance.  But at the end of the day, if this
> > part of the draft needs to be defined as part of the IEEE 802.3 space
> > then I think that would be fine too - I don't think that it should
> > really be an issue, and I think that we can involve the necessary
> > folks to ensure that this bit gets to the right home.
>=20
> Thanks for the background and explanation.
>=20
> > >If we add something to the work of this WG, what will be realistic
> > >milestones and how do we make sure we stay focused? Is there a need
> > >for some prioritization?
> > I believe that at least some of this configuration is required to
> > configure networks in a reliable way, so I would have thought that we
> > need to progress these models at the same time as the routing protocol
> > models.
> >
> > On a related note, any VPLS or Pseudowire models defined by IETF are
> > basically going to be undeployable without
> > draft-wilton-netmod-intf-vlan-yang-01 (or an equivalent) being defined
> > because there will be no configuration mechanism to bind the
> > classification of traffic from a particular VLAN to a VPLS instance.
> > Note that I don't see that any models coming out of IEEE 802.1Q are
> > likely to help here.  This point was also raised in PALS at IETF 94 by
> > some of the folks working on, or reviewing, those models.
>=20
> So what will be realistic milestones? There are many things needed to
> configure a complete network using YANG models and we need to make
> sure we are able to finish what we start with realistic milestones (and r=
ealistic
> really boils down to have a sufficient number of dedicated reviewers line=
d up
> with the necessary cycles available to make the milestones happen).
>=20
> It might help the WG chairs to not only see "I support this work"
> statements but also explicit "I support this work and I will provide the =
time
> necessary to review the drafts as they progress through the WG"
> statements.
>=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
>  2Duniversity.de_&d=3DBQICAg&c=3DBFpWQw8bsuKpl1SgiZH64Q&r=3DI4dzGxR31O
> cNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3D3tQyUrqfsDAP33LXzgkILy2EMU_0
> VWz161hD3GFUwRI&s=3DC5gBdpByRrOyMbxueDnG006pA9mM-
> sXifOLKaOpwlHo&e=3D >
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-
> 3A__www.ietf.org_mailman_listinfo_netmod&d=3DBQICAg&c=3DBFpWQw8bsuK
> pl1SgiZH64Q&r=3DI4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=3D3tQy
> UrqfsDAP33LXzgkILy2EMU_0VWz161hD3GFUwRI&s=3DNjmMtB78Y0S8wiF9-
> qLXz4zRy6TyzebcodZpAcFoLWY&e=3D


From nobody Wed Dec 16 04:36:18 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B98711B2CA9 for ; Wed, 16 Dec 2015 04:36:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 QCskTz2Eo7Sw for ; Wed, 16 Dec 2015 04:36:14 -0800 (PST)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6EE1B2B5C for ; Wed, 16 Dec 2015 04:36:13 -0800 (PST)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id D3065C4175C1; Wed, 16 Dec 2015 13:36:12 +0100 (CET)
To: Martin Bjorklund , lhotka@nic.cz
References: <09858705-2365-4B77-A233-91019B6BC681@nic.cz> <20151123.140956.1414405859229447636.mbj@tail-f.com>  <20151125.111622.1788981016001119642.mbj@tail-f.com>
From: Jernej Tuljak 
Message-ID: <56715ABC.1070209@mg-soft.si>
Date: Wed, 16 Dec 2015 13:36:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <20151125.111622.1788981016001119642.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y02: context node
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 12:36:16 -0000

Martin Bjorklund je 25.11.2015 ob 11:16 napisal:
> Ladislav Lhotka  wrote:
>> Hi,
>>
>> I'd like to resolve this issue. Here is a complete example (valid, I believe):
>>
>> module context {
>>    namespace "http://example.com/context";
>>    prefix ctx;
>>
>>    leaf foo {
>>      config false;
>>      type uint32;
>>    }
>>    rpc oper {
>>      output {
>>        must "/foo mod foo = 0";
>>        leaf foo {
>>          type uint32;
>>        }
>>      }
>>    }
>> }
>>
>> 1. What does the accessible tree look like?
> Note that the anser to this depends on the outcomne of Y04.  Andy has
> strong objections to Y04-02, and proposed Y04-04 instead.
>
> Assuming Y04-02, and assuming /foo has the value 20 and the oper rpc's
> result has foo = 10, the accessible tree would look like this:
>
>     
>       +-- oper
>       |   +-- foo = 10
>       +-- foo = 20
>
>
> (If we instead move back to Y04-04, the accessible tree would be:
>
>     
>       +-- oper
>           +-- foo = 10
>
> )
>
>> 2. What is the context node for the "must" expression?
>   /oper

This change to the accessible tree (1.0 --> 1.1) may break some existing 
"when" XPath expressions (those under "output" statement). Is this 
compatible with 1.1 charter - "All compliant YANG 1.0 modules must be 
accepted as compliant YANG 1.1 modules"?

   rpc my-rpc {
     output {
       uses my-stuff {
         when "specific-param = 'foo'";// 1.0
// when "my-rpc/specific-param = 'foo'" // 1.1
       }
       leaf specific-param {
         type string;
       }
     }
   }

Jernej

>
> /martin
>
>
>
>> Thanks, Lada
>>
>> Martin Bjorklund  writes:
>>
>>> Ladislav Lhotka  wrote:
>>>> Hi,
>>>>
>>>> Y02-01 allows "must" as a substatement of "input", "output" and
>>>> "notification" but for these cases the specification of the context
>>>> node in sec. 7.5.3 doesn't work.
>>>>
>>>>     o  The context node is the node in the accessible tree for which the
>>>>        "must" statement is defined.
>>> You are right.  But note how the accessible tree is defined.  There is
>>> a node for the operation / notification.  This node should be the
>>> context node:
>>>
>>>     o  If the "must" statement is a substatement of a "notification"
>>>        statement, the context node is the node representing the
>>>        notification in the accessible tree.
>>>
>>>     o  If the "must" statement is a substatement of a "input"
>>>        statement, the context node is the node representing the
>>>        operation in the accessible tree.
>>>
>>>     o  If the "must" statement is a substatement of a "output"
>>>        statement, the context node is the node representing the
>>>        operation in the accessible tree.
>>>
>>>
>>> /martin
>> -- 
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Wed Dec 16 04:48:00 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7319A1B2D41 for ; Wed, 16 Dec 2015 04:47:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 fdH8kSixeAlL for ; Wed, 16 Dec 2015 04:47:57 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3441B2D40 for ; Wed, 16 Dec 2015 04:47:57 -0800 (PST)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 057F61AE03CD; Wed, 16 Dec 2015 13:47:56 +0100 (CET)
Date: Wed, 16 Dec 2015 13:48:55 +0100 (CET)
Message-Id: <20151216.134855.549606106792110111.mbj@tail-f.com>
To: jernejt@mg-soft.si
From: Martin Bjorklund 
In-Reply-To: <56715ABC.1070209@mg-soft.si>
References:  <20151125.111622.1788981016001119642.mbj@tail-f.com> <56715ABC.1070209@mg-soft.si>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y02: context node
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 12:47:59 -0000

Jernej Tuljak  wrote:
> Martin Bjorklund je 25.11.2015 ob 11:16 napisal:
> > Ladislav Lhotka  wrote:
> >> Hi,
> >>
> >> I'd like to resolve this issue. Here is a complete example (valid, I
> >> believe):
> >>
> >> module context {
> >>    namespace "http://example.com/context";
> >>    prefix ctx;
> >>
> >>    leaf foo {
> >>      config false;
> >>      type uint32;
> >>    }
> >>    rpc oper {
> >>      output {
> >>        must "/foo mod foo = 0";
> >>        leaf foo {
> >>          type uint32;
> >>        }
> >>      }
> >>    }
> >> }
> >>
> >> 1. What does the accessible tree look like?
> > Note that the anser to this depends on the outcomne of Y04.  Andy has
> > strong objections to Y04-02, and proposed Y04-04 instead.
> >
> > Assuming Y04-02, and assuming /foo has the value 20 and the oper rpc's
> > result has foo = 10, the accessible tree would look like this:
> >
> >     
> >       +-- oper
> >       |   +-- foo = 10
> >       +-- foo = 20
> >
> >
> > (If we instead move back to Y04-04, the accessible tree would be:
> >
> >     
> >       +-- oper
> >           +-- foo = 10
> >
> > )
> >
> >> 2. What is the context node for the "must" expression?
> >   /oper
> 
> This change to the accessible tree (1.0 --> 1.1) may break some
> existing "when" XPath expressions (those under "output" statement).

Maybe.  The old text said:

   o  If the context node represents RPC output parameters, the tree is
      the RPC reply instance document.

So this probably meant that for this definition:

  module ex {
    ...
    prefix x;
    ...
    rpc foo {
      output {
        leaf bar { ... }
      }
    }
  }

The accessile tree was:

   nc:rpc-reply
     +-- x:bar

This is very NETCONF-specifc.  With 1.1, the tree would be:

   x:foo
     +-- x:bar

which is protocol-neutral.

> Is
> this compatible with 1.1 charter - "All compliant YANG 1.0 modules
> must be accepted as compliant YANG 1.1 modules"?
> 
>   rpc my-rpc {
>     output {
>       uses my-stuff {
>         when "specific-param = 'foo'";// 1.0
> // when "my-rpc/specific-param = 'foo'" // 1.1

This is not correct.  If a relative path is used, it would be the same
in 1.0 and 1.1.

If an absolute path is used, it would be:

   when "/nc:rpc-reply/x:specific-param = 'foo'"; // 1.0
   when "/x:my-rpc/x:specific-param = 'foo'";     // 1.1


I wonder if any implementation of 1.0 supports this absolute form.


/martin


>       }
>       leaf specific-param {
>         type string;
>       }
>     }
>   }
> 
> Jernej
> 
> >
> > /martin
> >
> >
> >
> >> Thanks, Lada
> >>
> >> Martin Bjorklund  writes:
> >>
> >>> Ladislav Lhotka  wrote:
> >>>> Hi,
> >>>>
> >>>> Y02-01 allows "must" as a substatement of "input", "output" and
> >>>> "notification" but for these cases the specification of the context
> >>>> node in sec. 7.5.3 doesn't work.
> >>>>
> >>>>     o  The context node is the node in the accessible tree for which the
> >>>>        "must" statement is defined.
> >>> You are right.  But note how the accessible tree is defined.  There is
> >>> a node for the operation / notification.  This node should be the
> >>> context node:
> >>>
> >>>     o  If the "must" statement is a substatement of a "notification"
> >>>        statement, the context node is the node representing the
> >>>        notification in the accessible tree.
> >>>
> >>>     o  If the "must" statement is a substatement of a "input"
> >>>        statement, the context node is the node representing the
> >>>        operation in the accessible tree.
> >>>
> >>>     o  If the "must" statement is a substatement of a "output"
> >>>        statement, the context node is the node representing the
> >>>        operation in the accessible tree.
> >>>
> >>>
> >>> /martin
> >> -- 
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >>
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
> 


From nobody Wed Dec 16 05:07:58 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8668A1B2D6A for ; Wed, 16 Dec 2015 05:07:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 HQqZdanuMEvY for ; Wed, 16 Dec 2015 05:07:56 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 BF4511B2D5B for ; Wed, 16 Dec 2015 05:07:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450271247; bh=nJbG5zUQKzrbT3sf06fxL2tGc3aZ4t+ppUIO0Fl3kI0=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Xf6MzLOCvRq4GJuitZR09gPDWvfkzHCtJP2+Mx3dTbfKzidqMXO8wmwWhjO1S6bGc VFiw129ObbSJaDkx/TVqVuk6NDtCNuPodoi/r1eUPCjWGwb9EXuzX6y6xdh0ABCn0z Utcd+kg42BYT+lDZxJulY/SrUfbsHJ7VlTpzwNLo=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=75.67.110.86; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Nadeau Thomas 
In-Reply-To: <5671271D.40603@cisco.com>
Date: Wed, 16 Dec 2015 08:07:54 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <2489AF1E-0DB4-456C-8D74-8B02BDF41E97@lucidvision.com>
References: <0C987A22-5602-438D-B42D-82C8476AA513@lucidvision.com> <23D79879-556D-4523-8CAB-845C10BC76CC@nic.cz> <5671271D.40603@cisco.com>
To: Benoit Claise 
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=2 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=75.67.110.86
X-IP-stats: Notspam Incoming Last 0, First 0, in=2, out=0, spam=0 Known=true ip=75.67.110.86
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] call for consensus to adopt draft-entitydt-netmod-entity as NETMOD WG draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 13:07:57 -0000

> On Dec 16, 2015:3:55 AM, at 3:55 AM, Benoit Claise  =
wrote:
>=20
> Dear all,
>>> On 15 Dec 2015, at 13:34, Nadeau Thomas  =
wrote:
>>>=20
>>>=20
>>> 	NETMOD:
>>>=20
>>> 	The Broadband Forum and the members of the design team who =
worked on the
>>> IETF Entity module have asked that the working group considerthe =
ietf-entity YANG module
>>> (currently =
https://datatracker.ietf.org/doc/draft-entitydt-netmod-entity/ which is
>>> still in individual draft status) as a working group item.
>>>=20
>>> 	Should we move to adopt draft-entitydt-netmod-entity as a WG =
item and
>>> correspondingly add this to the WG charter as a milestone?  Please =
comment by
>>> Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs =
will
>>> gauge whether or not there is consensus to move forward with the =
document.
> Support.
>> I would strongly prefer to finish the existing items first, or at =
least the critical ones on which other work depends. Adding more items =
would mean that both old and new items receive less attention on the =
average. We already have at most one or two reviews per WGLC, and this =
is IMO insufficient.
> While I understand the concern of work prioritization, one of the =
issues in NETMOD is that we need to grow the number of people involved =
in participating/editing/reviewing, and I'm happy to see Dan and Jimmy =
taking the lead here.
>=20
> Regards, Benoit

	Are you speaking as AD or as an individual?

	=E2=80=94Tom


>>=20
>> Lada
>>=20
>>> 	=E2=80=94Tom
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20


From nobody Wed Dec 16 05:08:13 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACB71B2D63 for ; Wed, 16 Dec 2015 05:08:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 M37XNQhdCiKo for ; Wed, 16 Dec 2015 05:08:10 -0800 (PST)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 91ACD1B2D5B for ; Wed, 16 Dec 2015 05:08:10 -0800 (PST)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 6B7DDC4175C1; Wed, 16 Dec 2015 14:08:09 +0100 (CET)
To: Martin Bjorklund 
References:  <20151125.111622.1788981016001119642.mbj@tail-f.com> <56715ABC.1070209@mg-soft.si> <20151216.134855.549606106792110111.mbj@tail-f.com>
From: Jernej Tuljak 
Message-ID: <56716238.2030100@mg-soft.si>
Date: Wed, 16 Dec 2015 14:08:08 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <20151216.134855.549606106792110111.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y02: context node
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 13:08:12 -0000

Martin Bjorklund je 16.12.2015 ob 13:48 napisal:
> Jernej Tuljak  wrote:
>> Martin Bjorklund je 25.11.2015 ob 11:16 napisal:
>>> Ladislav Lhotka  wrote:
>>>> Hi,
>>>>
>>>> I'd like to resolve this issue. Here is a complete example (valid, I
>>>> believe):
>>>>
>>>> module context {
>>>>     namespace "http://example.com/context";
>>>>     prefix ctx;
>>>>
>>>>     leaf foo {
>>>>       config false;
>>>>       type uint32;
>>>>     }
>>>>     rpc oper {
>>>>       output {
>>>>         must "/foo mod foo = 0";
>>>>         leaf foo {
>>>>           type uint32;
>>>>         }
>>>>       }
>>>>     }
>>>> }
>>>>
>>>> 1. What does the accessible tree look like?
>>> Note that the anser to this depends on the outcomne of Y04.  Andy has
>>> strong objections to Y04-02, and proposed Y04-04 instead.
>>>
>>> Assuming Y04-02, and assuming /foo has the value 20 and the oper rpc's
>>> result has foo = 10, the accessible tree would look like this:
>>>
>>>      
>>>        +-- oper
>>>        |   +-- foo = 10
>>>        +-- foo = 20
>>>
>>>
>>> (If we instead move back to Y04-04, the accessible tree would be:
>>>
>>>      
>>>        +-- oper
>>>            +-- foo = 10
>>>
>>> )
>>>
>>>> 2. What is the context node for the "must" expression?
>>>    /oper
>> This change to the accessible tree (1.0 --> 1.1) may break some
>> existing "when" XPath expressions (those under "output" statement).
> Maybe.  The old text said:
>
>     o  If the context node represents RPC output parameters, the tree is
>        the RPC reply instance document.
>
> So this probably meant that for this definition:
>
>    module ex {
>      ...
>      prefix x;
>      ...
>      rpc foo {
>        output {
>          leaf bar { ... }
>        }
>      }
>    }
>
> The accessile tree was:
>
>     nc:rpc-reply
>       +-- x:bar
>
> This is very NETCONF-specifc.  With 1.1, the tree would be:
>
>     x:foo
>       +-- x:bar
>
> which is protocol-neutral.
>
>> Is
>> this compatible with 1.1 charter - "All compliant YANG 1.0 modules
>> must be accepted as compliant YANG 1.1 modules"?
>>
>>    rpc my-rpc {
>>      output {
>>        uses my-stuff {
>>          when "specific-param = 'foo'";// 1.0
>> // when "my-rpc/specific-param = 'foo'" // 1.1
> This is not correct.  If a relative path is used, it would be the same
> in 1.0 and 1.1.

I disagree due to current text:

    o  data node: A node in the schema tree that can be instantiated in a
       data tree.  One of container, leaf, leaf-list, list, anydata, and
       anyxml.

    o  If the XPath expression is defined in a substatement to an
       "output" statement in an "rpc" or "action" statement, the
       accessible tree is the RPC or action operation instance, all state
       data in the server, and the running configuration datastore.  The
       root node has top-level data nodes in all modules as children.
       Additionally, for an RPC, the root node also has the node
       representing the RPC operation being defined as a child.  The node
       representing the operation being defined has the operation's
       output parameters as children.

    o  If the "when" statement is a child of a "uses", "choice", or
       "case" statement, then the context node is the closest ancestor
       node to the "uses", "choice", or "case" node that is also a data
       node.  If no such node exists, the context node is the root node.
       The accessible tree is tentatively altered during the processing
       of the XPath expression by removing all instances (if any) of the
       nodes added by the "uses", "choice", or "case" statement.


It clearly says that the context node is the root node ("/"), not the 
node representing the RPC ("/my-rpc"), which is a child to root node. 
The "root node" aka "document root" can only mean a single thing  XPath 
terminology.

Jernej

>
> If an absolute path is used, it would be:
>
>     when "/nc:rpc-reply/x:specific-param = 'foo'"; // 1.0
>     when "/x:my-rpc/x:specific-param = 'foo'";     // 1.1
>
>
> I wonder if any implementation of 1.0 supports this absolute form.
>
>
> /martin
>
>
>>        }
>>        leaf specific-param {
>>          type string;
>>        }
>>      }
>>    }
>>
>> Jernej
>>
>>> /martin
>>>
>>>
>>>
>>>> Thanks, Lada
>>>>
>>>> Martin Bjorklund  writes:
>>>>
>>>>> Ladislav Lhotka  wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Y02-01 allows "must" as a substatement of "input", "output" and
>>>>>> "notification" but for these cases the specification of the context
>>>>>> node in sec. 7.5.3 doesn't work.
>>>>>>
>>>>>>      o  The context node is the node in the accessible tree for which the
>>>>>>         "must" statement is defined.
>>>>> You are right.  But note how the accessible tree is defined.  There is
>>>>> a node for the operation / notification.  This node should be the
>>>>> context node:
>>>>>
>>>>>      o  If the "must" statement is a substatement of a "notification"
>>>>>         statement, the context node is the node representing the
>>>>>         notification in the accessible tree.
>>>>>
>>>>>      o  If the "must" statement is a substatement of a "input"
>>>>>         statement, the context node is the node representing the
>>>>>         operation in the accessible tree.
>>>>>
>>>>>      o  If the "must" statement is a substatement of a "output"
>>>>>         statement, the context node is the node representing the
>>>>>         operation in the accessible tree.
>>>>>
>>>>>
>>>>> /martin
>>>> -- 
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>>
>>> _______________________________________________
>>> 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 Dec 16 05:13:05 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3CF51B2D73 for ; Wed, 16 Dec 2015 05:13:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 bzc6MkRv1Cwk for ; Wed, 16 Dec 2015 05:13:03 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 14CC51B2D71 for ; Wed, 16 Dec 2015 05:13:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450271554; bh=strvHC+PqtBK/Eo3rGXiSFOgnVYCj9hoyinYby5AdQI=; h=From:Subject:Date:Cc:To; b=FQwl4IGzxdhb8c0xvbiOsLLbCB0Zc8uVBN01cheoj0X0N2uW6yOlWrDHI5KWpN10h ahCXxxVBq+liUSINw/tavzDs/TTHevLSIDr+tErMLP15dFberf6CYWMLV1Sn8Xo6f9 ZyV6zSDx3oerBVjK2dZW9WZ2aFef9aCbojsViKiA=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=75.67.110.86; 
From: Nadeau Thomas 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Wed, 16 Dec 2015 08:12:56 -0500
Message-Id: <24E7144A-1329-403C-AF8C-E8EFE9FB97C4@lucidvision.com>
To: netmod WG 
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=3 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=75.67.110.86
X-IP-stats: Notspam Incoming Last 0, First 0, in=3, out=0, spam=0 Known=true ip=75.67.110.86
Archived-At: 
Cc: netmod-chairs@tools.ietf.org
Subject: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 13:13:04 -0000

	This is a WG Last Call on draft-ietf-netmod-opstate-reqs-01.
Please post comments on this draft by Wednesday, December 30, 2015
at 9AM EST.

	Tom/Kent



From nobody Wed Dec 16 05:13:07 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60AD1B2D6E for ; Wed, 16 Dec 2015 05:13:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 5Uq3sM2CwQXU for ; Wed, 16 Dec 2015 05:13:03 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 E94811B2D75 for ; Wed, 16 Dec 2015 05:13:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450271555; bh=Rx7nwD3JrRV/TJDfD2NgBKr5K0f9PFNIPlOrdWS1xx0=; h=From:Subject:Date:Cc:To; b=ql7dJHoeQCyQX9vMPANc7kTV2NvtPFIDOfMOlJNuY6mHkdEciy3FNYZz9RPaCG9/L i7W2rS9baVrQc9z2pj5+tdn0l67bUVtYOkJFKfOmXSMLjK4zaCM0db8UEqphuSLseo RYAJhOh8LKIoTgu/Yu2JdQGvhRmnCqBJig+sw3OY=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=75.67.110.86; 
From: Nadeau Thomas 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 16 Dec 2015 08:13:00 -0500
Message-Id: 
To: netmod WG 
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=4 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=75.67.110.86
X-IP-stats: Notspam Incoming Last 0, First 0, in=4, out=0, spam=0 Known=true ip=75.67.110.86
Archived-At: 
Cc: netmod-chairs@tools.ietf.org
Subject: [netmod] IPR Check: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 13:13:05 -0000

This mail starts the IPR poll on draft-ietf-netmod-opstate-reqs-01.

Are you aware of any IPR that applies to =
draft-ietf-netmod-opstate-reqs-01?
If so, has this IPR been disclosed in compliance with IETF IPR rules =
(see RFCs
3979, 4879, 3669 and 5378 for more details)?

If you are listed as a document author or contributor please respond to =
this
email explicitly regardless of whether or not you are aware of any =
relevant IPR.
The response needs to be sent to the NETMOD WG mailing list.  The =
document
will not advance to the next stage until a response has been received =
from each
author and contributor.

If you are on the NETMOD WG email list but are not listed as an author =
or
contributor, then please explicitly respond only if you are aware of any =
IPR that
has not yet been disclosed in conformance with IETF rules.

Thank you,

Kent and Tom, NETMOD WG Chairs


From nobody Wed Dec 16 05:15:50 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A44B01A8871 for ; Wed, 16 Dec 2015 05:15:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 xp1ucM7p3dMI for ; Wed, 16 Dec 2015 05:15:47 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 06ACF1A8896 for ; Wed, 16 Dec 2015 05:15:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450271718; bh=ZwKB9b3k9CaIKB2VdAEPMQzwPPCl+5hRD5YwTd6F90w=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=IREeaTh9q3jovlnplkvncko5VSVs+CvY3HISoUOaqWTAlvTAZRGQ9KBeqLTAFd8oA D0qRKfqyQo/xVw1aNvnVCOJPlq9jALm78AqLYnD9oI9gXZiR4taz3fvDrY9/X/anUR IYzvZvRpkZgf5UtcSP57WFi0F4lwHcW7ONst+VnY=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=75.67.110.86; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Nadeau Thomas 
In-Reply-To: 
Date: Wed, 16 Dec 2015 08:13:43 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <5ACE20AC-0F8E-4E1B-8873-07D9F0F749E7@lucidvision.com>
References: 
To: netmod WG 
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=5 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=75.67.110.86
X-IP-stats: Notspam Incoming Last 0, First 0, in=5, out=0, spam=0 Known=true ip=75.67.110.86
Archived-At: 
Cc: netmod-chairs@tools.ietf.org
Subject: Re: [netmod] IPR Check: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 13:15:48 -0000

	I have no nor know of any IPR Claims against this document.

	=E2=80=94Tom (speaking as an individual contributor)



> On Dec 16, 2015:8:13 AM, at 8:13 AM, Nadeau Thomas =
 wrote:
>=20
> This mail starts the IPR poll on draft-ietf-netmod-opstate-reqs-01.
>=20
> Are you aware of any IPR that applies to =
draft-ietf-netmod-opstate-reqs-01?
> If so, has this IPR been disclosed in compliance with IETF IPR rules =
(see RFCs
> 3979, 4879, 3669 and 5378 for more details)?
>=20
> If you are listed as a document author or contributor please respond =
to this
> email explicitly regardless of whether or not you are aware of any =
relevant IPR.
> The response needs to be sent to the NETMOD WG mailing list.  The =
document
> will not advance to the next stage until a response has been received =
from each
> author and contributor.
>=20
> If you are on the NETMOD WG email list but are not listed as an author =
or
> contributor, then please explicitly respond only if you are aware of =
any IPR that
> has not yet been disclosed in conformance with IETF rules.
>=20
> Thank you,
>=20
> Kent and Tom, NETMOD WG Chairs
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Dec 16 05:22:55 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19D51B2D59 for ; Wed, 16 Dec 2015 05:22:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 ocaIzxNaX311 for ; Wed, 16 Dec 2015 05:22:52 -0800 (PST)
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 A7C281A8AF9 for ; Wed, 16 Dec 2015 05:22:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2447; q=dns/txt; s=iport; t=1450272171; x=1451481771; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=lAat8eHnHsHyZLOQmoflBVs7TTO+1eqiihPMzLlyflA=; b=BoKbhvzeLf2x1fuCxC0FR+HZgBKxhZvMlVwn6FAlWG16o/jdU2iMILo9 nshE6SxqngCVbD1arESpXOEseF3uOz+1jieZ+8YPT9OTh/GdFAVM82KIq r0AzbcQs8R3y7xsqiZ3HNWgtgO113j7ifpiE+3TYTUZxKQh9+e/uhrbZB s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQASZXFW/xbLJq1VCYQMbb1kAQ2BY?= =?us-ascii?q?xcKhSJKAoFfFAEBAQEBAQGBCoQ1AQEEAQEBGgYPAQU2CgEQCw4KAgIFFgsCAgk?= =?us-ascii?q?DAgECARUwBg0GAgEBiCsOrDCSDQEBAQEBAQEBAQEBAQEBAQEBAQEWBIEBhVWEf?= =?us-ascii?q?YQxg0aBSQWFWZEjhTmFVII7gVyERYMFk3QfAQFCgkSBQT00hREBAQE?=
X-IronPort-AV: E=Sophos;i="5.20,437,1444694400"; d="scan'208";a="618287986"
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; 16 Dec 2015 13:22:49 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tBGDMn9J001472; Wed, 16 Dec 2015 13:22:49 GMT
To: Nadeau Thomas 
References: <0C987A22-5602-438D-B42D-82C8476AA513@lucidvision.com> <23D79879-556D-4523-8CAB-845C10BC76CC@nic.cz> <5671271D.40603@cisco.com> <2489AF1E-0DB4-456C-8D74-8B02BDF41E97@lucidvision.com>
From: Benoit Claise 
Message-ID: <567165A9.1080400@cisco.com>
Date: Wed, 16 Dec 2015 14:22:49 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <2489AF1E-0DB4-456C-8D74-8B02BDF41E97@lucidvision.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] call for consensus to adopt draft-entitydt-netmod-entity as NETMOD WG draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 13:22:53 -0000

Hi Tom,

Good question. I should have made it clear. Sorry.
"While I understand the concern of work prioritization, one of the 
issues in NETMOD is that we need to grow the number of people involved 
in participating/editing/reviewing, and I'm happy to see Dan and Jimmy 
taking the lead here." This remark is done as OPS AD.

Also, I discussed, as OPS AD, with the chairs, having an identity YANG 
model design team in the past.
However, my "support" below is an individual.

Regards, Benoit
>> On Dec 16, 2015:3:55 AM, at 3:55 AM, Benoit Claise  wrote:
>>
>> Dear all,
>>>> On 15 Dec 2015, at 13:34, Nadeau Thomas  wrote:
>>>>
>>>>
>>>> 	NETMOD:
>>>>
>>>> 	The Broadband Forum and the members of the design team who worked on the
>>>> IETF Entity module have asked that the working group considerthe ietf-entity YANG module
>>>> (currently https://datatracker.ietf.org/doc/draft-entitydt-netmod-entity/ which is
>>>> still in individual draft status) as a working group item.
>>>>
>>>> 	Should we move to adopt draft-entitydt-netmod-entity as a WG item and
>>>> correspondingly add this to the WG charter as a milestone?  Please comment by
>>>> Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs will
>>>> gauge whether or not there is consensus to move forward with the document.
>> Support.
>>> I would strongly prefer to finish the existing items first, or at least the critical ones on which other work depends. Adding more items would mean that both old and new items receive less attention on the average. We already have at most one or two reviews per WGLC, and this is IMO insufficient.
>> While I understand the concern of work prioritization, one of the issues in NETMOD is that we need to grow the number of people involved in participating/editing/reviewing, and I'm happy to see Dan and Jimmy taking the lead here.
>>
>> Regards, Benoit
> 	Are you speaking as AD or as an individual?
>
> 	—Tom
>
>
>>> Lada
>>>
>>>> 	—Tom
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Wed Dec 16 05:53:49 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5245F1B2D94 for ; Wed, 16 Dec 2015 05:53:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 1qVPyUDB8FUs for ; Wed, 16 Dec 2015 05:53:46 -0800 (PST)
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 450D91B2D95 for ; Wed, 16 Dec 2015 05:53:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1195; q=dns/txt; s=iport; t=1450274026; x=1451483626; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=PBRWK1EjSeGESdzNuO2i/Wcwgbb5MGeRwyWJnd27gqM=; b=cGp7zqHbu75Q4yI1evW8PH959Xf0zCaN4OgPXX+ZHOLHOG6Lu/1/g6rC 2ezplwOTllyd51loggoOKxPLi87gkhCabRxkfpp0qGthM3ThUAHp/Zc73 wLYH4vNTpbALhKY3kKJRbetrTLxbzhnuPvPlr9u3M9M5rQbos4hyefVtx s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQDUa3FW/xbLJq1ehAxtvWcBDYFjF?= =?us-ascii?q?wqFIkoCgV8UAQEBAQEBAYEKhDUBAQQBAQE1NgYEARALDgoJFg8JAwIBAgEVMAY?= =?us-ascii?q?BDAYCAQGIKw6+SQEBAQEBAQEBAQEBAQEBAQEBAQEBARQEhlaEfYQqEAIBhQMBB?= =?us-ascii?q?JZ8jUiBXIRFgwWTdR8BAUKEBD40hGEBAQE?=
X-IronPort-AV: E=Sophos;i="5.20,437,1444694400"; d="scan'208";a="618289302"
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; 16 Dec 2015 13:53:42 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tBGDrgEn012307; Wed, 16 Dec 2015 13:53:42 GMT
To: Nadeau Thomas , netmod WG 
References: 
From: Robert Wilton 
Message-ID: <56716CE6.9060801@cisco.com>
Date: Wed, 16 Dec 2015 13:53:42 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod-chairs@tools.ietf.org
Subject: Re: [netmod] IPR Check: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 13:53:48 -0000

I have no nor know of any IPR Claims against this document.

Thanks,
Rob


On 16/12/2015 13:13, Nadeau Thomas wrote:
> This mail starts the IPR poll on draft-ietf-netmod-opstate-reqs-01.
>
> Are you aware of any IPR that applies to draft-ietf-netmod-opstate-reqs-01?
> If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs
> 3979, 4879, 3669 and 5378 for more details)?
>
> If you are listed as a document author or contributor please respond to this
> email explicitly regardless of whether or not you are aware of any relevant IPR.
> The response needs to be sent to the NETMOD WG mailing list.  The document
> will not advance to the next stage until a response has been received from each
> author and contributor.
>
> If you are on the NETMOD WG email list but are not listed as an author or
> contributor, then please explicitly respond only if you are aware of any IPR that
> has not yet been disclosed in conformance with IETF rules.
>
> Thank you,
>
> Kent and Tom, NETMOD WG Chairs
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Wed Dec 16 06:10:52 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23A71B2DA1 for ; Wed, 16 Dec 2015 06:10:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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 hwZnQe9z1qvy for ; Wed, 16 Dec 2015 06:10:49 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68CF61B2D9A for ; Wed, 16 Dec 2015 06:10:49 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:f1df:ae71:a097:15dc] (unknown [IPv6:2001:718:1a02:1:f1df:ae71:a097:15dc]) by mail.nic.cz (Postfix) with ESMTPSA id C5890181923; Wed, 16 Dec 2015 15:10:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450275047; bh=uNJb9qLbzl9mLubxTdiYxWfFBB2aXucrFba3J+RsbKY=; h=From:Date:To; b=RUKGwWfuJtC6RPjolhW+ZojNg/XQZ/kyN9nuJ09V0Yfcxj6VT8Xcb8yFs9NBQxFKz DJEOBYSvUPq202EUXAtbWeKsvtSM5YvYE3f+GNMTFhn///QSTf+ROTeqdxioynOcGX w7qXOKjDbL27dxBhx0UJhN5TW6idYK7EjeCCO8QU=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <56716238.2030100@mg-soft.si>
Date: Wed, 16 Dec 2015 15:10:48 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <960262F1-65C6-4091-A95C-38C1FCD8256A@nic.cz>
References:  <20151125.111622.1788981016001119642.mbj@tail-f.com> <56715ABC.1070209@mg-soft.si> <20151216.134855.549606106792110111.mbj@tail-f.com> <56716238.2030100@mg-soft.si>
To: Jernej Tuljak 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y02: context node
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 14:10:51 -0000

> On 16 Dec 2015, at 14:08, Jernej Tuljak  wrote:
>=20
> Martin Bjorklund je 16.12.2015 ob 13:48 napisal:
>> Jernej Tuljak  wrote:
>>> Martin Bjorklund je 25.11.2015 ob 11:16 napisal:
>>>> Ladislav Lhotka  wrote:
>>>>> Hi,
>>>>>=20
>>>>> I'd like to resolve this issue. Here is a complete example (valid, =
I
>>>>> believe):
>>>>>=20
>>>>> module context {
>>>>>    namespace "http://example.com/context";
>>>>>    prefix ctx;
>>>>>=20
>>>>>    leaf foo {
>>>>>      config false;
>>>>>      type uint32;
>>>>>    }
>>>>>    rpc oper {
>>>>>      output {
>>>>>        must "/foo mod foo =3D 0";
>>>>>        leaf foo {
>>>>>          type uint32;
>>>>>        }
>>>>>      }
>>>>>    }
>>>>> }
>>>>>=20
>>>>> 1. What does the accessible tree look like?
>>>> Note that the anser to this depends on the outcomne of Y04.  Andy =
has
>>>> strong objections to Y04-02, and proposed Y04-04 instead.
>>>>=20
>>>> Assuming Y04-02, and assuming /foo has the value 20 and the oper =
rpc's
>>>> result has foo =3D 10, the accessible tree would look like this:
>>>>=20
>>>>     
>>>>       +-- oper
>>>>       |   +-- foo =3D 10
>>>>       +-- foo =3D 20
>>>>=20
>>>>=20
>>>> (If we instead move back to Y04-04, the accessible tree would be:
>>>>=20
>>>>     
>>>>       +-- oper
>>>>           +-- foo =3D 10
>>>>=20
>>>> )
>>>>=20
>>>>> 2. What is the context node for the "must" expression?
>>>>   /oper
>>> This change to the accessible tree (1.0 --> 1.1) may break some
>>> existing "when" XPath expressions (those under "output" statement).
>> Maybe.  The old text said:
>>=20
>>    o  If the context node represents RPC output parameters, the tree =
is
>>       the RPC reply instance document.
>>=20
>> So this probably meant that for this definition:
>>=20
>>   module ex {
>>     ...
>>     prefix x;
>>     ...
>>     rpc foo {
>>       output {
>>         leaf bar { ... }
>>       }
>>     }
>>   }
>>=20
>> The accessile tree was:
>>=20
>>    nc:rpc-reply
>>      +-- x:bar
>>=20
>> This is very NETCONF-specifc.  With 1.1, the tree would be:
>>=20
>>    x:foo
>>      +-- x:bar
>>=20
>> which is protocol-neutral.
>>=20
>>> Is
>>> this compatible with 1.1 charter - "All compliant YANG 1.0 modules
>>> must be accepted as compliant YANG 1.1 modules"?
>>>=20
>>>   rpc my-rpc {
>>>     output {
>>>       uses my-stuff {
>>>         when "specific-param =3D 'foo'";// 1.0
>>> // when "my-rpc/specific-param =3D 'foo'" // 1.1
>> This is not correct.  If a relative path is used, it would be the =
same
>> in 1.0 and 1.1.
>=20
> I disagree due to current text:
>=20
>   o  data node: A node in the schema tree that can be instantiated in =
a
>      data tree.  One of container, leaf, leaf-list, list, anydata, and
>      anyxml.
>=20
>   o  If the XPath expression is defined in a substatement to an
>      "output" statement in an "rpc" or "action" statement, the
>      accessible tree is the RPC or action operation instance, all =
state
>      data in the server, and the running configuration datastore.  The
>      root node has top-level data nodes in all modules as children.
>      Additionally, for an RPC, the root node also has the node
>      representing the RPC operation being defined as a child.  The =
node
>      representing the operation being defined has the operation's
>      output parameters as children.
>=20
>   o  If the "when" statement is a child of a "uses", "choice", or
>      "case" statement, then the context node is the closest ancestor
>      node to the "uses", "choice", or "case" node that is also a data
>      node.  If no such node exists, the context node is the root node.
>      The accessible tree is tentatively altered during the processing
>      of the XPath expression by removing all instances (if any) of the
>      nodes added by the "uses", "choice", or "case" statement.
>=20
>=20
> It clearly says that the context node is the root node ("/"), not the =
node representing the RPC ("/my-rpc"), which is a child to root node. =
The "root node" aka "document root" can only mean a single thing XPath =
terminology.

RFC 6020 clearly says that the tree is the rpc reply instance document, =
so it is a different document whose root node coincides with =
. The problem of 6020bis is that we need a definition that's =
independent of XML, and that's not so easy, but I agree with Martin that =
nothing should change for relative paths.

Lada=20

>=20
> Jernej
>=20
>>=20
>> If an absolute path is used, it would be:
>>=20
>>    when "/nc:rpc-reply/x:specific-param =3D 'foo'"; // 1.0
>>    when "/x:my-rpc/x:specific-param =3D 'foo'";     // 1.1
>>=20
>>=20
>> I wonder if any implementation of 1.0 supports this absolute form.
>>=20
>>=20
>> /martin
>>=20
>>=20
>>>       }
>>>       leaf specific-param {
>>>         type string;
>>>       }
>>>     }
>>>   }
>>>=20
>>> Jernej
>>>=20
>>>> /martin
>>>>=20
>>>>=20
>>>>=20
>>>>> Thanks, Lada
>>>>>=20
>>>>> Martin Bjorklund  writes:
>>>>>=20
>>>>>> Ladislav Lhotka  wrote:
>>>>>>> Hi,
>>>>>>>=20
>>>>>>> Y02-01 allows "must" as a substatement of "input", "output" and
>>>>>>> "notification" but for these cases the specification of the =
context
>>>>>>> node in sec. 7.5.3 doesn't work.
>>>>>>>=20
>>>>>>>     o  The context node is the node in the accessible tree for =
which the
>>>>>>>        "must" statement is defined.
>>>>>> You are right.  But note how the accessible tree is defined.  =
There is
>>>>>> a node for the operation / notification.  This node should be the
>>>>>> context node:
>>>>>>=20
>>>>>>     o  If the "must" statement is a substatement of a =
"notification"
>>>>>>        statement, the context node is the node representing the
>>>>>>        notification in the accessible tree.
>>>>>>=20
>>>>>>     o  If the "must" statement is a substatement of a "input"
>>>>>>        statement, the context node is the node representing the
>>>>>>        operation in the accessible tree.
>>>>>>=20
>>>>>>     o  If the "must" statement is a substatement of a "output"
>>>>>>        statement, the context node is the node representing the
>>>>>>        operation in the accessible tree.
>>>>>>=20
>>>>>>=20
>>>>>> /martin
>>>>> --=20
>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>> PGP Key ID: E74E8C0C
>>>>>=20
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed Dec 16 06:28:26 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338951B2DD2 for ; Wed, 16 Dec 2015 06:28:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 XpLE2mMUPSNH for ; Wed, 16 Dec 2015 06:28:22 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3233C1B2DD9 for ; Wed, 16 Dec 2015 06:28:11 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 34FF8FB1 for ; Wed, 16 Dec 2015 15:28:09 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 1D-0pT7IWaFM for ; Wed, 16 Dec 2015 15:28:08 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 16 Dec 2015 15:28:08 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 40B8320056 for ; Wed, 16 Dec 2015 15:28:08 +0100 (CET)
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 6Am14eAacqwk; Wed, 16 Dec 2015 15:28:07 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6422820055; Wed, 16 Dec 2015 15:28:07 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 75AC93940277; Wed, 16 Dec 2015 15:28:06 +0100 (CET)
Date: Wed, 16 Dec 2015 15:28:05 +0100
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20151216142805.GA66356@elstar.local>
Mail-Followup-To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Subject: [netmod] IPR Check: draft-ietf-netmod-rfc6020bis-09
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 14:28:24 -0000

This mail starts the IPR poll on draft-ietf-netmod-rfc6020bis-09.

Are you aware of any IPR that applies to draft-ietf-netmod-rfc6020bis-09?
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details)?

If you are listed as a document author or contributor please respond
to this email explicitly regardless of whether or not you are aware of
any relevant IPR. The response needs to be sent to the NETMOD WG
mailing list. The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the NETMOD WG email list but are not listed as an author
or contributor, then please explicitly respond only if you are aware
of any IPR that has not yet been disclosed in conformance with IETF
rules.

/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 Dec 16 06:36:15 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 293221B2DC4 for ; Wed, 16 Dec 2015 06:36:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 xOaTkVqjAknb for ; Wed, 16 Dec 2015 06:36:12 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 817FB1A89F0 for ; Wed, 16 Dec 2015 06:36:12 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:f1df:ae71:a097:15dc] (unknown [IPv6:2001:718:1a02:1:f1df:ae71:a097:15dc]) by mail.nic.cz (Postfix) with ESMTPSA id 089F3181153; Wed, 16 Dec 2015 15:36:11 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450276571; bh=XqZaJSFPE+0Hq7klCQKunljX8i3wDnShZ0jfTQT5muo=; h=From:Date:To; b=ju/ZI+mCdMMtAG39E9veQgh7dudLMJ1bBGFocPbh3sBLYXdtLqyPhJx/EgSO0QEpB A9Tj4BvQI1wj35Z/LYw7fWJt8/3KE+Y4gyVmRVQaWwSn839YCbE2ZUnKisIIhMZvjV pGqOVGuLgbc7hT1AvsRQkYokkEOLGQ5d+rtxLZLQ=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <5671271D.40603@cisco.com>
Date: Wed, 16 Dec 2015 15:36:11 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <0C987A22-5602-438D-B42D-82C8476AA513@lucidvision.com> <23D79879-556D-4523-8CAB-845C10BC76CC@nic.cz> <5671271D.40603@cisco.com>
To: Benoit Claise 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] call for consensus to adopt draft-entitydt-netmod-entity as NETMOD WG draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 14:36:14 -0000

> On 16 Dec 2015, at 09:55, Benoit Claise  wrote:
>=20
> Dear all,
>>> On 15 Dec 2015, at 13:34, Nadeau Thomas  =
wrote:
>>>=20
>>>=20
>>> 	NETMOD:
>>>=20
>>> 	The Broadband Forum and the members of the design team who =
worked on the
>>> IETF Entity module have asked that the working group considerthe =
ietf-entity YANG module
>>> (currently =
https://datatracker.ietf.org/doc/draft-entitydt-netmod-entity/ which is
>>> still in individual draft status) as a working group item.
>>>=20
>>> 	Should we move to adopt draft-entitydt-netmod-entity as a WG =
item and
>>> correspondingly add this to the WG charter as a milestone?  Please =
comment by
>>> Tuesday, December 22, 2015 at 9AM EST at which time the WG Chairs =
will
>>> gauge whether or not there is consensus to move forward with the =
document.
> Support.
>> I would strongly prefer to finish the existing items first, or at =
least the critical ones on which other work depends. Adding more items =
would mean that both old and new items receive less attention on the =
average. We already have at most one or two reviews per WGLC, and this =
is IMO insufficient.
> While I understand the concern of work prioritization, one of the =
issues in NETMOD is that we need to grow the number of people involved =
in participating/editing/reviewing, and I'm happy to see Dan and Jimmy =
taking the lead here.

Of course, my comment wasn't directed against this draft in particular, =
or Dan and Jimmy. Unfortunately, the increase in the number of I-Ds =
doesn't seems to be proportional to the increase in the number of =
reviewers.

Lada

>=20
> Regards, Benoit
>>=20
>> Lada
>>=20
>>> 	=E2=80=94Tom
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed Dec 16 06:36:28 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B12F21A88AC for ; Wed, 16 Dec 2015 06:36:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 D4osQHFAh03J for ; Wed, 16 Dec 2015 06:36:23 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBDE1B2DDB for ; Wed, 16 Dec 2015 06:36:22 -0800 (PST)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 162C01AE03CD; Wed, 16 Dec 2015 15:36:21 +0100 (CET)
Date: Wed, 16 Dec 2015 15:37:21 +0100 (CET)
Message-Id: <20151216.153721.490078773679678705.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20151216142805.GA66356@elstar.local>
References: <20151216142805.GA66356@elstar.local>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] IPR Check: draft-ietf-netmod-rfc6020bis-09
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 14:36:27 -0000

Hi,

I am not aware of any IPR related to draft-ietf-netmod-rfc6020bis-09.


/martin


Juergen Schoenwaelder  wrote:
> This mail starts the IPR poll on draft-ietf-netmod-rfc6020bis-09.
> 
> Are you aware of any IPR that applies to draft-ietf-netmod-rfc6020bis-09?
> If so, has this IPR been disclosed in compliance with IETF IPR rules
> (see RFCs 3979, 4879, 3669 and 5378 for more details)?
> 
> If you are listed as a document author or contributor please respond
> to this email explicitly regardless of whether or not you are aware of
> any relevant IPR. The response needs to be sent to the NETMOD WG
> mailing list. The document will not advance to the next stage until a
> response has been received from each author and contributor.
> 
> If you are on the NETMOD WG email list but are not listed as an author
> or contributor, then please explicitly respond only if you are aware
> of any IPR that has not yet been disclosed in conformance with IETF
> rules.
> 
> /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
> 


From nobody Wed Dec 16 07:18:28 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9421A00C3 for ; Wed, 16 Dec 2015 07:18:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 CVCbUq_4q4Aw for ; Wed, 16 Dec 2015 07:18:24 -0800 (PST)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8E96E1A013B for ; Wed, 16 Dec 2015 07:17:46 -0800 (PST)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 3200FC4175C2; Wed, 16 Dec 2015 16:17:45 +0100 (CET)
To: Ladislav Lhotka 
References:  <20151125.111622.1788981016001119642.mbj@tail-f.com> <56715ABC.1070209@mg-soft.si> <20151216.134855.549606106792110111.mbj@tail-f.com> <56716238.2030100@mg-soft.si> <960262F1-65C6-4091-A95C-38C1FCD8256A@nic.cz>
From: Jernej Tuljak 
Message-ID: <56718098.90703@mg-soft.si>
Date: Wed, 16 Dec 2015 16:17:44 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <960262F1-65C6-4091-A95C-38C1FCD8256A@nic.cz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y02: context node
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 15:18:27 -0000

Ladislav Lhotka je 16.12.2015 ob 15:10 napisal:
>> On 16 Dec 2015, at 14:08, Jernej Tuljak  wrote:
>>
>> Martin Bjorklund je 16.12.2015 ob 13:48 napisal:
>>> Jernej Tuljak  wrote:
>>>> Martin Bjorklund je 25.11.2015 ob 11:16 napisal:
>>>>> Ladislav Lhotka  wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I'd like to resolve this issue. Here is a complete example (valid, I
>>>>>> believe):
>>>>>>
>>>>>> module context {
>>>>>>     namespace "http://example.com/context";
>>>>>>     prefix ctx;
>>>>>>
>>>>>>     leaf foo {
>>>>>>       config false;
>>>>>>       type uint32;
>>>>>>     }
>>>>>>     rpc oper {
>>>>>>       output {
>>>>>>         must "/foo mod foo = 0";
>>>>>>         leaf foo {
>>>>>>           type uint32;
>>>>>>         }
>>>>>>       }
>>>>>>     }
>>>>>> }
>>>>>>
>>>>>> 1. What does the accessible tree look like?
>>>>> Note that the anser to this depends on the outcomne of Y04.  Andy has
>>>>> strong objections to Y04-02, and proposed Y04-04 instead.
>>>>>
>>>>> Assuming Y04-02, and assuming /foo has the value 20 and the oper rpc's
>>>>> result has foo = 10, the accessible tree would look like this:
>>>>>
>>>>>      
>>>>>        +-- oper
>>>>>        |   +-- foo = 10
>>>>>        +-- foo = 20
>>>>>
>>>>>
>>>>> (If we instead move back to Y04-04, the accessible tree would be:
>>>>>
>>>>>      
>>>>>        +-- oper
>>>>>            +-- foo = 10
>>>>>
>>>>> )
>>>>>
>>>>>> 2. What is the context node for the "must" expression?
>>>>>    /oper
>>>> This change to the accessible tree (1.0 --> 1.1) may break some
>>>> existing "when" XPath expressions (those under "output" statement).
>>> Maybe.  The old text said:
>>>
>>>     o  If the context node represents RPC output parameters, the tree is
>>>        the RPC reply instance document.
>>>
>>> So this probably meant that for this definition:
>>>
>>>    module ex {
>>>      ...
>>>      prefix x;
>>>      ...
>>>      rpc foo {
>>>        output {
>>>          leaf bar { ... }
>>>        }
>>>      }
>>>    }
>>>
>>> The accessile tree was:
>>>
>>>     nc:rpc-reply
>>>       +-- x:bar
>>>
>>> This is very NETCONF-specifc.  With 1.1, the tree would be:
>>>
>>>     x:foo
>>>       +-- x:bar
>>>
>>> which is protocol-neutral.
>>>
>>>> Is
>>>> this compatible with 1.1 charter - "All compliant YANG 1.0 modules
>>>> must be accepted as compliant YANG 1.1 modules"?
>>>>
>>>>    rpc my-rpc {
>>>>      output {
>>>>        uses my-stuff {
>>>>          when "specific-param = 'foo'";// 1.0
>>>> // when "my-rpc/specific-param = 'foo'" // 1.1
>>> This is not correct.  If a relative path is used, it would be the same
>>> in 1.0 and 1.1.
>> I disagree due to current text:
>>
>>    o  data node: A node in the schema tree that can be instantiated in a
>>       data tree.  One of container, leaf, leaf-list, list, anydata, and
>>       anyxml.
>>
>>    o  If the XPath expression is defined in a substatement to an
>>       "output" statement in an "rpc" or "action" statement, the
>>       accessible tree is the RPC or action operation instance, all state
>>       data in the server, and the running configuration datastore.  The
>>       root node has top-level data nodes in all modules as children.
>>       Additionally, for an RPC, the root node also has the node
>>       representing the RPC operation being defined as a child.  The node
>>       representing the operation being defined has the operation's
>>       output parameters as children.
>>
>>    o  If the "when" statement is a child of a "uses", "choice", or
>>       "case" statement, then the context node is the closest ancestor
>>       node to the "uses", "choice", or "case" node that is also a data
>>       node.  If no such node exists, the context node is the root node.
>>       The accessible tree is tentatively altered during the processing
>>       of the XPath expression by removing all instances (if any) of the
>>       nodes added by the "uses", "choice", or "case" statement.
>>
>>
>> It clearly says that the context node is the root node ("/"), not the node representing the RPC ("/my-rpc"), which is a child to root node. The "root node" aka "document root" can only mean a single thing XPath terminology.
> RFC 6020 clearly says that the tree is the rpc reply instance document, so it is a different document whose root node coincides with . The problem of 6020bis is that we need a definition that's independent of XML, and that's not so easy, but I agree with Martin that nothing should change for relative paths.

I'm not against the new accessible tree. That nothing should change for 
relative paths is a given, IMO. So what about absolute location paths?

The previous accessible tree for a "when" expression under "output" was:


   +- x:bar

and now it is:


   +- x:foo
     +- x:bar

The absolute path to "x:bar" was:

/x:bar

and is now:

/x:foo/x:bar

and this needs to be taken into account for at least relative paths to 
stay the same. Again, the root node is "/" in any case. So the context 
node needs to be set explicitly "/x:foo" for this corner case. I dare 
say it is not even a corner case. There is a similar YANG pattern to my 
"my-rpc" example in ietf-netconf-notifications for a "notification".

Jernej

>
> Lada
>
>> Jernej
>>
>>> If an absolute path is used, it would be:
>>>
>>>     when "/nc:rpc-reply/x:specific-param = 'foo'"; // 1.0
>>>     when "/x:my-rpc/x:specific-param = 'foo'";     // 1.1
>>>
>>>
>>> I wonder if any implementation of 1.0 supports this absolute form.
>>>
>>>
>>> /martin
>>>
>>>
>>>>        }
>>>>        leaf specific-param {
>>>>          type string;
>>>>        }
>>>>      }
>>>>    }
>>>>
>>>> Jernej
>>>>
>>>>> /martin
>>>>>
>>>>>
>>>>>
>>>>>> Thanks, Lada
>>>>>>
>>>>>> Martin Bjorklund  writes:
>>>>>>
>>>>>>> Ladislav Lhotka  wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Y02-01 allows "must" as a substatement of "input", "output" and
>>>>>>>> "notification" but for these cases the specification of the context
>>>>>>>> node in sec. 7.5.3 doesn't work.
>>>>>>>>
>>>>>>>>      o  The context node is the node in the accessible tree for which the
>>>>>>>>         "must" statement is defined.
>>>>>>> You are right.  But note how the accessible tree is defined.  There is
>>>>>>> a node for the operation / notification.  This node should be the
>>>>>>> context node:
>>>>>>>
>>>>>>>      o  If the "must" statement is a substatement of a "notification"
>>>>>>>         statement, the context node is the node representing the
>>>>>>>         notification in the accessible tree.
>>>>>>>
>>>>>>>      o  If the "must" statement is a substatement of a "input"
>>>>>>>         statement, the context node is the node representing the
>>>>>>>         operation in the accessible tree.
>>>>>>>
>>>>>>>      o  If the "must" statement is a substatement of a "output"
>>>>>>>         statement, the context node is the node representing the
>>>>>>>         operation in the accessible tree.
>>>>>>>
>>>>>>>
>>>>>>> /martin
>>>>>> -- 
>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>> PGP Key ID: E74E8C0C
>>>>>>
>>>>> _______________________________________________
>>>>> 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, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Wed Dec 16 08:04:03 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D731A1A5A for ; Wed, 16 Dec 2015 08:04:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 pp8SVXXJPofA for ; Wed, 16 Dec 2015 08:03:59 -0800 (PST)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 C1D201A19E9 for ; Wed, 16 Dec 2015 08:03:12 -0800 (PST)
Received: by mail-lf0-x236.google.com with SMTP id p203so32804763lfa.0 for ; Wed, 16 Dec 2015 08:03:12 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=v8tW/EIXc1t3mQTekVZc1fNLD0It6DmJf8/B6eyEnxQ=; b=Ozavxuj/ZfWE9087wExpbPW0yTrVeKtqaKghvFCbNHkL8DwnBG5XNZXFllTWN9ISvv 5szX17+mzZdNe1WTM20eQ2DnZ1eOL+auToX7HTtkDFNdHPbIBJePG4vteqpED1br+nrc fbejWuspxgl6WBYVVtVmw5KLp+fqVJqRJCKj/gOIg8+jwOhyXjuvJ8HYSvil/HTyrHBT lQFMiEzBJYxBc4DqRh1RoI+UAKlyb9FTUUWAWqdHvB/y5SvvYUpijNT5OmhIWr6IIlD5 H1VxhnIMJunXHLMc6zjuCqL4mJ5FCNUXT48h1ZZazA76KKbhR2D4cseA5MHvkbokrAMw 4YWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=v8tW/EIXc1t3mQTekVZc1fNLD0It6DmJf8/B6eyEnxQ=; b=Kl7i+swzwM9GRypWOhHkon0YSQyDHAtpgeCToPpjY2qphyAIGexwNwViCC+1c78JVh mUw8ovolxbzkzSqJoKpUsHmmrbjVCKWt5XNPynQT95NqwSIl1TrnMghFS58eqCiBsdNI p67nh8l6JRvVeLgxqd7cMi5tUpQ3FNn7K5TntJU3nBUHXE9KZt73wq6PH5411lAZVgjr N7x6Zn/7Q239EyvNORlGEC4w3IYl/eEEUxddOkQ9GMi9Eb7aaw6iQweqfMpNVwPKZaRP hXaiKggX23eGRNKCRRWNaw8F4XXgzAjV2WZdyb4lOkMECH+HcuJWybGRJalD9JB3uj8h StgA==
X-Gm-Message-State: ALoCoQljlWFlr/D/iFy871/UaxeSquT9m8qfsZWWHx470s5I3pbzjiEhcDmz/Eo0w8GsVe9NuYPve5T4mLaIqiqqL+DzOPLdbw==
MIME-Version: 1.0
X-Received: by 10.25.218.9 with SMTP id r9mr18990163lfg.138.1450281790709; Wed, 16 Dec 2015 08:03:10 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Wed, 16 Dec 2015 08:03:10 -0800 (PST)
In-Reply-To: <56718098.90703@mg-soft.si>
References:  <20151125.111622.1788981016001119642.mbj@tail-f.com> <56715ABC.1070209@mg-soft.si> <20151216.134855.549606106792110111.mbj@tail-f.com> <56716238.2030100@mg-soft.si> <960262F1-65C6-4091-A95C-38C1FCD8256A@nic.cz> <56718098.90703@mg-soft.si>
Date: Wed, 16 Dec 2015 08:03:10 -0800
Message-ID: 
From: Andy Bierman 
To: Jernej Tuljak 
Content-Type: multipart/alternative; boundary=001a11402600f5c0a30527060af7
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Y02: context node
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 16:04:02 -0000

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

On Wed, Dec 16, 2015 at 7:17 AM, Jernej Tuljak  wrote:

> Ladislav Lhotka je 16.12.2015 ob 15:10 napisal:
>
>> On 16 Dec 2015, at 14:08, Jernej Tuljak  wrote:
>>>
>>> Martin Bjorklund je 16.12.2015 ob 13:48 napisal:
>>>
>>>> Jernej Tuljak  wrote:
>>>>
>>>>> Martin Bjorklund je 25.11.2015 ob 11:16 napisal:
>>>>>
>>>>>> Ladislav Lhotka  wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I'd like to resolve this issue. Here is a complete example (valid, I
>>>>>>> believe):
>>>>>>>
>>>>>>> module context {
>>>>>>>     namespace "http://example.com/context";
>>>>>>>     prefix ctx;
>>>>>>>
>>>>>>>     leaf foo {
>>>>>>>       config false;
>>>>>>>       type uint32;
>>>>>>>     }
>>>>>>>     rpc oper {
>>>>>>>       output {
>>>>>>>         must "/foo mod foo = 0";
>>>>>>>         leaf foo {
>>>>>>>           type uint32;
>>>>>>>         }
>>>>>>>       }
>>>>>>>     }
>>>>>>> }
>>>>>>>
>>>>>>> 1. What does the accessible tree look like?
>>>>>>>
>>>>>> Note that the anser to this depends on the outcomne of Y04.  Andy has
>>>>>> strong objections to Y04-02, and proposed Y04-04 instead.
>>>>>>
>>>>>> Assuming Y04-02, and assuming /foo has the value 20 and the oper rpc's
>>>>>> result has foo = 10, the accessible tree would look like this:
>>>>>>
>>>>>>      
>>>>>>        +-- oper
>>>>>>        |   +-- foo = 10
>>>>>>        +-- foo = 20
>>>>>>
>>>>>>
>>>>>> (If we instead move back to Y04-04, the accessible tree would be:
>>>>>>
>>>>>>      
>>>>>>        +-- oper
>>>>>>            +-- foo = 10
>>>>>>
>>>>>> )
>>>>>>
>>>>>> 2. What is the context node for the "must" expression?
>>>>>>>
>>>>>>    /oper
>>>>>>
>>>>> This change to the accessible tree (1.0 --> 1.1) may break some
>>>>> existing "when" XPath expressions (those under "output" statement).
>>>>>
>>>> Maybe.  The old text said:
>>>>
>>>>     o  If the context node represents RPC output parameters, the tree is
>>>>        the RPC reply instance document.
>>>>
>>>> So this probably meant that for this definition:
>>>>
>>>>    module ex {
>>>>      ...
>>>>      prefix x;
>>>>      ...
>>>>      rpc foo {
>>>>        output {
>>>>          leaf bar { ... }
>>>>        }
>>>>      }
>>>>    }
>>>>
>>>> The accessile tree was:
>>>>
>>>>     nc:rpc-reply
>>>>       +-- x:bar
>>>>
>>>> This is very NETCONF-specifc.  With 1.1, the tree would be:
>>>>
>>>>     x:foo
>>>>       +-- x:bar
>>>>
>>>> which is protocol-neutral.
>>>>
>>>> Is
>>>>> this compatible with 1.1 charter - "All compliant YANG 1.0 modules
>>>>> must be accepted as compliant YANG 1.1 modules"?
>>>>>
>>>>>    rpc my-rpc {
>>>>>      output {
>>>>>        uses my-stuff {
>>>>>          when "specific-param = 'foo'";// 1.0
>>>>> // when "my-rpc/specific-param = 'foo'" // 1.1
>>>>>
>>>> This is not correct.  If a relative path is used, it would be the same
>>>> in 1.0 and 1.1.
>>>>
>>> I disagree due to current text:
>>>
>>>    o  data node: A node in the schema tree that can be instantiated in a
>>>       data tree.  One of container, leaf, leaf-list, list, anydata, and
>>>       anyxml.
>>>
>>>    o  If the XPath expression is defined in a substatement to an
>>>       "output" statement in an "rpc" or "action" statement, the
>>>       accessible tree is the RPC or action operation instance, all state
>>>       data in the server, and the running configuration datastore.  The
>>>       root node has top-level data nodes in all modules as children.
>>>       Additionally, for an RPC, the root node also has the node
>>>       representing the RPC operation being defined as a child.  The node
>>>       representing the operation being defined has the operation's
>>>       output parameters as children.
>>>
>>>    o  If the "when" statement is a child of a "uses", "choice", or
>>>       "case" statement, then the context node is the closest ancestor
>>>       node to the "uses", "choice", or "case" node that is also a data
>>>       node.  If no such node exists, the context node is the root node.
>>>       The accessible tree is tentatively altered during the processing
>>>       of the XPath expression by removing all instances (if any) of the
>>>       nodes added by the "uses", "choice", or "case" statement.
>>>
>>>
>>> It clearly says that the context node is the root node ("/"), not the
>>> node representing the RPC ("/my-rpc"), which is a child to root node. The
>>> "root node" aka "document root" can only mean a single thing XPath
>>> terminology.
>>>
>> RFC 6020 clearly says that the tree is the rpc reply instance document,
>> so it is a different document whose root node coincides with .
>> The problem of 6020bis is that we need a definition that's independent of
>> XML, and that's not so easy, but I agree with Martin that nothing should
>> change for relative paths.
>>
>
> I'm not against the new accessible tree. That nothing should change for
> relative paths is a given, IMO. So what about absolute location paths?
>
> The previous accessible tree for a "when" expression under "output" was:
>
> 
>   +- x:bar
>
> and now it is:
>
> 
>   +- x:foo
>     +- x:bar
>
> The absolute path to "x:bar" was:
>
> /x:bar
>
> and is now:
>
> /x:foo/x:bar
>
> and this needs to be taken into account for at least relative paths to
> stay the same. Again, the root node is "/" in any case. So the context node
> needs to be set explicitly "/x:foo" for this corner case. I dare say it is
> not even a corner case. There is a similar YANG pattern to my "my-rpc"
> example in ietf-netconf-notifications for a "notification".
>
>

I am strongly opposed to changing the way when-stmt works,
and against expanding the XPath context for RPC and notifications.
You are demonstrating the types of complicated hacks required to
implement YANG 1.1.


Jernej
>
>
>> Lada
>>
>> Jernej
>>>
>>> If an absolute path is used, it would be:
>>>>
>>>>     when "/nc:rpc-reply/x:specific-param = 'foo'"; // 1.0
>>>>     when "/x:my-rpc/x:specific-param = 'foo'";     // 1.1
>>>>
>>>>
>>>> I wonder if any implementation of 1.0 supports this absolute form.
>>>>
>>>>
>>>> /martin
>>>>
>>>>
>>>>        }
>>>>>        leaf specific-param {
>>>>>          type string;
>>>>>        }
>>>>>      }
>>>>>    }
>>>>>
>>>>> Jernej
>>>>>
>>>>> /martin
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks, Lada
>>>>>>>
>>>>>>> Martin Bjorklund  writes:
>>>>>>>
>>>>>>> Ladislav Lhotka  wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Y02-01 allows "must" as a substatement of "input", "output" and
>>>>>>>>> "notification" but for these cases the specification of the context
>>>>>>>>> node in sec. 7.5.3 doesn't work.
>>>>>>>>>
>>>>>>>>>      o  The context node is the node in the accessible tree for
>>>>>>>>> which the
>>>>>>>>>         "must" statement is defined.
>>>>>>>>>
>>>>>>>> You are right.  But note how the accessible tree is defined.  There
>>>>>>>> is
>>>>>>>> a node for the operation / notification.  This node should be the
>>>>>>>> context node:
>>>>>>>>
>>>>>>>>      o  If the "must" statement is a substatement of a
>>>>>>>> "notification"
>>>>>>>>         statement, the context node is the node representing the
>>>>>>>>         notification in the accessible tree.
>>>>>>>>
>>>>>>>>      o  If the "must" statement is a substatement of a "input"
>>>>>>>>         statement, the context node is the node representing the
>>>>>>>>         operation in the accessible tree.
>>>>>>>>
>>>>>>>>      o  If the "must" statement is a substatement of a "output"
>>>>>>>>         statement, the context node is the node representing the
>>>>>>>>         operation in the accessible tree.
>>>>>>>>
>>>>>>>>
>>>>>>>> /martin
>>>>>>>>
>>>>>>> --
>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>
>>>>>>> _______________________________________________
>>>>>> 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, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>> _______________________________________________
>> 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
>

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




On Wed, Dec 16, 2015 at 7:17 AM, Jernej Tuljak <jernejt@mg-soft.si> wrote:
Ladislav Lhotka je 16=
.12.2015 ob 15:10 napisal:



On 16 Dec 2015, at 14:08, Jernej Tuljak <jernejt@mg-soft.si> wrote:



Martin Bjorklund je 16.12.2015 ob 13:48 napisal:



Jernej Tuljak <j=
ernejt@mg-soft.si> wrote:



Martin Bjorklund je 25.11.2015 ob 11:16 napisal:



Ladislav Lhotka <lhot=
ka@nic.cz> wrote:



Hi,



I'd like to resolve this issue. Here is a complete example (valid, I
believe):



module context {

=C2=A0 =C2=A0 namespace "http://example.com/context";

=C2=A0 =C2=A0 prefix ctx;



=C2=A0 =C2=A0 leaf foo {

=C2=A0 =C2=A0 =C2=A0 config false;

=C2=A0 =C2=A0 =C2=A0 type uint32;

=C2=A0 =C2=A0 }

=C2=A0 =C2=A0 rpc oper {

=C2=A0 =C2=A0 =C2=A0 output {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 must "/foo mod foo =3D 0";

=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf foo {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type uint32;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 }

}



1. What does the accessible tree look like?



Note that the anser to this depends on the outcomne of Y04.=C2=A0 Andy has<=
br>
strong objections to Y04-02, and proposed Y04-04 instead.



Assuming Y04-02, and assuming /foo has the value 20 and the oper rpc's<=
br>
result has foo =3D 10, the accessible tree would look like this:



=C2=A0 =C2=A0 =C2=A0<root>

=C2=A0 =C2=A0 =C2=A0 =C2=A0+-- oper

=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0+-- foo =3D 10

=C2=A0 =C2=A0 =C2=A0 =C2=A0+-- foo =3D 20





(If we instead move back to Y04-04, the accessible tree would be:



=C2=A0 =C2=A0 =C2=A0<root>

=C2=A0 =C2=A0 =C2=A0 =C2=A0+-- oper

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-- foo =3D 10



)





2. What is the context node for the "must" expression?



=C2=A0 =C2=A0/oper



This change to the accessible tree (1.0 --> 1.1) may break some

existing "when" XPath expressions (those under "output"=
 statement).



Maybe.=C2=A0 The old text said:



=C2=A0 =C2=A0 o=C2=A0 If the context node represents RPC output parameters,=
 the tree is

=C2=A0 =C2=A0 =C2=A0 =C2=A0the RPC reply instance document.



So this probably meant that for this definition:



=C2=A0 =C2=A0module ex {

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

=C2=A0 =C2=A0 =C2=A0prefix x;

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

=C2=A0 =C2=A0 =C2=A0rpc foo {

=C2=A0 =C2=A0 =C2=A0 =C2=A0output {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf bar { ... }

=C2=A0 =C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0}



The accessile tree was:



=C2=A0 =C2=A0 nc:rpc-reply

=C2=A0 =C2=A0 =C2=A0 +-- x:bar



This is very NETCONF-specifc.=C2=A0 With 1.1, the tree would be:



=C2=A0 =C2=A0 x:foo

=C2=A0 =C2=A0 =C2=A0 +-- x:bar



which is protocol-neutral.





Is

this compatible with 1.1 charter - "All compliant YANG 1.0 modules

must be accepted as compliant YANG 1.1 modules"?



=C2=A0 =C2=A0rpc my-rpc {

=C2=A0 =C2=A0 =C2=A0output {

=C2=A0 =C2=A0 =C2=A0 =C2=A0uses my-stuff {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0when "specific-param =3D 'foo=
9;";// 1.0

// when "my-rpc/specific-param =3D 'foo'" // 1.1



This is not correct.=C2=A0 If a relative path is used, it would be the same=


in 1.0 and 1.1.



I disagree due to current text:



=C2=A0 =C2=A0o=C2=A0 data node: A node in the schema tree that can be insta=
ntiated in a

=C2=A0 =C2=A0 =C2=A0 data tree.=C2=A0 One of container, leaf, leaf-list, li=
st, anydata, and

=C2=A0 =C2=A0 =C2=A0 anyxml.



=C2=A0 =C2=A0o=C2=A0 If the XPath expression is defined in a substatement t=
o an

=C2=A0 =C2=A0 =C2=A0 "output" statement in an "rpc" or =
"action" statement, the

=C2=A0 =C2=A0 =C2=A0 accessible tree is the RPC or action operation instanc=
e, all state

=C2=A0 =C2=A0 =C2=A0 data in the server, and the running configuration data=
store.=C2=A0 The

=C2=A0 =C2=A0 =C2=A0 root node has top-level data nodes in all modules as c=
hildren.

=C2=A0 =C2=A0 =C2=A0 Additionally, for an RPC, the root node also has the n=
ode

=C2=A0 =C2=A0 =C2=A0 representing the RPC operation being defined as a chil=
d.=C2=A0 The node

=C2=A0 =C2=A0 =C2=A0 representing the operation being defined has the opera=
tion's

=C2=A0 =C2=A0 =C2=A0 output parameters as children.



=C2=A0 =C2=A0o=C2=A0 If the "when" statement is a child of a &quo=
t;uses", "choice", or

=C2=A0 =C2=A0 =C2=A0 "case" statement, then the context node is t=
he closest ancestor

=C2=A0 =C2=A0 =C2=A0 node to the "uses", "choice", or &=
quot;case" node that is also a data

=C2=A0 =C2=A0 =C2=A0 node.=C2=A0 If no such node exists, the context node i=
s the root node.

=C2=A0 =C2=A0 =C2=A0 The accessible tree is tentatively altered during the =
processing

=C2=A0 =C2=A0 =C2=A0 of the XPath expression by removing all instances (if =
any) of the

=C2=A0 =C2=A0 =C2=A0 nodes added by the "uses", "choice"=
;, or "case" statement.





It clearly says that the context node is the root node ("/"), not=
 the node representing the RPC ("/my-rpc"), which is a child to r=
oot node. The "root node" aka "document root" can only =
mean a single thing XPath terminology.



RFC 6020 clearly says that the tree is the rpc reply instance document, so =
it is a different document whose root node coincides with <rpc-reply>=
. The problem of 6020bis is that we need a definition that's independen=
t of XML, and that's not so easy, but I agree with Martin that nothing =
should change for relative paths.





I'm not against the new accessible tree. That nothing should change for=
 relative paths is a given, IMO. So what about absolute location paths?



The previous accessible tree for a "when" expression under "=
output" was:



<root>

=C2=A0 +- x:bar



and now it is:



<root>

=C2=A0 +- x:foo

=C2=A0 =C2=A0 +- x:bar



The absolute path to "x:bar" was:



/x:bar



and is now:



/x:foo/x:bar



and this needs to be taken into account for at least relative paths to stay=
 the same. Again, the root node is "/" in any case. So the contex=
t node needs to be set explicitly "/x:foo" for this corner case. =
I dare say it is not even a corner case. There is a similar YANG pattern to=
 my "my-rpc" example in ietf-netconf-notifications for a "no=
tification".




I am strongly opposed t=
o changing the way when-stmt works,
and against expanding the XPa=
th context for RPC and notifications.
You are demonstrating the t=
ypes of complicated hacks required to
implement YANG 1.1.



Jernej







Lada





Jernej





If an absolute path is used, it would be:



=C2=A0 =C2=A0 when "/nc:rpc-reply/x:specific-param =3D 'foo'&q=
uot;; // 1.0

=C2=A0 =C2=A0 when "/x:my-rpc/x:specific-param =3D 'foo'"=
;=C2=A0 =C2=A0 =C2=A0// 1.1





I wonder if any implementation of 1.0 supports this absolute form.





/martin







=C2=A0 =C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf specific-param {

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type string;

=C2=A0 =C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0}

=C2=A0 =C2=A0}



Jernej





/martin









Thanks, Lada



Martin Bjorklund <mb=
j@tail-f.com> writes:





Ladislav Lhotka <lhot=
ka@nic.cz> wrote:



Hi,



Y02-01 allows "must" as a substatement of "input", &quo=
t;output" and

"notification" but for these cases the specification of the conte=
xt

node in sec. 7.5.3 doesn't work.



=C2=A0 =C2=A0 =C2=A0o=C2=A0 The context node is the node in the accessible =
tree for which the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "must" statement is defined.



You are right.=C2=A0 But note how the accessible tree is defined.=C2=A0 The=
re is

a node for the operation / notification.=C2=A0 This node should be the

context node:



=C2=A0 =C2=A0 =C2=A0o=C2=A0 If the "must" statement is a substate=
ment of a "notification"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 statement, the context node is the node represe=
nting the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 notification in the accessible tree.



=C2=A0 =C2=A0 =C2=A0o=C2=A0 If the "must" statement is a substate=
ment of a "input"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 statement, the context node is the node represe=
nting the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 operation in the accessible tree.



=C2=A0 =C2=A0 =C2=A0o=C2=A0 If the "must" statement is a substate=
ment of a "output"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 statement, the context node is the node represe=
nting the

=C2=A0 =C2=A0 =C2=A0 =C2=A0 operation in the accessible tree.





/martin



-- 

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C





_______________________________________________

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, CZ.NIC Labs

PGP Key ID: E74E8C0C









_______________________________________________

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





--001a11402600f5c0a30527060af7--


From nobody Wed Dec 16 08:12:12 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930361A1A86 for ; Wed, 16 Dec 2015 08:12:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 ffj0B0iQ4i0f for ; Wed, 16 Dec 2015 08:12:04 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED101A1A7E for ; Wed, 16 Dec 2015 08:11:17 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:f1df:ae71:a097:15dc] (unknown [IPv6:2001:718:1a02:1:f1df:ae71:a097:15dc]) by mail.nic.cz (Postfix) with ESMTPSA id C5E161810F1; Wed, 16 Dec 2015 17:11:15 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450282275; bh=2+TZO2BH+j+hLgDRV6mH/07Z5K0lDWfwDbenvsS/QH0=; h=From:Date:To; b=PnuYviSQV/AI5MK4+A54CmzwylwD3XA1QVZIc9v58362tL+j5cgsORFm3gEHwPfqH mqerJ/5NxDJjzsu+bVL2yE51yvxOiWLH4EGZzeonzitnXJJzQl42ES+j8hG0wnyBpa YAMP6PHPG5l+NG2kyoiaaLaqb5n66GJL530hlzl4=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <56718098.90703@mg-soft.si>
Date: Wed, 16 Dec 2015 17:11:16 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <21ED1E85-81D7-49A5-B857-76D127FACB92@nic.cz>
References:  <20151125.111622.1788981016001119642.mbj@tail-f.com> <56715ABC.1070209@mg-soft.si> <20151216.134855.549606106792110111.mbj@tail-f.com> <56716238.2030100@mg-soft.si> <960262F1-65C6-4091-A95C-38C1FCD8256A@nic.cz> <56718098.90703@mg-soft.si>
To: Jernej Tuljak 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y02: context node
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 16:12:10 -0000

> On 16 Dec 2015, at 16:17, Jernej Tuljak  wrote:
>=20
> Ladislav Lhotka je 16.12.2015 ob 15:10 napisal:
>>> On 16 Dec 2015, at 14:08, Jernej Tuljak  wrote:
>>>=20
>>> Martin Bjorklund je 16.12.2015 ob 13:48 napisal:
>>>> Jernej Tuljak  wrote:
>>>>> Martin Bjorklund je 25.11.2015 ob 11:16 napisal:
>>>>>> Ladislav Lhotka  wrote:
>>>>>>> Hi,
>>>>>>>=20
>>>>>>> I'd like to resolve this issue. Here is a complete example =
(valid, I
>>>>>>> believe):
>>>>>>>=20
>>>>>>> module context {
>>>>>>>    namespace "http://example.com/context";
>>>>>>>    prefix ctx;
>>>>>>>=20
>>>>>>>    leaf foo {
>>>>>>>      config false;
>>>>>>>      type uint32;
>>>>>>>    }
>>>>>>>    rpc oper {
>>>>>>>      output {
>>>>>>>        must "/foo mod foo =3D 0";
>>>>>>>        leaf foo {
>>>>>>>          type uint32;
>>>>>>>        }
>>>>>>>      }
>>>>>>>    }
>>>>>>> }
>>>>>>>=20
>>>>>>> 1. What does the accessible tree look like?
>>>>>> Note that the anser to this depends on the outcomne of Y04.  Andy =
has
>>>>>> strong objections to Y04-02, and proposed Y04-04 instead.
>>>>>>=20
>>>>>> Assuming Y04-02, and assuming /foo has the value 20 and the oper =
rpc's
>>>>>> result has foo =3D 10, the accessible tree would look like this:
>>>>>>=20
>>>>>>     
>>>>>>       +-- oper
>>>>>>       |   +-- foo =3D 10
>>>>>>       +-- foo =3D 20
>>>>>>=20
>>>>>>=20
>>>>>> (If we instead move back to Y04-04, the accessible tree would be:
>>>>>>=20
>>>>>>     
>>>>>>       +-- oper
>>>>>>           +-- foo =3D 10
>>>>>>=20
>>>>>> )
>>>>>>=20
>>>>>>> 2. What is the context node for the "must" expression?
>>>>>>   /oper
>>>>> This change to the accessible tree (1.0 --> 1.1) may break some
>>>>> existing "when" XPath expressions (those under "output" =
statement).
>>>> Maybe.  The old text said:
>>>>=20
>>>>    o  If the context node represents RPC output parameters, the =
tree is
>>>>       the RPC reply instance document.
>>>>=20
>>>> So this probably meant that for this definition:
>>>>=20
>>>>   module ex {
>>>>     ...
>>>>     prefix x;
>>>>     ...
>>>>     rpc foo {
>>>>       output {
>>>>         leaf bar { ... }
>>>>       }
>>>>     }
>>>>   }
>>>>=20
>>>> The accessile tree was:
>>>>=20
>>>>    nc:rpc-reply
>>>>      +-- x:bar
>>>>=20
>>>> This is very NETCONF-specifc.  With 1.1, the tree would be:
>>>>=20
>>>>    x:foo
>>>>      +-- x:bar
>>>>=20
>>>> which is protocol-neutral.
>>>>=20
>>>>> Is
>>>>> this compatible with 1.1 charter - "All compliant YANG 1.0 modules
>>>>> must be accepted as compliant YANG 1.1 modules"?
>>>>>=20
>>>>>   rpc my-rpc {
>>>>>     output {
>>>>>       uses my-stuff {
>>>>>         when "specific-param =3D 'foo'";// 1.0
>>>>> // when "my-rpc/specific-param =3D 'foo'" // 1.1
>>>> This is not correct.  If a relative path is used, it would be the =
same
>>>> in 1.0 and 1.1.
>>> I disagree due to current text:
>>>=20
>>>   o  data node: A node in the schema tree that can be instantiated =
in a
>>>      data tree.  One of container, leaf, leaf-list, list, anydata, =
and
>>>      anyxml.
>>>=20
>>>   o  If the XPath expression is defined in a substatement to an
>>>      "output" statement in an "rpc" or "action" statement, the
>>>      accessible tree is the RPC or action operation instance, all =
state
>>>      data in the server, and the running configuration datastore.  =
The
>>>      root node has top-level data nodes in all modules as children.
>>>      Additionally, for an RPC, the root node also has the node
>>>      representing the RPC operation being defined as a child.  The =
node
>>>      representing the operation being defined has the operation's
>>>      output parameters as children.
>>>=20
>>>   o  If the "when" statement is a child of a "uses", "choice", or
>>>      "case" statement, then the context node is the closest ancestor
>>>      node to the "uses", "choice", or "case" node that is also a =
data
>>>      node.  If no such node exists, the context node is the root =
node.
>>>      The accessible tree is tentatively altered during the =
processing
>>>      of the XPath expression by removing all instances (if any) of =
the
>>>      nodes added by the "uses", "choice", or "case" statement.
>>>=20
>>>=20
>>> It clearly says that the context node is the root node ("/"), not =
the node representing the RPC ("/my-rpc"), which is a child to root =
node. The "root node" aka "document root" can only mean a single thing =
XPath terminology.
>> RFC 6020 clearly says that the tree is the rpc reply instance =
document, so it is a different document whose root node coincides with =
. The problem of 6020bis is that we need a definition that's =
independent of XML, and that's not so easy, but I agree with Martin that =
nothing should change for relative paths.
>=20
> I'm not against the new accessible tree. That nothing should change =
for relative paths is a given, IMO. So what about absolute location =
paths?
>=20
> The previous accessible tree for a "when" expression under "output" =
was:
>=20
> 
>  +- x:bar
>=20
> and now it is:
>=20
> 
>  +- x:foo
>    +- x:bar
>=20
> The absolute path to "x:bar" was:
>=20
> /x:bar
>=20
> and is now:
>=20
> /x:foo/x:bar
>=20
> and this needs to be taken into account for at least relative paths to =
stay the same. Again, the root node is "/" in any case. So the context =
node needs to be set explicitly "/x:foo" for this corner case. I dare =
say it is not even a corner case. There is a similar

Yes, that's how I think it should be. It's tricky because x:foo doesn't =
appear in the XML encoding of  - that's what I asked about =
previously in this thread.

Lada

>  YANG pattern to my "my-rpc" example in ietf-netconf-notifications for =
a "notification".
>=20
> Jernej
>=20
>>=20
>> Lada
>>=20
>>> Jernej
>>>=20
>>>> If an absolute path is used, it would be:
>>>>=20
>>>>    when "/nc:rpc-reply/x:specific-param =3D 'foo'"; // 1.0
>>>>    when "/x:my-rpc/x:specific-param =3D 'foo'";     // 1.1
>>>>=20
>>>>=20
>>>> I wonder if any implementation of 1.0 supports this absolute form.
>>>>=20
>>>>=20
>>>> /martin
>>>>=20
>>>>=20
>>>>>       }
>>>>>       leaf specific-param {
>>>>>         type string;
>>>>>       }
>>>>>     }
>>>>>   }
>>>>>=20
>>>>> Jernej
>>>>>=20
>>>>>> /martin
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> Thanks, Lada
>>>>>>>=20
>>>>>>> Martin Bjorklund  writes:
>>>>>>>=20
>>>>>>>> Ladislav Lhotka  wrote:
>>>>>>>>> Hi,
>>>>>>>>>=20
>>>>>>>>> Y02-01 allows "must" as a substatement of "input", "output" =
and
>>>>>>>>> "notification" but for these cases the specification of the =
context
>>>>>>>>> node in sec. 7.5.3 doesn't work.
>>>>>>>>>=20
>>>>>>>>>     o  The context node is the node in the accessible tree for =
which the
>>>>>>>>>        "must" statement is defined.
>>>>>>>> You are right.  But note how the accessible tree is defined.  =
There is
>>>>>>>> a node for the operation / notification.  This node should be =
the
>>>>>>>> context node:
>>>>>>>>=20
>>>>>>>>     o  If the "must" statement is a substatement of a =
"notification"
>>>>>>>>        statement, the context node is the node representing the
>>>>>>>>        notification in the accessible tree.
>>>>>>>>=20
>>>>>>>>     o  If the "must" statement is a substatement of a "input"
>>>>>>>>        statement, the context node is the node representing the
>>>>>>>>        operation in the accessible tree.
>>>>>>>>=20
>>>>>>>>     o  If the "must" statement is a substatement of a "output"
>>>>>>>>        statement, the context node is the node representing the
>>>>>>>>        operation in the accessible tree.
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> /martin
>>>>>>> --=20
>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>=20
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>=20
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed Dec 16 08:17:41 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA91E1A0856 for ; Wed, 16 Dec 2015 08:17:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 ko6e7JPeFKsr for ; Wed, 16 Dec 2015 08:17:38 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DCCD91A00E2 for ; Wed, 16 Dec 2015 08:17:30 -0800 (PST)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 6D3551AE03CD; Wed, 16 Dec 2015 17:17:28 +0100 (CET)
Date: Wed, 16 Dec 2015 17:18:29 +0100 (CET)
Message-Id: <20151216.171829.2198076201177316023.mbj@tail-f.com>
To: jernejt@mg-soft.si
From: Martin Bjorklund 
In-Reply-To: <56718098.90703@mg-soft.si>
References: <56716238.2030100@mg-soft.si> <960262F1-65C6-4091-A95C-38C1FCD8256A@nic.cz> <56718098.90703@mg-soft.si>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y02: context node
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 16:17:40 -0000

Jernej Tuljak  wrote:
> Ladislav Lhotka je 16.12.2015 ob 15:10 napisal:
> >> On 16 Dec 2015, at 14:08, Jernej Tuljak  wrote:
> >>
> >> Martin Bjorklund je 16.12.2015 ob 13:48 napisal:
> >>> Jernej Tuljak  wrote:
> >>>> Martin Bjorklund je 25.11.2015 ob 11:16 napisal:
> >>>>> Ladislav Lhotka  wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> I'd like to resolve this issue. Here is a complete example (valid, I
> >>>>>> believe):
> >>>>>>
> >>>>>> module context {
> >>>>>>     namespace "http://example.com/context";
> >>>>>>     prefix ctx;
> >>>>>>
> >>>>>>     leaf foo {
> >>>>>>       config false;
> >>>>>>       type uint32;
> >>>>>>     }
> >>>>>>     rpc oper {
> >>>>>>       output {
> >>>>>>         must "/foo mod foo = 0";
> >>>>>>         leaf foo {
> >>>>>>           type uint32;
> >>>>>>         }
> >>>>>>       }
> >>>>>>     }
> >>>>>> }
> >>>>>>
> >>>>>> 1. What does the accessible tree look like?
> >>>>> Note that the anser to this depends on the outcomne of Y04.  Andy has
> >>>>> strong objections to Y04-02, and proposed Y04-04 instead.
> >>>>>
> >>>>> Assuming Y04-02, and assuming /foo has the value 20 and the oper rpc's
> >>>>> result has foo = 10, the accessible tree would look like this:
> >>>>>
> >>>>>      
> >>>>>        +-- oper
> >>>>>        |   +-- foo = 10
> >>>>>        +-- foo = 20
> >>>>>
> >>>>>
> >>>>> (If we instead move back to Y04-04, the accessible tree would be:
> >>>>>
> >>>>>      
> >>>>>        +-- oper
> >>>>>            +-- foo = 10
> >>>>>
> >>>>> )
> >>>>>
> >>>>>> 2. What is the context node for the "must" expression?
> >>>>>    /oper
> >>>> This change to the accessible tree (1.0 --> 1.1) may break some
> >>>> existing "when" XPath expressions (those under "output" statement).
> >>> Maybe.  The old text said:
> >>>
> >>>     o  If the context node represents RPC output parameters, the tree is
> >>>        the RPC reply instance document.
> >>>
> >>> So this probably meant that for this definition:
> >>>
> >>>    module ex {
> >>>      ...
> >>>      prefix x;
> >>>      ...
> >>>      rpc foo {
> >>>        output {
> >>>          leaf bar { ... }
> >>>        }
> >>>      }
> >>>    }
> >>>
> >>> The accessile tree was:
> >>>
> >>>     nc:rpc-reply
> >>>       +-- x:bar
> >>>
> >>> This is very NETCONF-specifc.  With 1.1, the tree would be:
> >>>
> >>>     x:foo
> >>>       +-- x:bar
> >>>
> >>> which is protocol-neutral.
> >>>
> >>>> Is
> >>>> this compatible with 1.1 charter - "All compliant YANG 1.0 modules
> >>>> must be accepted as compliant YANG 1.1 modules"?
> >>>>
> >>>>    rpc my-rpc {
> >>>>      output {
> >>>>        uses my-stuff {
> >>>>          when "specific-param = 'foo'";// 1.0
> >>>> // when "my-rpc/specific-param = 'foo'" // 1.1
> >>> This is not correct.  If a relative path is used, it would be the same
> >>> in 1.0 and 1.1.
> >> I disagree due to current text:
> >>
> >>    o  data node: A node in the schema tree that can be instantiated in a
> >>       data tree.  One of container, leaf, leaf-list, list, anydata, and
> >>       anyxml.
> >>
> >>    o  If the XPath expression is defined in a substatement to an
> >>       "output" statement in an "rpc" or "action" statement, the
> >>       accessible tree is the RPC or action operation instance, all state
> >>       data in the server, and the running configuration datastore.  The
> >>       root node has top-level data nodes in all modules as children.
> >>       Additionally, for an RPC, the root node also has the node
> >>       representing the RPC operation being defined as a child.  The node
> >>       representing the operation being defined has the operation's
> >>       output parameters as children.
> >>
> >>    o  If the "when" statement is a child of a "uses", "choice", or
> >>       "case" statement, then the context node is the closest ancestor
> >>       node to the "uses", "choice", or "case" node that is also a data
> >>       node.  If no such node exists, the context node is the root node.
> >>       The accessible tree is tentatively altered during the processing
> >>       of the XPath expression by removing all instances (if any) of the
> >>       nodes added by the "uses", "choice", or "case" statement.
> >>
> >>
> >> It clearly says that the context node is the root node ("/"), not the
> >> node representing the RPC ("/my-rpc"), which is a child to root
> >> node. The "root node" aka "document root" can only mean a single thing
> >> XPath terminology.
> > RFC 6020 clearly says that the tree is the rpc reply instance
> > document, so it is a different document whose root node coincides with
> > . The problem of 6020bis is that we need a definition
> > that's independent of XML, and that's not so easy, but I agree with
> > Martin that nothing should change for relative paths.
> 
> I'm not against the new accessible tree. That nothing should change
> for relative paths is a given, IMO. So what about absolute location
> paths?
> 
> The previous accessible tree for a "when" expression under "output"
> was:
> 
> 
>   +- x:bar

No it was:

  
    +-- nc:rpc-reply
      +- x:bar

> and now it is:
> 
> 
>   +- x:foo
>     +- x:bar
> 
> The absolute path to "x:bar" was:
> 
> /x:bar

/nc:rpc-reply/x:bar

> and is now:
> 
> /x:foo/x:bar
> 
> and this needs to be taken into account for at least relative paths to
> stay the same. Again, the root node is "/" in any case. So the context
> node needs to be set explicitly "/x:foo" for this corner case. I dare
> say it is not even a corner case. There is a similar YANG pattern to
> my "my-rpc" example in ietf-netconf-notifications for a
> "notification".

I think what needs to be done is to clarify that the context node for
when/must in input/output or uses in input/output is the node
representing the rpc.  Note that this is unspecified in 6020.


/martin



> 
> Jernej
> 
> >
> > Lada
> >
> >> Jernej
> >>
> >>> If an absolute path is used, it would be:
> >>>
> >>>     when "/nc:rpc-reply/x:specific-param = 'foo'"; // 1.0
> >>>     when "/x:my-rpc/x:specific-param = 'foo'";     // 1.1
> >>>
> >>>
> >>> I wonder if any implementation of 1.0 supports this absolute form.
> >>>
> >>>
> >>> /martin
> >>>
> >>>
> >>>>        }
> >>>>        leaf specific-param {
> >>>>          type string;
> >>>>        }
> >>>>      }
> >>>>    }
> >>>>
> >>>> Jernej
> >>>>
> >>>>> /martin
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Thanks, Lada
> >>>>>>
> >>>>>> Martin Bjorklund  writes:
> >>>>>>
> >>>>>>> Ladislav Lhotka  wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> Y02-01 allows "must" as a substatement of "input", "output" and
> >>>>>>>> "notification" but for these cases the specification of the context
> >>>>>>>> node in sec. 7.5.3 doesn't work.
> >>>>>>>>
> >>>>>>>>      o The context node is the node in the accessible tree for which
> >>>>>>>>      the
> >>>>>>>>         "must" statement is defined.
> >>>>>>> You are right.  But note how the accessible tree is defined.  There is
> >>>>>>> a node for the operation / notification.  This node should be the
> >>>>>>> context node:
> >>>>>>>
> >>>>>>>      o  If the "must" statement is a substatement of a "notification"
> >>>>>>>         statement, the context node is the node representing the
> >>>>>>>         notification in the accessible tree.
> >>>>>>>
> >>>>>>>      o  If the "must" statement is a substatement of a "input"
> >>>>>>>         statement, the context node is the node representing the
> >>>>>>>         operation in the accessible tree.
> >>>>>>>
> >>>>>>>      o  If the "must" statement is a substatement of a "output"
> >>>>>>>         statement, the context node is the node representing the
> >>>>>>>         operation in the accessible tree.
> >>>>>>>
> >>>>>>>
> >>>>>>> /martin
> >>>>>> -- 
> >>>>>> Ladislav Lhotka, CZ.NIC Labs
> >>>>>> PGP Key ID: E74E8C0C
> >>>>>>
> >>>>> _______________________________________________
> >>>>> 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, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> > _______________________________________________
> > 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 Dec 16 08:48:32 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DF41A1B22 for ; Wed, 16 Dec 2015 08:48:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 GobNCZbrIQys for ; Wed, 16 Dec 2015 08:48:29 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id B1E411A1B2E for ; Wed, 16 Dec 2015 08:48:15 -0800 (PST)
Received: from stubbs.local.chopps.org (75-128-113-61.dhcp.aldl.mi.charter.com [75.128.113.61]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id DCE4261D76; Wed, 16 Dec 2015 16:48:14 +0000 (UTC)
References:   
User-agent: mu4e 0.9.15; emacs 24.5.1
From: Christian Hopps 
To: Anees Shaikh 
In-reply-to: 
Date: Wed, 16 Dec 2015 11:48:12 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Guidance on list vs. container of list
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 16:48:31 -0000

--=-=-=
Content-Type: text/plain; format=flowed


Anees Shaikh  writes:

> hi Chris, in OpenConfig models we use enclosing containers on 
> lists based on feedback from some implementors who claimed that 
> it made it more efficient to, for example, retrieve the entire 
> list (ask for the container), retrieve the keys in the list (ask 
> for the list node), or retrieve a particular element of the list 
> (specify the key). 

But, I don't think asking for the list node returns only keys, I 
think it returns the entire content of the node, i.e., it's 
equivalent to asking for the out container if that container only 
contains a single list (the model in question here). 

Thanks,
Chris.

> Aside from some stuttering in the paths (which can be a little 
> annoying but I don't expect to write the config instances by 
> hand), there didn't seem to be a major downside.  So we try to 
> be consistent across the models with this approach.  After 
> getting some more experience with the implementations, we might 
> revisit.
>
> thanks.  -- Anees
>
> On Mon, Dec 14, 2015 at 6:30 PM, Andy Bierman 
>  wrote:
>
>> Hi,
>>
>> Use of NP-containers are subjective, based on how you want to 
>> organize your data.  The extra layer of containment may be a 
>> waste, but it sometimes has a purpose
>>
>>   - 2 or more sibling lists with lots of entries can be mixed 
>>   in JSON, 
>>     so putting each list in its container prevents that. 
>>  - There is no standard way to 'delete-all' in NETCONF or 
>>  RESTCONF 
>>     but a 'replace' on the parent container can be used for 
>>     this purpose.  (container of list or leaf-list) 
>>  - container servers as a conceptual 'root' for external 
>>  augments
>>
>> Andy
>>
>>
>> On Mon, Dec 14, 2015 at 5:56 PM, Christian Hopps 
>> 
>> wrote:
>>
>>>
>>> Some models seem to place a single list of things inside a 
>>> container also named after the items in the list, e.g.,
>>>
>>> +--ro modulename 
>>>   +--rw ribs 
>>>      +--rw rib* [name]         +--rw name 
>>> I don't see the purpose of these containers. It seems to me 
>>> that one can model and query the exact same data without the 
>>> outer container. That is,
>>>
>>> +--ro modulename 
>>>   +--rw rib* [name]      +--rw name 
>>> Is there something useful about these containers that I've 
>>> missed, as it's a fairly common pattern in the models I've 
>>> been looking at.   Example comparisons below..  Thanks, Chris.
>>>
>>>
>>> w/ container: 
>>>                   
>>>    foo 
>>>            bar         ... 
>>>   w/o container: 
>>>     
>>>              foo        
>>> bar       ...     Likewise if 
>>> you want to fetch all ribs you can either way:
>>>
>>>     
>>>       
>>>         
>>>       
>>>     
>>> or
>>>
>>>     
>>>       
>>>         
>>>       
>>>     
>>> Or a particular rib
>>>
>>>     
>>>       
>>>                              foo 
>>>                   
>>>       
>>>     
>>> or
>>>
>>>     
>>>                        foo 
>>>         
>>>       
>>>     
>>> Using xpath:
>>>
>>>    /modulename/ribs/rib[name='foo'] 
>>> or
>>>
>>>    /modulename/rib[name='foo']
>>>
>>> _______________________________________________ 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
>>
>>


--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWcZXNAAoJEC4dgw7XuDAlm9kQAI3RH997wi7qCyq5LqgpzNQy
lyLZgY6/eBtsqyfxG/wxHF6CNMG0kR8+VKQIsCux0nUW2Yu+hw6u4L3LylKEglvc
uHO1K2aja8zWrwRi0ePl290muPw95Bnty0eCwzWfi+hQWx7O21FFFLdH6x6szD3U
YJbGvxVx/WSR8+iMh/fPyBHqS6QZYxyiyS2E0lx+3YsYRYL4OqLkXD0bLmk/1WnR
VQypoCdIzK+jXh5Gry6z4N+CZ1Tfk2wI754r5UG6CeK+Ok2HrA5cnpd0IfdUTcIS
1dHWliBCS33pGy8RF2Es8FT21KHaZ0QG1dQ8+eXiIDmEC63eb5W5i6m+gHPxJ/d/
I5sVe5bPFRupn3omMTFZxKU7P7vZGP2KhmUTBnZmFlGXvYh4YxG+DCP51iInUmRE
ciB6iSktCSfjvvYLtG/WJbBqnMANxzChJRJK4TZ4Vp65KMdkDpu8zdi60X56toa9
P06i8tWQlKV7bREGg7Cm+7Q0G96eXiiZMI1a9qEOlwjCUyPQro3ExI28L7PutV3d
NBPkWeEseCfFhfLvSTopLYy9LSG0e+QLah+ETpnFoejWqYkQXLPvQcdqY1zbKLTG
rU9WWTnjOfpPBZeCiU73a6op5iyfQ3D2dcfYjnh6nT8tn2JDFqpk4yWo6TJcQ+Xc
Gi0UVOEIa190+SGLchL4
=25hl
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Wed Dec 16 09:00:41 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829231A1B8F for ; Wed, 16 Dec 2015 09:00:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level: 
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 r8ksT3QqjSOn for ; Wed, 16 Dec 2015 09:00:37 -0800 (PST)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::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 3195F1A6F6B for ; Wed, 16 Dec 2015 09:00:22 -0800 (PST)
Received: by mail-ig0-x22c.google.com with SMTP id mv3so141776594igc.0 for ; Wed, 16 Dec 2015 09:00:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XzVIY2Gkhct/MUKTAftxT7maCKRZ/B8NyL8zgS59QkI=; b=iwQd6XN8zN90ynpyBhmvZ7zOL+uior80Emml4HT0lKezUiawHDTBR0mIzdjn9rarNK ilgVYgA7g+4kx0CF0mPUsovwCNRNlzRPn8V2s7NZHAcnQ5SMfae8zOpbnMOp9LV2ipLO EKOeD5+NZNFYSGALUhyqa6ef6Jp1rkkIKPh5gXsOnUlnKcdB8lXZPnn7A39jPYy9AZqv T0hPAQKN/hPYdlUev7ZK2WenF4pdUp1Yf8qNQscOy9vPul++AFAJqjPoziTLMi7V2pvK rSfNIhVycLjOTE+hi1aTcTICo64MlflFsus1PqEGZ7NH+Bk5hJjjpp6Y1zRa0qlobpec meEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XzVIY2Gkhct/MUKTAftxT7maCKRZ/B8NyL8zgS59QkI=; b=WwtRl7Dsfw9OhkuUfGT7vdKJ6otrolVDtSFQHhOK5WL5Rrpf4hkh34tjbMF0XV7amt 3Osv87peDn3p8mFIvtCCtlVhx+rMrBs2IPhYyuZANwDNtZ6obZhBN4IOg5q303IrzQEY GKeAleZqemIPU2GEvZyESZuYFXw9VAiXvApl+SEYDi04BwLhXaHH9OibrH9HCxct80KS iaDehf9DXVDSE42HM0Kyr6JTssWAlEwGPUcna9UmGS4sWsP50iyuB3GVVKPmw/K7EG6x 4jhTSpJDTkYcnPJcpoRw0j62fqZOHusaIWsMYjOfnxIFfP+xY4Zqjo+IA0Ge8ft+Q65H o08A==
X-Gm-Message-State: ALoCoQlRznHLRVrVzdwxZLYk9LMeX8zN8kHR6yelZoK1rAM/lsADGzmYuRcRrIyrxe60vcgPqY+iOtoMl7WXwt58wkdRaGb5T/O0zmFCbE/xNI7+LMJGAlU=
MIME-Version: 1.0
X-Received: by 10.107.128.10 with SMTP id b10mr13833386iod.87.1450285206034; Wed, 16 Dec 2015 09:00:06 -0800 (PST)
Received: by 10.36.38.133 with HTTP; Wed, 16 Dec 2015 09:00:05 -0800 (PST)
In-Reply-To: 
References:    
Date: Wed, 16 Dec 2015 09:00:05 -0800
Message-ID: 
From: Anees Shaikh 
To: Christian Hopps 
Content-Type: multipart/alternative; boundary=001a113ec22a87b999052706d626
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Guidance on list vs. container of list
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 17:00:39 -0000

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

I'm not suggesting this is necessarily standard behavior :-), but some
major implementations behave this way (it could be useful in some
circumstances) -- on those platforms, the enclosing container makes a
request for the whole list arguably less ambiguous.

thanks.
-- Anees

On Wed, Dec 16, 2015 at 8:48 AM, Christian Hopps  wrote:

>
> Anees Shaikh  writes:
>
> hi Chris, in OpenConfig models we use enclosing containers on lists based
>> on feedback from some implementors who claimed that it made it more
>> efficient to, for example, retrieve the entire list (ask for the
>> container), retrieve the keys in the list (ask for the list node), or
>> retrieve a particular element of the list (specify the key).
>>
>
> But, I don't think asking for the list node returns only keys, I think it
> returns the entire content of the node, i.e., it's equivalent to asking for
> the out container if that container only contains a single list (the model
> in question here).
> Thanks,
> Chris.
>
>
> Aside from some stuttering in the paths (which can be a little annoying
>> but I don't expect to write the config instances by hand), there didn't
>> seem to be a major downside.  So we try to be consistent across the models
>> with this approach.  After getting some more experience with the
>> implementations, we might revisit.
>>
>> thanks.  -- Anees
>>
>> On Mon, Dec 14, 2015 at 6:30 PM, Andy Bierman  wrote:
>>
>> Hi,
>>>
>>> Use of NP-containers are subjective, based on how you want to organize
>>> your data.  The extra layer of containment may be a waste, but it sometimes
>>> has a purpose
>>>
>>>   - 2 or more sibling lists with lots of entries can be mixed   in
>>> JSON,     so putting each list in its container prevents that.  - There is
>>> no standard way to 'delete-all' in NETCONF or  RESTCONF     but a 'replace'
>>> on the parent container can be used for     this purpose.  (container of
>>> list or leaf-list)  - container servers as a conceptual 'root' for
>>> external  augments
>>>
>>> Andy
>>>
>>>
>>> On Mon, Dec 14, 2015 at 5:56 PM, Christian Hopps 
>>> wrote:
>>>
>>>
>>>> Some models seem to place a single list of things inside a container
>>>> also named after the items in the list, e.g.,
>>>>
>>>> +--ro modulename   +--rw ribs      +--rw rib* [name]         +--rw name
>>>> I don't see the purpose of these containers. It seems to me that one can
>>>> model and query the exact same data without the outer container. That is,
>>>>
>>>> +--ro modulename   +--rw rib* [name]      +--rw name Is there something
>>>> useful about these containers that I've missed, as it's a fairly common
>>>> pattern in the models I've been looking at.   Example comparisons below..
>>>> Thanks, Chris.
>>>>
>>>>
>>>> w/ container:                  
>>>> foo            bar         ...
>>>>   w/o container:          
>>>> foo        bar       ...
>>>>  Likewise if you want to fetch all ribs you can either way:
>>>>
>>>>                        
>>>>  or
>>>>
>>>>                        
>>>>  Or a particular rib
>>>>
>>>>                            
>>>> foo                        
>>>>  or
>>>>
>>>>                            foo
>>>>                Using xpath:
>>>>
>>>>    /modulename/ribs/rib[name='foo'] or
>>>>
>>>>    /modulename/rib[name='foo']
>>>>
>>>> _______________________________________________ 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
>>>
>>>
>>>
>

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


I'm not suggesting this is necessarily standard behavi=
or :-), but some major implementations behave this way (it could be useful =
in some circumstances) -- on those platforms, the enclosing container makes=
 a request for the whole list arguably less ambiguous. =C2=A0

thanks.
-- Anees

On Wed, Dec 16, 2015 at 8:48 AM, Christian Hopps <chopp=
s@chopps.org> wrote:


Anees Shaikh <a=
ashaikh@google.com> writes:





hi Chris, in OpenConfig models we use enclosing containers on lists based o=
n feedback from some implementors who claimed that it made it more efficien=
t to, for example, retrieve the entire list (ask for the container), retrie=
ve the keys in the list (ask for the list node), or retrieve a particular e=
lement of the list (specify the key). 





But, I don't think asking for the list node returns only keys, I think =
it returns the entire content of the node, i.e., it's equivalent to ask=
ing for the out container if that container only contains a single list (th=
e model in question here). 

Thanks,

Chris.






Aside from some stuttering in the paths (which can be a little annoying but=
 I don't expect to write the config instances by hand), there didn'=
t seem to be a major downside.=C2=A0 So we try to be consistent across the =
models with this approach.=C2=A0 After getting some more experience with th=
e implementations, we might revisit.



thanks.=C2=A0 -- Anees



On Mon, Dec 14, 2015 at 6:30 PM, Andy Bierman <andy@yumaworks.com> wrote:





Hi,



Use of NP-containers are subjective, based on how you want to organize your=
 data.=C2=A0 The extra layer of containment may be a waste, but it sometime=
s has a purpose



=C2=A0 - 2 or more sibling lists with lots of entries can be mixed=C2=A0 =
=C2=A0in JSON,=C2=A0 =C2=A0 =C2=A0so putting each list in its container pre=
vents that.=C2=A0 - There is no standard way to 'delete-all' in NET=
CONF or=C2=A0 RESTCONF=C2=A0 =C2=A0 =C2=A0but a 'replace' on the pa=
rent container can be used for=C2=A0 =C2=A0 =C2=A0this purpose.=C2=A0 (cont=
ainer of list or leaf-list)=C2=A0 - container servers as a conceptual '=
root' for external=C2=A0 augments



Andy





On Mon, Dec 14, 2015 at 5:56 PM, Christian Hopps <chopps@chopps.org>

wrote:







Some models seem to place a single list of things inside a container also n=
amed after the items in the list, e.g.,



+--ro modulename=C2=A0 =C2=A0+--rw ribs=C2=A0 =C2=A0 =C2=A0 +--rw rib* [nam=
e]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw name I don't see the purpose =
of these containers. It seems to me that one can model and query the exact =
same data without the outer container. That is,



+--ro modulename=C2=A0 =C2=A0+--rw rib* [name]=C2=A0 =C2=A0 =C2=A0 +--rw na=
me Is there something useful about these containers that I've missed, a=
s it's a fairly common pattern in the models I've been looking at.=
=C2=A0 =C2=A0Example comparisons below..=C2=A0 Thanks, Chris.





w/ container:=C2=A0 =C2=A0 <modulename>=C2=A0 =C2=A0 =C2=A0 <ribs&=
gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 <rib>=C2=A0 =C2=A0 <name>foo<=
/name> </rib> <rib>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <na=
me>bar</name>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </rib> ... </rib=
s> </modulename> w/o container:=C2=A0 =C2=A0 <modulename>=C2=
=A0 =C2=A0 =C2=A0 <rib>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>foo<=
;/name>=C2=A0 =C2=A0 =C2=A0 </rib> <rib> <name>bar<=
/name>=C2=A0 =C2=A0 =C2=A0 </rib> ...=C2=A0 =C2=A0 </modulename=
> Likewise if you want to fetch all ribs you can either way:



=C2=A0 =C2=A0<filter>=C2=A0 =C2=A0 =C2=A0 <modulename>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 <ribs/>=C2=A0 =C2=A0 =C2=A0 </modulename>=
=C2=A0 =C2=A0 </filter> or



=C2=A0 =C2=A0<filter>=C2=A0 =C2=A0 =C2=A0 <modulename>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 <rib/>=C2=A0 =C2=A0 =C2=A0 </modulename>=
=C2=A0 =C2=A0 </filter> Or a particular rib



=C2=A0 =C2=A0<filter>=C2=A0 =C2=A0 =C2=A0 <modulename>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 <ribs>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <rib=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>foo</name>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </rib>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
</ribs>=C2=A0 =C2=A0 =C2=A0 </modulename>=C2=A0 =C2=A0 </fil=
ter> or



=C2=A0 =C2=A0<filter>=C2=A0 =C2=A0 =C2=A0 <modulename>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 <rib>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name=
>foo</name>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </rib>=C2=A0 =C2=A0 =
=C2=A0 </modulename>=C2=A0 =C2=A0 </filter> Using xpath:



=C2=A0 =C2=A0/modulename/ribs/rib[name=3D'foo'] or



=C2=A0 =C2=A0/modulename/rib[name=3D'foo']



_______________________________________________ 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













--001a113ec22a87b999052706d626--


From nobody Wed Dec 16 09:05:12 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4442C1A1A90 for ; Wed, 16 Dec 2015 09:05:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 ufT88fUWK11U for ; Wed, 16 Dec 2015 09:05:07 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 881001A1EB7 for ; Wed, 16 Dec 2015 09:04:14 -0800 (PST)
Received: from stubbs.local.chopps.org (75-128-113-61.dhcp.aldl.mi.charter.com [75.128.113.61]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 081C661D76; Wed, 16 Dec 2015 17:04:13 +0000 (UTC)
References:  
User-agent: mu4e 0.9.15; emacs 24.5.1
From: Christian Hopps 
To: Andy Bierman 
In-reply-to: 
Date: Wed, 16 Dec 2015 12:04:12 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Guidance on list vs. container of list
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 17:05:10 -0000

--=-=-=
Content-Type: text/plain; format=flowed


Andy Bierman  writes:

> Hi,
>
> Use of NP-containers are subjective, based on how you want to 
> organize your data.  The extra layer of containment may be a 
> waste, but it sometimes has a purpose
>
>   - 2 or more sibling lists with lots of entries can be mixed in 
>   JSON, 
>     so putting each list in its container prevents that. 
 
Did you mean XML here (Lada indicated it's not the case with 
JSON)? I was curious if mixing like this was allowed in XML case 
(whether items from 2 different lists or even sibling leafs). I 
was hoping that once a list started in the XML all items in the 
list would be present before other items outside the list. If what 
your saying applies to XML then one would have to iterate all 
sibling nodes in the containing node to collect the list. This 
would seem to be the case even with sibling leafs in the model. I 
find this a bit surprising, and would expect bugs in 
implementation if so. :) 
 
>  - container servers as a conceptual 'root' for external 
>  augments 
 
This might be useful in some cases, probably not a reason to 
always include a container wrapper though. 
 
>  - There is no standard way to 'delete-all' in NETCONF or 
>  RESTCONF 
>     but a 'replace' on the parent container can be used for this 
>     purpose.  (container of list or leaf-list) 

This is an interesting use -- using a modeling technique to to get 
around missing functionality in the protocol (hello opstate! :) 

Seriously though, should we consider adding delete-all 
functionality then? 

Thanks, Chris.

> Andy
>
>
> On Mon, Dec 14, 2015 at 5:56 PM, Christian Hopps 
>  wrote:
>
>>
>> Some models seem to place a single list of things inside a 
>> container also named after the items in the list, e.g.,
>>
>> +--ro modulename 
>>   +--rw ribs 
>>      +--rw rib* [name]         +--rw name 
>> I don't see the purpose of these containers. It seems to me 
>> that one can model and query the exact same data without the 
>> outer container. That is,
>>
>> +--ro modulename 
>>   +--rw rib* [name]      +--rw name 
>> Is there something useful about these containers that I've 
>> missed, as it's a fairly common pattern in the models I've been 
>> looking at.   Example comparisons below..  Thanks, Chris.
>>
>>
>> w/ container: 
>>                   
>>    foo 
>>            bar         ... 
>>   w/o container: 
>>     
>>              foo        
>> bar       ...     Likewise if 
>> you want to fetch all ribs you can either way:
>>
>>     
>>       
>>         
>>       
>>     
>> or
>>
>>     
>>       
>>         
>>       
>>     
>> Or a particular rib
>>
>>     
>>       
>>                              foo 
>>                   
>>       
>>     
>> or
>>
>>     
>>                        foo 
>>         
>>       
>>     
>> Using xpath:
>>
>>    /modulename/ribs/rib[name='foo'] 
>> or
>>
>>    /modulename/rib[name='foo']
>>
>> _______________________________________________ netmod mailing 
>> list netmod@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>


--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWcZmMAAoJEC4dgw7XuDAlnMcP/iAKy9tdOiupbp6yf88OL7Em
qHBkHI7Hqj4vjVRaD96sRg+x/lrRtF03RhDYnOU8mq4CmIsKyLVslLaXDjaK67Gk
Z4y41ZFC5onrJzNQyNHDifupLFTX/QrRq51bCqt43S3PviaLsb9HjpB9a4exz6qq
tzAs+TQqkQbLfSAveREBGw6agYyIzi2ad8mYJbdhhiHVgCZu37LAkM6kHZSnfbqi
9JIzHY3YyIdLq98V0HlmH4X4s5WRfPQend2crr2Cwomg/R1OXjNQqrBk28q9Jdms
7+6Lfl2+2NsLa/W03EHeM7Za4O3fkl10hryPxgXIvLDLLEpzkGtbziOfqc7Zyoko
Vp26PJRdyJZkZZ75JdKA9GmRzm0fAavCVa1TNLBAStNaz7t8yWJmREpnpXuVXG/n
xfuh0JOLhOiGwuDcLpHxMDr8RriJ2qA7T6wAzdYYszaxq3udvbMQsWwF1bO9DDI6
Ypxq+bfboLiV3FvPgDxkpxSoGuVtxBLmrmPem149F99fhYKbUROMvxYl+Oourmso
0cIMyHa/aAMoTgda48YvQBDmUJaq54WzPI9SWSFG1HVUglmcxQm6EXr0hVL5DkAf
nJ8iacPt6Z1/1w+NQwC5AY7OdGD7QGcJWul9reZBNtwja0gwtd45tq24Ip7nWGXB
97hz/Iqi3LEqRk7sfCFZ
=UPJn
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Wed Dec 16 09:08:11 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A15F1A6F10 for ; Wed, 16 Dec 2015 09:08:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 wm22cBtKYvLO for ; Wed, 16 Dec 2015 09:08:08 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 84BF11A701D for ; Wed, 16 Dec 2015 09:07:18 -0800 (PST)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 92EAA1AE03CD; Wed, 16 Dec 2015 18:07:17 +0100 (CET)
Date: Wed, 16 Dec 2015 18:08:18 +0100 (CET)
Message-Id: <20151216.180818.925309370580470112.mbj@tail-f.com>
To: aashaikh@google.com
From: Martin Bjorklund 
In-Reply-To: 
References:   
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Guidance on list vs. container of list
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 17:08:10 -0000

Anees Shaikh  wrote:
> I'm not suggesting this is necessarily standard behavior :-)

I think this demonstrates that it is probably not a good idea to
design (standard) data models to optimize for a single protocol /
implementation.  For NETCONF, the problem is clearly in the protocol,
and it should be fixed in the protocol (Andy already showed a
solution).

Going back to the original question, I don't think there's a single
rule to be used.  Sometimes the additional container makes sense, but
in some cases (normally further down in the hierarchy, for "smaller"
lists) it just adds noise.


/martin


, but some
> major implementations behave this way (it could be useful in some
> circumstances) -- on those platforms, the enclosing container makes a
> request for the whole list arguably less ambiguous.
> 
> thanks.
> -- Anees
> 
> On Wed, Dec 16, 2015 at 8:48 AM, Christian Hopps  wrote:
> 
> >
> > Anees Shaikh  writes:
> >
> > hi Chris, in OpenConfig models we use enclosing containers on lists based
> >> on feedback from some implementors who claimed that it made it more
> >> efficient to, for example, retrieve the entire list (ask for the
> >> container), retrieve the keys in the list (ask for the list node), or
> >> retrieve a particular element of the list (specify the key).
> >>
> >
> > But, I don't think asking for the list node returns only keys, I think it
> > returns the entire content of the node, i.e., it's equivalent to asking for
> > the out container if that container only contains a single list (the model
> > in question here).
> > Thanks,
> > Chris.
> >
> >
> > Aside from some stuttering in the paths (which can be a little annoying
> >> but I don't expect to write the config instances by hand), there didn't
> >> seem to be a major downside.  So we try to be consistent across the models
> >> with this approach.  After getting some more experience with the
> >> implementations, we might revisit.
> >>
> >> thanks.  -- Anees
> >>
> >> On Mon, Dec 14, 2015 at 6:30 PM, Andy Bierman  wrote:
> >>
> >> Hi,
> >>>
> >>> Use of NP-containers are subjective, based on how you want to organize
> >>> your data.  The extra layer of containment may be a waste, but it sometimes
> >>> has a purpose
> >>>
> >>>   - 2 or more sibling lists with lots of entries can be mixed   in
> >>> JSON,     so putting each list in its container prevents that.  - There is
> >>> no standard way to 'delete-all' in NETCONF or  RESTCONF     but a 'replace'
> >>> on the parent container can be used for     this purpose.  (container of
> >>> list or leaf-list)  - container servers as a conceptual 'root' for
> >>> external  augments
> >>>
> >>> Andy
> >>>
> >>>
> >>> On Mon, Dec 14, 2015 at 5:56 PM, Christian Hopps 
> >>> wrote:
> >>>
> >>>
> >>>> Some models seem to place a single list of things inside a container
> >>>> also named after the items in the list, e.g.,
> >>>>
> >>>> +--ro modulename   +--rw ribs      +--rw rib* [name]         +--rw name
> >>>> I don't see the purpose of these containers. It seems to me that one can
> >>>> model and query the exact same data without the outer container. That is,
> >>>>
> >>>> +--ro modulename   +--rw rib* [name]      +--rw name Is there something
> >>>> useful about these containers that I've missed, as it's a fairly common
> >>>> pattern in the models I've been looking at.   Example comparisons below..
> >>>> Thanks, Chris.
> >>>>
> >>>>
> >>>> w/ container:                  
> >>>> foo            bar         ...
> >>>>   w/o container:          
> >>>> foo        bar       ...
> >>>>  Likewise if you want to fetch all ribs you can either way:
> >>>>
> >>>>                        
> >>>>  or
> >>>>
> >>>>                        
> >>>>  Or a particular rib
> >>>>
> >>>>                            
> >>>> foo                        
> >>>>  or
> >>>>
> >>>>                            foo
> >>>>                Using xpath:
> >>>>
> >>>>    /modulename/ribs/rib[name='foo'] or
> >>>>
> >>>>    /modulename/rib[name='foo']
> >>>>
> >>>> _______________________________________________ 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 Dec 16 09:42:02 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFB11A21AC for ; Wed, 16 Dec 2015 09:42:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 dBTCIisWYm3U for ; Wed, 16 Dec 2015 09:41:59 -0800 (PST)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 B16801A1B67 for ; Wed, 16 Dec 2015 09:41:58 -0800 (PST)
Received: by mail-lf0-x232.google.com with SMTP id y184so34590263lfc.1 for ; Wed, 16 Dec 2015 09:41:58 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=CT9usSq4ScsUJS452+tnezIpW5TlSbxkiA+ekJDKFGM=; b=RuaDGmQXI0wlHxB0blz0ce8y6S2iYcvqjqFb0QztTwE3Br3ns/buZi3tLaIupp+L5w /XQXGLWoDXCfmp2BY/ac2WhmhR50JxFob/H+TalYmYAUMfKpWqJdmyRrd3XXjbVIrTh/ jA8/aWUXfSKZB1uwkGBsnVxgstQJAJqoXbD37TKthqsCcd0WrKh+U3lJR8gNCYH7ZgoH IAYUUTHa0VtOWxKnj5zTSm597AdGEC0UOvd812QQ2VnCA2rOhUGb7GxGCL5l2erkWwKd DAaHVSK2Vpo9ukkKAfvLnmLr7PHf97RKRJ+Pv1ujeGeQIwWbt+QV2Xa+t7IHIs3mRyCm wQqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=CT9usSq4ScsUJS452+tnezIpW5TlSbxkiA+ekJDKFGM=; b=Pg7n8rEtdY3uJLgADGcDpfOzdxIai1dvJNCJVW0hz0vTaTdvM1kpr1dtfLR1rEMZaM qZ1Q2r3KyLSQCmvyDobE/PaxhbdJbAFPGqv2FlcdeOCD2DtjbwFt6kLtscbYZmaaaFs3 DeNDjdPfQtAhLTYycJQ+aJXMrbVN7+IpYkOO0rsqslvXAv9KUMwjm8EElmewfonwhM8j k1JqOtiGl95N8vX5NizEI8ccuDSCJqRMXy8oO3OjJvA2nTu4/FZhISTKGcXFi0x0pvjg t+yLRT2dCZpfKF09aL/41N//WLNjSmYTbzoluA/mMv85sL3hHAlVTgIR1GS3sVoYmADP UGrQ==
X-Gm-Message-State: ALoCoQntMcOo1YM+vQzxKT09HhBkWTHhqS/AJyBNLGrDeLHpyuDCRmxLZhe3AstvY2iAO3mFyYeIsGyFiMZpgBxQPyucdTHlkg==
MIME-Version: 1.0
X-Received: by 10.25.85.200 with SMTP id j191mr18839214lfb.131.1450287716792;  Wed, 16 Dec 2015 09:41:56 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Wed, 16 Dec 2015 09:41:56 -0800 (PST)
In-Reply-To: 
References:   
Date: Wed, 16 Dec 2015 09:41:56 -0800
Message-ID: 
From: Andy Bierman 
To: Christian Hopps 
Content-Type: multipart/alternative; boundary=001a11424d0c2e92ab0527076c34
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Guidance on list vs. container of list
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 17:42:01 -0000

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

On Wed, Dec 16, 2015 at 9:04 AM, Christian Hopps  wrote:

>
> Andy Bierman  writes:
>
> Hi,
>>
>> Use of NP-containers are subjective, based on how you want to organize
>> your data.  The extra layer of containment may be a waste, but it sometimes
>> has a purpose
>>
>>   - 2 or more sibling lists with lots of entries can be mixed in   JSON,
>>    so putting each list in its container prevents that.
>>
>
> Did you mean XML here (Lada indicated it's not the case with JSON)? I was
> curious if mixing like this was allowed in XML case (whether items from 2
> different lists or even sibling leafs). I was hoping that once a list
> started in the XML all items in the list would be present before other
> items outside the list. If what your saying applies to XML then one would
> have to iterate all sibling nodes in the containing node to collect the
> list. This would seem to be the case even with sibling leafs in the model.
> I find this a bit surprising, and would expect bugs in implementation if
> so. :)
>

Lada is correct so ignore this use-case



>  - container servers as a conceptual 'root' for external  augments
>>
>
> This might be useful in some cases, probably not a reason to always
> include a container wrapper though.
>
>>  - There is no standard way to 'delete-all' in NETCONF or  RESTCONF
>>  but a 'replace' on the parent container can be used for this     purpose.
>> (container of list or leaf-list)
>>
>
> This is an interesting use -- using a modeling technique to to get around
> missing functionality in the protocol (hello opstate! :)
> Seriously though, should we consider adding delete-all functionality then?
>


Maybe in the future if NETCONF gets updated



> Thanks, Chris.
>


Andy


>
> Andy
>>
>>
>> On Mon, Dec 14, 2015 at 5:56 PM, Christian Hopps 
>> wrote:
>>
>>
>>> Some models seem to place a single list of things inside a container
>>> also named after the items in the list, e.g.,
>>>
>>> +--ro modulename   +--rw ribs      +--rw rib* [name]         +--rw name
>>> I don't see the purpose of these containers. It seems to me that one can
>>> model and query the exact same data without the outer container. That is,
>>>
>>> +--ro modulename   +--rw rib* [name]      +--rw name Is there something
>>> useful about these containers that I've missed, as it's a fairly common
>>> pattern in the models I've been looking at.   Example comparisons below..
>>> Thanks, Chris.
>>>
>>>
>>> w/ container:                  
>>> foo            bar         ...
>>>   w/o container:          
>>> foo        bar       ...
>>>  Likewise if you want to fetch all ribs you can either way:
>>>
>>>                        
>>>  or
>>>
>>>                        
>>>  Or a particular rib
>>>
>>>                            
>>> foo                        
>>>  or
>>>
>>>                            foo
>>>                Using xpath:
>>>
>>>    /modulename/ribs/rib[name='foo'] or
>>>
>>>    /modulename/rib[name='foo']
>>>
>>> _______________________________________________ netmod mailing list
>>> netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
>>>
>>>
>>>
>

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




On Wed, Dec 16, 2015 at 9:04 AM, Christian Hopps <=
chopps@chopps.org> wrote:


Andy Bierman <an=
dy@yumaworks.com> writes:





Hi,



Use of NP-containers are subjective, based on how you want to organize your=
 data.=C2=A0 The extra layer of containment may be a waste, but it sometime=
s has a purpose



=C2=A0 - 2 or more sibling lists with lots of entries can be mixed in=C2=A0=
 =C2=A0JSON,=C2=A0 =C2=A0 =C2=A0so putting each list in its container preve=
nts that. 





Did you mean XML here (Lada indicated it's not the case with JSON)? I w=
as curious if mixing like this was allowed in XML case (whether items from =
2 different lists or even sibling leafs). I was hoping that once a list sta=
rted in the XML all items in the list would be present before other items o=
utside the list. If what your saying applies to XML then one would have to =
iterate all sibling nodes in the containing node to collect the list. This =
would seem to be the case even with sibling leafs in the model. I find this=
 a bit surprising, and would expect bugs in implementation if so. :) 

Lada is correct so ignore this use-case

=C2=A0



=C2=A0- container servers as a conceptual 'root' for external=C2=A0=
 augments 





This might be useful in some cases, probably not a reason to always include=
 a container wrapper though. 



=C2=A0- There is no standard way to 'delete-all' in NETCONF or=C2=
=A0 RESTCONF=C2=A0 =C2=A0 =C2=A0but a 'replace' on the parent conta=
iner can be used for this=C2=A0 =C2=A0 =C2=A0purpose.=C2=A0 (container of l=
ist or leaf-list) 





This is an interesting use -- using a modeling technique to to get around m=
issing functionality in the protocol (hello opstate! :) 

Seriously though, should we consider adding delete-all functionality then? =



Maybe in the future if =
NETCONF gets updated

=C2=A0

Thanks, Chris.


Andy
=C2=A0





Andy





On Mon, Dec 14, 2015 at 5:56 PM, Christian Hopps <chopps@chopps.org> wrote:







Some models seem to place a single list of things inside a container also n=
amed after the items in the list, e.g.,



+--ro modulename=C2=A0 =C2=A0+--rw ribs=C2=A0 =C2=A0 =C2=A0 +--rw rib* [nam=
e]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw name I don't see the purpose =
of these containers. It seems to me that one can model and query the exact =
same data without the outer container. That is,



+--ro modulename=C2=A0 =C2=A0+--rw rib* [name]=C2=A0 =C2=A0 =C2=A0 +--rw na=
me Is there something useful about these containers that I've missed, a=
s it's a fairly common pattern in the models I've been looking at.=
=C2=A0 =C2=A0Example comparisons below..=C2=A0 Thanks, Chris.





w/ container:=C2=A0 =C2=A0 <modulename>=C2=A0 =C2=A0 =C2=A0 <ribs&=
gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 <rib>=C2=A0 =C2=A0 <name>foo<=
/name> </rib> <rib>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <na=
me>bar</name>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </rib> ... </rib=
s> </modulename> w/o container:=C2=A0 =C2=A0 <modulename>=C2=
=A0 =C2=A0 =C2=A0 <rib>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>foo<=
;/name>=C2=A0 =C2=A0 =C2=A0 </rib> <rib> <name>bar<=
/name>=C2=A0 =C2=A0 =C2=A0 </rib> ...=C2=A0 =C2=A0 </modulename=
> Likewise if you want to fetch all ribs you can either way:



=C2=A0 =C2=A0<filter>=C2=A0 =C2=A0 =C2=A0 <modulename>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 <ribs/>=C2=A0 =C2=A0 =C2=A0 </modulename>=
=C2=A0 =C2=A0 </filter> or



=C2=A0 =C2=A0<filter>=C2=A0 =C2=A0 =C2=A0 <modulename>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 <rib/>=C2=A0 =C2=A0 =C2=A0 </modulename>=
=C2=A0 =C2=A0 </filter> Or a particular rib



=C2=A0 =C2=A0<filter>=C2=A0 =C2=A0 =C2=A0 <modulename>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 <ribs>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <rib=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name>foo</name>=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </rib>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
</ribs>=C2=A0 =C2=A0 =C2=A0 </modulename>=C2=A0 =C2=A0 </fil=
ter> or



=C2=A0 =C2=A0<filter>=C2=A0 =C2=A0 =C2=A0 <modulename>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 <rib>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <name=
>foo</name>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </rib>=C2=A0 =C2=A0 =
=C2=A0 </modulename>=C2=A0 =C2=A0 </filter> Using xpath:



=C2=A0 =C2=A0/modulename/ribs/rib[name=3D'foo'] or



=C2=A0 =C2=A0/modulename/rib[name=3D'foo']



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













--001a11424d0c2e92ab0527076c34--


From nobody Wed Dec 16 09:46:23 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B311A039B for ; Wed, 16 Dec 2015 09:46:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 U2PzplwxdFwL for ; Wed, 16 Dec 2015 09:46:17 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2AA1A011C for ; Wed, 16 Dec 2015 09:46:03 -0800 (PST)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id C9C031AE03CD; Wed, 16 Dec 2015 18:46:01 +0100 (CET)
Date: Wed, 16 Dec 2015 18:47:02 +0100 (CET)
Message-Id: <20151216.184702.2006246752868355276.mbj@tail-f.com>
To: jernej.tuljak@mg-soft.com
From: Martin Bjorklund 
In-Reply-To: <56719A45.90608@mg-soft.com>
References: <56718098.90703@mg-soft.si> <20151216.171829.2198076201177316023.mbj@tail-f.com> <56719A45.90608@mg-soft.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: jernejt@mg-soft.si, netmod@ietf.org
Subject: Re: [netmod] Y02: context node
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 16 Dec 2015 17:46:21 -0000

Jernej Tuljak  wrote:
> 
> Dne 16.12.2015 ob 17:18 je Martin Bjorklund zapisal(a):
> > Jernej Tuljak  wrote:
> >> Ladislav Lhotka je 16.12.2015 ob 15:10 napisal:
> >>>> On 16 Dec 2015, at 14:08, Jernej Tuljak  wrote:
> >>>>
> >>>> Martin Bjorklund je 16.12.2015 ob 13:48 napisal:
> >>>>> Jernej Tuljak  wrote:
> >>>>>> Martin Bjorklund je 25.11.2015 ob 11:16 napisal:
> >>>>>>> Ladislav Lhotka  wrote:
> >>>>>>>> Hi,
> >>>>>>>>
> >>>>>>>> I'd like to resolve this issue. Here is a complete example (valid, I
> >>>>>>>> believe):
> >>>>>>>>
> >>>>>>>> module context {
> >>>>>>>>      namespace "http://example.com/context";
> >>>>>>>>      prefix ctx;
> >>>>>>>>
> >>>>>>>>      leaf foo {
> >>>>>>>>        config false;
> >>>>>>>>        type uint32;
> >>>>>>>>      }
> >>>>>>>>      rpc oper {
> >>>>>>>>        output {
> >>>>>>>>          must "/foo mod foo = 0";
> >>>>>>>>          leaf foo {
> >>>>>>>>            type uint32;
> >>>>>>>>          }
> >>>>>>>>        }
> >>>>>>>>      }
> >>>>>>>> }
> >>>>>>>>
> >>>>>>>> 1. What does the accessible tree look like?
> >>>>>>> Note that the anser to this depends on the outcomne of Y04.  Andy has
> >>>>>>> strong objections to Y04-02, and proposed Y04-04 instead.
> >>>>>>>
> >>>>>>> Assuming Y04-02, and assuming /foo has the value 20 and the oper rpc's
> >>>>>>> result has foo = 10, the accessible tree would look like this:
> >>>>>>>
> >>>>>>>       
> >>>>>>>         +-- oper
> >>>>>>>         |   +-- foo = 10
> >>>>>>>         +-- foo = 20
> >>>>>>>
> >>>>>>>
> >>>>>>> (If we instead move back to Y04-04, the accessible tree would be:
> >>>>>>>
> >>>>>>>       
> >>>>>>>         +-- oper
> >>>>>>>             +-- foo = 10
> >>>>>>>
> >>>>>>> )
> >>>>>>>
> >>>>>>>> 2. What is the context node for the "must" expression?
> >>>>>>>     /oper
> >>>>>> This change to the accessible tree (1.0 --> 1.1) may break some
> >>>>>> existing "when" XPath expressions (those under "output" statement).
> >>>>> Maybe.  The old text said:
> >>>>>
> >>>>>      o  If the context node represents RPC output parameters, the tree is
> >>>>>         the RPC reply instance document.
> >>>>>
> >>>>> So this probably meant that for this definition:
> >>>>>
> >>>>>     module ex {
> >>>>>       ...
> >>>>>       prefix x;
> >>>>>       ...
> >>>>>       rpc foo {
> >>>>>         output {
> >>>>>           leaf bar { ... }
> >>>>>         }
> >>>>>       }
> >>>>>     }
> >>>>>
> >>>>> The accessile tree was:
> >>>>>
> >>>>>      nc:rpc-reply
> >>>>>        +-- x:bar
> >>>>>
> >>>>> This is very NETCONF-specifc.  With 1.1, the tree would be:
> >>>>>
> >>>>>      x:foo
> >>>>>        +-- x:bar
> >>>>>
> >>>>> which is protocol-neutral.
> >>>>>
> >>>>>> Is
> >>>>>> this compatible with 1.1 charter - "All compliant YANG 1.0 modules
> >>>>>> must be accepted as compliant YANG 1.1 modules"?
> >>>>>>
> >>>>>>     rpc my-rpc {
> >>>>>>       output {
> >>>>>>         uses my-stuff {
> >>>>>>           when "specific-param = 'foo'";// 1.0
> >>>>>> // when "my-rpc/specific-param = 'foo'" // 1.1
> >>>>> This is not correct.  If a relative path is used, it would be the same
> >>>>> in 1.0 and 1.1.
> >>>> I disagree due to current text:
> >>>>
> >>>>     o  data node: A node in the schema tree that can be instantiated in a
> >>>>        data tree.  One of container, leaf, leaf-list, list, anydata, and
> >>>>        anyxml.
> >>>>
> >>>>     o  If the XPath expression is defined in a substatement to an
> >>>>        "output" statement in an "rpc" or "action" statement, the
> >>>>        accessible tree is the RPC or action operation instance, all state
> >>>>        data in the server, and the running configuration datastore.  The
> >>>>        root node has top-level data nodes in all modules as children.
> >>>>        Additionally, for an RPC, the root node also has the node
> >>>>        representing the RPC operation being defined as a child.  The node
> >>>>        representing the operation being defined has the operation's
> >>>>        output parameters as children.
> >>>>
> >>>>     o  If the "when" statement is a child of a "uses", "choice", or
> >>>>        "case" statement, then the context node is the closest ancestor
> >>>>        node to the "uses", "choice", or "case" node that is also a data
> >>>>        node.  If no such node exists, the context node is the root node.
> >>>>        The accessible tree is tentatively altered during the processing
> >>>>        of the XPath expression by removing all instances (if any) of the
> >>>>        nodes added by the "uses", "choice", or "case" statement.
> >>>>
> >>>>
> >>>> It clearly says that the context node is the root node ("/"), not the
> >>>> node representing the RPC ("/my-rpc"), which is a child to root
> >>>> node. The "root node" aka "document root" can only mean a single thing
> >>>> XPath terminology.
> >>> RFC 6020 clearly says that the tree is the rpc reply instance
> >>> document, so it is a different document whose root node coincides with
> >>> . The problem of 6020bis is that we need a definition
> >>> that's independent of XML, and that's not so easy, but I agree with
> >>> Martin that nothing should change for relative paths.
> >> I'm not against the new accessible tree. That nothing should change
> >> for relative paths is a given, IMO. So what about absolute location
> >> paths?
> >>
> >> The previous accessible tree for a "when" expression under "output"
> >> was:
> >>
> >> 
> >>    +- x:bar
> > No it was:
> >
> >    
> >      +-- nc:rpc-reply
> >        +- x:bar
> >
> >> and now it is:
> >>
> >> 
> >>    +- x:foo
> >>      +- x:bar
> >>
> >> The absolute path to "x:bar" was:
> >>
> >> /x:bar
> > /nc:rpc-reply/x:bar
> 
> No. How do you explain the different wording for "input" when compared
> to "output" (6020, 7.19.5):
> 
>    o  If the context node represents RPC input parameters, the tree is
>       the RPC XML instance document.  The XPath root node has the
>       element representing the RPC operation being defined as the only
>       child.
> 
>    o  If the context node represents RPC output parameters, the tree is
>       the RPC reply instance document.  The XPath root node has the
>       elements representing the RPC output parameters as children.
> 
> "XPath root node has the _element_ representing the RPC operation as
> the _only child_" vs. "XPath root node has the _elements_ representing
> the RPC output as _children_".
> 
> This is different from what 6020bis-09 is saying. The latter
> "equalized" accessible trees for "input" and "output". What I am
> asking is whether this confilcts with 1.1 charter.

You're right, but the entire thing is underspecifed in 6020.  In the
example you had:

  rpc foo {
    output {
      uses my-stuff {
        when "...";
      }
    }
  }

and if you go by 6020, there is no context node for the when
expression, and the accessible tree is defined in terms of the context
node.

Yes this is different in 1.1, but I think we're specifying rules for
something that wasn't specified, and fix inconsistencies.

> You could never refer to "nc:rpc-reply" as anything other that the
> document root in 1.0 ("/") . You could never refer to "nc:rpc" either,
> only to "x:foo".

It depends on how you interpret the words: "the tree is the RPC reply
instance document."

> >> and is now:
> >>
> >> /x:foo/x:bar
> >>
> >> and this needs to be taken into account for at least relative paths to
> >> stay the same. Again, the root node is "/" in any case. So the context
> >> node needs to be set explicitly "/x:foo" for this corner case. I dare
> >> say it is not even a corner case. There is a similar YANG pattern to
> >> my "my-rpc" example in ietf-netconf-notifications for a
> >> "notification".
> > I think what needs to be done is to clarify that the context node for
> > when/must in input/output or uses in input/output is the node
> > representing the rpc.  Note that this is unspecified in 6020.
> 
> True. It is unspecified. For notifications also, yet
> ietf-netconf-notifications practices it.

It just uses relative paths, in places where the context node is
well-defined.


/martin



> 
> Jernej
> 
> >
> > /martin
> >
> >
> >
> >> Jernej
> >>
> >>> Lada
> >>>
> >>>> Jernej
> >>>>
> >>>>> If an absolute path is used, it would be:
> >>>>>
> >>>>>      when "/nc:rpc-reply/x:specific-param = 'foo'"; // 1.0
> >>>>>      when "/x:my-rpc/x:specific-param = 'foo'";     // 1.1
> >>>>>
> >>>>>
> >>>>> I wonder if any implementation of 1.0 supports this absolute form.
> >>>>>
> >>>>>
> >>>>> /martin
> >>>>>
> >>>>>
> >>>>>>         }
> >>>>>>         leaf specific-param {
> >>>>>>           type string;
> >>>>>>         }
> >>>>>>       }
> >>>>>>     }
> >>>>>>
> >>>>>> Jernej
> >>>>>>
> >>>>>>> /martin
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Thanks, Lada
> >>>>>>>>
> >>>>>>>> Martin Bjorklund  writes:
> >>>>>>>>
> >>>>>>>>> Ladislav Lhotka  wrote:
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> Y02-01 allows "must" as a substatement of "input", "output" and
> >>>>>>>>>> "notification" but for these cases the specification of the context
> >>>>>>>>>> node in sec. 7.5.3 doesn't work.
> >>>>>>>>>>
> >>>>>>>>>>       o The context node is the node in the accessible tree for
> >>>>>>>>>>       which
> >>>>>>>>>>       the
> >>>>>>>>>>          "must" statement is defined.
> >>>>>>>>> You are right.  But note how the accessible tree is defined.  There
> >>>>>>>>> is
> >>>>>>>>> a node for the operation / notification.  This node should be the
> >>>>>>>>> context node:
> >>>>>>>>>
> >>>>>>>>>       o If the "must" statement is a substatement of a "notification"
> >>>>>>>>>          statement, the context node is the node representing the
> >>>>>>>>>          notification in the accessible tree.
> >>>>>>>>>
> >>>>>>>>>       o  If the "must" statement is a substatement of a "input"
> >>>>>>>>>          statement, the context node is the node representing the
> >>>>>>>>>          operation in the accessible tree.
> >>>>>>>>>
> >>>>>>>>>       o  If the "must" statement is a substatement of a "output"
> >>>>>>>>>          statement, the context node is the node representing the
> >>>>>>>>>          operation in the accessible tree.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> /martin
> >>>>>>>> -- 
> >>>>>>>> Ladislav Lhotka, CZ.NIC Labs
> >>>>>>>> PGP Key ID: E74E8C0C
> >>>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> 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, CZ.NIC Labs
> >>> PGP Key ID: E74E8C0C
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> 


From nobody Wed Dec 16 16:10:11 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641CB1A9154 for ; Wed, 16 Dec 2015 16:10:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 4yLDay5BTKD0 for ; Wed, 16 Dec 2015 16:10:09 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 91B8F1A913D for ; Wed, 16 Dec 2015 16:10:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450310981; bh=strvHC+PqtBK/Eo3rGXiSFOgnVYCj9hoyinYby5AdQI=; h=From:Subject:Date:Cc:To; b=H5EJZ7oxUqelh/uf3+qS0TtRYPPDruj5ovtd1+eQmzWhN+ZA7v/ej8vbxVOnrBWX7 X/vEaUegPrVODKnCbfyjnQ4UqLWd49fRxn4jA477rKsQ1WbH7Q5eSJXU5lvpSDcflK 43Fj3XAldbR+VrpgOqn/ChMQpsvbc/wOhKLa7LZY=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
From: Nadeau Thomas 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Wed, 16 Dec 2015 19:10:03 -0500
Message-Id: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>
To: netmod WG 
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=17 Stars=0 Good=0 Friend=2 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 216, in=2892, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: netmod-chairs@tools.ietf.org
Subject: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 00:10:10 -0000

	This is a WG Last Call on draft-ietf-netmod-opstate-reqs-01.
Please post comments on this draft by Wednesday, December 30, 2015
at 9AM EST.

	Tom/Kent



From nobody Wed Dec 16 16:21:26 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADAC81A0235 for ; Wed, 16 Dec 2015 16:21:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 RdhsTRpFXjZe for ; Wed, 16 Dec 2015 16:21:18 -0800 (PST)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 2ECBE1A0180 for ; Wed, 16 Dec 2015 16:21:18 -0800 (PST)
Received: by mail-lf0-x22d.google.com with SMTP id p203so41516952lfa.0 for ; Wed, 16 Dec 2015 16:21:18 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=K8rRDjeaR1Y1TIu7snjxYz63SY7ok0cIapiBuajLe5w=; b=nHkYPBULvU8o+QW3LD2zq9o0PYcQ2qmVbJk4T3cwfmIo7lRFw7ojIF5jYnujhkqLEm 5VEUZ7fkGxMSBQYFbgVr6yMoQUwvTKK5K9t23ThsuqVbaQd6y9aNDuBg0GAgXBhDilxa x+70AWc0kn62BeFl/dZB/9l4lv4LIIoQoJXxlmU/xAvc0ui5ByD2O/0MZMFb6JGH6pbF g7EmYkrLKah0rphvTT0l2JqVuolvIDY+BKZqThfaCHDCLP/YvkbhHCklpG1ZaorUoqBf a4vEIlcuVgQ3kYOf1sckfCwQ+CZe0LMv5x4TIASzB1lDNJLrINu8d+B2yVtzwAtVXdeb +XKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=K8rRDjeaR1Y1TIu7snjxYz63SY7ok0cIapiBuajLe5w=; b=dKT7JAqm9KH8bS/KwzCynxn+pNNxQwUlAcKtuJ5+tKQQtTSawU1eA8Zp2Iz/S5jfy5 j2JqycsQXBAizBAV2psVs/jERdmnvIemTVNIO4QlJ7FzhxK32snCagZkeDqZPINPsSaR Y/jayPXi2LiolKPS9Z98WDM/chhHAtL+PNG1MpZmaI+pmNcr/kESqCiAXnu7JWiiTNYK Z1Y33Vjc/LaOHZfIseL1dRqk3Ud14cPix81aeES2ESHaMKcb2WUO14cEF/4boG/olzeQ cMuFVAil0c/kglhzSV+zh6g9lZzYFeUPrNHlEMLQFx+2bs9b5o7U//mzHvqawGp839s/ IatA==
X-Gm-Message-State: ALoCoQk4mkx4aZXdRwvtguYjSeZ6j4VSAbtK4ctk4zoykzZWTgxhXZW5sozcOrPMKLL6uVzJgtcATe4bWMvSFnxXRNlqmpxcXA==
MIME-Version: 1.0
X-Received: by 10.25.155.136 with SMTP id d130mr15494850lfe.54.1450311676223;  Wed, 16 Dec 2015 16:21:16 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Wed, 16 Dec 2015 16:21:16 -0800 (PST)
In-Reply-To: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>
Date: Wed, 16 Dec 2015 16:21:16 -0800
Message-ID: 
From: Andy Bierman 
To: Nadeau Thomas 
Content-Type: multipart/alternative; boundary=001a1140223e467e0305270d001f
Archived-At: 
Cc: "netmod-chairs@tools.ietf.org" , netmod WG 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 00:21:19 -0000

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

Hi,

I have asked repeatedly for some indication of scope in these requirements.
There is an assumption all possible YANG-based platforms have intended
and applied state that can be different for a long enough interval such
that retrieving
the differences is operationally useful.

For devices that converge in milli-seconds or even as long as 5 seconds,
I do not see the point of implementing solutions for these requirements.
I would prefer that this draft specify some sort of objective
metric for determining the solution applicability.


Andy


On Wed, Dec 16, 2015 at 4:10 PM, Nadeau Thomas 
wrote:

>
>         This is a WG Last Call on draft-ietf-netmod-opstate-reqs-01.
> Please post comments on this draft by Wednesday, December 30, 2015
> at 9AM EST.
>
>         Tom/Kent
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


Hi,

I have asked repeatedly for some in=
dication of scope in these requirements.
There is an assumption a=
ll possible YANG-based platforms have intended
and applied state =
that can be different for a long enough interval such that retrieving
=

the differences is operationally useful.

For =
devices that converge in milli-seconds or even as long as 5 seconds,
<=
div>I do not see the point of implementing solutions for these requirements=
.
I would prefer that this draft specify some sort of objective
metric for determining the solution applicability.

<=
/div>

Andy


On Wed, Dec 16, 2015 at 4:10 PM, Nad=
eau Thomas <tnadeau@lucidvision.com> wrote:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is a WG Last Call on draft-ietf-netmod-ops=
tate-reqs-01.

Please post comments on this draft by Wednesday, December 30, 2015

at 9AM EST.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Tom/Kent





_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a1140223e467e0305270d001f--


From nobody Wed Dec 16 18:19:10 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1DFA1A0069 for ; Wed, 16 Dec 2015 18:19:08 -0800 (PST)
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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 WszQQFdXSLax for ; Wed, 16 Dec 2015 18:19:05 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::758]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978321A0060 for ; Wed, 16 Dec 2015 18:19:04 -0800 (PST)
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 (TLS) id 15.1.355.16; Thu, 17 Dec 2015 02:18:42 +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.0355.012; Thu, 17 Dec 2015 02:18:42 +0000
From: Kent Watsen 
To: Andy Bierman 
Thread-Topic: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
Thread-Index: AQHROF9M9GZCZpOeokmaO0YJheWZYJ7OUPEA///M+wA=
Date: Thu, 17 Dec 2015 02:18:42 +0000
Message-ID: <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net>
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.151105
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.13]
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 5:82WWMrB4q6ra3hhEzJvtLHRiwJHkOcPndWeGE+FPSJxzZpoFp4tTBAg6x9GI2n2ClzZtPhx7IK4gBIqFMNuTnsKkObXDIZkTjVSMzAWClvVGYXh/h1wy46vrYQNjpwrzeGHErLjXFH3yU7NuCJJMIQ==; 24:vei/ZAXd7tq4dWsGIKcCp+oXOwnds3yN/9hQfDWU9Sm3M5GHq9WiMKocD5bVtg4aifN5U3Qr2VMRzi30SkwiQQDJSFUdMErpV/9z1UNYoBQ=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1442;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; 
x-forefront-prvs: 07935ACF08
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(377454003)(189002)(24454002)(122556002)(87936001)(82746002)(66066001)(83506001)(40100003)(19580405001)(54356999)(110136002)(97736004)(81156007)(4001350100001)(50986999)(189998001)(76176999)(5001960100002)(86362001)(16236675004)(106116001)(99286002)(101416001)(105586002)(106356001)(33656002)(19580395003)(5002640100001)(36756003)(11100500001)(5008740100001)(10400500002)(15975445007)(92566002)(83716003)(6116002)(3846002)(5004730100002)(77096005)(102836003)(586003)(1220700001)(1096002)(2900100001)(2950100001)(19617315012)(230783001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; 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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_02367647696D4BA881FA15CB95D5DBDAjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2015 02:18:42.0666 (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: 
Cc: netmod WG 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 02:19:08 -0000

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

DQpbYXMgYSBjb250cmlidXRvcl0NCg0KSGkgQW5keSwNCg0KSeKAmW0gc3RydWdnbGluZyBhIGJp
dCB0byB1bmRlcnN0YW5kIHdoYXQgaXMgbW90aXZhdGluZyB5b3UgdG8gYXNrIHRoaXMgcXVlc3Rp
b24uICAgIFRoYXQgaXMsIGFzIGEgdG9vbCB2ZW5kb3IsIEkgd291bGRu4oCZdCB0aGluayB0aGF0
IGFueSBkZWNpc2lvbiBtYWRlIGhlcmUgd291bGQgYWZmZWN0IHlvdSBpbW1lZGlhdGVseS4gICBN
eSBleHBlY3RhdGlvbnMgYXJlIHRoYXQgYW55IGltcGFjdCB0byBZQU5HL05FVENPTkYvUkVTVENP
TkYgd291bGQgYmUgYmFja3dhcmRzIGNvbXBhdGlibGUsIHN1Y2ggdGhhdCBpbXBsZW1lbnRhdGlv
bnMgd291bGQgb25seSBvcHQtaW4gd2hlbiBuZWVkZWQgLSBhIHBheSBhcyB5b3UgZ3JvdyBzdHJh
dGVneS4gICBCdXQgaGVyZWluIHBlcmhhcHMgbGllcyBhbiB1bnN0YXRlZCByZXF1aXJlbWVudCwg
dGhhdCB0aGUgaW1wYWN0IHRvIFlBTkcvTkVUQ09ORi9SRVNUQ09ORiBuZWVkcyB0byBiZSBiYWNr
d2FyZHMgY29tcGF0aWJsZSB3aXRoIHJlc3BlY3QgdG8gZXhpc3RpbmcgZGVwbG95bWVudHMuICBE
aWQgd2UgbWlzcyBpdCBvciBpcyBpdCB0b28gb2J2aW91cz8NCg0KSSBhZ3JlZSB0aGF0IHN1cHBv
cnRpbmcgdGhlc2UgcmVxdWlyZW1lbnRzIHdpbGwgYmUgdW5uZWNlc3NhcnkgZm9yIG1hbnkgcGxh
dGZvcm1zLiAgQWZ0ZXIgYWxsLCB3ZeKAmXZlIGdvbmUgZGVjYWRlcyB3aXRob3V0IG5lZWRpbmcg
c3VjaCB2aXNpYmlsaXR5LCBhbmQgdGhhdOKAmXMgbm90IGdvaW5nIHRvIGNoYW5nZSBmb3IgbWFu
eSBwbGF0Zm9ybXMgZm9yIHNvbWUgdGltZSwgaWYgZXZlci4NCg0KWW91IGFzayBmb3Igb2JqZWN0
aXZlIG1ldHJpY3MgZm9yIGRldGVybWluaW5nIHNvbHV0aW9uIGFwcGxpY2FiaWxpdHkuICBNeSB0
aGlua2luZyBpcyB0byBqdXN0IGxldCB0aGUgbWFya2V0IGRlY2lkZSAtIGlzIGl0IG5vdCBnb29k
IGVub3VnaD8gICBJZiBJIHRyaWVkIHRvIHF1YW50aWZ5IGl0LCBJIG1pZ2h0IHNheSB0aGF0IGl0
cyBvbmx5IHVzZWZ1bCBmb3IgbmV0d29ya2luZyBkZXZpY2VzIChhcyB0aGVpciBvcGVyYXRpb25h
bCBzdGF0ZSBzb21laG93IG1hdHRlcnMgbW9yZT8pIGFuZCB0aGF0IGl04oCZcyBvbmx5IHVzZWZ1
bCB3aGVuIHRoZXJlIGlzIG5vIGd1YXJhbnRlZSB0aGF0IHRoZSBpbnRlbmRlZCBjb25maWcgd2ls
bCBiZWNvbWUgb3BlcmF0aW9uYWwgKGkuZS4gYXBwbGllZCkgaW4gc29tZSBib3VuZGVkIGFtb3Vu
dCBvZiB0aW1lLiAgIEp1c3QgdGhyb3dpbmcgb3V0IGlkZWFzIGhlcmUsIGJ1dCBJIGxpa2UgYmVz
dCBsZXR0aW5nIHRoZSBtYXJrZXQgZGVjaWRlLg0KDQpLZW50DQoNCg0KRnJvbTogbmV0bW9kIDxu
ZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+PiBv
biBiZWhhbGYgb2YgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlA
eXVtYXdvcmtzLmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIERlY2VtYmVyIDE2LCAyMDE1IGF0IDc6
MjEgUE0NClRvOiBUaG9tYXMgTmFkZWF1IDx0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbTxtYWlsdG86
dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20+Pg0KQ2M6ICJuZXRtb2QtY2hhaXJzQHRvb2xzLmlldGYu
b3JnPG1haWx0bzpuZXRtb2QtY2hhaXJzQHRvb2xzLmlldGYub3JnPiIgPG5ldG1vZC1jaGFpcnNA
dG9vbHMuaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc+PiwgIm5l
dG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPiIgPG5ldG1vZEBpZXRmLm9yZzxt
YWlsdG86bmV0bW9kQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbbmV0bW9kXSBORVRNT0QgV0cg
TEM6IGRyYWZ0LWlldGYtbmV0bW9kLW9wc3RhdGUtcmVxcy0wMQ0KDQpIaSwNCg0KSSBoYXZlIGFz
a2VkIHJlcGVhdGVkbHkgZm9yIHNvbWUgaW5kaWNhdGlvbiBvZiBzY29wZSBpbiB0aGVzZSByZXF1
aXJlbWVudHMuDQpUaGVyZSBpcyBhbiBhc3N1bXB0aW9uIGFsbCBwb3NzaWJsZSBZQU5HLWJhc2Vk
IHBsYXRmb3JtcyBoYXZlIGludGVuZGVkDQphbmQgYXBwbGllZCBzdGF0ZSB0aGF0IGNhbiBiZSBk
aWZmZXJlbnQgZm9yIGEgbG9uZyBlbm91Z2ggaW50ZXJ2YWwgc3VjaCB0aGF0IHJldHJpZXZpbmcN
CnRoZSBkaWZmZXJlbmNlcyBpcyBvcGVyYXRpb25hbGx5IHVzZWZ1bC4NCg0KRm9yIGRldmljZXMg
dGhhdCBjb252ZXJnZSBpbiBtaWxsaS1zZWNvbmRzIG9yIGV2ZW4gYXMgbG9uZyBhcyA1IHNlY29u
ZHMsDQpJIGRvIG5vdCBzZWUgdGhlIHBvaW50IG9mIGltcGxlbWVudGluZyBzb2x1dGlvbnMgZm9y
IHRoZXNlIHJlcXVpcmVtZW50cy4NCkkgd291bGQgcHJlZmVyIHRoYXQgdGhpcyBkcmFmdCBzcGVj
aWZ5IHNvbWUgc29ydCBvZiBvYmplY3RpdmUNCm1ldHJpYyBmb3IgZGV0ZXJtaW5pbmcgdGhlIHNv
bHV0aW9uIGFwcGxpY2FiaWxpdHkuDQoNCg0KQW5keQ0KDQoNCk9uIFdlZCwgRGVjIDE2LCAyMDE1
IGF0IDQ6MTAgUE0sIE5hZGVhdSBUaG9tYXMgPHRuYWRlYXVAbHVjaWR2aXNpb24uY29tPG1haWx0
bzp0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbT4+IHdyb3RlOg0KDQogICAgICAgIFRoaXMgaXMgYSBX
RyBMYXN0IENhbGwgb24gZHJhZnQtaWV0Zi1uZXRtb2Qtb3BzdGF0ZS1yZXFzLTAxLg0KUGxlYXNl
IHBvc3QgY29tbWVudHMgb24gdGhpcyBkcmFmdCBieSBXZWRuZXNkYXksIERlY2VtYmVyIDMwLCAy
MDE1DQphdCA5QU0gRVNULg0KDQogICAgICAgIFRvbS9LZW50DQoNCg0KX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5l
dG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K

--_000_02367647696D4BA881FA15CB95D5DBDAjunipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <1E6C6A1C6901CD48A3AEE613468BC9A0@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+PGJy
Pg0KPC9kaXY+DQo8ZGl2PlthcyBhIGNvbnRyaWJ1dG9yXTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp
dj4NCjxkaXY+SGkgQW5keSw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PknigJltIHN0
cnVnZ2xpbmcgYSBiaXQgdG8gdW5kZXJzdGFuZCB3aGF0IGlzIG1vdGl2YXRpbmcgeW91IHRvIGFz
ayB0aGlzIHF1ZXN0aW9uLiAmbmJzcDsgJm5ic3A7VGhhdCBpcywgYXMgYSB0b29sIHZlbmRvciwg
SSB3b3VsZG7igJl0IHRoaW5rIHRoYXQgYW55IGRlY2lzaW9uIG1hZGUgaGVyZSB3b3VsZCBhZmZl
Y3QgeW91IGltbWVkaWF0ZWx5LiAmbmJzcDsgTXkgZXhwZWN0YXRpb25zIGFyZSB0aGF0IGFueSBp
bXBhY3QgdG8gWUFORy9ORVRDT05GL1JFU1RDT05GIHdvdWxkDQogYmUgYmFja3dhcmRzIGNvbXBh
dGlibGUsIHN1Y2ggdGhhdCBpbXBsZW1lbnRhdGlvbnMgd291bGQgb25seSBvcHQtaW4gd2hlbiBu
ZWVkZWQgLSBhIHBheSBhcyB5b3UgZ3JvdyBzdHJhdGVneS4gJm5ic3A7IEJ1dCBoZXJlaW4gcGVy
aGFwcyBsaWVzIGFuIHVuc3RhdGVkIHJlcXVpcmVtZW50LCB0aGF0IHRoZSBpbXBhY3QgdG8gWUFO
Ry9ORVRDT05GL1JFU1RDT05GIG5lZWRzIHRvIGJlIGJhY2t3YXJkcyBjb21wYXRpYmxlIHdpdGgg
cmVzcGVjdCB0byBleGlzdGluZw0KIGRlcGxveW1lbnRzLiAmbmJzcDtEaWQgd2UgbWlzcyBpdCBv
ciBpcyBpdCB0b28gb2J2aW91cz88L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgYWdy
ZWUgdGhhdCBzdXBwb3J0aW5nIHRoZXNlIHJlcXVpcmVtZW50cyB3aWxsIGJlIHVubmVjZXNzYXJ5
IGZvciBtYW55IHBsYXRmb3Jtcy4gJm5ic3A7QWZ0ZXIgYWxsLCB3ZeKAmXZlIGdvbmUgZGVjYWRl
cyB3aXRob3V0IG5lZWRpbmcgc3VjaCB2aXNpYmlsaXR5LCBhbmQgdGhhdOKAmXMgbm90IGdvaW5n
IHRvIGNoYW5nZSBmb3IgbWFueSBwbGF0Zm9ybXMgZm9yIHNvbWUgdGltZSwgaWYgZXZlci48L2Rp
dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PllvdSBhc2sgZm9yIG9iamVjdGl2ZSBtZXRyaWNz
IGZvciBkZXRlcm1pbmluZyBzb2x1dGlvbiBhcHBsaWNhYmlsaXR5LiAmbmJzcDtNeSB0aGlua2lu
ZyBpcyB0byBqdXN0IGxldCB0aGUgbWFya2V0IGRlY2lkZSAtIGlzIGl0IG5vdCBnb29kIGVub3Vn
aD8gJm5ic3A7IElmIEkgdHJpZWQgdG8gcXVhbnRpZnkgaXQsIEkgbWlnaHQgc2F5IHRoYXQgaXRz
IG9ubHkgdXNlZnVsIGZvciBuZXR3b3JraW5nIGRldmljZXMgKGFzIHRoZWlyIG9wZXJhdGlvbmFs
IHN0YXRlDQogc29tZWhvdyBtYXR0ZXJzIG1vcmU/KSBhbmQgdGhhdCBpdOKAmXMgb25seSB1c2Vm
dWwgd2hlbiB0aGVyZSBpcyBubyBndWFyYW50ZWUgdGhhdCB0aGUgaW50ZW5kZWQgY29uZmlnIHdp
bGwgYmVjb21lIG9wZXJhdGlvbmFsIChpLmUuIGFwcGxpZWQpIGluIHNvbWUgYm91bmRlZCBhbW91
bnQgb2YgdGltZS4gJm5ic3A7IEp1c3QgdGhyb3dpbmcgb3V0IGlkZWFzIGhlcmUsIGJ1dCBJIGxp
a2UgYmVzdCBsZXR0aW5nIHRoZSBtYXJrZXQgZGVjaWRlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp
dj4NCjxkaXY+S2VudDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGlkPSJN
QUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K
PC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9u
dC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6
YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5v
bmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hU
OiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1
bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk
Ij5Gcm9tOiA8L3NwYW4+bmV0bW9kICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kLWJvdW5jZXNA
aWV0Zi5vcmciPm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIEFu
ZHkgQmllcm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNvbSI+YW5keUB5
dW1hd29ya3MuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+
RGF0ZTogPC9zcGFuPldlZG5lc2RheSwgRGVjZW1iZXIgMTYsIDIwMTUgYXQgNzoyMSBQTTxicj4N
CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPlRob21hcyBOYWRlYXUg
Jmx0OzxhIGhyZWY9Im1haWx0bzp0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbSI+dG5hZGVhdUBsdWNp
ZHZpc2lvbi5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5D
YzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpuZXRtb2QtY2hhaXJzQHRvb2xzLmlldGYu
b3JnIj5uZXRtb2QtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0i
bWFpbHRvOm5ldG1vZC1jaGFpcnNAdG9vbHMuaWV0Zi5vcmciPm5ldG1vZC1jaGFpcnNAdG9vbHMu
aWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+
bmV0bW9kQGlldGYub3JnPC9hPiZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGll
dGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl
aWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtuZXRtb2RdIE5FVE1PRCBXRyBMQzogZHJh
ZnQtaWV0Zi1uZXRtb2Qtb3BzdGF0ZS1yZXFzLTAxPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv
ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj5IaSwNCjxkaXY+PGJyPg0KPC9kaXY+
DQo8ZGl2PkkgaGF2ZSBhc2tlZCByZXBlYXRlZGx5IGZvciBzb21lIGluZGljYXRpb24gb2Ygc2Nv
cGUgaW4gdGhlc2UgcmVxdWlyZW1lbnRzLjwvZGl2Pg0KPGRpdj5UaGVyZSBpcyBhbiBhc3N1bXB0
aW9uIGFsbCBwb3NzaWJsZSBZQU5HLWJhc2VkIHBsYXRmb3JtcyBoYXZlIGludGVuZGVkPC9kaXY+
DQo8ZGl2PmFuZCBhcHBsaWVkIHN0YXRlIHRoYXQgY2FuIGJlIGRpZmZlcmVudCBmb3IgYSBsb25n
IGVub3VnaCBpbnRlcnZhbCBzdWNoIHRoYXQgcmV0cmlldmluZzwvZGl2Pg0KPGRpdj50aGUgZGlm
ZmVyZW5jZXMgaXMgb3BlcmF0aW9uYWxseSB1c2VmdWwuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2
Pg0KPGRpdj5Gb3IgZGV2aWNlcyB0aGF0IGNvbnZlcmdlIGluIG1pbGxpLXNlY29uZHMgb3IgZXZl
biBhcyBsb25nIGFzIDUgc2Vjb25kcyw8L2Rpdj4NCjxkaXY+SSBkbyBub3Qgc2VlIHRoZSBwb2lu
dCBvZiBpbXBsZW1lbnRpbmcgc29sdXRpb25zIGZvciB0aGVzZSByZXF1aXJlbWVudHMuPC9kaXY+
DQo8ZGl2Pkkgd291bGQgcHJlZmVyIHRoYXQgdGhpcyBkcmFmdCBzcGVjaWZ5IHNvbWUgc29ydCBv
ZiBvYmplY3RpdmU8L2Rpdj4NCjxkaXY+bWV0cmljIGZvciBkZXRlcm1pbmluZyB0aGUgc29sdXRp
b24gYXBwbGljYWJpbGl0eS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwv
ZGl2Pg0KPGRpdj5BbmR5PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs
YXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFdlZCwg
RGVjIDE2LCAyMDE1IGF0IDQ6MTAgUE0sIE5hZGVhdSBUaG9tYXMgPHNwYW4gZGlyPSJsdHIiPg0K
Jmx0OzxhIGhyZWY9Im1haWx0bzp0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbSIgdGFyZ2V0PSJfYmxh
bmsiPnRuYWRlYXVAbHVjaWR2aXNpb24uY29tPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxi
bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2Jv
cmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGJyPg0KJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoaXMgaXMgYSBXRyBMYXN0IENhbGwgb24gZHJhZnQtaWV0
Zi1uZXRtb2Qtb3BzdGF0ZS1yZXFzLTAxLjxicj4NClBsZWFzZSBwb3N0IGNvbW1lbnRzIG9uIHRo
aXMgZHJhZnQgYnkgV2VkbmVzZGF5LCBEZWNlbWJlciAzMCwgMjAxNTxicj4NCmF0IDlBTSBFU1Qu
PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRvbS9LZW50PGJyPg0KPGJy
Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRm
Lm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2Js
YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48YnI+
DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv
c3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_02367647696D4BA881FA15CB95D5DBDAjunipernet_--


From nobody Wed Dec 16 19:13:01 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3321A92F4 for ; Wed, 16 Dec 2015 19:13:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 zrL_EAbHzpN9 for ; Wed, 16 Dec 2015 19:12:58 -0800 (PST)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 180561A8839 for ; Wed, 16 Dec 2015 19:12:58 -0800 (PST)
Received: by mail-lf0-x233.google.com with SMTP id y184so42898508lfc.1 for ; Wed, 16 Dec 2015 19:12:57 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=7Hhb+EnS6lffY0DLQ5/vTrSk2jwuAvgWH8+kiA93EGc=; b=0tiRDsqX6RdFvqlkqqKdkreuP74Q4O0GpQiYzqCpHzB8iMPKW1QDpHV7+kM9m6bfOQ +i18f+06iRztQTouDu9naAsBRJuQH/sqdqVJVPJFQyClrBKQ1kCEaDCAbgxBjqaWx5fI H70HKkmvdV7YbONw7xW9CllDJX2OMJCTjakrL6ubSPlyjVeKMrHTFSFu3Z/oZakQjzPT s5Rs8LfWXxWwj/ftPTQrXtZkvMPUxwADPXCDTZsyW8U/NCZQ3ymdxoSNOXCzexyHbTtH o2omvAUEGdNcoYz8nbCHfTaW8Kf4MO8cF4OB4FTJBDZFW94WlWxYFKmui8+SqwziZuVo QyOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=7Hhb+EnS6lffY0DLQ5/vTrSk2jwuAvgWH8+kiA93EGc=; b=Y4/GiqqyDO38VBguYPT5rPswxcCVPSZkXWY0JtBzQN6IZFPXqv8NjL+Q8cyhTDe2Nv mzoZA1vfGSJNuqwxZZq+c5FdvXerXbP71mGAdUgcTWmvisEsAwtwwdrTSeqFMHpI82H2 SAqfrKi09k41n6dGZIxU/lmqHpOAAhaX9ZA9lRUp97sE0QVuqr6mGFsRLKKx1U6pauuI nCYJ3r99zJhinzIS9wTMwT+bwZb2VF+PJMKIA4MzHyI2hkQ3F9oJQBr1PBnQt3RKelg+ bRYFZ0QOau91x98X1BACrfiSSw5SRvTPl1yMjDX5+xGb1nLyE1Gluc7Tp2xnJSpPuz6X AZtQ==
X-Gm-Message-State: ALoCoQmdrkck4DTPx2GrTh/tf0fgqC24sEiZ1DAfw6hHRP2jkPp4Y1KDqtVh9rxkpBjtTYvFmANldjJV49igkNdmihDt/1DJmA==
MIME-Version: 1.0
X-Received: by 10.25.64.9 with SMTP id n9mr7174714lfa.13.1450321976195; Wed, 16 Dec 2015 19:12:56 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Wed, 16 Dec 2015 19:12:56 -0800 (PST)
In-Reply-To: <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net>
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net>
Date: Wed, 16 Dec 2015 19:12:56 -0800
Message-ID: 
From: Andy Bierman 
To: Kent Watsen 
Content-Type: multipart/alternative; boundary=001a113ea4f633988005270f6623
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 03:13:00 -0000

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

On Wed, Dec 16, 2015 at 6:18 PM, Kent Watsen  wrote:

>
> [as a contributor]
>
> Hi Andy,
>
> I=E2=80=99m struggling a bit to understand what is motivating you to ask =
this
> question.    That is, as a tool vendor, I wouldn=E2=80=99t think that any=
 decision
> made here would affect you immediately.   My expectations are that any
> impact to YANG/NETCONF/RESTCONF would be backwards compatible, such that
> implementations would only opt-in when needed - a pay as you grow strateg=
y.
>   But herein perhaps lies an unstated requirement, that the impact to
> YANG/NETCONF/RESTCONF needs to be backwards compatible with respect to
> existing deployments.  Did we miss it or is it too obvious?
>
> I agree that supporting these requirements will be unnecessary for many
> platforms.  After all, we=E2=80=99ve gone decades without needing such vi=
sibility,
> and that=E2=80=99s not going to change for many platforms for some time, =
if ever.
>
> You ask for objective metrics for determining solution applicability.  My
> thinking is to just let the market decide - is it not good enough?   If I
> tried to quantify it, I might say that its only useful for networking
> devices (as their operational state somehow matters more?) and that it=E2=
=80=99s
> only useful when there is no guarantee that the intended config will beco=
me
> operational (i.e. applied) in some bounded amount of time.   Just throwin=
g
> out ideas here, but I like best letting the market decide.
>
>

There seemed to be agreement that most devices will apply intended config
within 5 seconds (not counting the 'waiting for line card' corner-case).
We usually see exec. times way under 1 sec., but if others are having
a problem with delays, I guess they will find this work useful.



> Kent
>


Andy


>
>
> From: netmod  on behalf of Andy Bierman <
> andy@yumaworks.com>
> Date: Wednesday, December 16, 2015 at 7:21 PM
> To: Thomas Nadeau 
> Cc: "netmod-chairs@tools.ietf.org" , "
> netmod@ietf.org" 
> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>
> Hi,
>
> I have asked repeatedly for some indication of scope in these requirement=
s.
> There is an assumption all possible YANG-based platforms have intended
> and applied state that can be different for a long enough interval such
> that retrieving
> the differences is operationally useful.
>
> For devices that converge in milli-seconds or even as long as 5 seconds,
> I do not see the point of implementing solutions for these requirements.
> I would prefer that this draft specify some sort of objective
> metric for determining the solution applicability.
>
>
> Andy
>
>
> On Wed, Dec 16, 2015 at 4:10 PM, Nadeau Thomas 
> wrote:
>
>>
>>         This is a WG Last Call on draft-ietf-netmod-opstate-reqs-01.
>> Please post comments on this draft by Wednesday, December 30, 2015
>> at 9AM EST.
>>
>>         Tom/Kent
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>

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




On Wed, Dec 16, 2015 at 6:18 PM, Kent Watsen <kwatsen@juniper.net> wrote:














[as a contributor]







Hi Andy,







I=E2=80=99m struggling a bit to understand what is motivating you to a=
sk this question. =C2=A0 =C2=A0That is, as a tool vendor, I wouldn=E2=80=99=
t think that any decision made here would affect you immediately. =C2=A0 My=
 expectations are that any impact to YANG/NETCONF/RESTCONF would
 be backwards compatible, such that implementations would only opt-in when =
needed - a pay as you grow strategy. =C2=A0 But herein perhaps lies an unst=
ated requirement, that the impact to YANG/NETCONF/RESTCONF needs to be back=
wards compatible with respect to existing
 deployments.=C2=A0 Did we miss it or is it too obvious?







I agree that supporting these requirements will be unnecessary for man=
y platforms.=C2=A0 After all, we=E2=80=99ve gone decades without needing su=
ch visibility, and that=E2=80=99s not going to change for many platforms fo=
r some time, if ever.







You ask for objective metrics for determining solution applicability.=
=C2=A0 My thinking is to just let the market decide - is it not good enough=
? =C2=A0 If I tried to quantify it, I might say that its only useful for ne=
tworking devices (as their operational state
 somehow matters more?) and that it=E2=80=99s only useful when there is no =
guarantee that the intended config will become operational (i.e. applied) i=
n some bounded amount of time. =C2=A0 Just throwing out ideas here, but I l=
ike best letting the market decide.





=
There seemed to be agreement that most devices will apply intended config
within 5 seconds (not counting the 'waiting for line card'=
 corner-case).
We usually see exec. times way under 1 sec., but i=
f others are having
a problem with delays, I guess they will find=
 this work useful.

=C2=A0




Kent


=
Andy
=C2=A0































Hi,






I have asked repeatedly for some indication of scope in these requirem=
ents.


There is an assumption all possible YANG-based platforms have intended=



and applied state that can be different for a long enough interval suc=
h that retrieving


the differences is operationally useful.







For devices that converge in milli-seconds or even as long as 5 second=
s,


I do not see the point of implementing solutions for these requirement=
s.


I would prefer that this draft specify some sort of objective


metric for determining the solution applicability.












Andy












On Wed, Dec 16, 2015 at 4:10 PM, Nadeau Thomas <=
span dir=3D"ltr">
<tnadeau@lu=
cidvision.com> wrote:





=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is a WG Last Call on draft-ietf-netmod-ops=
tate-reqs-01.

Please post comments on this draft by Wednesday, December 30, 2015

at 9AM EST.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Tom/Kent





_______________________________________________

netmod mailing list

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





















--001a113ea4f633988005270f6623--


From nobody Wed Dec 16 21:59:38 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED5D1ACEDA for ; Wed, 16 Dec 2015 21:59:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level: 
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 FAd2-T9LTIso for ; Wed, 16 Dec 2015 21:59:35 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B8751ACED9 for ; Wed, 16 Dec 2015 21:59:35 -0800 (PST)
Received: from [IPv6:2a01:5e0:29:ffff:f45e:2e30:90c6:2d42] (unknown [IPv6:2a01:5e0:29:ffff:f45e:2e30:90c6:2d42]) by mail.nic.cz (Postfix) with ESMTPSA id 23C3E18180F; Thu, 17 Dec 2015 06:59:34 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450331974; bh=Tgg6vCmCvU2/5CbOl2TjEAxRBjfk9jo15/TIhQk5nLA=; h=From:Date:To; b=HejN2gyzwzlQMqhSZrCZx2rTpuBTDc5IJPYLeT9ac9110L3NtTxqphtTraG8m+jDD BsPq291/8e3eKuUouFOWgE75RaQrIYA6671vcQDendhZODee6sbJkxUDguiL4bODq9 MX6nNshwnAuvtE01N5eYKDSTsN10GzFH5OTy3APs=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <20151216.180818.925309370580470112.mbj@tail-f.com>
Date: Thu, 17 Dec 2015 06:59:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:    <20151216.180818.925309370580470112.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Guidance on list vs. container of list
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 05:59:38 -0000

> On 16 Dec 2015, at 18:08, Martin Bjorklund  wrote:
>=20
> Anees Shaikh  wrote:
>> I'm not suggesting this is necessarily standard behavior :-)
>=20
> I think this demonstrates that it is probably not a good idea to
> design (standard) data models to optimize for a single protocol /
> implementation.  For NETCONF, the problem is clearly in the protocol,
> and it should be fixed in the protocol (Andy already showed a
> solution).

Agreed. This deficiency also blocks the introduction of keyless config =
lists that several people requested.

>=20
> Going back to the original question, I don't think there's a single
> rule to be used.  Sometimes the additional container makes sense, but
> in some cases (normally further down in the hierarchy, for "smaller"
> lists) it just adds noise.

Also, it is usually a good idea to use a wrapper container for =
user-ordered lists.

Lada

>=20
>=20
> /martin
>=20
>=20
> , but some
>> major implementations behave this way (it could be useful in some
>> circumstances) -- on those platforms, the enclosing container makes a
>> request for the whole list arguably less ambiguous.
>>=20
>> thanks.
>> -- Anees
>>=20
>> On Wed, Dec 16, 2015 at 8:48 AM, Christian Hopps  =
wrote:
>>=20
>>>=20
>>> Anees Shaikh  writes:
>>>=20
>>> hi Chris, in OpenConfig models we use enclosing containers on lists =
based
>>>> on feedback from some implementors who claimed that it made it more
>>>> efficient to, for example, retrieve the entire list (ask for the
>>>> container), retrieve the keys in the list (ask for the list node), =
or
>>>> retrieve a particular element of the list (specify the key).
>>>>=20
>>>=20
>>> But, I don't think asking for the list node returns only keys, I =
think it
>>> returns the entire content of the node, i.e., it's equivalent to =
asking for
>>> the out container if that container only contains a single list (the =
model
>>> in question here).
>>> Thanks,
>>> Chris.
>>>=20
>>>=20
>>> Aside from some stuttering in the paths (which can be a little =
annoying
>>>> but I don't expect to write the config instances by hand), there =
didn't
>>>> seem to be a major downside.  So we try to be consistent across the =
models
>>>> with this approach.  After getting some more experience with the
>>>> implementations, we might revisit.
>>>>=20
>>>> thanks.  -- Anees
>>>>=20
>>>> On Mon, Dec 14, 2015 at 6:30 PM, Andy Bierman  =
wrote:
>>>>=20
>>>> Hi,
>>>>>=20
>>>>> Use of NP-containers are subjective, based on how you want to =
organize
>>>>> your data.  The extra layer of containment may be a waste, but it =
sometimes
>>>>> has a purpose
>>>>>=20
>>>>>  - 2 or more sibling lists with lots of entries can be mixed   in
>>>>> JSON,     so putting each list in its container prevents that.  - =
There is
>>>>> no standard way to 'delete-all' in NETCONF or  RESTCONF     but a =
'replace'
>>>>> on the parent container can be used for     this purpose.  =
(container of
>>>>> list or leaf-list)  - container servers as a conceptual 'root' for
>>>>> external  augments
>>>>>=20
>>>>> Andy
>>>>>=20
>>>>>=20
>>>>> On Mon, Dec 14, 2015 at 5:56 PM, Christian Hopps =

>>>>> wrote:
>>>>>=20
>>>>>=20
>>>>>> Some models seem to place a single list of things inside a =
container
>>>>>> also named after the items in the list, e.g.,
>>>>>>=20
>>>>>> +--ro modulename   +--rw ribs      +--rw rib* [name]         =
+--rw name
>>>>>> I don't see the purpose of these containers. It seems to me that =
one can
>>>>>> model and query the exact same data without the outer container. =
That is,
>>>>>>=20
>>>>>> +--ro modulename   +--rw rib* [name]      +--rw name Is there =
something
>>>>>> useful about these containers that I've missed, as it's a fairly =
common
>>>>>> pattern in the models I've been looking at.   Example comparisons =
below..
>>>>>> Thanks, Chris.
>>>>>>=20
>>>>>>=20
>>>>>> w/ container:                  
>>>>>> foo            bar        =
 ...
>>>>>>   w/o container:          
>>>>>> foo        bar       =
...
>>>>>>  Likewise if you want to fetch all ribs you can =
either way:
>>>>>>=20
>>>>>>                       
>>>>>>  or
>>>>>>=20
>>>>>>                       
>>>>>>  Or a particular rib
>>>>>>=20
>>>>>>                           
>>>>>> foo                        =

>>>>>>  or
>>>>>>=20
>>>>>>                           =
foo
>>>>>>               Using xpath:
>>>>>>=20
>>>>>>   /modulename/ribs/rib[name=3D'foo'] or
>>>>>>=20
>>>>>>   /modulename/rib[name=3D'foo']
>>>>>>=20
>>>>>> _______________________________________________ netmod mailing =
list
>>>>>> netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>> _______________________________________________ netmod mailing =
list
>>>>> netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
>>>>>=20
>>>>>=20
>>>>>=20
>>>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed Dec 16 22:09:07 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B121ACF18 for ; Wed, 16 Dec 2015 22:09:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 cN1YrX-iGhIf for ; Wed, 16 Dec 2015 22:09:04 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39E8C1ACF17 for ; Wed, 16 Dec 2015 22:09:03 -0800 (PST)
Received: from [IPv6:2a01:5e0:29:ffff:f45e:2e30:90c6:2d42] (unknown [IPv6:2a01:5e0:29:ffff:f45e:2e30:90c6:2d42]) by mail.nic.cz (Postfix) with ESMTPSA id EA386181255; Thu, 17 Dec 2015 07:09:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450332541; bh=fau1MvMNNZy9ktJ/BfU93dsgTiHFjI7HpkYi054f9ug=; h=From:Date:To; b=VwiMI+8n9rbP215ksC+9bwJA/oT00q4Jgm5mJeEFfrhiLTsMlQiSxaX/i7n8WKUYU mwagSptBYfhr1ULf0Sa7LJgoJqjtjexuMhSd4tMxBmcLo+YtEKgHDmh3qZGbH4OQPd SShnJXQIyVeEjPVnfcpqUSuXr0KUcze4XmmsvfHk=
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_12BF82AE-70D5-4C10-876F-036719C2DE0E"; protocol="application/pgp-signature"; micalg=pgp-sha1
X-Pgp-Agent: GPGMail 2.6b2
From: Ladislav Lhotka 
In-Reply-To: 
Date: Thu, 17 Dec 2015 07:09:00 +0100
Message-Id: 
References:   
To: Christian Hopps 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Guidance on list vs. container of list
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 06:09:06 -0000

--Apple-Mail=_12BF82AE-70D5-4C10-876F-036719C2DE0E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On 16 Dec 2015, at 18:04, Christian Hopps  wrote:
>=20
>=20
> Andy Bierman  writes:
>=20
>> Hi,
>>=20
>> Use of NP-containers are subjective, based on how you want to =
organize your data.  The extra layer of containment may be a waste, but =
it sometimes has a purpose
>>=20
>>  - 2 or more sibling lists with lots of entries can be mixed in   =
JSON,     so putting each list in its container prevents that.
> Did you mean XML here (Lada indicated it's not the case with JSON)? I =
was curious if mixing like this was allowed in XML case (whether items =
from 2 different lists or even sibling leafs). I was hoping that once a =
list started in the XML all items in the list would be present before =
other items outside the list. If what your saying applies to XML then =
one would have to iterate all sibling nodes in

The possibility of (leaf-)list entries being interleaved with other =
sibling XML elements is explicitly mentioned in RFC 6020 (sec. 7.7.6 and =
7.8.5). This shouldn't come as a surprise because XML has no notion of =
lists.

>  the containing node to collect the list. This would seem to be the =
case even with sibling leafs in the model. I find this a bit surprising, =
and would expect bugs in implementation if so. :)
>> - container servers as a conceptual 'root' for external  augments
> This might be useful in some cases, probably not a reason to always =
include a container wrapper though.
>> - There is no standard way to 'delete-all' in NETCONF or  RESTCONF    =
 but a 'replace' on the parent container can be used for this     =
purpose.  (container of list or leaf-list)
>=20
> This is an interesting use -- using a modeling technique to to get =
around missing functionality in the protocol (hello opstate! :)
> Seriously though, should we consider adding delete-all functionality =
then?

Absolutely.

Lada

>=20
> Thanks, Chris.
>=20
>> Andy
>>=20
>>=20
>> On Mon, Dec 14, 2015 at 5:56 PM, Christian Hopps  =
wrote:
>>=20
>>>=20
>>> Some models seem to place a single list of things inside a container =
also named after the items in the list, e.g.,
>>>=20
>>> +--ro modulename   +--rw ribs      +--rw rib* [name]         +--rw =
name I don't see the purpose of these containers. It seems to me that =
one can model and query the exact same data without the outer container. =
That is,
>>>=20
>>> +--ro modulename   +--rw rib* [name]      +--rw name Is there =
something useful about these containers that I've missed, as it's a =
fairly common pattern in the models I've been looking at.   Example =
comparisons below..  Thanks, Chris.
>>>=20
>>>=20
>>> w/ container:                      =
foo            bar         =
...   w/o container:                =
  foo        bar       ...    =
 Likewise if you want to fetch all ribs you can either way:
>>>=20
>>>                           =
 or
>>>=20
>>>                           =
 Or a particular rib
>>>=20
>>>                                       =
foo                            =
 or
>>>=20
>>>                           foo  =
                 Using xpath:
>>>=20
>>>   /modulename/ribs/rib[name=3D'foo'] or
>>>=20
>>>   /modulename/rib[name=3D'foo']
>>>=20
>>> _______________________________________________ netmod mailing list =
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
>>>=20
>>>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--Apple-Mail=_12BF82AE-70D5-4C10-876F-036719C2DE0E
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAlZyUX0ACgkQWQVCj+dOjAzDmwCfR2Y4AvKRzhFQMfa7S4fqfyzN
D6kAnRXC3t2qils8tEgi0OrKCqBuANdp
=eXTy
-----END PGP SIGNATURE-----

--Apple-Mail=_12BF82AE-70D5-4C10-876F-036719C2DE0E--


From nobody Wed Dec 16 23:17:36 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A6D1B2A5E for ; Wed, 16 Dec 2015 23:17:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 hXdvesCHDvbb for ; Wed, 16 Dec 2015 23:17:33 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797F21B2A5B for ; Wed, 16 Dec 2015 23:17:33 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9CD0388D; Thu, 17 Dec 2015 08:17:31 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id BeCJIjjZ1sZJ; Thu, 17 Dec 2015 08:17:31 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 17 Dec 2015 08:17:31 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id F389A20058; Thu, 17 Dec 2015 08:17:30 +0100 (CET)
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 P8LgxVXZALsG; Thu, 17 Dec 2015 08:17:30 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B6BA520055; Thu, 17 Dec 2015 08:17:29 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 423FB3940E62; Thu, 17 Dec 2015 08:17:29 +0100 (CET)
Date: Thu, 17 Dec 2015 08:17:28 +0100
From: Juergen Schoenwaelder 
To: Kent Watsen 
Message-ID: <20151217071728.GC67701@elstar.local>
Mail-Followup-To: Kent Watsen , Andy Bierman , netmod WG 
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net>
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: <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 07:17:35 -0000

On Thu, Dec 17, 2015 at 02:18:42AM +0000, Kent Watsen wrote:
> 
> [as a contributor]
> 
> Hi Andy,
> 
> I’m struggling a bit to understand what is motivating you to ask this question.    That is, as a tool vendor, I wouldn’t think that any decision made here would affect you immediately.   My expectations are that any impact to YANG/NETCONF/RESTCONF would be backwards compatible, such that implementations would only opt-in when needed - a pay as you grow strategy.   But herein perhaps lies an unstated requirement, that the impact to YANG/NETCONF/RESTCONF needs to be backwards compatible with respect to existing deployments.  Did we miss it or is it too obvious?
>

It may be obvious for many of us but for the sake of completeness I
prefer to have this backwards compatibility assumption explicitely
stated.

/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 Dec 16 23:42:15 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A621B2AA2 for ; Wed, 16 Dec 2015 23:42:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level: 
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 E2uFiMZ9R0vt for ; Wed, 16 Dec 2015 23:42:12 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04DFA1B2A9F for ; Wed, 16 Dec 2015 23:42:11 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:f865:8d25:9206:6dae] (unknown [IPv6:2001:718:1a02:1:f865:8d25:9206:6dae]) by mail.nic.cz (Postfix) with ESMTPSA id 2EB77181A66; Thu, 17 Dec 2015 08:42:10 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450338130; bh=gWIkwcdNA2Shk+USYYcsLgc29RzlLOsYuBSOO94XzWg=; h=From:Date:To; b=MWr9szvU7cxzyP7VgZFypsEde4jvPkDxTo249VzitX6tBPJ9oEqX66ABv6xBe7M46 kY95gcbLxgsCSsLCwmZjeNneB2zvzzYRIfdcpkqwNty5dVUySjsySmbGcRnbO3eK2d 1YJPvjwNbfWxouyCNVF9eoaDgc0aqDDBnYU0TBx4=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <20151217071728.GC67701@elstar.local>
Date: Thu, 17 Dec 2015 08:42:10 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz>
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 07:42:13 -0000

> On 17 Dec 2015, at 08:17, Juergen Schoenwaelder =
 wrote:
>=20
> On Thu, Dec 17, 2015 at 02:18:42AM +0000, Kent Watsen wrote:
>>=20
>> [as a contributor]
>>=20
>> Hi Andy,
>>=20
>> I=E2=80=99m struggling a bit to understand what is motivating you to =
ask this question.    That is, as a tool vendor, I wouldn=E2=80=99t =
think that any decision made here would affect you immediately.   My =
expectations are that any impact to YANG/NETCONF/RESTCONF would be =
backwards compatible, such that implementations would only opt-in when =
needed - a pay as you grow strategy.   But herein perhaps lies an =
unstated requirement, that the impact to YANG/NETCONF/RESTCONF needs to =
be backwards compatible with respect to existing deployments.  Did we =
miss it or is it too obvious?
>>=20
>=20
> It may be obvious for many of us but for the sake of completeness I
> prefer to have this backwards compatibility assumption explicitely
> stated.

+1

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Thu Dec 17 01:35:28 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5651A8749 for ; Thu, 17 Dec 2015 01:35:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 Js6FhMF07zlo for ; Thu, 17 Dec 2015 01:35:05 -0800 (PST)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFD71A8714 for ; Thu, 17 Dec 2015 01:34:48 -0800 (PST)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id D4D45C4175D1; Thu, 17 Dec 2015 10:34:47 +0100 (CET)
To: Martin Bjorklund 
References: <56718098.90703@mg-soft.si> <20151216.171829.2198076201177316023.mbj@tail-f.com> <56719A45.90608@mg-soft.com> <20151216.184702.2006246752868355276.mbj@tail-f.com>
From: Jernej Tuljak 
Message-ID: <567281B7.9090709@mg-soft.si>
Date: Thu, 17 Dec 2015 10:34:47 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <20151216.184702.2006246752868355276.mbj@tail-f.com>
Content-Type: multipart/alternative; boundary="------------090307040908080704040309"
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y02: context node
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 09:35:15 -0000

This is a multi-part message in MIME format.
--------------090307040908080704040309
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Martin Bjorklund je 16.12.2015 ob 18:47 napisal:
> Jernej Tuljak  wrote:
>> Dne 16.12.2015 ob 17:18 je Martin Bjorklund zapisal(a):
>>> Jernej Tuljak  wrote:
>>>> Ladislav Lhotka je 16.12.2015 ob 15:10 napisal:
>>>>>> On 16 Dec 2015, at 14:08, Jernej Tuljak  wrote:
>>>>>>
>>>>>> Martin Bjorklund je 16.12.2015 ob 13:48 napisal:
>>>>>>> Jernej Tuljak  wrote:
>>>>>>>> Martin Bjorklund je 25.11.2015 ob 11:16 napisal:
>>>>>>>>> Ladislav Lhotka  wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I'd like to resolve this issue. Here is a complete example (valid, I
>>>>>>>>>> believe):
>>>>>>>>>>
>>>>>>>>>> module context {
>>>>>>>>>>       namespace "http://example.com/context";
>>>>>>>>>>       prefix ctx;
>>>>>>>>>>
>>>>>>>>>>       leaf foo {
>>>>>>>>>>         config false;
>>>>>>>>>>         type uint32;
>>>>>>>>>>       }
>>>>>>>>>>       rpc oper {
>>>>>>>>>>         output {
>>>>>>>>>>           must "/foo mod foo = 0";
>>>>>>>>>>           leaf foo {
>>>>>>>>>>             type uint32;
>>>>>>>>>>           }
>>>>>>>>>>         }
>>>>>>>>>>       }
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> 1. What does the accessible tree look like?
>>>>>>>>> Note that the anser to this depends on the outcomne of Y04.  Andy has
>>>>>>>>> strong objections to Y04-02, and proposed Y04-04 instead.
>>>>>>>>>
>>>>>>>>> Assuming Y04-02, and assuming /foo has the value 20 and the oper rpc's
>>>>>>>>> result has foo = 10, the accessible tree would look like this:
>>>>>>>>>
>>>>>>>>>        
>>>>>>>>>          +-- oper
>>>>>>>>>          |   +-- foo = 10
>>>>>>>>>          +-- foo = 20
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> (If we instead move back to Y04-04, the accessible tree would be:
>>>>>>>>>
>>>>>>>>>        
>>>>>>>>>          +-- oper
>>>>>>>>>              +-- foo = 10
>>>>>>>>>
>>>>>>>>> )
>>>>>>>>>
>>>>>>>>>> 2. What is the context node for the "must" expression?
>>>>>>>>>      /oper
>>>>>>>> This change to the accessible tree (1.0 --> 1.1) may break some
>>>>>>>> existing "when" XPath expressions (those under "output" statement).
>>>>>>> Maybe.  The old text said:
>>>>>>>
>>>>>>>       o  If the context node represents RPC output parameters, the tree is
>>>>>>>          the RPC reply instance document.
>>>>>>>
>>>>>>> So this probably meant that for this definition:
>>>>>>>
>>>>>>>      module ex {
>>>>>>>        ...
>>>>>>>        prefix x;
>>>>>>>        ...
>>>>>>>        rpc foo {
>>>>>>>          output {
>>>>>>>            leaf bar { ... }
>>>>>>>          }
>>>>>>>        }
>>>>>>>      }
>>>>>>>
>>>>>>> The accessile tree was:
>>>>>>>
>>>>>>>       nc:rpc-reply
>>>>>>>         +-- x:bar
>>>>>>>
>>>>>>> This is very NETCONF-specifc.  With 1.1, the tree would be:
>>>>>>>
>>>>>>>       x:foo
>>>>>>>         +-- x:bar
>>>>>>>
>>>>>>> which is protocol-neutral.
>>>>>>>
>>>>>>>> Is
>>>>>>>> this compatible with 1.1 charter - "All compliant YANG 1.0 modules
>>>>>>>> must be accepted as compliant YANG 1.1 modules"?
>>>>>>>>
>>>>>>>>      rpc my-rpc {
>>>>>>>>        output {
>>>>>>>>          uses my-stuff {
>>>>>>>>            when "specific-param = 'foo'";// 1.0
>>>>>>>> // when "my-rpc/specific-param = 'foo'" // 1.1
>>>>>>> This is not correct.  If a relative path is used, it would be the same
>>>>>>> in 1.0 and 1.1.
>>>>>> I disagree due to current text:
>>>>>>
>>>>>>      o  data node: A node in the schema tree that can be instantiated in a
>>>>>>         data tree.  One of container, leaf, leaf-list, list, anydata, and
>>>>>>         anyxml.
>>>>>>
>>>>>>      o  If the XPath expression is defined in a substatement to an
>>>>>>         "output" statement in an "rpc" or "action" statement, the
>>>>>>         accessible tree is the RPC or action operation instance, all state
>>>>>>         data in the server, and the running configuration datastore.  The
>>>>>>         root node has top-level data nodes in all modules as children.
>>>>>>         Additionally, for an RPC, the root node also has the node
>>>>>>         representing the RPC operation being defined as a child.  The node
>>>>>>         representing the operation being defined has the operation's
>>>>>>         output parameters as children.
>>>>>>
>>>>>>      o  If the "when" statement is a child of a "uses", "choice", or
>>>>>>         "case" statement, then the context node is the closest ancestor
>>>>>>         node to the "uses", "choice", or "case" node that is also a data
>>>>>>         node.  If no such node exists, the context node is the root node.
>>>>>>         The accessible tree is tentatively altered during the processing
>>>>>>         of the XPath expression by removing all instances (if any) of the
>>>>>>         nodes added by the "uses", "choice", or "case" statement.
>>>>>>
>>>>>>
>>>>>> It clearly says that the context node is the root node ("/"), not the
>>>>>> node representing the RPC ("/my-rpc"), which is a child to root
>>>>>> node. The "root node" aka "document root" can only mean a single thing
>>>>>> XPath terminology.
>>>>> RFC 6020 clearly says that the tree is the rpc reply instance
>>>>> document, so it is a different document whose root node coincides with
>>>>> . The problem of 6020bis is that we need a definition
>>>>> that's independent of XML, and that's not so easy, but I agree with
>>>>> Martin that nothing should change for relative paths.
>>>> I'm not against the new accessible tree. That nothing should change
>>>> for relative paths is a given, IMO. So what about absolute location
>>>> paths?
>>>>
>>>> The previous accessible tree for a "when" expression under "output"
>>>> was:
>>>>
>>>> 
>>>>     +- x:bar
>>> No it was:
>>>
>>>     
>>>       +-- nc:rpc-reply
>>>         +- x:bar
>>>
>>>> and now it is:
>>>>
>>>> 
>>>>     +- x:foo
>>>>       +- x:bar
>>>>
>>>> The absolute path to "x:bar" was:
>>>>
>>>> /x:bar
>>> /nc:rpc-reply/x:bar
>> No. How do you explain the different wording for "input" when compared
>> to "output" (6020, 7.19.5):
>>
>>     o  If the context node represents RPC input parameters, the tree is
>>        the RPC XML instance document.  The XPath root node has the
>>        element representing the RPC operation being defined as the only
>>        child.
>>
>>     o  If the context node represents RPC output parameters, the tree is
>>        the RPC reply instance document.  The XPath root node has the
>>        elements representing the RPC output parameters as children.
>>
>> "XPath root node has the _element_ representing the RPC operation as
>> the _only child_" vs. "XPath root node has the _elements_ representing
>> the RPC output as _children_".
>>
>> This is different from what 6020bis-09 is saying. The latter
>> "equalized" accessible trees for "input" and "output". What I am
>> asking is whether this confilcts with 1.1 charter.
> You're right, but the entire thing is underspecifed in 6020.  In the
> example you had:
>
>    rpc foo {
>      output {
>        uses my-stuff {
>          when "...";
>        }
>      }
>    }
>
> and if you go by 6020, there is no context node for the when
> expression, and the accessible tree is defined in terms of the context
> node.
>
> Yes this is different in 1.1, but I think we're specifying rules for
> something that wasn't specified, and fix inconsistencies.
>
>> You could never refer to "nc:rpc-reply" as anything other that the
>> document root in 1.0 ("/") . You could never refer to "nc:rpc" either,
>> only to "x:foo".
> It depends on how you interpret the words: "the tree is the RPC reply
> instance document."

There is no room for misinterpreting what an XPath root node is (next 
sentence). Even if the processing is actually done on an RPC reply 
instance document, an RPC instance document or a notification instance 
document, "nc:rpc-reply", "nc:rpc" and "ncEvent:notification" are simply 
not part of the YANG XPath model as anything else than a root node ("/") 
and they never were. The QNames previously listed do not exist in this 
model.

>
>>>> and is now:
>>>>
>>>> /x:foo/x:bar
>>>>
>>>> and this needs to be taken into account for at least relative paths to
>>>> stay the same. Again, the root node is "/" in any case. So the context
>>>> node needs to be set explicitly "/x:foo" for this corner case. I dare
>>>> say it is not even a corner case. There is a similar YANG pattern to
>>>> my "my-rpc" example in ietf-netconf-notifications for a
>>>> "notification".
>>> I think what needs to be done is to clarify that the context node for
>>> when/must in input/output or uses in input/output is the node
>>> representing the rpc.  Note that this is unspecified in 6020.
>> True. It is unspecified. For notifications also, yet
>> ietf-netconf-notifications practices it.
> It just uses relative paths, in places where the context node is
> well-defined.

The specific definition I had in mind is netconf-confirmed-commit 
"notification" (trimmed):

   notification netconf-confirmed-commit {
     uses common-session-parms {
       when "confirm-event != 'timeout'";
     }
   }

The context node for this "when" is as unspecified as in my original 
example for "output" per 6020 (no data node ancestor to "uses"). And in 
6020bis-09 the context node now defaults to root node (not root/document 
element)! So if I take ietf-netconf-notifications@2012-02-06 and add a 
"yang-version 1.1;" to it, the module will break.
Furthermore the absolute XPath location path for confirm-event node is 
"/ncn:netconf-confirmed-commit/ncn:confirm-event", not 
"/ncEvent:notification/ncn:netconf-confirmed-commit/ncn:confirm-event", 
which is what you seem to be saying. If this is what the intention was, 
several errata need to be posted for 6020. We implement the 1.0 
accessible tree the way I have been describing, and yes, we do implement 
absolute location paths.

XPATH, 5.1 (http://www.w3.org/TR/1999/REC-xpath-19991116/#data-model):
The root node is the root of the tree. A root node does not occur except 
as the root of the tree. The element node for the document element is a 
child of the root node.

6020:

    The data model used in the XPath expressions is the same as that used
    in XPath 1.0 [XPATH], with the same extension for root node children
    as used by XSLT 1.0 [XSLT] (Section 3.1).  Specifically, it means
    that the root node may have any number of element nodes as its
    children.

    o  data node: A node in the schema tree that can be instantiated in a
       data tree.  One of container, leaf, leaf-list, list, and anyxml.

    o  If the "when" statement is a child of a "uses", "choice", or
       "case" statement, then the context node is the closest ancestor
       node to the "uses", "choice", or "case" node that is also a data
       node.

    o  If the context node represents notification content, the tree is
       the notification XML instance document.  The XPath root node has
       the element representing the notification being defined as the
       only child.

6020bis-09:

    The data model used in the XPath expressions is the same as that used
    in XPath 1.0 [XPATH], with the same extension for root node children
    as used by XSLT 1.0 [XSLT] (Section 3.1).  Specifically, it means
    that the root node may have any number of element nodes as its
    children.

    o  data node: A node in the schema tree that can be instantiated in a
       data tree.  One of container, leaf, leaf-list, list, anydata, and
       anyxml.

    o  If the XPath expression is defined in a substatement to a
       "notification" statement, the accessible tree is the notification
       instance, all state data in the server, and the running
       configuration datastore.  If the notification is defined on the
       top-level in a module, then the root node has the node
       representing the notification being defined and all top-level data
       nodes in all modules as children.  Otherwise, the root node has
       all top-level data nodes in all modules as children.

    o  If the "when" statement is a child of a "uses", "choice", or
       "case" statement, then the context node is the closest ancestor
       node to the "uses", "choice", or "case" node that is also a data
       node.  If no such node exists, the context node is the root node.
       The accessible tree is tentatively altered during the processing
       of the XPath expression by removing all instances (if any) of the
       nodes added by the "uses", "choice", or "case" statement.


I hope this clarifies what my previous email was saying about 
ietf-netconf-notifications. The accessible tree for "output" is a 
different issue.

(PS: I've been having trouble replying to the mailing list ever since we 
migrated our mail server which is why my previous message was not sent 
to the mailing list and Martin seemed to be replying to thin air.)

Jernej

>
>
> /martin
>
>
>
>> Jernej
>>
>>> /martin
>>>
>>>
>>>
>>>> Jernej
>>>>
>>>>> Lada
>>>>>
>>>>>> Jernej
>>>>>>
>>>>>>> If an absolute path is used, it would be:
>>>>>>>
>>>>>>>       when "/nc:rpc-reply/x:specific-param = 'foo'"; // 1.0
>>>>>>>       when "/x:my-rpc/x:specific-param = 'foo'";     // 1.1
>>>>>>>
>>>>>>>
>>>>>>> I wonder if any implementation of 1.0 supports this absolute form.
>>>>>>>
>>>>>>>
>>>>>>> /martin
>>>>>>>
>>>>>>>
>>>>>>>>          }
>>>>>>>>          leaf specific-param {
>>>>>>>>            type string;
>>>>>>>>          }
>>>>>>>>        }
>>>>>>>>      }
>>>>>>>>
>>>>>>>> Jernej
>>>>>>>>
>>>>>>>>> /martin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Thanks, Lada
>>>>>>>>>>
>>>>>>>>>> Martin Bjorklund  writes:
>>>>>>>>>>
>>>>>>>>>>> Ladislav Lhotka  wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> Y02-01 allows "must" as a substatement of "input", "output" and
>>>>>>>>>>>> "notification" but for these cases the specification of the context
>>>>>>>>>>>> node in sec. 7.5.3 doesn't work.
>>>>>>>>>>>>
>>>>>>>>>>>>        o The context node is the node in the accessible tree for
>>>>>>>>>>>>        which
>>>>>>>>>>>>        the
>>>>>>>>>>>>           "must" statement is defined.
>>>>>>>>>>> You are right.  But note how the accessible tree is defined.  There
>>>>>>>>>>> is
>>>>>>>>>>> a node for the operation / notification.  This node should be the
>>>>>>>>>>> context node:
>>>>>>>>>>>
>>>>>>>>>>>        o If the "must" statement is a substatement of a "notification"
>>>>>>>>>>>           statement, the context node is the node representing the
>>>>>>>>>>>           notification in the accessible tree.
>>>>>>>>>>>
>>>>>>>>>>>        o  If the "must" statement is a substatement of a "input"
>>>>>>>>>>>           statement, the context node is the node representing the
>>>>>>>>>>>           operation in the accessible tree.
>>>>>>>>>>>
>>>>>>>>>>>        o  If the "must" statement is a substatement of a "output"
>>>>>>>>>>>           statement, the context node is the node representing the
>>>>>>>>>>>           operation in the accessible tree.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> /martin
>>>>>>>>>> -- 
>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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, CZ.NIC Labs
>>>>> PGP Key ID: E74E8C0C
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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


--------------090307040908080704040309
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Martin Bjorklund je 16.12.2015 ob
      18:47 napisal:

    

    

      
Jernej Tuljak <jernej.tuljak@mg-soft.com> wrote:


      

        
Dne 16.12.2015 ob 17:18 je Martin Bjorklund zapisal(a):


        

          
Jernej Tuljak <jernejt@mg-soft.si> wrote:


          

            
Ladislav Lhotka je 16.12.2015 ob 15:10 napisal:


            

              

                
On 16 Dec 2015, at 14:08, Jernej Tuljak <jernejt@mg-soft.si> wrote:

Martin Bjorklund je 16.12.2015 ob 13:48 napisal:


                

                  
Jernej Tuljak <jernejt@mg-soft.si> wrote:


                  

                    
Martin Bjorklund je 25.11.2015 ob 11:16 napisal:


                    

                      
Ladislav Lhotka <lhotka@nic.cz> wrote:


                      

                        
Hi,

I'd like to resolve this issue. Here is a complete example (valid, I
believe):

module context {
     namespace "http://example.com/context";
     prefix ctx;

     leaf foo {
       config false;
       type uint32;
     }
     rpc oper {
       output {
         must "/foo mod foo = 0";
         leaf foo {
           type uint32;
         }
       }
     }
}

1. What does the accessible tree look like?


                      

                      
Note that the anser to this depends on the outcomne of Y04.  Andy has
strong objections to Y04-02, and proposed Y04-04 instead.

Assuming Y04-02, and assuming /foo has the value 20 and the oper rpc's
result has foo = 10, the accessible tree would look like this:

      <root>
        +-- oper
        |   +-- foo = 10
        +-- foo = 20


(If we instead move back to Y04-04, the accessible tree would be:

      <root>
        +-- oper
            +-- foo = 10

)



                      

                        
2. What is the context node for the "must" expression?


                      

                      
    /oper


                    

                    
This change to the accessible tree (1.0 --> 1.1) may break some
existing "when" XPath expressions (those under "output" statement).


                  

                  
Maybe.  The old text said:

     o  If the context node represents RPC output parameters, the tree is
        the RPC reply instance document.

So this probably meant that for this definition:

    module ex {
      ...
      prefix x;
      ...
      rpc foo {
        output {
          leaf bar { ... }
        }
      }
    }

The accessile tree was:

     nc:rpc-reply
       +-- x:bar

This is very NETCONF-specifc.  With 1.1, the tree would be:

     x:foo
       +-- x:bar

which is protocol-neutral.



                  

                    
Is
this compatible with 1.1 charter - "All compliant YANG 1.0 modules
must be accepted as compliant YANG 1.1 modules"?

    rpc my-rpc {
      output {
        uses my-stuff {
          when "specific-param = 'foo'";// 1.0
// when "my-rpc/specific-param = 'foo'" // 1.1


                  

                  
This is not correct.  If a relative path is used, it would be the same
in 1.0 and 1.1.


                

                
I disagree due to current text:

    o  data node: A node in the schema tree that can be instantiated in a
       data tree.  One of container, leaf, leaf-list, list, anydata, and
       anyxml.

    o  If the XPath expression is defined in a substatement to an
       "output" statement in an "rpc" or "action" statement, the
       accessible tree is the RPC or action operation instance, all state
       data in the server, and the running configuration datastore.  The
       root node has top-level data nodes in all modules as children.
       Additionally, for an RPC, the root node also has the node
       representing the RPC operation being defined as a child.  The node
       representing the operation being defined has the operation's
       output parameters as children.

    o  If the "when" statement is a child of a "uses", "choice", or
       "case" statement, then the context node is the closest ancestor
       node to the "uses", "choice", or "case" node that is also a data
       node.  If no such node exists, the context node is the root node.
       The accessible tree is tentatively altered during the processing
       of the XPath expression by removing all instances (if any) of the
       nodes added by the "uses", "choice", or "case" statement.


It clearly says that the context node is the root node ("/"), not the
node representing the RPC ("/my-rpc"), which is a child to root
node. The "root node" aka "document root" can only mean a single thing
XPath terminology.


              

              
RFC 6020 clearly says that the tree is the rpc reply instance
document, so it is a different document whose root node coincides with
<rpc-reply>. The problem of 6020bis is that we need a definition
that's independent of XML, and that's not so easy, but I agree with
Martin that nothing should change for relative paths.


            

            
I'm not against the new accessible tree. That nothing should change
for relative paths is a given, IMO. So what about absolute location
paths?

The previous accessible tree for a "when" expression under "output"
was:

<root>
   +- x:bar


          

          
No it was:

   <root>
     +-- nc:rpc-reply
       +- x:bar



          

            
and now it is:

<root>
   +- x:foo
     +- x:bar

The absolute path to "x:bar" was:

/x:bar


          

          
/nc:rpc-reply/x:bar


        

        
No. How do you explain the different wording for "input" when compared
to "output" (6020, 7.19.5):

   o  If the context node represents RPC input parameters, the tree is
      the RPC XML instance document.  The XPath root node has the
      element representing the RPC operation being defined as the only
      child.

   o  If the context node represents RPC output parameters, the tree is
      the RPC reply instance document.  The XPath root node has the
      elements representing the RPC output parameters as children.

"XPath root node has the _element_ representing the RPC operation as
the _only child_" vs. "XPath root node has the _elements_ representing
the RPC output as _children_".

This is different from what 6020bis-09 is saying. The latter
"equalized" accessible trees for "input" and "output". What I am
asking is whether this confilcts with 1.1 charter.


      

      
You're right, but the entire thing is underspecifed in 6020.  In the
example you had:

  rpc foo {
    output {
      uses my-stuff {
        when "...";
      }
    }
  }

and if you go by 6020, there is no context node for the when
expression, and the accessible tree is defined in terms of the context
node.

Yes this is different in 1.1, but I think we're specifying rules for
something that wasn't specified, and fix inconsistencies.



      

        
You could never refer to "nc:rpc-reply" as anything other that the
document root in 1.0 ("/") . You could never refer to "nc:rpc" either,
only to "x:foo".


      

      
It depends on how you interpret the words: "the tree is the RPC reply
instance document."

    

    

    There is no room for misinterpreting what an XPath root node is
    (next sentence). Even if the processing is actually done on an RPC
    reply instance document, an RPC instance document or a notification
    instance document, "nc:rpc-reply", "nc:rpc" and
    "ncEvent:notification" are simply not part of the YANG XPath model
    as anything else than a root node ("/") and they never were. The
    QNames previously listed do not exist in this model.

    

    

      



      

        

          

            
and is now:

/x:foo/x:bar

and this needs to be taken into account for at least relative paths to
stay the same. Again, the root node is "/" in any case. So the context
node needs to be set explicitly "/x:foo" for this corner case. I dare
say it is not even a corner case. There is a similar YANG pattern to
my "my-rpc" example in ietf-netconf-notifications for a
"notification".


          

          
I think what needs to be done is to clarify that the context node for
when/must in input/output or uses in input/output is the node
representing the rpc.  Note that this is unspecified in 6020.


        

        
True. It is unspecified. For notifications also, yet
ietf-netconf-notifications practices it.


      

      
It just uses relative paths, in places where the context node is
well-defined.

    

    

    The specific definition I had in mind is netconf-confirmed-commit
    "notification" (trimmed):

    
  notification netconf-confirmed-commit {
    uses common-session-parms {
      when "confirm-event != 'timeout'";
    }
  }


    The context node for this "when" is as unspecified as in my original
    example for "output" per 6020 (no data node ancestor to "uses"). And
    in 6020bis-09 the context node now defaults to root node (not
    root/document element)! So if I take
    ietf-netconf-notifications@2012-02-06 and add a "yang-version 1.1;"
    to it, the module will break.

    Furthermore the absolute XPath location path for confirm-event node
    is "/ncn:netconf-confirmed-commit/ncn:confirm-event", not
    "/ncEvent:notification/ncn:netconf-confirmed-commit/ncn:confirm-event",
    which is what you seem to be saying. If this is what the intention
    was, several errata need to be posted for 6020. We implement the 1.0
    accessible tree the way I have been describing, and yes, we do
    implement absolute location paths.

    

    XPATH, 5.1
    (http://www.w3.org/TR/1999/REC-xpath-19991116/#data-model):

    The root node is the root of the tree. A root node does not occur
    except as the root of the tree. The element node for the document
    element is a child of the root node.

    

    6020:

    
   The data model used in the XPath expressions is the same as that used
   in XPath 1.0 [XPATH], with the same extension for root node children
   as used by XSLT 1.0 [XSLT] (Section 3.1).  Specifically, it means
   that the root node may have any number of element nodes as its
   children.

   o  data node: A node in the schema tree that can be instantiated in a
      data tree.  One of container, leaf, leaf-list, list, and anyxml.

    
   o  If the "when" statement is a child of a "uses", "choice", or
      "case" statement, then the context node is the closest ancestor
      node to the "uses", "choice", or "case" node that is also a data
      node.

   o  If the context node represents notification content, the tree is
      the notification XML instance document.  The XPath root node has
      the element representing the notification being defined as the
      only child.


    6020bis-09:

    
   The data model used in the XPath expressions is the same as that used
   in XPath 1.0 [XPATH], with the same extension for root node children
   as used by XSLT 1.0 [XSLT] (Section 3.1).  Specifically, it means
   that the root node may have any number of element nodes as its
   children.

   o  data node: A node in the schema tree that can be instantiated in a
      data tree.  One of container, leaf, leaf-list, list, anydata, and
      anyxml.

   o  If the XPath expression is defined in a substatement to a
      "notification" statement, the accessible tree is the notification
      instance, all state data in the server, and the running
      configuration datastore.  If the notification is defined on the
      top-level in a module, then the root node has the node
      representing the notification being defined and all top-level data
      nodes in all modules as children.  Otherwise, the root node has
      all top-level data nodes in all modules as children.

   o  If the "when" statement is a child of a "uses", "choice", or
      "case" statement, then the context node is the closest ancestor
      node to the "uses", "choice", or "case" node that is also a data
      node.  If no such node exists, the context node is the root node.
      The accessible tree is tentatively altered during the processing
      of the XPath expression by removing all instances (if any) of the
      nodes added by the "uses", "choice", or "case" statement.

    

    I hope this clarifies what my previous email was saying about
    ietf-netconf-notifications. The accessible tree for "output" is a
    different issue.

    

    (PS: I've been having trouble replying to the mailing list ever
    since we migrated our mail server which is why my previous message
    was not sent to the mailing list and Martin seemed to be replying to
    thin air.)

    

    Jernej

    

    

      


/martin





      

        
Jernej



        

          
/martin





          

            
Jernej



            

              
Lada



              

                
Jernej



                

                  
If an absolute path is used, it would be:

     when "/nc:rpc-reply/x:specific-param = 'foo'"; // 1.0
     when "/x:my-rpc/x:specific-param = 'foo'";     // 1.1


I wonder if any implementation of 1.0 supports this absolute form.


/martin




                  

                    
        }
        leaf specific-param {
          type string;
        }
      }
    }

Jernej



                    

                      
/martin





                      

                        
Thanks, Lada

Martin Bjorklund <mbj@tail-f.com> writes:



                        

                          
Ladislav Lhotka <lhotka@nic.cz> wrote:


                          

                            
Hi,

Y02-01 allows "must" as a substatement of "input", "output" and
"notification" but for these cases the specification of the context
node in sec. 7.5.3 doesn't work.

      o The context node is the node in the accessible tree for
      which
      the
         "must" statement is defined.


                          

                          
You are right.  But note how the accessible tree is defined.  There
is
a node for the operation / notification.  This node should be the
context node:

      o If the "must" statement is a substatement of a "notification"
         statement, the context node is the node representing the
         notification in the accessible tree.

      o  If the "must" statement is a substatement of a "input"
         statement, the context node is the node representing the
         operation in the accessible tree.

      o  If the "must" statement is a substatement of a "output"
         statement, the context node is the node representing the
         operation in the accessible tree.


/martin


                        

                        
-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C



                      

                      
_______________________________________________
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, CZ.NIC Labs
PGP Key ID: E74E8C0C




_______________________________________________
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


        

        

      

    

    

  


--------------090307040908080704040309--


From nobody Thu Dec 17 04:07:46 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67A91A8A54 for ; Thu, 17 Dec 2015 04:07:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 mfT0H1Ot0vuw for ; Thu, 17 Dec 2015 04:07:40 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 EEFCB1B29C7 for ; Thu, 17 Dec 2015 04:07:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450354031; bh=Jw1oKP1QKA+TFGbZO527VmED0tFphrarjDWwePwfGMI=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=YGNhf3yb64MgLTFZ7OyDmNUYV/OpYoeybkhIYYK+KgayFRn7a14z4DRUSLhWVSI/t Ob50xtS62CyMKac4R0WCPGf7JNbrDrvn99yZbRQ/8fO79NCO+DlYvoOAmIHD3wxKAz rNbyO5LGoRtUxjZd4GTFWdgwlTpwrnEMgt0WSXmA=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: multipart/alternative; boundary="Apple-Mail=_4A8D7460-F85E-4E8C-A7E4-27830A57E2B7"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Nadeau Thomas 
In-Reply-To: 
Date: Thu, 17 Dec 2015 07:07:29 -0500
Message-Id: <0AB0D1F1-666B-4E14-87D3-09F344B38651@lucidvision.com>
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=1 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 216, in=2895, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: "netmod-chairs@tools.ietf.org" , netmod WG 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 12:07:45 -0000

--Apple-Mail=_4A8D7460-F85E-4E8C-A7E4-27830A57E2B7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


	As you know, after much discussion, the Co-chairs declared these =
requirements to be in scope and=20
having consensus to proceed forward at one of the recent interim =
meetings, and on the mailing list to confirm.

	=E2=80=94Tom


> On Dec 16, 2015:7:21 PM, at 7:21 PM, Andy Bierman  =
wrote:
>=20
> Hi,
>=20
> I have asked repeatedly for some indication of scope in these =
requirements.
> There is an assumption all possible YANG-based platforms have intended
> and applied state that can be different for a long enough interval =
such that retrieving
> the differences is operationally useful.
>=20
> For devices that converge in milli-seconds or even as long as 5 =
seconds,
> I do not see the point of implementing solutions for these =
requirements.
> I would prefer that this draft specify some sort of objective
> metric for determining the solution applicability.
>=20
>=20
> Andy
>=20
>=20
> On Wed, Dec 16, 2015 at 4:10 PM, Nadeau Thomas =
> wrote:
>=20
>         This is a WG Last Call on draft-ietf-netmod-opstate-reqs-01.
> Please post comments on this draft by Wednesday, December 30, 2015
> at 9AM EST.
>=20
>         Tom/Kent
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod =

>=20


--Apple-Mail=_4A8D7460-F85E-4E8C-A7E4-27830A57E2B7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



	As you =
know, after much discussion, the Co-chairs declared these requirements =
to be in scope and 
having consensus to proceed =
forward at one of the recent interim meetings, and on the mailing list =
to confirm.

	=
=E2=80=94Tom


On Dec 16, 2015:7:21 PM, at 7:21 PM, Andy Bierman <andy@yumaworks.com> =
wrote:

Hi,

I have asked repeatedly for some indication of scope in these =
requirements.
There is an assumption all possible =
YANG-based platforms have intended
and applied =
state that can be different for a long enough interval such that =
retrieving
the differences is operationally =
useful.

For =
devices that converge in milli-seconds or even as long as 5 =
seconds,
I do not see the point of implementing =
solutions for these requirements.
I would prefer =
that this draft specify some sort of objective
metric=
 for determining the solution applicability.


Andy


On Wed, =
Dec 16, 2015 at 4:10 PM, Nadeau Thomas <tnadeau@lucidvision.com> wrote:


        This is a WG Last Call on =
draft-ietf-netmod-opstate-reqs-01.

Please post comments on this draft by Wednesday, December 30, 2015

at 9AM EST.



        Tom/Kent





_______________________________________________

netmod mailing list

netmod@ietf.org

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






=

--Apple-Mail=_4A8D7460-F85E-4E8C-A7E4-27830A57E2B7--


From nobody Thu Dec 17 04:22:00 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88EBF1B2BD0 for ; Thu, 17 Dec 2015 04:21:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 AlnLUqn7cqSe for ; Thu, 17 Dec 2015 04:21:55 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id AE8E91B2BDB for ; Thu, 17 Dec 2015 04:21:54 -0800 (PST)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 9BCAC1AE035C; Thu, 17 Dec 2015 13:21:53 +0100 (CET)
Date: Thu, 17 Dec 2015 13:23:02 +0100 (CET)
Message-Id: <20151217.132302.647018113529105090.mbj@tail-f.com>
To: jernej.tuljak@mg-soft.si
From: Martin Bjorklund 
In-Reply-To: <567281B7.9090709@mg-soft.si>
References: <56719A45.90608@mg-soft.com> <20151216.184702.2006246752868355276.mbj@tail-f.com> <567281B7.9090709@mg-soft.si>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y02: context node
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 12:21:58 -0000

Jernej Tuljak  wrote:
> Martin Bjorklund je 16.12.2015 ob 18:47 napisal:
> > Jernej Tuljak  wrote:
> >> Dne 16.12.2015 ob 17:18 je Martin Bjorklund zapisal(a):
> >>> Jernej Tuljak  wrote:
> >>>> Ladislav Lhotka je 16.12.2015 ob 15:10 napisal:
> >>>>>> On 16 Dec 2015, at 14:08, Jernej Tuljak  wrote:
> >>>>>>
> >>>>>> Martin Bjorklund je 16.12.2015 ob 13:48 napisal:
> >>>>>>> Jernej Tuljak  wrote:
> >>>>>>>> Martin Bjorklund je 25.11.2015 ob 11:16 napisal:
> >>>>>>>>> Ladislav Lhotka  wrote:
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> I'd like to resolve this issue. Here is a complete example (valid, I
> >>>>>>>>>> believe):
> >>>>>>>>>>
> >>>>>>>>>> module context {
> >>>>>>>>>>       namespace "http://example.com/context";
> >>>>>>>>>>       prefix ctx;
> >>>>>>>>>>
> >>>>>>>>>>       leaf foo {
> >>>>>>>>>>         config false;
> >>>>>>>>>>         type uint32;
> >>>>>>>>>>       }
> >>>>>>>>>>       rpc oper {
> >>>>>>>>>>         output {
> >>>>>>>>>>           must "/foo mod foo = 0";
> >>>>>>>>>>           leaf foo {
> >>>>>>>>>>             type uint32;
> >>>>>>>>>>           }
> >>>>>>>>>>         }
> >>>>>>>>>>       }
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> 1. What does the accessible tree look like?
> >>>>>>>>> Note that the anser to this depends on the outcomne of Y04.  Andy has
> >>>>>>>>> strong objections to Y04-02, and proposed Y04-04 instead.
> >>>>>>>>>
> >>>>>>>>> Assuming Y04-02, and assuming /foo has the value 20 and the oper
> >>>>>>>>> rpc's
> >>>>>>>>> result has foo = 10, the accessible tree would look like this:
> >>>>>>>>>
> >>>>>>>>>        
> >>>>>>>>>          +-- oper
> >>>>>>>>>          |   +-- foo = 10
> >>>>>>>>>          +-- foo = 20
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> (If we instead move back to Y04-04, the accessible tree would be:
> >>>>>>>>>
> >>>>>>>>>        
> >>>>>>>>>          +-- oper
> >>>>>>>>>              +-- foo = 10
> >>>>>>>>>
> >>>>>>>>> )
> >>>>>>>>>
> >>>>>>>>>> 2. What is the context node for the "must" expression?
> >>>>>>>>>      /oper
> >>>>>>>> This change to the accessible tree (1.0 --> 1.1) may break some
> >>>>>>>> existing "when" XPath expressions (those under "output" statement).
> >>>>>>> Maybe.  The old text said:
> >>>>>>>
> >>>>>>>       o If the context node represents RPC output parameters, the tree
> >>>>>>>       is
> >>>>>>>          the RPC reply instance document.
> >>>>>>>
> >>>>>>> So this probably meant that for this definition:
> >>>>>>>
> >>>>>>>      module ex {
> >>>>>>>        ...
> >>>>>>>        prefix x;
> >>>>>>>        ...
> >>>>>>>        rpc foo {
> >>>>>>>          output {
> >>>>>>>            leaf bar { ... }
> >>>>>>>          }
> >>>>>>>        }
> >>>>>>>      }
> >>>>>>>
> >>>>>>> The accessile tree was:
> >>>>>>>
> >>>>>>>       nc:rpc-reply
> >>>>>>>         +-- x:bar
> >>>>>>>
> >>>>>>> This is very NETCONF-specifc.  With 1.1, the tree would be:
> >>>>>>>
> >>>>>>>       x:foo
> >>>>>>>         +-- x:bar
> >>>>>>>
> >>>>>>> which is protocol-neutral.
> >>>>>>>
> >>>>>>>> Is
> >>>>>>>> this compatible with 1.1 charter - "All compliant YANG 1.0 modules
> >>>>>>>> must be accepted as compliant YANG 1.1 modules"?
> >>>>>>>>
> >>>>>>>>      rpc my-rpc {
> >>>>>>>>        output {
> >>>>>>>>          uses my-stuff {
> >>>>>>>>            when "specific-param = 'foo'";// 1.0
> >>>>>>>> // when "my-rpc/specific-param = 'foo'" // 1.1
> >>>>>>> This is not correct.  If a relative path is used, it would be the same
> >>>>>>> in 1.0 and 1.1.
> >>>>>> I disagree due to current text:
> >>>>>>
> >>>>>>      o data node: A node in the schema tree that can be instantiated in
> >>>>>>      a
> >>>>>>         data tree.  One of container, leaf, leaf-list, list, anydata,
> >>>>>>         and
> >>>>>>         anyxml.
> >>>>>>
> >>>>>>      o  If the XPath expression is defined in a substatement to an
> >>>>>>         "output" statement in an "rpc" or "action" statement, the
> >>>>>>         accessible tree is the RPC or action operation instance, all
> >>>>>>         state
> >>>>>>         data in the server, and the running configuration datastore.
> >>>>>>         The
> >>>>>>         root node has top-level data nodes in all modules as children.
> >>>>>>         Additionally, for an RPC, the root node also has the node
> >>>>>>         representing the RPC operation being defined as a child.  The
> >>>>>>         node
> >>>>>>         representing the operation being defined has the operation's
> >>>>>>         output parameters as children.
> >>>>>>
> >>>>>>      o  If the "when" statement is a child of a "uses", "choice", or
> >>>>>>         "case" statement, then the context node is the closest ancestor
> >>>>>>         node to the "uses", "choice", or "case" node that is also a data
> >>>>>>         node.  If no such node exists, the context node is the root
> >>>>>>         node.
> >>>>>>         The accessible tree is tentatively altered during the processing
> >>>>>>         of the XPath expression by removing all instances (if any) of
> >>>>>>         the
> >>>>>>         nodes added by the "uses", "choice", or "case" statement.
> >>>>>>
> >>>>>>
> >>>>>> It clearly says that the context node is the root node ("/"), not the
> >>>>>> node representing the RPC ("/my-rpc"), which is a child to root
> >>>>>> node. The "root node" aka "document root" can only mean a single thing
> >>>>>> XPath terminology.
> >>>>> RFC 6020 clearly says that the tree is the rpc reply instance
> >>>>> document, so it is a different document whose root node coincides with
> >>>>> . The problem of 6020bis is that we need a definition
> >>>>> that's independent of XML, and that's not so easy, but I agree with
> >>>>> Martin that nothing should change for relative paths.
> >>>> I'm not against the new accessible tree. That nothing should change
> >>>> for relative paths is a given, IMO. So what about absolute location
> >>>> paths?
> >>>>
> >>>> The previous accessible tree for a "when" expression under "output"
> >>>> was:
> >>>>
> >>>> 
> >>>>     +- x:bar
> >>> No it was:
> >>>
> >>>     
> >>>       +-- nc:rpc-reply
> >>>         +- x:bar
> >>>
> >>>> and now it is:
> >>>>
> >>>> 
> >>>>     +- x:foo
> >>>>       +- x:bar
> >>>>
> >>>> The absolute path to "x:bar" was:
> >>>>
> >>>> /x:bar
> >>> /nc:rpc-reply/x:bar
> >> No. How do you explain the different wording for "input" when compared
> >> to "output" (6020, 7.19.5):
> >>
> >>     o  If the context node represents RPC input parameters, the tree is
> >>        the RPC XML instance document.  The XPath root node has the
> >>        element representing the RPC operation being defined as the only
> >>        child.
> >>
> >>     o  If the context node represents RPC output parameters, the tree is
> >>        the RPC reply instance document.  The XPath root node has the
> >>        elements representing the RPC output parameters as children.
> >>
> >> "XPath root node has the _element_ representing the RPC operation as
> >> the _only child_" vs. "XPath root node has the _elements_ representing
> >> the RPC output as _children_".
> >>
> >> This is different from what 6020bis-09 is saying. The latter
> >> "equalized" accessible trees for "input" and "output". What I am
> >> asking is whether this confilcts with 1.1 charter.
> > You're right, but the entire thing is underspecifed in 6020.  In the
> > example you had:
> >
> >    rpc foo {
> >      output {
> >        uses my-stuff {
> >          when "...";
> >        }
> >      }
> >    }
> >
> > and if you go by 6020, there is no context node for the when
> > expression, and the accessible tree is defined in terms of the context
> > node.
> >
> > Yes this is different in 1.1, but I think we're specifying rules for
> > something that wasn't specified, and fix inconsistencies.
> >
> >> You could never refer to "nc:rpc-reply" as anything other that the
> >> document root in 1.0 ("/") . You could never refer to "nc:rpc" either,
> >> only to "x:foo".
> > It depends on how you interpret the words: "the tree is the RPC reply
> > instance document."
> 
> There is no room for misinterpreting what an XPath root node is (next
> sentence). Even if the processing is actually done on an RPC reply
> instance document, an RPC instance document or a notification instance
> document, "nc:rpc-reply", "nc:rpc" and "ncEvent:notification" are
> simply not part of the YANG XPath model as anything else than a root
> node ("/") and they never were. The QNames previously listed do not
> exist in this model.
> 
> >
> >>>> and is now:
> >>>>
> >>>> /x:foo/x:bar
> >>>>
> >>>> and this needs to be taken into account for at least relative paths to
> >>>> stay the same. Again, the root node is "/" in any case. So the context
> >>>> node needs to be set explicitly "/x:foo" for this corner case. I dare
> >>>> say it is not even a corner case. There is a similar YANG pattern to
> >>>> my "my-rpc" example in ietf-netconf-notifications for a
> >>>> "notification".
> >>> I think what needs to be done is to clarify that the context node for
> >>> when/must in input/output or uses in input/output is the node
> >>> representing the rpc.  Note that this is unspecified in 6020.
> >> True. It is unspecified. For notifications also, yet
> >> ietf-netconf-notifications practices it.
> > It just uses relative paths, in places where the context node is
> > well-defined.
> 
> The specific definition I had in mind is netconf-confirmed-commit
> "notification" (trimmed):
> 
>   notification netconf-confirmed-commit {
>     uses common-session-parms {
>       when "confirm-event != 'timeout'";
>     }
>   }
> 
> The context node for this "when" is as unspecified as in my original
> example for "output" per 6020 (no data node ancestor to "uses"). And
> in 6020bis-09 the context node now defaults to root node (not
> root/document element)!

As I wrote before, this needs to be fixed.  We need to take the
node representing the notification (or rpc) into account.  Do you
agree?

> So if I take
> ietf-netconf-notifications@2012-02-06 and add a "yang-version 1.1;" to
> it, the module will break.
> Furthermore the absolute XPath location path for confirm-event node is
> "/ncn:netconf-confirmed-commit/ncn:confirm-event", not
> "/ncEvent:notification/ncn:netconf-confirmed-commit/ncn:confirm-event",
> which is what you seem to be saying.

No, you are right.


/martin


> If this is what the intention
> was, several errata need to be posted for 6020. We implement the 1.0
> accessible tree the way I have been describing, and yes, we do
> implement absolute location paths.
> 
> XPATH, 5.1 (http://www.w3.org/TR/1999/REC-xpath-19991116/#data-model):
> The root node is the root of the tree. A root node does not occur
> except as the root of the tree. The element node for the document
> element is a child of the root node.
> 
> 6020:
> 
>    The data model used in the XPath expressions is the same as that used
>    in XPath 1.0
>    [XPATH],
>    with the same extension for root node children
>    as used by XSLT 1.0
>    [XSLT]
>    (Section 3.1).  Specifically, it means
>    that the root node may have any number of element nodes as its
>    children.
> 
>    o  data node: A node in the schema tree that can be instantiated in a
>       data tree.  One of container, leaf, leaf-list, list, and anyxml.
> 
>    o  If the "when" statement is a child of a "uses", "choice", or
>       "case" statement, then the context node is the closest ancestor
>       node to the "uses", "choice", or "case" node that is also a data
>       node.
> 
>    o  If the context node represents notification content, the tree is
>       the notification XML instance document.  The XPath root node has
>       the element representing the notification being defined as the
>       only child.
> 
> 6020bis-09:
> 
>    The data model used in the XPath expressions is the same as that used
>    in XPath 1.0 [XPATH], with the same extension for root node children
>    as used by XSLT 1.0 [XSLT] (Section 3.1).  Specifically, it means
>    that the root node may have any number of element nodes as its
>    children.
> 
>    o  data node: A node in the schema tree that can be instantiated in a
>       data tree.  One of container, leaf, leaf-list, list, anydata, and
>       anyxml.
> 
>    o  If the XPath expression is defined in a substatement to a
>       "notification" statement, the accessible tree is the notification
>       instance, all state data in the server, and the running
>       configuration datastore.  If the notification is defined on the
>       top-level in a module, then the root node has the node
>       representing the notification being defined and all top-level data
>       nodes in all modules as children.  Otherwise, the root node has
>       all top-level data nodes in all modules as children.
> 
>    o  If the "when" statement is a child of a "uses", "choice", or
>       "case" statement, then the context node is the closest ancestor
>       node to the "uses", "choice", or "case" node that is also a data
>       node.  If no such node exists, the context node is the root node.
>       The accessible tree is tentatively altered during the processing
>       of the XPath expression by removing all instances (if any) of the
>       nodes added by the "uses", "choice", or "case" statement.
> 
> 
> I hope this clarifies what my previous email was saying about
> ietf-netconf-notifications. The accessible tree for "output" is a
> different issue.
> 
> (PS: I've been having trouble replying to the mailing list ever since
> we migrated our mail server which is why my previous message was not
> sent to the mailing list and Martin seemed to be replying to thin
> air.)
> 
> Jernej
> 
> >
> >
> > /martin
> >
> >
> >
> >> Jernej
> >>
> >>> /martin
> >>>
> >>>
> >>>
> >>>> Jernej
> >>>>
> >>>>> Lada
> >>>>>
> >>>>>> Jernej
> >>>>>>
> >>>>>>> If an absolute path is used, it would be:
> >>>>>>>
> >>>>>>>       when "/nc:rpc-reply/x:specific-param = 'foo'"; // 1.0
> >>>>>>>       when "/x:my-rpc/x:specific-param = 'foo'";     // 1.1
> >>>>>>>
> >>>>>>>
> >>>>>>> I wonder if any implementation of 1.0 supports this absolute form.
> >>>>>>>
> >>>>>>>
> >>>>>>> /martin
> >>>>>>>
> >>>>>>>
> >>>>>>>>          }
> >>>>>>>>          leaf specific-param {
> >>>>>>>>            type string;
> >>>>>>>>          }
> >>>>>>>>        }
> >>>>>>>>      }
> >>>>>>>>
> >>>>>>>> Jernej
> >>>>>>>>
> >>>>>>>>> /martin
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> Thanks, Lada
> >>>>>>>>>>
> >>>>>>>>>> Martin Bjorklund  writes:
> >>>>>>>>>>
> >>>>>>>>>>> Ladislav Lhotka  wrote:
> >>>>>>>>>>>> Hi,
> >>>>>>>>>>>>
> >>>>>>>>>>>> Y02-01 allows "must" as a substatement of "input", "output" and
> >>>>>>>>>>>> "notification" but for these cases the specification of the
> >>>>>>>>>>>> context
> >>>>>>>>>>>> node in sec. 7.5.3 doesn't work.
> >>>>>>>>>>>>
> >>>>>>>>>>>>        o The context node is the node in the accessible tree for
> >>>>>>>>>>>>        which
> >>>>>>>>>>>>        the
> >>>>>>>>>>>>           "must" statement is defined.
> >>>>>>>>>>> You are right.  But note how the accessible tree is defined.  There
> >>>>>>>>>>> is
> >>>>>>>>>>> a node for the operation / notification.  This node should be the
> >>>>>>>>>>> context node:
> >>>>>>>>>>>
> >>>>>>>>>>>        o If the "must" statement is a substatement of a
> >>>>>>>>>>>        "notification"
> >>>>>>>>>>>           statement, the context node is the node representing the
> >>>>>>>>>>>           notification in the accessible tree.
> >>>>>>>>>>>
> >>>>>>>>>>>        o  If the "must" statement is a substatement of a "input"
> >>>>>>>>>>>           statement, the context node is the node representing the
> >>>>>>>>>>>           operation in the accessible tree.
> >>>>>>>>>>>
> >>>>>>>>>>>        o  If the "must" statement is a substatement of a "output"
> >>>>>>>>>>>           statement, the context node is the node representing the
> >>>>>>>>>>>           operation in the accessible tree.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> /martin
> >>>>>>>>>> -- 
> >>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
> >>>>>>>>>> PGP Key ID: E74E8C0C
> >>>>>>>>>>
> >>>>>>>>> _______________________________________________
> >>>>>>>>> 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, CZ.NIC Labs
> >>>>> PGP Key ID: E74E8C0C
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> 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
> 


From nobody Thu Dec 17 05:28:40 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB0B1B2D12 for ; Thu, 17 Dec 2015 05:28:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 X5uc3n5veLzC for ; Thu, 17 Dec 2015 05:28:34 -0800 (PST)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD691B2C91 for ; Thu, 17 Dec 2015 05:28:33 -0800 (PST)
Received: from [10.0.0.222] (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 3F06BC4175D2; Thu, 17 Dec 2015 14:28:31 +0100 (CET)
To: Martin Bjorklund 
References: <56719A45.90608@mg-soft.com> <20151216.184702.2006246752868355276.mbj@tail-f.com> <567281B7.9090709@mg-soft.si> <20151217.132302.647018113529105090.mbj@tail-f.com>
From: Jernej Tuljak 
Message-ID: <5672B87E.7080406@mg-soft.si>
Date: Thu, 17 Dec 2015 14:28:30 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <20151217.132302.647018113529105090.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y02: context node
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 13:28:39 -0000

Martin Bjorklund je 17.12.2015 ob 13:23 napisal:
> Jernej Tuljak  wrote:
>> Martin Bjorklund je 16.12.2015 ob 18:47 napisal:
>>> Jernej Tuljak  wrote:
>>>> Dne 16.12.2015 ob 17:18 je Martin Bjorklund zapisal(a):
>>>>> Jernej Tuljak  wrote:
>>>>>> Ladislav Lhotka je 16.12.2015 ob 15:10 napisal:
>>>>>>>> On 16 Dec 2015, at 14:08, Jernej Tuljak  wrote:
>>>>>>>>
>>>>>>>> Martin Bjorklund je 16.12.2015 ob 13:48 napisal:
>>>>>>>>> Jernej Tuljak  wrote:
>>>>>>>>>> Martin Bjorklund je 25.11.2015 ob 11:16 napisal:
>>>>>>>>>>> Ladislav Lhotka  wrote:
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> I'd like to resolve this issue. Here is a complete example (valid, I
>>>>>>>>>>>> believe):
>>>>>>>>>>>>
>>>>>>>>>>>> module context {
>>>>>>>>>>>>        namespace "http://example.com/context";
>>>>>>>>>>>>        prefix ctx;
>>>>>>>>>>>>
>>>>>>>>>>>>        leaf foo {
>>>>>>>>>>>>          config false;
>>>>>>>>>>>>          type uint32;
>>>>>>>>>>>>        }
>>>>>>>>>>>>        rpc oper {
>>>>>>>>>>>>          output {
>>>>>>>>>>>>            must "/foo mod foo = 0";
>>>>>>>>>>>>            leaf foo {
>>>>>>>>>>>>              type uint32;
>>>>>>>>>>>>            }
>>>>>>>>>>>>          }
>>>>>>>>>>>>        }
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> 1. What does the accessible tree look like?
>>>>>>>>>>> Note that the anser to this depends on the outcomne of Y04.  Andy has
>>>>>>>>>>> strong objections to Y04-02, and proposed Y04-04 instead.
>>>>>>>>>>>
>>>>>>>>>>> Assuming Y04-02, and assuming /foo has the value 20 and the oper
>>>>>>>>>>> rpc's
>>>>>>>>>>> result has foo = 10, the accessible tree would look like this:
>>>>>>>>>>>
>>>>>>>>>>>         
>>>>>>>>>>>           +-- oper
>>>>>>>>>>>           |   +-- foo = 10
>>>>>>>>>>>           +-- foo = 20
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> (If we instead move back to Y04-04, the accessible tree would be:
>>>>>>>>>>>
>>>>>>>>>>>         
>>>>>>>>>>>           +-- oper
>>>>>>>>>>>               +-- foo = 10
>>>>>>>>>>>
>>>>>>>>>>> )
>>>>>>>>>>>
>>>>>>>>>>>> 2. What is the context node for the "must" expression?
>>>>>>>>>>>       /oper
>>>>>>>>>> This change to the accessible tree (1.0 --> 1.1) may break some
>>>>>>>>>> existing "when" XPath expressions (those under "output" statement).
>>>>>>>>> Maybe.  The old text said:
>>>>>>>>>
>>>>>>>>>        o If the context node represents RPC output parameters, the tree
>>>>>>>>>        is
>>>>>>>>>           the RPC reply instance document.
>>>>>>>>>
>>>>>>>>> So this probably meant that for this definition:
>>>>>>>>>
>>>>>>>>>       module ex {
>>>>>>>>>         ...
>>>>>>>>>         prefix x;
>>>>>>>>>         ...
>>>>>>>>>         rpc foo {
>>>>>>>>>           output {
>>>>>>>>>             leaf bar { ... }
>>>>>>>>>           }
>>>>>>>>>         }
>>>>>>>>>       }
>>>>>>>>>
>>>>>>>>> The accessile tree was:
>>>>>>>>>
>>>>>>>>>        nc:rpc-reply
>>>>>>>>>          +-- x:bar
>>>>>>>>>
>>>>>>>>> This is very NETCONF-specifc.  With 1.1, the tree would be:
>>>>>>>>>
>>>>>>>>>        x:foo
>>>>>>>>>          +-- x:bar
>>>>>>>>>
>>>>>>>>> which is protocol-neutral.
>>>>>>>>>
>>>>>>>>>> Is
>>>>>>>>>> this compatible with 1.1 charter - "All compliant YANG 1.0 modules
>>>>>>>>>> must be accepted as compliant YANG 1.1 modules"?
>>>>>>>>>>
>>>>>>>>>>       rpc my-rpc {
>>>>>>>>>>         output {
>>>>>>>>>>           uses my-stuff {
>>>>>>>>>>             when "specific-param = 'foo'";// 1.0
>>>>>>>>>> // when "my-rpc/specific-param = 'foo'" // 1.1
>>>>>>>>> This is not correct.  If a relative path is used, it would be the same
>>>>>>>>> in 1.0 and 1.1.
>>>>>>>> I disagree due to current text:
>>>>>>>>
>>>>>>>>       o data node: A node in the schema tree that can be instantiated in
>>>>>>>>       a
>>>>>>>>          data tree.  One of container, leaf, leaf-list, list, anydata,
>>>>>>>>          and
>>>>>>>>          anyxml.
>>>>>>>>
>>>>>>>>       o  If the XPath expression is defined in a substatement to an
>>>>>>>>          "output" statement in an "rpc" or "action" statement, the
>>>>>>>>          accessible tree is the RPC or action operation instance, all
>>>>>>>>          state
>>>>>>>>          data in the server, and the running configuration datastore.
>>>>>>>>          The
>>>>>>>>          root node has top-level data nodes in all modules as children.
>>>>>>>>          Additionally, for an RPC, the root node also has the node
>>>>>>>>          representing the RPC operation being defined as a child.  The
>>>>>>>>          node
>>>>>>>>          representing the operation being defined has the operation's
>>>>>>>>          output parameters as children.
>>>>>>>>
>>>>>>>>       o  If the "when" statement is a child of a "uses", "choice", or
>>>>>>>>          "case" statement, then the context node is the closest ancestor
>>>>>>>>          node to the "uses", "choice", or "case" node that is also a data
>>>>>>>>          node.  If no such node exists, the context node is the root
>>>>>>>>          node.
>>>>>>>>          The accessible tree is tentatively altered during the processing
>>>>>>>>          of the XPath expression by removing all instances (if any) of
>>>>>>>>          the
>>>>>>>>          nodes added by the "uses", "choice", or "case" statement.
>>>>>>>>
>>>>>>>>
>>>>>>>> It clearly says that the context node is the root node ("/"), not the
>>>>>>>> node representing the RPC ("/my-rpc"), which is a child to root
>>>>>>>> node. The "root node" aka "document root" can only mean a single thing
>>>>>>>> XPath terminology.
>>>>>>> RFC 6020 clearly says that the tree is the rpc reply instance
>>>>>>> document, so it is a different document whose root node coincides with
>>>>>>> . The problem of 6020bis is that we need a definition
>>>>>>> that's independent of XML, and that's not so easy, but I agree with
>>>>>>> Martin that nothing should change for relative paths.
>>>>>> I'm not against the new accessible tree. That nothing should change
>>>>>> for relative paths is a given, IMO. So what about absolute location
>>>>>> paths?
>>>>>>
>>>>>> The previous accessible tree for a "when" expression under "output"
>>>>>> was:
>>>>>>
>>>>>> 
>>>>>>      +- x:bar
>>>>> No it was:
>>>>>
>>>>>      
>>>>>        +-- nc:rpc-reply
>>>>>          +- x:bar
>>>>>
>>>>>> and now it is:
>>>>>>
>>>>>> 
>>>>>>      +- x:foo
>>>>>>        +- x:bar
>>>>>>
>>>>>> The absolute path to "x:bar" was:
>>>>>>
>>>>>> /x:bar
>>>>> /nc:rpc-reply/x:bar
>>>> No. How do you explain the different wording for "input" when compared
>>>> to "output" (6020, 7.19.5):
>>>>
>>>>      o  If the context node represents RPC input parameters, the tree is
>>>>         the RPC XML instance document.  The XPath root node has the
>>>>         element representing the RPC operation being defined as the only
>>>>         child.
>>>>
>>>>      o  If the context node represents RPC output parameters, the tree is
>>>>         the RPC reply instance document.  The XPath root node has the
>>>>         elements representing the RPC output parameters as children.
>>>>
>>>> "XPath root node has the _element_ representing the RPC operation as
>>>> the _only child_" vs. "XPath root node has the _elements_ representing
>>>> the RPC output as _children_".
>>>>
>>>> This is different from what 6020bis-09 is saying. The latter
>>>> "equalized" accessible trees for "input" and "output". What I am
>>>> asking is whether this confilcts with 1.1 charter.
>>> You're right, but the entire thing is underspecifed in 6020.  In the
>>> example you had:
>>>
>>>     rpc foo {
>>>       output {
>>>         uses my-stuff {
>>>           when "...";
>>>         }
>>>       }
>>>     }
>>>
>>> and if you go by 6020, there is no context node for the when
>>> expression, and the accessible tree is defined in terms of the context
>>> node.
>>>
>>> Yes this is different in 1.1, but I think we're specifying rules for
>>> something that wasn't specified, and fix inconsistencies.
>>>
>>>> You could never refer to "nc:rpc-reply" as anything other that the
>>>> document root in 1.0 ("/") . You could never refer to "nc:rpc" either,
>>>> only to "x:foo".
>>> It depends on how you interpret the words: "the tree is the RPC reply
>>> instance document."
>> There is no room for misinterpreting what an XPath root node is (next
>> sentence). Even if the processing is actually done on an RPC reply
>> instance document, an RPC instance document or a notification instance
>> document, "nc:rpc-reply", "nc:rpc" and "ncEvent:notification" are
>> simply not part of the YANG XPath model as anything else than a root
>> node ("/") and they never were. The QNames previously listed do not
>> exist in this model.
>>
>>>>>> and is now:
>>>>>>
>>>>>> /x:foo/x:bar
>>>>>>
>>>>>> and this needs to be taken into account for at least relative paths to
>>>>>> stay the same. Again, the root node is "/" in any case. So the context
>>>>>> node needs to be set explicitly "/x:foo" for this corner case. I dare
>>>>>> say it is not even a corner case. There is a similar YANG pattern to
>>>>>> my "my-rpc" example in ietf-netconf-notifications for a
>>>>>> "notification".
>>>>> I think what needs to be done is to clarify that the context node for
>>>>> when/must in input/output or uses in input/output is the node
>>>>> representing the rpc.  Note that this is unspecified in 6020.
>>>> True. It is unspecified. For notifications also, yet
>>>> ietf-netconf-notifications practices it.
>>> It just uses relative paths, in places where the context node is
>>> well-defined.
>> The specific definition I had in mind is netconf-confirmed-commit
>> "notification" (trimmed):
>>
>>    notification netconf-confirmed-commit {
>>      uses common-session-parms {
>>        when "confirm-event != 'timeout'";
>>      }
>>    }
>>
>> The context node for this "when" is as unspecified as in my original
>> example for "output" per 6020 (no data node ancestor to "uses"). And
>> in 6020bis-09 the context node now defaults to root node (not
>> root/document element)!
> As I wrote before, this needs to be fixed.  We need to take the
> node representing the notification (or rpc) into account.  Do you
> agree?

I agree. The root node is acceptable only if none of these ancestors are 
found: a data node, node representing a notification, node representing 
an rpc, node representing rpc output.

Jernej

>
>> So if I take
>> ietf-netconf-notifications@2012-02-06 and add a "yang-version 1.1;" to
>> it, the module will break.
>> Furthermore the absolute XPath location path for confirm-event node is
>> "/ncn:netconf-confirmed-commit/ncn:confirm-event", not
>> "/ncEvent:notification/ncn:netconf-confirmed-commit/ncn:confirm-event",
>> which is what you seem to be saying.
> No, you are right.
>
>
> /martin
>
>
>> If this is what the intention
>> was, several errata need to be posted for 6020. We implement the 1.0
>> accessible tree the way I have been describing, and yes, we do
>> implement absolute location paths.
>>
>> XPATH, 5.1 (http://www.w3.org/TR/1999/REC-xpath-19991116/#data-model):
>> The root node is the root of the tree. A root node does not occur
>> except as the root of the tree. The element node for the document
>> element is a child of the root node.
>>
>> 6020:
>>
>>     The data model used in the XPath expressions is the same as that used
>>     in XPath 1.0
>>     [XPATH],
>>     with the same extension for root node children
>>     as used by XSLT 1.0
>>     [XSLT]
>>     (Section 3.1).  Specifically, it means
>>     that the root node may have any number of element nodes as its
>>     children.
>>
>>     o  data node: A node in the schema tree that can be instantiated in a
>>        data tree.  One of container, leaf, leaf-list, list, and anyxml.
>>
>>     o  If the "when" statement is a child of a "uses", "choice", or
>>        "case" statement, then the context node is the closest ancestor
>>        node to the "uses", "choice", or "case" node that is also a data
>>        node.
>>
>>     o  If the context node represents notification content, the tree is
>>        the notification XML instance document.  The XPath root node has
>>        the element representing the notification being defined as the
>>        only child.
>>
>> 6020bis-09:
>>
>>     The data model used in the XPath expressions is the same as that used
>>     in XPath 1.0 [XPATH], with the same extension for root node children
>>     as used by XSLT 1.0 [XSLT] (Section 3.1).  Specifically, it means
>>     that the root node may have any number of element nodes as its
>>     children.
>>
>>     o  data node: A node in the schema tree that can be instantiated in a
>>        data tree.  One of container, leaf, leaf-list, list, anydata, and
>>        anyxml.
>>
>>     o  If the XPath expression is defined in a substatement to a
>>        "notification" statement, the accessible tree is the notification
>>        instance, all state data in the server, and the running
>>        configuration datastore.  If the notification is defined on the
>>        top-level in a module, then the root node has the node
>>        representing the notification being defined and all top-level data
>>        nodes in all modules as children.  Otherwise, the root node has
>>        all top-level data nodes in all modules as children.
>>
>>     o  If the "when" statement is a child of a "uses", "choice", or
>>        "case" statement, then the context node is the closest ancestor
>>        node to the "uses", "choice", or "case" node that is also a data
>>        node.  If no such node exists, the context node is the root node.
>>        The accessible tree is tentatively altered during the processing
>>        of the XPath expression by removing all instances (if any) of the
>>        nodes added by the "uses", "choice", or "case" statement.
>>
>>
>> I hope this clarifies what my previous email was saying about
>> ietf-netconf-notifications. The accessible tree for "output" is a
>> different issue.
>>
>> (PS: I've been having trouble replying to the mailing list ever since
>> we migrated our mail server which is why my previous message was not
>> sent to the mailing list and Martin seemed to be replying to thin
>> air.)
>>
>> Jernej
>>
>>>
>>> /martin
>>>
>>>
>>>
>>>> Jernej
>>>>
>>>>> /martin
>>>>>
>>>>>
>>>>>
>>>>>> Jernej
>>>>>>
>>>>>>> Lada
>>>>>>>
>>>>>>>> Jernej
>>>>>>>>
>>>>>>>>> If an absolute path is used, it would be:
>>>>>>>>>
>>>>>>>>>        when "/nc:rpc-reply/x:specific-param = 'foo'"; // 1.0
>>>>>>>>>        when "/x:my-rpc/x:specific-param = 'foo'";     // 1.1
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I wonder if any implementation of 1.0 supports this absolute form.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> /martin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>           }
>>>>>>>>>>           leaf specific-param {
>>>>>>>>>>             type string;
>>>>>>>>>>           }
>>>>>>>>>>         }
>>>>>>>>>>       }
>>>>>>>>>>
>>>>>>>>>> Jernej
>>>>>>>>>>
>>>>>>>>>>> /martin
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Thanks, Lada
>>>>>>>>>>>>
>>>>>>>>>>>> Martin Bjorklund  writes:
>>>>>>>>>>>>
>>>>>>>>>>>>> Ladislav Lhotka  wrote:
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Y02-01 allows "must" as a substatement of "input", "output" and
>>>>>>>>>>>>>> "notification" but for these cases the specification of the
>>>>>>>>>>>>>> context
>>>>>>>>>>>>>> node in sec. 7.5.3 doesn't work.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         o The context node is the node in the accessible tree for
>>>>>>>>>>>>>>         which
>>>>>>>>>>>>>>         the
>>>>>>>>>>>>>>            "must" statement is defined.
>>>>>>>>>>>>> You are right.  But note how the accessible tree is defined.  There
>>>>>>>>>>>>> is
>>>>>>>>>>>>> a node for the operation / notification.  This node should be the
>>>>>>>>>>>>> context node:
>>>>>>>>>>>>>
>>>>>>>>>>>>>         o If the "must" statement is a substatement of a
>>>>>>>>>>>>>         "notification"
>>>>>>>>>>>>>            statement, the context node is the node representing the
>>>>>>>>>>>>>            notification in the accessible tree.
>>>>>>>>>>>>>
>>>>>>>>>>>>>         o  If the "must" statement is a substatement of a "input"
>>>>>>>>>>>>>            statement, the context node is the node representing the
>>>>>>>>>>>>>            operation in the accessible tree.
>>>>>>>>>>>>>
>>>>>>>>>>>>>         o  If the "must" statement is a substatement of a "output"
>>>>>>>>>>>>>            statement, the context node is the node representing the
>>>>>>>>>>>>>            operation in the accessible tree.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> /martin
>>>>>>>>>>>> -- 
>>>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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, CZ.NIC Labs
>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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


From nobody Thu Dec 17 05:37:28 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FDB21B2C6F for ; Thu, 17 Dec 2015 05:37:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 OErSEJxjxH63 for ; Thu, 17 Dec 2015 05:37:23 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B05E21B2C8A for ; Thu, 17 Dec 2015 05:37:22 -0800 (PST)
Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:22] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:22]) by mail.nic.cz (Postfix) with ESMTPSA id 3867D1818C8; Thu, 17 Dec 2015 14:37:21 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450359441; bh=172KYSo0tf3HgKcgxSRUMBj5QySPyDD4DZnj0RoacF0=; h=From:Date:To; b=uu9QyEa7baVkn6/ZKBeRkth/Gmy7H76Kd7RY2uZI/Bwdt+z37KZBJ423b0z6ZNfLR s13dxnO49yzhqCPektvAa5n1y3+X3qkTL8j+QKkkePt9X7sNqFgp/tkNYk3rJUA32B /lYYAoy54rxUPNdfyr4X5PwG130U2hNk2xZvEx0Y=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <5672B87E.7080406@mg-soft.si>
Date: Thu, 17 Dec 2015 14:37:21 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <56719A45.90608@mg-soft.com> <20151216.184702.2006246752868355276.mbj@tail-f.com> <567281B7.9090709@mg-soft.si> <20151217.132302.647018113529105090.mbj@tail-f.com> <5672B87E.7080406@mg-soft.si>
To: Jernej Tuljak 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Y02: context node
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 13:37:27 -0000

> On 17 Dec 2015, at 14:28, Jernej Tuljak  =
wrote:
>=20
> Martin Bjorklund je 17.12.2015 ob 13:23 napisal:
>> Jernej Tuljak  wrote:
>>> Martin Bjorklund je 16.12.2015 ob 18:47 napisal:
>>>> Jernej Tuljak  wrote:
>>>>> Dne 16.12.2015 ob 17:18 je Martin Bjorklund zapisal(a):
>>>>>> Jernej Tuljak  wrote:
>>>>>>> Ladislav Lhotka je 16.12.2015 ob 15:10 napisal:
>>>>>>>>> On 16 Dec 2015, at 14:08, Jernej Tuljak  =
wrote:
>>>>>>>>>=20
>>>>>>>>> Martin Bjorklund je 16.12.2015 ob 13:48 napisal:
>>>>>>>>>> Jernej Tuljak  wrote:
>>>>>>>>>>> Martin Bjorklund je 25.11.2015 ob 11:16 napisal:
>>>>>>>>>>>> Ladislav Lhotka  wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> I'd like to resolve this issue. Here is a complete example =
(valid, I
>>>>>>>>>>>>> believe):
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> module context {
>>>>>>>>>>>>>       namespace "http://example.com/context";
>>>>>>>>>>>>>       prefix ctx;
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>       leaf foo {
>>>>>>>>>>>>>         config false;
>>>>>>>>>>>>>         type uint32;
>>>>>>>>>>>>>       }
>>>>>>>>>>>>>       rpc oper {
>>>>>>>>>>>>>         output {
>>>>>>>>>>>>>           must "/foo mod foo =3D 0";
>>>>>>>>>>>>>           leaf foo {
>>>>>>>>>>>>>             type uint32;
>>>>>>>>>>>>>           }
>>>>>>>>>>>>>         }
>>>>>>>>>>>>>       }
>>>>>>>>>>>>> }
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> 1. What does the accessible tree look like?
>>>>>>>>>>>> Note that the anser to this depends on the outcomne of Y04. =
 Andy has
>>>>>>>>>>>> strong objections to Y04-02, and proposed Y04-04 instead.
>>>>>>>>>>>>=20
>>>>>>>>>>>> Assuming Y04-02, and assuming /foo has the value 20 and the =
oper
>>>>>>>>>>>> rpc's
>>>>>>>>>>>> result has foo =3D 10, the accessible tree would look like =
this:
>>>>>>>>>>>>=20
>>>>>>>>>>>>        
>>>>>>>>>>>>          +-- oper
>>>>>>>>>>>>          |   +-- foo =3D 10
>>>>>>>>>>>>          +-- foo =3D 20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>> (If we instead move back to Y04-04, the accessible tree =
would be:
>>>>>>>>>>>>=20
>>>>>>>>>>>>        
>>>>>>>>>>>>          +-- oper
>>>>>>>>>>>>              +-- foo =3D 10
>>>>>>>>>>>>=20
>>>>>>>>>>>> )
>>>>>>>>>>>>=20
>>>>>>>>>>>>> 2. What is the context node for the "must" expression?
>>>>>>>>>>>>      /oper
>>>>>>>>>>> This change to the accessible tree (1.0 --> 1.1) may break =
some
>>>>>>>>>>> existing "when" XPath expressions (those under "output" =
statement).
>>>>>>>>>> Maybe.  The old text said:
>>>>>>>>>>=20
>>>>>>>>>>       o If the context node represents RPC output parameters, =
the tree
>>>>>>>>>>       is
>>>>>>>>>>          the RPC reply instance document.
>>>>>>>>>>=20
>>>>>>>>>> So this probably meant that for this definition:
>>>>>>>>>>=20
>>>>>>>>>>      module ex {
>>>>>>>>>>        ...
>>>>>>>>>>        prefix x;
>>>>>>>>>>        ...
>>>>>>>>>>        rpc foo {
>>>>>>>>>>          output {
>>>>>>>>>>            leaf bar { ... }
>>>>>>>>>>          }
>>>>>>>>>>        }
>>>>>>>>>>      }
>>>>>>>>>>=20
>>>>>>>>>> The accessile tree was:
>>>>>>>>>>=20
>>>>>>>>>>       nc:rpc-reply
>>>>>>>>>>         +-- x:bar
>>>>>>>>>>=20
>>>>>>>>>> This is very NETCONF-specifc.  With 1.1, the tree would be:
>>>>>>>>>>=20
>>>>>>>>>>       x:foo
>>>>>>>>>>         +-- x:bar
>>>>>>>>>>=20
>>>>>>>>>> which is protocol-neutral.
>>>>>>>>>>=20
>>>>>>>>>>> Is
>>>>>>>>>>> this compatible with 1.1 charter - "All compliant YANG 1.0 =
modules
>>>>>>>>>>> must be accepted as compliant YANG 1.1 modules"?
>>>>>>>>>>>=20
>>>>>>>>>>>      rpc my-rpc {
>>>>>>>>>>>        output {
>>>>>>>>>>>          uses my-stuff {
>>>>>>>>>>>            when "specific-param =3D 'foo'";// 1.0
>>>>>>>>>>> // when "my-rpc/specific-param =3D 'foo'" // 1.1
>>>>>>>>>> This is not correct.  If a relative path is used, it would be =
the same
>>>>>>>>>> in 1.0 and 1.1.
>>>>>>>>> I disagree due to current text:
>>>>>>>>>=20
>>>>>>>>>      o data node: A node in the schema tree that can be =
instantiated in
>>>>>>>>>      a
>>>>>>>>>         data tree.  One of container, leaf, leaf-list, list, =
anydata,
>>>>>>>>>         and
>>>>>>>>>         anyxml.
>>>>>>>>>=20
>>>>>>>>>      o  If the XPath expression is defined in a substatement =
to an
>>>>>>>>>         "output" statement in an "rpc" or "action" statement, =
the
>>>>>>>>>         accessible tree is the RPC or action operation =
instance, all
>>>>>>>>>         state
>>>>>>>>>         data in the server, and the running configuration =
datastore.
>>>>>>>>>         The
>>>>>>>>>         root node has top-level data nodes in all modules as =
children.
>>>>>>>>>         Additionally, for an RPC, the root node also has the =
node
>>>>>>>>>         representing the RPC operation being defined as a =
child.  The
>>>>>>>>>         node
>>>>>>>>>         representing the operation being defined has the =
operation's
>>>>>>>>>         output parameters as children.
>>>>>>>>>=20
>>>>>>>>>      o  If the "when" statement is a child of a "uses", =
"choice", or
>>>>>>>>>         "case" statement, then the context node is the closest =
ancestor
>>>>>>>>>         node to the "uses", "choice", or "case" node that is =
also a data
>>>>>>>>>         node.  If no such node exists, the context node is the =
root
>>>>>>>>>         node.
>>>>>>>>>         The accessible tree is tentatively altered during the =
processing
>>>>>>>>>         of the XPath expression by removing all instances (if =
any) of
>>>>>>>>>         the
>>>>>>>>>         nodes added by the "uses", "choice", or "case" =
statement.
>>>>>>>>>=20
>>>>>>>>>=20
>>>>>>>>> It clearly says that the context node is the root node ("/"), =
not the
>>>>>>>>> node representing the RPC ("/my-rpc"), which is a child to =
root
>>>>>>>>> node. The "root node" aka "document root" can only mean a =
single thing
>>>>>>>>> XPath terminology.
>>>>>>>> RFC 6020 clearly says that the tree is the rpc reply instance
>>>>>>>> document, so it is a different document whose root node =
coincides with
>>>>>>>> . The problem of 6020bis is that we need a =
definition
>>>>>>>> that's independent of XML, and that's not so easy, but I agree =
with
>>>>>>>> Martin that nothing should change for relative paths.
>>>>>>> I'm not against the new accessible tree. That nothing should =
change
>>>>>>> for relative paths is a given, IMO. So what about absolute =
location
>>>>>>> paths?
>>>>>>>=20
>>>>>>> The previous accessible tree for a "when" expression under =
"output"
>>>>>>> was:
>>>>>>>=20
>>>>>>> 
>>>>>>>     +- x:bar
>>>>>> No it was:
>>>>>>=20
>>>>>>     
>>>>>>       +-- nc:rpc-reply
>>>>>>         +- x:bar
>>>>>>=20
>>>>>>> and now it is:
>>>>>>>=20
>>>>>>> 
>>>>>>>     +- x:foo
>>>>>>>       +- x:bar
>>>>>>>=20
>>>>>>> The absolute path to "x:bar" was:
>>>>>>>=20
>>>>>>> /x:bar
>>>>>> /nc:rpc-reply/x:bar
>>>>> No. How do you explain the different wording for "input" when =
compared
>>>>> to "output" (6020, 7.19.5):
>>>>>=20
>>>>>     o  If the context node represents RPC input parameters, the =
tree is
>>>>>        the RPC XML instance document.  The XPath root node has the
>>>>>        element representing the RPC operation being defined as the =
only
>>>>>        child.
>>>>>=20
>>>>>     o  If the context node represents RPC output parameters, the =
tree is
>>>>>        the RPC reply instance document.  The XPath root node has =
the
>>>>>        elements representing the RPC output parameters as =
children.
>>>>>=20
>>>>> "XPath root node has the _element_ representing the RPC operation =
as
>>>>> the _only child_" vs. "XPath root node has the _elements_ =
representing
>>>>> the RPC output as _children_".
>>>>>=20
>>>>> This is different from what 6020bis-09 is saying. The latter
>>>>> "equalized" accessible trees for "input" and "output". What I am
>>>>> asking is whether this confilcts with 1.1 charter.
>>>> You're right, but the entire thing is underspecifed in 6020.  In =
the
>>>> example you had:
>>>>=20
>>>>    rpc foo {
>>>>      output {
>>>>        uses my-stuff {
>>>>          when "...";
>>>>        }
>>>>      }
>>>>    }
>>>>=20
>>>> and if you go by 6020, there is no context node for the when
>>>> expression, and the accessible tree is defined in terms of the =
context
>>>> node.
>>>>=20
>>>> Yes this is different in 1.1, but I think we're specifying rules =
for
>>>> something that wasn't specified, and fix inconsistencies.
>>>>=20
>>>>> You could never refer to "nc:rpc-reply" as anything other that the
>>>>> document root in 1.0 ("/") . You could never refer to "nc:rpc" =
either,
>>>>> only to "x:foo".
>>>> It depends on how you interpret the words: "the tree is the RPC =
reply
>>>> instance document."
>>> There is no room for misinterpreting what an XPath root node is =
(next
>>> sentence). Even if the processing is actually done on an RPC reply
>>> instance document, an RPC instance document or a notification =
instance
>>> document, "nc:rpc-reply", "nc:rpc" and "ncEvent:notification" are
>>> simply not part of the YANG XPath model as anything else than a root
>>> node ("/") and they never were. The QNames previously listed do not
>>> exist in this model.
>>>=20
>>>>>>> and is now:
>>>>>>>=20
>>>>>>> /x:foo/x:bar
>>>>>>>=20
>>>>>>> and this needs to be taken into account for at least relative =
paths to
>>>>>>> stay the same. Again, the root node is "/" in any case. So the =
context
>>>>>>> node needs to be set explicitly "/x:foo" for this corner case. I =
dare
>>>>>>> say it is not even a corner case. There is a similar YANG =
pattern to
>>>>>>> my "my-rpc" example in ietf-netconf-notifications for a
>>>>>>> "notification".
>>>>>> I think what needs to be done is to clarify that the context node =
for
>>>>>> when/must in input/output or uses in input/output is the node
>>>>>> representing the rpc.  Note that this is unspecified in 6020.
>>>>> True. It is unspecified. For notifications also, yet
>>>>> ietf-netconf-notifications practices it.
>>>> It just uses relative paths, in places where the context node is
>>>> well-defined.
>>> The specific definition I had in mind is netconf-confirmed-commit
>>> "notification" (trimmed):
>>>=20
>>>   notification netconf-confirmed-commit {
>>>     uses common-session-parms {
>>>       when "confirm-event !=3D 'timeout'";
>>>     }
>>>   }
>>>=20
>>> The context node for this "when" is as unspecified as in my original
>>> example for "output" per 6020 (no data node ancestor to "uses"). And
>>> in 6020bis-09 the context node now defaults to root node (not
>>> root/document element)!
>> As I wrote before, this needs to be fixed.  We need to take the
>> node representing the notification (or rpc) into account.  Do you
>> agree?
>=20
> I agree. The root node is acceptable only if none of these ancestors =
are found: a data node, node representing a notification, node =
representing an rpc, node representing rpc output.

The latter is somewhat more peculiar because it doesn't appear in XML =
instances - the others do. I think it would be useful to include a =
section describing the data tree, its properties, and how it maps to =
XPath. This is a bit difficult prospect though given that 6020bis is =
already in the (second) WGLC.

Lada

>=20
> Jernej
>=20
>>=20
>>> So if I take
>>> ietf-netconf-notifications@2012-02-06 and add a "yang-version 1.1;" =
to
>>> it, the module will break.
>>> Furthermore the absolute XPath location path for confirm-event node =
is
>>> "/ncn:netconf-confirmed-commit/ncn:confirm-event", not
>>> =
"/ncEvent:notification/ncn:netconf-confirmed-commit/ncn:confirm-event",
>>> which is what you seem to be saying.
>> No, you are right.
>>=20
>>=20
>> /martin
>>=20
>>=20
>>> If this is what the intention
>>> was, several errata need to be posted for 6020. We implement the 1.0
>>> accessible tree the way I have been describing, and yes, we do
>>> implement absolute location paths.
>>>=20
>>> XPATH, 5.1 =
(http://www.w3.org/TR/1999/REC-xpath-19991116/#data-model):
>>> The root node is the root of the tree. A root node does not occur
>>> except as the root of the tree. The element node for the document
>>> element is a child of the root node.
>>>=20
>>> 6020:
>>>=20
>>>    The data model used in the XPath expressions is the same as that =
used
>>>    in XPath 1.0
>>>    =
[XPATH],
>>>    with the same extension for root node children
>>>    as used by XSLT 1.0
>>>    =
[XSLT]
>>>    (Section 3.1).  Specifically, it means
>>>    that the root node may have any number of element nodes as its
>>>    children.
>>>=20
>>>    o  data node: A node in the schema tree that can be instantiated =
in a
>>>       data tree.  One of container, leaf, leaf-list, list, and =
anyxml.
>>>=20
>>>    o  If the "when" statement is a child of a "uses", "choice", or
>>>       "case" statement, then the context node is the closest =
ancestor
>>>       node to the "uses", "choice", or "case" node that is also a =
data
>>>       node.
>>>=20
>>>    o  If the context node represents notification content, the tree =
is
>>>       the notification XML instance document.  The XPath root node =
has
>>>       the element representing the notification being defined as the
>>>       only child.
>>>=20
>>> 6020bis-09:
>>>=20
>>>    The data model used in the XPath expressions is the same as that =
used
>>>    in XPath 1.0 [XPATH], with the same extension for root node =
children
>>>    as used by XSLT 1.0 [XSLT] (Section 3.1).  Specifically, it means
>>>    that the root node may have any number of element nodes as its
>>>    children.
>>>=20
>>>    o  data node: A node in the schema tree that can be instantiated =
in a
>>>       data tree.  One of container, leaf, leaf-list, list, anydata, =
and
>>>       anyxml.
>>>=20
>>>    o  If the XPath expression is defined in a substatement to a
>>>       "notification" statement, the accessible tree is the =
notification
>>>       instance, all state data in the server, and the running
>>>       configuration datastore.  If the notification is defined on =
the
>>>       top-level in a module, then the root node has the node
>>>       representing the notification being defined and all top-level =
data
>>>       nodes in all modules as children.  Otherwise, the root node =
has
>>>       all top-level data nodes in all modules as children.
>>>=20
>>>    o  If the "when" statement is a child of a "uses", "choice", or
>>>       "case" statement, then the context node is the closest =
ancestor
>>>       node to the "uses", "choice", or "case" node that is also a =
data
>>>       node.  If no such node exists, the context node is the root =
node.
>>>       The accessible tree is tentatively altered during the =
processing
>>>       of the XPath expression by removing all instances (if any) of =
the
>>>       nodes added by the "uses", "choice", or "case" statement.
>>>=20
>>>=20
>>> I hope this clarifies what my previous email was saying about
>>> ietf-netconf-notifications. The accessible tree for "output" is a
>>> different issue.
>>>=20
>>> (PS: I've been having trouble replying to the mailing list ever =
since
>>> we migrated our mail server which is why my previous message was not
>>> sent to the mailing list and Martin seemed to be replying to thin
>>> air.)
>>>=20
>>> Jernej
>>>=20
>>>>=20
>>>> /martin
>>>>=20
>>>>=20
>>>>=20
>>>>> Jernej
>>>>>=20
>>>>>> /martin
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>> Jernej
>>>>>>>=20
>>>>>>>> Lada
>>>>>>>>=20
>>>>>>>>> Jernej
>>>>>>>>>=20
>>>>>>>>>> If an absolute path is used, it would be:
>>>>>>>>>>=20
>>>>>>>>>>       when "/nc:rpc-reply/x:specific-param =3D 'foo'"; // 1.0
>>>>>>>>>>       when "/x:my-rpc/x:specific-param =3D 'foo'";     // 1.1
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> I wonder if any implementation of 1.0 supports this absolute =
form.
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>> /martin
>>>>>>>>>>=20
>>>>>>>>>>=20
>>>>>>>>>>>          }
>>>>>>>>>>>          leaf specific-param {
>>>>>>>>>>>            type string;
>>>>>>>>>>>          }
>>>>>>>>>>>        }
>>>>>>>>>>>      }
>>>>>>>>>>>=20
>>>>>>>>>>> Jernej
>>>>>>>>>>>=20
>>>>>>>>>>>> /martin
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>=20
>>>>>>>>>>>>> Thanks, Lada
>>>>>>>>>>>>>=20
>>>>>>>>>>>>> Martin Bjorklund  writes:
>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> Ladislav Lhotka  wrote:
>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>> Y02-01 allows "must" as a substatement of "input", =
"output" and
>>>>>>>>>>>>>>> "notification" but for these cases the specification of =
the
>>>>>>>>>>>>>>> context
>>>>>>>>>>>>>>> node in sec. 7.5.3 doesn't work.
>>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>>        o The context node is the node in the accessible =
tree for
>>>>>>>>>>>>>>>        which
>>>>>>>>>>>>>>>        the
>>>>>>>>>>>>>>>           "must" statement is defined.
>>>>>>>>>>>>>> You are right.  But note how the accessible tree is =
defined.  There
>>>>>>>>>>>>>> is
>>>>>>>>>>>>>> a node for the operation / notification.  This node =
should be the
>>>>>>>>>>>>>> context node:
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>        o If the "must" statement is a substatement of a
>>>>>>>>>>>>>>        "notification"
>>>>>>>>>>>>>>           statement, the context node is the node =
representing the
>>>>>>>>>>>>>>           notification in the accessible tree.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>        o  If the "must" statement is a substatement of a =
"input"
>>>>>>>>>>>>>>           statement, the context node is the node =
representing the
>>>>>>>>>>>>>>           operation in the accessible tree.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>        o  If the "must" statement is a substatement of a =
"output"
>>>>>>>>>>>>>>           statement, the context node is the node =
representing the
>>>>>>>>>>>>>>           operation in the accessible tree.
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>>=20
>>>>>>>>>>>>>> /martin
>>>>>>>>>>>>> --=20
>>>>>>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>>>>>>>=20
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> netmod mailing list
>>>>>>>>>>>> netmod@ietf.org
>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>>>>>>=20
>>>>>>>>>> _______________________________________________
>>>>>>>>>> netmod mailing list
>>>>>>>>>> netmod@ietf.org
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>>>>=20
>>>>>>>>> _______________________________________________
>>>>>>>>> netmod mailing list
>>>>>>>>> netmod@ietf.org
>>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>> --
>>>>>>>> Ladislav Lhotka, CZ.NIC Labs
>>>>>>>> PGP Key ID: E74E8C0C
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>>>>>>> _______________________________________________
>>>>>>>> netmod mailing list
>>>>>>>> netmod@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>>=20
>>>>>>> _______________________________________________
>>>>>>> netmod mailing list
>>>>>>> netmod@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>>>=20
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Thu Dec 17 05:39:04 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9EF1B2DB9; Thu, 17 Dec 2015 05:39:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 bfD0ZpRKEm_w; Thu, 17 Dec 2015 05:38:55 -0800 (PST)
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 A44A71B2D30; Thu, 17 Dec 2015 05:38:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1545; q=dns/txt; s=iport; t=1450359535; x=1451569135; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=+YB6Jf1rROIEGcelRd0wW8VQN0GORdLikzhYpXl0pcA=; b=a6Y+JIC+pwmd2qVDDsAEZ/mc9PUP2Bk9X/1zcPSi6/GC8BtdYRFMQ68q mePAI1ZeeSlTmQ9cq5SJ03ZBTjo9izUlDHpUykhQh9UrWDO48XUI0Q4X2 cizYSG2/FyVadE59jwpHph5RMcBPp3wXdQQ6Li2KMaVbAyqnYNV/buzSv g=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B9AgCHunJW/xbLJq1ehAxtvXAOgWIXC?= =?us-ascii?q?oUiSgKBbRQBAQEBAQEBgQqENQEBBAEBARoGSwoBEAsOCgkWCwICCQMCAQIBFTA?= =?us-ascii?q?GAQwGAgEBiCsOqxiRfwEBAQEBAQEBAQEBAQEBAQEBAQEBEAUEi1SEKhEBgzuBS?= =?us-ascii?q?QWNNolHgm2BYoh5gVyERYMFhDiPPyABQ4QFPTSDOoFCAQEB?=
X-IronPort-AV: E=Sophos;i="5.20,441,1444694400";  d="asc'?scan'208";a="639125173"
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; 17 Dec 2015 13:38:32 +0000
Received: from [10.61.192.47] ([10.61.192.47]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tBHDcVgV006221; Thu, 17 Dec 2015 13:38:31 GMT
To: Nadeau Thomas , netmod WG 
References: 
From: Eliot Lear 
X-Enigmail-Draft-Status: N1110
Message-ID: <5672BAD7.2080003@cisco.com>
Date: Thu, 17 Dec 2015 14:38:31 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="E1gnH9oebBviaqk0f8D5sS88djGBweUfI"
Archived-At: 
Cc: Benoit Claise , RTG YANG Design Team 
Subject: Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 13:39:01 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--E1gnH9oebBviaqk0f8D5sS88djGBweUfI
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi everyone,

Please forgive the newbie question, but I would like to understand
whether the group has considered an ACL type that matches against a host
name.

Eliot


On 12/9/15 5:27 PM, Nadeau Thomas wrote:
> 	This email initiates a NETMOD WG Last call for draft-ietf-netmod-acl-m=
odel-06.=20
> Please review the draft and make any comments to the list by Wednesday,=
 16 December, 2015
> by 8AM EST.
>
> 	Tom and Kent (as NETMOD Co-chairs)
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>



--E1gnH9oebBviaqk0f8D5sS88djGBweUfI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJWcrrXAAoJEIe2a0bZ0nozvQEH/3gPXNr1gS89a/IIcFdk3hZ6
Y9AtH15naJCapygs1wDHwjkLY2fyZtv7dsw0tpf/dfy4U0DyV5lIZPFoyqpJCk1G
QqsnV5KrDz+rBdd/IAnu4xT0uRoiqr9MqlrOnjoEof2WJddOtpkhONdZ9ofQHGgF
lAZbIvwsh/EbnVizjLgAh8yj5HSZ5DGjncf/Gere60TM6u5Y3C69BY7MddW9mci6
d4gow+5am4SITyHsonN34NSGwQJ3jXtQboVOEOeADAklKUDwoRILULpj/Y9jVPtL
Cfqrs/0f4Ze6mgni/jpoTIwBKy+emVeZL7P8N5XS6RXpc9anuJ+gp/fpVMU/7dk=
=VFS2
-----END PGP SIGNATURE-----

--E1gnH9oebBviaqk0f8D5sS88djGBweUfI--


From nobody Thu Dec 17 05:46:36 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880EB1A1A4A; Thu, 17 Dec 2015 05:46:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 xrz965XtcbPV; Thu, 17 Dec 2015 05:46:32 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 06F061A8A10; Thu, 17 Dec 2015 05:46:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450359963; bh=LB+bVMSbzKjR+JwWloUd1rkgpPENGTeheK/d6oJb/4c=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=iVellc5voR4RISDMnduheKYcGIrTUg+AWYWSo3YG+3jaayDs2SGw/RLgCsjNEb2o7 zl0AhgSbditsgxRbVV7Ojc40xBRMq20ncU6biYuDFHCvDW7r3jOUeM95078nG3XVoW E8slzy4Gq2vmxRMO2JZ1k2Ua3PUFp+rDPmcM93QU=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Nadeau Thomas 
In-Reply-To: <5672BAD7.2080003@cisco.com>
Date: Thu, 17 Dec 2015 08:45:35 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <1B2DACE1-A8F0-493B-8B61-EF6321790ECE@lucidvision.com>
References:  <5672BAD7.2080003@cisco.com>
To: Lear Eliot 
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=4 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 216, in=2898, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: Benoit Claise , RTG YANG Design Team , netmod WG 
Subject: Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 13:46:33 -0000

	Do you mean an ASCII DNS name (versus an IP address w a mask)?

	=E2=80=94Tom

> On Dec 17, 2015:8:38 AM, at 8:38 AM, Eliot Lear  =
wrote:
>=20
> Hi everyone,
>=20
> Please forgive the newbie question, but I would like to understand
> whether the group has considered an ACL type that matches against a =
host
> name.
>=20
> Eliot
>=20
>=20
> On 12/9/15 5:27 PM, Nadeau Thomas wrote:
>> 	This email initiates a NETMOD WG Last call for =
draft-ietf-netmod-acl-model-06.=20
>> Please review the draft and make any comments to the list by =
Wednesday, 16 December, 2015
>> by 8AM EST.
>>=20
>> 	Tom and Kent (as NETMOD Co-chairs)
>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>=20
>=20


From nobody Thu Dec 17 06:34:20 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071B21B2E2E for ; Thu, 17 Dec 2015 06:34:12 -0800 (PST)
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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 yTIHTScwQ7b7 for ; Thu, 17 Dec 2015 06:34:05 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0713.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::713]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA54D1B2E30 for ; Thu, 17 Dec 2015 06:34:04 -0800 (PST)
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (TLS) id 15.1.355.16; Thu, 17 Dec 2015 14:33:42 +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.0355.012; Thu, 17 Dec 2015 14:33:42 +0000
From: Kent Watsen 
To: Robert Wilton , Nadeau Thomas , netmod WG 
Thread-Topic: [netmod] IPR Check: draft-ietf-netmod-opstate-reqs-01
Thread-Index: AQHROAOAnSEMZOp/gkmSSgkZYTg7z57NolEAgAFJr4A=
Date: Thu, 17 Dec 2015 14:33:42 +0000
Message-ID: <5AB6806F-5FCD-41FB-BBF6-F0FDEE3499EF@juniper.net>
References:  <56716CE6.9060801@cisco.com>
In-Reply-To: <56716CE6.9060801@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.151105
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.13]
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 5:Pv5yhmt7S7QBumlJ42Xi8JO8HFV8sP2lrGDkWS+/gQ3RYQL1Ebg1HtmkCrOGROZRYbe1eNBncvtGnQJO+wq1eKqdBhbq+qE6VAGs3qQFRyNenxGxMxHIten9QORVazwxJAAj77B4kXhoiPLtlBXIuA==; 24:/69maQWefFVu5PM1ZtBri0kxlAeEwNfU2JW6zHbX7f423YgKhFTkboKvraXJP08ihFWnMtxg2UODkkFgRTa1+MLgxyxa//aaF11yOkwYnug=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1443;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; 
x-forefront-prvs: 07935ACF08
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(24454002)(377454003)(164054003)(189002)(479174004)(19580395003)(11100500001)(87936001)(15975445007)(106356001)(2900100001)(86362001)(2950100001)(50986999)(83506001)(5001960100002)(92566002)(230783001)(122556002)(189998001)(19580405001)(83716003)(54356999)(5008740100001)(4001350100001)(66066001)(5001770100001)(77096005)(82746002)(99286002)(40100003)(81156007)(105586002)(97736004)(106116001)(5004730100002)(101416001)(1220700001)(586003)(102836003)(33656002)(3846002)(36756003)(5002640100001)(76176999)(1096002)(6116002)(10400500002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; 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:23
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: 17 Dec 2015 14:33:42.1907 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443
Archived-At: 
Cc: "netmod-chairs@tools.ietf.org" 
Subject: Re: [netmod] IPR Check: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 14:34:12 -0000

SSBoYXZlIG5vIG5vciBrbm93IG9mIGFueSBJUFIgQ2xhaW1zIGFnYWluc3QgdGhpcyBkb2N1bWVu
dC4NCg0KDQoNCg0KDQpPbiAxMi8xNi8xNSwgODo1MyBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2Yg
Um9iZXJ0IFdpbHRvbiIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiByd2ls
dG9uQGNpc2NvLmNvbT4gd3JvdGU6DQoNCj5JIGhhdmUgbm8gbm9yIGtub3cgb2YgYW55IElQUiBD
bGFpbXMgYWdhaW5zdCB0aGlzIGRvY3VtZW50Lg0KPg0KPlRoYW5rcywNCj5Sb2INCj4NCj4NCj5P
biAxNi8xMi8yMDE1IDEzOjEzLCBOYWRlYXUgVGhvbWFzIHdyb3RlOg0KPj4gVGhpcyBtYWlsIHN0
YXJ0cyB0aGUgSVBSIHBvbGwgb24gZHJhZnQtaWV0Zi1uZXRtb2Qtb3BzdGF0ZS1yZXFzLTAxLg0K
Pj4NCj4+IEFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQtaWV0
Zi1uZXRtb2Qtb3BzdGF0ZS1yZXFzLTAxPw0KPj4gSWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRp
c2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzDQo+PiAz
OTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpPw0KPj4NCj4+IElmIHlv
dSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSBy
ZXNwb25kIHRvIHRoaXMNCj4+IGVtYWlsIGV4cGxpY2l0bHkgcmVnYXJkbGVzcyBvZiB3aGV0aGVy
IG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuDQo+PiBUaGUgcmVzcG9u
c2UgbmVlZHMgdG8gYmUgc2VudCB0byB0aGUgTkVUTU9EIFdHIG1haWxpbmcgbGlzdC4gIFRoZSBk
b2N1bWVudA0KPj4gd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJl
c3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaA0KPj4gYXV0aG9yIGFuZCBjb250cmli
dXRvci4NCj4+DQo+PiBJZiB5b3UgYXJlIG9uIHRoZSBORVRNT0QgV0cgZW1haWwgbGlzdCBidXQg
YXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yDQo+PiBjb250cmlidXRvciwgdGhlbiBwbGVh
c2UgZXhwbGljaXRseSByZXNwb25kIG9ubHkgaWYgeW91IGFyZSBhd2FyZSBvZiBhbnkgSVBSIHRo
YXQNCj4+IGhhcyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdpdGggSUVU
RiBydWxlcy4NCj4+DQo+PiBUaGFuayB5b3UsDQo+Pg0KPj4gS2VudCBhbmQgVG9tLCBORVRNT0Qg
V0cgQ2hhaXJzDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4g
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4+IC4NCj4+DQo+
DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5uZXRt
b2QgbWFpbGluZyBsaXN0DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg==


From nobody Thu Dec 17 06:36:37 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 903641B2E3E for ; Thu, 17 Dec 2015 06:36:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level: 
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 2Ic-8ezFNr_7 for ; Thu, 17 Dec 2015 06:36:29 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0744.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::744]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC2EF1B2E3D for ; Thu, 17 Dec 2015 06:36:28 -0800 (PST)
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (TLS) id 15.1.355.16; Thu, 17 Dec 2015 14:36:08 +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.0355.012; Thu, 17 Dec 2015 14:36:08 +0000
From: Kent Watsen 
To: Ladislav Lhotka , =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= 
Thread-Topic: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
Thread-Index: AQHROF9M9GZCZpOeokmaO0YJheWZYJ7OUPEA///M+wCAAKdOAIAABuYAgAAf14A=
Date: Thu, 17 Dec 2015 14:36:08 +0000
Message-ID: <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net>
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz>
In-Reply-To: <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.151105
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.13]
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 5:kYYORwPcj41A7Q437VBePZUW23EjdyWxXCOXbeIuUFSM/BED7arVg/HG6Up9ab9xbEd6ucHxpaTfoNXy2ifv2srBmICYkqOeA4ORwrIcn/jD7/ydfURKyy+H0pqXToytYhiXD5UhMKEpeOykiP+s4Q==; 24:UOXb5lqd89yaLVB1KsKd2CXse/QZScLo9fszCvcB5kxrw6YoiKxT62pT0d84EhkVty8B6ZxZcw5EDd6MoXHs/1GV2u9hBuuEfKoLDB8OKpI=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1441;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; 
x-forefront-prvs: 07935ACF08
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(122556002)(1096002)(40100003)(86362001)(3846002)(586003)(76176999)(6116002)(5008740100001)(93886004)(50986999)(1220700001)(102836003)(230783001)(5001960100002)(106116001)(99286002)(4001350100001)(189998001)(81156007)(5001770100001)(36756003)(54356999)(5002640100001)(10400500002)(2900100001)(105586002)(11100500001)(87936001)(97736004)(33656002)(5004730100002)(77096005)(101416001)(92566002)(82746002)(2950100001)(83716003)(66066001)(83506001)(106356001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; 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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <3F74B279EFAD1E488554C481B997FB80@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2015 14:36:08.4573 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 14:36:35 -0000

DQoNCg0KDQoNCj4+PknigJltIHN0cnVnZ2xpbmcgYSBiaXQgdG8gdW5kZXJzdGFuZCB3aGF0IGlz
IG1vdGl2YXRpbmcgeW91IHRvIGFzayB0aGlzIHF1ZXN0aW9uLiAgICBUaGF0IGlzLCBhcyBhIHRv
b2wgdmVuZG9yLCBJIHdvdWxkbuKAmXQgdGhpbmsgdGhhdCBhbnkgZGVjaXNpb24gbWFkZSBoZXJl
IHdvdWxkIGFmZmVjdCB5b3UgaW1tZWRpYXRlbHkuICAgTXkgZXhwZWN0YXRpb25zIGFyZSB0aGF0
IGFueSBpbXBhY3QgdG8gWUFORy9ORVRDT05GL1JFU1RDT05GIHdvdWxkIGJlIGJhY2t3YXJkcyBj
b21wYXRpYmxlLCBzdWNoIHRoYXQgaW1wbGVtZW50YXRpb25zIHdvdWxkIG9ubHkgb3B0LWluIHdo
ZW4gbmVlZGVkIC0gYSBwYXkgYXMgeW91IGdyb3cgc3RyYXRlZ3kuICAgQnV0IGhlcmVpbiBwZXJo
YXBzIGxpZXMgYW4gdW5zdGF0ZWQgcmVxdWlyZW1lbnQsIHRoYXQgdGhlIGltcGFjdCB0byBZQU5H
L05FVENPTkYvUkVTVENPTkYgbmVlZHMgdG8gYmUgYmFja3dhcmRzIGNvbXBhdGlibGUgd2l0aCBy
ZXNwZWN0IHRvIGV4aXN0aW5nIGRlcGxveW1lbnRzLiAgRGlkIHdlIG1pc3MgaXQgb3IgaXMgaXQg
dG9vIG9idmlvdXM/DQo+Pj4gDQo+PiANCj4+IEl0IG1heSBiZSBvYnZpb3VzIGZvciBtYW55IG9m
IHVzIGJ1dCBmb3IgdGhlIHNha2Ugb2YgY29tcGxldGVuZXNzIEkNCj4+IHByZWZlciB0byBoYXZl
IHRoaXMgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgYXNzdW1wdGlvbiBleHBsaWNpdGVseQ0KPj4g
c3RhdGVkLg0KPg0KPisxDQoNCg0KW2FzIGEgY2hhaXJdDQoNCkFzIGxhc3QgY2FsbCBjb21tZW50
LCB0aGVyZSBzZWVtcyB0byBiZSBzdXBwb3J0IGZvciBhZGRpbmcgYSByZXF1aXJlbWVudCB0byB0
aGUgb3BzdGF0ZS1yZXFzIGRyYWZ0IHRvIHN0YXRlIHRoYXQgc29sdXRpb25zIHN1cHBvcnRpbmcg
c2FpZCByZXF1aXJlbWVudHMgTVVTVCBiZSBiYWNrd2FyZHMgY29tcGF0aWJsZSB3aXRoIHJlc3Bl
Y3QgdG8gZXhpc3RpbmcgZGVwbG95bWVudHMuICBEbyB3ZSBoYXZlIFdHIGNvbnNlbnN1cyB0byBh
ZGQgdGhpcyBhcyBhIHJlcXVpcmVtZW50IHRvIHRoaXMgZHJhZnQ/ICBBcmUgdGhlcmUgYW55IG9i
amVjdGlvbnM/IFBsZWFzZSB2b2ljZSB5b3VyIG9waW5pb24gYmVmb3JlIHRoZSBsYXN0IGNhbGwg
Y3V0b2ZmIGRhdGUgKERlYyAzMCkuDQoNCg0KW2FzIGEgY29udHJpYnV0b3JdDQoNCg0KSeKAmW0g
dW5zdXJlIGlmIGl0IG1ha2VzIHNlbnNlIHRvIGNhbGwgaXQgb3V0IGluIHRoaXMgZHJhZnQsIGlu
IHRoYXQgaXQgc2VlbXMgdW5pdmVyc2FsbHkgYXBwbGljYWJsZSwgYnV0IEkgZG9u4oCZdCBzZWUg
YW55IGhhcm0gaW4gaXQgZWl0aGVyIGFuZCB0aHVzIGRvIG5vdCBvYmplY3QuDQoNCg0KS2VudA0K
DQo=


From nobody Thu Dec 17 06:44:15 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8351B2E4C; Thu, 17 Dec 2015 06:44:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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_MGYH90cwzd; Thu, 17 Dec 2015 06:44:12 -0800 (PST)
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 B9AF21B2E4D; Thu, 17 Dec 2015 06:44:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1097; q=dns/txt; s=iport; t=1450363452; x=1451573052; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=Giu7gW2iyzMbNAmX2iGHRZc20/OEVr1uKuxq0nEpL4M=; b=VOAk/A3Ni2T28792igbMnpB52Fkc/lfLOr4j+4PVUffCaLuMOFKUzk5B ZGqcNE4P43lWvFVanSEAJk6+Uh7YkPwJxZE5RoKf//s1D6xUfeRssvc1Z KKdJnhxkXl20L8HvWVEjpZt/4adVh24o5ovwYPTvsUaqQg9TRVM2WJTEE o=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B5AgBLyXJW/xbLJq1ewmoOgWKGDQKBb?= =?us-ascii?q?hQBAQEBAQEBgQqENQEBBCNVARALDgoJFgsCAgkDAgECAUUGDQgBAYgrq0CSAgE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBARIJi1SHd4FJAQSNNolHgm2BYoh5iSaTdyABQ4QFP?= =?us-ascii?q?YUwAQEB?=
X-IronPort-AV: E=Sophos;i="5.20,441,1444694400";  d="asc'?scan'208";a="618328107"
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; 17 Dec 2015 14:44:09 +0000
Received: from [10.61.192.47] ([10.61.192.47]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tBHEi9Tm023376; Thu, 17 Dec 2015 14:44:09 GMT
To: Nadeau Thomas 
References:  <5672BAD7.2080003@cisco.com> <1B2DACE1-A8F0-493B-8B61-EF6321790ECE@lucidvision.com>
From: Eliot Lear 
Message-ID: <5672CA38.4060709@cisco.com>
Date: Thu, 17 Dec 2015 15:44:08 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <1B2DACE1-A8F0-493B-8B61-EF6321790ECE@lucidvision.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="N8mvX9kUXRvac0s8smPpn1eED5qJ9T5kI"
Archived-At: 
Cc: Benoit Claise , RTG YANG Design Team , netmod WG 
Subject: Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 14:44:13 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--N8mvX9kUXRvac0s8smPpn1eED5qJ9T5kI
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On 12/17/15 2:45 PM, Nadeau Thomas wrote:
> 	Do you mean an ASCII DNS name (versus an IP address w a mask)?

I was thinking of "host" in RFC 6021.

Eliot



--N8mvX9kUXRvac0s8smPpn1eED5qJ9T5kI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJWcso5AAoJEIe2a0bZ0nozAsIIAK4sLHeyowaoc87G1RNbcg9E
crzJ3lZ9AsI9Cy/wFR5UetPYGZEg1/v36/Xr4A6Y5xxpToAwBxJz8kSQiSBWGO7E
vEA6ctCT++oAwZOKpGEeLHD4eGrD8RuE1Ho9ipRy5Xg1GUbkjctybmW8v3YkDWVe
co3kd35x6+2UiVvbr94TfjRDjkNTzsEB6zFBKsg76eSZVRfOXJ7S7Z5V/NQJe5iO
OG8U/rz0x/WuGn+z0VId9/JuG3ePTW8sLB1wM+HBhqcaYGR+CbCi56kRz7xpHaZB
tRO7EUZakyc4aIpy5ZSc26FdTDFyXVQt+7J/fjDXcbDLmAX61rwjhoJATdJtclA=
=zf7w
-----END PGP SIGNATURE-----

--N8mvX9kUXRvac0s8smPpn1eED5qJ9T5kI--


From nobody Thu Dec 17 07:45:43 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3101B2ECC for ; Thu, 17 Dec 2015 07:45:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 NHC5iJdhpP3s for ; Thu, 17 Dec 2015 07:45:41 -0800 (PST)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::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 2A7A11B2EA2 for ; Thu, 17 Dec 2015 07:45:40 -0800 (PST)
Received: by mail-lb0-x22c.google.com with SMTP id kw15so47845558lbb.0 for ; Thu, 17 Dec 2015 07:45:40 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=ewZFOyhu/TO957qOOENGI/TSU/6w/PvsKVkVzZdFESw=; b=HbdVt3dflP6M9w22qtUQPzWNePoV1gN6HTtsXNFO7HCp5sL97ypYaxBO8ufYfqUqD+ PYRRnjOlTti6GFve3vVHVOnD258BWU2z2qkH/zfntHtgwuHRnSPq00iY9RgCgph/1GlI cZ0MHdJlgWVrJbbL6F7+XX9XF8mSLpvCszJHpeQik9hmcmCNy0z2MVNOkg62/VyxpaE+ ygHx3EDvWLQ5VSsHt7XlNFOlNpnt6E1O7RqyY28v46T8S/bfjzsggC97jXYtTo1D7nj8 ydsu1rnndgpkcjNhcCxMPzqRPCAcWWQ0yY8phOVjwuxeZxEjDfES4QidwoEpneTZyAn5 WbHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ewZFOyhu/TO957qOOENGI/TSU/6w/PvsKVkVzZdFESw=; b=EgbZJ+bSA9USwQn5lidKM3/3BJx9M9Ar9Sqmx0Mn4jIRMzvvvqOAxX9ReWVy4vdqcx Ovnasl914ZMSd1ZO9TjwOxXIKIalo1znjOTxb7Z+G+lPJD/PRocC7RYOGn93T4v65gB0 a2M6s6v6uTngeuO3oa24nSTzHbYAX3/KByc66Kjmv7FhHD/CyObx1Hq3u4Zoxb/w0y0x Fz/qMkb9HYs+3vqHNiIRVoYl5smR553XpO9v+owvQxhpCP9H5sMNFNa1QjFeWXKB+jOD R/HkPs6E9MU0DVPePs3nYLPY39EhS8M3gPZksTWWoJYERp35hn1RBnlDocH94AheW/zL nSQA==
X-Gm-Message-State: ALoCoQkitWNf8AVxhb29wKfK0u73lFdBSr+VbKjOLzqzxCNGV2QFUpqApQgmyAc0RA3cD9kKWPn1xpP607NxRe+Jv9qdtkPUZg==
MIME-Version: 1.0
X-Received: by 10.112.202.101 with SMTP id kh5mr21657205lbc.66.1450367139011;  Thu, 17 Dec 2015 07:45:39 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Thu, 17 Dec 2015 07:45:38 -0800 (PST)
In-Reply-To: <0AB0D1F1-666B-4E14-87D3-09F344B38651@lucidvision.com>
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <0AB0D1F1-666B-4E14-87D3-09F344B38651@lucidvision.com>
Date: Thu, 17 Dec 2015 07:45:38 -0800
Message-ID: 
From: Andy Bierman 
To: Nadeau Thomas 
Content-Type: multipart/alternative; boundary=001a11c3724c1d78ca052719eaad
Archived-At: 
Cc: "netmod-chairs@tools.ietf.org" , netmod WG 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 15:45:43 -0000

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

On Thu, Dec 17, 2015 at 4:07 AM, Nadeau Thomas 
wrote:

>
> As you know, after much discussion, the Co-chairs declared these
> requirements to be in scope and
> having consensus to proceed forward at one of the recent interim meetings=
,
> and on the mailing list to confirm.
>
>
I did not say any of the requirements are not in scope.
Apparently what is not in scope is any concept of an Applicability Statemen=
t
for this problem and its solution(s).





> =E2=80=94Tom
>

Andy


>
>
> On Dec 16, 2015:7:21 PM, at 7:21 PM, Andy Bierman 
> wrote:
>
> Hi,
>
> I have asked repeatedly for some indication of scope in these requirement=
s.
> There is an assumption all possible YANG-based platforms have intended
> and applied state that can be different for a long enough interval such
> that retrieving
> the differences is operationally useful.
>
> For devices that converge in milli-seconds or even as long as 5 seconds,
> I do not see the point of implementing solutions for these requirements.
> I would prefer that this draft specify some sort of objective
> metric for determining the solution applicability.
>
>
> Andy
>
>
> On Wed, Dec 16, 2015 at 4:10 PM, Nadeau Thomas 
> wrote:
>
>>
>>         This is a WG Last Call on draft-ietf-netmod-opstate-reqs-01.
>> Please post comments on this draft by Wednesday, December 30, 2015
>> at 9AM EST.
>>
>>         Tom/Kent
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
>

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




On Thu, Dec 17, 2015 at 4:07 AM, Nadeau Thomas <tnadeau@lucidvis=
ion.com> wrote:

	As you know, after much discussion, the Co-chairs declared these=
 requirements to be in scope and=C2=A0
having consensus to proceed forw=
ard at one of the recent interim meetings, and on the mailing list to confi=
rm.


<=
/div>
I did not say any of the requirements are not in scope.
Apparently what is not in scope is any concept of an Applicability Stateme=
nt
for this problem and its solution(s).



=C2=A0
<=
div style=3D"word-wrap:break-word">
	=E2=80=94Tom

Andy
=C2=A0
=


On Dec 16, 2015:7:21=
 PM, at 7:21 PM, Andy Bierman <andy@yumaworks.com> wrote:

Hi,

I have asked repeatedly for some indication of =
scope in these requirements.
There is an assumption all possible =
YANG-based platforms have intended
and applied state that can be =
different for a long enough interval such that retrieving
the dif=
ferences is operationally useful.

For devices that=
 converge in milli-seconds or even as long as 5 seconds,
I do not=
 see the point of implementing solutions for these requirements.
=
I would prefer that this draft specify some sort of objective
met=
ric for determining the solution applicability.

Andy


=

On Wed, Dec 16, 2015 at 4:10 PM, Nadeau Thomas <=
span dir=3D"ltr"><tnadeau@lucidvision.com> wrote:


=C2=A0 =C2=A0 =C2=A0 =C2=A0 This is a WG Last Call on draft-ietf-netmod-ops=
tate-reqs-01.

Please post comments on this draft by Wednesday, December 30, 2015

at 9AM EST.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Tom/Kent





_______________________________________________

netmod mailing list

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









--001a11c3724c1d78ca052719eaad--


From nobody Thu Dec 17 07:52:41 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1C11B2EFC for ; Thu, 17 Dec 2015 07:52:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 P-mHFPnpBAVD for ; Thu, 17 Dec 2015 07:52:38 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 3549C1B2F09 for ; Thu, 17 Dec 2015 07:52:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450367518; bh=bkXr9yGjRzkX8/Q7lINyqxikgNK8HKreEB3DX2feiV4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=LjwSzvws12WvONuP79oZwfHf4cNFEmRcwpSBnT0QQku4qeZF6y7g+DZgx+HoIcz0d VPh0OHF3owLddZQoEY8AfyzNs/7MAhO24Km0Tss3yXhZtHm+f0bFlunznTeREjRtin kyK7/9l+Hz6kcVIqtQU1EcGVHGWKFQKHqoephu/Q=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Nadeau Thomas 
In-Reply-To: <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net>
Date: Thu, 17 Dec 2015 10:52:13 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <0239ADFB-4A52-4E47-8FA5-406231AD92D5@lucidvision.com>
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net>
To: Kent Watsen 
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=6 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 216, in=2900, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 15:52:39 -0000

> On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen  =
wrote:
>=20
>=20
>=20
>=20
>=20
>=20
>>>> I=E2=80=99m struggling a bit to understand what is motivating you =
to ask this question.    That is, as a tool vendor, I wouldn=E2=80=99t =
think that any decision made here would affect you immediately.   My =
expectations are that any impact to YANG/NETCONF/RESTCONF would be =
backwards compatible, such that implementations would only opt-in when =
needed - a pay as you grow strategy.   But herein perhaps lies an =
unstated requirement, that the impact to YANG/NETCONF/RESTCONF needs to =
be backwards compatible with respect to existing deployments.  Did we =
miss it or is it too obvious?
>>>>=20
>>>=20
>>> It may be obvious for many of us but for the sake of completeness I
>>> prefer to have this backwards compatibility assumption explicitely
>>> stated.
>>=20
>> +1
>=20
>=20
> [as a chair]
>=20
> As last call comment, there seems to be support for adding a =
requirement to the opstate-reqs draft to state that solutions supporting =
said requirements MUST be backwards compatible with respect to existing =
deployments.  Do we have WG consensus to add this as a requirement to =
this draft?  Are there any objections? Please voice your opinion before =
the last call cutoff date (Dec 30).
>=20
>=20
> [as a contributor]
>=20
>=20
> I=E2=80=99m unsure if it makes sense to call it out in this draft, in =
that it seems universally applicable, but I don=E2=80=99t see any harm =
in it either and thus do not object.
>=20
>=20
> Kent

	[As Co-chair]

	Given the tall hill we climbed to get to this point on the =
requirements, I
want to be clear that there needs to be very significant support to =
change the requirements
in any significant way. We went round and round the drain on settling on =
these requirements, and=20
people had a whole host of reasonable opportunities to add this during =
those times. I want to point out that while this statement may seem =
subtle, slipping this in at the last minute could have a profound impact =
on solutions built from these requirements, so I want to be sure =
everyone involved has through through this kind of change.

	=E2=80=94Tom



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


From nobody Thu Dec 17 07:53:41 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6D31B2EFC; Thu, 17 Dec 2015 07:53:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 E5j51F1y0frK; Thu, 17 Dec 2015 07:53:38 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 0DB0A1B2EFA; Thu, 17 Dec 2015 07:53:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450367565; bh=ryfVlQfKyKzRe+24yJDwM+xzjcZP/96GcWmt52Mg12A=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=PeK0blIx+NMHLE7g3IoNqAygvCfs8zbMY1Bix3rHrN0go3ZkCCD15MtxNRMI0Cx9h GclyIw1JCJYuW6dYeOm2Pj8Thue/Zeu3VTEfpDXXJVjvKG8PskteddDs7h4ZHKkD3x TU5x8xCJ8/2s2aeXo+L1vntqHcxKoF/j+7R+MJXA=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Nadeau Thomas 
In-Reply-To: <5672CA38.4060709@cisco.com>
Date: Thu, 17 Dec 2015 10:53:13 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <5672BAD7.2080003@cisco.com> <1B2DACE1-A8F0-493B-8B61-EF6321790ECE@lucidvision.com> <5672CA38.4060709@cisco.com>
To: Lear Eliot 
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=7 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 216, in=2901, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: Benoit Claise , RTG YANG Design Team , netmod WG 
Subject: Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 15:53:39 -0000

	You raise a good point. Do the contributors/editors have any =
thoughts on
this suggestion?

	=E2=80=94Tom


> On Dec 17, 2015:9:44 AM, at 9:44 AM, Eliot Lear  =
wrote:
>=20
>=20
>=20
> On 12/17/15 2:45 PM, Nadeau Thomas wrote:
>> 	Do you mean an ASCII DNS name (versus an IP address w a mask)?
>=20
> I was thinking of "host" in RFC 6021.
>=20
> Eliot
>=20
>=20


From nobody Thu Dec 17 07:57:00 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CFB1B2F1B for ; Thu, 17 Dec 2015 07:56:59 -0800 (PST)
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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 vLJ9P7Z-A-ae for ; Thu, 17 Dec 2015 07:56:56 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0775.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::775]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BEE41B2F19 for ; Thu, 17 Dec 2015 07:56:56 -0800 (PST)
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) with Microsoft SMTP Server (TLS) id 15.1.355.16; Thu, 17 Dec 2015 15:56:37 +0000
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0355.012; Thu, 17 Dec 2015 15:56:37 +0000
From: Gert Grammel 
To: Nadeau Thomas , netmod WG 
Thread-Topic: [netmod] IPR Check: draft-ietf-netmod-opstate-reqs-01
Thread-Index: AQHROAOEBUyrbCQEKECI+g4l44C8Pp7PZ7+A
Date: Thu, 17 Dec 2015 15:56:37 +0000
Message-ID: 
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.9.151119
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [193.110.55.10]
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1609; 5:r4637mJ9QvKaLsJD1mPLclXsl2OgnTqtHODPThY6ygobnAc44gSv1BGQCF6q3dTBWd3sFzo/hSK5CyYJ1C/i2ILE1d/uvqJJp2HP/nSrBj8JCPOCT7PWM2omfVdGhCT4C0LxhWKvh7OMx6Qv1UsKXA==; 24:9B28anxfpgfLCJmFATS4NqWgg4cEP080Eu+N6YenAcU4Ns/V6Oa3/XfkDbxeDZQBHPA3boA5yWcqzzQzaLlKxYOzI7BU63l0bJQV7LkBT6o=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1609;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:CY1PR0501MB1609; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1609; 
x-forefront-prvs: 07935ACF08
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(101416001)(11100500001)(5001960100002)(5004730100002)(6116002)(586003)(189998001)(3846002)(5002640100001)(102836003)(36756003)(19580395003)(19580405001)(1220700001)(1096002)(5008740100001)(230783001)(50986999)(86362001)(105586002)(19617315012)(81156007)(87936001)(2900100001)(106356001)(106116001)(99286002)(83506001)(97736004)(2950100001)(15975445007)(77096005)(5001770100001)(92566002)(4001350100001)(40100003)(66066001)(10400500002)(54356999)(122556002)(76176999)(16236675004)(94096001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1609; H:CY1PR0501MB1609.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D2989998CB44ggrammeljunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Dec 2015 15:56:37.4047 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1609
Archived-At: 
Cc: "netmod-chairs@tools.ietf.org" 
Subject: Re: [netmod] IPR Check: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 15:56:59 -0000

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


I am not aware of any IPR

- Gert

as a contributor

From: netmod > on b=
ehalf of Thomas Nadeau >
Date: Wednesday 16 December 2015 14:13
To: "netmod@ietf.org" >
Cc: "netmod-chairs@tools.ietf.org" >
Subject: [netmod] IPR Check: draft-ietf-netmod-opstate-reqs-01

This mail starts the IPR poll on draft-ietf-netmod-opstate-reqs-01.

Are you aware of any IPR that applies to draft-ietf-netmod-opstate-reqs-01?
If so, has this IPR been disclosed in compliance with IETF IPR rules (see R=
FCs
3979, 4879, 3669 and 5378 for more details)?

If you are listed as a document author or contributor please respond to thi=
s
email explicitly regardless of whether or not you are aware of any relevant=
 IPR.
The response needs to be sent to the NETMOD WG mailing list.  The document
will not advance to the next stage until a response has been received from =
each
author and contributor.

If you are on the NETMOD WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of any IP=
R that
has not yet been disclosed in conformance with IETF rules.

Thank you,

Kent and Tom, NETMOD WG Chairs

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


--_000_D2989998CB44ggrammeljunipernet_
Content-Type: text/html; charset="us-ascii"
Content-ID: <6D3F43434DC05D4CB971AF103E9DAFAA@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable












I am not aware of any IPR







- Gert







as a contributor









From: netmod <netmod-bounces@ietf.org> on behalf of Thoma=
s Nadeau <tnadeau@lucidvision=
.com>

Date: Wednesday 16 December 2015 14=
:13

To: "netmod@ietf.org" <=
netmod@ietf.org>

Cc: "netmod-chairs@tools.ietf.org" <netmod-chairs@tools.ietf.org&g=
t;

Subject: [netmod] IPR Check: draft-=
ietf-netmod-opstate-reqs-01













This mail starts the IPR poll on draft-ietf-netmod-opstate-reqs-01.






Are you aware of any IPR that applies to draft-ietf-netmod-opstate-req=
s-01?


If so, has this IPR been disclosed in compliance with IETF IPR rules (=
see RFCs


3979, 4879, 3669 and 5378 for more details)?







If you are listed as a document author or contributor please respond t=
o this


email explicitly regardless of whether or not you are aware of any rel=
evant IPR.


The response needs to be sent to the NETMOD WG mailing list. &nbs=
p;The document


will not advance to the next stage until a response has been received =
from each


author and contributor.







If you are on the NETMOD WG email list but are not listed as an author=
 or


contributor, then please explicitly respond only if you are aware of a=
ny IPR that


has not yet been disclosed in conformance with IETF rules.







Thank you,







Kent and Tom, NETMOD WG Chairs







_______________________________________________


netmod mailing list
















--_000_D2989998CB44ggrammeljunipernet_--


From nobody Thu Dec 17 08:06:20 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8B4A1B2EED for ; Thu, 17 Dec 2015 08:06:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 aEYjn_zzWroh for ; Thu, 17 Dec 2015 08:06:13 -0800 (PST)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 297DF1B2EEC for ; Thu, 17 Dec 2015 08:06:12 -0800 (PST)
Received: by mail-lf0-x22b.google.com with SMTP id l133so54677098lfd.2 for ; Thu, 17 Dec 2015 08:06:12 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=Bq3YktJIAHiGPFn0Yn3yIQO75ror4i4LKm1i4syfuLE=; b=QaYFV6/4BuYRXTQmNCkpR8jAxOh2CgxvrwVrL92gGHzum70kQRQ9nc2tt+2uXRGZtv pKfX7W9DndLK8hUAU8/xObfcJqF0OaBzkazchadFuPoT3odyj6hrdzizWcOhl0LL3Aam +vBNNyV7EPXUpDVY0pOTP6MWSgoc8ltX7MC8bL8l4u6uVmLe1kIpFFjLefg4TTHPKTPj Uh2MPkvDdxFy72/18B5fY6JQotTBSYpXk9n979YIBAyhIUMZXZwLFewhGBg+NU9VnLhG WlA+CCZgBllUOR0t41m2biAk3u9Ju8CJPNYQTYVFlC5QkkwgH/SbP8npy1Oqcsa9MXHk F/1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Bq3YktJIAHiGPFn0Yn3yIQO75ror4i4LKm1i4syfuLE=; b=hlYD21TtwitWz9beaGkLqx6qtc3bofaKEroj/M+GhRvUnqnIepZScSRtl3JDBD+g6W nhUqqXyb7Llke0PB05/uWRtLjCKrBAgx0M18Ae62NU7D/cEQgJ18X/ja6GoQXumaRo5w iAi2DBKIkncOB0FzDWif9w4zGgjDrQ6vSEgc926wyNZRRU0Jb3pPCaRN/sFxxMUez8cO ryRiGqbGQq9Njr12SkuszAp00d9XHagvO29W2a5b2T6dt8DU+tOFfSDfE1PMBBNoXfWr r/No9L5c5jCI29u7ovAiWwTr2PoiAILKNVx8QXgjjgqGZAB6m5sA1jWv2JhQtALGLy3t GLyg==
X-Gm-Message-State: ALoCoQk1w1STzybJGPhKmZL4AZyDHrTeYGEWZxDgUOR1tk7pPIdprg0tZ03iA8K7UpcdudGoA7EXx6gzAl17HWolRamBICvZ6A==
MIME-Version: 1.0
X-Received: by 10.25.88.67 with SMTP id m64mr22353711lfb.23.1450368370349; Thu, 17 Dec 2015 08:06:10 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Thu, 17 Dec 2015 08:06:10 -0800 (PST)
In-Reply-To: <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net>
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net>
Date: Thu, 17 Dec 2015 08:06:10 -0800
Message-ID: 
From: Andy Bierman 
To: Kent Watsen 
Content-Type: multipart/alternative; boundary=001a1141a07c82417b05271a338d
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 16:06:19 -0000

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

Hi,

I agree with Juergen that this should be clear.
It was discussed several times.  All existing protocol
functionality for NETCONF and RESTCONF MUST continue to work
for clients which do not choose to examine the differences between
intended config and applied config.


Andy


On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen  wrote:

>
>
>
>
>
> >>>I=E2=80=99m struggling a bit to understand what is motivating you to a=
sk this
> question.    That is, as a tool vendor, I wouldn=E2=80=99t think that any=
 decision
> made here would affect you immediately.   My expectations are that any
> impact to YANG/NETCONF/RESTCONF would be backwards compatible, such that
> implementations would only opt-in when needed - a pay as you grow
> strategy.   But herein perhaps lies an unstated requirement, that the
> impact to YANG/NETCONF/RESTCONF needs to be backwards compatible with
> respect to existing deployments.  Did we miss it or is it too obvious?
> >>>
> >>
> >> It may be obvious for many of us but for the sake of completeness I
> >> prefer to have this backwards compatibility assumption explicitely
> >> stated.
> >
> >+1
>
>
> [as a chair]
>
> As last call comment, there seems to be support for adding a requirement
> to the opstate-reqs draft to state that solutions supporting said
> requirements MUST be backwards compatible with respect to existing
> deployments.  Do we have WG consensus to add this as a requirement to thi=
s
> draft?  Are there any objections? Please voice your opinion before the la=
st
> call cutoff date (Dec 30).
>
>
> [as a contributor]
>
>
> I=E2=80=99m unsure if it makes sense to call it out in this draft, in tha=
t it
> seems universally applicable, but I don=E2=80=99t see any harm in it eith=
er and
> thus do not object.
>
>
> Kent
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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


Hi,

I agree with Juergen that this shou=
ld be clear.
It was discussed several times.=C2=A0 All existing p=
rotocol
functionality for NETCONF and RESTCONF MUST continue to w=
ork
for clients which do not choose to examine the differences be=
tween
intended config and applied config.


Andy

<=
br>
On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen =
<kwatsen@juniper.net> wrote:










>>>I=E2=80=99m struggling a bit to understand what is motivating y=
ou to ask this question.=C2=A0 =C2=A0 That is, as a tool vendor, I wouldn=
=E2=80=99t think that any decision made here would affect you immediately.=
=C2=A0 =C2=A0My expectations are that any impact to YANG/NETCONF/RESTCONF w=
ould be backwards compatible, such that implementations would only opt-in w=
hen needed - a pay as you grow strategy.=C2=A0 =C2=A0But herein perhaps lie=
s an unstated requirement, that the impact to YANG/NETCONF/RESTCONF needs t=
o be backwards compatible with respect to existing deployments.=C2=A0 Did w=
e miss it or is it too obvious?

>>>

>>

>> It may be obvious for many of us but for the sake of completeness =
I

>> prefer to have this backwards compatibility assumption explicitely=


>> stated.

>

>+1





[as a chair]



As last call comment, there seems to be support for adding a requirement to=
 the opstate-reqs draft to state that solutions supporting said requirement=
s MUST be backwards compatible with respect to existing deployments.=C2=A0 =
Do we have WG consensus to add this as a requirement to this draft?=C2=A0 A=
re there any objections? Please voice your opinion before the last call cut=
off date (Dec 30).





[as a contributor]





I=E2=80=99m unsure if it makes sense to call it out in this draft, in that =
it seems universally applicable, but I don=E2=80=99t see any harm in it eit=
her and thus do not object.





Kent



_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a1141a07c82417b05271a338d--


From nobody Thu Dec 17 08:08:51 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 435671B2F10 for ; Thu, 17 Dec 2015 08:08:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 2dEEE0Jcda29 for ; Thu, 17 Dec 2015 08:08:46 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 951541B2F0C for ; Thu, 17 Dec 2015 08:08:46 -0800 (PST)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id 439891AE035C; Thu, 17 Dec 2015 17:08:45 +0100 (CET)
Date: Thu, 17 Dec 2015 17:09:55 +0100 (CET)
Message-Id: <20151217.170955.1627245573451317726.mbj@tail-f.com>
To: tnadeau@lucidvision.com
From: Martin Bjorklund 
In-Reply-To: <0239ADFB-4A52-4E47-8FA5-406231AD92D5@lucidvision.com>
References: <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net> <0239ADFB-4A52-4E47-8FA5-406231AD92D5@lucidvision.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 16:08:48 -0000

TmFkZWF1IFRob21hcyA8dG5hZGVhdUBsdWNpZHZpc2lvbi5jb20+IHdyb3RlOg0KPiANCj4gPiBP
biBEZWMgMTcsIDIwMTU6OTozNiBBTSwgYXQgOTozNiBBTSwgS2VudCBXYXRzZW4gPGt3YXRzZW5A
anVuaXBlci5uZXQ+DQo+ID4gd3JvdGU6DQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gDQo+
ID4gDQo+ID4+Pj4gSeKAmW0gc3RydWdnbGluZyBhIGJpdCB0byB1bmRlcnN0YW5kIHdoYXQgaXMg
bW90aXZhdGluZyB5b3UgdG8gYXNrIHRoaXMNCj4gPj4+PiBxdWVzdGlvbi4gIFRoYXQgaXMsIGFz
IGEgdG9vbCB2ZW5kb3IsIEkgd291bGRu4oCZdCB0aGluayB0aGF0IGFueQ0KPiA+Pj4+IGRlY2lz
aW9uIG1hZGUgaGVyZSB3b3VsZCBhZmZlY3QgeW91IGltbWVkaWF0ZWx5LiAgTXkgZXhwZWN0YXRp
b25zIGFyZQ0KPiA+Pj4+IHRoYXQgYW55IGltcGFjdCB0byBZQU5HL05FVENPTkYvUkVTVENPTkYg
d291bGQgYmUgYmFja3dhcmRzDQo+ID4+Pj4gY29tcGF0aWJsZSwgc3VjaCB0aGF0IGltcGxlbWVu
dGF0aW9ucyB3b3VsZCBvbmx5IG9wdC1pbiB3aGVuIG5lZWRlZCAtDQo+ID4+Pj4gYSBwYXkgYXMg
eW91IGdyb3cgc3RyYXRlZ3kuICBCdXQgaGVyZWluIHBlcmhhcHMgbGllcyBhbiB1bnN0YXRlZA0K
PiA+Pj4+IHJlcXVpcmVtZW50LCB0aGF0IHRoZSBpbXBhY3QgdG8gWUFORy9ORVRDT05GL1JFU1RD
T05GIG5lZWRzIHRvIGJlDQo+ID4+Pj4gYmFja3dhcmRzIGNvbXBhdGlibGUgd2l0aCByZXNwZWN0
IHRvIGV4aXN0aW5nIGRlcGxveW1lbnRzLiAgRGlkIHdlDQo+ID4+Pj4gbWlzcyBpdCBvciBpcyBp
dCB0b28gb2J2aW91cz8NCj4gPj4+PiANCj4gPj4+IA0KPiA+Pj4gSXQgbWF5IGJlIG9idmlvdXMg
Zm9yIG1hbnkgb2YgdXMgYnV0IGZvciB0aGUgc2FrZSBvZiBjb21wbGV0ZW5lc3MgSQ0KPiA+Pj4g
cHJlZmVyIHRvIGhhdmUgdGhpcyBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSBhc3N1bXB0aW9uIGV4
cGxpY2l0ZWx5DQo+ID4+PiBzdGF0ZWQuDQo+ID4+IA0KPiA+PiArMQ0KPiA+IA0KPiA+IA0KPiA+
IFthcyBhIGNoYWlyXQ0KPiA+IA0KPiA+IEFzIGxhc3QgY2FsbCBjb21tZW50LCB0aGVyZSBzZWVt
cyB0byBiZSBzdXBwb3J0IGZvciBhZGRpbmcgYQ0KPiA+IHJlcXVpcmVtZW50IHRvIHRoZSBvcHN0
YXRlLXJlcXMgZHJhZnQgdG8gc3RhdGUgdGhhdCBzb2x1dGlvbnMNCj4gPiBzdXBwb3J0aW5nIHNh
aWQgcmVxdWlyZW1lbnRzIE1VU1QgYmUgYmFja3dhcmRzIGNvbXBhdGlibGUgd2l0aCByZXNwZWN0
DQo+ID4gdG8gZXhpc3RpbmcgZGVwbG95bWVudHMuICBEbyB3ZSBoYXZlIFdHIGNvbnNlbnN1cyB0
byBhZGQgdGhpcyBhcyBhDQo+ID4gcmVxdWlyZW1lbnQgdG8gdGhpcyBkcmFmdD8gIEFyZSB0aGVy
ZSBhbnkgb2JqZWN0aW9ucz8gUGxlYXNlIHZvaWNlDQo+ID4geW91ciBvcGluaW9uIGJlZm9yZSB0
aGUgbGFzdCBjYWxsIGN1dG9mZiBkYXRlIChEZWMgMzApLg0KPiA+IA0KPiA+IA0KPiA+IFthcyBh
IGNvbnRyaWJ1dG9yXQ0KPiA+IA0KPiA+IA0KPiA+IEnigJltIHVuc3VyZSBpZiBpdCBtYWtlcyBz
ZW5zZSB0byBjYWxsIGl0IG91dCBpbiB0aGlzIGRyYWZ0LCBpbiB0aGF0IGl0DQo+ID4gc2VlbXMg
dW5pdmVyc2FsbHkgYXBwbGljYWJsZSwgYnV0IEkgZG9u4oCZdCBzZWUgYW55IGhhcm0gaW4gaXQg
ZWl0aGVyDQo+ID4gYW5kIHRodXMgZG8gbm90IG9iamVjdC4NCj4gPiANCj4gPiANCj4gPiBLZW50
DQo+IA0KPiAJW0FzIENvLWNoYWlyXQ0KPiANCj4gCUdpdmVuIHRoZSB0YWxsIGhpbGwgd2UgY2xp
bWJlZCB0byBnZXQgdG8gdGhpcyBwb2ludCBvbiB0aGUNCj4gCXJlcXVpcmVtZW50cywgSQ0KPiB3
YW50IHRvIGJlIGNsZWFyIHRoYXQgdGhlcmUgbmVlZHMgdG8gYmUgdmVyeSBzaWduaWZpY2FudCBz
dXBwb3J0IHRvDQo+IGNoYW5nZSB0aGUgcmVxdWlyZW1lbnRzDQo+IGluIGFueSBzaWduaWZpY2Fu
dCB3YXkuIFdlIHdlbnQgcm91bmQgYW5kIHJvdW5kIHRoZSBkcmFpbiBvbiBzZXR0bGluZw0KPiBv
biB0aGVzZSByZXF1aXJlbWVudHMsIGFuZA0KPiBwZW9wbGUgaGFkIGEgd2hvbGUgaG9zdCBvZiBy
ZWFzb25hYmxlIG9wcG9ydHVuaXRpZXMgdG8gYWRkIHRoaXMgZHVyaW5nDQo+IHRob3NlIHRpbWVz
LiBJIHdhbnQgdG8gcG9pbnQgb3V0IHRoYXQgd2hpbGUgdGhpcyBzdGF0ZW1lbnQgbWF5IHNlZW0N
Cj4gc3VidGxlLCBzbGlwcGluZyB0aGlzIGluIGF0IHRoZSBsYXN0IG1pbnV0ZSBjb3VsZCBoYXZl
IGEgcHJvZm91bmQNCj4gaW1wYWN0IG9uIHNvbHV0aW9ucyBidWlsdCBmcm9tIHRoZXNlIHJlcXVp
cmVtZW50cywgc28gSSB3YW50IHRvIGJlDQo+IHN1cmUgZXZlcnlvbmUgaW52b2x2ZWQgaGFzIHRo
cm91Z2ggdGhyb3VnaCB0aGlzIGtpbmQgb2YgY2hhbmdlLg0KDQpJIHRoaW5rIHRoaXMgaGFzIGJl
ZW4gdGFrZW4gZm9yIGdyYW50ZWQuICBBcyBzdWNoLCBpdCBpcyBub3QgcmVhbGx5IGENCmNvbXBs
ZXRlbHkgbmV3LCBsYXN0IG1pbnV0ZSwgcmVxdWlyZW1lbnQsIGFuZCBJIHRoaW5rIGl0IG1ha2Vz
IHNlbnNlDQp0byBleHBsaWNpdGx5IHN0YXRlIGl0Lg0KDQoNCi9tYXJ0aW4NCg==


From nobody Thu Dec 17 09:29:43 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83CE21B2FEC for ; Thu, 17 Dec 2015 09:29:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 EtCj-9nVtCVd for ; Thu, 17 Dec 2015 09:29:39 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCC041B2FEA for ; Thu, 17 Dec 2015 09:29:38 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D8D991311; Thu, 17 Dec 2015 18:29:36 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id PE5PgZqjV7vC; Thu, 17 Dec 2015 18:29:35 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 17 Dec 2015 18:29:35 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7DF9020056; Thu, 17 Dec 2015 18:29:35 +0100 (CET)
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 xITywDZSbsAx; Thu, 17 Dec 2015 18:29:33 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C1C9D20055; Thu, 17 Dec 2015 18:29:32 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 05DC8394176F; Thu, 17 Dec 2015 18:29:31 +0100 (CET)
Date: Thu, 17 Dec 2015 18:29:31 +0100
From: Juergen Schoenwaelder 
To: Nadeau Thomas 
Message-ID: <20151217172931.GA68858@elstar.local>
Mail-Followup-To: Nadeau Thomas , Kent Watsen , Ladislav Lhotka , "netmod@ietf.org" 
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net> <0239ADFB-4A52-4E47-8FA5-406231AD92D5@lucidvision.com>
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: <0239ADFB-4A52-4E47-8FA5-406231AD92D5@lucidvision.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 17:29:41 -0000

On Thu, Dec 17, 2015 at 10:52:13AM -0500, Nadeau Thomas wrote:
> 
> > On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen  wrote:
> > 
> > 
> > 
> > 
> > 
> > 
> >>>> I’m struggling a bit to understand what is motivating you to ask this question.    That is, as a tool vendor, I wouldn’t think that any decision made here would affect you immediately.   My expectations are that any impact to YANG/NETCONF/RESTCONF would be backwards compatible, such that implementations would only opt-in when needed - a pay as you grow strategy.   But herein perhaps lies an unstated requirement, that the impact to YANG/NETCONF/RESTCONF needs to be backwards compatible with respect to existing deployments.  Did we miss it or is it too obvious?
> >>>> 
> >>> 
> >>> It may be obvious for many of us but for the sake of completeness I
> >>> prefer to have this backwards compatibility assumption explicitely
> >>> stated.
> >> 
> >> +1
> > 
> > 
> > [as a chair]
> > 
> > As last call comment, there seems to be support for adding a requirement to the opstate-reqs draft to state that solutions supporting said requirements MUST be backwards compatible with respect to existing deployments.  Do we have WG consensus to add this as a requirement to this draft?  Are there any objections? Please voice your opinion before the last call cutoff date (Dec 30).
> > 
> > 
> > [as a contributor]
> > 
> > 
> > I’m unsure if it makes sense to call it out in this draft, in that it seems universally applicable, but I don’t see any harm in it either and thus do not object.
> > 
> > 
> > Kent
> 
> 	[As Co-chair]
> 
> 	Given the tall hill we climbed to get to this point on the requirements, I
> want to be clear that there needs to be very significant support to change the requirements
> in any significant way. We went round and round the drain on settling on these requirements, and 
> people had a whole host of reasonable opportunities to add this during those times. I want to point out that while this statement may seem subtle, slipping this in at the last minute could have a profound impact on solutions built from these requirements, so I want to be sure everyone involved has through through this kind of change.
> 
> 	—Tom

Tom,

I think Andy is talking about applicability - to which kind of servers
do these requirements apply. For example, if it takes more time on a
certain class of devices to retrieve the difference between applied
and intended config than it takes to turn intended config into applied
config, then these requirements may not be applicable (since by the
time you have finished retrieving the difference it has vanished).

Andy, did I get this right?

/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 Dec 17 09:29:56 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A251B2FEF for ; Thu, 17 Dec 2015 09:29:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 qeGnFhuYjPo7 for ; Thu, 17 Dec 2015 09:29:46 -0800 (PST)
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 D96381B2FE1 for ; Thu, 17 Dec 2015 09:29:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8986; q=dns/txt; s=iport; t=1450373386; x=1451582986; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=lu5W090s5zqPfFZWb4ITeQscC30wW7oAKGnTr3GjpOk=; b=SNqEtGLDURbccz50cM5R9uyr6B+OFwsJiiOR++gQHbVHprYppRLgs/z0 ui0IjuUQU0i4MwxHMHfqDL9BoreGvDjIs+f1uO4aL2nNNGx46UQ9jqDp/ XwXihDw368qSAIXw4RJkWSETPHfB/wH6WpxWw/eOjug/JsM/Ve5adqhL1 c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBAA88HJW/xbLJq1ehAxtv0kXAQmFI?= =?us-ascii?q?koCggYBAQEBAQGBC4Q1AQEEAQEBawoBEAsYCRYIBwkDAgECARUfEQYNBgIBARe?= =?us-ascii?q?IFA69VgEBAQEBAQEBAQEBAQEBAQEBAQEBARQEhlaEfolABZZ9jUiBXIRFgwWQA?= =?us-ascii?q?4N0ZIIRHYFWPjSEfAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.20,442,1444694400";  d="scan'208,217";a="609103221"
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; 17 Dec 2015 17:29:43 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tBHHTh7d015905; Thu, 17 Dec 2015 17:29:43 GMT
To: Andy Bierman 
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net> 
From: Robert Wilton 
Message-ID: <5672F107.2000900@cisco.com>
Date: Thu, 17 Dec 2015 17:29:43 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------050207000009010300020507"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 17:29:52 -0000

This is a multi-part message in MIME format.
--------------050207000009010300020507
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Andy,

Please can you let me know whether you think that any of the three 
proposed solutions wouldn't meet this backwards compatibility requirement?

draft-kwatsen-netmod-opstate-00 has some features that might be 
generally useful to NETCONF, like adding  support as defined 
in section 5.1, that I would expect could just be added to a future 
version of NETCONF.  Would a requirement that the solution is backwards 
compatible with existing implementations require that support for 
 must always be optional? Or could a new version of the 
NETCONF protocol require that support for  is required?

Thanks,
Rob


On 17/12/2015 16:06, Andy Bierman wrote:
> Hi,
>
> I agree with Juergen that this should be clear.
> It was discussed several times.  All existing protocol
> functionality for NETCONF and RESTCONF MUST continue to work
> for clients which do not choose to examine the differences between
> intended config and applied config.
>
>
> Andy
>
>
> On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen  > wrote:
>
>
>
>
>
>
>     >>>I’m struggling a bit to understand what is motivating you to
>     ask this question.    That is, as a tool vendor, I wouldn’t think
>     that any decision made here would affect you immediately.   My
>     expectations are that any impact to YANG/NETCONF/RESTCONF would be
>     backwards compatible, such that implementations would only opt-in
>     when needed - a pay as you grow strategy.  But herein perhaps lies
>     an unstated requirement, that the impact to YANG/NETCONF/RESTCONF
>     needs to be backwards compatible with respect to existing
>     deployments.  Did we miss it or is it too obvious?
>     >>>
>     >>
>     >> It may be obvious for many of us but for the sake of completeness I
>     >> prefer to have this backwards compatibility assumption explicitely
>     >> stated.
>     >
>     >+1
>
>
>     [as a chair]
>
>     As last call comment, there seems to be support for adding a
>     requirement to the opstate-reqs draft to state that solutions
>     supporting said requirements MUST be backwards compatible with
>     respect to existing deployments.  Do we have WG consensus to add
>     this as a requirement to this draft?  Are there any objections?
>     Please voice your opinion before the last call cutoff date (Dec 30).
>
>
>     [as a contributor]
>
>
>     I’m unsure if it makes sense to call it out in this draft, in that
>     it seems universally applicable, but I don’t see any harm in it
>     either and thus do not object.
>
>
>     Kent
>
>     _______________________________________________
>     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


--------------050207000009010300020507
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Andy,

    

    Please can you let me know whether you think that any of the three
    proposed solutions wouldn't meet this backwards compatibility
    requirement?

    

    draft-kwatsen-netmod-opstate-00 has some features that might be
    generally useful to NETCONF, like adding <get-state> support
    as defined in section 5.1, that I would expect could just be added
    to a future version of NETCONF.  Would a requirement that the
    solution is backwards compatible with existing implementations
    require that support for <get-state> must always be optional? 
    Or could a new version of the NETCONF protocol require that support
    for <get-state> is required?

    

    Thanks,

    Rob

    

    

    
On 17/12/2015 16:06, Andy Bierman
      wrote:

    

    

      
      
Hi,
        


        

        
I agree with Juergen that this should be clear.

        
It was discussed several times.  All existing protocol

        
functionality for NETCONF and RESTCONF MUST continue to
          work

        
for clients which do not choose to examine the differences
          between

        
intended config and applied config.

        


        

        


        

        
Andy

        


        

        

          


            
On Thu, Dec 17, 2015 at 6:36 AM,
              Kent Watsen <kwatsen@juniper.net>
              wrote:

              


                

                

                

                

                >>>I’m struggling a bit to understand what is
                motivating you to ask this question.    That is, as a
                tool vendor, I wouldn’t think that any decision made
                here would affect you immediately.   My expectations are
                that any impact to YANG/NETCONF/RESTCONF would be
                backwards compatible, such that implementations would
                only opt-in when needed - a pay as you grow strategy. 
                 But herein perhaps lies an unstated requirement, that
                the impact to YANG/NETCONF/RESTCONF needs to be
                backwards compatible with respect to existing
                deployments.  Did we miss it or is it too obvious?

                >>>

                >>

                >> It may be obvious for many of us but for the
                sake of completeness I

                >> prefer to have this backwards compatibility
                assumption explicitely

                >> stated.

                >

                >+1

                

                

                [as a chair]

                

                As last call comment, there seems to be support for
                adding a requirement to the opstate-reqs draft to state
                that solutions supporting said requirements MUST be
                backwards compatible with respect to existing
                deployments.  Do we have WG consensus to add this as a
                requirement to this draft?  Are there any objections?
                Please voice your opinion before the last call cutoff
                date (Dec 30).

                

                

                [as a contributor]

                

                

                I’m unsure if it makes sense to call it out in this
                draft, in that it seems universally applicable, but I
                don’t see any harm in it either and thus do not object.

                

                

                Kent

                

                _______________________________________________

                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


    

    

  


--------------050207000009010300020507--


From nobody Thu Dec 17 09:33:39 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192FC1B2FE5 for ; Thu, 17 Dec 2015 09:33:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 Xd4Ev7vtYYcX for ; Thu, 17 Dec 2015 09:33:37 -0800 (PST)
Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::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 9BB2A1B2FEA for ; Thu, 17 Dec 2015 09:33:36 -0800 (PST)
Received: by mail-lb0-x236.google.com with SMTP id kw15so49756967lbb.0 for ; Thu, 17 Dec 2015 09:33:36 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=c5lzqn+kmquzd9eE0MpQnXDsBM9nDZNqo7QGcSBaz6s=; b=btWdhwlcow4A9CpEL8dh8VN1SywXqcYkgRaXw+sWWG9OHDMlVb36rC9lWNRL7QYhYh /TB72CE9CLMhO7fDf6/DpjTlhZPzuYw7Cy/oAvImPeUCCI3nqWbVtB9/UngxYHCKdTt8 +uf84D2tzXT9bvHk6JJqeXdp9Fm4WAAO9011O3zAi+QdTE9FJjNPZj2cl9jnep/w7jDn ETvSTFagbVJDO2mpMR/wwmdiybalTOUtNmixfb708br02HC+jGEjaUMOs2KDEVEvB/Xu t+Griezmc/+o70wCrxzuMV4u0L3/5udSDdmE1WFI6ECkmif8yYy+HR5MkUBGI/mTIZC5 yrCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=c5lzqn+kmquzd9eE0MpQnXDsBM9nDZNqo7QGcSBaz6s=; b=h04AYu+lc0HHKSrnIELrxX9uEk7bTLgkq3leFOVNrwdmu7u3tuVtf3NZGXoiunFGUh OEZR3AA42dyeU8m1oe9IUPdMd2m1dQbxpgGFS5XeRaLZ8uyqGyLz/s8JTuUBQso6mDEb hxWKvNIA/B8V+KE51OhBiCzhUjpF6av860XKlT1fzsB20LC3XPUAVKR3bmqoopqm76+l YJ0XrQij6JsT3mr0ax9+lcwvyFcKgjUkLrItrT7rbgsvwt3CPB5UudJxUf+5F32iQrIh 9XbtLdSFXszsyZggYyhZ0T0xwUlwBi52YRnpsDVsNxRC3gUEPlVW8Ffzb+q+tUVAPcv+ 1tXg==
X-Gm-Message-State: ALoCoQlBGkpZ+W3aX1mTKdIaTU6ezPdPmyBlaOtM5B1iIJ5c1sW/i2RsYhkNYaR3hiKS2z/RsoiPRa7ZX6P2/IYP81jipB73yw==
MIME-Version: 1.0
X-Received: by 10.112.202.101 with SMTP id kh5mr21925302lbc.66.1450373614714;  Thu, 17 Dec 2015 09:33:34 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Thu, 17 Dec 2015 09:33:34 -0800 (PST)
In-Reply-To: <5672F107.2000900@cisco.com>
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net>  <5672F107.2000900@cisco.com>
Date: Thu, 17 Dec 2015 09:33:34 -0800
Message-ID: 
From: Andy Bierman 
To: Robert Wilton 
Content-Type: multipart/alternative; boundary=001a11c3724c18d97d05271b6c6e
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 17:33:39 -0000

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

Hi,

I am not commenting on the solution proposals.
The document being discussed is the requirements document.
I agree with Juergen that backward compatibility needs to be an
explicit requirement.  Are you objecting to such a requirement?


Andy




On Thu, Dec 17, 2015 at 9:29 AM, Robert Wilton  wrote:

> Hi Andy,
>
> Please can you let me know whether you think that any of the three
> proposed solutions wouldn't meet this backwards compatibility requirement=
?
>
> draft-kwatsen-netmod-opstate-00 has some features that might be generally
> useful to NETCONF, like adding  support as defined in section
> 5.1, that I would expect could just be added to a future version of
> NETCONF.  Would a requirement that the solution is backwards compatible
> with existing implementations require that support for  must
> always be optional?  Or could a new version of the NETCONF protocol requi=
re
> that support for  is required?
>
> Thanks,
> Rob
>
>
> On 17/12/2015 16:06, Andy Bierman wrote:
>
> Hi,
>
> I agree with Juergen that this should be clear.
> It was discussed several times.  All existing protocol
> functionality for NETCONF and RESTCONF MUST continue to work
> for clients which do not choose to examine the differences between
> intended config and applied config.
>
>
> Andy
>
>
> On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen  wrote:
>
>>
>>
>>
>>
>>
>> >>>I=E2=80=99m struggling a bit to understand what is motivating you to =
ask this
>> question.    That is, as a tool vendor, I wouldn=E2=80=99t think that an=
y decision
>> made here would affect you immediately.   My expectations are that any
>> impact to YANG/NETCONF/RESTCONF would be backwards compatible, such that
>> implementations would only opt-in when needed - a pay as you grow
>> strategy.   But herein perhaps lies an unstated requirement, that the
>> impact to YANG/NETCONF/RESTCONF needs to be backwards compatible with
>> respect to existing deployments.  Did we miss it or is it too obvious?
>> >>>
>> >>
>> >> It may be obvious for many of us but for the sake of completeness I
>> >> prefer to have this backwards compatibility assumption explicitely
>> >> stated.
>> >
>> >+1
>>
>>
>> [as a chair]
>>
>> As last call comment, there seems to be support for adding a requirement
>> to the opstate-reqs draft to state that solutions supporting said
>> requirements MUST be backwards compatible with respect to existing
>> deployments.  Do we have WG consensus to add this as a requirement to th=
is
>> draft?  Are there any objections? Please voice your opinion before the l=
ast
>> call cutoff date (Dec 30).
>>
>>
>> [as a contributor]
>>
>>
>> I=E2=80=99m unsure if it makes sense to call it out in this draft, in th=
at it
>> seems universally applicable, but I don=E2=80=99t see any harm in it eit=
her and
>> thus do not object.
>>
>>
>> Kent
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
>
> _______________________________________________
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/n=
etmod
>
>
>

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


Hi,

I am not commenting on the solution=
 proposals.
The document being discussed is the requirements docu=
ment.
I agree with Juergen that backward compatibility needs to b=
e an
explicit requirement.=C2=A0 Are you objecting to such a requ=
irement?


Andy

<=
div>


On Thu, Dec 17, 2015 at 9:29 AM, Robert Wilton <rwilton=
@cisco.com> wrote:

 =20
   =20
 =20
  

    Hi Andy,

    

    Please can you let me know whether you think that any of the three
    proposed solutions wouldn't meet this backwards compatibility
    requirement?

    

    draft-kwatsen-netmod-opstate-00 has some features that might be
    generally useful to NETCONF, like adding <get-state> support
    as defined in section 5.1, that I would expect could just be added
    to a future version of NETCONF.=C2=A0 Would a requirement that the
    solution is backwards compatible with existing implementations
    require that support for <get-state> must always be optional?=C2=
=A0
    Or could a new version of the NETCONF protocol require that support
    for <get-state> is required?

    

    Thanks,

    Rob

    

    

    
On 17/12/2015 16:06, Andy Bierman
      wrote:

    

    

     =20
      
Hi,
        


        

        
I agree with Juergen that this should be clear.

        
It was discussed several times.=C2=A0 All existing protocol
        
functionality for NETCONF and RESTCONF MUST continue to
          work

        
for clients which do not choose to examine the differences
          between

        
intended config and applied config.

        


        

        


        

        
Andy

        


        

        

          


            
On Thu, Dec 17, 2015 at 6:36 AM,
              Kent Watsen <kwatsen@juniper.net>
              wrote:

              


                

                

                

                

                >>>I=E2=80=99m struggling a bit to understand what=
 is
                motivating you to ask this question.=C2=A0 =C2=A0 That is, =
as a
                tool vendor, I wouldn=E2=80=99t think that any decision mad=
e
                here would affect you immediately.=C2=A0 =C2=A0My expectati=
ons are
                that any impact to YANG/NETCONF/RESTCONF would be
                backwards compatible, such that implementations would
                only opt-in when needed - a pay as you grow strategy.=C2=A0
                =C2=A0But herein perhaps lies an unstated requirement, that
                the impact to YANG/NETCONF/RESTCONF needs to be
                backwards compatible with respect to existing
                deployments.=C2=A0 Did we miss it or is it too obvious?

                >>>

                >>

                >> It may be obvious for many of us but for the
                sake of completeness I

                >> prefer to have this backwards compatibility
                assumption explicitely

                >> stated.

                >

                >+1

                

                

                [as a chair]

                

                As last call comment, there seems to be support for
                adding a requirement to the opstate-reqs draft to state
                that solutions supporting said requirements MUST be
                backwards compatible with respect to existing
                deployments.=C2=A0 Do we have WG consensus to add this as a
                requirement to this draft?=C2=A0 Are there any objections?
                Please voice your opinion before the last call cutoff
                date (Dec 30).

                

                

                [as a contributor]

                

                

                I=E2=80=99m unsure if it makes sense to call it out in this
                draft, in that it seems universally applicable, but I
                don=E2=80=99t see any harm in it either and thus do not obj=
ect.

                

                

                Kent

                

                _______________________________________________

                netmod mailing list

                netmod=
@ietf.org

                https://www.ietf.org/mailman/listinfo/ne=
tmod

              

            

            

          

        

      

      

      

      

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


    

    

  






--001a11c3724c18d97d05271b6c6e--


From nobody Thu Dec 17 09:41:54 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76431B3003 for ; Thu, 17 Dec 2015 09:41:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 JCzOPMGMlQ43 for ; Thu, 17 Dec 2015 09:41:51 -0800 (PST)
Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::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 59C411B3004 for ; Thu, 17 Dec 2015 09:41:50 -0800 (PST)
Received: by mail-lb0-x235.google.com with SMTP id cs9so49396575lbb.1 for ; Thu, 17 Dec 2015 09:41:50 -0800 (PST)
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:date:message-id:subject:from:to :content-type; bh=r9QI+pGz4EzckCB7DyXpEMDdIiWZDE9+zHbFhiMTZxQ=; b=gCENdIIpyAr5iyfn8BAUhS4L7UAud+3r1CmG/EU/Nm1W6BBbUepszwN4hjU8F43MnE LItZzFX0AHXkqd0oDWfMVru6tDb0OCDWk0lidtAl5V6mkSwQ+bjpSgzrsKWmQRnmsjfZ A/FJBydKrEfCO7MSfQaYzcaCIRZMFFthJFkWxlkjdNHCAflPsYbCqlb3ERm6QhUFmrnq PpYaLxkwc00Jra2bUxaBu9AkpEkPCNOZqju4ndY2ENn5xRQaVfYvnUNrb3IE+jpeQmKS 6tbGZD1KBDcxSHrl2uPFk8uNXZvkBcvH6WogGs0XxwFmIEotErMN7s3fjRla/vgMVA55 PriQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=r9QI+pGz4EzckCB7DyXpEMDdIiWZDE9+zHbFhiMTZxQ=; b=MRCV3K3Te+kcmR6dd96ywvBsVOgtSM58OfMV5gV4ptmG6un+JJTJonORS8PedVIzqC shrNAPDUm1NcPrfVPMGmimhAZLS2PwKvjWJA+oPbJ9j/Br5KACxqwt3dCuGNAHeqYRd0 nwnOUP34JYfOg2JMEMOqnHR/2MGf4OQlQ9VTtjVCZH+AkknjeJNA2cjEzZxg92Dqd4f0 0DA9sr4iQ1aZOeH4ZNP8BG4x0iraDVZ1J+cJTV2N6I9SqtVQCHcp/lB4n7/OQBOqhET9 1OfCGwl6bnjpKBSs6kgbf/yi3ri9TiyDitfgAhi/CNuQWON1DlUUfDfvjODzkfRMg3FP FkuQ==
X-Gm-Message-State: ALoCoQma7ZwNJ8xPMI4cBOjO3lPcRA+VbBXq86WF1i+A0As/SveEnRculOn0PZu2LlWf1YnoSKM60yTdnBaCag9yRlHLzhA1pQ==
MIME-Version: 1.0
X-Received: by 10.112.16.101 with SMTP id f5mr15135867lbd.30.1450374108421; Thu, 17 Dec 2015 09:41:48 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Thu, 17 Dec 2015 09:41:48 -0800 (PST)
In-Reply-To: <20151217172931.GA68858@elstar.local>
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net> <0239ADFB-4A52-4E47-8FA5-406231AD92D5@lucidvision.com> <20151217172931.GA68858@elstar.local>
Date: Thu, 17 Dec 2015 09:41:48 -0800
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder ,  Nadeau Thomas , Kent Watsen ,  Ladislav Lhotka , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=001a11c3fdfe8641ab05271b89f0
Archived-At: 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 17:41:53 -0000

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

On Thu, Dec 17, 2015 at 9:29 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Thu, Dec 17, 2015 at 10:52:13AM -0500, Nadeau Thomas wrote:
> >
> > > On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen 
> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > >>>> I=E2=80=99m struggling a bit to understand what is motivating you =
to ask
> this question.    That is, as a tool vendor, I wouldn=E2=80=99t think tha=
t any
> decision made here would affect you immediately.   My expectations are th=
at
> any impact to YANG/NETCONF/RESTCONF would be backwards compatible, such
> that implementations would only opt-in when needed - a pay as you grow
> strategy.   But herein perhaps lies an unstated requirement, that the
> impact to YANG/NETCONF/RESTCONF needs to be backwards compatible with
> respect to existing deployments.  Did we miss it or is it too obvious?
> > >>>>
> > >>>
> > >>> It may be obvious for many of us but for the sake of completeness I
> > >>> prefer to have this backwards compatibility assumption explicitely
> > >>> stated.
> > >>
> > >> +1
> > >
> > >
> > > [as a chair]
> > >
> > > As last call comment, there seems to be support for adding a
> requirement to the opstate-reqs draft to state that solutions supporting
> said requirements MUST be backwards compatible with respect to existing
> deployments.  Do we have WG consensus to add this as a requirement to thi=
s
> draft?  Are there any objections? Please voice your opinion before the la=
st
> call cutoff date (Dec 30).
> > >
> > >
> > > [as a contributor]
> > >
> > >
> > > I=E2=80=99m unsure if it makes sense to call it out in this draft, in=
 that it
> seems universally applicable, but I don=E2=80=99t see any harm in it eith=
er and
> thus do not object.
> > >
> > >
> > > Kent
> >
> >       [As Co-chair]
> >
> >       Given the tall hill we climbed to get to this point on the
> requirements, I
> > want to be clear that there needs to be very significant support to
> change the requirements
> > in any significant way. We went round and round the drain on settling o=
n
> these requirements, and
> > people had a whole host of reasonable opportunities to add this during
> those times. I want to point out that while this statement may seem subtl=
e,
> slipping this in at the last minute could have a profound impact on
> solutions built from these requirements, so I want to be sure everyone
> involved has through through this kind of change.
> >
> >       =E2=80=94Tom
>
> Tom,
>
> I think Andy is talking about applicability - to which kind of servers
> do these requirements apply. For example, if it takes more time on a
> certain class of devices to retrieve the difference between applied
> and intended config than it takes to turn intended config into applied
> config, then these requirements may not be applicable (since by the
> time you have finished retrieving the difference it has vanished).
>
> Andy, did I get this right?
>

pretty much.

I can see how the time delay is subjective and depends on the use-case
and the operator preferences.  In 1 deployment a delay of 5 seconds
is not a concern, and in another it is a concern.

The solution does not have to polling.
The server can send 1 indication when intended =3D=3D applied for the entir=
e
datastore,
or it can answer a million individual "are you done yet?" queries from the
client.
Both could be considered solutions to the same problem.


> /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
>

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




On Thu, Dec 17, 2015 at 9:29 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Dec 17, 2015 at 10:52:13AM -0500, Nadeau Tho=
mas wrote:

>

> > On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen <kwatsen@juniper.net> wrote:

> >

> >

> >

> >

> >

> >

> >>>> I=E2=80=99m struggling a bit to understand what is mo=
tivating you to ask this question.=C2=A0 =C2=A0 That is, as a tool vendor, =
I wouldn=E2=80=99t think that any decision made here would affect you immed=
iately.=C2=A0 =C2=A0My expectations are that any impact to YANG/NETCONF/RES=
TCONF would be backwards compatible, such that implementations would only o=
pt-in when needed - a pay as you grow strategy.=C2=A0 =C2=A0But herein perh=
aps lies an unstated requirement, that the impact to YANG/NETCONF/RESTCONF =
needs to be backwards compatible with respect to existing deployments.=C2=
=A0 Did we miss it or is it too obvious?

> >>>>

> >>>

> >>> It may be obvious for many of us but for the sake of comp=
leteness I

> >>> prefer to have this backwards compatibility assumption ex=
plicitely

> >>> stated.

> >>

> >> +1

> >

> >

> > [as a chair]

> >

> > As last call comment, there seems to be support for adding a requ=
irement to the opstate-reqs draft to state that solutions supporting said r=
equirements MUST be backwards compatible with respect to existing deploymen=
ts.=C2=A0 Do we have WG consensus to add this as a requirement to this draf=
t?=C2=A0 Are there any objections? Please voice your opinion before the las=
t call cutoff date (Dec 30).

> >

> >

> > [as a contributor]

> >

> >

> > I=E2=80=99m unsure if it makes sense to call it out in this draft=
, in that it seems universally applicable, but I don=E2=80=99t see any harm=
 in it either and thus do not object.

> >

> >

> > Kent

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0[As Co-chair]

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0Given the tall hill we climbed to get to thi=
s point on the requirements, I

> want to be clear that there needs to be very significant support to ch=
ange the requirements

> in any significant way. We went round and round the drain on settling =
on these requirements, and

> people had a whole host of reasonable opportunities to add this during=
 those times. I want to point out that while this statement may seem subtle=
, slipping this in at the last minute could have a profound impact on solut=
ions built from these requirements, so I want to be sure everyone involved =
has through through this kind of change.

>

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=94Tom



Tom,



I think Andy is talking about applicability - to which kind of servers

do these requirements apply. For example, if it takes more time on a

certain class of devices to retrieve the difference between applied

and intended config than it takes to turn intended config into applied

config, then these requirements may not be applicable (since by the

time you have finished retrieving the difference it has vanished).



Andy, did I get this right?

pretty much=
.

I can see how the time delay is subjective and d=
epends on the use-case
and the operator preferences.=C2=A0 In 1 d=
eployment a delay of 5 seconds
is not a concern, and in another i=
t is a concern.

The solution does not have to poll=
ing.
The server can send 1 indication when intended =3D=3D applie=
d for the entire datastore,
or it can answer a million individual=
 "are you done yet?" queries from the client.
Both =
could be considered solutions to the same problem.=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/>



_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a11c3fdfe8641ab05271b89f0--


From nobody Thu Dec 17 10:16:38 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA921B300B for ; Thu, 17 Dec 2015 10:16:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 JW8rVZQv_0OP for ; Thu, 17 Dec 2015 10:16:35 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA021A86EE for ; Thu, 17 Dec 2015 10:16:35 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DB57F14D2 for ; Thu, 17 Dec 2015 19:16:33 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id IZRe7pLO7LYk for ; Thu, 17 Dec 2015 19:16:32 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 17 Dec 2015 19:16:32 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2D68020055 for ; Thu, 17 Dec 2015 19:16:32 +0100 (CET)
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 s4rH_PrbUsME; Thu, 17 Dec 2015 19:16:30 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 604AB20056; Thu, 17 Dec 2015 19:16:30 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 8C3F93941886; Thu, 17 Dec 2015 19:16:29 +0100 (CET)
Date: Thu, 17 Dec 2015 19:16:28 +0100
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20151217181627.GB68858@elstar.local>
Mail-Followup-To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Subject: [netmod] review of draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 18:16:37 -0000

Hi,

reviewing as technical contributor....

a) Title:

     NETMOD Operational State Requirements

   I do not think having a WG name in the title is useful in the
   long-term. WGs come and go, technology stays. But likely more
   important, is the document really about 'operational state
   requirements'?  My understanding is that the document is primarily
   about the separation of intended config and applied config and not
   operational state requirements in general. Let me make a
   constructive proposal you can throw darts at...

     Separation of Intended Configuration from Applied Configuration:
     Terminology and Requirements

b) Abstract:

     This document defines requirements for servers enabling better
     visibility and control over the server's operational state.

   Do the requirements apply to _all_ servers? You later define server
   = device = system = network element but I think it is desirable if
   the abstract stands on its own. And, as stated above already, I
   think the document is not really about "enabling better visibility
   and control over the server's operational state" - it is primarily
   about the separation of Intended Configuration from Applied
   Configuration. Let me again try to make a constructive proposal:

     This document discusses the difference between intended
     configuration and applied configuration of a device and how
     intended and applied configuration relate to the operational
     state of a device. The document defines the necessary terminology
     and identifies requirements enabling visibility into the
     difference of intended configuration and applied configuration.

c) The document does not have an Introduction. I am personally OK with
   that but most RFCs do have an Introduction section. Well, the
   Gen-ART reviewers will tell us I guess.

d) I note that there is no reference to RFC 6244. For me, it seems
   Intended Configuration maps to the box 'config database' in the
   figure on page 15 of RFC 6244 and Applied Configuration is part of
   the box marked 'system software component' in RFC 6244. If this is
   correct, perhaps it is useful to spell this out. If this is
   incorrect, it is likely useful to spell this out as well. While RFC
   6244 might have its limitations, it is the only architectural
   document we have in the NETCONF and YANG space and we should
   perhaps not ignore it.

e) Title of Appendix A

   This should probably be 'in Other Documents" instead of in Other
   Drafts" since RFC 6241 is not really a "Draft".

f) Editorial: It would be nice to write terms such as
   continue-on-error always in the same way - makes searching in the
   document easier (I think I have seen Continue On Error, continue on
   error, and continue-on-error).  Same for stop-on-error and
   rollback-on-error. Or be explicit that continue-on-error means
   RFC6241 continue-on-error and Continue On Error means this
   document's continue on error.

g) Appendix A:

     The following terms were originally defined in [RFC6241], but since
     modified by the NETMOD WG:

     o  continue-on-error
     o  stop-on-error
     o  rollback-on-error

  Instead of noting the fact that terms are different, it might be
  more useful to _explain_ what the difference is between the terms
  defined in RFC 6241 the terms defined in this document. Are the
  terms defined here just a generalization to make the definition less
  protocol specific or is there also a semantic change beyond that?
  Perhaps also make it clear that the definitions provided here do not
  change the semantics of the terms defined in RFC 6241 (otherwise
  this document would have to formally update RFC 6241).

h) Appendix C: This should probably be marked with an RFC Editor
   instruction that this appendix should be removed from the final
   version.

i) Security Considerations

   I am wondering whether there are really none. For example, if
   applied and intended configuration differ for a longer period of
   time and it is not possible to observe the difference, then a
   configuration client might believe certain security policies are
   enforced while they actually are not. In other words, an attacker
   might be interested in trying to extend the period where intended
   configuration differs from applied configuration by finding ways to
   prevent the server to apply the intended configuration.

/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 Dec 17 10:18:22 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED011B2C0F for ; Thu, 17 Dec 2015 10:18:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 2fwo6rNHbDbA for ; Thu, 17 Dec 2015 10:18:18 -0800 (PST)
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 75BA51B301C for ; Thu, 17 Dec 2015 10:18:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12950; q=dns/txt; s=iport; t=1450376297; x=1451585897; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=CvA1+8bcq6+JBggROpo4IYrrhJx9BB2LAxPlJngsQtI=; b=LgNOpfZ1mZuaTJOJQRsgDMowTe+I/h9ktUJXqMmgGu/fzCLHvZ3w+4J7 5gtaUo9ejtKJ52Y7ykryDTSwA6NyusUX2ZvYwiVLunPg7LMFI7b+Spbda jy1TNMHL7Sfaf/n2P+Fd9pVJZe0yzJQw1doChddVey+S9Jj4XfBydwJFf E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBADy+3JW/xbLJq1ehAxtv0kXAQmFI?= =?us-ascii?q?koCggYBAQEBAQGBC4Q1AQEEAQEBIEsKARALGAkWCAMCAgkDAgECARUfEQYNBgI?= =?us-ascii?q?BAReIFA6rWJIAAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASGVoR+h3eBSQWWfY1Ig?= =?us-ascii?q?VyERYMFkAODdGSCER2BVj40hH0BAQE?=
X-IronPort-AV: E=Sophos;i="5.20,442,1444694400";  d="scan'208,217";a="609104900"
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; 17 Dec 2015 18:18:11 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tBHIIAXN019624; Thu, 17 Dec 2015 18:18:11 GMT
To: Andy Bierman 
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net>  <5672F107.2000900@cisco.com> 
From: Robert Wilton 
Message-ID: <5672FC62.7020509@cisco.com>
Date: Thu, 17 Dec 2015 18:18:10 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030900050801090202090307"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 18:18:20 -0000

This is a multi-part message in MIME format.
--------------030900050801090202090307
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Andy,

Please can you state the specific text that is being proposed to be 
added as a new requirement?

Thanks,
Rob


On 17/12/2015 17:33, Andy Bierman wrote:
> Hi,
>
> I am not commenting on the solution proposals.
> The document being discussed is the requirements document.
> I agree with Juergen that backward compatibility needs to be an
> explicit requirement.  Are you objecting to such a requirement?
>
>
> Andy
>
>
>
>
> On Thu, Dec 17, 2015 at 9:29 AM, Robert Wilton  > wrote:
>
>     Hi Andy,
>
>     Please can you let me know whether you think that any of the three
>     proposed solutions wouldn't meet this backwards compatibility
>     requirement?
>
>     draft-kwatsen-netmod-opstate-00 has some features that might be
>     generally useful to NETCONF, like adding  support as
>     defined in section 5.1, that I would expect could just be added to
>     a future version of NETCONF.  Would a requirement that the
>     solution is backwards compatible with existing implementations
>     require that support for  must always be optional?  Or
>     could a new version of the NETCONF protocol require that support
>     for  is required?
>
>     Thanks,
>     Rob
>
>
>     On 17/12/2015 16:06, Andy Bierman wrote:
>>     Hi,
>>
>>     I agree with Juergen that this should be clear.
>>     It was discussed several times.  All existing protocol
>>     functionality for NETCONF and RESTCONF MUST continue to work
>>     for clients which do not choose to examine the differences between
>>     intended config and applied config.
>>
>>
>>     Andy
>>
>>
>>     On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen >     > wrote:
>>
>>
>>
>>
>>
>>
>>         >>>I’m struggling a bit to understand what is motivating you
>>         to ask this question.   That is, as a tool vendor, I wouldn’t
>>         think that any decision made here would affect you
>>         immediately.   My expectations are that any impact to
>>         YANG/NETCONF/RESTCONF would be backwards compatible, such
>>         that implementations would only opt-in when needed - a pay as
>>         you grow strategy.   But herein perhaps lies an unstated
>>         requirement, that the impact to YANG/NETCONF/RESTCONF needs
>>         to be backwards compatible with respect to existing
>>         deployments.  Did we miss it or is it too obvious?
>>         >>>
>>         >>
>>         >> It may be obvious for many of us but for the sake of
>>         completeness I
>>         >> prefer to have this backwards compatibility assumption
>>         explicitely
>>         >> stated.
>>         >
>>         >+1
>>
>>
>>         [as a chair]
>>
>>         As last call comment, there seems to be support for adding a
>>         requirement to the opstate-reqs draft to state that solutions
>>         supporting said requirements MUST be backwards compatible
>>         with respect to existing deployments.  Do we have WG
>>         consensus to add this as a requirement to this draft?  Are
>>         there any objections? Please voice your opinion before the
>>         last call cutoff date (Dec 30).
>>
>>
>>         [as a contributor]
>>
>>
>>         I’m unsure if it makes sense to call it out in this draft, in
>>         that it seems universally applicable, but I don’t see any
>>         harm in it either and thus do not object.
>>
>>
>>         Kent
>>
>>         _______________________________________________
>>         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
>
>


--------------030900050801090202090307
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Andy,

    

    Please can you state the specific text that is being proposed to be
    added as a new requirement?

    

    Thanks,

    Rob

    

    

    
On 17/12/2015 17:33, Andy Bierman
      wrote:

    

    

      
      
Hi,
        


        

        
I am not commenting on the solution proposals.

        
The document being discussed is the requirements document.

        
I agree with Juergen that backward compatibility needs to
          be an

        
explicit requirement.  Are you objecting to such a
          requirement?

        


        

        


        

        
Andy

        


        

        


        

        


        

      

      


        
On Thu, Dec 17, 2015 at 9:29 AM, Robert
          Wilton <rwilton@cisco.com>
          wrote:

          

            
 Hi Andy,

              

              Please can you let me know whether you think that any of
              the three proposed solutions wouldn't meet this backwards
              compatibility requirement?

              

              draft-kwatsen-netmod-opstate-00 has some features that
              might be generally useful to NETCONF, like adding
              <get-state> support as defined in section 5.1, that
              I would expect could just be added to a future version of
              NETCONF.  Would a requirement that the solution is
              backwards compatible with existing implementations require
              that support for <get-state> must always be
              optional?  Or could a new version of the NETCONF protocol
              require that support for <get-state> is required?

              

              Thanks,

              Rob

              

              

              
On 17/12/2015 16:06, Andy Bierman wrote:

              

              

                
Hi,
                  


                  

                  
I agree with Juergen that this should be clear.

                  
It was discussed several times.  All existing
                    protocol

                  
functionality for NETCONF and RESTCONF MUST
                    continue to work

                  
for clients which do not choose to examine the
                    differences between

                  
intended config and applied config.

                  


                  

                  


                  

                  
Andy

                  


                  

                  

                    


                      
On Thu, Dec 17, 2015 at
                        6:36 AM, Kent Watsen <kwatsen@juniper.net>
                        wrote:

                        


                          

                          

                          

                          

                          >>>I’m struggling a bit to understand
                          what is motivating you to ask this question. 
                            That is, as a tool vendor, I wouldn’t think
                          that any decision made here would affect you
                          immediately.   My expectations are that any
                          impact to YANG/NETCONF/RESTCONF would be
                          backwards compatible, such that
                          implementations would only opt-in when needed
                          - a pay as you grow strategy.   But herein
                          perhaps lies an unstated requirement, that the
                          impact to YANG/NETCONF/RESTCONF needs to be
                          backwards compatible with respect to existing
                          deployments.  Did we miss it or is it too
                          obvious?

                          >>>

                          >>

                          >> It may be obvious for many of us but
                          for the sake of completeness I

                          >> prefer to have this backwards
                          compatibility assumption explicitely

                          >> stated.

                          >

                          >+1

                          

                          

                          [as a chair]

                          

                          As last call comment, there seems to be
                          support for adding a requirement to the
                          opstate-reqs draft to state that solutions
                          supporting said requirements MUST be backwards
                          compatible with respect to existing
                          deployments.  Do we have WG consensus to add
                          this as a requirement to this draft?  Are
                          there any objections? Please voice your
                          opinion before the last call cutoff date (Dec
                          30).

                          

                          

                          [as a contributor]

                          

                          

                          I’m unsure if it makes sense to call it out in
                          this draft, in that it seems universally
                          applicable, but I don’t see any harm in it
                          either and thus do not object.

                          

                          

                          Kent

                          

_______________________________________________

                          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


              

              

            

          

        

        

      

    

    

  


--------------030900050801090202090307--


From nobody Thu Dec 17 10:27:01 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFBCA1B300B for ; Thu, 17 Dec 2015 10:26:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 S6fthoMcxvHY for ; Thu, 17 Dec 2015 10:26:58 -0800 (PST)
Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (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 625751A9171 for ; Thu, 17 Dec 2015 10:26:57 -0800 (PST)
Received: by mail-lb0-x232.google.com with SMTP id cs9so50101704lbb.1 for ; Thu, 17 Dec 2015 10:26:57 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=N9dTYBpkD+5iRexReewiVwZK7QYoO2nVKt6vowiZ/Lw=; b=m4r1tReLhWaaMl3bdf70sePncqc46F789T3JO97BW2y6xZgrv8acSNrmsir0cMsmS6 iQuRsZG3cRToDHuLxMvyOByzNGETG3HnR5tBScgb3gWAtZiGljQqnCAsYOfQ4oZHvkjo eYEJnwpxeMW2mSaHtwojPuvzINfbJJ3adMXok8OLNQKznq/u7Q/Acl/m6O0L9p9LAwhA jKDcfCIHGfZznd9+yTicml/WKs1utfuXm0Ny/ZGb6ySoDwQOXOCDNb4cATh3pgxWE3dB KcRp4OH6B/j4J/eKsVjumdUdrzLH4wYLS7VZwwaBrKovmz0maWK1bsV3JcRXdWoxor7t 19fQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=N9dTYBpkD+5iRexReewiVwZK7QYoO2nVKt6vowiZ/Lw=; b=DieBVTBRI/kGdj8277V5POFPV7F/Z/by4008nd2BqSIRDWThRje1AGc9WZXpIisBF5 GSGQEN6/5ZgIY3trja9hOI/WhM9vCP+UDdsH45kU1z48qn8LgKKWCdYiYw9q3iOq7cJp CmARRPAYW6ldFWgLfrLDQz9bm8yp2Q049ARmkusECGxdHFzjKRH0OsAYzqXNzvM9sX3o CPzxkFk2+LfeKqUgWe8heA281tz4Gxr1YoNyUM4e/6pEQqB6RNppjhdDurMK6LpYSJ9Y o2fmqS/iTTXCuBHYcuFV8SnIbjPAGvQnt+v/qHI/Twhavb8p8aePzH2Wuf53L1OWstmI HoZQ==
X-Gm-Message-State: ALoCoQneba6tErHrbfn7XEcfYZp0ErF/7JKd20b8FIn75cMCk2EIqXMWGdTiUPoANt7HZUiGyq3dp7lkmeaVAPqsSAI9DMK41Q==
MIME-Version: 1.0
X-Received: by 10.112.156.39 with SMTP id wb7mr22217219lbb.96.1450376815566; Thu, 17 Dec 2015 10:26:55 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Thu, 17 Dec 2015 10:26:55 -0800 (PST)
In-Reply-To: <5672FC62.7020509@cisco.com>
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net>  <5672F107.2000900@cisco.com>  <5672FC62.7020509@cisco.com>
Date: Thu, 17 Dec 2015 10:26:55 -0800
Message-ID: 
From: Andy Bierman 
To: Robert Wilton 
Content-Type: multipart/alternative; boundary=089e0122971ee1fd1405271c2a10
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 18:27:00 -0000

--089e0122971ee1fd1405271c2a10
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

I already did that:

 All existing protocol
> functionality for NETCONF and RESTCONF MUST continue to work
> for clients which do not choose to examine the differences between
> intended config and applied config.
>
>
Another way to put it:

  The client MUST choose to participate (opt-in).

An example of a solution that meets this requirement

  - The client adds a  flag to an edit-config request
which causes the server to wait until the edit is applied before returning
.
This requires the server to opt-in for the wait, and it is not forced on
the client.


Andy



On Thu, Dec 17, 2015 at 10:18 AM, Robert Wilton  wrote:

> Hi Andy,
>
> Please can you state the specific text that is being proposed to be added
> as a new requirement?
>
> Thanks,
> Rob
>
>
> On 17/12/2015 17:33, Andy Bierman wrote:
>
> Hi,
>
> I am not commenting on the solution proposals.
> The document being discussed is the requirements document.
> I agree with Juergen that backward compatibility needs to be an
> explicit requirement.  Are you objecting to such a requirement?
>
>
> Andy
>
>
>
>
> On Thu, Dec 17, 2015 at 9:29 AM, Robert Wilton  wrote:
>
>> Hi Andy,
>>
>> Please can you let me know whether you think that any of the three
>> proposed solutions wouldn't meet this backwards compatibility requiremen=
t?
>>
>> draft-kwatsen-netmod-opstate-00 has some features that might be generall=
y
>> useful to NETCONF, like adding  support as defined in section
>> 5.1, that I would expect could just be added to a future version of
>> NETCONF.  Would a requirement that the solution is backwards compatible
>> with existing implementations require that support for  must
>> always be optional?  Or could a new version of the NETCONF protocol requ=
ire
>> that support for  is required?
>>
>> Thanks,
>> Rob
>>
>>
>> On 17/12/2015 16:06, Andy Bierman wrote:
>>
>> Hi,
>>
>> I agree with Juergen that this should be clear.
>> It was discussed several times.  All existing protocol
>> functionality for NETCONF and RESTCONF MUST continue to work
>> for clients which do not choose to examine the differences between
>> intended config and applied config.
>>
>>
>> Andy
>>
>>
>> On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen < 
>> kwatsen@juniper.net> wrote:
>>
>>>
>>>
>>>
>>>
>>>
>>> >>>I=E2=80=99m struggling a bit to understand what is motivating you to=
 ask this
>>> question.    That is, as a tool vendor, I wouldn=E2=80=99t think that a=
ny decision
>>> made here would affect you immediately.   My expectations are that any
>>> impact to YANG/NETCONF/RESTCONF would be backwards compatible, such tha=
t
>>> implementations would only opt-in when needed - a pay as you grow
>>> strategy.   But herein perhaps lies an unstated requirement, that the
>>> impact to YANG/NETCONF/RESTCONF needs to be backwards compatible with
>>> respect to existing deployments.  Did we miss it or is it too obvious?
>>> >>>
>>> >>
>>> >> It may be obvious for many of us but for the sake of completeness I
>>> >> prefer to have this backwards compatibility assumption explicitely
>>> >> stated.
>>> >
>>> >+1
>>>
>>>
>>> [as a chair]
>>>
>>> As last call comment, there seems to be support for adding a requiremen=
t
>>> to the opstate-reqs draft to state that solutions supporting said
>>> requirements MUST be backwards compatible with respect to existing
>>> deployments.  Do we have WG consensus to add this as a requirement to t=
his
>>> draft?  Are there any objections? Please voice your opinion before the =
last
>>> call cutoff date (Dec 30).
>>>
>>>
>>> [as a contributor]
>>>
>>>
>>> I=E2=80=99m unsure if it makes sense to call it out in this draft, in t=
hat it
>>> seems universally applicable, but I don=E2=80=99t see any harm in it ei=
ther and
>>> thus do not object.
>>>
>>>
>>> Kent
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>
>>
>>
>> _______________________________________________
>> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/=
netmod
>>
>>
>>
>
>

--089e0122971ee1fd1405271c2a10
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I already did that:

<=
/div>
=C2=A0All existing protocol
functionality for NETCONF and REST=
CONF MUST continue to work
for clients which do not choose to exa=
mine the differences between
intended config and applied config.<=
/div>
<=
div>

Another way to put it:

=C2=A0 The client MUST c=
hoose to participate (opt-in).

An example of a sol=
ution that meets this requirement

=C2=A0 - The cli=
ent adds a <wait-until-applied /> flag to an edit-config request
which causes the server to wait until the edit is applied before retu=
rning <rpc-reply>.
This requires the server to opt-in for t=
he wait, and it is not forced on the client.


<=
/div>
Andy

=C2=A0

On Thu, Dec 17, =
2015 at 10:18 AM, Robert Wilton <rwilton@cisco.com> wrote:

 =20
   =20
 =20
  

    Hi Andy,

    

    Please can you state the specific text that is being proposed to be
    added as a new requirement?

    

    Thanks,

    Rob

    

    

    
On 17/12/2015 17:33, Andy Bierman
      wrote:

    

    

     =20
      
Hi,
        


        

        
I am not commenting on the solution proposals.

        
The document being discussed is the requirements document.
        
I agree with Juergen that backward compatibility needs to
          be an

        
explicit requirement.=C2=A0 Are you objecting to such a
          requirement?

        


        

        


        

        
Andy

        


        

        


        

        


        

      

      


        
On Thu, Dec 17, 2015 at 9:29 AM, Robert
          Wilton <rwilton@cisco.com>
          wrote:

          

            
 Hi Andy,

              

              Please can you let me know whether you think that any of
              the three proposed solutions wouldn't meet this backwards
              compatibility requirement?

              

              draft-kwatsen-netmod-opstate-00 has some features that
              might be generally useful to NETCONF, like adding
              <get-state> support as defined in section 5.1, that
              I would expect could just be added to a future version of
              NETCONF.=C2=A0 Would a requirement that the solution is
              backwards compatible with existing implementations require
              that support for <get-state> must always be
              optional?=C2=A0 Or could a new version of the NETCONF protoco=
l
              require that support for <get-state> is required?

              

              Thanks,

              Rob

              

              

              
On 17/12/2015 16:06, Andy Bierman wrote:

              

              

                
Hi,
                  


                  

                  
I agree with Juergen that this should be clear.
                  
It was discussed several times.=C2=A0 All existing
                    protocol

                  
functionality for NETCONF and RESTCONF MUST
                    continue to work

                  
for clients which do not choose to examine the
                    differences between

                  
intended config and applied config.

                  


                  

                  


                  

                  
Andy

                  


                  

                  

                    


                      
On Thu, Dec 17, 2015 at
                        6:36 AM, Kent Watsen <kwatsen@juniper.net>
                        wrote:

                        


                          

                          

                          

                          

                          >>>I=E2=80=99m struggling a bit to under=
stand
                          what is motivating you to ask this question.=C2=
=A0
                          =C2=A0 That is, as a tool vendor, I wouldn=E2=80=
=99t think
                          that any decision made here would affect you
                          immediately.=C2=A0 =C2=A0My expectations are that=
 any
                          impact to YANG/NETCONF/RESTCONF would be
                          backwards compatible, such that
                          implementations would only opt-in when needed
                          - a pay as you grow strategy.=C2=A0 =C2=A0But her=
ein
                          perhaps lies an unstated requirement, that the
                          impact to YANG/NETCONF/RESTCONF needs to be
                          backwards compatible with respect to existing
                          deployments.=C2=A0 Did we miss it or is it too
                          obvious?

                          >>>

                          >>

                          >> It may be obvious for many of us but
                          for the sake of completeness I

                          >> prefer to have this backwards
                          compatibility assumption explicitely

                          >> stated.

                          >

                          >+1

                          

                          

                          [as a chair]

                          

                          As last call comment, there seems to be
                          support for adding a requirement to the
                          opstate-reqs draft to state that solutions
                          supporting said requirements MUST be backwards
                          compatible with respect to existing
                          deployments.=C2=A0 Do we have WG consensus to add
                          this as a requirement to this draft?=C2=A0 Are
                          there any objections? Please voice your
                          opinion before the last call cutoff date (Dec
                          30).

                          

                          

                          [as a contributor]

                          

                          

                          I=E2=80=99m unsure if it makes sense to call it o=
ut in
                          this draft, in that it seems universally
                          applicable, but I don=E2=80=99t see any harm in i=
t
                          either and thus do not object.

                          

                          

                          Kent

                          

_______________________________________________

                          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/listinfo/netmod


              

              

            

          

        

        

      

    

    

  






--089e0122971ee1fd1405271c2a10--


From nobody Thu Dec 17 13:13:05 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 405F11B30C0 for ; Thu, 17 Dec 2015 13:13:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 C6yQa4wqkv7e for ; Thu, 17 Dec 2015 13:13:02 -0800 (PST)
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 469761B30C1 for ; Thu, 17 Dec 2015 13:13:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22937; q=dns/txt; s=iport; t=1450386781; x=1451596381; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=dJB0sdY/ESUKTKth6ywIwuWrLWN0i4nLQH90hT2FWEI=; b=ES+9ppeChNSYgmCdwUOB8FJEImWekX78yhDgW5j7zCHxZfAuOtDRXrYx lNYhxOg61l/t7Qu+Y0ztRk9bOlngZgavMeCnEBuH+sOo4EFrPq5ADS6CA LQfQVRzUpCEdN3XYHPHQnEr4q+qqjoPJi14PPXhulfHgmT06Lcd+uCJqb g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvBAA4JHNW/xbLJq1egm6BHm2/SRcBC?= =?us-ascii?q?YUiSgKCCQEBAQEBAYELhDUBAQQBAQEgSwoBEAsYCRYBBwMCAgkDAgECARUfEQY?= =?us-ascii?q?NBgIBAReIFA6rYpF9AQEBAQEBAQEBAQEBAQEBAQEBARYEhlaEfoRCgzWBSQWWf?= =?us-ascii?q?Y1IgVyERYMFkAODdGSCER2BVj40hH0BAQE?=
X-IronPort-AV: E=Sophos;i="5.20,442,1444694400";  d="scan'208,217";a="609111887"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Dec 2015 21:12:59 +0000
Received: from [10.61.209.191] ([10.61.209.191]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tBHLCwZi012311; Thu, 17 Dec 2015 21:12:58 GMT
To: Andy Bierman 
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net>  <5672F107.2000900@cisco.com>  <5672FC62.7020509@cisco.com> 
From: Robert Wilton 
Message-ID: <5673255A.6030508@cisco.com>
Date: Thu, 17 Dec 2015 21:12:58 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080402060500060803050107"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 21:13:05 -0000

This is a multi-part message in MIME format.
--------------080402060500060803050107
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Andy,

Thanks for resending and apologies for missing it earlier.

Your requirement is a bit too strong for my liking.

To paraphrase your requirement text, it is forcing that all compliant 
NETCONF/RESTCONF servers MUST support any clients that do not want to 
differentiate between intended config and applied config.

However, this requires all opstate aware servers:
  - To handle a mix of clients, some of which are opstate aware, and 
some that are not.
  - To potentially handle a mix of requests, some of which are opstate 
aware requests, and some are not.

It also prevents:
  - Having a server that is implemented to only support opstate aware 
clients.
  - Having a server side configuration knob to control the behaviour 
(since it would affect the semantics for all clients).


Personally, I think that the best solutions will likely meet your 
proposed requirement below, but I don't agree that it should be 
mandated, even though I agree that it is something that the solution 
should aim for.

Changing the MUST to SHOULD would make the requirement fine with me ...

Finally, regarding your example below, I didn't think that the existing 
NETCONF protocol semantics specify exactly when the server is required 
to respond to the client, and hence blocking the client until the 
configuration has been applied would be a valid edit-config 
implementation under the existing NETCONF specification.

Thanks,
Rob


On 17/12/2015 18:26, Andy Bierman wrote:
> Hi,
>
> I already did that:
>
>>>      All existing protocol
>>>     functionality for NETCONF and RESTCONF MUST continue to work
>>>     for clients which do not choose to examine the differences between
>>>     intended config and applied config.
>>
>
> Another way to put it:
>
>   The client MUST choose to participate (opt-in).
>
> An example of a solution that meets this requirement
>
>   - The client adds a  flag to an edit-config 
> request
> which causes the server to wait until the edit is applied before 
> returning .
> This requires the server to opt-in for the wait, and it is not forced 
> on the client.
>
>
> Andy
>
>
> On Thu, Dec 17, 2015 at 10:18 AM, Robert Wilton  > wrote:
>
>     Hi Andy,
>
>     Please can you state the specific text that is being proposed to
>     be added as a new requirement?
>
>     Thanks,
>     Rob
>
>
>     On 17/12/2015 17:33, Andy Bierman wrote:
>>     Hi,
>>
>>     I am not commenting on the solution proposals.
>>     The document being discussed is the requirements document.
>>     I agree with Juergen that backward compatibility needs to be an
>>     explicit requirement.  Are you objecting to such a requirement?
>>
>>
>>     Andy
>>
>>
>>
>>
>>     On Thu, Dec 17, 2015 at 9:29 AM, Robert Wilton >     > wrote:
>>
>>         Hi Andy,
>>
>>         Please can you let me know whether you think that any of the
>>         three proposed solutions wouldn't meet this backwards
>>         compatibility requirement?
>>
>>         draft-kwatsen-netmod-opstate-00 has some features that might
>>         be generally useful to NETCONF, like adding 
>>         support as defined in section 5.1, that I would expect could
>>         just be added to a future version of NETCONF.  Would a
>>         requirement that the solution is backwards compatible with
>>         existing implementations require that support for 
>>         must always be optional?  Or could a new version of the
>>         NETCONF protocol require that support for  is
>>         required?
>>
>>         Thanks,
>>         Rob
>>
>>
>>         On 17/12/2015 16:06, Andy Bierman wrote:
>>>         Hi,
>>>
>>>         I agree with Juergen that this should be clear.
>>>         It was discussed several times.  All existing protocol
>>>         functionality for NETCONF and RESTCONF MUST continue to work
>>>         for clients which do not choose to examine the differences
>>>         between
>>>         intended config and applied config.
>>>
>>>
>>>         Andy
>>>
>>>
>>>         On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen
>>>         > wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>             >>>I’m struggling a bit to understand what is motivating
>>>             you to ask this question.    That is, as a tool vendor,
>>>             I wouldn’t think that any decision made here would
>>>             affect you immediately.   My expectations are that any
>>>             impact to YANG/NETCONF/RESTCONF would be backwards
>>>             compatible, such that implementations would only opt-in
>>>             when needed - a pay as you grow strategy.   But herein
>>>             perhaps lies an unstated requirement, that the impact to
>>>             YANG/NETCONF/RESTCONF needs to be backwards compatible
>>>             with respect to existing deployments.  Did we miss it or
>>>             is it too obvious?
>>>             >>>
>>>             >>
>>>             >> It may be obvious for many of us but for the sake of
>>>             completeness I
>>>             >> prefer to have this backwards compatibility
>>>             assumption explicitely
>>>             >> stated.
>>>             >
>>>             >+1
>>>
>>>
>>>             [as a chair]
>>>
>>>             As last call comment, there seems to be support for
>>>             adding a requirement to the opstate-reqs draft to state
>>>             that solutions supporting said requirements MUST be
>>>             backwards compatible with respect to existing
>>>             deployments.  Do we have WG consensus to add this as a
>>>             requirement to this draft?  Are there any objections?
>>>             Please voice your opinion before the last call cutoff
>>>             date (Dec 30).
>>>
>>>
>>>             [as a contributor]
>>>
>>>
>>>             I’m unsure if it makes sense to call it out in this
>>>             draft, in that it seems universally applicable, but I
>>>             don’t see any harm in it either and thus do not object.
>>>
>>>
>>>             Kent
>>>
>>>             _______________________________________________
>>>             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
>>
>>
>
>


--------------080402060500060803050107
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Andy,

    

    Thanks for resending and apologies for missing it earlier.

    

    Your requirement is a bit too strong for my liking.

    

    To paraphrase your requirement text, it is forcing that all
    compliant NETCONF/RESTCONF servers MUST support any clients that do
    not want to differentiate between intended config and applied
    config.

    

    However, this requires all opstate aware servers:

     - To handle a mix of clients, some of which are opstate aware, and
    some that are not.

     - To potentially handle a mix of requests, some of which are
    opstate aware requests, and some are not.

    

    It also prevents:

     - Having a server that is implemented to only support opstate aware
    clients.

     - Having a server side configuration knob to control the behaviour
    (since it would affect the semantics for all clients).

    

    

    Personally, I think that the best solutions will likely meet your
    proposed requirement below, but I don't agree that it should be
    mandated, even though I agree that it is something that the solution
    should aim for.

    

    Changing the MUST to SHOULD would make the requirement fine with me
    ...

    

    Finally, regarding your example below, I didn't think that the
    existing NETCONF protocol semantics specify exactly when the server
    is required to respond to the client, and hence blocking the client
    until the configuration has been applied would be a valid
    edit-config implementation under the existing NETCONF specification.

    

    Thanks,

    Rob

    

    

    
On 17/12/2015 18:26, Andy Bierman
      wrote:

    

    

      
      
Hi,
        


        

        
I already did that:

        


        

        

          

            

              

                

                  

                    

                      

                        
 All existing protocol

                        
functionality for NETCONF and RESTCONF MUST
                          continue to work

                        
for clients which do not choose to examine
                          the differences between

                        
intended config and applied config.

                      

                    

                  

                

              

            

          

        

        

          

            

              


              

              
Another way to put it:

              


              

              
  The client MUST choose to participate (opt-in).

              


              

              
An example of a solution that meets this requirement

              


              

              
  - The client adds a <wait-until-applied />
                flag to an edit-config request

              
which causes the server to wait until the edit is
                applied before returning <rpc-reply>.

              
This requires the server to opt-in for the wait, and
                it is not forced on the client.

              


              

              


              

              
Andy

              


              

              
 

            

          

        

      

      


        
On Thu, Dec 17, 2015 at 10:18 AM,
          Robert Wilton <rwilton@cisco.com>
          wrote:

          

            
 Hi Andy,

              

              Please can you state the specific text that is being
              proposed to be added as a new requirement?

              

              Thanks,

              Rob

              

              

              
On 17/12/2015 17:33, Andy Bierman wrote:

              

              

                
Hi,
                  


                  

                  
I am not commenting on the solution proposals.

                  
The document being discussed is the requirements
                    document.

                  
I agree with Juergen that backward compatibility
                    needs to be an

                  
explicit requirement.  Are you objecting to such
                    a requirement?

                  


                  

                  


                  

                  
Andy

                  


                  

                  


                  

                  


                  

                

                


                  
On Thu, Dec 17, 2015 at 9:29
                    AM, Robert Wilton <rwilton@cisco.com>
                    wrote:

                    

                      
 Hi Andy,

                        

                        Please can you let me know whether you think
                        that any of the three proposed solutions
                        wouldn't meet this backwards compatibility
                        requirement?

                        

                        draft-kwatsen-netmod-opstate-00 has some
                        features that might be generally useful to
                        NETCONF, like adding <get-state> support
                        as defined in section 5.1, that I would expect
                        could just be added to a future version of
                        NETCONF.  Would a requirement that the solution
                        is backwards compatible with existing
                        implementations require that support for
                        <get-state> must always be optional?  Or
                        could a new version of the NETCONF protocol
                        require that support for <get-state> is
                        required?

                        

                        Thanks,

                        Rob

                        

                        

                        
On 17/12/2015 16:06, Andy Bierman wrote:

                        

                        

                          
Hi,
                            


                            

                            
I agree with Juergen that this should
                              be clear.

                            
It was discussed several times.  All
                              existing protocol

                            
functionality for NETCONF and RESTCONF
                              MUST continue to work

                            
for clients which do not choose to
                              examine the differences between

                            
intended config and applied config.

                            


                            

                            


                            

                            
Andy

                            


                            

                            

                              


                                
On Thu, Dec 17,
                                  2015 at 6:36 AM, Kent Watsen <kwatsen@juniper.net>
                                  wrote:

                                  


                                    

                                    

                                    

                                    

                                    >>>I’m struggling a bit to
                                    understand what is motivating you to
                                    ask this question.    That is, as a
                                    tool vendor, I wouldn’t think that
                                    any decision made here would affect
                                    you immediately.   My expectations
                                    are that any impact to
                                    YANG/NETCONF/RESTCONF would be
                                    backwards compatible, such that
                                    implementations would only opt-in
                                    when needed - a pay as you grow
                                    strategy.   But herein perhaps lies
                                    an unstated requirement, that the
                                    impact to YANG/NETCONF/RESTCONF
                                    needs to be backwards compatible
                                    with respect to existing
                                    deployments.  Did we miss it or is
                                    it too obvious?

                                    >>>

                                    >>

                                    >> It may be obvious for many
                                    of us but for the sake of
                                    completeness I

                                    >> prefer to have this
                                    backwards compatibility assumption
                                    explicitely

                                    >> stated.

                                    >

                                    >+1

                                    

                                    

                                    [as a chair]

                                    

                                    As last call comment, there seems to
                                    be support for adding a requirement
                                    to the opstate-reqs draft to state
                                    that solutions supporting said
                                    requirements MUST be backwards
                                    compatible with respect to existing
                                    deployments.  Do we have WG
                                    consensus to add this as a
                                    requirement to this draft?  Are
                                    there any objections? Please voice
                                    your opinion before the last call
                                    cutoff date (Dec 30).

                                    

                                    

                                    [as a contributor]

                                    

                                    

                                    I’m unsure if it makes sense to call
                                    it out in this draft, in that it
                                    seems universally applicable, but I
                                    don’t see any harm in it either and
                                    thus do not object.

                                    

                                    

                                    Kent

                                    

_______________________________________________

                                    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


                        

                        

                      

                    

                  

                  

                

              

              

            

          

        

        

      

    

    

  


--------------080402060500060803050107--


From nobody Thu Dec 17 13:27:35 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57B891B30C9 for ; Thu, 17 Dec 2015 13:27:33 -0800 (PST)
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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 Pi4pnJHimpXn for ; Thu, 17 Dec 2015 13:27:30 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0777.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::777]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 421341B30CA for ; Thu, 17 Dec 2015 13:27:30 -0800 (PST)
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (TLS) id 15.1.355.16; Thu, 17 Dec 2015 21:27:12 +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.0355.012; Thu, 17 Dec 2015 21:27:12 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder , "netmod@ietf.org" 
Thread-Topic: [netmod] review of draft-ietf-netmod-opstate-reqs-01
Thread-Index: AQHROPcUricDJu8Sk0yc8T/z1+bQc57PXaAA
Date: Thu, 17 Dec 2015 21:27:12 +0000
Message-ID: <57D42158-C9B5-4CEE-959E-674EBB3EEA97@juniper.net>
References: <20151217181627.GB68858@elstar.local>
In-Reply-To: <20151217181627.GB68858@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.151105
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.13]
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 5:YkKfecMsKuWtUH3llPTD4s/k/BW4GOJ1LyEKu0B2mVkIDOvppokmfX93MfXvee8mUSNnOv6WXnXaaEM8S6sw90izkIh/fUSAG8I+qIPJtwPnSXRIQRVOLIaPL0U4W5NJM18w146rw7So6k0kR8E7sw==; 24:ZULLRGuEfPlLKKEyhXCkG7OJhvTFhjZI7w1m/jIIYxrYTg9HI4R76onbbdZazPtRca5BFRmp3rwiMS1QO/xRUe2J/l/jnM0L8G4SD9CqACc=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1441;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(10201501046)(3002001); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; 
x-forefront-prvs: 07935ACF08
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(43784003)(377454003)(24454002)(479174004)(189002)(36756003)(4001350100001)(5001960100002)(81156007)(189998001)(5001770100001)(54356999)(99286002)(106116001)(561944003)(66066001)(33656002)(2950100001)(82746002)(101416001)(83506001)(83716003)(106356001)(107886002)(15975445007)(92566002)(2900100001)(105586002)(19580395003)(10400500002)(2501003)(77096005)(97736004)(87936001)(5004730100002)(11100500001)(6116002)(76176999)(586003)(40100003)(19580405001)(1096002)(122556002)(5002640100001)(86362001)(3846002)(102836003)(50986999)(230783001)(1220700001)(5008740100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; 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:23
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: 17 Dec 2015 21:27:12.1154 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441
Archived-At: 
Subject: Re: [netmod] review of draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 21:27:33 -0000

W0FzIGEgY29udHJpYnV0b3JdDQoNClRoYW5rIHlvdSBmb3IgdGhlIHJldmlldyBKdWVyZ2VuLg0K
DQpHcmVhdCBzdWdnZXN0aW9ucy4gIElmIG5vIG9uZSBvYmplY3RzLCBJ4oCZbGwgaW5jb3Jwb3Jh
dGUgdGhlbSBpbnRvIHRoZSBuZXh0IHJldmlzaW9uIG9mIHRoZSBkb2N1bWVudCBhZnRlciBsYXN0
IGNhbGwuDQoNCk15IG9uZSBjb21tZW50IGlzIHRoYXQgSSBkb27igJl0IGJlbGlldmUgdGhlIGRv
Y3VtZW50IGlzIGxpbWl0ZWQgdG8gdGhlIGludHJvZHVjdGlvbiBvZiBhcHBsaWVkIGNvbmZpZ3Vy
YXRpb24uIEZvciBpbnN0YW5jZSwgdGhlIHJlbGF0aW5nIG9mIGNvbmZpZyB0byBkZXJpdmVkIHN0
YXRlIGFuZCBhbHNvIHRoZSBtb2RlbCBzdHJ1Y3R1cmUgcmVxdWlyZW1lbnQgYXJlIG5vdCByZWxh
dGVkIHRvIGFwcGxpZWQgY29uZmlnLiAgSW4gYWxsIGZhaXJuZXNzLCBSZXF1aXJlbWVudCAjNSAo
bW9kZWwgc3RydWN0dXJlKSBpc27igJl0IGV2ZW4gYWJvdXQgb3BlcmF0aW9uYWwgc3RhdGUuICBT
byB5b3VyIHRpdGxlIGFuZCBhYnN0cmFjdCBzdWdnZXN0aW9ucyBtaWdodCBkZWZpbmUgdG9vIG5h
cnJvdyBhIHNjb3BlLiAgU28gaG93IGFib3V0Og0KDQpUaXRsZTogVGVybWlub2xvZ3kgYW5kIFJl
cXVpcmVtZW50cyBmb3IgT3BlcmF0aW9uYWwgU3RhdGUgYW5kIE1vZGVsIFN0cnVjdHVyZQ0KQWJz
dHJhY3Q6DQogICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyByZXF1aXJlbWVudHMgZm9yIGVuaGFu
Y2luZyB0aGUgc3VwcG9ydA0KICAgICBvZiBvcGVyYXRpb25hbCBzdGF0ZSB0aHJvdWdoIHRoZSBp
bnRyb2R1Y3Rpb24gb2YgYSBjb25jZXB0dWFsDQogICAgICJhcHBsaWVkIGNvbmZpZ3VyYXRpb24i
LiAgVGhlIGRvY3VtZW50IGFsc28gZGVmaW5lcyByZXF1aXJlbWVudHMNCiAgICAgZW5hYmxpbmcg
ZGlzdGluY3QgbW9kdWxlcyB0byBsZXZlcmFnZSBhIGNvbW1vbiBtb2RlbCBzdHJ1Y3R1cmUuDQoN
Cg0KDQrigKZhbmQgYWRkIGFuIEludHJvZHVjdGlvbiBzZWN0aW9uIHRoYXQgZXhwYW5kcyBvbiB0
aGlzIHRoZW1lIGZ1cnRoZXI/DQoNClRoYW5rcyBhZ2FpbiwNCktlbnQNCg0KDQoNCg0KDQpPbiAx
Mi8xNy8xNSwgMToxNiBQTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgSnVlcmdlbiBTY2hvZW53YWVs
ZGVyIiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGouc2Nob2Vud2FlbGRl
ckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQoNCj5IaSwNCj4NCj5yZXZpZXdpbmcgYXMg
dGVjaG5pY2FsIGNvbnRyaWJ1dG9yLi4uLg0KPg0KPmEpIFRpdGxlOg0KPg0KPiAgICAgTkVUTU9E
IE9wZXJhdGlvbmFsIFN0YXRlIFJlcXVpcmVtZW50cw0KPg0KPiAgIEkgZG8gbm90IHRoaW5rIGhh
dmluZyBhIFdHIG5hbWUgaW4gdGhlIHRpdGxlIGlzIHVzZWZ1bCBpbiB0aGUNCj4gICBsb25nLXRl
cm0uIFdHcyBjb21lIGFuZCBnbywgdGVjaG5vbG9neSBzdGF5cy4gQnV0IGxpa2VseSBtb3JlDQo+
ICAgaW1wb3J0YW50LCBpcyB0aGUgZG9jdW1lbnQgcmVhbGx5IGFib3V0ICdvcGVyYXRpb25hbCBz
dGF0ZQ0KPiAgIHJlcXVpcmVtZW50cyc/ICBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhlIGRv
Y3VtZW50IGlzIHByaW1hcmlseQ0KPiAgIGFib3V0IHRoZSBzZXBhcmF0aW9uIG9mIGludGVuZGVk
IGNvbmZpZyBhbmQgYXBwbGllZCBjb25maWcgYW5kIG5vdA0KPiAgIG9wZXJhdGlvbmFsIHN0YXRl
IHJlcXVpcmVtZW50cyBpbiBnZW5lcmFsLiBMZXQgbWUgbWFrZSBhDQo+ICAgY29uc3RydWN0aXZl
IHByb3Bvc2FsIHlvdSBjYW4gdGhyb3cgZGFydHMgYXQuLi4NCj4NCj4gICAgIFNlcGFyYXRpb24g
b2YgSW50ZW5kZWQgQ29uZmlndXJhdGlvbiBmcm9tIEFwcGxpZWQgQ29uZmlndXJhdGlvbjoNCj4g
ICAgIFRlcm1pbm9sb2d5IGFuZCBSZXF1aXJlbWVudHMNCj4NCj5iKSBBYnN0cmFjdDoNCj4NCj4g
ICAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyByZXF1aXJlbWVudHMgZm9yIHNlcnZlcnMgZW5hYmxp
bmcgYmV0dGVyDQo+ICAgICB2aXNpYmlsaXR5IGFuZCBjb250cm9sIG92ZXIgdGhlIHNlcnZlcidz
IG9wZXJhdGlvbmFsIHN0YXRlLg0KPg0KPiAgIERvIHRoZSByZXF1aXJlbWVudHMgYXBwbHkgdG8g
X2FsbF8gc2VydmVycz8gWW91IGxhdGVyIGRlZmluZSBzZXJ2ZXINCj4gICA9IGRldmljZSA9IHN5
c3RlbSA9IG5ldHdvcmsgZWxlbWVudCBidXQgSSB0aGluayBpdCBpcyBkZXNpcmFibGUgaWYNCj4g
ICB0aGUgYWJzdHJhY3Qgc3RhbmRzIG9uIGl0cyBvd24uIEFuZCwgYXMgc3RhdGVkIGFib3ZlIGFs
cmVhZHksIEkNCj4gICB0aGluayB0aGUgZG9jdW1lbnQgaXMgbm90IHJlYWxseSBhYm91dCAiZW5h
YmxpbmcgYmV0dGVyIHZpc2liaWxpdHkNCj4gICBhbmQgY29udHJvbCBvdmVyIHRoZSBzZXJ2ZXIn
cyBvcGVyYXRpb25hbCBzdGF0ZSIgLSBpdCBpcyBwcmltYXJpbHkNCj4gICBhYm91dCB0aGUgc2Vw
YXJhdGlvbiBvZiBJbnRlbmRlZCBDb25maWd1cmF0aW9uIGZyb20gQXBwbGllZA0KPiAgIENvbmZp
Z3VyYXRpb24uIExldCBtZSBhZ2FpbiB0cnkgdG8gbWFrZSBhIGNvbnN0cnVjdGl2ZSBwcm9wb3Nh
bDoNCj4NCj4gICAgIFRoaXMgZG9jdW1lbnQgZGlzY3Vzc2VzIHRoZSBkaWZmZXJlbmNlIGJldHdl
ZW4gaW50ZW5kZWQNCj4gICAgIGNvbmZpZ3VyYXRpb24gYW5kIGFwcGxpZWQgY29uZmlndXJhdGlv
biBvZiBhIGRldmljZSBhbmQgaG93DQo+ICAgICBpbnRlbmRlZCBhbmQgYXBwbGllZCBjb25maWd1
cmF0aW9uIHJlbGF0ZSB0byB0aGUgb3BlcmF0aW9uYWwNCj4gICAgIHN0YXRlIG9mIGEgZGV2aWNl
LiBUaGUgZG9jdW1lbnQgZGVmaW5lcyB0aGUgbmVjZXNzYXJ5IHRlcm1pbm9sb2d5DQo+ICAgICBh
bmQgaWRlbnRpZmllcyByZXF1aXJlbWVudHMgZW5hYmxpbmcgdmlzaWJpbGl0eSBpbnRvIHRoZQ0K
PiAgICAgZGlmZmVyZW5jZSBvZiBpbnRlbmRlZCBjb25maWd1cmF0aW9uIGFuZCBhcHBsaWVkIGNv
bmZpZ3VyYXRpb24uDQo+DQo+YykgVGhlIGRvY3VtZW50IGRvZXMgbm90IGhhdmUgYW4gSW50cm9k
dWN0aW9uLiBJIGFtIHBlcnNvbmFsbHkgT0sgd2l0aA0KPiAgIHRoYXQgYnV0IG1vc3QgUkZDcyBk
byBoYXZlIGFuIEludHJvZHVjdGlvbiBzZWN0aW9uLiBXZWxsLCB0aGUNCj4gICBHZW4tQVJUIHJl
dmlld2VycyB3aWxsIHRlbGwgdXMgSSBndWVzcy4NCj4NCj5kKSBJIG5vdGUgdGhhdCB0aGVyZSBp
cyBubyByZWZlcmVuY2UgdG8gUkZDIDYyNDQuIEZvciBtZSwgaXQgc2VlbXMNCj4gICBJbnRlbmRl
ZCBDb25maWd1cmF0aW9uIG1hcHMgdG8gdGhlIGJveCAnY29uZmlnIGRhdGFiYXNlJyBpbiB0aGUN
Cj4gICBmaWd1cmUgb24gcGFnZSAxNSBvZiBSRkMgNjI0NCBhbmQgQXBwbGllZCBDb25maWd1cmF0
aW9uIGlzIHBhcnQgb2YNCj4gICB0aGUgYm94IG1hcmtlZCAnc3lzdGVtIHNvZnR3YXJlIGNvbXBv
bmVudCcgaW4gUkZDIDYyNDQuIElmIHRoaXMgaXMNCj4gICBjb3JyZWN0LCBwZXJoYXBzIGl0IGlz
IHVzZWZ1bCB0byBzcGVsbCB0aGlzIG91dC4gSWYgdGhpcyBpcw0KPiAgIGluY29ycmVjdCwgaXQg
aXMgbGlrZWx5IHVzZWZ1bCB0byBzcGVsbCB0aGlzIG91dCBhcyB3ZWxsLiBXaGlsZSBSRkMNCj4g
ICA2MjQ0IG1pZ2h0IGhhdmUgaXRzIGxpbWl0YXRpb25zLCBpdCBpcyB0aGUgb25seSBhcmNoaXRl
Y3R1cmFsDQo+ICAgZG9jdW1lbnQgd2UgaGF2ZSBpbiB0aGUgTkVUQ09ORiBhbmQgWUFORyBzcGFj
ZSBhbmQgd2Ugc2hvdWxkDQo+ICAgcGVyaGFwcyBub3QgaWdub3JlIGl0Lg0KPg0KPmUpIFRpdGxl
IG9mIEFwcGVuZGl4IEENCj4NCj4gICBUaGlzIHNob3VsZCBwcm9iYWJseSBiZSAnaW4gT3RoZXIg
RG9jdW1lbnRzIiBpbnN0ZWFkIG9mIGluIE90aGVyDQo+ICAgRHJhZnRzIiBzaW5jZSBSRkMgNjI0
MSBpcyBub3QgcmVhbGx5IGEgIkRyYWZ0Ii4NCj4NCj5mKSBFZGl0b3JpYWw6IEl0IHdvdWxkIGJl
IG5pY2UgdG8gd3JpdGUgdGVybXMgc3VjaCBhcw0KPiAgIGNvbnRpbnVlLW9uLWVycm9yIGFsd2F5
cyBpbiB0aGUgc2FtZSB3YXkgLSBtYWtlcyBzZWFyY2hpbmcgaW4gdGhlDQo+ICAgZG9jdW1lbnQg
ZWFzaWVyIChJIHRoaW5rIEkgaGF2ZSBzZWVuIENvbnRpbnVlIE9uIEVycm9yLCBjb250aW51ZSBv
bg0KPiAgIGVycm9yLCBhbmQgY29udGludWUtb24tZXJyb3IpLiAgU2FtZSBmb3Igc3RvcC1vbi1l
cnJvciBhbmQNCj4gICByb2xsYmFjay1vbi1lcnJvci4gT3IgYmUgZXhwbGljaXQgdGhhdCBjb250
aW51ZS1vbi1lcnJvciBtZWFucw0KPiAgIFJGQzYyNDEgY29udGludWUtb24tZXJyb3IgYW5kIENv
bnRpbnVlIE9uIEVycm9yIG1lYW5zIHRoaXMNCj4gICBkb2N1bWVudCdzIGNvbnRpbnVlIG9uIGVy
cm9yLg0KPg0KPmcpIEFwcGVuZGl4IEE6DQo+DQo+ICAgICBUaGUgZm9sbG93aW5nIHRlcm1zIHdl
cmUgb3JpZ2luYWxseSBkZWZpbmVkIGluIFtSRkM2MjQxXSwgYnV0IHNpbmNlDQo+ICAgICBtb2Rp
ZmllZCBieSB0aGUgTkVUTU9EIFdHOg0KPg0KPiAgICAgbyAgY29udGludWUtb24tZXJyb3INCj4g
ICAgIG8gIHN0b3Atb24tZXJyb3INCj4gICAgIG8gIHJvbGxiYWNrLW9uLWVycm9yDQo+DQo+ICBJ
bnN0ZWFkIG9mIG5vdGluZyB0aGUgZmFjdCB0aGF0IHRlcm1zIGFyZSBkaWZmZXJlbnQsIGl0IG1p
Z2h0IGJlDQo+ICBtb3JlIHVzZWZ1bCB0byBfZXhwbGFpbl8gd2hhdCB0aGUgZGlmZmVyZW5jZSBp
cyBiZXR3ZWVuIHRoZSB0ZXJtcw0KPiAgZGVmaW5lZCBpbiBSRkMgNjI0MSB0aGUgdGVybXMgZGVm
aW5lZCBpbiB0aGlzIGRvY3VtZW50LiBBcmUgdGhlDQo+ICB0ZXJtcyBkZWZpbmVkIGhlcmUganVz
dCBhIGdlbmVyYWxpemF0aW9uIHRvIG1ha2UgdGhlIGRlZmluaXRpb24gbGVzcw0KPiAgcHJvdG9j
b2wgc3BlY2lmaWMgb3IgaXMgdGhlcmUgYWxzbyBhIHNlbWFudGljIGNoYW5nZSBiZXlvbmQgdGhh
dD8NCj4gIFBlcmhhcHMgYWxzbyBtYWtlIGl0IGNsZWFyIHRoYXQgdGhlIGRlZmluaXRpb25zIHBy
b3ZpZGVkIGhlcmUgZG8gbm90DQo+ICBjaGFuZ2UgdGhlIHNlbWFudGljcyBvZiB0aGUgdGVybXMg
ZGVmaW5lZCBpbiBSRkMgNjI0MSAob3RoZXJ3aXNlDQo+ICB0aGlzIGRvY3VtZW50IHdvdWxkIGhh
dmUgdG8gZm9ybWFsbHkgdXBkYXRlIFJGQyA2MjQxKS4NCj4NCj5oKSBBcHBlbmRpeCBDOiBUaGlz
IHNob3VsZCBwcm9iYWJseSBiZSBtYXJrZWQgd2l0aCBhbiBSRkMgRWRpdG9yDQo+ICAgaW5zdHJ1
Y3Rpb24gdGhhdCB0aGlzIGFwcGVuZGl4IHNob3VsZCBiZSByZW1vdmVkIGZyb20gdGhlIGZpbmFs
DQo+ICAgdmVyc2lvbi4NCj4NCj5pKSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KPg0KPiAgIEkg
YW0gd29uZGVyaW5nIHdoZXRoZXIgdGhlcmUgYXJlIHJlYWxseSBub25lLiBGb3IgZXhhbXBsZSwg
aWYNCj4gICBhcHBsaWVkIGFuZCBpbnRlbmRlZCBjb25maWd1cmF0aW9uIGRpZmZlciBmb3IgYSBs
b25nZXIgcGVyaW9kIG9mDQo+ICAgdGltZSBhbmQgaXQgaXMgbm90IHBvc3NpYmxlIHRvIG9ic2Vy
dmUgdGhlIGRpZmZlcmVuY2UsIHRoZW4gYQ0KPiAgIGNvbmZpZ3VyYXRpb24gY2xpZW50IG1pZ2h0
IGJlbGlldmUgY2VydGFpbiBzZWN1cml0eSBwb2xpY2llcyBhcmUNCj4gICBlbmZvcmNlZCB3aGls
ZSB0aGV5IGFjdHVhbGx5IGFyZSBub3QuIEluIG90aGVyIHdvcmRzLCBhbiBhdHRhY2tlcg0KPiAg
IG1pZ2h0IGJlIGludGVyZXN0ZWQgaW4gdHJ5aW5nIHRvIGV4dGVuZCB0aGUgcGVyaW9kIHdoZXJl
IGludGVuZGVkDQo+ICAgY29uZmlndXJhdGlvbiBkaWZmZXJzIGZyb20gYXBwbGllZCBjb25maWd1
cmF0aW9uIGJ5IGZpbmRpbmcgd2F5cyB0bw0KPiAgIHByZXZlbnQgdGhlIHNlcnZlciB0byBhcHBs
eSB0aGUgaW50ZW5kZWQgY29uZmlndXJhdGlvbi4NCj4NCj4vanMNCj4NCj4tLSANCj5KdWVyZ2Vu
IFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0K
PlBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJy
ZW1lbiB8IEdlcm1hbnkNCj5GYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8v
d3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0KPm5ldG1vZCBtYWlsaW5nIGxpc3QNCj5uZXRtb2RAaWV0
Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K


From nobody Thu Dec 17 13:52:32 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327051B30F0 for ; Thu, 17 Dec 2015 13:52:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 vBqkjzO15nmH for ; Thu, 17 Dec 2015 13:52:25 -0800 (PST)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::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 1E1FC1B30EE for ; Thu, 17 Dec 2015 13:52:25 -0800 (PST)
Received: by mail-lb0-x22b.google.com with SMTP id cs9so52955579lbb.1 for ; Thu, 17 Dec 2015 13:52:25 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=kbzQKx8I9+FmQZOjqrt4Hnt/qaO4dbqGk5qIKclem9E=; b=EZ6JqIEWUlEtRpUz4sZMlpbYzP82tSTy+yfyuCRzt4a3Nw4KMNAXt9w6DWnWfPGgmR 7x2qPIeeLGGOd+fppmvFIgXDMf6ybj3jDbkJhvv/nP7gDVS3SFESnzzsrJEr5DeUp4UN 1QReyaoe2/Xmm3Ko16/Ae4R8eWHQfiasr1db/YiQNfq9RYt9koPwUHaHMI9c+BYEfzkZ mV5HnoeZjAyrSYNbO8bxEqKsRdhCLjaT6TOQ9KEYiDXWVYOs2hAIBK+e6cxB+SR0kGDu GQMXbaLV/91NckkMeugeGFnQ9CjA0O0Pa5Ga8OQOYMB/E/0RiOEXCkeQj0pR+7MgqCs1 bkSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=kbzQKx8I9+FmQZOjqrt4Hnt/qaO4dbqGk5qIKclem9E=; b=QJJEL3mgP6rtpYzKCRTMP8h21BW6WUN1K66XFcjhr0ghZAPoYevBDuIvafMDJNfjx9 qSeBa3v/1Zsu4LhwwM1+4OXGhzWo944WaSi+hhuBsouyur/ffzTmILQvhiRDN/LFJqHb Wn6QSWIilkqX2lBViItuQaspieU9ex0pKUQS89ceMf99Jv6XvIIjmBohKOb8G8tBJBId +sGA6BfGZkqmZCk90laGa14RO+p4reQdon9P6Nkslgth3inMgYUBM0fuP9SkPJD9YhV4 XnB+Npvj6t/B9ICwutdVNoCW6gqaxY0VlBMydvR8L1m4GBddCx376PGIoQwMZEJqViBx jzyQ==
X-Gm-Message-State: ALoCoQmjbRw2l/aCxy9D2umc4NNVMvkiOKDBV+29KCRdSO0UtqTsj9ErsZ18TF+c+LgH/wGR/t3spsuVyRKi94bPQLW//mEZbw==
MIME-Version: 1.0
X-Received: by 10.112.202.101 with SMTP id kh5mr37132lbc.66.1450389143250; Thu, 17 Dec 2015 13:52:23 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Thu, 17 Dec 2015 13:52:23 -0800 (PST)
In-Reply-To: <5673255A.6030508@cisco.com>
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net>  <5672F107.2000900@cisco.com>  <5672FC62.7020509@cisco.com>  <5673255A.6030508@cisco.com>
Date: Thu, 17 Dec 2015 13:52:23 -0800
Message-ID: 
From: Andy Bierman 
To: Robert Wilton 
Content-Type: multipart/alternative; boundary=001a11c3724cab7f9f05271f09c3
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 21:52:29 -0000

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

Hi,

I think the current operations need to continue to work.
With the current  or  the client does
not know if the server applied the config or just accepted the request.

With the new solution, I expect that a client that does not explicitly ask
for "wait until applied" will get the old (unspecified) behavior.


Andy



On Thu, Dec 17, 2015 at 1:12 PM, Robert Wilton  wrote:

> Hi Andy,
>
> Thanks for resending and apologies for missing it earlier.
>
> Your requirement is a bit too strong for my liking.
>
> To paraphrase your requirement text, it is forcing that all compliant
> NETCONF/RESTCONF servers MUST support any clients that do not want to
> differentiate between intended config and applied config.
>
> However, this requires all opstate aware servers:
>  - To handle a mix of clients, some of which are opstate aware, and some
> that are not.
>  - To potentially handle a mix of requests, some of which are opstate
> aware requests, and some are not.
>
> It also prevents:
>  - Having a server that is implemented to only support opstate aware
> clients.
>  - Having a server side configuration knob to control the behaviour (sinc=
e
> it would affect the semantics for all clients).
>
>
> Personally, I think that the best solutions will likely meet your propose=
d
> requirement below, but I don't agree that it should be mandated, even
> though I agree that it is something that the solution should aim for.
>
> Changing the MUST to SHOULD would make the requirement fine with me ...
>
> Finally, regarding your example below, I didn't think that the existing
> NETCONF protocol semantics specify exactly when the server is required to
> respond to the client, and hence blocking the client until the
> configuration has been applied would be a valid edit-config implementatio=
n
> under the existing NETCONF specification.
>
> Thanks,
> Rob
>
>
> On 17/12/2015 18:26, Andy Bierman wrote:
>
> Hi,
>
> I already did that:
>
>  All existing protocol
>> functionality for NETCONF and RESTCONF MUST continue to work
>> for clients which do not choose to examine the differences between
>> intended config and applied config.
>>
>>
> Another way to put it:
>
>   The client MUST choose to participate (opt-in).
>
> An example of a solution that meets this requirement
>
>   - The client adds a  flag to an edit-config reque=
st
> which causes the server to wait until the edit is applied before returnin=
g
> .
> This requires the server to opt-in for the wait, and it is not forced on
> the client.
>
>
> Andy
>
>
>
> On Thu, Dec 17, 2015 at 10:18 AM, Robert Wilton  wrote=
:
>
>> Hi Andy,
>>
>> Please can you state the specific text that is being proposed to be adde=
d
>> as a new requirement?
>>
>> Thanks,
>> Rob
>>
>>
>> On 17/12/2015 17:33, Andy Bierman wrote:
>>
>> Hi,
>>
>> I am not commenting on the solution proposals.
>> The document being discussed is the requirements document.
>> I agree with Juergen that backward compatibility needs to be an
>> explicit requirement.  Are you objecting to such a requirement?
>>
>>
>> Andy
>>
>>
>>
>>
>> On Thu, Dec 17, 2015 at 9:29 AM, Robert Wilton < 
>> rwilton@cisco.com> wrote:
>>
>>> Hi Andy,
>>>
>>> Please can you let me know whether you think that any of the three
>>> proposed solutions wouldn't meet this backwards compatibility requireme=
nt?
>>>
>>> draft-kwatsen-netmod-opstate-00 has some features that might be
>>> generally useful to NETCONF, like adding  support as defined=
 in
>>> section 5.1, that I would expect could just be added to a future versio=
n of
>>> NETCONF.  Would a requirement that the solution is backwards compatible
>>> with existing implementations require that support for  must
>>> always be optional?  Or could a new version of the NETCONF protocol req=
uire
>>> that support for  is required?
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>> On 17/12/2015 16:06, Andy Bierman wrote:
>>>
>>> Hi,
>>>
>>> I agree with Juergen that this should be clear.
>>> It was discussed several times.  All existing protocol
>>> functionality for NETCONF and RESTCONF MUST continue to work
>>> for clients which do not choose to examine the differences between
>>> intended config and applied config.
>>>
>>>
>>> Andy
>>>
>>>
>>> On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen < 
>>> kwatsen@juniper.net> wrote:
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> >>>I=E2=80=99m struggling a bit to understand what is motivating you t=
o ask
>>>> this question.    That is, as a tool vendor, I wouldn=E2=80=99t think =
that any
>>>> decision made here would affect you immediately.   My expectations are=
 that
>>>> any impact to YANG/NETCONF/RESTCONF would be backwards compatible, suc=
h
>>>> that implementations would only opt-in when needed - a pay as you grow
>>>> strategy.   But herein perhaps lies an unstated requirement, that the
>>>> impact to YANG/NETCONF/RESTCONF needs to be backwards compatible with
>>>> respect to existing deployments.  Did we miss it or is it too obvious?
>>>> >>>
>>>> >>
>>>> >> It may be obvious for many of us but for the sake of completeness I
>>>> >> prefer to have this backwards compatibility assumption explicitely
>>>> >> stated.
>>>> >
>>>> >+1
>>>>
>>>>
>>>> [as a chair]
>>>>
>>>> As last call comment, there seems to be support for adding a
>>>> requirement to the opstate-reqs draft to state that solutions supporti=
ng
>>>> said requirements MUST be backwards compatible with respect to existin=
g
>>>> deployments.  Do we have WG consensus to add this as a requirement to =
this
>>>> draft?  Are there any objections? Please voice your opinion before the=
 last
>>>> call cutoff date (Dec 30).
>>>>
>>>>
>>>> [as a contributor]
>>>>
>>>>
>>>> I=E2=80=99m unsure if it makes sense to call it out in this draft, in =
that it
>>>> seems universally applicable, but I don=E2=80=99t see any harm in it e=
ither and
>>>> thus do not object.
>>>>
>>>>
>>>> Kent
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo=
/netmod
>>>
>>>
>>>
>>
>>
>
>

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


Hi,

I think the current operations need=
 to continue to work.
With the current <edit-config> or <=
;commit> the client does
not know if the server applied the co=
nfig or just accepted the request.

With the new so=
lution, I expect that a client that does not explicitly ask
for &=
quot;wait until applied" will get the old (unspecified) behavior.


Andy



On Thu, De=
c 17, 2015 at 1:12 PM, Robert Wilton <rwilton@cisco.com> wro=
te:

 =20
   =20
 =20
  

    Hi Andy,

    

    Thanks for resending and apologies for missing it earlier.

    

    Your requirement is a bit too strong for my liking.

    

    To paraphrase your requirement text, it is forcing that all
    compliant NETCONF/RESTCONF servers MUST support any clients that do
    not want to differentiate between intended config and applied
    config.

    

    However, this requires all opstate aware servers:

    =C2=A0- To handle a mix of clients, some of which are opstate aware, an=
d
    some that are not.

    =C2=A0- To potentially handle a mix of requests, some of which are
    opstate aware requests, and some are not.

    

    It also prevents:

    =C2=A0- Having a server that is implemented to only support opstate awa=
re
    clients.

    =C2=A0- Having a server side configuration knob to control the behaviou=
r
    (since it would affect the semantics for all clients).

    

    

    Personally, I think that the best solutions will likely meet your
    proposed requirement below, but I don't agree that it should be
    mandated, even though I agree that it is something that the solution
    should aim for.

    

    Changing the MUST to SHOULD would make the requirement fine with me
    ...

    

    Finally, regarding your example below, I didn't think that the
    existing NETCONF protocol semantics specify exactly when the server
    is required to respond to the client, and hence blocking the client
    until the configuration has been applied would be a valid
    edit-config implementation under the existing NETCONF specification.
    

    Thanks,

    Rob

    

    

    
On 17/12/2015 18:26, Andy Bierman
      wrote:

    

    

     =20
      
Hi,
        


        

        
I already did that:

        


        

        

          

            

              

                

                  

                    

                      

                        
=C2=A0All existing protocol

                        
functionality for NETCONF and RESTCONF MUST
                          continue to work

                        
for clients which do not choose to examine
                          the differences between

                        
intended config and applied config.

                      

                    

                  

                

              

            

          

        

        

          

            

              


              

              
Another way to put it:

              


              

              
=C2=A0 The client MUST choose to participate (opt-in).
              


              

              
An example of a solution that meets this requirement
              


              

              
=C2=A0 - The client adds a <wait-until-applied />
                flag to an edit-config request

              
which causes the server to wait until the edit is
                applied before returning <rpc-reply>.

              
This requires the server to opt-in for the wait, and
                it is not forced on the client.

              


              

              


              

              
Andy

              


              

              
=C2=A0

            

          

        

      

      


        
On Thu, Dec 17, 2015 at 10:18 AM,
          Robert Wilton <rwilton@cisco.com>
          wrote:

          

            
 Hi Andy,

              

              Please can you state the specific text that is being
              proposed to be added as a new requirement?

              

              Thanks,

              Rob

              

              

              
On 17/12/2015 17:33, Andy Bierman wrote:

              

              

                
Hi,
                  


                  

                  
I am not commenting on the solution proposals.

                  
The document being discussed is the requirements
                    document.

                  
I agree with Juergen that backward compatibility
                    needs to be an

                  
explicit requirement.=C2=A0 Are you objecting to suc=
h
                    a requirement?

                  


                  

                  


                  

                  
Andy

                  


                  

                  


                  

                  


                  

                

                


                  
On Thu, Dec 17, 2015 at 9:29
                    AM, Robert Wilton <rwilton@cisco.com>
                    wrote:

                    

                      
 Hi Andy,
                        

                        Please can you let me know whether you think
                        that any of the three proposed solutions
                        wouldn't meet this backwards compatibility
                        requirement?

                        

                        draft-kwatsen-netmod-opstate-00 has some
                        features that might be generally useful to
                        NETCONF, like adding <get-state> support
                        as defined in section 5.1, that I would expect
                        could just be added to a future version of
                        NETCONF.=C2=A0 Would a requirement that the solutio=
n
                        is backwards compatible with existing
                        implementations require that support for
                        <get-state> must always be optional?=C2=A0 Or
                        could a new version of the NETCONF protocol
                        require that support for <get-state> is
                        required?

                        

                        Thanks,

                        Rob

                        

                        

                        
On 17/12/2015 16:06, Andy Bierman wrote:

                        

                        

                          
Hi,
                            


                            

                            
I agree with Juergen that this should
                              be clear.

                            
It was discussed several times.=C2=A0 All
                              existing protocol

                            
functionality for NETCONF and RESTCONF
                              MUST continue to work

                            
for clients which do not choose to
                              examine the differences between

                            
intended config and applied config.

                            


                            

                            


                            

                            
Andy

                            


                            

                            

                              


                                
On Thu, Dec 17,
                                  2015 at 6:36 AM, Kent Watsen <kwatsen@juniper.net>
                                  wrote:

                                  


                                    

                                    

                                    

                                    

                                    >>>I=E2=80=99m struggling a bi=
t to
                                    understand what is motivating you to
                                    ask this question.=C2=A0 =C2=A0 That is=
, as a
                                    tool vendor, I wouldn=E2=80=99t think t=
hat
                                    any decision made here would affect
                                    you immediately.=C2=A0 =C2=A0My expecta=
tions
                                    are that any impact to
                                    YANG/NETCONF/RESTCONF would be
                                    backwards compatible, such that
                                    implementations would only opt-in
                                    when needed - a pay as you grow
                                    strategy.=C2=A0 =C2=A0But herein perhap=
s lies
                                    an unstated requirement, that the
                                    impact to YANG/NETCONF/RESTCONF
                                    needs to be backwards compatible
                                    with respect to existing
                                    deployments.=C2=A0 Did we miss it or is
                                    it too obvious?

                                    >>>

                                    >>

                                    >> It may be obvious for many
                                    of us but for the sake of
                                    completeness I

                                    >> prefer to have this
                                    backwards compatibility assumption
                                    explicitely

                                    >> stated.

                                    >

                                    >+1

                                    

                                    

                                    [as a chair]

                                    

                                    As last call comment, there seems to
                                    be support for adding a requirement
                                    to the opstate-reqs draft to state
                                    that solutions supporting said
                                    requirements MUST be backwards
                                    compatible with respect to existing
                                    deployments.=C2=A0 Do we have WG
                                    consensus to add this as a
                                    requirement to this draft?=C2=A0 Are
                                    there any objections? Please voice
                                    your opinion before the last call
                                    cutoff date (Dec 30).

                                    

                                    

                                    [as a contributor]

                                    

                                    

                                    I=E2=80=99m unsure if it makes sense to=
 call
                                    it out in this draft, in that it
                                    seems universally applicable, but I
                                    don=E2=80=99t see any harm in it either=
 and
                                    thus do not object.

                                    

                                    

                                    Kent

                                    

_______________________________________________

                                    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


                        

                        

                      

                    

                  

                  

                

              

              

            

          

        

        

      

    

    

  






--001a11c3724cab7f9f05271f09c3--


From nobody Thu Dec 17 14:14:48 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D511B30EF for ; Thu, 17 Dec 2015 14:14:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 2lSDGfExh4-U for ; Thu, 17 Dec 2015 14:14:44 -0800 (PST)
Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (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 6DE3E1B30B1 for ; Thu, 17 Dec 2015 14:14:43 -0800 (PST)
Received: by mail-lb0-x232.google.com with SMTP id u9so53200195lbp.2 for ; Thu, 17 Dec 2015 14:14:43 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=8NBobEHnQ2qhex0Bk4hMFlDtJoSGEZI2iZFo2vZcnp0=; b=LKb1D67BVkm+GUgK4paamKntwyI1YZvWt1vMoXDqAoYMeriIaud03sTssoI0UwhGHP K5FNG7tQ64hki9a+kDFmisDWiJpYfO+Gb1+FSMjG/fGFHiZL4L0x2ltRLADVFQiwuKOw YJUyfBAg2lzslvl+Q4OszS090DwcB6c4UWICfSI+01jI/m7Jun/BNh93FiPC8vPLfJ/K uMWE44hIaoISK0LcR8A4kqW0QHOqPM3uy57XjIlKzgbgux+H0i/VAawwRtUDwCpXD9SQ 7Jj/hHFja70Q1ydRrJqoyyQnCRd6RdzB98KC2sxKPM5c16qNsbvMK6N4n4aKlZpGnWvW HZbw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8NBobEHnQ2qhex0Bk4hMFlDtJoSGEZI2iZFo2vZcnp0=; b=cQ/L8XcsOTHVYBEydRYq28X+fdK2w6cAtC1AB4XIWvWpLFw57OLCRtIs8umx1lNZaM N8+1sXPsfZm0VfEBJmN/pSNqz+pqRGq51duNHKhMZrvpOq2dreds/0xrpQakcfs8CD9U J6lNS592WhGJJ1XJWeOggP7SVxBieKOoqx4J5BWNW/GO9oKeI22sr9QDXbEG/8GAXIsg RbMgWAP87PRbJb1V0TMqtdLK4CS0rk9+ZckTjEoHLhas89cRzIUdaMJc2YSLK6dHHDcI R+8vSzPf9+hFTy5YpC/mPGINgdV1RV3ZZoFgrIZ+TfLf14A2G25vQ9qnrHIhsafIVbhC OMFA==
X-Gm-Message-State: ALoCoQl6n5tfGpjMxG6GcpItcw4H0OIfJp5EAMTYGwl+TmXP/j+em2cl2dq/s5I/ciE4wvSaJU9THxO5pMj6AxrDnwGEuGZHAw==
MIME-Version: 1.0
X-Received: by 10.112.16.101 with SMTP id f5mr70847lbd.30.1450390481550; Thu, 17 Dec 2015 14:14:41 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Thu, 17 Dec 2015 14:14:41 -0800 (PST)
In-Reply-To: 
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net>  <5672F107.2000900@cisco.com>  <5672FC62.7020509@cisco.com>  <5673255A.6030508@cisco.com> 
Date: Thu, 17 Dec 2015 14:14:41 -0800
Message-ID: 
From: Andy Bierman 
To: Robert Wilton 
Content-Type: multipart/alternative; boundary=001a11c3fdfe70589605271f59c6
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 22:14:47 -0000

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

On Thu, Dec 17, 2015 at 1:52 PM, Andy Bierman  wrote:

> Hi,
>
> I think the current operations need to continue to work.
> With the current  or  the client does
> not know if the server applied the config or just accepted the request.
>
> With the new solution, I expect that a client that does not explicitly as=
k
> for "wait until applied" will get the old (unspecified) behavior.
>
>
> Andy
>
>
>
> On Thu, Dec 17, 2015 at 1:12 PM, Robert Wilton  wrote:
>
>> Hi Andy,
>>
>> Thanks for resending and apologies for missing it earlier.
>>
>> Your requirement is a bit too strong for my liking.
>>
>> To paraphrase your requirement text, it is forcing that all compliant
>> NETCONF/RESTCONF servers MUST support any clients that do not want to
>> differentiate between intended config and applied config.
>>
>> However, this requires all opstate aware servers:
>>  - To handle a mix of clients, some of which are opstate aware, and some
>> that are not.
>>  - To potentially handle a mix of requests, some of which are opstate
>> aware requests, and some are not.
>>
>>

This is simple to achieve by adding optional parameters that a new client
will set
and an old client will not know about.



> It also prevents:
>>  - Having a server that is implemented to only support opstate aware
>> clients.
>>  - Having a server side configuration knob to control the behaviour
>> (since it would affect the semantics for all clients).
>>
>>


Not true, since the current RFC behavior is undefined.
A server vendor can choose right now to only return  after
all intended is applied.

The new feature will be that a client can explicitly request this behavior
and a compliant server will support it.  If the client does not request it,
then
there is a chance that operations will time out that did not use to time
out.
This will be very visible and disruptive to operators, and perceived as a
bug.





>
>> Personally, I think that the best solutions will likely meet your
>> proposed requirement below, but I don't agree that it should be mandated=
,
>> even though I agree that it is something that the solution should aim fo=
r.
>>
>> Changing the MUST to SHOULD would make the requirement fine with me ...
>>
>> Finally, regarding your example below, I didn't think that the existing
>> NETCONF protocol semantics specify exactly when the server is required t=
o
>> respond to the client, and hence blocking the client until the
>> configuration has been applied would be a valid edit-config implementati=
on
>> under the existing NETCONF specification.
>>
>

Yes it would be valid, but it might generate unhappy customers with broken
client applications just the same.



>
>> Thanks,
>> Rob
>>
>

Andy


>
>>
>> On 17/12/2015 18:26, Andy Bierman wrote:
>>
>> Hi,
>>
>> I already did that:
>>
>>  All existing protocol
>>> functionality for NETCONF and RESTCONF MUST continue to work
>>> for clients which do not choose to examine the differences between
>>> intended config and applied config.
>>>
>>>
>> Another way to put it:
>>
>>   The client MUST choose to participate (opt-in).
>>
>> An example of a solution that meets this requirement
>>
>>   - The client adds a  flag to an edit-config
>> request
>> which causes the server to wait until the edit is applied before
>> returning .
>> This requires the server to opt-in for the wait, and it is not forced on
>> the client.
>>
>>
>> Andy
>>
>>
>>
>> On Thu, Dec 17, 2015 at 10:18 AM, Robert Wilton 
>> wrote:
>>
>>> Hi Andy,
>>>
>>> Please can you state the specific text that is being proposed to be
>>> added as a new requirement?
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>> On 17/12/2015 17:33, Andy Bierman wrote:
>>>
>>> Hi,
>>>
>>> I am not commenting on the solution proposals.
>>> The document being discussed is the requirements document.
>>> I agree with Juergen that backward compatibility needs to be an
>>> explicit requirement.  Are you objecting to such a requirement?
>>>
>>>
>>> Andy
>>>
>>>
>>>
>>>
>>> On Thu, Dec 17, 2015 at 9:29 AM, Robert Wilton < 
>>> rwilton@cisco.com> wrote:
>>>
>>>> Hi Andy,
>>>>
>>>> Please can you let me know whether you think that any of the three
>>>> proposed solutions wouldn't meet this backwards compatibility requirem=
ent?
>>>>
>>>> draft-kwatsen-netmod-opstate-00 has some features that might be
>>>> generally useful to NETCONF, like adding  support as define=
d in
>>>> section 5.1, that I would expect could just be added to a future versi=
on of
>>>> NETCONF.  Would a requirement that the solution is backwards compatibl=
e
>>>> with existing implementations require that support for  mus=
t
>>>> always be optional?  Or could a new version of the NETCONF protocol re=
quire
>>>> that support for  is required?
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>> On 17/12/2015 16:06, Andy Bierman wrote:
>>>>
>>>> Hi,
>>>>
>>>> I agree with Juergen that this should be clear.
>>>> It was discussed several times.  All existing protocol
>>>> functionality for NETCONF and RESTCONF MUST continue to work
>>>> for clients which do not choose to examine the differences between
>>>> intended config and applied config.
>>>>
>>>>
>>>> Andy
>>>>
>>>>
>>>> On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen < 
>>>> kwatsen@juniper.net> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> >>>I=E2=80=99m struggling a bit to understand what is motivating you =
to ask
>>>>> this question.    That is, as a tool vendor, I wouldn=E2=80=99t think=
 that any
>>>>> decision made here would affect you immediately.   My expectations ar=
e that
>>>>> any impact to YANG/NETCONF/RESTCONF would be backwards compatible, su=
ch
>>>>> that implementations would only opt-in when needed - a pay as you gro=
w
>>>>> strategy.   But herein perhaps lies an unstated requirement, that the
>>>>> impact to YANG/NETCONF/RESTCONF needs to be backwards compatible with
>>>>> respect to existing deployments.  Did we miss it or is it too obvious=
?
>>>>> >>>
>>>>> >>
>>>>> >> It may be obvious for many of us but for the sake of completeness =
I
>>>>> >> prefer to have this backwards compatibility assumption explicitely
>>>>> >> stated.
>>>>> >
>>>>> >+1
>>>>>
>>>>>
>>>>> [as a chair]
>>>>>
>>>>> As last call comment, there seems to be support for adding a
>>>>> requirement to the opstate-reqs draft to state that solutions support=
ing
>>>>> said requirements MUST be backwards compatible with respect to existi=
ng
>>>>> deployments.  Do we have WG consensus to add this as a requirement to=
 this
>>>>> draft?  Are there any objections? Please voice your opinion before th=
e last
>>>>> call cutoff date (Dec 30).
>>>>>
>>>>>
>>>>> [as a contributor]
>>>>>
>>>>>
>>>>> I=E2=80=99m unsure if it makes sense to call it out in this draft, in=
 that it
>>>>> seems universally applicable, but I don=E2=80=99t see any harm in it =
either and
>>>>> thus do not object.
>>>>>
>>>>>
>>>>> Kent
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinf=
o/netmod
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>

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




On Thu, Dec 17, 2015 at 1:52 PM, Andy Bierman <andy@yumaworks.com=
> wrote:
Hi,
I think the current operations need to continue to work.<=
/div>
With the current <edit-config> or <commit> the client=
 does
not know if the server applied the config or just accepted =
the request.

With the new solution, I expect that =
a client that does not explicitly ask
for "wait until applie=
d" will get the old (unspecified) behavior.

<=
br>
Andy



On Thu, Dec 17, 2015 at 1:12 PM,=
 Robert Wilton <rwilton@cisco.com> wrote:

 =20
   =20
 =20
  

    Hi Andy,

    

    Thanks for resending and apologies for missing it earlier.

    

    Your requirement is a bit too strong for my liking.

    

    To paraphrase your requirement text, it is forcing that all
    compliant NETCONF/RESTCONF servers MUST support any clients that do
    not want to differentiate between intended config and applied
    config.

    

    However, this requires all opstate aware servers:

    =C2=A0- To handle a mix of clients, some of which are opstate aware, an=
d
    some that are not.

    =C2=A0- To potentially handle a mix of requests, some of which are
    opstate aware requests, and some are not.

    

This is simple to achieve by adding optional parameters that a =
new client will set
and an old client will not know about.
<=
div>
=C2=A0

    It also prevents:

    =C2=A0- Having a server that is implemented to only support opstate awa=
re
    clients.

    =C2=A0- Having a server side configuration knob to control the behaviou=
r
    (since it would affect the semantics for all clients).

    

=C2=
=A0

Not true, since the current RFC behavior is un=
defined.
A server vendor can choose right now to only return <=
rpc-reply> after
all intended is applied.

=

The new feature will be that a client can explicitly request this beha=
vior
and a compliant server will support it.=C2=A0 If the client =
does not request it, then
there is a chance that operations will =
time out that did not use to time out.
This will be very visible =
and disruptive to operators, and perceived as a bug.



=C2=A0

    

    Personally, I think that the best solutions will likely meet your
    proposed requirement below, but I don't agree that it should be
    mandated, even though I agree that it is something that the solution
    should aim for.

    

    Changing the MUST to SHOULD would make the requirement fine with me
    ...

    

    Finally, regarding your example below, I didn't think that the
    existing NETCONF protocol semantics specify exactly when the server
    is required to respond to the client, and hence blocking the client
    until the configuration has been applied would be a valid
    edit-config implementation under the existing NETCONF specification.


=

Yes it would be valid, but it might generate unhappy customers with br=
oken
client applications just the same.

=
=C2=A0

    

    Thanks,

    Rob

=

Andy
=C2=A0

    

    

    
On 17/12/2015 18:26, Andy Bierman
      wrote:

    

    

     =20
      
Hi,
        


        

        
I already did that:

        


        

        

          

            

              

                

                  

                    

                      

                        
=C2=A0All existing protocol

                        
functionality for NETCONF and RESTCONF MUST
                          continue to work

                        
for clients which do not choose to examine
                          the differences between

                        
intended config and applied config.

                      

                    

                  

                

              

            

          

        

        

          

            

              


              

              
Another way to put it:

              


              

              
=C2=A0 The client MUST choose to participate (opt-in).
              


              

              
An example of a solution that meets this requirement
              


              

              
=C2=A0 - The client adds a <wait-until-applied />
                flag to an edit-config request

              
which causes the server to wait until the edit is
                applied before returning <rpc-reply>.

              
This requires the server to opt-in for the wait, and
                it is not forced on the client.

              


              

              


              

              
Andy

              


              

              
=C2=A0

            

          

        

      

      


        
On Thu, Dec 17, 2015 at 10:18 AM,
          Robert Wilton <rwilton@cisco.com>
          wrote:

          

            
 Hi Andy,

              

              Please can you state the specific text that is being
              proposed to be added as a new requirement?

              

              Thanks,

              Rob

              

              

              
On 17/12/2015 17:33, Andy Bierman wrote:

              

              

                
Hi,
                  


                  

                  
I am not commenting on the solution proposals.

                  
The document being discussed is the requirements
                    document.

                  
I agree with Juergen that backward compatibility
                    needs to be an

                  
explicit requirement.=C2=A0 Are you objecting to suc=
h
                    a requirement?

                  


                  

                  


                  

                  
Andy

                  


                  

                  


                  

                  


                  

                

                


                  
On Thu, Dec 17, 2015 at 9:29
                    AM, Robert Wilton <rwilton@cisco.com>
                    wrote:

                    

                      
 Hi Andy,
                        

                        Please can you let me know whether you think
                        that any of the three proposed solutions
                        wouldn't meet this backwards compatibility
                        requirement?

                        

                        draft-kwatsen-netmod-opstate-00 has some
                        features that might be generally useful to
                        NETCONF, like adding <get-state> support
                        as defined in section 5.1, that I would expect
                        could just be added to a future version of
                        NETCONF.=C2=A0 Would a requirement that the solutio=
n
                        is backwards compatible with existing
                        implementations require that support for
                        <get-state> must always be optional?=C2=A0 Or
                        could a new version of the NETCONF protocol
                        require that support for <get-state> is
                        required?

                        

                        Thanks,

                        Rob

                        

                        

                        
On 17/12/2015 16:06, Andy Bierman wrote:

                        

                        

                          
Hi,
                            


                            

                            
I agree with Juergen that this should
                              be clear.

                            
It was discussed several times.=C2=A0 All
                              existing protocol

                            
functionality for NETCONF and RESTCONF
                              MUST continue to work

                            
for clients which do not choose to
                              examine the differences between

                            
intended config and applied config.

                            


                            

                            


                            

                            
Andy

                            


                            

                            

                              


                                
On Thu, Dec 17,
                                  2015 at 6:36 AM, Kent Watsen <kwatsen@juniper.net>
                                  wrote:

                                  


                                    

                                    

                                    

                                    

                                    >>>I=E2=80=99m struggling a bi=
t to
                                    understand what is motivating you to
                                    ask this question.=C2=A0 =C2=A0 That is=
, as a
                                    tool vendor, I wouldn=E2=80=99t think t=
hat
                                    any decision made here would affect
                                    you immediately.=C2=A0 =C2=A0My expecta=
tions
                                    are that any impact to
                                    YANG/NETCONF/RESTCONF would be
                                    backwards compatible, such that
                                    implementations would only opt-in
                                    when needed - a pay as you grow
                                    strategy.=C2=A0 =C2=A0But herein perhap=
s lies
                                    an unstated requirement, that the
                                    impact to YANG/NETCONF/RESTCONF
                                    needs to be backwards compatible
                                    with respect to existing
                                    deployments.=C2=A0 Did we miss it or is
                                    it too obvious?

                                    >>>

                                    >>

                                    >> It may be obvious for many
                                    of us but for the sake of
                                    completeness I

                                    >> prefer to have this
                                    backwards compatibility assumption
                                    explicitely

                                    >> stated.

                                    >

                                    >+1

                                    

                                    

                                    [as a chair]

                                    

                                    As last call comment, there seems to
                                    be support for adding a requirement
                                    to the opstate-reqs draft to state
                                    that solutions supporting said
                                    requirements MUST be backwards
                                    compatible with respect to existing
                                    deployments.=C2=A0 Do we have WG
                                    consensus to add this as a
                                    requirement to this draft?=C2=A0 Are
                                    there any objections? Please voice
                                    your opinion before the last call
                                    cutoff date (Dec 30).

                                    

                                    

                                    [as a contributor]

                                    

                                    

                                    I=E2=80=99m unsure if it makes sense to=
 call
                                    it out in this draft, in that it
                                    seems universally applicable, but I
                                    don=E2=80=99t see any harm in it either=
 and
                                    thus do not object.

                                    

                                    

                                    Kent

                                    

_______________________________________________

                                    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


                        

                        

                      

                    

                  

                  

                

              

              

            

          

        

        

      

    

    

  









--001a11c3fdfe70589605271f59c6--


From nobody Thu Dec 17 15:15:12 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57511B3113 for ; Thu, 17 Dec 2015 15:15:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 gj_-v-FUGQI9 for ; Thu, 17 Dec 2015 15:15:07 -0800 (PST)
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 D5CAF1A8A67 for ; Thu, 17 Dec 2015 15:15:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46018; q=dns/txt; s=iport; t=1450394106; x=1451603706; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=3bzvDGBbEW4KDhHqCy4Ybpz04632lTRb2dNCzoCpEK4=; b=cYTYg9u/4ngeQH/jqOi3AoCqmX2YMMIj5wDxcZAAY0e7XLuUrwskP27L e8g2YoGTX9z7UN7r0z9cCV5WEkP7tCxFXio3E0HuhkCvMmeb4AaJXsfK2 I557ly2Z5hqIz9gUbqQa47JGc/zr2/mNLGmFcZYlUxXsta9t9VEtFWp6P c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvBAATQXNW/xbLJq1egm6BHm2/ShcBC?= =?us-ascii?q?YUiSgKCBQEBAQEBAYELhDQBAQEDAQEBASBLBgQBEAsYCRYBAQYDAgIJAwIBAgE?= =?us-ascii?q?VHxEGDQYCAQEXiAwIDqtkkgYBAQEBAQEBAQEBAQEBAQEBAQEBFgSGVoR+hEKDN?= =?us-ascii?q?YFJBZMHg3aNSIFchEWDBZADg3RkghEdgVY+NIRqAQEB?=
X-IronPort-AV: E=Sophos;i="5.20,443,1444694400";  d="scan'208,217";a="609895886"
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; 17 Dec 2015 23:15:03 +0000
Received: from [10.61.209.191] ([10.61.209.191]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tBHNF2R5014678; Thu, 17 Dec 2015 23:15:02 GMT
To: Andy Bierman 
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net>  <5672F107.2000900@cisco.com>  <5672FC62.7020509@cisco.com>  <5673255A.6030508@cisco.com>  
From: Robert Wilton 
Message-ID: <567341F6.4040202@cisco.com>
Date: Thu, 17 Dec 2015 23:15:02 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------040703090906050707010703"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 23:15:11 -0000

This is a multi-part message in MIME format.
--------------040703090906050707010703
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Andy,

On 17/12/2015 22:14, Andy Bierman wrote:
>
>
> On Thu, Dec 17, 2015 at 1:52 PM, Andy Bierman  > wrote:
>
>     Hi,
>
>     I think the current operations need to continue to work.
>     With the current  or  the client does
>     not know if the server applied the config or just accepted the
>     request.
>
>     With the new solution, I expect that a client that does not
>     explicitly ask
>     for "wait until applied" will get the old (unspecified) behavior.
>
>
>     Andy
>
>
>
>     On Thu, Dec 17, 2015 at 1:12 PM, Robert Wilton      > wrote:
>
>         Hi Andy,
>
>         Thanks for resending and apologies for missing it earlier.
>
>         Your requirement is a bit too strong for my liking.
>
>         To paraphrase your requirement text, it is forcing that all
>         compliant NETCONF/RESTCONF servers MUST support any clients
>         that do not want to differentiate between intended config and
>         applied config.
>
>         However, this requires all opstate aware servers:
>          - To handle a mix of clients, some of which are opstate
>         aware, and some that are not.
>          - To potentially handle a mix of requests, some of which are
>         opstate aware requests, and some are not.
>
>
>
> This is simple to achieve by adding optional parameters that a new 
> client will set
> and an old client will not know about.

My point is really that it may be harder for servers to support clients 
using a mix of semantics.

It still feels to me that at this stage of just considering/comparing 
solutions we shouldn't rule out a server potentially being able to 
declare that it only supports/implements opstate-aware semantics, which 
I think that your requirement would. For some devices, if all customers 
are only asking for opstate-aware semantics, then do we really also have 
to support the non opstate-aware semantics as well?


>
>         It also prevents:
>          - Having a server that is implemented to only support opstate
>         aware clients.
>          - Having a server side configuration knob to control the
>         behaviour (since it would affect the semantics for all clients).
>
>
>
> Not true, since the current RFC behavior is undefined.
> A server vendor can choose right now to only return  after
> all intended is applied.
>
> The new feature will be that a client can explicitly request this behavior
> and a compliant server will support it.  If the client does not 
> request it, then
> there is a chance that operations will time out that did not use to 
> time out.
> This will be very visible and disruptive to operators, and perceived 
> as a bug.

Technically the bug would be in the client rather than the server here, 
but I don't deny that the client operator would necessarily perceive it 
the same way.  But shouldn't this be up to the implementer to weight up 
the benefits of a potentially simpler server solution vs the impacts to 
existing clients?

>
>
>
>
>         Personally, I think that the best solutions will likely meet
>         your proposed requirement below, but I don't agree that it
>         should be mandated, even though I agree that it is something
>         that the solution should aim for.
>
>         Changing the MUST to SHOULD would make the requirement fine
>         with me ...
>
>         Finally, regarding your example below, I didn't think that the
>         existing NETCONF protocol semantics specify exactly when the
>         server is required to respond to the client, and hence
>         blocking the client until the configuration has been applied
>         would be a valid edit-config implementation under the existing
>         NETCONF specification.
>
>
>
> Yes it would be valid, but it might generate unhappy customers with broken
> client applications just the same.
It still doesn't feel like a good requirement that states that an 
opstate-aware server must preserve support for some existing, but 
unspecified, behaviour.  If the new more tightly defined behaviour is 
compliant with the existing unspecified behaviour then it feels like 
that should be a valid implementation choice to treat both of them the 
same way.

Thanks,
Rob


>
>
>         Thanks,
>         Rob
>
>
>
> Andy
>
>
>
>         On 17/12/2015 18:26, Andy Bierman wrote:
>>         Hi,
>>
>>         I already did that:
>>
>>>>              All existing protocol
>>>>             functionality for NETCONF and RESTCONF MUST continue to
>>>>             work
>>>>             for clients which do not choose to examine the
>>>>             differences between
>>>>             intended config and applied config.
>>>
>>
>>         Another way to put it:
>>
>>           The client MUST choose to participate (opt-in).
>>
>>         An example of a solution that meets this requirement
>>
>>           - The client adds a  flag to an
>>         edit-config request
>>         which causes the server to wait until the edit is applied
>>         before returning .
>>         This requires the server to opt-in for the wait, and it is
>>         not forced on the client.
>>
>>
>>         Andy
>>
>>
>>         On Thu, Dec 17, 2015 at 10:18 AM, Robert Wilton
>>         > wrote:
>>
>>             Hi Andy,
>>
>>             Please can you state the specific text that is being
>>             proposed to be added as a new requirement?
>>
>>             Thanks,
>>             Rob
>>
>>
>>             On 17/12/2015 17:33, Andy Bierman wrote:
>>>             Hi,
>>>
>>>             I am not commenting on the solution proposals.
>>>             The document being discussed is the requirements document.
>>>             I agree with Juergen that backward compatibility needs
>>>             to be an
>>>             explicit requirement.  Are you objecting to such a
>>>             requirement?
>>>
>>>
>>>             Andy
>>>
>>>
>>>
>>>
>>>             On Thu, Dec 17, 2015 at 9:29 AM, Robert Wilton
>>>             > wrote:
>>>
>>>                 Hi Andy,
>>>
>>>                 Please can you let me know whether you think that
>>>                 any of the three proposed solutions wouldn't meet
>>>                 this backwards compatibility requirement?
>>>
>>>                 draft-kwatsen-netmod-opstate-00 has some features
>>>                 that might be generally useful to NETCONF, like
>>>                 adding  support as defined in section
>>>                 5.1, that I would expect could just be added to a
>>>                 future version of NETCONF.  Would a requirement that
>>>                 the solution is backwards compatible with existing
>>>                 implementations require that support for 
>>>                 must always be optional?  Or could a new version of
>>>                 the NETCONF protocol require that support for
>>>                  is required?
>>>
>>>                 Thanks,
>>>                 Rob
>>>
>>>
>>>                 On 17/12/2015 16:06, Andy Bierman wrote:
>>>>                 Hi,
>>>>
>>>>                 I agree with Juergen that this should be clear.
>>>>                 It was discussed several times.  All existing protocol
>>>>                 functionality for NETCONF and RESTCONF MUST
>>>>                 continue to work
>>>>                 for clients which do not choose to examine the
>>>>                 differences between
>>>>                 intended config and applied config.
>>>>
>>>>
>>>>                 Andy
>>>>
>>>>
>>>>                 On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen
>>>>                 >
>>>>                 wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>                     >>>I’m struggling a bit to understand what is
>>>>                     motivating you to ask this question.    That
>>>>                     is, as a tool vendor, I wouldn’t think that any
>>>>                     decision made here would affect you
>>>>                     immediately.   My expectations are that any
>>>>                     impact to YANG/NETCONF/RESTCONF would be
>>>>                     backwards compatible, such that implementations
>>>>                     would only opt-in when needed - a pay as you
>>>>                     grow strategy.   But herein perhaps lies an
>>>>                     unstated requirement, that the impact to
>>>>                     YANG/NETCONF/RESTCONF needs to be backwards
>>>>                     compatible with respect to existing
>>>>                     deployments.  Did we miss it or is it too obvious?
>>>>                     >>>
>>>>                     >>
>>>>                     >> It may be obvious for many of us but for the
>>>>                     sake of completeness I
>>>>                     >> prefer to have this backwards compatibility
>>>>                     assumption explicitely
>>>>                     >> stated.
>>>>                     >
>>>>                     >+1
>>>>
>>>>
>>>>                     [as a chair]
>>>>
>>>>                     As last call comment, there seems to be support
>>>>                     for adding a requirement to the opstate-reqs
>>>>                     draft to state that solutions supporting said
>>>>                     requirements MUST be backwards compatible with
>>>>                     respect to existing deployments.  Do we have WG
>>>>                     consensus to add this as a requirement to this
>>>>                     draft?  Are there any objections? Please voice
>>>>                     your opinion before the last call cutoff date
>>>>                     (Dec 30).
>>>>
>>>>
>>>>                     [as a contributor]
>>>>
>>>>
>>>>                     I’m unsure if it makes sense to call it out in
>>>>                     this draft, in that it seems universally
>>>>                     applicable, but I don’t see any harm in it
>>>>                     either and thus do not object.
>>>>
>>>>
>>>>                     Kent
>>>>
>>>>                     _______________________________________________
>>>>                     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
>>>
>>>
>>
>>
>
>
>


--------------040703090906050707010703
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    Hi Andy,

    

    
On 17/12/2015 22:14, Andy Bierman
      wrote:

    

    

      
      


        


          
On Thu, Dec 17, 2015 at 1:52 PM, Andy
            Bierman <andy@yumaworks.com>
            wrote:

            

              
Hi,
                


                

                
I think the current operations need to continue to
                  work.

                
With the current <edit-config> or
                  <commit> the client does

                
not know if the server applied the config or just
                  accepted the request.

                


                

                
With the new solution, I expect that a client that
                  does not explicitly ask

                
for "wait until applied" will get the old
                  (unspecified) behavior.

                


                

                


                

                
Andy

                


                

                


                

              

              


                
On Thu, Dec 17, 2015 at 1:12
                  PM, Robert Wilton <rwilton@cisco.com>
                  wrote:

                  

                    
 Hi Andy,

                      

                      Thanks for resending and apologies for missing it
                      earlier.

                      

                      Your requirement is a bit too strong for my
                      liking.

                      

                      To paraphrase your requirement text, it is forcing
                      that all compliant NETCONF/RESTCONF servers MUST
                      support any clients that do not want to
                      differentiate between intended config and applied
                      config.

                      

                      However, this requires all opstate aware servers:

                       - To handle a mix of clients, some of which are
                      opstate aware, and some that are not.

                       - To potentially handle a mix of requests, some
                      of which are opstate aware requests, and some are
                      not.

                      

                    

                  

                

              

            

            


            

            


            

            
This is simple to achieve by adding optional parameters
              that a new client will set

            
and an old client will not know about.

          

        

      

    

    

    My point is really that it may be harder for servers to support
    clients using a mix of semantics.

    

    It still feels to me that at this stage of just
    considering/comparing solutions we shouldn't rule out a server
    potentially being able to declare that it only supports/implements
    opstate-aware semantics, which I think that your requirement would. 
    For some devices, if all customers are only asking for opstate-aware
    semantics, then do we really also have to support the non
    opstate-aware semantics as well?

    

    

    

      

        

          

            


            

            
 

            

              

                

                  

                    
 It also
                      prevents:

                       - Having a server that is implemented to only
                      support opstate aware clients.

                       - Having a server side configuration knob to
                      control the behaviour (since it would affect the
                      semantics for all clients).

                      

                    

                  

                

              

            

            


            

            
 

            


            

            
Not true, since the current RFC behavior is undefined.

          

        

      

    

    

      

        

          

            
A server vendor can choose right now to only return
              <rpc-reply> after

            
all intended is applied.

            


            

            
The new feature will be that a client can explicitly
              request this behavior

            
and a compliant server will support it.  If the client
              does not request it, then

            
there is a chance that operations will time out that
              did not use to time out.

            
This will be very visible and disruptive to operators,
              and perceived as a bug.

          

        

      

    

    

    Technically the bug would be in the client rather than the server
    here, but I don't deny that the client operator would necessarily
    perceive it the same way.  But shouldn't this be up to the
    implementer to weight up the benefits of a potentially simpler
    server solution vs the impacts to existing clients?

    

    

      

        

          

            


            

            


            

            


            

            
 

            

              

                

                  

                    
 

                      Personally, I think that the best solutions will
                      likely meet your proposed requirement below, but I
                      don't agree that it should be mandated, even
                      though I agree that it is something that the
                      solution should aim for.

                      

                      Changing the MUST to SHOULD would make the
                      requirement fine with me ...

                      

                      Finally, regarding your example below, I didn't
                      think that the existing NETCONF protocol semantics
                      specify exactly when the server is required to
                      respond to the client, and hence blocking the
                      client until the configuration has been applied
                      would be a valid edit-config implementation under
                      the existing NETCONF specification.

                    

                  

                

              

            

            


            

            


            

            
Yes it would be valid, but it might generate unhappy
              customers with broken

            
client applications just the same.

          

        

      

    

    It still doesn't feel like a good requirement that states that an
    opstate-aware server must preserve support for some existing, but
    unspecified, behaviour.  If the new more tightly defined behaviour
    is compliant with the existing unspecified behaviour then it feels
    like that should be a valid implementation choice to treat both of
    them the same way.

    

    Thanks,

    Rob

    

    

    

      

        

          

            


            

            
 

            

              

                

                  

                    
 

                      Thanks,

                      Rob

                    

                  

                

              

            

            


            

            


            

            
Andy

            
 

            

              

                

                  

                    
 

                      

                      
On 17/12/2015 18:26, Andy Bierman wrote:

                      

                      

                        
Hi,
                          


                          

                          
I already did that:

                          


                          

                          

                            

                              

                                

                                  

                                    

                                      

                                        

                                          
 All existing protocol

                                          
functionality for NETCONF
                                            and RESTCONF MUST continue
                                            to work

                                          
for clients which do not
                                            choose to examine the
                                            differences between

                                          
intended config and
                                            applied config.

                                        

                                      

                                    

                                  

                                

                              

                            

                          

                          

                            

                              

                                


                                

                                
Another way to put it:

                                


                                

                                
  The client MUST choose to
                                  participate (opt-in).

                                


                                

                                
An example of a solution that meets
                                  this requirement

                                


                                

                                
  - The client adds a
                                  <wait-until-applied /> flag to
                                  an edit-config request

                                
which causes the server to wait
                                  until the edit is applied before
                                  returning <rpc-reply>.

                                
This requires the server to opt-in
                                  for the wait, and it is not forced on
                                  the client.

                                


                                

                                


                                

                                
Andy

                                


                                

                                
 

                              

                            

                          

                        

                        


                          
On Thu, Dec 17, 2015
                            at 10:18 AM, Robert Wilton <rwilton@cisco.com>
                            wrote:

                            

                              
 Hi
                                Andy,

                                

                                Please can you state the specific text
                                that is being proposed to be added as a
                                new requirement?

                                

                                Thanks,

                                Rob

                                

                                

                                
On 17/12/2015 17:33, Andy Bierman
                                  wrote:

                                

                                

                                  
Hi,
                                    


                                    

                                    
I am not commenting on the
                                      solution proposals.

                                    
The document being discussed is
                                      the requirements document.

                                    
I agree with Juergen that
                                      backward compatibility needs to be
                                      an

                                    
explicit requirement.  Are you
                                      objecting to such a requirement?

                                    


                                    

                                    


                                    

                                    
Andy

                                    


                                    

                                    


                                    

                                    


                                    

                                  

                                  


                                    
On Thu, Dec
                                      17, 2015 at 9:29 AM, Robert Wilton
                                      <rwilton@cisco.com>
                                      wrote:

                                      

                                        
 Hi Andy,

                                          

                                          Please can you let me know
                                          whether you think that any of
                                          the three proposed solutions
                                          wouldn't meet this backwards
                                          compatibility requirement?

                                          

                                          draft-kwatsen-netmod-opstate-00
                                          has some features that might
                                          be generally useful to
                                          NETCONF, like adding
                                          <get-state> support as
                                          defined in section 5.1, that I
                                          would expect could just be
                                          added to a future version of
                                          NETCONF.  Would a requirement
                                          that the solution is backwards
                                          compatible with existing
                                          implementations require that
                                          support for <get-state>
                                          must always be optional?  Or
                                          could a new version of the
                                          NETCONF protocol require that
                                          support for <get-state>
                                          is required?

                                          

                                          Thanks,

                                          Rob

                                          

                                          

                                          
On 17/12/2015 16:06, Andy
                                            Bierman wrote:

                                          

                                          

                                            
Hi,
                                              


                                              

                                              
I agree with Juergen
                                                that this should be
                                                clear.

                                              
It was discussed
                                                several times.  All
                                                existing protocol

                                              
functionality for
                                                NETCONF and RESTCONF
                                                MUST continue to work

                                              
for clients which do
                                                not choose to examine
                                                the differences between

                                              
intended config and
                                                applied config.

                                              


                                              

                                              


                                              

                                              
Andy

                                              


                                              

                                              

                                                


                                                  
On
                                                    Thu, Dec 17, 2015 at
                                                    6:36 AM, Kent Watsen
                                                    <kwatsen@juniper.net>
                                                    wrote:

                                                    


                                                      

                                                      

                                                      

                                                      

                                                      >>>I’m
                                                      struggling a bit
                                                      to understand what
                                                      is motivating you
                                                      to ask this
                                                      question.    That
                                                      is, as a tool
                                                      vendor, I wouldn’t
                                                      think that any
                                                      decision made here
                                                      would affect you
                                                      immediately.   My
                                                      expectations are
                                                      that any impact to
                                                      YANG/NETCONF/RESTCONF
                                                      would be backwards
                                                      compatible, such
                                                      that
                                                      implementations
                                                      would only opt-in
                                                      when needed - a
                                                      pay as you grow
                                                      strategy.   But
                                                      herein perhaps
                                                      lies an unstated
                                                      requirement, that
                                                      the impact to
                                                      YANG/NETCONF/RESTCONF
                                                      needs to be
                                                      backwards
                                                      compatible with
                                                      respect to
                                                      existing
                                                      deployments.  Did
                                                      we miss it or is
                                                      it too obvious?

                                                      >>>

                                                      >>

                                                      >> It may be
                                                      obvious for many
                                                      of us but for the
                                                      sake of
                                                      completeness I

                                                      >> prefer to
                                                      have this
                                                      backwards
                                                      compatibility
                                                      assumption
                                                      explicitely

                                                      >> stated.

                                                      >

                                                      >+1

                                                      

                                                      

                                                      [as a chair]

                                                      

                                                      As last call
                                                      comment, there
                                                      seems to be
                                                      support for adding
                                                      a requirement to
                                                      the opstate-reqs
                                                      draft to state
                                                      that solutions
                                                      supporting said
                                                      requirements MUST
                                                      be backwards
                                                      compatible with
                                                      respect to
                                                      existing
                                                      deployments.  Do
                                                      we have WG
                                                      consensus to add
                                                      this as a
                                                      requirement to
                                                      this draft?  Are
                                                      there any
                                                      objections? Please
                                                      voice your opinion
                                                      before the last
                                                      call cutoff date
                                                      (Dec 30).

                                                      

                                                      

                                                      [as a contributor]

                                                      

                                                      

                                                      I’m unsure if it
                                                      makes sense to
                                                      call it out in
                                                      this draft, in
                                                      that it seems
                                                      universally
                                                      applicable, but I
                                                      don’t see any harm
                                                      in it either and
                                                      thus do not
                                                      object.

                                                      

                                                      

                                                      Kent

                                                      

_______________________________________________

                                                      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


                                          

                                          

                                        

                                      

                                    

                                    

                                  

                                

                                

                              

                            

                          

                          

                        

                      

                      

                    

                  

                

                

              

            

          

          

        

      

    

    

  


--------------040703090906050707010703--


From nobody Thu Dec 17 15:17:36 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B50971B311E for ; Thu, 17 Dec 2015 15:17:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 LYXYcfNHDZeG for ; Thu, 17 Dec 2015 15:17:24 -0800 (PST)
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 02BD31B3117 for ; Thu, 17 Dec 2015 15:17:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1719; q=dns/txt; s=iport; t=1450394244; x=1451603844; h=to:from:subject:message-id:date:mime-version: content-transfer-encoding; bh=CdqUepByImRWUZeH1JjxUB3vmVVZk7u7PcsyjR0/HiU=; b=HngfoYQHH2nD2gWHK/dAqePeqyA7vuZSybxIkp0vX6bqyFsn/fLfSz1I 8zxlzu2C/3AR9D4C+iUCqyOwmdVUXyACRDmqWJr/xuP2YicPZqba6dtLD aQIMkm8LxeN4VN4tJdOVHeA61T0LegSKD3ZoXhRK1LdeEG0NlybYFfN8w M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CmBAATQXNW/xbLJq1ewDqECYgUAQEBA?= =?us-ascii?q?QEBgQALhF4VQDYCBRYLAgsDAgECAUsNCAEBiCucAo9wkgYBLIEBhVWMdYFJBZZ?= =?us-ascii?q?9gQyMPIkmk3dkhAQ+hR4BAQE?=
X-IronPort-AV: E=Sophos;i="5.20,443,1444694400"; d="scan'208";a="609895994"
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; 17 Dec 2015 23:17:22 +0000
Received: from [10.61.209.191] ([10.61.209.191]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tBHNHLQh015465 for ; Thu, 17 Dec 2015 23:17:22 GMT
To: "netmod@ietf.org" 
From: Robert Wilton 
Message-ID: <56734281.2010009@cisco.com>
Date: Thu, 17 Dec 2015 23:17:21 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [netmod] Modelling capabilities in YANG
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 23:17:31 -0000

Hi,

For the Ethernet interface model that we are working on, the question 
has come up on how best to model capabilities of a physical item of 
hardware.

In this particular case of Ethernet interfaces there are various 
capabilities that we would like to model, but to give some concrete 
examples:
  - whether a particular Ethernet interface supports auto-negotiation 
configuration
  - what speed values may be configured on a particular interface
  - whether the interface supports half duplex in addition to full duplex
  - what modes of flow control are supported on the interface.

All of these properties may change depending on what hardware is 
currently inserted (e.g. this could be as coarse as a linecard or as 
granular as a pluggable optics module).  I.e. it is not the case that 
the capabilities for all interfaces on a device would be the same, and 
hence YANG features don't appear to help with this scenario.

The current assumption is that we would model these dynamic capabilities 
as operational state leaves.  However, there is a general question as to 
where these leaves should be placed.  Should they be inline in the 
interface config tree, or should there be a separate capabilities 
container to hold them somewhere?

Further, in an ideal world it would be desirable to constrain the 
allowed configuration values to those that are supported by the 
capabilities, although writing such must statements on the config node 
that reference state data  is not allowed.

We can't be the first people to want to model dynamic capabilities, is 
there a best practice on how they should be handled?

Any advice would be gratefully appreciated!

Thanks,
Rob


From nobody Thu Dec 17 15:45:45 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C741A8A4D for ; Thu, 17 Dec 2015 15:45:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.3
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 z2P0NvA7mO07 for ; Thu, 17 Dec 2015 15:45:34 -0800 (PST)
Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7D3881A904E for ; Thu, 17 Dec 2015 15:45:34 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=CcTcBZKh8PzgkcS5n9R4+DUSI0bjqDOG+EmVCvrRtccR5uBc5ABFGvR118XhkKrq; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.50] (helo=mswamui-swiss.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1a9iEd-0006jf-Fe for netmod@ietf.org; Thu, 17 Dec 2015 18:45:23 -0500
Received: from 76.254.52.56 by webmail.earthlink.net with HTTP; Thu, 17 Dec 2015 18:45:23 -0500
Message-ID: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net>
Date: Thu, 17 Dec 2015 15:45:23 -0800 (GMT-08:00)
From: Randy Presuhn 
To: netmod@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888857e9f10d2205ddc5449f8cb19b0c651668e42878fead1ee350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.50
Archived-At: 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 17 Dec 2015 23:45:38 -0000

Hi -

> From: Robert Wilton
> Sent: Dec 17, 2015 1:12 PM
> To: Andy Bierman
> Cc: "netmod@ietf.org"
> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
...
>     Your requirement is a bit too strong for my liking.
>
>     To paraphrase your requirement text, it is forcing that all
>     compliant NETCONF/RESTCONF servers MUST support any clients that do
>     not want to differentiate between intended config and applied
>     config.

Do do otherwise sound to me like an interoperability disaster,
and would encourage the "siloization" of toolsets.

>     However, this requires all opstate aware servers:
>
>      - To handle a mix of clients, some of which are opstate aware, and
>      some that are not.

This seems perfectly reasonable.  To do otherwise torpedoes the very
notion of interoperability.

>      - To potentially handle a mix of requests, some of which are
>      opstate aware requests, and some are not.

Ditto. 

>     It also prevents:
>
>      - Having a server that is implemented to only support opstate aware
>      clients.

Avoiding the creation of such servers sounds like a *good* thing to me.

>      - Having a server side configuration knob to control the behaviour
>      (since it would affect the semantics for all clients).

This also sounds like something which it would be desireable to prevent.    

I think I'm squarely with Andy on this one.

Randy


From nobody Thu Dec 17 22:38:10 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631981B33AE for ; Thu, 17 Dec 2015 22:38:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 ruWFfiOD_CjL for ; Thu, 17 Dec 2015 22:38:07 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34C91B33AC for ; Thu, 17 Dec 2015 22:38:06 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0D3A51324; Fri, 18 Dec 2015 07:38:05 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id UQ9hjbGrUY17; Fri, 18 Dec 2015 07:38:03 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 18 Dec 2015 07:38:03 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A1B932005C; Fri, 18 Dec 2015 07:38:03 +0100 (CET)
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 SPgMNngxzQhH; Fri, 18 Dec 2015 07:38:02 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B1E3520055; Fri, 18 Dec 2015 07:38:01 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id B57E23941D28; Fri, 18 Dec 2015 07:37:59 +0100 (CET)
Date: Fri, 18 Dec 2015 07:37:58 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
Message-ID: <20151218063756.GA70037@elstar.local>
Mail-Followup-To: Robert Wilton , "netmod@ietf.org" 
References: <56734281.2010009@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56734281.2010009@cisco.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Modelling capabilities in YANG
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 06:38:09 -0000

On Thu, Dec 17, 2015 at 11:17:21PM +0000, Robert Wilton wrote:
> Hi,
> 
> For the Ethernet interface model that we are working on, the question 
> has come up on how best to model capabilities of a physical item of 
> hardware.
> 
> In this particular case of Ethernet interfaces there are various 
> capabilities that we would like to model, but to give some concrete 
> examples:
>  - whether a particular Ethernet interface supports auto-negotiation 
> configuration
>  - what speed values may be configured on a particular interface
>  - whether the interface supports half duplex in addition to full duplex
>  - what modes of flow control are supported on the interface.
> 
> All of these properties may change depending on what hardware is 
> currently inserted (e.g. this could be as coarse as a linecard or as 
> granular as a pluggable optics module).  I.e. it is not the case that 
> the capabilities for all interfaces on a device would be the same, and 
> hence YANG features don't appear to help with this scenario.
> 
> The current assumption is that we would model these dynamic capabilities 
> as operational state leaves.  However, there is a general question as to 
> where these leaves should be placed.  Should they be inline in the 
> interface config tree, or should there be a separate capabilities 
> container to hold them somewhere?

Inline in the config tree means that config must exist for the
capabilities to be able to exist and I do not think this is the case
here. Hence, this is operational state data that should exist in the
state tree.

> Further, in an ideal world it would be desirable to constrain the 
> allowed configuration values to those that are supported by the 
> capabilities, although writing such must statements on the config node 
> that reference state data  is not allowed.

The RFC 7223 model is that interface configuration is applied to
matching interfaces and there is the possibility that this does not
work out (e.g., interface types or interface properties do not match).
Constraining the config by the (dynamic) interface properties would
imply that configurations may become invalid spontaneously, which is
something YANG does not allow. In other words, there can be a mismatch
between 'intended config' and 'applied config' in such situations.

/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 Dec 17 23:59:55 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D83DB1B3426 for ; Thu, 17 Dec 2015 23:59:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 9VG0yuqcS_TJ for ; Thu, 17 Dec 2015 23:59:53 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E931B1B3427 for ; Thu, 17 Dec 2015 23:59:51 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B7535E62; Fri, 18 Dec 2015 08:59:50 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id TqukNt8XMh6O; Fri, 18 Dec 2015 08:59:49 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 18 Dec 2015 08:59:49 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5B1B120056; Fri, 18 Dec 2015 08:59:49 +0100 (CET)
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 xQfH4kvNqWny; Fri, 18 Dec 2015 08:59:48 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D2E7520055; Fri, 18 Dec 2015 08:59:47 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id C12033941E79; Fri, 18 Dec 2015 08:59:47 +0100 (CET)
Date: Fri, 18 Dec 2015 08:59:47 +0100
From: Juergen Schoenwaelder 
To: Kent Watsen 
Message-ID: <20151218075947.GC70138@elstar.local>
Mail-Followup-To: Kent Watsen , "netmod@ietf.org" 
References: <20151217181627.GB68858@elstar.local> <57D42158-C9B5-4CEE-959E-674EBB3EEA97@juniper.net>
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: <57D42158-C9B5-4CEE-959E-674EBB3EEA97@juniper.net>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] review of draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 07:59:55 -0000

On Thu, Dec 17, 2015 at 09:27:12PM +0000, Kent Watsen wrote:
> [As a contributor]
> 
> Thank you for the review Juergen.
> 
> Great suggestions.  If no one objects, I’ll incorporate them into the next revision of the document after last call.
> 
> My one comment is that I don’t believe the document is limited to the introduction of applied configuration. For instance, the relating of config to derived state and also the model structure requirement are not related to applied config.  In all fairness, Requirement #5 (model structure) isn’t even about operational state.

Reading #5 again I must admit that I do not really understand what
this requirement tries to accomplish:

   5.  Ability for distinct modules to leverage a common model-structure

       A.  Focus on the IETF-defined modules, and ideally provides
           guidance to other SDOs

       B.  Multiple domain-specific model-structure trees are okay

       C.  Model-structures may be defined in multiple modules with
           distinct namespaces

At this level of abstraction, #5 really does not mean anything or N
people will have at least N different interpretations of it. I
actually think this should be taken out and moved into a different
document and then it requires to be developed into something much more
concrete.

/js

> So your title and abstract suggestions might define too narrow a scope.  So how about:
> 
> Title: Terminology and Requirements for Operational State and Model Structure
>
> Abstract:
>      This document defines requirements for enhancing the support
>      of operational state through the introduction of a conceptual
>      "applied configuration".  The document also defines requirements
>      enabling distinct modules to leverage a common model structure.
> 
> …and add an Introduction section that expands on this theme further?

I think this is getting into the wrong direction and as explained
above #5 is by far underspecified to be of any value. I suggest to
take it out so that we can publish the rest in a timely manner. The
alternative is to hold off this document in an attempt to replace #5
with something that is concrete and actionable.

/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 Dec 18 00:23:44 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2460D1B3459 for ; Fri, 18 Dec 2015 00:23:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 plzIfhEeZOz1 for ; Fri, 18 Dec 2015 00:23:41 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4F01B3456 for ; Fri, 18 Dec 2015 00:23:41 -0800 (PST)
Received: from localhost (unknown [173.38.220.62]) by mail.tail-f.com (Postfix) with ESMTPSA id E0C511AE0A82 for ; Fri, 18 Dec 2015 09:23:39 +0100 (CET)
Date: Fri, 18 Dec 2015 09:23:41 +0100 (CET)
Message-Id: <20151218.092341.1370454568296215965.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Multipart/Mixed; boundary="--Next_Part(Fri_Dec_18_09_23_41_2015_601)--"
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [netmod] Fw: New Version Notification for draft-bjorklund-netmod-structural-mount-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 08:23:43 -0000

----Next_Part(Fri_Dec_18_09_23_41_2015_601)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

This draft proposes a mechanism for mounting YANG models in other
models.  It focuses on the *schema* only, not on the underlying
mechanism to implement the data (like "peer mount").


/martin

----Next_Part(Fri_Dec_18_09_23_41_2015_601)--
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=-107.5 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,
	RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RP_MATCHES_RCVD,SPF_PASS,URIBL_BLOCKED,
	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 2377D1AE0A82
	for ; Fri, 18 Dec 2015 09:08:49 +0100 (CET)
Received: from ietfa.amsl.com (localhost [IPv6:::1])
	by ietfa.amsl.com (Postfix) with ESMTP id B16861A1B72
	for ; Fri, 18 Dec 2015 00:08:47 -0800 (PST)
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-structural-mount-00.txt
X-Test-IDTracker: no
X-IETF-IDTracker: 6.11.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151218080847.15167.47671.idtracker@ietfa.amsl.com>
Date: Fri, 18 Dec 2015 00:08:47 -0800
X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4
   int  cnt   prob  spamicity histogram
  0.00   48 0.018715 0.018058 ################################################
  0.10    2 0.116340 0.022715 ##
  0.20    0 0.000000 0.022715 
  0.30    0 0.000000 0.022715 
  0.40    0 0.000000 0.022715 
  0.50    0 0.000000 0.022715 
  0.60    0 0.000000 0.022715 
  0.70    0 0.000000 0.022715 
  0.80    0 0.000000 0.022715 
  0.90    0 0.000000 0.022715 


A new version of I-D, draft-bjorklund-netmod-structural-mount-00.txt
has been successfully submitted by Martin Bjorklund and posted to the
IETF repository.

Name:		draft-bjorklund-netmod-structural-mount
Revision:	00
Title:		YANG Structural Mount
Document date:	2015-12-18
Group:		Individual Submission
Pages:		12
URL:            https://www.ietf.org/internet-drafts/draft-bjorklund-netmod-structural-mount-00.txt
Status:         https://datatracker.ietf.org/doc/draft-bjorklund-netmod-structural-mount/
Htmlized:       https://tools.ietf.org/html/draft-bjorklund-netmod-structural-mount-00


Abstract:
   This document defines a mechanism to combine YANG modules into the
   schema defined in other YANG modules.

                                                                                  


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(Fri_Dec_18_09_23_41_2015_601)----


From nobody Fri Dec 18 03:33:52 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 732941A913F for ; Fri, 18 Dec 2015 03:33:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 z-0LrwTJjcO5 for ; Fri, 18 Dec 2015 03:33:48 -0800 (PST)
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 1F9591A9103 for ; Fri, 18 Dec 2015 03:33:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5253; q=dns/txt; s=iport; t=1450438428; x=1451648028; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=JN71Q+8GBxILAbMLvOx3K4vCO4IM8GF2KUyY3lb1LxE=; b=d25FTYwyWaZ9FMh1tZJ5zxhDaNJN+kubBMowZSMDWm8n2G+HyAjzSm6v NakNb9m3a3gBtKjbh/Pz06ELovs8mubgV5WjBSzln57McWNHuuFCAdaOo xGr5Crw/414T0ltg7ymIcgxFgHBWSCr024aWBbDSAW1kRSRn1fnMkXbLo 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsBABQ7nNW/xbLJq1YBoQMbb9TFwqFI?= =?us-ascii?q?koCggcBAQEBAQGBC4Q0AQEBAwEBAQE1NhsLEQQBAQEJJQ8CFigIEwYCAQEXiAw?= =?us-ascii?q?IDr0wAQEBAQEBAQEBAQEBAQEBAQEBARYEhlaEfoQqEQEGCIR2BZZ/jUuBXIdKk?= =?us-ascii?q?AmDdGSEBD40g0+BQgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.20,445,1444694400"; d="scan'208";a="609137050"
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; 18 Dec 2015 11:33:44 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tBIBXi7W029486 for ; Fri, 18 Dec 2015 11:33:44 GMT
To: netmod@ietf.org
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net>
From: Robert Wilton 
Message-ID: <5673EF18.80907@cisco.com>
Date: Fri, 18 Dec 2015 11:33:44 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 11:33:50 -0000

Hi,

On 17/12/2015 23:45, Randy Presuhn wrote:
> Hi -
>
>> From: Robert Wilton
>> Sent: Dec 17, 2015 1:12 PM
>> To: Andy Bierman
>> Cc: "netmod@ietf.org"
>> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
> ...
>>      Your requirement is a bit too strong for my liking.
>>
>>      To paraphrase your requirement text, it is forcing that all
>>      compliant NETCONF/RESTCONF servers MUST support any clients that do
>>      not want to differentiate between intended config and applied
>>      config.
> Do do otherwise sound to me like an interoperability disaster,
> and would encourage the "siloization" of toolsets.
>
>>      However, this requires all opstate aware servers:
>>
>>       - To handle a mix of clients, some of which are opstate aware, and
>>       some that are not.
> This seems perfectly reasonable.  To do otherwise torpedoes the very
> notion of interoperability.
>
>>       - To potentially handle a mix of requests, some of which are
>>       opstate aware requests, and some are not.
> Ditto.
>
>>      It also prevents:
>>
>>       - Having a server that is implemented to only support opstate aware
>>       clients.
> Avoiding the creation of such servers sounds like a *good* thing to me.
>
>>       - Having a server side configuration knob to control the behaviour
>>       (since it would affect the semantics for all clients).
> This also sounds like something which it would be desireable to prevent.
>
> I think I'm squarely with Andy on this one.

Taking a step back ...

I am probably way off the mark, but my perception is that some (perhaps 
many) of the folks in the WG still perceive that the opstate 
requirements are niche requirements for some unusual scenarios, and that 
everyone else is happy with the status quo and don't want/need them.

Alas, I don't share that view.  For me, the opstate requirements can be 
summarized as saying that the operators just want to know what 
configuration the device is actually running in a format that is 
convenient for them to use.  This really doesn't appear to be 
unreasonable request to me, and if I was writing to a network 
manageability API then I would choose to use opstate because I perceive 
that it is a more robust and easier to use API.  The counter arguments 
appear to be that it is too hard for devices to provide this 
information, and that the operators have historically managed without it.

However, I think that several things have changed, and hence negate 
these counter arguments: (i) the operators want to have much more 
automation and management over their devices, (ii) they have found a way 
to group together and have a more vocal voice about what they need and 
want, (iii) the operators have realized that they don't need to wait for 
the SDOs and can create defacto standard models on their own if they 
have to.

Personally, I would like us to stop spending time churning on the 
requirements and actually get on to discussing the solutions.  To be 
honest, there has been relatively little change in my understanding of 
the requirements from reading draft-openconfig-netmod-opstate-01 back in 
July, and I was expecting to discuss the solution drafts back in 
September.  Here we are in December, and I'm not convinced that we have 
truly made significant progress.

The only reason that I submitted a solution draft to this problem was 
because I thought it unlikely that OpenConfig would support a multiple 
datastore solution, and I could see strong resistance amongst the IETF 
engineers to the proposed OpenConfig solution.  I was hoping that my 
proposed solution might be seen for the compromise that it is between 
the two opposing positions.  But I care less on what the solution is, 
and more whether we can agree on one and move forward.

As someone that is quite new to SDO processes, my main concern is that 
IETF (and other standards bodies) are moving too slowly here, and that 
by the time that IETF have produced a sufficiently complete set of YANG 
models to manage network devices it will be too late because the 
industry will already have converged on the OpenConfig models, which 
although not perfect, are close to being usable now, and are being 
evolved at a much quicker pace ...

So my hope for the early new year is that we can reach common ground 
with OpenConfig and converge on a single set of YANG modules for 
managing network devices, and that includes having a solution to the 
Opstate problem.

Finally, if my acquiescing to Andy's requirement is helpful to move this 
process forward then that is fine with me.  As I have previously 
indicated, I don't really think that it helps with framing or discussing 
the solutions, but equally I can live with it since I suspect that the 
solutions are likely to comply with it anyway.

Apologies for the long email, and given I may not be actively reading 
the WG emails over the next couple of weeks, I'll wish you all happy 
holidays!

Thanks,
Rob

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


From nobody Fri Dec 18 04:42:57 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151CE1B3413; Fri, 18 Dec 2015 04:42:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 B4kC8GC7_bq3; Fri, 18 Dec 2015 04:42:54 -0800 (PST)
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 AD29F1B3493; Fri, 18 Dec 2015 04:42:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1614; q=dns/txt; s=iport; t=1450442574; x=1451652174; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JHD85pnH1gwYTCoVuULfdHpK1+6zsQ7cmjSpBHupIYM=; b=U4R5jOWs3nZXYcGRAZPVyFEA3WIxi8Mnnv+slF1fCu5YRKJCnEfRn8t1 0dhKS+sq1Ssx0rpNJDpcG+1AM7YFN7+0Uqh+Vq+cpfjleQB4MdKf75N2M J5PN/2cOsNGPWJCMw+Gd8pgdYpDgjI2Gd9wcyHA6G3gJKS3w6kF99vQX/ 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuBACh/nNW/xbLJq1ehAxtBr88FwqFI?= =?us-ascii?q?koCHIFoAQEBAQEBgQuENAEBAQMBAQEBIBE6CwULAgEIDgoCAiYCAgIlCxUQAgQ?= =?us-ascii?q?OBYgnCA6rQpF0AQEBAQEBAQEBAQEBAQEBAQEBAQEBFASBAYVWgg6Cb4d3L4EaB?= =?us-ascii?q?Y03iUgBjUqdIgFkghEdgVZyhAmBCAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.20,446,1444694400"; d="scan'208";a="609918829"
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; 18 Dec 2015 12:42:51 +0000
Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tBICgnni022254 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Dec 2015 12:42:50 GMT
Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 18 Dec 2015 07:42:49 -0500
Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1104.009; Fri, 18 Dec 2015 07:42:49 -0500
From: "Einar Nilsen-Nygaard (einarnn)" 
To: Nadeau Thomas 
Thread-Topic: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06
Thread-Index: AQHRMp6ZKoRfznJbwESA5CFFcVgh3Z7PjwOAgAAB+oCAABBcAIAAE02AgAFdIIA=
Date: Fri, 18 Dec 2015 12:42:49 +0000
Message-ID: <81FC8933-AE0F-4979-A912-A5FC3905146E@cisco.com>
References:  <5672BAD7.2080003@cisco.com> <1B2DACE1-A8F0-493B-8B61-EF6321790ECE@lucidvision.com> <5672CA38.4060709@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.55.106.4]
Content-Type: text/plain; charset="utf-8"
Content-ID: <1299AFDA0435514EB0604C941F5E43F1@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: Benoit Claise , RTG YANG Design Team , netmod WG 
Subject: Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 12:42:56 -0000

SSBoYXZlIGJlZW4gaW52b2x2ZWQgaW4gc29tZSBkaXNjdXNzaW9ucyB3aXRoaW4gQ2lzY28gcmVs
YXRpbmcgdG8gb3VyIGNvbnRyaWJ1dGlvbnMgdG8gdGhpcyBkcmFmdCwgYW5kIEkgY2FuIHNheSB0
aGF0IHdlIGRpZCBub3Qgc3BlbmQgbXVjaCB0aW1lIGRpc2N1c3Npbmcgc3VjaCBhbiBhZGRpdGlv
biB3aXRoaW4gQ2lzY28uIEkgYW0gbm90IHN1cmUgd2hhdCBkaXNjdXNzaW9ucyB0aGUgQUNMIG1v
ZGVsIGRlc2lnbiB0ZWFtIG1heSBoYXZlIGhhZCBhcyBhIGdyb3VwLg0KDQpIb3dldmVyLCBJIHRo
aW5rIHRoZSBhZGRpdGlvbiBvZiBob3N0bmFtZS1iYXNlZCBtYXRjaGluZyB3b3VsZCBiZSBhIGdy
ZWF0IG9uZSwgYnV0IEkgdGhpbmsgdGhhdCwgaWYgYWRkZWQsIGl0IHNob3VsZCBiZSBtYWRlIG9w
dGlvbmFsIHZpYSBhIGZlYXR1cmUgZHVlIHRvIHRoZSBwb3RlbnRpYWwgY29tcGxleGl0aWVzIG9m
IGltcGxlbWVudGF0aW9uLiBJdCB3b3VsZCBiZSBncmVhdCB0byBzZWUgaWYgd2UgY2FuIGdldCB0
aGlzIGFkZGVkLg0KDQpDaGVlcnMsDQoNCkVpbmFyDQoNCj4gT24gRGVjIDE3LCAyMDE1LCBhdCAz
OjUzIFBNLCBOYWRlYXUgVGhvbWFzIDx0bmFkZWF1QGx1Y2lkdmlzaW9uLmNvbT4gd3JvdGU6DQo+
IA0KPiANCj4gCVlvdSByYWlzZSBhIGdvb2QgcG9pbnQuIERvIHRoZSBjb250cmlidXRvcnMvZWRp
dG9ycyBoYXZlIGFueSB0aG91Z2h0cyBvbg0KPiB0aGlzIHN1Z2dlc3Rpb24/DQo+IA0KPiAJ4oCU
VG9tDQo+IA0KPiANCj4+IE9uIERlYyAxNywgMjAxNTo5OjQ0IEFNLCBhdCA5OjQ0IEFNLCBFbGlv
dCBMZWFyIDxsZWFyQGNpc2NvLmNvbT4gd3JvdGU6DQo+PiANCj4+IA0KPj4gDQo+PiBPbiAxMi8x
Ny8xNSAyOjQ1IFBNLCBOYWRlYXUgVGhvbWFzIHdyb3RlOg0KPj4+IAlEbyB5b3UgbWVhbiBhbiBB
U0NJSSBETlMgbmFtZSAodmVyc3VzIGFuIElQIGFkZHJlc3MgdyBhIG1hc2spPw0KPj4gDQo+PiBJ
IHdhcyB0aGlua2luZyBvZiAiaG9zdCIgaW4gUkZDIDYwMjEuDQo+PiANCj4+IEVsaW90DQo+PiAN
Cj4+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K


From nobody Fri Dec 18 05:32:11 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F9A1B360E; Fri, 18 Dec 2015 05:32:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 Z9RnSg0A04xs; Fri, 18 Dec 2015 05:32:07 -0800 (PST)
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 675C51B360D; Fri, 18 Dec 2015 05:32:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3076; q=dns/txt; s=iport; t=1450445526; x=1451655126; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=FgKWMskM5NS6yAQkPaPY8d3XffIHesWAbFVw9JEaZ8o=; b=NG2O23v4l/fMqGBKajKC3zEIUf7ONTKodIF9njisksHO2qTOfW+i0v9e XUdEBT0GI7ndoS3qRs177RoObbC5jDUA9Q8SlIQ4nVvGG/RhZyf+E1Y5v Vj4yPZya8x6Z0yvWhG/r3ThyQKCO7Trsu1enZN4aZuEGGvMh3ggT8Fjiq M=;
X-Files: signature.asc : 481
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBAAtCnRW/xbLJq1ehAxtv0UXAQmFI?= =?us-ascii?q?koCggIBAQEBAQGBC4Q1AQEEAQEBIEsLEAsEAQkKCSECAg8CFjAGDQYCAQGIKw6?= =?us-ascii?q?rMZFzAQEBAQEBAQEBAQEBAQEBAQEBAQEBDwUEi1SHd4FJBY03iUiCb4FiiHmJJ?= =?us-ascii?q?pQDZIQFPTSFEQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.20,446,1444694400";  d="asc'?scan'208,217";a="609920459"
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; 18 Dec 2015 13:32:04 +0000
Received: from [10.61.67.244] (ams3-vpn-dhcp1012.cisco.com [10.61.67.244]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tBIDW4uZ005667; Fri, 18 Dec 2015 13:32:04 GMT
To: Nadeau Thomas 
References:  <5672BAD7.2080003@cisco.com> <1B2DACE1-A8F0-493B-8B61-EF6321790ECE@lucidvision.com> <5672CA38.4060709@cisco.com>
From: Eliot Lear 
Message-ID: <56740AD3.90904@cisco.com>
Date: Fri, 18 Dec 2015 14:32:03 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <5672CA38.4060709@cisco.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Qslwme51PgwNGAHhS5fXngjcpJIxqK6nK"
Archived-At: 
Cc: Benoit Claise , RTG YANG Design Team , netmod WG 
Subject: Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 13:32:08 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Qslwme51PgwNGAHhS5fXngjcpJIxqK6nK
Content-Type: multipart/alternative;
 boundary="------------050000080301000008020205"

This is a multi-part message in MIME format.
--------------050000080301000008020205
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

I should point out that there's some related IPR in this space that
Cisco has.  Depending on how this gets resolved, we'll file appropriately=
=2E

On 12/17/15 3:44 PM, Eliot Lear wrote:
>
> On 12/17/15 2:45 PM, Nadeau Thomas wrote:
>> 	Do you mean an ASCII DNS name (versus an IP address w a mask)?
> I was thinking of "host" in RFC 6021.
>
> Eliot
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--------------050000080301000008020205
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    I should point out that there's some related IPR in this space that
    Cisco has.=C2=A0 Depending on how this gets resolved, we'll file
    appropriately.

    

    
On 12/17/15 3:44 PM, Eliot Lear wrote:=


    

    

      

On 12/17/15 2:45 PM, Nadeau Thomas wrote:


      

        
	Do you mean an ASCII DNS name (versus an IP addre=
ss w a mask)?


      

      
I was thinking of "host" in RFC 6021.

Eliot




      

      

      

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


    

    

  


--------------050000080301000008020205--

--Qslwme51PgwNGAHhS5fXngjcpJIxqK6nK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2

iQEcBAEBCAAGBQJWdArTAAoJEIe2a0bZ0nozvecH/1DvMK+c55x6diau5Mjj8j6U
EMci048aikw+ffRvnO2LcevdXP2R4rmuFcVeCa+siimLT9BiXsMCsUyt4mYAo5HF
6aq9N4iuuefy0lAlXDEjyIDLHaO5PrDFzr+/kY4HcMbRDTS6LeCudCHnO0jGCB7g
SF7rthIb+ibIN2em+h/DeuMvXp6SYYvD7iGdbpyv9NXpHmHHXsc2jAkS2VbCeDAT
NQTAQN/y8rCd2owBi7S4gkaQKdP3Kg3nukRRywNrXad1J5HE9TWvfrIVyj8xdsxg
JaihuUqUNpdec+D4uPZDhpF6/qlOMr9q7qZeHAymZQPRqqx34zi4fDZYIkE5pOI=
=+8bP
-----END PGP SIGNATURE-----

--Qslwme51PgwNGAHhS5fXngjcpJIxqK6nK--


From nobody Fri Dec 18 05:52:04 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 866641B3638 for ; Fri, 18 Dec 2015 05:52:03 -0800 (PST)
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
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 QbRCGcgtFgFi for ; Fri, 18 Dec 2015 05:52:00 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 606011B3619 for ; Fri, 18 Dec 2015 05:52:00 -0800 (PST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 346EC1CC008F for ; Fri, 18 Dec 2015 14:52:02 +0100 (CET)
From: Ladislav Lhotka 
To: netmod@ietf.org
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Fri, 18 Dec 2015 14:52:02 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: [netmod] structural mount versus YSDL
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 13:52:03 -0000

Hi,

we now have two drafts with pull-style mechanism of combining data
models:

- draft-bjorklund-netmod-structural-mount-00
- draft-lhotka-netmod-ysdl-00

In many aspects they are quite similar, yet there are also substantial
differences that deserve to be discussed. In believe the underlying
problem is really pressing, and we should probably try to merge both
approaches and come up with a single solution asap.

In my view, the main differences are the following:

1. Structural mount uses a YANG extension while YSDL doesn't require any
   changes in YANG.

2. Structural mount allows for attaching sub-models only to places
   identified with "mount-point" extension, in YSDL all container,
   list, case and anydata nodes are eligible as "mount points".

3. Structural mount provides the meta-schema as regular state data, YSDL
   assumes they will be available to clients as a separate resource, or
   perhaps as an (optional) part of yang-library.

4. Structural mount puts yang-library data into the meta-schema while
   YSDL just uses references to the "standard" yang-library.

5. Structural mount allows different entries of the same list to contain
   different mounted data models (via instances of yang-library), in
   YSDL this can be achieved indirectly by defining a choice in the
   "super-schema" and assigning different schemas to its cases.

6. If the same set of modules is to be mounted in several locations,
   then in structural mount the same yang-library information has to be
   copied to all locations. YSDL offers the "schema" construct as kind
   of "grouping of modules" that can be referred to from different
   locations.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Fri Dec 18 06:08:52 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B82F1B3654 for ; Fri, 18 Dec 2015 06:08:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 G8mEkhx36qTT for ; Fri, 18 Dec 2015 06:08:40 -0800 (PST)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 CFCF81B3658 for ; Fri, 18 Dec 2015 06:08:39 -0800 (PST)
Received: by mail-lf0-x234.google.com with SMTP id y184so73210776lfc.1 for ; Fri, 18 Dec 2015 06:08:39 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=qtBrpATutD7CMUmWQ9Y1MX0YhIL8AxIZHQpsjgWj668=; b=HZN6YggZi8Pj/8JTyEBlHueT50KqlvojjL5yDO666s4MZKlzJEcWRHBnOpZRm8T5Zf UsuuTMV1b0kZp9S2zzUHVGhOPACP1/Q97ZDxQk2A4B3l7u2zh57UFiZUMNfCkrMEo52r WxtTVL0ED0QiRrhBzixaNzoP+lTeYrTkC+sV8m7xW/jGELlCswGKYXf1ut9y/k5AFmID eBCW3RKVs9oDFYZblNmWga7qgEGwtblAfYJpNFLuPTAiG3d+MUMFaERziF4TfQCQ8Xel 8Toh14saMgTGLgGau+ooLPYBX5dnTyfifmEmSSmw63qODwxlkyX1X7iSSrUDWHkMSz2Q ilEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=qtBrpATutD7CMUmWQ9Y1MX0YhIL8AxIZHQpsjgWj668=; b=QxMdrF8JwdwhwDeUE+OhZ5F2zAbmg2OColj4Eq6+iHP7ThQgNOMcRsgx9JwzKoh+6K ostiFBnjyqTl/sJ7f6ClC7YphBZqg+kOtYbJ94o2p0YfsLo5k0KXowQ0lrK4fiezvaLJ kdfQvGzSqz4Xn7BZtdhvxeQBQGV6FG4wqgpDF8kVPCRIQYWrKi/h7NXcAYNi8+AQ6KLy bFaMe1Ph+els0kzum5iGiWbzROGkrulTvI2Vml9SImM1Zad3a9bnXRIO48wmMOD4pKtD GaKMM9mhXVpC+BKJJn+ZCAhKF/XpxzStOz8i7ew+me38T7pz4U2H90l1ZEN21Tb+BNV1 lkew==
X-Gm-Message-State: ALoCoQmgUYTEZIIJr8k8FiS5yfM3BaRxHl6EgNaOl0+8Jd+fJCirCijvF9hmMwPVlfUGm35zum9lkHpdjCZ2uw0de1bgUV5B7g==
MIME-Version: 1.0
X-Received: by 10.25.88.67 with SMTP id m64mr1513953lfb.23.1450447717874; Fri, 18 Dec 2015 06:08:37 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Fri, 18 Dec 2015 06:08:37 -0800 (PST)
In-Reply-To: <5673EF18.80907@cisco.com>
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com>
Date: Fri, 18 Dec 2015 06:08:37 -0800
Message-ID: 
From: Andy Bierman 
To: Robert Wilton 
Content-Type: multipart/alternative; boundary=001a1141a07cfd581505272cacb9
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 14:08:47 -0000

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

On Fri, Dec 18, 2015 at 3:33 AM, Robert Wilton  wrote:

> Hi,
>
> On 17/12/2015 23:45, Randy Presuhn wrote:
>
>> Hi -
>>
>> From: Robert Wilton
>>> Sent: Dec 17, 2015 1:12 PM
>>> To: Andy Bierman
>>> Cc: "netmod@ietf.org"
>>> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>>>
>> ...
>>
>>>      Your requirement is a bit too strong for my liking.
>>>
>>>      To paraphrase your requirement text, it is forcing that all
>>>      compliant NETCONF/RESTCONF servers MUST support any clients that do
>>>      not want to differentiate between intended config and applied
>>>      config.
>>>
>> Do do otherwise sound to me like an interoperability disaster,
>> and would encourage the "siloization" of toolsets.
>>
>>      However, this requires all opstate aware servers:
>>>
>>>       - To handle a mix of clients, some of which are opstate aware, and
>>>       some that are not.
>>>
>> This seems perfectly reasonable.  To do otherwise torpedoes the very
>> notion of interoperability.
>>
>>       - To potentially handle a mix of requests, some of which are
>>>       opstate aware requests, and some are not.
>>>
>> Ditto.
>>
>>      It also prevents:
>>>
>>>       - Having a server that is implemented to only support opstate aware
>>>       clients.
>>>
>> Avoiding the creation of such servers sounds like a *good* thing to me.
>>
>>       - Having a server side configuration knob to control the behaviour
>>>       (since it would affect the semantics for all clients).
>>>
>> This also sounds like something which it would be desireable to prevent.
>>
>> I think I'm squarely with Andy on this one.
>>
>
> Taking a step back ...
>
> I am probably way off the mark, but my perception is that some (perhaps
> many) of the folks in the WG still perceive that the opstate requirements
> are niche requirements for some unusual scenarios, and that everyone else
> is happy with the status quo and don't want/need them.
>
> Alas, I don't share that view.  For me, the opstate requirements can be
> summarized as saying that the operators just want to know what
> configuration the device is actually running in a format that is convenient
> for them to use.  This really doesn't appear to be unreasonable request to
> me, and if I was writing to a network manageability API then I would choose
> to use opstate because I perceive that it is a more robust and easier to
> use API.  The counter arguments appear to be that it is too hard for
> devices to provide this information, and that the operators have
> historically managed without it.
>
> However, I think that several things have changed, and hence negate these
> counter arguments: (i) the operators want to have much more automation and
> management over their devices, (ii) they have found a way to group together
> and have a more vocal voice about what they need and want, (iii) the
> operators have realized that they don't need to wait for the SDOs and can
> create defacto standard models on their own if they have to.
>
> Personally, I would like us to stop spending time churning on the
> requirements and actually get on to discussing the solutions.  To be
> honest, there has been relatively little change in my understanding of the
> requirements from reading draft-openconfig-netmod-opstate-01 back in July,
> and I was expecting to discuss the solution drafts back in September.  Here
> we are in December, and I'm not convinced that we have truly made
> significant progress.
>
> The only reason that I submitted a solution draft to this problem was
> because I thought it unlikely that OpenConfig would support a multiple
> datastore solution, and I could see strong resistance amongst the IETF
> engineers to the proposed OpenConfig solution.  I was hoping that my
> proposed solution might be seen for the compromise that it is between the
> two opposing positions.  But I care less on what the solution is, and more
> whether we can agree on one and move forward.
>
> As someone that is quite new to SDO processes, my main concern is that
> IETF (and other standards bodies) are moving too slowly here, and that by
> the time that IETF have produced a sufficiently complete set of YANG models
> to manage network devices it will be too late because the industry will
> already have converged on the OpenConfig models, which although not
> perfect, are close to being usable now, and are being evolved at a much
> quicker pace ...
>
> So my hope for the early new year is that we can reach common ground with
> OpenConfig and converge on a single set of YANG modules for managing
> network devices, and that includes having a solution to the Opstate problem.
>
> Finally, if my acquiescing to Andy's requirement is helpful to move this
> process forward then that is fine with me.  As I have previously indicated,
> I don't really think that it helps with framing or discussing the
> solutions, but equally I can live with it since I suspect that the
> solutions are likely to comply with it anyway.
>
> Apologies for the long email, and given I may not be actively reading the
> WG emails over the next couple of weeks, I'll wish you all happy holidays!
>
>

The "old manager/new agent" problem has been around for at least 3 decades.
Experience has shown that adding new features in a way that does not break
existing deployments requires forethought and planning.

The backward compatibility requirement is not hard to meet.
Simply require the client to opt-in to the new behavior.
That's it.  Problem solved.



> Thanks,
> Rob
>
>
>>

Andy


> Randy
>>
>> _______________________________________________
>> 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
>

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




On Fri, Dec 18, 2015 at 3:33 AM, Robert Wilton <rwilton@cisco.com&=
gt; wrote:
Hi,



On 17/12/2015 23:45, Randy Presuhn wrote:



Hi -





From: Robert Wilton

Sent: Dec 17, 2015 1:12 PM

To: Andy Bierman

Cc: "netmod@ietf.=
org"

Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01



...



=C2=A0 =C2=A0 =C2=A0Your requirement is a bit too strong for my liking.



=C2=A0 =C2=A0 =C2=A0To paraphrase your requirement text, it is forcing that=
 all

=C2=A0 =C2=A0 =C2=A0compliant NETCONF/RESTCONF servers MUST support any cli=
ents that do

=C2=A0 =C2=A0 =C2=A0not want to differentiate between intended config and a=
pplied

=C2=A0 =C2=A0 =C2=A0config.



Do do otherwise sound to me like an interoperability disaster,

and would encourage the "siloization" of toolsets.





=C2=A0 =C2=A0 =C2=A0However, this requires all opstate aware servers:



=C2=A0 =C2=A0 =C2=A0 - To handle a mix of clients, some of which are opstat=
e aware, and

=C2=A0 =C2=A0 =C2=A0 some that are not.



This seems perfectly reasonable.=C2=A0 To do otherwise torpedoes the very
notion of interoperability.





=C2=A0 =C2=A0 =C2=A0 - To potentially handle a mix of requests, some of whi=
ch are

=C2=A0 =C2=A0 =C2=A0 opstate aware requests, and some are not.



Ditto.





=C2=A0 =C2=A0 =C2=A0It also prevents:



=C2=A0 =C2=A0 =C2=A0 - Having a server that is implemented to only support =
opstate aware

=C2=A0 =C2=A0 =C2=A0 clients.



Avoiding the creation of such servers sounds like a *good* thing to me.





=C2=A0 =C2=A0 =C2=A0 - Having a server side configuration knob to control t=
he behaviour

=C2=A0 =C2=A0 =C2=A0 (since it would affect the semantics for all clients).=




This also sounds like something which it would be desireable to prevent.


I think I'm squarely with Andy on this one.





Taking a step back ...



I am probably way off the mark, but my perception is that some (perhaps man=
y) of the folks in the WG still perceive that the opstate requirements are =
niche requirements for some unusual scenarios, and that everyone else is ha=
ppy with the status quo and don't want/need them.



Alas, I don't share that view.=C2=A0 For me, the opstate requirements c=
an be summarized as saying that the operators just want to know what config=
uration the device is actually running in a format that is convenient for t=
hem to use.=C2=A0 This really doesn't appear to be unreasonable request=
 to me, and if I was writing to a network manageability API then I would ch=
oose to use opstate because I perceive that it is a more robust and easier =
to use API.=C2=A0 The counter arguments appear to be that it is too hard fo=
r devices to provide this information, and that the operators have historic=
ally managed without it.



However, I think that several things have changed, and hence negate these c=
ounter arguments: (i) the operators want to have much more automation and m=
anagement over their devices, (ii) they have found a way to group together =
and have a more vocal voice about what they need and want, (iii) the operat=
ors have realized that they don't need to wait for the SDOs and can cre=
ate defacto standard models on their own if they have to.



Personally, I would like us to stop spending time churning on the requireme=
nts and actually get on to discussing the solutions.=C2=A0 To be honest, th=
ere has been relatively little change in my understanding of the requiremen=
ts from reading draft-openconfig-netmod-opstate-01 back in July, and I was =
expecting to discuss the solution drafts back in September.=C2=A0 Here we a=
re in December, and I'm not convinced that we have truly made significa=
nt progress.



The only reason that I submitted a solution draft to this problem was becau=
se I thought it unlikely that OpenConfig would support a multiple datastore=
 solution, and I could see strong resistance amongst the IETF engineers to =
the proposed OpenConfig solution.=C2=A0 I was hoping that my proposed solut=
ion might be seen for the compromise that it is between the two opposing po=
sitions.=C2=A0 But I care less on what the solution is, and more whether we=
 can agree on one and move forward.



As someone that is quite new to SDO processes, my main concern is that IETF=
 (and other standards bodies) are moving too slowly here, and that by the t=
ime that IETF have produced a sufficiently complete set of YANG models to m=
anage network devices it will be too late because the industry will already=
 have converged on the OpenConfig models, which although not perfect, are c=
lose to being usable now, and are being evolved at a much quicker pace ...<=
br>


So my hope for the early new year is that we can reach common ground with O=
penConfig and converge on a single set of YANG modules for managing network=
 devices, and that includes having a solution to the Opstate problem.



Finally, if my acquiescing to Andy's requirement is helpful to move thi=
s process forward then that is fine with me.=C2=A0 As I have previously ind=
icated, I don't really think that it helps with framing or discussing t=
he solutions, but equally I can live with it since I suspect that the solut=
ions are likely to comply with it anyway.



Apologies for the long email, and given I may not be actively reading the W=
G emails over the next couple of weeks, I'll wish you all happy holiday=
s!




The "old manager/n=
ew agent" problem has been around for at least 3 decades.
Ex=
perience has shown that adding new features in a way that does not break
existing deployments requires forethought and planning.
<=
br>
The backward compatibility requirement is not hard to meet.
Simply require the client to opt-in to the new behavior.
That's it.=C2=A0 Problem solved.

=C2=A0

Thanks,

Rob








Andy
=

=C2=A0

Randy



_______________________________________________

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





--001a1141a07cfd581505272cacb9--


From nobody Fri Dec 18 06:22:50 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEABC1B3654 for ; Fri, 18 Dec 2015 06:22:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 V9G8oH5DzZew for ; Fri, 18 Dec 2015 06:22:47 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C3E51B2A64 for ; Fri, 18 Dec 2015 06:22:46 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:95f1:e5af:5d06:4c6f] (unknown [IPv6:2001:718:1a02:1:95f1:e5af:5d06:4c6f]) by mail.nic.cz (Postfix) with ESMTPSA id B497D1812D4; Fri, 18 Dec 2015 15:22:44 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450448564; bh=BOHpjfV8uFtzoeu3/pVCGvVAqw9sXCYZ6UcD2wajc88=; h=From:Date:To; b=ls4jJq6n4l/gjtEk6okKo51IUxt3NSIX38mnzG5/VM3bsOkK6/w1aJFUTF7eaYdg6 7/juN0eYndeKoeM/HicWtzDgfwqbfyIATTcV6Pg8e3xdxgtQXq25eaGSNhzwVfZ+pw yrvTAIJVZlrQOtd9tusFxa0fzCCMKBIoi1GYUC+s=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Fri, 18 Dec 2015 15:22:48 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <110786DF-5106-4281-9870-E435A4754888@nic.cz>
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 14:22:49 -0000

> On 18 Dec 2015, at 15:08, Andy Bierman  wrote:
>=20
>=20
>=20
> On Fri, Dec 18, 2015 at 3:33 AM, Robert Wilton  =
wrote:
> Hi,
>=20
> On 17/12/2015 23:45, Randy Presuhn wrote:
> Hi -
>=20
> From: Robert Wilton
> Sent: Dec 17, 2015 1:12 PM
> To: Andy Bierman
> Cc: "netmod@ietf.org"
> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
> ...
>      Your requirement is a bit too strong for my liking.
>=20
>      To paraphrase your requirement text, it is forcing that all
>      compliant NETCONF/RESTCONF servers MUST support any clients that =
do
>      not want to differentiate between intended config and applied
>      config.
> Do do otherwise sound to me like an interoperability disaster,
> and would encourage the "siloization" of toolsets.
>=20
>      However, this requires all opstate aware servers:
>=20
>       - To handle a mix of clients, some of which are opstate aware, =
and
>       some that are not.
> This seems perfectly reasonable.  To do otherwise torpedoes the very
> notion of interoperability.
>=20
>       - To potentially handle a mix of requests, some of which are
>       opstate aware requests, and some are not.
> Ditto.
>=20
>      It also prevents:
>=20
>       - Having a server that is implemented to only support opstate =
aware
>       clients.
> Avoiding the creation of such servers sounds like a *good* thing to =
me.
>=20
>       - Having a server side configuration knob to control the =
behaviour
>       (since it would affect the semantics for all clients).
> This also sounds like something which it would be desireable to =
prevent.
>=20
> I think I'm squarely with Andy on this one.
>=20
> Taking a step back ...
>=20
> I am probably way off the mark, but my perception is that some =
(perhaps many) of the folks in the WG still perceive that the opstate =
requirements are niche requirements for some unusual scenarios, and that =
everyone else is happy with the status quo and don't want/need them.
>=20
> Alas, I don't share that view.  For me, the opstate requirements can =
be summarized as saying that the operators just want to know what =
configuration the device is actually running in a format that is =
convenient for them to use.  This really doesn't appear to be =
unreasonable request to me, and if I was writing to a network =
manageability API then I would choose to use opstate because I perceive =
that it is a more robust and easier to use API.  The counter arguments =
appear to be that it is too hard for devices to provide this =
information, and that the operators have historically managed without =
it.
>=20
> However, I think that several things have changed, and hence negate =
these counter arguments: (i) the operators want to have much more =
automation and management over their devices, (ii) they have found a way =
to group together and have a more vocal voice about what they need and =
want, (iii) the operators have realized that they don't need to wait for =
the SDOs and can create defacto standard models on their own if they =
have to.
>=20
> Personally, I would like us to stop spending time churning on the =
requirements and actually get on to discussing the solutions.  To be =
honest, there has been relatively little change in my understanding of =
the requirements from reading draft-openconfig-netmod-opstate-01 back in =
July, and I was expecting to discuss the solution drafts back in =
September.  Here we are in December, and I'm not convinced that we have =
truly made significant progress.
>=20
> The only reason that I submitted a solution draft to this problem was =
because I thought it unlikely that OpenConfig would support a multiple =
datastore solution, and I could see strong resistance amongst the IETF =
engineers to the proposed OpenConfig solution.  I was hoping that my =
proposed solution might be seen for the compromise that it is between =
the two opposing positions.  But I care less on what the solution is, =
and more whether we can agree on one and move forward.
>=20
> As someone that is quite new to SDO processes, my main concern is that =
IETF (and other standards bodies) are moving too slowly here, and that =
by the time that IETF have produced a sufficiently complete set of YANG =
models to manage network devices it will be too late because the =
industry will already have converged on the OpenConfig models, which =
although not perfect, are close to being usable now, and are being =
evolved at a much quicker pace ...
>=20
> So my hope for the early new year is that we can reach common ground =
with OpenConfig and converge on a single set of YANG modules for =
managing network devices, and that includes having a solution to the =
Opstate problem.
>=20
> Finally, if my acquiescing to Andy's requirement is helpful to move =
this process forward then that is fine with me.  As I have previously =
indicated, I don't really think that it helps with framing or discussing =
the solutions, but equally I can live with it since I suspect that the =
solutions are likely to comply with it anyway.
>=20
> Apologies for the long email, and given I may not be actively reading =
the WG emails over the next couple of weeks, I'll wish you all happy =
holidays!
>=20
>=20
>=20
> The "old manager/new agent" problem has been around for at least 3 =
decades.
> Experience has shown that adding new features in a way that does not =
break
> existing deployments requires forethought and planning.
>=20
> The backward compatibility requirement is not hard to meet.

Is it not? I would say it severely restricts the workflow for the data =
model development. The ultra-conservative update rules essentially =
permit only incremental changes to published modules. This would be fine =
if the data model landscape already was reasonably stable. We are not =
that far though, and everything is in flux. So I believe we would be =
much better off with "release early - release often" strategy, which is =
made impossible by the existing update rules.

Lada

> Simply require the client to opt-in to the new behavior.
> That's it.  Problem solved.
>=20
> =20
> Thanks,
> Rob
>=20
>=20
>=20
>=20
> Andy
> =20
> Randy
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Fri Dec 18 06:33:02 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AA41B2DE1 for ; Fri, 18 Dec 2015 06:33:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 GA2DPvjHud3B for ; Fri, 18 Dec 2015 06:33:00 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 190C21B2DB8 for ; Fri, 18 Dec 2015 06:33:00 -0800 (PST)
Received: from localhost (unknown [173.38.220.62]) by mail.tail-f.com (Postfix) with ESMTPSA id CE1461AE0A82; Fri, 18 Dec 2015 15:32:58 +0100 (CET)
Date: Fri, 18 Dec 2015 15:32:59 +0100 (CET)
Message-Id: <20151218.153259.2025312173249962491.mbj@tail-f.com>
To: kwatsen@juniper.net
From: Martin Bjorklund 
In-Reply-To: <411F084C-B435-4CBA-93C7-AA4213958A21@juniper.net>
References: <411F084C-B435-4CBA-93C7-AA4213958A21@juniper.net>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] call for consensus to adopt draft-wilton-netmod-intf-ext-yang as NETMOD WG draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 14:33:01 -0000

Kent Watsen  wrote:
> 
> The minutes for IETF 95 show that there was in-room support for
> adopting draft-wilton-netmod-intf-ext-yang as a WG draft.  The minutes
> also show that this decision would be confirmed on the mailing list,
> which I am doing now.
> 
> Should we move to adopt draft-wilton-netmod-intf-ext-yang as a WG item
> and correspondingly add this to the WG charter as a milestone?  Please
> comment by Tuesday, December 22, 2015 at 9AM EST at which time the WG
> Chairs will gauge whether or not there is consensus to move forward
> with the document.

I support the adoption of this draft and I will review and discuss it.


/martin


From nobody Fri Dec 18 06:50:01 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524D41B366C for ; Fri, 18 Dec 2015 06:50:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 k8-B-H9ST0SU for ; Fri, 18 Dec 2015 06:49:56 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AF301A916B for ; Fri, 18 Dec 2015 06:49:55 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B55D11492; Fri, 18 Dec 2015 15:49:53 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 39KWP2sJdYgk; Fri, 18 Dec 2015 15:49:53 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 18 Dec 2015 15:49:53 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C02A020058; Fri, 18 Dec 2015 15:49:52 +0100 (CET)
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 Psw6bC76Rct2; Fri, 18 Dec 2015 15:49:52 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 57BEC20055; Fri, 18 Dec 2015 15:49:51 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 8532D3942457; Fri, 18 Dec 2015 15:49:49 +0100 (CET)
Date: Fri, 18 Dec 2015 15:49:48 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20151218144948.GB71024@elstar.local>
Mail-Followup-To: Ladislav Lhotka , "netmod@ietf.org" 
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com>  <110786DF-5106-4281-9870-E435A4754888@nic.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <110786DF-5106-4281-9870-E435A4754888@nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 14:50:00 -0000

On Fri, Dec 18, 2015 at 03:22:48PM +0100, Ladislav Lhotka wrote:
> 
> Is it not? I would say it severely restricts the workflow for the data model development. The ultra-conservative update rules essentially permit only incremental changes to published modules. This would be fine if the data model landscape already was reasonably stable. We are not that far though, and everything is in flux. So I believe we would be much better off with "release early - release often" strategy, which is made impossible by the existing update rules.
>

There is a "release early - release often cycle" in the IETF process -
it is called the Internet Drafts stage. Unfortunately, often people
wait for things to stabilize (becoming an RFC) before implementing. I
assume we would have fewer but more solid data models if they would
all come along with running code behind them (and ideally > 1
independent implementations). The problem might be "us" and not the
update rules.

/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 Dec 18 07:16:06 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA4D1B33DB for ; Fri, 18 Dec 2015 07:16:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level: 
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 tWvDz2_G2i8S for ; Fri, 18 Dec 2015 07:16:02 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 687481B3426 for ; Fri, 18 Dec 2015 07:16:02 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:95f1:e5af:5d06:4c6f] (unknown [IPv6:2001:718:1a02:1:95f1:e5af:5d06:4c6f]) by mail.nic.cz (Postfix) with ESMTPSA id D207D180EAA; Fri, 18 Dec 2015 16:16:00 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450451760; bh=hAIOZpflRwxAXpYUq8ba57hdsQtDxTXO6gF/hRQofUM=; h=From:Date:To; b=iXhVn1OgqG951zitjbc/lC3dbXKGx1XPgCbalsgojmOt/oMkXoBy0KUO8iUWpFFwL 4ptPKCROp2QoNYb0u/gIq2eh/pTSn/ArDiJCRaDGpJxp+9xTlLApxtnYo2BYSyyprm 9sLbIcoaVvH7q5AUWwnXxXyH7hNObuY7IHSNuwQA=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <20151218144948.GB71024@elstar.local>
Date: Fri, 18 Dec 2015 16:16:04 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <85BE92FD-33DE-4BE1-AF9E-E4E5FAF330A2@nic.cz>
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com>  <110786DF-5106-4281-9870-E435A4754888@nic.cz> <20151218144948.GB71024@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 15:16:06 -0000

> On 18 Dec 2015, at 15:49, Juergen Schoenwaelder =
 wrote:
>=20
> On Fri, Dec 18, 2015 at 03:22:48PM +0100, Ladislav Lhotka wrote:
>>=20
>> Is it not? I would say it severely restricts the workflow for the =
data model development. The ultra-conservative update rules essentially =
permit only incremental changes to published modules. This would be fine =
if the data model landscape already was reasonably stable. We are not =
that far though, and everything is in flux. So I believe we would be =
much better off with "release early - release often" strategy, which is =
made impossible by the existing update rules.
>>=20
>=20
> There is a "release early - release often cycle" in the IETF process -
> it is called the Internet Drafts stage. Unfortunately, often people
> wait for things to stabilize (becoming an RFC) before implementing. I

There are other disadvantages to I-Ds, for example that they have to be =
updated every six months. It is actually funny: RFC used to mean =
"request for comments", then later I-D acquired this role, so now we =
probably need a "drafty draft" category.

> assume we would have fewer but more solid data models if they would
> all come along with running code behind them (and ideally > 1
> independent implementations). The problem might be "us" and not the
> update rules.

The update rules mean that it is risky to publish a data model in an =
RFC. And indeed, if there is a need, for one reason or another, to =
restructure, for example, ietf-interfaces, it will have to become a new =
module (ietf-interfaces-dash?) and the revision history will be broken. =
Doing this more than once would turn the data model ecosystem into a =
mess.

Backward compatibility is nice, but making it an absolute requirement, =
which is even ingrained in the data modelling language specification, is =
IMO absurd.

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Fri Dec 18 07:25:23 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D081B2ED3 for ; Fri, 18 Dec 2015 07:25:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 vQqZR01VJmIu for ; Fri, 18 Dec 2015 07:25:19 -0800 (PST)
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 DE6481B369F for ; Fri, 18 Dec 2015 07:25:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7940; q=dns/txt; s=iport; t=1450452310; x=1451661910; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=f6qR0wx8wSVtqjSuTXPGBc7VkOIBV++1mGL6HjOhrNw=; b=SaumXRZsAl1afNW3EgcvkZsPBt3zfIB9J3TK9yrkwZql3hreEf14Ta9N CF0Lux6u4LZSAO+rRwq0kNNmqk8bb9wsoJVg9RRSwP683DnYpsreXOdOQ YR3uIYmlFbcDrQM0gUf00gnwga8kORcRAla2/cMf7Rwl/E3KKvMgjAFWE M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AWAgBpJHRW/4ENJK1YBoM6Um0GvVABD?= =?us-ascii?q?YFiFwqFIkoCHIEeOBQBAQEBAQEBgQqENAEBAQQBAQEgETobAgEIEQQBAQECAiY?= =?us-ascii?q?CAgIlCxUICAIEARIbiBQOq1SRbwEBAQEBAQEBAQEBAQEBAQEBAQEBARQEgQGKU?= =?us-ascii?q?4QqCgcBBggPGIMGgUkFln8BjUmBXJdZg3MBIAEBQoQEcoNGCRcjgQgBAQE?=
X-IronPort-AV: E=Sophos;i="5.20,446,1444694400"; d="scan'208";a="219439341"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Dec 2015 15:25:09 +0000
Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id tBIFP977008391 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 18 Dec 2015 15:25:09 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 18 Dec 2015 10:25:08 -0500
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.1104.009; Fri, 18 Dec 2015 10:25:08 -0500
From: "Acee Lindem (acee)" 
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" ,  "netmod@ietf.org" 
Thread-Topic: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
Thread-Index: AQHROST+Qi5eUPyFCUOmbJF1PR1M/Z7Q8W4A///s0wA=
Date: Fri, 18 Dec 2015 15:25:08 +0000
Message-ID: 
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com>
In-Reply-To: <5673EF18.80907@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.199]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 15:25:21 -0000

SGkgUm9iLCANClRoYW5rcyBmb3IgYXV0aG9yaW5nIHRoZSBjb21wcmVoZW5zaXZlIHJlc3BvbnNl
LiBJ4oCZbSBpbiBjb21wbGV0ZSBhZ3JlZW1lbnQNCmFuZCBzdXBwb3J0IHB1YmxpY2F0aW9uIG9m
IHRoZSBkb2N1bWVudC4NClRoYW5rcywNCkFjZWUgDQoNCk9uIDEyLzE4LzE1LCA2OjMzIEFNLCAi
bmV0bW9kIG9uIGJlaGFsZiBvZiBSb2JlcnQgV2lsdG9uIC1YIChyd2lsdG9uIC0NCkVOU09GVCBM
SU1JVEVEIGF0IENpc2NvKSIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZg0K
cndpbHRvbkBjaXNjby5jb20+IHdyb3RlOg0KDQo+SGksDQo+DQo+T24gMTcvMTIvMjAxNSAyMzo0
NSwgUmFuZHkgUHJlc3VobiB3cm90ZToNCj4+IEhpIC0NCj4+DQo+Pj4gRnJvbTogUm9iZXJ0IFdp
bHRvbg0KPj4+IFNlbnQ6IERlYyAxNywgMjAxNSAxOjEyIFBNDQo+Pj4gVG86IEFuZHkgQmllcm1h
bg0KPj4+IENjOiAibmV0bW9kQGlldGYub3JnIg0KPj4+IFN1YmplY3Q6IFJlOiBbbmV0bW9kXSBO
RVRNT0QgV0cgTEM6IGRyYWZ0LWlldGYtbmV0bW9kLW9wc3RhdGUtcmVxcy0wMQ0KPj4gLi4uDQo+
Pj4gICAgICBZb3VyIHJlcXVpcmVtZW50IGlzIGEgYml0IHRvbyBzdHJvbmcgZm9yIG15IGxpa2lu
Zy4NCj4+Pg0KPj4+ICAgICAgVG8gcGFyYXBocmFzZSB5b3VyIHJlcXVpcmVtZW50IHRleHQsIGl0
IGlzIGZvcmNpbmcgdGhhdCBhbGwNCj4+PiAgICAgIGNvbXBsaWFudCBORVRDT05GL1JFU1RDT05G
IHNlcnZlcnMgTVVTVCBzdXBwb3J0IGFueSBjbGllbnRzIHRoYXQNCj4+PmRvDQo+Pj4gICAgICBu
b3Qgd2FudCB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gaW50ZW5kZWQgY29uZmlnIGFuZCBhcHBs
aWVkDQo+Pj4gICAgICBjb25maWcuDQo+PiBEbyBkbyBvdGhlcndpc2Ugc291bmQgdG8gbWUgbGlr
ZSBhbiBpbnRlcm9wZXJhYmlsaXR5IGRpc2FzdGVyLA0KPj4gYW5kIHdvdWxkIGVuY291cmFnZSB0
aGUgInNpbG9pemF0aW9uIiBvZiB0b29sc2V0cy4NCj4+DQo+Pj4gICAgICBIb3dldmVyLCB0aGlz
IHJlcXVpcmVzIGFsbCBvcHN0YXRlIGF3YXJlIHNlcnZlcnM6DQo+Pj4NCj4+PiAgICAgICAtIFRv
IGhhbmRsZSBhIG1peCBvZiBjbGllbnRzLCBzb21lIG9mIHdoaWNoIGFyZSBvcHN0YXRlIGF3YXJl
LA0KPj4+YW5kDQo+Pj4gICAgICAgc29tZSB0aGF0IGFyZSBub3QuDQo+PiBUaGlzIHNlZW1zIHBl
cmZlY3RseSByZWFzb25hYmxlLiAgVG8gZG8gb3RoZXJ3aXNlIHRvcnBlZG9lcyB0aGUgdmVyeQ0K
Pj4gbm90aW9uIG9mIGludGVyb3BlcmFiaWxpdHkuDQo+Pg0KPj4+ICAgICAgIC0gVG8gcG90ZW50
aWFsbHkgaGFuZGxlIGEgbWl4IG9mIHJlcXVlc3RzLCBzb21lIG9mIHdoaWNoIGFyZQ0KPj4+ICAg
ICAgIG9wc3RhdGUgYXdhcmUgcmVxdWVzdHMsIGFuZCBzb21lIGFyZSBub3QuDQo+PiBEaXR0by4N
Cj4+DQo+Pj4gICAgICBJdCBhbHNvIHByZXZlbnRzOg0KPj4+DQo+Pj4gICAgICAgLSBIYXZpbmcg
YSBzZXJ2ZXIgdGhhdCBpcyBpbXBsZW1lbnRlZCB0byBvbmx5IHN1cHBvcnQgb3BzdGF0ZQ0KPj4+
YXdhcmUNCj4+PiAgICAgICBjbGllbnRzLg0KPj4gQXZvaWRpbmcgdGhlIGNyZWF0aW9uIG9mIHN1
Y2ggc2VydmVycyBzb3VuZHMgbGlrZSBhICpnb29kKiB0aGluZyB0byBtZS4NCj4+DQo+Pj4gICAg
ICAgLSBIYXZpbmcgYSBzZXJ2ZXIgc2lkZSBjb25maWd1cmF0aW9uIGtub2IgdG8gY29udHJvbCB0
aGUNCj4+PmJlaGF2aW91cg0KPj4+ICAgICAgIChzaW5jZSBpdCB3b3VsZCBhZmZlY3QgdGhlIHNl
bWFudGljcyBmb3IgYWxsIGNsaWVudHMpLg0KPj4gVGhpcyBhbHNvIHNvdW5kcyBsaWtlIHNvbWV0
aGluZyB3aGljaCBpdCB3b3VsZCBiZSBkZXNpcmVhYmxlIHRvIHByZXZlbnQuDQo+Pg0KPj4gSSB0
aGluayBJJ20gc3F1YXJlbHkgd2l0aCBBbmR5IG9uIHRoaXMgb25lLg0KPg0KPlRha2luZyBhIHN0
ZXAgYmFjayAuLi4NCj4NCj5JIGFtIHByb2JhYmx5IHdheSBvZmYgdGhlIG1hcmssIGJ1dCBteSBw
ZXJjZXB0aW9uIGlzIHRoYXQgc29tZSAocGVyaGFwcw0KPm1hbnkpIG9mIHRoZSBmb2xrcyBpbiB0
aGUgV0cgc3RpbGwgcGVyY2VpdmUgdGhhdCB0aGUgb3BzdGF0ZQ0KPnJlcXVpcmVtZW50cyBhcmUg
bmljaGUgcmVxdWlyZW1lbnRzIGZvciBzb21lIHVudXN1YWwgc2NlbmFyaW9zLCBhbmQgdGhhdA0K
PmV2ZXJ5b25lIGVsc2UgaXMgaGFwcHkgd2l0aCB0aGUgc3RhdHVzIHF1byBhbmQgZG9uJ3Qgd2Fu
dC9uZWVkIHRoZW0uDQo+DQo+QWxhcywgSSBkb24ndCBzaGFyZSB0aGF0IHZpZXcuICBGb3IgbWUs
IHRoZSBvcHN0YXRlIHJlcXVpcmVtZW50cyBjYW4gYmUNCj5zdW1tYXJpemVkIGFzIHNheWluZyB0
aGF0IHRoZSBvcGVyYXRvcnMganVzdCB3YW50IHRvIGtub3cgd2hhdA0KPmNvbmZpZ3VyYXRpb24g
dGhlIGRldmljZSBpcyBhY3R1YWxseSBydW5uaW5nIGluIGEgZm9ybWF0IHRoYXQgaXMNCj5jb252
ZW5pZW50IGZvciB0aGVtIHRvIHVzZS4gIFRoaXMgcmVhbGx5IGRvZXNuJ3QgYXBwZWFyIHRvIGJl
DQo+dW5yZWFzb25hYmxlIHJlcXVlc3QgdG8gbWUsIGFuZCBpZiBJIHdhcyB3cml0aW5nIHRvIGEg
bmV0d29yaw0KPm1hbmFnZWFiaWxpdHkgQVBJIHRoZW4gSSB3b3VsZCBjaG9vc2UgdG8gdXNlIG9w
c3RhdGUgYmVjYXVzZSBJIHBlcmNlaXZlDQo+dGhhdCBpdCBpcyBhIG1vcmUgcm9idXN0IGFuZCBl
YXNpZXIgdG8gdXNlIEFQSS4gIFRoZSBjb3VudGVyIGFyZ3VtZW50cw0KPmFwcGVhciB0byBiZSB0
aGF0IGl0IGlzIHRvbyBoYXJkIGZvciBkZXZpY2VzIHRvIHByb3ZpZGUgdGhpcw0KPmluZm9ybWF0
aW9uLCBhbmQgdGhhdCB0aGUgb3BlcmF0b3JzIGhhdmUgaGlzdG9yaWNhbGx5IG1hbmFnZWQgd2l0
aG91dCBpdC4NCj4NCj5Ib3dldmVyLCBJIHRoaW5rIHRoYXQgc2V2ZXJhbCB0aGluZ3MgaGF2ZSBj
aGFuZ2VkLCBhbmQgaGVuY2UgbmVnYXRlDQo+dGhlc2UgY291bnRlciBhcmd1bWVudHM6IChpKSB0
aGUgb3BlcmF0b3JzIHdhbnQgdG8gaGF2ZSBtdWNoIG1vcmUNCj5hdXRvbWF0aW9uIGFuZCBtYW5h
Z2VtZW50IG92ZXIgdGhlaXIgZGV2aWNlcywgKGlpKSB0aGV5IGhhdmUgZm91bmQgYSB3YXkNCj50
byBncm91cCB0b2dldGhlciBhbmQgaGF2ZSBhIG1vcmUgdm9jYWwgdm9pY2UgYWJvdXQgd2hhdCB0
aGV5IG5lZWQgYW5kDQo+d2FudCwgKGlpaSkgdGhlIG9wZXJhdG9ycyBoYXZlIHJlYWxpemVkIHRo
YXQgdGhleSBkb24ndCBuZWVkIHRvIHdhaXQgZm9yDQo+dGhlIFNET3MgYW5kIGNhbiBjcmVhdGUg
ZGVmYWN0byBzdGFuZGFyZCBtb2RlbHMgb24gdGhlaXIgb3duIGlmIHRoZXkNCj5oYXZlIHRvLg0K
Pg0KPlBlcnNvbmFsbHksIEkgd291bGQgbGlrZSB1cyB0byBzdG9wIHNwZW5kaW5nIHRpbWUgY2h1
cm5pbmcgb24gdGhlDQo+cmVxdWlyZW1lbnRzIGFuZCBhY3R1YWxseSBnZXQgb24gdG8gZGlzY3Vz
c2luZyB0aGUgc29sdXRpb25zLiAgVG8gYmUNCj5ob25lc3QsIHRoZXJlIGhhcyBiZWVuIHJlbGF0
aXZlbHkgbGl0dGxlIGNoYW5nZSBpbiBteSB1bmRlcnN0YW5kaW5nIG9mDQo+dGhlIHJlcXVpcmVt
ZW50cyBmcm9tIHJlYWRpbmcgZHJhZnQtb3BlbmNvbmZpZy1uZXRtb2Qtb3BzdGF0ZS0wMSBiYWNr
IGluDQo+SnVseSwgYW5kIEkgd2FzIGV4cGVjdGluZyB0byBkaXNjdXNzIHRoZSBzb2x1dGlvbiBk
cmFmdHMgYmFjayBpbg0KPlNlcHRlbWJlci4gIEhlcmUgd2UgYXJlIGluIERlY2VtYmVyLCBhbmQg
SSdtIG5vdCBjb252aW5jZWQgdGhhdCB3ZSBoYXZlDQo+dHJ1bHkgbWFkZSBzaWduaWZpY2FudCBw
cm9ncmVzcy4NCj4NCj5UaGUgb25seSByZWFzb24gdGhhdCBJIHN1Ym1pdHRlZCBhIHNvbHV0aW9u
IGRyYWZ0IHRvIHRoaXMgcHJvYmxlbSB3YXMNCj5iZWNhdXNlIEkgdGhvdWdodCBpdCB1bmxpa2Vs
eSB0aGF0IE9wZW5Db25maWcgd291bGQgc3VwcG9ydCBhIG11bHRpcGxlDQo+ZGF0YXN0b3JlIHNv
bHV0aW9uLCBhbmQgSSBjb3VsZCBzZWUgc3Ryb25nIHJlc2lzdGFuY2UgYW1vbmdzdCB0aGUgSUVU
Rg0KPmVuZ2luZWVycyB0byB0aGUgcHJvcG9zZWQgT3BlbkNvbmZpZyBzb2x1dGlvbi4gIEkgd2Fz
IGhvcGluZyB0aGF0IG15DQo+cHJvcG9zZWQgc29sdXRpb24gbWlnaHQgYmUgc2VlbiBmb3IgdGhl
IGNvbXByb21pc2UgdGhhdCBpdCBpcyBiZXR3ZWVuDQo+dGhlIHR3byBvcHBvc2luZyBwb3NpdGlv
bnMuICBCdXQgSSBjYXJlIGxlc3Mgb24gd2hhdCB0aGUgc29sdXRpb24gaXMsDQo+YW5kIG1vcmUg
d2hldGhlciB3ZSBjYW4gYWdyZWUgb24gb25lIGFuZCBtb3ZlIGZvcndhcmQuDQo+DQo+QXMgc29t
ZW9uZSB0aGF0IGlzIHF1aXRlIG5ldyB0byBTRE8gcHJvY2Vzc2VzLCBteSBtYWluIGNvbmNlcm4g
aXMgdGhhdA0KPklFVEYgKGFuZCBvdGhlciBzdGFuZGFyZHMgYm9kaWVzKSBhcmUgbW92aW5nIHRv
byBzbG93bHkgaGVyZSwgYW5kIHRoYXQNCj5ieSB0aGUgdGltZSB0aGF0IElFVEYgaGF2ZSBwcm9k
dWNlZCBhIHN1ZmZpY2llbnRseSBjb21wbGV0ZSBzZXQgb2YgWUFORw0KPm1vZGVscyB0byBtYW5h
Z2UgbmV0d29yayBkZXZpY2VzIGl0IHdpbGwgYmUgdG9vIGxhdGUgYmVjYXVzZSB0aGUNCj5pbmR1
c3RyeSB3aWxsIGFscmVhZHkgaGF2ZSBjb252ZXJnZWQgb24gdGhlIE9wZW5Db25maWcgbW9kZWxz
LCB3aGljaA0KPmFsdGhvdWdoIG5vdCBwZXJmZWN0LCBhcmUgY2xvc2UgdG8gYmVpbmcgdXNhYmxl
IG5vdywgYW5kIGFyZSBiZWluZw0KPmV2b2x2ZWQgYXQgYSBtdWNoIHF1aWNrZXIgcGFjZSAuLi4N
Cj4NCj5TbyBteSBob3BlIGZvciB0aGUgZWFybHkgbmV3IHllYXIgaXMgdGhhdCB3ZSBjYW4gcmVh
Y2ggY29tbW9uIGdyb3VuZA0KPndpdGggT3BlbkNvbmZpZyBhbmQgY29udmVyZ2Ugb24gYSBzaW5n
bGUgc2V0IG9mIFlBTkcgbW9kdWxlcyBmb3INCj5tYW5hZ2luZyBuZXR3b3JrIGRldmljZXMsIGFu
ZCB0aGF0IGluY2x1ZGVzIGhhdmluZyBhIHNvbHV0aW9uIHRvIHRoZQ0KPk9wc3RhdGUgcHJvYmxl
bS4NCj4NCj5GaW5hbGx5LCBpZiBteSBhY3F1aWVzY2luZyB0byBBbmR5J3MgcmVxdWlyZW1lbnQg
aXMgaGVscGZ1bCB0byBtb3ZlIHRoaXMNCj5wcm9jZXNzIGZvcndhcmQgdGhlbiB0aGF0IGlzIGZp
bmUgd2l0aCBtZS4gIEFzIEkgaGF2ZSBwcmV2aW91c2x5DQo+aW5kaWNhdGVkLCBJIGRvbid0IHJl
YWxseSB0aGluayB0aGF0IGl0IGhlbHBzIHdpdGggZnJhbWluZyBvciBkaXNjdXNzaW5nDQo+dGhl
IHNvbHV0aW9ucywgYnV0IGVxdWFsbHkgSSBjYW4gbGl2ZSB3aXRoIGl0IHNpbmNlIEkgc3VzcGVj
dCB0aGF0IHRoZQ0KPnNvbHV0aW9ucyBhcmUgbGlrZWx5IHRvIGNvbXBseSB3aXRoIGl0IGFueXdh
eS4NCj4NCj5BcG9sb2dpZXMgZm9yIHRoZSBsb25nIGVtYWlsLCBhbmQgZ2l2ZW4gSSBtYXkgbm90
IGJlIGFjdGl2ZWx5IHJlYWRpbmcNCj50aGUgV0cgZW1haWxzIG92ZXIgdGhlIG5leHQgY291cGxl
IG9mIHdlZWtzLCBJJ2xsIHdpc2ggeW91IGFsbCBoYXBweQ0KPmhvbGlkYXlzIQ0KPg0KPlRoYW5r
cywNCj5Sb2INCj4NCj4+DQo+PiBSYW5keQ0KPj4NCj4+IF9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+PiBuZXRt
b2RAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0
bW9kDQo+PiAuDQo+Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+bmV0bW9kIG1haWxpbmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg==


From nobody Fri Dec 18 07:27:30 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04B61B2ED3 for ; Fri, 18 Dec 2015 07:27:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 O5s75f5cIABV for ; Fri, 18 Dec 2015 07:27:27 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E38741B369B for ; Fri, 18 Dec 2015 07:27:26 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B29AA14A6; Fri, 18 Dec 2015 16:27:25 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 2taStBnyNcDv; Fri, 18 Dec 2015 16:27:24 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 18 Dec 2015 16:27:24 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0D8DD20056; Fri, 18 Dec 2015 16:27:24 +0100 (CET)
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 2Udj_mdWFQgk; Fri, 18 Dec 2015 16:27:22 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 660A720055; Fri, 18 Dec 2015 16:27:22 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id C1DD8394252E; Fri, 18 Dec 2015 16:27:19 +0100 (CET)
Date: Fri, 18 Dec 2015 16:27:19 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20151218152719.GA71195@elstar.local>
Mail-Followup-To: Ladislav Lhotka , "netmod@ietf.org" 
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com>  <110786DF-5106-4281-9870-E435A4754888@nic.cz> <20151218144948.GB71024@elstar.local> <85BE92FD-33DE-4BE1-AF9E-E4E5FAF330A2@nic.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <85BE92FD-33DE-4BE1-AF9E-E4E5FAF330A2@nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 15:27:28 -0000

On Fri, Dec 18, 2015 at 04:16:04PM +0100, Ladislav Lhotka wrote:
> 
> > On 18 Dec 2015, at 15:49, Juergen Schoenwaelder  wrote:
> > 
> > On Fri, Dec 18, 2015 at 03:22:48PM +0100, Ladislav Lhotka wrote:
> >> 
> >> Is it not? I would say it severely restricts the workflow for the data model development. The ultra-conservative update rules essentially permit only incremental changes to published modules. This would be fine if the data model landscape already was reasonably stable. We are not that far though, and everything is in flux. So I believe we would be much better off with "release early - release often" strategy, which is made impossible by the existing update rules.
> >> 
> > 
> > There is a "release early - release often cycle" in the IETF process -
> > it is called the Internet Drafts stage. Unfortunately, often people
> > wait for things to stabilize (becoming an RFC) before implementing. I
> 
> There are other disadvantages to I-Ds, for example that they have to be updated every six months. It is actually funny: RFC used to mean "request for comments", then later I-D acquired this role, so now we probably need a "drafty draft" category.
> 
> > assume we would have fewer but more solid data models if they would
> > all come along with running code behind them (and ideally > 1
> > independent implementations). The problem might be "us" and not the
> > update rules.
> 
> The update rules mean that it is risky to publish a data model in an RFC. And indeed, if there is a need, for one reason or another, to restructure, for example, ietf-interfaces, it will have to become a new module (ietf-interfaces-dash?) and the revision history will be broken. Doing this more than once would turn the data model ecosystem into a mess.

No, it does not.
 
> Backward compatibility is nice, but making it an absolute requirement, which is even ingrained in the data modelling language specification, is IMO absurd.
>

I can grab interface statistics from pretty much all devices on my
network using a single data model and SNMP. This is a feature, not a
bug. You may find this not worth the effort or you might even find
this absurd in todays world. I do not have to share this view.

Can we stop here and get back to the I-D discussed in this thread? If
you want to complain about absurd YANG update rules, please do so
using a separate thread.

/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 Dec 18 07:49:17 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3DCE1B36A5 for ; Fri, 18 Dec 2015 07:49:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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 mD09lfEr3Ddm for ; Fri, 18 Dec 2015 07:49:14 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A0921B2E5E for ; Fri, 18 Dec 2015 07:49:14 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:95f1:e5af:5d06:4c6f] (unknown [IPv6:2001:718:1a02:1:95f1:e5af:5d06:4c6f]) by mail.nic.cz (Postfix) with ESMTPSA id 217E11816EF for ; Fri, 18 Dec 2015 16:49:13 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450453753; bh=SmEH4hiT2FcEBX29V3ziletafDpGmw5Ftliwk6VAyUI=; h=From:Date:To; b=PyE6tf8TvqAoHslSnlgSV9m06lgRbRQJh3/icUWH5e6TWoBMWc4W6lKKKV6Hufzr6 otJtnvitB36lGnsDSS3E3hu/xEvV9LVjlcnAGUprmYqB5ZO05OYQHWNKOXErJYyj/C xwuDjxfwHixVo2rIpFFl21/KbLpPJbQE2/SDldgY=
From: Ladislav Lhotka 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E169FEA-ABF9-4B3F-BB86-A3D3B900741A@nic.cz>
Date: Fri, 18 Dec 2015 16:49:16 +0100
To: NETMOD WG 
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 15:49:15 -0000

Hi,

if we want people to take YANG modules appearing in I-Ds seriously and =
implement them, then we should apply the revisioning rules to them. That =
is, if a module changes between two I-D revisions, then its =
revision-date has to be bumped and a new entry added to the revision =
history. As it is now, the I-D-based modules are esentially =
revisionless.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Fri Dec 18 08:06:05 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66F71B36CA for ; Fri, 18 Dec 2015 08:06:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 A_ZOgDYRS0cW for ; Fri, 18 Dec 2015 08:06:02 -0800 (PST)
Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 3FB3F1B36C4 for ; Fri, 18 Dec 2015 08:06:02 -0800 (PST)
Received: by mail-lf0-x231.google.com with SMTP id l133so75213253lfd.2 for ; Fri, 18 Dec 2015 08:06:02 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=4gUST+A7YtE5JgsfM7CSJNP8sg9haUwi1vCxedHAmbA=; b=K/FDk2MeV1D5dbp3FHKkCMlKyGtkqNu0UQETimjWzzKHlogPAkQC6a/J6J9gjGNASg Enygf8j7++95vgXav7HQvy2Pz/iKB3nex9ZNaWBwE5d9lwT8ypEm93hSk6qv78KLP5gT lTVJXiP6ppPaTHDC/fT/rM5ZBnzW7fh9EDcep2lmYu/MXK9lA34vmj8ngnBFKAmv02Ce YtuSdy5iPf7wvbwsHXgmT7BhI2nzoZwxKXM7Qnn6U+pe71hb216AFLdvrkZUZ2qZcP+H PnG0Fu8RX6sGC4i9xv2QuVFD7Oi/acLsT9n4jhsB3KzJSPPylgHzw+940oJYGKYadAae wB2Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4gUST+A7YtE5JgsfM7CSJNP8sg9haUwi1vCxedHAmbA=; b=XfJidHhKfxh9rqM9QsYxlYnUHXdQzaQXeRO/Te2mVOBNCJT+tp4EXbGQg8zFPr5SDH jQBtCoy3Kr325p6yn+6jfK265W51eW3s67pSXEEFyvtepWCINhZVHWGUZcXNH2XcOXvd xr/Ron1+e85/rWnHpcG7hibnJn6/qsxPV+NisLo7xYM3DVYlWLkV0TyTBF8GgCXW3gfb osjLfqcqwrtQpi2zpwsiWL2505O+jMt96kgBYKlfTj4G1xRxdTAr21jUMHV2ff4umVQH yu+rIy0KeZzDs/rcyUcXDGScO2E1rE5Z7UJIyvFLmePlsHfqMGUxwnJ/7T4/xg7mc9aw xsSw==
X-Gm-Message-State: ALoCoQnCAavbKSkDc1msPG8jxPuEsl/wXJZZgC/Sdl8gb/NlJJhGbs8ms4YPtzA4bl60LvaXajP9trrw/DmzjBRuXPZcmW2+6g==
MIME-Version: 1.0
X-Received: by 10.25.155.136 with SMTP id d130mr1837003lfe.54.1450454760402; Fri, 18 Dec 2015 08:06:00 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Fri, 18 Dec 2015 08:06:00 -0800 (PST)
In-Reply-To: <7E169FEA-ABF9-4B3F-BB86-A3D3B900741A@nic.cz>
References: <7E169FEA-ABF9-4B3F-BB86-A3D3B900741A@nic.cz>
Date: Fri, 18 Dec 2015 08:06:00 -0800
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a1140223ec1d7fb05272e5050
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 16:06:04 -0000

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

On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka  wrote:

> Hi,
>
> if we want people to take YANG modules appearing in I-Ds seriously and
> implement them, then we should apply the revisioning rules to them. That
> is, if a module changes between two I-D revisions, then its revision-date
> has to be bumped and a new entry added to the revision history. As it is
> now, the I-D-based modules are esentially revisionless.
>
>

The revision rules only apply to published modules.
In IETF-speak, that means an RFC.  An Internet Draft
is a work-in-progress.  We update the revision date every time
the module changes, but the numerous incremental changes
for a work-in-progress should not be recorded in the module
revision history.  They should be recorded in the Change Log appendix.

I will try to make this procedure more clear in the YANG guidelines draft.




> Lada
>
>
Andy



> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka <=
lhotka@nic.cz> wrote:
Hi,



if we want people to take YANG modules appearing in I-Ds seriously and impl=
ement them, then we should apply the revisioning rules to them. That is, if=
 a module changes between two I-D revisions, then its revision-date has to =
be bumped and a new entry added to the revision history. As it is now, the =
I-D-based modules are esentially revisionless.




The revision rules only=
 apply to published modules.
In IETF-speak, that means an RFC.=C2=
=A0 An Internet Draft
is a work-in-progress.=C2=A0 We update the =
revision date every time
the module changes, but the numerous inc=
remental changes
for a work-in-progress should not be recorded in=
 the module
revision history.=C2=A0 They should be recorded in th=
e Change Log appendix.

I will try to make this pro=
cedure more clear in the YANG guidelines draft.

=C2=A0

Lada



Andy

=C2=A0

--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C









_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a1140223ec1d7fb05272e5050--


From nobody Fri Dec 18 08:32:12 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF311B3704 for ; Fri, 18 Dec 2015 08:32:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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 b0ld4W8yIbYt for ; Fri, 18 Dec 2015 08:32:09 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05EDE1B2F0D for ; Fri, 18 Dec 2015 08:32:08 -0800 (PST)
Received: from [IPv6:2a01:5e0:29:ffff:fdbc:77bd:a0f9:7f76] (unknown [IPv6:2a01:5e0:29:ffff:fdbc:77bd:a0f9:7f76]) by mail.nic.cz (Postfix) with ESMTPSA id 5CC0F180A16; Fri, 18 Dec 2015 17:32:07 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450456327; bh=wYTIOvpMYLqfpD+a1nINct9tHsoqZnzmxhXxpNNyfPE=; h=From:Date:To; b=W5JfGgxN52kI9E+26ziATF7kssj7D5Az7BoolPScjQ8blEmYiaoOHE7sXVZOwXKLt 6MMql561VStoQ9qZyHjBpk+cLic/6FXYsA0tCP4NeIUT5rihL5JY2ghnAg4r3yk1Iv AWJsTHUQnUDur61Wf1D1xRU2g4/DtIpOO1BzPXAI=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Fri, 18 Dec 2015 17:32:11 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F9B1A29-A8FE-4EEC-B850-8AD98940DA65@nic.cz>
References: <7E169FEA-ABF9-4B3F-BB86-A3D3B900741A@nic.cz> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 16:32:11 -0000

> On 18 Dec 2015, at 17:06, Andy Bierman  wrote:
>=20
>=20
>=20
> On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka  =
wrote:
> Hi,
>=20
> if we want people to take YANG modules appearing in I-Ds seriously and =
implement them, then we should apply the revisioning rules to them. That =
is, if a module changes between two I-D revisions, then its =
revision-date has to be bumped and a new entry added to the revision =
history. As it is now, the I-D-based modules are esentially =
revisionless.
>=20
>=20
>=20
> The revision rules only apply to published modules.

Update rules of sec. 10 offer no such excuse.

> In IETF-speak, that means an RFC.  An Internet Draft
> is a work-in-progress.  We update the revision date every time
> the module changes, but the numerous incremental changes
> for a work-in-progress should not be recorded in the module
> revision history.  They should be recorded in the Change Log appendix.

Revision numbers are critical for interoperability. If we want vendors =
to implement modules such as ietf-routing now, the revisions must be =
solid and reliable.

>=20
> I will try to make this procedure more clear in the YANG guidelines =
draft.

I think it should be the other way around: YANG spec should not contain =
the update rules (because we all ignore them for I-D-based modules, =
right?), but the IETF guidelines should specify the policy you describe.

Lada

>=20
>=20
> =20
> Lada
>=20
>=20
> Andy
>=20
> =20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Fri Dec 18 08:47:57 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7ED1B372D for ; Fri, 18 Dec 2015 08:47:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 vlbi538obABF for ; Fri, 18 Dec 2015 08:47:50 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id DC71B1B372A for ; Fri, 18 Dec 2015 08:47:48 -0800 (PST)
Received: from stubbs.local.chopps.org (75-128-113-61.dhcp.aldl.mi.charter.com [75.128.113.61]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 44D2860A89; Fri, 18 Dec 2015 16:47:48 +0000 (UTC)
References: <7E169FEA-ABF9-4B3F-BB86-A3D3B900741A@nic.cz>
User-agent: mu4e 0.9.15; emacs 24.5.1
From: Christian Hopps 
To: Ladislav Lhotka 
In-reply-to: <7E169FEA-ABF9-4B3F-BB86-A3D3B900741A@nic.cz>
Date: Fri, 18 Dec 2015 11:47:47 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 16:47:54 -0000

--=-=-=
Content-Type: text/plain



Versioning has come up in previous conversations I've been a part of,
and I was led to believe that it does not really exist for yang
modules. That is, if you update a published module it's a completely new
model with no-expectation of compatibility with previous models.

Is it the case that there's no way to "bump the minor version" of a
model (i.e., you make only additions, but no deletions or changes to
meaning so that the model can be considered backward compatible)?

Thanks,
Chris.


Ladislav Lhotka  writes:

> Hi,
>
> if we want people to take YANG modules appearing in I-Ds seriously and implement them, then we should apply the revisioning rules to them. That is, if a module changes between two I-D revisions, then its revision-date has to be bumped and a new entry added to the revision history. As it is now, the I-D-based modules are esentially revisionless.
>
> Lada


--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWdDizAAoJEC4dgw7XuDAlmPoP/jopZ58OEstH4ir/n8UAOiFz
I2gHBdhf5I9L2bymzmLAZXDmGtRjF/vXVdp8fAWInqBfNnOwSuCkloHutrjU0pH/
PxghNL96/R86KD3t1YxohqUKgzkzMXK99US1gZWvCoYNZvyO9KIIQMQfBBIKQ3mC
7sfzrm1CHF6VUbjNrljfZqvRgF/TinpnZWYGBW6Ap3vJKjSp8DeGjfhqePZ1dq8V
dwKUjhjSlhrAIq8o7H79nb+R+BiSR3yHtbv/LABdOMDdS58DfzP8ijITAv1nCF2u
tEYjlltQZRgcY3HHQIpv2rBILqcsRmeR4vqfX3RIU2Uzm2AfFHx7Gkin+Lydv2l6
ONZZe4PuPH86dd5mWMfoE/yLkYJiJpWIzBndzbUZL6zYDRUp1J4kW24ESSrIMSlj
dVCyB3vHfUYhnVd9DA+SltDzQTNRZTLOdy8RbjlmX2LdOSlkjIoKq/cmOUW+4uwz
mVtcXpgcDySfXFXOdVmB9/cIZgr0qfLRbr4F1VUxlgOcmM5U7/ZzC3BEw1OZEIAc
seDFl3J3xK3aF/cSWxcKJEOa4pCpdEaODEPod1EuRTS2zMCGWtefmwHHB+dA9/8m
K21tVsQp0eljy+8i4gkBebYguRHBN6KDxNmoKW5pGdZirsliSG0/DjalbMEWSmZc
1Tjcp90GaUyAwKt0fzGq
=rrEz
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Fri Dec 18 09:00:54 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7641B374F for ; Fri, 18 Dec 2015 09:00:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 nyXkwRviKC4k for ; Fri, 18 Dec 2015 09:00:51 -0800 (PST)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::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 C2AFA1B3751 for ; Fri, 18 Dec 2015 09:00:50 -0800 (PST)
Received: by mail-lb0-x22b.google.com with SMTP id u9so66525460lbp.2 for ; Fri, 18 Dec 2015 09:00:50 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=XXRuAkczK1zO1GGdcX16uq3vvTUpEscrk34IBgvbGgM=; b=edhIIJYpwT3dNk0Qp8AO+1vn+P1xDf05bpTdpg+UpCvzLjAsFH1s1oxUHVgrXil333 9B8XwidkIXuWAPr7XMqNFZ3cK1BAh13yiji0QMXqoj7qv0lRdgi81ibFsxwal5LsIUTI Ou/i4h2lxvstAkGQ1uUiA+isuOaBEuL2zV61ol3pk9g6RD8yKyIpWKMGkmO5nFWBd022 EUeMvLt6VuyDuiiqDmAvmqq535OAkZCPS0Tf/kafQTx1qd80e68KUYk9osz8rCcbXibQ 04WaWARts6QPsrzj4GaDd7dtdAOUSHyRAVSS0ZjSgZwQshuHayP05RLuyyom2HlJThzK qKWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XXRuAkczK1zO1GGdcX16uq3vvTUpEscrk34IBgvbGgM=; b=FlHrJm4hstoCI67o9bZe0vLi0++eYQ7irCHb/g8jvEV1ZxX0lVK/todNPUz5Wc6isO WRKkWswzYqE0xBm+hrZ/GyNeRJC+AwrrP294Q+NoDcjnDOmLckhkR3+EesDSBcDiEqaT 35l0MBb8C6uG09cj4RWx+5CT3F8YNP8PxSCrQrh1TD8Lj6ubrIrcpIAErf1nVc8zYYzD BGqZrBdrcNtxdLGBwNZ46bHS3zyJvEPnDmhQrMR/5QpIXvWIt44RXvge2OwO8woNxQJv P9jmpljN1N01N3cpchHKC6cMGpMr6Sa0uYngFoc7JPe8tS9Iwo6tGKA+NjNCmtvwevOD SGZQ==
X-Gm-Message-State: ALoCoQkf3v7uIzmMAGMqULF8cjtlLTANaELqVuhqJk6snsnLreelZcbCgNX57rc6cYJ/nNUKU56h/Hb2z2ZdqDp2wjffBmN6cA==
MIME-Version: 1.0
X-Received: by 10.112.202.101 with SMTP id kh5mr1872216lbc.66.1450458048864; Fri, 18 Dec 2015 09:00:48 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Fri, 18 Dec 2015 09:00:48 -0800 (PST)
In-Reply-To: <5F9B1A29-A8FE-4EEC-B850-8AD98940DA65@nic.cz>
References: <7E169FEA-ABF9-4B3F-BB86-A3D3B900741A@nic.cz>  <5F9B1A29-A8FE-4EEC-B850-8AD98940DA65@nic.cz>
Date: Fri, 18 Dec 2015 09:00:48 -0800
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a11c3724cc3bf8c05272f1475
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 17:00:53 -0000

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

On Fri, Dec 18, 2015 at 8:32 AM, Ladislav Lhotka  wrote:

>
> > On 18 Dec 2015, at 17:06, Andy Bierman  wrote:
> >
> >
> >
> > On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka  wrote:
> > Hi,
> >
> > if we want people to take YANG modules appearing in I-Ds seriously and
> implement them, then we should apply the revisioning rules to them. That
> is, if a module changes between two I-D revisions, then its revision-date
> has to be bumped and a new entry added to the revision history. As it is
> now, the I-D-based modules are esentially revisionless.
> >
> >
> >
> > The revision rules only apply to published modules.
>
> Update rules of sec. 10 offer no such excuse.
>


That is a flaw in the draft



>
> > In IETF-speak, that means an RFC.  An Internet Draft
> > is a work-in-progress.  We update the revision date every time
> > the module changes, but the numerous incremental changes
> > for a work-in-progress should not be recorded in the module
> > revision history.  They should be recorded in the Change Log appendix.
>
> Revision numbers are critical for interoperability. If we want vendors to
> implement modules such as ietf-routing now, the revisions must be solid and
> reliable.
>


Vendors implement work-in-progress at their own risk.
IMO we should do a better job publishing RFCs on time,
and implement RFCs.



>
> >
> > I will try to make this procedure more clear in the YANG guidelines
> draft.
>
> I think it should be the other way around: YANG spec should not contain
> the update rules (because we all ignore them for I-D-based modules,
> right?), but the IETF guidelines should specify the policy you describe.
>
>
This is a closed issue in YANG 1.1



> Lada
>
>

Andy



> >
> >
> >
> > Lada
> >
> >
> > Andy
> >
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

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




On Fri, Dec 18, 2015 at 8:32 AM, Ladislav Lhotka <=
lhotka@nic.cz> wrote:


> On 18 Dec 2015, at 17:06, Andy Bierman <andy@yumaworks.com> wrote:

>

>

>

> On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> Hi,

>

> if we want people to take YANG modules appearing in I-Ds seriously and=
 implement them, then we should apply the revisioning rules to them. That i=
s, if a module changes between two I-D revisions, then its revision-date ha=
s to be bumped and a new entry added to the revision history. As it is now,=
 the I-D-based modules are esentially revisionless.

>

>

>

> The revision rules only apply to published modules.



Update rules of sec. 10 offer no such excuse.


That is a flaw in the draft

=
=C2=A0



> In IETF-speak, that means an RFC.=C2=A0 An Internet Draft

> is a work-in-progress.=C2=A0 We update the revision date every time
> the module changes, but the numerous incremental changes

> for a work-in-progress should not be recorded in the module

> revision history.=C2=A0 They should be recorded in the Change Log appe=
ndix.



Revision numbers are critical for interoperability. If we want vendors to i=
mplement modules such as ietf-routing now, the revisions must be solid and =
reliable.


Vendors implem=
ent work-in-progress at their own risk.
IMO we should do a better=
 job publishing RFCs on time,
and implement RFCs.

<=
/div>
=C2=A0



>

> I will try to make this procedure more clear in the YANG guidelines dr=
aft.



I think it should be the other way around: YANG spec should not contain the=
 update rules (because we all ignore them for I-D-based modules, right?), b=
ut the IETF guidelines should specify the policy you describe.



This is a closed issue in YANG 1.1

=C2=A0

Lada




Andy

=C2=A0

>

>

>

> Lada

>

>

> Andy

>

>

> --

> Ladislav Lhotka, CZ.NIC Labs

> PGP Key ID: E74E8C0C

>

>

>

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

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



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C













--001a11c3724cc3bf8c05272f1475--


From nobody Fri Dec 18 10:41:22 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 016C01B3808 for ; Fri, 18 Dec 2015 10:41:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 dmqMfVteU5rn for ; Fri, 18 Dec 2015 10:41:19 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C5E0B1B37EE for ; Fri, 18 Dec 2015 10:41:18 -0800 (PST)
Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 7F40A1AE0A82; Fri, 18 Dec 2015 19:41:17 +0100 (CET)
Date: Fri, 18 Dec 2015 19:42:38 +0100 (CET)
Message-Id: <20151218.194238.1889765562853846766.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <5F9B1A29-A8FE-4EEC-B850-8AD98940DA65@nic.cz>
References: <7E169FEA-ABF9-4B3F-BB86-A3D3B900741A@nic.cz>  <5F9B1A29-A8FE-4EEC-B850-8AD98940DA65@nic.cz>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 18:41:21 -0000

Ladislav Lhotka  wrote:
> 
> > On 18 Dec 2015, at 17:06, Andy Bierman  wrote:
> > 
> > 
> > 
> > On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka  wrote:
> > Hi,
> > 
> > if we want people to take YANG modules appearing in I-Ds seriously and implement them, then we should apply the revisioning rules to them. That is, if a module changes between two I-D revisions, then its revision-date has to be bumped and a new entry added to the revision history. As it is now, the I-D-based modules are esentially revisionless.
> > 
> > 
> > 
> > The revision rules only apply to published modules.
> 
> Update rules of sec. 10 offer no such excuse.

It says:

  For any published change, ...


I agree w/ Andy that 6087bis could clarify what this means in terms of
IETF.


/martin


> > In IETF-speak, that means an RFC.  An Internet Draft
> > is a work-in-progress.  We update the revision date every time
> > the module changes, but the numerous incremental changes
> > for a work-in-progress should not be recorded in the module
> > revision history.  They should be recorded in the Change Log appendix.
> 
> Revision numbers are critical for interoperability. If we want
> vendors to implement modules such as ietf-routing now, the
> revisions must be solid and reliable.
> 
> > 
> > I will try to make this procedure more clear in the YANG guidelines draft.
> 
> I think it should be the other way around: YANG spec should not
> contain the update rules (because we all ignore them for I-D-based
> modules, right?), but the IETF guidelines should specify the
> policy you describe. 
> 
> Lada
> 
> > 
> > 
> >  
> > Lada
> > 
> > 
> > Andy
> > 
> >  
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> > 
> > 
> > 
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > 
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Fri Dec 18 10:44:08 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5961B37F9 for ; Fri, 18 Dec 2015 10:44:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 xkJ_WSMaB6Xi for ; Fri, 18 Dec 2015 10:44:06 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE101B37F0 for ; Fri, 18 Dec 2015 10:44:06 -0800 (PST)
Received: from localhost (h-91-77.a165.priv.bahnhof.se [212.116.91.77]) by mail.tail-f.com (Postfix) with ESMTPSA id 4EC741AE0A82; Fri, 18 Dec 2015 19:44:05 +0100 (CET)
Date: Fri, 18 Dec 2015 19:45:26 +0100 (CET)
Message-Id: <20151218.194526.1877280801898778625.mbj@tail-f.com>
To: chopps@chopps.org
From: Martin Bjorklund 
In-Reply-To: 
References: <7E169FEA-ABF9-4B3F-BB86-A3D3B900741A@nic.cz> 
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 18:44:07 -0000

Christian Hopps  wrote:
> 
> 
> Versioning has come up in previous conversations I've been a part of,
> and I was led to believe that it does not really exist for yang
> modules. That is, if you update a published module it's a completely new
> model with no-expectation of compatibility with previous models.

Please see section 10 of RFC 6020.

> Is it the case that there's no way to "bump the minor version" of a
> model (i.e., you make only additions, but no deletions or changes to
> meaning so that the model can be considered backward compatible)?

All rules in section 10 of RFC 6020 are backwards compatible.

Also note that you can deprecate and obsolete nodes and define new
nodes in the same module.



/martin


From nobody Fri Dec 18 11:11:50 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84E61B383F for ; Fri, 18 Dec 2015 11:11:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 bfXPhNgea8iv for ; Fri, 18 Dec 2015 11:11:47 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id DE4831B383D for ; Fri, 18 Dec 2015 11:11:46 -0800 (PST)
Received: from stubbs.local.chopps.org (75-128-113-61.dhcp.aldl.mi.charter.com [75.128.113.61]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 212E060A89; Fri, 18 Dec 2015 19:11:46 +0000 (UTC)
References: <7E169FEA-ABF9-4B3F-BB86-A3D3B900741A@nic.cz>  <20151218.194526.1877280801898778625.mbj@tail-f.com>
User-agent: mu4e 0.9.15; emacs 24.5.1
From: Christian Hopps 
To: Martin Bjorklund 
In-reply-to: <20151218.194526.1877280801898778625.mbj@tail-f.com>
Date: Fri, 18 Dec 2015 14:11:45 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 19:11:48 -0000

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


Martin Bjorklund  writes:

> Christian Hopps  wrote:
>>=20
>>=20
>> Versioning has come up in previous conversations I've been a part of,
>> and I was led to believe that it does not really exist for yang
>> modules. That is, if you update a published module it's a completely new
>> model with no-expectation of compatibility with previous models.
>
> Please see section 10 of RFC 6020.

Ok, so I either misunderstood, or was misled. :)

So my reading of section 10 is that a new revision is the "bump the
minor" action, and a new module is required for "bump the major".

Thanks,
Chris.


>
>> Is it the case that there's no way to "bump the minor version" of a
>> model (i.e., you make only additions, but no deletions or changes to
>> meaning so that the model can be considered backward compatible)?
>
> All rules in section 10 of RFC 6020 are backwards compatible.
>
> Also note that you can deprecate and obsolete nodes and define new
> nodes in the same module.
>
>
>
> /martin


--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWdFpxAAoJEC4dgw7XuDAlcjcP/3/XVuAPOKQD85ngsQowwSLi
3PJGQgydSMoNdPPH+4i5bwGVmUF/dNI9HTtbGc9IFlKR7pM48UOq+O1QQNJcn9nk
EokTczWa4aauyg8ddfj1e/vu1R80a7P/+PJlp4KBO9SCAjooozCwIsW0smzAOulJ
9HS/ztWNkvQvGreG7/yM/mi4Dyuau09ofkkRLuwLNvCr3i2RTPbRAbvr4XlesGX2
9KHtwaUvGaOFJXXdkoPrhx3ItRDZacexilvCidB51MImd/DaT/ceBqMKcLp3k56R
r6TjEJj/ocBltMUzt5gPC5qDtSESSaDHa6aVbV9HNJFo6E0b4ELH7QmfvJzEAT41
RrU8vi3AE+4iGpksXc0TdO1xjdfUmlb7mq1pjCOs3Thdz6vE05TKB/1XeELGGGgB
/BsTa2AeBcR8cx4N0e4M+PI1BXxDm0iBEE/CJcI0XzFUiV6GE1/KPGM70jaV+n0L
PmA7CPqFQHQP1GLSrkZdlVJevtIMLqde6q5DxrUenYLFIOhogoo+bb2yJGSbVtZu
xU2b/CgDuhBokr7Pdd2dOnq0mgP7SNVb61uZXlDduoAFc9O3Da9JOd7s99cDfBm7
HIr1EYSpD0SeNDu3JDZY6krw/dcDNjSNLxgdLXTU0GSj7JrJmBY2BKHYic4lqRy7
15PYyLEDwc1JBblfkX/N
=/UqH
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Fri Dec 18 11:13:35 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608E81B383F for ; Fri, 18 Dec 2015 11:13:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 hAypnPxWKLJD for ; Fri, 18 Dec 2015 11:13:32 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 949D31B3845 for ; Fri, 18 Dec 2015 11:13:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450465982; bh=VKVX6iXCpWw3ihQsQjizee58JURRosAgm9Tl4Jk954M=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=S9NRCKRtaSZ2QEp65w07kF0tkFYGDHJyTNR0vjC4utxGyjR6WKyEFp8Nmlck/deED PIdJcIqVIwsbKEaXHXgR5/0wGk2WrTOjh+3RihDPow7l+uMcTX+knQ5pt8LJvD0t96 hX94H1d4kE249JdFvi07x8Qp4cWVAYNuCyscoczU=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Nadeau Thomas 
In-Reply-To: <20151218.194238.1889765562853846766.mbj@tail-f.com>
Date: Fri, 18 Dec 2015 14:13:29 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <20927166-2481-4C36-A088-5B19CA0F3F2C@lucidvision.com>
References: <7E169FEA-ABF9-4B3F-BB86-A3D3B900741A@nic.cz>  <5F9B1A29-A8FE-4EEC-B850-8AD98940DA65@nic.cz> <20151218.194238.1889765562853846766.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=6 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 217, in=2913, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 19:13:34 -0000

	It would help to define this outside of the IETF context.
As we are all well aware, there are many organizations outside
of the IETF such as ODL, OpenConfig, IEEE, MEF, etc=E2=80=A6 that are =
now creating=20
modules.

	=E2=80=94Tom



> On Dec 18, 2015:1:42 PM, at 1:42 PM, Martin Bjorklund  =
wrote:
>=20
> Ladislav Lhotka  wrote:
>>=20
>>> On 18 Dec 2015, at 17:06, Andy Bierman  wrote:
>>>=20
>>>=20
>>>=20
>>> On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka  =
wrote:
>>> Hi,
>>>=20
>>> if we want people to take YANG modules appearing in I-Ds seriously =
and implement them, then we should apply the revisioning rules to them. =
That is, if a module changes between two I-D revisions, then its =
revision-date has to be bumped and a new entry added to the revision =
history. As it is now, the I-D-based modules are esentially =
revisionless.
>>>=20
>>>=20
>>>=20
>>> The revision rules only apply to published modules.
>>=20
>> Update rules of sec. 10 offer no such excuse.
>=20
> It says:
>=20
>  For any published change, ...
>=20
>=20
> I agree w/ Andy that 6087bis could clarify what this means in terms of
> IETF.
>=20
>=20
> /martin
>=20
>=20
>>> In IETF-speak, that means an RFC.  An Internet Draft
>>> is a work-in-progress.  We update the revision date every time
>>> the module changes, but the numerous incremental changes
>>> for a work-in-progress should not be recorded in the module
>>> revision history.  They should be recorded in the Change Log =
appendix.
>>=20
>> Revision numbers are critical for interoperability. If we want
>> vendors to implement modules such as ietf-routing now, the
>> revisions must be solid and reliable.
>>=20
>>>=20
>>> I will try to make this procedure more clear in the YANG guidelines =
draft.
>>=20
>> I think it should be the other way around: YANG spec should not
>> contain the update rules (because we all ignore them for I-D-based
>> modules, right?), but the IETF guidelines should specify the
>> policy you describe.=20
>>=20
>> Lada
>>=20
>>>=20
>>>=20
>>>=20
>>> Lada
>>>=20
>>>=20
>>> Andy
>>>=20
>>>=20
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>=20
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Dec 18 11:23:00 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DBAD1B32BF for ; Fri, 18 Dec 2015 11:22:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 gqdHbMsoUVE0 for ; Fri, 18 Dec 2015 11:22:57 -0800 (PST)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 A08161B3036 for ; Fri, 18 Dec 2015 11:22:56 -0800 (PST)
Received: by mail-lf0-x236.google.com with SMTP id l133so78507614lfd.2 for ; Fri, 18 Dec 2015 11:22:56 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=ke5icSc5tW0bQ53OVlUkWbwSqRyDSKhvnqSKdFAtiB0=; b=bZ5NplkkGyBaDTY6jWc+lTcyLXtp6NXC0AmhHIig16u9BsTRgELMqukPuutn19W91y +7gY3UcmZlpfEW3cTtPs3BV43pgSjgN3jg9H/G0T+puymEYIV7YkZg6dFsxcybnb0YFn 1+BAwlWCJfh71ceXyxIGQolIchCVuENbWAdreserX7gnV9oCHYGcp7wPTvIMu1EJ1nmj qbam9so/AMRP8l3f7G0DBc599DKKCgQZXqa6R4e9wULS2bKG43AWrrugAMmvi24ESVoJ uEq0qWBUZlY47N2qMg/n1tXgw02uMUJzWJuS3/e8JAVNCHcKUq6RPRE1pDm2NQJSyesw 2AVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ke5icSc5tW0bQ53OVlUkWbwSqRyDSKhvnqSKdFAtiB0=; b=UPVgSmHO5U64LbUYEVmhPeyEfuYNbWdMBWEyHWZ4LVF+fE7516vkh4z9ynIiSgpsMW Jqc66p6a/fy8Keun71dLe/DaqHUs5+RPmdEoj93LlKFLNDliffppg51RkP0FKfYgmftn I91akTQ/Vu6zrjfxmIfDbgoe2uqd7CqzPhGaEoT3tvcwVyKPzs/VkcRwHaMOhnji3mz4 7s2qraK9TnqNldomYmv0RuuJOlYejRFl1+0ftnMohFsYFh38sqRZZU3sWtYwh+vkPc4H t4wL4cAzkM5g0tm35zhBDkz5LbgpyAuB9XODWiuAy/a1dJufm9t4dvqC9Kkn/qRz//Pp yZIQ==
X-Gm-Message-State: ALoCoQnalplU52SuqMtgQyYHjKXpEGU38TSyW6nduoJRmpWag1lKGoLWPOCI9yltMFSDCHl0LH6V1WQ4ICu3hw7sAZU3IGXVKA==
MIME-Version: 1.0
X-Received: by 10.25.82.144 with SMTP id g138mr2253334lfb.8.1450466574799; Fri, 18 Dec 2015 11:22:54 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Fri, 18 Dec 2015 11:22:54 -0800 (PST)
In-Reply-To: 
References: <7E169FEA-ABF9-4B3F-BB86-A3D3B900741A@nic.cz>  <20151218.194526.1877280801898778625.mbj@tail-f.com> 
Date: Fri, 18 Dec 2015 11:22:54 -0800
Message-ID: 
From: Andy Bierman 
To: Christian Hopps 
Content-Type: multipart/alternative; boundary=001a1141da8ef3341305273110a9
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 19:22:58 -0000

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

On Fri, Dec 18, 2015 at 11:11 AM, Christian Hopps  wrote:

>
> Martin Bjorklund  writes:
>
> > Christian Hopps  wrote:
> >>
> >>
> >> Versioning has come up in previous conversations I've been a part of,
> >> and I was led to believe that it does not really exist for yang
> >> modules. That is, if you update a published module it's a completely new
> >> model with no-expectation of compatibility with previous models.
> >
> > Please see section 10 of RFC 6020.
>
> Ok, so I either misunderstood, or was misled. :)
>
> So my reading of section 10 is that a new revision is the "bump the
> minor" action, and a new module is required for "bump the major".
>
>

There are no major or minor revision numbers in YANG.
There are on revision date strings YYYY-MM-DD.



> Thanks,
> Chris.
>
>
Andy


>
> >
> >> Is it the case that there's no way to "bump the minor version" of a
> >> model (i.e., you make only additions, but no deletions or changes to
> >> meaning so that the model can be considered backward compatible)?
> >
> > All rules in section 10 of RFC 6020 are backwards compatible.
> >
> > Also note that you can deprecate and obsolete nodes and define new
> > nodes in the same module.
> >
> >
> >
> > /martin
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

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




On Fri, Dec 18, 2015 at 11:11 AM, Christian Hopps <=
;chopps@chopps.org> wrote:


Martin Bjorklund <mbj@tail-f.com&g=
t; writes:



> Christian Hopps <chopps@chopps=
.org> wrote:

>>

>>

>> Versioning has come up in previous conversations I've been a p=
art of,

>> and I was led to believe that it does not really exist for yang
>> modules. That is, if you update a published module it's a comp=
letely new

>> model with no-expectation of compatibility with previous models.
>

> Please see section 10 of RFC 6020.



Ok, so I either misunderstood, or was misled. :)



So my reading of section 10 is that a new revision is the "bump the
minor" action, and a new module is required for "bump the major&q=
uot;.




There are no major or m=
inor revision numbers in YANG.
There are on revision date strings=
 YYYY-MM-DD.

=C2=A0

Thanks,

Chris.



Andy
=C2=A0



>

>> Is it the case that there's no way to "bump the minor ver=
sion" of a

>> model (i.e., you make only additions, but no deletions or changes =
to

>> meaning so that the model can be considered backward compatible)?<=
br>
>

> All rules in section 10 of RFC 6020 are backwards compatible.

>

> Also note that you can deprecate and obsolete nodes and define new

> nodes in the same module.

>

>

>

> /martin




_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a1141da8ef3341305273110a9--


From nobody Fri Dec 18 11:50:10 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0541B388E for ; Fri, 18 Dec 2015 11:50:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 KRRS2m_30QYv for ; Fri, 18 Dec 2015 11:49:57 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 C0DF71B3889 for ; Fri, 18 Dec 2015 11:49:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450468167; bh=PFYzzkyuRf89g7V7MmiIi85ZvAml4sow4V+HI1Lrg1g=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=cLkaG52nNfTocca/e24SKxmBwyM4xgHa8NOtB4FVPBb3dJY6gSb6VpgjHJQ+J7Ssp ypPOtFIZdzSKIsb8nkw10mThjBAQ05fICIOj70PnbEThUOBDqHX/tH5nNrCt7NvqWU FrPxWDWnbp6IOBY1Kg/QO2q3SvKH6M9adbosUX0g=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: multipart/alternative; boundary="Apple-Mail=_AB3E9973-51C4-401F-99B2-DFFC5E090CDF"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Nadeau Thomas 
In-Reply-To: 
Date: Fri, 18 Dec 2015 14:49:43 -0500
Message-Id: <91DB4E3A-AD71-409D-8B72-7327D5573D58@lucidvision.com>
References: <7E169FEA-ABF9-4B3F-BB86-A3D3B900741A@nic.cz> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=7 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 217, in=2914, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 19:50:00 -0000

--Apple-Mail=_AB3E9973-51C4-401F-99B2-DFFC5E090CDF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Dec 18, 2015:11:06 AM, at 11:06 AM, Andy Bierman =
 wrote:
>=20
>=20
>=20
> On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka > wrote:
> Hi,
>=20
> if we want people to take YANG modules appearing in I-Ds seriously and =
implement them, then we should apply the revisioning rules to them. That =
is, if a module changes between two I-D revisions, then its =
revision-date has to be bumped and a new entry added to the revision =
history. As it is now, the I-D-based modules are esentially =
revisionless.
>=20
>=20
>=20
> The revision rules only apply to published modules.
> In IETF-speak, that means an RFC.  An Internet Draft
> is a work-in-progress.  We update the revision date every time
> the module changes, but the numerous incremental changes
> for a work-in-progress should not be recorded in the module
> revision history.  They should be recorded in the Change Log appendix.
>=20
> I will try to make this procedure more clear in the YANG guidelines =
draft.

	The question is one of =E2=80=9Cpublished=E2=80=9D.  So at the =
IETF that means an RFC
today, but Lada makes a good point in that in our new rapid development
environment we may never get to RFCs for most of the models being worked
on today - or not for some time. If we want those I-Ds to be used in
production, it might make sense to define an I-D as =E2=80=9Cpublished=E2=80=
=9D.

	As I pointed out earlier, for other organizations, they have =
different
definitions of =E2=80=9Cpublished=E2=80=9D, so we should consider a more =
flexible definition of
=E2=80=9Cpublished=E2=80=9D to encompass those.  Its probably not a big =
deal to just say
something like, =E2=80=9Cother organizations that define models will =
define their
own definition of stable/published, and in those cases, that will=20
suffice as the threshold for a version and following the updating
rules described herein."

	=E2=80=94Tom


>=20
>=20
> =20
> Lada
>=20
>=20
> Andy
>=20
> =20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod =

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


--Apple-Mail=_AB3E9973-51C4-401F-99B2-DFFC5E090CDF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Dec 18, 2015:11:06 AM, at 11:06 AM, Andy Bierman <andy@yumaworks.com> =
wrote:



On Fri, Dec 18, 2015 at 7:49 AM, =
Ladislav Lhotka <lhotka@nic.cz> wrote:
Hi,



if we want people to take YANG modules appearing in I-Ds seriously and =
implement them, then we should apply the revisioning rules to them. That =
is, if a module changes between two I-D revisions, then its =
revision-date has to be bumped and a new entry added to the revision =
history. As it is now, the I-D-based modules are esentially =
revisionless.




The revision rules only =
apply to published modules.
In IETF-speak, that =
means an RFC.  An Internet Draft
is a =
work-in-progress.  We update the revision date every time
the module changes, but the numerous incremental =
changes
for a work-in-progress should not be =
recorded in the module
revision history.  They =
should be recorded in the Change Log appendix.

I will try to make this procedure more =
clear in the YANG guidelines =
draft.

	The question is one of =
=E2=80=9Cpublished=E2=80=9D.  So at the IETF that means an =
RFC
today, but Lada makes a good point in that in our new =
rapid development
environment we may never get to RFCs for =
most of the models being worked
on today - or not for some =
time. If we want those I-Ds to be used in
production, it might =
make sense to define an I-D as =E2=80=9Cpublished=E2=80=9D.

	As I pointed out earlier, for =
other organizations, they have different
definitions of =
=E2=80=9Cpublished=E2=80=9D, so we should consider a more flexible =
definition of
=E2=80=9Cpublished=E2=80=9D to encompass those. =
 Its probably not a big deal to just say
something like, =
=E2=80=9Cother organizations that define models will define =
their
own definition of stable/published, and in those cases, =
that will 
suffice as the threshold for a version and =
following the updating
rules described herein."

	=E2=80=94Tom




 

Lada



Andy

 

--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C









_______________________________________________

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

=

--Apple-Mail=_AB3E9973-51C4-401F-99B2-DFFC5E090CDF--


From nobody Fri Dec 18 12:00:22 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49C91B38E4 for ; Fri, 18 Dec 2015 12:00:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 7WggsYbG7QTL for ; Fri, 18 Dec 2015 12:00:18 -0800 (PST)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 16BA41B38D5 for ; Fri, 18 Dec 2015 12:00:12 -0800 (PST)
Received: by mail-lf0-x22d.google.com with SMTP id l133so79059863lfd.2 for ; Fri, 18 Dec 2015 12:00:12 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=K1hk1zaPM1qy9thjrR/RhgyGoupQvoLmIx2Z9EVO7uo=; b=PNvQKdauBEVQxPrt0AWX4l+Iu/syVG0IJf3X9KrcYPaN+fmkIqsiai3Y/ylk4TOCMC TFTIKGJuQUjcXjkWGdduequke565tLsa7roXIr+nBuUbR42gNfJKKUcl/u82uTQhjDJF F0rNx5iS+w0ETuMxQTgBhkX5/RTnIrKPK5ZsDmgB3ArkpuidPkKbOzTRue04Acixv3Px D7pXHlyLFJ8VeBL4q6GovAuSqo/HoYBJ8V74Wo11g6pC1nf9n8pljMYkynrrMtk8JwUj 2OjQSN1N7nxrFxUktqBfmuwIg0w/Bn0SVIrnLDF+7zvzbc/AaQ02wViWDeXJUJTJOWfZ G6ag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=K1hk1zaPM1qy9thjrR/RhgyGoupQvoLmIx2Z9EVO7uo=; b=Rm8KFBTo4aqa+lhj01BZiidu2lRU1nZWyTJUMOm/FgRXeBtfWSASms4w9fvAf6bM9V QHqjN3AwyrqP3xH7T3k1WFYrOTGCpp++7324k5eYEyJwmv+dymDVziS9vPk3rgH9AhnN ZAXOT1s/Hb3XxpTpCdF3i07Kff1G5MVV8DQpEQlcAmr2AIPSH7moXMIyvXaeqxz0Zfz+ s5srVj1xsmgHEVNyme6JyZxGZ989AnPad6WrVKqlRYcgSXe4sOvjMSeib1E677E610xR DwusnpIUJ0RJGdCE4IgZhJya2qJn3jAldXzI6vCFbOaNX9E33xaxZuathSNlS9n/PNOL kvuw==
X-Gm-Message-State: ALoCoQkaF9J6k/Qzx+uTujq5gCCn40HSO2T2ZB6ceS2Ngob5UO4n0mvNFUsqMoWb3kioPsoKJWTlvoNoyV+DcGg1uW8outkJqA==
MIME-Version: 1.0
X-Received: by 10.25.64.9 with SMTP id n9mr2157836lfa.13.1450468810898; Fri, 18 Dec 2015 12:00:10 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Fri, 18 Dec 2015 12:00:10 -0800 (PST)
In-Reply-To: <91DB4E3A-AD71-409D-8B72-7327D5573D58@lucidvision.com>
References: <7E169FEA-ABF9-4B3F-BB86-A3D3B900741A@nic.cz>  <91DB4E3A-AD71-409D-8B72-7327D5573D58@lucidvision.com>
Date: Fri, 18 Dec 2015 12:00:10 -0800
Message-ID: 
From: Andy Bierman 
To: Nadeau Thomas 
Content-Type: multipart/alternative; boundary=001a113ea4f63b5e4b05273196b3
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 20:00:20 -0000

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

On Fri, Dec 18, 2015 at 11:49 AM, Nadeau Thomas 
wrote:

>
> On Dec 18, 2015:11:06 AM, at 11:06 AM, Andy Bierman 
> wrote:
>
>
>
> On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka  wrote:
>
>> Hi,
>>
>> if we want people to take YANG modules appearing in I-Ds seriously and
>> implement them, then we should apply the revisioning rules to them. That
>> is, if a module changes between two I-D revisions, then its revision-dat=
e
>> has to be bumped and a new entry added to the revision history. As it is
>> now, the I-D-based modules are esentially revisionless.
>>
>>
>
> The revision rules only apply to published modules.
> In IETF-speak, that means an RFC.  An Internet Draft
> is a work-in-progress.  We update the revision date every time
> the module changes, but the numerous incremental changes
> for a work-in-progress should not be recorded in the module
> revision history.  They should be recorded in the Change Log appendix.
>
> I will try to make this procedure more clear in the YANG guidelines draft=
.
>
>
> The question is one of =E2=80=9Cpublished=E2=80=9D.  So at the IETF that =
means an RFC
> today, but Lada makes a good point in that in our new rapid development
> environment we may never get to RFCs for most of the models being worked
> on today - or not for some time. If we want those I-Ds to be used in
> production, it might make sense to define an I-D as =E2=80=9Cpublished=E2=
=80=9D.
>
> As I pointed out earlier, for other organizations, they have different
> definitions of =E2=80=9Cpublished=E2=80=9D, so we should consider a more =
flexible
> definition of
> =E2=80=9Cpublished=E2=80=9D to encompass those.  Its probably not a big d=
eal to just say
> something like, =E2=80=9Cother organizations that define models will defi=
ne their
> own definition of stable/published, and in those cases, that will
> suffice as the threshold for a version and following the updating
> rules described herein."
>


I think we should just try to focus on our own standards development
process.
Other organizations can adopt or reject IETF practices if they want.
We are using the same definition of published for about 25 years.
It means RFC in our process.  In a vendor environment, it means modules
released to customers.

We don't have a rapid development environment in the IETF.
If people want to implement half-baked YANG modules, that is their business=
.
They should be commended if they actually provide implementation feedback
into the RFC, but a work-in-progress is not a published module.



> =E2=80=94Tom
>


Andy


>
>
>
>
>
>
>> Lada
>>
>>
> Andy
>
>
>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>> _______________________________________________
>> 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
>
>
>

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




On Fri, Dec 18, 2015 at 11:49 AM, Nadeau Thomas <<=
a href=3D"mailto:tnadeau@lucidvision.com" target=3D"_blank">tnadeau@lucidvi=
sion.com> wrote:

On Dec =
18, 2015:11:06 AM, at 11:06 AM, Andy Bierman <andy@yumaworks.com> wrote:



On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka &=
lt;lhotka@nic.cz>=
 wrote:
Hi,



if we want people to take YANG modules appearing in I-Ds seriously and impl=
ement them, then we should apply the revisioning rules to them. That is, if=
 a module changes between two I-D revisions, then its revision-date has to =
be bumped and a new entry added to the revision history. As it is now, the =
I-D-based modules are esentially revisionless.




The revision rules only=
 apply to published modules.
In IETF-speak, that means an RFC.=C2=
=A0 An Internet Draft
is a work-in-progress.=C2=A0 We update the =
revision date every time
the module changes, but the numerous inc=
remental changes
for a work-in-progress should not be recorded in=
 the module
revision history.=C2=A0 They should be recorded in th=
e Change Log appendix.

I will try to make this pro=
cedure more clear in the YANG guidelines draft.

	The question is one of =E2=80=9Cpublished=E2=80=9D.=C2=A0 So at the IE=
TF that means an RFC
today, but Lada makes a good point in that i=
n our new rapid development
environment we may never get to RFCs =
for most of the models being worked
on today - or not for some ti=
me. If we want those I-Ds to be used in
production, it might make=
 sense to define an I-D as =E2=80=9Cpublished=E2=80=9D.

	As I pointed out earlier=
, for other organizations, they have different
definitions of =E2=
=80=9Cpublished=E2=80=9D, so we should consider a more flexible definition =
of
=E2=80=9Cpublished=E2=80=9D to encompass those.=C2=A0 Its prob=
ably not a big deal to just say
something like, =E2=80=9Cother or=
ganizations that define models will define their
own definition o=
f stable/published, and in those cases, that will=C2=A0
suffice a=
s the threshold for a version and following the updating
rules de=
scribed herein."

I think we should just try to focus on our own standards develo=
pment process.
Other organizations can adopt or reject IETF pract=
ices if they want.
We are using the same definition of published =
for about 25 years.
It means RFC in our process.=C2=A0 In a vendo=
r environment, it means modules
released to customers.
=

We don't have a rapid development environment in the IET=
F.
If people want to implement half-baked YANG modules, that is t=
heir business.
They should be commended if they actually provide =
implementation feedback
into the RFC, but a work-in-progress is n=
ot a published module.



=
	=E2=80=94Tom
=



Andy
=C2=A0
=





<=
div>=C2=A0

Lada



Andy

=C2=A0

--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C









_______________________________________________

netmod mailing list

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




_______________________________________________
netmod mailing list
<=
a href=3D"mailto:netmod@ietf.org" target=3D"_blank">netmod@ietf.org
=
=
https://www.ietf.org/mailman/listinfo/netmod




--001a113ea4f63b5e4b05273196b3--


From nobody Fri Dec 18 12:02:43 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5E41B38A8 for ; Fri, 18 Dec 2015 12:02:42 -0800 (PST)
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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 w3t5Q9AcRg7e for ; Fri, 18 Dec 2015 12:02:39 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0139.outbound.protection.outlook.com [65.55.169.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D5F21B3898 for ; Fri, 18 Dec 2015 12:02:38 -0800 (PST)
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (TLS) id 15.1.355.16; Fri, 18 Dec 2015 20:02:36 +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.0355.012; Fri, 18 Dec 2015 20:02:36 +0000
From: Kent Watsen 
To: Robert Wilton , "netmod@ietf.org" 
Thread-Topic: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
Thread-Index: AQHROST+9GZCZpOeokmaO0YJheWZYJ7QnZ0AgAA6WoA=
Date: Fri, 18 Dec 2015 20:02:36 +0000
Message-ID: <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com>
In-Reply-To: <5673EF18.80907@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.151105
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.14]
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 5:+8CJMzGyfqZx8Nx54/mjnzvWa4Gy+AV/2shEJVncJNwbuKAxeQCzNsZgLwEfsDR3Neqcxt1EfXrvB3+gRmag8nAON9BLoAjkGG8qu3lJLR5zIzL+dgtGH2HQ9pi5I6z56kPswV1xXDs0st8Ime6jmg==; 24:WbmXFADQzVGldM/tc4mPusybB2cnx8i/MRSt//gAN2U4DLHcQnp21vmKe+ZFE1cbuMaeRw4CmDEt5cM8ip8ZsEEwr+tRYJMDEv/pB2owV58=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1441;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; 
x-forefront-prvs: 07943272E1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(51444003)(164054003)(377454003)(24454002)(479174004)(189002)(36756003)(189998001)(33656002)(5001960100002)(4001350100001)(5001770100001)(92566002)(99286002)(106116001)(54356999)(81156007)(66066001)(106356001)(83506001)(15975445007)(107886002)(83716003)(101416001)(87936001)(19580395003)(77096005)(2501003)(10400500002)(97736004)(2900100001)(105586002)(5004730100002)(82746002)(11100500001)(2950100001)(1096002)(122556002)(86362001)(5002640100001)(76176999)(6116002)(586003)(40100003)(19580405001)(3846002)(50986999)(102836003)(1220700001)(230783001)(5008740100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; 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:23
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: 18 Dec 2015 20:02:36.1863 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441
Archived-At: 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 20:02:42 -0000

DQpIaSBSb2JlcnQsDQoNCkkgYWdyZWUgdGhhdCAtMDEgZG9lc27igJl0IGFkZCBtdWNoIG9uIHRv
cCBvZiAtMDAuICBUaGlzIGlzIGV4cGVjdGVkIGFzIHdl4oCZcmUgaW4gdGhlIGZpdCBhbmQgZmlu
aXNoIHBoYXNlLiAgSWYgeW91IHdhbnQgdG8gaGVscCBmaW5pc2ggdGhlIGRyYWZ0LCB0aGVuIHBs
ZWFzZSBjb25zaWRlciByZXNwb25kaW5nIHRvIG9uZSBvZiB0aGVzZSB0aHJlYWRzOg0KDQogIGh0
dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9uZXRtb2QvY3VycmVudC9tc2cxNDU4
Ny5odG1sICAocmU6IHJvbGxiYWNrLW9uLWVycm9yKQ0KICBodHRwOi8vd3d3LmlldGYub3JnL21h
aWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNnMTQ2NDEuaHRtbCAgKHJlOiBtb2RlbC1z
dHJ1Y3R1cmUpDQoNCkFzIGZvciB0aGlzIHRocmVhZDoNCg0KMS4gUmVnYXJkaW5nIGFkZGluZyBh
biBleHBsaWNpdCBiYWNrd2FyZHMtY29tcGF0aWJpbGl0eSByZXF1aXJlbWVudCwgcGxlYXNlIG5v
dGUgdGhhdCB3aGF0IHdhcyB3cml0dGVuIGhlcmUgaXMgc3RpbGwgaW4gZWZmZWN0OiBodHRwOi8v
d3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvbmV0bW9kL2N1cnJlbnQvbXNnMTQ2MjkuaHRt
bC4gIE5vdGUgdGhhdCBubyBvYmplY3Rpb25zIGhhdmUgYmVlbiByYWlzZWQgeWV0LCBzbyB0aGlz
IHdpbGwgbGlrZWx5IGhhcHBlbi4NCg0KMi4gUmVnYXJkaW5nIGFkZGluZyBhbiBhcHBsaWNhYmls
aXR5IHN0YXRlbWVudCwgdGhlcmUgaXMgY3VycmVudGx5IG9ubHkgb25lIHZvaWNlIGFza2luZyBm
b3IgaXQsIHdoaWNoIGlzbuKAmXQgZW5vdWdoIHRvIHdhcnJhbnQgYSBjaGFuZ2UuDQoNClRoYW5r
cywNCktlbnQNCg0KDQoNCk9uIDEyLzE4LzE1LCA2OjMzIEFNLCAibmV0bW9kIG9uIGJlaGFsZiBv
ZiBSb2JlcnQgV2lsdG9uIiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHJ3
aWx0b25AY2lzY28uY29tPiB3cm90ZToNCg0KPkhpLA0KPg0KPk9uIDE3LzEyLzIwMTUgMjM6NDUs
IFJhbmR5IFByZXN1aG4gd3JvdGU6DQo+PiBIaSAtDQo+Pg0KPj4+IEZyb206IFJvYmVydCBXaWx0
b24NCj4+PiBTZW50OiBEZWMgMTcsIDIwMTUgMToxMiBQTQ0KPj4+IFRvOiBBbmR5IEJpZXJtYW4N
Cj4+PiBDYzogIm5ldG1vZEBpZXRmLm9yZyINCj4+PiBTdWJqZWN0OiBSZTogW25ldG1vZF0gTkVU
TU9EIFdHIExDOiBkcmFmdC1pZXRmLW5ldG1vZC1vcHN0YXRlLXJlcXMtMDENCj4+IC4uLg0KPj4+
ICAgICAgWW91ciByZXF1aXJlbWVudCBpcyBhIGJpdCB0b28gc3Ryb25nIGZvciBteSBsaWtpbmcu
DQo+Pj4NCj4+PiAgICAgIFRvIHBhcmFwaHJhc2UgeW91ciByZXF1aXJlbWVudCB0ZXh0LCBpdCBp
cyBmb3JjaW5nIHRoYXQgYWxsDQo+Pj4gICAgICBjb21wbGlhbnQgTkVUQ09ORi9SRVNUQ09ORiBz
ZXJ2ZXJzIE1VU1Qgc3VwcG9ydCBhbnkgY2xpZW50cyB0aGF0IGRvDQo+Pj4gICAgICBub3Qgd2Fu
dCB0byBkaWZmZXJlbnRpYXRlIGJldHdlZW4gaW50ZW5kZWQgY29uZmlnIGFuZCBhcHBsaWVkDQo+
Pj4gICAgICBjb25maWcuDQo+PiBEbyBkbyBvdGhlcndpc2Ugc291bmQgdG8gbWUgbGlrZSBhbiBp
bnRlcm9wZXJhYmlsaXR5IGRpc2FzdGVyLA0KPj4gYW5kIHdvdWxkIGVuY291cmFnZSB0aGUgInNp
bG9pemF0aW9uIiBvZiB0b29sc2V0cy4NCj4+DQo+Pj4gICAgICBIb3dldmVyLCB0aGlzIHJlcXVp
cmVzIGFsbCBvcHN0YXRlIGF3YXJlIHNlcnZlcnM6DQo+Pj4NCj4+PiAgICAgICAtIFRvIGhhbmRs
ZSBhIG1peCBvZiBjbGllbnRzLCBzb21lIG9mIHdoaWNoIGFyZSBvcHN0YXRlIGF3YXJlLCBhbmQN
Cj4+PiAgICAgICBzb21lIHRoYXQgYXJlIG5vdC4NCj4+IFRoaXMgc2VlbXMgcGVyZmVjdGx5IHJl
YXNvbmFibGUuICBUbyBkbyBvdGhlcndpc2UgdG9ycGVkb2VzIHRoZSB2ZXJ5DQo+PiBub3Rpb24g
b2YgaW50ZXJvcGVyYWJpbGl0eS4NCj4+DQo+Pj4gICAgICAgLSBUbyBwb3RlbnRpYWxseSBoYW5k
bGUgYSBtaXggb2YgcmVxdWVzdHMsIHNvbWUgb2Ygd2hpY2ggYXJlDQo+Pj4gICAgICAgb3BzdGF0
ZSBhd2FyZSByZXF1ZXN0cywgYW5kIHNvbWUgYXJlIG5vdC4NCj4+IERpdHRvLg0KPj4NCj4+PiAg
ICAgIEl0IGFsc28gcHJldmVudHM6DQo+Pj4NCj4+PiAgICAgICAtIEhhdmluZyBhIHNlcnZlciB0
aGF0IGlzIGltcGxlbWVudGVkIHRvIG9ubHkgc3VwcG9ydCBvcHN0YXRlIGF3YXJlDQo+Pj4gICAg
ICAgY2xpZW50cy4NCj4+IEF2b2lkaW5nIHRoZSBjcmVhdGlvbiBvZiBzdWNoIHNlcnZlcnMgc291
bmRzIGxpa2UgYSAqZ29vZCogdGhpbmcgdG8gbWUuDQo+Pg0KPj4+ICAgICAgIC0gSGF2aW5nIGEg
c2VydmVyIHNpZGUgY29uZmlndXJhdGlvbiBrbm9iIHRvIGNvbnRyb2wgdGhlIGJlaGF2aW91cg0K
Pj4+ICAgICAgIChzaW5jZSBpdCB3b3VsZCBhZmZlY3QgdGhlIHNlbWFudGljcyBmb3IgYWxsIGNs
aWVudHMpLg0KPj4gVGhpcyBhbHNvIHNvdW5kcyBsaWtlIHNvbWV0aGluZyB3aGljaCBpdCB3b3Vs
ZCBiZSBkZXNpcmVhYmxlIHRvIHByZXZlbnQuDQo+Pg0KPj4gSSB0aGluayBJJ20gc3F1YXJlbHkg
d2l0aCBBbmR5IG9uIHRoaXMgb25lLg0KPg0KPlRha2luZyBhIHN0ZXAgYmFjayAuLi4NCj4NCj5J
IGFtIHByb2JhYmx5IHdheSBvZmYgdGhlIG1hcmssIGJ1dCBteSBwZXJjZXB0aW9uIGlzIHRoYXQg
c29tZSAocGVyaGFwcyANCj5tYW55KSBvZiB0aGUgZm9sa3MgaW4gdGhlIFdHIHN0aWxsIHBlcmNl
aXZlIHRoYXQgdGhlIG9wc3RhdGUgDQo+cmVxdWlyZW1lbnRzIGFyZSBuaWNoZSByZXF1aXJlbWVu
dHMgZm9yIHNvbWUgdW51c3VhbCBzY2VuYXJpb3MsIGFuZCB0aGF0IA0KPmV2ZXJ5b25lIGVsc2Ug
aXMgaGFwcHkgd2l0aCB0aGUgc3RhdHVzIHF1byBhbmQgZG9uJ3Qgd2FudC9uZWVkIHRoZW0uDQo+
DQo+QWxhcywgSSBkb24ndCBzaGFyZSB0aGF0IHZpZXcuICBGb3IgbWUsIHRoZSBvcHN0YXRlIHJl
cXVpcmVtZW50cyBjYW4gYmUgDQo+c3VtbWFyaXplZCBhcyBzYXlpbmcgdGhhdCB0aGUgb3BlcmF0
b3JzIGp1c3Qgd2FudCB0byBrbm93IHdoYXQgDQo+Y29uZmlndXJhdGlvbiB0aGUgZGV2aWNlIGlz
IGFjdHVhbGx5IHJ1bm5pbmcgaW4gYSBmb3JtYXQgdGhhdCBpcyANCj5jb252ZW5pZW50IGZvciB0
aGVtIHRvIHVzZS4gIFRoaXMgcmVhbGx5IGRvZXNuJ3QgYXBwZWFyIHRvIGJlIA0KPnVucmVhc29u
YWJsZSByZXF1ZXN0IHRvIG1lLCBhbmQgaWYgSSB3YXMgd3JpdGluZyB0byBhIG5ldHdvcmsgDQo+
bWFuYWdlYWJpbGl0eSBBUEkgdGhlbiBJIHdvdWxkIGNob29zZSB0byB1c2Ugb3BzdGF0ZSBiZWNh
dXNlIEkgcGVyY2VpdmUgDQo+dGhhdCBpdCBpcyBhIG1vcmUgcm9idXN0IGFuZCBlYXNpZXIgdG8g
dXNlIEFQSS4gIFRoZSBjb3VudGVyIGFyZ3VtZW50cyANCj5hcHBlYXIgdG8gYmUgdGhhdCBpdCBp
cyB0b28gaGFyZCBmb3IgZGV2aWNlcyB0byBwcm92aWRlIHRoaXMgDQo+aW5mb3JtYXRpb24sIGFu
ZCB0aGF0IHRoZSBvcGVyYXRvcnMgaGF2ZSBoaXN0b3JpY2FsbHkgbWFuYWdlZCB3aXRob3V0IGl0
Lg0KPg0KPkhvd2V2ZXIsIEkgdGhpbmsgdGhhdCBzZXZlcmFsIHRoaW5ncyBoYXZlIGNoYW5nZWQs
IGFuZCBoZW5jZSBuZWdhdGUgDQo+dGhlc2UgY291bnRlciBhcmd1bWVudHM6IChpKSB0aGUgb3Bl
cmF0b3JzIHdhbnQgdG8gaGF2ZSBtdWNoIG1vcmUgDQo+YXV0b21hdGlvbiBhbmQgbWFuYWdlbWVu
dCBvdmVyIHRoZWlyIGRldmljZXMsIChpaSkgdGhleSBoYXZlIGZvdW5kIGEgd2F5IA0KPnRvIGdy
b3VwIHRvZ2V0aGVyIGFuZCBoYXZlIGEgbW9yZSB2b2NhbCB2b2ljZSBhYm91dCB3aGF0IHRoZXkg
bmVlZCBhbmQgDQo+d2FudCwgKGlpaSkgdGhlIG9wZXJhdG9ycyBoYXZlIHJlYWxpemVkIHRoYXQg
dGhleSBkb24ndCBuZWVkIHRvIHdhaXQgZm9yIA0KPnRoZSBTRE9zIGFuZCBjYW4gY3JlYXRlIGRl
ZmFjdG8gc3RhbmRhcmQgbW9kZWxzIG9uIHRoZWlyIG93biBpZiB0aGV5IA0KPmhhdmUgdG8uDQo+
DQo+UGVyc29uYWxseSwgSSB3b3VsZCBsaWtlIHVzIHRvIHN0b3Agc3BlbmRpbmcgdGltZSBjaHVy
bmluZyBvbiB0aGUgDQo+cmVxdWlyZW1lbnRzIGFuZCBhY3R1YWxseSBnZXQgb24gdG8gZGlzY3Vz
c2luZyB0aGUgc29sdXRpb25zLiAgVG8gYmUgDQo+aG9uZXN0LCB0aGVyZSBoYXMgYmVlbiByZWxh
dGl2ZWx5IGxpdHRsZSBjaGFuZ2UgaW4gbXkgdW5kZXJzdGFuZGluZyBvZiANCj50aGUgcmVxdWly
ZW1lbnRzIGZyb20gcmVhZGluZyBkcmFmdC1vcGVuY29uZmlnLW5ldG1vZC1vcHN0YXRlLTAxIGJh
Y2sgaW4gDQo+SnVseSwgYW5kIEkgd2FzIGV4cGVjdGluZyB0byBkaXNjdXNzIHRoZSBzb2x1dGlv
biBkcmFmdHMgYmFjayBpbiANCj5TZXB0ZW1iZXIuICBIZXJlIHdlIGFyZSBpbiBEZWNlbWJlciwg
YW5kIEknbSBub3QgY29udmluY2VkIHRoYXQgd2UgaGF2ZSANCj50cnVseSBtYWRlIHNpZ25pZmlj
YW50IHByb2dyZXNzLg0KPg0KPlRoZSBvbmx5IHJlYXNvbiB0aGF0IEkgc3VibWl0dGVkIGEgc29s
dXRpb24gZHJhZnQgdG8gdGhpcyBwcm9ibGVtIHdhcyANCj5iZWNhdXNlIEkgdGhvdWdodCBpdCB1
bmxpa2VseSB0aGF0IE9wZW5Db25maWcgd291bGQgc3VwcG9ydCBhIG11bHRpcGxlIA0KPmRhdGFz
dG9yZSBzb2x1dGlvbiwgYW5kIEkgY291bGQgc2VlIHN0cm9uZyByZXNpc3RhbmNlIGFtb25nc3Qg
dGhlIElFVEYgDQo+ZW5naW5lZXJzIHRvIHRoZSBwcm9wb3NlZCBPcGVuQ29uZmlnIHNvbHV0aW9u
LiAgSSB3YXMgaG9waW5nIHRoYXQgbXkgDQo+cHJvcG9zZWQgc29sdXRpb24gbWlnaHQgYmUgc2Vl
biBmb3IgdGhlIGNvbXByb21pc2UgdGhhdCBpdCBpcyBiZXR3ZWVuIA0KPnRoZSB0d28gb3Bwb3Np
bmcgcG9zaXRpb25zLiAgQnV0IEkgY2FyZSBsZXNzIG9uIHdoYXQgdGhlIHNvbHV0aW9uIGlzLCAN
Cj5hbmQgbW9yZSB3aGV0aGVyIHdlIGNhbiBhZ3JlZSBvbiBvbmUgYW5kIG1vdmUgZm9yd2FyZC4N
Cj4NCj5BcyBzb21lb25lIHRoYXQgaXMgcXVpdGUgbmV3IHRvIFNETyBwcm9jZXNzZXMsIG15IG1h
aW4gY29uY2VybiBpcyB0aGF0IA0KPklFVEYgKGFuZCBvdGhlciBzdGFuZGFyZHMgYm9kaWVzKSBh
cmUgbW92aW5nIHRvbyBzbG93bHkgaGVyZSwgYW5kIHRoYXQgDQo+YnkgdGhlIHRpbWUgdGhhdCBJ
RVRGIGhhdmUgcHJvZHVjZWQgYSBzdWZmaWNpZW50bHkgY29tcGxldGUgc2V0IG9mIFlBTkcgDQo+
bW9kZWxzIHRvIG1hbmFnZSBuZXR3b3JrIGRldmljZXMgaXQgd2lsbCBiZSB0b28gbGF0ZSBiZWNh
dXNlIHRoZSANCj5pbmR1c3RyeSB3aWxsIGFscmVhZHkgaGF2ZSBjb252ZXJnZWQgb24gdGhlIE9w
ZW5Db25maWcgbW9kZWxzLCB3aGljaCANCj5hbHRob3VnaCBub3QgcGVyZmVjdCwgYXJlIGNsb3Nl
IHRvIGJlaW5nIHVzYWJsZSBub3csIGFuZCBhcmUgYmVpbmcgDQo+ZXZvbHZlZCBhdCBhIG11Y2gg
cXVpY2tlciBwYWNlIC4uLg0KPg0KPlNvIG15IGhvcGUgZm9yIHRoZSBlYXJseSBuZXcgeWVhciBp
cyB0aGF0IHdlIGNhbiByZWFjaCBjb21tb24gZ3JvdW5kIA0KPndpdGggT3BlbkNvbmZpZyBhbmQg
Y29udmVyZ2Ugb24gYSBzaW5nbGUgc2V0IG9mIFlBTkcgbW9kdWxlcyBmb3IgDQo+bWFuYWdpbmcg
bmV0d29yayBkZXZpY2VzLCBhbmQgdGhhdCBpbmNsdWRlcyBoYXZpbmcgYSBzb2x1dGlvbiB0byB0
aGUgDQo+T3BzdGF0ZSBwcm9ibGVtLg0KPg0KPkZpbmFsbHksIGlmIG15IGFjcXVpZXNjaW5nIHRv
IEFuZHkncyByZXF1aXJlbWVudCBpcyBoZWxwZnVsIHRvIG1vdmUgdGhpcyANCj5wcm9jZXNzIGZv
cndhcmQgdGhlbiB0aGF0IGlzIGZpbmUgd2l0aCBtZS4gIEFzIEkgaGF2ZSBwcmV2aW91c2x5IA0K
PmluZGljYXRlZCwgSSBkb24ndCByZWFsbHkgdGhpbmsgdGhhdCBpdCBoZWxwcyB3aXRoIGZyYW1p
bmcgb3IgZGlzY3Vzc2luZyANCj50aGUgc29sdXRpb25zLCBidXQgZXF1YWxseSBJIGNhbiBsaXZl
IHdpdGggaXQgc2luY2UgSSBzdXNwZWN0IHRoYXQgdGhlIA0KPnNvbHV0aW9ucyBhcmUgbGlrZWx5
IHRvIGNvbXBseSB3aXRoIGl0IGFueXdheS4NCj4NCj5BcG9sb2dpZXMgZm9yIHRoZSBsb25nIGVt
YWlsLCBhbmQgZ2l2ZW4gSSBtYXkgbm90IGJlIGFjdGl2ZWx5IHJlYWRpbmcgDQo+dGhlIFdHIGVt
YWlscyBvdmVyIHRoZSBuZXh0IGNvdXBsZSBvZiB3ZWVrcywgSSdsbCB3aXNoIHlvdSBhbGwgaGFw
cHkgDQo+aG9saWRheXMhDQo+DQo+VGhhbmtzLA0KPlJvYg0KPg0KPj4NCj4+IFJhbmR5DQo+Pg0K
Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IG5l
dG1vZCBtYWlsaW5nIGxpc3QNCj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4+IC4NCj4+DQo+DQo+X19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5uZXRtb2QgbWFpbGluZyBsaXN0
DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9uZXRtb2QNCg==


From nobody Fri Dec 18 12:19:21 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA611B38A7 for ; Fri, 18 Dec 2015 12:19:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 H2Z86lu8EyuV for ; Fri, 18 Dec 2015 12:19:17 -0800 (PST)
Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::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 050831B38A6 for ; Fri, 18 Dec 2015 12:19:17 -0800 (PST)
Received: by mail-lb0-x235.google.com with SMTP id pv2so1615909lbb.1 for ; Fri, 18 Dec 2015 12:19:16 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=sk/ugbVHh5MQvBlMOAFDHAfiUEOSf5w3ZKiW9KORLRc=; b=rHgcjGc/bFQ52VfVSbuCx35zwz6N/UeIreOnYuCm2sQfY3HKMfpFXTkEM5p34FZbI/ NRmO40jWQhnY1lMsyEQOZDRye13VcO8AGPLbbNGCZHxP+yTloxOA5G6RQSNhQZvxpBez syq1IMO8kD5DM5VfyJRPBjibM/SHp9dhJENlGxvReVXVPse5EdFNhTmirhQUx0phi5Hq PGN8Hc0BbxjON4GFjTLoVjWWV0P/9lSAwc87DcdfJAUVlaE9XzyXFr4yn63HYZ6wY3FZ Dx/YaT8h31t439xE09CuS7+e53mkgE7hilusRyuy8OTnO78oX8HGwrHgfRkDP5lPI/AI Y32g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sk/ugbVHh5MQvBlMOAFDHAfiUEOSf5w3ZKiW9KORLRc=; b=dVxREXY1utpYhMTDfiMy9mn7GiHGD0NsmB8okc7jhUm0oTvAXeKEB1JVJr7kfZX41v uzlECC7EP/LmEWuWpiL/pgkm1ZxlSTYoZX9tTmIOXeivdiALtlQWA6UfRnX02XpMuR4T dMIlXbTh7sllCKHDoKR0aQNXf7YakhKQYbHvSMm44AjJZ5CxOdYI8nd2t/u4FoOZevEj dNYYykJh9XBajTO6RS0Lya2jT6FD87DanL/CjYGbcNjRFndJylsZIYE4rl825peR+Ota 39eA9Lgb11EU9trRt0YN/L8JW4t/YMEFSYreNNTYq2L0l1NcxCN0LutN4f/2xouiQmSz TykA==
X-Gm-Message-State: ALoCoQk5uJ3MFASwyBhtKp2T3LqGttQoP1eaKgSKW+9hmNkRZYKlaB8Ees+uTSTXkRpKSg7FOA3zGgP5Jfli6oG/reeQ7ji4vA==
MIME-Version: 1.0
X-Received: by 10.112.134.169 with SMTP id pl9mr2098505lbb.145.1450469955175;  Fri, 18 Dec 2015 12:19:15 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Fri, 18 Dec 2015 12:19:15 -0800 (PST)
In-Reply-To: <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>
Date: Fri, 18 Dec 2015 12:19:15 -0800
Message-ID: 
From: Andy Bierman 
To: Kent Watsen 
Content-Type: multipart/alternative; boundary=089e011767e96fa708052731da99
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 20:19:20 -0000

--089e011767e96fa708052731da99
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Dec 18, 2015 at 12:02 PM, Kent Watsen  wrote:

>
> Hi Robert,
>
> I agree that -01 doesn=E2=80=99t add much on top of -00.  This is expecte=
d as
> we=E2=80=99re in the fit and finish phase.  If you want to help finish th=
e draft,
> then please consider responding to one of these threads:
>
>   http://www.ietf.org/mail-archive/web/netmod/current/msg14587.html  (re:
> rollback-on-error)
>   http://www.ietf.org/mail-archive/web/netmod/current/msg14641.html  (re:
> model-structure)
>
> As for this thread:
>
> 1. Regarding adding an explicit backwards-compatibility requirement,
> please note that what was written here is still in effect:
> http://www.ietf.org/mail-archive/web/netmod/current/msg14629.html.  Note
> that no objections have been raised yet, so this will likely happen.
>
> 2. Regarding adding an applicability statement, there is currently only
> one voice asking for it, which isn=E2=80=99t enough to warrant a change.
>
>
I did not ask to add an AS to the charter.
I don't think the WG agrees enough on the problem to write such a document.




> Thanks,
> Kent
>

Andy


>
>
>
> On 12/18/15, 6:33 AM, "netmod on behalf of Robert Wilton" <
> netmod-bounces@ietf.org on behalf of rwilton@cisco.com> wrote:
>
> >Hi,
> >
> >On 17/12/2015 23:45, Randy Presuhn wrote:
> >> Hi -
> >>
> >>> From: Robert Wilton
> >>> Sent: Dec 17, 2015 1:12 PM
> >>> To: Andy Bierman
> >>> Cc: "netmod@ietf.org"
> >>> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
> >> ...
> >>>      Your requirement is a bit too strong for my liking.
> >>>
> >>>      To paraphrase your requirement text, it is forcing that all
> >>>      compliant NETCONF/RESTCONF servers MUST support any clients that
> do
> >>>      not want to differentiate between intended config and applied
> >>>      config.
> >> Do do otherwise sound to me like an interoperability disaster,
> >> and would encourage the "siloization" of toolsets.
> >>
> >>>      However, this requires all opstate aware servers:
> >>>
> >>>       - To handle a mix of clients, some of which are opstate aware,
> and
> >>>       some that are not.
> >> This seems perfectly reasonable.  To do otherwise torpedoes the very
> >> notion of interoperability.
> >>
> >>>       - To potentially handle a mix of requests, some of which are
> >>>       opstate aware requests, and some are not.
> >> Ditto.
> >>
> >>>      It also prevents:
> >>>
> >>>       - Having a server that is implemented to only support opstate
> aware
> >>>       clients.
> >> Avoiding the creation of such servers sounds like a *good* thing to me=
.
> >>
> >>>       - Having a server side configuration knob to control the
> behaviour
> >>>       (since it would affect the semantics for all clients).
> >> This also sounds like something which it would be desireable to preven=
t.
> >>
> >> I think I'm squarely with Andy on this one.
> >
> >Taking a step back ...
> >
> >I am probably way off the mark, but my perception is that some (perhaps
> >many) of the folks in the WG still perceive that the opstate
> >requirements are niche requirements for some unusual scenarios, and that
> >everyone else is happy with the status quo and don't want/need them.
> >
> >Alas, I don't share that view.  For me, the opstate requirements can be
> >summarized as saying that the operators just want to know what
> >configuration the device is actually running in a format that is
> >convenient for them to use.  This really doesn't appear to be
> >unreasonable request to me, and if I was writing to a network
> >manageability API then I would choose to use opstate because I perceive
> >that it is a more robust and easier to use API.  The counter arguments
> >appear to be that it is too hard for devices to provide this
> >information, and that the operators have historically managed without it=
.
> >
> >However, I think that several things have changed, and hence negate
> >these counter arguments: (i) the operators want to have much more
> >automation and management over their devices, (ii) they have found a way
> >to group together and have a more vocal voice about what they need and
> >want, (iii) the operators have realized that they don't need to wait for
> >the SDOs and can create defacto standard models on their own if they
> >have to.
> >
> >Personally, I would like us to stop spending time churning on the
> >requirements and actually get on to discussing the solutions.  To be
> >honest, there has been relatively little change in my understanding of
> >the requirements from reading draft-openconfig-netmod-opstate-01 back in
> >July, and I was expecting to discuss the solution drafts back in
> >September.  Here we are in December, and I'm not convinced that we have
> >truly made significant progress.
> >
> >The only reason that I submitted a solution draft to this problem was
> >because I thought it unlikely that OpenConfig would support a multiple
> >datastore solution, and I could see strong resistance amongst the IETF
> >engineers to the proposed OpenConfig solution.  I was hoping that my
> >proposed solution might be seen for the compromise that it is between
> >the two opposing positions.  But I care less on what the solution is,
> >and more whether we can agree on one and move forward.
> >
> >As someone that is quite new to SDO processes, my main concern is that
> >IETF (and other standards bodies) are moving too slowly here, and that
> >by the time that IETF have produced a sufficiently complete set of YANG
> >models to manage network devices it will be too late because the
> >industry will already have converged on the OpenConfig models, which
> >although not perfect, are close to being usable now, and are being
> >evolved at a much quicker pace ...
> >
> >So my hope for the early new year is that we can reach common ground
> >with OpenConfig and converge on a single set of YANG modules for
> >managing network devices, and that includes having a solution to the
> >Opstate problem.
> >
> >Finally, if my acquiescing to Andy's requirement is helpful to move this
> >process forward then that is fine with me.  As I have previously
> >indicated, I don't really think that it helps with framing or discussing
> >the solutions, but equally I can live with it since I suspect that the
> >solutions are likely to comply with it anyway.
> >
> >Apologies for the long email, and given I may not be actively reading
> >the WG emails over the next couple of weeks, I'll wish you all happy
> >holidays!
> >
> >Thanks,
> >Rob
> >
> >>
> >> Randy
> >>
> >> _______________________________________________
> >> 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
>

--089e011767e96fa708052731da99
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Dec 18, 2015 at 12:02 PM, Kent Watsen <kwatsen@juniper.net> wrote:


Hi Robert,



I agree that -01 doesn=E2=80=99t add much on top of -00.=C2=A0 This is expe=
cted as we=E2=80=99re in the fit and finish phase.=C2=A0 If you want to hel=
p finish the draft, then please consider responding to one of these threads=
:



=C2=A0 http://www.ietf.org/mail-arc=
hive/web/netmod/current/msg14587.html=C2=A0 (re: rollback-on-error)

=C2=A0 http://www.ietf.org/mail-arc=
hive/web/netmod/current/msg14641.html=C2=A0 (re: model-structure)



As for this thread:



1. Regarding adding an explicit backwards-compatibility requirement, please=
 note that what was written here is still in effect: http://www.ietf.org/mail-archive/web/netmod/current/msg14=
629.html.=C2=A0 Note that no objections have been raised yet, so this w=
ill likely happen.



2. Regarding adding an applicability statement, there is currently only one=
 voice asking for it, which isn=E2=80=99t enough to warrant a change.



I did not ask to add an AS to the char=
ter.
I don't think the WG agrees enough on the problem to wri=
te such a document.


=C2=A0

Thanks,

Kent

Andy
=C2=A0







On 12/18/15, 6:33 AM, "netmod on behalf of Robert Wilton" <netmod-bounces@ietf.org on beha=
lf of rwilton@cisco.com> wrote:=




>Hi,

>

>On 17/12/2015 23:45, Randy Presuhn wrote:

>> Hi -

>>

>>> From: Robert Wilton

>>> Sent: Dec 17, 2015 1:12 PM

>>> To: Andy Bierman

>>> Cc: "netmod@ietf.org"

>>> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-=
reqs-01

>> ...

>>>=C2=A0 =C2=A0 =C2=A0 Your requirement is a bit too strong for m=
y liking.

>>>

>>>=C2=A0 =C2=A0 =C2=A0 To paraphrase your requirement text, it is=
 forcing that all

>>>=C2=A0 =C2=A0 =C2=A0 compliant NETCONF/RESTCONF servers MUST su=
pport any clients that do

>>>=C2=A0 =C2=A0 =C2=A0 not want to differentiate between intended=
 config and applied

>>>=C2=A0 =C2=A0 =C2=A0 config.

>> Do do otherwise sound to me like an interoperability disaster,

>> and would encourage the "siloization" of toolsets.

>>

>>>=C2=A0 =C2=A0 =C2=A0 However, this requires all opstate aware s=
ervers:

>>>

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0- To handle a mix of clients, some o=
f which are opstate aware, and

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0some that are not.

>> This seems perfectly reasonable.=C2=A0 To do otherwise torpedoes t=
he very

>> notion of interoperability.

>>

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0- To potentially handle a mix of req=
uests, some of which are

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0opstate aware requests, and some are=
 not.

>> Ditto.

>>

>>>=C2=A0 =C2=A0 =C2=A0 It also prevents:

>>>

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0- Having a server that is implemente=
d to only support opstate aware

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0clients.

>> Avoiding the creation of such servers sounds like a *good* thing t=
o me.

>>

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0- Having a server side configuration=
 knob to control the behaviour

>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0(since it would affect the semantics=
 for all clients).

>> This also sounds like something which it would be desireable to pr=
event.

>>

>> I think I'm squarely with Andy on this one.

>

>Taking a step back ...

>

>I am probably way off the mark, but my perception is that some (perhaps=


>many) of the folks in the WG still perceive that the opstate

>requirements are niche requirements for some unusual scenarios, and tha=
t

>everyone else is happy with the status quo and don't want/need them=
.

>

>Alas, I don't share that view.=C2=A0 For me, the opstate requiremen=
ts can be

>summarized as saying that the operators just want to know what

>configuration the device is actually running in a format that is

>convenient for them to use.=C2=A0 This really doesn't appear to be<=
br>
>unreasonable request to me, and if I was writing to a network

>manageability API then I would choose to use opstate because I perceive=


>that it is a more robust and easier to use API.=C2=A0 The counter argum=
ents

>appear to be that it is too hard for devices to provide this

>information, and that the operators have historically managed without i=
t.

>

>However, I think that several things have changed, and hence negate

>these counter arguments: (i) the operators want to have much more

>automation and management over their devices, (ii) they have found a wa=
y

>to group together and have a more vocal voice about what they need and<=
br>
>want, (iii) the operators have realized that they don't need to wai=
t for

>the SDOs and can create defacto standard models on their own if they
>have to.

>

>Personally, I would like us to stop spending time churning on the

>requirements and actually get on to discussing the solutions.=C2=A0 To =
be

>honest, there has been relatively little change in my understanding of<=
br>
>the requirements from reading draft-openconfig-netmod-opstate-01 back i=
n

>July, and I was expecting to discuss the solution drafts back in

>September.=C2=A0 Here we are in December, and I'm not convinced tha=
t we have

>truly made significant progress.

>

>The only reason that I submitted a solution draft to this problem was
>because I thought it unlikely that OpenConfig would support a multiple<=
br>
>datastore solution, and I could see strong resistance amongst the IETF<=
br>
>engineers to the proposed OpenConfig solution.=C2=A0 I was hoping that =
my

>proposed solution might be seen for the compromise that it is between
>the two opposing positions.=C2=A0 But I care less on what the solution =
is,

>and more whether we can agree on one and move forward.

>

>As someone that is quite new to SDO processes, my main concern is that<=
br>
>IETF (and other standards bodies) are moving too slowly here, and that<=
br>
>by the time that IETF have produced a sufficiently complete set of YANG=


>models to manage network devices it will be too late because the

>industry will already have converged on the OpenConfig models, which
>although not perfect, are close to being usable now, and are being

>evolved at a much quicker pace ...

>

>So my hope for the early new year is that we can reach common ground
>with OpenConfig and converge on a single set of YANG modules for

>managing network devices, and that includes having a solution to the
>Opstate problem.

>

>Finally, if my acquiescing to Andy's requirement is helpful to move=
 this

>process forward then that is fine with me.=C2=A0 As I have previously
>indicated, I don't really think that it helps with framing or discu=
ssing

>the solutions, but equally I can live with it since I suspect that the<=
br>
>solutions are likely to comply with it anyway.

>

>Apologies for the long email, and given I may not be actively reading
>the WG emails over the next couple of weeks, I'll wish you all happ=
y

>holidays!

>

>Thanks,

>Rob

>

>>

>> Randy

>>

>> _______________________________________________

>> 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





--089e011767e96fa708052731da99--


From nobody Fri Dec 18 12:23:59 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D43D11B38AE for ; Fri, 18 Dec 2015 12:23:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 jNJN-yhvYwzk for ; Fri, 18 Dec 2015 12:23:55 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 9864F1B3049 for ; Fri, 18 Dec 2015 12:23:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450470205; bh=LjqzkQSwBdUjqSjla0cRi+JSffB87fM1RknVcWxt+hg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=VvlfxV6Cm0jBcZeMQPuIm5cSt+rOt7oN/1U4JNueGmQAk2MsFyl68bVJUFyuretWq DToxJefJCtxnJYgeW+6aybHq6wS0LjkAL5l85PScNzQOYkZJ5PIKDHB7b5PHKYTSyU ZWO2BGzBB8lwvCX3fvnwgYs9SbNNzdL7dpKOkzHU=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: multipart/alternative; boundary="Apple-Mail=_0E1F7086-3EBA-4880-B805-883F98C20E7F"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Nadeau Thomas 
In-Reply-To: 
Date: Fri, 18 Dec 2015 15:23:40 -0500
Message-Id: 
References: <7E169FEA-ABF9-4B3F-BB86-A3D3B900741A@nic.cz>  <91DB4E3A-AD71-409D-8B72-7327D5573D58@lucidvision.com> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=8 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 217, in=2915, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 20:23:58 -0000

--Apple-Mail=_0E1F7086-3EBA-4880-B805-883F98C20E7F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Dec 18, 2015:3:00 PM, at 3:00 PM, Andy Bierman  =
wrote:
>=20
>=20
>=20
> On Fri, Dec 18, 2015 at 11:49 AM, Nadeau Thomas =
> wrote:
>=20
>> On Dec 18, 2015:11:06 AM, at 11:06 AM, Andy Bierman =
> wrote:
>>=20
>>=20
>>=20
>> On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka > wrote:
>> Hi,
>>=20
>> if we want people to take YANG modules appearing in I-Ds seriously =
and implement them, then we should apply the revisioning rules to them. =
That is, if a module changes between two I-D revisions, then its =
revision-date has to be bumped and a new entry added to the revision =
history. As it is now, the I-D-based modules are esentially =
revisionless.
>>=20
>>=20
>>=20
>> The revision rules only apply to published modules.
>> In IETF-speak, that means an RFC.  An Internet Draft
>> is a work-in-progress.  We update the revision date every time
>> the module changes, but the numerous incremental changes
>> for a work-in-progress should not be recorded in the module
>> revision history.  They should be recorded in the Change Log =
appendix.
>>=20
>> I will try to make this procedure more clear in the YANG guidelines =
draft.
>=20
> 	The question is one of =E2=80=9Cpublished=E2=80=9D.  So at the =
IETF that means an RFC
> today, but Lada makes a good point in that in our new rapid =
development
> environment we may never get to RFCs for most of the models being =
worked
> on today - or not for some time. If we want those I-Ds to be used in
> production, it might make sense to define an I-D as =E2=80=9Cpublished=E2=
=80=9D.
>=20
> 	As I pointed out earlier, for other organizations, they have =
different
> definitions of =E2=80=9Cpublished=E2=80=9D, so we should consider a =
more flexible definition of
> =E2=80=9Cpublished=E2=80=9D to encompass those.  Its probably not a =
big deal to just say
> something like, =E2=80=9Cother organizations that define models will =
define their
> own definition of stable/published, and in those cases, that will=20
> suffice as the threshold for a version and following the updating
> rules described herein."
>=20
>=20
> I think we should just try to focus on our own standards development =
process.
> Other organizations can adopt or reject IETF practices if they want.
> We are using the same definition of published for about 25 years.
> It means RFC in our process.  In a vendor environment, it means =
modules
> released to customers.
>=20
> We don't have a rapid development environment in the IETF.
> If people want to implement half-baked YANG modules, that is their =
business.
> They should be commended if they actually provide implementation =
feedback
> into the RFC, but a work-in-progress is not a published module.

	That isn=E2=80=99t the point; the rest of the Yang universe =
looks to the IETF
to standardize and manage the Yang lanague and also looks here
for rules or best practices on building modules.=20

	=E2=80=94Tom


>=20
>=20
>=20
> 	=E2=80=94Tom
>=20
>=20
> Andy
> =20
>=20
>=20
>>=20
>>=20
>> =20
>> Lada
>>=20
>>=20
>> Andy
>>=20
>> =20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netmod =

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

>=20
>=20


--Apple-Mail=_0E1F7086-3EBA-4880-B805-883F98C20E7F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Dec 18, 2015:3:00 PM, at 3:00 PM, Andy Bierman <andy@yumaworks.com> =
wrote:



On Fri, Dec 18, 2015 at 11:49 AM, =
Nadeau Thomas <tnadeau@lucidvision.com> wrote:

On Dec =
18, 2015:11:06 AM, at 11:06 AM, Andy Bierman <andy@yumaworks.com> wrote:



On Fri, =
Dec 18, 2015 at 7:49 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
Hi,



if we want people to take YANG modules appearing in I-Ds seriously and =
implement them, then we should apply the revisioning rules to them. That =
is, if a module changes between two I-D revisions, then its =
revision-date has to be bumped and a new entry added to the revision =
history. As it is now, the I-D-based modules are esentially =
revisionless.




The revision rules only =
apply to published modules.
In IETF-speak, that =
means an RFC.  An Internet Draft
is a =
work-in-progress.  We update the revision date every time
the module changes, but the numerous incremental =
changes
for a work-in-progress should not be =
recorded in the module
revision history.  They =
should be recorded in the Change Log appendix.

I will try to make this procedure more =
clear in the YANG guidelines =
draft.

	The question is one of =E2=80=9Cpublished=E2=80=9D.=
  So at the IETF that means an RFC
today, but =
Lada makes a good point in that in our new rapid development
environment we may never get to RFCs for most of the models =
being worked
on today - or not for some time. If we =
want those I-Ds to be used in
production, it might =
make sense to define an I-D as =E2=80=9Cpublished=E2=80=9D.

	As I pointed out =
earlier, for other organizations, they have different
definitions of =E2=80=9Cpublished=E2=80=9D, so we should =
consider a more flexible definition of
=E2=80=9Cpublished=E2=80=9D to encompass those.  Its =
probably not a big deal to just say
something like, =
=E2=80=9Cother organizations that define models will define =
their
own definition of stable/published, and in =
those cases, that will 
suffice as the =
threshold for a version and following the updating
rules described herein."


I think we should just try to focus on our own standards =
development process.
Other organizations can adopt =
or reject IETF practices if they want.
We are using =
the same definition of published for about 25 years.
It means RFC in our process.  In a vendor environment, =
it means modules
released to customers.

We don't have a rapid =
development environment in the IETF.
If people want =
to implement half-baked YANG modules, that is their business.
They should be commended if they actually provide =
implementation feedback
into the RFC, but a =
work-in-progress is not a published =
module.

	That isn=E2=80=99t the point; the =
rest of the Yang universe looks to the IETF
to standardize and =
manage the Yang lanague and also looks here
for rules or best =
practices on building modules. 

	=E2=80=94Tom





	=
=E2=80=94Tom


Andy
 




 

Lada



Andy

 

--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C









_______________________________________________

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





=

--Apple-Mail=_0E1F7086-3EBA-4880-B805-883F98C20E7F--


From nobody Fri Dec 18 12:34:54 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5871B38C1 for ; Fri, 18 Dec 2015 12:34:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 Q7dM6KPAzFYf for ; Fri, 18 Dec 2015 12:34:50 -0800 (PST)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 A93A81B38B5 for ; Fri, 18 Dec 2015 12:34:49 -0800 (PST)
Received: by mail-lf0-x229.google.com with SMTP id y184so79780171lfc.1 for ; Fri, 18 Dec 2015 12:34:49 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=iOH06y/ikE/hUQql5XL8QxJ9ETUKStaah1JkXrxlC2w=; b=KNV1LV7g+3ustS0ecmwVl0AzmFqCpLGdWBsH0ZopoAyVw3kdGm5hA7MPWx1Kruy+PQ auUeppEaIMuy3aYAvAWupD5y0gQd943/svj48QXfuUUhSVss7fgA/bUt1+Mvqvty0tTq 3izqrQO6Qa+rVrVMg/bZOym0AF4UChjjJB/W/tflG3DVz3NAT+KD/wPFAlNFi28ptwLS T9OIqh2jdB1BKSpnkqPHHyv1gzBbpfFpXBsuiSWeOGPci4R0dpdq3ljKF3xIkzME9Gvn c6hnbt6ZoXUlUPG1XRS7m1seN4W0mOWM7PkBMWUCAlK4LG+OLbBi7Cbu9TOQkqsSm+ju 1UOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iOH06y/ikE/hUQql5XL8QxJ9ETUKStaah1JkXrxlC2w=; b=csAp3Br0HXmPuArxvGfT6zVLYiMgrHoQyPBDngkdjRyEK+Rqnt3XXBmmz62dbtpc4H rnMMCUE/YkhY3lebLPsbSAzQYj8u0AHnDTL+Yp/g6RR9tLP8sxeVHZ1O3TbBMVk4oOTn G8/Goihn1TtMHdiRFP6OnaY7pX8OLYoVnTjWjgI08U1jjRTpQR5hZm2qNV00Glwnf6Fd qej18nkJp0+gdMK0arCSwp8eGaSyH90c0CMlPz93i/DcUtn84WURCKBBayS5zaKlSqef CxgfFOhMApeZWwg6qN1ATuYfqMzIdVt59D8LlJFz/SxlmiiMjXzAAQKmWdVwPmcPD4kn C4Pw==
X-Gm-Message-State: ALoCoQk2l6t0DyiwbNYGrDMV7UyT9IXLV2tAZv09vlKlpHctxi5XeSs3ykc1Y+m5z+4lzT2MQynsMWSRZxy3UvQ74XYDuR8vdQ==
MIME-Version: 1.0
X-Received: by 10.25.0.205 with SMTP id 196mr2364737lfa.62.1450470887830; Fri, 18 Dec 2015 12:34:47 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Fri, 18 Dec 2015 12:34:47 -0800 (PST)
In-Reply-To: 
References: <7E169FEA-ABF9-4B3F-BB86-A3D3B900741A@nic.cz>  <91DB4E3A-AD71-409D-8B72-7327D5573D58@lucidvision.com>  
Date: Fri, 18 Dec 2015 12:34:47 -0800
Message-ID: 
From: Andy Bierman 
To: Nadeau Thomas 
Content-Type: multipart/alternative; boundary=001a113c9c1206d038052732123e
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 20:34:52 -0000

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

On Fri, Dec 18, 2015 at 12:23 PM, Nadeau Thomas 
wrote:

>
> On Dec 18, 2015:3:00 PM, at 3:00 PM, Andy Bierman 
> wrote:
>
>
>
> On Fri, Dec 18, 2015 at 11:49 AM, Nadeau Thomas 
> wrote:
>
>>
>> On Dec 18, 2015:11:06 AM, at 11:06 AM, Andy Bierman 
>> wrote:
>>
>>
>>
>> On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka  wrote:
>>
>>> Hi,
>>>
>>> if we want people to take YANG modules appearing in I-Ds seriously and
>>> implement them, then we should apply the revisioning rules to them. Tha=
t
>>> is, if a module changes between two I-D revisions, then its revision-da=
te
>>> has to be bumped and a new entry added to the revision history. As it i=
s
>>> now, the I-D-based modules are esentially revisionless.
>>>
>>>
>>
>> The revision rules only apply to published modules.
>> In IETF-speak, that means an RFC.  An Internet Draft
>> is a work-in-progress.  We update the revision date every time
>> the module changes, but the numerous incremental changes
>> for a work-in-progress should not be recorded in the module
>> revision history.  They should be recorded in the Change Log appendix.
>>
>> I will try to make this procedure more clear in the YANG guidelines draf=
t.
>>
>>
>> The question is one of =E2=80=9Cpublished=E2=80=9D.  So at the IETF that=
 means an RFC
>> today, but Lada makes a good point in that in our new rapid development
>> environment we may never get to RFCs for most of the models being worked
>> on today - or not for some time. If we want those I-Ds to be used in
>> production, it might make sense to define an I-D as =E2=80=9Cpublished=
=E2=80=9D.
>>
>> As I pointed out earlier, for other organizations, they have different
>> definitions of =E2=80=9Cpublished=E2=80=9D, so we should consider a more=
 flexible
>> definition of
>> =E2=80=9Cpublished=E2=80=9D to encompass those.  Its probably not a big =
deal to just say
>> something like, =E2=80=9Cother organizations that define models will def=
ine their
>> own definition of stable/published, and in those cases, that will
>> suffice as the threshold for a version and following the updating
>> rules described herein."
>>
>
>
> I think we should just try to focus on our own standards development
> process.
> Other organizations can adopt or reject IETF practices if they want.
> We are using the same definition of published for about 25 years.
> It means RFC in our process.  In a vendor environment, it means modules
> released to customers.
>
> We don't have a rapid development environment in the IETF.
> If people want to implement half-baked YANG modules, that is their
> business.
> They should be commended if they actually provide implementation feedback
> into the RFC, but a work-in-progress is not a published module.
>
>
> That isn=E2=80=99t the point; the rest of the Yang universe looks to the =
IETF
> to standardize and manage the Yang lanague and also looks here
> for rules or best practices on building modules.
>


I don't really understand the confusion here.
Modules under development change constantly.
Almost all the changes are illegal for published modules.

Each SDO has a concept of unfinished work and finished work.
It should be easy to understand that the change rules apply
to finished work.





> =E2=80=94Tom
>
>
>

Andy


>
>
>
>> =E2=80=94Tom
>>
>
>
> Andy
>
>
>>
>>
>>
>>
>>
>>
>>> Lada
>>>
>>>
>> Andy
>>
>>
>>
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>>
>
>

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




On Fri, Dec 18, 2015 at 12:23 PM, Nadeau Thomas <<=
a href=3D"mailto:tnadeau@lucidvision.com" target=3D"_blank">tnadeau@lucidvi=
sion.com> wrote:

On Dec =
18, 2015:3:00 PM, at 3:00 PM, Andy Bierman <andy@yumaworks.com> wrote:



On Fri, Dec 18, 2015 at 11:49 AM, Nadeau Thomas <=
tnadeau@lucidv=
ision.com> wrote:

On Dec =
18, 2015:11:06 AM, at 11:06 AM, Andy Bierman <andy@yumaworks.com> wrote:



On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka &=
lt;lhotka@nic.cz>=
 wrote:
Hi,



if we want people to take YANG modules appearing in I-Ds seriously and impl=
ement them, then we should apply the revisioning rules to them. That is, if=
 a module changes between two I-D revisions, then its revision-date has to =
be bumped and a new entry added to the revision history. As it is now, the =
I-D-based modules are esentially revisionless.




The revision rules only=
 apply to published modules.
In IETF-speak, that means an RFC.=C2=
=A0 An Internet Draft
is a work-in-progress.=C2=A0 We update the =
revision date every time
the module changes, but the numerous inc=
remental changes
for a work-in-progress should not be recorded in=
 the module
revision history.=C2=A0 They should be recorded in th=
e Change Log appendix.

I will try to make this pro=
cedure more clear in the YANG guidelines draft.

	The question is one of =E2=80=9Cpublished=E2=80=9D.=C2=A0 So at the IE=
TF that means an RFC
today, but Lada makes a good point in that i=
n our new rapid development
environment we may never get to RFCs =
for most of the models being worked
on today - or not for some ti=
me. If we want those I-Ds to be used in
production, it might make=
 sense to define an I-D as =E2=80=9Cpublished=E2=80=9D.

	As I pointed out earlier=
, for other organizations, they have different
definitions of =E2=
=80=9Cpublished=E2=80=9D, so we should consider a more flexible definition =
of
=E2=80=9Cpublished=E2=80=9D to encompass those.=C2=A0 Its prob=
ably not a big deal to just say
something like, =E2=80=9Cother or=
ganizations that define models will define their
own definition o=
f stable/published, and in those cases, that will=C2=A0
suffice a=
s the threshold for a version and following the updating
rules de=
scribed herein."

I think we should just try to focus on our own standards develo=
pment process.
Other organizations can adopt or reject IETF pract=
ices if they want.
We are using the same definition of published =
for about 25 years.
It means RFC in our process.=C2=A0 In a vendo=
r environment, it means modules
released to customers.
=

We don't have a rapid development environment in the IET=
F.
If people want to implement half-baked YANG modules, that is t=
heir business.
They should be commended if they actually provide =
implementation feedback
into the RFC, but a work-in-progress is n=
ot a published module.

<=
/div>
	That isn=E2=80=99t t=
he point; the rest of the Yang universe looks to the IETF
to stan=
dardize and manage the Yang lanague and also looks here
for rules=
 or best practices on building modules.=C2=A0


I don't really understand the confu=
sion here.
Modules under development change constantly.
Almost all the changes are illegal for published modules.

Each SDO has a concept of unfinished work and finished work.
=

It should be easy to understand that the change rules apply
=
to finished work.



=


	=E2=
=80=94Tom



<=
div>
Andy
=C2=A0
<=
div dir=3D"ltr">
=



	=E2=80=94Tom

=

Andy
=C2=A0




=C2=A0

Lada



Andy

=C2=A0

--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C









_______________________________________________

netmod mailing list

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




_______________________________________________
netmod mailing list
<=
a href=3D"mailto:netmod@ietf.org" target=3D"_blank">netmod@ietf.org
=
=
https://www.ietf.org/mailman/listinfo/netmod








--001a113c9c1206d038052732123e--


From nobody Fri Dec 18 12:56:17 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF711B38E2 for ; Fri, 18 Dec 2015 12:56:16 -0800 (PST)
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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 UBca6cFrYJto for ; Fri, 18 Dec 2015 12:56:14 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0103.outbound.protection.outlook.com [65.55.169.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 2EDC01B38EE for ; Fri, 18 Dec 2015 12:56:14 -0800 (PST)
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1444.namprd05.prod.outlook.com (10.160.117.153) with Microsoft SMTP Server (TLS) id 15.1.361.13; Fri, 18 Dec 2015 20:56:10 +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.0355.012; Fri, 18 Dec 2015 20:56:10 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder 
Thread-Topic: [netmod] review of draft-ietf-netmod-opstate-reqs-01
Thread-Index: AQHROPcUricDJu8Sk0yc8T/z1+bQc57PXaAAgAEEkoCAAIUYgA==
Date: Fri, 18 Dec 2015 20:56:10 +0000
Message-ID: 
References: <20151217181627.GB68858@elstar.local> <57D42158-C9B5-4CEE-959E-674EBB3EEA97@juniper.net> <20151218075947.GC70138@elstar.local>
In-Reply-To: <20151218075947.GC70138@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.151105
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.14]
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1444; 5:zlTVtl/hv9wBbcdZ870mwyw/xHnWBiUHGSDT1bI1wz6Bv4BcQ7rFk9qi1LBfC//HGVttzk5UD0Y41N+kb9RCnURaZmCY/60HZBXecyhjf1VpelYEIsRhvm/JYAxmCoWmFmOkK1uj9zHJ/RkMaEcYpQ==; 24:3tP1dHRNUiV1DakpLJ9JTnWLcbehyIF6m/Ua2WhH2/AN6lbSjE2ikb2ZHkY5ZUiVWWZVwhxkSE4rupl2YYNkRdXz000677JoM2zJ7WitwSg=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1444;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(8121501046)(5005006)(3002001)(10201501046); SRVR:BN3PR0501MB1444; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1444; 
x-forefront-prvs: 07943272E1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(199003)(164054003)(52314003)(189002)(479174004)(377454003)(2900100001)(189998001)(1220700001)(5004730100002)(87936001)(92566002)(36756003)(105586002)(11100500001)(102836003)(230783001)(122556002)(40100003)(3846002)(1096002)(2950100001)(586003)(10400500002)(6116002)(15975445007)(77096005)(5008740100001)(83716003)(19580395003)(50986999)(110136002)(99286002)(82746002)(106116001)(106356001)(5001960100002)(97736004)(4001350100001)(5002640100001)(76176999)(81156007)(101416001)(54356999)(86362001)(33656002)(66066001)(83506001)(19580405001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1444; 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:23
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: 18 Dec 2015 20:56:10.2820 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1444
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] review of draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 20:56:16 -0000

W0FzIGEgY29udHJpYnV0b3JdDQoNCkhpIEp1ZXJnZW4sDQoNCkkgYWdyZWUgd2l0aCB5b3UgdGhh
dCByZXEgIzUgc3RpY2tzIG91dCBhcyB0aGUgb2RkIGJhbGwgaW4gdGhlIGJ1bmNoLiAgSSBzdWdn
ZXN0ZWQgb25jZSB0byByZW1vdmUgaXQgYSBsb25nIHRpbWUgYmFjaywgYnV0IEkgZ3Vlc3MgaXQg
ZmVsbCBvbiBkZWFmIGVhcnMgdGhlbi4gIEFueXdheSwgZ2l2ZW4gd2hlcmUgd2UgYXJlIHdpdGgg
dGhpcyBkb2N1bWVudCwgSeKAmW0gdW5zdXJlIHdoYXQgdG8gZG8sIGJ1dCBoZXJlIGFyZSBvdXIg
b3B0aW9uczoNCg0KMS4gTGVhdmUgcmVxdWlyZW1lbnQgIzUgaW4gdGhlIGRvY3VtZW50LCBidXQg
c3BlbmQgdGltZSBpbXByb3ZpbmcgaXQgdG8gV0cgc2F0aXNmYWN0aW9uLg0KDQoyLiBUYWtlIHJl
cXVpcmVtZW50ICM1IG91dCwgZGVjbGFyaW5nIGl0IGFuIHVud2FudGVkIGRpc3RyYWN0aW9uIGZy
b20gdGhlIHByaW1hcnkgb3BzdGF0ZSBmb2N1cy4gIFdl4oCZZCBoYXZlIHRvIGJlIHN1cmUgdG8g
Z2V0IHNpZ24tb2ZmIGZyb20gdGhlIE9DIGZvbGtzIHRvby4uLg0KDQpTbyBmYXIgaXQgc291bmRz
IGxpa2UgSnVlcmdlbiBhbmQgSSBhcmUgd2l0aCAjMiwgaG93IGFib3V0IG90aGVycz8NCg0KVGhh
bmtzLA0KS2VudA0KDQoNCg0KDQoNCk9uIDEyLzE4LzE1LCAyOjU5IEFNLCAiSnVlcmdlbiBTY2hv
ZW53YWVsZGVyIiA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToN
Cg0KPk9uIFRodSwgRGVjIDE3LCAyMDE1IGF0IDA5OjI3OjEyUE0gKzAwMDAsIEtlbnQgV2F0c2Vu
IHdyb3RlOg0KPj4gW0FzIGEgY29udHJpYnV0b3JdDQo+PiANCj4+IFRoYW5rIHlvdSBmb3IgdGhl
IHJldmlldyBKdWVyZ2VuLg0KPj4gDQo+PiBHcmVhdCBzdWdnZXN0aW9ucy4gIElmIG5vIG9uZSBv
YmplY3RzLCBJ4oCZbGwgaW5jb3Jwb3JhdGUgdGhlbSBpbnRvIHRoZSBuZXh0IHJldmlzaW9uIG9m
IHRoZSBkb2N1bWVudCBhZnRlciBsYXN0IGNhbGwuDQo+PiANCj4+IE15IG9uZSBjb21tZW50IGlz
IHRoYXQgSSBkb27igJl0IGJlbGlldmUgdGhlIGRvY3VtZW50IGlzIGxpbWl0ZWQgdG8gdGhlIGlu
dHJvZHVjdGlvbiBvZiBhcHBsaWVkIGNvbmZpZ3VyYXRpb24uIEZvciBpbnN0YW5jZSwgdGhlIHJl
bGF0aW5nIG9mIGNvbmZpZyB0byBkZXJpdmVkIHN0YXRlIGFuZCBhbHNvIHRoZSBtb2RlbCBzdHJ1
Y3R1cmUgcmVxdWlyZW1lbnQgYXJlIG5vdCByZWxhdGVkIHRvIGFwcGxpZWQgY29uZmlnLiAgSW4g
YWxsIGZhaXJuZXNzLCBSZXF1aXJlbWVudCAjNSAobW9kZWwgc3RydWN0dXJlKSBpc27igJl0IGV2
ZW4gYWJvdXQgb3BlcmF0aW9uYWwgc3RhdGUuDQo+DQo+UmVhZGluZyAjNSBhZ2FpbiBJIG11c3Qg
YWRtaXQgdGhhdCBJIGRvIG5vdCByZWFsbHkgdW5kZXJzdGFuZCB3aGF0DQo+dGhpcyByZXF1aXJl
bWVudCB0cmllcyB0byBhY2NvbXBsaXNoOg0KPg0KPiAgIDUuICBBYmlsaXR5IGZvciBkaXN0aW5j
dCBtb2R1bGVzIHRvIGxldmVyYWdlIGEgY29tbW9uIG1vZGVsLXN0cnVjdHVyZQ0KPg0KPiAgICAg
ICBBLiAgRm9jdXMgb24gdGhlIElFVEYtZGVmaW5lZCBtb2R1bGVzLCBhbmQgaWRlYWxseSBwcm92
aWRlcw0KPiAgICAgICAgICAgZ3VpZGFuY2UgdG8gb3RoZXIgU0RPcw0KPg0KPiAgICAgICBCLiAg
TXVsdGlwbGUgZG9tYWluLXNwZWNpZmljIG1vZGVsLXN0cnVjdHVyZSB0cmVlcyBhcmUgb2theQ0K
Pg0KPiAgICAgICBDLiAgTW9kZWwtc3RydWN0dXJlcyBtYXkgYmUgZGVmaW5lZCBpbiBtdWx0aXBs
ZSBtb2R1bGVzIHdpdGgNCj4gICAgICAgICAgIGRpc3RpbmN0IG5hbWVzcGFjZXMNCj4NCj5BdCB0
aGlzIGxldmVsIG9mIGFic3RyYWN0aW9uLCAjNSByZWFsbHkgZG9lcyBub3QgbWVhbiBhbnl0aGlu
ZyBvciBODQo+cGVvcGxlIHdpbGwgaGF2ZSBhdCBsZWFzdCBOIGRpZmZlcmVudCBpbnRlcnByZXRh
dGlvbnMgb2YgaXQuIEkNCj5hY3R1YWxseSB0aGluayB0aGlzIHNob3VsZCBiZSB0YWtlbiBvdXQg
YW5kIG1vdmVkIGludG8gYSBkaWZmZXJlbnQNCj5kb2N1bWVudCBhbmQgdGhlbiBpdCByZXF1aXJl
cyB0byBiZSBkZXZlbG9wZWQgaW50byBzb21ldGhpbmcgbXVjaCBtb3JlDQo+Y29uY3JldGUuDQo+
DQo+L2pzDQo+DQo+PiBTbyB5b3VyIHRpdGxlIGFuZCBhYnN0cmFjdCBzdWdnZXN0aW9ucyBtaWdo
dCBkZWZpbmUgdG9vIG5hcnJvdyBhIHNjb3BlLiAgU28gaG93IGFib3V0Og0KPj4gDQo+PiBUaXRs
ZTogVGVybWlub2xvZ3kgYW5kIFJlcXVpcmVtZW50cyBmb3IgT3BlcmF0aW9uYWwgU3RhdGUgYW5k
IE1vZGVsIFN0cnVjdHVyZQ0KPj4NCj4+IEFic3RyYWN0Og0KPj4gICAgICBUaGlzIGRvY3VtZW50
IGRlZmluZXMgcmVxdWlyZW1lbnRzIGZvciBlbmhhbmNpbmcgdGhlIHN1cHBvcnQNCj4+ICAgICAg
b2Ygb3BlcmF0aW9uYWwgc3RhdGUgdGhyb3VnaCB0aGUgaW50cm9kdWN0aW9uIG9mIGEgY29uY2Vw
dHVhbA0KPj4gICAgICAiYXBwbGllZCBjb25maWd1cmF0aW9uIi4gIFRoZSBkb2N1bWVudCBhbHNv
IGRlZmluZXMgcmVxdWlyZW1lbnRzDQo+PiAgICAgIGVuYWJsaW5nIGRpc3RpbmN0IG1vZHVsZXMg
dG8gbGV2ZXJhZ2UgYSBjb21tb24gbW9kZWwgc3RydWN0dXJlLg0KPj4gDQo+PiDigKZhbmQgYWRk
IGFuIEludHJvZHVjdGlvbiBzZWN0aW9uIHRoYXQgZXhwYW5kcyBvbiB0aGlzIHRoZW1lIGZ1cnRo
ZXI/DQo+DQo+SSB0aGluayB0aGlzIGlzIGdldHRpbmcgaW50byB0aGUgd3JvbmcgZGlyZWN0aW9u
IGFuZCBhcyBleHBsYWluZWQNCj5hYm92ZSAjNSBpcyBieSBmYXIgdW5kZXJzcGVjaWZpZWQgdG8g
YmUgb2YgYW55IHZhbHVlLiBJIHN1Z2dlc3QgdG8NCj50YWtlIGl0IG91dCBzbyB0aGF0IHdlIGNh
biBwdWJsaXNoIHRoZSByZXN0IGluIGEgdGltZWx5IG1hbm5lci4gVGhlDQo+YWx0ZXJuYXRpdmUg
aXMgdG8gaG9sZCBvZmYgdGhpcyBkb2N1bWVudCBpbiBhbiBhdHRlbXB0IHRvIHJlcGxhY2UgIzUN
Cj53aXRoIHNvbWV0aGluZyB0aGF0IGlzIGNvbmNyZXRlIGFuZCBhY3Rpb25hYmxlLg0KPg0KPi9q
cw0KPg0KPi0tIA0KPkp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZl
cnNpdHkgQnJlbWVuIGdHbWJIDQo+UGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1w
dXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPkZheDogICArNDkgNDIxIDIwMCAz
MTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0K


From nobody Fri Dec 18 13:09:03 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AF51B390A for ; Fri, 18 Dec 2015 13:09:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 AAyLWljjnLOh for ; Fri, 18 Dec 2015 13:09:01 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDED1B3909 for ; Fri, 18 Dec 2015 13:09:01 -0800 (PST)
Received: from stubbs.local.chopps.org (75-128-113-61.dhcp.aldl.mi.charter.com [75.128.113.61]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 8793A60A89; Fri, 18 Dec 2015 21:09:00 +0000 (UTC)
References: <7E169FEA-ABF9-4B3F-BB86-A3D3B900741A@nic.cz>  <20151218.194526.1877280801898778625.mbj@tail-f.com>  
User-agent: mu4e 0.9.15; emacs 24.5.1
From: Christian Hopps 
To: Andy Bierman 
In-reply-to: 
Date: Fri, 18 Dec 2015 16:08:59 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 21:09:03 -0000

--=-=-=
Content-Type: text/plain


Andy Bierman  writes:

> On Fri, Dec 18, 2015 at 11:11 AM, Christian Hopps  wrote:
>
>>
>> Martin Bjorklund  writes:
>>
>> > Christian Hopps  wrote:
>> >>
>> >>
>> >> Versioning has come up in previous conversations I've been a part of,
>> >> and I was led to believe that it does not really exist for yang
>> >> modules. That is, if you update a published module it's a completely new
>> >> model with no-expectation of compatibility with previous models.
>> >
>> > Please see section 10 of RFC 6020.
>>
>> Ok, so I either misunderstood, or was misled. :)
>>
>> So my reading of section 10 is that a new revision is the "bump the
>> minor" action, and a new module is required for "bump the major".
>>
>>
>
> There are no major or minor revision numbers in YANG.
> There are on revision date strings YYYY-MM-DD.

I thought that was the point I was making (the ""s being a reference
to my earlier mail), sorry for being confusing.

Chris.


>
>
>
>> Thanks,
>> Chris.
>>
>>
> Andy
>
>
>>
>> >
>> >> Is it the case that there's no way to "bump the minor version" of a
>> >> model (i.e., you make only additions, but no deletions or changes to
>> >> meaning so that the model can be considered backward compatible)?
>> >
>> > All rules in section 10 of RFC 6020 are backwards compatible.
>> >
>> > Also note that you can deprecate and obsolete nodes and define new
>> > nodes in the same module.
>> >
>> >
>> >
>> > /martin
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>


--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWdHXrAAoJEC4dgw7XuDAlfVgP/1A8Qy/0OaHUf4Etz1LysF6w
K6iBik9jIli2dksp5GJ+ft3sjHJwPAd2r6Lk41HqUicr6R7stgKzC/QfjY77z9eV
sZ3ExABFOCOx0IVCg9MiwhFaZXS/1jHXxxAxF+NWxCKu3agGpKlXep+SpET3yg65
Vt9f8TMWrMf77uH94+7lXy7FFAt8HKb5DN48WZTCeiIBycJ65YxpMH+c3J03a05O
DGrenBAxUtgO4EIp0oAOl05MKBqEWaBlZ18xUR2gAnvhb7VVe4LLnSJvbkqSFtPM
KQw39zxEtymJcveVuAHLicTKlrjVTtev6UKDzkC1/fwa4hGIC5z6W0EKYKtB30nf
lrF53ZiJGGC2X1RM4/ciHA2i5XRMJ0RnKzitMf4vhwaPABfgqTKWLNBne29XDEMk
/+mh8x/jYFYiHWdpDDdEfzUyVlVxXg/pfcde3H5RCSyoCxwxzQhI9X9V/FSeS2bx
tOTxQ/tVRf6CCH5Khc6IE2x0MYlWZjVwgJmrSF44rpamHYi9jiAD0Zbb6E1WN7cw
WZtBd+rbSo/zX1qVZB1R295MGjA/KbLh44ATPoH1fAbRkslZt2U+/uNT08VXQQ2K
VrZRiFky+fIj1N0S12JREGc3b9uK4YJS/pyraxpcLEJRg1eJD95rPMSKBK6Bhnfj
Jl+Jc4hxZ1bcVn8hR+Fm
=51uJ
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Fri Dec 18 13:37:38 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A78A41B392E for ; Fri, 18 Dec 2015 13:37:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 8wxZqE5a5WB3 for ; Fri, 18 Dec 2015 13:37:35 -0800 (PST)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 479831B392B for ; Fri, 18 Dec 2015 13:37:35 -0800 (PST)
Received: by mail-lf0-x22c.google.com with SMTP id z124so75841546lfa.3 for ; Fri, 18 Dec 2015 13:37:35 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=l0xioa0PoyuJTKaBFPon94XgIJacb/VyMxp/uQmN40k=; b=E37l+rX1dhOyeHq6EIKo6hpVDyhWrd509W6aDojQ+LaP46lli6jRYQyu+A5dPX0PsI wRQfEvL95vjE/0Qo+5Wf1EQDrqIX/FqwuBxdZy44IFySwJP5hqQ13k1mdUuWc/AGzSbZ hCrze3BA8nj0hTDj6FB7wJ/kvj7lsbu4Ygs9qqtMVeWON+2c82t9lFBpjsj5W/I3JEYv rv1rLt1zPGSks2enjPDBudMOFAO7Osx6pEzBbTPYt4JMDsMF//rIwPm1SJ/7r1F3JsgA 8raO/XjNCCYb2mU/SmKeOar6OgmZw7BTVfv0btc/ruPEk2FTxw4MHsby5H+ZJ7Roxxux 2cWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=l0xioa0PoyuJTKaBFPon94XgIJacb/VyMxp/uQmN40k=; b=Xj+ZP1t7JmGbhe67Eka+6aHk7idTs32EyOJUvz/3PZLZ4AKKARKYRfps2CVY8RUkOy PxhMIL0f/81IkaWQyem1g8AUQj3CQhHZjv+Q0qzXM/xm1MQ8msm22M9fUjpybpso2AcJ 8J4Uu8aioUyy2GVw0ssnTx7elf4nQlv9FM2KXGIHnhe5GtE7cH6l9ylS1LL9ig1E4qE7 j3fSCAOH6csqMnt0d6FQ3148ByBOG3eBBD6yx83vQDu9N68cbuISY1T1hx53ZIoe2Try QWg7dPoTnyj8erlO1DZNmC6soRnn0TuF+mFdxLtzfGZS4r/fgdc5tkjwPXKkasxjGoSp tj3w==
X-Gm-Message-State: ALoCoQluVg4NsH8WUhAcbH+Ex3zza82Wd/R3taZtaGxsxAmHp0AVRPV5tGVYNujyhmF0IIrPunCZ+j1SxrhU8UFTJq38Vd39hw==
MIME-Version: 1.0
X-Received: by 10.25.64.9 with SMTP id n9mr2292808lfa.13.1450474653354; Fri, 18 Dec 2015 13:37:33 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Fri, 18 Dec 2015 13:37:33 -0800 (PST)
In-Reply-To: 
References: <7E169FEA-ABF9-4B3F-BB86-A3D3B900741A@nic.cz>  <20151218.194526.1877280801898778625.mbj@tail-f.com>   
Date: Fri, 18 Dec 2015 13:37:33 -0800
Message-ID: 
From: Andy Bierman 
To: Christian Hopps 
Content-Type: multipart/alternative; boundary=001a113ea4f6782c55052732f27b
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 21:37:37 -0000

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

On Fri, Dec 18, 2015 at 1:08 PM, Christian Hopps  wrote:

>
> Andy Bierman  writes:
>
> > On Fri, Dec 18, 2015 at 11:11 AM, Christian Hopps 
> wrote:
> >
> >>
> >> Martin Bjorklund  writes:
> >>
> >> > Christian Hopps  wrote:
> >> >>
> >> >>
> >> >> Versioning has come up in previous conversations I've been a part of,
> >> >> and I was led to believe that it does not really exist for yang
> >> >> modules. That is, if you update a published module it's a completely
> new
> >> >> model with no-expectation of compatibility with previous models.
> >> >
> >> > Please see section 10 of RFC 6020.
> >>
> >> Ok, so I either misunderstood, or was misled. :)
> >>
> >> So my reading of section 10 is that a new revision is the "bump the
> >> minor" action, and a new module is required for "bump the major".
> >>
> >>
> >
> > There are no major or minor revision numbers in YANG.
> > There are on revision date strings YYYY-MM-DD.
>
> I thought that was the point I was making (the ""s being a reference
> to my earlier mail), sorry for being confusing.
>
>

YANG is a bit confusing, because it is not code, even though
we use it that way.  Major revisions do not exist because major changes
are simply not allowed to existing definitions.  You introduce new
definitions
to make major changes.  This can be in the same module or a new module.





> Chris.
>
>
Andy


>
> >
> >
> >
> >> Thanks,
> >> Chris.
> >>
> >>
> > Andy
> >
> >
> >>
> >> >
> >> >> Is it the case that there's no way to "bump the minor version" of a
> >> >> model (i.e., you make only additions, but no deletions or changes to
> >> >> meaning so that the model can be considered backward compatible)?
> >> >
> >> > All rules in section 10 of RFC 6020 are backwards compatible.
> >> >
> >> > Also note that you can deprecate and obsolete nodes and define new
> >> > nodes in the same module.
> >> >
> >> >
> >> >
> >> > /martin
> >>
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >>
> >>
>
>

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




On Fri, Dec 18, 2015 at 1:08 PM, Christian Hopps <=
chopps@chopps.org> wrote:


Andy Bierman <andy@yumaworks.com> writes:



> On Fri, Dec 18, 2015 at 11:11 AM, Christian Hopps <chopps@chopps.org> wrote:

>

>>

>> Martin Bjorklund <mbj@tail-f.=
com> writes:

>>

>> > Christian Hopps <chop=
ps@chopps.org> wrote:

>> >>

>> >>

>> >> Versioning has come up in previous conversations I've=
 been a part of,

>> >> and I was led to believe that it does not really exist fo=
r yang

>> >> modules. That is, if you update a published module it'=
;s a completely new

>> >> model with no-expectation of compatibility with previous =
models.

>> >

>> > Please see section 10 of RFC 6020.

>>

>> Ok, so I either misunderstood, or was misled. :)

>>

>> So my reading of section 10 is that a new revision is the "bu=
mp the

>> minor" action, and a new module is required for "bump th=
e major".

>>

>>

>

> There are no major or minor revision numbers in YANG.

> There are on revision date strings YYYY-MM-DD.



I thought that was the point I was making (the ""s being a refere=
nce

to my earlier mail), sorry for being confusing.




YANG is a bit confusing=
, because it is not code, even though
we use it that way.=C2=A0 M=
ajor revisions do not exist because major changes
are simply not =
allowed to existing definitions.=C2=A0 You introduce new definitions
<=
div>to make major changes.=C2=A0 This can be in the same module or a new mo=
dule.



=C2=A0

Chris.



Andy
=C2=A0



>

>

>

>> Thanks,

>> Chris.

>>

>>

> Andy

>

>

>>

>> >

>> >> Is it the case that there's no way to "bump the =
minor version" of a

>> >> model (i.e., you make only additions, but no deletions or=
 changes to

>> >> meaning so that the model can be considered backward comp=
atible)?

>> >

>> > All rules in section 10 of RFC 6020 are backwards compatible.=


>> >

>> > Also note that you can deprecate and obsolete nodes and defin=
e new

>> > nodes in the same module.

>> >

>> >

>> >

>> > /martin

>>

>>

>> _______________________________________________

>> netmod mailing list

>> netmod@ietf.org

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

>>

>>







--001a113ea4f6782c55052732f27b--


From nobody Fri Dec 18 14:21:16 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF581B397F; Fri, 18 Dec 2015 14:21:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level: 
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 Q7lkxb2tk53N; Fri, 18 Dec 2015 14:21:13 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 2497C1B396F; Fri, 18 Dec 2015 14:21:12 -0800 (PST)
Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id EF52587499F45; Fri, 18 Dec 2015 22:21:05 +0000 (GMT)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id tBIML8Mq002547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Dec 2015 22:21:08 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.182]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Fri, 18 Dec 2015 17:21:08 -0500
From: "Sterne, Jason (Jason)" 
To: Nadeau Thomas , Lear Eliot 
Thread-Topic: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06
Thread-Index: AQHROOMhYo4meG2BX0KJKHcnXKZDjJ7RUPOQ
Date: Fri, 18 Dec 2015 22:21:07 +0000
Message-ID: 
References:  <5672BAD7.2080003@cisco.com> <1B2DACE1-A8F0-493B-8B61-EF6321790ECE@lucidvision.com> <5672CA38.4060709@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.5.27.17]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: Benoit Claise , RTG YANG Design Team , netmod WG 
Subject: Re: [netmod] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 22:21:15 -0000

SSdtIG5vdCBhIGZhbiBvZiBhZGRpbmcgc29tZXRoaW5nIGxpa2UgdGhhdCBpbiB0aGUgYmFzZSBt
b2RlbC4gIExldCdzIGdldCBhIGJhc2ljIG1vZGVsIGRvbmUgYW5kIHRoZW4gd2UgY2FuIGNvbnNp
ZGVyIGFuIGV4dGVuc2lvbiBkcmFmdC4gIEknZCB0aGluayB0aGF0IHRoaW5ncyBsaWtlIFRDUCBm
bGFncywgZm9yIGV4YW1wbGUsIHdvdWxkIGJlIGEgbW9yZSBuYXR1cmFsICYgY29tbW9uIHRoaW5n
IHRvIGFkZCB0byBhbiBBQ0wgbW9kZWwgdGhhbiBhIGhvc3QgbmFtZSBtYXRjaCBzbyBJIGNhbid0
IHNlZSBob3N0IG5hbWUgYmVpbmcgaW4gdGhlcmUgYmVmb3JlIFRDUCBmbGFncyAod2hpY2ggSSdt
IG5vdCBhZHZvY2F0aW5nIGZvciBpbiB0aGUgYmFzZSBtb2RlbCkuDQoNCkkgYWxzbyBkb24ndCB0
aGluayB0aGUgbWV0YWRhdGEgaW50ZXJmYWNlIG1hdGNoIHNob3VsZCBiZSBpbiB0aGlzIGJhc2Ug
bW9kZWwgZWl0aGVyLiAgVGhhdCBpcyBvdXQgb2YgcGxhY2UgSU1PLiAgVGhlIGJhc2UgbW9kZWwg
cHJvdmlkZXMgYW4gQUNMIHRoYXQgY2FuIHRoZW4gZ2V0IGFzc29jaWF0ZWQgd2l0aCBvYmplY3Rz
IGxpa2UgaW50ZXJmYWNlcyAoYXMgaW4gdGhlIGV4YW1wbGUgaW4gc2VjdGlvbiBBLjMpLg0KDQpJ
J2QgYWxzbyBzdWdnZXN0IHdlIGNvbnNpZGVyIG1ha2luZyB0aGUgYWN0aW9ucyAnZGVueScgYW5k
ICdwZXJtaXQnIHByZXNlbmNlIGNvbnRhaW5lcnMgaW5zdGVhZCBvZiBlbXB0eSBsZWFmcy4gIFRo
YXQgd291bGQgYWxsb3cgZWFzaWVyIGF1Z21lbnRhdGlvbnMgKGUuZy4gYWRkaXRpb25hbCAncGVy
bWl0JyBwYXJhbWV0ZXJzIGZvciBwb2xpY3kgYmFzZWQgZm9yd2FyZGluZyBmb3IgZXhhbXBsZSku
DQoNClJlZ2FyZHMsDQpKYXNvbg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog
bmV0bW9kIFttYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBOYWRl
YXUgVGhvbWFzDQpTZW50OiBUaHVyc2RheSwgRGVjZW1iZXIgMTcsIDIwMTUgMTA6NTMNClRvOiBM
ZWFyIEVsaW90DQpDYzogQmVub2l0IENsYWlzZTsgUlRHIFlBTkcgRGVzaWduIFRlYW07IG5ldG1v
ZCBXRw0KU3ViamVjdDogUmU6IFtuZXRtb2RdIFdvcmtpbmcgZ3JvdXAgTGFzdCBDYWxsOiBkcmFm
dC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMDYNCg0KDQoJWW91IHJhaXNlIGEgZ29vZCBwb2ludC4g
RG8gdGhlIGNvbnRyaWJ1dG9ycy9lZGl0b3JzIGhhdmUgYW55IHRob3VnaHRzIG9uIHRoaXMgc3Vn
Z2VzdGlvbj8NCg0KCeKAlFRvbQ0KDQoNCj4gT24gRGVjIDE3LCAyMDE1Ojk6NDQgQU0sIGF0IDk6
NDQgQU0sIEVsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPiB3cm90ZToNCj4gDQo+IA0KPiANCj4g
T24gMTIvMTcvMTUgMjo0NSBQTSwgTmFkZWF1IFRob21hcyB3cm90ZToNCj4+IAlEbyB5b3UgbWVh
biBhbiBBU0NJSSBETlMgbmFtZSAodmVyc3VzIGFuIElQIGFkZHJlc3MgdyBhIG1hc2spPw0KPiAN
Cj4gSSB3YXMgdGhpbmtpbmcgb2YgImhvc3QiIGluIFJGQyA2MDIxLg0KPiANCj4gRWxpb3QNCj4g
DQo+IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K
bmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0K


From nobody Fri Dec 18 15:02:15 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9236D1A000B for ; Fri, 18 Dec 2015 15:02:13 -0800 (PST)
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, SPF_PASS=-0.001] autolearn=unavailable
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 ca7HDxF2piDu for ; Fri, 18 Dec 2015 15:02:12 -0800 (PST)
Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::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 091AA1B39C2 for ; Fri, 18 Dec 2015 14:54:20 -0800 (PST)
Received: by mail-pa0-x22d.google.com with SMTP id wq6so67035252pac.1 for ; Fri, 18 Dec 2015 14:54:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=wQzvrqTcTJiz2QLk7p2Bftt24m3ebvzemHL8c4lpK9M=; b=HFS14tWj7Z+lTnjy3vHimGi4rnHHSyaPPz5O96/fLT1LCNcD4ivlngalLa49Pa5sdm QelCYxTQ9ssSNz940WLOKN0b+KrroUg7Sxlo7gqmiKxMhhu5XkPWU1ZQbi1js9UuIOVW Z4x5E5EPygn1mchCiih9ftSHNtvhB7gmnNqZFYunEznyMvZ5RejqNXsMUuYCmgcV6XoZ u8+A1pSBy+GWdF2niKF6INCior2QdXft9XaAZNJiosKl2JxvfBFOkwmmCaffLgIhReK3 tlPAUPKhUDYawyALMerdAsAK8OGJiP4qeQDy+nV3i9zjbsovwMB749ndrIn9aD41Q/EJ Ai1g==
X-Received: by 10.66.251.193 with SMTP id zm1mr8817563pac.154.1450479258861; Fri, 18 Dec 2015 14:54:18 -0800 (PST)
Received: from ?IPv6:2001:420:c0c8:1007::383? ([2001:420:c0c8:1007::383]) by smtp.gmail.com with ESMTPSA id t73sm19927004pfi.26.2015.12.18.14.54.17 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 18 Dec 2015 14:54:17 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_F504A339-6081-4F87-BF0C-EADAFAEA3CCD"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Mahesh Jethanandani 
In-Reply-To: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net>
Date: Fri, 18 Dec 2015 14:54:16 -0800
Message-Id: <3B602BC3-50DE-4F37-83E7-255DB7E475B1@gmail.com>
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net>
To: Randy Presuhn 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 23:02:13 -0000

--Apple-Mail=_F504A339-6081-4F87-BF0C-EADAFAEA3CCD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Agree with Andy and Randy.

> On Dec 17, 2015, at 3:45 PM, Randy Presuhn =
 wrote:
>=20
> Hi -
>=20
>> From: Robert Wilton
>> Sent: Dec 17, 2015 1:12 PM
>> To: Andy Bierman
>> Cc: "netmod@ietf.org"
>> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
> ...
>>    Your requirement is a bit too strong for my liking.
>>=20
>>    To paraphrase your requirement text, it is forcing that all
>>    compliant NETCONF/RESTCONF servers MUST support any clients that =
do
>>    not want to differentiate between intended config and applied
>>    config.
>=20
> Do do otherwise sound to me like an interoperability disaster,
> and would encourage the "siloization" of toolsets.
>=20
>>    However, this requires all opstate aware servers:
>>=20
>>     - To handle a mix of clients, some of which are opstate aware, =
and
>>     some that are not.
>=20
> This seems perfectly reasonable.  To do otherwise torpedoes the very
> notion of interoperability.
>=20
>>     - To potentially handle a mix of requests, some of which are
>>     opstate aware requests, and some are not.
>=20
> Ditto.=20
>=20
>>    It also prevents:
>>=20
>>     - Having a server that is implemented to only support opstate =
aware
>>     clients.
>=20
> Avoiding the creation of such servers sounds like a *good* thing to =
me.
>=20
>>     - Having a server side configuration knob to control the =
behaviour
>>     (since it would affect the semantics for all clients).
>=20
> This also sounds like something which it would be desireable to =
prevent.   =20
>=20
> I think I'm squarely with Andy on this one.
>=20
> Randy
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com






--Apple-Mail=_F504A339-6081-4F87-BF0C-EADAFAEA3CCD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Agree with Andy and Randy.

On =
Dec 17, 2015, at 3:45 PM, Randy Presuhn <randy_presuhn@mindspring.com> wrote:

Hi -
From: Robert Wilton
Sent: Dec 17, 2015 1:12 PM
To: Andy Bierman
Cc: "netmod@ietf.org"
Subject: Re: [netmod] =
NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
...
    Your requirement is a bit too strong for =
my liking.

    To paraphrase =
your requirement text, it is forcing that all
 =
   compliant NETCONF/RESTCONF servers MUST support any =
clients that do
    not want to =
differentiate between intended config and applied
 =
   config.

Do =
do otherwise sound to me like an interoperability disaster,
and would encourage the "siloization" of toolsets.

 =
   However, this requires all opstate aware servers:

     - To handle a mix of =
clients, some of which are opstate aware, and
 =
    some that are not.

This seems perfectly reasonable.  To do otherwise =
torpedoes the very
notion of interoperability.

 =
    - To potentially handle a mix of requests, some =
of which are
     opstate aware =
requests, and some are not.

Ditto. 

    It also prevents:

     - Having a server that is =
implemented to only support opstate aware
 =
    clients.

Avoiding the creation of such servers sounds like a *good* =
thing to me.

     - Having a server side configuration =
knob to control the behaviour
 =
    (since it would affect the semantics for all =
clients).

This also sounds =
like something which it would be desireable to prevent. =
   

I think I'm squarely =
with Andy on this one.

Randy

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



Mahesh Jethanandani
mjethanandani@gmail.com








=

--Apple-Mail=_F504A339-6081-4F87-BF0C-EADAFAEA3CCD--


From nobody Fri Dec 18 15:13:24 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFD311A0033 for ; Fri, 18 Dec 2015 15:13:22 -0800 (PST)
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, SPF_PASS=-0.001] autolearn=ham
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 lY3Gvqt4Qxhp for ; Fri, 18 Dec 2015 15:13:20 -0800 (PST)
Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 4EF1B1A0032 for ; Fri, 18 Dec 2015 15:13:20 -0800 (PST)
Received: by mail-pf0-x230.google.com with SMTP id n128so38264776pfn.0 for ; Fri, 18 Dec 2015 15:13:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ZRfI27iNs+2KomSciBnQVZOyzwc5vTj4d6QZKPviKnM=; b=BQB2egNp/WmrT6NyKgxJFEuYCHs+vAPO3R1ePeo/ibcb535hcqqpEsyVrVGISv0D+X 5Zfttg5OjHYtWhTYlDabisWT4eFwpNYMrDgil3AFcq7PXfYaz2uwpPEUcVpTxroZqzJ6 zhmP0kg+xJXUwuStIUhvuHdfE3v8BsRhrIQoBHcPY8+v0zmQ+N/WB5GfhCvUy5zW3nSB 0o8L015jCpBsY+US9ylGoZhMTNxalZowNgnWoAQvJXk3IkSiE3364l3JFVCc2Sxc5db3 LZp3J01fHk84c1ylosOah0gn6olSU4pX25SWL/R47f92D8VJnhYJ4pq/z+lT1NIaEyhV PDUA==
X-Received: by 10.98.13.16 with SMTP id v16mr9013073pfi.129.1450480399755; Fri, 18 Dec 2015 15:13:19 -0800 (PST)
Received: from ?IPv6:2001:420:c0c8:1007::383? ([2001:420:c0c8:1007::383]) by smtp.gmail.com with ESMTPSA id y27sm19955484pfa.29.2015.12.18.15.13.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 18 Dec 2015 15:13:19 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_B1C7BB64-4702-48A3-A832-74FD84AB5F6E"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Mahesh Jethanandani 
In-Reply-To: 
Date: Fri, 18 Dec 2015 15:13:18 -0800
Message-Id: 
References: <20151217181627.GB68858@elstar.local> <57D42158-C9B5-4CEE-959E-674EBB3EEA97@juniper.net> <20151218075947.GC70138@elstar.local> 
To: Kent Watsen 
X-Mailer: Apple Mail (2.2104)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] review of draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 18 Dec 2015 23:13:22 -0000

--Apple-Mail=_B1C7BB64-4702-48A3-A832-74FD84AB5F6E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

My preference would also be to leave #5 out.=20

> On Dec 18, 2015, at 12:56 PM, Kent Watsen  wrote:
>=20
> [As a contributor]
>=20
> Hi Juergen,
>=20
> I agree with you that req #5 sticks out as the odd ball in the bunch.  =
I suggested once to remove it a long time back, but I guess it fell on =
deaf ears then.  Anyway, given where we are with this document, I=E2=80=99=
m unsure what to do, but here are our options:
>=20
> 1. Leave requirement #5 in the document, but spend time improving it =
to WG satisfaction.
>=20
> 2. Take requirement #5 out, declaring it an unwanted distraction from =
the primary opstate focus.  We=E2=80=99d have to be sure to get sign-off =
from the OC folks too...
>=20
> So far it sounds like Juergen and I are with #2, how about others?
>=20
> Thanks,
> Kent
>=20
>=20
>=20
>=20
>=20
> On 12/18/15, 2:59 AM, "Juergen Schoenwaelder" =
 wrote:
>=20
>> On Thu, Dec 17, 2015 at 09:27:12PM +0000, Kent Watsen wrote:
>>> [As a contributor]
>>>=20
>>> Thank you for the review Juergen.
>>>=20
>>> Great suggestions.  If no one objects, I=E2=80=99ll incorporate them =
into the next revision of the document after last call.
>>>=20
>>> My one comment is that I don=E2=80=99t believe the document is =
limited to the introduction of applied configuration. For instance, the =
relating of config to derived state and also the model structure =
requirement are not related to applied config.  In all fairness, =
Requirement #5 (model structure) isn=E2=80=99t even about operational =
state.
>>=20
>> Reading #5 again I must admit that I do not really understand what
>> this requirement tries to accomplish:
>>=20
>>  5.  Ability for distinct modules to leverage a common =
model-structure
>>=20
>>      A.  Focus on the IETF-defined modules, and ideally provides
>>          guidance to other SDOs
>>=20
>>      B.  Multiple domain-specific model-structure trees are okay
>>=20
>>      C.  Model-structures may be defined in multiple modules with
>>          distinct namespaces
>>=20
>> At this level of abstraction, #5 really does not mean anything or N
>> people will have at least N different interpretations of it. I
>> actually think this should be taken out and moved into a different
>> document and then it requires to be developed into something much =
more
>> concrete.
>>=20
>> /js
>>=20
>>> So your title and abstract suggestions might define too narrow a =
scope.  So how about:
>>>=20
>>> Title: Terminology and Requirements for Operational State and Model =
Structure
>>>=20
>>> Abstract:
>>>     This document defines requirements for enhancing the support
>>>     of operational state through the introduction of a conceptual
>>>     "applied configuration".  The document also defines requirements
>>>     enabling distinct modules to leverage a common model structure.
>>>=20
>>> =E2=80=A6and add an Introduction section that expands on this theme =
further?
>>=20
>> I think this is getting into the wrong direction and as explained
>> above #5 is by far underspecified to be of any value. I suggest to
>> take it out so that we can publish the rest in a timely manner. The
>> alternative is to hold off this document in an attempt to replace #5
>> with something that is concrete and actionable.
>>=20
>> /js
>>=20
>> --=20
>> 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

Mahesh Jethanandani
mjethanandani@gmail.com






--Apple-Mail=_B1C7BB64-4702-48A3-A832-74FD84AB5F6E
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

My preference would also be to leave #5 out. 

On Dec 18, 2015, at 12:56 PM, Kent Watsen <kwatsen@juniper.net>=
 wrote:

[As =
a contributor]

Hi Juergen,

I agree with you that req #5 sticks out as the odd ball in =
the bunch.  I suggested once to remove it a long time back, but I =
guess it fell on deaf ears then.  Anyway, given where we are with =
this document, I=E2=80=99m unsure what to do, but here are our =
options:

1. Leave requirement #5 in the =
document, but spend time improving it to WG satisfaction.

2. Take requirement #5 out, declaring it an =
unwanted distraction from the primary opstate focus.  We=E2=80=99d =
have to be sure to get sign-off from the OC folks too...
So far it sounds like Juergen and I are with #2, how about =
others?

Thanks,
Kent




On 12/18/15, 2:59 AM, "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de> wrote:

On Thu, =
Dec 17, 2015 at 09:27:12PM +0000, Kent Watsen wrote:
[As a contributor]

Thank you for the review Juergen.

Great suggestions.  If no one objects, =
I=E2=80=99ll incorporate them into the next revision of the document =
after last call.

My one comment is that I =
don=E2=80=99t believe the document is limited to the introduction of =
applied configuration. For instance, the relating of config to derived =
state and also the model structure requirement are not related to =
applied config.  In all fairness, Requirement #5 (model structure) =
isn=E2=80=99t even about operational state.
Reading #5 again I must admit that I do not really =
understand what
this requirement tries to accomplish:

  5.  Ability for distinct modules =
to leverage a common model-structure

 =
     A.  Focus on the IETF-defined =
modules, and ideally provides
 =
         guidance to other =
SDOs

      B. =
 Multiple domain-specific model-structure trees are okay

      C. =
 Model-structures may be defined in multiple modules with
 =
         distinct =
namespaces

At this level of abstraction, #5 =
really does not mean anything or N
people will have at =
least N different interpretations of it. I
actually think =
this should be taken out and moved into a different
document=
 and then it requires to be developed into something much more
concrete.

/js

So your title and =
abstract suggestions might define too narrow a scope.  So how =
about:

Title: Terminology and Requirements =
for Operational State and Model Structure

Abstract:
     This =
document defines requirements for enhancing the support
 =
    of operational state through the introduction of =
a conceptual
     "applied =
configuration".  The document also defines requirements
     enabling distinct modules to =
leverage a common model structure.

=E2=80=A6a=
nd add an Introduction section that expands on this theme further?

I think this is getting into the =
wrong direction and as explained
above #5 is by far =
underspecified to be of any value. I suggest to
take it =
out so that we can publish the rest in a timely manner. The
alternative is to hold off this document in an attempt to =
replace #5
with something that is concrete and =
actionable.

/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



Mahesh Jethanandani
mjethanandani@gmail.com








=

--Apple-Mail=_B1C7BB64-4702-48A3-A832-74FD84AB5F6E--


From nobody Fri Dec 18 23:41:23 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 955E71A7005 for ; Fri, 18 Dec 2015 23:41:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.361
X-Spam-Level: 
X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 IcPTEnPEjuj9 for ; Fri, 18 Dec 2015 23:41:18 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85D931A7004 for ; Fri, 18 Dec 2015 23:41:18 -0800 (PST)
Received: from [IPv6:2a01:5e0:29:ffff:e8b6:1b9b:2e77:a341] (unknown [IPv6:2a01:5e0:29:ffff:e8b6:1b9b:2e77:a341]) by mail.nic.cz (Postfix) with ESMTPSA id DF6111813B7; Sat, 19 Dec 2015 08:41:15 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450510876; bh=84p9qkBTIFAn7lX18SYrKUPVvN6a4BvIWiNc9CKQ+g4=; h=From:Date:To; b=QbVsz5p/A4pAKNuAqlSRniTOJ4TeTsMy9wN+VrLLecHnjrnRTt/ZEPdH+DAqaUGSs 2dTFwFt3oZjdwgtkZEWUn3Hy5HseK3u84Nmh0Rz0F8p2X+iL6WM00VwkwbgXzzOq2M HpSt4W3gbwmIzqXPf+bIPVpb3foeELGH5JrSXl14=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <20151218.194238.1889765562853846766.mbj@tail-f.com>
Date: Sat, 19 Dec 2015 08:41:15 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <18D1EC19-B59F-4E76-8A52-84F5E4A8BA5A@nic.cz>
References: <7E169FEA-ABF9-4B3F-BB86-A3D3B900741A@nic.cz>  <5F9B1A29-A8FE-4EEC-B850-8AD98940DA65@nic.cz> <20151218.194238.1889765562853846766.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Dec 2015 07:41:21 -0000

> On 18 Dec 2015, at 19:42, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>>=20
>>> On 18 Dec 2015, at 17:06, Andy Bierman  wrote:
>>>=20
>>>=20
>>>=20
>>> On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka  =
wrote:
>>> Hi,
>>>=20
>>> if we want people to take YANG modules appearing in I-Ds seriously =
and implement them, then we should apply the revisioning rules to them. =
That is, if a module changes between two I-D revisions, then its =
revision-date has to be bumped and a new entry added to the revision =
history. As it is now, the I-D-based modules are esentially =
revisionless.
>>>=20
>>>=20
>>>=20
>>> The revision rules only apply to published modules.
>>=20
>> Update rules of sec. 10 offer no such excuse.
>=20
> It says:
>=20
>  For any published change, ...

Well, sec. 10 (and 11 in 6020bis) only says: "For any published change, =
a new "revision" statement (Section 7.1.9) MUST be included in front of =
the existing "revision" statements." The update rules aren't conditional =
in any way.

Lada

>=20
>=20
> I agree w/ Andy that 6087bis could clarify what this means in terms of
> IETF.
>=20
>=20
> /martin
>=20
>=20
>>> In IETF-speak, that means an RFC.  An Internet Draft
>>> is a work-in-progress.  We update the revision date every time
>>> the module changes, but the numerous incremental changes
>>> for a work-in-progress should not be recorded in the module
>>> revision history.  They should be recorded in the Change Log =
appendix.
>>=20
>> Revision numbers are critical for interoperability. If we want
>> vendors to implement modules such as ietf-routing now, the
>> revisions must be solid and reliable.
>>=20
>>>=20
>>> I will try to make this procedure more clear in the YANG guidelines =
draft.
>>=20
>> I think it should be the other way around: YANG spec should not
>> contain the update rules (because we all ignore them for I-D-based
>> modules, right?), but the IETF guidelines should specify the
>> policy you describe.=20
>>=20
>> Lada
>>=20
>>>=20
>>>=20
>>>=20
>>> Lada
>>>=20
>>>=20
>>> Andy
>>>=20
>>>=20
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>=20
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Sat Dec 19 00:07:07 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8606B1A7D84 for ; Sat, 19 Dec 2015 00:07:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 HnsMWlYBtODl for ; Sat, 19 Dec 2015 00:07:04 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937A51A7D85 for ; Sat, 19 Dec 2015 00:07:03 -0800 (PST)
Received: from [IPv6:2a01:5e0:29:ffff:e8b6:1b9b:2e77:a341] (unknown [IPv6:2a01:5e0:29:ffff:e8b6:1b9b:2e77:a341]) by mail.nic.cz (Postfix) with ESMTPSA id 36B2E181877; Sat, 19 Dec 2015 09:07:02 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450512422; bh=QkAzRUJuGayswPn5/aWgogIHmXkKENkl1uUZN+SMKnM=; h=From:Date:To; b=gF6cfl3tKMoyVuV9TEcDJ1bL2QCLo1H4o6DuvQk6USFYeIdKBg/z0xN3vvhvY72SC 2OeJkKzh2Rzet8KFLconD/JFy9a8ieUgGcNcWi1a+gj9s0NhpebMgsfLv5UYn8+DJm iPu55EihTBC/L89uLBl1CbDQ9VTTGldD1nzy1+hQ=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Sat, 19 Dec 2015 09:07:01 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <27845138-2E3E-41AA-8D46-F445DA52FF64@nic.cz>
References: <7E169FEA-ABF9-4B3F-BB86-A3D3B900741A@nic.cz>  <5F9B1A29-A8FE-4EEC-B850-8AD98940DA65@nic.cz> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Dec 2015 08:07:05 -0000

> On 18 Dec 2015, at 18:00, Andy Bierman  wrote:
>=20
>=20
>=20
> On Fri, Dec 18, 2015 at 8:32 AM, Ladislav Lhotka  =
wrote:
>=20
> > On 18 Dec 2015, at 17:06, Andy Bierman  wrote:
> >
> >
> >
> > On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka  =
wrote:
> > Hi,
> >
> > if we want people to take YANG modules appearing in I-Ds seriously =
and implement them, then we should apply the revisioning rules to them. =
That is, if a module changes between two I-D revisions, then its =
revision-date has to be bumped and a new entry added to the revision =
history. As it is now, the I-D-based modules are esentially =
revisionless.
> >
> >
> >
> > The revision rules only apply to published modules.
>=20
> Update rules of sec. 10 offer no such excuse.
>=20
>=20
> That is a flaw in the draft

IMO, 6020(bis) is not a good place for such rules because their =
applicability depends on the context. Backward compatibility is a matter =
of policies and, above all, sound judgement of module =
authors/publishers/vendors.=20

>=20
> =20
>=20
> > In IETF-speak, that means an RFC.  An Internet Draft
> > is a work-in-progress.  We update the revision date every time
> > the module changes, but the numerous incremental changes
> > for a work-in-progress should not be recorded in the module
> > revision history.  They should be recorded in the Change Log =
appendix.
>=20
> Revision numbers are critical for interoperability. If we want vendors =
to implement modules such as ietf-routing now, the revisions must be =
solid and reliable.
>=20
>=20
> Vendors implement work-in-progress at their own risk.

Yes, and that's why no vendor is very eager to do that. I actually think =
we should try harder to reduce the module churn already in the I-D =
phase, if possible.

> IMO we should do a better job publishing RFCs on time,
> and implement RFCs.

But doing that means there is no way back - because of the update rules. =
We have to accept that even modules published in RFCs may need to be =
changed in ways that aren't permitted by sec. 10, based on feedback from =
implementations.=20

>=20
> =20
>=20
> >
> > I will try to make this procedure more clear in the YANG guidelines =
draft.
>=20
> I think it should be the other way around: YANG spec should not =
contain the update rules (because we all ignore them for I-D-based =
modules, right?), but the IETF guidelines should specify the policy you =
describe.
>=20
>=20
> This is a closed issue in YANG 1.1

You said there was a flaw in the draft.

Lada

>=20
> =20
> Lada
>=20
>=20
>=20
> Andy
>=20
> =20
> >
> >
> >
> > Lada
> >
> >
> > Andy
> >
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> >
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Sat Dec 19 00:12:41 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2901A711A for ; Sat, 19 Dec 2015 00:12:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 istlFil8t131 for ; Sat, 19 Dec 2015 00:12:37 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 898F41A86DD for ; Sat, 19 Dec 2015 00:12:37 -0800 (PST)
Received: from [IPv6:2a01:5e0:29:ffff:e8b6:1b9b:2e77:a341] (unknown [IPv6:2a01:5e0:29:ffff:e8b6:1b9b:2e77:a341]) by mail.nic.cz (Postfix) with ESMTPSA id 9A42718128F; Sat, 19 Dec 2015 09:12:35 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450512755; bh=191hfJfe+rvvDXbA/b9dyHz2VO31v6ZazYIzpCQIvQw=; h=From:Date:To; b=AJ7hOxhgwV7KrRa15FxVoiKw5NLiUZr924FtyenMOAK+6gIQIFpmvClmh89P0FZne 6P1owMrs5mUj4mQXdDSEIeUvU5UjTqtyiLeAFFJh8bgnLjHFPr71UE7tWfxdsFT/Xm Awy0zQ/p1oGwE68VDX27kaL9QYqzIjuwW64Rts0E=
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_4EB49F79-C3C6-4D5B-A124-B37FA35ABF06"; protocol="application/pgp-signature"; micalg=pgp-sha1
X-Pgp-Agent: GPGMail 2.6b2
From: Ladislav Lhotka 
In-Reply-To: 
Date: Sat, 19 Dec 2015 09:12:34 +0100
Message-Id: <395D0D2E-C596-4D1E-B45A-8ADF72051B66@nic.cz>
References: <7E169FEA-ABF9-4B3F-BB86-A3D3B900741A@nic.cz>  <20151218.194526.1877280801898778625.mbj@tail-f.com> 
To: Christian Hopps 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Dec 2015 08:12:40 -0000

--Apple-Mail=_4EB49F79-C3C6-4D5B-A124-B37FA35ABF06
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On 18 Dec 2015, at 20:11, Christian Hopps  wrote:
>=20
>=20
> Martin Bjorklund  writes:
>=20
>> Christian Hopps  wrote:
>>>=20
>>>=20
>>> Versioning has come up in previous conversations I've been a part =
of,
>>> and I was led to believe that it does not really exist for yang
>>> modules. That is, if you update a published module it's a completely =
new
>>> model with no-expectation of compatibility with previous models.
>>=20
>> Please see section 10 of RFC 6020.
>=20
> Ok, so I either misunderstood, or was misled. :)
>=20
> So my reading of section 10 is that a new revision is the "bump the
> minor" action, and a new module is required for "bump the major".

Very true, this is an excellent observation! But starting a new module =
also means (beside all other complications) that the revision history is =
discontinued, which is bad. It's like demanding that each time a library =
API changes, a new GitHub project has to be started.

Cheers, Lada

>=20
> Thanks,
> Chris.
>=20
>=20
>>=20
>>> Is it the case that there's no way to "bump the minor version" of a
>>> model (i.e., you make only additions, but no deletions or changes to
>>> meaning so that the model can be considered backward compatible)?
>>=20
>> All rules in section 10 of RFC 6020 are backwards compatible.
>>=20
>> Also note that you can deprecate and obsolete nodes and define new
>> nodes in the same module.
>>=20
>>=20
>>=20
>> /martin
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--Apple-Mail=_4EB49F79-C3C6-4D5B-A124-B37FA35ABF06
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAlZ1EXMACgkQWQVCj+dOjAyy/QCfZmj+r9/AV6I1f4NeSLg7vrtb
QLUAniLwCo6FnCUcysWDKENOhOQKrtJk
=0BZA
-----END PGP SIGNATURE-----

--Apple-Mail=_4EB49F79-C3C6-4D5B-A124-B37FA35ABF06--


From nobody Sat Dec 19 04:51:07 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22FD1A8927; Sat, 19 Dec 2015 04:51:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level: 
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 nlVU1B4H_vob; Sat, 19 Dec 2015 04:51:01 -0800 (PST)
Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::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 633321A8925; Sat, 19 Dec 2015 04:51:01 -0800 (PST)
Received: by mail-qg0-x234.google.com with SMTP id k90so74171977qge.0; Sat, 19 Dec 2015 04:51:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vW+DaTgria4hOLk6UeTXsC+yy4/EkmfvgfLuPE6DJCc=; b=BgQrWnTIoxhE/yfcshuMQytNqxBvtjywyKFRwX2cPWu3fbHnGjg/S8QUqGFA26V4L/ M367yU1g+QQ6g8cXbMnZqVtHcWYUdAOHf7ecQllwfEfkrRHUPEvCZLQr971EOgViDiWP x7uo38qqvgxmE8JwbfnEqJqucajpNkQh86qiAOnAUt4a/d3U1dBmwjb6X7UGsU3vLt9q fqkJFesvSqN/7PxWRCiyJxozUOUKiJdDbKlMTTDl1g5DElj296kFK9KPcaiJIaupMFc7 dWctwAOpxh3wwL9x3hPIO3ICJ1XWIimzSmK5/JJjM1En2dtauJu/0mxh5R5B1M0hajCo olPA==
X-Received: by 10.140.255.10 with SMTP id a10mr12671248qhd.103.1450529460533;  Sat, 19 Dec 2015 04:51:00 -0800 (PST)
Received: from [10.0.1.3] (c-73-234-145-200.hsd1.ma.comcast.net. [73.234.145.200]) by smtp.gmail.com with ESMTPSA id q78sm8792441qha.13.2015.12.19.04.50.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 19 Dec 2015 04:50:59 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Dean Bogdanovic 
In-Reply-To: <20151211113156.GA43862@elstar.local>
Date: Sat, 19 Dec 2015 07:50:58 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com>
References:  <20151211113156.GA43862@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.3096.5)
Archived-At: 
Cc: RTG YANG Design Team , netmod WG , Benoit Claise 
Subject: Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Dec 2015 12:51:04 -0000

Juergen,

Please see answers inline

Dean

> On Dec 11, 2015, at 12:31 PM, Juergen Schoenwaelder =
 wrote:
>=20
> On Wed, Dec 09, 2015 at 08:27:04AM -0800, Nadeau Thomas wrote:
>>=20
>> 	This email initiates a NETMOD WG Last call for =
draft-ietf-netmod-acl-model-06.=20
>> Please review the draft and make any comments to the list by =
Wednesday, 16 December, 2015
>> by 8AM EST.
>>=20
>=20
> Technical
>=20
> - I am not sure I personally like the acl-oper-data and ace-oper-data
>  containers in the middle of the config true tree. I understand that
>  operational state in this case is likely tightly bound to the
>  lifetime of the config state but I also generally prefer to have a
>  clean separation of config from state. But since I am not
>  implementing this, I am happy to leave the decision to those who
>  write the code.
>=20
> - I would probably have used src-ipv4-prefix and dst-ipv4-prefix
>  instead of source-ipv4-network and destination-ipv4-network and
>  I would probably have used src-mac-address and src-mac-address-mask
>  and dst-mac-address and dst-mac-address-mask. Generally simple
>  src instead source and dst instead destination - lines up all
>  much more nicely.

I know that src and dst are pretty standard abbreviations, but have =
preference to use full words.

>=20
> - I would have put the acl-name and acl-type first followed by the
>  entries list.

Can you please expand on this? Is there any major difference? OR just =
design choice?
>=20
> - I also wonder why we use both the term 'entry' and 'rule', why not
>  pick one of them? You have for example rule-name (which is the key
>  of the list but again comes last).
This is a bit of compromise between Cisco and Juniper terminology. In =
Cisco it is ACE and in Juniper term. But in the yang model and in the =
text we are using consistently one or the other word.

>=20
> - Should there be features for ace-eth and ace-ipv4 and ace-ipv6 or do
>  we expect that all implementations will always support all three?
>  Another option would be to have the generic model completely without
>  any protocol specific elements and to have separate models to
>  augment in ipv4, ipv6, and ethernet specific ace types. I actually
>  think this would make much more sense since you would not have a
>  module 'packet fields' but instead a clear extension of the
>  ietf-access-control-list module. You could also drop the examples
>  how to extend the core model since the ip and ethernet extensions
>  would already serve the purpose. You also would not need features
>  since an implementation advertises the extension modules.

We started early with such design, but then the WG feedback moved us to =
the current  design.

>=20
> - The 'uses packet-fields:metadata' resolves to a leaf
>  'input-interface' which is of type string. Is this the only metadata
>  field we ever envision to be there? If so, why not make it part of
>  the base model? If not, what is the extensibility model here? =20

It can be used for route filtering=20

> And
>  should the interface reference not use a more specific type than
>  'string=E2=80=99?

Interface references can be many things, from standard naming we are =
familiar, e.g. ge-1/0/0.1 to a numerical value like 13276. Leaving it as =
string gives us most flexibility in that regards.

>=20
> - Some implementations support the action to jump or goto other
>  acls. Is this not common enough to include it as a base action,
>  perhaps protected by a feature?

Yes among vendors, but it can be very specific. Example, in Juniper =
implementation there are two types of filters, classical and Fast Update =
Filters (FUF). Classic filters support (on specific HW platforms) filter =
as action, but FUF does not. Not all terms and not all actions are =
supported on FUFs. So you have to see what filter type and what platform =
it is, in order to such a specific action.
>=20
> - In the example in section 4.3, does the CLI shown really help much?
>  The syntax is pretty system specific.

OTH, it is widely understood and self explanatory.=20

> In the XML shown, can you not
>  leave out all the fields that are not set? This would remove a lot
>  of noise. I do not understand what having both actions deny and
>  permit at the same time means. Did you validate the example against
>  the data model? (I also find the keys at the end somewhat strange
>  and not that NETCONF XML serialization actually requires the keys to
>  be sent first.)
We used pyang sample xml skeleton to create the xml example.

Leaving both actions in the document is my fault. In the model, action =
is a choice, and it was a bad copy paste job. Didn=E2=80=99t choose :)
>=20
> - The clarification whether the boundary port numbers are included in
>  a port range should be in the YANG model. The YANG model should also
>  say what it means if one of the ranges is not present. We should not
>  define the semantics by examples.
I=E2=80=99m loosing you here. We are stating in the model if the =
boundary port numbers are included in a port rang.


   container source-port-range {
      presence "Enables setting source port range";
      description=20
        "Inclusive range representing source ports to be used.
        When only lower-port is present, it represents a single port.";
      leaf lower-port {
        type inet:port-number;
        mandatory true;
        description
          "Lower boundary for port.";
      }
      leaf upper-port {
        type inet:port-number;
        must ". >=3D ../lower-port" {
          error-message
          "The upper-port must be greater than or equal to lower-port";
        }
        description
          "Upper boundary for port . If existing, the upper port
          must be greater or equal to lower-port.";
      }
    }

Same is done for the upper port
>=20
> - I do not understand section 5. It shows some nftables syntax but
>  does not really shed a light on what the example shown does or how
>  that maps to the YANG data model. So I am left somewhat clueless.

Just wanted to point out that the basic structure of iptables is similar =
to ACL yang model, so a translation from one to the other should be a  =
simple process. If someone wants to make it compliant.
>=20
> - Can I trigger multiple actions from an ace? Or do I have to
>  replicate the ace to do that? In general, there is extension of
>  a choice (means one of several) and there are extension of a
>  choice already present.
Again, this is very platform dependent, so didn=E2=80=99t want to =
include it in the base model.

>=20
> - Empty description statements or descriptions statements "(null)"
>  need to be fixed.

There are no empty descriptions. You are probably referring to =
ietf-packet-fields.yang model. There is a bug in pyang which was =
reported to Martin and fixed since.

pyang --ietf --strict ietf-packet-fields.yang
ietf-packet-fields.yang:67: warning: RFC 6087: 4.12: statement "must" =
should have a "description" substatement
ietf-packet-fields.yang:89: warning: RFC 6087: 4.12: statement "must" =
should have a "description=E2=80=9D substatement

The code is correct, just the compiler is reporting an error.
          error-message
          "The upper-port must be greater than or equal to lower-port";
        }
        description
          "Upper boundary for port . If existing, the upper port
          must be greater or equal to lower-port.";
      }
>=20
> - I am a bit surprised that we do not define how to attach an ACL to
>  an interfaces or a set of interfaces given that we do have an
>  interfaces YANG data model. The example given in A.3 makes me wonder
>  why there should be a counter in the interfaces config tree. The
>  targets/interface-name back-reference seems to indicate that I can
>  attach an ACL only to a single interface.

I wasn=E2=80=99t the author of that section

>=20
> - I do not understand A.4 at all. Defining an identity does not make
>  the choice work differently.
>=20
> - Has someone tried to implement this?

Was working on implementation while at my previous employer, but am not =
aware of any other implementation.

> Organization
>=20
> - Section 3 to a large extend is a repetition of section 1. Perhaps
>  make section 1 shorter and leave the details to section 3?

OK
>=20
> - Some empty lines in the YANG definition would have pleased my eyes.

OK
>=20
> Editorial
>=20
> - there are a couple of missing articles throughout the text
> - sometimes singular/plural is at odds
> - s/this draft/this document/
> - you may add another 'e' to my name ;-)

or =C3=BC

Will fix those
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>=20
> _______________________________________________
> Rtg-dt-yang-arch mailing list
> Rtg-dt-yang-arch@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch


From nobody Sat Dec 19 05:05:31 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C25E1A8944; Sat, 19 Dec 2015 05:05:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
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 v3W9gY0jAmEN; Sat, 19 Dec 2015 05:05:27 -0800 (PST)
Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 B976D1A8941; Sat, 19 Dec 2015 05:05:27 -0800 (PST)
Received: by mail-qg0-x22d.google.com with SMTP id k90so74339880qge.0; Sat, 19 Dec 2015 05:05:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7kfyXu7Q4t85rv3pwD9+9IEOU8VqdhlDDeI2cfn7FHQ=; b=D2vzN/a8gcDzE5t8MdBhDmRhA+jjZ1dO7+BiGbI44KavFrZC8kOpj1iGQFVN4GCpeo 5E0OZ0C9x6w+GUiY12iNokzTveO73fPwLPyzdmi1wgWEjW6CVQ/TlYnF69+n9hugAn+Z CyyZgK7rqFcOy5C4Kt3Bsg6rdcJWz88iLjPxOAQZY1GoWtmZ6VsHeGYCHfjOZ/uj/Wpj iMRuYFKu2NSN22JW3KAykPRqjrwgfjpyeBPFEYhT1Y8zK2lRlDl9lLlxmI0eEoiZMzW0 1trKo45HkWpOuLV7nAcnaFOecM5Hk7lpfgMeI74td+Htb7Vm0lhJXPDu5QgB9gP6jGuF qv7A==
X-Received: by 10.140.18.115 with SMTP id 106mr12375509qge.34.1450530326933; Sat, 19 Dec 2015 05:05:26 -0800 (PST)
Received: from [10.0.1.3] (c-73-234-145-200.hsd1.ma.comcast.net. [73.234.145.200]) by smtp.gmail.com with ESMTPSA id z21sm6601310qge.18.2015.12.19.05.05.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 19 Dec 2015 05:05:26 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Dean Bogdanovic 
In-Reply-To: 
Date: Sat, 19 Dec 2015 08:05:25 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <4A6F06C5-7198-4FCA-A10C-0377F595D704@gmail.com>
References:  <5672BAD7.2080003@cisco.com> <1B2DACE1-A8F0-493B-8B61-EF6321790ECE@lucidvision.com> <5672CA38.4060709@cisco.com>  
To: "Sterne, Jason (Jason)" 
X-Mailer: Apple Mail (2.3096.5)
Archived-At: 
Cc: RTG YANG Design Team , netmod WG , Benoit Claise 
Subject: Re: [netmod] [Rtg-dt-yang-arch] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Dec 2015 13:05:29 -0000

The basic design idea for the base model is structure that all vendors =
support. Some of the examples mentioned below, like FQDN, are not =
supported by all vendors and are protected by IPR (which I wasn=E2=80=99t =
aware of it). There are many possible match conditions that could be =
added to the base model, like Auth header in IPSec or IPSec =
encapsulation security payload to keep it with security. There are many =
match conditions in Class of Services as well. All these match =
conditions would have created more issues to come to consensus about the =
base model, so for that reason we went with the minimal model that would =
be easy for all vendors to implement.

Dean

> On Dec 18, 2015, at 5:21 PM, Sterne, Jason (Jason) =
 wrote:
>=20
> I'm not a fan of adding something like that in the base model.  Let's =
get a basic model done and then we can consider an extension draft.  I'd =
think that things like TCP flags, for example, would be a more natural & =
common thing to add to an ACL model than a host name match so I can't =
see host name being in there before TCP flags (which I'm not advocating =
for in the base model).
>=20
> I also don't think the metadata interface match should be in this base =
model either.  That is out of place IMO.  The base model provides an ACL =
that can then get associated with objects like interfaces (as in the =
example in section A.3)
> I'd also suggest we consider making the actions 'deny' and 'permit' =
presence containers instead of empty leafs.  That would allow easier =
augmentations (e.g. additional 'permit' parameters for policy based =
forwarding for example).
>=20
> Regards,
> Jason
>=20
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Nadeau =
Thomas
> Sent: Thursday, December 17, 2015 10:53
> To: Lear Eliot
> Cc: Benoit Claise; RTG YANG Design Team; netmod WG
> Subject: Re: [netmod] Working group Last Call: =
draft-ietf-netmod-acl-model-06
>=20
>=20
> 	You raise a good point. Do the contributors/editors have any =
thoughts on this suggestion?
>=20
> 	=E2=80=94Tom
>=20
>=20
>> On Dec 17, 2015:9:44 AM, at 9:44 AM, Eliot Lear  =
wrote:
>>=20
>>=20
>>=20
>> On 12/17/15 2:45 PM, Nadeau Thomas wrote:
>>> 	Do you mean an ASCII DNS name (versus an IP address w a mask)?
>>=20
>> I was thinking of "host" in RFC 6021.
>>=20
>> Eliot
>>=20
>>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> _______________________________________________
> Rtg-dt-yang-arch mailing list
> Rtg-dt-yang-arch@ietf.org
> https://www.ietf.org/mailman/listinfo/rtg-dt-yang-arch


From nobody Sat Dec 19 11:06:33 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49EC51A90E6 for ; Sat, 19 Dec 2015 11:06:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 UA7C-t53POlv for ; Sat, 19 Dec 2015 11:06:30 -0800 (PST)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id B82271A90EA for ; Sat, 19 Dec 2015 11:06:30 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=OPB+bXwjIZz7UKwZFwETdpJbcm42CUsFBbZPACyuunQXCQ+NolxJyhIF/zA43GW6; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.26] (helo=mswamui-bichon.atl.sa.earthlink.net) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aAMpf-00050V-MO for netmod@ietf.org; Sat, 19 Dec 2015 14:06:19 -0500
Received: from 76.254.48.98 by webmail.earthlink.net with HTTP; Sat, 19 Dec 2015 14:06:19 -0500
Message-ID: <1033983.1450551979726.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>
Date: Sat, 19 Dec 2015 11:06:19 -0800 (GMT-08:00)
From: Randy Presuhn 
To: NETMOD WG 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888857e9f10d2205ddca7b8f71dcf6a800c18922d7a723bbbe9350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.26
Archived-At: 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Dec 2015 19:06:32 -0000

Hi -

>From: Ladislav Lhotka 
>Sent: Dec 19, 2015 12:07 AM
>To: Andy Bierman 
>Cc: NETMOD WG 
>Subject: Re: [netmod] module update rules
...
>IMO, 6020(bis) is not a good place for such rules because
> their applicability depends on the context. Backward
> compatibility is a matter of policies and, above all,
> sound judgement of module authors/publishers/vendors.

C'mon.  Can't we at least *pretend* to be doing configuration
management?  Being able to decide whether two things (schemata
or actual instances of configuration) are in some sense
the same, "compatible", or different is much too fundamental
to the problem space to be left to whim.

...
>> Vendors implement work-in-progress at their own risk.
>
>Yes, and that's why no vendor is very eager to do that.
> I actually think we should try harder to reduce the module
> churn already in the I-D phase, if possible.

SNMP dealt with this by not issuing the authoritative identifier
(the OID) until RFC publication, so anyone implementing the
work-in-progress did so in their own OID space.  Perhaps it
would be worthwhile to initiate a similar practice here.

>> IMO we should do a better job publishing RFCs on time,
>> and implement RFCs.
>
>But doing that means there is no way back - because of
> the update rules. We have to accept that even modules
>published in RFCs may need to be changed in ways that
> aren't permitted by sec. 10, based on feedback from
> implementations.

Why is that a problem?  If it turns out that the published
model is substantially flawed, then it seems that treating
the fixed module as a distinct entity is the right thing to
do.  Keeping the same name might help someone save face, but
it would in no way aid interoperability.  The basic idea is
that if one changes something too much, it becomes something
else.  This holds so often true in life that I'm surprised
that anyone would be surprised by this.

Randy


From nobody Sat Dec 19 12:12:00 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D251AC400 for ; Sat, 19 Dec 2015 12:11:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 me02sBGIZOHY for ; Sat, 19 Dec 2015 12:11:57 -0800 (PST)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 EB8F51AC3F7 for ; Sat, 19 Dec 2015 12:11:56 -0800 (PST)
Received: by mail-lf0-x234.google.com with SMTP id p203so92174866lfa.0 for ; Sat, 19 Dec 2015 12:11:56 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=q50l1uWI50RESaF9LFxZvs6pv12XkJc0rahO/AytSBI=; b=bxOUBPXU1dUFmXuvxRSRNXlBUHsRqqFGxcoA9z2HHwh08pn6kJZyf1Mdp5JIF7IjJM hRu3OeYgkQPuCGVarvbyaRfk8emXttL6kVuTy1jfXbsLiI/1YhnyRn4UGuoDZ/a3IB7s 7g9TVQGBxBYzZIHuTYE/+b60BP5viEoMUjzocmbdp9CG4j/oOlBFOajghc97COTowWWQ 260X/nrgzHyczCHP7q5IIJWBLY6Qp2wT0J3MeBHPHYx05xRpLgmL5ystiICGyML+trGP UzhL3GiM2Pt+bkdgbjWhDyek1jD56WyBPWnZ302KzDGSTAs81CDoCGPqeGKazYJRgqXH TjBw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=q50l1uWI50RESaF9LFxZvs6pv12XkJc0rahO/AytSBI=; b=SWMhDbdd4ziizzbENyhZ7uT+lFlB07+pVU7VSg2xLEjuVDklpsJcoPwnE2EYa8dN9Y uv0+lkGueNzhuUiZ0BPDKtzhIGQo/gUMTTIsUw9nWmzNJetBJ1Q1kzNMc5ZlZvNr0nlV ZXFyS1H2yxA+yRDVQ8yUPGSrHIqAJQGm5192ibNkninlmsE2ooxYbEoRHxss7hei3iXI pBuTvvbt2ucHgauitsNHEPdOfeH8Wxj4e+eLPlcsxCxDag9qDPH+83ZMxM7SfSKF2q5p w0NYSf0rNyFuF71gUpgiFMjlBJm0UbUbxiRXGiaI5VjGx9vDtJxnVcpnCU/vz6TzntbX ELyQ==
X-Gm-Message-State: ALoCoQlno18we/KEA+ENFYanfh5ZN1bvvdz/cc3KWipEHj7ehG3+KjKnAEXQwOQ2l2eAoMxNepVWn/OT/Snbb6G4kw2ZNZEyuA==
MIME-Version: 1.0
X-Received: by 10.25.0.205 with SMTP id 196mr4017714lfa.62.1450555915011; Sat, 19 Dec 2015 12:11:55 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Sat, 19 Dec 2015 12:11:54 -0800 (PST)
In-Reply-To: <1033983.1450551979726.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>
References: <1033983.1450551979726.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>
Date: Sat, 19 Dec 2015 12:11:54 -0800
Message-ID: 
From: Andy Bierman 
To: Randy Presuhn 
Content-Type: multipart/alternative; boundary=001a113c9c120ad04e052745de2f
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 19 Dec 2015 20:11:59 -0000

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

On Sat, Dec 19, 2015 at 11:06 AM, Randy Presuhn <
randy_presuhn@mindspring.com> wrote:

> Hi -
>
> >From: Ladislav Lhotka 
> >Sent: Dec 19, 2015 12:07 AM
> >To: Andy Bierman 
> >Cc: NETMOD WG 
> >Subject: Re: [netmod] module update rules
> ...
> >IMO, 6020(bis) is not a good place for such rules because
> > their applicability depends on the context. Backward
> > compatibility is a matter of policies and, above all,
> > sound judgement of module authors/publishers/vendors.
>
> C'mon.  Can't we at least *pretend* to be doing configuration
> management?  Being able to decide whether two things (schemata
> or actual instances of configuration) are in some sense
> the same, "compatible", or different is much too fundamental
> to the problem space to be left to whim.
>
>
Although I agree, we do try to set the bar high enough to
support deployments of mixed vendor and mixed revisions.
We try not to alter published APIs in a way that would break
an existing client implementation.  If one does not agree the bar
should be this high, then these rules get in the way.

...
> >> Vendors implement work-in-progress at their own risk.
> >
> >Yes, and that's why no vendor is very eager to do that.
> > I actually think we should try harder to reduce the module
> > churn already in the I-D phase, if possible.
>
> SNMP dealt with this by not issuing the authoritative identifier
> (the OID) until RFC publication, so anyone implementing the
> work-in-progress did so in their own OID space.  Perhaps it
> would be worthwhile to initiate a similar practice here.
>
>

That did not entirely help.
We would hack them in anyway.  RMON people broke OIDs
more than once (as you know ;-)

There actually is quite a lot of I-D implementation.
Those of us doing it know there will be lots of instability,
and therefore do not attempt to track every revision.
(Yes this leads to random snapshots out in the field,
and no, I don't want to replay the "WG snapshot" debate)


> >> IMO we should do a better job publishing RFCs on time,
> >> and implement RFCs.
> >
> >But doing that means there is no way back - because of
> > the update rules. We have to accept that even modules
> >published in RFCs may need to be changed in ways that
> > aren't permitted by sec. 10, based on feedback from
> > implementations.
>
> Why is that a problem?  If it turns out that the published
> model is substantially flawed, then it seems that treating
> the fixed module as a distinct entity is the right thing to
> do.  Keeping the same name might help someone save face, but
> it would in no way aid interoperability.  The basic idea is
> that if one changes something too much, it becomes something
> else.  This holds so often true in life that I'm surprised
> that anyone would be surprised by this.
>

We had this same problem for MIB modules for a long time, and still
managed to updated published RFCs many times.


> Randy
>


Andy



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

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




On Sat, Dec 19, 2015 at 11:06 AM, Randy Presuhn <<=
a href=3D"mailto:randy_presuhn@mindspring.com" target=3D"_blank">randy_pres=
uhn@mindspring.com> wrote:
=
Hi -



>From: Ladislav Lhotka <lhotka@nic.c=
z>

>Sent: Dec 19, 2015 12:07 AM

>To: Andy Bierman <andy@yumawor=
ks.com>

>Cc: NETMOD WG <netmod@ietf.org>

>Subject: Re: [netmod] module update rules

...

>IMO, 6020(bis) is not a good place for such rules because

> their applicability depends on the context. Backward

> compatibility is a matter of policies and, above all,

> sound judgement of module authors/publishers/vendors.



C'mon.=C2=A0 Can't we at least *pretend* to be doing configuration<=
br>
management?=C2=A0 Being able to decide whether two things (schemata

or actual instances of configuration) are in some sense

the same, "compatible", or different is much too fundamental

to the problem space to be left to whim.





...

>> Vendors implement work-in-progress at their own risk.

>

>Yes, and that's why no vendor is very eager to do that.

> I actually think we should try harder to reduce the module

> churn already in the I-D phase, if possible.



SNMP dealt with this by not issuing the authoritative identifier

(the OID) until RFC publication, so anyone implementing the

work-in-progress did so in their own OID space.=C2=A0 Perhaps it

would be worthwhile to initiate a similar practice here.







--001a113c9c120ad04e052745de2f--


From nobody Mon Dec 21 03:13:59 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A19F51A0273 for ; Mon, 21 Dec 2015 03:13:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.111
X-Spam-Level: 
X-Spam-Status: No, score=-13.111 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 vRvin3PYoFvT for ; Mon, 21 Dec 2015 03:13:56 -0800 (PST)
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 6CB3D1A028A for ; Mon, 21 Dec 2015 03:13:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4095; q=dns/txt; s=iport; t=1450696435; x=1451906035; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=c4zU4kzpmniGhgCMbXCahBSHUPVbgd3fj6ZBU50zWjs=; b=QGDaKQoFFxWgfA5aDkopB5cPA/0x2kLSj2fiBLv4/qPa4EoadpTTudSi p4ASYTjHatE9ZFMOhfpeqmz8/L3np14niig/mhfvJkVBHcjdspGOLeU0U ahYqjqjqMqiYjcgqzMr64wp/nwhGP0whp01f9bzx43Y6BxkFcVSBM5EIo 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBACC3ndW/xbLJq1aA4QMbYxSsS+BZ?= =?us-ascii?q?BcKhSJKAoFdEgEBAQEBAQGBCoQ0AQEBAwEBAQEgDwEFNgsOAgsOAggCAgUhAgI?= =?us-ascii?q?PAgoMMAYBDAYCAQGIIwgOq2yGVBYBAQIBizgBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEYBH2FVYR+hDRIJoJVgUkFlwCNS4Fch0qQEoN0KQoxhAQ+NINhJIEnAQEB?=
X-IronPort-AV: E=Sophos;i="5.20,459,1444694400"; d="scan'208";a="619622143"
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 Dec 2015 11:13:53 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tBLBDrwG030606; Mon, 21 Dec 2015 11:13:53 GMT
To: Kent Watsen , Juergen Schoenwaelder 
References: <20151217181627.GB68858@elstar.local> <57D42158-C9B5-4CEE-959E-674EBB3EEA97@juniper.net> <20151218075947.GC70138@elstar.local> 
From: Robert Wilton 
Message-ID: <5677DEF0.90705@cisco.com>
Date: Mon, 21 Dec 2015 11:13:52 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] review of draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 11:13:57 -0000

Hi Kent,

On 18/12/2015 20:56, Kent Watsen wrote:
> [As a contributor]
>
> Hi Juergen,
>
> I agree with you that req #5 sticks out as the odd ball in the bunch.  I suggested once to remove it a long time back, but I guess it fell on deaf ears then.  Anyway, given where we are with this document, I’m unsure what to do, but here are our options:
>
> 1. Leave requirement #5 in the document, but spend time improving it to WG satisfaction.
>
> 2. Take requirement #5 out, declaring it an unwanted distraction from the primary opstate focus.  We’d have to be sure to get sign-off from the OC folks too...
>
> So far it sounds like Juergen and I are with #2, how about others?
Yes, I support #2.

draft-rtgyangdt-rtgwg-device-model-01 is aiming to cover requirement #5, 
and is explicitly referencing the previous version of the Netmod 
requirements draft.

I would have thought that moving just this into a separate requirements 
document would make such a document too short.  So would it be 
appropriate to temporarily move the section 5 requirements to the next 
version of draft-rtgyangdt-rtgwg-device-model?  They could always be 
removed again at a future date if they are outlived their usefulness.

Thanks,
Rob


>
> Thanks,
> Kent
>
>
>
>
>
> On 12/18/15, 2:59 AM, "Juergen Schoenwaelder"  wrote:
>
>> On Thu, Dec 17, 2015 at 09:27:12PM +0000, Kent Watsen wrote:
>>> [As a contributor]
>>>
>>> Thank you for the review Juergen.
>>>
>>> Great suggestions.  If no one objects, I’ll incorporate them into the next revision of the document after last call.
>>>
>>> My one comment is that I don’t believe the document is limited to the introduction of applied configuration. For instance, the relating of config to derived state and also the model structure requirement are not related to applied config.  In all fairness, Requirement #5 (model structure) isn’t even about operational state.
>> Reading #5 again I must admit that I do not really understand what
>> this requirement tries to accomplish:
>>
>>    5.  Ability for distinct modules to leverage a common model-structure
>>
>>        A.  Focus on the IETF-defined modules, and ideally provides
>>            guidance to other SDOs
>>
>>        B.  Multiple domain-specific model-structure trees are okay
>>
>>        C.  Model-structures may be defined in multiple modules with
>>            distinct namespaces
>>
>> At this level of abstraction, #5 really does not mean anything or N
>> people will have at least N different interpretations of it. I
>> actually think this should be taken out and moved into a different
>> document and then it requires to be developed into something much more
>> concrete.
>>
>> /js
>>
>>> So your title and abstract suggestions might define too narrow a scope.  So how about:
>>>
>>> Title: Terminology and Requirements for Operational State and Model Structure
>>>
>>> Abstract:
>>>       This document defines requirements for enhancing the support
>>>       of operational state through the introduction of a conceptual
>>>       "applied configuration".  The document also defines requirements
>>>       enabling distinct modules to leverage a common model structure.
>>>
>>> …and add an Introduction section that expands on this theme further?
>> I think this is getting into the wrong direction and as explained
>> above #5 is by far underspecified to be of any value. I suggest to
>> take it out so that we can publish the rest in a timely manner. The
>> alternative is to hold off this document in an attempt to replace #5
>> with something that is concrete and actionable.
>>
>> /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


From nobody Mon Dec 21 04:17:41 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D039F1A071A for ; Mon, 21 Dec 2015 04:17:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level: 
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham
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 dvEgUW10Ctko for ; Mon, 21 Dec 2015 04:17:38 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 606AF1A0636 for ; Mon, 21 Dec 2015 04:17:37 -0800 (PST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 2093D1CC0339; Mon, 21 Dec 2015 13:17:34 +0100 (CET)
From: Ladislav Lhotka 
To: Randy Presuhn , NETMOD WG 
In-Reply-To: <1033983.1450551979726.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>
References: <1033983.1450551979726.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Mon, 21 Dec 2015 13:17:34 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 12:17:41 -0000

Randy Presuhn  writes:

> Hi -
>
>>From: Ladislav Lhotka 
>>Sent: Dec 19, 2015 12:07 AM
>>To: Andy Bierman 
>>Cc: NETMOD WG 
>>Subject: Re: [netmod] module update rules
> ...
>>IMO, 6020(bis) is not a good place for such rules because
>> their applicability depends on the context. Backward
>> compatibility is a matter of policies and, above all,
>> sound judgement of module authors/publishers/vendors.
>
> C'mon.  Can't we at least *pretend* to be doing configuration
> management?  Being able to decide whether two things (schemata

Actually, we are not doing only configuration management: for
state data the rules of sec. 10 are arguably useless.

> or actual instances of configuration) are in some sense
> the same, "compatible", or different is much too fundamental
> to the problem space to be left to whim.
>

Deciding whether a revision is compatible with a previous one is
possible =E2=80=93 at least if compatibility means sec. 10 rules. However,
sec. 10 states that a new revision MUST NOT introduce incompatible
changes, ever. Such an absolute statement IMO doesn't make sense - we
have been violating it for most NETMOD modules, and it is probably no
different in other WGs. And if the rules are meant as a whip on rogue
vendors and their proprietary modules, then it certainly won't help
either.

> ...
>>> Vendors implement work-in-progress at their own risk.
>>
>>Yes, and that's why no vendor is very eager to do that.
>> I actually think we should try harder to reduce the module
>> churn already in the I-D phase, if possible.
>
> SNMP dealt with this by not issuing the authoritative identifier
> (the OID) until RFC publication, so anyone implementing the
> work-in-progress did so in their own OID space.  Perhaps it
> would be worthwhile to initiate a similar practice here.

It might be helpful to be able explicitly indicate the status of each
module, e.g. pre-alpha, alpha, beta, release-candidate, stable.

Some modules spend a long time in the I-D stage (ietf-routing was
started 57 months ago), so it doesn't tell much by itself.

>
>>> IMO we should do a better job publishing RFCs on time,
>>> and implement RFCs.
>>
>>But doing that means there is no way back - because of
>> the update rules. We have to accept that even modules
>>published in RFCs may need to be changed in ways that
>> aren't permitted by sec. 10, based on feedback from
>> implementations.
>
> Why is that a problem?  If it turns out that the published
> model is substantially flawed, then it seems that treating
> the fixed module as a distinct entity is the right thing to
> do.  Keeping the same name might help someone save face, but
> it would in no way aid interoperability.  The basic idea is
> that if one changes something too much, it becomes something
> else.  This holds so often true in life that I'm surprised
> that anyone would be surprised by this.

Yes, if something changes too much. I don't think though that elementary
changes such as adding a single new mandatory leaf fall into this
category, yet they are not allowed per sec. 10 rules. It is not
reasonable to start a new module in such cases because the revision
history still provides valuable information, a new name and namespace
URI is needed etc. Such an abrupt change help neither old clients nor
anybody else.

Lada

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

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Mon Dec 21 05:04:52 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A73D1A1A56 for ; Mon, 21 Dec 2015 05:04:51 -0800 (PST)
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
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 VbemOyM1EOns for ; Mon, 21 Dec 2015 05:04:49 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDF91A1A4F for ; Mon, 21 Dec 2015 05:04:48 -0800 (PST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 0D8F31CC0339; Mon, 21 Dec 2015 14:04:46 +0100 (CET)
From: Ladislav Lhotka 
To: Kent Watsen , Juergen Schoenwaelder 
In-Reply-To: 
References: <20151217181627.GB68858@elstar.local> <57D42158-C9B5-4CEE-959E-674EBB3EEA97@juniper.net> <20151218075947.GC70138@elstar.local> 
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Mon, 21 Dec 2015 14:04:47 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] review of draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 13:04:51 -0000

Kent Watsen  writes:

> [As a contributor]
>
> Hi Juergen,
>
> I agree with you that req #5 sticks out as the odd ball in the bunch.  I =
suggested once to remove it a long time back, but I guess it fell on deaf e=
ars then.  Anyway, given where we are with this document, I=E2=80=99m unsur=
e what to do, but here are our options:
>
> 1. Leave requirement #5 in the document, but spend time improving it to W=
G satisfaction.
>
> 2. Take requirement #5 out, declaring it an unwanted distraction from the=
 primary opstate focus.  We=E2=80=99d have to be sure to get sign-off from =
the OC folks too...
>
> So far it sounds like Juergen and I are with #2, how about others?

I prefer #2.

Lada

>
> Thanks,
> Kent
>
>
>
>
>
> On 12/18/15, 2:59 AM, "Juergen Schoenwaelder"  wrote:
>
>>On Thu, Dec 17, 2015 at 09:27:12PM +0000, Kent Watsen wrote:
>>> [As a contributor]
>>>=20
>>> Thank you for the review Juergen.
>>>=20
>>> Great suggestions.  If no one objects, I=E2=80=99ll incorporate them in=
to the next revision of the document after last call.
>>>=20
>>> My one comment is that I don=E2=80=99t believe the document is limited =
to the introduction of applied configuration. For instance, the relating of=
 config to derived state and also the model structure requirement are not r=
elated to applied config.  In all fairness, Requirement #5 (model structure=
) isn=E2=80=99t even about operational state.
>>
>>Reading #5 again I must admit that I do not really understand what
>>this requirement tries to accomplish:
>>
>>   5.  Ability for distinct modules to leverage a common model-structure
>>
>>       A.  Focus on the IETF-defined modules, and ideally provides
>>           guidance to other SDOs
>>
>>       B.  Multiple domain-specific model-structure trees are okay
>>
>>       C.  Model-structures may be defined in multiple modules with
>>           distinct namespaces
>>
>>At this level of abstraction, #5 really does not mean anything or N
>>people will have at least N different interpretations of it. I
>>actually think this should be taken out and moved into a different
>>document and then it requires to be developed into something much more
>>concrete.
>>
>>/js
>>
>>> So your title and abstract suggestions might define too narrow a scope.=
  So how about:
>>>=20
>>> Title: Terminology and Requirements for Operational State and Model Str=
ucture
>>>
>>> Abstract:
>>>      This document defines requirements for enhancing the support
>>>      of operational state through the introduction of a conceptual
>>>      "applied configuration".  The document also defines requirements
>>>      enabling distinct modules to leverage a common model structure.
>>>=20
>>> =E2=80=A6and add an Introduction section that expands on this theme fur=
ther?
>>
>>I think this is getting into the wrong direction and as explained
>>above #5 is by far underspecified to be of any value. I suggest to
>>take it out so that we can publish the rest in a timely manner. The
>>alternative is to hold off this document in an attempt to replace #5
>>with something that is concrete and actionable.
>>
>>/js
>>
>>--=20
>>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

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Mon Dec 21 05:55:43 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBDE1A21A0 for ; Mon, 21 Dec 2015 05:55:42 -0800 (PST)
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
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 maolnzFhfln4 for ; Mon, 21 Dec 2015 05:55:39 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 99F4F1A1A0C for ; Mon, 21 Dec 2015 05:55:37 -0800 (PST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 408311CC0339; Mon, 21 Dec 2015 14:55:36 +0100 (CET)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder , Nadeau Thomas 
In-Reply-To: <20151217172931.GA68858@elstar.local>
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net> <0239ADFB-4A52-4E47-8FA5-406231AD92D5@lucidvision.com> <20151217172931.GA68858@elstar.local>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Mon, 21 Dec 2015 14:55:37 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 13:55:42 -0000

Juergen Schoenwaelder  writes:

> On Thu, Dec 17, 2015 at 10:52:13AM -0500, Nadeau Thomas wrote:
>>=20
>> > On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen =
 wrote:
>> >=20
>> >=20
>> >=20
>> >=20
>> >=20
>> >=20
>> >>>> I=E2=80=99m struggling a bit to understand what is motivating you t=
o ask this question.    That is, as a tool vendor, I wouldn=E2=80=99t think=
 that any decision made here would affect you immediately.   My expectation=
s are that any impact to YANG/NETCONF/RESTCONF would be backwards compatibl=
e, such that implementations would only opt-in when needed - a pay as you g=
row strategy.   But herein perhaps lies an unstated requirement, that the i=
mpact to YANG/NETCONF/RESTCONF needs to be backwards compatible with respec=
t to existing deployments.  Did we miss it or is it too obvious?
>> >>>>=20
>> >>>=20
>> >>> It may be obvious for many of us but for the sake of completeness I
>> >>> prefer to have this backwards compatibility assumption explicitely
>> >>> stated.
>> >>=20
>> >> +1
>> >=20
>> >=20
>> > [as a chair]
>> >=20
>> > As last call comment, there seems to be support for adding a requireme=
nt to the opstate-reqs draft to state that solutions supporting said requir=
ements MUST be backwards compatible with respect to existing deployments.  =
Do we have WG consensus to add this as a requirement to this draft?  Are th=
ere any objections? Please voice your opinion before the last call cutoff d=
ate (Dec 30).
>> >=20
>> >=20
>> > [as a contributor]
>> >=20
>> >=20
>> > I=E2=80=99m unsure if it makes sense to call it out in this draft, in =
that it seems universally applicable, but I don=E2=80=99t see any harm in i=
t either and thus do not object.
>> >=20
>> >=20
>> > Kent
>>=20
>> 	[As Co-chair]
>>=20
>> 	Given the tall hill we climbed to get to this point on the requirements=
, I
>> want to be clear that there needs to be very significant support to chan=
ge the requirements
>> in any significant way. We went round and round the drain on settling on=
 these requirements, and=20
>> people had a whole host of reasonable opportunities to add this during t=
hose times. I want to point out that while this statement may seem subtle, =
slipping this in at the last minute could have a profound impact on solutio=
ns built from these requirements, so I want to be sure everyone involved ha=
s through through this kind of change.
>>=20
>> 	=E2=80=94Tom
>
> Tom,
>
> I think Andy is talking about applicability - to which kind of servers
> do these requirements apply. For example, if it takes more time on a
> certain class of devices to retrieve the difference between applied
> and intended config than it takes to turn intended config into applied
> config, then these requirements may not be applicable (since by the
> time you have finished retrieving the difference it has vanished).

I think it is not only matter of synchronisation delays between intended
and applied configuration. I have serious troubles understanding how
these concepts map to the class of devices I am mainly interested in.

Let me give you an example: An OpenWRT router runs a NETCONF/RESTCONF
server that supports intended and applied config. Assume the server
implements modules of the acl-model family so that firewall rules can be
configured through NETCONF/RESTCONF. Great.

Now an admin runs "iptables" to manipulate netfilter rules in the
kernel. How does it affect the applied and intended configurations?

A. The change isn't reflected in applied configuration. Then applied
   configuration is no more "=E2=80=A6, the configuration state which is
   currently being used by server components (e.g., control plane
   daemons, operating system kernels, line cards)."

B. The change is reflected in applied but not in intended
   configuration. This violates requirement 1 sub D, and also it may be
   impossible to map the kernel changes back to the configuration.

For sure, these problems exist also with the good old "running", but I
think the migration to intended-applied would just make things worse.

Lada


>
> Andy, did I get this right?
>
> /js
>
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Mon Dec 21 06:21:32 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956301A6FD8 for ; Mon, 21 Dec 2015 06:21:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 Kg56V2gCfEt9 for ; Mon, 21 Dec 2015 06:21:28 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 1C68C1A6FE3 for ; Mon, 21 Dec 2015 06:21:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450707656; bh=k4+/AuA6zL/SrCJpXHRvXoMPKZejCuza0xmDG4yXlZk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=BlWdMi1Jw5PEbaofm1hWuVc3pLAnIrvpzTtR2zKL1AHANZTrDFvh3OkV99klBC04r /6gqXesumfWvLf1DFzNKfpNk92cCL0xFttkr+7Xih3qo1KOeeqeGiN5MJXM+XB6DzM u9R6gN28hC9JF3t3HK70Q3qKhNVwCLxjpEiXnFnE=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Nadeau Thomas 
In-Reply-To: 
Date: Mon, 21 Dec 2015 09:20:43 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <50D3D17E-41E0-4A5F-BA55-CA5765CCF87B@lucidvision.com>
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net> <0239ADFB-4A52-4E47-8FA5-406231AD92D5@lucidvision.com> <20151217172931.GA68858@elstar.local> 
To: Ladislav Lhotka 
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=4 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 220, in=2925, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 14:21:30 -0000

> On Dec 21, 2015:8:55 AM, at 8:55 AM, Ladislav Lhotka  =
wrote:
>=20
> Juergen Schoenwaelder  writes:
>=20
>> On Thu, Dec 17, 2015 at 10:52:13AM -0500, Nadeau Thomas wrote:
>>>=20
>>>> On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen =
 wrote:
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>>>> I=E2=80=99m struggling a bit to understand what is motivating =
you to ask this question.    That is, as a tool vendor, I wouldn=E2=80=99t=
 think that any decision made here would affect you immediately.   My =
expectations are that any impact to YANG/NETCONF/RESTCONF would be =
backwards compatible, such that implementations would only opt-in when =
needed - a pay as you grow strategy.   But herein perhaps lies an =
unstated requirement, that the impact to YANG/NETCONF/RESTCONF needs to =
be backwards compatible with respect to existing deployments.  Did we =
miss it or is it too obvious?
>>>>>>>=20
>>>>>>=20
>>>>>> It may be obvious for many of us but for the sake of completeness =
I
>>>>>> prefer to have this backwards compatibility assumption =
explicitely
>>>>>> stated.
>>>>>=20
>>>>> +1
>>>>=20
>>>>=20
>>>> [as a chair]
>>>>=20
>>>> As last call comment, there seems to be support for adding a =
requirement to the opstate-reqs draft to state that solutions supporting =
said requirements MUST be backwards compatible with respect to existing =
deployments.  Do we have WG consensus to add this as a requirement to =
this draft?  Are there any objections? Please voice your opinion before =
the last call cutoff date (Dec 30).
>>>>=20
>>>>=20
>>>> [as a contributor]
>>>>=20
>>>>=20
>>>> I=E2=80=99m unsure if it makes sense to call it out in this draft, =
in that it seems universally applicable, but I don=E2=80=99t see any =
harm in it either and thus do not object.
>>>>=20
>>>>=20
>>>> Kent
>>>=20
>>> 	[As Co-chair]
>>>=20
>>> 	Given the tall hill we climbed to get to this point on the =
requirements, I
>>> want to be clear that there needs to be very significant support to =
change the requirements
>>> in any significant way. We went round and round the drain on =
settling on these requirements, and=20
>>> people had a whole host of reasonable opportunities to add this =
during those times. I want to point out that while this statement may =
seem subtle, slipping this in at the last minute could have a profound =
impact on solutions built from these requirements, so I want to be sure =
everyone involved has through through this kind of change.
>>>=20
>>> 	=E2=80=94Tom
>>=20
>> Tom,
>>=20
>> I think Andy is talking about applicability - to which kind of =
servers
>> do these requirements apply. For example, if it takes more time on a
>> certain class of devices to retrieve the difference between applied
>> and intended config than it takes to turn intended config into =
applied
>> config, then these requirements may not be applicable (since by the
>> time you have finished retrieving the difference it has vanished).
>=20
> I think it is not only matter of synchronisation delays between =
intended
> and applied configuration. I have serious troubles understanding how
> these concepts map to the class of devices I am mainly interested in.
>=20
> Let me give you an example: An OpenWRT router runs a NETCONF/RESTCONF
> server that supports intended and applied config. Assume the server
> implements modules of the acl-model family so that firewall rules can =
be
> configured through NETCONF/RESTCONF. Great.
>=20
> Now an admin runs "iptables" to manipulate netfilter rules in the
> kernel. How does it affect the applied and intended configurations?
>=20
> A. The change isn't reflected in applied configuration. Then applied
>   configuration is no more "=E2=80=A6, the configuration state which =
is
>   currently being used by server components (e.g., control plane
>   daemons, operating system kernels, line cards)."
>=20
> B. The change is reflected in applied but not in intended
>   configuration. This violates requirement 1 sub D, and also it may be
>   impossible to map the kernel changes back to the configuration.
>=20
> For sure, these problems exist also with the good old "running", but I
> think the migration to intended-applied would just make things worse.
>=20
> Lada

	My note above was not concerned with technical details, but =
rather
procedural. As I noted, we spend numerous hours getting that document
and the agreements around that to the point where it is at by meeting =
with
a lot of people. Those changes are then the result (and consensus) of =
those
many meetings and peoples=E2=80=99 inputs. It is one thing to be making =
minor/editorial
changes, but an entirely other to be making substantive technical =
changes
at the last minute without everyones' buy-in.

	=E2=80=94Tom



>=20
>=20
>>=20
>> Andy, did I get this right?
>>=20
>> /js
>>=20
>> --=20
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | =
Germany
>> Fax:   +49 421 200 3103         
>=20
> --=20
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C


From nobody Mon Dec 21 06:38:08 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 531FD1A86F7 for ; Mon, 21 Dec 2015 06:38:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 c1aZy10M24TR for ; Mon, 21 Dec 2015 06:38:04 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 886401A86F5 for ; Mon, 21 Dec 2015 06:38:03 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:d05f:319f:bb5b:2b32] (unknown [IPv6:2001:718:1a02:1:d05f:319f:bb5b:2b32]) by mail.nic.cz (Postfix) with ESMTPSA id B020B181AC8; Mon, 21 Dec 2015 15:38:01 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450708681; bh=4zdAPHn5Tzfix6r2zEZHV3tEsTC+di6IPLvFDTt7Vh8=; h=From:Date:To; b=xze/mmS3Mc8zUkYurzigKGs/HTxsrB/MfqfcsYfnFh8ws0dtpJHCmymMNLhhae72k N1bTE30kOAJr6VJsbG4XIpl2IawLj/Eu5HnGZuC2ZPE+xgY/vsPrbM+n6+dg2WcAvp oUsVR34aAos1DGDN9UmIGVfD1VNS34euw2agbbsw=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <50D3D17E-41E0-4A5F-BA55-CA5765CCF87B@lucidvision.com>
Date: Mon, 21 Dec 2015 15:38:03 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net> <0239ADFB-4A52-4E47-8FA5-406231AD92D5@lucidvision.com> <20151217172931.GA68858@elstar.local>  <50D3D17E-41E0-4A5F-BA55-CA5765CCF87B@lucidvision.com>
To: Thomas Nadeau 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 14:38:07 -0000

> On 21 Dec 2015, at 15:20, Nadeau Thomas  =
wrote:
>=20
>>=20
>> On Dec 21, 2015:8:55 AM, at 8:55 AM, Ladislav Lhotka  =
wrote:
>>=20
>> Juergen Schoenwaelder  writes:
>>=20
>>> On Thu, Dec 17, 2015 at 10:52:13AM -0500, Nadeau Thomas wrote:
>>>>=20
>>>>> On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen =
 wrote:
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>>>> I=E2=80=99m struggling a bit to understand what is motivating =
you to ask this question.    That is, as a tool vendor, I wouldn=E2=80=99t=
 think that any decision made here would affect you immediately.   My =
expectations are that any impact to YANG/NETCONF/RESTCONF would be =
backwards compatible, such that implementations would only opt-in when =
needed - a pay as you grow strategy.   But herein perhaps lies an =
unstated requirement, that the impact to YANG/NETCONF/RESTCONF needs to =
be backwards compatible with respect to existing deployments.  Did we =
miss it or is it too obvious?
>>>>>>>>=20
>>>>>>>=20
>>>>>>> It may be obvious for many of us but for the sake of =
completeness I
>>>>>>> prefer to have this backwards compatibility assumption =
explicitely
>>>>>>> stated.
>>>>>>=20
>>>>>> +1
>>>>>=20
>>>>>=20
>>>>> [as a chair]
>>>>>=20
>>>>> As last call comment, there seems to be support for adding a =
requirement to the opstate-reqs draft to state that solutions supporting =
said requirements MUST be backwards compatible with respect to existing =
deployments.  Do we have WG consensus to add this as a requirement to =
this draft?  Are there any objections? Please voice your opinion before =
the last call cutoff date (Dec 30).
>>>>>=20
>>>>>=20
>>>>> [as a contributor]
>>>>>=20
>>>>>=20
>>>>> I=E2=80=99m unsure if it makes sense to call it out in this draft, =
in that it seems universally applicable, but I don=E2=80=99t see any =
harm in it either and thus do not object.
>>>>>=20
>>>>>=20
>>>>> Kent
>>>>=20
>>>> 	[As Co-chair]
>>>>=20
>>>> 	Given the tall hill we climbed to get to this point on the =
requirements, I
>>>> want to be clear that there needs to be very significant support to =
change the requirements
>>>> in any significant way. We went round and round the drain on =
settling on these requirements, and=20
>>>> people had a whole host of reasonable opportunities to add this =
during those times. I want to point out that while this statement may =
seem subtle, slipping this in at the last minute could have a profound =
impact on solutions built from these requirements, so I want to be sure =
everyone involved has through through this kind of change.
>>>>=20
>>>> 	=E2=80=94Tom
>>>=20
>>> Tom,
>>>=20
>>> I think Andy is talking about applicability - to which kind of =
servers
>>> do these requirements apply. For example, if it takes more time on a
>>> certain class of devices to retrieve the difference between applied
>>> and intended config than it takes to turn intended config into =
applied
>>> config, then these requirements may not be applicable (since by the
>>> time you have finished retrieving the difference it has vanished).
>>=20
>> I think it is not only matter of synchronisation delays between =
intended
>> and applied configuration. I have serious troubles understanding how
>> these concepts map to the class of devices I am mainly interested in.
>>=20
>> Let me give you an example: An OpenWRT router runs a NETCONF/RESTCONF
>> server that supports intended and applied config. Assume the server
>> implements modules of the acl-model family so that firewall rules can =
be
>> configured through NETCONF/RESTCONF. Great.
>>=20
>> Now an admin runs "iptables" to manipulate netfilter rules in the
>> kernel. How does it affect the applied and intended configurations?
>>=20
>> A. The change isn't reflected in applied configuration. Then applied
>>  configuration is no more "=E2=80=A6, the configuration state which =
is
>>  currently being used by server components (e.g., control plane
>>  daemons, operating system kernels, line cards)."
>>=20
>> B. The change is reflected in applied but not in intended
>>  configuration. This violates requirement 1 sub D, and also it may be
>>  impossible to map the kernel changes back to the configuration.
>>=20
>> For sure, these problems exist also with the good old "running", but =
I
>> think the migration to intended-applied would just make things worse.
>>=20
>> Lada
>=20
> 	My note above was not concerned with technical details, but =
rather
> procedural. As I noted, we spend numerous hours getting that document
> and the agreements around that to the point where it is at by meeting =
with
> a lot of people. Those changes are then the result (and consensus) of =
those
> many meetings and peoples=E2=80=99 inputs. It is one thing to be =
making minor/editorial
> changes, but an entirely other to be making substantive technical =
changes
> at the last minute without everyones' buy-in.

I did ask these questions previously but only got hand-waving or =
procedural answers (like yours). Therefore, I want to make sure that =
this intended-applied thing isn't the only way that will be supported =
from now on. That's all.

Thanks, Lada

>=20
> 	=E2=80=94Tom
>=20
>=20
>=20
>>=20
>>=20
>>>=20
>>> Andy, did I get this right?
>>>=20
>>> /js
>>>=20
>>> --=20
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | =
Germany
>>> Fax:   +49 421 200 3103         
>>=20
>> --=20
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon Dec 21 06:47:37 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F4A1A879F for ; Mon, 21 Dec 2015 06:47:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 XzyOK0Ft8OxL for ; Mon, 21 Dec 2015 06:47:33 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F6301A870D for ; Mon, 21 Dec 2015 06:47:33 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2FB3A78A; Mon, 21 Dec 2015 15:47:31 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id V0PAxf4D0VBh; Mon, 21 Dec 2015 15:47:30 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 21 Dec 2015 15:47:30 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2FD1F20056; Mon, 21 Dec 2015 15:47:30 +0100 (CET)
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 KV1inng7zoih; Mon, 21 Dec 2015 15:47:29 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 47EAE20055; Mon, 21 Dec 2015 15:47:27 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 1AD83395FCF7; Mon, 21 Dec 2015 15:47:25 +0100 (CET)
Date: Mon, 21 Dec 2015 15:47:24 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20151221144723.GA43211@elstar.local>
Mail-Followup-To: Ladislav Lhotka , NETMOD WG 
References: <1033983.1450551979726.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 14:47:35 -0000

I believe the model we have agreed on in RFC 6020 is this:

- YANG modules in I-Ds are 'development' modules and not 'published'
  modules.

- It helps a lot during module development if 'development' modules
  are actually implemented. Note that implementations of 'development'
  modules are not intended to be 'deployed'.

- A 'published' module (something appearing in an RFC in the IETF)
  will be subject to YANG update rules.

- 'Published' modules are expected to be 'implemented' and 'deployed'.

- IETF WGs need to take care of the maintenance and interoperability
  of what has been 'published', hence the module update rules.

- Obviously, it is good to detect major flaws during 'development' and
  hence the importance of early 'implementation' experience.

Note that there are no formal module name or namespace assignements
until a module has been published as an RFC. A WG might put in a best
guess what the names might be but assignment and registration via IANA
happens during the publication process.

Perhaps it helps to clarify in RFC6020bis that the updates rules apply
to published modules and not to modules under development.

/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 Dec 21 07:05:36 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B801A8828 for ; Mon, 21 Dec 2015 07:05:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 ZLY2-MpBJeMT for ; Mon, 21 Dec 2015 07:05:33 -0800 (PST)
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 8ADB11A8874 for ; Mon, 21 Dec 2015 07:05:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5391; q=dns/txt; s=iport; t=1450710332; x=1451919932; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=zIa3b3F5ldrd+mtksCyFljvi4UuDwKqFykRG8xmrN28=; b=Ie1PBu3dqh2UzAHxi8LmnXxnlAlLC2viF9jfDmUJ1j9PGtzyjpBBjw4S 84Wlt2Hd751DLmHBRE728WJtw12alyvkgEG8saY/55C5sZzFqncHCpSGV gzHF8TjSwIgEOVKHbXAWQ757OzeWOA2sB5XU3pgrJspjOxwNT4n3WWzK7 A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBAB9FHhW/xbLJq1aA4QMbYxSrwaEC?= =?us-ascii?q?x2FcAKBcwEBAQEBAYELhDQBAQEDASMPAQVADwILEAgCAgUWCwICCQMCAQIBCTw?= =?us-ascii?q?GAQwGAgEBF4gMCKw6hlQWAQECAYtHAQEBAQEBAQMBAQEBAQEBAQEaBH2FVYR+h?= =?us-ascii?q?EI6JoJVgUkFlwCNS4FchEWDBZASg3RkghEdgVY+NIUsAQEB?=
X-IronPort-AV: E=Sophos;i="5.20,459,1444694400"; d="scan'208";a="609209458"
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; 21 Dec 2015 15:05:30 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tBLF5UWJ024769; Mon, 21 Dec 2015 15:05:30 GMT
To: Ladislav Lhotka , "netmod@ietf.org" 
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net> <0239ADFB-4A52-4E47-8FA5-406231AD92D5@lucidvision.com> <20151217172931.GA68858@elstar.local> 
From: Robert Wilton 
Message-ID: <56781538.7010402@cisco.com>
Date: Mon, 21 Dec 2015 15:05:28 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 15:05:34 -0000

Hi Lada,

On 21/12/2015 13:55, Ladislav Lhotka wrote:
> Juergen Schoenwaelder  writes:
>
>> On Thu, Dec 17, 2015 at 10:52:13AM -0500, Nadeau Thomas wrote:
>>>> On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen  wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>>> I’m struggling a bit to understand what is motivating you to ask this question.    That is, as a tool vendor, I wouldn’t think that any decision made here would affect you immediately.   My expectations are that any impact to YANG/NETCONF/RESTCONF would be backwards compatible, such that implementations would only opt-in when needed - a pay as you grow strategy.   But herein perhaps lies an unstated requirement, that the impact to YANG/NETCONF/RESTCONF needs to be backwards compatible with respect to existing deployments.  Did we miss it or is it too obvious?
>>>>>>>
>>>>>> It may be obvious for many of us but for the sake of completeness I
>>>>>> prefer to have this backwards compatibility assumption explicitely
>>>>>> stated.
>>>>> +1
>>>>
>>>> [as a chair]
>>>>
>>>> As last call comment, there seems to be support for adding a requirement to the opstate-reqs draft to state that solutions supporting said requirements MUST be backwards compatible with respect to existing deployments.  Do we have WG consensus to add this as a requirement to this draft?  Are there any objections? Please voice your opinion before the last call cutoff date (Dec 30).
>>>>
>>>>
>>>> [as a contributor]
>>>>
>>>>
>>>> I’m unsure if it makes sense to call it out in this draft, in that it seems universally applicable, but I don’t see any harm in it either and thus do not object.
>>>>
>>>>
>>>> Kent
>>> 	[As Co-chair]
>>>
>>> 	Given the tall hill we climbed to get to this point on the requirements, I
>>> want to be clear that there needs to be very significant support to change the requirements
>>> in any significant way. We went round and round the drain on settling on these requirements, and
>>> people had a whole host of reasonable opportunities to add this during those times. I want to point out that while this statement may seem subtle, slipping this in at the last minute could have a profound impact on solutions built from these requirements, so I want to be sure everyone involved has through through this kind of change.
>>>
>>> 	—Tom
>> Tom,
>>
>> I think Andy is talking about applicability - to which kind of servers
>> do these requirements apply. For example, if it takes more time on a
>> certain class of devices to retrieve the difference between applied
>> and intended config than it takes to turn intended config into applied
>> config, then these requirements may not be applicable (since by the
>> time you have finished retrieving the difference it has vanished).
> I think it is not only matter of synchronisation delays between intended
> and applied configuration. I have serious troubles understanding how
> these concepts map to the class of devices I am mainly interested in.
>
> Let me give you an example: An OpenWRT router runs a NETCONF/RESTCONF
> server that supports intended and applied config. Assume the server
> implements modules of the acl-model family so that firewall rules can be
> configured through NETCONF/RESTCONF. Great.
>
> Now an admin runs "iptables" to manipulate netfilter rules in the
> kernel. How does it affect the applied and intended configurations?
>
> A. The change isn't reflected in applied configuration. Then applied
>     configuration is no more "…, the configuration state which is
>     currently being used by server components (e.g., control plane
>     daemons, operating system kernels, line cards)."
>
> B. The change is reflected in applied but not in intended
>     configuration. This violates requirement 1 sub D, and also it may be
>     impossible to map the kernel changes back to the configuration.
>
> For sure, these problems exist also with the good old "running", but I
> think the migration to intended-applied would just make things worse.
If I understand your example correctly, then the complexity in your 
scenario is that what is actually written in the hardware is controlled 
by two independent management entities.  Is that right?

If so I think that your scenario is outside what could be reasonably 
expected to be defined by a standards specification.

Ideally, all of the related configuration would be managed by the same 
YANG data model, in which case I would expect that your problem would 
disappear.

Pragmatically, I suspect that you can't do that, in which case I would 
model the opstate requirements as only applying to the YANG part of the 
configuration.  I.e. the ACL model is in applied configuration applied 
if it is regarded as being a valid input to what is being programmed 
into the system.  What is actually programmed in the forwarding filter 
depends on both the accepted ACL YANG configuration and also the other 
independent configuration.

Thanks,
Rob


>
> Lada
>
>
>> Andy, did I get this right?
>>
>> /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 Dec 21 07:07:09 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DD01A8881 for ; Mon, 21 Dec 2015 07:07:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 xpKehkKG1rXG for ; Mon, 21 Dec 2015 07:07:06 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id BD4131A87C5 for ; Mon, 21 Dec 2015 07:07:06 -0800 (PST)
Received: from stubbs.local.chopps.org (75-128-113-61.dhcp.aldl.mi.charter.com [75.128.113.61]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id D7A0B60B0E; Mon, 21 Dec 2015 15:07:05 +0000 (UTC)
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net> <0239ADFB-4A52-4E47-8FA5-406231AD92D5@lucidvision.com> <20151217172931.GA68858@elstar.local> 
User-agent: mu4e 0.9.15; emacs 24.5.1
From: Christian Hopps 
To: Ladislav Lhotka 
In-reply-to: 
Date: Mon, 21 Dec 2015 10:07:04 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 15:07:08 -0000

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Ladislav Lhotka  writes:
>> Tom,
>>
>> I think Andy is talking about applicability - to which kind of servers
>> do these requirements apply. For example, if it takes more time on a
>> certain class of devices to retrieve the difference between applied
>> and intended config than it takes to turn intended config into applied
>> config, then these requirements may not be applicable (since by the
>> time you have finished retrieving the difference it has vanished).
>
> I think it is not only matter of synchronisation delays between intended
> and applied configuration. I have serious troubles understanding how
> these concepts map to the class of devices I am mainly interested in.
>
> Let me give you an example: An OpenWRT router runs a NETCONF/RESTCONF
> server that supports intended and applied config. Assume the server
> implements modules of the acl-model family so that firewall rules can be
> configured through NETCONF/RESTCONF. Great.
>
> Now an admin runs "iptables" to manipulate netfilter rules in the
> kernel. How does it affect the applied and intended configurations?
>
> A. The change isn't reflected in applied configuration. Then applied
>    configuration is no more "=E2=80=A6, the configuration state which is
>    currently being used by server components (e.g., control plane
>    daemons, operating system kernels, line cards)."
>
> B. The change is reflected in applied but not in intended
>    configuration. This violates requirement 1 sub D, and also it may be
>    impossible to map the kernel changes back to the configuration.
>
> For sure, these problems exist also with the good old "running", but I
> think the migration to intended-applied would just make things worse.

Perhaps I'm misunderstanding the example, but it seems you have a setup
where your netconf/restconf server isn't in sync with actual
configuration of the device, regardless of whether is implements these
requirements or not.

Why isn't this a non-starter? I mean it seems to me that you don't need
to worry about new operational state requirements until the most basic
functionality is working.

Thanks,
Chris.


>
> Lada
>
>
>>
>> Andy, did I get this right?
>>
>> /js
>>
>> --=20
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103         


--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWeBWZAAoJEC4dgw7XuDAlM38P/iF+0t/KOMIrZXaxfct4dp1n
7ZAeqo0UNTCb4uQTL2mPe/6urOfMcyvuA/8A06dkFvifbj/oGAy8hi9P88M2qyPx
OL+xUWeHVtM1FLffIjhGJmplDQoA5SNxUzZtHF9Y51A3fXqJNUqcuRS4hl/ju5sJ
oCJHpBh0RP/dKnRiCnUQc3AZCQcTzd/6iXdMWTZ223FAabzz3dYNURbV1GbVgjxj
4hyW4rh7cXrvHQ/EPXqCFty3Qfq8pjKiCReIJ4nZUuCQ8My2sLZBzNoaiIVJT65l
QeUqt/k85yUBXFpux7nmf/3dQpoJPD5lPOgyGltA5NuTgTuV+Vqn97fPzmPhoQG2
C/JMlRj4tmEurQbllugWKN34IpY5Mwf2Q2hQv3qe3AXAnGyrTWLdfId9bWO/jPOn
nYd034L1rgR2aPtCL1YNCKPiK+p+1+JyuDxnxmTsi5AlslO8H651hREUawQudPiC
zlMNO8MucVfeTkL73GtvZR6CaZqcsr+4rAW+a+POAkpggPoUiZ8Dqi31zbpTyDjU
wzRFZRwapKbWvjvOX0CXiFLps0ILgFj4q9bG7BGaRwNutSTY4Sizg5N8V6qcudV4
6lEFXovq+hXWksEONAGkGVxetZs++yPmqXlPCFOrxmPHmBjYf5H3RsKxTHDcHxWO
UiPNhP+VLkON8pebtzif
=lTcL
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Mon Dec 21 07:07:23 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064C31A8874 for ; Mon, 21 Dec 2015 07:07:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.361
X-Spam-Level: 
X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 1b30sTKAjDUT for ; Mon, 21 Dec 2015 07:07:20 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E761A87C5 for ; Mon, 21 Dec 2015 07:07:20 -0800 (PST)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 4E09C1812CB; Mon, 21 Dec 2015 16:07:19 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450710439; bh=fd0bQnMHUj0/pA3w88IIWY1av2xISskz1QLVZ8sXLUE=; h=From:Date:To; b=Z42Ow6GQOfQxA+I/4plXsH4EVgzEEzGRdIpQb0IRag5aIJ5Ac6paZD3AfvofmAyeT 0x2JetbxnzEMeh2diT7CdvVwdGLXGQ6xUnPo8bRLlaniW8mPCRiUi+L4HVexjhqDbW QaDZdAZJvZJLX+NRtD3tBbzj2XFWoA4C0FB8n27g=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <20151221144723.GA43211@elstar.local>
Date: Mon, 21 Dec 2015 16:07:20 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5E9674F3-DDAB-479F-A8CA-0CF78FE5F1F2@nic.cz>
References: <1033983.1450551979726.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>  <20151221144723.GA43211@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 15:07:22 -0000

> On 21 Dec 2015, at 15:47, Juergen Schoenwaelder =
 wrote:
>=20
> I believe the model we have agreed on in RFC 6020 is this:
>=20
> - YANG modules in I-Ds are 'development' modules and not 'published'
>  modules.

Section 10 makes no distinction between development and published =
modules, except that for published modules a new "revision" statement =
MUST be included in front of the existing "revision" statements.

>=20
> - It helps a lot during module development if 'development' modules
>  are actually implemented. Note that implementations of 'development'
>  modules are not intended to be 'deployed'.

Absolutely, but this requires that development modules also carry =
revision information - otherwise clients won't be able to figure out the =
data model.

>=20
> - A 'published' module (something appearing in an RFC in the IETF)
>  will be subject to YANG update rules.

Are you saying that other SDOs may adopt different rules, and that these =
rules don't apply to proprietary modules?

>=20
> - 'Published' modules are expected to be 'implemented' and 'deployed'.
>=20
> - IETF WGs need to take care of the maintenance and interoperability
>  of what has been 'published', hence the module update rules.
>=20
> - Obviously, it is good to detect major flaws during 'development' and
>  hence the importance of early 'implementation' experience.
>=20
> Note that there are no formal module name or namespace assignements
> until a module has been published as an RFC. A WG might put in a best
> guess what the names might be but assignment and registration via IANA
> happens during the publication process.
>=20
> Perhaps it helps to clarify in RFC6020bis that the updates rules apply
> to published modules and not to modules under development.

Yes, some clarification is needed in any case.

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon Dec 21 07:33:28 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C30C81A904E; Mon, 21 Dec 2015 07:33:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.961
X-Spam-Level: 
X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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_lAQy5f5Mxx; Mon, 21 Dec 2015 07:33:24 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 199391A8AB2; Mon, 21 Dec 2015 07:33:24 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D4E231007; Mon, 21 Dec 2015 16:33:22 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id nUmJQ9de-Tws; Mon, 21 Dec 2015 16:33:20 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 21 Dec 2015 16:33:20 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DBCCD20056; Mon, 21 Dec 2015 16:33:19 +0100 (CET)
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 8qus6r_AZ-n0; Mon, 21 Dec 2015 16:33:17 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4060D20055; Mon, 21 Dec 2015 16:33:16 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 9C24F395FD95; Mon, 21 Dec 2015 16:33:14 +0100 (CET)
Date: Mon, 21 Dec 2015 16:33:13 +0100
From: Juergen Schoenwaelder 
To: Dean Bogdanovic 
Message-ID: <20151221153312.GA43316@elstar.local>
Mail-Followup-To: Dean Bogdanovic , Nadeau Thomas , Benoit Claise , RTG YANG Design Team , netmod WG 
References:  <20151211113156.GA43862@elstar.local> <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com>
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: <2059AD77-5375-4DB0-A1BF-432835F11A9F@gmail.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: RTG YANG Design Team , netmod WG , Benoit Claise 
Subject: Re: [netmod] [Rtg-dt-yang-arch] [yang-doctors] Working group Last Call: draft-ietf-netmod-acl-model-06
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 15:33:27 -0000

On Sat, Dec 19, 2015 at 07:50:58AM -0500, Dean Bogdanovic wrote:
> Juergen,
> 
> Please see answers inline
> 
> Dean
> 
> > On Dec 11, 2015, at 12:31 PM, Juergen Schoenwaelder  wrote:
> > 
> > On Wed, Dec 09, 2015 at 08:27:04AM -0800, Nadeau Thomas wrote:
> >> 
> >> 	This email initiates a NETMOD WG Last call for draft-ietf-netmod-acl-model-06. 
> >> Please review the draft and make any comments to the list by Wednesday, 16 December, 2015
> >> by 8AM EST.
> >> 
> > 
> > Technical
> > 
> > - I am not sure I personally like the acl-oper-data and ace-oper-data
> >  containers in the middle of the config true tree. I understand that
> >  operational state in this case is likely tightly bound to the
> >  lifetime of the config state but I also generally prefer to have a
> >  clean separation of config from state. But since I am not
> >  implementing this, I am happy to leave the decision to those who
> >  write the code.
> > 
> > - I would probably have used src-ipv4-prefix and dst-ipv4-prefix
> >  instead of source-ipv4-network and destination-ipv4-network and
> >  I would probably have used src-mac-address and src-mac-address-mask
> >  and dst-mac-address and dst-mac-address-mask. Generally simple
> >  src instead source and dst instead destination - lines up all
> >  much more nicely.
> 
> I know that src and dst are pretty standard abbreviations, but have preference to use full words.
>

My eyes prefer the shorter versions but it might be subjective where
the line between arconyms and words is drawn. For me, things are not
done consistently according to my personal preferences. ;-)

> > - I would have put the acl-name and acl-type first followed by the
> >  entries list.
> 
> Can you please expand on this? Is there any major difference? OR just design choice?

Technically you can define key leafs anywhere but I think there are some
benefits of defining them at the beginning of a list:

a) I find it nice if the leafs listed in the key statement follow the
   key statement and not N pages down the document.
b) If you put them at the end and you have to add additional definitions,
   you will end up with leafs somewhere in the middle.
c) The XML encoding requires to ship key leafs first and it might be
   simpler if the key leafs are also defined first in the data model
   (so if you use the same order, you actually get things correct).

Now you tell me what the advantages are to put them at the end...

> > - I also wonder why we use both the term 'entry' and 'rule', why not
> >  pick one of them? You have for example rule-name (which is the key
> >  of the list but again comes last).
> This is a bit of compromise between Cisco and Juniper terminology. In Cisco it is ACE and in Juniper term. But in the yang model and in the text we are using consistently one or the other word.

For the sake of clarity, I personally would prefer to have a single
term. I think Linux packet filters call things rules. I think BSD
packet filtering calls things rules. Wikipedia seem say that packet
filters consist of filtering rules... So I guess I have a preference
but I will not get a sleepless night over this.
 
> > - Should there be features for ace-eth and ace-ipv4 and ace-ipv6 or do
> >  we expect that all implementations will always support all three?
> >  Another option would be to have the generic model completely without
> >  any protocol specific elements and to have separate models to
> >  augment in ipv4, ipv6, and ethernet specific ace types. I actually
> >  think this would make much more sense since you would not have a
> >  module 'packet fields' but instead a clear extension of the
> >  ietf-access-control-list module. You could also drop the examples
> >  how to extend the core model since the ip and ethernet extensions
> >  would already serve the purpose. You also would not need features
> >  since an implementation advertises the extension modules.
> 
> We started early with such design, but then the WG feedback moved us to the current  design.

Can you provide pointers to minutes etc? I think the routing model
also has a core model where even unicast routing is augmented in. This
seems to make the boundary between the generic infrastructure and the
addins very clear.
 
> > - The 'uses packet-fields:metadata' resolves to a leaf
> >  'input-interface' which is of type string. Is this the only metadata
> >  field we ever envision to be there? If so, why not make it part of
> >  the base model? If not, what is the extensibility model here?  
> 
> It can be used for route filtering

Yeah, but the questions were:

- Is this the only metadata field we ever envision to be there?
- If so, why not make it part of the base model?
- If not, what is the extensibility model here?

> > And
> >  should the interface reference not use a more specific type than
> >  'string’?
> 
> Interface references can be many things, from standard naming we are familiar, e.g. ge-1/0/0.1 to a numerical value like 13276. Leaving it as string gives us most flexibility in that regards.

I disagree that the goal here is most flexibility. We do have an
interfaces data model in the IETF. Why are we avoiding to refer to it
here?

> > - Some implementations support the action to jump or goto other
> >  acls. Is this not common enough to include it as a base action,
> >  perhaps protected by a feature?
> 
> Yes among vendors, but it can be very specific. Example, in Juniper implementation there are two types of filters, classical and Fast Update Filters (FUF). Classic filters support (on specific HW platforms) filter as action, but FUF does not. Not all terms and not all actions are supported on FUFs. So you have to see what filter type and what platform it is, in order to such a specific action.

What speaks against making jump and/or call actions a feature?

> > - In the example in section 4.3, does the CLI shown really help much?
> >  The syntax is pretty system specific.
> 
> OTH, it is widely understood and self explanatory.

The question was whether it is needed to show system specific CLI.
BTW, I note that the textual description says "deny ... from
_leaving_".  How is the 'from leaving' translated into the XML? Is
there any distinction between input and output filters (or forwarding
filters or whatever your engine supports)?

> > In the XML shown, can you not
> >  leave out all the fields that are not set? This would remove a lot
> >  of noise. I do not understand what having both actions deny and
> >  permit at the same time means. Did you validate the example against
> >  the data model? (I also find the keys at the end somewhat strange
> >  and not that NETCONF XML serialization actually requires the keys to
> >  be sent first.)

> We used pyang sample xml skeleton to create the xml example.

Whatever, the noise does not really help and the example might even
mislead people to believe they have to write down all unused leafs.
 
> Leaving both actions in the document is my fault. In the model, action is a choice, and it was a bad copy paste job. Didn’t choose :)
> > 
> > - The clarification whether the boundary port numbers are included in
> >  a port range should be in the YANG model. The YANG model should also
> >  say what it means if one of the ranges is not present. We should not
> >  define the semantics by examples.
> I’m loosing you here. We are stating in the model if the boundary port numbers are included in a port rang.

Ack, I found it in the description of container source-port-range (and
previously I looked at lower-port and upper-port).

> > 
> > - I do not understand section 5. It shows some nftables syntax but
> >  does not really shed a light on what the example shown does or how
> >  that maps to the YANG data model. So I am left somewhat clueless.
> 
> Just wanted to point out that the basic structure of iptables is similar to ACL yang model, so a translation from one to the other should be a  simple process. If someone wants to make it compliant.

It escapes me how the iptables fragment shown in page 18 maps to the
YANG model. What is the substance behind the statement "It should be
fairly easy to do translation between ACL YANG model described in this
draft and Linux nftables."? Has someone done a mapping? It is not
obvious to me how this works.

> > - Can I trigger multiple actions from an ace? Or do I have to
> >  replicate the ace to do that? In general, there is extension of
> >  a choice (means one of several) and there are extension of a
> >  choice already present.
> Again, this is very platform dependent, so didn’t want to include it in the base model.
>

So what would I do if I want to 'log' and 'deny'? Even if the base
model does not do that, how can I augment this in? The base model must
provide the necessary extensibility hooks.

> > - Empty description statements or descriptions statements "(null)"
> >  need to be fixed.
> 
> There are no empty descriptions. You are probably referring to ietf-packet-fields.yang model. There is a bug in pyang which was reported to Martin and fixed since.

I am talking about this (page 25):

      description "(null)";
 
> > - I am a bit surprised that we do not define how to attach an ACL to
> >  an interfaces or a set of interfaces given that we do have an
> >  interfaces YANG data model. The example given in A.3 makes me wonder
> >  why there should be a counter in the interfaces config tree. The
> >  targets/interface-name back-reference seems to indicate that I can
> >  attach an ACL only to a single interface.
> 
> I wasn’t the author of that section

This is a WG document so this needs to be resolved.

> > - I do not understand A.4 at all. Defining an identity does not make
> >  the choice work differently.
> > 
> > - Has someone tried to implement this?
> 
> Was working on implementation while at my previous employer, but am not aware of any other implementation.

I believe it will help a lot to have prototype implementations of this
data model in order to make sure the model does actually work and
provides the extensibility hooks that are necessary. In particular, I
would feel much more convinced if it would be clear (as a proof of
concept) how the model maps to say Linux packet filters. I would
actually not mind if mapping examples from the data model to various
filtering engines would be in the appendix. This would give evidence
that people have actually worked through a couple of concrete
examples.

/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 Dec 21 07:37:29 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737241A9057 for ; Mon, 21 Dec 2015 07:37:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 r67DFi5kigXo for ; Mon, 21 Dec 2015 07:37:27 -0800 (PST)
Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 D7BDC1A905C for ; Mon, 21 Dec 2015 07:37:24 -0800 (PST)
Received: by mail-lf0-x233.google.com with SMTP id l133so112873445lfd.2 for ; Mon, 21 Dec 2015 07:37:24 -0800 (PST)
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:date:message-id:subject:from:to :content-type; bh=GPuCRbKCUcDw12dZ5WfkGwQrc8FHFotVvyDf/BhL0VE=; b=1EyqaYtCNAlsiYr8UQwN4amTlKI5q70eB6ryWun06D5RK66HiicUMyfT6Yezd//gii qcY7J3jijPRKML319Pc0hnEmLFU1f8fToC4juUNNsBB31WUPl51LEJtI0MdaYNiaK/jt z5mLuCzh7zEvYBT1wq1PK4YD/gdr7zvx1u80BbhxKh0gXK8BaYNF/h0m2jC9M4tZjErN SNjSUJIr9sQYdi/xBJ+mNh+LcjRy/XXiOQqMp4cY9AI8U+tYTSW2zo73Tj41jZt9LAba Qgq1MjxGZWbHXMDcI14RrWv4kmaLabhQghTsMxiAPXdV7B8qs9MKUMSRck81ischsNSH /X/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=GPuCRbKCUcDw12dZ5WfkGwQrc8FHFotVvyDf/BhL0VE=; b=Y860kf8A0+wvzuppGfIg2TMvl8DT1bp+39bGP3wL8tPd3ji2X3uofX/TMlqntmz0ot tMGgRSUGLutB0afkY1LPU2/hJw4mKJCexoUEhMPqE3XF7lq2KMOoqzpBCfZOjQm88rog TAEi75OFs13OnRac5dTwoXuqF3ethnlrVJAvG3RGRU8YumXM0fbnfTwOkzQ+6F942k67 F0CgOLfIAV770jY/bSOAIGkNL8nbgtbehD+PE4JNK4syower+kWb1gXM6WsT+CwWmKcA ISzvraDoLq8HJzd4A8ZO1GxI0BgmsIOA9x/EbfiRAchFInNx4rnSxYU5vPJuasCU3ObY uLYg==
X-Gm-Message-State: ALoCoQmkknNJrj0xW+4muTPBzBECTar0XsPDPykbKNXrftizSVA7nGhe+MEn89odxn/JPZF9hlVupiMk6zwVjlK5aUI+NIyZZA==
MIME-Version: 1.0
X-Received: by 10.25.64.9 with SMTP id n9mr6546346lfa.13.1450712242943; Mon, 21 Dec 2015 07:37:22 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Mon, 21 Dec 2015 07:37:22 -0800 (PST)
In-Reply-To: <20151221144723.GA43211@elstar.local>
References: <1033983.1450551979726.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>  <20151221144723.GA43211@elstar.local>
Date: Mon, 21 Dec 2015 07:37:22 -0800
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , Ladislav Lhotka , NETMOD WG 
Content-Type: multipart/alternative; boundary=001a113ea4f6e996b705276a4389
Archived-At: 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 15:37:28 -0000

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

Hi,

It seems rather fundamental that the members of a standards development
organization
understand the difference between a standard under development and a
standard
published for use.


Andy


On Mon, Dec 21, 2015 at 6:47 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> I believe the model we have agreed on in RFC 6020 is this:
>
> - YANG modules in I-Ds are 'development' modules and not 'published'
>   modules.
>
> - It helps a lot during module development if 'development' modules
>   are actually implemented. Note that implementations of 'development'
>   modules are not intended to be 'deployed'.
>
> - A 'published' module (something appearing in an RFC in the IETF)
>   will be subject to YANG update rules.
>
> - 'Published' modules are expected to be 'implemented' and 'deployed'.
>
> - IETF WGs need to take care of the maintenance and interoperability
>   of what has been 'published', hence the module update rules.
>
> - Obviously, it is good to detect major flaws during 'development' and
>   hence the importance of early 'implementation' experience.
>
> Note that there are no formal module name or namespace assignements
> until a module has been published as an RFC. A WG might put in a best
> guess what the names might be but assignment and registration via IANA
> happens during the publication process.
>
> Perhaps it helps to clarify in RFC6020bis that the updates rules apply
> to published modules and not to modules under development.
>
> /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
>

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


Hi,

It seems rather fundamental that th=
e members of a standards development organization
understand the =
difference between a standard under development and a standard
pu=
blished for use.


Andy

On M=
on, Dec 21, 2015 at 6:47 AM, Juergen Schoenwaelder <j.s=
choenwaelder@jacobs-university.de> wrote:
I believe the model we have agreed on in RFC 6020 is this:


- YANG modules in I-Ds are 'development' modules and not 'publi=
shed'

=C2=A0 modules.



- It helps a lot during module development if 'development' modules=


=C2=A0 are actually implemented. Note that implementations of 'developm=
ent'

=C2=A0 modules are not intended to be 'deployed'.



- A 'published' module (something appearing in an RFC in the IETF)<=
br>
=C2=A0 will be subject to YANG update rules.



- 'Published' modules are expected to be 'implemented' and =
'deployed'.



- IETF WGs need to take care of the maintenance and interoperability

=C2=A0 of what has been 'published', hence the module update rules.=




- Obviously, it is good to detect major flaws during 'development' =
and

=C2=A0 hence the importance of early 'implementation' experience.


Note that there are no formal module name or namespace assignements

until a module has been published as an RFC. A WG might put in a best

guess what the names might be but assignment and registration via IANA

happens during the publication process.



Perhaps it helps to clarify in RFC6020bis that the updates rules apply

to published modules and not to modules under development.



/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





--001a113ea4f6e996b705276a4389--


From nobody Mon Dec 21 07:41:08 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC431A907C for ; Mon, 21 Dec 2015 07:41:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 S2ACazUoZ40f for ; Mon, 21 Dec 2015 07:40:58 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 827DC1A9078 for ; Mon, 21 Dec 2015 07:40:58 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 50F32FFA; Mon, 21 Dec 2015 16:40:57 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 9P3aty-M58tO; Mon, 21 Dec 2015 16:40:56 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 21 Dec 2015 16:40:56 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EA19020056; Mon, 21 Dec 2015 16:40:55 +0100 (CET)
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 yvLCLSwhYmlJ; Mon, 21 Dec 2015 16:40:55 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5DB9720055; Mon, 21 Dec 2015 16:40:54 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 4E02E395FDE2; Mon, 21 Dec 2015 16:40:54 +0100 (CET)
Date: Mon, 21 Dec 2015 16:40:54 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20151221154054.GB43316@elstar.local>
Mail-Followup-To: Ladislav Lhotka , NETMOD WG 
References: <1033983.1450551979726.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>  <20151221144723.GA43211@elstar.local> <5E9674F3-DDAB-479F-A8CA-0CF78FE5F1F2@nic.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <5E9674F3-DDAB-479F-A8CA-0CF78FE5F1F2@nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 15:41:03 -0000

On Mon, Dec 21, 2015 at 04:07:20PM +0100, Ladislav Lhotka wrote:
> 
> > On 21 Dec 2015, at 15:47, Juergen Schoenwaelder  wrote:
> > 
> > I believe the model we have agreed on in RFC 6020 is this:
> > 
> > - YANG modules in I-Ds are 'development' modules and not 'published'
> >  modules.
> 
> Section 10 makes no distinction between development and published modules, except that for published modules a new "revision" statement MUST be included in front of the existing "revision" statements.
>

And I noted in my email that we may have to make section 11 of RFC
6020bis more explicit.

> > - It helps a lot during module development if 'development' modules
> >  are actually implemented. Note that implementations of 'development'
> >  modules are not intended to be 'deployed'.
> 
> Absolutely, but this requires that development modules also carry revision information - otherwise clients won't be able to figure out the data model.
>

I am against regulating development or investing effort to deal with
interoperability of development modules. If someone has to distinguish
the stuff running in your labs, I am sure he/she will find a way to do
so.

> > - A 'published' module (something appearing in an RFC in the IETF)
> >  will be subject to YANG update rules.
> 
> Are you saying that other SDOs may adopt different rules, and that these rules don't apply to proprietary modules?
>

I believe that it is generally up to the organization publishing
modules to define what is a 'published module' and what is a
'development module'. We can only reasonably define this for the
IETF.

> > - 'Published' modules are expected to be 'implemented' and 'deployed'.
> > 
> > - IETF WGs need to take care of the maintenance and interoperability
> >  of what has been 'published', hence the module update rules.
> > 
> > - Obviously, it is good to detect major flaws during 'development' and
> >  hence the importance of early 'implementation' experience.
> > 
> > Note that there are no formal module name or namespace assignements
> > until a module has been published as an RFC. A WG might put in a best
> > guess what the names might be but assignment and registration via IANA
> > happens during the publication process.
> > 
> > Perhaps it helps to clarify in RFC6020bis that the updates rules apply
> > to published modules and not to modules under development.
> 
> Yes, some clarification is needed in any case.
> 
> Lada
> 
> > 
> > /js
> > 
> > -- 
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103         
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 

-- 
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 Dec 21 08:05:46 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D0F1A9080 for ; Mon, 21 Dec 2015 08:05:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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 67-kraFjRBN6 for ; Mon, 21 Dec 2015 08:05:43 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 316521A9079 for ; Mon, 21 Dec 2015 08:05:43 -0800 (PST)
Received: from [IPv6:2a01:5e0:29:ffff:71d0:24c7:d5c4:bb42] (unknown [IPv6:2a01:5e0:29:ffff:71d0:24c7:d5c4:bb42]) by mail.nic.cz (Postfix) with ESMTPSA id 7EB2C1818C3; Mon, 21 Dec 2015 17:05:41 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450713941; bh=37eLUX4QSHlM9x4DsqU6T5Ig0l/sSucL8xI+YXYzqQo=; h=From:Date:To; b=O2jqq/xhcVj04soa2L4y+B4tUq5JvEHQtKn/Oz2xL2VuKKIiHGXfk7iBm9PZVbVQz w93wEtbGBAl2LJNVn/YKCyVxIq9wftPIbICD9A43VhEfp7b3RgwRV36i1V43RUJ6Fm 0XlzEzcC0f70p4zREA+iOLmHPCCOR/DyV52IndGE=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <56781538.7010402@cisco.com>
Date: Mon, 21 Dec 2015 17:05:43 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <3B1154B9-8055-4620-9EBD-861A7F525D94@nic.cz>
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net> <0239ADFB-4A52-4E47-8FA5-406231AD92D5@lucidvision.com> <20151217172931.GA68858@elstar.local>  <56781538.7010402@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 16:05:45 -0000

> On 21 Dec 2015, at 16:05, Robert Wilton  wrote:
>=20
> Hi Lada,
>=20
> On 21/12/2015 13:55, Ladislav Lhotka wrote:
>> Juergen Schoenwaelder  writes:
>>=20
>>> On Thu, Dec 17, 2015 at 10:52:13AM -0500, Nadeau Thomas wrote:
>>>>> On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen =
 wrote:
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>>>> I=E2=80=99m struggling a bit to understand what is motivating =
you to ask this question.    That is, as a tool vendor, I wouldn=E2=80=99t=
 think that any decision made here would affect you immediately.   My =
expectations are that any impact to YANG/NETCONF/RESTCONF would be =
backwards compatible, such that implementations would only opt-in when =
needed - a pay as you grow strategy.   But herein perhaps lies an =
unstated requirement, that the impact to YANG/NETCONF/RESTCONF needs to =
be backwards compatible with respect to existing deployments.  Did we =
miss it or is it too obvious?
>>>>>>>>=20
>>>>>>> It may be obvious for many of us but for the sake of =
completeness I
>>>>>>> prefer to have this backwards compatibility assumption =
explicitely
>>>>>>> stated.
>>>>>> +1
>>>>>=20
>>>>> [as a chair]
>>>>>=20
>>>>> As last call comment, there seems to be support for adding a =
requirement to the opstate-reqs draft to state that solutions supporting =
said requirements MUST be backwards compatible with respect to existing =
deployments.  Do we have WG consensus to add this as a requirement to =
this draft?  Are there any objections? Please voice your opinion before =
the last call cutoff date (Dec 30).
>>>>>=20
>>>>>=20
>>>>> [as a contributor]
>>>>>=20
>>>>>=20
>>>>> I=E2=80=99m unsure if it makes sense to call it out in this draft, =
in that it seems universally applicable, but I don=E2=80=99t see any =
harm in it either and thus do not object.
>>>>>=20
>>>>>=20
>>>>> Kent
>>>> 	[As Co-chair]
>>>>=20
>>>> 	Given the tall hill we climbed to get to this point on the =
requirements, I
>>>> want to be clear that there needs to be very significant support to =
change the requirements
>>>> in any significant way. We went round and round the drain on =
settling on these requirements, and
>>>> people had a whole host of reasonable opportunities to add this =
during those times. I want to point out that while this statement may =
seem subtle, slipping this in at the last minute could have a profound =
impact on solutions built from these requirements, so I want to be sure =
everyone involved has through through this kind of change.
>>>>=20
>>>> 	=E2=80=94Tom
>>> Tom,
>>>=20
>>> I think Andy is talking about applicability - to which kind of =
servers
>>> do these requirements apply. For example, if it takes more time on a
>>> certain class of devices to retrieve the difference between applied
>>> and intended config than it takes to turn intended config into =
applied
>>> config, then these requirements may not be applicable (since by the
>>> time you have finished retrieving the difference it has vanished).
>> I think it is not only matter of synchronisation delays between =
intended
>> and applied configuration. I have serious troubles understanding how
>> these concepts map to the class of devices I am mainly interested in.
>>=20
>> Let me give you an example: An OpenWRT router runs a NETCONF/RESTCONF
>> server that supports intended and applied config. Assume the server
>> implements modules of the acl-model family so that firewall rules can =
be
>> configured through NETCONF/RESTCONF. Great.
>>=20
>> Now an admin runs "iptables" to manipulate netfilter rules in the
>> kernel. How does it affect the applied and intended configurations?
>>=20
>> A. The change isn't reflected in applied configuration. Then applied
>>    configuration is no more "=E2=80=A6, the configuration state which =
is
>>    currently being used by server components (e.g., control plane
>>    daemons, operating system kernels, line cards)."
>>=20
>> B. The change is reflected in applied but not in intended
>>    configuration. This violates requirement 1 sub D, and also it may =
be
>>    impossible to map the kernel changes back to the configuration.
>>=20
>> For sure, these problems exist also with the good old "running", but =
I
>> think the migration to intended-applied would just make things worse.
> If I understand your example correctly, then the complexity in your =
scenario is that what is actually written in the hardware is controlled =
by two independent management entities.  Is that right?

Right, and this is quite typical for systems where users have access to =
a standard Unix shell and/or can install software on their own.

>=20
> If so I think that your scenario is outside what could be reasonably =
expected to be defined by a standards specification.

Why? Such systems could also benefit from NETCONF/RESTCONF and standard =
data models.

>=20
> Ideally, all of the related configuration would be managed by the same =
YANG data model, in which case I would expect that your problem would =
disappear.

It can be managed by the same YANG models as other devices, one can just =
never think that what's in the configuration is also what the system =
uses. The only (reasonably) reliable source for the latter is the /proc =
filesystem, which actually comes close to the definition of applied =
configuration - only its data model is generally very different.  =20

>=20
> Pragmatically, I suspect that you can't do that, in which case I would =
model the opstate requirements as only applying to the YANG=20

Yes, it is not realistic.

> part of the configuration.  I.e. the ACL model is in applied =
configuration applied if it is regarded as being a valid input to what =
is being programmed into the system.  What is actually programmed in the =
forwarding filter depends on both the accepted ACL YANG configuration =
and also the other independent configuration.

Sure, but then applied configuration is of no use.

Lada

>=20
> Thanks,
> Rob
>=20
>=20
>>=20
>> Lada
>>=20
>>=20
>>> Andy, did I get this right?
>>>=20
>>> /js
>>>=20
>>> --=20
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | =
Germany
>>> Fax:   +49 421 200 3103         

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon Dec 21 08:42:52 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C351B1A90C1 for ; Mon, 21 Dec 2015 08:42:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 jxCB6o4Xcp6n for ; Mon, 21 Dec 2015 08:42:48 -0800 (PST)
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 3BB5E1A9078 for ; Mon, 21 Dec 2015 08:42:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8251; q=dns/txt; s=iport; t=1450716168; x=1451925768; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Ttfs0dEXx5++m5ftVqc85hqByU8xSYuSUBFx8JbpFyM=; b=WnMUHVwgzKt09lHupL44uCUacbcYd68LLPs+N92SGThh9a2hUfa9jKiv AR2Uhzz9+67wBTc7fK7JB7TZvoZSUjV+ciG5PRvgF9cFdABG3AW1cifYm USbMhsdHsEUTBlIKfhU6rqBx0r+fjergPDeXYNAXtbb3muTyiwIZilWfB s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuBACoK3hW/xbLJq1bA4QMbYxSrwaEC?= =?us-ascii?q?x2CQIMwAoF1AQEBAQEBgQuENAEBAQMBIw8BBUABDgILEAgCAgUWCwICCQMCAQI?= =?us-ascii?q?BCTwGDQYCAQEXiAwIrF6GVBiLMgEBAQEBAQEBAQEBAQEBAQEBAQEBGQR9hVWEf?= =?us-ascii?q?oRCOiaCVYFJBZcAjUuBXIRFgwWQEoN0ZIIRHYFWPjSFLAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.20,460,1444694400"; d="scan'208";a="609990896"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Dec 2015 16:42:40 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tBLGgdPU003312; Mon, 21 Dec 2015 16:42:40 GMT
To: Ladislav Lhotka 
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net> <0239ADFB-4A52-4E47-8FA5-406231AD92D5@lucidvision.com> <20151217172931.GA68858@elstar.local>  <56781538.7010402@cisco.com> <3B1154B9-8055-4620-9EBD-861A7F525D94@nic.cz>
From: Robert Wilton 
Message-ID: <56782BFD.5080508@cisco.com>
Date: Mon, 21 Dec 2015 16:42:37 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <3B1154B9-8055-4620-9EBD-861A7F525D94@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 16:42:51 -0000

Hi Lada,

On 21/12/2015 16:05, Ladislav Lhotka wrote:
>> On 21 Dec 2015, at 16:05, Robert Wilton  wrote:
>>
>> Hi Lada,
>>
>> On 21/12/2015 13:55, Ladislav Lhotka wrote:
>>> Juergen Schoenwaelder  writes:
>>>
>>>> On Thu, Dec 17, 2015 at 10:52:13AM -0500, Nadeau Thomas wrote:
>>>>>> On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen  wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>>> I’m struggling a bit to understand what is motivating you to ask this question.    That is, as a tool vendor, I wouldn’t think that any decision made here would affect you immediately.   My expectations are that any impact to YANG/NETCONF/RESTCONF would be backwards compatible, such that implementations would only opt-in when needed - a pay as you grow strategy.   But herein perhaps lies an unstated requirement, that the impact to YANG/NETCONF/RESTCONF needs to be backwards compatible with respect to existing deployments.  Did we miss it or is it too obvious?
>>>>>>>>>
>>>>>>>> It may be obvious for many of us but for the sake of completeness I
>>>>>>>> prefer to have this backwards compatibility assumption explicitely
>>>>>>>> stated.
>>>>>>> +1
>>>>>> [as a chair]
>>>>>>
>>>>>> As last call comment, there seems to be support for adding a requirement to the opstate-reqs draft to state that solutions supporting said requirements MUST be backwards compatible with respect to existing deployments.  Do we have WG consensus to add this as a requirement to this draft?  Are there any objections? Please voice your opinion before the last call cutoff date (Dec 30).
>>>>>>
>>>>>>
>>>>>> [as a contributor]
>>>>>>
>>>>>>
>>>>>> I’m unsure if it makes sense to call it out in this draft, in that it seems universally applicable, but I don’t see any harm in it either and thus do not object.
>>>>>>
>>>>>>
>>>>>> Kent
>>>>> 	[As Co-chair]
>>>>>
>>>>> 	Given the tall hill we climbed to get to this point on the requirements, I
>>>>> want to be clear that there needs to be very significant support to change the requirements
>>>>> in any significant way. We went round and round the drain on settling on these requirements, and
>>>>> people had a whole host of reasonable opportunities to add this during those times. I want to point out that while this statement may seem subtle, slipping this in at the last minute could have a profound impact on solutions built from these requirements, so I want to be sure everyone involved has through through this kind of change.
>>>>>
>>>>> 	—Tom
>>>> Tom,
>>>>
>>>> I think Andy is talking about applicability - to which kind of servers
>>>> do these requirements apply. For example, if it takes more time on a
>>>> certain class of devices to retrieve the difference between applied
>>>> and intended config than it takes to turn intended config into applied
>>>> config, then these requirements may not be applicable (since by the
>>>> time you have finished retrieving the difference it has vanished).
>>> I think it is not only matter of synchronisation delays between intended
>>> and applied configuration. I have serious troubles understanding how
>>> these concepts map to the class of devices I am mainly interested in.
>>>
>>> Let me give you an example: An OpenWRT router runs a NETCONF/RESTCONF
>>> server that supports intended and applied config. Assume the server
>>> implements modules of the acl-model family so that firewall rules can be
>>> configured through NETCONF/RESTCONF. Great.
>>>
>>> Now an admin runs "iptables" to manipulate netfilter rules in the
>>> kernel. How does it affect the applied and intended configurations?
>>>
>>> A. The change isn't reflected in applied configuration. Then applied
>>>     configuration is no more "…, the configuration state which is
>>>     currently being used by server components (e.g., control plane
>>>     daemons, operating system kernels, line cards)."
>>>
>>> B. The change is reflected in applied but not in intended
>>>     configuration. This violates requirement 1 sub D, and also it may be
>>>     impossible to map the kernel changes back to the configuration.
>>>
>>> For sure, these problems exist also with the good old "running", but I
>>> think the migration to intended-applied would just make things worse.
>> If I understand your example correctly, then the complexity in your scenario is that what is actually written in the hardware is controlled by two independent management entities.  Is that right?
> Right, and this is quite typical for systems where users have access to a standard Unix shell and/or can install software on their own.
>
>> If so I think that your scenario is outside what could be reasonably expected to be defined by a standards specification.
> Why? Such systems could also benefit from NETCONF/RESTCONF and standard data models.
Sure.   But I don't see how you can standardize against a configuration 
system that probably isn't strongly specified itself.


>
>> Ideally, all of the related configuration would be managed by the same YANG data model, in which case I would expect that your problem would disappear.
> It can be managed by the same YANG models as other devices, one can just never think that what's in the configuration is also what the system uses. The only (reasonably) reliable source for the latter is the /proc filesystem, which actually comes close to the definition of applied configuration - only its data model is generally very different.
Personally, I would think that a device knowing what configuration it is 
actually running should be the desired and default expectation, and not 
being able to provide this is a deficiency.

Somehow the operator needs to be able to figure out whether a device is 
doing what it is supposed to be doing.  I don't think that it is really 
reasonable to just force this problem on to the operators and tell them 
that they need to figure it out themselves.  This would mean that each 
and every operator that needs to interact with that device either has to 
accept that either they don't know what it is actually doing, or they 
have to independently implement a similar solution to figure it out.

>
>> Pragmatically, I suspect that you can't do that, in which case I would model the opstate requirements as only applying to the YANG
> Yes, it is not realistic.
>
>> part of the configuration.  I.e. the ACL model is in applied configuration applied if it is regarded as being a valid input to what is being programmed into the system.  What is actually programmed in the forwarding filter depends on both the accepted ACL YANG configuration and also the other independent configuration.
> Sure, but then applied configuration is of no use.
That's not entirely true.

The operator still knows that the system is actually acting on the 
configuration that the user intended, it just doesn't mean that it has 
necessarily been programmed into the forwarding plane.  That is subject 
to the other independent configuration allowing the ACL YANG 
configuration is in effect.

E.g. in the following ASCII Art diagram, then if A was the YANG config, 
then they would know that has been successfully applied, even though 
they don't know about your other configuration 'B', or what ends up in 
the forwarding plane (derived state) :

A ==\
      ===> Forwarding plane
B ==/


Without the applied configuration state, the operator knows less 
information.  I.e. if the forwarding plane hasn't been programmed 
correctly then that might be either because the ACL YANG configuration 
(A) hasn't been applied or because the independent configuration (B) 
interferes with it.

Thanks,
Rob


>
> Lada
>
>> Thanks,
>> Rob
>>
>>
>>> Lada
>>>
>>>
>>>> Andy, did I get this right?
>>>>
>>>> /js
>>>>
>>>> -- 
>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>>>> Fax:   +49 421 200 3103         
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> .
>


From nobody Mon Dec 21 09:48:05 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041B41A914C for ; Mon, 21 Dec 2015 09:48:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 obVXuRCjoK8z for ; Mon, 21 Dec 2015 09:48:00 -0800 (PST)
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 9245F1A9147 for ; Mon, 21 Dec 2015 09:47:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25346; q=dns/txt; s=iport; t=1450720079; x=1451929679; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=sXNg+DkKn+87dkSrOI11S96dRmYbmRCyCsreAgRO9ec=; b=hMueD4WEhNfwyUohlaD63L5lmRJCe366+U9gu7hrYXkJNeBNl5D7GNrt qqmMddRGIJrYeOOCTgq9NCI9t/LRka7DNmahTfiLcRS7SMFLAHHmw/xgE RGtGMtwfOr19BFx9S3QWj2czc5gh7mnQqg/wyxdoQeYi9eoHm5/AbhKq9 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvBADnOnhW/xbLJq1YBoQMbYxSsxEXA?= =?us-ascii?q?QmFIkoCgXcBAQEBAQGBC4Q0AQEBBAEBAWsKARALEQQBAQEJFgEHBwkDAgECARU?= =?us-ascii?q?fCQgGAQwGAgEBBRKIFA6zOhYBAQIBizIBAQEBAQEBAQEBAQEBAQEBAQEBAQEYh?= =?us-ascii?q?laDeIEGgkGBaRACAQUIC4RrBZcAhTuIEIFchEWDBYwrg2eDdGSCER2BVz00AYU?= =?us-ascii?q?rAQEB?=
X-IronPort-AV: E=Sophos;i="5.20,460,1444694400";  d="scan'208,217";a="609993086"
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; 21 Dec 2015 17:47:52 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tBLHlqe6010755; Mon, 21 Dec 2015 17:47:52 GMT
To: Andy Bierman , Kent Watsen 
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net> 
From: Benoit Claise 
Message-ID: <56783B45.1020505@cisco.com>
Date: Mon, 21 Dec 2015 18:47:49 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000807030803080500040707"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 17:48:04 -0000

This is a multi-part message in MIME format.
--------------000807030803080500040707
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Andy,
>
>
> On Fri, Dec 18, 2015 at 12:02 PM, Kent Watsen  > wrote:
>
>
>     Hi Robert,
>
>     I agree that -01 doesn’t add much on top of -00.  This is expected
>     as we’re in the fit and finish phase.  If you want to help finish
>     the draft, then please consider responding to one of these threads:
>
>     http://www.ietf.org/mail-archive/web/netmod/current/msg14587.html
>     (re: rollback-on-error)
>     http://www.ietf.org/mail-archive/web/netmod/current/msg14641.html
>     (re: model-structure)
>
>     As for this thread:
>
>     1. Regarding adding an explicit backwards-compatibility
>     requirement, please note that what was written here is still in
>     effect:
>     http://www.ietf.org/mail-archive/web/netmod/current/msg14629.html.
>     Note that no objections have been raised yet, so this will likely
>     happen.
>
>     2. Regarding adding an applicability statement, there is currently
>     only one voice asking for it, which isn’t enough to warrant a change.
>
>
> I did not ask to add an AS to the charter.
> I don't think the WG agrees enough on the problem to write such a 
> document.
I hope that nobody disagrees that the operational state design and how 
to structure the models are the two blocking factors to publish YANG 
models. If you disagree or don't see this, let me know, I should 
communicate better.
I hope that nobody disagrees that there is a problem to be solved (a 
problem statement extracted from 
https://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/). We 
havea bunch of operators , 
coming to the IETF, telling us they have a problem. So there is a problem.
I hope that nobody really believes that because some people in IETF (or 
in any other SDOs) thinks that what those operators want is a bad idea, 
those operators will not get what they request/pay for from their suppliers.

Regards, Benoit (OPS AD)
>
>
>     Thanks,
>     Kent
>
>
> Andy
>
>
>
>
>     On 12/18/15, 6:33 AM, "netmod on behalf of Robert Wilton"
>      on
>     behalf of rwilton@cisco.com > wrote:
>
>     >Hi,
>     >
>     >On 17/12/2015 23:45, Randy Presuhn wrote:
>     >> Hi -
>     >>
>     >>> From: Robert Wilton
>     >>> Sent: Dec 17, 2015 1:12 PM
>     >>> To: Andy Bierman
>     >>> Cc: "netmod@ietf.org "
>     >>> Subject: Re: [netmod] NETMOD WG LC:
>     draft-ietf-netmod-opstate-reqs-01
>     >> ...
>     >>>      Your requirement is a bit too strong for my liking.
>     >>>
>     >>>      To paraphrase your requirement text, it is forcing that all
>     >>>      compliant NETCONF/RESTCONF servers MUST support any
>     clients that do
>     >>>      not want to differentiate between intended config and applied
>     >>>      config.
>     >> Do do otherwise sound to me like an interoperability disaster,
>     >> and would encourage the "siloization" of toolsets.
>     >>
>     >>>      However, this requires all opstate aware servers:
>     >>>
>     >>>       - To handle a mix of clients, some of which are opstate
>     aware, and
>     >>>       some that are not.
>     >> This seems perfectly reasonable.  To do otherwise torpedoes the
>     very
>     >> notion of interoperability.
>     >>
>     >>>       - To potentially handle a mix of requests, some of which are
>     >>>       opstate aware requests, and some are not.
>     >> Ditto.
>     >>
>     >>>      It also prevents:
>     >>>
>     >>>       - Having a server that is implemented to only support
>     opstate aware
>     >>>       clients.
>     >> Avoiding the creation of such servers sounds like a *good*
>     thing to me.
>     >>
>     >>>       - Having a server side configuration knob to control the
>     behaviour
>     >>>       (since it would affect the semantics for all clients).
>     >> This also sounds like something which it would be desireable to
>     prevent.
>     >>
>     >> I think I'm squarely with Andy on this one.
>     >
>     >Taking a step back ...
>     >
>     >I am probably way off the mark, but my perception is that some
>     (perhaps
>     >many) of the folks in the WG still perceive that the opstate
>     >requirements are niche requirements for some unusual scenarios,
>     and that
>     >everyone else is happy with the status quo and don't want/need them.
>     >
>     >Alas, I don't share that view.  For me, the opstate requirements
>     can be
>     >summarized as saying that the operators just want to know what
>     >configuration the device is actually running in a format that is
>     >convenient for them to use.  This really doesn't appear to be
>     >unreasonable request to me, and if I was writing to a network
>     >manageability API then I would choose to use opstate because I
>     perceive
>     >that it is a more robust and easier to use API.  The counter
>     arguments
>     >appear to be that it is too hard for devices to provide this
>     >information, and that the operators have historically managed
>     without it.
>     >
>     >However, I think that several things have changed, and hence negate
>     >these counter arguments: (i) the operators want to have much more
>     >automation and management over their devices, (ii) they have
>     found a way
>     >to group together and have a more vocal voice about what they
>     need and
>     >want, (iii) the operators have realized that they don't need to
>     wait for
>     >the SDOs and can create defacto standard models on their own if they
>     >have to.
>     >
>     >Personally, I would like us to stop spending time churning on the
>     >requirements and actually get on to discussing the solutions.  To be
>     >honest, there has been relatively little change in my
>     understanding of
>     >the requirements from reading draft-openconfig-netmod-opstate-01
>     back in
>     >July, and I was expecting to discuss the solution drafts back in
>     >September.  Here we are in December, and I'm not convinced that
>     we have
>     >truly made significant progress.
>     >
>     >The only reason that I submitted a solution draft to this problem was
>     >because I thought it unlikely that OpenConfig would support a
>     multiple
>     >datastore solution, and I could see strong resistance amongst the
>     IETF
>     >engineers to the proposed OpenConfig solution.  I was hoping that my
>     >proposed solution might be seen for the compromise that it is between
>     >the two opposing positions.  But I care less on what the solution is,
>     >and more whether we can agree on one and move forward.
>     >
>     >As someone that is quite new to SDO processes, my main concern is
>     that
>     >IETF (and other standards bodies) are moving too slowly here, and
>     that
>     >by the time that IETF have produced a sufficiently complete set
>     of YANG
>     >models to manage network devices it will be too late because the
>     >industry will already have converged on the OpenConfig models, which
>     >although not perfect, are close to being usable now, and are being
>     >evolved at a much quicker pace ...
>     >
>     >So my hope for the early new year is that we can reach common ground
>     >with OpenConfig and converge on a single set of YANG modules for
>     >managing network devices, and that includes having a solution to the
>     >Opstate problem.
>     >
>     >Finally, if my acquiescing to Andy's requirement is helpful to
>     move this
>     >process forward then that is fine with me.  As I have previously
>     >indicated, I don't really think that it helps with framing or
>     discussing
>     >the solutions, but equally I can live with it since I suspect
>     that the
>     >solutions are likely to comply with it anyway.
>     >
>     >Apologies for the long email, and given I may not be actively reading
>     >the WG emails over the next couple of weeks, I'll wish you all happy
>     >holidays!
>     >
>     >Thanks,
>     >Rob
>     >
>     >>
>     >> Randy
>     >>
>     >> _______________________________________________
>     >> 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
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--------------000807030803080500040707
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Andy,

    

    

      
      


        


          
On Fri, Dec 18, 2015 at 12:02 PM,
            Kent Watsen <kwatsen@juniper.net>
            wrote:

            


              Hi Robert,

              

              I agree that -01 doesn’t add much on top of -00.  This is
              expected as we’re in the fit and finish phase.  If you
              want to help finish the draft, then please consider
              responding to one of these threads:

              

                http://www.ietf.org/mail-archive/web/netmod/current/msg14587.html 
              (re: rollback-on-error)

                http://www.ietf.org/mail-archive/web/netmod/current/msg14641.html 
              (re: model-structure)

              

              As for this thread:

              

              1. Regarding adding an explicit backwards-compatibility
              requirement, please note that what was written here is
              still in effect: http://www.ietf.org/mail-archive/web/netmod/current/msg14629.html. 
              Note that no objections have been raised yet, so this will
              likely happen.

              

              2. Regarding adding an applicability statement, there is
              currently only one voice asking for it, which isn’t enough
              to warrant a change.

              

            

            


            

            
I did not ask to add an AS to the charter.

            
I don't think the WG agrees enough on the problem to
              write such a document.

          

        

      

    

    I hope that nobody disagrees that the operational state design and
    how to structure the models are the two blocking factors to publish
    YANG models. If you disagree or don't see this, let me know, I
    should communicate better.

    I hope that nobody disagrees that there is a problem to be solved (a
    problem statement extracted from
    https://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/).
    We have a bunch of
      operators, coming to the IETF, telling us they have a problem.
    So there is a problem. 

    I hope that nobody really believes that because some people in IETF
    (or in any other SDOs) thinks that what those operators want is a
    bad idea, those operators will not get what they request/pay for
    from their suppliers.

    

    Regards, Benoit (OPS AD)

    

      

        

          

            


            

            


            

            
 

            

              Thanks,

              Kent

            

            


            

            
Andy

            
 

            

              

              

              

              On 12/18/15, 6:33 AM, "netmod on behalf of Robert Wilton"
              <netmod-bounces@ietf.org
              on behalf of rwilton@cisco.com>
              wrote:

              

              >Hi,

              >

              >On 17/12/2015 23:45, Randy Presuhn wrote:

              >> Hi -

              >>

              >>> From: Robert Wilton

              >>> Sent: Dec 17, 2015 1:12 PM

              >>> To: Andy Bierman

              >>> Cc: "netmod@ietf.org"

              >>> Subject: Re: [netmod] NETMOD WG LC:
              draft-ietf-netmod-opstate-reqs-01

              >> ...

              >>>      Your requirement is a bit too strong for
              my liking.

              >>>

              >>>      To paraphrase your requirement text, it
              is forcing that all

              >>>      compliant NETCONF/RESTCONF servers MUST
              support any clients that do

              >>>      not want to differentiate between
              intended config and applied

              >>>      config.

              >> Do do otherwise sound to me like an
              interoperability disaster,

              >> and would encourage the "siloization" of
              toolsets.

              >>

              >>>      However, this requires all opstate aware
              servers:

              >>>

              >>>       - To handle a mix of clients, some of
              which are opstate aware, and

              >>>       some that are not.

              >> This seems perfectly reasonable.  To do otherwise
              torpedoes the very

              >> notion of interoperability.

              >>

              >>>       - To potentially handle a mix of
              requests, some of which are

              >>>       opstate aware requests, and some are
              not.

              >> Ditto.

              >>

              >>>      It also prevents:

              >>>

              >>>       - Having a server that is implemented
              to only support opstate aware

              >>>       clients.

              >> Avoiding the creation of such servers sounds like
              a *good* thing to me.

              >>

              >>>       - Having a server side configuration
              knob to control the behaviour

              >>>       (since it would affect the semantics
              for all clients).

              >> This also sounds like something which it would be
              desireable to prevent.

              >>

              >> I think I'm squarely with Andy on this one.

              >

              >Taking a step back ...

              >

              >I am probably way off the mark, but my perception is
              that some (perhaps

              >many) of the folks in the WG still perceive that the
              opstate

              >requirements are niche requirements for some unusual
              scenarios, and that

              >everyone else is happy with the status quo and don't
              want/need them.

              >

              >Alas, I don't share that view.  For me, the opstate
              requirements can be

              >summarized as saying that the operators just want to
              know what

              >configuration the device is actually running in a
              format that is

              >convenient for them to use.  This really doesn't
              appear to be

              >unreasonable request to me, and if I was writing to a
              network

              >manageability API then I would choose to use opstate
              because I perceive

              >that it is a more robust and easier to use API.  The
              counter arguments

              >appear to be that it is too hard for devices to
              provide this

              >information, and that the operators have historically
              managed without it.

              >

              >However, I think that several things have changed, and
              hence negate

              >these counter arguments: (i) the operators want to
              have much more

              >automation and management over their devices, (ii)
              they have found a way

              >to group together and have a more vocal voice about
              what they need and

              >want, (iii) the operators have realized that they
              don't need to wait for

              >the SDOs and can create defacto standard models on
              their own if they

              >have to.

              >

              >Personally, I would like us to stop spending time
              churning on the

              >requirements and actually get on to discussing the
              solutions.  To be

              >honest, there has been relatively little change in my
              understanding of

              >the requirements from reading
              draft-openconfig-netmod-opstate-01 back in

              >July, and I was expecting to discuss the solution
              drafts back in

              >September.  Here we are in December, and I'm not
              convinced that we have

              >truly made significant progress.

              >

              >The only reason that I submitted a solution draft to
              this problem was

              >because I thought it unlikely that OpenConfig would
              support a multiple

              >datastore solution, and I could see strong resistance
              amongst the IETF

              >engineers to the proposed OpenConfig solution.  I was
              hoping that my

              >proposed solution might be seen for the compromise
              that it is between

              >the two opposing positions.  But I care less on what
              the solution is,

              >and more whether we can agree on one and move forward.

              >

              >As someone that is quite new to SDO processes, my main
              concern is that

              >IETF (and other standards bodies) are moving too
              slowly here, and that

              >by the time that IETF have produced a sufficiently
              complete set of YANG

              >models to manage network devices it will be too late
              because the

              >industry will already have converged on the OpenConfig
              models, which

              >although not perfect, are close to being usable now,
              and are being

              >evolved at a much quicker pace ...

              >

              >So my hope for the early new year is that we can reach
              common ground

              >with OpenConfig and converge on a single set of YANG
              modules for

              >managing network devices, and that includes having a
              solution to the

              >Opstate problem.

              >

              >Finally, if my acquiescing to Andy's requirement is
              helpful to move this

              >process forward then that is fine with me.  As I have
              previously

              >indicated, I don't really think that it helps with
              framing or discussing

              >the solutions, but equally I can live with it since I
              suspect that the

              >solutions are likely to comply with it anyway.

              >

              >Apologies for the long email, and given I may not be
              actively reading

              >the WG emails over the next couple of weeks, I'll wish
              you all happy

              >holidays!

              >

              >Thanks,

              >Rob

              >

              >>

              >> Randy

              >>

              >> _______________________________________________

              >> 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

            

          

          

        

      

      

      

      

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


    

    

  


--------------000807030803080500040707--


From nobody Mon Dec 21 10:02:40 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C9B1A9173 for ; Mon, 21 Dec 2015 10:02:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 pH1mJnAGj77w for ; Mon, 21 Dec 2015 10:02:37 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611961A9218 for ; Mon, 21 Dec 2015 10:02:35 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2FBF31033; Mon, 21 Dec 2015 19:02:34 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id B8SVdw5zHMvM; Mon, 21 Dec 2015 19:02:33 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 21 Dec 2015 19:02:33 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A87320056; Mon, 21 Dec 2015 19:02:33 +0100 (CET)
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 ByE1zXMnQbi3; Mon, 21 Dec 2015 19:02:32 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C012E20055; Mon, 21 Dec 2015 19:02:31 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id AF7B9396006C; Mon, 21 Dec 2015 19:02:31 +0100 (CET)
Date: Mon, 21 Dec 2015 19:02:31 +0100
From: Juergen Schoenwaelder 
To: Benoit Claise 
Message-ID: <20151221180231.GC43694@elstar.local>
Mail-Followup-To: Benoit Claise , Andy Bierman , Kent Watsen , "netmod@ietf.org" 
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>  <56783B45.1020505@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <56783B45.1020505@cisco.com>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 18:02:39 -0000

On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:

> I hope that nobody disagrees that the operational state design and how 
> to structure the models are the two blocking factors to publish YANG 
> models. If you disagree or don't see this, let me know, I should 
> communicate better.

Even if it may spoil your day, I disagree that there is a blocking
factor that should stop us from publishing models. There seem to be
ways to address the requirements without having to block all work or
to redo what that we have published. But sure, if you make it a
blocking factor, it will be one.

> I hope that nobody really believes that because some people in IETF (or 
> in any other SDOs) thinks that what those operators want is a bad idea, 
> those operators will not get what they request/pay for from their suppliers.

To be fair, those operators also tell us that they use protocols that
are not IETF protocols and it remains somewhat unclear what those
protocols are we are expected to optimize data model solutions for.

/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 Dec 21 10:30:01 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A76421ABD3C for ; Mon, 21 Dec 2015 10:29:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 lSNHFhqGA-Gx for ; Mon, 21 Dec 2015 10:29:58 -0800 (PST)
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 84CF81A90A5 for ; Mon, 21 Dec 2015 10:29:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6753; q=dns/txt; s=iport; t=1450722597; x=1451932197; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=hp5mWp2tZoT7Kgu+2FSFWxpJa7qg43ZHF4zDfRsRm8g=; b=NB7F56zzqeN+i/3K2rZ7fehy/gFF+9OcOnfwZaJZVw5J01/YGWeQUhts LVU+kKMztw3AcM7t4MmzWN1qJPqGYOOM0jopG97Jj18NLP+CIva2xd/cP 90E9RiNdH3GRtVNhc+kOCPGT1GsTMVH889SCjfpvLENa/dHy3dS9ok5z/ o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsBAB/RHhW/xbLJq1ehAxtjFKzESOFa?= =?us-ascii?q?gKBdwEBAQEBAYEAC4Q0AQEBBCNUAREcAwECChYLAgIJAwIBAgE7AggGDQYCAQE?= =?us-ascii?q?XiBQOrHCGVBYBAQIBizEBAQEBAQEBAQEBAQEBAQEBAQEBGoZWhH6Ee4J8gUkFj?= =?us-ascii?q?TeJSYU7iBCBXEmDfIMFlAZkhAQ+NAGFKwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.20,460,1444694400";  d="scan'208,217";a="609994216"
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 Dec 2015 18:29:55 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tBLITtCY017454 for ; Mon, 21 Dec 2015 18:29:55 GMT
References: <20151221182052.25187.80308.idtracker@ietfa.amsl.com>
To: "netmod@ietf.org" 
From: Robert Wilton 
X-Forwarded-Message-Id: <20151221182052.25187.80308.idtracker@ietfa.amsl.com>
Message-ID: <56784520.7060805@cisco.com>
Date: Mon, 21 Dec 2015 18:29:52 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <20151221182052.25187.80308.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------030101000001000109080405"
Archived-At: 
Subject: [netmod] Fwd: New Version Notification for draft-wilton-netmod-opstate-yang-02.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 18:29:59 -0000

This is a multi-part message in MIME format.
--------------030101000001000109080405
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

I've published an updated version of my proposed opstate solution.

The main change is that I've updated the requirements tracking section 
to explain how the draft implements the requirements specified in the 
most recent requirements draft.

I also documented the outline of a possible YANG Metadata based solution 
in an appendix that was a variant broadly proposed by Andy Bierman on 
the WG alias.

Thanks,
Rob


-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-wilton-netmod-opstate-yang-02.txt
Date: 	Mon, 21 Dec 2015 10:20:52 -0800
From: 	internet-drafts@ietf.org
To: 	Robert Wilton 



A new version of I-D, draft-wilton-netmod-opstate-yang-02.txt
has been successfully submitted by Robert Wilton and posted to the
IETF repository.

Name:		draft-wilton-netmod-opstate-yang
Revision:	02
Title:		"With-config-state" Capability for NETCONF/RESTCONF
Document date:	2015-12-21
Group:		Individual Submission
Pages:		24
URL:            https://www.ietf.org/internet-drafts/draft-wilton-netmod-opstate-yang-02.txt
Status:         https://datatracker.ietf.org/doc/draft-wilton-netmod-opstate-yang/
Htmlized:       https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-wilton-netmod-opstate-yang-02

Abstract:
    This document proposes a possible alternative solution for handling
    applied configuration state in YANG as described in draft-openconfig-
    netmod-opstate-01.  The proposed solution, roughly modelled on the
    with-defaults NETCONF/RESTCONF capability, aims to meet the key
    requirements set out in draft-ietf-netmod-opstate-reqs-01 without the
    need for YANG module authors to explicitly duplicate configuration
    nodes in both configuration and operational containers.  This draft
    does not address the issue of co-location of configuration and
    operational state for interfaces, nor does it provide a NETCONF
    mechanism to retrieve operational data separately from configuration
    data.

                                                                                   


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

.




--------------030101000001000109080405
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    Hi,

    

    I've published an updated version of my proposed opstate solution.

    

    The main change is that I've updated the requirements tracking
    section to explain how the draft implements the requirements
    specified in the most recent requirements draft.

    

    I also documented the outline of a possible YANG Metadata based
    solution in an appendix that was a variant broadly proposed by Andy
    Bierman on the WG alias.

    


      Thanks,

      Rob

      

      

      -------- Forwarded Message --------
      

        
          

            Subject:
            
            New Version Notification for
              draft-wilton-netmod-opstate-yang-02.txt
          

          

            Date: 
            Mon, 21 Dec 2015 10:20:52 -0800
          

          

            From: 
            internet-drafts@ietf.org
          

          

            To: 
            Robert Wilton <rwilton@cisco.com>
          

        
      

      

      

      
A new version of I-D, draft-wilton-netmod-opstate-yang-02.txt
has been successfully submitted by Robert Wilton and posted to the
IETF repository.

Name:		draft-wilton-netmod-opstate-yang
Revision:	02
Title:		"With-config-state" Capability for NETCONF/RESTCONF
Document date:	2015-12-21
Group:		Individual Submission
Pages:		24
URL:            https://www.ietf.org/internet-drafts/draft-wilton-netmod-opstate-yang-02.txt
Status:         https://datatracker.ietf.org/doc/draft-wilton-netmod-opstate-yang/
Htmlized:       https://tools.ietf.org/html/draft-wilton-netmod-opstate-yang-02
Diff:           https://www.ietf.org/rfcdiff?url2=draft-wilton-netmod-opstate-yang-02

Abstract:
   This document proposes a possible alternative solution for handling
   applied configuration state in YANG as described in draft-openconfig-
   netmod-opstate-01.  The proposed solution, roughly modelled on the
   with-defaults NETCONF/RESTCONF capability, aims to meet the key
   requirements set out in draft-ietf-netmod-opstate-reqs-01 without the
   need for YANG module authors to explicitly duplicate configuration
   nodes in both configuration and operational containers.  This draft
   does not address the issue of co-location of configuration and
   operational state for interfaces, nor does it provide a NETCONF
   mechanism to retrieve operational data separately from configuration
   data.

                                                                                  


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

.



      

    

    

  


--------------030101000001000109080405--


From nobody Mon Dec 21 10:55:56 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1D91AC3C6 for ; Mon, 21 Dec 2015 10:55:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 JHJhky6xfWL0 for ; Mon, 21 Dec 2015 10:55:54 -0800 (PST)
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 888701AC3CF for ; Mon, 21 Dec 2015 10:55:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4883; q=dns/txt; s=iport; t=1450724153; x=1451933753; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=toHcgRz+rAiDQBz2d/yl9cdiWu+yOAuf3HgRxI55Oho=; b=CJrwnw95UTrKu9zjxnN3bo+JWpFa4VlLpva0Zfr6RP+bd7UWspPbOPG1 0r2VnkZJeg3iKeO/PVOHYD0Ks3WgGdB7VXygIY+B8FwYQPFqYNdJw2cL0 hsyFB2wUxv1vhnOVdcudlNxbeYdHf8fMV/VxLPglakTUvc+jDXgOsjw23 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtBADKSnhW/xbLJq1ehAxtjFKxLYFkF?= =?us-ascii?q?wqFIkoCgWQTAQEBAQEBAYEKhDQBAQEDAQEBASQRNhAHBAsOAwQBAQEJHgcPAhY?= =?us-ascii?q?fCQgGAQwGAgEBF4gMCA6zRhYBAQIBizMBAQEBAQEBAQEBAQEBAQEBAQEBAQEUB?= =?us-ascii?q?IZWhH6EKhEBBoR+AQSHUYcaiBWILIUfgVyERYMFI5NjJAM9hAQ+NINjBxcHgSQ?= =?us-ascii?q?BAQE?=
X-IronPort-AV: E=Sophos;i="5.20,460,1444694400"; d="scan'208";a="619969093"
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; 21 Dec 2015 18:55:51 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tBLItomn007350; Mon, 21 Dec 2015 18:55:51 GMT
To: Gert Grammel , "Sterne, Jason (Jason)" , "netmod@ietf.org" 
References:  
From: Robert Wilton 
Message-ID: <56784B33.30908@cisco.com>
Date: Mon, 21 Dec 2015 18:55:47 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 18:55:55 -0000

Hi Gert,

Please see inline ...

On 05/11/2015 03:53, Gert Grammel wrote:
> Jason,
>
> A synchronous config basically contains two pieces of information in the commit:
> 	1) the intended configuration is valid (i.e. is syntactically correct) and
> 	2) the intended config has been applied
> Any error that would affect the config before the commit could be rolled back to the old config and a suitable notification sent to the client. After the commit, there is no roll-back.
I agree.

> Similarly for asynchronous, however here the information needs to be split into two messages:
> 	1) a commit that the intended config is valid
> 	2) another message when the intended config is fully applied (let's call this 'validated').
> A rollback can happen before the intended config is fully applied i.e. before the 'validated' state is reached.
I agree.

>
> The real problem is what you called in another email  'hybrid' or cheating-synchronous implementations. This leads to a situation where the client is made to believe the intended config is applied, but the server still didn't apply it yet. Take the case where the server runs into trouble after the synchronous-commit (which lets the client believe that the intended config is applied) and decides to roll-back. From a client perspective this would look like a node randomly losing its committed configuration. There is tons of code required on the client side to cope with that situation. So what was the purpose of implementing it that way in the first place - instead of just applying an asynchronous implementation?
Yes, I agree that handling rollback could be a problem in this scenario, 
and hence I would propose that the behaviour in such a scenario is 
explicitly documented as being undefined in whatever solution is agreed 
upon :-)

Otherwise assuming that all requests are strictly synchronous or 
asynchronous then I think that we should be OK with the following two 
rules on the server:
1) All edit-config requests must strictly be processed in order.
2) You cannot tell a client that a request has been full applied unless 
all previous requests specifying rollback-on-error semantics with any 
overlapping nodes with the current request have either be applied or 
aborted (i.e. rolled back)

Thanks,
Rob


>
> Gert
>
>
>
>
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Sterne, Jason (Jason)
> Sent: 03 November 2015 08:24
> To: netmod@ietf.org
> Subject: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
>
> Hi all,
>
> The term "rollback on error" (and other error options) has been used during these discussions around the opstate requirements.
>
> That term already has some meaning in RFC6241 (or at least rollback-on-error does and that is pretty close) and IMO it (today) has nothing to do with "applied" config.  It is an error option that has the scope of the contents of a single edit-config request and how those contents get applied (all or nothing) to the candidate DS (which is neither intended nor applied config) or to the running DS (intended) if the  is .
>
> I think we need to clarify this "all or nothing" concept and how it is related to "applied" config.  We may also want to use slightly different terminology so we don't get confused with today's meaning of rollback-on-error.
>
> There are a few transitions to consider when editing a config and applying it to a device (I'll give the example of using the candidate DS):
> (A) config changes   ---> candidate DS   ()
> (B) candidate DS  ----> running (intended)  ()
> (C) intended ----> applied  (internal processed in the device)
>
> Today rollback-on-error is only applicable to transition (A).
>
> Transition (B) does have all-or-nothing properties (as described in RFC6241) but that isn't related to "rollback-on-error".
>
> Is there some intention in the opstate requirements to add some sort of all-or-nothing behavior to transition (C) ?  i.e. if some part of an edit fails during the transition from intended->applied we should "rollback" the other parts that may have already been applied ?
>
> Would we then remove it all from intended as well ?
>
> I'm not sure how that would work for an async/hybrid (read "real") system.  We've already done an "ack" back to the client before transition (C) so the client may have already sent some additional new config that depends on the previous edit.  That would mean that new config isn't valid.
>
> Jason
>
> _______________________________________________
> 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 Mon Dec 21 10:57:40 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCD31AC3BF for ; Mon, 21 Dec 2015 10:57:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 NclRHl1BsV0O for ; Mon, 21 Dec 2015 10:57:37 -0800 (PST)
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 141EA1A9236 for ; Mon, 21 Dec 2015 10:57:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2843; q=dns/txt; s=iport; t=1450724257; x=1451933857; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=pINQTiROLUL9vFDVvmoPrqq2fagbod93Nv+N7X7JglI=; b=YYqVLbmN3sS0+9x05ZSSp6t781i1EBurHN9cEgDzMtB/Qcgx+EGXl/HH CGHodfRR6e7fuvLypJcnujQlozSupbMIUCfAvCY3F4+1GgFBIZ3J7vgzU H9q2ks//LEtlDLj1PKf0T005AfF7m4rRCDOA3AB5JY9Zksc8XxAk8hb6+ 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQARS3hW/xbLJq1ehAxtjFKxHwENg?= =?us-ascii?q?WQXCoUiSgKBYxQBAQEBAQEBgQqENQEBBAEBASQRNgoRCxgJFg8JAwIBAgEVMAY?= =?us-ascii?q?BDAYCAQGIKw6zRxYBAQIBizMBAQEBAQEBAQEBAQEBAQEBAQEBFgSGVoR+hDWFC?= =?us-ascii?q?wEElwCNS4Fch0ojk2MgAQFChAQ+NINigUoBAQE?=
X-IronPort-AV: E=Sophos;i="5.20,460,1444694400"; d="scan'208";a="639243562"
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; 21 Dec 2015 18:57:35 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tBLIvZhx007780; Mon, 21 Dec 2015 18:57:35 GMT
To: "Sterne, Jason (Jason)" , "netmod@ietf.org" 
References: 
From: Robert Wilton 
Message-ID: <56784B9B.5020408@cisco.com>
Date: Mon, 21 Dec 2015 18:57:31 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 18:57:39 -0000

Hi Jason,

Picking up this slightly old thread.

The "rollback on error" definition that I added I took directly from 
RFC6241, so it's good that they look similar.  The intention is that the 
NETCONF "rollback-on-error" capability is a valid implementation of this 
requirement :-)

I think that the  rollback-on-error capability defined in RFC6241 can 
also be applied to the running datastore.  Certainly, the example quoted 
is in the context of the edit-config request on the running-config 
datastore, and the RFC description of this feature doesn't appear to 
limit it to the candidate datastore in any way.

Thanks,
Rob


On 03/11/2015 07:23, Sterne, Jason (Jason) wrote:
> Hi all,
>
> The term "rollback on error" (and other error options) has been used during these discussions around the opstate requirements.
>
> That term already has some meaning in RFC6241 (or at least rollback-on-error does and that is pretty close) and IMO it (today) has nothing to do with "applied" config.  It is an error option that has the scope of the contents of a single edit-config request and how those contents get applied (all or nothing) to the candidate DS (which is neither intended nor applied config) or to the running DS (intended) if the  is .
>
> I think we need to clarify this "all or nothing" concept and how it is related to "applied" config.  We may also want to use slightly different terminology so we don't get confused with today's meaning of rollback-on-error.
>
> There are a few transitions to consider when editing a config and applying it to a device (I'll give the example of using the candidate DS):
> (A) config changes   ---> candidate DS   ()
> (B) candidate DS  ----> running (intended)  ()
> (C) intended ----> applied  (internal processed in the device)
>
> Today rollback-on-error is only applicable to transition (A).
>
> Transition (B) does have all-or-nothing properties (as described in RFC6241) but that isn't related to "rollback-on-error".
>
> Is there some intention in the opstate requirements to add some sort of all-or-nothing behavior to transition (C) ?  i.e. if some part of an edit fails during the transition from intended->applied we should "rollback" the other parts that may have already been applied ?
>
> Would we then remove it all from intended as well ?
>
> I'm not sure how that would work for an async/hybrid (read "real") system.  We've already done an "ack" back to the client before transition (C) so the client may have already sent some additional new config that depends on the previous edit.  That would mean that new config isn't valid.
>
> Jason
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Mon Dec 21 11:05:20 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBD31AC3F0 for ; Mon, 21 Dec 2015 11:05:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 taVC_gHATn6M for ; Mon, 21 Dec 2015 11:05:10 -0800 (PST)
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 796951AC3E3 for ; Mon, 21 Dec 2015 11:05:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7348; q=dns/txt; s=iport; t=1450724701; x=1451934301; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=b1MtYLXlZOP5ZdaUouSOxQsFLb+c5vuitS/MKWU3tXU=; b=GfBXIVcu1eiP+YE2gSBT9p4oQZ+GH9tlKd1h6G/Y+0n/mNQ/s61jDks7 acb4AX056CUb/usqlXAHZFxNzEFMdM4pr54Okgjj6xOOKUNXPT9jWUq81 7XzkrpSS2Bpxq8Zs0ffSJVGa33okkYAY162VALwL5rYgY54rjyp6FsyJf w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvBAB0THhW/xbLJq1YBoQMbYxSsxEXC?= =?us-ascii?q?oUiSgKBdwEBAQEBAYELhDQBAQEDAQEBASAPAQU2CgYLCw4DBAEBAQICBRYLAgI?= =?us-ascii?q?JAwIBAgEVKAgGAQwGAgEBBRKIDAgOrHKGVBYBAQIBizMBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEYgQGFVYR+gkGBaRACAQUIgy2BSQWXAI1LgVyERYMFkBKDdGSEBD4?= =?us-ascii?q?0AYUrAQEB?=
X-IronPort-AV: E=Sophos;i="5.20,460,1444694400"; d="scan'208";a="609995107"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Dec 2015 19:04:59 +0000
Received: from [10.63.23.135] (dhcp-ensft1-uk-vla370-10-63-23-135.cisco.com [10.63.23.135]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tBLJ4wdZ009718; Mon, 21 Dec 2015 19:04:59 GMT
To: Kent Watsen , "netmod@ietf.org" 
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>
From: Robert Wilton 
Message-ID: <56784D57.6090507@cisco.com>
Date: Mon, 21 Dec 2015 19:04:55 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 19:05:13 -0000

Hi Kent,

On 18/12/2015 20:02, Kent Watsen wrote:
> Hi Robert,
>
> I agree that -01 doesn’t add much on top of -00.  This is expected as we’re in the fit and finish phase.  If you want to help finish the draft, then please consider responding to one of these threads:
>
>    http://www.ietf.org/mail-archive/web/netmod/current/msg14587.html  (re: rollback-on-error)
Done.  In this case I think that "rollback-on-error" semantics should be 
reasonably well understood transactional semantics, so I don't think 
that we need to churn/delay the precise definition for the requirements 
draft.  We can always wordsmith the definitions in whatever solution 
draft we end up coming up with anyway ...

>    http://www.ietf.org/mail-archive/web/netmod/current/msg14641.html  (re: model-structure)
Done.

>
> As for this thread:
>
> 1. Regarding adding an explicit backwards-compatibility requirement, please note that what was written here is still in effect: http://www.ietf.org/mail-archive/web/netmod/current/msg14629.html.  Note that no objections have been raised yet, so this will likely happen.
That's fine with me.  As you can probably tell I don't really agree that 
adding this requirement is necessary or particularly helpful, but I 
doubt that it will matter and it certainly isn't worth spending any 
extra time debating it further.

Thanks,
Rob


>
> 2. Regarding adding an applicability statement, there is currently only one voice asking for it, which isn’t enough to warrant a change.
>
> Thanks,
> Kent
>
>
>
> On 12/18/15, 6:33 AM, "netmod on behalf of Robert Wilton"  wrote:
>
>> Hi,
>>
>> On 17/12/2015 23:45, Randy Presuhn wrote:
>>> Hi -
>>>
>>>> From: Robert Wilton
>>>> Sent: Dec 17, 2015 1:12 PM
>>>> To: Andy Bierman
>>>> Cc: "netmod@ietf.org"
>>>> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>>> ...
>>>>       Your requirement is a bit too strong for my liking.
>>>>
>>>>       To paraphrase your requirement text, it is forcing that all
>>>>       compliant NETCONF/RESTCONF servers MUST support any clients that do
>>>>       not want to differentiate between intended config and applied
>>>>       config.
>>> Do do otherwise sound to me like an interoperability disaster,
>>> and would encourage the "siloization" of toolsets.
>>>
>>>>       However, this requires all opstate aware servers:
>>>>
>>>>        - To handle a mix of clients, some of which are opstate aware, and
>>>>        some that are not.
>>> This seems perfectly reasonable.  To do otherwise torpedoes the very
>>> notion of interoperability.
>>>
>>>>        - To potentially handle a mix of requests, some of which are
>>>>        opstate aware requests, and some are not.
>>> Ditto.
>>>
>>>>       It also prevents:
>>>>
>>>>        - Having a server that is implemented to only support opstate aware
>>>>        clients.
>>> Avoiding the creation of such servers sounds like a *good* thing to me.
>>>
>>>>        - Having a server side configuration knob to control the behaviour
>>>>        (since it would affect the semantics for all clients).
>>> This also sounds like something which it would be desireable to prevent.
>>>
>>> I think I'm squarely with Andy on this one.
>> Taking a step back ...
>>
>> I am probably way off the mark, but my perception is that some (perhaps
>> many) of the folks in the WG still perceive that the opstate
>> requirements are niche requirements for some unusual scenarios, and that
>> everyone else is happy with the status quo and don't want/need them.
>>
>> Alas, I don't share that view.  For me, the opstate requirements can be
>> summarized as saying that the operators just want to know what
>> configuration the device is actually running in a format that is
>> convenient for them to use.  This really doesn't appear to be
>> unreasonable request to me, and if I was writing to a network
>> manageability API then I would choose to use opstate because I perceive
>> that it is a more robust and easier to use API.  The counter arguments
>> appear to be that it is too hard for devices to provide this
>> information, and that the operators have historically managed without it.
>>
>> However, I think that several things have changed, and hence negate
>> these counter arguments: (i) the operators want to have much more
>> automation and management over their devices, (ii) they have found a way
>> to group together and have a more vocal voice about what they need and
>> want, (iii) the operators have realized that they don't need to wait for
>> the SDOs and can create defacto standard models on their own if they
>> have to.
>>
>> Personally, I would like us to stop spending time churning on the
>> requirements and actually get on to discussing the solutions.  To be
>> honest, there has been relatively little change in my understanding of
>> the requirements from reading draft-openconfig-netmod-opstate-01 back in
>> July, and I was expecting to discuss the solution drafts back in
>> September.  Here we are in December, and I'm not convinced that we have
>> truly made significant progress.
>>
>> The only reason that I submitted a solution draft to this problem was
>> because I thought it unlikely that OpenConfig would support a multiple
>> datastore solution, and I could see strong resistance amongst the IETF
>> engineers to the proposed OpenConfig solution.  I was hoping that my
>> proposed solution might be seen for the compromise that it is between
>> the two opposing positions.  But I care less on what the solution is,
>> and more whether we can agree on one and move forward.
>>
>> As someone that is quite new to SDO processes, my main concern is that
>> IETF (and other standards bodies) are moving too slowly here, and that
>> by the time that IETF have produced a sufficiently complete set of YANG
>> models to manage network devices it will be too late because the
>> industry will already have converged on the OpenConfig models, which
>> although not perfect, are close to being usable now, and are being
>> evolved at a much quicker pace ...
>>
>> So my hope for the early new year is that we can reach common ground
>> with OpenConfig and converge on a single set of YANG modules for
>> managing network devices, and that includes having a solution to the
>> Opstate problem.
>>
>> Finally, if my acquiescing to Andy's requirement is helpful to move this
>> process forward then that is fine with me.  As I have previously
>> indicated, I don't really think that it helps with framing or discussing
>> the solutions, but equally I can live with it since I suspect that the
>> solutions are likely to comply with it anyway.
>>
>> Apologies for the long email, and given I may not be actively reading
>> the WG emails over the next couple of weeks, I'll wish you all happy
>> holidays!
>>
>> Thanks,
>> Rob
>>
>>> Randy
>>>
>>> _______________________________________________
>>> 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 Mon Dec 21 11:21:23 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0DD1AC3F5 for ; Mon, 21 Dec 2015 11:21:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level: 
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 WTq2sc84OFGe for ; Mon, 21 Dec 2015 11:21:20 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C1CD1AC3F1 for ; Mon, 21 Dec 2015 11:21:20 -0800 (PST)
Received: from [IPv6:2a01:5e0:29:ffff:96c:169f:baa2:536d] (unknown [IPv6:2a01:5e0:29:ffff:96c:169f:baa2:536d]) by mail.nic.cz (Postfix) with ESMTPSA id D01C41814A4; Mon, 21 Dec 2015 20:21:18 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450725678; bh=u2gnfBIfv2mV+eZb4LYSlCZM4ZmgTZvt9XlSTalmNf0=; h=From:Date:To; b=hgeqIoIEZxtNaXcUv69efvW3MlWN2nx9Vb/EO2mU0xOzkUmOj8dW+ro11JhpHWNPI kpEq7fbICg7FTfBm6ChSMsCZHdMbTF5Pe/Mw0c7kwLFR5wpUm8ScN0C2UdvWwLdFox G2b4ZJ/JbspZjJhxhnf0nq/4ymtuI6ACRWog8fT0=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <20151221180231.GC43694@elstar.local>
Date: Mon, 21 Dec 2015 20:21:18 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <147269F5-7B47-4614-9C08-948E8B5FC65C@nic.cz>
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>  <56783B45.1020505@cisco.com> <20151221180231.GC43694@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 19:21:22 -0000

> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder =
 wrote:
>=20
> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>=20
>> I hope that nobody disagrees that the operational state design and =
how=20
>> to structure the models are the two blocking factors to publish YANG=20=

>> models. If you disagree or don't see this, let me know, I should=20
>> communicate better.
>=20
> Even if it may spoil your day, I disagree that there is a blocking
> factor that should stop us from publishing models. There seem to be
> ways to address the requirements without having to block all work or
> to redo what that we have published. But sure, if you make it a
> blocking factor, it will be one.

I agree with Juergen. It is not clear to me how the proposed split =
between intended and applied configuration is supposed to affect the =
data models we are working on.

Lada

>=20
>> I hope that nobody really believes that because some people in IETF =
(or=20
>> in any other SDOs) thinks that what those operators want is a bad =
idea,=20
>> those operators will not get what they request/pay for from their =
suppliers.
>=20
> To be fair, those operators also tell us that they use protocols that
> are not IETF protocols and it remains somewhat unclear what those
> protocols are we are expected to optimize data model solutions for.
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon Dec 21 11:28:47 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432581AC40C for ; Mon, 21 Dec 2015 11:28:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 eme4fOXmpfB7 for ; Mon, 21 Dec 2015 11:28:44 -0800 (PST)
Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 9DE501AC405 for ; Mon, 21 Dec 2015 11:28:43 -0800 (PST)
Received: by mail-lf0-x230.google.com with SMTP id z124so111846427lfa.3 for ; Mon, 21 Dec 2015 11:28:43 -0800 (PST)
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:date:message-id:subject:from:to :content-type; bh=7ccub+/RZXv6PKmX2jdhY45gMlbnlXdvB1+X4lANMKU=; b=Cmw3S6EtXkjQRmfEJKQznVDTPTTM+GzYYFohzxFbJ5RNHUHqCJNUpWBS+Ss5W5lYu+ z5506v+YXeha11H96pzMCDk/dqWnf6p/HzOU44ywGWZNxLwRmCqsX1YgbdoBL9LqUxlX /x0sT/iX1nzauB9kwQuo+LvrhysEmyI5HJuZTXT8P11Y4z3H6gENotLhfrq6ch1iU591 Bhh4yRkDcy4mBW6OQ6enz5Jy8FZWzO43yXQHnHcW3zBuvwiA+qcQmObxhaz2h8Wz9Vih jHU/MP1BIC5wUqFbwnzMZVZnrnDQQ6wLjS+zgErHbXMVcBX3xQMlnB3sceHejVQFvQ5P +pEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=7ccub+/RZXv6PKmX2jdhY45gMlbnlXdvB1+X4lANMKU=; b=CS89EUrmLeiFZ+8PvdLSHjY3MMb0NKXc9bLyh7I4yCJHlxubs3IZIBUBWw0ntUJI64 +wd9mh4++DZxkg/apIO9O9c2wk/SckCy0BV2hMXZwpdtSVpIqQsNGfBeL7taEfq4PgwP 2rOFQUaurwvc6w421gyq4XTgH2tI0xqJ7XIxtBNtEx3tRqjpfi6SbQ7F3ebCtD0+iBYW TGG0qrXlR358WRe8B/Q/VEL0MTLrxee7wiaqkscLm83ZWpvYsKC7pH+tBoFRKy3gwzdh l/juWz2oUz8B95BdHGwfL4CKhxvzVD/MXV5L8UDAHUq2mh0sUvM/9/77i3M/ETmGycFG eKNQ==
X-Gm-Message-State: ALoCoQmXL2b0fDXyp9HHkFvHjFRi1n0GWAe/YpT7VxOfheW671OyG/J6i8dVsHQx+gFzT0Gi/PL/PEa/1Ua+fyS4cLgGbutQjQ==
MIME-Version: 1.0
X-Received: by 10.25.213.205 with SMTP id m196mr4711221lfg.23.1450726121656; Mon, 21 Dec 2015 11:28:41 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Mon, 21 Dec 2015 11:28:41 -0800 (PST)
In-Reply-To: <20151221154054.GB43316@elstar.local>
References: <1033983.1450551979726.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>  <20151221144723.GA43211@elstar.local> <5E9674F3-DDAB-479F-A8CA-0CF78FE5F1F2@nic.cz> <20151221154054.GB43316@elstar.local>
Date: Mon, 21 Dec 2015 11:28:41 -0800
Message-ID: 
From: Andy Bierman 
To: Juergen Schoenwaelder , Ladislav Lhotka , NETMOD WG 
Content-Type: multipart/alternative; boundary=001a1141275025f2fe05276d7f1f
Archived-At: 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 19:28:46 -0000

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

On Mon, Dec 21, 2015 at 7:40 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Mon, Dec 21, 2015 at 04:07:20PM +0100, Ladislav Lhotka wrote:
> >
> > > On 21 Dec 2015, at 15:47, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> > >
> > > I believe the model we have agreed on in RFC 6020 is this:
> > >
> > > - YANG modules in I-Ds are 'development' modules and not 'published'
> > >  modules.
> >
> > Section 10 makes no distinction between development and published
> modules, except that for published modules a new "revision" statement MUST
> be included in front of the existing "revision" statements.
> >
>
> And I noted in my email that we may have to make section 11 of RFC
> 6020bis more explicit.
>
> > > - It helps a lot during module development if 'development' modules
> > >  are actually implemented. Note that implementations of 'development'
> > >  modules are not intended to be 'deployed'.
> >
> > Absolutely, but this requires that development modules also carry
> revision information - otherwise clients won't be able to figure out the
> data model.
> >
>
> I am against regulating development or investing effort to deal with
> interoperability of development modules. If someone has to distinguish
> the stuff running in your labs, I am sure he/she will find a way to do
> so.
>



I agree with you.
However, we do seem to aggressively extract YANG modules from documents and
then ignore the source document completely.
There is absolutely no way for a YANG compiler to tell the difference
between a module extracted from an Internet Draft from a module
extracted from an RFC.

There is no "module-status" statement in YANG.

   module-status draft;
   module-status published;

Perhaps this is overkill, but whining about module update rules
constantly is getting old.


Andy




> > > - A 'published' module (something appearing in an RFC in the IETF)
> > >  will be subject to YANG update rules.
> >
> > Are you saying that other SDOs may adopt different rules, and that these
> rules don't apply to proprietary modules?
> >
>
> I believe that it is generally up to the organization publishing
> modules to define what is a 'published module' and what is a
> 'development module'. We can only reasonably define this for the
> IETF.
>
> > > - 'Published' modules are expected to be 'implemented' and 'deployed'.
> > >
> > > - IETF WGs need to take care of the maintenance and interoperability
> > >  of what has been 'published', hence the module update rules.
> > >
> > > - Obviously, it is good to detect major flaws during 'development' and
> > >  hence the importance of early 'implementation' experience.
> > >
> > > Note that there are no formal module name or namespace assignements
> > > until a module has been published as an RFC. A WG might put in a best
> > > guess what the names might be but assignment and registration via IANA
> > > happens during the publication process.
> > >
> > > Perhaps it helps to clarify in RFC6020bis that the updates rules apply
> > > to published modules and not to modules under development.
> >
> > Yes, some clarification is needed in any case.
> >
> > Lada
> >
> > >
> > > /js
> > >
> > > --
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   +49 421 200 3103         
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
>
> --
> 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
>

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




On Mon, Dec 21, 2015 at 7:40 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Dec 21, 2015 at 04:07:20PM +0100, Ladislav L=
hotka wrote:

>

> > On 21 Dec 2015, at 15:47, Juergen Schoenwaelder <j.schoenwaelder@jacobs-universit=
y.de> wrote:

> >

> > I believe the model we have agreed on in RFC 6020 is this:

> >

> > - YANG modules in I-Ds are 'development' modules and not =
'published'

> >=C2=A0 modules.

>

> Section 10 makes no distinction between development and published modu=
les, except that for published modules a new "revision" statement=
 MUST be included in front of the existing "revision" statements.=


>



And I noted in my email that we may have to make section 11 of RFC

6020bis more explicit.



> > - It helps a lot during module development if 'development=
9; modules

> >=C2=A0 are actually implemented. Note that implementations of '=
;development'

> >=C2=A0 modules are not intended to be 'deployed'.

>

> Absolutely, but this requires that development modules also carry revi=
sion information - otherwise clients won't be able to figure out the da=
ta model.

>



I am against regulating development or investing effort to deal with

interoperability of development modules. If someone has to distinguish

the stuff running in your labs, I am sure he/she will find a way to do

so.



I agr=
ee with you.
However, we do seem to aggressively extract YANG mod=
ules from documents and then ignore the source document completely.
There is absolutely no way for a YANG compiler to tell the difference
between a module extracted from an Internet Draft from a module
extracted from an RFC.

There is no "mo=
dule-status" statement in YANG.

=C2=A0 =C2=A0=
module-status draft;
=C2=A0 =C2=A0module-status published;
<=
div>
Perhaps this is overkill, but whining about module updat=
e rules
constantly is getting old.


<=
/div>
Andy






> > - A 'published' module (something appearing in an RFC in =
the IETF)

> >=C2=A0 will be subject to YANG update rules.

>

> Are you saying that other SDOs may adopt different rules, and that the=
se rules don't apply to proprietary modules?

>



I believe that it is generally up to the organization publishing

modules to define what is a 'published module' and what is a

'development module'. We can only reasonably define this for the
IETF.



> > - 'Published' modules are expected to be 'implemented=
' and 'deployed'.

> >

> > - IETF WGs need to take care of the maintenance and interoperabil=
ity

> >=C2=A0 of what has been 'published', hence the module upda=
te rules.

> >

> > - Obviously, it is good to detect major flaws during 'develop=
ment' and

> >=C2=A0 hence the importance of early 'implementation' expe=
rience.

> >

> > Note that there are no formal module name or namespace assignemen=
ts

> > until a module has been published as an RFC. A WG might put in a =
best

> > guess what the names might be but assignment and registration via=
 IANA

> > happens during the publication process.

> >

> > Perhaps it helps to clarify in RFC6020bis that the updates rules =
apply

> > to published modules and not to modules under development.

>

> Yes, some clarification is needed in any case.

>

> Lada

>

> >

> > /js

> >

> > --

> > 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/>

>

> --

> Ladislav Lhotka, CZ.NIC Labs

> PGP Key ID: E74E8C0C

>

>

>

>



--

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





--001a1141275025f2fe05276d7f1f--


From nobody Mon Dec 21 12:17:29 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAC781ACCEE for ; Mon, 21 Dec 2015 12:17:27 -0800 (PST)
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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 lsI-yZfVCrQi for ; Mon, 21 Dec 2015 12:17:23 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0743.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::743]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CACC1ACCE5 for ; Mon, 21 Dec 2015 12:17:22 -0800 (PST)
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1612.namprd05.prod.outlook.com (10.161.162.140) with Microsoft SMTP Server (TLS) id 15.1.355.16; Mon, 21 Dec 2015 20:17:04 +0000
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0355.012; Mon, 21 Dec 2015 20:17:03 +0000
From: Gert Grammel 
To: Robert Wilton , "Sterne, Jason (Jason)" , "netmod@ietf.org" 
Thread-Topic: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
Thread-Index: AQHRPCE47xOcpKJOekikRF587Razi57V8ZkA
Date: Mon, 21 Dec 2015 20:17:03 +0000
Message-ID: 
References:   <56784B33.30908@cisco.com>
In-Reply-To: <56784B33.30908@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.9.151119
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [193.110.55.10]
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1612; 5:KZ75mP3lid1O0/cIRxQ7dJLF3C3x08khen04r9Crmb79d/oo6ycQ3py2ujUSj/UnABOzpmUebK8Lnp3kdL9OY0BDx3kNCtEdrda9NRkfalBDf9xHz55HRBqlwAqyRmTOanyaFl1B2w/l0M3SEdwIfQ==; 24:O4IpWhB8QjVU9BlHOngku/pSXD5tGWaEFx+KNkQ2hUkDhKAqq/MlYslf33hhIo1P9xZRmpoMf1B72Pip0VUrv7KsWl21NL0GhzhYxZd+a7Q=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1612;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(61489475475257)(138986009662008)(95692535739014); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(3002001)(10201501046); SRVR:CY1PR0501MB1612; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1612; 
x-forefront-prvs: 079756C6B9
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(13464003)(479174004)(164054003)(51444003)(199003)(53754006)(189002)(19617315012)(5001960100002)(2900100001)(16236675004)(2501003)(19580395003)(3846002)(5004730100002)(586003)(15975445007)(4001350100001)(40100003)(105586002)(77096005)(1220700001)(1096002)(86362001)(36756003)(102836003)(106356001)(106116001)(99286002)(230783001)(5008740100001)(54356999)(76176999)(50986999)(2950100001)(66066001)(6116002)(5002640100001)(107886002)(81156007)(5001770100001)(83506001)(189998001)(92566002)(19580405001)(97736004)(10400500002)(101416001)(87936001)(122556002)(94096001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1612; H:CY1PR0501MB1609.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:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_D29E0A87CFDFggrammeljunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Dec 2015 20:17:03.6139 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1612
Archived-At: 
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 20:17:28 -0000

--_000_D29E0A87CFDFggrammeljunipernet_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi Rob,

Seems we are pretty close with our understanding, so snipping the only disc=
ussion point left, with further comments:

Gert



The real problem is what you called in another email  'hybrid' or cheating-=
synchronous implementations. This leads to a situation where the client is =
made to believe the intended config is applied, but the server still didn't=
 apply it yet. Take the case where the server runs into trouble after the s=
ynchronous-commit (which lets the client believe that the intended config i=
s applied) and decides to roll-back. From a client perspective this would l=
ook like a node randomly losing its committed configuration. There is tons =
of code required on the client side to cope with that situation. So what wa=
s the purpose of implementing it that way in the first place - instead of j=
ust applying an asynchronous implementation?
Yes, I agree that handling rollback could be a problem in this scenario,
and hence I would propose that the behaviour in such a scenario is
explicitly documented as being undefined in whatever solution is agreed
upon :-)
Gert> sadly, we can=92t roll time back. So the best option is indeed to doc=
ument the issue and move on to improve things

Otherwise assuming that all requests are strictly synchronous or
asynchronous then I think that we should be OK with the following two
rules on the server:

  1.  All edit-config requests must strictly be processed in order.

Gert> yes, although there are corner cases we need to hash out.  I.e. a cli=
ent may set  a leaf to  followed by setting it to . Then a server may=
 skip setting it to , because it is anyhow overwritten by .

2) You cannot tell a client that a request has been full applied unless
all previous requests specifying rollback-on-error semantics with any
overlapping nodes with the current request have either be applied or
aborted (i.e. rolled back)

Gert> with =93have bee full applied=94 you meant a state that I tentatively=
 named =91validated=92  in my earlier email?  I am a bit sensitive to namin=
g here because of those =91cheating synchronous nodes=92 would return =91ap=
plied=92 without actually doing so in full. It would be great if we could q=
uickly converge on some naming convention to remove ambiguity.
The rule holds true but I don=92t see a dependency on =93rollback-on-error=
=94 semantics. In my view it is applicable also in cases of "continue-on-er=
ror=94 and =93stop-on-error=94 in the sense that unless any error has been =
reported, the client still needs to wait for the =91validated=92 state befo=
re it can reliably assume the config was applied.



From: Robert Wilton >
Date: Monday 21 December 2015 19:55
To: Gert Grammel >, Jason=
 Sterne >, "netmod@ietf.org" >
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback =
on error)

Hi Gert,

Please see inline ...

On 05/11/2015 03:53, Gert Grammel wrote:
Jason,

A synchronous config basically contains two pieces of information in the co=
mmit:
1) the intended configuration is valid (i.e. is syntactically correct) and
2) the intended config has been applied
Any error that would affect the config before the commit could be rolled ba=
ck to the old config and a suitable notification sent to the client. After =
the commit, there is no roll-back.
I agree.

Similarly for asynchronous, however here the information needs to be split =
into two messages:
1) a commit that the intended config is valid
2) another message when the intended config is fully applied (let's call th=
is 'validated').
A rollback can happen before the intended config is fully applied i.e. befo=
re the 'validated' state is reached.
I agree.


The real problem is what you called in another email  'hybrid' or cheating-=
synchronous implementations. This leads to a situation where the client is =
made to believe the intended config is applied, but the server still didn't=
 apply it yet. Take the case where the server runs into trouble after the s=
ynchronous-commit (which lets the client believe that the intended config i=
s applied) and decides to roll-back. From a client perspective this would l=
ook like a node randomly losing its committed configuration. There is tons =
of code required on the client side to cope with that situation. So what wa=
s the purpose of implementing it that way in the first place - instead of j=
ust applying an asynchronous implementation?
Yes, I agree that handling rollback could be a problem in this scenario,
and hence I would propose that the behaviour in such a scenario is
explicitly documented as being undefined in whatever solution is agreed
upon :-)

Otherwise assuming that all requests are strictly synchronous or
asynchronous then I think that we should be OK with the following two
rules on the server:
1) All edit-config requests must strictly be processed in order.
2) You cannot tell a client that a request has been full applied unless
all previous requests specifying rollback-on-error semantics with any
overlapping nodes with the current request have either be applied or
aborted (i.e. rolled back)

Thanks,
Rob



Gert




-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Sterne, Jason (J=
ason)
Sent: 03 November 2015 08:24
To: netmod@ietf.org
Subject: [netmod] netmod-opstate-reqs and error option terms (rollback on e=
rror)

Hi all,

The term "rollback on error" (and other error options) has been used during=
 these discussions around the opstate requirements.

That term already has some meaning in RFC6241 (or at least rollback-on-erro=
r does and that is pretty close) and IMO it (today) has nothing to do with =
"applied" config.  It is an error option that has the scope of the contents=
 of a single edit-config request and how those contents get applied (all or=
 nothing) to the candidate DS (which is neither intended nor applied config=
) or to the running DS (intended) if the  is .

I think we need to clarify this "all or nothing" concept and how it is rela=
ted to "applied" config.  We may also want to use slightly different termin=
ology so we don't get confused with today's meaning of rollback-on-error.

There are a few transitions to consider when editing a config and applying =
it to a device (I'll give the example of using the candidate DS):
(A) config changes   ---> candidate DS   ()
(B) candidate DS  ----> running (intended)  ()
(C) intended ----> applied  (internal processed in the device)

Today rollback-on-error is only applicable to transition (A).

Transition (B) does have all-or-nothing properties (as described in RFC6241=
) but that isn't related to "rollback-on-error".

Is there some intention in the opstate requirements to add some sort of all=
-or-nothing behavior to transition (C) ?  i.e. if some part of an edit fail=
s during the transition from intended->applied we should "rollback" the oth=
er parts that may have already been applied ?

Would we then remove it all from intended as well ?

I'm not sure how that would work for an async/hybrid (read "real") system. =
 We've already done an "ack" back to the client before transition (C) so th=
e client may have already sent some additional new config that depends on t=
he previous edit.  That would mean that new config isn't valid.

Jason

_______________________________________________
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
.




--_000_D29E0A87CFDFggrammeljunipernet_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <82344741DDA05D4A8B951938BFFA2999@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable







Hi Rob,







Seems we are pretty close with our understanding, so snipping the only=
 discussion point left, with further comments:







Gert












<snip>





The real problem is what you called in another email  'hybrid' or=
 cheating-synchronous implementations. This leads to a situation where the =
client is made to believe the intended config is applied, but the server st=
ill didn't apply it yet. Take the case where
 the server runs into trouble after the synchronous-commit (which lets the =
client believe that the intended config is applied) and decides to roll-bac=
k. From a client perspective this would look like a node randomly losing it=
s committed configuration. There
 is tons of code required on the client side to cope with that situation. S=
o what was the purpose of implementing it that way in the first place - ins=
tead of just applying an asynchronous implementation?


Yes, I agree that handling rollback could be a problem in this scenari=
o, 


and hence I would propose that the behaviour in such a scenario is&nbs=
p;


explicitly documented as being undefined in whatever solution is agree=
d 


upon :-)


Gert> sadly, we can=92t roll time back. So the best option is indee=
d to document the issue and move on to improve things







Otherwise assuming that all requests are strictly synchronous or =



asynchronous then I think that we should be OK with the following two&=
nbsp;


rules on the server:


    

  1. All edit-config requests must strictly be processed in order.


Gert> yes, although there are corner cases we need to hash out. &nb=
sp;I.e. a client may set  a leaf to <x> followed by setting it t=
o <y>. Then a server may skip setting it to <x>, because it is =
anyhow overwritten by <y>.







2) You cannot tell a client that a request has been full applied unles=
s 


all previous requests specifying rollback-on-error semantics with any&=
nbsp;


overlapping nodes with the current request have either be applied or&n=
bsp;


aborted (i.e. rolled back)









Gert> with =93have bee full applied=94 you meant a state that I ten=
tatively named =91validated=92  in my earlier email?  I am a bit =
sensitive to naming here because of those =91cheating synchronous nodes=92 =
would return =91applied=92 without actually doing so in full.
 It would be great if we could quickly converge on some naming convention t=
o remove ambiguity.


The rule holds true but I don=92t see a dependency on =93rollback-on-e=
rror=94 semantics. In my view it is applicable also in cases of "conti=
nue-on-error=94 and =93stop-on-error=94 in the sense that unless any error =
has been reported, the client still needs to wait
 for the =91validated=92 state before it can reliably assume the config was=
 applied.











<snip>









From: Robert Wilton <rwilton@cisco.com>

Date: Monday 21 December 2015 19:55=


To: Gert Grammel <ggrammel@juniper.net>, Jason Sterne <jason.sterne@alcatel-lucen=
t.com>, "netmod@ietf.org=
"
 <netmod@ietf.org>

Subject: Re: [netmod] netmod-opstat=
e-reqs and error option terms (rollback on error)













Hi Gert,







Please see inline ...







On 05/11/2015 03:53, Gert Grammel wrote:




Jason,







A synchronous config basically contains two pieces of information in t=
he commit:


1) the=
 intended configuration is valid (i.e. is syntactically correct) and


2) the=
 intended config has been applied


Any error that would affect the config before the commit could be roll=
ed back to the old config and a suitable notification sent to the client. A=
fter the commit, there is no roll-back.




I agree.









Similarly for asynchronous, however here the information needs to be s=
plit into two messages:


1) a c=
ommit that the intended config is valid


2) ano=
ther message when the intended config is fully applied (let's call this 'va=
lidated').


A rollback can happen before the intended config is fully applied i.e.=
 before the 'validated' state is reached.




I agree.














The real problem is what you called in another email  'hybri=
d' or cheating-synchronous implementations. This leads to a situation where=
 the client is made to believe the intended config is applied, but the serv=
er still didn't apply it yet. Take the case
 where the server runs into trouble after the synchronous-commit (which let=
s the client believe that the intended config is applied) and decides to ro=
ll-back. From a client perspective this would look like a node randomly los=
ing its committed configuration.
 There is tons of code required on the client side to cope with that situat=
ion. So what was the purpose of implementing it that way in the first place=
 - instead of just applying an asynchronous implementation?




Yes, I agree that handling rollback could be a problem in this scenari=
o, 


and hence I would propose that the behaviour in such a scenario is 

explicitly documented as being undefined in whatever solution is agree=
d 


upon :-)







Otherwise assuming that all requests are strictly synchronous or 

asynchronous then I think that we should be OK with the following two =



rules on the server:


1) All edit-config requests must strictly be processed in order.


2) You cannot tell a client that a request has been full applied unles=
s 


all previous requests specifying rollback-on-error semantics with any =



overlapping nodes with the current request have either be applied or <=
/div>

aborted (i.e. rolled back)







Thanks,


Rob



















Gert






















-----Original Message-----


From: netmod [mailto:netmod=
-bounces@ietf.org] On Behalf Of Sterne, Jason (Jason)


Sent: 03 November 2015 08:24



Subject: [netmod] netmod-opstate-reqs and error option terms (rollback=
 on error)







Hi all,







The term "rollback on error" (and other error options) has b=
een used during these discussions around the opstate requirements.







That term already has some meaning in RFC6241 (or at least rollback-on=
-error does and that is pretty close) and IMO it (today) has nothing to do =
with "applied" config.  It is an error option that has =
the scope of the contents of a single edit-config request
 and how those contents get applied (all or nothing) to the candidate DS (w=
hich is neither intended nor applied config) or to the running DS (intended=
) if the <target> is <running/>.







I think we need to clarify this "all or nothing" concept and=
 how it is related to "applied" config.  We may also wa=
nt to use slightly different terminology so we don't get confused with toda=
y's meaning of rollback-on-error.







There are a few transitions to consider when editing a config and appl=
ying it to a device (I'll give the example of using the candidate DS):

(A) config changes   ---> candidate DS   (<e=
dit-config>)


(B) candidate DS  ----> running (intended)  (&l=
t;commit>)


(C) intended ----> applied  (internal processed in the de=
vice)







Today rollback-on-error is only applicable to transition (A).







Transition (B) does have all-or-nothing properties (as described in RF=
C6241) but that isn't related to "rollback-on-error".







Is there some intention in the opstate requirements to add some sort o=
f all-or-nothing behavior to transition (C) ?  i.e. if some part =
of an edit fails during the transition from intended->applied we should =
"rollback" the other parts that may have already
 been applied ?







Would we then remove it all from intended as well ?







I'm not sure how that would work for an async/hybrid (read "real&=
quot;) system.  We've already done an "ack" back to the=
 client before transition (C) so the client may have already sent some addi=
tional new config that depends on the previous edit.  That would
 mean that new config isn't valid.







Jason







_______________________________________________


netmod mailing list









_______________________________________________


netmod mailing list




.


























--_000_D29E0A87CFDFggrammeljunipernet_--


From nobody Mon Dec 21 12:17:44 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27D641ACCF3 for ; Mon, 21 Dec 2015 12:17:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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 jpnJtvTiZx8w for ; Mon, 21 Dec 2015 12:17:35 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87FEE1ACCE5 for ; Mon, 21 Dec 2015 12:17:35 -0800 (PST)
Received: from [IPv6:2a01:5e0:29:ffff:96c:169f:baa2:536d] (unknown [IPv6:2a01:5e0:29:ffff:96c:169f:baa2:536d]) by mail.nic.cz (Postfix) with ESMTPSA id 3CC4B180461; Mon, 21 Dec 2015 21:17:34 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450729054; bh=TiFsIl+z974IthY1wUViRmIb1LxBA5R6KZOg7x09HzA=; h=From:Date:To; b=VsnbLd0yZPBiOdZLzZx6LtrkmpsgiIArbHoVv7RTdZu5mNDmN9Mytr8ei/v/bFXx4 oZqHbfJQMUcKfR+bDMNDBojNDc//o2hdEU36qNbQQTnI/qvWPSehLsR9Z74srPkMAr lV4LfjhjzsLd+XzsiZhopY7NNz1h7hxV8AKEBG4Y=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <56782BFD.5080508@cisco.com>
Date: Mon, 21 Dec 2015 21:17:30 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net> <0239ADFB-4A52-4E47-8FA5-406231AD92D5@lucidvision.com> <20151217172931.GA68858@elstar.local>  <56781538.7010402@cisco.com> <3B1154B9-8055-4620-9EBD-861A7F525D94@nic.cz> <56782BFD.5080508@cisco.com>
To: Robert Wilton 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 20:17:38 -0000

> On 21 Dec 2015, at 17:42, Robert Wilton  wrote:
>=20
> Hi Lada,
>=20
> On 21/12/2015 16:05, Ladislav Lhotka wrote:
>>> On 21 Dec 2015, at 16:05, Robert Wilton  wrote:
>>>=20
>>> Hi Lada,
>>>=20
>>> On 21/12/2015 13:55, Ladislav Lhotka wrote:
>>>> Juergen Schoenwaelder  =
writes:
>>>>=20
>>>>> On Thu, Dec 17, 2015 at 10:52:13AM -0500, Nadeau Thomas wrote:
>>>>>>> On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen =
 wrote:
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>>>> I=E2=80=99m struggling a bit to understand what is motivating =
you to ask this question.    That is, as a tool vendor, I wouldn=E2=80=99t=
 think that any decision made here would affect you immediately.   My =
expectations are that any impact to YANG/NETCONF/RESTCONF would be =
backwards compatible, such that implementations would only opt-in when =
needed - a pay as you grow strategy.   But herein perhaps lies an =
unstated requirement, that the impact to YANG/NETCONF/RESTCONF needs to =
be backwards compatible with respect to existing deployments.  Did we =
miss it or is it too obvious?
>>>>>>>>>>=20
>>>>>>>>> It may be obvious for many of us but for the sake of =
completeness I
>>>>>>>>> prefer to have this backwards compatibility assumption =
explicitely
>>>>>>>>> stated.
>>>>>>>> +1
>>>>>>> [as a chair]
>>>>>>>=20
>>>>>>> As last call comment, there seems to be support for adding a =
requirement to the opstate-reqs draft to state that solutions supporting =
said requirements MUST be backwards compatible with respect to existing =
deployments.  Do we have WG consensus to add this as a requirement to =
this draft?  Are there any objections? Please voice your opinion before =
the last call cutoff date (Dec 30).
>>>>>>>=20
>>>>>>>=20
>>>>>>> [as a contributor]
>>>>>>>=20
>>>>>>>=20
>>>>>>> I=E2=80=99m unsure if it makes sense to call it out in this =
draft, in that it seems universally applicable, but I don=E2=80=99t see =
any harm in it either and thus do not object.
>>>>>>>=20
>>>>>>>=20
>>>>>>> Kent
>>>>>> 	[As Co-chair]
>>>>>>=20
>>>>>> 	Given the tall hill we climbed to get to this point on the =
requirements, I
>>>>>> want to be clear that there needs to be very significant support =
to change the requirements
>>>>>> in any significant way. We went round and round the drain on =
settling on these requirements, and
>>>>>> people had a whole host of reasonable opportunities to add this =
during those times. I want to point out that while this statement may =
seem subtle, slipping this in at the last minute could have a profound =
impact on solutions built from these requirements, so I want to be sure =
everyone involved has through through this kind of change.
>>>>>>=20
>>>>>> 	=E2=80=94Tom
>>>>> Tom,
>>>>>=20
>>>>> I think Andy is talking about applicability - to which kind of =
servers
>>>>> do these requirements apply. For example, if it takes more time on =
a
>>>>> certain class of devices to retrieve the difference between =
applied
>>>>> and intended config than it takes to turn intended config into =
applied
>>>>> config, then these requirements may not be applicable (since by =
the
>>>>> time you have finished retrieving the difference it has vanished).
>>>> I think it is not only matter of synchronisation delays between =
intended
>>>> and applied configuration. I have serious troubles understanding =
how
>>>> these concepts map to the class of devices I am mainly interested =
in.
>>>>=20
>>>> Let me give you an example: An OpenWRT router runs a =
NETCONF/RESTCONF
>>>> server that supports intended and applied config. Assume the server
>>>> implements modules of the acl-model family so that firewall rules =
can be
>>>> configured through NETCONF/RESTCONF. Great.
>>>>=20
>>>> Now an admin runs "iptables" to manipulate netfilter rules in the
>>>> kernel. How does it affect the applied and intended configurations?
>>>>=20
>>>> A. The change isn't reflected in applied configuration. Then =
applied
>>>>    configuration is no more "=E2=80=A6, the configuration state =
which is
>>>>    currently being used by server components (e.g., control plane
>>>>    daemons, operating system kernels, line cards)."
>>>>=20
>>>> B. The change is reflected in applied but not in intended
>>>>    configuration. This violates requirement 1 sub D, and also it =
may be
>>>>    impossible to map the kernel changes back to the configuration.
>>>>=20
>>>> For sure, these problems exist also with the good old "running", =
but I
>>>> think the migration to intended-applied would just make things =
worse.
>>> If I understand your example correctly, then the complexity in your =
scenario is that what is actually written in the hardware is controlled =
by two independent management entities.  Is that right?
>> Right, and this is quite typical for systems where users have access =
to a standard Unix shell and/or can install software on their own.
>>=20
>>> If so I think that your scenario is outside what could be reasonably =
expected to be defined by a standards specification.
>> Why? Such systems could also benefit from NETCONF/RESTCONF and =
standard data models.
> Sure.   But I don't see how you can standardize against a =
configuration system that probably isn't strongly specified itself.
>=20

Well, only if "strongly specified" means that the ways how the user is =
allowed to interact with the system are strictly controlled. Open-source =
system are usually fond of keeping the user empowered. We have to live =
with it.

>=20
>>=20
>>> Ideally, all of the related configuration would be managed by the =
same YANG data model, in which case I would expect that your problem =
would disappear.
>> It can be managed by the same YANG models as other devices, one can =
just never think that what's in the configuration is also what the =
system uses. The only (reasonably) reliable source for the latter is the =
/proc filesystem, which actually comes close to the definition of =
applied configuration - only its data model is generally very different.
> Personally, I would think that a device knowing what configuration it =
is actually running should be the desired and default expectation, and =
not being able to provide this is a deficiency.
>=20
> Somehow the operator needs to be able to figure out whether a device =
is doing what it is supposed to be doing.  I don't think that it

The operator (using a NETCONF/RESTCONF client) should be able to figure =
out what the device is doing by inspecting state data. That's why we =
have the separate *-state trees that often duplicate configuration data.=20=


>  is really reasonable to just force this problem on to the operators =
and tell them that they need to figure it out themselves.  This would =
mean that each and every operator that needs to interact with that =
device either has to accept that either they don't know what it is =
actually doing, or they have to independently implement a similar =
solution to figure it out.
>=20
>>=20
>>> Pragmatically, I suspect that you can't do that, in which case I =
would model the opstate requirements as only applying to the YANG
>> Yes, it is not realistic.
>>=20
>>> part of the configuration.  I.e. the ACL model is in applied =
configuration applied if it is regarded as being a valid input to what =
is being programmed into the system.  What is actually programmed in the =
forwarding filter depends on both the accepted ACL YANG configuration =
and also the other independent configuration.
>> Sure, but then applied configuration is of no use.
> That's not entirely true.
>=20
> The operator still knows that the system is actually acting on the =
configuration that the user intended, it just doesn't mean that it has =
necessarily been programmed into the forwarding plane. That is subject =
to the other independent configuration allowing the ACL YANG =
configuration is in effect.
>=20
> E.g. in the following ASCII Art diagram, then if A was the YANG =
config, then they would know that has been successfully applied, even =
though they don't know about your other configuration 'B', or what ends =
up in the forwarding plane (derived state) :
>=20
> A =3D=3D\
>     =3D=3D=3D> Forwarding plane
> B =3D=3D/
>=20
>=20
> Without the applied configuration state, the operator knows less =
information.  I.e. if the forwarding plane hasn't been programmed =
correctly then that might be either because the ACL YANG configuration =
(A) hasn't been applied or because the independent configuration (B) =
interferes with it.

I think the substantial information is what parameters the system is =
currently using. If there is no guarantee that applied configuration has =
this information, then it is IMO much less interesting.

I understand that for some systems the intended-applied configuration =
may be the right thing to do, so it could perhaps be defined as an =
optional capability. I just don't agree that this concept is universally =
applicable to all systems.

Lada

>=20
> Thanks,
> Rob
>=20
>=20
>>=20
>> Lada
>>=20
>>> Thanks,
>>> Rob
>>>=20
>>>=20
>>>> Lada
>>>>=20
>>>>=20
>>>>> Andy, did I get this right?
>>>>>=20
>>>>> /js
>>>>>=20
>>>>> --=20
>>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | =
Germany
>>>>> Fax:   +49 421 200 3103         
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>> .

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon Dec 21 13:34:48 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E5D1ACD8E for ; Mon, 21 Dec 2015 13:34:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 KlO6fXRw-GR1 for ; Mon, 21 Dec 2015 13:34:43 -0800 (PST)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 6424F1ACD8D for ; Mon, 21 Dec 2015 13:34:42 -0800 (PST)
Received: by mail-lf0-x22e.google.com with SMTP id l133so117720799lfd.2 for ; Mon, 21 Dec 2015 13:34:42 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=AC1edN7nHLKM8Ank/VYHVRieGIp0+2+vacv2YeoNH4A=; b=Ee1sK8PfhXkQIerhRZgAG+I1UtR69F/GEoCtcCtr33PX4OV/gk64O9jpgjWArV/EwU nu7MFaeDqvltZMWPxeTk54aY0uZ9wyMHNmiRq0ohZuRA1GJyYLbV6Xq391tT5vlwbKoH wNZVGsCH/t9W8tHOU/B8YJhmjG79n1FKbXXYLmuLGrD2VxrPkRrFb+qW6c/C5c8hUIya PcB4k2rjuC1ljKxv8V0EOJGB9a5OcayCZlc3X+2Yk8ITON3xTZsqN/hFUwNBJHb2tvOt OmAIo17EqGX+8JJv+WUJlr3q/6lINvb2DX2k2ed7lyYaN5HrLLqeoFmSSEepsASz5+GX reRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=AC1edN7nHLKM8Ank/VYHVRieGIp0+2+vacv2YeoNH4A=; b=Rg4cmLE5wlA8JsoyJ6O6LcTbQ/ciQWqw9sL1WXDldzBky2iT/EE64wDpl+1OaZd21z WgHBtsoocJIOtrVBjygROIobfa28m+iBYwSjwDrJEUWuhhO1ILaO4Sd31jZndy3Qu42V SIlrFtqsyhqxDeasLPb3n1abXj5nAepnVLZuAjbkvN1OvHGA78bYqx3pJknLeDLJr5oc sjttnlmP9M62REn2XeTUfxcFfHVmUKhgVXyEeblobKLZzs6xJAdg6QihgYcwCpL1ETTP vnZX8GUlK0DcBbO/xVlG5Oo04jR5253aWdfTT9ll/iNXSAJasJGZjppHOqAByWGGGs8W Gjog==
X-Gm-Message-State: ALoCoQmkYh9NbxSY+Wy6CeLWA4rVxJYqaxHVvVKvOi7PkQC2LHIHiVJ9w6C1SRkQXSPRyITFLl1f01NBE6nhA46Upa44OiuKGg==
MIME-Version: 1.0
X-Received: by 10.25.155.136 with SMTP id d130mr7498493lfe.54.1450733680430; Mon, 21 Dec 2015 13:34:40 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Mon, 21 Dec 2015 13:34:40 -0800 (PST)
In-Reply-To: 
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net> <0239ADFB-4A52-4E47-8FA5-406231AD92D5@lucidvision.com> <20151217172931.GA68858@elstar.local>  <56781538.7010402@cisco.com> <3B1154B9-8055-4620-9EBD-861A7F525D94@nic.cz> <56782BFD.5080508@cisco.com> 
Date: Mon, 21 Dec 2015 13:34:40 -0800
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a1140223eafada205276f41f0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 21:34:47 -0000

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

On Mon, Dec 21, 2015 at 12:17 PM, Ladislav Lhotka  wrote:

>
> > On 21 Dec 2015, at 17:42, Robert Wilton  wrote:
> >
> > Hi Lada,
> >
> > On 21/12/2015 16:05, Ladislav Lhotka wrote:
> >>> On 21 Dec 2015, at 16:05, Robert Wilton  wrote:
> >>>
> >>> Hi Lada,
> >>>
> >>> On 21/12/2015 13:55, Ladislav Lhotka wrote:
> >>>> Juergen Schoenwaelder  writes:
> >>>>
> >>>>> On Thu, Dec 17, 2015 at 10:52:13AM -0500, Nadeau Thomas wrote:
> >>>>>>> On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen <
> kwatsen@juniper.net> wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> I=E2=80=99m struggling a bit to understand what is motivating =
you to
> ask this question.    That is, as a tool vendor, I wouldn=E2=80=99t think=
 that any
> decision made here would affect you immediately.   My expectations are th=
at
> any impact to YANG/NETCONF/RESTCONF would be backwards compatible, such
> that implementations would only opt-in when needed - a pay as you grow
> strategy.   But herein perhaps lies an unstated requirement, that the
> impact to YANG/NETCONF/RESTCONF needs to be backwards compatible with
> respect to existing deployments.  Did we miss it or is it too obvious?
> >>>>>>>>>>
> >>>>>>>>> It may be obvious for many of us but for the sake of
> completeness I
> >>>>>>>>> prefer to have this backwards compatibility assumption
> explicitely
> >>>>>>>>> stated.
> >>>>>>>> +1
> >>>>>>> [as a chair]
> >>>>>>>
> >>>>>>> As last call comment, there seems to be support for adding a
> requirement to the opstate-reqs draft to state that solutions supporting
> said requirements MUST be backwards compatible with respect to existing
> deployments.  Do we have WG consensus to add this as a requirement to thi=
s
> draft?  Are there any objections? Please voice your opinion before the la=
st
> call cutoff date (Dec 30).
> >>>>>>>
> >>>>>>>
> >>>>>>> [as a contributor]
> >>>>>>>
> >>>>>>>
> >>>>>>> I=E2=80=99m unsure if it makes sense to call it out in this draft=
, in that
> it seems universally applicable, but I don=E2=80=99t see any harm in it e=
ither and
> thus do not object.
> >>>>>>>
> >>>>>>>
> >>>>>>> Kent
> >>>>>>  [As Co-chair]
> >>>>>>
> >>>>>>  Given the tall hill we climbed to get to this point on the
> requirements, I
> >>>>>> want to be clear that there needs to be very significant support t=
o
> change the requirements
> >>>>>> in any significant way. We went round and round the drain on
> settling on these requirements, and
> >>>>>> people had a whole host of reasonable opportunities to add this
> during those times. I want to point out that while this statement may see=
m
> subtle, slipping this in at the last minute could have a profound impact =
on
> solutions built from these requirements, so I want to be sure everyone
> involved has through through this kind of change.
> >>>>>>
> >>>>>>  =E2=80=94Tom
> >>>>> Tom,
> >>>>>
> >>>>> I think Andy is talking about applicability - to which kind of
> servers
> >>>>> do these requirements apply. For example, if it takes more time on =
a
> >>>>> certain class of devices to retrieve the difference between applied
> >>>>> and intended config than it takes to turn intended config into
> applied
> >>>>> config, then these requirements may not be applicable (since by the
> >>>>> time you have finished retrieving the difference it has vanished).
> >>>> I think it is not only matter of synchronisation delays between
> intended
> >>>> and applied configuration. I have serious troubles understanding how
> >>>> these concepts map to the class of devices I am mainly interested in=
.
> >>>>
> >>>> Let me give you an example: An OpenWRT router runs a NETCONF/RESTCON=
F
> >>>> server that supports intended and applied config. Assume the server
> >>>> implements modules of the acl-model family so that firewall rules ca=
n
> be
> >>>> configured through NETCONF/RESTCONF. Great.
> >>>>
> >>>> Now an admin runs "iptables" to manipulate netfilter rules in the
> >>>> kernel. How does it affect the applied and intended configurations?
> >>>>
> >>>> A. The change isn't reflected in applied configuration. Then applied
> >>>>    configuration is no more "=E2=80=A6, the configuration state whic=
h is
> >>>>    currently being used by server components (e.g., control plane
> >>>>    daemons, operating system kernels, line cards)."
> >>>>
> >>>> B. The change is reflected in applied but not in intended
> >>>>    configuration. This violates requirement 1 sub D, and also it may
> be
> >>>>    impossible to map the kernel changes back to the configuration.
> >>>>
> >>>> For sure, these problems exist also with the good old "running", but=
 I
> >>>> think the migration to intended-applied would just make things worse=
.
> >>> If I understand your example correctly, then the complexity in your
> scenario is that what is actually written in the hardware is controlled b=
y
> two independent management entities.  Is that right?
> >> Right, and this is quite typical for systems where users have access t=
o
> a standard Unix shell and/or can install software on their own.
> >>
> >>> If so I think that your scenario is outside what could be reasonably
> expected to be defined by a standards specification.
> >> Why? Such systems could also benefit from NETCONF/RESTCONF and standar=
d
> data models.
> > Sure.   But I don't see how you can standardize against a configuration
> system that probably isn't strongly specified itself.
> >
>
> Well, only if "strongly specified" means that the ways how the user is
> allowed to interact with the system are strictly controlled. Open-source
> system are usually fond of keeping the user empowered. We have to live wi=
th
> it.
>
> >
> >>
> >>> Ideally, all of the related configuration would be managed by the sam=
e
> YANG data model, in which case I would expect that your problem would
> disappear.
> >> It can be managed by the same YANG models as other devices, one can
> just never think that what's in the configuration is also what the system
> uses. The only (reasonably) reliable source for the latter is the /proc
> filesystem, which actually comes close to the definition of applied
> configuration - only its data model is generally very different.
> > Personally, I would think that a device knowing what configuration it i=
s
> actually running should be the desired and default expectation, and not
> being able to provide this is a deficiency.
> >
> > Somehow the operator needs to be able to figure out whether a device is
> doing what it is supposed to be doing.  I don't think that it
>
> The operator (using a NETCONF/RESTCONF client) should be able to figure
> out what the device is doing by inspecting state data. That's why we have
> the separate *-state trees that often duplicate configuration data.
>
> >  is really reasonable to just force this problem on to the operators an=
d
> tell them that they need to figure it out themselves.  This would mean th=
at
> each and every operator that needs to interact with that device either ha=
s
> to accept that either they don't know what it is actually doing, or they
> have to independently implement a similar solution to figure it out.
> >
> >>
> >>> Pragmatically, I suspect that you can't do that, in which case I woul=
d
> model the opstate requirements as only applying to the YANG
> >> Yes, it is not realistic.
> >>
> >>> part of the configuration.  I.e. the ACL model is in applied
> configuration applied if it is regarded as being a valid input to what is
> being programmed into the system.  What is actually programmed in the
> forwarding filter depends on both the accepted ACL YANG configuration and
> also the other independent configuration.
> >> Sure, but then applied configuration is of no use.
> > That's not entirely true.
> >
> > The operator still knows that the system is actually acting on the
> configuration that the user intended, it just doesn't mean that it has
> necessarily been programmed into the forwarding plane. That is subject to
> the other independent configuration allowing the ACL YANG configuration i=
s
> in effect.
> >
> > E.g. in the following ASCII Art diagram, then if A was the YANG config,
> then they would know that has been successfully applied, even though they
> don't know about your other configuration 'B', or what ends up in the
> forwarding plane (derived state) :
> >
> > A =3D=3D\
> >     =3D=3D=3D> Forwarding plane
> > B =3D=3D/
> >
> >
> > Without the applied configuration state, the operator knows less
> information.  I.e. if the forwarding plane hasn't been programmed correct=
ly
> then that might be either because the ACL YANG configuration (A) hasn't
> been applied or because the independent configuration (B) interferes with
> it.
>
> I think the substantial information is what parameters the system is
> currently using. If there is no guarantee that applied configuration has
> this information, then it is IMO much less interesting.
>
> I understand that for some systems the intended-applied configuration may
> be the right thing to do, so it could perhaps be defined as an optional
> capability. I just don't agree that this concept is universally applicabl=
e
> to all systems.
>
>

The concept is applicable to all systems.
There will be non-zero elapsed time on any system between
the time of the request and the time the config is applied.

The amount of time is purely an implementation detail.
Many servers accomplish this task in under 1 second for a typical edit.
Whether this elapsed time is an operational problem or not really depends
on the deployment.


Lada
>


Andy


>
> >
> > Thanks,
> > Rob
> >
> >
> >>
> >> Lada
> >>
> >>> Thanks,
> >>> Rob
> >>>
> >>>
> >>>> Lada
> >>>>
> >>>>
> >>>>> Andy, did I get this right?
> >>>>>
> >>>>> /js
> >>>>>
> >>>>> --
> >>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >>>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen |
> Germany
> >>>>> Fax:   +49 421 200 3103         
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >>
> >>
> >>
> >>
> >> .
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Mon, Dec 21, 2015 at 12:17 PM, Ladislav Lhotka <=
;lhotka@nic.cz> wrote:


> On 21 Dec 2015, at 17:42, Robert Wilton <rwilton@cisco.com> wrote:

>

> Hi Lada,

>

> On 21/12/2015 16:05, Ladislav Lhotka wrote:

>>> On 21 Dec 2015, at 16:05, Robert Wilton <rwilton@cisco.com> wrote:

>>>

>>> Hi Lada,

>>>

>>> On 21/12/2015 13:55, Ladislav Lhotka wrote:

>>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes=
:

>>>>

>>>>> On Thu, Dec 17, 2015 at 10:52:13AM -0500, Nadeau Thoma=
s wrote:

>>>>>>> On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Wats=
en <kwatsen@juniper.net> w=
rote:

>>>>>>>

>>>>>>>

>>>>>>>

>>>>>>>

>>>>>>>

>>>>>>>

>>>>>>>>>> I=E2=80=99m struggling a bit to un=
derstand what is motivating you to ask this question.=C2=A0 =C2=A0 That is,=
 as a tool vendor, I wouldn=E2=80=99t think that any decision made here wou=
ld affect you immediately.=C2=A0 =C2=A0My expectations are that any impact =
to YANG/NETCONF/RESTCONF would be backwards compatible, such that implement=
ations would only opt-in when needed - a pay as you grow strategy.=C2=A0 =
=C2=A0But herein perhaps lies an unstated requirement, that the impact to Y=
ANG/NETCONF/RESTCONF needs to be backwards compatible with respect to exist=
ing deployments.=C2=A0 Did we miss it or is it too obvious?

>>>>>>>>>>

>>>>>>>>> It may be obvious for many of us but f=
or the sake of completeness I

>>>>>>>>> prefer to have this backwards compatib=
ility assumption explicitely

>>>>>>>>> stated.

>>>>>>>> +1

>>>>>>> [as a chair]

>>>>>>>

>>>>>>> As last call comment, there seems to be suppor=
t for adding a requirement to the opstate-reqs draft to state that solution=
s supporting said requirements MUST be backwards compatible with respect to=
 existing deployments.=C2=A0 Do we have WG consensus to add this as a requi=
rement to this draft?=C2=A0 Are there any objections? Please voice your opi=
nion before the last call cutoff date (Dec 30).

>>>>>>>

>>>>>>>

>>>>>>> [as a contributor]

>>>>>>>

>>>>>>>

>>>>>>> I=E2=80=99m unsure if it makes sense to call i=
t out in this draft, in that it seems universally applicable, but I don=E2=
=80=99t see any harm in it either and thus do not object.

>>>>>>>

>>>>>>>

>>>>>>> Kent

>>>>>>=C2=A0 [As Co-chair]

>>>>>>

>>>>>>=C2=A0 Given the tall hill we climbed to get to thi=
s point on the requirements, I

>>>>>> want to be clear that there needs to be very signi=
ficant support to change the requirements

>>>>>> in any significant way. We went round and round th=
e drain on settling on these requirements, and

>>>>>> people had a whole host of reasonable opportunitie=
s to add this during those times. I want to point out that while this state=
ment may seem subtle, slipping this in at the last minute could have a prof=
ound impact on solutions built from these requirements, so I want to be sur=
e everyone involved has through through this kind of change.

>>>>>>

>>>>>>=C2=A0 =E2=80=94Tom

>>>>> Tom,

>>>>>

>>>>> I think Andy is talking about applicability - to which=
 kind of servers

>>>>> do these requirements apply. For example, if it takes =
more time on a

>>>>> certain class of devices to retrieve the difference be=
tween applied

>>>>> and intended config than it takes to turn intended con=
fig into applied

>>>>> config, then these requirements may not be applicable =
(since by the

>>>>> time you have finished retrieving the difference it ha=
s vanished).

>>>> I think it is not only matter of synchronisation delays be=
tween intended

>>>> and applied configuration. I have serious troubles underst=
anding how

>>>> these concepts map to the class of devices I am mainly int=
erested in.

>>>>

>>>> Let me give you an example: An OpenWRT router runs a NETCO=
NF/RESTCONF

>>>> server that supports intended and applied config. Assume t=
he server

>>>> implements modules of the acl-model family so that firewal=
l rules can be

>>>> configured through NETCONF/RESTCONF. Great.

>>>>

>>>> Now an admin runs "iptables" to manipulate netfi=
lter rules in the

>>>> kernel. How does it affect the applied and intended config=
urations?

>>>>

>>>> A. The change isn't reflected in applied configuration=
. Then applied

>>>>=C2=A0 =C2=A0 configuration is no more "=E2=80=A6, the=
 configuration state which is

>>>>=C2=A0 =C2=A0 currently being used by server components (e.=
g., control plane

>>>>=C2=A0 =C2=A0 daemons, operating system kernels, line cards=
)."

>>>>

>>>> B. The change is reflected in applied but not in intended<=
br>
>>>>=C2=A0 =C2=A0 configuration. This violates requirement 1 su=
b D, and also it may be

>>>>=C2=A0 =C2=A0 impossible to map the kernel changes back to =
the configuration.

>>>>

>>>> For sure, these problems exist also with the good old &quo=
t;running", but I

>>>> think the migration to intended-applied would just make th=
ings worse.

>>> If I understand your example correctly, then the complexity in=
 your scenario is that what is actually written in the hardware is controll=
ed by two independent management entities.=C2=A0 Is that right?

>> Right, and this is quite typical for systems where users have acce=
ss to a standard Unix shell and/or can install software on their own.

>>

>>> If so I think that your scenario is outside what could be reas=
onably expected to be defined by a standards specification.

>> Why? Such systems could also benefit from NETCONF/RESTCONF and sta=
ndard data models.

> Sure.=C2=A0 =C2=A0But I don't see how you can standardize against =
a configuration system that probably isn't strongly specified itself.
>



Well, only if "strongly specified" means that the ways how the us=
er is allowed to interact with the system are strictly controlled. Open-sou=
rce system are usually fond of keeping the user empowered. We have to live =
with it.



>

>>

>>> Ideally, all of the related configuration would be managed by =
the same YANG data model, in which case I would expect that your problem wo=
uld disappear.

>> It can be managed by the same YANG models as other devices, one ca=
n just never think that what's in the configuration is also what the sy=
stem uses. The only (reasonably) reliable source for the latter is the /pro=
c filesystem, which actually comes close to the definition of applied confi=
guration - only its data model is generally very different.

> Personally, I would think that a device knowing what configuration it =
is actually running should be the desired and default expectation, and not =
being able to provide this is a deficiency.

>

> Somehow the operator needs to be able to figure out whether a device i=
s doing what it is supposed to be doing.=C2=A0 I don't think that it


The operator (using a NETCONF/RESTCONF client) should be able to figure out=
 what the device is doing by inspecting state data. That's why we have =
the separate *-state trees that often duplicate configuration data.



>=C2=A0 is really reasonable to just force this problem on to the operat=
ors and tell them that they need to figure it out themselves.=C2=A0 This wo=
uld mean that each and every operator that needs to interact with that devi=
ce either has to accept that either they don't know what it is actually=
 doing, or they have to independently implement a similar solution to figur=
e it out.

>

>>

>>> Pragmatically, I suspect that you can't do that, in which =
case I would model the opstate requirements as only applying to the YANG
>> Yes, it is not realistic.

>>

>>> part of the configuration.=C2=A0 I.e. the ACL model is in appl=
ied configuration applied if it is regarded as being a valid input to what =
is being programmed into the system.=C2=A0 What is actually programmed in t=
he forwarding filter depends on both the accepted ACL YANG configuration an=
d also the other independent configuration.

>> Sure, but then applied configuration is of no use.

> That's not entirely true.

>

> The operator still knows that the system is actually acting on the con=
figuration that the user intended, it just doesn't mean that it has nec=
essarily been programmed into the forwarding plane. That is subject to the =
other independent configuration allowing the ACL YANG configuration is in e=
ffect.

>

> E.g. in the following ASCII Art diagram, then if A was the YANG config=
, then they would know that has been successfully applied, even though they=
 don't know about your other configuration 'B', or what ends up=
 in the forwarding plane (derived state) :

>

> A =3D=3D\

>=C2=A0 =C2=A0 =C2=A0=3D=3D=3D> Forwarding plane

> B =3D=3D/

>

>

> Without the applied configuration state, the operator knows less infor=
mation.=C2=A0 I.e. if the forwarding plane hasn't been programmed corre=
ctly then that might be either because the ACL YANG configuration (A) hasn&=
#39;t been applied or because the independent configuration (B) interferes =
with it.



I think the substantial information is what parameters the system is curren=
tly using. If there is no guarantee that applied configuration has this inf=
ormation, then it is IMO much less interesting.



I understand that for some systems the intended-applied configuration may b=
e the right thing to do, so it could perhaps be defined as an optional capa=
bility. I just don't agree that this concept is universally applicable =
to all systems.




The concept is applicab=
le to all systems.
There will be non-zero elapsed time on any sys=
tem between
the time of the request and the time the config is ap=
plied.

The amount of time is purely an implementat=
ion detail.
Many servers accomplish this task in under 1 second f=
or a typical edit.
Whether this elapsed time is an operational pr=
oblem or not really depends
on the deployment.



Lada


Andy
=C2=
=A0



>

> Thanks,

> Rob

>

>

>>

>> Lada

>>

>>> Thanks,

>>> Rob

>>>

>>>

>>>> Lada

>>>>

>>>>

>>>>> Andy, did I get this right?

>>>>>

>>>>> /js

>>>>>

>>>>> --

>>>>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0Jacobs University Bremen gGmbH

>>>>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Campus 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/>

>> --

>> Ladislav Lhotka, CZ.NIC Labs

>> PGP Key ID: E74E8C0C

>>

>>

>>

>>

>> .



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C









_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a1140223eafada205276f41f0--


From nobody Tue Dec 22 00:49:31 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EF61A878C for ; Tue, 22 Dec 2015 00:49:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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 lSyl4D9cQCo1 for ; Tue, 22 Dec 2015 00:49:27 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 696CF1A878B for ; Tue, 22 Dec 2015 00:49:26 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:a0d6:b6d3:7f79:6a7] (unknown [IPv6:2001:718:1a02:1:a0d6:b6d3:7f79:6a7]) by mail.nic.cz (Postfix) with ESMTPSA id BD0C5181AE4; Tue, 22 Dec 2015 09:49:24 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450774164; bh=lT05t6MhLqCt3foC/ZEhKGHl8t1Z4OGR7DjtqYM9Xdk=; h=From:Date:To; b=PWffBdL4taUgEgwNdSC39dZl7sMm0CviOWioSIPm2/76gY8J9FTXQLSJ0o9NjpAAm ZXGZ4dtFQvlIGwf6eA844xjAC92EmnTTQ8mDbfcJDFt8ceJLsXXcrfpLkkaGO2eATM LEGRpYz7zgqSonwlURx72Bufd8Xy2tKAAPEdMZq4=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Tue, 22 Dec 2015 09:49:25 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <2FC98F02-1419-4776-A4A9-AAFC8925085F@nic.cz>
References: <688712B2-50E6-4DCB-A43D-BD2CFA0D40A2@lucidvision.com>  <02367647-696D-4BA8-81FA-15CB95D5DBDA@juniper.net> <20151217071728.GC67701@elstar.local> <43BB6143-BC67-4C15-BB73-F3F7D0633CAB@nic.cz> <23C16927-4D35-46E9-8101-B538EB5E14F4@juniper.net> <0239ADFB-4A52-4E47-8FA5-406231AD92D5@lucidvision.com> <20151217172931.GA68858@elstar.local>  <56781538.7010402@cisco.com> <3B1154B9-8055-4620-9EBD-861A7F525D94@nic.cz> <56782BFD.5080508@cisco.com>  
To: Andy Bierman 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 08:49:30 -0000

> On 21 Dec 2015, at 22:34, Andy Bierman  wrote:
>=20
>=20
>=20
> On Mon, Dec 21, 2015 at 12:17 PM, Ladislav Lhotka  =
wrote:
>=20
> > On 21 Dec 2015, at 17:42, Robert Wilton  wrote:
> >
> > Hi Lada,
> >
> > On 21/12/2015 16:05, Ladislav Lhotka wrote:
> >>> On 21 Dec 2015, at 16:05, Robert Wilton  wrote:
> >>>
> >>> Hi Lada,
> >>>
> >>> On 21/12/2015 13:55, Ladislav Lhotka wrote:
> >>>> Juergen Schoenwaelder  =
writes:
> >>>>
> >>>>> On Thu, Dec 17, 2015 at 10:52:13AM -0500, Nadeau Thomas wrote:
> >>>>>>> On Dec 17, 2015:9:36 AM, at 9:36 AM, Kent Watsen =
 wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>>>> I=E2=80=99m struggling a bit to understand what is =
motivating you to ask this question.    That is, as a tool vendor, I =
wouldn=E2=80=99t think that any decision made here would affect you =
immediately.   My expectations are that any impact to =
YANG/NETCONF/RESTCONF would be backwards compatible, such that =
implementations would only opt-in when needed - a pay as you grow =
strategy.   But herein perhaps lies an unstated requirement, that the =
impact to YANG/NETCONF/RESTCONF needs to be backwards compatible with =
respect to existing deployments.  Did we miss it or is it too obvious?
> >>>>>>>>>>
> >>>>>>>>> It may be obvious for many of us but for the sake of =
completeness I
> >>>>>>>>> prefer to have this backwards compatibility assumption =
explicitely
> >>>>>>>>> stated.
> >>>>>>>> +1
> >>>>>>> [as a chair]
> >>>>>>>
> >>>>>>> As last call comment, there seems to be support for adding a =
requirement to the opstate-reqs draft to state that solutions supporting =
said requirements MUST be backwards compatible with respect to existing =
deployments.  Do we have WG consensus to add this as a requirement to =
this draft?  Are there any objections? Please voice your opinion before =
the last call cutoff date (Dec 30).
> >>>>>>>
> >>>>>>>
> >>>>>>> [as a contributor]
> >>>>>>>
> >>>>>>>
> >>>>>>> I=E2=80=99m unsure if it makes sense to call it out in this =
draft, in that it seems universally applicable, but I don=E2=80=99t see =
any harm in it either and thus do not object.
> >>>>>>>
> >>>>>>>
> >>>>>>> Kent
> >>>>>>  [As Co-chair]
> >>>>>>
> >>>>>>  Given the tall hill we climbed to get to this point on the =
requirements, I
> >>>>>> want to be clear that there needs to be very significant =
support to change the requirements
> >>>>>> in any significant way. We went round and round the drain on =
settling on these requirements, and
> >>>>>> people had a whole host of reasonable opportunities to add this =
during those times. I want to point out that while this statement may =
seem subtle, slipping this in at the last minute could have a profound =
impact on solutions built from these requirements, so I want to be sure =
everyone involved has through through this kind of change.
> >>>>>>
> >>>>>>  =E2=80=94Tom
> >>>>> Tom,
> >>>>>
> >>>>> I think Andy is talking about applicability - to which kind of =
servers
> >>>>> do these requirements apply. For example, if it takes more time =
on a
> >>>>> certain class of devices to retrieve the difference between =
applied
> >>>>> and intended config than it takes to turn intended config into =
applied
> >>>>> config, then these requirements may not be applicable (since by =
the
> >>>>> time you have finished retrieving the difference it has =
vanished).
> >>>> I think it is not only matter of synchronisation delays between =
intended
> >>>> and applied configuration. I have serious troubles understanding =
how
> >>>> these concepts map to the class of devices I am mainly interested =
in.
> >>>>
> >>>> Let me give you an example: An OpenWRT router runs a =
NETCONF/RESTCONF
> >>>> server that supports intended and applied config. Assume the =
server
> >>>> implements modules of the acl-model family so that firewall rules =
can be
> >>>> configured through NETCONF/RESTCONF. Great.
> >>>>
> >>>> Now an admin runs "iptables" to manipulate netfilter rules in the
> >>>> kernel. How does it affect the applied and intended =
configurations?
> >>>>
> >>>> A. The change isn't reflected in applied configuration. Then =
applied
> >>>>    configuration is no more "=E2=80=A6, the configuration state =
which is
> >>>>    currently being used by server components (e.g., control plane
> >>>>    daemons, operating system kernels, line cards)."
> >>>>
> >>>> B. The change is reflected in applied but not in intended
> >>>>    configuration. This violates requirement 1 sub D, and also it =
may be
> >>>>    impossible to map the kernel changes back to the =
configuration.
> >>>>
> >>>> For sure, these problems exist also with the good old "running", =
but I
> >>>> think the migration to intended-applied would just make things =
worse.
> >>> If I understand your example correctly, then the complexity in =
your scenario is that what is actually written in the hardware is =
controlled by two independent management entities.  Is that right?
> >> Right, and this is quite typical for systems where users have =
access to a standard Unix shell and/or can install software on their =
own.
> >>
> >>> If so I think that your scenario is outside what could be =
reasonably expected to be defined by a standards specification.
> >> Why? Such systems could also benefit from NETCONF/RESTCONF and =
standard data models.
> > Sure.   But I don't see how you can standardize against a =
configuration system that probably isn't strongly specified itself.
> >
>=20
> Well, only if "strongly specified" means that the ways how the user is =
allowed to interact with the system are strictly controlled. Open-source =
system are usually fond of keeping the user empowered. We have to live =
with it.
>=20
> >
> >>
> >>> Ideally, all of the related configuration would be managed by the =
same YANG data model, in which case I would expect that your problem =
would disappear.
> >> It can be managed by the same YANG models as other devices, one can =
just never think that what's in the configuration is also what the =
system uses. The only (reasonably) reliable source for the latter is the =
/proc filesystem, which actually comes close to the definition of =
applied configuration - only its data model is generally very different.
> > Personally, I would think that a device knowing what configuration =
it is actually running should be the desired and default expectation, =
and not being able to provide this is a deficiency.
> >
> > Somehow the operator needs to be able to figure out whether a device =
is doing what it is supposed to be doing.  I don't think that it
>=20
> The operator (using a NETCONF/RESTCONF client) should be able to =
figure out what the device is doing by inspecting state data. That's why =
we have the separate *-state trees that often duplicate configuration =
data.
>=20
> >  is really reasonable to just force this problem on to the operators =
and tell them that they need to figure it out themselves.  This would =
mean that each and every operator that needs to interact with that =
device either has to accept that either they don't know what it is =
actually doing, or they have to independently implement a similar =
solution to figure it out.
> >
> >>
> >>> Pragmatically, I suspect that you can't do that, in which case I =
would model the opstate requirements as only applying to the YANG
> >> Yes, it is not realistic.
> >>
> >>> part of the configuration.  I.e. the ACL model is in applied =
configuration applied if it is regarded as being a valid input to what =
is being programmed into the system.  What is actually programmed in the =
forwarding filter depends on both the accepted ACL YANG configuration =
and also the other independent configuration.
> >> Sure, but then applied configuration is of no use.
> > That's not entirely true.
> >
> > The operator still knows that the system is actually acting on the =
configuration that the user intended, it just doesn't mean that it has =
necessarily been programmed into the forwarding plane. That is subject =
to the other independent configuration allowing the ACL YANG =
configuration is in effect.
> >
> > E.g. in the following ASCII Art diagram, then if A was the YANG =
config, then they would know that has been successfully applied, even =
though they don't know about your other configuration 'B', or what ends =
up in the forwarding plane (derived state) :
> >
> > A =3D=3D\
> >     =3D=3D=3D> Forwarding plane
> > B =3D=3D/
> >
> >
> > Without the applied configuration state, the operator knows less =
information.  I.e. if the forwarding plane hasn't been programmed =
correctly then that might be either because the ACL YANG configuration =
(A) hasn't been applied or because the independent configuration (B) =
interferes with it.
>=20
> I think the substantial information is what parameters the system is =
currently using. If there is no guarantee that applied configuration has =
this information, then it is IMO much less interesting.
>=20
> I understand that for some systems the intended-applied configuration =
may be the right thing to do, so it could perhaps be defined as an =
optional capability. I just don't agree that this concept is universally =
applicable to all systems.
>=20
>=20
>=20
> The concept is applicable to all systems.
> There will be non-zero elapsed time on any system between
> the time of the request and the time the config is applied.

Sure, but on some systems such as home routers this delay is of no =
interest, also because the admin edits the configuration and then has to =
apply it explicitly. This is how it works now (/etc/init.d/firewall =
reload), and NETCONF/RESTCONF just adds a solid remote operation.

Lada

>=20
> The amount of time is purely an implementation detail.
> Many servers accomplish this task in under 1 second for a typical =
edit.
> Whether this elapsed time is an operational problem or not really =
depends
> on the deployment.
>=20
>=20
> Lada
>=20
>=20
> Andy
> =20
>=20
> >
> > Thanks,
> > Rob
> >
> >
> >>
> >> Lada
> >>
> >>> Thanks,
> >>> Rob
> >>>
> >>>
> >>>> Lada
> >>>>
> >>>>
> >>>>> Andy, did I get this right?
> >>>>>
> >>>>> /js
> >>>>>
> >>>>> --
> >>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >>>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | =
Germany
> >>>>> Fax:   +49 421 200 3103         =

> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >>
> >>
> >>
> >>
> >> .
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Tue Dec 22 02:01:15 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9859E1A886D for ; Tue, 22 Dec 2015 02:01:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 NKtgklmffNif for ; Tue, 22 Dec 2015 02:01:12 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE861A6FCB for ; Tue, 22 Dec 2015 02:01:11 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E4BCD8F4; Tue, 22 Dec 2015 11:01:09 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 72Ex1Geojilg; Tue, 22 Dec 2015 11:01:08 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 22 Dec 2015 11:01:08 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 084BF20058; Tue, 22 Dec 2015 11:01:08 +0100 (CET)
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 K4aKzPDDxII0; Tue, 22 Dec 2015 11:01:04 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7939920055; Tue, 22 Dec 2015 11:01:03 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 7EADE3960580; Tue, 22 Dec 2015 11:01:01 +0100 (CET)
Date: Tue, 22 Dec 2015 11:01:01 +0100
From: Juergen Schoenwaelder 
To: Andy Bierman 
Message-ID: <20151222100101.GA45259@elstar.local>
Mail-Followup-To: Andy Bierman , Ladislav Lhotka , NETMOD WG 
References: <1033983.1450551979726.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>  <20151221144723.GA43211@elstar.local> <5E9674F3-DDAB-479F-A8CA-0CF78FE5F1F2@nic.cz> <20151221154054.GB43316@elstar.local> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 10:01:14 -0000

On Mon, Dec 21, 2015 at 11:28:41AM -0800, Andy Bierman wrote:

> However, we do seem to aggressively extract YANG modules from documents and
> then ignore the source document completely.
> There is absolutely no way for a YANG compiler to tell the difference
> between a module extracted from an Internet Draft from a module
> extracted from an RFC.

This is a tool problem that is easy to solve (e.g., by storing
published modules separately from other modules).

/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 Dec 22 02:35:43 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971661A88A6 for ; Tue, 22 Dec 2015 02:35:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 TvhuKyT3ebRf for ; Tue, 22 Dec 2015 02:35:39 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA8671A88A3 for ; Tue, 22 Dec 2015 02:35:39 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:a0d6:b6d3:7f79:6a7] (unknown [IPv6:2001:718:1a02:1:a0d6:b6d3:7f79:6a7]) by mail.nic.cz (Postfix) with ESMTPSA id EEB49181809 for ; Tue, 22 Dec 2015 11:35:37 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450780538; bh=npjsxeK8lb74ZWzE1Ax+AypjF7Bmuu3dueiz0/zqnF8=; h=From:Date:To; b=f+EIGykQrRWiFCQxByIA5cDFI7XU0iBRnDkIsY2Lq4qG4i9XaoKpVi9uOPP6DWa+D xYSRevDrIVy0Xpix2TM1CaQWLyp716j4Hmhpe2JvfoLYq4yJCIE5HpCILrAD1mq88K rYC1WYWS0U9hDnqwZmlTAigJEj7rxNzbT0WW8f7s=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <20151222100634.GB45259@elstar.local>
Date: Tue, 22 Dec 2015 11:35:39 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <1033983.1450551979726.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>  <20151221144723.GA43211@elstar.local> <5E9674F3-DDAB-479F-A8CA-0CF78FE5F1F2@nic.cz> <20151221154054.GB43316@elstar.local> <82E7F91B-9DC4-4E8A-B042-A87B21683283@nic.cz> <20151221190439.GA44038@elstar.local>  <20151222100634.GB45259@elstar.local>
To: NETMOD WG 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 10:35:41 -0000

> On 22 Dec 2015, at 11:06, Juergen Schoenwaelder =
 wrote:
>=20
> On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka wrote:
>>=20
>>>=20
>>> That's why the definition what 'published' means in the IETF is in =
the
>>> guidelines document. On the other hand, since this is an IETF
>>> document, I also do not find it problematic to define IETF rules
>>> here. Others should be able to skip over this. There are really more
>>> important problems to solve.
>>=20
>> It is not clear at all from sec. 10 that data modellers outside IETF =
may skip over this. I am not even sure that everybody in this WG agrees =
with your interpretation.
>>=20
>=20
> You are wrong.
>=20
> - Section 10 in RFC 6020 applies to all published modules.

The bullets specifying the rules are introduced with this sentence:

'A definition may be revised in any of the following ways:'

so IMO it is intended to apply to *all* modules. Are you saying that it =
actually means

'A definition in a module published by IETF may be revised in any of the =
following ways:'?

>=20
> - The definition of what turns a module into a published module is
> specific to the different organizations publishing modules.

So it means that such an organization may also decide to ignore the =
rules entirely or replace them with its own rules.

If the WG can agree on this and make the corresponding changes in sec. =
11 of 6020bis, then I have no more objections. =20

Lada

>=20
> - For the IETF, the definition is publication as an RFC. I do not care
> whether this definition is in RFC 6020bis or RFC 6087bis.
>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Tue Dec 22 03:38:06 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 774921A00FD for ; Tue, 22 Dec 2015 03:38:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 7BpA5kwKtf00 for ; Tue, 22 Dec 2015 03:38:03 -0800 (PST)
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 269931A00FC for ; Tue, 22 Dec 2015 03:38:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1297; q=dns/txt; s=iport; t=1450784283; x=1451993883; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=B4WBLkW9NnwBT9lbpVsDccZv6Udvp17zVX1Us7rDt98=; b=ccZL9uPodMM8G1S5jcq3wqUdNTSeeiLgFix76R++2LuWuPrWRaN58Q0N IrWs1ODId7AjLyUplTJbgy2Xht0DxJliEkvllHmy57cF7mrBq59erlbfA 4dJ8YgZlvQnqS1KK2nHTvniCdNefV6MfyO7pjyzurEmvt1kTte6w6Ja+P A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpBABUNXlW/xbLJq1ekUqvCoQKhg0Cg?= =?us-ascii?q?WYRAQEBAQEBAYEKhDUBAQQyAQVAEQsYCRYPCQMCAQIBRQYBDAgBAReIFL8sAQE?= =?us-ascii?q?BAQEBAQMBAQEBAQEdhlaEfolBAQSXAI1MgVyHSoVVikODdDgshAU9hTYBAQE?=
X-IronPort-AV: E=Sophos;i="5.20,464,1444694400"; d="scan'208";a="639261700"
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; 22 Dec 2015 11:38:01 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tBMBc1tS001363; Tue, 22 Dec 2015 11:38:01 GMT
To: Andy Bierman , Kent Watsen , "netmod@ietf.org" 
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>  <56783B45.1020505@cisco.com> <20151221180231.GC43694@elstar.local>
From: Benoit Claise 
Message-ID: <56793618.3080403@cisco.com>
Date: Tue, 22 Dec 2015 12:38:00 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <20151221180231.GC43694@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 11:38:04 -0000

Jürgen,
> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>
>> I hope that nobody disagrees that the operational state design and how
>> to structure the models are the two blocking factors to publish YANG
>> models. If you disagree or don't see this, let me know, I should
>> communicate better.
> Even if it may spoil your day, I disagree that there is a blocking
> factor that should stop us from publishing models.
Interestingly, I received that feedback again recently, this time from 
the OSPF and ISIS YANG model authors.
> There seem to be
> ways to address the requirements without having to block all work or
> to redo what that we have published.
That's my hope too.
> But sure, if you make it a
> blocking factor, it will be one.
I'll chose to ignore this last sentence.

Regards, Benoit
>
>> I hope that nobody really believes that because some people in IETF (or
>> in any other SDOs) thinks that what those operators want is a bad idea,
>> those operators will not get what they request/pay for from their suppliers.
> To be fair, those operators also tell us that they use protocols that
> are not IETF protocols and it remains somewhat unclear what those
> protocols are we are expected to optimize data model solutions for.
>
> /js
>


From nobody Tue Dec 22 03:44:42 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4311A010D for ; Tue, 22 Dec 2015 03:44:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.101
X-Spam-Level: 
X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 Iky5XJ3580ft for ; Tue, 22 Dec 2015 03:44:35 -0800 (PST)
Received: from SNT004-OMC3S3.hotmail.com (snt004-omc3s3.hotmail.com [65.55.90.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 828F01A0108 for ; Tue, 22 Dec 2015 03:44:35 -0800 (PST)
Received: from SNT404-EAS329 ([65.55.90.137]) by SNT004-OMC3S3.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008);  Tue, 22 Dec 2015 03:44:34 -0800
X-TMN: [Fzs//bGbWHjhKpLlF9zdpXEiP+jy+0XB]
X-Originating-Email: [rohitrranade@outlook.com]
Message-ID: 
Date: Tue, 22 Dec 2015 11:44:34 +0000
From: 
To: netmod@ietf.org
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_2085_626058790.1450784674482"
X-Mailer: Outlook for iOS and Android
X-OriginalArrivalTime: 22 Dec 2015 11:44:35.0013 (UTC) FILETIME=[213DCF50:01D13CAE]
Archived-At: 
Subject: [netmod] Draft clemm netmod mount draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 11:44:40 -0000

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

=0A=
=0A=
In the controller-network data model =2C is the interfaces module imported =
for a specific reason ?=0A=
=0A=
=0A=
=0A=
=0A=
Sent from Outlook Mobile=0A=
=0A=
=0A=

------=_Part_2085_626058790.1450784674482
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable


In the controller-network data model =2C is the interfaces m=
odule imported for a specific reason ?

=0A=

Sent from Outlook Mobile
=0A=

=0A=

------=_Part_2085_626058790.1450784674482--


From nobody Tue Dec 22 03:45:38 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00151A010D for ; Tue, 22 Dec 2015 03:45:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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 z-UJriiPmnmD for ; Tue, 22 Dec 2015 03:45:36 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C99A31A0108 for ; Tue, 22 Dec 2015 03:45:35 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:a0d6:b6d3:7f79:6a7] (unknown [IPv6:2001:718:1a02:1:a0d6:b6d3:7f79:6a7]) by mail.nic.cz (Postfix) with ESMTPSA id 87FA5180E8C; Tue, 22 Dec 2015 12:45:34 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450784734; bh=WEFUTRPnldgel1xClU5kDGqj3nPbDfOV8mgold343R4=; h=From:Date:To; b=Grbutj6c+a9n8hyuVvr20kBqQ7rL/pF3ZxvmHqd5lLR5JIgRg72h8pimyWlK1VxdV foZHlonWwToGxyXnPPxaPLuMQy7jM29BWuqHNrmLKxxfP6wHpU9qqT2lv1Ao85LWEQ lRpo2Dh/TQuMyLZKXt8PBgLkPcWaNW8aoEkRIJeI=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <56793618.3080403@cisco.com>
Date: Tue, 22 Dec 2015 12:45:35 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <003272D4-EB32-47DE-A105-DDB894F9D8C7@nic.cz>
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>  <56783B45.1020505@cisco.com> <20151221180231.GC43694@elstar.local> <56793618.3080403@cisco.com>
To: Benoit Claise 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 11:45:38 -0000

> On 22 Dec 2015, at 12:38, Benoit Claise  wrote:
>=20
> J=FCrgen,
>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>>=20
>>> I hope that nobody disagrees that the operational state design and =
how
>>> to structure the models are the two blocking factors to publish YANG
>>> models. If you disagree or don't see this, let me know, I should
>>> communicate better.
>> Even if it may spoil your day, I disagree that there is a blocking
>> factor that should stop us from publishing models.
> Interestingly, I received that feedback again recently, this time from =
the OSPF and ISIS YANG model authors.

Did they mention any reason *why* it is a blocking factor for their =
modules?

Thanks, Lada

>> There seem to be
>> ways to address the requirements without having to block all work or
>> to redo what that we have published.
> That's my hope too.
>> But sure, if you make it a
>> blocking factor, it will be one.
> I'll chose to ignore this last sentence.
>=20
> Regards, Benoit
>>=20
>>> I hope that nobody really believes that because some people in IETF =
(or
>>> in any other SDOs) thinks that what those operators want is a bad =
idea,
>>> those operators will not get what they request/pay for from their =
suppliers.
>> To be fair, those operators also tell us that they use protocols that
>> are not IETF protocols and it remains somewhat unclear what those
>> protocols are we are expected to optimize data model solutions for.
>>=20
>> /js
>>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Tue Dec 22 04:03:13 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6CAB1A0167 for ; Tue, 22 Dec 2015 04:03:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 BBI7X_iK2uQm for ; Tue, 22 Dec 2015 04:03:10 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 238FF1A0158 for ; Tue, 22 Dec 2015 04:03:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3252; q=dns/txt; s=iport; t=1450785790; x=1451995390; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uPJ09ChtXmACebFUXCFKOy9qaawa3kIsXUu7y/DgGUw=; b=VovUXlSI1yT4loY+gSrEbtxM2yC+tEOu1rJMTiALHljVWxKOEAYiWlqL +mvrrI3XcbNDV+43uuP/d4JeIpGDaYTdipLKTq+7lDD4EuMnM1qdM0EPm 8o5+0NI2+ilI0yLdoXeWM0W8w2XwOSoEz7iZZ2GUAdXfMAwGGZEIUQVPN A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvAgCPO3lW/4ENJK1egzpSbQaMS7EmA?= =?us-ascii?q?Q2BYxcKhSJKAhyBDzgUAQEBAQEBAYEKhDQBAQEDAQEBASAREycLEAIBCBgCAiY?= =?us-ascii?q?CAgIlCxUQAgQBDQUbiAwIDqxxhRqNFwEBAQEBAQEBAQEBAQEBAQEBAQEBARQEg?= =?us-ascii?q?QGKU4d3gUoFlwABjUuBXI0fikODcwEgAQFCghEdgVZyg3qBCAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.20,464,1444694400"; d="scan'208";a="219822020"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Dec 2015 12:03:09 +0000
Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id tBMC39p8013243 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Dec 2015 12:03:09 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.1104.5; Tue, 22 Dec 2015 07:03:08 -0500
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.1104.009; Tue, 22 Dec 2015 07:03:02 -0500
From: "Acee Lindem (acee)" 
To: Ladislav Lhotka , "Benoit Claise (bclaise)" 
Thread-Topic: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
Thread-Index: AQHROST+Qi5eUPyFCUOmbJF1PR1M/Z7Q8W4AgACOLQCAAASngIAEjK+AgAAEHICAASbmAIAAAh6A//+xC4A=
Date: Tue, 22 Dec 2015 12:03:01 +0000
Message-ID: 
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>  <56783B45.1020505@cisco.com> <20151221180231.GC43694@elstar.local> <56793618.3080403@cisco.com> <003272D4-EB32-47DE-A105-DDB894F9D8C7@nic.cz>
In-Reply-To: <003272D4-EB32-47DE-A105-DDB894F9D8C7@nic.cz>
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.199]
Content-Type: text/plain; charset="utf-8"
Content-ID: <46B691C04F57844AA7B70BB421E674EB@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 12:03:11 -0000

SnVyZ2VuLCBMYWRhLCANCg0KT24gMTIvMjIvMTUsIDY6NDUgQU0sICJuZXRtb2Qgb24gYmVoYWxm
IG9mIExhZGlzbGF2IExob3RrYSINCjxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg
b2YgbGhvdGthQG5pYy5jej4gd3JvdGU6DQoNCj4NCj4+IE9uIDIyIERlYyAyMDE1LCBhdCAxMjoz
OCwgQmVub2l0IENsYWlzZSA8YmNsYWlzZUBjaXNjby5jb20+IHdyb3RlOg0KPj4gDQo+PiBKw7xy
Z2VuLA0KPj4+IE9uIE1vbiwgRGVjIDIxLCAyMDE1IGF0IDA2OjQ3OjQ5UE0gKzAxMDAsIEJlbm9p
dCBDbGFpc2Ugd3JvdGU6DQo+Pj4gDQo+Pj4+IEkgaG9wZSB0aGF0IG5vYm9keSBkaXNhZ3JlZXMg
dGhhdCB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgZGVzaWduIGFuZCBob3cNCj4+Pj4gdG8gc3RydWN0
dXJlIHRoZSBtb2RlbHMgYXJlIHRoZSB0d28gYmxvY2tpbmcgZmFjdG9ycyB0byBwdWJsaXNoIFlB
TkcNCj4+Pj4gbW9kZWxzLiBJZiB5b3UgZGlzYWdyZWUgb3IgZG9uJ3Qgc2VlIHRoaXMsIGxldCBt
ZSBrbm93LCBJIHNob3VsZA0KPj4+PiBjb21tdW5pY2F0ZSBiZXR0ZXIuDQo+Pj4gRXZlbiBpZiBp
dCBtYXkgc3BvaWwgeW91ciBkYXksIEkgZGlzYWdyZWUgdGhhdCB0aGVyZSBpcyBhIGJsb2NraW5n
DQo+Pj4gZmFjdG9yIHRoYXQgc2hvdWxkIHN0b3AgdXMgZnJvbSBwdWJsaXNoaW5nIG1vZGVscy4N
Cj4+IEludGVyZXN0aW5nbHksIEkgcmVjZWl2ZWQgdGhhdCBmZWVkYmFjayBhZ2FpbiByZWNlbnRs
eSwgdGhpcyB0aW1lIGZyb20NCj4+dGhlIE9TUEYgYW5kIElTSVMgWUFORyBtb2RlbCBhdXRob3Jz
Lg0KPg0KPkRpZCB0aGV5IG1lbnRpb24gYW55IHJlYXNvbiAqd2h5KiBpdCBpcyBhIGJsb2NraW5n
IGZhY3RvciBmb3IgdGhlaXINCj5tb2R1bGVzPw0KDQpUaGlzIHNob3VsZCBiZSBvYnZpb3VzIC0g
dGhlIE9TUEYgYW5kIElTLUlTIFdHIGFyZSBub3QgZ29pbmcgdG8gcHVibGlzaA0KWUFORyBtb2Rl
bHMgdGhhdCBkb27igJl0IG1lZXQgdGhlIG9wcy1zdGF0ZSByZXF1aXJlbWVudHMuIFdoeSB3b3Vs
ZCB3ZQ0KcHVibGlzaCBzdGFuZGFyZHMgdGhhdCBkb27igJl0IG1lZXQgdGhlIHJlcXVpcmVtZW50
cyBhbmQgYXJlLCBjb25zZXF1ZW50bHksDQppcnJlbGV2YW50PyBGYWlsdXJlIHRvIHJlY29nbml6
ZSB0aGlzIGlzIGEgcmVhbCBibG9ja2luZyBpc3N1ZS4NCg0KQWNlZQ0KDQoNCg0KDQo+DQo+VGhh
bmtzLCBMYWRhDQo+DQo+Pj4gVGhlcmUgc2VlbSB0byBiZQ0KPj4+IHdheXMgdG8gYWRkcmVzcyB0
aGUgcmVxdWlyZW1lbnRzIHdpdGhvdXQgaGF2aW5nIHRvIGJsb2NrIGFsbCB3b3JrIG9yDQo+Pj4g
dG8gcmVkbyB3aGF0IHRoYXQgd2UgaGF2ZSBwdWJsaXNoZWQuDQo+PiBUaGF0J3MgbXkgaG9wZSB0
b28uDQo+Pj4gQnV0IHN1cmUsIGlmIHlvdSBtYWtlIGl0IGENCj4+PiBibG9ja2luZyBmYWN0b3Is
IGl0IHdpbGwgYmUgb25lLg0KPj4gSSdsbCBjaG9zZSB0byBpZ25vcmUgdGhpcyBsYXN0IHNlbnRl
bmNlLg0KPj4gDQo+PiBSZWdhcmRzLCBCZW5vaXQNCj4+PiANCj4+Pj4gSSBob3BlIHRoYXQgbm9i
b2R5IHJlYWxseSBiZWxpZXZlcyB0aGF0IGJlY2F1c2Ugc29tZSBwZW9wbGUgaW4gSUVURg0KPj4+
Pihvcg0KPj4+PiBpbiBhbnkgb3RoZXIgU0RPcykgdGhpbmtzIHRoYXQgd2hhdCB0aG9zZSBvcGVy
YXRvcnMgd2FudCBpcyBhIGJhZA0KPj4+PmlkZWEsDQo+Pj4+IHRob3NlIG9wZXJhdG9ycyB3aWxs
IG5vdCBnZXQgd2hhdCB0aGV5IHJlcXVlc3QvcGF5IGZvciBmcm9tIHRoZWlyDQo+Pj4+c3VwcGxp
ZXJzLg0KPj4+IFRvIGJlIGZhaXIsIHRob3NlIG9wZXJhdG9ycyBhbHNvIHRlbGwgdXMgdGhhdCB0
aGV5IHVzZSBwcm90b2NvbHMgdGhhdA0KPj4+IGFyZSBub3QgSUVURiBwcm90b2NvbHMgYW5kIGl0
IHJlbWFpbnMgc29tZXdoYXQgdW5jbGVhciB3aGF0IHRob3NlDQo+Pj4gcHJvdG9jb2xzIGFyZSB3
ZSBhcmUgZXhwZWN0ZWQgdG8gb3B0aW1pemUgZGF0YSBtb2RlbCBzb2x1dGlvbnMgZm9yLg0KPj4+
IA0KPj4+IC9qcw0KPj4+IA0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gbmV0bW9kQGlldGYu
b3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPg0K
Pi0tDQo+TGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPlBHUCBLZXkgSUQ6IEU3NEU4QzBD
DQo+DQo+DQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX18NCj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K


From nobody Tue Dec 22 04:25:24 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3A61A020A for ; Tue, 22 Dec 2015 04:25:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 XbbfCkDduLQD for ; Tue, 22 Dec 2015 04:25:20 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 441C61A0200 for ; Tue, 22 Dec 2015 04:25:19 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:a0d6:b6d3:7f79:6a7] (unknown [IPv6:2001:718:1a02:1:a0d6:b6d3:7f79:6a7]) by mail.nic.cz (Postfix) with ESMTPSA id 9A66218142B; Tue, 22 Dec 2015 13:25:17 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450787117; bh=pUSe1wJHknbumR94YradUD6+2ahO4ftTTM7ecY89KYQ=; h=From:Date:To; b=X6tbIBBB9fHEckkmODiqh8Ray4StLqbr/CpL0bkA5USmfsnfnX+IY31AGI6UUk/iy +2xdMMFO6vGcicNPB8TUuoqpp3/2D2ugQWRJOVMKY5rNKyPW7bwnolQbbB45B/NcrI 9eDLH3jOAf5i1OlbZAfX08WVvLUZn5PJiafxb2X8=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Tue, 22 Dec 2015 13:25:18 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5C282DDE-8D85-4507-92D9-1DEA0A782E17@nic.cz>
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>  <56783B45.1020505@cisco.com> <20151221180231.GC43694@elstar.local> <56793618.3080403@cisco.com> <003272D4-EB32-47DE-A105-DDB894F9D8C7@nic.cz> 
To: "Acee Lindem (acee)" 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 12:25:23 -0000

Hi Acee,

> On 22 Dec 2015, at 13:03, Acee Lindem (acee)  wrote:
>=20
> Jurgen, Lada,=20
>=20
> On 12/22/15, 6:45 AM, "netmod on behalf of Ladislav Lhotka"
>  wrote:
>=20
>>=20
>>> On 22 Dec 2015, at 12:38, Benoit Claise  wrote:
>>>=20
>>> J=C3=BCrgen,
>>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>>>>=20
>>>>> I hope that nobody disagrees that the operational state design and =
how
>>>>> to structure the models are the two blocking factors to publish =
YANG
>>>>> models. If you disagree or don't see this, let me know, I should
>>>>> communicate better.
>>>> Even if it may spoil your day, I disagree that there is a blocking
>>>> factor that should stop us from publishing models.
>>> Interestingly, I received that feedback again recently, this time =
from
>>> the OSPF and ISIS YANG model authors.
>>=20
>> Did they mention any reason *why* it is a blocking factor for their
>> modules?
>=20
> This should be obvious - the OSPF and IS-IS WG are not going to =
publish
> YANG models that don=E2=80=99t meet the ops-state requirements. Why =
would we

Can you please explain what specific ops-state requirements aren't met =
in those modules? I am interested because the same problem may possibly =
be present in our ietf-routing module.

Thanks, Lada

> publish standards that don=E2=80=99t meet the requirements and are, =
consequently,
> irrelevant? Failure to recognize this is a real blocking issue.
>=20
> Acee
>=20
>=20
>=20
>=20
>>=20
>> Thanks, Lada
>>=20
>>>> There seem to be
>>>> ways to address the requirements without having to block all work =
or
>>>> to redo what that we have published.
>>> That's my hope too.
>>>> But sure, if you make it a
>>>> blocking factor, it will be one.
>>> I'll chose to ignore this last sentence.
>>>=20
>>> Regards, Benoit
>>>>=20
>>>>> I hope that nobody really believes that because some people in =
IETF
>>>>> (or
>>>>> in any other SDOs) thinks that what those operators want is a bad
>>>>> idea,
>>>>> those operators will not get what they request/pay for from their
>>>>> suppliers.
>>>> To be fair, those operators also tell us that they use protocols =
that
>>>> are not IETF protocols and it remains somewhat unclear what those
>>>> protocols are we are expected to optimize data model solutions for.
>>>>=20
>>>> /js
>>>>=20
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Tue Dec 22 04:55:29 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A422F1A8924 for ; Tue, 22 Dec 2015 04:55:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 5jcZbZpZw3DZ for ; Tue, 22 Dec 2015 04:55:26 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 EE6E31A8923 for ; Tue, 22 Dec 2015 04:55:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450788893; bh=EZEEIGpwRv0mxJ10P3MltbrGhcM+QBQn5LPOvKnpK08=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=njbTUcYH+CnuEHqE+nvAD3Op3ZKBgMSEMBinqZwglr4i2QWeut3QHCg81iyPq2IzN 7yFuegzsc1Yc2+2lbwNSzOduDhIfQULRyw15EpoAWfBzWpHW+oVb6LLr6RH2jAztoj kDxtcCkttX9NCR8C0gb/Wkb3jNYx2sv5dTi3PWNE=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Nadeau Thomas 
In-Reply-To: <56793618.3080403@cisco.com>
Date: Tue, 22 Dec 2015 07:55:19 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <1DEB4607-3DB9-450C-884C-E0C9142F886C@lucidvision.com>
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>  <56783B45.1020505@cisco.com> <20151221180231.GC43694@elstar.local> <56793618.3080403@cisco.com>
To: Benoit Claise 
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=1 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 221, in=2939, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 12:55:27 -0000

> On Dec 22, 2015:6:38 AM, at 6:38 AM, Benoit Claise  =
wrote:
>=20
> J=FCrgen,
>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>>=20
>>> I hope that nobody disagrees that the operational state design and =
how
>>> to structure the models are the two blocking factors to publish YANG
>>> models. If you disagree or don't see this, let me know, I should
>>> communicate better.
>> Even if it may spoil your day, I disagree that there is a blocking
>> factor that should stop us from publishing models.
> Interestingly, I received that feedback again recently, this time from =
the OSPF and ISIS YANG model authors.

	This is a blocking factor that people are not considering: The =
RFC process the=20
IETF has in place is not suitable for rapid/modern/canonical model =
development.  It will=20
be difficult for the IESG review process to scale to even a couple =
models during any given=20
telechat period given the state of the document review/approval process. =
How do we=20
envision the IESG reviewing 250+ models (and growing)?  Besides the =
initial RFC version,=20
rapid refresh/update of models has the same issues.=20

	=97Tom

>> There seem to be
>> ways to address the requirements without having to block all work or
>> to redo what that we have published.
> That's my hope too.
>> But sure, if you make it a
>> blocking factor, it will be one.
> I'll chose to ignore this last sentence.
>=20
> Regards, Benoit
>>=20
>>> I hope that nobody really believes that because some people in IETF =
(or
>>> in any other SDOs) thinks that what those operators want is a bad =
idea,
>>> those operators will not get what they request/pay for from their =
suppliers.
>> To be fair, those operators also tell us that they use protocols that
>> are not IETF protocols and it remains somewhat unclear what those
>> protocols are we are expected to optimize data model solutions for.
>>=20
>> /js
>>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Dec 22 05:01:44 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A02F1A892B for ; Tue, 22 Dec 2015 05:01:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 EmtgUVvsp-8h for ; Tue, 22 Dec 2015 05:01:41 -0800 (PST)
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 C5ECF1A892A for ; Tue, 22 Dec 2015 05:01:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1327; q=dns/txt; s=iport; t=1450789300; x=1451998900; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=h79P2y5gaEiQ2pbKScOND248Ih6gH4sjK/RpMq3chQY=; b=BD71nTOozdlyJ7XM0+jEorUuCdPA/RTIAtoahT9QqVqU2pnRwWOWN22z dYkfDowm7mxntHWyIsDr3TLqwR6zwuVrMscShyXa2wr4PLKY16Ri9rGFC WKBnT8XphXirEdNBzlebQVZgcXCtEqmsTYgI1xf80rgvPjmOkyFeyMKGn Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAQCjSHlW/xbLJq1ehHmMUa8OghkBD?= =?us-ascii?q?YFjhg0CgWEUAQEBAQEBAYEKhDUBAQQyAQVAARALDgoJFg8JAwIBAgFFBg0GAgE?= =?us-ascii?q?BiCu/OQEBAQEBAQEBAQEBAQEBAQEBHIZWhH6EKhEBhQUBBJcAjUyBXIdKhVWFU?= =?us-ascii?q?4Rwg3QgAQFChAU9NINAgUIBAQE?=
X-IronPort-AV: E=Sophos;i="5.20,464,1444694400"; d="scan'208";a="620785145"
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; 22 Dec 2015 13:01:38 +0000
Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tBMD1c0r009825; Tue, 22 Dec 2015 13:01:38 GMT
To: Nadeau Thomas 
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>  <56783B45.1020505@cisco.com> <20151221180231.GC43694@elstar.local> <56793618.3080403@cisco.com> <1DEB4607-3DB9-450C-884C-E0C9142F886C@lucidvision.com>
From: Benoit Claise 
Message-ID: <567949B1.4040703@cisco.com>
Date: Tue, 22 Dec 2015 14:01:37 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <1DEB4607-3DB9-450C-884C-E0C9142F886C@lucidvision.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 13:01:43 -0000

On 12/22/2015 1:55 PM, Nadeau Thomas wrote:
>> On Dec 22, 2015:6:38 AM, at 6:38 AM, Benoit Claise  wrote:
>>
>> Jürgen,
>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>>>
>>>> I hope that nobody disagrees that the operational state design and how
>>>> to structure the models are the two blocking factors to publish YANG
>>>> models. If you disagree or don't see this, let me know, I should
>>>> communicate better.
>>> Even if it may spoil your day, I disagree that there is a blocking
>>> factor that should stop us from publishing models.
>> Interestingly, I received that feedback again recently, this time from the OSPF and ISIS YANG model authors.
> 	This is a blocking factor that people are not considering: The RFC process the
> IETF has in place is not suitable for rapid/modern/canonical model development.  It will
> be difficult for the IESG review process to scale to even a couple models during any given
> telechat period given the state of the document review/approval process. How do we
> envision the IESG reviewing 250+ models (and growing)?  Besides the initial RFC version,
> rapid refresh/update of models has the same issues.
I don't disagree, but I propose that we stick to the oper state 
discussion in this email thread.

Regards, Benoit


From nobody Tue Dec 22 05:06:19 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17081A8935 for ; Tue, 22 Dec 2015 05:06:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 ISb7NW1WKNbj for ; Tue, 22 Dec 2015 05:06:15 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 9E69A1A8930 for ; Tue, 22 Dec 2015 05:06:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450789539; bh=gns2tXXXkN6YAkmGj3ozuR4O4t8T2wLYKhrt3uhu830=; h=From:Subject:Date:To; b=1d+FuBcwv2pLZYtqndgocwkFiJSJp2h9fL5dtiIJIkqjVUX1EndXubh0Ju0U/3b+b SW1t0jfu0oDpZmyk2rdGOLzPKi4ZUV5o2UR/Q2xzjwQ6dkJf3H04jW9zkWVD5ocpet ctUgXt8TvuPaZgLrSbftzqwXklJ8GhdJzykCKKis=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
From: Nadeau Thomas 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: 
Date: Tue, 22 Dec 2015 08:06:09 -0500
To: NETMOD WG 
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=2 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 221, in=2940, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Subject: [netmod] New Thread: IESG Review Process for Yang Models at the IETF
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 13:06:17 -0000

[moving the thread to its own discussion.]

> 	This is a blocking factor that people are not considering: The =
RFC process the
> IETF has in place is not suitable for rapid/modern/canonical model =
development.  It will
> be difficult for the IESG review process to scale to even a couple =
models during any given
> telechat period given the state of the document review/approval =
process. How do we
> envision the IESG reviewing 250+ models (and growing)?  Besides the =
initial RFC version,
> rapid refresh/update of models has the same issues.

I don't disagree, but I propose that we stick to the oper state =
discussion in this email thread.

Regards, Benoit



From nobody Tue Dec 22 05:07:23 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628991A1A13 for ; Tue, 22 Dec 2015 05:07:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 btGPtrW48b9r for ; Tue, 22 Dec 2015 05:07:20 -0800 (PST)
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 A41B91A1A10 for ; Tue, 22 Dec 2015 05:07:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4676; q=dns/txt; s=iport; t=1450789640; x=1451999240; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=slpIRUaVBA43HAX8TJbO+bCMuX0hWTtEXNKHbAoQVNg=; b=N1Ksjt/nmuazWxSrM4vv/DqUfjbtqbOSLFYuVz8ImgJKHlzNARQ+ThpH V8N9wdHPeDtA1iQN8DkKUWmMmA1JiLe/SYomOYDZl2SW1q/AK4aEC8o3u yZrZKFL5z8kC2v8Ccc25WQLmY5kz+NighTShnd0Y99IP2l+oeRqzzISGc k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvAgDMSnlW/4UNJK1egzpSbQaMS7EnA?= =?us-ascii?q?Q2BYxcKhSJKAhyBDTgUAQEBAQEBAYEKhDUBAQQBAQEgERMnCxACAQgYAgImAgI?= =?us-ascii?q?CJQsVEAIEDgUbiBQOrQCFGo0VAQEBAQEBAQEBAQEBAQEBAQEBAQEBFASBAYlNg?= =?us-ascii?q?QaEWYMegUoFlwABhTuIEIFchEWIWopDg3MBIAEBQoIRHYFWcoN6gQgBAQE?=
X-IronPort-AV: E=Sophos;i="5.20,464,1444694400"; d="scan'208";a="57820483"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Dec 2015 13:07:11 +0000
Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id tBMD785A013324 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Dec 2015 13:07:09 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 22 Dec 2015 08:07:08 -0500
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.1104.009; Tue, 22 Dec 2015 08:07:08 -0500
From: "Acee Lindem (acee)" 
To: Ladislav Lhotka 
Thread-Topic: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
Thread-Index: AQHROST+Qi5eUPyFCUOmbJF1PR1M/Z7Q8W4AgACOLQCAAASngIAEjK+AgAAEHICAASbmAIAAAh6A//+xC4CAAFoOAP//t9oA
Date: Tue, 22 Dec 2015 13:07:07 +0000
Message-ID: 
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>  <56783B45.1020505@cisco.com> <20151221180231.GC43694@elstar.local> <56793618.3080403@cisco.com> <003272D4-EB32-47DE-A105-DDB894F9D8C7@nic.cz>  <5C282DDE-8D85-4507-92D9-1DEA0A782E17@nic.cz>
In-Reply-To: <5C282DDE-8D85-4507-92D9-1DEA0A782E17@nic.cz>
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.199]
Content-Type: text/plain; charset="utf-8"
Content-ID: <30293832D8276842B3C2BF60259E72C9@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 13:07:22 -0000

SGkgTGFkYSwNCg0KT24gMTIvMjIvMTUsIDc6MjUgQU0sICJMYWRpc2xhdiBMaG90a2EiIDxsaG90
a2FAbmljLmN6PiB3cm90ZToNCg0KPkhpIEFjZWUsDQo+DQo+PiBPbiAyMiBEZWMgMjAxNSwgYXQg
MTM6MDMsIEFjZWUgTGluZGVtIChhY2VlKSA8YWNlZUBjaXNjby5jb20+IHdyb3RlOg0KPj4gDQo+
PiBKdXJnZW4sIExhZGEsIA0KPj4gDQo+PiBPbiAxMi8yMi8xNSwgNjo0NSBBTSwgIm5ldG1vZCBv
biBiZWhhbGYgb2YgTGFkaXNsYXYgTGhvdGthIg0KPj4gPG5ldG1vZC1ib3VuY2VzQGlldGYub3Jn
IG9uIGJlaGFsZiBvZiBsaG90a2FAbmljLmN6PiB3cm90ZToNCj4+IA0KPj4+IA0KPj4+PiBPbiAy
MiBEZWMgMjAxNSwgYXQgMTI6MzgsIEJlbm9pdCBDbGFpc2UgPGJjbGFpc2VAY2lzY28uY29tPiB3
cm90ZToNCj4+Pj4gDQo+Pj4+IErDvHJnZW4sDQo+Pj4+PiBPbiBNb24sIERlYyAyMSwgMjAxNSBh
dCAwNjo0Nzo0OVBNICswMTAwLCBCZW5vaXQgQ2xhaXNlIHdyb3RlOg0KPj4+Pj4gDQo+Pj4+Pj4g
SSBob3BlIHRoYXQgbm9ib2R5IGRpc2FncmVlcyB0aGF0IHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBk
ZXNpZ24gYW5kDQo+Pj4+Pj5ob3cNCj4+Pj4+PiB0byBzdHJ1Y3R1cmUgdGhlIG1vZGVscyBhcmUg
dGhlIHR3byBibG9ja2luZyBmYWN0b3JzIHRvIHB1Ymxpc2ggWUFORw0KPj4+Pj4+IG1vZGVscy4g
SWYgeW91IGRpc2FncmVlIG9yIGRvbid0IHNlZSB0aGlzLCBsZXQgbWUga25vdywgSSBzaG91bGQN
Cj4+Pj4+PiBjb21tdW5pY2F0ZSBiZXR0ZXIuDQo+Pj4+PiBFdmVuIGlmIGl0IG1heSBzcG9pbCB5
b3VyIGRheSwgSSBkaXNhZ3JlZSB0aGF0IHRoZXJlIGlzIGEgYmxvY2tpbmcNCj4+Pj4+IGZhY3Rv
ciB0aGF0IHNob3VsZCBzdG9wIHVzIGZyb20gcHVibGlzaGluZyBtb2RlbHMuDQo+Pj4+IEludGVy
ZXN0aW5nbHksIEkgcmVjZWl2ZWQgdGhhdCBmZWVkYmFjayBhZ2FpbiByZWNlbnRseSwgdGhpcyB0
aW1lIGZyb20NCj4+Pj4gdGhlIE9TUEYgYW5kIElTSVMgWUFORyBtb2RlbCBhdXRob3JzLg0KPj4+
IA0KPj4+IERpZCB0aGV5IG1lbnRpb24gYW55IHJlYXNvbiAqd2h5KiBpdCBpcyBhIGJsb2NraW5n
IGZhY3RvciBmb3IgdGhlaXINCj4+PiBtb2R1bGVzPw0KPj4gDQo+PiBUaGlzIHNob3VsZCBiZSBv
YnZpb3VzIC0gdGhlIE9TUEYgYW5kIElTLUlTIFdHIGFyZSBub3QgZ29pbmcgdG8gcHVibGlzaA0K
Pj4gWUFORyBtb2RlbHMgdGhhdCBkb27igJl0IG1lZXQgdGhlIG9wcy1zdGF0ZSByZXF1aXJlbWVu
dHMuIFdoeSB3b3VsZCB3ZQ0KPg0KPkNhbiB5b3UgcGxlYXNlIGV4cGxhaW4gd2hhdCBzcGVjaWZp
YyBvcHMtc3RhdGUgcmVxdWlyZW1lbnRzIGFyZW4ndCBtZXQgaW4NCj50aG9zZSBtb2R1bGVzPyBJ
IGFtIGludGVyZXN0ZWQgYmVjYXVzZSB0aGUgc2FtZSBwcm9ibGVtIG1heSBwb3NzaWJseSBiZQ0K
PnByZXNlbnQgaW4gb3VyIGlldGYtcm91dGluZyBtb2R1bGUuDQoNClRoYXTigJlzIGVhc3kgLSB0
aGUgcmVxdWlyZW1lbnRzIGFzIHN0YXRlZCBpbg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y
Zy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2Qtb3BzdGF0ZS1yZXFzLw0KDQpXZSBjb3VsZCBnbyBiYWNr
IGFuZCByZW9yZ2FuaXplIHRoZSBJR1AgbW9kZWxzIGFuZCBhZGQgc2VwYXJhdGUgbGVhdmVzIGZv
cg0KaW50ZW5kZWQgYW5kIGFwcGxpZWQgY29uZmlnIGFuZCBtZWV0IHRoZXNlIHJlcXVpcmVtZW50
cy4gSG93ZXZlciwgaWYgd2UNCmNvbmNsdWRlIG9uIGEgbW9yZSBlbGVnYW50IHNvbHV0aW9uLCBp
dCB3b3VsZCBiZSBncmVhdCB0byBhdmFpbCBvdXJzZWx2ZXMNCnRvIHRoYXQgc29sdXRpb24uIA0K
DQpUaGFua3MsDQpBY2VlIA0KDQoNCg0KPg0KPlRoYW5rcywgTGFkYQ0KPg0KPj4gcHVibGlzaCBz
dGFuZGFyZHMgdGhhdCBkb27igJl0IG1lZXQgdGhlIHJlcXVpcmVtZW50cyBhbmQgYXJlLA0KPj5j
b25zZXF1ZW50bHksDQo+PiBpcnJlbGV2YW50PyBGYWlsdXJlIHRvIHJlY29nbml6ZSB0aGlzIGlz
IGEgcmVhbCBibG9ja2luZyBpc3N1ZS4NCj4+IA0KPj4gQWNlZQ0KPj4gDQo+PiANCj4+IA0KPj4g
DQo+Pj4gDQo+Pj4gVGhhbmtzLCBMYWRhDQo+Pj4gDQo+Pj4+PiBUaGVyZSBzZWVtIHRvIGJlDQo+
Pj4+PiB3YXlzIHRvIGFkZHJlc3MgdGhlIHJlcXVpcmVtZW50cyB3aXRob3V0IGhhdmluZyB0byBi
bG9jayBhbGwgd29yayBvcg0KPj4+Pj4gdG8gcmVkbyB3aGF0IHRoYXQgd2UgaGF2ZSBwdWJsaXNo
ZWQuDQo+Pj4+IFRoYXQncyBteSBob3BlIHRvby4NCj4+Pj4+IEJ1dCBzdXJlLCBpZiB5b3UgbWFr
ZSBpdCBhDQo+Pj4+PiBibG9ja2luZyBmYWN0b3IsIGl0IHdpbGwgYmUgb25lLg0KPj4+PiBJJ2xs
IGNob3NlIHRvIGlnbm9yZSB0aGlzIGxhc3Qgc2VudGVuY2UuDQo+Pj4+IA0KPj4+PiBSZWdhcmRz
LCBCZW5vaXQNCj4+Pj4+IA0KPj4+Pj4+IEkgaG9wZSB0aGF0IG5vYm9keSByZWFsbHkgYmVsaWV2
ZXMgdGhhdCBiZWNhdXNlIHNvbWUgcGVvcGxlIGluIElFVEYNCj4+Pj4+PiAob3INCj4+Pj4+PiBp
biBhbnkgb3RoZXIgU0RPcykgdGhpbmtzIHRoYXQgd2hhdCB0aG9zZSBvcGVyYXRvcnMgd2FudCBp
cyBhIGJhZA0KPj4+Pj4+IGlkZWEsDQo+Pj4+Pj4gdGhvc2Ugb3BlcmF0b3JzIHdpbGwgbm90IGdl
dCB3aGF0IHRoZXkgcmVxdWVzdC9wYXkgZm9yIGZyb20gdGhlaXINCj4+Pj4+PiBzdXBwbGllcnMu
DQo+Pj4+PiBUbyBiZSBmYWlyLCB0aG9zZSBvcGVyYXRvcnMgYWxzbyB0ZWxsIHVzIHRoYXQgdGhl
eSB1c2UgcHJvdG9jb2xzIHRoYXQNCj4+Pj4+IGFyZSBub3QgSUVURiBwcm90b2NvbHMgYW5kIGl0
IHJlbWFpbnMgc29tZXdoYXQgdW5jbGVhciB3aGF0IHRob3NlDQo+Pj4+PiBwcm90b2NvbHMgYXJl
IHdlIGFyZSBleHBlY3RlZCB0byBvcHRpbWl6ZSBkYXRhIG1vZGVsIHNvbHV0aW9ucyBmb3IuDQo+
Pj4+PiANCj4+Pj4+IC9qcw0KPj4+Pj4gDQo+Pj4+IA0KPj4+PiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+
Pj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL25ldG1vZA0KPj4+IA0KPj4+IC0tDQo+Pj4gTGFkaXNsYXYgTGhvdGthLCBDWi5OSUMg
TGFicw0KPj4+IFBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+
Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBu
ZXRtb2QgbWFpbGluZyBsaXN0DQo+Pj4gbmV0bW9kQGlldGYub3JnDQo+Pj4gaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4NCj4tLQ0KPkxhZGlzbGF2IExob3Rr
YSwgQ1ouTklDIExhYnMNCj5QR1AgS2V5IElEOiBFNzRFOEMwQw0KPg0KPg0KPg0KPg0KDQo=


From nobody Tue Dec 22 05:24:30 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC8931A19E9 for ; Tue, 22 Dec 2015 05:24:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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 9xH1rdai0evz for ; Tue, 22 Dec 2015 05:24:26 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F34C1A893B for ; Tue, 22 Dec 2015 05:24:26 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:a0d6:b6d3:7f79:6a7] (unknown [IPv6:2001:718:1a02:1:a0d6:b6d3:7f79:6a7]) by mail.nic.cz (Postfix) with ESMTPSA id 398EC1813C6; Tue, 22 Dec 2015 14:24:25 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450790665; bh=xWkUp+Gzad/x6FZQkIIzLjly6rLFWFZ8Z85mmUCMmTo=; h=From:Date:To; b=mroPjKtQeziggmfnpvXIoP83WVE1Ak9JaRmQDXzCJKYnBIlWswjKlI5N1BALWfDOH jZJ698moUUCATFAy5GC3yk3LymxxotBmvwEbpgrD/f2sGsQNZ+xHurFH23h7Jv20Y9 VBlmWlZVI4iwyxb/yiqctAFOlG0GbcCqqbEMm8+U=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Tue, 22 Dec 2015 14:24:26 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>  <56783B45.1020505@cisco.com> <20151221180231.GC43694@elstar.local> <56793618.3080403@cisco.com> <003272D4-EB32-47DE-A105-DDB894F9D8C7@nic.cz>  <5C282DDE-8D85-4507-92D9-1DEA0A782E17@nic.cz> 
To: "Acee Lindem (acee)" 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 13:24:29 -0000

> On 22 Dec 2015, at 14:07, Acee Lindem (acee)  wrote:
>=20
> Hi Lada,
>=20
> On 12/22/15, 7:25 AM, "Ladislav Lhotka"  wrote:
>=20
>> Hi Acee,
>>=20
>>> On 22 Dec 2015, at 13:03, Acee Lindem (acee)  wrote:
>>>=20
>>> Jurgen, Lada,=20
>>>=20
>>> On 12/22/15, 6:45 AM, "netmod on behalf of Ladislav Lhotka"
>>>  wrote:
>>>=20
>>>>=20
>>>>> On 22 Dec 2015, at 12:38, Benoit Claise  wrote:
>>>>>=20
>>>>> J=C3=BCrgen,
>>>>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>>>>>>=20
>>>>>>> I hope that nobody disagrees that the operational state design =
and
>>>>>>> how
>>>>>>> to structure the models are the two blocking factors to publish =
YANG
>>>>>>> models. If you disagree or don't see this, let me know, I should
>>>>>>> communicate better.
>>>>>> Even if it may spoil your day, I disagree that there is a =
blocking
>>>>>> factor that should stop us from publishing models.
>>>>> Interestingly, I received that feedback again recently, this time =
from
>>>>> the OSPF and ISIS YANG model authors.
>>>>=20
>>>> Did they mention any reason *why* it is a blocking factor for their
>>>> modules?
>>>=20
>>> This should be obvious - the OSPF and IS-IS WG are not going to =
publish
>>> YANG models that don=E2=80=99t meet the ops-state requirements. Why =
would we
>>=20
>> Can you please explain what specific ops-state requirements aren't =
met in
>> those modules? I am interested because the same problem may possibly =
be
>> present in our ietf-routing module.
>=20
> That=E2=80=99s easy - the requirements as stated in
> https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/
>=20
> We could go back and reorganize the IGP models and add separate leaves =
for
> intended and applied config and meet these requirements. However, if =
we

OK, so you probably already have a solution for implementing intended =
and applied configuration. In my view, since intended and applied =
configuration have identical schemas (Requirement 1C), there is no =
reason for repeating any leaves in the data model.

> conclude on a more elegant solution, it would be great to avail =
ourselves
> to that solution.

I don't know whether it is more elegant but certainly a possible =
solution is to have a separate datastore for applied configuration and =
use the same data model (config true part) for both intended and applied =
configuration.

Lada

>=20
> Thanks,
> Acee=20
>=20
>=20
>=20
>>=20
>> Thanks, Lada
>>=20
>>> publish standards that don=E2=80=99t meet the requirements and are,
>>> consequently,
>>> irrelevant? Failure to recognize this is a real blocking issue.
>>>=20
>>> Acee
>>>=20
>>>=20
>>>=20
>>>=20
>>>>=20
>>>> Thanks, Lada
>>>>=20
>>>>>> There seem to be
>>>>>> ways to address the requirements without having to block all work =
or
>>>>>> to redo what that we have published.
>>>>> That's my hope too.
>>>>>> But sure, if you make it a
>>>>>> blocking factor, it will be one.
>>>>> I'll chose to ignore this last sentence.
>>>>>=20
>>>>> Regards, Benoit
>>>>>>=20
>>>>>>> I hope that nobody really believes that because some people in =
IETF
>>>>>>> (or
>>>>>>> in any other SDOs) thinks that what those operators want is a =
bad
>>>>>>> idea,
>>>>>>> those operators will not get what they request/pay for from =
their
>>>>>>> suppliers.
>>>>>> To be fair, those operators also tell us that they use protocols =
that
>>>>>> are not IETF protocols and it remains somewhat unclear what those
>>>>>> protocols are we are expected to optimize data model solutions =
for.
>>>>>>=20
>>>>>> /js
>>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>=20
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Tue Dec 22 05:39:23 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF9761A026C for ; Tue, 22 Dec 2015 05:39:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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 Evi-wQOPYyZu for ; Tue, 22 Dec 2015 05:39:17 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE9721A0262 for ; Tue, 22 Dec 2015 05:39:16 -0800 (PST)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 27854181839; Tue, 22 Dec 2015 14:39:15 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450791555; bh=hflW872l/g92CoFbjFbXUi5SktlGs/yzhlr7v7Z55sw=; h=From:Date:To; b=FzsU4DA9A/sdllZLFHZV2bwGuJoIfzJDF3bF27F7Mig2cU02qx6p0I2IpIV2YU3/G NYs4KeuOG6ONFckLIdllx8F2sZnyPjsHpSazm+gz8B2WzNxUIzB5iFAA9gz0xvh9o7 03WpCbkw34VmruGtgv3GGpuSitsGy1rJsPbP54y8=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Tue, 22 Dec 2015 14:39:16 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <0E480747-91EE-46B7-9AF7-E3886600935D@nic.cz>
References: 
To: Thomas Nadeau 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] New Thread: IESG Review Process for Yang Models at the IETF
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 13:39:18 -0000

> On 22 Dec 2015, at 14:06, Nadeau Thomas  =
wrote:
>=20
>=20
> [moving the thread to its own discussion.]
>=20
>> 	This is a blocking factor that people are not considering: The =
RFC process the
>> IETF has in place is not suitable for rapid/modern/canonical model =
development.  It will
>> be difficult for the IESG review process to scale to even a couple =
models during any given
>> telechat period given the state of the document review/approval =
process. How do we
>> envision the IESG reviewing 250+ models (and growing)?  Besides the =
initial RFC version,
>> rapid refresh/update of models has the same issues.
>=20
> I don't disagree, but I propose that we stick to the oper state =
discussion in this email thread.

I agree with Tom. I personally decided not to work on any new module in =
the IETF any time soon. I am currently working on a number of modules =
related to DNS, they will be freely available for review and use by =
everybody, but I don't want to go through a similar process as with =
ietf-routing, and then be stymied by the update rules.

Lada

>=20
> Regards, Benoit
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Tue Dec 22 07:07:06 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE8E1A1A38 for ; Tue, 22 Dec 2015 07:07:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 FHVOLnvAP9bq for ; Tue, 22 Dec 2015 07:07:03 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD771A1A36 for ; Tue, 22 Dec 2015 07:07:03 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0B0696DE; Tue, 22 Dec 2015 16:07:02 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id QOiTe6jR81t5; Tue, 22 Dec 2015 16:07:01 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 22 Dec 2015 16:07:01 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2D33020056; Tue, 22 Dec 2015 16:07:01 +0100 (CET)
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 S_lsToWWhlxb; Tue, 22 Dec 2015 16:07:00 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D199820055; Tue, 22 Dec 2015 16:06:59 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 1F09D3960724; Tue, 22 Dec 2015 16:06:57 +0100 (CET)
Date: Tue, 22 Dec 2015 16:06:56 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20151222150654.GA45756@elstar.local>
Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org
References: <1033983.1450551979726.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>  <20151221144723.GA43211@elstar.local> <5E9674F3-DDAB-479F-A8CA-0CF78FE5F1F2@nic.cz> <20151221154054.GB43316@elstar.local> <82E7F91B-9DC4-4E8A-B042-A87B21683283@nic.cz> <20151221190439.GA44038@elstar.local>  <20151222100634.GB45259@elstar.local> <3DC4E3CB-9250-4A32-BD7A-8759CC027CC7@nic.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3DC4E3CB-9250-4A32-BD7A-8759CC027CC7@nic.cz>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 15:07:05 -0000

On Tue, Dec 22, 2015 at 11:34:41AM +0100, Ladislav Lhotka wrote:
> 
> > On 22 Dec 2015, at 11:06, Juergen Schoenwaelder  wrote:
> > 
> > On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka wrote:
> >> 
> >>> 
> >>> That's why the definition what 'published' means in the IETF is in the
> >>> guidelines document. On the other hand, since this is an IETF
> >>> document, I also do not find it problematic to define IETF rules
> >>> here. Others should be able to skip over this. There are really more
> >>> important problems to solve.
> >> 
> >> It is not clear at all from sec. 10 that data modellers outside IETF may skip over this. I am not even sure that everybody in this WG agrees with your interpretation.
> >> 
> > 
> > You are wrong.
> > 
> > - Section 10 in RFC 6020 applies to all published modules.
> 
> The bullets specifying the rules are introduced with this sentence:
> 
> 'A definition may be revised in any of the following ways:'
> 
> so IMO it is intended to apply to *all* modules. Are you saying that it actually means
> 
> 'A definition in a module published by IETF may be revised in any of the following ways:'?
>

A definition in a published module may be revised [...]

> > - The definition of what turns a module into a published module is
> >  specific to the different organizations publishing modules.
> 
> So it means that such an organization may also decide to ignore the rules entirely or replace them with its own rules.
>

No.

> If the WG can agree on this and make the corresponding changes in sec. 11 of 6020bis, then I have no more objections.

The rules are there to ensure interoperability. Interoperability is an
issue for published modules (but not for modules under development).
The IETF certainly has a history to care about interoperability. I
expect that other organizations care about interoperability as well.

/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 Dec 22 07:22:56 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDF61A1A4D for ; Tue, 22 Dec 2015 07:22:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 U89mODVIyGwI for ; Tue, 22 Dec 2015 07:22:52 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 E8C1E1A1A57 for ; Tue, 22 Dec 2015 07:22:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450797740; bh=q18uTOGr5mVpQI+/86U8aGah6BZHr/5pHUCj9JKj0KQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=bXLHZjCyN3SQVAnkeoh8Q8wul1Vkba0SdsYqRSMrgiFIrfP4im4TI7TBMAraL4VZL uVc/RKIelCfxQkS9e0xTCcvG0jbGRVFMak5COYpZVvaTQSGsW6FOceoDcDn6jaFGxC 1V+SfIfesvYz7NpybPL8ax6qHpcBtP2/yyQpe2cQ=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Nadeau Thomas 
In-Reply-To: <0E480747-91EE-46B7-9AF7-E3886600935D@nic.cz>
Date: Tue, 22 Dec 2015 10:22:49 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <0E480747-91EE-46B7-9AF7-E3886600935D@nic.cz>
To: Ladislav Lhotka 
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=5 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 221, in=2943, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] New Thread: IESG Review Process for Yang Models at the IETF
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 15:22:54 -0000

	The action I am trying to tease out of this thread is how do we =
take action
going forward? There are many who are saying (and doing) what you say =
below; however,
there are related discussions on the RFC6020 update to the module update =
rules
claiming that we should only focus on IETF-realted modules. Do you see =
the catch-22
I am trying to make clear here?   The other issue is the simple process =
for those modules
that are developed here. Should we move them all to an external model, =
should we=20
amend the IETF=E2=80=99s processes to accommodate rapid model =
development and iteration?

	=E2=80=94Tom


> On Dec 22, 2015:8:39 AM, at 8:39 AM, Ladislav Lhotka  =
wrote:
>=20
>=20
>> On 22 Dec 2015, at 14:06, Nadeau Thomas  =
wrote:
>>=20
>>=20
>> [moving the thread to its own discussion.]
>>=20
>>> 	This is a blocking factor that people are not considering: The =
RFC process the
>>> IETF has in place is not suitable for rapid/modern/canonical model =
development.  It will
>>> be difficult for the IESG review process to scale to even a couple =
models during any given
>>> telechat period given the state of the document review/approval =
process. How do we
>>> envision the IESG reviewing 250+ models (and growing)?  Besides the =
initial RFC version,
>>> rapid refresh/update of models has the same issues.
>>=20
>> I don't disagree, but I propose that we stick to the oper state =
discussion in this email thread.
>=20
> I agree with Tom. I personally decided not to work on any new module =
in the IETF any time soon. I am currently working on a number of modules =
related to DNS, they will be freely available for review and use by =
everybody, but I don't want to go through a similar process as with =
ietf-routing, and then be stymied by the update rules.
>=20
> Lada
>=20
>>=20
>> Regards, Benoit
>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20


From nobody Tue Dec 22 07:23:47 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F431A1A58 for ; Tue, 22 Dec 2015 07:23:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.361
X-Spam-Level: 
X-Spam-Status: No, score=-0.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] autolearn=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 XJwgMkU9poKZ for ; Tue, 22 Dec 2015 07:23:44 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EB5E1A1A56 for ; Tue, 22 Dec 2015 07:23:44 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:a0d6:b6d3:7f79:6a7] (unknown [IPv6:2001:718:1a02:1:a0d6:b6d3:7f79:6a7]) by mail.nic.cz (Postfix) with ESMTPSA id 16FD2180C26; Tue, 22 Dec 2015 16:23:43 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450797823; bh=KlLH/n5nPk+tykbwYf3jR4WA00i5TLe8RRxfkUbUbyE=; h=From:Date:To; b=LFzPppP3vLTK4XyKKtwsSfi6X3jc0+nNcq6VCdfxtmQ3mE2I6jdHzcbn1LlBZshOj 56D8CQLIB112CyfD0caHZkvI704KcVGZWRsdcRXE37QwvjSyTg2a268q65Xz7N4yN+ UpbVeIlxqbKW+OVsMv1NshGd2CrmJndJZI2/lDl0=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <20151222150654.GA45756@elstar.local>
Date: Tue, 22 Dec 2015 16:23:44 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <1033983.1450551979726.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>  <20151221144723.GA43211@elstar.local> <5E9674F3-DDAB-479F-A8CA-0CF78FE5F1F2@nic.cz> <20151221154054.GB43316@elstar.local> <82E7F91B-9DC4-4E8A-B042-A87B21683283@nic.cz> <20151221190439.GA44038@elstar.local>  <20151222100634.GB45259@elstar.local> <3DC4E3CB-9250-4A32-BD7A-8759CC027CC7@nic.cz> <20151222150654.GA45756@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 15:23:46 -0000

> On 22 Dec 2015, at 16:06, Juergen Schoenwaelder =
 wrote:
>=20
> On Tue, Dec 22, 2015 at 11:34:41AM +0100, Ladislav Lhotka wrote:
>>=20
>>> On 22 Dec 2015, at 11:06, Juergen Schoenwaelder =
 wrote:
>>>=20
>>> On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka wrote:
>>>>=20
>>>>>=20
>>>>> That's why the definition what 'published' means in the IETF is in =
the
>>>>> guidelines document. On the other hand, since this is an IETF
>>>>> document, I also do not find it problematic to define IETF rules
>>>>> here. Others should be able to skip over this. There are really =
more
>>>>> important problems to solve.
>>>>=20
>>>> It is not clear at all from sec. 10 that data modellers outside =
IETF may skip over this. I am not even sure that everybody in this WG =
agrees with your interpretation.
>>>>=20
>>>=20
>>> You are wrong.
>>>=20
>>> - Section 10 in RFC 6020 applies to all published modules.
>>=20
>> The bullets specifying the rules are introduced with this sentence:
>>=20
>> 'A definition may be revised in any of the following ways:'
>>=20
>> so IMO it is intended to apply to *all* modules. Are you saying that =
it actually means
>>=20
>> 'A definition in a module published by IETF may be revised in any of =
the following ways:'?
>>=20
>=20
> A definition in a published module may be revised [...]
>=20
>>> - The definition of what turns a module into a published module is
>>> specific to the different organizations publishing modules.
>>=20
>> So it means that such an organization may also decide to ignore the =
rules entirely or replace them with its own rules.
>>=20
>=20
> No.
>=20
>> If the WG can agree on this and make the corresponding changes in =
sec. 11 of 6020bis, then I have no more objections.
>=20
> The rules are there to ensure interoperability. Interoperability is an
> issue for published modules (but not for modules under development).

This doesn't make much sense unless you give an objective definition of =
"published". For example, are proprietary modules (developed by vendors) =
ever published?

> The IETF certainly has a history to care about interoperability. I
> expect that other organizations care about interoperability as well.

That's their business.

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Tue Dec 22 07:24:47 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026411A1A5F for ; Tue, 22 Dec 2015 07:24:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 RR-76ZuseYml for ; Tue, 22 Dec 2015 07:24:45 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 0154B1A1A60 for ; Tue, 22 Dec 2015 07:24:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450797852; bh=oZ8wCbfyuliJyWVLwpFkuMzLWoJtyKFyID2orBWaFVQ=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=HAIR1KM48PotN5t25S7ENiyXHhwDoG0qrV8A6R9bjEzPc6SfFinchi/vRYrJD4kM1 Zh3Ko0U9k7++88p1S7DHdVsY9XKHSPJSmW+VKoSIpk8QqFdjxEkfiKyxM0bAe+/eXb ghnSVueEo98PED4VhgDz4ONY54iVuPLMw4IjBHT8=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Nadeau Thomas 
In-Reply-To: 
Date: Tue, 22 Dec 2015 10:24:41 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <0079F052-231E-4DB0-9333-6B730328190E@lucidvision.com>
References: <1033983.1450551979726.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>  <20151221144723.GA43211@elstar.local> <5E9674F3-DDAB-479F-A8CA-0CF78FE5F1F2@nic.cz> <20151221154054.GB43316@elstar.local> <82E7F91B-9DC4-4E8A-B042-A87B21683283@nic.cz> <20151221190439.GA44038@elstar.local>  <20151222100634.GB45259@elstar.local> <3DC4E3CB-9250-4A32-BD7A-8759CC027CC7@nic.cz> <20151222150654.GA45756@elstar.local> 
To: Ladislav Lhotka 
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=6 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 221, in=2944, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 15:24:47 -0000

> On Dec 22, 2015:10:23 AM, at 10:23 AM, Ladislav Lhotka  =
wrote:
>=20
>=20
>> On 22 Dec 2015, at 16:06, Juergen Schoenwaelder =
 wrote:
>>=20
>> On Tue, Dec 22, 2015 at 11:34:41AM +0100, Ladislav Lhotka wrote:
>>>=20
>>>> On 22 Dec 2015, at 11:06, Juergen Schoenwaelder =
 wrote:
>>>>=20
>>>> On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka wrote:
>>>>>=20
>>>>>>=20
>>>>>> That's why the definition what 'published' means in the IETF is =
in the
>>>>>> guidelines document. On the other hand, since this is an IETF
>>>>>> document, I also do not find it problematic to define IETF rules
>>>>>> here. Others should be able to skip over this. There are really =
more
>>>>>> important problems to solve.
>>>>>=20
>>>>> It is not clear at all from sec. 10 that data modellers outside =
IETF may skip over this. I am not even sure that everybody in this WG =
agrees with your interpretation.
>>>>>=20
>>>>=20
>>>> You are wrong.
>>>>=20
>>>> - Section 10 in RFC 6020 applies to all published modules.
>>>=20
>>> The bullets specifying the rules are introduced with this sentence:
>>>=20
>>> 'A definition may be revised in any of the following ways:'
>>>=20
>>> so IMO it is intended to apply to *all* modules. Are you saying that =
it actually means
>>>=20
>>> 'A definition in a module published by IETF may be revised in any of =
the following ways:'?
>>>=20
>>=20
>> A definition in a published module may be revised [...]
>>=20
>>>> - The definition of what turns a module into a published module is
>>>> specific to the different organizations publishing modules.
>>>=20
>>> So it means that such an organization may also decide to ignore the =
rules entirely or replace them with its own rules.
>>>=20
>>=20
>> No.
>>=20
>>> If the WG can agree on this and make the corresponding changes in =
sec. 11 of 6020bis, then I have no more objections.
>>=20
>> The rules are there to ensure interoperability. Interoperability is =
an
>> issue for published modules (but not for modules under development).
>=20
> This doesn't make much sense unless you give an objective definition =
of "published". For example, are proprietary modules (developed by =
vendors) ever published?

	And that is the point I made the other day. Simply saying that =
definition is The IETF=E2=80=99s
definition forms a rather circular argument.

	=E2=80=94Tom


>=20
>> The IETF certainly has a history to care about interoperability. I
>> expect that other organizations care about interoperability as well.
>=20
> That's their business.
>=20
> Lada
>=20
>>=20
>> /js
>>=20
>> --=20
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | =
Germany
>> Fax:   +49 421 200 3103         
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Dec 22 07:36:40 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2361A1A82 for ; Tue, 22 Dec 2015 07:36:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 vLPbLk-oM2bZ for ; Tue, 22 Dec 2015 07:36:38 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ABF71A1A7E for ; Tue, 22 Dec 2015 07:36:38 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:a0d6:b6d3:7f79:6a7] (unknown [IPv6:2001:718:1a02:1:a0d6:b6d3:7f79:6a7]) by mail.nic.cz (Postfix) with ESMTPSA id 8CEC1181388; Tue, 22 Dec 2015 16:36:36 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450798596; bh=xLAR7JS0y3rTvbkRhgRrlry8+BonMD71UCUpnqSNAgU=; h=From:Date:To; b=tvN66NuxU18sEkV8Yc21E6kP5kq/q1Xm0RlCXaisxHNjReIQp+XUGMFGj2Wd5GO5I CCDrV5INlPKuwgTzuKNquC1/SVPbwuK8fuCRA5r8Ev80woaN2FcIZEcYTGZc54mhtS Bs1qb2ZcXB/FIy8PLtIsQTYHEzoWEwx2p2HmHESQ=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Tue, 22 Dec 2015 16:36:37 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <019FCEF5-780B-43B1-B112-F5DC729A6918@nic.cz>
References:  <0E480747-91EE-46B7-9AF7-E3886600935D@nic.cz> 
To: Thomas Nadeau 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] New Thread: IESG Review Process for Yang Models at the IETF
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 15:36:39 -0000

> On 22 Dec 2015, at 16:22, Nadeau Thomas  =
wrote:
>=20
>=20
> 	The action I am trying to tease out of this thread is how do we =
take action
> going forward? There are many who are saying (and doing) what you say =
below; however,

This should IMO be OK. One thing that might help avoid unnecessary =
duplication of work is to keep and up-to-date directory, where everybody =
could register their modules. Everything else could be a bottom-up =
process.

Lada

> there are related discussions on the RFC6020 update to the module =
update rules
> claiming that we should only focus on IETF-realted modules. Do you see =
the catch-22
> I am trying to make clear here?   The other issue is the simple =
process for those modules
> that are developed here. Should we move them all to an external model, =
should we=20
> amend the IETF=E2=80=99s processes to accommodate rapid model =
development and iteration?
>=20
> 	=E2=80=94Tom
>=20
>=20
>> On Dec 22, 2015:8:39 AM, at 8:39 AM, Ladislav Lhotka  =
wrote:
>>=20
>>=20
>>> On 22 Dec 2015, at 14:06, Nadeau Thomas  =
wrote:
>>>=20
>>>=20
>>> [moving the thread to its own discussion.]
>>>=20
>>>> 	This is a blocking factor that people are not considering: The =
RFC process the
>>>> IETF has in place is not suitable for rapid/modern/canonical model =
development.  It will
>>>> be difficult for the IESG review process to scale to even a couple =
models during any given
>>>> telechat period given the state of the document review/approval =
process. How do we
>>>> envision the IESG reviewing 250+ models (and growing)?  Besides the =
initial RFC version,
>>>> rapid refresh/update of models has the same issues.
>>>=20
>>> I don't disagree, but I propose that we stick to the oper state =
discussion in this email thread.
>>=20
>> I agree with Tom. I personally decided not to work on any new module =
in the IETF any time soon. I am currently working on a number of modules =
related to DNS, they will be freely available for review and use by =
everybody, but I don't want to go through a similar process as with =
ietf-routing, and then be stymied by the update rules.
>>=20
>> Lada
>>=20
>>>=20
>>> Regards, Benoit
>>>=20
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>=20

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Tue Dec 22 07:43:49 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FE71A1A9B for ; Tue, 22 Dec 2015 07:43:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 KZWqgZDlL1Mm for ; Tue, 22 Dec 2015 07:43:46 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 6CCBB1A1A93 for ; Tue, 22 Dec 2015 07:43:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450798993; bh=VOHoCJDjkjifSY3llDA1lVykfrRCXhJ2T7pJXBRePF4=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=YEllCZ4Niex3ZujPis2KPOBqqEBQmjUkN6wBt7JVKgfFGOsNzaAa4gEJLBh/959zQ ZHzzupVX7WjyJJwsqOfbqhfbYBsDTH2EQo9cJt+fV0In2/kd61tzzacRT8nFuoICXs xf3G4kwmzvngeUbmPtBQYteRdle3N+TjjHisTNvI=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Nadeau Thomas 
In-Reply-To: <019FCEF5-780B-43B1-B112-F5DC729A6918@nic.cz>
Date: Tue, 22 Dec 2015 10:43:43 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <0E480747-91EE-46B7-9AF7-E3886600935D@nic.cz>  <019FCEF5-780B-43B1-B112-F5DC729A6918@nic.cz>
To: Ladislav Lhotka 
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=7 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 221, in=2945, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] New Thread: IESG Review Process for Yang Models at the IETF
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 15:43:48 -0000

> On Dec 22, 2015:10:36 AM, at 10:36 AM, Ladislav Lhotka  =
wrote:
>=20
>=20
>> On 22 Dec 2015, at 16:22, Nadeau Thomas  =
wrote:
>>=20
>>=20
>> 	The action I am trying to tease out of this thread is how do we =
take action
>> going forward? There are many who are saying (and doing) what you say =
below; however,
>=20
> This should IMO be OK. One thing that might help avoid unnecessary =
duplication of work is to keep and up-to-date directory, where everybody =
could register their modules. Everything else could be a bottom-up =
process.
>=20
> Lada

	That has been discussed on a separate thread.  I think the best =
idea right now is to
do something in IANA for a module namespace/ID registry but Benoit has =
asked us to write
up a draft with some ideas.

	=E2=80=94Tom


>=20
>> there are related discussions on the RFC6020 update to the module =
update rules
>> claiming that we should only focus on IETF-realted modules. Do you =
see the catch-22
>> I am trying to make clear here?   The other issue is the simple =
process for those modules
>> that are developed here. Should we move them all to an external =
model, should we=20
>> amend the IETF=E2=80=99s processes to accommodate rapid model =
development and iteration?
>>=20
>> 	=E2=80=94Tom
>>=20
>>=20
>>> On Dec 22, 2015:8:39 AM, at 8:39 AM, Ladislav Lhotka  =
wrote:
>>>=20
>>>=20
>>>> On 22 Dec 2015, at 14:06, Nadeau Thomas  =
wrote:
>>>>=20
>>>>=20
>>>> [moving the thread to its own discussion.]
>>>>=20
>>>>> 	This is a blocking factor that people are not considering: The =
RFC process the
>>>>> IETF has in place is not suitable for rapid/modern/canonical model =
development.  It will
>>>>> be difficult for the IESG review process to scale to even a couple =
models during any given
>>>>> telechat period given the state of the document review/approval =
process. How do we
>>>>> envision the IESG reviewing 250+ models (and growing)?  Besides =
the initial RFC version,
>>>>> rapid refresh/update of models has the same issues.
>>>>=20
>>>> I don't disagree, but I propose that we stick to the oper state =
discussion in this email thread.
>>>=20
>>> I agree with Tom. I personally decided not to work on any new module =
in the IETF any time soon. I am currently working on a number of modules =
related to DNS, they will be freely available for review and use by =
everybody, but I don't want to go through a similar process as with =
ietf-routing, and then be stymied by the update rules.
>>>=20
>>> Lada
>>>=20
>>>>=20
>>>> Regards, Benoit
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>=20
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>=20
>>>=20
>>>=20
>>>=20
>>=20
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20
>=20
>=20
>=20


From nobody Tue Dec 22 07:49:49 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 563771A1A99 for ; Tue, 22 Dec 2015 07:49:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 Ab8zGMllDw54 for ; Tue, 22 Dec 2015 07:49:46 -0800 (PST)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 AA0D91A1A97 for ; Tue, 22 Dec 2015 07:49:45 -0800 (PST)
Received: by mail-lf0-x22b.google.com with SMTP id l133so131234080lfd.2 for ; Tue, 22 Dec 2015 07:49:45 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=5zsRQ49lzxymcrluxm6njgwK4r8IAoVL8YAuQsKNeiE=; b=Km7Z8H4oXiG3HWPZMOrN6SMQI3FyUGhsuwCWxy5O2ZkKkP8RE55+Ckx2CaQZ6uYiD6 gpWWqvSbXIoFRn2Kr3wlmwvzNU/h9A1nO+OYwU2rBw8xBGsiziol0X7dFnm0XrlDoBU/ k1I/+VjtzKtyX0+pbx0EuEQgPjFKuQAW2/UDZ7oa057EP4srjxCSFbhGTONqdmjnnte0 B4MYKIzZ6ZWAqR2rInyQR8mfRPfr6khqzfS+gTO+5rGPPtNuLfZ6L/ydWWm6ULCyinEI bQWxS5VmwsIKpFq+5gyzPzl7QfZWBH+6aHKHVh6c7a1rxOIzwuVV5ipZgBXx4CAjZRgf 94kQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5zsRQ49lzxymcrluxm6njgwK4r8IAoVL8YAuQsKNeiE=; b=aTzkq2+JWu9wB1Ma6E9svl2nvkqR6SbFcvPgc+4x5KHvfgy5FUh6kqQylATXFtsv26 eLoqzvUcVgcquskZdf6mObDd6ZkOPyAmm4uo2g93N6KWF6fNx8xK0usDTDI+pA3e1cTU cWt2ioRR3bdriZvOwUtP1ryPgCDa0uBhc3Rjjb+FowLo0/rCU2ocB23C9sODUSuFN0et w7JiB7bp/uZd/yCxLG3lzlkh6ud83RjsqSiEqHAh/+Tt5Cdi70hTPYdlMUXm//LnuA+l SlcahFAcoA/K5cMGv70yN81NfSjv93G9+0ByzZvu4YPWif6JjdDizp3A4tzeMzUIIzZ0 HjBw==
X-Gm-Message-State: ALoCoQm11Ignug+GzSU6XkPU/OJbUOWSuLgRb5Et9udEecaDTF6fqXBO1x/QePY45HRy5seRWzq5qAvprIG/tfiJhKVaDD1WiQ==
MIME-Version: 1.0
X-Received: by 10.25.64.9 with SMTP id n9mr8687305lfa.13.1450799383800; Tue, 22 Dec 2015 07:49:43 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Tue, 22 Dec 2015 07:49:43 -0800 (PST)
In-Reply-To: 
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>  <56783B45.1020505@cisco.com> <20151221180231.GC43694@elstar.local> <56793618.3080403@cisco.com> <003272D4-EB32-47DE-A105-DDB894F9D8C7@nic.cz>  <5C282DDE-8D85-4507-92D9-1DEA0A782E17@nic.cz> 
Date: Tue, 22 Dec 2015 07:49:43 -0800
Message-ID: 
From: Andy Bierman 
To: "Acee Lindem (acee)" 
Content-Type: multipart/alternative; boundary=001a113ea4f6e996f805277e8d6a
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 15:49:48 -0000

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

On Tue, Dec 22, 2015 at 5:07 AM, Acee Lindem (acee)  wrote:

> Hi Lada,
>
> On 12/22/15, 7:25 AM, "Ladislav Lhotka"  wrote:
>
> >Hi Acee,
> >
> >> On 22 Dec 2015, at 13:03, Acee Lindem (acee)  wrote:
> >>
> >> Jurgen, Lada,
> >>
> >> On 12/22/15, 6:45 AM, "netmod on behalf of Ladislav Lhotka"
> >>  wrote:
> >>
> >>>
> >>>> On 22 Dec 2015, at 12:38, Benoit Claise  wrote:
> >>>>
> >>>> J=C3=BCrgen,
> >>>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
> >>>>>
> >>>>>> I hope that nobody disagrees that the operational state design and
> >>>>>>how
> >>>>>> to structure the models are the two blocking factors to publish YA=
NG
> >>>>>> models. If you disagree or don't see this, let me know, I should
> >>>>>> communicate better.
> >>>>> Even if it may spoil your day, I disagree that there is a blocking
> >>>>> factor that should stop us from publishing models.
> >>>> Interestingly, I received that feedback again recently, this time fr=
om
> >>>> the OSPF and ISIS YANG model authors.
> >>>
> >>> Did they mention any reason *why* it is a blocking factor for their
> >>> modules?
> >>
> >> This should be obvious - the OSPF and IS-IS WG are not going to publis=
h
> >> YANG models that don=E2=80=99t meet the ops-state requirements. Why wo=
uld we
> >
> >Can you please explain what specific ops-state requirements aren't met i=
n
> >those modules? I am interested because the same problem may possibly be
> >present in our ietf-routing module.
>
> That=E2=80=99s easy - the requirements as stated in
> https://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/
>
> We could go back and reorganize the IGP models and add separate leaves fo=
r
> intended and applied config and meet these requirements. However, if we
> conclude on a more elegant solution, it would be great to avail ourselves
> to that solution.
>
>

At the last IETF, the consensus in the room was to use an RPC-based
solution.
Has that changed? What aspect of the RPC-based solution is blocking data
model development?



> Thanks,
> Acee
>


Andy


>
>
>
> >
> >Thanks, Lada
> >
> >> publish standards that don=E2=80=99t meet the requirements and are,
> >>consequently,
> >> irrelevant? Failure to recognize this is a real blocking issue.
> >>
> >> Acee
> >>
> >>
> >>
> >>
> >>>
> >>> Thanks, Lada
> >>>
> >>>>> There seem to be
> >>>>> ways to address the requirements without having to block all work o=
r
> >>>>> to redo what that we have published.
> >>>> That's my hope too.
> >>>>> But sure, if you make it a
> >>>>> blocking factor, it will be one.
> >>>> I'll chose to ignore this last sentence.
> >>>>
> >>>> Regards, Benoit
> >>>>>
> >>>>>> I hope that nobody really believes that because some people in IET=
F
> >>>>>> (or
> >>>>>> in any other SDOs) thinks that what those operators want is a bad
> >>>>>> idea,
> >>>>>> those operators will not get what they request/pay for from their
> >>>>>> suppliers.
> >>>>> To be fair, those operators also tell us that they use protocols th=
at
> >>>>> are not IETF protocols and it remains somewhat unclear what those
> >>>>> protocols are we are expected to optimize data model solutions for.
> >>>>>
> >>>>> /js
> >>>>>
> >>>>
> >>>> _______________________________________________
> >>>> netmod mailing list
> >>>> netmod@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/netmod
> >>>
> >>> --
> >>> Ladislav Lhotka, CZ.NIC Labs
> >>> PGP Key ID: E74E8C0C
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> netmod mailing list
> >>> netmod@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netmod
> >
> >--
> >Ladislav Lhotka, CZ.NIC Labs
> >PGP Key ID: E74E8C0C
> >
> >
> >
> >
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Tue, Dec 22, 2015 at 5:07 AM, Acee Lindem (acee) &=
lt;acee@cisco.com&g=
t; wrote:
Hi Lada,



On 12/22/15, 7:25 AM, "Ladislav Lhotka" <lhotka@nic.cz> wrote:



>Hi Acee,

>

>> On 22 Dec 2015, at 13:03, Acee Lindem (acee) <acee@cisco.com> wrote:

>>

>> Jurgen, Lada,

>>

>> On 12/22/15, 6:45 AM, "netmod on behalf of Ladislav Lhotka&qu=
ot;

>> <netmod-bounces@ietf=
.org on behalf of lhotka@nic.cz>=
; wrote:

>>

>>>

>>>> On 22 Dec 2015, at 12:38, Benoit Claise <bclaise@cisco.com> wrote:

>>>>

>>>> J=C3=BCrgen,

>>>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Clais=
e wrote:

>>>>>

>>>>>> I hope that nobody disagrees that the operational =
state design and

>>>>>>how

>>>>>> to structure the models are the two blocking facto=
rs to publish YANG

>>>>>> models. If you disagree or don't see this, let=
 me know, I should

>>>>>> communicate better.

>>>>> Even if it may spoil your day, I disagree that there i=
s a blocking

>>>>> factor that should stop us from publishing models.

>>>> Interestingly, I received that feedback again recently, th=
is time from

>>>> the OSPF and ISIS YANG model authors.

>>>

>>> Did they mention any reason *why* it is a blocking factor for =
their

>>> modules?

>>

>> This should be obvious - the OSPF and IS-IS WG are not going to pu=
blish

>> YANG models that don=E2=80=99t meet the ops-state requirements. Wh=
y would we

>

>Can you please explain what specific ops-state requirements aren't =
met in

>those modules? I am interested because the same problem may possibly be=


>present in our ietf-routing module.



That=E2=80=99s easy - the requirements as stated in

https://datatracker.ietf.org/doc/dra=
ft-ietf-netmod-opstate-reqs/



We could go back and reorganize the IGP models and add separate leaves for<=
br>
intended and applied config and meet these requirements. However, if we

conclude on a more elegant solution, it would be great to avail ourselves
to that solution.




At the last IETF, the c=
onsensus in the room was to use an RPC-based solution.
Has that c=
hanged? What aspect of the RPC-based solution is blocking data
mo=
del development?

=C2=A0

Thanks,

Acee


Andy
=C2=
=A0







>

>Thanks, Lada

>

>> publish standards that don=E2=80=99t meet the requirements and are=
,

>>consequently,

>> irrelevant? Failure to recognize this is a real blocking issue.
>>

>> Acee

>>

>>

>>

>>

>>>

>>> Thanks, Lada

>>>

>>>>> There seem to be

>>>>> ways to address the requirements without having to blo=
ck all work or

>>>>> to redo what that we have published.

>>>> That's my hope too.

>>>>> But sure, if you make it a

>>>>> blocking factor, it will be one.

>>>> I'll chose to ignore this last sentence.

>>>>

>>>> Regards, Benoit

>>>>>

>>>>>> I hope that nobody really believes that because so=
me people in IETF

>>>>>> (or

>>>>>> in any other SDOs) thinks that what those operator=
s want is a bad

>>>>>> idea,

>>>>>> those operators will not get what they request/pay=
 for from their

>>>>>> suppliers.

>>>>> To be fair, those operators also tell us that they use=
 protocols that

>>>>> are not IETF protocols and it remains somewhat unclear=
 what those

>>>>> protocols are we are expected to optimize data model s=
olutions for.

>>>>>

>>>>> /js

>>>>>

>>>>

>>>> _______________________________________________

>>>> netmod mailing list

>>>> netmod@ietf.org

>>>> https://www.ietf.org/mailman/listinfo/n=
etmod

>>>

>>> --

>>> Ladislav Lhotka, CZ.NIC Labs

>>> PGP Key ID: E74E8C0C

>>>

>>>

>>>

>>>

>>> _______________________________________________

>>> netmod mailing list

>>> netmod@ietf.org

>>> https://www.ietf.org/mailman/listinfo/net=
mod

>

>--

>Ladislav Lhotka, CZ.NIC Labs

>PGP Key ID: E74E8C0C

>

>

>

>



_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a113ea4f6e996f805277e8d6a--


From nobody Tue Dec 22 07:52:01 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE2F1A1A99 for ; Tue, 22 Dec 2015 07:52:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 kHkMmycEQ8ya for ; Tue, 22 Dec 2015 07:51:58 -0800 (PST)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 4B7581A1A73 for ; Tue, 22 Dec 2015 07:51:58 -0800 (PST)
Received: by mail-lf0-x22e.google.com with SMTP id l133so131271685lfd.2 for ; Tue, 22 Dec 2015 07:51:58 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=2uNl3hVPArs91sl3Da04t5pCgHxoG2x1jym26wgNYm8=; b=S0/l/5DY978CmYhivfxGHjwOQaZ5lSPMjNycRVtqqReolZ+5LWSeackk8vnJtr+qDp SATieIUBZvCW5kAg6FoIh6wQa8ZKaRAF46li+1FAVuoAsaHw6f+uw9A9maC/MbN2MFAk dFrNBimNjn6wr35G95N2wB6FPduV3iMh5/KRw1N3Lo2DswBjgKysHUYGo0RduNTLgbsF fD0kSpgi0GiDA9a4Xvfrvm8E2QTTUDERPvLOHxlUnVA6vE6XAasxTycpdlRtKacOaUNe rbv557ceprhrjE8wwiKmaQC4N3vlYZcMO+gRELGrBCgYfRcwSA0PAGluNTy6ZIBs94CC l6Sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=2uNl3hVPArs91sl3Da04t5pCgHxoG2x1jym26wgNYm8=; b=jojYVpznOAYg9csTLV6Ts7Cog2/0h4QI4AhjvPuBXm6qx2oDYRUYe0a0Nv733SL2kj eEwTcjcjvHqz5E0468LtWE0CD80kGB7oP5P222zQqTQqlvlgDYIptz5gBzl17GHAfeAq NjPJsfS26pPPTo8Smur3Vi/ATBXdDKHF4Pb0l7EWe5Ud2/ykFb4c+LgFnsV6H1JQQTaE JlRh/iQPtRfIj9OS5sz9VkIt4K6CSMVJl4iaMxzgSQ86sSisP1qsIjtGqvo1Iwps16Ou 7MJ12IiANKTm4GH7fIp0hYO0RPHONtmrPzAZcJuZqLrnwksxCxWiVwBVBE1/1F90GY2q pyWA==
X-Gm-Message-State: ALoCoQlwGIWAnme6rLS0ppikG4OerL3JPLmI2td/lk6Nn7jzCXpL5XDj7/Oh3NaBs7VLXH9B6XaIxBjQPoQkQK10/bSDhE/8EA==
MIME-Version: 1.0
X-Received: by 10.25.64.9 with SMTP id n9mr8691332lfa.13.1450799516348; Tue, 22 Dec 2015 07:51:56 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Tue, 22 Dec 2015 07:51:56 -0800 (PST)
In-Reply-To: <0079F052-231E-4DB0-9333-6B730328190E@lucidvision.com>
References: <1033983.1450551979726.JavaMail.root@mswamui-bichon.atl.sa.earthlink.net>  <20151221144723.GA43211@elstar.local> <5E9674F3-DDAB-479F-A8CA-0CF78FE5F1F2@nic.cz> <20151221154054.GB43316@elstar.local> <82E7F91B-9DC4-4E8A-B042-A87B21683283@nic.cz> <20151221190439.GA44038@elstar.local>  <20151222100634.GB45259@elstar.local> <3DC4E3CB-9250-4A32-BD7A-8759CC027CC7@nic.cz> <20151222150654.GA45756@elstar.local>  <0079F052-231E-4DB0-9333-6B730328190E@lucidvision.com>
Date: Tue, 22 Dec 2015 07:51:56 -0800
Message-ID: 
From: Andy Bierman 
To: Nadeau Thomas 
Content-Type: multipart/alternative; boundary=001a113ea4f6cffd4405277e9571
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 15:52:00 -0000

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

On Tue, Dec 22, 2015 at 7:24 AM, Nadeau Thomas 
wrote:

>
> > On Dec 22, 2015:10:23 AM, at 10:23 AM, Ladislav Lhotka 
> wrote:
> >
> >
> >> On 22 Dec 2015, at 16:06, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> >>
> >> On Tue, Dec 22, 2015 at 11:34:41AM +0100, Ladislav Lhotka wrote:
> >>>
> >>>> On 22 Dec 2015, at 11:06, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> >>>>
> >>>> On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka wrote:
> >>>>>
> >>>>>>
> >>>>>> That's why the definition what 'published' means in the IETF is in
> the
> >>>>>> guidelines document. On the other hand, since this is an IETF
> >>>>>> document, I also do not find it problematic to define IETF rules
> >>>>>> here. Others should be able to skip over this. There are really mo=
re
> >>>>>> important problems to solve.
> >>>>>
> >>>>> It is not clear at all from sec. 10 that data modellers outside IET=
F
> may skip over this. I am not even sure that everybody in this WG agrees
> with your interpretation.
> >>>>>
> >>>>
> >>>> You are wrong.
> >>>>
> >>>> - Section 10 in RFC 6020 applies to all published modules.
> >>>
> >>> The bullets specifying the rules are introduced with this sentence:
> >>>
> >>> 'A definition may be revised in any of the following ways:'
> >>>
> >>> so IMO it is intended to apply to *all* modules. Are you saying that
> it actually means
> >>>
> >>> 'A definition in a module published by IETF may be revised in any of
> the following ways:'?
> >>>
> >>
> >> A definition in a published module may be revised [...]
> >>
> >>>> - The definition of what turns a module into a published module is
> >>>> specific to the different organizations publishing modules.
> >>>
> >>> So it means that such an organization may also decide to ignore the
> rules entirely or replace them with its own rules.
> >>>
> >>
> >> No.
> >>
> >>> If the WG can agree on this and make the corresponding changes in sec=
.
> 11 of 6020bis, then I have no more objections.
> >>
> >> The rules are there to ensure interoperability. Interoperability is an
> >> issue for published modules (but not for modules under development).
> >
> > This doesn't make much sense unless you give an objective definition of
> "published". For example, are proprietary modules (developed by vendors)
> ever published?
>
>         And that is the point I made the other day. Simply saying that
> definition is The IETF=E2=80=99s
> definition forms a rather circular argument.
>
>

Each SDO may have its own definition of work-in-progress vs
published-for-use.
It doesn't seem that hard to figure out without help from the IETF.




>         =E2=80=94Tom
>


Andy


>
>
> >
> >> The IETF certainly has a history to care about interoperability. I
> >> expect that other organizations care about interoperability as well.
> >
> > That's their business.
> >
> > Lada
> >
> >>
> >> /js
> >>
> >> --
> >> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> >> Fax:   +49 421 200 3103         
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> > _______________________________________________
> > 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
>

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




On Tue, Dec 22, 2015 at 7:24 AM, Nadeau Thomas <tnadeau@lucidvis=
ion.com> wrote:


> On Dec 22, 2015:10:23 AM, at 10:23 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>

>

>> On 22 Dec 2015, at 16:06, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university=
.de> wrote:

>>

>> On Tue, Dec 22, 2015 at 11:34:41AM +0100, Ladislav Lhotka wrote:
>>>

>>>> On 22 Dec 2015, at 11:06, Juergen Schoenwaelder <j.schoenwaelder@jacobs-un=
iversity.de> wrote:

>>>>

>>>> On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka =
wrote:

>>>>>

>>>>>>

>>>>>> That's why the definition what 'published&=
#39; means in the IETF is in the

>>>>>> guidelines document. On the other hand, since this=
 is an IETF

>>>>>> document, I also do not find it problematic to def=
ine IETF rules

>>>>>> here. Others should be able to skip over this. The=
re are really more

>>>>>> important problems to solve.

>>>>>

>>>>> It is not clear at all from sec. 10 that data modeller=
s outside IETF may skip over this. I am not even sure that everybody in thi=
s WG agrees with your interpretation.

>>>>>

>>>>

>>>> You are wrong.

>>>>

>>>> - Section 10 in RFC 6020 applies to all published modules.=


>>>

>>> The bullets specifying the rules are introduced with this sent=
ence:

>>>

>>> 'A definition may be revised in any of the following ways:=
'

>>>

>>> so IMO it is intended to apply to *all* modules. Are you sayin=
g that it actually means

>>>

>>> 'A definition in a module published by IETF may be revised=
 in any of the following ways:'?

>>>

>>

>> A definition in a published module may be revised [...]

>>

>>>> - The definition of what turns a module into a published m=
odule is

>>>> specific to the different organizations publishing modules=
.

>>>

>>> So it means that such an organization may also decide to ignor=
e the rules entirely or replace them with its own rules.

>>>

>>

>> No.

>>

>>> If the WG can agree on this and make the corresponding changes=
 in sec. 11 of 6020bis, then I have no more objections.

>>

>> The rules are there to ensure interoperability. Interoperability i=
s an

>> issue for published modules (but not for modules under development=
).

>

> This doesn't make much sense unless you give an objective definiti=
on of "published". For example, are proprietary modules (develope=
d by vendors) ever published?



=C2=A0 =C2=A0 =C2=A0 =C2=A0 And that is the point I made the other day. Sim=
ply saying that definition is The IETF=E2=80=99s

definition forms a rather circular argument.




Each SDO may have its o=
wn definition of work-in-progress vs published-for-use.
It doesn&=
#39;t seem that hard to figure out without help from the IETF.

=C2=A0

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=94Tom


Andy
=C2=A0





>

>> The IETF certainly has a history to care about interoperability. I=


>> expect that other organizations care about interoperability as wel=
l.

>

> That's their business.

>

> Lada

>

>>

>> /js

>>

>> --

>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jaco=
bs University Bremen gGmbH

>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ri=
ng 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/>

>

> --

> Ladislav Lhotka, CZ.NIC Labs

> PGP Key ID: E74E8C0C

>

>

>

>

> _______________________________________________

> 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





--001a113ea4f6cffd4405277e9571--


From nobody Tue Dec 22 07:54:07 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB001A1AB1 for ; Tue, 22 Dec 2015 07:54:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 DISoCVXlB7Vp for ; Tue, 22 Dec 2015 07:54:03 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 927891A1AAD for ; Tue, 22 Dec 2015 07:54:03 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 63F8373C; Tue, 22 Dec 2015 16:54:02 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id AOBTBBO8NHHD; Tue, 22 Dec 2015 16:54:01 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 22 Dec 2015 16:54:01 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 14D2C20055; Tue, 22 Dec 2015 16:54:01 +0100 (CET)
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 0BLGUEfFtXWz; Tue, 22 Dec 2015 16:53:59 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6AD9920056; Tue, 22 Dec 2015 16:53:59 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 5615839607C0; Tue, 22 Dec 2015 16:53:57 +0100 (CET)
Date: Tue, 22 Dec 2015 16:53:56 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20151222155356.GA45865@elstar.local>
Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org
References: <20151221144723.GA43211@elstar.local> <5E9674F3-DDAB-479F-A8CA-0CF78FE5F1F2@nic.cz> <20151221154054.GB43316@elstar.local> <82E7F91B-9DC4-4E8A-B042-A87B21683283@nic.cz> <20151221190439.GA44038@elstar.local>  <20151222100634.GB45259@elstar.local> <3DC4E3CB-9250-4A32-BD7A-8759CC027CC7@nic.cz> <20151222150654.GA45756@elstar.local> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 15:54:05 -0000

On Tue, Dec 22, 2015 at 04:23:44PM +0100, Ladislav Lhotka wrote:
> 
> > On 22 Dec 2015, at 16:06, Juergen Schoenwaelder  wrote:
> > 
> > On Tue, Dec 22, 2015 at 11:34:41AM +0100, Ladislav Lhotka wrote:
> >> 
> >>> On 22 Dec 2015, at 11:06, Juergen Schoenwaelder  wrote:
> >>> 
> >>> On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka wrote:
> >>>> 
> >>>>> 
> >>>>> That's why the definition what 'published' means in the IETF is in the
> >>>>> guidelines document. On the other hand, since this is an IETF
> >>>>> document, I also do not find it problematic to define IETF rules
> >>>>> here. Others should be able to skip over this. There are really more
> >>>>> important problems to solve.
> >>>> 
> >>>> It is not clear at all from sec. 10 that data modellers outside IETF may skip over this. I am not even sure that everybody in this WG agrees with your interpretation.
> >>>> 
> >>> 
> >>> You are wrong.
> >>> 
> >>> - Section 10 in RFC 6020 applies to all published modules.
> >> 
> >> The bullets specifying the rules are introduced with this sentence:
> >> 
> >> 'A definition may be revised in any of the following ways:'
> >> 
> >> so IMO it is intended to apply to *all* modules. Are you saying that it actually means
> >> 
> >> 'A definition in a module published by IETF may be revised in any of the following ways:'?
> >> 
> > 
> > A definition in a published module may be revised [...]
> > 
> >>> - The definition of what turns a module into a published module is
> >>> specific to the different organizations publishing modules.
> >> 
> >> So it means that such an organization may also decide to ignore the rules entirely or replace them with its own rules.
> >> 
> > 
> > No.
> > 
> >> If the WG can agree on this and make the corresponding changes in sec. 11 of 6020bis, then I have no more objections.
> > 
> > The rules are there to ensure interoperability. Interoperability is an
> > issue for published modules (but not for modules under development).
> 
> This doesn't make much sense unless you give an objective definition of "published". For example, are proprietary modules (developed by vendors) ever published?
>

This has to be late binding - an organization publishing modules will
have to define what 'publishing' means for them and they will have to
decide whether they publish anything at all.

/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 Dec 22 08:36:04 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85931A6FD1 for ; Tue, 22 Dec 2015 08:36:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Level: 
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 BJhgK32PYsuF for ; Tue, 22 Dec 2015 08:36:01 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 3F3F21A6FC0 for ; Tue, 22 Dec 2015 08:36:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450802128; bh=s9qiiwhki/xMtVq2C8WBuxHTB/Jj+FkYRT3NisHn2Fk=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=p2TgYUNW89JTp8NZMLJEKVnJyfxQtNb58yR5ZPzqIXphoOLQFeME+c9hB03OsqpBM KeC7WI1mG63J2bJfMM8LTwB85XFgyJfk2HwB7rNXrlbcfn3fGKyrFIv8Q9uP5M3JAx vXq2uiy+/JjA4jP1zvrXEwxcTCcFAhz8u2+sWcq4=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Nadeau Thomas 
In-Reply-To: <20151222155356.GA45865@elstar.local>
Date: Tue, 22 Dec 2015 11:35:22 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <69A5AB6F-C076-4CA1-9DEA-832C16488515@lucidvision.com>
References: <20151221144723.GA43211@elstar.local> <5E9674F3-DDAB-479F-A8CA-0CF78FE5F1F2@nic.cz> <20151221154054.GB43316@elstar.local> <82E7F91B-9DC4-4E8A-B042-A87B21683283@nic.cz> <20151221190439.GA44038@elstar.local>  <20151222100634.GB45259@elstar.local> <3DC4E3CB-9250-4A32-BD7A-8759CC027CC7@nic.cz> <20151222150654.GA45756@elstar.local>  <20151222155356.GA45865@elstar.local>
To: Juergen Schoenwaelder 
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=8 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 221, in=2946, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 16:36:03 -0000

> On Dec 22, 2015:10:53 AM, at 10:53 AM, Juergen Schoenwaelder =
 wrote:
>=20
> On Tue, Dec 22, 2015 at 04:23:44PM +0100, Ladislav Lhotka wrote:
>>=20
>>> On 22 Dec 2015, at 16:06, Juergen Schoenwaelder =
 wrote:
>>>=20
>>> On Tue, Dec 22, 2015 at 11:34:41AM +0100, Ladislav Lhotka wrote:
>>>>=20
>>>>> On 22 Dec 2015, at 11:06, Juergen Schoenwaelder =
 wrote:
>>>>>=20
>>>>> On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka wrote:
>>>>>>=20
>>>>>>>=20
>>>>>>> That's why the definition what 'published' means in the IETF is =
in the
>>>>>>> guidelines document. On the other hand, since this is an IETF
>>>>>>> document, I also do not find it problematic to define IETF rules
>>>>>>> here. Others should be able to skip over this. There are really =
more
>>>>>>> important problems to solve.
>>>>>>=20
>>>>>> It is not clear at all from sec. 10 that data modellers outside =
IETF may skip over this. I am not even sure that everybody in this WG =
agrees with your interpretation.
>>>>>>=20
>>>>>=20
>>>>> You are wrong.
>>>>>=20
>>>>> - Section 10 in RFC 6020 applies to all published modules.
>>>>=20
>>>> The bullets specifying the rules are introduced with this sentence:
>>>>=20
>>>> 'A definition may be revised in any of the following ways:'
>>>>=20
>>>> so IMO it is intended to apply to *all* modules. Are you saying =
that it actually means
>>>>=20
>>>> 'A definition in a module published by IETF may be revised in any =
of the following ways:'?
>>>>=20
>>>=20
>>> A definition in a published module may be revised [...]
>>>=20
>>>>> - The definition of what turns a module into a published module is
>>>>> specific to the different organizations publishing modules.
>>>>=20
>>>> So it means that such an organization may also decide to ignore the =
rules entirely or replace them with its own rules.
>>>>=20
>>>=20
>>> No.
>>>=20
>>>> If the WG can agree on this and make the corresponding changes in =
sec. 11 of 6020bis, then I have no more objections.
>>>=20
>>> The rules are there to ensure interoperability. Interoperability is =
an
>>> issue for published modules (but not for modules under development).
>>=20
>> This doesn't make much sense unless you give an objective definition =
of "published". For example, are proprietary modules (developed by =
vendors) ever published?
>>=20
>=20
> This has to be late binding - an organization publishing modules will
> have to define what 'publishing' means for them and they will have to
> decide whether they publish anything at all.

	So that is exactly what I was suggesting the document=E2=80=99s =
text
be changed to.  At the present time it refers to the IETF=E2=80=99s =
process
only.

	=E2=80=94Tom


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


From nobody Tue Dec 22 08:55:09 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829BB1A87C5 for ; Tue, 22 Dec 2015 08:55:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 SMochmMoEtF5 for ; Tue, 22 Dec 2015 08:55:05 -0800 (PST)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 EFAE31A87B3 for ; Tue, 22 Dec 2015 08:55:04 -0800 (PST)
Received: by mail-lf0-x22e.google.com with SMTP id y184so132685208lfc.1 for ; Tue, 22 Dec 2015 08:55:04 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=fWGLSg6d9OhinGhS0KDS6CJzRJ0wO+M8rPu1iBIZxrs=; b=hVppc0xJy22QbpXl3OVEHI4YFwEO0CNOm8hziMlRDTEtiz9jMoBPLNIxNe52ECW5uY BXCmUPChf9G3bIvZZIXPM563CruAytEh2bSNxiJAQiVO251MKNYJ/AguqQvi3n3pF7hC msOV2vxweJQ1kiZgAFmP21n6k/w3G5zECMZA+1V8p+tRllU2Xjir9ByDLQ7iokelHJek qZF56JkWURK34cD9caIbUW8VYNBilGy+SMkJYuB1ldwnMzZnt9LD72Hqigfl6gH3J6ks oYPiUZPuJTotf5/8h6NI2L3sr+FqjNhRMReNq2MeeG+rq3k/g729tDw9GjOweGkRD8j2 3SHQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=fWGLSg6d9OhinGhS0KDS6CJzRJ0wO+M8rPu1iBIZxrs=; b=ZyDjvh2vFrPPJsx+OKNzyBuLApMf02wn5NGUSoh88wzeWKqOoiBwJiCsdHxiXAGwsq FTBav92HrS8l6dXeKT5+2oXTG+VOIP/Q9UAZ1xzicW/HDdE+7lzcPyhCNtqSt6ZwkvIP gSAt6AUZZVFOx8DTdZkKn/Ui8H0HV2mK0+K5Wxw1PgwkekYB35PO7tZ9Hlf4gXiWUNqe vHViTclJXu7RbDRHtxwdV1hBzeNKC1qvAjvYnU5w3nSjqai/XQgx3HJgeEVOHC+eF6Gy whbLo1nhbzObrLT+EnLxywFTGSWC/RnWDhxXEAapx+rev4woYsQsSKbyNgJZCC5mj44N 0HBQ==
X-Gm-Message-State: ALoCoQksZ03WTDl+akZGaJ5g/W1OoEqwY2kA31fjxz5GQ468H4yM3rXN22hyinAgQg+jF3A53qRfMkZjBWjFkRn8regWR3hE4g==
MIME-Version: 1.0
X-Received: by 10.25.64.9 with SMTP id n9mr8805204lfa.13.1450803303128; Tue, 22 Dec 2015 08:55:03 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Tue, 22 Dec 2015 08:55:02 -0800 (PST)
In-Reply-To: <69A5AB6F-C076-4CA1-9DEA-832C16488515@lucidvision.com>
References: <20151221144723.GA43211@elstar.local> <5E9674F3-DDAB-479F-A8CA-0CF78FE5F1F2@nic.cz> <20151221154054.GB43316@elstar.local> <82E7F91B-9DC4-4E8A-B042-A87B21683283@nic.cz> <20151221190439.GA44038@elstar.local>  <20151222100634.GB45259@elstar.local> <3DC4E3CB-9250-4A32-BD7A-8759CC027CC7@nic.cz> <20151222150654.GA45756@elstar.local>  <20151222155356.GA45865@elstar.local> <69A5AB6F-C076-4CA1-9DEA-832C16488515@lucidvision.com>
Date: Tue, 22 Dec 2015 08:55:02 -0800
Message-ID: 
From: Andy Bierman 
To: Nadeau Thomas 
Content-Type: multipart/alternative; boundary=001a113ea4f685bf5305277f7797
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 16:55:07 -0000

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

On Tue, Dec 22, 2015 at 8:35 AM, Nadeau Thomas 
wrote:

>
> > On Dec 22, 2015:10:53 AM, at 10:53 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> >
> > On Tue, Dec 22, 2015 at 04:23:44PM +0100, Ladislav Lhotka wrote:
> >>
> >>> On 22 Dec 2015, at 16:06, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> >>>
> >>> On Tue, Dec 22, 2015 at 11:34:41AM +0100, Ladislav Lhotka wrote:
> >>>>
> >>>>> On 22 Dec 2015, at 11:06, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
> >>>>>
> >>>>> On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka wrote:
> >>>>>>
> >>>>>>>
> >>>>>>> That's why the definition what 'published' means in the IETF is i=
n
> the
> >>>>>>> guidelines document. On the other hand, since this is an IETF
> >>>>>>> document, I also do not find it problematic to define IETF rules
> >>>>>>> here. Others should be able to skip over this. There are really
> more
> >>>>>>> important problems to solve.
> >>>>>>
> >>>>>> It is not clear at all from sec. 10 that data modellers outside
> IETF may skip over this. I am not even sure that everybody in this WG
> agrees with your interpretation.
> >>>>>>
> >>>>>
> >>>>> You are wrong.
> >>>>>
> >>>>> - Section 10 in RFC 6020 applies to all published modules.
> >>>>
> >>>> The bullets specifying the rules are introduced with this sentence:
> >>>>
> >>>> 'A definition may be revised in any of the following ways:'
> >>>>
> >>>> so IMO it is intended to apply to *all* modules. Are you saying that
> it actually means
> >>>>
> >>>> 'A definition in a module published by IETF may be revised in any of
> the following ways:'?
> >>>>
> >>>
> >>> A definition in a published module may be revised [...]
> >>>
> >>>>> - The definition of what turns a module into a published module is
> >>>>> specific to the different organizations publishing modules.
> >>>>
> >>>> So it means that such an organization may also decide to ignore the
> rules entirely or replace them with its own rules.
> >>>>
> >>>
> >>> No.
> >>>
> >>>> If the WG can agree on this and make the corresponding changes in
> sec. 11 of 6020bis, then I have no more objections.
> >>>
> >>> The rules are there to ensure interoperability. Interoperability is a=
n
> >>> issue for published modules (but not for modules under development).
> >>
> >> This doesn't make much sense unless you give an objective definition o=
f
> "published". For example, are proprietary modules (developed by vendors)
> ever published?
> >>
> >
> > This has to be late binding - an organization publishing modules will
> > have to define what 'publishing' means for them and they will have to
> > decide whether they publish anything at all.
>
>         So that is exactly what I was suggesting the document=E2=80=99s t=
ext
> be changed to.  At the present time it refers to the IETF=E2=80=99s proce=
ss
> only.
>

I know -- I added issue #25 4 days ago:
https://github.com/netmod-wg/rfc6087bis/issues/25



>
>         =E2=80=94Tom
>
>
>

Andy



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

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




On Tue, Dec 22, 2015 at 8:35 AM, Nadeau Thomas <tnadeau@lucidvis=
ion.com> wrote:


> On Dec 22, 2015:10:53 AM, at 10:53 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-u=
niversity.de> wrote:

>

> On Tue, Dec 22, 2015 at 04:23:44PM +0100, Ladislav Lhotka wrote:

>>

>>> On 22 Dec 2015, at 16:06, Juergen Schoenwaelder <j.schoenwaelder@jacobs-univer=
sity.de> wrote:

>>>

>>> On Tue, Dec 22, 2015 at 11:34:41AM +0100, Ladislav Lhotka wrot=
e:

>>>>

>>>>> On 22 Dec 2015, at 11:06, Juergen Schoenwaelder <j.schoenwaelder@jacob=
s-university.de> wrote:

>>>>>

>>>>> On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lho=
tka wrote:

>>>>>>

>>>>>>>

>>>>>>> That's why the definition what 'publis=
hed' means in the IETF is in the

>>>>>>> guidelines document. On the other hand, since =
this is an IETF

>>>>>>> document, I also do not find it problematic to=
 define IETF rules

>>>>>>> here. Others should be able to skip over this.=
 There are really more

>>>>>>> important problems to solve.

>>>>>>

>>>>>> It is not clear at all from sec. 10 that data mode=
llers outside IETF may skip over this. I am not even sure that everybody in=
 this WG agrees with your interpretation.

>>>>>>

>>>>>

>>>>> You are wrong.

>>>>>

>>>>> - Section 10 in RFC 6020 applies to all published modu=
les.

>>>>

>>>> The bullets specifying the rules are introduced with this =
sentence:

>>>>

>>>> 'A definition may be revised in any of the following w=
ays:'

>>>>

>>>> so IMO it is intended to apply to *all* modules. Are you s=
aying that it actually means

>>>>

>>>> 'A definition in a module published by IETF may be rev=
ised in any of the following ways:'?

>>>>

>>>

>>> A definition in a published module may be revised [...]

>>>

>>>>> - The definition of what turns a module into a publish=
ed module is

>>>>> specific to the different organizations publishing mod=
ules.

>>>>

>>>> So it means that such an organization may also decide to i=
gnore the rules entirely or replace them with its own rules.

>>>>

>>>

>>> No.

>>>

>>>> If the WG can agree on this and make the corresponding cha=
nges in sec. 11 of 6020bis, then I have no more objections.

>>>

>>> The rules are there to ensure interoperability. Interoperabili=
ty is an

>>> issue for published modules (but not for modules under develop=
ment).

>>

>> This doesn't make much sense unless you give an objective defi=
nition of "published". For example, are proprietary modules (deve=
loped by vendors) ever published?

>>

>

> This has to be late binding - an organization publishing modules will<=
br>
> have to define what 'publishing' means for them and they will =
have to

> decide whether they publish anything at all.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 So that is exactly what I was suggesting the do=
cument=E2=80=99s text

be changed to.=C2=A0 At the present time it refers to the IETF=E2=80=99s pr=
ocess

only.

I know -- I added issue #25 4 day=
s ago:

=C2=A0



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=94Tom






Andy

=C2=A0

>

> /js

>

> --

> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U=
niversity Bremen gGmbH

> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus 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


_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a113ea4f685bf5305277f7797--


From nobody Tue Dec 22 09:08:21 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879991A89A8 for ; Tue, 22 Dec 2015 09:08:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 FqrFpz8_2kRg for ; Tue, 22 Dec 2015 09:08:19 -0800 (PST)
Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::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 DF8341A89A7 for ; Tue, 22 Dec 2015 09:08:18 -0800 (PST)
Received: by mail-lb0-x22a.google.com with SMTP id bc4so34466097lbc.2 for ; Tue, 22 Dec 2015 09:08:18 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=sd/E/wF+f1AgMV0Daj5iU2+rtppopYuV87vybd0xi3A=; b=OOYAHLQhRUXsMTTDEed0s8LM+uQBy/OtSfoXA5KVeJ2eAEK5TlYaRbQb1uuZ8CafuP qLpHymBHD/Scca7arUQNCnyfF2ePdoDp2vh8ieqt289SqFCvvZcYdti8f6AIDw/pWXdT irux7I3FDKgidpKCb/Xiz3yNAJnF9QK6dy85tpKMgZwc++rfLBQOMpoTkChXx+TK4A5A QKM/4W22pf5aqqDQ35O4dWEnBosetVulgBS7lVQKO4kZ13IvAZOlbbKQh5MYJEbNSSVR Hkqx0tvhaFZThGAgFibxSEPnpWXe02gj0a6EzliV1SOv87Lwies6l+QZZHQPr76FM9Io 8JPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sd/E/wF+f1AgMV0Daj5iU2+rtppopYuV87vybd0xi3A=; b=ipHb0C57Xigh9hWd6K7/AC21KthOzweDIHhLzET8gxWadJdK1gUDydRUFCXumNCfqk kU3iVIl7uaJrWLUhq6vHogoziYkAI6LUA13JA73EvyR+7sZVenHit6RCD3WY4hlovlw1 atC7fxJR7fktKTd6g5o7CtHzF2Yr9mnuFnqnQ1F7b1+vJAB07/1mM4Gr20xnt5F8pIqL vaNvFHzKaphAViyoY9iYsRboAJLxwIYwx3Om8qtalYm/nmi60WjjM1yY7QNpulxcC/MH zVJBX2w//nLf6DLt2ibk3v5LyY+XVkrLhORrhsmVnO9ExOcygKTU868IDGB1MuwGEURY saCQ==
X-Gm-Message-State: ALoCoQk2Skx5S6OIKn7Ej5wSmD/EYqbGpIyM5+w6mObyqtWe+sgoMVmDxf2qFwKnlDT5UzLYE8DGhyxXWHlj7DgNMbZ/RE7u5Q==
MIME-Version: 1.0
X-Received: by 10.112.202.101 with SMTP id kh5mr8865681lbc.66.1450804096984; Tue, 22 Dec 2015 09:08:16 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Tue, 22 Dec 2015 09:08:16 -0800 (PST)
In-Reply-To: 
References: 
Date: Tue, 22 Dec 2015 09:08:16 -0800
Message-ID: 
From: Andy Bierman 
To: Nadeau Thomas 
Content-Type: multipart/alternative; boundary=001a11c3724cd706be05277fa6a3
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] New Thread: IESG Review Process for Yang Models at the IETF
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 17:08:20 -0000

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

On Tue, Dec 22, 2015 at 5:06 AM, Nadeau Thomas 
wrote:

>
> [moving the thread to its own discussion.]
>
> >       This is a blocking factor that people are not considering: The RFC
> process the
> > IETF has in place is not suitable for rapid/modern/canonical model
> development.  It will
> > be difficult for the IESG review process to scale to even a couple
> models during any given
> > telechat period given the state of the document review/approval process.
> How do we
> > envision the IESG reviewing 250+ models (and growing)?  Besides the
> initial RFC version,
> > rapid refresh/update of models has the same issues.
>
> I don't disagree, but I propose that we stick to the oper state discussion
> in this email thread.
>
>
Since this is a new thread, I am confused by the topic.
This suggests that the IESG final review of drafts is the bottleneck for
YANG.
I see no evidence of that.

The "RFC process" is a consensus and review based process.
The way to circumvent that consensus-based process is to publish
AD-sponsored Informational RFCs.

Getting people to agree on the details has always been the hard part
of standards development.  YANG modules are no different from any
other standard in this respect.





> Regards, Benoit
>


Andy


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

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




On Tue, Dec 22, 2015 at 5:06 AM, Nadeau Thomas <tnadeau@lucidvis=
ion.com> wrote:


[moving the thread to its own discussion.]



>=C2=A0 =C2=A0 =C2=A0 =C2=A0This is a blocking factor that people are no=
t considering: The RFC process the

> IETF has in place is not suitable for rapid/modern/canonical model dev=
elopment.=C2=A0 It will

> be difficult for the IESG review process to scale to even a couple mod=
els during any given

> telechat period given the state of the document review/approval proces=
s. How do we

> envision the IESG reviewing 250+ models (and growing)?=C2=A0 Besides t=
he initial RFC version,

> rapid refresh/update of models has the same issues.



I don't disagree, but I propose that we stick to the oper state discuss=
ion in this email thread.



Since this is a new thread, I am confu=
sed by the topic.
This suggests that the IESG final review of dra=
fts is the bottleneck for YANG.
I see no evidence of that.
<=
div>
The "RFC process" is a consensus and review ba=
sed process.
The way to circumvent that consensus-based process i=
s to publish
AD-sponsored Informational RFCs.

Getting people to agree on the details has always been the hard part<=
/div>
of standards development.=C2=A0 YANG modules are no different fro=
m any
other standard in this respect.


=C2=A0

Regards, Benoit


Andy
=C2=A0





_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a11c3724cd706be05277fa6a3--


From nobody Tue Dec 22 09:11:57 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2091A8792 for ; Tue, 22 Dec 2015 09:11:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 sTX0ShrMOhlA for ; Tue, 22 Dec 2015 09:11:54 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7EF71A6FB4 for ; Tue, 22 Dec 2015 09:11:53 -0800 (PST)
Received: from [IPv6:2a01:5e0:29:ffff:8da8:dd65:c442:8639] (unknown [IPv6:2a01:5e0:29:ffff:8da8:dd65:c442:8639]) by mail.nic.cz (Postfix) with ESMTPSA id 66136180A16; Tue, 22 Dec 2015 18:11:52 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450804312; bh=wYLIZjrJ+8Z4of2azNVgmbs9BnhGANb+h66B53MBtX4=; h=From:Date:To; b=HLWc3y/cnSxoyFghx26hpxymr1++L0lbDGkk7AVicRgEZjmFOX4JJfV7xkUTFeQCW z1jqQjVIDp7+bK3y+bUsFGWS3btXQSmQrlmkunG9haZPkWjfs15guNXc/HlrvXJng2 CxWUpCXW/sDAx/69NcOI02O8CwmgNN8Yl6INi6Ec=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Tue, 22 Dec 2015 18:11:54 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <0E480747-91EE-46B7-9AF7-E3886600935D@nic.cz>  <019FCEF5-780B-43B1-B112-F5DC729A6918@nic.cz> 
To: Thomas Nadeau 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] New Thread: IESG Review Process for Yang Models at the IETF
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 17:11:56 -0000

> On 22 Dec 2015, at 16:43, Nadeau Thomas  =
wrote:
>=20
>>=20
>> On Dec 22, 2015:10:36 AM, at 10:36 AM, Ladislav Lhotka =
 wrote:
>>=20
>>=20
>>> On 22 Dec 2015, at 16:22, Nadeau Thomas  =
wrote:
>>>=20
>>>=20
>>> 	The action I am trying to tease out of this thread is how do we =
take action
>>> going forward? There are many who are saying (and doing) what you =
say below; however,
>>=20
>> This should IMO be OK. One thing that might help avoid unnecessary =
duplication of work is to keep and up-to-date directory, where everybody =
could register their modules. Everything else could be a bottom-up =
process.
>>=20
>> Lada
>=20
> 	That has been discussed on a separate thread.  I think the best =
idea right now is to
> do something in IANA for a module namespace/ID registry but Benoit has =
asked us to write
> up a draft with some ideas.

I think I don't even need IANA registration.

Lada

>=20
> 	=E2=80=94Tom
>=20
>=20
>>=20
>>> there are related discussions on the RFC6020 update to the module =
update rules
>>> claiming that we should only focus on IETF-realted modules. Do you =
see the catch-22
>>> I am trying to make clear here?   The other issue is the simple =
process for those modules
>>> that are developed here. Should we move them all to an external =
model, should we=20
>>> amend the IETF=E2=80=99s processes to accommodate rapid model =
development and iteration?
>>>=20
>>> 	=E2=80=94Tom
>>>=20
>>>=20
>>>> On Dec 22, 2015:8:39 AM, at 8:39 AM, Ladislav Lhotka =
 wrote:
>>>>=20
>>>>=20
>>>>> On 22 Dec 2015, at 14:06, Nadeau Thomas  =
wrote:
>>>>>=20
>>>>>=20
>>>>> [moving the thread to its own discussion.]
>>>>>=20
>>>>>> 	This is a blocking factor that people are not considering: The =
RFC process the
>>>>>> IETF has in place is not suitable for rapid/modern/canonical =
model development.  It will
>>>>>> be difficult for the IESG review process to scale to even a =
couple models during any given
>>>>>> telechat period given the state of the document review/approval =
process. How do we
>>>>>> envision the IESG reviewing 250+ models (and growing)?  Besides =
the initial RFC version,
>>>>>> rapid refresh/update of models has the same issues.
>>>>>=20
>>>>> I don't disagree, but I propose that we stick to the oper state =
discussion in this email thread.
>>>>=20
>>>> I agree with Tom. I personally decided not to work on any new =
module in the IETF any time soon. I am currently working on a number of =
modules related to DNS, they will be freely available for review and use =
by everybody, but I don't want to go through a similar process as with =
ietf-routing, and then be stymied by the update rules.
>>>>=20
>>>> Lada
>>>>=20
>>>>>=20
>>>>> Regards, Benoit
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>=20
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>=20
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Tue Dec 22 10:52:31 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 176411A8A84 for ; Tue, 22 Dec 2015 10:52:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level: 
X-Spam-Status: No, score=-2.011 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 LwCwprIwqk_v for ; Tue, 22 Dec 2015 10:52:28 -0800 (PST)
Received: from lucidvision.com (lucidvision.com [64.71.170.115]) (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 061401A8A81 for ; Tue, 22 Dec 2015 10:52:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucidvision.com; s=default; t=1450810315; bh=MnBBjrO8iJ8SQo3lMAzbDKHOPfD6eVbVYlmyBXzZnWE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=IIMFz4AN1Icwu3D9H/ekpvsz0sr7D3q3N+U2y+kBk4ZsNQ043VOSt3m7f9DNsxepg zcc6oxUYfz3HxQMCbbpiUEXQpeQqfjg/L1fNJoBKE4/JfWJQvgm+xr3Elk8/xjgEzi IYbwEZQtCcagmZ+v0QNoV8Z8G/zFWeRoDbSJRaMg=
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=50.255.148.181; 
Content-Type: multipart/alternative; boundary="Apple-Mail=_534C2287-B8A7-4FE7-A13A-5F61982762B5"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Nadeau Thomas 
In-Reply-To: 
Date: Tue, 22 Dec 2015 13:52:13 -0500
Message-Id: 
References: <20151221144723.GA43211@elstar.local> <5E9674F3-DDAB-479F-A8CA-0CF78FE5F1F2@nic.cz> <20151221154054.GB43316@elstar.local> <82E7F91B-9DC4-4E8A-B042-A87B21683283@nic.cz> <20151221190439.GA44038@elstar.local>  <20151222100634.GB45259@elstar.local> <3DC4E3CB-9250-4A32-BD7A-8759CC027CC7@nic.cz> <20151222150654.GA45756@elstar.local>  <20151222155356.GA45865@elstar.local> <69A5AB6F-C076-4CA1-9DEA-832C16488515@lucidvision.com> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3096.5)
X-Authenticated-User: tnadeau@lucidvision.com 
X-Info: aspam skipped due to (g_smite_skip_relay)
X-Encryption: SSL encrypted
X-MyRbl: Color=Yellow Age=0 Spam=0 Notspam=9 Stars=0 Good=0 Friend=0 Surbl=0 Catch=0 r=0 ip=50.255.148.181
X-IP-stats: Notspam Incoming Last 0, First 221, in=2947, out=0, spam=0 Known=true ip=50.255.148.181
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 18:52:30 -0000

--Apple-Mail=_534C2287-B8A7-4FE7-A13A-5F61982762B5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

thx!

> On Dec 22, 2015:11:55 AM, at 11:55 AM, Andy Bierman =
 wrote:
>=20
>=20
>=20
> On Tue, Dec 22, 2015 at 8:35 AM, Nadeau Thomas =
> wrote:
>=20
> > On Dec 22, 2015:10:53 AM, at 10:53 AM, Juergen Schoenwaelder =
> wrote:
> >
> > On Tue, Dec 22, 2015 at 04:23:44PM +0100, Ladislav Lhotka wrote:
> >>
> >>> On 22 Dec 2015, at 16:06, Juergen Schoenwaelder =
> wrote:
> >>>
> >>> On Tue, Dec 22, 2015 at 11:34:41AM +0100, Ladislav Lhotka wrote:
> >>>>
> >>>>> On 22 Dec 2015, at 11:06, Juergen Schoenwaelder =
> wrote:
> >>>>>
> >>>>> On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka wrote:
> >>>>>>
> >>>>>>>
> >>>>>>> That's why the definition what 'published' means in the IETF =
is in the
> >>>>>>> guidelines document. On the other hand, since this is an IETF
> >>>>>>> document, I also do not find it problematic to define IETF =
rules
> >>>>>>> here. Others should be able to skip over this. There are =
really more
> >>>>>>> important problems to solve.
> >>>>>>
> >>>>>> It is not clear at all from sec. 10 that data modellers outside =
IETF may skip over this. I am not even sure that everybody in this WG =
agrees with your interpretation.
> >>>>>>
> >>>>>
> >>>>> You are wrong.
> >>>>>
> >>>>> - Section 10 in RFC 6020 applies to all published modules.
> >>>>
> >>>> The bullets specifying the rules are introduced with this =
sentence:
> >>>>
> >>>> 'A definition may be revised in any of the following ways:'
> >>>>
> >>>> so IMO it is intended to apply to *all* modules. Are you saying =
that it actually means
> >>>>
> >>>> 'A definition in a module published by IETF may be revised in any =
of the following ways:'?
> >>>>
> >>>
> >>> A definition in a published module may be revised [...]
> >>>
> >>>>> - The definition of what turns a module into a published module =
is
> >>>>> specific to the different organizations publishing modules.
> >>>>
> >>>> So it means that such an organization may also decide to ignore =
the rules entirely or replace them with its own rules.
> >>>>
> >>>
> >>> No.
> >>>
> >>>> If the WG can agree on this and make the corresponding changes in =
sec. 11 of 6020bis, then I have no more objections.
> >>>
> >>> The rules are there to ensure interoperability. Interoperability =
is an
> >>> issue for published modules (but not for modules under =
development).
> >>
> >> This doesn't make much sense unless you give an objective =
definition of "published". For example, are proprietary modules =
(developed by vendors) ever published?
> >>
> >
> > This has to be late binding - an organization publishing modules =
will
> > have to define what 'publishing' means for them and they will have =
to
> > decide whether they publish anything at all.
>=20
>         So that is exactly what I was suggesting the document=E2=80=99s =
text
> be changed to.  At the present time it refers to the IETF=E2=80=99s =
process
> only.
>=20
> I know -- I added issue #25 4 days ago:
> https://github.com/netmod-wg/rfc6087bis/issues/25 =

>=20
> =20
>=20
>         =E2=80=94Tom
>=20
>=20
>=20
>=20
> Andy
>=20
> =20
> >
> > /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 =

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

>=20


--Apple-Mail=_534C2287-B8A7-4FE7-A13A-5F61982762B5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

thx!

On Dec 22, 2015:11:55 AM, at =
11:55 AM, Andy Bierman <andy@yumaworks.com> wrote:



On Tue, Dec 22, 2015 at 8:35 AM, Nadeau Thomas =
<tnadeau@lucidvision.com> wrote:


> On Dec 22, 2015:10:53 AM, at 10:53 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

>

> On Tue, Dec 22, 2015 at 04:23:44PM +0100, Ladislav Lhotka wrote:

>>

>>> On 22 Dec 2015, at 16:06, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

>>>

>>> On Tue, Dec 22, 2015 at 11:34:41AM +0100, Ladislav Lhotka =
wrote:

>>>>

>>>>> On 22 Dec 2015, at 11:06, Juergen Schoenwaelder =
<j.schoenwaelder@jacobs-university.de> wrote:

>>>>>

>>>>> On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav =
Lhotka wrote:

>>>>>>

>>>>>>>

>>>>>>> That's why the definition what 'published' =
means in the IETF is in the

>>>>>>> guidelines document. On the other hand, =
since this is an IETF

>>>>>>> document, I also do not find it problematic =
to define IETF rules

>>>>>>> here. Others should be able to skip over =
this. There are really more

>>>>>>> important problems to solve.

>>>>>>

>>>>>> It is not clear at all from sec. 10 that data =
modellers outside IETF may skip over this. I am not even sure that =
everybody in this WG agrees with your interpretation.

>>>>>>

>>>>>

>>>>> You are wrong.

>>>>>

>>>>> - Section 10 in RFC 6020 applies to all published =
modules.

>>>>

>>>> The bullets specifying the rules are introduced with =
this sentence:

>>>>

>>>> 'A definition may be revised in any of the following =
ways:'

>>>>

>>>> so IMO it is intended to apply to *all* modules. Are =
you saying that it actually means

>>>>

>>>> 'A definition in a module published by IETF may be =
revised in any of the following ways:'?

>>>>

>>>

>>> A definition in a published module may be revised [...]

>>>

>>>>> - The definition of what turns a module into a =
published module is

>>>>> specific to the different organizations publishing =
modules.

>>>>

>>>> So it means that such an organization may also decide =
to ignore the rules entirely or replace them with its own rules.

>>>>

>>>

>>> No.

>>>

>>>> If the WG can agree on this and make the corresponding =
changes in sec. 11 of 6020bis, then I have no more objections.

>>>

>>> The rules are there to ensure interoperability. =
Interoperability is an

>>> issue for published modules (but not for modules under =
development).

>>

>> This doesn't make much sense unless you give an objective =
definition of "published". For example, are proprietary modules =
(developed by vendors) ever published?

>>

>

> This has to be late binding - an organization publishing modules =
will

> have to define what 'publishing' means for them and they will have =
to

> decide whether they publish anything at all.



        So that is exactly what I was suggesting the =
document=E2=80=99s text

be changed to.  At the present time it refers to the IETF=E2=80=99s =
process

only.

I know -- I added issue #25 4 days ago:
https://github.com/netmod-wg/rfc6087bis/issues/25

 



        =E2=80=94Tom






Andy

 

>

> /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
=



_______________________________________________

netmod mailing list

netmod@ietf.org

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






=

--Apple-Mail=_534C2287-B8A7-4FE7-A13A-5F61982762B5--


From nobody Tue Dec 22 11:40:16 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41E91A8ABF for ; Tue, 22 Dec 2015 11:40:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 FnoJvfNVn0wm for ; Tue, 22 Dec 2015 11:40:12 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AE751A8ABD for ; Tue, 22 Dec 2015 11:40:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5934; q=dns/txt; s=iport; t=1450813212; x=1452022812; h=from:to:cc:subject:date:message-id:mime-version; bh=4nkxnpiFy76DiuTD+zVmq0Sb6ICjdsjP9W+dx9WEU44=; b=AjYsHLj/jiMBpHLPbzqzdeLLuWpsSRZ3XkjZKAncI1+jTUWUVc57Lm+v UrBYiXl6B0hzRCU43W4guppm4iE2l69iXOmmr9pLgy0b2Ez/mPQB2Zah1 j319RWbWHKI0jDgKzxRo1fD/FTveLfljXFDV+QSRvOC2UQ5g9N+3ZaW7t o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C2BQCvpnlW/5pdJa1egm5MgT8GjEuxL?= =?us-ascii?q?YFjhg0egRU6EgEBAQEBAQGBCoQ0AQIEIwpMEgEIBA0DAQIoAwIEMBQJCgQOBYg?= =?us-ascii?q?vrWqSLAEBAQEBAQEBAQEBAQEBAQEBAQEBARiGVoIPgnCEPjmCfC+BGwWXAQGNS?= =?us-ascii?q?oFcjRyKQoNzASkBOoQEcoQgAYEHAQEB?=
X-IronPort-AV: E=Sophos; i="5.20,465,1444694400"; d="scan'208,217"; a="61314041"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Dec 2015 19:39:46 +0000
Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id tBMJdlT1000650 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Dec 2015 19:39:47 GMT
Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 22 Dec 2015 13:39:46 -0600
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.1104.009; Tue, 22 Dec 2015 13:39:46 -0600
From: "Clyde Wildes (cwildes)" 
To: "Sterne, Jason (Jason)" 
Thread-Topic: [netmod] syslog-model-05:  minor editorial comments
Thread-Index: AQHRPPCDEaA2a9ZB00uhCENfNnWrtA==
Date: Tue, 22 Dec 2015 19:39:46 +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: [128.107.157.191]
Content-Type: multipart/alternative; boundary="_000_D950439A03E34C07A9572111CE8CDED9ciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] syslog-model-05:  minor editorial comments
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 19:40:14 -0000

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

SmFzb24sDQoNCldlIGFyZSBhYm91dCB0byBwdWJsaXNoIGRyYWZ0LWlldGYtbmV0bW9kLXN5c2xv
Zy1tb2RlbC0wNiB3aGljaCBpbmNvcnBvcmF0ZXMgeW91ciBmZWVkYmFjayBiZWxvdy4NCg0KVGhh
bmtzLA0KDQpDbHlkZQ0KDQpGcm9tOiBuZXRtb2QgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1h
aWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiAiU3Rlcm5lLCBKYXNv
biAoSmFzb24pIiA8amFzb24uc3Rlcm5lQGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86amFzb24u
c3Rlcm5lQGFsY2F0ZWwtbHVjZW50LmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIE9jdG9iZXIgMjgs
IDIwMTUgYXQgMTE6NTAgQU0NClRvOiAibmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0
Zi5vcmc+IiA8bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KU3ViamVj
dDogW25ldG1vZF0gc3lzbG9nLW1vZGVsLTA1OiBtaW5vciBlZGl0b3JpYWwgY29tbWVudHMNCg0K
QSBmZXcgbWlub3IgZWRpdG9yaWFsIGNvbW1lbnRzIG9uIHN5c2xvZy1tb2RlbC0wNToNCg0KLSBU
aGUgaW50cm9kdWN0aW9uIHNheXMgIldlIGFyZSB1c2luZyBkZWZpbml0aW9ucyBvZiBTeXNsb2cg
cHJvdG9jb2wgZnJvbSBbUkZDMzE2NF0gaW4gdGhpcyBkcmFmdC4iIGJ1dCB0aGUgWUFORyBtb2Rl
bCBtb3N0bHkgcmVmZXJlbmNlcyA1NDI0Lg0KLSBJbiBzZWN0aW9uIDMgbWF5YmUgdXNlIHRoZSB0
ZXJtICJSZW1vdGUgQ29sbGVjdG9yKHMpIiBpbnN0ZWFkIG9mIFNlcnZlcihzKSA/IENvbGxlY3Rv
ciBzZWVtcyBtb3JlIGluIGxpbmUgd2l0aCBSRkM1NDI0IChvciAiUmVtb3RlIFJlY2VpdmVyIiBp
ZiBvdGhlcnMgcHJlZmVyIHRoYXQpLg0KLSBJbiB0aGUgU2VjdGlvbiAzIGZpZ3VyZSBtYWtlIGFs
bCB0aGUgRGlzdHJpYnV0b3JzIGhhdmUgYSBjb21tb24gc3ludGF4IGZvciBwbHVyYWwgdnMgc2lu
Z3VsYXIgIkxvZyBCdWZmZXIocykiLCAiTG9nIEZpbGUocykiLCAiUmVtb3RlIENvbGxlY3Rvcihz
KSIsIOKAnFVzZXIgVGVybWluYWwocynigJ0NCi0gRG9jdW1lbnQgaXMgbWlzc2luZyB0aGUgc3Rh
bmRhcmQgbGVnZW5kIGZvciB0aGUgUFlBTkcgdHJlZQ0KDQpKYXNvbg0KDQo=

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pkphc29uLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2UgYXJlIGFib3V0IHRv
IHB1Ymxpc2ggZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTA2IHdoaWNoIGluY29ycG9y
YXRlcyB5b3VyIGZlZWRiYWNrIGJlbG93LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+
VGhhbmtzLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Q2x5ZGU8L2Rpdj4NCjxkaXY+
DQo8ZGl2IGlkPSJNQUNfT1VUTE9PS19TSUdOQVRVUkUiPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElP
TiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTJwdDsgdGV4
dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJP
UkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZU
OiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7
IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5
bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5uZXRtb2QgJmx0OzxhIGhyZWY9Im1h
aWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyI+bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L2E+
Jmd0OyBvbiBiZWhhbGYgb2YgJnF1b3Q7U3Rlcm5lLCBKYXNvbiAoSmFzb24pJnF1b3Q7ICZsdDs8
YSBocmVmPSJtYWlsdG86amFzb24uc3Rlcm5lQGFsY2F0ZWwtbHVjZW50LmNvbSI+amFzb24uc3Rl
cm5lQGFsY2F0ZWwtbHVjZW50LmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp
Z2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXksIE9jdG9iZXIgMjgsIDIwMTUgYXQgMTE6
NTAgQU08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVv
dDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+JnF1
b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8
L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3Nw
YW4+W25ldG1vZF0gc3lzbG9nLW1vZGVsLTA1OiBtaW5vciBlZGl0b3JpYWwgY29tbWVudHM8YnI+
DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9y
IiBjb250ZW50PSJNaWNyb3NvZnQgRXhjaGFuZ2UgU2VydmVyIj4NCjwhLS0gY29udmVydGVkIGZy
b20gcnRmIC0tPjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFk
ZGluZy1sZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0
eWxlPg0KPGRpdj48Zm9udCBmYWNlPSJDb25zb2xhcyIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC41cHQ7Ij4NCjxkaXY+QSBmZXcgbWlub3IgZWRpdG9yaWFsIGNvbW1lbnRzIG9u
IHN5c2xvZy1tb2RlbC0wNTo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pi0gVGhlIGlu
dHJvZHVjdGlvbiBzYXlzICZxdW90O1dlIGFyZSB1c2luZyBkZWZpbml0aW9ucyBvZiBTeXNsb2cg
cHJvdG9jb2wgZnJvbSBbUkZDMzE2NF0gaW4gdGhpcyBkcmFmdC4mcXVvdDsgYnV0IHRoZSBZQU5H
IG1vZGVsIG1vc3RseSByZWZlcmVuY2VzIDU0MjQuPC9kaXY+DQo8ZGl2Pi0gSW4gc2VjdGlvbiAz
IG1heWJlIHVzZSB0aGUgdGVybSAmcXVvdDtSZW1vdGUgQ29sbGVjdG9yKHMpJnF1b3Q7IGluc3Rl
YWQgb2YgU2VydmVyKHMpID8gQ29sbGVjdG9yIHNlZW1zIG1vcmUgaW4gbGluZSB3aXRoIFJGQzU0
MjQgKG9yICZxdW90O1JlbW90ZSBSZWNlaXZlciZxdW90OyBpZiBvdGhlcnMgcHJlZmVyIHRoYXQp
LjwvZGl2Pg0KPGRpdj4tIEluIHRoZSBTZWN0aW9uIDMgZmlndXJlIG1ha2UgYWxsIHRoZSBEaXN0
cmlidXRvcnMgaGF2ZSBhIGNvbW1vbiBzeW50YXggZm9yIHBsdXJhbCB2cyBzaW5ndWxhciAmcXVv
dDtMb2cgQnVmZmVyKHMpJnF1b3Q7LCAmcXVvdDtMb2cgRmlsZShzKSZxdW90OywgJnF1b3Q7UmVt
b3RlIENvbGxlY3RvcihzKSZxdW90Oywg4oCcVXNlciBUZXJtaW5hbChzKeKAnTwvZGl2Pg0KPGRp
dj4tIERvY3VtZW50IGlzIG1pc3NpbmcgdGhlIHN0YW5kYXJkIGxlZ2VuZCBmb3IgdGhlIFBZQU5H
IHRyZWU8L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iVGltZXMgTmV3IFJvbWFuIiBzaXplPSIzIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEycHQ7Ij4mbmJzcDs8L3NwYW4+PC9mb250PjwvZGl2Pg0K
PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExcHQ7Ij5KYXNvbjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IlRpbWVz
IE5ldyBSb21hbiIgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMnB0OyI+Jm5ic3A7
PC9zcGFuPjwvZm9udD48L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8L2Rpdj4NCjwvc3Bh
bj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_D950439A03E34C07A9572111CE8CDED9ciscocom_--


From nobody Tue Dec 22 11:42:02 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2C11A8ACA for ; Tue, 22 Dec 2015 11:42:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 urXW84BS9RXh for ; Tue, 22 Dec 2015 11:42:00 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAC251A8AC5 for ; Tue, 22 Dec 2015 11:41:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7962; q=dns/txt; s=iport; t=1450813320; x=1452022920; h=from:to:subject:date:message-id:mime-version; bh=e2k8UeINHQR6hPYuKNNuMdg9tgx6YeDlhsGFqhEd1kg=; b=m/a2DdtFBv05EOWe0FNBrK2VbL+hYjpdcBIIrxzJ0wPw3id+nAqoB6Wh GL7xOoEqmN6CBcdiWM1NT/K2AQmtyL4I4fhsc+Cs9dAe6LwK/1KtjMukm WP2BBGUGzOkLG3vXG9SX8tftJRrCkZXAOB3H5IeduiHYR8MQfj24IP352 o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A4AgCvpnlW/4cNJK1egm5MgT8GjEuxH?= =?us-ascii?q?wENgWOGDQIcgRU4FAEBAQEBAQGBCoQ0AQIEIwpeAQgRAwECFwEQAwIEMBQJCgQ?= =?us-ascii?q?BEogvrWqSLAEBAQEBAQEBAQEBAQEBAQEBAQEBARiGVoIPCIJohHcWEgGCUy+BG?= =?us-ascii?q?wWXAQGLAYJJgVyNHIpCg3MBIAEBQoQEcoNfBxcjAYEHAQEB?=
X-IronPort-AV: E=Sophos; i="5.20,465,1444694400"; d="scan'208,217"; a="61314563"
Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Dec 2015 19:41:59 +0000
Received: from XCH-RCD-014.cisco.com (xch-rcd-014.cisco.com [173.37.102.24]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tBMJfxjM016715 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Dec 2015 19:41:59 GMT
Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-014.cisco.com (173.37.102.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 22 Dec 2015 13:41:58 -0600
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.1104.009; Tue, 22 Dec 2015 13:41:58 -0600
From: "Clyde Wildes (cwildes)" 
To: "Sterne, Jason (Jason)" , "netmod@ietf.org" 
Thread-Topic: [netmod] syslog-model-05: terminal logging vs session logging
Thread-Index: AQHRPPDRO5QpmCKPG0KqLXCFC/hm5g==
Date: Tue, 22 Dec 2015 19:41:58 +0000
Message-ID: <85E75CA7-1889-419A-9DFE-C3CEFCC08644@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: [128.107.157.191]
Content-Type: multipart/alternative; boundary="_000_85E75CA71889419A9DFEC3CEFCC08644ciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] syslog-model-05: terminal logging vs session logging
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 19:42:01 -0000

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

SmFzb24sDQoNCldlIGFyZSBhYm91dCB0byBwdWJsaXNoIGRyYWZ0LWlldGYtbmV0bW9kLXN5c2xv
Zy0wNiB3aGljaCBzZXBhcmF0ZXMgdGVybWluYWwgbG9nZ2luZyBmcm9tIHNlc3Npb24gbG9nZ2lu
Zy4gV2UgYXBwcmVjaWF0ZSB5b3VyIGZlZWRiYWNrLg0KDQpUaGFua3MsDQoNCkNseWRlDQoNCkZy
b206IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1ib3VuY2Vz
QGlldGYub3JnPj4gb24gYmVoYWxmIG9mICJTdGVybmUsIEphc29uIChKYXNvbikiIDxqYXNvbi5z
dGVybmVAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzpqYXNvbi5zdGVybmVAYWxjYXRlbC1sdWNl
bnQuY29tPj4NCkRhdGU6IFdlZG5lc2RheSwgT2N0b2JlciAyOCwgMjAxNSBhdCAxMTo1MCBBTQ0K
VG86ICJuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4iIDxuZXRtb2RAaWV0
Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbbmV0bW9kXSBzeXNsb2ct
bW9kZWwtMDU6IHRlcm1pbmFsIGxvZ2dpbmcgdnMgc2Vzc2lvbiBsb2dnaW5nDQoNCkhpIGFsbCwN
Cg0KT25lIG9mIHRoZSBzeXNsb2cgZGVzdGluYXRpb25zIGluIHRoZSBtb2RlbCBpcyB0aGUg4oCc
dGVybWluYWzigJ0gKGZvciBhbGwgdXNlcnMgb3Igc3BlY2lmaWMgdXNlcnMpLg0KDQpJc27igJl0
IGxvZ2dpbmcgdG8gYSB0ZXJtaW5hbCBtb3JlIHR5cGljYWxseSBlbmFibGVkIG9uIGEgQ0xJICpz
ZXNzaW9uKiBiYXNpcyByYXRoZXIgdGhhbiBjb25maWd1cmVkIGFnYWluc3QgYSBwYXJ0aWN1bGFy
IHVzZXIgPw0KDQpJIGJlbGlldmUgaXQgaXMgYWxzbyB0eXBpY2FsIGZvciBzZXNzaW9uIGxvZ2dp
bmcgdG8gc3RvcC9kaXNhcHBlYXIgd2hlbiB0aGF0IHNlc3Npb24gaXMgZW5kZWQgKGkuZS4gaXQg
aXMgbm90IHBlcnNpc3RlbnQgY29uZmlnKS4NCg0KSeKAmW0gbm90IHN1cmUgaXQgaXMgdHlwaWNh
bCB0byBoYXZlIGNvbmZpZ3VyYXRpb24gaW4gYSBkZXZpY2UgdGhhdCBiYXNpY2FsbHkgaW5zdHJ1
Y3RzIHRoZSBkZXZpY2UgdG8gZW5hYmxlIGxvZ2dpbmcgdG8gdGhlIHRlcm1pbmFsIGZvciDigJx1
c2VyIHjigJ0gd2hlbmV2ZXIgdGhhdCB1c2VyIGxhdGVyIGxvZ3MgaW4gKGFuZCBpZiB0aGV5IGhh
ZCBtdWx0aXBsZSBsb2dpbiBzZXNzaW9ucyB0aGVuIHByZXN1bWFibHkgbG9nIGV2ZW50cyB3b3Vs
ZCBiZSBkZWxpdmVyZWQgdG8gZWFjaCBzZXNzaW9uKS4NCg0KSSB0aGluayBzZXNzaW9uIGxvZ2dp
bmcgaXMgc29tZXRoaW5nIHRoYXQgaXMgcmVhbGx5IHB1cmVseSBDTEkgKGkuZS4gaW50ZXJhY3Rp
dmUgc2Vzc2lvbnMgd2l0aCBodW1hbiB1c2VycykgYW5kIG1heWJlIG5vdCBldmVuIGFwcGxpY2Fi
bGUgdG8gY29uZmlndXJhdGlvbiB2aWEgTkVUQ09ORiAoc2luY2Ugd2XigJlkIG5ldmVyIHdhbnQg
dG8gc2VuZCBhIHN0cmVhbSBvZiBzeXNsb2cgZXZlbnRzIGFzIHRleHQgdG8gdGhlIE5FVENPTkYg
Y2xpZW50L3Nlc3Npb24gbGlrZSB3ZSBkbyB0byB0aGUgdGVybWluYWwgZm9yIGEgQ0xJIHVzZXIp
Lg0KDQpJbiBzZWN0aW9uIDUgb2YgdGhlIGRyYWZ0IGl0IG1lbnRpb25zIHRoYXQgc3lzbG9nOmxv
Zy1hY3Rpb25zL3Rlcm1pbmFsIG1hcHMgdG8gQ2lzY28gTlhPUyDigJxsb2dnaW5nIG1vbml0b3Ig
MuKAnS4gIEkgYmVsaWV2ZSB0aGF0IGlzIGludGVuZGVkIHRvIGVuYWJsZSBsb2dzIHRvIGEgcGFy
dGljdWxhciAqc2Vzc2lvbiogKG5vdCB1c2VyKS4gICBJT1MtWFIgYmVoYXZpb3IgaXMgc2ltaWxh
ci4gIFRoZSBBTFUgU1IgT1MgbG9nZ2luZyBjb25maWcgaGFzIHRoZSBjb25jZXB0IG9mIHNlbmRp
bmcgKGVuYWJsaW5nKSBsb2cgZXZlbnRzIHRvIGEgcGFydGljdWxhciBzZXNzaW9uIChidXQgbm90
IGNvbmZpZ3VyZWQgYWdhaW5zdCBhIHVzZXIpLg0KDQpKYXNvbg0KDQoNCg0K

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8
ZGl2Pkphc29uLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V2UgYXJlIGFib3V0IHRv
IHB1Ymxpc2ggZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLTA2IHdoaWNoIHNlcGFyYXRlcyB0ZXJt
aW5hbCBsb2dnaW5nIGZyb20gc2Vzc2lvbiBsb2dnaW5nLiBXZSBhcHByZWNpYXRlIHlvdXIgZmVl
ZGJhY2suPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2
Pjxicj4NCjwvZGl2Pg0KPGRpdj5DbHlkZTwvZGl2Pg0KPGRpdj4NCjxkaXYgaWQ9Ik1BQ19PVVRM
T09LX1NJR05BVFVSRSI+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4N
CjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZv
bnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMnB0OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9y
OmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBu
b25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElORy1SSUdI
VDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRp
dW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9s
ZCI+RnJvbTogPC9zcGFuPm5ldG1vZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1ib3VuY2Vz
QGlldGYub3JnIj5uZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiAm
cXVvdDtTdGVybmUsIEphc29uIChKYXNvbikmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpqYXNv
bi5zdGVybmVAYWxjYXRlbC1sdWNlbnQuY29tIj5qYXNvbi5zdGVybmVAYWxjYXRlbC1sdWNlbnQu
Y29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9z
cGFuPldlZG5lc2RheSwgT2N0b2JlciAyOCwgMjAxNSBhdCAxMTo1MCBBTTxicj4NCjxzcGFuIHN0
eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpu
ZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1h
aWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4g
c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5bbmV0bW9kXSBzeXNsb2ct
bW9kZWwtMDU6IHRlcm1pbmFsIGxvZ2dpbmcgdnMgc2Vzc2lvbiBsb2dnaW5nPGJyPg0KPC9kaXY+
DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu
dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt
LT48c3R5bGU+PCEtLSAuRW1haWxRdW90ZSB7IG1hcmdpbi1sZWZ0OiAxcHQ7IHBhZGRpbmctbGVm
dDogNHB0OyBib3JkZXItbGVmdDogIzgwMDAwMCAycHggc29saWQ7IH0gLS0+PC9zdHlsZT4NCjxk
aXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MXB0OyI+DQo8ZGl2PkhpIGFsbCw8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pk9uZSBv
ZiB0aGUgc3lzbG9nIGRlc3RpbmF0aW9ucyBpbiB0aGUgbW9kZWwgaXMgdGhlIOKAnHRlcm1pbmFs
4oCdIChmb3IgYWxsIHVzZXJzIG9yIHNwZWNpZmljIHVzZXJzKS48L2Rpdj4NCjxkaXY+Jm5ic3A7
PC9kaXY+DQo8ZGl2PklzbuKAmXQgbG9nZ2luZyB0byBhIHRlcm1pbmFsIG1vcmUgdHlwaWNhbGx5
IGVuYWJsZWQgb24gYSBDTEkgKjxiPnNlc3Npb248L2I+KiBiYXNpcyByYXRoZXIgdGhhbiBjb25m
aWd1cmVkIGFnYWluc3QgYSBwYXJ0aWN1bGFyIHVzZXIgPzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp
dj4NCjxkaXY+SSBiZWxpZXZlIGl0IGlzIGFsc28gdHlwaWNhbCBmb3Igc2Vzc2lvbiBsb2dnaW5n
IHRvIHN0b3AvZGlzYXBwZWFyIHdoZW4gdGhhdCBzZXNzaW9uIGlzIGVuZGVkIChpLmUuIGl0IGlz
IG5vdCBwZXJzaXN0ZW50IGNvbmZpZykuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5J
4oCZbSBub3Qgc3VyZSBpdCBpcyB0eXBpY2FsIHRvIGhhdmUgY29uZmlndXJhdGlvbiBpbiBhIGRl
dmljZSB0aGF0IGJhc2ljYWxseSBpbnN0cnVjdHMgdGhlIGRldmljZSB0byBlbmFibGUgbG9nZ2lu
ZyB0byB0aGUgdGVybWluYWwgZm9yIOKAnHVzZXIgeOKAnSB3aGVuZXZlciB0aGF0IHVzZXIgbGF0
ZXIgbG9ncyBpbiAoYW5kIGlmIHRoZXkgaGFkIG11bHRpcGxlIGxvZ2luIHNlc3Npb25zIHRoZW4g
cHJlc3VtYWJseSBsb2cgZXZlbnRzIHdvdWxkIGJlDQogZGVsaXZlcmVkIHRvIGVhY2ggc2Vzc2lv
bikuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JIHRoaW5rIHNlc3Npb24gbG9nZ2lu
ZyBpcyBzb21ldGhpbmcgdGhhdCBpcyByZWFsbHkgcHVyZWx5IENMSSAoaS5lLiBpbnRlcmFjdGl2
ZSBzZXNzaW9ucyB3aXRoIGh1bWFuIHVzZXJzKSBhbmQgbWF5YmUgbm90IGV2ZW4gYXBwbGljYWJs
ZSB0byBjb25maWd1cmF0aW9uIHZpYSBORVRDT05GIChzaW5jZSB3ZeKAmWQgbmV2ZXIgd2FudCB0
byBzZW5kIGEgc3RyZWFtIG9mIHN5c2xvZyBldmVudHMgYXMgdGV4dCB0byB0aGUgTkVUQ09ORiBj
bGllbnQvc2Vzc2lvbg0KIGxpa2Ugd2UgZG8gdG8gdGhlIHRlcm1pbmFsIGZvciBhIENMSSB1c2Vy
KS4mbmJzcDsgPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JbiBzZWN0aW9uIDUgb2Yg
dGhlIGRyYWZ0IGl0IG1lbnRpb25zIHRoYXQgc3lzbG9nOmxvZy1hY3Rpb25zL3Rlcm1pbmFsIG1h
cHMgdG8gQ2lzY28gTlhPUyDigJxsb2dnaW5nIG1vbml0b3IgMuKAnS4mbmJzcDsgSSBiZWxpZXZl
IHRoYXQgaXMgaW50ZW5kZWQgdG8gZW5hYmxlIGxvZ3MgdG8gYSBwYXJ0aWN1bGFyICo8Yj5zZXNz
aW9uPC9iPiogKG5vdCB1c2VyKS4mbmJzcDsmbmJzcDsgSU9TLVhSIGJlaGF2aW9yIGlzIHNpbWls
YXIuJm5ic3A7IFRoZSBBTFUgU1IgT1MgbG9nZ2luZw0KIGNvbmZpZyBoYXMgdGhlIGNvbmNlcHQg
b2Ygc2VuZGluZyAoZW5hYmxpbmcpIGxvZyBldmVudHMgdG8gYSBwYXJ0aWN1bGFyIHNlc3Npb24g
KGJ1dCBub3QgY29uZmlndXJlZCBhZ2FpbnN0IGEgdXNlcikuPC9kaXY+DQo8ZGl2PiZuYnNwOzwv
ZGl2Pg0KPGRpdj5KYXNvbjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9k
aXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPC9z
cGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_85E75CA71889419A9DFEC3CEFCC08644ciscocom_--


From nobody Tue Dec 22 11:46:20 2015
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 1D93C1A8AD3; Tue, 22 Dec 2015 11:46:19 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.11.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151222194619.20038.73500.idtracker@ietfa.amsl.com>
Date: Tue, 22 Dec 2015 11:46:19 -0800
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-syslog-model-06.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 19:46:19 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF.

        Title           : SYSLOG YANG model
        Author          : Clyde Wildes
	Filename        : draft-ietf-netmod-syslog-model-06.txt
	Pages           : 21
	Date            : 2015-12-22

Abstract:
   This document describes a data model for Syslog
   protocol which is used to convey event notification messages.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-06


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 Tue Dec 22 12:31:49 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C62C1A8F44 for ; Tue, 22 Dec 2015 12:31:48 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 8mw2LcXDgyEJ for ; Tue, 22 Dec 2015 12:31:44 -0800 (PST)
Received: from auth-4.ukservers.net (auth-4.ukservers.net [217.10.138.158]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B3B1A8F45 for ; Tue, 22 Dec 2015 12:31:43 -0800 (PST)
Received: from [192.168.0.33] (cpc13-heme10-2-0-cust400.9-1.cable.virginm.net [81.111.149.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by auth-4.ukservers.net (Postfix smtp) with ESMTPSA id 323793763380; Tue, 22 Dec 2015 20:31:38 +0000 (GMT)
To: Gert Grammel , "netmod@ietf.org" 
References:   <56784B33.30908@cisco.com> 
From: Robert Wilton 
Message-ID: <5679B32A.2040001@wilton.org.uk>
Date: Tue, 22 Dec 2015 20:31:38 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------060809090003020501020006"
Archived-At: 
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 20:31:48 -0000

This is a multi-part message in MIME format.
--------------060809090003020501020006
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Gert,

On 21/12/2015 20:17, Gert Grammel wrote:
> Hi Rob,
>
> Seems we are pretty close with our understanding, so snipping the only 
> discussion point left, with further comments:
>
> Gert
>
>
> 
>
>     The real problem is what you called in another email  'hybrid' or
>     cheating-synchronous implementations. This leads to a situation
>     where the client is made to believe the intended config is
>     applied, but the server still didn't apply it yet. Take the case
>     where the server runs into trouble after the synchronous-commit
>     (which lets the client believe that the intended config is
>     applied) and decides to roll-back. From a client perspective this
>     would look like a node randomly losing its committed
>     configuration. There is tons of code required on the client side
>     to cope with that situation. So what was the purpose of
>     implementing it that way in the first place - instead of just
>     applying an asynchronous implementation?
>
> Yes, I agree that handling rollback could be a problem in this scenario,
> and hence I would propose that the behaviour in such a scenario is
> explicitly documented as being undefined in whatever solution is agreed
> upon :-)
> Gert> sadly, we can’t roll time back. So the best option is indeed to 
> document the issue and move on to improve things
>
> Otherwise assuming that all requests are strictly synchronous or
> asynchronous then I think that we should be OK with the following two
> rules on the server:
>
>  1. All edit-config requests must strictly be processed in order.
>
> Gert> yes, although there are corner cases we need to hash out.  I.e. 
> a client may set  a leaf to  followed by setting it to . Then a 
> server may skip setting it to , because it is anyhow overwritten by 
> .

Yes, it might, but from a correctness point of view it will need to able 
to fail the subsequent request to set the value to  and hence set it 
to  instead.


>
> 2) You cannot tell a client that a request has been full applied unless
> all previous requests specifying rollback-on-error semantics with any
> overlapping nodes with the current request have either be applied or
> aborted (i.e. rolled back)
>
> Gert> with “have bee full applied” you meant a state that I 
> tentatively named ‘validated’  in my earlier email?  I am a bit 
> sensitive to naming here because of those ‘cheating synchronous nodes’ 
> would return ‘applied’ without actually doing so in full. It would be 
> great if we could quickly converge on some naming convention to remove 
> ambiguity.

Yes, it means the same state as your 'validated'.  I basically just mean 
that the synchronous operation has completed (as per the definition of 
'Synchronous Configuration Operation' defined in 
draft-ietf-netmod-opstate-reqs-01).




> The rule holds true but I don’t see a dependency on 
> “rollback-on-error” semantics. In my view it is applicable also in 
> cases of "continue-on-error” and “stop-on-error” in the sense that 
> unless any error has been reported, the client still needs to wait for 
> the ‘validated’ state before it can reliably assume the config was 
> applied.
I would see that a "continue-on-error" configuration operation is 
processed best effort.  I.e. even if applying one of more config nodes 
failed to be applied, the rest of the configuration contained in a best 
effort operation would always be applied.  As such subsequent operations 
would not need to wait for a best effort request to complete first 
before they can complete.

Thanks,
Rob


>
> 
>
> From: Robert Wilton >
> Date: Monday 21 December 2015 19:55
> To: Gert Grammel >, 
> Jason Sterne  >, "netmod@ietf.org 
> " >
> Subject: Re: [netmod] netmod-opstate-reqs and error option terms 
> (rollback on error)
>
> Hi Gert,
>
> Please see inline ...
>
> On 05/11/2015 03:53, Gert Grammel wrote:
>
>     Jason,
>
>     A synchronous config basically contains two pieces of information
>     in the commit:
>     1) the intended configuration is valid (i.e. is syntactically
>     correct) and
>     2) the intended config has been applied
>     Any error that would affect the config before the commit could be
>     rolled back to the old config and a suitable notification sent to
>     the client. After the commit, there is no roll-back.
>
> I agree.
>
>     Similarly for asynchronous, however here the information needs to
>     be split into two messages:
>     1) a commit that the intended config is valid
>     2) another message when the intended config is fully applied
>     (let's call this 'validated').
>     A rollback can happen before the intended config is fully applied
>     i.e. before the 'validated' state is reached.
>
> I agree.
>
>
>     The real problem is what you called in another email  'hybrid' or
>     cheating-synchronous implementations. This leads to a situation
>     where the client is made to believe the intended config is
>     applied, but the server still didn't apply it yet. Take the case
>     where the server runs into trouble after the synchronous-commit
>     (which lets the client believe that the intended config is
>     applied) and decides to roll-back. From a client perspective this
>     would look like a node randomly losing its committed
>     configuration. There is tons of code required on the client side
>     to cope with that situation. So what was the purpose of
>     implementing it that way in the first place - instead of just
>     applying an asynchronous implementation?
>
> Yes, I agree that handling rollback could be a problem in this scenario,
> and hence I would propose that the behaviour in such a scenario is
> explicitly documented as being undefined in whatever solution is agreed
> upon :-)
>
> Otherwise assuming that all requests are strictly synchronous or
> asynchronous then I think that we should be OK with the following two
> rules on the server:
> 1) All edit-config requests must strictly be processed in order.
> 2) You cannot tell a client that a request has been full applied unless
> all previous requests specifying rollback-on-error semantics with any
> overlapping nodes with the current request have either be applied or
> aborted (i.e. rolled back)
>
> Thanks,
> Rob
>
>
>
>     Gert
>
>
>
>
>     -----Original Message-----
>     From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Sterne,
>     Jason (Jason)
>     Sent: 03 November 2015 08:24
>     To: netmod@ietf.org 
>     Subject: [netmod] netmod-opstate-reqs and error option terms
>     (rollback on error)
>
>     Hi all,
>
>     The term "rollback on error" (and other error options) has been
>     used during these discussions around the opstate requirements.
>
>     That term already has some meaning in RFC6241 (or at least
>     rollback-on-error does and that is pretty close) and IMO it
>     (today) has nothing to do with "applied" config.  It is an error
>     option that has the scope of the contents of a single edit-config
>     request and how those contents get applied (all or nothing) to the
>     candidate DS (which is neither intended nor applied config) or to
>     the running DS (intended) if the  is .
>
>     I think we need to clarify this "all or nothing" concept and how
>     it is related to "applied" config.  We may also want to use
>     slightly different terminology so we don't get confused with
>     today's meaning of rollback-on-error.
>
>     There are a few transitions to consider when editing a config and
>     applying it to a device (I'll give the example of using the
>     candidate DS):
>     (A) config changes   ---> candidate DS ()
>     (B) candidate DS  ----> running (intended)  ()
>     (C) intended ----> applied  (internal processed in the device)
>
>     Today rollback-on-error is only applicable to transition (A).
>
>     Transition (B) does have all-or-nothing properties (as described
>     in RFC6241) but that isn't related to "rollback-on-error".
>
>     Is there some intention in the opstate requirements to add some
>     sort of all-or-nothing behavior to transition (C) ?  i.e. if some
>     part of an edit fails during the transition from intended->applied
>     we should "rollback" the other parts that may have already been
>     applied ?
>
>     Would we then remove it all from intended as well ?
>
>     I'm not sure how that would work for an async/hybrid (read "real")
>     system.  We've already done an "ack" back to the client before
>     transition (C) so the client may have already sent some additional
>     new config that depends on the previous edit.  That would mean
>     that new config isn't valid.
>
>     Jason
>
>     _______________________________________________
>     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


--------------060809090003020501020006
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Gert,

      

      On 21/12/2015 20:17, Gert Grammel wrote:

    

    

      
      
Hi Rob,

      


      

      
Seems we are pretty close with our understanding, so snipping
        the only discussion point left, with further comments:

      


      

      
Gert

      


      

      


      

      
<snip>

      

        

          The real problem is what you called in another email  'hybrid'
          or cheating-synchronous implementations. This leads to a
          situation where the client is made to believe the intended
          config is applied, but the server still didn't apply it yet.
          Take the case where the server runs into trouble after the
          synchronous-commit (which lets the client believe that the
          intended config is applied) and decides to roll-back. From a
          client perspective this would look like a node randomly losing
          its committed configuration. There is tons of code required on
          the client side to cope with that situation. So what was the
          purpose of implementing it that way in the first place -
          instead of just applying an asynchronous implementation?

        
Yes, I agree that handling rollback could be a problem in
          this scenario, 

        
and hence I would propose that the behaviour in such a
          scenario is 

        
explicitly documented as being undefined in whatever
          solution is agreed 

        
upon :-)

        
Gert> sadly, we can’t roll time back. So the best option
          is indeed to document the issue and move on to improve things

        


        

        
Otherwise assuming that all requests are strictly
          synchronous or 

        
asynchronous then I think that we should be OK with the
          following two 

        
rules on the server:

        
    
          
  1. All edit-config requests must strictly be processed in
            order.
    2. 
        

        
Gert> yes, although there are corner cases we need to
          hash out.  I.e. a client may set  a leaf to <x> followed
          by setting it to <y>. Then a server may skip setting it
          to <x>, because it is anyhow overwritten by <y>.

      

    

    

    Yes, it might, but from a correctness point of view it will need to
    able to fail the subsequent request to set the value to <y>
    and hence set it to <x> instead.

    

    

    

      

        


        

        
2) You cannot tell a client that a request has been full
          applied unless 

        
all previous requests specifying rollback-on-error
          semantics with any 

        
overlapping nodes with the current request have either be
          applied or 

        
aborted (i.e. rolled back)

      

      


      

      
Gert> with “have bee full applied” you meant a state that
        I tentatively named ‘validated’  in my earlier email?  I am a
        bit sensitive to naming here because of those ‘cheating
        synchronous nodes’ would return ‘applied’ without actually doing
        so in full. It would be great if we could quickly converge on
        some naming convention to remove ambiguity.

    

    

    Yes, it means the same state as your 'validated'.  I basically just
    mean that the synchronous operation has completed (as per the
    definition of 'Synchronous Configuration Operation' defined in
    draft-ietf-netmod-opstate-reqs-01).

    

    

    

    

    

      
The rule holds true but I don’t see a dependency on
        “rollback-on-error” semantics. In my view it is applicable also
        in cases of "continue-on-error” and “stop-on-error” in the sense
        that unless any error has been reported, the client still needs
        to wait for the ‘validated’ state before it can reliably assume
        the config was applied.

    

    I would see that a "continue-on-error" configuration operation is
    processed best effort.  I.e. even if applying one of more config
    nodes failed to be applied, the rest of the configuration contained
    in a best effort operation would always be applied.  As such
    subsequent operations would not need to wait for a best effort
    request to complete first before they can complete. 

    

    Thanks,

    Rob

    

    

    

      

        


        

      

      
<snip>

      


      

      
        

          From: Robert Wilton
          <rwilton@cisco.com>

          Date: Monday 21
          December 2015 19:55

          To: Gert Grammel <ggrammel@juniper.net>,
          Jason Sterne <jason.sterne@alcatel-lucent.com>,
          "netmod@ietf.org"
          <netmod@ietf.org>

          Subject: Re: [netmod]
          netmod-opstate-reqs and error option terms (rollback on error)

        

        


        

        

          

            
Hi Gert,

            


            

            
Please see inline ...

            


            

            
On 05/11/2015 03:53, Gert Grammel wrote:

            

              
Jason,

              


              

              
A synchronous config basically contains two pieces of
                information in the commit:

              
1)
                the intended configuration is valid (i.e. is
                syntactically correct) and

              
2)
                the intended config has been applied

              
Any error that would affect the config before the
                commit could be rolled back to the old config and a
                suitable notification sent to the client. After the
                commit, there is no roll-back.

            

            
I agree.

            


            

            

              
Similarly for asynchronous, however here the
                information needs to be split into two messages:

              
1)
                a commit that the intended config is valid

              
2)
                another message when the intended config is fully
                applied (let's call this 'validated').

              
A rollback can happen before the intended config is
                fully applied i.e. before the 'validated' state is
                reached.

            

            
I agree.

            


            

            

              


              

              
The real problem is what you called in another
                email  'hybrid' or cheating-synchronous implementations.
                This leads to a situation where the client is made to
                believe the intended config is applied, but the server
                still didn't apply it yet. Take the case where the
                server runs into trouble after the synchronous-commit
                (which lets the client believe that the intended config
                is applied) and decides to roll-back. From a client
                perspective this would look like a node randomly losing
                its committed configuration. There is tons of code
                required on the client side to cope with that situation.
                So what was the purpose of implementing it that way in
                the first place - instead of just applying an
                asynchronous implementation?

            

            
Yes, I agree that handling rollback could be a problem
              in this scenario, 

            
and hence I would propose that the behaviour in such a
              scenario is 

            
explicitly documented as being undefined in whatever
              solution is agreed 

            
upon :-)

            


            

            
Otherwise assuming that all requests are strictly
              synchronous or 

            
asynchronous then I think that we should be OK with the
              following two 

            
rules on the server:

            
1) All edit-config requests must strictly be processed
              in order.

            
2) You cannot tell a client that a request has been
              full applied unless 

            
all previous requests specifying rollback-on-error
              semantics with any 

            
overlapping nodes with the current request have either
              be applied or 

            
aborted (i.e. rolled back)

            


            

            
Thanks,

            
Rob

            


            

            


            

            

              


              

              
Gert

              


              

              


              

              


              

              


              

              
-----Original Message-----

              
From: netmod [mailto:netmod-bounces@ietf.org]
                On Behalf Of Sterne, Jason (Jason)

              
Sent: 03 November 2015 08:24

              
              
Subject: [netmod] netmod-opstate-reqs and error
                option terms (rollback on error)

              


              

              
Hi all,

              


              

              
The term "rollback on error" (and other error
                options) has been used during these discussions around
                the opstate requirements.

              


              

              
That term already has some meaning in RFC6241 (or at
                least rollback-on-error does and that is pretty close)
                and IMO it (today) has nothing to do with "applied"
                config.  It is an error option that has the scope of the
                contents of a single edit-config request and how those
                contents get applied (all or nothing) to the candidate
                DS (which is neither intended nor applied config) or to
                the running DS (intended) if the <target> is
                <running/>.

              


              

              
I think we need to clarify this "all or nothing"
                concept and how it is related to "applied" config.  We
                may also want to use slightly different terminology so
                we don't get confused with today's meaning of
                rollback-on-error.

              


              

              
There are a few transitions to consider when editing
                a config and applying it to a device (I'll give the
                example of using the candidate DS):

              
(A) config changes   ---> candidate DS  
                (<edit-config>)

              
(B) candidate DS  ----> running
                (intended)  (<commit>)

              
(C) intended ----> applied  (internal processed in
                the device)

              


              

              
Today rollback-on-error is only applicable to
                transition (A).

              


              

              
Transition (B) does have all-or-nothing properties
                (as described in RFC6241) but that isn't related to
                "rollback-on-error".

              


              

              
Is there some intention in the opstate requirements
                to add some sort of all-or-nothing behavior to
                transition (C) ?  i.e. if some part of an edit fails
                during the transition from intended->applied we
                should "rollback" the other parts that may have already
                been applied ?

              


              

              
Would we then remove it all from intended as well ?

              


              

              
I'm not sure how that would work for an async/hybrid
                (read "real") system.  We've already done an "ack" back
                to the client before transition (C) so the client may
                have already sent some additional new config that
                depends on the previous edit.  That would mean that new
                config isn't valid.

              


              

              
Jason

              


              

              
_______________________________________________

              
netmod mailing list

              
              
              


              

              
_______________________________________________

              
netmod mailing list

              
              
              
.

              


              

            

            


            

            


            

          

        

      
      

      

      

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


    

    

  


--------------060809090003020501020006--


From nobody Tue Dec 22 12:37:47 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB451A8F4F for ; Tue, 22 Dec 2015 12:37:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 dmzSNLXcFSjo for ; Tue, 22 Dec 2015 12:37:43 -0800 (PST)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 60DA31A8F4D for ; Tue, 22 Dec 2015 12:37:42 -0800 (PST)
Received: by mail-lf0-x232.google.com with SMTP id y184so135942838lfc.1 for ; Tue, 22 Dec 2015 12:37:42 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=ldJwv0s1A1/0IiaWw1ePMDfKsz0v6qqAezU//DeOGc4=; b=foeBUqkBnd3j9WVUnoowS0yJIPnIDmbYCfT79PZrYrlE/8DWc18npqNK14z2sKsQj+ PcUylORR+YYjt8+EZm86neXoQ1yNEIY0OO+qwtEOaqKJhd18/Cqm865XNEPVMlOXH4od FSWfe+TOZQLmnEZA3D5W1ZKdchzBxd4gCv6nChKfKm9tYEQf0SMOWmlHX7v6J5lqrWV3 4sY59FIMPMzlt7YFSFYBOHhK/pm3uC+N+2dR65f2fueDTatjpGbb/FW/F1wSJOY3bpk7 RC5+djLnFgmZd5TGCZo9fOQb+4QMPXPmxAnz5njhDfIfPFja5vyo4SKzEeeLu5JBdVIS 5igg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ldJwv0s1A1/0IiaWw1ePMDfKsz0v6qqAezU//DeOGc4=; b=j1c8tSf5NveTVgU0GqMXWPaCRuUwbwVs9GGbAqY4LNa9rJV++uuvFXJZRqOZ/+x09Q pJcCofg40MH/6QhciDIq6NlK1el/PkLRC50S9BvSvLy31baiB+Vzf+obIB5M4cUvrNuR Npt/2UVoVYz5tbGq7a29K/T87BP0vtSnu8yu6+YGysfxh/ALygttgtH7aHvaB4UBE/rL lr6eXsszvPiYJRL5hs1sQyIRuQwFM1pxdrUyaO1slKLdC/HKaC53Pu5JaXykc1G/shLk fXKjjN35Khv7RkQWodzbK4iDkOcMo3G057KFBJxwo28wU1PN94+JklUINlRj1aq2dEY/ rbhA==
X-Gm-Message-State: ALoCoQnfDihWaLWLWv/c1Nj9eRTgfVxnYk6+m21GgBxA6CS0iUjW0ZZzO7eQ7qwO8ioIn6Et4zAF5dHyG/UOyiz1Mz5CuT2OEg==
MIME-Version: 1.0
X-Received: by 10.25.218.9 with SMTP id r9mr9302762lfg.138.1450816660465; Tue, 22 Dec 2015 12:37:40 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Tue, 22 Dec 2015 12:37:40 -0800 (PST)
In-Reply-To: <5679B32A.2040001@wilton.org.uk>
References:   <56784B33.30908@cisco.com>  <5679B32A.2040001@wilton.org.uk>
Date: Tue, 22 Dec 2015 12:37:40 -0800
Message-ID: 
From: Andy Bierman 
To: Robert Wilton 
Content-Type: multipart/alternative; boundary=001a11402600ae887005278293b6
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 20:37:46 -0000

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

On Tue, Dec 22, 2015 at 12:31 PM, Robert Wilton  wrote:

> Hi Gert,
>
> On 21/12/2015 20:17, Gert Grammel wrote:
>
> Hi Rob,
>
> Seems we are pretty close with our understanding, so snipping the only
> discussion point left, with further comments:
>
> Gert
>
>
> 
>
> The real problem is what you called in another email  'hybrid' or
> cheating-synchronous implementations. This leads to a situation where the
> client is made to believe the intended config is applied, but the server
> still didn't apply it yet. Take the case where the server runs into troub=
le
> after the synchronous-commit (which lets the client believe that the
> intended config is applied) and decides to roll-back. From a client
> perspective this would look like a node randomly losing its committed
> configuration. There is tons of code required on the client side to cope
> with that situation. So what was the purpose of implementing it that way =
in
> the first place - instead of just applying an asynchronous implementation=
?
>
> Yes, I agree that handling rollback could be a problem in this scenario,
> and hence I would propose that the behaviour in such a scenario is
> explicitly documented as being undefined in whatever solution is agreed
> upon :-)
> Gert> sadly, we can=E2=80=99t roll time back. So the best option is indee=
d to
> document the issue and move on to improve things
>
> Otherwise assuming that all requests are strictly synchronous or
> asynchronous then I think that we should be OK with the following two
> rules on the server:
>
>    1. All edit-config requests must strictly be processed in order.
>
> Gert> yes, although there are corner cases we need to hash out.  I.e. a
> client may set  a leaf to  followed by setting it to . Then a serve=
r
> may skip setting it to , because it is anyhow overwritten by .
>
>
> Yes, it might, but from a correctness point of view it will need to able
> to fail the subsequent request to set the value to  and hence set it t=
o
>  instead.
>
>


What does "processed in order" mean?
NETCONF has a requirement that  requests on a specific session
are processed in the order received.  There is no such requirement
across multiple sessions doing edits at once.


Andy




>
>
> 2) You cannot tell a client that a request has been full applied unless
> all previous requests specifying rollback-on-error semantics with any
> overlapping nodes with the current request have either be applied or
> aborted (i.e. rolled back)
>
> Gert> with =E2=80=9Chave bee full applied=E2=80=9D you meant a state that=
 I tentatively
> named =E2=80=98validated=E2=80=99  in my earlier email?  I am a bit sensi=
tive to naming
> here because of those =E2=80=98cheating synchronous nodes=E2=80=99 would =
return =E2=80=98applied=E2=80=99
> without actually doing so in full. It would be great if we could quickly
> converge on some naming convention to remove ambiguity.
>
>
> Yes, it means the same state as your 'validated'.  I basically just mean
> that the synchronous operation has completed (as per the definition of
> 'Synchronous Configuration Operation' defined in
> draft-ietf-netmod-opstate-reqs-01).
>
>
>
>
> The rule holds true but I don=E2=80=99t see a dependency on =E2=80=9Croll=
back-on-error=E2=80=9D
> semantics. In my view it is applicable also in cases of "continue-on-erro=
r=E2=80=9D
> and =E2=80=9Cstop-on-error=E2=80=9D in the sense that unless any error ha=
s been reported,
> the client still needs to wait for the =E2=80=98validated=E2=80=99 state =
before it can
> reliably assume the config was applied.
>
> I would see that a "continue-on-error" configuration operation is
> processed best effort.  I.e. even if applying one of more config nodes
> failed to be applied, the rest of the configuration contained in a best
> effort operation would always be applied.  As such subsequent operations
> would not need to wait for a best effort request to complete first before
> they can complete.
>
> Thanks,
> Rob
>
>
>
> 
>
> From: Robert Wilton 
> Date: Monday 21 December 2015 19:55
> To: Gert Grammel < ggrammel@juniper.net>, Jason
> Sterne , "netmod@ietf.org" <
> netmod@ietf.org>
> Subject: Re: [netmod] netmod-opstate-reqs and error option terms
> (rollback on error)
>
> Hi Gert,
>
> Please see inline ...
>
> On 05/11/2015 03:53, Gert Grammel wrote:
>
> Jason,
>
> A synchronous config basically contains two pieces of information in the
> commit:
> 1) the intended configuration is valid (i.e. is syntactically correct) an=
d
> 2) the intended config has been applied
> Any error that would affect the config before the commit could be rolled
> back to the old config and a suitable notification sent to the client.
> After the commit, there is no roll-back.
>
> I agree.
>
> Similarly for asynchronous, however here the information needs to be spli=
t
> into two messages:
> 1) a commit that the intended config is valid
> 2) another message when the intended config is fully applied (let's call
> this 'validated').
> A rollback can happen before the intended config is fully applied i.e.
> before the 'validated' state is reached.
>
> I agree.
>
>
> The real problem is what you called in another email  'hybrid' or
> cheating-synchronous implementations. This leads to a situation where the
> client is made to believe the intended config is applied, but the server
> still didn't apply it yet. Take the case where the server runs into troub=
le
> after the synchronous-commit (which lets the client believe that the
> intended config is applied) and decides to roll-back. From a client
> perspective this would look like a node randomly losing its committed
> configuration. There is tons of code required on the client side to cope
> with that situation. So what was the purpose of implementing it that way =
in
> the first place - instead of just applying an asynchronous implementation=
?
>
> Yes, I agree that handling rollback could be a problem in this scenario,
> and hence I would propose that the behaviour in such a scenario is
> explicitly documented as being undefined in whatever solution is agreed
> upon :-)
>
> Otherwise assuming that all requests are strictly synchronous or
> asynchronous then I think that we should be OK with the following two
> rules on the server:
> 1) All edit-config requests must strictly be processed in order.
> 2) You cannot tell a client that a request has been full applied unless
> all previous requests specifying rollback-on-error semantics with any
> overlapping nodes with the current request have either be applied or
> aborted (i.e. rolled back)
>
> Thanks,
> Rob
>
>
>
> Gert
>
>
>
>
> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org ]
> On Behalf Of Sterne, Jason (Jason)
> Sent: 03 November 2015 08:24
> To: netmod@ietf.org
> Subject: [netmod] netmod-opstate-reqs and error option terms (rollback on
> error)
>
> Hi all,
>
> The term "rollback on error" (and other error options) has been used
> during these discussions around the opstate requirements.
>
> That term already has some meaning in RFC6241 (or at least
> rollback-on-error does and that is pretty close) and IMO it (today) has
> nothing to do with "applied" config.  It is an error option that has the
> scope of the contents of a single edit-config request and how those
> contents get applied (all or nothing) to the candidate DS (which is neith=
er
> intended nor applied config) or to the running DS (intended) if the
>  is .
>
> I think we need to clarify this "all or nothing" concept and how it is
> related to "applied" config.  We may also want to use slightly different
> terminology so we don't get confused with today's meaning of
> rollback-on-error.
>
> There are a few transitions to consider when editing a config and applyin=
g
> it to a device (I'll give the example of using the candidate DS):
> (A) config changes   ---> candidate DS   ()
> (B) candidate DS  ----> running (intended)  ()
> (C) intended ----> applied  (internal processed in the device)
>
> Today rollback-on-error is only applicable to transition (A).
>
> Transition (B) does have all-or-nothing properties (as described in
> RFC6241) but that isn't related to "rollback-on-error".
>
> Is there some intention in the opstate requirements to add some sort of
> all-or-nothing behavior to transition (C) ?  i.e. if some part of an edit
> fails during the transition from intended->applied we should "rollback" t=
he
> other parts that may have already been applied ?
>
> Would we then remove it all from intended as well ?
>
> I'm not sure how that would work for an async/hybrid (read "real")
> system.  We've already done an "ack" back to the client before transition
> (C) so the client may have already sent some additional new config that
> depends on the previous edit.  That would mean that new config isn't vali=
d.
>
> Jason
>
> _______________________________________________
> 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 listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/n=
etmod
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

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




On Tue, Dec 22, 2015 at 12:31 PM, Robert Wilton <<=
a href=3D"mailto:robert.public@wilton.org.uk" target=3D"_blank">robert.publ=
ic@wilton.org.uk> wrote:

 =20
   =20
 =20
  

    
Hi Gert,

      

      On 21/12/2015 20:17, Gert Grammel wrote:

    

    

     =20
      
Hi Rob,

      


      

      
Seems we are pretty close with our understanding, so snipping
        the only discussion point left, with further comments:

      


      

      
Gert

      


      

      


      

      
<snip>

      

        

          The real problem is what you called in another email=C2=A0=C2=A0&=
#39;hybrid'
          or cheating-synchronous implementations. This leads to a
          situation where the client is made to believe the intended
          config is applied, but the server still didn't apply it yet.
          Take the case where the server runs into trouble after the
          synchronous-commit (which lets the client believe that the
          intended config is applied) and decides to roll-back. From a
          client perspective this would look like a node randomly losing
          its committed configuration. There is tons of code required on
          the client side to cope with that situation. So what was the
          purpose of implementing it that way in the first place -
          instead of just applying an asynchronous implementation?
        
Yes, I agree that handling rollback could be a problem in
          this scenario,=C2=A0

        
and hence I would propose that the behaviour in such a
          scenario is=C2=A0

        
explicitly documented as being undefined in whatever
          solution is agreed=C2=A0

        
upon :-)

        
Gert> sadly, we can=E2=80=99t roll time back. So the best o=
ption
          is indeed to document the issue and move on to improve things
        


        

        
Otherwise assuming that all requests are strictly
          synchronous or=C2=A0

        
asynchronous then I think that we should be OK with the
          following two=C2=A0

        
rules on the server:

        
    
          
  1. All edit-config requests must strictly be processed in
            order.
    2. 
        

        
Gert> yes, although there are corner cases we need to
          hash out.=C2=A0 I.e. a client may set =C2=A0a leaf to <x> f=
ollowed
          by setting it to <y>. Then a server may skip setting it
          to <x>, because it is anyhow overwritten by <y>.
      

    

    

    Yes, it might, but from a correctness point of view it will need to
    able to fail the subsequent request to set the value to <y>
    and hence set it to <x> instead.

    



What does "processed in order" mean?
NETCONF has a re=
quirement that <rpc> requests on a specific session
are pro=
cessed in the order received.=C2=A0 There is no such requirement
=
across multiple sessions doing edits at once.


=

Andy


=C2=A0

    

    

      

        


        

        
2) You cannot tell a client that a request has been full
          applied unless=C2=A0

        
all previous requests specifying rollback-on-error
          semantics with any=C2=A0

        
overlapping nodes with the current request have either be
          applied or=C2=A0

        
aborted (i.e. rolled back)

      

      


      

      
Gert> with =E2=80=9Chave bee full applied=E2=80=9D you meant =
a state that
        I tentatively named =E2=80=98validated=E2=80=99 =C2=A0in my earlier=
 email?=C2=A0 I am a
        bit sensitive to naming here because of those =E2=80=98cheating
        synchronous nodes=E2=80=99 would return =E2=80=98applied=E2=80=99 w=
ithout actually doing
        so in full. It would be great if we could quickly converge on
        some naming convention to remove ambiguity.

    

    

    Yes, it means the same state as your 'validated'.=C2=A0 I basic=
ally just
    mean that the synchronous operation has completed (as per the
    definition of 'Synchronous Configuration Operation' defined in
    draft-ietf-netmod-opstate-reqs-01).

    

    

    

    

    

      
The rule holds true but I don=E2=80=99t see a dependency on
        =E2=80=9Crollback-on-error=E2=80=9D semantics. In my view it is app=
licable also
        in cases of "continue-on-error=E2=80=9D and =E2=80=9Cstop-on-e=
rror=E2=80=9D in the sense
        that unless any error has been reported, the client still needs
        to wait for the =E2=80=98validated=E2=80=99 state before it can rel=
iably assume
        the config was applied.

    

    I would see that a "continue-on-error" configuration operatio=
n is
    processed best effort.=C2=A0 I.e. even if applying one of more config
    nodes failed to be applied, the rest of the configuration contained
    in a best effort operation would always be applied.=C2=A0 As such
    subsequent operations would not need to wait for a best effort
    request to complete first before they can complete. 

    

    Thanks,

    Rob

    

    

    

      

        


        

      

      
<snip>

      


      

      
        

          From: Robert Wilton
          <rwilto=
n@cisco.com>

          Date: Monday 21
          December 2015 19:55

          To: Gert Grammel <ggrammel@juniper.net>,
          Jason Sterne <jason.sterne@alcatel-lucent.com>,
          "netmod=
@ietf.org"
          <netmod@i=
etf.org>

          Subject: Re: [netmod]
          netmod-opstate-reqs and error option terms (rollback on error)
        

        


        

        

          

            
Hi Gert,

            


            

            
Please see inline ...

            


            

            
On 05/11/2015 03:53, Gert Grammel wrote:

            

              
Jason,

              


              

              
A synchronous config basically contains two pieces of
                information in the commit:

              
1)
                the intended configuration is valid (i.e. is
                syntactically correct) and

              
2)
                the intended config has been applied

              
Any error that would affect the config before the
                commit could be rolled back to the old config and a
                suitable notification sent to the client. After the
                commit, there is no roll-back.

            

            
I agree.

            


            

            

              
Similarly for asynchronous, however here the
                information needs to be split into two messages:

              
1)
                a commit that the intended config is valid

              
2)
                another message when the intended config is fully
                applied (let's call this 'validated').

              
A rollback can happen before the intended config is
                fully applied i.e. before the 'validated' state is
                reached.

            

            
I agree.

            


            

            

              


              

              
The real problem is what you called in another
                email=C2=A0=C2=A0'hybrid' or cheating-synchronous i=
mplementations.
                This leads to a situation where the client is made to
                believe the intended config is applied, but the server
                still didn't apply it yet. Take the case where the
                server runs into trouble after the synchronous-commit
                (which lets the client believe that the intended config
                is applied) and decides to roll-back. From a client
                perspective this would look like a node randomly losing
                its committed configuration. There is tons of code
                required on the client side to cope with that situation.
                So what was the purpose of implementing it that way in
                the first place - instead of just applying an
                asynchronous implementation?

            

            
Yes, I agree that handling rollback could be a problem
              in this scenario, 

            
and hence I would propose that the behaviour in such a
              scenario is 

            
explicitly documented as being undefined in whatever
              solution is agreed 

            
upon :-)

            


            

            
Otherwise assuming that all requests are strictly
              synchronous or 

            
asynchronous then I think that we should be OK with the
              following two 

            
rules on the server:

            
1) All edit-config requests must strictly be processed
              in order.

            
2) You cannot tell a client that a request has been
              full applied unless 

            
all previous requests specifying rollback-on-error
              semantics with any 

            
overlapping nodes with the current request have either
              be applied or 

            
aborted (i.e. rolled back)

            


            

            
Thanks,

            
Rob

            


            

            


            

            

              


              

              
Gert

              


              

              


              

              


              

              


              

              
-----Original Message-----

              
From: netmod [mailto:netmod-bounces@ietf.org]
                On Behalf Of Sterne, Jason (Jason)

              
Sent: 03 November 2015 08:24

              
              
Subject: [netmod] netmod-opstate-reqs and error
                option terms (rollback on error)

              


              

              
Hi all,

              


              

              
The term "rollback on error" (and other error
                options) has been used during these discussions around
                the opstate requirements.

              


              

              
That term already has some meaning in RFC6241 (or at
                least rollback-on-error does and that is pretty close)
                and IMO it (today) has nothing to do with "applied&quo=
t;
                config.=C2=A0=C2=A0It is an error option that has the scope=
 of the
                contents of a single edit-config request and how those
                contents get applied (all or nothing) to the candidate
                DS (which is neither intended nor applied config) or to
                the running DS (intended) if the <target> is
                <running/>.

              


              

              
I think we need to clarify this "all or nothing&quo=
t;
                concept and how it is related to "applied" config=
.=C2=A0=C2=A0We
                may also want to use slightly different terminology so
                we don't get confused with today's meaning of
                rollback-on-error.

              


              

              
There are a few transitions to consider when editing
                a config and applying it to a device (I'll give the
                example of using the candidate DS):

              
(A) config changes=C2=A0=C2=A0 ---> candidate DS=C2=
=A0=C2=A0
                (<edit-config>)

              
(B) candidate DS=C2=A0=C2=A0----> running
                (intended)=C2=A0=C2=A0(<commit>)

              
(C) intended ----> applied=C2=A0=C2=A0(internal proce=
ssed in
                the device)

              


              

              
Today rollback-on-error is only applicable to
                transition (A).

              


              

              
Transition (B) does have all-or-nothing properties
                (as described in RFC6241) but that isn't related to
                "rollback-on-error".

              


              

              
Is there some intention in the opstate requirements
                to add some sort of all-or-nothing behavior to
                transition (C) ?=C2=A0=C2=A0i.e. if some part of an edit fa=
ils
                during the transition from intended->applied we
                should "rollback" the other parts that may have a=
lready
                been applied ?

              


              

              
Would we then remove it all from intended as well ?
              


              

              
I'm not sure how that would work for an async/hybrid
                (read "real") system.=C2=A0=C2=A0We've alread=
y done an "ack" back
                to the client before transition (C) so the client may
                have already sent some additional new config that
                depends on the previous edit.=C2=A0=C2=A0That would mean th=
at new
                config isn't valid.

              


              

              
Jason

              


              

              
_______________________________________________

              
netmod mailing list

              
              
              


              

              
_______________________________________________

              
netmod mailing list

              
              
              
.

              


              

            

            


            

            


            

          

        

      
      

      

      

      
_______________________________________________
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





--001a11402600ae887005278293b6--


From nobody Tue Dec 22 13:37:26 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61CB41A9089 for ; Tue, 22 Dec 2015 13:37:25 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 vZGVISYxYuj4 for ; Tue, 22 Dec 2015 13:37:21 -0800 (PST)
Received: from auth-3.ukservers.net (auth-3.ukservers.net [217.10.138.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE141A9086 for ; Tue, 22 Dec 2015 13:37:20 -0800 (PST)
Received: from [192.168.0.33] (cpc13-heme10-2-0-cust400.9-1.cable.virginm.net [81.111.149.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by auth-3.ukservers.net (Postfix smtp) with ESMTPSA id C7B381721627; Tue, 22 Dec 2015 21:37:16 +0000 (GMT)
To: Andy Bierman 
References:   <56784B33.30908@cisco.com>  <5679B32A.2040001@wilton.org.uk> 
From: Robert Wilton 
Message-ID: <5679C28D.8040306@wilton.org.uk>
Date: Tue, 22 Dec 2015 21:37:17 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030406070706030402060708"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 21:37:25 -0000

This is a multi-part message in MIME format.
--------------030406070706030402060708
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

HI Andy,

On 22/12/2015 20:37, Andy Bierman wrote:
>
>
> On Tue, Dec 22, 2015 at 12:31 PM, Robert Wilton 
> > wrote:
>
>     Hi Gert,
>
>     On 21/12/2015 20:17, Gert Grammel wrote:
>>     Hi Rob,
>>
>>     Seems we are pretty close with our understanding, so snipping the
>>     only discussion point left, with further comments:
>>
>>     Gert
>>
>>
>>     
>>
>>         The real problem is what you called in another
>>         email  'hybrid' or cheating-synchronous implementations. This
>>         leads to a situation where the client is made to believe the
>>         intended config is applied, but the server still didn't apply
>>         it yet. Take the case where the server runs into trouble
>>         after the synchronous-commit (which lets the client believe
>>         that the intended config is applied) and decides to
>>         roll-back. From a client perspective this would look like a
>>         node randomly losing its committed configuration. There is
>>         tons of code required on the client side to cope with that
>>         situation. So what was the purpose of implementing it that
>>         way in the first place - instead of just applying an
>>         asynchronous implementation?
>>
>>     Yes, I agree that handling rollback could be a problem in this
>>     scenario,
>>     and hence I would propose that the behaviour in such a scenario is
>>     explicitly documented as being undefined in whatever solution is
>>     agreed
>>     upon :-)
>>     Gert> sadly, we can’t roll time back. So the best option is
>>     indeed to document the issue and move on to improve things
>>
>>     Otherwise assuming that all requests are strictly synchronous or
>>     asynchronous then I think that we should be OK with the following
>>     two
>>     rules on the server:
>>
>>      1. All edit-config requests must strictly be processed in order.
>>
>>     Gert> yes, although there are corner cases we need to hash out. 
>>     I.e. a client may set  a leaf to  followed by setting it to
>>     . Then a server may skip setting it to , because it is
>>     anyhow overwritten by .
>
>     Yes, it might, but from a correctness point of view it will need
>     to able to fail the subsequent request to set the value to  and
>     hence set it to  instead.
>
>
>
>
> What does "processed in order" mean?
> NETCONF has a requirement that  requests on a specific session
> are processed in the order received.  There is no such requirement
> across multiple sessions doing edits at once.

Thanks for the clarification.  I hope that whatever NETCONF does here 
should be a sufficient solution.  I.e. as long as the error handling 
semantics can be well defined with the request ordering just defined 
relative to particular sessions then that is fine with me.  I think that 
it would only be necessary to refine/modify the NETCONF behaviour if it 
is shown to be insufficiently specified to be robustly implementable, 
and I'm not aware of that being the case.

Otherwise, I think that this discussion can probably be deferred until 
we are discussing the specific solution draft.

As an aside - I also see this as another example where it would be 
useful to define the common semantics and expectations of a YANG 
manageability protocol outside of NETCONF and RESTCONF.

Thanks,
Rob


>
>
> Andy
>
>
>
>>
>>     2) You cannot tell a client that a request has been full applied
>>     unless
>>     all previous requests specifying rollback-on-error semantics with
>>     any
>>     overlapping nodes with the current request have either be applied or
>>     aborted (i.e. rolled back)
>>
>>     Gert> with “have bee full applied†you meant a state that I
>>     tentatively named ‘validated’  in my earlier email?  I am a bit
>>     sensitive to naming here because of those ‘cheating synchronous
>>     nodes’ would return ‘applied’ without actually doing so in full.
>>     It would be great if we could quickly converge on some naming
>>     convention to remove ambiguity.
>
>     Yes, it means the same state as your 'validated'.  I basically
>     just mean that the synchronous operation has completed (as per the
>     definition of 'Synchronous Configuration Operation' defined in
>     draft-ietf-netmod-opstate-reqs-01).
>
>
>
>
>>     The rule holds true but I don’t see a dependency on
>>     “rollback-on-error†semantics. In my view it is applicable also
>>     in cases of "continue-on-error†and “stop-on-error†in the sense
>>     that unless any error has been reported, the client still needs
>>     to wait for the ‘validated’ state before it can reliably assume
>>     the config was applied.
>     I would see that a "continue-on-error" configuration operation is
>     processed best effort.  I.e. even if applying one of more config
>     nodes failed to be applied, the rest of the configuration
>     contained in a best effort operation would always be applied.  As
>     such subsequent operations would not need to wait for a best
>     effort request to complete first before they can complete.
>
>     Thanks,
>     Rob
>
>
>>
>>     
>>
>>     From: Robert Wilton >
>>     Date: Monday 21 December 2015 19:55
>>     To: Gert Grammel >     >, Jason Sterne
>>     >     >, "netmod@ietf.org
>>     " >
>>     Subject: Re: [netmod] netmod-opstate-reqs and error option terms
>>     (rollback on error)
>>
>>     Hi Gert,
>>
>>     Please see inline ...
>>
>>     On 05/11/2015 03:53, Gert Grammel wrote:
>>
>>         Jason,
>>
>>         A synchronous config basically contains two pieces of
>>         information in the commit:
>>         1) the intended configuration is valid (i.e. is syntactically
>>         correct) and
>>         2) the intended config has been applied
>>         Any error that would affect the config before the commit
>>         could be rolled back to the old config and a suitable
>>         notification sent to the client. After the commit, there is
>>         no roll-back.
>>
>>     I agree.
>>
>>         Similarly for asynchronous, however here the information
>>         needs to be split into two messages:
>>         1) a commit that the intended config is valid
>>         2) another message when the intended config is fully applied
>>         (let's call this 'validated').
>>         A rollback can happen before the intended config is fully
>>         applied i.e. before the 'validated' state is reached.
>>
>>     I agree.
>>
>>
>>         The real problem is what you called in another
>>         email  'hybrid' or cheating-synchronous implementations. This
>>         leads to a situation where the client is made to believe the
>>         intended config is applied, but the server still didn't apply
>>         it yet. Take the case where the server runs into trouble
>>         after the synchronous-commit (which lets the client believe
>>         that the intended config is applied) and decides to
>>         roll-back. From a client perspective this would look like a
>>         node randomly losing its committed configuration. There is
>>         tons of code required on the client side to cope with that
>>         situation. So what was the purpose of implementing it that
>>         way in the first place - instead of just applying an
>>         asynchronous implementation?
>>
>>     Yes, I agree that handling rollback could be a problem in this
>>     scenario,
>>     and hence I would propose that the behaviour in such a scenario is
>>     explicitly documented as being undefined in whatever solution is
>>     agreed
>>     upon :-)
>>
>>     Otherwise assuming that all requests are strictly synchronous or
>>     asynchronous then I think that we should be OK with the following
>>     two
>>     rules on the server:
>>     1) All edit-config requests must strictly be processed in order.
>>     2) You cannot tell a client that a request has been full applied
>>     unless
>>     all previous requests specifying rollback-on-error semantics with
>>     any
>>     overlapping nodes with the current request have either be applied or
>>     aborted (i.e. rolled back)
>>
>>     Thanks,
>>     Rob
>>
>>
>>
>>         Gert
>>
>>
>>
>>
>>         -----Original Message-----
>>         From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of
>>         Sterne, Jason (Jason)
>>         Sent: 03 November 2015 08:24
>>         To: netmod@ietf.org 
>>         Subject: [netmod] netmod-opstate-reqs and error option terms
>>         (rollback on error)
>>
>>         Hi all,
>>
>>         The term "rollback on error" (and other error options) has
>>         been used during these discussions around the opstate
>>         requirements.
>>
>>         That term already has some meaning in RFC6241 (or at least
>>         rollback-on-error does and that is pretty close) and IMO it
>>         (today) has nothing to do with "applied" config.  It is an
>>         error option that has the scope of the contents of a single
>>         edit-config request and how those contents get applied (all
>>         or nothing) to the candidate DS (which is neither intended
>>         nor applied config) or to the running DS (intended) if the
>>          is .
>>
>>         I think we need to clarify this "all or nothing" concept and
>>         how it is related to "applied" config.  We may also want to
>>         use slightly different terminology so we don't get confused
>>         with today's meaning of rollback-on-error.
>>
>>         There are a few transitions to consider when editing a config
>>         and applying it to a device (I'll give the example of using
>>         the candidate DS):
>>         (A) config changes   ---> candidate DS   ()
>>         (B) candidate DS  ----> running (intended)  ()
>>         (C) intended ----> applied  (internal processed in the device)
>>
>>         Today rollback-on-error is only applicable to transition (A).
>>
>>         Transition (B) does have all-or-nothing properties (as
>>         described in RFC6241) but that isn't related to
>>         "rollback-on-error".
>>
>>         Is there some intention in the opstate requirements to add
>>         some sort of all-or-nothing behavior to transition (C)
>>         ?  i.e. if some part of an edit fails during the transition
>>         from intended->applied we should "rollback" the other parts
>>         that may have already been applied ?
>>
>>         Would we then remove it all from intended as well ?
>>
>>         I'm not sure how that would work for an async/hybrid (read
>>         "real") system.  We've already done an "ack" back to the
>>         client before transition (C) so the client may have already
>>         sent some additional new config that depends on the previous
>>         edit.  That would mean that new config isn't valid.
>>
>>         Jason
>>
>>         _______________________________________________
>>         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
>
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org 
>     https://www.ietf.org/mailman/listinfo/netmod
>
>


--------------030406070706030402060708
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
HI Andy,

      

      On 22/12/2015 20:37, Andy Bierman wrote:

    

    

      


        


          
On Tue, Dec 22, 2015 at 12:31 PM,
            Robert Wilton <robert.public@wilton.org.uk>
            wrote:

            

              

                
Hi Gert,

                  

                  On 21/12/2015 20:17, Gert Grammel wrote:

                

                

                  
Hi Rob,

                  


                  

                  
Seems we are pretty close with our understanding,
                    so snipping the only discussion point left, with
                    further comments:

                  


                  

                  
Gert

                  


                  

                  


                  

                  
<snip>

                  

                    
 The real
                      problem is what you called in another
                      email  'hybrid' or cheating-synchronous
                      implementations. This leads to a situation where
                      the client is made to believe the intended config
                      is applied, but the server still didn't apply it
                      yet. Take the case where the server runs into
                      trouble after the synchronous-commit (which lets
                      the client believe that the intended config is
                      applied) and decides to roll-back. From a client
                      perspective this would look like a node randomly
                      losing its committed configuration. There is tons
                      of code required on the client side to cope with
                      that situation. So what was the purpose of
                      implementing it that way in the first place -
                      instead of just applying an asynchronous
                      implementation?

                    
Yes, I agree that handling rollback could be a
                      problem in this scenario, 

                    
and hence I would propose that the behaviour in
                      such a scenario is 

                    
explicitly documented as being undefined in
                      whatever solution is agreed 

                    
upon :-)

                    
Gert> sadly, we can’t roll time back. So the
                      best option is indeed to document the issue and
                      move on to improve things

                    


                    

                    
Otherwise assuming that all requests are
                      strictly synchronous or 

                    
asynchronous then I think that we should be OK
                      with the following two 

                    
rules on the server:

                    
    
                      
  1. All edit-config requests must strictly be
                        processed in order.
    2. 
                    

                    
Gert> yes, although there are corner cases
                      we need to hash out.  I.e. a client may set  a
                      leaf to <x> followed by setting it to
                      <y>. Then a server may skip setting it to
                      <x>, because it is anyhow overwritten by
                      <y>.

                  

                

                

                Yes, it might, but from a correctness point of view it
                will need to able to fail the subsequent request to set
                the value to <y> and hence set it to <x>
                instead.

                

              

            

            


            

            


            

            


            

            
What does "processed in order" mean?

            
NETCONF has a requirement that <rpc> requests on
              a specific session

            
are processed in the order received.  There is no such
              requirement

            
across multiple sessions doing edits at once.

          

        

      

    

    

    Thanks for the clarification.  I hope that whatever NETCONF does
    here should be a sufficient solution.  I.e. as long as the error
    handling semantics can be well defined with the request ordering
    just defined relative to particular sessions then that is fine with
    me.  I think that it would only be necessary to refine/modify the
    NETCONF behaviour if it is shown to be insufficiently specified to
    be robustly implementable, and I'm not aware of that being the case.

    

    Otherwise, I think that this discussion can probably be deferred
    until we are discussing the specific solution draft.

    

    As an aside - I also see this as another example where it would be
    useful to define the common semantics and expectations of a YANG
    manageability protocol outside of NETCONF and RESTCONF.

    

    Thanks,

    Rob

    

    

    

      

        

          

            


            

            


            

            
Andy

            


            

            


            

            
 

            

              
 

                

                  

                    


                    

                    
2) You cannot tell a client that a request has
                      been full applied unless 

                    
all previous requests specifying
                      rollback-on-error semantics with any 

                    
overlapping nodes with the current request have
                      either be applied or 

                    
aborted (i.e. rolled back)

                  

                  


                  

                  
Gert> with “have bee full applied†you meant a
                    state that I tentatively named ‘validated’  in my
                    earlier email?  I am a bit sensitive to naming here
                    because of those ‘cheating synchronous nodes’ would
                    return ‘applied’ without actually doing so in full.
                    It would be great if we could quickly converge on
                    some naming convention to remove ambiguity.

                

                

                Yes, it means the same state as your 'validated'.  I
                basically just mean that the synchronous operation has
                completed (as per the definition of 'Synchronous
                Configuration Operation' defined in
                draft-ietf-netmod-opstate-reqs-01).

                

                

                

                

                

                  
The rule holds true but I don’t see a dependency
                    on “rollback-on-error†semantics. In my view it is
                    applicable also in cases of "continue-on-error†and
                    “stop-on-error†in the sense that unless any error
                    has been reported, the client still needs to wait
                    for the ‘validated’ state before it can reliably
                    assume the config was applied.

                

                I would see that a "continue-on-error" configuration
                operation is processed best effort.  I.e. even if
                applying one of more config nodes failed to be applied,
                the rest of the configuration contained in a best effort
                operation would always be applied.  As such subsequent
                operations would not need to wait for a best effort
                request to complete first before they can complete. 

                

                Thanks,

                Rob

                

                

                

                  

                    


                    

                  

                  
<snip>

                  


                  

                  
                    
 From: Robert
                      Wilton <rwilton@cisco.com>

                      Date: Monday
                      21 December 2015 19:55

                      To: Gert
                      Grammel <ggrammel@juniper.net>,
                      Jason Sterne <jason.sterne@alcatel-lucent.com>,

                      "netmod@ietf.org"
                      <netmod@ietf.org>

                      Subject: Re:
                      [netmod] netmod-opstate-reqs and error option
                      terms (rollback on error)

                    

                    


                    

                    

                      

                        
Hi Gert,

                        


                        

                        
Please see inline ...

                        


                        

                        
On 05/11/2015 03:53, Gert Grammel wrote:

                        

                          
Jason,

                          


                          

                          
A synchronous config basically contains
                            two pieces of information in the commit:

                          
1)

                            the intended configuration is valid (i.e. is
                            syntactically correct) and

                          
2)

                            the intended config has been applied

                          
Any error that would affect the config
                            before the commit could be rolled back to
                            the old config and a suitable notification
                            sent to the client. After the commit, there
                            is no roll-back.

                        

                        
I agree.

                        


                        

                        

                          
Similarly for asynchronous, however here
                            the information needs to be split into two
                            messages:

                          
1)

                            a commit that the intended config is valid

                          
2)

                            another message when the intended config is
                            fully applied (let's call this 'validated').

                          
A rollback can happen before the intended
                            config is fully applied i.e. before the
                            'validated' state is reached.

                        

                        
I agree.

                        


                        

                        

                          


                          

                          
The real problem is what you called in
                            another email  'hybrid' or
                            cheating-synchronous implementations. This
                            leads to a situation where the client is
                            made to believe the intended config is
                            applied, but the server still didn't apply
                            it yet. Take the case where the server runs
                            into trouble after the synchronous-commit
                            (which lets the client believe that the
                            intended config is applied) and decides to
                            roll-back. From a client perspective this
                            would look like a node randomly losing its
                            committed configuration. There is tons of
                            code required on the client side to cope
                            with that situation. So what was the purpose
                            of implementing it that way in the first
                            place - instead of just applying an
                            asynchronous implementation?

                        

                        
Yes, I agree that handling rollback could
                          be a problem in this scenario, 

                        
and hence I would propose that the
                          behaviour in such a scenario is 

                        
explicitly documented as being undefined in
                          whatever solution is agreed 

                        
upon :-)

                        


                        

                        
Otherwise assuming that all requests are
                          strictly synchronous or 

                        
asynchronous then I think that we should be
                          OK with the following two 

                        
rules on the server:

                        
1) All edit-config requests must strictly
                          be processed in order.

                        
2) You cannot tell a client that a request
                          has been full applied unless 

                        
all previous requests specifying
                          rollback-on-error semantics with any 

                        
overlapping nodes with the current request
                          have either be applied or 

                        
aborted (i.e. rolled back)

                        


                        

                        
Thanks,

                        
Rob

                        


                        

                        


                        

                        

                          


                          

                          
Gert

                          


                          

                          


                          

                          


                          

                          


                          

                          
-----Original Message-----

                          
From: netmod [mailto:netmod-bounces@ietf.org]
                            On Behalf Of Sterne, Jason (Jason)

                          
Sent: 03 November 2015 08:24

                          
                          
Subject: [netmod] netmod-opstate-reqs and
                            error option terms (rollback on error)

                          


                          

                          
Hi all,

                          


                          

                          
The term "rollback on error" (and other
                            error options) has been used during these
                            discussions around the opstate requirements.

                          


                          

                          
That term already has some meaning in
                            RFC6241 (or at least rollback-on-error does
                            and that is pretty close) and IMO it (today)
                            has nothing to do with "applied" config.  It
                            is an error option that has the scope of the
                            contents of a single edit-config request and
                            how those contents get applied (all or
                            nothing) to the candidate DS (which is
                            neither intended nor applied config) or to
                            the running DS (intended) if the
                            <target> is <running/>.

                          


                          

                          
I think we need to clarify this "all or
                            nothing" concept and how it is related to
                            "applied" config.  We may also want to use
                            slightly different terminology so we don't
                            get confused with today's meaning of
                            rollback-on-error.

                          


                          

                          
There are a few transitions to consider
                            when editing a config and applying it to a
                            device (I'll give the example of using the
                            candidate DS):

                          
(A) config changes   ---> candidate
                            DS   (<edit-config>)

                          
(B) candidate DS  ----> running
                            (intended)  (<commit>)

                          
(C) intended ----> applied  (internal
                            processed in the device)

                          


                          

                          
Today rollback-on-error is only
                            applicable to transition (A).

                          


                          

                          
Transition (B) does have all-or-nothing
                            properties (as described in RFC6241) but
                            that isn't related to "rollback-on-error".

                          


                          

                          
Is there some intention in the opstate
                            requirements to add some sort of
                            all-or-nothing behavior to transition (C)
                            ?  i.e. if some part of an edit fails during
                            the transition from intended->applied we
                            should "rollback" the other parts that may
                            have already been applied ?

                          


                          

                          
Would we then remove it all from intended
                            as well ?

                          


                          

                          
I'm not sure how that would work for an
                            async/hybrid (read "real") system.  We've
                            already done an "ack" back to the client
                            before transition (C) so the client may have
                            already sent some additional new config that
                            depends on the previous edit.  That would
                            mean that new config isn't valid.

                          


                          

                          
Jason

                          


                          

                          
_______________________________________________

                          
netmod mailing list

                          
                          
                          


                          

                          
_______________________________________________

                          
netmod mailing list

                          
                          
                          
.

                          


                          

                        

                        


                        

                        


                        

                      

                    

                   

                  

                  

                  
_______________________________________________
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

              

            

          

          

        

      

    

    

  


--------------030406070706030402060708--


From nobody Tue Dec 22 13:57:38 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9921A90D5 for ; Tue, 22 Dec 2015 13:57:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.361
X-Spam-Level: 
X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 ip-t9dLgk1H6 for ; Tue, 22 Dec 2015 13:57:34 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02F141A90D3 for ; Tue, 22 Dec 2015 13:57:34 -0800 (PST)
Received: from [IPv6:2a01:5e0:29:ffff:5dcc:3821:70e7:db11] (unknown [IPv6:2a01:5e0:29:ffff:5dcc:3821:70e7:db11]) by mail.nic.cz (Postfix) with ESMTPSA id 7F3D218030A; Tue, 22 Dec 2015 22:57:32 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450821452; bh=9qSUiUluc0cUUsYUdlb6Ym/fxu8XOQOgYpbPGra3PRs=; h=From:Date:To; b=RbJ/ySO2E/+s7wNS2vfWJ/hJvKyIMQV2UkQeIAef3vz6xB8uO69fcb91k8YeoZDC3 VjYrsk6gDTrlP1uXjtdfZUkBB+Ds5e/Qer1FdwPZva+Fi3YxXj4QyFyIpm2EW33Fc7 Vo3Fk/OqZQ8UAe2mHclRY6T2fGFILi02l2fRiKC8=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <20151222155356.GA45865@elstar.local>
Date: Tue, 22 Dec 2015 22:57:35 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <078F52F6-9BD8-4BA8-B0D2-D628A4ECD22C@nic.cz>
References: <20151221144723.GA43211@elstar.local> <5E9674F3-DDAB-479F-A8CA-0CF78FE5F1F2@nic.cz> <20151221154054.GB43316@elstar.local> <82E7F91B-9DC4-4E8A-B042-A87B21683283@nic.cz> <20151221190439.GA44038@elstar.local>  <20151222100634.GB45259@elstar.local> <3DC4E3CB-9250-4A32-BD7A-8759CC027CC7@nic.cz> <20151222150654.GA45756@elstar.local>  <20151222155356.GA45865@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] module update rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 22 Dec 2015 21:57:37 -0000

> On 22 Dec 2015, at 16:53, Juergen Schoenwaelder =
 wrote:
>=20
> On Tue, Dec 22, 2015 at 04:23:44PM +0100, Ladislav Lhotka wrote:
>>=20
>>> On 22 Dec 2015, at 16:06, Juergen Schoenwaelder =
 wrote:
>>>=20
>>> On Tue, Dec 22, 2015 at 11:34:41AM +0100, Ladislav Lhotka wrote:
>>>>=20
>>>>> On 22 Dec 2015, at 11:06, Juergen Schoenwaelder =
 wrote:
>>>>>=20
>>>>> On Mon, Dec 21, 2015 at 08:09:13PM +0100, Ladislav Lhotka wrote:
>>>>>>=20
>>>>>>>=20
>>>>>>> That's why the definition what 'published' means in the IETF is =
in the
>>>>>>> guidelines document. On the other hand, since this is an IETF
>>>>>>> document, I also do not find it problematic to define IETF rules
>>>>>>> here. Others should be able to skip over this. There are really =
more
>>>>>>> important problems to solve.
>>>>>>=20
>>>>>> It is not clear at all from sec. 10 that data modellers outside =
IETF may skip over this. I am not even sure that everybody in this WG =
agrees with your interpretation.
>>>>>>=20
>>>>>=20
>>>>> You are wrong.
>>>>>=20
>>>>> - Section 10 in RFC 6020 applies to all published modules.
>>>>=20
>>>> The bullets specifying the rules are introduced with this sentence:
>>>>=20
>>>> 'A definition may be revised in any of the following ways:'
>>>>=20
>>>> so IMO it is intended to apply to *all* modules. Are you saying =
that it actually means
>>>>=20
>>>> 'A definition in a module published by IETF may be revised in any =
of the following ways:'?
>>>>=20
>>>=20
>>> A definition in a published module may be revised [...]
>>>=20
>>>>> - The definition of what turns a module into a published module is
>>>>> specific to the different organizations publishing modules.
>>>>=20
>>>> So it means that such an organization may also decide to ignore the =
rules entirely or replace them with its own rules.
>>>>=20
>>>=20
>>> No.
>>>=20
>>>> If the WG can agree on this and make the corresponding changes in =
sec. 11 of 6020bis, then I have no more objections.
>>>=20
>>> The rules are there to ensure interoperability. Interoperability is =
an
>>> issue for published modules (but not for modules under development).
>>=20
>> This doesn't make much sense unless you give an objective definition =
of "published". For example, are proprietary modules (developed by =
vendors) ever published?
>>=20
>=20
> This has to be late binding - an organization publishing modules will
> have to define what 'publishing' means for them and they will have to
> decide whether they publish anything at all.

Right. Should there ever be any malcontents who are not happy with those =
rules, here is a recipe: they can provide the modules to their customers =
instead of publishing them. And W3C could just recommend their modules.

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Tue Dec 22 18:41:40 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214941A90B2 for ; Tue, 22 Dec 2015 18:41:40 -0800 (PST)
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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 uheq6Ovo4Lhb for ; Tue, 22 Dec 2015 18:41:36 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0108.outbound.protection.outlook.com [207.46.100.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B53931A90B0 for ; Tue, 22 Dec 2015 18:41:36 -0800 (PST)
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (TLS) id 15.1.361.13; Wed, 23 Dec 2015 02:41:34 +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.0361.006; Wed, 23 Dec 2015 02:41:34 +0000
From: Kent Watsen 
To: Robert Wilton , "Sterne, Jason (Jason)" , "netmod@ietf.org" 
Thread-Topic: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
Thread-Index: AQHRPCF5wOz/ziSgLkOMFH9D1Q78057Xis8A
Date: Wed, 23 Dec 2015 02:41:34 +0000
Message-ID: <327E370C-4D5F-4F9A-B982-B71108CEBC08@juniper.net>
References:  <56784B9B.5020408@cisco.com>
In-Reply-To: <56784B9B.5020408@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.151105
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.12]
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 5:cLcgkQlVxyIMT+yyreuO0s+JlFzPtfaDjbWA374BAJoGLrcKglTp9qNUgdUDoXTq20e9nREJqVGkRlvrsl5IG0uHISzyiMc8WbzdfvrlcqQKZeLXXkStC29L+siqsVq0gtmrYl8UWE7c3evsUKDOtw==; 24:p768m8XwXPFgzYMJLOdq8iHgyl5LQgQP1AZMG1dcB/OVzMsP5dOZ0gEH+PpH/f+/mtitjyEV090/MHUQ4Zh4A7Rm9okV+9RBfRbYYwKShdk=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1441;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; 
x-forefront-prvs: 0799B1B2D7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(189002)(377454003)(164054003)(479174004)(51444003)(199003)(53754006)(81156007)(11100500001)(50986999)(86362001)(5008740100001)(10400500002)(92566002)(66066001)(586003)(2900100001)(15975445007)(77096005)(2950100001)(5004730100002)(101416001)(1096002)(1220700001)(36756003)(2501003)(3846002)(6116002)(102836003)(99286002)(230783001)(82746002)(5002640100001)(40100003)(97736004)(122556002)(19580395003)(76176999)(5001770100001)(107886002)(33656002)(54356999)(106356001)(189998001)(87936001)(106116001)(4001350100001)(19580405001)(83716003)(5001960100002)(83506001)(105586002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; 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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <199BC011BE2FEF4EA7901B2DFD9AADC2@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Dec 2015 02:41:34.6399 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441
Archived-At: 
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2015 02:41:40 -0000

W0FzIGEgY29udHJpYnV0b3JdDQoNCkhpIFJvYmVydCwgSSB3YW50IHRvIGdvIGJhY2sgdG8gSmFz
b27igJlzIG9yaWdpbmFsIHF1ZXN0aW9ucy4gIEkgdGhpbmsgd2XigJlyZSBhbGlnbmVkIG9uIHRo
aXMsIGJ1dCBwbGVhc2UgY2hlY2sgbXkgYW5zd2VycyBiZWxvdy4gIA0KDQpRdW90aW5nIEphc29u
4oCZcyBvcmlnaW5hbCB0ZXh0IG5vdzoNCg0KDQo+SXMgdGhlcmUgc29tZSBpbnRlbnRpb24gaW4g
dGhlIG9wc3RhdGUgcmVxdWlyZW1lbnRzIHRvIGFkZCBzb21lIHNvcnQNCj5vZiBhbGwtb3Itbm90
aGluZyBiZWhhdmlvciB0byB0cmFuc2l0aW9uIChDKT8NCg0KWWVzDQoNCg0KPmkuZS4gaWYgc29t
ZSBwYXJ0IG9mDQo+YW4gZWRpdCBmYWlscyBkdXJpbmcgdGhlIHRyYW5zaXRpb24gZnJvbSBpbnRl
bmRlZC0+YXBwbGllZCB3ZSBzaG91bGQNCj4icm9sbGJhY2siIHRoZSBvdGhlciBwYXJ0cyB0aGF0
IG1heSBoYXZlIGFscmVhZHkgYmVlbiBhcHBsaWVkID8NCg0KWWVzDQoNCg0KPldvdWxkIHdlIHRo
ZW4gcmVtb3ZlIGl0IGFsbCBmcm9tIGludGVuZGVkIGFzIHdlbGwgPw0KDQpJTU8sIHllcy4gIFRo
aXMgaXMgbW9yZSBlYXNpbHkgdW5kZXJzdG9vZCB3aGVuIHRoaW5raW5nIGFib3V0IFN5bmNocm9u
b3VzIENvbmZpZ3VyYXRpb24gT3BlcmF0aW9ucyAoZGVmaW5lZCBpbiBvcHN0YXRlLXJlcXMpLCBi
dXQgSSBiZWxpZXZlIHRoYXQgaXQgZXF1YWxseSBhcHBsaWVzIHRvIEFzeW5jaHJvbm91cyBDb25m
aWd1cmF0aW9uIE9wZXJhdGlvbnMsIHNvIGxvbmcgYXMgdGhlIGNsaWVudCBleHBsaWNpdGx5IG9w
cy1pbiBmb3IgdGhlIGJlaGF2aW9yLg0KDQoNCj5JJ20gbm90IHN1cmUgaG93IHRoYXQgd291bGQg
d29yayBmb3IgYW4gYXN5bmMvaHlicmlkIChyZWFkICJyZWFs4oCdKQ0KPnN5c3RlbS4gIFdlJ3Zl
IGFscmVhZHkgZG9uZSBhbiAiYWNrIiBiYWNrIHRvIHRoZSBjbGllbnQgYmVmb3JlIA0KPnRyYW5z
aXRpb24gKEMpIHNvIHRoZSBjbGllbnQgbWF5IGhhdmUgYWxyZWFkeSBzZW50IHNvbWUgYWRkaXRp
b25hbA0KPm5ldyBjb25maWcgdGhhdCBkZXBlbmRzIG9uIHRoZSBwcmV2aW91cyBlZGl0LiAgVGhh
dCB3b3VsZCBtZWFuIHRoYXQNCj5uZXcgY29uZmlnIGlzbid0IHZhbGlkLg0KDQpJ4oCZbSBub3Qg
YSBmYW4gb24gdGhlIOKAnGh5YnJpZOKAnSB0ZXJtLCBidXQgaW4gdGhpbmtpbmcgYWJvdXQgbGVn
YWN5IG9yIGV4aXN0aW5nIE5FVENPTkYgc2VydmVycywgSSB0aGluayB0aGF0IHRoaXMgaXMgYSBu
b24taXNzdWUgYXMgdGhlIHNlcnZlciB3b3VsZG7igJl0IGFkdmVydGlzZSBzdXBwb3J0IGZvciBS
b2xsYmFjayBvbiBFcnJvciBpbiB0aGUgZmlyc3QgcGxhY2UuDQoNCg0KS2VudA0KDQoNCg0KDQoN
Ck9uIDEyLzIxLzE1LCAxOjU3IFBNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBSb2JlcnQgV2lsdG9u
IiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHJ3aWx0b25AY2lzY28uY29t
PiB3cm90ZToNCg0KPkhpIEphc29uLA0KPg0KPlBpY2tpbmcgdXAgdGhpcyBzbGlnaHRseSBvbGQg
dGhyZWFkLg0KPg0KPlRoZSAicm9sbGJhY2sgb24gZXJyb3IiIGRlZmluaXRpb24gdGhhdCBJIGFk
ZGVkIEkgdG9vayBkaXJlY3RseSBmcm9tIA0KPlJGQzYyNDEsIHNvIGl0J3MgZ29vZCB0aGF0IHRo
ZXkgbG9vayBzaW1pbGFyLiAgVGhlIGludGVudGlvbiBpcyB0aGF0IHRoZSANCj5ORVRDT05GICJy
b2xsYmFjay1vbi1lcnJvciIgY2FwYWJpbGl0eSBpcyBhIHZhbGlkIGltcGxlbWVudGF0aW9uIG9m
IHRoaXMgDQo+cmVxdWlyZW1lbnQgOi0pDQo+DQo+SSB0aGluayB0aGF0IHRoZSAgcm9sbGJhY2st
b24tZXJyb3IgY2FwYWJpbGl0eSBkZWZpbmVkIGluIFJGQzYyNDEgY2FuIA0KPmFsc28gYmUgYXBw
bGllZCB0byB0aGUgcnVubmluZyBkYXRhc3RvcmUuICBDZXJ0YWlubHksIHRoZSBleGFtcGxlIHF1
b3RlZCANCj5pcyBpbiB0aGUgY29udGV4dCBvZiB0aGUgZWRpdC1jb25maWcgcmVxdWVzdCBvbiB0
aGUgcnVubmluZy1jb25maWcgDQo+ZGF0YXN0b3JlLCBhbmQgdGhlIFJGQyBkZXNjcmlwdGlvbiBv
ZiB0aGlzIGZlYXR1cmUgZG9lc24ndCBhcHBlYXIgdG8gDQo+bGltaXQgaXQgdG8gdGhlIGNhbmRp
ZGF0ZSBkYXRhc3RvcmUgaW4gYW55IHdheS4NCj4NCj5UaGFua3MsDQo+Um9iDQo+DQo+DQo+T24g
MDMvMTEvMjAxNSAwNzoyMywgU3Rlcm5lLCBKYXNvbiAoSmFzb24pIHdyb3RlOg0KPj4gSGkgYWxs
LA0KPj4NCj4+IFRoZSB0ZXJtICJyb2xsYmFjayBvbiBlcnJvciIgKGFuZCBvdGhlciBlcnJvciBv
cHRpb25zKSBoYXMgYmVlbiB1c2VkIGR1cmluZyB0aGVzZSBkaXNjdXNzaW9ucyBhcm91bmQgdGhl
IG9wc3RhdGUgcmVxdWlyZW1lbnRzLg0KPj4NCj4+IFRoYXQgdGVybSBhbHJlYWR5IGhhcyBzb21l
IG1lYW5pbmcgaW4gUkZDNjI0MSAob3IgYXQgbGVhc3Qgcm9sbGJhY2stb24tZXJyb3IgZG9lcyBh
bmQgdGhhdCBpcyBwcmV0dHkgY2xvc2UpIGFuZCBJTU8gaXQgKHRvZGF5KSBoYXMgbm90aGluZyB0
byBkbyB3aXRoICJhcHBsaWVkIiBjb25maWcuICBJdCBpcyBhbiBlcnJvciBvcHRpb24gdGhhdCBo
YXMgdGhlIHNjb3BlIG9mIHRoZSBjb250ZW50cyBvZiBhIHNpbmdsZSBlZGl0LWNvbmZpZyByZXF1
ZXN0IGFuZCBob3cgdGhvc2UgY29udGVudHMgZ2V0IGFwcGxpZWQgKGFsbCBvciBub3RoaW5nKSB0
byB0aGUgY2FuZGlkYXRlIERTICh3aGljaCBpcyBuZWl0aGVyIGludGVuZGVkIG5vciBhcHBsaWVk
IGNvbmZpZykgb3IgdG8gdGhlIHJ1bm5pbmcgRFMgKGludGVuZGVkKSBpZiB0aGUgPHRhcmdldD4g
aXMgPHJ1bm5pbmcvPi4NCj4+DQo+PiBJIHRoaW5rIHdlIG5lZWQgdG8gY2xhcmlmeSB0aGlzICJh
bGwgb3Igbm90aGluZyIgY29uY2VwdCBhbmQgaG93IGl0IGlzIHJlbGF0ZWQgdG8gImFwcGxpZWQi
IGNvbmZpZy4gIFdlIG1heSBhbHNvIHdhbnQgdG8gdXNlIHNsaWdodGx5IGRpZmZlcmVudCB0ZXJt
aW5vbG9neSBzbyB3ZSBkb24ndCBnZXQgY29uZnVzZWQgd2l0aCB0b2RheSdzIG1lYW5pbmcgb2Yg
cm9sbGJhY2stb24tZXJyb3IuDQo+Pg0KPj4gVGhlcmUgYXJlIGEgZmV3IHRyYW5zaXRpb25zIHRv
IGNvbnNpZGVyIHdoZW4gZWRpdGluZyBhIGNvbmZpZyBhbmQgYXBwbHlpbmcgaXQgdG8gYSBkZXZp
Y2UgKEknbGwgZ2l2ZSB0aGUgZXhhbXBsZSBvZiB1c2luZyB0aGUgY2FuZGlkYXRlIERTKToNCj4+
IChBKSBjb25maWcgY2hhbmdlcyAgIC0tLT4gY2FuZGlkYXRlIERTICAgKDxlZGl0LWNvbmZpZz4p
DQo+PiAoQikgY2FuZGlkYXRlIERTICAtLS0tPiBydW5uaW5nIChpbnRlbmRlZCkgICg8Y29tbWl0
PikNCj4+IChDKSBpbnRlbmRlZCAtLS0tPiBhcHBsaWVkICAoaW50ZXJuYWwgcHJvY2Vzc2VkIGlu
IHRoZSBkZXZpY2UpDQo+Pg0KPj4gVG9kYXkgcm9sbGJhY2stb24tZXJyb3IgaXMgb25seSBhcHBs
aWNhYmxlIHRvIHRyYW5zaXRpb24gKEEpLg0KPj4NCj4+IFRyYW5zaXRpb24gKEIpIGRvZXMgaGF2
ZSBhbGwtb3Itbm90aGluZyBwcm9wZXJ0aWVzIChhcyBkZXNjcmliZWQgaW4gUkZDNjI0MSkgYnV0
IHRoYXQgaXNuJ3QgcmVsYXRlZCB0byAicm9sbGJhY2stb24tZXJyb3IiLg0KPj4NCj4+IElzIHRo
ZXJlIHNvbWUgaW50ZW50aW9uIGluIHRoZSBvcHN0YXRlIHJlcXVpcmVtZW50cyB0byBhZGQgc29t
ZSBzb3J0IG9mIGFsbC1vci1ub3RoaW5nIGJlaGF2aW9yIHRvIHRyYW5zaXRpb24gKEMpID8gIGku
ZS4gaWYgc29tZSBwYXJ0IG9mIGFuIGVkaXQgZmFpbHMgZHVyaW5nIHRoZSB0cmFuc2l0aW9uIGZy
b20gaW50ZW5kZWQtPmFwcGxpZWQgd2Ugc2hvdWxkICJyb2xsYmFjayIgdGhlIG90aGVyIHBhcnRz
IHRoYXQgbWF5IGhhdmUgYWxyZWFkeSBiZWVuIGFwcGxpZWQgPw0KPj4NCj4+IFdvdWxkIHdlIHRo
ZW4gcmVtb3ZlIGl0IGFsbCBmcm9tIGludGVuZGVkIGFzIHdlbGwgPw0KPj4NCj4+IEknbSBub3Qg
c3VyZSBob3cgdGhhdCB3b3VsZCB3b3JrIGZvciBhbiBhc3luYy9oeWJyaWQgKHJlYWQgInJlYWwi
KSBzeXN0ZW0uICBXZSd2ZSBhbHJlYWR5IGRvbmUgYW4gImFjayIgYmFjayB0byB0aGUgY2xpZW50
IGJlZm9yZSB0cmFuc2l0aW9uIChDKSBzbyB0aGUgY2xpZW50IG1heSBoYXZlIGFscmVhZHkgc2Vu
dCBzb21lIGFkZGl0aW9uYWwgbmV3IGNvbmZpZyB0aGF0IGRlcGVuZHMgb24gdGhlIHByZXZpb3Vz
IGVkaXQuICBUaGF0IHdvdWxkIG1lYW4gdGhhdCBuZXcgY29uZmlnIGlzbid0IHZhbGlkLg0KPj4N
Cj4+IEphc29uDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+IG5ldG1vZEBpZXRmLm9yZw0KPj4g
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4+IC4NCj4+DQo+
DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5uZXRt
b2QgbWFpbGluZyBsaXN0DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv
bWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg==


From nobody Tue Dec 22 19:07:00 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A9E1A9104 for ; Tue, 22 Dec 2015 19:06:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level: 
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 zXOdcYpx2GgD for ; Tue, 22 Dec 2015 19:06:57 -0800 (PST)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0114.outbound.protection.outlook.com [207.46.100.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 027121A9101 for ; Tue, 22 Dec 2015 19:06:55 -0800 (PST)
Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (TLS) id 15.1.361.13; Wed, 23 Dec 2015 03:06: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.0361.006; Wed, 23 Dec 2015 03:06:52 +0000
From: Kent Watsen 
To: Ladislav Lhotka , =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= 
Thread-Topic: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
Thread-Index: AQHROST+9GZCZpOeokmaO0YJheWZYJ7QnZ0AgAA6WoCAAFh6gIAEjK+AgAAEG4CAABYDAIABwJwA
Date: Wed, 23 Dec 2015 03:06:52 +0000
Message-ID: 
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>  <56783B45.1020505@cisco.com> <20151221180231.GC43694@elstar.local> <147269F5-7B47-4614-9C08-948E8B5FC65C@nic.cz>
In-Reply-To: <147269F5-7B47-4614-9C08-948E8B5FC65C@nic.cz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/0.0.0.151105
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.12]
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 5:8jDUx86DmNsiwqnsE6yEeuTL2eo0dD3ooTpv03DfdXcByehpwhFITrTsqBx/hizRBmqdkQlB1yTsmy2qmwNO4ugiEkP2nThROXoLfOcV/L7lL0+OmXAq3spI9shBCa0ncxxId1a0npkryb2g68ussQ==; 24:BjwyWQ9YOoicB4rZUyACqJqboaISCRfqTwqvAvj1bIBAQ/KYzL7uxeb+wCpjid9TeB0KyF2HNcNA+tFR/6ahbx3XCPrDZR3TXEsxo42zJiQ=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0501MB1441;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(520078)(5005006)(8121501046)(10201501046)(3002001); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; 
x-forefront-prvs: 0799B1B2D7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(189002)(377454003)(479174004)(199003)(81156007)(11100500001)(50986999)(86362001)(5008740100001)(10400500002)(92566002)(575784001)(66066001)(586003)(2900100001)(15975445007)(77096005)(2950100001)(5004730100002)(101416001)(1220700001)(1096002)(36756003)(6116002)(3846002)(102836003)(99286002)(230783001)(82746002)(5002640100001)(93886004)(97736004)(40100003)(122556002)(19580395003)(76176999)(5001770100001)(33656002)(54356999)(106356001)(87936001)(189998001)(106116001)(4001350100001)(19580405001)(83716003)(5001960100002)(83506001)(105586002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; 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:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <454635172D3F0B4F8F02AF2839D9B18E@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Dec 2015 03:06:52.2518 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2015 03:06:59 -0000

DQoNCg0KDQoNCk9uIDEyLzIxLzE1LCAyOjIxIFBNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBMYWRp
c2xhdiBMaG90a2EiIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbGhvdGth
QG5pYy5jej4gd3JvdGU6DQoNCj4NCj4+IE9uIDIxIERlYyAyMDE1LCBhdCAxOTowMiwgSnVlcmdl
biBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdy
b3RlOg0KPj4gDQo+PiBPbiBNb24sIERlYyAyMSwgMjAxNSBhdCAwNjo0Nzo0OVBNICswMTAwLCBC
ZW5vaXQgQ2xhaXNlIHdyb3RlOg0KPj4gDQo+Pj4gSSBob3BlIHRoYXQgbm9ib2R5IGRpc2FncmVl
cyB0aGF0IHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBkZXNpZ24gYW5kIGhvdyANCj4+PiB0byBzdHJ1
Y3R1cmUgdGhlIG1vZGVscyBhcmUgdGhlIHR3byBibG9ja2luZyBmYWN0b3JzIHRvIHB1Ymxpc2gg
WUFORyANCj4+PiBtb2RlbHMuIElmIHlvdSBkaXNhZ3JlZSBvciBkb24ndCBzZWUgdGhpcywgbGV0
IG1lIGtub3csIEkgc2hvdWxkIA0KPj4+IGNvbW11bmljYXRlIGJldHRlci4NCj4+IA0KPj4gRXZl
biBpZiBpdCBtYXkgc3BvaWwgeW91ciBkYXksIEkgZGlzYWdyZWUgdGhhdCB0aGVyZSBpcyBhIGJs
b2NraW5nDQo+PiBmYWN0b3IgdGhhdCBzaG91bGQgc3RvcCB1cyBmcm9tIHB1Ymxpc2hpbmcgbW9k
ZWxzLiBUaGVyZSBzZWVtIHRvIGJlDQo+PiB3YXlzIHRvIGFkZHJlc3MgdGhlIHJlcXVpcmVtZW50
cyB3aXRob3V0IGhhdmluZyB0byBibG9jayBhbGwgd29yayBvcg0KPj4gdG8gcmVkbyB3aGF0IHRo
YXQgd2UgaGF2ZSBwdWJsaXNoZWQuIEJ1dCBzdXJlLCBpZiB5b3UgbWFrZSBpdCBhDQo+PiBibG9j
a2luZyBmYWN0b3IsIGl0IHdpbGwgYmUgb25lLg0KPg0KPkkgYWdyZWUgd2l0aCBKdWVyZ2VuLiBJ
dCBpcyBub3QgY2xlYXIgdG8gbWUgaG93IHRoZSBwcm9wb3NlZCBzcGxpdCBiZXR3ZWVuIGludGVu
ZGVkIGFuZCBhcHBsaWVkIGNvbmZpZ3VyYXRpb24gaXMgc3VwcG9zZWQgdG8gYWZmZWN0IHRoZSBk
YXRhIG1vZGVscyB3ZSBhcmUgd29ya2luZyBvbi4NCg0KDQpBcyBJIHVuZGVyc3RhbmQgaXQsIHNv
bHV0aW9uICMxIGFmZmVjdHMgdGhlIG1vZGVscyB0aGVtc2VsdmVzLCB3aGVyZWFzIHNvbHV0aW9u
cyAjMiBhbmQgIzMgYXJlIHRyYW5zcGFyZW50IHRvIHRoZSBtb2RlbHMuDQoNCktlbnQNCg0KDQoN
Cj5MYWRhDQo+DQo+PiANCj4+PiBJIGhvcGUgdGhhdCBub2JvZHkgcmVhbGx5IGJlbGlldmVzIHRo
YXQgYmVjYXVzZSBzb21lIHBlb3BsZSBpbiBJRVRGIChvciANCj4+PiBpbiBhbnkgb3RoZXIgU0RP
cykgdGhpbmtzIHRoYXQgd2hhdCB0aG9zZSBvcGVyYXRvcnMgd2FudCBpcyBhIGJhZCBpZGVhLCAN
Cj4+PiB0aG9zZSBvcGVyYXRvcnMgd2lsbCBub3QgZ2V0IHdoYXQgdGhleSByZXF1ZXN0L3BheSBm
b3IgZnJvbSB0aGVpciBzdXBwbGllcnMuDQo+PiANCj4+IFRvIGJlIGZhaXIsIHRob3NlIG9wZXJh
dG9ycyBhbHNvIHRlbGwgdXMgdGhhdCB0aGV5IHVzZSBwcm90b2NvbHMgdGhhdA0KPj4gYXJlIG5v
dCBJRVRGIHByb3RvY29scyBhbmQgaXQgcmVtYWlucyBzb21ld2hhdCB1bmNsZWFyIHdoYXQgdGhv
c2UNCj4+IHByb3RvY29scyBhcmUgd2UgYXJlIGV4cGVjdGVkIHRvIG9wdGltaXplIGRhdGEgbW9k
ZWwgc29sdXRpb25zIGZvci4NCj4+IA0KPj4gL2pzDQo+PiANCj4+IC0tIA0KPj4gSnVlcmdlbiBT
Y2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4+
IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJy
ZW1lbiB8IEdlcm1hbnkNCj4+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6
Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4g
bmV0bW9kQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L25ldG1vZA0KPg0KPi0tDQo+TGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPlBHUCBLZXkg
SUQ6IEU3NEU4QzBDDQo+DQo+DQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX18NCj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+bmV0bW9kQGlldGYub3Jn
DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg==


From nobody Wed Dec 23 00:22:10 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755151ACDB0 for ; Wed, 23 Dec 2015 00:22:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 B2YRsEoIG7Hv for ; Wed, 23 Dec 2015 00:22:07 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24C721ACD7B for ; Wed, 23 Dec 2015 00:22:07 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:39a6:fad0:c05:eaa5] (unknown [IPv6:2001:718:1a02:1:39a6:fad0:c05:eaa5]) by mail.nic.cz (Postfix) with ESMTPSA id 8D39B181AF4; Wed, 23 Dec 2015 09:22:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1450858925; bh=CPSFsZ7jYKicWZve9RUzNvIjtQY+0QT6jh7BVTksZU8=; h=From:Date:To; b=rbme84u2nYs/jtoQ6skiqW2QStooQyjqeaAp04jn00KCUirn+mWtHYfpaJolb3iR3 WHaHopHhxeFQyu8S+GfCRjJa9g/lmhZlm4QwBN80r894heX4Xb1w008CFAOaAjI14i 5zYqlDfbxTtpDqzCylNOVjpjZx0hk+qz/WNaL/Nk=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Wed, 23 Dec 2015 09:22:10 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <6AFC7C6C-61B7-4310-A0CA-08A7CD76A899@nic.cz>
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>  <56783B45.1020505@cisco.com> <20151221180231.GC43694@elstar.local> <147269F5-7B47-4614-9C08-948E8B5FC65C@nic.cz> 
To: Kent Watsen 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2015 08:22:09 -0000

> On 23 Dec 2015, at 04:06, Kent Watsen  wrote:
>=20
>=20
>=20
>=20
>=20
>=20
> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka" =
 wrote:
>=20
>>=20
>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder =
 wrote:
>>>=20
>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>>>=20
>>>> I hope that nobody disagrees that the operational state design and =
how=20
>>>> to structure the models are the two blocking factors to publish =
YANG=20
>>>> models. If you disagree or don't see this, let me know, I should=20
>>>> communicate better.
>>>=20
>>> Even if it may spoil your day, I disagree that there is a blocking
>>> factor that should stop us from publishing models. There seem to be
>>> ways to address the requirements without having to block all work or
>>> to redo what that we have published. But sure, if you make it a
>>> blocking factor, it will be one.
>>=20
>> I agree with Juergen. It is not clear to me how the proposed split =
between intended and applied configuration is supposed to affect the =
data models we are working on.
>=20
>=20
> As I understand it, solution #1 affects the models themselves, whereas =
solutions #2 and #3 are transparent to the models.

Then #1 looks like a non-starter to me.

Lada

>=20
> Kent
>=20
>=20
>=20
>> Lada
>>=20
>>>=20
>>>> I hope that nobody really believes that because some people in IETF =
(or=20
>>>> in any other SDOs) thinks that what those operators want is a bad =
idea,=20
>>>> those operators will not get what they request/pay for from their =
suppliers.
>>>=20
>>> To be fair, those operators also tell us that they use protocols =
that
>>> are not IETF protocols and it remains somewhat unclear what those
>>> protocols are we are expected to optimize data model solutions for.
>>>=20
>>> /js
>>>=20
>>> --=20
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | =
Germany
>>> Fax:   +49 421 200 3103         
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed Dec 23 00:28:49 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69EEF1ACDB8 for ; Wed, 23 Dec 2015 00:28:48 -0800 (PST)
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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 v2B7_xHZyWjn for ; Wed, 23 Dec 2015 00:28:46 -0800 (PST)
Received: from auth-3.ukservers.net (auth-3.ukservers.net [217.10.138.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8E51ACDB6 for ; Wed, 23 Dec 2015 00:28:45 -0800 (PST)
Received: from [192.168.0.33] (cpc13-heme10-2-0-cust400.9-1.cable.virginm.net [81.111.149.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by auth-3.ukservers.net (Postfix smtp) with ESMTPSA id AF9B21721513; Wed, 23 Dec 2015 08:28:41 +0000 (GMT)
To: Kent Watsen , "netmod@ietf.org" 
References:  <56784B9B.5020408@cisco.com> <327E370C-4D5F-4F9A-B982-B71108CEBC08@juniper.net>
From: Robert Wilton 
Message-ID: <567A5B39.3010909@wilton.org.uk>
Date: Wed, 23 Dec 2015 08:28:41 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <327E370C-4D5F-4F9A-B982-B71108CEBC08@juniper.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2015 08:28:48 -0000

Hi Kent,

Yes, I think that we are in agreement.

I've one further comment inline below ...

On 23/12/2015 02:41, Kent Watsen wrote:
> [As a contributor]
>
> Hi Robert, I want to go back to Jason’s original questions.  I think we’re aligned on this, but please check my answers below.
>
> Quoting Jason’s original text now:
>
>
>> Is there some intention in the opstate requirements to add some sort
>> of all-or-nothing behavior to transition (C)?
> Yes
>
>
>> i.e. if some part of
>> an edit fails during the transition from intended->applied we should
>> "rollback" the other parts that may have already been applied ?
> Yes
>
>
>> Would we then remove it all from intended as well ?
> IMO, yes.  This is more easily understood when thinking about Synchronous Configuration Operations (defined in opstate-reqs), but I believe that it equally applies to Asynchronous Configuration Operations, so long as the client explicitly ops-in for the behavior.
>
>
>> I'm not sure how that would work for an async/hybrid (read "realâ€)
>> system.  We've already done an "ack" back to the client before
>> transition (C) so the client may have already sent some additional
>> new config that depends on the previous edit.  That would mean that
>> new config isn't valid.
> I’m not a fan on the “hybrid†term, but in thinking about legacy or existing NETCONF servers, I think that this is a non-issue as the server wouldn’t advertise support for Rollback on Error in the first place.
I agree that "hybrid" probably isn't a good term.

It is probably worth noting that NETCONF already defines a 
rollback-on-error optional capability, but that shouldn't be a problem 
because I think that we only need to concern ourselves with servers that 
express support for an explicit sync or async capability.

Thanks,
Rob


>
>
> Kent
>
>
>
>
>
> On 12/21/15, 1:57 PM, "netmod on behalf of Robert Wilton"  wrote:
>
>> Hi Jason,
>>
>> Picking up this slightly old thread.
>>
>> The "rollback on error" definition that I added I took directly from
>> RFC6241, so it's good that they look similar.  The intention is that the
>> NETCONF "rollback-on-error" capability is a valid implementation of this
>> requirement :-)
>>
>> I think that the  rollback-on-error capability defined in RFC6241 can
>> also be applied to the running datastore.  Certainly, the example quoted
>> is in the context of the edit-config request on the running-config
>> datastore, and the RFC description of this feature doesn't appear to
>> limit it to the candidate datastore in any way.
>>
>> Thanks,
>> Rob
>>
>>
>> On 03/11/2015 07:23, Sterne, Jason (Jason) wrote:
>>> Hi all,
>>>
>>> The term "rollback on error" (and other error options) has been used during these discussions around the opstate requirements.
>>>
>>> That term already has some meaning in RFC6241 (or at least rollback-on-error does and that is pretty close) and IMO it (today) has nothing to do with "applied" config.  It is an error option that has the scope of the contents of a single edit-config request and how those contents get applied (all or nothing) to the candidate DS (which is neither intended nor applied config) or to the running DS (intended) if the  is .
>>>
>>> I think we need to clarify this "all or nothing" concept and how it is related to "applied" config.  We may also want to use slightly different terminology so we don't get confused with today's meaning of rollback-on-error.
>>>
>>> There are a few transitions to consider when editing a config and applying it to a device (I'll give the example of using the candidate DS):
>>> (A) config changes   ---> candidate DS   ()
>>> (B) candidate DS  ----> running (intended)  ()
>>> (C) intended ----> applied  (internal processed in the device)
>>>
>>> Today rollback-on-error is only applicable to transition (A).
>>>
>>> Transition (B) does have all-or-nothing properties (as described in RFC6241) but that isn't related to "rollback-on-error".
>>>
>>> Is there some intention in the opstate requirements to add some sort of all-or-nothing behavior to transition (C) ?  i.e. if some part of an edit fails during the transition from intended->applied we should "rollback" the other parts that may have already been applied ?
>>>
>>> Would we then remove it all from intended as well ?
>>>
>>> I'm not sure how that would work for an async/hybrid (read "real") system.  We've already done an "ack" back to the client before transition (C) so the client may have already sent some additional new config that depends on the previous edit.  That would mean that new config isn't valid.
>>>
>>> Jason
>>>
>>> _______________________________________________
>>> 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


From nobody Wed Dec 23 02:24:16 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC491A9139 for ; Wed, 23 Dec 2015 02:24:15 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 3NCjgqWvbyRA for ; Wed, 23 Dec 2015 02:24:12 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0127.outbound.protection.outlook.com [65.55.169.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 CA3FF1A6FF0 for ; Wed, 23 Dec 2015 02:24:11 -0800 (PST)
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) with Microsoft SMTP Server (TLS) id 15.1.361.13; Wed, 23 Dec 2015 10:24:08 +0000
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0361.006; Wed, 23 Dec 2015 10:24:08 +0000
From: Gert Grammel 
To: Robert Wilton , Kent Watsen , "netmod@ietf.org" 
Thread-Topic: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
Thread-Index: AQHRPCF5yZUEnm9OEEacfs09McNkmJ7X3pwAgABg/ICAADECgA==
Date: Wed, 23 Dec 2015 10:24:08 +0000
Message-ID: 
References:  <56784B9B.5020408@cisco.com> <327E370C-4D5F-4F9A-B982-B71108CEBC08@juniper.net> <567A5B39.3010909@wilton.org.uk>
In-Reply-To: <567A5B39.3010909@wilton.org.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.5.9.151119
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ggrammel@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [193.110.55.12]
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1450; 5:6oUGQz+67OI6MPWuJHsYuE3IBDEjkeDFYCuc+R8vPAIa8GHaoyZmntyLT5FC1+FNNRqfzrJQ10vIZHZ3/a3IgqDQC2x9kYsLOLtj+xUpOFOOM46DBbZYyTArim/82/OWY0kR1h9ny8Dd+Dkazv1Icg==; 24:faR7/OSbdjTxm75VmU8TLt+IdGHlmDKy3RDCEw2lM2SfZRM/P9b5YZ6EmGncYaqu9ks3sShBoSxuLZ6eQPPH9Dtl618cvhjQEyhErKuNhVE=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1450;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:CY1PR0501MB1450; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1450; 
x-forefront-prvs: 0799B1B2D7
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(53754006)(199003)(377454003)(479174004)(164054003)(189002)(51444003)(106116001)(16236675004)(77096005)(40100003)(36756003)(50986999)(3846002)(54356999)(586003)(11100500001)(1220700001)(76176999)(83506001)(87936001)(5008740100001)(5004730100002)(97736004)(102836003)(5001770100001)(81156007)(189998001)(4001350100001)(5001960100002)(2501003)(6116002)(107886002)(105586002)(93886004)(15975445007)(66066001)(230783001)(19617315012)(92566002)(122556002)(2900100001)(19580405001)(2950100001)(10400500002)(19580395003)(101416001)(99286002)(1941001)(86362001)(5002640100001)(106356001)(1096002)(94096001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1450; H:CY1PR0501MB1609.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)
Content-Type: multipart/alternative; boundary="_000_D2A02F28D35Bggrammeljunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Dec 2015 10:24:08.1458 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1450
Archived-At: 
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2015 10:24:16 -0000

--_000_D2A02F28D35Bggrammeljunipernet_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Rob, Kent,

Adding to Rob=92s comments:



From: netmod > on b=
ehalf of Robert Wilton >
Date: Wednesday 23 December 2015 09:28
To: Kent Watsen >, "netmod@=
ietf.org" >
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback =
on error)

Hi Kent,

Yes, I think that we are in agreement.

I've one further comment inline below ...

On 23/12/2015 02:41, Kent Watsen wrote:
[As a contributor]

Hi Robert, I want to go back to Jason=92s original questions.  I think we=
=92re aligned on this, but please check my answers below.

Quoting Jason=92s original text now:


Is there some intention in the opstate requirements to add some sort
of all-or-nothing behavior to transition (C)?
Yes
+1 (if rollback-on-error has been requested)



i.e. if some part of
an edit fails during the transition from intended->applied we should
"rollback" the other parts that may have already been applied ?
Yes
+1 (if rollback-on-error has been requested)


Would we then remove it all from intended as well ?
IMO, yes.  This is more easily understood when thinking about Synchronous C=
onfiguration Operations (defined in opstate-reqs), but I believe that it eq=
ually applies to Asynchronous Configuration Operations, so long as the clie=
nt explicitly ops-in for the behavior.
IMO no. The intended config is imposed by the client to the server and othe=
r than performing some syntax check, the server has no choice to accept it =
as-is. If the server can=92t apply the intended config, obviously the misma=
tch between intended and applied config needs to be notified. As a result, =
it is up to the client to decide what to do. Actions can vary according to =
the situation naming a few: 1) retry intended config, 2) retry intended con=
fig with continue-on-error, 3) re-apply the previous intended config, =85
In other words:

  1.  the client shall not touch the applied config directly,
  2.  the server shall not touch the intended config,
  3.  it=92s up to the server to align the intended with the applied config=
 in a way requested by the client (i.e. rollback-on-error, =85)
  4.  Once applied, the server notifies the client about success or failure=
 to do so



I'm not sure how that would work for an async/hybrid (read "real=94)
system.  We've already done an "ack" back to the client before
transition (C) so the client may have already sent some additional
new config that depends on the previous edit.  That would mean that
new config isn't valid.
I=92m not a fan on the =93hybrid=94 term, but in thinking about legacy or e=
xisting NETCONF servers, I think that this is a non-issue as the server wou=
ldn=92t advertise support for Rollback on Error in the first place.
I agree that "hybrid" probably isn't a good term.
+1 in fact it=92s a "cheating synchronous=94 behaviour, probably not the be=
st term either. Let=92s find a better term we can agree upon.

It is probably worth noting that NETCONF already defines a
rollback-on-error optional capability, but that shouldn't be a problem
because I think that we only need to concern ourselves with servers that
express support for an explicit sync or async capability.
+1

Thanks,
Rob




Kent





On 12/21/15, 1:57 PM, "netmod on behalf of Robert Wilton"  on behalf of rwilton@cisco.com> wrote:

Hi Jason,

Picking up this slightly old thread.

The "rollback on error" definition that I added I took directly from
RFC6241, so it's good that they look similar.  The intention is that the
NETCONF "rollback-on-error" capability is a valid implementation of this
requirement :-)

I think that the  rollback-on-error capability defined in RFC6241 can
also be applied to the running datastore.  Certainly, the example quoted
is in the context of the edit-config request on the running-config
datastore, and the RFC description of this feature doesn't appear to
limit it to the candidate datastore in any way.

Thanks,
Rob


On 03/11/2015 07:23, Sterne, Jason (Jason) wrote:
Hi all,

The term "rollback on error" (and other error options) has been used during=
 these discussions around the opstate requirements.

That term already has some meaning in RFC6241 (or at least rollback-on-erro=
r does and that is pretty close) and IMO it (today) has nothing to do with =
"applied" config.  It is an error option that has the scope of the contents=
 of a single edit-config request and how those contents get applied (all or=
 nothing) to the candidate DS (which is neither intended nor applied config=
) or to the running DS (intended) if the  is .

I think we need to clarify this "all or nothing" concept and how it is rela=
ted to "applied" config.  We may also want to use slightly different termin=
ology so we don't get confused with today's meaning of rollback-on-error.

There are a few transitions to consider when editing a config and applying =
it to a device (I'll give the example of using the candidate DS):
(A) config changes   ---> candidate DS   ()
(B) candidate DS  ----> running (intended)  ()
(C) intended ----> applied  (internal processed in the device)

Today rollback-on-error is only applicable to transition (A).

Transition (B) does have all-or-nothing properties (as described in RFC6241=
) but that isn't related to "rollback-on-error".

Is there some intention in the opstate requirements to add some sort of all=
-or-nothing behavior to transition (C) ?  i.e. if some part of an edit fail=
s during the transition from intended->applied we should "rollback" the oth=
er parts that may have already been applied ?

Would we then remove it all from intended as well ?

I'm not sure how that would work for an async/hybrid (read "real") system. =
 We've already done an "ack" back to the client before transition (C) so th=
e client may have already sent some additional new config that depends on t=
he previous edit.  That would mean that new config isn't valid.

Jason

_______________________________________________
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

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


--_000_D2A02F28D35Bggrammeljunipernet_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <59E8CBE66BD3E649B6E82469505601E4@namprd05.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable







Rob, Kent,







Adding to Rob=92s comments:



















From: netmod <netmod-bounces@ietf.org> on behalf of Rober=
t Wilton <robert.public@w=
ilton.org.uk>

Date: Wednesday 23 December 2015 09=
:28

To: Kent Watsen <kwatsen@juniper.net>, "netmod@ietf.org" <netmod@ietf.org>

Subject: Re: [netmod] netmod-opstat=
e-reqs and error option terms (rollback on error)













Hi Kent,







Yes, I think that we are in agreement.







I've one further comment inline below ...







On 23/12/2015 02:41, Kent Watsen wrote:




[As a contributor]







Hi Robert, I want to go back to Jason=92s original questions. &nb=
sp;I think we=92re aligned on this, but please check my answers below.






Quoting Jason=92s original text now:














Is there some intention in the opstate requirements to add some sort

of all-or-nothing behavior to transition (C)?




Yes









+1 (if rollback-on-error has been requested)


























i.e. if some part of


an edit fails during the transition from intended->applied we shoul=
d


"rollback" the other parts that may have already been applie=
d ?




Yes









+1 (if rollback-on-error has been requested)





















Would we then remove it all from intended as well ?




IMO, yes.  This is more easily understood when thinking abou=
t Synchronous Configuration Operations (defined in opstate-reqs), but I bel=
ieve that it equally applies to Asynchronous Configuration Operations, so l=
ong as the client explicitly ops-in for the
 behavior.









IMO no. The intended config is imposed by the client to the server and=
 other than performing some syntax check, the server has no choice to accep=
t it as-is. If the server can=92t apply the intended config, obviously the =
mismatch between intended and applied
 config needs to be notified. As a result, it is up to the client to decide=
 what to do. Actions can vary according to the situation naming a few: 1) r=
etry intended config, 2) retry intended config with continue-on-error, 3) r=
e-apply the previous intended config,
 =85


In other words: 


    

  1. the client shall not touch the applied config directly, 
  2. t=
he server shall not touch the intended config, 
  3. it=92s up to t=
he server to align the intended with the applied config in a way requested =
by the client (i.e. rollback-on-error, =85)
  4. Once applied, the serve=
r notifies the client about success or failure to do so


























I'm not sure how that would work for an async/hybrid (read "real=
=94)


system.  We've already done an "ack" back to the c=
lient before


transition (C) so the client may have already sent some additional

new config that depends on the previous edit.  That would me=
an that


new config isn't valid.




I=92m not a fan on the =93hybrid=94 term, but in thinking about legacy=
 or existing NETCONF servers, I think that this is a non-issue as the serve=
r wouldn=92t advertise support for Rollback on Error in the first place.



I agree that "hybrid" probably isn't a good term.







+1 in fact it=92s a "cheating synchronous=94 behaviour, proba=
bly not the best term either. Let=92s find a better term we can agree upon.=













It is probably worth noting that NETCONF already defines a 


rollback-on-error optional capability, but that shouldn't be a problem=
 


because I think that we only need to concern ourselves with servers th=
at 


express support for an explicit sync or async capability.







+1












Thanks,


Rob
























Kent



























On 12/21/15, 1:57 PM, "netmod on behalf of Robert Wilton" &l=
t;netmod-bounces@ietf.org on=
 behalf of
rwilton@cisco.com> wrote:









Hi Jason,







Picking up this slightly old thread.







The "rollback on error" definition that I added I took direc=
tly from


RFC6241, so it's good that they look similar.  The intention=
 is that the


NETCONF "rollback-on-error" capability is a valid implementa=
tion of this


requirement :-)







I think that the  rollback-on-error capability defined in RF=
C6241 can


also be applied to the running datastore.  Certainly, the ex=
ample quoted


is in the context of the edit-config request on the running-config

datastore, and the RFC description of this feature doesn't appear to

limit it to the candidate datastore in any way.







Thanks,


Rob












On 03/11/2015 07:23, Sterne, Jason (Jason) wrote:




Hi all,







The term "rollback on error" (and other error options) has b=
een used during these discussions around the opstate requirements.







That term already has some meaning in RFC6241 (or at least rollback-on=
-error does and that is pretty close) and IMO it (today) has nothing to do =
with "applied" config.  It is an error option that has =
the scope of the contents of a single edit-config request
 and how those contents get applied (all or nothing) to the candidate DS (w=
hich is neither intended nor applied config) or to the running DS (intended=
) if the <target> is <running/>.







I think we need to clarify this "all or nothing" concept and=
 how it is related to "applied" config.  We may also wa=
nt to use slightly different terminology so we don't get confused with toda=
y's meaning of rollback-on-error.







There are a few transitions to consider when editing a config and appl=
ying it to a device (I'll give the example of using the candidate DS):

(A) config changes   ---> candidate DS   (<e=
dit-config>)


(B) candidate DS  ----> running (intended)  (&l=
t;commit>)


(C) intended ----> applied  (internal processed in the de=
vice)







Today rollback-on-error is only applicable to transition (A).







Transition (B) does have all-or-nothing properties (as described in RF=
C6241) but that isn't related to "rollback-on-error".







Is there some intention in the opstate requirements to add some sort o=
f all-or-nothing behavior to transition (C) ?  i.e. if some part =
of an edit fails during the transition from intended->applied we should =
"rollback" the other parts that may have already
 been applied ?







Would we then remove it all from intended as well ?







I'm not sure how that would work for an async/hybrid (read "real&=
quot;) system.  We've already done an "ack" back to the=
 client before transition (C) so the client may have already sent some addi=
tional new config that depends on the previous edit.  That would
 mean that new config isn't valid.







Jason







_______________________________________________


netmod mailing list




.









_______________________________________________


netmod mailing list






_______________________________________________


netmod mailing list











_______________________________________________


netmod mailing list
















--_000_D2A02F28D35Bggrammeljunipernet_--


From nobody Wed Dec 23 02:45:37 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3ECE1ACE5D for ; Wed, 23 Dec 2015 02:45:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 yZapKfjaRdX0 for ; Wed, 23 Dec 2015 02:45:33 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B02EF1ACE53 for ; Wed, 23 Dec 2015 02:45:32 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B3BE78B2; Wed, 23 Dec 2015 11:45:30 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id DMui2guQIVAp; Wed, 23 Dec 2015 11:45:28 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 23 Dec 2015 11:45:28 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 428E120056; Wed, 23 Dec 2015 11:45:28 +0100 (CET)
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 CR_V3ntO5pTi; Wed, 23 Dec 2015 11:45:26 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 966F220055; Wed, 23 Dec 2015 11:45:25 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 8A8033961177; Wed, 23 Dec 2015 11:45:24 +0100 (CET)
Date: Wed, 23 Dec 2015 11:45:23 +0100
From: Juergen Schoenwaelder 
To: Gert Grammel 
Message-ID: <20151223104523.GA47616@elstar.local>
Mail-Followup-To: Gert Grammel , Robert Wilton , Kent Watsen , "netmod@ietf.org" 
References:  <56784B9B.5020408@cisco.com> <327E370C-4D5F-4F9A-B982-B71108CEBC08@juniper.net> <567A5B39.3010909@wilton.org.uk> 
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: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2015 10:45:36 -0000

It seems message quoting is all messed up here (both in mutt and
thunderbird). I can't really follow anymore from this message who said
what and who agrees with whom on what.

/js

On Wed, Dec 23, 2015 at 10:24:08AM +0000, Gert Grammel wrote:
> Rob, Kent,
> 
> Adding to Rob’s comments:
> 
> 
> 
> From: netmod > on behalf of Robert Wilton >
> Date: Wednesday 23 December 2015 09:28
> To: Kent Watsen >, "netmod@ietf.org" >
> Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
> 
> Hi Kent,
> 
> Yes, I think that we are in agreement.
> 
> I've one further comment inline below ...
> 
> On 23/12/2015 02:41, Kent Watsen wrote:
> [As a contributor]
> 
> Hi Robert, I want to go back to Jason’s original questions.  I think we’re aligned on this, but please check my answers below.
> 
> Quoting Jason’s original text now:
> 
> 
> Is there some intention in the opstate requirements to add some sort
> of all-or-nothing behavior to transition (C)?
> Yes
> +1 (if rollback-on-error has been requested)
> 
> 
> 
> i.e. if some part of
> an edit fails during the transition from intended->applied we should
> "rollback" the other parts that may have already been applied ?
> Yes
> +1 (if rollback-on-error has been requested)
> 
> 
> Would we then remove it all from intended as well ?
> IMO, yes.  This is more easily understood when thinking about Synchronous Configuration Operations (defined in opstate-reqs), but I believe that it equally applies to Asynchronous Configuration Operations, so long as the client explicitly ops-in for the behavior.
> IMO no. The intended config is imposed by the client to the server and other than performing some syntax check, the server has no choice to accept it as-is. If the server can’t apply the intended config, obviously the mismatch between intended and applied config needs to be notified. As a result, it is up to the client to decide what to do. Actions can vary according to the situation naming a few: 1) retry intended config, 2) retry intended config with continue-on-error, 3) re-apply the previous intended config, …
> In other words:
> 
>   1.  the client shall not touch the applied config directly,
>   2.  the server shall not touch the intended config,
>   3.  it’s up to the server to align the intended with the applied config in a way requested by the client (i.e. rollback-on-error, …)
>   4.  Once applied, the server notifies the client about success or failure to do so
> 
> 
> 
> I'm not sure how that would work for an async/hybrid (read "realâ€)
> system.  We've already done an "ack" back to the client before
> transition (C) so the client may have already sent some additional
> new config that depends on the previous edit.  That would mean that
> new config isn't valid.
> I’m not a fan on the “hybrid†term, but in thinking about legacy or existing NETCONF servers, I think that this is a non-issue as the server wouldn’t advertise support for Rollback on Error in the first place.
> I agree that "hybrid" probably isn't a good term.
> +1 in fact it’s a "cheating synchronous†behaviour, probably not the best term either. Let’s find a better term we can agree upon.
> 
> It is probably worth noting that NETCONF already defines a
> rollback-on-error optional capability, but that shouldn't be a problem
> because I think that we only need to concern ourselves with servers that
> express support for an explicit sync or async capability.
> +1
> 
> Thanks,
> Rob
> 
> 
> 
> 
> Kent
> 
> 
> 
> 
> 
> On 12/21/15, 1:57 PM, "netmod on behalf of Robert Wilton"  on behalf of rwilton@cisco.com> wrote:
> 
> Hi Jason,
> 
> Picking up this slightly old thread.
> 
> The "rollback on error" definition that I added I took directly from
> RFC6241, so it's good that they look similar.  The intention is that the
> NETCONF "rollback-on-error" capability is a valid implementation of this
> requirement :-)
> 
> I think that the  rollback-on-error capability defined in RFC6241 can
> also be applied to the running datastore.  Certainly, the example quoted
> is in the context of the edit-config request on the running-config
> datastore, and the RFC description of this feature doesn't appear to
> limit it to the candidate datastore in any way.
> 
> Thanks,
> Rob
> 
> 
> On 03/11/2015 07:23, Sterne, Jason (Jason) wrote:
> Hi all,
> 
> The term "rollback on error" (and other error options) has been used during these discussions around the opstate requirements.
> 
> That term already has some meaning in RFC6241 (or at least rollback-on-error does and that is pretty close) and IMO it (today) has nothing to do with "applied" config.  It is an error option that has the scope of the contents of a single edit-config request and how those contents get applied (all or nothing) to the candidate DS (which is neither intended nor applied config) or to the running DS (intended) if the  is .
> 
> I think we need to clarify this "all or nothing" concept and how it is related to "applied" config.  We may also want to use slightly different terminology so we don't get confused with today's meaning of rollback-on-error.
> 
> There are a few transitions to consider when editing a config and applying it to a device (I'll give the example of using the candidate DS):
> (A) config changes   ---> candidate DS   ()
> (B) candidate DS  ----> running (intended)  ()
> (C) intended ----> applied  (internal processed in the device)
> 
> Today rollback-on-error is only applicable to transition (A).
> 
> Transition (B) does have all-or-nothing properties (as described in RFC6241) but that isn't related to "rollback-on-error".
> 
> Is there some intention in the opstate requirements to add some sort of all-or-nothing behavior to transition (C) ?  i.e. if some part of an edit fails during the transition from intended->applied we should "rollback" the other parts that may have already been applied ?
> 
> Would we then remove it all from intended as well ?
> 
> I'm not sure how that would work for an async/hybrid (read "real") system.  We've already done an "ack" back to the client before transition (C) so the client may have already sent some additional new config that depends on the previous edit.  That would mean that new config isn't valid.
> 
> Jason
> 
> _______________________________________________
> 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
> 
> _______________________________________________
> 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 Dec 23 07:01:49 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008F01A0167 for ; Wed, 23 Dec 2015 07:01:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 aksjqkzVNskm for ; Wed, 23 Dec 2015 07:01:46 -0800 (PST)
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 B46F51A0174 for ; Wed, 23 Dec 2015 07:01:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4628; q=dns/txt; s=iport; t=1450882905; x=1452092505; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CpeRs48l5IBdJ6JFXdXp80YV5CorWw8jGPP+CbmMoko=; b=Hs0a/haexgxXFZDaevX4I0TYD3r1IAShrtBzt6asReNzImDRnMH0xJtJ QnFQhgS5OWUIjFudoljDXihLAHZwQFzR4YR6IXK9jH7LnlQ70+iG49i80 +6gAlVAm2fIdAz7b08uenId+bAJw8UPSQbf5WEDeelYNVwn6iAH5a9KA9 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DQAQCFtnpW/xbLJq1bA4QMbQaMS7BvA?= =?us-ascii?q?Q2BYxgKhSNKAhyBPxQBAQEBAQEBgQqENAEBAQMBAQEBIBE6Cw4CAgEIEAgCAiY?= =?us-ascii?q?CAgIZDAsVEAIEAQ0FG4gMCA6uApIIAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAR9i?= =?us-ascii?q?lSEbQsmglWBSgWXAwGNS4FcjR2KR4NzASABAUKEC3IBhB+BCAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.20,469,1444694400"; d="scan'208";a="621972710"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Dec 2015 15:01:43 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id tBNF1f4s008195 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 23 Dec 2015 15:01:43 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.1104.5; Wed, 23 Dec 2015 10:01:41 -0500
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.1104.009; Wed, 23 Dec 2015 10:01:41 -0500
From: "Acee Lindem (acee)" 
To: Ladislav Lhotka , Kent Watsen 
Thread-Topic: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
Thread-Index: AQHROST+Qi5eUPyFCUOmbJF1PR1M/Z7Q8W4AgACOLQCAAASngIAEjK+AgAAEHICAABYDAIACFGgAgABYGQCAABvKAA==
Date: Wed, 23 Dec 2015 15:01:41 +0000
Message-ID: 
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>  <56783B45.1020505@cisco.com> <20151221180231.GC43694@elstar.local> <147269F5-7B47-4614-9C08-948E8B5FC65C@nic.cz>  <6AFC7C6C-61B7-4310-A0CA-08A7CD76A899@nic.cz>
In-Reply-To: <6AFC7C6C-61B7-4310-A0CA-08A7CD76A899@nic.cz>
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.199]
Content-Type: text/plain; charset="utf-8"
Content-ID: <54BFB9BBEC7BC5489F7D0BAF1B85AF24@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2015 15:01:48 -0000

DQpPbiAxMi8yMy8xNSwgMzoyMiBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgTGFkaXNsYXYgTGhv
dGthIg0KPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBsaG90a2FAbmljLmN6
PiB3cm90ZToNCg0KPg0KPj4gT24gMjMgRGVjIDIwMTUsIGF0IDA0OjA2LCBLZW50IFdhdHNlbiA8
a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3JvdGU6DQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4g
DQo+PiBPbiAxMi8yMS8xNSwgMjoyMSBQTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgTGFkaXNsYXYg
TGhvdGthIg0KPj48bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGxob3RrYUBu
aWMuY3o+IHdyb3RlOg0KPj4gDQo+Pj4gDQo+Pj4+IE9uIDIxIERlYyAyMDE1LCBhdCAxOTowMiwg
SnVlcmdlbiBTY2hvZW53YWVsZGVyDQo+Pj4+PGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVy
c2l0eS5kZT4gd3JvdGU6DQo+Pj4+IA0KPj4+PiBPbiBNb24sIERlYyAyMSwgMjAxNSBhdCAwNjo0
Nzo0OVBNICswMTAwLCBCZW5vaXQgQ2xhaXNlIHdyb3RlOg0KPj4+PiANCj4+Pj4+IEkgaG9wZSB0
aGF0IG5vYm9keSBkaXNhZ3JlZXMgdGhhdCB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgZGVzaWduIGFu
ZA0KPj4+Pj5ob3cgDQo+Pj4+PiB0byBzdHJ1Y3R1cmUgdGhlIG1vZGVscyBhcmUgdGhlIHR3byBi
bG9ja2luZyBmYWN0b3JzIHRvIHB1Ymxpc2ggWUFORw0KPj4+Pj4gbW9kZWxzLiBJZiB5b3UgZGlz
YWdyZWUgb3IgZG9uJ3Qgc2VlIHRoaXMsIGxldCBtZSBrbm93LCBJIHNob3VsZA0KPj4+Pj4gY29t
bXVuaWNhdGUgYmV0dGVyLg0KPj4+PiANCj4+Pj4gRXZlbiBpZiBpdCBtYXkgc3BvaWwgeW91ciBk
YXksIEkgZGlzYWdyZWUgdGhhdCB0aGVyZSBpcyBhIGJsb2NraW5nDQo+Pj4+IGZhY3RvciB0aGF0
IHNob3VsZCBzdG9wIHVzIGZyb20gcHVibGlzaGluZyBtb2RlbHMuIFRoZXJlIHNlZW0gdG8gYmUN
Cj4+Pj4gd2F5cyB0byBhZGRyZXNzIHRoZSByZXF1aXJlbWVudHMgd2l0aG91dCBoYXZpbmcgdG8g
YmxvY2sgYWxsIHdvcmsgb3INCj4+Pj4gdG8gcmVkbyB3aGF0IHRoYXQgd2UgaGF2ZSBwdWJsaXNo
ZWQuIEJ1dCBzdXJlLCBpZiB5b3UgbWFrZSBpdCBhDQo+Pj4+IGJsb2NraW5nIGZhY3RvciwgaXQg
d2lsbCBiZSBvbmUuDQo+Pj4gDQo+Pj4gSSBhZ3JlZSB3aXRoIEp1ZXJnZW4uIEl0IGlzIG5vdCBj
bGVhciB0byBtZSBob3cgdGhlIHByb3Bvc2VkIHNwbGl0DQo+Pj5iZXR3ZWVuIGludGVuZGVkIGFu
ZCBhcHBsaWVkIGNvbmZpZ3VyYXRpb24gaXMgc3VwcG9zZWQgdG8gYWZmZWN0IHRoZQ0KPj4+ZGF0
YSBtb2RlbHMgd2UgYXJlIHdvcmtpbmcgb24uDQo+PiANCj4+IA0KPj4gQXMgSSB1bmRlcnN0YW5k
IGl0LCBzb2x1dGlvbiAjMSBhZmZlY3RzIHRoZSBtb2RlbHMgdGhlbXNlbHZlcywgd2hlcmVhcw0K
Pj5zb2x1dGlvbnMgIzIgYW5kICMzIGFyZSB0cmFuc3BhcmVudCB0byB0aGUgbW9kZWxzLg0KPg0K
PlRoZW4gIzEgbG9va3MgbGlrZSBhIG5vbi1zdGFydGVyIHRvIG1lLg0KDQpJ4oCZZCBsaWtlIHRv
IHBvaW50IG91dCB0aGF0IHdlIGFsc28gaGF2ZSB0aGUgcmVxdWlyZW1lbnQgdG8gYWxsb3cgcmV0
cmlldmFsDQpvZiBkZXJpdmVkLXN0YXRlIGFsb25nIHdpdGggaW50ZW5kZWQtY29uZmlnIGFuZCBh
cHBsaWVkLWNvbmZpZy4gVGhpcyB3aWxsDQpyZXF1aXJlIG1vZGlmaWNhdGlvbiB0byBtb3N0IG9m
IHRoZSBleGlzdGluZyBZQU5HIGRyYWZ0cyBhcyBtb3N0IG5vdyBoYXZlDQpzZXBhcmF0ZSB0cmVl
cyBmb3IgY29uZmlnIGFuZCBvcGVyYXRpb25hbCBzdGF0ZS4gTm90ZSB0aGF0IHRoaXMgaXMNCmRp
c2N1c3NlZCBpbiBzZWN0aW9ucyA2LCA3LjMsIGFuZCA3LjQgb2YNCmh0dHBzOi8vd3d3LmlldGYu
b3JnL2lkL2RyYWZ0LXdpbHRvbi1uZXRtb2Qtb3BzdGF0ZS15YW5nLTAyLnR4dC4NCg0KVGhhbmtz
LA0KQWNlZSANCg0KDQo+DQo+TGFkYQ0KPg0KPj4gDQo+PiBLZW50DQo+PiANCj4+IA0KPj4gDQo+
Pj4gTGFkYQ0KPj4+IA0KPj4+PiANCj4+Pj4+IEkgaG9wZSB0aGF0IG5vYm9keSByZWFsbHkgYmVs
aWV2ZXMgdGhhdCBiZWNhdXNlIHNvbWUgcGVvcGxlIGluIElFVEYNCj4+Pj4+KG9yIA0KPj4+Pj4g
aW4gYW55IG90aGVyIFNET3MpIHRoaW5rcyB0aGF0IHdoYXQgdGhvc2Ugb3BlcmF0b3JzIHdhbnQg
aXMgYSBiYWQNCj4+Pj4+aWRlYSwgDQo+Pj4+PiB0aG9zZSBvcGVyYXRvcnMgd2lsbCBub3QgZ2V0
IHdoYXQgdGhleSByZXF1ZXN0L3BheSBmb3IgZnJvbSB0aGVpcg0KPj4+Pj5zdXBwbGllcnMuDQo+
Pj4+IA0KPj4+PiBUbyBiZSBmYWlyLCB0aG9zZSBvcGVyYXRvcnMgYWxzbyB0ZWxsIHVzIHRoYXQg
dGhleSB1c2UgcHJvdG9jb2xzIHRoYXQNCj4+Pj4gYXJlIG5vdCBJRVRGIHByb3RvY29scyBhbmQg
aXQgcmVtYWlucyBzb21ld2hhdCB1bmNsZWFyIHdoYXQgdGhvc2UNCj4+Pj4gcHJvdG9jb2xzIGFy
ZSB3ZSBhcmUgZXhwZWN0ZWQgdG8gb3B0aW1pemUgZGF0YSBtb2RlbCBzb2x1dGlvbnMgZm9yLg0K
Pj4+PiANCj4+Pj4gL2pzDQo+Pj4+IA0KPj4+PiAtLSANCj4+Pj4gSnVlcmdlbiBTY2hvZW53YWVs
ZGVyICAgICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4+Pj4gUGhvbmU6
ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwg
R2VybWFueQ0KPj4+PiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwOi8vd3d3
LmphY29icy11bml2ZXJzaXR5LmRlLz4NCj4+Pj4gDQo+Pj4+IF9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4+
Pj4gbmV0bW9kQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz
dGluZm8vbmV0bW9kDQo+Pj4gDQo+Pj4gLS0NCj4+PiBMYWRpc2xhdiBMaG90a2EsIENaLk5JQyBM
YWJzDQo+Pj4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4+PiANCj4+PiANCj4+PiANCj4+PiANCj4+
PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IG5l
dG1vZCBtYWlsaW5nIGxpc3QNCj4+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPg0KPi0tDQo+TGFkaXNsYXYgTGhvdGth
LCBDWi5OSUMgTGFicw0KPlBHUCBLZXkgSUQ6IEU3NEU4QzBDDQo+DQo+DQo+DQo+DQo+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5uZXRtb2QgbWFpbGlu
ZyBsaXN0DQo+bmV0bW9kQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9uZXRtb2QNCg0K


From nobody Wed Dec 23 07:46:47 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7F81A1ADD for ; Wed, 23 Dec 2015 07:46:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 VWfqBThUlJ5V for ; Wed, 23 Dec 2015 07:46:42 -0800 (PST)
Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::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 F22BD1A1A10 for ; Wed, 23 Dec 2015 07:46:41 -0800 (PST)
Received: by mail-lb0-x22b.google.com with SMTP id bc4so48462802lbc.2 for ; Wed, 23 Dec 2015 07:46:41 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=QHnNoojdx9ClECR3DvdIuJJb7iXIagDqYdCYePIOL7U=; b=SexFWwJN2bJ6LYtI4UfbTVU6M4X1O4a8OPfwo1K3GY5kFqZg3QHboULWWcepdXfzzG aPk+cILsr0xU1z1TtJPYEFLag8wEVVOhvO/v5lqpbuh1Pk+ZUtrloMG8ottbhSoH3C0h JpDd8ehlB3Kv1jqcl4XvjsQjX8fTsdbUZnqTTpLJzhXzGQjolXwC751QRh5vWYx0gRw8 ivIB7FG1MSRuyBsFS98wqEq6OfKjeehpFDK8UhtGQP/n4P6XqaaWx28PyB0S2WG3TaTP 9ou3K01nV1m7ZVKz77lYVN72O8xb/sYkON08z//oP5f9XitxuQcfP6GU57snDpWw4Bs8 pa3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QHnNoojdx9ClECR3DvdIuJJb7iXIagDqYdCYePIOL7U=; b=h3WvkCeGJTD9EURo5jbTOuuEyCjG7bOkCHInzEcCmtbBTmo5KbaMAPhSuQotOQnHRN pxNuuXUsKMmfeMuzb4kbpu0IosVK1AVkbz7gP7RTpUGGqQCC2liHcKhQlpJEMTBEbohT QI7c0MDEiHv1AaQhccxB0aaZCMOVwMY3s7cFu6hmpxWT+oGFZxVbgDIq+KmZTaMOtJeN vpSq1FYhudyrn/S/O4YNpMf0hdAkGtJUjHh3NqzVULDVe5QAwZbN2K/T6USk4xpctbj1 Y3CyNzLIa0H76vkw5meHyvgDjqN7Ub1f7idrrG8K3txFEDRK2lYkvdtRt5JJGhmXjjzl JRSA==
X-Gm-Message-State: ALoCoQlvdUckv6mCrgtPpka4zepaUy8bhICwnvk0i6P38Scn9n1D0SPxsFbHgQWU1obFRtr0uBq6zHG5Xq2R5h0Fk7BvnIu1ow==
MIME-Version: 1.0
X-Received: by 10.112.141.70 with SMTP id rm6mr8554034lbb.94.1450885600057; Wed, 23 Dec 2015 07:46:40 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Wed, 23 Dec 2015 07:46:39 -0800 (PST)
In-Reply-To: 
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>  <56783B45.1020505@cisco.com> <20151221180231.GC43694@elstar.local> <147269F5-7B47-4614-9C08-948E8B5FC65C@nic.cz>  <6AFC7C6C-61B7-4310-A0CA-08A7CD76A899@nic.cz> 
Date: Wed, 23 Dec 2015 07:46:39 -0800
Message-ID: 
From: Andy Bierman 
To: "Acee Lindem (acee)" 
Content-Type: multipart/alternative; boundary=001a11c3819ccd34e5052792a099
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2015 15:46:44 -0000

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

On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (acee)  wrote:

>
> On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
>  wrote:
>
> >
> >> On 23 Dec 2015, at 04:06, Kent Watsen  wrote:
> >>
> >>
> >>
> >>
> >>
> >>
> >> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
> >> wrote:
> >>
> >>>
> >>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
> >>>> wrote:
> >>>>
> >>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
> >>>>
> >>>>> I hope that nobody disagrees that the operational state design and
> >>>>>how
> >>>>> to structure the models are the two blocking factors to publish YAN=
G
> >>>>> models. If you disagree or don't see this, let me know, I should
> >>>>> communicate better.
> >>>>
> >>>> Even if it may spoil your day, I disagree that there is a blocking
> >>>> factor that should stop us from publishing models. There seem to be
> >>>> ways to address the requirements without having to block all work or
> >>>> to redo what that we have published. But sure, if you make it a
> >>>> blocking factor, it will be one.
> >>>
> >>> I agree with Juergen. It is not clear to me how the proposed split
> >>>between intended and applied configuration is supposed to affect the
> >>>data models we are working on.
> >>
> >>
> >> As I understand it, solution #1 affects the models themselves, whereas
> >>solutions #2 and #3 are transparent to the models.
> >
> >Then #1 looks like a non-starter to me.
>
> I=E2=80=99d like to point out that we also have the requirement to allow =
retrieval
> of derived-state along with intended-config and applied-config. This will
> require modification to most of the existing YANG drafts as most now have
> separate trees for config and operational state. Note that this is
> discussed in sections 6, 7.3, and 7.4 of
> https://www.ietf.org/id/draft-wilton-netmod-opstate-yang-02.txt.
>
>
A NETCONF  with a subtree filter  can retrieveg both config and
non-config subtrees
at the same time.  A new RPC can be added (or existing  RPC extended)
to
filter various conditions.  I don't see how the YANG data layout affects
the definition
of "rpc" statements in another module.


Thanks,
> Acee
>


Andy


>
>
> >
> >Lada
> >
> >>
> >> Kent
> >>
> >>
> >>
> >>> Lada
> >>>
> >>>>
> >>>>> I hope that nobody really believes that because some people in IETF
> >>>>>(or
> >>>>> in any other SDOs) thinks that what those operators want is a bad
> >>>>>idea,
> >>>>> those operators will not get what they request/pay for from their
> >>>>>suppliers.
> >>>>
> >>>> To be fair, those operators also tell us that they use protocols tha=
t
> >>>> are not IETF protocols and it remains somewhat unclear what those
> >>>> protocols are we are expected to optimize data model solutions for.
> >>>>
> >>>> /js
> >>>>
> >>>> --
> >>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germa=
ny
> >>>> Fax:   +49 421 200 3103         
> >>>>
> >>>> _______________________________________________
> >>>> netmod mailing list
> >>>> netmod@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/netmod
> >>>
> >>> --
> >>> Ladislav Lhotka, CZ.NIC Labs
> >>> PGP Key ID: E74E8C0C
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> netmod mailing list
> >>> netmod@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netmod
> >
> >--
> >Ladislav Lhotka, CZ.NIC Labs
> >PGP Key ID: E74E8C0C
> >
> >
> >
> >
> >_______________________________________________
> >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
>

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




On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (acee) &=
lt;acee@cisco.com&g=
t; wrote:


On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"

<netmod-bounces@ietf.org =
on behalf of lhotka@nic.cz> wrote:<=
br>


>

>> On 23 Dec 2015, at 04:06, Kent Watsen <kwatsen@juniper.net> wrote:

>>

>>

>>

>>

>>

>>

>> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka&qu=
ot;

>><netmod-bounces@ietf.=
org on behalf of lhotka@nic.cz>=
 wrote:

>>

>>>

>>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder

>>>><j.schoenwaelder@jacobs-university.de> wrote:

>>>>

>>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wr=
ote:

>>>>

>>>>> I hope that nobody disagrees that the operational stat=
e design and

>>>>>how

>>>>> to structure the models are the two blocking factors t=
o publish YANG

>>>>> models. If you disagree or don't see this, let me =
know, I should

>>>>> communicate better.

>>>>

>>>> Even if it may spoil your day, I disagree that there is a =
blocking

>>>> factor that should stop us from publishing models. There s=
eem to be

>>>> ways to address the requirements without having to block a=
ll work or

>>>> to redo what that we have published. But sure, if you make=
 it a

>>>> blocking factor, it will be one.

>>>

>>> I agree with Juergen. It is not clear to me how the proposed s=
plit

>>>between intended and applied configuration is supposed to affec=
t the

>>>data models we are working on.

>>

>>

>> As I understand it, solution #1 affects the models themselves, whe=
reas

>>solutions #2 and #3 are transparent to the models.

>

>Then #1 looks like a non-starter to me.



I=E2=80=99d like to point out that we also have the requirement to allow re=
trieval

of derived-state along with intended-config and applied-config. This will
require modification to most of the existing YANG drafts as most now have
separate trees for config and operational state. Note that this is

discussed in sections 6, 7.3, and 7.4 of

https://www.ietf.org/id/draft-wilton-=
netmod-opstate-yang-02.txt.



A NETCONF <get> with a subtree f=
ilter =C2=A0can retrieveg both config and non-config subtrees
at =
the same time.=C2=A0 A new RPC can be added (or existing <get> RPC ex=
tended) to
filter various conditions.=C2=A0 I don't see how t=
he YANG data layout affects the definition
of "rpc" sta=
tements in another module.



Thanks,

Acee


Andy
=C2=
=A0





>

>Lada

>

>>

>> Kent

>>

>>

>>

>>> Lada

>>>

>>>>

>>>>> I hope that nobody really believes that because some p=
eople in IETF

>>>>>(or

>>>>> in any other SDOs) thinks that what those operators wa=
nt is a bad

>>>>>idea,

>>>>> those operators will not get what they request/pay for=
 from their

>>>>>suppliers.

>>>>

>>>> To be fair, those operators also tell us that they use pro=
tocols that

>>>> are not IETF protocols and it remains somewhat unclear wha=
t those

>>>> protocols are we are expected to optimize data model solut=
ions for.

>>>>

>>>> /js

>>>>

>>>> --

>>>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Jacobs University Bremen gGmbH

>>>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C=
ampus 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/n=
etmod

>>>

>>> --

>>> Ladislav Lhotka, CZ.NIC Labs

>>> PGP Key ID: E74E8C0C

>>>

>>>

>>>

>>>

>>> _______________________________________________

>>> netmod mailing list

>>> netmod@ietf.org

>>> https://www.ietf.org/mailman/listinfo/net=
mod

>

>--

>Ladislav Lhotka, CZ.NIC Labs

>PGP Key ID: E74E8C0C

>

>

>

>

>_______________________________________________

>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





--001a11c3819ccd34e5052792a099--


From nobody Wed Dec 23 08:11:21 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266E01A1B3D for ; Wed, 23 Dec 2015 08:11:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 F1iyKTZsUGfo for ; Wed, 23 Dec 2015 08:11:17 -0800 (PST)
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 2D04F1A1B3C for ; Wed, 23 Dec 2015 08:11:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20287; q=dns/txt; s=iport; t=1450887077; x=1452096677; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XfwSFvYPu2CiaEfjsUAOmQDWQ2IjrlvY2XTFHmveX3o=; b=eqg/SPSwBuXvEszFvjC16+qympLsjIMPXsf1d2ZOS3sGzi8hdagfZxim cNyWMCcet3umjXFjsWeCBsbHyk5WlgJwF7WIcfAN4677G9Jh5+veSv+nN Eoo2PTEzYZZbKNTQzQERMybxcG++mEt3KxRVdAq8/tzdF8yVWfIo8X/ty c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BNAgCAxnpW/5NdJa1bA4JuTFJtBoxLs?= =?us-ascii?q?HEBDYFjGAEJhSNKAhyBCzgUAQEBAQEBAYEKhDQBAQEDAQEBASBLCw4CAgEIEAE?= =?us-ascii?q?DAQIBJwMCAgIZDAsUCQgCBA4FG4gMCA6uFpIHAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBGASLUYRtCgEMEQmCVYFKBZcDAY1LgVyNHYpHg3MBIAEBQoQLcgGEH4EIAQE?= =?us-ascii?q?B?=
X-IronPort-AV: E=Sophos; i="5.20,469,1444694400"; d="scan'208,217"; a="60921149"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Dec 2015 16:11:15 +0000
Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id tBNGBFiY010675 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 23 Dec 2015 16:11:15 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 23 Dec 2015 11:11:14 -0500
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.1104.009; Wed, 23 Dec 2015 11:11:14 -0500
From: "Acee Lindem (acee)" 
To: Andy Bierman 
Thread-Topic: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
Thread-Index: AQHROST+Qi5eUPyFCUOmbJF1PR1M/Z7Q8W4AgACOLQCAAASngIAEjK+AgAAEHICAABYDAIACFGgAgABYGQCAABvKAIAAYGWA//+zBYA=
Date: Wed, 23 Dec 2015 16:11:14 +0000
Message-ID: 
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>  <56783B45.1020505@cisco.com> <20151221180231.GC43694@elstar.local> <147269F5-7B47-4614-9C08-948E8B5FC65C@nic.cz>  <6AFC7C6C-61B7-4310-A0CA-08A7CD76A899@nic.cz>  
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.199]
Content-Type: multipart/alternative; boundary="_000_D2A0308C45B5Caceeciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2015 16:11:21 -0000

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

DQoNCkZyb206IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1
bWF3b3Jrcy5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBEZWNlbWJlciAyMywgMjAxNSBhdCAxMDo0
NiBBTQ0KVG86IEFjZWUgTGluZGVtIDxhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNlZUBjaXNjby5j
b20+Pg0KQ2M6IExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jejxtYWlsdG86bGhvdGthQG5p
Yy5jej4+LCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldDxtYWlsdG86a3dhdHNlbkBq
dW5pcGVyLm5ldD4+LCAibmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+IiA8
bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtu
ZXRtb2RdIE5FVE1PRCBXRyBMQzogZHJhZnQtaWV0Zi1uZXRtb2Qtb3BzdGF0ZS1yZXFzLTAxDQoN
Cg0KDQpPbiBXZWQsIERlYyAyMywgMjAxNSBhdCA3OjAxIEFNLCBBY2VlIExpbmRlbSAoYWNlZSkg
PGFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpPbiAxMi8y
My8xNSwgMzoyMiBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgTGFkaXNsYXYgTGhvdGthIg0KPG5l
dG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24g
YmVoYWxmIG9mIGxob3RrYUBuaWMuY3o8bWFpbHRvOmxob3RrYUBuaWMuY3o+PiB3cm90ZToNCg0K
Pg0KPj4gT24gMjMgRGVjIDIwMTUsIGF0IDA0OjA2LCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5p
cGVyLm5ldDxtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldD4+IHdyb3RlOg0KPj4NCj4+DQo+Pg0K
Pj4NCj4+DQo+Pg0KPj4gT24gMTIvMjEvMTUsIDI6MjEgUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9m
IExhZGlzbGF2IExob3RrYSINCj4+PG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRt
b2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIGxob3RrYUBuaWMuY3o8bWFpbHRvOmxo
b3RrYUBuaWMuY3o+PiB3cm90ZToNCj4+DQo+Pj4NCj4+Pj4gT24gMjEgRGVjIDIwMTUsIGF0IDE5
OjAyLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXINCj4+Pj48ai5zY2hvZW53YWVsZGVyQGphY29icy11
bml2ZXJzaXR5LmRlPG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+
PiB3cm90ZToNCj4+Pj4NCj4+Pj4gT24gTW9uLCBEZWMgMjEsIDIwMTUgYXQgMDY6NDc6NDlQTSAr
MDEwMCwgQmVub2l0IENsYWlzZSB3cm90ZToNCj4+Pj4NCj4+Pj4+IEkgaG9wZSB0aGF0IG5vYm9k
eSBkaXNhZ3JlZXMgdGhhdCB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgZGVzaWduIGFuZA0KPj4+Pj5o
b3cNCj4+Pj4+IHRvIHN0cnVjdHVyZSB0aGUgbW9kZWxzIGFyZSB0aGUgdHdvIGJsb2NraW5nIGZh
Y3RvcnMgdG8gcHVibGlzaCBZQU5HDQo+Pj4+PiBtb2RlbHMuIElmIHlvdSBkaXNhZ3JlZSBvciBk
b24ndCBzZWUgdGhpcywgbGV0IG1lIGtub3csIEkgc2hvdWxkDQo+Pj4+PiBjb21tdW5pY2F0ZSBi
ZXR0ZXIuDQo+Pj4+DQo+Pj4+IEV2ZW4gaWYgaXQgbWF5IHNwb2lsIHlvdXIgZGF5LCBJIGRpc2Fn
cmVlIHRoYXQgdGhlcmUgaXMgYSBibG9ja2luZw0KPj4+PiBmYWN0b3IgdGhhdCBzaG91bGQgc3Rv
cCB1cyBmcm9tIHB1Ymxpc2hpbmcgbW9kZWxzLiBUaGVyZSBzZWVtIHRvIGJlDQo+Pj4+IHdheXMg
dG8gYWRkcmVzcyB0aGUgcmVxdWlyZW1lbnRzIHdpdGhvdXQgaGF2aW5nIHRvIGJsb2NrIGFsbCB3
b3JrIG9yDQo+Pj4+IHRvIHJlZG8gd2hhdCB0aGF0IHdlIGhhdmUgcHVibGlzaGVkLiBCdXQgc3Vy
ZSwgaWYgeW91IG1ha2UgaXQgYQ0KPj4+PiBibG9ja2luZyBmYWN0b3IsIGl0IHdpbGwgYmUgb25l
Lg0KPj4+DQo+Pj4gSSBhZ3JlZSB3aXRoIEp1ZXJnZW4uIEl0IGlzIG5vdCBjbGVhciB0byBtZSBo
b3cgdGhlIHByb3Bvc2VkIHNwbGl0DQo+Pj5iZXR3ZWVuIGludGVuZGVkIGFuZCBhcHBsaWVkIGNv
bmZpZ3VyYXRpb24gaXMgc3VwcG9zZWQgdG8gYWZmZWN0IHRoZQ0KPj4+ZGF0YSBtb2RlbHMgd2Ug
YXJlIHdvcmtpbmcgb24uDQo+Pg0KPj4NCj4+IEFzIEkgdW5kZXJzdGFuZCBpdCwgc29sdXRpb24g
IzEgYWZmZWN0cyB0aGUgbW9kZWxzIHRoZW1zZWx2ZXMsIHdoZXJlYXMNCj4+c29sdXRpb25zICMy
IGFuZCAjMyBhcmUgdHJhbnNwYXJlbnQgdG8gdGhlIG1vZGVscy4NCj4NCj5UaGVuICMxIGxvb2tz
IGxpa2UgYSBub24tc3RhcnRlciB0byBtZS4NCg0KSeKAmWQgbGlrZSB0byBwb2ludCBvdXQgdGhh
dCB3ZSBhbHNvIGhhdmUgdGhlIHJlcXVpcmVtZW50IHRvIGFsbG93IHJldHJpZXZhbA0Kb2YgZGVy
aXZlZC1zdGF0ZSBhbG9uZyB3aXRoIGludGVuZGVkLWNvbmZpZyBhbmQgYXBwbGllZC1jb25maWcu
IFRoaXMgd2lsbA0KcmVxdWlyZSBtb2RpZmljYXRpb24gdG8gbW9zdCBvZiB0aGUgZXhpc3Rpbmcg
WUFORyBkcmFmdHMgYXMgbW9zdCBub3cgaGF2ZQ0Kc2VwYXJhdGUgdHJlZXMgZm9yIGNvbmZpZyBh
bmQgb3BlcmF0aW9uYWwgc3RhdGUuIE5vdGUgdGhhdCB0aGlzIGlzDQpkaXNjdXNzZWQgaW4gc2Vj
dGlvbnMgNiwgNy4zLCBhbmQgNy40IG9mDQpodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC13
aWx0b24tbmV0bW9kLW9wc3RhdGUteWFuZy0wMi50eHQuDQoNCg0KQSBORVRDT05GIDxnZXQ+IHdp
dGggYSBzdWJ0cmVlIGZpbHRlciAgY2FuIHJldHJpZXZlZyBib3RoIGNvbmZpZyBhbmQgbm9uLWNv
bmZpZyBzdWJ0cmVlcw0KYXQgdGhlIHNhbWUgdGltZS4gIEEgbmV3IFJQQyBjYW4gYmUgYWRkZWQg
KG9yIGV4aXN0aW5nIDxnZXQ+IFJQQyBleHRlbmRlZCkgdG8NCmZpbHRlciB2YXJpb3VzIGNvbmRp
dGlvbnMuICBJIGRvbid0IHNlZSBob3cgdGhlIFlBTkcgZGF0YSBsYXlvdXQgYWZmZWN0cyB0aGUg
ZGVmaW5pdGlvbg0Kb2YgInJwYyIgc3RhdGVtZW50cyBpbiBhbm90aGVyIG1vZHVsZS4NCg0KVGhl
cmUgaXMgdGhlIHJlcXVpcmVtZW50IHRvIGJlIGFibGUgdG8gZG8gdGhlIHJldHJpZXZhbHMgYnV0
IHRoZXJlIGlzIGFsc28gdGhpcyByZXF1aXJlbWVudDoNCg0KDQogQy4gIFRoZSBtYXBwaW5ncyBu
ZWVkcyB0byBiZSBwcm9ncmFtbWF0aWNhbGx5IGNvbnN1bWFibGUNCg0KTm93LCBpZiB0aGUgZGVy
aXZlZC1zdGF0ZSBub2RlcyBhcmUgbG9jYXRlZCB3aXRoIHRoZSBjb25maWctbm9kZXMsIHRoZW4g
dGhpcyBpcyByZWFkaWx5IHNhdGlzZmllZC4gQW5vdGhlciB3YXkgb2Ygc2F0aXNmeWluZyB0aGUg
cmVxdWlyZW1lbnQgbWF5IGJlIHN0cnVjdHVyYWwgYW5kIG5hbWluZyBjb252ZW50aW9ucyBidXQg
dGhpcyBpcyBub3QgYXMgc3VyZSBhcyBjby1sb2NhdGlvbi4NCg0KVGhhbmtzLA0KQWNlZQ0KDQoN
Cg0KVGhhbmtzLA0KQWNlZQ0KDQoNCkFuZHkNCg0KDQoNCj4NCj5MYWRhDQo+DQo+Pg0KPj4gS2Vu
dA0KPj4NCj4+DQo+Pg0KPj4+IExhZGENCj4+Pg0KPj4+Pg0KPj4+Pj4gSSBob3BlIHRoYXQgbm9i
b2R5IHJlYWxseSBiZWxpZXZlcyB0aGF0IGJlY2F1c2Ugc29tZSBwZW9wbGUgaW4gSUVURg0KPj4+
Pj4ob3INCj4+Pj4+IGluIGFueSBvdGhlciBTRE9zKSB0aGlua3MgdGhhdCB3aGF0IHRob3NlIG9w
ZXJhdG9ycyB3YW50IGlzIGEgYmFkDQo+Pj4+PmlkZWEsDQo+Pj4+PiB0aG9zZSBvcGVyYXRvcnMg
d2lsbCBub3QgZ2V0IHdoYXQgdGhleSByZXF1ZXN0L3BheSBmb3IgZnJvbSB0aGVpcg0KPj4+Pj5z
dXBwbGllcnMuDQo+Pj4+DQo+Pj4+IFRvIGJlIGZhaXIsIHRob3NlIG9wZXJhdG9ycyBhbHNvIHRl
bGwgdXMgdGhhdCB0aGV5IHVzZSBwcm90b2NvbHMgdGhhdA0KPj4+PiBhcmUgbm90IElFVEYgcHJv
dG9jb2xzIGFuZCBpdCByZW1haW5zIHNvbWV3aGF0IHVuY2xlYXIgd2hhdCB0aG9zZQ0KPj4+PiBw
cm90b2NvbHMgYXJlIHdlIGFyZSBleHBlY3RlZCB0byBvcHRpbWl6ZSBkYXRhIG1vZGVsIHNvbHV0
aW9ucyBmb3IuDQo+Pj4+DQo+Pj4+IC9qcw0KPj4+Pg0KPj4+PiAtLQ0KPj4+PiBKdWVyZ2VuIFNj
aG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPj4+
PiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBC
cmVtZW4gfCBHZXJtYW55DQo+Pj4+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0
dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBuZXRtb2QgbWFpbGluZyBs
aXN0DQo+Pj4+IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KPj4+PiBo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KPj4+DQo+Pj4gLS0N
Cj4+PiBMYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+Pj4gUEdQIEtleSBJRDogRTc0RThD
MEMNCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4+IG5ldG1vZEBp
ZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+DQo+LS0NCj5MYWRpc2xhdiBMaG90a2EsIENaLk5J
QyBMYWJzDQo+UEdQIEtleSBJRDogRTc0RThDMEMNCj4NCj4NCj4NCj4NCj5fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5ldG1vZCBtYWlsaW5nIGxpc3QN
Cj5uZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCj5odHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQpfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGll
dGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL25ldG1vZA0KDQo=

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj48YnI+DQo8L2Rp
dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K
PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxp
Z246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVIt
TEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGlu
OyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JE
RVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJm
b250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+QW5keSBCaWVybWFuICZsdDs8YSBocmVmPSJt
YWlsdG86YW5keUB5dW1hd29ya3MuY29tIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0Ozxicj4N
CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+V2VkbmVzZGF5LCBE
ZWNlbWJlciAyMywgMjAxNSBhdCAxMDo0NiBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo
dDpib2xkIj5UbzogPC9zcGFuPkFjZWUgTGluZGVtICZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBj
aXNjby5jb20iPmFjZWVAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13
ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5MYWRpc2xhdiBMaG90a2EgJmx0OzxhIGhyZWY9Im1haWx0
bzpsaG90a2FAbmljLmN6Ij5saG90a2FAbmljLmN6PC9hPiZndDssIEtlbnQgV2F0c2VuICZsdDs8
YSBocmVmPSJtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldCI+a3dhdHNlbkBqdW5pcGVyLm5ldDwv
YT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0
Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRt
b2RAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5T
dWJqZWN0OiA8L3NwYW4+UmU6IFtuZXRtb2RdIE5FVE1PRCBXRyBMQzogZHJhZnQtaWV0Zi1uZXRt
b2Qtb3BzdGF0ZS1yZXFzLTAxPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2Nr
cXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JE
RVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1
OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWls
X2V4dHJhIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gV2VkLCBEZWMgMjMsIDIw
MTUgYXQgNzowMSBBTSwgQWNlZSBMaW5kZW0gKGFjZWUpIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8
YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5hY2VlQGNpc2Nv
LmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf
cXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xp
ZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxicj4NCk9uIDEyLzIzLzE1LCAzOjIyIEFNLCAmcXVvdDtu
ZXRtb2Qgb24gYmVoYWxmIG9mIExhZGlzbGF2IExob3RrYSZxdW90Ozxicj4NCiZsdDs8YSBocmVm
PSJtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmciPm5ldG1vZC1ib3VuY2VzQGlldGYub3Jn
PC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzpsaG90a2FAbmljLmN6Ij5saG90a2FA
bmljLmN6PC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IE9uIDIz
IERlYyAyMDE1LCBhdCAwNDowNiwgS2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzprd2F0
c2VuQGp1bmlwZXIubmV0Ij5rd2F0c2VuQGp1bmlwZXIubmV0PC9hPiZndDsgd3JvdGU6PGJyPg0K
Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQom
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgT24gMTIvMjEvMTUsIDI6MjEgUE0s
ICZxdW90O25ldG1vZCBvbiBiZWhhbGYgb2YgTGFkaXNsYXYgTGhvdGthJnF1b3Q7PGJyPg0KJmd0
OyZndDsmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnIj5uZXRtb2Qt
Ym91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86bGhvdGth
QG5pYy5jeiI+bGhvdGthQG5pYy5jejwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBPbiAyMSBEZWMgMjAxNSwgYXQgMTk6
MDIsIEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmbHQ7PGEgaHJl
Zj0ibWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSI+ai5zY2hvZW53
YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgT24gTW9uLCBEZWMgMjEsIDIwMTUgYXQgMDY6
NDc6NDlQTSAmIzQzOzAxMDAsIEJlbm9pdCBDbGFpc2Ugd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7
Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgaG9wZSB0aGF0IG5vYm9keSBkaXNhZ3Jl
ZXMgdGhhdCB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgZGVzaWduIGFuZDxicj4NCiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7aG93PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdG8gc3RydWN0dXJlIHRoZSBt
b2RlbHMgYXJlIHRoZSB0d28gYmxvY2tpbmcgZmFjdG9ycyB0byBwdWJsaXNoIFlBTkc8YnI+DQom
Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtb2RlbHMuIElmIHlvdSBkaXNhZ3JlZSBvciBkb24ndCBzZWUg
dGhpcywgbGV0IG1lIGtub3csIEkgc2hvdWxkPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgY29t
bXVuaWNhdGUgYmV0dGVyLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsm
Z3Q7IEV2ZW4gaWYgaXQgbWF5IHNwb2lsIHlvdXIgZGF5LCBJIGRpc2FncmVlIHRoYXQgdGhlcmUg
aXMgYSBibG9ja2luZzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgZmFjdG9yIHRoYXQgc2hvdWxkIHN0
b3AgdXMgZnJvbSBwdWJsaXNoaW5nIG1vZGVscy4gVGhlcmUgc2VlbSB0byBiZTxicj4NCiZndDsm
Z3Q7Jmd0OyZndDsgd2F5cyB0byBhZGRyZXNzIHRoZSByZXF1aXJlbWVudHMgd2l0aG91dCBoYXZp
bmcgdG8gYmxvY2sgYWxsIHdvcmsgb3I8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHRvIHJlZG8gd2hh
dCB0aGF0IHdlIGhhdmUgcHVibGlzaGVkLiBCdXQgc3VyZSwgaWYgeW91IG1ha2UgaXQgYTxicj4N
CiZndDsmZ3Q7Jmd0OyZndDsgYmxvY2tpbmcgZmFjdG9yLCBpdCB3aWxsIGJlIG9uZS48YnI+DQom
Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgSSBhZ3JlZSB3aXRoIEp1ZXJnZW4uIEl0IGlz
IG5vdCBjbGVhciB0byBtZSBob3cgdGhlIHByb3Bvc2VkIHNwbGl0PGJyPg0KJmd0OyZndDsmZ3Q7
YmV0d2VlbiBpbnRlbmRlZCBhbmQgYXBwbGllZCBjb25maWd1cmF0aW9uIGlzIHN1cHBvc2VkIHRv
IGFmZmVjdCB0aGU8YnI+DQomZ3Q7Jmd0OyZndDtkYXRhIG1vZGVscyB3ZSBhcmUgd29ya2luZyBv
bi48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgQXMgSSB1bmRlcnN0
YW5kIGl0LCBzb2x1dGlvbiAjMSBhZmZlY3RzIHRoZSBtb2RlbHMgdGhlbXNlbHZlcywgd2hlcmVh
czxicj4NCiZndDsmZ3Q7c29sdXRpb25zICMyIGFuZCAjMyBhcmUgdHJhbnNwYXJlbnQgdG8gdGhl
IG1vZGVscy48YnI+DQomZ3Q7PGJyPg0KJmd0O1RoZW4gIzEgbG9va3MgbGlrZSBhIG5vbi1zdGFy
dGVyIHRvIG1lLjxicj4NCjxicj4NCknigJlkIGxpa2UgdG8gcG9pbnQgb3V0IHRoYXQgd2UgYWxz
byBoYXZlIHRoZSByZXF1aXJlbWVudCB0byBhbGxvdyByZXRyaWV2YWw8YnI+DQpvZiBkZXJpdmVk
LXN0YXRlIGFsb25nIHdpdGggaW50ZW5kZWQtY29uZmlnIGFuZCBhcHBsaWVkLWNvbmZpZy4gVGhp
cyB3aWxsPGJyPg0KcmVxdWlyZSBtb2RpZmljYXRpb24gdG8gbW9zdCBvZiB0aGUgZXhpc3Rpbmcg
WUFORyBkcmFmdHMgYXMgbW9zdCBub3cgaGF2ZTxicj4NCnNlcGFyYXRlIHRyZWVzIGZvciBjb25m
aWcgYW5kIG9wZXJhdGlvbmFsIHN0YXRlLiBOb3RlIHRoYXQgdGhpcyBpczxicj4NCmRpc2N1c3Nl
ZCBpbiBzZWN0aW9ucyA2LCA3LjMsIGFuZCA3LjQgb2Y8YnI+DQo8YSBocmVmPSJodHRwczovL3d3
dy5pZXRmLm9yZy9pZC9kcmFmdC13aWx0b24tbmV0bW9kLW9wc3RhdGUteWFuZy0wMi50eHQiIHJl
bD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL2lkL2Ry
YWZ0LXdpbHRvbi1uZXRtb2Qtb3BzdGF0ZS15YW5nLTAyLnR4dDwvYT4uPGJyPg0KPGJyPg0KPC9i
bG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QSBORVRDT05GICZsdDtnZXQmZ3Q7
IHdpdGggYSBzdWJ0cmVlIGZpbHRlciAmbmJzcDtjYW4gcmV0cmlldmVnIGJvdGggY29uZmlnIGFu
ZCBub24tY29uZmlnIHN1YnRyZWVzPC9kaXY+DQo8ZGl2PmF0IHRoZSBzYW1lIHRpbWUuJm5ic3A7
IEEgbmV3IFJQQyBjYW4gYmUgYWRkZWQgKG9yIGV4aXN0aW5nICZsdDtnZXQmZ3Q7IFJQQyBleHRl
bmRlZCkgdG88L2Rpdj4NCjxkaXY+ZmlsdGVyIHZhcmlvdXMgY29uZGl0aW9ucy4mbmJzcDsgSSBk
b24ndCBzZWUgaG93IHRoZSBZQU5HIGRhdGEgbGF5b3V0IGFmZmVjdHMgdGhlIGRlZmluaXRpb248
L2Rpdj4NCjxkaXY+b2YgJnF1b3Q7cnBjJnF1b3Q7IHN0YXRlbWVudHMgaW4gYW5vdGhlciBtb2R1
bGUuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j
a3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhlcmUgaXMgdGhlIHJl
cXVpcmVtZW50IHRvIGJlIGFibGUgdG8gZG8gdGhlIHJldHJpZXZhbHMgYnV0IHRoZXJlIGlzIGFs
c28gdGhpcyByZXF1aXJlbWVudDo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPHBy
ZT4gQy4gIFRoZSBtYXBwaW5ncyBuZWVkcyB0byBiZSBwcm9ncmFtbWF0aWNhbGx5IGNvbnN1bWFi
bGU8L3ByZT4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Tm93LCBpZiB0aGUgZGVy
aXZlZC1zdGF0ZSBub2RlcyBhcmUgbG9jYXRlZCB3aXRoIHRoZSBjb25maWctbm9kZXMsIHRoZW4g
dGhpcyBpcyByZWFkaWx5IHNhdGlzZmllZC4gQW5vdGhlciB3YXkgb2Ygc2F0aXNmeWluZyB0aGUg
cmVxdWlyZW1lbnQgbWF5IGJlIHN0cnVjdHVyYWwgYW5kIG5hbWluZyBjb252ZW50aW9ucyBidXQg
dGhpcyBpcyBub3QgYXMgc3VyZSBhcyBjby1sb2NhdGlvbi4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJy
Pg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QWNlZSZuYnNwOzwvZGl2Pg0KPGRp
dj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2tx
dW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRF
Ui1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7
Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRy
YSI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48
YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdp
bjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgi
Pg0KVGhhbmtzLDxicj4NCkFjZWU8YnI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4NCjwvZGl2
Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QW5keTwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N
CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4
O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGJyPg0KPGJy
Pg0KJmd0Ozxicj4NCiZndDtMYWRhPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn
dDsgS2VudDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7Jmd0OyBMYWRhPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxi
cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgaG9wZSB0aGF0IG5vYm9keSByZWFsbHkgYmVsaWV2
ZXMgdGhhdCBiZWNhdXNlIHNvbWUgcGVvcGxlIGluIElFVEY8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7
Jmd0Oyhvcjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGluIGFueSBvdGhlciBTRE9zKSB0aGlu
a3MgdGhhdCB3aGF0IHRob3NlIG9wZXJhdG9ycyB3YW50IGlzIGEgYmFkPGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0OyZndDtpZGVhLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRob3NlIG9wZXJhdG9y
cyB3aWxsIG5vdCBnZXQgd2hhdCB0aGV5IHJlcXVlc3QvcGF5IGZvciBmcm9tIHRoZWlyPGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0OyZndDtzdXBwbGllcnMuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4N
CiZndDsmZ3Q7Jmd0OyZndDsgVG8gYmUgZmFpciwgdGhvc2Ugb3BlcmF0b3JzIGFsc28gdGVsbCB1
cyB0aGF0IHRoZXkgdXNlIHByb3RvY29scyB0aGF0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBhcmUg
bm90IElFVEYgcHJvdG9jb2xzIGFuZCBpdCByZW1haW5zIHNvbWV3aGF0IHVuY2xlYXIgd2hhdCB0
aG9zZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgcHJvdG9jb2xzIGFyZSB3ZSBhcmUgZXhwZWN0ZWQg
dG8gb3B0aW1pemUgZGF0YSBtb2RlbCBzb2x1dGlvbnMgZm9yLjxicj4NCiZndDsmZ3Q7Jmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IC9qczxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom
Z3Q7Jmd0OyZndDsmZ3Q7IC0tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBKdWVyZ2VuIFNjaG9lbndh
ZWxkZXImbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0phY29icyBVbml2
ZXJzaXR5IEJyZW1lbiBnR21iSDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgUGhvbmU6ICYjNDM7NDkg
NDIxIDIwMCAzNTg3Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0NhbXB1cyBSaW5n
IDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBGYXg6Jm5i
c3A7ICZuYnNwOyYjNDM7NDkgNDIxIDIwMCAzMTAzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyZsdDs8YSBocmVmPSJodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLyIgcmVs
PSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0
eS5kZS88L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7
IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0
OyZndDsmZ3Q7Jmd0OyBuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyA8
YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL25ldG1vZCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48YnI+DQomZ3Q7Jmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0OyZndDsgLS08YnI+DQomZ3Q7Jmd0OyZndDsgTGFkaXNsYXYgTGhvdGth
LCBDWi5OSUMgTGFiczxicj4NCiZndDsmZ3Q7Jmd0OyBQR1AgS2V5IElEOiBFNzRFOEMwQzxicj4N
CiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZn
dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyBuZXRtb2QgbWFpbGluZyBsaXN0
PGJyPg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1v
ZEBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJf
YmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+
PGJyPg0KJmd0Ozxicj4NCiZndDstLTxicj4NCiZndDtMYWRpc2xhdiBMaG90a2EsIENaLk5JQyBM
YWJzPGJyPg0KJmd0O1BHUCBLZXkgSUQ6IEU3NEU4QzBDPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+
DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDtfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzxicj4NCiZndDtuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KJmd0Ozxh
IGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQom
Z3Q7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Qi
IHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21h
aWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbmV0bW9kIG1haWxpbmcgbGlzdDxicj4N
CjxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+
DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIg
cmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp
bG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4N
CjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_D2A0308C45B5Caceeciscocom_--


From nobody Wed Dec 23 08:18:24 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 834B81A1B59 for ; Wed, 23 Dec 2015 08:18:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 QylsI6m0uwar for ; Wed, 23 Dec 2015 08:18:19 -0800 (PST)
Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 7741F1A1B51 for ; Wed, 23 Dec 2015 08:18:18 -0800 (PST)
Received: by mail-lf0-x22f.google.com with SMTP id z124so144874256lfa.3 for ; Wed, 23 Dec 2015 08:18:18 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=TVV07+vmQFIwjENUFelUboLBQmcZhYQGP2qmDVMzsxQ=; b=g2xH9As8bZSHj1AFNVNKAswOg5ogyNIE7Xb1doCC1KWPEK5fQHdqb9KFIj2zwwGiPw sUKDefcI2vyjPOweBnSrfS1ngEwvaxvQ0TlVXezKfFrRuO7z0RX7Kf/8cQYXBWoZohGN tlyiwdO+sATinO7GgxyPhredPmADMo4Wy9lsEdxq4uqeuO2fq1yk1sUvD6vjc7C+nKui jSHSvGJ97gLOTTV2TbJBBlC5hyiPlH+6bpKZhahoiX2Q6cJw/VCPOUvBxO1pIKmq9umx /m926aZmVmw/rsRBm9PgqMWaD4FQY0ZMRWP0cyEidFv5o47wpzsQPDeiraTnWrwJMcIk mFzg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TVV07+vmQFIwjENUFelUboLBQmcZhYQGP2qmDVMzsxQ=; b=PnVcAm3AC5Mo3hwNXj6/APAvPb3Nu56RHA48iZY6gKcgMcQMTkCsY5di/NOOODrTb5 SEECYk820VYi9RaO7EIJKQo4jE5TkbSORox67eGOyDqgvqGKuGeb0L2bGfOOc0TxUZnY DCTBJEUfelDE0dSNbassF0Fff5r7gIW2Jmo0qmcvmQYSM1DQnBb8hck+6dilOFpWbMh2 n0zga+nuCWqcs3PzenosQDZQyA17SH9jzC0nRmxOItty77GSEhkijk39nnFBNP67F8lR p7t5G+7F183kWzbw0jIzFy0bqNPllGqQfiGYDIp8HQDPi/TIsQ/XWAy7qA3g6bn05icM gS1g==
X-Gm-Message-State: ALoCoQkOGRuHZNBTdccAYY9+d6KToWk68BR1CDNKzaA/l0Fsc7t0pWHhvh+KQtO9gX8+sqVlWImPOgb2VJVwb6KBYyKvsK5EjA==
MIME-Version: 1.0
X-Received: by 10.25.82.144 with SMTP id g138mr11594882lfb.8.1450887496579; Wed, 23 Dec 2015 08:18:16 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Wed, 23 Dec 2015 08:18:16 -0800 (PST)
In-Reply-To: 
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>  <56783B45.1020505@cisco.com> <20151221180231.GC43694@elstar.local> <147269F5-7B47-4614-9C08-948E8B5FC65C@nic.cz>  <6AFC7C6C-61B7-4310-A0CA-08A7CD76A899@nic.cz>   
Date: Wed, 23 Dec 2015 08:18:16 -0800
Message-ID: 
From: Andy Bierman 
To: "Acee Lindem (acee)" 
Content-Type: multipart/alternative; boundary=001a1141da8ed7dbf405279311b3
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2015 16:18:21 -0000

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

On Wed, Dec 23, 2015 at 8:11 AM, Acee Lindem (acee)  wrote:

>
>
> From: Andy Bierman 
> Date: Wednesday, December 23, 2015 at 10:46 AM
> To: Acee Lindem 
> Cc: Ladislav Lhotka , Kent Watsen , "
> netmod@ietf.org" 
> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>
>
>
> On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (acee) 
> wrote:
>
>>
>> On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
>>  wrote:
>>
>> >
>> >> On 23 Dec 2015, at 04:06, Kent Watsen  wrote:
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
>> >> wrote:
>> >>
>> >>>
>> >>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>> >>>> wrote:
>> >>>>
>> >>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>> >>>>
>> >>>>> I hope that nobody disagrees that the operational state design and
>> >>>>>how
>> >>>>> to structure the models are the two blocking factors to publish YA=
NG
>> >>>>> models. If you disagree or don't see this, let me know, I should
>> >>>>> communicate better.
>> >>>>
>> >>>> Even if it may spoil your day, I disagree that there is a blocking
>> >>>> factor that should stop us from publishing models. There seem to be
>> >>>> ways to address the requirements without having to block all work o=
r
>> >>>> to redo what that we have published. But sure, if you make it a
>> >>>> blocking factor, it will be one.
>> >>>
>> >>> I agree with Juergen. It is not clear to me how the proposed split
>> >>>between intended and applied configuration is supposed to affect the
>> >>>data models we are working on.
>> >>
>> >>
>> >> As I understand it, solution #1 affects the models themselves, wherea=
s
>> >>solutions #2 and #3 are transparent to the models.
>> >
>> >Then #1 looks like a non-starter to me.
>>
>> I=E2=80=99d like to point out that we also have the requirement to allow=
 retrieval
>> of derived-state along with intended-config and applied-config. This wil=
l
>> require modification to most of the existing YANG drafts as most now hav=
e
>> separate trees for config and operational state. Note that this is
>> discussed in sections 6, 7.3, and 7.4 of
>> https://www.ietf.org/id/draft-wilton-netmod-opstate-yang-02.txt.
>>
>>
> A NETCONF  with a subtree filter  can retrieveg both config and
> non-config subtrees
> at the same time.  A new RPC can be added (or existing  RPC extended=
)
> to
> filter various conditions.  I don't see how the YANG data layout affects
> the definition
> of "rpc" statements in another module.
>
>
> There is the requirement to be able to do the retrievals but there is als=
o
> this requirement:
>
>  C.  The mappings needs to be programmatically consumable
>
>
> Now, if the derived-state nodes are located with the config-nodes, then
> this is readily satisfied. Another way of satisfying the requirement may =
be
> structural and naming conventions but this is not as sure as co-location.
>
>
There can be meta-data returned (XML attributes) that identify the
additional properties.
This is better co-location since the pattern cannot be unintentional (as it
can with the
config-within-state containers).



> Thanks,
> Acee
>
>
Andy


>
>
> Thanks,
>> Acee
>>
>
>
> Andy
>
>
>>
>>
>> >
>> >Lada
>> >
>> >>
>> >> Kent
>> >>
>> >>
>> >>
>> >>> Lada
>> >>>
>> >>>>
>> >>>>> I hope that nobody really believes that because some people in IET=
F
>> >>>>>(or
>> >>>>> in any other SDOs) thinks that what those operators want is a bad
>> >>>>>idea,
>> >>>>> those operators will not get what they request/pay for from their
>> >>>>>suppliers.
>> >>>>
>> >>>> To be fair, those operators also tell us that they use protocols th=
at
>> >>>> are not IETF protocols and it remains somewhat unclear what those
>> >>>> protocols are we are expected to optimize data model solutions for.
>> >>>>
>> >>>> /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
>> >>>
>> >>> --
>> >>> Ladislav Lhotka, CZ.NIC Labs
>> >>> PGP Key ID: E74E8C0C
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> netmod mailing list
>> >>> netmod@ietf.org
>> >>> https://www.ietf.org/mailman/listinfo/netmod
>> >
>> >--
>> >Ladislav Lhotka, CZ.NIC Labs
>> >PGP Key ID: E74E8C0C
>> >
>> >
>> >
>> >
>> >_______________________________________________
>> >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
>>
>
>

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




On Wed, Dec 23, 2015 at 8:11 AM, Acee Lindem (acee) &=
lt;acee@cisco.com&g=
t; wrote:



















From: Andy Bierman <andy@yumaworks.com>

Date: Wednesday, December 23, 2015 =
at 10:46 AM

To: Acee Lindem <acee@cisco.com>

Cc: Ladislav Lhotka <lhotka@nic.cz>, Kent Watsen =
<kwatsen@junipe=
r.net>, "n=
etmod@ietf.org" <netmod@ietf.org>

Subject: Re: [netmod] NETMOD WG LC:=
 draft-ietf-netmod-opstate-reqs-01





















On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (ac=
ee) 
<acee@cisco.com&=
gt; wrote:





On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"

<netmod-bou=
nces@ietf.org on behalf of
lhotka@nic.cz> wr=
ote:



>

>> On 23 Dec 2015, at 04:06, Kent Watsen <kwatsen@juniper.net> wrote:

>>

>>

>>

>>

>>

>>

>> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka&qu=
ot;

>><ne=
tmod-bounces@ietf.org on behalf of
lhotka@nic.cz> wr=
ote:

>>

>>>

>>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder

>>>><j.schoenwaelder@jacobs-university.de> wrote:

>>>>

>>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wr=
ote:

>>>>

>>>>> I hope that nobody disagrees that the operational stat=
e design and

>>>>>how

>>>>> to structure the models are the two blocking factors t=
o publish YANG

>>>>> models. If you disagree or don't see this, let me =
know, I should

>>>>> communicate better.

>>>>

>>>> Even if it may spoil your day, I disagree that there is a =
blocking

>>>> factor that should stop us from publishing models. There s=
eem to be

>>>> ways to address the requirements without having to block a=
ll work or

>>>> to redo what that we have published. But sure, if you make=
 it a

>>>> blocking factor, it will be one.

>>>

>>> I agree with Juergen. It is not clear to me how the proposed s=
plit

>>>between intended and applied configuration is supposed to affec=
t the

>>>data models we are working on.

>>

>>

>> As I understand it, solution #1 affects the models themselves, whe=
reas

>>solutions #2 and #3 are transparent to the models.

>

>Then #1 looks like a non-starter to me.



I=E2=80=99d like to point out that we also have the requirement to allow re=
trieval

of derived-state along with intended-config and applied-config. This will
require modification to most of the existing YANG drafts as most now have
separate trees for config and operational state. Note that this is

discussed in sections 6, 7.3, and 7.4 of

https://www.ietf.org/id/draft-wilton-=
netmod-opstate-yang-02.txt.











A NETCONF <get> with a subtree filter =C2=A0can retrieveg both c=
onfig and non-config subtrees


at the same time.=C2=A0 A new RPC can be added (or existing <get>=
; RPC extended) to


filter various conditions.=C2=A0 I don't see how the YANG data lay=
out affects the definition


of "rpc" statements in another module.




















There is the requirement to be able to do the retrievals but there is =
also this requirement:









 C.  The mappings needs to be programmatically consumable









Now, if the derived-state nodes are located with the config-nodes, the=
n this is readily satisfied. Another way of satisfying the requirement may =
be structural and naming conventions but this is not as sure as co-location=
.=C2=A0




There can be meta-dat=
a returned (XML attributes) that identify the additional properties.
<=
div>This is better co-location since the pattern cannot be unintentional (a=
s it can with the
config-within-state containers).

=

=C2=A0




Thanks,


Acee=C2=A0




Andy
=C2=A0=





























Thanks,

Acee














Andy


=C2=A0







>

>Lada

>

>>

>> Kent

>>

>>

>>

>>> Lada

>>>

>>>>

>>>>> I hope that nobody really believes that because some p=
eople in IETF

>>>>>(or

>>>>> in any other SDOs) thinks that what those operators wa=
nt is a bad

>>>>>idea,

>>>>> those operators will not get what they request/pay for=
 from their

>>>>>suppliers.

>>>>

>>>> To be fair, those operators also tell us that they use pro=
tocols that

>>>> are not IETF protocols and it remains somewhat unclear wha=
t those

>>>> protocols are we are expected to optimize data model solut=
ions for.

>>>>

>>>> /js

>>>>

>>>> --

>>>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Jacobs University Bremen gGmbH

>>>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C=
ampus 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

>>>> netmo=
d@ietf.org

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

>>>

>>> --

>>> Ladislav Lhotka, CZ.NIC Labs

>>> PGP Key ID: E74E8C0C

>>>

>>>

>>>

>>>

>>> _______________________________________________

>>> netmod mailing list

>>> netmod@ie=
tf.org

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

>

>--

>Ladislav Lhotka, CZ.NIC Labs

>PGP Key ID: E74E8C0C

>

>

>

>

>_______________________________________________

>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

























--001a1141da8ed7dbf405279311b3--


From akash.jale@gmail.com  Fri Dec 18 04:32:48 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F4F1B2BC0 for ; Fri, 18 Dec 2015 04:32:48 -0800 (PST)
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, SPF_PASS=-0.001] autolearn=ham
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 1Z5V75MY6D-P for ; Fri, 18 Dec 2015 04:32:46 -0800 (PST)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::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 459991B2B8A for ; Fri, 18 Dec 2015 04:32:46 -0800 (PST)
Received: by mail-io0-x231.google.com with SMTP id q126so87767510iof.2 for ; Fri, 18 Dec 2015 04:32:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nVhggOqBO2e7GgsA7PbpaYVb3EtVRqPhXBkj9/9rV18=; b=pFp+b5XFeCg6tsQ/WZBkPaiqc+ujFXkYbWAkTXpunKwLa6qlDuuFNQEfI+G1+4jI5L 8WAHdko0xjGyaJeU5HS3pwgf4prmNo8NU66f+H7xNvueJDqzZ+tS4/tK2ZzJZq1lnyGB qKmqh9VmH+SKPkzr3eVGInsnQLFk7FH3b4yOBA9roCH1VrJglnDUCJZ8+COg55N2fZ/E 7htGaUPPzsnzkqJwFCUsHwDD7MMgZhz/uQqhAyvwZeRIjmYlsk/taR+JHSWxudOFJyEP ac7ll/Mn8ockquO6CDpTVynU6uPCDKUDQCAMxGRRuAs1Z+iNsJlddsNg3CwPdBLHSQh2 ebpg==
MIME-Version: 1.0
X-Received: by 10.107.166.82 with SMTP id p79mr4278419ioe.187.1450441965565; Fri, 18 Dec 2015 04:32:45 -0800 (PST)
Received: by 10.107.154.198 with HTTP; Fri, 18 Dec 2015 04:32:45 -0800 (PST)
In-Reply-To: 
References: 
Date: Fri, 18 Dec 2015 18:02:45 +0530
Message-ID: 
From: Akash Jale 
To: netmod@ietf.org
Content-Type: multipart/alternative; boundary=001a1141f2ac1ffce705272b566a
Archived-At: 
X-Mailman-Approved-At: Wed, 23 Dec 2015 09:20:34 -0800
Cc: Joey Boyd 
Subject: [netmod] Fwd: Feedback for Access-list YANG draft
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 21 Dec 2015 05:05:56 -0000

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

Hi Work Group,


   Based on the study of documentation of ACL feature usage with different
Vendors, it appears that the current draft doesn=E2=80=99t cover below
configuration options for matching:

=C2=B7  *Hostname in FQDN format*

=C2=B7  *Matching IPs based on wildcard masks*



We propose to add these elements into the draft to accommodate more usecase
scenarios/requirements and to be adaptable by different vendors.



*HOSTNAME Usecase:*

In deployments host generally have dynamic addresses within a Domain and
referred using the Hostnames (which is resolved into IP address using DNS).
So having Hostname/FQDN option should be present to handle scenarios for
creating hostname based ACLs.



*WILDCARD Usecase:*

Currently in the draft the Source and Destination node are IP-Prefix type.
Which is laying constraint in configuring traffic flow match criteria using
wildcards.



Using IP-Prefix, you can match packets of the subnet based on the CIDR
notation and it could support only limited wildcard mask cases.

*Examples of supported wildcard masks with CIDR notation : *

=C2=B7         Prefix:/24, Mask: 255.255.255.0,  Wildcard Mask: 0.0.0.255

=C2=B7         Prefix:/27 Mask:255.255.255.224, Wildcard Mask:0.0.0.31

=C2=B7         Prefix:/31 Mask:255.255.255.254, Wildcard Mask:0.0.0.1



There are few usecase scenarios of wildcard masks that we have come across
cannot be covered with / notation usage.

*Examples of Not-Supported wildcard cases:*

*      255.0.255.0 =E2=80=93 matching a particular network arrangement*

*      255.255.255.254 =E2=80=93 matching odd host addresses*






*Referred Link :
https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/?include_text=
=3D1
*



*Thank you.*



--=20
Best Regards,

Akash Jale.

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


Hi Work Group,
=C2=A0
=C2=A0=
=C2=A0 Based on
the study of documentation of ACL feature usage with different Vendors, it =
appears that the
current draft doesn=E2=80=99t cover below configuration options for matchin=
g:



=C2=B7=C2=A0 Hostname in FQDN format<=
/span>



=C2=B7=C2=A0 Matching IPs based on wildcard mask=
s



=C2=A0



We propose
to add these elements into the draft to accommodate more usecase
scenarios/requirements and to be adaptable by different vendors.



=C2=A0



HOSTNAME
Usecase:



In
deployments host generally have dynamic addresses within a Domain and refer=
red
using the Hostnames (which is resolved into IP address using DNS). So havin=
g
Hostname/FQDN option should be present to handle scenarios for creating
hostname based ACLs.



=C2=A0



WILDCARD
Usecase:



Currently
in the draft the Source and Destination node are IP-Prefix type. Which is
laying constraint in configuring traffic flow match criteria using wildcard=
s.



=C2=A0



Using
IP-Prefix, you can match packets of the subnet based on the CIDR notation a=
nd
it could support only limited wildcard mask cases.



Examples
of supported wildcard masks with CIDR notation : 



=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0
Prefix:/24, Mask: 255.255.255.0, =C2=A0Wildcard Mask: 0.0.0.255
<=
span class=3D"">


=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0
Prefix:/27 Mask:255.255.255.224, Wildcard Mask:0.0.0.31



=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0
Prefix:/31 Mask:255.255.255.254, Wildcard Mask:0.0.0.1



=C2=A0



There are
few usecase scenarios of wildcard masks that we have come across cannot be
covered with /<prefix> notation usage.



Examples
of Not-Supported wildcard cases:



=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0
255.0.255.0 =E2=80=93 matching a particular network arrangement<=
/p>


=C2=A0=C2=A0
=C2=A0=C2=A0=C2=A0255.255.255.254 =E2=80=93 matching odd host addresses



=C2=A0




=C2=A0
Referred Link : https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/?include_tex=
t=3D1

Thank you.
<=
/p>





--=C2=A0
Best R=
egards,

Akash Jale.




--001a1141f2ac1ffce705272b566a--


From nobody Wed Dec 23 10:22:18 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70B81A6F8B for ; Wed, 23 Dec 2015 10:22:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 Yya9jy6wmYuG for ; Wed, 23 Dec 2015 10:22:14 -0800 (PST)
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 CDF0A1A0061 for ; Wed, 23 Dec 2015 10:22:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26283; q=dns/txt; s=iport; t=1450894933; x=1452104533; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YZakg01BsTyi8a+xjl7fYkO6XLUR+Sj+vBnTfw23c8k=; b=WwPiZQts5uHsTdHLOeigPG/LnFKFBuyJSYmUxVmKbBDt6GS5yMh2SIMK wXlUQi3J1hTGN76EmByd8Xeejsp3obLIVEeD6tS4LmUDcyvvPKw1+bcHK dcAgYTKkvVf2QYMBCOPOJShogWl9Jy/9EfUvSKYQkkd5sOyNLIn/58Vkm g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BbAgDj5XpW/5xdJa1UBwOCbkxSbQaMS?= =?us-ascii?q?7B2AQ2BYxgBCYUjSgIcgQ04FAEBAQEBAQGBCoQ0AQEBAwEBAQEgSwQHDgICAQg?= =?us-ascii?q?QAQMBAgEnAwICAhkMCxQJCAIEDgUbiAwIDq4+kgUBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEYBItRhCxBCgEMEQmCVYFKBZcDAY1LgVyNHYpHg3MBIAEBQoQLcgGEH4E?= =?us-ascii?q?IAQEB?=
X-IronPort-AV: E=Sophos;i="5.20,470,1444694400";  d="scan'208,217";a="220882956"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Dec 2015 18:22:12 +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 tBNIMCnY025898 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 23 Dec 2015 18:22:12 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.1104.5; Wed, 23 Dec 2015 13:22:11 -0500
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.1104.009; Wed, 23 Dec 2015 13:22:11 -0500
From: "Acee Lindem (acee)" 
To: Andy Bierman 
Thread-Topic: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
Thread-Index: AQHROST+Qi5eUPyFCUOmbJF1PR1M/Z7Q8W4AgACOLQCAAASngIAEjK+AgAAEHICAABYDAIACFGgAgABYGQCAABvKAIAAYGWA//+zBYCAAFXRAP//zsaA
Date: Wed, 23 Dec 2015 18:22:11 +0000
Message-ID: 
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>  <56783B45.1020505@cisco.com> <20151221180231.GC43694@elstar.local> <147269F5-7B47-4614-9C08-948E8B5FC65C@nic.cz>  <6AFC7C6C-61B7-4310-A0CA-08A7CD76A899@nic.cz>    
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.199]
Content-Type: multipart/alternative; boundary="_000_D2A0500845CA0aceeciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2015 18:22:17 -0000

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

DQoNCkZyb206IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1
bWF3b3Jrcy5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBEZWNlbWJlciAyMywgMjAxNSBhdCAxMTox
OCBBTQ0KVG86IEFjZWUgTGluZGVtIDxhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNlZUBjaXNjby5j
b20+Pg0KQ2M6IExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jejxtYWlsdG86bGhvdGthQG5p
Yy5jej4+LCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldDxtYWlsdG86a3dhdHNlbkBq
dW5pcGVyLm5ldD4+LCAibmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+IiA8
bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtu
ZXRtb2RdIE5FVE1PRCBXRyBMQzogZHJhZnQtaWV0Zi1uZXRtb2Qtb3BzdGF0ZS1yZXFzLTAxDQoN
Cg0KDQpPbiBXZWQsIERlYyAyMywgMjAxNSBhdCA4OjExIEFNLCBBY2VlIExpbmRlbSAoYWNlZSkg
PGFjZWVAY2lzY28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQoNCkZyb206
IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1bWF3b3Jrcy5j
b20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBEZWNlbWJlciAyMywgMjAxNSBhdCAxMDo0NiBBTQ0KVG86
IEFjZWUgTGluZGVtIDxhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNlZUBjaXNjby5jb20+Pg0KQ2M6
IExhZGlzbGF2IExob3RrYSA8bGhvdGthQG5pYy5jejxtYWlsdG86bGhvdGthQG5pYy5jej4+LCBL
ZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldDxtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5l
dD4+LCAibmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+IiA8bmV0bW9kQGll
dGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtuZXRtb2RdIE5F
VE1PRCBXRyBMQzogZHJhZnQtaWV0Zi1uZXRtb2Qtb3BzdGF0ZS1yZXFzLTAxDQoNCg0KDQpPbiBX
ZWQsIERlYyAyMywgMjAxNSBhdCA3OjAxIEFNLCBBY2VlIExpbmRlbSAoYWNlZSkgPGFjZWVAY2lz
Y28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpPbiAxMi8yMy8xNSwgMzoy
MiBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgTGFkaXNsYXYgTGhvdGthIg0KPG5ldG1vZC1ib3Vu
Y2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9m
IGxob3RrYUBuaWMuY3o8bWFpbHRvOmxob3RrYUBuaWMuY3o+PiB3cm90ZToNCg0KPg0KPj4gT24g
MjMgRGVjIDIwMTUsIGF0IDA0OjA2LCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldDxt
YWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldD4+IHdyb3RlOg0KPj4NCj4+DQo+Pg0KPj4NCj4+DQo+
Pg0KPj4gT24gMTIvMjEvMTUsIDI6MjEgUE0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIExhZGlzbGF2
IExob3RrYSINCj4+PG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNl
c0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIGxob3RrYUBuaWMuY3o8bWFpbHRvOmxob3RrYUBuaWMu
Y3o+PiB3cm90ZToNCj4+DQo+Pj4NCj4+Pj4gT24gMjEgRGVjIDIwMTUsIGF0IDE5OjAyLCBKdWVy
Z2VuIFNjaG9lbndhZWxkZXINCj4+Pj48ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5
LmRlPG1haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+PiB3cm90ZToN
Cj4+Pj4NCj4+Pj4gT24gTW9uLCBEZWMgMjEsIDIwMTUgYXQgMDY6NDc6NDlQTSArMDEwMCwgQmVu
b2l0IENsYWlzZSB3cm90ZToNCj4+Pj4NCj4+Pj4+IEkgaG9wZSB0aGF0IG5vYm9keSBkaXNhZ3Jl
ZXMgdGhhdCB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgZGVzaWduIGFuZA0KPj4+Pj5ob3cNCj4+Pj4+
IHRvIHN0cnVjdHVyZSB0aGUgbW9kZWxzIGFyZSB0aGUgdHdvIGJsb2NraW5nIGZhY3RvcnMgdG8g
cHVibGlzaCBZQU5HDQo+Pj4+PiBtb2RlbHMuIElmIHlvdSBkaXNhZ3JlZSBvciBkb24ndCBzZWUg
dGhpcywgbGV0IG1lIGtub3csIEkgc2hvdWxkDQo+Pj4+PiBjb21tdW5pY2F0ZSBiZXR0ZXIuDQo+
Pj4+DQo+Pj4+IEV2ZW4gaWYgaXQgbWF5IHNwb2lsIHlvdXIgZGF5LCBJIGRpc2FncmVlIHRoYXQg
dGhlcmUgaXMgYSBibG9ja2luZw0KPj4+PiBmYWN0b3IgdGhhdCBzaG91bGQgc3RvcCB1cyBmcm9t
IHB1Ymxpc2hpbmcgbW9kZWxzLiBUaGVyZSBzZWVtIHRvIGJlDQo+Pj4+IHdheXMgdG8gYWRkcmVz
cyB0aGUgcmVxdWlyZW1lbnRzIHdpdGhvdXQgaGF2aW5nIHRvIGJsb2NrIGFsbCB3b3JrIG9yDQo+
Pj4+IHRvIHJlZG8gd2hhdCB0aGF0IHdlIGhhdmUgcHVibGlzaGVkLiBCdXQgc3VyZSwgaWYgeW91
IG1ha2UgaXQgYQ0KPj4+PiBibG9ja2luZyBmYWN0b3IsIGl0IHdpbGwgYmUgb25lLg0KPj4+DQo+
Pj4gSSBhZ3JlZSB3aXRoIEp1ZXJnZW4uIEl0IGlzIG5vdCBjbGVhciB0byBtZSBob3cgdGhlIHBy
b3Bvc2VkIHNwbGl0DQo+Pj5iZXR3ZWVuIGludGVuZGVkIGFuZCBhcHBsaWVkIGNvbmZpZ3VyYXRp
b24gaXMgc3VwcG9zZWQgdG8gYWZmZWN0IHRoZQ0KPj4+ZGF0YSBtb2RlbHMgd2UgYXJlIHdvcmtp
bmcgb24uDQo+Pg0KPj4NCj4+IEFzIEkgdW5kZXJzdGFuZCBpdCwgc29sdXRpb24gIzEgYWZmZWN0
cyB0aGUgbW9kZWxzIHRoZW1zZWx2ZXMsIHdoZXJlYXMNCj4+c29sdXRpb25zICMyIGFuZCAjMyBh
cmUgdHJhbnNwYXJlbnQgdG8gdGhlIG1vZGVscy4NCj4NCj5UaGVuICMxIGxvb2tzIGxpa2UgYSBu
b24tc3RhcnRlciB0byBtZS4NCg0KSeKAmWQgbGlrZSB0byBwb2ludCBvdXQgdGhhdCB3ZSBhbHNv
IGhhdmUgdGhlIHJlcXVpcmVtZW50IHRvIGFsbG93IHJldHJpZXZhbA0Kb2YgZGVyaXZlZC1zdGF0
ZSBhbG9uZyB3aXRoIGludGVuZGVkLWNvbmZpZyBhbmQgYXBwbGllZC1jb25maWcuIFRoaXMgd2ls
bA0KcmVxdWlyZSBtb2RpZmljYXRpb24gdG8gbW9zdCBvZiB0aGUgZXhpc3RpbmcgWUFORyBkcmFm
dHMgYXMgbW9zdCBub3cgaGF2ZQ0Kc2VwYXJhdGUgdHJlZXMgZm9yIGNvbmZpZyBhbmQgb3BlcmF0
aW9uYWwgc3RhdGUuIE5vdGUgdGhhdCB0aGlzIGlzDQpkaXNjdXNzZWQgaW4gc2VjdGlvbnMgNiwg
Ny4zLCBhbmQgNy40IG9mDQpodHRwczovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC13aWx0b24tbmV0
bW9kLW9wc3RhdGUteWFuZy0wMi50eHQuDQoNCg0KQSBORVRDT05GIDxnZXQ+IHdpdGggYSBzdWJ0
cmVlIGZpbHRlciAgY2FuIHJldHJpZXZlZyBib3RoIGNvbmZpZyBhbmQgbm9uLWNvbmZpZyBzdWJ0
cmVlcw0KYXQgdGhlIHNhbWUgdGltZS4gIEEgbmV3IFJQQyBjYW4gYmUgYWRkZWQgKG9yIGV4aXN0
aW5nIDxnZXQ+IFJQQyBleHRlbmRlZCkgdG8NCmZpbHRlciB2YXJpb3VzIGNvbmRpdGlvbnMuICBJ
IGRvbid0IHNlZSBob3cgdGhlIFlBTkcgZGF0YSBsYXlvdXQgYWZmZWN0cyB0aGUgZGVmaW5pdGlv
bg0Kb2YgInJwYyIgc3RhdGVtZW50cyBpbiBhbm90aGVyIG1vZHVsZS4NCg0KVGhlcmUgaXMgdGhl
IHJlcXVpcmVtZW50IHRvIGJlIGFibGUgdG8gZG8gdGhlIHJldHJpZXZhbHMgYnV0IHRoZXJlIGlz
IGFsc28gdGhpcyByZXF1aXJlbWVudDoNCg0KDQogQy4gIFRoZSBtYXBwaW5ncyBuZWVkcyB0byBi
ZSBwcm9ncmFtbWF0aWNhbGx5IGNvbnN1bWFibGUNCg0KTm93LCBpZiB0aGUgZGVyaXZlZC1zdGF0
ZSBub2RlcyBhcmUgbG9jYXRlZCB3aXRoIHRoZSBjb25maWctbm9kZXMsIHRoZW4gdGhpcyBpcyBy
ZWFkaWx5IHNhdGlzZmllZC4gQW5vdGhlciB3YXkgb2Ygc2F0aXNmeWluZyB0aGUgcmVxdWlyZW1l
bnQgbWF5IGJlIHN0cnVjdHVyYWwgYW5kIG5hbWluZyBjb252ZW50aW9ucyBidXQgdGhpcyBpcyBu
b3QgYXMgc3VyZSBhcyBjby1sb2NhdGlvbi4NCg0KDQpUaGVyZSBjYW4gYmUgbWV0YS1kYXRhIHJl
dHVybmVkIChYTUwgYXR0cmlidXRlcykgdGhhdCBpZGVudGlmeSB0aGUgYWRkaXRpb25hbCBwcm9w
ZXJ0aWVzLg0KVGhpcyBpcyBiZXR0ZXIgY28tbG9jYXRpb24gc2luY2UgdGhlIHBhdHRlcm4gY2Fu
bm90IGJlIHVuaW50ZW50aW9uYWwgKGFzIGl0IGNhbiB3aXRoIHRoZQ0KY29uZmlnLXdpdGhpbi1z
dGF0ZSBjb250YWluZXJzKS4NCg0KVGhpcyBtYXkgYmUgYW4gb3B0aW9uIGZvciBwdWJsaXNoZWQg
bW9kZWxzLiBIb3dldmVyLCBmb3IgbW9kZWxzIGluIGRldmVsb3BtZW50LCB3b3VsZG7igJl0IGl0
IGJlIGVhc2llciB0byBqdXN0IG1vdmUgdGhlIG5vZGVzIHJhdGhlciB0aGFuIGRlZmluaW5nIHRo
ZSByZWxhdGlvbnNoaXBzIGluIG1ldGEtZGF0YT8NCg0KVGhhbmtzLA0KQWNlZQ0KDQoNCg0KDQpU
aGFua3MsDQpBY2VlDQoNCg0KQW5keQ0KDQoNCg0KVGhhbmtzLA0KQWNlZQ0KDQoNCkFuZHkNCg0K
DQoNCj4NCj5MYWRhDQo+DQo+Pg0KPj4gS2VudA0KPj4NCj4+DQo+Pg0KPj4+IExhZGENCj4+Pg0K
Pj4+Pg0KPj4+Pj4gSSBob3BlIHRoYXQgbm9ib2R5IHJlYWxseSBiZWxpZXZlcyB0aGF0IGJlY2F1
c2Ugc29tZSBwZW9wbGUgaW4gSUVURg0KPj4+Pj4ob3INCj4+Pj4+IGluIGFueSBvdGhlciBTRE9z
KSB0aGlua3MgdGhhdCB3aGF0IHRob3NlIG9wZXJhdG9ycyB3YW50IGlzIGEgYmFkDQo+Pj4+Pmlk
ZWEsDQo+Pj4+PiB0aG9zZSBvcGVyYXRvcnMgd2lsbCBub3QgZ2V0IHdoYXQgdGhleSByZXF1ZXN0
L3BheSBmb3IgZnJvbSB0aGVpcg0KPj4+Pj5zdXBwbGllcnMuDQo+Pj4+DQo+Pj4+IFRvIGJlIGZh
aXIsIHRob3NlIG9wZXJhdG9ycyBhbHNvIHRlbGwgdXMgdGhhdCB0aGV5IHVzZSBwcm90b2NvbHMg
dGhhdA0KPj4+PiBhcmUgbm90IElFVEYgcHJvdG9jb2xzIGFuZCBpdCByZW1haW5zIHNvbWV3aGF0
IHVuY2xlYXIgd2hhdCB0aG9zZQ0KPj4+PiBwcm90b2NvbHMgYXJlIHdlIGFyZSBleHBlY3RlZCB0
byBvcHRpbWl6ZSBkYXRhIG1vZGVsIHNvbHV0aW9ucyBmb3IuDQo+Pj4+DQo+Pj4+IC9qcw0KPj4+
Pg0KPj4+PiAtLQ0KPj4+PiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBV
bml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KPj4+PiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAg
ICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQo+Pj4+IEZheDogICAr
NDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUv
Pg0KPj4+Pg0KPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+Pj4+IG5ldG1vZEBpZXRmLm9yZzxtYWls
dG86bmV0bW9kQGlldGYub3JnPg0KPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL25ldG1vZA0KPj4+DQo+Pj4gLS0NCj4+PiBMYWRpc2xhdiBMaG90a2EsIENaLk5JQyBM
YWJzDQo+Pj4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4+Pg0KPj4+DQo+Pj4NCj4+Pg0KPj4+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gbmV0bW9k
IG1haWxpbmcgbGlzdA0KPj4+IG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3Jn
Pg0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+DQo+
LS0NCj5MYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQo+UEdQIEtleSBJRDogRTc0RThDMEMN
Cj4NCj4NCj4NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0KPm5ldG1vZCBtYWlsaW5nIGxpc3QNCj5uZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1v
ZEBpZXRmLm9yZz4NCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v
ZA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0
bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+
DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQoNCg==

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj48YnI+DQo8L2Rp
dj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K
PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxp
Z246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVIt
TEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGlu
OyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JE
RVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJm
b250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+QW5keSBCaWVybWFuICZsdDs8YSBocmVmPSJt
YWlsdG86YW5keUB5dW1hd29ya3MuY29tIj5hbmR5QHl1bWF3b3Jrcy5jb208L2E+Jmd0Ozxicj4N
CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+V2VkbmVzZGF5LCBE
ZWNlbWJlciAyMywgMjAxNSBhdCAxMToxOCBBTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdo
dDpib2xkIj5UbzogPC9zcGFuPkFjZWUgTGluZGVtICZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBj
aXNjby5jb20iPmFjZWVAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13
ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5MYWRpc2xhdiBMaG90a2EgJmx0OzxhIGhyZWY9Im1haWx0
bzpsaG90a2FAbmljLmN6Ij5saG90a2FAbmljLmN6PC9hPiZndDssIEtlbnQgV2F0c2VuICZsdDs8
YSBocmVmPSJtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldCI+a3dhdHNlbkBqdW5pcGVyLm5ldDwv
YT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0
Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRt
b2RAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5T
dWJqZWN0OiA8L3NwYW4+UmU6IFtuZXRtb2RdIE5FVE1PRCBXRyBMQzogZHJhZnQtaWV0Zi1uZXRt
b2Qtb3BzdGF0ZS1yZXFzLTAxPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2Nr
cXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JE
RVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1
OyI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWls
X2V4dHJhIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gV2VkLCBEZWMgMjMsIDIw
MTUgYXQgODoxMSBBTSwgQWNlZSBMaW5kZW0gKGFjZWUpIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8
YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5hY2VlQGNpc2Nv
LmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf
cXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xp
ZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO2Nv
bG9yOnJnYigwLDAsMCk7Zm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNl
cmlmIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4+DQo8ZGl2
IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2ZvbnQtc2l6ZToxMXB0O3RleHQtYWxpZ246bGVm
dDtjb2xvcjpibGFjaztCT1JERVItQk9UVE9NOm1lZGl1bSBub25lO0JPUkRFUi1MRUZUOm1lZGl1
bSBub25lO1BBRERJTkctQk9UVE9NOjBpbjtQQURESU5HLUxFRlQ6MGluO1BBRERJTkctUklHSFQ6
MGluO0JPUkRFUi1UT1A6I2I1YzRkZiAxcHQgc29saWQ7Qk9SREVSLVJJR0hUOm1lZGl1bSBub25l
O1BBRERJTkctVE9QOjNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTog
PC9zcGFuPkFuZHkgQmllcm1hbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFuZHlAeXVtYXdvcmtzLmNv
bSIgdGFyZ2V0PSJfYmxhbmsiPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4g
c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5XZWRuZXNkYXksIERlY2VtYmVy
IDIzLCAyMDE1IGF0IDEwOjQ2IEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQi
PlRvOiA8L3NwYW4+QWNlZSBMaW5kZW0gJmx0OzxhIGhyZWY9Im1haWx0bzphY2VlQGNpc2NvLmNv
bSIgdGFyZ2V0PSJfYmxhbmsiPmFjZWVAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHls
ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj5MYWRpc2xhdiBMaG90a2EgJmx0OzxhIGhy
ZWY9Im1haWx0bzpsaG90a2FAbmljLmN6IiB0YXJnZXQ9Il9ibGFuayI+bGhvdGthQG5pYy5jejwv
YT4mZ3Q7LCBLZW50IFdhdHNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmt3YXRzZW5AanVuaXBlci5u
ZXQiIHRhcmdldD0iX2JsYW5rIj5rd2F0c2VuQGp1bmlwZXIubmV0PC9hPiZndDssICZxdW90Ozxh
IGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2RAaWV0
Zi5vcmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRh
cmdldD0iX2JsYW5rIj5uZXRtb2RAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJm
b250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtuZXRtb2RdIE5FVE1PRCBXRyBM
QzogZHJhZnQtaWV0Zi1uZXRtb2Qtb3BzdGF0ZS1yZXFzLTAxPGJyPg0KPC9kaXY+DQo8ZGl2Pjxi
cj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9IkJPUkRFUi1MRUZUOiNiNWM0ZGYgNSBzb2xp
ZDtQQURESU5HOjAgMCAwIDU7TUFSR0lOOjAgMCAwIDUiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2IGRp
cj0ibHRyIj48YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0i
Z21haWxfcXVvdGUiPk9uIFdlZCwgRGVjIDIzLCAyMDE1IGF0IDc6MDEgQU0sIEFjZWUgTGluZGVt
IChhY2VlKSA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOmFjZWVAY2lzY28u
Y29tIiB0YXJnZXQ9Il9ibGFuayI+YWNlZUBjaXNjby5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6
PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAw
IC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8YnI+
DQpPbiAxMi8yMy8xNSwgMzoyMiBBTSwgJnF1b3Q7bmV0bW9kIG9uIGJlaGFsZiBvZiBMYWRpc2xh
diBMaG90a2EmcXVvdDs8YnI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1ib3VuY2VzQGll
dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJl
aGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOmxob3RrYUBuaWMuY3oiIHRhcmdldD0iX2JsYW5rIj5s
aG90a2FAbmljLmN6PC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7
IE9uIDIzIERlYyAyMDE1LCBhdCAwNDowNiwgS2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0
bzprd2F0c2VuQGp1bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+a3dhdHNlbkBqdW5pcGVyLm5l
dDwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0
Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7
IE9uIDEyLzIxLzE1LCAyOjIxIFBNLCAmcXVvdDtuZXRtb2Qgb24gYmVoYWxmIG9mIExhZGlzbGF2
IExob3RrYSZxdW90Ozxicj4NCiZndDsmZ3Q7Jmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2QtYm91
bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPC9h
PiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzpsaG90a2FAbmljLmN6IiB0YXJnZXQ9Il9i
bGFuayI+bGhvdGthQG5pYy5jejwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0
OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBPbiAyMSBEZWMgMjAxNSwgYXQgMTk6MDIs
IEp1ZXJnZW4gU2Nob2Vud2FlbGRlcjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmbHQ7PGEgaHJlZj0i
bWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSIgdGFyZ2V0PSJfYmxh
bmsiPmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTwvYT4mZ3Q7IHdyb3RlOjxi
cj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IE9uIE1vbiwgRGVjIDIx
LCAyMDE1IGF0IDA2OjQ3OjQ5UE0gJiM0MzswMTAwLCBCZW5vaXQgQ2xhaXNlIHdyb3RlOjxicj4N
CiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGhvcGUgdGhhdCBu
b2JvZHkgZGlzYWdyZWVzIHRoYXQgdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGRlc2lnbiBhbmQ8YnI+
DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O2hvdzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRvIHN0
cnVjdHVyZSB0aGUgbW9kZWxzIGFyZSB0aGUgdHdvIGJsb2NraW5nIGZhY3RvcnMgdG8gcHVibGlz
aCBZQU5HPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgbW9kZWxzLiBJZiB5b3UgZGlzYWdyZWUg
b3IgZG9uJ3Qgc2VlIHRoaXMsIGxldCBtZSBrbm93LCBJIHNob3VsZDxicj4NCiZndDsmZ3Q7Jmd0
OyZndDsmZ3Q7IGNvbW11bmljYXRlIGJldHRlci48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0OyBFdmVuIGlmIGl0IG1heSBzcG9pbCB5b3VyIGRheSwgSSBkaXNhZ3Jl
ZSB0aGF0IHRoZXJlIGlzIGEgYmxvY2tpbmc8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGZhY3RvciB0
aGF0IHNob3VsZCBzdG9wIHVzIGZyb20gcHVibGlzaGluZyBtb2RlbHMuIFRoZXJlIHNlZW0gdG8g
YmU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHdheXMgdG8gYWRkcmVzcyB0aGUgcmVxdWlyZW1lbnRz
IHdpdGhvdXQgaGF2aW5nIHRvIGJsb2NrIGFsbCB3b3JrIG9yPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0
OyB0byByZWRvIHdoYXQgdGhhdCB3ZSBoYXZlIHB1Ymxpc2hlZC4gQnV0IHN1cmUsIGlmIHlvdSBt
YWtlIGl0IGE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGJsb2NraW5nIGZhY3RvciwgaXQgd2lsbCBi
ZSBvbmUuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEkgYWdyZWUgd2l0aCBK
dWVyZ2VuLiBJdCBpcyBub3QgY2xlYXIgdG8gbWUgaG93IHRoZSBwcm9wb3NlZCBzcGxpdDxicj4N
CiZndDsmZ3Q7Jmd0O2JldHdlZW4gaW50ZW5kZWQgYW5kIGFwcGxpZWQgY29uZmlndXJhdGlvbiBp
cyBzdXBwb3NlZCB0byBhZmZlY3QgdGhlPGJyPg0KJmd0OyZndDsmZ3Q7ZGF0YSBtb2RlbHMgd2Ug
YXJlIHdvcmtpbmcgb24uPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7
IEFzIEkgdW5kZXJzdGFuZCBpdCwgc29sdXRpb24gIzEgYWZmZWN0cyB0aGUgbW9kZWxzIHRoZW1z
ZWx2ZXMsIHdoZXJlYXM8YnI+DQomZ3Q7Jmd0O3NvbHV0aW9ucyAjMiBhbmQgIzMgYXJlIHRyYW5z
cGFyZW50IHRvIHRoZSBtb2RlbHMuPGJyPg0KJmd0Ozxicj4NCiZndDtUaGVuICMxIGxvb2tzIGxp
a2UgYSBub24tc3RhcnRlciB0byBtZS48YnI+DQo8YnI+DQpJ4oCZZCBsaWtlIHRvIHBvaW50IG91
dCB0aGF0IHdlIGFsc28gaGF2ZSB0aGUgcmVxdWlyZW1lbnQgdG8gYWxsb3cgcmV0cmlldmFsPGJy
Pg0Kb2YgZGVyaXZlZC1zdGF0ZSBhbG9uZyB3aXRoIGludGVuZGVkLWNvbmZpZyBhbmQgYXBwbGll
ZC1jb25maWcuIFRoaXMgd2lsbDxicj4NCnJlcXVpcmUgbW9kaWZpY2F0aW9uIHRvIG1vc3Qgb2Yg
dGhlIGV4aXN0aW5nIFlBTkcgZHJhZnRzIGFzIG1vc3Qgbm93IGhhdmU8YnI+DQpzZXBhcmF0ZSB0
cmVlcyBmb3IgY29uZmlnIGFuZCBvcGVyYXRpb25hbCBzdGF0ZS4gTm90ZSB0aGF0IHRoaXMgaXM8
YnI+DQpkaXNjdXNzZWQgaW4gc2VjdGlvbnMgNiwgNy4zLCBhbmQgNy40IG9mPGJyPg0KPGEgaHJl
Zj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtd2lsdG9uLW5ldG1vZC1vcHN0YXRlLXlh
bmctMDIudHh0IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5p
ZXRmLm9yZy9pZC9kcmFmdC13aWx0b24tbmV0bW9kLW9wc3RhdGUteWFuZy0wMi50eHQ8L2E+Ljxi
cj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkEgTkVUQ09O
RiAmbHQ7Z2V0Jmd0OyB3aXRoIGEgc3VidHJlZSBmaWx0ZXIgJm5ic3A7Y2FuIHJldHJpZXZlZyBi
b3RoIGNvbmZpZyBhbmQgbm9uLWNvbmZpZyBzdWJ0cmVlczwvZGl2Pg0KPGRpdj5hdCB0aGUgc2Ft
ZSB0aW1lLiZuYnNwOyBBIG5ldyBSUEMgY2FuIGJlIGFkZGVkIChvciBleGlzdGluZyAmbHQ7Z2V0
Jmd0OyBSUEMgZXh0ZW5kZWQpIHRvPC9kaXY+DQo8ZGl2PmZpbHRlciB2YXJpb3VzIGNvbmRpdGlv
bnMuJm5ic3A7IEkgZG9uJ3Qgc2VlIGhvdyB0aGUgWUFORyBkYXRhIGxheW91dCBhZmZlY3RzIHRo
ZSBkZWZpbml0aW9uPC9kaXY+DQo8ZGl2Pm9mICZxdW90O3JwYyZxdW90OyBzdGF0ZW1lbnRzIGlu
IGFub3RoZXIgbW9kdWxlLjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRo
ZXJlIGlzIHRoZSByZXF1aXJlbWVudCB0byBiZSBhYmxlIHRvIGRvIHRoZSByZXRyaWV2YWxzIGJ1
dCB0aGVyZSBpcyBhbHNvIHRoaXMgcmVxdWlyZW1lbnQ6PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2
Pg0KPGRpdj4NCjxwcmU+IEMuICBUaGUgbWFwcGluZ3MgbmVlZHMgdG8gYmUgcHJvZ3JhbW1hdGlj
YWxseSBjb25zdW1hYmxlPC9wcmU+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk5v
dywgaWYgdGhlIGRlcml2ZWQtc3RhdGUgbm9kZXMgYXJlIGxvY2F0ZWQgd2l0aCB0aGUgY29uZmln
LW5vZGVzLCB0aGVuIHRoaXMgaXMgcmVhZGlseSBzYXRpc2ZpZWQuIEFub3RoZXIgd2F5IG9mIHNh
dGlzZnlpbmcgdGhlIHJlcXVpcmVtZW50IG1heSBiZSBzdHJ1Y3R1cmFsIGFuZCBuYW1pbmcgY29u
dmVudGlvbnMgYnV0IHRoaXMgaXMgbm90IGFzIHN1cmUgYXMgY28tbG9jYXRpb24uJm5ic3A7PC9k
aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxicj4N
CjwvZGl2Pg0KPGRpdj5UaGVyZSBjYW4gYmUgbWV0YS1kYXRhIHJldHVybmVkIChYTUwgYXR0cmli
dXRlcykgdGhhdCBpZGVudGlmeSB0aGUgYWRkaXRpb25hbCBwcm9wZXJ0aWVzLjwvZGl2Pg0KPGRp
dj5UaGlzIGlzIGJldHRlciBjby1sb2NhdGlvbiBzaW5jZSB0aGUgcGF0dGVybiBjYW5ub3QgYmUg
dW5pbnRlbnRpb25hbCAoYXMgaXQgY2FuIHdpdGggdGhlPC9kaXY+DQo8ZGl2PmNvbmZpZy13aXRo
aW4tc3RhdGUgY29udGFpbmVycykuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp
dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk
aXY+VGhpcyBtYXkgYmUgYW4gb3B0aW9uIGZvciBwdWJsaXNoZWQgbW9kZWxzLiBIb3dldmVyLCBm
b3IgbW9kZWxzIGluIGRldmVsb3BtZW50LCB3b3VsZG7igJl0IGl0IGJlIGVhc2llciB0byBqdXN0
IG1vdmUgdGhlIG5vZGVzIHJhdGhlciB0aGFuIGRlZmluaW5nIHRoZSByZWxhdGlvbnNoaXBzIGlu
IG1ldGEtZGF0YT8mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcyw8
L2Rpdj4NCjxkaXY+QWNlZSZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJy
Pg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGJsb2NrcXVvdGUg
aWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVG
VDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8
ZGl2Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPg0K
PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7
PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAw
IDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxk
aXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO2NvbG9yOnJnYigwLDAsMCk7Zm9udC1zaXpl
OjE0cHg7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmIj4NCjxkaXY+PC9kaXY+DQo8ZGl2
PlRoYW5rcyw8L2Rpdj4NCjxkaXY+QWNlZSZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QW5keTwvZGl2
Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5
bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmct
bGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7Y29sb3I6cmdiKDAs
MCwwKTtmb250LXNpemU6MTRweDtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPg0KPGRp
dj48L2Rpdj4NCjxzcGFuPg0KPGJsb2NrcXVvdGUgc3R5bGU9IkJPUkRFUi1MRUZUOiNiNWM0ZGYg
NSBzb2xpZDtQQURESU5HOjAgMCAwIDU7TUFSR0lOOjAgMCAwIDUiPg0KPGRpdj4NCjxkaXY+DQo8
ZGl2IGRpcj0ibHRyIj4NCjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj4NCjxkaXYgY2xhc3M9Imdt
YWlsX3F1b3RlIj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2Nr
cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVy
LWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQpUaGFua3MsPGJyPg0KQWNl
ZTxicj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2
Pg0KPGRpdj5BbmR5PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9
ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNj
Y2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+DQo8YnI+DQo8YnI+DQomZ3Q7PGJyPg0KJmd0O0xh
ZGE8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBLZW50PGJyPg0KJmd0OyZn
dDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IExhZGE8YnI+
DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0
OyZndDsgSSBob3BlIHRoYXQgbm9ib2R5IHJlYWxseSBiZWxpZXZlcyB0aGF0IGJlY2F1c2Ugc29t
ZSBwZW9wbGUgaW4gSUVURjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7KG9yPGJyPg0KJmd0OyZn
dDsmZ3Q7Jmd0OyZndDsgaW4gYW55IG90aGVyIFNET3MpIHRoaW5rcyB0aGF0IHdoYXQgdGhvc2Ug
b3BlcmF0b3JzIHdhbnQgaXMgYSBiYWQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0O2lkZWEsPGJy
Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhvc2Ugb3BlcmF0b3JzIHdpbGwgbm90IGdldCB3aGF0
IHRoZXkgcmVxdWVzdC9wYXkgZm9yIGZyb20gdGhlaXI8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0
O3N1cHBsaWVycy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBU
byBiZSBmYWlyLCB0aG9zZSBvcGVyYXRvcnMgYWxzbyB0ZWxsIHVzIHRoYXQgdGhleSB1c2UgcHJv
dG9jb2xzIHRoYXQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGFyZSBub3QgSUVURiBwcm90b2NvbHMg
YW5kIGl0IHJlbWFpbnMgc29tZXdoYXQgdW5jbGVhciB3aGF0IHRob3NlPGJyPg0KJmd0OyZndDsm
Z3Q7Jmd0OyBwcm90b2NvbHMgYXJlIHdlIGFyZSBleHBlY3RlZCB0byBvcHRpbWl6ZSBkYXRhIG1v
ZGVsIHNvbHV0aW9ucyBmb3IuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0
OyZndDsgL2pzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgLS08
YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJI
PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBQaG9uZTogJiM0Mzs0OSA0MjEgMjAwIDM1ODcmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8
IEdlcm1hbnk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEZheDombmJzcDsgJm5ic3A7JiM0Mzs0OSA0
MjEgMjAwIDMxMDMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jmx0OzxhIGhyZWY9
Imh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdl
dD0iX2JsYW5rIj5odHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLzwvYT4mZ3Q7PGJyPg0K
Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IG5ldG1v
ZCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpuZXRt
b2RAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0
OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL25ldG1vZCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvYT48YnI+DQomZ3Q7Jmd0OyZndDs8
YnI+DQomZ3Q7Jmd0OyZndDsgLS08YnI+DQomZ3Q7Jmd0OyZndDsgTGFkaXNsYXYgTGhvdGthLCBD
Wi5OSUMgTGFiczxicj4NCiZndDsmZ3Q7Jmd0OyBQR1AgS2V5IElEOiBFNzRFOEMwQzxicj4NCiZn
dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm
Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzxicj4NCiZndDsmZ3Q7Jmd0OyBuZXRtb2QgbWFpbGluZyBsaXN0PGJy
Pg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpuZXRtb2RAaWV0Zi5vcmciIHRhcmdldD0i
X2JsYW5rIj5uZXRtb2RAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiByZWw9Im5vcmVmZXJy
ZXIiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vbmV0bW9kPC9hPjxicj4NCiZndDs8YnI+DQomZ3Q7LS08YnI+DQomZ3Q7TGFkaXNsYXYgTGhv
dGthLCBDWi5OSUMgTGFiczxicj4NCiZndDtQR1AgS2V5IElEOiBFNzRFOEMwQzxicj4NCiZndDs8
YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7X19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7bmV0bW9kIG1haWxpbmcgbGlz
dDxicj4NCiZndDs8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu
ayI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCiZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9i
bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8L2E+PGJy
Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRm
Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5ldG1vZEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCIgcmVsPSJub3JlZmVy
cmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m
by9uZXRtb2Q8L2E+PGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj48L2Rpdj4NCjwvYmxv
Y2txdW90ZT4NCjwvZGl2Pg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_D2A0500845CA0aceeciscocom_--


From nobody Wed Dec 23 10:34:30 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D5BF1A6FD6 for ; Wed, 23 Dec 2015 10:34:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 CPALQ3llE6qi for ; Wed, 23 Dec 2015 10:34:26 -0800 (PST)
Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 D27741A6FD2 for ; Wed, 23 Dec 2015 10:34:25 -0800 (PST)
Received: by mail-lf0-x22b.google.com with SMTP id p203so153399268lfa.0 for ; Wed, 23 Dec 2015 10:34:25 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=wCcnOM8+1dHk6MsiRSNNbErR0N4OlnyxClw24N9pob0=; b=YzELdGNKyoQfUuEIbYTNhQmG7JqlMgJ0p4ogEXIDazjtPImL8bF0xd2AE0KNZrMF9l FdlyV9KrkYrZugoSbsyrAWkCWJKn1/cbTMBMa/UtS/GCL5aLt4cI1aqW9ddsdGn4qdAO ZMC4Y+CrpgJINlMhvNpJ/Th0qgjkLeFlnuX/pL7M75nnsa3ZyqWBALBlu+1MVtUwJGij mIrlN5dLVBAVC+1eax3j3ssAYN8bHHHuiI2qCz7ELNvivH/3wAw+6MBXOd71RlwFVxAB dINXNp6QZTCw+IC/7eDx74kKbh3Y3lJj04miVKbffEzeweg+s6K2Ln1FnvSAOGig/4OU JBiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wCcnOM8+1dHk6MsiRSNNbErR0N4OlnyxClw24N9pob0=; b=gLXNvdiIhpURJksHetGtm6uE4rvxsj5mWHIHhHW+PZ/SBa4UOktaje0cDra+itrUUL 0aWHJYM8OWNM8CUHja/DtWzLMfReR5SGjhVanOTtdE2yEsRV/QYmyGG2LmNqtuFDQTXH zwHfRqENEe2ZjcuBVbDI4zUBNeaCekCS0kbW00Sr4ONc4RdbOPrnVwWfgkSs8yWQH6gB nqu+fUB5Yb0juYhNFbVqQO5ggIFIfy6r8CWL9AJXjvCkiSmINJLqhxP2891DUhfwL15M Hwe5pMR1p3IT8CWgZ6iV3B41p+/1MPlubTwYWH0RFc2n8fFdayx3POmd/Zzsvpt2Rqgm nWyw==
X-Gm-Message-State: ALoCoQl1ofNQW1EiXivxn/aDivY3gNrZskaEJeSDgLGWEOprDsQxNcNdU3xzymysOMTVtaO0zEvC6hbKiCRqXN3vXBYfXeUeEw==
MIME-Version: 1.0
X-Received: by 10.25.85.20 with SMTP id j20mr2789087lfb.131.1450895663964; Wed, 23 Dec 2015 10:34:23 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Wed, 23 Dec 2015 10:34:23 -0800 (PST)
In-Reply-To: 
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>  <56783B45.1020505@cisco.com> <20151221180231.GC43694@elstar.local> <147269F5-7B47-4614-9C08-948E8B5FC65C@nic.cz>  <6AFC7C6C-61B7-4310-A0CA-08A7CD76A899@nic.cz>     
Date: Wed, 23 Dec 2015 10:34:23 -0800
Message-ID: 
From: Andy Bierman 
To: "Acee Lindem (acee)" 
Content-Type: multipart/alternative; boundary=001a1141c532a83e25052794f846
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2015 18:34:29 -0000

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

On Wed, Dec 23, 2015 at 10:22 AM, Acee Lindem (acee)  wrote=
:

>
>
> From: Andy Bierman 
> Date: Wednesday, December 23, 2015 at 11:18 AM
> To: Acee Lindem 
> Cc: Ladislav Lhotka , Kent Watsen , "
> netmod@ietf.org" 
> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>
>
>
> On Wed, Dec 23, 2015 at 8:11 AM, Acee Lindem (acee) 
> wrote:
>
>>
>>
>> From: Andy Bierman 
>> Date: Wednesday, December 23, 2015 at 10:46 AM
>> To: Acee Lindem 
>> Cc: Ladislav Lhotka , Kent Watsen , =
"
>> netmod@ietf.org" 
>> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>>
>>
>>
>> On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (acee) 
>> wrote:
>>
>>>
>>> On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
>>>  wrote:
>>>
>>> >
>>> >> On 23 Dec 2015, at 04:06, Kent Watsen  wrote:
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
>>> >> wrote:
>>> >>
>>> >>>
>>> >>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>>> >>>> wrote:
>>> >>>>
>>> >>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>>> >>>>
>>> >>>>> I hope that nobody disagrees that the operational state design an=
d
>>> >>>>>how
>>> >>>>> to structure the models are the two blocking factors to publish
>>> YANG
>>> >>>>> models. If you disagree or don't see this, let me know, I should
>>> >>>>> communicate better.
>>> >>>>
>>> >>>> Even if it may spoil your day, I disagree that there is a blocking
>>> >>>> factor that should stop us from publishing models. There seem to b=
e
>>> >>>> ways to address the requirements without having to block all work =
or
>>> >>>> to redo what that we have published. But sure, if you make it a
>>> >>>> blocking factor, it will be one.
>>> >>>
>>> >>> I agree with Juergen. It is not clear to me how the proposed split
>>> >>>between intended and applied configuration is supposed to affect the
>>> >>>data models we are working on.
>>> >>
>>> >>
>>> >> As I understand it, solution #1 affects the models themselves, where=
as
>>> >>solutions #2 and #3 are transparent to the models.
>>> >
>>> >Then #1 looks like a non-starter to me.
>>>
>>> I=E2=80=99d like to point out that we also have the requirement to allo=
w
>>> retrieval
>>> of derived-state along with intended-config and applied-config. This wi=
ll
>>> require modification to most of the existing YANG drafts as most now ha=
ve
>>> separate trees for config and operational state. Note that this is
>>> discussed in sections 6, 7.3, and 7.4 of
>>> https://www.ietf.org/id/draft-wilton-netmod-opstate-yang-02.txt.
>>>
>>>
>> A NETCONF  with a subtree filter  can retrieveg both config and
>> non-config subtrees
>> at the same time.  A new RPC can be added (or existing  RPC
>> extended) to
>> filter various conditions.  I don't see how the YANG data layout affects
>> the definition
>> of "rpc" statements in another module.
>>
>>
>> There is the requirement to be able to do the retrievals but there is
>> also this requirement:
>>
>>  C.  The mappings needs to be programmatically consumable
>>
>>
>> Now, if the derived-state nodes are located with the config-nodes, then
>> this is readily satisfied. Another way of satisfying the requirement may=
 be
>> structural and naming conventions but this is not as sure as co-location=
.
>>
>>
> There can be meta-data returned (XML attributes) that identify the
> additional properties.
> This is better co-location since the pattern cannot be unintentional (as
> it can with the
> config-within-state containers).
>
>
> This may be an option for published models. However, for models in
> development, wouldn=E2=80=99t it be easier to just move the nodes rather =
than
> defining the relationships in meta-data?
>
>

I prefer an RPC-based solution using a similar approach to the
 parameter
already defined in NETCONF and RESTCONF.  Not only does it work for all
models
without changing the data model, it only requires 1 subtree to be retrieved
instead of 2.

However, any solution that requires lots of data to be retrieved seems
counter-productive
to the most obvious use-case.  It has been stated many times "what if the
server is busy adding
100,000 routes, so that is why applied !=3D intended".  Well, if the server
is busy applying config edits,
then burdening the server with lots of retrieval requests can only slow it
down.


Thanks,
> Acee
>


Andy


>
>
>
>
>
>> Thanks,
>> Acee
>>
>>
> Andy
>
>
>>
>>
>> Thanks,
>>> Acee
>>>
>>
>>
>> Andy
>>
>>
>>>
>>>
>>> >
>>> >Lada
>>> >
>>> >>
>>> >> Kent
>>> >>
>>> >>
>>> >>
>>> >>> Lada
>>> >>>
>>> >>>>
>>> >>>>> I hope that nobody really believes that because some people in IE=
TF
>>> >>>>>(or
>>> >>>>> in any other SDOs) thinks that what those operators want is a bad
>>> >>>>>idea,
>>> >>>>> those operators will not get what they request/pay for from their
>>> >>>>>suppliers.
>>> >>>>
>>> >>>> To be fair, those operators also tell us that they use protocols
>>> that
>>> >>>> are not IETF protocols and it remains somewhat unclear what those
>>> >>>> protocols are we are expected to optimize data model solutions for=
.
>>> >>>>
>>> >>>> /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
>>> >>>
>>> >>> --
>>> >>> Ladislav Lhotka, CZ.NIC Labs
>>> >>> PGP Key ID: E74E8C0C
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> netmod mailing list
>>> >>> netmod@ietf.org
>>> >>> https://www.ietf.org/mailman/listinfo/netmod
>>> >
>>> >--
>>> >Ladislav Lhotka, CZ.NIC Labs
>>> >PGP Key ID: E74E8C0C
>>> >
>>> >
>>> >
>>> >
>>> >_______________________________________________
>>> >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
>>>
>>
>>
>

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




On Wed, Dec 23, 2015 at 10:22 AM, Acee Lindem (acee) =
<acee@cisco.com&=
gt; wrote:



















From: Andy Bierman <andy@yumaworks.com>

Date: Wednesday, December 23, 2015 =
at 11:18 AM

To: Acee Lindem <acee@cisco.com>

Cc: Ladislav Lhotka <lhotka@nic.cz>, Kent Watsen =
<kwatsen@junipe=
r.net>, "n=
etmod@ietf.org" <netmod@ietf.org>

Subject: Re: [netmod] NETMOD WG LC:=
 draft-ietf-netmod-opstate-reqs-01





















On Wed, Dec 23, 2015 at 8:11 AM, Acee Lindem (ac=
ee) 
<acee@cisco.com&=
gt; wrote:


















From: Andy Bierman <andy@yumaworks.com>

Date: Wednesday, December 23, 2015 =
at 10:46 AM

To: Acee Lindem <acee@cisco.com>

Cc: Ladislav Lhotka <lhotka@nic.cz>, Kent Watsen =
<kwatsen@junipe=
r.net>, "n=
etmod@ietf.org"
 <netmod@ietf.org>

Subject: Re: [netmod] NETMOD WG LC:=
 draft-ietf-netmod-opstate-reqs-01





















On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (ac=
ee) 
<acee@cisco.com&=
gt; wrote:





On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"

<netmod-bou=
nces@ietf.org on behalf of
lhotka@nic.cz> wr=
ote:



>

>> On 23 Dec 2015, at 04:06, Kent Watsen <kwatsen@juniper.net> wrote:

>>

>>

>>

>>

>>

>>

>> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka&qu=
ot;

>><ne=
tmod-bounces@ietf.org on behalf of
lhotka@nic.cz> wr=
ote:

>>

>>>

>>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder

>>>><j.schoenwaelder@jacobs-university.de> wrote:

>>>>

>>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wr=
ote:

>>>>

>>>>> I hope that nobody disagrees that the operational stat=
e design and

>>>>>how

>>>>> to structure the models are the two blocking factors t=
o publish YANG

>>>>> models. If you disagree or don't see this, let me =
know, I should

>>>>> communicate better.

>>>>

>>>> Even if it may spoil your day, I disagree that there is a =
blocking

>>>> factor that should stop us from publishing models. There s=
eem to be

>>>> ways to address the requirements without having to block a=
ll work or

>>>> to redo what that we have published. But sure, if you make=
 it a

>>>> blocking factor, it will be one.

>>>

>>> I agree with Juergen. It is not clear to me how the proposed s=
plit

>>>between intended and applied configuration is supposed to affec=
t the

>>>data models we are working on.

>>

>>

>> As I understand it, solution #1 affects the models themselves, whe=
reas

>>solutions #2 and #3 are transparent to the models.

>

>Then #1 looks like a non-starter to me.



I=E2=80=99d like to point out that we also have the requirement to allow re=
trieval

of derived-state along with intended-config and applied-config. This will
require modification to most of the existing YANG drafts as most now have
separate trees for config and operational state. Note that this is

discussed in sections 6, 7.3, and 7.4 of

https://www.ietf.org/id/draft-wilton-=
netmod-opstate-yang-02.txt.











A NETCONF <get> with a subtree filter =C2=A0can retrieveg both c=
onfig and non-config subtrees


at the same time.=C2=A0 A new RPC can be added (or existing <get>=
; RPC extended) to


filter various conditions.=C2=A0 I don't see how the YANG data lay=
out affects the definition


of "rpc" statements in another module.




















There is the requirement to be able to do the retrievals but there is =
also this requirement:









 C.  The mappings needs to be programmatically consumable









Now, if the derived-state nodes are located with the config-nodes, the=
n this is readily satisfied. Another way of satisfying the requirement may =
be structural and naming conventions but this is not as sure as co-location=
.=C2=A0
















There can be meta-data returned (XML attributes) that identify the add=
itional properties.


This is better co-location since the pattern cannot be unintentional (=
as it can with the


config-within-state containers).




















This may be an option for published models. However, for models in dev=
elopment, wouldn=E2=80=99t it be easier to just move the nodes rather than =
defining the relationships in meta-data?=C2=A0





I pref=
er an RPC-based solution using a similar approach to the <with-defaults&=
gt; parameter
already defined in NETCONF and RESTCONF.=C2=A0 Not =
only does it work for all models
without changing the data model,=
 it only requires 1 subtree to be retrieved instead of 2.

However, any solution that requires lots of data to be retrieved se=
ems counter-productive
to the most obvious use-case.=C2=A0 It has=
 been stated many times "what if the server is busy adding
1=
00,000 routes, so that is why applied !=3D intended".=C2=A0 Well, if t=
he server is busy applying config edits,
then burdening the serve=
r with lots of retrieval requests can only slow it down.






Thanks,


Acee=C2=A0


=
Andy
=C2=A0






























=C2=A0








Thanks,


Acee=C2=A0
















Andy


=C2=A0
































Thanks,

Acee














Andy


=C2=A0







>

>Lada

>

>>

>> Kent

>>

>>

>>

>>> Lada

>>>

>>>>

>>>>> I hope that nobody really believes that because some p=
eople in IETF

>>>>>(or

>>>>> in any other SDOs) thinks that what those operators wa=
nt is a bad

>>>>>idea,

>>>>> those operators will not get what they request/pay for=
 from their

>>>>>suppliers.

>>>>

>>>> To be fair, those operators also tell us that they use pro=
tocols that

>>>> are not IETF protocols and it remains somewhat unclear wha=
t those

>>>> protocols are we are expected to optimize data model solut=
ions for.

>>>>

>>>> /js

>>>>

>>>> --

>>>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0Jacobs University Bremen gGmbH

>>>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C=
ampus 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

>>>> netmo=
d@ietf.org

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

>>>

>>> --

>>> Ladislav Lhotka, CZ.NIC Labs

>>> PGP Key ID: E74E8C0C

>>>

>>>

>>>

>>>

>>> _______________________________________________

>>> netmod mailing list

>>> netmod@ie=
tf.org

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

>

>--

>Ladislav Lhotka, CZ.NIC Labs

>PGP Key ID: E74E8C0C

>

>

>

>

>_______________________________________________

>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











































--001a1141c532a83e25052794f846--


From nobody Wed Dec 23 12:52:55 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5BF41A6FC8 for ; Wed, 23 Dec 2015 12:52:53 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 WnE3CJ5iEN5b for ; Wed, 23 Dec 2015 12:52:50 -0800 (PST)
Received: from auth-4.ukservers.net (auth-4.ukservers.net [217.10.138.158]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9476A1A1A62 for ; Wed, 23 Dec 2015 12:52:49 -0800 (PST)
Received: from [192.168.1.66] (host86-166-225-11.range86-166.btcentralplus.com [86.166.225.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by auth-4.ukservers.net (Postfix smtp) with ESMTPSA id F3732376293C; Wed, 23 Dec 2015 20:52:46 +0000 (GMT)
To: "Acee Lindem (acee)" , Andy Bierman 
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>  <56783B45.1020505@cisco.com> <20151221180231.GC43694@elstar.local> <147269F5-7B47-4614-9C08-948E8B5FC65C@nic.cz>  <6AFC7C6C-61B7-4310-A0CA-08A7CD76A899@nic.cz>     
From: Robert Wilton 
Message-ID: <567B09A0.1080203@wilton.org.uk>
Date: Wed, 23 Dec 2015 20:52:48 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------020205060106060001060204"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2015 20:52:53 -0000

This is a multi-part message in MIME format.
--------------020205060106060001060204
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

On 23/12/2015 18:22, Acee Lindem (acee) wrote:
>
>
> From: Andy Bierman >
> Date: Wednesday, December 23, 2015 at 11:18 AM
> To: Acee Lindem >
> Cc: Ladislav Lhotka >, Kent 
> Watsen >, 
> "netmod@ietf.org "  >
> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>
>
>
>     On Wed, Dec 23, 2015 at 8:11 AM, Acee Lindem (acee)
>     > wrote:
>
>
>
>         From: Andy Bierman          >
>         Date: Wednesday, December 23, 2015 at 10:46 AM
>         To: Acee Lindem >
>         Cc: Ladislav Lhotka >,
>         Kent Watsen          >, "netmod@ietf.org
>         "          >
>         Subject: Re: [netmod] NETMOD WG LC:
>         draft-ietf-netmod-opstate-reqs-01
>
>
>
>             On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (acee)
>             > wrote:
>
>
>                 On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav
>                 Lhotka"
>                                   on behalf of
>                 lhotka@nic.cz > wrote:
>
>                 >
>                 >> On 23 Dec 2015, at 04:06, Kent Watsen
>                 > wrote:
>                 >>
>                 >>
>                 >>
>                 >>
>                 >>
>                 >>
>                 >> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav
>                 Lhotka"
>                 >>                  on behalf of
>                 lhotka@nic.cz > wrote:
>                 >>
>                 >>>
>                 >>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>                 >>>>                 > wrote:
>                 >>>>
>                 >>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit
>                 Claise wrote:
>                 >>>>
>                 >>>>> I hope that nobody disagrees that the
>                 operational state design and
>                 >>>>>how
>                 >>>>> to structure the models are the two blocking
>                 factors to publish YANG
>                 >>>>> models. If you disagree or don't see this, let
>                 me know, I should
>                 >>>>> communicate better.
>                 >>>>
>                 >>>> Even if it may spoil your day, I disagree that
>                 there is a blocking
>                 >>>> factor that should stop us from publishing
>                 models. There seem to be
>                 >>>> ways to address the requirements without having
>                 to block all work or
>                 >>>> to redo what that we have published. But sure, if
>                 you make it a
>                 >>>> blocking factor, it will be one.
>                 >>>
>                 >>> I agree with Juergen. It is not clear to me how
>                 the proposed split
>                 >>>between intended and applied configuration is
>                 supposed to affect the
>                 >>>data models we are working on.
>                 >>
>                 >>
>                 >> As I understand it, solution #1 affects the models
>                 themselves, whereas
>                 >>solutions #2 and #3 are transparent to the models.
>                 >
>                 >Then #1 looks like a non-starter to me.
>
>                 I’d like to point out that we also have the
>                 requirement to allow retrieval
>                 of derived-state along with intended-config and
>                 applied-config. This will
>                 require modification to most of the existing YANG
>                 drafts as most now have
>                 separate trees for config and operational state. Note
>                 that this is
>                 discussed in sections 6, 7.3, and 7.4 of
>                 https://www.ietf.org/id/draft-wilton-netmod-opstate-yang-02.txt.
>
>
>             A NETCONF  with a subtree filter  can retrieveg both
>             config and non-config subtrees
>             at the same time.  A new RPC can be added (or existing
>              RPC extended) to
>             filter various conditions.  I don't see how the YANG data
>             layout affects the definition
>             of "rpc" statements in another module.
>
>
>         There is the requirement to be able to do the retrievals but
>         there is also this requirement:
>
>           C.  The mappings needs to be programmatically consumable
>
>
>         Now, if the derived-state nodes are located with the
>         config-nodes, then this is readily satisfied. Another way of
>         satisfying the requirement may be structural and naming
>         conventions but this is not as sure as co-location.
>
>
>     There can be meta-data returned (XML attributes) that identify the
>     additional properties.
>     This is better co-location since the pattern cannot be
>     unintentional (as it can with the
>     config-within-state containers).
>
>
> This may be an option for published models. However, for models in 
> development, wouldn’t it be easier to just move the nodes rather than 
> defining the relationships in meta-data?

Just relying on meta-data to relate config and state would probably add 
a lot of relations noise to the models.  I would imagine that this would 
make the models source YANG files harder to read, and potentially have a 
slight negative performance impact in the clients - which may be 
important if they have to relate many nodes.

Hence why I think that it is best to use co-location where possible, and 
just use explicit meta-data where the nodes are further apart in the 
data tree.

This still leaves the question as to what to do with the interfaces vs 
interfaces-state.  There would seem to be two possible solutions to me: 
(1) merge the trees together as per OpenConfig, or (2) add a special 
case rule for interfaces.  I think that this is an issue that neither 
Kent's nor my draft fully addresses.

Thanks,
Rob


>
> Thanks,
> Acee
>
>
>
>         Thanks,
>         Acee
>
>
>     Andy
>
>
>
>                 Thanks,
>                 Acee
>
>
>
>             Andy
>
>
>
>                 >
>                 >Lada
>                 >
>                 >>
>                 >> Kent
>                 >>
>                 >>
>                 >>
>                 >>> Lada
>                 >>>
>                 >>>>
>                 >>>>> I hope that nobody really believes that because
>                 some people in IETF
>                 >>>>>(or
>                 >>>>> in any other SDOs) thinks that what those
>                 operators want is a bad
>                 >>>>>idea,
>                 >>>>> those operators will not get what they
>                 request/pay for from their
>                 >>>>>suppliers.
>                 >>>>
>                 >>>> To be fair, those operators also tell us that
>                 they use protocols that
>                 >>>> are not IETF protocols and it remains somewhat
>                 unclear what those
>                 >>>> protocols are we are expected to optimize data
>                 model solutions for.
>                 >>>>
>                 >>>> /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
>                 >>>
>                 >>> --
>                 >>> Ladislav Lhotka, CZ.NIC Labs
>                 >>> PGP Key ID: E74E8C0C
>                 >>>
>                 >>>
>                 >>>
>                 >>>
>                 >>> _______________________________________________
>                 >>> netmod mailing list
>                 >>> netmod@ietf.org 
>                 >>> https://www.ietf.org/mailman/listinfo/netmod
>                 >
>                 >--
>                 >Ladislav Lhotka, CZ.NIC Labs
>                 >PGP Key ID: E74E8C0C
>                 >
>                 >
>                 >
>                 >
>                 >_______________________________________________
>                 >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


--------------020205060106060001060204
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi,

      

      On 23/12/2015 18:22, Acee Lindem (acee) wrote:

    

    

      
      


      

      


      

      
        

          From: Andy Bierman <andy@yumaworks.com>

          Date: Wednesday,
          December 23, 2015 at 11:18 AM

          To: Acee Lindem <acee@cisco.com>

          Cc: Ladislav Lhotka
          <lhotka@nic.cz>,
          Kent Watsen <kwatsen@juniper.net>,
          "netmod@ietf.org"
          <netmod@ietf.org>

          Subject: Re: [netmod]
          NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

        

        


        

        

          

            

              


                


                  
On Wed, Dec 23, 2015 at 8:11
                    AM, Acee Lindem (acee) 
                      <acee@cisco.com>
                    wrote:

                    

                      

                        


                        

                        


                        

                        
                          

                            From: Andy
                            Bierman <andy@yumaworks.com>

                            Date: Wednesday,
                            December 23, 2015 at 10:46 AM

                            To: Acee
                            Lindem <acee@cisco.com>

                            Cc: Ladislav
                            Lhotka <lhotka@nic.cz>,
                            Kent Watsen <kwatsen@juniper.net>,
                            "netmod@ietf.org" <netmod@ietf.org>

                            Subject: Re:
                            [netmod] NETMOD WG LC:
                            draft-ietf-netmod-opstate-reqs-01

                          

                          


                          

                          

                            

                              

                                


                                  


                                    
On Wed, Dec
                                      23, 2015 at 7:01 AM, Acee Lindem
                                      (acee) 
                                        <acee@cisco.com>
                                      wrote:

                                      

                                        

                                        On 12/23/15, 3:22 AM, "netmod on
                                        behalf of Ladislav Lhotka"

                                        <netmod-bounces@ietf.org
                                        on behalf of
                                        lhotka@nic.cz>
                                        wrote:

                                        

                                        >

                                        >> On 23 Dec 2015, at
                                        04:06, Kent Watsen <kwatsen@juniper.net>
                                        wrote:

                                        >>

                                        >>

                                        >>

                                        >>

                                        >>

                                        >>

                                        >> On 12/21/15, 2:21 PM,
                                        "netmod on behalf of Ladislav
                                        Lhotka"

                                        >><netmod-bounces@ietf.org
                                        on behalf of
                                        lhotka@nic.cz>
                                        wrote:

                                        >>

                                        >>>

                                        >>>> On 21 Dec 2015,
                                        at 19:02, Juergen Schoenwaelder

                                        >>>><j.schoenwaelder@jacobs-university.de>
                                        wrote:

                                        >>>>

                                        >>>> On Mon, Dec 21,
                                        2015 at 06:47:49PM +0100, Benoit
                                        Claise wrote:

                                        >>>>

                                        >>>>> I hope that
                                        nobody disagrees that the
                                        operational state design and

                                        >>>>>how

                                        >>>>> to
                                        structure the models are the two
                                        blocking factors to publish YANG

                                        >>>>> models. If
                                        you disagree or don't see this,
                                        let me know, I should

                                        >>>>> communicate
                                        better.

                                        >>>>

                                        >>>> Even if it may
                                        spoil your day, I disagree that
                                        there is a blocking

                                        >>>> factor that
                                        should stop us from publishing
                                        models. There seem to be

                                        >>>> ways to address
                                        the requirements without having
                                        to block all work or

                                        >>>> to redo what
                                        that we have published. But
                                        sure, if you make it a

                                        >>>> blocking
                                        factor, it will be one.

                                        >>>

                                        >>> I agree with
                                        Juergen. It is not clear to me
                                        how the proposed split

                                        >>>between intended and
                                        applied configuration is
                                        supposed to affect the

                                        >>>data models we are
                                        working on.

                                        >>

                                        >>

                                        >> As I understand it,
                                        solution #1 affects the models
                                        themselves, whereas

                                        >>solutions #2 and #3 are
                                        transparent to the models.

                                        >

                                        >Then #1 looks like a
                                        non-starter to me.

                                        

                                        I’d like to point out that we
                                        also have the requirement to
                                        allow retrieval

                                        of derived-state along with
                                        intended-config and
                                        applied-config. This will

                                        require modification to most of
                                        the existing YANG drafts as most
                                        now have

                                        separate trees for config and
                                        operational state. Note that
                                        this is

                                        discussed in sections 6, 7.3,
                                        and 7.4 of

                                        https://www.ietf.org/id/draft-wilton-netmod-opstate-yang-02.txt.

                                        

                                      

                                      


                                      

                                      
A NETCONF <get> with a
                                        subtree filter  can retrieveg
                                        both config and non-config
                                        subtrees

                                      
at the same time.  A new RPC
                                        can be added (or existing
                                        <get> RPC extended) to

                                      
filter various conditions.  I
                                        don't see how the YANG data
                                        layout affects the definition

                                      
of "rpc" statements in
                                        another module.

                                    

                                  

                                

                              

                            

                          

                        
                        


                        

                        
There is the requirement to be able to do
                          the retrievals but there is also this
                          requirement:

                        


                        

                        

                          
 C.  The mappings needs to be programmatically consumable

                        

                        


                        

                        
Now, if the derived-state nodes are located
                          with the config-nodes, then this is readily
                          satisfied. Another way of satisfying the
                          requirement may be structural and naming
                          conventions but this is not as sure as
                          co-location. 

                        


                        

                      

                    

                    


                    

                    
There can be meta-data returned (XML
                      attributes) that identify the additional
                      properties.

                    
This is better co-location since the pattern
                      cannot be unintentional (as it can with the

                    
config-within-state containers).

                  

                

              

            

          

        

      
      


      

      
This may be an option for published models. However, for
        models in development, wouldn’t it be easier to just move the
        nodes rather than defining the relationships in meta-data?

    

    

    Just relying on meta-data to relate config and state would probably
    add a lot of relations noise to the models.  I would imagine that
    this would make the models source YANG files harder to read, and
    potentially have a slight negative performance impact in the clients
    - which may be important if they have to relate many nodes.

    

    Hence why I think that it is best to use co-location where possible,
    and just use explicit meta-data where the nodes are further apart in
    the data tree.

    

    This still leaves the question as to what to do with the interfaces
    vs interfaces-state.  There would seem to be two possible solutions
    to me: (1) merge the trees together as per OpenConfig, or (2) add a
    special case rule for interfaces.  I think that this is an issue
    that neither Kent's nor my draft fully addresses.

    

    Thanks,

    Rob

    

    

    

      
 

      


      

      
Thanks,

      
Acee 

      


      

      


      

      
        

          

            

              

                

                  

                    


                    

                    
 

                    

                      

                        
Thanks,

                        
Acee 

                        


                        

                      

                    

                    


                    

                    
Andy

                    
 

                    

                      

                        
                          

                            

                              

                                

                                  

                                    

                                      


                                      

                                      


                                      

                                      

                                        Thanks,

                                        Acee

                                      

                                      


                                      

                                      


                                      

                                      
Andy

                                      
 

                                      

                                        

                                        

                                        >

                                        >Lada

                                        >

                                        >>

                                        >> Kent

                                        >>

                                        >>

                                        >>

                                        >>> Lada

                                        >>>

                                        >>>>

                                        >>>>> I hope that
                                        nobody really believes that
                                        because some people in IETF

                                        >>>>>(or

                                        >>>>> in any
                                        other SDOs) thinks that what
                                        those operators want is a bad

                                        >>>>>idea,

                                        >>>>> those
                                        operators will not get what they
                                        request/pay for from their

                                        >>>>>suppliers.

                                        >>>>

                                        >>>> To be fair,
                                        those operators also tell us
                                        that they use protocols that

                                        >>>> are not IETF
                                        protocols and it remains
                                        somewhat unclear what those

                                        >>>> protocols are
                                        we are expected to optimize data
                                        model solutions for.

                                        >>>>

                                        >>>> /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

                                        >>>

                                        >>> --

                                        >>> Ladislav Lhotka,
                                        CZ.NIC Labs

                                        >>> PGP Key ID:
                                        E74E8C0C

                                        >>>

                                        >>>

                                        >>>

                                        >>>

                                        >>>
                                        _______________________________________________

                                        >>> netmod mailing list

                                        >>> netmod@ietf.org

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

                                        >

                                        >--

                                        >Ladislav Lhotka, CZ.NIC Labs

                                        >PGP Key ID: E74E8C0C

                                        >

                                        >

                                        >

                                        >

>_______________________________________________

                                        >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


    

    

  


--------------020205060106060001060204--


From nobody Wed Dec 23 13:25:03 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03C31A8775 for ; Wed, 23 Dec 2015 13:25:02 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 8EVgJ4Ka2XbS for ; Wed, 23 Dec 2015 13:25:00 -0800 (PST)
Received: from auth-3.ukservers.net (auth-3.ukservers.net [217.10.138.152]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752BB1A8773 for ; Wed, 23 Dec 2015 13:25:00 -0800 (PST)
Received: from [192.168.1.66] (host86-166-225-11.range86-166.btcentralplus.com [86.166.225.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by auth-3.ukservers.net (Postfix smtp) with ESMTPSA id ED77A1723767; Wed, 23 Dec 2015 21:24:55 +0000 (GMT)
To: Gert Grammel , Kent Watsen , "netmod@ietf.org" 
References:  <56784B9B.5020408@cisco.com> <327E370C-4D5F-4F9A-B982-B71108CEBC08@juniper.net> <567A5B39.3010909@wilton.org.uk> 
From: Robert Wilton 
Message-ID: <567B1129.9090104@wilton.org.uk>
Date: Wed, 23 Dec 2015 21:24:57 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------000502000404090501030906"
Archived-At: 
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2015 21:25:02 -0000

This is a multi-part message in MIME format.
--------------000502000404090501030906
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Hi Gert,

Please see one comment inline ...

On 23/12/2015 10:24, Gert Grammel wrote:
> Rob, Kent,
>
> Adding to Rob’s comments:
>
>
>
> From: netmod  > on behalf of Robert Wilton 
> >
> Date: Wednesday 23 December 2015 09:28
> To: Kent Watsen >, 
> "netmod@ietf.org "  >
> Subject: Re: [netmod] netmod-opstate-reqs and error option terms 
> (rollback on error)
>
> Hi Kent,
>
> Yes, I think that we are in agreement.
>
> I've one further comment inline below ...
>
> On 23/12/2015 02:41, Kent Watsen wrote:
>
>     [As a contributor]
>
>     Hi Robert, I want to go back to Jason’s original questions.  I
>     think we’re aligned on this, but please check my answers below.
>
>     Quoting Jason’s original text now:
>
>
>         Is there some intention in the opstate requirements to add
>         some sort
>         of all-or-nothing behavior to transition (C)?
>
>     Yes
>
> +1 (if rollback-on-error has been requested)
>
>
>
>         i.e. if some part of
>         an edit fails during the transition from intended->applied we
>         should
>         "rollback" the other parts that may have already been applied ?
>
>     Yes
>
> +1 (if rollback-on-error has been requested)
>
>
>
>         Would we then remove it all from intended as well ?
>
>     IMO, yes.  This is more easily understood when thinking about
>     Synchronous Configuration Operations (defined in opstate-reqs),
>     but I believe that it equally applies to Asynchronous
>     Configuration Operations, so long as the client explicitly ops-in
>     for the behavior.
>
> IMO no. The intended config is imposed by the client to the server and 
> other than performing some syntax check, the server has no choice to 
> accept it as-is. If the server can’t apply the intended config, 
> obviously the mismatch between intended and applied config needs to be 
> notified. As a result, it is up to the client to decide what to do. 
> Actions can vary according to the situation naming a few: 1) retry 
> intended config, 2) retry intended config with continue-on-error, 3) 
> re-apply the previous intended config, …
> In other words:
>
>  1. the client shall not touch the applied config directly,
>  2. the server shall not touch the intended config,
>  3. it’s up to the server to align the intended with the applied
>     config in a way requested by the client (i.e. rollback-on-error, …)
>  4. Once applied, the server notifies the client about success or
>     failure to do so
>
I think that it cleaner just to fail and roll back the entire request 
(both intended and applied), i.e. effectively implementing default 
transaction semantics.  The client still has full control as to what to 
do after the failure has occurred.  I'm not sure how leaving it in 
intended config would pragmatically work with subsequent requests that 
may have been queued up.

Thanks,
Rob


--------------000502000404090501030906
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Gert,

      

      Please see one comment inline ...

      

      On 23/12/2015 10:24, Gert Grammel wrote:

    

    

      
      
Rob, Kent,

      


      

      
Adding to Rob’s comments:

      


      

      


      

      


      

      
        

          From: netmod <netmod-bounces@ietf.org>
          on behalf of Robert Wilton <robert.public@wilton.org.uk>

          Date: Wednesday 23
          December 2015 09:28

          To: Kent Watsen <kwatsen@juniper.net>,
          "netmod@ietf.org"
          <netmod@ietf.org>

          Subject: Re: [netmod]
          netmod-opstate-reqs and error option terms (rollback on error)

        

        


        

        

          

            
Hi Kent,

            


            

            
Yes, I think that we are in agreement.

            


            

            
I've one further comment inline below ...

            


            

            
On 23/12/2015 02:41, Kent Watsen wrote:

            

              
[As a contributor]

              


              

              
Hi Robert, I want to go back to Jason’s original
                questions.  I think we’re aligned on this, but please
                check my answers below.

              


              

              
Quoting Jason’s original text now:

              


              

              


              

              

                
Is there some intention in the opstate requirements
                  to add some sort

                
of all-or-nothing behavior to transition (C)?

              

              
Yes

            

          

        

      
      
+1 (if rollback-on-error has been requested)

      


      

      
        

          

            

              


              

              


              

              

                
i.e. if some part of

                
an edit fails during the transition from
                  intended->applied we should

                
"rollback" the other parts that may have already
                  been applied ?

              

              
Yes

            

          

        

      
      
+1 (if rollback-on-error has been requested)

      
        

          

            

              


              

              


              

              

                
Would we then remove it all from intended as well ?

              

              
IMO, yes.  This is more easily understood when
                thinking about Synchronous Configuration Operations
                (defined in opstate-reqs), but I believe that it equally
                applies to Asynchronous Configuration Operations, so
                long as the client explicitly ops-in for the behavior.

            

          

        

      
      
IMO no. The intended config is imposed by the client to the
        server and other than performing some syntax check, the server
        has no choice to accept it as-is. If the server can’t apply the
        intended config, obviously the mismatch between intended and
        applied config needs to be notified. As a result, it is up to
        the client to decide what to do. Actions can vary according to
        the situation naming a few: 1) retry intended config, 2) retry
        intended config with continue-on-error, 3) re-apply the previous
        intended config, …

      
In other words: 

      
    
        
  1. the client shall not touch the applied config directly, 
    2. 
        
  2. the server shall not touch the intended config, 
    3. 
        
  3. it’s up to the server to align the intended with the applied
          config in a way requested by the client (i.e.
          rollback-on-error, …)
    4. 
        
  4. Once applied, the server notifies the client about success
          or failure to do so
    5. 
      

    

    I think that it cleaner just to fail and roll back the entire
    request (both intended and applied), i.e. effectively implementing
    default transaction semantics.  The client still has full control as
    to what to do after the failure has occurred.  I'm not sure how
    leaving it in intended config would pragmatically work with
    subsequent requests that may have been queued up.

    

    Thanks,

    Rob

    

  


--------------000502000404090501030906--


From nobody Wed Dec 23 13:35:13 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE411A8787 for ; Wed, 23 Dec 2015 13:35:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 8n6yAFn-u3DY for ; Wed, 23 Dec 2015 13:35:09 -0800 (PST)
Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::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 6D1871A877E for ; Wed, 23 Dec 2015 13:35:08 -0800 (PST)
Received: by mail-lb0-x233.google.com with SMTP id oh2so52580980lbb.3 for ; Wed, 23 Dec 2015 13:35:08 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=1vBC1LyZIaT9+hn+kDS07IaL3oY+7k7jPg4wf23OVc4=; b=FZnQ1gZ1sjjiHd7byfbrdSxynap20sZf7Y0sM08/ScilO0Fs8SbpniWqpnua/r71cb LxPy1IoxrAx8iL0fH/qiqX45Jj3T8hRhnOhQNucZX3US71SVA/DQNw4wn/XWVq6aUbot zJXdH3xuMXJxQTp95sEYMPJ6vAohFizEpITaB8lNoMTxc9CiaYYUhsOCxA4GRGjivOLp nkGd7fCcEZv7fls8VMZLRVtXDZ3AcG1RLZbtx9NwFp5nmGEof1LO1DsQc4gKqpUIsNr+ WkP0guIa7FdxRJ1JZvcKP6upVfkyWwNQKJX/R+nplQUFVmA+s6wo0+tyT4zTOQjX9P6w 6Smw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1vBC1LyZIaT9+hn+kDS07IaL3oY+7k7jPg4wf23OVc4=; b=ijOe0AFSbiH/pa5ByaTbaVjKbes+yw9b/cT9N4WaNtA7s9GNUyfoi2xz6mtloWq971 QPf83WCA3alj6wuuEpERnB5mDgFDEw7Cp8pCHyR6lOiAmbEdIUbP/x89w47sJjA/k0Wu 50YDIS8CIjVGl2f2gxjrWT0xkbIKQTiPzP3ZtH6KfosG72V3Evx54zX+c2ZDRRr/ZYfC QCA95RqmBUOXFFVS/mmyZ4i7L8b6aCmVM6oTZqu0vvgMJMdenqk+lfo07FPkR4AG4UNN UU/FXnplcrw50JESiipwL1M9pZHFR2Y6Av0NtG7O+yenX4KZgVnXUbFMY+Y5D4ckgMjm +Quw==
X-Gm-Message-State: ALoCoQnB0hmDh/rDR2waRCKjXldDsd3OtuBqfWP+IMNvvUS+YIj+JkmOzOG/RU+FHgF9KQ1uXlHOuPQxS7tj/jcnclfVkSsolg==
MIME-Version: 1.0
X-Received: by 10.112.134.169 with SMTP id pl9mr10885548lbb.145.1450906506497;  Wed, 23 Dec 2015 13:35:06 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Wed, 23 Dec 2015 13:35:06 -0800 (PST)
In-Reply-To: <567B09A0.1080203@wilton.org.uk>
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>  <56783B45.1020505@cisco.com> <20151221180231.GC43694@elstar.local> <147269F5-7B47-4614-9C08-948E8B5FC65C@nic.cz>  <6AFC7C6C-61B7-4310-A0CA-08A7CD76A899@nic.cz>      <567B09A0.1080203@wilton.org.uk>
Date: Wed, 23 Dec 2015 13:35:06 -0800
Message-ID: 
From: Andy Bierman 
To: Robert Wilton 
Content-Type: multipart/alternative; boundary=089e011767e9ec28890527977e8a
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2015 21:35:12 -0000

--089e011767e9ec28890527977e8a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Dec 23, 2015 at 12:52 PM, Robert Wilton  wrote:

> Hi,
>
> On 23/12/2015 18:22, Acee Lindem (acee) wrote:
>
>
>
> From: Andy Bierman < andy@yumaworks.com>
> Date: Wednesday, December 23, 2015 at 11:18 AM
> To: Acee Lindem < acee@cisco.com>
> Cc: Ladislav Lhotka , Kent Watsen , "
> netmod@ietf.org" 
> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>
>
>
> On Wed, Dec 23, 2015 at 8:11 AM, Acee Lindem (acee) 
> wrote:
>
>>
>>
>> From: Andy Bierman 
>> Date: Wednesday, December 23, 2015 at 10:46 AM
>> To: Acee Lindem 
>> Cc: Ladislav Lhotka , Kent Watsen , =
"
>> netmod@ietf.org" < netmod@ietf.org>
>> Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>>
>>
>>
>> On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (acee) 
>> wrote:
>>
>>>
>>> On 12/23/15, 3:22 AM, "netmod on behalf of Ladislav Lhotka"
>>>  wrote:
>>>
>>> >
>>> >> On 23 Dec 2015, at 04:06, Kent Watsen < 
>>> kwatsen@juniper.net> wrote:
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> On 12/21/15, 2:21 PM, "netmod on behalf of Ladislav Lhotka"
>>> >>< netmod-bounces@ietf.org on behalf of
>>> lhotka@nic.cz> wrote:
>>> >>
>>> >>>
>>> >>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>>> >>>>< 
>>> j.schoenwaelder@jacobs-university.de> wrote:
>>> >>>>
>>> >>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100, Benoit Claise wrote:
>>> >>>>
>>> >>>>> I hope that nobody disagrees that the operational state design an=
d
>>> >>>>>how
>>> >>>>> to structure the models are the two blocking factors to publish
>>> YANG
>>> >>>>> models. If you disagree or don't see this, let me know, I should
>>> >>>>> communicate better.
>>> >>>>
>>> >>>> Even if it may spoil your day, I disagree that there is a blocking
>>> >>>> factor that should stop us from publishing models. There seem to b=
e
>>> >>>> ways to address the requirements without having to block all work =
or
>>> >>>> to redo what that we have published. But sure, if you make it a
>>> >>>> blocking factor, it will be one.
>>> >>>
>>> >>> I agree with Juergen. It is not clear to me how the proposed split
>>> >>>between intended and applied configuration is supposed to affect the
>>> >>>data models we are working on.
>>> >>
>>> >>
>>> >> As I understand it, solution #1 affects the models themselves, where=
as
>>> >>solutions #2 and #3 are transparent to the models.
>>> >
>>> >Then #1 looks like a non-starter to me.
>>>
>>> I=E2=80=99d like to point out that we also have the requirement to allo=
w
>>> retrieval
>>> of derived-state along with intended-config and applied-config. This wi=
ll
>>> require modification to most of the existing YANG drafts as most now ha=
ve
>>> separate trees for config and operational state. Note that this is
>>> discussed in sections 6, 7.3, and 7.4 of
>>> https://www.ietf.org/id/draft-wilton-netmod-opstate-yang-02.txt.
>>>
>>>
>> A NETCONF  with a subtree filter  can retrieveg both config and
>> non-config subtrees
>> at the same time.  A new RPC can be added (or existing  RPC
>> extended) to
>> filter various conditions.  I don't see how the YANG data layout affects
>> the definition
>> of "rpc" statements in another module.
>>
>>
>> There is the requirement to be able to do the retrievals but there is
>> also this requirement:
>>
>>  C.  The mappings needs to be programmatically consumable
>>
>>
>> Now, if the derived-state nodes are located with the config-nodes, then
>> this is readily satisfied. Another way of satisfying the requirement may=
 be
>> structural and naming conventions but this is not as sure as co-location=
.
>>
>>
> There can be meta-data returned (XML attributes) that identify the
> additional properties.
> This is better co-location since the pattern cannot be unintentional (as
> it can with the
> config-within-state containers).
>
>
> This may be an option for published models. However, for models in
> development, wouldn=E2=80=99t it be easier to just move the nodes rather =
than
> defining the relationships in meta-data?
>
>
> Just relying on meta-data to relate config and state would probably add a
> lot of relations noise to the models.  I would imagine that this would ma=
ke
> the models source YANG files harder to read, and potentially have a sligh=
t
> negative performance impact in the clients - which may be important if th=
ey
> have to relate many nodes.
>
>
The meta-data is not defined in the YANG models. It is defined for the
protocol.
Co-location doesn't really scale.  A system may have candidate, running,
startup,
and even proprietary "state-related" data collections. It would take 3 or 4
copies of the data to
model these datastores inside the data models.



But IMO any solution that burdens the server with retrieval
requests while the device is busy applying config will only
make the problem worse.




> Hence why I think that it is best to use co-location where possible, and
> just use explicit meta-data where the nodes are further apart in the data
> tree.
>
>

I looked at your draft.
Is it implemented anywhere?
It requires a custom parser that sometimes parses the leaf "foo" as a YANG
leaf
but if the special request is made, then the reply will be returning "foo"
as a container of leafs,
instead of a leaf like normal.





> This still leaves the question as to what to do with the interfaces vs
> interfaces-state.  There would seem to be two possible solutions to me: (=
1)
> merge the trees together as per OpenConfig, or (2) add a special case rul=
e
> for interfaces.  I think that this is an issue that neither Kent's nor my
> draft fully addresses.
>

This is different -- interfaces-state can contain discovered interfaces tha=
t
have not been configured yet.



>
> Thanks,
> Rob
>
>
>
Andy


>
>
> Thanks,
> Acee
>
>
>
>
>
>> Thanks,
>> Acee
>>
>>
> Andy
>
>
>>
>>
>> Thanks,
>>> Acee
>>>
>>
>>
>> Andy
>>
>>
>>>
>>>
>>> >
>>> >Lada
>>> >
>>> >>
>>> >> Kent
>>> >>
>>> >>
>>> >>
>>> >>> Lada
>>> >>>
>>> >>>>
>>> >>>>> I hope that nobody really believes that because some people in IE=
TF
>>> >>>>>(or
>>> >>>>> in any other SDOs) thinks that what those operators want is a bad
>>> >>>>>idea,
>>> >>>>> those operators will not get what they request/pay for from their
>>> >>>>>suppliers.
>>> >>>>
>>> >>>> To be fair, those operators also tell us that they use protocols
>>> that
>>> >>>> are not IETF protocols and it remains somewhat unclear what those
>>> >>>> protocols are we are expected to optimize data model solutions for=
.
>>> >>>>
>>> >>>> /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
>>> >>>
>>> >>> --
>>> >>> Ladislav Lhotka, CZ.NIC Labs
>>> >>> PGP Key ID: E74E8C0C
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> netmod mailing list
>>> >>> netmod@ietf.org
>>> >>> 
>>> https://www.ietf.org/mailman/listinfo/netmod
>>> >
>>> >--
>>> >Ladislav Lhotka, CZ.NIC Labs
>>> >PGP Key ID: E74E8C0C
>>> >
>>> >
>>> >
>>> >
>>> >_______________________________________________
>>> >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 listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/n=
etmod
>
>
>

--089e011767e9ec28890527977e8a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Wed, Dec 23, 2015 at 12:52 PM, Robert Wilton <<=
a href=3D"mailto:robert.public@wilton.org.uk" target=3D"_blank">robert.publ=
ic@wilton.org.uk> wrote:

 =20
   =20
 =20
  

    
Hi,

      

      On 23/12/2015 18:22, Acee Lindem (acee) wrote:

    

    

     =20
      


      

      


      

      
        

          From: Andy Bierman <andy@yumaworks.com>

          Date: Wednesday,
          December 23, 2015 at 11:18 AM

          To: Acee Lindem <acee@cisco.com>

          Cc: Ladislav Lhotka
          <lhotka@nic=
.cz>,
          Kent Watsen <kwatsen@juniper.net>,
          "netmod=
@ietf.org"
          <netmod@i=
etf.org>

          Subject: Re: [netmod]
          NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01

        

        


        

        

          

            

              


                


                  
On Wed, Dec 23, 2015 at 8:11
                    AM, Acee Lindem (acee) 
                      <acee@cisco.com>
                    wrote:

                    

                      

                        


                        

                        


                        

                        
                          

                            From: A=
ndy
                            Bierman <andy@yumaworks.com>

                            Date: W=
ednesday,
                            December 23, 2015 at 10:46 AM

                            To: Ace=
e
                            Lindem <acee@cisco.com>

                            Cc: Lad=
islav
                            Lhotka <lhotka@nic.cz>,
                            Kent Watsen <kwatsen@juniper.net>,
                            "netmod@ietf.org" <netmod@ietf.org>

                            Subject: Re:
                            [netmod] NETMOD WG LC:
                            draft-ietf-netmod-opstate-reqs-01

                          

                          


                          

                          

                            

                              

                                


                                  


                                    
On Wed, Dec
                                      23, 2015 at 7:01 AM, Acee Lindem
                                      (acee) 
                                        <acee@cisco.com>
                                      wrote:

                                      

                                        

                                        On 12/23/15, 3:22 AM, "netmod =
on
                                        behalf of Ladislav Lhotka"

                                        <netmod-bounces@ietf.org
                                        on behalf of
                                        lhotka@nic.cz>
                                        wrote:

                                        

                                        >

                                        >> On 23 Dec 2015, at
                                        04:06, Kent Watsen <kwatsen@juniper.net>
                                        wrote:

                                        >>

                                        >>

                                        >>

                                        >>

                                        >>

                                        >>

                                        >> On 12/21/15, 2:21 PM,
                                        "netmod on behalf of Ladislav
                                        Lhotka"

                                        >><netmod-bounces@ietf.org
                                        on behalf of
                                        lhotka@nic.cz>
                                        wrote:

                                        >>

                                        >>>

                                        >>>> On 21 Dec 2015,
                                        at 19:02, Juergen Schoenwaelder

                                        >>>><j.schoenwaeld=
er@jacobs-university.de>
                                        wrote:

                                        >>>>

                                        >>>> On Mon, Dec 21,
                                        2015 at 06:47:49PM +0100, Benoit
                                        Claise wrote:

                                        >>>>

                                        >>>>> I hope that
                                        nobody disagrees that the
                                        operational state design and

                                        >>>>>how

                                        >>>>> to
                                        structure the models are the two
                                        blocking factors to publish YANG
                                        >>>>> models. If
                                        you disagree or don't see this,
                                        let me know, I should

                                        >>>>> communicate
                                        better.

                                        >>>>

                                        >>>> Even if it may
                                        spoil your day, I disagree that
                                        there is a blocking

                                        >>>> factor that
                                        should stop us from publishing
                                        models. There seem to be

                                        >>>> ways to address
                                        the requirements without having
                                        to block all work or

                                        >>>> to redo what
                                        that we have published. But
                                        sure, if you make it a

                                        >>>> blocking
                                        factor, it will be one.

                                        >>>

                                        >>> I agree with
                                        Juergen. It is not clear to me
                                        how the proposed split

                                        >>>between intended and
                                        applied configuration is
                                        supposed to affect the

                                        >>>data models we are
                                        working on.

                                        >>

                                        >>

                                        >> As I understand it,
                                        solution #1 affects the models
                                        themselves, whereas

                                        >>solutions #2 and #3 are
                                        transparent to the models.

                                        >

                                        >Then #1 looks like a
                                        non-starter to me.

                                        

                                        I=E2=80=99d like to point out that =
we
                                        also have the requirement to
                                        allow retrieval

                                        of derived-state along with
                                        intended-config and
                                        applied-config. This will

                                        require modification to most of
                                        the existing YANG drafts as most
                                        now have

                                        separate trees for config and
                                        operational state. Note that
                                        this is

                                        discussed in sections 6, 7.3,
                                        and 7.4 of

                                        https://www.ietf.org/id/draft-wilton-netmod-opstate-yang-02.txt.

                                        

                                      

                                      


                                      

                                      
A NETCONF <get> with a
                                        subtree filter =C2=A0can retrieveg
                                        both config and non-config
                                        subtrees

                                      
at the same time.=C2=A0 A new RP=
C
                                        can be added (or existing
                                        <get> RPC extended) to

                                      
filter various conditions.=C2=A0=
 I
                                        don't see how the YANG data
                                        layout affects the definition

                                      
of "rpc" statements in
                                        another module.

                                    

                                  

                                

                              

                            

                          

                        
                        


                        

                        
There is the requirement to be able to do
                          the retrievals but there is also this
                          requirement:

                        


                        

                        

                          
 C.  The mappings needs to be programmatical=
ly consumable

                        

                        


                        

                        
Now, if the derived-state nodes are located
                          with the config-nodes, then this is readily
                          satisfied. Another way of satisfying the
                          requirement may be structural and naming
                          conventions but this is not as sure as
                          co-location.=C2=A0

                        


                        

                      

                    

                    


                    

                    
There can be meta-data returned (XML
                      attributes) that identify the additional
                      properties.

                    
This is better co-location since the pattern
                      cannot be unintentional (as it can with the

                    
config-within-state containers).

                  

                

              

            

          

        

      
      


      

      
This may be an option for published models. However, for
        models in development, wouldn=E2=80=99t it be easier to just move t=
he
        nodes rather than defining the relationships in meta-data?

    

    

    Just relying on meta-data to relate config and state would probably
    add a lot of relations noise to the models.=C2=A0 I would imagine that
    this would make the models source YANG files harder to read, and
    potentially have a slight negative performance impact in the clients
    - which may be important if they have to relate many nodes.

    

The meta-data is not defined=
 in the YANG models. It is defined for the protocol.
Co-location =
doesn't really scale.=C2=A0 A system may have candidate, running, start=
up,
and even proprietary "state-related" data collectio=
ns. It would take 3 or 4 copies of the data to
model these datast=
ores inside the data models.



But IMO any solution that burdens the server with retrieval
<=
div>requests while the device is busy applying config will only
m=
ake the problem worse.


=C2=A0
=


    Hence why I think that it is best to use co-location where possible,
    and just use explicit meta-data where the nodes are further apart in
    the data tree.

    


I looked at y=
our draft.
Is it implemented anywhere?
It requires a cu=
stom parser that sometimes parses the leaf "foo" as a YANG leaf
but if the special request is made, then the reply will be returni=
ng "foo" as a container of leafs,
instead of a leaf lik=
e normal.=C2=A0



=C2=
=A0

    This still leaves the question as to what to do with the interfaces
    vs interfaces-state.=C2=A0 There would seem to be two possible solution=
s
    to me: (1) merge the trees together as per OpenConfig, or (2) add a
    special case rule for interfaces.=C2=A0 I think that this is an issue
    that neither Kent's nor my draft fully addresses.

This is different -- interfaces-state can contain =
discovered interfaces that
have not been configured yet.=C2=A0

=C2=A0

    

    Thanks,

    Rob

    

    

Andy
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

    

      
=C2=A0

      


      

      
Thanks,

      
Acee=C2=A0

      


      

      


      

      
        

          

            

              

                

                  

                    


                    

                    
=C2=A0

                    

                      

                        
Thanks,

                        
Acee=C2=A0

                        


                        

                      

                    

                    


                    

                    
Andy

                    
=C2=A0

                    

                      

                        
                          

                            

                              

                                

                                  

                                    

                                      


                                      

                                      


                                      

                                      

                                        Thanks,

                                        Acee

                                      

                                      


                                      

                                      


                                      

                                      
Andy

                                      
=C2=A0

                                      

                                        

                                        

                                        >

                                        >Lada

                                        >

                                        >>

                                        >> Kent

                                        >>

                                        >>

                                        >>

                                        >>> Lada

                                        >>>

                                        >>>>

                                        >>>>> I hope that
                                        nobody really believes that
                                        because some people in IETF

                                        >>>>>(or

                                        >>>>> in any
                                        other SDOs) thinks that what
                                        those operators want is a bad

                                        >>>>>idea,

                                        >>>>> those
                                        operators will not get what they
                                        request/pay for from their

                                        >>>>>suppliers.

                                        >>>>

                                        >>>> To be fair,
                                        those operators also tell us
                                        that they use protocols that

                                        >>>> are not IETF
                                        protocols and it remains
                                        somewhat unclear what those

                                        >>>> protocols are
                                        we are expected to optimize data
                                        model solutions for.

                                        >>>>

                                        >>>> /js

                                        >>>>

                                        >>>> --

                                        >>>> Juergen
                                        Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0Jacobs
                                        University Bremen gGmbH

                                        >>>> Phone: +49 421
                                        200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0Campus 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

                                        >>>

                                        >>> --

                                        >>> Ladislav Lhotka,
                                        CZ.NIC Labs

                                        >>> PGP Key ID:
                                        E74E8C0C

                                        >>>

                                        >>>

                                        >>>

                                        >>>

                                        >>>
                                        ___________________________________=
____________

                                        >>> netmod mailing list
                                        >>> netmod@ietf.org

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

                                        >

                                        >--

                                        >Ladislav Lhotka, CZ.NIC Labs
                                        >PGP Key ID: E74E8C0C

                                        >

                                        >

                                        >

                                        >

>_______________________________________________

                                        >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


    

    

  






--089e011767e9ec28890527977e8a--


From nobody Wed Dec 23 14:05:57 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6711A8855 for ; Wed, 23 Dec 2015 14:05:55 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 bYNezsbOPQca for ; Wed, 23 Dec 2015 14:05:51 -0800 (PST)
Received: from auth-4.ukservers.net (auth-4.ukservers.net [217.10.138.158]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A20E11A8852 for ; Wed, 23 Dec 2015 14:05:50 -0800 (PST)
Received: from [192.168.1.66] (host86-166-225-11.range86-166.btcentralplus.com [86.166.225.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by auth-4.ukservers.net (Postfix smtp) with ESMTPSA id 6071A3762943; Wed, 23 Dec 2015 22:05:45 +0000 (GMT)
To: Andy Bierman 
References: <21156339.1450395923495.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> <5673EF18.80907@cisco.com> <68DAE5A8-E982-4C22-97AE-0B41AFC14E4C@juniper.net>  <56783B45.1020505@cisco.com> <20151221180231.GC43694@elstar.local> <147269F5-7B47-4614-9C08-948E8B5FC65C@nic.cz>  <6AFC7C6C-61B7-4310-A0CA-08A7CD76A899@nic.cz>      <567B09A0.1080203@wilton.org.uk> 
From: Robert Wilton 
Message-ID: <567B1ABA.3020301@wilton.org.uk>
Date: Wed, 23 Dec 2015 22:05:46 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------030709070207010105070708"
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 23 Dec 2015 22:05:55 -0000

This is a multi-part message in MIME format.
--------------030709070207010105070708
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Andy,

On 23/12/2015 21:35, Andy Bierman wrote:
>
>
> On Wed, Dec 23, 2015 at 12:52 PM, Robert Wilton 
> > wrote:
>
>     Hi,
>
>     On 23/12/2015 18:22, Acee Lindem (acee) wrote:
>>
>>
>>     From: Andy Bierman >
>>     Date: Wednesday, December 23, 2015 at 11:18 AM
>>     To: Acee Lindem >
>>     Cc: Ladislav Lhotka >, Kent
>>     Watsen >,
>>     "netmod@ietf.org " >     >
>>     Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>>
>>
>>
>>         On Wed, Dec 23, 2015 at 8:11 AM, Acee Lindem (acee)
>>         > wrote:
>>
>>
>>
>>             From: Andy Bierman >             >
>>             Date: Wednesday, December 23, 2015 at 10:46 AM
>>             To: Acee Lindem >
>>             Cc: Ladislav Lhotka >             >, Kent Watsen >             >, "netmod@ietf.org
>>             " >             >
>>             Subject: Re: [netmod] NETMOD WG LC:
>>             draft-ietf-netmod-opstate-reqs-01
>>
>>
>>
>>                 On Wed, Dec 23, 2015 at 7:01 AM, Acee Lindem (acee)
>>                 > wrote:
>>
>>
>>                     On 12/23/15, 3:22 AM, "netmod on behalf of
>>                     Ladislav Lhotka"
>>                     >                      on behalf of
>>                     lhotka@nic.cz > wrote:
>>
>>                     >
>>                     >> On 23 Dec 2015, at 04:06, Kent Watsen
>>                     >                     > wrote:
>>                     >>
>>                     >>
>>                     >>
>>                     >>
>>                     >>
>>                     >>
>>                     >> On 12/21/15, 2:21 PM, "netmod on behalf of
>>                     Ladislav Lhotka"
>>                     >>>                      on behalf of
>>                     lhotka@nic.cz > wrote:
>>                     >>
>>                     >>>
>>                     >>>> On 21 Dec 2015, at 19:02, Juergen Schoenwaelder
>>                     >>>>>                     > wrote:
>>                     >>>>
>>                     >>>> On Mon, Dec 21, 2015 at 06:47:49PM +0100,
>>                     Benoit Claise wrote:
>>                     >>>>
>>                     >>>>> I hope that nobody disagrees that the
>>                     operational state design and
>>                     >>>>>how
>>                     >>>>> to structure the models are the two
>>                     blocking factors to publish YANG
>>                     >>>>> models. If you disagree or don't see this,
>>                     let me know, I should
>>                     >>>>> communicate better.
>>                     >>>>
>>                     >>>> Even if it may spoil your day, I disagree
>>                     that there is a blocking
>>                     >>>> factor that should stop us from publishing
>>                     models. There seem to be
>>                     >>>> ways to address the requirements without
>>                     having to block all work or
>>                     >>>> to redo what that we have published. But
>>                     sure, if you make it a
>>                     >>>> blocking factor, it will be one.
>>                     >>>
>>                     >>> I agree with Juergen. It is not clear to me
>>                     how the proposed split
>>                     >>>between intended and applied configuration is
>>                     supposed to affect the
>>                     >>>data models we are working on.
>>                     >>
>>                     >>
>>                     >> As I understand it, solution #1 affects the
>>                     models themselves, whereas
>>                     >>solutions #2 and #3 are transparent to the models.
>>                     >
>>                     >Then #1 looks like a non-starter to me.
>>
>>                     I’d like to point out that we also have the
>>                     requirement to allow retrieval
>>                     of derived-state along with intended-config and
>>                     applied-config. This will
>>                     require modification to most of the existing YANG
>>                     drafts as most now have
>>                     separate trees for config and operational state.
>>                     Note that this is
>>                     discussed in sections 6, 7.3, and 7.4 of
>>                     https://www.ietf.org/id/draft-wilton-netmod-opstate-yang-02.txt.
>>
>>
>>                 A NETCONF  with a subtree filter  can retrieveg
>>                 both config and non-config subtrees
>>                 at the same time.  A new RPC can be added (or
>>                 existing  RPC extended) to
>>                 filter various conditions.  I don't see how the YANG
>>                 data layout affects the definition
>>                 of "rpc" statements in another module.
>>
>>
>>             There is the requirement to be able to do the retrievals
>>             but there is also this requirement:
>>
>>               C.  The mappings needs to be programmatically consumable
>>
>>
>>             Now, if the derived-state nodes are located with the
>>             config-nodes, then this is readily satisfied. Another way
>>             of satisfying the requirement may be structural and
>>             naming conventions but this is not as sure as co-location.
>>
>>
>>         There can be meta-data returned (XML attributes) that
>>         identify the additional properties.
>>         This is better co-location since the pattern cannot be
>>         unintentional (as it can with the
>>         config-within-state containers).
>>
>>
>>     This may be an option for published models. However, for models
>>     in development, wouldn’t it be easier to just move the nodes
>>     rather than defining the relationships in meta-data?
>
>     Just relying on meta-data to relate config and state would
>     probably add a lot of relations noise to the models.  I would
>     imagine that this would make the models source YANG files harder
>     to read, and potentially have a slight negative performance impact
>     in the clients - which may be important if they have to relate
>     many nodes.
>
>
> The meta-data is not defined in the YANG models. It is defined for the 
> protocol.
> Co-location doesn't really scale.  A system may have candidate, 
> running, startup,
> and even proprietary "state-related" data collections. It would take 3 
> or 4 copies of the data to
> model these datastores inside the data models.

I think that we may be talking across purposes.  My comments are 
regarding the relationship between operational nodes (aka derived state) 
and configuration, as per Acee's comments regarding my draft above.

>
>
>
> But IMO any solution that burdens the server with retrieval
> requests while the device is busy applying config will only
> make the problem worse.
I think that with the OpenConfig model based approach, the assumption is 
that they would register to be notified of changes to the datastore 
nodes.  If it is possible to register for such notifications with an 
appropriate level of filtering/granularity then I imaging that a 
management client wouldn't necessarily need to ever poll/read the data 
(except on corned case scenarios).  Instead, it can just rely on push 
notifications of the nodes that have changed.  I would think that such a 
system would be performant.

>
>
>     Hence why I think that it is best to use co-location where
>     possible, and just use explicit meta-data where the nodes are
>     further apart in the data tree.
>
>
>
> I looked at your draft.
Thanks.

> Is it implemented anywhere?
No.  Realistically, I would expect that it would need to gain more 
support before anyone would spend time implementing it.

> It requires a custom parser that sometimes parses the leaf "foo" as a 
> YANG leaf
> but if the special request is made, then the reply will be returning 
> "foo" as a container of leafs,
> instead of a leaf like normal.
Yes, agreed.

I'm not sure whether you have had the opportunity to look at the version 
2 of the draft that I published at the beginning of the week.  The main 
body of the draft hasn't really changed, but I have added an appendix 
with a possible overview of how it might be implemented using attributes 
(as you previously suggested).  If you have time to review the appendix, 
then I would be interested to know whether this is what you had broadly 
envisaged.


>
>
>
>     This still leaves the question as to what to do with the
>     interfaces vs interfaces-state.  There would seem to be two
>     possible solutions to me: (1) merge the trees together as per
>     OpenConfig, or (2) add a special case rule for interfaces.  I
>     think that this is an issue that neither Kent's nor my draft fully
>     addresses.
>
>
> This is different -- interfaces-state can contain discovered 
> interfaces that
> have not been configured yet.
Yes, of course, but has the downside that it forces a separation between 
the configuration and operational state for interfaces.

Personally, ignoring all the backwards compatibility issues, I would 
prefer that interfaces and interfaces-state were a combined single list 
(as proposed by OpenConfig).  E.g. something along the lines of:
  - the system can still provide an operational list of discovered 
interfaces so that clients can know what is there.
  - but management agents would be expected to explicitly configure 
(i.e. create an entry for) all interfaces for which it wanted to 
retrieve data for.

Thanks,
Rob


--------------030709070207010105070708
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Andy,

      

      On 23/12/2015 21:35, Andy Bierman wrote:

    

    

      


        


          
On Wed, Dec 23, 2015 at 12:52 PM,
            Robert Wilton <robert.public@wilton.org.uk>
            wrote:

            

              

                
Hi,

                  

                  On 23/12/2015 18:22, Acee Lindem (acee) wrote:

                

                

                  


                  

                  


                  

                  
                    
 From: Andy
                      Bierman <andy@yumaworks.com>

                      Date: Wednesday,

                      December 23, 2015 at 11:18 AM

                      To: Acee
                      Lindem <acee@cisco.com>

                      Cc: Ladislav
                      Lhotka <lhotka@nic.cz>,

                      Kent Watsen <kwatsen@juniper.net>, "netmod@ietf.org"
                      <netmod@ietf.org>

                      Subject: Re:
                      [netmod] NETMOD WG LC:
                      draft-ietf-netmod-opstate-reqs-01

                    

                    


                    

                    

                      

                        

                          


                            


                              
On Wed, Dec 23,
                                2015 at 8:11 AM, Acee Lindem (acee)  <acee@cisco.com>
                                wrote:

                                

                                  

                                    


                                    

                                    


                                    

                                    
                                      
 From:
                                        Andy Bierman <andy@yumaworks.com>

                                        Date:
                                        Wednesday, December 23,
                                        2015 at 10:46 AM

                                        To:
                                        Acee Lindem <acee@cisco.com>

                                        Cc:
                                        Ladislav Lhotka <lhotka@nic.cz>,

                                        Kent Watsen <kwatsen@juniper.net>,

                                        "netmod@ietf.org"
                                        <netmod@ietf.org>

                                        Subject:
                                        Re: [netmod] NETMOD WG
                                        LC:
                                        draft-ietf-netmod-opstate-reqs-01

                                      

                                      


                                      

                                      

                                        

                                          

                                            


                                              


                                                
On
                                                  Wed, Dec 23, 2015 at
                                                  7:01 AM, Acee Lindem
                                                  (acee)  <acee@cisco.com>
                                                  wrote:

                                                  

                                                    

                                                    On 12/23/15, 3:22
                                                    AM, "netmod on
                                                    behalf of Ladislav
                                                    Lhotka"

                                                    <netmod-bounces@ietf.org
                                                    on behalf of lhotka@nic.cz> wrote:

                                                    

                                                    >

                                                    >> On 23 Dec
                                                    2015, at 04:06, Kent
                                                    Watsen <kwatsen@juniper.net>

                                                    wrote:

                                                    >>

                                                    >>

                                                    >>

                                                    >>

                                                    >>

                                                    >>

                                                    >> On
                                                    12/21/15, 2:21 PM,
                                                    "netmod on behalf of
                                                    Ladislav Lhotka"

                                                    >><netmod-bounces@ietf.org
                                                    on behalf of lhotka@nic.cz> wrote:

                                                    >>

                                                    >>>

                                                    >>>> On
                                                    21 Dec 2015, at
                                                    19:02, Juergen
                                                    Schoenwaelder

                                                    >>>><j.schoenwaelder@jacobs-university.de>

                                                    wrote:

                                                    >>>>

                                                    >>>> On
                                                    Mon, Dec 21, 2015 at
                                                    06:47:49PM +0100,
                                                    Benoit Claise wrote:

                                                    >>>>

                                                    >>>>>
                                                    I hope that nobody
                                                    disagrees that the
                                                    operational state
                                                    design and

>>>>>how

                                                    >>>>>
                                                    to structure the
                                                    models are the two
                                                    blocking factors to
                                                    publish YANG

                                                    >>>>>
                                                    models. If you
                                                    disagree or don't
                                                    see this, let me
                                                    know, I should

                                                    >>>>>
                                                    communicate better.

                                                    >>>>

                                                    >>>>
                                                    Even if it may spoil
                                                    your day, I disagree
                                                    that there is a
                                                    blocking

                                                    >>>>
                                                    factor that should
                                                    stop us from
                                                    publishing models.
                                                    There seem to be

                                                    >>>>
                                                    ways to address the
                                                    requirements without
                                                    having to block all
                                                    work or

                                                    >>>> to
                                                    redo what that we
                                                    have published. But
                                                    sure, if you make it
                                                    a

                                                    >>>>
                                                    blocking factor, it
                                                    will be one.

                                                    >>>

                                                    >>> I agree
                                                    with Juergen. It is
                                                    not clear to me how
                                                    the proposed split

                                                    >>>between
                                                    intended and applied
                                                    configuration is
                                                    supposed to affect
                                                    the

                                                    >>>data
                                                    models we are
                                                    working on.

                                                    >>

                                                    >>

                                                    >> As I
                                                    understand it,
                                                    solution #1 affects
                                                    the models
                                                    themselves, whereas

                                                    >>solutions #2
                                                    and #3 are
                                                    transparent to the
                                                    models.

                                                    >

                                                    >Then #1 looks
                                                    like a non-starter
                                                    to me.

                                                    

                                                    I’d like to point
                                                    out that we also
                                                    have the requirement
                                                    to allow retrieval

                                                    of derived-state
                                                    along with
                                                    intended-config and
                                                    applied-config. This
                                                    will

                                                    require modification
                                                    to most of the
                                                    existing YANG drafts
                                                    as most now have

                                                    separate trees for
                                                    config and
                                                    operational state.
                                                    Note that this is

                                                    discussed in
                                                    sections 6, 7.3, and
                                                    7.4 of

                                                    https://www.ietf.org/id/draft-wilton-netmod-opstate-yang-02.txt.

                                                    

                                                  

                                                  


                                                  

                                                  
A NETCONF
                                                    <get> with a
                                                    subtree filter  can
                                                    retrieveg both
                                                    config and
                                                    non-config subtrees

                                                  
at the same
                                                    time.  A new RPC can
                                                    be added (or
                                                    existing <get>
                                                    RPC extended) to

                                                  
filter various
                                                    conditions.  I don't
                                                    see how the YANG
                                                    data layout affects
                                                    the definition

                                                  
of "rpc"
                                                    statements in
                                                    another module.

                                                

                                              

                                            

                                          

                                        

                                      

                                    
                                    


                                    

                                    
There is the requirement to be
                                      able to do the retrievals but
                                      there is also this requirement:

                                    


                                    

                                    

                                      
 C.  The mappings needs to be programmatically consumable

                                    

                                    


                                    

                                    
Now, if the derived-state nodes
                                      are located with the config-nodes,
                                      then this is readily satisfied.
                                      Another way of satisfying the
                                      requirement may be structural and
                                      naming conventions but this is not
                                      as sure as co-location. 

                                    


                                    

                                  

                                

                                


                                

                                
There can be meta-data returned
                                  (XML attributes) that identify the
                                  additional properties.

                                
This is better co-location since
                                  the pattern cannot be unintentional
                                  (as it can with the

                                
config-within-state containers).

                              

                            

                          

                        

                      

                    

                  
                  


                  

                  
This may be an option for published models.
                    However, for models in development, wouldn’t it be
                    easier to just move the nodes rather than defining
                    the relationships in meta-data?

                

                

                Just relying on meta-data to relate config and state
                would probably add a lot of relations noise to the
                models.  I would imagine that this would make the models
                source YANG files harder to read, and potentially have a
                slight negative performance impact in the clients -
                which may be important if they have to relate many
                nodes.

                

              

            

            


            

            
The meta-data is not defined in the YANG models. It is
              defined for the protocol.

            
Co-location doesn't really scale.  A system may have
              candidate, running, startup,

            
and even proprietary "state-related" data collections.
              It would take 3 or 4 copies of the data to

            
model these datastores inside the data models.

          

        

      

    

    

    I think that we may be talking across purposes.  My comments are
    regarding the relationship between operational nodes (aka derived
    state) and configuration, as per Acee's comments regarding my draft
    above.

    

    

      

        

          

            


            

            


            

            


            

            
But IMO any solution that burdens the server with
              retrieval

            
requests while the device is busy applying config will
              only

            
make the problem worse.

          

        

      

    

    I think that with the OpenConfig model based approach, the
    assumption is that they would register to be notified of changes to
    the datastore nodes.  If it is possible to register for such
    notifications with an appropriate level of filtering/granularity
    then I imaging that a management client wouldn't necessarily need to
    ever poll/read the data (except on corned case scenarios).  Instead,
    it can just rely on push notifications of the nodes that have
    changed.  I would think that such a system would be performant.

    

    

      

        

          

            


            

            


            

            
 

            

              
 Hence why I think
                that it is best to use co-location where possible, and
                just use explicit meta-data where the nodes are further
                apart in the data tree.

                

              

            

            


            

            


            

            
I looked at your draft.

          

        

      

    

    Thanks.

    

    

      

        

          

            
Is it implemented anywhere?

          

        

      

    

    No.  Realistically, I would expect that it would need to gain more
    support before anyone would spend time implementing it.

    

    

      

        

          

            
It requires a custom parser that sometimes parses the
              leaf "foo" as a YANG leaf

            
but if the special request is made, then the reply will
              be returning "foo" as a container of leafs,

            
instead of a leaf like normal. 

            

          

        

      

    

    Yes, agreed.

    

    I'm not sure whether you have had the opportunity to look at the
    version 2 of the draft that I published at the beginning of the
    week.  The main body of the draft hasn't really changed, but I have
    added an appendix with a possible overview of how it might be
    implemented using attributes (as you previously suggested).  If you
    have time to review the appendix, then I would be interested to know
    whether this is what you had broadly envisaged.

    

    

    

      

        

          

            


            

            


            

            


            

            
 

            

              
 This still leaves
                the question as to what to do with the interfaces vs
                interfaces-state.  There would seem to be two possible
                solutions to me: (1) merge the trees together as per
                OpenConfig, or (2) add a special case rule for
                interfaces.  I think that this is an issue that neither
                Kent's nor my draft fully addresses.

              

            

            


            

            
This is different -- interfaces-state can contain
              discovered interfaces that

            
have not been configured yet. 

            

          

        

      

    

    Yes, of course, but has the downside that it forces a separation
    between the configuration and operational state for interfaces.

    

    Personally, ignoring all the backwards compatibility issues, I would
    prefer that interfaces and interfaces-state were a combined single
    list (as proposed by OpenConfig).  E.g. something along the lines
    of:

     - the system can still provide an operational list of discovered
    interfaces so that clients can know what is there.

     - but management agents would be expected to explicitly configure
    (i.e. create an entry for) all interfaces for which it wanted to
    retrieve data for.

    

    Thanks,

    Rob

    

  


--------------030709070207010105070708--


From nobody Mon Dec 28 00:23:39 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEAEA1A8A55 for ; Mon, 28 Dec 2015 00:23:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.961
X-Spam-Level: 
X-Spam-Status: No, score=-2.961 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 pSqiGI7umINT for ; Mon, 28 Dec 2015 00:23:36 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 332561A8A54 for ; Mon, 28 Dec 2015 00:23:35 -0800 (PST)
Received: from [IPv6:2001:718:1a02:1:64d9:f2b6:d61b:65c5] (unknown [IPv6:2001:718:1a02:1:64d9:f2b6:d61b:65c5]) by mail.nic.cz (Postfix) with ESMTPSA id CB5B0181B34 for ; Mon, 28 Dec 2015 09:23:33 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1451291013; bh=ILEQ0aFm6XWyOdE1+qsoAJlkEBzyNvaO0/cEGi49Suw=; h=From:Date:To; b=MaVnCvFET1JcDDQeYEhFm15ppdnfzENfQcJGZG2vvQkiwXVeLSwQVK+Rna2xvsWSI lyDJ/UcoUZR5fKvSFZIePnw8l47cSgPqA5vezfofdD92fZN8Xa16JweUTgXxNKFdHF jWaRvosGs7mFqEThh7Rxmicqn74/zkhCh4uLeHMA=
From: Ladislav Lhotka 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <0CFCD92E-E220-4664-84E8-C2E2847F27EA@nic.cz>
Date: Mon, 28 Dec 2015 09:23:35 +0100
To: NETMOD WG 
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: [netmod] whitespace characters
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Dec 2015 08:23:38 -0000

Hi,

the definition of "enum" argument (sec. 9.6.4 in 6020bis) says:

   The string MUST NOT be empty and MUST NOT have any leading or =
trailing
   whitespace characters.

It is not clear what "whitespace character" means. The ABNF indicates =
this:

   WSP                 =3D SP / HTAB
                         ; whitespace

I think in the "enum" definition LF (and maybe also CR?) should also =
count as a whitespace character.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon Dec 28 05:08:27 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6DE51A90CA for ; Mon, 28 Dec 2015 05:08:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.16
X-Spam-Level: 
X-Spam-Status: No, score=-1.16 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 ID00PFsB2XCo for ; Mon, 28 Dec 2015 05:08:23 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DC6B1A90C9 for ; Mon, 28 Dec 2015 05:08:23 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A8B8FF68; Mon, 28 Dec 2015 14:08:21 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Qnoj_6XYk91H; Mon, 28 Dec 2015 14:08:20 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 28 Dec 2015 14:08:20 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA6C720056; Mon, 28 Dec 2015 14:08:20 +0100 (CET)
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 Iu9-NJEpC3rt; Mon, 28 Dec 2015 14:08:19 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 115A420055; Mon, 28 Dec 2015 14:08:19 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 9E46E3962D21; Mon, 28 Dec 2015 14:08:16 +0100 (CET)
Date: Mon, 28 Dec 2015 14:08:15 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
Message-ID: <20151228130815.GA56466@elstar.local>
Mail-Followup-To: Robert Wilton , "Acee Lindem (acee)" , Andy Bierman , "netmod@ietf.org" 
References: <20151221180231.GC43694@elstar.local> <147269F5-7B47-4614-9C08-948E8B5FC65C@nic.cz>  <6AFC7C6C-61B7-4310-A0CA-08A7CD76A899@nic.cz>      <567B09A0.1080203@wilton.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <567B09A0.1080203@wilton.org.uk>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Dec 2015 13:08:26 -0000

On Wed, Dec 23, 2015 at 08:52:48PM +0000, Robert Wilton wrote:
> 
> Just relying on meta-data to relate config and state would probably add 
> a lot of relations noise to the models.  I would imagine that this would 
> make the models source YANG files harder to read, and potentially have a 
> slight negative performance impact in the clients - which may be 
> important if they have to relate many nodes.
> 
> Hence why I think that it is best to use co-location where possible, and 
> just use explicit meta-data where the nodes are further apart in the 
> data tree.
>

For me, the most obvious and least disrupting solution remains a new
datastore. We already have running and startup, it seems logical to
extend this with an applied datastore. If there is a need to retrieve
data from multiple data stores in a single RPC call, then lets define
an RPC that does it.

> This still leaves the question as to what to do with the interfaces vs 
> interfaces-state.  There would seem to be two possible solutions to me: 
> (1) merge the trees together as per OpenConfig, or (2) add a special 
> case rule for interfaces.  I think that this is an issue that neither 
> Kent's nor my draft fully addresses.

I assume there are more data models out there (implemented, deployed)
that follow the RFC 7223 model. And there are cases where operational
state goes beyond applied config so I am not sure merging really helps
anyone. If the verbs (=RPCs) are too restrictive, lets extend the
verbs instead of forcing even more complexity on the data models.

/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 Dec 28 06:24:19 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE611A00BE for ; Mon, 28 Dec 2015 06:24:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.86
X-Spam-Level: 
X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 UzUsdOutKsGb for ; Mon, 28 Dec 2015 06:24:17 -0800 (PST)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D622F1A00BC for ; Mon, 28 Dec 2015 06:24:16 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A4B1D8FC; Mon, 28 Dec 2015 15:24:15 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id EwvZ9jp67FVp; Mon, 28 Dec 2015 15:24:14 +0100 (CET)
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 atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 28 Dec 2015 15:24:14 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7436D20056; Mon, 28 Dec 2015 15:24:14 +0100 (CET)
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 0RL7eP7jw9Dl; Mon, 28 Dec 2015 15:24:13 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5C49920055; Mon, 28 Dec 2015 15:24:12 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 830F43962E1C; Mon, 28 Dec 2015 15:24:11 +0100 (CET)
Date: Mon, 28 Dec 2015 15:24:11 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
Message-ID: <20151228142409.GA56667@elstar.local>
Mail-Followup-To: Robert Wilton , Andy Bierman , "netmod@ietf.org" 
References:  <6AFC7C6C-61B7-4310-A0CA-08A7CD76A899@nic.cz>      <567B09A0.1080203@wilton.org.uk>  <567B1ABA.3020301@wilton.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <567B1ABA.3020301@wilton.org.uk>
User-Agent: Mutt/1.4.2.3i
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Juergen Schoenwaelder 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Dec 2015 14:24:18 -0000

On Wed, Dec 23, 2015 at 10:05:46PM +0000, Robert Wilton wrote:
> 
> Personally, ignoring all the backwards compatibility issues, I would 
> prefer that interfaces and interfaces-state were a combined single list 
> (as proposed by OpenConfig).  E.g. something along the lines of:
>  - the system can still provide an operational list of discovered 
> interfaces so that clients can know what is there.
>  - but management agents would be expected to explicitly configure 
> (i.e. create an entry for) all interfaces for which it wanted to 
> retrieve data for.
>

A clear separation of config from operational state is one of the
outcomes of the IAB workshop documented in RFC 3535 and it is one of
the key foundations of both NETCONF and YANG. Config and operational
state have different and _independent_ lifetimes - you can have config
for resources that are not present and you can have operational state
for resources that are present but not configured. In addition, the
data models for operational state are often not the same as the data
models for configuration. Merging all things back into a single list
with a single keying (naming) structure gets us back into the mess we
were in with SNMP.

/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 Dec 28 08:46:45 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15301A039F for ; Mon, 28 Dec 2015 08:46:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.361
X-Spam-Level: 
X-Spam-Status: No, score=-5.361 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 8cVOtbNmpDxO for ; Mon, 28 Dec 2015 08:46:42 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A83C81A039C for ; Mon, 28 Dec 2015 08:46:41 -0800 (PST)
Received: from [IPv6:2a01:5e0:29:ffff:c837:d115:499b:938c] (unknown [IPv6:2a01:5e0:29:ffff:c837:d115:499b:938c]) by mail.nic.cz (Postfix) with ESMTPSA id DD38018144D; Mon, 28 Dec 2015 17:46:38 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1451321198; bh=MMxArXat1yEQB94WQ0LVcery5o6tJNuMigt6lv/pxn0=; h=From:Date:To; b=SVFKqdJ8nURATWD37ibglygOHRnG/ekOFxVDQKutiWxNB+GDBiIJmHqiEFkdrM5Eb bcMBx+cORwOTfLWdh1NmD7f2y4wyYj5JNa1Ai/Ha2rIjD1D5wf8HdDcVYotlXoN+DA JceEHJYS8s2NfXpGKDhXRDdKIGsM3seKfufaAHP4=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <20151228142409.GA56667@elstar.local>
Date: Mon, 28 Dec 2015 17:46:38 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <425145F1-6743-4160-9E7C-70CA20D6E8D3@nic.cz>
References:  <6AFC7C6C-61B7-4310-A0CA-08A7CD76A899@nic.cz>      <567B09A0.1080203@wilton.org.uk>  <567B1ABA.3020301@wilton.org.uk> <20151228142409.GA56667@elstar.local>
To: =?utf-8?Q?J=C3=BCrgen_Sch=C3=B6nw=C3=A4lder?= 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Dec 2015 16:46:44 -0000

> On 28 Dec 2015, at 15:24, Juergen Schoenwaelder =
 wrote:
>=20
> On Wed, Dec 23, 2015 at 10:05:46PM +0000, Robert Wilton wrote:
>>=20
>> Personally, ignoring all the backwards compatibility issues, I would=20=

>> prefer that interfaces and interfaces-state were a combined single =
list=20
>> (as proposed by OpenConfig).  E.g. something along the lines of:
>> - the system can still provide an operational list of discovered=20
>> interfaces so that clients can know what is there.
>> - but management agents would be expected to explicitly configure=20
>> (i.e. create an entry for) all interfaces for which it wanted to=20
>> retrieve data for.
>>=20
>=20
> A clear separation of config from operational state is one of the
> outcomes of the IAB workshop documented in RFC 3535 and it is one of
> the key foundations of both NETCONF and YANG. Config and operational
> state have different and _independent_ lifetimes - you can have config
> for resources that are not present and you can have operational state
> for resources that are present but not configured. In addition, the
> data models for operational state are often not the same as the data
> models for configuration. Merging all things back into a single list
> with a single keying (naming) structure gets us back into the mess we
> were in with SNMP.

I agree. A good example is in ietf-routing: static routes are part of =
configuration but in state data they only appear in RIBs together with =
protocol originated-routes - there is no representation of static routes =
per se in state data. Data models for configuration and state data can =
indeed be rather different.

I would also add that IMO state data can in general be expected less =
standardised than configuration because they often need to be closer to =
the underlying device implementation.

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Mon Dec 28 09:41:15 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE6A1A911F for ; Mon, 28 Dec 2015 09:41:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level: 
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 6y13963PcApd for ; Mon, 28 Dec 2015 09:41:04 -0800 (PST)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0799.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::799]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F05A1A911D for ; Mon, 28 Dec 2015 09:41:03 -0800 (PST)
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com (10.161.162.13) by CY1PR0501MB1452.namprd05.prod.outlook.com (10.160.149.13) with Microsoft SMTP Server (TLS) id 15.1.361.13; Mon, 28 Dec 2015 17:40:43 +0000
Received: from CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) by CY1PR0501MB1609.namprd05.prod.outlook.com ([10.161.162.13]) with mapi id 15.01.0361.006; Mon, 28 Dec 2015 17:40:43 +0000
From: Gert Grammel 
To: Robert Wilton 
Thread-Topic: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
Thread-Index: AQHRPCF5yZUEnm9OEEacfs09McNkmJ7X3pwAgABg/ICAADECgIAAp+GAgAedAV0=
Date: Mon, 28 Dec 2015 17:40:42 +0000
Message-ID: <5CB86359-D6B1-4D84-962C-750A8D7AE174@juniper.net>
References:  <56784B9B.5020408@cisco.com> <327E370C-4D5F-4F9A-B982-B71108CEBC08@juniper.net> <567A5B39.3010909@wilton.org.uk> ,<567B1129.9090104@wilton.org.uk>
In-Reply-To: <567B1129.9090104@wilton.org.uk>
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=ggrammel@juniper.net; 
x-originating-ip: [80.187.107.38]
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1452; 5:z2dM8DUoQnhcl+3dOAutcH0kegbG8NbW0tkI6zJN5JrXaHOwPZKcLF7P+CLsT2qPq7viuV9AEaxwDlYHLvZOW1WTyAu6WjXSjSC1qOfcX/1eIpoHuvpR7MzNF8pkz6l/3/tGD/iHCWGrNc9c6H12Sw==; 24:opQDqWwLHvGeuehqb7RRegjG6ySDSJfbFgqaf4hLngM2tAJEe8aho/SEhrfkPulno9evWW3odVyGiReoC8JQikYOi3e1ge57N3HfzTtU9l8=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1452;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(10201501046)(3002001); SRVR:CY1PR0501MB1452; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1452; 
x-forefront-prvs: 08041D247D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(189002)(199003)(164054003)(51444003)(479174004)(87936001)(99286002)(230783001)(54356999)(33656002)(2900100001)(2950100001)(106356001)(106116001)(101416001)(105586002)(551934003)(66066001)(92566002)(36756003)(11100500001)(77096005)(40100003)(93886004)(5002640100001)(5004730100002)(6116002)(76176999)(586003)(1096002)(1220700001)(86362001)(102836003)(3846002)(97736004)(82746002)(122556002)(5008740100001)(83716003)(50986999)(81156007)(16236675004)(189998001)(10400500002)(5001960100002)(19580405001)(110136002)(19580395003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1452; H:CY1PR0501MB1609.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)
Content-Type: multipart/alternative; boundary="_000_5CB86359D6B14D84962C750A8D7AE174junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Dec 2015 17:40:42.7450 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1452
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback on error)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Dec 2015 17:41:13 -0000

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

Rob,

>From a client perspective there should be no difference in the intended sta=
te behavior depending on error conditions, if continue-on-error leaves the =
intended state, a rollback-on-error should keep it as well. Moreover, a cli=
ent reaction on a unsuccessful application of intended state could be to a)=
 re-try, b) retry with continue-on-error or c) retry wit stop-on-error. Tho=
se actions would not require any change of intended state.
It shouldn't be the server to decide what the intended state is supposed to=
 be or hoe long it should last.

Gert


Sent from my Apple ][

On 23 Dec 2015, at 22:25, Robert Wilton > wrote:

Hi Gert,

Please see one comment inline ...

On 23/12/2015 10:24, Gert Grammel wrote:
Rob, Kent,

Adding to Rob's comments:



From: netmod <netmod-bounces@ietf.org> on behalf of Robert Wilton >
Date: Wednesday 23 December 2015 09:28
To: Kent Watsen <kwatsen@juniper.net>, "netmod@ietf.org" >
Subject: Re: [netmod] netmod-opstate-reqs and error option terms (rollback =
on error)

Hi Kent,

Yes, I think that we are in agreement.

I've one further comment inline below ...

On 23/12/2015 02:41, Kent Watsen wrote:
[As a contributor]

Hi Robert, I want to go back to Jason's original questions.  I think we're =
aligned on this, but please check my answers below.

Quoting Jason's original text now:


Is there some intention in the opstate requirements to add some sort
of all-or-nothing behavior to transition (C)?
Yes
+1 (if rollback-on-error has been requested)



i.e. if some part of
an edit fails during the transition from intended->applied we should
"rollback" the other parts that may have already been applied ?
Yes
+1 (if rollback-on-error has been requested)


Would we then remove it all from intended as well ?
IMO, yes.  This is more easily understood when thinking about Synchronous C=
onfiguration Operations (defined in opstate-reqs), but I believe that it eq=
ually applies to Asynchronous Configuration Operations, so long as the clie=
nt explicitly ops-in for the behavior.
IMO no. The intended config is imposed by the client to the server and othe=
r than performing some syntax check, the server has no choice to accept it =
as-is. If the server can't apply the intended config, obviously the mismatc=
h between intended and applied config needs to be notified. As a result, it=
 is up to the client to decide what to do. Actions can vary according to th=
e situation naming a few: 1) retry intended config, 2) retry intended confi=
g with continue-on-error, 3) re-apply the previous intended config, ...
In other words:

  1.  the client shall not touch the applied config directly,
  2.  the server shall not touch the intended config,
  3.  it's up to the server to align the intended with the applied config i=
n a way requested by the client (i.e. rollback-on-error, ...)
  4.  Once applied, the server notifies the client about success or failure=
 to do so

I think that it cleaner just to fail and roll back the entire request (both=
 intended and applied), i.e. effectively implementing default transaction s=
emantics.  The client still has full control as to what to do after the fai=
lure has occurred.  I'm not sure how leaving it in intended config would pr=
agmatically work with subsequent requests that may have been queued up.

Thanks,
Rob


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







Rob,







From a client perspective there should be no=
 difference in the intended state behavior depending on error conditions, i=
f continue-on-error leaves the intended state, a rollback-on-error should k=
eep it as well. Moreover, a client
 reaction on a unsuccessful application of intended state could be to a) re=
-try, b) retry with continue-on-error or c) retry wit stop-on-error. Those =
actions would not require any change of intended state.


It shouldn't be the server to decide what th=
e intended state is supposed to be or hoe long it should last. 







Gert






Sent from my Apple ][




On 23 Dec 2015, at 22:25, Robert Wilton <robert.public@wilton.org.uk> wrote:










Hi Gert,



Please see one comment inline ...



On 23/12/2015 10:24, Gert Grammel wrote:






Rob, Kent,







Adding to Rob’s comments:



















From: netmod <netmod-bounces@iet=
f.org> on behalf of Robert Wilton <robert.public@wilton.org.uk&g=
t;

Date: Wednesday 23 December 2015 09=
:28

To: Kent Watsen <kwatsen@juniper.net=
>, "net=
mod@ietf.org"
 <netmod@iet=
f.org>

Subject: Re: [netmod] netmod-opstat=
e-reqs and error option terms (rollback on error)













Hi Kent,







Yes, I think that we are in agreement.







I've one further comment inline below ...







On 23/12/2015 02:41, Kent Watsen wrote:




[As a contributor]







Hi Robert, I want to go back to Jason’s original questions. =
; I think we’re aligned on this, but please check my answers bel=
ow.







Quoting Jason’s original text now:














Is there some intention in the opstate requirements to add some sort

of all-or-nothing behavior to transition (C)?




Yes









+1 (if rollback-on-error has been requested)


























i.e. if some part of


an edit fails during the transition from intended->applied we shoul=
d


"rollback" the other parts that may have already been applie=
d ?




Yes









+1 (if rollback-on-error has been requested)





















Would we then remove it all from intended as well ?




IMO, yes.  This is more easily understood when thinking abou=
t Synchronous Configuration Operations (defined in opstate-reqs), but I bel=
ieve that it equally applies to Asynchronous Configuration Operations, so l=
ong as the client explicitly ops-in for the
 behavior.









IMO no. The intended config is imposed by the client to the server and=
 other than performing some syntax check, the server has no choice to accep=
t it as-is. If the server can’t apply the intended config, obviously =
the mismatch between intended and applied
 config needs to be notified. As a result, it is up to the client to decide=
 what to do. Actions can vary according to the situation naming a few: 1) r=
etry intended config, 2) retry intended config with continue-on-error, 3) r=
e-apply the previous intended config,
 …


In other words: 


    

  1. the client shall not touch the applied config directly,  
  2. =
the server shall not touch the intended config,  
  3. it’s u=
p to the server to align the intended with the applied config in a way requ=
ested by the client (i.e. rollback-on-error, …)

  4. Once applied, the server notifies the client about success or fail=
ure to do so




I think that it cleaner just to fail and roll back the entire request (both=
 intended and applied), i.e. effectively implementing default transaction s=
emantics.  The client still has full control as to what to do after th=
e failure has occurred.  I'm not sure
 how leaving it in intended config would pragmatically work with subsequent=
 requests that may have been queued up.



Thanks,

Rob










--_000_5CB86359D6B14D84962C750A8D7AE174junipernet_--


From nobody Mon Dec 28 10:01:55 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78B41A9142 for ; Mon, 28 Dec 2015 10:01:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.801
X-Spam-Level: 
X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 Mn35zf3J_sy2 for ; Mon, 28 Dec 2015 10:01:52 -0800 (PST)
Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 3217D1A9132 for ; Mon, 28 Dec 2015 10:01:52 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=BOyJQo3NUKEJvr3FtRooFNwXlzRSssZcOdeccHnci9twa6D/Kz1UbO8mCJiWePl4; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.36] (helo=elwamui-hybrid.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aDc76-00087D-Gp for netmod@ietf.org; Mon, 28 Dec 2015 13:01:44 -0500
Received: from 76.254.50.33 by webmail.earthlink.net with HTTP; Mon, 28 Dec 2015 13:01:44 -0500
Message-ID: <29527813.1451325704540.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
Date: Mon, 28 Dec 2015 10:01:44 -0800 (GMT-08:00)
From: Randy Presuhn 
To: NETMOD WG 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888857e9f10d2205ddc18f197f6b231929e47018cd3e39b262b350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.36
Archived-At: 
Subject: Re: [netmod] whitespace characters
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Dec 2015 18:01:54 -0000

Hi -

This got me thinking - would "U+202A U+202B" thus be a valid
argument, distinct from, say, "U+202B U+202A"?

Randy


-----Original Message-----
>From: Ladislav Lhotka 
>Sent: Dec 28, 2015 12:23 AM
>To: NETMOD WG 
>Subject: [netmod] whitespace characters
>
>Hi,
>
>the definition of "enum" argument (sec. 9.6.4 in 6020bis) says:
>
>   The string MUST NOT be empty and MUST NOT have any leading or trailing
>   whitespace characters.
>
>It is not clear what "whitespace character" means. The ABNF indicates this:
>
>   WSP                 = SP / HTAB
>                         ; whitespace
>
>I think in the "enum" definition LF (and maybe also CR?) should also count as a whitespace character.
>
>Lada
>
>--
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C
>
>
>
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod


From nobody Mon Dec 28 10:30:22 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EFA1A924B for ; Mon, 28 Dec 2015 10:30:21 -0800 (PST)
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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 dmnPBLGKg5PS for ; Mon, 28 Dec 2015 10:30:20 -0800 (PST)
Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by ietfa.amsl.com (Postfix) with ESMTP id D93131A92B2 for ; Mon, 28 Dec 2015 10:30:19 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=e9ExLl5H6/gMaZopP4hI0If1RDUU6SQeGlGQ/DNIuMI3737j+geWWKtw2B4QexBc; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.36] (helo=elwamui-hybrid.atl.sa.earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aDcYg-0006Kn-Ak for netmod@ietf.org; Mon, 28 Dec 2015 13:30:14 -0500
Received: from 76.254.50.33 by webmail.earthlink.net with HTTP; Mon, 28 Dec 2015 13:30:14 -0500
Message-ID: <17458705.1451327414188.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
Date: Mon, 28 Dec 2015 10:30:14 -0800 (GMT-08:00)
From: Randy Presuhn 
To: "netmod@ietf.org" 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888857e9f10d2205ddc2c3313beb6554c10bdcfa4f715d8709a350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.36
Archived-At: 
Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 28 Dec 2015 18:30:21 -0000

Hi -

>From: Juergen Schoenwaelder 
>Sent: Dec 28, 2015 6:24 AM
>To: Robert Wilton 
>Cc: "netmod@ietf.org" 
>Subject: Re: [netmod] NETMOD WG LC: draft-ietf-netmod-opstate-reqs-01
>
>On Wed, Dec 23, 2015 at 10:05:46PM +0000, Robert Wilton wrote:
>> 
>> Personally, ignoring all the backwards compatibility issues, I would 
>> prefer that interfaces and interfaces-state were a combined single list 
>> (as proposed by OpenConfig).  E.g. something along the lines of:
>>  - the system can still provide an operational list of discovered 
>> interfaces so that clients can know what is there.
>>  - but management agents would be expected to explicitly configure 
>> (i.e. create an entry for) all interfaces for which it wanted to 
>> retrieve data for.
>>
>
>A clear separation of config from operational state is one of the
>outcomes of the IAB workshop documented in RFC 3535 and it is one of
>the key foundations of both NETCONF and YANG. Config and operational
>state have different and _independent_ lifetimes - you can have config
>for resources that are not present and you can have operational state
>for resources that are present but not configured. In addition, the
>data models for operational state are often not the same as the data
>models for configuration. Merging all things back into a single list
>with a single keying (naming) structure gets us back into the mess we
>were in with SNMP.

This assumes that separation of config from operational state
is best represented in naming.   I think trying to get one's naming architecture to simultaneously and consistently encode too many
aspects of whatever is being modelled brings some of the messiness that concerns you. Perhaps it's finally time to consider what the intended
semantics of the NETCONF / YANG naming architecture really are,
to stop trying to overload them further, and figure out what means
are appropriate for all those other semantics folks have tried to
foist onto naming.

Randy


From nobody Tue Dec 29 01:09:16 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBAEB1A6F58 for ; Tue, 29 Dec 2015 01:09:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.661
X-Spam-Level: 
X-Spam-Status: No, score=-5.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 vg_n5pTyorKe for ; Tue, 29 Dec 2015 01:09:14 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B4E01A1B96 for ; Tue, 29 Dec 2015 01:09:12 -0800 (PST)
Received: from [IPv6:2a01:5e0:29:ffff:3884:7690:9f74:1e2f] (unknown [IPv6:2a01:5e0:29:ffff:3884:7690:9f74:1e2f]) by mail.nic.cz (Postfix) with ESMTPSA id AE208181A2A for ; Tue, 29 Dec 2015 10:09:10 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1451380150; bh=3d44tbi+U85CiyvvTqaIEt/Ad1X460Yxfu6tkbAKzSU=; h=From:Date:To; b=IIg02HGaJg4fZQ5vvaqEE033Wa12blg7NLgp91PL5pWkKTyyen7vZ16nIo7k+m6mT X8bYKAlPiNaTq5pL7rb4YK31VpBO3Yyza/Qa9Lr3T3W8T/a3NPuYo4D6pcjwoGzD3U 4apfWG67Fz4aU0xI9tZDwt6Vak/zUzIXZwTYmQ9Q=
From: Ladislav Lhotka 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: 
Date: Tue, 29 Dec 2015 10:09:11 +0100
To: NETMOD WG 
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: [netmod] comments
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Dec 2015 09:09:16 -0000

Hi,

I propose the following change to sec. 14 in 6020bis (third paragraph):

OLD
   This grammar assumes that the scanner replaces YANG comments with a
   single space character.

NEW
   This grammar assumes that the scanner replaces YANG comments outside
   quoted arguments with a single space character.

I think it would be useful to mention this substitution also in sec 6.1.1.

Lada 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Tue Dec 29 08:48:00 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0A71A8890 for ; Tue, 29 Dec 2015 08:48:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 hAqEnhNy_WFz for ; Tue, 29 Dec 2015 08:47:59 -0800 (PST)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 BF9201A884E for ; Tue, 29 Dec 2015 08:47:58 -0800 (PST)
Received: by mail-lf0-x229.google.com with SMTP id c192so38532923lfe.2 for ; Tue, 29 Dec 2015 08:47:58 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=DRy3f2LNV0CdPmMns2q9CkqIH++4BtZZzMwTCd2jms8=; b=L9bLu4Ous1y0Reh0fYUFjECHV2wbtd1qaUsYM1B6ANowNuPl8779uKkPwMWTaneqLQ ZVVlWnuNhE6vmDaE8UIUOZ70MunQofi1hH6ETjMRAVf0oSfSEZCcGVEvZf6x8ZG4SUbg IfYzLp1g8v41oSS31v0WHAuCPfjEA1yoN4csI2nwP8AGBsNe4RAQp5nBa1HHJsWoTRYN rQtGjZydLqZGRgjnnTtKbmZ7/Zfon3W/8ZOc9mXs1Xf3cJlAuqJFUzt/Z9woAfCkmf50 aDdaXeBJw1oe0PZwh/uhqXx8zrma9KTXEy8PXQUs/WLiQ1Hx4MhcvgKjIa/Ch67sVpGi g/pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DRy3f2LNV0CdPmMns2q9CkqIH++4BtZZzMwTCd2jms8=; b=Ksc4B6J2RBH3wcBkT7yRFxTnB1G0NXkEjifjOHkskwfyB6zu2k/EG5GQckKigHrJbh VxN/QLZVqZqbgPGDWcPHVUfdnMPuK3L0UalP5+CG/XLrlDb5vBmtOp80HkwKab+KciVq OnjfWnNKjZcxBEnTlJGLGw8wpp+zE5+kQV60Cqf5hbmxIjCG08HWvbq3wyWZPij2pH1T prLG//GANaXuI0ALtJXa0d2IZEnr+E/cqZQdW1NfY56CI3m/D941yJ88dFGmhcVylp03 S0K32WSVkRwPkDR/vOSB7ycm+Czg5+wsyixNkb17ZSDlHYQRkvR5OWZEaGgxD3GQkuFn 1UYg==
X-Gm-Message-State: ALoCoQlTQQpN83CV4K4eYkt0rdI8+YF0VKThSpRuBQzeAbhqqTKldpFJVxn+QhXEZiz4HEySBGqPYadeRzE2Y/+9H1ZtckNlMA==
MIME-Version: 1.0
X-Received: by 10.25.218.9 with SMTP id r9mr21716155lfg.138.1451407676694; Tue, 29 Dec 2015 08:47:56 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Tue, 29 Dec 2015 08:47:56 -0800 (PST)
In-Reply-To: 
References: 
Date: Tue, 29 Dec 2015 08:47:56 -0800
Message-ID: 
From: Andy Bierman 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a11402600fe866c05280c2e27
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] comments
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Dec 2015 16:48:00 -0000

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

On Tue, Dec 29, 2015 at 1:09 AM, Ladislav Lhotka  wrote:

> Hi,
>
> I propose the following change to sec. 14 in 6020bis (third paragraph):
>
> OLD
>    This grammar assumes that the scanner replaces YANG comments with a
>    single space character.
>
> NEW
>    This grammar assumes that the scanner replaces YANG comments outside
>    quoted arguments with a single space character.
>
>

A comment inside a quoted string is not a YANG comment.
It is just part of a string that happens to look like a comment.


Andy


> I think it would be useful to mention this substitution also in sec 6.1.1.
>
> Lada
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Tue, Dec 29, 2015 at 1:09 AM, Ladislav Lhotka <=
lhotka@nic.cz> wrote:
Hi,



I propose the following change to sec. 14 in 6020bis (third paragraph):



OLD

=C2=A0 =C2=A0This grammar assumes that the scanner replaces YANG comments w=
ith a

=C2=A0 =C2=A0single space character.



NEW

=C2=A0 =C2=A0This grammar assumes that the scanner replaces YANG comments o=
utside

=C2=A0 =C2=A0quoted arguments with a single space character.




A comment inside a quot=
ed string is not a YANG comment.
It is just part of a string that=
 happens to look like a comment.


An=
dy
=C2=A0

I think it would be useful to mention this substitution also in sec 6.1.1.<=
br>


Lada



--

Ladislav Lhotka, CZ.NIC Labs

PGP Key ID: E74E8C0C









_______________________________________________

netmod mailing list

netmod@ietf.org

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





--001a11402600fe866c05280c2e27--


From nobody Tue Dec 29 08:53:30 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16C2C1A88B1 for ; Tue, 29 Dec 2015 08:53:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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_Sybu-pnAIM for ; Tue, 29 Dec 2015 08:53:27 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 775131A88AF for ; Tue, 29 Dec 2015 08:53:27 -0800 (PST)
Received: from [IPv6:2a01:5e0:29:ffff:558d:a957:df70:c564] (unknown [IPv6:2a01:5e0:29:ffff:558d:a957:df70:c564]) by mail.nic.cz (Postfix) with ESMTPSA id 1CA031818F8; Tue, 29 Dec 2015 17:53:26 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1451408006; bh=3TTmwoSxuxgObn6JRPEwDjqm6ULVj8tE/4vRpHpuPtw=; h=From:Date:To; b=LP6K7MHV7KBGUjz3Dqoobf07WaJMCBNszRFJfS0PaGgbXW8y59y2KedfHwRtqpznJ ParOSo6XtkM4cT2GPBDKbutRM+VTAkyDS0LNoZvXej9ELgkCP1yx4EjpgCwEn/CNF0 YANECt9DGtHb/b+ZbuqNJ8/xI0GPO20pnCk2ru88=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Tue, 29 Dec 2015 17:53:24 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <67AEC897-854A-4CF3-B531-A27B530FB5C7@nic.cz>
References:  
To: Andy Bierman 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] comments
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Dec 2015 16:53:29 -0000

> On 29 Dec 2015, at 17:47, Andy Bierman  wrote:
> 
> 
> 
> On Tue, Dec 29, 2015 at 1:09 AM, Ladislav Lhotka  wrote:
> Hi,
> 
> I propose the following change to sec. 14 in 6020bis (third paragraph):
> 
> OLD
>    This grammar assumes that the scanner replaces YANG comments with a
>    single space character.
> 
> NEW
>    This grammar assumes that the scanner replaces YANG comments outside
>    quoted arguments with a single space character.
> 
> 
> 
> A comment inside a quoted string is not a YANG comment.
> It is just part of a string that happens to look like a comment.

As far as I can tell, this is not clear from the text.

Lada

> 
> 
> Andy
>  
> I think it would be useful to mention this substitution also in sec 6.1.1.
> 
> Lada
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Tue Dec 29 09:42:23 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76BF1A015F for ; Tue, 29 Dec 2015 09:42:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 oBIw0TXOEJ3E for ; Tue, 29 Dec 2015 09:42:20 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 66F751A0161 for ; Tue, 29 Dec 2015 09:42:20 -0800 (PST)
Received: from stubbs.local (24-247-68-31.dhcp.trcy.mi.charter.com [24.247.68.31]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 6542A60BFD; Tue, 29 Dec 2015 17:42:19 +0000 (UTC)
References:   <67AEC897-854A-4CF3-B531-A27B530FB5C7@nic.cz>
User-agent: mu4e 0.9.15; emacs 24.5.1
From: Christian Hopps 
To: Ladislav Lhotka 
In-reply-to: <67AEC897-854A-4CF3-B531-A27B530FB5C7@nic.cz>
Date: Tue, 29 Dec 2015 12:42:15 -0500
Message-ID: 
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] comments
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Dec 2015 17:42:22 -0000

--=-=-=
Content-Type: text/plain


Ladislav Lhotka  writes:

>> On 29 Dec 2015, at 17:47, Andy Bierman  wrote:
>>
>>
>>
>> On Tue, Dec 29, 2015 at 1:09 AM, Ladislav Lhotka  wrote:
>> Hi,
>>
>> I propose the following change to sec. 14 in 6020bis (third paragraph):
>>
>> OLD
>>    This grammar assumes that the scanner replaces YANG comments with a
>>    single space character.
>>
>> NEW
>>    This grammar assumes that the scanner replaces YANG comments outside
>>    quoted arguments with a single space character.
>>
>>
>>
>> A comment inside a quoted string is not a YANG comment.
>> It is just part of a string that happens to look like a comment.
>
> As far as I can tell, this is not clear from the text.

Doesn't the new text actually imply that YANG comments exist inside
quoted arguments?

Thanks,
Chris.

>
> Lada
>
>>
>>
>> Andy
>>
>> I think it would be useful to mention this substitution also in sec 6.1.1.
>>
>> Lada
>>
>> --
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>>
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>


--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJWgsX3AAoJEC4dgw7XuDAl0c8P/jKX83QH9kZpLmtaGgosnYF0
wZoFNj+GoVixV6BsbUbt5Wx7ZOiwo2aculLeRTpFIInJk1CUSrD0ksCaHB3bkcJ5
k92I3xAqJI3PWg0OU9YgypGmanopylGbg0uHUnKjjxA0MPvMQoZDUH3qFdGB/fmJ
PBI6OLrMrcjFZJbbUPgPRhiv+HCpWvQQD1Pz7hOszeDy8KfflE+kz8oX4VivdJIH
LVKPSodYtRxdF5wvElXQEoVyLmRLweEgDJTiIoVFhxEv9qN0VFy3crtRpq3k17Ai
wSDXbBB7MDuGAsWwVsCBahvgFyxS0P3/mkZgpBvpu83MuYmgjYrri+KIglLNbkC9
Kla76jYgVRVdtNiIcnjMJaLu7fKL/W3nrVUrLhqhtoE3Nz+N0/We0Vj7L8NIj+Uz
KTs92D+/uFdXMz5ePOV+mLdFW6Mf7e3lTQtlzNx35TxwmNC0mbs2dF4aMp96j9u5
d2OI1z5mbyA+F8HeZm0oNDohq0eiYpBvPoM9Yc2GyKVXbNM8xiEf6WHQp57B7f8R
bht5OK2+i6BYA/LOt3pp73u59g5/ue/VqGJCO6gdA6/Uw7/noHzGaKDPSs9S+rO7
8n4MzpUMtg695rEh5kRWLkSw30kaVyuWyHjH/mc/y52J2tsAgPNKNzjHpqKAF0U5
JOYkIFyKcv3YwiQngUHT
=s/CZ
-----END PGP SIGNATURE-----
--=-=-=--


From nobody Tue Dec 29 10:07:52 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF841A01EC for ; Tue, 29 Dec 2015 10:07:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level: 
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 1J6oGBkIZGHw for ; Tue, 29 Dec 2015 10:07:50 -0800 (PST)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 77EEB1A01D6 for ; Tue, 29 Dec 2015 10:07:49 -0800 (PST)
Received: by mail-lf0-x22e.google.com with SMTP id z124so210969811lfa.3 for ; Tue, 29 Dec 2015 10:07:49 -0800 (PST)
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:date:message-id:subject:from:to :cc:content-type; bh=QcIGrj3xuhui/Cr7t5PchkA+IhHRnlHOiH1XyhkQ+ik=; b=HC5yEouRqxiDx7mZOoz9qkkUUWHkakupkSKjcCyy0irVj32UVV24mPmmvUxrJciUhe fjbPkHUc0pz74Dbs27NzRjrLRVkAZNsKdA5KUet/qkGRiwsmEY9G2zUYpzDebR389vJh OWQCE+Tx3zgUilEilDWpxzvtESk2P8euMuQkh1u9UUW0mBIKv7VymrJE/Em+iWIpf2Oz tuC/aEcf2/H6JIdU8tDbthhWYzDOzXmUTw7EmN0TvFNE5N2c94u0cui5I1Fq+kawHfxp GqGKHsLGTXqr6mVUd7Jcg2xVBwuzexjYGUfos9nDe2G09DsDA03Gdups7tbIPLdHdceM U5Eg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=QcIGrj3xuhui/Cr7t5PchkA+IhHRnlHOiH1XyhkQ+ik=; b=Op8nGKBKs8LbEvxS30Y+6XvMDJEXmILWABOTU7pqiFqQK6MXTHUc4ZUvhtRrAlBDwf gMokz9o7xb4VcZ1SgFq53mmcSDEkgDvU4Y4fXlOVhAbcZ0hk9BP4ytIBkoM6iX/05adb b+MeBH2B/ve0IZynNRnaX3uncypXGh+5IDAw+s+5tliLYZtPcLe2r2wHQnV+7GA5T4CC gFNBC/jfJf5QdUlMhCoWzCR6hIZoiygRtFBgxlg3V0PzuHe39C/zwmFmRbaaowRVc4ur Mz//jgEYo5aoTM3RrUB7+Kz+Wt5s80UGsU6hX94ndrB9vcnH9aChGGfKUiTuaafveQUI eo4w==
X-Gm-Message-State: ALoCoQnZQB8fSflJlrsYbB+OfY0cFvz8kqu5pQwRAQAFx9UUsHoA2RbsyAmmu50aFlHkTXI3uLOphwPz2eNemDJMfH1SSqsWYA==
MIME-Version: 1.0
X-Received: by 10.25.213.205 with SMTP id m196mr19624943lfg.23.1451412467534;  Tue, 29 Dec 2015 10:07:47 -0800 (PST)
Received: by 10.112.144.36 with HTTP; Tue, 29 Dec 2015 10:07:47 -0800 (PST)
In-Reply-To: 
References:   <67AEC897-854A-4CF3-B531-A27B530FB5C7@nic.cz> 
Date: Tue, 29 Dec 2015 10:07:47 -0800
Message-ID: 
From: Andy Bierman 
To: Christian Hopps 
Content-Type: multipart/alternative; boundary=001a114127508ce5c905280d4c50
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] comments
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 29 Dec 2015 18:07:51 -0000

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

On Tue, Dec 29, 2015 at 9:42 AM, Christian Hopps  wrote:

>
> Ladislav Lhotka  writes:
>
> >> On 29 Dec 2015, at 17:47, Andy Bierman  wrote:
> >>
> >>
> >>
> >> On Tue, Dec 29, 2015 at 1:09 AM, Ladislav Lhotka  wrote:
> >> Hi,
> >>
> >> I propose the following change to sec. 14 in 6020bis (third paragraph):
> >>
> >> OLD
> >>    This grammar assumes that the scanner replaces YANG comments with a
> >>    single space character.
> >>
> >> NEW
> >>    This grammar assumes that the scanner replaces YANG comments outside
> >>    quoted arguments with a single space character.
> >>
> >>
> >>
> >> A comment inside a quoted string is not a YANG comment.
> >> It is just part of a string that happens to look like a comment.
> >
> > As far as I can tell, this is not clear from the text.
>
> Doesn't the new text actually imply that YANG comments exist inside
> quoted arguments?
>
>

The NEW text is wrong.

6.3.  Statements

   A YANG module contains a sequence of statements.  Each statement
   starts with a keyword, followed by zero or one argument, followed
   either by a semicolon (";") or a block of substatements enclosed
   within braces ("{ }"):

     statement = keyword [argument] (";" / "{" *statement "}")

   The argument is a string, as defined in Section 6.1.2.


This seems clear to me that any characters interpreted to be part of
[argument]
are not interpreted as a comment.  A quoted string as [argument] is taken
in its entirety as part of a YANG statement.




> Thanks,
> Chris.
>

Andy


>
> >
> > Lada
> >
> >>
> >>
> >> Andy
> >>
> >> I think it would be useful to mention this substitution also in sec
> 6.1.1.
> >>
> >> Lada
> >>
> >> --
> >> Ladislav Lhotka, CZ.NIC Labs
> >> PGP Key ID: E74E8C0C
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> >>
>
>

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




On Tue, Dec 29, 2015 at 9:42 AM, Christian Hopps <=
chopps@chopps.org> wrote:


Ladislav Lhotka <lhotka@nic.cz> =
writes:



>> On 29 Dec 2015, at 17:47, Andy Bierman <andy@yumaworks.com> wrote:

>>

>>

>>

>> On Tue, Dec 29, 2015 at 1:09 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

>> Hi,

>>

>> I propose the following change to sec. 14 in 6020bis (third paragr=
aph):

>>

>> OLD

>>=C2=A0 =C2=A0 This grammar assumes that the scanner replaces YANG c=
omments with a

>>=C2=A0 =C2=A0 single space character.

>>

>> NEW

>>=C2=A0 =C2=A0 This grammar assumes that the scanner replaces YANG c=
omments outside

>>=C2=A0 =C2=A0 quoted arguments with a single space character.

>>

>>

>>

>> A comment inside a quoted string is not a YANG comment.

>> It is just part of a string that happens to look like a comment.
>

> As far as I can tell, this is not clear from the text.



Doesn't the new text actually imply that YANG comments exist inside

quoted arguments?




The NEW text is wrong.<=
/div>

6.3.=C2=A0 Statements

=C2=
=A0 =C2=A0A YANG module contains a sequence of statements.=C2=A0 Each state=
ment
=C2=A0 =C2=A0starts with a keyword, followed by zero or one =
argument, followed
=C2=A0 =C2=A0either by a semicolon (";&qu=
ot;) or a block of substatements enclosed
=C2=A0 =C2=A0within bra=
ces ("{ }"):

=C2=A0 =C2=A0 =C2=A0stateme=
nt =3D keyword [argument] (";" / "{" *statement "}=
")

=C2=A0 =C2=A0The argument is a string, as =
defined in Section 6.1.2.


This seem=
s clear to me that any characters interpreted to be part of [argument]
are not interpreted as a comment.=C2=A0 A quoted string as [argument]=
 is taken
in its entirety as part of a YANG statement.
=


=C2=A0

Thanks,

Chris.

Andy
=C2=A0



>

> Lada

>

>>

>>

>> Andy

>>

>> I think it would be useful to mention this substitution also in se=
c 6.1.1.

>>

>> Lada

>>

>> --

>> Ladislav Lhotka, CZ.NIC Labs

>> PGP Key ID: E74E8C0C

>>

>>

>>

>>

>> _______________________________________________

>> netmod mailing list

>> netmod@ietf.org

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

>>







--001a114127508ce5c905280d4c50--


From nobody Tue Dec 29 23:32:18 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A5F1AC3CB for ; Tue, 29 Dec 2015 23:32:17 -0800 (PST)
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
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 y-bzMFUJiOCj for ; Tue, 29 Dec 2015 23:32:15 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 274CB1AC3CA for ; Tue, 29 Dec 2015 23:32:14 -0800 (PST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 09F8D1CC0154; Wed, 30 Dec 2015 08:32:17 +0100 (CET)
From: Ladislav Lhotka 
To: Christian Hopps 
In-Reply-To: 
References:   <67AEC897-854A-4CF3-B531-A27B530FB5C7@nic.cz> 
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Wed, 30 Dec 2015 08:32:11 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] comments
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Dec 2015 07:32:18 -0000

Christian Hopps  writes:

> Ladislav Lhotka  writes:
>
>>> On 29 Dec 2015, at 17:47, Andy Bierman  wrote:
>>>
>>>
>>>
>>> On Tue, Dec 29, 2015 at 1:09 AM, Ladislav Lhotka  wrote:
>>> Hi,
>>>
>>> I propose the following change to sec. 14 in 6020bis (third paragraph):
>>>
>>> OLD
>>>    This grammar assumes that the scanner replaces YANG comments with a
>>>    single space character.
>>>
>>> NEW
>>>    This grammar assumes that the scanner replaces YANG comments outside
>>>    quoted arguments with a single space character.
>>>
>>>
>>>
>>> A comment inside a quoted string is not a YANG comment.
>>> It is just part of a string that happens to look like a comment.
>>
>> As far as I can tell, this is not clear from the text.
>
> Doesn't the new text actually imply that YANG comments exist inside
> quoted arguments?

You are right, it is misleading. It would be better to add a sentence
like this to sec. 6.1.1:

NEW
   Inside an argument, the above character pairs are never interpreted
   as the start or end of a comment.

For example, Python spec also says this:

A comment starts with a hash character (#) that is not part of a string
literal, =E2=80=A6

Lada

>
> Thanks,
> Chris.
>
>>
>> Lada
>>
>>>
>>>
>>> Andy
>>>
>>> I think it would be useful to mention this substitution also in sec 6.1=
.1.
>>>
>>> Lada
>>>
>>> --
>>> Ladislav Lhotka, CZ.NIC Labs
>>> PGP Key ID: E74E8C0C
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>

--=20
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Tue Dec 29 23:42:54 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9613B1A1BE9 for ; Tue, 29 Dec 2015 23:42:53 -0800 (PST)
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
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 Br0uCU_Q6vKs for ; Tue, 29 Dec 2015 23:42:52 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 172071A1B74 for ; Tue, 29 Dec 2015 23:42:52 -0800 (PST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 473B41CC0154; Wed, 30 Dec 2015 08:42:56 +0100 (CET)
From: Ladislav Lhotka 
To: Andy Bierman , Christian Hopps 
In-Reply-To: 
References:   <67AEC897-854A-4CF3-B531-A27B530FB5C7@nic.cz>  
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Wed, 30 Dec 2015 08:42:50 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] comments
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Dec 2015 07:42:53 -0000

Andy Bierman  writes:

> On Tue, Dec 29, 2015 at 9:42 AM, Christian Hopps  wrote:
>
>>
>> Ladislav Lhotka  writes:
>>
>> >> On 29 Dec 2015, at 17:47, Andy Bierman  wrote:
>> >>
>> >>
>> >>
>> >> On Tue, Dec 29, 2015 at 1:09 AM, Ladislav Lhotka  wrote:
>> >> Hi,
>> >>
>> >> I propose the following change to sec. 14 in 6020bis (third paragraph):
>> >>
>> >> OLD
>> >>    This grammar assumes that the scanner replaces YANG comments with a
>> >>    single space character.
>> >>
>> >> NEW
>> >>    This grammar assumes that the scanner replaces YANG comments outside
>> >>    quoted arguments with a single space character.
>> >>
>> >>
>> >>
>> >> A comment inside a quoted string is not a YANG comment.
>> >> It is just part of a string that happens to look like a comment.
>> >
>> > As far as I can tell, this is not clear from the text.
>>
>> Doesn't the new text actually imply that YANG comments exist inside
>> quoted arguments?
>>
>>
>
> The NEW text is wrong.
>
> 6.3.  Statements
>
>    A YANG module contains a sequence of statements.  Each statement
>    starts with a keyword, followed by zero or one argument, followed
>    either by a semicolon (";") or a block of substatements enclosed
>    within braces ("{ }"):
>
>      statement = keyword [argument] (";" / "{" *statement "}")
>
>    The argument is a string, as defined in Section 6.1.2.
>
>
> This seems clear to me that any characters interpreted to be part of
> [argument]
> are not interpreted as a comment.  A quoted string as [argument] is taken
> in its entirety as part of a YANG statement.

The distinction between whitespace separators inside and outside
arguments is blurred by the fact that the ABNF has production rules for
arguments that use the same non-terminals representing whitespace as
statement-level productions. For example,

   key-stmt            = key-keyword sep key-arg-str stmtend

and then

   key-arg             = node-identifier *(sep node-identifier)

A comment is valid as the "sep" in the former case but not in the
latter.

Lada

>
>
>
>
>> Thanks,
>> Chris.
>>
>
> Andy
>
>
>>
>> >
>> > Lada
>> >
>> >>
>> >>
>> >> Andy
>> >>
>> >> I think it would be useful to mention this substitution also in sec
>> 6.1.1.
>> >>
>> >> Lada
>> >>
>> >> --
>> >> Ladislav Lhotka, CZ.NIC Labs
>> >> PGP Key ID: E74E8C0C
>> >>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> netmod mailing list
>> >> netmod@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/netmod
>> >>
>>
>>

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Wed Dec 30 00:19:51 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83C31A1A70 for ; Wed, 30 Dec 2015 00:19:49 -0800 (PST)
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
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 9xcZxWNUhkA7 for ; Wed, 30 Dec 2015 00:19:48 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 0452F1A1A6F for ; Wed, 30 Dec 2015 00:19:47 -0800 (PST)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id E4A8F1CC0154; Wed, 30 Dec 2015 09:19:51 +0100 (CET)
From: Ladislav Lhotka 
To: Randy Presuhn , NETMOD WG 
In-Reply-To: <29527813.1451325704540.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
References: <29527813.1451325704540.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Wed, 30 Dec 2015 09:19:45 +0100
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] whitespace characters
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Dec 2015 08:19:50 -0000

Randy Presuhn  writes:

> Hi -
>
> This got me thinking - would "U+202A U+202B" thus be a valid
> argument, distinct from, say, "U+202B U+202A"?

IMO they should be distinct. For "string" type, sec. 9.4.2 in 6020bis
says that no Unicode normalization is performed. The same should
probably be stated for string literals appearing in YANG modules.

Lada

>
> Randy
>
>
> -----Original Message-----
>>From: Ladislav Lhotka 
>>Sent: Dec 28, 2015 12:23 AM
>>To: NETMOD WG 
>>Subject: [netmod] whitespace characters
>>
>>Hi,
>>
>>the definition of "enum" argument (sec. 9.6.4 in 6020bis) says:
>>
>>   The string MUST NOT be empty and MUST NOT have any leading or trailing
>>   whitespace characters.
>>
>>It is not clear what "whitespace character" means. The ABNF indicates this:
>>
>>   WSP                 = SP / HTAB
>>                         ; whitespace
>>
>>I think in the "enum" definition LF (and maybe also CR?) should also count as a whitespace character.
>>
>>Lada
>>
>>--
>>Ladislav Lhotka, CZ.NIC Labs
>>PGP Key ID: E74E8C0C
>>
>>
>>
>>
>>_______________________________________________
>>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, CZ.NIC Labs
PGP Key ID: E74E8C0C


From nobody Wed Dec 30 11:07:18 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191CC1ACE65 for ; Wed, 30 Dec 2015 11:07:17 -0800 (PST)
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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 XyRBldJ2ifn5 for ; Wed, 30 Dec 2015 11:07:15 -0800 (PST)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5F39F1ACE66 for ; Wed, 30 Dec 2015 11:07:14 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=bPrNw6slxibCSsbM3gIMIZ3IZF88LoRDBWUKUC1jVotproMT5jhQR868XOsKf0ed; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.27] (helo=mswamui-billy.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aEM5V-0007Uh-0L for netmod@ietf.org; Wed, 30 Dec 2015 14:07:09 -0500
Received: from 76.254.53.99 by webmail.earthlink.net with HTTP; Wed, 30 Dec 2015 14:07:08 -0500
Message-ID: <23608050.1451502429051.JavaMail.root@mswamui-billy.atl.sa.earthlink.net>
Date: Wed, 30 Dec 2015 11:07:08 -0800 (GMT-08:00)
From: Randy Presuhn 
To: NETMOD WG 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888857e9f10d2205ddc2e046ab2c93a06a76be55d4f62e5b759350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.27
Archived-At: 
Subject: Re: [netmod] whitespace characters
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Dec 2015 19:07:17 -0000

Hi -

>From: Ladislav Lhotka 
>Sent: Dec 30, 2015 12:19 AM
>To: Randy Presuhn , NETMOD WG 
>Subject: Re: [netmod] whitespace characters
>
>Randy Presuhn  writes:
>
>> Hi -
>>
>> This got me thinking - would "U+202A U+202B" thus be a valid
>> argument, distinct from, say, "U+202B U+202A"?
>
>IMO they should be distinct. For "string" type, sec. 9.4.2 in 6020bis
>says that no Unicode normalization is performed. The same should
>probably be stated for string literals appearing in YANG modules.

Even given the semantics of U+202A (left-to-right embedding)?
I understand why they make a difference for strings in general,
but in an enum argument, cases like this seem rather pathological.

Randy

>Lada
>
>>
>> Randy
>>
>>
>> -----Original Message-----
>>>From: Ladislav Lhotka 
>>>Sent: Dec 28, 2015 12:23 AM
>>>To: NETMOD WG 
>>>Subject: [netmod] whitespace characters
>>>
>>>Hi,
>>>
>>>the definition of "enum" argument (sec. 9.6.4 in 6020bis) says:
>>>
>>>   The string MUST NOT be empty and MUST NOT have any leading or trailing
>>>   whitespace characters.
>>>
>>>It is not clear what "whitespace character" means. The ABNF indicates this:
>>>
>>>   WSP                 = SP / HTAB
>>>                         ; whitespace
>>>
>>>I think in the "enum" definition LF (and maybe also CR?) should also count as a whitespace character.
>>>
>>>Lada
>>>
>>>--
>>>Ladislav Lhotka, CZ.NIC Labs
>>>PGP Key ID: E74E8C0C
>>>
>>>
>>>
>>>
>>>_______________________________________________
>>>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, CZ.NIC Labs
>PGP Key ID: E74E8C0C


From nobody Wed Dec 30 13:22:12 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6F81AD1FE for ; Wed, 30 Dec 2015 13:22:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.661
X-Spam-Level: 
X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, T_RP_MATCHES_RCVD=-0.01] autolearn=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 KpzwxnLjaXB8 for ; Wed, 30 Dec 2015 13:22:09 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66CB81AD1F5 for ; Wed, 30 Dec 2015 13:22:08 -0800 (PST)
Received: from [IPv6:2a01:5e0:29:ffff:553:4b5a:6115:87c8] (unknown [IPv6:2a01:5e0:29:ffff:553:4b5a:6115:87c8]) by mail.nic.cz (Postfix) with ESMTPSA id 5D047181890; Wed, 30 Dec 2015 22:22:06 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1451510526; bh=6X3qn5uC+/r5kiD1/k9cuNtZRvHEaHXx85geKiaWn7M=; h=From:Date:To; b=sdgYXkKKpd4jLPg3NSeFPtKZdGG3XBF1tH/xD8VgvilrIoQqoYkJB7ZO4ffWDhl6K LfTSksBdDs4Bs9fzDBvohjk8Zh6O75KJHfFGu0kPFvhwdoO1qmAyvKz3LoZkgKu2Jk vHnqNuiLpey0zvGSkn+qo893qfEYBARv3RlwsQEQ=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Ladislav Lhotka 
In-Reply-To: <23608050.1451502429051.JavaMail.root@mswamui-billy.atl.sa.earthlink.net>
Date: Wed, 30 Dec 2015 22:22:06 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <73376543-3370-4751-9D44-9E0E38CC32EA@nic.cz>
References: <23608050.1451502429051.JavaMail.root@mswamui-billy.atl.sa.earthlink.net>
To: Randy Presuhn 
X-Mailer: Apple Mail (2.3112)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] whitespace characters
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Dec 2015 21:22:11 -0000

> On 30 Dec 2015, at 20:07, Randy Presuhn  =
wrote:
>=20
> Hi -
>=20
>> From: Ladislav Lhotka 
>> Sent: Dec 30, 2015 12:19 AM
>> To: Randy Presuhn , NETMOD WG =

>> Subject: Re: [netmod] whitespace characters
>>=20
>> Randy Presuhn  writes:
>>=20
>>> Hi -
>>>=20
>>> This got me thinking - would "U+202A U+202B" thus be a valid
>>> argument, distinct from, say, "U+202B U+202A"?
>>=20
>> IMO they should be distinct. For "string" type, sec. 9.4.2 in 6020bis
>> says that no Unicode normalization is performed. The same should
>> probably be stated for string literals appearing in YANG modules.
>=20
> Even given the semantics of U+202A (left-to-right embedding)?
> I understand why they make a difference for strings in general,
> but in an enum argument, cases like this seem rather pathological.

Honestly, I don't know, this seems rather pathological in any case. I =
just checked programming languages that claim to have decent Unicode =
handling (Python 3, Haskell), and both consider those two strings =
non-equal.=20

Lada

>=20
> Randy
>=20
>> Lada
>>=20
>>>=20
>>> Randy
>>>=20
>>>=20
>>> -----Original Message-----
>>>> From: Ladislav Lhotka 
>>>> Sent: Dec 28, 2015 12:23 AM
>>>> To: NETMOD WG 
>>>> Subject: [netmod] whitespace characters
>>>>=20
>>>> Hi,
>>>>=20
>>>> the definition of "enum" argument (sec. 9.6.4 in 6020bis) says:
>>>>=20
>>>>  The string MUST NOT be empty and MUST NOT have any leading or =
trailing
>>>>  whitespace characters.
>>>>=20
>>>> It is not clear what "whitespace character" means. The ABNF =
indicates this:
>>>>=20
>>>>  WSP                 =3D SP / HTAB
>>>>                        ; whitespace
>>>>=20
>>>> I think in the "enum" definition LF (and maybe also CR?) should =
also count as a whitespace character.
>>>>=20
>>>> Lada
>>>>=20
>>>> --
>>>> Ladislav Lhotka, CZ.NIC Labs
>>>> PGP Key ID: E74E8C0C
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>=20
>> --=20
>> Ladislav Lhotka, CZ.NIC Labs
>> PGP Key ID: E74E8C0C
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





From nobody Wed Dec 30 14:38:24 2015
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42D1D1A8A57 for ; Wed, 30 Dec 2015 14:38:24 -0800 (PST)
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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 I2sQ965V--BL for ; Wed, 30 Dec 2015 14:38:22 -0800 (PST)
Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id BD0E01A1A97 for ; Wed, 30 Dec 2015 14:38:22 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=lijbWijDpqnKxiEGEAV1lG+lr5Nadaqn/zIID/N07TZyNAI3Oahxdyg1ABd8e8LO; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.27] (helo=mswamui-billy.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aEPNm-0001yv-S7; Wed, 30 Dec 2015 17:38:14 -0500
Received: from 76.254.53.99 by webmail.earthlink.net with HTTP; Wed, 30 Dec 2015 17:38:14 -0500
Message-ID: <26372392.1451515094855.JavaMail.root@mswamui-billy.atl.sa.earthlink.net>
Date: Wed, 30 Dec 2015 14:38:14 -0800 (GMT-08:00)
From: Randy Presuhn 
To: Ladislav Lhotka 
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888857e9f10d2205ddc8c0dd8bc9387ebfbe986b6df61dfcf46350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.27
Archived-At: 
Cc: NETMOD WG 
Subject: Re: [netmod] whitespace characters
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Randy Presuhn 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 Dec 2015 22:38:24 -0000

Hi -

>From: Ladislav Lhotka 
>Sent: Dec 30, 2015 1:22 PM
>To: Randy Presuhn 
>Cc: NETMOD WG 
>Subject: Re: [netmod] whitespace characters
>
>
>> On 30 Dec 2015, at 20:07, Randy Presuhn  wrote:
>> 
>> Hi -
>> 
>>> From: Ladislav Lhotka 
>>> Sent: Dec 30, 2015 12:19 AM
>>> To: Randy Presuhn , NETMOD WG 
>>> Subject: Re: [netmod] whitespace characters
>>> 
>>> Randy Presuhn  writes:
>>> 
>>>> Hi -
>>>> 
>>>> This got me thinking - would "U+202A U+202B" thus be a valid
>>>> argument, distinct from, say, "U+202B U+202A"?
>>> 
>>> IMO they should be distinct. For "string" type, sec. 9.4.2 in 6020bis
>>> says that no Unicode normalization is performed. The same should
>>> probably be stated for string literals appearing in YANG modules.
>> 
>> Even given the semantics of U+202A (left-to-right embedding)?
>> I understand why they make a difference for strings in general,
>> but in an enum argument, cases like this seem rather pathological.
>
>Honestly, I don't know, this seems rather pathological in any case.
>I just checked programming languages that claim to have decent
>Unicode handling (Python 3, Haskell), and both consider those
>two strings non-equal. 

As *strings* they should indeed be non-equal.

As enum arguments, it seems less clear.  Is the whole point of
limiting leading and trailing whitespace merely a matter of
avoiding a pathology in the grammar, or is it actually connected
to human factors concerns?  If it's the former, then things like
LRE are a non-issue.  If it's the latter, then there's a potential
problem.

Randy